Info

rmát

ica

UFP

ABD

OO

1

Bancos de DadosBancos de DadosOrientados a ObjetosOrientados a Objetos

Prof. Benedito Ferreira

Info

rmát

ica

UFP

ABD

OO

2

Estrutura de objetos e

construtores

2

Info

rmát

ica

UFP

ABD

OO

3

Identidade de objetos:

Um SGBDOO provê um identificador único (IDO) para cada objeto independente armazenado no BD.

Propriedade essencial: ser imutável.Propriedade desejável: um IDO não deve ser reutilizado.

Então... IDOs não podem depender de valores de atributos dos objetos.

Info

rmát

ica

UFP

ABD

OO

4

Objetos versus valores

A maioria dos SGBDOO permite a representação de objetos e valores:

- Objetos possuem identificador único

- Valores não possuem IDO. São armazenados no interior de objetos e não podem ser referenciados por outros objetos.

Info

rmát

ica

UFP

ABD

OO

5

Construtores de tipos:

Definem operações básicas de estruturação de dados, que podem ser combinadas para formar estruturas complexas.

Construtores básicos: átomo, tupla, conjunto.Outros: lista, bolsa (bag), array.

Info

rmát

ica

UFP

ABD

OO

6

Construtores ortogonais significa que qualquer um deles pode ser aplicado a qualquer objeto, seja ele atômico ou resultante de aplicação anterior de outro construtor.

Ortogonalidade dos construtores

Info

rmát

ica

UFP

ABD

OO

7

Ortogonalidade dos construtores

Info

rmát

ica

UFP

ABD

OO

8

Estrutura de objetos

Formalmente, um objeto pode ser represen-tado por um trio (triple) (i,c,v), onde:

i: IDOc: construtor de tipov: estado (ou valor) do objeto

Info

rmát

ica

UFP

ABD

OO

9

Exemplo:o1=(i1,atom, ‘Houston’)o2=(i2,atom, ‘Bellaire’)o3=(i3,atom, ‘Sugarland’)o4=(i4,atom, 5)o5=(i5,atom, ‘Research’)o6=(i6,atom, ‘1988-05-22’)o7=(i7,set, {i1,i2,i3})o8=(i8,tuple, <DNAME:i5, DNUMBER:i4, MGR:i9, LOCATIONS:i7, EMPLOYEES:i10, PROJECT:i11>)o9=(i9,tuple,<MANAGER:i12, MGR_START_DATE:i6>)o10=(i10,set,{i12,i13,i14})o11=(i11,set{i15,i16,i17})o12=(i12,tuple,<FNAME:i18,LNAME:i20,SSN:I21, . . . , SALARY:i26,SUPERVISOR:i27,DEPTO:i8>). . .

Info

rmát

ica

UFP

ABD

OO

10

Objetos como grafos...

Um objeto pode ser representado como um grafo, construído pela aplicação recursiva de construtores.O grafo representando um objeto oi terá:- Um nó para oi (IDO + construtor)- Um nó para cada valor atômico

Info

rmát

ica

UFP

ABD

OO

11

Objetos como grafos...

Se o objeto oi possui um valor atômico, cria-se um arco dirigido do nó que representa oi até o nó que representa seu valor.

Se o valor do objeto é estruturado, cria-se um arco dirigido do nó que representa oi até o nó que representa o valor estruturado.

Info

rmát

ica

UFP

ABD

OO

12

Igualdade versus Identidade de objetos:Dois objetos são ditos idênticos se os grafos que representam seus estados são idênticos em todos os aspectos, incluindo os IDO em cada nível.Ex: o1 = (i1,tuple, <a1:i4,a2:i6>) o2 = (i2,tuple, <a1:i5,a2:i6>) o3 = (i3,tuple, <a1:i4,a2:i6>)

o4 = (i4,atom,10)o5 = (i5,atom,10)o6 = (i6,atom,20)

o1 e o2 são iguais (assim como o2 e o3) o1 e o3 são idênticos: igualdade profunda

Info

rmát

ica

