CENTRO UNIVERSITÁRIO DO MARANHÃO - UNICEUMA

CURSO DE SISTEMAS DE INFORMAÇÃO

BANCO DE DADOS AVANÇADO

BANCO DE DADOS ORIENTADO A OBJETOS

SÃO LUIS-MA
2011
 2

BANCO DE DADOS ORIENTADO A OBJETOS

Trabalho apresentado ao Prof. Emanoel Claudino do

curso de Sistemas de Informação como pré-requisito
para obtenção da nota.

SÂO LUIS-MA
2011
 3

SUMÁRIO

p.

1 INTRODUÇÃO .................................................................................................... 4

2 COMO SURGIRAM OS BDOO’S?...................................................................... 6

3. RECURSOS DE UM BDOO............................................................................ 6

3.1 Escopo....................................................................................................... 6

3.2 Consultas..................................................................................... 6

3.3 Versões dos objetos......................................................................................... 7

3.4 Concorrência................................................................................................ 7

3.5 Recuperação..................................................................................................... 8

3.6 Persistência..................................................................... 10

4 QUEM UTILIZA OS BDOO’S............................................................................... 11

4.1 Objetos complexos................................................................................ 11

4.2 Exemplos de aplicações complexas............................................................... 11

4.3 Características das aplicações complexas................................................ 11

5. CARACTERÍSTICAS DOS SGBDOO’S.......................................................... 12

6. EXEMPLO DE SISTEMA DE GERÊNCIA BANCO DE DADOS ORIENTADO 12

A OBJETOS............................................................................................................
6.1 O SGBD Órion ................................................................................................ 12

7. EXEMPLO DE CÓDIGO (BDOO + JAVA)......................................................... 14

8. QUANDO USAR UM BDOO............................................................................. 15

8.1 DBMS (Database Management System) Embarcados................................. 15

8.2 Relacionamentos de Dados Complexos....................................................... 15

8.3 Diferentes Estruturas de Dados................................................................... 15

8.4 Aceleração do processo de consulta.......................................................... 16

9. VANTAGENS.................................................................................................... 17

10. DESVANTAGENS.......................................................................................... 17

11. CONCLUSÃO ................................................................................................ 18

REFERÊNCIAS............................................................................................ 19
 4

1. INTRODUÇÃO

Os bancos de dados baseados em objetos (OODB) surgiram no final dos

anos 80, derivados da necessidade de suportar a programação baseada em objetos.
Os programadores de Smalltalk e C++ precisavam de um depósito para o que eles
chamavam de dados persistentes, ou seja, dados que permanecem após a
conclusão de um processo. Os bancos de dados baseados em objetos tomaram-se
importantes para certos tipos de aplicações com dados complexos, como por
exemplo, CAD e BLOBs (grandes objetos binários, tais como imagens, som, vídeo e
texto não-formatado) - tais aplicações geraram a necessidade de suportar diversos
tipos de dados, e não apenas tabelas simples, colunas e linhas, como os bancos de
dados relacionais.
O uso de banco de dados orientados a objetos sugere um processo de modelagem
diferente. Enquanto na modelagem de bancos relacionais temos diferentes conceitos
nos modelos conceituais, modelos de entidaderelacionamento e modelos físicos, na
modelagem orientada a objetos usamos uma única gama de conceitos.
Principalmente, pelo largo uso de linguagem de programação orientadas à objetos,
tal renovação nos processos de modelagem de dados, facilita as etapas de análise e
projeto do sistema em questão.
Assim é possível diminuir o tempo total de análise e o esforço técnico para
construção de modelos de dados intermediários (conceitual entidade
relacionamento).
Isto evita a perda da semântica entre a informação contida na aplicação e sua
representação na camada de armazenamento (banco de dados).
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” .
O uso de banco de dados orientados a objetos também facilita a conversão
entre os modelos de mais alto nível e de mais baixo nível por ferramentas
automáticas (CASE-OO), o que traz mais confiança ao processo, que nos bancos
de dados relacionais envolvem várias regras de transição.
Os Sistema de Gerenciamento de Banco de Dados Orientados a Objetos
(SGBDOO) adicionaram o conceito de persistência da programação orientada a
objetos. No ínicio os produtos comerciais eram integrados com várias linguagens
 5

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#.
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, a exemplo do PostgreSQL, que implementa herança e tipos
abstratos de dados.
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).
 6

