1
Bancos de Dados III
Bancos de Dados
Distribuídos
Arquiteturas, Modelos e Requisitos
Rogério Costarogcosta@inf.puc-rio.br
Arquitetura Genérica do
SGBDD
Existem diversas propostas de arquiteturas
para BDD (multi-database, federação, ...)
Um SGBD distribuído pode ser visto como
uma federação de SGBDs centralizados,
autônomos, chamados de SGBDs locais, que
são interligados por uma camada de software
chamada de SGBD da rede ou SGBD global
3
Arquitetura Genérica do
SGBDD
Um SGBD local:
É como um SGBD centralizado gerenciando de
forma autônoma o banco de dados local, exceto
que poderá receber comandos tanto de usuários
locais quanto da cópia local do SGBD global.
Arquitetura Genérica do
SGBDD
A coletividade dos bancos locais constitui, então,
uma implementação do banco distribuído.
O SGBD global roda como uma aplicação sob o
sistema operacional da rede de comunicação de
dados.
Isto significa que todos os problemas de comunicação de dados e distribuição de recursos é transparente ao SGBD global.
5
Arquitetura Genérica do SGBDD
Exemplo com ambiente
de Federação de Bancos
de Dados
Tipos de SGBDDs
Homogêneo vs Heterogêneo
SGBDD Homogêneo (em "software") : se os
SGBDs locais são semelhantes
oferecem interfaces idênticas ou, pelo menos, da
mesma família;
fornecem os mesmos serviços aos usuários em
diferentes nós.
SGBDD Heterogêneo
Caso contrário ao anterior
Classificação semelhante pode ser
feita com base no hardware.
7
Tipos de SGBDDs
Homogêneo vs Heterogêneo
SGBDDs homogêneos aparecem com mais
freqüência quando a aplicação a que se
destinam não existia antes.
SGBDDs heterogêneos surgem usualmente
quando há necessidade de integrar sistemas
já existentes.
Classificação dos Usuários de
SGBDD
dbas, analistas, programadores, usuários casuais,
paramétricos....
Usuários globais:
observam o banco de dados distribuído como um todo e
acessam os dados através das interfaces do SGBD
global;
Usuários locais:
têm contato apenas com o banco de dados local ao nó
onde residem e interagem apenas com o SGBD local.
9
Requisitos Funcionais de um
SGBDD
A forma como o banco de dados está armazenado deve
ser definida pelo administrador, mas não deve ser
visível aos outros tipos de usuários
Detalhes de armazenamento devem ser transparentes ao desenvolvimento de programas de aplicação e ao uso casual do banco, já que a este nível apenas a forma com que os dados estão logicamente estruturados importa. Espera-se que seja possível mudar a forma de armazenar
o banco sem alterar os programas de aplicação
Independência física de dados.
Requisitos Funcionais de um
SGBDD
Independência de Localização e Replicação
A localização do BD não deve causar problemas de implementação (exceto, é claro, na variação do tempo de acesso).
Eventuais replicações também devem ser transparentes O sistema deve ser responsável por localizar os dados e
atualizar todas as cópias. Além disto, se os arquivos forem movidos de um nó para outro, ou divididos, os usuários não devem tomar conhecimento do fato.
Em resumo, os usuários globais deverão ver o banco de dados
distribuído como se fosse centralizado =>Independência de localização e replicação.
11
Requisitos Funcionais de um
SGBDD
Autonomia Local
Este requisito está intrinsecamente ligado à estruturação de um SGBD distribuído em uma federação de SGBDs locais autônomos interligados pelo SGBD global.
Nesta arquitetura exige-se que cada SGBD local mantenha sua autonomia:
cada SGBD deve manter controle sobre seus próprios dados => distribuição da responsabilidade dos dados para os próprios usuários locais;
programas que acessem dados locais devem ser executados localmente, sem que seja necessário consultar outros nós.
Como conseqüência deste requisito, um usuário local deverá
acessar os dados locais como se constituíssem um banco de dados centralizado independente.
Requisitos Funcionais de um
SGBDD
Interfaces de Muito Alto Nível
A linguagem para acesso aos dados armazenados no banco deve ser de muito alto nível, ou seja, com as seguintes características:
a linguagem deve ser não-procedimental no sentido do usuário especificar que dados devem ser acessados e não como eles devem ser acessados (isto é problema do sistema);
os comandos de acesso ao banco, oferecidos pela linguagem, devem manipular conjuntos de objetos e não apenas um objeto de cada vez;
os comandos devem ser completamente independentes dos detalhes de armazenamento do banco e da existência de caminhos de acesso pré-definidos.
13
Requisitos Funcionais de um
SGBDD
Otimização Automática
O uso de interfaces de alto nível perderia o
impacto se o processamento de comandos para
acesso aos dados fosse ineficiente.
O SGBDD deve, portanto, conter um otimizador
para selecionar os caminhos de menor custo para
acessar os dados.
Requisitos Funcionais de um
SGBDD
Reestruturação Lógica do Banco e Suporte a Visões Modificações nas estruturas lógicas do banco (ou seja, na
forma como os usuários vêem a estruturação dos dados) são necessárias quando a aplicação muda conceitualmente. O SGBDD deve, então, fornecer meios para modificar a
estrutura lógica de um banco já existente e criar a nova versão dos dados a partir da antiga.
Reestruturações deste tipo podem causar impacto nos programas de aplicação => utilizar visões para minorar o impacto
15
Requisitos Funcionais de um
SGBDD
Segurança dos Dados
Uma aplicação baseada em um banco de dados
facilita enormemente o acesso aos dados
operacionais, o que traz o efeito adverso de
facilitar acessos não autorizados a dados
classificados.
O SGBDD deverá, necessariamente, prover
meios para definir critérios de autorização para
acesso aos dados e meios para assegurar que as
regras de acesso serão cumpridas.
Requisitos Funcionais de um
SGBDD
Suporte à Administração dos Dados
Um banco de dados é, em geral, uma estrutura complexa com centenas de tipos de objetos diferentes, armazenados de diversas formas.
A tarefa de administrar um banco, especialmente se é distribuído, exige ferramentas especiais para ser efetivamente executada.
O SGBDD deve, então, fornecer um dicionário ou diretório, onde é armazenada a descrição do banco, ferramentas para acesso a este dicionário, além de utilitários para manutenção do banco.
17
Arquitetura em 3 Camadas
Três níveis de esquemas: conceitual, interno e
externo
E squ e m a C o n c e itu a l E squ e m a In te rn o E s qu e m a E xte rn o E squ e m a E xte rn o Modelo de dados proposto pelo comitê SGBD ANSI/SPARCDescrição de BD Centralizados
Esquema conceitualdeve apresentar uma visão de alto nível do banco, independente da
forma de armazenamento refletindo apenas a semântica do empreendimento que está sendo modelado.
Esquema Conceitual Esquema Interno Esquema Externo Esquema Externo
19
Descrição de BD Centralizados
Esquema internoobtém-se uma representação eficiente do esquema conceitual em
termos dos métodos de acesso e estruturas de arquivos oferecidas pelo sistema de gerência de banco de dados.
E sque m a C o n c e itu a l E sque m a In tern o E s qu e m a E xterno E squ e m a E xtern o
Independência física de dados:
espera-se de um bom sistema de gerência de banco de dados que permita mudar o esquema interno do banco sem alterar os programas de aplicação.
Descrição de BD Centralizados
Esquema externovisão especializada do banco para cada grupo de usuários, no ponto de vista lógico
Esquema Conceitual Esquema Interno Esquema Externo Esquema Externo
21
Arquitetura em três camadas
Tabelas e Relacionamentos Visões para Usuários Visões para Usuários Visões para Usuários Aplicação 1 Aplicação 2 Aplicação 3Implementação física Esquema Externo Esquema Conceitual Esquema Interno
Esquemas
Exemplos:
Esquema Externo: Implementado por Views
CREATE VIEW V1(CV1,CV2) ASSELECT C1, C2 FROM T1
Esquema Conceitual: Implementado por Tabelas
CREATE TABLE T1(COL1 CHAR[10] NOT NULL, COL2 DECIMAL NOT NULL);
Esquema Interno: Implementado Internamente
Arquivos... struct TABLE T1 {23
Descrição do BDD
Esquema Conceitual Global Esquema Externo Global Esquema Externo Global Esquema Conceitual Local Esquema Conceitual Local Esquema Interno Local Esquema Interno LocalDescrição do BDD
Esquema Conceitual Global Esquema Externo Global Esquema Externo Global Esquema Conceitual Local Esquema Conceitual Local Esquema Interno Local Esquema Interno Local Existe umEsquema Conceitual Global
descrevendo o BDD a nível lógico e
ignorando o fato deste ser distribuído
25
Descrição do BDD
Esquema Conceitual Global Esquema Externo Global Esquema Externo Global Esquema Conceitual Local Esquema Conceitual Local Esquema Interno Local Esquema Interno Local Existe váriosesquemas externos globais
descrevendo visões do BDD para grupos de usuários.
Descrição do BDD
Esquema Conceitual Global Esquema Externo Global Esquema Externo Global Esquema Conceitual Local Esquema Conceitual Local Esquema Interno Local Esquema Interno LocalIdêntico para bancos de dados centralizados e distribuídos.
27
Descrição do BDD
Esquema Conceitual Global Esquema Externo Global Esquema Externo Global Esquema Conceitual Local Esquema Conceitual Local Esquema Interno Local Esquema Interno Local Existeesquema conceitual local
descrevendo o banco de dados local.
O mapeamento do esquema conceitual global para os vários esquemas conceituais locais define, então, o critério de distribuição usado.
Descrição do BDD
Esquema Conceitual Global Esquema Externo Global Esquema Externo Global Esquema Conceitual Local Esquema Conceitual Local Esquema Interno Local Esquema Interno Local A estratégia de armazenamento de cada banco de dados local é definida mapeando-se o esquema conceitual local que o define em um29
Esquema Global
Esquema global é construído num sitecentral.
Os dados permanecem fisicamente armazenados nos sites remotos, mas o usuário tem uma visão única do universo de dados através de visões construídas sobre o esquema conceitual global. site remoto 2 site central site remoto 1
esquema local esquema local
esquema global
Descrição do BDD
Esquema Conceitual Local Esquema Externo Local Esquema Externo Local Esquema Interno LocalComo os sistemas locais devem manter sua autonomia, faz sentido ter
esquemas externos locais
em cada nó descrevendo visões do banco de dados local para cada grupo de usuários locais.
31
Esquemas Locais e Globais
Visões Esquema Conceitual LOCAL Visões Dados Físicos Visões Esquema Conceitual LOCAL Visões Dados Físicos Visões Esquema Conceitual LOCAL Visões Dados Físicos Esquema Conceitual GLOBAL Visões Visões
SITE 1 SITE 2 SITE 3
GCS
LCS
LCS LCS
Catálogo Global
O site central precisa conter, de fato, dois conjuntos
de informações conhecidos como CATALOGO
GLOBAL:
o esquema global: visões, tabelas, colunas globais o esquema de distribuição
fragmentos de tabelas: como as tabelas estão
distribuídas pelos sites através de fragmentação horizontal.
fragmentos de colunas (para cada site): como as
tabelas estão distribuídas pelos sites através de fragmetnação vertical.
33
Descrição do BDD Homogêneo e
Heterogêneo
BDD homogêneo
todos os esquemas a nível lógico utilizarão o mesmo modelo de dados.
Visões e Consultas ao Catálogo
Global
Visões globais executadas através de comandos SQL distribuídos, que trazem a especificação da fragmentação. O formato geral: SITE.TABELA.COLUNA Exemplo:
CREATE VIEW GV1 AS
SELECT SITE1.T1.C1, SITE1.T1.C2, SITE2.T1.C4 FROM SITE1.T1, SITE2.T1
WHERE SITE1.T1.C1 = SITE2.T1.C1 AND SITE2.T1.C4 > 1000 A construção dos esquema conceitual global simplifica as consultas:
TABELA GLOBAL: GT1 SITE1.T1.C1 ALIAS: GC1 SITE1.T1.C2 ALIAS: GC2 SITE1.T1.C3 ALIAS: GC3 SITE2.T1.C4 ALIAS: GC4 O novo comando:
SELECT GC1, CG2, CG4 FROM GT1 WHERE GC1 = GC4 AND GC4 >
35
Descrição do BDD Homogêneo e
Heterogêneo
BDD heterogêneos
esquema conceitual global no modelo de dados pivot
esquemas externos globais podem ser tanto no modelo de dados pivot, para usuários globais, ou em um modelo de dados local, no caso de se desejar oferecer a um usuário local uma visão do BDD no modelo que ele está acostumado
esquemas conceituais locais no modelo de dados local; esquemas externos locais no modelo de dados local.
Projeto de BDD
O projeto do esquema conceitual global e o dos esquemas
externos globaisé inteiramente semelhante ao caso centralizado.
já que o BDD deverá se comportar como centralizado perante os usuários globais. Esquema Conceitual Global Esquema Externo Global Esquema Externo Global Esquema Conceitual Local Esquema Conceitual Local Esquema Interno Esquema Interno
37
Projeto de BDD
O projeto dos esquemas internos locais é idêntico ao de bancos centralizados
exceto que a carga imposta por acessos remotos aos dados locais também deve ser levada em consideração.
Esquema Conceitual Global Esquema Externo Global Esquema Externo Global Esquema Conceitual Local Esquema Conceitual Local Esquema Interno Local Esquema Interno Local
Projeto de BDD
O problema básico de projeto de BDD reside no projeto dos esquemas conceituais locais, pois estes refletem a estratégia de distribuição do banco. Esquema Conceitual Global Esquema Externo Global Esquema Externo Global Esquema Conceitual Local Esquema Conceitual Local Esquema Interno Local Esquema Interno Local
39
Especificação das Interfaces de um
SGBDD
Um SGBDD é constituído de uma coleção de
SGBD locais interligados por um SGBD global.
Em cada nó, os usuários locais e globais devem ser
atendidos
Há, portanto, duas classes de interfaces em um
SGBD distribuído:
as interfaces globais, oferecidas pelo SGBD global aos usuários globais;
as interfaces locais, oferecidas pelos SGBDs locais aos usuários locais.
Especificação das Interfaces de um
SGBDD
SGBD global deverá se comportar como um SGBD centralizado perante seus usuários, e o SGBD local é, para efeito dos usuários locais, um SGBD centralizado
autônomo.
Para especificar as características das interfaces oferecidas tanto a usuários locais quanto a usuários globais, basta estudar os tipos de interfaces comumente oferecidas por SGBDs centralizados, ou seja:
uma linguagem de definição de dados (LDD) usada para definir novos bancos de dados;
uma ou mais linguagens de manipulação de dados (LMDs) usadas para recuperar e modificar os dados armazenados no banco;
41
Influência do Tipo de SGBDD
Homogêneo sobre as Interfaces
Em um SGBDD homogêneo todos os SGBDs
locais oferecem interfaces idênticas => o mesmo
modelo de dados, a mesma LDD e as mesmas
LMDs.
SGBD global ofereça as mesmas interfaces.
Qualquer usuário, local ou global, poderá acessar
tanto dados locais quanto dados remotos através da
mesma LMD.
Influência do Tipo de SGBDD
Heterogêneo sobre as Interfaces
Em sistemas heterogêneos, os SGBDs locais potencialmenteusam modelos de dados e LMDs diferentes.
Uma opção seria o SGBD global oferecer ao usuário global, residente em um dado nó, uma visão do banco de dados distribuído no mesmo modelo de dados que o banco local, e permitir que este usuário acesse dados definidos nesta visão através da própria LMD local.
Não é necessário ensinar uma nova LMD aos usuários residentes em um determinado nó para que possam acessar dados remotos.
SGBD global possui, na verdade, uma interface diferente para cada nó. SGBD global pode ainda suportar uma LMD
43
Exemplo de Ciclo de Processamento em um
SGBDD
G Ti G Dj S G B D Lj B D L R e d e G Di S G B D Li D D T B D L1. Uma transação T operando no nó i (ou usuário acessando o banco através do nó i) executa um comando para acessar o banco
Exemplo de
Ciclo de Processamento em um
SGBDD
GTi GDj SGBDLj BDL Rede GDi SGBDLi DD T BDL 2. O gerente de transações do nó i: • intercepta o comando,• acessa o diretório global (que pode estar em outro nó) e
• cria um plano de acesso ao BDD para obter os dados necessários, ou seja, cria uma seqüência de comandos a serem enviados aos outros nós e para o próprio banco local
45
Exemplo de
Ciclo de Processamento em um
SGBDD
GTi GDj SGBDLj BDL Rede GDi SGBDLi DD T BDL 3. O gerente de transações do nó i:• envia comandos aos nós envolvidos e coordena a sua execução
Exemplo de
Ciclo de Processamento em um
SGBDD
GTi GDj SGBDLj BDL Rede GDi SGBDLi DD T BDL4. O gerente de dados de um nó j envolvido no processamento recebe comandos para o banco local e se encarrega de chamar o SGBD local para executá-los.
Se for necessário, o gerente de dados traduz os comandos para a linguagem de manipulação de dados local;
47
Exemplo de
Ciclo de Processamento em um
SGBDD
GTi GDj SGBDLj BDL Rede GDi SGBDLi DD T BDL4. O gerente de dados do nó j devolve os dados pedidos ao gerente de transações do nó i;
5. O gerente de transações do nó i completa o processamento do comando submetido, passando os dados para a transação (ou para o usuário).
