Database Refactoring: Improving Data Quality After the Fact

by Scott W. Ambler

It is very easy to say that everyone should take data quality considerations into account when they are modeling a system, but that doesn't always work in practice. What do you do when a database with data quality problems already exists in production? What do you do when a new database has been partially designed and implemented, and a new/changed requirement shows that your current database isn't sufficient? These situations come up all the time. The implication is that you need a way to easily improve both the quality of the data within your databases, as well as the quality of the schema design itself -- after the fact. An emerging technique that supports both iterative and incremental development -- a cornerstone of agile software development techniques such as Extreme Programming (XP) [4] and Feature-Driven Development [6] -- is database refactoring.

Password Protected Cutter Consortium clients, please log in:


This document is available to Cutter Consortium Resource Center clients only. Retrieve password.
If you would like further information about how to become a client, please contact us at +1 781 648 8700 or sales@cutter.com.
Database Refactoring: Improving Data Quality After the Fact November 2002