Beyond schema evolution to database reorganization

Abstract

IntroductionWhile the c.ontents of databases can be easily changed, their organization is typically extremely rigid. Some databases relax the rigidity of database organization somewhat by supporting simpIe changes to individual schemas. As described in this paper, OTGen supports not only more ccmmplex schema changes, but also database reorganization.A database administrator uses a declarative notation to describe mappings between objects created with old versions of schemas and their corresponding representations using new versions. OTGen genemtes a transformer that applies the mappings to update tb: database to the new definitions, thus facilitating improvements in performance, functionality, and usability of the database.l Separation of interfaces from implementation is by now a generally accepted technique for localizing the effect of change. It gives the implementor the freedom of improving the code without affecting the client, while the latter can continue to use the specified interfaces and apply the provided operations as before. Only when client and implementor agree on a change in the specifications will it be necessary to modify the client's application.However, changes in either specification or implementation not only affect programs, but also the representation of persistent data objects. The problem of modifying software is not limited to changing code, but also affects existing data objects that were generated with that software prior to modification. It is thus necessary to address the problem of how to adapt existing objects to the new requirements imposed by the modified software.

A survey of schema versioning issues for database systems

“…Suggestions in the literature indicate that modification of the database schema to accommodate changes at the relation or class level (and above) can be achieved in a number of ways. For instance, within the object-oriented paradigm a common method is to establish a set of invariants to ensure the semantic integrity of the schema and a set of rules or primitives for effecting the schema changes (Banerjee, et al 1986;Bretl, et al 1989;Lerner and Habermann 1990) while within the relational model a set of atomic operations is proposed which result in a consistent and, as far as possible, reversible database structure (Shneiderman and Thomas 1982).…”

“…This results in longer schema modification time but reduces subsequent data access time. An interesting extension to this approach is given by Lerner and Habermann (1990) where a data transformation table generator is used to produce routines to assist the Database Administrator with the data conversion.…”

“…A recent (and growing) bibliography of schema evolution research (Roddick 1994) lists over 50 papers in the area of which only a handful are dated prior to 1987. This research has been in connection with both relational (Clifford and Croker 1987;Dadam and Teuhola 1987;McKenzie and Snodgrass 1990;Ariav 1991;Roddick 1991Roddick , 1992bVentrone and Heiler 1991) and object-oriented databases (Banerjee, et al 1986(Banerjee, et al , 1987a(Banerjee, et al , 1987bZdonik 1986, 1987;Zdonik 1986;Penney and Stein 1987;Chou and Kim 1988;Kim and Chou 1988;Bretl, et al 1989;Kim, et al 1989;Rieu 1989a, 1989b;Osborn 1989;Lerner and Habermann 1990). …”

Schema evolution and integration

“…Lerner's OTGen design [23] addresses the problem of complex evolutions requiring major structural conversions of the database (e.g., information moving between classes, sharing of data using pointers) using a special-purpose language to specify instance conversion procedures. As it was developed in an integrated database context, where the entire application set is recompiled whenever the schema changes, versioning and compatibility were not considered.…”

Type Evolution and Instance Adaptation

“…Lerner's OTGen design [15] addresses the problem of complex evolutions requiring major structural conversions of the database (e.g., information moving between classes, sharing of data using pointers) using a special-purpose language to specify instance conversion procedures. As it was developed in an integrated database context, where the entire application set is recompiled when schema changes, versioning and compatibility were not considered.…”