Trabalho sobre Banco de Dados Banco de Dados Distribuídos, Orientado a Objetos e XML

Transcrição

1 PCS 2033 Engenharia de Software II Trabalho sobre Banco de Dados Banco de Dados Distribuídos, Orientado a Objetos e XML Integrantes: Nusp: Data: 02/08/2010 Anderson Jun Kodama Eduardo Barasal Morales Fernando Cabral Grandjean Pinto Filho Renato Dias Kavai

2 Índice 1. Resumo Introdução Banco de Dados Distribuídos Sobre Principais Usos Exemplos e SGBDs Vantagens Desvantagens Banco de Dados Orientado a Objetos Sobre Principais Usos Exemplos e SGBDs Vantagens Desvantagens Banco de Dados XML Sobre Principais Usos Exemplos Vantagens Desvantagens Características e Uso de 2 SGBDs exist Xindice Formas de uso Analise Comparativa Conclusão Bibliografia...15 Glossário SGBD - Sistema de Gerenciamento de Banco de Dados SQL - Structured Query Language XML - extensible Markup Language BDD - Banco de Dados Distribuídos SGBDOO - Sistema de Gerenciamento de Banco de Dados Orientado a Objetos. ODGM - Object Database Management Group ODL - Object Definition Language OQL - Object Query Language BDOO - Banco de Dados Oreintado a Objetos CAD - Computer Aided Design CAM - Computer Aided Manufacturing W3C - World Wide Web Consortium API - Application Programming Interface

3 1. Resumo Com o intuito de armazenar informações em único lugar integrado para várias aplicações desenvolveu-se o Banco de Dados. Contudo diferentes níveis de complexidade de informações necessitou formas distintas de armazenamento e acesso. Através desse documento é feita uma análise sobre três tipos de Banco de Dados: Banco de Dados Distribuídos, Banco de Dados Orientado a Objetos e Banco de Dados XML, onde para cada tipo é dada uma introdução aos conceitos envolvidos, além de uma idéia de usos comuns, exemplos de SGBDs e a listagem de algumas vantagens e desvantagens relacionadas à estes bancos. De forma geral os Bancos de Dados Distribuídos apresentam uma forma de comunicação entre diversos nós que podem representar uma cópia ou um fragmento do conjunto de dados de uma aplicação. O atual cenário das aplicações em nuvem e a grande demanda de armazenamento de dados cria um ambiente propício para a popularização deste tipo de banco de dados, a idéia destes bancos não requerem o uso de um paradigma específico. Além de conceitos por trás de Bancos Distribuídos, pode-se estudar a partir deste documento conceitos relacionados à Banco de Dados Orientado a Objetos. O paradigma que rege estes bancos é empregado na maior parte das aplicações de sistemas, fazendo com que seja vantajoso a utilização de um banco de dados que não necessite de tradução ou conversão. Além disso, a partir desse banco, foi possível armazenar valores de tipos de dados estruturados ao invés de itens atômicos definido pelas tabelas no modelo relacional. Por fim, tem-se os Bancos de Dados XML que vem com o intuito de facilitar e tornar mais eficiente o emprego desta linguagem de marcação, que também é amplamente difundida em diversos tipos de aplicações. Para ilustrar melhor este tipo de banco foi desenvolvido também uma breve demonstração de uso de dois SGBDs que empregam XML nativamente e foram apontadas distinções entre eles. 2. Introdução O Objetivo deste trabalho é analisar diferente tipos de modelos de Banco de Dados e compará-los quanto às características teóricas e utilização na engenharia de computação atual. Um banco de dados consiste em um conjunto organizado de dados, os quais são utilizados por softwares, sistemas WEB e outras aplicações para gerenciamento de dados. Existem diferentes tipos e níveis de organização de banco de dados. Uma das organizações mais utilizadas atualmente é o modelo de dados relacional, onde diferentes conjuntos de dados são representados por relações ou tabelas e estas organizações são relacionadas através de chaves estrangeiras. O gerenciamento de um banco de dados é feito por um SGBD. Os SGBDs são diferentes para cada tipo de modelo de banco de dados e, também, diferem entre si em relação a qual linguagem de query (busca) eles utilizam. Existem SGBDs que abordam mais de uma organização e linguagem de busca. A query é o método de alteração utilizado pelos SGBDs para o gerenciamento dos bancos de dados. A partir de uma query dados podem ser inseridos, editados, apagados e recuperados do banco de dados a partir de diversas regras impostas por elas. A linguagem de query mais utilizada hoje em dia é a SQL, que é baseada na algebra relacional. A seguir serão apresentados três modelos de banco de dados: o Banco de Dados Distribuídos, o Banco de Dados Orientado a Objetos e o Banco de dados XML.

