IMPLEMENTANDO WRAPPERS XML E RELACIONAL PARA O CoDIMS

Transcrição

1 UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO MONOGRAFIA DE GRADUAÇÃO TATIANA MARA CÔCO IMPLEMENTANDO WRAPPERS XML E RELACIONAL PARA O CoDIMS VITÓRIA 2005

2 TATIANA MARA CÔCO IMPLEMENTANDO WRAPPERS XML E RELACIONAL PARA O CoDIMS Monografia apresentada como exigência parcial para obtenção do título de Engenheiro de Computação à Universidade Federal do Espírito Santo, na área de concentração Banco de Dados, sob a orientação do Prof. Dr. Álvaro César Pereira Barbosa. VITÓRIA 2005

3 TATIANA MARA CÔCO IMPLEMENTANDO WRAPPERS XML E RELACIONAL PARA O CoDIMS Monografia apresentada como exigência parcial para obtenção do título de Engenheiro de Computação à Universidade Federal do Espírito Santo, na área de concentração Banco de Dados, sob a orientação do Prof. Dr. Álvaro César Pereira Barbosa. Aprovada em 17 de março de 2005 COMISSÃO EXAMINADORA Prof. Dr. Álvaro César Pereira Barbosa DI/UFES Orientador Prof. Cristiano Biancardi (Mestrando) DI/UFES Prof. Dr. José Gonçalves Pereira Filho DI/UFES

4 AGRADECIMENTOS A Deus, por me dar sabedoria, paz e saúde para conquistar mais esta etapa em minha vida. Ao meu orientador Prof. Dr. Álvaro César Pereira Barbosa pela dedicação e pela contribuição para o desenvolvimento deste trabalho. Aos meus pais, José Maria e Mercedes, pela vida, pelo amor e pelo apoio nesses longos de anos de graduação. Sem o incentivo de vocês eu não teria conseguido alcançar mais esse objetivo. À minha irmã Claudia pela presença e pela força. Sua constante colaboração foi essencial. Muito obrigada pelo empenho em me ajudar principalmente nos momentos de maiores dificuldades. Ao meu irmão Denys pela compreensão. Você é muito especial para mim. Ao meu amigo Idílio pela paciência e pela contribuição para o desenvolvimento desse projeto. A todos os meus amigos que me ajudaram e incentivaram, ofereço meus sinceros agradecimentos.

5 RESUMO Com a grande quantidade de Sistemas de Informação existentes hoje nas organizações funcionando de forma independente foi gerado um grande problema no que diz respeito à integração de dados heterogêneos e distribuídos. É cada vez mais notável a necessidade de sistemas capazes de prover acesso integrado a dados distribuídos, de forma transparente e homogênea. Esse é o objetivo do CoDIMS (Configurable Data Integration Middleware System) (BARBOSA, 2001), um ambiente flexível e configurável, em desenvolvimento, que permite gerar sistemas configurados para integração de dados heterogêneos e distribuídos. O CoDIMS consiste em um framework baseado em componentes que disponibilizam serviços específicos de integração de dados denominados DIMS (Data Integration Middleware Services). Esses componentes são também frameworks que implementam serviços de sistemas gerenciadores de banco de dados, e possuem a característica de serem plug and play, fornecendo assim um alto nível de interoperabilidade, configuração e abstração da sua implementação e da forma de comunicação que utilizam. Este trabalho tem como objetivo projetar e implementar wrappers para o CoDIMS. Wrappers são responsáveis pelo acesso aos dados das fontes de dados distribuídas e pela transformação entre modelos de dados. Para tanto será necessário um estudo de conversões entre modelos de dados que serão utilizadas pelos wrappers, visando a tradução da linguagem interna do CoDIMS para a linguagem de cada fonte de dados. Ao final será implementada uma aplicação que fará a simulação de wrappers a serem utilizados no CoDIMS.

6 LISTA DE FIGURAS Figura 1 : Middleware...11 Figura 2 : Wrapper...13 Figura 3 : Exemplo de documento XML...15 Figura 4 : Exemplo de DTD...16 Figura 5 : Exemplo de documento XML (LOTAR)...18 Figura 6 : O XML Schema do arquivo valida.xml (LOTAR)...19 Figura 7 : Exemplo de utilização de Namespaces (COSTA)...21 Figura 8 : Exemplo de árvore DOM (LOTAR)...22 Figura 9 : Documento XML gerado a partir da árvore da Figura 8 (LOTAR)...22 Figura 10 : Configuração dos Componentes Básicos do CoDIMS...32 Figura 11 : Fluxograma interno do CoDIMS...33 Figura 12 : DTD da requisição XML...36 Figura 13 : DTD da requisição relacional...38 Figura 14 : DTD dos arquivos de resultados relacionais retornados pelos wrappers 40 Figura 15 : DTD dos arquivos de resultados XML retornados pelos wrappers...41 Figura 16 : As classes dos wrappers...42 Figura 17 : Wrapper relacional para MEC relacional...45 Figura 18 : Wrapper relacional para MEC XML...46 Figura 19 : Wrapper XML para MEC relacional...47 Figura 20 : Wrapper XML para MEC XML...47 Figura 21 : Casos de uso - MEC relacional...48 Figura 22 : Casos de uso MEC XML...49 Figura 23 : Diagrama de seqüência: Relacional x Relacional...50 Figura 24 : Diagrama de seqüência: Relacional x XML...51 Figura 25 : Diagrama de seqüência: XML x Relacional...52 Figura 26 : Diagrama de seqüência: XML x XML...53 Figura 27 : Modelo de dados da fonte XML desembarque...55 Figura 28 : Fonte de dados Desembarque.xml...56 Figura 29 : Modelo de dados utilizado...57 Figura 30 : Consulta enviada ao CoDIMS no formato SQL...58 Figura 31 : Subconsulta enviada ao wrapper relacional...58 Figura 32 : Subconsulta enviada ao wrapper XML...59

7 1 Figura 33 : Consulta transformada pelo wrapper relacional...59 Figura 34 : Conjunto resultado do wrapper relacional...60 Figura 35 : Conjunto resultado do wrapper XML...60 Figura 36 : Modelo de dados utilizado...61 Figura 37 : Consulta enviada ao CoDIMS no formato XQUERY...61 Figura 38 : Subconsulta enviada ao wrapper relacional...62 Figura 39 : Subconsulta enviada ao wrapper XML...62 Figura 40 : Consulta transformada pelo wrapper relacional...62 Figura 41 : Conjunto resultado do wrapper relacional...63 Figura 42 : Conjunto resultado do wrapper XML...64 Figura 43 : Tela da aplicação...66

