Tema 2 - Sistemas de banco de dados distribuídos

Prévia do material em texto

21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 1/63
Projeto de banco de dados distribuídos
Prof. Sidney Nicolau Venturi Filho
Descrição
O projeto de banco de dados distribuídos e os mecanismos de
fragmentação e replicação utilizados na distribuição de dados.
Propósito
Banco de dados distribuídos é uma tendência atual no mercado de TI.
Saber projetar esse tipo de banco de dados e como implementar a
distribuição dos dados é fundamental para o profissional da área.
Objetivos
Módulo 1
Fundamentos de projeto de banco de dados
distribuídos
Identificar a sistemática de projetos de banco de dados distribuídos.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 2/63
Módulo 2
Fragmentação
Analisar as técnicas de particionamento de uma tabela.
Módulo 3
Replicação
Identificar as características da replicação.
Módulo 4
Modelagem e implementação de um BDD
Formular um banco de dados distribuído.
Introdução
O projeto de um banco de dados distribuído se inicia de modo
muito similar ao de um banco centralizado, ou seja, pela criação
do modelo conceitual global.
A partir desse modelo, é realizada a modelagem dos bancos
locais e o projeto de distribuição de dados. Nosso propósito
neste conteúdo é realizar um projeto de um banco de dados
distribuído.
Confira o vídeo!
 

21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 3/63
1 - Fundamentos de projeto de banco de dados distribuídos
Ao �nal deste módulo, você será capaz de identi�car a sistemática de projetos de banco de
dados distribuídos.
Descrições de banco de dados
Confira no vídeo os tipos de descrição de banco de dados e veja como
diferenciá-los entre centralizados e distribuídos.
Descrição de bancos centralizados
A descrição de um banco de dados centralizado segue uma arquitetura
chamada de três esquemas, que corresponde a três níveis de abstração.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 4/63
Vejamos quais são eles!
Esquema Conceitual
Corresponde ao nível lógico, apresentando uma visão de alto nível do
banco de dados. É totalmente independente da forma de
armazenamento e se baseia apenas na semântica do negócio
modelado.
Esquema Interno
Corresponde ao nível físico, apresentando os métodos de acesso aos
dados, bem como as estruturas de armazenamento utilizadas.
Esquema Externo
Corresponde ao nível externo, apresentando as diversas visões que os
usuários possuem do banco de dados, que são definidas com base no
nível lógico, facilitando o desenvolvimento das diversas aplicações.
Observe agora a arquitetura de três esquemas de um banco de dados
centralizado.
Descrição de bancos centralizados.
Importante observar que o nível interno é o único que armazena dados,
os demais correspondem apenas a descrições dos dados armazenados.
Descrição de bancos de dados distribuídos
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 5/63
A descrição de um banco de dados distribuído (BDD) deve refletir tanto
os aspectos do banco de dados global quanto do banco de dados local,
tornando transparente aos usuários a localização e a replicação de
dados e mantendo a autonomia dos sistemas locais.
Como a distribuição do BDD deve ser transparente a nível logico, seu
esquema conceitual global deve ser entendido como se fosse um banco
centralizado. Deve contemplar também vários esquemas externos
globais descrevendo as visões do BDD para os grupos de usuários.
Desse modo, o nível externo global e o conceitual global são muito
similares ao externo e ao conceitual de bancos centralizados.
O mapeamento do conceitual global para o nível interno é bem diferente.
Isso porque o nível interno em BDD corresponde aos bancos locais que,
para manterem a sua autonomia local, necessitam de um esquema
conceitual local mapeado a partir do conceitual global e que representa
o nível lógico do banco local, o qual por sua vez, será mapeado para o
nível interno local.
Descrição de bancos distribuídos.
O banco local se comporta para seus usuários locais como um banco
centralizado, possuindo os níveis locais: externo, conceitual e interno.
Veja!
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 6/63
Descrição de bancos locais.
Técnicas para projeto de banco de
dados distribuídos
Confira no vídeo alguns princípios para projetos de banco de dados
distribuídos, identificando e exemplificando as abordagens top-down e
bottom-up.
Princípios para o projeto de BDD
O projeto de um BDD é uma especificação formal de alto nível do
esquema de um banco de dados. Desde o início, deve-se considerar se a
solução distribuída é realmente uma opção viável, o que implica
detectar se o banco é fortemente integrado ou se pode ser distribuído
em partes razoavelmente independentes.
Além disso, deve ser determinado se existe vantagem em descentralizar
o banco para tal. Para isso, são necessárias as seguintes medidas:
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 7/63
Analisar o perfil das transações existentes.
Avaliar se o custo de transmissão de dados cairá em caso de
distribuição.
Analisar se as visões de dados dos usuários, locais e globais,
poderão ser atendidas após a distribuição.
Para o projeto de banco de dados distribuídos, duas abordagens podem
ser utilizadas: a top-down e a bottom-up.
A primeira ocorre normalmente no desenvolvimento de um novo
sistema, levantando-se inicialmente as necessidades da empresa como
um todo e projetando o banco global. Em seguida, se projeta a
distribuição projetando os bancos locais.
A abordagem bottom-up corresponde, normalmente, à integração de
bancos já existentes, ou seja, de banco locais que serão mapeados para
um banco global.
Abordagem top-down
Nessa abordagem, o projeto do esquema conceitual global e do
esquema externo global é semelhante ao caso centralizado, pois o
banco global irá se comportar como se fosse centralizado para os
usuários globais.
Os projetos conceituais locais são também similares a um banco
centralizado, atendendo às necessidades dos usuários locais. A grande
diferença dessa abordagem é a existência de uma etapa que determina
como a distribuição será realizada, e isso pode acontecer de duas
maneiras:
Fragmentação ou particionamento
É quando uma tabela do esquema global é mapeada para duas ou mais
tabelas no esquema local que não são idênticas à tabela global.
Replicação
É caracterizada por uma tabela global “copiada integralmente” para um
banco de dados local.
Na escolha da estratégia de distribuição, devem ser considerados os
seguintes fatores:
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 8/63
Na fragmentação, o banco não fica limitado à memória secundária
do servidor e, em comparação com uma solução centralizada,
aumenta a confiabilidade e eficiência se a maioria das consultas
acessa apenas dados locais.
Na replicação, ocorre um aumento da confiabilidade e da
disponibilidade, mas apresenta o problema de como propagar as
atualizações ocorridas em um dos sites para os outros e exige mais
memória secundaria local.
Veja a seguir um resumo das estratégias de distribuição que demonstra
qual solução deve ser aplicada com base na frequência com que uma
transação necessita de dados que não estão armazenados (% de
exceções) localmente e o tamanho do arquivo.
% de exceções
Tamanho do
arquivo
Método de
distribuição
--- Pequeno Replicação
Pequena Grande Fragmentação
Alta Grande Centralizado
Tabela: Estratégiasde distribuição.
Adaptado de Casanova, 1999.
A seguir, veja as etapas da abordagem top-down.
 Especi�cação de requisitos
Corresponde à coleção de cenários de uso dos
dados do banco.
 Esquema conceitual global
Modelo criado para atender às visões necessárias
aos usuários globais.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 9/63
Agora confira a representação da abordagem top-down para melhor
assimilar as informações!
 Restrições tecnológicas
Informações das necessidades das aplicações e
dos requisitos e recursos de comunicação de
dados.
 Projeto de distribuição
