pi - odailson _ivsemestre

8/12/2019 PI - Odailson _IVsemestre

1/44

Castanhal,2014

ODAILSON NOGUEIRA CARDOSO

SISTEMA DE ENSINO PRESENCIAL CONECTADOANLISE E DESENVOLVIMENTO DE SISTEMAS

PRODUO TEXTUAL INTERDICIPLINAR


2/44

Castanhal2012

SS

PRODUO TEXTUAL INTERDICIPLINAR

Trabalho interdisciplinar (Desenvolvimento Orientado aObjetos, Rede de Computadores e ModelagemOrientada a objetos) apresentado a Universidade Nortedo Paran - UNOPAR

Profs.: Marcio Roberto ChiaveliPaulo K.NIshitaniPolyanna P. Gomes Fabris

ODAILSON NOGUEIRA CARDOSO

Castanhal,2014


3/44

LISTA DE SIGLAS E ABREVIATURAS

BDOO Banco de Dados Orientados a Objetos

BDR Banco de Dados Relacional

BD Banco de Dados

LOO Linguagem Orientada a Objetos

MOR/ORM Mapeamento Objeto-Relacional/Object Relational Mapping

ODMG Object Data Management Group

ODL Object Definition Language

OML ObjectManipulation Language

OID Object Identifier

OO Orientao a Objetos

ORM Object Relacional Mapper

POO Programao Orientada a ObjetosSQL Structured Query Language

SGBDOO Sistema Gerenciador de Banco de Dados Orientado Objetos

UML Unified Modeling Language

XML Extensible Markup Language

Protocolo:144674206

Usurio:

ead00897634


4/44

LISTA DE FIGURAS

Figura 1- Estrutura de BDOO

Figura 2- Classes nibus e caminho

Figura 3- Hierarquia de Herana

Figura 5- Herana mltipla

Figura 6- Exemplo de mapeamento

Figura 7. Mapeamento de um aplicativo Orientado a Objetos

Figura 8 Mapeamento bsico um-para-um

Figura 9- Uma tabela para todas as classes de hierarquia

Figura 10- Uma tabela para classe concreta

Figura 11- Uma tabela por classe

Figura 12- Mapeamento um-para-um

Figura 13- Mapeamento um-para-muitos

Figura 14- Mapeamento muitos-para-muitos

Figura 15- Alto nvel da arquitetura Hibernate


5/44

LISTA DE TABELA

Tabela 1 Diferenas entre os BDOO e BDRs


6/44

SUMRIO

1 INTRODUO....................................................................................................32 OBJETIVOS........................................................................................................5 3. BANCO DE DADOS ORIENTADO A OBJETO"...............................................6

3.1 O que so?.......................................................................................................6

3.2 Caractersticas de um BDOO............................................................................7

3.3 Tipos de BDOO...............................................................................................17

4 DIFERENASENTRE BANCO DE DADOS ORIENTADO A OBJETOS EBANCO DE DADOS RELACIONAIS.........................................,,..............................20

5 MAPEAMENTO OBJETO RELACIONAL..........................................................23

5.1 Conceito..................................................................... ......................................23

5.1 Vantagem do Mapeamento Objeto Relacional................................................26

5.1 Desvantagem do Mapeamento Objeto Relacional..........................................27

6 DESENVOLVENDO EM MOR...........................................................................28

6.1Mapeamento Bsico.......................................................................................28

6.2Mapeamento de herana................................................................................29

6.3Mapeamento de relacionamentos..................................................................31

7 PRINCIPAIS FERRAMENTAS DE MAPEAMENTO OBJETO

RELACIONAL.........................................................................................................34

7.1Hibernate.......................................................................................................34

7.2TopLink..........................................................................................................35

7.3OpenJPA.......................................................................................................35

8 CONCLUSO..................................................................................................37

9 REFERNCIAS BIBLIOGRFICAS................................................................39


7/44

3

1 INTRODUO

A tcnica da orientao a objetos est cada vez mais popular para projetar e

implementar sistemas de natureza variadas. Com relao a bancos de dados, essas

tcnicas tem sido empregadas, com predominncia, nos casos aonde os dados

envolvidos na aplicao considerada apresentam estrutura complexa. A diferena

existente entre os modelos de dados tradicionais (relacional, hierrquico e em redes)

e os modelos de dados orientados a objetos est na maneira como eles veem os

dados.

Os modelos de dados tradicionais detalham os dados como uma coleo de

tipos de registros ou relaes, cada um tendo uma coleo de registros ou tuplasarmazenadas em um arquivo. J num modelo de dados orientado a objetos (OO); o

banco de dados considerado como uma coleo de objetos do mundo real.

Considerando que o volume dirio de transaes de uma empresa pode ser

muito grande, necessrio elaborar a melhor soluo para a atualizao e

replicao dos dados, pois o trafego na rede ir aumentar substancialmente, o que

far, dependendo da soluo que for adotada, que as respostas s requisies feitas

pelos usurios em suas estaes de trabalho sejam muito lentas.Por esse motivo, os profissionais de TI necessitam adotarem alternativas

eficientes para realizar consultas e alteraes dos dados sem que haja o

comprometimento do desempenho da rede.

Portanto, este trabalho tem por base a construo de um portflio individual

dissertativo, que abordem, em carter exploratrio e descritivo, as principais

caractersticas, aspectos e propriedades dos bancos de dados orientados a objetos

(BDOO) e do Object Relational Mapper (ORM). Trata-se de um trabalho curricular

interdisciplinar que exibe como meta central aproximar os discentes dos principais

conceitos, propriedades, comparaes e controvrsias sobre o universo de

desenvolvimento de banco de dados.

Sendo assim, este portflio individual, partindo de uma pesquisa exploratria

e descritiva na literatura, abordar os seguintes tpicos: (1) caracterizao,

aplicao e mecanismo de funcionamento dos BDOO; (2) Principais diferenas entre

BDOO e Banco de dados relacionais e (3) definio e particularidades do ORM.

Todos esse itens visam integrar assuntos de todas as disciplinas trabalhadas, do

segundo semestre de 2014, do curso superior de tecnologia em Anlise e


8/44

4

Desenvolvimento de Sistemas, dentro do eixo temtico desenvolvimento de sistemas

de informao I, da Unopar.


9/44

5

2 OBJETIVOS

2.1 Objetivo Geral:

Este trabalho buscou atender os critrios de interatividade e regionalidade

da produo interdisciplinar em individual, do primeiro semestre do superior de