8 LISTA DE TABELAS Tabela 1 : Modelo de dados da fonte relacional Pesquisa...55 Tabela 2 : Fonte de dados Pesquisa.mdb...57

9 SUMÁRIO 1 Introdução Motivação Objetivo Metodologia Organização do trabalho Conceitos e Tecnologias Middleware de integração Wrapper XML (extensible Markup Language) DTD XML Squema Namespaces DOM SAX Banco de Dados Relacional Conversões de Modelo de Dados Conversão XML-Relacional/Relacional-XML Altova XMLSpy TIMBER (Tree- structured native XML database Implemented at the University of Michigan by Bright Energetic Researchers) Artigos Relatório de Pesquisa: Implementação de um Wrapper para a linguagem XML-SQL Projeto dos Wrappers do CoDIMS CoDIMS Especificação dos wrappers Formato das requisições de consulta Formato dos resultados Diagrama de classes Casos de uso Diagrama de seqüência Implementação Descrição da aplicação...54

10 8 5.2 Modelo de dados integrador relacional Modelo de dados integrador XML Implementação Conclusões Resultados Contribuições ao CoDIMS Dificuldades Encontradas Trabalhos Futuros...68

11 9 1 Introdução Com o avanço da informática temos hoje a informação heterogênea e distribuída, seja na forma de armazenamento no ambiente operacional utilizado ou na localização dos dados. Dentro de uma mesma empresa podemos encontrar uma diversidade de informações, muitas vezes relacionadas, mas contidas em sistemas diferentes: vários sistemas de informação foram desenvolvidos, cada um para uma área específica da empresa, sem a preocupação em interagir com outros sistemas existentes ou em manter os dados centralizados. Hoje, com a interdependência cada vez maior de setores de uma empresa e entre empresas e com a necessidade de se acessar as informações que estão distribuídas e às vezes encontradas sob diversas formas de armazenamento, surge a necessidade de se desenvolver sistemas de integração de dados. Com essa finalidade está sendo desenvolvido o CoDIMS (Configurable Data Integration Middleware System) (BARBOSA, 2001), um ambiente flexível e configurável que possibilita gerar sistemas configurados para a integração de dados heterogêneos e distribuídos. A fase atual de desenvolvimento do CoDIMS consiste na especificação e implementação de seus serviços e componentes e na forma de comunicação entre os mesmos e com as fontes de dados. 1.1 Motivação A necessidade de desenvolvimento de serviços do CoDIMS, principalmente o de acesso às fontes de dados distribuídas e o de transformação entre os modelos de dados das fontes e o modelo de dados interno do CoDIMS, tarefas essas realizadas por wrappers, foram as motivações iniciais deste trabalho.

12 Objetivo Como é necessário desenvolver um wrapper para cada tipo fonte de dados e há uma diversidade de modelos de dados que poderão estar envolvidos, este trabalho tem como objetivo projetar e implementar especificamente wrappers XML e relacional para o CoDIMS. 1.3 Metodologia Para a implementação desses wrappers será necessário um estudo sobre a definição e o formato de um documento XML, os recursos de manipulação de documentos XML, as formas de conversões entre modelo de dados, e por último a análise de requisitos e a modelagem desses wrappers para que e possa realizar a implementação dos mesmos. 1.4 Organização do trabalho O capítulo 2 trata dos conceitos utilizados, as tecnologias utilizadas em Sistemas de Integração, as formas de apresentação e manipulação do XML e o conceito de banco de dados relacional. No Capítulo 3 são descritos a conversão de modelos de dados relacional e XML, sistemas que fazem conversões e alguns trabalhos relativos a conversões de modelos de dados. No Capítulo 4 são detalhados a arquitetura do CoDIMS e o projeto dos wrappers para o CoDIMS. O Capítulo 5 trata da implementação dos wrappers para o CoDIMS. Finalmente, no Capítulo 6 são apresentados os resultado obtidos, as contribuições para o CoDIMS, as dificuldades encontradas e os trabalhos que poderão ser realizados no futuro.

13 11 2 Conceitos e Tecnologias Neste capítulo são descritos os conceitos e as tecnologias necessárias para o entendimento deste trabalho. 2.1 Middleware de integração Muitas aplicações necessitam de informações de diversas fontes onde os dados relacionados podem diferir na representação ou na tecnologia utilizada para armazenamento. Para a integração destes dados, é necessária uma camada de software denominada middleware que age como um intermediador entre a aplicação e as fontes de dados, como pode ser visualizado na Figura 1. Aplicação 1 Aplicação 2 Aplicação 3 Middleware Fonte de Dados 1 Fonte de Dados 2 Fonte de Dados 3 Figura 1 : Middleware O termo middleware é utilizado para descrever diversos níveis de interoperabilidade, desde os níveis de abstração mais baixos, como em aplicações mais próximas ao

14 12 sistema operacional e do sistema de rede, até os sistemas complexos como nos casos dos sistemas de integração de dados com maior nível de abstração. Uma característica de um middleware para integração de dados é o usuário não enviar consultas diretamente para as fontes de dados. A razão disso, e seu principal objetivo, é liberar o usuário de ter que conhecer detalhes sobre todas as fontes de dados e ter que interagir com cada uma delas individualmente. Essa característica é exatamente a proposta do CoDIMS. Para viabilizar a integração de dados no CoDIMS torna-se necessário realizar a integração de esquemas. Para isso, todos os esquemas dos bancos de dados componentes devem estar descritos em um mesmo modelo de dados. O problema é que os esquemas dos diferentes bancos de dados componentes podem estar expressos em diferentes modelos. Assim, torna-se necessário, inicialmente, transformar todos os esquemas para um mesmo modelo de dados, denominado de Modelo de Dados Comum (MDC). No caso de sistemas componentes não baseados em banco de dados, um wrapper deve simular a existência de um esquema (metadados) para permitir o processo de integração. O esquema conceitual de cada banco de dados componente é denominado de esquema local. Este esquema, expresso no modelo de dados do sistema componente, deve ser transformado e descrito no MDC. O esquema derivado desta transformação é denominado de esquema de exportação. Um esquema global (ou federado), descrito no MDC, é então criado pela integração de múltiplos esquemas de exportação. Finalmente, são definidos os esquemas externos (visões) sobre o esquema global, para atender às necessidades de um grupo específico de usuários ou de aplicações, ou ainda por razões de controle de acesso. Para o acesso às fontes de dados e a transformação de modelos o CoDIMS utiliza wrappers, termo conceituado a seguir.

