Software para Sincronização de Estruturas de Bancos de Dados

Software para Sincronização de Estruturas de Bancos de Dados Eduardo Carneiro Felippetto Faculdade de Informática - Centro Universitário Ritter dos Reis (Uniritter) Porto Alegre RS Brasil ecfelippetto@gmail.com Resumo. Este trabalho insere-se em um contexto onde uma determinada aplicação é utilizada por vários clientes, cada um com seu próprio banco de dados. A manutenção e a customização desta aplicação podem requerer a trabalhosa e arriscada tarefa de alterar o esquema de cada banco de dados separadamente. Este artigo aborda o desenvolvimento de um protótipo de software para sincronização de estruturas de bancos de dados. Diferente de soluções disponíveis comercialmente, o protótipo proposto neste artigo realiza a sincronização de quantas estruturas de bancos de dados Microsoft SQL Server 2005 forem necessárias por vez. Para tanto, utiliza-se a linguagem de programação Microsoft C#.Net com o auxílio da biblioteca SMO da Microsoft Corporation. Abstract. This work is in a context where a particular application is used by multiple clients, each one with its own database. Maintenance and customization of this application may require the laborious and risky task of changing the schema of each database separately. This paper discusses the development of a prototype software for synchronization of databases structures. Unlike commercially available solutions, the prototype proposed in this paper performs the synchronization of many structures databases Microsoft SQL Server 2005 are required at a time. To this end, the programming language Microsoft C#.Net with the benefits of the Microsoft Corporation SMO library is used. 1. Introdução No atual contexto empresarial, observa-se uma grande volubilidade em processos de negócio e nos sistemas de informação que dão suporte a estes negócios. Tendo em vista que muitas empresas, por motivos diversos, aumentam ou diminuem seus segmentos de negócios e sua diversidade de atividades, os sistemas que atendem às suas necessidades devem acompanhar tal dinamismo. Para se adequar às novas funcionalidades do negócio para o qual foi desenvolvido, o sistema passa por um processo de modificação, normalmente incluindo a manutenção de códigos-fonte. Dessa forma, o conjunto das funcionalidades desempenhadas pela aplicação é alterado. Isso acarreta, em muitas situações, a necessidade de alterar o esquema da base de dados a que o sistema está submetido, ou seja, realizar uma reestruturação de parte ou de toda a base de dados. Este trabalho aborda um contexto em que diversas empresas utilizam sistemas de informação não desenvolvidos internamente em seus próprios departamentos de

informática. Na maioria das vezes, esse cenário se caracteriza pela compra de softwares de terceiros. Normalmente, as empresas que comercializam softwares para atenderem os negócios de outras empresas vendem seus produtos para vários clientes. Dessa forma, além da possibilidade de serem realizadas customizações específicas para cada cliente, alterações comuns a todos são freqüentemente feitas, visando evoluir o produto vendido e atender de melhor forma os negócios existentes. Analisando o contexto descrito anteriormente, pode-se identificar que as alterações em sistemas implicam em realizar a manutenção das bases de dados relacionadas. Como cada cliente possui seu próprio banco de dados, tais reestruturações devem ser feitas nas bases de cada cliente, de forma a manter o perfeito funcionamento do software atualizado. Dependendo do número de clientes que utilizam tal aplicação e do volume das alterações a serem feitas, a manutenção das bases de dados pode se tornar um trabalho de bastante risco. O trabalho repetitivo de realizar as mesmas alterações em cada banco de dados separadamente pode ocasionar equívocos por parte de quem está fazendo a manutenção. E, obviamente, se o esquema da base não está de acordo com o que o sistema foi programado, exceções não tratadas na programação podem ocorrer, podendo comprometer o sucesso de alguma funcionalidade da aplicação. Outro fator a ser considerado é o tempo para realizar tais modificações em cada base de dados separadamente, o qual muitas vezes extrapola o aceitável. O objetivo deste trabalho é o estudo e o desenvolvimento de um protótipo de software para sincronizar estruturas de bases de dados construídas sobre o Microsoft SQL Server 2005. Para a sua implementação, foi utilizada a linguagem de programação Microsoft C#.Net. Seu funcionamento consiste em uma comparação prévia entre as bases de dados que o usuário especificar, e a reestruturação das bases conforme uma delas, determinada como a base modelo. Dessa forma, é necessário reestruturar manualmente apenas um banco de dados e, através do software proposto, é possível aplicar as mesmas alterações nas demais bases de dados. O restante deste artigo apresenta detalhes do desenvolvimento deste trabalho e está organizado em seis seções. O Referencial Teórico, Seção 2, descreve conceitos pesquisados para o embasamento do projeto. O Estado da Arte, Seção 3, relaciona softwares semelhantes existentes na atualidade e suas características. A Solução Proposta, Seção 4, descreve os detalhes do protótipo, como suas principais funcionalidades e tecnologia utilizada para sua implementação. Os Testes Funcionais, Seção 5, apresenta detalhes acerca de algumas funcionalidades do software desenvolvido. As Considerações Finais, Seção 6, aponta os principais aspectos identificados durante os estudos e elaboração deste projeto. 2. Referencial Teórico Nesta seção, serão abordados aspectos que fundamentam o desenvolvimento deste trabalho. A seção 2.1 apresenta conceitos de sincronização de estruturas de bancos de dados, onde são descritas formas de sincronização. A seção 2.2 trata de visões de catálogo, através das quais é possível acessar as informações sobre tais estruturas. A seção 2.3 aborda características de uma biblioteca C# para manipulação de estrutura de banco de dados, desenvolvida pela Microsoft Corporation para facilitar a interação com informações de estrutura.