Aplicação das técnicas de distribuição ao banco de
dados global.
 Banco local
É o banco de dados a ser criado em cada site,
considerando os esquemas conceitual, interno e
externo local.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 10/63
Abordagem top-down.
Abordagem bottom-up
Nesta abordagem as informações dos bancos de dados locais são
integradas para formar o banco global. Essa integração pode ser
realizada de duas maneiras:

Primeira
Definindo o esquema conceitual global e, em seguida, realizando o
mapeamento dos esquemas locais, como ocorre normalmente no
projeto de data warehouse.
Data warehouse
É um repositório central de informações que podem ser analisadas
para tomar decisões mais adequadas. Os dados fluem de sistemas
transacionais, bancos de dados relacionais e de outras fontes para o
data warehouse.

Segunda
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 11/63
Definindo o esquema conceitual global como uma integração de partes
dos esquemas conceituais locais, o que envolve a geração do primeiro a
partir do mapeamento dos bancos locais para o global.
O projeto ascendente ocorre em duas etapas:
Quando o esquema do banco local é traduzido para alguma
forma intermediária, como o MER, que facilite o seu
mapeamento para o Esquema Global.
Quando as representações intermediárias dos bancos locais são
utilizadas para gerar o esquema conceitual global consistindo no
uso de três técnicas:
Combinação de esquemas determinando as
correspondências sintáticas e semânticas entre os
elementos locais traduzidos.
Integração dos elementos do esquema comum em um
esquema conceitual global.
Mapeamento do esquema que determina como mapear os
elementos de cada esquema local para os outros
elementos do esquema global.
A seguir, veja a estrutura da abordagem Botton-up.
Abordagem bottom-up.
Tradução do esquema 
Geração do esquema 
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 12/63
Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
A abordagem top-down do projeto de banco de dados distribuídos
normalmente ocorre no desenvolvimento de novos sistemas. A
respeito dessa abordagem podemos afirmar que:
O projeto dos esquemas externo global e conceitual global é similar
ao realizado no projeto de um banco centralizado.
PORQUE
Em bancos de dados distribuídos, o banco global irá atuar como se
fosse centralizado para os usuários globais.
Quanto às duas afirmativas, assinale a alternativa correta.
Parabéns! A alternativa A está correta.
Em BDD temos os usuários locais e os globais. Para os usuários
globais, o banco deve tornar transparente toda e qualquer
distribuição de dados, dando-lhes a impressão de ser um único
A
As duas afirmações estão corretas e a segunda
justifica a primeira.
B
As duas afirmações estão corretas e a segunda não
justifica a primeira.
C A primeira afirmação é correta e a segunda falsa.
D A primeira afirmação é falsa e a segunda correta.
E As duas afirmações são falsas.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 13/63
banco centralizado. Por esse motivo, como as consultas globais
envolvem todo o banco, a modelagem de suas visões e o esquema
conceitual seguem os mesmos princípios dos bancos
centralizados.
Questão 2
A respeito de como podemos descrever bancos de dados
distribuídos, podemos afirmar que:
I. Esquema interno existe apenas a nível local.
II. Esquema conceitual existe apenas a nível global.
III. Esquemas externos existem tanto a nível local como global.
Está correto o que se afirma
Parabéns! A alternativa E está correta.
A afirmativa I está correta já que não existe esquema interno global,
pois os itens físicos de dados existem apenas no nível local. A
afirmativa III está correta porque o esquema externo existe nos dois
níveis.
A somente em I.
B somente em II.
C somente em III.
D em I e II.
E em I e III.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 14/63
2 - Fragmentação
Ao �nal deste módulo, você será capaz de analisar as técnicas de particionamento de uma
tabela.
Princípios de fragmentação
Confira no vídeo os princípios da fragmentação em banco de dados
distribuídos, como também os motivos, formas e regras de correção da
fragmentação.
Motivos para fragmentar
A fragmentação de um BD corresponde ao particionamento de suas
tabelas entre vários sites, permitindo que o conteúdo original possa ser
reconstruído a partir de operações da álgebra relacional. Podemos fazer
então uma pergunta:
A fragmentação é realmente necessária?
Do ponto de vista específico da distribuição de dados, não. Poderíamos
simplesmente replicar o banco de dados entre os vários sites, porém
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 15/63
questões de desempenho e gastos com a comunicação de dados
podem recomendar que ela seja realizada. Veja a seguir alguns dos
fatores que recomendam a fragmentação.

O tamanho do arquivo: quando muito grande e devido à alta taxa de
acesso, dificulta o suporte por um único site do sistema.

A taxa de acesso às diferentes partes dos dados pelos diversos sites:
dados mais acessados por um local devem estar armazenados nele
visando minimizar os custos de comunicação.

A busca por melhorias na concorrência das transações: direcionar o
acesso apenas aos fragmentos envolvidos na sua execução.
A fragmentação possui então as seguintes vantagens:
Aumento do desempenho, pois os dados são armazenados nos
bancos locais onde são mais utilizados.
Aumento do paralelismo na execução de consultas quando elas
atuam em fragmentos diferentes armazenados em sites
distintos.
Vantagem 1 
Vantagem 2 
Vantagem 3 
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 16/63
Aumento da confiabilidade, pois os dados estão armazenados
em diversos locais diferentes.
Formas de fragmentação
O banco composto de fragmentos é denominado banco particionado,
sendo a tabela a unidade básica de armazenamento de dados no
modelo relacional. A fragmentação então corresponde a dividir uma
tabela em tabelas menores.
Existem duas alternativas básicas para fazer essa fragmentação:
Dividir a partir da seleção de suas tuplas (fragmentação horizontal).
Dividir a partir de projeção de suas colunas (fragmentação vertical).
É possível ainda realizar as duas fragmentações de forma aninhada
caracterizando a fragmentação híbrida.
Regras de correção da fragmentação
Durante o processo de particionamento do banco de dados, devemos
observar três regras a fim de não gerar perda semântica:
 Completeza
Quando uma tabela for decomposta em
fragmentos, temos de garantir que todos os itens
de dados da tabela original apareçam em pelo
menos um dos fragmentos. No caso da
fragmentação horizontal, todas as linhas da tabela
original devem estar em algum fragmento.No caso
da fragmentação vertical, o conjunto de colunas
dos fragmentos deve conter todas as colunas da
tabela original.
 Reconstrução
Quando uma tabela for fragmentada deve ser
possível reconstituir o seu conteúdo original a partir
d õ d ál b l i l li d
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 17/63
Alternativas de alocação
Com o banco particionado adequadamente, a próxima preocupação é
em quais sites alocar os fragmentos. Nesse caso, duas soluções são
possíveis:
Replicar o mesmo fragmento em mais de um site (banco replicado).
A vantagem dessa solução é a confiabilidade e eficiência das
consultas apenas de leitura que podem ser executadas em paralelo.
Como desvantagem, há necessidade de lidar com as atualizações
de dados que devem ser realizadas nas várias réplicas.
Alocar cada um dos fragmentos em um único site (banco
particionado). Nessa solução, existe apenas uma cópia de qualquer
fragmento na rede.
Com relação ao banco replicado, existem duas variantes:
Totalmente replicado
Quando o banco de dados existe em sua totalidade em cada site.
Parcialmente replicado
Quando os fragmentos são distribuídos para os sites de modo que as
cópias de um fragmento podem residir em vários sites.
de operações da álgebra relacional aplicada aos
seus fragmentos.
 Disjunção
