Banco de Dados

Distribuídos
 Material Teórico
Utilizando Banco de Dados Distribuídos

Responsável pelo Conteúdo:

Prof. Me. Marcel Thomé Filho

Revisão Textual:
Prof. Me. Luciano Vieira Francisco
 Utilizando Banco de Dados Distribuídos

• Projetando uma Base de Dados Distribuída;

• Fragmentação;
• Alocação;
• Distribuição;
• Segurança;
• Controle de Concorrência;
• Processamento Distribuído de Questões;

OBJETIVO DE APRENDIZADO
• Compreender a importância dos conceitos sobre a distribuição de dados, frag-
mentação, alocação e processamento em ambientes de multiusuários, web, entre
outros aspectos;
• Demonstrar o seu compartilhamento utilizando uma estrutura de banco de dados
adequada e as diferentes situações de distribuição de dados.
 Orientações de estudo
Para que o conteúdo desta Disciplina seja bem
aproveitado e haja maior aplicabilidade na sua
formação acadêmica e atuação profissional, siga
algumas recomendações básicas:
Conserve seu
material e local de
estudos sempre
organizados.
Aproveite as
Procure manter indicações
contato com seus de Material
colegas e tutores Complementar.
para trocar ideias!
Determine um Isso amplia a
horário fixo aprendizagem.
para estudar.

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

Seja original!
Nunca plagie
trabalhos.

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

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

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

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

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

Projetando uma Base de Dados Distribuída

Temos mais coisas a aprender sobre banco de dados distribuído.

Durante este processo de aprendizado já vimos conceitos sobre arquitetura, da-

dos e ambiente. Porém, agora nos aprofundaremos em situações mais específicas
a fim de conhecer as maneiras de se trabalhar nas quais.

O uso dos dados tem funções específicas, pois um banco de dados é a parte mais importante
Explor

na composição da estrutura de um sistema.

A criação e o desenvolvimento de um projeto de banco de dados são essenciais

aos sistemas de informação. Em grande parte da missão de desenvolvimento de
uma estrutura de armazenamento é muito importante conhecer a fundo o pro-
pósito de sua criação, pois sem um bom conhecimento, ou com falta de clareza
ao entender a natureza exata do ambiente onde o banco de dados será aplicado,
pode-se criar bancos de dados ineficientes e falhos, sem atingir o objetivo esperado
pelo cliente.

Preste atenção em todos os detalhes existentes em um projeto de banco de da-

dos, pois desta forma os objetivos exigidos dentro desse escopo serão alcançados.
No entanto, temos mais detalhes a observar, conforme apresentado a seguir.

Figura 1
Fonte: iStock/Getty Images

8
 O uso de sistemas em rede para internet ou distribuídos de natureza comercial
e, principalmente, os sistemas gerenciadores de banco de dados têm se mostrado
necessários às grandes organizações, as quais passaram a necessitar de profissio-
nais mais capacitados e que entendam de distribuição de dados para melhorar a
sua infraestrutura, com o objetivo de aprimorar a distribuição de suas informações.

Os sistemas distribuídos, conhecidos também como sistemas baseados em rede,

apresentam melhor desempenho e correspondem mais às necessidades da estru-
tura organizacional de instituições geográficas e amplamente distribuídas que, por
sua vez, podem prover melhor desempenho e são mais confiáveis e disponíveis em
relação a sistemas centralizados.

A criação, aplicação e o desenvolvimento em dias atuais estão cada vez mais

simples em função do constante declínio no custo de processamento e memória,
na popularização dos computadores pessoais e no aumento da escalabilidade dos
sistemas, por meio de maior facilidade para expansões e integrações de recursos
diferenciados, permitindo a montagem de diversos tipos de sites.

Observamos no mundo de tecnologia aplicações para bancos de grandes lojas

de departamento, que são exemplos clássicos de organizações beneficiadas com a
tecnologia de sistemas distribuídos, em especial, o chamado Sistema de Gerencia-
mento de Banco de Dados Distribuídos (SGBDD).