4 3. Banco de Dados Distribuídos 3.1 Sobre O banco de dados distribuído é um conjunto de banco de dados logicamente relacionados distribuídos sobre uma rede de computadores. As estações podem ter dados replicados, ou seja, cada estação possui uma cópia dos dados, ou podem ter dados fragmentados, onde cada nó possui base de dados diferentes. Os bancos de dados distribuídos podem ser divididos em dois tipos diferentes: Homogêneos e Heterogêneos. Quando um banco é homogêneo todos os nós são compostos pelos mesmos bancos de dados, sendo geralmente utilizado quando o sistema ja foi desenvolvido para ser distribuído. Um banco heterôgeneo possui mais de um tipo de banco de dados, e é aplicado costumamente quando as aplicações já existiam e necessitam ser relacionadas. Outra classificação para os BDDs é quanto a replicação de dados. Ela pode ser síncrona, onde todos os nós recebem os dados e a transação só é concluída quando todas as transações locais forem. A replicação também pode ser assíncrona onde cada transação é feita localmente. 3.2 Principais Usos Uma grande utilidade dos Bancos de Dados Distribuídos é em empresas ou lojas com diversos departamentos, onde cada um produz e possui diferentes demandas de dados. Nesse tipo de ambiente, os dados podem ser concentrados onde são mais necessários, e podem ser acessados por qualquer um dos outros departamentos quando necessários. Outros usos desse tipo de banco de dados são redes sociais como o Facebook, que utiliza essa organização nas buscas. 3.3 Exemplos e SGBDs Os SGBDs para banco de dados distribuídos (conhecidos como SGBDDs) são costumamente mais complexos que os SGBDs para bancos locais, pois necessitam de um controle de concorrência mais avançado para conseguir gerenciar a replicação de todos os nós e centralizar os dados de maneira transparente. Alguns exemplos de SGBDDs são o Apache Cassandra e o HBase. 3.4 Vantagens Reflete a estrutura organizacional, ou seja, os dados são salvos nos locais onde são utilizados, mas podem ser consultados por qualquer nó da distribuição. Autonômia local que permite que cada nó controle seus dados. Maior disponibilidade e confiabilidade, pois falhas afetam somente um fragmento do sistema. Melhor performance, consequência da estrutura organizada, que concentra os dados no local onde há mais demanda. Econômico, pois uma rede de computadores menores tem menor custo do que um computador maior de mesmo desempenho. Modularidade que permite adição, remoção e modificação sem afetar os outros nós.

