Desenvolvimento de Sistema de Distribuição de Bases de Dados Heterogêneas

Transcrição

1 Desenvolvimento de Sistema de Distribuição de Bases de Dados Heterogêneas R.E.M. Melo e M.R. Fornari, IEEE Member Abstract-- This work describes the development of a data distribution system. The main goal is produce a flexible and easy to use software, that allows data exchange between heterogeneous databases off-line. Some offices or shops are located in regions without good coverage of communications line, or, the price is very expensive to obtain a good quality of service. So, the system implement some facilities for off-line distributed transaction, all data are transmitted using cryptography, and, to supports heterogeneity, uses XML documents. Palavras chaves Sistemas de banco de dados distribuídos, Gerência de dados. I. INTRODUÇÃO OMO destaca [1], uma das motivações importantes por Ctrás do uso de sistemas de banco de dados é o desejo de integrar os dados operacionais de um empreendimento e proporcionar acesso controlado a esses dados. Sistemas de informação de empresas, tipicamente, mantêm os dados em um Sistema Gerenciador de Bancos de Dados (SGBD), que passam a representar um papel essencial para o funcionamento de toda empresa, pelas diversas facilidades que agrega. Um SGBD Distribuído (SGBDD) é um conjunto de banco de dados independentes, que interagem para alcançar determinado objetivo [2]. Cada banco de dados pode estar em um servidor diferente, localizado a grande distância dos demais. Estes servidores se conectam através de uma rede de comunicação de dados. Se os bancos de dados forem de diferentes fabricantes, teremos heterogeneidade quanto aos SGBD utilizados. Empresas com uma sede matriz e filiais em diferentes cidades podem se beneficiar da tecnologia de SGBDD, como Oracle ou IBM DB2. Porém, estas requerem altos investimentos e linhas de comunicação rápidas. Tratando-se de empresas pequenas, ou filiais com pouco movimento, talvez localizadas em cidades sem linhas digitais de comunicação, os custos envolvidos tornam-se muito elevados. O Data Distribution Manager (DDM) é uma solução que resolve este problema, viabilizando a descentralização dos sistemas de banco de dados, mantendo a integração das informações em um ou mais pontos da empresa. É um sistema com capacidade de integrar ambientes heterogêneos de forma assíncrona, com o objetivo de dispensar o investimento em sistemas de banco de dados de alto desempenho para pontos de presença que não compatibilizam investimentos elevados. A solução baseia-se em um protocolo de comunicação de controle e dados desenvolvido totalmente em XML, o que o torna independente de qualquer SGBD comercial. Assim, é possível que na matriz haja um SGBD de maior capacidade, como Oracle e IBM DB2, e, nas filiais, SGBD mais simples ou gratuitos, como MS Access, Firebird ou MySQL. Permite, também, a comunicação assíncrona de dados, viabilizando sua utilização em linhas discadas. Por segurança e para reduzir a quantidade de dados transmitidos, toda informação é criptografada. O trabalho esta assim organizado: no capítulo 2 estão descritas as principais funcionalidades do DDM. No terceiro capítulo, alguns pontos relativos a sua implementação são discutidos e, no quarto capítulo, as conclusões do trabalho. II. FUNCIONAMENTO DO SISTEMA O sistema foi concebido a partir de uma parceria da universidade com uma empresa especializada em software para transportadoras, mas é capaz de atender a empresas de outros ramos de atividade. Ele deve permitir a integração de bases de dados heterogêneas, com baixo custo de implantação e manutenção. A. Configuração do DDM Para a utilização do sistema, o passo inicial é o cadastramento dos servidores que estão interligados. Em cada servidor pode haver uma ou mais bases de dados. Em qualquer momento, novos servidores ou bases de dados podem ser acrescentadas ao sistema. A figura 1 mostra a tela principal de configuração do DDM. Na área 1 estão listados os servidores, bases de dados e grupos de distribuição (que serão explicados a seguir). Na área dois estão detalhadas as propriedades dos servidores. O conteúdo da área 2 é alterado de acordo com o objeto selecionado na área 1. Um dos servidores que executa o aplicativo deve ser o responsável pelas informações de configuração de todos os demais. Todas as informações, como servidor primário (servidor de origem dos dados), servidores secundários (servidores destinatários dos dados), bancos de dados distribuídos, tabelas distribuídas e regras da distribuição, devem ser mantidas neste servidor. Estas informações são armazenadas em documentos XML. 47

