A Linguagem XML numa Perspectiva de Bases de Dados

(1)

A Linguagem XML numa Perspectiva de Bases de Dados

Artur Afonso de Sousa

Escola Superior de Tecnologia de Viseu, Departamento de Informática, Viseu, Portugal ajas@di.estv.ipv.pt

José Luís Pereira

Universidade do Minho, Departamento de Sistemas de Informação, Guimarães, Portugal jlmp@dsi.uminho.pt

João Álvaro Carvalho

Universidade do Minho, Departamento de Sistemas de Informação, Guimarães, Portugal jac@dsi.uminho.pt

Resumo

A linguagem XML (eXtensible Markup Language), proposta pelo W3C (World

Wide Web Consortium) como o novo standard para a representação e permuta

de dados na Internet, é uma (meta)linguagem de marcação de documentos adequada aos requisitos da WWW (World Wide Web).

Neste artigo pretende-se analisar as potencialidades da linguagem XML, não apenas como meio para a representação e troca de documentos na WWW, mas também como linguagem para a definição e manipulação de dados, assim como para a interligação de sistemas heterogéneos.

Palavras chave: XML, Bases de Dados, Dados semi-estruturados

1. Introdução

A linguagem XML (eXtensible Markup Language) é o novo standard que o W3C (World Wide

Web Consortium) propõe, com vista à representação e permuta de dados na WWW. Trata-se de

uma (meta)linguagem de marcação de documentos, simultaneamente simples e versátil, cujo potencial de aplicação se tem vindo a reconhecer noutras áreas, como por exemplo, no armazenamento e estruturação de dados e na interligação de bases de dados heterogéneas. De facto, tem-se sentido um interesse cada vez maior na linguagem XML, por parte da comunidade científica interessada na área das bases de dados. O trabalho recentemente realizado por esta última no âmbito dos modelos de dados semi-estruturados, como se verá mais à frente, é um exemplo muito relevante da aproximação entre as duas áreas científicas.

Neste artigo, pretende-se analisar os mais recentes desenvolvimentos que têm sido levados a cabo sobre a linguagem XML, fazendo um levantamento das suas principais limitações relativamente à definição e manipulação de dados, assim como as linhas de desenvolvimento actuais no sentido de se ultrapassarem essas limitações. Nesse sentido, será inicialmente descrito o papel da XML como uma (meta)linguagem de marcação de documentos para, de seguida, se analisar as suas potencialidades no suporte à definição e manipulação de dados. Relativamente à estruturação do artigo: Na secção 2 analisa-se com alguma profundidade a XML e as especificações/tecnologias que lhe estão associadas na perspectiva da marcação de documentos. Na secção 3 analisam-se as características e limitações da linguagem XML relativamente à definição e manipulação de dados. No seguimento, apresenta-se na secção 4 um

(2)

resumo de algumas das linguagens de interrogação actualmente existentes para a XML. As conclusões estão contidas na secção 5.

2. A Linguagem XML

A história da linguagem XML [Bray et al. 1998] está intimamente ligada à evolução da World Wide Web. É por todos reconhecido que a larga aceitação de que a WWW hoje desfruta se deve, em grande parte, à “invenção” da linguagem HTML (HyperText Markup Language), em 1992, por Tim Berners-Lee. Numa primeira fase, o seu principal objectivo foi a disseminação de documentos na Internet. Todavia, devido aos rápidos avanços tecnológicos e aos novos requisitos da WWW, a HTML apresenta, actualmente, algumas limitações importantes, das quais se destacam:

• A HTML não é extensível. Disponibiliza apenas um conjunto de etiquetas (marcas) predefinidas, não permitindo, assim, contemplar requisitos mais específicos, com necessidade de recorrer a novas etiquetas.

• As etiquetas da HTML apesar de fornecerem indicações sobre a posição e a

apresentação dos dados, não disponibilizam qualquer informação sobre o significado dos dados.

Por seu lado, a SGML (Standard Generalized Markup Language), criada em 1986, é uma metalinguagem (na qual a HTML foi baseada) utilizada para definir regras que especifiquem a estrutura e o conteúdo de diferentes tipos de documentos electrónicos. Apesar de a SGML ser extremamente versátil, é, contudo, muito complexa (só a sua especificação compreende cerca de 500 páginas).

Uma vez que a SGML é demasiado complexa e que a HTML apresenta algumas limitações, a solução encontrada pelo W3C foi a criação de um novo standard em 1998 – a XML – que é um subconjunto da SGML, ou seja, é uma versão simplificada da SGML, especialmente projectada para os requisitos da WWW.

2.1 O que é a XML?

A XML é uma (meta)linguagem de marcação de documentos, completamente independente das plataformas H/W e S/W que a utilizam. É, portanto, um padrão aberto, que fornece um conjunto de regras para descrever o conteúdo dos documentos, assim como a sua estrutura lógica, de modo a que estes possam ser interpretados e/ou manipulados, quer pelos utilizadores, quer pelas aplicações.

Um dos principais objectivos da XML é providenciar muitos dos benefícios da SGML, que não estão disponíveis na HTML, numa linguagem que seja fácil de apreender e de utilizar. Estes benefícios incluem, entre outros, a utilização arbitrária de etiquetas de marcação (TAGs) e de atributos nos documentos, o suporte de documentos com estruturas aleatoriamente complexas, assim como a possibilidade de validação da estrutura do documento, no que diz respeito à utilização opcional de uma gramática chamada definição de tipos do documento (Document

Type Definition - DTD).

As ideias base subjacentes à XML são muito simples: as etiquetas, para além de fornecerem indicações sobre a estrutura lógica do documento, identificam também o conteúdo dos dados, em vez de, por exemplo, especificarem o modo como estes devem ser apresentados (como acontece na HTML). O conteúdo é, portanto, separado da apresentação, tornando fácil a obtenção de múltiplas perspectivas sobre os mesmos dados. Os relacionamentos entre os dados são estabelecidos através de simples referências ou por aninhamento de etiquetas.

