BANCO DE DADOS DISTRIBUÍDOS

Prévia do material em texto

1 
 
 
BANCO DE DADOS DISTRIBUIDOS 
1 
 
 
SUMÁRIO 
 
NOSSA HISTÓRIA .......................................................................................... 2 
Descrição de Bancos de Dados Centralizados ................................................ 3 
Descrição de Bancos de Dados Distribuídos ................................................... 4 
banco de dados distribuído .............................................................................. 5 
IMPLEMENTAÇÃO .......................................................................................... 8 
Processamento de consultas distribuídas ....................................................... 9 
Requisitos Funcionais de um Banco de Dados Distribuído Ideal................... 11 
Arquitetura de Referência para um Banco de Dados Distribuído .................. 13 
Projeto de Banco de Dados Distribuído ......................................................... 14 
Projeto de Fragmentação de Dados .............................................................. 15 
Projeto de Replicação de Dados ................................................................... 16 
Projeto de Alocação de Dados ...................................................................... 17 
CONTROLE E MONITORAMENTO .............................................................. 18 
PAPEL ESTRATÉGICO DAS APLICAÇÕES DE TI ...................................... 19 
Organização e Tarefas da Equipe de Administração ..................................... 20 
Problemas que Afetam a Administração ........................................................ 21 
REFERENCIAS ............................................................................................. 22 
 
 
2 
 
 
 
NOSSA HISTÓRIA 
 
 
A nossa história inicia com a realização do sonho de um grupo de empresários, 
em atender à crescente demanda de alunos para cursos de Graduação e Pós-
Graduação. Com isso foi criado a nossa instituição, como entidade oferecendo 
serviços educacionais em nível superior. 
A instituição tem por objetivo formar diplomados nas diferentes áreas de 
conhecimento, aptos para a inserção em setores profissionais e para a participação 
no desenvolvimento da sociedade brasileira, e colaborar na sua formação contínua. 
Além de promover a divulgação de conhecimentos culturais, científicos e técnicos que 
constituem patrimônio da humanidade e comunicar o saber através do ensino, de 
publicação ou outras normas de comunicação. 
A nossa missão é oferecer qualidade em conhecimento e cultura de forma 
confiável e eficiente para que o aluno tenha oportunidade de construir uma base 
profissional e ética. Dessa forma, conquistando o espaço de uma das instituições 
modelo no país na oferta de cursos, primando sempre pela inovação tecnológica, 
excelência no atendimento e valor do serviço oferecido. 
 
 
 
 
 
3 
 
 
DESCRIÇÃO DE BANCOS DE DADOS CENTRALIZADOS 
 
A descrição de um banco de dados centralizado usualmente está dividida em 
três níveis: conceitual ou lógico, interno ou físico e externo. A descrição a nível lógico 
forma o esquema conceitual do banco de dados. O esquema conceitual deve 
apresentar uma visão de alto nível do banco, independente da forma de 
armazenamento refletindo apenas a semântica do empreendimento que está sendo 
modelado. 
O esquema conceitual consiste de um conjunto de estruturas de dados 
descrevendo como os dados estão organizados do ponto de vista lógico, além de um 
conjunto de restrições de integridade indicando que conjuntos de dados corretamente 
refletem situações do mundo real. A classe de estruturas de dados e restrições de 
integridade permitidas são determinadas pelo modelo de dados escolhido. 
Ao nível interno ou físico, obtém-se uma representação eficiente do esquema 
conceitual em termos dos métodos de acesso e estruturas de arquivos oferecidas 
pelo sistema de gerência de banco de dados. O resultado é chamado de esquema 
interno do banco. A existência de um esquema interno separado do esquema 
conceitual é bastante importante pois os detalhes de armazenamento do banco 
devem ser transparentes (ou mesmo irrelevantes) ao desenvolvimento de programas 
de aplicação. 
O esquema interno não deve ser visível aos usuários ou analistas de aplicação, 
sendo responsabilidade do administrador do banco definí-lo. Além disto, espera-se 
de um bom sistema de gerência de banco de dados que permita mudar o esquema 
interno do banco sem alterar os programas de aplicação. Ou seja, o SGBD deve 
permitir alcançar o que chamamos de independência física de dados. 
Finalmente, pode-se criar uma visão especializada do banco para cada grupo 
de usuários, ainda do ponto de vista lógico, através da definição de um esquema 
externo para cada grupo. Esquemas externos facilitam o desenvolvimento de 
aplicações já que focalizam apenas a parte do banco que interessa à aplicação, 
escondendo parte da complexidade do banco. Esquemas externos também são úteis 
como uma forma de restringir o acesso a dados classificados por parte de grupos de 
usuários. 
4 
 
 
 
DESCRIÇÃO DE BANCOS DE DADOS DISTRIBUÍDOS 
 