2 Fig. 1. Tela principal de configuração do sistema Para cada aplicação diferente da empresa é possível criar um grupo de servidores que podem receber e enviar dados, pela criação de um grupo de distribuição. Um mesmo servidor pode participar de vários grupos. É necessário definir qual dos bancos de dados é o primário da distribuição. O banco primário é responsável em receber os pacotes de dados de todos os integrantes do grupo e distribuir as informações conforme as regras definidas. Por exemplo, a aplicação de controle de transporte de cargas deve estar disponível em todos depósitos e lojas da empresa, bem como seus dados. O controle de vendas só é necessário nos pontos de atendimento a clientes. Um dos servidores do grupo é a base de dados distribuidora das informações. Ele é o responsável em receber, processar, filtrar e redistribuir para todos membros do grupo, as informações processadas, exceto para o servidor que originou a operação. A distribuição é realizada através de regras cadastradas para cada grupo de distribuição. Estas regras devem ser montadas considerando a estrutura das tabelas. É obrigatória a definição de uma ou mais tabelas como sendo tabelas primárias de distribuição. A tabela primária deve conter, obrigatoriamente, algum atributo de localidade, porque a distribuição de dados é realizada pelo critério de proximidade geográfica, pois os dados referentes a um local são mais acessados em locais próximos. Por exemplo, mais de 98% das transações bancárias são realizadas na cidade onde esta localizada a agência a qual a conta pertence. Este critério é fundamental para reduzir os custos de transmissão. O servidor é definido através de um conjunto de predicados, que são associados aos destinos. A tabela Filiais é a primária na aplicação de controle de vendas, uma vez que as vendas são originadas em uma determinada filial e contem um atributo de referência geográfica, o atributo Cidade. Assim, com base no valor do atributo Cidade, pode-se definir a distribuição de dados com regras como se Cidade=Viamão 1 então enviar tuplas para o servidor de Porto Alegre. Para cada valor possível do atributo, um servidor deve ser especificado. Um servidor pode ser indicado para vários valores diferentes do atributo. Para tabelas secundárias, distribuídas por derivação, as regras de distribuição devem se basear em junções com a tabela primária por chave estrangeira, para que o sistema consiga definir o destino das informações do banco de dados que sofreram operações (insert, update e delete). A tabela Clientes é particionada a partir da tabela Filiais, já que, para cada cliente, apenas a filial local necessita de suas informações. Nesta tabela o atributo Filial é chave estrangeira, relacionando-a a tabela Filiais. Para cada grupo de distribuição, é necessário decidir como é realizada a atualização de dados. As opções são: (1) apenas o servidor primário atualiza dados, que são repassados para os secundários. Nesta situação, as bases 1 A cidade de Viamão esta localizada na Grande Porto Alegre. 48

