Bancos de dados distribuídos

Prévia do material em texto

Brasília-DF. 
Banco de dados distriBuídos
Elaboração
Ednewton de Vasconcelos
Produção
Equipe Técnica de Avaliação, Revisão Linguística e Editoração
Sumário
APrESEntAção ................................................................................................................................. 4
orgAnizAção do CAdErno dE EStudoS E PESquiSA .................................................................... 5
introdução.................................................................................................................................... 7
unidAdE i
Introdução a Banco de dados dIstrIBuídos ................................................................................. 9
CAPítulo 1
conceIto de Banco de dados dIstrIBuídos ...................................................................... 9
CAPítulo 2 
algumas questões prelImInares ....................................................................................... 16
CAPítulo 3 
Funções adIcIonaIs do Banco de dados dIstrIBuído ................................................... 20
unidAdE ii
prIncípIo de Banco de dados dIstrIBuídos ................................................................................... 22
CAPítulo 1 
Fundamentos do Banco de dados dIstrIBuídos ............................................................. 22
unidAdE iii
arquItetura e projeto de Banco de dados dIstrIBuídos............................................................. 32
CAPítulo 1 
transações ......................................................................................................................... 32
CAPítulo 2 
tIpos de sIstemas Bdd ......................................................................................................... 38
CAPítulo 3 
proBlemas de sIstemas dIstrIBuídos .................................................................................. 41
unidAdE iV
controle, sIncronIzação e atualIzação em sIstemas dIstrIBuídos ........................................... 49
CAPítulo 1 
processamento de consulta, sIstemas de dIretórIos e protocolos de acesso ao 
dIretórIo ............................................................................................................................. 49
PArA (não) finAlizAr ..................................................................................................................... 52
rEfErênCiA .................................................................................................................................... 53
4
Apresentação
Caro aluno
A proposta editorial deste Caderno de Estudos e Pesquisa reúne elementos que se entendem 
necessários para o desenvolvimento do estudo com segurança e qualidade. Caracteriza-se pela 
atualidade, dinâmica e pertinência de seu conteúdo, bem como pela interatividade e modernidade 
de sua estrutura formal, adequadas à metodologia da Educação a Distância – EaD.
Pretende-se, com este material, levá-lo à reflexão e à compreensão da pluralidade dos conhecimentos 
a serem oferecidos, possibilitando-lhe ampliar conceitos específicos da área e atuar de forma 
competente e conscienciosa, como convém ao profissional que busca a formação continuada para 
vencer os desafios que a evolução científico-tecnológica impõe ao mundo contemporâneo.
Elaborou-se a presente publicação com a intenção de torná-la subsídio valioso, de modo a facilitar 
sua caminhada na trajetória a ser percorrida tanto na vida pessoal quanto na profissional. Utilize-a 
como instrumento para seu sucesso na carreira.
Conselho Editorial
5
organização do Caderno 
de Estudos e Pesquisa
Para facilitar seu estudo, os conteúdos são organizados em unidades, subdivididas em capítulos, de 
forma didática, objetiva e coerente. Eles serão abordados por meio de textos básicos, com questões 
para reflexão, entre outros recursos editoriais que visam a tornar sua leitura mais agradável. Ao 
final, serão indicadas, também, fontes de consulta, para aprofundar os estudos com leituras e 
pesquisas complementares.
A seguir, uma breve descrição dos ícones utilizados na organização dos Cadernos de Estudos 
e Pesquisa.
Provocação
Textos que buscam instigar o aluno a refletir sobre determinado assunto antes 
mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor 
conteudista.
Para refletir
Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa e reflita 
sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio. É importante 
que ele verifique seus conhecimentos, suas experiências e seus sentimentos. As 
reflexões são o ponto de partida para a construção de suas conclusões.
Sugestão de estudo complementar
Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo, 
discussões em fóruns ou encontros presenciais quando for o caso.
Praticando
Sugestão de atividades, no decorrer das leituras, com o objetivo didático de fortalecer 
o processo de aprendizagem do aluno.
Atenção
Chamadas para alertar detalhes/tópicos importantes que contribuam para a 
síntese/conclusão do assunto abordado.
6
Saiba mais
Informações complementares para elucidar a construção das sínteses/conclusões 
sobre o assunto abordado.
Sintetizando
Trecho que busca resumir informações relevantes do conteúdo, facilitando o 
entendimento pelo aluno sobre trechos mais complexos.
Exercício de fixação
Atividades que buscam reforçar a assimilação e fixação dos períodos que o autor/
conteudista achar mais relevante em relação a aprendizagem de seu módulo (não 
há registro de menção).
Avaliação Final
Questionário com 10 questões objetivas, baseadas nos objetivos do curso, 
que visam verificar a aprendizagem do curso (há registro de menção). É a única 
atividade do curso que vale nota, ou seja, é a atividade que o aluno fará para saber 
se pode ou não receber a certificação.
Para (não) finalizar
Texto integrador, ao final do módulo, que motiva o aluno a continuar a aprendizagem 
ou estimula ponderações complementares sobre o módulo estudado.
7
introdução
Imaginação é mais importante que inteligência. 
Albert Einstein
As empresas, os bancos, o comércio, as indústrias e os mais diversos segmentos sociais têm estado 
muito interessados na descentralização do processamento de suas informações independentemente 
da localização geográfica de seus escritórios. E com a explosão da Internet ligada aos avanços 
tecnológicos e aos avanços nas telecomunicações, estas empresas estão cada vez mais propícias a 
utilizarem Banco de Dados Distribuídos (BDD).
A tecnologia de BDD surgiu como uma fusão de duas tecnologias: a de banco de dados e a tecnologia 
de rede e telecomunicações de dados. Enquanto os primeiros bancos de dados se voltaram para 
a centralização e resultaram em bancos de dados monolíticos nos anos 1970, logo nas décadas 
seguintes, o sistema de banco de dados foi-se alterando em pequenas proporções até chegar aos 
dias de hoje com o avanço de sistemas distribuídos e também decorrente dos sistemas operacionais 
distribuídos. 
Ao contrário dos sistemas paralelos, em que os processadores são bastante acoplados e constituem 
um único sistema de banco de dados, um sistema de banco de dados distribuídos consiste em sites 
poucos acoplados, que não compartilham componentes físicos. Além do mais, os sistemas de banco 
que executam em cada site podem ter um grau de independência mútua substancial. 
Outro fator relevante foi a comunidade de pesquisa de banco de dados ter desenvolvido um trabalho 
considerável para tratar as questões de distribuição de dados distribuídos e de outros tópicos, bem 
como ter desenvolvido muitos protótipos de pesquisa. 
Neste caderno será abordado, o tema banco de Dados Distribuídos, desenvolvimento de tecnologia de 
banco de dados que está aproximadamente vinculada aos avanços da tecnologia de telecomunicações 
e de rede.
objetivos
 » Apresentar as principais metodologias voltadas para a área de desenvolvimentode 
projetos de banco de dados distribuídos.
 » Conhecer os procedimentos para um entendimento entre os bancos de dados 
distribuídos e paralelos.
 » Apresentar os mecanismos para a implantação de banco de dados distribuídos.
 » Refletir sobre a gerência, manutenção de banco de dados distribuídos.
 » Elaborar algumas variedades de banco de dados diferentes gerenciados por vários 
SGBDs.
8
9
unidAdE i
introdução A 
BAnCo dE dAdoS 
diStriBuídoS
Se vocês acham que os seus professores são rudes, esperem até terem um chefe. Ele 
não vai ter pena de vocês. 
Bill Gates
CAPítulo 1
Conceito de banco de dados 
distribuídos
Os bancos de dados distribuídos trazem as vantagens da computação distribuída para o domínio 
do gerenciamento de banco de dados. Um sistema de computação distribuída consiste em vários 
elementos de processamento, não necessariamente homogêneos, que são interconectados por 
uma rede de computador e cooperam na execução de certas tarefas. Como uma meta genérica, os 
sistemas de computação distribuídos dividem um problema grande e intratável em partes menores 
e os resolvem de maneira eficiente e coordenada. 
Podemos definir um Banco de Dados Distribuído (BDD) como uma coleção de múltiplos bancos de 
dados logicamente interrelacionados distribuídos por uma rede de computadores, e um sistema de 
Gerenciamento de Banco de Dados Distribuídos (SGBD) como um sistema de software que gerencia 
um banco de dados distribuído enquanto torna a distribuição transparente para o usuário. 
Uma coleção de arquivos armazenados em nós diferentes de uma rede e a manutenção de inter-
relacionamentos entre eles via hiperlinks se tornou uma configuração comum na Internet, com os 
arquivos Web.
As funções comuns de gerenciamento de banco de dados, incluindo o processamento uniforme 
de consultas e o processamento de transações, não se aplicam, contudo, a esse cenário. Porém, a 
tecnologia está se modificando em uma direção tal que bancos de dados distribuídos no World Wide 
Web (WWW) se tornarão uma realidade no futuro próximo.
10
UNIDADE I │INtroDUção A BANco DE DADos DIstrIBUíDos
Banco de dados homogêneos e heterogêneos
 Em um sistema de banco de dados distribuídos homogêneo, todos os sites possuem software de 
sistema de gerenciamento de banco de dados idêntico, conhecem um ao outro e concordam em 
cooperar nas solicitações dos usuários do processamento. Neste tipo de sistema, os sites locais 
entregam uma parte de sua autonomia em termos do seu direito de mudar esquemas ou software de 
sistema de gerenciamento de banco de dados. Esse software também precisa cooperar com outros 
sites na troca de informações sobre transações, para tornar o processamento da transação possível 
entre vários sites.
Ao contrário, em um banco de dados distribuídos heterogêneo, diferentes sites podem usar 
diferentes esquemas e softwares de sistemas de gerenciamento de banco de dados. Os sites podem 
não ser cientes um do outro e podem oferecer facilidades apenas limitadas para cooperação no 
processo da transação. As diferenças nos esquemas normalmente são um problema importante 
para o processamento da consulta, enquanto a divergência no software se torna um obstáculo para 
o processamento de transações que acessam múltiplos sites.
Arquitetura cliente/servidor
O objetivo geral desses sistemas é fornecer suporte ao desenvolvimento e à execução de aplicações 
de banco de dados. Portanto, sob um ponto de vista de mais alto nível, um sistema desse tipo pode 
ser considerado de estrutura muito simples em duas partes, consistindo em um servidor, também 
chamado back end, e um conjunto de clientes, chamados front ends. 
O servidor é o próprio SGBD. Ele admite todas as funções básicas de SGBD, definição e manipulação 
de dados, segurança e integridade de dados, e assim por diante. Em outras palavras, o termo 
“servidor” neste contexto é tão somente um outro nome para o SGBD.
Os clientes são as diversas aplicações executadas no SGBD, tanto aplicações escritas por usuários 
quanto aplicações internas. No que se refere ao servidor, não existe diferença alguma entre 
aplicações escritas pelos usuários e aplicações internas; todas elas empregam a mesma interface 
para o servidor especificamente, a interface de nível externo. Certas aplicações especiais, chamadas 
“utilitárias”, podem constituir uma exceção ao que vimos antes, já que elas às vezes podem ter de 
operar diretamente no nível interno do sistema. Esses utilitários normalmente são considerados 
componentes internos do SGBD, em vez de aplicações no sentido mais comum.
As aplicações são divididas em dois tipos: aplicações escritas pelo usuário e aplicações fornecidas 
pelo fabricante.
As aplicações escritas pelo usuário são basicamente programadas de aplicação comuns, escritas (em 
geral) em uma linguagem de programação convencional de terceira geração (L3G), como C++ ou 
COBOL, ou então em alguma linguagem proprietária de quarta geração (L4G), embora em ambos os 
casos a linguagem precisa ser, de algum modo, acoplada a uma sublinguagem de dados apropriada.
11
Introdução a Banco de dados dIstrIBuídos│ unIdade I
As aplicações fornecidas por fabricante, também conhecidas de ferramentas, são aquelas cuja 
finalidade básica é auxiliar na criação e execução de outras aplicações. As criadas são aplicações 
adaptadas a alguma tarefa específica (elas podem não ser muito semelhantes às aplicações no 
sentido convencional). De fato, a finalidade das ferramentas é permitir aos usuários, em especial aos 
usuários finais, criar aplicações sem ter de escrever programas em uma linguagem de programação 
convencional. Por exemplo, uma ferramenta fornecida pelo fabricante será um gerador de relatórios 
cuja finalidade é permitir que os usuários finais obtenham relatórios formatados a partir do sistema 
sob requisição. Qualquer requisição de relatórios pode ser considerada um pequeno programa de 
aplicação, escrito em uma linguagem de geração de relatórios de nível muito alto.
Como o sistema por completo pode estar tão claramente dividido em duas partes, servidores e 
clientes, surge a possibilidade de executar os dois em máquinas diferentes. Em outras palavras, existe 
o potencial para o processamento distribuído. O processamento distribuído significa que máquinas 
diferentes podem estar conectadas entre si para formar algum tipo de rede de comunicações, de 
maneira que uma única tarefa de processamento de dados possa ser dividida entre várias máquinas 
na rede. Na verdade, essa possibilidade é tão atraente por diversos motivos, principalmente de 
ordem econômica, que o termo cliente/servidor passou a se aplicar quase exclusivamente ao caso 
em que o cliente e o servidor estão de fato localizados em máquinas diferentes.
Processamento distribuído
A expressão processamento distribuído significa que máquinas diferentes podem estar conectadas 
entre si em uma rede de comunicações. Um exemplo clássico é a Internet, em que uma única tarefa 
de processamento de dados possa se estender a várias máquinas na rede. A comunicação entre as 
várias máquinas é efetuada por algum tipo de software de gerenciamento de rede, possivelmente 
uma extensão do gerenciador DC ou, mais provavelmente, um componente de software separado.
 Gerenciador DC – Data Communications.