Tecnologia em Anlise e Desenvolvimento de Sistemas, ano 2014, tendo como base

os assuntos no eixo temtico Desenvolvimento de Sistemas de Informao II. A

finalidade construir uma dissertao que aborde a resoluo de questes definidas

no documento de produo textual individual, envolvendo paralelamente, osconceitos trabalhados nas seguintes disciplinas: Desenvolvimento Orientado a

Objetos, Redes de Computadores e Modelagem Orientada a Objetos.

2.2 Objetivos Especficos:

Caracterizar o BDOO: especificando definio, aplicao e mecanismo de

funcionamento;

Analisar, Comparar e diferenciar o BDOO do BDR;

Caracterizar o ORM: especificando e detalhando os seguintes requisitos: (1)

definio e utilidade; (2) principais ferramentas de ORM disponveis no

mercado e (3) vantagem e desvantagem desse modelo;


10/44

6

3 BANCO DE DADOS ORIENTADO A OBJETOS

At o incio dos anos 60, as informaes eram armazenadas de maneiraaleatria em arquivos, gerando altos custos para as empresas que necessitavam

empregar um grande nmero de profissionais para armazenar e organizar os

arquivos. A partir desta situao, surgiram os primeiros Sistemas Gerenciadores de

Banco de Dados (SGBD), provendo capacidade de armazenamento dos dados de

forma uniforme e independente aplicao, baseados no modelo relacional.

A partir dos anos 80, os sistemas computacionais evoluram, somando

crescimento ao poder de processamento das mquinas, fazendo surgir necessidade

de tratar dados no- convencionais, de maior complexidade. No entanto, os SGBD

relacionais continuavam a armazenar as informaes de maneira uniforme. Devido a

essa carncia no tratamento de dados complexos, ficou clara a necessidade de

serem criadas formas mais adequadas para o armazenamento e representao

destes dados.

Paralelamente a esta necessidade, surgiram s tecnologias orientadas a

objetos sustentados na comunidade de desenvolvimento de software, sobretudo

facilidade de alterao das implementaes, de acordo com mudanas solicitadas

nos requisitos. A capacidade que esse paradigma possui de representar dados

complexos uniu-se tecnologia de banco de dados, criando os Bancos de Dados

Orientados a Objetos (BDOO) que suportam, tanto na modelagem quanto na criao

de dados, os objetos.

3.1 O que so ?

Carvalho (2011, p. 19) destaca que o BDOO so nada mais que a juno

entre os conceitos de OO com conceitos de SGBD. Contudo, para Elmasri e

Navathe (2005, p. 459) Uma caracterstica-chave dos bancos de dados orientados a

objetos o poder dado ao projetista para especificar tanto a estrutura de objetos

complexos quanto as operaes que podem ser aplicadas a esses objetos.


11/44

7

Ainda seguinte essa linha de pensamento, Silberschatz et al(1999), destaca

que um banco de dados orientado a objetos consiste um gerenciador de grandes

volumes de informao que tem a estrutura de armazenamento de dados baseado

no paradigma de orientao a objetos. A sua criao ocorreu quando houve uma

necessidade de se trabalhar com aplicaes complexas, implementadas em

linguagens OO e com estrutura complexa de armazenamento de dados que

possussem algumas capacidades como continuidade, simultaneidade e transaes

dos seus ambientes.

Na verdade, umas das grandes razes de existirem os BDOO so atender

s necessidades das aplicaes mais complexas e o uso crescente de linguagens

de programao orientadas a objetos no desenvolvimento de aplicaes desoftware. A modelagem dos dados orientados a objetos possuem caractersticas que

diferem muito da forma tradicional das modelagens de dados que so utilizadas

pelos bancos de dados relacionais, apesar de possuir algumas semelhanas,

especialmente, relativas cardinalidade das relaes entre as entidades. A figura 1

ilustra e identifica as principais propriedades que um BDOO deve atender.

Portanto, BDOO basicamente um sistema em que a unidade de

armazenamento o objeto, com o mesmo conceito das linguagens de POO. Adiferena fundamental est no fato que em BDOO, os dados no deixam de existir

aps o encerramento do programa, ou seja, os objetos continuam a existir mesmo se

o sistema venha a ser encerrado. Com isso os dados, isto , os valores dos atributos

que fazem referncia a seus respectivos objetos deixam de existir. Este conceito

conhecido como persistncia.

Figura 1- Estrutura de BDOO


12/44

8

3.2 Caractersticas de um BDOO

Os BDOOs so baseados nos conceitos de modelos de dados orientados a

objetos. Diferentemente dos BDRs que foram desenvolvidos para dar suporte s

necessidades das aplicaes comerciais tradicionais, os BDOOs foram

desenvolvidos para satisfazer aos requisitos impostos por aplicaes mais

avanadas, ditas no convencionais. Essas aplicaes no convencionais

apresentam requisitos e caractersticas tais como:

- necessidade de estruturas complexas para representar objetos;

- necessidade de novos tipos de dados para armazenar informaes, tais

como imagens, voz e documentos textuais grandes;- requisitos de manipulao de dados no bem suportados pelos SGBDs

tradicionais.

Alguns conceitos encontrados nas linguagens de programao orientadas a

objetos (LPOO) so tambm aplicados nos modelos de dados orientados a objetos,

porm bancos de dados requerem alguns conceitos prprios. Os objetos, em uma

LPOO, existem somente durante a execuo do programa e so, por isso,

chamados de transitrios. Um banco de dados orientado a objetos pode estender aexistncia dos objetos de modo que eles sejam armazenados permanentemente,

isto , os objetos so persistentes ( eles persistem aps o trmino do programa e

podem ser recuperados posteriormente e compartilhados por outros programas).

Segundo Atkinson (2003), um banco de dados O.O. deve satisfazer

basicamente a dois critrios:

1) O banco deve caracterizar-se enquanto um SGBD, implementando osseguintes recursos:

Persistncia: O objeto deve ser capaz de sobreviver fora dos limites da

aplicao que o criou. Este recurso equivalente definio de durabilidade

nas propriedades ACID.

Gerenciamento de memria secundria: Este recurso inclui o

gerenciamento de ndices, clusters de dados, buffers e otimizao de

consultas (queries). Enfim, recursos de desempenho em geral. Estes fatores

devem ser invisveis ao usurio, isto , deve haver uma independncia entre

o modelo fsico e lgico do sistema.


13/44

9

Concorrncia: Deve permitir o acesso simultneo aos dados e prover

mecanismos (como locks de acesso) para que os dados sejam mantidos em