A descrição de um banco de dados distribuído, refletindo os requisitos de que 
a localização e replicação dos dados deve ser transparente aos usuários do BDD e 
de que o sistemas locais devem manter sua autonomia. O requisito postulando que a 
distribuição do BDD deve ser transparente ao usuário pode ser entendido como 
indicando que, a nível lógico, um BDD deve ser visto como se fosse um banco de 
dados centralizado. Desta forma, deve existir: 
 Um esquema conceitual global descrevendo o BDD a nível lógico e 
ignorando o fato deste ser distribuído e 
 Vários esquemas externos globais descrevendo visões do BDD para 
grupos de usuários. 
Estes dois primeiros níveis são, portanto, idênticos para bancos de dados 
centralizados e distribuídos. O esquema conceitual global não é mapeado 
diretamente em esquemas internos nos diversos nós onde residirá o banco. Esta 
alternativa aglutinaria em um único passo os problemas de se definir tanto o critério 
de distribuição do banco como também a estratégia de armazenamento do banco em 
cada nó. Para evitar este inconveniente, introduz-se para cada nó onde uma parte do 
banco estará armazenada um esquema conceitual local descrevendo o banco de 
dados local. O mapeamento do esquema conceitual global para os vários esquemas 
conceituais locais define, então, o critério de distribuição usado. 
A estratégia de armazenamento de cada banco de dados local é definida 
mapeando-se o esquema conceitual local que o define em um esquema interno local. 
Cada nó possui, portando, uma descrição completa, a nível lógico e físico, do banco 
ali armazenado. 
O conceito de um banco de dados local é mais facilmente justificado frente ao 
requisito indicando que sistemas locais devem manter sua autonomia. Assim, faz 
sentido introduzir também esquemas externos locais em cada nó descrevendo visões 
do banco de dados local para cada grupo de usuários locais. A descrição de um banco 
de dados distribuído é afetada pelo tipo de sistema da seguinte forma. Se o SGBD for 
5 
 
 
homogêneo, todos os esquemas a nível lógico utilizarão o mesmo modelo de dados. 
Já no caso de sistemas heterogêneos, teremos a seguinte situação: 
 Esquema conceitual global no modelo de dados pivot; 
 Esquemas externos globais podem ser tanto no modelo de 
dados pivot, para usuários globais, ou em um modelo de dados 
local, no caso de se desejar oferecer a um usuário local uma 
visão do BDD no modelo que ele está acostumado; 
 Esquemas conceituais locais no modelo de dados local; 
 Esquemas externos locais no modelo de dados local. 
 
BANCO DE DADOS DISTRIBUÍDO 
 
Um sistema de banco de dados distribuído (BDD) consiste em um relação de 
nós, cada qual podendo participar na execução de transações que acessam dados 
em um ou mais nós. Emum sistema de banco de dados distribuído, o banco de dados 
é armazenado em diversos computadores (nós). Os computadores, em um sistema 
distribuído, comunicam-se uns com os outros por intermédio de vários meios de 
comunicação, tais como: redes de alta velocidade, redes sem fio ou linhas telefônicas, 
eles não compartilham a memoria principal e o relógio. 
A diferença principal entre sistemas de banco de dados centralizados e 
distribuídos é que no primeiro os dados estão localizados em um único lugar, 
enquanto que no outro os dados residem em diversos locais. Esta distribuição de 
dados é motivo de muitas preocupações e dificuldades. 
Os processadores em um sistema distribuído podem variar em tamanho e 
função, podendo incluir microcomputadores, estações de trabalho, minicomputadores 
e sistemas de computadores de uso em geral. Estes processadores são geralmente 
chamados de nós, dependendo do contexto no qual eles estejam mencionados. Usa-
se principalmente o termo nó (lugar, posição), a fim de enfatizar a distribuição física 
destes sistemas. Veja o exemplo na Figura 1: 
Figura 1: Figura demonstrando o sistema de banco de dados distribuído. 
6 
 
 
 
 
Banco de Dados (BD): Um banco de dados pode ser definido como uma 
coleção computadorizada de dados operacionais armazenados que servem para 
suprir as necessidades de múltiplos usuários dentro de uma ou mais organizações, 
Sistema Gerenciador de Banco de Dados (SGBD) : De uma forma bastante simples 
pode-se dizer que o SGBD é um conjunto de softwares responsável pelo controle e 
gerenciamento dos recursos de banco de dados. 
Banco de Dados Distribuído (BDD): Um banco de dados distribuído é uma 
coleção de dados pertencentes logicamente ao mesmo sistema, mas distribuídos 
sobre vários sítios de uma rede de computadores, Para Christian J. Date “Um sistema 
de banco de dados distribuído consiste de uma coleção de sítios, conectados através 
de redes de comunicação, no qual cada sítio é um sistema de banco de dados em 
seu próprio direito, mas os sítios concordam em cooperar, de tal forma que um usuário 
em qualquer sítio possa acessar qualquer dado na rede exatamente como se 
estivesse armazenado no próprio sítio do usuário.” 
Sobre Bancos de Dados Distribuídos, destacam-se o projeto de banco de 
dados distribuído e os seus componentes: projeto de fragmentação, projeto de 
replicação e projeto de alocação de dados. O principal enfoque na implementação do 
sistema Controle da Frota de Veículos é o projeto de replicação, totalmente suportado 
pelo SGBDD Oracle7. O projeto de fragmentação não é suportado pelo SGBDD 
Oracle7. O projeto de alocação neste trabalho é constituído basicamente do 
levantamento das tabelas, réplicas e índices destinados a cada sítio e pelos cálculos 
efetuados para se chegar ao espaço em disco necessário para armazená-los. 
7 
 
 
Os Sistemas de Gerência de Banco de Dados Distribuídos são estudados 
através de seus principais componentes : gerência de transação, concorrência e 
recuperação. O método mais utilizado pelos SGBD’s comerciais para o controle de 
concorrência é o Bloqueio. Para manter a integridade dos dados envolvidos em 
transações distribuídas, a maioria dos SGBD’s utiliza o Protocolo Bifásico de 
Confirmação (2PC). Para resolver os casos de deadlocks globais, o método 
geralmente implementado é o Timeout. 
 
