Integrando BD XML

UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PS-GRADUAO EM CINCIAS DA COMPUTAO
Mauri Ferrandin
INTEGRANDO BANCOS DE DADOS HETEROGNEOS ATRAVS DO PADRO XML
Dissertao submetida Universidade Federal de Santa Catarina como parte dos requisitos para obteno do grau de Mestre em Cincia da Computao
Prof. Murilo Silva de Camargo, Dr.
Florianpolis, setembro 2002
ii
UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PS-GRADUAO EM CINCIAS DA COMPUTAO
Mauri Ferrandin
Dissertao submetida Universidade Federal de Santa Catarina como parte dos requisitos para obteno do grau de Mestre em Cincia da Computao
Prof. Murilo Silva de Camargo, Dr.
Florianpolis, outubro 2002
iii
Mauri Ferrandin
Esta Dissertao foi julgada adequada para a obteno do ttulo de Mestre em Cincia da Computao rea de Concentrao Sistemas de Computao e aprovada em sua forma final pelo Programa de Ps-Graduao em Cincia da Computao.
________________________________
Professor Fernando Ostuni Gauthier, Dr.
Banca Examinadora ________________________________

Professor Murilo Silva de Camargo, Dr (orientador)
________________________________
Professor Roberto Willrich, Dr.
________________________________
Professor Rosvelter J. Coelho da Costa, Dr.
iv
Existem poucas coisas que jamais sero tiradas de um homem, o conhecimento com certeza uma delas.
A todos que acreditam que a educao um fundamento para construo de uma sociedade mais justa, e buscam a luz da cincia construir um mundo melhor procurando respostas para os desafios do mundo moderno.
vi
AGRADECIMENTOS
Agradeo a Deus, a minha famlia, aos amigos, a Universidade Federal de Santa Catarina, ao Centro Universitrio de Jaragu do Sul (SC).
vii
SUMRIO
AGRADECIMENTOS ...................................................................................................................... VI SUMRIO ........................................................................................................................................ VII RESUMO........................................................................................................................................... IX ABSTRACT......................................................................................................................................... X LISTA DE FIGURAS E TABELAS.................................................................................................. XI LISTAGENS DE CDIGO FONTE................................................................................................ XII LISTA DE SIGLAS.........................................................................................................................XIII 1. INTRODUO................................................................................................................................2 1.1. 1.2. 1.3. 1.4. 1.5. 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. MOTIVAO .............................................................................................................................3 OBJETIVOS ................................................................................................................................3 METODOLOGIA .........................................................................................................................4 TRABALHOS CORRELACIONADOS ...............................................................................................4 ORGANIZAO DO TEXTO .........................................................................................................4
2. BANCOS DE DADOS DISTRIBUDOS E HETEROGNEOS.....................................................7 CONCEITOS BSICOS .................................................................................................................7 REQUISITOS FUNCIONAIS DE UM SGBDD ...................................................................................8 FATORES NEGATIVOS NA UTILIZAO DE SGBDD....................................................................10 ARQUITETURAS PARA SGBDD ................................................................................................10 SISTEMAS HOMOGNEOS E SISTEMAS HETEROGNEOS .............................................................12 BANCO DE DADOS DISTRIBUDO HETEROGNEO.......................................................................13 2.6.1. Sistemas Multidatabase.................................................................................................13 2.6.2. Sistema Federado e No Federado................................................................................14 2.6.3. Sistemas Legados..........................................................................................................14 2.7. TCNICAS E FERRAMENTAS DE INTEGRAO............................................................................15 2.7.1. Integrao atravs de modelos que especificam um esquema conceitual global..............16 2.7.2. O processo de integrao e traduo de esquemas ........................................................17 2.7.3. Mediadores...................................................................................................................19 2.7.4. Wrappers......................................................................................................................21 2.8. EXEMPLOS DE SISTEMAS GERENCIADORES DE BANCOS DE DADOS HETEROGNEOS ...................22 2.8.1. Multidatabase [Buretta, 1997] ......................................................................................23 2.8.2. Projeto Jupter [Murphy e Grimson, 1995].....................................................................25 2.8.3. HEROS - HetERogeneous Object System [Castro, 1998] ...............................................26 2.8.4. DDTS - Distributed Database Testbed System [Buretta, 1997] ......................................28 2.9. COMENTRIOS FINAIS .............................................................................................................30 3. A LINGUAGEM XML ..................................................................................................................31 3.1. 3.2. 3.3. 3.4. CONCEITOS BSICOS ...............................................................................................................31 IMPORTNCIA DA XML...........................................................................................................33 XML E HTML........................................................................................................................34 COMPONENTES DE UM DOCUMENTO XML................................................................................35 3.4.1. Elementos.....................................................................................................................35 3.4.2. Atributos.......................................................................................................................36 3.4.3. Outros componentes da XML ........................................................................................37
viii
3.5. ESTRUTURA LGICA DE UM DOCUMENTO XML ........................................................................39 3.5.1. Expresses de Caminho ( Path expressions) ..................................................................40 3.5.2. Xpath............................................................................................................................41 3.6. XML E DADOS SEMI-ESTRUTURADOS ......................................................................................42 3.7. LINGUAGENS PARA ESQUEMAS ................................................................................................42 3.7.1. Document Type Definition (DTD)..................................................................................43 3.7.2. XML Schema ................................................................................................................44 3.7.3. XDR .............................................................................................................................48 3.7.4. SOX..............................................................................................................................49 3.7.5. Schematron...................................................................................................................49 3.7.6. DSD .............................................................................................................................49 3.7.7. Tabela comparativa ......................................................................................................49 3.8. LINGUAGENS DE CONSULTA PARA DADOS XML .......................................................................51 3.8.1. Requisitos de uma linguagem de consulta para dados XML ...........................................51 3.8.2. Exemplo de linguagem de consulta para dados XML (XML-QL) ....................................52 3.8.3. Outras linguagens de consultas para dados XML ..........................................................57 3.9. APIS PARA XML.....................................................................................................................59 3.9.1. SAX ..............................................................................................................................59 3.9.2. DOM ............................................................................................................................60 3.10. INTEGRIDADE EM DOCUMENTOS XML............................................................................62 3.11. COMENTRIOS FINAIS ....................................................................................................64 4. INTEGRAO DE FONTES HETEROGNEAS DE DADOS UTILIZANDO XML ...............65 4.1. REPRESENTANDO BASES DE DADOS RELACIONAIS COM XML...................................................65 4.2. VISES XML ..........................................................................................................................68 4.2.1. Atualizao de vises....................................................................................................70 4.2.2. Dimenses do problema de atualizao de vises ..........................................................72 4.3. ALGUMAS PROPOSTAS EXISTENTES DE INTEGRAO UTILIZANDO VISES MATERIALIZADAS .......72 4.3.1. Sistema ARGOS............................................................................................................72 4.3.2. MIX (Metadata based Integration model for data X-change)..........................................74 4.3.3. SilkRoute ......................................................................................................................76 4.3.4. Resumo comparativo entre as principais abordagens ....................................................77 4.4. COMENTRIOS FINAIS .............................................................................................................78 5. MODELO PARA INTEGRAO DE FONTES HETEROGNEAS DE DADOS.....................79 5.1. VISO GERAL DO SISTEMA PROPOSTO.......................................................................................79 5.2. DESENVOLVIMENTO DO PROTTIPO .........................................................................................81 5.2.1. Definio dos Requisitos...............................................................................................81 5.2.2. Projeto .........................................................................................................................81 5.2.3. Especificaes atravs de UML.....................................................................................90 5.2.4. Implementao .............................................................................................................92 5.2.5. Exemplo de utilizao do prottipo ...............................................................................92 5.3. COMENTRIOS FINAIS .............................................................................................................97 6. ANLISE E INTERPRETAO DOS RESULTADOS ..............................................................98 6.1. VANTAGENS DO SISTEMA PROPOSTO ........................................................................................98 6.2. DESVANTAGENS DO SISTEMA PROPOSTO ..................................................................................99 7. CONCLUSES E PERSPECTIVAS FUTURAS........................................................................ 100 7.1. 7.2. 7.3. 7.4. RESUMO ............................................................................................................................... 100 COMPARAO COM AS SOLUES EXISTENTES ....................................................................... 101 PONTOS FRACOS E PONTOS FORTES ........................................................................................ 102 PERSPECTIVAS FUTURAS ........................................................................................................ 102
8. REFERNCIAS BIBLIOGRFICAS......................................................................................... 104 9. APNDICE .................................................................................................................................. 109
ix
RESUMO
Com objetivo de organizar e estruturar o armazenamento das informaes necessrias s organizaes, SGBDs so utilizados a fim de prover o acesso de maneira gil, eficiente e segura a estas informaes pelas aplicaes. Os dados armazenados em um SGBD so organizados de acordo com um esquema definido em cada organizao, assim, quando estas precisam integrar/trocar informaes armazenadas em seus respectivos bancos de dados, vrios problemas surgem devido a heterogeneidade dos esquemas ou plataformas de hardware/software, necessitando de uma estrutura capaz de mediar tal intercmbio. Para prover a integrao de diversos bancos de dados heterogneos, so utilizados os Sistemas Gerenciados de Bancos de Dados Distribudos Heterogneos, que controlam e possibilitam as aplicaes acesso de maneira transparente aos dados distribudos entre as bases heterogneas. Com a especificao do padro XML, o mesmo passou a ser utilizado para intercmbio de dados, uma vez que capaz de agregar a seu contedo informaes que o descrevem(metadados), possibilitando assim a representao de dados que no poderiam ser representadas atravs do modelo relacional utilizado pela maioria dos SGBDs. Com o padro XML possvel ento a criao de vises materializadas dos dados armazenados em um SGBD local e utilizar esta viso para os mais variados fins. O presente trabalho apresenta uma proposta de um sistema capaz de prover o acesso - de maneira integrada e transparente para as aplicaes s informaes armazenadas em bases heterogneas e distribudas, utilizando o padro XML para representa-las atravs da criao de vises materializadas dos dados presentes em cada uma das bases a serem integradas, agrupando posteriormente as diversas vises em uma nica viso XML. Tal integrao traz a tona uma srie de questes a serem tratadas, como a integridade dos dados que antes era controlada por cada um dos SGBDs e que agora precisa ser observada na viso integrada para garantir que os dados nela presentes possuam a mesma integridade, possibilitando assim que haja um serializao dos dados entre a viso e as bases distribudas sem que ocorram problemas de integridade. Palavras Chaves : Integrao de Banco de Dados Distribudos Heterogneos, XML.
ABSTRACT
With the objective of organize and to structuralize the storage of information necessary to the organizations, databases are used in order to provide agile, efficient secure access to these information for the applications. The data stored in a database are structuralized and organized in accordance with a project defined in each organization, thus, when two or more of those needs to integrate or exchange informations stored in its respective databases, some problems appear due the heterogenity of projects or hardware/software plataform, needing a structure capable to mediate such interchange. To provide the integration between heterogeneous databases, Distributed Heterogeneous Databases Management Systems are used, they control and make possible the applications access in transparent way to the data distributed between the heterogeneous bases. With the specification of the XML standard, it passed to be used for interchange of data, a time that its capable to add to its content informations that describe it (metadata), making possible the representation of data that could not be represented through the relational model actually used by the majority of the databases. With the XML standard, its possible create materialized views of the data stored in a local Database Managment System and use this data for the most varied ends. This work presents a proposal of a system capable to provide the access in a way integrated and transparent for the applications - to the information stored in heterogeneous and distributed databases, using XML standard for represent the data through the creation of materialized views of the data stored in each one of the bases to be integrated, grouping later the diverse views in an integrated XML view. Such integration brings a lot of questions to be considered, like the integrity of data that before was controlled by every database and that now this integrity needs to be observed in the integrated view to guarantee that those data will preserve the same integrity, making possible a serialization between the view and the distributed databases without occur integrity problems. Keywords: Distributed Heterogeneous Databases Systems Integration, XML.
xi
LISTA DE FIGURAS E TABELAS

Figura 1 : Arquitetura de um banco de dados distribudo. ........................................................................7 Figura 2 : Arquitetura data-lgica de SGBD distribudo. .......................................................................11 Figura 3 : Arquitetura data-lgica de multi-SGBD ................................................................................12 Figura 4 : Sistema Multidatabase (com usurios locais e globais)..........................................................14 Figura 5 : Arquitetura com esquema conceitual global ..........................................................................17 Figura 6 : Integrao de Bancos de dados: traduo e integrao ...........................................................18 Figura 7 : Arquitetura Bsica dos Mediadores. ......................................................................................20 Figura 8 : Arquitetura Bsica dos Mediadores com auxlio dos wrappers...............................................22 Figura 9 : Arquitetura do SGBDD-H Multidatabase ..............................................................................24 Figura 10 : Arquitetura do Jupter. .........................................................................................................26 Figura 11 : Arquitetura de esquemas do HEROS ...................................................................................27 Figura 12 : Componentes de Software do DDTS ....................................................................................29 Figura 13 : Estrutura em rvore de um documento XML. ......................................................................40 Figura 14 : Arvore XML contendo base de dados bibliogrfica..............................................................41 Figura 15 : Representao lgica de uma tabela HTML em um DOM....................................................61 Figura 16 : Representao de dados relacionais em rvore exemplo 01. ..............................................66 Figura 17 : Representao de dados relacionais em rvore exemplo 02. ..............................................66 Figura 18 : Representao de dados relacionais em rvore exemplo 03 ...............................................67 Figura 19 : Arquitetura geral do Sistema ARGOS .................................................................................73 Figura 20 : Arquitetura MIX. ................................................................................................................75 Figura 21 : Arquitetura geral do Sistema SilkRoute ...............................................................................76 Figura 22 : Modelo proposto para integrar fontes heterogneas de dados................................................80 Figura 23 : API JDBC...........................................................................................................................84 Figura 24 : Modelo proposto utilizando o wrapper DB2XML................................................................84 Figura 25 : Integrao das vises XML locais em uma viso XML integrada.........................................85 Figura 26 : Violao de chave primria na viso integrada XML. ..........................................................87 Figura 27 : Insero de um registro na viso integrada de acordo com as regras de chave estrangeira. ....88 Figura 28 : Funcionamento do gerenciador de consultas. .......................................................................89 Figura 29 : Diagrama de classes do prottipo proposto. .........................................................................91 Figura 30 : Diagrama de casos de uso do prottipo proposto..................................................................91 Figura 31 : Tela inicial do prottipo. .....................................................................................................93 Figura 32 : Visualizando a viso XML integrada dos dados...................................................................94 Figura 33 : Exemplo de violao de chave primria...............................................................................95 Figura 34 : Exemplo de violao de chave estrangeira. ..........................................................................95 Figura 35 : Exemplo de insero de um registro na viso XML integrada. .............................................96 Figura 36 : Consulta recuperando todos os registros de pacientes em todas as bases. ..............................96
Tabela 1 : SGBDD: fatores complicadores. ...........................................................................................10 Tabela 2 : Caractersticas dos SGBDH. ................................................................................................23 Tabela 3 : Exemplos de predicados da linguagem XPath. ......................................................................41 Tabela 4 : Comparativo entre as seis principais linguagens para esquema. .............................................51 Tabela 5 : Comparativo entre linguagens de consulta para XML............................................................59 Tabela 6 : Exemplo de relao r1. .........................................................................................................66 Tabela 7 : Exemplo de relao r2. .........................................................................................................66 Tabela 8 : Comparativo entre abordagens de vises sobre dados semi-estruturados ................................78 Tabela 9 : Exemplo de tabela de pacientes base01. ................................................................................82 Tabela 10 : Exemplo de tabela de internao base01..............................................................................82
xii
LISTAGENS DE CDIGO FONTE

Listagem 1 : Exemplo de documento XML contendo dados de uma pessoa............................................31 Listagem 2 : Exemplo de documento HTML contendo dados de uma pessoa. ........................................34 Listagem 3 : Exemplo de documento XML representando uma coleo de pessoas. ...............................36 Listagem 4 : Documento XML sem abreviao de tags. ........................................................................36 Listagem 5 : Documento XML com abreviao de tags.........................................................................36 Listagem 6 : Exemplo de utilizao de atributos em elementos de um documento XML.........................37 Listagem 7 : Ambigidade na representao Elementos X Atributos - 1.................................................37 Listagem 8 : Ambigidade na representao Elementos X Atributos - 2.................................................37 Listagem 9 : Ambigidade na representao Elementos X Atributos - 3.................................................37 Listagem 10 : Utilizando comentrios em um documento XML.............................................................38 Listagem 11 : Instruo de processamento em um documento XML. .....................................................38 Listagem 12 : Declarao do tipo de codificao atravs de uma instruo de processamento.................38 Listagem 13 : Utilizando uma seo CDATA em um documento XML. ................................................39 Listagem 14 : Documento XML contendo informaes bibliogrficas. ..................................................39 Listagem 15 : Documento XML para definio de sua estrutura atravs de esquemas.............................43 Listagem 16 : DTD para documento da Listagem 15. ............................................................................44 Listagem 17 : XML Schema para documento da Listagem 15................................................................45 Listagem 18 : Derivao de tipos com a XML Schema..........................................................................46 Listagem 19 : Derivao de um complexType em XML Schema. ..........................................................46 Listagem 20 : Definio de grupos com XML Schema. .........................................................................47 Listagem 21 : Utilizao de namespaces em XML ................................................................................48 Listagem 22 : DTD para exemplo de consultas XML-QL. .....................................................................53 Listagem 23 : Exemplo de consulta bsica XML-QL.............................................................................53 Listagem 24 : Exemplo de consulta bsica XML-QL com abreviao de tags. .......................................54 Listagem 25 : Consulta XML-QL formatando os resultados em XML....................................................54 Listagem 26 : Documento XML contendo dados bibliogrficos. ............................................................55 Listagem 27 : Formatando o resultado de uma consulta XML-QL em XML...........................................55 Listagem 28 : Agrupando dados atravs de consultas aninhadas.............................................................56 Listagem 29 : Resultado de uma consulta agrupando o resultado. ..........................................................56 Listagem 30 : Junes de elementos pelo valor em uma consulta XML-QL. ..........................................56 Listagem 31 : Consulta XSL para dados XML. .....................................................................................57 Listagem 32 : Documento para ser processado atravs de SAX..............................................................60 Listagem 33 : Representao de uma tabela em HTML. ........................................................................61 Listagem 34 : Representao das relaes r1 e r2 atravs de tuplas. .......................................................65 Listagem 35 : Representao da rvore de dados da Figura 16 com XML. .............................................67 Listagem 36 : Exemplo de objeto MIX..................................................................................................76 Listagem 37 : Instrues de consulta RXL. ...........................................................................................77 Listagem 38: Viso XML gerada por wrapper a partir de uma base relaciona base01.............................83 Listagem 39 : Exemplo de um arquivo de regras de integridade para um documento XML.....................86 Listagem 40 : Exemplo de regra de chave estrangeira para um documento XML....................................87 Listagem 41 : Exemplo de repositrio de dados de localizao. .............................................................88 Listagem 42 : Algoritmo bsico representando o funcionamento do gerenciador de consultas. ...............90
xiii
Lista de Siglas
API APIX BNF CORBA DCD DOM DTD HTML JDBC LORE LOREL OMG OQL QBE SAX SBDD SGBD SGBDD SGBDH SGML SMBD SOX SQL URI URL W3C XDR XML XML-GL XML-QL XSL XSLT Application Programming Interface Aggregate Path IndeX Backus-Naur Form
Common Object Request Broker

Document Content Description Document Object Model Document Type Definition Hypertext Markup Language Java Database Connectivity
Lightweight Object Repository

LORE Language Object Managment Group Object Query Language Query By Example Simple Application for XML Sistema de Banco de Dados Distribudo Sistema Gerenciador de Banco de Dados Sistema Gerenciador de Banco de Dados Distribudo Sistema Gerenciador de Banco de Dados Heterogneo
Standard Generalized Markup Language

Sistema de Mltiplos Bancos de Dados Schema for Object-Oriented XML Structured Query Language Uniform Resource Indicator Uniform Resource Locator World Wide Web Consortium XML Data Reduced Extensible Markup Language XML Graphic Language XML Query Language XML Stylesheet Language XML Stylesheet Transformation
1.Introduo
O crescimento da Internet, em especial da World Wide Web trouxe grandes benefcios as organizaes que a utilizam como meio de acesso as informaes. Os diversos e variados sistemas de informaes existentes esto gradualmente sendo integrados com servidores Web para transformarem consultas realizadas por usurios em resultados a serem exibidos em browsers de Internet. No entanto, tanto as pessoas, como as organizaes que geram informaes para a rede utilizam diferentes maneiras de estrutur-las. Assim, quando necessrio alguma transferncia de informaes entre elas, a falta de uma estrutura padronizada pode causar problemas de incompatibilidade entre o sistema transmissor e o sistema receptor. Um Sistema Gerenciador de Banco de Dados (SGBD) capaz de resolver os problemas de gerenciamento e acesso a grandes volumes de dados em uma nica plataforma, mas muitos problemas surgem quando duas ou plataformas precisam trabalhar de maneira integrada. A maioria destes problemas so conseqncias da heterogeneidade semntica - dados duplicados entre estas plataformas representados de maneira diferente nos esquemas das bases de dados [Hull, 1997]. Um dos principais requisitos para a integrao de sistemas de informaes a existncia de um mecanismo que possa mediar e compatibilizar a troca de informaes entre sistemas que utilizam diferentes formas de representaes. As novas tecnologias associadas a linguagem Extensible Markup Language (XML) possibilitam o desenvolvimento de estruturas de mediao que atendem a este requisito. Integrar diversas fontes heterogneas de dados um desafio que a anos vem fomentando pesquisas e surgimento de novos padres a fim de tornar transparente o acesso a estas fontes para os usurios e desenvolvedores de aplicaes. A idia central deste trabalho consiste na especificao e implementao de um sistema capaz de integrar dados de diversas fontes relacionais (bancos de dados heterogneos distribudos) atravs da utilizao de vises materializadas dos dados, vises estas que utilizaro o padro XML para organizar e armazenar os dados, e para as quais ser tambm proposto um meio para definio de integridade referencial para os
dados nelas presentes, a fim de possibilitar que estes dados quando alterados na viso materializada possam ser sincronizados com as bases de origem sem causar violaes de integridade. O sistema proposto no se preocupa com as questes e problemas referentes ao processo de atualizao dos dados nas bases distribudas, apenas prope a manuteno da integridade referencial dos dados exportados para evitar problemas se os mesmos forem sincronizados para as bases de origem, as demais questes referentes ao processo de sincronizao de vises materializadas e bases distribudas esto fora do escopo deste trabalho.
1.1. Motivao
Diante do contexto atual no qual as pesquisas envolvendo bancos de dados e XML esto se desenvolvendo clara a necessidade de trabalhos voltados para a questo da integrao de dados armazenados em bases relacionais e dados armazenados na Web, pois segundo [Abiteboul et al., 2000], atravs da convergncia das solues apontadas pelas tecnologias XML/dados semi-estruturados e documentos Web/banco de dados, que se acredita que uma tecnologia combinada para a Web ir emergir. J existem muitas pesquisas sendo desenvolvidas no intuito de solucionar os problemas da heterogeneidade1 dos sistemas de armazenamento de dados e este trabalho ter tambm como foco a anlise de solues j propostas confrontando-as com a realidade atual. A motivao para este trabalho a crescente necessidade de um modelo baseado em uma camada de mediao capaz recuperar informaes de bases relacionais heterogneas2 mantendo as regras de integridade na camada de mediao a fim de que os dados que estiverem materializados nesta camada possam ser sincronizados de volta a suas respectivas bases em situaes que envolvam alteraes de dados. A troca de informaes dentro do modelo ser realizada atravs de XML, e o modelo proposto conforme a Figura 22 composto de vrios mdulos que sero detalhados na seo 4.4.
1.2. Objetivos
1 2
Seja ela de hardware, sofware ou conceitual. SGBDs de diferentes fabricantes e/ou com heterogeneidade semntica em suas definies de dados.
O trabalho proposto ter os seguintes objetivos: Especificar um sistema de consulta de informaes armazenadas em
bases relacionais distribudas heterogneas atravs da criao de vises XML; Especificar um mecanismo capaz de manter/preservar a integridade dos dados exportados em casos de atualizaes dos mesmos a fim de que estas atualizaes possam ser propagadas para as bases relacionais. Pesquisar como as tecnologias XML e Java podem auxiliar na integrao de fontes heterogneas de dados; Implementar um prottipo do modelo proposto.
1.3. Metodologia
Para a realizao deste trabalho, foram pesquisadas diversas bibliografias, tais como: livros, dissertaes, teses, artigos, relatrios tcnicos, documentos oficiais de congressos, Workshops e sites da Internet. Para implementao de um prottipo do sistema tambm foi necessrio um breve estudo sobre ferramentas de programao, APIs para manipulao de dados em documentos XML j existentes desenvolvidas por outros pesquisadores e/ou empresas atuantes no ramo.
1.4. Trabalhos Correlacionados

