UNIVERSIDADE FEDERAL DE SO CARLOS

DEPARTAMENTO DE COMPUTAO

Banco de Dados
Orientado a Objetos

Marina Teresa Pires Vieira

Contedo

Contedo........................................................................................................................1
1. Conceitos Avanados sobre Modelagem de Dados..................................................3
1.1. Introduo..................................................................................................................... 3
1.2. Modelos de Dados......................................................................................................... 5
1.2.1. Abstraes no Projeto Conceitual de Banco de Dados ......................................................... 5

1.3. Modelo EER (Extended Entity-Relationship) ........................................................... 6

1.3.1. Atributos compostos: ............................................................................................................ 7
1.3.2. Hierarquia de Generalizao................................................................................................. 7

1.4. Exerccios .................................................................................................................... 10

2. Modelos de Dados Orientados a Objetos................................................................12

2.1. Introduo................................................................................................................... 12
2.2. Conceitos Bsicos ....................................................................................................... 13
2.2.1. Objetos e Identidade ........................................................................................................... 13
2.2.2. Valores ................................................................................................................................ 14
2.2.3. Estrutura do objeto.............................................................................................................. 14
2.3.4. OIDs x Chaves Primrias.................................................................................................... 14
2.3.5. Objetos Complexos............................................................................................................. 15
2.3.6. Encapsulamento .................................................................................................................. 15
2.3.7. Mtodos .............................................................................................................................. 16
2.3.8. Tipos e Classes.................................................................................................................... 16
2.3.9. Herana ............................................................................................................................... 16
2.3.10. Polimorfismo..................................................................................................................... 19

3. Modelagem de Dados Orientada a Objetos............................................................21

3.1. Motivao.................................................................................................................... 21
3.2. Desenvolvimento de Sistemas Orientados a Objetos............................................... 21
3.3. Modelando Objetos .................................................................................................... 22
3.3.1. Definio de classe ............................................................................................................. 22
3.3.2. Herana ............................................................................................................................... 23

3.4. Representao grfica................................................................................................ 23

3.4.1. Representao de uma classe de objetos............................................................................. 24
3.4.2. Representao de conjunto, lista e tupla ............................................................................. 24
3.4.3. Herana simples .................................................................................................................. 25
3.4.4. Herana mltipla................................................................................................................. 25
3.4.5. Definio recursiva ............................................................................................................. 26
3.4.6. representao de referncias inversas ................................................................................ 26

3.5. Gerao do Esquema Lgico..................................................................................... 26

3.6. Exemplo: Banco de Dados para Gerenciamento de Projetos................................. 28
3.7. Notao adotada X diagrama de classes UML ........................................................ 31
3.8. Exerccios .................................................................................................................... 37

4. Manipulando Objetos..............................................................................................39
4.1. Caractersticas de Linguagens de Consulta OO (LCOO) ...................................... 39

4.1.1. Hierarquias de Agregao................................................................................................... 39

4.1.2. Hierarquia de Herana ........................................................................................................ 40

4.2. Consultando Objetos.................................................................................................. 40

4.2.1. Hierarquias de Agregao................................................................................................... 40
4.2.2. Hierarquia de Herana ........................................................................................................ 42

4.3. Definio de Mtodos................................................................................................. 42

4.4. Exerccios .................................................................................................................... 46

5. Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos................48

5.1. Caractersticas dos SGBDs Orientados a Objetos................................................... 48
5.2. Vantagens dos SGBDOOs ......................................................................................... 52
5.3. Alguns SGBDOOs Existentes................................................................................... 53

6. Padres para SGBDOOs.........................................................................................54

6. Padres para SGBDOOs.........................................................................................55
6. Padres para SGBDOOs.........................................................................................56
6.1. SQL3........................................................................................................................... 56
6.2. ODMG-93 ................................................................................................................... 57

7. Bibliografia..............................................................................................................58

1. Conceitos Avanados sobre Modelagem de Dados

1.1. Introduo
Bancos de dados so componentes importantes dos sistemas de informao
(SIs) e consequentemente, o projeto do banco de dados apresenta-se como uma
atividade essencial na fase de desenvolvimento dos SIs. Projetar bancos de dados tem
se tornado uma atividade popular, as vezes realizada no somente por profissionais da
rea de banco de dados, mas tambm por no especialistas.
Freqentemente, a falta de abordagens adequadas para o projeto de um banco
de dados pode incorrer em resultados indesejveis, como ineficincia em atender a
demanda de aplicaes e problemas com a manuteno do banco de dados.
Geralmente a causa disso a falta de clareza em entender a natureza exata dos dados
em um nvel conceitual (abstrato).
O projeto de um banco de dados decomposto em Projeto Conceitual,
Projeto Lgico e Projeto Fsico, conforme mostrado na figura 1.1.
Requisitos
de dados

Projeto
Conceitual
Esquema conceitual
Projeto
Lgico
Esquema Lgico
Projeto
Fsico
Esquema Fsico
Fig. 1.1

O Projeto Conceitual inicia a partir da especificao dos requisitos e resulta

no esquema conceitual do banco de dados. Um esquema conceitual uma descrio
em alto nvel da estrutura do banco de dados, independente do Sistema de
Gerenciamento de Banco de Dados (SGBD) adotado para implement-lo. Um modelo
conceitual usado para descrever os esquemas conceituais.
O propsito do projeto conceitual descrever o contedo de informao do
banco de dados ao invs das estruturas de armazenamento que sero necessrias para
gerenciar essa informao.
O Projeto Lgico inicia a partir do esquema conceitual e resulta no esquema
lgico. Um esquema lgico uma descrio da estrutura do banco de dados que pode
ser processada por um SGBD. Um modelo lgico usado para especificar esquemas
lgicos. Os modelos lgicos mais amplamente usados pertencem a trs classes:
relacional, em redes e hierrquico. O projeto lgico depende da classe do modelo de
dados usado pelo SGBD, mas no do SGBD especfico usado.
O Projeto Fsico inicia a partir do esquema lgico e resulta no esquema fsico.
Um esquema fsico uma descrio da implementao do banco de dados em
memria secundria; ele descreve as estruturas de armazenamento e mtodos de
acesso usados para efetivamente realizar o acesso aos dados. O projeto fsico
direcionado para um SGBD especfico. Decises tomadas durante o projeto fsico,
para melhorar o desempenho, podem afetar a estrutura do esquema lgico.
Uma vez que o projeto fsico do banco de dados completado, os esquemas
lgico e fsico so expressos usando a linguagem de definio de dados do SGBD
adotado. O banco de dados criado e populado e pode ser testado para se tornar
operacional.
O esquema fsico do banco de dados influenciado pelas fases por que passou
a construo do banco de dados. A fase de projeto conceitual tida como uma das
mais (seno a mais) delicadas em todo esse processo, pois depende muito da
habilidade do projetista do banco de dados e das qualidades do modelo de dados
adotado para a elaborao do esquema conceitual. A meta nessa fase obter um
esquema conceitual do banco de dados que seja to completo e expressivo quanto
possvel. Esse esquema deve procurar expressar o mximo da semntica envolvida na
informao. Mecanismos de representao de alto nvel so empregados, tais como

representao de hierarquias de subconjunto e de generalizao, representao de

restries de cardinalidade e de atributos compostos e multivalorados.
O esquema conceitual deve permanecer como uma parte da documentao do
processo de projeto, sendo utilizado durante a operao e manuteno do banco de
dados, pois facilita o entendimento dos esquemas de dados e das aplicaes que os
utilizam.
Para auxiliar o projetista a elaborar o projeto conceitual de um banco de
dados existem as abstraes de dados, que apresentam as vantagens:
ajudam o projetista a entender, classificar e modelar a realidade,
melhoram a eficincia de implementaes subsequentes,
permitem melhor representar a semntica das novas aplicaes de banco de dados,
provenientes de reas no tradicionais.

1.2. Modelos de Dados

Modelos de dados so veculos para descrever a realidade. Um modelo de
dados uma coleo de conceitos que podem ser usados para descrever um conjunto
de dados e operaes para manipular os dados. Os modelos de dados servem de base
para o desenvolvimento de Sistemas de Gerenciamento de Banco de Dados (SGBDs).
Distinguem-se dois tipos de modelos de dados:
Modelos conceituais, que so ferramentas para representar a realidade em alto
nvel de abstrao;
Modelos lgicos, que suportam descries de dados que podem ser processados
por um computador (ex: modelos relacional, hierrquico, em redes). Esses modelos
so facilmente mapeados para a estrutura fsica do banco de dados .

1.2.1. Abstraes no Projeto Conceitual de Banco de Dados

Para auxiliar o projetista na tarefa de modelar os dados, existem os
mecanismos de abstrao de dados que permitem melhor representar a semntica da
informao envolvida na aplicao. As abstraes comumente usadas no projeto
conceitual so: classificao, agregao e generalizao.

 Abstrao de Classificao: usada para alocar objetos similares, caracterizados

por propriedades comuns, em classes de objetos. A classificao estabelece um
relacionamento -INSTANCIA-DE entre cada elemento da classe e a classe.
Ex: classe EMPREGADO - instancias : (Joo, Pedro, ..., Jos).
Abstrao de Agregao: um conceito de abstrao para construir objetos
compostos a partir de seus objetos componentes. Essa abstrao estabelece um
relacionamento -PARTE-DE entre os componentes e a classe.
Ex:
-

Uma entidade uma agregao de atributos: PESSOA, composta por Nome,

Sexo, Profisso;

Um relacionamento uma agregao de entidades e atributos;

Um atributo composto uma agregao de atributos;

Pode-se agregar entidades relacionadas entre si, compondo uma entidade de

nvel mais alto.

Abstrao de Generalizao: define um relacionamento de subconjunto entre os

elementos de duas ou mais classes. Essa abstrao estabelece um relacionamento
-UM entre a classe pai (chamada superclasse) e cada classe filha (subclasse).
Ex: classes CARRO e BICICLETA so subconjuntos da classe VECULO.
As subclasses so definidas com base em alguma caracterstica da superclasse. No
exemplo dado, essa caracterstica tipo de veculo (Carro, Bicicleta).
Propriedade Fundamental da Generalizao: Todas as abstraes definidas para a
classe genrica so herdadas por todas as classes que so subconjunto.

