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

Transcrição

1 Mapeamento de Definições XML Schema para SQL:1999 Patrícia Martins, Alberto H. F. Laender Departamento de Ciência da Computação Universidade Federal de Minas Gerais Belo Horizonte MG Brasil Resumo. Este artigo apresenta um algoritmo para mapear definições do padrão W3C XML Schema em esquemas SQL:1999. A escolha pelo 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. O algoritmo trata questões fundamentais como a preservação da ordem e da cardinalidade dos elementos, e utiliza a técnica de inlining para reduzir a fragmentação dos dados nas tabelas criadas. Abstract. This paper 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 the inlining technique to reduce data fragmentation in the created tables. 1. Introdução Atualmente, um grande volume de dados é representado como documentos XML [25] que apresentam estrutura cada vez mais complexa. Com isso, é notória a necessidade de facilidades para armazenamento, consulta e atualizaçã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 SGBDs relacionais (SGBDRs), o que decorre do oferecimento de recursos amplamente utilizados e testados por mais de duas décadas. Uma opção natural seria o uso de SGBDs orientados a objetos (SGBDOOs). Entretanto, esses sistemas ainda não estão suficientemente maduros [8], especialmente com relação a desempenho, para comportar grandes volumes de dados. Uma opção intermediária, e utilizada atualmente por diversos produtos comerciais disponíveis, são os sistemas objeto-relacionais [22], que por possibilitar a representação de tipos abstratos, se mostram adequados para o armazenamento de dados XML. A linguagem padrão adotada pelos SGBDs relacionais e objeto-relacionais é SQL (Structured Query Language). Desde o seu surgimento, vários padrões foram publicados: SQL-86, SQL-89, SQL-92, SQL:1999 [14, 15] e SQL:2003 [7]. Até o padrão SQL-92, apenas eram oferecidos recursos derivados do modelo relacional, enquanto o padrão SQL:1999 adicionou características de orientação a objetos e outras facilidades, sendo assim a base dos sistemas objeto-

2 relacionais. Por sua vez, o padrão SQL:2003 faz revisões ao SQL:1999 e adiciona uma nova parte, denominada SQL/XML [7]. Documentos XML opcionalmente possuem esquemas que os descrevem, especificando restrições estruturais e semânticas. Um esquema XML define uma classe de documentos e pode ser escrito em diversas linguagens [11], destacando-se Document Type Definition (DTD) [1] e o padrão W3C XML Schema [26], sendo esta última mais expressiva. Por terem propósito semelhante aos esquemas de bancos de dados, ou seja, a definição da estrutura dos dados, esquemas XML são fundamentais para a extração de informações sobre a organização dos dados a serem armazenados em SGBDs, pois, caso contrário, seria necessário inferir um esquema a partir de um conjunto de documentos, o que constitui um outro problema [18]. Entretanto, poucos trabalhos discutem o armazenamento de documentos XML descritos por meio de XML Schema, já que a maioria das abordagens encontradas na literatura considera o uso de DTDs. O objetivo deste artigo é identificar as definições (também referenciadas no texto como construções) XML Schema que são úteis para a descrição de documentos XML válidos de modo que possam ser armazenados em um SGBD objeto-relacional mantendo-se a sua conformidade com o esquema associado. Para isso, é proposto um algoritmo 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 validade dos dados correspondentes em relação às restrições de integridade especificadas no padrão SQL:1999. 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. É importante ressaltar, ainda, que não foi encontrado na literatura nenhum trabalho que descreva o mapeamento de definições XML Schema para o padrão SQL:1999, o que motivou o desenvolvimento desta proposta. O artigo está organizado da seguinte forma. Na Seção 2, são tratados os trabalhos relacionados ao tema. A abordagem proposta é descrita na Seção 3, onde são discutidos os conceitos associados e o algoritmo de mapeamento proposto. A Seção 4 discute um exemplo de mapeamento e, finalmente, a Seção 5 apresenta as conclusões. 2. 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, 4, 5, 8, 12, 13, 19, 20, 23]. Uma análise dessas abordagens pode ser feita 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, a abordagem proposta por Florescu e Kossmann [8], daquelas que dependem dessa definição, seja ela por meio de uma DTD [12, 19] ou do padrão XML Schema [2, 13, 23]. Ainda neste contexto, é importante destacar aquelas abordagens que procuram capturar a semântica dos dados XML por meio de restrições de integridade [12, 13]. 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, 4, 5, 8, 12, 13, 19, 23], embora existam esforços no sentido de se utilizar a plataforma objeto-relacional [20] ou mesmo plataformas nativas [9, 21]. Um estudo comparativo dessas diversas abordagens pode ser encontrado em [4]. 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 tabela, representando os relacionamentos entre eles através de chaves estrangeiras [4, 12, 13, 19]. Essa estratégia, embora simples de implementar, causa uma fragmentação dos dados que geralmente leva a um

