bancos de dados orientados a objetos

Bancos de Dados Orientados a Objetos

Álvaro Vinícius de Souza Coê[email protected]

Roteiro

Orientação a ObjetosConceitosComo Identificar Classes e Objetos

UMLCasos de UsoObjetos e Classes

Roteiro

UML (cont)AtributosAssociaçõesDiagramas de ColaboraçãoDiagramas de SeqüênciaMétodos

Roteiro

BDOOHistóricoRelacional X RedesSQLBDOO – Objetos (apontadores?)EstendidosLing. de Prog. Em BD

Roteiro

DefiniçãoPersistênciaObjetos ComplexosEncapsulamentoClassesHerançaLing. de Programação e Consulta

Roteiro

Definição (cont)Completeza computacionalControle de TransaçõesExtensibilidadeRelacionamentosControle de ConcorrênciaRecuperação de Falhas

Roteiro

Análise GeralRelacionamentosLinguagens DDL e DMLFalta de PadrãoViolação do EncapsulamentoModo Formal Incompleto

Roteiro

O PostGresRelacional EstendidoObjetos, OIDs, Herança (simples e múltipla)PostQuel (Quel OO)ADT (Abstract Data Type)Declarações de Dados

Roteiro

O PostGres (cont)Manipulação de DadosRegras

Conclusão

Orientação a Objetos

O que é um objetoAlguma coisa que faz sentido no contexto da aplicação.Podem ser definidos como um conceito, abstração ou simplesmente algo que tenha significado bem definidoObjetos servem a dois propósitos: Prover entendimento do mundo real e dar uma base prática para a implementação


O que é um objetoA decomposição de um problema em seus objetos depende de preferências e julgamentos pessoaisTodo objeto tem identidade e é distinguível dos seus semelhantesObjeto: Uma Coisa. Classe: Conjunto de Coisas


O que é um objetoClasses: Árvores, Árvores Frutíferas, Árvores Ornamentais, Empregados, FornecedoresObjetos:“A mangueira do quintal da minha avó”, “José da Silva, Professor, nascido em 14/07/1963” e “Microsoft Corporation”


Classes“É um conceito que descreve um grupo de objetos com propriedades (atributos) similares, comportamentos (métodos), relacionamentos (associações) comuns com outras classes e principalmente, semântica semelhante “ Rumbaugh• Parêntesis são notas minhas


ClassesSe o foco da modelagem é objeto, porque perder tempo com classes?O agrupamento de objetos em classes permite a abstração do problema!Prerrogativa de generalizar a partir de poucos casos específicos


ClassesAs definições são armazenadas uma por classe, não uma por instânciaAs operações também são definidas para a classe, de forma que seus objetos possam reutilizá-lasTomando por exemplo a classe Pessoa


ClassesPode ser necessário saber que uma pessoa (qualquer) possui: Idade, Nome, Endereço e, possivelmente Cônjuge, Emprego e FilhosQualquer pessoa, também, tem os comportamentos de Casar, Separar, Ter Filhos, Aniversariar, Se mudar ...


ClassesIsso é verdade para todas as pessoas que eventualmente sejam inseridas nesta classeAinda que o valor de cada informação possa ser modificado a cada caso, a forma de descrição é a mesma


ClassesJosé pode ter 34 anos, morar na Rua das Flores, não ter cônjuge, trabalhar como vendedor na Sapataria Vianna e ter uma filha, a Maria. Antônio pode ter 51 anos, morar na Rua da Independência, ter uma esposa (Helena), trabalhar como gerente na Sapataria Vianna e ter dois filhos: Pedro e Ricardo


ClassesJosé e João são, nesta abordagem, objetos de uma mesma ClasseObjetos de uma classe tem os mesmos atributos e comportamentos padronizados • não necessariamente iguais, como vai se

ver


ClassesOs objetos de uma classe normalmente se diferenciam pelos seus atributos e relações com outros objetos Mas dois objetos podem ser idênticos em seus atributos e relações, mantendo ainda assim cada um a sua individualidade


ClassesPor exemplo um sistema de pesquisa por amostragemCada pessoa entrevistada te seu nome mantido no anonimato. É um objeto da classe EntrevistadoUma classe “Entrevistado” possui os atributos “Cor”, “Naturalidade”, “Idade”, “Faixa Salarial” e “Sexo”.


ClassesPodem existir inúmeras instâncias de objetos com os mesmos valores (Negra, Itabuna/BA, 22, 0 a 300 Reais, Feminino)Apesar disso, cada instância é única – e pode ser referida unicamente no sistema


ClassesOs objetos de uma classe compartilham uma semântica comum, mais que atributos e métodos comuns


ClassesPor exemplo, um objeto da classe Roupa e um objeto da classe Carro podem ter os atributos Cor e Fabricante. Porém, olhados sob a perspectiva dos mais variados sistemas terão, certamente, que ser colocados em classes distintas

• Exceto no caso de um sistema bastante excêntrico - não consegui pensar em nenhum caso que Cor e Fabricante fossem relevantes ao mesmo tempo em que roupas e carros pudessem ficar numa mesma classe.


