Bancos de Dados Distribuídos

Prévia do material em texto

Éverton Alves de Oliveira 
 
 
 
 
 
 
 
 
 
Banco de Dados Distribuído no Desenvolvimento 
de Aplicações Comerciais 
 
 
 
 
 
 
 
 
 
 
 
 
 
Londrina 
2006
 
 I 
 
Éverton Alves de Oliveira
 
 
 
 
 
 
 
 
Banco de Dados Distribuído no Desenvolvimento 
de Aplicações Comerciais 
 
 
 
 
 
 
 
Monografia apresentada ao Curso de Pós-
Graduação em Engenharia de Software e 
Banco de Dados da Universidade Estadual de 
Londrina, como requisito parcial à obtenção 
do título de Especialista. 
 
Orientador: Prof. Ms. Daniel dos Santos Kaster 
 
 
 
 
 
 
 
Londrina 
2006 
 
 II 
Éverton Alves de Oliveira 
 
 
 
Banco de Dados Distribuído no Desenvolvimento 
de Aplicações Comerciais 
 
 
 
 
Monografia apresentada ao Curso de Pós-
Graduação em Engenharia de Software e Banco 
de Dados da Universidade Estadual de Londrina, 
como requisito parcial à obtenção do título de 
Especialista. 
 
 
 
 
 
 
COMISSÃO EXAMINADORA 
 
 
______________________________________________ 
Prof. Ms. Daniel dos Santos Kaster 
Universidade Estadual de Londrina 
 
______________________________________________ 
Prof. Ms. Rodolfo Miranda de Barros 
Universidade Federal do Rio de Janeiro 
 
______________________________________________ 
Prof. Ms. Fábio Cezar Martins 
Universidade Estadual de Londrina 
 
 
 
 
Londrina, ____ de____________ de 2007
 
 III 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DEDICATÓRIA 
 
Dedicado à minha família que me apoiou e a 
amigos que me incentivaram e contribuíram 
para tornar possível mais esta etapa de 
aprendizado em minha trajetória.
 
 IV 
OLIVEIRA, Éverton A.: Banco de Dados Distribuído no Desenvolvimento de 
Aplicações Comerciais. 2006. Monografia (Especialização em Engenharia de Software e 
Banco de Dados) - Universidade Estadual de Londrina. 
 
 
 
 
RESUMO 
 
 
A tecnologia de Banco de Dados Distribuído une as tecnologias de redes de comunicação e 
banco de dados, dando origem a um poderoso sistema distribuído que tem como principais 
finalidades proporcionar maior segurança e disponibilidade dos dados e tornar possível a 
integração de dados entre empresas geograficamente distantes e que utilizam diferentes 
estruturas de armazenamento de dados. No capítulo introdutório deste trabalho são 
apresentados de forma sintetizada os conceitos que constituem as bases para a compreensão 
desta tecnologia. Os capítulos subseqüentes irão aprofundar os conceitos de fragmentação e 
replicação de dados, apresentar estratégias de fragmentação e abordar os desafios da 
tecnologia no que se refere a transações e consultas distribuídas. Por fim, é apresentado um 
estudo de caso que demonstra a implementação de um sistema de banco de dados 
distribuído aplicando os conceitos estudados. 
 
 
 
 
 
 
 
 
 
Palavras-chave: Banco de dados, fragmentação, replicação, distribuição, site. 
 
 V 
OLIVEIRA, Éverton A.: Distributed Database in Development of Commercial 
Applications. 2006. Monografia (Especialização em Engenharia de Software e Banco de 
Dados) - Universidade Estadual de Londrina. 
 
 
 
 
ABSTRACT 
 
 
 
The technology of Distributed Database unites the technologies of communication 
networks and databases, creating a powerful distributed system which its main purpose is to 
provide more safety and readiness of the data and turn possible the integration of data 
among companies geographically distant which use different structures of data storage. In 
the introduction chapter of this article, the concepts are presented in a synthesized way that 
constitutes the bases for the understanding of this technology. The next chapters will 
deepen the fragmentation concepts and response of data, present fragmentation strategies 
and approach the challenges of the technology in what refers to transactions and distributed 
queries. Finally, it is presented a study case that demonstrates the implementation of a 
system of distributed database applying the studied concepts. 
 
 
 
 
 
 
 
 
 
Keywords: Database, fragmentation, replication, distribution, site.
 
 VI 
SUMÁRIO 
 
1. INTRODUÇÃO ............................................................................................................1 
1.1 OBJETIVOS...............................................................................................................2 
1.1.1 Objetivo geral .................................................................................................2 
1.1.2 Objetivos específicos ......................................................................................2 
1.2 JUSTIFICATIVA .........................................................................................................2 
1.3 PRESSUPOSTOS........................................................................................................2 
2. SISTEMAS DE BANCO DE DADOS DISTRIBUÍDOS ..........................................4 
2.1 PROMESSAS DE SBDDS...........................................................................................5 
2.1.1 Independência de dados .................................................................................7 
2.1.2 Transparência de rede....................................................................................8 
2.1.3 Transparência de replicação..........................................................................8 
2.1.4 Transparência de fragmentação.....................................................................8 
2.1.5 Quem deve proporcionar transparência? ......................................................9 
2.1.6 Confiabilidade em transações distribuídas ....................................................9 
2.2 FATORES DE COMPLICAÇÃO...................................................................................11 
2.2.1 Processamento distribuído de consultas ......................................................11 
2.2.2 Controle distribuído da concorrência ..........................................................11 
2.2.3 Gerenciamento distribuído de impasses.......................................................12 
2.2.4 Bancos de dados heterogêneos.....................................................................12 
3. PROJETO DE BANCO DE DADOS DISTRIBUÍDO............................................13 
3.1 RAZÕES PARA A FRAGMENTAÇÃO..........................................................................13 
3.2 GRAU DE FRAGMENTAÇÃO....................................................................................14 
3.3 ALTERNATIVAS DE FRAGMENTAÇÃO.....................................................................15 
3.3.1 Fragmentação horizontal .............................................................................15 
3.3.2 Fragmentação vertical .................................................................................16 
3.4 REGRAS DE FRAGMENTAÇÃO.................................................................................17 
3.5 ALOCAÇÃO............................................................................................................18 
4. PROCESSAMENTO DE CONSULTAS DISTRIBUÍDAS....................................20 
4.1 TRANSFORMAÇÃO DE CONSULTA...........................................................................22 
4.2 LOCALIZAÇÃO DE DADOS DISTRIBUÍDOS................................................................25 
5. TRANSAÇÕES DISTRIBUÍDAS.............................................................................27 
5.1 PROPRIEDADES DE TRANSAÇÕES............................................................................28 
5.2 CONTROLE DE TRANSAÇÕES DISTRIBUÍDAS...........................................................29 
5.3 CONTROLE DISTRIBUÍDO DA CONCORRÊNCIA.........................................................30 
5.3.1 Algoritmos baseados em bloqueios ..............................................................31 
5.3.2 Algoritmos baseados em timbre de hora......................................................32 
5.3.3 Gerenciamento de impasses .........................................................................33 
5.3.4 Algoritmos otimistas para controle de concorrência...................................35 
6. CONFIABILIDADE DE SGBDS DISTRIBUÍDOS................................................36 
 
 VII 
6.1 PROTOCOLOS DE EFETIVAÇÃO...............................................................................38 
6.1.1 Efetivação em duas fases..............................................................................38 
6.1.2 Efetivação em três fases ...............................................................................39 
7. ESTUDO DE CASO...................................................................................................42 
7.1 CONCEITOS BÁSICOS..............................................................................................43 
7.2 CONFIGURANDO SERVIDORES................................................................................44 
7.3 CRIANDO O BANCO DE DADOS................................................................................44 
7.4 CRIANDO PUBLICAÇÕES.........................................................................................45 
7.5 CONFIGURANDO ASSINATURAS..............................................................................46 
8. CONCLUSÃO.............................................................................................................48 
9. REFERÊNCIAS BIBLIOGRÁFICAS .....................................................................49 
 
 VIII 
LISTA DE ABREVIATURAS 
 
SBDD Sistema de Banco de Dados Distribuído 
SGBD Sistema Gerenciador de Bancos de Dados 
SQL Structured Query Language 
ACID Atomicidade, consistência, isolamento e durabilidade 
2PC two-phase commit 
3PC three-phase commit 
 
 
 IX 
LISTA DE FIGURAS 
 
Figura 1.1: Modelagem do banco de dados da Instituição financeira...................................17 
Figura 4.1: Modelo de fragmentação do banco dados..........................................................34 
Figura 4.2: Estratégia 1 de processamento de consulta.........................................................35 
Figura 4.3: Estratégia 2 de processamento de consulta.........................................................35 
Figura 7.1: Banco de dados fragmentado e replicado...........................................................52
 
 X 
LISTA DE TABELAS 
 
Tabela 3.1: Fragmentação horizontal da relação CLIENTE.................................................26 
Tabela 3.2: Fragmentação horizontal da relação CONTA....................................................27 
Tabela 3.3: Fragmentação vertical da relação CONTA........................................................28 
Tabela 3.4: Comparação entre alternativas de replicação.....................................................30 
Tabela 7.1: Dicionário de dados do banco de dados Instituição Financeira.........................56 
 
 1 
