Uma Abordagem para o Mapeamento de Definições XML Schema para SQL:1999

Transcrição

1 Patrícia Martins Uma Abordagem para o Mapeamento de Definições XML Schema para SQL:1999 Dissertação apresentada ao Curso de Pós-Graduação em Ciência da Computação da Universidade Federal de Minas Gerais como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação Belo Horizonte 22 de agosto de 2005

2 Livros Grátis Milhares de livros grátis para download.

3 Resumo Atualmente, um grande volume de dados é representado como documentos XML com estrutura cada vez mais complexa. Com isso, é notória a necessidade de facilidades para armazenamento, consulta e alteração de tais documentos, de forma consistente, confiável e eficiente. Nesse contexto, SGBDs relacionais e objeto-relacionais mostramse uma solução adequada por prover recursos já consolidados para o gerenciamento de dados e têm SQL como linguagem padrão. O armazenamento de dados XML em SGBDs relacionais ou objeto-relacionais não é uma tarefa trivial devido ao seu formato hierárquico, entretanto a existência de esquemas que descrevem o seu conteúdo permite identificar as possíveis estruturas de documentos válidos em relação a esses esquemas. No momento, XML Schema é o padrão que apresenta maior riqueza para a descrição de esquemas XML. Esta dissertação apresenta um algoritmo para mapear definições do padrão W3C XML Schema em esquemas SQL:1999. A escolha do padrão SQL:1999 se deve aos recursos oferecidos pela linguagem, especialmente a possibilidade de criação de tipos abstratos de dados. A abordagem está fundamentada em levantamentos de conteúdo realizados a partir de uma coleção de 199 XSDs (XML Schema Definitions) obtidas da Web de modo a identificar quais são as construções efetivamente utilizadas na prática e determinar estratégias adequadas de mapeamento. Esses levantamentos mostraram detalhes da formação de XSDs que não foram encontrados em nenhum outro trabalho, o que permitiu o desenvolvimento de um algoritmo específico que contempla as principais definições. São tratadas questões fundamentais como a preservação da ordem e da cardinalidade dos elementos, sendo a técnica de inlining adaptada para reduzir a fragmentação dos dados nas tabelas criadas.

4 Abstract Nowadays, large volumes of data are represented as XML documents, presenting more and more complex structures. Thus, it is necessary to provide facilities for storage, querying and modification of those documents in a consistent, trusty and efficient way. In this scenario, relational and object-relational DBMSs can be seen as a suitable solution because of their consolidated resources for management of data and the use of SQL as a standard language. The storage of XML data by relational or object-relational DBMSs is not a trivial task because of their hierarquical structure, but the existence of schemas that describe its content allows the identification of feasible structures of valid documents with respect to those schemas Currently, XML Schema is the richest standard for the description of XML schemas. This dissertation presents an algorithm to map W3C XML Schema definitions into SQL:1999 database schemas. The choice of SQL:1999 was due to its facilities, especially the ability to create abstract types. The approach is founded on a content analysis carried out on a collection of 199 XSDs (XML Schema Definitions) obtained from the Web in order to identify which constructs are effectively used in practice and to determine proper mapping strategies. The algorithm handles key aspects such as order preservation and the cardinality of the elements, and uses an adaptation of the inlining technique to reduce data fragmentation in the created tables.

5 Dedico esta dissertação aos meus pais que me apoiaram incondicionalmente em todos os instantes.

6 Agradecimentos Nem acredito que estou escrevendo a seção de agradecimentos da minha dissertação e que já se passaram dois anos e quatro meses desde o dia em que cheguei sozinha ao aeroporto da Pampulha em Belo Horizonte, sem conhecer ninguém e em busca de um sonho: cursar um mestrado. Esse objetivo teve um preço, que foi ficar longe da minha família e dos meus amigos, o que não foi nada fácil. Além do conhecimento acadêmico, amadureci muito com as experiências que vivi, aprendizado que vou levar por toda a minha vida. Neste caminho, tenho muito que agradecer às pessoas que me apoiaram para que eu conseguisse chegar até aqui. Definitivamente, sem a ajuda de Deus eu não teria força suficiente para tantos desafios. Ele me indicou o caminho para vencer todas as dificuldades fazendo tudo sempre dar certo no final. Meus pais, Solange e Jorge, são as pessoas que me prepararam para a vida, dando a formação moral necessária e muito amor. Mesmo a tantos quilômetros de distância, reduzidos pelo telefone e MSN, eu sempre soube que eles estiveram ao meu lado em todos os momentos, me apoiando incondicionalmente. Espero fazer jus ao orgulho que sentem de mim e agradeço profundamente por tudo. Tenho certeza que meu querido vovô Jonas iria ficar muito feliz em ver a neta dele mestra e sei que ele está olhando por mim de onde quer que ele esteja, obrigada por tudo vovô. Agradeço a minha avó Sessé e a minha dinda Lêda pelo apoio, mesmo à distância. O Professor Alberto Laender é um exemplo de orientador e me sinto muito feliz por ter tido a oportunidade de aprender tanto com ele. A sua seriedade e dedicação na tarefa de formar alunos nos motiva a tentar fazer sempre o melhor. Meus sinceros agradecimentos pelo apoio e paciência. Geraldo fez desse mestrado um período especial pelos tantos momentos maravilhosos que vivemos juntos. Agradeço por ele ter aparecido na minha vida e ter trazido tanta alegria. Agradeço à amiga Dani que foi uma pessoa fundamental neste percurso, sempre disposta a me ouvir. Aos amigos do LBD que fizeram deste laboratório o mais animado do DCC, em um clima de muita alegria. Um agradecimento especial aos meus amigos Willian, Carol, Karen e Julinho que não deixaram nossa amizade mudar mesmo à

7 distância e sempre me receberam tão bem em Salvador a cada retorno. Meu agradecimento às funcionárias do DCC, sempre atenciosas e eficientes, Renata, Maristela, Stella e Sheila, e ao Professor Geraldo Robson.