UFP

ABD

OO

13

A construção de tipos

Construtores de tipos são empregados para definir estruturas de dados para um esquema de BD OO.

Atributos que referem-se a outros objeto são referências a outros objetos, servindo para representar relacionamentos entre tipos de objetos.

Info

rmát

ica

UFP

ABD

OO

14

Exemplo:

define type Empregadotuple ( nome: string;

snome: string;cpf: string;datanasc: Data;endereco: string;sexo: char;salario: float;supervisor: Empregado;dept: Departamento; )

Info

rmát

ica

UFP

ABD

OO

15

Exemplo(cont.):

define type Data tuple ( ano: integer;

mes: integer;dia: integer; )

define type Departamento tuple ( nomed: string;

numd: integer;gerente: tuple ( ger: Empregado;

datainic: Data; );localiz: set(string);empregados: set(Empregado);projetos: set(Projeto); )

Info

rmát

ica

UFP

ABD

OO

16

Encapsulamento de operações

Em SBD tradicionais, a estrutura do BD é visível aos usuários e programas externos.Um conjunto de operações padrão é aplicado a objetos de qualquer tipo.

Ex (relacional): seleção, projeção, inserção, etc.

Info

rmát

ica

UFP

ABD

OO

17

Encapsulamento de operações

Nos SBDOO...

É possível definir o comportamento de um tipo de objetos, através das operações que podem ser aplicadas externamente aos objetos daquele tipo.

A estrutura interna do objeto permanece escondida, e o acesso ao mesmo se dá somente através das operações definidas.

Info

rmát

ica

UFP

ABD

OO

18

Encapsulamento de operações

Operações mais comuns:

- criar um objeto- destruir um objeto- atualizar seu estado - recuperar dados do objeto- efetuar algum cálculo

Em geral, a implementação de uma operação pode ser especificada em uma LPPG.

Info

rmát

ica

UFP

ABD

OO

19

Encapsulamento de operações

O usuário externo de um objeto estará ciente apenas da interface do objeto: nome e lista de parâmetros (assinatura) de cada operação. A estrutura de dados interna e as im-plementações das operações (métodos) estarão ocultas. O usuário poderá invocar determina-da operação através do envio das men-sagens apropriadas.

Info

rmát

ica

UFP

ABD

OO

20

Relaxando o encapsulamento...

Para aplicações de BD, o encapsulamento absoluto pode ser bastante limitante. Uma forma de relaxar esse princípio seria dividir a estrutura de um objeto em duas partes:

Atributos visíveis Atributos escondidosEm geral, aos atributos visíveis pode-se ter acesso direto para leitura, via linguagens de consulta de alto nível.

Info

rmát

ica

UFP

ABD

OO

21

Alterações permanecem encapsuladas...

Em geral, operações que atualizam o es-tado de objetos devem ser encapsuladas.

Essa é uma forma de definir a semân-tica de atualizacão dos objetos (restri-ções de integridade são programadas nos métodos)

Info

rmát

ica

UFP

ABD

OO

22

define class Empregado: type tuple (nome: string; snome: string;

cpf: string;datanasc: Data;endereco: string;sexo: char;salario: float;supervisor: Empregado;depto: Departamento; )

operations idade: integer;criar_emp: Empregado;excluir_emp boolean;

end Empregado;

Especificando comportamento dos objetos

Info

rmát

ica

UFP

ABD

OO

23

define type Departamento type tuple( nomed: string;

numd: integer;gerente: tuple ( ger: Empregado;

datainic: Data; );localiz: set(string);empregados: set(Empregado);projetos: set(Projeto); );

operations num_empr integer;criar_depto Departamento;excluir_dept boolean;associar_emp(e:Empregado): boolean;remover_emp (e:Empregado): boolean;

end Departamento;

Especificando comportamento dos objetos

Info

rmát

ica

UFP

ABD

OO

24

Especificando persistência de objetos

Nem todos os objetos são armazenados permanentemente no BD

Objetos transientes: existem durante a execução de um programa.

