Banco de Dados

Distribuídos
 Material Teórico
Processamento de Consultas e Replicação de Dados

Responsável pelo Conteúdo:

Prof. Me. Marcel Thomé Filho

Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
 Processamento de Consultas
e Replicação de Dados

• Introdução;
• Comandos Remotos e Distribuídos;
• Protocolos de Segurança;
• Níveis de Persistência;
• Mecanismos de Atualização;
• Fragmentação de Dados.

OBJETIVO DE APRENDIZADO
• Compreender a importância dos estudos dos conceitos sobre a distribuição de dados;
• Entender o que é uma transação em uma base de dados;
• Entender o que é ACID;
• Entender a importância da replicação e fragmentação em um ambiente distribuído
de dados.
 Orientações de estudo
Para que o conteúdo desta Disciplina seja bem
aproveitado e haja maior aplicabilidade na sua
formação acadêmica e atuação profissional, siga
algumas recomendações básicas:
Conserve seu
material e local de
estudos sempre
organizados.
Aproveite as
Procure manter indicações
contato com seus de Material
colegas e tutores Complementar.
para trocar ideias!
Determine um Isso amplia a
horário fixo aprendizagem.
para estudar.

Mantenha o foco!
Evite se distrair com
as redes sociais.

Seja original!
Nunca plagie
trabalhos.

Não se esqueça
de se alimentar
Assim: e de se manter
Organize seus estudos de maneira que passem a fazer parte hidratado.
da sua rotina. Por exemplo, você poderá determinar um dia e
horário fixos como seu “momento do estudo”;

Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma

alimentação saudável pode proporcionar melhor aproveitamento do estudo;

No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos e
sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você tam-
bém encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão
sua interpretação e auxiliarão no pleno entendimento dos temas abordados;

Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e
de aprendizagem.
UNIDADE Processamento de Consultas e Replicação de Dados

Introdução
Olá, vamos mais uma vez estudar sobre banco de dados distribuído, desta vez o
assunto diz respeito a gerenciar as transações que ocorrem em uma base de dados e
principalmente se ela for distribuída, que é o caso. Então vamos continuar.

Atualmente, o ambiente de recuperação e armazenamento de dados tem uma

grande competitividade em que as organizações têm que atuar, estas são forçadas
a distribuir-se geograficamente, procurando as condições locais mais favoráveis à
produção ou exploração do seu negócio.

É por isso que as organizações possuem instalações dispersas por vários pon-
tos geográficos, dispondo cada um destes de bases de dados e meios de proces-
samento próprios.

Contudo, apesar da relativa autonomia dessas bases de dados locais, é normal

haver a necessidade de manter uma perspectiva integrada dos dados da organização.

Este motivo demonstra que os dados, apesar de fisicamente distribuídos, deve-

rão estar logicamente integrados.

Um sistema de bases de dados distribuídas consiste em múltiplos servidores, onde

cada um tem a responsabilidade de administrar seus dados. Esses dados podem ser
acessados utilizando uma rede de computadores e, apesar de estarem fisicamente
distribuídos, devem apresentar-se ao solicitante logicamente integrados, como se
estivessem num único servidor.

A principal razão para utilizar bases de dados distribuídas é o fato do problema

em análise ter uma natureza distribuída. Por exemplo, no caso de uma organização
que tenha a sua sede em São Paulo e uma fábrica A em Campinas, um armazém
B em Mairiporã e uma fábrica C em Jundiai, pode fazer sentido utilizar uma base
de dados distribuída, pois espelha a estrutura da organização.
Explor

Será que hoje tudo deve ser distribuído?

Às vezes, pode não fazer sentido ter um servidor em vários locais. Por exemplo,
se uma empresa tem sede em São Paulo e 3 lojas no litoral paulista, não faz sentido
ter um servidor em cada local. Nesta situação, talvez seja mais adequada uma so-
lução cliente/servidor. Portanto, se o problema não tiver uma natureza distribuída,
não devemos utilizar uma base de dados distribuída.

