segunda-feira, 10 de junho de 2013

Bad Smells (Mal cheiros) em Bancos de Dados

Uma estrutura de um banco de dados, diferentemente da estrutura de um software, tende a deteriorar naturalmente com o passar do tempo. Dentre várias causas de deterioração podemos citar o crescimento progressivo do volume de dados devido ao aumento natural de usuários que o utilizam e também ao seu próprio tempo de uso, tornando um modelo de dados que no início era eficiente para solução proposta em um modelo ineficiente e defasado.

Essa deterioração natural aliada a mudanças em requisitos de negócio exigem modificações e refatorações tanto no software que os implementa quanto em seus bancos de dados. Entretanto a refatoração de um banco de dados é mais complexa que a de um software devido aos seguintes motivos: (i) além de manter comportamento também é necessário manter as informações (dados) e (ii) acoplamento com diversas origens (outras aplicações, frameworks, integrações, etc).

Devido a essas dificuldades a evolução de uma estrutura de banco de dados torna-se um desafio, ocorrendo assim um fenômeno conhecido como Bad Smells (mal cheiros), da mesma forma que ocorre com o código de um software. Em software um code smell (bad smell) é uma categoria comum de problema no código fonte que indica a necessidade de refatoração, e o mesmo ocorre com bancos de dados, onde são chamados database smells.

Abaixo segue uma lista de alguns database smells:
  • Multi-purpose column (coluna com mais de uma função)
  • Multi-purpose table (tabela com mais de uma função)
  • Redundant data (dados redundantes/repetidos)
  • Tables with many columns (tabelas com muitas colunas)
  • "Smart" columns (colunas "espertas")
  • Lack of constraints (falta de restrições)
  • Fear of change (medo da mudança)
Dentre os database smells citados acima, devemos ter atenção especial ao "Fear of change", pois pode ser considerado o pior de todos, pois:
  • inibe a inovação, 
  • reduz a efetividade, 
  • produz ainda mais bagunça e 
  • ao longo do tempo a situação fica cada vez pior. 
Lembra do valor "Coragem" do XP (eXtreme Programming)? Mudança é algo que deve ser considerado natural e irá acontecer em projetos de software, isso é um fato, não podemos fugir disso, então precisamos das práticas e ferramentas adequadas para que a mudança não seja um entrave na evolução do seu projeto, e sim algo natural e, de certa forma, trivial para sua equipe, e o mesmo deve ocorrer com seu banco de dados.

Esse post é apenas uma introdução a este assunto pouco explorado e que tenho como proposta para conclusão de Pós-Graduação em Tecnologias Aplicadas a Sistemas de Informações com Métodos Ágeis que estou realizando na http://www.uniritter.edu.br.

A idéia é montar uma taxonomia de Database Smells através de um catálogo, inclusive sugerindo os Database Refactoring que podem ser utilizados em sua solução, e futuramente, quem sabe em um futuro trabalho de Mestrado fazer um paralelo dos Database Smells com Code Smells, principalmente se os mal cheiros em códigos podem refletir mal cheiros no seu banco de dados. ;-)

Database Refactoring

Contextualização

Refatoração de código (Code Refactoring) é uma disciplina/processo que consiste em melhorar a estrutura interna de um software sem modificar seu comportamento externo, e uma Refatoração de Banco de Dados (Database Refactoring) parte do mesmo princípio, porém além de manter o comportamento externo também deve manter a semântica da informação que ele mantém/armazena, e por esse motivo é considerada mais difícil.

Um outro conceito que posso destacar a respeito de Database Refactoring é:
"Mudança disciplinada na estrutura de uma base de dados que não altera sua semântica, porém melhora seu projeto e minimiza a introdução de dados inconsistentes"

O ponto interessante deste último é o texto "minimiza a introdução de dados inconsistentes", pois esse é o grande objetivo de realizarmos um refactoring na estrutura de um banco de dados, ou seja, melhorar o desing atual para melhorar a consistência dos dados e também a qualidade dos novos dados que serão adicionados ao seu banco de dados.

E esta tarefa não é das mais simples, pois existe um fator preponderante no que diz respeito a dificuldade de execução deste tipo de refactoring que é o acoplamento, que será visto logo a seguir.

Acoplamento

Figura 1. Baixo Acoplamento
É a medida de dependência entre dois elementos. Quanto mais acoplados dois elementos estiverem, maior a chance que a mudança em um implique na mudança em outro.

Figura 2. Alto Acoplamento
Simples assim, quanto mais o seu banco de dados estiver acoplado, ou seja, dependente de diversas aplicações externas, mais difícil será a aplicação de um refactoring.

A Figura 1 demonstra um cenário "Single-Database Application" que é bem simplificado, onde a aplicação de um refactoring será mais tranquilo.

Com certeza o cenário da Figura 2, o "Multi-Database Application" é o pior caso, pois exige muito cuidado e planejamento para execução do refactoring, então veremos a seguir uma sugestão de processo para execução.

