BDs Orientados a Objeto
Propaganda
Bancos de Dados Orientados a Objetos Álvaro Vinícius de Souza Coêlho [email protected] 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: BD SGBD Aplicação 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 Aplicativo Servidor de Banco de Dados BD Aplicativo SGBD 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 – 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 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 • 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