1.3. Modelo EER (Extended Entity-Relationship)

Devido popularidade e ampla utilizao do modelo Entidade-Relacionamento (ER)
para o projeto conceitual de bancos de dados, vrias extenses desse modelo foram
propostas, visando sua utilizao para a modelagem de informaes mais complexas.
6

O modelo ER foi proposto por Peter Chen em 1976, sendo que originalmente o
modelo incluia somente os conceitos de entidade, relacionamento e atributos;
posteriormente outros conceitos foram introduzidos no modelo, tais como atributos
compostos e hierarquias de generalizao.
1.3.1. Atributos compostos:
Um atributo composto representa um grupo de atributos que possuem uma afinidade
em significado ou uso. Como exemplo, considere o atributo endereo na figura 1.2,
que composto por Rua, Cidade, Estado, Pas e CEP.
Rua
Cidade
Estado
Pas
CEP

endereo

Professor

Fig. 1.2 - atributo composto

1.3.2. Hierarquia de Generalizao

Uma classe E uma generalizao de um grupo de classes E1, E2, ..., En se cada objeto das
classes E1, E2, ..., En tambm um objeto da classe E. Uma forma de representar uma
hierarquia de generalizao dada na figura 1.3.

E1

E2

...

En

Fig. 1.3- Hierarquia de generalizao

Propriedades de Cobertura da generalizao

Cobertura TOTAL ou PARCIAL

A cobertura de uma generalizao total (t) se cada elemento da classe

genrica mapeada para pelo menos um elemento das classes especializadas.

Ex: A generalizao formada pela classe PESSOA e as subclasses HOMEM

MULHER (figura 1.4) possui cobertura total.

A cobertura parcial (p) se existe algum elemento da classe genrica que no
mapeado para nenhum elemento das subclasses.
Exemplo: Suponha que VECULO uma classe cujos elementos so todos os
possveis tipos de veculos. A generalizao da figura 1.5 parcial.

Pessoa
Veculo

Homem

Carro

Mulher

Fig.1.4 - cobertura total

Bicicleta

Fig.1.5 - cobertura parcial

Cobertura EXCLUSIVA ou de SOBREPOSIO:

A cobertura de uma generalizao exclusiva (e) se cada elemento da classe genrica
possui no mximo um elemento correspondente em uma das subclasses.
Ex: A figura 1.6 representa uma cobertura exclusiva.
A cobertura de sobreposio (s) se existe algum elemento da classe genrica que
possui elementos correspondentes em duas ou mais subclasses.
Ex: Na figura 1.6, suponha que pode existir aluno que cursa a graduao e a psgraduao ao mesmo tempo.

Aluno

AlunoGraduaao

Aluno-PsGraduao

Fig. 1.6 - cobertura de overlapping

Notao: Para denotar o tipo de cobertura de uma hierarquia de generalizao ser
usada a seguinte notao: (t,e), (t,s), (p,e), (p,s), como exemplificado na figura 1.7.
Quando numa generalizao a cobertura no est especificada, admite-se que (t,e).
Veculo
(p,e)
Carro

Bicicleta

Fig. 1.7 - cobertura parcial e exclusiva

Hierarquia de Subconjunto
Uma entidade E1 um subconjunto de outra entidade E2 se toda ocorrncia de E1 for
tambm uma ocorrncia de E2. um caso particular da hierarquia de generalizao.
Numa hierarquia de subconjunto o tipo de cobertura (p,e) sempre, no sendo
necessria sua representao no esquema conceitual.
A figura 1.8 um exemplo de hierarquia de subconjunto.

Cliente

nro-cli
nome-cli
endereo

Cliente
Especial

taxa-desconto

Fig.1.8 - hierarquia de subconjunto

Observaes:
1. O identificador da entidade genrica tambm um identificador para as entidades
da especializao.
9

2. Entidades da especializao podem ter outros identificadores, como mostrado na

figura 1.9.
RG
nome
ttulo

Pessoa

situaoserv-mil

Homem

Mulher
nomesolteira

Empr

Chefe

nro-emp

nome-diviso

Gerente

Militar

categoria

diviso
ident-nadiviso

posio

Fig. 1.9
1.4. Exerccios
1. Indique na figura 1.4 se a cobertura exclusiva ou de sobreposio.
2. Indique na figura 1.6 se a cobertura total ou parcial.
3. Indique as propriedades de cobertura da generalizao na figura 1.10.
Suposies: - s existem jogadores de futebol e de tnis;
- pode ter jogadores que jogam os dois esportes.
Jogador

Futebol

Tnis

Fig. 1.10
4. Verifique como as propriedades de cobertura da hierarquia de generalizao se
relacionam com as restries de cardinalidade de relacionamento. (Sugesto:
interprete hierarquias de generalizao como tipos especiais de relacionamento entre
classes).
5. Transforme as hierarquias do exerc.4 em relacionamentos entre a classe genrica e
as subclasses.
6. Considerando a propriedade fundamental de hierarquias de generalizao,
simplifique o esquema da figura 1.11.
10

mora
(1,n)
(1,n)
nascida

Cidade

Pessoa
(1,1)

(1,1)

(1,n)

nome

reside

Masculino

Feminino

(1,1)

(0,n)
idade
trabalha

Soldado
(0,1)

Empregado

idade
Fig. 1.11

7. Considere o esquema da figura 1.11. Como voc pode mud-lo para representar no
esquema todos os empregados, homens e mulheres?
8. Faa o esquema conceitual usando o modelo Entidade-RelacionamentoEstendido,
do seguinte problema:
Uma companhia mantm informaes sobre as pessoas que, de alguma forma,
possuem com ela algum vnculo, dentre essas seus funcionrios. Os seguintes
requisitos foram levantados junto aos usurios:
a. De cada pessoa mantm-se um cdigo, o nome, endereo.
b. De cada funcionrio guarda-se tambm seu salrio e o departamento a que ele
pertence. Desses funcionrios, alguns so gerentes e para cada um destes guarda-se os
nomes dos projetos que eles gerenciam.
c. Dos demais funcionrios que so operrios, guarda-se suas habilidades (um
operrio pode ter vrias habilidades).
d. Mantm-se tambm os
trabalhos executados na Companhia (cdigo e
caracterstica) e os operrios que executaram cada trabalho, juntamente com o perodo
que isto se deu. Sabe-se tambm que pode haver operrios que no exercem nenhum
tipo de trabalho dentre os cadastrados.
e. Deve-se tambm manter os dependentes de cada funcionrio (nome, sexo e data de
nascimento).

11

2. Modelos de Dados Orientados a Objetos

2.1. Introduo
A tcnica da orientao a objetos est cada vez mais popular para projetar e
implementar sistemas de natureza variada. Com relao a bancos de dados, essa
tcnica tem sido empregada, com predominncia, nos casos aonde os dados
envolvidos na aplicao considerada apresentam estrutura complexa.
A diferena existente entre os modelos de dados tradicionais (relacional,
hierrquico e em redes) e os modelos de dados orientados a objetos est na maneira
como eles vem os dados.
Os modelos de dados tradicionais vem os dados como uma coleo de tipos
de registros ou relaes, cada um tendo uma coleo de registros ou tuplas
armazenadas em um arquivo. J num modelo de dados orientado a objetos um banco
de dados considerado como uma coleo de objetos do mundo real.
Embora a informao sobre objetos complexos do mundo real possa ser
espalhada em tabelas relacionais, a meta dos bancos de dados orientados a objetos
manter uma correspondncia direta entre os objetos do mundo real e os do banco de
dados, podendo estes serem identificados e manipulados como um todo. Representar
um objeto complexo no modelo relacional significa que o objeto tem que ser
subdividido em um grande nmero de tuplas, o que leva necessidade de realizar um
considervel nmero de operaes de juno para recuperar o objeto.
Os conceitos da orientao a objetos formam uma boa base para aplicaes de
banco de dados mais avanadas, como por exemplo: aplicaes de engenharia tais
como CAD/CAM (Computer Aided Design/Computer Aided Manufacturation),
CASE (Computer Aided Software Engineering), sistemas de informao geogrfica,
sistemas de informao multimdia, sistemas de interface de usurio avanadas, etc.
Essas aplicaes tem requisitos e caractersticas que diferem das aplicaes
comerciais tradicionais, tais como estruturas de dados mais complexas, transaes de
durao mais longa, novos tipos de dados para armazenar imagens ou textos longos e
a necessidade de definio de operaes no padres especficas da aplicao. Os
bancos de dados orientados a objetos foram propostos para dar suporte s
necessidades dessas aplicaes mais complexas.

12

Os modelos de dados orientados a objetos usam os conceitos de abstrao de

dados dos modelos semnticos (classificao, generalizao e agregao) e
incorporam outros conceitos.
2.2. Conceitos Bsicos
Alguns conceitos encontrados nas linguagens de programao orientadas a
objetos (LPOO) so tambm aplicados nos modelos de dados orientados a objetos,
porm bancos de dados requerem alguns conceitos prprios.

Os objetos, em uma

LPOO, existem somente durante a execuo do programa e so por isso chamados de

