Baixe o app para aproveitar ainda mais
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.
Compartilhar