8 Sumário 1 INTRODUÇÃO Motivação Objetivo Trabalhos Relacionados Contribuições Organização da Dissertação CONCEITOS RELACIONADOS XML Árvores XML Esquemas XML XML Schema Estrutura SQL SQL: SQL: DESCRIÇÃO DA ABORDAGEM Estatísticas Algoritmo de Mapeamento Pré-processamento Detecção de Ciclos Aplicação de etapa fundamentada na Técnica de Inlining Geração do Esquema SQL: Exemplo... 39

9 4 VALIDAÇÃO DO ALGORITMO DE MAPEAMENTO Cobertura do Algoritmo Experimentos Casos Não-mapeados CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS... 53

10 Índice de Figuras Figura 2.1. Exemplo de elemento e atributo... 8 Figura 2.2. Documento XML com dois elementos-raiz Figura 2.3. Aninhamento entre elementos... 9 Figura 2.4. Documento XML orientado a dados Figura 2.5. Documento XML orientado a documento Figura 2.6. Associação do prefixo xs ao espaço de nomes padrão Figura 2.7. Uso de tipos simples Figura 2.8. Declaração de tipo complexo com modelo de conteúdo simples Figura 2.9. Uso de choice em XSD e uma instância correspondente Figura Uso de group e attributegroup e uma instância correspondente Figura 2.11 Tipo estruturado com atributo de tipo ARRAY Figura Herança de tipo estruturado (subtipo) Figura Tabela de tipos Figura Uso de tipo REF Figura 3.1. Exemplo de realização de uma das etapas do pré-processamento Figura 3.2. Esquemas e instâncias antes e após a eliminação de aninhamentos Figura 3.3. Trechos de XSDs com ciclos na declaração de elementos Figura 3.4. Algoritmo para detecção de ciclos em XSD Figura 3.5. Algoritmo fundamentado na técnica de Inlining Figura 3.6. Esquemas e instâncias antes e após transformação de inlining Figura 3.7. Multiplicação das ocorrências dos elementos e construtores de agregação na realização de inlining Figura 3.8. Algoritmo de mapeamento de uma XSD para um script SQL: Figura 3.9. Procedimento para a criação de hierarquias Figura Detalhamento do procedimento para geração de script SQL: Figura Exemplo de XSD Figura Substituição de definições group e attributegroup Figura XSD resultante do pré-processamento Figura Aplicação da técnica de inlining Figura Script SQL:1999 resultante do mapeamento da XSD da Figura Figura 4.1. Resultados da aplicação do algoritmo de mapeamento

11 Índice de Tabelas Tabela 2.1. Modelos de conteúdo. Fonte: [34] Tabela 3.1. Utilização de construções em XSDs Tabela 3.2. Distribuição de modelo de conteúdo em construções complextype Tabela 3.3. Utilização das construções all, choice, sequence e group em modelos de conteúdo complexos Tabela 3.4. Uso de construtores de agregação com apenas um elemento-filho Tabela 3.5. Aninhamento em construtores de composição Tabela 3.6. Aninhamento de construtores em XSDs Tabela 3.7. Distribuição de tipos de derivação Tabela 3.8. Mapeamento de restrições sobre atributos e elementos do XML Schema em SQL:

12 1 Introdução Desde o seu surgimento em 1996, a linguagem XML (extended Markup Language) [38] vem se difundindo rapidamente como um padrão para representação, troca e armazenamento de dados. Razões para isso incluem o seu formato textual e nãoproprietário que facilita a criação de documentos por pessoas e softwares, ao contrário do que acontece com formatos binários. Sua estrutura auto-descritiva provê meios flexíveis para manipulação de dados [28] e interoperação entre sistemas heterogêneos. Com XML, é possível armazenar dados estruturados e semi-estruturados [7], o que torna seu uso adequado para diversas aplicações. A existência de linguagens associadas a XML, tais como XSLT (Extensible Stylesheet Language Transformations) [44], XPath (XML Path Language) [41], CSS (Cascading Style Sheet) [36], XML Schema [42], DTD (Document Type Definition) [1, 38], XQuery (XML Query) [43], torna o seu uso ainda mais atraente para o gerenciamento de dados, por oferecer recursos diversificados para exploração do conteúdo dos documentos, que variam desde a restrição da estrutura até a consulta e formatação. Dentre esses padrões, aqueles que são mais importantes para a organização dos dados são as linguagens de esquema, cujas construções, também chamadas de definições, permitem especificar regras de formação para os dados contidos em documentos XML. Fazendo-se uma comparação simples, esquemas XML são análogos a esquemas de bancos de dados. Seu uso não é obrigatório, entretanto são importantes quando se deseja conhecer previamente o formato dos dados a serem manipulados. O processamento de documentos sem esquemas não é muito útil, já que não há um consenso sobre o significado dos elementos [29], podendo causar ambigüidades. Documentos que estão em conformidade com um determinado esquema são chamados válidos. Diversas linguagens de esquema foram propostas até o momento, destacando-se DTD e XML Schema, sendo esta última mais expressiva [18]. 1.1 Motivação Atualmente, um grande volume de dados é representado como documentos XML 1