Existem diversos estudos e propostas na rea de bancos de dados e dados semiestruturados que esto correlacionados com este trabalho, dentre elas merecem um destaque as propostas de sistemas para integrao de dados abordadas nos sistemas MIX, SilkRoute, Argos, Heros, Jupter, Pegasus entre outros. [Manica, 2000] e [Silva, 2001]. Muitos estudos de tendncias futuras tambm merecem destaque tais como o apresentado por [Hull, 1997],
1.5. Organizao do Texto
O texto deste trabalho est organizado conforme o indicado a seguir. O captulo 2 faz uma reviso do principais aspectos relacionados a bancos de dados distribudos, tais como definio, arquitetura, terminologia, problemtica, possibilidades para a distribuio dos dados. descrita tambm, a definio de sistemas distribudos heterogneos, mostrando suas arquiteturas e terminologia bem como as principais formas de integrao de bancos de dados individuais j existentes e autnomos, atravs de modelos que especificam ou no um esquema conceitual global. Detalha tambm, o processo de integrao e traduo de esquemas, destacando vantagens e desvantagens dos diferentes modelos apresentados. O captulo 3 apresenta o padro XML, suas caractersticas principais, e os outros subpadres a ele correlacionados, tais como as diversas linguagens para definio de esquemas (gramtica) para documentos XML com comparativos entre as mesmas, estrutura lgica dos documentos e as principais linguagens para consulta a dados XML existentes com um comparativo entre as suas funcionalidades. E por ltimo tambm aborda questes referentes a restries de integridade em documentos XML. O captulo 4 trata basicamente da integrao de fontes de dados heterogneas atravs da utilizao do padro XML, demonstrando como se pode representar dados de bases relacionais atravs de XML, a utilizao de vises XML em arquiteturas de integrao, caractersticas, vantagens e problemas que podem surgir mediante o emprego das mesmas para integrar fontes de dados, e por ltimo so demonstrados algumas abordagens j existentes para integrao de fontes de dados heterogneas. O captulo 5 mostra a proposta de um novo modelo para integrar fontes de dados relacionais e heterogneas utilizando o padro XML, levando em conta a problemtica da manuteno das regras de integridade da viso integrada dos dados de maneira a garantir que os dados possam ser sincronizados com as bases distribudas sem enfrentar problemas com violaes de integridade. O captulo 6 apresenta uma anlise e interpretao dos resultado obtidos com este estudo e com a proposta de um modelo para integrao de dados, vantagens, desvantagens, problemas e dificuldades encontradas. E por fim, no captulo 7 esto a concluso final sobre o trabalho e propostas de continuidade para o mesmo.
2.Bancos de Dados Distribudos e Heterogneos

Neste captulo sero abordados os conceitos relacionados a Bancos de Dados Distribudos Heterogneos, suas caractersticas, vantagens, desvantagens, bem com sero apresentados alguns modelos existentes que propiciam a integrao de bases heterogneas. Tambm sero abordadas algumas tcnicas e ferramentas utilizadas para integr-los.
2.1. Conceitos bsicos

Um sistema gerenciador de banco de dados distribudo (SGBDD) um software que gerencia um banco de dados distribudo de tal modo que os aspectos da distribuio ficam transparentes para o usurio. O usurio de um sistema de banco de dados distribudo incapaz de saber a origem das informaes, tendo a impresso de estar acessando um nico banco de dados. Um sistema de banco de dados distribudo(SBDD) como uma coleo de dados inter-relacionados que se encontram fisicamente distribudos pelos ns de uma rede de computadores. A Figura 1 mostra como ocorre a distribuio dos dados atravs de uma rede de computadores.
Site 1 Site 2
Rede de Comunicao
Site 3
Site n
Figura 1 : Arquitetura de um banco de dados distribudo.
Cada n de um banco de dados distribudo capaz de processar transaes locais, as quais acessam apenas dados daquele nico n, ou pode participar na execuo de
transaes globais, que fazem acesso a dados em diversos ns [Manica, 2001]. A execuo de transaes globais requer comunicaes entre os ns o que implica na existncia de uma infra-estrutura de rede para prover tal comunicao. Se o projeto de um sistema distribudo executado top-down, isto , sem um sistema j existente, conveniente desenvolver um sistema homogneo. Todavia, em alguns casos onde a criao do banco de dados distribudo for feita pela integrao de vrios bancos de dados j existentes (chamamos bottom-up), ser necessrio um SGBDD heterogneo, capaz de fornecer interoperabilidade entre os bancos de dados locais. Existem diversas razes para construir um banco de dados distribudo, como o partilhamento de dados, confiabilidade, disponibilidade e acelerao de processamento de consultas. Entretanto, juntamente com essas vantagens h diversas desvantagens, como o custo de desenvolvimento de software, maior potencial para existncia de erros e crescente sobrecarga de processamento. A principal vantagem de sistemas de bancos de dados distribudos a capacidade de dividir e fazer acesso a dados de uma maneira confivel e eficiente. Pois, se uma srie de ns diferentes esto conectados, ento um usurio em um n pode ser capaz de fazer acesso a dados disponveis em um outro n. Cada n capaz de reter um grau de controle sobre dados armazenados localmente. Em caso de uma falha em um dos ns do sistema distribudo, os ns remanescentes podem ser capazes de continuar operando, aumentando a confiabilidade e disponibilidade. Alm disso, quando uma consulta envolve dados em diversos ns, possvel dividi-la em subconsultas que podem ser executadas em paralelo, acelerando seu processamento.
2.2. Requisitos funcionais de um SGBDD

Em 1987, C. J. Date, um dos primeiros projetistas de bancos de dados relacionais (junto com o Dr. E. F. Codd, autor da teoria relacional), props 12 regras que um SGBDD completo deveria seguir. Essas regras no representam requisitos absolutos, foram propostas somente para esclarecer as discusses sobre sistemas de bancos de dados distribudos. No entanto, elas se tornaram largamente aceitas como um conjunto
de definies de trabalho e como critrios de um banco de dados distribudo. As 12 regras de Date so: 1. Autonomia local : cada n participante de um sistema distribudo deve ser independente dos outros ns; 2. No dependncia de um n central: um sistema de banco de dados distribudo no deve depender de um n central; 3. Operao contnua: um sistema de banco de dados distribudo nunca deve precisar ser desativado; 4. Transparncia e independncia de localidade: os usurios do sistema no devem saber o local (n) onde esto localizados os dados; 5. Independncia de fragmentao: as tabelas que fazem parte de um sistema de banco de dados distribudo podem estar divididas em fragmentos localizados fisicamente em diferentes ns; 6. Independncia de replicao: dados podem estar replicados em vrios ns da rede, de forma transparente; 7. Processamento de consultas distribudo: o desempenho de uma consulta deve ser independente do local onde a mesma executada; 8. Gerenciamento de transaes distribudas: um SGBDD deve suportar transaes atmicas. As propriedades ACID (Atomicidade, Consistncia, Independncia e Durabilidade) das transaes devem ser suportadas; 9. Independncia de hardware: um SGBDD deve poder operar e acessar dados em uma variedade de plataformas de hardware; 10. Independncia de sistema operacional: um SGBDD deve poder executar em sistemas operacionais diferentes; 11. Independncia de rede: um SGBDD deve ser projetado para executar independente do protocolo de comunicao; 12. Independncia de SGBD: um SGBDD ideal deve possuir capacidades para se comunicar com outros sistemas de banco de dados executando em ns
10
diferentes, mesmo se estes sistemas de bancos de dados so diferentes (heterogneos).
2.3. Fatores negativos na utilizao de SGBDD

A complexidade em sistemas distribudos aumenta devido a vrios fatores. Um deles, refere-se distribuio dos dados. No essencial que cada site da rede possua o banco de dados completo e sim que um banco de dados resida em mais de um site. Portanto, necessrio definir como ser a distribuio e replicao (ou no) dos dados. A maior desvantagem do sistema de banco de dados distribudo a complexidade adicional requerida para assegurar a prpria coordenao entre os ns. Devido a esta complexidade so requeridos hardware e software adicionais, o que leva a um aumento de custos de desenvolvimento, potencialidade de defeitos e da sobrecarga de processamento. A Tabela 1 resume os principais fatores complicadores na utilizao de um SGBDD. Processamento de consultas Controle de concorrncia Confiabilidade Projeto como distribuir o banco de dados distribuio dos dados replicados converso de transaes de usurios em instrues de dados problema de otimizao sincronizao de acessos concorrentes consistncia e isolamento de efeitos de transaes gerenciamento de deadlocks como manter o sistema imune falhas atomicidade e durabilidade
Tabela 1 : SGBDD: fatores complicadores.
2.4. Arquiteturas para SGBDD

Uma arquitetura define a estrutura de um sistema: identificao, definio da funo, e o inter-relacionamento e interaes entre os componentes do sistema. A arquitetura data-lgica formada pelo esquema interno local de cada site, o esquema conceitual local de cada site, o esquema conceitual global e esquemas externos [Manica, 2001]. A Figura 2 representa a arquitetura data-lgica de SGBD Distribudo.
11
EE1
EE2
...
EEn
ECG
E C L1
E C L2
...
E C Ln
E IL1
E IL2
... ...
E ILn
Figura 2 : Arquitetura data-lgica de SGBD distribudo.
O esquema interno local (EIL) refere-se aos aspectos relacionados ao armazenamento fsico dos dados do site. O esquema conceitual local (ECL) refere-se estrutura lgica (informaes) do banco de dados. O esquema conceitual global (ECG) formado pela unio dos esquemas conceituais locais, permitindo uma viso global dos dados. Finalmente o nvel mais externo, os esquemas externos (EE) so as vises definidas aos usurios globais. Esta arquitetura denominada ponto-a-ponto (peer-to-peer) devido ao fato de que cada site possui o SGBD completo, diferente da arquitetura cliente servidor que concentra o gerenciamento dos dados em servidores, enquanto nos clientes ficam as interfaces e aplicaes. Quando o projeto do banco de dados distribudo realizado a partir de base de dados j existentes o chamamos de bottom-up. Deste modo, surge uma nova arquitetura data-lgica de multi-SGBD. A Figura 3 mostra a Arquitetura data-lgica de multi-SGBD. A maior diferena entre esta arquitetura e a data-lgica forma do mapeamento entre esquemas.
12
EE1 EE2
...
EEn
ECG
EEL1 ECL1 EEL2 EIL1 EIL1 ECL2
EEL1
...
ECL3 EEL2
... ...
EIL1
Figura 3 : Arquitetura data-lgica de multi-SGBD
2.5. Sistemas Homogneos e Sistemas Heterogneos

Sistemas de bancos de dados homogneos so aqueles que possuem o mesmo software gerenciador de banco de dados em todos os sites integrantes deste sistema na rede. Diversas aplicaes de banco de dados tm sido desenvolvidas requerendo dados de uma variedade de sistemas de bancos de dados preexistentes, localizados em vrios ambientes heterogneos de hardware e software. A manipulao de informaes localizadas em bancos de dados heterogneos requer uma camada adicional de software no topo dos sistemas de bancos de dados existentes. Essa camada de software chamada de Sistema Gerenciador de Bancos de Dados Heterogneos (SGBDH). Considera-se um SGBDD heterogneo [zsu e Valduriez, 1999] aquele que usa pelo menos dois tipos de SGBDs diferentes. Portanto, um SGBDH fornece transparncia no s da distribuio dos dados, mas tambm dos diferentes sistemas que o usurio acessa. Um SGBDH fornece uma viso integrada que esconde diferenas de estruturas e distribuio do vrios bancos de dados. Esta viso integrada apresentada como uma viso global do banco de dados (esquema conceitual global) e expressa em algum modelo de dados comum aos SGBDs locais, como o orientado a objetos, entidaderelacionamento ou o modelo relacional.
13
O SGBDH responsvel pelo mapeamento de dados e operaes entre o banco de dados virtual (esquema conceitual global) e o banco de dados local (esquema conceitual local), por resolver diferenas entre modelos, esquemas e sistemas, e por gerenciar as transaes distribudas e o controle de concorrncia [zsu e Valduriez, 1999].
2.6. Banco de Dados Distribudo Heterogneo

Em sistemas distribudos heterogneos, as nomenclaturas mais comumente utilizadas so: sistemas multidatabase, sistemas federados e sistemas legados. O termo sistema gerenciador de banco de dados distribudo heterogneo uma generalizao destas arquiteturas.
2.6.1. Sistemas Multidatabase

Um sistema com mltiplos bancos de dados: multidatabase (SMBD) um tipo especial de sistema de banco de dados distribudo. formado por uma coleo coerente e integrada de dados que logicamente aparenta ser um nico banco de dados mas implementado fisicamente em vrios bancos de dados. Cada banco de dados participante de um SMBD autnomo. Os usurios locais dos bancos de dados participantes continuam usando as suas aplicaes locais no banco de dados sem nenhuma alterao pela sua participao no SMBD. Os bancos de dados que participam no SMBD so geralmente heterogneos e os usurios no precisam saber como ou de onde os dados so acessados. Em um SMBD existem usurios locais e globais. A Figura 4 detalha a arquitetura de um SMBD.
UG1 UG2 UG3 ULn1 Site 1 Rede de Comunicao Site n ULn2 ULn3 BD1 UG = Usurio Global UL = Usurio Local BD = Banco de Dados BDn
UL11 UL12 UL13
14 Figura 4 : Sistema Multidatabase (com usurios locais e globais)
2.6.2. Sistema Federado e No Federado

Consideram-se os sistemas de bancos de dados federados [Sheth e Larson, 1990] como um subcaso de sistemas multidatabase, sendo que os sistemas federados podem ser classificados em : sistemas fracamente acoplados : so aqueles que no possuem um esquema global dos dados; sistemas com acoplamento forte : so compostos por conjuntos de SGBDs componentes, heterogneos, cooperativos mas autnomos, integrados de tal forma na federao que consultas e atualizaes podem ser realizadas de forma transparente localizao dos dados e aos caminhos de acesso. Isto viabilizado pela presena de um esquema global. Os sistemas no federados so multidatabase que no possuem usurios locais. O esquema conceitual global definido atravs da unio de todos os esquemas locais. Desta forma, todos os dados dos bancos de dados locais so compartilhados. Em um sistema multidatabase federado, os bancos de dados locais so semi-autnomos, pois operam independentemente e participam da federao compartilhando parte de seus dados. O modelo de banco de dados federado mais flexvel pois suporta a autonomia dos bancos de dados participantes da federao. Para organizaes descentralizadas, este modelo ideal porque cada componente do banco de dados controla o acesso a seus dados.
2.6.3. Sistemas Legados

Sistemas legados [Silva, 1994] (Legacy Systems) so aqueles sistemas que esto em uso por muito tempo, que atendem aos requisitos dos usurios e so de difcil substituio ou porque a reimplementao de seu cdigo invivel financeiramente ou porque eles so imprescindveis, j que esses sistemas no podem ficar sem execuo por muito tempo.
15
Na maioria das vezes, os sistemas legados foram desenvolvidos em linguagens procedurais, no implementam abstrao de dados e no possuem documentao, exceto o cdigo fonte. Tudo isso dificulta a adio de novas funcionalidades e a realizao de manuteno no sistema. Em [Brodie e Stonebraker, 1995] define-se Sistemas Legados como aqueles sistemas que contm dados valiosos, mas que carecem de poder ou agilidade para satisfazer as necessidades atuais da organizao. A necessidade de sobrevivncia dos sistemas legados, em sua grande maioria, faz com que vrias alternativas tenham sido propostas para resolver, ou pelo menos minimizar esse problema.
2.7. Tcnicas e Ferramentas de Integrao

Normalmente, os dados que empresas e instituies pblicas de mdio e grande porte desejam compartilhar so dados que esto em bancos de dados heterogneos j existentes, o que torna a interoperabilidade ainda mais complexa. Nestes casos, os bancos de dados individuais j existentes so autnomos e necessrio projetar uma forma ideal para integrar tais sistemas. Este projeto de integrao executado a partir de base de dados existentes chamado de bottom-up, e diferentes autores apresentam vrias alternativas. A integrao de bancos de dados [zsu e Valduriez, 1999] o processo no qual informaes dos bancos de dados participantes so integrados para formar um nico e coeso multidatabase. Em outras palavras, o processo de projetar um esquema conceitual global a partir dos esquemas locais de cada banco de dados participante do multidatabase. A dificuldade na definio do modelo de dados utilizado pelo SGBD heterogneo [Silva, 1994] conseqncia da necessidade de se escolher um modelo de dados com poder de expresso suficiente para capturar a semntica dos dados expressa pelos esquemas locais dos SGBDs. Existem propostas que no utilizam o esquema conceitual global para integrar mltiplas bases de dados. H discusses se o esquema conceitual global deve existir ou no em sistemas multidatabase. Portanto, existem dois modelos que podem ser
16
utilizados para integrar bancos de dados: arquiteturas que especificam um esquema conceitual global e arquiteturas que no especificam um esquema conceitual global.
2.7.1. Integrao atravs de modelos que especificam um esquema conceitual global

Uma alternativa para integrao de bancos de dados [zsu e Valduriez, 1999], [Bell e Grimson, 1992] atravs da especificao de um esquema conceitual global a partir dos esquemas conceituais locais. Bell e Grimson, classificam os sistemas federados que possuem um esquema global como fortemente acoplados. Portanto, um SBDD heterogneo fortemente acoplado composto por um conjunto de SGBDs componentes, integrados de forma que a localizao dos dados e os caminhos de acesso so transparentes aos usurios. A construo de um esquema global uma tarefa difcil e complexa. O esquema global pode ser formado pela unio de esquemas locais conforme a Figura 5. Deste modo, o esquema conceitual global um subconjunto da unio de todos os esquemas conceituais locais, pois formado apenas por parte dos esquemas conceituais locais. Em ambas alternativas as vises para usurios que requerem acesso global so definidas a partir do esquema conceitual global. A maior diferena entre o projeto do esquema conceitual global em sistemas distribudos e este tipo de sistema que, no primeiro, o mapeamento ocorre do esquema conceitual local para o esquema global. No segundo, o mapeamento ao contrrio, do esquema global para o conceitual. Assim, o projeto de um sistema multidatabase normalmente bottom-up, enquanto que nos sistemas distribudos top-down.
17
EEG1 EEG2 EEGn
EEG = esquema externo global ECG = esquema conceitual global EEL = esquema externo local ECL = esquema conceitual local BD = banco de dados
ECG
EEL11 ECL1 EEL12 EIL1

BD1
EELn1
...
ECLn EELn2
... ...
EILn
BDn
Figura 5 : Arquitetura com esquema conceitual global
2.7.2. O processo de integrao e traduo de esquemas

O processo de integrao ocorre em dois passos: traduo e integrao de esquemas. A traduo s necessria se os bancos de dados forem heterogneos (cada esquema local foi definido usando modelo de dados diferentes). Nesta primeira etapa, o esquema conceitual de cada banco de dados traduzido para um esquema intermedirio padro. O esquema intermedirio corresponde ao esquema local traduzido para um modelo de dados de uso comum no SGBDH. Na fase de integrao de esquemas, realizada em seguida ao processo de traduo, ocorre a integrao dos esquemas intermedirios gerando um esquema conceitual global. Integrao segundo [zsu e Valduriez, 1999], o processo de identificar os componentes de um banco de dados que esto relacionados com um outro, selecionar a melhor representao para o esquema conceitual global, e, finalmente, integrar os componentes de cada esquema intermedirio. A Figura 6 ilustra os processos de traduo e integrao.
18
Esquema Conceitual Global
Integrador
Esquema Intermedirio 1
Esquema Intermedirio 2
...
Esquema Intermedirio n
Tradutor 1
Tradutor 2
...
Tradutor n
BD1
BD2
...
BDn
Figura 6 : Integrao de Bancos de dados: traduo e integrao
A integrao de esquemas envolvem duas tarefas [Yan et. al., 1997]: homogeneizao e integrao. Na homogeneizao, so tratados os problemas de heterogeneidade semntica e estrutural. Problemas semnticos referem-se ao significado, interpretao e como os dados so usados. O problema mais importante de heterogeneidade semntica o de conflito de nomes: sinnimos (duas entidades com nomes diferentes, mas com o mesmo significado) e homnimos (duas entidades com o mesmo nome e com significados diferentes). Existem vrios mtodos alternativos para lidar com conflitos de nomes. Alguns dos problemas de heterogeneidade semntica e estrutural tratados na homogeneizao no so possveis de serem implementados. Isso faz com que seja essencial a interveno humana na soluo destes. Aps a homogeneizao dos esquemas feita a integrao. Os esquemas dos mltiplos bancos de dados (agora esquemas intermedirios) so combinados em um nico esquema conceitual global e reestruturados da melhor forma possvel.
19
Muitas vezes, a heterogeneidade entre os esquemas a serem integrados muito grande, tornando invivel o investimento no desenvolvimento do esquema global, principalmente quando o nmero de pesquisas globais so relativamente baixas. As principais desvantagens deste modelo so a difcil automao, necessidade de interveno humana para a soluo de conflitos semnticos e/ou estruturais, e a no adaptabilidade do sistema que faz com que toda vez que ocorram mudanas nos esquemas locais a integrao deva ser refeita.
2.7.3. Mediadores
Mediador um componente de software que explora conhecimento codificado sobre conjuntos ou subconjuntos de dados para criar informao til para uma camada de aplicaes [Wiederhold, 1992]. Uma aplicao que requer dados de fontes heterogneas necessita de uma camada intermediria de software que faa a mediao entre ela e as fontes de dados, esta camada de mediao ter tarefas como abstrao, combinao e explicao dos dados. Os mediadores tem como principal funcionalidade a disponibilizao de dados para aplicaes, agindo como uma interface inteligente para lidar com problemas de representao e abstrao presentes nas diferentes fontes de dados, eles apresentam regras ativas e contm estruturas de conhecimento que guiam as transformaes de dados, podendo inclusive manter resultados intermedirios que podem ser consultados. As principais funcionalidade de um mediador so: Transformaes e gerao de dados de bases de dados atravs da utilizao de vises e templates de objetos reorganizando os dados de maneira apropriada para serem acessados pelas aplicaes; Disponibilizao de informaes textuais como aplicao de padres para texto visando um melhor entendimento de suas informaes. Esta funcionalidade muito importante na organizao de fontes de dados semiestruturados, como os dados presentes na Web; Armazenamento de dados derivados afim de melhorar a eficincia reduzindo o acesso as fontes e mantendo conhecimento processado para uso posterior. Para
20
a implementar esta funcionalidade preciso manter o controle de integridade dos dados. A presena de mediadores pressupe a existncia de uma arquitetura bsica em trs camadas, conforme a Figura 7.
Aplicao Aplicao Aplicao
Camada Mediadora
SGBD
SGBD
SGBD
SGBD
Figura 7 : Arquitetura Bsica dos Mediadores.
A camada superior composta pelas aplicaes independentes, a camada intermediria formada por mltiplos mediadores, gerenciados por especialistas em domnios do conhecimento, sendo que o nmero de mediadores depende da heterogeneidade dos dados necessrios a aplicao, e a camada inferior composta de vrias fontes de dados gerenciadas por administradores de dados. A interface aplicao-mediador deve ser uma linguagem declarativa e extensvel que permita a incorporao de novas funes de modo a prover a flexibilidade e a interao com novos mediadores. A interface mediador-fonte deve ser uma linguagem de acesso a dados. Alguns aspectos devem ser levados em conta no projeto de uma arquitetura que envolva o uso de mediadores: A manuteno do mediador deve ser feita por um pequeno grupo de especialistas, responsveis pela manuteno das suas regras de transformao; Os dados mantidos por um mediador podem servir de entrada para outros mediadores ou serem consultados por usurios ou aplicaes finais;
21
Mediadores podem ser especializados para prover melhor extensibilidade, facilitar a manuteno e oferecer mais opes as aplicaes, assim, a
camada intermediria pode ser formada por uma hierarquia de especializaes de mediadores com relacionamentos de associao para troca de informaes; Eventos (Triggers)3 podem ser disparados dos sistemas gerenciadores das fontes de dados para os mediadores relacionados de modo a manter a integridade dos dados na ocorrncia de alteraes nos mesmos ou na sua estrutura; Linguagens de acesso a mediadores so objetos de pesquisas, devendo incluir capacidades funcionais da linguagem SQL, iterao, teste e ranqueamento.
2.7.4. Wrappers
Um wrapper ou tradutor, um componente de software que converte dados e consultas (query) de um modelo para outro [Papakonstantinou et al., 1995]. Neste caso, uma aplicao (que pode ser um mediador), solicita ao wrapper consultas em uma linguagem de consulta comum (SQL, OQL, XML-QL), e o mesmo converte esta consulta para uma linguagem de consulta suportada pelo banco de dados ao qual est ligado, depois recebe o resultado desta consulta e o converte para um formato suportado pela aplicao ou mediador. A Figura 8 detalha uma arquitetura baseada em mediadores com a utilizao wrappers.
Triggers so instrues de processamento armazenadas no prprio SGBD que so executadas automaticamente mediante condies especficas.
22
Aplicao Aplicao
...
Aplicao
Camada Mediadora
Wrapper
Wrapper
Wrapper
...
Wrapper
SGBD
SGBD
SGBD
...
SGBD
Figura 8 : Arquitetura Bsica dos Mediadores com auxlio dos wrappers.
Podemos definir como funo bsica de um wrapper o trabalho de exportar para cada fonte de dados, informaes sobre o esquema de dados e dados, alm de traduzir as consultas de uma linguagem para outra.
2.8. Exemplos de Sistemas Gerenciadores de Bancos de Dados Heterogneos

