Database design and refactoring can be done in an agile and evolutionary way.
Data is only one of the many important aspects of software development, and rarely a primary one. Agile is developed from the “object” community, and sometimes suffers from a blind spot with regard to database development.
Databases can be built incrementally, with an evolutionary approach within the agile model. At the start of the project, spend around ten or fifteen minutes with the business owner to define the database structure at a high level – at this stage, attributes and behaviors are not discussed.
Having a small amount of upfront modeling is useful to avoid major changes later – but it is not necessary to do the amount of upfront modeling advocated by traditionalists.
The database is then built iteratively, evolving in the same way as the objects, with just enough tables and attributes at each stage to support the system. Visual Team Studio for Data Professionals supports this approach for database engineers.
Often expectations of the data community are low, we don’t expect them to be able to do “trivial” things, such as adding a field to a production database. But databases can be refactored while retaining both behavioural and informational semantics – in other words, without messing up the data.
Databases are generally tightly coupled to applications. Refactoring a production database, for example changing a field name, therefore affects a lot of applications. However, it can be done by creating a new field with a new name, using triggers to ensure it is kept up to date, and using a short transition period to allow developers to update all of the applications that will be affected. The “scaffolding code” is then removed.
Coupling is the main enemy of database refactoring – if this can be reduced, refactoring databases becomes more straightforward.
Recommended further reading
Agile Model Driven Development: http://www.agilemodeling.com/essays/amdd.htm