3 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. [19] 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 [12], permeia a idéia central do nosso algoritmo permitindo otimizar o esquema SQL:1999 gerado a partir de uma definição XML Schema. A riqueza semântica do padrão XML Schema, entretanto, introduz uma maior complexidade para as estratégias de mapeamento. A estratégia proposta em [23], 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. A formalização de uma estratégia de mapeamento para conversão de definições XML Schema em esquemas relacionais é proposta por Murani e Lee em [13]. Esse trabalho tem como base gramáticas de árvores regulares (regular tree grammars) e prevê a manutenção de restrições semânticas especificadas nas definições XML Schema. Uma maior flexibilidade no mapeamento pode ser obtida com uso das ferramentas ShreX [2] e LegoDB [4]. 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. 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 [11] 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. [16] 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 dessas construções em termos do padrão SQL: Descrição da Abordagem A fim de possibilitar uma melhor compreensão da abordagem proposta, primeiramente será dada uma visão geral das características dos padrões XML Schema e SQL:1999. Como XML Schema é um padrão complexo, fez-se necessário analisar o conteúdo de uma coleção de XSDs para determinar qual subconjunto de construções é utilizado na prática. O produto desta análise é um conjunto de estatísticas sobre a estrutura das XSDs. Quanto ao SQL:1999, as características adicionais em relação ao padrão anterior (SQL-92) são o foco de estudo, especialmente aquelas relacionadas à orientação a objetos XML Schema e Estatísticas Quando usado sozinho, XML é um padrão que permite muita liberdade para a criação de documentos. Em situações que requerem a apresentação da informação em um formato definido, é necessário fazer uso de linguagens de esquema XML. Com elas, é possível especificar a estrutura e as restrições de um conjunto de documentos XML. Um documento é dito válido em relação a um esquema se obedece às suas restrições [1, 24].

4 Tabela 1. Utilização de construções em XSDs. Construção Geral (%) Em XSDs (%) all 0,36 10,55 annotation 8,79 59,80 any 0,08 15,07 anyattribute 0,03 6,53 appinfo 0,08 5,53 attribute 7,89 79,40 attributegroup 1,01 8,54 choice 0,94 46,23 complexcontent 0,71 19,09 complextype 5,77 91,46 documentation 9,40 58,80 element 25,66 92,96 enumeration 19,35 56,78 extension 1,46 47,24 field 1,40 10,05 fractiondigits 0,16 2,51 group 0,47 8,04 import 0,06 14,07 include 0,01 2,51 key 0,29 7,54 keyref 0,27 5,53 length 0,02 4,52 list 0,04 5,53 maxexclusive 0,04 2,51 maxinclusive 0,40 15,07 maxlength 0,52 11,56 minexclusive 0,27 2,51 mininclusive 0,41 17,59 minlength 0,14 11,56 notation 0,00 0,50 pattern 0,93 24,62 restriction 3,31 68,34 selector 0,89 10,05 sequence 3,50 87,94 simplecontent 0,76 36,18 simpletype 3,66 68,84 totaldigits 0,17 2,51 union 0,31 5,53 unique 0,32 5,53 whitespace 0,07 4,02 Tabela 2. Distribuição de modelo de conteúdo em construções complextype. Modelo de Conteúdo Utilização Geral (%) Simples 13,11 Complexo 86,89 Tabela 3. Utilização das construções all, choice, sequence e group em modelos de conteúdo complexos Construção Utilização Geral (%) all 8,61 choice 11,52 sequence 79,35 group 0,51 Tabela 4. Uso de construtores de composição com apenas um elemento-filho. Construção Utilização Utilização em Geral (%) XSDs (%) all 14,05 4,02 choice 17,94 11,05 sequence 42,75 77,39 Tabela 5. Aninhamento em construtores de composição. Construção Aninhamento (%) choice 8,86 sequence 9,62 Tabela 6. Aninhamento de construtores de composição em XSDs. Tipo Utilização (%) com aninhamento 32,66 sem aninhamento 67,34 Várias linguagens já foram definidas com esse propósito, das quais aquelas que mais se destacam são DTD (Document Type Definition) e XML Schema [26]. O uso de DTDs para a descrição de esquemas é bastante popular [16], entretanto apresenta limitações em relação a outras linguagens de esquema. Por sua vez, XML Schema é bastante expressiva, apresentando construções que ao serem combinadas entre si geram infinitas possibilidades para a definição da estrutura de documentos XML. Alguns mecanismos XML Schema não encontram similar em DTDs, como tipos simples, derivação de tipos simples e complexos (análogo à herança em orientação a objetos), especificação do número de ocorrências de elementos-filho, namespaces (espaços de nomes), entre outras. Logo, a linguagem escolhida neste trabalho é XML Schema.