Ocorre quando, durante a fragmentação horizontal,
determinado item de dados está presente em
apenas um dos fragmentos. Já a fragmentação
vertical ocorre quando as colunas que não são
parte da chave primária da tabela de origem
aparecem apenas em um dos fragmentos.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 18/63
Confira a seguir uma comparação das diversas soluções de
fragmentação/replicação.
Totalmente
replicado
Parcialmente
replicado
Processamento de
consultas
Fácil
Dificuldade
moderada
Controle de
concorrência
Moderada Difícil
Confiabilidade Muito Alta Alta
Tabela: Soluções de fragmentação/replicação.
Sidney Nicolau Venturi Filho.
Fragmentação horizontal
Confira no vídeo o uso da fragmentação horizontal no particionamento
de tabelas de um banco de dados distribuídos.
Particionando uma tabela horizontalmente
Nesse tipo de fragmentação, o particionamento gera um conjunto de
linhas selecionadas do valor de um ou mais atributos da tabela
definidos a partir de um requisito lógico de informação.
O fragmento horizontal é obtido a partir de uma operação de seleção da
álgebra relacional especificada por “σ Condição (Tabela)”.
Para permitir a reconstrução da tabela original, cada uma de suas linhas
deve pertencer a pelo menos um fragmento.
A reconstrução é obtida a partir da operação de união (U) de todos os
fragmentos. Veja!
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 19/63
Em que:
TO – Tabela original.
Fx – Fragmento X.
O objetivo desse tipo de particionamento é diminuir o tempo de acesso
aos dados, pois, em uma tabela muito grande, com milhares ou milhões
de linhas, a consulta sempre irá demorar mais do que a realizada em
tabelas menores, obtidas a partir dos fragmentos.
Os nomes das tabelas geradas pelo particionamento são normalmente
aqueles das tabelas de origem ou pelo menos uma variação, facilitando
a administração dos subconjuntos.
Exemplo
Origem Projetos, Fragmentos ProjetosRJ, ProjetosSP etc.
Exemplo de fragmentação horizontal
Observe o conteúdo e a estrutura da tabela Projetos.
Código Valor Cidade
P01 100.000 Rio de Janeiro
P02 120.000 São Paulo
P03 80.000 Belo Horizonte
P04 75.000 São Paulo
P05 100.000 Rio de Janeiro
Tabela: Projetos.
Sidney Nicolau Venturi Filho.
Para criarmos dois fragmentos, um referente aos projetos de São Paulo
e outro do Rio de Janeiro, poderíamos utilizar as seguintes operações
algébricas:
TO = F1 U F2 U F3 U ... U Fn 
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 20/63
Seriam, então, geradas as seguintes tabelas:
ProjetosSP
Código Valor Cidade
P02 120.000 São Paulo
P04 75.000 São Paulo
Tabela: Fragmentos de Projetos.
Sidney Nicolau Venturi Filho.
ProjetosRJ
Código Valor Cidade
P01 100.000 Rio de Janeiro
P05 100.000 Rio de Janeiro
Tabela: Fragmentos de Projetos.
Sidney Nicolau Venturi Filho.
Observe que o particionamento realizado é incompleto, não sendo
possível reconstruir a tabela original, uma vez que a linha de Belo
Horizonte não está presente nos fragmentos.
Fragmentação incompleta.
ProjetosSP = σCidade = ‘São Paulo” (Projetos)
ProjetosRJ = σCidade = ‘Rio de Janeiro” (Projetos)
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 21/63
Para completar o particionamento, precisamos criar a tabela ProjetoBH
com a expressão:
A tabela gerada pela expressão é a seguinte:
ProjetosBH
Código Valor Cidade
P03 80.000 Belo Horizonte
Tabela: Fragmentação ProjetoBH.
Sidney Nicolau Venturi Filho.
Observe a seguir a ocorrência tanto da disjunção, uma vez que cada
linha da tabela original aparece em apenas um dos fragmentos, quanto
da completeza, já que todas as linhas de Projetos aparecem em pelo
menos um fragmento.
Fragmentação com disjunção.
Fragmentação vertical
Assista ao vídeo e compreenda a implementação da fragmentação
vertical em banco de dados distribuídos. Veja ainda na prática um
exemplo desse tipo de fragmentação.
ProjetosBH = σCidade = ‘Belo Horizonte” (Projetos)
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 22/63
Particionando uma tabela verticalmente
A fragmentação vertical equivale realizar a decomposição de uma
tabela dividindo as suas colunas por vários fragmentos.
O fragmento vertical é obtido a partir de uma operação de projeção da
álgebra relacional especificada por " colunas (Tabela)".
A reconstrução da tabela é realizada a partir da junção dos vários
fragmentos utilizando como chave de junção uma coluna comum entre
as tabelas, normalmente a chave primária da tabela original.
Em que:
TO – Tabela original.
Fx – Fragmento X.
C1 – Coluna comum às tabelas envolvidas na junção.
Como podemos notar pela expressão de reconstrução, todos os
fragmentos devem possuir uma coluna em comum, normalmente a
chave primária da tabela que foi particionada, pois se este atributo não
existir nos fragmentos, não será possível realizar a reconstrução da
tabela de origem.
Em algumas situações, os projetistas podem também incluir nos
fragmentos um atributo especial denominado identificador de
tupla(tupla_id), cujo valor deve ser único, permitindo a identificação
única da tupla no contexto do banco de dados, atuando de forma similar
a uma chave candidata.
Note que, nesse modelo de particionamento, todas as linhas da tabela
de origem aparecem em cada fragmento.
O particionamento vertical tem como objetivo agrupar os registros por
colunas de interesse para diminuir o tempo de acesso aos dados.
Para definir as colunas que devem fazer parte de um fragmento, existem
duas abordagens possíveis:
π
(⋈)
TO = F1 ⋈(C1=C1) F2 ⋈(C1=C1) F3 ⋈(C1=C1) … ⋈(C1=C1) Fn
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 23/63
Agrupamento
Começa atribuindo cada atributo a um fragmento e vai juntando outros
atributos até achar os que satisfazem os requisitos da aplicação.
Divisão
Começa com uma relação e define como particionar de acordo com o
comportamento de acesso aos atributos. Esse método se ajusta de
forma mais natural dentro da metodologia de projeto top-down.
Exemplo de fragmentação vertical
Observe, a seguir, a estrutura da tabela Projetos, cuja coluna Código é
sua chave primária.
Código Valor Coordenador
P01 100.000João Guilherme
P02 120.000 Pedro Ivo
P03 80.000 Maria Silva
P04 75.000 João Guilherme
P05 100.000 José Piva
Tabela: Projetos.
Sidney Nicolau Venturi Filho.
Para criarmos dois fragmentos, um referente às cidades dos projetos e
outro ao valor dos projetos, podemos utilizar as seguintes operações
algébricas:
Note que, para permitir a reconstrução, a chave primária Código foi
projetada nos dois fragmentos. Seriam então geradas as tabelas a
seguir.
ProjetosCidade = πCodigo, Cidade (Projetos)
ProjetosValor = πCodigo, Cidade (Valor)
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 24/63
ProjetosValor
Código Valor
P01 100.000
P02 12.000
P03 80.000
P04 75.000
P05 100.000
Tabela: Fragmentos verticais.
Sidney Nicolau Venturi Filho.
ProjetosCidade
Código Cidade
P01 Rio de Janeiro
P02 São Paulo
P03 Belo Horizonte
P04 São Paulo
P05 Rio de Janeiro
Tabela: Fragmentos verticais.
Sidney Nicolau Venturi Filho.
Com esses dois fragmentos não é possível realizar a reconstrução. O
particionamento não foi completo porque duas colunas não aparecem
nos fragmentos. Veja quais!
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 25/63
Fragmentação vertical incompleta.
Para atender à completeza e obter a disjunção, precisamos criar um
terceiro fragmento a partir da seguinte expressão:
Observe que agora temos todos os atributos da relação original nos
fragmentos e estes são disjuntos, pois somente a chave primária de
Projetos (Código) se repete, sem o que seria impossível realizar a
reconstrução.
Fragmentação vertical completa e disjunta.
Fragmentação híbrida
Assista ao vídeo e compreenda a implementação da fragmentação
híbrida em banco de dados distribuídos. Veja ainda na prática um
exemplo desse tipo de fragmentação.
ProjetosOutros = πCodigo, Coordenador, Area Cidade (Projetos)
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 26/63
Particionando uma tabela de forma híbrida
A fragmentação híbrida ou mista consiste em realizar um
particionamento horizontal seguido de um vertical ou vice-versa.
Observe!
Fragmentação híbrida ou mista.
O nível de particionamentos aninhados pode ser grande, mas estes
fatores devem ser observados:
Deve-se parar o particionamento horizontal quando cada fragmento
consistir em uma única tupla.
Deve-se parar o particionamento vertical quando temos um único
atributo não chave por fragmento.
As regras de completeza, reconstrução e disjunção decorrem de forma
natural das regras para as fragmentações horizontal e vertical.
Para a reconstrução, serão realizadas as operações de junção entre os
fragmentos verticais e de união entre os horizontais, na ordem que for
apropriada para o particionamento realizado.
Exemplo de fragmentação híbrida
Veja agora o conteúdo e a estrutura da tabela Projetos, cuja coluna
Código é sua chave primária.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 27/63
Código Valor Cidade
P01 100.000 Rio de Janeiro
P02 120.000 São Paulo
P03 80.000 Belo Horizonte
P04 75.000 São Paulo
P05 100.000 Rio de Janeiro
Tabela: Projetos.
Sidney Nicolau Venturi Filho.
Vamos realizar um particionamento híbrido criando um fragmento com
o valor e código dos projetos na cidade do Rio de Janeiro.
Nesse processo, inicialmente, realizaremos o particionamento
horizontal com a expressão:
Na sequência, a partir do fragmento horizontal, realizaremos o
particionamento vertical com esta expressão:
Confira o passo a passo do particionamento híbrido realizado.
Geração do fragmento ProjetosHV1.
ProjetosH1 = σCidade = ‘Rio de Janeiro”  (Projetos)
ProjetosHV1 = πCodigo, Valor  (ProjetosH1)
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 28/63
Vamos agora criar um fragmento misto com as cidades que possuem
projetos com valor inferior a 100.000.
Ao contrário da situação anterior, vamos realizar uma única operação
algébrica aproveitando o fato de que podemos aninhar a seleção dentro
da projeção, gerando direto o fragmento final. A expressão será:
Observe a ilustração do processo a seguir.
Geração do fragmento ProjetosHV2.
Os projetistas de BDD devem ter em mente que a fragmentação híbrida,
muitas vezes, gera um particionamento incompleto que inviabiliza a
reconstrução da tabela de origem.
Veja a situação de nosso exemplo, no qual os fragmentos não
contemplam grande parte dos itens de dados da tabela Projetos.
Particionamento sem completeza.
O projetista deve então providenciar a criação de outros fragmentos que
permitam a reconstrução ou manter uma cópia da tabela original no
banco de dados global.
ProjetosHV2 = πCodigo, Cidade (σValor < 100.000(Projetos))
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 29/63
Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
A imagem a seguir mostra a fragmentação realizada na tabela
Projetos.
A respeito da fragmentação realizada, podemos afirmar que:
Ela viola a regra da disjunção.
PORQUE
A disjunção se caracteriza por não existirem colunas repetidas em
mais de um fragmento.
Quantos às afirmativas, assinale a alternativa correta.
A
As duas afirmações estão corretas e a segunda
justifica a primeira.
B
As duas afirmações estão corretas e a segunda não
justifica a primeira.
C A primeira afirmação é correta e a segunda falsa.
D A primeira afirmação é falsa e a segunda correta.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 30/63
Parabéns! A alternativa D está correta.
Realmente, a regra de disjunção não permite colunas repetidas em
mais de um fragmento, o que torna a segunda afirmativa verdadeira.
Porém, a fragmentação realizada foi a vertical, que cria uma
exceção, sendo esse o caso da chave primária da tabela de origem
que deve ser repetida em todos os fragmentos para permitir a
reconstrução da tabela original a partir dos fragmentos.
Esse fato torna a primeira afirmativa falsa.
Questão 2
A imagem a seguir mostra fragmentos gerados a partir da tabela
Projetos. Observe:
A respeito desses fragmentos, podemos afirmar que:
I. O fragmento 1 foi gerado por uma fragmentação vertical.
II. O fragmento 2 foi gerado por uma fragmentação horizontal.
III. O fragmento 3 foi gerado por uma fragmentação vertical.
IV. O fragmento 4 foi gerado por uma fragmentação horizontal.
Estão corretas as afirmativas
E As duas afirmações são falsas.
A I e II.
B II e III.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 31/63
Parabéns! A alternativa A está correta.
Da análise dos fragmentos, podemos notar que o fragmento 1 foi
gerado por uma fragmentação vertical; o fragmento 2 foi gerado por
uma fragmentação horizontal; o fragmento 3 por uma
fragmentação mista; e o fragmento 4 também por uma
fragmentação mista. Portanto, estão corretas as afirmativas I e II.
3 - Replicação
Ao �nal deste módulo, você será capaz de identi�car as características da replicação.
Fundamentos de replicação
Assista ao vídeo e entenda os fundamentos de replicação em banco de
dados distribuídos. Veja ainda os principais motivos para a replicação,
C III e IV.
D I e III.
E I e IV.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 32/63
assim como os desafios e fatores que a influenciam.
Motivos para replicar os dados
Os bancos de dados distribuídos possuem normalmente algum grau de
replicação pelos seguintes motivos:
Os BDD, por meio da replicação, removempontos únicos de falha
devido aos itens de dados serem acessíveis a partir de mais de
um site. Desse modo, se um local estiver indisponível, o dado
poderá ser acessado em outro.
Um dos principais fatores que aumentam o tempo de resposta é
a sobrecarga de comunicação, entretanto a replicação permite
localizar os dados mais próximos de seu ponto de acesso, o que
contribui para tornar a resposta mais rápida.
O crescimento dos sistemas em número de sites e diversidade
geográfica acarreta o aumento no número de solicitações de
acesso; a replicação oferece suporte para esse crescimento,
mantendo o tempo de resposta aceitável.
Replicação pode ser ditada pelos aplicativos, que podem desejar
manter várias cópias de dados como parte de suas
Disponibilidade do sistema 
Desempenho 
Escalabilidade 
Requisitos de aplicação 
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 33/63
especificações operacionais.
Desa�o inerentes à replicação de dados
Apesar de seus benefícios, a replicação apresenta o desafio de manter
as diversas cópias sincronizadas e coerentes entre si.
Comentário
Em bancos replicados, cada item de dados replicado “x” tem um número
de cópias (x1, x2,...xn), considerando “x” como um item de dado lógico e
suas cópias (ou réplicas) como os itens de dados físicos.
Para se obter a transparência de replicação, as transações de usuários
devem poder emitir comandos de leitura ou escrita nos dados lógicos,
sem se preocupar com a localização ou o estado dos dados físicos.
Visando efetivar essa transparência, o protocolo de controle de réplica
realiza o mapeamento das operações do dado lógico para os dados
físicos, fazendo o sistema se comportar como se existisse apenas uma
cópia de cada item de dado.
Fatores que afetam o projeto de replicação de dados
Conheça alguns fatores capazes de afetar o projeto de replicação de
dados.
 Projeto de banco de dados