1. Introdução 
 
 
O maior objetivo de um sistema bancos de dados é manter a integridade dos dados e 
não centralizá-los. Os Sistemas de Bancos de Dados Distribuídos (SBDDs) são a união de 
duas tecnologias que podem ser consideradas de propósitos opostos dentro da computação: 
o sistema de bancos dados, que visa promover a integração dos dados operacionais de um 
empreendimento e proporcionar acesso centralizado, e as redes de comunicação, que 
promove um modo de trabalho que se opõem a todos os esforços de centralização. 
Um banco de dados distribuído constitui de um conjunto de bancos de dados 
logicamente inter-relacionados, distribuídos em diversos servidores através de uma rede de 
comunicação. Cada servidor armazena uma parte do banco de dados e é desejável que uma 
determinada partição dos dados esteja armazenada em mais de um local. Uma vez que cada 
servidor não opera sobre o banco de dados inteiro, mas apenas sobre parte dele, obtém-se 
maior performance na manutenção dos dados. Quando uma consulta ao banco de dados 
necessita de dados que estão presentes em diversos sites, é possível distribuir a consulta de 
modo que cada site processe uma parte dela, fazendo uso de processamento paralelo, o que 
também contribui para o ganho de performance. E ainda, o fato de uma partição de dados 
estar replicada em mais de um site, proporciona maior disponibilidade dos dados no 
sistema, pois ainda que ocorra uma falha em um dos sites, os dados armazenados por ele 
podem ser encontrados em outro local. 
A tecnologia de Banco de Dados Distribuídos não é popularmente utilizada por ser 
de difícil implementação. Todas as dificuldades enfrentadas em um sistema de banco de 
dados centralizado são potencializadas em um contexto distribuído, pois como se trata de 
um sistema distribuído através de uma rede, existem os problemas relacionados à 
comunicação e ao tráfego da rede. Outro agravante é o fato de existirem cópias de uma 
determinda porção de dados em diversos locais, o que proporciona maior dificuldade na 
manutenção da consistência entre todas as réplicas, pois uma única transação pode estar 
sendo executada em diversos sites e atualizando várias réplicas de um mesmo fragmento de 
dados. 
 
 2 
1.1 Objetivos 
1.1.1 Objetivo geral 
O objetivo deste trabalho é introduzir os conceitos básicos para a compreensão da 
tecnologia de bancos de dados distribuídos, bem como apresentar um caso de sua utilização 
e a aplicação dos conceitos apresentados. 
1.1.2 Objetivos específicos 
• Relacionar as propostas da tecnologia de banco de dados distribuído; 
• Definir os conceitos básicos de fragmentação e replicação de dados; 
• Apresentar os conceitos e a complexidade de transações e consultas no contexto 
distribuído; 
• Apresentar um estudo de caso de implementação da tecnologia de banco de 
dados distribuído utilizando o Microsoft® SQL Server™ 2000. 
 
1.2 Justificativa 
A tecnologia de bancos de dados distribuídos é uma solução utilizada tipicamente 
por grandes corporações, nas quais a total segurança e disponibilidade dos seus dados são 
fatores críticos. O conhecimento desta tecnologia pode oferecer ao profissional de 
computação a possibilidade de desenvolver sistemas comerciais voltados para empresas 
constituídas de diversas unidades filiais e/ou setores, distanciados geograficamente, e que 
visam integração de seus dados. 
 
1.3 Pressupostos 
Considera-se o prévio conhecimento das tecnologias de bancos de dados e redes de 
computadores no contexto de desenvolvimento de sistemas computacionais. 
 
 3 
Esta monografia está organizada da seguinte forma: o capítulo 2 apresenta 
resumidamente os conceitos básicos, as propostas e os desafios a serem enfrentado pela 
tecnologia de Banco de Dados Distribuídos. O capítulo 3 aprofunda os conceitos de 
fragmentação e replicação de dados bem como as técnicas existentes. O capítulo 4 trata do 
processamento distribuído de consultas, seguido do capítulo 5 que aborda as características 
e dificuldades das transações distribuídas. O capítulo 6 descreve os protocolos de 
efetivação de transações distribuídas e por fim, o capítulo 7 demonstra utilizando o SGDB 
Microsoft® SQL Server™ 2000 um estudo de caso de utilização desta tecnologia, 
empregando os conceitos apresentados. 
 
 4 
2. Sistemas de Banco de Dados Distribuídos 
 
O termo processamento distribuído talvez seja o termo mais excessivamente 
utilizado em informática nos últimos anos para se referir a sistemas tão diversos quanto 
sistemas de multiprocessadores, processamento de dados distribuídos e redes de 
computadores. Será considerada uma definição de processamento distribuído de um modo 
que leva a compreensão do que é um sistema de banco de dados distribuído. A definição 
funcional usada para um sistema de computação distribuída estabelece que ele consiste em 
diversos elementos autônomos de processamentoque estão interconectados por uma rede 
de computadores que cooperam entre si na execução de suas tarefas [Özsu, M.; Valduriez, 
2001]. 
Mas o que pode ser distribuído em um sistema de computação distribuída? Um dos 
itens que pode ser distribuído é a lógica de processamento. De fato, a definição de um 
sistema de computação distribuída dada anteriormente pressupõe implicitamente que a 
lógica de processamento ou os elementos de processamento são distribuídos. Outra 
distribuição possível é feita de acordo com a função. Várias funções de um sistema de 
computador poderiam ser delegadas a diversas peças de hardware ou software. Um terceiro 
modo de distribuição possível é de acordo com os dados. Os dados usados por vários 
aplicativos podem ser distribuídos em diversos locais (sites) de processamento. Por fim, o 
controle pode ser distribuído. O controle da execução de várias tarefas poderia ser 
distribuído, em lugar de ser executado por um único sistema de computador. Do ponto de 
vista de banco de dados distribuídos, esses modos de distribuição são todos necessários e 
importantes [Özsu, M.; Valduriez, 2001]. 
Outra pergunta importante a ser feita é: por que distribuir? Todavia, pode-se afirmar 
que a motivação fundamental por trás do processamento distribuído é ser capaz de dividir 
os problemas computacionais em fragmentos menores atribuindo-os a grupos de software 
distintos, que funcionem em computadores diferentes e produzam um sistema que atue 
sobre vários elementos de processamento, mas que possam colaborar de forma eficaz para a 
execução de uma tarefa comum. 
 
 5 
Essa abordagem apresenta duas vantagens fundamentais sob um ponto de vista de 
economia. Primeiro, a computação distribuída proporciona um método econômico para se 
conseguir maior poder de computação, empregando-se vários elementos de processamento 
de maneira ótima. A segunda razão econômica é que a dissolução dos problemas em grupos 
menores atuando de forma mais ou menos autônoma talvez torne possível disciplinar o 
custo de desenvolvimento de software [Özsu, M.; Valduriez, 2001]. 
Os sistemas de banco de dados distribuídos também devem ser vistos dentro dessa 
estrutura e tratados como ferramentas que podem tornar o processamento distribuído mais 
fácil e eficiente e sem dúvida ajudar na tarefa de desenvolver software distribuído. 
Pode-se definir um banco de dados distribuído como uma coleção de vários bancos 
de dados logicamente inter-relacionados, distribuídos por uma rede de computadores, e é 
gerenciado por um sistema de software chamado sistema gerenciador de bancos de dados 
distribuídos (SGBDD) que tem o objetivo de tornar a distribuição transparente para o 
usuário. O conceito de transparência neste contexto se refere à separação entre a semântica 
de nível mais alto de um sistema e questões de implementação de nível mais baixo. Em 
outras palavras, um sistema transparente deve ser capaz de ocultar do usuário os detalhes de 
implementação [Özsu, M.; Valduriez, 2001]. 
 
2.1 Promessas de SBDDs 
Para iniciar a compreensão dos conceitos que envolvem a tecnologia de sistemas de 
bancos de dados distribuídos e suas propostas, será utilizado um pequeno exemplo. Uma 
instituição financeira possui agências nas cidades A, B e C, ela necessita manter um banco 
de dados de seus clientes, suas contas correntes e das movimentações financeiras realizadas 
diariamente. Para isso, utiliza um banco de dados formado pelas relações CLIENTE, 
CONTA e MOVIMENTO, inter-relacionadas conforme a figura abaixo: 
 
 6 
 
Figura 1.1: Modelagem do banco de dados da Instituição Financeira 
 
Se todos estes dados estivessem armazenados em um SGBD centralizado e fosse 
necessário realizar uma consulta que mostrasse o nome e saldo da conta corrente de todos 
os clientes cujas contas correntes sofreram movimentações no dia 06/01/2006, estes dados 
poderiam ser obtidos através da seguinte consulta SQL: 
 
 SELECT DISTINCT CLIENTE.NOME, CONTA.SALDO 
 FROM CLIENTE, CONTA, MOVIMENTO 
 WHERE MOVIMENTO.DATA = '06/01/2006' 
 AND MOVIMENTO.AGENCIA = CONTA.AGENCIA 
 AND MOVIMENTO.CONTA = CONTA.NUMERO_CONTA 
 AND CLIENTE.CODIGO_CLIENTE = CONTA.CODIGO_CLIE NTE 
 
Porém, data a natureza distribuída dos negócios da instituição financeira, é 
preferível, sob essas circunstâncias, que os dados referentes às contas correntes da agência 
localizada na cidade A estejam armazenadas na cidade A, os dados referentes às contas 
correntes da agência localizada na cidade B estejam armazenadas na cidade B e assim por 
diante. Desse modo, cada uma das relações deve ser particionada e cada uma das partições 
armazenadas em um local diferente. Isso é conhecido como fragmentação. Além disso, 
talvez seja preferível duplicar alguns desses dados em outros locais por razões de 
desempenho e confiabilidade, utilizando assim o recurso conhecido como replicação. O 
resultado é um banco de dados distribuído que é fragmentado e replicado. O acesso 
totalmente transparente significa que os usuários ainda podem formular a consulta da 
 
 7 
