Modelo orientado por objectos

Apresentação em tema: "Modelo orientado por objectos"— Transcrição da apresentação:

1 Modelo orientado por objectos
Sumário limitações do modelo relacional modelo de objectos linguagem orientada por objectos modelo de objectos versus modelo relacional

2 Deficiências Edifício( nome, bilhete, rua, cidade, população, país )
Jerónimos 300 Pr. Império Lisboa Portugal Ajuda 500 Calçada da Ajuda Lisboa Portugal Torre 100 Pr. Catedral Pisa Itália    Luanda Angola • redundância • inconsistência • anomalia de apagamento • anomalia de inserção/ actualização • valores nulos • dispêndio de espaço

3 Normalização Edifício( nome, bilhete, rua, cidade )
Cidade( nome, população, país ) Jerónimos 300 Pr. Império Lisboa Ajuda 500 Calç. da Ajuda Lisboa Torre 100 Pr. Catedral Pisa Lisboa Portugal Pisa Itália Luanda Angola tuplo pendente • relação na Terceira Forma Normal (Boyce-Codd) - só existem dependências na chave de cada relação • problemas anteriores resolvidos pela decomposição • recuperar o aspecto anterior através de uma vista create view Monumento as ( select * from Edifício, Cidade c where cidade = c.nome); • problema na actualização de vistas prejudica a independência lógica dos dados

4 Potência das linguagens relacionais
Quais os monumentos com um preço igual ao máximo da respectiva cidade? select nome from Edificio e where bilhete = (select max(bilhete) from Edificio where cidade= e.cidade) • linguagem natural, de alto nível, com acesso arbitrário • elevada declaratividade  optimização  reforça a independência física dos dados • impossível obter o fecho transitivo da relação binária LIGAÇÕES • só viagens com um número fixo de ligações • esta limitação é que torna viável a optimização • LMD não estão pensadas para IGU  necessário recorrer a linguagens genéricas LIGAÇÕES VIAGENS origem destino Lisboa Madrid Madrid Paris Madrid Londres Paris Oslo Oslo Londres origem destino Lisboa Madrid Madrid Paris Madrid Londres Paris Oslo Oslo Londres Lisboa Paris Lisboa Londres Madrid Oslo Paris Londres Lisboa Oslo

5 Vantagens do modelo relacional
Simplicidade dos conceitos e do esquema só relações esquema físico separado Boa base teórica Grau elevado de independência dos dados independência lógica incompletamente resolvida - problemas com a definição de vistas e com a sua actualização aplicações especificadas independentemente dos dados - mas semântica da aplicação codificada no programa e não no esquema conceptual Linguagens de manipulação de alto nível (declarativas) Aumento da integridade e da segurança Possibilidade de optimização dos acessos aos dados (sistemas rápidos) Manipulação directa de conjuntos de dados tratamento de duplicados processamento paralelo comunicação com liguagens hospedeiras ao nível do tuplo destroi vantagem

6 Novas utilizações das BD
BD clássicas - gestão grandes quantidades de dados número de “ficheiros” pequeno sujeitos a operações simples BD modernas - engenharia: VLSI, CAD, gráficos dispersos por muitos “ficheiros” requerendo operações elaboradas Distinção LMD - eficiente: limitada linguagem hospedeira - geral; não optimizada Quem é o chefe (directo) do Zé?  Quem são os superiores (todos) do Zé?  as LMD falham a recursão mas é isso que permite a optimização Integração LMD + linguagem hospedeira para evitar ter que construir estruturas de dados complexas na área local, à custa de múltiplas chamadas à LMD

7 BD de imagens célula 1 a imagem da célula 1 “é” uma indicação das subimagens componentes e respectivas coordenadas relativas quando necessária, é recursivamente construída a partir dos componentes esta operação deveria ser da responsabilidade do SGBD, para ser eficiente e permitir ver apenas partes da imagem “automaticamente” 2 célula 3 célula 2 célula 4 célula 5...

8 Limitações do modelo relacional
Modelo excessivamente simplificado novas aplicações  objectos complexos, não os valores atómicos da 1FN modelo esparso  requer restrições de integridade para manter a semântica esquema estável, nº baixo de entidades diferentes  fosso semântico para realidades complexas junção pesada  impede construção dinâmica de objectos complexos Linguagens limitadas necessária integração com outras linguagens desadaptação de impedâncias: processamento de conjuntos / de tuplos problemas de comunicação de variáveis e de conversão de tipos optimização só da parte BD

9 Novo contexto de computação
Mainframes centralizados corresponderam aos esquemas conceptuais totalizantes Ascensão do poder de cálculo distribuído por estações em rede requer novo paradigma Interfaces elaborados exigem integração com linguagens não BD Aplicações de projecto (CAD, CAM, CAPublishing, CASE) dados na BD representam artefactos itens muitas vezes organizados em hierarquias projecto é processo interactivo (alterações frequentes nos esquemas; versões) partilha dos dados (justifica SGBD; senão bastava linguagem persistente) Multimedia e escritório electrónico integração da pesquisa tradicional com processamento de imagem, som, video linguagem genérica guardar código na própria BD hipertexto, workflow, partilha de documentos Sistemas operativos têm elevado nível de abstracção

10 Nova geração de BD OBJECTIVOS SEM ESQUECER
o desenvolvimento de aplicações baseado na integração do SGBD com linguagens de programação o gestão mais flexível de dados e esquema o ambiente de desenvolvimento moderno, integrado e com bom IGU o adaptação às arquitecturas distribuídas o extensibilidade (modularidade) OBJECTIVOS o manipulação declarativa dos dados o representação simples de ligações complexas não direccionais o independência de dados e programas o base teórica sólida SEM ESQUECER

11  SGBDOO Funções SGBD persistência transacções
controlo da concorrência recuperação pesquisa versões integridade segurança desempenho  Orientação por objectos tipos de dados abstractos herança identidade dos objectos Estratégias 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

12 RECORDOF(c1:T1, c2:T2, …, cn:Tn)
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

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

14 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

15 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}]

16 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 i Rua João João 34 Braga Direita Nome Esposo António Joana Endereço Próprio Apelido Próprio Apelido Filhos No João Costa Cidade Costa i Rua Maria 34 Braga Direita António Joana

17 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 i Rua Costa João i3 Maria Costa 34 Braga Direita …

18 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

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