2.1. Sincronização de Estruturas de Bancos de Dados A sincronização de estrutura de banco de dados representa atualizações de objetos de um determinado banco de dados com base nas características de objetos de outra base de dados definida como modelo [Manseo 2009]. Uma maneira de efetuar tais alterações seria codificando scripts SQL (Structure Query Language) e executando-os nas bases de dados necessárias. Porém, este método possui algumas fragilidades, como o tempo despendido para efetuar a tarefa, feita em cada base separadamente. Outro agravante é a possibilidade de que erros sejam cometidos por quem executa o procedimento, por se tratar de um trabalho repetitivo [Akinshin 2009]. Práticas utilizadas pela Microsoft Corporation prevêem uma comparação prévia entre os repositórios de dados, apresentando as diferenças e, com base nelas, efetuando as devidas alterações automaticamente de forma que a estrutura dos objetos do banco de destino fique conforme a do banco de origem [Microsoft 2009a]. As características dos objetos do banco de dados relacional são comumente chamadas de metadados e se referem à descrição conceitual da estrutura (esquema) do banco de dados. Essas descrições são encontradas em catálogos do sistema, os quais são armazenados no cerne do SGBD (Sistema de Gerenciamento de Banco de Dados). Normalmente, os catálogos são armazenados em forma relacional e são consultados, atualizados e mantidos pelo próprio software do SGBD. As informações contidas no catálogo incluem nomes de relações, nomes de atributos, tipos de dados, descrições de restrições e visualizações [Elmasri 2000]. 2.2. Estrutura de Metadados do SQL Server 2005 O SQL Server utiliza um conceito de objetos para representar os bancos de dados e todos os seus elementos e configurações. Estes objetos ficam armazenados no catálogo de sistema. Para acessar tais informações, existem visões padrões do SGBD, onde as visões de catálogo são consideradas a interface mais geral a essas informações [Stanek 2006]. Duas visões de catálogo são importantes no contexto deste trabalho, pois fornecem informações sobre todos os objetos de sistema: as visões de catálogo de sistema (sys) e as visões INFORMATION_SCHEMA. As visões sys são mais completas, contendo informações em aproximadamente 250 catálogos. Já as visões INFORMATION_SCHEMA, apesar de possuírem aproximadamente 20 catálogos, representam a maneira mais direta de acessar determinadas informações [Dobson 2006]. A Tabela 1 e a Tabela 2 contêm visões que acessam dados necessários para o objetivo deste trabalho. Tabela 1. Visões de catálogo sys [Stanek 2006] [Microsoft 2009b]. Schemas Objects Tables Types Columns Visão (sys) Esquema Objeto Tabela Tipo de Dado Coluna Elemento Descrito

key_constraints; check_constraints; default_constraints identity_columns foreing_keys; foreing_key_columns Views SCHEMATA TABLES COLUMNS Restrição de Coluna Colunas com Valor Automático Chave Estrangeira Visualização de Dados Tabela 2. Visões de catálogo INFORMATION_SCHEMA [Microsoft 2008a]. Visão (INFORMATION_SCHEMA) REFERENTIAL_CONSTRAINTS; CONSTRAINT_COLUMN_USAGE; TABLE_CONSTRAINTS; CONSTRAINT_TABLE_USAGE KEY_COLUMN_USAGE Elemento Descrito Esquema Tabela Coluna Restrição Chave VIEW_COLUMN_USAGE; VIEW_TABLE_USAGE; VIEWS Visualização de Dados 2.3. Biblioteca C# para Manipulação de Estrutura de Banco de Dados A Microsoft Corporation desenvolveu uma biblioteca para a plataforma.net com funcionalidades para manipulação de bancos de dados SQL Server. Essa biblioteca é chamada de SQL Server Management Objects (SMO). O principal objetivo desse recurso é obter e alterar as informações de estrutura de banco de dados através das linguagens de programação Visual Basic.Net e C#.Net. Com isso, é possível desenvolver softwares que manipulam esquemas de bases de dados dinamicamente, sem que o programador precise criar scripts com SQL [Microsoft 2008b]. Essa biblioteca foi desenvolvida visando um melhor desempenho quanto à alocação de memória do computador em tempo de execução. Para tanto, os objetos são primeiramente instanciados de forma parcial, obtendo uma quantidade mínima de informações do servidor da base de dados. Somente quando uma determinada propriedade não contemplada na instância parcial do objeto é requisitada ou quando uma chamada de método depender dessa propriedade, o objeto é totalmente instanciado [Microsoft 2008b]. O SMO possui duas categorias de classes: classes de instância, as quais representam os objetos do banco de dados, e classes de utilitário, que executam funcionalidades específicas no banco de dados. As classes de instância fazem o acesso às informações necessárias para as funcionalidades de sincronização de bancos de dados. Os objetos SMO são relacionados de forma hierárquica, onde pode existir um pai para vários filhos, agrupados em coleções de objetos; e um pai para um único filho, este representado por um objeto apenas. Um exemplo seria uma tabela possuir uma ou várias colunas [Microsoft 2008b]. As classes destinadas ao encapsulamento dos metadados fazem parte de um conjunto de classes chamado Microsoft.SqlServer.Management.Smo, o qual está contido