maneira especificada anteriormente, sem qualquer preocupação com a fragmentação, a 
localização ou a replicação dos dados, e deixar a cargo do sistema a resolução dessas 
questões [Silberschatz, A.; Korth, H.; Sudarshan, S., 1999]. 
Para um sistema lidar de maneira adequada com esse tipo de consulta sobre um 
banco de dados distribuído, fragmentado e replicado, ele precisa ser capaz de lidar com 
vários tipos diferentes de transparências. 
2.1.1 Independência de dados 
A independência de dados se refere à imunidade de aplicativos do usuário a 
mudanças na definição na organização de dados, e vice-versa. É uma forma fundamental de 
transparência que procuramos dentro de um SGDB, é também o único importante dentro do 
contexto do SGDB centralizado [Özsu, M.; Valduriez, 2001]. 
A definição de dados pode ocorrer em dois níveis. Em um nível a estrutura lógica 
dos dados é especificada, conhecida como definição do esquema, e no outro nível a 
estrutura física dos dados é definida, referido como a descrição dos dados físicos. Portanto, 
são considerados dois tipos de independência de dados: independência de dados lógica e 
independência de dados física. 
A independência de dados lógica se refere à imunidade de aplicativos do usuário a 
mudanças na estrutura lógica do banco de dados. Em geral, se um aplicativo do usuário 
opera sobre um subconjunto dos atributos de uma relação, ela não deve ser afetada mais 
tarde quando novos atributos forem acrescentados à mesma relação [Özsu, M.; Valduriez, 
2001]. 
A independência de dados física lida com a ocultação dos detalhes da estrutura de 
armazenamento em relação aos aplicativos do usuário. Quando um aplicativo do usuário é 
escrito, ele não deve se preocupar com os detalhes da organização física dos dados. Os 
dados poderiam estar organizados em tipos de discos diferentes, partes deles poderiam estar 
organizados de maneiras diferentes, ou poderiam até mesmo estar distribuídos em 
hierarquias de memória distintas. O aplicativo não deve se envolver com estas questões 
porque, conceitualmente, não há nenhuma diferença nas operações executadas sobre os 
dados [Özsu, M.; Valduriez, 2001]. 
 
 8 
2.1.2 Transparência de rede 
Em sistemas de bancos de dados centralizados, o único recurso disponível que 
precisa ser isolado do usuário é o dado. Contudo, em um ambiente de gerenciamento de 
banco de dados distribuído a rede é um segundo recurso que precisa ser administrado quase 
da mesma maneira. É desejável que o usuário esteja protegido contra os detalhes 
operacionais da rede e, se possível, ocultar até mesmo a existência de uma rede, ter meios 
uniformes pelos quais os serviços sejam acessados e exigir que o usuário não tenha que 
especificar onde os dados estão localizados. Esse tipo de transparência é referido como 
transparência de rede ou transparência de distribuição[Özsu, M.; Valduriez, 2001]. 
2.1.3 Transparência de replicação 
Em geral, por razões de desempenho, confiabilidade e disponibilidade, é desejável 
poder distribuir os dados de forma replicada pelas máquinas de uma rede. Tal replicação 
ajuda ao desempenho, pois, requisitos do usuário distintos e conflitantes podem ser 
acomodados com maior facilidade. Por exemplo, os dados comumente acessados por um 
usuário podem ser localizados mais próximos dele, assim como de outro usuário com os 
mesmos requisitos de acesso. Além disso, se uma máquina falhar, uma cópia dos dados 
ainda estará disponível na rede. É claro que esta é uma descrição muito simplificada da 
situação. Na verdade, a decisão de replicar ou não os dados e de quantas cópias existirão 
dependerá em um grau considerável dos aplicativos do usuário, pois a replicação causa 
problemas na atualização do banco de dados [Özsu, M.; Valduriez, 2001]. 
A questão relacionada com a transparência que precisa ser examinada neste ponto é 
se os usuários devem estar cientes da existência de cópias, ou se o sistema deve tratar o 
gerenciamento de cópias enquanto o usuário deve agir como se houvesse uma única cópia 
dos dados. Obviamente que é preferível não se envolver com a manipulação de cópias e 
com a obrigação de especificar se uma certa ação pode e/ou deve ser executada sobre várias 
cópias. 
2.1.4 Transparência de fragmentação 
É desejável dividir cada relação de um banco de dados em fragmentos menores, e 
tratar cada fragmento como um objeto de banco de dados separado (isto é, outra relação). 
 
 9 
Isso é feito normalmente por motivos de desempenho, disponibilidade e confiabilidade. 
Além disso, a fragmentação pode reduzir os efeitos negativos da replicação, pois cada 
réplica não é a relação completa, mas apenas um subconjunto dessa relação, desse modo, é 
exigido menos espaço, e menos itens de dados precisam ser administrados. 
Há dois tipos gerais de alternativas de fragmentação. Em um caso, chamado de 
fragmentação horizontal, uma relação é particionada em um conjunto de sub-relações, cada 
uma das quais tem um subconjunto das tuplas (linhas) da relação original. A segunda 
alternativa é a fragmentação vertical, na qual cada sub-relação é definida sobre um 
subconjunto dos atributos (colunas) da relação original [Özsu, M.; Valduriez, 2001]. 
A questão fundamental de se lidar com a transparência de fragmentação está 
relacionada com o processamento de consultas, pois existe o problema de manipular 
consultas do usuário que foram especificadas sobre relações inteiras, mas que agora têm de 
ser executadas em sub-relações. 
2.1.5 Quem deve proporcionar transparência? 
É muito importante perceber que níveis razoáveis de transparência dependem de 
vários componentes dentro do ambiente de gerenciamento de dados. A transparência de 
rede pode ser tratada facilmente pelo sistema operacional distribuído como parte de suas 
responsabilidades de oferecer transparência de replicação e de fragmentação. O SGBD deve 
ser responsável por oferecer um nível elevado de independência de dados, juntamente com 
a transparência de replicação e fragmentação. Por fim, a interface do usuário pode admitir 
um nível mais alto de transparência, não apenas em termos de um método de acesso 
uniforme aos recursos de dados dentro de uma linguagem, mas também em termos de 
construções de estrutura que permite ao usuário lidar com objetos em seu ambiente, em vez 
de se concentrar em detalhes de descrição do banco de dados [Özsu, M.; Valduriez, 2001]. 
2.1.6 Confiabilidade em transações distribuídas 
Os SGBDs distribuídos são planejados para melhorar a confiabilidade, pois têm 
componentes replicados e, portanto, eliminam pontos únicos de falha. A falha de um único 
site ou falha de um link de comunicação que torne um ou mais sites inacessíveis não são 
suficientes para deixar inativo o sistema inteiro. No caso de um banco de dados distribuído, 
 
 10 
isso significa que alguns dados podem estar inacessíveis, mas, com cuidado apropriado, é 
possível que os usuários tenham permissão para acessar outras partes do banco de dados 
distribuído [Silberschatz, A.; Korth, H.; Sudarshan, S., 1999]. 
Uma transação é uma unidade básica de computação consistente e confiável, 
formada por uma seqüência de operações de bancos de dados executadas como uma ação 
atômica [Özsu, M.; Valduriez, 2001]. Isso significa dizer que esta seqüência de várias 
operações é executada como se fosse uma única operação, e se parte desta operação não 
puder ser executada, nada será executado, permanecendo o banco de dados em seu último 
estado de consistência. Ela tem o objetivo de garantir que o banco de dados deixe um 
estado de consistência somente para entrar em outro estado de consistência, mesmo quando 
várias destas transações são executadas de forma concorrente, e até mesmo quando ocorrem 
falhas (atomicidade de falha). 
Examinando uma transação baseada no exemplo da instituição financeira discutida 
anteriormente, considera-se que um aplicativo aumente o limite de crédito em 5% em todas 
as contas que possuem saldo superior a dois mil reais. É desejável encapsular esta operação 
dentro dos limites de uma transação. Caso ocorra uma falha durante a execução deste 
programa, o SGBD deverá ser capaz de determinar, ao ocorrer a recuperação, onde o 
programa foi interrompido e de continuar com sua operação ou começar tudo de novo. Por 
outro lado, caso não ocorram falhas, e outro usuário executar uma consulta para calcular a 
média dos limites de crédito das contas correntes enquanto a ação original de atualização 
estiver em andamento, o resultado calculado estará incorreto. Neste caso o sistema deve ser 
capaz de sincronizar a execução concorrente desses dois programas. 
A transação anterior será executada nas cidades A, B e C. Com suporte total para 
transações distribuídas, os aplicativos dos usuários devem acessar uma única imagem 
lógica do banco de dados e confiar no SGBD distribuído para assegurar que suas 
solicitações serão executadas corretamente, independente do que acontecer no sistema. Isto 
significa que os aplicativos do usuário não precisarão se preocupar com a coordenação de 
seus acessos a banco de dados locais individuais, nem terão de se preocupar com a 
possibilidade de falhas de sites ou links de comunicação durante a execução de suas 
transações. 
 
 
 11 
2.2 Fatores de complicação 
Os problemas encontrados em sistemas de bancos de dados impõem uma 
complexidade adicional em um ambiente distribuído, pois, os dados podem ser replicados 
em um ambiente distribuído. Não é essencial que todo site na rede contenha uma cópia do 
banco de dados, só é essencial que existe mais de um local em que o banco de dados esteja 
presente. Conseqüentemente, o sistema de banco de dados distribuído é responsável por 
escolher uma das cópias dos dados solicitados para acesso em caso de recuperação, e 
assegurar que o efeito de uma atualização se refletirá em todas as cópias existentes desse 
item de dado [Özsu, M.; Valduriez, 2001]. 
Outro agravante encontrado em um ambiente distribuído é em caso de falhas em 
alguns sites ou links de comunicação enquanto uma atualização estiver em andamento. O 
sistema deverá assegurar que os efeitos se refletirão nos dados residentes nos sites 
defeituosos, tão logo o sistema possa se recuperar da falha. 
Como cada site não pode ter informações instantâneas sobre as ações que estão 
ocorrendo nos outros sites no momento, a sincronização de transações em vários sites é 
consideravelmente mais difícil que no caso de um sistema centralizado, caracterizando mais 
um ponto crítico em sistemas de bancos de dados distribuídos. 
2.2.1 Processamento distribuído de consultas 
Para um SBDD o problema do processamento de consultas está em como decidir 
sobre uma estratégia para a execução de cada consulta através da rede da maneira mais 
econômica, considerando a distribuiçãodos dados, os custos de comunicação e a falta de 
informações suficientes disponíveis no local. 
2.2.2 Controle distribuído da concorrência 
No controle da concorrência em um contexto distribuído é necessário não apenas se 
preocupar com a integridade de um único banco de dados, como ocorre em um sistema 
centralizado, mas também com a consistência de várias cópias do banco de dados. Para 
isso, duas classes gerais de controle de concorrência são consideradas, o controle pessimista 
e o controle otimista [Özsu, M.; Valduriez, 2001]. 
 
 12 