13 com estrutura cada vez mais complexa. Com isso, é notória a necessidade de facilidades para armazenamento, consulta e alteração de tais documentos, de forma consistente, confiável e eficiente. Na maioria dos casos, o gerenciamento manual não se mostra uma opção viável, de modo que as alternativas existentes podem ser divididas de acordo com o mecanismo de armazenamento utilizado: sistemas de arquivos, sistemas de gerenciamento de bancos de dados (SGBDs) e sistemas específicos para XML. As propostas que mais se destacam são aquelas que utilizam SGBDRs (Sistemas de Gerenciamento de Bancos de Dados Relacionais). Os sistemas de arquivos são a solução mais simples, mas não oferecem facilidades para a manipulação de dados no padrão XML. Nesse contexto, a opção por sistemas relacionais decorre do oferecimento de recursos amplamente otimizados e testados, como conseqüência de pesquisas e aceitação por mais de duas décadas, já que os sistemas de gerenciamento de bancos de dados orientados a objetos ainda não estão suficientemente maduros [13], especialmente com relação ao desempenho, para comportar grandes volumes de dados. Uma opção intermediária e utilizada atualmente, com diversos produtos comerciais disponíveis, são os sistemas objeto-relacionais [33]. Especialmente por possibilitar a representação de tipos abstratos, mostram-se adequados para o armazenamento de dados XML. A linguagem padrão adotada pelos SGBDs (relacionais e objeto-relacionais) para especificar a estrutura dos dados e manipulá-los é SQL (Structured Query Language). Desde o seu surgimento, vários padrões foram publicados: SQL-86, SQL-89, SQL-92, SQL:1999 [21, 22] e SQL:2003 [11]. O padrão SQL-92 fornecia recursos apenas para sistemas relacionais, sendo ainda o mais utilizado na prática, enquanto o padrão SQL:1999 adicionou características de orientação a objetos e outras facilidades, sendo assim a base de muitos sistemas objeto-relacionais [10], ao mesmo tempo que mantém a compatibilidade com o padrão SQL-92. Por sua vez, SQL:2003 faz revisões ao padrão SQL:1999 e adiciona uma nova parte, denominada SQL/XML [11]. O armazenamento de dados XML, que apresenta estrutura hierárquica, em sistemas (objeto-) relacionais não é um problema trivial, devido às diferenças entre os modelos de representação. Assim, é desejável que os dados possam ser armazenados sem perdas semânticas nem estruturais significativas. Neste sentido, é fundamental preservar os dados existentes nos documentos XML válidos em relação ao esquema que está sendo mapeado. Assim, as mudanças devem ser realizadas sem violar esse princípio. Restrições estruturais e semânticas são expressas explicitamente através de esquemas XML, embora seja possível extraí-las a partir de um conjunto de documentos 2

14 relacionados entre si, o que constitui um outro problema [25]. 1.2 Objetivo O objetivo deste trabalho é determinar as definições (também referenciadas no texto como construções) especificadas em XML Schema que são úteis para o armazenamento de documentos XML válidos em um sistema objeto-relacional, mantendo-se a sua conformidade com o esquema associado. Para isso, é proposto um algoritmo [20] para mapeamento de definições XML Schema para o padrão SQL:1999, ou seja, pretende-se identificar determinados tipos de XSDs (XML Schema Definitions) que podem ser representadas em um SGBD objeto-relacional de forma a garantir a especificação das suas restrições por meio das restrições de integridade existentes no padrão SQL:1999. Conseqüentemente, apenas documentos XML válidos podem ser armazenados. O padrão SQL:1999 foi escolhido ao invés do SQL:2003 porque a maioria dos SGBDs atuais ainda não implementa este padrão mais recente e todas as construções utilizadas neste trabalho são também válidas no padrão SQL:2003. O mapeamento não é uma tarefa simples, já que as diversas combinações possíveis entre as definições existentes no padrão XML Schema e a sua semântica associada são fatores de difícil tratamento. Ao invés de tentar mapear todas as construções do padrão XML Schema, a proposta se fundamenta em um subconjunto de uso mais freqüente determinado a partir de levantamentos estatísticos realizados sobre XSDs coletadas da Web. A análise é feita considerando-se todas as construções e é aprofundada para aquelas identificadas como mais utilizadas. Tendo-se como base o padrão SQL:1999, serão determinadas quais as definições XML Schema são implementáveis em SQL. 1.3 Trabalhos Relacionados O gerenciamento de dados XML por meio de SGBDs tem sido amplamente discutido nos últimos anos. A principal questão tratada se refere às estratégias usadas para armazenamento desses dados, tendo sido propostas diversas abordagens com essa finalidade [2, 5, 9, 13, 18, 19, 27, 29, 30, 34], as quais podem ser analisadas sob diferentes dimensões. Primeiramente, podemos distinguir aquelas que não dependem da existência de qualquer definição prévia da estrutura do documento XML considerado, como, por exemplo, as abordagens propostas por Florescu e Kossmann [13], Deutsch et al. [9], Shimura et al. [28], daquelas que dependem dessa definição, seja ela por meio de 3

15 uma DTD [18, 29] ou do padrão XML Schema [2, 19, 34]. Ainda neste contexto, é importante destacar aquelas abordagens que procuram capturar a semântica dos dados XML por meio de restrições de integridade [18, 19]. Finalmente, podemos analisar as abordagens sob o ponto de vista da plataforma tecnológica utilizada, sendo que a plataforma relacional é ainda a mais difundida [2, 5, 9, 13, 18, 19, 29, 34], embora existam esforços no sentido de se utilizar a plataforma objeto-relacional [30] ou mesmo plataformas nativas [15, 31]. Um estudo comparativo dessas diversas abordagens pode ser encontrado em [5] e Tian et al. [32] avaliam várias estratégias de armazenamento. Propostas de mapeamento que partem de documentos XML sem um esquema associado são mais genéricas por não requererem o tratamento de definições específicas das linguagens de esquema, considerando apenas as construções XML mais simples que são os elementos e atributos. Para isso, geralmente armazenam dados não-relacionados em um mesmo local, o que dificulta a recuperação e compreensão semântica dos mesmos [13, 30]. Shimura et al. propõem que as tabelas Element, Attribute, Text e Path contenham os dados de um ou mais documentos, sem prover esquemas de banco de dados diferenciados de acordo com a estrutura de cada um. Florescu e Kossmann seguem a mesma idéia e apresentam três soluções possíveis que se diferenciam pelos esquemas propostos em cada caso. Neste último caso, a vantagem é a possibilidade de reconstruir os documentos originais, entretanto o desempenho é prejudicado devido à necessidade de realização de muitas junções entre as tabelas envolvidas. Uma alternativa é extrair um esquema a partir de um ou mais documentos XML [9, 25], sendo que até mesmo técnicas de data-mining (mineração de dados) vêm sendo aplicadas com essa finalidade [9]. Os mapeamentos fundamentados em esquemas XML são mais freqüentes e provêem uma solução específica para cada contexto. Para cada esquema XML, é gerado um esquema de banco de dados [2, 18, 19, 29, 34], já que um mesmo esquema pode descrever a estrutura de vários documentos XML ao mesmo tempo. Esta também foi a opção adotada neste trabalho. As abordagens que têm DTDs como base mostram-se mais simples por precisarem tratar poucas construções, estando <!ELEMENT...> e <!ATTLIST...> dentre as mais importantes. Nessas abordagens, a complexidade reside em tratar as expressões regulares que descrevem o conteúdo de elementos e atributos, como em [29], que tomou como base simplificações e equivalências das expressões regulares de uma DTD. A riqueza semântica do padrão XML Schema, entretanto, introduz uma maior 4

