Schema and Database Evolution in Object. Database Systems. Project Progress Report. Parag Mahalley. Jayesh Govindrajan. Swathi Subramanium

Transcription

1 Schema and Database Evolution in Object Database Systems Project Progress Report By Parag Mahalley Jayesh Govindrajan Swathi Subramanium Anuja Gokhale Advisor: Elke A.Rundensteiner CS Database Management Systems November 1, 1997 Abstract In most database applications schema changes are seen frequently. After every schema change in a database, it is very important that the database be changed such that the schema and the database stay consistent with each other. Our project covers the implementation of the immediate and deferred approach to database evolution. We describe the overall design that we shall use for this implementation. We also present our proposal on developing a cost model for measuring performance of Immediate and Deferred. This model would be used to obtain a hybrid strategy intermixing the deferred and the immediate technique.

2 1 Introduction In most database applications schema changes are seen frequently. After every schema change in a database, it is very important that the database be updated such that the schema and the database stay consistent with each other. Our project covers the implementation of the immediate and deferred approach to database evolution. We consider only the basic schema update primitives. To achieve this consistency, there are two strategies for database evolution, viz Immediate transformation and Deferred transformation. The rst phase of our project deals with deferred and immediate transformation techniques in the O2 object database system. We consider the implementation of the following schema manipulation primitives using both techniques : Addition of an atomic attribute Modication of an atomic attribute Deletion of an atomic attribute Deletion of a class Renaming of a class Addition of an edge between two classes Deletion of an edge between two classes In the second phase, we hope to come up with a mechanism which intermixes the deferred and immediate techniques, thus incorporating the advantages of each. This involves nding a criteria on which the DBMS automatically switches from one mode of transformation to another. We have identied two such criteria, number of users and number of schema evolutions on a class. To evaluate the performance, we plan to consider response time as a benchmark. 1.1 Database Transformation When a schema is changed by an user, it implies changing the database. The changes to the schema have to be propagated to all objects composing the database. This is referred as Database Transformation Immediate Database Transformation The system executes conversion functions on all objects of the modied classes as soon as the modication on the schema is committed. The main problems with this approach are: All running programs have to be suspended until the updation is completed. This waiting time depends on several parameters (size of the database, type of update performed, object retrieving strategy etc). All objects of the modied class have to be updated at once. This could be expensive, especially if the system does not manage class extensions Deferred Database Transformation In this case the objects are updated to conform logically to the new schema after the change to the schema has been committed. However, objects are physically restructured only when they are accessed by an application. The schema may undergo several changes before an object is eectively used. Thus, only those objects that are used are transformed, and not all objects of the modied classes as in the case of immediate updates. The main problems with this approach are: There is a need to store and remember the history of all schema updates that have been performed in the system. Every time an object is accessed by an application, the history should be checked and updated accordingly. The rest of the report is structured as follows: Section 2 covers problem description. In Section 3, we review relevant the related work. The project goals and details are stated in Section 4. Implementation details are included in this section. The work distribution for the above implementation has been split over a six week period. This schedule has been listed in Section 6. Finally we conclude in Section 7. 1

