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
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
5/44
LISTA DE TABELA
Tabela 1 Diferenas entre os BDOO e BDRs
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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/12/2019 PI - Odailson _IVsemestre
8/44
4
Desenvolvimento de Sistemas, dentro do eixo temtico desenvolvimento de sistemas
de informao I, da Unopar.
8/12/2019 PI - Odailson _IVsemestre
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;
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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.
Figura 4- Herana mltipla
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
8/12/2019 PI - Odailson _IVsemestre
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.
Figura 5- Herana mltipla
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:
8/12/2019 PI - Odailson _IVsemestre
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;
8/12/2019 PI - Odailson _IVsemestre
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/8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
27/44
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
29/44
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
34/44
30
Figura 9- Uma tabela para todas as classes de hierarquia
Fonte: Adaptado de Fowler (2002)
A figura 10 demonstra a modelagem das classes utilizando uma tabela para
cada classe concreta.
Figura 10- Uma tabela para classe concreta
Fonte: Adaptado de Fowler (2002)
A figura 11 exibe a construo do mapeamento fazendo uso de uma tabelapor classe, tanto abstrata quanto concreta.
8/12/2019 PI - Odailson _IVsemestre
35/44
31
Figura 11- Uma tabela por classe
Fonte: Adaptado de Fowler (2002)
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.
8/12/2019 PI - Odailson _IVsemestre
36/44
32
Figura 12- Mapeamento um-para-um
Fonte: Adaptado de Fowler (2002)
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)
8/12/2019 PI - Odailson _IVsemestre
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
Fonte: Adaptado de Fowler (2002)
8/12/2019 PI - Odailson _IVsemestre
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).
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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
8/12/2019 PI - Odailson _IVsemestre
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.
8/12/2019 PI - Odailson _IVsemestre
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/8/12/2019 PI - Odailson _IVsemestre
44/44