OODBMS Schema Refactoring Catalogue

OO-Database Refactoring / Schema Evolution

Intention

This document shall look at the different refactorings that might occur to a OODBMS schema. It is also called schema evolution. In the RDBMS world schema refactoring is covered by brilliant web-sites like this. the respective huge catalog and Tools. But for a long time there was no equivalent for the OODBMS side. This site shall adress the need. So we need you input! If you have new refactorings or any ideas that can improve this site then let me know and send us an email to the adress listed at the bottom. Thanks!

Catalog

Name	Description & Solution
Rename Class	The name of the class must change
Split Class	Split one class into two parts. Should include method refactoring.
Merge Class	Merges two classes to be one class.

Name	Description & Solution
Delete field	A field from the class should be deleted
Add field	A new field is inserted into the class
Rename Field	The name of a field must change in the class
Change Field Type	You change the int productAmount to long productAmount
Merge Fields	Two fields from the same class should be merged. The common example is the string firstname and string surname field in classes, which often are getting merged to a single field string name.
Split Field	Is the reverse of above. Like a single name field to be split up to fields named firstname and surname
Move Field	Moves a field from class A to class B.

Name	Description & Solution
Change Class Hierarchy	Any deletion, insertation or modification of the inheritance structure. For example conisder a worse case: Class A->B->M->X->N->Y->C will get the inheritance structure A->C->B->Y->K->X->M. This means that classes change their position (like X and Y), classes will be deleted (like N) and classes will be inserted newly (as K).

Name	Description & Solution
Add Class	Trivial case. Must be covered by basic OODBMS operations
Delete Class	Trivial case. Must be covered by basic OODBMS operations
Change Interface	This means that the signature of the methods to be implemented change which mostly means that nothing notably will happen because only the attributes will change. Vendor support might differ from product to product converning the support of fields.

Under investigation: merge fields from different class, split fields to different classes. For further reading we suggest the following book:

** Advanced Database Systems**
by Carlo Zaniolo, Stefano Ceri, Christos Faloutsos, Richard T.
Snodgrass, V.S. Subrahmanian, Roberto Zicari
Publisher: Morgan Kaufmann (May 1, 1997)
Language: English
ISBN: 155860443X

Feedback

Any feedback or additions are welcome and shall be send to: edlich "on the host" gmail.com
I really appreciate your feedback and will work hard to incorporate your suggestions. If you suggest a refactoring that will survive indepndent examination we will cite you as it done in the famous refactoring catalog by Martin Fowler.