16 complexidade para as estratégias de mapeamento. A estratégia proposta em [34], por exemplo, considera a representação relacional de poucas construções do padrão, não contemplando, portanto, construções mais complexas derivadas da combinação entre as definições existentes. Além disso, essa estratégia, ao contrário da nossa, não efetua nenhum tratamento diferenciado para os construtores de composição (compositors) possíveis para um tipo complexo. As diversas construções possíveis não são discutidas, o que leva a uma visão parcial do problema. A formalização de uma estratégia de mapeamento para conversão de definições XML Schema em esquemas relacionais é proposta por Mani e Lee em [19]. Esse trabalho tem como base as gramáticas de árvores regulares (regular tree grammars) e prevê a manutenção de restrições semânticas especificadas nas definições XML Schema. Assim como na abordagem descrita nesta dissertação, propõe simplificações para facilitar o mapeamento de XSDs e faz uso da técnica de inlining, entretanto esta é aplicada na geração de esquemas relacionais e não diretamente na XSD a ser mapeada, conforme será descrito nesta dissertação. Como solução específica, tem-se os SGBDs XML nativos com estrutura exclusivamente destinada à manipulação de documentos XML [15, 31]. Entretanto seu uso ainda não está difundido e algumas razões possíveis são a falta de padronização, o que possibilita soluções diferenciadas entre os fabricantes e deixa o usuário dependente do produto, e a impossibilidade de uso com sistemas que não manipulam dados em formato XML. Esta última razão obrigaria o usuário a utilizar também um outro SGBD, acarretando custos e maior complexidade de desenvolvimento. Ao se armazenar dados XML por meio de SGBDs relacionais, ou mesmo objetorelacionais, a maioria das abordagens citadas procura preservar a semântica dos dados mapeando cada elemento, com seus respectivos sub-elementos e atributos, para uma ou mais tabelas, representando os relacionamentos entre eles através de chaves estrangeiras [5, 18, 19, 29]. Essa estratégia, embora simples de implementar, causa uma fragmentação dos dados que geralmente leva a um número muito grande de tabelas e, portanto, a problemas de desempenho ao se manipular o banco de dados resultante. Para amenizar esse problema, Shanmugasudaram et al. [29] propõem uma técnica, denominada inlining, que consiste em, sempre que possível, agregar em uma mesma tabela todos os elementos descendentes de um determinado elemento, de forma a reduzir o número de tabelas geradas no banco de dados. Essa técnica, que também é usada por Lee e Chu [18], permeia a idéia central do nosso algoritmo permitindo otimizar o esquema SQL:1999 gerado a partir de uma definição XML Schema. No outro 5

17 extremo, também é possível considerar um documento XML como uma grande cadeia de caracteres e armazená-lo em um único campo, do tipo BLOB (Binary Long Object), por exemplo. Um dos trabalhos encontrados que faz uso de um SGBD objeto-relacional [30] utiliza apenas tabelas relacionais, sem explorar a criação de tipos abstratos, que é exatamente o diferencial entre um SGBD relacional e outro objeto-relacional. Por sua vez, Runapongsa e Patel [27] apresentam uma abordagem que parte de uma DTD para a realização de mapeamentos em um sistema objeto-relacional. Uma maior flexibilidade no mapeamento pode ser obtida com uso das ferramentas ShreX [2] e LegoDB [5]. No primeiro caso, essa flexibilidade é conseqüência de anotações introduzidas nas definições XML Schema, possibilitando o uso de diferentes estratégias de mapeamento. Com SherX, o problema é tratado de forma semiautomática e requer a intervenção do usuário para direcionar os mapeamentos desejados, por meio de anotações nas definições XML Schema. Já o LegoDB explora diversas possibilidades de mapeamento e seleciona a que melhor se adequa a uma determinada aplicação com base em estimativas de custo para acesso ao banco de dados. Finalmente, é importante ressaltar os recentes estudos que têm sido realizados no sentido de compreender melhor como as linguagens de definição de esquemas para dados XML têm sido utilizadas na prática. Lee e Chu [17] apresentam uma análise comparativa de seis dessas linguagens. Bex et al. [3] apresentam um estudo comparativo sobre DTDs e XSDs encontradas na Web. Por último, Mignet et al. [23] apresentam um estudo sobre as características dos documentos XML encontrados na Web. Dentro deste contexto, o nosso trabalho procura contribuir propondo uma estratégia para mapeamento de definições XML Schema para esquemas SQL:1999 que leva em consideração as principais construções utilizadas na prática e a adequada representação, no sentido de preservar a semântica, dessas construções em termos do padrão SQL:1999. Na literatura pesquisada, não foi encontrado nenhum trabalho que trata do mapeamento de definições XML Schema para o padrão SQL:1999, o que motivou o desenvolvimento desta proposta especialmente devido às diversas possibilidades de combinação entre as definições existentes no padrão XML Schema e à complexidade da sua representação em uma linguagem com maior poder de expressão. Além de apresentar características positivas de outros trabalhos, como, por exemplo, o uso da técnica de inlining para diminuir a fragmentação dos dados, esta proposta toma como base levantamentos de conteúdo de XSDs e faz uso de abstrações presentes no padrão 6