Um banco de dados distribuído pode ser total ou
parcialmente replicado. No caso de um banco de
dados parcialmente replicado, o número de itens de
dados físicos para cada item de dados lógicos pode
variar, e alguns itens de dados podem até não ser
replicados. Nesse caso, as transações que
acessam apenas itens de dados não replicados são
transações locais (uma vez que podem ser
executadas localmente em um site) e sua execução
normalmente não nos interessa. As transações que
acessam itens de dados replicados devem ser
executadas em diversos sites e são transações
globais.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 34/63
 Consistência do banco de dados
Quando transações globais atualizam cópias de um
item de dados em sites diferentes, os valores
dessas cópias podem ser diferentes em
determinado ponto no tempo. Diz-se que um banco
de dados replicado está em um estado
mutuamente consistente se todas as réplicas de
cada um de seus itens de dados tiverem valores
idênticos.
 Local onde as atualizações são realizadas
As atualizações podem ser realizadas de maneira
centralizada, se primeiro ocorrerem em uma cópia
mestre, ou de maneira distribuída, se realizadas
primeiro em qualquer uma das réplicas. Técnicas
centralizadas podem ser ainda identificadas como
um mestre único, quando há apenas uma cópia do
banco de dados mestre no sistema, ou cópia
primária, quando a cópia mestre de cada item de
dados pode ser diferente.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 35/63
Outros aspectos da replicação
Métodos de replicação
Em sistemas de banco de dados, toda replicação necessita dos
mecanismos para realizar as alterações feitas em dados replicados.
Vejamos quais são eles:
Cópia as transações marcadas para replicação para uma área de
preparação para transmissão. Essa técnica possui a vantagem
de ter baixo impacto no servidor porque exige o mínimo do uso
 Propagação de atualização