ARMAZENAMENTO DISTRIBUÍDO DOS DADOS 
 
Uma relação r (ou tabela) possui diversos enfoques para o armazenamento em 
um banco de dados distribuído (BDD): 
 Replicação: o sistema mantém réplicas idênticas da relação, onde cada 
réplica é armazenada em sites diferentes, resultando na replicação dos 
dados 
 Fragmentação: a relação é particionada em vários fragmentos, onde 
cada fragmento é armazenado em um site diferente 
 Replicação e fragmentação: a relação é particionada em vários 
segmentos, e o sistema mantém diversas réplicas de cada fragmento 
Replicação de dados 
A replicação de dados significa que um determinado objeto de dados logico 
pode possuir diversos representantes armazenados, em nós. O grau de suporte para 
a replicação é um pré-requisito para atingir o verdadeiro potencial de um sistema 
distribuído. 
Fragmentação de dados 
Uma relação é dividida em fragmentos, onde cada fragmento contem 
informação suficiente para permitir a reconstrução da relação original. Existem duas 
formas de fazer a fragmentação: 
8 
 
 
 Fragmentação Horizontal: divide a relação separando as tuplas de r 
em dois ou mais fragmentos. 
 Fragmentação Vertical: divide a relação pela decomposição do 
esquema R da relação r. 
Fragmentação e Replicação de Dados 
As técnicas de fragmentação e replicação podem ser aplicadas 
sucessivamente a uma mesma relação. Um fragmento pode ser replicado, e as 
réplicas podem ser fragmentadas novamente e assim por diante. 
IMPLEMENTAÇÃO 
 
Esta parte não representa uma função somente do planejamento, mas da 
administração da empresa como um todo. Stoner e Freeman (1999) ressaltam que a 
partir do momento em que a estratégia for escolhida deve ser implementada ou 
inserida nas operações da organização. Os autores ainda ressaltam a importância 
desta implementação iniciar-se a partir de um documento formal que pode ser um 
plano. 
Para ocorrer uma implementação adequada não bastam apenas as 
informações fornecidas no processo de planejamento, Megginson et al (1998) destaca 
que é fundamental a existência de recursos humanos, materiais e 24 financeiros 
suficientes para que ocorra tal execução. Ainda assim, o mesmo destaca que para 
colocar o planejamento em ação é fundamental alguém capaz de liderar e motivar os 
envolvidos. 
Megginson et al (1998) ainda afirma que em empresas muito grandes devese 
tomar cuidados especiais quanto a sobreposição de planos ou até conflito entre 
esses. Para evitar tais empecilhos, a criação de um setor central responsável pela 
coordenação geral dos planos é essencial. 
Bateman e Snell (1998) acrescentam que esta etapa torna-se mais eficaz e 
eficiente quando os administrados e funcionários participam dos passos anteriores, 
tornando assim os envolvidos mais informados, compromissados e motivados a 
cumprir os objetivos estabelecidos. Mais além, ressalta-se também que o emprego 
9 
 
 
de programas de incentivos financeiros são uma grande maneira de incentivar uma 
implementação bem sucedida. 
 
PROCESSAMENTO DE CONSULTAS DISTRIBUÍDAS 
 
A transparência para leitura é mais fácil de se conseguir e manter do que a 
transparência para atualização. O maior problema para a atualização é garantir que 
todas as réplicas e fragmentos sejam atualizados, após uma atualização em uma das 
réplicas ou fragmentos. A atualização deve ser prolongada para todas as cópias 
(réplicas e fragmentos) existentes no sistema. 
Um dos fatores mais importantes no desempenho de uma consulta, em uma 
base centralizada, é a quantidade de acesso a disco necessária para atingir o 
resultado. Em um banco distribuído os problemas aumentam, pois existe também a 
preocupação com a transmissão de dados na rede. Um fator interessante para a 
consulta realizada em uma base distribuída é que para os diversos sites podem 
processar partes da consulta em paralelo. 
Na realização de uma consulta simples (trivial), como consultar todas as tuplas 
da relação CONTA, pode caracterizar um processamento não tão trivial, pois CONTA 
pode estar fragmentada, replicada ou ambas. 
Transações 
O acesso a diversos itens de dados em um sistema distribuído é normalmente 
acompanhado de transações que têm de preservar as propriedades ACID: 
 A: Atomicidade 
 C: Consistência 
 I: Isolamento 
 D: Durabilidade 