5 3.5 Desvantagens Complexidade, pois é necessário processamento extra para manter sistemas diferente sincronizados de maneira transparente. Implantação mais cara, embora compense a longo prazo. Segurança deve ser bem reforçada, tanto nas estações quanto na transferencia de dados entre elas. A integridade do sistema é dificil de ser mantida, pois exige muitos recursos da rede. Por ser um sistema relativamente novo, não existem muitas experiências práticas Não existem padrões de de conversão de SGBDs para SGBDs distribuídos. Por fim, o design é muito mais complexo por ter que considerar a fragmentação e replicação de dados em lugares específicos. 4. Banco de Dados Orientado a Objetos 4.1 Sobre Com a crescente complexidade das aplicações de sistema, bancos de dados relacionais apresentaram limitações que se tornaram obstáculos. Para solucionar essas limitações e agregar o paradigma de desenvolvimento orientado a objetos surgiu o banco de dados orientados a objetos (BDOOs). Uma outra vantagem para a criação desse banco foi o padrão UML que é amplamente utilizado na orientação objetos. Para padronizar as funcionalidades de um SGBDOO foi formado um grupo chamado ODGM (Object Database Management Group). Esse grupo definiu um modelo de objetos, denominado ODL (Object Definition Language) e uma linguagem de consulta, denominada OQL (Object Query Language). Através do ODL foi possivel definir estruturas de dados arbitrariamente complexas como valores de tipos de dados estruturados no SGBDOO. Já com a OQL é possível consultar e manipular objetos armazenados no banco de dados. Orientação a Objetos Antes de analisarmos esse SGBD é preciso definir o paradigma de orientação a objetos. Esse paradigma é uma forma de representar uma solução no domínio do problema, utilizando uma abstração do mundo em objetos que realizam pequenas tarefas e interagem entre si. A orientação a objetos é construido baseando-se nos seus quatros conceitos básicos, abstração, encapsulamento, herança e polimorfismo. A abstração permite agrupar as propriedades comuns a um determinado conjunto, suprimindo alguns detalhes. Algumas formas de aplicação de abstração são as generalizações/especializações e agregações. O encapsulamento que consiste na separação dos conceitos internos e externos de uma classe ocasionando assim um baixo acoplamento e uma alta coesão. A partir dessa divisão cria-se uma proteção aos dados internos de um objeto, de uma determina classe, que só podem ser acessados através da troca de mensagens. A herança é um mecanismo que permite o reuso e o compartilhamento de código e acarreta numa consistência de interface (duas classes que herdam de uma classe disporão ter um comportamento semelhante). O Polimorfismo é um mecanismo que permite que uma mesma operação possa se comporta de diferentes formas em classes distintas. Algumas possíveis formas de utilização de polimorfismo é através de sobrecarga de operação(overload) e redefinição de operação (override).

6 Sistema de gerenciamento de banco de dados orientados a objetos Em um sistema de gerenciamento de banco de dados orientado a objetos podemos dividir o estudo em objetos, classes e relacionamentos. Objetos podem ser vistos como encapsuladores de dados e de código que se comunicam entre si através de mensagens. Eles possuem variáveis que armazenam o estado do objetos, um conjunto de mensagens às quais o objeto responde e um conjunto de métodos que realizam a manipulação dos dados e o tratamento e geração de mensagens. Classe é um agrupamento de objetos de mesmo tipo,ou seja, um objeto é um instância de uma classe. Uma classe é composta por atributos, que corresponde aos dados dos objetos, e métodos. Os relacionamentos entre classes podem ser classificados em três tipos: herança, associação e composição/agregação. No relacionamento de herança é do tipo é um e representa a derivação de uma classe a outra classe (especialização). Essa derivação faz com que a sub-classe herde tanto atributos como métodos da super-classe. Contudo na sub-classe pode acontecer o polimorfismo através overload e/ou override. O conceito de BDOO permite tanto herança simples, aonde uma classe herda de uma outra, quanto herança múltipla, aonde um classe pode herdar de mais de uma classe. Além disso pode se utilizar o conceito de classe abstrata, que não pode ser instanciada porém que contém informações, na herança. O relacionamento de associação, é igual ao dos bancos de dados relacionais, e pode ser unidirecional ou bidirecional com cardinalidades de 1x1, 1xn e nxn. O relacionamento de composição/agregação é do tipo é parte de e utiliza o conceito de objetos compostos ou complexos. Um objeto composto consiste no agrupamento de objetos. Esse agrupamento também pode acontecer em vários níveis como por exemplo: um objeto avô é composta de vários objetos pais que por sua vez é composto por vários objetos filhos. Para armazenar os objetos no banco de dados foi desenvolvido o conceito de identidade do objeto para caracterizar cada objeto. A identidade do objeto não utiliza informações do estado do objeto e nem de seus atributos e é geralmente gerada pelo sistema. Assim cada objeto se torna único no banco de dados. 4.2 Principais Usos Os bancos de dados orientados a objetos não são amplamente utilizados atualmente em comparação com os banco de dados relacionais. Contudo em algumas situações, principalmente em mercados verticais, como telecomunicações, finanças e saúde, ele é bem empregado. Além disso áreas como multimídia, CAD e CAM (Computer Aided Design/ Computer Aided Manufacturing) pode expandir o mercado desse banco de dados. 4.3 Exemplos e SGBDs Existem vários sistemas de gerenciamento de banco de dados orientados a objetos. Abaixo segue alguns exemplos: EnterpriseBD criado pela empresa EnterpriseBD e é opensource. Objectivity/DB criado pela empresa Objectivity Database Systems e não é opensource. GemStone criado pela empresa GemStone System Inc. e não é opensource. ConteXT criado pela empresa Unixspace e não é opensource.

