Um Tradutor de Esquemas Relacionais em XML para Esquemas SQL

Um Tradutor de Esquemas Relacionais em XML para Esquemas SQL Alisson Giovanni Rosa 1, Ronaldo dos Santos Mello 1 1 Departamento de Informática e Estatística Universidade Federal de Santa Catarina (UFSC) Florianópolis SC Brasil {alisson,ronaldo}@inf.ufsc.br Abstract. This paper presents the architecture of a translator of XML documents, that represent relational schemata, to SQL/DDL schemata. Such documents are usually generated by relational database modeling tools, and the contribution of this work is to allow interchanging and further creation of relational schemata through the use of XML format. The translator considers existing technologies to the solution of the problem in order to reduce the complexity of the final solution, in particular XSL technology. It uses XSLT transformations to eliminate the need for constructing a proprietary annotations processor. Resumo. Este artigo apresenta a arquitetura de um Tradutor de documentos XML, que representam esquemas relacionais, para esquemas SQL/DDL. Tais documentos são usualmente gerados por ferramentas de modelagem de bancos de dados relacionais e a contribuição deste trabalho é permitir o intercâmbio e posterior geração de esquemas relacionais entre parceiros de negócio através do formato XML. O Tradutor utiliza tecnologias já existentes na solução do problema, no intuito de reduzir a complexidade da solução final, em particular a tecnologia XSL. A utilização de transformações XSLT elimina a necessidade da construção de um processador de anotações proprietário. 1. Introdução O foco deste artigo são dados no formato XML que representam esquemas relacionais. Muitas ferramentas de projeto de bancos de dados relacionais persistem o resultado do desenvolvimento, ou seja, o esquema relacional, em formato XML. É o caso de ferramentas como a ERWIN [Computer Associates 2006], a Rational Rose [IBM 2006], e a brasileira brmodelo [Cândido 2005], esta última desenvolvida no Grupo de Banco de Dados da UFSC. Entretanto, cada ferramenta segue um esquema proprietário para a disposição destas informações no arquivo XML. Isto torna extremamente caro o trabalho de extrair o esquema relacional destes arquivos XML (com a intenção de gerar o esquema SQL de implementação para um SGBD específico), na impossibilidade de se ter acesso à ferramenta que criou este arquivo XML. Assim sendo, este trabalho tem por objetivo criar uma ferramenta de apoio ao mapeamento e extração de esquemas relacionais especificados em arquivos XML, bem como a geração dos comandos SQL para a criação das tabelas componentes do esquema de implementação do banco de dados. A finalidade deste trabalho é permitir um mapeamento flexível de esquemas relacionais representados em XML, ou seja, um método de mapeamento que seja executado diretamente sobre um arquivo XML. Esta

