• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Db mapeamento relacional
 

Db mapeamento relacional

on

  • 1,578 views

Bem, essas são as 4 cláusulas mais utilizadas para fazermos amarrações entre tabelas ou pegarmos valores relacionados.

Bem, essas são as 4 cláusulas mais utilizadas para fazermos amarrações entre tabelas ou pegarmos valores relacionados.

Statistics

Views

Total Views
1,578
Views on SlideShare
1,578
Embed Views
0

Actions

Likes
1
Downloads
49
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Db mapeamento relacional Db mapeamento relacional Document Transcript

    • 1 Anderson Gomes da Silva 0205109 8º SemestreMapeamento Objeto-Relacional Monografia apresentada à disciplina Trabalho de Conclusão do Curso de Ciências da Computação da Faculdade de Jaguariúna, sob. a orientação do Prof. Leonardo Hartleben Reinehr, como exigência parcial para conclusão do curso de graduação. Jaguariúna 2005
    • 2Silva, Anderson Gomes. Estudo Comparativo de Ferramentas de Mapeamento Objeto-Relacional, Monografia defendida e aprovada na FAJ em 15 de Dezembro de 2005 pelabanca examinadora constituída pelos professores:____________________________________________________Profº. Leonardo Hartleben Reinehr –FAJ - Orientador____________________________________________________Profº. Odersom____________________________________________________Profº. Roberto Pacheco
    • 3Aos meus pais Vital e Maria do Carmoe irmãos Helinton e Erica.
    • 4 AgradecimentosPrimeiramente à Deus pois sem ele nada é possível;Aos meus pais Vital e Maria do Carmo, por toda educação e amor queforam investidos em mim durante a minha vida;Aos meus irmão e minha namorada que me incentivaram neste trabalho;Aos meus professores, pelas conversas, conselhos e ensinamento queservirão para a vida toda;Ao meu orientador Leonardo Hartleben Reinehr, pela confiança e apoiodepositados em mim;À todos meus amigos: Leonardo, Michel, Robson, Juliano, pela amizade eapoio, algo que vai durar muito mais do que quatro anos;À todas as pessoas que me ajudaram nesta etapa da minha vida;
    • 5"É muito melhor arriscar coisas grandiosas,alcançar triunfos e glórias, mesmo expondo-se aderrota, do que formar fila com os pobres deespírito que nem gozam muito nem sofrem muito,porque vivem nessa penumbra cinzenta que nãoconhece vitória nem derrota." (Theodore Roosevelt)
    • 6SILVA, Anderson Gomes. Estudo Comparativo de Ferramentas de MapeamentoObjeto-Relacional. 2005. Monografia. (Bacharelado em Ciências da Computação) –Curso de Ciências da Computação da Faculdade de Jaguariúna, Jaguariúna. RESUMO Este trabalho é um estudo comparativo entre as Ferramentas de MapeamentoObjeto-relacional, com enfoque ao Banco de Dados Objeto-Relacional. E tem comoobjetivo avaliar o estado da arte da teoria de mapeamento objeto-relacional, identificandoas características e necessidades desse mecanismo, ele também ira mostrar os principaisframeworks para mapeamento objeto-relacional, identificando as vantagens de suautilização, funcionalidades oferecidas e características de implementação de acordo com ateoria de mapeamento objeto-relacional. Mostrara também a implementação de um estudo de caso utilizando os frameworksestudados, comparando os resultados obtidos em termos de funcionalidades, performance,flexibilidade e facilidade de uso entre outros aspectos.Palavras-chave: Banco de Dados Relacional, Ferramentas de Mapeamento Objeto-Relacional. ABSTRACT This work is a comparative study between the Relational-object Mapping Tools, with approach to the Database Relational-object. Its target is to evaluate the art state of the theory of mapping relational-object, and identify the characteristics and needs of this mechanism, it will also show the main frameworks to mapping relational-object, to identify the advantages of its use, offered functionalities and implementation characteristics according to the theory of mapping relational-object. It will also show the implementation of a case-study using the analyzed frameworks, comparing the acquired results in functionalities terms, performance, flexibility and facilities, and others aspects. Key-Word: Relationary data base, Tools of Objeto-Relacional Mapping.
    • 7LISTA DE ABREVIATURAS E SIGLASAPI Application Programming InterfaceCASE Computer Aided Software EngineeringOID Object IdentificationOO Orientado a ObjetoOO-ER Orientado a Objeto Entidade RelacionalUML Unified Modeling LanguageXMI XML Metadata InterchangeXML eXtensible Markup LanguageOQL Object Query LanguageSGBD Sistema Gerenciador de Banco de DadosSGBDOO Sistema Gerenciador de Banco de Dados Orientado a ObjetoSGBDOR Sistema Gerenciador de Banco de Dados Objeto RelacionalSGBDR Sistema Gerenciador de Banco de Dados RelacionaisSQL Structured Query LanguageER Entidade Relacionamento
    • 8 LISTA DE FIGURASFIGURA 1 Mapeamento BásicoFIGURA 2 Mapeamento de Relacionamento (um-para-um)FIGURA 3 Mapeamento de Relacionamento (um-para-muitos)FIGURA 4 Mapeamento de Relacionamento (muitos-para-muitos)FIGURA 5 Uma Tabela para toda HierarquiaFIGURA 6 Uma Tabela por Classe ConcretaFIGURA 7 Uma Tabela por ClasseFIGURA 8 Uma Visão Simplista do HibernateFIGURA 9 Componentes do Hiberante
    • 9 LISTAS DE TABELASTABELA 1 Comparativo entre técnicas de mapeamento de classeTABELA 2 Parâmetros principais para configuração da conexão JDBCTABELA 3 Parâmetros que definem comportamentos em tempo de execuçãoTABELA 4 Criando um SessionFactory através do objeto configurationTABELA 5 Classe candidata a persistênciaTABELA 6 Implementação da classe pessoaTABELA 7 Declaração de criação da tabela que armazena a classe pessoaTABELA 8 Mapeando a classe pessoa numa tabelaTABELA 9 Tipos de geradores presentes no HiberanteTABELA 10 Mapeamento da classe pessoa com parâmetros opcionaisTABELA 11 Associação entre os tipos do Hibernate, classes Wrapper Java e tipo no BDTABELA 12 Mapeamento conteplado no SessionFactoryTABELA 13 Banco de dados suportados pelo HibernateTABELA 14 Comparações do Hibernate com outros frameworks de persistênciasTABELA 15 Diagrama de Classe “Biblioteca Música”
    • 10 SUMÁRIOLISTA DE ABREVIATURA E SIGLAS......................................................................7LISTAS DE FIGURAS..................................................................................................8LISTAS DE TABELAS.................................................................................................91. INTRODUÇÃO………………...............................................................................112. REVISÃO BIBLIOGRÁFICA……………………................................................213. MAPEAMENTO OBJETO RELACIONAL……………...................................... 394. FERRAMENTAS DE MAPEAMENTO OBJETO RELACIONAL………..........595. ESTUDO DE CASO…………………...................................................................666. RESULTADOS OBTIDOS.....................................................................................687. CONCLUSÕES.......................................................................................................708. REFERÊNCIA BIBLIOGRÁFICA.........................................................................71
    • 11 1. INTRODUÇAO Desde seu desenvolvimento até os dias atuais, bancos de dados relacionais sempreforam os mais utilizados no cenário comercial [DATE, SILBERSCHATZ]. Por outro lado,nos últimos anos houve uma crescente disseminação das linguagens orientadas a objeto nodesenvolvimento de aplicações. Dessa forma, hoje existe um grande número de aplicaçõesorientadas a objeto que acessam bancos de dados relacionais. Existe uma notada incompatibilidade entre o modelo orientado a objetos e o modelorelacional [AGILE DATA], a qual dificulta a transformação dos dados armazenados em ummodelo para o outro. Por isso, é importante a existência de mecanismos para realizar omapeamento das classes do modelo orientado a objeto para tabelas do modelo relacional. A teoria de mapeamento objeto-relacional define um conjunto de característicasnecessárias a tais mecanismos, além de apresentar possíveis soluções para os problemas deincompatibilidade entre os modelos [DATE, SILBERSCHATZ, AGILE DATA]. Os frameworks de mapeamento objeto-relacional oferecem enormes facilidades paraa realização desse tipo de mapeamento, implementando as soluções indicadas na teoria demapeamentos e permitindo que as aplicações executem mapeamentos por meio deconfiguração e definição de regras ao invés da escrita de linhas de código [Hibernate]. O presente trabalho tem por objetivo mostrar as principais características de umMapeamento Objeto-Relacional, com enfoque em um estudo comparativo de ferramentasde mapeamento e na identificação de problemas e questões em aberto das ferramentasexistentes. Para isso, será implementado um estudo de caso usando diversas tecnologias eframeworks existentes, comparando os resultados obtidos.
    • 12 2. REVISÃO BIBLIOGRÁFICA 2.1. BANCO DE DADOS RELACIONAIS Um banco de dados é um conjunto de informações com uma estrutura regular. Umbanco de dados é normalmente, mas não necessariamente, armazenado em algum formatode máquina lido pelo computador. Há uma grande variedade de banco de dados, desdesimples tabelas armazenadas em um único arquivo até gigantescos bancos de dados commuitos milhões de registros, armazenados em salas cheias de dados rígidos. Os banco dedados caracteristicamente moderno são desenvolvidos desde os anos da década de 1960,um dos pioneiros neste trabalho foi Charles Bachman. Existe uma grande variedade debanco de dados, desde exemplos simples como uma simples coleção de tabelas até ummodelo teoricamente definido, o relacional [AGILE DATA]. O modelo de dados lógico relacional é atualmente o mais utilizado nos SGBDscomerciais. Entretanto, este modelo possui um sistema de tipos simples e restrito, o quedificulta a descrição de algumas aplicações atuais que necessitam tipos mais complexos ecaracterísticas do modelo Orientado a Objetos. Sistemas de Banco de Dados que utilizam o modelo relacional, ou seja, SGBDRs,são também considerados sistemas de segunda geração de SGBDs visto que os sistemas deBanco de Dados Hierárquicos e de Rede são considerados a primeira geração. Assim, ossistemas de Banco de Dados Objeto Relacionais são classificados como a terceira geraçãode SGBDs. 2.2. ORIENTAÇÃO A OBJETO Orientação a objeto pode ser definida como um conjunto de disciplinas demodelagem de software que facilitam a construção sistemas complexos a partir decomponentes individuais). O apelo intuitivo da orientação a objeto é que ele proporcionaconceitos e ferramentas para modelar e representar o mundo real. As vantagens daorientação a objeto na programação e na modelagem de dados são muitas[AGILE DATA].
    • 13 A programação de objeto (orientada) permite uma representação mais direta domodelo do mundo real no código. O resultado é que a transformação radical dasrequisições do sistema (definido em termos de usuários) para especificação do sistema(definido em termos de computador) é enormemente reduzida. 2.3. IMPEDÂNCIA Os desenvolvedores de aplicações de bancos de dados (ou seja, qualquer aplicaçãoque acesse dados armazenados em um banco de dados) freqüentemente se vêem brigandocom problemas de diferenças de impedância: a inerente falta de casamento entre osmodelos de dados relacionais e os orientados a objeto. Os esforços para “mapear” dadosrelacionais em um formato utilizável de objetos frequentemente prejudicam tanto aprodutividade do programador quanto o desempenho da aplicação. A diferença de impedância é uma expressão utilizada em engenharia elétrica, masno contexto deste trabalho, refere-se à diferença que existe entre os modelos de dadosrelacional e objeto. O modelo relacional organiza todos os dados em linhas e colunas, ondecada linha representa um registro. Se os dados forem por demais complexos para seremrepresentados em forma de tabela, tabelas adicionais são cridas para conter as informações“relacionadas”. Dessa forma, cada tabela em um esquema relacional conterá registro masnão todos os dados para uma grande quantidade de registros. O modelo de dados orientado a objeto não está limitado a manter as informações emlinhas e colunas. Em vez disso, o desenvolvedor cria uma definição, um modelo, quedescreve completamente uma determinada classe de informações. Cada registro (objeto) éuma instância específica daquela classe. Assim, cada registro contém todos os itens deinformação para um, e apenas um, registro. Mas isso não é tudo, as definições de classestambém podem incluir trechos de programação, denominados métodos que apenas sobre osdados descritos pela classe. Não há uma concepção análoga no modelo relacional. 2.3.1. Usando um banco de dados relacional
    • 14 Esta seção já discute como a tentativa de usar um banco de dados relacional comuma aplicação baseada em tecnologia de objetos apresenta sérios problemas de diferença deimpedância. Mas as vezes os desenvolvedores não tem escolha. Pode ser que eles tenhamde acessar dados que residem em um banco de dados relacional. Nesse caso, uma opção éusar ema ferramenta de “mapeamento objeto-relacional”, quer seja ela autônoma, querconsiste em facilidades disponível nos bancos de dados “objeto-relacional”.Essencialmente, as ferramentas de mapeamento criam um arquivo (um mapa) que contémas regras para a tradução entre objetos e tabelas relacionais. Os desenvolvedores devemespecificar exatamente como a tradução será feita, ou seja, que propriedades do objetocorrespondem a quais colunas de que tabelas e vice-versa. Uma vez criado, o mapa é salvoe invocado sempre que uma aplicação move os dados para o banco de dados. Algumasferramentas de mapeamento objeto relacional provêem um componente de cachê em tempode execução para ajudar a compensar a perda de desempenho causada pela tradução entreas formas relacionais e de objetos. Além de poder causar problema de performance durante a execução, o mapeamentoobjeto-relacional pode atrasar significativamente o desenvolvimento da aplicação. Amaioria das ferramentas de mapeamento não implementa conceitos de modelagem deobjetos, como herança e polimorfismo, ou o faz apenas parcialmente. Assim, à medida queuma aplicação é adaptada e modificada, mapas objeto-relacional novos e atualizados têm deser criados. Os desenvolvedores que enfrentam o problema da diferença de impedância entreaplicação orientadas a objeto e bancos de dados relacionais relacional podem quererconsiderar a opção de migrar os dados para um sistema de armazenamento mais amigável.Eles devem então avaliar, o esforço de reformatar e transferir seus dados uma só vez, emrelação ao trabalho constante e as perdas de desempenho que resultam do uso de um mapaobjeto-relacional. 2.3.2. Usando um banco de dados de objeto À primeira vista, parecia que a diferença de impedância poderia ser totalmenteeliminada armazenando-se os dados em um banco “puramente” de objetos. Isso é
    • 15parcialmente verdade. Em geral, para uma aplicação orientada a objeto é fácil interagir comum banco de dados orientado a objeto. No entanto, neste cenário, a diferença de impedânciaocorre quando se quer executar uma consulta SQL a essa base de dados. A SQL é, de longea linguagem de consulta mais amplamente utilizada em todo o mundo, e ela assume que osdados estão armazenados em tabelas do modelo relacional. Alguns fabricantes de banco dedados orientados a objeto fornecem o acesso a dados via linguagem de consulta de objeto(OQL, do inglês Object Query Language), mas essas linguagens não têm aceitaçãogeneralizada. Para ser compatível com as aplicações comuns de analise de dados e de geração derelatórios, um banco de dados orientado a objeto deve prover algum mecanismo pararepresentar os dados como tabelas relacionais. A solução típica é mais uma vez o mapeamento. Os pontos negativos do mapeamento(perdas de performance de dados) ainda se aplicam ao caso. O aspecto positivo é que omapeamento só precisa ser chamado quando uma consulta SQL é feita á base de dados. 2.4. CAMADA DE PERSISTÊNCIA Podemos definir persistência de dados como uma forma de manter a existência dainformação mesmo fora da aplicação. Podemos persistir a informação em um banco dedados, em um arquivo de dados ou qualquer outro meio existente e o fato da informaçãoexistir também fora da aplicação faz com que essas informações possam ser compartilhadaspor outras aplicações. Para permitir um processo de mapeamento entre sistemas baseados em objetos e basesde dados relacionais, foram propostas diversas idéias que convergiram para o conceito deCamada de Persistência. Conceitualmente, uma Camada de Persistência de Objetos é uma biblioteca quepermite a realização do processo de persistência (isto é, o armazenamento e manutenção doestado de objetos em algum meio não-volátil, como um banco de dados) de formatransparente. Graças à independência entre a camada de persistência e o repositório dedados utilizado, também é possível gerenciar a persistência de um modelo de objetos emdiversos tipos de repositórios, com pouco ou nenhum esforço extra. A utilização deste
    • 16conceito permite ao desenvolvedor trabalhar como se estivesse em um sistemacompletamente orientado a objetos – utilizando métodos para incluir, alterar e removerobjetos e uma linguagem de consulta para SGBDs Orientados a Objetos – comumente alinguagem OQL – para realizar consultas que retornam coleções de objetos instanciados. 2.4.1. Vantagens da utilização As vantagens decorrentes do uso de uma Camada de Persistência nodesenvolvimento de aplicações são evidentes: a sua utilização isola os acessos realizadosdiretamente ao banco de dados na aplicação, bem como centraliza os processos deconstrução de consultas e operações de manipulação de dados (insert, update e delete) emuma camada de objetos inacessível ao programador. Este encapsula mento deresponsabilidades garante maior confiabilidade às aplicações e permite que, em algunscasos, o próprio SGBD ou a estrutura de suas tabelas possam ser modificados, sem trazerimpacto à aplicação nem forçar a revisão e recompilação de códigos. 2.4.2. Requisitos de uma camada de persistência Segundo Scott Ambler, pesquisador e autor de diversos livros, uma Camada dePersistência real deve implementar as seguintes características: • Dar suporte a diversos tipos de mecanismos de persistência: um mecanismo de persistência pode ser definido como a estrutura que armazenará os dados – seja ela um SGBD relacional, um arquivo XML ou um SGBD OO, por exemplo. Uma Camada de Persistência deve suportar a substituição deste mecanismo livremente e permitir a gravação de estado de objetos em qualquer um destes meios. • Encapsula mento completo da camada de dados: o usuário do sistema de persistência de dados deve utilizar-se, no máximo, de mensagens de alto nível como save ou delete para lidar com a persistência dos objetos, deixando o tratamento destas mensagens para a camada de persistência em si. • Ações com multi-objetos: Suportar listas de objetos sendo instanciadas e retornadas da base de dados deve ser um item comum para qualquer implementação, tendo em vista a freqüência desta situação.
    • 17• Transações: ao utilizar-se da Camada de Persistência, o programador deve ser capaz de controlar o fluxo da transação – ou ter garantias sobre o mesmo, caso a própria Camada de Persistência preste este controle.• Extensibilidade: A Camada de Persistência deve permitir a adição de novas classes ao esquema e a modificação fácil do mecanismo de persistência.• Identificadores de Objetos: A implementação de algoritmos de geração de chaves de identificação garante que a aplicação trabalhará com objetos com identidade única e sincronizada entre o banco de dados e a aplicação.• Cursores e Proxies: As implementações de serviços de persistência devem ter ciência de que, em muitos casos, os objetos armazenados são muito grandes – e recuperá-los por completo a cada consulta não é uma boa idéia. Técnicas como o lazy loading (carregamento tardio) utilizam-se dos proxies para garantir que atributos só serão carregados à medida que forem importantes para o cliente e do conceito de cursores para manter registro da posição dos objetos no banco de dados (e em suas tabelas específicas).• Registros: Apesar da idéia de trabalhar-se apenas com objetos, as camadas de persistência devem, no geral, dispor de um mecanismo de recuperação de registros - conjuntos de colunas não encapsuladas na forma de objetos, como resultado de suas consultas. Isto permite integrar as camadas de persistências a mecanismos de geração de relatórios que não trabalham com objetos, por exemplo, além de permitir a recuperação de atributos de diversos objetos relacionados com uma só consulta.• Arquiteturas Múltiplas: O suporte a ambientes de programas stand-alone, cenários onde o banco de dados encontra-se em um servidor central e mesmo arquiteturas mais complexas (em várias camadas) deve ser inerente à Camada de Persistência, já que a mesma deve visar a reusabilidade e fácil adaptação a arquiteturas distintas.• Diversas versões de banco de dados e fabricantes: a Camada de Persistência deve tratar de reconhecer diferenças de recursos, sintaxe e outras minúcias existentes no acesso aos bancos de dados suportados, isolando isto do usuário do mecanismo e garantindo portabilidade entre plataformas.
    • 18 • Múltiplas conexões: Um gerenciamento de conexões (usualmente utilizando-se de pooling) é uma técnica que garante que vários usuários utilizarão o sistema simultaneamente sem quedas de performance. • Queries SQL: Apesar do poder trazido pela abstração em objetos, este mecanismo não é funcional em cem porcento dos casos. Para os casos extremos, a Camada de Persistência deve prover um mecanismo de queries que permita o acesso direto aos dados – ou então algum tipo de linguagem de consulta similar à SQL, de forma a permitir consultas com um grau de complexidade maior que o comum. • Controle de Concorrência: Acesso concorrente a dados pode levar a inconsistências. Para prever e evitar problemas decorrentes do acesso simultâneo, a Camada de Persistência deve prover algum tipo de mecanismo de controle de acesso. Este controle geralmente é feito utilizando-se dois níveis – com o travamento pessimístico (pessimistic locking), as linhas no banco de dados relativas ao objeto acessado por um usuário são travadas e torna-se inacessíveis a outros usuários até o mesmo liberar o objeto. No mecanismo otimístico (optimistic locking), toda a edição é feita em memória, permitindo que outros usuários venham a modificar o objeto. 2.4.3. Camadas de persistência e linguagens de programação Diversas implementações de camadas de persistência estão disponíveisgratuitamente na Internet. Estas bibliotecas muitas vezes tratam da geração dos esquemasde dados (mapeamentos) automaticamente e podem até mesmo efetuar uma engenhariareversa – criando hierarquia de classes a partir de um esquema de tabelas em banco dedados. As Camadas de Persistência que geralmente trabalham com apenas um esquema demapeamento de classes para tabelas, diversas estratégias de geração de identificadores,suporte a quaisquer tipos de relacionamento e geração de código SQL automatizada.Na linguagem Java, podemos citar algumas destas bibliotecas de persistência: • Hibernate – uma implementação que permite a persistência transparente de objetos em bases de dados utilizando JDBC e o mapeamento de classes para XML. Trata-se de um serviço de persistência e recuperação de objetos, já que, ao contrário dos
    • 19 frameworks de persistência, não é necessário estender nenhuma classe especial para que um objeto possa ser armazenado. Projetado para permitir integração com ambientes J2EE, o Hibernate utiliza reflexão (reflection) para tratar a persistência, gerando código SQL à medida que for necessário. Atualmente compatível com 11 SGBDs comerciais em sua versão 1.1 (Oracle, DB2, MySQL, PostgreSQL, Sybase, SAP DB, HypersonicSQL, Microsoft SQL Server, Progress, Mckoi SQL, Pointbase e Interbase), o Hibernate é distribuído segundo a licença LGPL e suporta uma API baseada no padrão ODMG 3.0 (o padrão para construção de SGBDs Orientados a Objetos). Dentre outros recursos interessantes, o Hibernate suporta gerenciamento remoto utilizando-se a API JMX e é capaz de gerar esquemas de dados (tabelas) para representar hierarquias de classes.• Castor – um framework de ligação de dados (databinding), o Castor propõe-se a ser "a menor distância entre objetos Java, documentos XML, diretórios LDAP e dados SQL",promovendo mapeamentos entre todas estas estruturas de representação de objetos. A API do pacote Castor específica para a persistência em bancos de dados relacionais é a JDO – uma implementação inspirada no padrão Java Data Objects da Sun. A API provê integração com ambientes J2EE. Atualmente em sua versão 0.9, o Castor suporta os SGBDs Oracle, Sybase, SQL Server, DB2, Informix, PostgreSQL, Hypersonic SQL, InstantDB, Interbase, MySQL e SAP DB. A distribuição segue a licença LGPL.• Object-Relational Java Bridge (OJB) - um projeto do grupo Apache para prover uma implementação open-source dos padrões de mapeamento de objetos ODMG e JDO, o OJB permite que objetos sejam manipulados sem a necessidade de implementar nenhuma interface em especial ou estender alguma classe específica. A biblioteca dá suporte a cenários cliente-servidor (aplicações distribuídas) ou standalone, de forma que é possível utilizar a API OJB para persistência de objetos. Além disso, a biblioteca possui integração com o sistema de geração de logs. Em sua versão 0.9, o OJB dá suporte a configuração de esquemas em tempo de execução, geração de tabelas para mapear uma hierarquia de classes ou classes relativas a um conjunto de tabelas e implementa uma série de elementos que visam melhorar a performance da Camada de Persistência. Os SGBDs suportados pela
    • 20 implementação atual incluem DB2, Hypersonic SQL, Informix, MS-Access, MS- SQL Server, MySQL, Oracle, PostgreSQL, Sybase e SAP DB. A distribuição é feita segundo a licença Apache. • Torque – um framework de persistência desenvolvido como subprojeto do projeto Apache Turbine, a API trabalha gerando toda a estrutura de banco de dados, classes e código SQL para acesso aos dados relativos a um esquema pré-configurado. O esquema é escrito na forma de um arquivo XML, que é interpretado pela biblioteca utilizando o Ant, uma ferramenta de compilação de código (build tool) do projeto Apache. A API torque encontra-se em sua versão 3.0 e é distribuída segundo a licença Apache. 2.5. O QUE SÃO FRAMEWORKS Um framework OO é uma estrutura de classes inter-relacionadas que constitui umaimplementação inacabada, para um conjunto de aplicações de um domínio, além de ser umatécnica que faz o reuso do projeto. O termo framework que inicialmente estava associado ao conceito de bibliotecas declasses reutilizáveis, mais recentemente, teve seu conceito estendido para qualquer soluçãoincompleta que pode ser completada através da instanciação, possibilitando a criação demais uma aplicação dentro do domínio-alvo do framework (Esta definição temsimilaridades com a do gerador de artefatos).Atualmente esta técnica tem sido muito apoiada e utilizada pela comunidade dedesenvolvimento de SI. Há uma vasta gama de frameworks disponíveis, tanto na forma desoftware livre quanto proprietário, alguns mais restritos, outros mais flexíveis. É necessário conhecer bem um framework antes de adotá-lo em seu projeto, muitosainda são muito imaturos e podem condenar o software a um curto período de sucesso.
    • 213. MAPEAMNTO OBJETO RELACIONAL O termo Mapeamento Objeto Relacional refere-se a técnica de mapear os registro doBanco de Dados em objetos e persistir as informações contidas nos objeto em forma delinhas e colunas. Como o próprio nome diz, Mapeamento Objeto / Relacional,é responsável pormapear classes e atributos do modelo orientado a objeto para tabelas e colunas do banco dedados. Existem várias formas de fazer esse mapeamento. Alguns frameworks utilizam alinguagem XML, outros nos obrigam a implementar alguma Interface ou trabalhar com osAtributos do .NET, mas o objetivo é sempre o mesmo: Permitir que o framework consigagerar os comandos SQL dinamicamente. Uma outra característica deste modelo é a independência do banco de dados.Devido a geração de comandos dinâmicos, o framework pode analisar qual banco de dadosa aplicação está acessando e gerar os comandos no dialeto específico do banco de dados, ouseja, é possível mudar o banco de dados da aplicação apenas alterando um arquivo deconfiguração. 3.1. Mapeando objetos para tabelas Para permitir a correta persistência de objetos em um banco de dados relacional,algum acordo deve ser feito no tocante à forma como os dados serão armazenados. Existemdiversas técnicas que permitem o mapeamento de conjuntos de objetos, cada qual com suasvantagens e desvantagens sobre as demais. Em geral, uma Camada de Persistênciaimplementa uma destas técnicas, de forma que o desenvolvedor de software, ao escolher omecanismo de persistência com o qual trabalhará, sabe como deve organizar as tabelas emseu banco de dados para suportar o esquema de objetos desejado. No decorrer deste artigo,detalhamos como é feito o mapeamento de cada um dos elementos de um objeto: seusatributos, relacionamentos e classes descendentes (herança).
    • 22 3.2. Mapeando atributos Ao transpor-se um objeto para uma tabela relacional, os atributos do mesmo sãomapeados em colunas da tabela. Este processo de mapeamento deve levar em consideraçãofatores como a tipagem dos dados (alguns SGBDs podem não suportar tipos binárioslongos, por exemplo) e o comprimento máximo dos campos (no caso de números e strings).Também é importante lembrar que, em diversos casos, atributos de um objeto não devemter obrigatoriamente uma coluna em uma tabela que os referencie. Como exemplo,podemos citar o valor total de um pedido: este dado poderia ser armazenado no objeto parafins de consulta, mas mantê-lo no banco de dados talvez não seja uma idéia tãointeressante, por tratar-se de um valor que pode ser obtido através de consultas. Alémdisso, existem casos onde um atributo pode ser mapeado para diversas colunas (exemplosincluem endereços completos, nome dividido em primeiro nome e sobrenome no bancode dados) ou vários atributos podem ser mapeados para uma mesma coluna (prefixo enúmero de telefone, por exemplo). As implementações de Camadas dePersistência provêem, em alguns casos, suporte a este tipo de situação. 3.3. Mapeamento de classes em tabelas O mapeamento de estruturas de classes em tabelas de uma base de dados relacionalnem sempre é um processo simples: enquanto alguns acham interessante a adoção de"tabelões" (isto é, tabelas não-normalizadas agrupando dados de diversas entidades) comorepositório para os dados, outros preferem ater-se às regras propostas pelas teorias denormalização de bancos de dados relacionais. As três técnicas de mapeamento de objetosmais comumente implementadas (inclusive em Camadas de Persistência) são detalhadas aseguir. É comum a adoção de uma destas técnicas, mesmo quando nenhum tipo demecanismo de persistência automático é adotado no desenvolvimento. 3.4. Mapeamento de uma tabela por hierarquia
    • 23 Segundo esta estratégia, toda a hierarquia de classes deve ser representada por umamesma tabela no banco de dados: uma coluna que identifique o tipo do objeto serve paraidentificar a classe do objeto representado por cada linha na tabela, quando nenhum outromodo de identificação é viável. As desvantagens desta estratégia são evidentes: a ausênciade normalização dos dados fere as regras comuns da teoria de modelagem de dados – alémdisso, para hierarquias de classes com muitas especializações, a proliferação de camposcom valores nulos na maioria das linhas da tabela se torna também um problema potencial. 3.5. Mapeamento de uma tabela por classe concreta Nesta estratégia, teremos uma tabela no banco de dados para cada classe concretapresente em nosso sistema. A tabela identifica a classe de todos os elementos contidos namesma, tornando desnecessário o mecanismo de Object Type adotado na estratégiaanterior. A estratégia de geração de uma tabela para cada classe concreta levaà redundância de dados: quaisquer atributos definidos em uma superclasse abstrata nahierarquia devem ser criados em todas as tabelas que representam subclasses da mesma.Além disso, mudar o tipo (especializar ou generalizar) um objeto torna-se um problema, jáque é necessário transferir todos os seus dados de uma tabela para outra no atoda atualização. 3.6. Mapeamento de uma tabela por classe Na terceira estratégia proposta, criamos uma tabela para cada classe da hierarquia,relacionadas através do mecanismo de especialização padrão do banco de dados (utilizaçãode chaves estrangeiras). Segundo esta modalidade de mapeamento, tenta-se ao máximomanter a normalização de dados, de forma que a estrutura final das tabelas fica bastanteparecida com a hierarquia das classes representada pela UML. A colocação de umidentificador de tipo (Object Type) na classe-pai da hierarquia permite identificar o tipo deum objeto armazenado nas tabelas do sistema sem forçar junções entre as tabelas,garantindo melhorias na performance, e é uma estratégia comumente utilizada. Esta é atécnica que mais naturalmente mapeia objetos para bancos de dados relacionais, de forma
    • 24que as Camadas de Persistência geralmente forçam a utilização de um esquema de dadosque siga esta modalidade de mapeamento. A quantidade de junções (joins) entre tabelaspara obter todos os dados de um objeto o seu principal ponto negativo. A tabela 1 faz um comparativo destas três técnicas quanto à facilidade de consulta adados interativa (ad-hoc reporting), facilidade implementação, facilidade de acesso aosdados, acoplamento dos dados das classes mapeadas, velocidade de acesso e suporte apolimorfismo. Uma tabela por Uma tabela por Uma tabela por hierarquia de classes classe concreta classeAd-hoc reporting Simples Médio Médio/DifícilFacilidade de Simples Médio DifícilimplementaçãoFacilidade de acesso Simples Simples Médio/SimplesAcoplamento Muito alto Alto BaixoVelocidade de acesso Rápido Rápido Médio/RápidoSuporte a Médio Baixo Altopolimorfismos Tabela 1. Comparativo entre técnicas de mapeamento de classes 3.7. Mapeamento de relacionamentos Os relacionamentos de associação entre objetos são uma das características maisfacilmente mapeadas. Conceitualmente, existem apenas trás tipos de relacionamentospossíveis (um-para-um, um-para-muitos e muitos-para-muitos). Relacionamentos um-para-um necessitam que uma chave (foreign key) seja postaem uma das duas tabelas, relacionando o elemento associado na outra tabela. Dependendoda disposição desta chave estrangeira, podemos definir a navegabilidade do relacionamento(que se dá sempre da tabela que possui a chave estrangeira para a tabela referenciada). Paramanter relacionamentos um-para-muitos, adota-se a mesma técnica: uma referência naforma de chave estrangeira deve ser posta na tabela que contém os objetos múltiplos (lado
    • 25"n" do relacionamento).No caso de relacionamentos muitos-para-muitos (ou n-para-n),convenciona-se criar uma tabela intermediária que armazene pares de chaves, identificandoos dois lados do relacionamento. Há uma tendência para a utilização de Linguagens de Programação Orientadas aObjeto(LPOO) e mecanismos de persistência diversos, principalmente, Banco de DadosRelacionais(BDR).Surge então um problema, a integração entre a linguagem e o BD.Embora existam várias APIs e modelos de mapeamento que possibilitam esta integração,elas devem ser utilizadas de acordo com diretrizes para que não se perca os benefícios daorientação a objetos e nem do BDR. O simples mapeamento das classes, em nível de projeto, para tabelas do BDR nãogarante a resolução do problema, na verdade existem outros aspectos, não menosimportantes, que podem levar a, violação dos princípios básicos da orientação a objetoscomo encapsula-mento e modularização, ou descaracterização da arquitetura adotada.Mesmo assim o modelo de objetos do banco é diferente do modelo de objetos utilizado pelalinguagem de programação. Enquanto a linguagem trabalha com objetos na memória, obanco trabalha com objetos em disco, o que exige algoritmos e estratégias diferenciadas.Além de que, os BDOOs não são, atualmente, a tecnologia padrão no mercado, por contado legado em investimento em sistemas desenvolvidos, pela cultura dos profissionaisatuando no mercado ou até mesmo por questões de performance. Algumas ferramentas RAD, como DelphiTM, JbuilderTM e Dreamweaver, tornamsemi-automática a integração de uma LPOO com um BDR. No entanto essa implementaçãoé realizada sem a preocupação de critérios que garantam a continuidade e reversibilidade daimplementação em relação ao projeto. Estes erros não são somente cometidos nestascondições, existem diversas “implementações ad hoc” que infringem estes e outrosaspectos. Um mecanismo de persistência tem três componentes básicos, são eles:– Regras de mapeamento;– API de acesso ao Banco de Dados;– Linguagem de consulta;
    • 26 Este componentes se interligam para gerar o mecanismo de persistência, que deveter como objetivos a maior abstração possível do BDR nas regras de negócio e a melhorperformance possível. Além disso um mecanismo deve considerar também asfuncionalidades tanto da LPOO quanto do BDR, resultando maior reusabilidade,extensibilidade e eficiência. No caso de se obter reusabilidade nas regras de negócio orientado a objeto é precisoseguir o princípio da independência dos objetos de negócio em relação ao mecanismo depersistência. As regras de mapeamento gerenciam como o modelo OO que é mais ricosemanticamente, vai ser mapeado para o modelo relacional. Como irão se comportarherança, agregação, entre outros devem estar definidos nestas regras. A linguagem de consulta é responsável para manipular os dados do banco, pode serbaseada em objetos ou não. As APIs são responsáveis pela integração do mecanismo com as regras de negócio.Estas podem ser intrusivas ou não. Quando estas impõem regras sob criação das classespersistentes, a API é intrusiva, caso contrário não. A tendência é que as APIs sejam não intrusivas, porém dificilmente o BD seráutilizado com eficiência, bem como os conceitos transparentes ao Banco de Dados, comotransações, serão mais difíceis de implementar sem modificar ou denegrir responsabilidadesno modelo de objetos. Em termos de performance deve-se desenvolver uma política sobre como e quais osatributos serão carregados, em uma consulta. Podemos utilizar o carregamento antecipado,ou o carregamento tardio4. Em alguns casos deve-se ter uma política de escrita no BDtambém. 3.2. MAPEAMENTO OO – ER A integração objeto-relacional requer uma estratégia para mapeamento de modeloobjeto para o modelo relacional. O banco de dados relacional possui característicasimportantes tais como consultas rápidas, compartilhamento de informações entre programase armazenamento permanente. O modelo objeto possui componentes, estado e é baseado
    • 27em estruturas que combinam código e dados e ainda possuem sua própria identidade(Object Identification – OID) Esta identidade não depende dos valores que o objeto possui,ela possibilita estabelecer referências entre objetos e definir os relacionamentos, os quaispodem ser dos seguintes tipos: associação, agregação, generalização/especialização.OIDs possibilitam simplificar a estratégia de uso de chaves no banco de dados, elesfacilitam a navegação entre objetos simplificados os joins. Outra vantagem é que o uso deOIDs facilitam a manutenção dos relacionamentos entre objetos. Quando todas as tabelaspossuem suas chaves baseadas num mesmo tipo de colunas, torna-se mais fácil escrever ocódigo e tirar vantagens disso. O modelo objeto e o modelo relacional são fundamentalmente diferentes, o modeloobjeto é útil para expressar relações complexas entre objetos nas Linguagens deProgramação Orientada a Objeto como, C++ e Java. Já o modelo relacional é útil paragerenciar grande volume de dados em Banco de Dados Relacional como, SQL Server eOracle. Sendo assim cada uma das classes do modelo OO é transformada em uma tabela nomodelo relacional. Para as associações, o mapeamento é feito ou com a criação de novastabelas ou com a cópia das chaves de uma tabela para outra. Para agregação, a regra égeneralização /especialização, cuja transformação para o modelo relacional é executadocom interação do usuário, uma vez que para um mesmo caso pode haver diferentes formasde transformação.Existem algumas regras de transformação que tem por finalidade a conversão do modeloOO para o modelo relacional. As regras se dividem em (OBJECTMATTER, 2003): - Mapeamento Básico - Mapeamento Herança de Classe - Mapeamento Relacionamento de Objeto Serão descritas as técnicas fundamentais requeridas para o sucesso do mapeamentoobjeto para o relacional. Isto poderá ajudar a rever os conteúdos que predominam nodesenvolvimento e praticas que envolvem este assunto 3.2.1. Mapeamento Básico
    • 28 A classe pode ser mapeada para tabelas. O simples mapeamento entre a classepersiste e a tabela é um-para-um. Neste caso, todos os atributos da classe persistente sãorepresentados por todas as colunas da tabela. Cada instância da classe do negócio éarmazenada em uma linha da tabela. Um atributo de uma classe pode ser mapeado para zero ou mais colunas. Èimportante lembrar que nem todos os atributos são persistentes, por exemplo, um atributototal que é usado para instanciar um somatório, logo, este não é persistido no banco dedados. Alguns atributos dos objetos são objetos por si só, como exemplo: endereço, cep,rua,etc.. portanto devem ser tratados como relacionamentos. 3.2.2. Mapeamento herança de classe O conceito de herança lança vários interesses do entrelaçamento de salvar objetosem banco de dados relacionais. Este assunto basicamente concentra-se em imaginar comoorganizar o atributo herdado em seu modelo persistente. A maneira como será resolvidoeste desafio poderá ter um grande impacto no projeto de seu sistema.Existem três tipos de soluções que são fundamentais para mapear a herança para o modelorelacional: - Mapeamento uma tabela para toda hierarquia: com este método mapeia-se toda aclasse de herança para uma tabela, onde todos os atributos de toda a classe da hierarquiasão armazenados e, uma coluna OID é introduzida como chave primária na tabela; - Mapeando uma tabela por classe: com este método cada tabela inclui tanto os seusatributos quanto os atributos herdados. Somente as classes “folhas” das hierarquias sãomapeadas para tabelas; -Mapeando uma tabela por classe; com este método cria-se uma tabela por classe. Aprincipal vantagem é que esta abordagem é a que esta mais conforme a orientação aobjetos. Os registros estão armazenados nas tabelas apropriadas, de acordo com seus
    • 29papeis. Uma desvantagem, neste método são mais tabelas BD (mais tabelas para manter osrelacionamentos). 3.2.3. Mapeando relacionamento de objetos Não somente devemos mapear os objetos para o banco de dados, mas tambémmapear os relacionamentos que envolvem os objetos. Existem quatro tipos derelacionamento os quais os objetos podem estar envolvidos: generalização, associação,agregação e composição. Para mapear efetivamente esses relacionamentos, devemosestender as diferenças entre eles, como implementar a generalização, e como implementarrelacionamento muitos-para-muitos especificamente. Para o banco de dados, perspectivamente, somente tem diferença entre osrelacionamentos de associação e agregação/composição e como o objeto é firmementeamarrado a ele. Com a agregação e composição qualquer coisa que você faça com o todono banco de dados você sempre precisará fazer nas partes, enquanto que com associaçãoeste não é o caso. O diagrama de classes é a estrutura das tabelas que são usadas para discutir as varias Maneiras de relacionamentos de objetos um-para-um, um-para-muitos, muitos-para-muitos, que podem ser mapeados para o modelo relacional. No modelo relacional o relacionamento um-para-um, mantém-se, comumente, pormeios de colunas de chaves estrangeiras. Esta coluna de chave estrangeira mantém o valorda chave primária (OID do objeto) da coluna (objeto) referenciada. O relacionamento um-para-um pode ser definido como referencia ao atributo, isto pode ser feitotransparentemente convertendo a chave estrangeira do objeto referenciado. Isto tambémpossibilita a definição do relacionamento um-para-um no modelo relacional usando umajoin table. No modelo objetos existem dois tipos de relacionamento um-para-muitos:agregação (parte de), e associação. Um relacionamento de agregação é definido por meiosdo próprio atributo e um relacionamento de associação por meios de uma coleçãoreferenciada ao atributo. A diferença entre as duas é que no relacionamento próprio, que épróprio é atualizado no banco de dados. Todos os objetos, em todas as suas coleções, são
    • 30automaticamente atualizados (este comportamento pode ser modificado em tempo deexecução se necessário). No modelo relacional, um-para-muitos pode ser definidos usando a coluna de chaveestrangeira ou usando uma join table é uma tabela com o propósito de armazenar os valoresmapeados entre a chave estrangeira das duas tabelas envolvidas no relacionamento. Um relacionamento muitos-para-muitos pode ser como uma bi-direcionalassociação um-para-muitos. Para criar este tipo de relacionamento, simplesmente,definimos o atributo referenciado na coleção, em cada classe envolvida no relacionamento.No modelo relacional um relacionamento muitos-para-mutos pode ser definido usandocolunas de chaves estrangeiras ou uma join table. Para usar chaves estrangeiras, uma coluna com a chave estrangeira é definida paracada tabela envolvida no relacionamento. Cada coluna da chave estrangeira mantém achave da outra tabela. Existem vários tipos que podem ser implementados para associaçãomuitos-para-muitos usando join table. Uma das maneiras de implementar relacionamento muitos-para-muitos é usandouma tabela associativa. O nome da tabela associativa é geralmente a combinação dos nomesdas tabelas que estão associadas ou o nome da associação implementada entre elas. Aassociação original possui um relacionamento muitos-para-muitos e com a utilização databela associativa se faz um cruzamento das multiplicações e não se perde essa associação.O propósito de uma tabela associativa é implementar uma associação descrita em umaclasse associativa. 3.3. OBJETIVOS GERAIS DOS COMPONENTES MAPEAMENTO OO- ER Mapeamento objeto-relacional é a transformação das regras do modelo objeto paraas regras e normalizações do modelo relacional. Isto significa que existem dois modelosutilizados na construção de sistemas. O modelo objeto é utilizado para descrever eapresentar as regras de negócio, enquanto. A utilização do paradigma relacional napersistência dos objetos, atividade importante para definir a base de dados de sistemas queutilizam o paradigma orientado a objeto no seu desenvolvimento.
    • 31 A transformação de uma classe em uma tabela e seus respectivos relacionamentos eatributos em chaves primárias e chaves estrangeiras define, com mais precisão, questõesrelacionadas à performance no acesso aos dados (não fazer um-para-um). O relacionamentoum-para-um, possui algumas desvantagens:1º são mais tabelas no Banco de Dados (mais tabelas para manter os relacionamentos);2º o tempo de leitura e escrita de dados será maior usando esta técnica porque varias tabelasserão acessadas. Neste caso, ceve existir a preocupação em atualizar e manipular as classesde nível superior na hierarquias profundas, são requeridos múltiplos joins para recuperar asinformações básicas do objeto. Resumindo, o mapeamento OO-ER é importante para que dois mundosconsolidados (OO – desenvolvimento e ER – base de dados) possam convergir em umaúnica solução. O objetivo principal do componente é fazer o mapeamento objeto-relacionalutilizando como entrada um arquivo XMI que é o padrão entre intercambio de dadosutilizado hoje, e gerando como saída um arquivo .sql para utilização no banco de dados. 3.3.1. Mapeamento básico Cada classe do modelo será transformada em uma tabela do modelo relacional e,todos os seus atributos, serão representados por todas as colunas da tabelas. A Figura 1apresenta um exemplo de mapeamento básico.A chave primária é definida através da utilização de Object Identification (OID).
    • 32 FIGURA 1 – Mapeamento Básico Geração das Primary Keys (OID): Toda a classe transformada m tabela tem umidentificador próprio: o seu OID. O qual facilita o relacionamento entre as tabelas, e comisso, as consultas na maioria dos casos se tornam mais eficientes. 3.3.2. Mapeamento de relacionamentos • Um-para-um - O mapeamento de relacionamentos um-para-um foi implementado no componente utilizando a chave primária da tabela relacionada como chave estrangeira. A figura 2 apresenta um exemplo de mapeamento um-para-um. - Coloca-se a chave primaria de uma tabela como chave estrangeira na outra tabela, independentemente do lado do relacionamento. FIGURA 2 – Mapeamento de relacionamentos (um-para-um) • Um-para-muitos
    • 33 - O mapeamento de relacionamentos um-para-muitos foi implementado no componente utilizando a chave primária da tabela relacionada como chave estrangeira da tabela referenciada. A figura 3 apresenta um exemplo de mapeamento um-para-muitos. - Coloca-se a chave primária de uma tabela como chave na outra tabela, no lado do muitos no relacionamento. FIGURA 3 – Mapeamento de relacionamentos (um-para-muitos)• Muitos-para-muitos - O mapeamento de relacionamento muitos-para-muitos foi implementado no componente utilizando uma tabela associativa. A figura 4 apresenta um exemplo de mapeamento muitos-para-muitos. - Cria-se uma terceira tabela que possui as chaves primárias das duas tabelas relacionadas, como chaves estrangeiras na tabela associativa. O nome da nova tabela é a junção dos nomes das tabelas relacionadas.
    • 34 FIGURA 4 – Mapeamento de relacionamentos (muitos-para-muitos) 3.3.3. Generalização A generalização pode ser mapeada de três formas: uma tabela para toda hierarquia,uma tabela por classe concreta e uma tabela por classe. O componente contempla as trêsformas de mapeamento. Previamente pode-se definir um mapeamento padrão para ageneralização (uso do properties) ou através da escolha, pelo usuário, em tempo deexecução. As três formas são: • Uma tabela para toda hierarquia: a tabela pai herda os atributos das tabelas filhas, e permanece o nome da tabela pai, conforme apresenta a figura 5;
    • 35 FIGURA 5 – Uma tabela para toda hierarquia• Uma tabela por classe concreta: as tabelas filhas herdam os atributos da tabela pai e permanecem com os seus nomes. A tabela pai é excluída, conforme apresentado na figura 6; FIGURA 6 – Uma tabela por classe concreta• Uma tabela por classe: para cada classe se gera uma tabela com os seus respectivos atributos, transformados em colunas e, a herança é representada com um relacionamento um-para-um entre o pai e seus filhos. Conforme apresentado na figura 7.
    • 36FIGURA 7 – Uma tabela por classe
    • 37 3.4. REPRESENTAÇÃO DE UM ESQUEMA RELACIONAL Para que possamos aplicar as regras de mapeamento, consideramos que as relaçõesno esquema relacional de origem estão no mínimo na 2ª forma normal, ou seja, as relaçõespodem conter dependência funcionais transitivas, mas não dependências parciais.Consideramos também que, são conhecidas as chaves primárias e estrangeiras das relaçõesque compõe o esquema relacional de origem. Em relação ao particionamento horizontal de tabelas, consideramos que se talparticionamento existe no esquema relacional de origem, isto foi feito devido á decisão deprojeto. Por não conhecemos o motivo de tal decisão, estabelecemos que: se duas tabelas Ae B são equivalentes, mas são tratadas como tabelas diferentes devido ao particionamentohorizontal, então estas tabelas continuando sendo tratadas como distintas no esquemaobjeto-relacional, observamos que, não estamos considerando o problema de performancedurante o mapeamento, uma vez que a tecnologia objeto-relacional ainda é recente, e não sepode afirmar, deste ponto de vista, qual a melhor estrutura para modelar os dados, diantedas diversas possibilidades oferecidas. Entretanto, procuramos fazer o mapeamentooferecendo uma melhor modelagem do ponto de vista de compreensão do esquema. Ainda com o objetivo de minimizar as “falhas” de projeto no esquema relacional deentrada, definimos, a seguir, um procedimento de pré-processamento deste esquema,descrito por;1. Sejam as relações R1 e R2. Se a chave primária de R1 é também uma chave estrangeiraque referencia a chave primária de R2 e a chave primária de R2 é também uma chaveestrangeira que referencia a chave primária de R1, então dizemos que as relações R1 e R2estão particionadas verticalmente. Neste caso, consideramos que as relações R1 e R2representam uma única relação (R3), cujos atributos dão dados pela união dos atributos deR1 e R2. A chave primária de R3 é a mesma de R1 ( que é a mesma chave primária de R2).Consideramos também, que todas as restrições definidas sobre R1 e R2, tornam-se
    • 38restrições sobre R3, exceto as restrições de chave estrangeira de R1 para R2 e vice-versa. Arelação R3 é então definida: R3 (A, B, C, D, E). A opção de “unir” tabelas particionadas verticalmente deve-se ao seguinte fato: se,aplicando as regras de mapeamento tais tabelas fossem mapeadas em tabelas de objetosdistintas, que possuem em identificadores únicos. Desta forma, mesmo que dois objetospossuem a mesma chave-primária, mas em tabelas distintas, então estes objetos possuemOIds diferentes. Conforme definido anteriormente, consideramos que as relações do esquemarelacional de entrada podem estar na 2ª forma normal. Desta forma, utilizamos o processodescrito para relações, de tal forma que se na 3ª forma normal. 3.4.1. Algumas regras para mapeamento As regras listadas a seguir, para mapear um esquema relacional em objeto-relacional, são baseadas em um conjunto trabalho, com algumas adaptações para adequar omodelo objeto-relacional descrito. A maioria destes trabalhos tratam do mapeamento paraestruturas orientadas a objetos.Regra T1: Toda tabela em um esquema relacional que tem somente um atributo na chaveprimária correspondente a uma tabela de objeto-relacional. Os atributos da tabela relacionaltornam-se atributos do tipo de dados estruturados que definem a tabela de objetos.Regra T2: Se a chave primária de uma tabela no esquema relacional tem mais que umatributo, e além disso, a tabela possua outros atributos que não pertençam à chave primária,então esta tabela relacional corresponde a uma tabela de objetos no esquema objeto-relacional. Os atributos de chave primária que representam chaves estrangeiras, devem sermapeados como uma referência ao tipo que define a estrutura de tabelas referenciada pelachave estrangeira.
    • 39Regra T3: Toda tabela em um esquema relacional, cuja chave primária é composta por maisde um atributo, e todos eles representam chaves estrangeiras. Esta associação érepresentada no esquema objeto-relacional através de tabelas aninhadas.Regra T4: Toda tabela que possui atributos de chave estrangeira que não fazem parte dachave-primária, estabelece uma associação entre esta tabela e a cada tabela referenciada porchaves estrangeiras. Esta associação é representada no esquema objeto-relacional através dereferências (tipo de dados ref.).Regra T5: Todo par de tabelas R1 e R2 que têm as mesmas chaves primárias podem serenvolvidos em um relacionamento de herança. O relacionamento R1 “ é um “ R2 existe se achave primária de R1 é também a chave estrangeira que refere a tabela R2.Regra T6: Quando um relacionamento de herança esta embutido em uma única tabela , énecessário extrair regras do banco de dados de uma maneira não convencional. Existemvários algoritmos que podem identificar tais regras, denominadas “strong rules” em bancode dados relacionais. Usando-se algum deste algoritmo, pode-se identificar as condiçõesque são estabelecidas para que um atributo, ou conjunto de atributos, possua valor nulo.Identificadas estas regras, podem-se extrair da tabela os relacionamentos de herança nelaembutidos. Utilizamos o algoritmo descrito para determinar relacionamento de herança, emum esquema relacional.Regra T7: Seja R uma tabela cuja chave primária tem mais que um atributo e no mínimoum deles não é chave estrangeira, e além disso, R não possui outros atributos que nãopertençam à chave primária. Deve-se então acrescentar um atributo na tabela referenciadapela chave primária, cujo domínio é um tipo coleção formado pelos atributos de tabelas,exceto o atributo de chave estrangeira.
    • 40 4. FERRAMENTAS DE MAPEAMENTO OBJETO RELACIONAL 4.1. FUNCIONALIDADES ESSENCIAIS DE UMA FERRAMENTA DEMAPEAMENTO OBJETO/RELACIONAL Já existem hoje no mercado algumas ferramentas capazes de realizar mapeamentoentre objeto e registros de tabelas de banco de dados relacionais, fazendo com queoperações básicas de cadastro como armazenamento, atualizações, exclusão e consultaspossam ser realizadas naturalmente sobre objeto e reflitam por fim em SQL que serãointerpretados pelos bancos relacionais. Produtos que realizam mapeamento objeto – relacional integram as capacidades daslinguagens de programação orientadas a objeto com sistemas de gerenciamento de bancosrelacionais, como Oracle, DB2, Sysbase, e outros. Produtos que realizam mapeamentoobjeto-relacional são projetados para funcionar bem como linguagens de programaçãoorientadas a objetos. A definição de correspondência entre elementos modelados em objeto e elementosno modelo relacional precisa ser de fáceis configurações. Um grande numero de soluçõesusa arquivos de configurações XML. Um editor gráfico para edição destes arquivosconsiste em uma vantagem extra e terá melhor preferência pela equipe projetista desoftware para momento de realizar-se uma integração da ferramenta ao ambiente dedesenvolvimento. Ferramentas de mapeamento podem ser mais ou menos genéricas e sua capacidadede adaptar-se aos recursos existentes é um importante motivo de escolha. Buscarinformações armazenadas em banco de dados relacionais pode prover muita complexidadese a ferramenta de mapeamento por em uso controle de restrições de integridade sobre omodelo relacional usado. A ferramenta deve prover funcionalidade de pesquisa, de montagem de objeto e deatualizações. Estes mecanismos precisam gerenciar corretamente quaisquer problemas detransações e adaptar-se a arquitetura do sistema de informações ao qual se destina, mesmoque seja usado um servidor de aplicação.
    • 41 A descrição dos tipos de dados varia de um modelo para o outro. A ferramenta demapeamento deve estar apta a diferenciar os tipos de dados e propor correspondência nomodelo relacional do banco de dados utilizados. A partir do momento em que uma empresa desenvolvedora de software opta por umaferramenta de mapeamento objeto/relacional ela geralmente tem como objetivo conseguiras seguintes vantagens no seu processo de engenharia de software: • Melhorar a manutenibilidade de código. O código relacionado a persistência esta embutido em um modulo especifico e não é modificado durante os vários ciclos de vida do desenvolvimento; • O tamanho de código médio seja reduzido uma vez que o código relacionado a persistência é inteiramente genérico e não esteja distribuído por toda a aplicação • O trabalho do(a) desenvolvedor(a) seja facilitado e reduzido, uma vez que ele não tenha mais que com problemas de persistência e possa concentrar-se em resolver problemas de persistência e possa concentrar-se em resolver problemas de regras de negócios; • Aumentar a portabilidade da aplicação: numerosos frameworks de mapeamento objeto/relacional habilitam o uso da maioria dos bancos de dados relacionais existentes no mercado para serem usados transparentemente;A tabela abaixo exibe uma lista com os principais itens que devem ser verificados aoadquirir uma ferramenta de mapeamento objeto/relacional;Características DescriçãoHerança A ferramenta de desenvolvimento deve ser hábil a projetar um modelo de herança de objetos via relacionamento de tabelas em um banco de dados relacional.Representar relacionamento entre objetos (1-1, 1-M, M-M) Deve saber como projetar relacionamento entre objetos em bancos relacionais.Número de BDs Relacionais suportados Possui suporte aos principais BDs. Relacionais (DB2, Oracle, Informix, MSSQLServer, entre outros)Mecanismos de otimização de performance Quais as funcionalidades para otimizar a performance da ferramentas? Instanciação parcial de objetos, cachê em memória para leitura, etc.
    • 42Transações Simples A ferramenta suporta o modelo transacional dos BDs Relacionais?Suporte e transações aninhadas A ferramenta suporta o modelo de transações aninhadas BDs Relacionais?4.2. TIPOS DE FERRAMENTAS 4.2.1. Hibernate É um dos mais bem sucedidos projetos Open Source desenvolvido em Java. Suafacilidade de uso, abstração e transparência fizeram dele quase um padrão em frameworksde mapeamento objeto-relacional. Embora sua documentação seja rica e extensa, a falta deexemplos e dicas em português muitas vezes dificulta a sua adoção por parte dedesenvolvedores brasileiros. O Hibernate não trata apenas do mapeamento de classes Javaem tabelas de banco de dados (e tipos de dados Java em tipo de dados SQL), masdisponibiliza também um poderoso mecanismo de consulta de dados que pode reduzirsignificamente o tempo de desenvolvimento. O Hibernate objetiva “liberar” odesenvolvedor em 95% das tarefas comum relacionadas à programação de persistência dedados. O Hibernate disponibiliza um poderoso framework para persistência objeto-relacional, de fácil manuseio e alto desempenho. O Hibernate provê suporte para coleçõese relacionamentos entre objetos, assim como herança. polimorfismo e composições. Eletambém tem um rica linguagem de consulta orientada a objetos, o HQL ( Hibernate QueryLanguage) para recuperação de objetos de banco de dados, uma camada de cachê eficientee suporte para Java Management Extensions (JMX). O Hibernate possui uma comunidade ativa de usuários que ajuda a prover suporte eferramentas para extensão. È distribuído de acordo com a Lesser GNU Public License(LGPL), portanto pode ser usado tanto em explicações de código aberto como comerciais.Suporta um grande numero de banco de dados, incluindo Oracle e DB2, assim como bancode dados livres tais como de dados, PostgreSQL e MySQL, permitindo a utilização demeios nativos para a geração de chaves primarias e pessimistic locking além de resolverproblemas como pool de conexões e configurações de datasources.Arquitetura
    • 43 Uma visão de alto nível da arquitetura do Hibernate: Figura 8: Uma visão simplista do Hibernate Esta figura mostra o Hibernate usando o banco de dados e a configuraçãode dados para disponibilizar serviço de persistência (e objetos persistentes) para aaplicação. Dependendo da complexidade do projeto, um maior número de APIs e componentessão utilizados pelo Hibernate. A figura abaixo exibe uma visão mais detalhada daarquitetura: Figura 9: Componentes do Hibernate
    • 44De acordo com a especificação do Hibernate, estes componentes são definidos da seguinteforma:• SessionFactory (net. sf. hibernate. SessionFactory) Armazena os mapeamentos econfigurações compiladas para um banco de dados. É uma fábrica de objetos Session eque provê conexões através do ConnectionProvider. Este objeto é imutável e threadsafe(pode ser acessado por múltiplas threads sem perigo de inconsistência).• Session (net. sf. Hibernate .Session) Um objeto que representa o "diálogo" entre aaplicação e a persistência (banco de dados), encapsulando uma conexão JDBC emanipulado por somente uma thread. Este objeto controla um cache dos objetospersistentes. Os Session não devem durar toda a execução da aplicação, ou seja, sãoobjetos de "vida curta".• Persistent Objects and Collections Objetos manipulados por somente uma threadque contém as informações persistentes e regras de negócio. Devem ser JavaBeans(possuir m construtor sem parâmetros e métodos get/set para os atributos persistidos).Eles só podem estar associados à exatamente uma Session. Assim que o Session éfinalizado, estes objetos são liberados para serem usados em qualquer camada daaplicação.• Transient Objects and CollectionsInstâncias de classes persistentes que não estão atualmente associadas a um Session.Podem ter sido instanciados pela aplicação mas ainda não persistidos, ou eles podem tersido instanciados por um Session fechado.• Transaction (net.sf.hibernate.Transaction) Objeto usado pela aplicação paraespecificar unidades atômicas de acesso ao banco de dados. Não deve ser manipuladopor múltiplas threads. Abstrai a aplicação dos detalhes das transações JDBC, JTA ouCORBA. Em alguns casos um Session pode manipular vários Transactions.
    • 45• ConnectionProvider (net.sf.hibernate.connection.ConnectionProvider) Uma fábricapara (e pool de) conexões JDBC. Abstrai a aplicação dos detalhes do Datasource ouDriverManager. Não exposto à aplicação, mas pode ser estendido/implementado pelodesenvolvedor.• TransactionFactory (net.sf.hibernate.TransactionFactory)Uma fábrica para instâncias deTransaction. Não exposto à aplicação, mas pode ser estendido/implementado pelodesenvolvedor.4.2.2. Instalação e Configuração A última versão Hibernate pode ser copiada dositeoficial(http://www.hibernate.org). A instalação é simples, bastando descompactar oarquivo .zip. O diretório criado contém o JAR núcleo do Hibernate (hibernate2.jar). Também existe um subdiretório chamado lib onde ficam os JARs das outrasAPIs utilizadas pelo framework.Esses arquivos JARs devem ser referenciados no classpath da aplicação. É tambémnecessário que a classe de driver do seu banco de dados esteja no classpath. O Hibernate foi desenvolvido para operar em vários ambientes diferentes. Porisso, existe um grande número de parâmetros de configuração. Por outro lado, agrande maioria dos parâmetros tem valor padrão e, além disso, o Hibernate é distribuídocom um arquivo chamado hibernate.properties que mostra as várias opções disponíveis.Você apenas precisa colocar esse arquivo no classpath e customizá-lo.Configurando o SessionFactory A tabela abaixo mostra os parâmetros mais importantes para configuração daconexão JDBC (com banco de dados):
    • 46 Tabela 2: Parâmetros principais para configuração da conexão JDBC O Hibernate possui ainda uma série de parâmetros que definem seu comportamentoem tempo de execução, como por exemplo: Tabela 3: Parâmetros que definem comportamento em tempo de execução O Hibernate trabalha com dialetos para um grande número de bancos de dados, taiscomo: DB2, MySQL, Oracle, Sybase, Progress, PostgreSQL, Microsoft SQL Server,Ingres, Informix entre outros. Todos estes parâmetros são usados na configuração inicial. A partir deles, é criado umobjeto da classe SessionFactory. Este objeto contém todas as informações passadas naconfiguração. Quando criado, o SessionFactory carrega e verifica todas as configurações.Esta operação consome mais tempo do Hibernate e por isso é recomendável criar esteobjeto somente uma vez e utilizá-lo durante toda execução da aplicação. O Hibernatepermite que sejam criados mais de um SessionFactory, mas isso só deve ser feito se houvernecessidade de acesso a mais de um banco de dados. Existem duas formas de informar aoSessionFactory as configurações do Hibernate:4.2.3. Configuração através do objeto Configuration A configuração pode ser feita através da classe Configuration(net.sf.hibernate.cfg.Configuration). Os objetos desta classe podem ser instanciados deforma direta. Configuration deve receber as configurações gerais através da classeProperties e também os mapeamentos Objeto/Relacional (ORM). Na tabela 4 um exemplo de como criar um SessionFactory através do objetoConfiguration: Tabela Exemplo 4: Criando um SessionFactory através do objeto Configuration
    • 474.2.4. Mapeamento O/R Básico O Hibernate usa arquivos XML para mapear os atributos das classes em campos dastabelas. Qualquer classe pode ser mapeada desde que seja um Bean, ou seja, possua umconstrutor sem parâmetros e os atributos mapeados possuam métodos get e set. A presençade um atributo de identificação (chave primária) é altamente recomendada, mas não éobrigatória, caso contrário diversas funcionalidades não estarão disponíveis. Não énecessário nenhum tipo de especialização (herança) ou realização de interface para que umaclasse seja persistida pelo Hibernate. Isto quer dizer que o Hibernate pode persistir objetosPOJO (Plain Old Java Object). Abaixo o exemplo de uma classe que poderia ser persistida: Tabela Exemplo 5: Classe candidata à persistênciaAbaixo, a implementação da classe do diagrama UML acima. Tabela Exemplo 6: Implementação da classe Pessoa Segue a declaração de criação da tabela que armazena a classe acima.
    • 48 Aconselha-se escolher identificadores de tipos de grande capacidade (comoBIGINT) para que um grande número de registros possa ser armazenado. Nota-se o atributoAUTO_INCREMENT para a chave primária idPessoa, logo em seguida fica claro o porquêdisso. Tabela Exemplo 7: Declaração de criação da tabela que armazena a classe PessoaPara mapear uma classe numa tabela: Tabela Exemplo 8: Mapeando a classe Pessoa numa tabela Os arquivos de mapeamento são fáceis de configurar e divididos de maneirabastante intuitiva. Além disso, a maioria dos parâmetros existentes possui valores padrão.Este exemplo inicial exibe apenas os parâmetros obrigatórios (com exceção do elemento<id>). É obrigatório especificar o nome da classe e a tabela com a qual está associada. Oelemento <id> indica qual é o identificador do objeto e como ele é criado e obtido. Caso eleseja omitido, o Hibernate considera que a classe não possui identificador. O atributo nameindica que atributo da classe será usado como identificador. O elemento generator informacomo serão gerados os identificadores dos novos elementos. Segue alguns dos tipos degeradores existentes no Hibernate:
    • 49 Tabela 9: Tipo de geradores existentes no Hibernate Cada atributo da classe é mapeado através do elemento <property>. O únicoparâmetro obrigatório é o nome do atributo. O Hibernate tentará encontrar uma coluna comeste mesmo nome e definir seu tipo por reflexão. Abaixo, o mapeamento desta mesmaclasse com os parâmetros opcionais (usando o mapeamento simples para executar comoexemplo, nota-se que os nomes das colunas foram trocados). Tabela Exemplo 10: Mapeamento da classe Pessoa com parâmetros opcionais O primeiro parâmetro a notar é column. Ele indica a coluna correspondente aoatributo da classe na tabela, caso não tenham o mesmo nome. O parâmetro type, indica o
    • 50tipo do atributo Hibernate. Abaixo a associação entre os tipos do Hibernate mais comuns,as classes wrapper Java e os tipos no banco de dados: Tabela 11: Associação entre tipos do Hibernate, classes wrapper Java e tipos no BD No mapeamento, pode ser informado na propriedade type tanto o tipo Hibernatequando a classe Java. Outra propriedade opcional importante é not-null. Ela indica que no momento da persistência de um objeto, o determinado atributopode ser nulo ou não. Caso um atributo esteja indicado como not-null=”true” e no momentodo salvamento ele esteja null, Hibernate irá lançar uma exceção. É essencial lembrar de incluir a linha abaixo no arquivo do hibernate.cfg.xml. Elaindica que este mapeamento deve estar contemplado no SessionFactory. Tabela Exemplo 12: Mapeamento contemplado no SessionFactory
    • 514.3. Hibernate / Persistência Hibernate é um mecanismo simples e poderoso que permite a persistência deobjetos em banco de dados relacionais de maneira transparente para qualquer tipo deaplicação Java. Esta ferramenta, que pode ser baixada gratuitamente da Internet através doendereço http://hibernate.sf.net/, possibilita que os objetos possam ser gravados erecuperados a partir de um banco de dados sem que o desenvolvedor tenha que sepreocupar com muitos detalhes. Não há necessidade de se implementar mapeamentos hard-coded no código Java. O Hibernate resolve problemas como pool de conexões econfigurações de Datasources. Em linhas gerais, a codificação de um sistema pode ser dividida em duas partes:regras de negócio e serviços de infra-estrutura. Regras de negócio, como o próprio nomediz, estão relacionadas ao negócio com o qual o sistema visa trabalhar. Já os serviços deinfra-estrutura estão relacionados à segurança, cache, transação, serviços de nomes, etc. Aidéia do Hibernate é permitir que o desenvolvedor mantenha seu foco sobre as regras denegócio, liberando-o de parte das tarefas de infra-estrutura. O Hibernate suporta alguns dos principais bancos de dados relacionais disponíveisno mercado, permitindo a utilização de meios nativos para geração de chaves primárias epessimistic locking. O hibernate trabalha com os bancos de dados através de dialetos,conforme a tabela 1.Banco de dados DialetoDB2 cirus.hibernate.sql.DB2DialectMySQL cirus.hibernate.sql.MySqlDialectSAPDB cirus.hibernate.sql.SAPDBDialectOracle cirus.hibernate.sql.OracleDialectSybase cirus.hibernate.sql.SybaseDialectProgress cirus.hibernate.sql.ProgressDialectMcKoiSQL cirus.hibernate.sql.McKoiDialectInterbase/Firebird cirus.hibernate.sql.InterbaseDialectPointbase cirus.hibernate.sql.PointbaseDialectPostgreSQL cirus.hibernate.sql.PostgreSQLDialectHypersonicSQL cirus.hibernate.sql.HSQLDialectMicrosoft SQL Server cirus.hibernate.sql.SybaseDialect Tabela 13 – Bancos de dados suportados pelo Hibernate
    • 52Fonte: www.mundojava.com.br O desenvolvimento usando Hibernate é um processo que pode ser dividido em cincoetapas. O primeiro passo é a construção do banco de dados com o qual a aplicação irátrabalhar, ou seja, criar as tabelas onde os objetos serão persistidos. Este banco de dados,com suas entidades, atributos e relacionamentos, poderá ser criado de forma tradicional ou,a critério do usuário, poderá ser utilizada a ferramenta SchemaExport que acompanha oHibernate, Esta ferramenta gera o esquema de banco de dados baseado no relacionamentoentre os objetos que se quer persistir. O segundo passo é criação dos objetos cujos estadosvão ser persistidos, isto é, a construção de classes (beans) para cada entidade do banco dedados. Estas classes devem ser construídas seguindo o modelo JavaBeans, com métodos gete set para manipulação dos atributos. Neste ponto, o Hibernate difere-se de outrosmecanismos de persistências como o JDO, visto que os beans utilizados pelo Hibernate nãonecessitam estender superclasses ou implementar interfaces. É necessária a implementaçãode um construtor default (construtor sem parâmetros) para todas as classes persistentes. OHibernate faz a instanciação de objetos e o acesso às suas propriedades através de reflexão,assim métodos de acesso e construtores não necessitam ser declarados como públicos.Adicionalmente, deve ser criada uma propriedade “chave-primária”, que fará às vezes deuma primary key, através da qual um objeto será unicamente identificado. Esta propriedade,não obrigatória, pode ser do tipo primitivo int, long, char ou mesmo uma String. Após a criação das tabelas e dos beans é necessário criar meta-dados de modo afornecer ao Hibernate informações sobre como relacionar os objetos com as entidades dobanco de dados. Esta é a terceira etapa, a criação de arquivos XML que relacionam aspropriedades de cada objeto aos campos das tabelas. Nestes arquivos de mapeamento deve-se informar, ainda, qual propriedade do objeto se relaciona com a chave-primária, bem comos relacionamentos entre entidades (inclusive os tipos de relacionamento: 1-1, 1-N ou N-N). A quarta etapa refere-se à criação de um arquivo contendo as propriedadesnecessárias para que o Hibernate se conecte ao banco de dados. Existe um arquivo de
    • 53configuração modelo (hibernate.properties) que poderá ser utilizado como base para que ousuário proceda à configuração. A quinta e última etapa é a criação de Data Access Objects(DAO), Tais mecanismos são design pattern úteis para separação da lógica de acesso adados da lógica de negócios da aplicação. Estas classes é que conterão os métodos deinclusão, alteração, exclusão dos objetos, etc. Em resumo, o Hibernate é uma ferramenta que permite trabalhar com persistênciasobre banco de dados, sem necessidade da inclusão de instruções SQL em meio ao códigoJava, assim como elimina a necessidade de se mapear ResultSets e implementarconfiguração de pool de conexões, etc., o que torna o código mais legível e,conseqüentemente, mais fácil de manter. Contudo a implementação não é independente dafonte de dados, visto que o Hibernate trabalha apenas com alguns dos bancos de dadosrelacionais. Por outro lado, caso a aplicação exija consultas SQL complexas, há de seconsiderar a utilização da linguagem HQL, a Query Language do Hibernate. Tabela 14 - Comparações do Hibernate com outros frameworks de persistência
    • 54 4.5. OJB O OJB (Object Relational Bridge) faz parte do projeto Jakarta, da fundação Apache,que desenvolve ferramentas de código aberto para Java. Prestes a ter sua primeira versãooficial lançada o OJB é baseado em um cerne de mapeamento objeto relacional a partir doqual várias APIs podem ser disponibilizadas. O OJB e muito flexivel na forma em que podeser usado. O desenvolvedor tem opções de 3 diferentes API:Uma API compativel com o padrao ODMG 3.0Uma API compativel com o padrão JDO da Sun (ainda incompleta).A PersistenceBroker API que server como o núcleo das demais APIs usada no OJB. Essa APIpode ser usada por qualquer tipo de aplicação.Podemos considerar OJB comparado ao Hibernate em termos de suporte aos conceitos OOe funcionalidades. O OJB apresenta as vantagens de possuir melhor suporte a distribuição(com sincronização de cachê) e ser aderente a padrões estabelecidos. O mapeamento objeto-relacional do OJB é feito através de um único arquivo XML,cujas marcações fazem parte de um DTD próprio, e para o mapeamento de hierarquias declasse são permitidos todos os tipos de particionamento (tipado, vertical e horizontal).Inicialmente foi tentado o mapeamento sobre a mesma base de dados utilizada nos testes doHibernate, com particionamento vertical. Contudo, testes preliminares detectaram algumasfalhas do OJB na execução deste tipo de mapeamento. Devido a este problema o programade carga utilizado para a geração da base de dados de testes do Hibernate foi modificadopara que também fossem geradas na base tabelas que suportassem o particionamentohorizontal das classes. A base de dados passou então a ser usada tanto pelo Hibernate comopelo OJB, porém com mapeamentos sobre conjuntos diferentes de tabelas. A implementação do modelo de classes, em comparação com o Hibernate, foi umpouco mais complicada. No caso do OJB também foram utilizadas classes simples, apenascom atributos protegidos e métodos de acesso e modificação. Contudo, por uma restrição do OJB, para que fosse possível o uso de suafuncionalidade de carga de objetos sob demanda foi necessário a definição de interfaces, efazer que as classes as implementassem, também, de forma semelhante ao caso doHibernate, não foi possível declarar algumas das classes como abstratas.
    • 55Cliente CLIENT APPLICATIONOJB LayersBackends Componentes do OJB● O JDO Suporta:– Hypersonic SQL– Lutris InstantDB– IBM DB2– Oracle– MS Access– MS SQL Server 2000-Instalar/Configurar
    • 56 Toda a funcionalidade da versao 1.0 ja esta presente na versao atual. Baixe a versaobinaria do OJB, a menos que você queira dar uma olhada na fonte.O arquivo que esta disponível para download no web site tem valioas arquivos p/configurar e criar os tutoriais, e algumas aplicações dentro do OJB. Vou descrever todos osarquivos necessários para uma aplicação OJB rodar.-ArquivosEsses são os arquivos JAR que você precisa no classpath de uma aplicação OJB:antlr.jarcommons-collections-2.0.jarcommons-dbcp.jarcommons-lang-1.0-mod.jarcommons-pool.jardb-ojb-1.0.rc2.jarjta-spec1_0_1.jar O arquivo OJB.properties contem configurações especificas de como o ambiente OJBdeve rodar. Nele você configura que pool de conexões quer usar, qual a política de cachê aser usada, em que arquivo esta a configuração do banco de dados (chamada de repositório),e varias outras opções. Em geral, não se precisa mudar nada nesse arquivo, mas, ter umaboa noção e importante p/ saber que partes do OJB você pode configurar. Chegou a vez do arquivo mais importante, onde se configura a aplicação que estasendo desenvolvida, e o repository.xml, ele contem chamada a outros arquivos XML,sendo:-repository_database.xml, contem a configuração do acesso ao banco de dados. Aqui, vocêespecifica o banco, usuário, senha, enfim, as configurações normais de uma conexão JDBC.Também se pode setar opções do pool de conexões, como a quantidade máxima e inicial deconexões a serem abertas.
    • 57-repository_user.xml, contem o mapeamento das classes Java as tabelas no banco de dados.Para cada classe, você deve criar uma definição como esta a seguir: Code: <class-descriptor class="br.com.javafree.ojb.Produto" table="jf_produto" > <field-descriptor id="1" name="produtoId" column="produto_id" jdbc-type="INTEGER" primarykey="true" autoincrement="true" /> <field-descriptor id="2" name="descricao" column="produto_desc" jdbc-type="VARCHAR" /> </class-descriptor> Nesse exemplo, temos uma classe br.com.javafree.ojb.Produto que corresponde a tabelajf_produto, os campos produto_id e producto_desc correspondem as propriedades id edescrição na classe. A fase de construção do repository_user.xml e um pouco trabalhosa, mas,os desenvolvedores do OJB esta criando uma aplicação para criar o XML quando vocêindica a base de dados, o que agilizara muito esse processo. Chegou a vez do código, vou mostrar treis exemplos de operação no banco de dados,uma parte do código é sempre necessária no uso do OJB, que é a chamado aoPersistenceBroker, classe responsável pela operações no banco de dados.Os pacotes org.apache.ojb.broker e org.apache.ojb.broker.query tem que ser importados.SELECIONAR TODOS OS REGISTROS E IMPRIMIR Code: PersistenceBroker broker = null; // indicamos que classe queremos buscar no banco de dados Query query = new QueryByCriteria(br.com.javafree.ojb.Produto.class, null); try { broker = PersistenceBrokerFactory.defaultPersistenceBroker(); // pedimos ao broker p/ gerar uma colecao como os dados do BD Collection allProducts = broker.getCollectionByQuery(query); // simplesmente imprimos as propriedades dos objetos retornados java.util.Iterator iter = allProducts.iterator(); while (iter.hasNext()) { br.com.javafree.ojb.Produto produto = (br.com.javafree.ojb.Produto)iter.next(); out.println(produto.getId() + " - " + produto.getDescricao() + "<br>"); } } catch (Throwable t) {
    • 58 t.printStackTrace(); }INSERIR UM NOVO REGISTRO Code: // try to save to DB using OJB br.com.javafree.ojb.Produto novoProduto = new br.com.javafree.ojb.Produto(); novoProduto.setDescricao("Livro de Java "); // ojb PersistenceBroker broker = null; try { broker = PersistenceBrokerFactory.defaultPersistenceBroker(); broker.store(novoProduto); } catch(Exception e) { e.printStackTrace(); } Para inserir um registro, e mais simples ainda, basta chamar o método store() doPersistenceBroker que o OJB se encarrega de armazenar os dados no BD de acordo com oque definido no arquivo repository_user.xml. Percebam que, pelo fato de termos definido ocampo produto_id como auto incremento, o próprio OJB se encarrega em calcular essavalor usando a configuração no arquivo OJB.properties. Esse recurso (auto-incremento)exige o uso de uma tabela interna do OJB, que pode ser criada com o seguinte comandoSQL, no meu caso, p/ MySQL: Code: CREATE TABLE `ojb_hl_seq` ( `TABLENAME` varchar(175) NOT NULL default , `FIELDNAME` varchar(70) NOT NULL default , `MAX_KEY` int(11) default NULL, `GRAB_SIZE` int(11) default NULL, PRIMARY KEY (`TABLENAME`,`FIELDNAME`) ) 5. ESTUDO DE CASO 5.1. DIAGRAMA DE CLASSE “BIBLIOTECA MÚSICA” Na tabela 15 estão as classe que vão ser utilizada no mapeamento dasferramentas estudadas.
    • 59 TABELA 15 Diagrama de Classe “Biblioteca Música”; 5.1.2. Modelo de Mapeamento Hibernate:Definição da classe Artista;Import java.uitl.Set;Import java.util.HashSet;Public class Artista{ private Long id; private String nome; private Set cds = new HashSet();}Mapeamento da classe Artista<?xml version”1.0” encoding= “UTF-8”?> // cabeçalho do xml<!DOCTYPE hibernate-mapping PUBLIC // cabeçalho do hibernate “-//Hibernate/Hibernate Mapping DTD 2.0//EN” “http://hibernate.sourceforge.net/hibernate.mapping-2.0.dtd”><hibernate-mapping> <class name= “Artista” table=”artista”> <id name= “id” column=“id” type=“long” unsaved-value= “null”> <generator class=“native”/><id>
    • 60<property Name= “nome” Type= “java.lang.String” Column= “nome” Length= “255” Not-null= “true”/><set name= “cds”lazy= “true” inverse= “true”> <key column= “artista_id”/> <one-to-many class= “Cd”/></set></class></hibernate-mapping>Definição da classe Cd;Import java.uitl.Set;Import java.util.HashSet;Public class Cd{ private Long id; private String titulo; private Capa capa; private Artista artista; private Set cds = new HashSet();}Mapeamento da classe Cd;<?xml version”1.0” encoding= “UTF-8”?> // cabeçalho do xml<!DOCTYPE hibernate-mapping PUBLIC // cabeçalho do hibernate “-//Hibernate/Hibernate Mapping DTD 2.0//EN” “http://hibernate.sourceforge.net/hibernate.mapping-2.0.dtd”><hibernate-mapping> <class name= “Cd” table=”cd”> <id name= “id” column=“id” type=“long” unsaved-value= “null”> <generator class=“native”/><id><property Name= “titulo”
    • 61 Type= “java.lang.String” Column= “titulo” Length= “255” Not-null= “true”/><set name= “musicas”lazy= “true” inverse= “true”> <key column= “cd_id”/> <one-to-many class= “Musica”/></set><many-to-one name=”artista” column= “artista_id” not-null= “true”><one-to-one name= “capa” class= “Capa”/></class></hibernate-mapping>Definição da classe Capa;Import java.uitl.Set;Import java.util.HashSet;Public class Capa{ private Long id; private String imagem; private Cd cd;}Mapeamento da classe Capa;<?xml version”1.0” encoding= “UTF-8”?> // cabeçalho do xml<!DOCTYPE hibernate-mapping PUBLIC // cabeçalho do hibernate “-//Hibernate/Hibernate Mapping DTD 2.0//EN” “http://hibernate.sourceforge.net/hibernate.mapping-2.0.dtd”><hibernate-mapping> <class name= “Capa” table=”capa”> <id name= “id” column=“id” type=“long” unsaved-value= “null”> <generator class=“native”/><id><property Name= “imagem” Type= “java.lang.String”
    • 62 Column= “imagem” Length= “255” Not-null= “true”/></class></hibernate-mapping>Definição da classe Musica;Public class Musica{ private Long id; private String titulo; private Cd cd;}Mapeamento da classe Musica;<?xml version”1.0” encoding= “UTF-8”?> // cabeçalho do xml<!DOCTYPE hibernate-mapping PUBLIC // cabeçalho do hibernate “-//Hibernate/Hibernate Mapping DTD 2.0//EN” “http://hibernate.sourceforge.net/hibernate.mapping-2.0.dtd”><hibernate-mapping> <class name= “Musica” table=”musica”> <id name= “id” column=“id” type=“long” unsaved-value= “null”> <generator class=“native”/><id><property Name= “titulo” Type= “java.lang.String” Column= “titulo” Length= “255” Not-null= “true”/><many-to-one name=”cd” column= “cd_id” not-null= “true”></class></hibernate-mapping>
    • 63 5.2. Modelo de mapeamento OJBDefinição da classe Artista;Import java.uitl.Set;Import java.util.HashSet;Public class Artista{ private Long id; private String nome; private Set cds = new HashSet();}Mapeamento da classe Artista<class-descriptorClass=”br.com.javafree.ojb.produto”Table=”jf_produto”> <class name= “Artista” table=”artista”> <id name= “id” column=“id” type=“long” unsaved-value= “null”> <generator class=“native”/><id><field-descriptorid=”1” Name= “nome” Type= “java.lang.String” Column= “nome” Length= “255” Not-null= “true”/><class-descriptor>Definição da classe Cd;Import java.uitl.Set;Import java.util.HashSet;Public class Cd{ private Long id; private String titulo; private Capa capa; private Artista artista;
    • 64 private Set cds = new HashSet();}Mapeamento da classe Cd;<class-descriptorClass=”br.com.javafree.ojb.produto”Table=”jf_produto”><field-descriptorid=”1” <class name= “Cd” table=”cd”> <id name= “id” column=“id” type=“long” unsaved-value= “null”> <generator class=“native”/><id><property Name= “titulo” Type= “java.lang.String” Column= “titulo” Length= “255” Not-null= “true”/><set name= “musicas”lazy= “true” inverse= “true”> <key column= “cd_id”/> <one-to-many class= “Musica”/></set><many-to-one name=”artista” column= “artista_id” not-null= “true”><one-to-one name= “capa” class= “Capa”/>/><class-descriptor>Definição da classe Capa;Import java.uitl.Set;Import java.util.HashSet;Public class Capa{ private Long id; private String imagem; private Cd cd;}
    • 65Mapeamento da classe Capa;<class-descriptorClass=”br.com.javafree.ojb.produto”Table=”jf_produto”><field-descriptorid=”1” <class name= “Capa” table=”capa”> <id name= “id” column=“id” type=“long” unsaved-value= “null”> <generator class=“native”/><id><property Name= “imagem” Type= “java.lang.String” Column= “imagem” Length= “255” Not-null= “true”/><class-descriptor>Definição da classe Musica;Public class Musica{ private Long id; private String titulo; private Cd cd;}Mapeamento da classe Musica;<class-descriptorClass=”br.com.javafree.ojb.produto”Table=”jf_produto”><field-descriptorid=”1” <class name= “Musica” table=”musica”> <id name= “id” column=“id” type=“long” unsaved-value= “null”> <generator class=“native”/><id>
    • 66<property Name= “titulo” Type= “java.lang.String” Column= “titulo” Length= “255” Not-null= “true”/><class-descriptor> 5.3. Essas são as tabelas do SQLCREATE TABLE Cd ( ID INT NOT NULL, TITULO VARCHAR(30) NOT NULL, CAPA INT NOT NULL, ARTISTA INT NOT NULL PRIMARY KEY (ID), FOREIGN KEY (CAPA) REFERENCES Capa(ID), FOREIGN KEY (ARTISTA) REFERENCES Artista(ID));CREATE TABLE Capa ( ID INT NOT NULL, IMAGEM VARCHAR(50), CD INT NOT NULL PRIMARY KEY (ID), FOREIGN KEY (CD) REFERENCES Cd(ID));CREATE TABLE Musica ( ID INT NOT NULL, TITULO VARCHAR(30) NOT NULL, CD INT, PRIMARY KEY (ID), FOREIGN KEY (CD) REFERENCES Cd(ID));
    • 67CREATE TABLE Artista ( ID INT NOT NULL, NOME VARCHAR(30), PRIMARY KEY (ID)); 5.4. Assim seria a inserção nas tabelas uma a umaINSERT INTO Artista (ID, NOME) VALUES (55, ‘João’);INSERT INTO Musics (ID, TITULO, CD) VALUES (123654, ‘MTV AO VIVO’, 53651); 6. RESULTADOS OBTIDOS Todos os testes foram executados em um mesmo ambiente. Para a execução de cadaconsulta foi adotado o seguinte procedimento: (1) iniciar o SGBD; (2) iniciar o programa
    • 68de execução da consulta; (3) finalizar o SGBD; (4) executar a leitura de arquivos em disco,não relacionados aos testes, para invalidação de cachês e buffers do sistema operacional.Antes da execução dos testes de desempenho, porém, foi feito também um teste inicial paraque fosse comprovada a consistência de resultados entre os diversos sistemas testados. Osconteúdos dos resultados das consultas foram tomados como referência e posteriormentecomparados com os consteúdos dos resultados das consultas executadas pelo Hibernate e oOJB. O Hibernate e o OJB apresentam funcionalidades semelhantes aos resumos,chamadas de consultas escalares e consultas de relatório, respectivamente. O Hibernate e o OJB também apresentam funcionalidades para distribuição, sendo oHibernate mais restritivo e o OJB tendo suporte direto a sincronização de cachê e controlede concorrência distribuído. 6.1. Vantagens e desvantagens da utilização do mapeamento usando aferramenta HibernateUsando a ferramenta: O Hibernate torna transparente o acesso ao banco de dados, sendo que ele faz tudo sozinho, ou seja, ele salva tudo na memória e quando você termina ele salva tudo no banco. O código fica menor e mais eficiente pois o Hibernate otimiza o código. Você usa o SQL mas as tabelas são montadas pelo Hibernate. Com Hibernate você montaria os objetos mas a inserção ele pegaria cada atributo e montaria os comandos inserts sozinho.Não Usando a ferramenta: O código seria bem maior. Teria que inserir toda as classes usando o SQL sendo que eu teria que montar as tabelas sendo que o Hibernate já te entrega pronto. Todo o acesso ao banco seria manual.
    • 69 6.2. Vantagens e desvantagens da utilização do mapeamento usando aferramenta OJBUsando a ferramenta: Fácil de utilizar O código fica bem menor Ele inseri no banco de dados altomâticamenteNão Usando a ferramenta: Não tem a característica de um banco de dados robusto Por exemplo: indexs, transaccion... Não é escalavel O código ficaria bem maior A inserção ao banco de dados seria manual 7. Conclusão
    • 70 Apesar da relutância de alguns em adotar esquemas de persistência, fica evidenteque sua utilização trás um ganho considerável de tempo na implementação de um sistema eeleva a qualidade do produto final, à medida que diminui a possibilidade de erros decodificação. O fraco acoplamento entre as camadas de dados e de lógica do sistemapromovido pelas Camadas de Persistência é outro ponto que demonstra a sua utilidade.Além de fornecer um acesso mais natural aos dados, as Camadas de Persistência executamcontrole transacional, otimização de consultas e transformações automáticas de dados entreformatos distinto (tabelas relacionais para arquivos XML ou classes Java, por exemplo).Sem dúvida, as Camadas de Persistência devem funcionar como a principal ponte deligação entre sistemas Orientados a Objetos e repositórios de dados diversos: um conceitopoderoso, com implementações estáveis e comprovadamente eficientes.
    • 71 8. REFERÊNCIA BIBLIOGRÁFICAAGILE DATA. “Object-Relational Mapping – An Essay”. [Internet: http://www.agiledata.org/essays/mappingObjects.html, recuperado em 20/01/2005].AMBYSOFT. [Internet:http://www.ambysoft.com/mappingObjects.html, recuperado em 20/01/2005].DATE, C. J. “Introdução a Sistemas de Bancos de Dados”. Rio de Janeiro: Campus, 1990.HIBERNATE. [Internet: http://www.hibernate.org, recuperado em 16/02/2005].NASSU, E. A.; SETZER, W. W. “Banco de Dados Orientado a Objeto”. Editora Edgar Bkucher Ltda., 1º edição 1999.SILBERSCHATZ, A.; KORTH, H. F., SUDARSHAN, S. “Sistema de Banco de Dados”. São Paulo: Makron Books, 1999.MUNDO-OO.“Mapeando Objetos para Bancos de Dados Relacionais: técnicas e implementações.”[Internet:http://www.mundooo.com.br/php/mooartigos.php?pa=show page&pid=19, recuperado em 15/03/2005].ULBRA“Persistência de Dados”[Internet:http://www.ulbra.tche.br/~roland/tcc- gr/monografias/2003-2-tc2-Anelise_Rosa_Rodrigues.pdf, recuperado em 08/04/2005].INTERSYSTEMS.“Problemas de Impedância”[Internet:http://www.intersystems.com.br /isc/downloads/cachedoctec/ProblemadeImpedância.pdf, recuperado em 08/04/2005].JAKARTA PROJECT. “Projeto Jakarta” [Internet: http://www.jakarta.apache.org recuperado em 10/10/2005].
    • 72