O documento discute banco de dados orientado a objetos, incluindo sua história, recursos técnicos, vantagens e desvantagens. Também aborda ORM e como desenvolver usando modelo orientado a objetos com banco de dados relacional.

1. Brasília
2014
WANDERSON JONER SILVA CRUZ
SISTEMA DE ENSINO PRESENCIAL CONECTADO
ANALISE E DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO
FUNDAMENTOS DA INFORMAÇÃO:
Desenvolvimento orientado a objetos;
Redes de computadores;
Modelagem orientada a objetos

2. Brasília
2014
FUNDAMENTOS DA INFORMAÇÃO:
Desenvolvimento orientado a objetos;
Redes de computadores;
Modelagem orientada a objetos
Trabalho de Fundamentos da Informação apresentado à
Universidade Norte do Paraná - UNOPAR, como
requisito parcial para a obtenção de média semestral na
disciplina de Análise de Desenvolvimentos de Sistemas
de Informação.
Orientador: Prof.
WANDERSON JONER SILVA CRUZ

3. SUMÁRIO
2 INTRODUÇÃO......................................................................................................................................3
3 OBJETIVO................................................................................................................3
4. DESENVOLVIMENTO..........................................................................................................................4
4.1 Pesquisa sobre Banco de Dados Orientados à Objetos .......................4 à 7
4.1.1. Descreva sua aplicação e seu mecanismo de funcionamento....................7 à 8
4.1.2. Qual é a diferença entre banco de dados orientado a objeto e banco de dados
relacional...........................................................................................8 à 13
4.2. Pesquise sobre ORM – Mapeamento Objeto Relacional.........................13 à 14
4.2.1 Como desenvolver utilizando o modelo orientado a objetos com um banco de dados
relacional.............................................................................................14
4.2.2. O que é ORM e para que é utilizado..................................................................14
4.2.3. Quais ferramentas estão disponíveis hoje no mercado.......................15
4.2.4. Quais a vantagens e desvantagens de se usar uma ferramenta ORM..........15
5. CONCLUSÃO.......................................................................................... .16
6. ANEXOS......................................................................................................16 à 17
7. Biliografia ............................................................................................................17

4. 3
2 INTRODUÇÃO
No contexto abaixo Abordaremos os seguintes assuntos banco de dados orientado a objeto
onde falaremos sobre as suas aplicações e seu mecanismo de funcionamento e buscando saber as
diferença entre banco de dados orientado a objeto e banco de dados relacional também abordaremos
ORM (object relational mapper)- mapeamento objeto relacional e como desenvolver utilizando o modelo
orientado a objeto com banco de dados relacional e, para que é utilizado o ORM nos preocupando
como saber quais sãos as vantagens e desvantagens de se usar uma ferramenta ORM e as
ferramentas disponível no mercado.
3. OBJETIVO
Tenho como objetivo me especializar de maneira que venho a conseguir suprir o mercado
com minha especialização oferecendo uma melhor maneira para desenvolver software de boa
qualidade. Visando atender o mercado de software e possibilitando melhor desempenho e automação
nas empresas onde o projeto for desenvolvido.