Características da ACID 
 Atomicidade: Todas as operações da transação são refletidas 
corretamente no BD ou nenhuma será. 
10 
 
 
 Consistência: A execução de uma transação isolada preserva a 
consistência do banco de dados. 
 Isolamento: Cadatransação não toma conhecimento de outras 
transações concorrentes. 
 Durabilidade: Depois da transação completar-se com sucesso, as 
mudanças que ela faz no banco de dados persistem. 
Tipos de transação 
 Locais: mantem acesso e atualizam somente a base de dados local. 
 Globais: mantem acesso e atualizam diversas bases de dados locais. 
Funções adicionais 
 Rastreamente de dados. 
 Processamento de consultas distribuídas. 
 Gerenciamento de transações distribuídas. 
 Gerenciamento de dados replicados. 
 Recuperação de banco de dados distribuído. 
 Segurança. 
 Gerenciamento do diretório distribuido 
Vantagens 
 Gerenciamento de dados distribuído com níveis diferentes de 
transparência. 
 Transparência de distribuição ou de rede. 
 Transparência de replicação. 
 Transparência de fragmentação. 
 Melhoria da confiabilidade e na disponibilidade. 
 Melhoria no desempenho. 
 Expansão mais fácil. 
Falhas 
Em um sistema de banco de dados distribuído pode sofrer os mesmos tipos de 
falhas que ocorrem em um sistema centralizado, porem existem falhas adicionais que 
podem ocorrer em um (BDD), tais como: falha de comunicação entre eles, perda de 
11 
 
 
mensagens e o particionamento da rede, cada um desses problemas devem ser 
considerados no projeto de recuperação de um BDD. Para um sistema ser robusto, 
ele precisa detectar qualquer uma dessas falhas, reconfigurar-se enquanto a falha é 
recuperada. 
 
REQUISITOS FUNCIONAIS DE UM BANCO DE DADOS DISTRIBUÍDO 
IDEAL 
 
Segundo Christian J. Date um banco de dados distribuído ideal deve atender 
os seguintes requisitos: 
Autonomia Local: Os sítios, em um sistema distribuído, devem ser 
autônomos, ou seja, os dados são acessados e gerenciados localmente, as 
operações locais permanecem no mesmo sítio e nenhum sítio depende de outro para 
se tomar operável. Não deve existir dicionário centralizado, controlador de atividades 
centralizado ou detector de bloqueio mútuo centralizado. 
Independência dos Sítios: Todos os sítios em um sistema distribuído devem 
possuir o mesmo tratamento. As funções de gerenciamento de dicionário, 
processamento de pesquisas, controle de concorrência e recuperação não devem 
depender de um sítio central. 
Operação Contínua: A entrada de um novo sítio, instalação de uma nova 
versão do SCiBD são exemplos de operações que não devem alterar em nada o 
funcionamento do sistema ou das aplicações. Cada sítio é uma unidade funcional 
independente. Independência de Local : Os dados aparecem para os usuários como 
se estivessem armazenados localmente. A movimentação de dados entre sítios não 
deve alterar a forma do usuário ver os dados. O usuário deve consultar e atualizar 
dados independente do sítio. 
Independência de Fragmentação: Fragmentação é a divisão de uma relação 
utilizando-se operações relacionais de restrições e projeções. Esta divisão pode 
ocorrer de forma horizontal, envolvendo subconjuntos de linhas, de forma vertical, 
envolvendo subconjuntos de colunas e de forma mista. A reconstrução da relação 
original dos fragmentos é feita utilizando-se operadores de junção e de união da 
12 
 
 
Linguagem de Manipulação de Dados (SQL). A visão que um usuário possui de uma 
relação fragmentada é a mesma que ele possui de uma relação centralizada. 
Independência de Replicação: Um sistema de banco de dados distribuído 
deve suportar replicação de dados, ou seja, deve permitir que uma relação (ou 
fragmento) possua uma ou mais cópias em vários locais distintos da rede. As razões 
básicas de uso de réplicas são a disponibilidade dos dados e o desempenho das 
aplicações. A localização e manipulação das réplicas de dados devem ser 
transparentes ao usuário. 
Processamento de Consultas Distribuídas: A otimização de consultas em 
um sistema distribuído deve- ser também distribuída, envolvendo normalmente uma 
etapa de otimização global para minimizar o tráfego na rede, seguido das etapas 
seguintes de otimização local em cada sítio envolvido. 
Gerenciamento de Transações Distribuídas: Dois aspectos importantes no 
gerenciamento de uma transação distribuída são o controle de concorrência e o 
controle de recuperação. Em uma transação distribuída, a atomicidade da transação 
deve ser obtida, da mesma forma como ocorre em um sistema centralizado. O método 
geralmente utilizado para manter a integridade dos dados em uma transação 
distribuída é conhecido como Protocolo Bifásico de Confirmação. Os SGBDs 
comerciais, em sua maioria, utilizam o bloqueio de linha para atualizações e, para 
detectar bloqueios mútuos globais, o mecanismo de expiração de tempo. 
Independência de Máquina: Os SGBDD’s utilizados em um sistema de banco 
de dados distribuídos devem suportar qualquer plataforma de hardware, ou seja, o 
fato de rodar em uma ou outra máquina deve ser transparente ao sistema. 
Independência do Sistema Operacional: O sistema operacional que 
executará o SGBDD deve ser transparente ao Sistema de Banco de Dados 
Distribuído. 
Independência de Rede de Comunicação: Topologia da rede, protocolo, 
método de acesso, etc, são tópicos transparentes ao sistema distribuído. O sistema 
de banco de dados distribuído deve rodar em qualquer plataforma de rede. 
Independência de SGBD: A independência de SGBDs em um sistema 
homogêneo é muito fácil de ser alcançada. A interface de acesso padrão utilizada é 
13 
 
 
a lLiguagem SQL, padronizada pela ANSI (American National Standards Institute). Os 
problemas se avolumam quando um banco de dados distribuído é implementado em 
um sistema heterogêneo de SGBDs. Atualmente existem comercialmente SGBDs 
hierárquicos, redes e relacionais. Rodar transações distribuídas envolvendo três 
formas distintas de armazenamento e de estruturação 
 