O primeiro, sincroniza a execução de solicitações do usuário antes de iniciar a 
execução, e o segundo, executa as solicitações e depois verifica se a execução 
comprometeu a consistência do banco de dados. Duas primitivas básicas que podem ser 
usadas com ambas as abordagens são o bloqueio, que se baseia na exclusão mútua de 
acesso a itens de dados, e o uso de timbre de hora, no qual as transações são executadas em 
alguma ordem. Existem variações desses esquemas, bem como algoritmos híbridos que 
tentam combinar os dois mecanismos básicos [Özsu, M.; Valduriez, 2001]. 
2.2.3 Gerenciamento distribuído de impasses 
O problema de impasses em SBDDs tem natureza muito semelhante ao encontrado 
em sistemas operacionais. A competição entre usuários pelo acesso a um conjunto de dados 
pode resultar em um impasse, se o mecanismo de sincronização se basear em bloqueios. 
2.2.4 Bancos de dados heterogêneos 
Normalmente, bancos de dados distribuídos heterogêneos surgem quando há a 
necessidade de integrar SGBDs já existentes autônomos e centralizados. A heterogeneidade 
pode ocorrer de várias formas nos sistemas distribuídos, variando desde a heterogeneidade 
de hardware e diferenças em protocolos de interligação de redes até variações em 
gerenciadores de dados, como linguagens de consulta e protocolos de gerenciamento de 
transações [Özsu, M.; Valduriez, 2001]. 
 
 13 
3. Projeto de banco de dados distribuído 
 
O projeto de sistema de computadores distribuídos inclui decisões sobre a 
disposição dos dados e programas pelos sites de uma rede de computadores, como também 
o possível projeto da própria rede. No caso de SGBDs distribuídos, a distribuição dos 
aplicativos inclui dois itens: a distribuição do software de SGBD distribuído e a 
distribuição dos programas aplicativos que funcionam nele. Neste caso, considera-se que 
existe uma cópia do software do SGBD distribuído em cada site e que a localização dos 
programas não é relevante. Além disso, considera-se que a rede já foi projetada ou que será 
projetada posteriormente, de acordo com as decisões relativas ao banco de dados 
distribuído. Portanto, o que deve ser considerado primordialmente em projeto de banco de 
dados distribuído é localização dos dados [Özsu, M.; Valduriez, 2001]. 
 
3.1 Razões para a fragmentação 
Sob um ponto de vista de distribuição de dados, não há nenhuma razão real para a 
fragmentar dados. Afinal, em sistemas de arquivos distribuídos a distribuição é realizada 
sobre arquivos inteiros. 
Com relação à fragmentação, a questão mais importante é a unidade apropriada de 
distribuição. Uma relação não é uma unidade adequada, por várias razões. Primeiro, em 
geral as visões de aplicativos são subconjuntos de relações. Portando, o caráter local de 
acessos de aplicativos não é definido sobre relações inteiras, mas sim sobre seus 
subconjuntos. 
Segundo, sendo a relação inteira a unidade de distribuição e os aplicativos que têm 
visões definidas sobre uma dada relação residem em sites diferentes, podem ser seguidas 
duas alternativas. Ou a relação não é replicada e é armazenada em um único site, o que 
resultaria em um volume desnecessariamente alto de acessos remotos aos dados. Ou então 
ela é replicada em todos ou alguns sites onde residem os aplicativos, o que geraria 
problemas na execução de atualizações. 
 
 14 
Por fim, a decomposição de uma relação em fragmentos, sendo cada um deles 
tratado como uma unidade, permite que várias transações sejam executadas de forma 
concorrente. Além disso, a fragmentações de relações em geral resulta na execução paralela 
de uma única consulta, dividindo-a em conjunto de subconsultas que operam sobre 
fragmentos. 
Além disso, é necessário também mencionar as desvantagens da fragmentação. Se 
os aplicativos têm requisitos conflitantes que impedem a decomposição das relações em 
fragmentos mutuamente exclusivos, esses aplicativos cujas visões são definidas sobre mais 
de um fragmento podem sofrer degradação de desempenho. O segundo problema está 
relacionado com o controle semântico de dados semânticos, especificamente com 
verificação de integridade. Como resultado da fragmentação, os atributos que participam de 
uma dependência podem ser decompostos em diferentes fragmentos, os quais poderiam ser 
alocados em sites diferentes. Nesse caso, até mesmo a tarefa mais simples de verificação de 
dependência resultaria em uma busca por dados em diversos sites [Özsu, M.; Valduriez, 
2001]. 
 
3.2 Grau de fragmentação 
O grau de fragmentação a que um banco de dados deve ser submetido representa 
uma decisão importante que afeta o desempenho do processamento de consultas. O grau de 
fragmentação vai de um extremo de nenhuma fragmentação a outro extremo, que seria 
fragmentação até o nível de tuplas individuais (no caso de fragmentação horizontal) ou até 
o nível de atributos individuais (no caso de fragmentação vertical). 
Considerando os efeitos adversos de unidades de fragmentação muito grandes ou 
muito pequenas, conforme analizado anteriormente, é necessário encontrar um nível 
adequado de fragmentação que mantenha um compromisso com os dois extremos. Tal nível 
só pode ser definido em relação aos aplicativos que atuarão sobre o banco de dados [Özsu, 
M.; Valduriez, 2001]. 
 
 15 
3.3 Alternativas de fragmentação 
As instâncias de relações são essencialmente tabelas, a assim a questão é encontrar 
modos alternativos de dividir uma tabela em tabelas menores. Existem duas alternativas 
para isso: dividir a tabela horizontalmente ou verticalmente. 
3.3.1 Fragmentação horizontal 
A fragmentação horizontal particiona uma relação em suas tuplas. Portanto, cada 
fragmento tem um subconjunto das tuplas da relação. Um fragmento pode ser obtido como 
uma seleção sobre a relação global, ou seja, é usado um predicado para construir o 
fragmento. Para ilustrar a utilização desta modalidade de fragmentação será utilizado o 
exemplo da instituição financeira estudado anteriormente, considerando que a instituição 
financeira possui agências nas cidades de São Paulo, Curitiba e Porto Alegre: 
Exemplo 1: Deseja-se que os dados da relação CLIENTE estejam particionados de 
modo que cada fragmento possua os dados da cidade correspondente. A tabela 3.1 
apresenta essa fragmentação: 
CLIENTE 
codigo_cliente nome fisica_juridica cpf_cnpj cidade 
1 Pedro da Silva fisica 5693215487 Curitiba 
2 Francisco de Almeida fisica 87452102136 São Paulo 
3 Maria Aparecia da Silva fisica 96583215874 São Paulo 
4 Luiz Carlos Barbosa fisica 8589698421 Curitiba 
5 Roberto César Xavier fisica 20320152147 Porto Alegre 
 
 
 
 
 
 
 
Tabela 3.1: Fragmentação horizontal da relação CLIENTE 
CLIENTE1 
codigo_cliente nome ... cidade 
1 Pedro da Silva Curitiba 
4 Luiz Carlos Barbosa Curitiba 
 CLIENTE2 
codigo_cliente nome ... cidade 
2 Francisco de Almeida São Paulo 
3 Maria Aparecia da Silva São Paulo 
 CLIENTE3 
codigo_cliente nome ... cidade 
5 Roberto César Xavier Porto Alegre 
 
 
 16 
Exemplo 2: Deseja-se que as contas correntes com saldo superior a R$ 10.000,00 
residam na cidade de São Paulo, as contas correntes com saldo superior a R$ 5.000,00 até 
R$ 10.000,00 residem em Curitiba, e as contas corrente com saldo até R$ 5.000,00 residam 
em Porto Alegre. A tabela 3.2 mostra essa situação: 
CONTA 
agencia numero_conta codigo_cliente data_abertura limite_creditosaldo data_encerra
mento 
1 93521 1 18/03/2005 500,00 1.000,00 
2 74258 2 05/08/2001 1.200,00 14.000,00 
2 23685 3 01/05/2005 750,00 9.000,00 
1 63695 4 19/06/2000 2.000,00 2.750,00 
3 98547 5 20/09/2002 900,00 11.580,00 
 
 
 
 
 
 
 
 
 
 
 
 
Tabela 3.2: Fragmentação horizontal da relação CONTA 
 
3.3.2 Fragmentação vertical 
A fragmentação vertical de uma relação produz fragmentos que contém um 
subconjunto dos atributos da relação, bem como sua chave primária. O objetivo da 
fragmentação vertical é particionar uma relação em um conjunto de relações menores, de 
tal modo que muitos dos aplicativos do usuário possam atuar apenas sobre um fragmento, 
diminuindo a quantidade de acessos a páginas [Navathe et al., 1984]. Também é possível 
identificar as sub-relações mais “ativas” e inseri-las em um subsistema de memória mais 
rápido, nos casos em que as hierarquias de memórias são administradas [Eisner e 
Severance, 1976]. 
CONTA1 
agencia numero_conta codigo_cliente ... limite_credito saldo 
2 74258 2 1.200,00 14.000,00 
3 98547 5 900,00 11.580,00 
 