Fragmentação
Segundo Özsu e Valduriez (2001), em um SGBDD, por razões de desempenho,
confiabilidade e disponibilidade, é desejável que os dados sejam distribuídos pelas
máquinas de uma rede de forma replicada.

Para que isso ocorra é usada uma técnica de fragmentação que consiste na
observação das relações existentes em um banco de dados e são divididas em
fragmentos menores, onde cada fragmento é tratado como um objeto de banco de
dados separado. Assim, cada réplica – fragmento usado como objeto – não cor-
responde à sua replicação completa, mas a uma parte ou a um subconjunto dessa
relação, exigindo menos espaço e, consequentemente, menos itens de dados a
serem administrados.

Importante! Importante!

Você percebe que agora estamos entrando em uma das características que definem o
uso da distribuição? Preste atenção, pois este momento é fundamental!

Definimos, portanto, que a fragmentação no mundo real pode ser divisão, re-
dução ou pequenos pedaços. No entanto, se aplicada ao universo tecnológico, a
fragmentação nada mais é do que a divisão em menores partes de um conjunto

9
9
UNIDADE Utilizando Banco de Dados Distribuídos

de dados, ou do resultado de uma seleção de dados usando uma condição ou não.

Por exemplo, uma tabela de empregados poderia ser fragmentada em duas partes:
aqueles que possuem salário acima de quinze mil reais e os funcionários com salá-
rio menor ou igual a esse valor.

A fragmentação pode ser ainda dividida em três tipos: horizontal, vertical ou

híbrida, vejamos:
• Horizontal: onde a relação é particionada em suas tuplas/linhas e cada frag-
mento gerado tem um subconjunto dessas tuplas da relação original;

AGÊNCIA CONTA SALDO

Brasília A-110 1000
CONTA
Brasília A-120 500
Brasília A-150 250
Brasília A-180 2000

AGÊNCIA CONTA SALDO

São Paulo A-500 500
São Paulo A-200 300
Figura 2 – Fragmentação Horizontal (ex.)
• Vertical: onde são produzidos fragmentos que contêm subconjuntos dos atri-
butos/colunas da relação original, bem como a sua primary key;

AGÊNCIA CONTA CLIENTE SALDO CONTA

Brasília A-110 MARIA 1000
Brasília A-120 PEDRO 500
São Paulo A-500 JOÃO 500
São Paulo A-200 RICARDO 300
Brasília A-150 MARCELO 250
Brasília A-180 CARLA 2000

AGÊNCIA CONTA CLIENTE SALDO TUPLA_ID

Brasília A-110 MARIA 1000 1
Brasília A-120 PEDRO 500 2
São Paulo A-500 JOÃO 500 3
São Paulo A-200 RICARDO 300 4
Brasília A-150 MARCELO 250 5
Brasília A-180 CARLA 2000 6

Figura 3 – Fragmentação Horizontal (ex.)

• Híbrida: consiste na aplicação das duas técnicas anteriores, uma após a outra.
É utilizada porque, na maioria dos casos, uma fragmentação vertical ou hori-
zontal não é suficiente para atender aos requisitos de aplicativos do usuário.

10
 Para a utilização da técnica da fragmentação horizontal, podemos ter as seguin-
tes tipologias:
• Primária: executada com o uso de predicados definidos sobre a própria relação;
• Derivada: surge do particionamento de uma relação, que é resultado da defi-
nição de predicados sobre outra ligação.

O principal objetivo de se utilizar uma das técnicas de fragmentação é a diminui-

ção do tempo de processamento dos aplicativos do usuário. Logo, mesmo sendo ba-
seadas em uma relação completa, as consultas são executadas sobre os fragmentos.

Ademais, para uma fragmentação correta, esta deve ser:

• Completa: se existe determinado dado na relação original, há também um
mapeamento que indica onde esse fragmento se encontra e se há garantias de
sua existência;
• Reconstruível: a relação original pode ser corretamente reconstruída a partir
de seus fragmentos;
• Única: os dados de um fragmento não devem aparecer em nenhum outro,
com exceção da chave primária na fragmentação vertical.

Escolher a técnica mais apropriada para fragmentar cada tabela que compõe
a base de dados é, atualmente, um grande problema que possui apenas algumas
propostas de solução.