transitrios. Um banco de dados orientado a objetos pode estender a existncia dos
objetos de modo que eles sejam armazenados permanentemente, isto , os objetos so
persistentes (eles persistem aps o trmino do programa e podem ser recuperados
posteriormente e compartilhados por outros programas.
A seguir so apresentados os principais conceitos envolvidos em bancos de
dados orientados a objetos.
2.2.1. Objetos e Identidade
Cada entidade do mundo real modelada como um objeto.
A cada objeto associado um estado e um comportamento: o estado representado
pelos valores dos atributos do objeto; o comportamento definido pelos mtodos que
agem sobre o estado do objeto pela invocao de operaes.
A cada objeto armazenado no banco de dados associado um identificador nico
(OID: Object Identifier), que gerado pelo SGBDOO (sistema de gerenciamento de
banco de dados orientado a objetos). O valor do OID no e visvel ao usurio, mas
usado internamente pelo sistema para identificar cada objeto de forma nica e criar e
gerenciar referncias entre objetos.
A principal propriedade de um OID que ele imutvel, isto , o valor do OID de
um particular objeto no deve mudar. O SGBDOO deve ter algum mecanismo para
gerenciar OIDs e preservar a propriedade de imutabilidade. tambm desejvel que
cada OID seja usado somente uma vez, isto , os OIDs dos objetos que so removidos
do banco de dados no so reaproveitados.
As duas propriedades acima implicam que o OID no deve depender de nenhum valor
de atributo do objeto. Geralmente considerado no apropriado basear o OID no
endereo fsico do objeto no meio de armazenamento, uma vez que o endereo fsico
13

pode mudar aps a reorganizao do banco de dados. Entretanto, alguns sistemas

usam o endereo fsico como OID, para aumentar a eficincia de recuperao do
objeto. Nesse caso, se o endereo fsico do objeto muda, pode ser colocado um
ponteiro indireto no primeiro endereo, indicando a nova localizao fsica do
mesmo. mais comum usar inteiros longos como OIDs e uma funo hash para
mapear o valor do OID para o endereo fsico do objeto.
2.2.2. Valores
A maioria dos SGBDOOs representam as entidades primitivas, tais como inteiros ou
caracteres, por valores (no possuem OIDs), enquanto as entidades no primitivas so
representadas como objetos. J outros sistemas, como o O2, permitem a definio de
valores complexos que no podem ser compartilhados por outros objetos, uma vez
que valores no possuem OIDs.
2.2.3. Estrutura do objeto
O valor de cada atributo de um objeto pode ser:
- atmico: integer, real, character, booleano, etc.
- complexo: definido atravs de construtores: tuple, set, list, bag e array.
O construtor de tipo tuple serve para agregar informaes afins. freqentemente
chamado de tipo estruturado, pois corresponde ao construtor struct nas linguagens de
programao C e C++.
Os construtores de tipo set, list, array e bag so chamados de tipos de coleo e
servem para definir atributos multivalorados. Podem ser no ordenados (set e bag) ou
ordenados (list e array). Em um set no pode haver dois elementos com o mesmo
valor, enquanto que na bag isso possvel.
2.3.4. OIDs x Chaves Primrias
Nos modelos orientados a objetos no existe o conceito de chave primria como
acontece no modelo relacional. Ao invs disso, existem os OIDs dos objetos que,
como j dito, so criados e mantidos pelo sistema de gerenciamento de banco de
dados e no so de acesso do usurio.
As vantagens do uso de OIDs com relao s chaves so:
- os programadores de aplicaes no precisam se preocupar com a seleo de chaves
para as vrias classes de objetos;

14

- obtm-se melhor desempenho, pois os OIDs so implementados em baixo nvel pelo

sistema;
- embora as chaves sejam mais significativas ao usurio, muitas vezes o usurio
precisa usar cdigos artificiais, sem significado semntico, para poder identificar as
tuplas de uma relao.
2.3.5. Objetos Complexos
A composio estrutural de um objeto definida atravs de um
atributos.

conjunto de

O valor de cada atributo pode ser primitivo, um objeto ou uma

combinao dos construtores tupla, lista, array, conjunto ou bag, envolvendo outros
objetos ou no. Objetos complexos so definidos atravs de construtores envolvendo
outros objetos.
Quando o valor de um atributo de um objeto O um objeto O, o sistema armazena o
identificador de O em O ou todo o valor complexo armazenado no atributo do
objeto.
2.3.6. Encapsulamento
A cada objeto est associada sua estrutura e seu comportamento (os mtodos ou
operaes). O comportamento armazenado no banco de dados junto com a estrutura
do objeto.
O conceito real de encapsulamento determina que somente as operaes sobre os
objetos so visveis e sua estrutura escondida. Em banco de dados a noo de
invisibilidade da estrutura do objeto afrouxada. desejvel, por exemplo, poder
consultar os atributos do objeto atravs de uma linguagem de consulta. Assim, a
maioria dos SGBDOOs permitem acesso direto aos atributos fornecendo operaes
definidas pelo sistema para a leitura e modificao dos atributos, o que livra o usurio
da incumbncia de implementar uma considervel quantidade de mtodos cujo nico
propsito ler e escrever os valores dos vrios atributos dos objetos. Isso um
exemplo de violao do encapsulamento permitida pelos SGBDOOs. Esses sistemas,
porm, possuem mecanismos para que o usurio possa proteger o acesso aos atributos
dos objetos, caso desejvel.

O sistema O2, por exemplo, permite o usurio

estabelecer quais atributos e mtodos so visveis na interface do usurio, atravs da

declarao public, o que permite serem invocados por qualquer outro objeto. Os no
visveis so referidos como private.
15

2.3.7. Mtodos
Os objetos nos SGBDOOs so manipulados atravs de mtodos. Em geral, a definio
de um mtodo consiste de assinatura e corpo. A assinatura especifica o nome do
mtodo, os nomes e classes dos argumentos e a classe do resultado, se existir. O corpo
representa a implementao do mtodo e consiste de um conjunto de instrues
expressas em uma dada linguagem de programao.
2.3.8. Tipos e Classes
Um tipo modela as caractersticas comuns de um conjunto de objetos e corresponde
noo de tipos abstratos de dados. Uma classe um conjunto de objetos que tem
exatamente a mesma estrutura interna, i., os mesmos atributos e mesmos mtodos.
Os modelos de dados orientados a objetos usam o conceito de classe como uma base
para instanciao.
2.3.9. Herana
um mecanismo de reusabilidade muito poderoso. Com herana, uma classe
chamada uma subclasse pode ser definida com base na definio de outra classe
chamada a superclasse. A subclasse herda os atributos, mtodos e mensagens de sua
superclasse e pode ter atributos especficos, mtodos e mensagens adicionais.
Exemplo: Considere duas classes com informaes sobre um conjunto de nibus e
caminhes. As caractersticas das duas classes so mostradas na figura 2.1 cuja
notao grfica utilizada representa cada classe por um retngulo dividido em 3
partes. A parte superior contm o nome da classe; a do meio contm os atributos e a
inferior contm os mtodos definidos pelo usurio. Como as duas classes possuem
algumas caractersticas em comum, pode-se criar a classe Veculo para conter essas
caractersticas, como na figura 2.2. Somente as caractersticas prprias de cada
subclasse so mantidas na mesma.

16

Caminho

nibus

nro-placa:STRING
modelo:STRING
licena:NUMBER
data_ltima_reviso:DATE
valor_estimado:NUMBER
prxima_reviso:DATE

nro-placa:STRING
modelo:STRING
lugares:NUMBER
data_ltima_reviso:DATE
prxima_reviso:DATE

Fig.2.1

Veculo
nro-placa:STRING
modelo:STRING
data_ltima_reviso:DATE
prxima_reviso:DATE

Caminho
licena:NUMBER
valor_estimado:NUMBER

nibus
lugares:NUMBER

Fig. 2.2 - Hierarquia de herana

Vantagens da utilizao de hierarquias de classe:

- diminui a quantidade de cdigo a ser escrito;
- propicia uma descrio mais precisa e concisa da realidade.
Em certos sistemas, uma classe pode ter vrias superclasses, em cujo caso diz-se que
ocorre herana mltipla (fig.2.3), enquanto outros impem a restrio de uma nica
superclasse, dita herana simples.

17

Veculo
nro-placa:STRING
modelo:STRING
data_ltima_reviso:DATE
prxima_reviso:DATE

Caminho

Veculo_Passageiro
rota: STRING
preo:NUMBER
horrio_sada:NUMBER

nibus

licena:NUMBER
valor_estimado:NUMBER

lugares:NUMBER

Fig. 2.3 - Herana mltipla

A herana mltipla pode provocar problemas de conflitos, como por exemplo, duas ou
mais superclasses podem ter um atributo com o mesmo nome, mas com diferentes
domnios. Esses conflitos precisam ser tratados pelo sistema. Se existe uma relao de
incluso entre os domnios, ento o domnio mais especfico ser escolhido como o
domnio para a subclasse. Por exemplo, se na classe Veculo existir o atributo
combustvel cujo domnio : (gasolina, lcool, diesel) e em Veculo_Passageiro
existir tambm o atributo combustvel cujo domnio (diesel), a classe nibus
herdar o atributo combustvel cujo domnio ser (diesel) (figura 2.4), isto , o
domnio mais restrito. Se essa relao no existe, uma soluo adotada a escolha do
domnio com base na ordem de precedncia entre as superclasses. Outros sistemas
deixam por conta do usurio a resoluo do conflito.
Em um esquema de bd, as classes podem ser organizadas em uma hierarquia de
herana, formando um grafo acclico dirigido.

18

Veculo
nro-placa:STRING
modelo:STRING
data_ltima_reviso:DATE
combustvel:(gasolina, lcool,diesel)
prxima_reviso:DATE

Veculo_Passageiro
rota: STRING
preo:NUMBER
horrio_sada:NUMBER
combustvel:(diesel)

nibus
lugares:NUMBER

combustvel:(diesel)

Fig. 2.4 - Herana mltipla

2.3.10. Polimorfismo
Os SGBDOOs oferecem o recurso de polimorfismo de operaes, tambm conhecido
como sobrecarga de operador (overloading). Outros conceitos relacionados com o
polimorfismo so os de late binding (ligao tardia) e overriding (redefinio de
operao).
Para melhor expor esses conceitos, considere uma operao display que recebe um
objeto como entrada e apresenta o objeto na tela. Se o objeto for:
- uma imagem: deseja-se apresentar a imagem;
- uma pessoa: deseja-se apresentar os dados sobre a pessoa (nome, endereo, etc);
- um grfico: deseja-se apresentar uma representao grfica.
Usando um sistema convencional, seriam necessrias 3 operaoes: display_pessoa,
display_figura e display_grfico, como mostrado a seguir:
for x in X do
begin
case of type(x)
pessoa: display_pessoa(x);
figura: display_figura(x);
grfico: display_grfico(x);
end;
end;

19

Em um sistema orientado a objetos, a operao display pode ser definida em uma

classe mais geral. A operao tem um nico nome e pode ser chamada
indiscriminadamente por vrios objetos. A implementao da operao redefinida
para cada uma das subclasses. Essa redefinio chamada overriding. O sistema
decide qual implementaco usar para execuo. Assim, o cdigo dado simplificado
para:
for x in X do display(x)
A ligao do nome da operao com a correspondente implementao realizada em
tempo de execuo. Essa ligao retardada dita late binding.
A sobrecarga (overloading) de operador refere-se ao uso do mesmo smbolo de
operador para denotar operaes distintas sobre diferentes tipos de dados.

20

3. Modelagem de Dados Orientada a Objetos

3.1. Motivao
A motivao mais imediata para a adoo dos princpios da orientao a
objetos para a modelagem de dados que o mundo real pode ser visto como uma
variedade de objetos inter-relacionados.
Os objetos podem ser vistos em diferentes nveis de detalhe. Por exemplo, para
um observador, uma rvore pode ser vista como um objeto indivisvel, sem levar em
considerao sua composio em folhas, troncos, raiz, etc. Outro observador pode
estar interessado em analis-la com mais detalhe, por exemplo, considerando a cor,
textura e forma das folhas. Neste caso, as folhas so consideradas objetos que fazem
parte da composio do objeto rvore.
Essa maneira natural de ver a composio dos objetos deve ser conservada na
modelagem dos objetos e o objetivo dos modelos de dados orientados a objetos,
fornecendo uma representao mais natural do mundo real.
Assim como na modelagem de dados convencional, a modelagem de dados
orientada a objetos aqui abordada ser realizada em 2 fases:
1. Projeto conceitual:
Essa fase visa o projeto de um esquema conceitual que apresente uma abstrao do
problema do mundo real. Uma diferena quando se trata de projeto conceitual do
banco de dados orientado a objetos que, alm da definio da estrutura dos objetos,
tambm so definidos os mtodos que manipulam esses objetos. Assim, toda a
funcionalidade do sistema definida juntamente com a estrutura dos objetos.
2. Projeto lgico: projeto de uma estrutura lgica, representando o esquema lgico
do banco de dados orientado a objetos, com base no esquema conceitual.
3.2. Desenvolvimento de Sistemas Orientados a Objetos
O desenvolvimento de sistemas orientados a objetos usa uma abordagem
diferenciada daquela utilizada para o desenvolvimento de sistemas de informao
tradicionais.
21

 Desenvolvimento de sistemas tradicionais:

O desenvolvimento de sistemas de informao nos moldes convencionais
realizando com base na perspectiva dos dados e na dos processos.
Do ponto de vista da perspectiva dos dados, o desenvolvimento do sistema
envolve a modelagem E-R dos dados, a anlise relacional, a gerao do esquema
lgico e a implementao fsica do bd.
Sob a perspectiva dos processos, o desenvolvimento do sistema trata os
requisitos funcionais do sistema envolvendo a construo de DFDs (diagramas de
fluxos de dados), especificao das funes do sistema e dos mdulos de programa.
Desenvolvimento orientado a objetos:
O desenvolvimento orientado a objetos usa o princpio de abstrao de dados, aonde
as funcionalidades do sistema so associadas com os objetos (objetos encapsulam
dados e comportamento).
3.3. Modelando Objetos
Na modelagem da estrutura dos objetos, dois tipos de hierarquias so
utilizadas: a hierarquia de agregao (relacionamento -PARTE-DE) e a hierarquia
de generalizao/especializao (relacionamento -UM). No esquema lgico do
banco de dados o.o., hierarquia de agregao estabelecida atravs de referncias. A
hierarquia de generalizao/especializao

estabelecida atravs de declaraes

prprias. A seguir apresenta-se, atravs de exemplos usando uma linguagem de

definio de objetos fictcia, como realizada a definio das classes e a definio de
hierarquias de generalizao/especializao.
3.3.1. Definio de classe
A definio de classe uma especificao abstrata. Por exemplo: classe
Conta_Corrente com as propriedades: nro_conta, proprietrio, saldo_corrente (veja
especificao abaixo). As propriedades podem ser definidas em termos de outras
classes: o proprietrio de uma conta uma instncia de uma classe Cliente. As
propriedades de proprietrio representam objetos inteiros, no valores de chaves ou
ponteiros.
class Conta_Corrente
properties
22

nro_conta: Integer;
proprietrio: Cliente;
saldo_corrente: Money;
operations
deposito(quantia: Money);
retirada(quantia: Money);
end Conta_Corrente.
class Cliente
properties
nome: String;
...
operations
...
end Cliente

3.3.2. Herana
Para especificar a hierarquia de classe e subclasse ser utilizada a declarao
inherits. No exemplo a seguir tem-se que a classe Carro herda todas as propriedades e
operaes da classe Veculo.
class Veculo
properties
nro_reg, marca, modelo: String;
cor: String;
milhas: Integer;
tipo_combustvel: (lcool, gasolina, dsel);
ano: Integer;
operations
...
end Veculo.
class Carro
inherits Veculo
properties
tipo_combustvel: (lcool, gasolina); {redefinido}
{propriedades adicionais de carro}
tamanho: (compacto, mdio, grande);
extras: set(String);
end Carro.

3.4. Representao grfica

A seguir ser apresentada uma notao grfica para representao conceitual
de objetos, que tem como objetivo oferecer uma forma simplificada para a
modelagem de um banco de dados orientado a objetos. Vrias notaes existem na
23

literatura, entre elas a UML, que podem ser adotadas para essa fase do projeto do
banco de dados o.o. A adoo dessa notao visa simplicidade e utilizao dos
recursos dos construtores tuple, list e set, que so bastante expressivos para uma
variedade de aplicaes de bdoo.
3.4.1. Representao de uma classe de objetos

nome da classe
nome_mtodo(param);
...

atributo1
atributo2
...

atributon

3.4.2. Representao de conjunto, lista e tupla

Conjunto (SET):
Tupla (TUPLE):
Lista (LIST):

Exemplo:
nome-rua
Pessoa

nome
endereo
telefone
filhos

rua
bairro
Dependente

nmero
nome
sexo
datanasc

Fig. 3.1
Na figura 3.1 est representado que uma pessoa pode ter vrios telefones,
sendo que os mesmos devem ser armazenados segundo uma ordem. Essa ordem
definida de acordo com a semntica da aplicao; por exemplo, a lista de telefones
24

pode estar representando a ordem de preferncia a ser usado para se entrar em contato
com a pessoa. Cada pessoa pode possuir vrios filhos, que esto representados por
um conjunto de objetos do tipo Dependente.
ATENO:
Quando um atributo possui tipo simples e envolve o construtor SET ou LIST, a
indicao desse construtor inserida na seta de definio do atributo.

3.4.3. Herana simples

a) uma s subclasse

