SCC0141 - Bancos de Dados

e Suas Aplicações
Visões e Bancos de Dados
Distribuídos

Prof. Jose Fernando Rodrigues Junior

Material original: Profa. Elaine Parros Machado de Sousa

1
 Visão (View)

Tabela Base Tabela Base 1 Tabela Base 2

junção

consulta consulta

View View
 Visão (View)

 Representação de dados contidos em outras

tabelas (tabelas base) ou mesmo em outras
visões
 Trata resultado de uma consulta como uma tabela
 consulta armazenada
 tabela virtual
 Espaço de armazenamento (no dicionário de
dados) apenas para a consulta (select) que
define a visão
 Consulta é executada cada vez que a visão é
acessada
 Visão (View)
 Utilidade:
 segurança - restrição de acesso a tuplas e colunas
 armazenamento de consultas complexas ou
executadas com muita frequência
 simplicidade para usuário
 abstração
 apresentação dos dados com menor complexidade ou
em diferentes perspectivas
 isolamento de aplicações em relação a alterações de
esquema
 Views

CREATE OR REPLACE VIEW nome

[(NomeColuna [, NomeColuna ...])]
AS <select>;
 Disciplina = {Sigla, Nome, NCred, Professor, Livro}

Views

 Exemplo – visão atualizável

create or replace view view_disciplina as

select nome, sigla
from disciplina;

select * from view_disciplina;

 Professor = {Nome, NFunc, Idade, Titulação}

Views

 Exemplo

create view view_professor_doutor as

select * from professor
where titulacao = 'DOUTOR'
 Aluno = {Nome, Nusp, Idade, DataNasc}
Disciplina = {Sigla, Nome, NCred, Professor, Livro}

Views Matrícula = {Sigla, Numero, Aluno, Ano, Nota}

 Exemplo – join view

create view view_matricula (NUsp, Nome,
Sigla, Disciplina) as
select A.NUSP, A.Nome, D.Sigla, D.Nome
from Aluno A join Matricula M
on A.NUSP = M.Aluno
join Disciplina D
on M.sigla = D.sigla;
Views

 CREATE VIEW
 ALTER VIEW
 DROP VIEW
 Visão Materializada
(materialized view)

 Visões armazenadas como tabelas

 dados provenientes de master tables (tabelas base)
 Utilidade
 replicação de dados
 performance
 snapshot local de dados remotos
 armazenamento de resultados de consultas complexas e custosas
 armazenamento de informações sumarizadas
 distribuição de dados
 Visão Materializada
(materialized view)

 Comuns em data warehousing, sistemas

distribuídos, computação móvel....

 Principais desvantagens:
 ocupa espaço de armazenamento
 exige refresh quando as master tables são modificadas
 Visão Materializada no ORACLE

CREATE MATERIALIZED VIEW view_matriculados

BUILD IMMEDIATE
REFRESH FAST ON COMMIT
AS SELECT D.Sigla,
count(M.Sigla) as Nro_Matriculados
FROM Disciplina D, Matricula M
WHERE D.Sigla=M.Sigla
GROUP BY D.Sigla;
 BDs distribuídos - Introdução
 Sistemas de banco de dados centralizados
 dados mantidos em um único local
 processamento de transações individuais essencialmente
sequencial

 Sistemas de banco de dados distribuídos

 dados armazenados fisicamente em diversos locais (sites)
 usualmente: cada site gerenciado por um SGBD

 Sistemas relacionais de fato distribuídos não se

tornaram padrões comerciais, ao invés disso os
grandes fabricantes usam uma camada sobre
diversos sistemas centralizados para se obter o
13
mesmo resultado
 Sistemas comerciais
 IBM DB2 – Distributed Database Facility (DDF)

 Informix Dynamic Server

 Microsoft SQLServer – Distributed Management

Framework (DMF)

 Oracle – Oracle Replication Manager e Heterogeneous

Services/Transparent Gateway

14
 Problema
 Imagine o seguinte problema: uma empresa abrange
várias cidades e a operação da empresa é
integrada por meio de uma base de dados única.
Problemas:
 Copiar a base inteira para todas as filiais? Mas apenas