2. COMO SURGIRAM OS BDOO’S?

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 são mais adequados para o tratamento de objetos complexos
(textos, gráficos, imagens) e dinâmicos (programas, simulações), por possuírem
maior naturalidade conceitual e, finalmente, por estarem em harmonia com fortes
tendências em linguagens de programação e engenharia de software. A junção 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.

3 RECURSOS DE UM BDOO

3.1 Escopo

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

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.

3.2 Consultas
 7

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.

3.3 Versões dos objetos

O acesso a estados anteriores ou a estados alterados de objetos é parte

inerente de muitas aplicações. Ele é obtido por meio de várias versões do
mesmo objeto, que normalmente está associado ao conceito de escopo das
variáveis nas linguagens de programação. O gerenciamento de versão em um
banco de dados orientados a objeto consiste em ferramentas e construções que
automatizam ou simplificam a construção e a organização de versões ou
configurações. Sem essas ferramentas, caberia ao usuário organizar e manter as
versões.
Podemos considerar a configuração como um grupo de objetos tratados
como uma unidade para bloqueio e versionamento. Os objetos individuais dentro
da configuração podem sofrer modificações, de modo que cada objeto pode Ter
um histórico das versões. Vários objetos dentro da configuração são atualizados
em momentos diferentes e não necessariamente na mesma freqüência.

3.4 Concorrência

Nos bancos de dados orientados a objeto, há dois aspectos de bloqueio

que são relevantes para o compartilhamento concorrente de objetos:
Bloqueio de Hierarquia de classe: As classes nos bancos de dados
orientados a objeto são organizadas em hierarquias de herança, de modo que
 8

cada classe da hierarquia tenha uma extensão ou instância preexistente. Por isso
é importante fornecer bloqueio de granularidade a essas estruturas. Por
exemplo, uma superclasse poderia bloquear implicitamente todas as subclasses
no mesmo modo de bloqueio. As subclasses incluem os descendentes diretos da
superclasse e os descendentes de suas subclasses.
Bloqueio de Objeto complexo: Os bancos de dados orientados a objetos
contêm objetos que podem referenciar ou incorporar outros objetos. Além disso,
alguns objetos são "valores", enquanto outros possuem identidade. Para otimizar
a concorrência na presença de modelos que envolvam objetos complexos, são
analisados vários esquemas de bloqueio de "objetos compostos" ou de "objetos
dependentes" para objetos complexos.

3.5 Recuperação

A confiabilidade e a grata recuperação de falhas são importantes recursos

de um SGBD. O gerenciador de recuperação é o modulo que administra as técnicas
de recuperação dessas falhas. Os três importantes tipos de falhas que são
responsabilidade do gerenciador de recuperação são: as falhas de transação, as
falhas no sistema, as falhas no meio.
Uma das estruturas mais utilizadas para o gerenciamento de recuperação é o
log. O log é utilizado para registrar e armazenar as imagens anteriores e posteriores
dos objetos atualizados. A imagem anterior é o estado do objeto antes da
atualização da transação, e a imagem posterior é o estado do objeto após a
atualização da transação.
Quase todos os bancos de dados orientados a objeto suportam a
recuperação. A maioria dos SGBDOO utiliza o logging para a recuperação do banco
de dados a um estado coerente. Alguns utilizam a duplicação ou espelhamento de
dados.

3.6 Persistência

O termo persistência usado é banco de dados, conota o espaço de objeto

resiliente, concorrentemente compartilhado. A função de um sistema de SGBD é
 9

permitir o acesso e a atualização simultâneos de bancos de dados persistentes.

