bancos de dados orientados a objetos

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.


• Histórico– Para compreender melhor é necessária uma

rápida visita à arquitetura MainFrame:

Aplicação

SGBD

BD

Terminal

MainFrame


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


• 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


• 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


• 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


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


• 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


• Histórico– O servidor de arquivos

EstaçõesServidor de Arquivos


• 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


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


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


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


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


• Histórico– Modelo Cliente-Servidor

EstaçõesServidor de Banco de Dados

SGBD

BD

Aplicativo

Aplicativo

Aplicativo


• Histórico– A principal vantagem é que o Servidor de BD

implementava os aspectos de – Concorrência– Integridade– Segurança– Recuperação de falhas


• 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


• 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


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


• 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


• Histórico– A solução – Implementar múltiplas camadas (no mínimo 3)

a invés de apenas duas.


• 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


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


• 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


• 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


• 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


• 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


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


• 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


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


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


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


• 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


• 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


• 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


• 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


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


• 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


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


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


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


• 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


• Relacionais Estendidos– Um BD relacional sob uma casca orientada a

objeto– OIDs– Métodos– Classes– Ex: PostGres

bancos de dados orientados a objetos

Documents