alguns dados são necessários em cada uma; como manter as
cópias atualizadas?
 Quais dados ter em cada filial então? Ainda assim, alguns
dados comuns serão necessários em todas as sedes?
 Onde guardar os dados comuns? Na sede? Como
disponibilizar estes dados às filiais sem prejudicar o
desempenho? Ter várias cópias dos mesmos dados é uma
opção?
 Em algumas situações será inevitável usar a infra-estrutura
de rede para trafegar dados entre pontos geográficos distantes
uns dos outros? Como minimizar o tráfego? Como tirar o
melhor proveito da rede? Quais alterações podem melhorar 15 o
desempenho?
 Problema
 Imagine o seguinte problema: uma empresa abrange
várias cidades e a operação da empresa é
integrada por meio de uma base de dados única.
Problemas:
 Exemplo:
Copiar a base empresa depara
inteira transporte
todasrodoviário, rede
as filiais? de apenas
Mas
alguns dados são necessários em cada uma; como manter as
hotéis, empresa aérea internacional, rede de lojas do
cópias atualizadas?
 Quais dados ter em cada varejo, ...então? Ainda assim, alguns
filial
dados comuns serão necessários em todas as sedes?
 Onde guardar os dados comuns? Na sede? Como
disponibilizar estescada
Quais problemas dados às filiais
uma destas sem pode
categorias prejudicar
ter o
desempenho? Ter várias cópias dos mesmos dados é uma
de maneira que um BD distribuído possa resolver.
opção?
 Em algumas situações será inevitável usar a infra-estrutura
de rede para trafegar dados entre pontos geográficos distantes
uns dos outros? Como minimizar o tráfego? Como tirar o
melhor proveito da rede? Quais alterações podem melhorar 16 o
desempenho?
 Motivação
 Por que distribuir dados?
 disponibilidade
 acesso distribuído
 localidade  desempenho

 análise distribuída de dados

 expansão

 Aplicações
 grandes corporações
 redes de hotéis
 redes de lojas
 companhias aéreas
 companhias viárias

17
 Componentes

Tecnologia de Banco de Dados Distribuído

Tecnologia de Banco de Dados

Tecnologia de Redes e Comunicação de Dados

18
 Definições
 Banco de Dados Distribuído (BDD)
 conjunto de múltiplos bancos de dados (SGBDs) inter-
relacionados distribuídos por uma rede de computadores

 Sistema de Gerenciamento de Banco de Dados

Distribuído (SGBDD)
 sistema que gerencia um BDD
 torna a distribuição transparente para o usuário

19
 Características

 Sistema de BDD  mais complexo

 funções adicionais do SGBDD
 localização de dados’
 processamento de consultas distribuídas

 gerenciamento de transações distribuídas

 gerenciamento de dados replicados

 recuperação de BDD

 segurança

 gerenciamento de dicionário de dados distribuído

20
 Arquitetura nada

Algumas arquiteturas diferentes de sistemas de

compartilhado – cada
site seu BD
banco de dados (Elmasri e Navathe, 2005)

Arquitetura de
rede com um BD
centralizado

Arquitetura BDD –
o banco é uma
composição dos
diversos sites
21
 Projeto
 Questões relevantes sobre BDD
 Projeto de Distribuição
(Fragmentação/Replicação) da Base de
Dados
 como distribuir a base de dados?
 base de dados distribuída replicada ou não replicada?

 Processamento de Consulta
 como converter transações do usuário em instruções de
manipulação de dados?
 como otimizar uma consulta?
 custo = transmissão dados + processamento local

22
 Projeto
 Questões relevantes sobre BDD
 Controle de Concorrência
 como sincronizar acessos concorrentes?
 como garantir consistência e isolamento das
transações?
 como evitar deadlocks?

 Confiabilidade
 como tornar o sistema tolerante a falhas?
 como garantir durabilidade e atomicidade das
transações?

23
Projeto
 Catálogo (ou Dicionário) de Dados Distribuído
 como e onde os dados estão fragmentados
 como e onde os dados estão replicados
 informação de esquema
 informação de autorização de usuários
 estatísticas

24
 Transparência
 Em SBDDs é necessário que os usuários
não tenham que saber da arquitetura
distribuída  transparência

 Tipos de transparência de dados

 de distribuição
 localização
 nomenclatura

 de replicação
 de fragmentação
 horizontal (WHERE)