As mensagens de comunicação são transmitidas sob o controle de um outro 
componente de software. 
O gerenciador não faz parte do SGBD.
São possíveis muitos níveis ou variedades de processamento distribuído. Um caso simples envolve 
a execução do back end do SGBD (o servidor) em uma das máquinas e dos front ends da aplicação 
(os clientes), conforme a Figura 1.
12
UNIDADE I │INtroDUção A BANco DE DADos DIstrIBUíDos
Figura 1 – cliente(s) e servidor funcionando em máquinas diferentes
Como exercício de esclarecimento, esboce três exemplos de empresas que utilizem 
banco de dados distribuídos. 
Explique em detalhes, conforme a Figura 1.
Como vimos no item “Arquitetura Cliente/Servidor”, o termo cliente/servidorpassou a ser quase 
sinônimo da disposição ilustrada na Figura 1, na qual o cliente e o servidor funcionam em máquinas 
diferentes. De fato, há muitos argumentos em favor de um esquema desse tipo:
a. o argumento mais comum sobre o processamento paralelo, especificamente, 
duas ou mais máquinas estão sendo agora aplicadas na tarefa geral, enquanto o 
processamento do servidor (o banco de dados) e do cliente (a aplicação) está sendo 
feito em paralelo. Assim, o tempo de resposta e a vazão (throughput) devem ser 
melhorados;
b. além disso, a máquina servidora pode ser uma máquina feita por encomenda para 
se ajustar à função do SGBD e, assim, fornecer melhor desempenho ao SGBD;
c. mesmo assim, a máquina cliente poderia ser uma estação de trabalho pessoal, 
adaptada às necessidades do usuário final e, portanto, capaz de oferecer interfaces 
melhores, alta disponibilidade, respostas mais rápidas e, de modo geral, maiores 
com facilidade de utilização para o usuário;
d. várias máquinas clientes distintas poderiam ser capazes (na verdade, normalmente 
serão capazes) de obter acesso à máquina servidora. Assim, um único banco de dados 
poderia ser compartilhado entre vários sistemas clientes distintos, conforme Figura 2.
13
Introdução a Banco de dados dIstrIBuídos│ unIdade I
Figura 2 – uma máquina servidora, várias máquinas clientes
Como exercício de esclarecimento, analise a Figura 2 e cite exemplos de instituições 
que trabalham com esse tipo de serviço de banco de dados.
Além dos argumentos anteriores, existe também o fato de que as execuções dos clientes e dos 
servidores em máquinas diferentes correspondem ao modo como as empresas operam na realidade. 
É bastante comum que uma única empresa, um banco, por exemplo, opere muitos computadores, 
de tal modo que os dados correspondentes a uma parte da empresa sejam armazenados em um 
computador e os dados de outra parte sejam armazenados em outro computador. Prosseguindo 
com o exemplo do banco, é muito provável que os usuários de uma agência ocasionalmente tenham 
de obter acesso a dados armazenados em outra agência. Portanto, observe que as máquinas clientes 
poderiam ter seus próprios dados armazenados, e a máquina servidora poderia ter suas próprias 
aplicações. Dessa forma, em geral, cada máquina atuará como um servidor para alguns usuários e 
como cliente para outros, conforme a Figura 3. 
14
UNIDADE I │INtroDUção A BANco DE DADos DIstrIBUíDos
Figura 3 – cada máquina pode executar tanto os clientes como o servidor
Como exercício de esclarecimetno, analise a Figura 3 tente explicar com suas palavras 
o qeu você conseguiu entender.
O último ponto a mencionar é que uma única máquina cliente poderia ser capaz de obter acesso 
a várias máquinas servidoras diferentes conforme mostrado na Figura 2. Esse recurso é desejável 
porque, como já estudamos, as empresas, em geral, operam de tal maneira que a totalidade de seus 
dados não fica armazenada em uma única máquina, mas se espalha por muitas máquinas distintas, 
e as aplicações às vezes precisarão ter a capacidade de acessar dados de mais de uma máquina. 
Basicamente, esse acesso pode ser fornecido de dois modos distintos:
a. determinado cliente pode ser capaz de obter acesso a qualquer quantidade de 
servidores, mas somente um de cada vez, ou seja, cada requisição individual ao 
banco de dados tem de ser direcionada para apenas um servidor. Em um sistema 
desse tipo não é possível, dentro de uma única requisição, combinar dados de dois 
ou mais servidores diferentes. Além disso, o usuário de tal sistema tem de saber 
qual máquina em particular contém quais partes dos dados;
b. O cliente pode ser capaz de obter acesso a vários servidores simultaneamente, isto 
é, uma única requisição ao banco de dados poderia ter a possibilidade de combinar 
dados de vários servidores. Nesse caso, os servidores aparentam para o cliente, de 
um ponto de vista lógico, ser raramente um único servidor, e o usuário não precisa 
saber qual máquina contém cada uma das partes constituintes dos dados.
O item b constitui um exemplo daquilo que se costuma chamar sistema de banco de dados 
distribuído. Este tema é um grande tópico por si só. Levado a sua conclusão lógica, o suporte 
completo a bancos de dados distribuídos implica que uma única aplicação deve ser capaz de operar 
“de modo transparente” sobre dados espalhados por uma variedade de bancos de dados diferentes, 
15
Introdução a Banco de dados dIstrIBuídos│ unIdade I
gerenciados por uma variedade de SGBDs diferentes, funcionando em uma variedade de máquinas 
distintas, com suporte de uma variedade de sistemas operacionais diferentes e conectados entre si 
por meio de uma variedade de redes de comunicações diferentes.
“Modo transparente” significa que a aplicação opera de um ponto de vista lógico, 
como se os dados fossem todos gerenciados por um único SGBD executado em uma 
máquina.
16
CAPítulo 2 
Algumas questões preliminares
um sistema de banco de dados distribuído consiste em uma coleção de sites, interligados por meio 
de algum tipo de rede de telecomunicações, em que:
a. cada site é por ele próprio, um site completo do sistema de banco de dados;
b. os sites concordam em atuar juntos, de modo que um usuário em qualquer site 
pode ter acesso aos dados em qualquer lugar da rede, exatamente como se os dados 
estivessem armazenados no site do próprio usuário.
Ocorre que o chamado “banco de dados distribuído” é na verdade uma espécie de banco de dados 
virtual cujas partes componentes estão fisicamente armazenadas em vários bancos de dados “reais” 
distintos em vários sites distintos (com efeito, é a união lógica desses bancos de dados reais). Um 
exemplo claro é a Figura 4.
Figura 4 – um sistema de banco de dados distribuído típico
Como exercício de esclarecimento, analise a Figura 4. Se um cliente estiver em Lisboa, 
poderá acessar as mesmas informações do cliente que está em Brasília? Explique sua 
resposta.
17
Introdução a Banco de dados dIstrIBuídos│ unIdade I
Observe que, repetindo, cada site é um site do sistema de banco de dados por si mesmo. Em 
outras palavras, cada site possui seus próprios bancos de dados locais “reais”, seus próprios 
usuários locais, seu próprio SGBD local e software de gerenciamento de transações, e seu próprio 
gerenciador de comunicações de dados local (gerenciador DC). Em particular, qualquer usuário 
pode executar operações sobre dados no seu site local exatamente como se esse site não participasse 
de modo algum do sistema distribuído. O sistema de banco de dados distribuído em geral pode, 
portanto, ser considerado como um tipo de parceria entre SGBD individuais locais nos sites locais 
individuais; um novo componente de software em cada site uma extensão lógica do SGBD local 
fornece a funcionalidade necessária à parceria e é a combinação desse novo componente com o 
SGBD existente, o que constitui aquilo que se costuma chamar sistema de gerenciamento de 
banco de dados distribuído.
Vantagens
O gerenciamento de bancos de dados distribuídos tem sido proposto por diversas razões que variam 
desde a descentralização organizacional e a economia de processamento até a maior autonomia. 
Destacamos algumas dessas vantagens a seguir:
 » Gerenciamento de dados distribuídos com níveis diferentes de transparência 
– de forma ideal, um SGBD deveria ser transparente na distribuição, no sentido 
de esconder os detalhes de onde cada arquivo (tabela, relação) está armazenado 
fisicamente dentro do sistema.
 » Transparência de distribuição ou de rede – esta se refere à liberdade para o usuário 
em relação aos detalhes operacionais da rede.
 » Transparência de replicação – cópias dos dados podem ser armazenadas em 
múltiplos sites para obter melhor disponibilidade, desempenho e confiabilidade. A 
transparência de replicação faz o usuário não precisar estar ciente da existência das 
cópias.
 » Transparência de fragmentação – existem dois tipos de fragmentação. A 
fragmentação horizontal distribui umarelação em conjuntos de tuplas (linhas). 
Exemplo: Se a relação r for fragmentada, r será dividida em uma série de fragmentos 
r1, r2, ..., rn. Esses fragmentos contêm informações suficientes para permitir a 
reconstrução da relação original r. A fragmentação vertical distribui uma relação 
em sub-relações, nas quais cada sub-relação é definida por um subconjunto das 
colunas da relação original. Exemplo: A fragmentação vertical divide a relação 
decompondo o esquema R da relação r. A fragmentação vertical de r(R) envolve 
a definição de vários subconjuntos de atributos R1, R2, ..., Rn. A fragmentação 
horizontal normalmente é usada para manter tuplas nos sites em que são mais 
usados, para minimizar a transferência de dados.
 » Melhoria na confiabilidade e na disponibilidade – estas são duas das potenciais 
vantagens mais comuns citadas para bancos de dados distribuídos. A confiabilidade 
18
UNIDADE I │INtroDUção A BANco DE DADos DIstrIBUíDos
é definida de maneira ampla como a probabilidade de que um sistema esteja em 
operação (não seja inoperante) em um determinado momento, ao passo que a 
disponibilidade é a probabilidade de que o sistema esteja continuamente disponível 
durante um intervalo de tempo. Quando os dados e o software do SGBD são 
distribuídos por vários sites, um site pode falhar, então os outros não podem ser 
acessados. Isso faz aumentar a confiabilidade e a disponibilidade. Uma melhoria 
é obtida por meio de replicação criteriosa de dados e de software em mais que 
um site. Em um sistema centralizado, a falha em um dado torna o sistema inteiro 
indisponível para todos os usuários. Em um banco de dados distribuído, alguns 
dos dados podem ficar inalcançáveis, mas os usuários ainda podem acessar outras 
partes do banco de dados.
 » Melhoria de desempenho – um SGBD distribuído fragmenta o banco de dados 
mantendo os dados mais próximos de onde eles são mais necessários. A localização 
dos dados reduz a disputa pela CPU e por operações de Entrada/Saída, e 
simultaneamente reduz os atrasos de acesso envolvidos em redes remotas WAN. 
Quando um grande banco de dados é distribuído por múltiplos sites, bancos de 
dados menores existem em cada site. Como resultado, consultas e transações locais 
que acessam dados em um único site têm um desempenho melhor por causa dos 
bancos de dados menores locais. Além disso, cada site possui um número menor de 
transações que são executadas do que se todas as transações fossem submetidas a um 
único banco de dados centralizados. O paralelismo entre consultas (interqueries) e 
o paralelismo dentro das consultas (intraqueries) podem ser obtidos pela execução 
de múltiplas consultas em diferentes sites, ou pela quebra de uma consulta em 
diversas subconsultas que são executadas em paralelo. Isso contribui para a 
melhoria do desempenho.
 » Expansão mais fácil – em um ambiente distribuído a expansão do sistema quanto a 