5 Entretanto, em decorrência da complexidade do padrão XML Schema, foi necessário obter algumas estatísticas relativas ao conteúdo de XSDs utilizadas na prática. Muitas construções XML Schema ainda não são efetivamente usadas [3], de modo que o propósito de se obter essas estatísticas foi verificar aquelas que são mais freqüentes e, assim, determinar o subconjunto a ser considerado para o mapeamento. Em [3] são apresentados alguns dados extraídos a partir da análise do conteúdo de XSDs encontradas na Web mas que não são adequados para a abordagem descrita neste artigo, uma vez não quantificam o uso das construções, focando a análise na formação das XSDs em termos de expressões regulares. Em uma XSD, todo tipo complexo deve possuir um construtor de composição (compositor), cujo propósito é definir a organização das construções internas, chamadas de partículas (particles), que, na maioria dos casos, são definições do tipo element. Por outro lado, elementos globais são aqueles que têm um nome e assim podem ser referenciados de qualquer parte do documento, em oposição a elementos locais, cujo escopo é limitado. Para que um esquema gere instâncias não-vazias, ele deve possuir pelo menos um elemento global. As XSDs analisadas foram obtidas a partir do Google [10] nos dias 8 e 9 de março de 2005, especificando-se o tipo de arquivo a ser encontrado. Adicionalmente, foi necessário fornecer pelo menos uma palavra-chave e a escolhida foi schema, uma vez que toda XSD deve possuir obrigatoriamente este elemento. Assim, a cadeia de caracteres resultante para a realização da busca foi schema filetype:xsd. Dentre os resultados retornados, foram coletados arquivos das cinqüenta primeiras páginas da pesquisa, sendo que cada uma contém dez ocorrências, mas apenas 199 eram válidas e foram consideradas na análise. Inicialmente, determinou-se as porcentagens de utilização geral de cada construção, ou seja, o número de ocorrências de cada definição em relação a todas as ocorrências encontradas, e seu uso nas XSDs. Da Tabela 1, observa-se que as construções que apresentam maior porcentagem de utilização são element com 92,96% e complextype com 91,46%. Assim, realizou-se uma análise mais detalhada do conteúdo das construções complextype para compreender a sua formação, especialmente quanto aos construtores de composição que utilizam. Os resultados são mostrados na Tabelas 2 e 3. Embora os construtores tenham a função de especificar a disposição das suas partículas, observa-se que é comum o uso de apenas uma partícula. Para obter dados mais específicos, esta situação também foi levantada nas amostras colhidas (Tabela 4). Adicionalmente, foram realizadas duas totalizações gerais. Uma delas mostrou que 80,40% das XSDs possui pelo menos um construtor (all, choice ou sequence) com apenas um elemento-filho. A outra chega à porcentagem de tais construtores que têm apenas um elemento-filho, que é 35,77%. A freqüência de uso de aninhamento entre construtores de composição também foi verificada, já que isto acrescenta um nível de complexidade adicional na formação de documentos XML. Para isso, determinou-se a porcentagem de aninhamento em relação a cada construtor (Tabela 5) e a porcentagem de XSDs que apresenta pelo menos um construtor com aninhamento (Tabela 6). Como a construção all não pode exercer o papel de partícula e seu conteúdo resume-se apenas a element ou annotation, apenas sequence e choice foram considerados. Dentre as XSDs coletadas, 48 (24,12%) fazem uso de construções include e import, ou seja, referenciam construções criadas em outros arquivos. Analisando-se as possíveis raízes dos 151 arquivos restantes, constatou-se que 9,93% das XSDs não permitem a criação de instâncias XML por não possuírem definições de elementos globais. De forma semelhante, há XSDs que possuem apenas um elemento passível de ser raiz, mas que é de tipo simples. Isto ocorreu em 1,99% dos casos.

6 3.2. 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 [6]. Isto se mostrou muito útil para o algoritmo proposto, 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 novas facilidades, com foco naquelas que são úteis a este trabalho. Foram adicionados tipos compostos ao padrão SQL3, ARRAY 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 [6]. Assim, outras formas de representação dos relacionamentos entre dados são permitidas. A principal inovação no padrão SQL3 é o suporte à 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 [15]. 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, os quais só não podem ser do tipo atual, que está sendo definido [15]. Em outras palavras, definições recursivas são proibidas. Como a herança de tipos é suportada no padrão SQL3, uma forma de contornar esta regra seria substituir o tipo pelo seu supertipo, no caso de haver necessidade de recursão. Assim, uma estrutura arbitrariamente complexa pode ser definida. Para fazer uso dos tipos estruturados, deve-se criar Typed Tables (tabelas de tipos) que se baseiem no tipo referido. Assim, cada linha da tabela será uma instância (objeto) do seu tipo estruturado associado e possui um identificador único (coluna self-referencing), podendo ser referenciada por atributos REF do mesmo tipo Algoritmo de Mapeamento O propósito da geração de esquemas é o armazenamento dos dados das instâncias (documentos XML) válidas em relação ao esquema referido. Assim, é direto perceber que cada XSD deve ser mapeada para um esquema SQL:1999, de forma a ser possível armazenar os dados dos documentos XML válidos sem perdas estruturais significativas. É importante salientar que apenas XSDs válidas serão consideradas, pois este é um requisito para a validação de documentos XML. Além disso, serão mapeadas apenas XSDs que não façam uso de construções contidas em outros esquemas (ver estatísticas na Seção 3.2), o que adiciona um nível extra de complexidade na implementação, quando é possível colocar todas as definições em um único esquema sem prejudicar o seu conteúdo. Conseqüentemente, os esquemas que utilizam espaços de nomes diferentes do padrão [26] também não serão considerados. Por fim, este trabalho não contempla esquemas que possam gerar conteúdo misto, que apresentem recursão, em qualquer nível, e que usem o recurso de derivação para a criação de tipos. No momento, o objetivo é prover um algoritmo para o mapeamento das construções que apresentam uso mais comum. Dentre as diversas possibilidades de combinação de construções para a geração de XSDs, aquela que apresentou maior complexidade para a representação objeto-relacional foi o aninhamento entre os construtores de composição sequence e choice. Como 32,66% dos arquivos analisados apresentam tal situação, não se deve ignorar esta possibilidade, entretanto uma simples transformação elimina a necessidade de uma solução não-trivial em SQL:1999. Na Figura 1(a), é exibida uma XSD com aninhamento entre construtores. A transformação proposta parte da idéia que um conjunto de partículas dentro de um construtor de composição compõe um tipo complexo. Assim, quando houver aninhamento, o construtor mais