15 Wrapper Wrappers são ferramentas (também denominadas de middleware) que atendem a instruções de manipulação (consultas e atualizações) de uma fonte específica de dados. Os wrappers representados por W1, W2 e W3 podem ser visualizados na Figura2. Aplicação 1 Aplicação 2 Aplicação 3 Middleware Integrador W1 W2 W3 Fonte de Dados 1 Fonte de Dados 2 Fonte de Dados 3 Figura 2 : Wrapper Um wrapper encapsula uma única fonte de dados para que ela possa ser utilizada de maneira mais conveniente, o que o distingue de outros tipos de middleware. Através do uso de wrappers, pode-se transformar uma fonte de dados em uma forma mais estruturada. Podem, ainda, ser usados para apresentar uma interface simplificada, para adicionar funcionalidade ou para expor alguma das interfaces internas de uma fonte de dados.

16 14 Os wrappers do CoDIMS promovem o acesso às fontes de dados distribuídas e heterogêneas e promovem a transformação entre o modelo de dados da fonte e o modelo de dados interno do CoDIMS, permitindo então a integração de dados. A troca de informações entre o wrapper e o ambiente interno do CoDIMS é sempre representada em XML (PINHEIRO, 2004). XML é uma forma de representação de dados largamente utilizada por promover interoperabilidade entre sistemas de informação. O padrão XML é o objeto de estudo da próxima seção. 2.3 XML (extensible Markup Language) Para resolver as limitações do HTML para representar o conteúdo de determinado documento, o World Wide Web Consortium (W3C) decidiu criar um novo padrão para representação de dados. O objetivo era criar uma linguagem similar ao HTML, porém mais extensível e capaz de separar o conteúdo da apresentação. Este esforço resultou no XML. O XML é um subconjunto do SGML (Standart Generalized Markup Language), uma linguagem (complexa) usada para descrever documentos (ALHANDRA, 2001). O XML separa conteúdo da apresentação, uma vez que em conjunto com o XLS (Extensible Stylesheet Language) permite definir a apresentação a dar ao documento XML (ALHANDRA, 2001). O XML é extensível uma vez que permite que se inventem novas tags, consoante às necessidades da aplicação em questão (ALHANDRA, 2001). Um exemplo de arquivo XML pode ser visualizado na Figura 3.

17 15 <?xml version="1.0" encoding="utf-8"?> <Fatura> <Data> 25/02/2004</Data> <IdCliente>123</IdCliente> <NomeCliente prioridade="baixa">cst</nomecliente> <Item> <IdItem>987</IdItem> <NomeItem>Papel</NomeItem> <Quantidade>5</Quantidade> </Item> <Item> <IdItem>9</IdItem> <NomeItem>Caneta</NomeItem> <Quantidade>100</Quantidade> </Item> <Item> <IdItem>100</IdItem> <NomeItem>Borracha</NomeItem> <Quantidade>105</Quantidade> </Item> </Fatura> Figura 3 : Exemplo de documento XML Um documento XML é constituído por várias partes: Uma declaração <?xml version="1.0"?> que identifica o arquivo como sendo um documento XML, também conhecida como prólogo; Um conjunto de tags customizadas. Neste documento estão presentes as seguintes tags: <Fatura>... </Fatura>, <IdCliente>...</IdCliente>, <Item>...</Item>, <Quantidade>... </Quantidade> etc. Em um documento XML todas as tags (<tag>) têm que possuir uma tag correspondente de fechamento. (</tag>); Dados em formato texto. Exemplo Caneta, Borracha, 105, 25/02/2004 ;