ClassesCada objeto sabe a que classe pertence, Isto é tão natural que muitas Linguagens Orientadas a Objeto implementam um atributo interno que informa a classe do objeto.


Como identificar classes. Iniciando a modelagem

Classes são coisas que deverão existir dentro do sistema. Logo, devem representar coisas do mundo real Normalmente aparecem como nomes nas sentenças que definem o mundo a ser modelado (a se ver em UML)



Deve-se observar que nem todos os nomes das sentenças são classes É interessante ressaltar que a observância dessas regras pode resultar no surgimento/desaparecimento de classes no decorrer do processo



A orientação a objetos sugere que o processo de análise seja feito em espiralcada etapa pode ser re-visitada inúmeras vezes, e a cada destas se acrescenta novas características



Lembrança Necessária: É necessário lembrar de alguma coisa sobre os objetos da classe? Processamento Necessário: Há algum comportamento relevante dos objetos?



Atributos Múltiplos: Duvidar de classes que não tenham pelo menos dois atributos.Mais de um objeto por classe: Duvidar de classes que tenham somente um objeto



Atributos sempre aplicáveis: Deve haver um conjunto de atributos possível de se imaginar para os mais diferentes objetos da classe.• Caso o conjunto seja sempre o mesmo

ok. Caso contrário, deve se tratar de Generalização


Classes, no diagrama de casses, devem ser colocados num retângulo dividido em três partes, a primeira com seu nome

Pessoa Empresa


Como identificar Atributos Atributos são informações específicas de propriedades de um objeto que são relevantes para o sistemaPara identificar os atributos, deve-se olhar para as classes identificadas e imaginar as responsabilidades do sistema.• O que é necessário saber sobre quem, a

qualquer tempo.


Como identificar Atributos Atributos devem ser um valor de dados puroNão se pode permitir que um atributo seja um outro objetoMas podem ser multivaloradosOs atributos vão ser listados na segunda parte do retângulo da classe


Identificadores Naturais e Artificiais

Existem atributos que são naturalmente identificadores únicos de objetos: Placa, CPF, etc.Os BD Relacionais usam identificadores únicos, naturais ou artificiais, para reconhecer um objeto (uma tupla).


Identificadores Naturais e Artificiais Aqui se deve esquecer a questão: Atributos nunca são identificadores únicos• Ainda que não ocorram mais de uma vez e

eventualmente sejam usados assim na implementação.

• Chaves primárias são considerações de projeto.

• E em BDs Relacionais


Identificadores Naturais e Artificiais

Portanto, RG, Placa, Chassis são atributos perfeitamente válidos. Mas Usuário_ID, CodPaciente NumCliente são erros


Generalização Uma classe deve ter atributos ou métodos específicos para objetos bem definidosPor exemplo, uma classe “Figura Geométrica” Atributos “Posição_Centro”Métodos “Desenhar()” e “Área()”.


Generalização Mas para figuras diferentes, a forma de calcular a área muda de acordo com o tipo Círculo e RetânguloAlém disso, atributos também sofrem mudanças Círculos precisam de “Raio” e retângulos precisam de “Base” e “Altura”


Generalização “Círculo” e “Retângulo” são, portanto, candidatos naturais a serem generalizados na classe “Figura Geométrica”Regra Geral: “Se duas (ou mais) classes tem semântica semelhante, e um ou mais atributo ou método e comum (mas não todos, pois seriam a mesa classe!), dêvem ser conjugadas como especialização de uma terceira”


Generalização Analogamente, “Se uma classe tem um (ou mais de um) conjunto de atributos ou métodos que são empregados apenas em ocasiões específicas, deve ser dividida em uma ou mais especialização”.Em ambos os casos, os atributos ou métodos que forem comuns devem ser colocados na classe geral, restando para as especializações aqueles que forem do seu escopo


Generalização Generalização e Especialização provêem uma série de vantagens, ligadas à herança e reutilização de código – A se ver em UML


Associações entre ClassesNo levantamento das classes ou dos atributos, pode-se perceber que há relações entre duas ou mais classesAs associações complementam a informação do objeto com mapeamentos necessários para que ele possa de fato cumprir seu papel


Associações entre ClassesSão semelhantes aos relacionamentos do MERPossuem cardinalidade • Um para Um • Um para muitos • Muitos para muitos


Associações entre ClassesE opcionalidade • As associações podem ou não obrigar

cada objeto a se associar com algum outro, de acordo com as regras da cardinalidade

A notação para cardinalidade e opcionalidade não será mostrada – A se ver em UML


Associações entre ClassesAs associações podem ser percebidas a partir dos atributos: Por exemplo, uma classe “Filme” tem, entre outros, o atributo “Diretor”. Há uma classe “Diretor”, aojando objetos deste tipo A classe filme ganha uma associação com a classe diretor: “Dirigido por”.


