Refactoring Databases

Objetivo Problema e Solução (Abordagem Tradicional e Ágil)‏ Refactoring e Database Refactoring Categorias de Refactoring Database Dificuldades Processos de Refactoring Database Exemplos práticos Conclusão Agenda

Apresentar os conceitos de refatoração em banco de dados, o chamado Database Refactoring e apresentar alguns exemplos práticos. Objetivo

Após colocar em produção, como fazer os banco de dados evoluírem facilmente de acordo com os novos requisitos? Pergunta

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

Abordagem Tradicional Análise... Análise... Análise........... Análise Schema da base está disponível mais cedo e é isso que os desenvolvedores irão utilizar. E se houver mudanças??? Problema e Solução

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?

Abordagem Ágil Processo Iterativo e Incremental Feedback Rápido Constante Inspeção e Adaptação Agile DBA Problema e Solução

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

“ 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?

“ É 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?

“ 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?

Mudanças nas estruturas de tabelas e/ou view’s. Mudar uma coluna de tabela. Dividir uma coluna em duas, etc. Categorias de Refactoring Databases

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

Melhorias para garantir a integridade dos dados. Adicionar uma trigger para exclusão em cascata. Adicionar um chave estrangeira, etc. Categorias de Refactoring Databases

Uma mudança que melhora a forma global em que programas externos interagem com um banco de dados. Substituição de uma operação de Java existentes em uma biblioteca de código compartilhado por um procedimento armazenado no banco de dados. Tê-lo como um procedimento armazenado torna disponível para aplicações não Java. Categorias de Refactoring Databases

Uma mudança para um método (um procedimento armazenado, função armazenado ou gatilho) que melhora a sua qualidade. Renomeando um procedimento armazenado para tornar mais fácil de entender. Categorias de Refactoring Databases

Uma mudança no seu esquema de banco de dados que muda a sua semântica. Adicionar um coluna numa tabela existente. Categorias de Refactoring Databases

Database Refactoring é mais difícil que Code Refactorings porque além de manter o comportamento também deve manter as informações. Dificuldades

Scott Ambler (Julho 2006): 95,7% consideram dados como bens corporativos. 40,3% possuem bateria de testes para BD 61,9% possuem problemas com dados em produção. 18% sem estratégia para corrigi-los. 33% a estratégia é não deixar ficar pior Dificuldades

As mais conhecidas são: DBUnit DBM Data Generator NDbUni Ounit Quest Unit Tester TSQLUnit Dificuldades

Single-Database Application (Modelo Simples) BD Sistema Dificuldades

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

Encapsulamento do acesso ao banco de dados. Como resolver o acoplamento?

Existe necessidade de refatorar? Escolher o refactoring mais apropriado Depreciar o esquema original Testar antes, durante e depois Modificar o esquema Migrar os dados Modificar código externo Executar testes de regressão Versionar seu trabalho Anunciar o refactoring Processos de Refactoring Databases

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

Devemos levar em conta três considerações: A refatoração é essencial? O dba ou arquiteto deve ter uma visão corporativa e técnica para dizer qual o melhor esquema para atender as necessidades da empresa. É necessário fazer a mudança agora? Deve-se avaliar se este é o momento certo para fazer a refatoração. É preciso medir o “ tamanho do gigante”. Além disso, devemos avaliar qual é o risco que corremos se precisarmos voltar para o esquema anterior depois de alguns dias. Valerá apenas o esforço? Deve-se avaliar os valores e impactos que a refatoração trará. Os profissionais estão qualificados? Qual ou quanto é o custo benefício? Antes de começar...

Exemplo de Database Refactoring

“ Mal cheiros” são sintomas para refatorar: – Colunas multi-uso – Tabelas multi-uso – Dados redundantes – Tabelas com muitas colunas – Tabelas com muitas linhas – Colunas “espertas” – Resistência a mudanças O que refatorar?

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

O que testar? Testar o esquema Testar a forma que a aplicação utiliza o esquema do banco Validar a migração dos dados Testar o código de programas externos Test-Driven Development (TDD)

Testes do esquema Procedures e triggers: podem ser testados com o código que será usado após as alterações. Integridade referencial: também precisa ser testado, principalmente quando faz exclusão em cascata. 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? 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.) 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. Test-Driven Development (TDD)

Testes de migração dos dados Todos os registros foram migrados? Houve perda de informações? 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. As referencias de integridade continuam apontando para o registro correto? Exemplo: O número de telefone 555-1234 referencia o cliente Fulano da Silva, na refactoring foi adicionado um ID para este telefone 1234567. Test-Driven Development (TDD)

Testes do código de programas externos Quais são os programas que serão afetados com a refactoring do seu banco? Todos programas externos devem possuir um suíte de testes de regressão, para garantir que o esquema final poderá aplicado nos mesmos. Os impactos só poderão ser avaliados com a quebra dos testes, dependo da complexidade e arquitetura (tamanho dos sistemas). Test-Driven Development (TDD)

Existem algumas vantagens em trabalhar com pequenos scripts: Controle: não existe mágica! Muitos scripts serão criados manualmente, isto requer muito controle. Simplicidade: por ser focado, os scripts de alterações são mais fáceis de manter do que scripts que compreende várias etapas. 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. Versionamento: cada desenvolvedor pode trabalhar no seu próprio sandbox , alterando de forma incremental os scripts. Modificando o esquema

O controle dos artefatos do banco de dados devem ser tratados da mesma forma que os do código fonte. “ Release Notes” - associar o número dos scripts da refatoração com a alteração realizada. Artefatos de controle de versão incluem o seguinte: Todos os scripts criados Dados usados nos testes e geração de códigos Casos de testes Documentações Modelos Controle de versionamento

O banco de dados é um recurso compartilhado, portanto, todos os envolvidos precisam ser informados. A refatoração pode ser informada através de um simples email ou listas com as alterações na ordem. Devem ser informados os prazos para se refatorar os códigos dos sistemas externos. Não publique as alterações prematuramente, aguarde até o fluxo de alterações tenha acabado. Anunciando o Refactoring

1. Fazer um backup do BD 2. Executar os testes de regressão Antes, é preciso garantir que tudo está funcionando Se falhar, pode ser melhor abortar 3. Implantar as alterações nas aplicações 4. Implantar as alterações no BD 5. Executar os testes de regressão 6. Desfazer, caso necessário Falhas sérias nos testes de regressão Utilize os backups do passo 1 Desfaça as alterações nas aplicações 7. Anunciar a implantação • A refatoração não está completa até a remoção do esquema depreciado Processos de implantação

Refactoring Databases é uma técnica de implementação de banco de dados. Facilita a adição de novas funcionalidades. Possibilita uma melhoria contínua. Torna a base de dados mais fáceis de entender e usar. Melhora a produtividade global do desenvolvimento. Técnica moderna que acompanha metodologias de desenvolvimento ágil. Conclusão

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

Refactoring Databases

Mais conteúdo relacionado

Destaque (20)

Semelhante a Refactoring Databases (20)

Mais de Ismael (20)

Último (11)

Refactoring Databases