450 likes | 626 Views
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.
E N D
Bancos de DadosOrientados 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. Propriedade desejável: um IDO não deve ser reutilizado. Então... IDOs não podem depender de valores de atributos dos objetos.
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.
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.
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.
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
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>) . . .
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
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.
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
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.
Exemplo: define type Empregado tuple ( nome: string; snome: string; cpf: string; datanasc: Data; endereco: string; sexo: char; salario: float; supervisor: Empregado; dept: Departamento; )
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); )
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.
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.
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.
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.
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.
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)
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;
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;
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.
Especificando persistência de objetos • Os dois mecanismos típicos para tornar um objeto persistente são: • Nomeação (naming) • Alcançabilidade (reachability)
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.
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.
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.
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.
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.
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.
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
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).
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.
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
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)
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.
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;
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.
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)
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.
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.
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)
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.
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.