Académique Documents
Professionnel Documents
Culture Documents
DEPARTAMENTO DE COMPUTAÇÃO
Banco de Dados
Orientado a Objetos
Setembro 2001
Conteúdo
Conteúdo___________________________________________________________1
1. Conceitos Avançados sobre Modelagem de Dados ________________________3
1.1. Introdução _________________________________________________________ 3
1.2. Modelos de Dados ___________________________________________________ 5
1.2.1. Abstrações 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 Generalização _______________________________________________ 7
1.4. Exercícios _________________________________________________________ 10
2. Modelos de Dados Orientados a Objetos _______________________________12
2.1. Introdução ________________________________________________________ 12
2.2. Conceitos Básicos___________________________________________________ 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 Primárias _________________________________________________ 14
2.3.5. Objetos Complexos _____________________________________________________ 15
2.3.6. Encapsulamento ________________________________________________________ 15
2.3.7. Métodos ______________________________________________________________ 16
2.3.8. Tipos e Classes _________________________________________________________ 16
2.3.9. Herança_______________________________________________________________ 16
2.3.10. Polimorfismo _________________________________________________________ 19
3. Modelagem de Dados Orientada a Objetos _____________________________21
3.1. Motivação_________________________________________________________ 21
3.2. Desenvolvimento de Sistemas Orientados a Objetos ______________________ 21
3.3. Modelando Objetos _________________________________________________ 22
3.3.1. Definição de classe ______________________________________________________ 22
3.3.2. Herança_______________________________________________________________ 23
3.4. Representação gráfica_______________________________________________ 24
3.4.1. Representação de uma classe de objetos _____________________________________ 24
3.4.2. Representação de conjunto, lista e tupla______________________________________ 24
3.4.3. Herança simples ________________________________________________________ 25
3.4.4. Herança múltipla _______________________________________________________ 25
3.4.5. Definição recursiva______________________________________________________ 26
3.4.6. representação de referências inversas _______________________________________ 26
3.5. Geração do Esquema Lógico _________________________________________ 26
3.6. Exemplo: Banco de Dados para Gerenciamento de Projetos _______________ 28
3.7. Notação adotada X diagrama de classes UML ___________________________ 31
3.8. Exercícios _________________________________________________________ 37
2
1. Conceitos Avançados sobre Modelagem de Dados
1.1. Introdução
Bancos de dados são componentes importantes dos sistemas de informação
(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 não somente por profissionais da
área de banco de dados, mas também por não especialistas.
Freqüentemente, a falta de abordagens adequadas para o projeto de um banco
de dados pode incorrer em resultados indesejáveis, como ineficiência em atender a
demanda de aplicações e problemas com a manutenção do banco de dados.
Geralmente a causa disso é a falta de clareza em entender a natureza exata dos dados
em um nível conceitual (abstrato).
O projeto de um banco de dados é decomposto em Projeto Conceitual,
Projeto Lógico e Projeto Físico, conforme mostrado na figura 1.1.
Requisitos
de dados
Projeto
Conceitual
Esquema conceitual
Projeto
Lógico
Esquema Lógico
Projeto
Físico
Esquema Físico
Fig. 1.1
3
O Projeto Conceitual inicia a partir da especificação dos requisitos e resulta
no esquema conceitual do banco de dados. Um esquema conceitual é uma descrição
em alto nível 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 propósito do projeto conceitual é descrever o conteúdo de informação do
banco de dados ao invés das estruturas de armazenamento que serão necessárias para
gerenciar essa informação.
O Projeto Lógico inicia a partir do esquema conceitual e resulta no esquema
lógico. Um esquema lógico é uma descrição da estrutura do banco de dados que pode
ser processada por um SGBD. Um modelo lógico é usado para especificar esquemas
lógicos. Os modelos lógicos mais amplamente usados pertencem a três classes:
relacional, em redes e hierárquico. O projeto lógico depende da classe do modelo de
dados usado pelo SGBD, mas não do SGBD específico usado.
O Projeto Físico inicia a partir do esquema lógico e resulta no esquema físico.
Um esquema físico é uma descrição da implementação do banco de dados em
memória secundária; ele descreve as estruturas de armazenamento e métodos de
acesso usados para efetivamente realizar o acesso aos dados. O projeto físico é
direcionado para um SGBD específico. Decisões tomadas durante o projeto físico,
para melhorar o desempenho, podem afetar a estrutura do esquema lógico.
Uma vez que o projeto físico do banco de dados é completado, os esquemas
lógico e físico são expressos usando a linguagem de definição de dados do SGBD
adotado. O banco de dados é criado e populado e pode ser testado para se tornar
operacional.
O esquema físico do banco de dados é influenciado pelas fases por que passou
a construção do banco de dados. A fase de projeto conceitual é tida como uma das
mais (senão 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 elaboração do esquema conceitual. A meta nessa fase é obter um
esquema conceitual do banco de dados que seja tão completo e expressivo quanto
possível. Esse esquema deve procurar expressar o máximo da semântica envolvida na
informação. Mecanismos de representação de alto nível são empregados, tais como
4
representação de hierarquias de subconjunto e de generalização, representação de
restrições de cardinalidade e de atributos compostos e multivalorados.
O esquema conceitual deve permanecer como uma parte da documentação do
processo de projeto, sendo utilizado durante a operação e manutenção do banco de
dados, pois facilita o entendimento dos esquemas de dados e das aplicações que os
utilizam.
Para auxiliar o projetista a elaborar o projeto conceitual de um banco de
dados existem as abstrações de dados, que apresentam as vantagens:
• ajudam o projetista a entender, classificar e modelar a realidade,
• melhoram a eficiência de implementações subsequentes,
• permitem melhor representar a semântica das novas aplicações de banco de dados,
provenientes de áreas não tradicionais.
5
♦ Abstração de Classificação: é usada para alocar objetos similares, caracterizados
por propriedades comuns, em classes de objetos. A classificação estabelece um
relacionamento É-INSTANCIA-DE entre cada elemento da classe e a classe.
Ex: classe EMPREGADO - instancias : (João, Pedro, ..., José).
6
propostas, visando sua utilização para a modelagem de informações mais complexas.
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 generalização.
Rua
Cidade
Professor endereço
Estado
País
CEP
Fig. 1.2 - atributo composto
E1 E2 En
...
Fig. 1.3- Hierarquia de generalização
7
• Propriedades de Cobertura da generalização
A cobertura é parcial (p) se existe algum elemento da classe genérica que não
é mapeado para nenhum elemento das subclasses.
Exemplo: Suponha que VEÍCULO é uma classe cujos elementos são todos os
possíveis tipos de veículos. A generalização da figura 1.5 é parcial.
Pessoa
Veículo
8
Aluno
Aluno- Aluno-Pós-
Graduaçao Graduação
Veículo
(p,e)
Carro Bicicleta
• Hierarquia de Subconjunto
Uma entidade E1 é um subconjunto de outra entidade E2 se toda ocorrência de E1 for
também uma ocorrência de E2. É um caso particular da hierarquia de generalização.
Numa hierarquia de subconjunto o tipo de cobertura é (p,e) sempre, não sendo
necessária sua representação no esquema conceitual.
A figura 1.8 é um exemplo de hierarquia de subconjunto.
nro-cli
Cliente nome-cli
endereço
Cliente
Especial taxa-desconto
Observações:
1. O identificador da entidade genérica é também um identificador para as entidades
da especialização.
9
2. Entidades da especialização podem ter outros identificadores, como mostrado na
figura 1.9.
RG
Pessoa nome
título
divisão
situação- Empr Chefe Gerente Militar ident-na-
Homem Mulher
serv-mil divisão
Fig. 1.9
1.4. Exercícios
Jogador
Futebol Tênis
Fig. 1.10
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?
c. Dos demais funcionários que são operários, guarda-se suas habilidades (um
operário pode ter várias habilidades).
11
2. Modelos de Dados Orientados a Objetos
2.1. Introdução
A técnica da orientação a objetos está cada vez mais popular para projetar e
implementar sistemas de natureza variada. Com relação a bancos de dados, essa
técnica tem sido empregada, com predominância, nos casos aonde os dados
envolvidos na aplicação considerada apresentam estrutura complexa.
A diferença existente entre os modelos de dados tradicionais (relacional,
hierárquico e em redes) e os modelos de dados orientados a objetos está na maneira
como eles vêem os dados.
Os modelos de dados tradicionais vêem os dados como uma coleção de tipos
de registros ou relações, cada um tendo uma coleção de registros ou tuplas
armazenadas em um arquivo. Já num modelo de dados orientado a objetos um banco
de dados é considerado como uma coleção de objetos do mundo real.
Embora a informação sobre objetos complexos do mundo real possa ser
espalhada em tabelas relacionais, a meta dos bancos de dados orientados a objetos é
manter uma correspondência 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 número de tuplas, o que leva à necessidade de realizar um
considerável número de operações de junção para recuperar o objeto.
Os conceitos da orientação a objetos formam uma boa base para aplicações de
banco de dados mais avançadas, como por exemplo: aplicações de engenharia tais
como CAD/CAM (Computer Aided Design/Computer Aided Manufacturation),
CASE (Computer Aided Software Engineering), sistemas de informação geográfica,
sistemas de informação multimídia, sistemas de interface de usuário avançadas, etc.
Essas aplicações tem requisitos e características que diferem das aplicações
comerciais tradicionais, tais como estruturas de dados mais complexas, transações de
duração mais longa, novos tipos de dados para armazenar imagens ou textos longos e
a necessidade de definição de operações não padrões específicas da aplicação. Os
bancos de dados orientados a objetos foram propostos para dar suporte às
necessidades dessas aplicações mais complexas.
12
Os modelos de dados orientados a objetos usam os conceitos de abstração de
dados dos modelos semânticos (classificação, generalização e agregação) e
incorporam outros conceitos.
13
pode mudar após a reorganização do banco de dados. Entretanto, alguns sistemas
usam o endereço físico como OID, para aumentar a eficiência de recuperação do
objeto. Nesse caso, se o endereço físico do objeto muda, pode ser colocado um
ponteiro indireto no primeiro endereço, indicando a nova localização física do mesmo.
É mais comum usar inteiros longos como OIDs e uma função hash para mapear o
valor do OID para o endereço físico do objeto.
2.2.2. Valores
A maioria dos SGBDOOs representam as entidades primitivas, tais como inteiros ou
caracteres, por valores (não possuem OIDs), enquanto as entidades não primitivas são
representadas como objetos. Já outros sistemas, como o O2, permitem a definição de
valores complexos que não podem ser compartilhados por outros objetos, uma vez
que valores não possuem OIDs.
14
- obtém-se melhor desempenho, pois os OIDs são implementados em baixo nível pelo
sistema;
- embora as chaves sejam mais significativas ao usuário, muitas vezes o usuário
precisa usar códigos artificiais, sem significado semântico, para poder identificar as
tuplas de uma relação.
2.3.6. Encapsulamento
A cada objeto está associada sua estrutura e seu comportamento (os métodos ou
operações). O comportamento é armazenado no banco de dados junto com a estrutura
do objeto.
O conceito real de encapsulamento determina que somente as operações sobre os
objetos são visíveis e sua estrutura é escondida. Em banco de dados a noção de
invisibilidade da estrutura do objeto é afrouxada. É desejável, por exemplo, poder
consultar os atributos do objeto através de uma linguagem de consulta. Assim, a
maioria dos SGBDOOs permitem acesso direto aos atributos fornecendo operações
definidas pelo sistema para a leitura e modificação dos atributos, o que livra o usuário
da incumbência de implementar uma considerável quantidade de métodos cujo único
propósito é ler e escrever os valores dos vários atributos dos objetos. Isso é um
exemplo de violação do encapsulamento permitida pelos SGBDOOs. Esses sistemas,
porém, possuem mecanismos para que o usuário possa proteger o acesso aos atributos
dos objetos, caso desejável. O sistema O2, por exemplo, permite o usuário estabelecer
quais atributos e métodos são visíveis na interface do usuário, através da declaração
public, o que permite serem invocados por qualquer outro objeto. Os não visíveis são
referidos como private.
15
2.3.7. Métodos
Os objetos nos SGBDOOs são manipulados através de métodos. Em geral, a definição
de um método consiste de assinatura e corpo. A assinatura especifica o nome do
método, os nomes e classes dos argumentos e a classe do resultado, se existir. O corpo
representa a implementação do método e consiste de um conjunto de instruções
expressas em uma dada linguagem de programação.
2.3.9. Herança
É um mecanismo de reusabilidade muito poderoso. Com herança, uma classe chamada
uma subclasse pode ser definida com base na definição de outra classe chamada a
superclasse. A subclasse herda os atributos, métodos e mensagens de sua superclasse
e pode ter atributos específicos, métodos e mensagens adicionais.
16
Caminhão
Ônibus
nro-placa:STRING
nro-placa:STRING
modelo:STRING
modelo:STRING
licença:NUMBER
lugares:NUMBER
data_última_revisão:DATE
data_última_revisão:DATE
valor_estimado:NUMBER
próxima_revisão:DATE
próxima_revisão:DATE
Fig.2.1
Veículo
nro-placa:STRING
modelo:STRING
data_última_revisão:DATE
próxima_revisão:DATE
Caminhão Ônibus
licença:NUMBER lugares:NUMBER
valor_estimado:NUMBER
Em certos sistemas, uma classe pode ter várias superclasses, em cujo caso diz-se que
ocorre herança múltipla (fig.2.3), enquanto outros impõem a restrição de uma única
superclasse, dita herança simples.
17
Veículo
Veículo_Passageiro
nro-placa:STRING
modelo:STRING rota: STRING
data_última_revisão:DATE preço:NUMBER
horário_saída:NUMBER
próxima_revisão:DATE
Caminhão Ônibus
licença:NUMBER lugares:NUMBER
valor_estimado:NUMBER
A herança múltipla pode provocar problemas de conflitos, como por exemplo, duas ou
mais superclasses podem ter um atributo com o mesmo nome, mas com diferentes
domínios. Esses conflitos precisam ser tratados pelo sistema. Se existe uma relação de
inclusão entre os domínios, então o domínio mais específico será escolhido como o
domínio para a subclasse. Por exemplo, se na classe Veículo existir o atributo
combustível cujo domínio é: (gasolina, álcool, diesel) e em Veículo_Passageiro
existir também o atributo combustível cujo domínio é (diesel), a classe Ônibus
herdará o atributo combustível cujo domínio será (diesel) (figura 2.4), isto é, o
domínio mais restrito. Se essa relação não existe, uma solução adotada é a escolha do
domínio com base na ordem de precedência entre as superclasses. Outros sistemas
deixam por conta do usuário a resolução do conflito.
18
Veículo
Veículo_Passageiro
nro-placa:STRING
modelo:STRING rota: STRING
data_última_revisão:DATE preço:NUMBER
combustível:(gasolina, álcool,diesel) horário_saída:NUMBER
combustível:(diesel)
próxima_revisão:DATE
Ônibus
lugares:NUMBER
combustível:(diesel)
2.3.10. Polimorfismo
Os SGBDOOs oferecem o recurso de polimorfismo de operações, também conhecido
como sobrecarga de operador (overloading). Outros conceitos relacionados com o
polimorfismo são os de late binding (ligação tardia) e overriding (redefinição de
operação).
Para melhor expor esses conceitos, considere uma operação 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, endereço, etc);
- um gráfico: deseja-se apresentar uma representação gráfica.
Usando um sistema convencional, seriam necessárias 3 operaçoes: display_pessoa,
display_figura e display_gráfico, como mostrado a seguir:
for x in X do
begin
case of type(x)
pessoa: display_pessoa(x);
figura: display_figura(x);
gráfico: display_gráfico(x);
end;
end;
19
Em um sistema orientado a objetos, a operação display pode ser definida em uma
classe mais geral. A operação tem um único nome e pode ser chamada
indiscriminadamente por vários objetos. A implementação da operação é redefinida
para cada uma das subclasses. Essa redefinição é chamada overriding. O sistema
decide qual implementacão usar para execução. Assim, o código dado é simplificado
para:
for x in X do display(x)
20
3. Modelagem de Dados Orientada a Objetos
3.1. Motivação
1. Projeto conceitual:
Essa fase visa o projeto de um esquema conceitual que apresente uma abstração do
problema do mundo real. Uma diferença quando se trata de projeto conceitual do
banco de dados orientado a objetos é que, além da definição da estrutura dos objetos,
também são definidos os métodos que manipulam esses objetos. Assim, toda a
funcionalidade do sistema é definida juntamente com a estrutura dos objetos.
21
♦ Desenvolvimento de sistemas tradicionais:
O desenvolvimento de sistemas de informação 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 análise relacional, a geração do esquema
lógico e a implementação física do bd.
Sob a perspectiva dos processos, o desenvolvimento do sistema trata os
requisitos funcionais do sistema envolvendo a construção de DFDs (diagramas de
fluxos de dados), especificação das funções do sistema e dos módulos de programa.
22
class Conta_Corrente
properties
nro_conta: Integer;
proprietário: 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. Herança
Para especificar a hierarquia de classe e subclasse será utilizada a declaração
inherits. No exemplo a seguir tem-se que a classe Carro herda todas as propriedades e
operações da classe Veículo.
class Veículo
properties
nro_reg, marca, modelo: String;
cor: String;
milhas: Integer;
tipo_combustível: (álcool, gasolina, dísel);
ano: Integer;
operations
...
end Veículo.
class Carro
inherits Veículo
properties
tipo_combustível: (álcool, gasolina); {redefinido}
{propriedades adicionais de carro}
tamanho: (compacto, médio, grande);
extras: set(String);
end Carro.
23
3.4. Representação gráfica
A seguir será apresentada uma notação gráfica para representação conceitual
de objetos, que tem como objetivo oferecer uma forma simplificada para a modelagem
de um banco de dados orientado a objetos. Várias notações existem na literatura, entre
elas a UML, que podem ser adotadas para essa fase do projeto do banco de dados o.o.
A adoção dessa notação visa simplicidade e utilização dos recursos dos construtores
tuple, list e set, que são bastante expressivos para uma variedade de aplicações de
bdoo.
Conjunto (SET):
Tupla (TUPLE):
Lista (LIST):
Exemplo:
nome-rua
nome rua
endereço bairro número
Pessoa telefone
filhos nome
Dependente sexo
datanasc
Fig. 3.1
Na figura 3.1 está representado que uma pessoa pode ter vários telefones,
sendo que os mesmos devem ser armazenados segundo uma ordem. Essa ordem é
definida de acordo com a semântica da aplicação; por exemplo, a lista de telefones
pode estar representando a ordem de preferência a ser usado para se entrar em contato
24
com a pessoa. Cada pessoa pode possuir vários filhos, que estão representados por
um conjunto de objetos do tipo Dependente.
ATENÇÃO:
Quando um atributo possui tipo simples e envolve o construtor SET ou LIST, a
nome nome
endereço endereço
Pessoa telefone Pessoa telefone
Cliente nro-cliente
ender-comercial
Cliente- renda Cliente- nro-cliente
Casual limite- Frequente débito
cred
Fig. 3.2 a e b - Herança Simples
nome*
nome Cliente nro-carteira-trab
endereço Funcionário endereço*
cpf salário
25
3.4.5. Definição recursiva
nome
Pessoa endereço
filhos
empregs • proj
Projeto Empregado
class nome_da_classe
inherits nome_superclasse1, . . ., nome_superclassej
properties
nome_atrib1: tipo;
nome_atrib2: tipo;
...
nome_atribj: tipo;
operations
nome_método(parâmetros); ... ;
end nome_da_classe
Por convenção, nos esquemas conceitual e lógico, os nomes dos atributos são escritos
com letras minúsculas e os nomes das classes iniciam com letra maiúscula.
class Dependente
properties
nome: String;
sexo: String;
data_nasc: Date;
end Dependente
27
class Empregado
properties
proj: Projeto inverse is Projeto.empregs;
end Empregado;
Suponha que deseja-se manter um banco de dados com informações sobre os projetos
desenvolvidos pelos grupos de pesquisa de uma instituição. As informações a serem
armazenadas referem-se aquelas sobre projetos, especificando as tarefas que compõem
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:
- Para cada projeto há vários documentos produzidos, que podem ser artigos
publicados em jornais ou conferências ( cujos autores são pesquisadores que
atuam no projeto), ou relatórios técnicos internos do projeto.
28
- Associar_membro, para a classe Grupo, que insere um novo pesquisador num
determinado grupo de pesquisadores.
A figura 3.6 mostra o esquema conceitual do banco de dados o.o. desse exemplo,
usando a notação dada. Para permitir uma comparação com a UML, uma versão desse
esquema, usando sua notação, é também fornecida na figura 3.10.
29
nome_ proj Documento código_doc
objetivo
Projeto nome
documento analisar_doc(classif:String) classificação
plano_trabalho
sub_projeto
Grupo nome_grupo
membro
associar_membro() coordenador
30
3.7. Notação adotada X diagrama de classes UML
31
que as multiplicidades, são colocados nos lados opostos quando comparados ao
diagrama EER.
Em UML há dois tipos de relacionamentos: associação e agregação. Uma
agregação representa um relacionamento entre um objeto e suas partes componentes.
Na figura 3.8 as localizações de um departamento e a localização de um projeto foram
modelados como agregações. Associações e agregações não possuem propriedades
estruturais diferentes, elas diferem apenas no significado semântico. No modelo EER,
ambas são representadas como relacionamentos. Associações ou agregações
unidirecionais, em UML, são mostradas com uma seta para indicar que somente é
necessária uma direção para acessar os objetos. Instancias de relacionamento podem
ser especificadas como sendo ordenadas.
prim_nome
nome
sobrenome nro-empregados
nroE sexo nroD
endereço nome localização (1,n)
salário
Trabalha (4,n)
data nasc (1,1)
Empregado Departamento
data-início (1,1)
(0,1) (0,n)
Gerência
(0,n)
(0,1) (1,n)
Supervisiona é super- horas
visionado Controla
Atua
Supervisiona
(1,n) (1,1)
(0,n)
Projeto
Possui
nome
Dependente sexo
Data_nasc
grau-parentesco
32
Empregado Departamento
4..* Trabalha 1..1 nroD
nroE nome
nome
prim_nome 1..1 0..1
sobrenome Adiciona-empr 0..*
sexo: { M,F} Nro-empregados
endereço Gerência Muda-gerente
salário ...
data_nasc: Date Data_Inicio 1..1 1..*
1..* controla Localização
Nome
idade Atua
muda-depto é supervisionado 1..* * 1..1
... Horas
* Projeto
Sexo: {M,F}
Data nasc: Date
Grau-parentesco
...
33
A notação UML para generalização/especialização é mostrada na figura 3.9. O
triângulo vazio indica cobertura exclusiva e o triângulo cheio indica cobertura de
sobreposição.
Pessoa
nro
nome
endereço
RG
Empregado Cliente
tipo cliente
Salário porcent-desconto
34
prim_nome
nome
sobrenome
nroE sexo endereço salário
data_nasc
Departamento nroD
Empregado depto-trab • emprs
supervisor projs
depends horas
atua
Projeto
Dependente emps
proj adiciona-empr
...
adiciona-proj
35
Documento
codigo_doc : int
+compõe nome : string
0..1 gera classificação : string
Projeto
nome_proj : string 0..*
1 analisar_documento()
objetivo : string
0..*
+é_composto 1
possui
Relatório_Técnico Artigo
1..* tópicos : string tipo_publ : string
Tarefa início_validade : date local_publ : string
+é_precedida fim_validade : date data : date
data_inicio : date
0..* data_fim : date
descrição_tarefa : string 0..*
anos_homem : float
0..* 0..* escreve
+precede calcular_esforço()
1..* coordena 1..*
participa 1 Pesquisador
1
é membro nome : string
Grupo 1..* 1..* especialização : string
nome_grupo : string salário : float
bônus_produção : float
associar_membro() 1
0..1 coordena calcular_bônus()
Legenda
Class Multiplicity
ClassName
0 zero
attributes
1 one
operations() 0..1 zero or one
0..* zero or more
Agregation
1..* one or more
* n
Association
36
3.8. Exercícios
37
4. Deseja-se desenvolver um banco de dados que armazene informações sobre um
acervo de CDs e Livro. O banco de dados deve conter informações sobre os CDs,
como a nacionalidade, o tipo de CD, se musical ou multimídia, não permitindo para
um mesmo CD, ser de ambos os tipos. Se for CD de música, as informações
consistem no nome do CD, cantores e compositores, gênero, número de músicas e
tempo total gravado; caso seja multimídia, o tipo de software e a empresa responsável.
Para os Livros deseja-se informações como nome, autores, editora, gênero, edição e
encadernação. A base de dados também armazena informações sobre empréstimo de
CDs e Livros a pessoas físicas, armazenando o nome da pessoa, telefone, e-mail e a
data de empréstimo, permitindo assim, o controle do acervo.
Suponha que as seguintes atividades devem ser realizadas:
b) Dado o nome de uma Pessoa Física, mostrar seu telefone e o nome dos CDs que
ela emprestou.
38
4. Manipulando Objetos
Encontre todos os nomes de projetos que têm 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
utilização de dois predicados de junção :
39
Nas linguagens de consulta orientadas a objetos são utilizadas expressões de caminho
de modo que as junções sejam formuladas de forma mais direta, sendo referidas como
junções implícitas. Isso ocorre devido à forma em que os objetos são estruturados
envolvendo hierarquias de agregação, conforme mostrado na figura 4.1. Nessa figura,
o atributo de uma classe C1 tem como domínio uma classe C2 estabelecendo um
relacionamento de agregação entre as duas classes. C2, por sua vez, é definido em
termos da classe C3. Diz-se então que essas classes estão organizadas no esquema
através de uma hierarquia de agregação.
• Referências Simples
Com base na figura 4.1, a consulta:
40
“selecionar o valor do atributo atrib_c3 de um objeto x pertencente à classe
C1, que satisfaz uma certa condição”
pode ser expressa como:
Select t.coordenador.nome
From t in Tarefa
Where t.data_início = '01/02/1999'
• Referências 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 condição”.
Como existe uma referência multivalorada de C1 para C2, é necessário percorrer
cada elemento do atributo atrib_c1 para recuperar o valor correspondente de
atrib_c2 desse elemento.
C1 atrib_c1 C2 atrib_c2
Select y.atrib_c2
From x in C1
y in x.atrib_c1
Where condição de seleção
41
Exemplo: Na figura 3.6: Selecione o código e a classificação dos documentos
do Projeto "Projeto A".
Select a.nome
From a in Artigo
Where a.data = "20/05/1999"
42
cod_proj
objetivo Documento
código_doc
Projeto documento nome
Mostra
coordenador classificação
Busca_Proj
nome_proj
Cadastra_Projeto
Mostra_Documentos
Elimina_Proj
Pesquisador nome
especialização
salário
Busca_Pesq
Cadastra_Pesq bônus_produção
Alguns dos métodos definidos nas classes da figura 4.3 são dados a seguir, usando
uma linguagem algorítmica.
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.
{ Select proj
From proj in Projeto
Where proj.cod_proj=codigo_proj;
return(proj);
}
{resultado.inicio_val = self.inicio_validade;
resultado.fim_val = self.fim_validade;
resultado.nome_rel = self.nome;
display(resultado);
}
44
Método Mostra( ) da classe Artigo
//Mostrar tipo de publicação e nome do artigo
{resultado.tipo_pub = self.tipo_publ;
resultado.nome_art = self.nome;
display(resultado);
}
p:Projeto;
{ p=Busca_proj(cod_projeto); // recupera o projeto
Para cada d de p.documento faça
d.Mostra( ); // ativar o método mostra no documento d
}
rt:Relatorio_Tecnico;
proj:Projeto;
{ rt.codigo_doc=cod_doc;
rt.nome=nome_doc;
rt.classificacao=classific;
rt.topicos=topicos;
45
rt.inici_validade=inicio_val;
rt.fim_validade=fim_val;
Insira rt em Relatorio_Tecnico;
4.4. Exercícios
1. Faça o método Cadastra_Artigo.
4.Recupere o nome dos coordenadores dos grupos que participam das tarefas que
iniciaram em 10/03/99.
46
9. Recupere a composição do bairro aonde está localizado o imóvel de código de
inscrição 1000.
10. Para cada imóvel, selecione a composição do bairro em que ele está situado.
11. Para cada imóvel, selecione o código das quadras que compõem o bairro em que o
imóvel está situado.
12. Recupere os imóveis cuja área construida é maior que 200 m2.
47
5. Sistemas de Gerenciamento de Banco de Dados Orientados
a Objetos
48
Independência de estrutura: preservação da identidade independente de mudanças
em sua estrutura.
• Gerenciamento de Versão:
O acesso a estados anteriores ou alternados de objetos é uma parte inerente de
muitas aplicações. Como exemplos de aplicações que exigem acesso à evolução
de estados de objetos estão as aplicações de projeto de engenharia por ex: desenho
auxiliado por computador e fabricação auxiliada por computador.
Nessas aplicações, o mesmo objeto passa por muitas alterações ou transições de
estado e é desejável acessar ou investigar estados prévios, ou versões, do objeto.
Por exemplo, considere os capítulos dessa apostila. Cada capítulo sofreu uma
49
evolução. Para alguns capítulos foram mantidas várias versões, que diferiam em
organização e conteúdo. Houve capítulo em que a versão final foi uma integração
de diversos componentes de versões anteriores. Foi muito útil manter-se as
versões anteriores e utilizar partes delas nas versões seguintes.
O gerenciamento de versões em um banco de dados orientado a objetos 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. Uma maneira de fazer isso seria utilizar
uma convenção de nome que controlasse as várias versões do mesmo objeto e a
relação entre as versões (árvore de derivação).Isso é muito trabalhoso e propenso a
erro. Assim, em aplicações de projeto complexas, o gerenciamento de versão é um
utilitário útil e poderoso.
Em aplicações de engenharia de projeto, os objetos de projeto são normalmente
armazenados em um repositório central (persistente). Os projetistas fazem o
check-out do objeto persistente no banco de dados, trabalham nele e, quando
acharem que possuem a melhor implementação, fazem o check-in do objeto como
uma versão diferente.
Depois que um objeto versionado é criado, a raiz de um conjunto de versões
contém todas as versões preexistentes de objetos. A principal propriedade comum
a todas as versões do mesmo objeto é a identidade do objeto. Por toda a história
versionada, um objeto pode passar por muitos estados e até por modificações
estruturais.
Em suma, a versões servem para registrar os vários estágios de um projeto, ou
para manter várias alternativas corretas do projeto. Cada alternativa correta pode
estar associada a um conjunto de versões, correspondendo aos vários estágio de
desenvolvimento daquela alternativa, para registrar a evolução do projeto,
conforme ilustrado na figura 5.1. Nessa figura tem-se que v2 e v3 são alternativas
de v1; v4 e v5 são alternativas de v2. Com exceção da versão inicial e da final,
cada versão possui sucessores e predecessores.
Algumas linguagens orientadas a objeto que suportam versionamento fornecem
construções na linguagem para:
- o check-out e o check-in deversões do objeto
50
- a recuperação de sucessores ou predecessores de versões.
O1:
v1: versão original
v2
v3 versões alternativas
v5
v6
V4
• Gerenciamento de Transações
Tradicionalmente, uma transação é uma seqüência de ações que lê ou grava
objetos persistentes e satisfaz as propriedades ACID (atomicidade, consistência,
isolamento e durabilidade). Resumindo, atomicidade significa que a transação ou
é executada inteiramente ou não é executada. Consistência significa que as
transações mapeiam um banco de dados persistente de um estado coerente para
outro. Isolamento significa que as transações não lêem resultados intermediários
de outras transações não-efetivas. Durabilidade significa que, uma vez que uma
transação é efetivada, fica garantido que seus efeitos (i.é., atualizações) serão
suportados apesar das falhas.
Enquanto as transações em aplicações mais tradicionais são relativamente curtas,
recuperando e/ou atualizando poucos registros do banco de dados, as transações
de aplicações mais avançadas podem demorar horas e até mesmo dias.
Considere, por exemplo, a elaboração de um documento eletrônico em um
ambiente de escritório. Suponha quase trata de um documento que descreve o
plano diretor de 5 anos do departamento. Em certo sentido, a “transação” que cria
esse documento e que pode envolver muitos funcionários se completa quando o
documento é concluído.
51
O documento passa por muitas fases intermediárias e sua preparação pode levar
dias. Esse tipo de transação apresenta alguns desafios e problemas relacionados às
estratégias de gerenciamento de transação mais tradicionais.
Diversos gerenciadores de banco de dados orientados a objetos oferecem algum
suporte para transações de longa duração. Por exemplo, o Versant e o ITASCA,
suportam a noção de transações de longa e de curta duração. A idéia é ter
transações curtas aninhadas dentro de transações demoradas. Quando o usuário
inicia uma transação de longa duração, 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 usuário faz todas as
operações nos objetos e quando elas se completarem ele pode fazer o check –in
desses objetos.
52
∗ Junções implícitas ao longo de hierarquias de agregações, baseadas em identidade
de objetos.
∗ Mecanismos de versões.
∗ Melhor gerenciamento de transação e concorrência.
∗ Linguagem de consulta mais expressiva.
∗ Melhor suporte para trabalho cooperativo.
53
54
55
6. Padrões para SGBDOOs
6.1. SQL3
ANSI X3H2 é um comitê técnico do American National Standards Institute
(ANSI), formado em 1978, para a definição de uma linguagem para bancos de dados
CODASYL ou redes. Em 1982, o modelo relacional estava adquirindo importância, o
que levou o comitê X3H2 a ser solicitado para desenvolver o padrão SQL. A versão
56
corrente da SQL é a SQL-92, que é a culminação de trabalhos sobre várias versões
anteriores. Ela é baseada na SQL-89, que por sua vez foi baseada na SQL-86.
SQL-92 é o padrão para SGBDs Relacionais. SQL-92 não introduz conceitos
de objetos. O comitê reconheceu a importância de adição de objetos à sua
especificação e tem trabalhado visando a definição da SQL3, que estende a SQL-92
para suportar objetos.
SQL3 mantém a compatibilidade com a SQL-92 (e versões anteriores do
padrão), o que interfere na forma de seu suporte a objetos. Estes, no modelo de
objetos da SQL3, são armazenados em tipos especiais de colunas em relações
particulares. Assim, objetos não são considerados “primeira classe” porque eles não
podem existir separadamente das relações, o que afeta operações tais como consultas.
Não é possível acessar um objeto diretamente em SQL3; é necessário fazê-lo através
da relação. Esse passo extra, de acesso a relação para poder recuperar o objeto, pode
afetar o desempenho da aplicação, conforme avaliado em (Barry 1996).
SQL3 difere do resto dos padrões industriais de objeto. É um sistema fechado,
definido somente em função de suas antecessoras. Ela não usa nenhum dos padrões do
OMG ou da comunidade de programação de objeto.
6.2. ODMG-93
ODMG (Object Database Management Group) é um consórcio de vendedores
e grupos de interesse que trabalham na criação de padrões para SGBDOOs. Ele foi
concebido em 1991 e a versão 1.0 da especificação do padrão ODMG-93 (também
chamado ODMG 1.0) foi publicada em agosto de1993. Em 1995 o grupo terminou a
versão 1.2 do padrão ODMG-93 e posteriormente foi revisado e chamado ODMG 2.0.
A linguagem de consulta a Objeto (OQL) do ODMG-93 é baseada na porção
de consulta da SQL-92, porém com algumas variações, pois a SQL-92 assume um
modelo relacional e a OQL assume um modelo de objeto.
A meta do ODMG é tornar disponível um conjunto de padrões permitindo que
um cliente de SGBDOO escreva aplicações portáveis, isto é, aplicações que possam
ser executadas por diferentes SGBDOOs. Assim, os esquemas de dados, ligações com
linguagens de programação; manipulação de dados e linguagens de consulta devem
ser portáveis.
57
Segundo Cattell, em (Cattell 1996), as companhias que são membro do
ODMG (Cattell é um dos membros do grupo), representando quase toda a indústria de
SGBDOO, estão suportando esse padrão. A meta não é a produção de SGBDOOs
idênticos, e sim, portabilidade de código fonte. Haverá diferenças entre produtos
relativas a desempenho, linguagens suportadas, funcionalidade única para segmentos
particulares do mercado, ferramentas de construção de aplicações, construtores de
interfaces de usuário gráficas (GUI), entre outros.
O trabalho de padronização, apresentado pelo grupo, é derivado,
principalmente, pela combinação das características mais fortes dos SGBDOOs
correntemente disponíveis.
O grupo define um SGBDOO como sendo um SGBD que integra capacidades
de banco de dados com capacidades de linguagem de programação orientada a
objetos. Um SGBDOO faz com que objetos do banco de dados apresentem-se como
objetos de linguagem de programação, em uma ou mais linguagens existentes. Os
SGBDOOs têm sido integrados com C++, C, Smalltalk e LISP.
Os principais componentes do OGMG-93 são:
- um Modelo de Objetos
- uma Linguagem de Definição de Objetos (ODL)
- uma Linguagem de Consulta a Objetos (OQL) declarativa (não procedural) para
consultar e atualizar objetos do banco de dados. Foi usado o padrão SQL como
base, porém OQL suporta capacidades mais poderosas. O grupo espera que SQL3
irá convergir com a OQL futuramente.
- Ligação com a linguagem C++. Isso inclui uma versão da ODL que usa a sintaxe
de C++, um mecanismo para invocar OQL e procedimentos para operações sobre
banco de dados e transações.
- Ligação com a linguagem Smalltalk e Java, com mesmos suportes acima para
C++.
Várias das idéias embutidas no modelo de objetos ODMG são baseadas em
duas décadas de pesquisa em modelagem conceitual e bancos de dados orientados a
objetos realizadas por muitos pesquisadores.
Várias companhias passaram a suportar esse padrão em seus produtos a partir final
de1995.
58
7. Bibliografia
Barry, D.K. The Object Database Handbook. John Wiley & Sons, Inc. 1996.
Cattell, R.G.G. The Object Database Standard: ODMG-93 - Release 1.2, Morgan
Kaufmann Publishers, inc., 1996.
59