Esse artigo faz parte da revista SQL Magazine edição 60. Clique aqui para ler todos os artigos desta edição
a visão evolucionária sobre o processo de programação, possibilitando contínuas alterações com agilidade e rapidez.
A refatoração de banco de dados é um processo similar, porém, como o próprio nome diz, aplicado a sistemas de bancos de dados. Neste caso, trata-se de uma alteração no esquema do banco, visando alguma melhoria ou agregação de nova funcionalidade, sem, contudo, alterar seu comportamento ou semântica. Nesta alteração podem estar incluídos os mais diversos tipos de objetos como tabelas, visões, funções, procedimentos, gatilhos e seqüências. Por exemplo, a adição de uma coluna é um processo de refatoração bastante conhecido.
Para refatorar um banco de dados, normalmente é necessário rodar um script DDL. A complexidade deste script irá variar de acordo com o tipo de processo a ser empregado, e o número de objetos que dependem do objeto a ser refatorado.
Por exemplo, a adição de uma nova coluna a uma tabela não traz a princípio nenhum impacto sobre os demais objetos, pois trata-se de um novo objeto, que ainda não referencia e não é referenciado por nenhum outro.
Já a remoção da coluna, ao contrário do exemplo anterior, pode trazer grande impacto sobre outros objetos. Caso a coluna a ser removida participe de alguma chave primária ou estrangeira, ou faça parte de uma visão, todos estes objetos dependentes terão que ser também removidos ou remanejados. Essas alterações se tornam necessárias para evitar que o comportamento ou semântica do restante do esquema do banco seja corrompido.
Se ao invés de remover a coluna, o objetivo fosse deslocá-la para outra tabela, além do remanejamento de chaves, também se tornaria necessário migrar os dados da coluna antiga para a coluna nova. Em muitos casos essa migração não poderá ser efetuada usando recursos do SGBD, sendo necessário recorrer a soluções em nível de aplicação.
Alguns processos de refatoração podem ser executados com o auxílio de ferramentas CASE. No entanto, o suporte é limitado para processos mais complexos, especialmente aqueles que envolvem remanejamento de chaves e/ou migração de dados. Assim, os profissionais responsáveis pela alteração vêem-se obrigados a realizar o levantamento das dependências e do eventual impacto sobre outros objetos e codificar manualmente todas as alterações.
Neste artigo analisaremos alguns processos de refatoração de banco de dados. Como no total existem muitos processos, não será possível mostrar exemplos de todos. Assim, mostraremos alguns dos processos mais utilizados.
Para cada processo mostraremos uma situação que comprova que o seu uso por vezes se faz necessário. Além disso, cada exemplo será acompanhado de implementações que podem ser usadas para executar o processo. A codificação dos exemplos seguirá a sintaxe do banco de dados POSTGRESQL, um banco de dados open source muito utilizado atualmente.
Alteração do nome de tabelas/visões
A alteração do nome de uma tabela geralmente visa a escolha de um nome mais claro e intuitivo, ressaltando alguma característica ou função da tabela.
Alguns SGBDs já possuem funções ou comandos para renomear tabelas, enquanto que em outros os desenvolvedores são obrigados a criar uma nova tabela, migrar os dados e restrições, e remover a tabela antiga. No POSTGRESQL é possível renomear uma tabela com um único comando, conforme indicado a seguir:
ALTER TABLE TABELA RENAME TO NOVA_TABELA;
Caso o banco de dados não tenha esse recurso, mas tenha suporte à criação de tabelas com base em consultas, pode-se usar o comando mostrado na linha 1 da Listagem 1. Este não é um comando SQL ANSI, mas é suportado pela maioria dos bancos de dados do mercado, por exemplo, Oracle e SQL Server.
Listagem 1. Renomeando a tabela
1. //Criação da nova tabela com cópia dos dados:
2. CREATE TABLE NOVA_TABELA AS SELECT * FROM TABELA; ...