Cada Servidor que participa na base de dados distribuída tem uma autonomia
local, ou seja, é administrado (contas, segurança, ...) separado e independentemente
dos outros servidores. Esta autonomia local tem várias vantagens:
• Os nós dos sistemas podem espelhar mais facilmente a estrutura lógica das
organizações onde se inserem;

8
 • Os dados armazenados localmente são controlados por um administrador lo-
cal, pelo que o domínio de administração é menor e mais manejável;
• A recuperação de falhas pode ser efetuada numa base estritamente local;
• Os nós do sistema podem ter a dimensão mais adequada a cada problema local
e crescer independentemente.

Aplicação
do Utilizador
Begin_transaction,
Resultados
Read, Write, EOT, Modelo de Execução da
e notificações
Abort Transação Distribuída
Gestor de Gestor de
Transações Transações
Protocolo de
Read, Write, Controle de Réplicas
EOT, Abort
Gestor de Gestor de Protocolo de Controle de
Escalonamento Escalonamento Concorrência Distribuída

Gestor de Gestor de Protocolo de

Recursos Recursos Recuperação Local

Figura 1 – Execução de uma transação distribuída

Com uma estrutura preparada e adequado, podemos começar a pensar nas ações
que acontecem entre a base de dados e as diversas interfaces existentes no sistema.
A estas ações podemos tecnicamente chamar de transação.

Transação é uma unidade lógica de processamento de operações sobre um banco

de dados. Uma transação é formada por uma sequência de operações que precisam
ser executadas integralmente para garantir a consistência e a precisão.

Segundo M.Tamer Özsu e Patrick Valduriez, uma transação é uma coleção de

ações que fazem transformações consistentes aos estados do sistema, ao mesmo
tempo que preservam a sua consistência.

Nas bases distribuídas, as transações têm sua complexidade aumentada, já que

uma transação pode envolver a cooperação de vários nós. Quando isso acontece,
a transação é chamada “global” e é dividida em subtransações, tantas quantas os
nós envolvidos.

Geralmente, uma transação consiste de uma das seguintes instruções:

• uma ou mais instruções DML (Data Manipulation Language);
• uma instrução DDL (Data Definition Language);
• uma instrução DCL (Data Control Language).

9
9
UNIDADE Processamento de Consultas e Replicação de Dados

Uma transação começa quando for executada a 1ª instrução SQL executável e

termina com um dos seguintes eventos:
• comando COMMIT ou ROLLBACK é emitido;
• instrução DDL ou DCL é executada (commit automático);
• o usuário desconecta do banco de dados (commit automático);
• o sistema falha (rollback automático).
Quando uma transação termina, o próximo comando SQL inicia automatica-
mente na próxima transação.
As instruções de controle de transações são:
• COMMIT: finaliza a transação atual tornando permanentes todas as alterações
de dados pendentes.
• SAVEPOINT: marca um ponto de gravação dentro da transação atual, sendo
utilizado para dividir uma transação em partes menores.
• ROLLBACK [TO SAVEPOINT]: ROLLBACK finaliza
a transação atual, descartando todas as alterações de da- Lembre da
dos pendentes. ROLLBACK TO SAVEPOINT descarta o linguagem SQL!
ponto de gravação determinado e as alterações seguintes
ao mesmo.
Exemplo:

INSERT INTO Depto (Num_Depto, NmDepto, Cd_Gerente) VALUES (100, ‘TI’, 3);

UPDATE Funcionario SET salario = salario * 1.15 WHERE Num_Depto = 10;

COMMIT;

DELETE FROM Funcionario;

ROLLBACK;

No exemplo, o departamento 100 é inserido, os salários dos funcionários do

departamento 10 são atualizados, mas nenhum funcionário é excluído. Exemplo:

INSERT INTO Depto (Num_Depto, NmDepto, Cd_Gerente) VALUES (110, ‘RH’, 20);

SAVEPOINT ponto1;

DELETE FROM Funcionario;

ROLLBACK TO SAVEPOINT ponto1;

UPDATE Funcionario SET salario = salario * 1.15 WHERE Cd_Depto = 10;

COMMIT;

No exemplo, o departamento 110 é inserido, os salários dos funcionários do