no arquivo Microsoft.SqlServer.Smo.dll. Cada tipo de objeto da base de dados possui classes para sua representação, conforme a Tabela 3. Check; CheckCollection Classe Column; ColumnCollection Database DataType ForeignKey; ForeignKeyColumn; ForeignKeyColumnCollection Schema; SchemaCollection Server Table; TableCollection View; View Collection Tabela 3. Classes do SMO [Microsoft 2008b]. Restrição de Coluna Coluna Banco de Dados Tipo de Dado Chave Estrangeira Esquema Elemento que Representa Servidor de Banco de Dados Tabela Visualização de Dados A criação de objetos se torna simples quando se utiliza SMO. Para criar uma tabela no banco de dados, por exemplo, basta instanciar a classe Table associando um nome a ela. Após ter o objeto referente à tabela, utiliza-se a classe Column para criar suas respectivas colunas. A Figura 1 ilustra um exemplo de uso da biblioteca [Gunderloy 2006]: Figura 1. Exemplo de uso da biblioteca SMO [Adaptado de Gunderloy 2006]. 3. Estado da Arte Como o problema que este trabalho se propõe a solucionar é algo cada vez mais presente na realidade atual do mercado de software, existem algumas formas de solução já implementadas por algumas empresas. Nesta seção, será apresentada uma análise de algumas dessas soluções, salientando algumas diferenças e semelhanças entre elas com um ponto de vista que foca a usabilidade e a solução do problema propriamente dita. Para isso, foram realizados testes em bases de dados SQL Server 2005 criadas exclusivamente para este fim. Os softwares analisados foram: StarInix Database Compare, MS SQL Sync Toolkit Lite 2.3, RedGate SQL Compare, SQL Examiner, xsql Object e dbforge Schema Compare for SQL Server. A seguir, são relacionadas características, diferenças e semelhanças entre os aplicativos mencionados no parágrafo anterior.

3.1. StarInix Database Compare O StarInix Database Compare, versão 2.0.15, é um software livre, oferecido pela StarInix Corporation, utilizado para comparação entre esquemas de bancos de dados. Com os testes realizados nessa ferramenta, observou-se uma quantidade de funcionalidades menor em relação às demais. A principal diferença é a ausência da possibilidade de sincronização. Enquanto as outras ferramentas realizam a comparação e a sincronização dos esquemas, esta apenas os compara. Apesar de suas limitações funcionais, este aplicativo apresenta uma boa usabilidade. Sua interface gráfica com o usuário é bastante clara. Seus botões possuem dimensões maiores do que os botões das outras ferramentas. É possível visualizar os objetos do banco de dados em uma árvore que mostra a hierarquia entre eles, permitindo sua identificação de forma mais facilitada. Ao selecionar um objeto, suas características são exibidas em outra listagem, acompanhadas pelo status da comparação do objeto, isto é, indica se o mesmo existe nos dois bancos, se existe em apenas um deles ou se está diferente em cada banco. Outra facilidade de visualização é identificada em filtros disponíveis, onde é possível escolher se determinado tipo de objeto vai ser apresentado na comparação ou não, permitindo visualizar apenas, por exemplo, views, ou apenas tabelas. 3.2. MS SQL Sync Toolkit Lite 2.3 O MS SQL Sync Toolkit Lite 2.3 é um software de comparação e sincronização de bases de dados comercializado pela BizKit Software. Para a realização dos testes, foi utilizada sua versão de avaliação. Para sua operação, inicialmente, é preciso definir qual será a base fonte (modelo) e qual será a base de destino, a qual sofrerá as alterações. Dessa forma, o sentido da sincronização é determinado antes da comparação ser realizada, ou seja, no momento da definição dos bancos de dados. Após a comparação, os objetos são agrupados por tipo (ex., tabelas, views), em abas exclusivas para cada tipo. É possível selecionar quais objetos serão sincronizados, tornando não obrigatória a sincronização de todos os objetos comparados. Após a sincronização, é gerada uma relação das operações realizadas, mostrando o status de cada operação. Nessa relação, se alguma operação não foi realizada por impedimento do próprio SGBD (por exemplo, por motivos de integridade referencial), não é apresentado o motivo de seu fracasso, apenas é indicado que a mesma não foi efetivada. 3.3. RedGate SQL Compare O RedGate SQL Compare é um software comercializado pela RedGate Software Ltd. Para realizar os testes, foi utilizada a versão de avaliação 8.1.0.360. Este aplicativo permite que a sincronização seja efetuada em qualquer um dos sentidos, ou seja, qualquer um dos dois bancos de dados pode ser o banco modelo. Ao definir as bases de dados a comparar, não é definida qual delas será a base modelo e qual delas será a base de destino. A comparação é feita em ambos os sentidos, bem como seus resultados são apresentados em ambos os sentidos. Por padrão, o software identifica, inicialmente, a primeira base de dados informada como sendo a base modelo. Para definir a segunda base como a base modelo, não é necessário realizar a comparação novamente.

