Bancos de Dados Orientados a Objetos

Leonardo Jones, Luis Alberto, Murilo de Lima1

1
Universidade Federal da Bahia – Instituto de Matemática (UFBA)
Departamento de Ciência da Computação – MATA60 – Banco de Dados
Salvador – BA – Brasil – 30 de outubro de 2007
{leojones, luis, muca}@dcc.ufba.br

Abstract. This paper describes the object-oriented database mechanism

(OOD), its relation with the object-oriented programming paradigm and the
main differences among relational databases. We describe some examples of
OODs, the ODMG standard and its data definition and query languages (ODL
and OQL, respectively). We expose still the EyeDB database and a practical
example with it. At last, we make a evaluation of the advantages and disadvan-
tages from the use of BDOOs in contrast with the relational databases.

Resumo. Este artigo descreve o mecanismo de banco de dados orientado de

objetos (BDOO), sua relação com o paradigma de programação orientado a
objetos e as diferenças principais em relação aos bancos de dados relacionais.
São descritos alguns exemplos de BDOOs, o padrão ODMG e suas linguagens
de definição e consulta de dados (ODL e OQL, respectivamente). É exposto
ainda o banco de dados EyeDB e um exemplo prático no mesmo. Ao final, faz-
se uma avaliação das vantagens e desvantagens da utilização de BDOOs em
contraste com os bancos de dados relacionais.

1. Introdução
SGBDOO seguem o modelo de programação orientada a objetos no que diz respeito
a forma com que o dados são tratados por conceitos como objetos, encapsulamento,
herança, polimorfismo. Sua motivação deve-se ao fato que SGBD relacionais não tra-
tam bem dados complexos além do problema da resistência.

2. Relação com programação orientada a objetos

Os SGBDO geralmente têm os mesmos tipos de dados da aplicação que o usa, acabando
com as chamadas perdas por resistência. Além de usarem a OQL para acessá-los. Essa
busca, entretanto, é feita pelo mecanismo de ponteiros.

3. Diferenças em relação aos bancos de dados relacionais

As principais diferenças são [Wikipedia 2007b]:
• Ausência de ferramentas facilmente encontradas no modelo relacional tais como
ferramentas de relatório, OLAP, Backup.
• Não há necessidade do join porque os dados são encontrados seguindo ponteiros
que apontam aos dados. Assim, para alguns tipos de dados os SGBDO são mais
eficientes que os SGBD relacionais; normalmente consultas a dados gerais são
melhor modeladas em SGBD relacional, enquanto dados especı́ficos são melhor
modelados em SGBDO.
 • O embasamento teórico que no caso do relacional é a teoria dos conjuntos e a
lógica de predicados enquanto no modelo OO os dados seguem o modelo de
programação orientada a objetos.

4. Padrões
A padronização visa oferecer portabilidade de aplicações que usam SGBDO. O principal
consórcio para criação de um padrão é o ODMG (Object Database Menegement Group),
descrito na Seção 6. Outro bastante utilizado é o JDO (Java Data Objects).

5. Exemplos de bancos de dados orientados a objetos

Há diversos bancos de dados orientados a objetos disponı́veis. A seguir descrevemos
alguns produtos comerciais e outros de código aberto.

5.1. Objectivity/DB

Trata-se de um BDOO comercial, desenvolvido pela Objectivity, Inc. Provê suporte às
linguagens C, C++, Java, Python e Smalltalk, e aos sistemas operacionais Linux, LynxOS,
UNIX e Windows. As interfaces para C++, Java e Smalltalk atendem ao padrão ODMG
93 [Wikipedia 2007c]. Aplica-se bem a sistemas distribuı́dos e de missão crı́tica. O
mesmo pode ser obtido em http://www.objectivity.com/.

5.2. FastObjects

Outro banco comercial (Versant; denominado anteriormente Poet [Wikipedia 2007b]),