ARQUITETURA DE REFERÊNCIA PARA UM BANCO DE DADOS 
DISTRIBUÍDO 
 
Como é mostrado na fíg. 2, um banco de dados distribuído, ao ser definido, 
deve possuir os seguintes componentes: Esquema Global, Esquema de 
Fragmentação e Esquema de Alocação, No Esquema Global são descritas todas as 
entidades de dados (relações) e seus relacionamentos. A definição dos dados, em 
um banco de dados distribuído, é feita da mesma forma que em um banco de dados 
centralizado. 
O Esquema de Fragmentação fornece o mapeamento entre relações globais e 
seus respectivos fragmentos. Determina como relações globais são divididas em 
fragmentos verticais, horizontais ou mistos. Desta forma, a conectividade do 
relacionamento entre relações globais e fragmentos é de 1:N. O Esquema de 
Alocação define em que sítio cada fragmento irá residir. Determina de que forma os 
fragmentos são mapeados para alocações físicas. 
Fig. 2 - Representação da arquitetura de um Banco de dados distribuído. 
 
 
14 
 
 
PROJETO DE BANCO DE DADOS DISTRIBUÍDO 
 
A arquitetura de um banco de dados distribuído é constituída de esquema 
conceituai global, esquema de fragmentação, esquema de alocação e o projeto físico 
do banco de dados em cada sítio. No tópico anterior descreveu-se o esquema global, 
esquema de fragmentação e esquema de alocação. No projeto físico mapeia-se o 
esquema conceituai global para áreas de armazenamento permanentes em cada 
sítio. 
Para definir o esquema de fragmentação e alocação deve-se levar em 
consideração requisitos das-aplicações sobre os dados; sítio onde a aplicação é 
usada; freqüência de ativação; número, tipo e distribuição estatística dos acessos 
feitos para cada item de dado requisitado (tupla ou coluna). 
 O Projeto de Banco de Dados Distribuído deve ter como metas: 
 Processamento Local : Deve-se reduzir acessos remotos e simplificar 
os controles dos programas de aplicação. 
 Disponibilidade e Confiabilidade dos Dados Distribuídos : A utilização 
de cópias facilita o acesso em caso de indisponibilidade de um 
determinado sítio e aumenta a confiabilidade do sistema em caso de 
acidentes catastróficos na instalação. Distribuição da Carga de Trabalho : Aproveita a capacidade de cada 
sítio (armazenamento e processamento) e maximiza o nível de 
paralelismo de execução da aplicação. 
 Custo de Armazenamento e disponibilidade : Deve ser analisado em 
cada sítio para se estudar alternativas de alocação e fragmentação. 
Em um projeto de banco de dados distribuído deve-se ter como um dos 
principais objetivos a maximização do processamento local de cada sítio. Existem 
basicamente duas propostas em um projeto de banco de dados distribuído: 
 Top-Down: Geralmente utilizada em bancos de dados distribuídos 
homogêneos. Inicia-se pelo desenho do esquema global, seguido pelo 
esquema de fragmentação e alocação. Este modelo é complementado 
com o projeto físico dos dados alocados em cada sítio. 
15 
 
 
 Bottom-Up: Agrega bancos de dados existentes, integrando existentes 
esquemas de dados em um esquema global. Este modelo possui os 
seguintes requisitos: seleção de um modelo comum de banco de dados 
para escrever o esquema global; tradução de cada esquema local para 
o modelo comum de dados; integração dos esquemas locais para o 
esquema global e resolução de conflitos entre os bancos de dados 
existentes. 
 