Processo de Refatoração

Figura 3. Processo de Database Refactoring
Um processo é um conjunto organizado de atividades com um objetivo em comum. Executar um database refactoring em um cenário "Single-Database Application" ou "Multi-Application Database" requer um processo, por mais simples que seja. A grande diferença na execução em ambos cenários é que no caso do "Multi-Application Database" o período de transição (mais abaixo falaremos) geralmente será mais longo.

É bom sempre ter em mente que um database refactoring, como já vimos, não é uma atividade simples então caso seja identificada a real necessidade de refatorar um banco de dados então podemos usar o seguinte roteiro (processo) para se guiar:
  • Escolher o refactoring mais apropriado;
  • Depreciar o esquema original;
  • Testar antes, durante e após;
  • Modificar esquema;
  • Migrar os dados;
  • Modificar código externo;
  • Executar testes de regressão;
  • Versionar seu trabalho;
  • Anunciar o refactoring.
Figura 4. Regra Geral Processo Refatoração

Na Figura 4 é demonstrado um pequeno processo descrevendo um fluxo básico para aplicação de um refactoring.

Atente bem para o "Período de Transição", que é a fase mais importante, principalmente para cenários "Multi-Database Application" (Figura 2), onde você precisa ter em mente que não conseguirá realizar o refactoring e fazer o deploy em produção de todas as aplicações ao mesmo tempo. Na verdade você nem conseguirá alterar todas as aplicações ao mesmo tempo, principalmente se você tiver dependência de terceiros, então você precisará suportar o esquema original e o esquema resultante ao mesmo tempo, para somente quando todas aplicações estiverem suportando apenas o esquema resultante, ou novo esquema, você poderá aposentar de vez o antigo esquema e assim finalizar este período.

Estratégias de Database Refactorings

Existem alguns pontos a considerar com estratégias para adoção de um database refactoring:

  • Pequenas mudanças são mais fáceis de aplicar;
  • Identifique unicamente cada refactoring;
  • Implemente uma grande mudança realizando várias pequenas mudanças;
  • Tenha uma tabela de configuração/versionamento do seu banco de dados;
  • Priorize triggers ao invés de views ou sincronizações em lote;
  • Escolha um período de transição suficiente para realizar as mudanças;
  • Simplifique sua estratégia de controle de versão de banco de dados;
  • Simplifique negociações com outros times;
  • Encapsule acesso ao banco de dados;
  • Habilite-se a montar facilmente um ambiente de banco de dados;
  • Não duplique SQL;
  • Coloque os ativos de banco de dados sobre controle de mudanças;
  • Seja cuidadoso com políticas.
Os items acima mostram apenas algumas sugestões, em forma de "lições aprendidas", de algumas estratégias que você pode considerar quando tiver a necessidade de realizar um refactoring.
Para apoiar essas estratégias existe um catálogo que descrevem diversos tipos de refactorings em bancos de dados e exemplos de uso, que veremos a seguir.

Catálogo de Database Refactorings

Este catálogo é dividido em algumas categorias:

  • Structural: são mudanças na estrutura do banco de dados (tabelas, colunas, visões, etc).
  • Data Quality: são mudanças que melhoram a qualidade das informações contidas em um banco de dados.
  • Referential Integrity: são mudanças que asseguram que uma linha referenciada exista em outra relação e/ou assegura que uma linha que não é mais necessária seja removida apropriadamente.
  • Architectural: são mudanças que melhoram a maneira que programas externos interagem com a base de dados.
  • Method: são mudanças que melhoram a qualidade de uma Procedure um Função.
  • Transformations: mudanças que alteram a semântica do esquema do banco pela adição de novas funcionalidades.

No meu github é possível encontrar exemplos práticos de aplicação passo-a-passo de um refactoring em um modelo inicial, passando por um período de transição e chegando ao modelo final

Considerações Finais

Devemos levar em consideração que apesar destas técnicas serem direcionadas para refatoração, ou seja, mudar estrutura sem mudar sua semântica, as mesmas podem e devem ser utilizadas para evolução da sua aplicação, ou seja, se você precisa construir uma nova feature em sua aplicação que está em produção, você poderá recorrer das práticas aqui apresentadas para evoluir seu esquema de forma mais consistente e segura.

Baseado no exposto podemos facilmente responder a pergunta "Por quê Refatorar?":

  • aceitar mudança de escopo;
  • fornecer feedback rápido;
  • melhoria contínua;
  • aumentar simplicidade para facilitar entendimento;
  • tornar os modelos mais próximos do mundo real;
  • termos modelos simples para facilitar:
    • manutenção e
    • evolução da aplicação
E para refatorarmos precisamos ter conhecimento, disciplina, simplicidade, bom senso e persistência, sem contar no ponto fundamental que é organização.

Referências