5. 4
4. DESENVOLVIMENTO
4.1 Pesquisa sobre Banco de Dados Orientados à Objetos – Seção Primária
Banco de dados orientado a objetos
Um banco de dados orientado a objetos é um banco de dados em que cada informação é
armazenada na forma de objetos, ou seja, utiliza a Estrutura de dados denominada Orientação a
objetos, a qual permeia as linguagens mais modernas. O gerenciador do banco de dados para um
orientado a objeto é referenciado por vários como ODBMS ou OODBMS.
Existem dois fatores principais que levam a adoção da tecnologia de banco de dados
orientados a objetos. A primeira, é que em um banco de dados relacional se torna difícil de manipular
com dados complexos (esta dificuldade se dá pois o modelo relacional se baseia menos no senso
comum relativo ao modelo de dados necessário ao projeto e mais nas contingências práticas do
armazenamento eletrônico). Segundo, os dados são geralmente manipulados pela aplicação escrita
usando linguagens de programação orientada a objetos, como C++, C#, Java,Python ou Delphi (Object
Pascal), e o código precisa ser traduzido entre a representação do dado e as tuplas da tabela
relacional, o que além de ser uma operação tediosa de ser escrita, consome tempo. Esta perda entre
os modelos usados para representar a informação na aplicação e no banco de dados é também
chamada de “perda por resistência.
HISTÓRIA
Os sistemas de gerenciamento de banco de dados orientado a objetos cresceram fora das
pesquisas durante o começo da metade dos anos 80, buscando ter sustentação intrínseca da gerência
da base de dados para objetos gráfico-estruturados. O termo “sistema de banco de dados orientado a
objetos” surgiu originalmente por volta de 1985. Projetos de pesquisa notáveis incluem Encore-
Ob/Server (Brown University), EXODUS (University of Wisconsin), IRIS (Hewlett-Packard), ODE (Bell
Labs), ORION (Microelectronics and Computer Technology Corporation or MCC), Vodak (GMD-IPSI), e
Zeitgeist (Texas Instruments). O projeto ORION teve mais artigos publicados do que qualquer outro.
Won Kim, do MCC, compilou os melhores destes artigos num livro publicado pelo MIT Press.
Surgiram produtos comerciais, como o GemStone (Servio Logic, alterado para GemStone
Systems), Gbase (Graphael), e Vbase (Ontologic). No começo da metade dos anos 90 vimos novos
produtos comerciais entrarem no mercado. Deste inclui-se ITASCA (Itasca Systems), Matisse (Matisse
Software), Objectivity/DB (Objectivity, Inc.), ObjectStore (Progress Software, adquirido pela eXcelon, a
qual era originalmente Object Design), ONTOS (Ontos, Inc., alterado para Ontologic), O22 (O2
Technology, surgiu de várias companhias, adquirido pela Informix, qual por sua vez foi adquirida pela
IBM), POET (agora da FastObjects da Versant que adquiriu a Poet Systems), e Versant Object
Database (Versant Corporation). Alguns destes produtos se mantem no mercado, tendo alguns se
unido com novos produtos.
Os Sistema de Gerenciamento de Banco de Dados Orientados a Objetos adicionaram o
conceito de persistência à programação orientada a objetos. No início os produtos comerciais eram
integrados com várias linguagens GemStone (Smalltalk), Gbase (Lisp), e Vbase (COP). O COP era o C
Object Processor, uma linguagem proprietária baseada no C ( COP é diferente de C++. Apesar de

6. 5
ambas terem C como base C++ também foi influenciada Pela Simula). Durante praticamente todos os
anos 90, o C++ dominou o mercado comercial de Gerenciadores de Banco de Dados Orientados a
Objetos. Os vendedores acrescentaram o Java no final dos anos 90 e mais recentemente o C#.
RECURSOS TÉCNICOS
Num banco de dados orientado a objetos puro, os dados são armazenados como objetos
onde só podem ser manipulados pelos métodos definidos pela classe de que estes objetos pertencem.
Os objetos são organizados numa hierarquia de tipos e subtipos que recebem as características de
seus supertipos. Os objetos podem conter referências para outros objetos, e as aplicações podem
conseqüentemente acessar os dados requeridos usando um estilo de navegação de programação.
A maioria dos bancos de dados também oferecem algum tipo de linguagem de consulta,
permitindo que os objetos sejam localizados por uma programação declarativa mais próxima. Isto é, na
área das linguagens de consulta orientada a objetos. A integração da consulta com a interface de
navegação faz a grande diferença entre os produtos que são encontrados. Uma tentativa de
padronização foi feita pela ODMG (Object Data Management Group) com a OQL (Object Query
Language).
O acesso aos dados pode ser rápido porque as junções geralmente não são necessárias
(como numa implementação tabular de uma base de dados relacional), isto é, porque um objeto pode
ser obtido diretamente sem busca, seguindo os ponteiros.
Outra área de variação entre os produtos é o modo que este schema do banco de dados é
definido. Uma característica geral, entretanto, é que a linguagem de programação e o schema do
banco de dados usam o mesmo modo de definição de tipos.
Aplicações multimídia são facilitadas porque os métodos de classe associados com os dados
são responsável pela correta reprodução.
Muitos bancos de dados orientados a objetos oferecem suporte a versões. Um objeto pode
ser visto de todas as várias versões. Ainda, versões de objetos podem ser tratadas como objetos na
versão correta. Alguns bancos de dados orientados a objetos ainda provêem um suporte sistemático a
triggers e constraints que são as bases dos bancos ativos.
VANTAGENS E DESVANTAGENS
Benchmarks entre ODBMSs e relacionais DBMSs tem mostrado que ODBMS podem ser
claramente superiores para certos tipos de tarefas. A principal razão para isto é que várias operações
são feitas utilizando interfaces navegacionais ao invés das relacionais, e o acesso navegacional é
geralmente implementado de forma muito eficiente por ponteiros.
Críticos das tecnologias baseadas em Bancos de Dados Navegacionais, como os ODBMS,
sugerem que as técnicas baseadas em ponteiros são otimizadas para “rotas de pesquisa ou pontos de
vista muito específicos. Entretanto, para o propósito de consultas gerais a mesma informação, técnicas
baseadas em ponteiros tenderão a ser mais lentas e mais difíceis de formular do que as relacionais.
Desta maneira, a abordagem navegacional parece simplificar para usos dos específicos conhecidos às
custas do uso geral, ignorando usos futuros.