Pessoa

Cliente

b) vrias subclasses

nome
endereo
telefone

nro-cliente
ender-comercial

Pessoa

ClienteCasual

Fig. 3.2 a e b - Herana Simples

3.4.4. Herana mltipla

* : indica o atributo a ser herdado no caso de conflito.

25

renda
limitecred

nome
endereo
telefone

ClienteFrequente

nro-cliente
dbito

nome
endereo
cpf

Cliente

Funcionrio

Cliente Interno

nome*
nro-carteira-trab
endereo*
salrio

dbito

Fig. 3.3- Herana Mltipla

3.4.5. Definio recursiva

nome
endereo
filhos

Pessoa

Fig. 3.4 - Definio Recursiva

3.4.6. representao de referncias inversas

Quando a referncia entre duas classes nos dois sentidos, usa-se a notao da
figura 3.5, aonde est representado que cada projeto possui um conjunto de
empregados (atravs do atributo empregs) e cada empregado atua em um projeto.

Projeto

empregs

proj

Empregado

Fig. 3.5 - referncias inversas

3.5. Gerao do Esquema Lgico

Para a gerao do esquema lgico ser adotada a linguagem utilizada na seo
3.3, cuja forma geral dada seguir:

26

class nome_da_classe
inherits nome_superclasse1, . . ., nome_superclassej
properties
nome_atrib1: tipo;
nome_atrib2: tipo;
...
nome_atribj: tipo;
operations
nome_mtodo(parmetros); ... ;
end nome_da_classe
A definio do tipo segue a seguinte regra de sintaxe:
tipo :: = tipo-bsico / nome-classe /tipos_inversos
tuple (nome-atributo: tipo [, nome-atributo:tipo] ...) /
set(tipo) /
list(tipo)
tipo-bsico :: = Integer / Real / String / Boolean / ...
nome-classe : nome de uma classe existente (um identificador)
nome-atributo : identificador
tipos_inversos: nome_classe_inversa inverse is nome_classe_inversa. atrib_inverso/
set(nome_classe_inversa) inverse is nome_classe_inversa. atrib_inverso/
list(nome_classe_inversa) inverse is nome_classe_inversa. atrib_inverso/
Por conveno, nos esquemas conceitual e lgico, os nomes dos atributos so escritos
com letras minsculas e os nomes das classes iniciam com letra maiscula.
Exemplo : O esquema da figura 3.1 expresso como:
class Pessoa
properties
nome : String;
endereo: tuple ( rua: tuple ( nome_rua: String, nmero: Integer),
bairro:String);
telefone: list (Integer);
filhos: set (Dependente);
end Pessoa

class Dependente
properties
nome: String;
sexo: String;
data_nasc: Date;
27

end Dependente
A especificao das classes da figura 3.5 dada a seguir:
class Projeto
properties
empregs: set(Empregado) inverse is Empregado.proj;
end Projeto;
class Empregado
properties
proj: Projeto inverse is Projeto.empregs;
end Empregado;

3.6. Exemplo: Banco de Dados para Gerenciamento de Projetos