departamento 10 são atualizados, mas nenhum funcionário é excluído.

10
 Na atividade onde diversas transações são processadas ao mesmo tempo (tran-
sações concorrentes), ocorre um entrelaçamento de operações entre elas.

Algumas operações de uma transação são executadas; em seguida, seu processo

é suspenso e algumas operações de outra transação são executadas.

Depois, um processo suspenso é retomado a partir do ponto de interrupção, exe-

cutado e interrompido novamente para a execução de uma outra transação.

Verificamos que o uso das técnicas que

envolvem a base de dados pode ser comum
aos tipos de estrutura, mas quando usa-
mos um ambiente distribuído, precisamos
pensar e criar métodos que satisfaçam às
necessidades do negócio, da organização
para obter os resultados necessários. As-
sim, podemos continuar aprendendo so-
bre as ações, processos ou, ainda, as tran-
sações neste ambiente, vamos continuar! Figura 2
Fonte: iStock/Getty Images

Comandos Remotos e Distribuídos

• Interrogação remota com um processo de transação:
» Seleciona (Select) informação de uma ou mais tabelas, todas residentes no
mesmo nó remoto.
• Atualização remota como processo de transação:
» Modifica dados numa ou mais tabelas, todas residentes no mesmo nó remoto.
• Interrogação distribuída em um processo de transação:
» Seleciona informação de dois ou mais nós da base distribuída.
• Atualização distribuída, processo de transação:
» Modifica dados em dois ou mais nós da base distribuída.

Transações Remotas e Distribuídas

Transação remota
• Contém um ou mais comandos remotos, todos referenciando o mesmo nó.

Transação distribuída
• Inclui comandos que acedem a dados em dois ou mais nós distintos.

11
11
UNIDADE Processamento de Consultas e Replicação de Dados

Transações Distribuídas
Uma transação distribuída termina com commit em todos os servidores que
participam dela, ou então termina com rollback em todos os servidores.

Ao ser finalizada, o mecanismo/protocolo que deve ser executado é mais uti-

lizado por profissionais e conhecido por garantir a execução destas transações, o
two-phase-commit.

O mecanismo tem como característica garantir a transparência numa base de

dados distribuída, como:
• na localização física de objetos;
• nas interrogações e atualizações distribuídas;
• nas transações distribuídas;
• na replicação de objetos.

Importante! Importante!

Transações e seus tipos, quais podemos usar e quando?

As propriedades de uma transação (propriedades ACID) devem ser garantidas

ao processar transações concorrentes, são elas:
• Atomicidade: uma transação é uma unidade atômica de processamento; é
realizada integralmente ou não é realizada.
• Consistência: uma transação é consistente se levar o banco de dados de um
estado consistente para outro estado também consistente.
• Isolamento: a execução de uma transação não deve sofrer interferência de
quaisquer outras transações que estejam sendo executadas concorrentemente.
• Durabilidade (ou persistência): as alterações aplicadas ao banco de dados,
por meio de uma transação confirmada, devem persistir no banco de dados,
não sendo perdidas por nenhuma falha.

Perceba como temos que aprender muitas características em um ambiente dis-

tribuído e escolher como tudo isso irá acontecer, vamos seguir.

ACID, Transação, conceitos de distribuição de dados.

O modelo simplificado para processamento de transações concorrentes envolve

as seguintes operações:
• read_item(X): lê um item X do banco de dados e transfere para uma variável
X de memória;

12
 • write_item(X): escreve o valor de uma variável X de memória em um item X
do banco de dados.

Exemplo:

T1 T2

read_item(X); read_item(X);

X := X - N; X := X + M;

write_item(X); write_item(X);

read_item(Y);

Y := Y + N;

write_item(Y);

Técnicas de controle de concorrência são utilizadas para garantir que transações

concorrentes sejam executadas adequadamente.

Muitos problemas podem ocorrer quando transações concorrentes são executa-

das sem controle:
• problema da perda de atualização;
• problema da atualização temporária (leitura suja);
• problema da agregação incorreta;
• problema da leitura não-repetitiva.

