Como parte do Bluesoft Labs (a nossa versão do 20% time do Google), Ismael Soares fez uma pesquisa sobre Refatoração de Bancos de Dados, escreveu um artigo a respeito do assunto e fez uma apresentação de aproximadamente 45 minutos.
Assista a apresentação e leia o artigo na integra, não esqueça de deixar um comentário como feedback.

Introdução

Quanto vale a informação? Com o avanço tecnológico, esta pergunta ganhou um lugar importante no cenário de negócios corporativos atual. Por este motivo, apenas ter as informações armazenados numa base de dados não é suficiente. É preciso garantir qualidade.

Os sistemas de banco de dados, que há alguns anos eram tão úteis, passaram a ser substituídos por outros mais avançados. Os SGBD’s atuais estão a todo tempo sendo melhorados. Fazer a migração destes bancos de dados custa caro e é difícil, por razões como:

  • Mudança da cultura empresarial.
  • Treinamento de profissionais.
  • Mudanças de paradigmas.
  • Requer organização e disciplina.

A boa notícia é que existe uma forma de fazer estas migrações e melhorias de forma segura e incremental, usando técnicas de Refactoring de Banco de dados. Além disto, usando estas técnicas pode-se apoiar no processo de desenvolvimento de softwares evolutivos, incluindo Rational Unified Process (RUP), Extreme Programming (XP), Agile Unified Process (AUP), Scrum e Métodos Dinâmicos de Desenvolvimento de Sistemas.

O que é Refactoring de Banco de Dados?

Refactoring de Banco de Dados não é mágica! Consiste em simples mudanças no esquema do banco de dados (tabelas, views, trigger, procedures, etc) que melhoram o design sem alterar a semântica. Em outras palavras, não se pode adicionar novas funcionalidades ou interromper as funcionalidades existentes. Também não é possível adicionar novos dados nem mudar o significado dos que já estão persistidos. O processo de refactoring do banco de dados define a forma de evoluir de maneira segura um esquema de banco de dados em pequenos passos (incremental e evolutivamente).

Martin Fowler define refactoring da seguinte forma: “É um processo de alteração em um sistema de software, de modo que, o comportamento externo do código não mude, mas que sua estrutura interna seja melhorada.”

Categorias de Refactoring

Para melhor compreendermos o que pode ser refatorado em um esquema de banco de dados, considere as seis principais categorias de refactoring:

  1. Estrutural: mudanças em estruturas de tabelas e/ou views.
  2. Qualidade dos dados: melhora na qualidade da informação, por exemplo, fazendo uma coluna não-nula para garantir que sempre contenha valores.
  3. Integridade referencial: mudanças para garantir a integridade dos dados, por exemplo, adicionando chaves estrangeiras e/ou triggers.
  4. Arquitetura: Mudança que melhora a forma global que programas externos interagem com um banco de dados, por exemplo, substituindo uma operação Java existente, em uma biblioteca, por uma stored procedure armazenada no banco de dados.
  5. Métodos: Mudança que melhora a qualidade de métodos, por exemplo, renomeando um procedimento armazenado para torná-lo mais fácil de entender.
  6. Transformação sem refactoring: Mudança no esquema de banco de dados que muda a semântica, por exemplo, adicionar uma coluna numa tabela existente.

O Processo de Refactoring de Banco de Dados

O processo de refactoring está dividido em várias etapas, onde o resultado de cada um gera o próximo passo a ser seguido:

  1. Identificar a necessidade de refatorar.
  2. Escolher o refactoring mais apropriado.
  3. Depreciar o esquema original.
  4. Testar antes, durante e depois (TDD).
  5. Modificar o esquema.
  6. Migrar os dados.
  7. Modificar o código externo.
  8. Executar testes de regressão.
  9. Versionar seu trabalho.
  10. Anunciar o refactoring.

Exemplo de Refactoring

Para exemplificar um refactoring, observe um caso simples, mas muito comum:
Considere duas tabelas: Customer e Account.

O primeiro passo é identificar a necessidade da refatoração, que neste caso, é mover a coluna “Balance” da tabela “Customer” para a tabela “Account”. Profissionais com habilidades de programação e banco de dados determinam a melhor estratégia de refactoring e, de preferência em par, executam a modificação no esquema e a migração dos dados.

A coluna da tabela “Customer” não pode ser removida de imediato. É preciso definir um tempo para que as modificações sejam aplicadas nos sistemas externos. Este tempo é chamado de período ou estado de transição, por isso, deve-se adicionar um comentário na coluna que será removida, indicando que está deprecated, em seguida, deve-se criar duas triggers, uma em cada tabela, para sincronizar os dados. Estas triggers serão removidas juntamente com coluna da tabela “Customer”.

