Graceful Database Schema Evolution

Abstract

When transforming old schema into new schema, much effort was put on examining key and inclusion dependency (ID) constraints to identify class and establish inheritance and association between classes. However, in order to further remove the original data redundancy and update anomaly, multi-valued dependency (MVD) should also be examined. In this paper, we discuss class structures and define well-structured classes. Based on MVDs, a theorem is given transforming a relation schema into a well-structured class. To transform old schema into new schema, a composition process simplifying the input old schema and an algorithm transforming the simplified old schema into well-structured new classes are developed.

Graceful Database Schema Evolution

1. Introduction

With the development of object-oriented technology, old schemas are seeking ways to transit to new schemas. This makes transforming old schema into new schema an important task and considerable effort has been seen on this topic. All studies done so far focus on examining keys and key-based inclusion dependency (IDs) to identify classes and derive inheritance and association between classes. Such transformation scheme usually results in classes having the same flat structure as the original relation schemas. In our view, however, this kind of class structure fails to make use of the OO modeling power to the largest extent and has not eliminated the data redundancy and update anomaly problem existing in the original old schema. Example 1 below explains the notion of class structure.tmp-buf

Table 1: Relation service

How are we going to transform Service into a class? The most direct approach is as follows:

class Service-1 (

flight: int,

working-day: string,

plane-type: int

);

With this class definition, corresponding to each tuple of relation service we have an object in class Service-1 (Table 2). In Table 2 each row represents an object and object identifiers (OIDs) are explicitly listed. However, data redundancy of the original relation is retained. When we update the value of plane-type for object O1 from 747 to 727, to maintain the MVDs holding on Service, we must change the value of plane-type for object O2 accordingly. In other words, with such schema transformation, we must use the method mechanism of the OO model to enforce the MVDs of the relational model.

Table 2: Class Service-1

A more appropriate class structure for this transformation is as follows:

class Service-2 (

flight: int,

working-day: set(string),

plane-type: set(int)

);

As shown in Table 3, under this class definition, there are only two objects in the resulting class. Objects are no longer in 1 : 1 correspondence with tuples of the original relation, instead, an object is the composition of several tuples. No information is lost, but the data redundancy of the original relation is completely removed. When we change the value of either plane-type or working-day of one object, only that object itself is affected. The MVDs on Service are built into the class definition and enforced by that attributes working-day and plane-type are defined to be set-valued.

Table 3: Class Service-2

Comparing the two classes Service-1 and Service-2 defined over the same attribute set, we say they are of different structures. Moreover, we say Service-2 is well-structured but Service-1 is ...