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 Modelo de objectos - 1 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 Modelo de objectos - 2 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 IDL IDL IDL que o modelo de objectos ODMG fosse um superconjunto do modelo de objectos OMG CORBA Modelo de objectos - 3 Linguagem de Definição de Objectos em ODL o Mundo é constituído por objectos, com identidade, agrupados em classes uma classe agrupa objectos que propriedades: correspondem a conceitos do mundo real semelhantes têm todos as mesmas 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> } Modelo de objectos - 4 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 Modelo de objectos - 5 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; Estrela nome morada rua cidade filmes Filme titulo ano comprimento tipoFilme estrelas Modelo de objectos - 6 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. Modelo de objectos - 7 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 Modelo de objectos - 8 Tipos em ODL Tipos atómicos integer, float, character, string, boolean, enumeration 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 enumerações são listas de constantes vistas como sinónimos dos inteiros 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 Modelo de objectos - 9 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 Modelo de objectos - 10 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) {…} Modelo de objectos - 11 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) Modelo de objectos - 12 Exemplo dos Internamentos Considere o seguinte esquema de uma BD de um hospital. O hospital organiza-se em serviços, cada qual com a designação da respectiva especialidade e o número de camas onde pode internar doentes. Os doentes são pessoas adicionalmente descritas pelo organismo de segurança social e respectivo número. Relativamente a cada internamento, regista-se o momento de entrada no serviço, o motivo, o respectivo momento de alta, o estado à saída e o médico responsável; uma transferência de serviço corresponde a uma alta do primeiro em simultâneo com um novo internamento no segundo. Os funcionários são pessoas com um vencimento e o serviço a que estão adstritos. Os médicos são funcionários com uma especialidade e os enfermeiros são também funcionários com uma categoria e que pertencem a uma equipa. Obtenha o modelo de objectos (em ODL) da situação descrita. Modelo de objectos - 13 Resolução Object Servico Pessoa Funcionario * Internamento Doente * Enfermeiro refere objecto Medico refere conjunto de internamentos (e de funcionarios no caso dos Servicos) subclasse associação com atributo inverso Equipa * associação sem manutenção automática de atributo inverso (conjuntos têm os correntes; Internamento os históricos) Modelo de objectos - 14 Algumas classes interface Servico { attribute string designacao; attribute int camas; relationship Set<Funcionario> pessoal inverse Funcionario::serviço; relationship Set<Internamento> internados } a associação pessoal tem uma inversa na classe de Funcionarios chamada serviço de forma a garantir a consistência da sua representação em ambas as classes, i.e., que se um funcionário indica a pertença a um serviço, então esse serviço tem que o referir como parte do seu pessoal (idem para Internamento::internado) interface Internamento { relationship Doente internado inverse Doente::internamentos; attribute date entrada; attribute date alta; attribute string motivo; attribute string estado; relationship Servico servico; relationship Medico medico; } a associação Serviço::internados não tem inversa; no conjunto só se incluem os internamentos correntes; do lado dos internamentos, mantém-se o registo completo, incluindo o histórico, dos internamentos, pelo que há referências a objectos serviço sem que nestes existam as correspondentes ligações a internamentos (apagadas quando o doente teve alta) Modelo de objectos - 15