18 SQL:1999 para a representação das restrições. A escolha pelo padrão SQL:1999 torna a solução independente de implementações de SGBDs. Uma outra característica relevante é ser uma abordagem automática, não requerendo a intervenção do usuário em nenhum momento. 1.4 Contribuições A principal contribuição deste trabalho é um algoritmo para mapeamento de definições XML Schema em SQL:1999, de forma a possibilitar o armazenamento dos dados, procurando-se manter as restrições originais. Tal proposta não foi encontrada na literatura pesquisada, já que a maioria dos trabalhos relacionados foca no modelo relacional. Para melhor compreender o escopo do problema e identificar as construções utilizadas na prática, foi realizado um levantamento estatístico sobre o conteúdo das XSDs criadas atualmente, o que também é uma contribuição relevante. Com isso, foi obtida uma análise das construções efetivamente utilizadas na prática, o que reflete a importância de cada uma delas. 1.5 Organização da Dissertação A dissertação a seguir está organizada da seguinte forma. O Capítulo 2 apresenta os principais conceitos e trabalhos relacionados aos padrões XML, XML Schema e SQL:1999. No Capítulo 3 a abordagem proposta é descrita, sendo apresentadas as estatísticas levantadas sobre o conteúdo de XSDs e o algoritmo desenvolvido para mapeamento de XSDs para esquemas SQL:1999. O Capítulo 4 descreve os resultados obtidos na validação do algoritmo de mapeamento. Finalmente, o Capítulo 5 apresenta as conclusões e trabalhos futuros. 7

19 2 Conceitos Relacionados Neste capítulo, são discutidos os principais conceitos relacionados ao trabalho, de forma a possibilitar uma melhor compreensão sobre os tópicos abordados. Alguns termos citados mais adiante no texto são apresentados aqui. 2.1 XML XML (extensible Markup Language) [38] é uma linguagem simples para a formatação, derivada do padrão SGML (Standard Generalized Markup Language) [40]. Desenvolvida pelo XML Working Group em 1996, tornou-se uma recomendação do W3C (World Wide Web Consortium) em 1998 e atualmente está na versão 1.1. A linguagem descreve as regras de formação, em termos de sintaxe, de uma classe de objetos de dados, chamados de documentos XML. Os blocos de construção desses documentos são os elementos, delimitados por marcadores (tags), um de abertura e outro de fechamento, ou representados por um único marcador vazio. No marcador de abertura, é possível adicionar mais informações sobre um elemento na forma de atributos, que são pares nome-valor [26]. A Figura 2.1 mostra o elemento cantor, com seus marcadores de abertura e fechamento e com o atributo estado, cujo valor é Bahia. Um elemento pode conter outros elementos ou texto e, embora seja menos comum, a ocorrência de ambos ao mesmo tempo também é possível, o que recebe o nome de conteúdo misto (Figura 2.5). <cantor estado= Bahia >Caetano Veloso</cantor> Figura 2.1. Exemplo de elemento e atributo. Em XML, os dados e sua descrição são encontrados em um mesmo local, o que faz desse padrão um formato auto-descritivo e simples. Adicionalmente, XML é baseada em texto e não necessita de processamento específico [14], ao contrário de outros formatos binários, o que implica em portabilidade e maior segurança já que os dados 8

20 não são tão facilmente corrompidos. Nesse contexto, a leitura e o processamento de documentos torna-se fácil, tanto por pessoas quanto por sistemas de software. XML é um padrão rígido no sentido de estabelecer regras sintáticas bem-definidas para a edição de documentos XML, contendo a sua especificação [38] mais de uma centena dessas regras. Em termos gerais, essa especificação descreve como os marcadores e seus atributos devem estar dispostos, quais identificadores são válidos e como é a estrutura de um documento. Um documento é dito bem-formado quando todos os critérios são obedecidos. Alguns desses critérios são: 1. Um documento deve possuir um e apenas um elemento-raiz, também chamado de elemento do documento, que contém todos os outros elementos [14]. A Figura 2.2 mostra um exemplo de documento XML que não está em conformidade com esta regra. <?xml version= 1.0?> <cantor>caetano Veloso</cantor> <cantora>ivete Sangalo</cantora> Figura 2.2. Documento XML com dois elementos-raiz. 2. Todo marcador de abertura deve ter o seu correspondente de fechamento. 3. O aninhamento entre elementos é possível sem que haja sobreposição entre eles. Na Figura 2.3, é mostrada uma versão válida e outra inválida do mesmo documento. <?xml version= 1.0?> <cantor> <nome>gilberto Gil</nome> </cantor> <?xml version= 1.0?> <cantor> <nome>gilberto Gil</cantor> </nome> (a) válido (b) inválido Figura 2.3. Aninhamento entre elementos. 4. Todo valor de atributo deve estar delimitado por aspas simples ou duplas. A conformidade de documentos XML com as regras de boa-formação é especialmente importante para o seu processamento por sistemas, visto que a falta de 9

21 padronização dificulta a identificação e, conseqüentemente, a extração das informações relevantes. Uma outra questão importante é que, em XML, a ordem em que os elementos aparecem é relevante, mas dos atributos, não. Ao mesmo tempo em que estabelece um formato rígido para a representação de informações, é bastante flexível por possibilitar a criação de marcadores de acordo com as necessidades de cada aplicação e permitir a disposição de um mesmo conjunto de dados sob uma infinidade de maneiras distintas. Essas características fazem de XML um formato adequado para uso em diversas áreas do conhecimento, podendo ser utilizado para o armazenamento de dados ou documentos. Neste caso, os documentos criados são ditos orientados a dados (data-centric) ou orientados a documentos (document-centric), respectivamente [6]. Documentos orientados a dados (Figura 2.4) possuem uma estrutura mais regular e granularidade mais fina, ou seja, os dados estão divididos em porções menores. No outro extremo, a abordagem de orientação a documentos (Figura 2.5) resulta em uma estrutura irregular ou inexistente, com granularidade maior e bastante conteúdo misto [6]. <?xml version= 1.0 encoding= UTF-7?> <biblioteca> <livro> <titulo>todas as Comédias</titulo> <autor>luiz Fernando Veríssimo</autor> </livro> <livro> <titulo>o Senhor dos Anéis</titulo> <autor>j.r.r. Tolkien </autor> </livro> </biblioteca> Figura 2.4. Documento XML orientado a dados. Um documento XML pode ser o resultado da combinação de marcação de várias fontes e para evitar ambigüidade entre nomes, decorrente do uso de um mesmo termo com significados diferentes, foi criado o conceito de espaço de nomes (namespace). Um espaço de nomes é um grupo de nomes de elementos e atributos. Na prática, declara-se que um elemento ou atributo existe em um determinado espaço nomes anexando-se um prefixo a eles [26] e um documento pode utilizar vários espaços de nomes ao mesmo tempo. 10

