1. E.Bertino, L.Matino Object-Oriented Database Systems 1 Chapter 5. Evolution Seoul National University Department of Computer Engineering OOPSLA Lab.

2. OOPSLA Lab Chapter5. Evolution 2 Table of Contents 4 Schema Evolution 4 Taxonomy of Schema Modification 4 Schema Invariant 4 Semantics of Schema Modification 4 Implementation of Schema Evolution 4 Instance Evolution 4 Evolution in Gemstone, O 2 and Iris

3. OOPSLA Lab Chapter5. Evolution 3 Taxonomy of schema modification Schema A Schema A’ Schema Invariants Instance Evolution Instances O Instances O’

4. OOPSLA Lab Chapter5. Evolution 4 Schema Evolution in OODB 4 Repository of possible modifications is larger 4 increased complexity in model 4 modifications to a class can involve several classes 4 Concept of inheritance hierarchy 4 other schema modification operations 4 On-line execution of schema modification 4 efficiency

5. OOPSLA Lab Chapter5. Evolution 5 Taxonomy of Schema Modifications 4 Modifying the class definition 4 modifying attributes 4 modifying methods 4 Modifying the inheritance hierarchy 4 making a class S the superclass of a class C 4 removing a class S from the list of superclasses of C 4 modifying the order of the superclass of C 4 Modifying the set of classes 4 creating new classes 4 deleting classes 4 modifying class names

6. OOPSLA Lab Chapter5. Evolution 6 Taxonomy of Modifying Attributes 4 Adding attributes 4 Deleting attributes 4 Renaming attributes 4 Modifying the domain of attribute 4 Modifying the inheritance of attributes 4 Modifying the default value of attributes 4 Manipulating shared attributes 4 transforming non-shared attributes into shared attributes 4 modifying the value of shared attributes 4 transforming shared attributes into non-shared attributes 4 Modifying composite attributes into non-composite attributes

7. OOPSLA Lab Chapter5. Evolution 7 Taxonomy of Modifying Methods 4 Adding methods 4 Deleting methods 4 Modifying the names of methods 4 Modifying the implementation of methods 4 Modifying the inheritance of methods

8. OOPSLA Lab Chapter5. Evolution 8 Schema Consistency 4 After schema modification, schema consistency should be maintained 4 Schema invariants to make schema consistent 4 inheritance hierarchy invariant 4 unique names invariant 4 single origin invariant 4 complete inheritance invariant 4 domain compatibility invariant 4 preserving information invariant

9. OOPSLA Lab Chapter5. Evolution 9 Example of the Inheritance Hierarchy

10. OOPSLA Lab Chapter5. Evolution 10 Rules for Schema Consistency 4 Must be specified in such a way that schema invariants are respected 4 Classification of rules 4 for conflict resolution caused by multiple inheritance, redefinition of attributes and methods in a subclass 4 for propagation of modifications to subclasses 4 for aggregation, inheritance and existence of classes 4 for composite objects

11. OOPSLA Lab Chapter5. Evolution 11 Rules for Conflict Resolution 4 [S1] Rule for precedence of subclasses over superclasses 4 [S2] Rule for precedence between superclasses of a different origin 4 one from the first superclass 4 [S3] Rule for precedence between superclasses of the same origin 4 with same name and origin, inherited only once 4 for redefined attributes, the most specialized one 4 for incomparable domains, one from the first superclass

12. OOPSLA Lab Chapter5. Evolution 12 Rules for Modification Propagation 4 [P1] Rule for propagation of modifications 4 always propagated to the subclasses except for those classes in which have redefined them 4 [P2] rule for propagation of modifications in the event of conflicts 4 propagated to the subclasses only if no name conflicts 4 [P3] rule for modification of domains 4 modifiable to be more general 4 domain of inherited attribute can’t be more general than that of attribute of the superclass

