Advanced Object-Oriented Database Systems: Modeling and Data Language

1. SGBDOO • novos modelo e linguagem de dados SIM (Unysis) • estender linguagem BD com capacidades OO Oracle, Informix, Ontos • estender uma LP OO com capacidades BD Opal • fornecer bibliotecas OO com funções de SGBD ObjectStore, Ontos, Versant • embeber construções de BDOO em linguagem hospedeira O2 • produtos para domínios específicos suportados por SGBDOO escritório inteligente  • persistência • transacções • controlo da concorrência • recuperação • pesquisa • versões • integridade • segurança • desempenho • tipos de dados abstractos • herança • identidade dos objectos Funções SGBD Orientação por objectos Estratégias

2. Sistema de tipos • Tipos de base: inteiros, reais, booleanos, cadeias de caracteres • Construtores de tipos • estruturas de registos: dada uma lista de tipos T1, T2, …, Tn e a correspondente lista de nomes de campos c1, c2, …, cn, RECORDOF(c1:T1, c2:T2, …, cn:Tn) é um tipo registo com n componentes (struct) • tipos colecção: dado um tipo T, SETOF(T) é um tipo conjunto de elementos do tipo base T; para além dos conjuntos é habitual usar outras colecções, como multiconjuntos, listas, vectores • tipos referência: uma referência para um tipo T REF T é um tipo cujos valores são adequados para encontrar eficientemente um valor do tipo T: apontador para endereço de memória virtual, ou uma localização num disco de uma máquina (distribuição) — REF frequentemente omitido dá imagem de objectos contidos em objectos

3. Tipos, classes e objectos • Exemplo: Banco • CLASS Conta= RECORDOF( nr : inteiro; balanço : real titular : REF Cliente) CLASS Cliente= RECORDOF( nc : inteiro; nome : string; contas : SETOF(Conta)) • Conta • nr • balanço • titular - por iteração dos construtores obtêm-se estruturas arbitrariamente complexas - tipos + métodos = classe - os objectos de uma classe são constantes (objectos imutáveis) ou variáveis desse tipo (mutáveis) - {2,5,7} objecto imutável da classe CInt=SETOF(inteiro) - s:Cint é uma variável e pode guardar o conjunto {2,5,7} Cliente nc nome contas ... ... ...

4. Características dos objectos • Identidade dos objectos (OID) • cada objecto tem o seu OID cuja validade tem que acompanhar toda a vida do objecto • Métodos • são procedimentos ou funções associados a uma classe • têm sempre como alvo um objecto; podem ter outros argumentos • ex: calcular a soma dos números numa instância de Cint • ADT - Tipos de Dados Abstractos • encapsulamento das variáveis internas impõe disciplina no acesso à informação • obtém-se melhor qualidade e robustez ao software • elevada modularidade facilita a manutenção • capacidade expressiva contrasta com a fixidez do modelo relacional • Relação = SETOF( RECORDOF(c1:T1, c2:T2, …, cn:Tn ) ) • Classes organizam-se em hierarquias • subclasses herdam a estrutura do tipo e os métodos (reutilização) • podem estender a superclasse com mais propriedades ou redefinir as herdadas

5. Modelos de objectos complexos • modelos semanticamente ricos, próximos das construções dos formalismos de especificação (entidade-associação, OMT, etc.), mas várias das linguagens são ad hoc • objectos complexos baseados em valores • sem OID e sem referências • unicidade de um objecto depende apenas do estado (conjunto de valores atómicos das variáveis de instância) • espaço de objectos: florestas de árvores (semelhança com modelo hierárquico e modelo relacional não primeira forma normal) • espaço transitório versus espaço persistente [objectos na memória são caminhos (path) constituídos por atributos (selectores em tuplos) e chaves (selectores em conjuntos)] conjunto de tuplos {[Nome:Pedro, Idade:25], [Nome:João,Idade:7], [Nome:Maria, Idade:13]} relação encaixada {[Nome:Pedro, Filhos:{Max, Susana}], [Nome:João, Filhos:{Maria, Francisco}]} objectos atómicos 25, João, 1.3 conjunto {João, Maria, Susana} tuplo [Nome:Pedro, Idade:25] tuplo hierárquico [Nome:[Próprio: João, Apelido:Costa], Idade:25, Filhos: {Pedro, Paulo, Maria}]

6. Objectos complexos baseados em valores CLASS Nome= RECORDOF( proprio:string, apelido:string) CLASS Morada= RECORDOF( cidade:string, rua:string, no:inteiro) CLASS Pessoa = RECORDOF( nome:Nome, filhos:SETOF(Pessoa), endereço: Morada, esposo:Nome)) tuplo i conjunto Maria Nome Esposo Endereço Próprio Apelido Próprio Apelido Filhos Maria No Costa Cidade Costa Rua João i 34 João Braga Direita António Joana Nome Esposo Endereço Próprio Apelido Próprio Apelido Filhos No João Costa Cidade Costa Rua Maria i 34 Braga Direita António Joana

