Desenvolvimento de Sistema de Distribuição de Bases de Dados

IV Congresso Brasileiro de Computação – CBComp 2004
Banco de Dados
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.
C
I. INTRODUÇÃO
OMO destaca [1], uma das motivações importantes por
trá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
IV Congresso Brasileiro de Computação – CBComp 2004
Banco de Dados
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ão1 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
IV Congresso Brasileiro de Computação – CBComp 2004
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.
Banco de Dados
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
IV Congresso Brasileiro de Computação – CBComp 2004
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
Banco de Dados
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
IV Congresso Brasileiro de Computação – CBComp 2004
a base de dados local.
B. Criação do log de modificações
Durante a configuração do DDM, o sistema gera triggers2
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
Banco de Dados
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]
[2]
[3]
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.
[4]
Korth, Henry F; Silberschatz, Abraham; Sudarshan, S. Sistemas de
Banco de Dados. São Paulo : MAKRON Books, 1999.
Özsu, M. Tamer; Valdurez, Patrick. Principio de Sistemas de Bancos de
Dados Distribuídos. Rio de Janeiro: Campus, 2001.
Bernstein, Philip; Goodman, Nathan. Concurrency Control in Database
Systems. ACM computing Surveys, vol. 13 (2), pp.185-221, June, 1981.
Kirtland, Mary Projetando Soluções Baseadas em Componentes. Rio de
Janeiro: Campus, 2000.
51
IV Congresso Brasileiro de Computação – CBComp 2004
Banco de Dados
[5]
Engler, Eric. Embeded and Delphi Zip. [online] Disponível em
http://www.geocities.com/SiliconValley/Network/2114/.
[6] Ribeiro, Elivaldo S. TCF Library [online] Disponível em
http://www.elivaldo.com.br.
[7] PSmi. Beehive
Replicator
Agent
Disponível
em
http://www.beehive.com.br/replicator.html.
[8] DBMaster, DBReplicator - A Solução definitiva. Disponível em:
http://www.dbmaster.com.br/dbreplicator.html
[9] Advancedit S/A, Dinamic 2.6.0.0 – Manual de Usuário, Porto Alegre:
sem editora, 2003.
[10] Papakonstantinou, Yannis; Vassalos, Vasilis. “The Enosys Markets data
integration platform: lessons from the trenches” in Proc. 2001 Conf. On
Information and Knowledge Management, pp. 538-540
[11] Petrou, C. ; Hadjiefthymiades, S.; Martakos, D. An XML-Based, 3-Tier
Scheme for Integrating Heterogeneous Information Sources to the
WWW. In Proc. 1999 of 10th International Workshop on Database
& Expert Systems Applications. pp. 706-712.
Rene Eduardo Mesquita Melo nasceu em Torres, em
03 de Novembro de 1976. 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 é [email protected].
Miguel Rodrigues Fornari nasceu em Porto Alegre,
em 29 de Setembro de 1967. 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 é [email protected].
52