Após a atualização inicial em uma réplica (mestre
ou não), ela deve ser propagada a todas as outras.
Uma alternativa é executar todas as atualizações
dentro do contexto da transação global que gerou a
primeira atualização (replicação síncrona), sendo
que, quando a transação inicial é confirmada, todas
as réplicas também estarão atualizadas. A segunda
alternativa (replicação assíncrona) propaga as
atualizações algum tempo depois que a transação
a qual gerou a primeira atualização foi confirmada.
Por conta disso, durante algum tempo, as várias
cópias podem ser inconsistentes entre si.
 Grau de transparência da replicação
Algumas soluções de replicação exigem que a
aplicação conheça o site mestre em que as
atualizações devem ser realizadas, limitando a
transparência, ao contrário de outras que fornecem
transparência total utilizando um gerenciador de
transações em cada site, que fica responsável por
receber do usuário as solicitações e as propagar
para os demais locais.
Log de transações 
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 36/63
de processador quando está lendo o log em memória e
escrevendo em disco.
Propagam, em uma tabela de log, as mudanças quando elas
ocorrem, para transmissão posterior.
Para a implementação desses métodos, pode ser utilizada a própria
linguagem procedural do SGBD.
Existem ainda diversas ferramentas no mercado que permitem
configurar a replicação, síncrona ou assíncrona, como GoldenGate para
Oracle, PGpool II para PostgreSql, entre tantas outras.
Con�itos de replicação
Quando lidamos com replicação, uma série de conflitos pode ocorrer
devido ao fato de duas transações diferentes atualizarem réplicas
armazenadas em bancos distintos. Para obter a convergência, os
conflitos de atualização devem ser detectados e resolvidos, visando
garantir que o item de dado possua o mesmo valor em todos os bancos
de dados.
Uma forma de diminuir a ocorrência dos conflitos é realizar a
propagação das atualizações com maior frequência. Além disso, uma
gerência adequada dos direitos de atualização pelos usuários também
irá contribuir para minimizar a situação.
Confira a seguir alguns exemplos de conflitos que podem ocorrer:
Con�ito de update
Ocorre quando duas ou mais transações atuando em réplicas diferentes
atualizam o mesmo item de dados no mesmo instante. A redução do
intervalo de tempo entre as replicações minimiza muito sua ocorrência.
Con�ito de chaves únicas e sequenciais
Ocorre quando duas ou mais transações tentam fazer a inserção de
uma linha na mesma tabela com a mesma chave (primary key ou unique
key), causando a violação de integridade.
Con�ito de delete
Log triggers (gatilhos) 
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 37/63
Ocorre quando duas ou mais transações tentam, ao mesmo instante,
deletar a mesma linha de uma tabela. Nesse caso, só a primeira
transação obterá sucesso e a segunda gerará um erro, pois a linha não
mais existirá.
Fique ligado agora nos tipos de cópias de dados, extratos e réplicas!
Extratos
Confira no vídeo os fundamentos de replicação do tipo extrato em banco
de dados distribuídos.
Tipos de extratos
Extratos são cópias de itens de dados que não sofrem atualizações
diretamente pelas transações, sendo muito úteis para aplicações que
demandem apenas a recuperação (consulta) de dados.
Os extratos podem ser classificados em simples, associado a uma data
hora, controlado e periodicamente atualizado.
Conheça cada tipo de extrato!
Extrato simples
Normalmente utilizado para compor bancos de dados em sistemas de
suporte à decisão e para dados não voláteis, por exemplo, para dados
históricos.
Para produzir extratos simples, normalmente são utilizados utilitários ou
programas de aplicação batch, queacessam o banco de dados de
origem e copiam as linhas das tabelas com conteúdo a ser propagado,
gerando uma tabela que possa ser apenas consultada e realizando a
chamada exportação de dados.
Cabe observar que a exportação de dados permite o formato dos dados
e as estruturas dos bancos de origem e de destino serem diferentes.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 38/63
Exportação de dados no extrato simples.
Extrato associado a uma data hora
Também conhecido como snapshot, consiste em uma variação do
extrato simples que faz referência a um ponto no tempo. Isso permite
que a aplicação ou o usuário avalie a utilidade do dado ou a
necessidade da sua substituição por um extrato mais atual.
Para passar a referência de tempo, o BD de origem envia do destino,
além das linhas, uma informação referente ao instante de tempo
(timestamp) em que o extrato foi gerado.
Exportação de dados no extrato associado a uma data hora.
Extrato controlado
Similar ao associado a uma data hora, envia ao BD de destino,
juntamente com as linhas, uma informação que o vincula a um
somatório de valores, substituindo o timestamp por um valor agregado.
Essa informação agregada permite à aplicação estabelecer uma
correlação entre a porção copiada e o valor total. É produzido também
utilizando a exportação de dados.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 39/63
Exportação de dados no extrato controlado.
Extrato periodicamente atualizado
O seu funcionamento inclui a realização do controle da passagem do
tempo necessário para realizar uma cópia substitutiva.
O tempo decorrido antes do descarte do extrato atual e sua substituição
por um novo é definido pelas necessidades dos usuários e das
aplicações na fase de projeto da replicação.
O mecanismo básico de funcionamento consiste na criação de um
procedimento em batch executado periodicamente que gera um novo
extrato e substitui o antigo nos diversos sites.
Nesse tipo de replicação, podem ser utilizados utilitários existentes no
próprio SGBDD ou programas desenvolvidos especificamente para a
tarefa, sendo o seu controle realizado pelos administradores do banco
de dados.
Existem dois métodos usados para criar um extrato periodicamente
atualizado:

Realizar uma cópia completa para o BD de destino em cada intervalo.
Esse método é mais simples e pode ser preferido para pequenos
extratos.

Realizar uma cópia completa e executar cópias incrementais em cada
intervalo. Esse método minimiza o fluxo de dados.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 40/63
A seguir, observe o esquema de manipulação de dados no extrato
periodicamente atualizado.
Esquema de manipulação de dados no extrato periodicamente atualizado.
Réplicas
Confira no vídeo os fundamentos de replicação do tipo réplica em banco
de dados distribuídos.
O que são réplicas?
Denominamos réplica a cópia de itens de dados que podem ser
atualizados em qualquer um dos sites onde estejam localizados.
A atualização de uma réplica exige que essa alteração seja propagada
para todos os outros sites que possuem a mesma réplica, a fim de
manter a consistência dos dados. Essa propagação pode ser realizada
de forma síncrona ou assíncrona.
Atualização síncrona
Na atualização síncrona, todas as réplicas da tabela devem ser
atualizadas simultaneamente durante o processamento da transação
que modificou os dados.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 41/63
Possui como principal vantagem a garantia da consistência dos dados
em todas as réplicas, permitindo que uma consulta em qualquer das
cópias produza o mesmo resultado.
Veja a seguir quais são as suas principais desvantagens.
 Intolerância às falhas
Como existem réplicas em sites diferentes, ao se
executar a propagação da atualização gerada por
uma transação, caso ocorra uma falha de rede ou
do servidor do SGBD em um dos sites, a transação
toda terá de sofrer rollback e ser desfeita, mesmo
nos sites em que a atualização tenha sido bem-
sucedida. Isso significa que ou todas as réplicas
são atualizadas ou nenhuma é modificada.
Rollback
Em tecnologias de banco de dados, um rollback
é uma operação que retorna o banco de dados a
algum estado anterior. As reversões são
importantes para a integridade do banco de
dados, pois significam que o banco de dados
pode ser restaurado para uma cópia limpa
mesmo após a execução de operações
incorretas.
 Perda de desempenho de transações
Quando uma transação atualiza uma das réplicas,
seu desempenho será afetado, aumentando o
tempo de seu processamento devido ao tempo
necessário para a propagação da atualização por
meio da rede de computadores. Além disso, em
cada um dos sites, a atualização irá concorrer pelo
uso de recursos com as transações locais do
próprio site.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 42/63
Esse tipo de replicação é o mais apropriado para aplicações comerciais
de tempo real, como bancos, caso em que é imprescindível todos os
servidores serem atualizados ao mesmo tempo. Essa necessidade de
rápida atualização implica a necessidade de utilizar meios de
transmissão de alta velocidade, garantindo a eficiência e eficácia do
processo. Isso acaba gerando custos muito elevados, o que não ocorre
com o tipo assíncrono.
Observe a seguir uma ilustração desse processo, note que o cliente
somente recebe a confirmação da efetivação da operação depois que
todos os sites confirmam a propagação para o servidor que originou a
atualização.
Troca de mensagens na replicação síncrona.
Atualização assíncrona
 Bloqueio do acesso às tabelas
Quando da realização das atualizações, as réplicas
necessitam ser bloqueadas, dependendo da
arquitetura do SGBD. Isso pode impedir inclusive as
operações de leitura impactando o tempo de
resposta às consultas dos usuários e,
eventualmente, até gerar um deadlock.
Deadlock
No contexto de sistemas operacionais, refere-se
a uma situação em que ocorre um impasse, e
dois ou mais processos ficam impedidos de
continuar suas execuções, ou seja, ficam
bloqueados, esperando uns pelos outros.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 43/63
Na atualização assíncrona, a propagação da atualização não ocorre
imediatamente, e sim é realizada em um momento posterior. Nesse
modelo, o replicador necessita montar um histórico das atualizações
que ocorreram no banco desde a última replicação; em um segundo
momento, ele as propaga.
É possível, portanto, definir o funcionamento do método assíncrono da
seguinte maneira:

Cópias do BD de origem são geradas e exportadas para o BD destino.

Atualizações realizadas no banco de origem são registradas em um log
e, periodicamente, aplicadas às outras copias, restaurando a
consistência do banco de dados global.
A principal vantagem da atualização assíncrona é uma maior
flexibilidade se comparada com a síncrona. Se um servidor remoto
estiver inativo no momento da propagação, poderá ser atualizado
posteriormente. Como principal desvantagem, está o fato de que o
método permite inconsistências nos bancos de dados globais até que
todas as réplicas recebam a propagação das atualizações.
Observando o processo a seguir, podemos notar que o cliente recebe a
confirmação da efetivação da operação após o servidor que o atende
atualizar os seus dados, sem esperar que os demais sites confirmem a
atualização da propagação.
Troca de mensagens na replicação assíncrona.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html#44/63
Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
Quando Realizamos uma replicação síncrona podemos afirmar que:
A confirmação do término da transação ocorre após todos os nós
remotos confirmarem que a propagação da atualização foi
realizada.
PORQUE
Somente dessa forma a consistência do banco de dados global
pode ser mantida.
Quanto às afirmativas, assinale a alternativa correta.
Parabéns! A alternativa A está correta.
De fato, na atualização síncrona, o usuário somente recebe a
confirmação da transação após todos os nós envolvidos
confirmarem ao replicador que a atualização foi propagada. Esse
A
As duas afirmações estão corretas e a segunda
justifica a primeira.
B
As duas afirmações estão corretas e a segunda não
justifica a primeira.
C A primeira afirmação é correta e a segunda falsa.
D A primeira afirmação é falsa e a segunda correta.
E As duas afirmações são falsas.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 45/63
esquema permite que a consistência do banco de dados global seja
mantida.
Questão 2
Quanto aos tipos de extratos de dados podemos afirmar que:
Um extrato periodicamente atualizado é alterado de tempos em
tempos.
PORQUE
O extrato associado a uma data hora possui um timestamp.
Quanto às afirmativas, assinale a alternativa correta.
Parabéns! A alternativa B está correta.
As duas afirmativas estão corretas já que o extrato periodicamente
atualizado sofre atualização automática de tempos em tempos e o
extrato associado a uma data hora possui um timestamp. Porém,
como eles são tipos diferentes de extrato, a segunda afirmativa não
pode justificar a primeira.
A
As duas afirmações estão corretas e a segunda
justifica a primeira.
B
As duas afirmações estão corretas e a segunda não
justifica a primeira.
C A primeira afirmação é correta e a segunda falsa.
D A primeira afirmação é falsa e a segunda correta.
E As duas afirmações são falsas.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 46/63
4 - Modelagem e implementação de um BDD
Ao �nal deste módulo, você será capaz de formular um banco de dados distribuído.
Projetando o esquema conceitual
global
Confira no vídeo o passo a passo para criar um projeto em esquema
conceitual global de um banco de dados distribuídos.
Descrição do cenário
Considere que uma empresa de representação comercial, que realiza a
venda de remédios no atacado fornecendo produtos para farmácias
cadastradas, decidiu utilizar um banco de dados distribuído para fazer o
controle de seu negócio. Para que esse processo seja possível, os
seguintes requisitos devem ser atendidos:
 Cada remédio fornecido por um laboratório deve ser
