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 ObjetoRelacional, 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

Aos meus pais Vital e Maria do Carmo

e irmos Helinton e Erica.

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;

" 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 ObjetoRelacional.

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
CASE
OID
OO
OO-ER
UML
XMI
XML
OQL
SGBD
SGBDOO
SGBDOR
SGBDR
SQL
ER

Application Programming Interface

Computer Aided Software Engineering
Object Identification
Orientado a Objeto
Orientado a Objeto Entidade Relacional
Unified Modeling Language
XML Metadata Interchange
eXtensible Markup Language
Object Query Language
Sistema Gerenciador de Banco de Dados
Sistema Gerenciador de Banco de Dados Orientado a Objeto
Sistema Gerenciador de Banco de Dados Objeto Relacional
Sistema Gerenciador de Banco de Dados Relacionais
Structured Query Language
Entidade Relacionamento

8
LISTA DE FIGURAS
FIGURA 1
FIGURA 2
FIGURA 3
FIGURA 4
FIGURA 5
FIGURA 6
FIGURA 7
FIGURA 8
FIGURA 9

Mapeamento Bsico
Mapeamento de Relacionamento (um-para-um)
Mapeamento de Relacionamento (um-para-muitos)
Mapeamento de Relacionamento (muitos-para-muitos)
Uma Tabela para toda Hierarquia
Uma Tabela por Classe Concreta
Uma Tabela por Classe
Uma Viso Simplista do Hibernate
Componentes do Hiberante

9
LISTAS DE TABELAS
TABELA 1
TABELA 2
TABELA 3
TABELA 4
TABELA 5
TABELA 6
TABELA 7
TABELA 8
TABELA 9
TABELA 10

Comparativo entre tcnicas de mapeamento de classe

Parmetros principais para configurao da conexo JDBC
Parmetros que definem comportamentos em tempo de execuo
Criando um SessionFactory atravs do objeto configuration
Classe candidata a persistncia
Implementao da classe pessoa
Declarao de criao da tabela que armazena a classe pessoa
Mapeando a classe pessoa numa tabela
Tipos de geradores presentes no Hiberante
Mapeamento da classe pessoa com parmetros opcionais

TABELA 11

Associao entre os tipos do Hibernate, classes Wrapper Java e tipo no BD

TABELA 12
TABELA 13
TABELA 14
TABELA 15

Mapeamento conteplado no SessionFactory

Banco de dados suportados pelo Hibernate
Comparaes do Hibernate com outros frameworks de persistncias
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, MSSQL 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

Alto

Baixo

Velocidade de acesso Rpido

Rpido

Mdio/Rpido

Suporte a
polimorfismos

Baixo

Alto

Muito alto

Mdio

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
API

de mapeamento;

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-paramuitos, 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 umpara-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 objetorelacional, 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 objetorelacional. 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 objetorelacional, 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
<id>).
obrigatrio especificar o nome da classe e a tabela com a qual est associada. O
elemento <id> 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 <property>. 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 hardcoded 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
DB2
MySQL
SAPDB
Oracle
Sybase
Progress
McKoiSQL
Interbase/Firebird
Pointbase
PostgreSQL
HypersonicSQL
Microsoft SQL Server

Dialeto
cirus.hibernate.sql.DB2Dialect
cirus.hibernate.sql.MySqlDialect
cirus.hibernate.sql.SAPDBDialect
cirus.hibernate.sql.OracleDialect
cirus.hibernate.sql.SybaseDialect
cirus.hibernate.sql.ProgressDialect
cirus.hibernate.sql.McKoiDialect
cirus.hibernate.sql.InterbaseDialect
cirus.hibernate.sql.PointbaseDialect
cirus.hibernate.sql.PostgreSQLDialect
cirus.hibernate.sql.HSQLDialect
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 devese 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 NN).
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

CLIENT APPLICATION

OJB Layers

Backends

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 versao
binaria

do

OJB,

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:

<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 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()
+ "<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 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

<?xml version1.0 encoding= UTF-8?> // cabealho do xml
<!DOCTYPE hibernate-mapping PUBLIC // cabealho 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= cdslazy= true inverse= true>
<key column= artista_id/>
<one-to-many class= Cd/>
</set>
</class>
</hibernate-mapping>

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;
<?xml version1.0 encoding= UTF-8?> // cabealho do xml
<!DOCTYPE hibernate-mapping PUBLIC // cabealho 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= musicaslazy= 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>

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;