Associações entre ClassesNo nosso exemplo, os atributos agora estão colocados. As associações idemObservá-las entre Pessoa e Empresa (“trabalha em”), e mesmo entre Pessoa e Pessoa (“filho de” e “Casado com”).


Associações entre ClassesPessoa

NomeIdadeEndereço

Empresa

RazãoSocialEndereçoTrabalha

em

Filho de

Casado com


Como identificar Métodos Um método é uma função de transformação Pode ser aplicada por ou para objetos em uma classeApós a execução de um método, algum tem sempre seu estado alterado (ainda que para mesmo, mas houve a transformação)


Como identificar Métodos Exceto em três métodos especiais Criar, que é um método específico da classe, e que especifica que uma nova instância passa a existir.Destruir, que, similarmente, exclui uma instancia daquela casse • destruir deve ser aplicado ao objeto, ao

contrário de criar


Como identificar Métodos Pegar_*, que são métodos que permitem o acesso aos atributos. Dispensáveis, para efeito de desenvolvimento (para que usar X := Mostrar_Nome(Empregado) se se pode fazer X := Empregado.Nome?)


Como identificar Métodos Muitos autores recomendam o uso destes tipos de método para esconder a implementação interna do objeto Em caso de modificações específicas, não estender alterações por outros objetos – enfraquecer o acoplamento


Como identificar MétodosOs métodos fica na terceira e última parte do retânguloEm alguns casos, uma mesma operação pode ser aplicada, com adaptações específicas, a diferentes classes. Esta propriedade é chamada polimorfismo.


Como identificar MétodosO exemplo do cálculo da área de figuras geométricas é um cãs de polimorfismoA área de um círculo, de um triângulo, de um retângulo e de um trapézio são calculadas, embora com semântica idêntica, de formas totalmente diferentes


Como identificar MétodosPara se identificar métodos, deve-se levantar as funções que altera o estado de um objeto Isso sugere o uso de métodos Fazer_* para cada atributo modificável pelo sistema, o que normalmente é válido


Como identificar MétodosHá métodos que criam ou modificam uma associação com outros objetos Estas associações precisarão respeitar a semântica de cardinalidade e opcionalidade que tenha sido definida entre as classes


Como identificar MétodosFinalmente, existem métodos que, para serem executados, recorrem a métodos de outros objetos. Por exemplo, um objeto “CNH”, num sistema do Detran, tem o método “Emitir” CNH se associa, um para um, com Condutor


Como identificar MétodosEste método verifica os resultados do exame do condutor e, caso esteja tudo em ordem, libera os dados para impressão.Um Pedido, portanto, deve ser enviado ao objeto específico da classe “Exames” que armazena exames de condutores, solicitando o serviço (que deverá existir) “Verifica_Aprovação”.


Como identificar MétodosEste método verifica os resultados do exame do condutor e, caso esteja tudo em ordem, libera os dados para impressão.Um Pedido, portanto, deve ser enviado ao objeto específico da classe “Exames”


Como identificar MétodosA classe “Exames” armazena os exames dos condutores a serem emitidas a CNHÉ solicitando o serviço (que deverá existir) “Verifica_Aprovação”. A essa solicitação chamou-se Mensagem


No nosso exemploPessoa

NomeIdadeEndereço

Casar(Pessoa)Separar()TerFilho(Nome)Aniversaria()Mudar(NovEnd)

Empresa

RazãoSocialEndereço

Contrata(Pessoa)Demite(Pessoa)

Trabalha em

Filho de

Casado com


Alguns métodos merecem ser descritos (em pseudocódigo) para ilustrar a simplicidade e a troca de mensagens Pessoa.Casar(x) {x é um objeto do tipo pessoa}

Este.CasadoCom x; {Este se refere ao próprio objeto}

X.CasadoCom Este

Orientação a ObjetosPessoa.Separar()

XEste.CasadoCom;

X.CasadoCom Nulo

Este.CasadoCom Nulo

A relação “Casado com” está definida bilateralmente, o que é incorreto para efeitos de projeto mas foi empregado aqui por motivos didáticos.

Orientação a ObjetosPessoa.TerFilho(NomeFilho)

X Pessoa.Criar()X.Nome NomeFilho {ou X.Altera_Nome(NomeFilho)}X.Idade 0 [ou X.Altera_Idade(0)}X.Endereço Este.Endereço { ou ...}

Pessoa.Aniversaria()Este.Idade Este.Idade + 1 {aqui não é necessário chamar

método, pois estamos “dentro” do mesmo objeto}

Empresa.Contrata (X)X.TrabalhaEm Este

Orientação a ObjetosPessoa.TerFilho(NomeFilho)

X Pessoa.Criar()

X.Nome NomeFilho {ou X.Altera_Nome(NomeFilho)}

X.Idade 0 [ou X.Altera_Idade(0)}

X.Endereço Este.Endereço { ou ...}

Pessoa.Aniversaria()

Este.Idade Este.Idade + 1 {aqui não é necessário chamar método, pois estamos

“dentro” do

mesmo objeto}


