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
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
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
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.
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.
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 :
wrappers
DTD dos arquivos de resultados relacionais retornados pelos
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
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
LISTA DE TABELAS
Tabela 1 :
Modelo de dados da fonte relacional Pesquisa....................................55
Tabela 2 :
Fonte de dados Pesquisa.mdb ............................................................57
SUMÁRIO
1
2
Introdução ............................................................................................................9
1.1
Motivação......................................................................................................9
1.2
Objetivo.......................................................................................................10
1.3
Metodologia.................................................................................................10
1.4
Organização do trabalho.............................................................................10
Conceitos e Tecnologias ....................................................................................11
2.1
Middleware de integração ...........................................................................11
2.2
Wrapper ......................................................................................................13
2.3
XML (eXtensible Markup Language)...........................................................14
2.3.1
DTD .....................................................................................................16
2.3.2
XML Squema .......................................................................................17
2.3.3
Namespaces ........................................................................................20
2.3.4
DOM ....................................................................................................21
2.3.5
SAX......................................................................................................23
2.4
3
Banco de Dados Relacional........................................................................23
Conversões de Modelo de Dados ......................................................................25
3.1.1
Conversão XML-Relacional/Relacional-XML .......................................25
3.1.2
Altova XMLSpy 2005 ...........................................................................26
3.1.3
TIMBER (Tree- structured native XML database Implemented at the
University of Michigan by Bright Energetic Researchers)...................................28
3.1.4
Artigos..................................................................................................29
3.1.5
Relatório de Pesquisa: Implementação de um Wrapper para a
linguagem XML-SQL ..........................................................................................30
4
5
Projeto dos Wrappers do CoDIMS .....................................................................31
4.1
CoDIMS ......................................................................................................31
4.2
Especificação dos wrappers........................................................................35
4.2.1
Formato das requisições de consulta ..................................................35
4.2.2
Formato dos resultados .......................................................................39
4.2.3
Diagrama de classes ...........................................................................42
4.2.4
Casos de uso .......................................................................................48
4.2.5
Diagrama de seqüência .......................................................................49
Implementação...................................................................................................54
5.1
Descrição da aplicação ...............................................................................54
8
6
5.2
Modelo de dados integrador relacional .......................................................57
5.3
Modelo de dados integrador XML ...............................................................60
5.4
Implementação............................................................................................64
Conclusões ........................................................................................................67
6.1
Resultados ..................................................................................................67
6.2
Contribuições ao CoDIMS...........................................................................67
6.3
Dificuldades Encontradas ...........................................................................68
6.4
Trabalhos Futuros.......................................................................................68
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.
10
1.2 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.
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
Figura 1 :
Fonte de
Dados 3
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
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.
13
2.2 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
Fonte de
Dados 1
Fonte de
Dados 2
Figura 2 :
W3
Fonte de
Dados 3
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.
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.
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”;
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 2.3.1 e 2.3.2 são mostrados como se define uma DTD e um XML
Schema.
2.3.1 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
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 2.3.4 e
2.3.5.
2.3.2 XML Squema
A DTD é uma especificação da W3C e possui as seguintes limitações:
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 www.w3.org (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-8859-1”?>
<cadastro xmlns=”x-schema:valida.xml”>
<nome>José da Silva</nome>
<end>Rua das Américas</end>
<fone comercial=”sim”>5455-2212</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.
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;
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 2.3.4 e 2.3.5,
porém, antes disso, na próxima seção é explicado o termo namespace utilizado
anteriormente.
2.3.3 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.
21
<?xml version=”1.0”?>
<lojaVirtualA:produto
xmlns:lojaVirtualA=”http://www.lojavirtuala.com”
xmlns:shoppingVirtualB=”http://www.shoppingvirtualb.com”>
<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)
2.3.4 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.
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-8859-1”?>
<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)
23
2.3.5 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
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.
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.
3.1.1 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.
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.
3.1.2 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.
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 € 800.00
(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.
28
3.1.3 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:
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.
3.1.4 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.
3.1.4.1 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.
3.1.4.2 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;
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.
3.1.5 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 XMLSQL” (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.
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.
32
Componente
Controle
Componente
Processamento
de Consultas
Figura 10 :
Componente
Metadados
Componente
Acesso aos
Dados
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.
33
Consulta formulada
pelo usuário
Processador de
Consultas
Analisador
Gerência de
Metadados
Reescritor
Componente
Controle
Otimizador
MEC
Acesso aos Dados
Subconsulta 1
Subconsulta 2
Wrapper 1
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;
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.
35
4.2 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.
4.2.1 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.
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.
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)
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.
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.
4.2.2 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;
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:
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
42
possam ser feitas. Dessa forma, nas próximas seções são apresentados os
diagramas de classe e de seqüência e os casos de uso.
4.2.3 Diagrama de classes
Na Figura 16 são mostradas as classes necessárias para o desenvolvimento dos
wrappers do CoDIMS.
Wrapper
Wrapper XML
Wrapper Rel
executarS ubConsulta()
executarSubConsulta()
a)
Executor
Conversor
execut a()
converte()
Converte Rel
SQL
Converte XML
SQL
converte()
converte()
Converte XML
Converte ResultSet
XML
converte()
converte()
Executa Rel
XML
Executa SQL
Rel
Executa XML
XML
executa()
execut a()
executa()
b)
c)
XML Parser
Mont a SQL
montaSelectFromSQL()
montaCondicaoSQL()
transfString()
d)
getPageElement()
obterAtributos()
obterAtributosValorArvore()
obterElemsArvore()
obterAtributosValorElemento()
tamanhoElementos()
geraArquivoXML()
Banco
consulta()
fechaConexao()
abreConexao()
f)
e)
Figura 16 :
As classes dos wrappers
As classes acima desempenham os seguintes papéis:
a)
43
•
Wrapper: É uma interface. Possui o método ExecutarSubconsulta() que é
implementado pelos wrappers;
•
Wrapper XML: É o wrapper da fonte de dados XML. É responsável pelo
controle da transformação do formato de entrada para o formato XML e do
formato XML para o formato de entrada;
•
WrapperRel: É o wrapper da fonte de dados relacional. É responsável pelo
controle da transformação do formato de entrada para o formato relacional e
do formato relacional para o formato de entrada.
b)
•
Conversor: Responsável pelas conversões entre modelos de dados. É a
classe que será herdada pelas classes conversoras específicas. Possui o
método converte;
•
ConverteRelSQL: Responsável pela conversão da requisição de consulta
relacional para uma string SQL. Torna-se necessária devido à subconsulta vir
encapsulada em XML;
•
ConverteXMLSQL: Responsável pela conversão da requisição de consulta
XML para uma string SQL;
•
ConverteXML: Responsável por transformar a requisição de consulta em
parâmetros que serão executados na fonte de dados XML;
•
ConverteResultSetXML: Responsável pela conversão do ResultSet retornado
pelo banco de dados relacional para o arquivo de saída XML.
c)
•
Executor: Executa a subconsulta na fonte de dados. É chamada após a
requisição de consulta ser transformada para um modelo de dados
compreendido pela fonte;
•
ExecutaRelXML: Consulta na fonte de dados XML os parâmetros requeridos
na entrada e gera o arquivo de saída XML;
44
•
ExecutaSQLRel: Executa uma string SQL em um banco de dados relacional;
•
ExecutaXMLXML: Consulta na fonte de dados XML os parâmetros requeridos
na entrada e gera o arquivo de saída XML.
d)
•
Monta: Auxilia na construção de uma string SQL.
•
Banco: Realiza conexão, consulta e desconexão de um banco de dados.
•
XMLParser: Contém os parsers necessários para a manipulação de
e)
f)
documento XML.
Como quase todas as classes da Figura 16 interagem umas com as outras, para
facilitar a compreensão foi dividido o diagrama de classes de forma a representar os
wrappers individualmente e para cada suposição da MEC.
Na figura 17 temos o wrapper relacional para o formato de dados da MEC também
relacional.
45
Converte ResultSet XML
converte()
Executa SQL Rel
executa()
Banco
Wrapper Rel
executarSubConsulta()
consulta()
fechaConexao()
abreConexao()
XML Parser
Converte Rel SQL
c onverte()
getPageElement()
obterAtributos()
obterAtributosValorArvore()
obterElemsArvore()
obterAtributosValorElemento()
tamanhoElementos()
geraArquivoXML()
Monta SQL
montaSelectFromSQL()
montaCondicaoSQL()
transfString()
Figura 17 :
Wrapper relacional para MEC relacional
Na figura 18 temos o wrapper relacional para o formato de dados da MEC XML.
46
Converte ResultSet XML
converte()
Executa SQL Rel
executa()
Banco
Wrapper Rel
executarSubConsulta()
consulta()
fechaConexao()
abreConexao()
XML Parser
Converte XML SQL
converte()
getPageElement()
obterAtributos()
obterAtributosValorArvore()
obterElemsArvore()
obterAtributosValorElemento()
tamanhoElementos()
geraArquivoXML()
Monta SQL
montaSelectFromSQL()
montaCondicaoSQL()
transfString()
Figura 18 :
Wrapper relacional para MEC XML
Na figura 19 temos o wrapper XML para o formato de dados da MEC relacional.
47
Convert e XML
converte()
Wrapper XML
executarSubConsulta()
Executa Rel XML
executa()
XML Parser
getPageElement()
obterAtributos()
obterAtributosValorArvore()
obterElemsArvore()
obterAtributosValorElemento()
tamanhoElementos()
geraArquivoXML()
Figura 19 :
Wrapper XML para MEC relacional
Na figura 20 temos o wrapper XML para o formato de dados da MEC XML.
Converte XML
converte()
Wrapper XML
executarS ubConsul ta()
XML Parser
getPageEl ement()
obterAtribut os()
obterAtribut osValorArvore()
obterElemsArvore()
obterAtribut osValorElement o()
t amanhoElement os()
geraArquivoXML()
Figura 20 :
Wrapper XML para MEC XML
Executa XML XML
executa()
48
Após a apresentação das classes, visto que o wrapper pode receber diferentes
requisições, tona-se necessário a especificação dos casos de uso.
4.2.4 Casos de uso
Para a situação em que a MEC é relacional, o caso de uso está descrito na Figura
21. A MEC Relacional enviará subconsultas no formato relacional, sendo que uma
subconsulta será enviada para o wrapper da fonte de dados relacional (Consultar
Base Relacional) e outra subconsulta será enviada para o wrapper da fonte de
dados XML (Consultar Base XML). As fontes serão consultadas, cada uma por seu
wrapper, e os dados resultantes da consultas serão enviados no formato de um
arquivo XML para a MEC Relacional.
Consultar Bas e Relacional
ME C Relacional
Consultar Base XML
Figura 21 :
Casos de uso - MEC relacional
Para a situação em que a MEC é XML, o caso de uso está descrito na Figura 22. A
MEC XML também enviará subconsultas, porém agora no formato XML, sendo que
uma subconsulta será enviada para o wrapper da fonte de dados relacional
(Consultar Base Relacional) e outra subconsulta será enviada para o wrapper da
fonte de dados XML (Consultar Base XML). As fontes serão consultadas, cada uma
por seu wrapper, e os dados resultantes das consultas serão enviados no formato de
um arquivo XML para a MEC XML.
49
Consultar Relacional
ME C XML
Consult ar XM L
Figura 22 :
Casos de uso – MEC XML
Para cada subconsulta diferente enviada, o wrapper deve se comportar percorrendo
classes diferentes de maneira que consiga atender às requisições e retornar os
resultados esperados. A seqüência de classes a ser percorrida para cada caso de
uso é especificada em diagrama de seqüência.
4.2.5 Diagrama de seqüência
Os diagramas de seqüência abaixo mostram a seqüência de execução dos métodos
a serem chamados para atender a cada caso de uso.
50
: MEC Relacional
: Wrapper Rel
: Banco
: Converte Rel
SQL
: Monta SQL
: Executa SQL
Rel
: Converte
ResultSet XML
: XM L Parser
abreConexao( )
converte( )
getPageElement( )
obterAtributos( )
montaSelectFromSQL( )
mont aCondicaoS QL( )
executa( )
cons ulta( )
converte( )
fechaConexao( )
Figura 23 :
Diagrama de seqüência: Relacional x Relacional
51
: MEC Relacional
: Wrapper XML
: Converte XML
: XML Parser
: Executa Rel
XML
converte( )
getPageElement( )
obterAtributosValorArvore( )
obterAtributosValorElemento( )
executa( )
geraArquivoXML( )
Figura 24 :
Diagrama de seqüência: Relacional x XML
52
: MEC XML
: Wrapper Rel
: Banco
: Converte XML
SQL
: Monta SQL
: Executa SQL
Rel
: Converte
ResultSet XML
: XML Parser
abreConexao( )
converte( )
getPageElement( )
obterAtributos( )
montaSelectFromSQL( )
montaCondicaoSQL( )
executa( )
consulta( )
converte( )
fechaConexao( )
Figura 25 :
Diagrama de seqüência: XML x Relacional
53
: MEC XML
: Wrapper XML
: Converte XML
: XML Parser
: Executa XML
XML
converte( )
getPageElement( )
obterAtributosValorArvore( )
obterAtributosValorElemento( )
execut a( )
geraArquivoXML( )
Figura 26 :
Diagrama de seqüência: XML x XML
54
5 Implementação
Neste capítulo é apresentada a implementação de dois wrappers para o CoDIMS,
um para uma fonte de dados relacional e outro para uma fonte de dados XML,
atendendo a subconsultas nos formatos XML e relacional.
5.1 Descrição da aplicação
Uma Organização Não Governamental (ONG), “Rios e Lagos”, exemplo utilizado em
(BARBOSA, 2001), deseja controlar a pesca predatória e necessita integrar
informações dos desembarques pesqueiros realizados em uma determinada região
e dos dados científicos das espécies de peixes que se deseja controlar. Em cada
local de desembarque existe um sistema de entrada de dados que alimenta uma
base de dados central que armazena informações sobre cada um dos
desembarques realizados. Em um banco de dados científico de uma empresa de
pesquisa do governo, existem informações sobre as diversas espécies de peixes
que habitam a região. O que a ONG deseja conhecer são informações sobre a
pesca de espécies em período de reprodução e quantidade pescada de cada uma
das espécies. Para isso é necessário o acesso e a integração destas duas fontes de
dados distribuídas e heterogêneas.
A fonte de dados “Desembarque” tem seus dados armazenados segundo o modelo
XML, com a seguinte descrição:
55
<!ELEMENT pesca>
<!ATTLIST pesca
Cod-desembarque CDATA #REQUIRED
cod-local CDATA #REQUIRED
dia-desembarque CDATA #REQUIRED
mes-desembarque CDATA #REQUIRED
ano-desembarque CDATA #REQUIRED
cod-especie CDATA #REQUIRED
qtde-Kg CDATA #REQUIRED
cod-tipo-embarcação CDATA #REQUIRED
cod-aparelho-pesca CDATA #REQUIRED
qtde-pescadores CDATA #REQUIRED
qtde-dias-pesca CDATA #REQUIRED>
>
Figura 27 :
Modelo de dados da fonte XML desembarque
O banco de dados “Pesquisa” está armazenado em um ambiente relacional, com o
seguinte esquema:
Tabela
Atributo
Especie
cod-especie
mes-reproducao
nome-vulgar
Tabela 1 :
Tipo
Long
Int
char(15)
Modelo de dados da fonte relacional Pesquisa
Para exemplificar foi construído o arquivo Desembarque.xml conforme a Figura 28 e
a tabela Espécie conforme a Tabela 2 no banco de dados Microsoft Access 2003. O
documento XML e o banco de dados acima citados estão localizados na mesma
máquina para efeito de simulação.
56
<?xml version="1.0" encoding="ISO-8859-1"?>
<desembarque>
<pesca cod_desembarque = "1"
cod_local="1"
dia_desembarque="01"
mes_desembarque="02"
ano_desembarque="2004"
cod_especie="1"
qtde_kg="25"
cod_tipo_embarcacao ="1"
cod_aparelho_pesca="1"
qtde_pescadores="4"
qtde_dias_pesca="3" />
<pesca cod_desembarque = "2"
cod_local="1"
dia_desembarque="02"
mes_desembarque="03"
ano_desembarque="2004"
cod_especie="1"
qtde_kg="25"
cod_tipo_embarcacao ="1"
cod_aparelho_pesca="1"
qtde_pescadores="4"
qtde_dias_pesca="3" />
<pesca cod_desembarque = "3"
cod_local="1"
dia_desembarque="05"
mes_desembarque="04"
ano_desembarque="2004"
cod_especie="2"
qtde_kg="30"
cod_tipo_embarcacao ="5"
cod_aparelho_pesca="1"
qtde_pescadores="5"
qtde_dias_pesca="4" />
<pesca cod_desembarque = "4"
cod_local="1"
dia_desembarque="05"
mes_desembarque="05"
ano_desembarque="2004"
cod_especie="2"
qtde_kg="30"
cod_tipo_embarcacao ="5"
cod_aparelho_pesca="1"
qtde_pescadores="5"
qtde_dias_pesca="4" />
</desembarque>
Figura 28 :
Fonte de dados Desembarque.xml
57
cod_especie mes_reproducao nome_vulgar
1
2
perua
2
3
bagre
3
4
sardinha
4
1
dourado
5
2
cacao
Tabela 2 :
Fonte de dados Pesquisa.mdb
5.2 Modelo de dados integrador relacional
O primeiro exemplo ilustra a situação em que o modelo de dados interno do CoDIMS
é relacional. Nesse caso, as subconsultas enviadas para os wrappers serão sempre
no formato relacional encapsulado em XML. A Figura 29 esquematiza os modelos
de dados utilizados.
XML
Relacional
Wrapper
Desembarque
MECR
Desembarque
Acesso aos
Dados
Relacional
Wrapper
Pesquisa
Figura 29 :
Pesquisa
Modelo de dados utilizado
No caso da Figura anterior o Wrapper Desembarque é relacional x XML e o Wrapper
Pesquisa é relacional x relacional.
58
Suponha que a consulta no formato SQL enviada para o CoDIMS seja:
SELECT cod_local, dia_desembarque, mes_desembarque,
ano_desembarque, cod_especie, qtde_kg, mes_reproducao
FROM pesca p, especie e
WHERE p.mes_desembarque = e.mes_reproducao AND p.cod_especie =
e.cod_especie AND e. mes_reproducao = 2 AND p.mes_desembarque =
2
Figura 30 :
Consulta enviada ao CoDIMS no formato SQL
Essa consulta será transformada em um PEC otimizado (Felipe, 2004) e enviada à
MEC. Como o modelo de dados integrador é relacional, a MEC irá gerar as
subconsultas no formato relacional encapsuladas em XML e as mesmas vão chegar
aos wrappers relacional e XML conforme as Figuras 31 e Figura 32.
<?xml version="1.0" encoding="ISO-8859-1"?>
<local-plano>
<coluna ordem ="0" nome="cod_especie" tabela="Especie"/>
<coluna ordem ="1" nome="mes_reproducao" tabela="Especie"/>
<tabela nome="Especie"/>
<condicao argumentoesquerdo="mes_reproducao" operacao="igual"
argumentodireito="2" />
</local-plano>
Figura 31 :
Subconsulta enviada ao wrapper relacional
59
<?xml version="1.0" encoding="ISO-8859-1"?>
<local-plano>
<coluna ordem ="0" nome="cod_local" tabela="desembarque"/>
<coluna ordem ="1" nome="dia_desembarque"
tabela="desembarque"/>
<coluna ordem ="2" nome="mes_desembarque"
tabela="desembarque"/>
<coluna ordem ="3" nome="ano_desembarque"
tabela="desembarque"/>
<coluna ordem ="4" nome="cod_especie" tabela="desembarque"/>
<coluna ordem ="5" nome="qtde_kg" tabela="desembarque"/>
<tabela nome="desembarque"/>
<condicao argumentoesquerdo="mes_desembarque" operacao="igual"
argumentodireito="2" />
</local-plano>
Figura 32 :
Subconsulta enviada ao wrapper XML
O wrapper relacional irá transformar a subconsulta da Figura 31 em uma consulta
compreendida pela fonte de dados relacional, para este caso, a consulta da Figura
33. Essa consulta será processada pela fonte de dados relacional e esta retornará
um ResultSet para o wrapper relacional, que gerará um arquivo XML com essas
informações.
SELECT cod_especie, mes_reproducao
FROM Especie
WHERE mes_reproducao = “2”
Figura 33 :
Consulta transformada pelo wrapper relacional
O wrapper XML não transforma a subconsulta recebida para outro formato, pois, a
subconsulta já está no formato XML, visto que a subconsulta relacional é
encapsulada em XML.
O retorno dos wrappers para a MEC referente às subconsultas das Figuras 31 e 32
serão os caminhos dos arquivos (que estão descritos nas Figuras 34 e 35) no
60
formato
XML,
por
exemplo,
os
endereços
C:\
temp\TG1RS1.xml
e
C:\
temp\TG1RS2.xml, e o código de retorno “0”.
<?xml version="1.0" encoding="UTF-8"?>
<conjunto-resultado conjunto-completo="sim">
<tupla ordem="1">
<coluna ordem="1" nome="cod_especie" valor="1"/>
<coluna ordem="2" nome="mes_reproducao" valor="2"/>
</tupla>
<tupla ordem="2">
<coluna ordem="1" nome="cod_especie" valor="5"/>
<coluna ordem="2" nome="mes_reproducao" valor="2"/>
</tupla>
</conjunto-resultado>
Figura 34 :
Conjunto resultado do wrapper relacional
<?xml version="1.0" encoding="UTF-8"?>
<conjunto-resultado conjunto-completo="sim">
<tupla ordem="1">
<coluna ordem="1" nome="cod_local" valor="1"/>
<coluna ordem="2" nome="dia_desembarque" valor="01"/>
<coluna ordem="3" nome="mes_desembarque" valor="02"/>
<coluna ordem="4" nome="ano_desembarque"
valor="2004"/>
<coluna ordem="5" nome="cod_especie" valor="1"/>
<coluna ordem="6" nome="qtde_kg" valor="25"/>
</tupla>
</conjunto-resultado>
Figura 35 :
Conjunto resultado do wrapper XML
5.3 Modelo de dados integrador XML
Neste exemplo a situação é inversa e o modelo de dados interno do CoDIMS é XML,
portanto, as subconsultas enviadas para os wrappers serão sempre no formato XML.
A Figura 36 esquematiza os modelos de dados utilizados para esse novo cenário.
61
XML
XML
Wrapper
Desembarque
Desembarque
Acesso aos
MECX
Dados
Relacional
Wrapper
Pesquisa
Figura 36 :
Pesquisa
Modelo de dados utilizado
No caso da Figura anterior o Wrapper Desembarque é XML x XML e o Wrapper
Pesquisa é XML x relacional.
Suponhamos que a consulta, baseada na linguagem X-Query, enviada para o
CoDIMS seja:
FOR $pesca in document (“Pesca.xml”)//desembarque//pesca
LET $pesquisa in document (“Pesquisa.xml”)//pesquisa//especie
WHERE $pesca//@mes_desembarque = $pesquisa//@mes_reproducao
AND $pesca//@cod_especie = $pesquisa//@cod_especie
RETURN <conjunto-resultado>
<pesca-pesquisa cod_local = {$pesca//@cod_local }
dia_desembarque = {$pesca//@dia_desembarque}
mes_desembarque = {$pesca//@mes_desembarque}
ano_desembarque = {$pesca//@ano_desembarque}
cod_especie = {$pesca//@cod_especie}
qtde_kg = {$pesca//@qtde_kg}
mes_reproducao = {$pesquisa//@mes_reproducao}
</pesca-pesquisa>
</conjunto-resultado>
Figura 37 :
Consulta enviada ao CoDIMS no formato XQUERY
Essa consulta será transformada em um PEC otimizado (Felipe, 2004) e enviada à
MEC. Como o modelo de dados integrador é XML, a MEC irá gerar as subconsultas
no formato XML e as mesmas vão chegar aos wrappers relacional e XML conforme
as Figuras 38 e Figura 39.
62
<?xml version="1.0" encoding="ISO-8859-1"?>
<local-plano nome-arquivo="Pesquisa.mdb">
<elemento nome="Especie">
<atributo nome="cod_especie"/>
<atributo nome="mes_reproducao" />
</elemento>
</local-plano>
Figura 38 :
Subconsulta enviada ao wrapper relacional
<?xml version="1.0" encoding="ISO-8859-1"?>
<local-plano>
<coluna ordem ="0" nome="cod_local" tabela="desembarque"/>
<coluna ordem ="1" nome="dia_desembarque" tabela="desembarque"/>
<coluna ordem ="2" nome="mes_desembarque" tabela="desembarque"/>
<coluna ordem ="3" nome="ano_desembarque" tabela="desembarque"/>
<coluna ordem ="4" nome="cod_especie" tabela="desembarque"/>
<coluna ordem ="5" nome="qtde_kg" tabela="desembarque"/>
<tabela nome="desembarque"/>
</local-plano>
Figura 39 :
Subconsulta enviada ao wrapper XML
O wrapper relacional irá transformar a subconsulta da Figura 38 em uma consulta
compreendida pela fonte de dados relacional, para este caso, a consulta da Figura
40. Essa consulta será processada pela fonte de dados relacional e esta retornará
um ResultSet para o wrapper relacional, que gerará um arquivo XML com essas
informações.
SELECT cod_especie, mes_reproducao
FROM Especie
Figura 40 :
Consulta transformada pelo wrapper relacional
O wrapper XML não transforma a subconsulta recebida para outro formato, pois, a
subconsulta já está no formato XML.
63
O retorno dos wrappers para a MEC referente a essas subconsultas serão os
caminhos dos arquivos (que estão descritos nas Figuras 41 e 42) no formato XML,
por exemplo, os endereços C:\ temp\TG2RS1.xml e C:\ temp\TG2RS2.xml, e o
código de retorno “0”.
<?xml version="1.0" encoding="UTF-8"?>
<conjunto-resultado conjunto-completo="sim">
<elemento ordem="1">
<atributo ordem="1" nome="cod_especie" valor="1"/>
<atributo ordem="2" nome="mes_reproducao" valor="2"/>
</elemento >
<elemento ordem="2">
<atributo ordem="1" nome="cod_especie" valor="2"/>
<atributo ordem="2" nome="mes_reproducao" valor="3"/>
</elemento >
<elemento ordem="3">
<atributo ordem="1" nome="cod_especie" valor="3"/>
<atributo ordem="2" nome="mes_reproducao" valor="4"/>
</elemento >
<elemento ordem="4">
<atributo ordem="1" nome="cod_especie" valor="4"/>
<atributo ordem="2" nome="mes_reproducao" valor="1"/>
</elemento >
<elemento ordem="5">
<atributo ordem="1" nome="cod_especie" valor="5"/>
<atributo ordem="2" nome="mes_reproducao" valor="2"/>
</elemento >
</conjunto-resultado>
Figura 41 :
Conjunto resultado do wrapper relacional
64
<?xml version="1.0" encoding="UTF-8"?>
<conjunto-resultado conjunto-completo="sim">
<elemento ordem="1">
<atributo ordem="1" nome="cod_local" valor="1"/>
<atributo ordem="2" nome="dia_desembarque" valor="01"/>
<atributo ordem="3" nome="mes_desembarque" valor="02"/>
<atributo ordem="4" nome="ano_desembarque" valor="2004"/>
<atributo ordem="5" nome="cod_especie" valor="1"/>
<atributo ordem="6" nome="qtde_kg" valor="25"/>
</elemento >
<elemento ordem="2">
<atributo ordem="1" nome="cod_local" valor="1"/>
<atributo ordem="2" nome="dia_desembarque" valor="03"/>
<atributo ordem="3" nome="mes_desembarque" valor="03"/>
<atributo ordem="4" nome="ano_desembarque" valor="2004"/>
<atributo ordem="5" nome="cod_especie" valor="1"/>
<atributo ordem="6" nome="qtde_kg" valor="25"/>
</elemento >
<elemento ordem="3">
<atributo ordem="1" nome="cod_local" valor="1"/>
<atributo ordem="2" nome="dia_desembarque" valor="05"/>
<atributo ordem="3" nome="mes_desembarque" valor="04"/>
<atributo ordem="4" nome="ano_desembarque" valor="2004"/>
<atributo ordem="5" nome="cod_especie" valor="2"/>
<atributo ordem="6" nome="qtde_kg" valor="30"/>
</elemento >
<elemento ordem="4">
<atributo ordem="1" nome="cod_local" valor="1"/>
<atributo ordem="2" nome="dia_desembarque" valor="05"/>
<atributo ordem="3" nome="mes_desembarque" valor="05"/>
<atributo ordem="4" nome="ano_desembarque" valor="2004"/>
<atributo ordem="5" nome="cod_especie" valor="2"/>
<atributo ordem="6" nome="qtde_kg" valor="30"/>
</elemento >
</conjunto-resultado>
Figura 42 :
Conjunto resultado do wrapper XML
5.4 Implementação
Conforme mostrado anteriormente o wrapper desenvolvido atende aos quatro casos
de uso, a seguir:
•
Subconsulta XML e execução em fonte de dados relacional;
•
Subconsulta relacional e execução em fonte de dados relacional;
•
Subconsulta XML e execução em base XML;
65
•
Subconsulta relacional e execução em base XML.
Para atender às situações acima e facilitar o entendimento da execução dos
wrappers, foi construída uma aplicação para simular as requisições de consultas
enviadas pela MEC.
Essa aplicação foi desenvolvida utilizando a linguagem de programação Java e o
ambiente de desenvolvimento NetBeans IDE 3.6.
A API escolhida para a manipulação de XML nessa aplicação foi o DOM. A
vantagem é que o DOM acessa aleatoriamente a estrutura de árvore XML, ou seja, o
nó pode ser criado ou anexado a qualquer momento e em qualquer lugar da árvore
XML. Além disso, o DOM evita relacionamentos inadequados de pai-filho e
informações associadas, garantindo assim, boa formação e gramática adequada.
Um problema que teríamos com o SAX é que essa API não tem métodos que
permitem a alteração do documento gerado, ela o acessa apenas em modo de
leitura.
A aplicação atende a todos os quatro casos de uso, utilizando internamente os
wrappers separadamente dependendo da solicitação. A tela principal da aplicação
pode ser visualizada na Figura 43.
As entradas da tela principal devem ser configuradas da seguinte forma:
•
Consulta: é escolhido se o formato de dados do CoDIMS é relacional ou XML;
•
Fonte: é marcado a qual tipo de fonte se deseja aplicar a saída;
•
Local da fonte: é colocado o caminho em que se encontra a fonte, sendo o
caminho de um arquivo XML no caso de fonte de dados XML e o caminho de
um arquivo com extensão ini no caso de um banco de dados relacional. O
arquivo com extensão ini contém os parâmetros de conexão com o banco de
dados;
•
Local da consulta: é preenchido com o caminho em que se encontra o arquivo
que contém a consulta. Esse arquivo será sempre do tipo XML;
66
•
Arquivo de saída: é preenchido com o caminho do arquivo para onde serão
enviados os dados de saída. Esse arquivo será sempre do tipo XML.
Figura 43 :
Tela da aplicação
67
6 Conclusões
Este capítulo apresenta as conclusões finais abordando os resultados deste
trabalho, contribuições e trabalhos futuros.
6.1 Resultados
Os resultados obtidos foram satisfatórios, uma vez que os objetivos deste trabalho
foram alcançados. Foram implementados dois wrappers, um para fonte de dados
relacional e o outro para fonte de dados XML, que poderão ser incluídos ao CoDIMS
permitindo execução de subconsultas em duas bases de dados diferentes e
distribuídas.
6.2 Contribuições ao CoDIMS
Este trabalho gerou as seguintes contribuições para o CoDIMS:
•
Implementação dos wrappers para fonte de dados relacional e para fonte de
dados XML, permitindo execução de subconsultas em duas fontes de dados
diferentes e distribuídas;
•
Definição de um novo padrão utilizado para o retorno dos dados provenientes
dos wrappers, otimizando as informações do conjunto-resultado;
•
Definição de um padrão utilizado para o retorno dos dados provenientes do
wrapper XML;
•
Definição do código de retorno que deverá ser retornado pelo wrapper para a
MEC, tornando possível o conhecimento, pela MEC, dos status das fontes de
dados.
68
6.3 Dificuldades Encontradas
Durante o desenvolvimento deste trabalho foram encontradas algumas dificuldades,
como:
•
Entendimento inicial do CoDIMS;
•
Dificuldade na obtenção de aplicações similares para análise de técnicas
utilizadas, devido ao assunto abordado ser atual.
6.4 Trabalhos Futuros
A partir das contribuições conseguidas neste trabalho, notamos que ainda existem
alguns outros trabalhos a serem desenvolvidos para o CoDIMS no que se refere a
wrappers, como:
•
Implementação de wrappers para outros tipos de fontes de dados, como
banco de dados Orientado a Objetos, planilha etc;
•
Refinamento dos códigos de retorno devolvidos pelos wrappers para a MEC;
•
Execução paralela dos wrappers em um ambiente de grid;
•
Revisão dos formatos de consulta entre os componentes e revisão da
máquina de execução de consultas do CoDIMS para que os componentes
desenvolvidos possam ser integrados;
•
Alteração da DTD do arquivo resultado XML para atender os casos em que o
documento XML tem vários níveis;
•
Execução dos wrappers em um ambiente multiusuário de forma que os
wrappers recebam várias subconsultas enfileiradas.
69
Referências Bibliográficas
1. ALHANDRA, Hugo. O XML nas bases de dados. Trabalho da cadeira Integração
de Sistemas Informação, Lisboa, Portugal, 2001.
2. BARBOSA, Álvaro Cesar Pereira. Middleware para Integração de Dados
Heterogêneos Baseado em Composição de Frameworks, Tese de doutorado, Rio
de Janeiro, 2001.
3. BRAGANHOLO, V. P.; DAVIDSON, S. B.; HEUSER, C. A. UXQuery: Building
Updatable XML Views over Relacional Databases. UFRGS. Disponível em:
<http://www.inf.ufrgs.br/~vanessa/artigos/sbbd2003.pdf>. Acesso em: 09 dez.
2004.
4. COSTA, Luiz Alberto Gibson da. Namespaces e Tradução de Diagrama de
Classe em UML para XML Schema. UFRJ, Rio de Janeiro, 2003. Disponível em:
<http://www.freezope.org/Members/luiz_gibson/monografias>.
Acesso em: 02
mar. 2005.
5. GRAVES, Mark. Projeto de Banco de Dados com XML. 1. ed. São
Paulo: Pearson Education do Basil, 2003.
6. LOTAR, Alfredo. XML para Programadores ASP. Rio de Janeiro: Axcel Books do
Brasil, 2001.
7. NOTARI, Daniel Luís. Relatório de Pesquisa: Implementação de um Wrapper
para a linguagem XML-SQL. UFRGS, Instituto de Informática, Porto Alegre.
Disponível em: <http://metropole.inf.ufrgs.br/wrapper/>. Acesso em: 10. dez 2004.
8. PINHEIRO, Felipe Santos.
Incorporando uma máquina de execução de
consultas ao CoDIMS. Monografia de Graduação, Vitória, ES, 2004.
9. SHANMUGASUNDARAM, J.; SHEKITA, E.; KIERNAN, J.; KRISHNAMURTHY,
R.; VIGLAS, E.; NAUGHTON, J.; TATARINOV, I. A General Technique for
Querying XML Documents using a Relational Database System. Disponível em:
<http://www.cs.cornell.edu/people/jai/papers/GeneralXMLQuerying.pdf>. Acesso
em: 10 dez. 2004.