Objetos persistentes: são armazenados no BD.

Info

rmát

ica

UFP

ABD

OO

25

Especificando persistência de objetos

Os dois mecanismos típicos para tornar um objeto persistente são:

Nomeação (naming)

Alcançabilidade (reachability)

Info

rmát

ica

UFP

ABD

OO

26

Atribuição de um nome ao objeto, através do qual ele poderá ser recuperado futuramente.

Nomeação

O nome deve ser único para um certo BD. Os objetos persistentes nomeados funcionam como pontos de entrada para o BD.

Info

rmát

ica

UFP

ABD

OO

27

Alcançabilidade

Este mecanismo torna persistentes todos os objetos aos quais se possa chegar a partir de outros objetos persistentes. (persistência inferida)

Ou seja...

Se a partir de um objeto persistente A, por uma seqüência de referências, pode-se chegar ao objeto B, então B é persistente.

Info

rmát

ica

UFP

ABD

OO

28

Exemplo...

define class ConjDepart: type set (Departamento); operations incluir_depto(d: Departamento) : boolean; remover_depto(d: Departamento) : boolean;

criar_conj_depto: ConjDepart; destruir_conj_depto: boolean;end ConjDepartamentos;

O objeto TodosDepart é denominado extensão (extent) da classe Departamento.

. . .Persistent name TodosDepart: ConjDepart;. . . d := criar_depto;b := TodosDepart.incluir_depto(d);

Info

rmát

ica

UFP

ABD

OO

29

Hierarquia de tipos e herança

Nos SBDOO, é possível a definição de novos tipos a partir de outros tipos predefinidos.

O conceito de subtipo é útil quando se pretende criar um novo tipo que possui similaridade com algum outro já existente.

O novo tipo herdará todas as funções (atributos e operações) do primeiro, que chamamos de supertipo.

Info

rmát

ica

UFP

ABD

OO

30

Hierarquia de tipos (exemplo 1)

PESSOA: Nome, Endereço, DataNasc, Idade, CPF

EMPREGADO subtype-of PESSOA: Salario, DataContrat

ESTUDANTE subtype-of PESSOA: CG, Curso

Em geral, um subtipo inclui todas as funções definidas para seu supertipo, e algumas funções adicionais, específicas (ou locais) ao subtipo.

Info

rmát

ica

UFP

ABD

OO

31

Hierarquia de tipos (exemplo 2)

FIGURA_GEOM: Forma, Area, PontoReferencia

RETANGULO subtype-of FIGURA_GEOM: Larg, Alt

TRIANGULO subtype-of FIGURA_GEOM: Lado1, Lado2, Angulo

A operação Area pode ser implementada por diferentes métodos para cada subtipo. O atributo PontoReferencia pode ter diferentes significados para cada subtipo.

CIRCULO subtype-of FIGURA_GEOM: Raio

Info

rmát

ica

UFP

ABD

OO

32

Estabelecendo uma restrição para um subtipo...

FIGURA_GEOM: Forma, Area, PontoReferencia

RETANGULO subtype-of FIGURA_GEOM (Forma = ‘retângulo’): Larg, Alt

TRIANGULO subtype-of FIGURA_GEOM (Forma = ‘triângulo’): Lado1, Lado2, Angulo

CIRCULO subtype-of FIGURA_GEOM (Forma = ‘círculo’): Raio

Info

rmát

ica

UFP

ABD

OO

33

Observações...

A definição de tipos descreve objetos, mas não os cria. Um objeto pertencente a um subtipo qualquer também pertencerá ao(s) seu(s) supertipo(s) o t1 t2 ... Em uma aplicação de BDOO, um objeto, tipicamente, pertencerá a uma ou mais coleção de objetos persistentes (ou extensão).

Info

rmát

ica

UFP

ABD

OO

34

Observações...

Considera-se que um SGBDOO possui um sistema de tipos extensível: Pode-se criar bibliotecas de novos tipos, com sua estrutura e comportamento.

Outras aplicações podem usar esses tipos e modificá-los pela criação de subtipos.