abordagem é particularmente interessante quando um arquivo descrevendo o esquema do documento XML não estiver disponível. Uma possível solução para o problema (adotada neste trabalho) é a utilização da tecnologia XSLT [W3C 2006], que tem como finalidade transformar documentos XML em outros documentos XML ou outros documentos texto, em substituição aos processadores de anotações propostos em outras ferramentas, citadas adiante na Seção 2. Neste trabalho, XSLT é utilizada tanto para realizar transformações nos arquivos XML de entrada (segundo regras de mapeamento definidas pelo usuário) em um arquivo XML padronizado e semanticamente compreensível para a fase de geração do SQL de criação de tabelas, quanto na geração do script SQL, que é a saída do Tradutor. Tal solução evita a necessidade de construir um processador de anotações fixas (associado a um esquema XML fixo) e torna a ferramenta mais aberta, uma vez que XSLT já possui vários processadores disponíveis livremente [Sourceforge.org 2006] [Apache.org 2006]. A solução proposta também define um conjunto de regras para extração de esquemas relacionais a partir de arquivos XML. No intuito de facilitar, e ao mesmo tempo assegurar a corretude da tradução do esquema relacional para os comandos SQL, a transformação do arquivo XML de entrada se dá em duas fases. O objetivo da primeira fase é gerar, a partir do arquivo de entrada, um arquivo XML em conformidade com um arquivo XML Schema que descreve a BNF [ISO 1996] do comando SQL Create Table. Na segunda fase, com base neste arquivo XML intermediário, é gerado o script SQL de criação das tabelas. Uma vez válido o arquivo XML intermediário de acordo com o arquivo XML Schema, garante-se que a sintaxe do comando SQL resultante está correta. Tanto na primeira como na segunda fase, as transformações são especificadas utilizando a linguagem XSLT. Este trabalho apresenta mais três seções. A Seção 2 descreve trabalhos relacionados. A Seção 3 detalha o Tradutor proposto e a Seção 4 apresenta a conclusão. 2. Trabalhos Relacionados Em geral, os trabalhos existentes na literatura tratam a questão da persistência e recuperação de arquivos XML em bancos de dados relacionais. Entretanto, não foram encontradas ferramentas específicas para o tratamento de arquivos XML cujo conteúdo seja a especificação de esquemas relacionais. Dois trabalhos mais robustos neste contexto são o X-Database [Varlamis et. al. 2001] e ShreX [Amer-Yahia et.al. 1984], que se propõem a realizar o mapeamento para esquema relacional de qualquer arquivo XML, não importando o seu conteúdo. A base do sistema X-Database é um arquivo XML Schema que descreve o esquema lógico dos dados a serem trocados. O sistema analisa a sintaxe do XML Schema e gera a base de dados relacional. Após, processa a decomposição em tuplas de tabelas de arquivos XML válidos de acordo com o XML Schema. A diferença fundamental entre o X-Database e o Tradutor proposto é que o primeiro necessita do XML Schema enquanto o segundo atua diretamente sobre o arquivo XML. ShreX é um sistema para decomposição e carga de documentos XML em bancos de dados relacionais, sendo o mapeamento definido por anotações em arquivos XML Schema que indicam quais elementos e atributos devem ser armazenados no banco. O esquema relacional correspondente é gerado por um processador de anotações que executa o parsing do XML Schema anotado. Em comum entre o ShreX e o Tradutor

proposto temos o fato de que ambos utilizam o conceito de regras padrão para guiar o mapeamento de elementos e atributos. Entretanto, ShreX utiliza um processador de anotações próprio, de difícil manutenção, enquanto o Tradutor proposto utiliza XSLT para esta função. Da mesma forma que o X-Database, as anotações são feitas em um XML Schema. O trabalho de Boshernitsan [Boshernitsan et. al. 2000] não tem como objetivo o mapeamento XML-relacional, mas contribuiu de forma relevante para a criação de uma estratégia de tradução em dois passos com o uso de um formato de troca, adotado pela ferramenta proposta. Ele apresenta um formato de troca de código de programação, baseado em XML, entre as ferramentas de um framework denominado Harmonia. Gerase uma representação em XML da árvore sintática de um programa escrito nas linguagens suportadas pelo framework. Em comum com o Tradutor proposto tem-se a geração de um XML intermediário baseado na gramática da linguagem. Porém, Boshernitsan não prevê o tratamento de variações das gramáticas, enquanto o Tradutor proposto pode tratá-las através de uma base de arquivos XSLT. O Tradutor proposto introduz algumas melhorias, se comparado com as características dos trabalhos expostos nesta Seção, como o fato de não necessitar de um processador de anotações próprio, nem tampouco necessitar do arquivo XML Schema associado ao arquivo XML de entrada. 3. O Tradutor Proposto O Tradutor proposto recebe como entrada um arquivo XML cujo conteúdo é uma especificação de um esquema relacional. Este arquivo é transformado em um arquivo XML cujo conteúdo está em conformidade com um esquema em XML Schema construído para representar a sintaxe BNF/EBNF [ISO 1996] do comando SQL Create Table em conformidade com o padrão ISO/IEC 9075:1992 da ISO [ISO 1992]. A definição deste esquema XML a partir de um BNF levou em conta a similaridade conceitual existente entre estas duas linguagens, ou seja, assumiu-se que os símbolos não-terminais da gramática correspondem a elementos da XML e as relações hierárquicas entre elementos são as produções. A partir deste XML intermediário gerado, a posterior geração do código SQL se torna automática e totalmente livre de erros de sintaxe. Um aspecto importante tratado pelo Tradutor é que parsers não reconhecem a semântica contida nos arquivos de entrada. Eles cuidam apenas da verificação da sintaxe do documento, ou seja, da aderência do documento às regras de sintaxe da linguagem. Em função disto, a etapa de importação do arquivo de entrada considera a intervenção de um usuário especialista para definir aspectos semânticos da importação. Para tanto, foram definidas regras de mapeamento específicas para arquivos XML que contenham esquemas relacionais, automatizando tanto quanto possível, a tarefa de tradução. Uma vez definidas, estas regras são persistidas e podem ser aplicadas posteriormente de forma automática, para novos arquivos XML com a mesma estrutura, ou seja, produzidos pelas mesmas fontes de dados (pessoas ou ferramentas de modelagem). Adiante, na Seção 3.2, esta interação é exemplificada. A arquitetura do Tradutor proposto é mostrada na Figura 1. Ele realiza a tradução do arquivo XML de entrada em dois passos, onde cada transformação XSLT representa a conclusão de um passo.