Assim como o StarInix Database Compare, seus botões possuem imagens e dimensões que possibilitam uma identificação mais fácil das principais funcionalidades disponíveis, melhorando a usabilidade do aplicativo. 3.4. SQL Examiner Comercializado pela TulaSoft, o SQL Examiner, versão de demonstração 3.2.0.32, é outro software de comparação e de sincronização de esquema de banco de dados testado neste trabalho. Em seus testes, foi observado que, ao identificar os objetos do banco de dados, o aplicativo os apresenta em uma árvore hierárquica. Nessa estrutura, os objetos dos dois bancos são unidos, ou seja, existe uma única árvore para ambas as bases de dados. As tabelas são muito bem detalhadas, mostrando cada coluna e permitindo selecionar cada uma delas com o intuito de realizar a sincronização apenas nas colunas desejadas. Se o objeto está idêntico nos dois bancos, não é permitido selecioná-lo para incluí-lo na operação de sincronização. Assim como no RedGate SQL Compare, ao ativar a sincronização, é possível escolher em qual sentido a operação será realizada. 3.5. xsql Object O xsql Object é comercializado pela empresa xsql Software. Para os testes, foi utilizada a versão de avaliação 3.1.2.6. Essa ferramenta trabalha com a idéia de adicionar bancos de dados ao projeto de sincronização. Com isso, é possível adicionar vários bancos de dados para que possam ser realizadas as operações de comparação e de sincronização. Porém, após ter adicionado os bancos desejados, as operações só podem ser efetuadas com apenas dois deles, assim como todas as ferramentas aqui analisadas. Depois de identificar cada base de dados, seus objetos são apresentados de forma hierárquica em uma árvore para cada um dos bancos separadamente, facilitando a compreensão da hierarquia entre bancos e objetos. 3.6. dbforge Schema Compare for SQL Server Comercializado pela Devart, dbforge Schema Compare for SQL Server, versão 1.50.336 de avaliação, foi um aplicativo também analisado através de testes. Nele, constatou-se que, assim como os outros, possibilita que suas operações sejam realizadas somente nos objetos selecionados. As tabelas dos bancos comparados são apresentadas em uma listagem onde não constam suas colunas, estando apenas contidas em scripts SQL referentes a cada tabela, o que dificulta a identificação imediata das colunas por parte do usuário. 3.7. Análise Comparativa As ferramentas analisadas mostraram uma boa usabilidade. Com interfaces gráficas intuitivas, permitem que a comparação e a sincronização das estruturas das bases de dados sejam realizadas em etapas separadas. Dessa forma, o usuário pode analisar os resultados da comparação antes de efetuar a sincronização. Outro aspecto positivo a ressaltar é que, em alguns dos aplicativos, os objetos dos bancos são apresentados em árvores, mostrando a hierarquia existente entre eles. Contudo, em todos os testes, foi observado que nenhum dos softwares relacionados realiza a comparação e a sincronização de mais de duas bases de dados em