Quantas técnicas são usadas no desenvolvimento de um Behavior Driven Development (BDD)

Explor

– desenvolvimento guiado por comportamento?

A escolha que definirá a técnica de fragmentação das tabelas utilizadas depen-

derá de uma série de análises onde diversas informações relativas à sua aplicação
serão verificadas, tais como:
• Consultas mais solicitadas e suas respectivas frequências;
• Características das tabelas que formam a base de dados;
• Relacionamentos com outras tabelas e suas cardinalidades; e
• Quantidade de registros existentes em uma única tabela.

Tal técnica permite o processamento paralelo de uma relação com maior de-
sempenho e possibilita colocar os dados onde são acessados de maneira mais con-
tínua, diminuindo o peso das comunicações.

Nesse sentido, alguns fatores que afetam a realização do processamento divi-

dem-se em:

11
11
UNIDADE Utilizando Banco de Dados Distribuídos

• Estrutura do banco de dados, onde devemos conhecer as ligações/relações

entre as tuplas, com as chaves estrangeiras/integridades referenciais usadas
para definir fragmentos horizontais derivados;
• Características das aplicações, onde devemos conhecer as condições usadas,
localização e frequência de acessos;
• Características da rede, onde devemos conhecer o número e a localização dos
nós, tipo e largura de banda da rede; e
• Capacidade de processamento dos nós.

Percebemos que existem muitos detalhes técnicos a serem observados, pois

para a fragmentação acontecer deve-se realizar a análise de alguns itens e depois
tomar a decisão de qual deve ser empregado. Agora, entramos em outro detalhe
técnico, mas que também envolve o mesmo processo, o da fragmentação.

Utilizar técnicas que envolvem a observação permite uma visão mais ampla de
toda a estrutura desenvolvida ou já finalizada. Partindo para a visão dessa análise,
temos duas estratégias que são utilizadas para a distribuição de bases de dados:
1. Ascendente: comumente aplicada sobre uma base de dados, operando
nas tarefas de modelagem e integrando as bases existentes. Este tipo de
ambiente é visto nos sistemas heterogêneos;
2. Descendente: envolve atividades básicas ao desenvolvimento de sistemas,
tais como a análise de requisitos e captura de informações, gerando um
esquema global até a implementação do projeto físico de distribuição em
projetos locais. É aconselhável para sistemas de bases de dados projetados
no início da modelagem da aplicação, pois sabe-se que é um processo
dinâmico e evolutivo, devendo ser sempre revisado a partir de histogramas
coletados no SGBDD.

Agora que conhecemos uma das técnicas que são usadas em bancos distribuí-
dos, veremos como o processo acontece de maneira que os dados e as informações
trafegam nas bases de dados existentes, assim como os seus comportamentos em
diversos sites ou nós das redes de computadores que dão suporte a essa estrutura.

Alocação
Após decidir quais são as técnicas de fragmentação a serem implementadas, de-
vemos nos preocupar com os recursos de alocação ou como realizar as alocações
de modo que o desempenho chegue a níveis satisfatórios de consulta nas bases de
dados, de acordo com os seus nós ou locais de armazenamento. Nesse sentido,
trabalharemos neste seguimento.

12
 Depois de fragmentar as relações, o importante é tratar a alocação – colocar o
fragmento em um único nó – e/ou replicação – colocar o fragmento em dois ou
mais nós.

A intenção de prestar atenção nisso tem como objetivo minimizar os custos e/

ou melhorar a performance no tempo de resposta e capacidade de processamento.
Ademais, esta performance inclui os custos de:
• Comunicação entre nós;
• Processamento;
• Obtenção e atualização dos dados;
• Armazenamento dos dados.

Aplicação 1

Aplicação 2 SGBD Banco de

Dados

Aplicação 3

Figura 4

Com a chegada dos processos, a primeira cópia é altamente vantajosa porque

aumenta a confiabilidade e disponibilidade do sistema. Mas, a partir da demanda
devemos observar algumas restrições, tais como as capacidades de armazenamen-
to e processamento dos nós.

Por envolver elevado número de variáveis, a alocação pode se tornar um proble-