18 16 Atributos inseridos em tags, como por exemplo, <NomeCliente prioridade="baixa">. Este tipo de codificação permite mais flexibilidade ao customizar os elementos. Com a criação de tags, às vezes faz-se necessário definir regras que ajudarão a criar documentos válidos. Basicamente uma DTD (Definição de Tipo de Documento) ou XML Schema valida a estrutura de um documento. Pode-se definir, por exemplo, os elementos que se deseja usar no documento e indicar em que ordem estrutural eles deverão ocorrer, se este elemento pode ser vazio ou deve conter texto. São definidos também os atributos que devem ser associados com um elemento. Nas seções e são mostrados como se define uma DTD e um XML Schema DTD Na DTD, basicamente, são especificados quais elementos ou atributos são permitidos e em que local do documento XML eles podem aparecer. Um exemplo de um DTD é mostrado na Figura 4. <!ELEMENT Fatura (Data, IdCliente, NomeCliente, Item+)> <!ELEMENT Data (#PCDATA) <!ELEMENT IdCliente (#PCDATA)> <!ELEMENT NomeCliente (#PCDATA)> <!ATTLIST NomeCliente prioridade CDATA #IMPLIED> <!ELEMENT Item (IdItem, NomeItem, Quantidade)> <!ELEMENT IdItem (#PCDATA)> <!ELEMENT NomeItem (#PCDATA)> <!ELEMENT Quantidade (#PCDATA)> Figura 4 : Exemplo de DTD

19 17 A DTD da Figura 4 tem as seguintes especificações: Uma fatura consiste nos seguintes elementos: uma Data, um identificador de cliente (IdCliente), o nome do cliente (NomeCliente) anotado com a respectiva prioridade associada. Um ponto de interrogação indica um elemento opcional (por exemplo, se tivéssemos NomeCliente? ), um + indica elementos que podem ocorrer uma ou mais vezes (neste caso o Item+ indica que pode aparecer uma ou mais vezes), um * indica um elemento que pode ocorrer zero ou mais vezes (caso fosse possível enviar faturas vazias); Os elementos definidos por (#PCDATA) correspondem a texto; <ATTLIST> define elementos que têm atributos, o termo #IMPLIED indica que determinado atributo é opcional (podemos, por exemplo, omitir a prioridade do cliente). Um problema com a definição do elemento #PCDATA é que não é possível definir, por exemplo, que determinado campo deverá conter texto que representa um número (exemplo Quantidade). Para resolver este problema foram inventados os XML Schema que permitem especificar melhor a estrutura de determinado documento XML (ALHANDRA, 2001). Não é necessário que exista um documento XML que referencie um DTD, no entanto um documento é válido apenas se tem um DTD correspondente e está de acordo (conforme) com ele (ALHANDRA, 2001). A tarefa de validação do documento é facilitada utilizando DTDs, sendo também possível desenvolver aplicações para validar o conteúdo do documento usando a interface DOM ou SAX. As interfaces de manipulação do XML, DOM e SAX, são descritas nos itens e XML Squema A DTD é uma especificação da W3C e possui as seguintes limitações:

20 18 Sintaxe diferente da XML; Não possui suporte para tipos de dados. Além das limitações acima citadas, ainda existe uma outra; por exemplo, usando uma DTD pode-se definir quais elementos filhos um determinado elemento pode ter, mas não se pode estabelecer um número máximo ou mínimo de vezes em que este elemento pode aparecer nos documentos (LOTAR, 2001). Uma alternativa é usar os Schemas para definir e validar a estrutura e o conteúdo de um documento XML. Um Schema pode fazer parte do documento XML ou estar em um arquivo separado. No próximo exemplo será usado o XDR Schema, que é definido a seguir. Além disso, existem outros mecanismos para validar a estrutura de um documento XML, conforme pode ser verificado no site (LOTAR, 2001). XML-Data Reduced (XDR) Schema é um subconjunto baseado na especificação XML-Data, assim como a DTD, e é utilizada para definir a estrutura de um documento XML, mas com a vantagem de suprir as suas principais limitações (LOTAR, 2001). Na Figura 5 é mostrado o conteúdo do arquivo valida.xml a partir do qual será montado um XML Schema. <?xml version= 1.0 encoding= ISO ?> <cadastro xmlns= x-schema:valida.xml > <nome>josé da Silva</nome> <end>rua das Américas</end> <fone comercial= sim > </fone> </cadastro> Figura 5 : Exemplo de documento XML (LOTAR) A seguir, na Figura 6, temos um XDR Schema para o documento XML da Figura 5.

21 19 <Schema name= valida xmlns= urn:schemas-microsoft-com:xml-data xmlns:dt= urn:schemas-microsoft-com:datatypes <ElementType name="nome" content= textonly dt:type= string /> <ElementType name="end" content= textonly dt:type= string /> <AttributeType name="comercial" dt:type= string /> <ElementType name="fone" content= textonly dt:type= string /> <attribute type="comercial"/> </ElementType> <ElementType name="cadastro" content= eltonly model= closed > <element type="nome"/> <element type="end"/> <element type="fone"/> </ElementType> </Schema> Figura 6 : O XML Schema do arquivo valida.xml (LOTAR) O documento XDR Schema da Figura 6 é formado da seguinte forma: O elemento Schema é usado para conter elementos e delimitar o início e o fim de um XDR Schema; O atributo xmlns é usado para declarar o XML namespace do XDR Schema; O namespace xmlns:dt está associado com o tipo de dados do XDR Schema; ElementType são os elementos que farão parte do documento e os atributos representam: name, o nome do elemento; content, se o elemento pode conter texto; dt:type, o tipo de dados do elemento; model: open para conter filhos além dos declarados e closed para somente os declarados;

22 20 atributo type do elemento element e do elemento attribute também definem o nome; Os atributos do elemento AttributeType têm o mesmo significado do elemento ElementType. Para testar ou validar o documento XML que utiliza XDR Schemas, também deverão ser utilizadas as interfaces DOM ou SAX, abordadas nas seções e 2.3.5, porém, antes disso, na próxima seção é explicado o termo namespace utilizado anteriormente Namespaces Um documento XML precisa de namespaces quando utiliza elementos definidos em dois ou mais schemas. Com isso, não há ambigüidade no caso de schemas diferentes terem elementos com o mesmo nome. A ausência de ambigüidade é importante não só para a validação como para o uso dos documentos em aplicações (COSTA, 2003). O exemplo da Figura 7 possui dois namespaces: lojavirtuala e shoppingvirtualb. Haveria ambigüidade na aplicação caso não utilizasse namespaces, mesmo não utilizando validação, pois os dois schemas possuem um elemento código.

23 21 <?xml version= 1.0?> <lojavirtuala:produto xmlns:lojavirtuala= xmlns:shoppingvirtualb= > <lojavirtuala:nome>produto 1234</lojaVirtualA:nome> <lojavirtuala:preco>125.00</lojavirtuala:preco> <lojavirtuala:codigo>1234</lojavirtuala:codigo> <shoppingvirtualb:codigo>a456</shoppingvirtualb:codigo> </lojavirtuala:produto> Figura 7 : Exemplo de utilização de Namespaces (COSTA) DOM O padrão inicial do XML dá informação suficiente para que se possa construir um parser XML, mas não especifica como manipular a informação obtida pelo parser. As soluções mais comuns para este problema são o DOM e o SAX (ALHANDRA, 2001). O Document Object Model (DOM) surge como uma API abstrata para manipular documentos XML. Existem várias implementações desta API para várias linguagens de programação, como por exemplo, para Java, Perl e C. O DOM foi projetado para ser usado com qualquer linguagem de programação e define uma estrutura lógica dos documentos e métodos para manipular um documento XML. O programador usa, portanto, um conjunto de métodos padrão para manipular e navegar numa árvore DOM (ALHANDRA, 2001). Com DOM é possível manipular qualquer tipo de informação que esteja na árvore de elementos do documento XML. Um documento XML possui uma estrutura em forma de uma árvore e com o DOM, cada elemento pode ser representado por um ou mais objetos. O objeto XMLDOMElement, por exemplo, representa todos os elementos do documento XML.

24 22 A seguir, na Figura 8, temos uma representação de uma árvore de elementos e nós texto de um documento XML. Árvore DOM Elemento raiz Elemento filho Texto Elemento filho Elemento filho Texto Figura 8 : Exemplo de árvore DOM (LOTAR) Se o esquema acima for aplicado a um documento XML, será obtido o documento mostrado na Figura 9. <?xml version= 1.0 encoding= ISO ?> <cadastro> <registro> <nome>josé da Silva</nome> </registro> <registro> <dadospessoais> <nome>josé da Silva</nome> </dadospessoais> </registro> </cadastro> Figura 9 : Documento XML gerado a partir da árvore da Figura 8 (LOTAR)

25 SAX O Simple API for XML (SAX) é outra API para permitir o acesso e a manipulação de XML. O SAX é uma API baseada em eventos, o que significa que as funções (ou métodos consoante a linguagem de programação usada) são chamadas pelo analisador SAX. Será, por exemplo, chamada uma função no início e no fim do parsing de cada elemento. Uma vantagem desta abordagem é que se torna desnecessário construir uma árvore representando o documento XML (que pode ser grande) poupando-se memória (ALHANDRA, 2001). No entanto, a análise com base em eventos pode precisar da criação de estruturas de dados temporárias adicionais para a retenção das informações analisadas antes de sua inserção na estrutura de dados final. Por exemplo, dados formados por caracteres podem ser associados ao elemento que os contém. Nesse caso, uma pilha de elementos é necessária para facilitar a associação (GRAVES, 2003). Os analisadores XML geralmente são criados com o uso de um padrão de fábrica. Uma string com o nome da classe do analisador é passada para a fábrica de analisadores a fim de que um seja criado. Muitas empresas incluindo a IBM, Sun e Oracle fornecem analisadores que podem ser criados com o uso dessa abordagem. Uma vantagem de empregar uma fábrica de analisadores é que o analisador pode ser facilmente substituído se outro mais eficiente for encontrado. A principal advertência à utilização do padrão de fábrica é se certificar de incluir a classe do analisador especificado no seu caminho (GRAVES, 2003). Com a definição de quase todos os conceitos utilizados para a realização desse trabalho, ainda falta definir um banco de dados relacional. Essa definição específica de banco de dados torna-se necessária por se utilizar unicamente banco de dados relacional neste trabalho. 2.4 Banco de Dados Relacional O Modelo de Dados relacional representa os dados contidos em um Banco de Dados através do conceito matemático de relações. Estas relações contêm

26 24 informações sobre as entidades representadas e seus relacionamentos. O Modelo Relacional, é claramente baseado no conceito de matrizes, onde as chamadas linhas (das matrizes) seriam os registros e as colunas (das matrizes) seriam os campos. Os nomes das tabelas e dos campos são de fundamental importância para a compreensão entre o que está armazenado, onde está armazenado e qual a relação existente entre os dados armazenados. Cada linha da relação é chamada de TUPLA e cada coluna da relação é chamada de ATRIBUTO. O conjunto de valores passíveis de serem assumidos por um atributo, é intitulado de DOMÍNIO. O domínio consiste de um grupo de valores atômicos a partir dos quais um ou mais atributos retiram seus valores reais. Assim sendo Rio de Janeiro, Paraná e Pará são estados válidos para o Brasil, enquanto que Corrientes não é um estado válido (pertence à Argentina e não ao Brasil). O esquema de uma relação, nada mais é que os campos (colunas) existentes em uma tabela. Já a instância da relação consiste no conjunto de valores que cada atributo assume em um determinado instante. Portanto, os dados armazenados no Banco de Dados, são formados pelas instâncias das relações. As chaves primárias nas relações não podem ser duplicadas (não podem existir dois estados do Pará, no conjunto de estados brasileiros, por exemplo), a ordem de entrada de dados no Banco de Dados não deverá ter qualquer importância para as relações, no que concerne ao seu tratamento. Os atributos deverão ser atômicos, isto é, não são passíveis de novas divisões. É chamado de Chave Primária o Atributo que define um registro, dentre uma coleção de registros. Chave Secundária (Ternária, etc), serão chaves que possibilitarão pesquisas ou ordenações alternativas, ou seja, diferentes da ordem criada a partir da chave primária ou da ordenação natural (física) da tabela. É chamada de Chave Composta, aquela chave que contém mais de um atributo (por exemplo um cadastro ordenado alfabeticamente por Estado, Cidade e Nome do Cliente, necessitaria de uma chave composta que contivesse estes três atributos). É chamada de Chave Estrangeira um atributo que permite a ligação lógica entre uma tabela (onde ela se encontra) com outra na qual ele é chave primária.

27 25 3 Conversões de Modelo de Dados Neste capítulo é mostrado um estudo de sistemas e artigos que se propõem a fazer conversão entre informações XML e banco de dados relacional, porém, nem todas as técnicas utilizadas nesses casos foram utilizadas para a implementação dos wrappers para o CoDIMS. Entretanto, esse estudo serve de conhecimento para entender como são feitas as transformações de modelos de dados, de uma maneira geral, para então especificar a transformação requerida pelo CoDIMS. A conversão entre modelo de dados é a abordagem mais importante deste capítulo, principalmente conversão entre modelo de dados relacional e XML, que é o foco deste trabalho e o próximo assunto a ser detalhado Conversão XML-Relacional/Relacional-XML Para que se possa usar o XML como formato de troca de informação nas bases de dados relacionais, é necessário decidir que correspondência existe entre os documentos XML e os dados relacionais, se o mapeamento será feito no cliente ou no servidor, e como será utilizado o documento XML no modelo relacional (ALHANDRA, 2001). Na conversão os dados do documento XML são extraídos e armazenamos como linhas e colunas numa tabela. Por exemplo, no caso da Fatura da Figura 3, vista no capítulo 2, página 15, seria construída uma tabela com os seguintes campos: NomeClietne, IdCliente, Data, e outra tabela para guardar os detalhes da Fatura. Para criar um documento XML, é necessário construir várias consultas SQL para obter os dados, e depois construir o documento XML. Para armazenar um documento XML na base de dados é necessário extrair os elementos presentes no documento (usando por exemplo o DOM), e gerar o SQL para atualizar as tabelas que guardam esses dados.

28 26 Uma interface XML com um SGBD relacional fornece acesso a uma tecnologia arrojada de banco de dados com as vantagens da distribuição XML. A principal desvantagem é que a representação dos dados é limitada aos relacionamentos. Há uma incompatibilidade entre o que o relacionamento e o elemento XML podem representar, porque o elemento XML possui maior flexibilidade que o relacionamento. Um relacionamento (ou uma linha fixa de uma tabela) é composto de uma quantidade fixa de características (ou colunas) e cada uma contém um item de dados, enquanto um elemento XML pode armazenar uma quantidade aleatória de características (como os subelementos ou atributos) e cada subelemento pode conter mais de um item dos dados. O relacionamento pode ser facilmente expresso em XML, mas carregar os dados de um documento XML dentro de um banco de dados relacional pode ser uma tarefa mais complicada. Talvez seja necessário alterar o esquema relacional para permitir mais variações na estrutura dos dados e assim facilitar a inclusão dos dados originalmente em XML no banco de dados relacional (GRAVES, 2003). Uma das vantagens de usar o banco de dados relacional é que consultas complexas podem ser escritas em SQL, a linguagem-padrão de consultas em SGBDs relacionais (GRAVES, 2003). Foram estudados também dois sistemas e alguns artigos que tratam da conversão de dados entre modelo relacional e XML, que serão resumidamente apresentados abaixo Altova XMLSpy 2005 O software XMLSpy 2005 (XMLSPY) fabricado pela Altova, no mercado há algum tempo, faz a conversão de bancos de dados relacionais para XML, assim como converte um arquivo XML em banco de dados relacional. Além de transformar bancos de dados, também é possível converter arquivos texto comuns ou separados por vírgula para XML. A conversão também pode ser baseada em algum DTD ou SCHEMA existente.

29 27 Arquivos XML podem ser gerados a partir de um DTD ou SCHEMA e um DTD ou SCHEMA pode ser gerado a partir de um arquivo XML. Esse software também auxilia na edição de arquivos XML, verificando se o arquivo XML está bem formado (verifica se as tags estão fechadas, verifica nomenclatura de elementos e atributos) e cruzando as informações do XML com o DTD ou SCHEMA relativo (apontando se a formação do XML confere com a designada pelo DTD ou SCHEMA). Também podem ser feitas consultas em arquivos XML no formato XPath ou XQuery (XQUERY). Na conversão de arquivos XML para relacionais, os elementos que possuem filhos ou que possuem atributos são transformados em tabela, os atributos são transformados em campos e os elementos filhos podem ser transformados em campos ou em novas tabelas relacionadas com a tabela pai referente ao elemento. Dentre as principais vantagens, destacam-se: Na conversão pode ser utilizado o banco de dados Access ou qualquer conexão de banco de dados ADO ou ODBC; Alta flexibilidade entre XML, DTD/SCHEMA, bancos de dados e arquivos texto. Dentre as desvantagens, temos: O software Altova XMLSpy 2005 é pago e seu custo pode chegar a (oitocentos euros); Como o software é desenvolvido por uma empresa especializada que o comercializa, a estrutura e os códigos-fonte dos produtos não são divulgados; Ao gerar tabelas relacionadas, o relacionamento não é informado e o campo relacionado é apenas chamado de ForeignKey ou PrimaryKey; Devido a seu funcionamento isolado e a impossibilidade de se modelar, o mesmo não pode ser utilizado como componente do CoDIMS.

30 TIMBER (Tree- structured native XML database Implemented at the University of Michigan by Bright Energetic Researchers) A idéia principal do projeto TIMBER (TIMBER) foi construir um banco de dados XML que possuísse uma arquitetura tão próxima quanto possível de um banco de dados relacional. Dessa forma, seria possível reutilizar, quando apropriado, as tecnologias desenvolvidas para banco de dados relacional existente há anos. Os documentos XML são transformados em árvores e o sistema manipula coleções de árvores. Essa aplicação aceita três tipos de consulta: XQuery. A consulta de entrada está no formato XQuery; Plano Lógico. A consulta é composta de operadores de álgebra lógica. Álgebra lógica é baseada em álgebra relacional, porém possui uma gramática própria. O TIMBER suporta qualquer plano lógico satisfazendo as regras da gramática de álgebra lógica; Plano físico. A consulta é composta de operadores físicos que normalmente acessam banco de dados, combinam e reconstroem suas informações. Dentre as vantagens desse sistema destacam-se: Pelo fato de guardar as informações no seu formato nativo XML não precisando converter as informações, o desempenho se torna melhor, além de não ter os problemas decorrentes da conversão, como por exemplo, atributos multivalorados; Usa XQuery que é uma linguagem de consulta XML, não precisando converter a consulta que é entrada no sistema; Disponibilização do código-fonte. Dentre as desvantagens, ressaltamos:

31 29 Não poderia ser utilizado no CoDIMS porque armazena árvores XML tornando necessária a conversão dos dados relacionais em informações XML para que pudessem ser armazenadas. Esse não seria o objetivo do CoDIMS, já que mantém as fontes nos seus formatos locais Artigos Diversos artigos foram lidos no intuito de adquirir o conhecimento necessário para a realização da transformação entre dados relacionais e XML. A seguir serão descritos alguns trabalhos que contribuíram para o entendimento das conversões de modelos UXQuery: Building Updatable XML Views over Relacional Databases Em UXQuery: Building Updatable XML Views over Relacional Databases (BRAGANHOLO; DAVIDSON; HEUSER) é explicado como fazer o mapeamento de bases relacionais para documentos XML e ainda é exemplificado como uma consulta no formato UXQuery percorre uma árvore de consulta. Nesse artigo fica claro mais uma vez que na transformação as tabelas relacionais podem ser transformadas em elementos e suas tuplas podem se transformar em seus elementos filhos. Uma outra observação importante é que as relações entre as tabelas podem ser todas reunidas dentro um elemento pai, eliminando as chaves estrangeiras. Os dados de tabelas diferentes que possuem relação são agrupados num mesmo elemento XML A General Technique for Querying XML Documents using a Relational Database System Em A General Technique for Querying XML Documents using a Relational Database System (SHANMUGASUNDARAM; SHEKITA; KIERNAN; KRISHNAMURTHY;

32 30 VIGLAS; NAUGHTON; TATARINOV), ao contrário do artigo anterior, é explicado como fazer a transformação de arquivo XML em banco de dados relacional. É criada uma árvore de navegação do DTD do documento e a partir dela fica claro quando um elemento possui elementos filhos. Os elementos pai são transformados em tabela e seus elementos filhos (se não se dividirem) são transformados em seus campos. Os atributos também viram campos. Se os elementos filhos se dividirem, os mesmos são transformados também em tabelas e é criado um relacionamento com a tabela pai Relatório de Pesquisa: Implementação de um Wrapper para a linguagem XML-SQL Em Relatório de Pesquisa: Implementação de um Wrapper para a linguagem XML- SQL (NOTARI) é descrito a arquitetura de um wrapper, as classes criadas para um wrapper e o funcionamento dos módulos e das classes. Esse documento traz também os exemplos que foram utilizados como teste. O estudo desse documento foi importante para o conhecimento da modelagem de um wrapper através do diagrama de classes e também para o conhecimento da sua arquitetura, que foi bem exemplificado por figuras. Como se trata apenas de um relatório, os códigos-fonte desses wrappers não foram disponibilizados, mas contribuíram para o entendimento de um wrapper em termos de modelagem e arquitetura, conforme descrito acima.

33 31 4 Projeto dos Wrappers do CoDIMS Este capítulo trata do projeto dos wrappers do CoDIMS envolvendo análise de requisitos e todas as especificações necessárias para a modelagem desses wrappers. Inicialmente é detalhado o ambiente CoDIMS e nas seções seguintes são feitas as especificações necessárias para o desenvolvimento dos wrappers relacional e XML do CoDIMS. 4.1 CoDIMS O CoDIMS (Configurable Data Integration Middleware System) (BARBOSA, 2001) é um middleware que tem como objetivo integrar informações provenientes de fontes heterogêneas e distribuídas. A arquitetura do CoDIMS é baseada em componentes, denominados DIMS (Data Integration Middleware Services), os quais possuem a característica de serem plug and play. Esse middleware se baseia numa configuração física e numa configuração lógica de componentes. A configuração física define os componentes que disponibilizarão serviços para a aplicação específica. A configuração lógica é representada por um workflow que determina a ordem de execução dos serviços oferecidos pelos componentes DIMS. Essa característica fornece um alto nível de configuração, abstração e interoperabilidade. Os componentes básicos para a configuração física do CoDIMS podem ser visualizados na Figura 10.

34 32 Componente Controle Componente Metadados Componente Processamento de Consultas Componente Acesso aos Dados Figura 10 : Configuração dos Componentes Básicos do CoDIMS O Componente de Controle contém as configurações física e lógica do middleware. O Componente Metadados armazena e gerencia os metamodelos dos dados. O Componente Processamento de Consulta tem o objetivo de transformar as consultas enviadas ao middleware, em linguagem de alto nível, e processá-las. O Componente de Acesso a Dados permite o acesso a cada fonte de dados ligada ao middleware. Na implementação original do CoDIMS usava-se RMI para a comunicação entre os seus componentes, sendo descrita atualmente como Web Services (TREVISOL, 2004). Na Figura 11 pode ser observado o fluxo de uma consulta enviada por um usuário ao ambiente CoDIMS.

35 33 Consulta formulada pelo usuário Processador de Consultas Analisador Reescritor Otimizador Gerência de Metadados Componente Controle MEC Acesso aos Dados Subconsulta 1 Wrapper 1 Subconsulta 2 Wrapper 2 Fonte 1 Fonte 2 Figura 11 : Fluxograma interno do CoDIMS Conforme a Figura 11, os passos para a execução da consulta enviada ao CoDIMs são: 1) Um usuário formula uma consulta usando uma linguagem de alto nível, como por exemplo, SQL;

36 34 2) O Analisador faz a análise léxica e sintática, o Reescritor agrupa a consulta por fonte de dados e o Otimizador otimiza a consulta. Esses subcomponentes se comunicam com o componente Gerência de Metadados, pois eles necessitam de informações sobre o modelo de dados para realizarem suas funcionalidades ; 3) A Máquina de Execução de Consultas (MEC) se comunica com o componente Acesso aos Dados, enviando as requisições de consulta; 4) Como os dados estão distribuídos em fontes diferentes, o componente Acesso aos Dados envia subconsultas aos wrappers, que estão ligados às fontes; 5) Os wrappers convertem a subconsulta no formato da fonte e encaminham a consulta transformada para a respectiva fonte de dados; 6) A fonte executa a consulta; 7) Os wrappers recebem os dados resultantes das fontes e convertem para o formato compreendido pela MEC. A capacidade do CoDIMS de integrar dados heterogêneos e distribuídos se dá devido ao comportamento do componente Acesso aos Dados que através dos wrappers consegue acessar as fontes locais nos seus diversos formatos, conforme pode ser observado na Figura 11. O componente Acesso aos Dados é responsável pela comunicação com as fontes de dados disponíveis. Ele interage com os wrappers, sendo que cada wrapper está vinculado a uma fonte de dados distinta. A função do wrapper é traduzir a requisição de consulta enviada pela MEC (no formato do modelo de dados do CoDIMS, que pode ser relacional ou XML) para o formato que seja compreendido pela fonte de dados e traduzir o resultado obtido da fonte para o formato que a MEC entenda. Por exemplo: a MEC envia uma requisição de consulta no formato XML para o wrapper e este reescreve essa consulta em SQL supondo que a fonte seja um banco de dados relacional. Depois, o wrapper recebe o resultado como um ResultSet e converte para XML retornando o mesmo para a MEC. Os wrappers têm a capacidade de encapsular a fonte de dados tornando o seu acesso transparente ao CoDIMS, conforme visto na próxima seção.