13. OOPSLA Lab Chapter5. Evolution 13 Rules for Class Hierarchy 4 [E1] Rule for inserting superclasses 4 inserted class becomes the last superclass 4 [E2] Rule for removing superclass C’ from C 4 C’ is deleted from superclass list of C 4 if C’ is the only superclass, C gets superclass list of C’ 4 [E3] Rule for inserting a class into a schema 4 if no explicit superclass, it becomes the subclass of OBJECT class 4 [E4] Rule for removing a class from a schema 4 removed from the superclass list of all its subclasses

14. OOPSLA Lab Chapter5. Evolution 14 Rule for Composite Object 4 [C1] Rule for modification of the definition of composite attributes 4 exclusive composite attribute can be transformed into a non-composite or shared, but vice-versa 4 dependent attribute can be transformed into an independent and vice-versa

15. OOPSLA Lab Chapter5. Evolution 15 Semantics of Attribute Modification(1) 4 [1.1.1] Adding an attribute 4 if no conflicts, done  propagation to all subclasses 4 [1.1.2] Deleting an attribute 4 the attribute must have been defined locally in C. 4 [1.1.3] Modifying the name of attribute 4 can only be executed if they do not create conflicts 4 [1.1.4] Modifying the domain of attribute 4 can only be generalized 4 rule P1 (about propagation)

16. OOPSLA Lab Chapter5. Evolution 16 Semantics of Attribute Modification(2) 4 [1.1.5] Modifying the inheritance of attributes 4 with different origin is equivalent to delete old attribute(S.A) and add newly inherited attribute(S’.A) 4 with same origin, if both have same domain or domain of S’.A is superclass of that of S.A, then properties of S’.A are inherited otherwise, same with the case of different origin 4 [1.1.6] Modifying the default values of attributes 4 rule P1. propagated only to those subclasses which have not redefined the default value locally

17. OOPSLA Lab Chapter5. Evolution 17 Semantics of Attribute Modification(3) 4 [1.1.7] Manipulating shared attributes by rule P1 4 [1.1.7.1] Instance attributes  shared attributes 4 [1.1.7.2] modifying the values of shared attributes rule 4 [1.1.7.3] Shared attributes  non-shared attributes 4 [1.1.8] Modifying composite attributes into non- composite attributes follows rule P1

18. OOPSLA Lab Chapter5. Evolution 18 Semantics of Modifying Methods 4 [1.2] Similar to those rules previously for modifications to attributes

19. OOPSLA Lab Chapter5. Evolution 19 Semantics of Modifying Inheritance Hierarchies 4 [2.1] Making a class S a superclass of a class C 4 only if not cause cycles in inheritance hierarchies 4 rule E1, S3 4 [2.2] Removing a class S from superclasses of a C 4 C should not become disconnected from its inheritance hierarchy as [1.1.2], [1.2.2] 4 [2.3] Modifying the order of the superclasses 4 results in a complete revaluation of the inheritance 4 rule S1, S2 and S3 as [1.1.5], [1.2.5]

20. OOPSLA Lab Chapter5. Evolution 20 Semantics of Modifying a Set of Classes 4 [3.1] Creation of a new class C 4 rule E3, rule S1, S2 and S3 4 [3.2] Deleting a class C 4 if C is the domain of an attribute, change it’s domain to the superclass of C 4 all of C's instances are deleted, as a result pending references can be made 4 [3.3] Modifying class names 4 only if other classes do not have the same name

21. OOPSLA Lab Chapter5. Evolution 21 Deletion of age() from Person

22. OOPSLA Lab Chapter5. Evolution 22 Deletion of monthly_salary() from Researcher

23. OOPSLA Lab Chapter5. Evolution 23 Deletion of address from Researcher_Part_Time

24. OOPSLA Lab Chapter5. Evolution 24 Appliance of Class Modification to Instances 4 How modifications of classes can be applied to the class instances 4 only certain type of modifications 4 modifying methods have no impact on instances 4 Immediate approach 4 proposed for GemStone, but not yet implemented 4 disadvantage : high cost 4 Deferred approach

