[Link], L.

Matino
Object-Oriented Database Systems

Chapter 5. Evolution

1
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

2
OOPSLA Lab
Chapter5. Evolution

Schema Invariants

Taxonomy of

Schema A’
schema modification
Schema A

Instance Evolution
Instances O
OOPSLA Lab
Instances O’ 3
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

4
OOPSLA 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

5
OOPSLA 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 into
non-composite attributes

6
OOPSLA 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

7
OOPSLA 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
8
OOPSLA Lab
Chapter5. Evolution

Example of the Inheritance Hierarchy

9
OOPSLA 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

10
OOPSLA 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

11
OOPSLA 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
12
OOPSLA 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
13
OOPSLA 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

14
OOPSLA 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)
15
OOPSLA 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
16
OOPSLA Lab
Chapter5. Evolution

Semantics of Attribute Modification(3)

 [1.1.7] Manipulating shared attributes by rule P1
 [[Link]] Instance attributes  shared attributes
 [[Link]] modifying the values of shared attributes rule
 [[Link]] Shared attributes  non-shared attributes

 [1.1.8] Modifying composite attributes into non-

composite attributes follows rule P1

17
OOPSLA Lab
Chapter5. Evolution

Semantics of Modifying Methods

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

18
OOPSLA 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]

19
OOPSLA 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

20
OOPSLA Lab
Chapter5. Evolution

Deletion of age() from Person

21
OOPSLA Lab
Chapter5. Evolution

Deletion of monthly_salary() from Researcher

22
OOPSLA Lab
Chapter5. Evolution

Deletion of address from Researcher_Part_Time

23
OOPSLA 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

24
OOPSLA 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

25
OOPSLA 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
26
OOPSLA 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

27
OOPSLA 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

28
OOPSLA 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

29
OOPSLA Lab
Chapter5. Evolution

Example of Instance Evolution

30
OOPSLA 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

31
OOPSLA 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
32
OOPSLA 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
33
OOPSLA 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'

34
OOPSLA 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

35
OOPSLA 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

36
OOPSLA 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 deletion
DELETE 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

37
OOPSLA Lab