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.
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.
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.
Figura 2. Alto Acoplamento
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.
Na Figura 4 é demonstrado um pequeno processo descrevendo um fluxo básico para aplicação de um refactoring.
Figura 4. Regra Geral Processo Refatoração
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. A grande verdade é que muito provavelmente você nem consiga 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
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
- Livros:
- Refactoring Databases (Scott W. Ambler e Pramod J. Sadalage)
- Agile Database Techniques (Scott W. Ambler)
- Refactoring (Martin Fowler)
- Agile Modeling (Scott W. Ambler)
- Links:
- Slides
CodingByExample.org 