com suporte às linguagens Java e C++ e a diversos sistemas operacionais, efetuando per-
sistência de objetos transparente e atendendo aos padrões JDO e J2EE. Efetua controle de
concorrência de alta granularidade; multi-threading e multi-sessão; dispensa boa parte da
administração; possui performance dez vezes superior a bancos de dados relacionais.
Duas caracterı́sticas a serem destacadas são a distribuição “sem costuras” de
múltiplas bases de dados (o cliente pode interagir com um ou mais bancos de forma
transparente) e a evolução dinâmica do modelo de dados (o objeto obtido da base é con-
vertido para o formato descrito na classe, caso a definição da mesma tenha sido alterada)
[Versant 2007].

5.3. EyeDB

EyeDB é um Sistema de Gerenciamento de Banco de Dados Orientado a Objeto livre

(OODBMS, diferentemente da maioria dos outros sistemas, que são apenas extensões
da linguagem de programação), baseado na especificação ODMG 3.0 (embora utilize
linguagens ODL e OQL próprias, baseadas no padrão). Provê um modelo de objetos e
linguagens de definição e manipulação de dados baseados no padrão ODMG (ver Seção
6).
Este banco foi utilizado na prática em nosso trabalho e é descrito mais profunda-
mente na Seção 7, podendo ser obtido em http://www.eyedb.org/.
5.4. db4o
Db4o (do inglês database for objects) é um banco de dados livre (com uma licença adi-
cional para uso comercial) de alta performance, com suporte a Java e .NET. Se aplica
bem a sistemas embarcados e sistemas controle de tempo real. Alguns testes exibem per-
formance 55 vezes superior que o uso de Hibernate com MySQL. Possui o sistema dRS
(db4o Replication System), que provê compatibilidade com sistemas legados, como Ora-
cle e MySQL. Vem sendo aplicado em diversas áreas do conhecimento e por empresas de
grande porte como Boeing, Bosch e Intel. [db4objects 2007]
Sua caracterı́stica de destaque é a facilidade de uso. É possı́vel realizar uma con-
sulta em apenas uma linha de código, através do método QBE (Query By Example –
consulta através de exemplo). Disponibiliza ainda um gerenciador gráfico de bases de
dados, o Object Manager GUI. No entanto não provê suporte aos padrões ODMG e JDO.

5.5. Outros
Outros bancos de dados orientados a objetos estão disponı́veis. Destacamos ainda os
bancos Perst1 (software livre da McObject) e O2 (IBM). Está ainda sendo desenvol-
vido o banco Magma na linguagem Squeak, uma implementação livre de Smalltalk
[Wikipedia 2007b].

6. O padrão ODMG
O ODMG (Object Database Management Group) publicou uma série de especificações,
a fim de permitir a escrita de aplicações portáveis para bancos de dados de objetos e
ferramentas de mapeamento objeto-relacional [Wikipedia 2007a].
A especificação mais recente é a ODMG 3.0, de 2001 [Wikipedia 2007b], e inclui
um modelo de dados, extensões de persistência para as linguagens de programação C++,
Smalltalk e Java, além de linguagens para definição e manipulação de objetos, descritas a
seguir.

6.1. Modelo de dados

O padrão ODMG define um objeto através das seguinte caracterı́sticas básicas
[Filho et al. 2007]:
1. OID – um número único de identificação do objeto. Este número é utilizado
para recuperação do objeto independente da posição em memória/disco, uma vez
que ponteiros têm suas localidades alteradas durante execuções diferentes do pro-
grama. Em algumas linguagens (como C++) são utilizados “ponteiros persisten-
tes” [Silberschatz et al. 2002], isto é, o programador pode referenciar o objeto
como se fosse uma posição de memória qualquer.
2. Nome – utilizado apenas para a persistência por nomeação (identificação do objeto
através de um nome) de alguns objetos (denominados pontos de entrada), através
dos quais pode-se referenciar os demais objetos do banco de dados, que se tornam
persistentes por acessibilidade.
Outra forma de identificar um objeto é através de uma descrição [Cattell 1994],
que é um predicado sobre os atributos que permitem identificar univocamente um
objeto.
1
Disponı́vel em http://www.mcobject.com/perst/
 3. Tempo de vida – caracteriza se o objeto é persistente (e será armazenado no banco)