25
 Vertical (SELECT)
 Tipos de Sistemas de BDD
 Fator: grau de homogeneidade
 SGBDD homogêneo

 todos os SGBDs locais e todos os clientes idênticos

 SGBDD heterogêneo

 SGBDs locais distintos

 Fator: grau de autonomia

 Em que grau os sites do sistema distribuído são
administrados independentemente

nenhuma AUTONOMIA alto

 esquema conceitual único  SGBDs independentes

 acesso por um único site e autônomos
 para usuário “parece” um  SGBDDs Federados
único SGBD centralizado  Multibases de dados
26
 Catálogo de Dados Distribuído
 Possíveis estruturas
 centralizado
 Vantagem: uma única cópia, simples de
implementar
 Desvantagem: gargalo para o processamento
de consultas – todos os sites tem que acessar
o site central para qq consulta
 catálogo global replicado
 Vantagem: desempenho local de consultas
 Desvantagem: manter a consistência das
múltiplas cópias do catálogo
27
 Catálogo de Dados Distribuído
 Abordagem do R* - projeto protótipo de bases
de dados distribuídas da IBM
 cada site mantém catálogo apenas local

 descrição apenas dos dados locais

 site de criação de uma tabela é

responsável por manter informação de
réplicas
 para encontrar uma tabela é necessário
consultar o catálogo de seu site de
criação
 estratégia: uso de cache nos demais sites
28
 Fragmentação
 Fragmentação  quebra de uma tabela
em fragmentos que podem ser
armazenados em sites diferentes
 Tipos:
 fragmentação vertical  projeção (SELECT)
 fragmentação horizontal  filtragem (WHERE)

 fragmentação mista  projeção +

seleção
 Conceito de “Esquema de Fragmentação”:
metadados que descrevem como os dados são
quebrados ao longo da arquitetura
29
 Fragmentação
 Fragmentação  quebra de uma tabela
em fragmentos que podem ser
armazenados em sites diferentes
Esquema de Fragmentação: definição de um

conjunto de fragmentos que inclui todos os
Tipos:
atributos e tuplas no banco de dados e satisfaz à
 fragmentação vertical  projeção
condição de que o banco de dados pode ser
fragmentação
 reconstruído horizontal
com base nos seleção ao se
fragmentos
aplicar algumamista
 fragmentação sequência de operações
 projeção + de
UNIÃO E JUNÇÃO. (Elmasri-Navathe, 2010)
seleção
 Conceito de “Esquema de Fragmentação”:
metadados que descrevem como os dados são
quebrados ao longo da arquitetura
30
 Fragmentação

 Deve ser possível recuperar a tabela original

a partir dos fragmentos
 fragmentação horizontal (WHERE)
 união dos fragmentos  tabela original
 fragmentação vertical (SELECT)
 coleção de fragmentos  decomposição sem perda de
junção
 como garantir? A chave deve fazer parte de cada fragmento

31
 Replicação

 Replicação  armazenamento de
várias cópias de uma tabela ou
fragmento de tabela
 maior disponibilidade dos dados
 consultas mais rápidas

REPLICAÇÃO

alocação não replicação BD

redundante parcial completamente
replicado

33
 Replicação
 Replicação total: cópias de toda a base em
todos os sites
 Vantagem: maior desempenho de consultas
 Desvantagem: atualizações e controle de
concorrência são dispendiosos, pois novos dados
e locks devem ser propagados para todos os
sites; intenso tráfego de dados

 Alocação não redundante: os sites são

todos disjuntos (com exceção das chaves) 
vantagens e desvantagens inversas à
replicação total 34
 Replicação
 Replicação parcial: algumas partes do banco
são replicadas enquanto que outras não são:
 Conceito de “Esquema de Replicação”:
metadados que descrevem o que é replicado,
onde, quantas vezes e com qual atualização os
dados são sincronizados
 O esquema de replicação é um problema de
otimização complexo, ele depende:
 De quais consultas são realizadas com qual
frequência em cada site
 De quais atualizações são realizadas com qual
frequência em cada site
 De qual controle de concorrência (isolamento) é