7 Versant criado pela empresa Versant Corp. e não é opensource. Caché criado pela empresa Intersystems Software e não é opensource. EyeDB criado pela empresa Sysra Informatique e é opensource. Jasmine criado pela empresa Computer Associates e não é opensource. ORION criado pela empresa Orion Group (Purdue University) e é opensource. ObjectStore criado pela empresa Progress Software e não é opensource. 4.4 Vantagens A capacidade de armazenamento de objetos para aplicações que usam o paradigma de orientação a objetos, ou seja, não precisa fazer nenhuma conversão ou mapeamento para armazenar os dados. Não há a necessidade de joins porque os dados são encontrados através de ponteiros gerando assim uma possível melhora nos SGBDOOs comparados a SGBDs relacionais, principalmente em casos especificos. Utilização de conceitos de orientação a objetos para armazenamento de dados permite uma maior flexibilidade do sistema, escalabilidade e facilidade de manutenção. 4.5 Desvantagens A falta de padronização das linguagens de manipulação dos dados entre SGBDOOs. O conceito de encapsulamento da orientação a objetos implica que os métodos e tipos de dados sejam determinados com antencedência uma vez que atributos internos de um objeto não podem ser alterados pelo exterior. Alguns SGBDOOs podem apresentar problemas de interoperabilidade com ferramentas e padr oes do modelo relacional já bem estabelecidos. Baixa utilização comparado ao banco de dados relacional devido ao alto custo envolvido na troca de sistemas e a dificuldade de aprendizado. 5. Banco de Dados XML 5.1 Sobre Um banco de dados XML pode ser entendido como um software de persistência que permite o armazenamento de dados obtidos no formato XML. O XML é uma linguagem de marcação de dados, que pode ser utilizada para troca, compartilhamento ou armazenamento de dados.

8 De forma geral existem duas abordagens dominantes para a implementação deste modelo de banco de dados: XML-habilitado: nesta abordagem os utilizados Sistemas de Gerenciamento de Banco de Dados são utilizados para prover interfaces que transformem os dados no formato XML para o formato interno de armazenamento e vice-versa. XML Nativo: esta abordagem define um modelo lógico para documentos XML de forma que haja um suporte eficiente para seu armazenamento e recuperação. Estas duas abordagens são descritas em melhor detalhe a seguir. XML-habilitado Neste caso os documentos XML são utilizados para trocar dados entre o banco de dados e uma aplicação ou outro banco. O processo de retirar dados do banco e gerar um documento XML, ou um pedaço de um documento, é denominado de publicação ou composição, já o processo inverso é chamado de particionamento ou decomposição. Para facilitar o entendimento deste conceito são usados exemplos para casos onde se faz o uso de bancos de dados relacionais, que são os mais comuns atualmente. Na figura a seguir é apresentada uma visão geral do funcionamento explicado. Nota-se que dentro do SGBD os documentos são armazenados na forma de tabelas. Estas tabelas são organizadas de forma específica para a estrutura do documento XML, ou seja, o schema do banco de dados é equivalente ao schema do documento XML, assim para um schema XML diferente é necessário outro schema de banco de dados. Outro fato que pode ser notado neste tipo de abordagem é que dentro do banco de dados não há um XML visível, de forma que não é clara a diferenciação entre elementos e atributos, por exemplo. XML Nativo Nesta abordagem, os documentos XML são armazenados no banco de dados. Abaixo é apresentada uma figura que ilustra a visão geral do banco.

