Prof: Thiago Moraes Martins Bacharel em Sistemas de Informa ç ão

1. Prof: Thiago Moraes Martins Bacharel em Sistemas de Informação Pós-Graduação Software Livre Aplicado Pós-Graduação Analista de Sistemas Pós-Graduação Metodologia do Ensino Superior Mestrado Engenharia de Software (Andamento) Certificado ITIL Certificado COBIT Certificado CWSP

2. Refactoring de Banco de Dados

3. Para que serve: As técnicas de refactoring de banco de dados permitem evoluir de forma segura o design de um esquema em pequenos passos. Além disso, elas ainda podem ser utilizadas para apoiar o desenvolvimento de software evolutivo. Em que situação o tema útil: Além de serem muito úteis na migração de bancos de dados legados, as técnicas apresentadas neste artigo permitem alterações em esquemas que já estejam em produção. Sendo esta uma das grandes dificuldades das empresas de desenvolvimento de software

4. As empresas de desenvolvimento de software têm evoluído constantemente. Muitas delas devem isto às novas e modernas metodologias ágeis que defendem a construção do software de maneira incremental e iterativa. Entretanto, disponibilizar sistemas de informação com qualidade em ciclos cada vez menores, ainda é uma missão desafiadora para muitas delas. Isto porque, é preciso garantir que a cada entrega, o sistema não perderá as suas funcionalidades e continuará sem erros. Além do mais, estas metodologias não prevêem a mesma iteratividade para o banco de dados. Para finalizar, algumas destas empresas ainda utilizam bancos de dados legados e não migram para sistemas mais novos por diversos motivos, dentre eles:

5. - Complexidade;- Alto custo;- Mudança de cultura da empresa;- Falta de conhecimento dos desenvolvedores;- Mudanças de paradigmas dos DBAs.

7. É neste cenário que surge a figura do DBA ágil. Diferente do DBA comum, este participa de todas as iterações do projeto, planejando o esquema do banco de dados e apoiando a equipe de desenvolvimento.

8. Figura 1. Modelo Cascata.

10. 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 e o significado dos dados que já estão persistidos. O processo de refactoring de banco de dados define a forma de evoluir de maneira segura um esquema em pequenos passos (incremental e evolutivamente). Ela também fornece uma estratégia coerente para organizações que querem migrar seus bancos de dados legados para outros mais modernos.

11. Figura 2. Modelo Espiral.

12. Conceitualmente, refactoring de banco de dados é mais difícil que refactoring de código. Isto porque, refactoring de código precisa apenas manter a semântica comportamental, enquanto refactoring de banco de dados, além de ter esta obrigação, ainda precisa assegurar a semântica informacional. A complexidade de um projeto de refactoring de banco de dados pode ser ainda maior em ambientes onde a arquitetura de acesso aos dados é altamente acoplada, como o exemplo da Figura 3.

13. Figura 3. Modelo complexo de arquitetura de acesso aos dados.

16. O que deve ser refatorado?- Tabela genérica: quando uma tabela está sendo usado para armazenar vários tipos de entidades, é provável que exista uma falha de projeto. Um exemplo é a tabela de pessoa, onde são inseridas informações de clientes e de fornecedores. O problema é que cliente e fornecedor têm as suas diferenças, e desta forma, a tabela conterá colunas que só serão preenchidas quando o tipo da pessoa for um ou outro; - Coluna genérica: desta mesma forma, se uma coluna está sendo usada para vários fins, é provável que exista um código extra para identificar os dados contidos nela.

17. Um exemplo é uma coluna da tabela de pessoa usada para armazenar data de nascimento de um cliente ou a data de admissão de um empregado. A única forma saber se o dado contido nesta coluna é uma data de admissão ou uma data de nascimento, é verificando outra coluna que identifique a pessoa. Agora suponha que seja necessário adicionar a data de nascimento do empregado, se for criado uma nova coluna, a tabela ficará ainda mais redundante; • Dados redundantes: os dados redundantes é um problema grave nos • bancos de dados operacionais, pois quando os dados são armazenados • em vários locais, a possibilidade de inconsistência é muito grande. • É comum, por exemplo, ter informações de clientes armazenadas em • locais diferentes, e no momento em que estes dados necessitarem de • manutenção será difícil saber qual deles é o correto;

18. Dados redundantes: os dados redundantes é um problema grave nos • bancos de dados operacionais, pois quando os dados são armazenados • em vários locais, a possibilidade de inconsistência é muito grande. • É comum, por exemplo, ter informações de clientes armazenadas em • locais diferentes, e no momento em que estes dados necessitarem de • manutenção será difícil saber qual deles é o correto;