3 2 Problem Description When there is a schema change in a database, the database needs to be updated such that it reects the corresponding change and maintains data consistency. There are two strategies involved in updating the database The Immediate Approach The Deferred Approach. The Immediate Approach is where objects in the database are updated in any case as soon as the schema modication is performed. This Approach leads to a signicant problem as the database needs to be locked for updation after every schema change. Thus denying access to all other users in the system. On the other hand, the deferred approach updates objects only when they are accessed/used. This circumvents the problem faced by the Immediate approach. The decision to use either one of the approaches depends on the number of schema changes among other factors. We therefore need to implement both the above strategies for schema evolution and to develop a cost model which models the performance of both under varying number of schema changes and to come up with a hybrid strategy to eectively intermix the two for optimum results. 3 Related Work Not all available ODBSs provide the feature of adapting the database after a schema modication has been performed [7] [8]. For those that do it, they dier from each other in the approach followed for updating the objects. Some commercial systems support the possibility to dene object versions to evolve the database from one version to another, examples are Objectivity [6] and Gemstone [3]. Objectivity does not provide any tool to automatically update the database besides providing object versions. Gemstone provides a exible way for updating object instances using default transformation of objects, along with the possibility to add conversion methods to a class. In both these systems versioning is used. One the other hand majority of the existing commercial systems do not use versioning for updating the database. Instances of a class, in this case are converted either immediately or lazily. Objectstore [5] makes use of immediate database transformation. Deferred transformation of objects is provided in systems like Itasca [4] and Versant [9]. Both these systems do not provide the user with exible conversion functions like the one presented in O2 [1]. O2 object database system oers an automatic database modication mechanism after a schema change. It supports both immediate and deferred database transformations. The performance of immediate vs. deferred database updates is discussed by Fabrizio Ferrandina et al [2]. The performance was evaluated for both large and small databases. For small databases it was shows that the costs for the immediate database transformation grows linearly with the number of schema modications. Except for one schema modication, the deferred technique always performs better than the immediate. In large databases, deferred transformation performs better than immediate, when the number of schema updates exceeds a particular threshold (5 in their case). 4 Project Goals We set the following goals for our project. Implementation of Deferred Approach This involves updation of objects in the database as and when they are accessed. It is implemented using the Classes we have identied in the latter part of the report. Implementation of Immediate Approach This involves a one-time updation of all objects in the database as a result of a schema change. This technique does not involve any of the deferred overheads. Comparison of Costs in Immediate and Deferred Approaches The cost is calculated on the basis of the response time of the database to the queries,in case of deferred and on the basis of average time to update an object in case of immediate. The time needed for transforming an object using immediate and deferred would depend on the number of schema evolutions performed. The cost model tries to nd a relation between this time and the number of schema evolution. This would involve 2