9 Diferentemente do que este conceito pode levar a crer, os bancos de dados não armazenam necessariamente os documentos diretamente como arquivos de extensão xml ou na forma direta de texto, eles podem fazer uso de outro tipo de abstração de dados, como o relacional. Para ilustrar um exemplo, no caso do uso de uma abstração relacional, as tabelas são definidas para o armazenamento especifico de documentos XML, assim há uma tabela para especificação de documentos, outra para elementos, outra para atributos e outra para textos. Com isso, no próprio banco é observável uma estrutura de documentos XML, ou seja o schema do banco de dados modela um documento XML e não os dados contidos nele. Os bancos de dados XML nativos visam prover um sistema robusto para manipulação e armazenamento de documentos XML, porém nem todos estes bancos funcionam de forma autônoma e trabalham com o auxilio de outros SGBDs. Na figura abaixo são apresentados os componentes que constituem um banco nativo, nela podem ser identificados o Gerenciador de Armazenamento e a Interface XML nativa, que são os principais constituintes do sistema. Existe uma definição formal dada pela iniciativa XML:DB dizendo que um banco de dados XML nativo define um modelo para um documento XML e armazena e recupera documentos baseados neste modelo, possui um documento XML como sua unidade fundamental para armazenamento (fazendo um paralelo com bancos relacionais, esta unidade seriam suas linhas) e por fim, o banco não precisa ter nenhum sistema para armazenamento de baixo nível em particular, podem ser usadas estruturas relacionais, orientadas a objetos ou alguma estrutura proprietária.

10 5.2 Principais Usos Os principais usos deste tipo de SGBDs estão ligados ao fato do emprego extensivo de documentos XML. Um dos casos mais comuns é a necessidade de publicação de dados armazenados em bancos de dados no formato XML, outro caso de uso é para o armazenamento de dados semi-estruturados de onde se tira proveito da extensibilidade do formato XML, um último exemplo, é para o caso mais óbvio onde se deseja armazenar documentos XML. A escolha entre o uso de um banco XML-habilitado ou um XML Nativo deve levar em conta principalmente, se os documentos XML são centrados em dados ou documentos. No caso de documentos voltados a dados, a escolha feita em geral são os bancos XMLhabilitados, uma vez que este tipo de documento costuma ter uma estrutura relativamente regular e poucos conteúdos misturados. Já para o caso de documentos centrados em documentos, a escolha mais comum são os bancos XML Nativos, já que ao contrário do outro tipo de documento, estes apresentam maior variabilidade na estrutura e diversos tipos de conteúdos. Estas decisões não são absolutas, nem sempre pode-se fazer uma distinção clara sobre o tipo dos documentos, sendo assim, toma-se os casos citados no parágrafo anterior como meros guias para a tomada de decisões. 5.3 Exemplos Alguns exemplos de bancos XML Nativos são: NatiX: um banco que internamente divide os documentos XML em sub-árvores de acordo com o tamanho de páginas do disco físico. exist: um banco de código aberto que pode guardar documentos tanto por um mecanismo interno quanto por um banco relacional externo. É independente de schema. Xindice: armazena um documento XML por completo, como um único registro. Tamino: possui armazenamento orientado a documentos para guardar a estrutura hierárquica do documento XML, diferentemente dos exemplos anteriores suporta o uso de um schema XML. Para o caso de banco XML-habilitados diversos SGBDs bem conhecidos no mercado podem atuar como tal, só para citar alguns exemplos tem-se os casos do MySQL, SQL Server, Access 2007, DB2, Oracle e PostgreSQL. 5.4 Vantagens Banco de dados XML Nativos apresentam três vantagens fundamentais: Escalabilidade: o fato destas ferramentas nativas possuirem uma organização interna semelhante ao do XML permite que elas sejam moldadas de forma a atender as necessidades do cliente ou servidor de forma mais fácil. Acesso a dados mais rápidos: os bancos nativos não querem um overhead para mapeamento, trocas de dados e junções entre o XML e outras estruturas (como uma tabela). Confiabilidade: entre o armazenamento e recuperação de um documento XML não há a possibilidade de ocorrência de inconsistências, no caso de um XML-habilitado ou uma solução que empregue uma conversão do XML, há o risco da estrutura se alterar entre as conversões para e a partir do formato XML.