ma extremamente complexo, de modo que a sua complexidade está diretamente
ligada ao número de nós e aplicações existentes no sistema. Às vezes não chega a
ser possível encontrar uma ótima solução em tempo útil – se for este o caso, deve-
-se recorrer:
• A heurísticas – quando se deseja otimizar o desempenho;
• À programação de fórmulas lineares/inteiras – quando o objetivo é minimizar
os custos;
• Ao método best-fit – ou melhor medida –, utilizado para determinar uma alo-
cação sem replicação, onde é associada uma medida a cada alocação possível
e o nó com a melhor medida é selecionado;
• À alocação de réplicas: utilizar todos os nós beneficiários, ou seja, replicar em
todos os nós onde o benefício de alocar uma cópia seja maior que o custo, ou
ainda prover-se da variante de replicação adicional e começar com a solução não
replicada, introduzindo progressivamente as cópias até que deixe de ser vantajoso.

13
13
UNIDADE Utilizando Banco de Dados Distribuídos

A alocação envolve encontrar a ótima distribuição de dados por meio dos nós da
rede, com o objetivo de minimizar o custo das aplicações sobre os mesmos. Esse é
um aspecto crítico em um SGBDD, pois gera uma alocação ineficiente, levando a
um aumento considerável do custo de acesso ao sistema.

Na criação de um projeto de distribuição da base de dados, a fase de alocação

é realizada após a de fragmentação, vez que um dos principais objetivos a serem
alcançados é o aumento da proximidade entre os fragmentos e nós, na tentativa de
minimizar o custo da comunicação.

Pensando na qualidade, o principal aspecto é a eficiência que existe no desen-

volvimento do projeto de alocação, ou seja, pensar na alocação dos dados nos nós
deve minimizar, ao máximo necessário, o custo das consultas executadas.

Trabalhar com o processo de tomada de decisão presente na alocação de dados

é definido como escolher entre todos os possíveis modelos de alocação de frag-
mentos nos nós de uma rede, trabalhando com todas as possíveis distribuições dos
fragmentos e escolhendo aquela que minimize o custo de acesso aos dados aloca-
dos. Tal problema inclui a decisão de replicação dos fragmentos.

Distribuição
Segundo Özsu e Valduriez (2001), uma transação é um grupo de processos que
fazem transformações consistentes aos estados do sistema, ao mesmo tempo que
preservam a sua consistência.

Nas bases distribuídas de dados, esses processos têm complexidade aumenta-

da, já que podem envolver a cooperação de vários nós. Quando isso acontece,
é denominado processo global e se divide em subprocessos – tantos quanto os
nós envolvidos.
Explor

Quanto trabalho existe no desenvolvimento de um projeto?

Apesar dessas contingências, devem manter as suas propriedades fundamentais,

a saber:
• Atomicidade: todos os subprocessos são realizados, assim como o commit do
processamento global – ou todos são abortados;
• Consistência: cada processamento é executado separadamente na base de
dados, com o intuito de mantê-la consistente, sem violar as restrições de inte-
gridade da mesma;
• Isolamento: para que esta característica seja uma realidade é necessário se-
guir uma sequência, afinal, uma transação ou processamento incompleto não
deve mostrar os seus resultados às outras transações antes de ser realizado o

14
 seu commit – evitando aborts em cascata de processamento. Assim, ao existir
isolamento evitam-se vários problemas, por exemplo:
» Leitura suja – dirty read: a transação T1 modifica o item de dados X que é,
em seguida, lido por T2 antes de T1 terminar;
» T1 aborta;
» T2 lê um valor que nunca existiu no banco de dados;
» Leitura não repetível ou confusa – fuzzy read: T1 lê X;
» T2 modifica ou apaga X e faz commit;
» T1 tenta ler X outra vez, mas lê um valor diferente, ou não consegue encontrá-lo;
» Fantasmas: T1 procura na base de dados tuplas de acordo com um predica-
do, enquanto T2 insere novas tuplas que satisfazem esse predicado.
• Persistência: com o commit realizado, o sistema deve garantir que os resulta-
dos não desapareçam, mesmo que ocorram falhas subsequentes.