7. Objectos complexos com identidade (modelo baseado em FAD) • espaço de objectos complexos baseados em identidade (grafo dirigido) - conjunto de identificadores I, conjunto de atributos A - objecto é (identificador, tipo, valor); identificador Î I, tipo é atómico, conjunto ou tuplo tipo atómico — elemento de um domínio de valores atómicos do utilizador conjunto — {i1, i2,…, in}, ijÎ I, sem ordem e sem repetições tuplo — [ai:i1, a2:i2, …, an:in], ijÎ I, ajÎ A - notar a partilha referencial e os ciclos i1 Esposo i101 Nome Nome i2 i102 Endereço Próprio Filhos Apelido Apelido Próprio i4 No Cidade Rua i Costa João i3 Maria Costa 34 Braga Direita …

8. Igualdade • Objectos complexos baseados em valores 1. Dois objectos atómicos são iguais sse forem o mesmo. 2. Dois objectos tuplo são iguais sse os valores em cada atributo forem iguais. 3. Dois objectos conjunto S e S' são iguais sse para cada elemento de S (S') existir um elemento de S' (S) igual. • Objectos complexos baseados em identidade 1. Idênticos. Dois objectos têm identificadores idênticos sse forem o mesmo objecto. 2. Igualdade superficial (shallow equal). Dois objectos são superficialmente iguais sse têm o mesmo tipo e os valores do conteúdo são idênticos; • dois objectos atómicos são iguais se denotam o mesmo elemento no domínio de valores base. 3. Igualdade profunda (deep equal). Dois objectos são profundamente iguais sse têm o mesmo tipo e os valores do conteúdo são profundamente iguais; • Modelo híbrido • objectos atómicos (inteiros, reais, caracteres, booleanos, apontadores, datas) não precisam de uma identidade diferente do seu valor (Smalltalk, Java) — eficiência

9. Estes objectos são iguais? • Pessoa1 = Pessoa2 ? Claro • Pessoa1 = Pessoa3 ? Profundamente; não superficialmente • Filhos1 = Filhos2 ? Profundamente e superficialmente i1 esposo nome filhos endereço i2 i3 i4 i201 i próprio apelido cidade no rua João Costa Braga Direita 34 i401 i301 Pessoa1= i1 Pessoa2= i1 Pessoa3= i101 Filhos1= i3 Filhos2= i103 esposo apelido próprio i102 i103 i endereço filhos nome i101

10. Apoiantes da norma • Object Database Management Group • representa 90 % do mercado existente de SGBDO’s: • Object Design • Objectivity • O2 • Versant • Ontos • Servio • Itasca e liderado por Rick Cattell da SunSoft

11. Modelo de objectos • Modelo proposto pela ODMG (Object Database Management Group dirigido por Rick Cattell) para servir como norma (versão 2.0) para BDOO • Modelo abstracto — existem mapeamentos para C++, Smalltalk e Java • Arquitectura com três componentes • ODL - Object Definition Language — interesse para o projecto • OQL - Object Query Language — extracção de informação • OML - Object Manipulation Language — alteração dos dados; pouco desenvolvida na norma por ser específica de cada linguagem • ODL é uma extensão da IDL (Interface Description Language), a componente da CORBA que descreve as interfaces entre objectos

12. CORBA • Common Object Request Broker Architecture • norma desenvolvida pelo OMG (Object Management Group) para sistemas de objectos distribuídos • pretende tornar a distribuição transparente • e aumentar a interoperabilidade • fornece uma infraestrutura que permite encontrar um determinado objecto para lhe solicitar um serviço e que faz as conversões necessárias • cada objecto apresenta ao sistema uma interface com a sua descrição feita em IDL (Interface Description Language) • as aplicações ligam-se através dessa interface a uma espécie de barramento de dados • houve a preocupação de garantir que o modelo de objectos ODMG fosse um superconjunto do modelo de objectos OMG IDL IDL IDL CORBA

13. Linguagem de Definição de Objectos • em ODL o Mundo é constituído por objectos, com identidade, agrupados em classes • uma classe agrupa objectos que • correspondem a conceitos do mundo real semelhantes • têm todos as mesmas propriedades • propriedades: • atributos - têm tipos baseados em tipos primitivos, que não envolvam classes • associações - referência ou colecção de referências para objectos • métodos - funções aplicáveis aos objectos da classe • declaração de uma classe (muito ao estilo C++) interface <nome> { <lista de propriedades> }

14. Exemplo • As definições de classe em rigor têm uma interface e uma implementação (daí a designação) interface Filme { attribute string titulo; attribute integer ano; attribute integer comprimento; attribute enum Filme {cor, pretoBranco} tipoFilme; } • o quarto atributo é do tipo enumerado Filme, o qual é um conjunto com dois literais cor, pretoBranco interface Estrela { attribute string nome; attribute Struct Morada {string rua, string cidade} endereco; } • neste exemplo existe um atributo composto, mas sem referência