7 interno é convertido em um tipo complexo global e, no seu lugar, é criado um elemento cujo valor do atributo type é exatamente o nome do tipo complexo criado. Referências a construções group que gerem aninhamento entre construtores de composição devem ser tratadas da mesma forma. O resultado da conversão de aninha.xsd pode ser visto na Figura 1(c). Comparando-se as instâncias de cada esquema, nas Figuras 1(b) e 1(d), vê-se que os dados armazenados no documento da primeira figura são preservados e apenas foi adicionado um elemento extra, novo. Após ser realizado o pré-processamento, a XSD está pronta para ser mapeada para SQL:1999. O algoritmo proposto é mostrado na Figura 2. O primeiro passo do algoritmo é determinar as prováveis raízes (linha 5) do esquema, pois ao contrário das declarações DOCTYPE de DTDs, em XML Schema não é especificada a raiz dos documentos válidos. Partindo-se dos candidatos a raiz, ou seja, elementos globais de tipo complexo, é realizada uma varredura no esquema a fim de verificar quais desses candidatos não são referenciados por nenhuma declaração de elemento, através do atributo ref. Tal processamento tem o propósito de identificar o início da formação de possíveis instâncias e a partir daí extrair as demais construções decorrentes da raiz. Esta heurística tem como base o fato que muitos elementos globais são assim declarados porque têm seu uso compartilhado por outras declarações, já que esta é a única forma de serem referenciados. <xsd:element name="a"> <xsd:complextype> <xsd:sequence> <xsd:element name="b" type="xsd:string"/> <xsd:element name="c" type="xsd:string"/> <xsd:choice minoccurs="2" maxoccurs="4"> <xsd:element name="d" type="xsd:string"/> <xsd:element name="e" type="xsd:string"/> </xsd:choice> </xsd:element> (a) aninha.xsd (sem transformação) <xsd:complextype name="novotipo"> <xsd:choice minoccurs="2" maxoccurs="4"> <xsd:element name="d" type="xsd:string"/> <xsd:element name="e" type="xsd:string"/> </xsd:choice> <xsd:element name="a"> <xsd:complextype> <xsd:sequence> <xsd:element name="b" type="xsd:string"/> <xsd:element name="c" type="xsd:string"/> <xsd:element name="novo" type="novotipo"/> </xsd:element> (c) novo.xsd (após transformação) <A> <B>Texto 1</B> <C>Texto 2</C> <E>Texto 3</E> <D>Texto 4</D> <D>Texto 5</D> <E>Texto 6</E> </A> (b) instância válida de aninha.xsd <A> <B>Texto 1</B> <C>Texto 2</C> <novo> <E>Texto 3</E> <D>Texto 4</D> <D>Texto 5</D> <E>Texto 6</E> </novo> </A> (d) instância válida de novo.xsd Figura 1. Esquemas e instâncias antes e após a transformação Todo processamento é iniciado a partir da raiz (linhas 6 a 10). É realizada uma busca em profundidade (linha 8), a fim de se obter recursivamente todos os tipos complexos (complextype) do ramo da árvore que inicia na raiz que é passada como parâmetro. Para cada tipo complexo, caso ainda não se encontre em UDTS_RAIZ, são extraídas as informações relevantes (linha 20) para a geração do script SQL:1999 e armazenadas na variável registro UDT_REG, estruturada de acordo com os seguintes campos: UDT_REG.raiz - valores verdadeiro ou falso; UDT_REG.construtorAgregacao - valores all, choice, sequence ou NULL;

8 UDT_REG.nome - nome do tipo estruturado; UDT_REG.nomesAtributos - vetor com os nomes dos atributos; UDT_REG.tiposAtributos - vetor com os tipos dos atributos; UDT_REG.restricoesAtributos - vetor com restrições para cada atributo. Basicamente, o procedimento extrairdados verifica se o tipo complexo T é raiz e qual é o construtor de composição associado. O outro passo é atribuir um nome ao UDT_REG e obter os nomes e tipos dos atributos do UDT_REG com base nos nomes e tipos dos elementos (construção element) e atributos (construção attribute) do tipo complexo associado. Para isso, as regras abaixo são seguidas: 1. Se for um atributo, é criado um atributo no UDT_REG com um tipo simples equivalente. 2. Se for um elemento de tipo simples e com valores de minoccurs e maxoccurs menores ou iguais a 1, é criado um atributo no UDT_REG com tipo simples equivalente; caso minoccurs ou maxoccurs tenham valor 0, é adicionada a restrição NULL para o atributo. 1 Procedimento GeraScript 2 entrada: XSD; 3 saída: script SQL:1999; 4 Início 5 RAIZES := obtemprovaveisraízes(xsd); 6 para cada R em RAIZES 7 T := obtertipo(r); 8 UDTS_RAIZ := extrairudts(t, UDTS_RAIZ); 9 UDTS_TODOS := concatenavetores(udts_todos, UDTS_RAIZ); 10 fim-para 11 UDTS_TODOS := aplicarinlining(udts_todos); 12 UDTS_TODOS := criarhierarquias(udts_todos) 13 SCRIPT := obtemscript(udts_todos); 14 Fim Procedimento extrairudts 17 Entrada: T, UDTS_RAIZ; 18 saída: UDTS_RAIZ; 19 Início 20 UDT_REG:= extrairdados(t, UDTS_RAIZ); 21 UDTS_RAIZ := adicionaelemento(udts_raiz, UDT_REG); 22 ELEMENTOS := obterelementos(t); 23 para cada E em ELEMENTOS 24 se obtertipo(e) é complexo então 25 UDTS_TEMP := extrairudts(obtertipo(e), UDTS_RAIZ); 26 UDTS_RAIZ := concatenavetores(udts_raiz, UDTS_TEMP); 27 fim-se 28 fim-para 29 Retorna UDTS_RAIZ; 30 Fim Figura 2. Algoritmo de mapeamento de uma XSD para um script SQL: Se for um elemento de tipo simples e minoccurs ou maxoccurs forem maiores que 1, é criado um atributo em UDT_REG cujo tipo é um ARRAY do tipo simples equivalente. Caso o valor de minoccurs seja igual a 0, é adicionada a restrição NULL para o atributo.

