Bancos de Dados Orientados a Objetos Álvaro Vinícius de Souza Coêlho

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 Diagramas de Seqüência Métodos

Roteiro BDOO Histórico Relacional X Redes SQL BDOO – Objetos (apontadores?) Estendidos Ling. de Prog. Em BD

Roteiro Definição Persistência Objetos Complexos Encapsulamento Classes Herança Ling. de Programação e Consulta

Roteiro Definição (cont) Completeza computacional Controle de Transações Extensibilidade Relacionamentos Controle de Concorrência Recuperação de Falhas

Roteiro Análise Geral Relacionamentos Linguagens DDL e DML Falta de Padrão Violação do Encapsulamento Modo Formal Incompleto

Roteiro O PostGres Relacional Estendido Objetos, 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 Dados Regras Conclusão

Orientação a Objetos O que é um objeto Alguma coisa que faz sentido no contexto da aplicação. Podem ser definidos como um conceito, abstração ou simplesmente algo que tenha significado bem definido Objetos 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 objeto A decomposição de um problema em seus objetos depende de preferências e julgamentos pessoais Todo objeto tem identidade e é distinguível dos seus semelhantes Objeto: Uma Coisa. Classe: Conjunto de Coisas

Orientação a Objetos O que é um objeto Classes: Árvores, Árvores Frutíferas, Árvores Ornamentais, Empregados, Fornecedores Objetos:“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 Classes Se 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 Classes As definições são armazenadas uma por classe, não uma por instância As operações também são definidas para a classe, de forma que seus objetos possam reutilizá-las Tomando por exemplo a classe Pessoa

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

Orientação a Objetos Classes Isso é verdade para todas as pessoas que eventualmente sejam inseridas nesta classe Ainda que o valor de cada informação possa ser modificado a cada caso, a forma de descrição é a mesma

Orientação a Objetos Classes José 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 Classes José e João são, nesta abordagem, objetos de uma mesma Classe Objetos de uma classe tem os mesmos atributos e comportamentos padronizados não necessariamente iguais, como vai se ver

Orientação a Objetos Classes Os 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 Classes Por exemplo um sistema de pesquisa por amostragem Cada pessoa entrevistada te seu nome mantido no anonimato. É um objeto da classe Entrevistado Uma classe “Entrevistado” possui os atributos “Cor”, “Naturalidade”, “Idade”, “Faixa Salarial” e “Sexo”.

Orientação a Objetos Classes Podem 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 Classes Os objetos de uma classe compartilham uma semântica comum, mais que atributos e métodos comuns

Orientação a Objetos Classes Por 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 Classes Cada 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 espiral cada 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 PessoaEmpresa

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 sistema Para 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 puro Não se pode permitir que um atributo seja um outro objeto Mas podem ser multivalorados Os 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 definidos Por 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ângulo Alé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 Classes No levantamento das classes ou dos atributos, pode-se perceber que há relações entre duas ou mais classes As 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 Classes São semelhantes aos relacionamentos do MER Possuem cardinalidade Um para Um Um para muitos Muitos para muitos

Orientação a Objetos Associações entre Classes E 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 Classes As 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 Classes No nosso exemplo, os atributos agora estão colocados. As associações idem Observá-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 Classes Pessoa Nome Idade Endereço Empresa RazãoSocial Endereço Trabalha 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 classe Apó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étodos Os métodos fica na terceira e última parte do retângulo Em 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étodos O exemplo do cálculo da área de figuras geométricas é um cãs de polimorfismo A á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étodos Para 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étodos Há 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étodos Finalmente, 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étodos Este 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étodos Este 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étodos A 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 exemplo Pessoa Nome Idade Endereço Casar(Pessoa) Separar() TerFilho(Nome) Aniversaria() Mudar(NovEnd) Empresa RazãoSocial Endereç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 Objetos Pessoa.Separar() X  Este.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 Objetos Pessoa.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 Objetos Pessoa.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 outro Uma seta, partindo do objeto que solicita, pode deixar isso evidente Diagramas 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órico Historicamente 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órico Para compreender melhor é necessária uma rápida visita à arquitetura MainFrame: Aplicação SGBD BD Terminal MainFrame

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