7. 6
Outra coisa que trabalha contra os ODBMS parece ser a perda da interoperabilidade com um
grande número de ferramentas/características que são tidas como certas no mundo SQL, incluindo a
indústria de padrões de conectividade, ferramentas de relatório, ferramentas de OLAP e backup, e
padrões de recuperação. Adicionalmente, banco de dados orientado a objetos perdem o fundamento
formal matemático, ao contrário do modelo relacional, e isto às vezes conduz a fraqueza na
sustentação da consulta. Entretanto esta objeção é descartada pelo fato que alguns ODBMSs
suportam totalmente o SQL em adição ao acesso navegacional (Objectivity/SQL++). Mas, o uso eficaz
pode requerer acordos para manter ambos os paradigmas sincronizados.
De fato há uma tensão intrínseca entre a noção de encapsulamento, que esconde os dados e
somente os disponibiliza através de uma interface de métodos publicados, e o presuposto de muitas
tecnologias de bancos de dados, de que estes dados podem ser acessados por consultas baseadas
em seu conteúdo ao invés de caminhos predefinidos. O pensamento centrado em bancos de dados
tende a ver o mundo através de forma declarativa e dirigida a uma visão de atributos, enquanto a OOP
tenta ver o mundo através um ponto de vista comportamental. Esta é uma das várias “perdas por
resistência” que envolvem OOP e banco de dados.
Embora alguns afirmem que a tecnologia de banco de dados orientado a objetos fracassou,
os argumentos essenciais em seu favor permanecem válidos, e as tentativas de integrar as
funcionalidades de bancos de dados mais próximas às linguagens de programação orientadas a objeto
continuam tanto nas comunidades de pesquisa quanto nas industriais.
ODMG
O ODMG (Object Database Management Group) era um consórcio de vendedores de banco
de dados orientados a objetos e mapeadores objeto-relacionais, membros da comunidade acadêmica,
e parceiros interessados. A meta era criar um conjunto de especificações que permitiriam a
portabilidade das aplicações que armazenam objetos em sistemas de gerenciamento de banco de
dados. Foram publicadas várias versões desta especificação. O último release foi a ODMG 3.0. Em
2001, a maioria dos principais vendedores de banco de dados orientado a objetos e mapeadores de
objeto-relacionais reivindicaram a conformidade com a ODMG Java Language Binding. A conformidade
com os demais componentes da especificação foi variada. Em 2001, o ODMG Java Language Binding
foi submetido para o Java Community Process como base para a especificação Java Data Objects. As
companhias membras do ODMG decidiram então concentrar esforços na especificação do Java Data
Objects. Como resultado, a ODMG se dissolveu em 2001.
Várias ideias do banco de dados orientado a objetos foram absorvidas pela SQL:1999 e tem
sido implementadas em vários graus nos produtos de banco de dados objeto-relacional.
Em 2005 Cook, Rai e Rosenberger propuseram abandonar todos os esforços de
padronização para introduzir APIs adicionais de consulta orientadas a objetos e, ao invés disso, usar as
próprias linguagens orientadas a objetos, como o JAVA e o .NET. Como resultado surgiram as
Consultas Nativas (Native Queries). Similarmente, a Microsoft anunciou a LINQ (Language Integrated
Query) e DLINQ, uma implementação do LINQ, em setembro de 2005, para prover a aproximação da
capacidade da linguagem de consulta integrada do banco de dados com as linguagens de
programação C# e VB.NET 9.
Em fevereiro de 2006, o OMG (Object Management Group) anunciou que havia concedido o
direito de desenvolver novas especificações baseadas na especificação ODMG 3.0 e a formação do