9 4. Se um elemento é de tipo complexo e os valores dos seus atributos minoccurs e maxoccurs são menores ou iguais a 1, então o tipo do atributo em UDT_REG será uma referência (tipo REF) ao tipo estruturado equivalente ao tipo complexo do elemento. 5. Se um determinado elemento tem tipo complexo e valor de minoccurs ou maxoccurs maior que 1, seu atributo associado deve ter como tipo um ARRAY de referências (REF) ao tipo complexo equivalente. O número mínimo de elementos do ARRAY é dado pela multiplicação dos valores de minoccurs do elemento e do construtor de composição do tipo complexo que está sendo referenciado. Para obter o número máximo de elementos, deve-se realizar um processo análogo com o atributo maxoccurs. Se um dos valores for unbounded, o resultado é unbounded. As restrições de cardinalidade devem ser associadas ao atributo e se o valor de minoccurs for 0, deve-se adicionar a restrição NULL. 6. Caso o tipo complexo possua referência(s) a construções group (grupo) ou atributegroup (grupo de atributos), serão tratadas como se houvesse uma substituição à sua referência, ou seja, como se os seus conteúdos fossem parte da referência que o origina. Assim, seu tratamento vai resultar em um dos casos descritos anteriormente (1 a 5). Ao final da extração de informações de todos os tipos complexos das prováveis raízes, o vetor UDTS_TODOS (linha 9) irá conter os dados necessários para a criação dos tipos estruturados do esquema SQL:1999. <xsd:complextype name= Tipo > <xsd:sequence minoccurs= 1 maxoccurs= 2 > <xsd:element name= D type= xsd:string /> <xsd:element name= A > <xsd:complextype> <xsd:sequence> <xsd:element name= B type= xsd:string /> <xsd:element name= C type= Tipo maxoccurs= 2 /> </xsd:element> (a) uma.xsd (sem inlining) <xsd:element name= A > <xsd:complextype> <xsd:sequence> <xsd:element name= B type= xsd:string /> <xsd:element name= C type= xsd:string minoccurs= 1 maxoccurs= 4 /> </xsd:element> (c) in_par.xsd (após transformação) <A> <B>Texto 1</B> <C> <D>Texto 2</D> <D>Texto 3</D> </C> <C> <D>Texto 4</D> <D>Texto 5</D> </C> </A> (b) instância válida de uma.xsd <A> <B>Texto 1</B> <C>Texto 2</C> <C>Texto 3</C> <C>Texto 4</C> <C>Texto 5</C> </A> (d) instância válida de in_par.xsd Figura 3. Esquemas e instâncias antes e após transformação de inlining. A Tabela 4 mostra que em uma parte considerável dos construtores de composição existe apenas uma partícula. Logo o tipo estruturado associado a tal construtor teria apenas um atributo, caso o tipo complexo não possua atributos, o que aumenta o número de tipos e tabelas criadas, tendo impacto na complexidade do esquema gerado. Para evitar esse tipo de situação, propõe-se que, nesses casos, essa partícula seja vista como se compusesse um tipo complexo de nível superior, se houver. Assim, ao invés de se criar um tipo estruturado com um campo que

10 referencie um outro tipo, a partícula seria mapeada como se fizesse parte do tipo complexo de nível superior, o que consiste no processo de inlining [12, 19]. Este passo é realizado no procedimento aplicarinlining (linha 11). Se os valores de minoccurs e maxoccurs do elemento cujo tipo é complexo, do construtor de composição do tipo e da partícula forem todos iguais a 1, o campo que sofreu inlining não terá um tipo ARRAY. Caso contrário, isto ocorre e o número mínimo e máximo de elementos permitido é obtido pela multiplicação dos valores de minoccurs e maxoccurs, respectivamente. Na Figura 3, é mostrado um exemplo de inlining sob o ponto de vista da XSD e da instância. Considerando-se que fossem criados tipos estruturados para a XSD da Figura 3(a), após o processo de inlining é gerado um script equivalente àquele que seria gerado para o esquema da Figura 3(c). Antes da geração do script, o vetor UDTS_TODOS é varrido para encontrar os UDT_REGs cujo tipo complexo associado possui um construtor all (o que é indicado pelo campo construtoragregacao de UDT_REG). O propósito é criar uma hierarquia de tipos onde cada subtipo apresente uma combinação distinta de ordem entre os atributos. Os UDT_REGs com valor all para o campo construtoragregacao são removidos do vetor UDTS_TODOS e são adicionados novos UDT_REGs derivados da hierarquia de tipos gerada. Também é necessário que as referências (campos com tipo REF ou ARRAY de REFs) aos UDT_REGs que foram removidos do vetor sejam substituídas por referências ao supertipo de cada hierarquia equivalente criada. Todos esses passos são realizados no procedimento criarhierarquias (linha 12). Finalmente, o script para o esquema de banco de dados pode ser gerado a partir das informações contidas no vetor UDTS_TODOS resultante, o que é feito no procedimento obtemscript. Para cada UDT_REG em UDTS_TODOS, será criado um tipo estruturado. Aqueles campos cujos tipos são REF ou um ARRAY de REFs devem ter uma cláusula REFERENCES ARE CHECKED, para garantir que não existem referências inconsistentes. O padrão SQL:1999 requer que seja indicado se um tipo estruturado pode ser ou não um supertipo, o que é especificado por NOT FINAL ou FINAL na sua declaração. Assume-se que todos são NOT FINAL. Uma outra questão a ser decidida é a criação da coluna self-referencing e optou-se pela solução mais simples que é o gerenciamento automático pelo sistema ( REF IS SYSTEM GENERATED ). Após a criação dos tipos estruturados, são criadas tabelas de tipos (Typed Tables) para cada um. Todos os campos associados a um atributo que sejam do tipo REF ou um ARRAY de REFs devem ter seu escopo associado à tabela de tipos baseada no tipo que é referenciado. Para especificar o número de elementos possíveis dos campos ARRAY, usa-se a função CARDINALITY. Por último, devem ser criadas as restrições de tabela: 1. Se o construtor do tipo complexo for choice, deve ser criada uma cláusula CHECK para garantir que apenas um dos campos tem valor diferente de NULL em cada instância (linha) da tabela. 2. Se a tabela criada estiver representando um elemento raiz, deve ser criada uma cláusula CHECK para garantir a sua cardinalidade, ou seja, só poderá conter uma linha. A abordagem proposta neste artigo garante a ordem das partículas contidas em construtores de composição sequence através da ordem dos campos nas tabelas de tipos. Por sua vez, a ordem dos elementos da(s) instância(s) é garantida pelos campos com tipos ARRAY. Considerando-se que sequence é o construtor mais utilizado (Tabela 3), este é um resultado fundamental. Embora o tratamento a choice requeira a criação de cláusulas CHECK que podem ser extensas caso o número de partículas seja grande, seu uso é pouco freqüente (11,52%). A solução que insere maior nível de complexidade ao esquema gerado é all, devido à necessidade de criação de uma hierarquia de tipos. No entanto, apenas 10,55% (Tabela 1) das amostras fazem uso dessa construção, sendo a utilização geral de 8,61% (Tabela 3).