37 Especificação dos wrappers Os wrappers, conforme descrito anteriormente, receberão subconsultas da MEC e deverão reescrever as mesmas para o formato compreendido pela fonte. Com o resultado obtido da fonte, o wrapper deverá fazer novamente uma reescrita para que a MEC possa compreender o resultado. O modelo de dados do CoDIMS, ou seja, o formato que o CoDIMS trabalhará internamente inicialmente, poderá ser relacional ou XML. Portanto, as informações (subconsultas) que os wrappers receberão da MEC poderão estar em dois formatos diferentes e os wrappers a serem desenvolvidos deverão contemplar as duas situações. As fontes de dados que os wrappers acessarão, para efeito de implementação, serão uma fonte relacional e uma fonte no formato XML. Em (PINHEIRO, 2004) são especificadas as requisições de consulta ou subconsultas, uma para cada modelo de dados do CoDIMS, que são enviadas aos wrappers para que os mesmos possam transcrevê-las para o formato da fonte Formato das requisições de consulta As requisições de consulta quando estão no formato relacional são encapsuladas por XML, portanto, nos dois casos as subconsultas chegarão aos wrappers no formato XML.

38 36 A seguir temos as DTDs que foram especificadas em (PINHEIRO, 2004). <!ELEMENT local-plano (elemento+)> <!ATTLIST local-plano nome-arquivo CDATA #REQUIRED > <!ELEMENT elemento ((atributo*), (condicao*))> <!ATTLIST elemento nome CDATA #REQUIRED obterconteudo (sim nao) #REQUIRED > <!ELEMENT atributo EMPTY> <!ATTLIST atributo nome CDATA #REQUIRED > <!ELEMENT condicao EMPTY> <!ATTLIST condicao tipoargumentodireito (valor atributo valor-elemento) #REQUIRED argumentodireito CDATA #REQUIRED operacao (nao igual diferente maior menor maior-igual menor-igual) #REQUIRED tipoargumentoesquerdo (valor atributo valorelemento) #REQUIRED argumentoesquerdo CDATA #REQUIRED > Figura 12 : DTD da requisição XML Na Figura 12 podemos observar a DTD de uma requisição XML, ou seja, quando o formato da MEC é XML. Essa DTD tem a seguinte descrição: local-plano: elemento raiz do documento. o nome-arquivo: nome do arquivo que contêm o documento. elemento: define o nome do elemento a ser pesquisado quando a fonte é um documento XML e uma tabela quando a fonte é relacional. o obterconteudo: define se o conteúdo será obtido. atributo: define o nome de um atributo de um elemento quando a fonte é um documento XML e um campo quando a fonte é relacional.