A fim de garantir a persistência dos dados a longo prazo, os SGBDs utilizam
várias estratégias de recuperação em caso de falhas na transação, no sistema
ou no meio.
Há uma relação fundamental entre o compartilhamento e a persistência
simultâneos em banco de dados. As atualizações de transação devem persistir,
mas, como o banco de dados persistentes é ao mesmo tempo acessado e
atualizado, o sistema de gerenciamento de banco de dados deve preocupar-se
com a coerência dos objetos de dados persistentes. Isso normalmente é obtido
por meio de estratégias de controle e recuperação concorrentes.
Os dados manipulados por um banco de dados orientado a objeto podem
ser transientes ou persistente. Os dados transientes só são validos dentro de um
programa ou transação, eles se perdem quando o programa ou a transação
termina. Os dados persistentes, por outro lado, são armazenados fora do
contexto de um programa e assim sobrevivem a varias invocações de
programas.
No entanto, há vários níveis de persistência. Os objetos menos
persistentes são aqueles criados e destruídos em procedures. Depois, há os
objetos que persistem dentro do espaço de trabalho de uma transação, mas que
são invalidados quando a transação termina. As transações são normalmente
executadas dentro de uma sessão. O usuário estabelece seu login e define
diferentes parâmetros ambientais dentro de um sessão, como caminhos, opções
de exibição, janelas, etc. Se o sistema suportar o multiprocessamento, várias
transações poderão estar ativas dentro da mesma sessão de usuário ao mesmo
tempo.
Todas estas transações compartilharão os objetos da sessão. No entanto,
quando o usuário terminar a sessão, os objetos da sessão serão invalidados. O
único tipo de objeto que persiste através das transações são objetos
permanentes normalmente compartilhados por vários usuários. Esses objetos
persistem através de transações, instabilizações de sistema e até de meio.
Tecnicamente, esses são os objetos recuperáveis do banco de dados.
 10

4 QUEM UTILIZA OS BDOO’S

4.1 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. Em SGBDOO,
também podemos utilizar estes tipos de dados estruturados, assim sendo, a consulta
ao banco de dados precisa ser mais complexa, pois ao invés de acesso a tabelas e
registros, é necessário o acesso a listas, tuplas, arrays, entre outros.

4.2 Exemplos de aplicações complexas

 Projetos de engenharia e arquitetura.

 Experiências cientificas.

 Telecomunicações.

 Sistemas de informações geográficas.

 Multimídia..

4.3 Características das aplicações complexas

 Transações de duração mais longa;

 Novos tipos de dados para armazenar imagens ou grandes itens de texto;

 Necessidade de definir operações específicas de aplicações

nãopadronizadas;
 11

5. CARACTERÍSTICAS DOS SGBDOO’S

Cada objeto possui um identificador de objeto ou OID (object identifier), que o

torna único, não usa a linguagem sql, por isso não há querys, na verdade você
busca por seus objetos através de metodologias predefinidas. Chamamos estas
metodologias de Native Query’s.
Na diferenciação do modelo relacional e do orientado a objeto, ficaria da
seguinte maneira.

Modelo Relacional Modelo OO

Tabelas (entidades) Objetos
Linhas (registros) Tuplas
Query’s(consultas,etc) Native Query’s
Sql Ansci Métodos, construtores

Esta figura mostra como o dado é representado tanto no modelo relacional

como no orientado a objetos
A forma de acesso aos dados no banco é remodelada porque os SGBDS
orientados a objetos sugerem novos tipos de dados como seqüências de bits,
ponteiros, linhas, números complexos e elementos de dados do tipo array. Para
acessar uma array, um modo especial de consulta teria que ser construído, por
exemplo:

6. EXEMPLO DE SISTEMA DE GERÊNCIA BANCO DE DADOS ORIENTADO A

OBJETOS

Considerando-se que, na prática, todas as condições necessárias ao bom

andamento da pesquisa foram pensadas, esta, depois de iniciada, somente será
interrompida por motivo de os sujeitos convidados se negarem a participar, ou seja,
não se atingindo a amostra prevista, ou por motivo de força maior.

6.1 O SGBD Órion

 12

Existem vários tipos de SGBDOO, vários deles de suma importância para

determinadas funções. Dentre eles existe o Òrion que é muito utilizado em perícias.
O Órion conta com 1103 veículos de carga e 4121 veículos de passeio e
comerciais leves cadastrados em seu banco de dados, alem de ser o mais barato do
mercado. Presente em mais de 640 oficinas, o Órion possibilitou a realização de
mais de130 mil perícias, no ano de 2006, e mais de 58 mil, até maio deste ano, pelo
processo de imagem.
Com o objetivo de atuar cada vez mais na melhoria do software, foi oferecida
uma nova versão do Órion. As oficinas e seguradoras contam com as seguintes
novas funcionalidades:
 Comparativo de revisões: Possibilita a oficina a total gestão do processo de
