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 permitem