PROJETO DE FRAGMENTAÇÃO DE DADOS 
 
O Projeto de Fragmentação de dados é o primeiro problema que deve ser 
resolvido no modelo Top down de distribuição de dados. Este projeto consiste em 
identificar e agrupar tuplas (fragmentação horizontal) ou atributos (fragmentação 
vertical) que tenham a mesma propriedade do ponto de vista de sua alocação. 
 Fragmentação Horizontal: É o particionamento das tuplas de uma 
relação global em subconjuntos disjuntos. A reconstituição da relação 
global se dá através da união de todos os fragmentos. Determinar a 
fragmentação horizontal significa determinar as propriedades lógicas 
dos dados ( predicado de fragmentação) e propriedades estatísticas dos 
dados (números de referências das aplicações para o fragmento). 
 Fragmentação Horizontal Primária: Determinar a fragmentação 
primária de uma relação global consiste na determinação de um 
conjunto disjunto e completo de \predicados de seleçãoj O método para 
realizar esse tipo de fragmentação consiste de 2 passos: 
1) Considera-se um predicado simples pi que particiona as 
tuplas de uma relação global R em 2 partes que são 
referenciadas diferentemente por pelo menos 1 aplicação. 
Seja P=pi, onde P é um conjunto de predicados simples. 
2) Considera-se um novo predicado pi no qual particiona 
pelo menos um fragmento de P em 2 partes que são 
referenciadas em diferentes modos por pelo menos 1 
16 
 
 
aplicação. Seja P <= P upi. Elimina-se os predicados não 
relevantes de P. Repete-se este passo até que o conjunto 
de termos mínimos do fragmento P esteja completo. 
 Fragmentação Horizontal Derivada: A fragmentação horizontal 
derivada de uma relação global R não é baseada em propriedades de 
seus próprios atributos, mas derivada da fragmentação horizontal de 
uma outra relação. 
 Fragmentação Vertical: É o agrupamento de atributos de uma relação 
R. Cada atributo de R deve pertencer a pelo menos 1 fragmento e cada 
fragmento deve incluir um identificador único de tupla ou chave primária. 
A relação global pode ser obtida com a operação de junção dos diversos 
fragmentos. As alternativas para se chegar aos atributos de 
particionamento são: 
a) Divisão: Consiste na divisão progressiva da relação 
global em fragmentos. 
b) Agrupamento: Agregam-se progressivamente os 
atributos para se constituir os fragmentos. 
 Fragmentação Mista: É o particionamento de uma relação global II 
utilizando-se a fragmentação horizontal e vertical. 
 
PROJETO DE REPLICAÇÃO DE DADOS 
 
Em BDDs Relacionais, a realização de replicação de dados se dá.através_.de 
cópias de dados feitas a partir de tabela(s) máster(s). O objetivo principal do uso de 
réplicas é a melhoria de desempenho de acesso aos dados. Quando a cópia é 
somente de leitura recebe o nome de extrato ou snapshot. Quando uma cópia possui 
a característica de poder ser atualizada é denominada somente de réplica. As cópias 
podem ser completas ou parciais. As parciais utilizam o log da tabela máster para 
efetuar as atualizações. 
As cópias extrato podem assumir os seguintes formatos: 
- Simples: Não possui mecanismo automático de atualização da cópia. São 
definidas a partir de comandos DDL ou DML. 
17 
 
 
-Timestamp: A renovação da imagem dos dados é efetuada a partir de 
mecanismo de tempo definido no catálogo. 
- Refreshed: 
Periódico: Vinculada a períodos de tempo para a renovação parcial ou total 
dos dados. 
Imediato: Todas as cópias de uma tabela master são atualizadas no mesmo 
instante da atualização desta. 
As réplicas possuem os seguintes tipos: 
- Periódica: Num primeiro momento é feita uma cópia completa ao sítio 
destino. A partir daí as réplicas já podem sofrer atualizações. As atualizações 
efetuadas nas réplicas são periodicamente transferidas para a tabela. 
- Contínua: Depois de realizada uma cópia completa, esta passa a receber 
atualizações. Cada alteração realizada em uma réplica é imediatamente repassada à 
tabela máster. 
No projeto de replicação de dados, incorporado pelo projeto físico do banco de 
dados distribuído, define-se para cada sítio as réplicas que comporão o banco de 
dados e a forma de atualização. 
 
PROJETO DE ALOCAÇÃO DE DADOS 
 
O Projeto de Alocação de dados tem por objetivo definir as alocações físicas 
dos arquivos do banco de dados distribuído em cada sítio, levando-se em 
consideração a máxima eficiência nas operações de consulta e atualizações dos 
dados. 
O problema de otimizar a alocação dos arquivos nos sítios em um banco de 
dados distribuído tem sido arduamente estudado. Muitas das soluções são muito 
genéricas e complexas para serem usadas em problemas práticos, porque o número 
de parâmetros a ser considerado tende a atingir patamares proibitivos. 
18 
 
 
É estudada a questão de como alocar os dados nos diversos sítios de um 
banco de dados distribuído de forma a tornar a consulta de uma transação o mais 
eficiente possível. São apresentadas as condições básicas para distribuição de dados 
nos aspectos qualitativo e quantitativo deste procedimento 
 