22 <?xml version= 1.0 encoding= UTF-7?> <filme><nome>guerra dos Mundos</nome> é um <tipo>romance de ficção científica</tipo> estrelado por <ator>tom Cruise</ator> </filme> Figura 2.5. Documento XML orientado a documento Árvores XML Documentos XML bem-formados podem ser representados como uma árvore [1], onde elementos e atributos correspondem aos nós da árvore. Assim, é comum usar o termo nó como sinônimo para elementos e atributos, sendo que os nós-texto ou nósfolha são aqueles que não possuem descendentes e correspondem aos valores associados aos elementos e atributos. Analisadores sintáticos, também conhecidos como processadores XML, têm o papel de verificar se um documento XML é bem-formado e transformá-lo para uma representação em árvore (por exemplo, de acordo com o formato DOM Document Object Model [37]) Esquemas XML Conforme visto, ao ser usado sozinho, XML é um padrão que permite muita liberdade para a criação de documentos, o que nem sempre é uma vantagem. Em situações que requerem a apresentação da informação em um formato definido, é necessário fazer uso de linguagens de esquema XML, que têm a finalidade de formalizar as restrições que se aplicam a uma classe de documentos XML [35]. Um documento que obedece às restrições de um determinado esquema é dito ser válido em relação a esse esquema [1, 35]. Um esquema XML define uma classe de documentos e pode ser escrito em diversas linguagens, destacando-se Document Type Definition (DTD) [1, 38] e o padrão W3C XML Schema [42]. As DTDs surgiram primeiro, ainda para uso com SGML, e são bastante populares para a definição de esquemas XML [23]. Possuem poucas construções para a especificação da estrutura de um documento XML, que basicamente é feita através da definição de um conjunto de elementos permitidos e do seu conteúdo, e da declaração de um conjunto de atributos possíveis para cada elemento [26]. DTDs possuem algumas limitações, como a inexistência de um sistema de tipos, impossibilidade de 11

23 representação exata da cardinalidade de elementos, poucos recursos para a especificação do conteúdo dos elementos, dentre outros. Para atender à demanda emergente dos desenvolvedores de software por novos recursos para a representação de dados, o W3C trabalhou durante dois anos na elaboração de uma nova linguagem para a descrição de documentos XML [35], a XML Schema Language, cujos detalhes serão abordados na Seção XML Schema Lançada em 2001 como uma recomendação do W3C, XML Schema é uma especificação bastante extensa e tem o propósito de contemplar uma ampla variedade de usos. É consideravelmente maior e mais complexa do que a própria especificação do padrão XML [14]. Assim, a seguir serão descritos apenas os conceitos fundamentais e que são utilizados no texto. A estrutura e restrições de conteúdo de uma classe de documentos XML são definidas por meio de uma XSD (XML Schema Definition), ou seja, um documento escrito de acordo com a especificação XML Schema, que também é chamado simplesmente de um XML Schema. Seguindo esta terminologia, os documentos XML desta classe são também denominados documentos-instância [45]. Uma característica importante do padrão XML Schema é a utilização da sintaxe XML para sua definição, o que significa que uma XSD é também um documento XML. Sendo assim, devem seguir as regras de formação de um documento XML e ser manipulados como tal, em oposição às DTDs. Por exemplo, APIs que implementam DOM (Document Object Model) [37] podem ser diretamente utilizadas para processar XSDs, abordagem que é utilizada neste trabalho Estrutura O elemento-raiz de toda XSD é schema, que irá conter as outras declarações e deve pertencer ao espaço de nomes padrão, representado pela URI (Universal Resource Identificator) [39] Esta associação é realizada com o atributo xmlns, freqüentemente com um prefixo representando o espaço de nomes dentro da XSD. Todas as outras construções pertencentes ao espaço de nomes padrão devem utilizar o mesmo prefixo, caso contrário não serão reconhecidas. É possível também atribuir um espaço de nomes para um esquema, com o uso do atributo targetnamespace no elemento schema. As duas situações são ilustradas na Figura 12

24 2.6. Adicionalmente, as definições que são declaradas imediatamente abaixo do elemento schema desempenham um papel especial, pois podem ser referenciadas de qualquer lugar do esquema, e por isso são consideradas globais [45]. <?xml version= 1.0?> <xs:schema xmlns:xs= targetnamespace= meuespaco >... </xs:schema> Figura 2.6. Associação do prefixo xs ao espaço de nomes padrão. Embora uma DTD por si só não indique qual é o elemento-raiz dos documentos que valida, a declaração de tipo de documento (Document Type Declaration) [38], existente em um documento XML, contém ou aponta para uma DTD e determina qual é o elemento-raiz do documento em questão, dentre aqueles que foram previamente declarados. Em XML Schema, não há um recurso semelhante, levando à possibilidade de que um ou mais elementos sejam candidatos à raiz, bastando que sejam elementos globais. Logo, uma instância pode ter como raiz quaisquer desses elementos. Um XML Schema é definido como um conjunto de componentes de esquema. No total, há treze tipos de componentes divididos em três grupos [42]: 1. Componentes primários (primary components): definições de tipo simples, definições de tipo complexo, declarações de atributo, declarações de elementos, sendo que elementos e atributos devem ter um nome e no caso dos tipos, é opcional. 2. Componentes secundários (secondary components): definições de grupo de atributos, definições de restrição de identidade, definições de grupo de modelo (model group), declarações notation. Todos esses componentes devem ter necessariamente um nome. 3. Componentes de apoio ( helper ): anotações, grupos de modelo, partículas, curingas e usos de atributo (attribute uses). Componentes desse tipo não são independentes, pois fazem parte de outros. As instâncias de esquemas (documentos XML) possuem apenas elementos e atributos, representados pelas construções element e attribute em XML Schema, logo todos os componentes têm o propósito de colaborar, direta ou indiretamente, para a 13