15. Associações • Representar as participações de estrelas em filmes • acrescenta uma linha a Filme com um conjunto (Set) de referências para Estrelas relationship Set<Estrela> estrelas; • ou acrescenta uma linha a Estrela, com uma referência para o Filme de que é a estrela principal relationship Set<Filme> filmes; Filme Estrela nome titulo morada ano rua comprimento cidade tipoFilme estrelas filmes

16. Associação inversa • é natural que se no objecto Jack Nicholson, no conjunto dos filmes constar o objecto Shinning, se espere ir encontrar no objecto Shinning uma referência ao Jack Nicholson • a manutenção da coerência em ambos os lados de uma associação pode ser feita automaticamente, desde que, numa classe, se indique qual o atributo que faz par na outra e é usado para garantir o inverso. interface Estrela { attribute string nome; attribute Struct Morada {string rua, string cidade} endereco; relationship Set<Filme> filmes inverse Filme::estrelas; } • em ODL, por ser abstracta, insiste-se na existência de inversa • permite percorrer os dados arbitrariamente nos vários sentidos • uma concretização numa linguagem OO, pode levar a só criar inversos em associações que o justifiquem.

17. Multiplicidade das associações • Muitos-para-muitos: é o caso da estrelas nos filmes; implementada com conjuntos de ambos os lados • Muitos-para-um: proprietário de um filme; implementada com um conjunto de um lado mais uma referência simples do outro interface Filme { attribute string titulo; attribute integer ano; attribute integer comprimento; attribute enum Filme {cor, pretoBranco} tipoFilme; relationship Set<Estrela> estrelas inverse Estrela::filmes; relationship Estudio proprietario inverse Estudio::possui;} interface Estudio { attribute string nome; attribute string endereco; relationship Set<Filme> possui inverse Filme::proprietario; } • Um-para-um: caso dos presidentes dos estúdios; implementada com uma referência simples quer de um lado quer do outro

18. Tipos em ODL • Tipos atómicos integer, float, character, string, boolean, enumeration • enumerações são listas de constantes vistas como sinónimos dos inteiros • Tipos interface na realidade são estruturas com componentes para os atributos e para as associações mas, uma vez definidos, podem também ser vistos como tipos base • Construtores de tipos • Set (conjunto) - sem repetidos e sem ordem {1, 2} • Bag (multiconjunto) - com repetidos e sem ordem {1,2,1}={2,1,1} • List (lista) - com repetidos e com ordem; string = List<char> (1,2,1)  (2,1,1) • Array (vector) - com repetidos e com ordem, com dimensão definida; Array<char,10> denota as cadeias de caracteres de comprimento 10 • Struct (estrutura) - se T1, T2, …, Tn forem tipos e F1, F2, …, Fn nomes de campos Struct N{ T1 F1, T2 F2, …, Tn Fn } é uma estrutura • Colecções: Set, Bag, List, Array

19. Regras de uso dos tipos • Atributos - começam em tipos atómicos ou estruturas só com tipos atómicos e podem ser envolvidos por uma colecção (4 casos possíveis) • integer • Struct N {string campo1, integer campo2} • List<float> • Array<struct N {string campo1, integer campo2}> • Associações - tipo interface ou um tipo colecção aplicado a um tipo interface • possível: Filme; Bag<Estrelas> • impossível: • Struct N {Filme campo1, Estrela campo2} - envolve uma estrutura • Set<integer> - envolve só tipos atómicos • Set<Array<Estrela>> - envolve colecção de colecções

20. Princípios de projecto • Fidelidade às especificações • evitar a redundância • cada facto da realidade deve estar representado num único sítio no sistema • as relações inversas, se automaticamente mantidas, não implicam redundância • parcimónia e simplicidade • KISS (keep it simple, stupid) • escolha do elemento apropriado para representar a realidade • Declaração de chave (objectos continuam a ter identidade) • interface filme key( titulo, ano) {…}

21. Subclasses • por vezes ocorre que, numa dada classe, parte dos seus objectos tem, para além das características comuns a todos os outros, algumas propriedades específicas. Nesse caso faz sentido usar o conceito de subclasse. • Notação: pôr a seguir ao nome da classe a ser definida, dois pontos e respectiva superclasse interface Cartoon : Filme { relationship Set<Estrela> vozes; // inverse Estrela::personagensAnimação; } • a subclasse herda todas as propriedades de todos os que estão para cima na hierarquia • herança múltipla: se existir interface Policial : Filme {attribute string arma} interface Cartoon-policial : Cartoon, Policial {}; herda dos dois lados, mas para uma classe acessível por mais do que um caminho só herda uma vez (Filme que é superclasse duplamente)