Segurança
As características fundamentais das transações, mais conhecidas por Atomicity,
Consistency, Isolation, Durability (Acid), tornaram-se realidade de acordo com os
protocolos de segurança criados para as quais, a saber, protocolos de:
1. Commit;
2. Abort ou terminação;
3. Recuperação.

A utilização de desenvolvimento, preparação, observação e das técnicas que

existem nas bases distribuídas contemplam também uma parte de segurança e seus
protocolos – não podemos fugir disso.

Figura 5
Fonte: iStock/Getty Images

15
15
UNIDADE Utilizando Banco de Dados Distribuídos

Devemos pensar que em cada nó existe um gestor local de transações, respon-

sável por manter o log – para a recuperação, caso seja necessária – e por participar
e observar o que acontece, estando também na coordenação da execução concor-
rente que existe para aplicar no próprio nó. Há um coordenador de transações
responsável por iniciar a execução das que começam nesse nó, por distribuir as
subtransações pelos nós apropriados e por coordenar a terminação de todas as
transações que iniciam no próprio nó – fazer o commit ou abort em todos os nós.

Protocolos de Commit
Sua responsabilidade é manter segura a propriedade da atomicidade da tran-
sação em seu cumprimento, sendo que o protocolo mais conhecido e simples é o
Two-Phase Commit (2PC) – commit em duas fases.

O seu funcionamento ocorre de modo que o nó coordenador – ou seja, que

controla o protocolo – envie a seguinte mensagem a cada um dos nós participantes
envolvidos na transação: “Pronto para commit?”

Após o envio da mensagem, uma resposta é aguardada com esta informação:

“Pronto”, indicando estar preparado para fazer o commit de sua parte da transa-
ção; ou então com esta mensagem: “Abort”, sinalizando que não é possível fazer
o commit. Ademais, todos os envolvidos no processamento da transação devem
responder: “Pronto”, a fim de que o commit da transação possa ocorrer. Caso isso
não ocorra é enviada esta mensagem: “Global abort” a todos os participantes para
que abortem as suas subtransações. Ou seja, basta um abort de um dos nós para
que toda a transação falhe.

Ademais, existem três implementações do 2PC:

1. Centralizada: todas as comunicações envolvem o nó coordenador;
2. Linear: os nós se comunicam em uma sequência ordenada, a partir do
coordenador;
3. Distribuída: todos os nós se comunicam entre si de forma direta. Poderá
ocorrer um bloqueio pelo 2PC caso perceba uma falha de um dos nós
durante o processo.

Uma transação bloqueada não é desejável porque pode impedir que outras tran-
sações que precisem desses mesmos recursos os possam obter.

Para resolver o impasse na limitação do 2PC foi criado o Three-Phase Commit

(3PC), semelhante ao 2PC, mas com pre-commit, confirmando que todos os nós
estão em condições de finalizar.

16
Protocolos de Abort ou Terminação
Ao ser percebida uma falha, estes protocolos indicam aos restantes como lidar
com o ocorrido. No caso do 2PC, se um nó participante falha e se o:
• Coordenador se encontra no estado wait, é necessário abortar a transação;
• Coordenador se encontra no estado commit ou abort, deve reenviar a mensa-
gem de commit/abort global ao nó em falha;
• Coordenador falha no estado wait, quando em recuperação, pode simples-
mente recomeçar o processo de commit;
• Participante falha no estado ready, quando em recuperação, pode perguntar
ao coordenador o que fazer quanto à subtransação interrompida.

Protocolos de Recuperação
Após resolvidas as falhas e as transações voltarem a ficar operacionais, tais
protocolos demonstram quais soluções devem ser tomadas para sincronizarem aos
nós restantes.

Controle de Concorrência
Ufa! Quantos detalhes temos que aprender e observar, mas espere que ainda
discorreremos sobre processar itens ao mesmo tempo – isso pode atrapalhar um
pouco o processo.

Avaliar, processar, verificar, tentar realizar etc., várias são as técnicas para sin-
cronizar transações concorrentes de modo a manter a consistência da base de da-
dos, enquanto ao mesmo tempo é atingido o máximo grau de concorrência.

