CAPÍTULO 2. BANCOS DE DADOS DISTRIBUÍDOS Este capítulo inicia com uma proposta para estruturação da descrição de bancos de dados distribuídos, que estende aquela sugerida pela ANSI/SPARC os centralizados. Em seguida, os problemas de projeto e administração de um banco de dados distribuído são discutidos. 2.1 ESPECIFICAÇÃO DE BANCOS DE DADOS DISTRIBUÍDOS A forma usual adotada para descrição de bancos de dados centralizados é inicialmente apresentada e, em seguida, estendida para bancos distribuídos. Um pequeno exemplo da descrição de um banco de dados distribuído completa a seção. 2.1.1 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 (vide Figura 2.1). 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. s 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. s externos também são úteis como uma forma de restringir o acesso a dados classificados por parte de grupos de usuários. - 1 -
Interno Figura 2.1 - Um Banco de Dados Centralizado 2.1.2 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, é apresentada a seguir (vide Figura 2.2). 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. - 2 -
Global Global Global Interno Interno Figura 2.2 - Um Banco de Dados Distribuído 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 (ver Figura 2.3). 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 esquemas externos globais esquemas conceituais locais esquemas externos locais no modelo de dados pivot; 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; no modelo de dados local; no modelo de dados local. - 3 -
Interno Figura 2.3 - Um Banco de Dados 2.1.3 Um Exemplo da Descrição de Bancos de Dados Distribuídos O banco de dados usado como exemplo refere-se a fornecedores, com número, nome e cidade-sede; peças, com código e nome; e fornecimentos relacionando um fornecedor a cada peça que fornece e indicando a quantidade fornecida. Assumindo que o banco é descrito no modelo relacional, o esquema conceitual seria: Global FORNECEDORES [ NUMERO,NOME,SEDE ] PECAS [ CODIGO,NOME,COR,PESO ] FORNECIMENTO [ NUMERO,CODIGO,QUANTIDADE ] Poderíamos definir dois esquemas externos globais da seguinte forma: Global A: de relação: FORN_PECA [ NUMERO,CODIGO,NOME ] Definição: FORN_PECA = (FORNECIMENTO * PECAS) [ NUMERO,CODIGO,NOME ] - 4 -
Global B: de relação: FORN_PECA [ NUMERO,CODIGO ] Definição: FORN_PECA = FORNECIMENTO [ NUMERO,CODIGO ] Nota: Álgebra relacional será usada para indicar mapeamentos neste exemplo; a operação de junção natural será indicada pelo símbolo '*' e as operações de projeção e seleção serão denotadas da forma usual, ou seja, R[X] indicará a projeção de R na lista de atributos X e R[B], onde B é uma qualificação, indicará uma seleção das tuplas de R que satisfazem B. Assumindo que o sistema é homogêneo e distribuído em apenas dois nós, os esquemas conceituais locais e a distribuição do esquema conceitual global seriam então descritos da forma abaixo (o primeiro nó conterá todos os fornecedores com sede em Passa Três, todos os fornecimentos em que estão envolvidos e o nome e código das peças; o segundo nó conterá o resto dos fornecedores e seus fornecimentos, além do código, cor e peso das peças. s Conceituais Locais: Primeiro Nó: Segundo Nó: FORNECEDORES1 [ NUMERO,NOME,SEDE ] PECAS1 [ CODIGO,NOME ] FORNECIMENTO1 [ NUMERO,CODIGO,QUANTIDADE ] FORNECEDORES2 [ NUMERO,NOME,SEDE ] PECAS2 [ CODIGO,COR,PESO ] FORNECIMENTO2 [ NUMERO,CODIGO,QUANTIDADE ] Mapeamentos Definindo o Critério de Distribuição: Primeiro Nó: Segundo Nó: FORNECEDORES1 = FORNECEDORES [ SEDE='PASSA TRES' ] PECAS1 = PECAS [ CODIGO,NOME ] FORNECIMENTO1 = FORNECIMENTO * (FORNECEDORES1 [ NUMERO] FORNECEDORES2 = FORNECEDORES [ SEDE 'PASSA TRES' ] FORNECIMENTO2 = FORNECIMENTO * (FORNECEDORES2 [ NUMERO] PECAS2 = PECAS [ CODIGO,COR,PESO ] Como os esquemas internos locais dependem do SGBD local em questão, não faz sentido apresentá-los aqui. s externos locais também são omitidos. - 5 -
2.2 PROJETO DE BANCOS DE DADOS DISTRIBUÍDOS A breve discussão sobre o projeto de bancos de dados distribuídos apresentada nesta seção baseia-se em certas observações simples. Em primeiro lugar, o projeto do esquema conceitual global e o dos esquemas externos globais é inteiramente semelhante ao caso centralizado, já que o banco de dados distribuído deverá se comportar como centralizado perante os usuários globais. Além disto, o projeto dos esquemas internos locais é também idêntico ao de bancos centralizados, exceto que a carga imposta por acessos remotos aos dados locais também deve ser levada em consideração. Portanto, o problema básico de projeto de bancos de dados distribuídos reside no projeto dos esquemas conceituais locais, pois estes refletem a estratégia de distribuição do banco. As estratégias de distribuição são classificadas em particionamento e replicação. Seja D uma estrutura (lógica) de dados do esquema conceitual global. Dizemos que D é particionada verticalmente (ou estruturalmente) quando D é mapeada em duas ou mais estruturas (lógicas) de dados que não são idênticas a D e que pertencem a diferentes esquemas conceituais locais. Dizemos que D é particionada horizontalmente (ou particionada por ocorrência) quando D é mapeada em estruturas idênticas a D e pertencentes a dois ou mais esquemas conceituais locais de tal forma que o mapeamento define um particionamento (no sentido matemático) do conjunto de dados associado a D. No exemplo da seção anterior, FORNECEDORES foi particionada horizontalmente em FORNECEDORES1 e FORNECEDORES2, o mesmo acontecendo com FORNECIMENTO. Já PECAS foi particionada verticalmente em PECAS1 e PECAS2. Dizemos que D é replicada quando D é mapeada em duas ou mais estruturas (lógicas) de dados idênticas a D e pertencentes a diferentes esquemas conceituais locais de tal forma que o apeamento de D em cada uma destas estruturas é sempre a identidade. Ou seja, existirão cópias idênticas do conjunto de dados associado a D armazenadas em dois ou mais nós. A replicação é total quando cada banco de dados local contém uma cópia completa do banco. Caso contrário a replicação é parcial. A escolha da estratégia de distribuição do banco exige cuidados especiais pois se vier a gerar um tráfego de dados exagerado entre os vários nós, o custo de comunicação tornará o projeto anti-econômico. Inicialmente, deve-se verificar se a solução distribuída é de fato uma opção viável. Isto significa, essencialmente, detetar se o banco é fortemente integrado, ou se pode ser dividido em partes mais ou menos independentes; se este for o caso, deve-se então determinar qual a vantagem de descentralizar o banco. Um estudo do perfil da população de transações existentes no sistema centralizado em uso (se este for o caso) deverá ser feito, tentando determinar se é possível dividir o sistema - banco de dados e transações - em subsistemas mais ou menos independentes. Se este for o caso, o custo de transmissão de dados deverá ser reduzido, descentralizando-se o banco e suas funções. Acessos que cortem fronteiras geográficas ainda serão suportados, desde que não sejam muito freqüentes. Uma vez identificado que a solução distribuída é viável, deve-se escolher a técnica de distribuição, levando-se em conta os seguintes fatores: um BDD particionado não fica limitado à memória secundária disponível localmente e, comparativamente a uma solução centralizada (com acesso distribuído), aumenta a confiabilidade e eficiência do sistema, se há um alto grau de localidade de referência; - 6 -
um BDD replicado aumenta a confiabilidade, disponibilidade e pode aumentar a rapidez do sistema, mas por outro lado cria problemas de propagação de atualizações nos dados e exige mais memória secundária local. Naturalmente, o grau de replicação do BDD traduz um compromisso entre o custo de acesso a dados remotos e o custo de atualizar cópias múltiplas. Um resumo desta discussão encontra-se na tabela abaixo: RESUMO DAS ESTRATÉGIAS DE DISTRIBUIÇÃO % de Exceções Tamanho do Arquivo Método de Distribuição -- pequena alta pequeno grande grande replicação particionamento centralizado Nota: percentagem de exceções refere-se à freqüência com que uma transação necessita de dados que não estão armazenados localmente. Por fim, considerações envolvendo "hardware" devem ser mencionadas com relação ao projeto de BDDs. A análise do equipamento necessário deverá responder, pelo menos, às seguintes perguntas: Que processadores existem na organização (ou precisam ser adquiridos)? Qual a configuração mínima dos processadores para suportar o SGBDD? Que periféricos são necessários? Que equipamentos de comunicação de dados são necessário para interligar os processadores? Isto encerra a nossa breve discussão sobre projeto de BDDs. 2.3 ADMINISTRAÇÃO DE BANCOS DE DADOS DISTRIBUÍDOS Nesta seção são abordados os problemas, as tarefas e a organização da equipe de administração de um banco de dadosdistribuído. 2.3.1 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. - 7 -
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 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. 2.3.2 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. NOTAS BIBLIOGRÁFICAS O relatório do CODASYL Systems Commitee [1982] discute extensivamente as principais características, formas de organização, problemas de administração, etc. de BDDs. Gross et all. [1980] contém uma discussão interessante dos problemas de administração. Champine [1978] apresenta vários exemplos de BDDs. Shertock [1982] descreve o esforço da Philips do Brasil na área de sistemas distribuídos. Schreiber, Baldissera e Ceri [1980] aborda, de um ponto de vista genérico, aplicações de BDDs. O problema de alocação de arquivos em um - 8 -
sistema distribuído, assunto abordado muito superficialmente neste capítulo, é de primordial importância no projeto de BDDs. Este problema é bastante semelhante ao problema clássico de transporte em Pesquisa Operacional. Downy e Foster [1982] resume os principais modelos e soluções desenvolvidos para o problema de alocação de arquivos e Wah [1984] contém uma introdução bastante interessante sobre o problema. Apers [1983] contém uma discussão longa sobre o problema de alocação de arquivos em bancos de dados distribuídos. - 9 -