8. 7
ODBT WG (Object Database Technology Working Group). O ODBT WG planeja criar um conjunto de
especificações que incorporará avanços da tecnologia de banco de dados orientados a objetos (ex.
replicação), gerenciamento de dados (ex. indexação espacial) e formato de dados (ex. XML) e incluir
novas características dentro deste padrão que dará suporte ao dominios onde os bancos de dados
orientados a objeto estão sendo adotadas (ex. sistemas de Tempo real).
4.1.1. DESCREVA SUA APLICAÇÃO E SEU MECANISMO DE FUNCIONAMENTO.
Temos que fazer a ligação entre o banco de dados e a aplicação.
E uma aplicação é feita através da necessidade de conecta o banco de dado a uma aplicação
por tanto os programadores precisão fazerem aplicações precisas para conversamos com esses
dados, as aplicações precisão ter mecanismo para toda a hierarquia do projeto da empresa. E os
banco de dados para essas aplicações devem ser projetados bem detalhadamente, verificando cada
etapa utilizando o mecanismo de classificação, relacionamento, normatização e etc. que visam à
integridade e confiabilidade dos dados.
Um exemplo comum de aplicação de um banco de dado e o da web, comercio eletrônico, o
cliente ao se cadastra no site o sistema pede informações sobre seus dados pessoais e depois você
pode fazer suas compra esses produtos ficam armazenado em um banco de dados da empresa ate
serem utilizados para escolha e postagem do produto. Ou seja grava seu dados pessoas e endereço
para postagem do produto desejado.
4.1.2 QUAL É A DIFERENÇA ENTRE BANCO DE DADOS ORIENTADO A OBJETO E BANCO DE
DADOS RELACIONAL
A diferença entre banco de dados orientado a objeto e relacional é que a conexão ocorre
através de ponteira e referencias enquanto as relações são unidas através de produtos cartesianos e
chaves estrangeiras, o que leva a soluções de otimização diferentes para os dois casos. A
implementação orientada a objeto entende que a informação é acessível de maneira idêntica.
A necessidade de manipulação e armazenamento de dados complexos vem
crescendo rapidamente com o passar do tempo. Essa necessidade fez com que o
paradigma orientado a objetos fosse agregado aos Sistemas Gerenciadores de Banco de Dados
(SGBDs). As informações complexas, como gráficos, imagens, áudio, vídeo, mapas, entre outros,
requerem funcionalidades que vão além do que o modelo relacional de banco de dados pode oferecer.
Por essa razão, surgiu o modelo de banco de dados orientado a objetos, que traz muitos benefícios em
relação ao banco dedados relacional, pela sua produtividade ao agregar a orientação a objetos ao
banco dedados. Entretanto, por ser um modelo jovem e imaturo que carece de mais estudo e
desenvolvimento, suas operações são lentas quando comparadas com os bancos dedados relacionais
existentes. Por essa razão, foi desenvolvido o banco de dados objeto relacional, o qual agrega
características de ambos os bancos, o BDOO e o BDR, possuindo assim características da orientação
a objetos combinada com tecnologia relacional que domina o mercado e funciona perfeitamente, seja
no desempenho ou na confiabilidade do SGBD.
Este artigo apresentará características dos BDOO e DBOR, com uma comparação das
vantagens e desvantagens dos dois modelos.

9. 8
Banco de Dados Orientado a Objetos
Os Banco de Dados Orientado a Objetos sugiram da necessidade de armazenar dados
complexos e de acabar com a disparidade que havia na modelagem da aplicação e do Banco de Dados
(BD). Com o advento das linguagens de programação orientadas a objetos, os programadores
passaram a utilizar este paradigma e a modelagem então naturalmente passou também a seguir este
modelo. O outro ponto é que objetos complexos precisam ser quebrados em diversas tabelas, ou
relações, para serem armazenados e com isto para recuperar tal informação é preciso realizar um JOIN
entre diversas tabelas.
Com a orientação a objetos, é possível modelar objetos de forma mais próxima ao mundo
real, como por exemplo, em um sistema de geoprocessamento, engenharia, pesquisa científica e
tantos outros sistemas não triviais. Um Bando de Dados Orientado a Objetos – BDOO – permite ainda
que a aplicação manipule objetos, independente se eles são persistentes ou não, pois é possível
armazenar todo o objeto e não apenas seus atributos.
Diferentemente do modelo Relacional, o BDOO não utiliza o conceito de chave primária ou
secundária. As chaves foram substituídas pelo identificador de objeto (OID – Objetct Identifier), que é
controlado pelo próprio SGBD – Sistema
Gerenciador de Banco de Dados – e não é visível ao usuário do Banco de Dados. O
OID pode ser visto como uma referência ao objeto em memória, assemelhando-se a
um ponteiro, porém um OID nunca é alterado e nem reaproveitado, diferentemente do que acontece
quando o objeto está em memória, onde é utilizado o endereço físico da memória RAM (Random
Access Memory). Apesar da característica mencionada, é possível criar campos como chave para
facilitar a identificação dos objetos armazenados por parte do usuário.
Orientação a Objetos
A orientação a objetos fornece recursos como encapsulamento, herança,
polimorfismo e sobrecarga que serão rapidamente explicados.
Segundo Elmasri e Navathe, “o conceito de encapsulamento é uma das principais
características das linguagens e dos sistemas OO. Ele está relacionado também com os conceitos de
tipos abstratos de dados e ocultar a informação nas linguagens de programação”. Encapsular dados
significa que as variáveis serão acessadas por métodos definidos em sua estrutura. Uma vantagem é
poder ocultar a complexidade na manipulação do objeto por meio das operações disponibilizadas de tal
forma que aumenta a segurança e produtividade.
Herança é o mecanismo pelo qual a linguagem de programação orientada a objetos (LPOO)
fornece a possibilidade do reaproveitamento de código. É possível uma classe herdar os métodos e
atributos de outra classe chamada superclasse ou classe mãe e assim estender a classe mãe.
O polimorfismo é a capacidade que um objeto tem de ora se comportar de uma maneira, ora
de outra. Considere as classes as classes Pessoa, Funcionário e Aluno.
Com uma variável do tipo Pessoa, é possível utilizá-la para representar um objeto do tipo
Pessoa, mas também objetos do tipo Funcionário e Aluno.