3 secundárias mantêm uma cópia local, aumentando a disponibilidade do sistema e a velocidade de processamento. Tipicamente, tabelas primárias fazem uso desta alternativa. Trata-se de replicação simples de dados. (2) cada servidor secundário pode atualizar os dados que mantêm, que são repassados apenas para o servidor primário. Este é o único que possui todas as tuplas pertencentes a tabela. Neste caso, é fundamental que ao definir as regras de distribuição seja garantida a propriedade de disjunção, ou seja, nenhuma tupla pode ser mantida em mais de um servidor. Caso contrário, pode haver problemas de coerência e perda de informações, com dois servidores modificando a mesma informação, de maneiras diferentes. O DDM não garante a propriedade de disjunção, nem a coerência dos dados caso ela não seja estabelecida pelo usuário. Esta alternativa chama-se particionamento horizontal [3]. (3) todas as tuplas da tabela são mantidas em todos servidores, porém, as regras de distribuição estabelecem o subconjunto de tuplas que cada servidor pode alterar. Os subconjuntos, neste caso, também devem ser disjuntos. Este é um particionamento horizontal com replicação total. A figura 2 ilustra um conjunto de regras de distribuição. A tabela primária é Filiais, as tabelas Clientes e Produtos são derivadas, e a tabela Contatos é derivada de Clientes, criando um nível de indireção em relação à tabela primária. A tabela Estoque é derivada de Produtos. Há uma interface gráfica para criar estas regras, que garante a correção sintática das regras. remotamente, desde a matriz da empresa. Usuários locais podem acionar o envio e recepção de dados e verificar o andamento das mesmas. B. Transmissão de Dados Uma vez em funcionamento, o DDM monitora o funcionamento da base de dados, mantendo um log de modificações ocorridas em todas as tabelas distribuídas. Quando desejado, o usuário pode iniciar a transmissão de dados. O primeiro passo é transformar os logs de modificações em documentos XML. A fim de reduzir o tamanho dos documentos de dados, todos são divididos em pacotes, que são compactados. Antes de serem submetidos a compactação, todos pacotes são criptografados, para garantir a confiabilidade das informações na rede. A criptografia baseiase em uma chave de 128 bits, cujo método de geração esta embutido dentro do software. Os pacotes de dados são armazenados em um servidor de arquivos de transferência (FTP), e, posteriormente, serão lidos pelos servidores destinos. A figura mostra o acompanhamento da transmissão de vários documentos XML, cada um deles relativos a configuração do DDM ou uma tabela de dados que deve ser distribuída. Fig. 3. Acompanhamento da transmissão de documentos XML. Fig. 2. Regras de distribuição definidas no DDM A configuração do DDM é completada com a indicação do servidor de transferência de arquivos (FTP) a ser utilizado. Esta opção permite que dados sejam depositados nele a partir de qualquer servidor, a qualquer momento, e lidos por outros servidores quando estes estabelecerem a conexão. Não é necessário conexão ponto-a-ponto entre servidores, nem linhas de dados permanentes. O DDM possui ainda um controle de usuários. Todas operações de configuração são realizadas em um nível privilegiado e a partir de um único local. Esta restrição se adequa com as finalidades do sistema, uma vez que não se espera que haja profissionais especializados em cada localidade. Uma vez instalado, a configuração pode ser feita Ao receber um pacote de dados, o servidor deve descompactar e descriptografar o conteúdo. Para recompor o documento XML, deve receber todos os pacotes que o compõem. Quando o documento estiver completo, as modificações indicadas são realizadas na base de dados local. Obviamente, estas modificações não são copiadas para o log, pois não há necessidade de serem refeitas novamente. Quando o processo é completado com sucesso, o servidor que originou os dados é avisado. Em caso de falha de comunicação, o servidor destino tenta um novo acesso ao servidor de FTP. Os pacotes e documentos são numerados, de modo que a ordem entre eles não seja perdida. Modificações de um certo documento só são aplicadas se todas as modificações indicadas em documentos de número inferior já estiverem sido realizadas com sucesso, mantendo a coerência de dados. 49