acréscimo de mais dados, aumento do tamanho dos bancos de dados ou acréscimo 
de mais processadores é muito mais fácil.
Por que bancos de dados distribuídos são desejáveis? A resposta básica a essa pergunta é que 
normalmente as empresas já são distribuídas, pelo menos logicamente, em divisões, departamentos, 
grupos de trabalho etc. e, com grande probabilidade, também, fisicamente em fábricas, laboratórios 
entre outros. Disso decorre que os dados também já estão normalmente distribuídos, porque cada 
unidade organizacional dentro da empresa necessariamente manterá dados que são relevantes para 
sua própria operação. O patrimônio total das informações da empresa é, desse modo, disseminado 
naquilo que às vezes se costuma chamar de ilhas de informações. Um sistema distribuído fornece 
as pontes necessárias para conectar essas ilhas. Em outras palavras, ele permite que a estrutura do 
banco de dados reflita a estrutura da empresa. Dados locais podem ser mantidos em instalações 
locais, às quais eles pertencem logicamente, enquanto dados remotos estão disponíveis para serem 
acessados quando for necessário.
Um exemplo esclarecerá o que foi dito. Suponha que existam apenas dois sites, um em São Paulo 
e o outro no Rio de Janeiro, e que se trata de um sistema bancário, com dados de contas para as 
19
Introdução a Banco de dados dIstrIBuídos│ unIdade I
contas de São Paulo armazenadas em São Paulo e dados de contas para as contas do Rio de Janeiro 
armazenadas no Rio de Janeiro. Então, as vantagens são óbvias: o arranjo distribuído combina 
eficiência de processamento (os dados são mantidos próximos ao local em que são usados mais 
frequentemente) com maior facilidade de acesso (é possível ter acesso a uma conta no Rio de Janeiro 
a partir de São Paulo e vice-versa, por meio da rede de telecomunicações).
Fazer com que a estrutura do banco de dados reflita a estrutura da empresa é 
provavelmente a principal vantagem dos sistemas distribuídos.
20
CAPítulo 3 
funções adicionais do banco de dados 
distribuído
A distribuição leva a uma maior complexidade no projeto e na implementação do sistema. Para 
obter as vantagens potenciais listadas no tópico anterior, o software do SGBDD deve ser capaz de 
prover as seguintes funções, além daquelas de um SGBD centralizado:
 » Rastreamento de dados – habilidade para rastrear a distribuição, a fragmentação e 
a replicação dos dados por meio da ampliação do catálogo do SGBDD.
 » Processamento de consultas distribuídas – habilidade para acessar sites remotos 
e transmitir consultas e dados entre os vários sites por meio de uma rede de 
comunicação.
 » Gerenciamento de transações distribuídas – habilidade para conceber estratégias 
de execução para consultas e transações que acessam dados de mais de um site, 
e para sincronizar o acesso aos dados distribuídos e para manter a integridade do 
banco de dados global.
 » Gerenciamento dos dados replicados – habilidade para decidir qual a cópia de um 
item de dados replicado será acessada e para manter a consistência das cópias de 
um item de dados replicado.
 » Recuperação de banco de dados distribuído – habilidade para recuperar a partir de 
falhas em um site individual e a partir de novos tipos de falhas como a queda e dos 
links de comunicação.
 » Segurança – as transações distribuídas devem ser executadas com o gerenciamento 
adequado da segurança dos dados e dos privilégios de autorização/acesso dos 
usuários.
 » Gerenciamento do diretório (catálogo) distribuído – um diretório contém 
informações (metadados) sobre os dados no banco de dados. O diretório pode ser 
global para o BDD inteiro ou local para cada site. O posicionamento e a distribuição 
do diretório são questões de projeto e de política.
Essas funções por si só aumentam a complexidade de um SGBDD em relação a um SGBD centralizado. 
Antes que possamos perceber completamente as vantagens potenciais da distribuição, precisamos 
encontrar soluções satisfatórias para essas questões e para esses problemas de projeto. A inclusão 
de toda essa funcionalidade adicional é difícil de ser obtida, e encontrar soluções ótimas é um passo 
mais avançado.
21
Introdução a Banco de dados dIstrIBuídos│ unIdade I
No nível físico de hardware, os seguintes fatores principais distinguem um SGBDD de um sistema 
centralizado:
a. existem múltiplos computadores, chamados sites ou nós;
b. esses sites devem ser conectados por algum tipo de rede de comunicação para 
transmitir dados e comandos entre sites.
Os sites podem estar todos localizados fisicamente próximos, dentro do mesmo prédio ou do grupo de 
prédios adjacentes e conectados por uma rede local – LAN, ou eles podem ser distribuídos geograficamente 
por grandes distâncias e conectados por uma rede de enlace longo ou por uma rede remota – WAN. As 
redes locais geralmente utilizam cabos, ao passo que as redes de enlace longo utilizam linhas telefônicas 
ou satélites. Também é possível usar uma combinação dos dois tipos de redes.
As redes podem ter topologias diferentes que definem caminhos de comunicação direta entre os 
sites.O tipo e a topologia de rede utilizados podem ter um efeito significativo no desempenho e, 
consequentemente, nas estratégias para o processamento de consultas distribuídas e para o projeto 
de banco de dados distribuído. Entretanto, para as questões arquitetônicas de alto nível, não 
importa o tipo de rede utilizado. Apenas é relevante que cada site seja capaz de se comunicar, direta 
ou indiretamente, com todos os outros sites.
22
unidAdE ii
PrinCíPio dE 
BAnCo dE dAdoS 
diStriBuídoS
CAPítulo 1 
fundamentos do banco de dados 
distribuídos
Em um sistema distribuído, usuários devem comportar-se exatamente como se o sistema não fosse 
distribuído. Todos os problemas dos sistemas distribuídos são, ou deveriam ser, problemas internos 
ou do nível de implementação; não, problemas externos ou do nível do usuário.
O termo usuários no parágrafo anterior refere-se especificamente a usuários finais 
ou programadores de aplicações que estão executando operações de manipulação 
de dados.
As operações de definição de dados exigirão alguma extensão em um sistema distribuído, por 
exemplo, para que um usuário (talvez o DBA) no site A possa especificar que determinada RelVar 
deve ser dividida em “fragmentos”que serão armazenados nos sites B e C.
O fundamento de BDD conduz doze regras, conforme a seguir:
1. Autonomia local.
2. Não dependência de um site central.
3. Operação contínua.
4. Independência de localização.
5. Independência de fragmentação.
6. Independência de replicação.
7. Processamento de consultas distribuído.
8. Gerenciamento de transações distribuído.
9. Independência do hardware.
23
PrincíPio de Banco de dados distriBuídos│ unidade ii
10. Independência do sistema operacional.
11. Independência da rede.
12. Independência do SGDB.
Entenda que essas regras não são todas independentes umas das outras nem são necessariamente 
completas nem igualmente significativas (usuários diferentes darão graus diferentes de importância 
a objetivos diferentes em ambientes diferentes; na verdade, alguns delas podem ser totalmente 
não aplicáveis em algumas situações). Contudo, as regras são úteis como base para a compreensão 
da tecnologia distribuída e como uma estrutura para caracterizar a funcionalidade de sistemas 
distribuídos específicos. 
É importante distinguir sistemas de bancos de dados distribuídos verdadeiros, generalizados, dos 
sistemas que apenas fornecem alguma espécie de acesso a dados remotos (é tudo o que os sistemas 
cliente/servidor realmente fazem). Em um sistema de acesso a dados remotos, o usuário pode ser 
capaz de operar sobre dados em um site remoto ou mesmo sobre dados em vários sites remotos 
simultaneamente, mas “as emendas aparecem”, ou seja, o usuário está definitivamente ciente, em 
maior ou menor grau, de que os dados são remotos e precisa se comportar de acordo com esse 
fato. Ao contrário, em um verdadeiro sistema de banco de dados distribuídos, as emendas ficam 
escondidas. 
As 12 regras
Autonomia
Os sites, em um sistema distribuído, devem ser autônomos. Autonomia local significa que todas 
as operações em determinado site são controladas por ele mesmo; nenhum site A deve depender 
de algum outro site B para sua operação ser bem-sucedida (de outra forma, o fato de que o site C 
esteja inativo poderia significar que o site A não poderia funcionar, mesmo que não houvesse nada 
de errado como o próprio site A, o que evidentemente seria indesejável). A autonomia local também 
implica que dados locais são de propriedade e gerenciamento locais, com contabilidade local; todos 
os dados “realmente” pertencem a algum banco de dados local, mesmo que sejam acessíveis a partir 
de outros sites. Assim, questões como segurança, integridade e representação de armazenamento 
físico de dados locais permanecem sob o controle e a jurisdição do site local.
Na verdade, a regra de autonomia local não é completamente realizável; há várias situações em que 
um determinado site A precisa ceder um certo grau de controle a algum outro site B. O objetivo 
de autonomia , então, seria mais precisamente enunciado como: os sites devem ser autônomos na 
maior extensão possível. 
não dependência de um site central
Autonomia local implica que todos os sites devem ser tratados como iguais. Em particular, portanto, 
não haverá qualquer dependência de um site “mestre” central que forneça algum serviço central. 
24
UNIDADE II │PrINcíPIo DE BANco DE DADos DIstrIBUíDos
Por exemplo: serviços centralizados de processamento de consultas, gerenciamento de transações 
ou nomeações tais que o sistema inteiro dependa desse site central. Desse modo, essa segunda regra 
é uma continuação da primeira regra (se a primeira regra for realizada, a segunda virá logo em 
seguida). Porém, a “não dependência de um site central” é desejável por si, mesmo que não seja 
alcançada a completa autonomia local, motivo pelo qual a enunciamos como uma regra separada.
A dependência de um site central seria indesejável pelo menos por estas duas razões: primeiro, esse 
site central poderia ser um gargalo; segundo, e mais importante, o sistema seria vulnerável se o site 
central caísse, todo o sistema cairia (o problema do único ponto de falha).
operação contínua
Uma vantagem dos sistemas distribuídos em geral é que eles devem fornecer maior confiabilidade 
e maior disponibilidade.
Assim como foi explicitado no item Vantagens, referenciado no Capítulo 2, a 
confiabilidade e a disponibilidade são questões preliminares (funções Adicionais 
de BDD) e tratadas como gerência, mas também são regras claras e precisas para a 
utilização de BDD.
 » Confiabilidade é a probabilidade de o sistema funcionar sem queda em qualquer 
