1 / 45

Bancos de Dados Orientados a Objetos

Bancos de Dados Orientados a Objetos. Prof. Benedito Ferreira. 2. Estrutura de objetos e construtores. Identidade de objetos:. Um SGBDOO provê um identificador único (IDO) para cada objeto independente armazenado no BD. Propriedade essencial: ser imutável.

saxon
Download Presentation

Bancos de Dados Orientados a Objetos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Bancos de DadosOrientados a Objetos Prof. Benedito Ferreira

  2. 2 Estrutura de objetos e construtores

  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.

  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.

  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.

  6. Ortogonalidade dos construtores 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.

  7. Ortogonalidade dos construtores

  8. Estrutura de objetos Formalmente, um objeto pode ser represen-tado por um trio (triple) (i,c,v), onde: i: IDO c: construtor de tipo v: estado (ou valor) do objeto

  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>) . . .

  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

  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.

  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

  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.

  14. Exemplo: define type Empregado tuple ( nome: string; snome: string; cpf: string; datanasc: Data; endereco: string; sexo: char; salario: float; supervisor: Empregado; dept: Departamento; )

  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); )

  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.

  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.

  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.

  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.

  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 escondidos Em geral, aos atributos visíveis pode-se ter acesso direto para leitura, via linguagens de consulta de alto nível.

  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)

  22. Especificando comportamento dos objetos 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;

  23. Especificando comportamento dos objetos 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;

  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.

  25. Especificando persistência de objetos • Os dois mecanismos típicos para tornar um objeto persistente são: • Nomeação (naming) • Alcançabilidade (reachability)

  26. Nomeação Atribuição de um nome ao objeto, através do qual ele poderá ser recuperado futuramente.  O nome deve ser único para um certo BD.  Os objetos persistentes nomeados funcionam como pontos de entrada para o BD.

  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.

  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; . . . Persistentname TodosDepart: ConjDepart; . . . d := criar_depto; b := TodosDepart.incluir_depto(d);  O objeto TodosDepart é denominado extensão (extent) da classe Departamento.

  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.

  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.

  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 CIRCULO subtype-of FIGURA_GEOM: Raio  A operação Area pode ser implementada por diferentes métodos para cada subtipo.  O atributo PontoReferencia pode ter diferentes significados para cada subtipo.

  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

  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).

  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.

  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

  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)

  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.

  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;

  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.

  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)

  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.

  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.

  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)

  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.

  45. Versões Um 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.

More Related