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

Apresentação em tema: "Bancos de Dados Orientados a Objetos Álvaro Vinícius de Souza Coêlho"— Transcrição da apresentação:

1 Bancos de Dados Orientados a Objetos Álvaro Vinícius de Souza Coêlho degas@uesc.br

2 Roteiro Orientação a Objetos Conceitos Como Identificar Classes e Objetos UML Casos de Uso Objetos e Classes

3 Roteiro UML (cont) Atributos Associações Diagramas de Colaboração Diagramas de Seqüência Métodos

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

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

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

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

8 Roteiro O PostGres Relacional Estendido Objetos, OIDs, Herança (simples e múltipla) PostQuel (Quel OO) ADT (Abstract Data Type) Declarações de Dados

9 Roteiro O PostGres (cont) Manipulação de Dados Regras Conclusão

10 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

11 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

12 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”

13 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

14 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

15 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

16 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...

17 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

18 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

19 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

20 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

21 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”.

22 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

23 Orientação a Objetos Classes Os objetos de uma classe compartilham uma semântica comum, mais que atributos e métodos comuns

24 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.

25 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.

26 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)

27 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

28 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

29 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?

30 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

31 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

32 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

33 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.

34 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

35 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).

36 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

37 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

38 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()”.

39 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”

40 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”

41 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

42 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

43 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

44 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

45 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

46 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”.

47 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”).

48 Orientação a Objetos Associações entre Classes Pessoa Nome Idade Endereço Empresa RazãoSocial Endereço Trabalha em Filho de Casado com

49 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)

50 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

51 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?)

52 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

53 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.

54 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

55 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

56 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

57 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

58 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”.

59 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”

60 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

61 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

62 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

63 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.

64 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

65 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}

66 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

67 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

68 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.

69 BDs Orientados a Objeto Histórico Para compreender melhor é necessária uma rápida visita à arquitetura MainFrame: Aplicação SGBD BD Terminal MainFrame

70 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.

71 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

72 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

73 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

74 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.

75 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

76 BDs Orientados a Objeto Histórico O servidor de arquivos Estações Servidor de Arquivos

77 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

78 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”

79 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?

80 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.

81 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.

82 BDs Orientados a Objeto Histórico Modelo Cliente-Servidor Estações Servidor de Banco de Dados SGBD BD Aplicativo

83 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

84 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

85 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

86 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:

87 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

88 BDs Orientados a Objeto Histórico A solução Implementar múltiplas camadas (no mínimo 3) a invés de apenas duas.

89 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

90 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)

91 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

92 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

93 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

94 BDs Orientados a Objeto Histórico Multicamadas

95 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

96 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.

97 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

98 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.

99 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?

100 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.

101 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

102 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

103 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

104 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

105 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).

106 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

107 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.

108 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

109 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)...

110 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

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

112 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

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

114 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

115 Características O que define um BDOO? Discussão indefinida Definição (Atkinson, 1989)

116 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

117 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?

118 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

119 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

120 Características Qual a melhor alternativa? Ortogonalidade entre tipos e persistência Por classe – não há ortogonalidade Por chamada – perfeitamente ortogonal

121 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

122 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!

123 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!

124 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

125 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!

126 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

127 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

128 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?

129 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

130 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

131 Características Para resolver: Compatibilizar dados obtidos nos acessos com as estruturas da linguagem Tabelas Structs, Listas, Matrizes, etc.

132 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

133 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

134 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

135 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!

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

137 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

138 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

139 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

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

141 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

142 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

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

144 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

145 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

146 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)

147 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

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

149 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

150 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

151 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

152 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

153 Críticas Linguagens DDL e DML Linguagens Algoritmicas: Retrocesso à 3 a Geração SQL: O que se quer C++: Como se faz

154 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?

155 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

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

157 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

158 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

159 Críticas Formalismo O modelo relacional é formal Associações, Projeções, Junções: Rigorosamente demonstrados Álgebra Relacional E em BDOO?

160 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

161 PostGres Desenvolvido na Universidade de Berkeley Sucessor do INGRES Atualmente: Miro (Comercial)

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

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

164 PostGres Dados históricos Linguagem de consulta PostQUEL – extensão da linguagem QUEL do INGRES

165 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

166 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

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

168 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

169 PostGres Declaração: Create empresa (CNPJ char [15], razaosocial = char[25], Endereço = char[30], Pessoas = postquel) Key (CNPJ)

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

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

172 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.

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

174 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

175 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

176 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?

177 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)

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

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

180 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

181 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

182 PostGres A consulta Retrieve func.salario From func[D] Where func.nome = “José” Retorna o salário de José na data D

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

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

185 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

186 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)

187 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”

188 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

189 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...

190 PostGres. FIM! “Numa democracia, o direito de ser ouvido não inclui automaticamente o direito de ser levado a sério” Hubert Humphrey