CONTROLE E MONITORAMENTO 
 
Assim como na etapa anterior, esta é também fundamental em qualquer 
processo administrativo. Maximiano (2004) define os meios de controle como 
informações utilizadas para avaliação do grau de cumprimento dos objetivos já 
estabelecidos e da adequação dos cursos de ação escolhidos. 
Mais além, Bateman e Snell (1998, p. 430) definem o controle como “qualquer 
processo que orienta as atividades dos indivíduos na direção da realização das metas 
organizacionais”. Este considera que sem o controle para indicar as atividades 
corretas a ser desempenhadas pelos indivíduos pode ocasionar inconscientemente 
ações capazes de prejudicar a organização. 
Le Breton (1961) afirma que o planejador deve utilizar controles formais ou até 
mesmo auditorias, principalmente em situações nas quais variações significativas não 
podem ser facilmente identificadas. Além disso, o autor ainda ressalta que é 
necessário gastar um tempo considerável, esforço e capital para a criação de um 
sistema de feedback rápido e preciso que demonstre os resultados dos planos atuais. 
Para Stoner e Freeman (1999) os controladores da empresa devem criar um 
sistema capaz de responder se as estratégias estão sendo implementadas conforme 
planejado e se está atingindo os resultados pretendidos. Somente dessa maneira será 
possível verificar o progresso do plano. 
Apesar de o controle ser muitas vezes ignorado é fundamental no processo 
formal de planejamento que é considerado contínuo e repetitivo. Dessa maneira, 
formalizar o controle facilita o monitoramento do desempenho das unidades de 
trabalho de acordo com os objetivos determinadosno início do processo. Sendo 
assim, é importante também se preocupar com a necessidade de realização de 
19 
 
 
ajustes ou ações corretivas que podem ser ocasionados por planos mal formulados 
ou situações que mudaram (BATEMAN E SNELL, 1998) 
 
PAPEL ESTRATÉGICO DAS APLICAÇÕES DE TI 
 
A TI tem desempenhado um importante papel na estratégia de empresas 
líderes nos mercados competitivos, em particular as aplicações de TI, as quais podem 
ser utilizadas para obtenção de vantagem competitiva na cadeia de valor e aumento 
das competências essenciais das organizações (LAURINDO, 2008). Contudo, deve-
se ter em mente que a importância estratégica da TI pode variar de uma indústria 
para outra e também entre empresas de uma mesma indústria, cenário que pode ser 
melhor compreendido por meio dos trabalhos de Porter e Millar (1985) e McFarlan 
(1984). 
De acordo com Porter e Millar (1985), o potencial que a TI tem de impactar a 
cadeia e o sistema de valor de uma organização varia de acordo com a quantidade 
de informação embutida ou requerida por seus processos e produtos, o que pode ser 
visualizado por meio da “Matriz de Intensidade de Informação”. De acordo com essa 
matriz, as aplicações de TI tendem a ser de grande importância para organizações 
cujos produtos e processos contém muita informação, tais como bancos, jornais e 
companhias aéreas. 
Já o “Grid Estratégico” de McFarlan (1984) permite visualizar como a TI está 
relacionada à estratégia e operação do negócio da empresa, focalizando a relação 
entre estratégia de TI e carteira de aplicações. O grid dos impactos estratégicos da 
TI definem quatro regiões principais: 
a) Suporte: as aplicações de TI presentes e futuras possuem pouca 
influência na estratégia da organização; 
b) Fábrica: as aplicações de TI são importantes para o sucesso da 
operação da empresa, mas não há nenhuma aplicação estratégica para 
o futuro; 
20 
 
 
c) Transição: a TI está saindo de uma situação de baixa importância para 
assumir um papel de importância estratégica na organização, em face 
das aplicações de TI planejadas para o futuro; 
d) Estratégico: a TI é muito importante na estratégia atual do negócio e 
as novas aplicações planejadas manterão essa importância estratégica 
no futuro. 
 
ORGANIZAÇÃO E TAREFAS DA EQUIPE DE ADMINISTRAÇÃO 
 