O objetivo do primeiro passo é criar um arquivo XML em um formato que atenda às especificações da sintaxe do comando SQL Create Table, utilizando o mapeamento definido pelo usuário e transformações XSLT. Uma vez este arquivo XML intermediário gerado é conhecido pelo Tradutor, o passo seguinte é realizado de forma automática, consistindo na aplicação de novas transformações XSLT sobre ele para gerar o script SQL. O arquivo XSLT a ser executado no segundo passo pode ser configurado, caso haja a necessidade de alterações no resultado da saída do Tradutor. Figura 1. Arquitetura do Tradutor O Tradutor necessita que o usuário primeiramente informe se já existe um XSLT com mapeamentos definidos para esta fonte de dados. Em caso positivo, o Tradutor simplesmente executa o primeiro passo de transformação, gerando o arquivo XML intermediário. Caso contrário, o Tradutor auxilia o usuário na definição dos mapeamentos através de uma base de regras padrão (ver Seção 3.2). De posse dos mapeamentos definidos pelo usuário, o Tradutor complementa um arquivo XSLT base com expressões XPath [W3C 2007] necessários para a geração do arquivo XML intermediário (ver mais detalhes na Seção 3.3). Uma vez gerado este arquivo, o passo seguinte é executado de maneira automática, uma vez que o XSLT utilizado para o segundo passo (geração do script SQL) tem um formato pré-definido, pois foi preparado para atuar sobre este formato de arquivo XML. As Seções a seguir detalham as etapas de funcionamento do Tradutor. 3.1 Etapa 1 Aquisição do Arquivo XML de Entrada O arquivo de entrada para o Tradutor representa um esquema relacional persistido em XML. A Figura 2, a seguir, ilustra a forma e o conteúdo de um arquivo proveniente da ferramenta brmodelo [Cândido 2005]. O arquivo descreve duas tabelas relacionais: Estados e Municípios. O método de persistência XML de cada ferramenta de modelagem é proprietário. Logo, cada arquivo XML é heterogêneo e pode manter mais informações do que apenas o esquema relacional em si, devendo estas informações serem descartadas. A próxima etapa se dedica a resolver estas questões.

