Mudanas nos requisitos dos usurios so freqentes e tendem a causar alteraes em aplicaes.

A utilizao de mtodos geis para desenvolvimento tambm pode causar mudanas freqentes na aplicao, j que a mesma receber novos incrementos medida que novas funcionalidades vo sendo desenvolvidas. Em conseqncia, estas mudanas realizadas nas aplicaes podem refletir no(s) banco(s) de dados utilizados pelas mesmas e, portando, criam a necessidade de lidar corretamente com a evoluo do banco de dados. Alm disso, vrias aplicaes (que podem utilizar linguagens e tecnologias diferentes ou ter equipes distintas de desenvolvimento) podem estar utilizando o mesmo banco de dados. Para que no seja necessria a adequao preliminar de todas as aplicaes (o que poderia demandar muito tempo) para que o novo esquema possa vir a ser acessado/utilizado (ainda mais quando j existe uma aplicao pronta para se beneficiar das alteraes), no artigo props-se um perodo de transio, durante o qual so realizadas refatoraes do banco de dados e tanto o esquema antigo, como o novo coexistem. A refatorao de banco de dados consiste em uma tcnica para reestruturar os objetos de um banco de dados existente, alterando as estruturas desses objetos sem afetar a semntica informacional (significado das informaes do banco de dados do ponto de vista dos usurios destas informaes). O perodo de transio exige um cdigo de apoio para manter os dois esquemas sincronizados. A soluo proposta no artigo uma alternativa de organizao e estruturao do cdigo de apoio, dividida em trs etapas: (1) Coleta da transao, onde utiliza-se um trigger com o objetivo de capturar todas as informaes da transao; (2) Mapeamento, onde define-se um mapeamento de origem e destino das transaes; (3) Execuo, onde disparado um processo (com freqncia definida pelo usurio) para executar a sincronizao entre os esquemas antigo e novo. Quando estas trs etapas so executadas por triggers, a atualizao dos esquemas feita de forma sncrona. Porm, conforme proposto no artigo, a fase de Execuo (que quem realmente efetua o trabalho de atualizao) realizada posteriormente, tornando, portanto, a soluo assncrona. Um prottipo para automatizao denominado Database Evolution Manager (DEM) foi construdo e testado para validar a possibilidade do uso de ferramentas para auxiliar as evolues dos bancos de dados. Atravs de uma interface Web, o DEM pode realizar as seguintes atividades: (1) explorar tabelas do banco de dados; (2) gerar automaticamente um trigger coletor para a coleta das transaes; (3) criar uma tabela auxiliar para armazenar as transaes coletadas; (4) criar o mapeamento necessrio para a sincronizao; (5) executar o processo de sincronizao. Uma desvantagem para a utilizao de uma soluo assncrona o fato de que existe a possibilidade de as tabelas envolvidas em uma fatorao ficarem com os dados desatualizados durante o intervalo de tempo entre as sincronizaes. Porm, em contrapartida, a diminuio da utilizao de triggers (pois estes so usados em quantidade menor que na soluo do tipo sncrona) faz com que o desempenho do bando de dados melhore. Outra vantagem que no necessria a reescrita dinmica de consultas e procedures, uma vez que as verses dos esquemas so transitrias e devem coexistir com replicao de dados at que todas as aplicaes sejam atualizadas para usarem a verso mais nova do esquema. Crtica: A construo de ferramentas para sncronas no possvel?