peritagem;
 Laudo em extensão XML: Possibilita a integração com o sistema de gestão
interna da oficina;
 Novo layout da agenda de visitas: Possui todas as informações necessárias
para o trâmite de realização de orçamento e comunicação direta com o perito
da seguradora;
 Novo layout de fotos: Possibilita a inserção de mais de 30 fotos por processo;
 Consulta eletrônica de peças: Permite a consulta eletrônica de peças, tanto
por descrição como por partnumber;

6.2 O Cachê

É um SGBDOO com toda a tecnologia em banco de dados orientado a

objetos .O Caché é um banco de dados pósrelacional orientado a objetos, que vem
conquistando espaço no mercado devido ao seu desempenho com as aplicações.
Além de seu desempenho ele permite a integração entre a linguagem padrão
de banco de dados, que é a SQL (Structured Query Language – Linguagem de
Consultas Estruturada), e Objetos, assim trabalhando com SQL e OQL (Object
Query Language – Linguagem de Consultas a Objetos). Devido a essa gama de
 13

possibilidades do Caché, as aplicações relacionais podem fazer uso dos

componentes de negócios construídos em OO (Orientado a Objeto).
A ferramenta Studio,nativa do Caché, é um grande facilitador na criação e
manipulação das classes que constituem a base de dados.

Figura2: Interface gráfica da ferramenta Studio do Cachê

 14

7. EXEMPLO DE CÓDIGO (BDOO + JAVA)

O trecho de código abaixo exemplifica etapas comuns na utilização de bancos

orientados a objeto, onde é notável a simplicidade na execução da consulta e
atualização sobre os dados de forma mais direta:

import org.odmg.*;
import java.util.Collection;

Implementation impl = new com.vendor.odmg.Implementation();

Database db = impl.newDatabase();
Transaction txn = impl.newTransaction();
try {
// conectando ao BANCO Orientado a Objetos
db.open("addressDB", Database.OPEN_READ_WRITE);
txn.begin();
// realizando uma CONSULTA
OQLQuery query = new OQLQuery(
"select x from Person x where x.name = \"Amadeu Barbosa\"");
// coletando o resultado da CONSULTA
Collection result = (Collection) query.execute();
// atribuindo um iterador a esses resultados
Iterator iter = result.iterator();
// operando sobre cada resultado
while ( iter.hasNext() )
{
Person person = (Person) iter.next();
// agora atualizando o valor de um campo do objeto consultado
person.address.street = "Av. Jose Silveira, 34, 450";
}
// efetivando tais operações no banco
txn.commit();
// fechando a conexão ao BANCO Orientado a Objetos
db.close();
}
 15

8. QUANDO USAR UM BDOO

Existem situações que um sistema de gerenciamento de banco de dados

relacional se adequa melhor à aplicação. Para isso é importante saber definir
quais tipos de aplicações podem usar as vantagens disponibilizadas pelos banco
de dados orientados a objetos em contraposição aos bancos relacionais.

8.1 DBMS (Database Management System) Embarcados

Normalmente aplicações que rodam em dispositivos móveis ou embarcados

requisitam sistemas de bancos de dados imbutidos nas linguagens e programação,
com acesso a dados persistentes e de fácil deposição para o lado do cliente ou do
middleware (em ambientes distribuídos). Já com os recursos atuais disponíveis em
linguagens como Java é possível disponibilizar objetos de um grande banco de
dados persistentes nas memórias destes dispositivos, que venham a ser
sincronizados a posteriore pela aplicação ou middleware. Enquanto que usando um
banco relacional seria necessário um overhead para a atualização desses dados,
com conexões dedicadas.

8.2 Relacionamentos de Dados Complexos

O uso de inter-relacionamentos complexos em uma base relacional pode