A organização da equipe de administração, no caso distribuído, deve 
acompanhar a própria estratégia de descentralização. Controle centralizado de um 
banco distribuído não faz sentido. Uma organização plausível seria criar uma equipe 
local para cada nó onde o banco reside com autoridade para propor e implementar 
mudanças em detalhe no banco local e nos esquemas externos locais. Haveria ainda 
uma equipe central com autoridade para coordenar e vetar, se necessário, mudanças 
no sistema (a serem implementadas pelas equipes locais). 
As tarefas tradicionais da equipe de administração de um banco de dados 
(centralizado) incluem o projeto lógico e físico do banco e sua documentação, 
definição dos vários esquemas externos em consulta com os analistas de aplicação, 
definição dos critérios de autorização, criação de rotinas de recuperação do banco, 
monitoração da utilização do banco e reestruturação do banco. No caso de bancos 
de dados distribuídos, deve-se acrescentar ainda a tarefa mais geral de garantir a 
cooperação entre os usuários em prol de uma compartilhação efetiva dos dados. 
Três facetas da administração de um BDD merecem especial atenção: 
documentação do banco, administração dos recursos locais de cada sistema e 
monitoração do sistema. (A tarefa básica de projeto lógico e físico do banco já foi 
brevemente abordada na seção anterior). 
A documentação do BDD deve tornar claro a todos os usuários o significado 
dos ítens de dados armazenados pelo banco. Isto requer regras para sistematizar a 
nomenclatura e a descrição informal dos ítens de dados, definição dos tipos de cada 
ítem de dados e regras para traduzir um tipo utilizado em uma máquina para o tipo 
equivalente de outra (e.g., representação e precisão de reais em máquinas 
21 
 
 
diferentes). A administração da carga imposta a cada sistema que compõe o BDD 
exige, antes de mais nada, a definição de critérios de medição. Feito isto, é necessário 
criar regras que assegurem a usuários remotos acesso a recursos locais e que 
atinjam um balanceamento entre a carga local e a imposta por acessos remotos. 
Administração da carga inclui, também, definir como será cobrado aos usuários 
locais e remotos a utilização do sistema. Finalmente, uma vez estabelecidas regras 
para administração do banco, a equipe deverá auditar periodicamente o sistema para 
assegurar a aderência a tais regras. A carga, tempo de resposta e utilização do 
sistema deverá ser constantemente monitorada, prevendo-se reestruturação do 
banco ou mudanças nas regras de administração para corrigir desequilíbrios. 
 
PROBLEMAS QUE AFETAM A ADMINISTRAÇÃO 
 
Os problemas a serem enfrentados pela equipe de administração para atingir 
os seus objetivos podem ser compreendidos considerando-se três cenários básicos 
para um banco de dados distribuído. 
Se o BDD resultou da interligação de sistemas existentes então certamente 
aparecerão problemas devidos a: heterogeneidade do sistema global, introdução de 
padrões globais sem que seja comprometida a autonomia local, critérios de alocação 
de custos tendo em vista acessos locais e remotos, além do balanceamento do tempo 
de resposta de acessos locais e remotos. 
Se o cenário admite a criação de novos bancos locais de forma semi-
autônoma, aparecerão problemas relativos a: definição de regras e responsabilidades 
locais, descrição da semântica dos dados definidos localmente, grau de cooperação 
entre os núcleos locais, principalmente no que se refere à alocação de recursos para 
processamento de acessos remotos. 
Finalmente, em um cenário onde o BDD foi criado pela distribuição em nós 
homogêneos de um sistema centralizado, haverá o problema fundamental de definir 
uma estratégia de distribuição que otimize o tempo de resposta global, sem penalizar 
demasiadamente grupos de usuários. 
22 
 
 
 
REFERENCIAS 
 
ADMINISTRATION oracle7 with distributed option. Belmont,USA : Oracle 
Corporation, 1995. 
 
DB2 family solutions. San José : IBM Corporation, 1994 
 
DB2 for mvs/esa. San José,USA : IBM Corporation, 1994. 
 
BELL, David ; GRIMSOM, Jane. Distributed database systems. 
Workingham,England : Addison-Wesley, 1992. 410 p. 
 
CASANOVA, Marco Antonio. Princípios de sistemas de gerência de banco de 
dados distribuídos. Rio de Janeiro : Campus, 1985. 355 p. 
 
CERI, Stefano ; PELAGATTI, Giusepper. Distributed databases : principles & 
systems. New York : McGraw-Hill, 1992. 410 p. 
 
CERICOLA, Osvaldo Vicente. Banco de dados relacionais e distribuído. Rio de 
Janeiro : Livros Técnicos e Científicos, 1991. p 213-243. 
 
COMITÊ de gestão empresarial. (COGE). Processamento distribuído em 
multiplataforma. Rio de Janeiro : [sn], 1995. 
 
CONGRESSO nacional de novas tecnologias e aplicações em banco de dados. 
7. : 1996 : São Paulo. Pág. 107 
 
DATE, C. J. Introdução a sistemas de banco de dados. Rio de Janeiro : Campos, 
1989. 513 p. 
 
DISTRIBUTED relacional database architecture. San José,USA : IBM 
Corporation, 1995. 477 p. 
 
HOPPER, Teresa (Editor). Distributed relacional database architecture : 
connectivity guide. San José ,USA : IBM Corporation, 1995. 477 p. 
 
MARTIN, James. Strategic data planning methodologies. Savant Research 
Studies,USA, 1980. 275 p. 
 
ORACLE7 for mvs system administration guide. Belmont,USA : Oracle 
Corporation, 1996.