10. 9
O polimorfismo dá a possibilidade da sobrecarga de operadores, no qual subclasses podem
modificar a implementação de um método definido na superclasse.
Considerando o exemplo anterior e que cada classe tenha um método chamado Remover,
para remover uma pessoa basta apenas excluir o seu registro, já para um aluno é preciso verificar se o
mesmo não possui nenhuma pendência na organização, excluir o aluno das disciplinas que está
matriculado e por fim alterar o seu estado. Já para um funcionário é preciso remover o acesso às
informações da instituição, calcular e pagar a indenização caso se aplique e alterar o estado do
funcionário.
Percebe-se que cada classe tem a sua própria implementação, apesar de
compartilharem o mesmo nome do método.
Padrão ODMG “O sucesso dos sistemas de banco de dados relacionais não resulta apenas
de um nível mais alto de independência de dados e um modelo de dados mais simples do que os
sistemas anteriores. Seu sucesso se deve também à padronização que sofreram. A aceitação do
padrão SQL permite o alto grau de portabilidade e interoperabilidade... Portabilidade é a capacidade de
executar um programa de aplicação particular em diferentes sistemas com modificações mínimas no
programa.” (Vieira, 2001) Interoperabilidade se refere à habilidade de uma aplicação acessar múltiplos
SGDBs distintos.O padrão ODGM (Object Database Management Group) se baseia em:
• Modelo de Objetos;
• Linguagem de Definição de Objetos (ODL);
• Linguagem de Consulta a Objetos (OQL);
• Acoplamento (binding);
Elmasri e Navathe, 2005, dizem que o modelo de objetos fornece os tipos de
dados, os construtores de tipos e outros conceitos que podem ser utilizados na ODL
para especificar esquemas de BDs. O modelo define objetos e literais no qual os
objetos possuem um OID e um estado, ou valor atual, já as literais possuem apenas
um valor sendo basicamente uma constante. Tanto os objetos como as literais podem ser do tipo
atômico, coleção ou estruturado.
A linguagem ODL é usada para criar a definição dos tipos de objetos, por isso devesuportar
todos os construtores semânticos do Modelo de Objetos. É apenas umalinguagem de definição e
independente de qualquer linguagem de programação, sendo utilizado o binding para a LPOO
específica.
A OQL é uma linguagem declarativa não procedural que pode ser utilizada dentro linguagens
de programação. A OQL é baseada na SQL, adicionando conceitos do padrão ODMG como OID,
objetos complexos, herança, polimorfismo,
relacionamento e operações.
O binding, ou acoplamento, especifica como as estruturas em ODL são mapeadas para
estruturas na LPOO escolhida, como C# por exemplo. É o binding que converte o objeto do BD para a
aplicação.
Banco de Dados Objeto Relacional
Com a evolução dos paradigmas de programação e a gradativa manipulação de dados
complexos, houve a necessidade da evolução dos SGDB’s de forma a