25. OOPSLA Lab Chapter5. Evolution 25 Deferred Approach for Appliance of Class Modification to Instances 4 Class version 4 new version of a given class C whenever C is modified 4 each instance of C has the version of the class 4 exception manager 4 Screening system 4 instances are modified when accessed by application 4 ORION system 4 Disadvantage 4 the access to the instances can take longer

26. OOPSLA Lab Chapter5. Evolution 26 Consistency of Methods 4 Structural consistency 4 Behavioral consistency 4 ex) if a method refers to deleted or modified attribute? 4 compile-based solution recompile the entire schema and its method  cost overhead 4 interpretation-based solution type error or semantically incorrect method can be executed 4 No general solutions 4 difficult to determine the effects of a schema modifications to the set of methods

27. OOPSLA Lab Chapter5. Evolution 27 Other Approaches to Schema Evolution 4 Versions of schema 4 objects created in a specific schema version are only visible in that schema version 4 Object oriented view 4 no information loss 4 object is visible in all view, if the conditions are met

28. OOPSLA Lab Chapter5. Evolution 28 Instance Evolution 4 State evolution 4 modifications to an object’s attributes 4 Structural and behavioral evolution 4 migrating of the object to different classes 4 the dynamic addition of classes 4 specialization of instances

29. OOPSLA Lab Chapter5. Evolution 29 Integrity Constraints for Evolution 4 Migrations within the application domain 4 specifying a class as essential 4 specifying a class as exclusive 4 Migration poses inconsistency problems 4 temporary inconsistency with notification mechanism

30. OOPSLA Lab Chapter5. Evolution 30 Example of Instance Evolution

31. OOPSLA Lab Chapter5. Evolution 31 Evolution in GemStone, O 2, and Iris 4 Not provide all the evolution of functions in schemas and instanecs 4 All support 4 state evolution of instances 4 dynamic creation of classes

32. OOPSLA Lab Chapter5. Evolution 32 Class Evolution in GemStone 4 All types of modification to a class definition can be executed, if the class is modifiable. 4 Modifiable class cannot be instantiated 4 schema modifications which can affect instances can’t be executed on classes with instances 4 No explicit class deletion operation 4 Implicit deletion 4 no instance, no subclasses, not used as the domain in the definition of another class

33. OOPSLA Lab Chapter5. Evolution 33 Instance Evolution in GemStone 4 State evolution and migration between classes 4 State evolution can be controlled by 4 immediateInvariant message 4 (instanceInvariant) flag 4 Instance migration only if it wasn’t modified and the new class is 4 subclass of the old class 4 no additional instance attributes 4 same storage format as old 4 same domains of attributes

34. OOPSLA Lab Chapter5. Evolution 34 Example of Instance Evolution in GemStone 4 changeClassTo message | tempVar | tempVar := C new. 'Creates an instance of class C'................… tempVar changeClassTo: C1 'Converts the instance of class C to the instance of class C1'

35. OOPSLA Lab Chapter5. Evolution 35 Evolution in O 2 4 Schema modifications can’t be done dynamically 4 Class deletion only for the class 4 no instances 4 not used in the definition of other class 4 State and structural instance evolution 4 exceptional instances

36. OOPSLA Lab Chapter5. Evolution 36 Evolution in Iris 4 Schema evolution is very limited 4 Function deletion 4 type properties can’t be added and deleted dynamically automatically deleted if the type is deleted 4 other functions can always be deleted DELETE FUNCTION function-name 4 system automatically deletes all those derived functions from the deleted functions

37. OOPSLA Lab Chapter5. Evolution 37 Type Evolution in Iris 4 No instruction to change the ordering of supertype 4 ordering of supertypes have no effect on type definition 4 Type deletion DELETE TYPE type-name 4 only if no subtype and not used in defining other types 4 not result in the deletion of its instances 4 Dynamic instance evolution 4 add type and remove type dynamically 4 default type : UserTypeObject