25 sua especificação de conteúdo. Deve existir pelo menos uma definição element global na XSD para que a instância associada contenha dados. XML Schema apresenta recursos para a definição de tipos de elementos e atributos, de forma que o conteúdo desses componentes não é validado apenas como texto. Modelos de conteúdo caracterizam elementos em termos de elementos-filho e nóstexto que contém. O modelo de conteúdo é vazio quando não tem nós-texto nem elementos-filho, simples quando apenas nós-texto são aceitos, complexo quando somente sub-elementos são esperados e mistos quando tanto elementos texto quanto sub-elementos estão presentes [35]. A Tabela 2.1 sumariza essas regras. Na prática, as possibilidades para a declaração de elementos são associá-lo a um tipo simples, complexo ou declará-lo como vazio. Modelo de conteúdo Misto Complexo Simples Vazio Elementos-filho Sim Sim Não Não Elementos de texto Sim Não Sim Não Tabela 2.1. Modelos de conteúdo. Fonte: [35]. Tipos simples são aqueles que não são compostos por atributos nem por elementos, se encaixando na classificação de modelo de conteúdo simples. Tanto os tipos simples pré-definidos quanto os definidos pelo usuário representam um conjunto de dados, o que seria um domínio no contexto dos bancos de dados relacionais. No segundo caso, a construção simpletype é utilizada juntamente com outras definições específicas e os tipos criados podem ser referenciados em várias partes do esquema, através de seu nome, como tipos de elementos e atributos. Na Figura 2.7, o elemento nome tem como tipo string, do espaço de nomes padrão, e o elemento apelido contém uma referência ao tipo simples nomecurto. <?xml version= 1.0?> <xs:schema xmlns:xs= > <xs:simpletype name= nomecurto > <xs:restriction base= xs:string > <xs:maxlength value= 10 /> </xd:restriction> </xs:simpletype> <xs:element name= apelido type= nomecurto /> <xs:element name= nome type= xs:string /> </xs:schema> Figura 2.7. Uso de tipos simples. 14

26 Para ser caracterizado como complexo, um tipo deve conter atributos ou elementos na sua declaração e sua definição é realizada com a construção complextype. É possível simplesmente criar tipos complexos ou derivá-los a partir de outro previamente declarado. Se um tipo complexo é derivado de um tipo simples e são adicionados atributos, sem que tenha elementos-filho, tem-se um tipo complexo com modelo de conteúdo simples (Figura 2.8).... <xs:complextype name= cliente > <xs:simplecontent> <xs:extension base= xs:string > <xs:attribute name= cpf type= integer /> </xs:extension> </xs:simplecontent> </xs:complextype>... Figura 2.8. Declaração de tipo complexo com modelo de conteúdo simples. Modelos de conteúdo complexo necessariamente devem possuir elementos-filho e a presença de atributos é opcional. A definição complexcontent é usada para indicar a derivação de um tipo complexo com modelo de conteúdo complexo. As possibilidades para derivação de tipos são: derivação por extensão, adicionandose atributos ou elementos a um tipo existente, ou derivação por restrição, limitando-se o domínio dos campos existentes, no caso dos tipos complexos e restringindo ainda mais o tipo que está sendo criado, no caso de tipos simples. É direto notar que a derivação por extensão só resulta na formação de tipos complexos. A base para a formação dos modelos de conteúdo complexo é o uso de construtores de composição (compositors), ou simplesmente construtores, que são sequence, choice e all. Para se estabelecer ordem entre elementos, usa-se o construtor sequence. A escolha de um elemento a partir de outros é definida com choice. Por último, all define que os elementos podem aparecer em qualquer ordem, em diversas combinações possíveis. Definições declaradas sob esses construtores de composição desempenham o papel de partículas, o que é mais comum com definições element, entretanto outras possibilidades incluem choice, sequence, any e group. Nos dois primeiros casos, ter-se-ia aninhamento entre construtores de composição, levando à especificação de estruturas mais complexas. Observa-se que all não pode desempenhar o papel de partícula, de acordo com a especificação XML Schema e também não pode 15

27 ter outros construtores de composição como suas partículas, sendo algumas das restrições relativas ao seu uso.... <xs:element name= cantor > <xs:complextype> <xs:choice> <xs:element name= MPB type= xs:string /> <xs:element name= rock type= xs:string /> </xs:choice> </xs:complextype> </xs:element> <cantor> <MPB>Caetano Veloso</MPB> </cantor>... Figura 2.9. Uso de choice em XSD e uma instância correspondente.... <xs:attributegroup name= documentos > <xs:attribute name= rg type= xs:integer /> <xs:attribute name= cpf type= xs:integer /> </xs:attributegroup> <xs:group name= dados > <xs:sequence> <xs:element name= nome type= xs:string /> <xs:element name= nascimento type= xs:date /> </xs:sequence> </xs:group> <xs:element name= cliente > <xs:group ref= dados /> <xs:attributegroup ref= documentos /> </xs:element> <cliente rg= cpf= > <nome>patrícia Martins</nome> <nascimento> </nascimento> </cliente>... Figura Uso de group e attributegroup e uma instância correspondente. Para definir a cardinalidade de partículas e construtores de composição, existem os atributos minoccurs e maxoccurs, para o número mínimo e máximo de ocorrências, respectivamente. Quando ausentes, assumem o valor 1 por padrão. Números inteiros são 16

28 valores válidos para esses atributos e a palavra unbounded também pode ser usada, representando uma quantidade ilimitada. O componente secundário group permite a reutilização de declarações de conjuntos de elementos, evitando a repetição de código. Essa definição sempre deve ter um nome a fim de ser referenciada em partes do documento. De forma análoga, attributegroup agrupa atributos que estejam relacionados entre si. No documento XML, o efeito do uso dessas definições é o mesmo que se a referência a elas fossem substituídas pelo seu conteúdo. As principais definições de restrição de identidade são key, keyref e unique, sendo que as demais compõem as construções acima. Basicamente, key e keyref permitem especificar como porções do documento podem ser identificadas unicamente, de uma maneira bastante flexível e tendo como base XPath. Com keyref, essas porções podem ser referenciadas e sua validade é verificada na validação do documento, o que não ocorre com ID e IDREF em DTDs. Declarações notation provêem um mecanismo [4] para a localização de programas externos ou instruções de processamento. Como não estão relacionadas ao escopo deste trabalho, não serão detalhadas. Os componentes de apoio restantes são usos de atributo, anotações e curingas. Usos de atributo são um nome abstrato para representar restrições impostas a declarações de atributos, como a especificação de um valor padrão ou fixo, com os atributos default e fixed de element e a obrigatoriedade de uso com o atributo required. Conforme esperado, XML Schema oferece recursos para a documentação de uma XSD e, para isso, existem as definições annotation, documentation e appinfo. Grande flexibilidade pode ser alcançada com any e anyattribute. Denominadas curingas, essas definições podem substituir quaisquer elementos e atributos, respectivamente, que estejam em um espaço de nomes cuja URI é o valor do atributo namespace. Analisando-se as características do padrão XML Schema, pode-se perceber que alguns dos seus conceitos foram extraídos do paradigma de orientação a objetos. Por exemplo, elementos são semelhantes a objetos e a derivação de tipos é análoga à herança, enquanto tipos complexos seriam as classes e os elementos, objetos. 17