Mensagens entre classesÉ útil indicar, no modelo a dependência de um objeto, de métodos de outroUma seta, partindo do objeto que solicita, pode deixar isso evidenteDiagramas alternativos pode ajudar – a se ver em UML

BD Orientado a Objetos.

FIM!

“Deixadas a si mesmas, as coisas irão de mal a pior. A natureza conspira pela falha. Posto que a natureza é canalha,

para algo dar certo é preciso deixar de fazer por onde”Lei de Murphy aplicada à Metafísica

BDs Orientados a Objeto

HistóricoHistoricamente os sistemas de Bancos de Dados caminharam abraçados à tecnologia mais difundida.Assim que surgiram, BDs estavam suportados em MainFrames.


HistóricoPara compreender melhor é necessária uma rápida visita à arquitetura MainFrame:

Aplicação

SGBD

BD

Terminal

MainFrame


HistóricoO usuário tem diante de si um terminal cuja função única é entrada e saída de dadosA aplicação (que está no MainFrame) acessa o SGBD, que cuida do BD em todos os aspectos, conforme mostrado.


HistóricoOpcionalmente a aplicação poderia acessar diretamente os arquivosO MainFrame permitia a execução de muitos programas ao mesmo tempoCompartilhar um único arquivo através da estratégia de Time SharingUma fatia de tempo para cada processo, assim todos estavam sempre sendo executados


HistóricoAs vantagens desse modelo eram a segurança e a integração, pois os sistemas estavam suportados numa única plataforma de HW e SWA principal desvantagem era o custo. Os MainFrames muitas vezes eram até alugados


HistóricoCom a popularização e o barateamento dos microcomputadores, surgem os sistemas menores, que acessavam arquivosNa prática, é importante ressaltar, não há ação de um SGBD, pois os aplicativos acessam o arquivo de dados diretamente


HistóricoEsta estratégia ganhou força com o aparecimento do Dbase, fabricado pela Aston Tate, que trazia inúmeras facilidades de manipulação interativa de dados, usando os famosos arquivos .DBF. Aston Tate hoje é Borland Inc.


HistóricoFenômeno 1: Popularização das redes locais de computadores, Fenômeno 2: Aparecimento das versões mais populares dos sistemas operacionais de rede, Conseqüência: A orientação mudaria um pouco


HistóricoO servidor de arquivos

EstaçõesServidor de Arquivos


HistóricoProvia mecanismos de compartilhamento de arquivos por mais de um processo Estando, inclusive, em máqinas diferentes Semelhante ao que o MainFrame fazia Um aplicativo agora podia acessar os arquivos compartilhando-os com outros


HistóricoOs aplicativos cuidariam de acessar o servidor a partir de muitos pontosAtendendo a diversos usuários como o MainFrame, mas a custo bem inferiorAlém disso uma estação de trabalho tinha vantagens sobre o terminal “burro”


HistóricoAs desvantagens eram todas ligadas ao fato de que não havia um SGBD, Os dados ficavam à mercê das aplicações para ter seus aspectos de segurança e integridade respeitados E Concorrência?


HistóricoEste modelo arquitetural de Banco de Dados ficou conhecido como Sistemas tipo Servidor de ArquivosA partir das criticas feitas ao modelo tipo Servidor de Arquivos surge uma alternativa, a instalação de um SGBD para atender a todos. Ou seja, criar um Servidor de Banco de Dados.


HistóricoA arquitetura fica um pouco mais parecida com a do MainFrame, A diferença é que a aplicação agora funcionaria em outra máquina (na verdade poderia ser na mesma) Seria cliente do serviço prestado pelo SGBD, ou seja, acesso aos dados.


HistóricoModelo Cliente-Servidor

EstaçõesServidor de Banco de Dados

SGBD

BD

Aplicativo

Aplicativo

Aplicativo


HistóricoA principal vantagem é que o Servidor de BD implementava os aspectos de ConcorrênciaIntegridadeSegurançaRecuperação de falhas


HistóricoA desvantagem surge ironicamente do fato que levou muita gente a se afastar da arquitetura MainFrame: A Estação ClienteArgumento dos detratores do MainFrame:Aplicações nas pontas permite-se rodar aplicações em máquinas muito mais baratas. Isso é realmente um fato


HistóricoOs problemas: Manutenção das aplicações: cada nova versão tinha que ser instalada em muitas máquinas, e isso começou a representar um custo excessivo Dependência tecnológica: Escolhido o SO e o SGBD, qualquer mudança teria custos por vezes proibitivos


HistóricoPor outro lado, a crescente sofisticação das aplicações exigia investimentos pesados no fortalecimento do poder de processamento dos clientesPassou-se a olhar, então, esta arquitetura como um modelo em duas camadas:


HistóricoCliente processa dados e apresentação Cliente se conecta diretamente aos servidores. Cliente “Robusto” (e caro) Aplicações grandes, e baixa reutilização Dificuldade na distribuição das versões


HistóricoA solução Implementar múltiplas camadas (no mínimo 3) a invés de apenas duas.


