XVII Simpsio Brasileiro de Banco de Dados

XVerter: Armazenamento e Consulta de Dados XML em SGBDs

Humberto Vieira Gabriela Ruberg Marta Mattoso Coordenao dos Programas de Ps Graduao em Engenharia (COPPE) Universidade Federal do Rio de Janeiro (UFRJ) {hjvj, gruberg, marta}@cos.ufrj.br Resumo

Tcnicas de armazenamento e consulta em bases de dados XML vm sendo amplamente estudadas na literatura. A maioria dos trabalhos favorvel ao armazenamento de documentos XML em SGBDs para aproveitar o potencial de uma tecnologia bem estabelecida, alm da vantagem de armazenar dados estruturados e dados XML em um mesmo sistema. O objetivo deste trabalho propor uma soluo para a realizao de consultas XQuery sobre uma base de dados XML armazenada em um SGBDOR atravs do formato de representao DOM. So propostas regras de traduo automtica da XQuery para a SQL3, onde explorada a representao de documentos XML baseada em objetos.

Storage techniques and queries over XML databases are being widely studied. Most works store XML documents in DBMS to take advantage of a well established technology and also to store both structured data and XML data within a single system. This work proposes a translation mechanism to execute queries expressed on XML documents that are stored in an ORDBMS using the DOM representation format. Transformation rules for automatic translation from XQuery to SQL3 are presented, where the object-based representation of XML documents is explored.

Abstract

1. Introduo Com a consolidao do padro XML como a lingua franca para a troca de informaes na Web, tornaram-se essenciais mecanismos para consulta sobre bases de dados XML. Recentemente, o W3C XML Query Working Group [15] props a XQuery [17], uma linguagem de consulta para dados XML derivada principalmente da linguagem Quilt [1], mas que herda caractersticas de diferentes outras linguagens. Existem inmeros trabalhos sobre estratgias para armazenamento de documentos XML com o objetivo de facilitar o processamento de consultas [2, 3, 5, 6, 11, 13, 14]. Esses trabalhos so favorveis ao armazenamento de documentos XML em Sistemas Gerenciadores de Bases de Dados (SGBDs) tradicionais, devido s vantagens obtidas pelo armazenamento de dados estruturados legados e dados XML em um nico sistema, aliado ao aproveitamento das funcionalidades tpicas de um SGBD. Todavia, podemos identificar vrios problemas nas propostas apresentadas para o armazenamento de documentos XML em SGBDs. Primeiramente, a grande maioria dessas propostas utiliza o modelo de dados relacional [3, 6, 11, 13], que oferece poucos recursos para representar caractersticas prprias dos dados XML, como relacionamentos aninhados e ordenamento das estruturas. Em segundo lugar, os esquemas de representao de documentos XML so especficos, tornando pouco provvel o conhecimento prvio do esquema criado no SGBD para armazenar os documentos XML e dificultando o acesso declarativo aos dados. Alm disso, poucos trabalhos suportam as

224

XVII Simpsio Brasileiro de Banco de Dados