Apesar destas contingências, as transações devem manter as suas proprie-

dades fundamentais:
• Atomicidade – todas as subtransações são realizadas (COMMIT) e logo, tam-
bém, é feito o COMMIT da transação global, ou todas são abortadas (ABORT);
• Consistência – cada transação a executar sozinha numa base de dados con-
sistente mantém-na consistente. Ou seja, não devem ser violadas as restrições
de integridade da BD;
• Isolamento – para que esta característica seja uma realidade, é necessário:
» Seriabilidade, uma transação incompleta não deve mostrar os seus resultados às
outras transações antes de ser feito o seu COMMIT (evitando aborts em cascata).

Figura 3
Fonte: iStock/Getty Images

13
13
UNIDADE Processamento de Consultas e Replicação de Dados

Ao existir isolamento, evitam-se vários problemas:

• Leitura suja (dirty read) – a transação T1 modifica o item de dados X, que
é, em seguida, lido por T2 antes de T1 terminar;

T1 aborta; T2 leu um valor que nunca existiu na BD;

• Leitura não repetível ou confusa (fuzzy read) – T1 lê X; t2 modifica ou
apaga X e faz COMMIT; T1 tenta ler X outra vez, mas lê um valor diferente
ou não o consegue encontrar;
• Fantasmas (phantom) – T1 procura na BD tuplos de acordo com um predi-
cado, enquanto T2 insere novos tuplos que satisfazem esse predicado.

Persistência – a partir do momento em que é feito o COMMIT, o sistema deve

garantir que os resultados não desapareçam, mesmo que existem falhas subsequentes.

Protocolos de Segurança
Para que as características fundamentais das transações (mais conhecidas por
ACID: Atomicity, Consistency, Isolation, Durability) pudessem ser uma realida-
de nas base de dados distribuída, foi necessário criar protocolos de segurança:
• Protocolos de COMMIT;
• Protocolos de ABORT ou terminação;
• Protocolos de recuperação.

Cada nó tem um gestor de transações local, responsável por manter o log (para
recuperação caso seja necessário) e por participar na coordenação da execução
concorrente de transações a executar no próprio nó.

Também tem um coordenador de transações, responsável por iniciar a execução

de transações que começam nesse nó, por distribuir as subtransações pelos nós
apropriados e por coordenar a terminação de todas as transações que começam no
próprio nó (fazer o COMMIT ou o ABORT em todos os nós).

Protocolos de COMMIT
Asseguram que a propriedade da atomicidade da transação é respeitada. O pro-
tocolo mais conhecido e mais simples é o Two-Phase Commit (COMMIT em duas
fases) ou 2PC.

O nó coordenador (controla o protocolo) envia uma mensagem “Pronto para

COMMIT?” a cada um dos nós participantes envolvidos na transação em causa.

Estes respondem com uma mensagem de “Pronto”, indicando que está prepara-
do para fazer o COMMIT da sua parte da transação, ou então com uma mensagem
de “Abort”, indicando que não é possível fazer o COMMIT.

14
 Todos os participantes têm de responder com “Pronto” para que o COMMIT da
transação possa ocorrer. Senão, é enviado um “Global Abort” a todos os partici-
pantes para que abortem as suas subtransações. Ou seja, basta um “Abort” de um
dos nós para que toda a transação falhe.

Existem três implementações do 2PC:

• Centralizada – todas as comunicações envolvem o nó coordenador;
• Linear – os nós se comunicam numa sequência ordenada, a partir do
coordenador;
• Distribuída – todos os nós se comunicam uns com os outros diretamente.

O 2PC pode bloquear devido à falha de um dos nós durante o processo. Uma
transação bloqueada não é desejável porque continua a manter os locks dos recur-
sos de que necessita para a sua tran-
sação – impedindo que outras tran-
sações que precisem desses mesmos
recursos possam obtê-los.

Para ultrapassar esta limitação

do 2PC, foi criado o Three-Phase
Commit (3PC).

Este é semelhante ao 2PC, mas com

