Approaches to Handling Temporal Data in Object ... - Semantic Scholar

Approaches to Handling Temporal Data in Object-Oriented Databases

Elisa Bertino Elena Ferrari

(1)

(1)

Michela Bevilacqua

(2)

Giovanna Guerrini

(2)

(1) Dipartimento di Scienze dell'Informazione Universita di Milano Via Comelico, 39/41 - I20135 Milano, Italy e-mail: fbertino,[email protected] (2) Dipartimento di Informatica e Scienze dell'Informazione Universita di Genova Via Dodecaneso, 35 - I16146 Genova, Italy e-mail: [email protected]

1

Abstract Temporal databases are an active and fast growing research area. Although many temporal extensions of the relational data model have been proposed, there is no comparable amount of work in the context of object-oriented data models. Moreover, few of the proposed models have been implemented. This report discusses how the temporal data model developed for T Chimera [4] has been implemented on top of the Ode OODBMS [1]. In particular, two dierent approaches to handle temporal data are investigated. The rst approach relies on the Ode versioning mechanism [2]; the second one is based on the allocation of special structures for storing temporal data. The main contribution of this work is to show how time can be eectively introduced in a conventional object-oriented context.

2

1 Introduction Conventional database systems do not oer the possibility of dealing with time-varying data. The content of a database represents a snapshot of the reality in that only the current data values are recorded, without the possibility of maintaining the complete history of data over time. If such a need arises, data histories must be managed at application program level, thus, making the management of data very dicult, if at all possible. To overcome this lack in the past years there has been a growing interest in extending data models with temporal capabilities [30]. Most proposals, however, are temporal extensions of the relational data model [12, 16, 26]. By contrast, research on temporal extensions of object-oriented data models is at a more preliminary stage, altough some proposals can be found in this direction [25]. This research area seems however very promising since the capability of object-oriented data models to represent in a natural way complex objects and relationships can be extended to the modelling of temporal information. Two dierent approaches to model temporal information in object-oriented database systems have been proposed [25]: the attribute timestamping approach associates time to object attributes [10, 11, 24], whereas the object versioning approach associates time to the whole object [20, 27, 29]. However, few of the proposed models have been actually implemented [20, 23, 27]. In this report we propose and compare two possible approaches to implement temporal objectoriented data models, based on the attribute timestamping approach, on top of existing objectoriented database systems. In particular, we consider the temporal object-oriented data model T Chimera [4]. Our discussion is however highly independent from T Chimera and can be adapted to other temporal object-oriented data models relying on the attribute timestamping approach. As target OODBMS we consider Ode [1] which supports a powerful versioning mechanism [2]. The choice of Ode as implementation platform is motivated by its support for the common object-oriented modeling features, and by its support for a versioning mechanism, since we were interested in investigating the possibility of realizing an attribute timestamping model through a system based on the object versioning approach. Two dierent implementations are presented and compared in the report: the rst one is based on the Ode versioning mechanism, whereas the second makes use of auxiliary storage structures to record temporal attributes. The rst approach demonstrates the feasibility of realizing a temporal object data model based on attribute timestamping using a version mechanism, but, as we will discuss in the report, results in being inecient both from a spatial and from a temporal point of view.Thus, the second approach has been investigated, which implements the extension of a conventional OODBMS with temporal capabilities, without relying on any additional mechanisms. The remainder of this report is organized as follows. Section 2 presents the T Chimera temporal object-oriented data model. Section 3 introduces the basic notions of the Ode OODBMS, and illustrates its versioning mechanism. Section 4 summarizes the basic assumptions and provides a general description of our implementation approaches. Section 5 describes the implementation based on the versioning mechanism, whereas Section 6 deals with the implementation based on auxiliary structures. Section 7 presents an example to better illustrate both the implementation approaches. Section 8 discusses issues related to inheritance. Section 9 compares our implementation strategies with other implementations of temporal object-oriented data models. Finally, Section 10 concludes the report and discusses further developments.

3

2 The T Chimera Data Model In this section we brie y introduce the notions of the T Chimera temporal object-oriented data model [4] that are relevant to this work. In the following, we denote with OI a set of object identi ers, with CI a set of class identi ers (i.e., class names), and with AN a set of attribute names. Moreover V denotes the set of T Chimera legal values. T Chimera supports the notion of type. A nite set of basic prede ned types is provided by the language, containing in addition to the usual (nontemporal) types, a time type. The domain of time is the set T IME = f0,1,: : :,now, : : :g, isomorphic to the set of natural numbers IN. Symbol `0' denotes the relative beginning, while now denotes the current time. T Chimera supports moreover structured types such as sets, lists and records, and allows the use of class names in the de nition of structured types. Finally, temporal types are supported: for each type T , a corresponding temporal type, temporal(T ), is de ned. Intuitively, instances of type temporal(T ) are partial functions from instances of type time to instances of type T . Temporal types can be used in the de nition of structured types. In T Chimera a contiguos lifespan is associated with each class, representing the time interval during which the class has existed. In T Chimera, attributes of class instances can be either temporal, immutable or nontemporal. A temporal attribute is an attribute whose value may change over time, and whose values at dierent times are recorded in the database. An immutable attribute is an attribute whose value cannot be modi ed during the object lifetime, whereas a nontemporal (or static) attribute is an attribute whose value can change over time, but whose past values are not meaningful for the application at hand, and are thus not recorded in the database. Temporal attributes have temporal types as domains and their values are thus functions from the temporal domain T IME to the set of legal values for the attribute.1 We represent the value of a temporal attribute of type temporal(T ) as a set of pairs fh1; v1i; : : :; h ; v ig, where v1; : : :; v 2 V are legal values for type T , and 1 ; : : :;  2 T IME  T IME are time intervals such that the attribute assumes the value v for each time instant in  , i = 1; : : :; n. Given a class c 2 CI, A(c)  AN denotes the set of attributes of instances of that class, whereas dom(a; c) denotes the domain of attribute a in class c. Finally, since the objects belonging to a class vary over time, each class maintains the history of the objects instances or members of the class over time.2 To represent the extension of T Chimera classes, we introduce a function  : CI  T IME ! 2 , assigning an extent to each class, for each instant t. For each c 2 CI ,  (c; t) is the set of the identi ers of objects that, at time t, belong to c either as instances or as members. n

n

n

n

i

i

OI

Example 2.1 Suppose that i ; : : :;i 2 OI . The following are examples of T Chimera classes:  class employee, with lifespan = [10,now], such that: 1

{ {

5

A(employee) = fname, salary, status, division, managerg dom(name; employee) = temporal(string), dom(salary; employee) = temporal(integer), dom(status; employee) = string, dom(department; employee) = temporal(string), dom(manager; employee) = temporal(manager)

In this report we will concentrate on temporal and static attributes. Immutable attributes can be regarded as a particular case of temporal ones, since their value is a constant function from a temporal domain. 2 According to the usual terminology, an object is an instance of a class c, if c is the most speci c class, in the inheritance hierarchy, to which the object belongs. If an object is an instance of a class it is also a member of all the superclasses of this class. 1

4

{

(employee; t) = fi1; : : :;i5g 8t 2[10,now]

 class manager, with lifespan = [10,now], subclass of employee, such that: A(manager) = A(employee) [ fdependents; official carg dom(dependents; manager) = temporal(set-of(employee)), dom(official car; manager) = string { (manager; t) = fi2; i4g 8t 2[10,now].

{ {

4

A T Chimera object o is a 4-tuple (i; lifespan; v; class-history ), where:

i 2 OI is the oid of o; lifespan 2 (T IME  T IME ) is the lifespan of o; v 2 V is a record value (a1 : v1 ; : : :; a : v ), where a1 ; : : :; a 2 AN are the names of the attributes of o, and v1; : : :; v 2 V are their corresponding values; class-history is a set fh1; c1i; : : :; h ; c ig, where 1 ; : : :;  2 T IME  T IME , c1; : : :; c 2 CI, such that c is the class identi er of the most speci c class to which o belongs in  , 1  i  n. Example 2.2 Consider the classes of Example 2.1, and suppose that i1; : : :;i5 2 OI . The following are examples of T Chimera objects: i =i1 lifespan = [20; now] v = f(name: fh[20,now],`Alan Smith'ig), (salary: fh[20,60],15ki; h[61,now],30kig), (status: `full-time'), (department: fh[20,100],`Disks'i; h[101,now],`Printers'ig), (manager: fh[20,49],i4i; h[50,now],i2ig)g class-history = fh[20,now],employeeig i = i2 lifespan = [50,now] v = f(name: fh[50,now],`Mary Dole'ig), (salary: fh[50,now],50kig), n