BDs Orientados a Objeto Histórico Opcionalmente a aplicação poderia acessar diretamente os arquivos O MainFrame permitia a execução de muitos programas ao mesmo tempo Compartilhar um único arquivo através da estratégia de Time Sharing Uma fatia de tempo para cada processo, assim todos estavam sempre sendo executados

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

BDs Orientados a Objeto Histórico Com a popularização e o barateamento dos microcomputadores, surgem os sistemas menores, que acessavam arquivos Na 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órico Esta 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órico Fenô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órico O servidor de arquivos Estações Servidor de Arquivos

BDs Orientados a Objeto Histórico Provia 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órico Os aplicativos cuidariam de acessar o servidor a partir de muitos pontos Atendendo a diversos usuários como o MainFrame, mas a custo bem inferior Além disso uma estação de trabalho tinha vantagens sobre o terminal “burro”

BDs Orientados a Objeto Histórico As 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órico Este modelo arquitetural de Banco de Dados ficou conhecido como Sistemas tipo Servidor de Arquivos A 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órico A 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órico Modelo Cliente-Servidor Estações Servidor de Banco de Dados SGBD BD Aplicativo

BDs Orientados a Objeto Histórico A principal vantagem é que o Servidor de BD implementava os aspectos de Concorrência Integridade Segurança Recuperação de falhas

BDs Orientados a Objeto Histórico A desvantagem surge ironicamente do fato que levou muita gente a se afastar da arquitetura MainFrame: A Estação Cliente Argumento 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órico Os 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órico Por outro lado, a crescente sofisticação das aplicações exigia investimentos pesados no fortalecimento do poder de processamento dos clientes Passou-se a olhar, então, esta arquitetura como um modelo em duas camadas:

BDs Orientados a Objeto Histórico Cliente 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órico A solução Implementar múltiplas camadas (no mínimo 3) a invés de apenas duas.

BDs Orientados a Objeto Histórico Apresentaçã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órico A 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órico Objetos de lógica do negócio Encapsulam regras de negócio do mundo real independente de como os dados estão armazenados Usualmente possuem múltiplas operações acessando vários objetos de dados

BDs Orientados a Objeto Histórico Objetos 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órico Necessidade: Mapeamento Objetos de Dados – Objetos de Negócio O 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 Objeto Histórico Multicamadas

BDs Orientados a Objeto Histórico O 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 forma A camada de acesso a dados atua como cliente do servidor de Banco de Dados

BDs Orientados a Objeto Histórico O cliente pode ser tão magro quanto possível. Idealmente, trata-se apenas de um navegador Web Pela Web, as conexões podem ser feitas No cliente funciona apenas um componente (ASP, Java,...) Provê a visualização, e a entrada/saída de dados Quase um terminal do MainFrame, mas executa efetivamente processos.

BDs Orientados a Objeto Histórico Ao ser ativado o processo (componente) Verifica-se se a data do que está instalado é defasada em relação ao do servidor Então houve uma atualização A versão mais recente é transportada automaticamente

BDs Orientados a Objeto Histórico Vantagens Pode-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órico Os 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órico Preserva-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órico Mas alguma coisa havia mudado A necessidade de componentes e de encapsulamento Este 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órico Java começa, então, a ganhar muito espaço neste contexto. Surgem aplicações visuais Java Provêem todas as facilidades dos ambientes de Visual Basic e Delphi Mais Orientação a Objetos

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

BDs Orientados a Objeto Histórico Os SGBDs acompanharam essa evolução, mudando também Até 1960: Sistemas de Arquivos Integrados – ISAM, VSAM (IBM). Crítica: pouco encapsulamento Controles de segurança, concorrência, integridade e recuperação de falhas ficavam a cargo dos programas aplicativos

BDs Orientados a Objeto Histórico Se 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órico Uma estrutura de registros pai-filho dispostos em seqüência, implementando relação um para muitos de cima para baixo Implementava 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órico 1970 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órico Final dos anos 70: Modelo Relacional (Codd) – SQL-DS, DB2, (IBM), Oracle, Ingres. Relação entre dados, não através de estruturas internas do banco Modela, como o em Rede, toda sorte de relacionamentos

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