Suponha que deseja-se manter um banco de dados com informaes sobre os projetos
desenvolvidos pelos grupos de pesquisa de uma instituio. As informaes a serem
armazenadas referem-se aquelas sobre projetos, especificando as tarefas que
compem cada projeto, os grupos de pesquisa que desenvolvem as tarefas do projeto,
os pesquisadores que fazem parte dos grupos e os documentos produzidos relativos
aos projetos. O esquema conceitual orientado a objetos desse banco de dados
mostrado na figura 3.6, aonde se tem que:
- Um projeto pode ser organizado na forma de vrios sub-projetos e a classe Projeto
definida recursivamente em termos dela mesma.
- Um plano de trabalho, consistindo de vrias tarefas, associado a cada projeto.
- Cada tarefa atribuda a um grupo de pesquisa que consiste de vrios pesquisadores
e tem um coordenador. Note-se que o coordenador de uma tarefa no
necessariamente o coordenador do grupo de pesquisa atribudo para a tarefa. Para
cada tarefa so identificadas as tarefas que a antecedem.

28

Para cada projeto h vrios documentos produzidos, que podem ser artigos
publicados em jornais ou conferncias ( cujos autores so pesquisadores que
atuam no projeto), ou relatrios tcnicos internos do projeto.

Os seguintes mtodos devem ser definidos:

-

Calcular_esforo, para a classe Tarefa, que calcula o esforo dedicado pelos

pesquisadores para desenvolvimento da tarefa, em termos do tempo dedicado.

Associar_membro, para a classe Grupo, que insere um novo pesquisador num

determinado grupo de pesquisadores.

Analisar_documento,

que

recupera

documentos

de

uma

determinada

classificao.
-

Calcular_bnus, que calcula o valor total dos bnus recebidos pelos

pesquisadores.

A figura 3.6 mostra o esquema conceitual do banco de dados o.o. desse exemplo,
usando a notao dada. Para permitir uma comparao com a UML, uma verso desse
esquema, usando sua notao, tambm fornecida na figura 3.10.

29

nome_ proj
objetivo
documento
plano_trabalho
sub_projeto

Projeto

tpicos
incio_validade
fim_validade
evoluo

Tarefa

calcular_esforo()

Documento
analisar_doc(classif:String)

Relatrio_
Tcnico

data_incio
data_fim
descrio_tarefa
coordenador
anos_homem
participante
precede

Artigo

Pesquisador
calcular_bonus()

Grupo
associar_membro()
Fig.3.6 Banco de Dados para Gerenciamento de Projetos

30

cdigo_doc
nome
classificao

autor
tipo_publ
local_publ
data_publ

nome
especializao
salrio
bnus_produo

nome_grupo
membro
coordenador

3.7. Notao adotada X diagrama de classes UML

UML (Universal Modeling Language) uma linguagem de modelagem de objetos,
desenvolvida principalmente para projeto de software. Os diagramas de classes, que
fazem parte de UML, possuem alguma semelhana com os diagramas EER. Para
acompanhar a discusso a seguir, considere o esquema de banco de dados EER de
uma companhia, da figura 3.7, e sua representao na notao UML na figura 3.8
(apresentados no livro de Elmasri & Navathe, 2000). Os tipos de entidades da figura
3.7 so modelados como classes na figura 3.8. Na notao UML, uma classe
representada por uma caixa com 3 sees: a do topo contm o nome da classe; a seo
do meio contm os atributos dos objetos da classe e a ltima seo contm as
operaes que podem se aplicadas sobre esses objetos. Opcionalmente pode-se
especificar o domnio dos atributos (por exemplo: datanasc: date), como mostrado na
figura 3.8. Um atributo composto modelado como um domnio estruturado, como
ilustrado pelo atributo Nome da classe Empregado. Um atributo multivalorado
geralmente modelado como uma classe separada, conforme ilustrado pela classe
Localizao.
Na terminologia UML, tipos de relacionamentos so chamados associaes e
instncias de relacionamentos so chamados links. Uma associao binria
(correspondendo a um tipo de relacionamento binrio do modelo EER) representada
atravs de uma linha conectando as classes participantes e podem opcionalmente Ter
um nome. Um atributo de relacionamento, chamado de atributo de ligao (link
attribute) colocado em uma caixa que conectada linha da associao por uma
linha pontilhada. A notao (min, max) usada para especificar restries de
relacionamento no modelo EER, chamada de multiplicidade em UML.
Multiplicidades so representadas na forma min .. max, e o asterisco (*) indica que
no h limite mximo na participao. Note-se que as multiplicidades so colocadas
nos lados opostos do relacionamento quando comparadas notao do modelo EER.
Em UML, um asterisco sozinho indica uma multiplicidade de 0..*, e 1 sozinho indica
uma multiplicidade de 1..1. Um relacionamento recursivo (relacionamento unrio)
chamado uma associao reflexiva em UML e os nomes dos papis, da mesma forma
que as multiplicidades, so colocados nos lados opostos quando comparados ao
diagrama EER.
31

Em UML h dois tipos de relacionamentos: associao e agregao. Uma

agregao representa um relacionamento entre um objeto e suas partes componentes.
Na figura 3.8 as localizaes de um departamento e a localizao de um projeto foram
modelados como agregaes. Associaes e agregaes no possuem propriedades
estruturais diferentes, elas diferem apenas no significado semntico. No modelo EER,
ambas so representadas como relacionamentos. Associaes ou agregaes
unidirecionais, em UML, so mostradas com uma seta para indicar que somente
necessria uma direo para acessar os objetos. Instancias de relacionamento podem
ser especificadas como sendo ordenadas.
prim_nome

nome
nroE

sexo

Empregado

sobrenome
endereo
salrio
data nasc (1,1)

nroD

(0,1)

(4,n)

Trabalha
data-incio

nro-empregados
nome
localizao (1,n)
Departamento

(1,1)

(0,n)

Gerncia

(0,n)
Supervisiona

(0,1)

supervisionado

(1,n)

horas

Controla

Atua

Supervisiona

(1,n)

(0,n)

(1,1)

Projeto

Possui
(1,1)

Dependente

nro nome localizao

nome
sexo
Data_nasc
grau-parentesco

Figura 3.7- Esquema EER - BD Companhia

32

Departamento

Empregado
4..*
nroE
nome
prim_nome
sobrenome
sexo: { M,F}
endereo
salrio
data_nasc: Date

Trabalha

1..1

1..1

nroD
nome

0..1
Adiciona-empr
Nro-empregados
Muda-gerente
...

Gerncia

0..*

1..1

Data_Inicio
1..*

1..*
Localizao

controla

Nome
idade
muda-depto
...

Nome Dependente

Atua
supervisionado
*

Horas

0..1
supervisiona

1..*

Projeto
Nome
Nro

1..1

0..*

Adiciona_empr
Adiciona_projeto
...

Dependente
Sexo: {M,F}
Data nasc: Date
Grau-parentesco
...
Figura 3.8 Diagrama de classes UML BD Companhia

As operaes dadas em cada classe podem ser acompanhadas pelos parmetros.

Entidades fracas podem ser modeladas usando o construtor chamado associao
qualificada (ou agregao qualificada). A chave parcial colocada em uma caixa
anexada classe proprietria.

33

A notao UML para generalizao/especializao mostrada na figura 3.9. O

tringulo vazio indica cobertura exclusiva e o tringulo cheio indica cobertura de
sobreposio.
Pessoa
nro
nome
endereo
RG

Cliente

Empregado

tipo cliente
porcent-desconto

Salrio

Pessoa fisca

Pessoa Juridca

CPF

CGC

Figura 3.9 Generalizao/especializao em UML

Na Figura 3.10 tem-se o BD Companhia modelado segundo a notao de objetos
considerada nesta apostila e a figura 3.11 mostra o BD de Projeto modelado segundo
a notao UML, usando a ferramenta Rational Rose.

34

prim_nome

nome
nroE

sobrenome
sexo endereo salrio
data_nasc

Empregado

depto-trab
ger

idade
muda-depto
...
supervisor

depends

emprs

gerente

data-incio

atua

...

proj

nroD

Adiciona-empr
Nro-empregados
Muda-gerente
...

nome

projs

horas

Dependente

Departamento

emps

Projeto
adiciona-empr
adiciona-proj
nome nro localizao

grau_parentesco
nome sexo data_nas
Figura 3.10 Esquema de Objetos - BD companhia

35

+compe
0..1

gera

Projeto
nome_proj : string
objetivo : string

0..*
+_composto

0..*

Relatrio_Tcnico
tpicos : string
incio_validade : date
fim_validade : date

1..*

0..*

Tarefa
data_inicio : date
data_fim : date
descrio_tarefa : string
anos_homem : float

0..*
+precede

analisar_documento()

1
possui

+_precedida

Documento
codigo_doc : int
nome : string
classificao : string

Artigo
tipo_publ : string
local_publ : string
data : date
0..*
escreve

0..*

calcular_esforo()
1..*

1..*

coordena

participa
1

1
1..*

Grupo

membro

1..*

nome_grupo : string
associar_membro()

Pesquisador
nome : string
especializao : string
salrio : float
bnus_produo : float

1
0..1

calcular_bnus()

coordena

Fig.3.11 - BD de Projeto- notao UML

Legenda
Class

Multiplicity

ClassName
attributes
operations()
Agregation

zero

one

0..1

zero or one

0..*

zero or more

1..*

one or more
n

Association

36

3.8. Exerccios
1. Mapeie o esquema da figura 3.6 para a linguagem de especificao de objetos dada
na seo 3.5.

2. Desenvolva o esquema conceitual orientado a objetos do problema do exerccio 8

do captulo 1 e faa o mapeamento para a linguagem de especificao de objetos
dada.
3. Desenvolva o esquema conceitual orientado a objetos da aplicao a seguir,
referente ao cadastro imobilirio de uma cidade. Faa o mapeamento para a
linguagem de especificao de objetos dada.
Nessa aplicao esto envolvidas informaes relativas a bairros, ruas,
quadras, segmentos de quadras e imveis.
As informaes a serem mantidas sobre cada bairro so: Nome do bairro,
delimitao (regio que delimita o bairro) e composio (quadras que compem o
bairro).
Sobre cada quadra, necessrio armazenar: cdigo da quadra e composio
(imveis que compem a quadra).
Com relao s ruas, deve-se guardar o cdigo da rua, nome, o incio da rua
(ponto de coordenadas (x,y)) e a composio (segmentos de quadra que compem a
rua).
Os segmentos de quadra devem possuir um cdigo, nmero inicial, nmero
final e composio (uma seqncia ordenada de pontos (x,y)).
Quanto aos imveis, as informaes a serem mantidas so: cdigo de
inscrio, proprietrio (nome e categoria: particular, municipal,etc), localizao (rua,
nmero, bairro).
No caso de haver construo no imvel, deve-se guardar tambm informaes
sobre: utilizao (residencial, comercial,...) e delimitao da construo.