Considere-se, a título de exemplo, o código, que representa um pequeno documento XML contendo dados bibliográficos (ver Figura 1). Como se pode verificar, os dados num documento

(3)

XML estão agrupados em elementos delimitados por etiquetas de marcação, podendo estes, por sua vez, estar aninhados dentro de outros elementos. O fragmento de dados que surge entre estas etiquetas representa o conteúdo do elemento. Cada elemento tem um tipo, identificado pelo nome da etiqueta que lhe está associada, algumas vezes também chamado o seu “identificador genérico”, e pode ter associada uma especificação de um conjunto de atributos. Cada especificação de um atributo tem um nome e um valor.

Assim, os principais blocos de construção de estruturas hierárquicas, nos documentos XML, são os elementos. Os elementos, na XML, podem conter texto, outros elementos, ou ambos, ou ainda, estarem simplesmente vazios. Além disso, os elementos, na XML, também podem ter atributos associados, para adicionar (meta)informação. As especificações dos atributos só podem aparecer dentro das etiquetas de início de marcação e das etiquetas de elementos vazios.

Figura 1 - Exemplo de um documento XML.

A XML permite associar identificadores únicos aos elementos, através da utilização de um tipo especial de atributo, ID. Por exemplo, na Figura 1, o elemento <livro> tem associado, para esse efeito, o atributo “ISBN” (ver também a Figura 2). Também é possível referenciar um determinado elemento, utilizando um tipo especial de atributo, IDREF(S). Por exemplo, na Figura 1, o atributo “referencia” (associado ao elemento <artigo>) serve para referenciar o elemento <livro>, cujo atributo do tipo ID tem o valor “_972-722-193-9” (ver também a Figura 2). A utilização destes tipos especiais de atributos permite a construção de estruturas de dados complexas, representadas por grafos e, circunstancialmente, cíclicas/recursivas.

Parece, pois, evidente, que o código XML, apesar de ser eventualmente mais verboso (do que o equivalente HTML), estrutura os dados num formato muito mais conveniente e utilizável, do ponto de vista da gestão de dados. Tanto a HTML como a XML oferecem um método universal para a representação de documentos, mas com uma diferença fundamental: a primeira serve

<?xml version="1.0" encoding="windows-1252”?> <bdbib>

<livro ISBN = “_972-722-143-2”> <autor> José Luís Pereira </autor>

<título> Tecnologia de Bases de Dados </título> <editora>

<nome> FCA </nome> <sede> Lisboa </sede> </editora>

<livro ISBN = “_972-722-193-9”> <autor> Luís Amaral </autor> <autor> João Varajão </autor>

<título> Planeamento de Sistemas de Informação </título> <editora>

<nome> FCA </nome> <sede> Lisboa </sede> </editora>

<artigo classificação = “KM” referencia = “_972-722-193-9”> <autor> João Álvaro Carvalho </autor>

<título> Knowledge Needs of Self-Organized Systems </título> <ano> 2000 </ano>

</artigo> </bdbib>

(4)

essencialmente para estruturar e apresentar os dados num determinado formato, enquanto que a segunda procede à respectiva descrição.

Uma das características mais atractivas da XML é que é possível criar etiquetas para descrever e estruturar os dados relativos a uma determinada situação. Ou seja, eliminam-se as restrições da HTML, que apenas permitia a utilização de um conjunto de etiquetas predefinidas. Esta característica de extensibilidade torna a linguagem XML versátil e completa em termos de modelação, já que permite adequá-la a qualquer situação. A única restrição que existe é que as etiquetas têm que emparelhar. Por exemplo, a etiqueta <livro> tem que ter outra correspondente </livro>. Outra característica interessante é o facto de se poderem aninhar as etiquetas até um nível arbitrário. Para concluir esta breve comparação entre a XML e a HTML, registe-se ainda que um documento XML pode conter uma gramática opcional (DTD), para as aplicações utilizarem, sempre que necessitarem de realizar validações estruturais.

2.1.1 Definição de Tipos do Documento (Document Type Definition – DTD)

A um documento XML pode, opcionalmente, estar associado um conjunto de regras que especificam restrições na sua estrutura lógica chamado definição de tipos do documento (Document Type Definition - DTD), e que serve como uma gramática para o documento XML que lhe está subjacente.

Uma declaração de tipos do documento (Document Type Declaration) permite declarar quais os elementos constituintes do documento, qual a ordem que devem ter, e que outros elementos podem conter, para além de outras regras. Entretanto, é de salientar queo facto de ambos os conceitos (definição de tipos do documento e declaração de tipos do documento) serem expressos, normalmente, na literatura, pela mesma sigla (DTD), torna-se, geralmente, uma fonte de confusão.

Assim, a declaração de tipos do documento é onde estão declarados os elementos, atributos, tipos, entidades, etc. A definição de tipos do documento (DTD) é o nome dado à gramática geral, que engloba o conjunto de todas as declarações. Uma declaração de tipos do documento pode fazer parte do próprio documento XML, ou pode estar noutro ficheiro. Contudo, é necessário ter a noção de que os documentos XML podem existir sem quaisquer declarações de tipos do documento.

Nas declarações de tipos do documento também é possível declarar os atributos e os respectivos tipos (CDATA, ID, IDREF, IDREFS, etc). O tipo CDATA significa que o valor do atributo é uma cadeia de caracteres; o tipo ID declara que o atributo define um identificador único (do elemento associado); o tipo IDREF significa que o valor do atributo é um identificador de outro elemento; o tipo IDREFS significa que o valor do atributo é uma lista de identificadores, separados por espaços. Os valores dos atributos ID têm que ser distintos e todas as referências do tipo IDREF e IDREFS têm que ser para identificadores existentes no documento. Note-se que os atributos estão sempre associados a elementos.