um estado ntegro mesmo sendo acessados concorrentemente. Este recurso

o equivalente definio de atomicidade das propriedades ACID.

Tolerncia a falhas: Em caso de falhas de software ou hardware, o

sistema deve fornecer mecanismos de recuperao, isto , de retorno a um

estado coerente de dados.

Queries ad-hoc: O sistema deve permitir alguma forma de consulta de

alto nvel base de dados, efetiva em qualquer SGBDOO (independente de

aplicao).

2) O banco deve caracterizar-se enquanto um sistema O.O., apresentando:

Suporte a objetos complexos: Construtores aplicados a tipos simples de

objetos representam objetos complexos, e estes devem ser ortogonais

(aplicveis a qualquer objeto). Entre eles esto os construtores de tupla, que

representam as propriedades de uma entidade, set, list e bag.

Identidade: Cada objeto deve apresentar um identificador de objeto (OID)nico, que deve ser persistente. Dois objetos podem compartilhar

componentes, sendo assim atualizaes nos componentes devem refletir em

ambos.

Encapsulamento: Distino entre especificao (interface) e

implementao (estado). Em geral, o encapsulamento deve envolver os

dados de forma a mant-los apenas acessveis pelas operaes (ou

mtodos) do objeto. Tipos e classes: O suporte a mecanismos estruturados de dados, sejam

tipos ou classes (dependendo da abordagem da linguagem), fundamental.

Este conceito substitui o esquema dos bancos de dados tradicionais pelo

conceito de conjunto de classes ou tipos.

Hierarquias de classes ou tipos: O conceito de herana (simples) um

requisito fundamental de um SGBDOO.

Sobrecarga e la te bind ing: O polimorfismo implementado atravs de

mtodos de sobrecarga e sobrescrita. Late binding necessrio para que a


14/44

10

linguagem seja capaz de associar, em tempo de execuo, a mensagem

enviada a um objeto a seu respectivo mtodo.

Extensibilidade:A linguagem deve apresentar mecanismos de definio

de novos tipos pelo usurio, alm de tipos pr-definidos.

Completude computacional: Refere-se capacidade do sistema de

executar qualquer funo computvel, utilizando-se da linguagem de

manipulao de dados do prprio SGBD.

Os bancos de dados orientados a objetos tambm possuem uma linguagem

de consulta: a OQL (Object Query Language), proposta pela ODMG (Object

Database Management Group). Entretanto, ela ainda pouco utilizada, dando lugar

muitas vezes utilizao de iteradores em colees de objetos.A ODMG a responsvel pela definio dos padres dos bancos orientados a

objetos, assim como pela definio do modelo de objeto. Entretanto, as

implementaes variam entre os distribuidores. Por outro lado, segundo Cettel

(2000), Outras propostas de padro da ODMG, que ainda no atingiram um grau

significativo de aceitao, so a ODL (Object Definition Language) e a OML (Object

Manipulation Language) ()

A seguir, sero detalhadas as principais caractersticas envolvidas em

bancos de dados orientados a objetos:

3.2.1 Objeto e Identidade

Cada entidade do mundo real modelada como um objeto.

A cada objeto associado um estado e um comportamento: o estado

representado pelos valores dos atributos do objeto; o comportamento definido

pelos mtodos que agem sobre o estado do objeto pela invocao de operaes.

A cada objeto armazenado no banco de dados associado um identificador

nico (OID: Object Identifier), que gerado pelo SGBDOO (sistema de

gerenciamento de banco de dados orientado a objetos). O valor do OID no e visvel

ao usurio, mas usado internamente pelo sistema para identificar cada objeto de

forma nica e criar e gerenciar referncias entre objetos.


15/44

11

A principal propriedade de um OID que ele imutvel, isto , o valor do

OID de um particular objeto no deve mudar. O SGBDOO deve ter algum

mecanismo para gerenciar OIDs e preservar a propriedade de imutabilidade.

tambm desejvel que cada OID seja usado somente uma vez, isto , os OIDs dos

objetos que so removidos do banco de dados no so reaproveitados.

As duas propriedades acima implicam que o OID no deve depender de

nenhum valor de atributo do objeto. Geralmente considerado no apropriado

basear o OID no endereo fsico do objeto no meio de armazenamento, uma vez

que o endereo fsico pode mudar aps a reorganizao do banco de dados.

Entretanto, alguns sistemas usam o endereo fsico como OID, para aumentar a

eficincia de recuperao do objeto. Nesse caso, se o endereo fsico do objetomuda, pode ser colocado um ponteiro indireto no primeiro endereo, indicando a

nova localizao fsica do mesmo. mais comum usar inteiros longos como OIDs e

uma funo hash para mapear o valor do OID para o endereo fsico do objeto.

3.2.2 Valores

A maioria dos SGBDOOs representam as entidades primitivas, tais como

inteiros ou caracteres, por valores (no possuem OIDs), enquanto as entidades no

primitivas so representadas como objetos. J outros sistemas, como o O2,

permitem a definio de valores complexos que no podem ser compartilhados por

outros objetos, uma vez que valores no possuem OIDs.

3.2.3 Estrutura do objeto

O valor de cada atributo de um objeto pode ser:

- atmico: integer, real, character, booleano, etc.

- complexo: definido atravs de construtores: tuple, set, list, bag e array.

O construtor de tipo tuple serve para agregar informaes afins.

frequentemente chamado de tipo estruturado, pois corresponde ao construtor struct

nas linguagens de programao C e C++.Os construtores de tipo set, list, array e bag so chamados de tipos de

coleo e servem para definir atributos multivalorados. Podem ser no ordenados


16/44

12

(set e bag) ou ordenados (list e array). Em um set no pode haver dois elementos

com o mesmo valor, enquanto que na bag isso possvel.

3.2.4 OIDs X Chaves primrias

Nos modelos orientados a objetos no existe o conceito de chave primria

como acontece no modelo relacional. Ao invs disso, existem os OIDs dos objetos

que, como j dito, so criados e mantidos pelo sistema de gerenciamento de banco

de dados e no so de acesso do usurio.

As vantagens do uso de OIDs com relao s chaves so:

- os programadores de aplicaes no precisam se preocupar com a seleo de

chaves para as vrias classes de objetos;

- obtm-se melhor desempenho, pois os OIDs so implementados em baixo nvel

pelo sistema;

- embora as chaves sejam mais significativas ao usurio, muitas vezes o usurio

precisa usar cdigos artificiais, sem significado semntico, para poder identificar as