3.2 Etapa 2 Definição dos Mapeamentos a partir das Decisões do Usuário e Regras Padrão O objetivo desta etapa é responder à ferramenta de tradução perguntas como: Quais elementos deste arquivo devem ser considerados tabelas, e de qual atributo ou elemento deve-se extrair os nomes destas tabelas? Quais elementos (ou atributos) simbolizam os campos de uma tabela, e de qual atributo ou elemento deve-se extrair os nomes dos campos e os tipos de dados a serem armazenados? <?xml version="1.0" encoding="iso-8859-1"?> <MER> <Informacoes> <Posicao Left="0" Top="0"/> <TotalItens Valor="16"/> <Tipo Valor="LOGICO"/> <Versao Valor="1.0.0"/> </Informacoes> <Tabelas> <Tabela nome="estados" id="1"> <Nula Valor="0"/> <Color Valor="12632256"/> <Campos> <Campo nome="sigla" id="2"> <Nula Valor="-1"/> <ApenasSeparador Valor="0"/> <IsKey Valor="-1"/> <IsFKey Valor="0"/> <Tipo Valor="varchar"/> <TabOrigem Valor="0"/> </Campo> <Campo nome="nome" id="3"> <Nula Valor="-1"/> <ApenasSeparador Valor="0"/> <IsKey Valor="0"/> <IsFKey Valor="0"/> <Tipo Valor="nvarchar"/> <TabOrigem Valor="0"/> </Campo> </Campos> </Tabela> <Tabela nome="municipios" id="4"> <Nula Valor="0"/> <Color Valor="12632256"/> <Campos> <Campo nome="nome" id="5"> <Nula Valor="-1"/> <ApenasSeparador Valor="0"/> <IsKey Valor="-1"/> <IsFKey Valor="0"/> <Tipo Valor="nvarchar"/> <TabOrigem Valor="0"/> </Campo> <Campo nome="estado" id="6"> <Nula Valor="-1"/> <ApenasSeparador Valor="0"/> <IsKey Valor="0"/> <IsFKey Valor="-1"/> <Tipo Valor="varchar"/> <TabOrigem Valor="0"/> </Campo> </Campos> </Tabela> </Tabelas> </MER> <Texto> </Texto> Figura 2. Exemplo de arquivo XML de entrada. Considerando-se de antemão que o conteúdo dos arquivos XML de entrada sempre contém esquemas relacionais, sabe-se que existem restrições para os conceitos do modelo relacional que precisam ser respeitadas para um correto mapeamento dos elementos do arquivo de entrada. Por exemplo, sabe-se que, ao ser identificado um elemento XML como sendo uma tabela, este elemento deve possuir um conteúdo (subelemento ou atributo) que defina o seu nome. Para tanto, um conjunto de regras (ou restrições) de mapeamento foram definidas. A fim de facilitar a especificação de maneira mais formal destas regras de mapeamento, utilizam-se siglas. A Tabela 1 ilustra essas siglas. Diversos tipos de relacionamento entre dados XML podem ocorrer em um arquivo XML. O mais comum é o relacionamento hierárquico entre elementos, onde um

