Gerenciamento de Dados XML
Propaganda
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 semiestruturado, 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 semiestruturada 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 emails 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 round-tripping 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 ordem (1,N) Artigos nome autoria eMail (0,1) (1,N) (1,N) (1,1) (1,1) versão Autores (0,N) (1,N) (1,1) título Artigos (0,N) composição Seções Autores Seções (1,1) (1,1) (1,1) (1,1) (0,1) nome texto ordem 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 subelementos autor dentro do elemento artigo. Uma outra alternativa seria modela-lo 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 http://www.rpbourret.com/xml/XMLAndDatabases.htm. Último acesso: outubro de 2003. em: [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 http://www.w3c.org/Style/XSL. Último acesso em: outubro de 2003. (XSL). Disponível em:
