Refactoring Databases

1,789 views
1,670 views

Published on

Introdução à Refactoring Databases.
Processos de refactoring
Dificuldades no projeto
Exemplos de Refactoring
Testes de scripts
Deploy

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,789
On SlideShare
0
From Embeds
0
Number of Embeds
390
Actions
Shares
0
Downloads
58
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Refactoring Databases

  1. 1. Por: Ismael Soares
  2. 2. <ul><li>Objetivo </li></ul><ul><li>Problema e Solução (Abordagem Tradicional e Ágil)‏ </li></ul><ul><li>Refactoring e Database Refactoring </li></ul><ul><li>Categorias de Refactoring Database </li></ul><ul><li>Dificuldades </li></ul><ul><li>Processos de Refactoring Database </li></ul><ul><li>Exemplos práticos </li></ul><ul><li>Conclusão </li></ul>Agenda
  3. 3. Apresentar os conceitos de refatoração em banco de dados, o chamado Database Refactoring e apresentar alguns exemplos práticos. Objetivo
  4. 4. Após colocar em produção, como fazer os banco de dados evoluírem facilmente de acordo com os novos requisitos? Pergunta
  5. 5. Ou de forma mais específica, quem consegue mudar o nome de uma coluna do BD hoje e implantar essa alteração em produção amanhã? Pergunta
  6. 6. <ul><li>Abordagem Tradicional </li></ul><ul><ul><li>Análise... Análise... Análise........... Análise </li></ul></ul><ul><ul><li>Schema da base está disponível mais cedo e é isso que os desenvolvedores irão utilizar. </li></ul></ul><ul><ul><li>E se houver mudanças??? </li></ul></ul>Problema e Solução
  7. 7. Problema e Solução Modelo Cascata (Waterfall)‏ Desenvolvimento (Vários Meses ou Anos)‏ Testes (Dias)‏ Entrega Planejamento, Análise, Modelagem (Vários Meses)‏ Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Tabela Precisa Alterar o Modelo e agora?
  8. 8. <ul><li>Abordagem Ágil </li></ul><ul><ul><li>Processo Iterativo e Incremental </li></ul></ul><ul><ul><li>Feedback Rápido </li></ul></ul><ul><ul><li>Constante Inspeção e Adaptação </li></ul></ul><ul><ul><li>Agile DBA </li></ul></ul>Problema e Solução
  9. 9. Problema e Solução Idéia Abrangente Solução Iterativa e Incremental (Espiral) Iteração 01 (2 a 4 semanas)‏ (Planejamento, Modelagem, Desenvolvimento, Testes)‏ Tabela Tabela Tabela Tabela Software Iteração 02 (2 a 4 semanas)‏ (Planejamento, Modelagem, Desenvolvimento, Testes)‏ Software Tabela Tabela Tabela Tabela Iteração 03 (2 a 4 semanas)‏ (Planejamento, Modelagem, Desenvolvimento, Testes)‏ Tabela Tabela Tabela Tabela Software Iteração 04 (2 a 4 semanas)‏ (Planejamento, Modelagem, Desenvolvimento, Testes)‏ Software Tabela Tabela Tabela Tabela
  10. 10. “ Processo de alteração de um sistema de software de modo que o comportamento externo do código não mude, mas que sua estrutura interna seja melhorada.” “ É uma forma disciplinada de aperfeiçoar código que minimiza a introdução de falhas.” (Martin Fowler 2004)‏ O que é Refactoring?
  11. 11. “ É quando uma simples mudança no esquema de uma base de dados melhora a sua concepção (projeto), embora mantendo simultaneamente a sua semântica.” (Scott W. Ambler 2006)‏ O que é Data Base Refactoring?
  12. 12. “ Mudança disciplinada na estrutura de uma base de dados que não modifica sua semântica, porém melhora seu projeto e minimiza a introdução de dados inconsistentes.” (Fabrízio de Royes Mello 2009)‏ O que é Data Base Refactoring?
  13. 13. <ul><li>Mudanças nas estruturas de tabelas e/ou view’s. </li></ul><ul><ul><li>Mudar uma coluna de tabela. </li></ul></ul><ul><ul><li>Dividir uma coluna em duas, etc. </li></ul></ul>Categorias de Refactoring Databases
  14. 14. Melhoria na qualidade da informação. Fazendo uma coluna não-nula para garantir que ela sempre conterá um valor ou a aplicação de um formato comum para uma coluna para garantir a consistência. Categorias de Refactoring Databases
  15. 15. <ul><li>Melhorias para garantir a integridade dos dados. </li></ul><ul><ul><li>Adicionar uma trigger para exclusão em cascata. </li></ul></ul><ul><ul><li>Adicionar um chave estrangeira, etc. </li></ul></ul>Categorias de Refactoring Databases
  16. 16. <ul><li>Uma mudança que melhora a forma global em que programas </li></ul><ul><li>externos interagem com um banco de dados. </li></ul><ul><ul><li>Substituição de uma operação de Java existentes em uma </li></ul></ul><ul><ul><li>biblioteca de código compartilhado por um procedimento </li></ul></ul><ul><ul><li>armazenado no banco de dados. Tê-lo como um procedimento armazenado torna disponível para aplicações não Java. </li></ul></ul>Categorias de Refactoring Databases
  17. 17. <ul><li>Uma mudança para um método (um procedimento armazenado, função armazenado ou gatilho) que melhora a sua qualidade. </li></ul><ul><ul><li>Renomeando um procedimento armazenado para tornar mais fácil de entender. </li></ul></ul>Categorias de Refactoring Databases
  18. 18. <ul><li>Uma mudança no seu esquema de banco de dados que muda a sua semântica. </li></ul><ul><ul><li>Adicionar um coluna numa tabela existente. </li></ul></ul>Categorias de Refactoring Databases
  19. 19. Database Refactoring é mais difícil que Code Refactorings porque além de manter o comportamento também deve manter as informações. Dificuldades
  20. 20. Dificuldades
  21. 21. <ul><li>Scott Ambler (Julho 2006): </li></ul><ul><ul><li>95,7% consideram dados como bens </li></ul></ul><ul><ul><li>corporativos. </li></ul></ul><ul><ul><li>40,3% possuem bateria de testes para BD </li></ul></ul><ul><ul><li>61,9% possuem problemas com dados em produção. </li></ul></ul><ul><ul><li>18% sem estratégia para corrigi-los. </li></ul></ul><ul><ul><li>33% a estratégia é não deixar ficar pior </li></ul></ul>Dificuldades
  22. 22. Dificuldades
  23. 23. <ul><li>As mais conhecidas são: </li></ul><ul><ul><li>DBUnit </li></ul></ul><ul><ul><li>DBM Data Generator </li></ul></ul><ul><ul><li>NDbUni </li></ul></ul><ul><ul><li>Ounit </li></ul></ul><ul><ul><li>Quest Unit Tester </li></ul></ul><ul><ul><li>TSQLUnit </li></ul></ul>Dificuldades
  24. 24. Single-Database Application (Modelo Simples) BD Sistema Dificuldades
  25. 25. Multi-Application Database (Modelo complexo) Quanto maior o acoplamento mais dificil é a refatoração! Dificuldades BD Sistema A Sistema desconhecido Outros BD Testes de Integração Hibernate Interfaces Externas
  26. 26. Encapsulamento do acesso ao banco de dados. Como resolver o acoplamento?
  27. 27. <ul><li>Existe necessidade de refatorar? </li></ul><ul><li>Escolher o refactoring mais apropriado </li></ul><ul><li>Depreciar o esquema original </li></ul><ul><li>Testar antes, durante e depois </li></ul><ul><li>Modificar o esquema </li></ul><ul><li>Migrar os dados </li></ul><ul><li>Modificar código externo </li></ul><ul><li>Executar testes de regressão </li></ul><ul><li>Versionar seu trabalho </li></ul><ul><li>Anunciar o refactoring </li></ul>Processos de Refactoring Databases
  28. 28. SandBox (caixa de  areia)  é um ambiente de teste que isola as mudanças de código não testado no contexto do desenvolvimento de software, incluindo o desenvolvimento Web e controle de revisão. É uma espécie de branch específico para testes. Cada desenvolvedor que irá trabalhar no projeto deve ter um sandBox . Cada sandBox possui uma cópia do BD inteiro. SandBox
  29. 29. Devemos levar em conta três considerações: <ul><li>A refatoração é essencial? </li></ul><ul><ul><li>O dba ou arquiteto deve ter uma visão corporativa e técnica para dizer qual o melhor </li></ul></ul><ul><ul><li>esquema para atender as necessidades da empresa. </li></ul></ul><ul><li>É necessário fazer a mudança agora? </li></ul><ul><ul><li>Deve-se avaliar se este é o momento certo para fazer a refatoração. É preciso medir o </li></ul></ul><ul><ul><li>“ tamanho do gigante”. </li></ul></ul><ul><ul><li>Além disso, devemos avaliar qual é o risco que corremos se precisarmos voltar para o </li></ul></ul><ul><ul><li>esquema anterior depois de alguns dias. </li></ul></ul><ul><li>Valerá apenas o esforço? </li></ul><ul><ul><li>Deve-se avaliar os valores e impactos que a refatoração trará. Os profissionais estão </li></ul></ul><ul><ul><li>qualificados? Qual ou quanto é o custo benefício? </li></ul></ul>Antes de começar...
  30. 30. Exemplo de Database Refactoring
  31. 31. Exemplo de Database Refactoring
  32. 32. “ Mal cheiros” são sintomas para refatorar: <ul><li>– Colunas multi-uso </li></ul><ul><li>– Tabelas multi-uso </li></ul><ul><li>– Dados redundantes </li></ul><ul><li>– Tabelas com muitas colunas </li></ul><ul><li>– Tabelas com muitas linhas </li></ul><ul><li>– Colunas “espertas” </li></ul><ul><li>– Resistência a mudanças </li></ul>O que refatorar?
  33. 33. Ao fazer refactoring é de importante que a semântica seja mantida, ou seja, o esquema deve ser melhorada mas para o usuário, isto precisa ser transparente. Exemplo: Imagine que em uma tabela de cliente o número do telefone seja um varchar no seguinte formato: (416) 555-1234 , e será alterado para numérico: 4165551234. Mantendo a semântica
  34. 34. O que testar? <ul><li>Testar o esquema </li></ul><ul><li>Testar a forma que a aplicação utiliza o esquema do banco </li></ul><ul><li>Validar a migração dos dados </li></ul><ul><li>Testar o código de programas externos </li></ul>Test-Driven Development (TDD)
  35. 35. Test-Driven Development (TDD)
  36. 36. Testes do esquema <ul><li>Procedures e triggers: podem ser testados com o código que será usado após as alterações. </li></ul><ul><li>Integridade referencial: também precisa ser testado, principalmente quando faz exclusão em cascata. </li></ul><ul><li>Definição de views: views costumam implementar lógica de negócio interessante. Será que a filtragem lógica está selecionando os dados corretamente? Você recebe de volta o número correto de linhas? Você está retornando as colunas corretas? </li></ul><ul><li>Valores default: colunas muitas vezes têm valores padrão definidos para eles. Os valores padrões estão sendo utilizados de fato? (Alguém poderia ter removido acidentalmente esta parte da definição da tabela.) </li></ul><ul><li>Invariantes de dados: colunas têm freqüentemente invariantes, implementada sob a forma de restrições, definido por eles. Por exemplo, uma coluna de número pode ser limitada a que contém os valores de 1 a 7. Estes invariantes devem ser testados. </li></ul>Test-Driven Development (TDD)
  37. 37. Testes de migração dos dados <ul><li>Todos os registros foram migrados? </li></ul><ul><li>Houve perda de informações? </li></ul><ul><li>Nas refatorações de formatos, os registros continuam com a mesma informação? Exemplo : na coluna antiga o telefone estava formatada como: 114104-3333, depois da refactoring deve ficar 1141043333. </li></ul><ul><li>As referencias de integridade continuam apontando para o registro correto? </li></ul><ul><li>Exemplo: O número de telefone 555-1234 referencia o cliente Fulano da Silva, na refactoring foi adicionado um ID para este telefone 1234567. </li></ul>Test-Driven Development (TDD)
  38. 38. Testes do código de programas externos <ul><li>Quais são os programas que serão afetados com a refactoring do seu banco? </li></ul><ul><li>Todos programas externos devem possuir um suíte de testes de regressão, para garantir que o esquema final poderá aplicado nos mesmos. </li></ul><ul><li>Os impactos só poderão ser avaliados com a quebra dos testes, dependo da complexidade e arquitetura (tamanho dos sistemas). </li></ul>Test-Driven Development (TDD)
  39. 39. Modificando o esquema
  40. 40. Modificando o esquema
  41. 41. <ul><ul><li>Existem algumas vantagens em trabalhar com pequenos scripts: </li></ul></ul><ul><ul><ul><li>Controle: não existe mágica! Muitos scripts serão criados manualmente, isto requer muito controle. </li></ul></ul></ul><ul><ul><li>Simplicidade: por ser focado, os scripts de alterações são mais fáceis de manter do que scripts que compreende várias etapas. </li></ul></ul><ul><ul><li>Exatidão: possibilita aplicar cada refatoração, na devida ordem, ao seu esquema de banco de dados de modo a evoluir-lo de uma forma definida. Refactorings pode basear-se uns aos outros. </li></ul></ul><ul><ul><li>Versionamento: cada desenvolvedor pode trabalhar no seu próprio sandbox , alterando de forma incremental os scripts. </li></ul></ul>Modificando o esquema
  42. 42. Migração dos dados
  43. 43. <ul><li>O controle dos artefatos do banco de dados devem ser tratados da mesma forma que os do código fonte. </li></ul><ul><ul><li>“ Release Notes” - associar o número dos scripts da refatoração com a alteração realizada. </li></ul></ul><ul><li>Artefatos de controle de versão incluem o seguinte: </li></ul><ul><ul><li>Todos os scripts criados </li></ul></ul><ul><ul><li>Dados usados nos testes e geração de códigos </li></ul></ul><ul><ul><li>Casos de testes </li></ul></ul><ul><ul><li>Documentações </li></ul></ul><ul><ul><li>Modelos </li></ul></ul>Controle de versionamento
  44. 44. <ul><li>O banco de dados é um recurso compartilhado, portanto, todos os envolvidos precisam ser informados. </li></ul><ul><li>A refatoração pode ser informada através de um simples email ou listas com as alterações na ordem. </li></ul><ul><li>Devem ser informados os prazos para se refatorar os códigos dos sistemas externos. </li></ul><ul><li>Não publique as alterações prematuramente, aguarde até o fluxo de alterações tenha acabado. </li></ul>Anunciando o Refactoring
  45. 45. <ul><li>1. Fazer um backup do BD </li></ul><ul><li>2. Executar os testes de regressão </li></ul><ul><ul><li>Antes, é preciso garantir que tudo está funcionando </li></ul></ul><ul><ul><li>Se falhar, pode ser melhor abortar </li></ul></ul><ul><li>3. Implantar as alterações nas aplicações </li></ul><ul><li>4. Implantar as alterações no BD </li></ul><ul><li>5. Executar os testes de regressão </li></ul><ul><li>6. Desfazer, caso necessário </li></ul><ul><ul><li>Falhas sérias nos testes de regressão </li></ul></ul><ul><ul><li>Utilize os backups do passo 1 </li></ul></ul><ul><ul><li>Desfaça as alterações nas aplicações </li></ul></ul><ul><li>7. Anunciar a implantação </li></ul><ul><li>• A refatoração não está completa até a remoção do esquema depreciado </li></ul>Processos de implantação
  46. 46. <ul><li>Refactoring Databases é uma técnica de implementação de banco de dados. </li></ul><ul><li>Facilita a adição de novas funcionalidades. </li></ul><ul><li>Possibilita uma melhoria contínua. </li></ul><ul><li>Torna a base de dados mais fáceis de entender e usar. </li></ul><ul><li>Melhora a produtividade global do desenvolvimento. </li></ul><ul><li>Técnica moderna que acompanha metodologias de desenvolvimento ágil. </li></ul>Conclusão
  47. 47. Ambler, Scott W., Pramod J. Sadalage (2006). Refactoring Databases: Evolutionary Databases Design. New York: Addison Wesley Professional. http://www.ambysoft.com/books/refactoringDatabases.html   Ambler, Scott W., Pramod J. Sadalage (2006). Refactoring Databases: The Process. http://www.simple-talk.com/sql/database-administration/refactoring-databases-the-process/   Ambler, Scott W. (2007). Presentation Databases Refactoring. http://www.infoq.com/presentations/ambler-database-refactoring   Ambler, S. W. (2003). Agile Databases Techniques: Effective Strategies for the Agile Software Developer. New York: John Wiley & Sons. www.ambysoft.com/agileDatabasesTechniques.html Sato, Danilo e Ferreira, João Eduardo (2007). Banco de Dados Ágeis e Refatoração . Curso de Verão 2007 - IME/USP . http://ccsl.ime.usp.br/agilcoop/files/4-BDs-Ageis.pdf Bibliografia
  48. 48. Perguntas
  49. 49. Agradecimentos

×