1

E.Bertino, L.MatinoObject-Oriented Database Systems

Chapter 5. Evolution

Seoul National University

Department of Computer Engineering

OOPSLA Lab.

2OOPSLA Lab

Chapter5. Evolution

Table of Contents

Schema Evolution Taxonomy of Schema Modification Schema Invariant Semantics of Schema Modification Implementation of Schema Evolution

Instance Evolution Evolution in Gemstone, O2 and Iris

3OOPSLA Lab

Chapter5. Evolution

Taxonomy of schema modification

Schema A

Schem

a A’

Schema Invariants

Instance EvolutionInstances O

Instances O’

4OOPSLA Lab

Chapter5. Evolution

Schema Evolution in OODB

Repository of possible modifications is larger increased complexity in model modifications to a class can involve several classes

Concept of inheritance hierarchy other schema modification operations

On-line execution of schema modification efficiency

5OOPSLA Lab

Chapter5. Evolution

Taxonomy of Schema Modifications Modifying the class definition

modifying attributes modifying methods

Modifying the inheritance hierarchy making a class S the superclass of a class C removing a class S from the list of superclasses of C modifying the order of the superclass of C

Modifying the set of classes creating new classes deleting classes modifying class names

6OOPSLA Lab

Chapter5. Evolution

Taxonomy of Modifying Attributes Adding attributes Deleting attributes Renaming attributes Modifying the domain of attribute Modifying the inheritance of attributes Modifying the default value of attributes Manipulating shared attributes

transforming non-shared attributes into shared attributes modifying the value of shared attributes transforming shared attributes into non-shared attributes

Modifying composite attributes intonon-composite attributes

7OOPSLA Lab

Chapter5. Evolution

Taxonomy of Modifying Methods

Adding methods Deleting methods Modifying the names of methods Modifying the implementation of methods Modifying the inheritance of methods

8OOPSLA Lab

Chapter5. Evolution

Schema Consistency

After schema modification, schema consistency should be maintained

Schema invariants to make schema consistent inheritance hierarchy invariant unique names invariant single origin invariant complete inheritance invariant domain compatibility invariant preserving information invariant

9OOPSLA Lab

Chapter5. Evolution

Example of the Inheritance Hierarchy

10OOPSLA Lab

Chapter5. Evolution

Rules for Schema Consistency

Must be specified in such a way that schema invariants are respected

Classification of rules for conflict resolution caused by multiple inheritance,

redefinition of attributes and methods in a subclass for propagation of modifications to subclasses for aggregation, inheritance and existence of classes for composite objects

11OOPSLA Lab

Chapter5. Evolution

Rules for Conflict Resolution

[S1] Rule for precedence of subclasses over superclasses

[S2] Rule for precedence between superclasses of a different origin one from the first superclass

[S3] Rule for precedence between superclasses of the same origin with same name and origin, inherited only once for redefined attributes, the most specialized one for incomparable domains, one from the first superclass

12OOPSLA Lab

Chapter5. Evolution

Rules for Modification Propagation

[P1] Rule for propagation of modifications always propagated to the subclasses except for those classes

in which have redefined them

[P2] rule for propagation of modifications in the event of conflicts propagated to the subclasses only if no name conflicts

[P3] rule for modification of domains modifiable to be more general domain of inherited attribute can’t be more general than

that of attribute of the superclass

13OOPSLA Lab

Chapter5. Evolution

Rules for Class Hierarchy

[E1] Rule for inserting superclasses inserted class becomes the last superclass

[E2] Rule for removing superclass C’ from C C’ is deleted from superclass list of C if C’ is the only superclass, C gets superclass list of C’

[E3] Rule for inserting a class into a schema if no explicit superclass, it becomes the subclass of OBJECT

class

[E4] Rule for removing a class from a schema removed from the superclass list of all its subclasses

14OOPSLA Lab

Chapter5. Evolution

Rule for Composite Object

[C1] Rule for modification of the definition of composite attributes exclusive composite attribute can be transformed into a

non-composite or shared, but vice-versa dependent attribute can be transformed into an

independent and vice-versa

15OOPSLA Lab

Chapter5. Evolution

Semantics of Attribute Modification(1)

[1.1.1] Adding an attribute if no conflicts, done propagation to all subclasses

[1.1.2] Deleting an attribute the attribute must have been defined locally in C.

[1.1.3] Modifying the name of attribute can only be executed if they do not create conflicts

[1.1.4] Modifying the domain of attribute can only be generalized rule P1 (about propagation)

16OOPSLA Lab

Chapter5. Evolution

Semantics of Attribute Modification(2)

[1.1.5] Modifying the inheritance of attributes with different origin is equivalent to

• delete old attribute(S.A) and add newly inherited attribute(S’.A)

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

[1.1.6] Modifying the default values of attributes rule P1. propagated only to those subclasses which have

not redefined the default value locally

17OOPSLA Lab

Chapter5. Evolution

Semantics of Attribute Modification(3)