Existe um grande nmero de SGBDHs bem como novos projetos sendo desenvolvidos. Apesar das diferenas, todos eles possuem como principal objetivo desenvolver uma arquitetura e ferramentas que propiciem interoperabilidade entre sistemas de banco de dados heterogneos. A Tabela 2 apresenta os principais sistemas gerenciadores com suas caractersticas e nas subsees seguintes sero detalhadas as arquiteturas dos principais SGBDHs existentes. Sistema
Multidatabase
Tipo de Acoplamento
Forte Forte
Modelo de Dados
Orientado a objetos Orientado a objetos
Lingua-gem Caractersticas de Acesso Global

Daplex JIL O multidatabase tem como restrio o fato de no fazer um controle ideal da consistncia dos bancos de dados. Os SGBDs locais so encapsulados como clientes e servidores Orbix. Solicitaes remotas so tratadas por chamadas ao Jupter, que estabelece um objeto representante local para a solicitao remota. Utiliza para o controle de
Jupter
HEROS
Forte
Orientado a
OQL
23
objetos
(da OMG)
DDTS
Fraco
Orientado a objetos
GORDAS
Pegasus
Fraco
ris e Orientado a objetos Orientado a objetos
HOSQL (extenso da OSQL) VML
concorrncia global um mtodo baseado no Mtodo de Tquete Implcito estendido para possibilitar a garantia de serialibilidade das transaes globais. DDTS ainda possui vrios problemas a serem solucionados, como otimizao de consultas, controle da concorrncia, regras de integridade, etc. Trata conflitos e otimizao de consultas. Utiliza metaclasse, novas idias para gerenciamento de transaes para resolver conflitos.
Vodak
Fraco
Tabela 2 : Caractersticas dos SGBDH.
2.8.1. Multidatabase [Buretta, 1997]

Multidatabase um software desenvolvido pela Computer Corporation of America para recuperao de dados de bancos de dados heterogneos. Este sistema prov ao usurio uma viso uniforme do banco de dados e uma linguagem de manipulao de dados chamada Daplex. O Multidatabase fornece um alto nvel de interface para aplicaes somente para leitura mantendo transparncia da localizao e heterogeneidade dos SGBDs participantes. O principal objetivo deste sistema gerenciador prover uma interface para sistemas preexistentes sem modificar seus softwares. A arquitetura do multidatabase demonstrada na Figura 9 composta por dois principais componentes: gerenciador de dados global (GDG) : responsvel pelas consultas globais; interface de banco de dados local (IDL) : responsvel pela interface dos SGBDs nos vrios sites. O esquema global oferece um viso integrada do banco de dados distribudo e acessado pela linguagem Daplex. Cada site possui o componente de interface local que
24
um intermedirio entre o esquema local do site (acessado pela linguagem do BDs locais) e um esquema intermedirio local (acessado em Daplex). O gerenciamento de consultas executado da seguinte maneira. Quando uma consulta global executada, o GDG decompe a consulta em vrias subconsultas Daplex sobre os esquemas locais e o banco de dados auxiliar. O esquema auxiliar descreve dados necessrios para o mapeamento entre os esquemas. Tambm de responsabilidade do GDG montar os resultados parciais e retorn-los ao usurio. O IDL (interface de banco de dados local) responsvel por aspectos relacionados especificamente aos bancos de dados locais. Ele traduz as consultas escritas nas linguagens dos BDs locais para Daplex e vice-versa.
Consulta Resultado
Esquema Auxiliar (Daplex)
Interface de dados globais
Esquema Global (Daplex)
Interface de BD Local 1
BD Auxiliar
Esquema Local (Daplex)
...
Interface de BD Local n
Esquema Local (Daplex)
SGBD1
Esquema Local 1
...
SGBDn
Esquema Local n
Figura 9 : Arquitetura do SGBDD-H Multidatabase
O GDG composto por cinco mdulos : transformador, otimizador global, decompositor e monitor enquanto o IDL composto por trs: interface de rede, otimizador local, e tradutor. O transformador pega a consulta global em Daplex como entrada e produz como sada uma consulta global Daplex que referencia o esquema local. O otimizador global utiliza a sada do transformador para gerar um plano de consulta atravs do algoritmo de otimizao SDD-14.
SDD-1 (System for Distributed Databases), um prottipo de um sistema de banco de dados distribudo desenvolvido pela Computer Corporation of America. No SDD-1, parties de dados distribudos atravs
25
O decompositor decompe a consulta em subconsultas e o filtro elimina de cada subconsulta aquelas operaes que no so suportadas pelo SGBD correspondente. Estas operaes removidas sero executadas parte. O monitor controla a execuo da consulta. A interface de rede em cada site o mdulo responsvel por transmitir as consultas e seus resultados. O tradutor finalmente traduz a consulta para a linguagem do banco de dados local. O multidatabase tem como restrio o fato de no fazer um controle ideal da consistncia dos bancos de dados. Porm, vrias solues esto sendo propostas para lidar com inconsistncias. A mais utilizada agregar funes prprias para controle da inconsistncia de dados.
2.8.2. Projeto Jupter [Murphy e Grimson, 1995]

O projeto Jupter tem como objetivo bsico permitir que sistemas autnomos e, possivelmente, heterogneos cooperem e compartilhem informao de uma forma controlada. Sua arquitetura consiste em um conjunto de servios e uma linguagem para mltiplos bancos de dados, a JIL- Jupter Interoperator Language que permite que provedores de informao construam sistemas de informao fracamente acoplados, autnomos e interoperveis. A Figura 10 detalha os componentes da arquitetura do Jupter.
de uma rede so replicados em mltiplos sites. O controle de concorrncia do SDD-1 garante a consistncia das bases em um ambiente de distribuio.
26
System Services Transaction Services Application Services Query Services Metadata Services Object Manag. Services Data Movement Services Negotiation Services
ORBIX (CORBA Implementations)
Local System 1 Jupter Server Local DBMS (1-n)
Local System 2 Jupter Server Local DBMS (1-n)
Local System n Jupter Server Local DBMS (1-n)
Figura 10 : Arquitetura do Jupter.
A arquitetura de esquemas possui quatro nveis: esquema local, esquema de participao, esquema de exportao e esquema federado. Os componentes da arquitetura do Jupter so: system services, application services, dictionary (metadata), query services, transaction services, data movement services, object services e negotiation services.
2.8.3. HEROS - HetERogeneous Object System [Castro, 1998]

HEROS - HetERogeneous Object System um SGBDH orientado a objetos desenvolvido no departamento de informtica da PUC-Rio, sob o patrocnio do CNPq. Possui acoplamento forte, que prov aos usurios transparncia de localizao e replicao das informaes acessadas. O modelo de dados utilizado no HEROS para expressar o esquema global o modelo de objetos, escolhido devido a sua expressividade e minimalidade. Para representar a informao (sobre os SGBDs componentes) necessria para permitir o acesso e interoperao (meta-informao) utilizada a hierarquia de classes. Desta forma, representa-se no esquema do HEROS, no somente os esquemas dos sistemas a serem integrados, mas tambm as prprias caractersticas dos modelos de dados e SGBDs dos componentes, com as regras de mapeamento entre estes e o modelo global da federao. Deste modo, possvel a extensibilidade da federao, o que permite que qualquer novo sistema componente possa ser integrado federao, sem a necessidade de
27
alteraes na estrutura base do HEROS. Para integrar um novo componente, cujas caractersticas de modelo de dados ou sistema de gerncia ainda no existam na federao, basta defini-lo atravs da criao de classes que descrevam suas caractersticas, juntamente com suas respectivas regras de mapeamento, deixando, ento, que o prprio HEROS faa a traduo de esquemas automaticamente [Castro, 1998]. A arquitetura de esquemas do HEROS dividia em quatro nveis conforme demonstrado na Figura 11: esquema local (EL), esquema de exportao (EExp), esquema global (EG) e esquema externo (EE). O esquema local o prprio esquema do SGBD componente, expresso no seu prprio modelo de dados. Esquema de exportao o esquema local do SGBD componente expresso no modelo de dados do HEROS. Esquema global obtido pela integrao de todos os esquemas de exportao e esquema externo representa uma viso global do esquema integrado do HEROS.
EE1 EE2
...
EEn
EG
EExp1
EExp2
...
EExpn
EIL1
DB
EIL2
DB
... ...
EILn
DB
Figura 11 : Arquitetura de esquemas do HEROS
Conforme mencionado, o HEROS usa um modelo de dados orientado a objetos, o que permite que tudo seja modelado atravs da representao de objetos, desde a metainformao at as instncias dos bancos de dados. Os elementos do modelo de dados HEROS so representados na Figura 11.
28
O controle de concorrncia em um SGBDH deve ser efetivado tanto no nvel global quanto no nvel local. Para o controle de concorrncia local no HEROS, tendo em vista que a autonomia dos SGBDs componentes impede a interferncia do gerente global no controle de transaes, foram restringidos os tipos de SGBDs que podem participar, atravs de requisitos que devem ser atendidos pelos protocolos empregados no controle da concorrncia. Cada SGBD componente deve efetuar o controle da concorrncia com o uso do protocolo 2PL5 estrito [Bernstein et al., 1987]. Para o controle de concorrncia global, o HEROS apresenta um mtodo baseado no Mtodo de Tquete Implcito ITM [Georgakopoulos et al.,1994], estendido para possibilitar a garantia de serialibilidade das transaes globais mesmo no caso de ocorrncia de falhas acrescentando ao mecanismo original um mecanismo para controle de acessos baseado tambm no protocolo 2PL.
2.8.4. DDTS - Distributed Database Testbed System [Buretta, 1997]

DDTS foi desenvolvido por Honeywell Corporate Computer Science Center. O projeto enfatiza a modularizao e flexibilidade e composto por subsistemas que provem servios de interface com o usurio, traduo de consultas e execuo distribuda. Como no Multidatabase (abordado na 2.8.1), ele capaz de integrar SGBDs e prover algumas facilidades adicionais. A arquitetura do DDTS consiste em um conjunto de processadores de aplicao (application processors: AP) e processadores de dados (data processors DP). Os Aps controlam a interface com os usurios e gerenciam aplicaes enquanto os DPs gerenciam dados. Ambos so alocados a processadores fsicos nos sites durante a configurao do sistema. Um subsistema de comunicao transfere mensagens entre Aps e DPs. Sua arquitetura em cinco nveis utiliza um esquema global que uma descrio relacional de toda a estrutura dos bancos de dados. A linguagem de manipulao de dados utilizada GORDAS.
2PL (Two-Phase Locking) Algoritmo de controle de bloqueios em SGBDs baseado em duas fases.
29
Seus componentes conforme a Figura 12 so divididos entre Aps e DPs. Processadores de aplicao (Ap) incluem quatro mdulos: interface, tradutor e controlador de integridade, planejador de acesso e monitor de execuo distribuda. Processadores de dados (DP) incluem dois mdulos: o monitor de execuo local e o mdulo de operao local. A interface prov a interao do usurio com DDTS. Este componente fornece funes para armazenamento, edio e execuo de aplicaes. O tradutor traduz uma consulta na linguagem GORDAS para lgebra relacional. Informaes para mapeamento so armazenadas no esquemas de representao, conforme ilustra a Figura 12.
U surio Produo da C onsulta GOR DAS interface
Esque m a Conce itua l
Tradutor e controlador de Integridade
Planejador de acesso
Esquem a de Re pre se nta o
lgebra relacional + estratgia de execuo distribuda Monitor de execuo distribuda
Esquem a de Re pre se nta o
DP DP
Mdulo de execuo local
Esque ma Local
M dulo de operao local
Esque ma Local
S GBD Local
Figura 12 : Componentes de Software do DDTS
O planejador de acesso prope uma estratgia para um processamento eficiente das aplicaes distribudas. O algoritmo de otimizao implementado no DDTS determina o custo mnimo de transmisso selecionando cpias que esto mais prximas do site de origem da aplicao. Deste modo a estratgia de custo mnimo determinada. O monitor de execuo distribuda (DEM) e o monitor de execuo local (LEM) cooperam na execuo de transaes. O DEM cria um conjunto de processos LEM. Cada processo DEM retido at que a transao confirmada (commit) ou abortada
30
(abort). Os algoritmos utilizados so os 2PC (2-phase-commitment) e 2PL (2phase-locking). Finalmente, o mdulo de operao local traduz e otimiza as subtransaes.
2.9. Comentrios finais

Na atualidade difcil conceber uma aplicao que ir manipular informaes sobre pessoas e organizaes sem a presena de um sistema capaz de gerenciar de maneira eficiente, gil e segura os dados necessrios para esta aplicao. Tambm muito comum que muitas organizaes, dependendo da natureza da mesma, tenham necessidade de manter os seus dados em vrias bases distribudas por muitas razes, dentre elas podem ser citadas questes geogrficas, necessidade de partilhamento, diviso de carga de processamento, maior disponibilidade, entre muitos outros motivos. Assim, a presena de um sistema capaz de gerenciar dados distribudos fundamental. Mas em muitos casos, a necessidade de integrao surge depois que os diversos sites a serem integrados j possuem uma estrutura local, com seu prprio banco de dados, o que traz a tona uma srie de questes a serem resolvidas ao se tentar integrar estes dados legados. Estas situaes so muito comuns principalmente com a necessidade de agilidade criada pela popularizao da Internet. Em meio a tudo isto, torna-se necessrio a especificao de um modelo capaz de mediar as trocas de informaes entre bases heterogneas, como o caso do HEROS e do Jupter abordados neste captulo que possibilitam a integrao de bases relacionais heterogneas atravs de uma estrutura baseada em mediadores.
31
3.A Linguagem XML

Este captulo aborda o padro XML, sua origem, suas caractersticas, funcionalidades, subpadres e especificaes. Tambm sero mostradas e comparadas as principais linguagens para definio de esquemas para dados XML, as principais linguagens de consulta para dados XML, e a questo da integridade de dados armazenados no formato XML.
3.1. Conceitos bsicos