11 Os números de ocorrências mínimos e máximos são preservados através da combinação das cláusulas CHECK com a função CARDINALITY aplicadas sobre os campos de tipo ARRAY e da(s) cláusula(s) CHECK da(s) raiz(es) de cada esquema. Aquelas tabelas que não estão representando elementos que são raízes necessariamente serão referenciadas por campos cujo tipo é REF ou um ARRAY de REFs e, sobre eles, há cláusulas CHECK que restringem o número de elementos. Conseqüentemente, o número de elementos da tabela também é restrito. Por outro lado, elementos raiz não são referenciados por nenhum outro, logo precisam ter sua cardinalidade garantida por outros meios. A opção escolhida foi a criação de uma cláusula CHECK para isso. Em resumo, o algoritmo de mapeamento proposto permite que sejam tratadas as principais construções associadas à definição de tipos complexos, que são all, attribute, attributegroup, choice, complextype, element, group, sequence e simplecontent, para as quais todas as possibilidades de uso são consideradas. Aquelas relacionadas à derivação de tipos não são consideradas, incluindo complexcontent, extension e restriction. As definições curingas any e anyattribute também não são contempladas devido à dificuldade de se encontrar uma solução aceitável em termos práticos para representar o mapeamento referente à sua substituição por qualquer elemento ou atributo, respectivamente, que estejam declarados na XSD. A maioria das construções restantes é utilizada para a definição de tipos simples e a solução proposta parte do tipo base que está sendo definido, fornecendo uma solução genérica para o problema. Algumas dessas definições são fractiondigits, length, maxexclusive e pattern. 4. Discussão de um Exemplo A Figura 4 exibe a listagem de uma XSD para a representação de dados de uma clínica e a Figura 5 o esquema SQL:1999 resultante da aplicação do algoritmo sugerido sobre essa XSD. Primeiramente, o arquivo é pré-processado a fim de identificar e tratar possíveis aninhamentos entre construtores de composição, situação que ocorre no tipo complexo associado ao elemento clinica, com a referência a um grupo, e no construtor sequence que contém o elemento paciente. A partir daí, é gerada uma nova XSD que possui os tipos complexos globais tipoclinicatype e pacientetype e que são tipos dos elementos tipoclinica e paciente, respectivamente, partículas do elemento clinica. Em destaque, estão as construções que serão mapeadas em tipos estruturados e tabelas. A execução do algoritmo é realizada sobre o novo arquivo gerado. A raiz provável é o elemento clinica, já que o outro elemento global, telefones, é referenciado no tipo complexo tpessoa. A busca em profundidade é iniciada pelo elemento clinica e são extraídas as informações relevantes para o mapeamento dos tipos clinica, tipoclinicatype, pacientetype e tpessoa. Tendo concluído esse passo, a técnica de inlining é aplicada e o tipo complexo pacientetype passa a compor a definição do elemento clinica, ao invés de ser referenciado. A última etapa antes da geração do esquema é a identificação dos tipos complexos que possuem um construtor de composição all na sua definição e a criação dos novos registros UDTs, armazenando-os em UDTS_TODOS, com informações necessárias para a criação de uma hierarquia de tipos onde cada um possua uma combinação distinta de ordem entre os atributos. No esquema, esse passo se reflete nos tipos telefones1type e telefones2type. <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <xsd:attributegroup name="endereco"> <xsd:attribute name="rua" type="xsd:string"/> <xsd:attribute name="complemento" type="xsd:string"/> </xsd:attributegroup> <xsd:group name="tipoclinica"> <xsd:choice>