n

n

n

n

n

n

i

n

i

(status: `full-time'), (department: fh[50,now],`Printers'ig), (manager: fh[50,now],i4ig), (dependents: fh[50,100],fi1, i3gi; h[101,now],fi1,i3,i5ig)g class-history = fh[50,now],managerig

4

We require that each object is a consistent instance of all the classes it belongs to. Our notion of consistency keeps into account that, in a temporal context, both the object state and the class an object belongs to change over time. Therefore, verifying the consistency of an object requires two steps. First the set of attributes characterizing the object for each instant t of its lifespan must be determined. Then, the correctness of their values, with respect to the most speci c class3 the object belongs at time t, must be veri ed. We refer the interested reader to [4] for further details. The consistency of an object is checked only with respect to its most speci c class. If an object is consistent with respect to its most speci c class, it is consistent with respect to all its superclasses. 3

5

3 ODE: Object Database and Environment Ode [1, 3] is a database system and environment based on the object paradigm. A database can be de ned, queried and manipulated in the database programming language O++. O++ borrows and extends C++ classes by providing facilities for creating and manipulating persistent objects and their versions, and for associating constraints and triggers with objects. Moreover, O++ provides other facilities, suitable for database applications, such as those for de ning and manipulating sets, organizing objects into clusters, and iterating over clusters of persistent objects. Note that O++ provides all concepts commonly ascribed to object-oriented data models. In particular, it provides encapsulation to hide implementation details, it supports multiple inheritance for organizing objects in taxonomies in which more specialized objects inherit data and functions from more general objects. Moreover, it separates type de nition from type instantiation, it allows explicit speci cation of relationships between objects, and it supports object identity that allows persistent objects to have an existence independent from their values. Both volatile and persistent objects are supported by Ode. Volatile objects are allocated in volatile memory and they exist from the time of their creation till the time the program creating them terminates; by contrast, persistent objects are allocated in persistent store and they continue to exist after the program that created them has completed its execution. The introduction of persistence in O++ is based on the following principles:

 persistence should be a property of instances (objects) rather than of types;  it should be possible to allocate objects of any type in either volatile or persistent store;  there should be no dierence between accessing and manipulating persistent and volatile objects;  it should be possible to move objects from persistent store to volatile store and vice-versa.

The other features of the Ode object-oriented data model are mainly inherited from C++, thus we do not discuss them here. A relevant peculiarity of the Ode system is, by contrast, its powerful versioning mechanism, that is illustrated in detail in what follows.

3.1 Object Versioning in Ode

The Ode object-oriented database system supports the creation and manipulation of objects with versions [2]. The main characteristics of object versioning in Ode are:

 Version orthogonality: Object versioning is orthogonal to types, that is, versioning is an object

property and not a type property. Versions of an object can be created without requiring any changes to the type de nition of the object. All persistent objects can have versions, and both versioned and non-versioned objects of the same type can be created. Moreover, a dierent number of versions can be associated with objects of the same type.  Generic and speci c references: Ode supports the possibility of accessing both the latest version and a speci c version of an object. The latest version of an object can be accessed by means of the object identi er, whereas accesses to a speci c version are possible since each version of an object is uniquely identi ed by means of a version identi er. Note that, both these possibilities are useful for real applications. For example, an address-book object that keeps track of current addresses should reference the latest versions of person objects to access their 6

p

v0

p

becomes

v1

v0

Figure 1: Creation of version v1 latest addresses. On the other hand, a software con guration object may be implemented to reference speci c versions of objects representing component modules.  Temporal and derived-from relationships: Versions of an object are temporally ordered according to their creation time. The temporal relationship among versions is therefore a total ordering relationship based on the version creation times. A new version of a given object is created by modi ng an existing version of the object. Therefore, versions are also related by a derived-from relationships, which is a partial ordering relationship re ecting the derivation history of the versions. The object versioning mechanism is based on a formal model which is incorporated in O++ through appropriate linguistic constructs. In particular, a persistent object is a set of versions related by temporal and derived-from relationships. A persistent object is created through the pnew operator. The creation of a persistent object, through the pnew operation, involves the creation of an initial version. New versions must be created explicitly by invoking the newvers operation which takes as argument an object identi er or a version identi er and returns the version identi er of the newly created version. In particular, the newvers operation receives as input an object identi er when the new version is derived from the latest version of the object, rather it receives as input a version identi er when the new version should be derived from a speci c version of the object. Operator pdelete can be used to delete both an entire object or a speci c version. Additionally, some functions to access versions of an object are provided. Function Tprev is used to access the previous version in the temporal ordering, whereas function Dprev is used to access the version from which a speci c version has been derived from. As an example, consider the following code: persistent part *p, *vp;

:::

p = pnew part(); /*

creation of a new object */

vp = newvers(p); /*

creation of a new version of the object */

:::

Suppose that p points to object v0. The eect of the newvers call can be described pictorially as in Figure 1. In that gure, dotted boxes denote objects and they encapsulate all versions (represented by circles) of objects. Current versions are represented by double circles. Arrows pointing to boxes refer to objects (and therefore to their latest versions). If an arrow points directly to a circle, then it refers to a speci c version. Dotted arrows between object versions represent the temporal relationship, whereas solid arrows represent the derived-from relationship. Referring to the previous example, another version of v0 can be created with the call: newvers(vp0);

7

v1

v0

p v2 Figure 2: Creation of version v2 derived from v0

v3

v1

v0

p v2 Figure 3: Creation of version v3 derived from v1 where vp0 is the identi er of version v0. The eect of the call is to derive a new version v2 derived from v0, as illustrated in Figure 2. In this way, versions v1 and v2 can be thought as variants or alternatives, both derived from v0. Finally, suppose that another version is derived from v1 by means of the call: newvers(vp1);

where vp1 is identi er of version v1. The object is now as shown in Figure 3. Note that v3 , v1 and v0 represent a version history.

4 Overall Description of the Approach The main objective of our work is to implement the temporal object-oriented data model T Chimera with a conventional OODBMS. In particular, we consider the OODBMS Ode and its version mechanism. We wish to provide a database manager with the possibility of de ning and manipulating, in an appropriate way, temporal attributes. For example, consider a class employee and suppose it contains a temporal attribute salary. This means that the whole temporal history of attribute salary must be recorded, rather than its current value only. Conventional databases do not support this possibility, since if we introduce a new value for an attribute, the old value is overwritten by the new one. In order to implement our temporal model on top of the conventional OODBMS Ode, we have realized a program, which takes as input a le f , containing the de nitions of the T Chimera classes (attributes, constructors, destructors and methods) constituting the schema of the database, and translates it into an equivalent set of Ode classes, stored in an output le f . This process is graphically depicted in Figure 4. This translation allows the management of temporal data. 0

8

file f

schema definition in T_Chimera

file f’ our program

schema in O++, able to manage temporal data

Figure 4: Overall structure of the approach Temporal attributes are speci ed in T Chimera by means of the keyword temporal. Obviously, the term temporal is not inserted in the output le, as a conventional compiler is not able to interpret it. De nitions of classes in f are copied in f . Moreover, the management of temporal data is realized by introducing some attributes and methods for each class in f . In particular, we have introduced explicitly the concept of time in constructors and destructors and in all methods which we have added. In the following sections, we examine in detail these modi cations. Note that, our implementation only consider classes whose instances are persistent objects. This choice is due to the implicit correlation between a temporal database which memorizes the values of the attributes with reference to time and the concept of objects which persist in time. Two dierent approaches to handle temporal data have been investigated. The rst approach (described in Section 5) relies on the Ode versioning mechanisms; the second one (described in Section 6) is based on the allocation of special structures for storing temporal data. In what follows, we describe the notion of time supported and the operations on temporal objects considered in both the approaches. 0

4.1 Notion of Time Supported

It is important to emphasize that in T Chimera, and consequently in our implementation, we consider only valid time (that is, the time in which an event is true in the reality), and we do not consider transaction time (that is, the time in which an event is stored in the database). However, our implementation can be easily extended to consider transaction time. In what follows, we use the day as our nest temporal granularity. In this way, we omit concepts like hours, minutes and seconds. This choice also means that a temporal attribute is updated at most once every day. However, our implementation can be easily extended to the consideration of any temporal granularity. Time is represented by means of the following record structure:

f

struct date int day, month, year;

g

Whenever the date 0/0/0 is used, the current date, returned by the system function localtime(time t), is considered as a default.

4.2 Supported Operations

In both the approaches, we consider the following operations on objects with temporal attributes:

 creation of a temporal object (which relies on the class constructor);  insertion of a new value for a temporal attribute of an object at a given date;  search for the value of a temporal attribute of an object at a given date; 9

 \deletion" of a temporal object. Note that the migration to a temporal context requires a re-examination of the delete operation. Indeed, two dierent types of deletion of temporal objects (that is, objects containing at least one temporal attribute) can be realized: 1. an object can be physically deleted from the database (through the system operation pdelete); 2. an object can be marked as deleted; in this case the object is not physically removed from the database but it can no more be updated and it cannot be accessed at times subsequent to its deletion. In our implementation we adopt the second approach. The reason is that with this approach queries requiring values of a temporal attribute of a deleted object on times preceding its deletion can be answered. For instance, the second approach can be used to model an employee which is red; his data are maintained in the database and can be used in temporal queries.

5 Management of Temporal Data through Version Mechanisms Our rst approach to implement the T Chimera model is based on the version mechanism of Ode. In particular, whenever we want to add a new value to the temporal history of an attribute X of a given object, we create a new version of the object, derived from the latest object version. The new version is a copy of the previous version except that it contains the new value of the temporal attribute X. In this way, we create a particular version hierarchy which is composed of a single branch and whose root is the initial version, implicitly generated at the moment of the object creation. Moreover, the unique leaf of the version hierarchy stores the latest values of the temporal attributes of the given object. Time is not explicitly supported by the notion of version. Therefore, in order to keep track of the time updates take place, it is necessary to introduce a new attribute in every user-de ned class. This attribute is called valid time and it is used to store the date of the update, that is, the time at which a new version is created. Attribute valid time is of type date (cfr. Section 4.1). Moreover, to manage the delete operation we insert an additional attribute is alive in the de nition of all user-de ned class containing at least a temporal attribute. This attribute is initialized to true at the moment of object creation and it remains unchanged till the moment of object deletion, when it assumes the value false. In such a way we can distinguish deleted objects from the other ones.

5.1 Constructors and Destructors

We assume that each user-de ned class has at least a constructor to create objects of this class. The user can realize the constructors and destructors of his classes and manipulate all attributes (also temporal ones) as he prefers. Moreover, we have inserted appropriate operations to initialize and delete the additional attributes we have introduced. In particular, the attribute is alive is initialized and deleted, respectively, in all user-de ned constructors and destructors. The attribute valid time is managed in two dierent ways. In particular, we assign the current time to this attribute in constructors and destructors without parameters. On the contrary, in constructors and destructors with parameters, we add a new parameter of type date; the user can use this parameter to specify the creation and deletion time, respectively. If this parameter is null, the current time is considered. 10

5.2 Update Operation

For each temporal attribute we de ne a method which allows to update the temporal history of the attribute. Given an object, the call of the update methods associated with its temporal attributes implies the following operations: 1. creation of a new version of the object derived from the latest version in the version hierarchy of the object (this is performed by means of the Ode operation newvers(vlatest(pthis))); 2. recording of the new value of the attribute in the created version; 3. recording of the valid time of the new value in the attribute valid time of the created version. The new value of the temporal attribute is speci ed as a parameter of the corresponding update method.

5.3 Delete Operation

We recall that, in our model, the delete operation does not physically delete an object, rather it marks the object as deleted, without removing its data, which may be accessed by subsequent temporal queries. A deleted object, however, can no longer be updated. The operation delete object is realized through the following operations:  creation of a new version of the object;  recording of the date speci ed as parameter in the valid time attribute of the created version; this date represents the instant on which the object has been deleted and thus from which it is not possible any more to modify nor to access its attributes;  updating of the attribute is alive of the created version, setting it to false. Note that, attribute is alive is checked by all update and access methods to verify whether the speci ed object has been deleted; if its value is false, then an error message is returned and the operation is not performed.

5.4 Search Operation

For every user-de ned class, we have introduced a search operation which can be used to retrieve the value of a temporal attribute at a given time. This operation consists of a search in the version hierarchy of the object. In particular, the search operation considers the latest version (which is returned by the operation vlatest(pthis)) and compares the value of attribute valid time with the date speci ed as parameter of the search operation. In this way, we can decide if the information we are looking for is in the considered version or if it is necessary to proceed backwards in the hierarchy. Note that two particular cases can arise:  the object has been deleted before the date speci ed as parameter of the search operation;  the object has been created after the date speci ed as parameter of the search operation. In both these cases appropriate error messages are issued. Each search operation has as input parameter the search date and a return parameter which gets bound to the value of the object attribute at the speci ed time. Moreover, the method also returns an integer value which can be used to check whether the search operation has been successfully executed. 11

6 Management of Temporal Data through Auxiliary Structures In the previous section we have examined an implementation of T Chimera in Ode relying on the Ode version mechanism. The main advantage of that approach is the possibility of using features provided by the system, as object versioning and the related member functions. In this way, the eective storage of information is a task left to the system; in particular, allocation of structures is an implicit operation. Therefore, the user has the possibility of using temporal data ignoring tasks such as storage allocation. However, in that approach it is necessary to create a new version (which in Ode implies to create a new object) every time the value of a temporal attribute is updated. This approach thus implies data duplication, waste of memory and inecient search for the value of an attribute at a given date. For these reasons, in this section, we introduce an alternative approach to the implementation of T Chimera on top of Ode. This approach is based on the use of auxiliary structures to store temporal information. The main dierence with the versioning approach is the introduction, in each user-de ned class, of auxiliary structures to store temporal data.

6.1 Auxiliary Structures

The approach is based on the idea of using an ad-hoc structure to store temporal data. In particular, we are interested in storing the values of temporal attributes with respect to their evolution in time. Obviously, we have decided to use a dynamic structure to store a variable number of values for each temporal attribute. We maintain an ordered list of the values of the temporal attribute. In this way, the update operation has a constant cost and the search operation has a linear cost with respect to the number of elements in the list. Moreover, the current value of the attribute is stored at the head of the list; in this way, the current value of a temporal attribute can be obtained with a constant cost. A temporal attribute X, with type type X, is thus replaced by a pointer to an ordered list, called X < class name >, which stores the temporal history of the attribute. For each value, also the time of its insertion is maintained. Temporal attributes are therefore lists of pairs of the form (value,initial valid time). The class attribute valid time that we have used in the versioning approach, is replaced with an analogous attribute speci ed in every auxiliary structure. Therefore, we can say that the temporal information is no more stored at the object level, rather it is stored at the level of each single attribute value. By contrast, the attribute is alive is used as in the versioning approach. Note that the introduction of the auxiliary structures requires to specify appropriate allocation and deallocation operations. These operations are the topic of the following subsection. As we have already said, in the auxiliary structures approach, we have eliminated the class attribute valid time which becomes a slot of the auxiliary structures. Therefore, whenever an object is deleted it is necessary to store of the nal valid time of the last value of all the temporal attributes. We associate this information with the whole object, using an appropriate attribute. Therefore, we have introduced an additional attribute del time of type date which represents the time at which an object has been deleted. In Sections 6.2 and 6.4 we will describe its use.

6.2 Constructors and Destructors

The introduction of auxiliary structures to store temporal information implies a relevant change of the proper type of a temporal attribute. In particular, the value of a temporal attribute becomes a pointer to an appropriate structure. This change implies a substantial transformation of user-de ned class constructors and destructors. The code of these methods should indeed be modi ed accordingly; 12

potentially, the user can use any C++ construct to manage attributes, also temporal ones. Therefore, as a consequence of the change of temporal attribute types and names, it is necessary to update user code, especially to adapt the new types of temporal attributes to the user-de ned types used in the considered methods. We do not address those problems in our prototype, rather we consider a simpli ed scenario. In particular, we assume that the user manages in constructors and destructors only non-temporal attributes and that temporal attributes are completely managed by our program. We examine separately as we have handled constructors and destructors; moreover, we consider two dierent cases of constructors, distinguishing whether they are parametric or not. In constructors without parameters we initialize all temporal attributes (which are pointers to appropriate structures) to NULL. Therefore, the call of a constructor without parameters implies the creation of an object of the class, whose temporal attributes are set to null. Constructors with parameters are handled in a particular way so that the user can create a new object and initialize all attributes (or only not-temporal attributes) through one of his methods. For each constructor with parameters in the user-de ned class two dierent constructor de nitions are included in the output le: the original user-de ned constructor (which has only non-temporal parameters) and a new constructor which adds to the original parameters (speci ed by the user) all temporal attributes de ned for the considered class. Note that in both cases we initialize in an appropriate way all temporal attributes: in the rst case, the temporal attributes are initialized to the NULL value, while in the second case, they are initialized to the speci ed value. It is thus necessary to allocate an appropriate structure to store the initial value for each temporal attribute. Moreover, it is necessary to introduce a parameter time of type date to store the initial valid time of the speci ed value for each attribute. As we have said previously, if the speci ed date is 0/0/0, we consider the current date. Finally, for what concerns attribute del time, it must be initialized at object creation. Therefore, in each constructor of the considered class, we introduce the initialization of attribute del time to 0/0/0. This attribute will be used in update and access operations, to verify that the object has still not be deleted. In particular, we check that the value of attribute del time is still 0/0/0. In destructors we must deallocate all structures that have been used to store temporal data. In particular, note that, besides the recursive deallocation of all the elements of the lists which are associated to the temporal attributes, we have provided the operations to deallocate the dynamic structures used as proper types of the temporal attributes as persistent objects or lists.

6.3 Update Operation

The update operation allows to update the temporal history of a particular temporal attribute. Each new value of a temporal attribute is stored in the head of the list associated with the attribute. Note that the value in the head of the list is the latest value, that is, the current value, if the object has not been deleted, the value the attribute had at the moment of object deletion, otherwise. We have introduced appropriate checks to guarantee an ordered insertion of the new values of the considered attribute in the associated list. In particular, we consider the date of the latest update and we verify that the date of the new operation is subsequent. If this is not the case, the operation fails and an appropriate error message is raised. The update method associated with a temporal attribute performs the following operations: 1. check the modi ability of the object; 2. allocate a new element in the list associated with the attribute; 13

3. store the new value of the attribute and its valid time in that new element. As in the versioning approach, the new value of the temporal attribute is speci ed as a parameter of the corresponding update method.

6.4 Delete Operation

The operation delete object has been realized in a simple way using the attribute del time. In particular, function delete object has a parameter of type date which allows to specify the nal valid time of the latest value of all temporal attributes of the considered object. This parameter is used to set the attribute del time. Note that the delete operation of the object must be subsequent to all update operations that are already stored in the database. For this reason, we have introduced an appropriate check; in particular, the dates of the latest updates of every temporal attribute are compared with the date of the delete operation. This check is realized by considering the elements in the head of the lists of values associated with temporal attributes. If the check is not satis ed, the delete operation fails and an appropriate error message is returned.

6.5 Search Operation

For each user-de ned class we have introduced a search operation which allows to retrieve the value of a temporal attribute on a given date. This operation consists in a search in the list associated with the considered temporal attribute. In particular, the search operation considers the element in the head of the list and compares its date with the date speci ed as parameter of the operation. In this way we can decide if the information we are looking for is in the considered element, or if it is necessary to consider other elements of the list. Note that before proceeding in the search, it is necessary to verify that the considered object has not been deleted. This check is realized using the attribute del time. As in the versioning approach, the date at which the attribute value is searched is speci ed as a parameter of the method and the method returns, besides the requested attribute value, an integer value which can be used to check whether the search operation has been successfully executed.

7 An Illustrative Example Consider a class employee with the temporal attributes: salary, department and manager. Suppose the following events should be modeled:

 On 1/1/90, Mr Paul Smith is employed in the department 3 of the rm XX; his monthly salary     

is $2.000 and his manager is Mr Mark Trent; on 6/6/90, Mr Paul Smith gets a salary rise of $500; on 8/8/91, Mr Paul Smith is transferred in the department 1; on 10/10/92, the manager of Mr Paul Smith becomes Mrs Diana Conrad; on 12/12/93, Mr Paul Smith gets a new salary rise of $500; on 10/15/95, Mr Paul Smith ends his work relationship with the rm XX. 14

time

code

name

salary

department

manager

valid_time

state 1

1578535

Paul

2.000

3

Mark

1/1/90

state 2

1578535

Paul

*2.500

3

Mark

6/6/90

state 3

1578535

Paul

2.500

*1

Mark

8/8/91

state 4

1578535

Paul

2.500

1

* Diana

10/10/92

state 5

1578535

Paul

*3.000

1

Diana

12/12/93

state 6

1578535

Paul

3.000

1

Diana

15/10/95

* it specifies the attribute which is modified

Table 1: Updates on the employee object corresponding to Mr Paul Smith These events are summarized in Table 1. Figure 5 illustrates the temporal evolution of the object which represents employee Paul Smith under the versioning mechanism. Note that each baloon represents a new version created upon an attribute update. Figure 7 illustrates the approach based on axiliary structures. In particular, each temporal attribute is a pointer to an appropriate structure.

8 Inheritance There are some dierences between the notion of inheritance supported by T Chimera and inheritance management in C++. In both cases, inherited concepts may be rede ned (overwritten) in a subclass but it is important to note that in T Chimera the rede nition of the signature of an attribute is possible by specializing, that is, re ning, the domain of the attribute with respect to the notions of covariance rule for result parameters and contravariance rule for the input ones. The main idea is that attribute domains can be replaced in subclasses by re ned types. This means that, as suggested in [10], a non-temporal attribute can be re ned in a temporal attribute (on the same domain or on a most speci c one), but not vice-versa. In C++, each subclass must contain all attributes and operations of all its superclasses but the possibility of re ning an attribute domain is not supported. In particular, an attribute which is de ned in the base class, can be speci ed in the derived class without any restrictions about its type. In this case, these attributes are considered as two dierent tokens and in their use the notion of environment is crucial. In the following subsections we examine as we have realized the inheritance concepts of T Chimera in our approaches. In particular, we deal with single and multiple inheritance with respect to temporal attributes. The discussion applies to both our implementation approaches.

8.1 Single Inheritance

A derived class inherits all temporal attributes which are de ned in its base class, moreover, we would like to support the re nement of attribute domains. In particular, we have handled the following cases, related to the introduction of temporal attributes:  a non-temporal attribute is re ned in a temporal attribute (with the same domain or with a more speci c domain); 15

1578535

1578535

Paul Smith

Paul Smith

2.000

* 2.500

3 Mark Trent

3 Mark Trent 1

1 1/1/90

6/6/90

this attribute (is_life) specifies the modificability of the object 1578535

1578535

Paul Smith

Paul Smith

2.500

2.500

3 * Diana Conrad 1

* 1 Mark Trent 1

10/10/92

8/8/91

1578535

1578535

Paul Smith

Paul Smith

* 3.000

3.000

3 Diana Conrad 1 12/12/93

3 Diana Conrad * 0 15/10/95

* it specifies the attribute which is modified

Figure 5: Temporal updates through the versioning mechanism

16

t_salary 3.000 12/12/93 2.500 6/6/90 2.000 1/1/90 NULL

t_department 1 8/8/91 3 1/1/90 NULL

t_manager Diana Conrad 10/10/92 Mark Trent 1/1/90 NULL

Figure 6: Temporal updates through auxiliary structures

17

A

C

B

D Figure 7: Inheritance hierarchy

 a temporal attribute is re ned in a temporal attribute with a more speci c domain. As we have previously seen, a non-temporal attribute can be re ned in a temporal attribute (on the same domain or on a more speci c one), but not vice-versa. This restriction has been realized by checking that any non-temporal attribute which is speci ed in a subclass has not previously been de ned in any superclass. Otherwise, an appropriate error message is returned and the derived class is not speci ed in the output le.

8.2 Multiple Inheritance

The introduction of multiple inheritance causes some diculties. In particular, there is an ambiguous situation when an attribute is de ned in several superclasses of a derived class. In C++, this ambiguity can be solved through the notion of environment, that is, by explicitly specifying in the attribute access the superclass where the considered attribute is de ned. This allows to manage all attributes referring to the superclasses where they are de ned. We prefer to solve the ambiguity at schema de nition time, so that the derived class inherits the attribute from only one of its superclasses. Thus, in presence of those ambiguity situations we have imposed that the temporal attribute is \re ned" -that is, redeclared- (with the same domain or with a more speci c one), in the derived class. In particular, a particular ambiguity to be managed arises when in a superclass an attribute is de ned as temporal whereas it is de ned as non-temporal in a dierent superclass. In this case, the only reasonable solution is to re ne the attribute in the derived class as a temporal attribute. Our program checks that no ambiguities of this kind are present in the input schema, and, if necessary, it raises an appropriate error message, specifying the derived class and the attribute names involved in some ambiguities. Moreover, those derived classes are ignored in the generation of the output le. Moreover, the notion of virtual class typical of C++ has been extended with respect to the introduction of temporal attributes. We start from the assumption that if a class is present in more inheritance hierarchies, it is de ned as a virtual class. 18

Referring to Figure 7, which presents an inheritance hierarchy rooted at a virtual class A, in the following we discuss all possible cases that can arise and our solutions with respect to the introduction of time. Consider an attribute a de ned in A:  if a is a temporal attribute and it is re ned in a temporal attribute (with the same domain or with a more speci c one) in B and/or C, the use of this attribute in D is ambiguous, then it is required to rede ne it;  if a is a non-temporal attribute and it is re ned in B and/or C as a temporal attribute, the use of this attribute in D is ambiguous again, then it is required to rede ne it;  if a is a temporal attribute and it is not re ned in B or C, then the use of this attribute in D is not ambiguous: our program manages this situation and allows the implicit inheritance of this temporal attribute as de ned in A;  if a is non-temporal and it is not re ned in B or C, then the use of this attribute in D is not ambiguous.

9 Comparisons and Discussion In the previous sections we have examined two dierent approaches to implement T Chimera in Ode. In this section we analyze and compare the proposed implementations. Moreover, we compare our approaches with two implementation approaches proposed in the literature: the one of Steiner and Norrie [27], and that of Kafer and Schoning [19, 20, 21]. Though for other temporal objectoriented models prototypal implementations have been developed [18, 24] not enough details of such implementations are available to allow an in-depth comparison with ours.

9.1 Comparison between our Approaches

The rst implementation approach is based on the versioning mechanism of Ode. This solution allows to realize the management of time according to the attribute timestamping approach, as suggested in T Chimera, using the object versioning mechanism provided by Ode. In other words, this approach allows to create and manipulate temporal attributes by \hiding" these information in the context of object versioning. In this way, the management of temporal attributes is simpli ed as the storing of temporal data is a task left to the system, which relies on the notion of version. In particular, each update of a temporal attribute implies the creation of a new version of the corresponding object. In this way, we create a hierarchy of versions whose root is the rst version implicitly created upon the creation of the object, and whose (unique) leaf is the latest version which stores the latest values the object temporal attributes. The main disadvantage of this approach is that an high number of versions must be created in order to store the temporal history of an attribute. In particular each element of the history requires the creation of a new version. In Ode each version is implicitly realized by the creation of a new object of a system class. Therefore, the use of a great number of versions implies the creation of a great number of persistent objects. Moreover, we need to consider the duplication of information and, in particular, of values of temporal attributes in dierent versions. In fact, the update of a particular temporal attribute implies the creation of a new version whose state is identical to that of the previous version, except for the updated attribute. The values of the other objec attributes, both temporal and non-temporal ones, are copied in the new version even though they are unchanged. This drawback could be avoided by modifying the internal support of versions in Ode, for example, 19

by introducing a mechanism to specify that only some attributes of a class are versionable. However, we built our system on top of Ode, without the ability of modifying its built-in features. The versioning approach has also some drawbacks in terms of time eciency. Consider the search of the value of a temporal attribute at a given date. This operation implies the scanning of the hierarchy of versions of the considered object. In particular, the latest version is examined and then we proceed backwards in the hierarchy until a version is found whose valid time is less than or equal to the date speci ed in the search operation. The computational cost of the scanning of the hierarchy is proportional to the number of object versions; therefore, it depends on the total number of updates to temporal attributes of the object rather than on the updates to the considered attribute only. The second implementation approach is based on the use of auxiliary structures to store temporal information. This alternative has made the management of information more dicult but it has improved both memory occupation and the computational cost of the search operation. The main idea of this second approach is to maintain an ordered list of values for each temporal attribute. In this way, duplication of information is avoided as the update of a temporal attribute implies only the introduction of a new element in the head of the corresponding list. Moreover, searching the value of a temporal attribute at a given date is realized by scanning the list associated with the considered attribute. Obviously, the number of elements in the list depends on the number of updates to the considered attribute. It is important to note that the dierences for the user between the two implementation approaches are minimal. In fact, in both cases, the management of the temporal data is realized by apposite methods.

9.2 Comparisons with the Implementation Approach of Steiner and Norrie

The work of Steiner and Norrie is based on the temporal object-oriented data model TOM [28], which is based on object-timestamping. They show how TOM can be implemented on top of the O2 system. It is very important to note that their implementation approach is deeply in uenced by the considered timestamping granularity. In particular, Steiner and Norrie have proposed to generalize their idea also to attribute timestamping. Our main objective is to compare their proposal with our realization of T Chimera in Ode. In particular, we are not interested in examining the TOM model, rather we focus on the implementation aspects. The TOM implementation described in [27] is based on the O2 OODBMS [13]. The system architecture of O2 is divided into several layers and the base of O2 is the O2 Engine which provides all the features of a database system and all the features of an object-oriented system. Several programming interfaces are built on top of the O2 Engine as O2 and OQL. Such interfaces have been used to support temporal functionalities. In particular, a new class TempObject, subclass of the root class Object, common to all system and user-de ned classes, has been de ned to manage temporal data. Therefore, if the user wants to de ne a class of temporal objects, he can specify this new class as a subclass of TempObject. This approach has the advantage to be very simple. Unfortunately, the features of the OODBMS Ode do not allow to realize this approach. In fact, in Ode there is not a common root class and the code of the system class to implement versioning mechanism is not available. Note that the approach of Steiner and Norrie, like ours, only considers the concept of valid time. In TOM the temporal approach based on attribute timestamping is supported through a generalization of the approach based on object timestamping. In particular, if a user wants to maintain the history of an attribute, this must be stored as an object. For instance, the salary history of an employee can be represented as a set of temporal objects, where each object is used to represent a particular value 20

in the salary temporal history. As an attribute can have the same value in dierent, not necessarily contiguos, temporal intervals, it is obvious that each object has associated a set of temporal intervals. We illustrate the approach by means of an example. In particular, we show how the salary history of an employee can be modeled. First the classes employee and salary history are de ned. The values of attribute salary are modeled by objects of the class salary history, This implies that several objects of this class (one for each distinct value) must be created to model the temporal history of attribute salary. First, note that the transformation of the type of the attribute implies the substitution of an integer with a persistent object. This implies the creation of a great number of persistent objects. Moreover, consider that a value of an attribute is repeated for the same object in very unusual cases. For example, if we consider the attribute salary of the class employee, it is unusual that the salary of an employee is reduced exactly to a previous salary. Thus, an high number of objects need to be created to model the dierent values of an object attribute. Moreover, there is also the need of creating several objects to model the same value. In fact, with each value (represented by an object of the class salary history) a set of intervals is associated representing the set of instants in which this value is valid for a particular employee. In this way, several objects of the class salary history must be created, representing the same value for dierent employees. Note that this choice implies the duplication of the same value for all objects employee in which the temporal attribute assumes this value. For example, suppose that 10 employees receive or have received in the past a salary of $2000, then we have 10 objects of the class salary history to represent this value. Let us now consider the access to temporal information. As we have already said, each value is transformed in a persistent object in the database. Therefore, if we query the database searching for the value of an attribute of a particular object, we must look for the considered object and successively look for the related object which models the value. This approach implies two successive memory accesses which would involve two dierent physic cylinders unless we use appropriate clusters to group these information and speed up queries. To express temporal operations, Steiner and Norrie introduce appropriate function. For example methods to calculate intersection or union of sets of temporal objects are provided. Unfortunately, in O2 only classes and named objects may be exported from schemas. This means that all the temporal functions have to be methods of an exported class. Adding them as methods to class TempObject means adding methods operating on sets of instances of class TempObject to each single instance. This is the same problem that we have found with respect to the de nition of the operations which are related with user-de ned classes and with the proper types of the temporal attributes. Finally the approach of Steiner and Norrie does not provide methods to search or delete temporal attributes. In particular, it is not easy to nd the value of a temporal attribute at a given date. For example, consider again the salary history of employees. To calculate the current value of the monthly salary of a particular employee, it is necessary to examine the set of values of this attribute. Moreover, Steiner and Norrie suppose that in a temporal database temporal data are never deleted. Though we agree that data should never be physically deleted, we believe that a logical deletion of objects, like the one we support, which marks the object as deleted and allows no more modi cations on it, need to be supported.

9.3 Comparisons with the Implementation Approach of Kafer and Schoning

In this subsection we examine the temporal data model TMAD and its implementation, and we compare it with our implementations. The main objective of Kafer and Schoning [19, 20, 21] is to show that a complex object data model is an appropriate means for handling temporal data. In particular, they explain the mapping of time sequences onto recursively structured complex objects 21

and they show how operations on temporal data can be transformed into complex object operations. Their work relies on the temporal data model T MAD and the prototype implementation of the model, called PRIMA. Note that T MAD is based on object timestamping as time is associated with the whole object. Note that in all models based on the concept of version, the temporal notion is maintained implicitly by a temporal order of the object versioning. T MAD, by contrast, introduces the concept of valid time and transaction time. The main idea behind the approach of Kafer and Schoning, is the concept of Time Sequence (TS), that is, a time-ordered sequence of all snapshots of a real word entity. In particular, a TS represents the history of an entity of the real world and can be seen as an extension of a tuple in the temporal dimension. Moreover, TS are able to represent event-oriented and continuous history. In event-oriented histories (e.g., debit/credit actions on an account) the tuples in the TS are only valid at single points in time. In the case of continuous histories, such as a fever curve of a patient, the degree of the fever changes continuously over time. Therefore tuples in the TS can only capture some characteristic values at single moments. Based on these characteristic values, the history has to be reconstructed by a function, for example, linear interpolation. It is particularly interesting to note that the implementation choices to model the concept of time sequence are similar to our implementation approach to realize T Chimera in Ode by the version mechanism. The de nition of the type time to represent the temporal concept and the introduction of some system attributes to manage the temporal information are analogous to our proposal. In particular, Kafer and Schoning introduce the attributes valid and timestamp to memorize the valid and the transaction time with respect to a particular event, respectively; in a similar way, we introduce the attribute valid time which represents the valid time of a value of a temporal attribute. Moreover the attribute alive used in T MAD corresponds to our attribute is alive. Note that these analogies allow to handle in the same way the delete operation; in particular, the attribute alive represents the concept of updatability of an object which is used to delete an object with at least a temporal attribute. The analogy between the two implementation approaches implies the same drawbacks such as data duplication. T MAD presents some suggestions to reduce the amount of storage space. Kafer and Schoning suggest to store only the dierences between two adjacent tuples instead of the complete information. In particular, instead of storing the full data only the result of an EXOR operation between the current tuple and the predecessor tuple is stored. Note that the youngest tuple is completely stored whereas all older tuples are represented only by dierences. The EXOR operation is only applicable at the byte level of the database management system. This has three major drawbacks:  the mechanism has to be integrated into the database management itself;  in order to evaluate a boolean expression on one attribute, the whole tuple has to be reconstructed by traversing a chain of dierences starting with the current tuple;  the dierences are \unstructured" tuples for the higher levels of the database management system. Thus, conventional access path structures cannot be used on history data. Hence, they suggest using logical rather than physical dierences, that is assigning null-values to those attributes which are not altered in comparison to their temporal predecessor. This has three advantages:  it is possible to operate on tuples with the data manipulation operations of the database system;  using conventional access path structures on the history data it is easier to obtain the tuples in which the requested value is stored; 22

 in PRIMA, the PRototype Implementation of the MAd model, null-values do not need any

storage space. Note that the above approach could also be used to reduce the amount of storage space in Ode. In fact, this property will allow to store only the dierences between a version and the previous version. Finally, it is interesting to note that in all temporal data models that we have considered in this section, only a linear notion of time is considered. In [20], Kafer and Schoning show that the nonlinearity found in versioning models can be implemented using the same approach. This characteristic can be an interesting development also for our approach.

10 Conclusions and Future Work In this report we have described and compared two dierent approaches to implement a temporal object model on top of an existing OODBMS provided with a version mechanism. This work is part of a wider research eort we are carrying on temporal object-oriented database systems. Thus, we plan to extend this work in several directions. For what concerns the data model, we are currently investigating how ad-hoc storage structures and indexing techniques developed for temporal relational model [14, 22] can be integrated with those developed for object-oriented databases [7] so that temporal object-oriented databases can be eciently indexed and accessed. Then, we would like to extend the developed system to support event-based temporal object models [6]. An event-based temporal object model allows to keep track of selected values within the temporal history of a data object attribute. The portions, within the temporal history of a data object, which are actually stored into the database are identi ed by relating them to events. We plan to rely on the Ode trigger facility [17] for such an extension. The model could also be extended to support multiple time granularities. We are also developing a query language for temporal object databases, as a temporal extension of the OQL object query language [9]. The implementation of this query language on top of our system is another direction of future work.

References [1] R. Agrawal and N. Gehani. ODE (Object Database and Environment): The Language and the Data Model. In Proc. ACM-SIGMOD Int'l Conf. on Management of Data, Portland, Oregon, 1989, pages 36-45. [2] R. Agrawal, S.J. Buro, N.H. Gehani, D.Shasha. Object Versioning in Ode. In Proc. Seventh IEEE Int'l Conf. on Data Engineering, 1991. [3] R. Arlein, J. Gava, N. Gehani and D. Lieuwen. Ode 4.1 User Manual. AT&T Bell Laboratories, Murray Hill, New Jersey, 1995. [4] E. Bertino, E. Ferrari, and G. Guerrini. A Formal Temporal Object-Oriented Data Model. In P. Apers et al., editors, Proc. Fifth Int'l Conf. on Extending Database Technology (EDBT'96), pages 342{356, 1996. [5] E. Bertino, E. Ferrari, and G. Guerrini. T Chimera: A Temporal Object-Oriented Data Model. Theory and Practice of Object Systems, 3(2): 103{125, 1997. 23

[6] E. Bertino, E. Ferrari, and G. Guerrini. An Approach to Model and Query Event-Based Temporal Data. Technical Report, Department of Computer Science, University of Milano, January 1997. [7] E. Bertino and W. Kim. Indexing Techniques for Queries on Nested Objects. IEEE Transactions on Knowledge and Data Engineering, 1(2):196{214, 1989. [8] R. Breitl, D. Maier, A. Otis, J. Penney, B. Schuchardt, J. Stein, E. H. Williams, and M. Williams. The GemStone Data Management System. In W. Kim and F. H. Lochovsky, editors, ObjectOriented Concepts, Databasases, and Applications, pages 283{308. Addison-Wesley, 1989. [9] R. Cattel. The Object Database Standard: ODMG-93. Morgan-Kaufmann, 1996. [10] T. Cheng and S. Gadia. An Object-Oriented Model for Temporal Databases. In Proc. of the Int'l Workshop on an Infrastrutcture for Temporal Databases, 1993. [11] J. Cliord and A. Crocker. Objects in Time. In Proc. Fourth IEEE Int'l Conf. on Data Engineering, pages 11-18, 1988. [12] J. Cliord and A. Crocker. The Historical Relational Data Model (HRDM) Revisited. In A. Tansel, J. Cliord, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass, editors, Temporal Databases: Theory, Design, and Implementation, pages 6{26. Benjamin/Cummings, 1993. [13] O. Deux et al. The Story of 02. IEEE Transactions on Knowledge and Data Engineering, 2(1):91{108, 1990. [14] R. Elmasri, G. Wuu and V. Kouramajian. The Time Index and the Monotonic B+ tree. In A. Tansel, J. Cliord, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass, editors, Temporal databases: Theory, Design, and Implementation, pages 433-456. Benjamin/Cummings, 1993. [15] D. H. Fishman et al. Overview of the Iris DBMS. In W. Kim and F. H. Lochovsky, editors, Object-Oriented Concepts, Databases, and Applications, pages 219{250. Addison-Wesley, 1989. [16] S. Gadia and S. Nair. Temporal Databases: a prelude to Parametric Data. In A. Tansel, J. Clifford, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass, editors, Temporal databases: Theory, Design, and Implementation, pages 28{66. Benjamin/Cummings, 1993. [17] N. Gehani and H. V. Jagadish. Active Database Facilities in Ode. In S. Ceri and J. Widom, editors, Active Database Systems. Morgan-Kaufmann, 1996. [18] I. Goralwalla and M. O zsu. Temporal Extensions to a Uniform Behavioral Object Model. In R. Elmasri, V. Kouramajian, and B. Thalheim, editors, Proc. Twelfth Int'l Conf. on the Entity-Relationship Approach, volume 823 of Lecture Notes in Computer Science, pages 110{ 121. Springer-Verlag, Berlin, 1993. [19] W. Kafer, N. Ritter and H. Schoning. Support for Temporal Data by Complex Objects. In D. McLeod editor, Proc. Sixteenth Int'l Conf. on Very Large Data Bases, pages 24-35, 1990. [20] W. Kafer and H. Schoning. Mapping a Version to a Complex-Object Data Model. In Proc. Eighth IEEE Int'l Conf. on Data Engineering, pages 348-357, 1992. [21] W. Kafer and H. Schoning. Realizing a Temporal Complex-Object Data Model. In M. Stonebracker editor, Proc. of the ACM SIGMOD Int'l Conf. on Management of Data, pages 266-275, ACM Press, 1992. 24

[22] C. Kolovson. Indexing Techniques for Historical Databases. In A. Tansel, J. Cliord, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass, editors, Temporal databases: Theory, Design, and Implementation, pages 418-432. Benjamin/Cummings, 1993.  [23] M. T. Ozsu, R. Peters, D. Szafron, B. Irani, A. Lipka, and A. Munoz, TIGUKAT: A Uniform Behavioral Objectbase Management System. in VLDB Journal 4(3):445-492, 1995. [24] E. Rose and A. Segev. TOODM - A Temporal Object-Oriented Data Model with Temporal Constraints. In Proc. 10th Int'l Conf. on the Entity-Relationship Approach, pp. 205{229, 1991. [25] R. Snodgrass. Temporal Object-Oriented Databases: A Critical Comparison. In W. Kim, editor, Modern Database Systems: The Object Model, Interoperability and Beyond. AddisonWesley/ACM Press, 1995. [26] R. Snodgrass. The TSQL2 Temporal Query Language. Kluwer Academic Publisher, 1995. [27] A. Steiner and M.C. Norrie. Implementing Temporal Databases in Object-Oriented Systems. In R. W. Topor and K. Tanaka, editors, Database Systems for Advanced Applications '97, Proc. of the Fifth Int'l Conf. on Database Systems for Advanced Applications, pages 381-390, 1997. [28] A. Steiner and M.C. Norrie. Temporal Object Role Modelling. In A. Olive and J. A. Pastor, editors, Advanced Information Systems Engineering, Proc. Ninth Int'l Conf. CAiSE'97, Lecture Notes in Computer Science, Vol. 1250, pages 245-258, 1997. [29] S. Su and H. Chen. A Temporal Knowledge Representation Model OSAM*/T and its Query Language OQL/T. In Proc. 17th VLDB Conf., pp. 431{441, 1991. [30] V. J. Tsotras and A. Kumar. Temporal Database Bibliography Update. SIGMOD-RECORD, 25, 1996. [31] X.S. Wang. Algebraic Query Languages on Temporal Databases with Multiple Time Granularities. In Proc. International Conference on Information and Knowledge Management, pages 304-311, 1995. [32] G. Wiederhold, S. Jajodia and W. Litwin. Dealing with Granularity of Time in Temporal Databases. In R. Andersen and J.A. Bubenko, editor, Advanced Information Systems Engineering. Solvberg, pages 124-140, 1991.

25