HistóricoApresentação, Lógica do Negócio e Acesso a Dados.Cliente “Magro” Serviços da camada de negócios compartilhados Atualização de versões centralizado Independência de Plataforma


HistóricoA grande modificação fica no cliente “magro”Opcionalmente (e normalmente é uma boa idéia), pode-se quebrar a camada intermediária (Lógica do Negócio) e a de acesso a dados em componentes (ou objetos)


HistóricoObjetos de lógica do negócioEncapsulam regras de negócio do mundo real independente de como os dados estão armazenadosUsualmente possuem múltiplas operações acessando vários objetos de dados


HistóricoObjetos de acesso a dados Deve ser o único meio de acesso a dados (incorpora especificamente a DML do Banco de Dados)Provê um conjunto de métodos que permitem lhe serem solicitados serviços


HistóricoNecessidade: Mapeamento Objetos de Dados – Objetos de NegócioO modelo é, então, estendido para N camadasÉ possível, se desejável, até a re-inclusão do próprio MainFrame na estrutura

BDs Orientados a ObjetoHistórico

Multicamadas


HistóricoO SGBD não “vê” a estrutura complexa que se construiu ao seu redor.Os acessos aos dados, do ponto de vista do SGBD permanecem da mesma formaA camada de acesso a dados atua como cliente do servidor de Banco de Dados


HistóricoO cliente pode ser tão magro quanto possível. Idealmente, trata-se apenas de um navegador WebPela Web, as conexões podem ser feitasNo cliente funciona apenas um componente (ASP, Java, ...) Provê a visualização, e a entrada/saída de dadosQuase um terminal do MainFrame, mas executa efetivamente processos.


HistóricoAo ser ativado o processo (componente)Verifica-se se a data do que está instalado é defasada em relação ao do servidorEntão houve uma atualizaçãoA versão mais recente é transportada automaticamente


HistóricoVantagensPode-se trocar de plataforma com propagação mínima de efeitos colaterais• Ex. Para trocar o SGBD é necessário apenas

um ajuste nos objetos de acesso a dados.

Atualizações de versões automáticas e imediatas, sem a necessidade de reinstalação on site.


HistóricoOs componentes podem (e tendem a) ser projetados preservando-se os princípios de encapsulamento – Como?Os problemas de coesão baixa e acoplamento alto precisam ser minimizados – Como?


HistóricoPreserva-se o legado do MainFrame, do qual muitas organizações nunca puderam se desfazer.O cliente magro pode ter uma capacidade de processamento mais modesta, o que diminui os custos.Esta estrutura, é conhecida como Servidor Web.


HistóricoMas alguma coisa havia mudadoA necessidade de componentes e de encapsulamentoEste ambiente é o natural para a orientação a objetos.Os ambientes de programação precisam ser OO – além de gráficos


HistóricoJava começa, então, a ganhar muito espaço neste contexto. Surgem aplicações visuais JavaProvêem todas as facilidades dos ambientes de Visual Basic e DelphiMais Orientação a Objetos


HistóricoContra a força de Java a Microsoft propõe padrões proprietários, integrados ao Visual Basic, mas encontra resistênciaDelphi, por sua vez, passa a ser aproveitada nos conceitos de Orientação a ObjetoSistemas distribuídos em Java, Delphi e Visual Basic vão se multiplicando a cada dia


HistóricoOs SGBDs acompanharam essa evolução, mudando tambémAté 1960: Sistemas de Arquivos Integrados – ISAM, VSAM (IBM).Crítica: pouco encapsulamentoControles de segurança, concorrência, integridade e recuperação de falhas ficavam a cargo dos programas aplicativos


HistóricoSe houvesse alguma modificação no modelo, como garantir que todos os programas respeitariam a “nova ordem”? Muito trabalhoso!Final dos aos 60: Modelo hierárquico – IMS (IBM).


HistóricoUma estrutura de registros pai-filho dispostos em seqüência, implementando relação um para muitos de cima para baixoImplementava regras de integridade, embora com limitações, e aspectos de segurança, recuperação de falhas e controle de concorrência


Histórico1970 e início dos anos 80: Modelo de redes (Codasyl) – IDMS, DBMS-II (Unisys).Extensão do modelo hierárquico, com relações muitos para um estabelecidas e todas as direções.Modelava toda sorte de relacionamentos com facilidade.


HistóricoFinal dos anos 70: Modelo Relacional (Codd) – SQL-DS, DB2, (IBM), Oracle, Ingres.Relação entre dados, não através de estruturas internas do bancoModela, como o em Rede, toda sorte de relacionamentos


BDs Relacionais X RedesRelacionais Tem performance inferior ao em RedesMas tem linguagens DDL e DML como Quel e SQL mais simples. Fator decisivo.São dominantes hojeFinal dos anos 80: Modelo reacional-estendido. Orientado a Objeto. BDOO, O2, Oracle (a partir da versão 9) ...


SQLO argumento decisivo a favor dos relacionaisFácil de usarEficiente EficazPadrãoConsagrada em todos os produtos hoje