necessário em cada site 35
 Replicação
 Replicação parcial: algumas partes do banco
são replicadas enquanto que outras não são:
 Conceito de “Esquema de Replicação”:
metadados que descrevem o que é replicado,
onde, Um esquema
quantas deereplicação
vezes com qualenvolve
atualização os
dados fragmentação horizontal e vertical.
são sincronizados
 O esquema
É comum dequereplicação é um de
um site precise problema
apenas de
otimização complexo,
alguns atributos, ele depende:
enquanto que outro de
 De quais apenas
consultas são tuplas.
algumas realizadas com qual
frequência em cada site
 De quais atualizações são realizadas com qual
frequência em cada site
 De qual controle de concorrência (isolamento) é
necessário em cada site 36
 Replicação

 Tipos:
 replicação síncrona  todas as cópias são
atualizadas dentro de uma mesma transação
 problema? – tráfego intenso de rede

 replicação assíncrona  atualizações

periódicas das cópias de dados modificados
 problema? – controle de transação mais elaborado é
necessário, alguns dados não tem garantia de
consistência e não devem ser lidos

37
 Esquema Distribuído
 Esquemas Lógicos locais ou um esquema global
+
Esquema de Fragmentação
+
Esquema de Replicação

 A arquitetura de um esquema distribuído visa

reduzir seu maior custo: tráfego de rede

 No entanto, em algumas situações como consultas

raramente efetuadas, não há o que se fazer – os
dados irão trafegar em rede intensamente 38
 Esquema Distribuído
 Esquemas Lógicos locais ou um esquema global
+
Esquema de Fragmentação
+
Os esquemas de fragmentação e de replicação
Esquema
determinam umdeúnico
Replicação
esquema de
fragmentação/replicação.
 A arquitetura de um esquema distribuído visa
reduzir seu maior custo: tráfego de rede

 No entanto, em algumas situações como consultas

raramente efetuadas, não há o que se fazer – os
dados irão trafegar em rede intensamente 39
Processamento de Consultas Distribuídas

Custo da Consulta Distribuída

Custo de Transferência de Dados

Custo do Processamento da Consulta

40
 EX: Transferência de Dados
 Exercício
 Processamento-de-consulta-distribuido
 Semi-Junção

 Idéia geral: reduzir o número de tuplas e de atributos transferidos

entre sites
 Por exemplo:

No site 1, executar: SELECT * FROM R JOIN S

ON R.atr1 = S.atr2
com R no site 1 e S no site 2
 No site 1, F=SELEC R.atr1 FROM R, e enviar para o site 2

 No site 2, executar: T = SELECT * FROM F JOIN S

ON F.atr1 = S.atr2
e enviar o resultado para o site 1
 No site 1, executar: SELECT * FROM R JOIN T

ON R.atr1 = T. atr2 42
 EX: Semi-junção
 Exercício
 Semi-juncao
 Transações Distribuídas

 Propriedades ACID devem ser

garantidas

 Atomicidade

 Consistência Recuperação
Concorrência de falhas
distribuída distribuída
 Isolamento

 Durabilidade

44
 Concorrência Distribuída
 Problema: o mesmo dado replicado em diferentes sites
A e B. No site A, o dado é alterado, quase que
imediatamente o site B usará este dado, cuja cópia será
diferente do valor no site A.

 Solução: uso de locks. Quando o site A alterar o dado,

deve-se bloqueá-lo (lock) para uso e escrita até que A
finalize sua operação e o dado seja sincronizado com o
site B.

 Como gerenciar bloqueios (locks) de objetos (tabelas e

fragmentos) distribuídos?
 abordagem centralizada

 abordagem cópia primária

45
 Concorrência Distribuída

 Baseada no conceito de Cópia Distinguida (ou Distinta):

dentre as várias cópias dos dados, uma delas dita como o
controle de concorrência é feito – isto é, uma única
cópia recebe e libera locks

 A escolha da cópia que irá ditar o controle de

concorrência pode ser estático ou dinâmico

 O site que possui a cópia distinguida é denominado site

Coordenador, o qual deverá responder ao sistema de
locks 46
 Concorrência Distribuída
 Abordagem cópia primária
 bloqueios são gerenciados pelo site onde está a cópia