Trabalhar com escalonamento – ou história – de execução significa conhecer a

ordem em que as operações de um conjunto de transações são executadas.

Podemos ter o escalonamento serial, onde as transações ocorrem consecutiva-

mente se forem consistentes, ou seja, obedecer às regras de integridade, garantin-
do a consistência da base de dados ao final da execução.

Já em um escalonamento serializável – serial – as transações são executadas

concorrentemente, mas o efeito prático sobre a Base de Dados (BD) é equivalente
ao de um escalonamento serial.

17
17
UNIDADE Utilizando Banco de Dados Distribuídos

Nesse sentido, deve-se considerar também:

• Equivalência de conflitos: a ordem de execução de operações conflituosas
pertencentes a transações que não foram abortadas em dois escalonamentos
é a mesma;
• Operações conflituosas: duas operações – por exemplo, read e write – entram
em conflito acessando o mesmo item. Se duas operações de duas transações
diferentes entrarem em conflito, as transações dizem-se conflituosas.

Para tentar resolver tais conflitos existem o que chamamos de algoritmos de

controle de concorrência, os quais se dividem em pessimistas – por exemplo, 2PL,
algoritmos de timestamp e híbridos – e otimistas.

No 2PL existem duas fases: obtenção de locks e libertação de locks. Cada tran-
sação deve obter os locks de todos os objetos que necessitará antes de os usar. Se
um objeto já estiver locked por outra transação, todas as demais devem esperar.
Ademais, quando a transação liberta um dos locks, não pode pedir outros.

No timestamp a abordagem é diferente: a cada transação é atribuído um

timestamp único em todo o sistema. A cada item de dados é atribuído um read
timestamp e um write timestamp. Operações conflituosas são resolvidas usando o
ordenamento timestamp.

Segundo a criação por meio do método de Lamport, timestamp é um número

com características de composição formadas por dois grupos de dígitos: os menos
significativos, em que é identificado o nó onde ocorreu o evento; enquanto os mais
significativos apontam os eventos que ocorreram nesse nó.

Os últimos dígitos podem ser obtidos por meio de um contador lógico ou através de
um relógio local, mas cada vez que dois nós trocam uma mensagem, os timestamps
são sincronizados. O receptor timestamp tem um valor maior do que o do emissor
– se isso não for verdade, a transação é abortada. O contador local do receptor é
avançado, realizando uma nova tentativa.

Nos algoritmos de locking e nos de timestamp que implicam espera podem

ocorrer deadlocks, de modo que existem várias estratégias alternativas para lidar
com esse problema, por exemplo:
• Ignorar: deixar o programador lidar com o problema ou fazer restart do sistema;
• Prevenir: garantir que os deadlocks não cheguem sequer a se manifes-
tarem. Realizar a verificação quando esta inicia e pré-declarar todos os
recursos necessários;
• Evitar: detectar potenciais deadlocks antes de estes ocorrerem e tomar medi-
das para que isso não aconteça;
• Detectar e recuperar: se os deadlocks ocorrerem, detectá-los e obrigá-los
a terminar.

18
Processamento Distribuído de Questões
Consultar em bases distribuídas nos faz pensar em como as instruções de banco
ou SQL devem ser descritas.

Uma base que possui processamento distribuído de questões corresponde ao

processo de obter dados de diferentes nós, momento em que podemos utilizar di-
versas formas ou estratégias.

Em sistemas centralizados, o primeiro critério para avaliar o custo de uma deter-

minada estratégia é o número de acessos ao disco; já no sistema distribuído, outros
critérios devem ser levados em conta, incluindo o custo da transmissão de dados
sobre a rede e a possibilidade de paralelismo.

A função de obtenção de dados possui três componentes, ou seja, custos de I/O,

CPU e comunicações.

Conforme o que se mede ou avalia, deve-se levar em conta toda a arquitetura

desenvolvida e o seu ambiente. Nesse sentido, dependendo do ambiente distribuí-
do – LAN ou WAN –, deve-se prestar atenção a um ou outro custo. Em WAN, por
exemplo, os custos de transmissão são dominantes, enquanto que nas LAN deve-se
ter em conta a função global – sendo possível aqui recorrer aos broadcasts.