um passo adicional intermédio (Pre-
-Commit), que confirma que todos os
nós estão em condições de finalizar. Na
prática, porém, como este protocolo
aumenta ainda mais o tráfego de men-
sagens, não teve aceitação comercial. Figura 4
Fonte: iStock/Getty Images

Protocolos de ABORT ou Terminação

Se uma falha ocorrer, estes protocolos indicam aos restantes nós como lidar
com o fato. Tipicamente, os outros nós não devem ter de esperar até que a falha
seja reparada para terminar a transação.

No caso do 2PC, se um nó participante falha, por exemplo:

• se o coordenador se encontra no estado WAIT, é necessário abortar a transação;
• se o coordenador se encontra no estado COMMIT ou ABORT, deve reenviar
a mensagem de COMMIT/ABORT global ao nó em falha.

Protocolos de Recuperação
Depois de os nós que falharam voltarem a ficar operacionais, estes protocolos
indicam-lhes as medidas que devem tomar para se sincronizarem com os restantes
nós. Voltando ao caso do 2PC:

15
15
UNIDADE Processamento de Consultas e Replicação de Dados

• Se o coordenador falhar no estado WAIT, quando em recuperação, pode sim-

plesmente recomeçar o processo de COMMIT;
• Se o participante falhar no estado READY, quando em recuperação, pode per-
guntar ao coordenador o que fazer quanto à sub transação interrompida.

O termo persistência é raramente utilizado no contexto de banco de dados. Pre-

ferencialmente, o termo usado é banco de dados, que conota o espaço de objeto
resiliente, concorrentemente compartilhado. A função de um sistema de gerencia-
mento de banco de dados é permitir o acesso e a atualização simultâneos de bancos
de dados persistentes. A fim de garantir a persistência dos dados a longo prazo, os
sistemas de gerenciamento de banco de dados utilizam várias estratégias de recupe-
ração em caso de falhas na transação, no sistema ou no meio.

Há uma relação fundamental entre o compartilhamento e a persistência simultâ-

neos em banco de dados. As atualizações de transações devem persistir, mas, como o
banco de dados persistentes é ao mesmo tempo acessado e atualizado, o sistema de
gerenciamento de banco de dados deve preocupar-se com a coerência dos objetos de
dados persistentes. Isso normalmente é obtido por meio de estratégias de controle e
recuperação concorrentes.

Trocando ideias...Importante!
Compartilhar é a mesma coisa que fragmentar.

Níveis de Persistência
O processamento em uma base de dados consiste na manipulação de seus dados e
de acordo com a característica de sua estrutura podem ser transientes ou persistentes.

Os dados transientes só são validos dentro de um programa ou transação, eles

se perdem quando o programa ou a transação termina, ou seja, ao final do proces-
so não serão mais uteis ao sistema ou a base de dados.

Os dados persistentes, por outro lado, são armazenados fora do contexto de um

programa e assim sobrevivem a várias invocações de programas.

Estes normalmente residem nos bancos de dados compartilhados, podem ser

acessados e atualizados através de transações. Por exemplo, banco de dados pes-
soais, banco de dados de inventário e banco de dados de vendedores, contas ou
itens, todos contém dados persistentes pois estes estão guardados.

No entanto, há vários níveis de persistência. Os objetos menos persistentes são

aqueles criados e destruídos em procedimentos que executam algo para o sistema
como uma validação de código.

16
 Existem objetos que persistem dentro do espaço de trabalho de uma transação,
mas que são invalidados quando a transação termina. As transações são normal-
mente executadas dentro de uma sessão. O usuário estabelece seu login e define
diferentes parâmetros ambientais dentro da sessão em que está conectado ou
logado, como caminhos, opções de exibição, janelas etc.

Se o sistema suportar o multiprocessamento, várias transações poderão estar ati-

vas dentro da mesma sessão de usuário ao mesmo tempo. Todas estas transações
compartilharão os objetos da sessão.

No entanto, quando o usuário terminar a sessão, os objetos da sessão serão inva-

lidados ou não estarão mais disponíveis. O único tipo de objeto que persiste através
das transações são objetos permanentes, normalmente compartilhados por vários
usuários. Esses objetos persistem através de transações, instabilidade de sistema.
Tecnicamente esses são os objetos recuperáveis do banco de dados.