BDs Orientados a Objeto SQL O argumento decisivo a favor dos relacionais Fácil de usar Eficiente Eficaz Padrão Consagrada em todos os produtos hoje

BDs Orientados a Objeto Histórico Mas não há sentido em migrar dos relacionais para os Orientados a Objetos Custos Cultura Treinamento

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

BDs Orientados a Objeto Relacionais Estendidos Um BD relacional sob uma casca orientada a objeto OIDs Métodos Classes Ex: PostGres

BDs Orientados a Objeto Linguagens de Programação de BDs Extenção de C++, SmallTalk ou Java com Persistências de Objetos Controle de Transações e Concorrência Possui (normalmente) uma linguagem proprietária para DDL e DML

Características O que define um BDOO? Discussão indefinida Definiçã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ência Caracterí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 O 2 – “name” torna o objeto persistente Poet – Classes definidas como persistentes ObjectStore – 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, O 2 ) 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á ortogonalidade Por chamada – perfeitamente ortogonal

Características Objetos Complexos Objetos 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ção Associações “Invisíveis” e “Intocáveis” pelo usuário

Características Encapsulamento Conceito é importante para a OO Em BDOO: Acesso não aos atributos, mas a métodos Impossí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 BDOO Encapsulamento: 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 Linguagens Num Banco de Dados Relacional há linguagens de Consulta – SQL, QBE, Xbase, Quel... Programação – PL/SQL, TransactSQL, Dbase... E num BDOO?

Características Linguagens de Consulta Consultas ad hoc Sem maiores complicações – “feita” para quem já usa SQL Acessam atributos e métodos Violam o encapsulamento

Características Linguagens de Programação Tentam 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 linguagem Tabelas Structs, 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 interesse Tabelas: 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ância Diminuição e Simplicidade de código Diminuição de Tempo de Execução Compartilhamento de estruturas

Características Completeza Computacional Nem todas as consultas podem ser feitas com linguagens de consulta A questão do Auto-Relacionamento Não são implementações completas da Máquina de Turing!

Características Solução: Programação em SGBDs Uma Linguagem de Programação completa Desvios condicionais Repetição Subprogramação Recursividade

Características Em SGBDOO o problema é o mesmo Linguagens 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ções Nos Bds tradicionais: O mais rápido possível A interrupção de uma transação no meio é indesejável Atômica

Características Nos BDOO O tempo depende da natureza da aplicação A interrupção de uma transação no meio pode ser necessária Não-Atômica

Características Recuperação de Falhas BDs tradicionais: Redo das transações completas Undo das transações incompletas

Características BDOO: Redo das transações completas Redo do que for possível das transações incompletas Estudos para se ajustar a teoria ded BD aos requisitos de BDOO Possivelmente o estabelecimento de uma nova técnica de Recuperação de Falhas

Características Extensibilidade Tipos tradicionais: Inteiros, Reais, Strings, Data, etc. Predefinidos com operações sobre eles Tipos criados pelo usuário: mesmas características Ainda que apenas sob o ponto de vista do usuário

Características Relacionamentos Não há um elemento para representar A tecnologia aponta para variáveis de instância Armazenam OIDs de objetos relacionados

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

Características Crítica A variável fica misturada aos atributos “naturais” Parece com uma chave estrangeira Não há uma especificação de que se trata de uma associação Dá a impressão de se tratar de uma relação Todo-Parte

Características Problemas 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ário Caso o relacionamento tenha atributo ele deverá aparecer dos dois lados (data aquisição)

Características Integridade Referencial A exclusão de um automóvel implica em Nulidade 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 BDOO Exemplo: ORION-2

Críticas Porque se usa LPs Orientadas a Objeto e não se usa BDs Orientados a Objeto? Cultura Plataforma Instalada Pouca necessidade de Componentes Faltas nos aspectos Técnicos

Críticas Relacionamentos Não são declarados explicitamente Usa-se Atributos “Especiais” Relações 1-N e N-N: Referências Cruzadas Atributos em objetos auxiliares ou em ambos os lados

Críticas Relacionamentos Linguagens 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 DML Argumento 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 DML Linguagens Algoritmicas: Retrocesso à 3 a Geração SQL: O que se quer C++: Como se faz