tuplas de uma relao.

3.2.5 Objetos complexos

A composio estrutural de um objeto definida atravs de um conjunto de

atributos. O valor de cada atributo pode ser primitivo, um objeto ou uma

combinao dos construtores tupla, lista, array, conjunto ou bag, envolvendo outros

objetos ou no. Objetos complexos so definidos atravs de construtoresenvolvendo outros objetos.

Quando o valor de um atributo de um objeto O um objeto O, o sistema

armazena o identificador de O em O ou todo o valor complexo armazenado no

atributo do objeto.


17/44

13

3.2.6 Encapsulamento

A cada objeto est associada sua estrutura e seu comportamento (os

mtodos ou operaes). O comportamento armazenado no banco de dados junto

com a estrutura do objeto.

O conceito real de encapsulamento determina que somente as operaes

sobre os objetos so visveis e sua estrutura escondida. Em banco de dados a

noo de invisibilidade da estrutura do objeto afrouxada. desejvel, por exemplo,

poder consultar os atributos do objeto atravs de uma linguagem de consulta. Assim,

a maioria dos SGBDOOs permitem acesso direto aos atributos fornecendo

operaes definidas pelo sistema para a leitura e modificao dos atributos, o quelivra o usurio da incumbncia de implementar uma considervel quantidade de

mtodos cujo nico propsito ler e escrever os valores dos vrios atributos dos

objetos. Isso um exemplo de violao do encapsulamento permitida pelos

SGBDOOs. Esses sistemas, porm, possuem mecanismos para que o usurio

possa proteger o acesso aos atributos dos objetos, caso desejvel. O sistema O2,

por exemplo, permite o usurio estabelecer quais atributos e mtodos so visveis na

interface do usurio, atravs da declarao public, o que permite serem invocadospor qualquer outro objeto. Os no visveis so referidos comoprivate.

3.2.7 Mtodos

Os objetos nos SGBDOOs so manipulados atravs de mtodos. Em geral,

a definio de um mtodo consiste de assinatura e corpo. A assinatura especifica o

nome do mtodo, os nomes e classes dos argumentos e a classe do resultado, se

existir. O corpo representa a implementao do mtodo e consiste de um conjunto

de instrues expressas em uma dada linguagem de programao.

3.2.8 Tipos e classes

Um tipo modela as caractersticas comuns de um conjunto de objetos ecorresponde noo de tipos abstratos de dados. Uma classe um conjunto de


18/44

14

objetos que tem exatamente a mesma estrutura interna, i., os mesmos atributos e

mesmos mtodos.

Os modelos de dados orientados a objetos usam o conceito de classe como

uma base para instanciao.

3.2.8 Herana

um mecanismo de reusabilidade muito poderoso. Com herana, uma

classe chamada uma subclasse pode ser definida com base na definio de outra

classe chamada a superclasse. A subclasse herda os atributos, mtodos e

mensagens de sua superclasse e pode ter atributos especficos, mtodos e

mensagens adicionais.

Exemplo: Considere duas classes com informaes sobre um conjunto de

nibus e caminhes. As caractersticas das duas classes so mostradas na figura 2.

A notao grfica utilizada representa cada classe por um retngulo dividido em 3

partes. A parte superior contm o nome da classe; a do meio contm os atributos e a

inferior contm os mtodos definidos pelo usurio. Como as duas classes possuem

algumas caractersticas em comum, pode-se criar a classe Veculo para conter

essas caractersticas, como na figura 3. Somente as caractersticas prprias de cada

subclasse so mantidas na mesma.

Figura 2- Classes nibus e caminho


19/44

15

Figura 3- Hierarquia de Herana

Vantagens da utilizao de hierarquias de classe:- diminui a quantidade de cdigo a ser escrito;

- propicia uma descrio mais precisa e concisa da realidade.

Em certos sistemas, uma classe pode ter vrias superclasses, em cujo caso diz-se

que ocorre herana mltipla (fig.4), enquanto outros impem a restrio de uma

nica superclasse, dita herana simples.


A herana mltipla pode provocar problemas de conflitos, como por exemplo,

duas ou mais superclasses podem ter um atributo com o mesmo nome, mas com

diferentes domnios. Esses conflitos precisam ser tratados pelo sistema. Se existe

uma relao de incluso entre os domnios, ento o domnio mais especfico ser

escolhido como o domnio para a subclasse. Por exemplo, se na classe Veculoexistir o atributo combustvel cujo domnio : (gasolina, lcool, diesel) e em


20/44

16

Veculo_Passageiroexistir tambm o atributo combustvel cujo domnio (diesel),

a classe nibusherdar o atributo combustvel cujo domnio ser (diesel) (figura

5), isto , o domnio mais restrito. Se essa relao no existe, uma soluo adotada

a escolha do domnio com base na ordem de precedncia entre as superclasses.

Outros sistemas deixam por conta do usurio a resoluo do conflito.


3.2.9 Polimorfismo

Os SGBDOOs oferecem o recurso de polimorfismo de operaes, tambm

conhecido como sobrecarga de operador (overloading). Outros conceitos

relacionados com o polimorfismo so os de late binding (ligao tardia) e overriding

(redefinio de

operao).

Para melhor expor esses conceitos, considere uma operao display que

recebe um objeto como entrada e apresenta o objeto na tela. Se o objeto for:

- uma imagem: deseja-se apresentar a imagem;

- uma pessoa: deseja-se apresentar os dados sobre a pessoa (nome, endereo, etc);

- um grfico: deseja-se apresentar uma representao grfica.

Usando um sistema convencional, seriam necessrias 3 operaoes:

display_pessoa, display_figura e display_grfico, como mostrado a seguir:


21/44

17

for x in X do

begin

case of type(x)

pessoa: display_pessoa(x);

figura: display_figura(x);

grfico: display_grfico(x);

end;

end;

Em um sistema orientado a objetos, a operao display pode ser definida em

uma classe mais geral. A operao tem um nico nome e pode ser chamadaindiscriminadamente por vrios objetos. A implementao da operao redefinida

para cada uma das subclasses. Essa redefinio chamada overriding. O sistema

decide qual implementaco usar para execuo. Assim, o cdigo dado simplificado

para:

for x in X do display(x)

A ligao do nome da operao com a correspondente implementao

realizada em tempo de execuo. Essa ligao retardada dita late binding.

A sobrecarga (overloading) de operador refere-se ao uso do mesmo smbolo

de operador para denotar operaes distintas sobre diferentes tipos de dados.

