OODBMS Schema Refactoring Catalogue

OO-Database Refactoring / Schema Evolution


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!


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


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.

(C) Prof. Dr. Stefan Edlich
TFH-Berlin, agileodb.com