Críticas Padronização Absolutamente não há Modelo de Dados: Uns tem Herança, Uns tem Polimorfismo, Uns tem Associação N- N, outros não Migração?

Críticas Padronização ODMG (Object Database Management Group) Produtores de: GemStone, Orion, O2, ObjectStore, Objectivity, Poet, UniSQL e Versant Tentativa de criar padrões Nova e incipiente

Críticas Padronização Normalmente os BDOO surgem voltados para aplicações específicas Interessante: Cactis - Aplicações CASE Transações muito especiais

Críticas Encapsulamento Violado Linguagens de consulta derivadas de SQL Acesso direto ao atributo Alteração (UPDATE) direto no atributo Bombardeada 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 Formalismo O modelo relacional é formal Associações, Projeções, Junções: Rigorosamente demonstrados Álgebra Relacional E em BDOO?

Críticas Formalismo A Álgebra Relacional não se aplica Dois 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 Berkeley Sucessor do INGRES Atualmente: Miro (Comercial)

PostGres Versão não comercial disponível no site da universidade Escrito em C linhas de código

PostGres Relacional Estendido Objetos OIDs “tradicionais” Objetos Compostos Herança Múltipla Versões

PostGres Dados históricos Linguagem 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 momento Armazena o estado do BD depois ded cada alteração

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

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

PostGres O projeto: Pessoa Nome Idade Endereço Casar(Pessoa) Separar() TerFilho(Nome) Aniversaria() Mudar(NovEnd) Empresa RazãoSocial Endereç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)

PostGres Declaração: Create pessoa ( RG (char[11], nome = char[25], Idade = int, endereco = char [50], empregador = empresa, Filhode = pessoa Casadocom = pessoa) Key (RG)

PostGres Herança Create PrestServico (precohora = float) Inrerits (pessoa)

PostGres Herança múltipla Caso se ponha mais de uma classe no comando inherits Caso haja conflito de nomes de atributos retorna um erro.

PostGres Tipos de dados PostQuel Servem para executar um método que faz o acesso ao relacionamento Uma consulta feita em PostQuel

PostGres Key define um atributo como OID Pode haver mais de um atributo Nenhum pode ser nulo e eles não irão se repetir Implementação idêntica à de chave primária do modelo relacional

PostGres Key define um atributo como OID Pode haver mais de um atributo Nenhum pode ser nulo e eles não irão se repetir Implementaçã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ário Por exemplo, usar o par (empregador, matricula) Empregador é do tipo empresa Como comparar empresa?

PostGres Cria-se uma função Define function há_emp(e = empresa) Return int as Retrieve any(empresa.all Where empresa.cnpj = e.cnpj Key empregador using há_emp, matricula)

PostGres Manipulação de Dados PostQUEL contem os comandos append, replace e delete Append to pessoa (nome =...) Delete pessoa where... Replace pessoa (nome=... ) where...

PostGres Percurso do fecho transitivo de um esquema Característica do postquel em extensão a quel Mostrar todos os ancestrais de José

PostGres A consulta Retrieve * into classeresposta (pessoa.filhode) from a in classeresposta Where pessoa.nome = “José” Or pessoa.nome = diznome(a.filhode)) * obriga que a consulta será executada até não retornar mais dados

PostGres A consulta Retrieve (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 consulta Retrieve func.salario From func[D] Where func.nome = “José” Retorna o salário de José na data D

PostGres Regras Ação executada no banco sob ordem de determinado evento On evento to objeto where condição Then do [instead] comandos

PostGres Evento pode ser Retrieve Replace Delete Append New (replace ou append) Old (delete ou replace)

PostGres Objeto é o nome de uma classe, ou do atributo de uma classe Condição é um qualificador qualquer usado em PostQUEL Instead 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.salario From c in cargos Where c.nome = “Professor”

PostGres Críticas Métodos implementados em funções – não nas classes Não implementa OIDs naturais Relacionamentos se confundem com variáveis de instância Padrão proprietário Viola o encapsulamento

PostGres Qualidades Herança e Herança múltipla Versões de dados ao longo do tempo Completeza implementada em PostQuel Aceita 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