4 Fig. 4. Principais componentes da arquitetura do sistema. III. IMPLEMENTAÇÃO DO SISTEMA O sistema foi desenvolvido na linguagem de programação ObjectPascal e compilado em Borland Delphi 7. Este é um ambiente de programação RAD (Rapid Application Development), composto de vários componentes. Componentes são classes programadas com atributos e métodos, feitos para um devido fim [4]. Eles ajudam os programadores na hora de desenvolver seus programas, pois. reúnem em seu código métodos que são reutilizados, diminuindo o tempo de programação. Os componentes mais significativos utilizados neste software são: SQLConnection: É um componente nativo do Delphi, que representa a conexão ao banco de dados do dbexpress. Sua conexão ao banco de dados pode ser compartilhada por muitos componentes que fazem a manipulação dos dados. Por sua vez dbexpress é um drive de acesso a banco de dados, desenvolvido pela Borland, capaz de se conectar com uma lista grande de SGBD comericais e não-comerciais. SimpleDataset: É um cliente de banco de dados, de uma série de componentes da Borland, que usa o SQLConnection como conexão. Componente nativo do Delphi, combina acesso rápido e distribuição fácil de uma série de dados unidirecional com a habilidade de edição e navegação. É capaz de salvar uma seleção de dados em formato XML, e, também, carregar documentos XML salvos por ele. Com o componente é possível determinar os atributos da estrutura do documento, como nome, tipo e tamanho, muito semelhante a uma tabela de banco de dados. ZipMaster: É um componente de compactação de arquivos compatível com o formato ZIP [5]. É uma interface usada como ponte para o uso dos arquivos no formato DLL, desenvolvidas por Eric Engler, que detêm os procedimentos compactação e descompactação. O uso das DDLs é livre. EvFileCripto: É um componente destinado a criptografar e descriptografar arquivos. Usado para manter as informações dos documentos XML seguros, o componente é simples na implementação, dando facilidade ao programador na hora de desenvolver as rotinas de criptografia. O componente compõe a TCF Library Additional [6] e deve ser adquirido em separado. A. Arquitetura do Sistema A arquitetura do sistema pode ser visualizada na figura 4. O sistema é composto por quatro tipos diferentes de servidores, ilustrando os papéis que existem no sistema, como mostrado. Isto não significa que um mesmo computador não possa exercer dois papéis diferentes, como Administrador e Primário. E o fato de ser servidor primário de um grupo de distribuição, não obriga a sê-lo em outros grupos. Assim, um computador pode ser o primário de um grupo e secundário em outro grupo de distribuição. Da mesma forma, qualquer um pode exercer o papel de servidor de FTP. Também, alguns SGBD estão citados, mas é possível suportar outros produtos. O sistema esta dividido em dois programas executáveis: Transmit, responsável pela gerência de comunicação de dados e DDM, que é a interface com o usuário e a comunicação com 50

5 a base de dados local. B. Criação do log de modificações Durante a configuração do DDM, o sistema gera triggers 2 na base de dados para cada tabela que deve ser distribuída. Estes triggers são associados aos eventos de modificação da tabela (insert, update e delete). O log de modificações é mantido em uma tabela chamada DDMDistribution. Para cada tupla é gravada o valor de sua chave primária, um indicador da operação e o timestamp da operação. Devido às diferenças entre os SGBD, para cada produto específico, novas classes devem ser implementadas. Isto ocorre não apenas porque alguns produtos não seguem rigorosamente o padrão da linguagem SQL vigente, mas também porque o padrão é omisso em alguns pontos. Por exemplo, nada é dito sobre a estrutura do Dicionário de Dados do SGBD, que é um ponto crítico para o DDM. C. Algoritmo de Geração de Dados O algoritmo de geração de dados inicia identificando o servidor e a base de dados local. Para cada tupla na tabela DDMDistribution, verifica as regras de distribuição que se aplicam e o servidor de destino. Para cada servidor de destino, um documento XML diferente é gerado e a tupla acrescentada ao respectivo documento. Tuplas de diferentes tabelas são colocadas em diferentes documentos, para um mesmo servidor de destino. Um documento de índice é gerado para controlar todo processo. Após, os documentos são criptografados, compactados e enviados. A figura 5 ilustra esta seqüência. Fig. 5. Sequencia de geração de dados para distribuição. D. Algoritmo de Recepção de Dados O algoritmo de recepção de dados também inicia identificando o servidor local e suas bases de dados. Para cada servidor dos quais pode receber informações, o DDM busca todos arquivos armazenados no servidor de FTP, endereçados para si. Cada arquivo recebido é descompactado e descriptografado. Cada tupla de um arquivo é processada adequadamente. Há três situações possíveis: inserção, modificação de valores de atributos e remoção da tupla. A ordem em que as tuplas são 2 Para o MSAccess, a criação de triggers é substituída adequadamente por procedimentos em Visual Basic for Applications, associados a eventos de tabela. Esta é uma solução que atende às necessidades do DDM, mas não é portável. processadas é determinada pelo timestamp da operação. Um documento XML é criado com o status de cada operação. Ao final do processo, este arquivo é enviado para o respectivo servidor de origem dos dados. A figura 6 mostra a seqüência de processamento na recepção de dados. Fig. 6. Processamento na recepção de dados. IV. CONCLUSÃO O DDM atingiu seus objetivos principais, ao permitir a distribuição de dados em empresas com SGBDD heterogêneo, com segurança e baixo custo, sem a necessidade de linhas de dados dedicadas. Já esta sendo utilizada por uma transportadora de cargas, com sucesso. Trata-se de uma parceria universidade-empresa que utiliza tecnologias inovadoras, para buscar uma solução que satisfaça a necessidade dos usuários. Além das características técnicas, o projeto da interface gráfica tem contribuído bastante. Um fator decisivo foi aquisição de ícones desenhados por um designer gráfico especializado nesta tarefa. Em termos de mercado, há três outros produtos com características semelhantes. O Beehive Replicator Agent [7] é voltado exclusivamente para a replicação de dados, suportando atualização apenas no servidor primário. O DBReplicator [8] e o Dinamic [9] não dão suporte a outras plataformas além do Oracle, não atendendo a um requisito básico do projeto. Na literatura científica, o Sistema Enosys [10] integra fontes heterogêneas de dados, sem a necessidade de compartilharem uma mesma estrutura de tabelas e atributos, como o DDM. Também integrando documentos textos, especialmente em HTML, e bases de dados relacionais, há o sistema proposto em [11]. Porém, esta não é uma característica necessária para o DDM, embora algumas idéias presentes nestes trabalhos tenham sido úteis para nós. Na continuidade do projeto, propõe-se validar a propriedade de disjunção das regras de distribuição e torná-lo multiplataforma, utilizando Java. V. REFERENCIAS [1] Korth, Henry F; Silberschatz, Abraham; Sudarshan, S. Sistemas de. São Paulo : MAKRON Books, [2] Özsu, M. Tamer; Valdurez, Patrick. Principio de Sistemas de Bancos de Dados Distribuídos. Rio de Janeiro: Campus, [3] Bernstein, Philip; Goodman, Nathan. Concurrency Control in Database Systems. ACM computing Surveys, vol. 13 (2), pp , June, [4] Kirtland, Mary Projetando Soluções Baseadas em Componentes. Rio de Janeiro: Campus,