11 5.5 Desvantagens A maior desvantagem para este tipo de banco é que: Em geral, estes sistemas são menos maduros se comparados a outros mais difundidos, como os bancos de dados relacionais. Observando outra formas de abordagens pode-se citar algumas vantagens e desvantagens de cada uma: Orientado à sistema de arquivos: é de fácil implementação e atende bem a pequenos conjuntos de XML, tem como desvantagem o fato de apresentar menor praticidade no acesso e atualização de dados. Relacional: é de fácil implementação, possui uma escalabilidade e confiabilidade relativamente boas, por outro lado, requer muitas junções devido à segmentação dos XMLs. Objeto-Relacional: também de fácil implementação e suporta tipos abstratos de dados, tem por desvantagem a grande segmentação dos documentos XML. 6. Características e Uso de 2 SGBDs Para aprofundar os estudos de banco de dados XML, serão feito estudos das características e uso de dois SGBDs que utilizam XML. Os SGBDs estudados serão o exist e o Xindice, que são dois SGBDs XML nativos. Antes de fazer uma comparação, a seguir encontra-se uma introdução sobre cada uma dessas escolhas: 6.1 exist O exist é um banco de dados de código aberto desenvolvido em java, que pode ser integrado em aplicações que utilizam XML, tais como aplicações web e até sistemas de documentação. O exist oferece armazenamento de documentos XML sem esquemas através de coleções hierárquicas. Os usuários podem recuperar qualquer parte da coleção ou todos documentos do banco de dados através do XPath. O módulo de consulta do exist tem um eficiente processamento de consultas baseadas em índice. A indexação suporta a identificação rápida das relações estruturais entre os nós das árvores que representam o documento XML.. exist oferece extensões para o padrão XPath para processar consultas fulltext, incluindo por palavras chaves, por proximidade ou expressões regulares. Para desenvolvedores são oferecidos acesso via HTTP, XL-RPC, SOAP e WebDav e aplicações Java podem utilizar a API XML:DB. 6.2 Xindice O Xindice era inicialmente o banco de dados XML chamado dbxml, que foi o primeiro produto lançado pelo grupo dbxml, mas o código fonte foi doado ao Apache Software Foundation e renomeado para Xindice.