<?xml version1.0 encoding= UTF-8?> // cabealho do xml
<!DOCTYPE hibernate-mapping PUBLIC // cabealho 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>
Definio da classe Musica;
Public class Musica{
private Long id;
private String titulo;
private Cd cd;
}

Mapeamento da classe Musica;

<?xml version1.0 encoding= UTF-8?> // cabealho do xml
<!DOCTYPE hibernate-mapping PUBLIC // cabealho 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 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

<class-descriptor
Class=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>
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;
<class-descriptor
Class=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= musicaslazy= 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>
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;

<class-descriptor
Class=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>
Definio da classe Musica;
Public class Musica{
private Long id;
private String titulo;
private Cd cd;
}

Mapeamento da classe Musica;

<class-descriptor
Class=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 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 entre os diversos sistemas testados. Os
contedos dos resultados das consultas foram tomados como referncia e posteriormente
comparados com os constedos dos resultados das consultas executadas pelo Hibernate e o
OJB.
O Hibernate e o OJB apresentam funcionalidades semelhantes aos resumos,
chamadas de consultas escalares e consultas de relatrio, respectivamente.
O Hibernate e o OJB tambm apresentam funcionalidades para distribuio, sendo o
Hibernate mais restritivo e o OJB tendo suporte direto a sincronizao de cach e controle
de concorrncia distribudo.

6.1. Vantagens e desvantagens da utilizao do mapeamento usando a

ferramenta Hibernate
Usando a ferramenta:

O Hibernate torna transparente o acesso ao banco de dados, sendo que ele faz tudo
sozinho, ou seja, ele salva tudo na memria e quando voc termina ele salva tudo no
banco.

O cdigo fica menor e mais eficiente pois o Hibernate otimiza o cdigo.

Voc usa o SQL mas as tabelas so montadas pelo Hibernate.

Com Hibernate voc montaria os objetos mas a insero ele pegaria cada atributo e
montaria os comandos inserts sozinho.
No Usando a ferramenta:

O cdigo 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 utilizao do mapeamento usando a

ferramenta OJB
Usando a ferramenta:

Fcil de utilizar

O cdigo fica bem menor

Ele inseri no banco de dados altomticamente
No Usando a ferramenta:

No tem a caracterstica de um banco de dados robusto
Por exemplo: indexs, transaccion...

No escalavel

O cdigo ficaria bem maior

A insero ao banco de dados seria manual

7. Concluso

70
Apesar da relutncia de alguns em adotar esquemas de persistncia, fica evidente
que sua utilizao trs um ganho considervel de tempo na implementao de um sistema e
eleva a qualidade do produto final, medida que diminui a possibilidade de erros de
codificao. O fraco acoplamento entre as camadas de dados e de lgica do sistema
promovido pelas Camadas de Persistncia outro ponto que demonstra a sua utilidade.
Alm de fornecer um acesso mais natural aos dados, as Camadas de Persistncia executam
controle transacional, otimizao de consultas e transformaes automticas de dados entre
formatos distinto (tabelas relacionais para arquivos XML ou classes Java, por exemplo).
Sem dvida, as Camadas de Persistncia devem funcionar como a principal ponte de
ligao entre sistemas Orientados a Objetos e repositrios de dados diversos: um conceito
poderoso, com implementaes estveis e comprovadamente eficientes.

71
8. REFERNCIA BIBLIOGRFICA
AGILE

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. Introduo 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 edio 1999.
SILBERSCHATZ, A.; KORTH, H. F., SUDARSHAN, S. Sistema de Banco de Dados.
So Paulo: Makron Books, 1999.
MUNDO-OO.Mapeando Objetos para Bancos de Dados Relacionais: tcnicas e
implementaes.[Internet:http://www.mundooo.com.br/php/mooartigos.php?pa=show
page&pid=19, recuperado em 15/03/2005].
ULBRAPersistncia

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 Impedncia[Internet:http://www.intersystems.com.br
/isc/downloads/cachedoctec/ProblemadeImpedncia.pdf, recuperado em 08/04/2005].
JAKARTA PROJECT. Projeto Jakarta [Internet: http://www.jakarta.apache.org
recuperado em 10/10/2005].

72