1

Anderson Gomes da Silva 0205109 8 Semestre

Mapeamento Objeto-Relacional

Monografia apresentada disciplina Trabalho de Concluso do Curso de Cincias da Computao da Faculdade de Jaguarina, sob.

a orientao do Prof. Leonardo Hartleben Reinehr, como exigncia parcial para concluso do

curso de graduao.

Jaguarina

2005

2

Silva, Anderson Gomes. Estudo Comparativo de Ferramentas de Mapeamento Objeto-Relacional, Monografia defendida e aprovada na FAJ em 15 de Dezembro de 2005 pela banca examinadora constituda pelos professores:

____________________________________________________

Prof. Leonardo Hartleben Reinehr FAJ - Orientador

____________________________________________________

Prof. Odersom

____________________________________________________

Prof. Roberto Pacheco

3

Aos meus pais Vital e Maria do Carmo e irmos Helinton e Erica.

4

Agradecimentos

Primeiramente Deus pois sem ele nada possvel; Aos meus pais Vital e Maria do Carmo, por toda educao e amor que foram investidos em mim durante a minha vida; Aos meus irmo e minha namorada que me incentivaram neste trabalho; Aos meus professores, pelas conversas, conselhos e ensinamento que serviro para a vida toda; Ao meu orientador Leonardo Hartleben Reinehr, pela confiana e apoio depositados em mim; todos meus amigos: Leonardo, Michel, Robson, Juliano, pela amizade e apoio, 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, alcanar triunfos e glrias, mesmo expondo-se a derrota, do que formar fila com os pobres de esprito que nem gozam muito nem sofrem muito, porque vivem nessa penumbra cinzenta que no conhece vitria nem derrota."

(Theodore Roosevelt)

6

SILVA, Anderson Gomes. Estudo Comparativo de Ferramentas de Mapeamento Objeto-Relacional. 2005. Monografia. (Bacharelado em Cincias da Computao) Curso de Cincias da Computao da Faculdade de Jaguarina, Jaguarina.

RESUMO

Este trabalho um estudo comparativo entre as Ferramentas de Mapeamento Objeto-relacional, com enfoque ao Banco de Dados Objeto-Relacional. E tem como objetivo avaliar o estado da arte da teoria de mapeamento objeto-relacional, identificando as caractersticas e necessidades desse mecanismo, ele tambm ira mostrar os principais frameworks para mapeamento objeto-relacional, identificando as vantagens de sua utilizao, funcionalidades oferecidas e caractersticas de implementao de acordo com a teoria de mapeamento objeto-relacional.

Mostrara tambm a implementao de um estudo de caso utilizando os frameworks estudados, 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.

7

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface CASE Computer Aided Software Engineering OID Object Identification OO Orientado a Objeto OO-ER Orientado a Objeto Entidade Relacional UML Unified Modeling Language XMI XML Metadata Interchange XML eXtensible Markup Language OQL Object Query Language SGBD Sistema Gerenciador de Banco de Dados SGBDOO Sistema Gerenciador de Banco de Dados Orientado a Objeto SGBDOR Sistema Gerenciador de Banco de Dados Objeto Relacional SGBDR Sistema Gerenciador de Banco de Dados Relacionais SQL Structured Query Language ER Entidade Relacionamento

8

LISTA DE FIGURAS

FIGURA 1 Mapeamento Bsico FIGURA 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 Hierarquia FIGURA 6 Uma Tabela por Classe Concreta FIGURA 7 Uma Tabela por Classe FIGURA 8 Uma Viso Simplista do Hibernate FIGURA 9 Componentes do Hiberante

9

LISTAS DE TABELAS

TABELA 1 Comparativo entre tcnicas de mapeamento de classe TABELA 2 Parmetros principais para configurao da conexo JDBC TABELA 3 Parmetros que definem comportamentos em tempo de execuo TABELA 4 Criando um SessionFactory atravs do objeto configuration TABELA 5 Classe candidata a persistncia TABELA 6 Implementao da classe pessoa TABELA 7 Declarao de criao da tabela que armazena a classe pessoa TABELA 8 Mapeando a classe pessoa numa tabela TABELA 9 Tipos de geradores presentes no Hiberante TABELA 10 Mapeamento da classe pessoa com parmetros opcionais TABELA 11 Associao entre os tipos do Hibernate, classes Wrapper Java e tipo no BD TABELA 12 Mapeamento conteplado no SessionFactory TABELA 13 Banco de dados suportados pelo Hibernate TABELA 14 Comparaes do Hibernate com outros frameworks de persistncias TABELA 15 Diagrama de Classe Biblioteca Msica

10

SUMRIO

LISTA DE ABREVIATURA E SIGLAS......................................................................7

LISTAS DE FIGURAS..................................................................................................8 LISTAS DE TABELAS.................................................................................................9 1. INTRODUO...............................................................................11 2. REVISO BIBLIOGRFICA................................................21 3. MAPEAMENTO OBJETO RELACIONAL...................................... 39 4. FERRAMENTAS DE MAPEAMENTO OBJETO RELACIONAL..........59 5. ESTUDO DE CASO...................................................................66 6. RESULTADOS OBTIDOS.....................................................................................68 7. CONCLUSES.......................................................................................................70

8. REFERNCIA BIBLIOGRFICA.........................................................................71

11

1. INTRODUAO

Desde seu desenvolvimento at os dias atuais, bancos de dados relacionais sempre foram os mais utilizados no cenrio comercial [DATE, SILBERSCHATZ]. Por outro lado, nos ltimos anos houve uma crescente disseminao das linguagens orientadas a objeto no desenvolvimento de aplicaes. Dessa forma, hoje existe um grande nmero de aplicaes orientadas a objeto que acessam bancos de dados relacionais.

Existe uma notada incompatibilidade entre o modelo orientado a objetos e o modelo relacional [AGILE DATA], a qual dificulta a transformao dos dados armazenados em um modelo para o outro. Por isso, importante a existncia de mecanismos para realizar o mapeamento das classes do modelo orientado a objeto para tabelas do modelo relacional.

A teoria de mapeamento objeto-relacional define um conjunto de caractersticas necessrias a tais mecanismos, alm de apresentar possveis solues para os problemas de incompatibilidade entre os modelos [DATE, SILBERSCHATZ, AGILE DATA].

Os frameworks de mapeamento objeto-relacional oferecem enormes facilidades para a realizao desse tipo de mapeamento, implementando as solues indicadas na teoria de mapeamentos e permitindo que as aplicaes executem mapeamentos por meio de

configurao e definio de regras ao invs da escrita de linhas de cdigo [Hibernate]. O presente trabalho tem por objetivo mostrar as principais caractersticas de um

Mapeamento Objeto-Relacional, com enfoque em um estudo comparativo de ferramentas de mapeamento e na identificao de problemas e questes em aberto das ferramentas existentes. Para isso, ser implementado um estudo de caso usando diversas tecnologias e frameworks existentes, comparando os resultados obtidos.

12

2. REVISO BIBLIOGRFICA

2.1. BANCO DE DADOS RELACIONAIS

Um banco de dados um conjunto de informaes com uma estrutura regular. Um banco de dados normalmente, mas no necessariamente, armazenado em algum formato de mquina lido pelo computador. H uma grande variedade de banco de dados, desde

simples tabelas armazenadas em um nico arquivo at gigantescos bancos de dados com muitos milhes de registros, armazenados em salas cheias de dados rgidos. Os banco de dados caracteristicamente moderno so desenvolvidos desde os anos da dcada de 1960, um dos pioneiros neste trabalho foi Charles Bachman. Existe uma grande variedade de banco de dados, desde exemplos simples como uma simples coleo de tabelas at um modelo teoricamente definido, o relacional [AGILE DATA]. O modelo de dados lgico relacional atualmente o mais utilizado nos SGBDs comerciais. Entretanto, este modelo possui um sistema de tipos simples e restrito, o que

dificulta a descrio de algumas aplicaes atuais que necessitam tipos mais complexos e caractersticas do modelo Orientado a Objetos.

Sistemas de Banco de Dados que utilizam o modelo relacional, ou seja, SGBDRs, so tambm considerados sistemas de segunda gerao de SGBDs visto que os sistemas de Banco de Dados Hierrquicos e de Rede so considerados a primeira gerao. Assim, os sistemas de Banco de Dados Objeto Relacionais so classificados como a terceira gerao de SGBDs.

2.2. ORIENTAO A OBJETO

Orientao a objeto pode ser definida como um conjunto de disciplinas de modelagem de software que facilitam a construo sistemas complexos a partir de componentes individuais). O apelo intuitivo da orientao a objeto que ele proporciona conceitos e ferramentas para modelar e representar o mundo real. As vantagens da orientao a objeto na programao e na modelagem de dados so muitas[AGILE DATA].

13

A programao de objeto (orientada) permite uma representao mais direta do modelo do mundo real no cdigo. O resultado que a transformao radical das requisies do sistema (definido em termos de usurios) para especificao do sistema (definido em termos de computador) enormemente reduzida.

2.3. IMPEDNCIA

Os desenvolvedores de aplicaes de bancos de dados (ou seja, qualquer aplicao que acesse dados armazenados em um banco de dados) freqentemente se vem brigando com problemas de diferenas de impedncia: a inerente falta de casamento entre os modelos de dados relacionais e os orientados a objeto. Os esforos para mapear dados relacionais em um formato utilizvel de objetos frequentemente prejudicam tanto a produtividade do programador quanto o desempenho da aplicao.