A replicação é a técnica de duplicar dados em vários nós diferentes. As razões

que podem tornar desejável esta duplicação são, basicamente, as seguintes:
• Prevenção contra falhas: a falha de um nó que contenha dados vitais ao sis-
tema não compromete, necessariamente, o seu funcionamento.
• Redução da transferência de dados: há uma maior probabilidade de os dados
estarem disponíveis localmente ou mais perto do nó que os requisita. Desta ma-
neira, são reduzidos os custos da sua transferência, quer em termos de explora-
ção dos meios de comunicação, quer em termos de tempo consumido.
• Paralelismo: os inquéritos à base de dados podem ser processados por vários
nós em paralelo (maior desempenho).

Porém, também existem desvantagens que se prendem com o fato de ser neces-
sário manter a coerência global do sistema. De fato, quando a informação num nó
é atualizada, as suas réplicas também o devem ser, o que aumenta o overhead do
sistema (custos de atualização e necessidade de algoritmos complexos para a execu-
ção de transações).

Existe vantagem nisso?

Sim, a replicação é mais vantajosa em sistemas onde sem tem uma necessidade
de muitas leituras a dados, mas poucas atualizações. Um detalhe que se deve pensar
é sobre a implementação com a localização física das réplicas.

Um conjunto de réplicas é identificado por um nome lógico e cada réplica indivi-

dual por um nome físico. Por exemplo: ficheiro fiche1.DB existe na base de dados,
no nó X. Quando esse ficheiro é replicado no nó Y, passam a existir dois ficheiros
com os seguintes caminhos físicos: X/fiche1.DB e Y/fiche1.DB.

A aplicação cliente apenas tem de saber o nome lógico para ter condições de aces-
sar o ficheiro, sendo da responsabilidade do SGBD manter um catálogo de réplicas que
forneça o mapeamento dos nomes físicos e respectivas localizações.

17
17
UNIDADE Processamento de Consultas e Replicação de Dados

Dependendo de quando as atualizações são propagadas, a replicação pode ser

síncrona ou assíncrona.

A replicação síncrona faz as atualizações

das réplicas do item de dados dentro de uma úni-
ca transação. Este tipo de replicação também é
chamado de eager replication (replicação esfo-
meada). Quando é feito o COMMIT desta tran-
sação, todas as réplicas estão no mesmo estado
e têm os mesmos valores. Assim, a transação
apenas pode ser finalizada com sucesso se as Figura 4
réplicas forem alteradas com sucesso. Fonte: iStock/Getty Images

O modelo assíncrono atualiza apenas uma das réplicas numa transação e pro-
paga as alterações para as outras réplicas depois, em outra transação. Este tipo de
replicação também é chamado lazy replication (replicação preguiçosa).

Quando é indispensável que exista consistência estrita (os dados têm de estar per-
manentemente atualizados), é necessário usar a replicação síncrona. Se não for esse
o caso, deve-se utilizar a replicação assíncrona por ter melhores tempos de resposta.

É possível até indicar intervalos de tempo para que as atualizações tenham lugar,
de hora em hora, por exemplo.

Mecanismos de Atualização
Existem vários tipos de mecanismos de atualização, sendo executadas onde as
atualizações são feitas, das permissões dos clientes e do timing das atualizações:
• primary copy (também chamada primary site replication);
• update everywhere (também chamada shared ownership ou, em português,
replicação simétrica);
• Epidémica – as operações são feitas numa única réplica (uma qualquer) e uma
transação diferente compara os dados das outras réplicas, atualizando-as;
• Subscrição – semelhante à anterior, mas considera-se que os nós apenas que-
rendo ter os dados, não se importando com a sua consistência.

Os nós que desejem manter a sua réplica atualizada devem subscrever-se perante
o nó responsável pelos dados. Um nó que não se tenha subscrevido, é responsável
por tentar obter os dados a partir de qualquer um dos outros nós, mas é possível que
esses dados não sejam os mais recentes.

Você percebeu como existem configurações e teorias sobre a distribuição de da-