12 Esse banco de dados armazena e indexa documentos XML compactados para reduzir o número de overheads de processamento no lado do servidor. O Xindice possui uma estrutura hierárquica onde os documentos ficam dentro de coleções. A raiz de todos os dados é uma instância no banco de dados chamada db e todas coleções abaixo da raiz começam com /db. O Xindice usa como linguagem de atualização o XML:DB XUpdate e existe uma implementação da API XML:DB para o desenvolvimento em Java. Há também uma maneira de acessar Xindice de outras linguagens de programação usando a API XML-PRC. Para a linguagem de consulta o Xindice utiliza o XPath. 6.3 Formas de uso Como foi citado ambos os SGBDs podem ser utilizados a partir da API XML:DB, além disso ambos permitem o uso da linguagem de atualização XML:DB XUpdate (no caso do exist também existe o suporte ao XQuery Extension como linguagem de atualização), a seguir são apresentados dois códigos implementados em Java, o primeiro permite a execução de queries no padrão XPath, já o segundo permite a execução de estruturas no formato da linguagem XML:DB XUpdate. Os códigos apresentam a implementação para o caso do exist, para o Xindice os códigos são análogos bastando alterar o driver e a URI passada ao DatabaseManager. import org.xmldb.api.base.*; import org.xmldb.api.modules.*; import org.xmldb.api.*; public class ExemploQuery { public static void main(string args[]) throws Exception { String driver = "org.exist.xmldb.databaseimpl"; Class cl = Class.forName(driver); Database database = (Database)cl.newInstance(); DatabaseManager.registerDatabase(database); Collection col = DatabaseManager.getCollection( "xmldb:exist://localhost:8080/ xist/xmlrpc/db/discos"); XPathQueryService service = (XPathQueryService) col.getservice("xpathqueryservice", "1.0"); service.setproperty("indent", "yes"); /* Execução de uma query XPath */ ResourceSet result = service.query("/catalogo/cd[preco < 10]"); ResourceIterator i = result.getiterator(); while(i.hasmoreresources()) { Resource r = i.nextresource(); import org.xmldb.api.base.*; import org.xmldb.api.modules.*; import org.xmldb.api.*; public class ExemploXUpdate { public static void main(string[] args) throws Exception { String driver = "org.exist.xmldb.databaseimpl"; Class c = Class.forName(driver); Database database = (Database) c.newinstance(); DatabaseManager.registerDatabase(database); Collection col = DatabaseManager.getCollection("xmldb:exist: //localhost:8080/exist/xmlrpc/db/discos"); /* Exemplo de uma requisição insert-after (outras operações podem ser usadas) */ String xupd = "<xupdate:modifications version=\"1.0\" xmlns:xupdate=\" + "<xupdate:insert-after select=\"/catalogo/cd[last()]\">" + "<xupdate:element name=\"teste\">insert</xupdate:element>" + "</xupdate:insert-before>" + "</xupdate:modifications>"; XUpdateQueryService service = (XUpdateQueryService) col.getservice("xupdatequeryservice", "1.0"); service.update(xupd); } } System.out.println((String)r.getContent ()); } } }