39 37 condicao: define uma condição para fazer a busca. As condições são ligadas por AND. Não foram criadas condições que envolvam OR. o tipoargumentodireito: define o significado do argumento valor: valor independente de elemento ou atributo. atributo: o argumento é um atributo. valor-elemento: valor do elemento (#PCDATA) o argumento-direito: argumento a direita da condição. o operacao: operador lógico da condição. o argumentoesquerdo: argumento a esquerda da condição. o tipoargumentoesquerdo: define o significado do argumento valor: valor indepêndente de elemento ou atributo. atributo: o argumento é um atributo. valor-elemento: valor do elemento (#PCDATA)

40 38 <!ELEMENT local-plano (coluna+,tabela+,condicao*)> <!ELEMENT coluna EMPTY> <!ATTLIST coluna ordem CDATA #REQUIRED nome CDATA #REQUIRED tabela CDATA #REQUIRED > <!ELEMENT tabela EMPTY> <!ATTLIST taleba nome CDATA #REQUIRED > <!ELEMENT condicao EMPTY> <!ATTLIST condicao argumentodireito CDATA #REQUIRED operacao (nao igual diferente maior menor maior-igual menor-igual) #REQUIRED argumentoesquerdo CDATA #REQUIRED > Figura 13 : DTD da requisição relacional Na Figura 13 podemos observar a DTD de uma requisição relacional, ou seja, quando o formato da MEC é relacional. Essa DTD tem a seguinte descrição: local-plano: elemento raiz do documento. coluna: define qual (quais) coluna(s) de qual tabela se deseja retornar quando a base é relacional ou quais atributos quando a base é XML. o ordem: posição que a coluna deve ser retornada em relação às outras. o nome: nome da coluna (atributo ou campo). o tabela: nome da tabela que contêm a coluna quando a base é relacional ou nome do elemento raiz quando a base é XML. tabela: define qual (quais) tabelas será (serão) utilizada(s) quando a base é relacional ou nome do elemento raiz quando a base é XML o nome: nome da tabela.

41 39 condicao: define uma condição a ser colocada na clausula WHERE. As condições são ligadas por AND. Não foram criadas condições que envolvam OR. o argumentodireito: argumento a direita da condição. o operacao: operador lógico da condição. o argumentodireito: argumento a esquerda da condição. De acordo com as especificações acima, deverão ser desenvolvidos dois wrappers: um para uma base relacional, e outro para uma base XML. Cada wrapper poderá receber dois formatos de consulta: uma relacional encapsulada em XML quando a MEC for relacional, e outra em XML quando a MEC for XML. O resultado obtido de cada fonte deverá ser convertido pelo seu wrapper em um arquivo no formato XML e o wrapper deverá também retornar um código de retorno para que a MEC conheça o status da fonte Formato dos resultados O arquivo de saída retornado pelos wrappers deverá ser formatado como XML porque apesar do modelo de dados interno do CoDIMS ser relacional ou XML, a comunicação interna deverá sempre ser feita no formato XML para prover flexibilidade. Cada wrapper deverá retornar para a MEC o caminho referente ao arquivo de saída gerado e um código de retorno. Esse código de retorno se torna necessário pelo fato de o wrapper nem sempre conseguir retornar resultados para a MEC. Os fatores para que isso ocorra podem ser: fonte não localizada, conjunto-resultado vazio, time out, parâmetro (tabela, campo, elemento, atributo,...) inexistente e fonte não conectada, por exemplo. Os códigos de retorno foram especificados da seguinte forma: 0: resultado obtido com sucesso;

42 40 1: conjunto-resultado vazio; 2: fonte não conectada; 3: time out; 4: fonte não localizada; 5: parâmetro inexistente. Em (PINHEIRO, 2004) também é especificado o conjunto-resultado relacional, ou seja, o formato dos arquivos retornados pelos wrappers para a MEC relacional. Porém, as seguintes alterações foram necessárias para que o resultado pudesse ficar mais otimizado: Eliminação dos atributos tipo e tabela-origem do elemento coluna. Esses atributos não iriam acrescentar informações necessárias para a MEC, tornando-se dispensáveis; Inclusão do atributo valor, que contém o valor propriamente dito da coluna, ou seja, a informação retornada da consulta. A Figura 14 mostra a DTD de como deverão ser os arquivos de resultados relacionais criados pelos wrappers com a nova definição. <!ATTLIST conjunto-resultado conjunto-completo (sim nao) #REQUIRED> <!ELEMENT tupla (coluna+)> <!ATTLIST tupla ordem CDATA #REQUIRED> <!ELEMENT coluna (#PCDATA)* > <!ATTLIST coluna ordem CDATA #REQUIRED nome CDATA #REQUIRED valor CDATA #REQUIRED> Figura 14 : DTD dos arquivos de resultados relacionais retornados pelos wrappers A DTD do arquivo resultado relacional tem a seguinte descrição:

43 41 conjunto-resultado: conjunto de tuplas (caso seja uma fonte relacional) ou elementos (caso seja uma fonte XML) que um wrapper retornou da fonte. O atributo conjunto-completo indica se existem mais tuplas ou elementos a serem enviadas ou se o conjunto já esta completo; tupla: corresponde a uma linha do ResultSet (caso seja uma fonte relacional) ou elemento (caso seja uma fonte XML); coluna: corresponde a um campo de uma linha da tabela (caso seja uma fonte relacional) ou a um atributo do elemento (caso seja uma fonte XML). O atributo ordem indica a posição da coluna na linha ou a posição de um atributo no elemento. O atributo nome é o nome do campo ou do atributo. O atributo valor é o valor do campo ou do atributo. Como não foi definido anteriormente o conjunto-resultado XML dos wrappers, o mesmo foi especificado para que pudesse representar os dados provenientes das fontes de dados para a MEC XML. A DTD dos arquivos de resultados XML criados pelo wrappers pode ser visualizada na Figura 15. <!ATTLIST conjunto-resultado conjunto-completo (sim nao) #REQUIRED> <!ELEMENT elemento (coluna+)> <!ATTLIST elemento ordem CDATA #REQUIRED> <!ELEMENT atributo (#PCDATA)* > <!ATTLIST atributo ordem CDATA #REQUIRED nome CDATA #REQUIRED valor CDATA #REQUIRED> Figura 15 : DTD dos arquivos de resultados XML retornados pelos wrappers A descrição da DTD do arquivo resultado XML tem a mesma descrição da DTD do arquivo resultado relacional, porém, agora, a tupla é elemento e a coluna é atributo. Conhecendo os formatos dos resultados a serem retornados pelos wrappers, os formatos das requisições de consulta e os modelos de conversão, todos os requisitos estão definidos para que especificações dos wrappers através de UML