A diferena de impedncia uma expresso utilizada em engenharia eltrica, mas no contexto deste trabalho, refere-se diferena que existe entre os modelos de dados relacional e objeto. O modelo relacional organiza todos os dados em linhas e colunas, onde cada linha representa um registro. Se os dados forem por demais complexos para serem representados em forma de tabela, tabelas adicionais so cridas para conter as informaes

relacionadas. Dessa forma, cada tabela em um esquema relacional conter registro mas no todos os dados para uma grande quantidade de registros.

O modelo de dados orientado a objeto no est limitado a manter as informaes em linhas e colunas. Em vez disso, o desenvolvedor cria uma definio, um modelo, que descreve completamente uma determinada classe de informaes. Cada registro (objeto) uma instncia especfica daquela classe. Assim, cada registro contm todos os itens de informao para um, e apenas um, registro. Mas isso no tudo, as definies de classes tambm podem incluir trechos de programao, denominados mtodos que apenas sobre os

dados descritos pela classe. No h uma concepo anloga no modelo relacional.

2.3.1. Usando um banco de dados relacional

14

Esta seo j discute como a tentativa de usar um banco de dados relacional com uma aplicao baseada em tecnologia de objetos apresenta srios problemas de diferena de impedncia. Mas as vezes os desenvolvedores no tem escolha. Pode ser que eles tenham de acessar dados que residem em um banco de dados relacional. Nesse caso, uma opo usar ema ferramenta de mapeamento objeto-relacional, quer seja ela autnoma, quer consiste em facilidades disponvel nos bancos de dados objeto-relacional. Essencialmente, as ferramentas de mapeamento criam um arquivo (um mapa) que contm as regras para a traduo entre objetos e tabelas relacionais. Os desenvolvedores devem especificar exatamente como a traduo ser feita, ou seja, que propriedades do objeto correspondem a quais colunas de que tabelas e vice-versa. Uma vez criado, o mapa salvo e invocado sempre que uma aplicao move os dados para o banco de dados. Algumas ferramentas de mapeamento objeto relacional provem um componente de cach em tempo de execuo para ajudar a compensar a perda de desempenho causada pela traduo entre as formas relacionais e de objetos.

Alm de poder causar problema de performance durante a execuo, o mapeamento

objeto-relacional pode atrasar significativamente o desenvolvimento da aplicao. A maioria das ferramentas de mapeamento no implementa conceitos de modelagem de

objetos, como herana e polimorfismo, ou o faz apenas parcialmente. Assim, medida que uma aplicao adaptada e modificada, mapas objeto-relacional novos e atualizados tm de ser criados.

Os desenvolvedores que enfrentam o problema da diferena de impedncia entre aplicao orientadas a objeto e bancos de dados relacionais relacional podem querer considerar a opo de migrar os dados para um sistema de armazenamento mais amigvel. Eles devem ento avaliar, o esforo de reformatar e transferir seus dados uma s vez, em relao ao trabalho constante e as perdas de desempenho que resultam do uso de um mapa

objeto-relacional.

2.3.2. Usando um banco de dados de objeto

primeira vista, parecia que a diferena de impedncia poderia ser totalmente eliminada armazenando-se os dados em um banco puramente de objetos. Isso

15

parcialmente verdade. Em geral, para uma aplicao orientada a objeto fcil interagir com um banco de dados orientado a objeto. No entanto, neste cenrio, a diferena de impedncia ocorre quando se quer executar uma consulta SQL a essa base de dados. A SQL , de longe a linguagem de consulta mais amplamente utilizada em todo o mundo, e ela assume que os dados esto armazenados em tabelas do modelo relacional. Alguns fabricantes de banco de

dados orientados a objeto fornecem o acesso a dados via linguagem de consulta de objeto (OQL, do ingls Object Query Language), mas essas linguagens no tm aceitao generalizada.

Para ser compatvel com as aplicaes comuns de analise de dados e de gerao de relatrios, um banco de dados orientado a objeto deve prover algum mecanismo para representar os dados como tabelas relacionais.

A soluo tpica mais uma vez o mapeamento. Os pontos negativos do mapeamento (perdas de performance de dados) ainda se aplicam ao caso. O aspecto positivo que o mapeamento s precisa ser chamado quando uma consulta SQL feita base de dados.

2.4. CAMADA DE PERSISTNCIA

Podemos definir persistncia de dados como uma forma de manter a existncia da informao mesmo fora da aplicao. Podemos persistir a informao em um banco de dados, em um arquivo de dados ou qualquer outro meio existente e o fato da informao existir tambm fora da aplicao faz com que essas informaes possam ser compartilhadas por outras aplicaes.

Para permitir um processo de mapeamento entre sistemas baseados em objetos e bases de dados relacionais, foram propostas diversas idias que convergiram para o conceito de Camada de Persistncia.

Conceitualmente, uma Camada de Persistncia de Objetos uma biblioteca que permite a realizao do processo de persistncia (isto , o armazenamento e manuteno do estado de objetos em algum meio no-voltil, como um banco de dados) de forma transparente. Graas independncia entre a camada de persistncia e o repositrio de dados utilizado, tambm possvel gerenciar a persistncia de um modelo de objetos em diversos tipos de repositrios, com pouco ou nenhum esforo extra. A utilizao deste

16

conceito permite ao desenvolvedor trabalhar como se estivesse em um sistema completamente orientado a objetos utilizando mtodos para incluir, alterar e remover objetos e uma linguagem de consulta para SGBDs Orientados a Objetos comumente a linguagem OQL para realizar consultas que retornam colees de objetos instanciados.

2.4.1. Vantagens da utilizao

As vantagens decorrentes do uso de uma Camada de Persistncia no desenvolvimento de aplicaes so evidentes: a sua utilizao isola os acessos realizados diretamente ao banco de dados na aplicao, bem como centraliza os processos de

construo de consultas e operaes de manipulao de dados (insert, update e delete) em uma camada de objetos inacessvel ao programador. Este encapsula mento de responsabilidades garante maior confiabilidade s aplicaes e permite que, em alguns casos, o prprio SGBD ou a estrutura de suas tabelas possam ser modificados, sem trazer impacto aplicao nem forar a reviso e recompilao de cdigos.

2.4.2. Requisitos de uma camada de persistncia

Segundo Scott Ambler, pesquisador e autor de diversos livros, uma Camada de Persistncia real deve implementar as seguintes caractersticas:

Dar suporte a diversos tipos de mecanismos de persistncia: um mecanismo de persistncia 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 Persistncia deve suportar a substituio deste mecanismo livremente e permitir a gravao de estado de objetos em qualquer um destes meios.

Encapsula mento completo da camada de dados: o usurio do sistema de persistncia de dados deve utilizar-se, no mximo, de mensagens de alto nvel como

save ou delete para lidar com a persistncia dos objetos, deixando o tratamento destas mensagens para a camada de persistncia em si.

Aes com multi-objetos: Suportar listas de objetos sendo instanciadas e retornadas da base de dados deve ser um item comum para qualquer implementao, tendo em vista a freqncia desta situao.

17

Transaes: ao utilizar-se da Camada de Persistncia, o programador deve ser capaz de controlar o fluxo da transao ou ter garantias sobre o mesmo, caso a prpria Camada de Persistncia preste este controle.

Extensibilidade: A Camada de Persistncia deve permitir a adio de novas classes ao esquema e a modificao fcil do mecanismo de persistncia.

Identificadores de Objetos: A implementao de algoritmos de gerao de chaves de identificao garante que a aplicao trabalhar com objetos com identidade nica e sincronizada entre o banco de dados e a aplicao.

Cursores e Proxies: As implementaes de servios de persistncia devem ter cincia de que, em muitos casos, os objetos armazenados so muito grandes e recuper-los por completo a cada consulta no uma boa idia. Tcnicas como o lazy loading (carregamento tardio) utilizam-se dos proxies para garantir que atributos s sero carregados medida que forem importantes para o cliente e do conceito de cursores para manter registro da posio dos objetos no banco de dados (e em suas tabelas especficas).

Registros: Apesar da idia de trabalhar-se apenas com objetos, as camadas de persistncia devem, no geral, dispor de um mecanismo de recuperao de registros -

conjuntos de colunas no encapsuladas na forma de objetos, como resultado de suas consultas. Isto permite integrar as camadas de persistncias a mecanismos de gerao de relatrios que no trabalham com objetos, por exemplo, alm de permitir a recuperao de atributos de diversos objetos relacionados com uma s consulta.

Arquiteturas Mltiplas: O suporte a ambientes de programas stand-alone, cenrios onde o banco de dados encontra-se em um servidor central e mesmo arquiteturas mais complexas (em vrias camadas) deve ser inerente Camada de Persistncia, j que a mesma deve visar a reusabilidade e fcil adaptao a arquiteturas distintas.

Diversas verses de banco de dados e fabricantes: a Camada de Persistncia deve tratar de reconhecer diferenas de recursos, sintaxe e outras mincias existentes no

acesso aos bancos de dados suportados, isolando isto do usurio do mecanismo e garantindo portabilidade entre plataformas.

18

Mltiplas conexes: Um gerenciamento de conexes (usualmente utilizando-se de pooling) uma tcnica que garante que vrios usurios utilizaro o sistema simultaneamente sem quedas de performance.

Queries SQL: Apesar do poder trazido pela abstrao em objetos, este mecanismo no funcional em cem porcento dos casos. Para os casos extremos, a Camada de

Persistncia deve prover um mecanismo de queries que permita o acesso direto aos dados ou ento algum tipo de linguagem de consulta similar SQL, de forma a permitir consultas com um grau de complexidade maior que o comum.