CONTA2 
agencia numero_conta codigo_cliente ... limite_credito saldo 
2 23685 3 750,00 9.000,00 
 
CONTA3 
agencia numero_conta codigo_cliente ... limite_credito saldo 
1 93521 1 500,00 1.000,00 
1 63695 4 2.000,00 2.750,00 
 
 
 17 
Exemplo: A relação CONTA é particionada de modo que os atributos cadastrais 
sejam separados do saldo e limite de crédito. Desta forma os dados referentes a abertura e 
encerramento de contas podem ser administrados por um determinado setor e os dados 
financeiros podem estar sendo manipulados por outro setor da organização, separados 
geograficamente. A tabela 3.3 demonstra esse tipo de fragmentação: 
 
 
 
 
 
 
 
 
 
Tabela 3.3: Fragmentação vertical da relação CONTA 
 
3.4 Regras de fragmentação 
As regras a seguir em conjunto irão assegurar que o banco de dados não sofrerá 
nenhuma mudança semântica durante a fragmentação. 
Completeza. Se uma instância da relação R é decomposta em fragmentos, cada item 
de dado que pode ser encontrada em R também pode ser encontrada em um ou mais de seus 
fragmentos. Esta propriedade garante que os dados de uma relação global serão mapeados 
em fragmentos sem perdas [Grant, 1984]. No caso de fragmentação horizontal, o ítem de 
dado se refere a tuplas enquanto que na fragmentação vertical, se refere a um atributo da 
relação R [Özsu, M.; Valduriez, 2001]. 
Reconstrução. Se uma relação R é decomposta em fragmentos, deve ser possível 
definir um operador relacional que aplicado sobre os fragmentos retorne a relação original. 
CONTA1 
agencia numero_conta limite_credito saldo 
1 93521 500,00 1.000,00 
2 74258 1.200,00 14.000,00 
2 23685 750,00 9.000,00 
1 63695 2.000,00 2.750,00 
3 98547 900,00 11.580,00 
 
CONTA2 
agencia numero_conta codigo_cliente data_abertura data_encerramento 
1 93521 1 18/03/2005 
2 74258 2 05/08/2001 
2 23685 3 01/05/2005 
1 63695 4 19/06/2000 
3 98547 5 20/09/2002 
 
 
 18 
Este operador será diferente para cada forma de fragmentação, porém, é importante que ele 
possa ser identificado [Özsu, M.; Valduriez, 2001]. 
Disjunção. Se uma relação R é decomposta horizontalmente em fragmentos, e o 
item de dados está em Rj, ele não está em qualquer outro fragmento diferente de Rj. Se a 
relação R é decomposta verticalmente, os atributos de sua chave primária normalmente se 
repetem em todos os seus fragmentos. Assim, no caso de particionamento vertical, a 
disjunção só é definida sobre os atributos que não fazem parte da chave primária de uma 
relação [Özsu, M.; Valduriez, 2001]. 
 
3.5 Alocação 
O problema da alocação de recursos através dos nós de uma rede de computadores 
envolve encontrar a distribuição “ótima” do conjunto de fragmentos entre o conjunto de 
sites disponíveis. O caráter ótimo pode ser definido com relação às medidas Custo mínimo 
e Desempenho. 
A função de custo consiste no custo do armazenamento, consulta e atualização em 
todos os sites onde um determinado fragmento possa estar armazenado e também no custo 
da comunicação de dados. 
Com relação ao desempenho, a estratégia de alocação é projetada para minimizar o 
tempo de resposta e maximizar o throughput (vazão) do sistema em cada site. Em outras 
palavras, deve-se procurar um esquema de alocação que responda às consultas do usuário 
em tempo mínimo e mantém mínimo o custo do processamento. 
Supondo-se que o banco de dados seja fragmentado de forma apropriada, é 
necessário decidir sobre a alocação dos fragmentos aos vários sites da rede. As razões para 
a replicação são a confiabilidade e a eficiência de consultas somente leitura. Se houver 
várias cópias de um item de dados, haverá uma chance de que alguma cópia dos dados 
esteja acessível em algum lugar, mesmo quando ocorrerem falhas do sistema. Além disso, 
consulta somente leitura que acessam os mesmos itens de dados poderão ser executadas em 
paralelo, pois existirão cópias em vários sites. Por outro lado, a execução de consultas de 
atualização causa problemas, porque o sistema tem de garantir que todas as cópias dos 
 
 19 
dados serão atualizadas de forma adequada. Portanto, a decisão sobre replicação é um 
compromisso que depende da proporção entre consultas somente de leitura e consultas de 
atualização. Essa decisão afeta quase todos os algoritmos e funções de controle de SGBDs 
distribuídos [Özsu, M.; Valduriez, 2001]. 
Um banco de dados não replicado (em geral chamado de banco de dados 
particionado) contém fragmentos alocados a sites, e só existe uma única cópia de qualquer 
fragmento na rede. Em caso de replicação, o banco de dados existe por inteiro em cada site 
(banco de dados totalmente replicado) ou os fragmentos estão distribuídos pelos sites 
(banco de dados parcialmente replicado). A tabela 3.4 compara essas três alternativas de 
replicação em relação a diversas funções dos SGBDs distribuídos. 
 
 Replicação total Replicação parcial Particionamento 
Processamento de 
consultas 
Fácil 
Gerenciamento de 
diretórios 
Fácil ou não existente 
Controle de 
concorrência 
Moderado Difícil Fácil 
Confiabilidade Muito alta Alta Baixa 
Realidade Aplicação possível Realista Aplicação possível 
 
Tabela 3.4: Comparação entre alternativas de replicação 
 
Mesmo grau de dificuldade 
Mesmo grau de dificuldade 
 
 20 
4. Processamento de consultas distribuídas 
 
Ao ocultar os detalhes de baixo nível a respeito da organização física dos dados, as 
linguagens de bancos de dados relacionais (SQL) permitem a expressão de consultas 
complexas de modo conciso e simples. Em particular, para construir a resposta à consulta, o 
usuário não especifica exatamente o procedimento a ser seguido, ficando esta tarefa a cargo 
de um módulo do SGBD chamado processador de consultas, que terá o trabalho de realizar 
a otimização da consulta, pois ele é capaz de explorar uma grande quantidade de 
informações úteis a respeito do banco de dados [Özsu, M.; Valduriez, 2001]. 
A principal função de um processador de consultas relacionais é transformar uma 
consulta de alto nível em uma consulta equivalente de nível mais baixo, que implementa a 
estratégia de execução para a consulta. A transformação deve alcançar tanto a correção 
quanto a eficiência. Pelo fato de muitas estratégias de execução serem transformações 
corretas da mesma consulta de alto nível, aquela que otimiza (minimiza) o consumo de 
recursos deve ser a escolhida. Tendo em vista que, em termos computacionais, o problema 
não pode ser manipulado com um grande número de relações [Ibaraki e Kameda, 1984], em 
geral é reduzido a escolha de uma solução próxima da solução ótima. 
O problema do processamento de consultas em um ambiente distribuído é muito 
mais difícil que em um ambiente centralizado, porque um número maior de parâmetros 
afeta o desempenho de consultas distribuídas. Em particular, as relações envolvidas emuma consulta distribuída podem ser fragmentadas e/ou replicadas, induzindo assim os 
custos de sobrecarga de comunicação. Além disso, se forem acessados muitos sites, o 
tempo de resposta da consulta poderá se tornar muito alto. O papel de um processador de 
consultas distribuídas é mapear uma consulta de alto nível sobre um banco de dados 
distribuído em uma seqüência de operações de bancos de dados sobre fragmentos da 
relação, escolhendo os melhores sites para processar dados e, possivelmente, o modo como 
os dados devem ser transformados [Özsu, M.; Valduriez, 2001]. 
O grande desafio do processamento de consultas em um banco de dados distribuído 
está em elaborar a melhor estratégia para obter o resultado esperado, considerando que: 
 
 21 
• As relações envolvidas na consulta podem não estar presentes no site originário 
da consulta; 
• As relações envolvidas na consulta podem estar fragmentadas em vários sites; 
• Os fragmentos de uma relação envolvida na consulta podem estar replicados em 
vários sites; 
• Algum site onde residem os fragmentos de uma relação pode estar inoperante 
em dado momento. 
Nestas condições, algumas perguntas devem ser respondidas com o objetivo de 
obter a melhor estratégia de execução: 
• Quais fragmentos de uma relação estão envolvidos na consulta? 
• Onde está localizada a réplica de um fragmento envolvido de modo que o custo 
de obtenção de resposta seja o menor possível? 
• O site considerado ideal para obtenção de um fragmento envolvido está 
operante? Caso não esteja, qual site é a melhor alternativa? 
É evidente que a execução de uma consulta, por mais simples que seja, assume um 
grau de complexidade muito maior em um ambiente distribuído, se comparado a um 
ambiente centralizado. 
Em um sistema de banco de dados distribuído, o custo total a ser minimizado inclui 
os custos de CPU, E/S e comunicação. Os dois primeiros são os únicos fatores 
considerados pelos SGBDs centralizados. O componente de custo de comunicação talvez 
seja o fator mais importante considerado pelos bancos de dados distribuídos, portanto, o 
objetivo da otimização de consultas distribuídas se reduz ao problema de minimizar o custo 
de comunicação de forma geral, a expensas de processamento local, ainda que os ambientes 
modernos de processamento distribuído utilizam redes de comunicação muito rápidas, cuja 
largura de banda é comparada a largura de banda de discos. A vantagem é que a otimização 
local pode ser feita de forma independente, com o uso dos métodos conhecidos para 
sistemas centralizados. O custo de comunicação é o tempo necessário para a troca de dados 
entre os sites que participam da execução da consulta. Esse custo é incidente no 
 
 22 