HistóricoMas não há sentido em migrar dos relacionais para os Orientados a ObjetosCustosCulturaTreinamento


BDOO – Objetos (Apontadores)Vantagens prometidas:Simplicidade – BDs OO estão para BDs Relacionais como Java está para CPromessa: A performance de BDs em rede sem a complicação da operação de endereços internos


Relacionais EstendidosUm BD relacional sob uma casca orientada a objetoOIDsMétodosClassesEx: PostGres


Linguagens de Programação de BDsExtenção de C++, SmallTalk ou Java com Persistências de ObjetosControle de Transações e ConcorrênciaPossui (normalmente) uma linguagem proprietária para DDL e DML

Características

O que define um BDOO?Discussão indefinidaDefinição (Atkinson, 1989)

Características

Um BDOO deverá prover:Persistência, Objetos Complexos, Identidade, Encapsulamento, Classes, Herança, Linguagens, Completeza, Transações, Extensibilidade, Relacionamentos, Concorrência, Tol. Falhas? ? ? ? ? ? ? ? ? ? ? ? ?

• Objetivos de BDs tradicionais + OO

Características

PersistênciaCaracterística principal para diferenciar BDOO de LPOO

Problema: Como definir o que deve e o que não deve ser persistente?

Características

Declaração de Persistência: depende do SGBD

O2 – “name” torna o objeto persistente

Poet – Classes definidas como persistentesObjectStore – Quaisquer objetos podem ser persistentes: definido em sua construção

Características

Especificamente: Objetos podem ser persistentes das seguintes formas:

Por classe – uma classe é declarada persistente (Poet)Por chamada – na criação do objeto um comando o torna persistente (ObjectStore, O2)Por referência – Objetos referenciados por objetos persistentes também o são

Características

Qual a melhor alternativa?Ortogonalidade entre tipos e persistência

Por classe – não há ortogonalidadePor chamada – perfeitamente ortogonal

Características

Objetos ComplexosObjetos complexos: Todos-Partes, Associações Múltiplas

No MR: muitas tabelas!

Propõe-se a utilização dos modelos das LPOO

Características

Não é necessário respeitar a 1FN!Objetos podem não ser atômicos: Listas, conjuntos, vetores, outros objetos, etc.

Em LPOO isso é uma vantagem! Mas nos SGBDRs não se pode aproveitar!

Características

Identificador de Objeto (OID)Nas LPOO: Objetos momentâneos e “proprietários”Nos BDOO: Objetos persistentes e “compartilhados”Em BDOO há a necessidade de uma identificação muito mais forte!

Características

Único e imutável durante toda a existência – não apenas na “sessão”OIDs são identificadores únicos e válidos em todo o BD

RecuperaçãoAssociações

“Invisíveis” e “Intocáveis” pelo usuário

Características

EncapsulamentoConceito é importante para a OOEm BDOO: Acesso não aos atributos, mas a métodosImpossível prever todos os acessos necessários para criar os métodos! As necessidades são dinâmicas!

Características

“Abrir” os atributos a uma Linguagem de Consulta

Quebra do encapsulamento

Admite-se que o encapsulamento “nem sempre” é adequado aos BDOOEncapsulamento: característica básica da OO

Características

Normalmente se “copia” a solução encontrada em C++

Permite-se que atributos sejam “públicos”, e não somente métodos

E usa-se linguagens de consulta parecidas com SQL

Características

LinguagensNum Banco de Dados Relacional há linguagens deConsulta – SQL, QBE, Xbase, Quel...Programação – PL/SQL, TransactSQL, Dbase...E num BDOO?

Características

Linguagens de ConsultaConsultas ad hocSem maiores complicações – “feita” para quem já usa SQLAcessam atributos e métodosViolam o encapsulamento

Características

Linguagens de ProgramaçãoTentam resolver um problema antigo nos SGBDR – Não-Casamento de Impedância (Impedande Mismatch)

Impedande Mismatch refere-se à complexidade das estruturas de dados das linguagens X estruturas de dados nos SGBDR

Características

Para resolver:Compatibilizar dados obtidos nos acessos com as estruturas da linguagemTabelasStructs, Listas, Matrizes, etc.

Características

Num SGBDR: Tabelas (Relações)Num programa em Delphi(Pascal): Record – Vários níveis

Um registro Departamento com listas de professores, projetos de pesquisa e áreas de interesseTabelas: Departamento, Professores, Projetos e Áreas de Interesse

Características

Para gravar:Cada parte do objeto é processada à parte – indo para seu local determinado

Para ler:Operação inversa: Leituras de partes em separados para organização centralizada

Desestruturação e Reestruturação

Características

A proposta é usar uma LPOO que acesse os dados no BDOO (objetos persistentes)

Não há impedânciaDiminuição e Simplicidade de códigoDiminuição de Tempo de ExecuçãoCompartilhamento de estruturas

Características

Completeza ComputacionalNem todas as consultas podem ser feitas com linguagens de consultaA questão do Auto-RelacionamentoNão são implementações completas da Máquina de Turing!

Características