Controle de Concorrncia: Acesso concorrente a dados pode levar a inconsistncias. Para prever e evitar problemas decorrentes do acesso simultneo, a Camada de Persistncia deve prover algum tipo de mecanismo de controle de acesso. Este controle geralmente feito utilizando-se dois nveis com o travamento pessimstico (pessimistic locking), as linhas no banco de dados relativas ao objeto acessado por um usurio so travadas e torna-se inacessveis a outros usurios at o mesmo liberar o objeto. No mecanismo otimstico (optimistic locking), toda a edio feita em memria, permitindo que outros usurios venham a modificar o objeto.

2.4.3. Camadas de persistncia e linguagens de programao

Diversas implementaes de camadas de persistncia esto disponveis gratuitamente na Internet. Estas bibliotecas muitas vezes tratam da gerao dos esquemas de dados (mapeamentos) automaticamente e podem at mesmo efetuar uma engenharia reversa criando hierarquia de classes a partir de um esquema de tabelas em banco de dados. As Camadas de Persistncia que geralmente trabalham com apenas um esquema de

mapeamento de classes para tabelas, diversas estratgias de gerao de identificadores, suporte a quaisquer tipos de relacionamento e gerao de cdigo SQL automatizada.

Na linguagem Java, podemos citar algumas destas bibliotecas de persistncia:

Hibernate uma implementao que permite a persistncia transparente de objetos em bases de dados utilizando JDBC e o mapeamento de classes para XML. Trata-se

de um servio de persistncia e recuperao de objetos, j que, ao contrrio dos

19