processamento de mensagens (formatação/desformatação) e na transmissão dos dados pela 
rede de comunicação [Özsu, M.; Valduriez, 2001]. 
 
4.1 Transformação de consulta 
Ao executar uma consulta extremamente simples como: “obter todas as tuplas da 
relação CONTA”, seu processamento não é trivial em um contexto distribuído, uma vez 
que a relação pode estar fragmentada, replicada ou de ambas as formas. Se a relação 
CONTA for replicada, é necessário escolher de qual réplica obter o resultado. Se nenhuma 
replica for fragmentada, basta escolher a replica cujo custo de transmissão seja menor. 
Entretanto, se uma réplica for fragmentada, a escolha não será fácil, pois será necessário 
efetuar diversas junções e uniões para reconstrução da relação CONTA. Nesse caso, o 
número de estratégias possíveis para uma consulta, aparentemente trivial, pode ser grande 
[Silberschatz, A.; Korth, H.; Sudarshan, S., 1999]. 
Desenvolvendo o exemplo da instituição financeira utilizado, são apresentadas a 
seguir duas estratégias de execução em um ambiente distribuído para a consulta: obter o 
código e o nome do cliente, o saldo da conta corrente e o valor total das movimentações de 
todas as contas correntes com saldo superior a R$ 5.000,00 e que realizaram 
movimentações no período de 01/01/2006 a 31/01/2006. Será considerado que o banco de 
dados é distribuído através dos sites residentes nas cidades de São Paulo, Curitiba e Porto 
Alegre e que o site residente em Curitiba é originário da consulta. Conforme ilustrado na 
figura 4.1, as relações CONTA e CLIENTE estão fragmentadas de modo que cada site 
concentre os dados das cidades correspondentes, enquanto que a relação MOVIMENTO 
está totalmente replicada em cada um dos sites existentes. 
 
 
 
 
 
 
 
 
 
 
 23 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.1: Modelo de fragmentação do banco dados 
 
A consulta apresentada poderia ser expressa através da linguagem SQL da seguinte 
forma: 
 
 SELECT CLIENTE.CODIGO_CLIENTE, CLIENTE.NOME, CONT A.SALDO, SUM(MOVIMENTO.VALOR) 
 FROM CLIENTE, CONTA, MOVIMENTO 
 WHERE CLIENTE.CODIGO_CLIENTE = CONTA.CODIGO_CLIE NTE 
 AND CONTA.AGENCIA = MOVIMENTO.AGENCIA 
 AND CONTA.NUMERO_CONTA = MOVIMENTO.NUMERO_CONTA 
 AND CONTA.SALDO > 5000 
 AND MOVIMENTO.DATA BETWEEN '01/01/2006' AND '3 1/01/2006' 
GROUP BY CLIENTE.CODIGO_CLIENTE, CLIENTE.NOME, CONT A.SALDO 
 
A primeira estratégia explora o fato de que as relações CONTA E CLIENTE são 
fragmentadas da mesma forma, a fim de obter um subconjunto resultante do processamento 
local em cada site e transferir este subconjunto para o site de origem da consulta (vide 
figura 4.2). 
 
 
 
 Site1 (São Paulo) 
 
CLIENTE1 
CONTA1 
MOVIMENTO 
 Site2 (Curitiba) 
 
CLIENTE2 
CONTA2 
MOVIMENTO 
 Site3 (Porto Alegre) 
 
CLIENTE3 
CONTA3 
MOVIMENTO 
 
 24 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.2: Estratégia 1 de processamento de consulta 
 
A segunda estratégia centraliza os dados necessários no site de origem da consulta 
antes de realizar o processamento, conforme representado na figura 4.3. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.3: Estratégia 2 de processamento de consulta 
Site1 (São Paulo) 
 
R1 = Processamento 
local 
Site2 (Curitiba) 
 
R2 = Processamento 
local 
R = R1 U R2 U R3 
Site3 (Porto Alegre) 
 
R3 = Processamento 
local 
Site1 (São Paulo) 
 
CLIENTE1 
CONTA1 
 
Site2 (Curitiba) 
 
CLIENTE = CLIENTE1 U CLIENTE2 U CLIENTE3 
CONTA = CONTA1 U CONTA2 U CONTA3 
MOVIMENTO 
 
R = Processamento local 
Site3 (Porto Alegre) 
 
CLIENTE3 
CONTA3 
 
 
 25 
 
Evidentemente a primeira estratégia se mostra mais eficiente, pois explora a 
capacidade de processamento distribuído do sistema e reduz o tráfego de rede ao 
transportar para o site de origem da consulta apenas os dados resultantes da consulta 
realizada localmente, enquanto que na segunda estratégia, todos os dados das relações 
CLIENTE e CONTA são concentrados no site dois, para só então realizar o processamento 
sobre uma maior massa de dados. 
Dentre as diversas técnicas utilizadas para otimização de consultas distribuídas, a 
apresentada anteriormente caracteriza-se pelo uso de semijunções na qual tem a principal 
finalidade de reduzir o tamanho da relação operando de uma junção. 
 
4.2 Localização de dados distribuídos 
Na execução de uma consulta sobre um banco de dados distribuído existe uma fase 
da preparação da consulta responsável por resolver o problema da localização dos dados, 
que constitui em transformar uma consulta expressa sobre relações globais em um consulta 
sobre fragmentos físicos. A localização utiliza informações armazenadas no esquema de 
fragmentos. 
A fragmentação é definida por meio de regras de fragmentação, que podem ser 
expressas como consultas relacionais. Uma relação global pode ser reconstruída pela 
aplicação das regras de reconstrução e pela derivação de um programa de álgebra relacional 
cujos operandos são os fragmentos. Isso se denomina programa de localização. Uma forma 
ingênua de localizar uma consulta distribuída é gerar uma consulta em que cada relação 
global é substituída por seu programa de localização. 
Exemplo: A função de fragmentação horizontaldistribui a relação CONTA com 
base em predicados de seleção da seguinte forma: 
 
CONTA1 = Contas com saldo menor que R$ 5.000,00 
CONTA2 = Contas com saldo de R$ 5.000,00 a R$ 10.000,00 
CONTA3 = Contas com saldo superior a R$ 10.000,00 
 
 26 
 
O programa de localização para a relação CONTA fragmentada horizontalmente é a 
união dos fragmentos: 
CONTA = CONTA1 U CONTA2 U CONTA3 
Assim, a forma genérica de qualquer consulta especificada sobre CONTA é obtida 
substituindo-a por (CONTA1 U CONTA2 U CONTA3). 
As seleções sobre os fragmentos que têm uma qualificação que contradiz a 
qualificação da regra de fragmentação geram relações vazias. Estas seleções devem ser 
ignoradas gerando uma consulta reduzida. 
Exemplo: A consulta para obter as contas-correntes com saldo inferior a R$ 
10.000,00 poderia ser expressa através do seguinte comando SQL: 
 
SELECT * 
FROM CONTA 
WHERE SALDO < 10000,00 
 
É fácil detectar que o predicado de seleção (SALDO < 10000,00) contradiz o 
predicado de CONTA3, produzindo assim uma relação vazia. A consulta reduzida é 
simplesmente aplicada sobre a união de CONTA1 e CONTA2. 
 
 27 
5. Transações distribuídas 
 
Até o momento, a primitiva básica de acesso considerada era uma consulta. No 
entanto, deve ser considerado o que pode acontecer se, por exemplo, duas consultas tentam 
atualizar o mesmo item de dados, ou se ocorre uma falha do sistema durante a execução de 
uma consulta. No caso de consulta apenas de recuperação, nenhuma dessas condições é um 
problema. Porém, no caso de consultas de atualização, essas condições podem ter efeitos 
desastrosos sobre o banco de dados. Por exemplo, não é correto apenas reiniciar a execução 
de uma transação após a recuperação de uma falha do sistema, pois alguns valores de itens 
de dados já podem ter sido atualizados antes da falha e não devem ser atualizados 
novamente quando a consulta for reinicializada. Com isso, o banco de dados conteria dados 
incorretos [Özsu, M.; Valduriez, 2001]. 
O conceito de transação é usado dentro do domínio de banco de dados como uma 
unidade básica de computação consistente e confiável. Um banco de dados está em estado 
consistente se ele obedece a todas as restrições de consistência (integridade) definidas sobre 
ele. Uma transação toma um banco de dados, executa uma ação sobre ele e gera uma nova 
versão do banco de dados, provocando uma transição de estado. As mudanças de estados 
ocorrem devido a modificações, inserções e eliminações (atualizações). Considerando que o 
banco de dados pode estar (e em geral está) temporariamente inconsistente durante a 
execução de uma transação, o importante é que o banco de dados esteja consistente quando 
a transação terminar. A consistência da transação se refere às ações de transações 
concorrentes [Özsu, M.; Valduriez, 2001]. 
Uma transação sempre termina, mesmo quando há falhas. Se a transação pode 
completar sua tarefa com sucesso, então a transação se consolida. Por outro lado, se a 
transação pára sem completar sua tarefa, ela aborta. Quando uma transação é abortada, sua 
execução é interrompida e todas as suas ações já executadas são desfeitas, devolvendo-se o 
banco de dados a seu estado anterior ao início da transação. A consolidação assinala ao 
SGBD que os efeitos da transação devem agora estar refletidos no banco de dados, 
tornando-o assim visível para outras transações que possam acessar o mesmo item de 
dados. O ponto em que uma transação é consolidada é um “ponto sem retorno”, em que 
 
 28 
seus resultados estão permanentemente armazenados no banco de dados e não podem ser 
desfeitos. 
 