Solução: Programação em SGBDsUma Linguagem de Programação completa

Desvios condicionaisRepetiçãoSubprogramaçãoRecursividade

Características

Em SGBDOO o problema é o mesmoLinguagens de Programação OO são “nativas” aos SGBDs

Muitos deles são LPOO estendidas para objetos persistentes!

As linguagens de consultas em BDOO – o mesmo problema

Características

Controle de TransaçõesNos Bds tradicionais:

O mais rápido possívelA interrupção de uma transação no meio é indesejávelAtômica

Características

Nos BDOOO tempo depende da natureza da aplicaçãoA interrupção de uma transação no meio pode ser necessáriaNão-Atômica

Características

Recuperação de FalhasBDs tradicionais:

Redo das transações completasUndo das transações incompletas

Características

BDOO:Redo das transações completasRedo do que for possível das transações incompletas

Estudos para se ajustar a teoria ded BD aos requisitos de BDOOPossivelmente o estabelecimento de uma nova técnica de Recuperação de Falhas

Características

ExtensibilidadeTipos tradicionais: Inteiros, Reais, Strings, Data, etc.Predefinidos com operações sobre elesTipos criados pelo usuário: mesmas característicasAinda que apenas sob o ponto de vista do usuário

Características

RelacionamentosNão há um elemento para representarA tecnologia aponta para variáveis de instânciaArmazenam OIDs de objetos relacionados

Características

ExemploO objeto Automóvel possui, entre outras variáveis, a variável ProprietárioProprietário contém o(s) OID(s) do(s) dono(s) do automóvelIsso permite referenciar algo como:X = carro->proprietario->endereco

Características

CríticaA variável fica misturada aos atributos “naturais”Parece com uma chave estrangeiraNão há uma especificação de que se trata de uma associaçãoDá a impressão de se tratar de uma relação Todo-Parte

CaracterísticasProblemas as associações N para N

Caso muitos automóveis possam pertencer a um mesmo proprietário, e reciprocramente:Proprietário conterá uma variável Automóvel e Automóvel uma variável ProprietárioCaso o relacionamento tenha atributo ele deverá aparecer dos dois lados (data aquisição)

Características

Integridade ReferencialA exclusão de um automóvel implica emNulidade da variável Automóvel em que este OID aparecia – como por hipótese na classe Proprietário

Características

BDOO distribuídoÉ possível – a tecnologia de BDs distribuídos é perfeitamente compatível com BDOOExemplo: ORION-2

Críticas

Porque se usa LPs Orientadas a Objeto e não se usa BDs Orientados a Objeto?CulturaPlataforma InstaladaPouca necessidade de ComponentesFaltas nos aspectos Técnicos

Críticas

RelacionamentosNão são declarados explicitamenteUsa-se Atributos “Especiais”Relações 1-N e N-N: Referências Cruzadas• Atributos em objetos auxiliares ou em

ambos os lados

Críticas

RelacionamentosLinguagens de Consulta não reconhecem Relacionamentos• SQL também não

Relacionamentos entre Classes = Relacionamentos entre Entidades• A única diferença: 1FN• Simlpifica p/ objetos complexos

Críticas

Linguagens DDL e DMLArgumento dos defensores dos BDOO: “Com LPs e objetos persistentes é desnecessário aprender uma nova linguagem”Aprender novas linguagens hoje é muito fácil e rápido

Críticas

Linguagens DDL e DMLLinguagens Algoritmicas: Retrocesso à 3a Geração• SQL: O que se quer• C++: Como se faz

Críticas

PadronizaçãoAbsolutamente não háModelo de Dados: Uns tem Herança, Uns tem Polimorfismo, Uns tem Associação N-N, outros nãoMigração?

Críticas

PadronizaçãoODMG (Object Database Management Group)Produtores de: GemStone, Orion, O2, ObjectStore, Objectivity, Poet, UniSQL e VersantTentativa de criar padrõesNova e incipiente

Críticas

PadronizaçãoNormalmente os BDOO surgem voltados para aplicações específicasInteressante: Cactis - Aplicações CASE• Transações muito especiais

Críticas

EncapsulamentoVioladoLinguagens de consulta derivadas de SQLAcesso direto ao atributoAlteração (UPDATE) direto no atributoBombardeada pelos críticos mais puristas

Críticas

Encapsulamento“O fato de o encapsulamente ter que ser relaxado aponta para a inaplicabilidade da programação orientada a objetos em Bancos de Dados”Não seriam, portanto, propriamente Orientados a Objeto

Críticas

FormalismoO modelo relacional é formalAssociações, Projeções, Junções: Rigorosamente demonstradosÁlgebra RelacionalE em BDOO?

Críticas

FormalismoA Álgebra Relacional não se aplicaDois caminhos:Adaptação: Afronta a orientação a objetos (como no encapsulamento)Desenvolvimento de um novo formalismo: Pesquisa pura, com resultados incertos e a longo prazo

PostGres

Desenvolvido na Universidade de BerkeleySucessor do INGRESAtualmente: Miro (Comercial)