29 2.3 SQL SQL:1999 O padrão SQL:1999, também chamado de SQL3, apresenta diversos recursos novos quando comparado ao anterior (SQL-92), principalmente relacionados à tecnologia de orientação a objetos [10]. Isto se mostrou muito útil para o algoritmo proposto mais adiante, uma vez que permite um nível maior de abstração e um mapeamento mais direto a partir das definições XML Schema. As novas características não se limitam à orientação a objetos, há avanços também em direção ao núcleo relacional do padrão. Será feito a seguir um breve resumo das facilidades, com foco naquelas que são úteis a este trabalho. Foram adicionados ao padrão SQL:1999 tipos compostos, ARRAY (Figura 2.11) e ROW, com os quais é possível armazenar coleções de valores diretamente na coluna de uma tabela, violando então a primeira forma normal [10]. Assim, outras formas de representação dos relacionamentos entre dados são permitidas. Além dos recursos para garantia de restrições de integridade já presentes nos padrões anteriores, como cláusulas CHECK, asserções e chaves estrangeiras, considerados mecanismos declarativos, os gatilhos (triggers) foram definidos formalmente a partir do padrão SQL:1999. Gatilhos são procedimentos disparados automaticamente pelo SGBD em resposta a determinados eventos previamente especificados [33]. A sua flexibilidade é importante para garantir regras de integridade que não seriam possíveis com outros recursos (cláusulas CHECK, NOT NULL, UNIQUE, chaves primárias e estrangeiras, asserções, etc.) e isso se deve, em parte, à sua natureza procedimental. Embora sua aplicação seja recomendada em algumas situações, no geral o seu uso deve ser realizado somente se uma restrição de integridade não puder ser expressa apropriadamente de forma declarativa [33]. Algumas razões para isso são a dificuldade de manutenção e a possibilidade de disparo em cascata de forma não prevista. CREATE TYPE cantor AS ( nome VARCHAR(255), musicas VARCHAR(255) ARRAY[100] ) NOT FINAL REF IS SYSTEM GENERATED; Figura 2.11 Tipo estruturado com atributo de tipo ARRAY. 18

30 A principal inovação no padrão SQL:1999 é a sua aderência ao paradigma de orientação a objetos, manisfestado na especificação de tipos definidos pelo usuário (User Defined Types - UDTs), dos quais há duas variações: structured types, referenciados no texto como tipos estruturados, e distinct types [22]. De forma resumida, distinct type é um tipo de dados baseado em um tipo pré-definido e tipos estruturados são a variação mais importante no contexto de orientação a objetos. Tipos estruturados permitem a criação de tipos com um ou mais atributos (Figura 2.11), os quais só não podem ser do tipo atual, que está sendo definido [22]. Em outras palavras, definições recursivas são proibidas. Ao criar um tipo estruturado, deve-se especificar se podem ser criados sub-tipos desse tipo ou não. A cláusula [NOT] FINAL tem esse papel. Opcionalmente, é possível indicar se o identificador de um objeto desse tipo é gerado pelo sistema, com a cláusula REF IS SYSTEM GENERATED. CREATE TYPE cantoraxe UNDER cantor AS( blococarnaval VARCHAR(50) ) FINAL; Figura Herança de tipo estruturado (subtipo) Para fazer uso dos tipos estruturados, ou seja, ter instâncias, deve-se criar Tabelas de Tipos (Typed Tables) que se baseiem no tipo referido, como na Figura Assim, cada linha da tabela será uma instância (objeto) do seu tipo estruturado associado e possui um identificador único (coluna self-referencing) [21]. CREATE TABLE cantortable OF cantor( REF IS cantorid SYSTEM GENERATED ); Figura Tabela de tipos. REF é um tipo especial introduzido em SQL:1999 e o valor de um atributo deste tipo é um identificador único, localizado na coluna self-referencing (Figura 2.13) ou fazendo referência a uma instância do tipo estruturado associado (Figura 2.14). Tipos REF têm comportamento semelhante à restrição de integridade referencial [10], sendo possível garantir que as referências não fiquem quebradas, com as cláusulas 19

31 REFERENCES ARE CHECKED e SCOPE. Dessa forma, são uma opção alternativa para representar relacionamentos entre dados. CREATE TYPE banda AS (... vocalista REF(cantor) REFERENCES ARE CHECKED... ) NOT FINAL REF IS SYSTEM GENERATED; CREATE TABLE bandatable OF banda (... vocalista WITH OPTIONS SCOPE cantortable... ); Figura Uso de tipo REF SQL:2003 Dentre as novidades presentes no padrão SQL:2003 [11], está a Part 14: XML- Related Specificactions (SQL/XML) [12], que define um mapeamento de tabelas para documentos XML, abordagem exatamente oposta à que será discutida no capítulo seguinte. O tipo XML e operadores específicos foram adicionados (XMLELEMENT, XMLFOREST, etc.), provendo uma manipulação mais direta de documentos XML, em oposição ao armazenamento em campos BLOB [12]. Foram feitas revisões no padrão SQL:1999 e adicionados dois tipos de dados além do XML: BIGINT e MULTISET. BIGINT é um tipo numérico semelhante a INTEGER e SMALLINT, a única diferença é que apresenta uma precisão maior. MULTISET é um tipo coleção similar a ARRAY, exceto por não ter ordem implícita [11]. As demais mudanças foram pequenas melhorias localizadas, como a adição de funções, geração de seqüências e assim por diante. 20