37

4. Deseja-se desenvolver um banco de dados que armazene informaes sobre um

acervo de CDs e Livro. O banco de dados deve conter informaes sobre os CDs,
como a nacionalidade, o tipo de CD, se musical ou multimdia, no permitindo para
um mesmo CD, ser de ambos os tipos. Se for CD de msica, as informaes
consistem no nome do CD, cantores e compositores, gnero, nmero de msicas e
tempo total gravado; caso seja multimdia, o tipo de software e a empresa
responsvel. Para os Livros deseja-se informaes como nome, autores, editora,
gnero, edio e encadernao. A base de dados tambm armazena informaes sobre
emprstimo de CDs e Livros a pessoas fsicas, armazenando o nome da pessoa,
telefone, e-mail e a data de emprstimo, permitindo assim, o controle do acervo.
Suponha que as seguintes atividades devem ser realizadas:
a) Dado um ttulo (referente a um nome de Cd ou de Livro), recuperar:
-

gnero e compositores, se for CD de msica;

empresa responsvel, se for CD Multimdia; ou

nomes dos autores, se for livro.

a) Dado o nome de um CD, recuperar nome e telefone da pessoa que emprestou o

CD.
b) Dado o nome de uma Pessoa Fsica, mostrar seu telefone e o nome dos CDs que
ela emprestou.
Faa um esquema conceitual e o esquema lgico correspondente.

38

4. Manipulando Objetos
A manipulao de objetos feita atravs de uma linguagem de consulta a
objetos. Uma linguagem de consulta oferece uma forma de recuperar informaes do
banco de dados de uma maneira declarativa e formulada em alto nvel. Muitos
Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos utilizam uma
extenso da linguagem de consulta SQL (Structured Query Language), uma das mais
utilizadas para SGBDs relacionais, incorporando nesta mecanismos para manipulao
da estrutura complexa dos objetos.
A formulao de consultas podem ser feitas interativamente para recuperar
objetos do banco de dados ou podem ser embutidas em uma linguagem de
programao, na definio de mtodos.
4.1. Caractersticas de Linguagens de Consulta OO (LCOO)
4.1.1. Hierarquias de Agregao
No modelo relacional, para consultar informaes envolvendo mais do que uma
tabela, usa-se a operao de juno sobre seus atributos chaves (primrias / estrangeiras).
Como exemplo, suponha as tabelas abaixo e, a seguir, uma consulta sobre essas
tabelas:
Projeto (codproj, nome_proj, objetivo, ...)
Tarefa (codtarefa, data-incio, data-fim, ...,codproj, codpesq)
Pesquisador(codpesq, nome, especializao,salrio)
Encontre todos os nomes de projetos que tm pelo menos uma tarefa possuindo, como
seu coordenador, um pesquisador especializado em banco de dados.
Essa consulta pode ser expressa em SQL como dado a seguir, aonde se nota a
utilizao de dois predicados de juno :
SELECT DISTINCT Projeto.nome_proj
FROM Projeto, Tarefa, Pesquisador
WHERE Projeto.codproj = Tarefa.codproj and
Tarefa.codpesq = Pesquisador.codpesq and
Pesquisador.especializao = BD

39

Nas linguagens de consulta orientadas a objetos so utilizadas expresses de caminho

de modo que as junes sejam formuladas de forma mais direta, sendo referidas como
junes implcitas. Isso ocorre devido forma em que os objetos so estruturados
envolvendo hierarquias de agregao, conforme mostrado na figura 4.1. Nessa figura,
o atributo de uma classe C1 tem como domnio uma classe C2 estabelecendo um
relacionamento de agregao entre as duas classes. C2, por sua vez, definido em
termos da classe C3. Diz-se ento que essas classes esto organizadas no esquema
atravs de uma hierarquia de agregao.
C1

atrib_c1

C2

atrib_c2

C3

atrib_c3

Fig. 4.1 - Hierarquia de agregao

Isso implica em certas extenses linguagem de consulta, para possibilitar a
navegao atravs da estrutura do objeto, com facilidade (tente imaginar, por
exemplo, como se pode expressar a consulta dada anteriormente, sobre o esquema da
figura 3.6, utilizando a juno implcita).
4.1.2. Hierarquia de Herana
Numa hierarquia de herana, pode-se querer consultar s a classe raiz ou a classe e
todas as suas subclasses. interessante que a linguagem de consulta oferea as duas
possibilidades.
4.2. Consultando Objetos
4.2.1. Hierarquias de Agregao
Numa hierarquia de agregao, a expresso de caminho pode envolver
referncias simples ou multivaloradas. A seguir so apresentadas expresses de
consultas envolvendo essas duas formas de referncia. A sintaxe apresentada baseiase em linguagens de consulta de gerenciadores existentes, mas no se refere
exatamente sintaxe de um gerenciador especfico.
Referncias Simples
Com base na figura 4.1, a consulta:
selecionar o valor do atributo atrib_c3 de um objeto x pertencente classe
C1, que satisfaz uma certa condio
40

pode ser expressa como:

Select x. atrib_c1. atrib_c2. atrib_c3
From x in C1
Where condio de seleo
Exemplo: Expressar a seguinte consulta no Banco de Dados de Projeto (figura 3.6):
Selecionar o nome dos coordenadores das tarefas que iniciaram em 01/02/99.
Select t.coordenador.nome
From t in Tarefa
Where t.data_incio = '01/02/1999'

Referncias Multivaloradas
Considere a figura 4.2 e a seguinte consulta:
Selecionar os valores do atrib_c2 de um objeto x pertencente classe C1, que
satisfaz uma certa condio.
Como existe uma referncia multivalorada de C1 para C2, necessrio percorrer
cada elemento do atributo atrib_c1 para recuperar o valor correspondente de
atrib_c2 desse elemento.
C1

atrib_c1

C2

atrib_c2

Fig. 4.2 - Uso de Referncia Multivalorada

Select y.atrib_c2
From x in C1
y in x.atrib_c1
Where condio de seleo
Exemplo: Na figura 3.6: Selecione o cdigo e a classificao dos documentos
do Projeto "Projeto A".
Select d.cdigo_doc, d.classificao
From p in Projeto
d in p.documento

// documento o nome do atributo e no da classe

Where p.nome_proj = "Projeto A"

41

4.2.2. Hierarquia de Herana

A recuperao de informaes de uma subclasse que foram herdadas de uma
superclasse, podem ser referenciadas como pertencente subclasse. Exemplo:
com base na figura 3.5, pode-se formular a seguinte consulta: Selecione os nomes
dos artigos publicados em 20/05/99.
Select a.nome
From a in Artigo
Where a.data = "20/05/1999"
4.3. Definio de Mtodos
A seguir so apresentados os algortmos de alguns mtodos desenvolvidos para o
Banco de Dados da figura 4.3, que uma simplificao do Banco de Dados de
Projeto. Alguns gerenciadores de banco de dados orientados a objetos possuem
uma linguagem de quarta gerao, estilo C++, para a codificao dos mtodos.
Opcionalmente permitem o uso de outras linguagens de programao, tais como
C++, C, Smalltalk, nas quais pode-se embutir comandos da linguagem de consulta
do gerenciador.

42

Projeto
Busca_Proj
Cadastra_Projeto

cod_proj
objetivo
documento
coordenador
nome_proj

Documento
Mostra

cdigo_doc
nome
classificao

Mostra_Documentos
Elimina_Proj

tpicos
incio_validade
fim_validade

Relatrio_
Tcnico
Cadastra_RT
Mostra

Artigo

aut_princ
tipo_publ
local_publ
data_publ

Cadastra_Art
Mostra

Pesquisador
Busca_Pesq
Cadastra_Pesq

nome
especializao
salrio
bnus_produo

Fig. 4.3 - BD de Projeto simplificado

Alguns dos mtodos definidos nas classes da figura 4.3 so dados a seguir, usando
uma linguagem algortmica.

1. Cadastrar um Projeto, sem documentos e com coordenador

Mtodo Cadastra_Projeto(nome_coord:String,codigo:Integer, obj:String,

nome_projeto:String) da classe Projeto
proj:Projeto;
pesq:Pesquisador;
{ pesq=Busca_Pesq(nome_coord);
proj.cod_proj=codigo;
proj.objetivo=obj;
proj.coordenador=pesq;
proj.nome_proj=nome_projeto;
Insira proj em Projeto;
}

43

2. Recuperar um Pesquisador, dado seu nome.

Mtodo Busca_Pesq(nome_pesq:String):Pesquisador da classe Pesquisador

{Select pesq
From pesq in Pesquisador
Where pesq.nome=nome_pesq
return(pesq);
}

3. Recupera um projeto dado seu cdigo.

Mtodo Busca_Proj(codigo_proj:Integer):Projeto da classe Projeto
{ Select proj
From proj in Projeto
Where proj.cod_proj=codigo_proj;
return(proj);
}

4. Mostrar os documentos (Relatrio Tcnico ou Artigo) de um projeto, dado seu

cdigo. Se Relatrio Tcnico, mostrar incio e fim de validade e o nome. Se Artigo,
mostrar tipo de publicao e nome do artigo.

Mtodo Mostra ( ) da classe Documento

{ } // no faz nada

Mtodo Mostra( ) da classe Relatrio_Tcnico

// Mostrar incio e fim de validade e nome do relatrio tcnico
resultado: tupla(incio_val:Date, fim_val:Date, nome_rel:String)
{resultado.inicio_val = self.inicio_validade;
resultado.fim_val = self.fim_validade;
resultado.nome_rel = self.nome;
display(resultado);
}

44

Mtodo Mostra( ) da classe Artigo

//Mostrar tipo de publicao e nome do artigo
resultado: tupla(tipo_pub:String, nome_art:String)
{resultado.tipo_pub = self.tipo_publ;
resultado.nome_art = self.nome;
display(resultado);
}

