order to suit database applications relevant to these fields (e.g. Orion [7], Encore. [20], Avance [4]...). However, current database design methods such as OMT ...
Integrating Versions in the OMT Models E. Andonoff, G. Hubert, A. Le Parc, G. Zurfluh Laboratoire IRIT, Université Toulouse III, 31062 Toulouse Cédex, France Email : {ando,hubert,leparc,zurfluh}@irit.fr
Abstract. This paper shows how to extend the object, dynamic and functional models of the OMT method so that it integrates version modeling capabilities. Thus, this method will suit new database applications relevant to fields such as computer aided design, technical documentation or software engineering where managed data are time-dependant.
1 Introduction The version concept has been introduced in database systems to describe evolution of real world data over time: different significant states of data are kept (neither only the last state as in classical databases nor all the states as in temporal databases); these states correspond to different versions. The concept of version is important in computer aided design, technical documentation or software engineering fields where managed data are time-dependent [2]. Most current object-oriented database systems implement the version concept in order to suit database applications relevant to these fields (e.g. Orion [7], Encore [20], Avance [4]...). However, current database design methods such as OMT [19], OOA [6]... do not take into account versions and consequently do not suit database applications relevant to the previous fields. Indeed, these methods do not give solutions to describe versions in the different models they propose. The version problem is only approached when implementing the database according to the model of the database system. Now, version modelling is an activity recovered from the design stage. From this stage, a designer must be able to tell if an entity or an entity class evolve over time. So, he must have tools to describe versions in the different models he defines. This paper shows how versions can be modelled from the design stage of a database: it proposes solutions to extend the conceptual models (object, dynamic and functional ones) of the OMT method [19] in order to describe versions. OMT is chosen because it begins to be widely used in aeronautical industry in Toulouse where managed data are documentary or multimedia ones. So, this work extends the OMT method so that it integrates version modelling capabilities and consequently suits new database applications relevant to fields such as computer aided design, technical documentation or software engineering.
This paper is organised as follows. Section 2 outlines the works relating to the modelling of versions. Section 3 introduces the version concept. The following sections describe the OMT conceptual model extensions. Sections 4 presents the extensions provided to the object model in order to describe versions. It also studies the problems relating to the modelling of composition, relationship and inheritance links between classes according to their instances (objects or versions), and, the operations that the classes and their instances can perform. Section 5 describes the extensions provided to the dynamic and functional models. Section 6 is the conclusion.
2 Related works Works relating to the modelling of versions are the matter for two modelling levels: the system level and the conceptual level. Works which are the matter for the system level are numerous. In these works, versions are investigated at two abstraction levels: the object level and the class level. Some systems have studied versions at only one abstraction level. For example, CloSQL [17] or Clamen's works [5] have studied this concept at the class level while Ode [1] or OVM [11] have investigated it at the object level. Other systems, such as Orion [7], Encore [20], Iris [3], Avance [4] or Presage [21] have studied versions at the two abstraction levels. But they do not clearly explain the outcomes of both management of class and object versions. Moreover, they partially tackle the problem relating to the modelling of links between instances because they do not take into account each kind of instance (object and version) and each kind of link (composition, relationship and inheritance). Works which are the matter for the conceptual level are less numerous. Current object-oriented database design methods such as OMT or OOA... do not provide version modelling capabilities. Only [9] and [10] have tried to extend the EntityRelationship model to include version modelling capabilities. But these works do not tackle neither the problem relating to the modelling of composition, relationship or inheritance links between Entity-Relationship classes nor the dynamic and functional aspects of the database. Our work is the matter for the conceptual level. As in [9,10], we consider that the version concept is a concept of the real world which can be modelled from the design stage of a database, as relationships or entity classes. Our work extends the object, dynamic and functional models of the OMT method in order to describe object and class versions. It particularly approaches the object model because it is the most important one when modelling database applications [19]. It tackles the modelling of composition, relationship or inheritance links between classes taking into account the different kinds of class instances. It also studies the operations that the classes and their instances can perform.
3 The Version Concept This section first describes basic concepts for versions and then presents the object and class version concepts. 3.1 Basic Concepts A real world entity has characteristics which may evolve during its life cycle: it has different successive states. In object-oriented database systems which provide version management, this entity is described by a set of objects called versions. A version corresponds to one of the significant entity states. Then, it is possible to manage several entity states (neither only the last one as in classical databases nor all the states as in temporal databases). The entity versions are linked by a derivation link; they form a version derivation hierarchy [12]. When created, an entity is described by only one version. The definition of every new entity version is done by derivation from a previous one. Such versions are called derived versions [12] (e.g. E1.v1 is a derived version from E1.v0). Several versions may be derived from the same previous one. They are called alternatives [12] (e.g. E1.v2 and E1.v3 are alternatives derived from E1.v1). Real world
Database E1.v0
E1.v1
E1.v2
Caption
E1 E1.v3
En.v1
version entity
En
En.v2 En.v0
En.v3
Fig. 1. Representing entities with versions
A version is either frozen or working. A frozen version describes a significant and final state of an entity. A frozen version may be deleted but not updated. To describe a new state of this entity, we have to derive a new version (from the frozen one). A working version is a version that temporarily describes one of the entity states. It may be deleted and updated to describe a next entity state. The previous state is lost to the benefit of the next one. The default version of an entity [8] is a version pointed out as the most representative version of the entity. It is unique for each entity and may be chosen among the set of frozen or working versions.
3.2 Object and class versions Evolution of entities may find expression in either value or schema evolution. One talks about object version when the entity evolution is a value evolution. One talks about class version when the entity evolution is a schema evolution. Value evolution consists in updating (in a partial or a total way) the attribute values of the considered object version. Schema evolution consists in adding new attributes, links (composition, relationship or inheritance links) or methods, in the considered class version. It also consists in updating or deleting existing attributes, links or methods. When value and schema evolution are available for an entity, the entity is described by a set of object versions belonging to different class versions. Note that only the version model of Presage [21] gives such a possibility. Object or class versions are defined by deriving an object or a class version (derived or alternative). These object or class versions are linked by a derivation link; they form a version derivation hierarchy. The frozen, working and default version concepts are available for object and class versions.
4 Modelling Versions in the Object Model This section first briefly summarises the basic OMT object model and then shows how versions are taken into account. 4.1 Basic Object Model [19] The class is the unique tool for modelling real world entities. A class contains a set of objects having the same schema. The class schema describes the structure and behaviour of its objects. The structure is represented by a set of (mono-valued or multi-valued) attributes whose domain is a predefined class (integer, real...) and the behaviour is defined through a set of methods described by their signature. Links which are inheritance, composition or relationship links can be defined between classes. 4.2 Extending the Basic Object Model with Versions: the Classes The basic model is extended to integrate the object and class version concepts. Not versionable classes and versionable classes are introduced. Not versionable classes correspond to the basic model classes: only the last schema of the class is kept. Versionable classes are classes describing entity classes of which several schemas (class versions) are kept. The instances of these classes are objects or versions. Objects correspond to the basic model objects: only the last value of the object is kept. Versions are objects describing entities of which several values (object versions) are kept.
So, four cases of classes are conceivable: -
not versionable classes whose instances are objects (no version), not versionable classes whose instances are versions (only object versions), versionable classes whose instances are objects (only class versions), versionable classes whose instances are versions (both object and class versions).
Operations inherent to the introduction of versions are class operations and instance operations. Class operations permit us to create a new class deriving an existing one (derive), to modify the schema of an existing class (update), to delete an existing class (delete), to freeze an existing class (freeze) or to create (from scratch) an instance in an existing class (create). Instance operations enable us to create a new instance deriving an existing one (derive), to modify the values of an existing instance (update), to delete an existing instance (delete) or to freeze an existing instance (freeze). The freeze operation enables us to keep the state of a class or an object version. This operation is either triggered at the class level (a class version is frozen) or at the instance level (an object version is frozen and the class it belongs to is automatically frozen). The derive operation for a class consists in defining a new class version from an existing one (which becomes frozen) and, in updating this derived class version using the update operation. This operation can only be performed to conventional classes or to unfrozen class version (versionable classes). Moreover, this operation can trigger a data conversion process (this process is not discussed in this paper; see [5,15,16,18] for further information). The derive operation for an object consists in defining a new object version from an existing one (which becomes frozen) and, in updating this derived object version using the update operation. This operation only consists in modifying the value of the considered object version. We can observe than that operation can only be performed on (conventional) objects or on unfrozen object versions. 4.3 Extending the Basic Object Model with Versions: the Links This section addresses the problems relating to the modelling of composition, relationship and inheritance links between the four kinds of classes. This section also studies in detail the main operations for classes and instances according to their links. 4.3.1 Composition Links Composition links are defined between versionable or not versionable classes containing either objects or versions. However, only four composition cases are put forward in the paper. Indeed, the constraints which are inherent to composition link cardinalities must only be taken into account at the instance level. So, it is useless to distinguish versionable classes from not versionable classes. The four composition cases are the following. Only the last three ones are novel and presented in the paper.
-
composition link between classes which contain objects (see [14]), composition link between a (composite) class containing objects and a (component) class containing versions, composition link between a (composite) class containing versions and a (component) class containing objects, composition link between classes which contain versions.
Case 2. Composition between a composite class containing objects and a component class containing versions. The cardinality is defined as follows (Fig. 2): -
from the composite class to the component class, one expresses a link from a composite object to one (mono-valued link) or several (multi-valued link) hierarchies of component versions, from the component class to the composite class, one expresses a link from a component version to one (exclusive link) or several (shared link) composite objects. Composite objects
Composite objects
Component version hierarchies
Component version hierarchies
Fig. 2. Composition between objects and versions
Case 3. Composition between a composite class containing versions and a component class containing objects. The cardinality is defined as follows: -
from the composite class to the component class, one expresses a link from a composite version to one (mono-valued link) or several (multi-valued link) component objects, from the component class to the composite class, one expresses a link from a component object to one (exclusive link) or several (shared link) hierarchies of composite versions.
Case 4. Composition between classes containing versions. The cardinality is defined as follows (Fig. 3): -
from the composite class to the component class, one expresses a link from a composite version to one or several hierarchies of component versions, from the component class to the composite class, one expresses a link from a component version to one or several hierarchies of composite versions.
Composite versions
Component version hierarchies
Composite versions
Component version hierarchies
Fig. 3. Composition between versions
To the best of our knowledge, cases 2 and 3 are never approached in the literature. Case 4 is only really studied in Orion which proposes a different solution for the one we propose: when several derived versions have the same component version, only one of them is linked to the component version. The other ones are linked to the default version of the generic object corresponding to the component version. This solution (as in the one we propose) limits version duplication but information is lost when derived composite versions are linked to the default component ones instead of being directly linked to the chosen component ones (which are often different from the default ones). In the solution we propose, composite versions are directly linked with their component versions; indeed, we authorise a component version to be a part of several successive derived versions belonging to the same composite hierarchy. Operations. Because of space limitation, this paragraph only details the create and derive operations for object versions. Only the most interesting cases are considered. Create. The composition link semantics imposes to create a component instance only when creating a composite instance [14]. Case 2. Composition between a composite class containing objects and a component class containing versions. A new (created) composite object must be linked to one or several versions belonging to hierarchies of versions of the component class according to the composite class cardinality. These versions are: -
root versions of new hierarchies of component versions, versions belonging to existing hierarchies of component versions if the link is shared for the component class.
Case 4. Composition between classes containing versions. In this case, a new composite version must be linked to one or several versions belonging to hierarchies of versions of the component class according to the composite class cardinality. These versions are: -
root versions of new hierarchies of component versions, versions derived from a free leaf version of existing hierarchies of component versions,
-
versions belonging to existing hierarchies of component versions if the link is shared for the component class.
A leaf version of a component hierarchy is free when it is not part of a leaf version of a composite hierarchy: Composite version hierarchies
free leaf version
free leaf version
Component version hierarchies Fig. 4. Free leaf versions
Derive. Derive is an operation which can only be performed on versions. Unlike create, derive can be performed either on composite or component versions. Case 4. Composition between classes gathering versions. On the one hand, a derived composite version must be linked to one or several versions belonging to hierarchies of versions of the component class according to the composite class cardinality. These versions are: -
the same component versions as the composite version it derives from, versions derived from the component versions, root versions of new hierarchies of component versions, versions derived from free leaf versions of component hierarchies existing in the component class (Fig. 4). versions belonging to existing hierarchies of component versions if the link is shared for the component class.
derivation of a component version
after derivation
Fig. 5. Derivation of a component version
On the other hand, a component version derivation triggers the derivation of the composite versions it composes (Fig 5). More precisely, it triggers the derivation of
all the composite versions from the derived component version up to the root versions of all the composition hierarchies that the derived component version belongs to. The versions linked to versions belonging to the considered composition hierarchies are kept and not derived. Note that such a propagation process restricts useless version duplication as in Presage [21], Encore [20], or Katz's works [12]. 4.3.2 Relationship Links Relationship links are defined between versionable or not versionable classes. These classes contain either objects or versions. However, only three relationship cases are put forward in the paper. Indeed, the constraints which are inherent to relationship link cardinalities must only be taken into account at the instance level. So, it is useless to distinguish versionable classes from not versionable classes. The three relationship cases are the following but only the last two ones are novel and presented in the paper: -
relationship link between classes which contain objects (see [6,19]), relationship link between a class containing objects and a class containing versions, relationship link between classes which contain versions.
Case 2. Relationship between a class which contains versions and a class which contains objects. The relationship cardinality is defined as follows: -
from the class which contains versions to the class which contains objects, one expresses a link from a version to one or several objects, from the class which contains objects to the class which contains versions, one expresses a link from an object to one (mono-valued link) or several (multivalued link) current version hierarchies.
We distinguish current and past links between objects and versions. A current link is the last link defined between an object and a version. A past link exists because the previous versions of the considered version are also linked to the object. A current hierarchy for an object is a hierarchy having at least one version linked to the object with a current link. current link versions
objects
past links
current hierarchy for the object
Fig. 6. Current links and current hierarchies
Case 3. Relationship between classes containing versions. The relationship cardinality is defined as follows: one expresses a link from a version to one (monovalued link) or several (multi-valued link) hierarchies of versions. We note that a version linked to a hierarchy of versions can be linked to several versions which belong to the hierarchy and which are derived one from another. Operations. Because of space limitation, this paragraph only details the create operation. Case 2 is the most interesting for this operation. Case 2. Relationship between a class which contains versions and a class which contains objects. A new (created) version must be linked to one or several objects according to the version class cardinality. These objects are: -
new objects or free objects or existing objects which are not yet linked, existing objects if the link is shared for the object class.
A free object is an object which is not linked to a leaf of a hierarchy of versions. not free free
versions
objects Fig. 7. Free object
When a new object is created, it must be linked to one or several versions belonging to hierarchies of versions according to the object class cardinality. These versions are: -
new root versions of new hierarchies, new versions derived from free leaf versions of existing hierarchies, existing versions of existing hierarchies which are not yet linked to objects, existing versions if the link is shared for the version class.
4.3.3 Inheritance Links Inheritance links are defined between versionable or not versionable classes. However, with the aim of describing the class operation derive, only three cases are put forward: -
the super-class is a versionable class whereas the subclass is not versionable, the subclass is a versionable class whereas the super-class is not versionable, the subclass and the super-class are both versionable classes.
Operations. Only class operations must be considered with inheritance links. Because of space limitation, we only study the derive operation (which is the most interesting one). Two possibilities are conceivable: derivation of a superclass and derivation of a subclass. Derivation of a superclass. The derivation of a superclass does not trigger the derivation of its subclasses. The derived class has the same characteristics as the class from which it derives: it is a versionable class and contains objects or versions (e.g. a versionable class containing objects derives a versionable class containing objects). Derivation of a subclass. For this operation, two situations are possible according to the derivation. In both situations, the derived class has the same characteristics as the class from which it derives: it is a versionable class which contains either objects or versions. Situation 1: if the derivation corresponds to a redefinition of inherited attributes or to an update of specific attributes belonging to the subclass, the derived class inherits from the same class as the class from which it derives.
B.v0
derivation
B.v0
B.v1
after derivation
A.v0
A.v0
A.v1
B.v0
B.v0
B.v1
derivation
Situation 1
after derivation
Situation 2 Fig. 8. Derivation of a subclass
Situation 2: if the derivation corresponds to an update of inherited attributes, deriving the subclass causes the derivation of its super-class. The derived subclass inherits from the derived super-class. We note that this situation is possible if the super-class is versionable.
5 Modelling Versions in the Dynamic and Functional Models This section summarises the basic features of the dynamic and functional models and shows how versions are combined with these basic models. 5.1 Basic Dynamic Model [19] This model describes the database behaviour through the behaviour of its instances. This behaviour is described in state diagrams through events and states. These diagrams show how the state of an object changes when an event occurs (possibly if
a condition is satisfied). States diagrams can be generalised in order to describe complex dynamic models. 5.2 Extending the Basic Dynamic Model with Versions The proposed solution consists in introducing generalised state diagrams. Three generalised states diagrams are introduced: two for describing object versions and one for describing class version. According to OMT, a state diagram is defined for each class (class version or simple class) of the database. This state diagram, called Class State Diagram (CSD), defines the behaviour of all the instances (objects or versions) of the class. Moreover, to express that an object version is either working or frozen, we define for each class which contains object versions, a state diagram which generalises the CSD state diagram of the class. This state diagram, called Version State Diagram (VSD), is the following. Version
derive
create
frozen version
delete
create derive
unfreeze [if not derive]
freeze
create
delete
working version VSD
update
Fig. 9. Version State Diagram (VSD)
Version is a class describing object versions. The VSD diagram is the state diagram of that class. It nests the CSD one as follows: Version
derive
create
frozen version
delete
create derive
unfreeze [if not derive]
freeze
create
delete
working version state 2 state 1
event 1
CSD event 2 state 3
VSD Fig. 10. Nesting a CSD into a VSD
The working version state is a generalisation of all the states described in the state diagram (CSD) of the considered class. The update event is also a generalisation of all the events described in the state diagram of the considered class. The derive event is an event which triggers the create event in the class Version. A state diagram indicates how a version belonging to a class version can evolve to belong to another class version. The version states are the different VSD diagrams for each class version and change is the one and only existing event (a version is going to belong to another class). This state diagram, called VErsionable State Diagram (VESD), is the following: VESD
VSD class version 1 change change
VSD class version 2 change
VSD class version n
Fig. 11. VErsionable State Diagram (VESD)
Finally, a generalised state diagram is also defined to describe the behaviour of the class versions. Class versions are considered as instances of a meta-class and the state diagram of this meta-class indicates if a class version is working or frozen; this state diagram is the same as the VSD one. 5.3 Basic Functional Model [19] This model consists of several data flow diagrams. A data flow diagram contains processes that transform data, data flows that move data, actors and data stores. Actors are active object which produce or consume values: they are attached to the inputs and outputs of the data flow diagram. Data stores are passive objects which store passively data. A data flow diagram shows the flow of values from external inputs, through processes and data stores, to external outputs. 5.4 Extending the Basic Functional Model with Versions The proposed solution consists in introducing versionable actors and versionable data stores to take into account object versions. Class versions are taken into account
through the data flow diagrams of the different class versions: there is as much data flow diagrams for a process as class versions. A versionable actor is an active object version which produce or consume values (i.e. an actor which is an object version) whereas a versionable data store is a passive object which store object versions (i.e. a data store for object versions). Versionable actors and versionable data stores are represented as follows: Process
Actor
Data Store
v
v
Process
Fig. 12. Versionable actors and versionable data stores
6 Conclusion This paper defends the idea that versions must be studied from the design stage of a database. Current database design methods do not propose solutions to describe versions in the different models they propose: versions are only taken into account when implementing the database according to the model of the database system. Now, version modelling is an activity recovered from the design stage. From this stage, a designer must be able to tell if an entity or an entity class evolve over time. The version concept must be considered as relationships or entity classes. This paper has shown how versions can be modelled from the design stage of a database. It proposes solutions to extend the conceptual models (object, dynamic and functional ones) of the OMT method [19] in order to describe versions. Both object and class versions are considered through the three models. Our work particularly approaches the object model because it is the most important one when modelling database applications [19]. Notably it tackles the modeling of composition, relationship or inheritance links between classes taking into account the different kinds of instances of the classes (object and version). It also studies the main operations that the classes and their instances can perform. To the best of our knowledge, such a study has never been done for conceptual models. However, it is partially approached for logical (database) models with regards to the object model. However, in these approaches, links and operations are not studied in details (inheritance, relationship and composition between objects and versions are not investigated in the literature). This study has extended the OMT method so that it integrates version modeling capabilities and consequently suit new database applications relevant to fields such as
computer aided design, technical documentation or software engineering. OMT has been chosen because it begins to be widely used in aeronautical industry in Toulouse where managed data are documentary or multimedia ones. However, this study can be re-used to extend the data models of current object-oriented database design methods. Now, we carry on this work addressing the problem of the implementation of the modelled conceptual schemas into existing object-oriented database systems.
References 1.
R. Agrawal, S. Buroff, N. Gehani, D. Sasha: Object Versioning in Ode. In: 7th International Conference on Data Engineering, Kobe (Japan), April 1991.
2.
D. Batori, W. Kim: Modeling Concepts for VLSI CAD Objects. In: ACM Transaction On Database Systems, 10(3), 1985.
3.
D. Beech, B. Mahbod: Generalized Version Control in an Object-Oriented Database. In: 4th International Conference on Data Engineering, Los Angeles (USA), April 1988.
4.
A. Björnerstedt, C. Hultén: Version Control in an Object-Oriented Architecture. In: Object-Oriented Concepts, Databases and Applications, Edited by W. Kim, F. Lochovsky, Addisson-Wesley Publishing Company, 1989.
5.
S. Clamen: Schema Evolution and Integration. In: Distributed and Parallel Databases Journal, 2(1), 1994.
6.
P. Coad, Y. Yourdon: Object-Oriented Analysis. In: Yourdon-Press Publishing Company, 1990.
7.
H.T. Chou, W. Kim: A Unifying Framework for Version Control in a CAD Environment. In: 12th International Conference on Very Large Databases, Kyoto (Japan), August 1986.
8.
H.T. Chou, W. Kim: Versions and Change Notification in Object-Oriented Database System. In: 25th International Conference on Design Automation, Anaheim (USA), June 1988.
9.
K. Dittrich, W. Gotthard, P. Lockemann: Complex Entities for Engineering Applications. In: Research Foundation in Object-Oriented and Semantic Database Systems, Edited by A. Cardenas, D. Mc Leod, Prentice-Hall Publishing Company, 1990.
10. J. Dijkstra: On Complex Objects and Versioning in Complex Environments. In: 12th International Conference on Entity-Relationship Approach, Arlington (USA), December 1993.
11. W. Käfer, H. Schöning: Mapping a Version Model to a Complex Object Data Model. In: 8th International Conference on Data Engineering, Tempe (USA), February 1992. 12. R. Katz: Toward a Unified Framework for Version Modeling in Engineering Databases. In: ACM Computing Surveys, 22(4), 1990. 13. W. Kim, H.T. Chou: Versions of Schema for Object-Oriented Databases. In: 14th International Conference on Very Large Databases, Los Angeles (USA), August 1988. 14. W. Kim: Composite Object Revisited. In: 14th ACM International Conference on Management of Data, Portland (USA), June 1989. 15. W. Kim, N. Ballou, HT. Chou, J. Garza, D. Woelk: Features of the Orion Object-Oriented Database System. In: Object-Oriented Concepts, Databases and Applications, Edited by W. Kim, F. Lochovsky, Addisson-Wesley Publishing Company, 1989. 16. B. Lerner, A. Habermann: Beyond Schema Evolution to Database Reorganisation. ACM SIGPLAN Notices, 25(10), 1990. 17. S. Monk, I. Sommerville: Schema Evolution in Object-Oriented Databases using Class Versioning. ACM SIGMOD Record, 22(3), September 1993. 18. D. Penney, J. Stein: Class Modification in the GemStone Object-Oriented Database System. In: International Conference on Object-Oriented Programming, Systems, Languages and Applications, OOPSLA 87, Orlando (USA), September 1987. 19. M. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: ObjectOriented Modeling and Design. Prentice-Hall Publishing Company, 1991. 20. A. Skarra, S. Zdonik. The Management of Changing Types in an ObjectOriented Database. In: International Conference on Object-Oriented Programming, Systems, Languages and Applications, OOPSLA 86, Portland (USA), September 1986. 21. G. Talens, C. Oussalah, M.F. Colinas: Versions of Simple and Composite Objects. In: 19th International Conference on Very Large Databases, Dublin (Ireland), August 1993. 22. S. Zdonik: Version Management in an Object-Oriented Database. In: International Workshop on Object-Oriented Databases, LNCS n° 244, Trondhein (Norway), June 1986.