uma única operação. Para realizar em um terceiro banco, é necessário configurar uma nova comparação entre este e algum outro banco que já esteja com o esquema desejado. 4. Solução Proposta Durante os testes mencionados na Seção 3, os aplicativos se mostraram eficazes ao efetuar comparação e sincronização de esquemas. Porém, para situações em que se deseja sincronizar várias bases de dados, deve-se repetir o procedimento diversas vezes. Isso acontece devido à característica que tais aplicações possuem de realizar a comparação e a sincronização de apenas duas bases de dados por operação. A solução aqui proposta tem o objetivo de minimizar as dificuldades existentes em manter sincronizados vários bancos de dados que devem possuir a mesma estrutura. Para tanto, foi desenvolvido um protótipo de software com a função de sincronização da estrutura de bancos de dados, tornando as alterações de seus esquemas menos trabalhosas. Este protótipo possui a propriedade de realizar suas operações envolvendo quantas bases de dados forem necessárias por vez. Dessa forma, ao término de apenas um procedimento de comparação e sincronização, é possível obter resultados em uma quantidade de bancos de dados finita sem limite imposto pelo aplicativo. Os processos de comparação e de sincronização contemplam inclusão e exclusão de tabelas e inclusão, alteração e exclusão de colunas, chaves estrangeiras e índices. A alteração refere-se à modificação dos valores das propriedades de objetos contempladas nessa versão do protótipo. As propriedades das colunas são: Tipo de Dado, Precisão Numérica, Escala Numérica, Tamanho Máximo, Permite Nulo, Identity, Identity Increment e Identity Speed. As propriedades das chaves estrangeiras são: Tabela Referenciada, Chave Primária Referenciada, Colunas (contempladas pela chave estrangeira), Colunas Referenciadas (de cada coluna contemplada pela chave estrangeira), Delete Action, Update Action. As propriedades de índices são: Clustered, Unique, Colunas (contempladas pelo índice), Ordenação das Colunas. Como se trata de um protótipo, foram escolhidos esses objetos por serem, geralmente, os mais manipulados por necessidades de customizações em aplicações que atuam sobre o banco de dados. A seguir, são descritas as características do protótipo desenvolvido. Na seção 4.1, apresentam-se as principais funcionalidades. Na seção 4.2, detalha-se o fluxo de cada processo. Na seção 4.3, são abordados os aspectos referentes à interface gráfica e as facilidades que oferece ao usuário. Na seção 4.4, apresenta-se a questão da possível variação do desempenho do protótipo conforme o cenário onde é executado, bem como técnicas utilizadas para amenizar possíveis demoras em seu processamento. Na seção 4.5, é descrito como foi feito para garantir a restauração da estrutura original do banco de dados após uma possível sincronização não desejada ou equivocada. Na seção 4.6, detalha-se os recursos tecnológicos utilizados no desenvolvimento deste trabalho. 4.1. Principais Funcionalidades De maneira mais objetiva, é possível dizer que o fim desse protótipo é o ajuste das estruturas de várias bases de dados para que fiquem iguais. Portanto, uma comparação prévia entre elas é fundamental para a identificação do que é necessário alterar e como alterar. Este processo é iniciado com a definição das bases de dados envolvidas no

projeto de sincronização. Após esta etapa, a comparação e a sincronização podem ser realizadas. O Diagrama de Casos de Uso da Figura 2 ilustra as principais funcionalidades desempenhadas pelo protótipo aqui proposto. Neste contexto, o ator é representado pelo usuário que interage diretamente com a ferramenta e inicia os procedimentos. Os casos de uso contemplam as principais operações da aplicação, que são: Adicionar Banco de Dados, onde o usuário define quais os bancos que farão parte da comparação e da sincronização; Remover Banco de Dados, ativando a operação de remoção de um banco de dados do projeto; Comparar Bancos de Dados, onde é ativada a operação de comparação entre as bases, bem como é identificado e apresentado o conjunto de diferenças e semelhanças entre elas; Sincronizar Bancos de Dados, onde é ativada a rotina de alterações dos esquemas das bases para que fiquem iguais. Figure 2. Diagrama de Casos de Uso. 4.2. Estrutura Interna Analisando o processo de forma um pouco mais detalhada, é possível identificar o comportamento do algoritmo para desempenhar as principais funcionalidades do protótipo. Para ilustrar tal comportamento, foram elaborados Diagramas de Atividades detalhando algumas das principais funcionalidades existentes no Diagrama de Casos de Uso apresentado anteriormente. A Figura 3 ilustra o Diagrama de Atividades referente ao procedimento de adição de bancos de dados ao projeto de sincronização. Primeiramente, para ter acesso ao banco a ser adicionado, é preciso se autenticar e se conectar a ele através da interface do protótipo. Para tanto, uma tela é apresentada contendo um formulário para que o usuário informe os dados de conexão ao servidor do banco de dados. Ao submeter tais dados ao SGBD, se a conexão for bem sucedida, os bancos de dados encontrados no servidor conectado são exibidos para que o usuário escolha um deles para ser adicionado. Após esta etapa, as características dos objetos contidos no banco são lidas e armazenadas na memória do aplicativo para uso futuro. Neste ponto do processo, é

possível adicionar outro banco de dados do mesmo servidor já conectado ou conectar-se em outro servidor para adicionar outro banco de dados. Se a conexão ao servidor não obtiver êxito, uma mensagem informativa é exibida ao usuário. Figura 3. Diagrama de Atividades referente à adição de banco de dados. O Diagrama de Atividades ilustrado na Figura 4 representa a operação de remover, do projeto de sincronização, um banco de dados anteriormente adicionado. Para isso, a aplicação recebe um banco de dados selecionado pelo usuário e o remove da lista de bancos que serão comparados e sincronizados. Figura 4. Diagrama de Atividades referente à remoção de banco de dados. O Diagrama de Atividades que representa o comportamento do algoritmo quanto à funcionalidade de comparação de esquemas é ilustrado na Figura 5. Conforme mencionado nas seções anteriores deste artigo, para que a comparação seja possível, é necessário que o usuário escolha um banco de dados modelo dentre os já adicionados ao projeto. Será com base neste banco que os demais serão alterados. Quando o procedimento é acionado, o algoritmo identifica qual das bases foi definida como modelo. Com isso, a comparação entre os objetos dos bancos de destino e os objetos do banco modelo é iniciada. Ao término da análise dos objetos, os resultados obtidos são