11. 10
acompanhar e atender as exigências requisitadas. Dessa evolução nascem os SGBDOO, os SGBDOR
e evoluções nos SGBDR.
Analisando de forma sucinta o SGBDOO, temos respectivamente um banco que facilita a
aproximação do mundo real, devido a trabalhar com orientação a objetos e suas características
(herança, encapsulamento, abstração, polimorfismo), um banco que permite a manipulação de dados
complexos, mesmo com desempenho inferior ao relacional e que possui um pobre nível nas consultas
dos dados. Continuando a analise só que de um SGBDR, temos um banco que atua a um bom tempo
no mercado pelo fato de se ter anos de desenvolvimento, investimentos e aperfeiçoamentos, um banco
com desempenho superior aos SGBDOO, um SGBD que apresenta ricas consultas e que possui
dificuldade em manipular dados complexos.
Como podemos notar no parágrafo acima temos em cada tipo de SGBD citado, vantagens e
desvantagens nos mesmos. Então se notou a carência de um SGBD que tivesse a capacidade de
manipular dados complexos, que se adequasse ao paradigma de programação atual (orientação a
objetos), que tivesse bom desempenho e que demonstrasse ricas consultas de dados. É a partir
dessas vantagens de cada SGBD que se fundamenta o SGBDOR.
O SGBDOR emprega um modelo que coloca a orientação a objetos em tabelas, unindo os
dois paradigmas em um só. Utiliza os conceitos de supertabelas, supertipos, herança, reutilização de
código, encapsulamento, controle de identidade de objetos (OID), referência a objetos, consultas
avançadas e alta proteção dos dados.
Com esse novo conceito surgiu à necessidade de uma linguagem padrão para o uso com o
SGBDOR. É a partir daí que nasce o SQL-3, que na verdade é uma extensão do SQL-2
complementado com características do modelo objeto-relacional.
Alguns exemplos de aplicações que utilizam SGBDOR são os seguintes:
armazenamento de imagens (obtidas por satélite ou de alguma outra forma digital);
projetos de arquitetura; dados sobre o espaço (regiões geográficas, criação de mapas), sistemas de
informações geoespaciais, entre outros.
Apesar de ser um conceito relativamente novo no mundo da tecnologia de banco de dados, o
SGBDOR tem sido uma das promessas capaz de substituir o SGBDR e o SGBDOO. O fato de obter o
melhor do SGBDOO e do SGBDR faz tender que seja o modelo de banco de dados “ideal” para
atender as necessidades atuais.
Padrão SQL3 ou SQL99
Assim como o SGBDOO e SGBDR possuem padrões de linguagem de consulta, com a
evolução do conceito objeto relacional ocorreu à necessidade da criação de mais um padrão para
manipular o mesmo, findando assim a criação do padrão SQL3 ou SQL99.
Criado em 1999 com o intuito de propor interação entre o banco de dados e
aplicações orientadas a objetos de forma mais natural, inclui novos tipos de dados,
novos operadores, suporte para a noção de objeto (OIDs, métodos, tipos de dados
estruturados definidos pelo usuário e etc.), consultas recursivas, triggers, navegação
pela estrutura dos objetos, chamada de métodos (na própria formulação da consulta) e etc. Nele,
representamos objetos como linhas (ROW) que definem uma tupla em
forma de registro. Diferente do modelo relacional, onde cada atributo possui valores.

