Banco de dados evolutivo

Levando-se em consideração o modelo sequencial (ou modelo em cascata) de desenvolvimento de software, no qual a concepção de um sistema é vista como um fluir constante para frente, através das fases de análises de requisitos, projeto, implementação, testes, integração e manutenção, mudanças causam problemas significativos, uma vez que todo trabalho é iniciado.

Em contrapartida, para lidar melhor com as constantes alterações de requisitos de sistema, surgiu uma nova geração de metodologias de desenvolvimento de software – as metodologias ágeis.

Uma das principais características dessas metodologias é a predisposição para lidar com mudanças. Elas buscam aceitar as modificações, controlando-as, em quaisquer fases do projeto até o fim do desenvolvimento.

A fim de aceitar o desafio de lidar com variações constantes no projeto de construção de um sistema, é necessário adotar um pensamento diferenciado. Em vez de conceber o design como uma fase isolada e, em grande parte, concluída antes do início do desenvolvimento, é preciso olhar para ele como um processo contínuo que intercala com a construção até o momento da entrega do software. Esse é o principal contraste entre o design planejado, como o da metodologia sequencial, e o design evolutivo das metodologias ágeis.

Apesar dessas novas técnicas terem crescido em uso e interesse, uma das maiores questões é como fazer o trabalho de design evolutivo para banco de dados.

É necessário que a estrutura do SGBD evolua em conjunto com o sistema para que se tenha sucesso na implementação dos métodos ágeis. E é sobre isso que esse artigo trata, sobre conceitos e técnicas de implementar a construção evolutiva da estrutura de banco de dados.

Colaboração contínua

Inicialmente, para que a ideia de design de banco de dados evolutivo possa funcionar e fluir bem onde ela estiver sendo aplicada, é necessário que algumas medidas sejam adotadas. Uma delas é uma colaboração contínua e irrestrita entre todo o time de desenvolvimento.

Não podem existir barreiras para essa comunicação. Em vez de decisões tomadas em reuniões formais, por exemplo, é preciso que ocorram conversas abertas entre todos os profissionais de forma a facilitar a comunicação.

Outra medida consiste em fazer com que cada atividade executada por um programador que afete, de alguma forma, a estrutura DDL ou DML do banco de dados seja feita em colaboração com o administrador de dados.

Assim, como o desenvolvedor sabe acerca da precisão de uma nova funcionalidade, o responsável pelo SGBD possui uma visão global dos dados e da estrutura do banco.

Dessa forma, será possível descobrir de que forma essa nova implementação irá afetar o esquema de banco de dados e qual a melhor forma de executá-la.

Instâncias de banco de dados - SandBox

O conceito de metodologia ágil reconhece que as pessoas aprendem coisas por tentar executá-las. Na programação podemos ver que os desenvolvedores experimentam formas de fazer determinada característica, podendo assim escolher uma melhor forma de implementá-la.

Com a base de dados não deve ser diferente. É preciso conceder a cada um dos desenvolvedores um banco de dados próprio (conhecido como sandbox). Dessa maneira, assim como na programação, o desenvolvedor poderá usar a imaginação em seu próprio ambiente, mexendo na estrutura da base de dados como bem quiser, sem que essas variações afetem alguém de alguma forma.

Muitos especialistas DBAs veem essa opção como muito difícil de funcionar na prática. Porém, observa-se que sim, é possível trabalhar com inúmeras bases. Mas para isso é essencial possuir ferramentas que manipulem as bases tão facilmente quanto se manipulam arquivos.

Banco de dados central - Master

Embora os desenvolvedores possam realizar as mudanças de forma distribuída, é importante unir essas diferentes mudanças em um único lugar novamen ...