exibidos ao usuário para que tenha conhecimento das semelhanças e diferenças identificadas entre cada objeto das bases de dados. Figura 5. Diagrama de Atividades referente à comparação de banco de dados. Por fim, a rotina de sincronização é executada, alterando os objetos dos bancos de dados para atingir o objetivo final de manter suas estruturas, ou parte delas, iguais. O Diagrama de Atividades da Figura 6 ilustra os detalhes desta última etapa do processo. Para executar essa funcionalidade, o usuário precisa informar, através da interface gráfica, quais objetos deseja sincronizar. O algoritmo do protótipo recebe tal informação, e inicia o processo de sincronização apenas dos objetos selecionados. Terminando as alterações, é exibido um relatório contendo o resultado de cada alteração executada pelo procedimento. Figura 6. Diagrama de Atividades referente à sincronização de banco de dados. 4.3. Usabilidade Devido ao elevado risco e complexidade ao efetuar alterações em estruturas de bancos de dados, a atenção do usuário deve estar focada principalmente nos detalhes de cada alteração, se preocupando o mínimo possível com a usabilidade do sistema utilizado. Com base nisso, foi elaborada uma interface gráfica que disponibiliza cada funcionalidade de forma clara e separada, buscando ser o mais intuitiva possível. As Figuras 7 e 8 ilustram, respectivamente, a tela de conexão e adição dos bancos de dados do projeto e a tela de comparação e sincronização das bases de dados.

Cada banco de dados é apresentado em uma aba (componente TabPage do.net Framework) separada. Em cada aba, existe uma árvore hierárquica (componente TreeView do.net Framework) com a estrutura do banco destino, outra com a estrutura do banco modelo e outra onde são apresentadas somente as diferenças encontradas após a comparação entre os dois bancos. Todas as TreeViews são incrementadas com imagens ilustrando cada tipo de objeto (tabelas, colunas, chaves estrangeiras, etc). Nas estruturas dos bancos destino e modelo, ao selecionar um objeto, suas características são listadas em uma grade (componente DataGridView do.net Framework), possibilitando identificar as semelhanças e diferenças existentes entre cada um. Ao selecionar um objeto na TreeView que apresenta o resultado da comparação, as imagens de cada tipo de objeto são acrescidas de ícones que identificam seu estado para sincronização. Os estados existentes são: o objeto deve ser excluído (existe apenas no banco destino); o objeto deve ser inserido (existe apenas no banco modelo); o objeto deve ser alterado (existe nos dois bancos, porém com algumas características diferentes). Para possibilitar a escolha de quais objetos devem ser sincronizados, é apresentado também um checkbox ao lado de cada nó da árvore das diferenças. Após a sincronização, é gerado um relatório de resultados em cada aba, referente à sincronização de cada banco de dados. Figura 7. Tela de conexão e adição dos bancos de dados do projeto. Na Figura 8, é apresentado um exemplo da tela principal, onde existem três abas (uma para cada banco a ser comparado). A aba selecionada apresenta a árvore hierárquica do banco dbteste2 no quadro superior esquerdo. No quadro superior direito, está a árvore referente ao banco modelo (dbteste). No quadro inferior esquerdo, está a árvore do resultado da comparação (contendo todas as diferenças encontradas, sinalizadas com ícones que representam inserir, excluir e alterar). No quadro inferior

direito (em branco), serão listados, após a sincronização, os resultados das operações de cada objeto selecionado. Figura 8. Tela de comparação dos bancos de dados (Tela Principal). 4.4. Desempenho Como os objetos de banco de dados são estruturados de forma hierárquica, os procedimentos de obtenção das informações, comparação e sincronização das estruturas são efetuados através de repetidas iterações, implementadas no código-fonte com os chamados loops. Muitas vezes, é necessário que sejam realizadas iterações aninhadas, ou seja, um loop dentro de outro loop. Um exemplo dessa prática é representado por um banco de dados que possui várias tabelas, e cada tabela possui várias colunas. Com base nisso, é possível afirmar que o tempo necessário para executar tais procedimentos é proporcional à quantidade de objetos aninhados existentes no esquema da base de dados. Se essa quantidade for muito grande, o tempo de processamento do protótipo pode ultrapassar limites aceitáveis por quem o utiliza. Para amenizar esse problema, foram utilizadas tarefas (Threads) separadas para cada banco de dados, onde os procedimentos são executados em cada banco paralelamente. Por exemplo, enquanto está sendo realizada a comparação do banco A, a comparação do banco B também está sendo processada. Como os procedimentos de um banco não dependem dos procedimentos de outro, essa prática se torna possível. É importante salientar que o hardware utilizado para executar o protótipo é de extrema relevância para se obter um bom desempenho.

