refactoring databases

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


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?


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


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



Software

Tabela Tabela

Tabela

Tabela

Iteração 03(2 a 4 semanas)

,Planejamento, Modelagem)(Desenvolvimento, Testes



Tabela Tabela

Tabela

Tabela

SoftwareIteração 04

(2 a 4 semanas),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.


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.


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


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.


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.


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

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


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.


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.


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

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

refactoring databases

Technology