6 [5] Engler, Eric. Embeded and Delphi Zip. [online] Disponível em [6] Ribeiro, Elivaldo S. TCF Library [online] Disponível em [7] PSmi. Beehive Replicator Agent Disponível em [8] DBMaster, DBReplicator - A Solução definitiva. Disponível em: [9] Advancedit S/A, Dinamic Manual de Usuário, Porto Alegre: sem editora, [10] Papakonstantinou, Yannis; Vassalos, Vasilis. The Enosys Markets data integration platform: lessons from the trenches in Proc Conf. On Information and Knowledge Management, pp [11] Petrou, C. ; Hadjiefthymiades, S.; Martakos, D. An XML-Based, 3-Tier Scheme for Integrating Heterogeneous Information Sources to the WWW. In Proc of 10th International Workshop on Database & Expert Systems Applications. pp Rene Eduardo Mesquita Melo nasceu em Torres, em 03 de Novembro de Graduou-se no Curso Superior em Tecnologia de Informática, na Universidade Luterana do Brasil (ULBRA)., onde desenvolveu atividades de pesquisa na área de Bancos de Dados Distribuídos. Atualmente é Gerente de TI na Modular Transportes e Analista de Sistemas na Reel Informática Ltda. Seus interesses principais são na área de banco de dados distribuídos e desenvolvimento de sistemas. Seu endereço eletrônico é melo@reel.com.br. Miguel Rodrigues Fornari nasceu em Porto Alegre, em 29 de Setembro de Gradou-se em Ciências da Computação pela Universidade Federal do Rio Grande do Sul (UFRGS), onde também realizou o curso de mestrado. Atualmente é professor da Faculdade de Informática, na Universidade Luterana do Brasil (ULBRA), onde leciona disciplinas na área e Bancos de Dados. Também esta realizando doutorado em Sistemas de Informação Geográfica, na UFRGS. Seu interesses principais são na área de desempenho de banco de dados e distribuição de dados. Seu endereço eletrônico é fornari@ieee.org. 52