A verificação para as otimizações começa na fragmentação e alocação desses

mesmos fragmentos. Se, de fato, a alocação for bem estruturada, os custos podem
ser minimizados e o desempenho do sistema, otimizado.

Importante! Importante!

As observações citadas trazem apontamentos que podem nos levar a caminhos mais
fáceis de se resolver os inconvenientes anunciados ao longo do projeto.

A execução e criação, bem como a avaliação do processamento distribuído de

questões trazem várias condições complexas, tal como o cálculo do custo do mode-
lo, tornando necessário encontrar uma solução de compromisso entre as necessi-
dades de otimização e redução dos custos de execução. Por vezes, a performance
tem limitado o tempo de vida devido a mudanças no sistema, o que implica na
criação e atualização do que já foi melhorado.

Os sistemas estão em constante evolução, sendo contraproducente consumir

muitos recursos e tempo de execução para encontrar o melhor escalonamento;
eventualmente será necessário observar sempre que houver tais mudanças, a fim
de encontrar um novo escalonamento.

A partir do momento em que for encontrado o melhor escalonamento global,

deve-se realizar tudo o que for necessário para as otimizações locais, encontrando
o melhor caminho de acesso e utilizando técnicas para a otimização centralizada.

19
19
UNIDADE Utilizando Banco de Dados Distribuídos

A necessidade de manter a integridade dos dados do sistema não é problemáti-

ca nos sistemas homogêneos. Contudo, nos heterogêneos, onde as restrições de
integridade são, muitas vezes, diferentes entre si, obrigam a resolução de conflitos
antes de se avançar ao inquérito global – conflitos estes que existem em três níveis:
1. Inconsistências em restrições locais de integridade;
2. Dificuldades em especificar restrições globais de integridade;
3. Inconsistências entre restrições locais e globais de integridade.

As restrições globais de integridade, apesar de difíceis de implementação, po-

dem eliminar as inconsistências locais em cada base individual de dados. As res-
trições globais de integridade, por outro lado, não estão ligadas às bases de dados
individuais, de modo que pode ser dificultoso mudar a organização da estrutura
para tornar a base de dados consistente. Nestes casos, as inconsistências entre
restrições locais e globais de integridade são inevitáveis.

A resolução dos conflitos depende do nível de controle centralizado. Assim, se

tal controle for forte, as restrições globais de integridade terão precedência; caso
contrário, serão as locais.

Ademais, são passos no processamento distribuído de questões:

• Decomposição;
• Localização; e
• Otimização do inquérito global.

Existem diversos modelos e métodos para o trabalho com essas questões, sendo
a utilização de árvores de análise algébrica uma opção, pois são facilitadoras na ve-
rificação do processamento distribuído de questões ao apresentarem graficamente
os passos da questão. Assim, os inquéritos remotos são imediatamente localizados,
permitindo rapidez para remeter ao servidor adequado a execução do subinquérito.

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

Sites
CONHECENDO a técnica de fragmentação no SGBD Oracle
CONHECENDO a técnica de fragmentação no SGBD Oracle. 2015. Devmedia.
https://goo.gl/HvmiWh
Distribuição e fragmentação de bases de dados
FLORENTINO, P. V. Distribuição e fragmentação de bases de dados. SQL Magazine,
n. 16, 2007.
https://goo.gl/s9avdM

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

21
21
UNIDADE Utilizando Banco de Dados Distribuídos

Referências
BARBIERI, C. Bi2: business intelligence, modelagem & qualidade. Rio de Ja-
neiro: Elsevier, 2011.

DATE, C. J. Introdução a sistemas de banco de dados. Rio de Janeiro: Elsevier, 2003.

MACHADO, F. N. R. Banco de dados: projeto e implementação. 3. ed. São Pau-

lo: Érica, 2014.

ÖZSU, M. T.; VALDURIEZ, P. Principles of distributed database systems.

[S.l.]: Prentice Hall, 1991.

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

mas. 3. ed. São Paulo: Pearson, 2009.

22