[1.1.7] Manipulating shared attributes by rule P1 [1.1.7.1] Instance attributes shared attributes [1.1.7.2] modifying the values of shared attributes rule [1.1.7.3] Shared attributes non-shared attributes

[1.1.8] Modifying composite attributes into non-composite attributes follows rule P1

18OOPSLA Lab

Chapter5. Evolution

Semantics of Modifying Methods

[1.2] Similar to those rules previously for modifications to attributes

19OOPSLA Lab

Chapter5. Evolution

Semantics of Modifying Inheritance Hierarchies

[2.1] Making a class S a superclass of a class C only if not cause cycles in inheritance hierarchies rule E1, S3

[2.2] Removing a class S from superclasses of a C C should not become disconnected from its inheritance

hierarchy as [1.1.2], [1.2.2]

[2.3] Modifying the order of the superclasses results in a complete revaluation of the inheritance rule S1, S2 and S3 as [1.1.5], [1.2.5]

20OOPSLA Lab

Chapter5. Evolution

Semantics of Modifying a Set of Classes

[3.1] Creation of a new class C rule E3, rule S1, S2 and S3

[3.2] Deleting a class C if C is the domain of an attribute, change it’s domain to

the superclass of C all of C's instances are deleted, as a result pending

references can be made

[3.3] Modifying class names only if other classes do not have the same name

21OOPSLA Lab

Chapter5. Evolution

Deletion of age() from Person

22OOPSLA Lab

Chapter5. Evolution

Deletion of monthly_salary() from Researcher

23OOPSLA Lab

Chapter5. Evolution

Deletion of address from Researcher_Part_Time

24OOPSLA Lab

Chapter5. Evolution

Appliance of Class Modification to Instances

How modifications of classes can be applied to the class instances only certain type of modifications modifying methods have no impact on instances

Immediate approach proposed for GemStone, but not yet implemented disadvantage : high cost

Deferred approach

25OOPSLA Lab

Chapter5. Evolution

Deferred Approach for Appliance of Class Modification to Instances

Class version new version of a given class C whenever C is modified each instance of C has the version of the class exception manager

Screening system instances are modified when accessed by application ORION system

Disadvantage the access to the instances can take longer

26OOPSLA Lab

Chapter5. Evolution

Consistency of Methods

Structural consistency Behavioral consistency

ex) if a method refers to deleted or modified attribute? compile-based solution

• recompile the entire schema and its method cost overhead

interpretation-based solution• type error or semantically incorrect method can be executed

No general solutions difficult to determine the effects of a schema

modifications to the set of methods

27OOPSLA Lab

Chapter5. Evolution

Other Approaches to Schema Evolution

Versions of schema objects created in a specific schema version are only

visible in that schema version

Object oriented view no information loss object is visible in all view, if the conditions are met

28OOPSLA Lab

Chapter5. Evolution

Instance Evolution

State evolution modifications to an object’s attributes

Structural and behavioral evolution migrating of the object to different classes the dynamic addition of classes specialization of instances

29OOPSLA Lab

Chapter5. Evolution

Integrity Constraints for Evolution

Migrations within the application domain specifying a class as essential specifying a class as exclusive

Migration poses inconsistency problems temporary inconsistency with notification mechanism

30OOPSLA Lab

Chapter5. Evolution

Example of Instance Evolution

31OOPSLA Lab

Chapter5. Evolution

Evolution in GemStone, O2, and Iris

Not provide all the evolution of functions in schemas and instanecs

All support state evolution of instances dynamic creation of classes

32OOPSLA Lab

Chapter5. Evolution

Class Evolution in GemStone

All types of modification to a class definition can be executed, if the class is modifiable.

Modifiable class cannot be instantiated schema modifications which can affect instances can’t

be executed on classes with instances

No explicit class deletion operation Implicit deletion

no instance, no subclasses, not used as the domain in the definition of another class

33OOPSLA Lab

Chapter5. Evolution

Instance Evolution in GemStone

State evolution and migration between classes State evolution can be controlled by

immediateInvariant message (instanceInvariant) flag

Instance migration only if it wasn’t modified and the new class is subclass of the old class no additional instance attributes same storage format as old same domains of attributes

34OOPSLA Lab

Chapter5. Evolution

Example of Instance Evolution in GemStone

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'

35OOPSLA Lab

Chapter5. Evolution

Evolution in O2

Schema modifications can’t be done dynamically Class deletion only for the class

no instances not used in the definition of other class

State and structural instance evolution exceptional instances

36OOPSLA Lab

Chapter5. Evolution

Evolution in Iris

Schema evolution is very limited Function deletion

type properties can’t be added and deleted dynamically• automatically deleted if the type is deleted

other functions can always be deleted

DELETE FUNCTION function-name system automatically deletes all those derived functions

from the deleted functions

37OOPSLA Lab

Chapter5. Evolution

Type Evolution in Iris

No instruction to change the ordering of supertype ordering of supertypes have no effect on type definition

Type deletionDELETE TYPE type-name

only if no subtype and not used in defining other types not result in the deletion of its instances

Dynamic instance evolution add type and remove type dynamically default type : UserTypeObject