GerenciaDadosXML-MinicursoERI2003

Gerenciamento de Dados XML
Ronaldo dos Santos Mello
Departamento de Informática e Estatística (INE) – Centro Tecnológico (CTC) –
Universidade Federal de Santa Catarina (UFSC)
Campus Universitário Trindade - Caixa Postal 476 – 88040-900 – Florianópolis – SC.
[email protected]
Abstract. XML is a largely used standard for data representation and
exchange, specially by people and applications that work on the Web.
Considering the increasing need for defining, manipulating and storing XML
data, the database community is focusing its research efforts to the proposal of
solutions related to the management of XML data. This course aims at
reviewing the XML technology and discussing some XML data management
problems based on two points of view: a relational database that stores XML
documents and a native XML database.
Resumo. XML é um padrão cada vez mais utilizado para a representação e
intercâmbio de dados, especialmente entre pessoas e aplicações que utilizam a
Web. Considerando a crescente necessidade de definição, manipulação e
armazenamento de dados XML, a comunidade de banco de dados começa a
intensificar suas pesquisas no sentido de propor soluções relacionadas ao
gerenciamento de dados XML. Este mini-curso tem por objetivo revisar a
tecnologia XML e discutir problemas de gerenciamento de dados XML do
ponto de vista de um banco de dados relacional que mantém documentos XML
ou de um banco de dados XML nativo.
1. Introdução
XML é um formato padrão para transferência de dados entre computadores. Diversos
domínios de aplicação, como comércio eletrônico [CXM03,EBi03] e cadastro
bibliográfico [DBL03,SIG03], vêm definindo protocolos XML para os seus dados e
cada vez mais aplicações e pessoas disponibilizam e manipulam informações XML na
Web. O uso cada vez mais intensivo de XML vem despertando o interesse de diversas
áreas da ciência da computação, como linguagens de programação, engenharia de
software e bancos de dados, todas elas preocupadas com a definição de mecanismos
para o tratamento de dados neste formato.
Do ponto de vista da área de Banco de Dados (BD), um documento XML é uma
coleção de dados, da mesma forma que um BD. Porém, um documento XML tem a
vantagem de manter dados auto-descritivos e facilmente portáveis [BOU03]. A
tecnologia XML assemelha-se bastante com a tecnologia de Sistemas Gerenciadores de
BD (SGBDs), uma vez que possui um formato de armazenamento específico
(documento), permite a definição de esquemas, possui linguagens de consulta e define
interfaces (APIs) para o acesso a dados. Entretanto, a tecnologia XML não é equivalente
à tecnologia de SGBD, pois não existem soluções para todos os aspectos de
gerenciamento de dados, como controle de integridade, gerenciamento de transações,
indexação e consultas a múltiplos documentos.
Além disso, o formato de um dado XML é altamente irregular e muitas vezes
combina texto em linguagem natural com informações estruturadas. Assim sendo, BDs
tradicionais, como os BDs relacionais, são incapazes de armazenar diretamente
ocorrências de dados XML.
Toda esta problemática associada ao tratamento de dados XML vem estimulando
a comunidade científica de BD a estudar e desenvolver soluções para o gerenciamento
de dados XML persistentes. Neste contexto, duas frentes de pesquisa vêm se
consolidando: uma que procura estender a tecnologia de BDs relacionais para o suporte
a dados XML e outra que está investindo no desenvolvimento de BDs específicos para
dados XML, chamados BDs XML nativos. O foco principal deste mini-curso é, além de
apresentar a tecnologia XML, mostrar um panorama da problemática enfrentada por
estas duas frentes de pesquisa e algumas soluções já propostas.
O restante deste resumo estendido está organizado da seguinte forma: a seção
dois revisa a tecnologia XML: documentos XML, esquemas, linguagens de consulta e
de transformação de dados e interfaces de acesso. A seção três apresenta o estado da arte
em termos de pesquisa em gerenciamento de dados XML e a seção quatro é dedicada às
conclusões.
2. A Tecnologia XML
XML (eXtensible Markup Language) é uma meta-linguagem de marcação desenvolvida
pelo consórcio W3C (World Wide Web Consortium), sendo considerada um padrão para
a publicação e transferência de dados de diferentes domínios de aplicação na Web
[XML03,BRA02]. Sendo uma linguagem de marcação, XML utiliza delimitadores (ou
tags) para descrever dados, assim como a linguagem HTML. A diferença entre HTML e
XML é que tags em HTML descrevem instruções para apresentação de dados em
browsers Web, enquanto tags em XML denotam uma interpretação semântica para o
dado delimitado por ela. Como esta interpretação é particular para cada domínio de
aplicação, XML é dita uma meta-linguagem, pois cada aplicação tem a liberdade de
definir a sua própria linguagem de marcação de dados, descrevendo a nomenclatura e a
estruturação das tags que julgar apropriada.
Um conjunto de dados XML sempre é descrito em um documento XML. A
Figura 1 mostra um exemplo de um documento XML para o domínio de publicações de
artigos científicos.
Um dado XML é chamado de elemento, sendo o seu conteúdo delimitado por
uma tag inicial e uma tag final. O conteúdo de um elemento pode ser um conjunto de
elementos componentes (por exemplo, o elemento autor, composto de nome e
eMail), um texto de comprimento arbitrário (por exemplo, o elemento título) ou
um misto de texto e elementos componentes (por exemplo, o elemento seção). Um
elemento pode ter atributos, que descrevem algumas de suas propriedades na tag inicial
(por exemplo, o atributo versão do elemento artigo).
<?xml version =“1.0” encoding =“UTF-8” standalone =”yes”>
<publicacoes>
<artigo versao=“1”>
<titulo>XML</titulo>
<autor>
<nome>João da Silva</nome>
<eMail>[email protected]</eMail>
</autor>
<autor>
<nome>Maria Souza</nome>
</autor>
<secao nome=“Introducao”>XML foi ...
<subsecao>Linguagens de Marcacao</subsecao>
...
</secao>
...
</artigo>
...
</publicacoes>
Figura 1. Exemplo de um documento XML
Como pode ser visto na Figura 1, a organização dos dados em um documento
XML é hierárquica, existindo sempre um elemento raiz que é composto por um ou mais
elementos que podem, por sua vez, conter uma outra hierarquia de elementos. Um
documento XML é dito bem formado se contiver um elemento raiz e todos os seus
elementos possuírem uma tag inicial, uma tag final e atributos com conteúdo delimitado
por aspas simples (‘) ou duplas (“).
A tecnologia XML não se resume apenas ao formato de descrição de dados, mas
a todo um conjunto de especificações que possibilita o gerenciamento de dados XML.
As principais especificações são descritas a seguir.
2.1 DTD e XSD
A organização ou esquema dos elementos em um documento XML pode ser definida
basicamente de duas maneiras: através de um DTD (Document Type Definition) ou de
um XSD (XML Schema Definition) [XSC03]. Ambos especificam elementos válidos
que podem ocorrer em um documento, a ordem na qual eles ocorrem e algumas
restrições sobre a estrutura e o conteúdo destes elementos. Um documento XML é dito
válido se estiver de acordo com um esquema DTD ou XSD associado a ele.
DTD foi a primeira recomendação da W3C para a especificação de esquemas de
documentos XML. Um DTD é uma gramática formada basicamente por cláusulas
ELEMENT e ATTLIST. Estas cláusulas descrevem, respectivamente, um elemento e
uma lista de atributos de um elemento. A Figura 2 (a) mostra a DTD do documento
XML da Figura 1. Neste esquema, o elemento raiz publicações é composto por um ou
mais elementos do tipo artigo. Um elemento artigo possui um atributo versão e define
uma seqüência composta por um elemento título (com conteúdo textual - #PCDATA),
um ou mais elementos do tipo autor e zero ou mais elementos do tipo seção. Cada autor
possui um nome e um eMail opcional. Cada seção possui um atributo nome e define um
misto de texto e sub-elementos do tipo subseção.
<!ELEMENT publicacoes (artigo+)>
<!ELEMENT artigo (titulo, autor+,secao*)>
<!ATTLIST artigo versao CDATA>
<!ELEMENT titulo (#PCDATA)>
<!ELEMENT autor (nome, eMail?)>
<!ELEMENT nome (#PCDATA)>
<!ELEMENT eMail (#PCDATA)>
<!ELEMENT secao (#PCDATA | subsecao)*>
<!ATTLIST secao nome CDATA>
<!ELEMENT subsecao (#PCDATA)>
(a)
<?xml version =“1.0” encoding =“UTF-8” ?>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<element name=”publicacoes”>
<complexType>
<element ref=”artigo” maxOccurs=”unbounded”/>
</complexType>
</element>
<element name=”artigo”>
<complexType>
<sequence>
<element name=”titulo” type=”string”/>
<element ref=”autor” maxOccurs=”unbounded”/>
<element ref=”secao” maxOccurs=”unbounded”/>
</sequence>
<attribute name=”versao” type=”decimal”/>
</complexType>
</element>
<element name=”autor”/>
<complexType>
<sequence>
<element name=”nome” type=”string”/>
<element name=”eMail” type =”string” minOccurs=”0”/>
</sequence>
<attribute name=”versao” type=”decimal”/>
</complexType>
</element>
<element name=”secao”/>
<complexType mixed=”true”>
<element name=”subsecao” type =”string” minOccurs=”0”/>
<attribute name=”nome” type=”string”/>
</complexType>
</element>
</schema>
(b)
Figura 2. Exemplos de esquemas para documentos XML definidos através de
um DTD (a) e de um XSD (b)
XSD é uma recomendação recente da W3C e possui mais recursos para a
especificação de esquemas em relação a um DTD, como o suporte a tipos de dados, a
conceitos de orientação a objetos, como herança e polimorfismo, além de apresentar
uma sintaxe XML. A Figura 2 (b) descreve o esquema do documento XML da Figura 1
em XSD. Apesar de XSD ser mais expressivo que um DTD em termos de especificação
de esquemas XML, DTDs ainda são amplamente utilizados e a grande maioria das
ferramentas que realizam validação de documentos XML (chamadas parsers) operam
sobre DTDs.
2.2 XPath e XQuery
Consultas a dados de documentos XML são definidas através de duas linguagens: XPath
e XQuery. Ambas são capazes de percorrer documentos XML, definir predicados de
seleção e retornar dados no formato XML como resultado.
XPath foi a primeira recomendação da W3C para a consulta a dados XML
[XPA03]. Ela é uma linguagem para navegação na estrutura de um documento XML e
recuperação de fragmentos de documentos alcançados por uma expressão de navegação.
Sua sintaxe é semelhante à sintaxe para navegação em diretórios de arquivos Unix ou
DOS. A Figura 3(a) mostra três exemplos de expressões XPath executadas sobre o
documento XML da Figura 1. A consulta superior recupera títulos de artigos. A consulta
central ilustra a definição de um critério de seleção (delimitado por colchetes),
recuperando títulos de artigos da autora de nome Maria, enquanto a consulta inferior
busca atributos (indicados pelo caractere ‘@’) nome de todos os elementos que são
filhos imediatos (indicado pelo caractere ’*’) do elemento artigo cujo atributo
versão possui valor superior a 1.
/publicacoes/artigo/titulo
//artigo/autor[nome = ´Maria´]/titulo
//artigo[@versao > 1]/*/@nome
(a)
for $art in /publicacoes/artigo
let $v := $art/@versao * 10
where $art/autor/nome = “Maria”
return {$art/titulo, $v}
(b)
Figura 3. Exemplos de consultas em XPath (a) e XQuery (b)
Apesar de satisfazer a diversas intenções de consulta, a linguagem XPath
apresenta algumas limitações. Expressões XPath retornam somente porções de um
documento XML, sendo incapazes de produzir resultados de consultas com uma
estrutura diferente daquela existente no documento. Além disso, ela não é capaz de
realizar junções entre dados XML. A linguagem XQuery [XQU03], uma recomendação
mais recente da W3C, corrige estas deficiências da XPath.
XQuery é uma linguagem de consulta declarativa para dados XML. A estrutura
básica de um comando XQuery é mostrada na Figura 3(b), sendo composta pelo bloco
de instruções For-Let-Where-Return (expressão FLOWER). A consulta exemplo
busca títulos de artigos da autora Maria e o número da versão do artigo multiplicado por
10. Este exemplo ilustra a capacidade de XQuery de gerar estruturas de resultado
diferentes daquelas existentes no documento XML.
2.3 XSL
XSL (eXtensible Stylesheet Language) é uma recomendação da W3C para a
transformação e apresentação de dados XML [XSL03]. Através da XSL é possível
definir estilos particulares de visualização para XML, da mesma forma que a linguagem
HTML faz com dados a serem visualizados em browsers Web. Além disto, XSL tem a
capacidade de manipular dados de documentos XML, realizando, por exemplo, a
reorganização da estrutura hierárquica do documento (gerando um novo documento
XML) ou a transformação do documento em um outro formato de arquivo, como HTML
ou PDF.
Para a definição de uma formatação ou transformação de dados XML, um
documento XSL deve ser criado e um programa processador de instruções XSL deve ser
executado. Alguns browsers Web funcionam como processadores XSL, ou seja, são
capazes de analisar um documento XSL (referenciado por um documento XML) e exibir
os dados XML de acordo com as instruções definidas. A Figura 4 mostra um trecho de
um documento XSL.
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl
="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<head><title>Lista de Artigos</title></head>
<body>
</xsl:apply-templates/>
</body>
</html>
</xsl:template>
<xsl:template match="artigo/titulo">
<BR/>
<B>Título: </B>
<xsl:value-of select=""/><BR/>
</xsl:template>
...
Figura 4. Exemplo de um trecho de documento XSL
XSL utiliza uma sintaxe XML e suas principais instruções são baseadas em
reconhecimento de padrões existentes no documento XML (instrução template na
Figura 4) e sua posterior modificação para o formato de saída desejado (conjunto de
instruções dentro da instrução template ou dos dados de saída). A linguagem XPath é
utilizada para a definição do padrão a ser identificado (valor do atributo match da
instrução template), que geralmente corresponde a um nome de elemento ou atributo,
ou ainda a uma certa estrutura hierárquica presente no documento XML.
O documento XSL ilustrado na Figura 4 tem a intenção de gerar um arquivo
HTML a partir dos dados do documento XML da Figura 1 para fins de exibição em um
browser. Quando o elemento raiz do documento é identificado (padrão “/” na primeira
instrução template), um cabeçalho de arquivo HTML é gerado e o processamento de
transformação é recursivamente aplicado aos elementos restantes do documento XML
(instrução apply-templates). A segunda instrução template insere uma string
Titulo em negrito mais o valor de um título de artigo no arquivo de saída HTML, toda
vez que um título de artigo for encontrado no documento XML.
2.4 DOM
DOM (Document Object Model) [DOM03] é uma tecnologia que permite o
processamento de dados XML pelas aplicações. Ela disponibiliza uma API (Application
Program Interface) com métodos de acesso e manipulação de documentos XML.
Diversos parsers para validação de documentos XML suportam a API DOM. Alguns
browsers Web são capazes de processar instruções DOM definidas em scripts HTML.
DOM é um modelo de objetos que representa um documento XML através de
uma estrutura hierárquica em árvore. A API DOM fornece métodos para transformar o
documento em uma instância do modelo e manipular objetos documento, nodo da árvore
(atributos, elementos ou valores) e particularmente nodos elemento. A Figura 5 mostra
alguns métodos da interface DOM sendo ativadas, por exemplo, dentro de um programa
JavaScript. A interface para objetos documento permite, por exemplo, a busca do nodo
raiz do documento, através do método documentElement. Já a interface para objetos
nodo permite o acesso aos seus nodos filhos (método childNodes) em uma ordem
específica (método item(int)). Neste exemplo, atribui-se à variável artigo1 o
nodo que corresponde ao primeiro artigo do documento XML.
...
raiz = doc.documentElement;
artigo1 = raiz.childNodes.item(0);
...
Figura 5. Exemplos de métodos da API DOM
3. XML e Bancos de Dados
Aplicações desenvolvidas para a Web ou que utilizam a Web para a transferência de
dados utilizam amplamente protocolos XML. Quando dados XML necessitam ser
mantidos em um BD, existe a necessidade de se gerenciar adequadamente estes dados.
Novos desafios surgem em decorrência desta necessidade, uma vez que a tecnologia de
BD precisa ser adaptada para garantir o armazenamento e manipulação de dados XML
de forma eficiente.
Um documento XML pode ser considerado uma coleção de dados, da mesma
forma que um BD. Porém, um dado XML possui uma natureza diferente de um dado
convencional de um BD, uma vez que um dado de BD é um dado totalmente estruturado
enquanto que um dado XML é um dado semi-estruturado [ABI00]. Em um dado
tipicamente semi-estruturado, apenas parte de sua definição possui alguma estruturação
e cada ocorrência de um mesmo dado possui um esquema particular e auto-descritivo.
Desta forma, o esquema de representação destes dados é bastante irregular. Uma seção
de um artigo científico analisada por um revisor é um exemplo. Cada seção de um artigo
é basicamente um texto contínuo, podendo este texto conter subseções e parágrafos bem
delimitados. Além disso, comentários do revisor podem estar documentados em
qualquer ponto do texto da seção, com a indicação do problema encontrado e de uma
eventual sugestão de correção. A Figura 6 exemplifica este contexo, mostrando duas
ocorrências de dados do tipo seção com estruturas bastante distintas.
<seção> Esta é uma seção exemplo. Toda
<comentário><problema>Erro
concordância</problema><correção>Todas
</correção></comentário> as seções
contém texto.
<subseção><parag>
Este é o primeiro parágrafo da
primeira sub-seção.
</parag>...</subseção>
</seção>
<seção>
Esta é uma outra instância de seção,
formada apenas por um texto contínuo e
sem sub-elementos no seu interior.
</seção>
Figura 6. Exemplos de ocorrências de dados semi-estruturados
O fato de um dado XML ter uma organização mais ou menos semi-estruturada
define duas categorias de documentos XML [BOU03]:
 Documento XML Orientado a Dados (DOD): documento fracamente semiestruturado, ou seja, possui uma estrutura mais regular e repetitiva.
Documentos desta categoria são tipicamente usados para transferência de
dados convencionais entre aplicações. Notas fiscais e relatórios de clientes e
produtos são alguns exemplos;
 Documento XML Orientado a Documentos (DODoc): documento fortemente
semi-estruturado, ou seja, possui uma estrutura mais irregular e particular.
Documentos desta categoria são tipicamente usados para o relato da
linguagem natural, com destaque para alguns dados delimitados dentro do
seu conteúdo. Livros e anúncios classificados são alguns exemplos.
O modo como os dados XML são gerenciados está intimamente relacionada a
estas duas categorias de documentos. Aplicações que lidam com DODs geralmente
utilizam BDs relacionais, uma vez que os dados XML são fortemente estruturados. Já
aplicações que lidam com DODocs utilizam BDs específicos para o gerenciamento de
dados XML, chamados BDs XML nativos (ou simplesmente BDs XML). Estes BDs
utilizam mais efetivamente a tecnologia XML para a representação e o acesso a dados.
Estas duas alternativas para gerenciamento de dados XML são detalhadas a seguir.
3.1 Gerenciamento de Dados XML através de BDs Relacionais
SGBDs relacionais vêm sendo bastante utilizados para o armazenamento de dados XML
quando o foco da aplicação é nos dados propriamente ditos e não no formato XML de
organização hierárquica e ordenada de dados. Este é o caso, por exemplo, de aplicações
que fazem intercâmbio de dados estruturados (dados geralmente mantidos em arquivos
ou BDs) através da Web utilizando XML. Esta abordagem de gerenciamento tem a
vantagem de utilizar a tecnologia de BD, que apresenta bom desempenho de acesso a
dados e utiliza linguagens de consulta declarativas, para a manipulação de dados XML.
Por outro lado, os SGBDs relacionais devem se preocupar com a forma como dados de
documentos XML devem ser armazenados e com a definição de métodos de acesso
específicos para estes dados.
3.1.1 Armazenamento de Dados XML
O armazenamento de dados XML em um BD relacional exige a definição de um
mapeamento entre o esquema do documento XML e o esquema do BD. As seguintes
soluções são geralmente adotadas [GRA03]:
 Uso de aplicações middleware: o objetivo neste caso é transferir dados entre
BDs, ou seja, não há o armazenamento de novos documentos XML, mas sim o
armazenamento de dados de BD que foram mapeados para um formato XML.
Uma aplicação middleware gera um documento XML que corresponde
exatamente à estrutura do BD e o transfere para outro BD, onde o mapeamento
no sentido contrário ocorre. Um exemplo simples é a conversão de um BD
relacional para um formato XML, como mostra a Figura 7. Neste exemplo, o
documento XML tem como elemento raiz o próprio BD, que é formado por
elementos do tipo tabela. Cada elemento tabela, por sua vez, é composto de
elementos linhas que mantêm os conteúdos dos dados em cada coluna.
<BD>
<tabela nome=”tabela1”>
<linha>
<coluna1> ...</coluna1>
<coluna2> ...</coluna2>
...
</linha>
...
</tabela nome=”tabela2”>
...
</BD>
Figura 7. Representação de um esquema relacional no formato XML
 Suporte a dados XML pelo SGBD relacional: têm-se, neste caso, SGBDs que
sabem como converter documentos XML em esquemas relacionais e vice-versa.
Esta é a solução adotada por vários SGBDs e é discutida em mais detalhes na
seqüência. Grandes fabricantes de SGBDs relacionais, como Oracle e DB2, vêm
estendendo as funcionalidades dos seus sistemas para lidar com dados XML.
Dois enfoques para o mapeamento de dados XML para tabelas de um BD
relacional são propostos na literatura. Um deles, apresentado em [FLO99], vê um
documento XML como um grafo orientado rotulado cujas arestas são ordenadas e
representam relacionamentos hierárquicos entre elementos, entre elemento e atributo, ou
entre elemento/atributo e conteúdo. Diversas alternativas são propostas para o
armazenamento deste grafo em um BD relacional. As duas alternativas mais viáveis em
termos de desempenho são as seguintes:
 Alternativa 1: todas as arestas são mantidas em uma única tabela com colunas
que informam o nodo pai, o nome do rótulo, a ordem da aresta dentre todos os
nodos filhos e uma referência a um nodo filho e ao valor (se houver) do nodo
destino;
 Alternativa 2: arestas com o mesmo rótulo são mantidas em tabelas separadas,
equivalendo a uma tabela para cada tipo de elemento ou atributo. Colunas que
informam o nodo pai, a ordem da aresta e uma referência ao nodo (com um
possível valor) são necessárias.
A Figura 8 exemplifica o armazenamento do documento XML da Figura 1 nas
alternativas 1 (a) e 2 (b). Supõe-se que o nodo 1 representa o elemento raiz
(publicações), o nodo 2 representa a primeira ocorrência do elemento artigo, e assim
sucessivamente, conforme o nível dos nodos na árvore.
Arestas
origem
Artigos
ordem
nome
tipo
destino
valor
Origem
ordem
destino
1
1
artigo
ref
2
1
1
2
1
2
artigo
ref
3
1
2
20
origem
ordem
destino
valor
2
1
11
XML
3
1
23
BD e XML
...
...
2
1
versão
int
10
1
2
2
título
string
11
XML
Títulos
...
(a)
...
...
(b)
Figura 8. Exemplos de armazenamento de um documento XML em
um
relacional segundo a visão de [FLO99]: alternativa 1 (a) e alternativa 2 (b)
BD
A alternativa 1 exige mais de espaço de armazenamento que a alternativa 2 pois
necessita de uma coluna adicional para manter nomes de rótulos. No entanto, é a
alternativa mais rápida para processar consultas que navegam na estrutura de um
documento XML, pois não há a necessidade de junções entre tabelas, como no caso da
alternativa 2. O problema principal deste enfoque como um todo é o tempo para
reconstrução de um documento XML, pois ambas as alternativas fragmentam o
documento em arestas ou nodos, sendo necessária a investigação de muitas referências a
nodos para determinar a estrutura do documento. Além disso, são necessários dados
adicionais no esquema relacional que informem se um nodo é um elemento ou um
atributo.
Outro enfoque de armazenamento baseia-se em níveis de granularidade (ou de
detalhamento) que podem ser definidos para um documento XML [GRA03]. Em função
destes níveis, um esquema de armazenamento relacional é definido. Três níveis de
granularidade podem ser definidos:

Granularidade grande: define uma única tabela para armazenar todos os
documentos XML. As colunas desta tabela descrevem basicamente o
identificador do documento, seu nome e um campo longo para o seu
conteúdo. Este é o nível com menor detalhamento de dados XML;

Granularidade pequena: define uma tabela para cada tipo de elemento ou
atributo existente em um documento XML, exigindo colunas adicionais para
manter os relacionamentos hierárquicos entre elementos e a ordem de subelementos ou atributos de um elemento. Este é o nível de maior
detalhamento de dados XML;

Granularidade média: define um meio termo entre os níveis de
granularidade grande e pequena, ou seja, parte do esquema do documento é
definida de forma estruturada (em geral os elementos de nível superior no
documento) e parte é armazenada na forma de um campo longo. A decisão
pelos pontos exatos de divisão na árvore do documento depende basicamente
do nível de detalhe das consultas desejadas (e conseqüentemente, das
colunas que necessitam ser indexadas) e do tamanho de buffer para
transmissão de dados, que pode ser equivalente ao tamanho dos campos
longos.
Quanto maior o nível de granularidade, mais simples é a definição do esquema
relacional e menos detalhes do documento XML são passíveis de consulta. No nível de
granularidade grande não é possível definir consultas declarativas com base em valores
de elementos e atributos, por outro lado, não existe um custo associado à reconstrução
do documento XML. Estes prós e contras devem ser considerados quando do projeto do
BD relacional.
3.1.2 Acesso a Dados XML
O acesso a dados através de um SGBD deve considerar a estrutura lógica do modelo do
BD para a definição de expressões de consulta. No caso de um BD relacional, a
linguagem SQL é o protocolo padrão para acesso a tabelas. Caso um mapeamento de
granulação pequena (considerando também as alternativas de [FLO99]) ou média seja
adotado, atributos e elementos estão em tabelas e podem ser consultados via SQL.
Entretanto, extensões da SQL são propostas para lidar com consultas a esquemas
de mapeamento com granulação média ou grande, assim como para possibilitar visões
XML de resultados de consultas [BOU03]. Um exemplo para o primeiro caso é a
ferramenta XML Extender do SGBD DB2. No DB2 pode-se armazenar um documento
XML completo em um atributo do tipo XMLCLOB ou XMLVARCHAR de uma tabela.
A Figura 9 (a) ilustra a definição da tabela Artigos, que mantém um documento XML
sobre artigos científicos no atributo doc.
TABLE Artigos
SELECT código, nome
código VARCHAR(10) NOT NULL
PRIMARY KEY
FROM Artigos
WHERE extractVarchar (doc,
nome VARCHAR(40)
“/Publicacoes/artigo/titulo”) LIKE
doc
“%XML%”
XMLVARCHAR
(a)
(b)
Figura 9. Exemplo de definição de tabela no DB2 XML Extender para manter
documentos XML (a) e de uma consulta SQL estendida sobre os dados destes
documentos (b)
Para esquemas com granulação grande, índices sobre fragmentos de texto em
geral são definidos, permitindo buscas por palavras-chave em documentos XML. O
desempenho de acesso será bom se o BD implementar uma política de armazenamento
físico contíguo destes fragmentos.
Extensões da SQL para consultas a dados XML geralmente utilizam linguagens
de consulta XML para definir navegações na estrutura hierárquica de documentos. A
Figura 9 (b) mostra um exemplo de consulta na SQL do DB2. Esta consulta realiza uma
busca nos documentos XML (utilizando expressões XPath), recuperando nomes e
códigos de documentos cujo título contém a palavra XML.
A geração de resultados de consultas no formato XML é um requisito importante
para SGBDs que gerenciam dados XML. Esta facilidade é encontrada na linguagem
SQL/XML, um padrão ANSI ISO SQL que define extensões para o tratamento de dados
XML na SQL [SQX03].
A Figura 10 mostra uma consulta na SQL/XML que retorna uma visão XML
(um documento XML) sobre dados de tabelas chamadas Artigos e Autores. O
documento resultante conterá um conjunto de elementos Paper, sendo que cada
elemento possuirá um atributo Title e sub-elementos Conference e
Institution. SQL/XML é utilizada pelo SGBD Oracle.
SELECT XMLElement (“Paper”,
XMLAttributes (“Title”, Ar.Titulo),
XMLElement (“Conference”, Ar. Conferencia),
XMLElement (“Institution”, Au.Instituicao))
as xmldocument
FROM Artigos Ar, Autores Au
WHERE Ar.autor = Au.código
Figura 10. Exemplo de consulta em SQL/XML cujo resultado é um documento XML
Quanto à política de atualização de dados XML em BDs relacionais, em geral
um dado XML em um documento pode ser incluído, excluído ou modificado em um
esquema de mapeamento com granulação média ou pequena, desde que o documento
XML mantenha-se válido. No caso de um mapeamento com granulação grande, apenas
a inclusão ou exclusão de documentos XML é possível.
3.2 Gerenciamento de Dados XML através de BDs XML
Um BD XML é um BD que define um modelo lógico específico para documentos XML,
armazenando e recuperando dados de acordo com este modelo [BOU03,XML2-03,
XDB03]. Um modelo mínimo para dados XML deve conter a definição de elementos,
atributos e conteúdo textual (PCDATA); e manter a ordem dos dados no documento. Um
modelo completo deve ainda oferecer suporte à representação de conteúdo misto e
dados altamente semi-estruturados (com estruturas alternativas e repetitivas). Um BD
XML é recomendado para aplicações que lidam com DODocs (sua natureza fortemente
semi-estruturada torna complexo o mapeamento para um BD relacional), ou aplicações
que lidam somente com dados no formato XML.
A definição de BD XML não impõe nenhuma restrição sobre o modelo de
armazenamento físico a ser adotado. Assim sendo, um BD XML pode ser considerado
tanto um BD que é definido utilizando o suporte de um SGBD qualquer, como um BD
que define um formato proprietário de armazenamento XML (SGBD XML nativo). O
importante é que exista uma visão lógica de dados no formato XML.
3.2.1 Características de Gerenciamento de Dados
Apesar de alguns produtos de BDs XML disponíveis no mercado não serem totalmente
homogêneos em termos de gerenciamento de dados, algumas características já são
consideradas de consenso e, ou são encontradas atualmente nestes produtos, ou são
características que se desejam alcançar no futuro [XML2-03,BOU03]. Estas
características são apresentadas a seguir.
Coleções
Coleção é a noção lógica de um conjunto de documentos. Assemelha-se ao conceito
lógico de diretório em discos rígidos. Documentos com intenções semânticas
semelhantes podem ser mantidos em uma mesma coleção e assim o BD XML pode
manipular estes documentos de forma conjunta. Não há restrições quanto à estrutura de
um documento XML para pertencer a uma dada coleção, ou seja, uma coleção pode
armazenar qualquer documento XML, independente do mesmo ser válido ou não com
relação a um esquema XML. Este relaxamento estrutural permite uma maior
flexibilidade na inclusão de novos documentos no BD, porém incorre em um baixo
nível de integridade dos dados. Para minimizar esta desvantagem, alguns BD XML
permitem a vinculação de um esquema XML a uma coleção, de modo que todos os
documentos devam sofrer parsing para pertencerem à coleção.
Consultas
Pelo menos uma linguagem de consulta para XML deve ser suportada pelo BD. A mais
utilizada é XPath, porém, alguns BDs suportam também dialetos da XQuery e índices
definidos sobre dados em coleções de modo a oferecer um melhor desempenho e
expressividade nas consultas. Uma linguagem de consulta para BDs XML deve
possibilitar desde pesquisas por padrões em textos de documentos até consultas
declarativas (típicas de BDs relacionais) que retornem fragmentos de documentos e
possam gerar novas estruturas XML como resposta. Em função disto, aposta-se na
adoção de XQuery como um padrão a curto prazo para BDs XML.
Atualizações
A capacidade de realizar atualizações de dados em documentos XML ainda é restrita em
BDs XML. Alguns produtos não oferecem este suporte, exigindo que o usuário recupere
um documento XML, modifique-o e o grave novamente no BD. Outros oferecem uma
interface DOM para acesso e modificação do documento XML, enquanto uma terceira
categoria utiliza linguagens proprietárias de atualização de dados, como a XUpdate.
XUpdate é uma iniciativa da XML:DB, um consórcio de empresas responsáveis pelo
desenvolvimento de tecnologias para BDs XML [XDB03]. A linguagem permite a
inclusão e exclusão de elementos, atributos e texto, assim como a alteração de valores
de elementos e atributos. A figura 11 mostra exemplos de atualizações de dados XML
com XUpdate.
<xupdate:append
select=”//autor[nome=´Maria´]/eMail”
child=”last()”>
<xupdate:element name="eMail">
[email protected]
</xupdate:element>
</xupdate:append>
<xupdate:remove
select="/publicacoes/artigo[1]"/>
(b)
(a)
Figura 11. Exemplos de atualizações de dados XML com XUpdate: (a) inclusão e
(b) alteração de dados
Na Figura 11 (a) é incluído um elemento eMail como sub-elemento do
elemento autor de nome Maria. Este novo e-mail é colocado como último elemento
na lista de e-mails de Maria. Na Figura 11 (b), o primeiro elemento artigo do
documento XML é removido.
Apesar de existirem algumas soluções para a atualização de dados, como a
XUpdate, entende-se que estas serão apenas soluções temporárias enquanto não existir
uma linguagem declarativa padrão para a manipulação de dados XML, muito
possivelmente uma extensão de XQuery.
Gerenciamento de Transações
BDs XML suportam controle de concorrência e rollback de transações em caso de
falhas. Bloqueios ocorrem geralmente no nível do documento completo, apesar dos
modelos lógicos de dados XML permitirem o detalhamento de fragmentos de um
documento (elementos e atributos). Isto acarreta um baixo nível de concorrência no
acesso a dados. No futuro, espera-se que bloqueios a nível de fragmentos, ou seja,
bloqueios com granularidade mais fina, sejam permitidos.
APIs
BDs XML oferecem recursos básicos para a comunicação entre aplicações e o BD,
baseados geralmente em interfaces ODBC: métodos para conexão com o BD, execução
de consultas e exploração de resultados. Resultados de consultas são usualmente
retornados na forma de strings XML ou árvores DOM. Caso múltiplos documentos
sejam retornados, métodos específicos para iteração sobre o conjunto resultante são
ativados (semelhante à noção de cursores em BDs relacionais). Adicionalmente, alguns
BDs podem ser acessados através de browsers Web via protocolo HTTP. Uma tendência
em termos de padrão é a API para BDs XML proposta pelo consórcio XML:DB
[XDB03].
Round-Tripping
Round-Tripping é a capacidade de armazenar um documento XML em um BD XML e
obter o documento de volta com o seu conteúdo na íntegra, ou seja, na seqüência textual
estrita em que foi definido. Tal capacidade é particularmente importante para DCDocs,
que possuem estruturas mais irregulares, ricas em seqüências de textos narrativos que
devem ser respeitadas. Na sua totalidade, BDs XML são capazes de realizar roundtripping de documentos XML a nível de elementos, atributos e conteúdos PCDATA. Já
no que diz respeito a DCDocs, a precisão do round-tripping varia de BD para BD e está
intimamente associada ao nível de detalhamento do modelo lógico para o qual o
documento XML é mapeado. Quanto mais sucinto for este modelo, menor será a
precisão do round-tripping.
Armazenamento de Entidades Externas
Um aspecto de gerenciamento particular a dados XML é o tratamento de referências a
entidades externas presentes em documentos XML. A questão é: (i) deve-se buscar os
valores destas entidades e armazená-las no BD ou (ii) manter apenas as referências a
elas? Este aspecto não é em geral considerado pelos BDs XML, porém, idealmente,
ambas as alternativas deveriam ser suportadas, dependendo da intenção da aplicação e
do conteúdo da referência. A alternativa (i) é relevante quando os dados referenciados
complementam os dados presentes no documento XML. Já a alternativa (ii) pode ser
considerada, por exemplo, para casos em que uma referência indica um programa (em
CGI, por exemplo) que faz algum processamento com os dados do documento.
Redundância de Dados
No projeto de um BD relacional, o objetivo de um processo de normalização é evitar a
redundância de dados nas tabelas do esquema do BD. Redundância de dados ocorre com
freqüência em documentos XML, uma vez que um mesmo sub-elemento pode ocorrer
várias vezes como filho de elementos diferentes. Apesar disto, nem sempre é desejado o
armazenamento separado e não-redundante de sub-elementos por questões de
desempenho, principalmente quando se trata da recuperação completa de um documento
XML. Um armazenamento extremamente fragmentado do documento exigiria muitas
junções para recriar o documento completo. Em geral, a aplicação da teoria da
normalização é relaxada nos BDs XML em detrimento de um melhor desempenho de
acesso.
Integridade Referencial
A integridade referencial em um BD relacional refere-se ao controle de referências
válidas através de chaves estrangeiras. No caso de um BD XML, referências entre dados
XML também são possíveis, seja através de atributos ID/IDREF(S) ou key/keyref
(permitem referências entre elementos dentro de um mesmo documento); ou através de
links internos ou externos ao documento. O controle de integridade referencial neste
contexto é bem mais complexo, pois referências externas podem indicar qualquer
documento XML presente no BD ou mesmo na Web! Devido a alta complexidade para
realizar este gerenciamento, BDs XML se limitam ao controle de integridade referencial
apenas a nível interno do documento ou, no máximo, entre documentos mantidos dentro
de um mesmo BD.
Restrições Gerais de Integridade
O controle de integridade semântica em BDs relacionais é amplo e considera não apenas
restrições a nível de tipo de dado de um atributo, mas também a nível de valores
permitidos para um atributo e transições de valor válidas. Tais controles são possíveis
através de diversos recursos da SQL, como gatilhos (triggers), a cláusula check e
procedimentos armazenados (stored procedures). No que se refere a BDs XML,
recursos semelhantes em geral não existem, limitando bastante o nível de integridade
dos dados. Apenas controles básicos em geral são suportados, como o tipo de dado
associado ao conteúdo de um elemento ou atributo, valores default ou enumeração de
valores permitidos. Esta limitação em termos de integridade está também associada à
inexistência de um padrão da W3C para especificação de restrições de integridade em
esquemas XML. Mesmo assim, espera-se futuramente que um controle de integridade
mais robusto esteja disponível em BDs XML.
3.2.2 Projeto de um BD XML
O projeto tradicional de BD é composto de quatro etapas: (i) coleta de requisitos de
dados do domínio da aplicação; (ii) modelagem conceitual do domínio; (iii)
mapeamento do esquema conceitual para o esquema lógico do BD; e (iv) implementação
do esquema lógico no SGBD escolhido. Esta metodologia de projeto pode ser aplicada a
um BD XML toda vez que uma aplicação deseja manipular dados persistentes no
formato XML. Esta metodologia é particularmente relevante para aplicações que lidam
com DODs, cujos esquemas são mais estruturados.
Uma alternativa para a realização do projeto de um BD XML é utilizar um
modelo conceitual tradicional de BD (como o modelo Entidade-Relacionamento
[BAT92]) na etapa (ii) e realizar a conversão do esquema conceitual para um esquema
lógico na forma de grafo orientado, que é mais adequado ao formato de um esquema
lógico para XML. A Figura 12 ilustra um exemplo de projeto para o domínio de
publicações de artigos científicos: modelagem ER (a); modelagem lógica na forma de
grafo (b); e o esquema XML final (c).
Publicações
versão
título
(1,N)
Artigos
nome
ordem
autoria
eMail (0,1)
(1,N)
(1,N)
versão
Autores
(1,1)
(1,1)
Artigos
(0,N)
(1,N)
(1,1)
composição
título
(0,N)
Seções
Autores
nome texto
ordem
Seções
(1,1)
(1,1)
(1,1)
(1,1)
(0,1)
nome
texto
eMail
(a)
(b)
<!ELEMENT publicacoes (artigo+)>
<!ELEMENT artigo (autor+, secao*)>
<!ATTLIST artigo titulo CDATA REQUIRED versao CDATA REQUIRED>
<!ELEMENT autor EMPTY>
<!ATTLIST autor nome CDATA REQUIRED eMail CDATA>
<!ELEMENT secao (#PCDATA)>
<!ATTLIST secao nome CDATA REQUIRED>
(c)
Figura 12. Exemplo de projeto de um BD XML: modelagem conceitual (a),
modelagem lógica (b) e esquema XML correspondente (c)
O mapeamento conceituallógico deve levar em conta algumas particularidades
da modelagem de dados XML:

definição do nodo raiz: este nodo serve apenas para conter o conjunto de
dados XML e geralmente não tem relevância do ponto de vista da
semântica da aplicação. Ele pode ter relação com a entidade central da
modelagem (por exemplo, artigo), – neste caso, ele poderia se chamar
artigos – ou corresponder a intenção do domínio como um todo (que é
publicação de artigos científicos), chamando-se assim publicações;

indicação de nodos léxicos e não-léxicos e seus relacionamentos: nodos
léxicos são nodos que modelam conteúdos de dados, correspondendo a
atributos de entidades no nível conceitual. Eles são indicados por círculos
tracejados. Nodos não-léxicos representam entidades e são indicados por
círculos contínuos (ver Figura 12(b)). As arestas entre nodos representam
relacionamentos entre entidades e possuem rótulos que indicam as
restrições de cardinalidade. A orientação das arestas deve levar em conta
a hierarquia desejada para os futuros dados XML. Deve-se eleger um
nodo não-léxico central (corresponde à entidade central da modelagem –
no caso, artigo) e partir dele definir o restante das orientações
hierárquicas. Este nodo central será filho do nodo raiz.
A etapa final do projeto realiza o mapeamento do esquema lógico para um
esquema DTD ou XSD. Neste processo, duas abordagens podem ser seguidas:

abordagem orientada a atributos: define nodos léxicos como atributos
de elementos. A principal vantagem desta abordagem é a economia de
espaço do documento XML, pois as tags de elementos PCDATA ocupam
muito espaço. Esta abordagem é predominantemente utilizada no
exemplo da Figura 12 (ver Figura 12(c)). Além disso, algumas restrições
de integridade, como valor default e enumeração de valores permitidos
só podem ser definidos sobre atributos XML;

abordagem orientada a elementos: define nodos léxicos como elementos
PCDATA. Esta abordagem é recomendada para conteúdos de dados
extensos (como o texto de uma seção) e deve ser utilizada para
representar elementos mistos (nestes casos, o conteúdo textual do
elemento deve ser um componente PCDATA e não um atributo).
Vale ressaltar ainda que o mapeamento do nodo léxico ordem (indica a ordem
dos autores do artigo) foi substituído no esquema XML pela ordem hierárquica implícita
dos sub-elementos autor dentro do elemento artigo. Uma outra alternativa seria modelalo como um atributo ou sub-elemento PCDATA do elemento autor.
3.2.3 Exemplo de BD XML: Tamino
O SGBD Tamino foi o primeiro servidor de BD para dados XML. Ele começou a ser
desenvolvido pela empresa Software AG no final da década de 90 e é considerado o BD
XML mais maduro existente no mercado, sendo comercializado atualmente na versão
4.1.4 [TAM03].
Tamino permite o armazenamento e a manipulação de documentos XML no
formato nativo ou no formato relacional. No formato nativo, é possível armazenar
documentos que tenham ou não um esquema XML associado. Ele suporta a definição de
coleções, sendo que cada coleção pode estar associada a um esquema XML para fins de
validação de documentos. Tamino define esquemas XML em um formato proprietário,
porém este formato pode ser convertido para XSD. Elementos ou atributos de um
esquema podem ser indexados e existe o suporte de tipos de dados para elementos com
conteúdo ou atributos.
Tamino também gerencia dados relacionais, permitindo a definição de esquemas
de mapeamento de dados XML para tabelas e vice-versa. Através destes esquemas é
possível realizar junções entre dados de documentos diferentes. Consultas a dados
relacionais são formuladas via SQL, enquanto que consultas a dados XML podem ser
formuladas através de linguagens que são extensões das linguagens XPath ou XQuery.
Buscas por padrões em documentos completos também são possíveis. A linguagem
XQuery do Tamino possibilita a atualização de dados de documentos.
Diversos controles funcionais de um SGBD são encontrados no Tamino:
gerenciamento de transações (controle de concorrência e rollback), níveis de autorização
de acesso, processamento otimizado de consultas e ferramentas para administração de
BD. Em termos de acesso, basicamente existem APIs DOM para Java, Jscript e
ActiveX, APIs para acesso SQL através de ODBC e JDBC ou ainda embutimento na
linguagem C. Tamino pode ser acessado diretamente através de um browser Web, via
protocolo HTTP.
4. Conclusão
O amplo uso de XML como um formato de representação e transferência de dados entre
computadores justifica as pesquisas atuais da comunidade de banco de dados nesta área.
O gerenciamento de dados XML vem sendo realizado basicamente de duas maneiras:
através de mecanismos implementados em SGBDs existentes no mercado ou através do
desenvolvimento de SGBDs XML nativos. Neste contexto, uma questão a levantar é por
que investir no desenvolvimento de BDs XML nativos se já existe a tecnologia de
SGBDs e esta tecnologia está oferecendo soluções para o suporte a dados XML. Alguns
argumentos a favor de BDs XML nativos são os seguintes:

Dados XML, principalmente dados presentes em DODocs, apresentam
estruturas muito irregulares, tornando complexo o armazenamento e o
gerenciamento através de um BD relacional, por exemplo. Um BD XML
nativo já é projetado para lidar com dados semi-estruturados de forma
eficiente;

Certas aplicações para a Web (no domínio de comércio eletrônico, por
exemplo) podem ter regras de negócio que ainda não estão totalmente
definidas, gerando freqüentemente páginas dinâmicas conforme a
natureza da negociação feita com o cliente. Tais aplicações podem não
querer investir no projeto de um BD com estrutura mais estática,
preferindo armazenar as transações personalizadas de negócio em
documentos XML com formatações mais flexíveis;

O custo da extensão de um BD convencional para permitir o suporte a
dados XML tende a ser maior do que o custo para desenvolver um BD
XML nativo, considerando as diversas ferramentas já existentes para a
tecnologia XML (processadores XPath e XSL, parsers para DTD e para
DOM, etc). Este fator custo pode fazer a diferença no momento em que
um cliente que deseja adquirir um BD com suporte para XML;

Aplicações que manipulam dados exclusivamente no formato XML
podem não ter interesse em adquirir, por exemplo, um BD relacional com
suporte a XML e ter que lidar com um modelo e uma linguagem de
manipulação que não são adequados a dados XML. Um BD relacional,
por exemplo, pode não ser capaz de recuperar a estrutura física completa
de um documento e executar consultas e transações sobre um documento
como um todo;
O quão relevantes são estas argumentações depende muito das necessidades de
cada aplicação e é necessário mais tempo para avaliar se os BDs XML irão conquistar
ou não uma fatia no mercado de produtos de BD (uma lista de SGBDs para XML pode
ser encontrada em [BOU03]). Independente disto, os BDs XML não têm a intenção de
marcar histórica como uma nova geração de SGBDs, uma vez que BDs relacionais
continuam sendo adequados a aplicações que lidam com dados estruturados.
Referências
[ABI00] ABITEBOUL, S., BUNEMAN, P., SUCIU, D. Data on the Web: From Relations to
Semistructured Data and XML. Morgan Kaufmann, 2000.
[BAT92] BATINI, C., CERI, S., NAVATHE, S.B. Conceptual Database Design: An Entity-Relationship
Approach. Benjamin/Cummings Publishing Company, 1992.
[BOU03]
BOURRET,
R.
XML
and
Databases.
Disponível
em:
http://www.rpbourret.com/xml/XMLAndDatabases.htm. Último acesso: outubro de 2003.
[BRA02] BRADLEY, N. The XML Companion. 3a ed. Addison-Wesley, 2002.
[CXM03] CXML.org. Disponível em: http://www.cxml.org. Último acesso: outubro de 2003.
[DBL03] DBLP Bibliography. Disponível em: http://www.informatik.uni-trier.de/ley/db. Último acesso:
outubro de 2003.
[DOM03] W3C DOCUMENT OBJECT MODEL. Disponível em: http://www.w3c.org/DOM. Último
acesso em: outubro de 2003.
[EBi03] EBisXML. Disponível em: http://www.basda.org. Último acesso: outubro de 2003.
[FLO99] FLORESCU, D., KOSSMANN, D. Storing and Querying XML Data Using an RDMBS. IEEE
Data Engineering Bulletin, 22(3), p.27-34, 1999.
[GRA03] GRAVES, M. Projeto de Banco de Dados com XML. Makron Books, 2003.
[SQX03] SQL/XML. Disponível em: http://otn.oracle.com/tech/xml/xmldb/htdocs/sql_xml.html. Último
acesso em: outubro de 2003.
[TAM03] TAMINO XML SERVER. Disponível em: http://www.softwareag.com/tamino. Último acesso
em: outubro de 2003.
[XDB03] XML:DB INITIATIVE: ENTERPRISE TECHNOLOGIES FOR XML DATABASES.
Disponível em: http://www.xmldb.org. Último acesso em: outubro de 2003.
[XML03] eXtensible Markup Language. Disponível em: http://www.w3c.org/xml. Último acesso em:
outubro de 2003.
[XML2-03] XML.COM: INTRODUCTION TO NATIVE XML DATABASES. Disponível em:
http://www.xml.com/lpt/a/2001/10/31/nativexmldb.html. Último acesso em: outubro de 2003.
[XPA03] XML PATH LANGUAGE (XPATH). Disponível em: http://www.w3c.org/TR/xpath. Último
acesso em: outubro de 2003.
[XQU03] W3C XML QUERY. Disponível em: http://www.w3c.org/xml/Query. Último acesso em:
outubro de 2003.
[XSC03] W3C XML SCHEMA. Disponível em: http://www.w3c.org/xml/Schema. Último acesso em:
outubro de 2003.
[XSL03] THE EXTENSIBLE STYLESHEET LANGUAGE FAMILY (XSL). Disponível em:
http://www.w3c.org/Style/XSL. Último acesso em: outubro de 2003.