dos em um ambiente de banco de dados? Vamos nessa, ainda temos mais algumas
coisas para aprender, ou deixar-nos maluco de vez!

18
 • ROWA (read one, write all) – como o nome indica, nas operações de escri-
ta, as réplicas são sincronizadas e atualizadas ao mesmo tempo.

Como todas as réplicas estão sincronizadas, é possível ler apenas uma delas,
obtendo uma leitura consistente. As duas primeiras técnicas são as mais difundidas,
apresentando-se em maior pormenor de seguida.

Na replicação por primary copy, um dos nodos detém a posse dos dados,
sendo o único que pode atualizá-los e propagar essas atualizações para os nodos
onde estão as suas réplicas – denominadas snapshots. Este método funciona da
seguinte maneira:
• Primeiro, é necessário escolher a réplica do item de dados que irá ser a primary
copy. O nó que contém a réplica é chamado primary site.

Diferentes itens de dados podem ter diferentes primary sites. O primary site
deve ser escolhido de modo que seja o que acesse mais vezes a estes dados, ou o
que acesse com mais dificuldade (devido, por exemplo, a uma ligação de rede com
uma baixa taxa de transferência de dados).

Quando uma transação necessita de fazer um lock ao item de dados Q, pede o

lock do primary site de Q. Implicitamente, é obtido o lock de todas as réplicas do
item de dados.

A vantagem deste método é a sua simplicidade, já que dados replicados são tra-
tados de um modo semelhante aos dados não replicados. Por outro lado, o primary
site pode tornar-se um gargalo para o desempenho de um grande sistema: são
enviados para este nó os pedidos de leitura provenientes de nós que não tenham
réplicas desses dados e todos os pedidos de escrita. Apesar de os pedidos de leitura
poderem ser realizados em paralelo por nós com réplicas, o processamento dos
pedidos de escrita são todos feitos por este nó.

Na replicação simétrica, qualquer réplica pode ser atualizada a qualquer

momento, até mesmo em simultâneo, propagando-se o efeito dessas atualiza-
ções, de forma sincronizada ou não, para as restantes réplicas. Este método
pode dar origem a conflitos entre atualizações, o que acontece quando duas
ou mais transações tentam atualizar os mesmos dados em duas ou mais répli-
cas distintas simultaneamente.

Uma das possibilidades para resolução destes conflitos incluem, por exemplo, o
recurso ao fator tempo, em que prevalece a atualização mais recente.

O uso da técnica de reconciliação para resolver o problema de a mesma réplica

ser atualizada por dois nós diferentes é uma solução onde existam dados contra-
ditórios. O item de dados tem o timestamp da última atualização; a réplica que
pretende atualizar este item de dados tem dois timestamps, um novo e um mais
antigo (correspondente à anterior atualização dos dados).

Se este último valor e o timestamp do item de dados forem iguais, então a atuali-
zação é segura: os dados são alterados e é colocado no item de dados o timestamp
que a réplica contém, senão, a réplica tem de ser reconciliada.

19
19
UNIDADE Processamento de Consultas e Replicação de Dados

Replicação e Tolerância a Falhas

Existem duas estratégias de replicação:
• Gossip (“Boato”) – as atualizações são propagadas assincronamente a todas
as réplicas, uma a uma, são enviadas simples mensagens a todos os nós onde
existam réplicas;
• Comunicação de Grupo – é feito um multicast/broadcast das atualizações a
todas as réplicas ao mesmo tempo.

Por vezes, não é possível atualizar todas as réplicas. Em ambientes realistas, temos
também de contar com a possibilidade de existirem falhas, quer dos nós, quer da rede
de comunicações. A melhor maneira de lidar com falhas nos nós pode ser ignorá-las.

No entanto, alguns métodos podem ser empregados para corrigir a falta de

atualizações de réplicas em nós que falharam ou que deixaram de estar disponíveis
devido a uma falha na rede.

Um deles é o protocolo de quorum, mais propriamente o protocolo consensual

de quórum, cada cópia tem um peso associado e um número de versão.