13 A execução do primeiro código retorna apenas um elemento, no caso CD, que por sua vez contém como filho o elemento PRECO de valor Já na execução do segundo código um novo elemento filho de CATALOGO é incluido após o último filho CD. <CATALOGO> <CD> <TITULO>Empire Burlesque</TITULO> <ARTISTA>Bob Dylan</ARTISTA> <PRECO>10.90</PRECO> <ANO>1985</ANO> </CD> <CD> <TITULO>Hide your heart</titulo> <ARTISTA>Bonnie Tyler</ARTISTA> <PRECO>9.90</PRECO> <ANO>1988</ANO> </CD> </CATALOGO> <CD> <TITULO>Hide your heart</titulo> <ARTISTA>Bonnie Tyler</ARTISTA> <PRECO>9.90</PRECO> <ANO>1988</ANO> </CD> <CATALOGO> <CD> <TITULO>Empire Burlesque</TITULO> <ARTISTA>Bob Dylan</ARTISTA> <PRECO>10.90</PRECO> <ANO>1985</ANO> </CD> <CD> <TITULO>Hide your heart</titulo> <ARTISTA>Bonnie Tyler</ARTISTA> <PRECO>9.90</PRECO> <ANO>1988</ANO> </CD> <TESTE>INSERT</TESTE> </CATALOGO> XML original Resultado da consulta XML após insert 7. Analise Comparativa Alguns aspectos e características de cada SGBD foram pesquisados e encontrados algumas diferenças entre eles: O exist possui maior capacidade de armazenamento do que o Xindice. Ele, teoricamente, não tem um limite de tamanho máximo de um documento XML para inserção, embora algumas características do arquivo e do sistema operacional possam influenciar e causar erros, tornando bastante instável a inserção de documentos grandes. Então o exist suporta inserção de arquivos grandes, enquanto que no Xindice existe um limite baixo em torno de 2,5Mb. O exist suporta um maior número de níveis hierárquicos que o Xindice. No teste pesquisado, onde apenas haviam dados de criação de n níveis e mais nenhum outro tipo de dados, o exist suportou aproximadamente 8000 níveis hierárquicos, enquanto que o Xindice suportou apenas aproximadamente 700. E o exist suportou aproximadamente 2milhões de filhos do nó raiz, enquanto que o Xindice suportou apenas algo em torno de 90mil. O exist suporta validação de documentos tanto implicitamente quanto explicitamente, enquanto que no Xindice não é possível fazer essa validação. Segundo o guia de usuário do Xindice essa funcionalidade foi omitida para proporcionar maior flexibilidade de armazenamento de dados. O exist utiliza XQuery (padrão da W3C) como linguagem de consulta dos dados. O XQuery utiliza expressões de caminho XPath para referir-se a partes do documento e, através do XPath, é possível acessar a árvore toda do documento através da notação de caminhos, além de definir predicados e eixos para filtrar os dados desejados. Já o Xindice utiliza o XPath como linguagem de consulta de dados. Nesse caso a consulta pode ser feita de duas maneiras: através da API XML- RPC ou por linha de comando. Como linguagem de atualização, no caso da pesquisa desses dados para comparação, o exist usou o XQuery Extension, o qual permite inserir dentro de suas expressões comandos de atualização. Essa extensão permite inserir, atualizar, excluir e renomear nós de documentos XML. Nesse caso, o Xindice usou a linguagem de atualização XUpdate, a qual é expressada em formato XML, portanto deve estar em um arquivo separado e deve ser referenciado na linha de comando ao ser utilizado. Na questão de capacidades, o XUpdate é semelhante ao XQuery Extension.

14 8. Conclusão O estudo de diferentes tipos de paradigmas leva a constatação de que apesar do amplo uso de bancos de dados relacionais em diversos projetos correntes, existem outras alternativas capazes de se adaptar melhor ao requisito da aplicação, como os bancos de dados orientados a objetos ou os bancos XML nativos. Há casos também onde alternativas são capazes de suprir necessidades não cobertas pelos bancos relacionais tradicionais, como o caso dos SGBDs distribuidos. Além dos tipos de banco de dados, também é importante fazer um estudo e testes para mesmos tipos de banco de dados. Ao comparar dois SGBDs de mesmo tipo (exist e Xindice) verifica-se uma grande diferença em algumas características, tornando cada um dos SGBDs adequados a aplicações diferentes. O exist, por exemplo, é mais adequado que o Xindice para o desenvolvimento de uma camada para gerenciamento de atualizações de documentos e esquemas XML.

15 9. Bibliografia XML Data Stores: Emerging Practices (2005). Último acesso: 31/07/2010. Link: XML for DB2 Information Integration. Último acesso: 31/07/2010. Link: XML and Databases. Último acesso: 31/07/2010. Link: XML Databases Products: XML-Enabled Databases. Último acesso: 01/08/2010. Link: XML Databases Products: XML Native. Último acesso: 01/08/2010. Link: Apache Cassandra. Último acesso: 31/07/2010 Link: Banco de Dados Distribuídos - Centro de Insino Superior Foz do Iguaçu. Último acesso: 31/07/2010 Link: Banco de Dados Distribuídos - Anibal Pinheiro. Último acesso: 31/07/2010 Link: Último acesso: 2/08/ Último acesso: 2/08/ Último acesso: 2/08/ Último acesso: 2/08/ Último acesso: 2/08/ Último acesso: 2/08/2010 Wikipédia - Database - Link: Último acesso: 2/08/2010 Wikipédia - SQL - Link: Último acesso: 2/08/2010 Wikipédia - Distributed Database: Link: Último acesso: 2/08/2010 Xindice: User Guide: Link Último acesso: 2/08/2010 exist: Último acesso: 2/08/2010