3.3 Tipos de BDOO

Os bancos de dados orientados a objetos podem ser divididos em dois

grupos:

Bancos de Dados Puramente Orientados a Objetos (BDPOO): baseia-se

somente no modelo de dados orientado a objetos. Est baseado no conceito

de objetos persistentes e usa declaraes de classes muito semelhantes sdeclaraes das linguagens orientadas a objetos;


22/44

18

Bancos de Dados Objeto-Relacionais (BDOR): correspondem a bancos

relacionais que possibilitam o armazenamento de objetos.

3.3.1 Caractersticas dos BDPOO

As principais caractersticas dos Bancos de Dados Puramente Orientados a

Objetos so:

Permitem a representao de relacionamentos 1-n, n-n e de herana;

A representao de um relacionamento feita incluindo-se dentro de um

objeto os object identifiers dos outros objetos com os quais ele se

relaciona;

Object Identifier um identificador interno do banco de dados para cada

objeto. Os object identifiers so atribudos e utilizados somente pelo

SGBD, nunca pelos usurios.

No possuem um padro nico de implementao como os bancos

relacionais. Assim, cada produto tem a sua prpria especificao para

criao de classes e relacionamentos;

Os BDPOO tendem a seguir um padro estabelecido pelo ODMG (Object

Database Management Group). A ltima verso disponibilizada pelo ODMG a

verso 3.0, que pode ser obtida em no endereowww.odmg.org.

3.3.2 Caractersticas dos BDOR

Com relao aos Bancos de Dados Objeto-Relacionais, pode-se dizer que

as principais caractersticas so:

Um banco objeto-relacional um banco que permite o armazenamento de

objetos em suas tabelas;

Uma classe representa um domnio, atuando como um data type para uma

coluna. A classe, diferentemente dos bancos orientados a objetos, no

representa mais um elemento envolvido em relacionamentos;

Todas as regras de um banco relacional continuam vlidas;
http://www.odmg.org/http://www.odmg.org/http://www.odmg.org/http://www.odmg.org/


23/44

19

Uma coluna cujo data type seja uma classe, s poder ter uma instncia

desta classe. Imagine, por exemplo, uma coluna cujo data type seja uma

classe TELEFONE. Nos BDOR, esta coluna no poder ter vrias instncias

da classe TELEFONE, mas apenas uma. Se o banco fosse OO, poderia ter

mais do que uma.

Dentre as principais vantagens dos BDOR, pode-se citar que todo o suporte

para ao paradigma orientado a objetos est presente. Alm disso, j existe um

padro de implementao estabelecido, determinando certa facilidade de

convivncia com os sistemas j existentes.


24/44

20

4 DIFERENAS ENTRE BANCO DE DADOS ORIENTADO A OBJETOS E

BANCO DE DADOS RELACIONAL

Em sistemas computacionais, os BDOOs podem atuar como uma alternativa

aos BDRs tradicionais para preservao de informaes. A principal diferena est

na forma da representao da informao que vai ser preservada, como tambm,

recuperada. Ou seja, na interface que oferece ao desenvolvedor de sistemas.

Enquanto os relacionais fazem uso de tabelas; os que implementam a tecnologia

orientada a objetos, valem-se, da prpria concepo e definio dos objetos. Por

isso, BBDRs e BDOOs possuem caractersticas distintas, mas basicamente servem

ao mesmo propsito: persistncia de dados necessrios para as manutenes denegcios para os quais so aplicados, possibilitando a recuperao, comparao e

tratamento desses dados a fim de produzir resultados tangveis.

Como j apresentado, os Banco de Dados Orientado a Objetos (BDOO)

sugiram da necessidade de armazenar dados complexos e de acabar com a

disparidade que havia na modelagem da aplicao e do Banco de Dados (BD).

Logo, as vantagens do BDOO vieram rapidamente tona: possui uma abordagem

flexvel, facilidade de manusear objetos complexos, trabalha com noes de objetos,classes, relacionamento e identidade de objetos.

Em BDR, entretanto, uma coleo de tabelas, todas com nomes nicos,

compem a base de dados, podendo estar relacionada a uma ou mais tabelas.

Conceitos como integridade referencial de dados que garantem que um dado

referenciado em uma tabela esteja presente na tabela que est sendo referenciada

e chaves primrias esto presentes e garantem que um conjunto de informaes

possa ser representado de maneira consistente, independente da forma de acesso.

Sendo assim, os bancos de dados relacionais so baseados no modelo

relacional, cujo fundamento encontra-se na lgebra relacional. Este tipo de

abordagem permite o desenvolvimento de um modelo lgico dos dados

armazenados no banco. Os dados so armazenados em tuplas, um conjunto de

atributos, constitudos por domnio (tipo de dados) e valor (o dado em si). A definio

de um domnio ou combinao de domnios que identifica individualmente cada

elemento da relao chamada de chave primria, enquanto a identificao da

relao entre os itens nicos da tabela dada por uma chave estrangeira.


25/44

21

Contudo, BDOO possui trs pilares principais: herana, polimorfismo e

encapsulamento, como descrito no item 3.2. Este modelo apresenta maior

flexibilidade na manipulao de seu contedo e por meio de identificadores de

objetos manipula os dados de forma consistente. A tabela 1 demonstra essas

diferenas entre os dois modelos.

Tabela 1- Diferenas entre os BDOO e BDRs

BDR- Banco de Dados relacionais

BDOO- Banco de dados Orientado a Objetos

Silbeschatz et. al. (2001) concluem que as bases de dados tradicionais so

bastante eficientes para tarefas ligadas ao processamento de dados. A gerao de

folhas de pagamento e o gerenciamento de contas correntes, so exemplos. Esse

tipo de aplicao trabalha basicamente com tipos de dados simples: numricos,

texto e datas. Alm disso, essas aplicaes possuem itens de dados que podem ser

representados como registros razoavelmente pequenos e campos atmicos.

Critrios de comparaoBanco de dados Orientado a

Objetos (BDOO)

Banco de Dados Relacionais

(BDR)

Representao da informao Baseado no conceito de objetos Baseado em tabelas

Modelo de dadosFundamenta-se a partir de

coleo de objetos do mundo real

Evidenciado a partir de registros

ou relaes

Aplicabilidade

Em softwares comerciais

tradicionais em que no

necessitem trabalha com dados

complexos

Software de engenharia,

software de pesquisa cientificas,

sistema de informao

multimdia e sistema deinformao geogrfico

AbordagemFlexvel e prxima do mundo