ou transiente (existe apenas durante a execução da aplicação).
4. Estrutura – caracteriza o tipo do objeto, por exemplo se o objeto é atômico ou
uma coleção (definidos a seguir). Um objeto complexo (como um tipo estruturado
de dados) também é definido como atômico. O padrão ainda define a noção de
objetos literais (ou imutáveis), que é um objeto sem identificador.

6.1.1. Tipos de dados

O tipo de um objeto é definido pelo seu comportamento (conjunto de operações

que podem ser executadas) e estado (valores que tomam suas propriedades – atribu-
tos e relações). Objetos do mesmo tipo têm propriedades e comportamento comuns.
[Cattell 1994]
Um tipo possui uma especificação externa e uma ou mais implementações. A
especificação externa é uma descrição abstrata das propriedades, operações e exceções de
um tipo, independente da implementação.
Existem três formas de caracterizar um tipo:

• Uma interface define apenas o comportamento abstrato de um tipo de objeto.

• Um literal define apenas o estado abstrato de um tipo literal.
• Uma classe define o comportamento abstrato e o estado abstrato de um tipo de
objeto.

Este conceito fica evidenciado na Figura 1.

Figura 1. Especificação do tipo de um objeto [Cattell 1994].

Os tipos de dados atômicos são: [unsigned] int, [unsigned] long e [unsigned]

short, real (ou float) e double (número de ponto flutuante), char, string (cadeia de
caracteres), boolean (valor lógico), octet (grupos de bits), além dos tipos enumeração,
estrutura e classe e do tipo NULL. Há algumas estruturas pré-definidas, como date, in-
terval (intervalo de tempo), time e timestamp (data e hora).
Os tipos coleção (ou construtores) são cinco: Set (coleção sem elementos repeti-
dos), Bag (coleção com elementos possivelmente repetidos), List (elementos ordenados
segundo algum critério), Array unidimensional de comprimento variável e Dictionary
(seqüência de pares (chave, valor) sem chaves duplicadas).
O padrão ODMG utiliza ainda o conceito de extensão de classe (class extent), que
é o conjunto de todos os objetos de determinada classe. Se uma extensão está presente
para uma classe, quaisquer objetos criados e destruı́dos da classe serão automaticamente
inseridos/removidos da extensão. Este conceito permite tratarmos uma classe de forma
similar a uma relação composta de tuplas [Silberschatz et al. 2002].

6.2. Linguagem de definição de objetos (ODL)

A linguagem de definição de dados (ODL) do padrão ODMG é derivada da comuni-
dade de orientação a objetos, podendo ser utilizada tal como o modelo Entidade/Rela-
cionamento como design primário para um banco de dados relacional [Mehrotra 2001].
Não é uma linguagem de programação completa e provê independência da linguagem de
programação.
A declaração de uma classe segue o seguinte protótipo:
class <nome> [extends <nome_pai>] [: <nomes_interfaces>]
[(extent <nome_extensao>)] { <elementos: atributos,
relacionamentos e métodos> [<declaracao_chaves>]}
O padrão ODMG não permite herança múltipla. Como podemos ver, da mesma
forma que em algumas linguagens de programação, uma classe pode implementar diver-
sas interfaces (a declaração de uma interface é similar). A declaração extent indica a
criação de uma extensão da classe.
Atributos são declarados como
attribute <tipo> <nome>;
e relacionamentos como:
relationship <rangetype> <nome>
[inverse <nome_classe_inv>::<metodo_inv>];
Onde rangetype é um tipo coleção, declarado, por exemplo, como:
Set<tipo_conj>
Quanto aos métodos, são declaradas apenas suas assinaturas, seguindo o formato:
<tipo_retorno> <nome_metodo>(<lista_parametros>)
[raises(<lista_excecoes))]
Note que um método pode levantar exceções. A declaração dos parâmetros segue a forma:
[in | out | inout] <nome_parametro>
Um parâmetro in é somente-leitura; out e inout são parâmetros de escrita e leitura/escrita,
respectivamente.
A declaração de uma chave é feita da seguinte forma
key(<lista_de_atributos)
ou:
(key <lista_de_chaves>)
No entanto as chaves não são necessários, pois os objetos são identificados por seus OIDs.
Supondo o modelo Entidade/Relacionamento da Figura 2, o código da Listagem
1 representa a codificação em ODL da entidade Cliente.