De um modo simplista, um documento XML é bem formatado se a sua estrutura está correcta, isto é, os elementos estão devidamente aninhados. Por outro lado, um documento XML é válido se tiver uma declaração de tipos do documento associada e se estiver de acordo com as restrições expressas por essa declaração de tipos do documento. Como é evidente, um documento XML válido é necessariamente um documento bem formatado. De seguida, apresenta-se a declaração de tipos do documento relativos ao documento XML da Figura 1.

(5)

Figura 2 - Declaração de tipos do documento para o documento XML da Figura 1.

A segunda linha da Figura 2 indica que o elemento “bdbib” pode conter vários elementos “livro” ou “artigo”, sem qualquer ordem específica. A quarta linha especifica que o elemento “livro” tem associado um atributo “ISBN” do tipo ID. A quinta linha indica que o elemento “artigo” pode conter vários elementos “autor”, exactamente um elemento “título” e, opcionalmente, um elemento “ano”. “#PCDATA” significa “Parsed Character DATA”. Os elementos deste tipo contêm, como valores, cadeias de caracteres.

Como se pode verificar, numa declaração de tipos do documento pode ser utilizado um conjunto de operadores de expressões regulares, de modo a permitir uma maior flexibilidade nas restrições impostas. Assim, o símbolo “*” significa qualquer número de ocorrências; o símbolo “+” significa uma ou mais ocorrências; o símbolo “?” significa zero ou uma ocorrência (equivalente a opcional); o símbolo “|” significa alternância; o símbolo “,” significa concatenação (sequência).

2.1.2 Algumas Especificações Associadas à XML

Uma vez que nos documentos XML as etiquetas de marcação não especificam o modo de apresentação do documento (isto é, o conteúdo está separado da sua apresentação), torna-se necessário recorrer a uma outra linguagem, a XSL (eXtensible Stylesheet Language) [Adler et al. 2000], para apresentar os dados ao utilizador final. A XSL é uma linguagem para especificação de folhas de estilo, e é constituída por duas partes:

• Uma linguagem para transformar os documentos XML;

• Um vocabulário XML para especificar a sua formatação.

As folhas de estilo XSL são associadas aos documentos XML através da inclusão de uma, ou mais, instruções de processamento no início do documento XML.

Uma das vantagens da XSL é que, para além de possibilitar a criação de diferentes formatos de apresentação para o mesmo documento XML, pode também ser utilizada como uma linguagem de transformação de documentos XML. Isto é, através da XSL, é possível transformar um documento XML num outro completamente diferente. Por outro lado, a XSL possui várias características de programação, que permitem manipular o conteúdo de documentos XML. Nos casos em que se pretender apresentar o conteúdo de um documento XML no formato HTML também podem ser utilizadas as CSS (Cascading Style Sheets). No entanto, a linguagem CSS [Bos et al. 1998] é menos poderosa que a linguagem XSL, embora tenha a vantagem de ser mais fácil de implementar. As folhas de estilo CSS também são associadas aos documentos XML através da inclusão de instruções de processamento no início do documento XML.