5.1 Propriedades de transações 
Os aspectos de consistência e confiabilidade das transações se devem a quatro 
propriedades: (1) atomicidade, (2) consistência, (3) isolamento e (4) durabilidade. Juntas, 
em geral elas são referidas como as propriedades ACID das transações [Date, C. J., 2004]. 
A atomicidade se refere ao fato de que a transação é tratada como uma unidade de 
operação. Assim, ou todas as ações da transação são concluídas, ou nenhuma delas se 
completa. A atomicidade exige que, se a execução de uma transação for interrompida por 
qualquer tipo de falha, o SGBD será responsável pela determinação do que fazer com a 
transação após a recuperação da falha. Ela pode ser encerrada completando-se as ações 
restantes ou pode ser encerrada desfazendo-se todas as ações que já foram executadas. 
A consistência de uma transação é simplesmente sua correção. Em outras palavras, 
uma transação é um programa correto que mapeia um estado consistente do banco de dados 
em outro. Verificar se as transações são consistentes é o objetivo do controle de dados 
semânticos, por outro lado, assegurar a consistência da transação é o objetivo dos 
mecanismos de controle da concorrência. 
O isolamento é a propriedade das transações que exige que cada transação veja um 
banco de dados consistente em todos os momentos. Em outras palavras, uma transação em 
execução não pode revelar seus resultados a outras transações concorrentes antes de se 
consolidar. A consistência entre as transações é necessária pois se duas transações 
concorrentes acessam um item de dados que está sendo atualizado por uma delas, não é 
possível garantir que a segunda lerá o valor correto. 
O termo durabilidade se refere à propriedade das transações que assegura que, uma 
vez que a transação se consolida, seus resultados se tornam permanentes e não podem ser 
apagados do banco de dados. Por conseguinte, o SGBD assegura que os resultados de uma 
transação permanecerão após a ocorrência de uma falha do sistema. 
 
 29 
 
5.2 Controle de transações distribuídas 
Existem basicamente dois tipos de transações que devem ser consideradas. As 
transações locais, que são aquelas que mantêm acesso e atualizam somente a base de dados 
local; e as transações globais, que são aquelas que mantêm acesso e atualizam diversas 
bases de dados locais. A garantia das propriedades ACID nas transações globais é bem 
mais complicada que nas transações locais, já que diversos sites podem participar de sua 
execução. Uma falha em um desses sites ou uma falha de comunicação entre sites pode 
resultar em erros no processamento [Silberschatz, A.; Korth, H.; Sudarshan, S., 1999]. 
Cada site possui seu próprio gerenciador local de transação, cuja função é garantir 
as propriedades ACID das transações executadas localmente. Os diversos gerenciadores de 
transações cooperam para executar as transações globais. Para entender como esses 
gerenciadores podem ser implementados, pode-se definir um modelo abstrato de um 
sistema de transações. Cada site contém dois subsistemas: 
O gerenciador de transações administra a execução daquelas transações que 
mantêm acesso aos dados armazenados no site local. Cada uma dessas transações pode ser 
uma transação local (que se processa somente naquele site) ou parte de uma transações 
global (que se processa em diversos sites). A estrutura do gerenciador de transações é 
similar em vários aspectos à estrutura usada nos sistemas centralizados. Cada gerenciador 
de transações é responsável pela manutenção de um log para propósito de recuperação e 
participação em um esquema de controle de concorrência adequado para coordenação da 
execução de transações concorrentes em um mesmo site [Silberschatz, A.; Korth, H.; 
Sudarshan, S., 1999]. 
O coordenador de transações coordena a execução de várias transações (tanto local 
quanto global) iniciadas naquele site. Um subsistema de coordenação de transações é 
responsável por iniciar a execução da transação, quebrar uma transação em um número 
determinado de subtransações de distribuí-las pelo sites apropriados para execução. 
Também é responsável por coordenar o término das transações, que podem resultar em 
 
 30 
efetivação em todos os sites ou em interrupção em todos os sites [Silberschatz, A.; Korth, 
H.; Sudarshan, S., 1999].5.3 Controle distribuído da concorrência 
O mecanismo de controle distribuído da concorrência de um SGBD distribuído 
assegura que a consistência do banco de dados seja mantida em um ambiente distribuído 
multiusuário. Se as transações são consistentes internamente, a maneira mais simples de 
alcançar esse objetivo é executar cada transação sozinha, uma depois da outra. Obviamente 
essa alternativa não pode ser implementada em nenhum sistema na prática, pois ela 
minimiza o throughput (vazão) do sistema. O nível de concorrência (ou seja, o número de 
transações concorrentes) talvez seja o parâmetro mais importante em sistemas distribuídos 
[Balter et al., 1982]. Por essa razão, o mecanismo de controle de concorrência tenta 
encontrar um equilíbrio adequado entre a manutenção da consistência do banco de dados e 
a manutenção de um nível elevado de concorrência [Özsu, M.; Valduriez, 2001]. Nesta 
seção serão descritos os algoritmos utilizados no controle de concorrência em Sistemas de 
Bancos de Dados Distribuídos e no capítulo seguinte será avaliado o controle de 
concorrência em um ambiente distribuído sujeito a falhas. 
No controle distribuído da concorrência são consideradas duas classes mais 
importantes de algoritmos: os algoritmos baseados em bloqueios e os algoritmos baseados 
em ordenação de timbres de hora. Tanto as classes de bloqueio quanto as de ordenação de 
timbres de hora tratam daquilo que se denomina algoritmos pessimistas. Qualquer 
algoritmo baseado em bloqueio pode resultar em impasses, exigindo métodos especiais de 
gerenciamento. Algoritmos pessimistas consideram que muitas transações entrarão em 
conflito entre si e, portanto, sincronizam a execução concorrente de transação mais cedo em 
seu ciclo de execução [Özsu, M.; Valduriez, 2001]. 
Existem ainda algoritmos otimistas, que consideram que não haverá um número 
muito grande de transações que entrarão em conflito entre si, e atrasam a sincronização das 
transações até seu término. 
 
 31 
5.3.1 Algoritmos baseados em bloqueios 
O controle de concorrência baseado em bloqueios consiste em um mecanismo para 
criar um ambiente de execução de diversas transações que disputam os mesmos itens de 
dados estabelecendo uma ordem de execução para as operações de cada transação de modo 
que cada transação obtenha o mais prontamente possível o acesso de que necessitam. Por 
exemplo, a transação X é constituída das operações (x1, x2, x3) e a transação Y pelas 
operações (y1, y2, y3). Se cada transação fosse executada separadamente, as operações 
seriam executadas na seqüencia em que aparecem (x1, x2, x3, y1, y2, y3), ou seja, primeiro as 
operações da transação X, depois as operações da transação Y. Isso faria com que a 
transação Y tivesse que aguardar o término da transação X para poder iniciar a sua 
execução, mesmo que não existam operações conflitantes entre as transações. Se após 
executar a operação x2 a operação y1 puder ser executada sem gerar inconsistências, a 
transação Y poderia iniciar antes do término da transação X, aumentando a concorrência. 
Então, a execução das operações poderia ser redefinida como (x1, x2, y1, x3, y2, y3). O 
algoritmo baseado em bloqueio deverá garantir que y1 não seja executada antes que x2 
libere o item de dados que y1 necessita [Özsu, M.; Valduriez, 2001]. 
A idéia principal do controle de concorrência baseado em bloqueios é assegurar que 
os dados compartilhados por operações conflitantes sejam acessados por uma única 
operação de cada vez. Isso é conseguido pela associação de um “bloqueio” a cada unidade 
de bloqueio. Esse bloqueio é definido por uma transação antes de ser acessado e é 
redefinido no final de seu uso. Uma unidade de bloqueio não poderá ser acessada por uma 
operação se já estiver bloqueada por outra. Portanto, uma solicitação de bloqueio por uma 
transação só será concedida se o bloqueio associado não estiver sendo mantido por outra 
transação [Özsu, M.; Valduriez, 2001]. 
O SGBD distribuído não apenas gerencia os bloqueios, mas também trata das 
responsabilidades de gerenciamento de bloqueios no interesse das transações. Em outras 
palavras, os usuários não têm de especificar quando os dados devem ser bloqueados; o 
SGBD distribuído se encarrega disso toda vez que a transação emite uma operação de 
leitura ou de gravação. 
 
 32 
Dos mecanismos de bloqueio o bloqueio em duas fases (2PL – two-phase locking) é 
o mais amplamente utilizado no gerenciamento da concorrência em bancos de dados 
distribuídos. A regra de bloqueio em duas fases estabelece simplesmente que nenhuma 
transação deve solicitar um bloqueio após liberar um de seus bloqueios. Como uma 
alternativa, uma transação não deve liberar um bloqueio até ter certeza de que não solicitará 
outro bloqueio. Os algoritmos de 2PL executam transações em duas fases. Cada transação 
tem uma fase de crescimento, na qual ela obtém bloqueios de que necessita e acessa itens 
de dados, e uma fase de contração, durante a qual ela libera os bloqueios obtidos. O 
gerenciador de bloqueio libera bloqueios logo que o acesso ao item de dados é concluído. 
Isso permite que outras transações que esperam pelo acesso prossigam e bloqueiem, 
aumentando assim o grau de concorrência. No entanto, é difícil de implementar essa ação, 
pois o gerenciador de bloqueios tem de saber que a transação obteve todos os seus 
bloqueios e não precisara bloquear outro item de dados. O gerenciador de bloqueio também 
precisa saber que a transação não necessita mais de acesso ao item de dados em questão, de 
forma que o bloqueio possa ser liberado. Finalmente, se a transação abortar depois de 
liberar um bloqueio, ela poderá fazer com que também sejam abortadas outras transações 
que talvez tenham acessado o item de dados desbloqueado. Isso é conhecido como abortar 
em cascata [Özsu, M.; Valduriez, 2001]. 
Devido a essas dificuldades, a maioria dos escalonadores de 2PL implementa aquilo 
que se denomina bloqueio de duas fases estrito, que libera todos os bloqueios juntos 
quando a transação termina (efetivada ou abortada). 
5.3.2 Algoritmos baseados em timbre de hora 
Diferentes dos algoritmos baseados em bloqueios, os algoritmos de controle da 
concorrência baseados em timbre de hora não tentam estabelecer uma ordem de execução 
para as operações conflitantes das transações que concorrem pelo mesmo item de dados 
através da exclusão mútua. 
Um timbre de hora é um identificador simples que serve para identificar cada 
transação de forma exclusiva e para permitir a ordenação. Há várias maneiras de atribuir 
timbres de hora. Um método é usar um contador global (no âmbito do sistema) 
monotonamente crescente. Entretanto, a manutenção de contadores globais é um problema 
 
 33 