dificultar e tornar o sistema propenso a erros, que são forçosamente contornados
por restrições de atualização como as foreign keys e outras classes de
constraints. Os conceitos de persistência de dados em BDOO garantem que se
um objeto A, que se relaciona ao objeto B, persiste então o objeto B também
sofrerá persistência para que em momento de atualização a referência possa ser
atualizada. Isto também garante consistência das referências em cache.

8.3 Diferentes Estruturas de Dados

 16

Alguns dados que precisam necessitam de um armazenamento diferente da

arrumação tabular por linhas e colunas (como nos bancos relacionais). Certas
estruturas de dados como grafos e árvores de busca, por exemplo, são difíceis de
armazenar segundo os conceitos de tabelas. Assim a forma de armazenamento em
bancos relacionais pode ser confusa e difícil de manter, além de pode causar uma
corrupção de dados, em momento de manipulação indevida. Nos BDOOs é mais
simples, pois o programador-usuário pode dizer com clareza quais tipos abstratos de
dados quer armazenar, evitando preocupar-se tanto com as convenções para a
camada de armazenamento de dados, tornando o processo transparente e mais
seguro.

8.4 Aceleração do processo de consulta

Em bancos relacionais a SQL fornece diretivas como o SELECT para

viabilizar a navegação de dados, mas nos bancos orientados a objetos é natural
pensar que uma vez coleta certa porção de dados, porções vizinhas possam ser
acessadas por estruturas semelhantes a ponteiros de memória ou referência a
outras instâncias dos objetos. Desta forma, em casos de acessos a grande volumes
facilita-se a coletagem de dados. Exatamente, seguindo esta filosofia é que os
mecanismos de persistência são desenvolvidos para manter em cache na sessão os
dados mais propensos a serem utilizados.
 17

9. VANTAGENS

Entre as Vantagens dos SGBD’s OO, podemos destacar:

 Capacidade de Armazenamento de Objetos

 Podes de Processamento de Requisições

 Não possuem Chaves Primarias nem Estrangeiras, aumentando o

desempenho das consultas e processos

 Os Objetos se comunicam entre si através de mensagens.

10. DESVANTAGENS

Entre as Desvantagens dos SGBD’s OO, podemos destacar:

 Falta de Padronização das linguagens de manipulação dos dados;

 Alto custo de aquisição das novas tecnologias;

 Curva de aprendizagem e adaptação ao novo ambiente demorada

 18

11. CONCLUSÃO
Ao estudar BDOO percebe-se que sua conceituação traz novos recursos
antes não existentes nos bancos de dados puramente relacionais. Estes recursos
surgiram pelo largo uso de linguagens de programação orientadas à objetos. Um
dos desafios, em face a este contexto de evolução da modelagem de dados
sugerido pelos desenvolvedores de bancos orientados à objetos, é a grande
quantidade de aplicações estáveis que usam bancos relacionais. Por isso, grande é
o esforço em prol de padronizar as linguagens de acesso aos bancos orientados à
objetos de forma a difundir seu uso e aplicabilidade.
É errado pensar puramente que o bancos orientados à objetos são os
substitutos da tecnologia atual de bancos relacionais. Eles estão disponíveis para
situações distintas, que devem ser bem medidas para evitar sub aproveitamento de
seus detalhes de funcionamento.
Talvez motivado por esta situação que grandes projetos de bancos relacionais
já adotaram alguns conceitos da orientação à objetos como a herança, tipos
abstratos de dados e funções personalizadas. Estes bancos, conhecidamente, como
objeto-relacionais são cada vez mais usados nas aplicações diárias como altenativa
mais estável, uma vez que boa parte dos projetos de bancos puramente orientados
à objetos não estão largamente difundidos.
 19

REFERÊNCIAS

RAMOS, Ricardo. Banco de Dados Orientado Objeto. Brasília(DF): 2002.

DIVINO, Gomes Miranda.. Cachê – 2009. Disponível em: http://www.Linhade

Código.com.br/cachê . Acesso em:18/05/2009. Nursing, 2006.

Luiz dos Santos Sousa – 2009 – Universidade Católica de Pelotas(UFPEL).

Disponível em: http://souza_l.sites.uol.com.br/OO_Oracle.PDF Acesso em:
05/04/2011