Hoje, o banco de dados orientados a objeto é um fator emergente que integra banco de dados

e a tecnologia de orientação a objetos. Por um lado, a necessidade de realizar manipulações

complexas para os banco de dados existentes e uma nova geração de aplicações de banco de
dados geralmente requisitam mais diretamente um banco de dados orientado a objeto. Por
outro lado, aplicações de linguagens orientadas a objeto e sistemas estão exigindo
capacidades de banco de dados, tais como continuidade, simultaneidade e transações, dos
seus ambientes. Estas necessidades estão levando à criação de sistemas poderosos,
chamados banco de dados orientados a objeto.

Os bancos de dados orientados a objeto iniciaram-se primeiramente em projetos de pesquisa

nas universidade e centros de pesquisa. Em meados dos anos 80, eles começaram a se tornar
produtos comercialmente viaveis. Hoje, eles são mais de 25 produtos no mercado.

Conceitos Básicos

O desenvolvimento dos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos

(SGBDOO) teve origem na combinação de idéias dos modelos de dados tradicionais e de
linguagens de programação orientada a objetos.

No SGBDOO, a noção de objeto é usada no nível lógico e possui características não

encontradas nas linguagens de programação tradicionais, como operadores de manipulação de
estruturas, gerenciamento de armazenamento, tratamento de integridade e persistência dos
dados.

Os modelos de dados orientados a objetos tem um papel importante nos SGBDs porque, em
primeiro lugar, são mais adequados para o tratamento de objetos complexos (textos, gráficos,
imagens) e dinâmicos (programas, simulações). Depois, por possuírem maior naturalidade
conceitual e, finalmente, por estarem em consonância com fortes tendências em linguagens de
programação e engenharia de software. O casamento entre as linguagens de programação e
banco de dados é um dos problemas que estão sendo tratados de forma mais adequada no
contexto de orientação a objetos.

Apresenta-se adiante os conceitos básicos de modelos de dados e SGBDs orientados a

objetos.

Modelos de Dados Orientados a Objetos

Superficialmente, pode-se dizer que orientação a objetos corresponde à organização de

sistemas como uma coleção de objetos que integram estruturas de dados e comportamento.
Além desta noção básica, a abordagem inclui um certo número de conceitos, princípios e
mecanismos que a diferenciam das demais. Seus principais conceitos são apresentados em
seguida.

Abstração
É a consideração apenas das propriedades comuns de um conjunto de objetos, omitindo os
detalhes, utilizada com freqüência na definição de valores similares e na formação de um tipo a
partir de outro, em diferentes níveis de abstração. O uso de abstrações permite a geração de
tipos baseada em hierarquias de tipos e de relacionamentos.

Os principais conceitos de abstração utilizados em banco de dados são generalização e

agregação. A generalização corresponde à associação "é um" onde, a partir de propriedades
comuns de diferentes entidades, é criada uma outra entidade. O processo inverso é a
especialização. A agregação corresponde a associação "parte de".
Objeto
Os objetos são abstrações de dados do mundo real, com uma interface de nomes de
operações e um estado local que permanece oculto. As abstrações da representação e das
operações são ambas suportadas no modelo de dados orientado a objetos, ou seja, são
incorporadas as noções de estruturas de dados e de comportamento. Um objeto tem um
estado interno descrito por atributos que podem apenas ser acessados ou modificados através
de operações definidas pelo criador do objeto. Um objeto individual é chamado de instância ou
ocorrência de objeto. A parte estrutural de um objeto (em banco de dados) é similar à noção de
entidade no modelo Entidade-Relacionamento.

Identidade de Objeto
Num modelo com identidade de objetos, estes têm existência independente de seus valores
correntes e dos endereços de armazenamento físico. A identidade do objeto é geralmente
gerada pelo sistema. A impossibilidade de garantir a identificação de objetos exclusivamente
através de suas propriedades estruturais e comportamentais motivou a definição de
identificadores únicos de objetos, que persistem no tempo de forma independente ao estado
interno do objeto.