frameworks de persistncia, no necessrio estender nenhuma classe especial para que um objeto possa ser armazenado. Projetado para permitir integrao com ambientes J2EE, o Hibernate utiliza reflexo (reflection) para tratar a persistncia, gerando cdigo SQL medida que for necessrio. Atualmente compatvel com 11 SGBDs comerciais em sua verso 1.1 (Oracle, DB2, MySQL, PostgreSQL, Sybase, SAP DB, HypersonicSQL, Microsoft SQL Server, Progress, Mckoi SQL, Pointbase e Interbase), o Hibernate distribudo segundo a licena LGPL e suporta uma API baseada no padro ODMG 3.0 (o padro para construo 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 ligao de dados (databinding), o Castor prope-se a ser "a menor distncia entre objetos Java, documentos XML, diretrios LDAP e dados SQL",promovendo mapeamentos entre todas estas estruturas de representao de objetos. A API do pacote Castor especfica para a persistncia em bancos de dados relacionais a JDO uma implementao inspirada no padro Java Data Objects da Sun. A API prov integrao com ambientes J2EE. Atualmente em sua verso 0.9, o Castor suporta os SGBDs Oracle, Sybase, SQL Server, DB2, Informix, PostgreSQL, Hypersonic SQL, InstantDB, Interbase, MySQL e SAP DB. A distribuio segue a licena LGPL.

Object-Relational Java Bridge (OJB) - um projeto do grupo Apache para prover uma implementao open-source dos padres 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 especfica. A biblioteca d suporte a cenrios cliente-servidor (aplicaes distribudas) ou standalone, de forma que possvel utilizar a API OJB para persistncia de objetos. Alm disso, a biblioteca possui integrao com o sistema de gerao de logs. Em sua verso 0.9, o OJB d suporte a configurao de esquemas em tempo de execuo, gerao de tabelas para mapear uma hierarquia de classes ou classes relativas a um conjunto de tabelas e implementa uma srie de elementos que visam melhorar a performance da Camada de Persistncia. Os SGBDs suportados pela

20

implementao atual incluem DB2, Hypersonic SQL, Informix, MS-Access, MS-SQL Server, MySQL, Oracle, PostgreSQL, Sybase e SAP DB. A distribuio feita segundo a licena Apache.

Torque um framework de persistncia desenvolvido como subprojeto do projeto Apache Turbine, a API trabalha gerando toda a estrutura de banco de dados, classes

e cdigo 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 compilao de cdigo (build tool) do projeto Apache. A API torque encontra-se em sua verso 3.0 e distribuda segundo a licena Apache.

2.5. O QUE SO FRAMEWORKS

Um framework OO uma estrutura de classes inter-relacionadas que constitui uma implementao inacabada, para um conjunto de aplicaes de um domnio, alm de ser uma tcnica que faz o reuso do projeto.

O termo framework que inicialmente estava associado ao conceito de bibliotecas de classes reutilizveis, mais recentemente, teve seu conceito estendido para qualquer soluo incompleta que pode ser completada atravs da instanciao, possibilitando a criao de mais uma aplicao dentro do domnio-alvo do framework (Esta definio tem similaridades com a do gerador de artefatos). Atualmente esta tcnica tem sido muito apoiada e utilizada pela comunidade de desenvolvimento de SI. H uma vasta gama de frameworks disponveis, tanto na forma de software livre quanto proprietrio, alguns mais restritos, outros mais flexveis.

necessrio conhecer bem um framework antes de adot-lo em seu projeto, muitos ainda so muito imaturos e podem condenar o software a um curto perodo de sucesso.

21

3. MAPEAMNTO OBJETO RELACIONAL

O termo Mapeamento Objeto Relacional refere-se a tcnica de mapear os registro do Banco de Dados em objetos e persistir as informaes contidas nos objeto em forma de linhas e colunas.

Como o prprio nome diz, Mapeamento Objeto / Relacional, responsvel por mapear classes e atributos do modelo orientado a objeto para tabelas e colunas do banco de dados.

Existem vrias formas de fazer esse mapeamento. Alguns frameworks utilizam a linguagem XML, outros nos obrigam a implementar alguma Interface ou trabalhar com os

Atributos do .NET, mas o objetivo sempre o mesmo: Permitir que o framework consiga gerar os comandos SQL dinamicamente.

Uma outra caracterstica deste modelo a independncia do banco de dados. Devido a gerao de comandos dinmicos, o framework pode analisar qual banco de dados a aplicao est acessando e gerar os comandos no dialeto especfico do banco de dados, ou seja, possvel mudar o banco de dados da aplicao apenas alterando um arquivo de configurao.

3.1. Mapeando objetos para tabelas

Para permitir a correta persistncia de objetos em um banco de dados relacional, algum acordo deve ser feito no tocante forma como os dados sero armazenados. Existem diversas tcnicas que permitem o mapeamento de conjuntos de objetos, cada qual com suas vantagens e desvantagens sobre as demais. Em geral, uma Camada de Persistncia implementa uma destas tcnicas, de forma que o desenvolvedor de software, ao escolher o mecanismo de persistncia com o qual trabalhar, sabe como deve organizar as tabelas em seu 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: seus atributos, relacionamentos e classes descendentes (herana).

22

3.2. Mapeando atributos

Ao transpor-se um objeto para uma tabela relacional, os atributos do mesmo so mapeados em colunas da tabela. Este processo de mapeamento deve levar em considerao fatores como a tipagem dos dados (alguns SGBDs podem no suportar tipos binrios longos, por exemplo) e o comprimento mximo dos campos (no caso de nmeros e strings). Tambm importante lembrar que, em diversos casos, atributos de um objeto no devem ter 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 para fins de consulta, mas mant-lo no banco de dados talvez no seja uma idia to interessante, por tratar-se de um valor que pode ser obtido atravs de consultas. Alm

disso, existem casos onde um atributo pode ser mapeado para diversas colunas (exemplos incluem endereos completos, nome dividido em 'primeiro nome' e 'sobrenome' no banco

de dados) ou vrios atributos podem ser mapeados para uma mesma coluna (prefixo e nmero de telefone, por exemplo). As implementaes de Camadas de Persistncia provem, em alguns casos, suporte a este tipo de situao.

3.3. Mapeamento de classes em tabelas

O mapeamento de estruturas de classes em tabelas de uma base de dados relacional nem sempre um processo simples: enquanto alguns acham interessante a adoo de "tabeles" (isto , tabelas no-normalizadas agrupando dados de diversas entidades) como repositrio para os dados, outros preferem ater-se s regras propostas pelas teorias de normalizao de bancos de dados relacionais. As trs tcnicas de mapeamento de objetos mais comumente implementadas (inclusive em Camadas de Persistncia) so detalhadas a seguir. comum a adoo de uma destas tcnicas, mesmo quando nenhum tipo de mecanismo de persistncia automtico adotado no desenvolvimento.

3.4. Mapeamento de uma tabela por hierarquia

23

Segundo esta estratgia, toda a hierarquia de classes deve ser representada por uma mesma tabela no banco de dados: uma coluna que identifique o tipo do objeto serve para identificar a classe do objeto representado por cada linha na tabela, quando nenhum outro modo de identificao vivel. As desvantagens desta estratgia so evidentes: a ausncia de normalizao dos dados fere as regras comuns da teoria de modelagem de dados alm

disso, para hierarquias de classes com muitas especializaes, a proliferao de campos com valores nulos na maioria das linhas da tabela se torna tambm um problema potencial.

3.5. Mapeamento de uma tabela por classe concreta

Nesta estratgia, teremos uma tabela no banco de dados para cada classe concreta

presente em nosso sistema. A tabela identifica a classe de todos os elementos contidos na mesma, tornando desnecessrio o mecanismo de Object Type adotado na estratgia anterior. A estratgia de gerao de uma tabela para cada classe concreta leva redundncia de dados: quaisquer atributos definidos em uma superclasse abstrata na hierarquia devem ser criados em todas as tabelas que representam subclasses da mesma. Alm disso, mudar o tipo (especializar ou generalizar) um objeto torna-se um problema, j que necessrio transferir todos os seus dados de uma tabela para outra no ato da atualizao.

3.6. Mapeamento de uma tabela por classe

Na terceira estratgia proposta, criamos uma tabela para cada classe da hierarquia, relacionadas atravs do mecanismo de especializao padro do banco de dados (utilizao de chaves estrangeiras). Segundo esta modalidade de mapeamento, tenta-se ao mximo manter a normalizao de dados, de forma que a estrutura final das tabelas fica bastante parecida com a hierarquia das classes representada pela UML. A colocao de um identificador de tipo (Object Type) na classe-pai da hierarquia permite identificar o tipo de um objeto armazenado nas tabelas do sistema sem forar junes entre as tabelas, garantindo melhorias na performance, e uma estratgia comumente utilizada. Esta a

tcnica que mais naturalmente mapeia objetos para bancos de dados relacionais, de forma

24

que as Camadas de Persistncia geralmente foram a utilizao de um esquema de dados que siga esta modalidade de mapeamento. A quantidade de junes (joins) entre tabelas para obter todos os dados de um objeto o seu principal ponto negativo.

A tabela 1 faz um comparativo destas trs tcnicas quanto facilidade de consulta a dados interativa (ad-hoc reporting), facilidade implementao, facilidade de acesso aos dados, acoplamento dos dados das classes mapeadas, velocidade de acesso e suporte a polimorfismo.

Uma tabela por hierarquia de classes

Uma tabela por classe concreta

Uma tabela por classe

Ad-hoc reporting Simples Mdio Mdio/Difcil Facilidade de implementao Simples Mdio Difcil

Facilidade de acesso Simples Simples Mdio/Simples Acoplamento Muito alto Alto Baixo Velocidade de acesso Rpido Rpido Mdio/Rpido Suporte a polimorfismos Mdio Baixo Alto

Tabela 1. Comparativo entre tcnicas de mapeamento de classes

3.7. Mapeamento de relacionamentos

Os relacionamentos de associao entre objetos so uma das caractersticas mais facilmente mapeadas. Conceitualmente, existem apenas trs tipos de relacionamentos

possveis (um-para-um, um-para-muitos e muitos-para-muitos).

Relacionamentos um-para-um necessitam que uma chave (foreign key) seja posta em uma das duas tabelas, relacionando o elemento associado na outra tabela. Dependendo

da disposio desta chave estrangeira, podemos definir a navegabilidade do relacionamento (que se d sempre da tabela que possui a chave estrangeira para a tabela referenciada). Para manter relacionamentos um-para-muitos, adota-se a mesma tcnica: uma referncia na forma de chave estrangeira deve ser posta na tabela que contm os objetos mltiplos (lado

25

"n" do relacionamento).No caso de relacionamentos muitos-para-muitos (ou n-para-n), convenciona-se criar uma tabela intermediria que armazene pares de chaves, identificando os dois lados do relacionamento.

H uma tendncia para a utilizao de Linguagens de Programao Orientadas a

Objeto(LPOO) e mecanismos de persistncia diversos, principalmente, Banco de Dados Relacionais(BDR).Surge ento um problema, a integrao entre a linguagem e o BD. Embora existam vrias APIs e modelos de mapeamento que possibilitam esta integrao, elas devem ser utilizadas de acordo com diretrizes para que no se perca os benefcios da orientao a objetos e nem do BDR.

O simples mapeamento das classes, em nvel de projeto, para tabelas do BDR no garante a resoluo do problema, na verdade existem outros aspectos, no menos importantes, que podem levar a, violao dos princpios bsicos da orientao a objetos como encapsula-mento e modularizao, ou descaracterizao da arquitetura adotada. Mesmo assim o modelo de objetos do banco diferente do modelo de objetos utilizado pela linguagem de programao. Enquanto a linguagem trabalha com objetos na memria, o banco trabalha com objetos em disco, o que exige algoritmos e estratgias diferenciadas. Alm de que, os BDOOs no so, atualmente, a tecnologia padro no mercado, por conta do legado em investimento em sistemas desenvolvidos, pela cultura dos profissionais atuando no mercado ou at mesmo por questes de performance.

Algumas ferramentas RAD, como DelphiTM, JbuilderTM e Dreamweaver, tornam semi-automtica a integrao de uma LPOO com um BDR. No entanto essa implementao realizada sem a preocupao de critrios que garantam a continuidade e reversibilidade da implementao em relao ao projeto. Estes erros no so somente cometidos nestas condies, existem diversas implementaes ad hoc que infringem estes e outros aspectos.

Um mecanismo de persistncia tem trs componentes bsicos, so eles:

Regras de mapeamento; API de acesso ao Banco de Dados; Linguagem de consulta;

26

Este componentes se interligam para gerar o mecanismo de persistncia, que deve ter como objetivos a maior abstrao possvel do BDR nas regras de negcio e a melhor performance possvel. Alm disso um mecanismo deve considerar tambm as funcionalidades tanto da LPOO quanto do BDR, resultando maior reusabilidade, extensibilidade e eficincia.

No caso de se obter reusabilidade nas regras de negcio orientado a objeto preciso seguir o princpio da independncia dos objetos de negcio em relao ao mecanismo de persistncia.

As regras de mapeamento gerenciam como o modelo OO que mais rico semanticamente, vai ser mapeado para o modelo relacional. Como iro se comportar herana, agregao, entre outros devem estar definidos nestas regras.

A linguagem de consulta responsvel para manipular os dados do banco, pode ser baseada em objetos ou no.

As APIs so responsveis pela integrao do mecanismo com as regras de negcio. Estas podem ser intrusivas ou no. Quando estas impem regras sob criao das classes persistentes, a API intrusiva, caso contrrio no.

A tendncia que as APIs sejam no intrusivas, porm dificilmente o BD ser utilizado com eficincia, bem como os conceitos transparentes ao Banco de Dados, como transaes, sero mais difceis de implementar sem modificar ou denegrir responsabilidades no modelo de objetos.

Em termos de performance deve-se desenvolver uma poltica sobre como e quais os atributos sero carregados, em uma consulta. Podemos utilizar o carregamento antecipado,

ou o carregamento tardio4. Em alguns casos deve-se ter uma poltica de escrita no BD tambm.

3.2. MAPEAMENTO OO ER

A integrao objeto-relacional requer uma estratgia para mapeamento de modelo objeto para o modelo relacional. O banco de dados relacional possui caractersticas importantes tais como consultas rpidas, compartilhamento de informaes entre programas e armazenamento permanente. O modelo objeto possui componentes, estado e baseado

27

em estruturas que combinam cdigo e dados e ainda possuem sua prpria identidade (Object Identification OID) Esta identidade no depende dos valores que o objeto possui, ela possibilita estabelecer referncias entre objetos e definir os relacionamentos, os quais podem ser dos seguintes tipos: associao, agregao, generalizao/especializao. OIDs possibilitam simplificar a estratgia de uso de chaves no banco de dados, eles

facilitam a navegao entre objetos simplificados os joins. Outra vantagem que o uso de OIDs facilitam a manuteno dos relacionamentos entre objetos. Quando todas as tabelas possuem suas chaves baseadas num mesmo tipo de colunas, torna-se mais fcil escrever o cdigo e tirar vantagens disso.

O modelo objeto e o modelo relacional so fundamentalmente diferentes, o modelo objeto til para expressar relaes complexas entre objetos nas Linguagens de Programao Orientada a Objeto como, C++ e Java. J o modelo relacional til para gerenciar grande volume de dados em Banco de Dados Relacional como, SQL Server e Oracle.

Sendo assim cada uma das classes do modelo OO transformada em uma tabela no

modelo relacional. Para as associaes, o mapeamento feito ou com a criao de novas tabelas ou com a cpia das chaves de uma tabela para outra. Para agregao, a regra

generalizao /especializao, cuja transformao para o modelo relacional executado com interao do usurio, uma vez que para um mesmo caso pode haver diferentes formas de transformao. Existem algumas regras de transformao que tem por finalidade a converso do modelo OO para o modelo relacional. As regras se dividem em (OBJECTMATTER, 2003):

- Mapeamento Bsico - Mapeamento Herana de Classe

- Mapeamento Relacionamento de Objeto

Sero descritas as tcnicas fundamentais requeridas para o sucesso do mapeamento objeto para o relacional. Isto poder ajudar a rever os contedos que predominam no desenvolvimento e praticas que envolvem este assunto

3.2.1. Mapeamento Bsico

28

A classe pode ser mapeada para tabelas. O simples mapeamento entre a classe persiste e a tabela um-para-um. Neste caso, todos os atributos da classe persistente so representados por todas as colunas da tabela. Cada instncia da classe do negcio 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 so persistentes, por exemplo, um atributo

total que usado para instanciar um somatrio, logo, este no persistido no banco de dados. Alguns atributos dos objetos so objetos por si s, como exemplo: endereo, cep, rua,etc.. portanto devem ser tratados como relacionamentos.

3.2.2. Mapeamento herana de classe

O conceito de herana lana vrios interesses do entrelaamento de salvar objetos em banco de dados relacionais. Este assunto basicamente concentra-se em imaginar como

organizar o atributo herdado em seu modelo persistente. A maneira como ser resolvido este desafio poder ter um grande impacto no projeto de seu sistema. Existem trs tipos de solues que so fundamentais para mapear a herana para o modelo relacional:

- Mapeamento uma tabela para toda hierarquia: com este mtodo mapeia-se toda a classe de herana para uma tabela, onde todos os atributos de toda a classe da hierarquia so armazenados e, uma coluna OID introduzida como chave primria na tabela;

- Mapeando uma tabela por classe: com este mtodo cada tabela inclui tanto os seus atributos quanto os atributos herdados. Somente as classes folhas das hierarquias so

mapeadas para tabelas;

-Mapeando uma tabela por classe; com este mtodo cria-se uma tabela por classe. A principal vantagem que esta abordagem a que esta mais conforme a orientao a objetos. Os registros esto armazenados nas tabelas apropriadas, de acordo com seus

29

papeis. Uma desvantagem, neste mtodo so mais tabelas BD (mais tabelas para manter os relacionamentos).

3.2.3. Mapeando relacionamento de objetos

No somente devemos mapear os objetos para o banco de dados, mas tambm mapear os relacionamentos que envolvem os objetos. Existem quatro tipos de relacionamento os quais os objetos podem estar envolvidos: generalizao, associao, agregao e composio. Para mapear efetivamente esses relacionamentos, devemos estender as diferenas entre eles, como implementar a generalizao, e como implementar relacionamento muitos-para-muitos especificamente.

Para o banco de dados, perspectivamente, somente tem diferena entre os relacionamentos de associao e agregao/composio e como o objeto firmemente amarrado a ele. Com a agregao e composio qualquer coisa que voc faa com o todo no banco de dados voc sempre precisar fazer nas partes, enquanto que com associao este no o caso.

O diagrama de classes a estrutura das tabelas que so 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, mantm-se, comumente, por

meios de colunas de chaves estrangeiras. Esta coluna de chave estrangeira mantm o valor da chave primria (OID do objeto) da coluna (objeto) referenciada. O relacionamento um-para-um pode ser definido como referencia ao atributo, isto pode ser feito transparentemente convertendo a chave estrangeira do objeto referenciado. Isto tambm possibilita a definio do relacionamento um-para-um no modelo relacional usando uma join table.

No modelo objetos existem dois tipos de relacionamento um-para-muitos: agregao (parte de), e associao. Um relacionamento de agregao definido por meios do prprio atributo e um relacionamento de associao por meios de uma coleo referenciada ao atributo. A diferena entre as duas que no relacionamento prprio, que prprio atualizado no banco de dados. Todos os objetos, em todas as suas colees, so

30

automaticamente atualizados (este comportamento pode ser modificado em tempo de execuo se necessrio).

No modelo relacional, um-para-muitos pode ser definidos usando a coluna de chave estrangeira ou usando uma join table uma tabela com o propsito de armazenar os valores mapeados entre a chave estrangeira das duas tabelas envolvidas no relacionamento.

Um relacionamento muitos-para-muitos pode ser como uma bi-direcional associao um-para-muitos. Para criar este tipo de relacionamento, simplesmente,

definimos o atributo referenciado na coleo, em cada classe envolvida no relacionamento. No modelo relacional um relacionamento muitos-para-mutos pode ser definido usando colunas de chaves estrangeiras ou uma join table.

Para usar chaves estrangeiras, uma coluna com a chave estrangeira definida para cada tabela envolvida no relacionamento. Cada coluna da chave estrangeira mantm a chave da outra tabela. Existem vrios tipos que podem ser implementados para associao muitos-para-muitos usando join table.

Uma das maneiras de implementar relacionamento muitos-para-muitos usando

uma tabela associativa. O nome da tabela associativa geralmente a combinao dos nomes das tabelas que esto associadas ou o nome da associao implementada entre elas. A

associao original possui um relacionamento muitos-para-muitos e com a utilizao da tabela associativa se faz um cruzamento das multiplicaes e no se perde essa associao. O propsito de uma tabela associativa implementar uma associao descrita em uma classe associativa.

3.3. OBJETIVOS GERAIS DOS COMPONENTES MAPEAMENTO OO- ER

Mapeamento objeto-relacional a transformao das regras do modelo objeto para as regras e normalizaes do modelo relacional. Isto significa que existem dois modelos utilizados na construo de sistemas. O modelo objeto utilizado para descrever e apresentar as regras de negcio, enquanto. A utilizao do paradigma relacional na persistncia dos objetos, atividade importante para definir a base de dados de sistemas que utilizam o paradigma orientado a objeto no seu desenvolvimento.

31

A transformao de uma classe em uma tabela e seus respectivos relacionamentos e atributos em chaves primrias e chaves estrangeiras define, com mais preciso, questes relacionadas performance no acesso aos dados (no fazer um-para-um). O relacionamento um-para-um, possui algumas desvantagens:

1 so 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 tcnica porque varias tabelas sero acessadas. Neste caso, ceve existir a preocupao em atualizar e manipular as classes de nvel superior na hierarquias profundas, so requeridos mltiplos joins para recuperar as informaes bsicas do objeto.

Resumindo, o mapeamento OO-ER importante para que dois mundos consolidados (OO desenvolvimento e ER base de dados) possam convergir em uma nica soluo.

O objetivo principal do componente fazer o mapeamento objeto-relacional utilizando como entrada um arquivo XMI que o padro entre intercambio de dados

utilizado hoje, e gerando como sada um arquivo .sql para utilizao no banco de dados.

3.3.1. Mapeamento bsico

Cada classe do modelo ser transformada em uma tabela do modelo relacional e, todos os seus atributos, sero representados por todas as colunas da tabelas. A Figura 1 apresenta um exemplo de mapeamento bsico.

A chave primria definida atravs da utilizao de Object Identification (OID).

32

FIGURA 1 Mapeamento Bsico

Gerao das Primary Keys (OID): Toda a classe transformada m tabela tem um identificador prprio: o seu OID. O qual facilita o relacionamento entre as tabelas, e com isso, 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 primria 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 primria da tabela relacionada como chave estrangeira da tabela referenciada. A figura 3 apresenta um exemplo de mapeamento um-para-muitos.

- Coloca-se a chave primria 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 primrias das duas tabelas relacionadas, como chaves estrangeiras na tabela associativa. O nome da nova

tabela a juno dos nomes das tabelas relacionadas.

34

FIGURA 4 Mapeamento de relacionamentos (muitos-para-muitos)

3.3.3. Generalizao

A generalizao pode ser mapeada de trs formas: uma tabela para toda hierarquia, uma tabela por classe concreta e uma tabela por classe. O componente contempla as trs formas de mapeamento. Previamente pode-se definir um mapeamento padro para a generalizao (uso do properties) ou atravs da escolha, pelo usurio, em tempo de execuo. As trs formas so:

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 excluda, 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 herana representada com um relacionamento um-para-um entre o pai e seus filhos. Conforme apresentado na figura 7.

36

FIGURA 7 Uma tabela por classe

37

3.4. REPRESENTAO DE UM ESQUEMA RELACIONAL

Para que possamos aplicar as regras de mapeamento, consideramos que as relaes no esquema relacional de origem esto no mnimo na 2 forma normal, ou seja, as relaes podem conter dependncia funcionais transitivas, mas no dependncias parciais.

Consideramos tambm que, so conhecidas as chaves primrias e estrangeiras das relaes que compe o esquema relacional de origem.

Em relao ao particionamento horizontal de tabelas, consideramos que se tal particionamento existe no esquema relacional de origem, isto foi feito devido deciso de projeto. Por no conhecemos o motivo de tal deciso, estabelecemos que: se duas tabelas A e B so equivalentes, mas so tratadas como tabelas diferentes devido ao particionamento horizontal, ento estas tabelas continuando sendo tratadas como distintas no esquema objeto-relacional, observamos que, no estamos considerando o problema de performance durante o mapeamento, uma vez que a tecnologia objeto-relacional ainda recente, e no se pode afirmar, deste ponto de vista, qual a melhor estrutura para modelar os dados, diante das diversas possibilidades oferecidas. Entretanto, procuramos fazer o mapeamento

oferecendo uma melhor modelagem do ponto de vista de compreenso do esquema.

Ainda com o objetivo de minimizar as falhas de projeto no esquema relacional de entrada, definimos, a seguir, um procedimento de pr-processamento deste esquema, descrito por;

1. Sejam as relaes R1 e R2. Se a chave primria de R1 tambm uma chave estrangeira que referencia a chave primria de R2 e a chave primria de R2 tambm uma chave

estrangeira que referencia a chave primria de R1, ento dizemos que as relaes R1 e R2 esto particionadas verticalmente. Neste caso, consideramos que as relaes R1 e R2

representam uma nica relao (R3), cujos atributos do dados pela unio dos atributos de R1 e R2. A chave primria de R3 a mesma de R1 ( que a mesma chave primria de R2). Consideramos tambm, que todas as restries definidas sobre R1 e R2, tornam-se

38

restries sobre R3, exceto as restries de chave estrangeira de R1 para R2 e vice-versa. A relao R3 ento definida: R3 (A, B, C, D, E).

A opo de unir tabelas particionadas verticalmente deve-se ao seguinte fato: se, aplicando as regras de mapeamento tais tabelas fossem mapeadas em tabelas de objetos distintas, que possuem em identificadores nicos. Desta forma, mesmo que dois objetos possuem a mesma chave-primria, mas em tabelas distintas, ento estes objetos possuem OIds diferentes.

Conforme definido anteriormente, consideramos que as relaes do esquema relacional de entrada podem estar na 2 forma normal. Desta forma, utilizamos o processo descrito para relaes, 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, so baseadas em um conjunto trabalho, com algumas adaptaes para adequar o modelo objeto-relacional descrito. A maioria destes trabalhos tratam do mapeamento para estruturas orientadas a objetos.

Regra T1: Toda tabela em um esquema relacional que tem somente um atributo na chave primria correspondente a uma tabela de objeto-relacional. Os atributos da tabela relacional tornam-se atributos do tipo de dados estruturados que definem a tabela de objetos.

Regra T2: Se a chave primria de uma tabela no esquema relacional tem mais que um atributo, e alm disso, a tabela possua outros atributos que no pertenam chave primria,

ento esta tabela relacional corresponde a uma tabela de objetos no esquema objeto-relacional. Os atributos de chave primria que representam chaves estrangeiras, devem ser

mapeados como uma referncia ao tipo que define a estrutura de tabelas referenciada pela chave estrangeira.

39

Regra T3: Toda tabela em um esquema relacional, cuja chave primria composta por mais de um atributo, e todos eles representam chaves estrangeiras. Esta associao representada no esquema objeto-relacional atravs de tabelas aninhadas.

Regra T4: Toda tabela que possui atributos de chave estrangeira que no fazem parte da

chave-primria, estabelece uma associao entre esta tabela e a cada tabela referenciada por chaves estrangeiras. Esta associao representada no esquema objeto-relacional atravs de referncias (tipo de dados ref.).

Regra T5: Todo par de tabelas R1 e R2 que tm as mesmas chaves primrias podem ser envolvidos em um relacionamento de herana. O relacionamento R1 um R2 existe se a chave primria de R1 tambm a chave estrangeira que refere a tabela R2.

Regra T6: Quando um relacionamento de herana esta embutido em uma nica tabela , necessrio extrair regras do banco de dados de uma maneira no convencional. Existem

vrios algoritmos que podem identificar tais regras, denominadas strong rules em banco de dados relacionais. Usando-se algum deste algoritmo, pode-se identificar as condies

que so estabelecidas para que um atributo, ou conjunto de atributos, possua valor nulo. Identificadas estas regras, podem-se extrair da tabela os relacionamentos de herana nela embutidos. Utilizamos o algoritmo descrito para determinar relacionamento de herana, em um esquema relacional.

Regra T7: Seja R uma tabela cuja chave primria tem mais que um atributo e no mnimo um deles no chave estrangeira, e alm disso, R no possui outros atributos que no pertenam chave primria. Deve-se ento acrescentar um atributo na tabela referenciada

pela chave primria, cujo domnio um tipo coleo 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 DE MAPEAMENTO OBJETO/RELACIONAL

J existem hoje no mercado algumas ferramentas capazes de realizar mapeamento entre objeto e registros de tabelas de banco de dados relacionais, fazendo com que operaes bsicas de cadastro como armazenamento, atualizaes, excluso e consultas possam ser realizadas naturalmente sobre objeto e reflitam por fim em SQL que sero interpretados pelos bancos relacionais.

Produtos que realizam mapeamento objeto relacional integram as capacidades das linguagens de programao orientadas a objeto com sistemas de gerenciamento de bancos relacionais, como Oracle, DB2, Sysbase, e outros. Produtos que realizam mapeamento objeto-relacional so projetados para funcionar bem como linguagens de programao orientadas a objetos.

A definio de correspondncia entre elementos modelados em objeto e elementos no modelo relacional precisa ser de fceis configuraes. Um grande numero de solues

usa arquivos de configuraes XML. Um editor grfico para edio destes arquivos consiste em uma vantagem extra e ter melhor preferncia pela equipe projetista de software para momento de realizar-se uma integrao da ferramenta ao ambiente de desenvolvimento.

Ferramentas de mapeamento podem ser mais ou menos genricas e sua capacidade de adaptar-se aos recursos existentes um importante motivo de escolha. Buscar informaes armazenadas em banco de dados relacionais pode prover muita complexidade se a ferramenta de mapeamento por em uso controle de restries de integridade sobre o

modelo relacional usado. A ferramenta deve prover funcionalidade de pesquisa, de montagem de objeto e de

atualizaes. Estes mecanismos precisam gerenciar corretamente quaisquer problemas de transaes e adaptar-se a arquitetura do sistema de informaes ao qual se destina, mesmo que seja usado um servidor de aplicao.

41

A descrio dos tipos de dados varia de um modelo para o outro. A ferramenta de mapeamento deve estar apta a diferenciar os tipos de dados e propor correspondncia no modelo relacional do banco de dados utilizados.

A partir do momento em que uma empresa desenvolvedora de software opta por uma ferramenta de mapeamento objeto/relacional ela geralmente tem como objetivo conseguir as seguintes vantagens no seu processo de engenharia de software:

Melhorar a manutenibilidade de cdigo. O cdigo relacionado a persistncia esta embutido em um modulo especifico e no modificado durante os vrios ciclos de vida do desenvolvimento;

O tamanho de cdigo mdio seja reduzido uma vez que o cdigo relacionado a persistncia inteiramente genrico e no esteja distribudo por toda a aplicao

O trabalho do(a) desenvolvedor(a) seja facilitado e reduzido, uma vez que ele no tenha mais que com problemas de persistncia e possa concentrar-se em resolver problemas de persistncia e possa concentrar-se em resolver problemas de regras de

negcios;

Aumentar a portabilidade da aplicao: 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 ao adquirir uma ferramenta de mapeamento objeto/relacional;

Caractersticas Descrio

Herana A ferramenta de desenvolvimento deve ser hbil a projetar um modelo de herana 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.

Nmero de BDs Relacionais suportados Possui suporte aos principais BDs. Relacionais (DB2, Oracle, Informix, MSSQLServer, entre outros)

Mecanismos de otimizao de performance Quais as funcionalidades para otimizar a performance da ferramentas? Instanciao parcial de objetos, cach em memria para leitura, etc.

42

Transaes Simples A ferramenta suporta o modelo transacional dos BDs Relacionais?

Suporte e transaes aninhadas A ferramenta suporta o modelo de transaes aninhadas BDs Relacionais?

4.2. TIPOS DE FERRAMENTAS

4.2.1. Hibernate

um dos mais bem sucedidos projetos Open Source desenvolvido em Java. Sua facilidade de uso, abstrao e transparncia fizeram dele quase um padro em frameworks de mapeamento objeto-relacional. Embora sua documentao seja rica e extensa, a falta de exemplos e dicas em portugus muitas vezes dificulta a sua adoo por parte de desenvolvedores brasileiros. O Hibernate no trata apenas do mapeamento de classes Java em tabelas de banco de dados (e tipos de dados Java em tipo de dados SQL), mas disponibiliza tambm um poderoso mecanismo de consulta de dados que pode reduzir significamente o tempo de desenvolvimento. O Hibernate objetiva liberar o desenvolvedor em 95% das tarefas comum relacionadas programao de persistncia de dados. O Hibernate disponibiliza um poderoso framework para persistncia objeto-relacional, de fcil manuseio e alto desempenho. O Hibernate prov suporte para colees e relacionamentos entre objetos, assim como herana. polimorfismo e composies. Ele tambm tem um rica linguagem de consulta orientada a objetos, o HQL ( Hibernate Query Language) para recuperao de objetos de banco de dados, uma camada de cach eficiente e suporte para Java Management Extensions (JMX). O Hibernate possui uma comunidade ativa de usurios que ajuda a prover suporte e ferramentas para extenso. distribudo de acordo com a Lesser GNU Public License (LGPL), portanto pode ser usado tanto em explicaes de cdigo aberto como comerciais. Suporta um grande numero de banco de dados, incluindo Oracle e DB2, assim como banco de dados livres tais como de dados, PostgreSQL e MySQL, permitindo a utilizao de meios nativos para a gerao de chaves primarias e pessimistic locking alm de resolver problemas como pool de conexes e configuraes de datasources.

Arquitetura

43

Uma viso de alto nvel da arquitetura do Hibernate:

Figura 8: Uma viso simplista do Hibernate

Esta figura mostra o Hibernate usando o banco de dados e a configurao de dados para disponibilizar servio de persistncia (e objetos persistentes) para a aplicao.

Dependendo da complexidade do projeto, um maior nmero de APIs e componentes so utilizados pelo Hibernate. A figura abaixo exibe uma viso mais detalhada da arquitetura:

Figura 9: Componentes do Hibernate

44

De acordo com a especificao do Hibernate, estes componentes so definidos da seguinte forma:

SessionFactory (net. sf. hibernate. SessionFactory) Armazena os mapeamentos e configuraes compiladas para um banco de dados. uma fbrica de objetos Session e que prov conexes atravs do ConnectionProvider. Este objeto imutvel e threadsafe (pode ser acessado por mltiplas threads sem perigo de inconsistncia).

Session (net. sf. Hibernate .Session) Um objeto que representa o "dilogo" entre a aplicao e a persistncia (banco de dados), encapsulando uma conexo JDBC e manipulado por somente uma thread. Este objeto controla um cache dos objetos persistentes. Os Session no devem durar toda a execuo da aplicao, ou seja, so objetos de "vida curta".

Persistent Objects and Collections Objetos manipulados por somente uma thread que contm as informaes persistentes e regras de negcio. Devem ser JavaBeans (possuir m construtor sem parmetros e mtodos get/set para os atributos persistidos). Eles s podem estar associados exatamente uma Session. Assim que o Session finalizado, estes objetos so liberados para serem usados em qualquer camada da aplicao.

Transient Objects and Collections Instncias de classes persistentes que no esto atualmente associadas a um Session. Podem ter sido instanciados pela aplicao mas ainda no persistidos, ou eles podem ter sido instanciados por um Session fechado.

Transaction (net.sf.hibernate.Transaction) Objeto usado pela aplicao para especificar unidades atmicas de acesso ao banco de dados. No deve ser manipulado por mltiplas threads. Abstrai a aplicao dos detalhes das transaes JDBC, JTA ou CORBA. Em alguns casos um Session pode manipular vrios Transactions.

45

ConnectionProvider (net.sf.hibernate.connection.ConnectionProvider) Uma fbrica para (e pool de) conexes JDBC. Abstrai a aplicao dos detalhes do Datasource ou DriverManager. No exposto aplicao, mas pode ser estendido/implementado pelo desenvolvedor.

TransactionFactory (net.sf.hibernate.TransactionFactory)Uma fbrica para instncias de Transaction. No exposto aplicao, mas pode ser estendido/implementado pelo

desenvolvedor.

4.2.2. Instalao e Configurao

A ltima verso Hibernate pode ser copiada do siteoficial(http://www.hibernate.org). A instalao simples, bastando descompactar o arquivo .zip. O diretrio criado contm o JAR ncleo do Hibernate (hibernate2.jar).

Tambm existe um subdiretrio chamado lib onde ficam os JARs das outras

APIs utilizadas pelo framework. Esses arquivos JARs devem ser referenciados no classpath da aplicao. tambm necessrio que a classe de driver do seu banco de dados esteja no classpath. O Hibernate foi desenvolvido para operar em vrios ambientes diferentes. Por isso, existe um grande nmero de parmetros de configurao. Por outro lado, a grande maioria dos parmetros tem valor padro e, alm disso, o Hibernate distribudo com um arquivo chamado hibernate.properties que mostra as vrias opes disponveis. Voc apenas precisa colocar esse arquivo no classpath e customiz-lo.

Configurando o SessionFactory A tabela abaixo mostra os parmetros mais importantes para configurao da conexo JDBC (com banco de dados):

46

Tabela 2: Parmetros principais para configurao da conexo JDBC

O Hibernate possui ainda uma srie de parmetros que definem seu comportamento em tempo de execuo, como por exemplo:

Tabela 3: Parmetros que definem comportamento em tempo de execuo

O Hibernate trabalha com dialetos para um grande nmero de bancos de dados, tais como: DB2, MySQL, Oracle, Sybase, Progress, PostgreSQL, Microsoft SQL Server, Ingres, Informix entre outros.

Todos estes parmetros so usados na configurao inicial. A partir deles, criado um objeto da classe SessionFactory. Este objeto contm todas as informaes passadas na configurao. Quando criado, o SessionFactory carrega e verifica todas as configuraes. Esta operao consome mais tempo do Hibernate e por isso recomendvel criar este objeto somente uma vez e utiliz-lo durante toda execuo da aplicao. O Hibernate permite que sejam criados mais de um SessionFactory, mas isso s deve ser feito se houver necessidade de acesso a mais de um banco de dados. Existem duas formas de informar ao

SessionFactory as configuraes do Hibernate:

4.2.3. Configurao atravs do objeto Configuration

A configurao pode ser feita atravs da classe Configuration (net.sf.hibernate.cfg.Configuration). Os objetos desta classe podem ser instanciados de forma direta. Configuration deve receber as configuraes gerais atravs da classe Properties e tambm os mapeamentos Objeto/Relacional (ORM). Na tabela 4 um exemplo de como criar um SessionFactory atravs do objeto Configuration:

Tabela Exemplo 4: Criando um SessionFactory atravs do objeto Configuration

47

4.2.4. Mapeamento O/R Bsico

O Hibernate usa arquivos XML para mapear os atributos das classes em campos das

tabelas. Qualquer classe pode ser mapeada desde que seja um Bean, ou seja, possua um construtor sem parmetros e os atributos mapeados possuam mtodos get e set. A presena

de um atributo de identificao (chave primria) altamente recomendada, mas no obrigatria, caso contrrio diversas funcionalidades no estaro disponveis. No necessrio nenhum tipo de especializao (herana) ou realizao de interface para que uma classe seja persistida pelo Hibernate. Isto quer dizer que o Hibernate pode persistir objetos POJO (Plain Old Java Object). Abaixo o exemplo de uma classe que poderia ser persistida:

Tabela Exemplo 5: Classe candidata persistncia

Abaixo, a implementao da classe do diagrama UML acima.

Tabela Exemplo 6: Implementao da classe Pessoa

Segue a declarao de criao da tabela que armazena a classe acima.

48

Aconselha-se escolher identificadores de tipos de grande capacidade (como BIGINT) para que um grande nmero de registros possa ser armazenado. Nota-se o atributo AUTO_INCREMENT para a chave primria idPessoa, logo em seguida fica claro o porqu disso.

Tabela Exemplo 7: Declarao de criao da tabela que armazena a classe Pessoa

Para mapear uma classe numa tabela:

Tabela Exemplo 8: Mapeando a classe Pessoa numa tabela

Os arquivos de mapeamento so fceis de configurar e divididos de maneira bastante intuitiva. Alm disso, a maioria dos parmetros existentes possui valores padro. Este exemplo inicial exibe apenas os parmetros obrigatrios (com exceo do elemento ). obrigatrio especificar o nome da classe e a tabela com a qual est associada. O elemento indica qual o identificador do objeto e como ele criado e obtido. Caso ele seja omitido, o Hibernate considera que a classe no possui identificador. O atributo name indica que atributo da classe ser usado como identificador. O elemento generator informa

como sero gerados os identificadores dos novos elementos. Segue alguns dos tipos de geradores existentes no Hibernate:

49

Tabela 9: Tipo de geradores existentes no Hibernate

Cada atributo da classe mapeado atravs do elemento . O nico parmetro obrigatrio o nome do atributo. O Hibernate tentar encontrar uma coluna com este mesmo nome e definir seu tipo por reflexo. Abaixo, o mapeamento desta mesma classe com os parmetros opcionais (usando o mapeamento simples para executar como exemplo, nota-se que os nomes das colunas foram trocados).

Tabela Exemplo 10: Mapeamento da classe Pessoa com parmetros opcionais

O primeiro parmetro a notar column. Ele indica a coluna correspondente ao atributo da classe na tabela, caso no tenham o mesmo nome. O parmetro type, indica o

50

tipo do atributo Hibernate. Abaixo a associao entre os tipos do Hibernate mais comuns, as classes wrapper Java e os tipos no banco de dados:

Tabela 11: Associao entre tipos do Hibernate, classes wrapper Java e tipos no BD

No mapeamento, pode ser informado na propriedade type tanto o tipo Hibernate quando a classe Java. Outra propriedade opcional importante not-null. Ela indica que no momento da persistncia de um objeto, o determinado atributo pode ser nulo ou no. Caso um atributo esteja indicado como not-null=true e no momento do salvamento ele esteja null, Hibernate ir lanar uma exceo.

essencial lembrar de incluir a linha abaixo no arquivo do hibernate.cfg.xml. Ela indica que este mapeamento deve estar contemplado no SessionFactory.

Tabela Exemplo 12: Mapeamento contemplado no SessionFactory

51

4.3. Hibernate / Persistncia

Hibernate um mecanismo simples e poderoso que permite a persistncia de objetos em banco de dados relacionais de maneira transparente para qualquer tipo de aplicao Java. Esta ferramenta, que pode ser baixada gratuitamente da Internet atravs do endereo http://hibernate.sf.net/, possibilita que os objetos possam ser gravados e recuperados a partir de um banco de dados sem que o desenvolvedor tenha que se preocupar com muitos detalhes. No h necessidade de se implementar mapeamentos hard-coded no cdigo Java. O Hibernate resolve problemas como pool de conexes e configuraes de Datasources.

Em linhas gerais, a codificao de um sistema pode ser dividida em duas partes: regras de negcio e servios de infra-estrutura. Regras de negcio, como o prprio nome

diz, esto relacionadas ao negcio com o qual o sistema visa trabalhar. J os servios de infra-estrutura esto relacionados segurana, cache, transao, servios de nomes, etc. A

idia do Hibernate permitir que o desenvolvedor mantenha seu foco sobre as regras de negcio, liberando-o de parte das tarefas de infra-estrutura.

O Hibernate suporta alguns dos principais bancos de dados relacionais disponveis

no mercado, permitindo a utilizao de meios nativos para gerao de chaves primrias e pessimistic locking. O hibernate trabalha com os bancos de dados atravs de dialetos,

conforme a tabela 1.

Banco de dados Dialeto DB2 cirus.hibernate.sql.DB2Dialect MySQL cirus.hibernate.sql.MySqlDialect SAPDB cirus.hibernate.sql.SAPDBDialect Oracle cirus.hibernate.sql.OracleDialect Sybase cirus.hibernate.sql.SybaseDialect Progress cirus.hibernate.sql.ProgressDialect McKoiSQL cirus.hibernate.sql.McKoiDialect Interbase/Firebird cirus.hibernate.sql.InterbaseDialect Pointbase cirus.hibernate.sql.PointbaseDialect PostgreSQL cirus.hibernate.sql.PostgreSQLDialect HypersonicSQL cirus.hibernate.sql.HSQLDialect Microsoft SQL Server cirus.hibernate.sql.SybaseDialect

Tabela 13 Bancos de dados suportados pelo Hibernate

52

Fonte: www.mundojava.com.br

O desenvolvimento usando Hibernate um processo que pode ser dividido em cinco etapas. O primeiro passo a construo do banco de dados com o qual a aplicao ir trabalhar, ou seja, criar as tabelas onde os objetos sero persistidos. Este banco de dados, com suas entidades, atributos e relacionamentos, poder ser criado de forma tradicional ou, a critrio do usurio, poder ser utilizada a ferramenta SchemaExport que acompanha o Hibernate, Esta ferramenta gera o esquema de banco de dados baseado no relacionamento entre os objetos que se quer persistir. O segundo passo criao dos objetos cujos estados vo ser persistidos, isto , a construo de classes (beans) para cada entidade do banco de dados. Estas classes devem ser construdas seguindo o modelo JavaBeans, com mtodos get e set para manipulao dos atributos. Neste ponto, o Hibernate difere-se de outros mecanismos de persistncias como o JDO, visto que os beans utilizados pelo Hibernate no necessitam estender superclasses ou implementar interfaces. necessria a implementao de um construtor default (construtor sem parmetros) para todas as classes persistentes. O Hibernate faz a instanciao de objetos e o acesso s suas propriedades atravs de reflexo, assim mtodos de acesso e construtores no necessitam ser declarados como pblicos. Adicionalmente, deve ser criada uma propriedade chave-primria, que far s vezes de uma primary key, atravs da qual um objeto ser unicamente identificado. Esta propriedade, no obrigatria, pode ser do tipo primitivo int, long, char ou mesmo uma String.

Aps a criao das tabelas e dos beans necessrio criar meta-dados de modo a fornecer ao Hibernate informaes sobre como relacionar os objetos com as entidades do banco de dados. Esta a terceira etapa, a criao de arquivos XML que relacionam as

propriedades de cada objeto aos campos das tabelas. Nestes arquivos de mapeamento deve-se informar, ainda, qual propriedade do objeto se relaciona com a chave-primria, bem com os relacionamentos entre entidades (inclusive os tipos de relacionamento: 1-1, 1-N ou N-N).

A quarta etapa refere-se criao de um arquivo contendo as propriedades

necessrias para que o Hibernate se conecte ao banco de dados. Existe um arquivo de

53

configurao modelo (hibernate.properties) que poder ser utilizado como base para que o usurio proceda configurao. A quinta e ltima etapa a criao de Data Access Objects (DAO), Tais mecanismos so design pattern teis para separao da lgica de acesso a dados da lgica de negcios da aplicao. Estas classes que contero os mtodos de incluso, alterao, excluso dos objetos, etc.

Em resumo, o Hibernate uma ferramenta que permite trabalhar com persistncia sobre banco de dados, sem necessidade da incluso de instrues SQL em meio ao cdigo Java, assim como elimina a necessidade de se mapear ResultSets e implementar configurao de pool de conexes, etc., o que torna o cdigo mais legvel e, conseqentemente, mais fcil de manter. Contudo a implementao no independente da

fonte de dados, visto que o Hibernate trabalha apenas com alguns dos bancos de dados relacionais. Por outro lado, caso a aplicao exija consultas SQL complexas, h de se considerar a utilizao da linguagem HQL, a Query Language do Hibernate.

Tabela 14 - Comparaes do Hibernate com outros frameworks de persistncia

54

4.5. OJB

O OJB (Object Relational Bridge) faz parte do projeto Jakarta, da fundao Apache, que desenvolve ferramentas de cdigo aberto para Java. Prestes a ter sua primeira verso oficial lanada o OJB baseado em um cerne de mapeamento objeto relacional a partir do qual vrias APIs podem ser disponibilizadas. O OJB e' muito flexivel na forma em que pode ser usado. O desenvolvedor tem opes de 3 diferentes API:

Uma API compativel com o padrao ODMG 3.0

Uma API compativel com o padro JDO da Sun (ainda incompleta).

A PersistenceBroker API que server como o ncleo das demais APIs usada no OJB. Essa API

pode ser usada por qualquer tipo de aplicao.

Podemos considerar OJB comparado ao Hibernate em termos de suporte aos conceitos OO e funcionalidades. O OJB apresenta as vantagens de possuir melhor suporte a distribuio

(com sincronizao de cach) e ser aderente a padres estabelecidos. O mapeamento objeto-relacional do OJB feito atravs de um nico arquivo XML,

cujas marcaes fazem parte de um DTD prprio, e para o mapeamento de hierarquias de classe so permitidos todos os tipos de particionamento (tipado, vertical e horizontal). Inicialmente foi tentado o mapeamento sobre a mesma base de dados utilizada nos testes do Hibernate, com particionamento vertical. Contudo, testes preliminares detectaram algumas falhas do OJB na execuo deste tipo de mapeamento. Devido a este problema o programa de carga utilizado para a gerao da base de dados de testes do Hibernate foi modificado para que tambm fossem geradas na base tabelas que suportassem o particionamento horizontal das classes. A base de dados passou ento a ser usada tanto pelo Hibernate como

pelo OJB, porm com mapeamentos sobre conjuntos diferentes de tabelas. A implementao do modelo de classes, em comparao com o Hibernate, foi um

pouco mais complicada. No caso do OJB tambm foram utilizadas classes simples, apenas com atributos protegidos e mtodos de acesso e modificao.

Contudo, por uma restrio do OJB, para que fosse possvel o uso de sua funcionalidade de carga de objetos sob demanda foi necessrio a definio de interfaces, e fazer que as classes as implementassem, tambm, de forma semelhante ao caso do Hibernate, no foi possvel declarar algumas das classes como abstratas.

55

Cliente

OJB Layers

Backends

Componentes do OJB

O JDO Suporta:

Hypersonic SQL Lutris InstantDB

IBM DB2

Oracle MS Access

MS SQL Server 2000

-Instalar/Configurar

CLIENT APPLICATION

56

Toda a funcionalidade da versao 1.0 ja esta presente na versao atual. Baixe a versao binaria do OJB, a menos que voc queira dar uma olhada na fonte. O arquivo que esta disponvel para download no web site tem valioas arquivos p/ configurar e criar os tutoriais, e algumas aplicaes dentro do OJB. Vou descrever todos os arquivos necessrios para uma aplicao OJB rodar.

-Arquivos Esses so os arquivos JAR que voc precisa no classpath de uma aplicao OJB:

antlr.jar commons-collections-2.0.jar commons-dbcp.jar commons-lang-1.0-mod.jar commons-pool.jar db-ojb-1.0.rc2.jar jta-spec1_0_1.jar

O arquivo OJB.properties contem configuraes especificas de como o ambiente OJB deve rodar. Nele voc configura que pool de conexes quer usar, qual a poltica de cach a ser usada, em que arquivo esta a configurao do banco de dados (chamada de repositrio), e varias outras opes. Em geral, no se precisa mudar nada nesse arquivo, mas, ter uma boa noo e' importante p/ saber que partes do OJB voc pode configurar.

Chegou a vez do arquivo mais importante, onde se configura a aplicao que esta sendo desenvolvida, e o repository.xml, ele contem chamada a outros arquivos XML,

sendo: -repository_database.xml, contem a configurao do acesso ao banco de dados. Aqui, voc

especifica o banco, usurio, senha, enfim, as configuraes normais de uma conexo JDBC. Tambm se pode setar opes do pool de conexes, como a quantidade mxima e inicial de conexes 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 definio como esta a seguir:

Code:

Nesse exemplo, temos uma classe br.com.javafree.ojb.Produto que corresponde a tabela

jf_produto, os campos produto_id e producto_desc correspondem as propriedades id e descrio na classe. A fase de construo do repository_user.xml e' um pouco trabalhosa, mas, os desenvolvedores do OJB esta criando uma aplicao para criar o XML quando voc indica a base de dados, o que agilizara muito esse processo.

Chegou a vez do cdigo, vou mostrar treis exemplos de operao no banco de dados, uma parte do cdigo sempre necessria no uso do OJB, que a chamado ao PersistenceBroker, classe responsvel pela operaes 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() + ""); } } 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 mtodo store() do PersistenceBroker que o OJB se encarrega de armazenar os dados no BD de acordo com o que definido no arquivo repository_user.xml. Percebam que, pelo fato de termos definido o campo produto_id como auto incremento, o prprio OJB se encarrega em calcular essa valor usando a configurao no arquivo OJB.properties. Esse recurso (auto-incremento) exige o uso de uma tabela interna do OJB, que pode ser criada com o seguinte comando SQL, 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 MSICA