real

Rgida e com dificuldade em

lidar com informaes

complexas do mundo real

Vantagemabstrao da realidade mais

simplificada e reutilizaoConfiveis e eficientes

Desvantagem Imaturos e pouco confiveisDificuldade em abstrair a

realidade


26/44

22

Apesar do conceito de bancos de dados orientados a objetos ser bastante

distinto do modelo relacional, o mesmo resulta da integrao entre a orientao a

objetos e a tecnologia de banco de dados tradicionais. Enquanto na programao

orientada a objetos, os objetos existem apenas enquanto o programa que os criou

est em execuo, os bancos de dados orientados a objetos podem criar objetos

que sejam persistentes e compartilhados entre diferentes aplicativos.


27/44


28/44

24

maioria das vezes, no gera correlao; foi preciso criar uma metodologia que

permitisse a compatibilidade entre a LOO e BDRs. Com o surgimento do Object

Relational Mapping isso ocorreu, j que essa tcnica garante a persistncia

automatizada dos objetos para as tabelas em banco de dados relacional, atravs do

uso de meta dados que descrevem o mapeamento entre os objetos e o banco de

dados.

O termo Mapeamento Objeto-Relacional definido como a tcnica de

mapear o registro do banco de dados em objetos, persistir as informaes contidas

nos objetos em forma de linhas e colunas. Responsvel por mapear classes e

atributos do modelo orientado a objeto para tabelas e colunas do banco de dados.

Entretanto, existem diversos conceitos na orientao a objeto para os quais omodelo relacional no oferece suporte. Umas das diferenas entre objetos e banco

de dados relacionais a forma de representao dos relacionamentos. Os objetos

trabalham com ponteiros ou referncias para outros objetos, que so criados em

tempo de execuo, enquanto no banco de dados esto relacionados por sua

estrutura vinculada por chaves primrias e estrangeiras (DALLOGLIO, P., 2009, p.

223).

Figura 6- Exemplo de mapeamento

A Figura 6 demonstra que o Mapeamento Objeto-Relacional faz uma relao

entre a classe e tabela com suas linhas e colunas.

No paradigma orientado a objetos, alm dos atributos temos

comportamentos que so mtodos, entre outras estruturas complexas, heranas,agregaes e composies. Assim surgiu a necessidade de ferramenta para


29/44


30/44

26

d atravs de uma interface de programao (API Application Programming

Interface) de conectividade do banco de dados, que responsvel em fazer o envio

de instrues SQL para o banco de dados relacional. A tarefa de persistir objetos

utilizando instrues SQL atravs daAPI de conectividade muito trabalhosa e

tediosa, o que pode gerar erros nodesenvolvimento do sistema (BAUER, 2007, p.

22).

Persistncia em Banco de Dados Orientado a Objetos: persistncia em

banco de dados orientados a objetos, trabalha com um banco de dados puramente

orientado a objetos. Seu funcionamento se d com o armazenamento de dados

organizados em hierarquias de classes e no em tabelas. O problema que este

tipo de banco de dados no possui uma utilizao muito difundida, devido a sua faltade padronizao. Suas APIs possuem diferenas de um banco de dados para outro,

no permitindo assim uma portabilidade do sistema, o que no bom, pois dentro

da comunidade de desenvolvedores de sistemas orientado a objetos o que mais

valorizado justamente a padronizao e portabilidade de um sistema

(DOEDERLEIN, 2005, p.22).

5.2 VANTAGEM DO MAPEAMENTO OBJETO RELACIONAL

De acordo com Esjug (2007, p.14) implementar um mapeamento objeto

relacional pode ser considerada uma tarefa complexa, porm esta tecnologia possui

algumas vantagens:

Produtividade com a eliminao dos cdigos SQL no cdigo fonte, as

classes passam a ser mais simples e com isso o sistema desenvolvido em menor

tempo.

Manutenibilidade por reduzir o nmero de linhas do cdigo fonte do

sistema, menor ser o trabalho de manuteno do sistema.

Desempenho o tempo economizado no desenvolvimento, pode ser

dedicado a programar otimizaes do sistema.

Independncia de Fornecedorpor mais que um banco de dados utilize a

mesma linguagem SQL, alguns comandos, tipos de dados, podem ser diferentes de

um banco para outro.


31/44

27

5.3 DESVANTAGEM DO MAPEAMENTO OBJETO RELACIONAL

A adoo da tcnica de Mor, na maioria das vezes, torna-se um trabalho

complexo e minucioso. Inicialmente a adoo da tcnica parece ser benfica, mas

no longo prazo, segundo Voss (2011), poder trazer consequncias negativas do

que positivas.

Voss (2011) resume algumas vantagens das tcnicas e ferramentas de ORM

como simplicidade, gerao de cdigo e eficincia mnima, mas d enfoque maior

aos problemas, apontando os trs principais:

Abstrao inadequada.O problema mais bvio de tecnologias ORM,

segundo o autor, vem de uma abstrao inadequada. Por exemplo, a

documentao de grande parte das bibliotecas de ORM cita conceitos de SQL.

Mas uma abstrao que exige o aprendizado de SQL e de conceitos de bancos

relacionais, alm de uma nova API, no estaria atingindo o seu principal objetivo:

simplificar e esconder do desenvolvedor os detalhes de implementao.

Abstrao incorreta: Outro problema destacado o uso do tipo

errado de datastore. O carga adicional de recursos para usar um banco de dados

relacional geralmente grande e este o motivo, argumenta Voss (2011), pelo

qual a tecnologia NoSQL possui desempenho superior.

Excesso de consultas. Outro problema comum do ORM, segundo

Voss (2011), a ineficincia. Na consulta de um objeto, o ORM no "sabe" quais

propriedades (ou colunas de uma tabela) so necessrias e por isso traz todas

elas. Ele cita que vrios mecanismos de ORM tm problemas graves no

gerenciamento de joins e gerando um nmero imenso de consultas

desnecessrias. Embora sejam problemas conhecido e j se tenha tentandoresolv-los atravs de vrias tcnicas como caching e lazy-loading, o autor deixa

claro que considera as solues encontradas pouco satisfatrias.


32/44

28

6 DESENVOLVENDO EM MOR

A tcnica de mapeamento de objetos para o modelo relacional consiste

basicamente em representar uma classe, como se fosse uma tabela no banco de

dados, sendo as colunas da tabela representadas atravs de atributos da classe, e

as instncias (objetos) desta classe representando os registros (linhas) contidos na