PostGres

Versão não comercial disponível no site da universidadeEscrito em C180.000 linhas de código

PostGres

Relacional EstendidoObjetosOIDs “tradicionais”Objetos CompostosHerança MúltiplaVersões

PostGres

Dados históricosLinguagem de consulta

PostQUEL – extensão da linguagem QUEL do INGRES

PostGres

Dados históricos:Pode-se consultar sobre o estado do banco em um determinado momentoArmazena o estado do BD depois ded cada alteração

PostGres

Modelo de dados baseado no relacionalADT (Abstract Data Type) – disponível para que se possa definir um novo tipo DatabaseTodos os demais são derivados deste

PostGres

Fornece um OID para cada elemento da relação – “mapeando” tabelas em objetosComo criar classes e objetos?

PostGres

O projeto:Pessoa

NomeIdadeEndereço

Casar(Pessoa)Separar()TerFilho(Nome)Aniversaria()Mudar(NovEnd)

Empresa

RazãoSocialEndereço

Contrata(Pessoa)Demite(Pessoa)

Trabalha em

Filho de

Casado com

PostGres

Declaração:Create empresa (CNPJ char [15],

razaosocial = char[25],Endereço = char[30],Pessoas = postquel)

Key (CNPJ)

PostGresDeclaração:Create pessoa ( RG (char[11],

nome = char[25],Idade = int,endereco = char [50],empregador = empresa,Filhode = pessoaCasadocom = pessoa)

Key (RG)

PostGres

Herança

Create PrestServico (precohora = float)

Inrerits (pessoa)

PostGres

Herança múltiplaCaso se ponha mais de uma classe no comando inheritsCaso haja conflito de nomes de atributos retorna um erro.

PostGres

Tipos de dados PostQuelServem para executar um método que faz o acesso ao relacionamentoUma consulta feita em PostQuel

PostGres

Key define um atributo como OIDPode haver mais de um atributoNenhum pode ser nulo e eles não irão se repetirImplementação idêntica à de chave primária do modelo relacional

PostGres

Key define um atributo como OIDPode haver mais de um atributoNenhum pode ser nulo e eles não irão se repetirImplementação quase idêntica à de chave primária do modelo relacional

PostGres

Onde está a diferença?Pode-se usar um tipo definido pelo usuárioPor exemplo, usar o par (empregador, matricula)Empregador é do tipo empresaComo comparar empresa?

PostGres

Cria-se uma funçãoDefine function há_emp(e = empresa)Return int asRetrieve any(empresa.allWhere empresa.cnpj = e.cnpj

Key empregador using há_emp, matricula)

PostGres

Manipulação de DadosPostQUEL contem os comandos append, replace e deleteAppend to pessoa (nome = ...)Delete pessoa where ...Replace pessoa (nome= ... ) where ...

PostGres

Percurso do fecho transitivo de um esquemaCaracterística do postquel em extensão a quelMostrar todos os ancestrais de José

PostGres

A consultaRetrieve * into classeresposta(pessoa.filhode) from a in classerespostaWhere pessoa.nome = “José”Or pessoa.nome = diznome(a.filhode))

* obriga que a consulta será executada até não retornar mais dados

PostGres

A consultaRetrieve (e.nome) from e in pessoa*Where e.nome = “José”

* aqui obriga que a consulta seja executada em todas as subclasses da classe pessoa

PostGres

A consultaRetrieve func.salarioFrom func[D]Where func.nome = “José”

Retorna o salário de José na data D

PostGres

RegrasAção executada no banco sob ordem de determinado eventoOn evento to objeto where condiçãoThen do [instead]comandos

PostGres

Evento pode serRetrieveReplaceDeleteAppendNew (replace ou append)Old (delete ou replace)

PostGres

Objeto é o nome de uma classe, ou do atributo de uma classeCondição é um qualificador qualquer usado em PostQUELInstead indica que o comando deve substituir, e não acompanhar o evento que gerou a regra

PostGres

Podem se referenciar a new e current em lugar do nome da classe

New é o novo valor (caso de inclusões ou alterações)Current é o valor atual (caso de exclusões ou alterações)

Refuse: indica o cancelamento do evento (Rollback)

PostGres

Exemplo:O Salário de um funcionário no cargo de professor deve ser igual ao de JoséOn new funcionario.salario where

funcionario.cargo = “Professor”Then do replace new.salario = c.salarioFrom c in cargosWhere c.nome = “Professor”

PostGres

CríticasMétodos implementados em funções – não nas classesNão implementa OIDs naturaisRelacionamentos se confundem com variáveis de instânciaPadrão proprietárioViola o encapsulamento

PostGres

QualidadesHerança e Herança múltiplaVersões de dados ao longo do tempoCompleteza implementada em PostQuelAceita tipos definidos pelo usuárioÉ baratinho...

PostGres.

FIM!

“Numa democracia, o direito de ser ouvido não inclui automaticamente o direito de ser levado a sério”

Hubert Humphrey

bancos de dados orientados a objetos

Documents