12. 11
atômicos, pode ocorrer de objetos posuirem outros objetos ou de mais de um registro, caracterizando o
conceito de relação aninhada, onde os atributos podem ser constituídos de outras relações e não
apenas de valores atômicos.
Um conjunto de novos operadores pode ser encontrado no SQL3, alguns deles são os
seguintes: Set, Cast-Multiset, Cursor, Bag, List, Array, Row.
Outro ponto que vale ressaltar é o uso do tipo de dado LOB, utilizado para dados muito
grandes como vídeos, música e etc. Possui dois subtipos que são o CLOB (Character LOB) e BLOB
(Binary LOB).
Enfim, um conjunto de outras utilidades pode ser encontrado na linguagem SQL3 ou SQL99
de modo a facilitar o uso do SGBDOR de forma eficiente e padronizada.
Comparação BDOO x BDOR
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 aplicação e do Banco de Dados (BD). Logo, as vantagens do BDOO vieram rapidamente à tona:
possui uma abordagem flexível, facilidade de manusear objetos complexos, trabalha com noções de
objetos, classes, relacionamento e identidade de objetos.
Entretanto, logo foram percebidas suas limitações, principalmente a relacionada ao
desempenho quando comparado com o Banco de Dados Relacional (BDR) e a falta de fundamentação
matemática, o que dificulta realizar consultas complexas. Por conta, principalmente destas limitações,
foi desenvolvido do Banco de Dados Objeto Relacional (BDOR). Este apresenta diversas vantagens em
relação ao BDOO e ao BDR. Em poucas palavras, pode-se dizer que o BDOR surgiu para agregar as
vantagens da orientação a objetos (herança, polimorfismo, encapsulamento, abstração) que há no
BDOO, juntamente com o alto desempenho, eficiência e maturidade do BDR.
O armazenamento de dados, tanto em BDOO, quanto em BDOR, se torna relativamente
simples, uma vez que em ambos os bancos oferecem suporte a dados complexos. Entretanto, a
principal vantagem do BDOR é a capacidade manipular dados complexos, persistentes e ao mesmo
tempo manter a facilidade de uso dos métodos de consulta do SQL3.
O BDOO possui um modelo rico de dados, ou seja, possui representação de objetos
complexos, é extensível (oferece suporte para novos tipos de dados capazes de operar no objeto),
ofereço suporte à ocultação da informação e herança. Seu ponto fraco é seu baixo desempenho, uma
vez que sua otimização de consultas é bastante complexa, logo é perdido um tempo precioso neste
processo. O BDOR oferece todas as características citadas no parágrafo anterior, exceto a do baixo
desempenho. O BDOR possui uma otimização de consulta mais simples, e consequentemente, não
perde tanto desempenho quanto o BDOO.
Com relação ao mercado, o BDOO é voltado para aplicações de pequena escala, por
questões de desempenho. Já o BDOR busca alcançar aplicações de larga escala, a qual é atualmente
dominada pelos BDR.
Conclusão
A orientação a objetos é a tendência seja qual for a situação, o seu dilema é o fato da perda de
desempenho. Assim como primeiras linguagens de programação onde tudo era um objeto, os BDOOs

13. 12
sofrem com o desempenho. Quando só existia o BDR, apareceu a necessidade de armazenar dados
complexos, uma ótima solução foi o BDOO, entretanto, por seu desempenho não satisfatório, um outro
banco foi desenvolvido, o BDOR, que agrega características da orientação a objetos e otimização do
BDR. O modelo objeto relacional pode ser comparado às linguagens de programação atuais, onde
apenas dados complexos são representados como objetos, tendo assim maior desempenho.
O BDOR ainda não alcançou aplicações de larga escala, pois se trata de um banco
relativamente novo, mas como suas vantagens estão se tornando cada vez mais evidentes, a
tendência é que as empresas e aplicações que manipulam dados
complexos comecem a utilizar o BDOR e no futuro este modelo de banco de dados
tome o lugar do tradicional BDR.
4.2 ORM (Object-Relational Mapping) – Seção quartenária
Um ORM (Object-Relational Mapping), nada mais é do que um Framework ou um conjunto
de classes que permite que você faça este trabalho sem precisar escrever códigos de conexão com o
banco, querys de SQL a todo o momento, preservando as características de orientação a objetos da
linguagem face à natureza relacional dos bancos de dados atuais.
O Mapeamento objeto-relacional (ou ORM, do inglês: Object-relational mapping) é uma
técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos objetos
utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de
classes e os registros de cada tabela são representados como instâncias das classes correspondentes.
Com esta técnica, o programador não precisa se preocupar com os comandos em linguagem
SQL; ele irá usar uma interface de programação simples que faz todo o trabalho de persistência.
Não é necessária uma correspondência direta entre as tabelas de dados e as classes do
programa. A relação entre as tabelas onde originam os dados e o objecto que os disponibiliza é
configurada pelo programador, isolando o código do programa das alterações à organização dos dados
nas tabelas do banco de dados.
A forma como este mapeamento é configurado depende da ferramenta que estamos a usar.
Como exemplo, o programador que use Hibernate na linguagem Java pode usar arquivos XML ou o
sistema de anotações que a linguagem providencia.
4.2.1. COMO DESENVOLVER UTILIZANDO O MODELO ORIENTADO A OBJETOS COM UM BANCO
DE DADOS RELACIONAL
Para desenvolver utilizando o modelo orientado a objeto com o banco de dado racional o
programador não precisa se preocupar com os comandos SQL; ele irá usar uma interface de
programação simples que faz todo o trabalho de persistência.
Não é necessária uma ligação direta entre as tabelas de dados e as classes do programa. A
relação entre as tabelas onde originam os dados e o objeto que os disponibiliza é configurada pelo
programador, isolando o código do programa das alterações à organização dos dados nas tabelas do
banco de dados.

