Por: Ismael Soares
Agenda
• 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
Objetivo
Apresentar os conceitos de refatoração em banco de dados, o chamado Database
Refactoring e apresentar alguns exemplos práticos.
Pergunta
Após colocar em produção, como fazer osbanco de dados evoluírem facilmente de
acordo com os novos requisitos?
Pergunta
Ou de forma mais específica, quemconsegue mudar o nome de uma coluna
do BD hoje e implantar essa alteraçãoem produção amanhã?
Problema e Solução
• 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
Modelo CascataModelo Cascata(Waterfall)(Waterfall)
Desenvolvimento(Vários Meses ou Anos)
Testes (Dias)
Entrega
Planejamento, Análise, Modelagem(Vários Meses)
Tabela Tabela
Tabela
TabelaTabela
TabelaTabela
Tabela
Tabela
Tabela
Tabela Tabela
TabelaTabela
Tabela Tabela
Tabela TabelaPrecisa Alterar o Modelo e agora?
Precisa Alterar o Modelo e agora?
Problema e Solução
• Abordagem Ágil– Processo Iterativo e Incremental– Feedback Rápido– Constante Inspeção e Adaptação– Agile DBA
Problema e Solução
IdéiaAbrangente
Solução Iterativa e Incremental (Espiral)Solução Iterativa e Incremental (Espiral)
Iteração 01(2 a 4 semanas)
,Planejamento, Modelagem)(Desenvolvimento, Testes
Iteração 01(a 4 semanas 2)
(Planejamento, Modelagem,Desenvolvimento, Testes)
Tabela Tabela
Tabela
Tabela
SoftwareIteração 02
(2 a 4 semanas),Planejamento, Modelagem)(Desenvolvimento, Testes
Iteração 02(a 4 semanas 2)
(Planejamento, Modelagem,Desenvolvimento, Testes)
Software
Tabela Tabela
Tabela
Tabela
Iteração 03(2 a 4 semanas)
,Planejamento, Modelagem)(Desenvolvimento, Testes
Iteração 03(a 4 semanas 2)
(Planejamento, Modelagem,Desenvolvimento, Testes)
Tabela Tabela
Tabela
Tabela
SoftwareIteração 04
(2 a 4 semanas),Planejamento, Modelagem)(Desenvolvimento, Testes
Iteração 04(a 4 semanas 2)
(Planejamento, Modelagem,Desenvolvimento, Testes)
Software
Tabela Tabela
Tabela
Tabela
O que é Refactoring?
“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 é Data Base 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)
“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?
Categorias de Refactoring Databases
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.
Dificuldades
Database Refactoring é mais difícil que Code Refactorings porque além de manter o comportamento também
deve manter as informações.
Dificuldades
Dificuldades
Scott Ambler (Julho 2006):95,7% consideram dados como bens corporativos.40,3% possuem bateria de testes para BD61,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
Dificuldades
As mais conhecidas são:
DBUnit DBM Data GeneratorNDbUniOunitQuest Unit TesterTSQLUnit
Dificuldades
Single-Database Application(Modelo Simples)
BDBD
SistemaSistema
Dificuldades
Multi-Application Database(Modelo complexo)
BDBD
Sistema A
Sistema A
Sistema desconhecido
Sistema desconhecido
Outros BD
Outros BD
Testes de Integração
Hibernate
Interfaces Externas
Quanto maior o acoplamento mais dificil é a refatoração!
Como resolver o acoplamento?
Encapsulamento do acesso ao banco de dados.
Processos de Refactoring Databases
• 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
SandBox
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.
Antes de começar...
Devemos levar em conta três considerações:
1. 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.
2. É 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.
3. 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?
Exemplo de Database Refactoring
Exemplo de Database Refactoring
O que refatorar?
“Mal cheiros” são sintomas para refatorar:
1. – Colunas multi-uso2. – Tabelas multi-uso3. – Dados redundantes4. – Tabelas com muitas colunas5. – Tabelas com muitas linhas6. – Colunas “espertas”7. – Resistência a mudanças
Mantendo a semântica
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.
Test-Driven Development (TDD)
O que testar?
1. Testar o esquema2. Testar a forma que a aplicação utiliza o esquema do banco3. Validar a migração dos dados4. Testar o código de programas externos
Test-Driven Development (TDD)
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).
Modificando o esquema
Modificando o esquema
Modificando o esquema
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.
Migração dos dados
Controle de versionamento
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: o Todos os scripts criadoso Dados usados nos testes e geração de códigoso Casos de testeso Documentações o Modelos
Anunciando o Refactoring
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.
Processos de implantação
1. Fazer um backup do BD2. Executar os testes de regressão
Antes, é preciso garantir que tudo está funcionandoSe falhar, pode ser melhor abortar
3. Implantar as alterações nas aplicações4. Implantar as alterações no BD5. Executar os testes de regressão6. Desfazer, caso necessário
Falhas sérias nos testes de regressãoUtilize os backups do passo 1Desfaç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
Conclusã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.
Bibliografia
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
Perguntas
Agradecimentos