elemento filho está contido no elemento pai. Outro relacionamento é entre um elemento e seus atributos. O Tradutor trata estes dois tipos de relacionamento, utilizando a sintaxe XPath para especificá-los. Tabela 1. Siglas utilizadas para os conceitos do modelo relacional. Elemento Descrição Sigla Tabela Elemento identificador de uma tabela T Tabela.nome Elemento ou atributo que contém o nome da tabela definida para T TA1 Campo Elemento que identifica um campo de uma tabela definida para T C Campo.nome Elemento ou atributo que contém o nome do campo definido para C CA1 Campo.tipo Elemento ou atributo que contém o tipo de dado do campo definido CA2 para C Campo.nome_tabela Elemento ou atributo que contém o nome da tabela definida para T CA3 ao qual o campo pertence Campo.chave_primaria Elemento ou atributo que define a condição de chave primária para CA4 o campo definido para C Relacionamentos Par de elementos do tipo C, definindo um relacionamento entre eles R A definição de elementos pelo usuário deve obedecer a uma ordem de precedência pré-definida, denotada por A > B, onde A e B são elementos quaisquer, tal que A deve estar definido para que se possa definir B. Assim a primeira regra é a seguinte: (1) T > C > R Uma vez respeitada a regra (1), deve-se respeitar, ainda, as seguintes regras: (2) T é considerado definido quando estiver acompanhado de uma definição de TA1, sendo T um elemento qualquer e TA1 um dos caminhos XPath genéricos a seguir: (a) //T/ elemento de T /text() ou (b) //T/ elemento de T /@ atributo /text() ou (c) //T/@ atributo de T /text(). (3) C é considerado definido quando estiver acompanhado das definições de CA1, CA2, CA3 e, opcionalmente, CA4. C é definido por: (a) //T/ elemento de T ou (b) // elemento (4) CA1 é definido por: (a) // elemento de C /text() ou (b) // elemento de C /@ atributo /text() ou (c) //C/@ atributo de C /text(). (5) CA2 é definido por: (a) // elemento de CA1 /text() ou (b) // elemento de CA1 /@ atributo /text() ou (c) // atributo de CA1 /text(). (6) CA3 é inferido automaticamente a partir da Regra (3), sendo definido: (a) de acordo com a definição (a) da Regra (3) como: CA3 = T, ou (b) de acordo com a definição (b) da Regra (3) como:

// elemento de C /text() ou // elemento de C /@ atributo /text() ou // atributo de C /text(). (7) CA4 é definido por: (a) // elemento de CA1 /text() ou (b) // elemento de CA1 /@ atributo /text() ou (c) //@ atributo de CA1 /text() ou (d) // elemento de C /text()* ou (e) // elemento de C /@ atributo /text()* ou (f) //@ atributo de C /text()* * Esta regra só é utilizada se text() = CA1. (8) R é definido por um conjunto de pares (origem, destino), onde tanto origem como destino são elementos CA1, tal que: CA1(origem).T <> CA1(destino).T e CA1(origem).CA2 = CA1(destino).CA2 O mapeamento pelo usuário precisa ser feito apenas para um elemento ou atributo de cada tipo contido no arquivo XML de entrada. Através deste aprendizado por amostragem, o Tradutor libera o usuário de definir todos os componentes do esquema relacional até o final do arquivo XML. Essas decisões do usuário preenchem os requisitos mínimos para que o Tradutor esteja apto a executar a transformação XSLT, que irá processar o arquivo XML de entrada, gerando o XML intermediário. Este arquivo XSLT é específico para a fonte mapeada em questão e sua construção é detalhada na próxima Seção. 3.3 Etapa 3 Geração do arquivo XSLT de Transformação Com base nas decisões de mapeamento adquiridas na etapa anterior, o Tradutor gera um arquivo XSLT contendo os comandos de transformação a serem aplicados sobre o arquivo XML de entrada. Este arquivo é armazenado como um arquivo padrão de transformação para todo arquivo XML proveniente desta mesma fonte em um catálogo do Tradutor. Desta forma, não são necessárias novas intervenções do usuário para definir traduções sobre este formato. O arquivo XSLT é construído ao se integrar uma estrutura de um arquivo XSLT parcialmente definido (XSLT base) aos caminhos XPath obtidos na etapa anterior. O XSLT base possui a definição dos templates a serem utilizados na transformação dos XPath extraídos para fins de construção da instrução SQL Create Table correspondente, como mostra a Figura 3. <xsl:for-each select=" "> < table_definition > <xsl:text>create TABLE </xsl:text> <xsl:value-of select=" "/> </table_definition> </xsl:for-each> Figura 3. Descrição parcial do arquivo XSLT base para geração do XML intermediário.