20. Antes de começar Antes de começar um projeto de refactoring de banco de dados, leve em consideração as recomendações a seguir: Verifique se o refactoring é mesmo necessário, pois talvez a estrutura do modelo atual esteja correta. É comum os desenvolvedores discordarem, ou simplesmente não compreender o projeto existente de um banco de dados. Este mal-entendido poderá levá-los a acreditar que o projeto precisa ser alterado quando ele realmente não precisa.

21. O DBA deve ter um bom conhecimento do esquema do banco de dados, e em casos de haver sistemas externos acessando-o, ele deve saber quem contatar para discutir questões técnicas e tomar as medidas cabíveis.   Além disso, o DBA, por ter participado de diversos projetos relacionados ao esquema do banco de dados, conhece o panorama global da empresa, possuindo uma visão importante que pode não estar aparente do ponto de vista dos desenvolvedores;

22. - É preciso ter em mente que nenhuma estrutura deve ser tão rígida a ponto de ser inalterável, isto porque, pequenas melhorias sempre irão acontecer; - Divida o seu projeto de refactoring em pequenas etapas para facilitar o controle e a compreensão de todos os profissionais envolvidos. Entretanto, isto exigirá um controle rigoroso sobre o versionamento das alterações. Por exemplo: imagine que em uma etapa qualquer, você altere o nome da coluna de uma tabela, e algumas semanas depois, seja necessário mover a mesma coluna para outra tabela. Se estas alterações não forem aplicadas no momento adequado e não estiverem versionadas, a última refatoração poderá ser executada antes da primeira;

23. Evite duplicações de código SQL. Utilize um framework de persistência • para encapsular o acesso ao banco de dados.

24. Qual a melhor estratégia de refatoração?1. Avaliação do impacto: antes de fazer qualquer alteração na estrutura, deve-se avaliar o tamanho do impacto, tanto interno quanto externo, ou seja, descobrir todas as views, triggers, procedures, constraints e sistemas que serão afetados com a mudança; 2. Definição do período de transição: após fazer a avaliação acima, será possível definir com maior precisão o período de transição. Entretanto, deve-se fazer um controle rigoroso para garantir que os prazos estabelecidos serão seguidos;3. Criação e execução de testes: antes de alterar o modelo é preciso garantir que atualmente ele está funcionando. Crie testes automatizados para facilitar a identificação e correção dos impactos causados pelas refatorações;

25. 4. Executar a refatoração: crie os scripts necessários para aplicar a refatoração e adicione os comentários nas colunas, tabelas e triggers que serão removidas após o período de transição; 5. Execute os testes: antes de anunciar as refatorações feitas, é preciso garantir que nada do que estava funcionando deixou de funcionar. Para isto, execute os testes criados antes da refatoração e caso algum deles falhe, faça as correções necessárias;6. Alteração das dependências internas e externas: se for possível, faça as alterações necessárias nos objetos internos (triggers, procedures, etc.) e externos (sistemas, outros bancos de dados, etc.) em paralelo. Caso contrário, prefira iniciar as alterações pelos objetos internos, já que estão mais próximos do seu domínio.

28. Substituir associações um para muitos por tabelas associativas. • Ao implementar a refactoring estrutural, leve em consideração alguns • impedimentos comuns que certamente aparecerão. Dentre os quais se • podem listar:- Triggers circulares: em quase todas as refactorings que alteram a • estrutura do modelo, é comum o uso de triggers para controlar o • sincronismo dos dados. Em alguns casos, podem-se ter duas ou mais • triggers, uma disparando a outra. E se não houver um controle rigoroso, • elas entrarão num loop infinito comprometendo o desempenho do banco • de dados;- Objetos do banco que acessam a tabela: é muito comum, durante este • tipo de refatoração, deixar para trás alguns objetos que fazem referências • às tabelas alteradas. Exemplos: views, triggers, stored procedures, etc.

29. Qualidade de dados As implementações feitas nesta categoria visam melhorar a qualidade das informações contidas no banco de dados. São elas:- Adicionar tabelas de consulta;- Padronização de siglas;- Aplicar tipos padrões para evitar, por exemplo, que em uma tabela uma informação seja do tipo varchar e em outra ela seja do tipo numérico;- Adicionar ou remover chaves estrangeiras;- Adicionar ou remover valores padrões em colunas;- Mover dados de uma tabela para outra.

30. Integridade referencial As implementações feitas nesta categoria visam garantir a integridade dos dados. São elas: - Adicionar ou remover chave estrangeira;- Adicionar trigger para coluna calculada;- Adicionar exclusão em cascata;- Adicionar trigger para armazenar em log as alterações.

31. Adicionar métodos CRUD (procedures para inserção, consulta, • atualização e exclusão);- Adicionar encapsulamento à tabela através de views;- Adicionar métodos de cálculos;- Adicionar tabelas apenas para leituras;- Migrar métodos dos sistemas externos para o banco de dados.