Info

rmát

ica

UFP

ABD

OO

35

Objetos Complexos

O interesse pela representação de objetos complexos é a principal motivação para o desenvolvimento de sistemas OO.

Objetos complexos podem ser de dois tipos:

Estruturados Não-estruturados

Info

rmát

ica

UFP

ABD

OO

36

Objetos Complexos não-estruturados

São tipos de dados que requerem grande quantidade de memória, como imagens ou longos objetos textuais (documentos).

Também conhecidos como BLOB’s (binary large objects)

São não-estruturados no sentido de que o SGBD não conhece sua estrutura (somente a aplicação que deles faz uso pode interpretar seu significado)

Info

rmát

ica

UFP

ABD

OO

37

Objetos Complexos estruturados

Possuem uma estrutura definida pela repetida aplicação dos construtores de tipo providos pelo SGBDOO.

Diferentemente dos não-estruturados, sua estrutura é definida e conhecida do SGBD.

Info

rmát

ica

UFP

ABD

OO

38

Exemplo...

define type Departamento type tuple( nomed: string;

numd: integer;gerente: tuple ( ger: Empregado;

datainic: Data; );localiz: set(string);empregados: set(Empregado);projetos: set(Projeto); );

operations num_empr integer;criar_depto Departamento;excluir_dept boolean;associar_emp(e:Empregado): boolean;remover_emp (e:Empregado): boolean;

end Departamento;

Info

rmát

ica

UFP

ABD

OO

39

Referências Semânticas

Há dois tipos de referências semânticas entre objetos complexos e seus componentes:

- pertencimento (ownership): sub-objetos são considerados parte do objeto complexo.

- referência: representa relacionamentos entre objetos independentes.

Info

rmát

ica

UFP

ABD

OO

40

Polimorfismo

O mesmo nome de operação pode ser vinculado a diferentes implementações, dependendo do objeto.

Em hierarquias de tipos, pode-se definir um método genérico para o supertipo, e versões otimizadas para os subtipos.

Em sistemas não fortemente tipados, poderemos ter amarração tardia (late binding)

Info

rmát

ica

UFP

ABD

OO

41

Herança múltipla

Ocorre quando um certo tipo é subtipo de dois (ou mais) outros, herdando atributos e métodos de todos os supertipos.

Com a herança múltipla, temos, não só uma hierarquia, mas uma grade (lattice) de tipos: maior flexibilidade.

Ex: ENGENHEIRO_GERENTE pode ser subtipo de ENGENHEIRO e de GERENTE.

Info

rmát

ica

UFP

ABD

OO

42

Problema típico

Ambiguidade: os vários supertipos podem ter funções distintas com o mesmo nome.

Supertipo comum: se os dois supertipos têm, por sua vez, um supertipo comum, e dele herdaram a função, então não há ambiguidade.

Info

rmát

ica

UFP

ABD

OO

43

Resolução de conflitos

1- Na criação do subtipo, se houver conflito, o usuário deverá explicitar sua escolha.2- Adoção de uma solução padrão (default). Ex: em caso de ambiguidade assumir a função do primeiro supertipo listado. 3- Proibir herança múltipla se ocorrer ambiguidade de nomes de funções (forçar o usuário a ajustar os nomes)

Info

rmát

ica

UFP

ABD

OO

44

Versões

Muitas aplicações demandam a existência de várias versões de um mesmo objeto.

Ex: uma aplicação de eng. de software pode requerer a manutenção de versões para:

- módulos de projeto;- código fonte;- informações de configuração;- massa de teste, etc.

Enquanto novas versões não forem completa-mente validadas, as antigas são mantidas.

Info

rmát

ica

UFP

ABD

OO

45

VersõesUm SGBDOO dever ser capaz de armazenar e gerenciar múltiplas versões do mesmo objeto conceitual (alguns mantêm um grafo de versões).

Em geral, o SGBD oferece meios para referência explícita para as várias versões.

Questões mais complexas (juntar e conciliar várias versões, etc.) ficam para os programas da aplicação.