tabela. Por sua vez um atributo pode representar um relacionamento existente com

uma tabela (AMBLER, 1998).

Conforme Ambler (2002), os trs conceitos bsicos de transformao do

modelo OO para o modelo relacional so:

a) mapeamento bsico;b) mapeamento de herana;

c) mapeamento de relacionamentos.

6.1 MAPEAMENTO BSICO

O mapeamento simples de objetos tem como principal objetivo descrever a

forma de persistir apenas as informaes relevantes para o modelo relacional e de

objetos, garantindo que apenas os atributos de valor primitivo (inteiro, ponto

flutuante, string, entre outros) sejam mapeados, no levando em considerao os

relacionamentos existentes entre duas ou mais classes, onde existe a necessidade

de tratar recursivamente o relacionamento (AMBLER,1998).

Uma forma prtica para realizar o mapeamento entre os atributos de uma

classe com as colunas da tabela no banco de dados mapear um atributo para

apenas uma coluna de mesmo tipo, ou similar, de dados em ambos os modelos,

eliminando a necessidade de tratamento diferenciado para cada coluna, podendo

ser preservado o nome da coluna na classe de mapeamento ou criando sinnimos

para facilitar a identificao (AMBLER, 2002).

A figura 8 representa o mapeamento bsico dos atributos da classe para as

colunas da tabela, mantendo a correspondncia entre os tipos de dados dos campos

em ambos os modelos.


33/44

29

Figura 8 Mapeamento bsico um-para-um

Fonte: Adaptado de Fowler (2002)

6.2 MAPEAMENTO DE HERANA

O modelo relacional no possui suporte nativo para utilizao do conceito de

herana conforme conhecido no modelo de objetos. Devido a isso, o mapeamento

das classes que utilizam esse conceito se torna complexo de realizar, pois o nvel do

encapsulamento dos atributos da classe ancestral inviabiliza o acesso atravs da

classe concreta. Muitas vezes esse importante princpio (encapsulamento) de

modelagem orientada a objetos infringido para que o mapeamento possa ser

realizado pela ferramenta de Object Relational Mapper (ORM) (AMBLER, 2002).

Conforme Fowler (2002), no existe uma forma padro para realizar o

mapeamento de classes que utilizam herana, sem ter que mapear a classe abstrata

juntamente com as classes concretas, correlacionando seus atributos com as

colunas. Para qualquer tipo de estrutura hierrquica, existem basicamente trs

opes:

a) uma tabela para todas as classes da hierarquia;

b) uma tabela para cada classe concreta;

c) uma tabela por classe (abstrata e concreta).

A figura 9 exemplifica um possvel mapeamento utilizando uma tabela para

todas as classes da hierarquia.


34/44

30

Figura 9- Uma tabela para todas as classes de hierarquia


A figura 10 demonstra a modelagem das classes utilizando uma tabela para

cada classe concreta.

Figura 10- Uma tabela para classe concreta


A figura 11 exibe a construo do mapeamento fazendo uso de uma tabelapor classe, tanto abstrata quanto concreta.


35/44

31

Figura 11- Uma tabela por classe


6.3 MAPEAMENTO DE RELACIONAMENTOS

Para que a persistncia de um objeto seja realizada por completo, devem-se

mapear alm dos atributos, os relacionamentos que possam existir com outros

objetos, a fim de garantir a integridade do registro quando o mesmo for inserido ou

alterado fisicamente no banco de dados.

Para isso, deve-se observar a diferena entre manter um relacionamento nomodelo de objetos e no modelo relacional. No modelo de objetos o relacionamento

resolvido mantendo-se a referncia em memria do objeto relacionado, enquanto

que no modelo relacional o relacionamento formado por uma chave de outra tabela

(FOWLER, 2002).

De acordo com Ambler (2002), existem trs tipos de relacionamentos que

necessitam ser mapeados: associao, agregao e composio. Dentre as

abordagens para mapeamentode relacionamentos existentes destacam-se:

a) relacionamento um-para-um;

b) relacionamento um-para-muitos;

c) relacionamento muitos-para-muitos.

Na figura 12 a classe Album ir conter um atributo relacionado com a classe

Artista, da mesma forma que a tabela lbuns contm um relacionamento para a

tabelaArtistas, assim sendo, consiste em um relacionamento de um-para-um.


36/44

32

Figura 12- Mapeamento um-para-um


Na figura 13 existe um relacionamento um-para-muitos entre as tabelas

lbuns e Trilhas, ou seja, um lbum contm vrias faixas de msicas, gerando no

modelo de classes uma coleo de Trilha como atributo de relacionamento na classe

Album.

Figura 13- Mapeamento um-para-muitosFonte: Adaptado de Fowler (2002)


37/44

33

A figura 14 expe um exemplo de um relacionamento muitos-para-muitos

onde um funcionrio pode possuir vrias habilidades e vice-versa. No modelo

relacional este problema resolvido criando uma tabela associativa,

FuncionarioHabilidade, entre Funcionrios e Habilidades. Porm, no modelo de

objetos resolvido criando uma coleo em ambas as classes que possuem este

relacionamento.

Figura 14- Mapeamento muitos-para-muitos



38/44

34

7 PRINCIPAIS FERRAMENTAS DE MAPEAMENTO OBJETO RELACIONAL

7.1 HIBERNATE

O Hibernate uma ferramenta de mapeamento objeto relacional de grande

aceitao entre os desenvolvedores de sistemas orientados a objetos.

Esta uma ferramenta gratuita e considerada uma das mais utilizadas por

especialistas da rea. Toda a configurao do Hibernate feita atravs de arquivos

em XML, os quais contem detalhes sobre o mapeamento de dados e detalhes sobre

as conexes com bancos de dados. Uma nova verso do Hibernate, o Hibernate

Annotations permite fazer anotaes sobre o mapeamento em cada classe que sedeseja mapear no sistema, substituindo assim os arquivos XML de mapeamento que

cada classe deve possuir para realizar o mapeamento, exceto o arquivo de

configurao do Hibernate (FERNANDES, 2005).

O hibernate, portanto, consiste em um Framework de persistncia para

aplicaes Java de cdigo aberto distribudo com a licena Lesser GNU Public

License (LGPL), possui verso .NET o NHibernate. Criado por desenvolvedores

Java no mundo e liderado por Gavin King. Com benefcio de ser uma soluo

madura, compatvel com diversos bancos relacionais e servidores de aplicao, com

curva de aprendizado rpido e principalmente variedade na documentao, livros,

artigos, tutoriais, entre outros.

