BANCO

PLANEJAMENTO DE DADOS DISTRIBUÍDOS

ESTRATÉGICO E PORTFÓLIOS EM
T.I
 Faculdade de Minas

SUMÁRIO

DESCRIÇÃO DE BANCOS DE DADOS CENTRALIZADOS ....................................... 4

DESCRIÇÃO DE BANCOS DE DADOS DISTRIBUÍDOS ............................................ 5

BANCO DE DADOS DISTRIBUÍDO .............................................................................. 6

IMPLEMENTAÇÃO ........................................................................................................ 9

PROCESSAMENTO DE CONSULTAS DISTRIBUÍDAS............................................ 10

REQUISITOS FUNCIONAIS DE UM BANCO DE DADOS DISTRIBUÍDO IDEAL ... 12

ARQUITETURA DE REFERÊNCIA PARA UM BANCO DE DADOS DISTRIBUÍDO14

PROJETO DE BANCO DE DADOS DISTRIBUÍDO ................................................... 15

PROJETO DE FRAGMENTAÇÃO DE DADOS .......................................................... 17

PROJETO DE REPLICAÇÃO DE DADOS ................................................................. 18

PROJETO DE ALOCAÇÃO DE DADOS ..................................................................... 19

CONTROLE E MONITORAMENTO ............................................................................ 20

PAPEL ESTRATÉGICO DAS APLICAÇÕES DE TI ................................................... 21

ORGANIZAÇÃO E TAREFAS DA EQUIPE DE ADMINISTRAÇÃO .......................... 22

PROBLEMAS QUE AFETAM A ADMINISTRAÇÃO ................................................... 23

REFERENCIAS ............................................................................................................ 24

2
 Faculdade de Minas

FACUMINAS

A história do Instituto Facuminas, inicia com a realização do sonho de um

grupo de empresários, em atender a crescente demanda de alunos para cursos de
Graduação e Pós-Graduação. Com isso foi criado a Facuminas, como entidade
oferecendo serviços educacionais em nível superior.

A Facuminas 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
 Faculdade de Minas

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,

4
 Faculdade de Minas

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.

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.

5
 Faculdade de Minas

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 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. Em um sistema de banco de dados distribuído, o banco de
dados é armazenadoem 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.

6
 Faculdade de Minas

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.

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

7
 Faculdade de Minas

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.

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

8
 Faculdade de Minas

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:

 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

9
 Faculdade de Minas

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
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.

10
 Faculdade de Minas

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á.
 Consistência: A execução de uma transação isolada preserva a
consistência do banco de dados.
 Isolamento: Cada transaçã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

11
 Faculdade de Minas

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 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.

12
 Faculdade de Minas

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 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.

13
 Faculdade de Minas

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 é
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

14
 Faculdade de Minas

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.

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 é

15
 Faculdade de Minas

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.
 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.

16
 Faculdade de Minas

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
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.

17
 Faculdade de Minas

 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.

-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.

18
 Faculdade de Minas

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.

É 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

19
 Faculdade de Minas

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 determinados no início do processo. Sendo
assim, é importante também se preocupar com a necessidade de realização de
ajustes ou ações corretivas que podem ser ocasionados por planos mal formulados
ou situações que mudaram (BATEMAN E SNELL, 1998)

20
 Faculdade de Minas

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;
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;

21
 Faculdade de Minas

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
diferentes). A administração da carga imposta a cada sistema que compõe o BDD

22
 Faculdade de Minas

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

23
 Faculdade de Minas

uma estratégia de distribuição que otimize o tempo de resposta global, sem

penalizar demasiadamente grupos de usuários.

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.

24