Mtodo Mostra_Documentos (cod_projeto:Integer) da classe Projeto

p:Projeto;
{ p=Busca_proj(cod_projeto); // recupera o projeto
Para cada d de p.documento faa
d.Mostra( ); // ativar o mtodo mostra no documento d
}

5. Eliminar um projeto de cdigo dado (sem eliminar pesquisador e documento)

Mtodo Elimina_proj(cod_proj:Integer):Boolean da classe Projeto
// sem eliminar um pesquisador e os documentos
p:Projeto;
{ p=Busca_proj(cod_proj);
// ou: selecione projeto p na classe Projeto onde p.cod_proj=cod_proj;
Se achou ento
{Retira p de Projeto
return(true)}
seno return(false)
}

6. Cadastrar um documento (pode ser relatrio tcnico ou artigo). Incluir esse

documento no projeto que o gerou ( fornecido como entrada o cdigo do projeto).
Mtodo Cadastra_RT (cod_doc:Integer, nome_doc:String, classific:String,
tpicos:String; inicio_val, fim_val:Date, cod_proj:Integer) da classe
Relatrio_Tcnico
rt:Relatorio_Tecnico;
proj:Projeto;
{ rt.codigo_doc=cod_doc;
rt.nome=nome_doc;
rt.classificacao=classific;
rt.topicos=topicos;
rt.inici_validade=inicio_val;
45

rt.fim_validade=fim_val;
Insira rt em Relatorio_Tecnico;
// Inserir o relatorio tecnico nos documentos do projeto dado
proj=Busca_proj(cod_proj);
Se projnulo ento
Insira rt em proj.documento;
}

4.4. Exerccios
1. Faa o mtodo Cadastra_Artigo.
Formule as consultas a seguir, com base no esquema da figura 3.6.
2. Recupere os documentos do projeto de nome Projeto A.
3. Supondo que os autores sejam modelados como uma lista de pesquisadores,
representando a ordem em que eles aparecem no artigo, formule a consulta:
a) Recupere o segundo autor do artigo cujo cdigo 520.
b) Recupere o nome do primeiro autor do artigo cujo cdigo 520
4.Recupere o nome dos coordenadores dos grupos que participam das tarefas que
iniciaram em 10/03/99.
5. Recupere o nome do coordenador de cada tarefa do projeto de nome Projeto A.
6. Recupere o nome do coordenador do grupo que participa de cada tarefa do projeto
de nome "Projeto A", bem como a descrio da respectiva tarefa.
Com base no esquema do Cadastro Imobilirio, expresse as consultas a seguir.
7. Recupere a localizao de cada imvel.
8. Recupere o bairro aonde est localizado o imvel de cdigo de inscrio 1000.

46

9. Recupere a composio do bairro aonde est localizado o imvel de cdigo de

inscrio 1000.
10. Para cada imvel, selecione a composio do bairro em que ele est situado.
11. Para cada imvel, selecione o cdigo das quadras que compem o bairro em que o
imvel est situado.
12. Recupere os imveis cuja rea construida maior que 200 m2.
13. Selecione o 70 segmento de quadra da rua de cdigo X.
14. Formule uma consulta qualquer envolvendo 2 classes ou mais, e expresse-a na
linguagem de consulta adotada.

47

5. Sistemas de Gerenciamento de Banco de Dados Orientados

a Objetos
Neste captulo resume-se as principais caractersticas dos SGBDs orientados a objetos
e apresenta-se alguns SGBDOOs existentes destacando, atravs de uma tabela, quais
dessas caractersticas cada um deles possui.
5.1. Caractersticas dos SGBDs Orientados a Objetos
Os SGBDOOs so SGBDs baseados nos conceitos de modelos de dados orientados a
objetos. Diferentemente dos SGBDs Relacionais que foram desenvolvidos para dar
suporte s necessidades das aplicaes comerciais tradicionais, os SGBDs orientados
a objetos foram desenvolvidos para satisfazer aos requisitos impostos por aplicaes
mais avanadas, ditas no convencionais. Essas aplicaes no convencionais
apresentam requisitos e caractersticas tais como:
-

necessidade de estruturas complexas para representar objetos;

necessidade de novos tipos de dados para armazenar informaes, tais

como imagens, voz e documentos textuais grandes;

requisitos de manipulao de dados no bem suportados pelos SGBDs

tradicionais.

Uma outra caracterstica importante de bancos de dados orientados a objetos a

possibilidade, que eles oferecem aos projetistas, de poder especificar a estrutura de
objetos complexos e as operaes que podem ser aplicadas a esses objetos.

Identificador de Objeto (OID): a implementao de identidade de objeto em

sistemas de bdoo envolve 3 tipos de independncia:

Independncia de local: a identidade do objeto preservada quando ocorre

mudanas de localizao fsica.
Independncia de valor: preservao da identidade independente do contedo.
Independncia de estrutura: preservao da identidade independente de mudanas
em sua estrutura.
48

Vantagens dos OIDs:

- facilidade para modelar a estrutura complexa dos objetos;
- propicia o compartilhamento de objetos;
- propagao de mudanas de valor de um objeto (atravs da referncia)
- suporte ao relacionamento entre os objetos
- favorece o gerenciamento de verses

Atributos e Mtodos Visveis/Invisveis : Alguns sistemas permitem o usurio

estabelecer quais atributos e mtodos so visveis (pblicos) na interface do objeto
e podem ser invocados por outros objetos. Aqueles que no so visveis so ditos
privados.

Instncias Excepcionais: O sistema O2 permite a criao de instncias de uma

classe com atributos e/ou mtodos adicionais queles especificados para a classe.

Objeto Composto: Alguns sistemas (por ex. ORION) permitem aplicaes

modelar um conjunto de objetos (ditos objetos componentes) como uma entidade
lgica. Isso significa que o sistema pode manipular esse conjunto de objetos como
uma unidade para bloqueio, autorizao e clustering fsico.

Gerenciamento de Verso:
O acesso a estados anteriores ou alternados de objetos uma parte inerente de
muitas aplicaes. Como exemplos de aplicaes que exigem acesso evoluo
de estados de objetos esto as aplicaes de projeto de engenharia por ex: desenho
auxiliado por computador e fabricao auxiliada por computador.
Nessas aplicaes, o mesmo objeto passa por muitas alteraes ou transies de
estado e desejvel acessar ou investigar estados prvios, ou verses, do objeto.
Por exemplo, considere os captulos dessa apostila. Cada captulo sofreu uma
evoluo. Para alguns captulos foram mantidas vrias verses, que diferiam em
organizao e contedo. Houve captulo em que a verso final foi uma integrao

49

de diversos componentes de verses anteriores. Foi muito til manter-se as

verses anteriores e utilizar partes delas nas verses seguintes.
O gerenciamento de verses em um banco de dados orientado a objetos consiste
em ferramentas e construes que automatizam ou simplificam a construo e a
organizao de verses ou configuraes. Sem essas ferramentas, caberia ao
usurio organizar e manter as verses. Uma maneira de fazer isso seria utilizar
uma conveno de nome que controlasse as vrias verses do mesmo objeto e a
relao entre as verses (rvore de derivao).Isso muito trabalhoso e propenso
a erro. Assim, em aplicaes de projeto complexas, o gerenciamento de verso
um utilitrio til e poderoso.
Em aplicaes de engenharia de projeto, os objetos de projeto so normalmente
armazenados em um repositrio central (persistente). Os projetistas fazem o
check-out do objeto persistente no banco de dados, trabalham nele e, quando
acharem que possuem a melhor implementao, fazem o check-in do objeto como
uma verso diferente.
Depois que um objeto versionado criado, a raiz de um conjunto de verses
contm todas as verses preexistentes de objetos. A principal propriedade comum
a todas as verses do mesmo objeto a identidade do objeto. Por toda a histria
versionada, um objeto pode passar por muitos estados e at por modificaes
estruturais.
Em suma, a verses servem para registrar os vrios estgios de um projeto, ou
para manter vrias alternativas corretas do projeto. Cada alternativa correta pode
estar associada a um conjunto de verses, correspondendo aos vrios estgio de
desenvolvimento daquela alternativa, para registrar a evoluo do projeto,
conforme ilustrado na figura 5.1. Nessa figura tem-se que v2 e v3 so alternativas
de v1; v4 e v5 so alternativas de v2. Com exceo da verso inicial e da final,
cada verso possui sucessores e predecessores.
Algumas linguagens orientadas a objeto que suportam versionamento fornecem
construes na linguagem para:
-

o check-out e o check-in deverses do objeto

a recuperao de sucessores ou predecessores de verses.

O1:
50

v1: verso original

v2

verses alternativas

v3
v5

v6

V4
v7: verso final
Figura 5.1.- Conjunto de verses de O1

Gerenciamento de Transaes
Tradicionalmente, uma transao uma seqncia de aes que l ou grava
objetos persistentes e satisfaz as propriedades ACID (atomicidade, consistncia,
isolamento e durabilidade). Resumindo, atomicidade significa que a transao ou
executada inteiramente ou no executada. Consistncia significa que as
transaes mapeiam um banco de dados persistente de um estado coerente para
outro. Isolamento significa que as transaes no lem resultados intermedirios
de outras transaes no-efetivas. Durabilidade significa que, uma vez que uma
transao efetivada, fica garantido que seus efeitos (i.., atualizaes) sero
suportados apesar das falhas.
Enquanto as transaes em aplicaes mais tradicionais so relativamente curtas,
recuperando e/ou atualizando poucos registros do banco de dados, as transaes
de aplicaes mais avanadas podem demorar horas e at mesmo dias.
Considere, por exemplo, a elaborao de um documento eletrnico em um
ambiente de escritrio. Suponha quase trata de um documento que descreve o
plano diretor de 5 anos do departamento. Em certo sentido, a transao que cria
esse documento e que pode envolver muitos funcionrios se completa quando o
documento concludo.
O documento passa por muitas fases intermedirias e sua preparao pode levar
dias. Esse tipo de transao apresenta alguns desafios e problemas relacionados s
estratgias de gerenciamento de transao mais tradicionais.

51

Diversos gerenciadores de banco de dados orientados a objetos oferecem algum