momento dado. A confiabilidade é melhor nos sistemas distribuídos porque esses 
sistemas não seguem a proposta de tudo ou nada. Eles podem continuar a funcionar 
(em nível reduzido) mesmo diante da falha de algum componente individual, 
como um site isolade é a probabilidade de o sistema estar pronto e funcionando 
continuamente sem queda durante um período especificado. Assim como a 
confiabilidade, a disponibilidade é melhor em um sistema distribuído, em parte 
pela mesma razão, em parte devido à possibilidade de replicação de dados.
As discussões anteriores se aplicam ao caso em que uma parada não planejada (isto é, uma falha 
de algum tipo) ocorreu em algum momento no sistema. As paradas não planejadas são obviamente 
indesejáveis, mas difíceis de evitar inteiramente. Ao contrário, as paradas planejadas nunca devem 
ser necessárias; isto é, nunca deve ser preciso desligar o sistema para a execução de alguma tarefa, 
como adicionar um novo site ou atualizar o SGBD em um site existente para uma nova versão.
Sem dúvida, você já deve ter percebido que a independência de localização é 
somente uma extensão do conceito familiar de independência (física) de dados.
25
PrincíPio de Banco de dados distriBuídos│ unidade ii
independência de localização
A idéia básica da independência de localização (também chamada transparência de localização) é 
simples: os usuários não devem ser obrigados a saber onde estão fisicamente armazenados os dados, 
mas devem ser capazes de se comportar pelo menos de um ponto de vista lógico como se os dados 
estivessem todos armazenados em seu próprio site local. A independência de localização é desejável 
porque simplifica os programas de aplicações e as atividades do usuário final; em particular, permite 
que dados migrem de um site para outro sem invalidar qualquer desses programas ou atividades. 
Essa capacidade de migração é desejável porque permite que dados sejam deslocados pela rede em 
resposta a alterações de exigências de desempenho.
independência de fragmentação
Um sistema admite fragmentação de dados se determinada Relação Variável armazenada pode ser 
dividida em pedaços ou fragmentos para fins de armazenamento físico, e os fragmentos distintos 
podem ser armazenados em sites diferentes. A fragmentação é desejável por motivos de desempenho:os dados podem ser armazenados no local em que são utilizados mais frequentemente, de modo 
que a maior parte das operações seja apenas local, e o tráfego da rede seja reduzido. Por exemplo: 
considere o RelVar EMP (“empregados”), com a amostra de valores apresentada na parte superior 
da Figura 5. Em um sistema que admitisse a fragmentação, poderíamos definir dois fragmentos:
FRAGMENT EMP AS
S_EMP AT SITE ‘SÃO PAULO’ WHERE DEPTO# = ‘D1’
OR
DEPTO# = ‘D3’,
R_EMP AT SITE ‘RIO DE JANEIRO’ WHERE DEPTO# = ‘D2’;
Figura 5 – um exemplo de fragmentação
26
UNIDADE II │PrINcíPIo DE BANco DE DADos DIstrIBUíDos
Vimos que existem duas espécies de fragmentação, horizontal e vertical, correspondentes às 
operações relacionais de restrição e projeção, respectivamente. (A Figura 5 ilustra uma fragmentação 
horizontal).
Suponha que tuplas EMP são mapeadas no armazenamento físico de modo bastante 
direto, e que D1 e D3 são departamentos de São Paulo, e D2 é um departamento do 
Rio de Janeiro. Tuplas para empregados em São Paulo serão armazenadas no site de 
São Paulo, e tuplas para empregados no Rio de Janeiro serão armazenadas no site do 
Rio de Janeiro. Observe na Figura 5 os nomes dos fragmentos internos do sistema, 
S_EMP e R_EMP.
A reconstrução da RelVar básica original a partir dos fragmentos é feita através de operações de 
junção e união adequadas (junção para fragmentos verticais, união para fragmentos horizontais). 
A propósito, no caso de união, observe que a eliminação de duplicatas não será necessária, graças à 
primeira das duas regras anteriores, ou seja, a união será uma união disjunta.
 Se realmente quisermos armazenar o mesmo fragmento de informações em vários 
