Examinando o Database Refactoring

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Veja neste artigo um exame do 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.

25-01-2008pic01.JPG
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

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?