identificado por um código, possuir um nome, seu
preço de compra e preço de tabela.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 47/63
Modelo conceitual global
Para criar esse modelo, utilizaremos o diagrama entidade-
relacionamento. Da análise do cenário, identificamos cinco entidades:
Laboratório, com os atributos CNPJ, Razão Social e Telefone.
 Cada laboratório deve ser identificado pelo seu
CNPJ e possuir sua razão social, nome e telefone
de contato.
 Cada remédio só pode ser fornecido por um e
apenas um laboratório.
 A venda é identificada unicamente pelo número da
nota fiscal e deve conter a data da venda.
 Cada venda deve possuir pelo menos um item de
venda, podendo ter vários, sendo que cada item
deve possuir o remédio, o preço unitário de venda
do remédio e a quantidade.
 A farmácia cliente deve ser identificada pelo CNPJ e
deve ter registrados no sistema a sua razão social e
seu telefone de contato.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 48/63
Remédio, com os atributos Código, Nome, Preço de Tabela e Preço
de Compra.
Item de Venda, com os atributos Número do item, Preço Unitário de
Venda e Quantidade Vendida.
Venda, com os atributos Número da Nota Fiscal e data.
Farmácia, com os atributos CNPJ, Razão Social e Telefone.
Além disso foram identificados os seguintes relacionamentos:
Fornecimento entre Laboratório e Remédio
Posse entre Item de Venda e Remédio
Posse entre Venda e Item de Venda
Referência entre Farmácia e Venda
Observe, a seguir, o DER gerado para atender aos requisitos.
DER do modelo conceitual global.
Modelo lógico global
Para a criação do modelo lógico, ficou determinado que o sistema seria
implementado utilizando os seguintes sistemas gerenciadores de banco
de dados relacional: Oracle, Sql Server ou PostgreSQL.
As entidades foram então mapeadas da seguinte maneira:

Laboratório para a tabela LABORATORIO que possui as colunas
CNPJ(PK), RAZAOSOCIAL e TELEFONE.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 49/63

Remédio para a tabela REMEDIO que possui as seguintes colunas
CODIGO(PK), NOME, PRECOTABELA, PRECOCOMPRA e CNPJ(FK para
LABORATORIO).

Item de Venda para a tabela ITEMVENDA que possui as colunas
NRITEM(PK), NRNOTA(PK e FK para VENDA), CODIGO(FK para
REMEDIO), QUANTIDADE e PRECOUNITARIO.

Venda para a tabela VENDA que possui as colunas NRNOTA(PK), DATA e
CNPJ (FK para FARMACIA).

Farmácia para a tabela FARMACIA que possui as colunas CNPJ(PK),
RAZAOSOCIAL e TELEFONE.
Os relacionamentos foram mapeados da seguinte forma:
 Fornecimento entre Laboratório e Remédio com a
chave estrangeira CNPJ na tabela REMEDIO para a
tabela LABORATORIO.
 Posse entre Item de Venda e Remédio com a chave
estrangeira CODIGO na tabela ITEMVENDA para a
tabela REMEDIO.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 50/63
Veja agora quais foram as regras para o tratamento dos atributos e
definição de seus tipos:
Os atributos que se referiam a dinheiro, ou seja, PRECOTABELA,
PRECOCOMPRA, PRECOUNITARIO, foram definidos como decimal.
O atributo data assumiu o tipo data.
Os atributos de Nome e Razão Social foram definidos como
caractere variável de 50.
Os atributos de telefone foram definidos como caractere de 13 (2
para o DDD, 9 para o número mais os dois parênteses).
Todos os atributos que referenciavam documentos ou códigos,
como CNPJ, Código de Barras do Remédio, Número da Nota Fiscal,
devido ao fato de poderem possuir zeros à esquerda, foram
definidos como caracteres com o seu tamanho obedecendo às
regras do tipo de código/documento.
Os demais atributos numéricos foram definidos como inteiros.
Observe o modelo relacional gerado pela modelagem lógica.
 Posse entre Venda e Item de Venda com a chave
estrangeira NRNOTA na tabela ITEMVENDA para a
tabela VENDA, além disso como ITEMVENDA se
originou de uma entidade fraca, NRNOTA foi
incluída como parte da chave primária composta da
tabela junto com o atributo discriminador NRITEM.
 Referência entre Farmácia e Venda com a chave
estrangeira CNPJ na tabela VENDA para a tabela
FARMACIA.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 51/63
Modelo lógico global.
Projetando os bancos locais
Confira no vídeo o passo a passo para criar um projeto em esquema
conceitual local de um banco de dados distribuídos.
Descrição do cenário dos bancos locais
A empresa de representação passou as seguintes informações para
balizar o projeto dos bancos locais:
 Ela possui um escritório central responsável por
atender os clientes de sua área e mais duas
sucursais que atendem clientes de outras áreas
geográficas.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 52/63
Modelagem conceitual elógica local do escritório central
Como o escritório central necessita de todos os dados para realizar o
seu trabalho, ou seja, a compra dos medicamentos e a venda para seus
clientes, o seu modelo conceitual local é igual ao global da empresa.
Veja!
DER do modelo conceitual local do escritório central.
O mesmo processo ocorre em relação ao modelo lógico, sendo igual ao
modelo global.
 Todas as negociações com os laboratórios para a
compra de remédios ocorrem de forma centralizada
no escritório central.
 O escritório central estabelece o preço de tabela do
remédio com base no preço de compra.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 53/63
Modelo lógico local do escritório central.
O script SQL da listagem abaixo demonstra os comandos de criação do
banco de dado local do escritório central para um SGBD genérico. Para
um SGBD específico, pode ser necessário fazer acertos nos tipos de
dados.
SQL 
Modelagem conceitual e lógica local das sucursais
Analisando as novas informações do cenário, podemos chegar as
seguintes conclusões a respeito da modelagem conceitual:
As sucursais não precisam dos dados dos laboratórios, pois
somente o escritório central interage com eles, portanto não
precisam enxergar a entidade Laboratório.
Pelo mesmo motivo, as sucursais não necessitam saber o preço de
compra do medicamento, já que o estabelecimento do preço de
tabela é feito pelo escritório central após analisar o preço de
compra.
Sabendo disso, observe a seguir o modelo conceitual local das
sucursais.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 54/63
DER do modelo conceitual local das sucursais central.
Em relação ao modelo lógico, a maior mudança em relação ao global é a
ausência da tabela LABORATORIO, da coluna PRECOCOMPRA na tabela
REMEDIO e a inexistência da FK para LABORATORIO na tabela REMEDIO.
Veja!
Modelo lógico local das sucursais.
O script SQL da listagem a seguir mostra os comandos de criação do
banco de dado local das sucursais para um SGBD genérico. Para um
SGBD específico, podem ser necessários acertos nos tipos de dados.
SQL 
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 55/63
Projetando a distribuição
Confira neste vídeo o projeto da distribuição de dados para um banco de
dados distribuído.
Descrição do cenário de distribuição
A empresa de representação passou as seguintes informações para
balizar o projeto da distribuição:
 O escritório central estabelece o preço de tabela do