12 <xsd:element name="hospital" type="xsd:string"/> <xsd:element name="ambulatorio" type="xsd:string"/> </xsd:choice> </xsd:group> <xsd:element name="telefones"> <xsd:complextype> <xsd:all> <xsd:element name="residencial" type="xsd:string" minoccurs="1" maxoccurs="1"/> <xsd:element name="celular" type="xsd:string" minoccurs="0" maxoccurs="1"/> </xsd:all> </xsd:element> <xsd:complextype name="tpessoa"> <xsd:sequence> <xsd:element name="nome" type="xsd:string"/> <xsd:element name="nascimento" type="xsd:date"/> <xsd:element ref="telefones"/> <xsd:attribute name="cpf" type="xsd:string"/> <xsd:element name="clinica"> <xsd:complextype> <xsd:sequence> <xsd:group ref="tipoclinica"/> <xsd:element name="nome" type="xsd:string"/> <xsd:element name= especialidade type= xsd:string minoccurs= 1 maxoccurs= 10 /> <xsd:sequence minoccurs="1" maxoccurs="50"> <xsd:element name="paciente" type="tpessoa"/> <xsd:attributegroup ref="endereco"/> </xsd:element> </xsd:schema> Figura 4. Exemplo de XSD Durante a geração do esquema, para cada tipo complexo existente é criado um tipo estruturado e uma tabela de tipos. Os atributos cujos tipos são complexos devem ter suas referências garantidas pelas cláusulas REFERENCES ARE CHECKED na declaração do tipo e SCOPE na tabela de tipos, como é o caso no campo telefone de tpessoatype. Campos do tipo ARRAY têm seus números de elementos mínimo e máximo garantidos pela função CARDINALITY usada na cláusula CHECK do campo na tabela de tipos. As restrições que precisam ser especificadas para as tabelas são cláusulas CHECK para garantir a escolha entre atributos quando o construtor associado for o choice, como declarado na tabela tipoclinicatable, e o número de elementos das tabelas que armazenam dados de prováveis raízes, como declarado em clinicatable. Para evitar dependências sintáticas com SGBDs específicos, o esquema SQL:1999 gerado na Figura 5 foi validado em [17]. CREATE TYPE clinicatype AS ( tipoclinica REF(tipoClinicaType) REFERENCES ARE CHECKED, nome VARCHAR(255), especialidade VARCHAR(255) ARRAY [10], paciente REF(tPessoa) ARRAY[50] REFERENCES ARE CHECKED, rua VARCHAR(255), complemento VARCHAR(255) ) NOT FINAL REF IS SYSTEM GENERATED;

13 CREATE TABLE clinicatable OF clinicatype ( REF IS clinicaid SYSTEM GENERATED, tipoclinica WITH OPTIONS SCOPE tipoclinicatable, especialidade WITH OPTIONS CONSTRAINT cardespecialidade CHECK (CARDINALITY(especialidade) BETWEEN 1 AND 10), paciente WITH OPTIONS SCOPE tpessoatable CONSTRAINT cardpaciente CHECK (CARDINALITY(paciente) BETWEEN 1 AND 50), CONSTRAINT clinicaraiz CHECK ((SELECT COUNT(*) FROM clinicatable) = 1) ); CREATE TYPE tipoclinicatype AS ( hospital VARCHAR(255), ambulatorio VARCHAR(255) ) NOT FINAL REF IS SYSTEM GENERATED; CREATE TABLE tipoclinicatable OF tipoclinicatype ( REF IS clinicatipoid SYSTEM GENERATED, CONSTRAINT tipoclinicachoice CHECK (((hospital IS NULL)AND(ambulatorio IS NOT NULL)) OR ((hospital IS NOT NULL)AND(ambulatorio IS NULL))) ); CREATE TYPE tpessoatype AS ( nome VARCHAR(255), nascimento DATE, telefones REF(telefonesType) REFERENCES ARE CHECKED, cpf VARCHAR(255) ) NOT FINAL REF IS SYSTEM GENERATED; CREATE TABLE tpessoatable OF tpessoatype ( REF IS tpessoaid SYSTEM GENERATED, telefones WITH OPTIONS SCOPE telefonestable ); CREATE TYPE telefonestype NOT FINAL REF IS SYSTEM GENERATED; CREATE TABLE telefonestable OF telefonestable ( REF IS telefonesid SYSTEM GENERATED ); CREATE TYPE telefones1type UNDER telefonestype AS ( comercial VARCHAR(255), celular VARCHAR(255) ) NOT FINAL REF IS SYSTEM GENERATED; CREATE TABLE telefones1table OF telefonestable ( REF IS telefones1id SYSTEM GENERATED ); CREATE TYPE telefones2type UNDER telefonestype AS ( celular VARCHAR(255), comercial VARCHAR(255) ) NOT FINAL REF IS SYSTEM GENERATED; CREATE TABLE telefones2table OF telefonestable ( REF IS telefones2id SYSTEM GENERATED ); Figura 5. Esquema SQL:1999 obtido a partir das definições XML Schema da Figura Conclusões Apresentamos um algoritmo de mapeamento de definições XML Schema para o padrão SQL:1999 que se fundamenta em levantamentos estatísticos realizados sobre uma coleção de 199 XSDs obtidas da Web. Esse algoritmo de mapeamento considera as principais construções propostas pelo padrão XML Schema e utiliza a técnica de inlining para diminuir a fragmentação do esquema gerado. Questões fundamentais como a ordem e a cardinalidade dos elementos são tratadas explorando-se os recursos existentes no padrão SQL:1999. A abordagem utilizada é totalmente automática, não requerendo a intervenção do usuário em nenhum momento de sua execução. No momento, o algoritmo descrito neste artigo mostrou-se adequado para mapear 53,64% das XSDs de uma amostra de 151 arquivos, coleção que apresenta apenas XSDs que não fazem uso de esquemas externos. As XSDs não-mapeáveis são aquelas que apresentam definições para tipos complexos de conteúdo misto, derivação de tipos complexos ou uso das construções key/keyref. Entretanto, é importante ressaltar que essas construções não constituem uma forte limitação para uso do nosso algoritmo, uma vez que a existência de conteúdo misto e derivação de tipos complexos pode ser facilmente tratada realizando-se transformações que resultem em

