bancos de dados orientados a objetos
DESCRIPTION
Bancos de Dados Orientados a Objetos. Álvaro Vinícius de Souza Coêlho [email protected]. Roteiro. Orientação a Objetos Conceitos Como Identificar Classes e Objetos UML Casos de Uso Objetos e Classes. Roteiro. UML (cont) Atributos Associações Diagramas de Colaboração - PowerPoint PPT PresentationTRANSCRIPT
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
Orientação a Objetos
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
Orientação a Objetos
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”
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
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 ...
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
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”.
Orientação a Objetos
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
Orientação a Objetos
ClassesOs objetos de uma classe compartilham uma semântica comum, mais que atributos e métodos comuns
Orientação a Objetos
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.
Orientação a Objetos
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.
Orientação a Objetos
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)
Orientação a Objetos
Como identificar classes. Iniciando a modelagem
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
Orientação a Objetos
Como identificar classes. Iniciando a modelagem
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
Orientação a Objetos
Como identificar classes. Iniciando a modelagem
Lembrança Necessária: É necessário lembrar de alguma coisa sobre os objetos da classe? Processamento Necessário: Há algum comportamento relevante dos objetos?
Orientação a Objetos
Como identificar classes. Iniciando a modelagem
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
Orientação a Objetos
Como identificar classes. Iniciando a modelagem
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
Orientação a Objetos
Classes, no diagrama de casses, devem ser colocados num retângulo dividido em três partes, a primeira com seu nome
Pessoa Empresa
Orientação a Objetos
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.
Orientação a Objetos
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
Orientação a Objetos
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).
Orientação a Objetos
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
Orientação a Objetos
Identificadores Naturais e Artificiais
Portanto, RG, Placa, Chassis são atributos perfeitamente válidos. Mas Usuário_ID, CodPaciente NumCliente são erros
Orientação a Objetos
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()”.
Orientação a Objetos
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”
Orientação a Objetos
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”
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
Associações entre ClassesSão semelhantes aos relacionamentos do MERPossuem cardinalidade • Um para Um • Um para muitos • Muitos para muitos
Orientação a Objetos
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
Orientação a Objetos
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”.
Orientação a Objetos
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”).
Orientação a Objetos
Associações entre ClassesPessoa
NomeIdadeEndereço
Empresa
RazãoSocialEndereçoTrabalha
em
Filho de
Casado com
Orientação a Objetos
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)
Orientação a Objetos
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
Orientação a Objetos
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?)
Orientação a Objetos
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
Orientação a Objetos
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.
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
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”.
Orientação a Objetos
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”
Orientação a Objetos
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
Orientação a Objetos
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
Orientação a Objetos
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}
Orientação a Objetos
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.
BDs Orientados a Objeto
HistóricoPara compreender melhor é necessária uma rápida visita à arquitetura MainFrame:
Aplicação
SGBD
BD
Terminal
MainFrame
BDs Orientados a Objeto
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.
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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.
BDs Orientados a Objeto
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
BDs Orientados a Objeto
HistóricoO servidor de arquivos
EstaçõesServidor de Arquivos
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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”
BDs Orientados a Objeto
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?
BDs Orientados a Objeto
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.
BDs Orientados a Objeto
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.
BDs Orientados a Objeto
HistóricoModelo Cliente-Servidor
EstaçõesServidor de Banco de Dados
SGBD
BD
Aplicativo
Aplicativo
Aplicativo
BDs Orientados a Objeto
HistóricoA principal vantagem é que o Servidor de BD implementava os aspectos de ConcorrênciaIntegridadeSegurançaRecuperação de falhas
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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:
BDs Orientados a Objeto
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
BDs Orientados a Objeto
HistóricoA solução Implementar múltiplas camadas (no mínimo 3) a invés de apenas duas.
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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)
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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.
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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.
BDs Orientados a Objeto
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?
BDs Orientados a Objeto
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.
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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).
BDs Orientados a Objeto
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
BDs Orientados a Objeto
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.
BDs Orientados a Objeto
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 Orientados a Objeto
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) ...
BDs Orientados a Objeto
SQLO argumento decisivo a favor dos relacionaisFácil de usarEficiente EficazPadrãoConsagrada em todos os produtos hoje
BDs Orientados a Objeto
HistóricoMas não há sentido em migrar dos relacionais para os Orientados a ObjetosCustosCulturaTreinamento
BDs Orientados a Objeto
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
BDs Orientados a Objeto
Relacionais EstendidosUm BD relacional sob uma casca orientada a objetoOIDsMétodosClassesEx: PostGres
BDs Orientados a Objeto
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