Figura 2. Modelo Entidade/Relacionamento de um banco simples

[Mehrotra 2001].

Listing 1. Entidade Cliente expressa em ODL [Mehrotra 2001].

interface Cliente {
a t t r i b u t e s t r i n g nome ;
a t t r i b u t e i n t e g e r ssn ;
a t t r i b u t e S t r u c t Addr { s t r i n g r u a , s t r i n g c i d a d e ,
i n t cep } endereco ;

r e l a t i o n s h i p S e t <Emprestimo > e m p r e s t o u
i n v e r s e Emprestimo : : e m p r e s t a n t e ;
r e l a t i o n s h i p S e t <Agencia > t e m c o n t a e m
i n v e r s e Agencia : : c l i e n t e s ;

key ( s s n )
}

6.3. Linguagem de consulta de objetos (OQL)

A linguagem de consulta de objetos (OQL) é utilizada para realizar buscas em um BDOO.
A mesma pode ser utilizada para consultas ad-hoc (interativas) ou embutida na lingua-
gem de programação. É uma linguagem declarativa, o que permite (tal como com SQL)
otimizações nas consultas [Vassilakis 1998].
Exemplo (listagem do nome e SSN de todos os clientes que moram em Salvador):
select struct(n: c.nome, ssn: c.ssn)
from Cliente as c
where c.endereco.cidade = "Salvador";
Podemos utilizar constantes (tanto numéricas como strings), objetos nomeados
(incluindo as extensões de classes) e variáveis (com sintaxe idêntica para acesso a atri-
butos e métodos). Estão disponı́veis operadores numéricos, de comparação e booleanos,
com semântica semelhante à SQL.
Temos ainda os operadores construtores, que podem ser utilizados para criar/bus-
car objetos, coleções e estruturas. Exemplos:
//objeto (observe a declaração da estrutura)
Cliente(nome: "Joao", ssn: 12345, endereco: struct (
rua: "Rua A", cidade: "Salvador", cep: 12345);
//coleção
Vector(1, 2, 3); Set(1, 2, 3);
As consultas retornam coleções do tipo Bag, a não ser que se utilize select dis-
tinct, o que retornará uma coleção do tipo Set.
Uma das melhores caracterı́sticas da OQL em relação à SQL é o uso de partições,
que simplificam consultas com agregação. Exemplo:
select * from Emprestimo as e
group by e.tipo as tipo
order by avg(select e.quantia from partition);
A consulta retorna o valor médio dos empréstimos, agrupados por tipo. O tipo de retorno
será:
List<struct(tipo: int, partition: Bag<struct(e:Emprestimo)>>
A inclusão de objetos no banco de dados pode ser feita por objetos nomeados:
joao := Cliente(nome: "Joao", ssn: 12345, endereco: struct (
rua: "Rua A", cidade: "Salvador", cep: 12345);
ou através de acessibilidade:
add Emprestimo(quantia: 500, id_emprestimo: 1234, tipo: 2)
to joao.emprestou;
Caracterı́sticas adicionais:
• Compatibilidade com modelos de linguagens orientadas a objeto
• Acesso via caminhos (path expressions) – minimiza a necessidade de joins
• Operadores e operandos ortogonais
• Chamada de métodos
• Semelhança com SQL
• Simplicidade

7. O banco de dados EyeDB

Nesta seção descrevemos o sistema EyeDB e um exemplo de como utilizá-lo na prática.
Suas principais caracterı́sticas incluem [EyeDB 2006]:
 • Gerenciamento de dados do tipo persistente
• Modelo cliente/servidor
• Serviços de transações
• Modelo de objeto expressivo
• Herança
• Restrições de integridade
• Métodos
• Triggers
• QL (Query Languages)
• APIs (Application Programming Interfaces)
• Polimorfismo
• Relações binárias
• Suporte a bases de dados de vários Tb (terabytes)
• Objetos são mapeados diretamente dentro da memória virtual
• Cópias de memória de objetos são minimizadas
• Polı́tica de cache
• Escalabilidade: Programas podem lidar com centenas de milhões de objetos sem
perda de desempenho.
7.1. Histórico
Seu primeiro protótipo foi desenvolvido nos laboratórios Genethon para o projeto Ge-
noma. Em abril de 1994, uma versão nova foi desenvolvida com o apoio da ANVAR
(Agence Nationale pour la Valorisation de la Recherche) e do conselho regional da
França. Esta segunda versão de EyeDB foi reescrita do zero. Desde 1994, EyeDB tem
sido usado em vários projetos de bioinformática juntamente com o CRI Infobiogen e pro-
jetos europeus com a EBI [EyeDB 2006].
7.2. A Arquitetura
EyeDB é baseado em uma arquitetura de cliente/servidor [SYSRA 2006b].
O servidor é composto de:
• A camada do protocolo de servidor baseado em RPC (Remote Procedure Call)
• A implementação do modelo de objeto
• O motor de OQL
• O sistema do gerenciador de armazenamento
O cliente é composto de:
• O UAC (user application code)
• A API de C++ que implementa a interação com C++ (o mesmo com Java)
• A camada de protocolo de cliente baseado em RPC
7.3. O Sistema de Gerenciamento de Armazenamento
O kernel do servidor é o sistema de gerenciamento de armazenamento, que oferece os
seguintes serviços [SYSRA 2006b]:
• gerenciamento de dados persistentes
• serviços de transação
• sistemas de recuperação
• ı́ndices de hash e árvore B
• gerenciamento de banco de dados multi-volume
É possı́vel usar o gerenciador de armazenamento independentemente do EyeDB.
7.4. O modelo de objeto
O modelo de objeto do EyeDB é baseado nos modelos de SmallTalk, LOOPS, ObjVlisp,
Java e ODMG [SYSRA 2006b].
Um modelo nativo de objeto é composto de 76 classes como ”collection”,
”method”, ”constraint”, ”index”, ”image”, etc. Ele possui suporte a todos os tipos
padrões: inteiros de 16, 32 e 64 bits, caracteres, strings, floats de 64 bits.
Ele suporta apenas relações binárias, ou seja, relações entre apenas duas entidades.
Estas podem ser de 1 para 1, 1 para n ou n para m, dependendo da cardinalidade das
entidades envolvidas. EyeDB mantém a integridade referencial das relações, ou seja, se
um objeto que participa em uma relação for removido, então qualquer caminho até aquele
objeto também é removido.

7.5. Exemplo prático

A seguir descrevemos um exemplo prático de utilização do EyeDB [SYSRA 2006a], uti-
lizando o seguinte modelo de dados em ODL:
Listing 2. Modelo de Pessoa em ODL (arquivo schema.odl)
c l a s s Address {
i n t num ;
string street ;
s t r i n g town ;
s t r i n g country ;
};

c l a s s Person {
string firstname ;
s t r i n g lastname ;
i n t age ;
Address addr ;
Person ∗ spouse i n v e r s e Person : : spouse ;
s e t <P e r s o n ∗> c h i l d r e n ;

i n d e x on f i r s t n a m e ;
i n d e x on l a s t n a m e ;
i n d e x on a g e ;
};

c l a s s Employee e x t e n d s P e r s o n {
long s a l a r y ;
};

Para criar uma base de dados com este modelo, utilizamos o comando:
//cria um banco com o nome person_g
# eyedbdbcreate person_g
//determina o acesso padrão a esse banco como leitura/escrita
# eyedbdbaccess person_g rw
//cadastra o modelo no banco
# eyedbodl --update --database=person_g schema.odl
Para inserir dados no banco:
# eyedboql -d person_g -w << EOF
//exemplo de persistência por nomeação
john := new Person(firstname: "john", lastname: "wayne", age: 72);
mary := new Person(firstname: "mary", lastname: "poppins", age: 68);
john.spouse := mary;
add Person(firstname: "baby1", age: 2) to john->children;
add Person(firstname: "baby2", age: 3) to john->children;
add Person(firstname: "baby3", age: 4) to john->children;
\commit
\quit
EOF
Para consultar os dados (o comando eyedboql provê um prompt de comando para
consultas):
# eyedboql -d person_g
? select Person->lastname;
= bag(NULL, NULL, NULL, "poppins", "wayne")
? select Person->firstname;
= bag("john", "mary", "baby2", "baby3", "baby1")
? \quit

8. Vantagens e desvantagens em relação a bancos de dados relacionais

Em geral, é mais fácil pensar nas informações do mundo real como propriedades de um
objeto individual. Para que um dado faça sentido, ele precisa estar relacionado a algum
contexto, ou seja, ele deve estar relacionado a alguém ou a alguma coisa. Dessa forma,
pode-se enxergar o dado como um atributo ou propriedade que pertence a alguma en-
tidade existente, e podemos ver as maneiras especı́ficas de tratar esse dado como um
comportamento ou uma ação da entidade. Ao invés de ver uma relação como uma tabela
associando valores de duas entidades, podemos ver uma relação como uma ligação entre
dois objetos, cada um com propriedades e comportamentos individuais.
Se uma entidade representa uma pessoa fı́sica ou jurı́dica, estes podem ser objetos.
O funcionário de uma empresa seria um objeto cujos atributos estariam relacionados aos
dados do funcionário (nome, CPF, salário, turno, etc), já a própria empresa seria outro
objeto com seus próprios atributos, inclusive ponteiros para uma lista de objetos do tipo
funcionário (e cada funcionário pode ter um atributo que aponte para o objeto empresa que
o emprega). Essas ligações próprias de cada entidade facilitam a navegação e organização
dos dados, já que todas as informações de uma entidade estão no mesmo lugar e con-
seqüentemente não é necessário consultar e juntar inúmeras tabelas para encontrar uma
relação entre dois dados de objetos distintos.
Como objetos podem ter outros objetos como atributos, estes podem facilmente
armazenar atributos multivalorados. Um objeto “funcionário” pode ter a instância de um
objeto “endereço” como atributo, e este objeto “endereço” teria atributos como “rua”,
“número”, “CEP” e “cidade”. Objetos também oferecem o conceito de herança, que
pode ser usado para criar modelos hierárquicos e especializações de entidades (um objeto
“gerente” pode herdar os atributos do objeto “funcionário”.
Dessa forma, objetos proporcionam uma vantagem sobre o modelo relacional em
qualquer modelo onde uma entidade possua atributos e participe em mais de uma relação,
principalmente se as duas relações não utilizam os mesmos atributos da entidade.
Exemplo: tenhamos um banco de dados de uma escola com uma tabela com o
nome e número de matrı́cula do aluno (a chave primária é o número de matrı́cula) e outra
tabela com o CPF e o nome do aluno (o CPF é a chave primária). Digamos que haja dois
alunos com o mesmo nome. Para exibir uma tabela que mostre o CPF, nome e número de
matrı́cula, em um modelo relacional seria necessário ter uma chave estrangeira, enquanto
que em um modelo orientado a objeto, o aluno seria um objeto com os atributos nome,
CPF e número de matrı́cula, e não haveria ambigüidade quanto aos dados de múltiplas
tabelas.
Portanto, a eficiência do modelo orientado a objeto proporciona um aumento de
produtividade, seu paradigma de componentização implica em uma possı́vel separação
de responsabilidades, uma maior flexibilidade do sistema, escalabilidade e facilidade de
manutenção [George et al. 2006].
No entanto, apesar do modelo orientado a objetos ter essas vantagens e funcionar
bem com linguagens orientadas a objeto como C++ e Java, este modelo pode apresen-
tar problemas de interoperabilidade com ferramentas e padrões do modelo relacional já
bem estabelecidos, como ferramentas de relatório, ferramentas de backup, padrões de
recuperação e de conectividade.
Além disso, o conceito de “encapsulamento”, ou seja, de não permitir que um
atributo de um objeto seja alterado por métodos fora deste objeto, apesar de dar maior
segurança e estabilidade, ele implica que estes métodos e tipos de dados devam ser deter-
minados com uma certa antecedência. Questões importantes de implementação precisam
ser definidas ainda na fase de projeto, já que não poderiam ser alteradas mais tarde, o que
pode trazer problemas caso haja necessidade de uma operação que não foi prevista ou que
só poderia ser percebida durante a fase de uso do sistema.
Em outras palavras, o modelo orientado a objeto é melhor utilizado em siste-
mas com propósitos e previsões de uso bastante especı́ficos, onde já se sabe que tipo de
informação o usuário e outras áreas do sistema irão consultar. Como o modelo relacional
é mais aberto, é mais fácil fazer mudanças durante o uso e fazer operações e consultas
que não estavam previstas, ou seja, é melhor para usos mais gerais [Wikipedia 2007b].

9. Conclusão
O modelo orientado a objeto nasceu de uma necessidade de se organizar tipos de dados
mais complexos e que mais se adequam a certas aplicações em áreas gráficas, de rede,
simulações, vı́deo e som. Ele trouxe ao campo de bancos de dados as mesmas vantagens
que o conceito havia trazido às linguagens de programação.
Embora o modelo de gerenciamento de banco de dados orientados a objetos não
tenha feito o sucesso que era esperado, suas vantagens sobre o modelo relacional ainda são
válidas e não estão sendo ignoradas. Ainda há tentativas de se integrar as linguagens de
programação orientadas a objetos nas ferramentas e padrões de bancos de dados, além da
criação de ferramentas de mapeamento de modelos para ajudar na interoperabilidade dos
padrões novos com os padrões antigos. Novas pesquisas envolvendo modelos orientados a
objetos e modelos relacionais podem inclusive ajudar a encontrar um novo paradigma que
tenha as vantagens de ambos os modelos. Enquanto isso não acontece, cabe ao projetista
do banco de dados decidir se ele vai usar o modelo relacional ou o orientado a objeto
para o seu sistema, levando em conta todas as vantagens e desvantagens de cada modelo
[Gonçalves et al. 2007].

Referências
Cattell, R. G. G. (1994). The Object Database Standard: ODMG. Morgan Kaufmann.
db4objects (2007). Product information. Outubro de 2007: http://www.db4o.com/
about/productinformation/.
EyeDB (2006). Eyedb key features. Outubro de 2007: http://www.eyedb.org/
keyfeatures.php.
Filho, H. B. G., Sodré, M., Santana, R., and Jurity, R. A. (2007). Banco de dados de
objetos. Trabalho da disciplina Banco de Dados, Universidade Federal da Bahia, De-
partamento de Ciência da Computação.
George, A., Saccaro, A. M., and Huang, O. (2006). Banco de dados orienta-
dos a objeto. Outubro de 2007: http://www.shammas.eng.br/acad/
sitesalunos0606/bdoo/oo.html.
Gonçalves, G. I., Pesente, G. R., and Lima, R. (2007). Banco de dados orientados a
objetos. Trabalho da disciplina Bancos de Dados B, Pontifı́cia Universidade Católica
do Rio Grande do Sul, Faculdade de Informática.
Mehrotra, S. (2001). Object definition language. Notas de aula da disciplina Database
Management, University of California - Irvine, School of Information and Computer
Sciences.
Silberschatz, A., Korth, H. F., and Sudarshan, S. (2002). Database System Concepts.
McGraw-Hill, 4th edition.
SYSRA (2006a). EyeDB Getting Started. SYSRA. Disponı́vel em (versão 2.7.3): http:
//doc.eyedb.org/manual/html/GettingStarted/.
SYSRA (2006b). EyeDB Overview. SYSRA. Disponı́vel em (versão 2.7.3): http:
//doc.eyedb.org/manual/html/Overview/.
Vassilakis, C. (1998). Omdg oql – object query language. Slides do seminário Temporal
Object-Oriented Databases in Information Systems, disponı́vel em (out/2007): http:
//helios.mm.di.uoa.gr/∼toobis/seminar/OQL/index.htm.
Versant (2007). Powerful advantages: Versant object database. Outubro de 2007: http:
//www.versant.com/en US/products/objectdatabase.
Wikipedia (2007a). Object data management group. Outubro de 2007: http://en.
wikipedia.org/wiki/Object Data Management Group.
Wikipedia (2007b). Object database. Outubro de 2007: http://en.wikipedia.
org/wiki/Object database.
Wikipedia (2007c). Objectivity/db. Outubro de 2007: http://en.wikipedia.
org/wiki/Objectivity/DB.