Modelo orientado por 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

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

3. Normalização • 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 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 1 000 000 Portugal Pisa 200 000 Itália Luanda 800 000 Angola tuplo pendente

4. Potência das linguagens relacionais • 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 select nome from Edificio e where bilhete = (select max(bilhete) from Edificio where cidade= e.cidade) Quais os monumentos com um preço igual ao máximo da respectiva cidade? 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 • grandes quantidades de dados • 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 4 célula 2 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 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