4.5. Desfazer a Sincronização Os dados de um banco são armazenados em sua estrutura de tabelas, colunas, etc. Como algumas alterações em esquemas podem acarretar a perda ou mudança desses dados, é preciso que sejam feitas com bastante cuidado. Um exemplo dessa situação seria a exclusão de uma determinada tabela ou a mudança do tipo de dado suportado por uma coluna de decimal para inteiro. Baseando-se nesse cenário, se o usuário identifica que executou a sincronização realizando alterações que não deveriam ter sido feitas e perdeu alguns dados importantes, seria necessário reverter o processo para recuperar tais informações juntamente com o esquema alterado. Para permitir que a sincronização seja desfeita, foi utilizada a classe Backup do SMO para gerar cópias (backups) dos bancos de dados adicionados ao projeto. Para isso, basta clicar no botão Backup da tela principal. Uma pequena tela é carregada mostrando o andamento do processo de geração dos backups com barras de progressão. À medida que o procedimento é executado, uma listagem com os resultados da cópia de cada banco de dados é alimentada nessa mesma tela. Com as cópias já geradas, é possível realizar a restauração dos bancos de dados, revertendo qualquer alteração realizada após a geração dos backups (para isso, foi utilizada a classe Restore do SMO). A restauração deve ser feita em cada banco de dados separadamente, clicando no botão Restaurar existente na aba referente à base de dados desejada. Semelhante ao procedimento anteriormente descrito, uma barra de progressão é apresentada com o andamento do processo de restauração. 4.6. Tecnologia O protótipo desenvolvido neste trabalho se aplica exclusivamente ao Sistema de Gerenciamento de Banco de Dados Microsoft SQL Server. Os testes foram realizados na sua versão 2005 Express. Este recurso foi escolhido pela sua presença bastante significativa na Tecnologia da Informação de várias empresas e negócios atuantes atualmente no mercado. Como tecnologia de desenvolvimento de software, foi escolhida, também da Microsoft Corporation, a plataforma.net. A linguagem utilizada é C#.Net com seu framework 3.5, a qual é considerada uma das mais utilizadas linguagens de programação da atualidade. Para facilitar o desenvolvimento dos métodos que interagem com banco de dados, o SMO, mencionado na seção Referencial Teórico é muito útil, possuindo abstrações específicas para cada tipo de objeto de banco de dados utilizado. A seguir, é feita uma análise onde se justifica a utilização dessa biblioteca ao invés de visões de catálogos disponibilizadas pelo SGBD. 4.6.1. Análise Comparativa entre Métodos para Manipulação de Esquemas Conforme a Seção 2 deste artigo, as duas formas estudadas para realizar a obtenção, comparação e sincronização de estrutura de banco de dados são: Catálogos de Metadados do SGBD e a biblioteca SQL Server Management Objects (SMO). De ambas as formas, é possível realizar as operações propostas neste trabalho. Utilizando-se as visões de catálogos, seria necessário montar várias queries (instruções SQL destinadas a manipular dados em um banco de dados) dinâmicas com o intuito de consultar e atualizar tais metadados. Além disso, para que o código-fonte ficasse melhor

