Banco de Dados Orientado a Objetos

UNIVERSIDADE FEDERAL DE SÃO CARLOS
DEPARTAMENTO DE COMPUTAÇÃO
Banco de Dados
Orientado a Objetos
Marina Teresa Pires Vieira
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
4. Manipulando Objetos ______________________________________________39
1
4.1. Características de Linguagens de Consulta OO (LCOO) __________________ 39
4.1.1. Hierarquias de Agregação ________________________________________________ 39
4.1.2. Hierarquia de Herança ___________________________________________________ 40
4.2. Consultando Objetos________________________________________________ 40
4.2.1. Hierarquias de Agregação ________________________________________________ 40
4.2.2. Hierarquia de Herança ___________________________________________________ 42
4.3. Definição de Métodos _______________________________________________ 42
4.4. Exercícios _________________________________________________________ 46
5. Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos _______48
5.1. Características dos SGBDs Orientados a Objetos ________________________ 48
5.2. Vantagens dos SGBDOOs ___________________________________________ 52
5.3. Alguns SGBDOOs Existentes ________________________________________ 53
6. Padrões para SGBDOOs ___________________________________________56
6.1. SQL3 ____________________________________________________________ 56
6.2. ODMG-93_________________________________________________________ 57
7. Bibliografia______________________________________________________59
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.
1.2. Modelos de Dados
Modelos de dados são veículos para descrever a realidade. Um modelo de
dados é uma coleção de conceitos que podem ser usados para descrever um conjunto
de dados e operações 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 são ferramentas para representar a realidade em alto nível
de abstração;
• Modelos lógicos, que suportam descrições de dados que podem ser processados por
um computador (ex: modelos relacional, hierárquico, em redes). Esses modelos são
facilmente mapeados para a estrutura física do banco de dados .
1.2.1. Abstrações no Projeto Conceitual de Banco de Dados
Para auxiliar o projetista na tarefa de modelar os dados, existem os
mecanismos de abstração de dados que permitem melhor representar a semântica da
informação envolvida na aplicação. As abstrações comumente usadas no projeto
conceitual são: classificação, agregação e generalização.
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é).
♦ Abstração de Agregação: é um conceito de abstração para construir objetos
compostos a partir de seus objetos componentes. Essa abstração estabelece um
relacionamento É-PARTE-DE entre os componentes e a classe.
Ex:
-
Uma entidade é uma agregação de atributos: PESSOA, composta por Nome,
Sexo, Profissão;
-
Um relacionamento é uma agregação de entidades e atributos;
-
Um atributo composto é uma agregação de atributos;
-
Pode-se agregar entidades relacionadas entre si, compondo uma entidade de
nível mais alto.
♦ Abstração de Generalização: define um relacionamento de subconjunto entre os
elementos de duas ou mais classes. Essa abstração estabelece um relacionamento
É-UM entre a classe pai (chamada superclasse) e cada classe filha (subclasse).
Ex: classes CARRO e BICICLETA são subconjuntos da classe VEÍCULO.
As subclasses são definidas com base em alguma característica da superclasse. No
exemplo dado, essa característica é tipo de veículo (Carro, Bicicleta).
Propriedade Fundamental da Generalização: Todas as abstrações definidas para a
classe genérica são herdadas por todas as classes que são subconjunto.
1.3. Modelo EER (Extended Entity-Relationship)
Devido à popularidade e ampla utilização do modelo Entidade-Relacionamento (ER)
para o projeto conceitual de bancos de dados, várias extensões desse modelo foram
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.
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 endereço na figura 1.2,
que é composto por Rua, Cidade, Estado, País e CEP.
Rua
Cidade
endereço
Professor
Estado
País
CEP
Fig. 1.2 - atributo composto
1.3.2. Hierarquia de Generalização
Uma classe E é uma generalização de um grupo de classes E1, E2, ..., En se cada objeto das
classes E1, E2, ..., En é também um objeto da classe E. Uma forma de representar uma
hierarquia de generalização é dada na figura 1.3.
E
E1
E2
...
En
Fig. 1.3- Hierarquia de generalização
7
•
Propriedades de Cobertura da generalização
Cobertura TOTAL ou PARCIAL
A cobertura de uma generalização é total (t) se cada elemento da classe
genérica é mapeada para pelo menos um elemento das classes especializadas.
Ex: A generalização formada pela classe PESSOA e as subclasses HOMEM
e
MULHER (figura 1.4) possui cobertura total.
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
Homem
Carro
Mulher
Fig.1.4 - cobertura total
Bicicleta
Fig.1.5 - cobertura parcial
Cobertura EXCLUSIVA ou de SOBREPOSIÇÃO:
A cobertura de uma generalização é exclusiva (e) se cada elemento da classe genérica
possui no máximo um elemento correspondente em uma das subclasses.
Ex: A figura 1.6 representa uma cobertura exclusiva.
A cobertura é de sobreposição (s) se existe algum elemento da classe genérica que
possui elementos correspondentes em duas ou mais subclasses.
Ex: Na figura 1.6, suponha que pode existir aluno que cursa a graduação e a pósgraduação ao mesmo tempo.
8
Aluno
AlunoGraduaçao
Aluno-PósGraduação
Fig. 1.6 - cobertura de overlapping
Notação: Para denotar o tipo de cobertura de uma hierarquia de generalização será
usada a seguinte notação: (t,e), (t,s), (p,e), (p,s), como exemplificado na figura 1.7.
Quando numa generalização a cobertura não está especificada, admite-se que é (t,e).
Veículo
(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 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.
Cliente
nro-cli
nome-cli
endereço
Cliente
Especial
taxa-desconto
Fig.1.8 - hierarquia de subconjunto
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
nome
título
Pessoa
situaçãoserv-mil
Homem
Mulher
nomesolteira
Empr
Chefe
nro-emp
nome-divisão
Gerente
Militar
categoria
divisão
ident-nadivisão
posição
Fig. 1.9
1.4. Exercícios
1. Indique na figura 1.4 se a cobertura é exclusiva ou de sobreposição.
2. Indique na figura 1.6 se a cobertura é total ou parcial.
3. Indique as propriedades de cobertura da generalização na figura 1.10.
Suposições: - só existem jogadores de futebol e de tênis;
- pode ter jogadores que jogam os dois esportes.
Jogador
Futebol
Tênis
Fig. 1.10
4. Verifique como as propriedades de cobertura da hierarquia de generalização se
relacionam com as restrições de cardinalidade de relacionamento. (Sugestão:
interprete hierarquias de generalização como tipos especiais de relacionamento entre
classes).
5. Transforme as hierarquias do exerc.4 em relacionamentos entre a classe genérica e
as subclasses.
6. Considerando a propriedade fundamental de hierarquias de generalização,
simplifique o esquema da figura 1.11.
10
mora
(1,n)
(1,n)
nome
nascida
Cidade
Pessoa
(1,1)
(1,1)
(1,n)
(1,1)
Masculino
reside
Feminino
(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. Faça o esquema conceitual usando o modelo Entidade-RelacionamentoEstendido,
do seguinte problema:
Uma companhia mantém informações sobre as pessoas que, de alguma forma,
possuem com ela algum vínculo, dentre essas seus funcionários. Os seguintes
requisitos foram levantados junto aos usuários:
a. De cada pessoa mantém-se um código, o nome, endereço.
b. De cada funcionário guarda-se também seu salário e o departamento a que ele
pertence. Desses funcionários, alguns são gerentes e para cada um destes guarda-se os
nomes dos projetos que eles gerenciam.
c. Dos demais funcionários que são operários, guarda-se suas habilidades (um
operário pode ter várias habilidades).
d. Mantém-se também os
trabalhos executados na Companhia (código e
característica) e os operários que executaram cada trabalho, juntamente com o período
que isto se deu. Sabe-se também que pode haver operários que não exercem nenhum
tipo de trabalho dentre os cadastrados.
e. Deve-se também manter os dependentes de cada funcionário (nome, sexo e data de
nascimento).
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.
2.2. Conceitos Básicos
Alguns conceitos encontrados nas linguagens de programação orientadas a
objetos (LPOO) são também aplicados nos modelos de dados orientados a objetos,
porém bancos de dados requerem alguns conceitos próprios.
Os objetos, em uma
LPOO, existem somente durante a execução do programa e são por isso chamados de
transitórios. Um banco de dados orientado a objetos pode estender a existência dos
objetos de modo que eles sejam armazenados permanentemente, isto é, os objetos são
persistentes (eles persistem após o término do programa e podem ser recuperados
posteriormente e compartilhados por outros programas.
A seguir são 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 métodos que
agem sobre o estado do objeto pela invocação de operações.
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 não e visível ao usuário, mas é
usado internamente pelo sistema para identificar cada objeto de forma única e criar e
gerenciar referências entre objetos.
A principal propriedade de um OID é que ele é imutável, isto é, o valor do OID de um
particular objeto não deve mudar. O SGBDOO deve ter algum mecanismo para
gerenciar OIDs e preservar a propriedade de imutabilidade. É também desejável que
cada OID seja usado somente uma vez, isto é, os OIDs dos objetos que são removidos
do banco de dados não são reaproveitados.
As duas propriedades acima implicam que o OID não deve depender de nenhum valor
de atributo do objeto. Geralmente é considerado não apropriado basear o OID no
endereço físico do objeto no meio de armazenamento, uma vez que o endereço físico
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.
2.2.3. Estrutura do objeto
O valor de cada atributo de um objeto pode ser:
- atômico: integer, real, character, booleano, etc.
- complexo: definido através de construtores: tuple, set, list, bag e array.
O construtor de tipo tuple serve para agregar informações afins. É freqüentemente
chamado de tipo estruturado, pois corresponde ao construtor struct nas linguagens de
programação C e C++.
Os construtores de tipo set, list, array e bag são chamados de tipos de coleção e
servem para definir atributos multivalorados. Podem ser não ordenados (set e bag) ou
ordenados (list e array). Em um set não pode haver dois elementos com o mesmo
valor, enquanto que na bag isso é possível.
2.3.4. OIDs x Chaves Primárias
Nos modelos orientados a objetos não existe o conceito de chave primária como
acontece no modelo relacional. Ao invés disso, existem os OIDs dos objetos que,
como já dito, são criados e mantidos pelo sistema de gerenciamento de banco de
dados e não são de acesso do usuário.
As vantagens do uso de OIDs com relação às chaves são:
- os programadores de aplicações não precisam se preocupar com a seleção de chaves
para as várias classes de objetos;
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.5. Objetos Complexos
A composição estrutural de um objeto é definida através de um
atributos.
conjunto de
O valor de cada atributo pode ser primitivo, um objeto ou uma
combinação dos construtores tupla, lista, array, conjunto ou bag, envolvendo outros
objetos ou não. Objetos complexos são definidos através 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 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.8. Tipos e Classes
Um tipo modela as características comuns de um conjunto de objetos e corresponde à
noção de tipos abstratos de dados. Uma classe é um conjunto de objetos que tem
exatamente a mesma estrutura interna, i.é, os mesmos atributos e mesmos métodos.
Os modelos de dados orientados a objetos usam o conceito de classe como uma base
para instanciaçã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.
Exemplo: Considere duas classes com informações sobre um conjunto de ônibus e
caminhões. As características das duas classes são mostradas na figura 2.1 cuja
notação gráfica utilizada representa cada classe por um retângulo dividido em 3
partes. A parte superior contém o nome da classe; a do meio contém os atributos e a
inferior contém os métodos definidos pelo usuário. Como as duas classes possuem
algumas características em comum, pode-se criar a classe Veículo para conter essas
características, como na figura 2.2. Somente as características próprias de cada
subclasse são mantidas na mesma.
16
Caminhão
Ônibus
nro-placa:STRING
modelo:STRING
licença:NUMBER
data_última_revisão:DATE
valor_estimado:NUMBER
próxima_revisão:DATE
nro-placa:STRING
modelo:STRING
lugares:NUMBER
data_última_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
licença:NUMBER
valor_estimado:NUMBER
Ônibus
lugares:NUMBER
Fig. 2.2 - Hierarquia de herança
Vantagens da utilização de hierarquias de classe:
- diminui a quantidade de código a ser escrito;
- propicia uma descrição mais precisa e concisa da realidade.
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
nro-placa:STRING
modelo:STRING
data_última_revisão:DATE
próxima_revisão:DATE
Caminhão
Veículo_Passageiro
rota: STRING
preço:NUMBER
horário_saída:NUMBER
Ônibus
licença:NUMBER
valor_estimado:NUMBER
lugares:NUMBER
Fig. 2.3 - Herança múltipla
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.
Em um esquema de bd, as classes podem ser organizadas em uma hierarquia de
herança, formando um grafo acíclico dirigido.
18
Veículo
Veículo_Passageiro
nro-placa:STRING
modelo:STRING
data_última_revisão:DATE
combustível:(gasolina, álcool,diesel)
rota: STRING
preço:NUMBER
horário_saída:NUMBER
combustível:(diesel)
próxima_revisão:DATE
Ônibus
lugares:NUMBER
combustível:(diesel)
Fig. 2.4 - Herança múltipla
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)
A ligação do nome da operação com a correspondente implementação é realizada em
tempo de execução. Essa ligação retardada é dita late binding.
A sobrecarga (overloading) de operador refere-se ao uso do mesmo símbolo de
operador para denotar operações distintas sobre diferentes tipos de dados.
20
3. Modelagem de Dados Orientada a Objetos
3.1. Motivação
A motivação mais imediata para a adoção dos princípios da orientação 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 níveis de detalhe. Por exemplo, para
um observador, uma árvore pode ser vista como um objeto indivisível, sem levar em
consideração sua composição 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 são consideradas objetos que fazem
parte da composição do objeto árvore.
Essa maneira natural de ver a composição dos objetos deve ser conservada na
modelagem dos objetos e é o objetivo dos modelos de dados orientados a objetos,
fornecendo uma representação 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 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.
2. Projeto lógico: projeto de uma estrutura lógica, representando o esquema lógico
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 informação
tradicionais.
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.
♦ Desenvolvimento orientado a objetos:
O desenvolvimento orientado a objetos usa o princípio de abstração de dados, aonde
as funcionalidades do sistema são associadas com os objetos (objetos encapsulam
dados e comportamento).
3.3. Modelando Objetos
Na modelagem da estrutura dos objetos, dois tipos de hierarquias são
utilizadas: a hierarquia de agregação (relacionamento É-PARTE-DE) e a hierarquia de
generalização/especialização (relacionamento É-UM). No esquema lógico do banco de
dados o.o., hierarquia de agregação é estabelecida através de referências. A hierarquia
de generalização/especialização é estabelecida através de declarações próprias. A
seguir apresenta-se, através de exemplos usando uma linguagem de definição de
objetos fictícia, como é realizada a definição das classes e a definição de hierarquias
de generalização/especialização.
3.3.1. Definição de classe
A definição de classe é uma especificação abstrata. Por exemplo: classe
Conta_Corrente com as propriedades: nro_conta, proprietário, saldo_corrente (veja
especificação abaixo). As propriedades podem ser definidas em termos de outras
classes: o proprietário de uma conta é uma instância de uma classe Cliente. As
propriedades de proprietário representam objetos inteiros, não valores de chaves ou
ponteiros.
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.
3.4.1. Representação de uma classe de objetos
nome da classe
nome_método(param);
...
atributo1
atributo2
...
atributon
3.4.2. Representação de conjunto, lista e tupla
Conjunto (SET):
Tupla (TUPLE):
Lista (LIST):
Exemplo:
nome-rua
Pessoa
nome
endereço
telefone
filhos
rua
bairro
Dependente
número
nome
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
indicação desse construtor é inserida na seta de definição do atributo.
3.4.3. Herança simples
a) uma só subclasse
Pessoa
Cliente
b) várias subclasses
nome
endereço
telefone
Pessoa
nome
endereço
telefone
nro-cliente
ender-comercial
ClienteCasual
renda
limitecred
ClienteFrequente
nro-cliente
débito
Fig. 3.2 a e b - Herança Simples
3.4.4. Herança múltipla
* : indica o atributo a ser herdado no caso de conflito.
nome
endereço
cpf
Cliente
Funcionário
Cliente Interno
Fig. 3.3- Herança Múltipla
25
débito
nome*
nro-carteira-trab
endereço*
salário
3.4.5. Definição recursiva
nome
endereço
filhos
Pessoa
Fig. 3.4 - Definição Recursiva
3.4.6. representação de referências inversas
Quando a referência entre duas classes é nos dois sentidos, usa-se a notação da
figura 3.5, aonde está representado que cada projeto possui um conjunto de
empregados (através do atributo empregs) e cada empregado atua em um projeto.
Projeto
empregs
•
proj
Empregado
Fig. 3.5 - referências inversas
3.5. Geração do Esquema Lógico
Para a geração do esquema lógico será adotada a linguagem utilizada na seção
3.3, cuja forma geral é dada seguir:
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
A definição do tipo segue a seguinte regra de sintaxe:
tipo :: = tipo-básico / nome-classe /tipos_inversos
tuple (nome-atributo: tipo [, nome-atributo:tipo] ...) /
set(tipo) /
26
list(tipo)
tipo-básico :: = 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 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.
Exemplo : O esquema da figura 3.1 é expresso como:
class Pessoa
properties
nome : String;
endereço: tuple ( rua: tuple ( nome_rua: String, número: Integer),
bairro:String);
telefone: list (Integer);
filhos: set (Dependente);
end Pessoa
class Dependente
properties
nome: String;
sexo: String;
data_nasc: Date;
end Dependente
A especificação das classes da figura 3.5 é dada a seguir:
class Projeto
properties
empregs: set(Empregado) inverse is Empregado.proj;
end Projeto;
27
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 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:
- Um projeto pode ser organizado na forma de vários sub-projetos e a classe Projeto é
definida recursivamente em termos dela mesma.
- Um plano de trabalho, consistindo de várias tarefas, é associado a cada projeto.
- Cada tarefa é atribuída a um grupo de pesquisa que consiste de vários pesquisadores
e tem um coordenador. Note-se que o coordenador de uma tarefa não é
necessariamente o coordenador do grupo de pesquisa atribuído para a tarefa. Para cada
tarefa são identificadas as tarefas que a antecedem.
-
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.
Os seguintes métodos devem ser definidos:
-
Calcular_esforço, para a classe Tarefa, que calcula o esforço dedicado pelos
pesquisadores para desenvolvimento da tarefa, em termos do tempo dedicado.
28
-
Associar_membro, para a classe Grupo, que insere um novo pesquisador num
determinado grupo de pesquisadores.
-
Analisar_documento,
que
recupera
documentos
de
uma
determinada
classificação.
-
Calcular_bônus, que calcula o valor total dos bônus recebidos pelos
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
objetivo
documento
plano_trabalho
sub_projeto
Projeto
tópicos
início_validade
fim_validade
evolução
Tarefa
calcular_esforço()
Documento
analisar_doc(classif:String)
Relatório_
Técnico
data_início
data_fim
descrição_tarefa
coordenador
anos_homem
participante
precede
Artigo
Pesquisador
calcular_bonus()
Grupo
associar_membro()
Fig.3.6 – Banco de Dados para Gerenciamento de Projetos
30
código_doc
nome
classificação
autor
tipo_publ
local_publ
data_publ
nome
especialização
salário
bônus_produção
nome_grupo
membro
coordenador
3.7. Notação 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 semelhança com os diagramas EER. Para
acompanhar a discussão a seguir, considere o esquema de banco de dados EER de
uma companhia, da figura 3.7, e sua representação na notação UML na figura 3.8
(apresentados no livro de Elmasri & Navathe, 2000). Os tipos de entidades da figura
3.7 são modelados como classes na figura 3.8. Na notação UML, uma classe é
representada por uma caixa com 3 seções: a do topo contém o nome da classe; a seção
do meio contém os atributos dos objetos da classe e a última seção contém as
operações que podem se aplicadas sobre esses objetos. Opcionalmente pode-se
especificar o domínio dos atributos (por exemplo: datanasc: date), como mostrado na
figura 3.8. Um atributo composto é modelado como um domínio estruturado, como
ilustrado pelo atributo Nome da classe Empregado. Um atributo multivalorado é
geralmente modelado como uma classe separada, conforme ilustrado pela classe
Localização.
Na terminologia UML, tipos de relacionamentos são chamados associações e
instâncias de relacionamentos são chamados links. Uma associação binária
(correspondendo a um tipo de relacionamento binário do modelo EER) é representada
através de uma linha conectando as classes participantes e podem opcionalmente Ter
um nome. Um atributo de relacionamento, chamado de atributo de ligação (link
attribute) é colocado em uma caixa que é conectada à linha da associação por uma
linha pontilhada. A notação (min, max) usada para especificar restrições de
relacionamento no modelo EER, é chamada de multiplicidade em UML.
Multiplicidades são representadas na forma min .. max, e o asterisco (*) indica que
não há limite máximo na participação. Note-se que as multiplicidades são colocadas
nos lados opostos do relacionamento quando comparadas à notação 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 unário) é
chamado uma associação reflexiva em UML e os nomes dos papéis, da mesma forma
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
nroE
sexo
sobrenome
endereço
salário
data nasc (1,1)
nroD
nro-empregados
nome
localização (1,n)
(4,n)
Trabalha
Empregado
Departamento
data-início
(0,1)
(1,1)
(0,n)
Gerência
(0,n)
Supervisiona
(0,1)
é supervisionado
(1,n)
horas
Controla
Atua
Supervisiona
(1,n)
(0,n)
(1,1)
Projeto
Possui
nro nome localização
(1,1)
Dependente
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}
endereço
salário
data_nasc: Date
Trabalha
1..1
1..1
nroD
nome
0..1
Adiciona-empr
Nro-empregados
Muda-gerente
...
Gerência
0..*
1..1
Data_Inicio
1..*
1..*
Localização
controla
Nome
idade
muda-depto
...
Atua
é supervisionado
1..*
*
1..1
Horas
*
Projeto
Nome
Nro
Nome Dependente
0..1
supervisiona
0..*
Adiciona_empr
Adiciona_projeto
...
Dependente
Sexo: {M,F}
Data nasc: Date
Grau-parentesco
...
Figura 3.8 – Diagrama de classes UML – BD Companhia
As operações dadas em cada classe podem ser acompanhadas pelos parâmetros.
Entidades fracas podem ser modeladas usando o construtor chamado associação
qualificada (ou agregação qualificada). A chave parcial é colocada em uma caixa
anexada à classe proprietária.
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
Cliente
Empregado
tipo cliente
porcent-desconto
Salário
Pessoa fisíca
Pessoa Juridíca
CPF
CGC
Figura 3.9 – Generalização/especialização em UML
Na Figura 3.10 tem-se o BD Companhia modelado segundo a notação de objetos
considerada nesta apostila e a figura 3.11 mostra o BD de Projeto modelado segundo
a notação UML, usando a ferramenta Rational Rose.
34
prim_nome
nome
nroE
sobrenome
sexo endereço salário
data_nasc
Empregado
ger
idade
muda-depto
...
supervisor
depends
•
depto-trab
emprs
gerente
data-início
atua
Departamento
nroD
Adiciona-empr
Nro-empregados
Muda-gerente
...
nome
projs
horas
Projeto
Dependente
...
emps
proj
adiciona-empr
adiciona-proj
nome nro localização
grau_parentesco
nome sexo data_nas
Figura 3.10 – Esquema de Objetos - BD companhia
35
+compõe
0..1
gera
Projeto
nome_proj : string
objetivo : string
0..*
+é_composto
Documento
codigo_doc : int
nome : string
classificação : string
0..*
1
analisar_documento()
1
possui
Relatório_Técnico
tópicos : string
início_validade : date
fim_validade : date
1..*
+é_precedida
0..*
Tarefa
data_inicio : date
data_fim : date
descrição_tarefa : string
anos_homem : float
0..*
+precede
Artigo
tipo_publ : string
local_publ : string
data : date
0..*
escreve
0..*
calcular_esforço()
1..*
1..*
coordena
participa
1
1
1..*
Grupo
é membro
1..*
nome_grupo : string
Pesquisador
nome : string
especialização : string
salário : float
bônus_produção : float
1
associar_membro()
0..1
calcular_bônus()
coordena
Fig.3.11 - BD de Projeto- notação UML
Legenda
Class
Multiplicity
ClassName
attributes
operations()
Agregation
0
zero
1
one
0..1
zero or one
0..*
zero or more
1..*
one or more
n
*
Association
36
3.8. Exercícios
1. Mapeie o esquema da figura 3.6 para a linguagem de especificação de objetos dada
na seção 3.5.
2. Desenvolva o esquema conceitual orientado a objetos do problema do exercício 8
do capítulo 1 e faça o mapeamento para a linguagem de especificação de objetos dada.
3. Desenvolva o esquema conceitual orientado a objetos da aplicação a seguir,
referente ao cadastro imobiliário de uma cidade. Faça o mapeamento para a linguagem
de especificação de objetos dada.
Nessa aplicação estão envolvidas informações relativas a bairros, ruas,
quadras, segmentos de quadras e imóveis.
As informações a serem mantidas sobre cada bairro são: Nome do bairro,
delimitação (região que delimita o bairro) e composição (quadras que compõem o
bairro).
Sobre cada quadra, é necessário armazenar: código da quadra e composição
(imóveis que compõem a quadra).
Com relação às ruas, deve-se guardar o código da rua, nome, o início da rua
(ponto de coordenadas (x,y)) e a composição (segmentos de quadra que compõem a
rua).
Os segmentos de quadra devem possuir um código, número inicial, número
final e composição (uma seqüência ordenada de pontos (x,y)).
Quanto aos imóveis, as informações a serem mantidas são: código de
inscrição, proprietário (nome e categoria: particular, municipal,etc), localização (rua,
número, bairro).
No caso de haver construção no imóvel, deve-se guardar também informações
sobre: utilização (residencial, comercial,...) e delimitação da construção.
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:
a) Dado um título (referente a um nome de Cd ou de Livro), recuperar:
-
gênero e compositores, se for CD de música;
-
empresa responsável, se for CD Multimídia; 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 Física, mostrar seu telefone e o nome dos CDs que
ela emprestou.
Faça um esquema conceitual e o esquema lógico correspondente.
38
4. Manipulando Objetos
A manipulação de objetos é feita através de uma linguagem de consulta a
objetos. Uma linguagem de consulta oferece uma forma de recuperar informações do
banco de dados de uma maneira declarativa e formulada em alto nível. Muitos
Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos utilizam uma
extensão da linguagem de consulta SQL (Structured Query Language), uma das mais
utilizadas para SGBDs relacionais, incorporando nesta mecanismos para manipulação
da estrutura complexa dos objetos.
A formulação de consultas podem ser feitas interativamente para recuperar
objetos do banco de dados ou podem ser embutidas em uma linguagem de
programação, na definição de métodos.
4.1. Características de Linguagens de Consulta OO (LCOO)
4.1.1. Hierarquias de Agregação
No modelo relacional, para consultar informações envolvendo mais do que uma
tabela, usa-se a operação de junção sobre seus atributos chaves (primárias / estrangeiras).
Como exemplo, suponha as tabelas abaixo e, a seguir, uma consulta sobre essas
tabelas:
Projeto (codproj, nome_proj, objetivo, ...)
Tarefa (codtarefa, data-início, data-fim, ...,codproj, codpesq)
Pesquisador(codpesq, nome, especialização,salário)
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 :
SELECT DISTINCT Projeto.nome_proj
FROM Projeto, Tarefa, Pesquisador
WHERE Projeto.codproj = Tarefa.codproj and
Tarefa.codpesq = Pesquisador.codpesq and
Pesquisador.especialização = ‘BD’
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.
C1
atrib_c1
atrib_c2
C2
C3
atrib_c3
Fig. 4.1 - Hierarquia de agregação
Isso implica em certas extensões à linguagem de consulta, para possibilitar a
navegação através 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 junção implícita).
4.1.2. Hierarquia de Herança
Numa hierarquia de herança, pode-se querer consultar só a classe raiz ou a classe e
todas as suas subclasses. É interessante que a linguagem de consulta ofereça as duas
possibilidades.
4.2. Consultando Objetos
4.2.1. Hierarquias de Agregação
Numa hierarquia de agregação, a expressão de caminho pode envolver
referências simples ou multivaloradas. A seguir são apresentadas expressões de
consultas envolvendo essas duas formas de referência. A sintaxe apresentada baseia-se
em linguagens de consulta de gerenciadores existentes, mas não se refere exatamente à
sintaxe de um gerenciador específico.
• 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 x. atrib_c1. atrib_c2. atrib_c3
From x in C1
Where condição de seleção
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_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
Fig. 4.2 - Uso de Referência Multivalorada
Select y.atrib_c2
From x in C1
y in x.atrib_c1
Where condição de seleção
41
atrib_c2
Exemplo: Na figura 3.6: Selecione o código e a classificação dos documentos
do Projeto "Projeto A".
Select d.código_doc, d.classificação
From p in Projeto
d in p.documento
// documento é o nome do atributo e não da classe
Where p.nome_proj = "Projeto A"
4.2.2. Hierarquia de Herança
A recuperação de informações 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. Definição de Métodos
A seguir são apresentados os algorítmos de alguns métodos desenvolvidos para o
Banco de Dados da figura 4.3, que é uma simplificação do Banco de Dados de
Projeto. Alguns gerenciadores de banco de dados orientados a objetos possuem
uma linguagem de quarta geração, estilo C++, para a codificação dos métodos.
Opcionalmente permitem o uso de outras linguagens de programação, 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
código_doc
nome
classificação
Mostra_Documentos
Elimina_Proj
tópicos
início_validade
fim_validade
Relatório_
Técnico
Cadastra_RT
Mostra
Artigo
aut_princ
tipo_publ
local_publ
data_publ
Cadastra_Art
Mostra
Pesquisador
Busca_Pesq
Cadastra_Pesq
nome
especialização
salário
bônus_produção
Fig. 4.3 - BD de Projeto simplificado
Alguns dos métodos definidos nas classes da figura 4.3 são dados a seguir, usando
uma linguagem algorítmica.
1. Cadastrar um Projeto, sem documentos e com coordenador
Método 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.
Método 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 código.
Método 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 (Relatório Técnico ou Artigo) de um projeto, dado seu
código. Se Relatório Técnico, mostrar início e fim de validade e o nome. Se Artigo,
mostrar tipo de publicação e nome do artigo.
Método Mostra ( ) da classe Documento
{ } // não faz nada
Método Mostra( ) da classe Relatório_Técnico
// Mostrar início e fim de validade e nome do relatório técnico
resultado: tupla(início_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
Método Mostra( ) da classe Artigo
//Mostrar tipo de publicação 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);
}
Método Mostra_Documentos (cod_projeto:Integer) da classe Projeto
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
}
5. Eliminar um projeto de código dado (sem eliminar pesquisador e documento)
Método 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 então
{Retira p de Projeto
return(true)}
senão return(false)
}
6. Cadastrar um documento (pode ser relatório técnico ou artigo). Incluir esse
documento no projeto que o gerou (é fornecido como entrada o código do projeto).
Método Cadastra_RT (cod_doc:Integer, nome_doc:String, classific:String,
tópicos:String; inicio_val, fim_val:Date, cod_proj:Integer) da classe
Relatório_Técnico
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;
// Inserir o relatorio tecnico nos documentos do projeto dado
proj=Busca_proj(cod_proj);
Se proj≠nulo então
Insira rt em proj.documento;
}
4.4. Exercícios
1. Faça o método 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 código é 520.
b) Recupere o nome do primeiro autor do artigo cujo código é 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 descrição da respectiva tarefa.
Com base no esquema do Cadastro Imobiliário, expresse as consultas a seguir.
7. Recupere a localização de cada imóvel.
8. Recupere o bairro aonde está localizado o imóvel de código de inscrição 1000.
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.
13. Selecione o 70 segmento de quadra da rua de código ‘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 capítulo resume-se as principais características dos SGBDs orientados a objetos
e apresenta-se alguns SGBDOOs existentes destacando, através de uma tabela, quais
dessas características cada um deles possui.
5.1. Características dos SGBDs Orientados a Objetos
Os SGBDOOs são SGBDs baseados nos conceitos de modelos de dados orientados a
objetos. Diferentemente dos SGBDs Relacionais que foram desenvolvidos para dar
suporte às necessidades das aplicações comerciais tradicionais, os SGBDs orientados
a objetos foram desenvolvidos para satisfazer aos requisitos impostos por aplicações
mais avançadas, ditas não convencionais. Essas aplicações não convencionais
apresentam requisitos e características tais como:
-
necessidade de estruturas complexas para representar objetos;
-
necessidade de novos tipos de dados para armazenar informações, tais
como imagens, voz e documentos textuais grandes;
-
requisitos de manipulação de dados não bem suportados pelos SGBDs
tradicionais.
Uma outra característica 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 operações que podem ser aplicadas a esses objetos.
•
Identificador de Objeto (OID): a implementação de identidade de objeto em
sistemas de bdoo envolve 3 tipos de independência:
Independência de local: a identidade do objeto é preservada quando ocorre
mudanças de localização física.
Independência de valor: preservação da identidade independente do conteúdo.
48
Independência de estrutura: preservação da identidade independente de mudanças
em sua estrutura.
Vantagens dos OIDs:
- facilidade para modelar a estrutura complexa dos objetos;
- propicia o compartilhamento de objetos;
- propagação de mudanças de valor de um objeto (através da referência)
- suporte ao relacionamento entre os objetos
- favorece o gerenciamento de versões
•
Atributos e Métodos Visíveis/Invisíveis : Alguns sistemas permitem o usuário
estabelecer quais atributos e métodos são visíveis (públicos) na interface do objeto
e podem ser invocados por outros objetos. Aqueles que não são visíveis são ditos
privados.
•
Instâncias Excepcionais: O sistema O2 permite a criação de instâncias de uma
classe com atributos e/ou métodos adicionais àqueles especificados para a classe.
•
Objeto Composto: Alguns sistemas (por ex. ORION) permitem aplicações
modelar um conjunto de objetos (ditos objetos componentes) como uma entidade
lógica. Isso significa que o sistema pode manipular esse conjunto de objetos como
uma unidade para bloqueio, autorização e clustering físico.
•
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
versões alternativas
v3
v5
v6
V4
v7: versão final
Figura 5.1.- Conjunto de versões de O1
•
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.
•
Recuperação: um SGBD recuperável é aquele que pode alcançar um estado
consistente após uma falha. Recuperação em SGBDOO é mais complexa
principalmente devido à existência de transações de longa duração.
•
Gerenciamento de Dados Multimídia: Um SGBDOO que suporta dados
multimídia deve fornecer um sistema de armazenamento e recuperação de dados
mais eficiente.
5.2. Vantagens dos SGBDOOs
∗ Possuem um poderoso modelo de dados.
∗ Permitem representar a semântica do problema do mundo real de forma mais exata
do que através de um conjunto de tabelas planas.
∗ Manipulam objetos complexos.
∗ Objetos podem ser reusados em diferentes programas.
∗ Herança de relacionamentos entre conjuntos de entidades.
∗ Associam comportamento de objetos com definições de objeto ao nível de
esquema.
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.
5.3. Alguns SGBDOOs Existentes
Há vários SGBDOOs em desenvolvimento por fabricantes, laboratórios de pesquisa,
universidades. Nos últimos anos, muitos protótipos experimentais e SGBDOOs
comerciais têm se tornado disponíveis. As tabelas 5.1 e 5.2 apresentam um resumo
das principais características de alguns SGBDOOs existentes. Esse levantamento foi
realizado em 1995. Desde então houveram mudanças 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 definição de esquemas e
desenvolvimento de aplicações. O sistema ObjectStore permite integração com a
linguagem Java.
53
54
55
6. Padrões para SGBDOOs
O sucesso dos sistemas de banco de dados relacionais não resulta apenas de
um nível mais alto de independência de dados e um modelo de dados mais simples do
que os sistemas anteriores. Seu sucesso se deve também à padronização que sofreram.
A aceitação do padrão 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 aplicação particular em diferentes sistemas
com modificações mínimas no programa. Interoperabilidade se refere à habilidade
de uma aplicação em acessar múltiplos sistemas distintos. Em termos de banco de
dados, isso significa que um mesmo programa de aplicação pode acessar alguns dados
armazenados segundo um certo SGBD e outros dados armazenados por um outro
SGBD.
Esses fatores são importantes também para SGBDs orientados a objetos. Na
indústria de software há vários grupos trabalhando sobre padrões que afetam os
SGBDOOs: o ODMG - Object Database Management Group (padrões gerais para
SGBDOOs), o OMG - Object Management Group (padrão CORBA – Commom
Object Request Broker Architecture, que permite que uma ampla variedade de objetos
interaja em um ambiente distribuído), ANSI X3H2 (SQL padrão), ANSI X3J16 (C++
padrão), ANSI X3J20 (Smalltalk padrão). Esses padrões visam a portabilidade de
código em alguma maneira.
Com relação a SGBD orientados a objetos, há três padrões: SQL-92, ODMG93 e SQL3. Os dois principais grupos que trabalham sobre padrões para SGBD são o
ODMG e o ANSI X3H2.
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
principalmente,
de padronização,
apresentado pelo grupo, é derivado,
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.
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. The Object Database Standard: ODMG-93 - Release 1.2, Morgan
Kaufmann Publishers, inc., 1996.
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 Gerência de
Objetos em Ambiente de Desenvolvimento de Sistemas Interativos. Tese de
Doutorado, Departamento de Informática, 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