BDs Orientados a Objeto

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