suporte para transaes de longa durao. Por exemplo, o Versant e o ITASCA,
suportam a noo de transaes de longa e de curta durao. A idia ter
transaes curtas aninhadas dentro de transaes demoradas. Quando o usurio
inicia uma transao de longa durao, ele pode fazer um check-out do objeto
complexo e seus subobjetos, do banco de dados concorrentemente compartilhado
e trabalhar nesses objetos em seu banco de dados pessoal. O usurio faz todas as
operaes nos objetos e quando elas se completarem ele pode fazer o check in
desses objetos.

Recuperao: um SGBD recupervel aquele que pode alcanar um estado

consistente aps uma falha. Recuperao em SGBDOO mais complexa
principalmente devido existncia de transaes de longa durao.

Gerenciamento de Dados Multimdia: Um SGBDOO que suporta dados

multimdia deve fornecer um sistema de armazenamento e recuperao de dados
mais eficiente.

5.2. Vantagens dos SGBDOOs

Possuem um poderoso modelo de dados.
Permitem representar a semntica do problema do mundo real de forma mais exata
do que atravs de um conjunto de tabelas planas.
Manipulam objetos complexos.
Objetos podem ser reusados em diferentes programas.
Herana de relacionamentos entre conjuntos de entidades.
Associam comportamento de objetos com definies de objeto ao nvel de
esquema.
Junes implcitas ao longo de hierarquias de agregaes, baseadas em identidade
de objetos.
Mecanismos de verses.
Melhor gerenciamento de transao e concorrncia.
52

 Linguagem de consulta mais expressiva.

Melhor suporte para trabalho cooperativo.

5.3. Alguns SGBDOOs Existentes

H vrios SGBDOOs em desenvolvimento por fabricantes, laboratrios de pesquisa,
universidades. Nos ltimos anos, muitos prottipos experimentais e SGBDOOs
comerciais tm se tornado disponveis. As tabelas 5.1 e 5.2 apresentam um resumo
das principais caractersticas de alguns SGBDOOs existentes. Esse levantamento foi
realizado em 1995. Desde ento houveram mudanas em alguns desses gerenciadores.
Por exemplo, o sistema O2, atualmente chamado de Ardent e comercializado pela
Ardent Software, permite o uso de C++ e Java para definio de esquemas e
desenvolvimento de aplicaes. O sistema ObjectStore permite integrao com a
linguagem Java.

53

54

55

6. Padres para SGBDOOs

O sucesso dos sistemas de banco de dados relacionais no resulta apenas de
um nvel mais alto de independncia de dados e um modelo de dados mais simples do
que os sistemas anteriores. Seu sucesso se deve tambm padronizao que sofreram.
A aceitao do padro SQL permite o alto grau de portabilidade e
interoperabilidade entre sistemas, simplifica o aprendizado de novos SGBDs
relacionais e representa um amplo endosso da abordagem relacional. Portabilidade
a capacidade de executar um programa de aplicao particular em diferentes sistemas
com modificaes mnimas no programa. Interoperabilidade se refere habilidade
de uma aplicao em acessar mltiplos sistemas distintos. Em termos de banco de
dados, isso significa que um mesmo programa de aplicao pode acessar alguns dados
armazenados segundo um certo SGBD e outros dados armazenados por um outro
SGBD.
Esses fatores so importantes tambm para SGBDs orientados a objetos. Na
indstria de software h vrios grupos trabalhando sobre padres que afetam os
SGBDOOs: o ODMG - Object Database Management Group (padres gerais para
SGBDOOs), o OMG - Object Management Group (padro CORBA Commom
Object Request Broker Architecture, que permite que uma ampla variedade de objetos
interaja em um ambiente distribudo), ANSI X3H2 (SQL padro), ANSI X3J16 (C++
padro), ANSI X3J20 (Smalltalk padro). Esses padres visam a portabilidade de
cdigo em alguma maneira.
Com relao a SGBD orientados a objetos, h trs padres: SQL-92, ODMG93 e SQL3. Os dois principais grupos que trabalham sobre padres para SGBD so o
ODMG e o ANSI X3H2.

6.1. SQL3
ANSI X3H2 um comit tcnico do American National Standards Institute
(ANSI), formado em 1978, para a definio de uma linguagem para bancos de dados
CODASYL ou redes. Em 1982, o modelo relacional estava adquirindo importncia, o
que levou o comit X3H2 a ser solicitado para desenvolver o padro SQL. A verso
corrente da SQL a SQL-92, que a culminao de trabalhos sobre vrias verses
anteriores. Ela baseada na SQL-89, que por sua vez foi baseada na SQL-86.
56

SQL-92 o padro para SGBDs Relacionais. SQL-92 no introduz conceitos

de objetos. O comit reconheceu a importncia de adio de objetos sua
especificao e tem trabalhado visando a definio da SQL3, que estende a SQL-92
para suportar objetos.
SQL3 mantm a compatibilidade com a SQL-92 (e verses anteriores do
padro), o que interfere na forma de seu suporte a objetos. Estes, no modelo de
objetos da SQL3, so armazenados em tipos especiais de colunas em relaes
particulares. Assim, objetos no so considerados primeira classe porque eles no
podem existir separadamente das relaes, o que afeta operaes tais como consultas.
No possvel acessar um objeto diretamente em SQL3; necessrio faz-lo atravs
da relao. Esse passo extra, de acesso a relao para poder recuperar o objeto, pode
afetar o desempenho da aplicao, conforme avaliado em (Barry 1996).
SQL3 difere do resto dos padres industriais de objeto. um sistema fechado,
definido somente em funo de suas antecessoras. Ela no usa nenhum dos padres do
OMG ou da comunidade de programao de objeto.

6.2. ODMG-93
ODMG (Object Database Management Group) um consrcio de vendedores
e grupos de interesse que trabalham na criao de padres para SGBDOOs. Ele foi
concebido em 1991 e a verso 1.0 da especificao do padro ODMG-93 (tambm
chamado ODMG 1.0) foi publicada em agosto de1993. Em 1995 o grupo terminou a
verso 1.2 do padro ODMG-93 e posteriormente foi revisado e chamado ODMG 2.0.
A linguagem de consulta a Objeto (OQL) do ODMG-93 baseada na poro
de consulta da SQL-92, porm com algumas variaes, pois a SQL-92 assume um
modelo relacional e a OQL assume um modelo de objeto.
A meta do ODMG tornar disponvel um conjunto de padres permitindo que
um cliente de SGBDOO escreva aplicaes portveis, isto , aplicaes que possam
ser executadas por diferentes SGBDOOs. Assim, os esquemas de dados, ligaes com
linguagens de programao; manipulao de dados e linguagens de consulta devem
ser portveis.
Segundo Cattell, em (Cattell 1996), as companhias que so membro do
ODMG (Cattell um dos membros do grupo), representando quase toda a indstria de
SGBDOO, esto suportando esse padro. A meta no a produo de SGBDOOs
57

idnticos, e sim, portabilidade de cdigo fonte. Haver diferenas entre produtos

relativas a desempenho, linguagens suportadas, funcionalidade nica para segmentos
particulares do mercado, ferramentas de construo de aplicaes, construtores de
interfaces de usurio grficas (GUI), entre outros.
O trabalho de padronizao, apresentado pelo grupo, derivado,
principalmente,

pela combinao das caractersticas mais fortes dos SGBDOOs

correntemente disponveis.
O grupo define um SGBDOO como sendo um SGBD que integra capacidades
de banco de dados com capacidades de linguagem de programao orientada a
objetos. Um SGBDOO faz com que objetos do banco de dados apresentem-se como
objetos de linguagem de programao, em uma ou mais linguagens existentes. Os
SGBDOOs tm sido integrados com C++, C, Smalltalk e LISP.
Os principais componentes do OGMG-93 so:
-

um Modelo de Objetos

uma Linguagem de Definio de Objetos (ODL)

uma Linguagem de Consulta a Objetos (OQL) declarativa (no procedural)

para consultar e atualizar objetos do banco de dados. Foi usado o padro SQL
como base, porm OQL suporta capacidades mais poderosas. O grupo espera que
SQL3 ir convergir com a OQL futuramente.

Ligao com a linguagem C++. Isso inclui uma verso da ODL que usa a sintaxe
de C++, um mecanismo para invocar OQL e procedimentos para operaes sobre
banco de dados e transaes.

Ligao com a linguagem Smalltalk e Java, com mesmos suportes acima para
C++.
Vrias das idias embutidas no modelo de objetos ODMG so baseadas em

duas dcadas de pesquisa em modelagem conceitual e bancos de dados orientados a

objetos realizadas por muitos pesquisadores.
Vrias companhias passaram a suportar esse padro em seus produtos a partir final
de1995.

7. Bibliografia
58

Barry, D.K. The Object Database Handbook. John Wiley & Sons, Inc. 1996.
Bertino, E.; Martino, L. (1993). Object-Oriented Database Systems: Concepts and
Architectures. Addison-Wesley, 1993.
Blaha, M.; Premerli, W. Object-Oriented Modeling and Design for Database
Applications. Prentice-Hall, 1998.
Cattel, R.G.G. Object-Oriented and Extended Relational Database Systems.
Addison-Wesley, 1994.
Cattell, R.G.G.; Barry, D.K. The Object Database Standard: ODMG-3.0. Morgan
Kaufmann Publishers, inc., 2000.
Elmasri, R.A.; Navathe, S.B. . Fundamentals of Database Systems. AddisonWesley, 2000 (third edition).
Hughes, J.G. Object-Oriented Databases. Prentice-Hall, 1991.
Khoshafian, S. Banco de Dados Orientado a Objeto. Livraria e Editora Infobook
S.A., 1994.
Vieira, M.T.P. (1991) Um modelo de Objetos para um Sistema de Gerncia de
Objetos em Ambiente de Desenvolvimento de Sistemas Interativos. Tese de
Doutorado, Departamento de Informtica, PUC-RJ, 1991.
Zand, M.; Collins, V.; Caviness, D. A Survey of Current Object-Oriented
Databases. In: DATA BASE Advances in Information Systems, Vol.26, No. 1,
February, 1995.

59