suportar o esquema original e o esquema resultante ao mesmo tempo, para somente quando todas aplicacoes estiverem suportando apenas o esquema resultante, ou novo esquema, voce podera aposentar de vez o antigo esquema e assim finalizar este periodo.Estrategias de Database RefactoringsExistem alguns pontos a considerar com estrategias para adocao de um database refactoring:Pequenas mudancas sao mais faceis de aplicar;Identifique unicamente cada refactoring;Implemente uma grande mudanca realizando varias pequenas mudancas;Tenha uma tabela de configuracao/versionamento do seu banco de dados;Priorize triggers ao inves de views ou sincronizacoes em lote;Escolha um periodo de transicao suficiente para realizar as mudancas;Simplifique sua estrategia de controle de versao de banco de dados;Simplifique negociacoes com outros times;Encapsule acesso ao banco de dados;Habilite-se a montar facilmente um ambiente de banco de dados;Nao duplique SQL;Coloque os ativos de banco de dados sobre controle de mudancas;Seja cuidadoso com politicas.Os items acima mostram apenas algumas sugestoes, em forma de "licoes aprendidas", de algumas estrategias que voce pode considerar quando tiver a necessidade de realizar um refactoring.Para apoiar essas estrategias existe um catalogo que descrevem diversos tipos de refactorings em bancos de dados e exemplos de uso, que veremos a seguir.Catalogo de Database RefactoringsEste catalogo e dividido em algumas categorias:Structural: sao mudancas na estrutura do banco de dados (tabelas, colunas, visoes, etc).Data Quality: sao mudancas que melhoram a qualidade das informacoes contidas em um banco de dados.Referential Integrity: sao mudancas que asseguram que uma linha referenciada exista em outra relacao e/ou assegura que uma linha que nao e mais necessaria seja removida apropriadamente.Architectural: sao mudancas que melhoram a maneira que programas externos interagem com a base de dados.Method: sao mudancas que melhoram a qualidade de uma Procedure um Funcao.Transformations: mudancas que alteram a semantica do esquema do banco pela adicao de novas funcionalidades.No meu github e possivel encontrar exemplos praticos de aplicacao passo-a-passo de um refactoring em um modelo inicial, passando por um periodo de transicao e chegando ao modelo final. Consideracoes FinaisDevemos levar em consideracao que apesar destas tecnicas serem direcionadas para refatoracao, ou seja, mudar estrutura sem mudar sua semantica, as mesmas podem e devem ser utilizadas para evolucao da sua aplicacao, ou seja, se voce precisa construir uma nova feature em sua aplicacao que esta em producao, voce podera recorrer das praticas aqui apresentadas para evoluir seu esquema de forma mais consistente e segura.Baseado no exposto podemos facilmente responder a pergunta "Por que Refatorar?":aceitar mudanca de escopo;fornecer feedback rapido;melhoria continua;aumentar simplicidade para facilitar entendimento;tornar os modelos mais proximos do mundo real;termos modelos simples para facilitar:manutencao eevolucao da aplicacaoE para refatorarmos precisamos ter conhecimento, disciplina, simplicidade, bom senso e persistencia, sem contar no ponto fundamental que e organizacao.ReferenciasLivros: Refactoring Databases (Scott W. Ambler e Pramod J. Sadalage)Agile Database Techniques (Scott W. Ambler)Refactoring (Martin Fowler)Agile Modeling (Scott W. Ambler) Links:http://www.agiledata.orghttp://www.databaserefactoring.orghttp://visaoagil.wordpress.comhttp://www.refactoring.comhttp://www.postgresql.orghttp://www.epictest.orghttp://www.slideshare.net/diogobiazus/testes-unitarios-com-postgre-sqlSlideshttp://www.slideshare.net/fabriziomello/tag/refactoringhttp://www.slideshare.net/antonkeks/database-refactoring