caractersticas da linguagem padro para consulta XML (XQuery), como as expresses FLWR, as expresses de caminho e os operadores curingas (por ex., o operador //). A execuo transparente de consultas escritas na linguagem XQuery em um SGBD tradicional (que no nativo de XML) requer um processo automtico de traduo para a linguagem-alvo do SGBD hospedeiro. Esta tarefa no trivial, pois necessrio que o tradutor conhea as estruturas do esquema de representao utilizado para armazenar os documentos XML no SGBD. Assim, a escolha do esquema de representao num SGBD fundamental para o sucesso de execuo de consultas XQuery. A adoo do modelo de dados relacional torna essa traduo complexa e muito ineficiente para consultas recursivas, pois o mapeamento resulta em comandos SQL verborrgicos contendo um nmero excessivo de junes. Por outro lado, o modelo de dados orientado a objetos (OO) oferece maior semntica para a representao de relacionamentos e algoritmos especficos para a execuo de consultas contendo expresses de caminho. Fegaras e Elmasri [2] apresentam uma nova linguagem de consulta XML, dita XML-OQL, e uma lgebra que permite sua traduo para linguagem OQL. Apesar de usar um mapeamento mais direto que no modelo relacional, em [2] no adotada a linguagem padro XQuery e utilizado um esquema proprietrio para o armazenamento dos dados XML. Alm disso, a lgebra apresentada bastante complexa, o que torna pouco vivel a implementao do respectivo tradutor. O objetivo do nosso trabalho propor uma arquitetura para o armazenamento de documentos XML em um SGBD objeto-relacional (SGBDOR) e para a execuo transparente de consultas escritas na linguagem XQuery. O cerne da nossa proposta o tradutor XVerter, o qual utiliza um conjunto de regras de transformao para converter consultas XQuery em comandos da linguagem SQL3. O tradutor XVerter baseado na criao do esquema do DOM (Document Object Model) [16] em um SGBDOR, consistindo em uma abordagem semelhante representao baseada em objetos proposta em [14], que apresenta um bom desempenho na execuo de consultas. Uma vantagem considervel da nossa abordagem que o DOM consiste em um padro amplamente utilizado no universo XML para a manipulao de documentos em memria principal por linguagens de programao como Java. Vale ressaltar tambm que no encontramos trabalhos sobre a implementao do formato DOM sobre classes de um SGBD. As regras de transformao do tradutor XVerter so expressas na linguagem XSLT [18], um outro padro XML recomendado pelo W3C. Nossa proposta foi validada experimentalmente no GOA [4], um prottipo de SGBDOO desenvolvido na COPPE/UFRJ, atravs da traduo de diversas consultas XQuery que exploram caractersticas definidas em [10], como as expresses de caminho e o operador //. Maiores detalhes quanto ao armazenamento de documentos XML no GOA so encontrados em [7]. O restante deste artigo est organizado da seguinte forma: a seo 2 analisa propostas de armazenamento de um documento XML em SGBDs e apresenta o formato DOM. Na seo 3, detalhamos o conjunto de regras de transformao que constituem o XVerter. A seo 4 apresenta a arquitetura do XVerter e algumas consultas utilizadas para a validao das regras de transformao do prottipo do XVerter. Finalmente, a seo 5 resume as concluses deste trabalho. 2. Estratgias para o Armazenamento de Documentos XML A estratgia mais simples para o armazenamento de documentos XML consiste na gerao e manuteno de arquivos de texto no sistema operacional, respeitando o formato original de cada documento. Esta alternativa apresenta inmeras desvantagens quanto

225

XVII Simpsio Brasileiro de Banco de Dados

flexibilidade e ao desempenho no acesso aos dados. Por isso, altamente recomendvel que bases de documentos XML sejam beneficiadas pelas funcionalidades disponveis em sistemas de bancos de dados [8]. Existem diversas abordagens para o armazenamento de um documento XML em SGBDs [14], as quais variam basicamente segundo dois aspectos: (i) o modelo de dados do SGBD; e (ii) o esquema de representao dos dados. Quanto ao modelo de dados empregado, as principais propostas existentes esto divididas entre SGBDs relacionais (SGBDRs) [3, 6, 11, 13], baseados em objetos [2, 14] e bancos nativos de XML [12]. Em [14] so analisadas cinco estratgias para o armazenamento de documentos XML que abrangem o uso do sistema de arquivos, trs variaes do uso de SGBDRs e um caso com um SGBD orientado a objetos. O emprego de SGBDs tradicionais (que no so nativos de XML) para o armazenamento de documentos XML considerado vantajoso por usufruir da segurana e do desempenho de tecnologias amplamente consolidadas, alm de permitir a aplicao do universo de recursos advindos do XML em sistemas legados. Entretanto, nesse caso no h um mapeamento direto do modelo de dados XML para o modelo de dados do SGBD hospedeiro, o que requer a identificao e o devido ajuste das possveis discrepncias. Esse processo pode incorrer em perdas semnticas, como a ordem dos elementos no documento XML, e no aumento da complexidade das estruturas utilizadas para representar a base XML. Tal complexidade compromete a clareza e o desempenho do acesso aos dados. Um outro aspecto decorrente desse hiato entre os modelos de dados a dificuldade de traduo da linguagem padro para consulta sobre dados XML (XQuery) para a linguagem-alvo do SGBD hospedeiro. Um problema adicional est na dificuldade de reconstruo do documento original. 2.1. Modelo de Dados Em SGBDRs, o mapeamento de um documento XML pode implicar na criao de vrias estruturas adicionais (colunas para chaves estrangeiras, tabelas normalizadoras para atributos multivalorados, etc.). O modelo de dados relacional privilegia o armazenamento fsico eficiente das estruturas de dados, sacrificando para isso o suporte definio e manipulao de relacionamentos entre essas estruturas. Para o processamento de expresses de caminho envolvendo vrios relacionamentos entre diferentes elementos, comuns na linguagem XQuery, esse enfoque requer comandos SQL verborrgicos e com um nmero excessivo de junes [5, 11, 14]. Por outro lado, os SGBDs baseados em objetos oferecem a riqueza semntica do modelo de dados OO, com maior transparncia para a representao de relacionamentos atravs de identificadores de objetos (OIDs) gerados automaticamente e de atributos de referncia para tais OIDs. Esse diferencial reduz significativamente o impacto da transio entre os modelos de dados XML e OO, diminuindo o nmero de estruturas auxiliares como as relacionais e facilitando a traduo da linguagem de consulta. 2.2. Esquema de Representao Quanto ao esquema de representao de documentos XML, independente do modelo de dados do SGBD, existem quatro alternativas bsicas: (i) empregar tipos especiais como os CLOBs (Character Binary Large Objects) para armazenar o documento XML no formato original; (ii) usar uma nica estrutura de dados (por exemplo, uma tabela universal);

226

XVII Simpsio Brasileiro de Banco de Dados

(iii) mapear cada elemento XML em uma estrutura de dados prpria (por exemplo, tabelas em SGBDRs e colees em SGBDORs); e (iv) adotar um esquema genrico de representao da rvore do documento XML. A primeira alternativa a mais simples e assemelha-se em muitos aspectos ao armazenamento de arquivos de texto no sistema operacional, portanto no oferecendo muitas vantagens. Em [14], a alternativa (i) equivale abordagem Texto. No caso do uso de uma nica estrutura de dados, a simplicidade da estrutura de representao possui como desvantagem a inflexibilidade para o armazenamento do esquema XML. Essa alternativa corresponde abordagem Edge em [3, 14]. Um esquema de representao mais flexvel o enfoque da alternativa (iii), onde cada elemento XML possui uma estrutura prpria no SGBD, tal que os atributos de um elemento so os atributos da estrutura equivalente. Entretanto, necessrio um atributo adicional para representar o contedo (texto) do elemento XML, alm de atributos de referncia para os relacionamentos entre os elementos. Essa abordagem otimiza o acesso a elementos de um mesmo tipo, mas dificulta bastante a reconstruo do documento XML original, pois pode gerar um nmero alto de estruturas no SGBD (contendo poucas instncias), alm de requerer razovel conhecimento sobre as estruturas de armazenamento do documento XML para a elaborao de consultas. Alm disso, no previsto claramente o armazenamento adequado de elementos com tipos distintos (em nveis e documentos diferentes e com atributos prprios) mas com o mesmo nome. As abordagens DTD e Atributo, apresentadas em [14], so exemplos desta alternativa. Observe que tanto em (ii) como em (iii) difcil representar certas caractersticas importantes dos dados XML, como a ordem em que os elementos aparecem no documento. Por fim, na adoo de um esquema genrico para representar documentos XML, como a abordagem Objeto apresentada em [14], so solucionados muitos dos problemas citados nas alternativas anteriores. Nesta abordagem, no gerado um nmero alto de estruturas de dados e no h conflito de nomes de elementos XML. Entretanto, o grande problema consiste na necessidade de conhecer as estruturas especficas do esquema de representao para a elaborao de consultas XQuery. A maioria dos trabalhos que adotam essa abordagem de armazenamento define um esquema proprietrio para a representao dos dados [2, 14], muitas vezes dependente de recursos do SGBD hospedeiro. Isso dificulta o compartilhamento da pesquisa realizada e torna ainda menos provvel o conhecimento prvio das estruturas utilizadas por parte do usurio. Para minimizar esse problema, ns propomos a adoo do formato DOM para o armazenamento de documentos XML em um SGBDOR, pois este formato consiste em uma representao amplamente conhecida no universo XML. A rvore DOM possui a vantagem considervel de ser um padro para a manipulao de documentos XML em memria principal, com grande representatividade das principais caractersticas do XML (por exemplo, conservada a ordenao dos elementos). Por usar uma estrutura de dados tradicional, a rvore DOM permite o emprego de algoritmos simples, eficientes e bastante conhecidos para a manipulao dos elementos XML. A principal desvantagem da rvore DOM para o armazenamento de documentos XML em SGBDs decorre do baixo desempenho das consultas que recuperam elementos XML de um mesmo tipo, visto que tais elementos esto espalhados pela rvore. Todavia, estruturas de indexao da rvore DOM podem ser utilizadas para minimizar este problema. importante ressaltar que, pelo uso intensivo de relacionamentos e operaes de navegao, a implementao do DOM em SGBDRs pouco factvel.

227

XVII Simpsio Brasileiro de Banco de Dados

2.3. rvores DOM para Armazenar Documentos XML No contexto de SGBDs baseados em objetos, acreditamos que o formato DOM oferece a melhor relao entre a semntica oferecida para representao dos documentos XML e a eficincia de acesso aos dados. Todavia, nesta estratgia ainda persiste a necessidade de conhecimento prvio dos tipos que compem a rvore DOM para a elaborao de consultas SQL sobre os documentos XML armazenados. Portanto, extremamente necessrio um mecanismo que transforme uma consulta sobre documentos XML escrita em XQuery (que deve ser a mais natural ao usurio do documento XML) em uma consulta sobre a rvore DOM escrita na linguagem do SGBD. Neste artigo, ns apresentamos regras de traduo da linguagem XQuery para a linguagem SQL3 e mostramos que as caractersticas da rvore DOM facilitam significativamente esse processo, conforme o conjunto de regras propostas na seo 3.2. O nosso objetivo aproveitar a infra-estrutura oferecida por SGBDORs, como tambm tornar o processo de transformao o mais simples possvel. Para tanto, necessrio um formato de armazenamento que nos permita acessar um esquema de representao conhecido e reconstruir com facilidade o documento XML ou parte dele. Como o formato DOM se enquadra nestas caractersticas, optamos por utilizar esta abordagem para o armazenamento de documentos XML. Atravs da criao e povoamento de classes da rvore DOM possvel consultar os dados armazenados. A seguir, explicamos rapidamente como acessar o contedo de um documento XML armazenado na rvore DOM e o procedimento para recuperar elementos da rvore. A classe DocumentImpl, como o prprio nome sugere, armazena informaes sobre os diferentes documentos XML armazenados na rvore DOM. J a classe ElementImpl responsvel por armazenar os elementos XML, deixando para a classe TextImpl guardar o seu contedo. A classe AttrImpl guarda, alm do nome do atributo, o seu valor. A navegao entre as classes realizada atravs do atributo childrenNode, que pertence classe NodeImpl. Todas as classes citadas anteriormente so herdadas de NodeImpl. Os nomes de elementos e atributos XML ficam armazenados no atributo name e seus contedos no atributo value.
<recados> <recado id = 1> <para>Joao</para> <cabecalho>Lembrete</cabecalho> </recado> <recado id = 2> <para>Maria</para> <cabecalho>Colegio</cabecalho> </recado> </recados>

DocumentImpl recados.xml ElementImpl <recados>

ElementImpl <recado>

ElementImpl <recado>

AttrImpl <id = 1>

ElementImpl ElementImpl AttrImpl ElementImpl ElementImpl <para> <cabecalho> <id = 2> <para> <cabecalho> TextImpl Joao TextImpl Lembrete TextImpl Maria TextImpl Colegio

Figura 1. Exemplo de armazenamento de um documento XML no formato DOM

Portanto, uma consulta sobre determinado documento comea sobre o DocumentImpl e continua atravs do atributo childrenNode, alcanando desta forma a raiz do documento. Prosseguindo atravs do childrenNode, acessamos os elementos filhos da raiz e assim sucessivamente, at chegarmos aos ns-folhas do documento. importante ressaltar que os

228

XVII Simpsio Brasileiro de Banco de Dados

nomes e os valores de atributos XML encontram-se em um mesmo n da rvore, ao contrrio do que ocorre em elementos. Desta forma, para acessar o contedo de determinado elemento, precisamos navegar mais uma vez pelo childrenNode, para s ento recuperar o seu valor. A Figura 1 apresenta o exemplo de um documento XML e as classes da rvore DOM correspondente a esta representao. 3. Transformao XQuery->SQL3 Este artigo apresenta uma arquitetura para traduo da linguagem XQuery na linguagem SQL3, conforme mostrado na Figura 2. A idia inicial consiste no envio de um documento XML ao Mdulo de Armazenamento, que representa este documento atravs de uma rvore DOM em um SGBDOR. A partir da, o documento armazenado no DOM pode ser consultado atravs da linguagem XQuery de maneira transparente, respeitando as caractersticas do documento XML original. As consultas XQuery so submetidas ao XVerter, um tradutor automtico, dando a impresso que existe um processador nativo de consultas XML. Com isso, podemos explorar a potencialidade de execuo otimizada de consultas em SGBDs j existentes. A seo 4 apresenta mais detalhes sobre a arquitetura da Figura 2.
XQuery sobre os documentos XML Aplicao das regras de transformao SQL3 sobre as classes do DOM Armazenamento dos documentos XML no formato DOM Documentos XML Mdulo de Armazenamento Resultado

XVerter

SQL3

SGBDOR SGBDRO

Figura 2. Contexto geral da arquitetura proposta

A XQuery uma linguagem bastante poderosa e fornece uma enorme variedade de funcionalidades para consultar dados XML. Porm, devido s suas caractersticas, no existe um mapeamento direto entre a XQuery e a linguagem de consulta tpica de SGBDORs a SQL3. Isto quer dizer que algumas consultas XQuery requerem construes adicionais SQL3 para que o mapeamento seja satisfeito. O nosso trabalho engloba a traduo de todas as operaes de consulta da XQuery, com exceo das expresses condicionais (por limitaes do SQL3, que uma linguagem de consulta essencialmente declarativa). As principais caractersticas da linguagem XQuery, as quais so apresentadas neste trabalho, so: ' Expresses FLWR (FOR-LET-WHERE-RETURN); ' Navegao sobre as expresses de caminho; ' Uso do operador //. Validamos essas caractersticas inovadoras atravs de experimentos baseados no benchmark [10] sobre processadores XQuery, visando avaliar o potencial desta linguagem e as principais implementaes existentes. A base de testes foi gerada a partir do XML Generator [10]. As consultas do benchmark foram testadas sobre os sistemas XQuery Demo [19] e Quip [9]. Esses sistemas so considerados nativos de XML e no realizam o mapeamento XQuery->SQL. poca do teste, apenas uma (consulta por valor exato), dentre as quatorze caractersticas apresentadas no benchmark, estava presente no XQuery Demo. J o Quip atendeu a esta caracterstica e a mais quatro: acesso ordenado pela posio dos elementos no documento original, reconstruo do documento XML, navegao em

229

XVII Simpsio Brasileiro de Banco de Dados

expresses de caminho e ordenao do resultado (SORTBY). Com base nesse experimento, verificamos que os sistemas existentes concentram-se no suporte a um conjunto limitado de caractersticas da linguagem XQuery. 3.1. Expresses de Caminho DEFINIO 1 (Expresso de caminho): Uma expresso de caminho (EC) representa um percurso por uma seqncia EC:root/e[1][p1]/.../e[n][pn] de elementos XML relacionados, onde root indica a raiz do documento XML para o qual EC analisada e os termos da forma e[i], 1in, representam os elementos XML nomeados tal que e[0]=root e e[i-1] pai de e[i]. O comprimento de EC determinado pelo nmero de elementos envolvidos, sendo denotado por n. Podem ser definidos predicados aninhados sobre os elementos e/ou atributos de elementos contidos em uma EC. Cada predicado aninhado pi, 1in, opcional e pode ser escrito como uma combinao lgica de termos da forma (e[i]|a[i])<operador><valor>, onde a[i] representa um atributo do elemento e[i]. DEFINIO 2 (Radical de uma Expresso de Caminho): Denotamos ECr como o radical de uma expresso de caminho ECx de comprimento n, tal que ECr uma expresso de caminho de comprimento m e ECr ECx, mn. 3.2 Regras de Transformao Uma consulta em XQuery possui como estrutura bsica uma expresso FLWR da forma: FOR [declarao de cursores] LET [atribuio de cursores] WHERE [predicados de seleo] RETURN [projeo do resultado]. Um expresso FLWR denotada por Q pode conter um conjunto de ECs, representado por SQ={EC1,...,ECw}, w0. Na converso desta estrutura para a representao tradicional SELECT-FROM-WHERE da SQL3, ns devemos observar as seguintes regras: 1. O resultado da consulta corresponde projeo feita na clusula RETURN da XQuery. Esse resultado descrito na clusula SELECT da SQL3; 2. As clusulas FOR, LET, WHERE e RETURN da XQuery definiro os cursores a serem especificados na clusula FROM da SQL3. Nessas clusulas so declaradas as ECs contidas em SQ, onde a quantidade de cursores determinada pelo comprimento de cada ECxSQ, denotado por nx, tal que: a. Para cada ECx , 1xw, declarado um cursor dx que representa a raiz do documento XML correspondente, da forma dx in DocumentImpls; b. Para cada elemento nomeado e[i]ECx, 1xw e 1inx, declarado um cursor ci da forma ci in ci-1.childrenNode, onde c0=dx. No caso de existirem vrias ECs na consulta, os cursores sero identificados por cai, cbi , ..., e assim sucessivamente para cada EC declarada; c. Para cada elemento XML nomeado e[i], 1inx, de cada ECxSQ, 1xw, cujo valor acessado na consulta e para cada atributo a[i], 1inx, especificado em cada ECxSQ, 1xw, declarado um cursor ci+1 da forma ci+1 in ci.childrenNode;

230

XVII Simpsio Brasileiro de Banco de Dados

3. A clusula WHERE da XQuery corresponde quase diretamente clusula WHERE da SQL3. Neste caso, observamos tambm que, alm dos predicados definidos sobre elementos e atributos XML, teremos predicados derivados de: a. Declarao dos documentos XML na clusula FOR da XQuery; b. Declarao de cada elemento XML nomeado nas ECs, ou seja, para cada e[i]ECx, 1inx, ECxSQ, 1xw, necessrio declarar um predicado aninhado pi referente ao nome de e[i]. c. Declarao de junes de ECs relativas clusula LET. Passo de Otimizao: Em uma consulta Q, duas expresses de caminho Ecx e Ecy, tal que ECxSQ e ECySQ, podem compartilhar os cursores correspondentes se possurem um radical comum ECr. Os cursores compartilhados so os determinados pela estrutura de ECr. Em consulta XQuery sobre uma rvore DOM de um documento XML, cuja altura (nmero de nveis de elementos XML da rvore) representada por h, assumimos a seguinte representao: e[i.1], ..., e[i.k]: nomes dos k diferentes elementos XML que esto armazenados em um mesmo nvel i, 1ih, da rvore DOM; a[i.1], ..., a[i.k]: k diferentes atributos de um elemento e[i], 1ih, da rvore DOM. 3.2.1. Traduo de uma Expresso de Caminho Explcito. A Figura 3 apresenta um exemplo que transforma uma EC simples da XQuery, de comprimento n, em um comando da SQL3. A parte da linha 1 da XQuery que faz referncia ao nome do documento tem como equivalentes a linha 2 da SQL3 (decorrente da regra 2a) e a linha 5 (aplicao da regra 3a). Aplicando as regras 2b e 2c, o restante da linha 1 da XQuery (que define a EC) corresponde s linhas 3 e 4 da SQL3, respectivamente (onde so declarados os cursores que navegam na rvore DOM atravs do atributo childrenNode). As linhas 6 e 7 da SQL3 so montadas a partir da regra 3b. Por fim, a linha 2 da XQuery (referente projeo do resultado) equivale linha 1 da SQL3, aps ser aplicada a regra 1. importante ressaltar a necessidade de declarar todos os elementos XML nomeados na EC da XQuery na clusula WHERE da SQL3. Um retorno errado poder acontecer caso o e[i], 1in, esteja presente mais de uma vez no documento XML e seja filho de diferentes ns-pais (por exemplo, e[y] e e[z]). Se quisermos consultar o e[i] filho de e[y] e no declararmos um predicado referente ao elemento e[y] na clusula WHERE, o resultado desta consulta poder retornar tambm o e[i] filho de e[z].
XQuery 1 for $x in document(doc.xml)/e[1]/e[2]//e[n] 2 return $x SQL3 1 select resultado(result: cn+1.value) 2 from d1 in DocumentImpls, 3 c1 in d1.childrenNode, c2 in c2.childrenNode,, 4 cn+1 in cn.childrenNode 5 where (d1.name = doc.xml) and 6 (c1.name = e[1]) and (c2.name = e[2]) and and 7 (cn.name = e[n])

Figura 3. Expresso de caminho explcito

Tambm precisamos declarar o nome do documento na clusula WHERE porque vrios documentos podem estar armazenados na mesma base. Caso ocultemos o nome do

231

XVII Simpsio Brasileiro de Banco de Dados

documento pesquisado, o resultado poder retornar os elementos de um outro documento XML que tambm satisfizerem s condies da consulta. Verifique que a rvore DOM precisa ser percorrida at o nvel mximo da expresso de caminho, j que a nossa abordagem de armazenamento no extrai um esquema onde classes representam cada elemento no documento XML (e o acesso somente aos elementos nomeados da EC no possvel). Neste exemplo, so criados n+1 cursores ci para percorrer os n nveis de elementos da EC contida na XQuery, sendo o ltimo cursor necessrio para acessar o valor do elemento armazenado no nvel n. 3.2.2. Traduo de uma Expresso de Caminho Explcito com Atributos. O exemplo da Figura 4 tem apenas uma diferena em relao ao exemplo anterior: a presena de atributos XML na EC. Como observamos no exemplo anterior, o contedo de um elemento e[i] fica armazenado em um n no nvel i+1 da rvore DOM. Do mesmo modo, o nome e o contedo de um atributo a[i] (pertencente ao elemento e[i]) encontram-se armazenados no nvel i+1 da rvore DOM. Desta forma, n+1 cursores devem ser declarados na clusula FROM da SQL3.
XQuery 1 for $x in document(doc.xml)/e[1]//e[n][@a[n]<operador><valor>] 2 return $x SQL3 1 select resultado(result: cn.value) 2 from d1 in DocumentImpls, 3 c1 in d1.childrenNode, c2 in c1.childrenNode,, 4 cn in cn-1.childrenNode, cn+1 in cn.childrenNode 5 where (d1.name = doc.xml) and 6 (c1.name = e[1]) and (c2.name = e[2]) and and 7 (cn.name = e[n]) and 8 (cn+1.name = @a[n]) and (cn+1.value <operador> <valor>)

Figura 4. Expresso de caminho explcito com atributos

3.2.3. Traduo de XQuery contendo Vrias Expresses de Caminho. O exemplo da Figura 5 consiste em uma generalizao dos exemplos anteriores. Neste caso, mais de uma EC est presente na consulta XQuery, como podemos verificar nas linhas 2 a 5. Deste modo, de acordo com a regra 2, precisamos fazer referncia a todas elas na clusula FROM da SQL3 para podermos representar os predicados de consulta existentes na clusula WHERE da XQuery. Porm, considerando o nosso passo de otimizao, no necessrio declarar todas as ECs completamente, j que elas possuem um radical ECr em comum (o radical que comea em e[1] e segue at e[n-1] est presente em todas as ECs da consulta), cuja declarao equivale linha 4 da SQL3. As linhas 3 a 8 representam as declaraes das diferentes ECs presentes na XQuery, conforme determinado pelas regras 2b e 2c. Seguindo a regra 3b, os predicados correspondentes consultas so declarados nas linhas 10 a 14 da SQL3. Atravs da regra 3a, a linha 5 da XQuery equivale linha 1 da SQL3. A declarao do documento na linha 1 da XQuery equivale linha 2 da SQL3 (aplicando a regra 2a) e linha 9 (ao seguirmos a regra 3b). Finalmente, aps aplicada a regra 1, a linha 5 da XQuery corresponde linha 1 da SQL3. Embora o comando SQL3 resultante na Figura 5 parea um pouco longo, j que o caminho deve ser explicitado totalmente tanto para os predicados de consulta quanto para o esquema XML (nomes dos elementos), no caso da representao relacional sem o uso do DOM, o comando SQL ficaria bem maior devido s inmeras junes, como pode ser observado em [5].

232

XVII Simpsio Brasileiro de Banco de Dados

XQuery 1 for $x in document(doc.xml)/e[1]/e[2]/.../e[n-1] 2 where $x/e[n.1] = constante[1] and 3 $x/e[n.2] = constante[2] and ... and 4 $x/e[n.(k-1)] = constante[k-1] 5 return $x/e[n.k] SQL3 1 select resultado(result: czn+1.value) 2 from d1 in DocumentImpls, 3 ca1 in d1.childrenNode, ca2 in ca1.childrenNode,, 4 can-1 in can-2.childrenNode, 5 can in can-1.childrenNode, can+1 in can.childrenNode, 6 cbn in can-1.childrenNode, cbn+1 in cbn.childrenNode, 7 ccn in can-1.childrenNode, ccn+1 in ccn.childrenNode,, 8 czn in can-1.childrenNode, czn+1 in czn.childrenNode 9 where (d1.name = doc.xml) and 10 (ca1.name = e[1]) and (ca2.name = e[2]) and and 11 (can.name = e[n.1]) and (can+1.value = constante[1]) and 12 (cbn.name = e[n.2]) and (cbn+1.value = constante[2]) and ... and 13 (cyn.name = e[n.(k-1)]) and (cyn+1.value = constante[k-1]) and 14 (czn.name = e[n.k])

Figura 5. XQuery contendo vrias expresses de caminho

3.2.4. Traduo do Operador //. Em todos os exemplos vistos at agora, o caminho completo das ECs est declarado na consulta XQuery. Porm, bastante comum em uma consulta XQuery a especificao de um determinado elemento nomeado no documento XML que pode ser encontrado em qualquer nvel de profundidade na rvore. E exatamente este o objetivo do operador //, onde root/e[1]/.../e[n]//e[j] indica que, partindo de root/e[1]/.../e[n], desejamos alcanar todos os elementos com nome e[j] independente dos caminhos existentes entre eles e a raiz da rvore DOM, ou mesmo do nvel onde e[j] se encontra. O termo conhecido nesse problema o comprimento do radical de elementos nomeados, representado por n. Para traduzir o // para SQL3 no suficiente declarar na clusula WHERE apenas aqueles elementos que so nomeados na EC. Necessitamos descobrir a altura mxima da rvore para definirmos quantos cursores sero declarados na clusula FROM e para construirmos os predicados correspondentes na clusula WHERE. Portanto, esta traduo ser realizada em dois passos: (i) descobrir a altura da rvore; e (ii) construir a consulta resultante. No nosso procedimento de armazenamento no formato DOM, utilizamos o campo value da classe DocumentImpl para guardar a altura mxima da rvore DOM, considerando os ns que armazenam elementos XML. Desta forma, teremos acesso a esta informao apenas com a consulta trivial mostrada na Figura 6.
select resultado(result: d1.value) from d1 in DocumentImpls where (d1.name = doc.xml)

Figura 6. Consulta para descobrir a altura mxima da rvore DOM

Aps a execuo desta consulta, temos o resultado da altura mxima da rvore (desconsiderando os ns de contedo e os ns de atributos XML) e estamos aptos para construir a consulta final. A Figura 7 mostra a traduo de uma EC contendo o operador // em uma rvore DOM com altura h. Utilizando as regras 2b e 3b respectivamente, as linhas 3 e 6 da SQL3 correspondem aos elementos declarados na linha 1 da XQuery que comea em e[1] e vai at e[n]. Pelas regras 2b e 2c, a linha 4 da SQL3 declara os cursores necessrios para percorrer a rvore DOM conforme o critrio de busca por e[j]. J as linhas 7 e 8, atravs da regra 3b, definem os predicados destes cursores, utilizando o operador lgico or para indicar que o elemento

233

XVII Simpsio Brasileiro de Banco de Dados

e[j] pode estar em qualquer nvel da rvore DOM, desde o nvel n+1 at o nvel h.

Aplicando a regra 1, a linha 1 da SQL3 equivale linha 2 da XQuery e inclui na projeo todas as possibilidades de resposta, desde o nvel n+1 at o h. E finalmente, conforme j visto nos exemplos anteriores, atravs da aplicao das regras 2a e 3a , construmos respectivamente as linhas 2 e 5 da SQL3, que correspondem declarao do documento XML.
XQuery 1 for $x in document(doc.xml)/e[1]/e[2]/.../e[n]//e[j] 2 return $x SQL3 1 select resultado(result: a[n+2].value, result: a[n+3].value,...,result: a[h+1].value) 2 from d1 in DocumentImpls, 3 c1 in d1.childrenNode, c2 in c1.childrenNode,, cn in cn-1.childrenNode, 4 cn+1 in cn.childrenNode,, ch in ch-1.childrenNode, ch+1 in ch.childrenNode 5 where (d1.name = doc.xml) and 6 (c1.name = e[1]) and (c2.name = e[2]) and and (cn.name = e[n]) and 7 ((cn+1.name= e[j]) or (cn+2.name= e[j]) or or 8 (ch-1.name= e[j]) or (ch.name= e[j]))

Figura 7. Expresso de caminho utilizando o operador //

3.2.5. Traduo do LET. A clusula LET de uma expresso FLWR representa uma atribuio de cursores, que basicamente consiste na juno de ECs. Portanto, esta clusula tratada de maneira semelhante declarao das ECs presentes na clusula FOR. O exemplo da Figura 8 ilustra a utilizao do LET. As linhas 5, 6 e 9 da SQL3 equivalem declarao da EC no LET, atravs da aplicao das regras 2b, 2c e 3b respectivamente. Da mesma forma, as linhas 3, 4 e 8 correspondem EC declarada no FOR. As linhas 2 e 7 da SQL3 equivalem aos documentos declarados no FOR e LET, nas linhas 1 e 2 da XQuery, ao serem aplicadas as regras 2a e 3a respectivamente. A linha 3 da XQuery equivale linha 1 da SQL3, atravs da regra 1. E finalmente, a regra 3c define a linha 10 da SQL3 que equivale ao final da linha 2 da XQuery ([f[m]=$x]).
XQuery 1 for $x in document(doc1.xml)/e[1]/e[2]/.../e[n] 2 let $y := document(doc2.xml)/f[1]/f[2]//f[m-1][f[m]=$x] 3 return $y/f[m] SQL3 1 select resultado(result:cbm+1.value) 2 from d1 in DocumentImpls, d2 in DocumentImpls, 3 ca1 in d1.childrenNode, ca2 in ca1.childrenNode,, can in can-1.childrenNode, 4 can+1 in can.childrenNode, 5 cb1 in d2.childrenNode, cb2 in cb1.childrenNode,, cbm in cbm-1.childrenNode, 6 cbm+1 in cbm.childrenNode, 7 where (d1.name = doc1.xml) and (d2.name = doc2.xml") and 8 (ca1.name = e[1]) and (ca2.name = e[2]) and and (can.name = e[n]) and 9 (cb1.name = f[1]) and (cb2.name = f[2]) and and (cbm.name = f[m]) and 10 (can+1.value = cbm+1.value)

Figura 8. Utilizao do LET

4. Avaliao do XVerter Neste artigo, ns propomos o tradutor XVerter para converter consultas XQuery em consultas escritas em linguagens-alvos de SGBDs, de acordo com a arquitetura exibida na Figura 9 (que corresponde a um detalhamento da Figura 2). Foi implementado um prottipo do XVerter com um conjunto de regras para gerao de consultas em SQL3 a partir da

234

XVII Simpsio Brasileiro de Banco de Dados

linguagem XQuery, conforme apresentado na seo anterior. Validamos um conjunto de consultas XQuery traduzidas para SQL3 no GOA, um prottipo de um SGBDOR. Foram implementados no GOA os recursos para o armazenamento de documentos XML no formato DOM. Ao receber uma XQuery como entrada, o tradutor XVerter gera uma representao interna da consulta, faz as devidas normalizaes e aplica as regras necessrias para transformar a consulta XQuery em SQL3. A consulta em SQL3 executada sobre as classes do DOM e o resultado retornado para o usurio. A rvore DOM previamente criada no prottipo de SGBD na ocasio da carga dos documentos XML. Observe que a arquitetura interna do tradutor XVerter genrica, pois os documentos podem estar armazenados em qualquer formato e em qualquer SGBD, desde que as regras aplicadas sejam capazes de transformar a XQuery na linguagem utilizada pelo SGBD alvo.
XQuery sobre os documentos XML Aplicao das regras de transformao SQL3 sobre as classes do DOM SQL3 Armazenamento dos documentos XML no formato DOM Documentos XML Regras de Transformao (SQL, SQL3,...) Linguagens alvo Mdulo de Armazenamento SQL SQL3 Resultado SGBDOR SGBDRO

XVerter

Java/C++

Regras de Reescrita

SGBD Relacional

SGBD Rel. Objeto Objeto Rel. SGBD Nativo XML

XQuery

Normalizador

Tradutor

XQuery

Figura 9. Arquitetura interna do tradutor XVerter

O ncleo do XVerter est implementado na linguagem XSLT, que oferece uma maior expressividade para a definio e a manuteno das regras de transformao. Em nossa arquitetura, diferentes SGBDs alvos podem ser representados por cartuchos de regras especficas em XSLT, configurando uma soluo coerente com o formato XML. Vale ressaltar que o processo de traduo baseada no formato DOM automtico e, com exceo do operador //, independe do estado do banco de dados. Ou seja, no so necessrias conexes adicionais ao SGBD alm da consulta propriamente dita. Deste modo, o tempo gasto na traduo irrisrio, pois o processamento necessrio consiste em uma simples transformao de palavras dentro de um texto curto (consulta XQuery). No caso de consultas contendo o operador //, somente ser necessrio o acesso adicional ao SGBD (para descobrir a altura da rvore DOM) se o operador de consulta correspondente no estiver implementado no banco de dados, ou ainda se o SGBD no suportar mtodos ou funes, como ocorre no GOA. Quanto ao desempenho da nossa abordagem de armazenamento, em [14] apresentada uma anlise detalhada do processamento de diferentes tipos de consultas XML em uma estratgia de representao (dita Objeto) estruturalmente similar nossa. Essa anlise indica bons resultados para a representao baseada em objetos, principalmente na reconstruo dos documentos XML. Foram utilizados dois documentos XML para os testes de traduo XQuery->SQL3 (recados.xml e cartas.xml), apresentados na Figura 10 e na Figura 11, respectivamente.

235

XVII Simpsio Brasileiro de Banco de Dados

<recados> <recado id="1"> <para>Joao</para> <de>Jane</de> <cabecalho>Lembrete</cabecalho> <corpo>Nao se esqueca de mim no fim de semana.</corpo> <data><dia>01</dia><mes>02</mes><ano>2001</ano></data> </recado> <recado id="2"> <para>Maria</para> <de>Jane</de> <cabecalho>Colegio</cabecalho> <corpo>Nao se esqueca do dever de casa.</corpo> <data><dia>01</dia><mes>03</mes><ano>2001</ano></data> </recado> <recado id="3"> <para>Joao</para> <de>Maria</de> <cabecalho>Almoco</cabecalho> <corpo>Hoje eu vou almocar em casa.</corpo> <data><dia>02</dia><mes>02</mes><ano>2001</ano></data> </recado> </recados>

<cartas> <carta id="1"> <para>Joao</para> <de>Maria</de> <assunto>Viagem</assunto> </carta> <carta id="2"> <para>Jane</para> <de>Joao</de> <assunto>Empresa</assunto> </carta> <bilhete id="1"> <conteudo> <para>Maria</para> <de>Jane</de> <assunto>Carro</assunto> </conteudo> </bilhete> </cartas>

Figura 10. recados.xml

Figura 11. cartas.xml

Apresentamos a seguir algumas consultas testadas no XVerter, que correspondem aos cinco exemplos bsicos de traduo explicados na seo anterior: EC explcito, EC explcito com atributos, consulta com vrias expresses de caminho, uso do operador // e uso da clusula LET. Essas consultas so baseadas nas caractersticas especificadas no benchmark proposto em [10]. As consultas so apresentadas na Tabela 1, onde a coluna Mapeamento representa a figura onde os termos e o resultado da traduo so exibidos.
Tabela 1. Consultas para avaliao do tradutor XVerter

Consulta Q1 Q2 Q3 Q4 Q5

Texto Retornar os dias de todos os recados do documento recados.xml.

Mapeamento Figura 12 Figura 13 Figura 14 Figura 15

Listar os identificadores de todos os recados do documento recados.xml. Listar as pessoas para as quais Jane enviou recados no documento recados.xml. Listar todos os assuntos descendentes de cartas no documento cartas.xml.

Listar as pessoas que enviaram cartas no documento cartas.xml e que tambm foram Figura 16 remetentes no documento recados.xml.
XQuery FOR $n IN document("recados.xml")/recados/recado[@id<5] RETURN $n SQL3 select resultado(result: c2.value) from d1 in DocumentImpls, c1 in d1.childrenNode, c2 in c1.childrenNode, c3 in c2.childrenNode where (d1.name = recados.xml) and (c1.name = recados) and (c2.name = recado) and (c3.name = id) and (c3.value < 5) Resultado { [ "1" ] [ "2" ] [ "3" ] }

XQuery FOR $n IN document("recados.xml")/recados/recado/data/dia RETURN $n SQL3 select resultado(result: c5.value) from d1 in DocumentImpls, c1 in d1.childrenNode, c2 in c1.childrenNode, c3 in c2.childrenNode, c4 in c3.childrenNode, c5 in c4.childrenNode where (d1.name = recados.xml) and (c1.name=recados) and (c2.name=recado) and (c3.name = data) and (c4.name = dia) Resultado { [ "01" ] [ "01" ] [ "02" ] }

Figura 12. Traduo da Consulta Q1

Figura 13. Traduo da Consulta Q2

236

XVII Simpsio Brasileiro de Banco de Dados

XQuery FOR $n IN document("recados.xml")/recados/recado WHERE $n/de = "Jane" RETURN $n/para SQL3 select resultado(result: cb4.value) from d1 in DocumentImpls, ca1 in d1.childrenNode, ca2 in ca1.childrenNode, ca3 in ca2.childrenNode, ca4 in ca3.childrenNode, cb3 in ca2.childrenNode, cb4 in cb3.childrenNode where (d1.name = recados.xml) and (ca1.name = recados) and (ca2.name = recado) and (ca3.name = de) and (ca4.value = Jane) and (cb3.name = para) Resultado { [ "Joao" ] [ "Maria" ] }

XQuery FOR $n IN document("cartas.xml")/cartas//assunto RETURN $n SQL3 select resultado(result1: c4.value, result2: c5.value) from d1 in DocumentImpls, c1 in d1.childrenNode, c2 in c1.childrenNode, c3 in c2.childrenNode, c4 in c3.childrenNode, c5 in c4.childrenNode where d1.name = cartas.xml and (c1.name = cartas) and ((c2.name = assunto) or (c3.name = assunto) or (c4.name = assunto)) Resultado { [ "Viagem" "null" ] [ "Empresa" "null" ] [ "null" "Carro" ] }

Figura 14. Traduo da Consulta Q3

XQuery for $x in document("recados.xml")/recados/recado/de let $y := document("cartas.xml")/cartas/carta[de=$x] return $y/de

Figura 15. Traduo da Consulta Q4

SQL3 select resultado(result: cb4.value) from d1 in DocumentImpls, d2 in DocumentImpls, ca1 in d1.childrenNode, ca2 in ca1.childrenNode, ca3 in ca2.childrenNode, ca4 in ca3.childrenNode, cb1 in d2.childrenNode, cb2 in cb1.childrenNode, cb3 in cb2.childrenNode, cb4 in cb3.childrenNode where (d1.name = recados.xml) and (d2.name = cartas.xml) and (ca1.name = recados) and (ca2.name = recado) and (ca3.name = de) and (cb1.name = cartas) and (cb2.name = carta) and (cb3.name = de) and (ca4.value = cb4.value) Resultado { [ "Maria" ] }

Figura 16. Traduo da Consulta Q5

5. Concluses A soluo proposta neste trabalho para o armazenamento e consulta sobre os dados XML em SGBDORs tem inmeras vantagens. J que estamos realizando o armazenamento em um SGBD consolidado, aproveitamos todo o seu potencial nos aspectos importantes de um SGBD, como a execuo eficiente de consultas. Alm disso, dados j armazenados em um SGBD podem conviver com novos dados XML, sem a necessidade de utilizao de um segundo SGBD para esta finalidade. Outro aspecto positivo da nossa abordagem a utilizao do modelo objeto-relacional em vez do relacional, que o foco da maioria dos trabalhos existentes. Nestes trabalhos, so apresentados SQLs complexos e de difcil traduo, ao contrrio do que nossa abordagem proporciona com a utilizao da combinao SGBDOR e formato DOM. Uma outra vantagem o uso de dois padres amplamente conhecidos no universo XML, que so a linguagem XQuery e o DOM. Portanto, a nossa proposta no utiliza esquemas de representao proprietrios nem linguagens de consulta adaptadas para facilitar a transformao, como ocorre com outros trabalhos relacionados. A facilidade para a recuperao total ou parcial do documento XML tambm favoreceu a escolha do esquema de representao DOM. Vale ressaltar que, embora o DOM seja um formato bastante conhecido, no encontramos trabalhos que exploram a estrutura de rvore DOM no armazenamento de documentos XML em SGBDs. Este formato geralmente utilizado para a manipulao de documentos XML na memria principal. A arquitetura proposta para a traduo da linguagem de consulta XQuery genrica e flexvel para a gerao de diferentes linguagens-alvo. Isto contribui bastante para a consolidao do XML como a lingua franca de ambientes distribudos e heterogneos. Alm disso, o uso da linguagem XSLT para expressar as regras de transformao do XVerter torna o processo de traduo mais
237

XVII Simpsio Brasileiro de Banco de Dados

coerente com o padro XML, oferecendo maior expressividade e extensibilidade soluo proposta. O tempo gasto no processo de traduo baseada no formato DOM irrisrio, pois no so necessrias conexes adicionais ao SGBD alm da consulta propriamente dita. Por fim, a soluo apresentada neste trabalho para o armazenamento de documentos XML e a traduo de consultas XQuery simples de ser implementada em qualquer SGBDOR, pois as nicas modificaes que precisam ser efetuadas so a criao de um mecanismo de importao dos documentos XML para o formato DOM e, eventualmente, o ajuste das regras apresentadas neste trabalho. 6. Agradecimentos Este trabalho foi parcialmente financiado pelo CNPq, pela CAPES e pela FAPERJ. A autora Gabriela Ruberg est sob licena do Banco Central do Brasil. O contedo deste artigo representa o ponto de vista dos autores e no necessariamente o do Banco Central ou de seus membros. Referncias 1. Chamberlin, D., Robie, J. e Florescu, D.: Quilt: An XML Query Language for Heterogeneous Data Sources. WebDB 2000, pp. 1-25 . 2. Fegaras, L. e Elmasri, R.: Query Engines for Web-Accessible XML Data. VLDB 2001, pp. 251-260. 3. Florescu, D. e Kossman, D.: Storing and Querying XML Data using an RDBMS. IEEE Data Engineering Bulletin 22(3) 1999, pp. 27-34. 4. GOA++: Gerente de Objetos Armazenados. http://www.cos.ufrj.br/~goa. 5. Manolescu, I., Florescu, D. e Kossmann, D.: Answering XML Queries Over Heterogeneous Data Sources. VLDB 2001, pp. 241-250. 6. Manolescu, I., Florescu, D., Kossmann, D., Xhumari, F. e Olteanu, D.: Agora: Living with XML and Relational. VLDB 2000, pp. 623-626. 7. Mattoso, M., Cavalcanti, M. C., Pinheiro, R., Vieira, H., Azevedo, L. G., Marques, C. F., Monteiro, R. S., Gonalves, F. C., Werner, C.: Gerncia de Documentos XML no GOA, a ser publicado no XVI Simpsio Brasileiro de Engenharia de Software 2002, Sesso de Ferramentas. 8. McHugh, J.: Data Management and Query Processing for Semistructured Data. Tese de Doutorado, Department of Computer Science, Stanford University, EUA (2000). 9. Quip. http://www.softwareag.com/developer/quip/default.htm. 10. Schmidt, A., Waas, F., Kersten, M., Florescu, D., Manolescu, I., Carey, M. e Busse, R.: The XML Benchmark Project. Technical Report INS-R0103, CWI, Amsterdam, The Netherlands, April 2001. 11. Shanmugasundaram, J., Tufte, K., He, G., Zhang, C., DeWitt, D. e Naughton, J.: Relational Databases for Querying XML Documents: Limitations and Opportunities. VLDB 1999, pp. 302314. 12. Tamino XML Server. http://www.softwareag.com/tamino/. 13. Tatarinov, I., Viglas, S., Beyer, K., Shanmugasundaram, J., Shekita, E. e Zhang, C.: Storing and Querying Ordered XML Using a Relational Database System. SIGMOD 2002. 14. Tian, F., DeWitt, D., Chen, J. e Zhang, C.: The Design and Performance Evaluation of Alternative XML Storage Strategies. SIGMOD Record 31(1) 2002. 15. W3C World Wide Web Consortium. http://www.w3.org. 16. W3C World Wide Web Consortium Document Object Model. http://www.w3.org/DOM. 17. W3C World Wide Web Consortium XML Query. http://www.w3.org/XML/Query. 18. W3C World Wide Web Consortium XSL Transformations. http://www.w3c.org/TR/xslt . 19. XML Query Language Demo. http://xmlqueryservices.com/.

238