remédio com base no preço de compra.
 Somente o escritório central pode cadastrar ou
alterar os dados dos remédios, sendo que a deleção
de remédios já cadastrados é proibida.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 56/63
Projeto da fragmentação vertical
Como somente o escritório central acessa e utiliza o preço de compra, a
tabela global REMEDIO pode sofrer fragmentação vertical desse atributo
nas tabelas da sucursal, permanecendo na íntegra no banco do
escritório central.
Fragmentação vertical da tabela REMEDIO.
 Quando um novo remédio for cadastrado, a sua
venda somente poderá começar a ser realizada no
dia seguinte ao cadastro, para permitir o
processamento de sua inclusão no portfólio da
empresa.
 As vendas para as farmácias são realizadas de
forma descentralizada, sendo seu controle e seu
registro realizados no âmbito de cada escritório
(central e sucursais).
 A direção da empresa, localizada no escritório
central, eventualmente gera relatórios com os
dados das vendas realizadas por cada um dos
escritórios (central e sucursais).
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 57/63
Projeto da fragmentação horizontal
Como as vendas são gerenciadas de forma centralizada, sem que um
escritório interfira na ação dos outros, as tabelas ITEMVENDA, VENDA e
FARMACIA deverão sofrer um particionamento horizontal, com cada
escritório mantendo somente os dados de sua área de atuação.
Fragmentação horizontal das tabelas FARMACIA, VENDA e ITEMVENDA.
Projeto da replicação
Veja as soluções adotadas com relação à replicação.
 Não replicar os dados das vendas das sucursais
para o banco do escritório central, pois, como a
diretoria consulta esses dados apenas de forma
eventual, os custos da replicação não compensam
e, quando necessário, os dados podem ser obtidos
com uma consulta distribuída, acessando
diretamente as tabelas do banco local das filiais.
 Como as sucursais somente realizam leituras na
tabela REMEDIO, em seu banco local, essa tabela
d t t l t d t b l REMEDIO
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 58/63
pode ser um extrato completo da tabela REMEDIO
do escritório central.
 Inicialmente, será realizada a exportação da tabela
REMEDIO do banco central para o banco das
sucursais.
 Após a exportação, somente serão propagadas de
forma incremental as atualizações realizadas na
tabela do banco central.
 Devido à regra de negócio já especificada, quando
da inclusão de novos remédios, estes somente
estarão disponíveis para venda pelos escritórios no
dia seguinte, sendo que a replicação deverá ocorrer
todo dia às 20 horas, após o término das atividades
operacionais no escritório central, ou seja,
utilizaremos um extrato periodicamente atualizado.
 Para a implementação da replicação, será criado
um gatilho na tabela REMEDIO do banco do
escritório central que irá gerar um log das
atualizações a serem propagadas.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 59/63
Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
No projeto de replicação do estudo de caso do atacadista de
remédios, foi adotada uma solução de replicação que envolve a
propagação da atualização da tabela REMEDIO todo dia às 20
horas.
Com relação a essa solução, podemos afirmar que:
I. Foi utilizada para a replicação um extrato associado a uma
data.
II. O extrato poderá ser atualizado nas sucursais.
III. A replicação de dados das sucursais para o escritório central
foi substituída pela consulta remota e distribuída aos bancos
locais das sucursais.
Está correto o que se afirma em
 A replicação propriamente dita será realizada por
um aplicativo em lote, a ser executado todo dia às
20 horas, propagando as atualizações para os
bancos das sucursais e limpando os registros do
log.
A somente em I.
B somente em II.
C somente em III.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 60/63
Parabéns! A alternativa C está correta.
A afirmativa I está errada porque o extrato gerado é denominado
periodicamente atualizado. A afirmativa II também está errada
porque extratos não podem ser atualizados, apenas as réplicas
aceitam essa operação. A afirmativa III está correta porque a
replicação de dados das sucursais para o escritório central foi
substituída pela consulta remota e distribuída aos bancos locais
das sucursais. Portanto, a opção C é a resposta correta.
Questão 2
Considere a fragmentação realizada no estudo de caso e analise as
afirmativas a seguir.
I. Foi realizada a fragmentação mista na tabela LABORATORIO
do esquema global.
II. A fragmentação realizada na tabela vendas foi horizontal.
III. Para as sucursais, foi realizada a fragmentação vertical da
tabela REMEDIO.
Está correto o que se afirma em
D em I e II.
E em I e III.
A somente em I.
B somente em II.
C somente em III.
D em I e II.
21/11/2023, 07:42 Projeto de banco de dados distribuídoshttps://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 61/63
Parabéns! A alternativa E está correta.
Considerando que no estudo de caso a fragmentação realizada na
tabela VENDAS foi horizontal e para as sucursais foi realizada a
fragmentação vertical da tabela REMEDIO, temos somente a
afirmativa I errada. A tabela LABORATORIO não foi fragmentada,
sendo mantida na íntegra no banco de dados local do escritório
central. Portanto, a opção E é a resposta correta.
Considerações �nais
Ao longo deste estudo, entendemos o processo de projeto de um banco
de dados distribuído, aprender a respeito das formas de distribuição de
dados e exemplificar um processo de projeto.
Abordamos as técnicas para projeto de banco de dados distribuídos,
com destaque para as abordagens top-down e bottom-up. Vimos a
importância das fragmentações horizontal, vertical e híbrida, bem como
os fundamentos de replicação por meio de extratos e réplicas.
Finalmente, desenvolvemos um estudo de caso incluindo um projeto de
banco de dados distribuído.
Podcast
Ouça sobre as características essenciais que diferenciam bancos de
dados centralizados dos bancos de dados distribuídos. Confira ainda as
principais técnicas de fragmentação de dados e os principais métodos
de replicação de dados.
E em II e III.

21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 62/63
Explore +
Pesquise a respeito de programas de suporte à replicação de dados,
como o GoldenGate e o PGpoolII.
Referências
CASANOVA, M. A. Princípios de sistemas de gerência de bancos de
dados distribuídos. Edição revisada, 1999.
ELSMARI, R.; NAVATHE, S. Sistemas de banco de dados. São Paulo:
Pearson, 2011
HEUSER, C. A. Projeto de banco de dados. [s.l.]: Sagra Luzzatto, 2001.
MELO, R. N.; SILVA, S. D.; TANAKA, A. K. Banco de dados em aplicações
cliente-servidor. [s.l.]: Infobook, 1998.
SIBERSCHATZ, A.; KORTH, H.; SUDARSHAN, S. Sistemas de banco de
dados. Rio de Janeiro: Elsevier, 2006.
21/11/2023, 07:42 Projeto de banco de dados distribuídos
https://stecine.azureedge.net/repositorio/00212ti/07591/index.html# 63/63
Material para download
Clique no botão abaixo para fazer o download do
conteúdo completo em formato PDF.
Download material
O que você achou do conteúdo?
Relatar problema
javascript:CriaPDF()