Na tabela 15 esto as classe que vo ser utilizada no mapeamento das ferramentas estudadas.

59

TABELA 15 Diagrama de Classe Biblioteca Msica;

5.1.2. Modelo de Mapeamento Hibernate:

Definio 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

// cabealho do xml

60

Definio 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;

// cabealho do xml

61

Type= java.lang.String Column= titulo Length= 255 Not-null= true />

Definio 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;

// cabealho do xml

62

Column= imagem Length= 255 Not-null= true />

Definio da classe Musica;

Public class Musica{ private Long id; private String titulo; private Cd cd;

}

Mapeamento da classe Musica;

// cabealho do xml

63

5.2. Modelo de mapeamento OJB

Definio 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

Definio 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;

Definio da classe Capa;

Import java.uitl.Set; Import java.util.HashSet;

Public class Capa{ private Long id; private String imagem; private Cd cd;

}

65

Mapeamento da classe Capa;

66

5.3. Essas so as tabelas do SQL

CREATE 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)

);

67

CREATE TABLE Artista ( ID INT NOT NULL, NOME VARCHAR(30), PRIMARY KEY (ID) );

5.4. Assim seria a insero nas tabelas uma a uma

INSERT INTO Artista (ID, NOME) VALUES (55, Joo); 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 execuo de cada consulta foi adotado o seguinte procedimento: (1) iniciar o SGBD; (2) iniciar o programa

68

de execuo da consulta; (3) finalizar o SGBD; (4) executar a leitura de arquivos em disco, no relacionados aos testes, para invalidao de cachs e buffers do sistema operacional. Antes da execuo dos testes de desempenho, porm, foi feito tambm um teste inicial para que fosse comprovada a consistncia de resultados en