No momento do refactoring são executados também os testes necessários – unitários e de regressão – para garantir que a mudança não irá afetar os dados e os sistemas externos.

Impedimentos

Em seu livro – Refactoring Databasess Evolutionary Databasess Design – Scott W. Ambler disse que para falar de refactoring, é necessário falar sobre os impedimentos e dificuldades que provavelmente surgirão ao longo do processo. Segundo Ambler, o primeiro obstáculo, e um dos mais difícieis de se superar, é o cultural. Isto porque muitos profissionais confundem abordagens evolutivas com o “cod-and-fix” (codificar e corrigir) – técnica de desenvolvimento usada no final da década de 70 e início da 80, que resultou em softwares de baixa qualidade – e acredita-se que é perda de tempo evoluir ao longo do projeto. Tal fato acaba consumindo boa parte do investimento no projeto, e exige muita paciência do gestor da mudança para convencer a equipe de que, esta mudança de paradigma é algo bom.

O segundo obstáculo, é a falta de ferramentas de testes, embora tenhamos algumas de código aberto, a eficiência ainda é baixa e não são totalmente integradas com o desenvolvimento. É preciso organizar muito bem cada passo da refactoring para se conseguir testes eficazes. Atualmente as ferramentas mais conhecidas são: DBUnit (dbunit.sourceforge.net) e SQLUnit (sqlunit.sourceforge.net).

O terceiro obstáculo é o grau de acoplamento. Em boa parte das empresas, quer sejam de T.I. ou não, a questão da arquitetura do banco de dados não é algo bem resolvido e amplamente discultido como deveria. Este fato faz com que a utilização do banco de dados crie uma dependência muito grande com outros componentes, levando a arquitetura do sistema à um alto grau de acoplamento. Este cenário implica em muito mais tempo para a aplicação da técnica, do que seria necessário, elevando assim o custo do projeto.

Conclusão

Refactoring de Banco de Dados é uma técnica de implementação de bancos de dados, assim como Code Refactoring é uma técnica de implementação de aplicativos. Partindo do princípio que freqüentemente é preciso adicionar novas funcionalidades, como, por exemplo, uma nova coluna ou stored procedure, usando técnicas de refactoring, estas alterações tornam-se mais simples de ser aplicadas.

Refactorings podem ser iniciadas a qualquer momento do projeto, sempre que se for necessário. A vantagem desta abordagem é que aos poucos, porem constantemente, melhora-se a qualidade do banco de dados. Este processo não só torna a base de dados mais fácil de entender e usar, mas também facilita a evolução ao longo do tempo, em outras palavras, melhoramos a produtividade global do desenvolvimento.

As empresas evoluem adotando técnicas modernas de desenvolvimento ágil, mas ficam com uma parcela do projeto defasada, quando negligenciam a arquitetura de bancos de dados. Portanto, os profissionais de banco de dados também podem usufruir de técnicas ágeis, como Refactoring de Banco de Dados, por exemplo.

Referências

Ambler, Scott W., Pramod J. Sadalage (2006). Refactoring Databases: Evolutionary Databases Design. New York: Addison Wesley Professional. http://www.ambysoft.com/books/refactoringDatabases.html
Ambler, Scott W., Pramod J. Sadalage (2006). Refactoring Databases: The Process.
http://www.simple-talk.com/sql/database-administration/refactoring-databases-the-process/
Ambler, Scott W. (2007). Presentation Databases Refactoring.
http://www.infoq.com/presentations/ambler-database-refactoring
Ambler, S. W. (2003). Agile Databases Techniques: Effective Strategies for the Agile Software Developer. New York: John Wiley & Sons. http://www.ambysoft.com/agileDatabasesTechniques.html

Autor

André Faria Gomes é executivo, empreendedor, investidor, mentor, gerente, escritor, palestrante, podcaster e agilista. Atualmente, é CEO da Bluesoft em São Paulo, investidor e membro do conselho da Wow e mentor da Liga Ventures.

10 Comentários

  1. Pingback: 1 ano de Bluesoft Labs - Labs Bluesoft

  2. Pingback: 1 ano de Bluesoft Labs « Blog da Bluesoft

  3. Pingback: Refatoração de Banco de Dados na Prática « Blog da Bluesoft

  4. Wellington Marion Resposta

    Parabéns Ismael, ficou muito boa sua apresentação. Ficaremos anciosos para a nova parte que você está fazendo.
    Abraço, Well

Deixe aqui o seu comentário