primária (original) do objeto requisitado
 problema? Maior complexidade

 Abordagem completamente distribuída

 bloqueios gerenciados nos sites onde ocorrem as
operações – coordenação dinâmica
 problema? Maior complexidade, necessidade de broadcast
dinâmico para informar sobre a coordenação
 Abordagem centralizada
 um único site responsável por gerenciar todas as
requisições de bloqueio
 problema? Vulnerável a falhas, requer um backup –
sobrecarga de um único site 47
 Recuperação de Falhas Distribuída

 Novos tipos de falha que não ocorrem em

SGBDs não distribuídos
 falhas de comunicação
 falha em um site onde uma sub-transação é
executada
 Atomicidade:
 ou todas as sub-transações são efetivadas
(committed) ou nenhuma deve ser efetivada
COMMIT protocol
Ex: Two-Phase Commit (2PC)
48
 Recuperação de Falhas
Distribuída
 Uso do two-phase commit protocol (2PC)
 Algoritmo distribuído que visa gerenciar situações
transacionais – protocolo do tipo consensual
 Duas fases
1ª. Contacta todos os participantes preparando-os
para o sistema de consenso, segundo o qual, após a
execução distribuída, cada um terá que “votar” sim
(commit) ou não (abort)
2ª. Efetivação da decisão consensual, todos são
informados de que devem consolidar a transação
(todos votaram commit) ou retornar ao estado
anterior (pelo menos um votou abort ou alcançou
time-out) 49
 Exemplo:
ORACLE

 Transparência de localização
(uso de LDAP)
 Transações distribuídas
baseadas em 2PC
 Replicação básica
 leitura em qualquer site
 escrita em site primário
 Replicação avançada – leitura e
escrita em qualquer site
 snapshots
 Suporte a arquitetura
heterogênea (Elmasri e Navathe,50
2005)
 Exemplo:
ORACLE

 Enterprise Manager
 Third-Party Administration Tools
 SNMP Support

Caso heterogêneo:
Heterogeneous services
Caso homogêneo: Oracle Transparent gateway
Advanced Replication Oracle Net Services 52
 Exemplo:
ORACLE

 Enterprise Manager
 Third-Party Administration Tools
 SNMP Support

Caso heterogêneo:
Heterogeneous services
Caso homogêneo: Oracle Transparent gateway
Advanced Replication Oracle Net Services 53
 Exemplo:
ORACLE
 Fluxo de dados entre sites: Oracle Stream Replication, mantém
todos os sites atualizados ao enviar continuamente dados de
atualização
 Transparência de distribuição por meio de database links
 Um database link é um objeto de um esquema que permite o
acesso a objetos de outro banco de dados

CREATE DATABASE LINK remote.us.oracle.com

CONNECT TO junio IDENTIFIED BY junio_password
USING ‘orcl’ -- nome do serviço remoto

SELECT *
FROM tabela1@remote.us.oracle.com

CREATE SYNONYM tabela1_remota

FOR tabela1@remote.us.oracle.com

SELECT * FROM tabela1_remota 54

 Exemplo:
ORACLE
 Fragmentação/Replicação são obtidas por meio de Materialized Views
 horizontal: cláusula WHERE

 vertical: cláusula SELECT

 Em Oracle, a fragmentação é denominada Subsetting (ou

“subconjuntando”)
 Sincronização:
 Periodicidade

 Síncrona: qualquer atualização é propagada imediatamente a

todos os sites
 Assíncrona: as atualizações ocorrem posteriormente, em
intervalos de tempo pré-definidos
 Método

 Fast refresh: usa logs para fazer a atualização apenas do que foi
alterado desde o último refresh
 Complete refresh: atualiza todos os dados da view

 Force refresh: se possível, realiza um fast refresh, do contrário

55
realiza um complete refresh
Referências
 ELMASRI, R; NAVATHE, S.B. Sistemas de
Banco de Dados, Addison Wesley, 4a
edição, 2005.
 Ramakrishnan R.; Gehrke, J. Database
Management Systems, Mc Graw Hill,
2000.
 OZSU, M. T.; VALDURIEZ, P. Principles of
distributed database systems. 2. ed.
Englewood Cliffs: Prentice Hall, 1999.

56