A necessidade de troca de informaes entre computadores e sistemas computacionais viabilizada pela existncia de padres para intercmbio de dados. O padro XML um formato ideal para armazenagem, intercmbio e posterior publicao de dados estruturados e semi-estruturados atravs das mais variadas mdias [Bradley, 98]. A sigla XML representa eXtensible Markup Language (onde o X substitui o E por questes de esttica), suas especificaes so mantidas pela W3C6 e foi desenvolvida baseada em experincias com outras linguagens de marcao. Um documento XML contem instrues especiais chamadas de tags, as quais, identificam o contedo do documento. Conforme vemos no exemplo da Listagem 1, os dados compreendidos entre as tags <pessoa> e </pessoa> contm dados referentes a pessoas.
<pessoa> <nome> Paulo da Silva </nome> <idade> 46 </idade> <e-mail> paulo@familiasilva.com.br </e-mail> </pessoa> Listagem 1 : Exemplo de documento XML contendo dados de uma pessoa.
Em 1996, especialistas em SGML7, a principal linguagem de marcao da qual surgiu a HTML, sob a chefia de Jon Bosak, da Sun Microsystems, se uniram para definio de um novo padro de marcao que pudesse ser utilizado na Internet,
O W3C que um grupo que especifica padres para as tecnologias relacionadas a Web (World Wide Web Consortium - http://www.w3.org).
7 6
A sigla SGML um padro ISO (ISO 8879). Esse padro especifica as regras para a criao de linguagens de marcao indepente da plataforma.
32
constituindo-se em uma verso simplificada da SGML, cujo objetivo principal era fornecer aos desenvolvedores da Web maneiras de definir e criar seus prprios marcadores e atributos quando necessrio, em vez de estarem restritos ao esquema de marcao da HTML. No final de 1996, o comit de trabalho anunciou a primeira verso da XML em uma conferncia da SGML, realizada em Boston, nos Estados Unidos. Novos recursos foram consolidados no primeiro semestre de 1997. A meta principal do comit foi desenvolver uma linguagem de marcao que tivesse a capacidade e a generalidade da SGML, e fosse fcil de ser implementada na Web. Resumidamente, as caractersticas desejadas inicialmente para a XML se referiam a trs partes: a definio da linguagem em si (XML-LANG); a definio da ligao entre os documentos (XML-LINK); a forma de apresentao dos documentos (XS8). As regras bsicas para a criao dessa linguagem de marcao, isto , as principais caractersticas desejveis para implementao na Web eram as seguintes: Criar uma linguagem simples, que possibilite a rpida construo de documentos para utilizao na Web; Fornecer suporte criao de aplicaes compatveis com a abordagem da HTML; Possibilitar o desenvolvimento de uma grande variedade de aplicativos, aproveitando-se de seus recursos; Fornecer um mecanismo de apresentao genrico e poderoso, permitindo ao desenvolvedor criar a forma de apresentao que mais se adapte s suas necessidades; Fornecer suporte para a criao de marcadores personalizados, definidos pelo desenvolvedor do documento Web;
A sigla XS aqui significa XML Stylesheet ou folhas de estilo.
33
Permitir a criao de documentos que pudessem ser validados, isto , que existisse uma forma de verificar a estrutura do documento, verificando se
seus elementos eram vlidos, da mesma forma que ocorria com a SGML; Fornecer suporte para criao de hiperlinks que fossem compatveis com a especificao de endereos URL, de modo a criar ligaes entre documentos; Fornecer um mecanismo de folha de estilo genrico e poderoso, que possibilitasse no apenas a formatao do documento, como tambm sua manipulao. Uma vez contempladas essas caractersticas, a XML passa a fornecer um meio completo para a elaborao e distribuio de documentos por toda a Web, sendo independente de plataformas e de sistemas. O objetivo era transformar o conceito da HTML, fornecendo a XML recursos adicionais para a criao e distribuio de documentos.
3.2. Importncia da XML

A XML no apenas mais uma linguagem de marcao como a HTML, pois ela possibilita a utilizao de vrios recursos importantes. A possibilidade de o desenvolvedor definir marcadores (tags) personalizados torna o documento mais inteligente, dando significado ao texto armazenado entre os marcadores. Esse o aspecto mais importante da XML. A XML independente de plataforma e no uma linguagem de programao. Ela no faz nada por conta prpria e tambm de domnio pblico, constituindo um padro aberto que nenhuma empresa pode monopoliz-la. Os documentos criados em XML pertencem a seu criador e sua funo principal criar condies para permitir uma padronizao na descrio de informaes. Uma vez padronizada a estrutura do documento, possvel, com a utilizao de linguagens de programao, interpretar e manipular o contedo do documento [Furgeri, 2001]. Um documento XML composto, basicamente, de trs elementos distintos: Contedo dos dados: so as informaes armazenadas entre as tags;
34
Estrutura: a organizao dos elementos dentro do documento, que pode possuir diversos tipos de formato, como um memorando, um contrato,
uma receita, um oramento, enfim, de acordo com as necessidades da marcao da informao; Apresentao: a forma como as informaes so apresentadas ao leitor do documento, isto , como apresentar o contedo de um documento XML, pois um mesmo documento pode ser visualizado de forma diferentes. A idia central da XML que muitos benefcios podem ser alcanados quando estes trs elementos podem ser mantidos e manipulados de forma separada.
3.3. XML e HTML

Enquanto a HTML indica como algo deve ser exibido, a XML indica o que a informao significa [Furgeri, 2001]. Enquanto a HTML descreve a apresentao dos dados, como tamanho do ttulo ou da fonte que ser usado para apresentar os dados em um navegador, a XML descreve o contedo destes dados. No exemplo da Listagem 2, vemos como poderiam ser representados em HTML os dados do exemplo da anterior (Listagem 1) contendo informaes sobre uma pessoa, nele esto presentes apenas tags que tratam da apresentao dos dados como por exemplo <h1> que indica que os dados que a compe representam o cabealho, ou a tag <p> que indica que o texto deve ser exibido em uma nova linha.
<html> <h1> Dados de uma Pessoa </h1> <p> Nome : Paulo da Silva <p> Idade : 46 <p> e-mail : paulo@familiasilva.com.br </html> Listagem 2 : Exemplo de documento HTML contendo dados de uma pessoa.
Segundo [Abiteboul et al., 2000], a XML difere da HTML em trs aspectos: Novas tags podem ser definidas; As estruturas podem ser aninhadas e agrupadas sem limite de profundidade; Um documento XML pode conter uma descrio opcional da sua gramtica.
35
Documentos XML so ditos como bem formados quando no possuem restries quanto a marcas, nomes de atributos ou outros padres, ou seja, quando um documento XML satisfaz uma gramtica baseada na qual ele foi especificado ele considerado vlido. A XML permite a definio de novas tags para representar a estrutura dos dados, porm, ao contrrio da HTML, no traz nenhuma descrio de como os dados devem ser apresentados. Estas informaes sobre a apresentao dos dados deve ser includas em separado a uma folha de estilos (Stylesheet). As folhas de estilos em uma especificao denominada XML Stylesheet Language (XSL) so usadas para converter os dados XML para HTML, podendo assim o seu resultado ser mostrado em um navegador padro [Abiteboul et al., 2000].
3.4. Componentes de um documento XML

Um documento XML composto por vrios tipos de informaes que so usadas para representar os dados presentes no documento e as informaes (metadados) referentes a estes dados.
3.4.1. Elementos
XML uma representao textual de dados. Um elemento formando por uma tag inicial, uma tag final e os dados compreendidos entre elas. No exemplo da Listagem 1, os dados compreendidos entre as tags <pessoa> e </pessoa> compe o elemento pessoa. O termo subelemento tambm utilizado para representar relaes entre um elemento e os elementos que o compe, assim, podemos dizer que o elemento e-mail (que composto pelos dados presentes entre as tags <e-mail> e </e-mail>) um subelemento do elemento pessoa. Na representao de dados XML usam-se elementos repetidos com as mesmas tags para representar colees. O documento XML da Listagem 3 contem um exemplo no qual vrias tags <pessoa> aparecem uma aps a outra representando assim, dados de uma coleo de pessoas.
<tabela> <descricao> Artistas Famosos </descricao> <pessoas> <pessoa>
36
<nome> Raul Seixas </nome> <idade> 46 </idade> <e-mail> raul@seixas.com.br </e-mail> </pessoa> <pessoa> <nome> Kurt Kobain </nome> <idade> 28 </idade> <e-mail> kurt@kobain.com </e-mail> </pessoa> </pessoas> </tabela> Listagem 3 : Exemplo de documento XML representando uma coleo de pessoas.
A XML permite utilizao de abreviao na representao de elementos vazios como por exemplo o elemento banda no exemplo da Listagem 4, pode ser representado apenas pela tag <banda/> conforme o descrito na Listagem 5.
<pessoa> <nome> Jimi Hendrix </nome> <idade> 42 </idade> <e-mail> jimi@hendrix.com </e-mail> <banda> </banda> </pessoa> Listagem 4 : Documento XML sem abreviao de tags. <pessoa> <nome> Jimi Hendrix </nome> <idade> 42 </idade> <e-mail> jimi@hendrix.com </e-mail> <banda/> </pessoa> Listagem 5 : Documento XML com abreviao de tags.
3.4.2. Atributos
A XML permite a associao de atributos aos elementos. Os atributos so declarados dentro da tag inicial do elemento e so definidos pelo par nome=valor. Segundo [Bradley, 1998], os atributos servem para representar informaes mais refinadas sobre um elemento. No exemplo da Listagem 6, os atributos so usados para informar o idioma, o ISBN do livro e a moeda corrente.
<produto> <livro idioma="Ingles" isbn="0-200-987508"> <titulo> The XML Companion </titulo> <preco moeda="Real"> 75.00 </preco> </livro> </produto>
37 Listagem 6 : Exemplo de utilizao de atributos em elementos de um documento XML.
Assim como tags os usurios podem definir novos atributos, sendo que o valor dos atributos deve ser sempre uma cadeia de caracteres (string) e deve ser representada entre aspas (). Existem diferenas entre os atributos e as tags. Um atributo pode ocorrer uma vez apenas juntamente com a tag, ao passo que subelementos com a mesma tag podem ser repetidos. O valor do atributo sempre uma string, enquanto que os dados compreendidos entre uma tag inicial e uma tag final podem contr subelementos. No intercmbio de dados, os atributos trazem uma certa ambigidade de quando representar as informaes como atributos ou elementos [Abiteboul et al., 2000]. Por exemplo, podemos representar as mesmas informaes sobre uma pessoa como na Listagem 7, ou como na Listagem 8, ou ainda como na Listagem 9:
<pessoa> <nome>Jimi Hendrix</nome> <idade>42</idade> <e-mail>jimi@hendrix.com</e-mail> </pessoa> Listagem 7 : Ambigidade na representao Elementos X Atributos - 1. <pessoa nome="Jimi Hendrix" idade="42" e-mail="jimi@hendrix.com"/> Listagem 8 : Ambigidade na representao Elementos X Atributos - 2. <pessoa idade="42"> <nome> Jimi Hendrix </nome> <e-mail> jimi@hendrix.com </e-mail> </pessoa> Listagem 9 : Ambigidade na representao Elementos X Atributos - 3.
3.4.3. Outros componentes da XML

A linguagem XML possui ainda outros componentes utilizados na criao de documentos utilizados pelas aplicaes que so muito pouco, ou nada utilizados no intercmbio de dados.
3.4.3.1.
Comentrios
Os comentrios so teis para escrever notas em seus documentos (tanto XML quanto HTML ou em linguagens de programao) para que voc saiba porque utilizou
38
determinado elemento ou quando uma parte das informaes necessitam de atualizao ou maior ateno. Os comentrios em um documento XML so identificados por uma tag especial que aberta pelos caracteres . A Listagem 10 mostra a utilizao dos comentrios em um documento XML.
<pessoa> <nome>Jimi Hendrix</nome>  <idade>42</idade>  <e-mail>jimi@hendrix.com</e-mail>  </pessoa> Listagem 10 : Utilizando comentrios em um documento XML.
3.4.3.2.
Instrues de Processamento
As instrues de processamento so definidas por tags iniciadas por <? e terminadas por ?> e permitem que o documento contenha instrues que sero executadas pelas aplicaes. Alm de declarar a verso da XML, as instrues de processamento tambm so utilizadas para especificar a folha de estilo a ser usada, entre outras coisas. A declarao XML opcional, mas se for includa, deve ser a primeira linha em seu documento conforme o exemplo da Listagem 11.
<?xml version="1.0" ?> <pessoa> <nome>Jimi Hendrix</nome> <idade>42</idade> <e-mail>jimi@hendrix.com</e-mail> </pessoa> Listagem 11 : Instruo de processamento em um documento XML.
Tambm pode ser necessrio utilizar essa instruo de processamento XML inicial para atribuir a codificao de caracteres utilizada no documento, como por exemplo UTF-8 conforme a Listagem 12, ou outra.
<?xml version=1.0 encoding=UTF-8?> <pessoa> <nome>Jimi Hendrix</nome> <idade>42</idade> <e-mail>jimi@hendrix.com</e-mail> </pessoa> Listagem 12 : Declarao do tipo de codificao atravs de uma instruo de processamento.
3.4.3.3.
Sees CDATA
39
Para inserir um contedo em um documento XML e evitar que o analisador (parser) interprete este contedo pode-se para isto criar uma seo CDATA no documento XML. Uma seo CDATA representada por uma tag aberta pelo conjunto de caracteres <![CDATA[ e finalizada por ]]>. Uma caracterstica importante dessa seo, que no possvel aninhar sees CDATA. Alm disso, o incio desta seo s pode aparecer depois do incio do elemento raiz e o final da seo CDATA tambm s pode aparecer antes do final do elemento raiz. A Listagem 13 nos mostra como uma seo CDATA pode ser utilizada em um documento XML.
<?xml version="1.0" encoding=UTF-8?> <pessoa> <![CDATA[Este texto no ser processado por nenhum parser pois o mesmo se encontra dentro de uma seo CDATA ]]> <nome>Jimi Hendrix</nome> <idade>42</idade> <e-mail>jimi@hendrix.com</e-mail> </pessoa> Listagem 13 : Utilizando uma seo CDATA em um documento XML.
3.5. Estrutura lgica de um documento XML

Um documento XML pode ser representado por uma estrutura em rvore pela sua natureza e caractersticas bsicas, por exemplo, o documento XML da Listagem 14 possui a representao em rvore conforme a Figura 13.
<bibliography> <book> <title> Data on the Web </title> <author> Abiteboul </author> <author> Buneman </author> <author> Vianu </author> <publisher> M. Kaufmann</publisher> <year> 1999 </year> </book> <book> <title> Principles of Distributed Database Systems </title> <author> Ozsu </author> <author> Valduriez </author> <publisher> Prentice Hall </publisher> <year> 1999 </year> </book> </bibliography> Listagem 14 : Documento XML contendo informaes bibliogrficas.
40
Documento XML
bibliography
book year
1999
book
publisher
M.Kauffman
author author
Vianu
title
Data on the Web
author
Abiteboul
Figura 13 : Estrutura em rvore de um documento XML.
3.5.1. Expresses de Caminho ( Path expressions)

As expresses de caminho so muito utilizadas para determinar o caminho para se encontrar um elemento dentro de um documento XML tomando como referncia e base o elemento raiz. Um caminho ou path uma seqncia de ns T1.T2.T3. ... .Tn, assim, com uma expresso de caminho podemos encontrar um elemento Tn dentro de um documento XML desde que exista o caminho T1T2, ..., Tn-1Tn. Assim sendo, dada a representao de uma rvore XML correspondente a um documento que armazena informaes bibliogrficas conforme a Figura 14, podemos determinar por exemplo que: conjunto de elementos {b1, b2} est no caminho : biblio.book; conjunto de elementos {a1, a2} est no caminho : biblio.book.author; conjunto de elementos {a1, t1, a2} est no caminho biblio.book.(author|title).
41
db
biblio book bi1 book
b1
author title
b2
author
a1
Buneman
t1
Data on the Web
a2
Valduriez
Figura 14 : Arvore XML contendo base de dados bibliogrfica.
3.5.2. Xpath
O XPath um padro para path expressions em XML que utiliza predicados para especificar elementos ou valores de atributos e serve de base para outros padres XML tais como XSL, entre outros. A Tabela 3 mostra alguns exemplos de predicados baseados na rvore de dados XML representados na Figura 14: Predicado / /db Resultado elemento raiz do documento um elemento chamado db abaixo (como subelemento) do elemento raiz db/book db//book @price db/book/@price db/book[@price] db/book[@price=10] //book/para[2] um elemento book imediatamente abaixo do elemento db um elemento book em qualquer profundidade um atributo price um atributo price em um elemento book, em db elementos book com um atributo price elementos book com atributo price igual a 10 o 2 pargrafo do contedo de qualquer elemento book
Tabela 3 : Exemplos de predicados da linguagem XPath.
42
3.6. XML e Dados Semi-estruturados

Outro importante tpico de pesquisa em desenvolvimento, no contexto de integrao de fontes heterogneas, aquele que se refere ao tratamento de dados do tipo semi-estruturados, suas peculiaridades, aplicaes e diferentes possibilidades de abordagem. A partir do momento em que surgiram fontes de dados com caractersticas de naturezas diversificadas, como a Web, as quais tambm se deseja tratar e integrar como as bases de dados tradicionais, normalmente representadas por meio de esquemas, ou quando se tornou desejvel ter um formato bastante flexvel para a troca de dados entre bases de dados diferentes, uma maior ateno sobre dados semi-estruturados se fez necessria[Buneman, 1997]. Vrias so as definies apresentadas para dados semi-estruturados. Um conceito bastante aceito define que so dados que no podem ser diretamente representados atravs dos modelos relacional ou de objetos, podendo ser irregulares ou incompletos [Abiteboul et al., 1998]. Outra definio afirma que este tipo de dado no pode ser representado por qualquer esquema fixo e rgido, apesar de possuir normalmente algum tipo de estrutura implcita a ele associado [Nestorov et al., 1998]. Algumas caractersticas prprias dos dados semi-estruturados segundo [Florescu, 1998b] so: ausncia de esquema previamente definido, o qual pode estar implcito nos prprios dados; esquema implcito relativamente grande, passvel de alteraes freqentes; esquema com funo descritiva, em relao ao estado corrente dos dados; no definio precisa de tipos de dados, j que para diferentes objetos, por exemplo, os valores de um mesmo atributo podem ser de diferentes tipos, em determinadas situaes.
3.7. Linguagens para Esquemas
43
Vrios tem sido os esforos no sentido de se criar mecanismos para se representar a estrutura de um documento XML. Na seqncia sero abordadas as principais propostas de linguagens para definio de esquemas para documentos XML.
3.7.1. Document Type Definition (DTD)

A DTD funciona como uma gramtica para o documento XML e parte da linguagem XML podendo tambm ser um esquema para os dados representados pelo documento XML, mas para definio destes esquemas, a DTD deixa a desejar e outras propostas surgiram aps a adoo do XML como um padro. O principal conceito dentro da XML segundo [Mello et al., 2000] o conceito de elemento, que descreve uma unidade atmica ou no-atmica de dado. Um ou mais elementos podem estar definidos previamente atravs de uma DTD, que define um padro para marcao de dados em documentos atravs da definio de uma hierarquia de elementos, onde um elemento a raiz desta hierarquia. Para que um documento XML esteja de acordo com uma DTD, apenas os elementos e as estruturas de aninhamento entre elementos definidas na DTD so permitidos no corpo do documento - esta validao feita por parsers XML. Em uma DTD, uma definio de elemento pode ser atmica ou complexa. No primeiro caso, o elemento possui apenas um contedo textual. No segundo caso, o elemento agrega subelementos componentes. Elementos componentes podem ser definidos como obrigatrios ou opcionais e tambm podem se repetir. Elementos podem ainda ter atributos. Atributos devem pertencer a um tipo de dado9 e podem ter um valor default. Considere o documento da Listagem 15:
<?xml version="1.0"?> <base-de-dados> <pessoa> <nome> Jimi Hendrix </nome> <idade> 33 </idade> <e-mail> jimi@hendrix.com </e-mail> </pessoa> </base-de-dados> Listagem 15 : Documento XML para definio de sua estrutura atravs de esquemas.
DTDs suportam alguns tipos de dados derivados de strings.
44
A DTD para ela ficaria definido conforme a Listagem 16:

<DOCTYPE base-de-dados [ <!ELEMENT base-de-dados (pessoa*)> <!ELEMENT pessoa (nome, idade, e-mail)> <!ELEMENT nome (#PCDATA)> <!ELEMENT idade (#PCDATA)> <!ELEMENT e-mail (#PCDATA)> ]> Listagem 16 : DTD para documento da Listagem 15.
A primeira linha informa que o elemento raiz o <base-de-dados>. As prximas cinco linhas so declaram que o elemento <base-de-dados> deve conter um nmero qualquer de elementos pessoa cada um contendo os subelementos nome, idade e e-mail, sendo que os ltimos contem apenas dados e no contem outros elementos. Assim, pessoa* uma expresso regular, indicando que existiro qualquer nmero de ocorrncias do elemento pessoa. Outras expresses regulares permitidas so e+ (uma ou mais ocorrncias), e? (zero ou uma ocorrncia), entre outras. A DTD uma gramtica para o documento XML. No exemplo de DTD da Listagem 16, podemos notar que o mesmo define que obrigatoriamente os subelementos nome, idade e e-mail devero aparecer nesta ordem no elemento pessoa.
3.7.2. XML Schema

XML Schema uma proposta da W3C [Fallside, 2000] para descrever a estrutura de um documento XML. XML Schema um padro mais abrangente que uma DTD, permitindo expressar tipos de dados, herana, tipos abstratos, unicidade e chaves, entre outras funcionalidades [Mello et al., 2000]. Uma especificao em XML Schema sempre inicia com a tag <schema> e termina com a tag </schema>. Todas as declaraes de elementos, atributos e tipos devem ser inseridas entre estas duas tags. Tipos, que representam a estrutura de uma classe de documentos e seus relacionamentos com outras classes, podem ser definidos. Um tipo pode ser: simples (simpleType): um tipo bsico como string, date, float, double, timeDurations, etc.
45
complexo (complexType): define a estrutura de um elemento, ou seja, define caractersticas como subelementos, atributos, cardinalidades dos
subelementos e obrigatoriedade dos atributos. Considere novamente o documento XML da Listagem 15, a especificao XML Schema para ela ficaria definido conforme a Listagem 17:
<?xml version="1.0"?> <schema xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:grp="http://meunamespace.com/base-de-dados_pessoas" targetNamespace="http://meunamespace.com/exemplobase-de-dados"> <complexType name="tbase-de-dados"> <element ref="pessoa" minOccurs='1' maxOccurs='*'/> </complexType> <complexType name="tpessoa"> <element name="nome" type="string" minOccurs='1' maxOccurs='1'/> <element name="idade" type="integer" minOccurs='1' maxOccurs='1'/> <element name="e-mail" type="string" minOccurs='1' maxOccurs='1'/> </complexType> <element name="base-de-dados" type="tbase-de-dados"/> <element name="pessoa" type="tpessoa"/> </schema> Listagem 17 : XML Schema para documento da Listagem 15.
O exemplo acima mostra a declarao de um complexType tbase-de-dados e mais adiante uma declarao:
<element name="base-de-dados" type="tbase-de-dados"/>
Esta segunda declarao liga o elemento base-de-dados ao complexType tbase-dedados, indicando que, em uma instncia de um documento XML que segue este esquema, deve-se ter um elemento base-de-dados com o subelementos pessoa, que da mesma forma est ligado ao complexType tpessoa que deve conter os elementos nome, idade e e-mail. As cardinalidades mnima e mxima so indicadas pelos atributos MinOccurs e MaxOccurs, respectivamente. ComplexTypes podem ter atributos, que so declarados atravs da tag <attribute> e devem ser do tipo simpleType. Um atributo pode ser declarado como obrigatrio ou opcional atravs da clusula use. Os valores permitidos para esta clusula so required (obrigatrio), optional (opcional) ou fixed (fixo). No ltimo caso, deve-se dizer o valor default do atributo utilizando a clusula value.
46
Ainda, pode-se restringir o contedo de um elemento atravs do uso de um atributo chamado content, que pode assumir os seguintes valores: textOnly (apenas texto); elementOnly (apenas subelementos); mixed (texto e subelementos); ou empty (contedo vazio). A XML Schema possui um mecanismo de derivao de tipos, permitindo a criao de novos tipos a partir de outros j existentes. Isto pode ser feito de duas maneiras: por restrio ou por extenso. Tipos simples s podem ser derivados por restrio, aplicando-se "facetas" a um tipo bsico ou utilizando uma linguagem de expresses regulares [Mello et al., 2000]. O exemplo abaixo mostra a derivao de um tipo simples chamado inteiroDerivado atravs da aplicao de facetas que restringem o valor mnimo e mximo de um valor inteiro.
<simpleType name="inteiroDerivado" base="integer"> <minInclusive value="1"/> <maxInclusive value="20"/> </simpleType> Listagem 18 : Derivao de tipos com a XML Schema.
Tipos complexos podem ser derivados por restrio ou por extenso. A derivao por restrio permite, por exemplo, restringir a cardinalidade de um subelemento. A derivao por extenso adiciona caractersticas a um tipo, sendo semelhante ao conceito de herana [Fallside, 2000]. O exemplo da Listagem 19 mostra o complexType tpessoacomfiliacao acrescenta os elementos "nome-do-pai" e "nome-da-mae" ao complexType tpessoa, com cardinalidades mnima igual a 1 e mxima igual a 1.
<complexType name="tpessoacomfiliacao" base="tpessoa" derivedBy="extension"> <element name="nome-do-pai" type="string" minOccurs='1' maxOccurs='1'/> <element name="nome-da-mae" type="string" minOccurs='1' maxOccurs='1'/> </complexType> Listagem 19 : Derivao de um complexType em XML Schema.
Grupos especificam restries sobre um conjunto fixo de subelementos, podendo ser de trs tipos: sequence estabelece que todos os elementos pertencentes a ele devem aparecer na ordem em que foram definidos e nenhum pode ser omitido;
47
choice estabelece que apenas um dos elementos pertencentes ao grupo deve aparecer em uma instncia XML;
all estabelece que os elementos podem aparecer em qualquer ordem e podem ser repetidos ou omitidos.
Um exemplo de definio de um grupo do tipo sequence para o complexType tpessoa pode ser visto na Listagem 20.
<group> <sequence> <complexType name="tpessoa"> <element name="nome" type="string" minOccurs='1' maxOccurs='1'/> <element name="idade" type="integer" minOccurs='1' maxOccurs='1'/> <element name="e-mail" type="string" minOccurs='1' maxOccurs='1'/> </complexType> </sequence> </group> Listagem 20 : Definio de grupos com XML Schema.
Uma declarao de atributo, elemento ou grupo pode ser referenciada, permitindo a reutilizao de declaraes, como a declarao:
<element ref="pessoa" minOccurs='1' maxOccurs='1'/>
dentro do complexType tbase-de-dados na Listagem 17. A nica restrio no uso de referncias que o elemento referido seja global, ou seja, tenha sido declarado dentro de <schema>, porm, no dentro de um complexType.
3.7.2.1.
Namespaces
Pelo fato da XML ser extensvel com a possibilidade da criao de qualquer tag, conflitos entre estas tags podem ocorrer. Num mesmo documento podem existir dois elementos com mesmo nome, mas que possuam significados diferentes. Ou ainda, como no existe um rgo global responsvel pela especificao de elementos XML (isto tiraria a flexibilidade da linguagem), um programador pode criar uma tag para armazenar determinada informao e, outro programador pode criar uma outra tag para guardar o mesmo tipo de informao. Por exemplo, um dono de uma vdeo locadora cria a tag GNERO para indicar se o filme de comdia, terror, ao ou drama. J um outro
48
dono de locadora, cria a tag TIPO para o mesmo objetivo. Se as duas empresas forem trocar informaes, ocorrer um conflito ou no entendimento dos dados contidos no documento XML. Para esta problemtica foi criada uma pequena extenso para XML denominada namespaces. Namespaces no limitam a facilidade de extenso da XML, mas insere um mecanismo para gerenci-la. Com os namespaces pode-se misturar elementos descritivos definidos por comunidades independentes, sem medo de cometer discrepncias na nomeao, uma vez que cada segmento de dados est vinculado a um URI (Universal Resource Indicator) que fornece um contexto e uma definio para tal segmento. Um esquema especificado atravs do XML Schema pode ser visto como um conjunto de declaraes de tipos e elementos cujos nomes pertencem a um namespaces [Bray et al., 1999]. Todo esquema definido atravs de XML Schema deve definir um nico namespace, sendo usual o formato de URI para a sua identificao O uso de namespaces aumenta a flexibilidade de XML Schema, permitindo a reutilizao de definies feitas em outros esquemas. A utilizao de um tipo definido em outro esquema possvel atravs da sua declarao e da associao de um prefixo a ele [Mello et al., 2000].
<?xml version=1.0?> <referencias xmlns:mau=http://mauri.org/documents/> <mau:descricao>Artigo sobre P2P</mau:descricao> <mau:autor>Mauri Ferrandin </mau:autor> <mau:data>15/07/2002</mau:data> </referencias> Listagem 21 : Utilizao de namespaces em XML
Na Listagem 21, foram utilizados elementos definidos na URI mauri.org e foi utilizado como namespace o prefixo mau, que, por sua vez, est associado a um URI. Neste URI que esto definidos o que significa cada elemento (autor, data, descricao, etc.). Com o recurso do namespace, permitido que cada autor elabore semnticas adicionais requeridas pelos tipos particulares de recursos ou por uma rea de atuao especfica.
3.7.3. XDR
49
Primeiramente chamada de XML-Data e mais tarde abreviada para XDR (XML-Data Reduced), esta linguagem um esforo da Microsoft e algumas outras empresas e foi usada no Microsoft Bizz Talk Framework. A XDR foi fortemente influenciada por outra proposta desenvolvida em cooperao entre a Microsoft e a IBM denominada DCD (Document Content Description) o que faz com que as duas tenham muitas caractersticas em comum.
3.7.4. SOX
A SOX (Schema for Objetc-Oriented XML) uma linguagem alternativa para definio da estrutura sinttica de um documento XML e parcialmente a sua estrutura semntica. Conforme o prprio nome, ela extenso da DTD incorporando funes de orientao a objetos, permitindo a herana de tipos de dados e de elementos. mantida e desenvolvida pela Commerce One.
3.7.5. Schematron
O Schematron foi criada por Rick Jelliffe, um pouco diferente das demais uma vez que seu foco est na validao de esquemas usando padres ao invs de definir esquemas. Seu esquema simples e pode ser representado em uma simples pgina, alm de permitir a definio de restries poderosas atravs da linguagem XPath.
3.7.6. DSD
A DSD foi desenvolvida pela AT&T Labs em cooperao com a BRICS com o objetivo de ser uma descrio para os elementos e atributos dependendo do contexto, com mecanismos padres de insero bem flexveis e um poder expressivo quando combinada com XSLT. Assim como a Schematron, a DSD fortemente focada na definio de esquemas baseados em restries.
3.7.7. Tabela comparativa

A Tabela 4 apresenta um comparativo entre as seis principais linguagens para definio de esquemas de dados para XML segundo [Lee e Chu, 2000].
50
Features Esquemas Sintaxe em XML Namespace Incluses Importaes Tipos de Dados Tipos pr-definidos Tipos definidos pelo usurio Restries de domnio Tipos nulos Atributos
DTD 1.0
XML Schema 1.0 Sim Sim Sim Sim
XDR 1.0
SOX 2.0
Schematron 1.4
DSD 1.0
No No No No
Sim Sim No No
Sim Sim Sim Sim
Sim Sim No No
Sim No Sim No
10 No No No
37 Sim Sim Sim
33 No No No
17 Sim Parcial No
0 No Sim No
0 Sim Sim No
Valor default Sim Tipo escolha (choice) No Opcional vs. Obrigatrio Sim Restries de domnio Parcial Definies condicionais No Elementos Valor default No Modelo de contedo Sim Seqncia ordenada Sim Seqncia no ordenada No Escolha Sim Ocorrncias mx. e mn. Parcial Modelo aberto No Definio condicional No Herana Tipos simples por extenso Tipos simples por restrio Tipos complexos por extenso Tipos complexos por restrio Unicidade de chaves No No No No
Sim No Sim Sim No
Sim No Sim Parcial No
Sim No Sim Parcial No
No Sim Sim Sim Sim
Sim Sim Sim Sim Sim
Parcial Sim Sim Sim Sim Sim No No
No Sim Sim Sim Sim Sim Sim No
No Parcial Sim No Sim Sim No No
No Sim Sim Sim Sim Sim Sim Sim
Sim Sim Sim Sim Sim Parcial No Sim
No Sim Sim Sim
No No No No
No Sim Sim No
No No No No
No No No No
Unicidade para atributos Sim Unicidade para no atributos No Chave para a atributos No Chave para no atributos No Chave estrangeira para a Parcial atributos Chave estrangeira para no No atributos Outros Restries dinmicas No Verses No Documentao No HTML Embutido No Auto descrio No
Sim Sim Sim Sim Sim Sim
Sim Parcial No No Parcial No
Sim No No No Parcial No
Sim Sim Sim Sim Sim No
Sim No No No Sim Sim
No No Sim Sim Parcial
No No No No No
No No Sim Sim No
Sim No Sim Parcial Parcial
No Sim Sim Sim Sim
51 Tabela 4 : Comparativo entre as seis principais linguagens para esquema.
3.8. Linguagens de consulta para dados XML

Uma das grandes questes por que no adaptar a SQL ou a OQL para executar consultas sobre dados XML. A resposta esta no fato de que dados XML so fundamentalmente diferentes de dados relacionais ou orientados a objetos, e ento, nem a SQL, nem a OQL so apropriadas para consultas a dados XML. O fator chave que diferencia dados XML dos dados armazenados em modelos tradicionais que os dados XML no apresentam estrutura rgida. Nos esquemas relacionais e orientados a objetos, os dados possuem um esquema que esta separado e independente dos dados, j no caso de dados XML o esquema est juntamente com os dados. Assim, podemos dizer que os dados XML so auto-descritivos e podem naturalmente modelar dados com estruturas irregulares e que no podem ser modelados em esquemas tradicionais.
3.8.1. Requisitos de uma linguagem de consulta para dados XML

Nesta seo, sero abordados os requisitos necessrios para uma linguagem de consulta para dados XML. Preciso semntica. Uma linguagem de consulta para dados XML deve possuir uma formalidade semntica. Habilidade de rescrita e otimizao. Os dados XML sero gerados a partir de outros formatos, tais como relacional e orientado a objetos, ou outros formatos utilizados para propsitos mais especficos. Operaes de consulta. As diferentes operaes que devem ser suportadas por uma linguagem de consulta so: seleo, extrao, reduo, reestruturao, combinao Semntica composicional. As expresses definidas na linguagem de consulta XML devem possuir transparncia referencial, ou seja, o significado de uma expresso deve ser o mesmo independente de onde ela aparece.
52
No requer esquema. Uma linguagem de consulta para dados XML deve executar consultas a dados XML mesmo quando no existir um esquema
definido para estes dados (DTD, XML-Schema ou outro). Explora esquema disponvel. Quando o DTD estiver disponvel para a fonte de dados, a linguagem de consulta deve ser capaz de julgar quando a consulta est corretamente formulada em relao ao DTD. Preserva ordem e a associao. Uma linguagem de consulta para dados XML deve ser capaz de preservar a ordem e a associao dos elementos dos dados XML, se necessrio. Baseada em XML. Uma consulta XML deve ser capaz de conter dados arbitrrios XML, e um documento XML deve ser capaz de armazenar consultas arbitrrias. Suporta novos tipos de dados. Uma linguagem de consulta para dados XML deve conter um mecanismo de extenso para operaes e condies especficas para um tipo de dado em particular. Apropriada para metadados. A linguagem de consulta para dados XML deve poder ser utilizada como parte da descrio dos metadados. Processada no servidor. Uma linguagem de consulta para dados XML deve apresentar a possibilidade de ser executada remotamente no servidor independente do contexto local da aplicao. Manipulvel atravs de programao. Uma consulta poder ser formulada por programas em tempo de execuo. Representvel atravs de XML. Uma consulta deve ser representvel atravs de XML.
3.8.2. Exemplo de linguagem de consulta para dados XML (XML-QL)

Na seqncia sero demonstradas alguns casos de uso, caractersticas e funcionalidades de uma linguagem para consulta a dados XML. A linguagem ser a
53
XML-QL, uma vez que a mesma ser utilizada na etapa de desenvolvimento do prottipo proposto por este trabalho. Tomemos um documento XML com a estrutura descrita de acordo com a DTD definida na Listagem 22 disponvel em um determinado site acessvel atravs da URI www.a.b.c/bib.xml:
<!ELEMENT livro (autor+, titulo, editora)> <!ATTLIST livro ano CDATA> <!ELEMENT artigo (autor+, titulo, ano?, (versaoresumida|versaocompleta))> <!ATTLIST artigo tipo CDATA> <!ELEMENT editora (nomeeditora, endereco)> <!ELEMENT autor (nome?, sobrenome)> Listagem 22 : DTD para exemplo de consultas XML-QL.
Esta DTD especifica que um elemento livro contm um ou mais elementos autor, um elemento titulo, um elemento editora e um atributo ano. Um artigo similar, sendo que o atributo ano opcional, no possui editora, e possui um elemento versaoresumida ou um elemento versaocompleta. Um elemento artigo possui um atributo chamado tipo. O elemento editora contm um elemento nomeeditora e um elemento endereo, e um elemento autor possui um elemento nome nomeeditora, endereo, nome e sobrenome so todos do tipo CDATA. Recuperando dados atravs da identificao de padres : a XML-QL usa elementos padres para recuperar dados de um documento XML. O exemplo de consulta da Listagem 23 retorna todos os autores que publicaram obras pela editora Addison-Wesley que esto presentes em um documento XML na URI www.a.b.c/bib.xml. Toda a URI que representa uma fonte de dados XML deve aparecer a direita da palavra reservada IN.
WHERE <livro> <editora> <nomeeditora>Addison-Wesley</nomeeditora> </editora> <titulo> $t</titulo> <autor> $a</autor> </livro> IN "www.a.b.c/bib.xml" CONSTRUCT $a Listagem 23 : Exemplo de consulta bsica XML-QL.
no
obrigatrio e um elemento sobrenome obrigatrio. Assumimos que os campos
54
Na prtica, esta consulta encontra todos os elementos <livro> no documento XML presente na URI www.a.b.c/bib.xml que tenha um subelemento <titulo>, um subelemento <autor> e um subelemento <editora>, sendo que o ltimo possui um subelemento <nomeeditora> o qual possui valor igual a Addison-Wesley. Para cada elemento que se enquadre na consulta ele armazena o nome do autora na varivel a ($a) e o ttulo da obra na varivel t ($t) . Note que todos os nomes de variveis so precedidos pele caracter $ para distinguir as mesmas dos outros valores literais presentes no documento. Pode-se abreviar o fechamento da tag de cada elemento (</elemento> por exemplo) utilizando apenas a tag </>. Assim, a consulta anterior (Listagem 23) pode ser descrita conforme na Listagem 24.
WHERE <livro> <editora><nomeeditora>Addison-Wesley</></> <titulo> $t</> <autor> $a</> </> IN "www.a.b.c/bib.xml" CONSTRUCT $a Listagem 24 : Exemplo de consulta bsica XML-QL com abreviao de tags.
Montando os resultados em um documento XML: a consulta exibida anteriormente retorna a lista de todos os autores com publicaes na editora AddisonWesley presentes no documento. muito importante porm que os resultados de uma consulta XML-QL sejam retornados no formato XML por questes de padronizao. A consulta na seqncia retorna todos os nomes dos autores e os ttulos de suas publicaes dentro de um elemento raiz chamado <resultado> :
WHERE <livro> <editora><nomeeditora>Addison-Wesley</></> <titulo> $t</> <autor> $a</> </> IN "www.a.b.c/bib.xml" CONSTRUCT <resultado> <autor> $a </> <titulo> $t </> </> Listagem 25 : Consulta XML-QL formatando os resultados em XML.
Para exemplificar melhor, tomemos o documento XML da Listagem 26:

<bib> <livro ano="1995"> <titulo> Integrando fontes de dados</titulo>
55
<autor> <sobrenome> Ferrandin</sobrenome> </autor> <editora> <nomeeditora> Addison-Wesley </nomeditora> </editora> </livro> <livro ano="1998"> <titulo> Foundation for Object/Relational Databases </titulo> <autor> <sobrenome> Date </sobrenome> </autor> <autor> <sobrenome> Darwen </sobrenome> </autor> <editora> <nameeditora> Addison-Wesley </nameeditora > </editora> </livro> </bib> Listagem 26 : Documento XML contendo dados bibliogrficos.
Aplicando a consulta anterior (Listagem 25) sobre o documento exemplo acima (Listagem 26) obteremos os resultados conforme a Listagem 27:
<resultado> <autor><sobrenome> Date </sobrenome> </autor> <titulo>Na Introduction to Database Systems </titulo> </resultado> <resultado> <autor> <sobrenome> Date </sobrenome> </autor> <titulo>Foundation for Object/Relational Databases</titulo> </resultado> <resultado> <autor> <sobrenome> Darwen </sobrenome> </autor> <titulo>Foundation for Object/Relational Databases </titulo> </resultado> Listagem 27 : Formatando o resultado de uma consulta XML-QL em XML.
Agrupando dados usando consultas aninhas: a consulta anterior (Listagem 25) no agrupava os autores de acordo com o livro, ou seja, no caso da existncia de dois autores para o mesmo ttulo ela retorna um elemento <resultado> para cada autor. Para agruparmos o resultado por ttulo teremos que usar consultas aninhadas (Listagem 28) que retornar um elemento <resultado> para cada ttulo e cada um contendo a lista dos seus respectivos autores.
WHERE <livro> $p </> IN "www.a.b.c/bib.xml", <titulo> $t </>, <editora><nomeeditora>Addison-Wesley</> </> IN $p CONSTRUCT <resultado> <titulo> $t </>
56
WHERE <autor> $a </> IN $p CONSTRUCT <autor> $a</> </> Listagem 28 : Agrupando dados atravs de consultas aninhadas.
Aplicando esta consulta (Listagem 28) sobre o documento XML exemplo da Listagem 26 teremos os resultados mostrados na Listagem 29:
<resultado> <titulo> An Introduction to Database Systems </titulo> <autor> <sobrenome> Date </sobrenome> </autor> </resultado> <resultado> <titulo> Foundation for Object/Relational Databases </titulo> <autor> <sobrenome> Date </sobrenome> </autor> <autor> <sobrenome> Darwen </sobrenome> </autor> </resultado> Listagem 29 : Resultado de uma consulta agrupando o resultado.
Junes de elementos pelo valor : XML-QL pode expressar junes (joins) encontrando um ou mais elementos que contm o mesmo valor. Por exemplo, a consulta da Listagem 30, recupera todos os artigos que tenham pelo menos um autor que tenha sido escrito um livro desde 1995. Aqui, assumimos que o autor tem o mesmo nome e sobrenome (representados pelas variveis $f e $1) para livros e artigos.
WHERE <artigo> <autor> <nome> $f </> <sobrenome> $l </> </> </> CONTENT_AS $a IN "www.a.b.c/bib.xml" <livro ano=$y> <autor> <nome> $f </> <sobrenome> $l </> </> </> IN "www.a.b.c/bib.xml", y > 1995 CONSTRUCT <artigo> $a </> Listagem 30 : Junes de elementos pelo valor em uma consulta XML-QL.
Existem muitas outras consultas possveis utilizando a linguagem XML-QL, mas a inteno aqui mostrar apenas o bsico. Construes utilizando tag com variveis, expresses regulares de caminhos (regular path expressions), transformaes de dados
57
atravs de consultas XML-QL, integrao e consultas a vrias fontes simultneas, criao de funes, namespaces, semi-junes entre outras podem ser utilizadas de acordo com as necessidades das aplicaes/desenvolvedores. A gramtica completa contendo a BNF10 da linguagem XML-QL pode ser visualizada junto ao apndice deste trabalho no Anexo 1 : XML-QL Grammar.
3.8.3. Outras linguagens de consultas para dados XML

Existem vrias propostas de linguagens de consulta para dados XML, sendo que sero abordadas aqui as principais, uma lista completa pode ser obtida em http://www.w3.org/TandS/QL/QL98/. LORE(Lightweight Object Repository) um sistema de gerenciamento de dados semi-estruturados. Sua linguagem de consulta, a LOREL, foi obtida atravs da extenso da OQL para consultar dados semi-estruturados. Recentemente, a Lorel foi adaptada para consultar dados XML. A XSL proposta pela W3C pode tambm ser vista como uma linguagem de consulta para dados XML, mas suas funcionalidades so muito limitadas. Ela no suporta joins ou funes do tipo skolen, mas ainda assim, pode ser usada como uma linguagem de consulta dentro de um escopo limitado. Ao contrrio de outras linguagens, com a XSL, fcil fazer processamento recursivo. Por exemplo, a consulta XSL da Listagem 31 recupera todos os elementos autor de um documento, independente da profundidade na qual o mesmo se encontra.
<xsl:template> <xsl:apply-templates/> </xsl:template> <xsl:template match=''author''> <result> <xsl:value-of/> </result> </xsl:template> Listagem 31 : Consulta XSL para dados XML.
A XQL uma linguagem que essencialmente consiste de uma busca de padres atravs de XSL com uma sintaxe bem definida para a construo dos resultados. Seu poder de reestruturao restrito a um subconjunto da linguagem XSL. A XML-GL uma linguagem de consulta grfica para XML, da mesma linha da linguagem QBE11. Na XML-GL, ambas as clusulas WHERE e CONSTRUCT so
10
BNF uma notao para descrio formal de linguagens de programao.
58
especificadas atravs de uma interface grfica, e suas funcionalidades so similares a XML-QL. A Tabela 5 mostra um comparativo entre as seis principais linguagens de consulta para dados XML segundo [Bonifati e Ceri, 1999].
Linguagem / Caracterstica Modelos de dados especficos Gerenciamento diferencial de IDREFs Seleo de Documentos Junes Formato do resultado Especificao e expresses de caminho parciais. Parada Quando encontrar dados cclicos Quantificao existencial Qualificadores Universais Negaes Redues Construo de novos elementos Construes em grupos Funes skolem Agregao Consultas aninhadas Consultas binrias Ordenao dos resultados Preservando ordem dos resultados Consultas ordenadas por esquemas Consultas por ordem de instncias Abstrao de tipos Coero de tipos Suporte a RDF Suporte a Xpointer e Xlink Tags variveis Linguagens de atualizao LOREL Sim Sim Sim Sim Conj. de OIDs Sim Sim Sim Sim Sim No Sim Sim Sim Sim Sim Sim Sim Sim No Sim Sim Sim No No Sim Sim XML-QL Sim No Sim Sim Documento XML Sim Indefinido Sim No No No Sim No Sim No Sim Parcial Sim Sim Sim No No No No No Sim No XML-GL Sim No Sim Sim Documento XML Parcial Sim Sim No Sim No Sim Sim Parcial Sim No Sim Sim Sim No No No No No No No Sim XSL Sim No Sim No Documento XML Sim No Sim No Sim No Sim No No Parcial Sim Sim Sim Sim No No No No No No No No XQL No No Sim No Documento XML Sim Indefinido Sim Sim Sim No No No No Parcial No Sim No Sim No Sim No Partially No No No No
11
QBE (Query by Example) Consultas atravs de exemplos.
59 Tabela 5 : Comparativo entre linguagens de consulta para XML
3.9. APIs para XML

Existem dois tipos principais de API para dados XML: API baseada em rvores (Tree-based APIs) : mapeia o documento XML em uma estrutura de rvore e permite a aplicao navegar entre os nodos desta rvore. O grupo de trabalho para definio do DOM coordenado pela W3C mantm as recomendaes das API baseadas em rvore para documentos XML e HTML, sendo que existem muitas outras APIs definidas por outras entidades. O DOM ser abordado na seo 3.9.2; API baseada em eventos (Event-based API) : reporta eventos no processo de parsing diretamente a aplicao atravs de callbacks, e no mapeia os dados para uma estrutura interna de rvore. A aplicao por sua vez implementa os handlers para lidar com cada um dos eventos que possam ocorrer. SAX o melhor exemplo deste tipo de API e ser abordado na seo 3.9.1. As APIs baseadas em rvores so muito teis para uma grade variedade de aplicaes, mas normalmente demandam grande quantidade de recursos do sistema, especialmente se o documento for grande. As APIs baseadas em eventos provm um acesso simples e de baixo nvel ao documento XML, assim, possvel manipular documentos muito maiores que a capacidade de memria do sistema, alm de possibilitar a implementao de novas estruturas atravs do tratamentos de eventos que disparam os callbacks. Considere, por exemplo, a seguinte tarefa : Localizar o elemento que contm a palavra Florianpolis. Se o seu documento for de uns 20MB por exemplo, ser ineficiente construir e armazenar na memria uma rvore contendo os dados do arquivo somente para encontrar uma parte muito pequena compreendida no mesma. Utilizando uma API baseada em eventos, ser possvel encontrar est palavra no documento usando muito menos memria do sistema.
3.9.1. SAX
60
A API SAX mais voltada para a sintaxe, enquanto DOM oferece muitas funcionalidades para desenvolver algumas aplicaes com dados XML. A SAX um API padro para anlise (parsing) documentos XML. Um parser SAX l o fluxo de dados XML, analisa-os e detecta eventos ao interpretar as tags. Estes eventos so coletados pela aplicao que pode realizar aes especficas para cada um deles. Para entender como funciona uma API baseada em eventos (como e o caso da SAX), considere o documento da Listagem 32, ao ser analisado por uma API baseada em eventos. A API ir dividir a estrutura deste documento em uma srie de eventos lineares tais como : start document; start element: doc; start element: para; characters: Alo, mundo!; end element: para; end element: doc; end document;
<?xml version="1.0"?> <doc> <para>Alo, Mundo!</para> </doc> Listagem 32 : Documento para ser processado atravs de SAX.
A aplicao por sua vez ir tratar cada um destes eventos tal como trata eventos gerados por uma interface grfica de um usurio: no h necessidade de armazenar o documento inteiro na memria ou em um meio de armazenamento secundrio.
3.9.2. DOM
O DOM uma API para documentos HTML e XML. Ela define a estrutura lgica dos documentos e como estes documentos sero acessados e manipulados. Na especificao do DOM o termo documento (document) largamente usado. XML est sendo usado como uma maneira de representar muitos tipos diferentes de informaes que podem estar armazenadas nos diversos sistemas e o DOM usado para manipular estes dados [Wood, 1998]. Com o DOM, os programadores podem construir documentos, navegar na sua estrutura, modificar ou apagar elementos no seu contedo. Qualquer dado presente em um documento XML pode ser acessado, alterado, excludo, ou adicionado usando o DOM. Sendo uma especificao da W3C, o objetivo mais importante do DOM prover uma interface padro para programao que possa ser usada por uma grande quantidade de ambientes e aplicaes. O DOM foi desenvolvido para ser usado com qualquer linguagem de programao.
61
No DOM os documentos tem uma estrutura lgica que muito semelhante a uma rvore. A representao de uma tabela HTML da Listagem 33, tem a estrutura lgica representada no DOM conforme a Figura 15.
<TABLE> <TBODY> <TR> <TD>Shady Grove</TD> <TD>Aeolian</TD> </TR> <TR> <TD>Over the River, Charlie</TD> <TD>Dorian</TD> </TR> </TBODY> </TABLE> Listagem 33 : Representao de uma tabela em HTML.
O nome "Document Object Model" foi escolhido por que ele um modelo de objetos dentro do desenvolvimento orientado a objetos : os documentos so modelados usando objetos e o modelo agrega no apenas a estrutura deste documento mas tambm o comportamento do documento e dos objetos que o compe. Em outras palavras, os ns da Figura 15 no representam a estrutura dos dados, eles representam os objetos os quais possuem funes e identidade.
Figura 15 : Representao lgica de uma tabela HTML em um DOM.
Segundo [Wood, 1998], a estrutura de um documento SGML tradicionalmente representada por um modelo abstrato, e no por um modelo de objetos. Em um modelo abstrato, o modelo centrado nos dados. Nas linguagens de programao orientadas a objetos, os dados esto encapsulados nos objetos que armazenam estes dados, no sendo permitido que os mesmos sejam manipulados diretamente por objetos externos. As funes associadas a estes objetos determinam como estes objetos podem ser manipulados, e elas so parte do modelo de objetos. O DOM atualmente est divido em duas partes : DOM Core - representa as funcionalidades utilizadas para manipular documentos XML e tambm serve como base
62
para a DOM HMTL, e o DOM HTML que representa as funcionalidades utilizadas para manipular documentos HTML.
3.10. Integridade em documentos XML

As questes referentes a manuteno de restries de integridade em documentos XML vem recebendo grande ateno pela comunidade de pesquisadores e muitos esforos tem sido feitos no sentido de se criar maneiras e padres para a definio e validao de regras de integridade como por exemplo chaves primrias ou chaves estrangeiras. Vrias propostas foram feitas no sentido de se definir e validar restries de integridade em documentos XML utilizando os padres da especificao XML como atravs da DTD, XML Schema, entre outros [Buneman et ali, 2001]. O maior problema para se determinar restries de integridade em um documento XML est em como especificar que, por exemplo, em um determinado nvel da rvore XML, um determinado elemento ser chave primria, ou seja, ele s poder existir uma vez naquele nvel, ou como, por exemplo, dizer que um atributo deste mesmo elemento ser chave estrangeira de elementos que se encontram em outros nveis da rvore. Para se resolver este problema, necessrio a utilizao de um padro para se especificar os caminhos dentro da rvore XML para assim se poder acessar a um determinado nvel da rvore. Para [Buneman et al., 2001], chaves so de fundamental importncia em uma base de dados, elas proporcionam um meio eficiente para se localizar objetos e relacionar uma objeto com o outro (relacionamentos), e as mesmas so de grande importncia na validao de dados, permitindo mantr os mesmos de acordo com o modelo definido baseado no mundo real. Muitas propostas para manuteno de chaves foram feitas usando o prprio padro XML atravs de DTD e XML Schema para manuteno das mesmas, mas estas propostas se mostram deficientes em muitos casos. Como um documento XML no precisa necessariamente possuir uma definio de sua gramtica (atravs de DTD, XML Schema), muito til que o mesmo possua um mecanismo para especificao de chaves independente do tipo de documento XML.
63
Para superar estas limitaes, autores prope mecanismos para definio de chaves que : possam ser definidos atravs de uma ou mais expresses de caminho, possibilitando indicar precisamente um determinado n em uma rvore XML; possam ser definidas para um conjunto relativo de ns; no dependa de qualquer mecanismo utilizado para especificar a estrutura do documento, como por exemplo DTD e XML Schema. [Chen et ali., 2002] props uma notao para definio de chaves com a seguinte sintaxe : (Q, (Q,{P1,...,PP})) onde Q, Q, e P1,...,PP so expresses de caminho12. Q chamado de caminho do contexto (context path), Q o caminho alvo (target path) e P1,...,PP so caminhos chaves (keys path). A idia que o caminho de contexto Q identifique o conjunto de ns do contexto (context nodes) onde para cada n n a restrio de integridade deve ser respeitada no conjunto de ns acessveis atravs do caminho alvo Q. Por exemplo, a chave KS1 definida por : KS1= (/, (./universidade, {./nome})) indica que no caminho de contexto / (ou seja raiz do documento) uma universidade identificada por um subelemento chamado nome. Outro exemplo, tomemos uma chave KS2= (/universidade, (.//funcionario, {./@codigofuncionario})) que indica que no dentro de um nvel do documento identificado pelo elemento universidade (caminho de contexto), um funcionrio em qualquer subnvel (indicado pelo .//) do documento dentro do caminho de contexto identificado pelo por um atributo (@) do elemento funcionrio denominado codigofuncionario. Como um terceiro exemplo, tomemos uma chave KS3= (/, (.//funcionario, {./nome, /telefone})) que indica que no caminho de contexto /, ou seja todo o documento, um elemento funcionario em qualquer subnvel da rvore identificado unicamente por um elemento denominado nome e um elemento denominado telefone. Esta notao complexa, mas permite definio de restries de integridade em documentos XML. Existem muitas outras propostas diferentes e com estudos
64
aprofundados propondo algoritmos de validao para verificar um documento est de acordo com um conjunto de restries para ele pr-determinadas.

O padro XML uma poderosa ferramenta capaz de representar dados que no so possveis de se representar atravs dos modelos tradicionalmente utilizados, tais como os modelos relacional e objeto. Esta vantagem se deve pelo fato de que os dados XML so auto-descritivos, ou seja, sua estrutura esta representada juntamente com seu contedo atravs da organizao e aninhamento de seus elementos, e ao contrrio da HTML, no armazena informaes sobre como estes dados sero apresentados. O padro XML separa os dados das questes de apresentao, permite que os mesmos sejam formatados e apresentados atravs de uma folha de estilos (XSL) por exemplo de diversas maneiras e para os mais variados fins. Os padres para definio de esquemas tem um papel fundamental na definio de gramticas para os dados XML, dentre elas, merecem destaque a DTD e a XML Schema, esta ltima muito mais poderosa e em constante evoluo. Linguagens de consulta para dados XML permitem so uma ferramentas poderosas que permitem a execuo de consultas em dados XML possibilitando extrair e/ou alterar os mesmos de maneira muito funcional, tornado a manipulao de um documento XML to simples como a manipulao de tabelas no modelo relacional. A questo da integridade referencial em documentos XML muito importante quando o padro XML utilizado para representar dados relacionais, sendo que os padres para definio de esquemas relacionados a XML (DTD, XML Schema e outros) deixam a desejar quando se deseja manter em um documento, regras de integridade as quais dados exportados de bases relacionais estavam submetidos, tais como chaves primrias e estrangeiras.
12
Expresses de caminho (Path Expressions) foram abordados na seo 3.5.1.
65
4.Integrao de Fontes Heterogneas de Dados Utilizando XML

Este captulo aborda algumas tcnicas utilizadas para representar dados relacionais atravs de XML, e uma vez que estes dados relacionais tenham sido exportados para XML, como podemos acess-los, mant-los e organiz-los e integr-los atravs do conceito de vises materializadas. Tambm neste captulo sero estudadas as questes ligadas a utilizao de vises de dados XML para representao e integrao de fontes heterogneas de dados, bem como, algumas propostas j existentes para integrar dados de diversas fontes heterogneas.
4.1. Representando Bases de Dados Relacionais com XML

Uma base de dados relacional representada por seu esquema como por exemplo r1(a,b,c) r2(d,e). Nestas expresses, r1 e r2 so os nomes das relaes (tabelas), a,b,c so colunas da relao r1 e d,e so colunas da relao r2. Tomemos ento, por exemplo um base relacional formada por duas relaes r1 e r2 descritas dentro de uma notao {r1 : i1, r2 : i2} onde i1 e i2 representam os dados presentes nas respectivas relaes que podem ser representados atravs de um conjunto de linhas (tuplas) conforme a Listagem 34.
{r1 : {tupla{a {tupla{a }, {r2 : {tupla{d {tupla{d {tupla{d } : a1, b : b1, c : c1}, : a2, b : b2, c : c2}, : d1, e : e1}, : d2, e : e2}, : d3, e : e3}
Listagem 34 : Representao das relaes r1 e r2 atravs de tuplas.
As relaes r1, r2 podem tambm ser representadas atravs de tabelas como podemos observ-las respectivamente na Tabela 6 e na Tabela 7.
66
r1: a a1 a2 b1 b2 b c1 c2 c
Tabela 6 : Exemplo de relao r1.
r2: d d1 d2 d3 e e1 e2 e3
Tabela 7 : Exemplo de relao r2.
Segundo [Abiteboul et al., 2000], podemos representar estes dados atravs de uma estrutura de rvore das mais variadas formas, dependendo da organizao desejada. As figuras Figura 16, Figura 17 e Figura 18 mostram trs maneiras de representar dados das relaes r1 e r2 atravs de rvores.
r1 r2
tupla
tupla
tupla
tupla
tupla
a a1
b b1
c c1 a2
b b2
c c2
d d1
e e1
d d2
e e2
d d3
e e3
Figura 16 : Representao de dados relacionais em rvore exemplo 01.
r1
r1
r2
r2
r2
a a1
b b1
c c1 a2
b b2
c c2
d d1
e e1
d d2
e e2
d d3
e e3
Figura 17 : Representao de dados relacionais em rvore exemplo 02.
67
tup la
tup la
tup la
tu p la
tu p la
r1 a a1 b b1 c c1 a2 a
r1 b b2 c c2
r2 d d1 e e1
r2 d d2 e e2
r2 d d3 e e3
Figura 18 : Representao de dados relacionais em rvore exemplo 03
Cada uma das rvores representadas na Figura 16, Figura 17 e Figura 18 pode ser representada atravs de um documento XML. A Listagem 35 mostra como podem ser representados os dados das relaes r1 e r2 em um documento XML de acordo com a representao em rvore da Figura 16.
<?xml version=1.0?> <bd> <r1> <tupla> <a> a1 </a> <b> b1 </b> <c> c1 </c> </tupla> <tupla> <a> a2 </a> <b> b2 </b> <c> c2 </c> </tupla> </r1> <r2> <tupla> <d> d1 </d> <e> e1 </e> </tupla> <tupla> <d> d2 </d> <e> e2 </e> </tupla> <tupla> <d> d3 </d> <e> e3 </e> </tupla> </r2> </bd> Listagem 35 : Representao da rvore de dados da Figura 16 com XML.
Desta maneira, podemos representar os dados de uma mesma base relacional em documentos XML com estruturas variadas. Esta estrutura esta ser determinada pela
68
organizao
pela
formatao
exigida
por
quem
(usurio/aplicao/desenvolvedores) ir eventualmente utilizar estes dados.
4.2. Vises XML

Vises materializadas em banco de dados so aquelas para as quais ocorre o armazenamento fsico das informaes, obtidas a partir das fontes de dados originais. Consultas podem ser respondidas, na maior parte dos casos, sem o acesso direto s fontes de informao que originaram a viso. Uma viso materializada se caracteriza pelo armazenamento de suas tuplas no banco de dados, com a construo de estruturas de ndices prprias e a possibilidade de acessos mais rpidos do que aqueles aplicados sobre os dados que originaram a viso [Gupta et al., 1995]. Uma viso materializada se constitui em uma cpia ("cache") de determinados dados, apropriada para consultas que exijam respostas rpidas ou quando se queira evitar, sempre que possvel, o acesso aos dados de origem. Este tipo de viso definida como uma alternativa abordagem virtual (por demanda) [Widom, 1995], possuindo as seguintes caractersticas: informaes das fontes de dados que sejam identificadas como potenciais itens de consulta so extradas, convertidas, filtradas e tratadas em conjunto com outras possveis informaes relevantes, sendo posteriormente armazenadas em um repositrio centralizado de dados; quando uma consulta submetida, esta avaliada diretamente junto ao repositrio criado, sem que seja necessrio um acesso constante junto s fontes de dados existentes. O uso de vises materializadas ou virtuais deve ser considerado de acordo com o tipo de situao na qual se esteja aplicando a integrao de fontes heterogneas. Neste sentido, diversas contribuies tm sido apresentadas em trabalhos desenvolvidos nos ltimos anos [Hull, 1997]. A abordagem virtual tende a apresentar melhores resultados quando as fontes de informaes esto mudando freqentemente, enquanto a materializao, por seu lado, se
69
aplica melhor quando estas fontes no sofrem alteraes com tanta freqncia, alm de ser exigido um tempo de resposta rpido para as consultas submetidas [Hull, 1996]. A abordagem virtual apropriada para informaes que mudam rapidamente, para clientes com necessidades normalmente no previsveis e para consultas que so realizadas sobre grandes quantidades de dados, a partir de um volume significativo de fontes de informaes [Widom, 1995]. No entanto esta abordagem se mostra ineficiente quando consultas so submetidas repetidas vezes, quando as fontes de informao so lentas, caras ou muitas vezes no disponveis, e quando requerido um processamento considervel para as diversas etapas de preparao dos dados, antes de seu uso. Neste caso, o uso de materializao se torna a alternativa de melhores resultados, por permitir que a informao esteja disponvel imediatamente para consultas e anlises desejadas. Em um outro artigo [Hull, 1997], Hull afirma que a materializao de vises integradas pode oferecer benefcios substanciais sobre a abordagem virtual no que se refere ao tempo de resposta para consultas, podendo isto ser observado quando so necessrias junes de grande complexidade envolvendo os dados das mltiplas bases de dados presentes na viso integrada. Alm disso, tambm se aplica adequadamente em casos nos quais no h uma chave universal para entidades referenciadas a partir destes diversos bancos de dados. No entanto, uma preocupao a ser considerada quando se trata deste tipo de abordagem diz respeito atualizao das vises materializadas, sendo necessrio implementar algum tipo de mecanismo que permita garantir a coerncia dos dados manipulados em relao aos dados armazenados nas fontes de dados integradas. Para garantir uma viso materializada consistente, algum mecanismo deve ser adotado para mant-la em relao s fontes dos dados. Uma viso materializada proporciona rpido acesso aos dados armazenados, podendo a diferena de velocidade ser crtica para aplicaes nas quais ocorrem muitas consultas, com vises to complexas que no se torna possvel refaz-las para cada nova consulta realizada [Gupta et al., 1995]. Porm, assim como uma "cache", este tipo de viso necessita de mecanismos que permitam mant-la adequada s mudanas ocorridas
70
com os dados a partir dos quais esta se originou, sendo adotado normalmente um processo denominado atualizao de vises. Outra vantagem apresentada para justificar o uso de vises materializadas descrita por Abiteboul [Abiteboul et al., 1998], quando este afirma que normalmente a prtica de materializao adotada para melhorar o desempenho de consultas, quando os dados de origem esto localizados remotamente, de forma distribuda, ou o tempo de resposta para consultas um fator crtico. Da mesma forma que os demais autores, Abiteboul descreve a importncia de que o contedo de vises desta natureza sejam sempre mantidos de forma consistente em relao s fontes de dados, seja atravs da sua redefinio a partir destas fontes, seja pela computao de mudanas incrementais em seus dados tendo como base as alteraes que ocorrerem com as fontes originais.
4.2.1. Atualizao de vises

Dados materializados, sobre os quais se realize qualquer tipo de consulta, devem ser atualizados periodicamente, buscando garantir sua coerncia em relao s fontes das quais foram extrados. O processo de atualizar uma viso materializada, em resposta mudanas nos dados fontes, chamado de atualizao de vises [Gupta et al., 1995]. Recomputar todo o contedo de uma viso, a partir de mudanas nas fontes de dados, uma alternativa possvel para manter esta viso atualizada. No entanto, em muitas situaes este processo pode se tornar demasiadamente oneroso, at mesmo no justificando a existncia destas vises. Uma alternativa para a soluo deste problema a utilizao de algoritmos para a atualizao incremental de vises, os quais basicamente permitem modificar uma parte da viso em resposta a mudanas nas fontes de dados [Gupta et al., 1995]. Uma poltica de atualizao de vises a deciso de quando a viso atualizada. Uma viso pode ser atualizada dentro de uma transao que modifica as tabelas base ou a atualizao pode ser adiada. O primeiro caso denominado atualizao imediata de vises e o segundo atualizao adiada de vises [Gupta et al., 1995]: Vises imediatas: a viso atualizada imediatamente aps uma modificao na tabela base usada para criar a viso. Esta tcnica permite consultas rpidas, mas aumenta o tempo das transaes de atualizao;
71
Vises adiadas: nesta tcnica, a viso atualizada em uma transao separada, fora da transao que atualiza a tabela base usada para derivar "preguiosa" (lazy
a viso. Diferentes polticas podem ser definidas: (1)
deferred): a viso atualizada to tarde quanto seja possvel, desde que esteja garantindo que todos os resultados das consultas submetidas estejam consistentes com os dados base. Em outras palavras, vises "preguiosas" adiadas no precisam estar consistentes com as tabelas sobre as quais elas foram definidas, mas as consultas sobre as vises tem de ser respondidas como se a viso estivesse consistente; (2) "peridica" (periodic deferred): a viso modificada periodicamente em intervalos preestabelecidos, em uma transao especial de atualizao. Esta tcnica permite consultas rpidas e no aumenta o tempo das atualizaes. A desvantagem que as consultas submetidas viso podem trazer resultados inconsistentes com os dados fonte; (3) forada (forced delay): a viso atualizada depois de um certo nmero de modificaes nas tabelas base usadas para derivar a viso. A atualizao imediata de vises tem a desvantagem de que cada transao de atualizao implica em "overhead" para propagar as mudanas das tabelas base e atualizar cada viso. Este "overhead" cresce com o nmero de vises e esta abordagem no escalonvel em relao a este nmero de vises. A atualizao adiada de vises remove o "overhead" criado pela propagao e "refresh" das transaes de atualizao. Entretanto, impe diferentes "overheads" nestas transaes de atualizao: as mudanas nas tabelas base devem ser registradas em um arquivo de "log", de modo que estejam disponveis mais tarde para a operao de atualizao. Esta abordagem permite que alteraes de vrias transaes de atualizao possam ser realizadas juntas, em uma nica operao de propagao e "refresh". Por outro lado, atualizao "preguiosa" adiada impe um significativo "overhead" em transaes de consulta, j que a consulta tem que esperar para que a viso materializada seja atualizada. Dependendo do tipo de aplicao, a performance da consulta pode ser melhorada usando atraso forado ou atualizao peridica. Quando a aplicao precisa de um armazenamento estvel de dados, a atualizao peridica tem
72
excelente performance, como o caso de datawarehouses que precisam rodar longas consultas de suporte deciso [Silva, 2000].
4.2.2. Dimenses do problema de atualizao de vises

Basicamente, h quatro dimenses ao longo das quais o problema da atualizao de vises pode ser estudado [Gupta et al., 1995]: Dimenso da informao: se refere quantidade de informao disponvel para atualizao (acesso s relaes e viso materializada, conhecimento das restries de integridade, chaves, etc); Dimenso de modificao: diz respeito modificaes que devem ser manipuladas pelo algoritmo de atualizao da viso; Dimenso de linguagem: relacionada com a forma como a viso expressa (consulta, SQL, agregao, etc) Dimenso de instncia: refere-se s instncias da base de dados para as quais o algoritmo ser usado.
4.3. Algumas propostas existentes de integrao utilizando vises materializadas

4.3.1. Sistema ARGOS
A proposta do sistema [Quan et al., 2001] possibilitar a criao de uma viso semi-estruturada para dados Web, sobre as quais possam ser executadas consultas recursivas. Baseado em tcnicas de atualizao da linguagem XQL, o sistema prope um ambiente distribudo com mltiplas fontes Web, registradas no site onde as vises iro residir. A arquitetura resumida do sistema pode ser representada pelo esquema da Figura 19. Nesta arquitetura, as fontes XML so percorridas e armazenadas em estruturas DOMs persistentes. Estas estruturas ficam armazenadas na parte principal do sistema, a viso Web local. Esta viso, por sua vez, pode ser dividida em dois mdulos:
73
gerenciador de consultas: composto pelo parser de consulta, que recebe a consulta XQL e faz um parser em uma rvore de sintaxe abstrata;
processador de consultas, que executa chamadas para a efetivao das consultas.
Gerenciador APIX: dividido em alguns mdulos especficos. O inicializador APIX faz a inicializao da estrutura APIX (Aggregate Path IndeX) para uma determinada consulta e tambm a gerao da viso materializada de acordo com o resultado do processamento. O atualizador APIX, com a ajuda da estrutura APIX, realiza a atualizao das vises a partir de notificaes vindas do detector de atualizaes nas fontes Web. A estratgia de manuteno do sistema ARGOS se baseia em um algoritmo que faz a atualizao incremental da viso Web, a partir de modificaes que ocorram nas fontes de dados. Esta tcnica implica em custos reduzidos se comparados queles envolvidos na criao inicial da viso.
Interface do Usurio
Parser de Consulta Gerenciador de Consultas Processador de Consulta Sistema de Consulta Sites de vises Inicializador APIX Gerenciador APIX APIX PDOM Atuallizador APIX Carregador PDOM
PDOM Detector de Atualizaes
PDOM
PDOM Sites de origem
XML
XML
XML
Figura 19 : Arquitetura geral do Sistema ARGOS
74
4.3.2. MIX (Metadata based Integration model for data X-change)

A proposta do modelo de dados MIX [Zhu et al., 2000] oferecer uma estrutura que possibilite a criao de datawarehouses para dados extrados da Web. O sistema prope um mapeamento objeto-relacional que leve em considerao as peculiaridades de datawarehouses, atravs de uma linguagem que descreva as transformaes necessrias para este mapeamento. O modelo MIX foi proposto visando atender a trs desafios existentes quando da materializao de dados Web [Zhu et al., 2000]: extrao de dados: dificultada pela dinamicidade e autonomia dos dados Web, os quais so gerados por diferentes fontes, sem um controle pr-determinado; preparao e integrao de dados: informaes semelhantes ou relacionadas, presentes na Web, podem ter diferentes representaes de acordo com a forma como foram criadas; apresentao e materializao: o paradigma Web totalmente diferente do paradigma de datawarehouses. A idia principal da abordagem do modelo MIX representar os dados
associados com uma descrio de seu contexto original, utilizando ontologias para interpretar corretamente estes dados e tambm os metadados. A arquitetura proposta, aplicando o modelo MIX, se baseia na abordagem de mediadores e est apresentada na Figura 20. Nesta arquitetura, os wrappers so usados para extrair dados relevantes a partir das fontes, mape-los para MIX baseados em um contexto estrutural comum e retornar objetos MIX para o gerenciador de dados. O gerenciador de dados gerencia as fontes disponveis, atravs da atualizao do repositrio de metadados. Baseado na descrio do contexto das fontes de dados, este gerenciador tenta integrar dados heterogneos atravs da converso destes dados para um modelo semntico comum.
75
O servidor de ontologias armazena e gerencia o vocabulrio de um domnio especfico, possibilitando uma maneira de descrever conceitos da ontologia de forma independente de qualquer aplicao ou fonte de dados. Dados integrados so repassados para o processador de transformaes, o qual mapeia objetos MIX para o esquema do datawarehouse e carrega dados nas tabelas. Este processador se utiliza de regras de mapeamento, definidas no arquivo de mapeamentos (o sistema prope uma linguagem especfica para a definio destas regras). Por fim, o processador de atualizao incremental modifica o datawarehouse, quando as fontes Web sofrem alteraes. Este processador mantm uma cpia dos ltimos objetos MIX utilizados, fazendo comparaes com novos objetos MIX que sejam recebidos do gerenciador de dados.
Biblioteca de Funes de Mapeamento
DataWarehouse
Arquivos de Mapeamento
Processador de Transformaes
Servidor de Ontologia
Processador de Atualizao Incremental
Ontologias
Gerenciador de dados
Metadados
Wrapper 1
Wrapper 2
Wrapper 3
DB
Data File
XML File Internet
Figura 20 : Arquitetura MIX.
Um exemplo de um objeto MIX est descrito a seguir Listagem 36 : Exemplo de objeto MIX.
Obj = <Artigo, { <ttulo, XML>, <Autor, { <nome, Ferrandin, Mauri, {<formato nome, Last, First>}>,
76
<endereo, { <Instituio, UFSC> }> }> Listagem 36 : Exemplo de objeto MIX.
4.3.3. SilkRoute
A ferramenta SilkRoute [Fernandez et al., 1999] procura oferecer uma alternativa geral, dinmica e eficiente para a criao de vises e consultas sobre dados relacionais atravs de XML. Este processo realizado atravs de duas etapas principais: primeiro, definida uma viso XML para o banco de dados relacional, atravs do uso de uma linguagem de consulta especfica, denominada RXL (Relational to XML Transformation Language). Esta viso virtual e no materializada; segundo passo a formulao de consultas sobre estas vises virtuais, extraindo dados XML. Estas consultas so realizadas com uma linguagem de consulta prpria para dados XML, chamada XML-QL e apenas seu resultado enviado como resposta para a aplicao. A arquitetura geral da ferramenta SilkRoute ilustrada pela Figura 21.
Aplicao Consulta (XML-QL) Resposta (XML)
RXL
Preparador de Consultas Consulta Executvel RXL
Gerador XML
SilkRoute
Descrio da fonte de dados
Tradutor
Template XML
Tuplas
SQL
SGBDR
Figura 21 : Arquitetura geral do Sistema SilkRoute
77
A idia principal desta arquitetura servir como um middleware entre uma base de dados relacional e uma aplicao que acesse esta base atravs da Web. O mdulo principal da ferramenta o PREPARADOR DE CONSULTAS. A partir de uma viso virtual definida pelo administrador do banco de dados, este mdulo recebe a consulta do usurio (XML-QL) e gera uma nova consulta RXL (executvel) que ento enviada para o mdulo TRADUTOR. O mdulo TRADUTOR, por sua vez, particiona esta consulta executvel em uma ou mais consultas SQL, alm de gerar dados XML (template) enviados ao GERADOR XML. O TRADUTOR ainda recebe como entrada uma descrio da fonte de dados, no formato XML, para auxiliar no processo de consulta de dados no banco relacional. O mdulo GERADOR XML recebe o resultado de consultas SQL e o template XML, preparando o documento XML a ser enviado como resposta para a aplicao que formulou a consulta inicial. A linguagem RXL, que serve de base para a gerao das vises nesta abordagem, combina a parte de recuperao de dados do SQL (clusulas FROM and WHERE) com clusulas de construo da linguagem XML-QL, gerando instrues de consulta como a apresentada na Listagem 37.
from ARTIGO $A where $A.ttulo = XML construct <artigo> <ttulo> $A.ttulo </ttulo> </artigo> Listagem 37 : Instrues de consulta RXL.
4.3.4. Resumo comparativo entre as principais abordagens

A tabela a seguir ilustra as principais caractersticas de cada uma das abordagens descritas segundo [Silva, 2000].
Abordagem VISO MATERIALIZADA Sim Sim No OBJETIVO ATUALIZAO LINGUAGEM DE CONSULTA Incremental Incremental (No se aplica) XQL Qualquer (extrao de dados) XML-QL
ARGOS MIX SILKROUTE
Sistema de caching para Web Materializar dados Web para OLAP e DSS (datawarehouse) Middleware entre banco de dados relacional e aplicao acessando dados via Web
78 Tabela 8 : Comparativo entre abordagens de vises sobre dados semi-estruturados

O padro XML uma poderosa ferramenta para integrao de dados, sendo que pode ser utilizado tambm para representar exportados de bases relacionais, uma vez que dados relacionais podem ser representados atravs de uma estrutura de rvore, que os mesmos dados extrados de um modelo tradicional podem ser estruturados de maneiras diferentes de acordo com a utilizao que ser dada aos mesmos. Outra questo chave para integrao de dados atravs do padro XML a utilizao de vises XML, que servem para representar um conjunto de dados exportados ou extrados de uma ou mais fontes de dados. Estas vises podem ser materializadas quando ocorre armazenamento fsico dos dados exportados - ou virtuais quando no ocorre armazenamento fsico e sim apenas lgico dos dados exportados. Existem diversos fatores que devem ser levados em conta no momento de definir que tipo de viso utilizar, como por exemplo, volume de dados, tipo de acesso (consulta/atualizao), quantidade de acessos que cada viso ir receber, entre outros. Os modelos apresentados (ARGOS, MIX e SilkRoute) so capazes de integrar informaes das mais variadas fontes, mas nenhum trata de questes especficas presentes em dados exportados de bases relacionais, tais como a integridade referencial e a utilizao do XML como um padro nico dentro do modelo, tanto para exportar os dados como regras de integridade e dicionrio de dados.
79
5.Modelo para Integrao de Fontes Heterogneas de Dados

Este captulo trata da proposta de um sistema para integrar dados de bases relacionais heterogneas e distribudas, apresentando uma proposta global que envolve todas os processos necessrios para implementao de uma arquitetura mediadora para possibilitar tal integrao. Muitas questes precisam ser levadas em conta quando se prope integrao de dados de fontes relacionais heterogneas, sendo que est proposta esta focada na integrao dos dados de diversas bases relacionais atravs da criao de vises XML, permitindo que estes dados integrados possam ser consultados de maneira integrada e transparente para as aplicaes e especificando um mecanismo para manuteno da integridade referencial a qual os dados estavam submetidos nas bases antes de serem exportados, a fim de garantir a serializao entre a viso integrada e as bases, sem violaes de integridade.
5.1. Viso geral do sistema proposto

O sistema proposto consistir de um conjunto de mdulos de software que tero por objetivo viabilizar a integrao de diversas fontes de dados relacionais heterogneas e distribudas utilizando o padro XML para o intercmbio dos dados entre as mesmas com o propsito de prover estes dados de maneira transparente para aplicaes e desenvolvedores. Para que tal integrao seja possvel, ser especificada uma arquitetura baseada em mediadores conforme demonstra a Figura 22. Um conjunto de wrappers especficos para cada fonte de dados faro a exportao dos dados relacionais para o padro XML, criando uma viso XML local para cada fonte a ser integrada. Estas vises sero depois integradas compondo uma viso XML global, possibilitando assim que os dados armazenados nas diversas bases heterogneas possam ser manipulados em um nica viso atravs de uma linguagem para consulta a dados XML.
80
A Figura 22 demonstra a arquitetura geral do sistema proposto, sendo que cada mdulo do sistema ser detalhado na seo 5.2.2.
Aplicao
Aplicao
...
Aplicao
XML-QL
XML-QL Gerenciador de Consultas
XML-QL
Regras de Localizao
Viso XML Integrada
Regras de Integridade
XML
Integrador de Vises Locais
XML
XML
XML
XML
Viso XML Local
Viso XML Local
... ... ...
Viso XML Local
XML Wrapper
XML Wrapper
XML
...
Wrapper
SQL
SGBD
SQL
SGBD
SQL
SGBD
Figura 22 : Modelo proposto para integrar fontes heterogneas de dados.
Outro ponto importante desta proposta a manuteno das regras de integridade na viso XML global de modo que as alteraes nela realizadas, possam ser propagadas para as bases relacionais sem que ocorram problemas de integridade referencial. Para gerenciamento das regras de integridade que determinaro a integridade da viso XML global ser criado um repositrio de regras de integridade que armazenar as mesmas tambm atravs do padro XML. Para definio das regras, ser necessrio a
81
interveno de um especialista humano que definir a partir dos dados que sero exportados, que integridade dever ser preservada na viso XML global. O especialista dever levar em conta a manuteno de uma integridade mnima para que no ocorram problemas de integridade em casos de sincronizao de dados entre a viso XML integrada e os SGBDHs.
5.2. Desenvolvimento do prottipo

Para o desenvolvimento do prottipo ser utilizada a metodologia de desenvolvimento em cascata que composta pelas etapas de estudo de viabilidade, definio dos requisitos, projeto, implementao, integrao e testes, quarta etapas. implantao e manuteno, sendo que nesta dissertao sero cumpridas apenas a segunda, terceira e
5.2.1. Definio dos Requisitos

Requisitos principais do sistema : Integrar fontes heterogneas de dados armazenados em bases relacionais atravs do padro XML de maneira que os dados possam ser acessados de maneira transparente para o usurio. Prover um mecanismo de manuteno de integridade dos dados integrados, de maneira que os mesmos possam ser sincronizados novamente para as bases relacionais sem causar violaes de integridade.
5.2.2. Projeto
O sistema proposto composto por vrios mdulos independentes que interagem entre si que sero detalhados nas subsees seguintes, so eles: os wrappers; integrador de vises XML locais; gerenciador de consultas; repositrio de regras de integridade;
82
repositrio regras de localizao dos dados.
5.2.2.1.
Wrappers
Um wrapper ou tradutor, um componente de software que converte dados e consultas (query) de um modelo para outro [Papakonstantinou et al., 1995]. Neste caso, uma aplicao (que pode ser um mediador), solicita ao wrapper consultas em uma linguagem de consulta comum (SQL, XML-QL), e o mesmo converte esta consulta para uma linguagem de consulta suportada pelo banco de dados ao qual est ligado e envia uma requisio ao mesmo, depois, recebe o resultado desta consulta e o converte para um formato suportado pela aplicao ou mediador. No caso especfico deste sistema, os wrappers faro acesso as informaes armazenadas nas bases relacionais heterogneas distribudas atravs da SQL e convertero os resultados para o padro XML. Vejamos um exemplo bsico do funcionamento dos wrappers : Dadas as relaes Paciente e Internao, representadas respectivamente na Tabela 9 e Tabela 10, presentes em uma base de dados base01: Paciente : CPF 01 02 Nome Joo Z
Tabela 9 : Exemplo de tabela de pacientes base01.
Internao : CPF 01 01 02
Doena Gripe Diarria Sfilis
Tabela 10 : Exemplo de tabela de internao base01.
Como resultado teramos a viso XML representada pela Listagem 38 para a base de dados base01:
<base01> <tabelas> <pacientes> <linha> <CPF>1</CPF> <Nome>Joo</Nome> </linha>
83
<linha> <CPF>2</CPF> <Nome>Z</Nome> </linha> </paciente> <Internao> <linha> <CPF>1</CPF> <Doena>Gripe</Doena> </linha> <linha> <CPF>1</CPF> <Doena>Diarria</Doena> </linha> <linha> <CPF>2</CPF> <Doena>Sfilis</Doena> </linha> </Internao> </tabelas> </base01> Listagem 38: Viso XML gerada por wrapper a partir de uma base relaciona base01.
A implementao dos wrappers no o foco principal deste trabalho, sendo que para desempenhar as funes deste mdulo ser utilizada uma implementao j existente chamada DB2XML que um projeto de Volker Turau Copyright (C) 1999 distribudo sob a GNU (General Public License) de acordo com as normas da Free Software Foundation. O DB2XML foi implementado em Java e utiliza o JDBC (Java Database Connectivity) para fazer acesso a bases relacionais, assim, no existe a necessidade de implementao de um wrapper para cada tipo diferente de SGBD, uma vez que basta carregar o driver JDBC especfico para cada SGBD pois est API dividida em duas sub APIs que so a API da linguagem e a API do fabricante do SGBD. A Figura 23 detalha as partes da API JDBC e a Figura 24 mostra como o DB2XML ser utilizado dentro do modelo proposto. A maioria dos fabricantes de SGBD possuem API JDBC para seus produtos, sendo que a lista de todos os SGBDs que j possuem suporte pode ser encontrada no site http://industry.java.sun.com/products/jdbc/drivers mantido pela Sun Microsystems.
84
Aplicao Java
API JDBC
API JDBC da Lingugem Java API JDBC Oracle SQL API JDBC PostgreSQL SQL Postgre SQL API JDBC DB2 SQL API JDBC MySQL SQL
...
Oracle
DB2
...
MySQL
Figura 23 : API JDBC.
Viso XML Local
Viso XML Local
... ... ...
Viso XML Local
XML Wrapper DB2XML JDBC
XML Wrapper DB2XML JDBC
XML
...
Wrapper DB2XML JDBC
SQL
SGBD
SQL
SGBD
SQL
SGBD
Figura 24 : Modelo proposto utilizando o wrapper DB2XML
5.2.2.2.
Integrador de vises XML
Este mdulo ir receber os dados de cada uma das vises XML locais exportadas atravs dos wrappers e os integrar em uma nica viso XML global. Tal integrao ser feita de maneira simplificada criando um elemento raiz dentro do qual estaro contidas as vises locais. muito importante a presena de um especialista humano no momento de incluso/excluso de SGBDs componentes do sistema para resoluo de conflitos e problemas de integridade que eventualmente possam surgir. A Figura 25 mostra como ficaro organizados os dados de cada viso XML local de maneira a compor uma viso XML integrada. Na raiz do documento XML que
85
corresponde a viso integrada foi chamado de <visao_xml_integrada>, e cada uma das bases a serem representadas viso integrada identificada por um elemento raiz <basexx> que ser adicionado ao documento como sendo elemento filho do elemento raiz.
<base01> <tabelas> <pacientes> ... </paciente> ... </tabelas> </base01> <base02> <tabelas> <pacientes> ... </paciente> ... </tabelas> </base02> ... <basen> <tabelas> <pacientes> ... </paciente> ... </tabelas> </basen> <visao_xml_integrada> <base01> <tabelas> <pacientes> ... </paciente> ... </tabelas> </base01> <base02> <tabelas> <pacientes> ... </paciente> ... </tabelas> </base02> ... <basen> <tabelas> <pacientes> ... </paciente> ... </tabelas> </basen> </visao_xml_integrada>
BD1
BD2
BDn
Figura 25 : Integrao das vises XML locais em uma viso XML integrada
5.2.2.3.
Repositrio de regras de integridade
As regras de integridade da viso XML global so definidas a partir das regras de integridade de cada base relacional exportada. Para o armazenamento destas regras tambm ser utilizado uma notao baseada em XML o que padroniza a troca e consulta de informaes entre os mdulos do sistema, uma vez que assim, as regras de integridade ficam acessveis a qualquer linguagem de consulta para dados XML.
86
A Listagem 39 mostra o exemplo de um arquivo de regras de integridade para um documento XML conforme o proposto neste trabalho.
<?xml version="1.0" encoding="UTF-8"?> <RegrasIntegridade> <visao_xml_integrada.basededados01.paciente.paciente_rectipo="pk"> <campo>cpf</campo> </visao_xml_integrada.basededados01.paciente.paciente_rec> . . . </RegrasIntegridade> Listagem 39 : Exemplo de um arquivo de regras de integridade para um documento XML.
Uma regra composta basicamente por uma tag que indica o contexto(path) do documento onde a regra deve ser observada, sendo que o tipo da regra indicado por um atributo denominado tipo que pode ser : pk : para indicar que a regra uma regra de chave primria (primary key); fk : para indicar que a regra uma regra de chave estrangeira (foreign key).
A tag que discrimina uma regra ter ento uma ou mais tags filhas denominadas campos que iro armazenar quais as tags que no devem possuir o mesmo valor dentro daquele contexto. Basicamente a regra acima descrita uma regra do de chave primria (tipo=pk) e indica que no nvel do documento XML indicado pelo caminho visao_xml_integrada.basededados01.paciente.paciente_rec no podero existir duas tags filhas da tag paciente_rec contendo o mesmo valor. A Figura 26 representa graficamente uma violao de chave primria em um documento XML e a Listagem 40, mostra um exemplo de regra de chave estrangeira para um documento XML. Uma regra de chave estrangeira (tipo = fk) na prtica, indica que um valor s poder existir em um local do documento (contexto) se j existir um determinado valor em outro local (contexto) do documento. Assim as regras de chave estrangeira so compostas por uma tag cujo o nome da mesma determina o contexto onde ela ser validada, no caso do exemplo acima, o com caminho um visao_xml_integrada.basededados01.internacao.internacao_rec atributo
denominado contexto (visao_xml_integrada.basededados01.paciente.paciente_rec no caso) que indica onde se encontram os dados de referncia. Na prtica, de acordo com
87
esta regra, somente ser possvel inserir uma tag com nome cpf (<campo>) no contexto visao_xml_integrada.basededados01.internacao.internacao_rec da viso se existir uma tag chamada cpf (<campofk>) no contexto visao_xml_integrada.basededados01.paciente.paciente_rec.
<visao_ xm l_inte gra da> <bas ededa dos01 > <p aciente > <pacien te_re c> <cpf> 01 </cpf> <nom e> Jo o </no m e> </paciente_re c> </p aciente > ... </bas e01> ... </visao_x m l_inte gra da>
<pacien te_rec> <cpf> 01 </cp f> <no m e> P aulo </nom e > </pacien te_rec>
Violao de chave primria
<RegrasIn tegridade > <v is ao_xm l_integ rad a.based edad os01.p aciente .pacien te_re c tipo="p k"> <ca m po>cpf</ca m po> </vis ao_xm l_integ rad a.based edad os01.p aciente .pacien te_re c> ... </RegrasIn tegridade >
Figura 26 : Violao de chave primria na viso integrada XML. <visao_xml_integrada.basededados01.internacao.internacao_rec tipo="fk" contexto="visao_xml_integrada.basededados01.paciente.paciente_rec"> <campo>cpf</campo> <campofk>cpf</campofk> </visao_xml_integrada.basededados01.internacao.internacao_rec> Listagem 40 : Exemplo de regra de chave estrangeira para um documento XML.
A Figura 27 ilustra a insero de um valor na viso integrada considerando regras de chave estrangeira.
88
<visao_xm l_ integrad a> <base dedados01> <pac iente> <pacie nte_r ec> <cpf> 01 </cpf> <nome > Jo o </nom e> </paciente_re c> </paciente> <inte rnacao> </in ter nacao> ... </base01> ... </visa o_xml_inte grada> <ca mpofk>
<in ter nacao_r ec> <cpf> 0 1 </cpf> <doenca > G r ipe </doenca> </internaca o_rec>
Operao permitida
<visa o_xm l_inte grada.basede dados01.in ter nacao.interna cao_rec tipo="fk " c ontexto="v isao _xml_inte grada.baseded ados01.paciente .paciente_re c"> <c ampo>cpf</cam po> <c ampofk>cpf</cam pofk> </visao_x ml_integr ada.basededados 01.internaca o.inte rnacao_ rec>
Figura 27 : Insero de um registro na viso integrada de acordo com as regras de chave estrangeira.
5.2.2.4.
Repositrio regras de localizao dos dados.
O repositrio de regras de localizao armazenar metadados referentes a origem dos dados presentes na viso XML integrada dos mesmos, tal como, qual a base de dados da qual tal campo foi exportado, tabela, etc. A Listagem 41 mostra um exemplo de regras de localizao.
<localizacao> <base nome=base01> <SGBD>Oracle</SGBD> <IP>10.0.0.1</IP> <porta>1521</porta> <campos> <campo> <nome>CPF</nome> <tabela>Paciente</tabela> </campo> <campo> <nome>Nome</nome> <tabela>Paciente</tabela> </campo> ... </campos> </base> </localizacao> Listagem 41 : Exemplo de repositrio de dados de localizao.
89
O repositrio de regras de localizao serve para facilitar uma possvel propagao de alteraes nos dados presentes na viso XML integrada para as bases distribudas. Este processo bastante complexo e no ser foco de estudo deste trabalho, assim, este repositrio de dados somente ser usado se o gerenciador de consultas eventualmente por algum motivo precisar conhecer a origem dos dados, origem esta que deve ser escondida do usurio/desenvolvedor para manter a transparncia do sistema.
5.2.2.5.
Gerenciador de consultas
O mdulo gerenciador de consultas tem como funcionalidade principal, receber as consultas formuladas pelas aplicaes j em XML-QL e executar as mesmas sobre a viso XML global para recuperar os dados solicitados, ou sobre o repositrio de regras de integridade se houver alguma atualizao ou em algum caso em que o prprio gerenciador ou a aplicao necessitem de dados referentes a integridade da viso, ou ainda sobre o repositrio de dados de localizao original dos dados nas bases relacionais exportadas. A Figura 28 detalha o funcionamento do gerenciador de consultas, sendo que podemos definir como seqncia de eventos que podem ocorrer com o gerenciador de consultas atravs do algoritmo mostrado na Listagem 42.
Ap lica o D oc um e nto XM L
func tion query () { CONS TR UC T <resultado> { W H ER E <visao_xm l_integrada.basededados0 1.internacao> <internacao_rec>$d</> </> IN "V isaoIntegrada.x ml" C ON STR UC T<rec> $d </> } </resultado> }
<re sultado> <rec> <cpf> 01 </cpf> <nome> Joo </nome> </rec> ... </resultado>
XM L -Q L G e re nc iad or de C o ns ulta s Re g ra s d e Lo c aliza o Vis o X M L In te g ra da Reg ra s de In teg rid ad e
Figura 28 : Funcionamento do gerenciador de consultas.
90
Para a execuo das consultas XML-QL sobre a viso integrada XML foi utilizado a implementao de um prottipo de processador de consultas para esta linguagem desenvolvido pela AT&T Corporation sendo que o mesmo est disponvel em http://www.research.att.com/sw/tools/xmlql/.
... consulta = rede.recebe_requisio_da_aplicao(); Se consulta.tipo != alterao_de_dados ento rede.retorna_aplicao( gerenciador_consultas.executa_consulta(consulta) ); seno se gerenciador_consultas.verifica_integridade( consulta) = OK ento rede.retorna_aplicao( gerenciador_consultas.executa_consulta(consulta) ); seno rede.retorna_aplicao( gerenciador_consultas.codigo_erro() ); fim se; fim se;
...
Listagem 42 : Algoritmo bsico representando o funcionamento do gerenciador de consultas.
5.2.3. Especificaes atravs de UML

A UML (Unified Modelating Language) uma linguagem para modelagem orientada a objetos. A mesma composta de vrios tipos de diagramas utilizados na modelagem, sendo que para especificao deste prottipo a relevncia maior est no : diagrama de classes : descreve os tipos de objetos no sistema e os vrios tipos de relacionamento esttico que existem entre eles; diagrama de casos de uso : descreve um conjunto de cenrios amarrados por um objetivo comum de um usurio, sendo que um cenrio uma seqncia de passos que descrevem uma interao entre o usurio e o sistema.
5.2.3.1.
Diagrama de classes
O diagrama de classes que sero implementadas para desenvolvimento do sistema demonstrado atravs da Figura 29, sendo que o mesmo especifica apenas as classes fundamentais para o funcionamento do prottipo.
91
DB2XMLMauri +DB2XMLMauri() : DB2XMLMauri +roda() : <unspecified>
Wrapper -db : DB2XMLMauri +Wrapper() : Wrapper +retornaVisaoLocal() : <unspecified>
IntegradorDeVisoesLocais -VisoesLocaisXML : array of Document -VisaoIntegradaXML : Document +IntegradorDeVisoesLocais() : IntegradorDeVisoesLocais +retornaVisaoIntegradaXML() : <unspecified> +integraVisoesLocaisXML() : <unspecified>
GerenciadorDeLocalizacao -RegrasLocalizacao : Document
GerenciadorDeConsulta -VisaoIntegradaXML : Document +ExecutaXMLQL()
GerenciadorDeIntegridade -RegrasDeLocalizacao : Document
Figura 29 : Diagrama de classes do prottipo proposto.
5.2.3.2.
Diagrama de casos de uso
A Figura 30 mostra o diagrama de casos de uso do prottipo proposto por este trabalho.
Aplicao * -End5 * -End1 * -End2 * -End6 * -End8 *
Regras de Integridade * -End7
Executar uma consulta sobre a Viso Integra da
-End10 -End9
Gerenciador de Consultas
uses
Regras de Localizao
-1 *
-1 Integrar as Vises XML Locais * uses
IntegradordorDeVisoesLocais
-1 *
-1 * Criar Viso XML Local
-1 *
-1 *
Wrapper
SGBD
Figura 30 : Diagrama de casos de uso do prottipo proposto.
92
5.2.4. Implementao
Para a implementao do sistema proposto sero utilizado basicamente as seguintes ferramentas: Bases de dados de diferentes fabricantes - Oracle, PostgreSQL; Linguagem de programao Java; Nebeans IDE para linguagem Java; JDBC para acesso as bases relacionais com Java; B2XML - uma implementao de um wrapper para bancos de dados que possibilitam acesso via JDBC; XML-QL - uma implementao de um mdulo para execuo de consultas sobre dados XML.
5.2.4.1.
Implementao das classes do sistema
As classes bsicas do sistema foram implementadas de acordo com a especificao UML mostrada na Figura 29, sendo que todas as classes foram implementadas utilizando a linguagem de programao Java. Para uma melhor demonstrao da implementao realizada, foi necessrio a criao de uma interface grfica simples que pudesse concentrar as operaes principais do prottipo em uma nica tela, de maneira a facilitar a utilizao do mesmo, bem como a compreenso do sistema proposto como um todo.
5.2.5. Exemplo de utilizao do prottipo

Nesta subseo ser demonstrado atravs de figuras a utilizao do prottipo na realizao de algumas operaes bsicas. A Figura 31 mostra a interface inicial do prottipo, composta basicamente de um conjunto de botes que sero utilizados para disparar diversos eventos especficos, tais como :
93
materializar as vises : dispara o processo de extrao dos dados relacionais das bases para XML atravs dos wrappers, e na seqncia o
processo de integrao das vises criando assim a viso XML integrada dos dados relacionais;
Figura 31 : Tela inicial do prottipo.
mostrar viso integrada : mostra a viso integrada dos dados atravs de uma representao grfica (Figura 32);
mostrar regras de integridade : mostra as regras de integridade definidas em um arquivo XML previamente por um expert humano;
94
inserir dados : abre uma interface para insero de dados na viso XML integrada (Figura 35);
executar XML-QL : executa a consulta XML-QL definida no campo acima dele localizado sobre a viso XML integrada.
A Figura 32 mostra a visualizao dos dados XML armazenados na viso integrada, demonstrados atravs de uma interface grfica que mostra a rvore de elementos e a descrio textual dos mesmos.
Figura 32 : Visualizando a viso XML integrada dos dados.
A Figura 33 mostra a ocorrncia de uma violao de chave primria no sistema, quando o usurio tentou inserir um registro de paciente em uma das bases representadas na viso com cpf = 1 e nome = Marcos, sendo que j existe um registro com cpf = 1 na viso indicando outro paciente. A Figura 34 ilustra a ocorrncia de uma violao de chave estrangeira quando o usurio tenta inserir na viso um registro de internao para o cpf = 33 com a doena =
95
gripe sendo que no existe no cadastro de pacientes que chave estrangeira para o cadastro de internaes, nenhum registro de paciente com cpf = 33.
Figura 33 : Exemplo de violao de chave primria.
Figura 34 : Exemplo de violao de chave estrangeira.
96
A Figura 35 ilustra a insero de um registro de um paciente com cpf = 55 e nome = Mauri Ferrandin na viso XML integrada dos dados. A Figura 36 mostra a execuo de uma consulta XML-QL que recupera todos os registros de pacientes de todas as bases que esto integradas na viso XML integrada dos dados.
Figura 35 : Exemplo de insero de um registro na viso XML integrada.
Figura 36 : Consulta recuperando todos os registros de pacientes em todas as bases.
97

Neste captulo foi documentado a proposta de um sistema para integrar dados de fontes heterogneas distribudas. importante ressaltar que a especificao e implementao de um modelo completo uma tarefa que demanda muito tempo e trabalho, assim, na implementao do prottipo foi dada uma maior nfase para as questes chaves em um modelo de implantao, tais como, definio de padres de formatao dos dados e esquemas para exportao, a disponibilidade de uma meio eficiente de prover o acesso das aplicaes aos dados integrados e as questes de integridade em casos de atualizao dos dados presentes na viso integrada. Muitos problemas tiveram que ser contornados, como por exemplo, na proposta inicial do modelo, as atualizaes na viso materializada seriam feitas atravs da prpria linguagem de consulta para dados XML, mas com a adoo da XML-QL surgiu o problema da mesma no suportar updates, assim, foi necessrio a criao de um mecanismo para alterar a viso XML integrada dos dados utilizando a API DOM, o que limita a performance do prottipo quando a integrao envolver grande volume de dados, uma vez que para sua manipulao toda a viso ter que ser carregada para a memria.
98
6.Anlise e Interpretao dos Resultados

Como anlise final do sistema proposto, possvel afirmar que o prottipo atendeu aos principais requisitos para os quais ele foi projetado, tais como : prover uma maneira eficiente e transparente para os usurios acessarem a dados armazenados em bancos de dados heterogneos distribudos; especificar um mecanismo de manuteno de restries de integridade na viso XML integrada dos dados evitando assim a ocorrncia de problemas de integridade se os dados nela presentes fossem serializados de volta para as bases. Ao longo do da fase de desenvolvimento do prottipo foram necessrios vrios testes com diversas implementaes de prottipos de wrappers, linguagens para consultas da dados XML, analisadores (parsers) entre outros, e o que se pode perceber que em muitos casos falta padronizao no que diz respeito ao projeto e desenvolvimento de sistemas, bem como, a ausncia de um modelo bsico mnimo a ser seguido para a criao de um modelo para integrao de dados. Na seqncia sero expostas as principais vantagens e desvantagens do modelo proposto.
6.1. Vantagens do sistema proposto

O sistema prov uma maneira nica de armazenamento e tratamento de informaes exportadas das bases relacionais atravs de XML, assim, todas as informaes referentes a dados ou questes de integrao podero ser acessadas de maneira padronizada; A manuteno das regras de integridade em vises XML exportados de bases relacionais no impe grandes dificuldade para especificao pelo fato de que os dados armazenados nas bases relacionais j possuem uma estrutura regular com regras de integridade bem definidas;
99
Para operaes que envolvam apenas consultas (sem atualizaes na viso XML) a complexidade do sistema se torna muito reduzida. O prottipo est implementado em linguagem multiplatafoma, o que aumenta a flexibilidade dos sistema no somente no sentido de se utilizar somente padres independentes de plataforma ou fornecedor para intercmbio de dados como o caso do XML, mas tambm para criao modelos capazes de rodar nos mais variados ambientes.
6.2. Desvantagens do sistema proposto

Necessidade da presena de um expert humano para configurar e dar o startup inicial no sistema e atualiz-lo cada vez que as fontes de dados forem alteradas. Complexidade para implementao do sistema levando em conta situaes em que ocorram atualizaes nos dados da viso XML global tendo assim que propagar estas atualizaes para as fontes de dados relacionais. O sistema tem uma performance muito baixa quando utilizado para integrar bases de dados com grande volume de dados, uma vez que o mesmo utiliza como a API DOM como core, assim, a viso integrada precisa ser armazenada por completa na memria para se efetuar qualquer transao, seja ela um simples consulta, ou uma alterao. Uma grande deficincia dos sistema proposto est em no possibilitar as atualizaes na viso XML integrada atravs de uma linguagem para consulta a dados XML, uma vez que a linguagem escolhida para suportar as consultas das aplicaes sobre a viso foi a XML-QL que de acordo com a Tabela 5 : Comparativo entre linguagens de consulta para XML, no suporta atualizaes. Assim, toda a vez que for necessrio uma aplicao atualizar dados na viso ela ter que faz-lo atravs de uma API para manipulao de dados XML tal como o SAX ou o DOM.
100
7.Concluses e Perspectivas Futuras

7.1. Resumo
Com o advento da Internet existe uma necessidade crescente de que aplicaes faam acesso a bases heterogneas distribudas. Essas bases heterogneas no foram planejadas ou projetadas para suportarem tal integrao, assim, diversas barreiras surgem ao se tentar integr-las, tais como problemas da heterogeneidade semntica e diferenas entre representao de esquemas, sem levar em conta os problemas decorrentes da prpria natureza do SGBD, tais como, fabricantes diferentes, arquiteturas e sistemas operacionais, entre outros. Alm de todos estes agravantes, podemos ainda considerar que estes dados integrados sero tambm atualizados pelas aplicaes e teremos ento um cenrio ainda mais complexo, onde ter que ser levada em conta a propagao destas consultas (atualizaes) e tambm a maneira pela qual sero mantidas as restries integridade mnimas na camada mediadora para que a propagao de um consulta no venha a causar problemas de integridade nas bases distribudas. Esta dissertao discutiu a utilizao do padro XML para integrao de fontes de dados heterogneas mais especificamente bancos de dados relacionais heterogneos distribudos, propondo um sistema capaz de integrar dados distribudos e disponibilizlos de maneira transparente aos usurios e/ou aplicaes. O escopo deste trabalho envolveu diversas atividades, tais como levantamento bibliogrfico sobre o assunto e as diversas linhas de pesquisa correlacionadas, estudo sobre o funcionamento e arquitetura dos sistemas de bancos de dados distribudos, estudo do padro XML e seus subpadres, estudo sobre arquiteturas e tcnicas para integrao de dados relacionais, estudo da problemtica da especificao, manuteno e validao de regras de integridade em dados armazenados atravs de XML e, por ltimo, proposta de um sistema para integrar os dados de bases distribudas atravs de vises, capaz de manter a integridade referencial na viso integrada dos dados em casos de alteraes destes (dados) na mesma (viso), de maneira que os dados nela presentes
101
respeitem as restries de integridade existentes no banco de dados do qual eles so originrios. Os objetivos propostos com este trabalho foram de maneira geral alcanados, o sistema proposto mostrou-se capaz de integrar fontes heterogneas de dados atravs de uma camada de mediao criada entre os dados distribudos e as aplicaes finais, bem como, a proposta de manuteno da integridade referencial dos dados na camada mediadora especificou um esquema que pode ser adotado no somente para questes de integridade na integrao de fontes heterogneas de dados, mas tambm para definio de regras de integridade em documentos XML. O padro XML cai como uma luva para solucionar estes problemas, uma vez que o mesmo independente de plataforma, um padro aberto, e atravs dele podemos representar qualquer tipo de dado, desde os que se encontram em bases relacionais e/ou objetos, e tambm dados semi-estruturados. Muitas ferramentas e APIs para manipulao de dados armazenados atravs de XML j foram implementadas, facilitando e tornando o padro XML uma poderosa ferramenta de integrao, tais como as APIs SAX e DOM, e as diversas linguagens para consulta da dados XML.
7.2. Comparao com as solues existentes

Em relao aos outros modelos propostos para integrao de fontes heterogneas de dados, o modelo proposto por esta dissertao inclu no contexto da integrao de fontes de dados a problemtica de preservao da integridade referencial especificada para os dados em suas bases de origem, problema este no levado em conta na maioria dos sistemas propostos, isto se deve ao fato de que a maioria deles foi criada apenas para integrar fontes de dados XML sem dar um enfoque a integrao de dados exportados para XML provenientes de bases relacionais, ou nem cogita a possibilidade de atualizao dos dados materializados e conseqente necessidade de serializao dos mesmos para suas bases de origem.
102
Outra vantagem do modelo proposto em relao aos modelos estuados que o mesmo foi implementado utilizando apenas padres no proprietrios e independente de qualquer plataforma de hardware ou software.
7.3. Pontos fracos e pontos fortes

No contexto das pesquisas atuais na rea de armazenamento, gerenciamento e integrao de dados, fundamental a proposta de novas solues capazes de integrar dados independente da sua origem, sejam dados provenientes de um SGBD objeto/relacional, um documento texto, ou at mesmo um site na Internet. O padro XML e os subpadres a ele correlacionados possuem a flexibilidade necessria para possibilitar o intercmbio de dados entre sistemas com alto grau de heterogeneidade, e no restam dvidas de que a combinao das tecnologias XML com ferramentas e APIs de programao modernas tais como Java com capacidade de ser multiplataforma e com os modernos SGBDs hoje existentes ir resultar em um novo modelo de sistema para tratamento, integrao, manipulao e intercmbio de informaes. Como principal deficincia deste modelo, podemos citar a necessidade da presena de um especialista humano para iniciar e solucionar conflitos de integrao, bem como definir a integridade a ser mantida nos dados integrados, isto aumenta a possibilidade da ocorrncia de erros. Como ponto forte, temos a utilizao do XML para todo o intercmbio de dados dentro do modelo, exceto claro na exportao das bases relacionais atravs dos wrappers onde foi necessrio utilizar a linguagem de consulta nativa a cada diferente SGBD (SQL na maioria dos casos), toda a integrao, definio de restries, armazenamento de regras de localizao esto definidos baseados no padro XML. Isto torna o modelo mais flexvel e possibilita a integrao de alguns mdulos do mesmo com outros modelos que tambm sejam baseados no mesmo padro.
7.4. Perspectivas futuras

Como sugestes para trabalhos futuros, pode-se citar, (i) a especificao de um sistema capaz de automatizar a definio das regras de integridade para a viso integrada dos dados diminuindo a necessidade de interveno humana; (ii)
103
implementao de wrappers com suporte a SGBDs orientados a objetos; (iii) integrao de dados exportados de bases relacionais com documentos ou bases de dados armazenadas atravs de XML e documentos semi-estruturados; (iv) estudo para verificar a viabilidade da utilizao de vises materializadas XML em grande bases de dados; (v) implementao de controle de transaes e segurana para o sistema atual; (vi) especificao de um esquema para criao de restries de integridade em vises de dados XML materializadas implementando outras funcionalidades alm da chave primria e chave estrangeira demonstradas neste trabalho.
104
8.Referncias Bibliogrficas
[Abiteboul 1997b] ABITEBOUL, S. Querying semi-structured data. In: ICDT, 1997. [s.n.], 1997. p.118. [Abiteboul et al., 1997a] ABITEBOUL, S. et al. Views for semi-structured data. In: WORKSHOP ON MANAGEMENT OF SEMISTRUCTURED DATA, 1997. Proceedings... Tucson, Arizona: [s.n.], 1997. [Abiteboul et al., 1998] ABITEBOUL, S. et al. Incremental maintenance for materialized views over semistructured data. In: PROC. 24TH INT. CONF. VERY LARGE DATA BASES, VLDB, 1998. [s.n.], 1998. p.3849. [Abiteboul et al., 2000] ABITEBOUL, S.; BUNEMAN, P.; SUCIU, D. Data on the Web : From relations to semistructured data and XML. Morgan Kaufmann Publishers, San Francisco, CA, 2000. [Batini et al., 1986] Batini, C.; Leuzirini M.; Navathe S.B.. A Compartive Analysis of Methodologies for Database Schema Integration. ACM Computer Survey, vol. 18, n. 4, 323-364, December 1986. [Bell e Grimson, 1992] Bell, D.; Grimson, J.. Distributed Database Systems. AddisonWesley, 1992, 2 ed. Pg. 44-55. [Bourret, 2001] BOURRET, R. Xml and databases. 2001. [s.n.], 2001. p.27. [Bradley, 1998] BRADLEY, N. The XML Companion. Adisson-Wesley, Edinburgh Gate, UK, 1998. [Bray et al., 1999] BRAY, T.; HOLLANDER, D.; LAYMAN, A. Namespaces in XML. World Wide Web Consortium (W3C), Janeiro, 1999. W3C RecommendationREC-xml-names-19900114.
105
[Brodie e Stonebraker, 1995] Brodie, M.; Stonebraker, M.; Migrating Legacy Systems: gateways, interfaces & the incremental approch. So Francisco, CA: Morgan Kaufmann Publishers, Inc., 1995. [Buneman et ali., 2001] BUNEMAN, Peter; DAVIDSON, Susan; et al. Reasoning about Keys for XML (Technical Report). International Workshop on Database Programming Languages (DBPL), 2001. Disponvel em http://db.cis.upenn.edu/DL/absreltr.ps.gz [Buneman, 1997] BUNEMAN, P. Semistructured data. 1997. [s.n.], 1997. p.117121. [Buretta, 1997] Buretta, M.. Data replication: tools and techniques for managing distributes information. Wiley Computer Publishing, 1997. [Buretta, 1997] BURETTA, M.. Data replication: tools and techniques for managing distributes information. Wiley Computer Publishing, 1997. [Castro, 1998] CASTRO, C. E. P. S.. Integrao de Legacy Systems a Sistemas de Bancos de Dados Heterogneos. Dissertao de Mestrado, Departamento de Informtica, Pontifcia Universidade Catlica do Rio de Janeiro, Rio de Janeiro, Jul. 1998. [Chen et al., 2002] CHEN, Yi; DAVIDSON, Susan; ZHENG, Yifeng. Validating Constraints in XML. Department of Computer and Information Science, University of Pennsylvania, 2002. Disponvel em http://db.cis.upenn.edu/DL/validate.ps. [Date, 1991] DATE, C. J. Introduo a Sistemas de Bancos de Dados. Rio de Janeiro: Campus, 1991. [Elmasri et al., 1987] Elmasri, R.; Larson, J.; Navathe, S. B.. Integration Algorithms for Database and Logical Database Design. Technical Report, Golden Valley, Minn.: Honey-well Corporate Research Center, 1987. [Fallside, 2000] FALLSIDE, D. C. XML schema part 0: Primer. World Wide Web Consortium (W3C), Fevereiro, 2000. Working DraftWD-xmlschema-0-20000225.
106
[Fernandez et al, 1999] FERNANDEZ, M.; TAN, W. C.; SUCIU, D. SilkRoute: Trading between Relations and XML. University of Pennsylvania: [s.n.], 1999. Disponvel em: < http://db.cis.upenn.edu/RXL/papers/sr.html>. Acesso em: 22 mar 2000.Technical Report. [Florescu et al., 1998a] FLORESCU, D.; KOSSMANN, D. A performance evaluation of alternative mapping schemes for storing XML data in a relational database. 1998. 31 p. p. Relatrio tcnico. [Florescu et al., 1998b] FLORESCU, D.; LEVY, A. Y.; MENDELZON, A. O. Database techniques for the world-wide Web: A survey. SIGMOD Record, [S.l.], v.27, n.3, p.5974, 1998. [Furgeri, 2001] FURGERI, S. Ensino Didtico da Linguagem XML. rica, 2001. [Georgakopoulos et al., 1994] GEROGAKOPOULOS, et al. Using Tickets to Ensure Serializability of Multidatabase Transactions. IEEE Transactions on knowledge and Data Engineering, vol. 6, n.1, February, 1994. [Gupta et al., 1995] GUPTA, A.; MUMICK, I. S. Maintenance of materialized views: Problems, techniques and applications. IEEE Quarterly Bulletin on Data Engineering; Special Issue on Materialized Views and DataWarehousing, [S.l.], v.18, n.2, p.318, 1995. [Hull, 1996] HULL, R.; ZHOU, G. A framework for supporting data integration using the materialized and virtual approaches. 1996. [s.n.], 1996. p.481492. [Hull, 1997] HULL, R. Managing semantic heterogeneity in databases : A theoretical perspective. In: ICDT, 1997. [s.n.], 1997. [Lee e Chu, 2000] Lee, Dongwon; Chu, Wesley W. Comparative Analysis of Six XML Schema Languages. University of California, Los Angeles 2000. [Manica, 2001] Manica, Heloise. Bancos de dados distribudos heterogneos: Arquiteturas, tecnologias e tendncias. Dissertao de mestrado em Cincias da Computao, Departamento de Informtica e Estatstica INE, 2001.
107
[Mello et al., 2000] MELLO, R. S. et al. Dados semi-estruturados. In: SIMPSIO BRASILEIRO DE BANCO DE DADOS, 2000. [s.n.], 2000. p.39. [Murphy e Grimson, 1995] MURPHY, J. & GRIMSON, J.. Multidatabase Interoperability in the Jupiter System. Information and Software Technology. Vol 37, N. 9, 1995. [Nestorov et al., 1998] NESTOROV, S.; ABITEBOUL, S.; MOTWANI, R. Extracting schema from semistructured data. 1998. [s.n.], 1998. p.295306. [zsu e Valduriez, 1999] zsu, M. Tamer; Valduriez, Patrick. Principles of distributed Database Systems. New Jersey: Prentice Hall, 2 ed., US, 1999. [Papakonstantinou et al., 1995] PAPAKONSTANTINOU, Y. et al. A query translation scheme for rapid implementation of wrappers. In: 4TH INTL. CONF. ON DEDUCTIVE AND OBJECT-ORIENTED [Quan et al., 2001] QUAN, L.; CHEN, L.; RUNDENSTEINER, E. A. Argos: Efficient refresh in an XQL-based Web caching system. Lecture Notes in Computer Science, [S.l.], v.1997. [Sheth e Larson, 1990] Sheth, A.P.; Larson, J. A.. Federated Database Systems for managing Distributed, Heterogeneous and Autonomous Databases. ACM Computing Surveys, vol. 22, n. 3, Sept, 1990. [Silva, 1994] Silva, S. D.. Sistemas de Bancos de Dados Heterogneos: Modelo de Execuo de Gerncia de Transaes. Tese de doutorado em informtica, Dept. de Informtica PUC-Rio. Rio de Janeiro, 1994. [Silva, 2001] SILVA, A. S. Materializao de Vises Relacionais para Dados SemiEstruturados atravs de Ontologias. Universidade Federal do Rio Grande do Sul, 2001. Dissertao de Mestrado. [Widom, 1995] WIDOM, J. Research problems in data warehousing. In: 4TH INTERNATIONAL CONFERENCE ON INFORMATION AND KNOWLEDGE MANAGEMENT, 1995. Proceedings... Baltimore, Maryland: [s.n.], 1995. p.2530.
108
[Wiederhold, 1992] WIEDERHOLD, G. Mediators in the architecture of future information systems. Computer Magazine of the Computer Group News of the IEEE Computer Group Society, [S.l.], 1992. [Wood, 1998] WOOD, L. Documento object model (dom). World Wide Web Consortium (W3C), Outubro, 1998. W3C working draft. [Yan et al., 1997] Yan, L. L.. zsu, M. T.; Liu, L.. Accessing Heterogeneous Data Through Homogenization and Integration Mediators. In 2nd Int. Conf. On Cooperative Information Systems (CoopIS97), 130-139, June 1997. [Yao et al., 1982] Yao, S. B.. Waddle, V.; Housel, B.. View Modeling and Integration Using the Functional Data Model. IEEE Trans. Software Eng., vol 8, n. 6, 544-554, November 1982. [Zhu, 2000] ZHU, Y. et al. Materializing Web data for OLAP and DSS. In: WEBAGE INFORMATION MANAGEMENT, 2000. [s.n.], 2000. p.201214.
109
9.Apndice
XML-QL ::= (Function | Query) <EOF> Function ::= 'FUNCTION' <FUN-ID> '(' (<VAR>(':' <DTD>)?)* ')' (':' <DTD>)? Query 'END' Query ::= Element | Literal | <VAR> | QueryBlock Element ::= StartTag Query EndTag StartTag ::= '<'(<ID>|<VAR>) SkolemID? Attribute* '>' SkolemID ::= <ID> '(' <VAR> (',' <VAR>)* ')' Attribute ::= <ID> '=' ('"' <STRING> '"' | <VAR> ) EndTag ::= '<' / <ID>? '>' Literal ::= <STRING> QueryBlock ::= Where Construct ('{' QueryBlock '}')* Where ::= 'WHERE' Condition (',' Condition)* Construct ::= OrderedBy? 'CONSTRUCT' Query Condition ::= Pattern BindingAs* 'IN' DataSource | Predicate Pattern ::= StartTagPattern Pattern* EndTag StartTagPattern ::= '<' RegularExpression Attribute* '>' RegularExpression ::= RegularExpression '*' | RegularExpression '+' | RegularExpression '.' RegularExpression | RegularExpression '|' RegularExpression | <VAR> | <ID> BindingAs ::= 'ELEMENT_AS' <VAR> | 'CONTENT_AS' <VAR> Predicate ::= Expression OpRel Expression Expression ::= <VAR> | <CONSTANT> OpRel ::= '<' | '<=' | '>' | '>=' | '=' | '!=' OrderedBy ::= 'ORDERED-BY' <VAR>+ DataSource ::= <VAR> | <URI> | <FUN-ID>(DataSource (',' DataSource)*) Anexo 1 : XML-QL Grammar

Integrando BD XML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Integrando BD XML

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PS-GRADUAO EM CINCIAS DA COMPUTAO

INTEGRANDO BANCOS DE DADOS HETEROGNEOS ATRAVS DO PADRO XML

Prof. Murilo Silva de Camargo, Dr.

Florianpolis, setembro 2002

UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PS-GRADUAO EM CINCIAS DA COMPUTAO

INTEGRANDO BANCOS DE DADOS HETEROGNEOS ATRAVS DO PADRO XML

Prof. Murilo Silva de Camargo, Dr.

Florianpolis, outubro 2002

INTEGRANDO BANCOS DE DADOS HETEROGNEOS ATRAVS DO PADRO XML

Banca Examinadora ________________________________

8. REFERNCIAS BIBLIOGRFICAS......................................................................................... 104 9. APNDICE .................................................................................................................................. 109

LISTA DE FIGURAS E TABELAS

LISTAGENS DE CDIGO FONTE

Common Object Request Broker

Lightweight Object Repository

Standard Generalized Markup Language

1.4. Trabalhos Correlacionados

1.5. Organizao do Texto

2.Bancos de Dados Distribudos e Heterogneos

2.1. Conceitos bsicos

Figura 1 : Arquitetura de um banco de dados distribudo.

2.2. Requisitos funcionais de um SGBDD

diferentes, mesmo se estes sistemas de bancos de dados so diferentes (heterogneos).

2.3. Fatores negativos na utilizao de SGBDD

2.4. Arquiteturas para SGBDD

Figura 2 : Arquitetura data-lgica de SGBD distribudo.

EEL1 ECL1 EEL2 EIL1 EIL1 ECL2

Figura 3 : Arquitetura data-lgica de multi-SGBD

2.5. Sistemas Homogneos e Sistemas Heterogneos

2.6. Banco de Dados Distribudo Heterogneo

2.6.1. Sistemas Multidatabase

UL11 UL12 UL13

14 Figura 4 : Sistema Multidatabase (com usurios locais e globais)

2.6.2. Sistema Federado e No Federado

2.6.3. Sistemas Legados

2.7. Tcnicas e Ferramentas de Integrao

2.7.1. Integrao atravs de modelos que especificam um esquema conceitual global

EEL11 ECL1 EEL12 EIL1

Figura 5 : Arquitetura com esquema conceitual global

2.7.2. O processo de integrao e traduo de esquemas

Esquema Conceitual Global

Figura 6 : Integrao de Bancos de dados: traduo e integrao

Figura 7 : Arquitetura Bsica dos Mediadores.

Figura 8 : Arquitetura Bsica dos Mediadores com auxlio dos wrappers.

2.8. Exemplos de Sistemas Gerenciadores de Bancos de Dados Heterogneos

Lingua-gem Caractersticas de Acesso Global

ris e Orientado a objetos Orientado a objetos

HOSQL (extenso da OSQL) VML

Tabela 2 : Caractersticas dos SGBDH.

2.8.1. Multidatabase [Buretta, 1997]

Esquema Auxiliar (Daplex)

Interface de dados globais

Esquema Global (Daplex)

Esquema Local (Daplex)

Esquema Local (Daplex)

Figura 9 : Arquitetura do SGBDD-H Multidatabase

2.8.2. Projeto Jupter [Murphy e Grimson, 1995]

ORBIX (CORBA Implementations)

Local System 1 Jupter Server Local DBMS (1-n)

Local System 2 Jupter Server Local DBMS (1-n)

Local System n Jupter Server Local DBMS (1-n)

Figura 10 : Arquitetura do Jupter.

2.8.3. HEROS - HetERogeneous Object System [Castro, 1998]