4 running experiments for immediate and deferred strategy on a set of objects and coming up with average time taken. Integrate the Immediate and Deferred approaches into an optimal strategy for database evolution Using the cost model our objective is to come up with a strategy for database update which intermixes both the immediate and deferred strategy in a single hybrid framework. We believe that there exists a certain threshold above which the immediate strategy outperforms deferred in terms of time taken to update an object.our aim is to nd this threshold and using this threshold obtain the hybrid strategy which would perform optimally for any number of schema evolutions. 5 Project Details 5.1 Implementation Details Our design ignores the following: Property Dependencies Cycles caused from adding edges between dierent classes Multiple Inheritance. Hence for every class there is only one parent class. We have a Class Lookup Table that stores the class names and their corresponding class IDs. We use this table to locate the class ID from its class name. Following is a list of basic primitives: Attributes add atomic attribute (attribute name : string, class name : string, attribute type:(integer, real, string), default initial value:(integer, real, string)) Input: Takes in the attribute name, the class name it needs to add the attribute to, the type of this attribute and the default value it needs to be set to. Description: This method adds the given attribute name to the given class name and also assigns it the default initial value. The given class name is mapped to its corresponding class ID in the Class Lookup Table. On locating this classid it adds the given attribute to it. modify atomic attribute (attribute name : string, class name : string, new attribute type:(integer, real, string) Input: Takes in the attribute name, the class name it belongs to and the new attribute type that it needs to be changed to. Description: This method modies the type of the given attribute in the given class. The given class name is mapped to its corresponding class ID in the Class Lookup Table. On locating this class ID it modies the type of the given attribute. delete attribute (attribute name : string, class name : string) Input: Takes in the attribute name to be deleted and the class name it belongs to. Description: This method deletes the given attribute from the give class. The given class name is mapped to its corresponding class ID in the Class Lookup Table. On locating this class ID it deletes the given attribute from it. Class delete class (class name : string) Input: Takes in the name of the class that needs to be deleted. Description: This method deletes the given class from the structure. The given class name is mapped to its corresponding class ID in the Class Lookup Table. On locating this class ID it deletes this class from the structure. If this class is not a leaf and has hierarchies below it, then its immediate children are linked to its parent. The parent class now holds these additional children class Id's' in its children list and removes the 3

5 class ID of the deleted class from its children list/attribute list. This class deletion could cause loss of inherited properties in the children classes of this deleted class. However, we do not consider property dependency and hence tend to ignore this aw. The class ID of the deleted class is also removed from the main class of classes. The Class Lookup Table no longer holds this class name or class ID. rename class (old class name : string, new class name : string) Input: Takes in the old class name and the new class name it needs to be changed to. Description: This method renames the given class name to the new class name. The given class name is mapped to its corresponding class ID in the Class Lookup Table. On locating this class ID it changes the current class name to the new given class name. add ISA edge (super class, sub class) Input: Takes in the parent class name (super class) and the child class name (sub class) to add the edge between the two. Description: This method adds an inheritance edge(link) between two classes. The given classes are mapped to their corresponding class Id's' in the Class Lookup Table. On locating their class Id's' we add the inheritance link between the two classes. The super class(parent) now holds the class ID of the sub class(child) in its children list, and the sub class(child) now holds the super class(parent) ID in its parent ID eld. Though we do not allow multiple inheritance, we do not check for them while adding this edge. We assume that the user is smart and knows where he/she is adding an edge. We also ignore cycles. delete ISA edge (super class : string, sub class : string) Input: Takes in the super class name(parent) and the sub class name (child) to delete an edge between the two. Description: This method deletes an inheritance edge(link) between two classes. The given classes are mapped to their corresponding class Id's' in the Class Look up Table. On locating their class Id's' we delete the inheritance link between the two classes. It removes the class ID of the sub class (child) from the children list of the super class (parent) and the class ID of the super class (parent) from the parent eld of the sub class (child). It then moves the sub class(child) and links it to the class of classes (root). It adds the class ID of the sub class to the list of class IDs' in the class of classes(root).it also adds this sub class name and its ID in the Class Lookup Table. Due to deletion of the link between the sub class and the super class the properties that are inherited by the sub class from the super class are lost. But since we do not consider property dependencies we can ignore this aw. set mode (mode : string) Input : Takes in the mode of schema update. Description : The database transformation technique can be switched between deferred and immediate depending upon the value of mode parameter. If the mode is changed from deferred to immediate, all the schema updates need to be incorporated. This is done using the history list. On the other hand, no changes are required when the mode is changed from immediate to deferred. History The history stores information about the earlier schema modications. The history list entries can be updated by using the following methods. add history entry (state : integer) Input: Takes in the current state to add an entry in the history list. Description : It creates an instance of the history class to reect the schema change. delete history entry ( state : integer) Input: Takes in the class name whose history classes need to be deleted. Description: It deletes instances of the history class depending of the schema state of the particular instance and the state of class accessed. 4

6 Class Schema name : string ; class_list : list < class_id : integer > ; delete_class ( class_name : string ) name : string ; class_id : integer ; parent_id : integer; children_list : list < class_id : integer > ; attribute_list : list < class_id : integer > ; visibility : { public, private } ; state : integer ; mode : {deferred, immediate } ; history_list : list < class_id : integer > ; rename_class ( old_class_name : string, new_class_name : string ) add_isa_edge ( superclass : string, subclass : string ) History sch_state : integer ; property_list : list < meta_property_entry > ; function : string ; add_property_entry ( pid : integer, sch_state : integer ) delete_property_entry ( pid : integer, sch_state : integer ) delete_isa_edge ( superclass : string, subclass : string ) delete_attribute ( attribute_name : string, class_name : string ) add_atomic_attribute ( attribute_name : string, class name : string, attribute_type : { integer, real, string }, default_initial_value : { integer, real, string } ) set_mode ( mode : string ) add_history_entry ( state : integer ) delete_history_entry ( state : integer ) Meta_property_entry pid : integer ; sch_state : integer ; offset : integer ; Attribute name : string ; attribute_id : integer ; class_id : integer ; type : { integer, real, string } ; modify_atomic_attribute ( attribute_name : string, class_name : string, new_type : {integer, real, string} ) cls : class_id tid : integer... value object header value Structure of an object Figure 1: Class Primitives Figure 1 shows the denitions for the various classes used in the design. The Schema class is the description of the base schema, which is an aggregation of various classes. Each of the classes have several attributes, and a history list. The history list stores information about the earlier schema modications. 5.2 Stepwise Implementation of the Database Transformation When a class is created it is given a default mode (deferred or immediate). The mode of a class can be changed by using the set mode primitive. A schema change is made using the add atomic attribute primitive. Here an attribute "ssn#" is added to a "Person" class. Depending upon the class mode, deferred or immediate updation is performed. Let's assume that the default mode is immediate. In such a case "ssn#" is added to each instance of the "Person" class and thus the database is updated. If the default mode needs to be changed to deferred we use the set mode primitive. Before performing the immediate updation, the database is locked for all other transactions. If the mode of the class is deferred, history is maintained. 6 Schedule We have devised the following schedule for future work towards the project: NOV { Week 1 Design of basic Primitives Design history structures { Week 2, 3 Create underlying schema Design history structures Implement Primitives for Immediate Approach 5

7 DEC { Week 4 Implement Deferred Strategy { Week 1 Design and implement Interface Devise Cost Model { Week 2 Integration of all modules Project Report The Work Distribution for the team is underlined below: Anuja Swathi { Schema class delete class { Class class rename class { Class class add atomic attribute delete attribute Jayesh and Parag { Class class modify atomic attribute add ISA edge del ISA edge All together Implement history structures. add history entry delete history entry set mode 7 Conclusion There exist various approaches to solving the schema evolution problem that exists in Object Database Systems. We have considered two of these methods, identied above in the report,namely deferred an immediate. As a part of our project we shall be implementing the 7 schema evolution primitives discussed above. Having implemented the primitives we plan to focus on developing a cost model for evaluating the performance of immediate and deferred strategies for updating updating the database. Using the cost model our objective is to come up with a strategy for database update which intermixes both the immediate and deferred strategy in a single hybrid framework. References [1] Fabrizo Farradina, Guy Ferran, Thorsten Meyers, Joelle Madec, Roberto Zicari Schema and Database Evolution in O2 object database system Proceedings of the 21st VLDB Conference, Zurich, Switzerland, 1995 [2] Fabrizo Farradina, Thorsten Meyer, Roberto Zicari Schema Evolution in Object Databases: Measuring the Performance of Immediate and Deferred updates. OOPSLA Workshop on Object Database behavior, Benchmarks and Performance,Austin, Texas, 1995 [3] R. Bretl, D. Maier, A. Otis, J. Penney, B. Schuchardt, J. Stein, E.H.Williams. The Gemstone Data Management System. W. Kim and F.H.Lockovsky, editors, Object Oriented Concepts, Databases and Applications, chapter 12. ACM Press,

8 [4] Itsaca Systems, Inc. Itasca Systems Technical Report Number TM OODBMS Feature Checklist.Rev 1.1, December 1993 [5] Object Design Inc. Object Store User Guide, Release 3.0, chapter 10, December 1993 [6] Objectivity Inc. Objectivity, User Manual, Version 2.0, March 1993 [7] J.E.Richardson and M.J. Carey Persistence in the E language.: Issues and Implementation Software- Practice and Experience, 19(12):1150, December 1989 [8] B. Schiefer Supporting Integration and Evolution with Object-Oriented Views. FZI-Report 15/93, July 1993 [9] Versant Object Technology Bohannon Drive Menlo Park, CA Versant User Manual,