Examinando o Database Refactoring
por João Marcelo Borovina Josko
Disponibilizar sistemas de informação com qualidade em ciclos cada vez menores para suportar o negócio, representa um sonho almejado por muitas áreas de negócio e de desenvolvimento também. Essa realidade impulsionou muitas organizações – principalmente aquelas fornecedoras de software – a buscar processos de desenvolvimento capazes de atender a essa demanda concomitante a manutenção da lucratividade.
Em resposta, o mercado presenciou o aparecimento de modelos de qualidade ou metodologias que, apesar de focarem nas questões citadas acima, o fizeram sob óticas de atuação distintas. Uma dessas está ligada às metodologias ágeis de desenvolvimento – como o SCRUM ou Dynamic System Development Method, DSDM – que defendem a construção do software de maneira incremental e iterativa cujas características são conhecidas pouco antes da entrega.
Essa nova perspectiva de desenvolvimento também implica o emprego de novas técnicas e métodos de atuação sobre a porção de dados, uma vez que o projeto de todo o modelo de banco de dados antes do uso – visão tradicional –, naturalmente diverge dos princípios de agilidade presentes nessa perspectiva. Não obstante a pouca discussão desse tema dentro do círculo dos desenvolvedores ágeis, alguns métodos e técnicas aplicados sobre os dados foram propostos, dentre eles o Database Refactoring.
Desvelando a Técnica
Refactoring ou Code Refactoring é uma técnica de reestruturação de um código, de forma disciplinada e evolutiva em pequenos passos, empregada no processo proposto pelo Extreme Programming – XP –, por exemplo. Nessa reestruturação, contudo, o comportamento semântico do código – garantia de que todos os códigos afetados pela modificação continuem funcionando – é preservado, não havendo a introdução de novas funcionalidades.
De maneira análoga, a técnica Database Refactoring aprimora os aspectos estruturais – modelo de dados físico – e funcionais – objetos programados como stored procedures e triggers – de um banco de dados, preservando não só o comportamental semântico como também o informacional – garantia de que os dados permaneçam íntegros e com o conceito adequado. Contudo, para que funcione na prática, essa técnica requer sofisticada infra-estrutura e processos de testes – como testes de regressão – para garantir que as modificações não acrescentem defeitos no banco de dados em si ou nas interfaces entre este e os sistemas de informação.
O processo de refactoring de um banco de dados apresenta um conjunto de atividades cujo tipo de mudança determina quais delas serão opcionais ou dispensáveis. São elas:
1. Identificar a modificação a ser realizada;
2. Identificar a estratégia de refactoring apropriada;
3. Executar o refactoring do banco de dados
4. Escrever e aplicar os testes unitários apropriados;
5. Aplicar os testes de regressão apropriados;
6. Efetuar migração de dados, caso necessário;
7. Disponibilizar modificações em ambiente produtivo com a comunicação apropriada.
Exemplificando, o processo de refactoring de um banco de dados começa identificando a necessidade de uma modificação; a renomeação da coluna “FNAME” para “FIRSTNAME” na tabela de Clientes – ver estado “Inicial” na figura 1. Os desenvolvedores – com habilidades de programação e banco de dados – determinam à estratégia de refactoring e, trabalhando em par, realizam a modificação acrescentando uma nova coluna com o nome adequado e uma trigger que irá garantir a integridade dos dados entre as duas colunas – ver estado “Transição” na figura 1.
Figura 1 – Exemplo de Database Refactoring – Renomear a Coluna
Nesse momento são aplicados os testes necessários – unitários e de regressão – para garantir que a modificação não afete os sistemas de informação e outros objetos do banco de dados que utiliza a tabela modificada e, na inexistência de problemas, a modificação é implantada em produção.
O estado de “transição” permite que todos os impactados façam os ajustes indispensáveis, passando a utilizar a nova coluna – “FIRSTNAME” – até uma data limite estipulada. Findo este prazo, a coluna original e a trigger são removidas – ver estado “Final” na figura 1 – completando o processo de refactoring do banco de dados.
Obstáculos no uso da Técnica
O uso habitual do Database Refactoring ocorre em projetos de desenvolvimento que optam por algum dos processos ágeis disponíveis. Ademais, a técnica mostra-se aplicável em situações de manutenção de um banco de dados com o propósito de melhorar a qualidade dos dados, ajustar o desempenho ou mesmo flexibilizar o modelo de dados. Independente da situação, o emprego da técnica enfrenta obstáculos de ordem tecno-culturais, sendo as principais:
§ Aversão a Mudança de Processos
São notórias as dificuldades daquelas organizações que promovem mudanças internas, uma vez que somente uma pequena parcela dos afetados a recebe como oportunidade. Tal fato acaba exigindo boa parcela de investimento da organização e paciência por parte do gestor da mudança para atuar na parcela daqueles que vêem mudanças como ameaças.
Transformar o processo de projeção do banco de dados – da visão tradicional para a ágil – não é diferente, principalmente se considerarmos que o relacionamento entre as equipes de desenvolvimento e de dados ocorre com certo desentendimento.
§ Grau de Acoplamento
Em muitas organizações, a questão da interface com o banco de dados não constitui elemento amplamente discutido dentro da arquitetura de seus sistemas de informação. Essa negligência conduz, quase sempre, a uma forma de utilização dos bancos de dados que cria uma dependência desse para com os componentes funcionais – grau de acoplamento –, determinando que a alteração naquele exija a alteração nesses.
Esse cenário constitui-se um forte obstáculo à aplicação da técnica em virtude do grande esforço envolvido. Um modificação, por mais necessária que seja ou por melhor que sejam seus benefícios, tende a não encontrar respaldo da gerência de desenvolvimento, pois sempre existem outras prioridades.
Aplicando o Database Refactoring em soluções de Business Intelligence
O desenvolvimento de soluções de Business Intelligence – BI –, por sua natureza complexa, praticamente exige uma abordagem evolutiva na qual cada ciclo implica a entrega de um naco de dados integrados e íntegros, bem como dos respectivos componentes de armazenamento e de exploração. Sua forte orientação ao dado torna a preocupação sobre a estruturação dos dados algo natural; atendendo às necessidades informacionais prementes, mas deixando aberturas para as mudanças vindouras.
Frente a essas características, a aplicação da técnica de Database Refactoring não se mostra adequada para aplicação no processo de desenvolvimento de soluções de BI, pois um modelo estável – dentro de cada ciclo evolutivo – é imprescindível para a construção dos procedimentos de ETL. Contudo, a técnica apresenta maior potencial de emprego nas atividades de administração da solução, principalmente naquelas ligadas à melhoria do desempenho.
Conclusão
A idiossincrasia dos processos ágeis de desenvolvimento de software exige o alinhamento das técnicas e processos aplicados sobre os dados. Esse alinhamento, porém, deixa em aberto alguns pontos frente ao método tradicional de desenvolvimento – como qual dos modelos apresenta melhor nível de qualidade –, bem como não endereça a pouca cooperação das equipes responsáveis pela parte funcional e de dados. Pontos esses que merecem ser analisados futuramente.
Questionamentos à parte, é importante ressaltar que o Database Refactoring reforça a idéia de que modificações disciplinadas sobre um banco de dados são possíveis e viáveis, contraria a prática corrente de modificações emergenciais que se perpetuam. Empregar mecanismos que preservem os bancos de dados são importantes de forma a garantir o investimento realizado, bem como evitar o custo – construção, migração dos dados, testes – e impactos relativos à sua substituição.
Referências bibliográficas
AMBLER, Scott W. “Agile database techniques”. Editora Wiley, 2003.
FOWLER, Martin. “Refactoring: improving the design of existing code”. Editora Addison Wesley Longman, 1999.
THE AGILE ALLIANCE. www.agilealliance.org
THE AGILE DATA. www.agiledata.org
