Here’s a little something about Database Refactoring I found in the blogosphere.
Although the methodology of refactoring code has been adopted enthusiastically, the same has not really been the case with databases. Nick [Harrison] argues that the reason could lie in the extent of the task of unpicking complex databases systems sufficiently to make them more efficient and effective: and this will only be ameliorated with better tools and planning to support the techniques.
Respectfully disagree. Don’t get me wrong: There is no doubt that many implemented databases are inefficient and ineffective. Likewise, better tools and planning would surely be a good thing.
But the difficulty of Database Refactoring is more fundamental, and good tools won’t change the fundamental realities. Most “database refactorings” alter the semantic expressiveness of the data model, and one way or another, such changes will always be evident to the users of the system. That is, most database refactorings are not refactorings at all, because they do change the functional requirements of the database.
Remember, code refactoring should improve code without changing its functional requirements. Here’s the Wikipedia entry for refactoring:
Code refactoring is "a disciplined way to restructure code", undertaken in order to improve some of the nonfunctional attributes of the software. Typically, this is done by applying series of "refactorings", each of which is a (usually) tiny change in a computer program's source code that does not modify its functional requirements. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility.
The real reason why database refactoring is used less than code refactoring is that database experts know that very few database modifications achieve this standard. Almost all database modifications alter the functional capabilities of the database.