estruturado, classes deveriam ser criadas para armazenar informações de cada objeto do banco de dados. Utilizando-se o SMO, como as funcionalidades de consulta e atualização de esquema já estão implementadas através de métodos e propriedades na biblioteca, basta apenas utilizá-las de forma simples e direta. Com base nesse estudo, foi escolhido o SMO como recurso de manipulação de estrutura de banco de dados, facilitando as operações, permitindo direcionar atenção maior às lógicas da sincronização e na boa usabilidade do protótipo. 5. Testes Funcionais Para os testes realizados no protótipo, foram utilizadas bases de dados criadas exclusivamente para este fim, contemplando diversas possibilidades de sincronização com todos os tipos de objetos de esquema que se propõe a sincronizar nesta versão do protótipo. Dentre esses testes, destaca-se a situação onde objetos do banco estão vinculados. A definição de uma coluna como chave estrangeira constitui-se em um exemplo clássico de vínculo. Neste caso, operações de exclusão e de alteração podem ser impedidas pelos vínculos existentes entre objetos. Se o procedimento de sincronização tentar, por exemplo, excluir um objeto coluna referenciado por um objeto chave estrangeira, não obteria sucesso, pois eles estariam vinculados. Outro exemplo seria a alteração do tipo de dado de uma coluna referenciada por uma chave estrangeira sem alterar também o tipo de dado da coluna chave primária da tabela referenciada. Para tratar a situação exposta acima, foi definida uma regra a ser seguida no momento da sincronização: para que um objeto, que possui dependências, possa ser excluído ou alterado (desde que a propriedade que está sendo alterada faça parte da dependência), os objetos a ele vinculados que inviabilizam a alteração ou exclusão devem ser previamente excluídos. Porém, para que o usuário possa intervir, caso não esteja ciente ou seguro dessa situação, um procedimento de certificação é executado. Antes de realizar a exclusão ou a alteração de um determinado objeto, verificam-se todas as suas dependências (existentes entre os objetos e propriedades contemplados nesse trabalho). Caso exista alguma dependência, o processo é paralisado e o usuário é notificado. Esta notificação é composta por um alerta de risco, contendo o nome do objeto que está sendo sincronizado e os nomes de todos os outros objetos que possuem referência a este objeto e estão inviabilizando a operação. Nesse momento, o usuário responde uma pergunta que o permite continuar o processo efetuando as alterações necessárias nesse objeto, seguindo a regra estabelecida, ou continuar o processo sem sincronizá-lo, partindo do próximo objeto a ser sincronizado. De forma resumida, na etapa de testes foram identificados alguns erros de desenvolvimento e algumas operações necessárias que não haviam sido planejadas inicialmente. Cada problema foi solucionado logo após sua identificação, deixando o aplicativo em condições de ser utilizado para o fim proposto. 6. Considerações Finais Ao longo do desenvolvimento deste artigo, destacou-se a necessidade de construir o protótipo aqui descrito, visando à solução de dificuldades existentes no dia-a-dia de profissionais da tecnologia da informação ao desempenhar tarefas de sincronização de bancos de dados. As soluções já existentes no mercado que foram analisadas, apesar de

algumas delas apresentarem um conjunto bastante completo de funcionalidades, não sincronizam, simultaneamente, a quantidade de bases de dados desejada. Além de concretizar a necessidade da criação deste protótipo, os estudos realizados para sua elaboração foram muito úteis para identificar facilidades e boas formas de solucionar o problema. A biblioteca SMO demonstrou um bom desempenho e ofereceu uma grande facilidade na manipulação das estruturas de bancos de dados. O encapsulamento dos objetos do esquema foi de grande utilidade, possibilitando a organização necessária para o desenvolvimento de funcionalidades com a complexidade exigida. Durante os estudos que fundamentam este trabalho, foi enfrentada a dificuldade de escassez de bibliografia específica sobre sincronização de estruturas de bancos de dados. Apesar disso, o acesso a informações técnicas em literaturas relacionadas ao funcionamento geral de banco de dados e sua manutenção viabilizou a elaboração da solução proposta. Outras pequenas dificuldades enfrentadas ao longo do desenvolvimento do protótipo se referem ao estudo mais aprofundado da biblioteca SMO e de como utilizar determinadas funcionalidades de componentes de interface do.net Framework da forma desejada. O protótipo desenvolvido realizou com sucesso as operações propostas, sendo bastante útil para cenários onde se deseja sincronizar diversas bases de dados simultaneamente. Sua interface gráfica foi montada de forma a permitir uma prática usabilidade e uma fácil identificação das funcionalidades existentes. Por se tratar de um protótipo, futuramente pode ser evoluído para possibilitar a sincronização de mais objetos de esquema ainda não contemplados. Bibliografia Akinshin, Eugene. (2009) Database Deployment: Synchronizing Database Structures, http://www.perpetuumsoft.com/product.aspx?lang=en&pid=55&tid=databasedeploy mentsynchronizingdatabasestructures, Maio. Dobson, R. (2006) Beginning SQL Server 2005 Express. Database Applications with Visual Basic Express and Visual Web Developer Express, Apress. Elmasri, R e Navathe, S. (2000) Sistemas de Banco de Dados Fundamentos e aplicações, 3. Ed. Rio de Janeiro: LTC. Gunderloy, M, Jorden, J. L. e Tschanz, D. W. (2006) Mastering Microsoft SQL Server 2005, Indianapolis: Wiley Publishing Inc. Manseo. (2009) What is Online Synchronization, http://deviandriana01- databases.blogspot.com/2009/03/what-is-online-synchronization.html, Março. Microsoft. (2008a) Information Schema Views (Transact - SQL), http://msdn.microsoft.com/en-us/library/ms186778(sql.90).aspx, Novembro. Microsoft. (2008b) SQL Server Management Objects (SMO), http://msdn.microsoft.com/en-us/library/ms162169(sql.90).aspx, Novembro. Microsoft. (2009a) How to: Synchronize Database Schemas, http://msdn.microsoft.com/pt-br/library/aa833193.aspx, Novembro.

Microsoft. (2009b) Exibições do catálogo de objeto (Transact http://msdn.microsoft.com/pt-br/library/ms189783.aspx, Julho. - SQL), Stanek, W. R. (2006) Microsoft SQL Server 2005: guia de bolso do administrador, Porto Alegre: Bookman.