Modelo de objectos 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
Modelo de objectos - 1
Deficiências
Edifício( nome, bilhete, rua, cidade, população, país )
Jerónimos
Ajuda
Torre

300
500
100

Pr. Império
Calçada da Ajuda
Pr. Catedral

Lisboa
Lisboa
Pisa
Luanda
1 000 000
1 100 000
200 000
800 000
Portugal
Portugal
Itália
Angola
• redundância
• inconsistência
• anomalia de apagamento
• anomalia de inserção/ actualização
• valores nulos
• dispêndio de espaço
Modelo de objectos - 2
Normalização
Edifício( nome, bilhete, rua, cidade )
Jerónimos 300
Pr.
Império Lisboa
Ajuda
500
Calç. da
Ajuda Lisboa
Torre
100
Pr.
CatedralPisa
Cidade( nome, população, país )
Lisboa
1 000 000
Portugal
Pisa
200 000
Itália
Luanda
800 000
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
Modelo de objectos - 3
Potência das linguagens relacionais
select nome
Quais os monumentos com um preço igual ao
máximo da respectiva cidade?
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
origem destino
Lisboa
Madrid
Madrid
Paris
Oslo
Lisboa
Madrid
Madrid
Paris
Oslo
Lisboa
Lisboa
Madrid
Paris
Lisboa
Madrid
Paris
Londres
Oslo
Londres
Madrid
Paris
Londres
Oslo
Londres
Paris
Londres
Oslo
Londres
Oslo
Modelo de objectos - 4
Vantagens do modelo relacional

Simplicidade dos conceitos e do esquema




Boa base teórica
Grau elevado de independência dos dados






só relações
esquema físico separado
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
Modelo de objectos - 5
Novas utilizações das BD

BD clássicas - gestão



grandes quantidades de dados
número de “ficheiros” pequeno
sujeitos a operações simples
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

BD modernas - engenharia: VLSI, CAD, gráficos
 grandes quantidades de dados
Integração


dispersos por muitos “ficheiros”
requerendo operações elaboradas
•
•
LMD + linguagem hospedeira
para evitar ter que construir estruturas de dados
complexas na área local, à custa de múltiplas
chamadas à LMD
Modelo de objectos - 6
BD de imagens
célula 1


2
célula 2
célula 3
célula 4

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”
célula 5...
Modelo de objectos - 7
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
Modelo de objectos - 8
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
Modelo de objectos - 9
Nova geração de BD
o desenvolvimento de aplicações baseado na
integração do SGBD com linguagens de
programação
OBJECTIVOS
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)
o manipulação declarativa dos dados
SEM ESQUECER
o representação simples de ligações
complexas não direccionais
o independência de dados e programas
o base teórica sólida
Modelo de objectos - 10
SGBDOO
Funções  persistência
SGBD
 transacções
 controlo da concorrência
 recuperação
 pesquisa
 versões
 integridade
 segurança
 desempenho

Orientação
por objectos
Estratégias
 novos modelo e linguagem de dados
 estender linguagem BD com capacidades OO
 estender uma LP OO com capacidades BD
 fornecer bibliotecas OO com funções de SGBD
 embeber construções de BDOO em linguagem hospedeira
 produtos para domínios específicos suportados por SGBDOO
 tipos de dados abstractos
 herança
 identidade dos objectos
SIM (Unysis)
Oracle, Informix, Ontos
Opal
ObjectStore, Ontos, Versant
O2
escritório inteligente
Modelo de objectos - 11
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
Modelo de objectos - 12
Tipos, classes e objectos

Exemplo: Banco

CLASS Conta= RECORDOF(
nr : inteiro;
balanço : real
titular : REF Cliente)
- 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}
CLASS Cliente= RECORDOF(
nc : inteiro;
nome : string;
contas : SETOF(Conta))
Conta
nr
balanço
titular Cliente
nc
nome
contas ...
...
...
Modelo de objectos - 13
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
Modelo de objectos - 14
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
o 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)]
•
objectos atómicos
conjunto
tuplo
tuplo hierárquico
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}]}
25, João, 1.3
{João, Maria, Susana}
[Nome:Pedro, Idade:25]
[Nome:[Próprio: João, Apelido:Costa],
Idade:25, Filhos: {Pedro, Paulo, Maria}]
Modelo de objectos - 15
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
Próprio
Apelido
Maria
Costa
Esposo
Endereço
Filhos
i
Cidade Rua
João
Braga
Nome
Próprio
João
Apelido
Costa
Esposo
Endereço
Filhos
i
Cidade Rua
Braga
António
António
Próprio
Próprio
Apelido
No
João
Costa
Direita 34
Joana
Apelido
No
Maria
Costa
Direita 34
Joana
Modelo de objectos - 16
Objectos complexos com identidade
(modelo baseado em FAD)
o 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
i2
Próprio
João
Esposo
Nome
i101
Nome
Endereço
Filhos
Apelido
Costa
i3
i
i4
Cidade Rua No
Braga
Direita 34
Próprio
i102
Apelido
Maria
Costa
…
Modelo de objectos - 17
Igualdade
o 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.
o 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;
o 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
Modelo de objectos - 18
Estes objectos são iguais?
i1
nome
i2
próprio
João
próprio
filhos
i3 i
i4
apelido
Costa
cidade rua
i401
i301
Braga
i103 i
nome
i201
no
Direita 34
esposo
apelido
i102
esposo
endereço
filhos
i101
endereço
Pessoa1= i1
Pessoa2= i1
Pessoa3= i101
Filhos1= i3
Filhos2= i103



Pessoa1 = Pessoa2 ?
Pessoa1 = Pessoa3 ?
Filhos1 = Filhos2 ?
Claro
Profundamente; não superficialmente
Profundamente e superficialmente
Modelo de objectos - 19