lugares diferentes, poderemos fazê-lo por meio do mecanismo de replicação do 
sistema, a fim de obter o efeito desejado.
Devemos nos aprofundar mais um pouco sobre a questão de fragmentação vertical. Visto que tal 
fragmentação deve ser realizada sem perdas, fica claro que a fragmentação da RelVar EMP da Figura 
5 em suas projeções sobre, digamos, {EMP#,DEPTO#} e {SALÁRIO} não seria válida. Contudo, em 
alguns sistemas, RelVars armazenadas são consideradas como tendo uma “ID de tupla”, ou atributo 
TID oculto, fornecido pelo sistema, onde a TID para determinada tupla armazenada é, em linhas 
gerais, o endereço da tupla em questão. Esse atributo TID é claramente uma chave candidata para 
a RelVar em questão. Assim, por exemplo, se a RelVar EMP incluísse tal atributo, ela poderia ser 
fragmentada de modo válido em suas projeções sobre {TID,EMP#,DEPTO#} e {TID,SALÁRIO}, 
pois essa fragmentação, sem dúvida, seria sem perdas. Observe ainda que o fato de os atributos 
TID serem ocultos não viola o Princípio da Informação, pois a independência de fragmentação, 
que discutiremos em seguida, significa que o usuário, de qualquer forma, não está ciente da 
fragmentação.
A propósito, observe que a facilidade de fragmentação e a facilidade de reconstrução são duas das 
muitas razões pelas quais os sistemas distribuídos são relacionais; o modelo relacional fornece 
exatamente as operações necessárias para essa tarefa.
Agora, chegamos ao ponto mais importante: um sistema que admita fragmentação de dados 
também deve admitir independência de fragmentação (também conhecida como transparência de 
fragmentação). Isto é, os usuários devem ser capazes de se comportar, pelo menos de um ponto 
de vista lógico, como se os dados na verdade não estivessem fragmentados de modo algum. A 
independência de fragmentação (como a independência de localização) é desejável porque simplifica 
programas do usuário e atividades de terminal. Em particular, ela permite que os dados sejam 
refragmentados a qualquer momento, e os fragmentos sejam redistribuídos a qualquer momento 
27
PrincíPio de Banco de dados distriBuídos│ unidade ii
em resposta a mudanças nas exigências de desempenho, sem invalidar quaisquer desses programas 
ou atividades do usuário.
A independência de fragmentação implica que será apresentada aos usuários uma visão dos dados 
na qual os fragmentos estão combinados logicamente por meio de junções e uniões adequadas. É 
responsabilidade do otimizador determinar a quais fragmentos é necessário ter acesso físico para 
satisfazer a qualquer requisição do usuário. Por exemplo, dada a fragmentação mostrada na Figura 
5, se o usuário emitir a requisição:
EMP WHERE SALÁRIO > 40K AND DEPTO# = ‘D1’
O otimizador saberá, pelas definições do fragmento que estarão armazenadas no catálogo que o 
resultado inteiro pode ser obtido no site de São Paulo. Não haverá necessidade alguma de acessar o 
site do Rio de Janeiro.
Examinaremos esse exemplo com um pouco mais de detalhe. Em primeiro lugar, a RelVar EMP, tal 
como é percebida pelo usuário, pode ser considerada (informalmente) uma visão dos fragmentos 
básicos S_EMP e R_EMP:
VAR EMP “VIEW” /*pseudocódigo*/
S_EMP UNION R_EMP;
Assim, o otimizador transforma a requisição original do usuário na seguinte:
(S_EMP UNION R_EMP) WHERE SALÁRIO >40, 
 AND DEPTO# = DEPTO# (‘D1’)
Essa expressão pode ainda ser transformada em:
(S_EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO (‘D1’))
UNION
(R_EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO (‘D1’))
(porque a restrição é distributiva em relação à união). Em seguida, a partir da definição do 
fragmento R_EMP no catálogo, o otimizador sabe que o segundo desses dois operandos de UNION 
é equivalente a:
EMP WHERE SALÁRIO > 40K AND
 DEPTO# = DEPTO# (‘D1’) AND DEPTO# DEPTO# (‘D2’)
Essa expressão deverá ser avaliada como uma relação vazia, pois a condição na cláusula WHERE 
nunca poderá ter o valor TRUE. A consulta original pode então ser simplificada para apenas:
R_EMP WHERE SALÁRIO > 40K AND DEPTO# = DEPTO (‘D1’)
28
UNIDADE II │PrINcíPIo DE BANco DE DADos DIstrIBUíDos
Agora, o otimizador sabe que só precisa ter acesso ao site de São Paulo.
Considere o que significa para o otimizador lidar com a requisição:
EMP WHERE SALÁRIO > 40K
independência de replicação
Um sistema admite replicação de dados se determinada RelVar básica, ou, mais geralmente, 
determinado fragmento de determinada RelVar básica pode ser representada por muitas cópias ou 
réplicas distintas, armazenadas em muitos sites distintos. Por exemplo:
REPLICATE S EMP AS
 SR_EMP AT SITE ‘SÃO PAULO’;
REPLICATE R EMP AS
 RS_EMP AT SITE ‘RIO DE JANEIRO’;
Veja a Figura 6. Observe os nomes internos de réplicas do sistema, SR_EMP e RS_EMP.
Figura 6 – um exemplo de replicação
A replicação é desejável por ao menos dois motivos. Primeiro, pode significar melhor desempenho 
(aplicações podem operar sobre cópias locais, em vez de terem de se comunicar com site remotos); 
segundo, também pode significar melhor disponibilidade (algum objeto replicado permanece 
disponível para processamento pelo menos para acesso, enquanto houver no mínimo uma cópia 
disponível). Naturalmente, a maior desvantagem da replicação é que, quando determinado objeto 
replicado é atualizado, todas as cópias desse objeto precisam ser atualizadas: o problema da 
propagação de atualizações.
29
PrincíPio de Banco de dados distriBuídos│ unidade ii
 Exercício de esclarecimento. Qual é a diferença de independência de fragmentação 
e independência de replicação? Dê exemplos nos dois casos.
Observamos de passagem que a replicação em um sistema distribuído representa uma aplicação 
específica da ideia de redundância controlada.
A replicação, como a fragmentação, deve no caso ideal ser “transparente para o usuário”. Em 
outras palavras, um sistema que admita replicação de dados também deve admitir independência 
de replicação (também conhecida como transparência de replicação), isto é, os usuários devem 
ser capazes de se comportar, pelo menos de um ponto de vista lógico, como se os dados de fato 
não fossem replicados de modo algum. A independência de replicação (como a independência 
de localização ou de fragmentação) é desejável porque simplifica os programas deaplicações e as 
atividades do usuário final; em particular, ela permite que réplicas sejam criadas ou destruídas 
em qualquer momento, em resposta a mudanças de requisitos, sem invalidar quaisquer um desses 
programas ou atividades.
A independência de replicação implica a responsabilidade do otimizador do sistema de determinar 
a quais réplicas é necessário atribuir acesso físico para satisfazer qualquer requisição de um 
determinado usuário. Omitimos aqui os detalhes específicos da questão.
Muitos produtos comerciais atuais admitem uma forma de replicação que não inclui a independência 
de replicação total, ou seja, ela não é totalmente “transparente para o usuário”.
Processamento de consultas distribuído
Há dois aspectos gerais a serem analisados:
I. Considere a consulta “Obter fornecedores em São Paulo de peças vermelhas”. Suponha 
que o usuário esteja no site do Rio de Janeiro e que os dados estejam armazenados 
no site de São Paulo. Suponha também que existem “n” fornecedores que satisfazem 
à requisição. Se o sistema for relacional, a consulta envolverá basicamente duas 
mensagens: uma para enviar a requisição de São Paulo para o Rio de Janeiro e outra 
para retornar o conjunto de resultados de “n” tuplas do Rio de Janeiro para São 
Paulo. Se, por outro lado, o sistema não for relacional, mas sim um sistema de um 
registro por vez, a consulta envolverá basicamente “2n” mensagens: “n” de São Paulo 
para o Rio de Janeiro solicitando o “próximo” fornecedor, e “n” do Rio de Janeiro 
para São Paulo, a fim de retornar “o próximo” fornecedor. Assim, o exemplo ilustra 
o fato de que o sistema distribuído relacional provavelmente irá superar um sistema 
não relacional em desempenho, possivelmente por várias ordens de grandeza.
II. A otimização é ainda mais importante em um sistema distribuído do que em um 
sistema centralizado. O detalhe é que, em uma consulta como a mencionada no 
item I, envolvendo diversos sites, haverá muitos modos possíveis de mover os 
30
UNIDADE II │PrINcíPIo DE BANco DE DADos DIstrIBUíDos
dados pelo sistema de maneira a satisfazer à requisição e é de importância crucial 
que se encontre uma estratégia eficiente. Por exemplo, uma requisição de união 
de uma relação ra armazenada no site A e uma relação “rb” armazenada no site 
B poderia ser executada movendo-se “rb“ para A ou movendo-se “ra” para B, ou 
ainda movendo-se ambas para um terceiro site C etc. Para resumir rapidamente o 
exemplo, são analisadas seis diferentes estratégias para processamento da consulta 
sob um certo conjunto de hipóteses plausíveis, e o tempo de resposta varia de um 
mínimo de um décimo de segundo a um máximo de aproximadamente seis horas. 
Portanto, a otimização é claramente crucial e esse fato, por sua vez, pode ser visto 
como mais uma razão pela qual os sistemas distribuídos são sempre relacionais 
(observando-se que as requisições relacionais podem ser otimizadas enquanto as 
requisições não relacionais não podem).
Analise, com calma, os itens I e II e explique a principal diferença entre eles.
gerenciamento de transações distribuído
Existem dois aspectos principais do gerenciamento de transações: recuperação e concorrência. 
Cada um deles exige um extenso tratamento no ambiente distribuído. Para explicar esse extenso 
tratamento, é preciso antes introduzir um novo termo, agente. Em um sistema distribuído, uma 
única transação pode envolver a execução de código de vários sites; em particular, pode envolver 
atualizações em muitos sites. Dizemos então que cada transação consiste em vários agentes, em 
que um agente é o processo executado em favor de determinada transação em um site específico. 
E o sistema precisa saber quando dois agentes são ambos da mesma transação. Por exemplo: dois 
agentes que fazem parte da mesma transação obviamente não podem ter um impasse (deadlock) 
entre eles.
Passando agora especificamente à recuperação: para garantir que determinada transação é atômica 
(tudo ou nada) no ambiente distribuído, o sistema deve, portanto, assegurar que o conjunto de 
agentes para essa transação tenha feito o commit em uníssono ou o roll back em uníssono. Esse 
efeito pode ser obtido por meio de protocolo de COMMIT em duas fases.
31
PrincíPio de Banco de dados distriBuídos│ unidade ii
independência do hardware
Na verdade, não há muito a dizer sobre esse assunto, pois o título já diz tudo. Instalações de 
computadores do mundo real, em geral, envolvem uma multiplicidade de máquinas diferentes, 
(máquinas IBM, máquinas Fujitsu, máquinas HP, PCs e estações de trabalho de várias espécie). E 
existe uma necessidade real de ser capaz de integrar os dados em todos esses sistemas e apresentar 
ao usuário uma “imagem de um único sistema”. Assim, é desejável poder executar o mesmo 
SGBD em diferentes plataformas de hardware e, ainda mais, ter todas essas máquinas diferentes 
participando como parcerias em um sistema distribuído.
independência do sistema operacional
Esse objetivo é, em parte, uma sequência do item anterior e também não exige muita discussão aqui. 
Obviamente, é desejável não apenas poder executar o mesmo SGBD em diferentes plataformas de 
hardware, mas também poder executá-lo em diferentes plataformas de sistemas operacionais, 
inclusive sistemas operacionais distintos no mesmo hardware. Por exemplo: fazer uma versão 
OS/390, uma versão UNIX e uma versão Windows participarem todas do mesmo sistema distribuído.
independência da rede
Mais uma vez, não há muito a dizer. Se o sistema deve ser capaz de admitir muitos sites diferentes, 
com diferentes tipos de hardware e sistemas operacionais distintos, é evidente que ele precise 
admitir diversas redes de telecomunicações distintas.
independência do SgBd
Consideramos o que está envolvido na ação de relaxar a hipótese de homogeneidade estrita. Podemos 
afirmar que essa hipótese é um pouco forte. É necessário apenas que as instâncias do SGBD em sites 
diferentes admitam todas a mesma interface, elas não precisam ser todas necessariamente cópias 
do mesmo software de SGBD.
32
unidAdE iii
ArquitEturA E 
ProjEto dE
BAnCo dE dAdoS 
diStriBuídoS
CAPítulo 1 
transações
Normalmente, uma coleção de várias operações sobre o banco de dados parece ser uma única 
entidade do ponto de vista do usuário do banco de dados. Por exemplo: uma transferência de fundos 
de uma conta corrente para uma conta poupança é uma única operação do ponto de vista do cliente, 
contudo, dentro do sistema de banco de dados, ela consiste em várias operações. Logicamente, é 
essencial que todas essas operações ocorram ou que, no caso de uma falha, nenhuma delas ocorra. 
Seria inaceitável se a conta corrente fosse debitada, mas a conta poupança não fosse creditada.
Coleções de operações que formam uma única unidade lógica de trabalho são chamadas 
transações. Um sistema de banco de dados precisa garantir a execução apropriada de transações 
apesar das falhas, ou a transação inteira é executada, ou nenhuma parte dela é executada. Além 
do mais, ele precisa gerenciar a execução simultânea de transações de modo a evitar a introdução 
da inconsistência. Em nosso exemplo de transferência de fundos, uma que calcula calculando o 
valor total do cliente poderia ver o saldo da conta corrente antes de ser debitado pela transação de 
transferência de fundos, mas ver o saldo da poupança depois de ser creditado. Como resultado, ela 
obteria um resultado incorreto.
Conceito de transação
Uma transação é uma unidade de execução do programa que acessa e possivelmente atualiza vários 
itens de dados. Normalmente, uma transação é iniciada por um programa do usuário escrito em 
uma linguagem de manipulação de dados ou linguagem de programação de alto nível, por exemplo, 
SQL, C++ ou Java, em que é delimitada pelas instruções (ou chamadas de função) na forma Begin 
transaction e end transaction. A transação consiste em todas as operações executadas entre o Begin 
transaction e o end transaction.
Para garantir a integridade dos dados, é necessário que osistema de banco de dados mantenha as 
seguintes propriedades das transações:
33
ArquiteturA e Projeto de BAnco de dAdos distriBuídos│ unidAde iii
a. Atomicidade – todas as operações da transação são refletidas corretamente no 
banco de dados, ou nenhuma delas.
b. Consistência – a execução de uma transação isolada, ou seja, sem qualquer outra 
transação executando simultaneamente, preserva a consistência do banco de dados.
c. Isolamento – embora várias transações possam ser executadas simultaneamente, o 
sistema garante que, para cada par de transações Ti e Tj, parece para Ti que ou Tj 
terminou a execução antes que Ti começasse, ou Tj iniciou a execução depois que Ti 
terminou. Assim, cada transação não está ciente das outras transações executando 
simultaneamente no sistema.
d. Durabilidade – depois que uma transação for completada com sucesso, as mudanças 
que ela fez ao banco de dados persistem, mesmo que existam falhas no sistema.
Essas propriedades normalmente são conhecidas como propriedades ACID; o 
acrônimo é derivado da primeira letra de cada uma das quatro propriedades.
Para entender melhor as propriedades ACID e a necessidade delas, considere um sistema bancário 
simplificado, consistindo em várias contas e um conjunto de transações que acessem e atualizem 
essas contas. Por enquanto, vamos supor que o banco de dados resida permanentemente no disco, 
mas que alguma parte dele esteja residindo temporariamente na memória principal.
As transações acessam dados usando duas operações:
I. read(X), que transfere o item de dados X do banco de dados para um buffer local 
pertencente à transação que executou a operação read;
II. write(X), que transfere o item de dados X do buffer local da transação que executou 
o write de volta ao banco de dados.
Em um sistema de banco de dados real, a operação write não necessariamente resulta na atualização 
imediata dos dados no disco; a operação write pode ser armazenada temporariamente na memória 
e executada no disco mais tarde. Por enquanto, porém, vamos supor que a operação write atualize 
o banco de dados imediatamente. 
Suponha que Ti$ seja uma transação que transfere $50 da conta A para a conta B. Essa transação 
pode ser definida como:
TI : read(A);
 A := A – 50;
 Write(A);
 Read(b);
 B := B + 50;
 Write(B).
34
UNIDADE III │ArqUItEtUrA E ProjEto DE BANco DE DADos DIstrIBUíDos
Agora, vamos considerar cada uma das propriedades ACID. (Para facilitar a apresentação, 
consideramos as propriedades em uma ordem diferente da ordem A-C-I-D).
 » Consistência: o requisito de consistência aqui é que a soma de A e B seja inalterada 
pela execução da transação. Sem o requisito de consistência, o dinheiro poderia ser 
criado ou destruído pela transação. Podemos verificar facilmente que, se o banco 
de dados estiver consistente antes de uma execução da transação, ele permanecerá 
consistente após a execução da transação.
Garantir a consistência para uma transação individual é responsabilidade do 
programador de aplicação que codifica a transação.
 » Atomicidade: suponha que, imediatamente antes da execução da transação Ti, os 
valores das contas A e B sejam $1.000 e $2.000, respectivamente. Agora suponha 
que, durante a execução da transação Ti, aconteça uma falha que impede Ti de 
completar sua execução com sucesso. Os exemplos dessas falhas incluem falta de 
energia, falha de hardware e erros de software. Além disso suponha que a falha 
aconteceu depois da operação write(A), mas antes da operação write(B). Nesse 
caso, os valores das contas A e B refletidos no banco de dados são $950 e $2000. 
O sistema destruiu $50 como resultado dessa falha. Em particular, notamos que a 
soma A + B não é mais preservada.
Assim, devido à falha, o estado do sistema não reflete mais um estado real do 
mundo que o banco de dados deveria capturar. Chamamos esse estado de estado 
inconsistente. Temos de garantir que essas inconsistências não sejam visíveis em 
um sistema de banco de dados. Observe, porém, que o sistema precisa, em algum 
ponto, estar em um estado inconsistente. Mesmo que a transação Ti seja executada 
até o término, existe um ponto em que o valor da conta A é $950 e o valor da conta 
B é $2.000, o que claramente é um estado inconsistente. Porém, esse estado por fim 
será substituído pelo estado consistente, em que o valor da conta A é $950 e o valor 
da conta B é $2.050. Assim, se a transação nunca foi iniciada ou foi completada com 
sucesso, esse estado inconsistente não seria visível, exceto durante a execução da 
transação, ou seja, o motivo para o requisito de atomicidade. Se a propriedade de 
atomicidade estiver presente, todas as transações são refletidas no banco de dados, 
ou nenhuma delas.
A ideia básica por trás da garantia da atomicidade é esta: o sistema de banco de 
dados acompanha (em disco) os valores antigos de quaisquer dados em que uma 
transação realiza uma escrita e, se a transação não completa sua execução, o 
sistema de banco de dados restaura os valores antigos para que apareçam como se 
a transação nunca tivesse sido executada.
 » Durabilidade: quando a execução da transação termina com sucesso, e o usuário 
que iniciou a transação foi notificado de que a transferência de fundos aconteceu, é 
preciso que nenhuma falha no sistema resulte em perda dos dados correspondentes 
a essa transferência de fundos.
35
ArquiteturA e Projeto de BAnco de dAdos distriBuídos│ unidAde iii
A propriedade de durabilidade garante que, quando uma transação é executada 
com sucesso, todas as atualizações que ela executou no banco de dados persistem, 
mesmo que haja uma falha no sistema após a transação terminar sua execução.
Consideramos por enquanto que uma falha do sistema de computador pode resultar 
na perda de dados na memória principal, mas os dados gravados em disco nunca 
são perdidos. Podemos conseguir a durabilidade garantindo que:
1. as atualizações executadas pela transação sejam gravadas em disco antes que a 
transação termine;
2. as informações sobre as atualizações executadas pela transação e gravadas em disco 
sejam suficientes para permitir que o banco de dados reconstrua as atualizações 
quando o sistema de banco de dados for reiniciado após a falha.
Garantir a durabilidade é responsabilidade de um componente de software do 
sistema de banco de dados, chamado componente de gerenciamento de recuperação. 
O componente de gerenciamento de transação e o componente de gerenciamento 
de recuperação estão bastante relacionados.
 » Isolamento: mesmo que as propriedades de consistência e atomicidade 
sejam garantidas para cada transação, se várias transações forem executadas 
simultaneamente, suas operações podem intercalar de alguma maneira indesejável, 
resultando em um estado inconsistente.
Por exemplo, como já vimos, o banco de dados está temporariamente inconsistente 
enquanto a transação para transferir fundos de A para B está executando, com o 
total deduzindo gravado em A e o total aumentado ainda a ser gravado em B. Se uma 
segunda transação executada simultaneamente lê A e B nesse ponto intermediário e 
calcula A + B, ela observará um valor inconsistente. Além do mais, se essa segunda 
transação realizar atualizações sobre A e B com base nos valores inconsistentes 
que ela lê, o banco de dados pode ser deixado em um estado inconsistente mesmo 
depois que as transações tenham terminado.
Um modo de evitar o problema de transações executada simultaneamente é executar transações de 
modo serial, ou seja, uma após outra. Porém, a execução simultânea de transações oferece benefícios 
de desempenho significativos. Portanto, outras soluções foram desenvolvidas; elas permitem que 
várias transações sejam executadas simultaneamente.
A propriedade de isolamento de uma transação garante que a execução simultânea das transações 
resulte em um estado do sistema equivalente ao estado que poderia ter sido obtido se essas transações 
fossem executadas uma de cada vez em alguma ordem. A garantiada propriedade de isolamento 
é responsabilidade de um componente do sistema de banco de dados chamado componente de 
controle de concorrência.
36
UNIDADE III │ArqUItEtUrA E ProjEto DE BANco DE DADos DIstrIBUíDos
Estado da transação
Na ausência de falhas, todas as transações são completadas com sucesso. Porém, como observamos 
anteriormente, uma transação nem sempre pode completar sua execução com sucesso. Essa transação 
é considerada abortada. Se tivermos de garantir a propriedade de atomicidade, uma transação 
abortada não pode ter efeito sobre o estado do banco de dados. Assim, quaisquer mudanças que a 
transação abortada fez no banco de dados precisam ser desfeitas. Quando as mudanças causadas 
por uma transação abortada tiverem sido desfeitas, dizemos que a transação foi revertida. É parte 
da responsabilidade do esquema de recuperação gerenciar transações revertidas.
Uma transação que completa sua execução com sucesso é considerada confirmada. Uma transação 
confirmada que realizou atualizações transforma o banco de dados em um novo estado consistente, 
que precisa persistir mesmo que haja uma falha no sistema.
Quando uma transação tiver sido confirmada, não podemos desfazer seus efeitos abortando-a. A 
única maneira de desfazer os efeitos de uma transação confirmada é executar uma transação de 
compensação. 
Precisamos ser mais precisos a respeito do que significa término bem-sucedido de uma transação. 
Portanto, vamos estabelecer um modelo abstrato simples de transação. Uma transação precisa estar 
em um dos seguintes estados:
 » ativa, o estado inicial, a transação permanece nesse estado enquanto está executando;
 » parcialmente confirmada, depois que a instrução final foi executada;
 » falha, depois da descoberta de que a execução normal não pode mais prosseguir;
 » abortada, depois que a transação foi revertida e o banco de dados foi restaurado ao 
seu estado anterior ao início da transação;
 » confirmada, após o término bem-sucedido.
O diagrama de estado corresponde a uma transação conforme, na Figura 7. Dizemos que uma 
transação foi confirmada somente se ela entrou no estado confirmado. De modo semelhante, 
dizemos que uma transação foi abortada somente se ela entrou no estado abortado. Uma transação 
é considerada como terminada se tiver sido confirmada ou abortada.
37
ArquiteturA e Projeto de BAnco de dAdos distriBuídos│ unidAde iii
Figura 7 – diagrama de estado de uma transação
parcialmente
confirmada
ativa
falha abortada
confirmada
Uma transação começa no estado ativo. Quando ela termina sua última instrução, entra no estado 
parcialmente confirmado. Nesse ponto, a transação completou sua execução, mas ainda pode ser 
abortada, pois a saída real ainda pode estar temporariamente residindo na memória principal, por 
isso uma falha de hardware pode impedir seu término bem-sucedido.
38
CAPítulo 2 
tipos de Sistemas Bdd
O termo sistema de gerenciamento de banco de dados distribuído pode descrever vários sistemas 
que diferem uns dos outros em muitos aspectos. A característica principal que todos os sistemas 
desse tipo possuem em comum é o fato de que os dados e o software são distribuídos por múltiplos 
sites conectados por alguma forma de rede de telecomunicações. 
O primeiro fator que consideramos é o grau de homogeneidade do software do SGBDD. Se todos 
os servidores, ou SGBDs locais individuais, usam um software idêntico e todos os usuários, 
clientes, usam um software idêntico, o SGBDD é chamado homogêneo; caso contrário, é chamado 
heterogêneo. Um outro fator relacionado ao grau de homogeneidade é o grau de autonomia local. Se 
não há nenhuma provisão para o site local funcionar como um SGBD stand-alone, então o sistema 
não possui autonomia local. Por outro lado, se for permitido o acesso direto ao servidor para as 
transações locais, o sistema possui algum grau de autonomia local.
Em um extremo do espectro de autonomia, temos um SGBDD que se parece com um SGBD 
centralizado para o usuário. Existe um único esquema conceitual, e todos os acessos ao sistema 
ocorrem por meio de um site, que é parte do SGBDD, o que significa que nenhuma autonomia local 
existe. No outro extremo, encontramos um tipo de SGDBB chamado federado (ou de sistema de 
multibases de dados). Nesse tipo de sistema, cada servidor é um SGBD centralizado independente 
e autônomo que tem seus próprios usuários locais, transações locais e DBA e, consequentemente, 
possui um grau muito alto de autonomia local. O termo sistema de banco de dados federado (SBDF) 
é usado quando existir alguma visão ou esquema global da federação de banco de dados que é 
compartilhada pelas aplicações. Por outro lado, um sistema de multibases de dados (multidatabase) 
não possui um esquema global e constrói interativamente um esquema, conforme a necessidade 
da aplicação. Ambos os sistemas são híbridos entre os sistemas distribuídos e centralizados, e a 
distinção que fizemos entre eles não é seguida estritamente. Faremos referências a eles como SBDFs 
em um sentido genérico.
Em um SBDF heterogêneo, um servidor pode ser um SGBD relacional; um outro, um SGBD de rede; 
e um terceiro SGBD orientado por objeto ou hierárquico. Em tal caso, é necessário possuir uma 
linguagem de sistema canônica e incluir tradutores da linguagem para traduzir as subconsultas da 
linguagem canônica para a linguagem de cada servidor. 
gerenciamento de SBdf
 » Diferenças nos modelos de dados: os bancos de dados em uma organização vêm 
de uma variedade de modelos de dados, inclusive dos, assim chamados, modelos 
legados (de rede e hierárquico), do modelo de dados relacional, do modelo de dados 
orientado por objeto, e até mesmo de arquivos. As capacidades de modelagem dos 
modelos variam. Consequentemente, lidar com eles de maneira uniforme por meio 
de um único esquema global ou processá-los em uma linguagem única é desafiante. 
Mesmo se dois bancos de dados forem ambos do ambiente de SGBDR, a mesma 
39
ArquiteturA e Projeto de BAnco de dAdos distriBuídos│ unidAde iii
informação poderia ser representada com diferentes nomes de atributo, nome 
de relação ou valores em diferentes bancos de dados. Isso exige um mecanismo 
inteligente de processamento de consultas que possa relacionar a informação 
baseando-se nos metadados.
 » Diferenças em restrições: as facilidades de restrições para a especificação e 
a implementação variam de sistema para sistema. Existem características 
comparáveis que devem ser reconciliadas na construção de um esquema global. Por 
exemplo, os relacionamentos dos modelos ER são representados como restrições de 
integridade referencial no modelo relacional. Gatilhos podem precisar ser usados 
para implementar certas restrições no modelo relacional. O esquema global também 
deve tratar dos conflitos potenciais entre as restrições.
 » Diferenças nas linguagens de consulta: Mesmo com o modelo de dados igual, as 
linguagens e suas versões variam. Por exemplo, o SQL possui múltiplas versões 
como o SQL-89, o SQL-92 e o SQL-99, e cada sistema possui seu próprio conjunto 
de tipos de dados, de operadores de comparação, de características de manipulação, 
de cadeias de caracteres etc.
diferenças no significado
As diferenças no significado ou heterogeneidade semântica ocorre quando existem diferenças na 
interpretação e na intenção de uso dos mesmos dados ou de dados relacionados. A heterogeneidade 
semântica entre sistemas de banco de dados (SBDs) componentes cria o maior obstáculo no projeto 
de esquemas globais de banco de dados heterogêneos. A autonomia de projeto de componentes de 
SBDs refere-se à sua liberdade de escolher os seguintes parâmetros de projeto, que, por sua vez, 
afetam a complexidade eventual do SBDF:
 » o universo de discurso a partir do qual os dados são retirados – por exemplo, duas 
contas de clientes, banco de dados na federação, podem ser do Brasil e do Japão com 
conjuntos de atributos completamente diferentes sobre contas de clientes necessárias 
para as atividadesde contabilidade. As flutuações da taxa de câmbio também 
apresentariam um problema. Consequentemente, as relações nesses dois bancos de 
dados que possuem nomes idênticos, CLIENTE ou CONTA, podem possuir algumas 
informações em comum e algumas informações completamente distintas;
 » representação e nomenclatura – a representação e a nomenclatura dos elementos 
de dados e a estrutura do modelo de dados podem ser pré-especificadas para cada 
banco de dados local;
 » a compreensão, significado e interpretação subjetiva dos dados – este é um 
contribuinte principal para a heterogeneidade semântica;
 » política de transações e de restrições – estas tratam do critério de serialização, da 
compensação de transações e de outras políticas de transações;
 » derivação de sumários – agregação, sumarização e outras características de 
processamento de dados e de operações que têm o suporte do sistema.
40
UNIDADE III │ArqUItEtUrA E ProjEto DE BANco DE DADos DIstrIBUíDos
A autonomia de comunicação de um SBD componente refere-se à sua habilidade em decidir se há 
comunicações com outro SBD componente. A autonomia de execução refere-se à habilidade de um 
SBD componente em executar operações locais sem a interferência de operações externas por outros 
SBDs componentes e à sua habilidade em decidir se e quanto compartilhar de sua funcionalidade 
(as operações que ele fornece suporte) e de seus recursos (dados que ele gerencia) com outros SBDs 
componentes. O desafio principal do projeto de SBDFs é fazer os SBDs componentes interoperarem 
enquanto ainda lhes são proporcionados os tipos de autonomia acima.
Uma típica arquitetura de esquema e cinco níveis para fornecer suporte a aplicações globais no 
ambiente de SBDF são mostradas na Figura 8. Nessa arquitetura, o esquema local é o esquema 
conceitual (definição completa de banco de dados) de um banco de dados componente, e o esquema 
do componente é derivado por meio da tradução do esquema local em um modelo de dados canônico 
ou em um modelo comum de dados (CDM – Common Data Model) para o SBDF. A tradução do 
esquema a partir do esquema local para o esquema do componente é acompanhada pela geração de 
mapeamentos para transformar os comandos, em um esquema de componente, em comandos no 
esquema local correspondente.
Figura 8 – arquitetura de esquema de cinco níveis em um sistema de banco de dados (sBdF)
Fonte: adaptado de sheth e larson, Federated database systems for managing distribuited Heterogeneous autonomous 
databases. acm computing surveys. v. 22, n. 3, setembro de 1990.
O esquema de exportação representa o subconjunto de um esquema de componente que está 
disponível para o SBDF. O esquema federado é o esquema ou visão global, resultado da integração 
de todos os esquemas de exportação compartilháveis. O esquema externo define o esquema para um 
grupo de usuários ou para uma aplicação como na arquitetura de esquema de três níveis.
Para uma discussão detalhada das autonomias e da arquitetura de cinco níveis dos 
SGBDFs, consulte Sheth e Larson (1990).
41
CAPítulo 3 
Problemas de sistemas distribuídos
Vamos aprofundar um pouco a discussão sobre alguns dos problemas mencionados anteriormente. 
O problema principal é que as redes de telecomunicações, pelo menos as redes remotas – WANs, 
são lentas. Uma WAN típica poderia ter uma taxa de dados efetiva de cerca de 5 mil a 10 mil bytes 
por segundo; ao contrário, uma unidade de disco típica tem uma taxa de dados de cerca de 5 a 
10 milhões de bytes por segundo. Por outro lado, algumas redes locais admitem taxas de dados 
da mesma ordem de grandeza que as unidades de discos. Deste modo, um objetivo essencial nos 
sistemas distribuídos (pelo menos no caso de WANs e, até certo ponto, também no caso de LANs) é 
minimizar a utilização da rede, isto é, minimizar o número e o volume de mensagens. Esse objetivo, 
por sua vez, gera problemas em várias outras áreas, entre elas as seguintes (esta lista não pretende 
ser completa):
 » Processamento de consultas.
 » Gerenciamento de catálogo.
 » Propagação de atualizações.
 » Recuperação.
 » Concorrência.
Processamento de consultas
O objetivo de minimizar a utilização da rede implica que o próprio processo de otimização de 
consultas precisa ser distribuído, como também o processo de execução de consultas. Em outras 
palavras, o processo geral de otimização consistirá normalmente em uma etapa de otimização 
global, seguida por etapas de otimização global, seguida por etapas de otimização local em cada site 
afetado. Por exemplo, suponha que uma consulta Q seja apresentada no site X, e suponha que Q 
envolva uma junção de uma relação ry de 10 tuplas no site Y com uma relação rz de 10 milhões de 
tuplas no site Z. O otimizador do site X escolherá a estratégia global para executar Q; e logicamente 
é desejável que ele decida mover ry para Z, e não rz para Y (ou, dependendo da cardinalidade do 
resultado da junção, poderia ser melhor mover ry e rz para X). Suponha que ele decida mover ry 
para Z. Em seguida, a estratégia para executar a junção real no site Z será decidida pelo otimizador 
local em Z. 
Apresentamos, a seguir, uma ilustração mais detalhada do que foi dito.
 » Banco de dados (Fornecedores e peças, simplificado):
F {F#, CIDADE } 10.000 tuplas armazenadas no site A
42
UNIDADE III │ArqUItEtUrA E ProjEto DE BANco DE DADos DIstrIBUíDos
P {P#, COR } 100.000 tuplas armazenadas no site B
FP {F#, P# } 1.000.000 tuplas armazenadas no site A
Suponha que toda tupla armazenada tenha 25 bytes (200 bits) de extensão.
 » Consulta (“Obter números de fornecedores para fornecedores em Londres de peças 
vermelhas”):
( ( F JOIN FP JOIN P ) WHERE CIDADE = ‘Londres’ AND
 COR = COR (‘Vermelho’) ) { F#}
 » Cardinalidade estimadas de certos resultados intermediários:
Número de peças vermelhas = 10
Número de remessas por fornecedores de Londres = 100.000
 » Hipóteses de comunicações:
Taxa de dados = 50.000 bits por segundo
Retardo de acesso = 0,1 segundo
Examinamos agora rapidamente seis estratégias possíveis para processar essa consulta, e para cada 
estratégia i calculamos o tempo de comunicação total Ti a partir da fórmula:
( retardo de acesso total ) + ( volume de dados total / taxa de dados )
Que se torna (em segundos):
( número de mensagens / 10 ) + ( numero de bits / 50000)
1. Mover peças para o site A e processar a consulta em A.
T1 = 0,1 + ( 100000 * 200 ) / 50000
 = 400 segundos aprox. (6,67 minutos)
2. Mover fornecedores e remessas para o site B e processar a consulta em B:
T2 = 0,2 + ( ( 10000 + 1000000 ) * 200 ) / 50000
 = 400 segundos aprox. (1.12 horas)
3. Fazer a junção de fornecedores e remessas no site A, restringir o resultado a 
fornecedores de Londres e, em seguida, para cada um desses fornecedores, verificar 
no site B se a peça correspondente é vermelha. Cada uma dessas verificações 
43
ArquiteturA e Projeto de BAnco de dAdos distriBuídos│ unidAde iii
envolverá duas mensagens, uma consulta e uma resposta. O tempo de transmissão 
para essas mensagens será pequeno comparado com o retardo de acesso.
T3 = 20000 segundos aprox. (5,56 horas)
4. Restringir peças no site B às que são vermelhas, e depois, para cada uma dessas 
peças, verificar no site A se existe uma remessa relacionando a peça a um fornecedor 
de Londres. Cada uma dessas verificações envolverá duas mensagens; novamente, 
o tempo de transmissão para essas mensagens será pequeno comparado com o 
retardo de acesso.
T4 = 2 segundos aprox.
5. Fazer a junção de fornecedores e remessas no site A, restringir o resultado a 
fornecedores em Londres, projetar o resultado sobre F# e P# e mover o resultado 
para o site B. Completar o processamento no site B.
T5 = 0,1 + ( 100000 * 200 ) / 50000
 = 400 segundos aprox. (6.67 minutos)
6. Restringir peças no site B às que são vermelhas e mover o resultado para o site A. 
Completar o processamento no site A.
Algumas estratégias permitemprocessamento paralelo nos dois sites; assim, o 
tempo de resposta para o usuário poderia na verdade ser menor que em um sistema 
centralizado. Porém, observe que ignoramos a questão de qual site deve receber o 
resultado final.
gerenciamento de catálogo
Em um sistema distribuído, o catálogo do sistema incluirá não apenas os dados normais de catálogo 
relativos a RelVars básicas, visões, restrições de integridade, autorização etc., mas também todas as 
informações de controle necessárias para permitir que o sistema forneça a desejada independência 
de local, fragmentação e replicação. Surge a questão: onde e como deve ser armazenado o próprio 
catálogo? Algumas possibilidades são:
1. centralizado – o catálogo inteiro é armazenado exatamente uma vez, em um único 
site central;
2. totalmente replicado – o catálogo inteiro é armazenado por completo em cada site;
3. particionado – cada site mantém seu próprio catálogo para objetos armazenados 
nesse site. O catálogo total é a união de todos esses catálogos locais disjuntos;
44
UNIDADE III │ArqUItEtUrA E ProjEto DE BANco DE DADos DIstrIBUíDos
4. combinação das abordagens 1 e 3 – cada site mantém seu próprio catálogo local, 
como no item 3; além disso, um único site central mantém uma cópia unificada de 
todos esses catálogos locais, como no item 1.
Cada uma dessas abordagens tem seus problemas. A abordagem 1 evidentemente viola o objetivo 
de “não dependência de um site central”. A abordagem 2 sofre de uma severa perda de autonomia, 
pois cada atualização de catálogo deve ser propagada para todos os sites. A abordagem 3 torna as 
operações não locais muito dispendiosas (a localização de um objeto remoto exigirá acesso à metade 
da quantidade de sites, em média). A abordagem 4 é mais eficiente que a abordagem 3 (a localização 
de um objeto remoto exige somente um acesso ao catálogo remoto), mas viola mais uma vez o 
objetivo de “não dependência de um site central”. Assim, na prática, os sistemas em geral não usam 
qualquer uma dessas quatro abordagens. A título de exemplo, descrevemos a abordagem utilizada 
em R*.
 R* (o “R estrela”) – O asterisco é o chamado operador de Kleene – “R*” significa “zero 
ou mais [System] R’s”.
Para explicar como é estruturado o catálogo do R*, primeiro é preciso dizer algo sobre a nomeação 
de objetos em R*. A nomeação de objetos é questão significativa para sistemas distribuídos em 
geral; a possibilidade de dois sites distintos X e Y conterem ambos um objeto, digamos, uma RelVar 
básica chamada R, implica que algum mecanismo normalmente, a qualificação pelo nome do site 
será necessário para “desfazer a ambiguidade”, isto é, garantir a unicidade de nomes no âmbito do 
sistema. No entanto, se nomes qualificados como X.R e Y.R forem expostos ao usuário, o objetivo 
de independência do local está claramente violado. Portanto, é necessário um meio de mapear os 
nomes conhecidos pelos usuários para seus nomes correspondentes, conhecidos pelo sistema.
Aqui está então a abordagem do R* para esse problema. Primeiro, R* faz distinção entre o nome 
impresso de um objeto, que é o nome pelo qual o objeto é normalmente referenciado pelos usuários, 
por exemplo, em uma instrução SELECT da SQL e seu nome para o sistema, que é um identificador 
interno globalmente exclusivo para o objeto. Os nomes para o sistema têm quatro componentes:
1. ID do criador (a ID do usuário que emitiu a operação CREATE, que criou o objeto 
em primeiro lugar);
2. ID do site do criador (a ID do site no qual a operação CREATE foi executada);
3. Nome local (o nome não qualificado do objeto);
4. ID do site de nascimento (a ID do site em que o objeto foi inicialmente armazenado).
As IDs de usuários são exclusivas dentro do site, e as IDs de sites são globalmente exclusivas. Assim, 
por exemplo, o nome para o sistema.
MARCOS @ BRASIL . STATS @ LONDRES
45
ArquiteturA e Projeto de BAnco de dAdos distriBuídos│ unidAde iii
Identifica um objeto para definir melhor; vamos considerá-lo como uma RelVar básica com o nome 
local STATS, criado pelo usuário chamado Marcos no site do Brasil e inicialmente armazenado no 
site de Londres. Esse nome tem a garantia de nunca mudar nem mesmo se o objeto migrar para 
outro site.
Um nome impresso consiste em um nome não qualificado simples, seja o componente “nome 
local” do nome para o sistema (STATS, no exemplo anterior), seja um sinônimo desse nome para o 
sistema, definido por meio da instrução especial CREATE SYNONYM do R*. Aqui está um exemplo:
CREATE SYNONYM MSTATS FOR MARCOS @ BRASIL . STATS @ LONDRES ;
Agora, o usuário pode especificar, por exemplo:
SELECT ... FROM STATS ...
ou
SELECT ... FROM MSTATS ...
No primeiro caso (usando o nome local), o sistema deduz o nome para o sistema assumindo todos 
os defaults óbvios, ou seja, que o objeto foi criado por este usuário, que ele foi criado neste site e que 
foi armazenado inicialmente neste site. A propósito, uma consequência dessas hipóteses default é 
que antigas aplicações do System R funcionarão sem alterações no R*, isto é, depois que os dados 
do System R forem redefinidos como dado do R*.
No segundo caso (usando o sinônimo), o sistema determina o nome para o sistema interrogado 
a tabela de sinônimos relevantes. As tabelas de sinônimos podem ser vistas como o primeiro 
componente do catálogo; cada site mantém um conjunto dessas tabelas para cada usuário conhecido 
nesse site, mapeando os sinônimos conhecidos por esse usuário nos nomes correspondentes para 
o sistema.
Além das tabelas de sinônimos, cada site mantém:
1. uma entrada de catálogo para cada objeto nascido nesse site;
2. uma entrada de catálogo para cada objeto armazenado atualmente nesse site.
Suponha agora que o usuário emita uma requisição referente ao sinônimo MSTATS. Primeiro, o 
sistema procura o nome para o sistema correspondente na tabela de sinônimos apropriada (uma 
pesquisa puramente local). Agora, ele sabe o site de nascimento, Londres, no exemplo interrogar 
o catálogo de Londres (o que vamos supor, para generalizar, ser uma pesquisa remota, de modo 
que esse é o primeiro acesso remoto). O catálogo de Londres conterá uma entrada para o objeto, 
em virtude de item 1 anterior. Se o objeto ainda estiver em Londres, ele será encontrado nesse 
momento. Contudo, se o objeto tiver migrado para o Japão (exemplo), então a entrada no catálogo 
em Londres informará esse fato, de modo que agora o sistema possa interrogar o catálogo do Japão 
(segundo acesso remoto). E o catálogo do Brasil conterá uma entrada para o objeto, em virtude do 
item 2 anterior. Assim, o objeto será encontrado com no máximo dois acessos remotos.
46
UNIDADE III │ArqUItEtUrA E ProjEto DE BANco DE DADos DIstrIBUíDos
Além disso, se o objeto migrar outra vez, digamos para a Austrália, então o sistema:
1. inserirá uma entrada de catálogo da Austrália;
2. eliminará a entrada no catálogo do Japão;
3. atualizará a entrada de catálogo de Londres para indicar Austrália em vez do Brasil.
O efeito final é que o objeto ainda poderá ser encontrado com no máximo dois acessos remotos. E 
esse é um esquema completamente distribuído, não existe um site de catálogo central e nenhum 
ponto único de falha dentro do sistema.
Saiba que o esquema de nomeação de objetos usados no recurso de dados 
distribuídos do DB2 é semelhante, mas não idêntico ao descrito.
Propagação de atualizações
O problema básico com a replicação de dados é que uma atualização de qualquer objeto lógico 
dado deve ser propaganda a todas as cópias armazenadas desse objeto. Surge imediatamente uma 
dificuldade, se algum site que tenha uma cópia do objeto não estiver disponível (devido a uma falha 
em um site ou na rede), no momento da atualização. A estratégia óbvia de propagar imediatamente 
as atualizações para todas as cópias poderia ser então inaceitável, porque implica que a atualização 
e, portanto, a transação falhará se qualquer uma dessas cópias não estiver disponível no momento. 
De replicação, minando assim uma das vantagensproclamadas para a replicação do item anterior. 
Um esquema comum para tratar do problema (não o único possível) é o chamado esquema de cópia 
primária, que funciona assim:
1. uma cópia de cada objeto replicado é designada como cópia primáriae e as demais 
são todas cópias secundárias;
2. cópias primárias de diferentes objetos estão em sites diferentes (assim, mais uma 
vez esse é um esquema distribuído);
3. operações de atualização são consideradas logicamente completas tão logo a 
cópia primária seja atualizada. O site que guarda essa cópia é então responsável 
pela propagação da atualização para as cópias secundárias em algum momento 
subsequente.
Esse “momento subsequente” deve ser anterior ao COMMIT, se as propriedades ACID 
da transação tiverem de ser preservadas.
47
ArquiteturA e Projeto de BAnco de dAdos distriBuídos│ unidAde iii
As exigências ACID de processamento de transações implicam que toda propagação de atualização 
deve ser concluída antes que a transação em questão possa se completar (“replicação síncrona”). 
No entanto, vários produtos comerciais admitem atualmente uma forma menos ambiciosa de 
replicação, na qual a propagação de atualizações é feita em algum momento posterior, talvez em 
algum momento especificado pelo usuário, não necessariamente dentro do escopo da transação 
relevante (“replicação assíncrona”). Na verdade, o termo replicação infelizmente foi mais ou menos 
usurpado por esses produtos, resultando que pelo menos no mercado comercial quase sempre 
ele é tomado com o significado de que a propagação de atualizações é postergada além do ponto 
de COMMIT da transação relevante. Um dos problemas com essa abordagem de propagação 
postergada é que o banco de dados não pode mais ter a garantia de ser consistente tempo todo; de 
fato, o usuário pode nem, sequer, saber se ele está consistente ou não.
recuperação
O controle de recuperação em sistemas distribuídos em geral se baseia no protocolo do COMMIT 
em duas fases, ou alguma variante dele. O COMMIT em duas fases é exigido em qualquer ambiente 
em que uma única transação pode interagir com vários gerenciadores de recursos autônomos; 
porém, é particularmente importante em um sistema distribuído, porque os gerenciadores de 
recursos em questão, isto é, os SGBDs locais, estão operando em sites distintos e, portanto, são 
muitos autônomos. Surgem pontos importantes:
1. o objetivo de “não dependência de um site central” determina que a função de 
coordenador não deve ser atribuída a um site específico na rede, mas ser realizada 
por sites diferentes para transações diferentes. Em geral, ela é tratada pelo site no 
qual a transação em questão é iniciada; assim, cada site deve ser capaz de atuar 
como site coordenador para algumas transações e como site participante em outras 
(em geral);
2. o processo de COMMIT em duas fases exige que o coordenador se comunique com 
todos os sites participantes o que significa mais mensagens e maior sobrecarga;
3. se o site Y atuar como participante em um processo de COMMIT em duas fases 
coordenado pelo site X então Y deve fazer o que for determinado pelo site X 
(COMMIT ou ROLLBACK, o que for aplicável): uma perda de autonomia local, 
embora talvez uma pequena perda.
Para simplificar, vamos supor que o coordenador e o participante estão em sites diferentes; além 
disso, suponhamos que a transação tenha solicitado um COMMIT, e não um ROLLBACK. Ao receber 
essa requisição de COMMIT, o coordenador executa o seguinte processo em duas fases:
1. ele instrui cada participante a “ficar pronto para seguir um dos caminhos” na 
transação;
48
UNIDADE III │ArqUItEtUrA E ProjEto DE BANco DE DADos DIstrIBUíDos
2. quando o coordenador recebe respostas de todos os participantes, ele toma sua 
decisão (que será commit se todas as respostas foram “OK” e rollback em caso 
contrário). 
Concorrência
Na maioria dos sistemas distribuídos, o controle de concorrência se baseia no bloqueio, exatamente 
como na maioria dos sistemas não distribuídos. Porém, em um sistema distribuído, requisições para 
testar, impor e liberar bloqueios se tornam mensagens (supondo-se que o objeto em consideração 
esteja em um site remoto), e mensagens significam sobrecarga. Por exemplo: considere uma 
transação T que precise atualizar um objeto para o qual existem réplicas em n sites remotos. Se 
cada site é responsável por bloqueios sobre objetos armazenados nesse site (como acontecerá sob a 
hipótese de autonomia local), então uma implementação direta exigirá pelo menos 5n mensagens:
1. n requisições de bloqueio;
2. n concessões de bloqueio;
3. n mensagens de atualizações;
4. n confirmações;
5. n requisições de desbloqueio.
Podemos facilmente melhorar essa implementação usando mensagens “de carona”, por exemplo. 
As mensagens de requisição de bloqueio e de atualização podem ser combinadas, do mesmo modo 
que as mensagens de concessão de bloqueio e de confirmação, mas, mesmo assim, o tempo total 
para a atualização ainda poderá ser várias ordens de grandeza maior do que seria em um sistema 
centralizado.
49
unidAdE iV
ControlE, 
SinCronizAção E
AtuAlizAção 
Em SiStEmAS 
diStriBuídoS
CAPítulo 1 
Processamento de consulta, sistemas 
de diretórios e protocolos de acesso ao 
diretório
Processamento de consulta
O processamento da consulta em um banco de dados heterogêneo pode ser complicado. Algumas 
das questões são:
 » Dada uma consulta em um esquema global, a consulta pode ter de ser traduzida 
para consultas em esquemas locais em cada um dos sites em que ela precisa ser 
executada. Os resultados da consulta precisam ser traduzidos de volta para o 
esquema global.
A tarefa é simplificada pela escrita origem de dados, que oferece uma visão dos 
dados locais no esquema global. Os wrappers também traduzem consultas no 
esquema global para consultas no esquema local, e traduzem resultados de volta 
para o esquema global. Wrappers podem ser fornecidos por sites individuais ou 
podem ser escritos separadamente como parte do sistema de multibanco de dados.
Os wrappers podem ainda ser usados para oferecer uma visão relacional das 
origens de dados não relacionais, como páginas Web (possivelmente com interfaces 
de formulários), arquivos puros, bancos de dados hierárquicos e de rede, além de 
sistemas de diretório.
 » Algumas origens de dados podem oferecer apenas capacidades limitadas de 
consulta, por exemplo, elas podem admitir seleções, mas não junções. Elas podem, 
ainda, restringir a forma das seleções, permitindo-as apenas sobre certos campos; 
50
UNIDADE IV │CoNtrolE, SINCroNIzAção E AtUAlIzAção Em SIStEmAS DIStrIbUíDoS
as origens de dados da Web com interfaces de formulário são um exemplo de tais 
origens de dados. As consultas, portanto, podem ser desmembradas, para serem 
parcialmente realizadas na origem de dados e parcialmente no site que emite a 
consulta.
 » A otimização de consulta global em um banco de dados heterogêneo é difícil, pois 
o sistema de execução de consulta pode não saber quais custos são de planos de 
consulta alternativos nos diferentes sites. A solução normal é contar apenas a 
heurística no nível global.
Sistemas mediadores são sistemas que integram várias origens de dados oferecendo uma visão global 
integrada dos dados e facilidades de consulta na visão global. Ao contrário dos sistemas multibanco 
de dados com todos os recursos, os sistemas mediadores não se importam com o processamento da 
transação. Os termos mediador e multibanco de dados normalmente são usados de uma maneira 
intercambiável, e os sistemas que são chamados mediadores podem admitir formas limitadas de 
transação. O termo banco de dados virtual é usado para se referir a sistemas multibanco de dados/
mediadores, pois oferecem a aparência de um único banco de dados com um esquema global, 
embora existam dados em vários sites nos esquemas locais.
Sistemas de diretório
Considere uma organização que queira tornar os dados sobre seus funcionários disponíveis a uma 
série de pessoas na organização.Alguns exemplos dos tipos de dados incluem nome, designação, 
id-funcionário, endereço, número de telefone, número de fax e assim por diante. Nos dias anteriores 
aos computadores, as organizações criariam diretórios físicos de funcionários e os distribuiriam 
pela organização. Ainda hoje, companhias de telefone criam diretórios físicos dos clientes.
Em geral um diretório é uma listagem de informações sobre alguma classe de objetos, como 
pessoas. Os diretórios podem ser usados para encontrar informações sobre um objeto específico 
ou, na direção reversa, para encontrar objetos que atendem a um certo requisito. No mundo dos 
diretórios de telefone físicos (os catálogos telefônicos), aqueles que satisfazem as pesquisas na 
direção normal são chamados páginas brancas, enquanto os diretórios que satisfazem pesquisas na 
direção contrária são chamados páginas amarelas.
No mundo atual interligado por redes, a necessidade de diretórios ainda está presente, e 
ainda é mais importante. Porém, os diretórios hoje precisam estar disponíveis por uma 
rede de computadores, em vez de uma forma física (papel).
Protocolos de Acesso ao diretório – ldAP
As informações de diretório podem se tornar disponíveis por meio de interfaces da Web, como 
fazem muitas organizações, principalmente companhias telefônicas. Essas interfaces são boas 
para os humanos. Porém, os programas também precisam acessar informações de diretório. Os 
diretórios podem ser usados para armazenar outros tipos de informações, muito semelhantes aos 
51
Controle, SinCronização e atualização em SiStemaS DiStribuíDoS │ uniDaDe iV
diretórios do sistema de arquivos. Por exemplo, os navegadores Web podem armazenar marcadores 
pessoais e outras configurações de navegador em um sistema de diretório. Um usuário pode, assim, 
acessar as mesmas configurações a partir de vários locais, como em casa e no trabalho, sem ter de 
compartilhar um sistema de arquivos.
Vários protocolos de acesso a diretório foram desenvolvidos para oferecer uma forma padronizada 
de acessar dados em diretório. O mais utilizado, entre eles, hoje é o Lightwight Directory Access 
Protocol – LDAP.
Obviamente, todos os tipos de dados em nossos exemplos podem ser armazenados sem muito 
trabalho em um sistema de banco de dados e acessados por meio de protocolos como o SQL ou ODBC. 
Logo, a questão é: por que a necessidade de um protocolo especializado para acessar informações de 
diretório? Existem pelos menos duas respostas para a pergunta:
 » Primeira, os protocolos de acesso ao diretório são protocolos simplificados, que 
satisfazem um tipo limitado de acesso aos dados. Eles evoluíram em paralelo com 
os protocolos de acesso ao banco de dados.
 » Segunda, e mais importante, os sistemas de diretório oferecem um mecanismo 
simples para nomear objetos de uma forma hierárquica, semelhante aos nomes 
de diretório do sistema de arquivos, que podem ser usados em um sistema de 
diretório distribuído para especificar que informações são armazenadas em cada 
um dos servidores de diretório. Por exemplo, determinado servidor de diretório 
pode armazenar informações para os funcionários da Bell Laboratories, em Murray 
Hill, enquanto outro pode armazenar informações para funcionários da Bell 
Laboratories, em Bangalore, dando a ambos os sites autonomia no controle de seus 
dados locais. O protocolo de acesso ao diretório pode ser usado para obter dados 
dos dois diretórios, através de uma rede. Mais importante, o sistema de diretório 
pode ser configurado para encaminhar automaticamente as consultas feitas em um 
site para outro, sem intervenção do usuário.
Por esses motivos, várias organizações possuem sistemas de diretórios para tornar as 
informações organizacionais disponíveis on-line por meio de um protocolo de acesso 
ao diretório. As informações em um diretório organizacional podem ser usadas para 
uma série de propósitos, como descobrir endereço, telefone ou endereço de e-mail das 
pessoas, descobrir em quais departamentos as pessoas estão, acompanhar hierarquias 
de departamento. Os diretórios também são usados para autenticar usuários: aplicações 
podem coletar informações de autenticação, como as senhas dos usuários, e autenticá-los 
usando o diretório.
Como poderíamos esperar, várias implementações de diretório acham benefício usar bancos 
de dados relacionais para armazenar dados, em vez de criar sistemas de armazenamento de 
uso especial.
52
Para (não) finalizar
Nesta disciplina, conhecemos as principais metodologias de sistemas de banco de dados distribuído, 
que consiste em uma coleção de sites, cada um mantendo um sistema de banco de dados local. Cada 
site é capaz de processar transações locais: aquelas transações que acessam dados apenas nesse site 
isolado. Além disso, um site pode participar na execução de transações globais: aquelas transações 
que acessam dados em vários sites. A execução de transações globais requer a comunicação entre 
os sites.
O aprendizado é integrar esses conhecimentos de banco de dados distribuído com as outras 
disciplinas estudadas e, ainda, as que estão por vim. É um grande objetivo do profissional de banco 
de dados distribuídos, ou um DBA, inovar, criar, elaborar e manter projetos eficazes de banco de 
dados distribuído e aplicar os conhecimentos em prol da TI da sua empresa.
53
referência
DATE, C. J. Introdução a sistemas de banco de dados. Tradução da 8. ed. americana, Rio de 
Janeiro: Editora Elsevier, 2004.
MEYER, L. A. V. C.; MATTOSO, M. L. Q. Sistemas de banco de dados distribuídos e 
paralelos: parallelism in database management systems, Tutorial nos Anais do XII Simpósio 
Brasileiro de Banco de Dados, Apostila publicada como separata, 38 p.
NAVATHE, Elmasri. Sistema de banco de dados. 4. ed. São Paulo: Pearson, 2006.
ÖZSU, M. Tamer; VALDURIEZ Patrick. Princípios de sistemas de banco de dados 
distribuídos. Tradução da 2. ed. americana. Rio de Janeiro: Campus, 2001.
SILBERSCHATZ, Abraham; SUDARSHAN Korth S. Sistema de banco de dados. Tradução da 5. 
ed. americana.Rio de Janeiro: Elsevier, 2006.