em sistemas distribuídos. Então, é preferível que cada site atribua timbre de hora de forma 
autônoma, com base em seu contador local. Para manter a unicidade, cada site acrescenta 
seu próprio identificador ao valor do contador. Assim, o timbre de hora é uma tupla de dois 
elementos da forma <valor do contador, identificador do site>. 
Com essa informação, é simples ordenar a execução das operações de transações de 
acordo com seus timbres de hora. Ao executar duas operações conflitantes, pertencentes a 
transações diferentes, será executada primeiro aquela que possuir o menor timbre de hora, 
ou seja, a mais antiga, e em seguida será executada a mais nova. 
Um escalonador que impõe a regra de timbre de hora verifica cada nova operação, 
comparando-a com operações conflitantes que já tenham sido escalonadas. Se a nova 
operação pertencer a uma transação mais nova que todas as transações conflitantes que já 
foram escalonadas, a operação será aceita; do contrário, ela será rejeitada, fazendo toda a 
transação reiniciar com um novo timbre de hora [Özsu, M.; Valduriez, 2001]. 
5.3.3 Gerenciamento de impasses 
De modo informal, uma situação de impasse é um conjunto de solicitações quejamais poderão ser concedidas pelo mecanismo de controle da concorrência. Um impasse 
pode ocorrer porque as transações esperam uma pela outra [Özsu, M.; Valduriez, 2001]. 
Por exemplo, duas transações T1 e T2 mantêm bloqueios de gravação sobre as 
entidades x e y respectivamente. Em determinado momento da execução da transação T1, 
ela solicita uma operação de acesso à entidade y, bloqueada pela transação T2. No entanto, 
se durante esse período de espera T2 solicitar um bloqueio sobre x, haverá um impasse. Isso 
ocorre porque T1 estará bloqueada esperando T2 liberar seu bloqueio sobre y, enquanto T2 
estará esperando T1 liberar seu bloqueio sobre x. 
Um impasse é um fenômeno permanente. Se houver um impasse em um sistema, ele 
não terminará a menos que ocorra uma intervenção externa. Essa interferência pode vir do 
usuário, do operador do sistema ou do sistema de software (o sistema operacional o SGBD 
distribuído). 
 
 34 
Uma situação de impasse torna-se mais complicada em sistemas distribuídos, pois 
duas transações que participam de uma condição de impasse podem estar em execução em 
sites diferentes. Neste caso, é chamada situação de impasse global. 
Há três métodos conhecidos para tratamento de impasses: prevenção, anulação e 
ainda detecção e resolução. 
Os métodos de prevenção de impasses garantem que os impasses não podem 
ocorrer. Portanto, o gerenciador de transações verifica uma transação quando ela é 
inicializada pela primeira vez e não permite que ela prossiga se houver a possibilidade de 
um impasse. Para isso, é necessário que todos os itens de dados que serão acessados por 
uma transação sejam declarados previamente. O gerenciador de transações permitirá que a 
transação prossiga somente se todos os itens de dados aos quais ela terá acesso estiverem 
disponíveis. 
O método de tratamento de impasses baseado em anulação de impasses irá evitar a 
ocorrência do impasse abortando uma das transações. Se uma solicitação de bloqueio de 
uma transação T1 for negada, o gerenciador de bloqueio não forçará automaticamente T1 a 
esperar. Em vez disso, ele aplicará um teste de prevenção à transação solicitante e à 
transação que mantém atualmente o bloqueio (T2, por exemplo). Se aprovada no teste, T1 
terá permissão para esperar por T2, caso contrário, uma ou outra transação será abortada. 
Exemplos desta abordagem são os algoritmos WAIT-DIE e WOUND-WAIT [Rosenkrantz 
et al., 1978]. O algoritmo WAIT-DIE verifica se T1 é mais antiga que T2, caso seja, T1 
poderá esperar por T2, caso contrário (se T1 for mais nova que T2), então T1 será abortada e 
reinicializada. O algoritmo WOUND-WAIT verifica se T1 é mais nova que T2, caso seja, T1 
poderá esperar por T2, caso contrário (se T1 for mais antiga que T2), então T2 será abortada 
e o bloqueio concedido a T1 [Özsu, M.; Valduriez, 2001]. 
Existe ainda o método de tratamento de impasses baseado na detecção e resolução 
de impasses. A detecção é feita estudando-se a possibilidade de formação de ciclos de 
espera entre as transações. Em geral, a resolução de impasse é feita pela seleção de uma ou 
mais transações vítimas que serão apropriadas antecipadamente e abortadas para romper 
um possível ciclo de dependência entre as transações. 
 
 35 
5.3.4 Algoritmos otimistas para controle de concorrência 
Os algoritmos de controle de concorrência vistos anteriormente são considerados 
pessimistas, pois pressupõem que os conflitos entre as transações são bastante freqüentes e 
não permitem que uma transação acesse um item de dados de houver uma transação 
conflitante que tenha acesso a esse item de dados. Desse modo, a execução de qualquer 
operação de uma transação segue a seqüência de fases: validação, leitura, computação, 
gravação. Em geral, essa seqüência é válida para uma transação de atualização, e também 
para cada uma de suas operações [Özsu, M.; Valduriez, 2001]. 
Por outro lado, os algoritmos otimistas, atrasam a fase de validação até um pouco 
antes da fase de gravação. Assim, uma operação submetida a um escalonador otimista 
nunca é atrasada. As operações de leitura, computação e gravação de cada transação são 
processadas livremente, sem atualizar o banco de dados real. A fase de validação consiste 
em verificar se essas atualizações manteriam a consistência do banco de dados. Se a 
resposta for afirmativa, as mudanças se serão gravadas no banco de dados real. Caso 
contrário, a transação será abortada e terá de ser reinicializada [Özsu, M.; Valduriez, 2001]. 
 
 
 36 
6. Confiabilidade de SGBDs distribuídos 
 
Um sistema de gerenciamento de bancos de dados distribuído confiável é aquele 
que pode continuar a processar solicitações do usuário, mesmo quando o sistema subjacente 
não é confiável. Em outras palavras, até mesmo quando componentes do ambiente de 
computação distribuída falham, um SGBD distribuído confiável deve ser capaz de 
continuar a executar solicitações do usuário sem violar a consistência do banco de dados 
[Özsu, M.; Valduriez, 2001]. 
Para um sistema distribuído ser robusto ele precisa detectar falhas, reconfigurar o 
sistema para que ele possa continuar funcionando e recuperar a situação original durante o 
retorno de uma ligação ou de um processador [Silberschatz, A.; Korth, H.; Sudarshan, S., 
1999]. 
O projeto de um sistema confiável que possa se recuperar de falhas requer a 
identificação dos tipos de falhas com que o sistema tem de lidar. Um gerenciador de 
recuperação de banco de dados tem de lidar com quatro tipos de falhas: falhas de transação, 
falhas de sites, falhas de mídia e falhas de linha de comunicação [Özsu, M.; Valduriez, 
2001]. 
As falhas diferentes são tratadas de modos diferentes. Perda de mensagens são 
retransmitidas. Retransmissão repetida de uma mensagem, sem mensagem de 
reconhecimento, é normalmente sintoma de perda de comunicação. Em geral, a rede tenta 
encontrar rotas alternativas para uma mensagem. Falhas nessas tentativas sugerem 
particionamento da rede [Silberschatz, A.; Korth, H.; Sudarshan, S., 1999]. 
Entretanto, geralmente não é possível ter certeza se houve falha na comunicação 
entre sites ou se houve particionamento da rede. O sistema detecta a falha, mas não 
consegue identificar o tipo. Por exemplo, caso o site S1 não consiga se comunicar com o 
site S2. Pode ser que S2 esteja com problemas. Entretanto, pode ser que a ligação entre S1 e 
S2 não esteja funcionando, particionando a rede. 
Caso o site S1 tenha identificado uma falha, ele iniciará um procedimento para 
reconfiguração do sistema e, então, prosseguirá no modo de operação normal. 
 
 37 
• Se há dados replicados no site que não está funcionando, o catálogo deverá ser 
atualizado para que as consultas não solicitem acesso à cópia desse site. 
• Se no site com problemas houver transações ativas no momento da falha, essas 
transações deverão ser abortadas. É preferível abortar essas transações 
rapidamente, já que elas poderão manter bloqueios em dados em sites ainda 
ativos. 
• Se o site que não está funcionando é um servidor de algum subsistema, deverá 
ser feita uma eleição para determinar o novo servidor. Alguns exemplos de 
servidores centrais são os servidores de nomes, coordenador de concorrência ou 
detector de deadlock global. 
Já que, em geral, não é possível distinguir entre falhas de rede e falhas de sites, 
qualquer esquema de reconfiguração precisa ser projetado de modo a trabalhar 
corretamente caso haja o particionamento da rede. Em particular, a seguinte situação 
precisa ser evitada: 
• Dois ou mais servidores são eleitos em partições distintas. 
• Mais de uma partição atualiza e replica itens de dados. 
A reintegração de um site ou da comunicação entre pares dentro de um sistema 
também exige cuidados. Quando um site volta a integrar a rede, é preciso que um 
procedimento seja executado para atualização das tabelas do sistema, de modo a refletir as 
alterações sofridas enquanto ele