Bancos de Dados Orientados a Objetos

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

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

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

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

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

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

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

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

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

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

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

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

13. 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?

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

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

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

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

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

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

20. 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:

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

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

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

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

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

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

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

28. BDs Orientados a Objeto • Histórico • Multicamadas

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

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

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

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

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

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

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

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

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

38. BDs Orientados a Objeto • Histórico • As arquiteturas de SGBDs evoluíram 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

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

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

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

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

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

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

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

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