Fragmentação de Dados
A fragmentação é a utilização de uma técnica para dividir logicamente as relações.
As tabelas não são uma unidade lógica apropriada para estruturar uma base de da-
dos. Normalmente as aplicações e seus utilizadores não estão interessados em todos
os dados que estas contêm.

Existem dois tipos de fragmentação:

• Horizontal – é feita uma seleção à tabela, de acordo com alguma condi-
ção específica;
• Vertical – é feita uma projeção da tabela.

Também é possível combinar estes dois tipos, originando uma fragmentação mista.

Tabela 1 – Fragmentação Horizontal da Tabela de Empregados

CÓDIGO NOME LOCALIZAÇÃO CARGO OBRA
2 J. Barros 2 4 2
5 M. Pereira 2 1 1

20
 Tabela 2 – Fragmentação Vertical da Tabela de Empregados
CÓDIGO NOME CARGO
1 F. Rodrigues 4
2 J. Barros 4
3 A. Silva 3
4 J. Sousa 2
5 M. Pereira 1

Para um administrador de projeto que se encontra em Campinas saber quem

são os empregados da sua área, independentemente do seu cargo e do seu salário:
Tabela 3 – Fragmentação Misto da Tabela de Empregados
CÓDIGO NOME LOCALIZAÇÃO
3 A. Silva 3

A fragmentação horizontal, por sua vez, divide-se em duas:

• Fragmentação Horizontal Primária;
• Fragmentação Horizontal Derivada.
A fragmentação horizontal diz-se primária quando é definida por uma con-
dição aplicada diretamente à relação, como se pode ver no primeiro exemplo de
fragmentação apresentado.
A fragmentação horizontal é derivada quando definida por uma condição que
é aplicada as tuplas de relação diferente. Para exemplificar este caso, pode apre-
sentar-se a seleção dos códigos e nomes das obras onde trabalham os empregados
com código entre 1 e 3.
Tabela 4 – Fragmentação derivada da tabela OBRA
CÓDIGO NOME
1 Lote 2
2 Loja 34

Para que a fragmentação seja correta, deve ser:

• Completa – se existe um determinado dado na relação original, existe um
mapeamento que indica onde esse fragmento se encontra e se esse fragmento
existe garantidamente;
• Reconstruível – a relação original pode ser corretamente reconstruída a partir
dos seus fragmentos;
• Única – os dados de um fragmento não devem aparecer em mais nenhum,
exceto a chave primária na fragmentação vertical.
Esta técnica permite o processamento paralelo de uma relação (maior desem-
penho) e permite colocar os dados onde são acedidos mais insistentemente (dimi-
nuindo o peso das comunicações).

21
21
UNIDADE Processamento de Consultas e Replicação de Dados

Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:

  Sites
Introdução a persistência de dados com o hibernate
https://goo.gl/hVLGST
MYSQL – Replicação de dados
https://goo.gl/2aChGQ

 Livros
1941 – Introdução a sistemas de banco de dados
DATE, C.J. 1941 – Introdução a sistemas de banco de dados. Tradução de Daniel
Vieira. Rio de Janeiro: Elsevier, 2003.
Sistemas distribuídos princípios e paradigmas
TANENBAUM A. S.; STEEN, M. V. Sistemas distribuídos princípios e paradigmas.
3. ed. São Paulo: Pearson, 2009. (e-book)

22
Referências
BARBIERI, C. Bi2: Business Intelligence, modelagem & qualidade. Rio de Janeiro:
Elsevier, 2011.

DATE, C.J. 1941 – Introdução a sistemas de banco de dados. Tradução de

Daniel Vieira. Rio de Janeiro: Elsevier, 2003.

MACHADO, Felipe Nery Rodrigues. Banco de dados: projeto e implementação.

3. ed. São Paulo: Erica, 2014. (e-book)

ÖZSU, M.T. Valduriez, P. Principles of Distributed Database Systems. Prentice

Hall, 1991.

TANENBAUM A S.; STEEN, M. V. Sistemas distribuídos princípios e paradig-

mas. 3. ed. São Paulo: Pearson, 2009. (e-book)

23
23