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 your 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, or you can Request Guest Access.
Database Refactoring: Improving Data Quality After the Fact November 2002

Become a Member

Research and inquiry privileges, plus regular strategy meetings with Cutter's Data Insight & Social BI experts are just some of the perks!
Want to learn more? Talk to Cutter today about trial membership, including access to research, webinars, podcasts, white papers and more.

Request trial membership