14. 13
4.2.2. O QUE É ORM E PARA QUE É UTILIZADO.
Um ORM (Object-Relational Mapping), nada mais é do que um Framework ou um conjunto de
classes que permite que você faça este trabalho sem precisar escrever códigos de conexão com o
banco, querys de SQL a todo momento, preservando as características de orientação a objetos da
linguagem face à natureza relacional dos bancos de dados atuais.
O Mapeamento objeto-relacional (ou ORM, do inglês: Object-relational mapping) é uma
técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos objetos
utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de
classes e os registros de cada tabela são representados como instâncias das classes correspondentes.
Com esta técnica, o programador não precisa se preocupar com os comandos em linguagem
SQL; ele irá usar uma interface de programação simples que faz todo o trabalho de persistência.
Não é necessária uma correspondência direta entre as tabelas de dados e as classes do
programa. A relação entre as tabelas onde originam os dados e o objecto que os disponibiliza é
configurada pelo programador, isolando o código do programa das alterações à organização dos dados
nas tabelas do banco de dados.
A forma como este mapeamento é configurado depende da ferramenta que estamos a usar.
Como exemplo, o programador que use Hibernate na linguagem Java pode usar arquivos XML ou o
sistema de anotações que a linguagem providencia.
4.2.3. QUAIS FERRAMENTAS ESTÃO DISPONÍVEIS HOJE NO MERCADO.
 Gentle.NET:
o CARACTERÍSTICAS: Persistência, Querys, Cache, Relacionamento;
 MyGeneration:
o CARACTERÍSTICAS: Gerador de código baseado em templates e banco de
dados. Os recursos dependem dos templates;
 Subsonic:
o CARACTERÍSTICAS: Persistência, Coleções, Suporte a alguns bancos, Querys,
Configuração rápida, Releases rápidos;
 NHibernate:
o CARACTERÍSTICAS: Persistência, Herança, Relacionamento, Querys, Suporte a
vários bancos, Transações e muito mais;

15. 14
 CODUS:
o CARACTERÍSTICAS: Persistência, Herança, Relacionamento, Suporte a vários
bancos, Querys, NUnit, WebServices, Coleções, Suporte a
Nhibernate/Ibatis,Gentle.
 ObjectMapper:
o CARACTERÍSTICAS:IDE UML que mapeia para o ORM (Npersist e Nhibernate).
4.2.4. QUAIS A VANTAGENS E DESVANTAGENS DE SE USAR UMA FERRAMENTA ORM.
As vantagem de se usa o Mapeamento objecto-relacional ou objeto - relacional por que é
uma técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos
objetos utilizando bancos de dados relacionais. A desvantagem é o mecanismo de armazenamento e
recuperação de dados mais comumente utilizado - o Banco de Dados Relacional - não foi projetado
para interagir diretamente com o paradigma OO e com suas particularidades.
5. CONCLUSÃO
Esse trabalho foi feito com o propósito de mostra meu aprendizado e abstrair boas lições e
também tive a oportunidade de desenvolver mais meus conhecimentos através das pesquisas que fiz
em relação ao assunto abordado abstrair boas lições sobres banco de dados orientado a objeto e o
relacional suas diferença e como trabalhar com os dois e também sobre a ferramenta ORM como
desenvolver com o modelo orientado a objeto suas vantagens e desvantagem e com tudo isso tive um
bom aprendizado.

16. 15
6. ANEXOS
EXEMPLO DE GRÁFICO

17. 16
7. REFERÊNCIAS BIBLIOGRÁFICAS.
Wikipédia enciclopédia livre Banco de Dados Orientados à Objetos seu endereço eletrônico está
disponível em http://pt.wikipedia.org/wiki/Banco_de_dados_orientado_a_objetos
Análise dos melhores ORM (Object-Relational Mapping) para plataforma .NET endereço eletrônico está
disponível em http://www.devmedia.com.br/analise-dos-melhores-orm-object-relational-mapping-para-
plataforma-net/5548#ixzz2vhR8gjZX
Trabalhos Gratuitos postado por Janderson estudante de Tecnologia, endereço eletrônico disponível
em http://trabalhosgratuitos.com/Tecnologia/Janderson/148709.html
Teses Capitulo 3, endereço eletrônico disponível em http://www.dpi.inpe.br/teses/thome/cap3.pdf
Leandro Gyn Professor de Modelagem Orientada a Objetos, endereço eletrônico disponível em
http://pt.slideshare.net/leandrogynprof/aula1-modelagem-de-sistemas-orientada-a-objetos
André Maués Brabo Pereira Departamento de Engenharia Civil, endereço eletrônico disponível em
http://www.tecgraf.puc-rio.br/ftp_pub/lfm/CIV2802-131-Aula04-ModelagemOrientadaObjetos.pdf