A identidade de objetos elimina as anomalias de atualização e de integridade referencial, uma

vez que a atualização de um objeto será automaticamente refletida nos objetos que o
referenciam e que o identificador de um objeto não tem seu valor alterado.

Objetos Complexos
Os objetos complexos são formados por construtores (conjuntos, listas, tuplas, registros,
coleções, arrays) aplicados a objetos simples (inteiros, booleanos, strings). Nos modelos
orientados a objetos, os construtores são em geral ortogonais, isto é, qualquer construtor pode
ser aplicado a qualquer objeto. No modelo relacional este não é o caso, visto que só é possível
aplicar o construtor de conjuntos às tuplas e o construtor de registro a valores atômicos.

A manutenção de objetos complexos, independente de sua composição, requer a definição de

operadores apropriados para sua manipulação como um todo, e transitivos para seus
componentes. Exemplos destas operações são: a atualização ou remoção de um objeto e
cópia profunda ou rasa.

Encapsulamento
O encapsulamento possibilita a distinção entre a especificação e a implementação das
operações de um objeto, além de prover a modularidade que permite uma melhor estruturação
das aplicações ditas complexas, bem como a segurança dentro do sistema. Em banco de
dados se diz que um objeto está encapsulado quando o estado é oculto ao usuário e o objeto
pode ser consultado e modificado exclusivamente por meio das operações a ele associadas.

Existe uma certa discussão sobre as consultas em banco de dados quando está incorporada a
noção de encapsulamento: Deve-se tornar visível apenas as operações e deixar ocultos os
dados e as implementações ? É interessante relaxar o encapsulamento apenas para as
consultas ? Como deve ser realizada a otimização de consultas em SGBDOO com
encapsulamentos ?

Tipo de Objetos
O tipo de objeto pode ser visto como a descrição ou especificação de objetos. Um tipo possui
duas partes, interface (visível para o usuário do tipo) e implementação (visível só para o
usuário construtor do tipo).

Existem várias vantagens em se ter um sistema de tipos em um modelo de dados. Além de

modularidade e segurança, do ponto de vista da evolução do sistema os tipos são
especificações do comportamento que podem ser compostos e modificados incrementalmente,
para formar novas especificações.
Classes
Um conjunto de objetos que possui o mesmo tipo (atributos, relacionamentos, operações) pode
ser agrupado para formar uma classe. A noção de classe é associada ao tempo de execução,
podendo ser vista como uma representação por extensão, enquanto que o tipo é uma
representação intencional. Cada classe tem um tipo associado, o qual especifica a estrutura e o
comportamento de seus objetos. Assim, a extensão da classe denota o conjunto dos objetos
atualmente existentes na classe e o tipo provê a estrutura destes objetos.

Herança
Herança é um mecanismo que permite ao usuário definir tipos de forma incremental, por
refinamento de outros já existentes, permitindo composição de tipos em que as propriedades
de um ou mais tipos são reutilizadas na definição de um novo tipo. De fato, ela corresponde a
transferência de propriedades estruturais e de comportamento de uma classe para suas
subclasses.

As principais vantagens de herança são prover uma maior expressividade na modelagem dos
dados, facilitar a reusabilidade de objetos e definir classes por refinamento, podendo fatorar
especificações e implementações como na adaptação de métodos gerais para casos
particulares, redefinindo-os para estes, e simplificando a evolução e a reusabilidade de
esquemas de banco de dados.

Tipos de Herança
Os dois tipos de herança, simples e múltipla, são descritos a seguir:

Herança Simples: Na herança simples um certo tipo pode ter apenas um supertipo, da
mesma forma uma subclasse só herda diretamente de uma única classe. Podemos classificar
esta herança em quatro subtipos: de substituição, de inclusão, de restrição e de especialização.
Herança Múltipla: Nesta herança um tipo pode ter supertipos e os mesmos refinamentos de
herança simples. Há basicamente dois tipos de conflitos referentes à herança múltipla: entre o
tipo e o supertipo e entre múltiplos supertipos. O primeiro pode ser resolvido dando-se
prioridade à definição presente no tipo, e não a no supertipo. Com os conflitos entre múltiplos
supertipos, como uma resolução por default pode causar heranças não desejadas, a
abordagem mais segura é baseada na requisição explícita da intervenção do usuário.
Métodos e Mensagens
Um método, em relação a um objeto, corresponde ao comportamento dos objetos,
implementando uma operação associada a uma ou mais classes, de forma similar aos códigos
dos procedimentos usados em linguagens de programação tradicionais, que manipula o objeto
ou parte deste. Cada objeto tem um certo número de operações para ele definida. Para cada
operação pode-se ter um ou mais métodos de implementação associados.

As mensagens são a forma mais usada para se ativar os métodos. Num SGBDOO os objetos
se comunicam e são ativados através de mensagens enviadas entre eles.

Polimorfismo
Em sistemas polimórficos uma mesma operação pode se comportar de diferentes formas em
classes distintas. Como exemplo temos o operação print que será implementada de forma
diferente se o objeto correspondente for um texto ou uma imagem: dependendo do objeto
teremos um tipo de impressão. Tem-se também polimorfismo quando ocorre a passagem de
diferentes tios de objetos como parâmetros enviados a outros objetos

Um mesmo nome pode ser usado por mais de uma operação definida sobre diferentes objetos,
o que caracteriza uma sobrecarga (overloading). A redefinição do operador para cada um dos
tipos de objetos definidos caracteriza uma sobreposição (overriding). As operações são ligadas
aos programas em tempo de execução caracterizando o acoplamento tardio ou late binding.

Outros conceitos
Finalmente há duas propriedades fundamentais para a construção de um SGBDOO:
extensibilidade e completude computacional. A primeira garante que o conjunto de tipos
oferecidos pelo sistema permite a definição de novos tipos e não há distinção entre os tipos
pré-definidos e os definidos pelo usuário. A segunda implica que a linguagem de manipulação
de um banco de dados orientado a objetos pode exprimir qualquer função computacional.

o modelo objecto (SGBDO, Sistema de gestão de bases de dados objecto): os dados são
armazenados sob a forma de objectos, quer dizer, de estruturas chamadas classes que
apresentam dados membros. Os campos são instâncias destas classes

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. 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. Segundo, os dados são geralmente manipulados pela
aplicação escrita usando linguagens de programação orientada a objetos, como C++, C#, Java
ou Delphi, 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.[1]

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), O2[2] (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 da programação orientada a objetos. No ínicio 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 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#.

Adoção de Banco de Dados Orientado a Objetos

Banco de dados orientados a objetos baseados numa programação persistente adquiriram um
nicho nas áreas como banco de dados espaciais, telecomunicações, e áreas científicas como
física de alta energia e Biologia molecular. Eles tiveram pouco impacto nas principais
aplicações comerciais de processamento de dados, embora sejam utilizados em algumas
áreas especializadas em serviços financeiros. Há também que notar que estes bancos
guardam a maior base de dados do mundo ( mais de 1000 Terabytes da Stanford Linear
Accelerator Center) e tem a maior taxa de inserção atingida por um banco de dados comercial (
mais de um Terabyte por hora).

Iniciando em 2004, os bancos de dados orientados a objetos tiveram um segundo período de

crescimento quando os projetos de banco de dados livres surgiram com diversos recursos e de
fácil uso, porque eles eram totalmente escritos em linguagens orientada a objetos, como o
Java, C++ ou 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 banco 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.
Isso é na área das linguagens de consulta orientada a objetos, e 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 são geralmente nã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áveis pela correta reprodução.

Muitos banco 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 banco de dados orientados a objetos ainda provem 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 eficientemente por ponteiros.[3]

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 se
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.

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 as
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óxima as linguagens de programação orientadas a
objeto continuam tanto nas comunidades de pesquisa quanto nas industriais.

Padrões
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.[4] 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 idéias 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 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 as bancos de dados orientadas a objeto estão sendo adotadas (ex.
sistemas de Tempo real).