Sua principal funo reduzir a complexidade nos programas Java, baseado

no modelo orientado a objeto, que trabalhem com banco de dados relacionais.

Permite facilidade para o mapeamento dos atributos com uso de XML ou Anotaes

nas classes conforme Figura 15. Com o HQL (Hibernate Query Language) uma

linguagem de consulta orientada a objetos, faz a recuperao das consultas por

meio de uma camada de cache eficiente (SILVA, A.G. da, 2005, p. 42).


39/44

35

Figura 15- Alto nvel da arquitetura Hibernate

Fonte: Silva, A.G. da.(2005, p.43)

7.2 TOPLINK

Toplink um produto Oracle que, segundo o prprio site do fabricante, um

produto voltado para aplicativos que necessitam de alto desempenho e

escalabilidade, produtividade do desenvolvedor e flexibilidade em design e

arquitetura, especialmente no que diz respeito s necessidades de persistncia

(Oracle, 2010).

O TopLink membro da famlia de produtos Oracle Fusion Middleware, que

promete maior agilidade, melhor tomada de decises e reduo de custos e risco

para diversos ambientes de TI. Contudo, apesar desta informao oficial da Oracle,

h questionamentos informais na comunidade de desenvolvedores sobre a

integrao entre funcionalidades e produtos Oracle, bem como a liberdade de

trabalhar em suas IDE's.

7.3 OPENJPA

O Apache Open JPA um projeto, como o nome sugere, da ApacheSoftware Foundation que, segundo a prpria Apache Software Foundation (2010),

pode ser usado como uma camada de persistncia de classes em Plain Old Java


40/44

36

(POJO) ou integrada a um conteiner Java EE, trabalhando junto com outros

frameworks para aplicaes Java EE, como Tomcat, Spring, Struts, entre outros.


41/44

37

8 CONCLUSES

A partir da pesquisa bibliogrfica, foi possvel observar que um dos principais

fatores que contriburam para o nascimento do banco de dados orientado a objeto

consistiu na necessidade de armazenamento de dados complexos, de difcil

representao no banco de dados relacional. Seguindo os princpios do paradigma

orientado a objetos; esse tipo de BD se baseia na representao de estruturas, a

partir de objetos abstrados da realidade, com dados e comportamento associados.

Esses objetos possuem atributos (propriedades que contm valores que descrevem

o objeto) e mtodos (especificaes de comportamentos dos objetos).

A pesquisa bibliogrfica permitiu, ainda, sobre o tema BDOO, a identificaode dois grupos desses tipos de BD: (1) O banco de dados Puramente orientado a

objetos (BDPOO)- baseado somente no modelo orientado a objetos-; e, (2) Banco de

dados objeto Relacionais (BDOR)- que corresponde a banco de dados relacionais

que possibilitam o armazenamento de objetos atravs de tcnicas de mapeamento

objeto relacional.

Considerando o modelo de dados para desenvolvimento de BD, ficou claro

que existem diferenas significativas entre o modelo relacional- que servem de basepara construo dos BDRs-; e, o modelo orientado a objetos-que permite a

construo dos BDOO. Enquanto, a abordagem relacional est baseada no princpio

de que as informaes em uma base de dados podem ser consideradas relaes

matemticas e que esto representadas de maneira uniforme com o uso de tabelas

bidimensionais; o modelo OO uma extenso do paradigma orientado a objetos,

possuindo basicamente os mesmos conceitos.

Entretanto, apesar do paradigma OO estar sendo cada vez mais difundidono processo de desenvolvimento de software, no existe hoje solues comerciais

robustas e amplamente aceitas neste paradigma para a persistncia de dados em

banco. Mercado este dominado pelos bancos de dados relacionais. Neste contexto,

o mapeamento do modelo orientado a objetos para o relacional uma necessidade

cada vez mais importante no processo de desenvolvimento.

Portanto, o surgimento do Mapeamento Objeto Relacional foi fundamental

para garantir que aplicaes desenvolvidas em linguagens orientadas a objetos

pudessem se comunicar com SGBD com persistncia de dados no modelo

relacional. Os mecanismos de MOR trabalham para transformar uma representao


42/44

38

de dados em outra, atravs de tcnicas de traduo entre os diferentes esquemas

de dados, para, enfim, lidar com este descompasso em situaes onde a utilizao

de um banco de dados orientado a objetos no uma opo.


43/44

39

9 REFERNCIAS BIBLIOGRFICAS

AMBLER, Scott W. Anlise e Projeto Orientados a Objeto: seu guia para

desenvolver sistemas robustos com tecnologia de objetos. Rio de Janeiro: Infobook,1998.

AMBLER, S. W. Agile Database Techniques. 1st ed. New York: Wiley & Sons,2003.

AMBLER, Scott W. Mapping Objects to Relational Databases: O/R Mapping InDetail. Toronto, [2002?]. Disponvel em < http://www.agiledata. org/essas/mappingObjects.html>. Acesso em: 12 maro 2014.

ATKINSON, M.; et al. The Object-Oriented Database System Manifesto.

Proceedings of the First International Conference on Deductive and Object-Oriented Databases, Japan, 1989. Disponvel em: . Acesso em: 11 dez, 2003.

BAUER, Christian et al, Java Persistence com Hibernate, Rio de Janeiro:Cincia Moderna, 2007.

CARVALHO, Guilherme Canturio. Sistema de Banco de Dados Orientado aObjetos. Dissertao (Trabalho de Concluso do Curso). So Paulo: Faculdade deTecnologia de So Paulo, 2011.

CATTELL, R.; et al. The Object Data Standard: ODMG 3.0. San Francisco:Morgan Kaufmann, 2000

DALLOGLIO, P. PHP: programando com orientao a objetos. 2. ed. So Paulo:Novatec, 2009.

DOEDERLEIN, Osvaldo Pinali. Dados e Mapeamento Explorando tcnicase tecnologias para persistncia de dados. JAVA magazine, Ed.42, ano.V, p.22-30, 2006

ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemasdebancodedados. 4. ed.

So Paulo, SP: Pearson Addison Wesley, 2005. 724 p.

ESJUG, Tutorial Hibernate Bsico, Disponvel em:. Acesso em:13 Maio 2014.

FERNANDEZ, Luiz Rafael . Construindo aplicaes utilizando Thinlet eHibernate- Parte 02, Disponvel em : , Acesso em: 03 maio 2014.
http://www.agiledata/http://www.agiledata/


44/44

pi - odailson _ivsemestre

Documents