Considerando o arquivo XML exemplo da Figura 2, neste ponto do processo já se obteve o XPath /MER/Tabelas/Tabela@nome como sendo o caminho que retorna o identificador das tabelas. Assim sendo, torna-se possível o preenchimento dos valores dos elementos <xsl:for-each select=" "> e <xsl:value-of select=" "/>, gerando assim um novo arquivo XSLT, específico para a transformação de arquivos de entrada provenientes desta mesma fonte. A Figura 4 mostra o arquivo XSLT da Figura 3 já com os valores preenchidos. <xsl:for-each select="tabela"> < table_definition > <xsl:text>create TABLE </xsl:text> <xsl:value-of select="tabela/@nome"/> </table_definition> </xsl:for-each> Figura 4. Descrição parcial do arquivo XSLT específico de uma fonte para geração do XML intermediário. 3.4 Etapa 4 Transformação do Arquivo XML de Entrada em um XML Intermediário Nesta etapa, um processador XSLT executa as transformações sobre o arquivo XML de entrada definidas no arquivo XSLT específico da fonte. O resultado desta transformação é um arquivo XML em conformidade com o arquivo XML Schema que descreve a sintaxe do comando SQL Create Table. Após a geração deste XML intermediário, o mesmo é validado contra o XML Schema. Caso a validação seja positiva, a geração do código SQL para a criação das tabelas ocorrerá sem erros de sintaxe. A execução do trecho de código XSLT ilustrado na Figura 4 gera um XML intermediário com os elementos <table_definition>, conforme mostra a Figura 5. < table_definition > CREATE TABLE Estados </table_definition> < table_definition > CREATE TABLE Municipios </table_definition> Figura 5. Trecho do arquivo XML intermediário. 3.5 Etapa 5 Geração do Script SQL Nesta etapa, transformações definidas em um arquivo XSLT proveniente de uma base de arquivos XSLT para a geração da saída (mantidas no catálogo do Tradutor) são aplicadas ao arquivo XML intermediário gerado na etapa anterior. Os arquivos XSLT pertencentes a esta base podem ser utilizados na transformação de dados de qualquer fonte, uma vez que a sua execução ocorre sobre o arquivo XML intermediário, já padronizado para manter a descrição de comandos Create Table.

O resultado desta última transformação é o comando SQL de criação das tabelas do esquema relacional contido no arquivo XML de entrada. O comando SQL para o exemplo apresentado anteriormente é mostrado na Figura 6. CREATE TABLE Estados ( sigla NVARCHAR(2), nome NVARCHAR(50), PRIMARY KEY(sigla) ); CREATE TABLE Municipios ( nome NVARCHAR(2), estado NVARCHAR(50) NULL, PRIMARY KEY(nome), CONSTRAINT FK_Municipios_Estados FOREIGN KEY ( estado ) REFERENCES Estados ( sigla ) ); Figura 6. Script SQL resultante da tradução. Vale observar que, uma outra vantagem do uso de transformações XSLT em etapas separadas durante o processo é que, no caso desta etapa, pode-se substituir o arquivo XSLT de geração do comando SQL por outro que especifique a transformação para uma determinada variante da linguagem SQL. Na prática, isto significa que é possível gerar o comando para SGBDs relacionais específicos, por exemplo, apenas definindo este arquivo XSLT quando da execução desta etapa do Tradutor e executando todas as etapas anteriores da mesma forma. 3. Conclusão Este artigo apresenta a arquitetura para um Tradutor de esquemas relacionais em XML para esquemas SQL. No desenvolvimento da solução buscou-se reduzir a complexidade encontrada em ferramentas semelhantes existentes na literatura. Esta redução de complexidade foi alcançada baseando a arquitetura na utilização de um processador XSLT qualquer para efetuar as transformações sobre os arquivos XML de entrada e intermediário. Desta forma, elimina-se a necessidade da construção de um processador de anotações próprio, como adotado por outros trabalhos. Adicionalmente, a especificação de um processo de tradução em dois passos, com a utilização de um formato intermediário de troca, tornou o Tradutor flexível em termos de escolha do formato de saída. A Etapa 5 pode considerar a substituição do arquivo XSLT de transformação por outro que especifique alguma variação da linguagem SQL ou mesmo outros formatos de saída como HTML, PDF, texto ou XML. Destaca-se como contribuição a integração de tecnologias já existentes na solução do problema, no intuito de reduzir a complexidade da solução final. Tal abordagem não foi encontrada nos trabalhos pesquisados na literatura, que, no sentido inverso, sugerem o desenvolvimento de tecnologias próprias para a solução do problema do mapeamento XML-relacional. A intenção é que este trabalho venha a se tornar uma ferramenta útil, preenchendo uma lacuna hoje existente, principalmente para ferramentas de modelagem conceitual de banco de dados que não dão suporte à geração do script SQL/DDL. O Tradutor encontra-se atualmente em fase de implementação e pretende-se obter a sua liberação segundo os modelos de licença pública adotados atualmente.