<!DOCTYPE bdbib [

<!ELEMENT bdbib ((livro | artigo)* )>

<!ELEMENT livro (autor+, título, editora, ano)> <!ATTLIST livro ISBN ID #REQUIRED> <!ELEMENT artigo (autor+, título, ano?)>

<!ATTLIST artigo classificação CDATA #IMPLIED referencia IDREF #REQUIRED> <!ELEMENT autor (#PCDATA)>

<!ELEMENT título (#PCDATA)> <!ELEMENT editora (nome, sede)> <!ELEMENT nome (#PCDATA)> <!ELEMENT sede (#PCDATA)> <!ELEMENT ano (#PCDATA)> ]>

(6)

2.1.3 Vantagens da XML

Para terminar esta breve apresentação da linguagem XML, a seguir resumem-se algumas das suas principais vantagens:

• Os documentos XML são auto-descritivos. São, portanto, relativamente fáceis de interpretar, manipular e questionar. Esta característica pode também revolucionar o modo como as pesquisas são efectuadas na WWW, permitindo o aparecimento de motores de pesquisa que realizem as pesquisas tendo em conta o significado (contexto) dos dados, em vez de se basearem unicamente na associação de palavras-chave.

• Apesar da sua simplicidade, a XML permite criar estruturas bastante complexas (grafos de profundidade arbitrária e, eventualmente, cíclicos e recursivos).

• A XML é extremamente flexível, possibilitando a representação, quer de dados

estruturados, quer de dados semi-estruturados.

• Recorrendo às declarações de tipos do documento, é possível efectuar a validação de documentos. Esta característica revela-se de extrema importância para aplicações em que a verificação estrutural dos dados seja vital, como é o caso das bases de dados relacionais.

• O conteúdo de um documento XML pode ser facilmente manipulado pelas aplicações de software (recorrendo às APIs existentes), o que torna possível atingir níveis de automação bastante elevados.

• Uma vez que a XML tem uma natureza metalinguística, as organizações podem utilizá-la para desenvolver padrões específicos (novas linguagens baseadas na XML), definindo declarações de tipos do documento comuns, de modo a trocarem, eficientemente, dados entre si. Estas declarações de tipos do documento podem ser disponibilizadas publicamente na WWW. O objectivo é utilizar a XML como a “língua franca” para a troca de dados entre os sistemas de informação organizacionais.

• A XML é um padrão aberto. Os documentos XML são independentes das aplicações, dos sistemas operativos, etc. Esta característica pode vir a revolucionar a integração de sistemas heterogéneos.

• Uma vez que o conteúdo de um documento XML está separado da sua apresentação, é possível obter múltiplas perspectivas sobre um mesmo documento XML (recorrendo à XSL).

•

Um documento XML pode ser pesquisado de formas não previstas (questões ad hoc). Na realidade, como se pode verificar na Figura 1, um documento XML torna-se uma verdadeira base de dados. É de salientar que, embora não exista ainda um standard, já foram apresentadas várias propostas de linguagens de interrogação para a XML. Mais à frente, voltar-se-á a este assunto.

A adopção da XML trará consigo também a necessidade de repensar o modo de armazenar, gerir e questionar os dados. Nas secções seguintes, pretende-se analisar as várias possibilidades de armazenamento de documentos XML (bases de dados relacionais, orientadas a objecto, semi-estruturadas e o sistema de ficheiros), assim como as características de algumas das linguagens de interrogação propostas para questionar os dados XML (XML-QL, Lorel, YATL, XQL). De

facto, à medida que os dados vão sendo armazenados no formato XML, os utilizadores e as aplicações irão beneficiar da possibilidade de questionar os dados XML.

3. Armazenamento de dados XML

A XML pode ser vista sob várias perspectivas: no seu nível mais básico, é uma (meta) linguagem de marcação de documentos mais expressiva do que a HTML (na secção anterior introduzimos a XML essencialmente segundo esta perspectiva); como um formato de troca de dados entre aplicações; ou como uma linguagem de modelação de dados. Nesta secção, vamos debruçar-nos sobre a gestão dos dados XML.

(7)

Apesar dos benefícios que apresentam, as declarações de tipos do documento são, de certa forma, limitadas [St. Laurent 1999]. Do ponto de vista das bases de dados, uma insuficiência clara das declarações de tipos do documento é o facto de não fornecerem informação de tipo para os dados. Essencialmente, numa declaração de tipos do documento tudo é do tipo PCDATA ou CDATA (cadeia de caracteres). Assim, quando se constrói uma declaração de tipos do documento a partir de um esquema de uma base de dados, pode-se perder informação sobre os tipos dos dados. Todavia, podem ser utilizados artifícios com a inclusão de metainformação (normalmente através de atributos) que as aplicações terão depois de ser capazes de interpretar. A troca de dados entre as bases de dados heterogéneas fica, deste modo, mais complicada.

Outros inconvenientes são, por exemplo: a incapacidade de restringir o tipo dos objectos referenciados pelos atributos IDREF(S) (por exemplo, poder especificar que o valor do atributo “referencia”, do tipo IDREF, deve ser um identificador de um elemento do tipo “livro” e não de outro qualquer tipo); a impossibilidade de especificação de intervalos (por exemplo, capacidade de restringir os valores do elemento “ano” de publicação entre 1700 e a actualidade).

Para eliminar estes inconvenientes, entre outros, e para facilitar a integração com as bases de dados, têm sido apresentadas várias propostas de linguagens de esquema para a XML: DCD (Document Content Description) [Bray, Frankston et al. 1998], XML-DATA [Layman et al. 1998], XML-SCHEMAS, SOX (Schema for Object-Oriented XML) [Davidson et al. 1999], DDML (Document Description Markup Language) [Bourret et al. 1999], DSD (Document

Structure Definition) [Klarlund et al. 1999].

Os XML-SCHEMAS são o substituto oficial do W3C para as declarações de tipos do documento. O seu objectivo é “restringir e documentar o significado, a utilização e os relacionamentos das partes constituintes de um documento XML” [Malhotra e Maloney 1999]. A proposta está definida em duas especificações: uma para as estruturas [Thompson 2000] e outra para os tipos de dados [Biron e Malhotra 2000].

Uma das principais funcionalidades disponibilizadas pelos XML-SCHEMAS é um sistema de tipificação de dados muito melhorado. Nesse sentido, poder-se-á, eventualmente, afirmar que, enquanto as declarações de tipos do documento estão mais orientadas para os documentos, os XML-SCHEMAS estão mais virados para os dados, tornando assim a XML mais apta para as aplicações de tratamento de dados.

A indústria de bases de dados já reconheceu o potencial da linguagem XML, como se comprova pelo facto de muitos dos vendedores estarem a expandir as suas tecnologias, com o intuito de proporem repositórios para documentos XML (são exemplos, na área das bases de dados relacionais: Oracle, Microsoft, IBM, Sybase, entre outros; e na área das bases de dados orientadas a objectos: ArdentSoftware, ODI, POET, entre outros).

Na comunidade das bases de dados existem adeptos de diferentes modelos: os defensores do modelo relacional, os seguidores do modelo orientado a objectos e os adeptos do recente modelo de dados semi-estruturados. Todos eles se dizem estar na posse da melhor solução, quando se trata de abordar a questão da gestão dos dados XML. Neste artigo, optou-se por dar especial atenção aos modelos de bases de dados semi-estruturados e relacional. O primeiro, porque é um modelo novo e promissor, com características particularmente adequadas para o suporte de dados do tipo XML; o segundo, porque é um modelo de reconhecido mérito, muito divulgado pelas organizações e que, por essa razão, poderá vir a ser utilizado como repositório de documentos XML.

3.1 SGBDs semi-estruturados para gerir dados XML

A investigação sobre dados semi-estruturados (também chamados dados não-estruturados) [Abiteboul 1997, Buneman 1997, Suciu 1998] é relativamente recente e teve origem na observação de que muitos dos dados electrónicos não se ajustam completamente aos modelos de

(8)

dados tradicionais, pois não podem ser restringidos por um esquema fixo e previamente estabelecido (como é o caso de grande parte dos dados na WWW). O resultado desse trabalho foi o aparecimento de um novo paradigma nas bases de dados, o modelo de dados semi-estruturados.

Por outro lado, os dados XML partilham muitas das características dos dados semi-estruturados: são auto-descritivos (isto é, o esquema está misturado com os dados); a sua estrutura pode ser irregular e nem sempre é conhecida previamente1, e pode mudar com frequência. Assim, alguns investigadores defendem que os resultados da pesquisa na área dos dados semi-estruturados podem - e devem - ser aplicados na gestão dos dados XML. Por essa razão, neste artigo vai-se analisar com maior profundidade o suporte da linguagem XML através do paradigma de bases de dados semi-estruturados.

O LORE (Ligthweigth Object REpository) [McHugh et al. 1997] é um protótipo de um Sistema de Gestão de Bases de Dados semi-estruturados que começou a ser desenvolvido na Universidade de Stanford em 1995. Apesar de ser apenas um protótipo de investigação, o LORE é o SGBD semi-estruturados mais divulgado na literatura e disponibiliza muitas características dos SGBDs comerciais, tais como suporte multi-utilizador, recuperação a falhas, uma linguagem de interrogação declarativa, uma linguagem de actualização, criação e manutenção de índices, etc.

Os documentos XML representados no modelo de dados do sistema LORE podem ser vistos como grafos dirigidos, etiquetados e ordenados. Os nós do grafo representam os elementos de dados, e os arcos representam os relacionamentos elemento/sub-elemento. Cada nó de um elemento complexo contém uma etiqueta e uma lista ordenada de pares nome_do_atributo/valor_atómico. Os nós dos elementos atómicos contêm valores de texto. Existem dois tipos diferentes de arcos no grafo: os arcos de sub-elemento normais, identificados com a etiqueta de marcação do sub-elemento de destino; e os arcos de ligação, etiquetados com o nome do atributo que introduz a ligação. A Figura 3 ilustra a representação gráfica, neste modelo de dados, para o documento XML da Figura 1.

livro autor &5 &6 &2 &7 &9 título editora &11 &12 &3 nome sede bdbib &1 livro título autor editora

&14 &15 &16 artigo autor título &4 ano "Tecnologia de Bases de Dados" "FCA" "José Luís Pereira" {ISBN="_972-722-143-2"} "Planeamento de Sistemas de Informação" "Lisboa" "Luís Amaral" "FCA" "Lisboa" "1999" "1998" referencia &17 text &18 text &19 &20 nome sede &24 &22 text text text &31 &32 &25 text &26 &13 text &27 ano &8 ano &21 text

&28 &29 &30 text &33 &34 text text text text {ISBN="_972-722-193-9"} {Classificação="KM", referencia="_972-722-193-9"} "João Álvaro Carvalho" "Knowledge Needs of Self-Organized Systems" "2000" &10 &23 text "João Varajão" autor

Figura 3 – Representação gráfica no sistema LORE do documento XML da Figura 1

1_{Como já foi referido, embora os documentos XML possam ter associada uma declaração de tipos do}

(9)

Os identificadores dos elementos aparecem dentro dos nós e são precedidos do símbolo “&” (&1, &2, etc). Os pares nome_do_atributo/valor_atómico são mostrados entre {} colocados próximo dos nós associados, com os atributos de referenciação em itálico. Os arcos dos sub-elementos são linhas a cheio, e os arcos de ligação estão representados por linhas tracejadas. A ordem dos sub-elementos é da esquerda para a direita. As etiquetas associadas a cada elemento não estão ilustradas, uma vez que são fáceis de deduzir, para esta base de dados. Por exemplo, o nó &3 tem a etiqueta “livro” e não “referencia”.

O LORE possibilita a utilização de dataguides, para tentar tirar partido da estrutura, nos casos em que ela existir. Um dataguide é um sumário conciso e preciso da estrutura de uma base de dados LORE, que é mantido dinamicamente. De certa forma, no LORE, um dataguide desempenha o papel equivalente ao do esquema de uma base de dados tradicional (ou de uma declaração de tipos do documento): é essencial para os utilizadores – e as aplicações – explorarem a estrutura da base de dados e formularem questões com maior facilidade; é também importante para o sistema, por exemplo, guardar estatísticas sobre a base de dados e conduzir à optimização de questões.

Contudo, no LORE, ao invés dos sistemas relacionais e orientados a objectos, em vez de ser obrigatório que os dados estejam conformes com o esquema (ou com uma declaração de tipos do documento), o sistema mantém dinamicamente o dataguide, de modo a que este sumarie correctamente a estrutura actual da base de dados (isto é, com o objectivo de manter consistente o dataguide, sempre que a base de dados subjacente é actualizada). Em [Goldman e Widom 1997] é apresentado um algoritmo para a criação e manutenção dinâmica de um dataguide. Um dataguide pode ser representado em XML. Cada caminho (etiquetas de marcação/atributos) da base de dados original aparece exactamente uma vez no dataguide, e todos os caminhos do

dataguide aparecem na base de dados original. A Figura 4 representa o dataguide (em formato

XML) da base de dados da Figura 3.

Figura 4 – Dataguide (em formato XML) da base de dados da Figura 3.

Em relação a este exemplo, repare-se que, apesar de uma base de dados real poder conter milhares de livros, o caminho bdbib.livro aparece somente uma vez no dataguide.

Porém, no que concerne às bases de dados de grandes dimensões e que contêm muitos ciclos na sua estrutura, a construção de um dataguide pode tornar-se proibitivamente dispendiosa. Em [Goldman e Widom 1999] defende-se que, em muitas situações, um sumário “aproximado” da estrutura da base de dados pode ser benéfico e, ao mesmo tempo, muito menos dispendioso de computar. Nesse artigo introduz-se o conceito de approximate dataguide (ADG), como sendo um grafo com as propriedades de um dataguide; contudo, a condição de que todos os caminhos existentes no dataguide têm que existir também na base de dados correspondente deixa de ser

<título> </título> <ano> </ano> </artigo>

(10)

obrigatória. São também apresentadas duas abordagens para construir este novo tipo de

dataguide (que sumaria “aproximadamente” a estrutura da base de dados) e os respectivos

resultados experimentais. São ainda descritas algumas das situações em que se deve, ou não, utilizar os ADGs em detrimento dos dataguides.

O sistema LORE possui também uma linguagem de interrogação declarativa – a lorel (LORE

Language). Nesta subsecção, apresenta-se, a título de exemplo, uma questão simples, que

introduz o bloco básico de construção de questões lorel com as expressões de caminho. Assim, a questão que se segue, quando aplicada sobre o documento XML da Figura 1, selecciona os autores dos livros publicados pela editora FCA.

Select L.autor

From bdbib.livro L, L.editora E Where E.nome = “FCA”

Questão 1 – Questão expressa na linguagem lorel.

Para perceber esta questão, é mais fácil começar pela cláusula “From”, a qual itera sobre cada caminho bdbib.livro, associando os elementos “livro” à variável L. Por cada elemento associado à variável L é também associado o seu (sub)elemento “editora” à variável E. Para cada par de associações, verificam-se depois as condições de filtragem da cláusula “Where”. Se os pares de associações verificarem as condições, então devolve-se o autor dos livros como resultado da questão(cláusula “Select”).

3.2 SGBDs Relacionais para gerir dados XML

Uma outra abordagem, bem mais conservadora, consiste em utilizar SGBDs relacionais para armazenar e questionar os documentos XML. Os vendedores destes sistemas parecem adoptar uma estratégia comum, quer para as opções de armazenamento disponibilizadas, quer para as funcionalidades que oferecem [Banerjee et al. 2000, Cheng e Xu 2000, Sybase 1999]. Assim, no que concerne ao armazenamento dos dados XML, são fornecidos três métodos distintos:

1. Armazenamento por elemento: o documento XML é decomposto em estruturas relacionais e/ou “objecto-relacionais”. Isto é, extraem-se os dados dos elementos do documento XML e armazenam-se na base de dados, como registos e colunas de tabelas, por exemplo. Este tipo de armazenamento é útil para os documentos XML estruturados (com a declaração de tipos do documento).

2. Armazenamento por documento: o documento é armazenado (sem ser particionado), numa coluna como um CLOB (Character Large OBject). Este tipo de armazenamento é ideal, se a estrutura do documento XML for desconhecida ou dinâmica.

3. Armazenamento híbrido: armazena o documento como um CLOB. No entanto, parte do documento é também decomposta e armazenada como estruturas no formato “objecto-relacional”. Este tipo de armazenamento é útil quando o utilizador quer ter o controlo da granularidade dos dados.

O armazenamento por elemento, para além de preservar a estrutura original do documento XML, proporciona um acesso mais rápido e conveniente aos dados (XML) que estão na base de dados, através da utilização eficiente da SQL (Standard Query Language) e de índices. Todavia, é um método mais dispendioso, uma vez que implica o mapeamento entre o documento XML e a base de dados. O armazenamento por documento evita os custos provenientes do mapeamento, mas proporciona um acesso aos dados mais lento e menos conveniente, que se resume a uma pesquisa por palavras-chave. Finalmente, o armazenamento híbrido, sendo mais flexível, pretende estabelecer o equilíbrio entre as qualidades e as desvantagens de ambos os métodos anteriores; contudo tem também associado o custo e a complexidade do armazenamento dos dados extraídos do documento XML (a parte que é decomposta em estruturas no formato “objecto-relacional”).

(11)

No caso de ser necessário mapear os dados XML para a base de dados e vice versa, os SGBDs relacionais oferecem, normalmente, ferramentas “middleware” para fazer o mapeamento directamente. No entanto, encontram-se também disponíveis (gratuitamente) na Internet várias versões destas ferramentas, genéricas, independentes dos SGBDs.

Em [Shanmugasundaram et al. 1999, Florescu e Kossmann 1999] é feita uma análise da forma como os dados XML podem ser armazenados e questionados utilizando SGBDs relacionais. São também apresentados alguns mapeamentos possíveis, assim como os resultados de uma análise do desempenho deste tipo de sistemas na gestão de dados XML. São ainda indicadas algumas das vantagens e desvantagens desta abordagem. A título de exemplo, referem-se como principais vantagens: utiliza-se uma tecnologia já madura, bem estabelecida no mercado, e escalável; os resultados das experiências efectuadas revelam que, na grande maioria dos casos, se podem obter bons desempenhos no processamento de questões. Por outro lado, apresenta-se como principal desvantagem o facto de ser, normalmente, dispendiosa a operação de reconstrução do documento XML original, a partir dos dados existentes na base de dados. O aparecimento de novas linguagens de esquema para a XML, mais expressivas que as actuais declarações de tipos dos documentos XML, irá com certeza tornar os mapeamentos, entre as bases de dados relacionais e os documentos XML, mais simples.

Outra abordagem possível para gerir os dados XML consiste em utilizar um SGBD orientado a objectos. Os adeptos desta abordagem defendem que o modelo orientado a objectos é o que mais se adapta à XML, referindo até que a adopção universal da XML poderá, num futuro próximo, vir a mudar o panorama actual do mercado de bases de dados orientadas a objectos que, como é sabido, é hoje bastante reduzido. Por exemplo, em [Poet 1997] é apresentada a estratégia da Poet Software para gerir dados XML através do seu SGBD orientado a objectos. Um método alternativo para armazenar documentos XML consiste em utilizar o próprio sistema de ficheiros. De um modo simplista, e de um ponto de vista especificamente voltado para as bases de dados, em oposição à perspectiva sobre o documento, podemos considerar um documento XML como uma base de dados e a declaração de tipos do documento como o esquema da base de dados.

Assim, utilizando um processador XML para aceder à estrutura do documento e recorrendo a uma linguagem de programação (a Java, por exemplo) para manipular/questionar o conteúdo dos documentos, podem-se implementar bases de dados rudimentares. Contudo, isto limita, naturalmente, o género de questões que possam ser formuladas à base de dados. Essas questões restringem-se às possibilidades que forem oferecidas, quer pelo processador XML, quer pela linguagem de programação utilizados. Em [Holzner 1999] estão descritos vários exemplos que seguem esta abordagem.

4. Linguagens de Interrogação para a XML

O impulso inicial para a criação da XML parece ter sido, essencialmente, o de melhorar a capacidade de interpretar e operar sobre os documentos da WWW. Porém, na perspectiva das bases de dados, a XML gerou uma outra possibilidade deveras importante: com os dados armazenados em documentos XML torna-se possível questionar o conteúdo destes documentos. Consequentemente, deve ser possível formular questões sobre conjuntos de documentos XML para extrair, sintetizar e analisar os seus conteúdos.

Da investigação realizada sobre os dados semi-estruturados surgiram algumas propostas de linguagens para questionar os dados XML, nomeadamente a XML-QL [Deutsch et al. 1999], a YATL [Cluet et al. 1998] e a lorel [Abiteboul et al. 1997]. Por outro lado, proveniente da área da

(12)

Em [Maier 1998, Rys 1998] apresentam-se alguns dos requisitos que uma linguagem de interrogação para a XML deve apresentar, dos quais se destacam: apresentação dos resultados no formato XML; possibilidade de seleccionar, extrair, eliminar, combinar e transformar o conteúdo de um documento XML; capacidade de actuar sobre dados sem esquema predefinido; possibilidade de ser representável em XML (isto é, apesar de poder existir mais do que uma sintaxe para representar uma questão, uma delas deve ser a XML); capacidade de ser manipulável por software.

Em [Fernandez et al. 2000] são apresentadas as principais características que devem ser contempladas por uma linguagem de interrogação para os dados XML, através de exemplos expressos em quatro linguagens existentes. Em [Ceri et al. 1999] é apresentada uma linguagem gráfica, a XML-GL, para questionar dados XML.

Nesta secção, por condicionamentos de espaço, apresenta-se apenas um exemplo da utilização de linguagens de interrogação para dados XML, através de duas linguagens: a XML-QL (questão 2), e a lorel (questão 3).

A lorel (LORE Language) é a linguagem de interrogação do sistema LORE e consiste, basicamente, numa extensão da linguagem OQL (Object Query Language), linguagem de interrogação proposta pelo ODMG (Object Database Management Group) para os sistemas de bases de dados orientadas a objectos. A lorel adopta uma sintaxe Select-From-Where. Contudo, nem todas as questões lorel têm que possuir esta estrutura.

Por outro lado, a XML-QL, que foi projectada especificamente para a XML, combina a sintaxe da XML com as técnicas das linguagens de interrogação. Uma questão XML-QL consiste numa cláusula Where, que indica o que se pretende seleccionar, e numa cláusula Construct, que especifica o resultado a devolver.

As questões 2 e 3, quando aplicadas sobre o documento XML2 da Figura 1 seleccionam os autores dos livros publicados pela editora FCA depois de 1995.

WHERE <bdbib> <livro> <autor> $a </autor>

<título> $t </título>

</livro> </bdbib> IN “www.estv.ipv.pt/biblioteca/bdbiblio.xml”, $n > 1995 CONSTRUCT $a

Questão 2 – Questão expressa na linguagem XML-QL.

A operação de selecção, na XML-QL, é feita através da utilização de padrões e de condições. À expressão <bdbib> ... </bdbib> na cláusula Where chama-se Padrão; tem a forma de uma expressão XML, mas pode conter também variáveis. A operação de extracção é realizada através de variáveis. Os nomes das variáveis são precedidos do símbolo $, para se distinguirem do resto do texto. A URL (Uniform Resource Locator), colocada à direita da palavra-chave IN, identifica o ficheiro XML sobre o qual se pretende lançar a questão. De um modo informal: a questão 2 encontra todos os elementos <livro> do documento XML da Figura 1 que têm, pelo menos, um elemento <autor>, um elemento <título>, um elemento <editora> (cujo elemento <nome> é igual a FCA) e um elemento <ano>. Para cada elemento <livro> que verifica esta condição a questão associa as variáveis $t e $a aos elementos “título”, “autor”, respectivamente. O resultado da questão é a lista de todos os autores associados à variável $a.

Na linguagem XML-QL pode-se indicar a estrutura do documento XML desejado para a apresentação dos resultados. Por exemplo, se na questão 2 fosse alterada a parte do construtor para:

(13)

CONSTRUCT <resultado>

esta nova questão devolveria tanto os autores como os títulos dos livros publicados pela editora FCA depois de 1995. Contudo, agrupava os elementos <autor> e <título> num novo elemento <resultado>.

A mesma questão colocada em linguagem lorel, poderia ser:

SELECT bdbib.livro.autor

WHERE bdbib.livro.editora.nome = “FCA” AND bdbib.livro.ano > 1995 Questão 3 - Questão expressa na linguagem lorel.

Note-se que, ao contrário da questão 1, na questão 3 não se adoptou uma sintaxe

Selec-From-Where, nem se utilizaram variáveis. O resultado destas questões é expresso na

forma de um documento XML.

Deve-se, no entanto, notar que se está apenas no campo das propostas. Não existe actualmente um standard para linguagens de interrogação XML. Parece, pois, estar-se perante uma estratégia em tudo semelhante à seguida no caso das bases de dados orientadas a objectos, isto é, têm vindo a aparecer, com origem em alguns diferentes grupos de investigação independentes, várias propostas de modelos de dados e das respectivas linguagens de interrogação para a XML. Perspectiva-se, assim, o aparecimento de um standard, quer para um modelo de dados, quer para uma linguagem de interrogação para os dados XML. Com esse objectivo, foi criado um grupo de trabalho – o XML Query Working Group – no âmbito do W3C.

5. Conclusão

A XML está a revolucionar o mundo da WWW. Apesar de ter surgido, inicialmente, como uma tentativa de resolver as limitações da HTML no que se relaciona com a definição do conteúdo dos documentos WWW, depressa se notaram as suas potencialidades como formato para a gestão, armazenamento e troca de dados. Por essa razão, tem vindo a ser alvo de grande atenção, também por parte da comunidade científica e construtores de bases de dados.

Com a representação de dados surge, naturalmente, a necessidade de os questionar. Nesse sentido, têm sido propostas várias linguagens de interrogação para a XML de acordo com os respectivos modelos de dados subjacentes.

Merece também destaque o importante papel que a XML poderá vir a ter no campo da integração de fontes de dados heterogéneas que, tudo indica, lhe permitirá assumir-se como “língua franca” da WWW.

Para concluir, é necessário ter em atenção que esta é uma área de ponta em termos de investigação, onde os desenvolvimentos surgem constantemente e onde nada, ou quase nada, é tido como definitivo.

6. Referências

Abiteboul, S., “Querying semistructured data”, Proc. of Intl. Conf. on Database Theory, 1997. Abiteboul, S., Quass, D., McHugh, J., Widom, J. e Wiener, J., “ The Lorel Query Language for Semistructured Data”, International Journal on Digital Libraries, (Abril de 1997), 1, 1, 68-88. Adler, S. et al., eXtensible Stylesheet Language, W3C Working Draft, Março de 2000. Disponível em http://www.w3.org/TR/xsl/

(14)

Banerjee, S., Krishnamurthy, V., Krisshnaprasad, M. e Murthy, R., Oracle 8i – The XML Enableb Data Management System, 2000.

Biron, P. V. e Malhotra, A, XML Schema part 2: Datatypes, W3C working draft, Abril de 2000. Disponível em http://www.w3c.org/TR/xmlschema-2

Bos, B., Lie, H. W., Lilley, C. e Jacobs, I., Cascading Style Sheets – Level 2, World Wide Web Consortium, Maio de 1998. Disponível em http://www.w3.org/TR/REC-CSS2/

Bourret, R. et al., Document Definition Markup Language, submission to the World Wide Web Consortium, Janeiro de 1999. Disponível em http://www.w3.org/TR/NOTE-ddml

Bray, T. et al., eXtensible Markup Language (XML) 1.0, World Wide Web Consortium, Fevereiro 1998. Disponível em http://www.w3c.org/TR/REC-xml.

Bray, T., Frankston, C. e Malhotra, A., Document Content Description, submission to the World Wide Web Consortium, Julho de 1998. Disponível em http://www.w3.org/TR/NOTE-dcd Buneman, P., “Tutorial: Semistructured data”, Proceedings of ACM Symposium on Principles of

Database Systems, (1997), 117-121.

Ceri, S., Comai, S., Damiani, E., Fraternali, P., Paraboshi, S. e Tanca, L., “XML-GL: a Graphical Language for Querying and Restructuring XML Documents”, Proceedings of the Int.

WWW Conf., 1999.

Cheng, J. e Xu, J., XML and DB2, IBM Santa Teresa Laboratory, 2000.

Cluet, S., Delobel, C., Siméon, J. e Smaga, K., “Your Mediators Need Data Conversion!”,

Proceedings of the ACM SIGMOD International Conference of Management of Data, (1998),

177-188

Davidson, A. et al., Schema for Object-Oriented, SOX 2.0, W3C Note, Julho de 1999. Disponível em http://www.w3.org/TR/NOTE-SOX/

Deutsch, A., Fernandez, M., Florescu, D., Levy, A. e Suciu, D., “A query language for XML”,

International World Wide Web Conference, 1999.

Fernandez, M., Siméon, J. e Wadler, P., XML Query Languages: Experiences and Exemplares, Paper for the W3C XML Query Working Group, 2000.

Florescu, D. e Kossmann, R., A Performance Evaluation of Alternative Mapping Schemes for Storing XML Data in a Relational Database, Technical Report 3684, Março de 1999.

Goldman, R. e Widom, J., ”Dataguides: Enabling query formulation and optimisation in semistructured databases”, Proc. of Intl. Conf. on Very Large Data Bases, (1997), 436-445. Goldman, R. e Widom, J., ”Approximate DataGuides”, Proceedings of the Workshop on Query Processing for Semistructured Data and Non-Standard Data Formats, (Janeiro de 1999), Jerusalem, Israel.

Holzner, S., XML Complet, McGraw-Hill ,(1998), 221-278.

Klarlund, N., Moller, A. e Schwartzbach, M., DSD: A Schema Language for XML., Novembro 1999. Disponível em http://www.brics.dk/DSD/.

Layman, A. et al., XML-Data, W3C Note, Janeiro de 1998. Disponível em http://www.w3.org/TR/1998/NOTE-XML-data-0105/

Maier, D., “Database Desiderata for an XML Query Language”, W3C Workshop on Query

Languages for XML, 1998.

McHugh, J., Abiteboul, S., Goldman, R., Quass, D. e Widom, J., “Lore: A database management system for semistructured data”, ACM SIGMOD Record, (1997), 26, 3, 1997.

(15)

Malhotra, A. e Maloney, M., XML Schema Requirements, W3C Note, Fevereiro de 1999. Disponível em http://www.w3.org/TR/NOTE-xml-schema-req

Poet XML White Paper, “XML The Foundation for the Future”, Novembro de 1997.

Disponível em:

http://www.poet.com/products/cms/white_papers/foundation_for_the_future/index.html

Robie, J., The design of XQL, 1999. Disponível em: http://www.textel.no/whitepapers/xql-design.html.

Rys, M., “Query Languages for XML Documents: A QL’98 Position Paper” , W3C Workshop

on Query Languages for XML, 1998.

Shanmugasundaram, J., Tufte, K., He, G., Zhang, C., Dewitt, D. e Naughton, J, “Relational Databases for Querying XML Documents: Limitations and Opportunities”, Proceedings of the

25th VLDB Conference, (1999), Edinburgh, Scotland.

St. Laurent, S., “Describing your data: DTDs and XML Schemas”, XML.com, Dezembro de 1999. Disponível em http://www.xml.com/pub/1999/12/dtd/index.html.

Suciu, D., “An overview of semistructured data”, SIGACT News, 29, 4, (Dezembro de 1998), 28-38.

Sybase XML Technical White Paper, Using XML with the Sybase Adaptive Server SQL Databases, 1999

Thompson, H. S., Beech, D. B., Maloney, M. e Mendelsohn, N, XML Schema Part 1: Structures, W3C Working Draft, Abril de 2000. Disponível em http://www.w3c.org/TR/xmlschema-1