14 XSDs equivalentes à original e que as construções key/keyref ainda são pouco utilizadas na prática (ver Tabela 1). Como trabalhos futuros, em uma próxima implementação pretendemos tratar as construções que não foram contempladas de modo a aumentar a porcentagem de XSDs que podem ser representadas por esquemas SQL:1999 através da nossa abordagem. Também pretendemos considerar o mapeamento de tipos simples, pré-definidos e derivados, pois, na literatura consultada, não foi encontrado nenhum trabalho que abordasse essa questão. Um outro trabalho interessante seria a avaliação da abordagem proposta em termos de desempenho em relação à eficiência de armazenamento e de tempo de execução de consultas. Agradecimentos Este trabalho contou com apoio financeiro do CNPq e do projeto GERINDO (processo MCT/CNPq/CT-INFO /02). Referências 1. Abiteboul, S; Buneman, P.; Suciu, D. Data on the Web: From Relations to Semistructured Data and XML. Morgan Kauffman Publishers, San Francisco, CA, Amer-Yahia, S.; Du, F.; Freire, J. A Comprehensive Solution to the XML-to-Relational Mapping Problem. In Proceedings of the 6 th ACM International Workshop on Web Information and Data Management, Washington, DC, USA, November 7-8, 2004, pp Bex, G. J.; Neven, F.; Busschen, J. V. den: DTDs versus XML Schema: A Practical Study. In Proceedings of the 7 th International Workshop on Web Information and Data Management, Paris, France, June 17-18, 2004, pp Bohannon, P.; Freire, J.; Roy, P.; Siméon, J. From XML Schema to Relations: A Cost- Based Approach to XML Storage. In Proceedings of the 18 th International Conference on Data Engineering, San Jose, CA, February 26 March 1, 2002, pp Deutsch, A.; Fernandez, M.; Suciu, D. Storing Semistructured Data with STORED. In Proceedings of 1999 SIGMOD International Conference on Management of Data, Philadelphia, Pennsylvania,United States, June 1-3, 1999, pp Eisenberg, A.; Melton, J. SQL:1999, formely known as SQL3. ACM SIGMOD Record 28, 1 (March 1999), pp Eisenberg, A.; Melton, J.; Kullkarni, K.; Michels, J.; Zemke, F. SQL:2003 Has Been Published. ACM SIGMOD Record 33, 1 (March 2004), pp Florescu, D.; Kossmann, D. Storing and Querying XML Data using an RDBMS. IEEE Data Engineering Bulletin 22, 3 (March 1999), pp Jagadish, H. V. et al. TIMBER: A Native XML Database. The International Journal on Very Large Data Bases 11, 4 (December 2002), pp Google. Disponível em: Visitado: Março Lee, D.; Chu, W. Comparative Analysis of Six XML Schema Languages. ACM SIGMOD Record 29, 3 (September 2000), pp Lee, D.; Chu, W. CPI: Constraints-Preserving Inlining Algorithm for Mapping XML DTD to Relational Schema. Data & Knowledge Engineering 39, 1 (October 2001), pp

15 13. Mani, M.; Lee, D. XML to Relational Conversion using Theory of Regular Tree Grammars. In Proceedings of the First VLDB 2002 Workshop on Efficiency and Effectiveness of XML Tools and Techniques, Hong Kong, China, August 19, 2002, pp Melton, J. Advanced SQL:1999 Understanding Object-Relational and Other Advanced Features, 1 st edition. Morgan Kauffmann Publishers, San Francisco, Melton, J.; Simon, A. R. SQL:1999 Understanding Relational Language Components, 1 st edition. Academic Press, San Diego, Mignet, L.; Barbosa, D.; Veltri, P. The XML Web: a First Study. In Proceedings of the 12 th International World Wide Web Conference, Budapest, Hungary, May 20-24, 2003, pp Mimer SQL. Mimer SQL-99 Validator. Disponível: parser99/index.tml. Visitado: Abril Nestorov, S.; Abiteboul, S.; Motwani, R. Inferring Structure in Semistructured Data, Workshop on Management of Semi-structured Data. ACM SIGMOD Record 24, 4 (December 1997), pp Shanmugasundaram, J.; Kristin, T.; Zhang, C.; He, G.; De-Witt, D. J.; Naughton, J. F. Relational Databases for Querying XML Documents: Limitations and Opportunities. In Proceedings of the 25 th International Conference Very Large Data Bases, Edinburgh, Scotland, UK, September 7-10, 1999, pp Shimura, T.; Yoshikawa, M.; Uemura, S. Storage and Retrieval of XML Documents using Object-Relational Databases. In Proceedings of the 10 th International Conference on Database and Expert Systemas Applications, Florence, Italy, August 30 - September 3, 1999, pp Software AG. Tamino XML Server. Disponível: products/tamino/. Visitado: Abril Türker, C.; Gertz, M. Semantic Integrity Support in SQL-99 and Commercial (Object-) Relational Database Management Systems. The International Journal on Very Large Data Bases 22, 3 (December 2001), pp Varlamis, I.; Vazirgiannis, M. Bridging XML-Schema and Relational Databases: A System for Generating and Manipulating Relational Databases using Valid XML Documents. In Proceedings of the 2001 ACM Symposium on Document Engineering, Atlanta, Georgia, USA, November 9-10, 2001, pp Vlist, E. v. d. XML Schema, 1 st edition. O Reilly, Sebastopol, World Wide Web Consortium. Extensible Markup Language (XML). Disponível em: Visitado: Abril World Wide Web Consortium. XML Schema Part 1: Structures Second Edition. Disponível em: Visitado: Abril 2005.