Como trabalhos futuros, salienta-se a construção de um modelo de persistência e recuperação de regras padrão (para domínios específicos ou não), que possa ser expandido com facilidade. Isto é necessário porque as regras padrão apresentadas neste artigo são parte da lógica do Tradutor, tornando atualmente a sua expansão mais trabalhosa. Também seria de grande valia o desenvolvimento de um método ou algoritmo de verificação automática de conflitos entre as regras padrão especificadas. Este método preveniria a definição de regras padrão conflitantes, que poderiam no futuro vir a impossibilitar determinado mapeamento pelo usuário. A construção de um módulo para edição interativa de arquivos XSLT de transformação para vários SQL de saída desejados é igualmente uma extensão interessante para o Tradutor. Referências Apache.org (2008) The Apache Xalan Project. http://xalan.apache.org/. Último acesso: Fevereiro de 2008. Amer-Yahia, S.; Du, F.; Freire, J. (1984) "ShreX: Managing XML Documents in Relational Databases". In: VLDB 2004. Boshernitsan, M.; Graham S. (2000) Designing an XMLbased Exchange Format for Harmonia. In: WCRE. 2000. p. 287-289. Computer Associates (2008) ERwin Data Modeler http://www3.ca.com/solutions/product.aspx?id=260. Último acesso: Fevereiro de 2008. Cândido, C. (2005) Aprendizagem em Banco de Dados: Implementação de Ferramenta de Modelagem E.R. Programa de Pós-Graduação em Banco de Dados - Universidade Federal de Santa Catarina. Monografia de Especialização. 2005. IBM (2008) Rational Rose. http://www.rational.com/products/rose/index.jsp. Último acesso: Fevereiro de 2008. ISO (1992) ISO/IEC 9075-1:2003 - Database languages -- SQL -- Part 1: Framework (SQL/Framework). http://www.iso.org/iso/en/cataloguedetailpage.cataloguedetail?csnumber=3413 2. 1992. ISO (1996) ISO/IEC 14977:1996 - Syntactic metalanguage -- Extended BNF. http://standards.iso.org/ittf/publiclyavailablestandards/s026153_iso_iec_14977_1 996(E).zip. 1996. Sourceforge.org (2008) SAXON The XSLT and XQuery Processor. http://saxon.sourceforge.net. Último acesso: Fevereiro de 2008. Varlamis, I.; Vazirgiannis, M. (2001) Bridging XML-Schema and relational databases. A system for generating and manipulating relational databases using valid XML documents. Proceedings of the ACM Symposium on Document Engineering, 2001. 105-114. W3C (2007) XML Path Language (XPath) Version 1.0. http://www.w3.org/tr/xpath. Último acesso: Novembro de 2007. W3C (2008) XSL Transformations (XSLT) Version 1.0. http://www.w3.org/tr/xslt. Último acesso: Fevereiro de 2008.