Approaches to Handling Temporal Data in Object-OrientedDatabasesElisa Bertino(1) Michela Bevilacqua(2)Elena Ferrari (1) Giovanna Guerrini(2)(1) Dipartimento di Scienze dell'InformazioneUniversit�a di MilanoVia Comelico, 39/41 - I20135 Milano, Italye-mail: fbertino,ferrarieg@dsi.unimi.it(2) Dipartimento di Informatica e Scienze dell'InformazioneUniversit�a di GenovaVia Dodecaneso, 35 - I16146 Genova, Italye-mail: guerrini@disi.unige.it

1

AbstractTemporal databases are an active and fast growing research area. Although many temporalextensions of the relational data model have been proposed, there is no comparable amount of workin the context of object-oriented data models. Moreover, few of the proposed models have beenimplemented. 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 di�erent approaches tohandle 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. Themain contribution of this work is to show how time can be e�ectively introduced in a conventionalobject-oriented context.

2

1 IntroductionConventional database systems do not o�er the possibility of dealing with time-varying data. Thecontent of a database represents a snapshot of the reality in that only the current data values arerecorded, without the possibility of maintaining the complete history of data over time. If such a needarises, data histories must be managed at application program level, thus, making the managementof data very di�cult, if at all possible. To overcome this lack in the past years there has been agrowing 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 pre-liminary stage, altough some proposals can be found in this direction [25]. This research areaseems however very promising since the capability of object-oriented data models to represent in anatural way complex objects and relationships can be extended to the modelling of temporal inform-ation. Two di�erent approaches to model temporal information in object-oriented database systemshave 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 object-oriented data models, based on the attribute timestamping approach, on top of existing object-oriented database systems. In particular, we consider the temporal object-oriented data modelT Chimera [4]. Our discussion is however highly independent from T Chimera and can be adap-ted 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]. Thechoice of Ode as implementation platform is motivated by its support for the common object-orientedmodeling features, and by its support for a versioning mechanism, since we were interested in in-vestigating the possibility of realizing an attribute timestamping model through a system based onthe object versioning approach.Two di�erent implementations are presented and compared in the report: the �rst one is based onthe Ode versioning mechanism, whereas the second makes use of auxiliary storage structures to recordtemporal attributes. The �rst approach demonstrates the feasibility of realizing a temporal objectdata model based on attribute timestamping using a version mechanism, but, as we will discuss in thereport, results in being ine�cient both from a spatial and from a temporal point of view.Thus, thesecond approach has been investigated, which implements the extension of a conventional OODBMSwith temporal capabilities, without relying on any additional mechanisms.The remainder of this report is organized as follows. Section 2 presents the T Chimera tem-poral object-oriented data model. Section 3 introduces the basic notions of the Ode OODBMS, andillustrates its versioning mechanism. Section 4 summarizes the basic assumptions and provides ageneral description of our implementation approaches. Section 5 describes the implementation basedon the versioning mechanism, whereas Section 6 deals with the implementation based on auxiliarystructures. Section 7 presents an example to better illustrate both the implementation approaches.Section 8 discusses issues related to inheritance. Section 9 compares our implementation strategieswith other implementations of temporal object-oriented data models. Finally, Section 10 concludesthe report and discusses further developments. 3

2 The T Chimera Data ModelIn 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, withCI a set of class identi�ers (i.e., class names), and with AN a set of attribute names. Moreover Vdenotes the set of T Chimera legal values.T Chimera supports the notion of type. A �nite set of basic prede�ned types is provided bythe language, containing in addition to the usual (nontemporal) types, a time type. The domain oftime 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 moreoverstructured types such as sets, lists and records, and allows the use of class names in the de�nition ofstructured types. Finally, temporal types are supported: for each type T , a corresponding temporaltype, temporal(T ), is de�ned. Intuitively, instances of type temporal(T ) are partial functions frominstances of type time to instances of type T . Temporal types can be used in the de�nition ofstructured types.In T Chimera a contiguos lifespan is associated with each class, representing the time intervalduring 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 di�erent times are recorded in the database. An immutable attribute is anattribute 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 meaningfulfor the application at hand, and are thus not recorded in the database. Temporal attributes havetemporal types as domains and their values are thus functions from the temporal domain T IMEto the set of legal values for the attribute.1 We represent the value of a temporal attribute of typetemporal(T ) as a set of pairs fh�1; v1i; : : : ; h�n; vnig, where v1; : : : ; vn 2 V are legal values for typeT , and �1; : : : ; �n 2 T IME � T IME are time intervals such that the attribute assumes the valuevi for each time instant in �i, i = 1; : : : ; n. Given a class c 2 CI, A(c) � AN denotes the set ofattributes 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 ofthe objects instances or members of the class over time.2 To represent the extension of T Chimeraclasses, we introduce a function �: CI � T IME ! 2OI , assigning an extent to each class, for eachinstant t. For each c 2 CI, �(c; t) is the set of the identi�ers of objects that, at time t, belong to ceither as instances or as members.Example 2.1 Suppose that i1; : : : ;i5 2 OI. The following are examples of T Chimera classes:� class employee, with lifespan = [10,now], such that:{ 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)1In this report we will concentrate on temporal and static attributes. Immutable attributes can be regarded as aparticular case of temporal ones, since their value is a constant function from a temporal domain.2According to the usual terminology, an object is an instance of a class c, if c is the most speci�c class, in theinheritance hierarchy, to which the object belongs. If an object is an instance of a class it is also a member of all thesuperclasses of this class. 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]. 4A 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; : : : ; an : vn), where a1; : : : ; an 2 AN are the names of the attributesof o, and v1; : : : ; vn 2 V are their corresponding values;class-history is a set fh�1; c1i; : : : ; h�n; cnig, where �1; : : : ; �n 2 T IME � T IME, c1; : : : ; cn 2 CI,such that ci is the class identi�er of the most speci�c class to which o belongs in �i, 1 � i � n.Example 2.2 Consider the classes of Example 2.1, and suppose that i1; : : : ;i5 2 OI. The followingare examples of T Chimera objects:i =i1lifespan = [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)gclass-history = fh[20,now],employeeigi = i2lifespan = [50,now]v = f(name: fh[50,now],`Mary Dole'ig), (salary: fh[50,now],50kig),(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)gclass-history = fh[50,now],managerig 4We require that each object is a consistent instance of all the classes it belongs to. Our notionof consistency keeps into account that, in a temporal context, both the object state and the class anobject belongs to change over time. Therefore, verifying the consistency of an object requires twosteps. First the set of attributes characterizing the object for each instant t of its lifespan must bedetermined. Then, the correctness of their values, with respect to the most speci�c class3 the objectbelongs at time t, must be veri�ed. We refer the interested reader to [4] for further details.3The consistency of an object is checked only with respect to its most speci�c class. If an object is consistent withrespect to its most speci�c class, it is consistent with respect to all its superclasses.5

3 ODE: Object Database and EnvironmentOde [1, 3] is a database system and environment based on the object paradigm. A database canbe de�ned, queried and manipulated in the database programming language O++. O++ borrowsand extends C++ classes by providing facilities for creating and manipulating persistent objects andtheir versions, and for associating constraints and triggers with objects. Moreover, O++ providesother 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 providesencapsulation to hide implementation details, it supports multiple inheritance for organizing objectsin taxonomies in which more specialized objects inherit data and functions from more general ob-jects. Moreover, it separates type de�nition from type instantiation, it allows explicit speci�cation ofrelationships between objects, and it supports object identity that allows persistent objects to havean existence independent from their values.Both volatile and persistent objects are supported by Ode. Volatile objects are allocated involatile memory and they exist from the time of their creation till the time the program creatingthem terminates; by contrast, persistent objects are allocated in persistent store and they continueto exist after the program that created them has completed its execution. The introduction ofpersistence 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 di�erence between accessing and manipulating persistent and volatile ob-jects;� 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++, thuswe do not discuss them here. A relevant peculiarity of the Ode system is, by contrast, its powerfulversioning mechanism, that is illustrated in detail in what follows.3.1 Object Versioning in OdeThe Ode object-oriented database system supports the creation and manipulation of objects withversions [2]. The main characteristics of object versioning in Ode are:� Version orthogonality: Object versioning is orthogonal to types, that is, versioning is an objectproperty and not a type property. Versions of an object can be created without requiring anychanges to the type de�nition of the object. All persistent objects can have versions, and bothversioned and non-versioned objects of the same type can be created. Moreover, a di�erentnumber 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 versionand a speci�c version of an object. The latest version of an object can be accessed by meansof the object identi�er, whereas accesses to a speci�c version are possible since each versionof an object is uniquely identi�ed by means of a version identi�er. Note that, both thesepossibilities are useful for real applications. For example, an address-book object that keepstrack of current addresses should reference the latest versions of person objects to access their6

p pv0 1 0v vbecomesFigure 1: Creation of version v1latest addresses. On the other hand, a software con�guration object may be implemented toreference speci�c versions of objects representing component modules.� Temporal and derived-from relationships: Versions of an object are temporally ordered ac-cording to their creation time. The temporal relationship among versions is therefore a totalordering relationship based on the version creation times. A new version of a given object iscreated by modi�ng an existing version of the object. Therefore, versions are also related bya derived-from relationships, which is a partial ordering relationship re ecting the derivationhistory 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 versionsrelated 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 createdexplicitly by invoking the newvers operation which takes as argument an object identi�er or a versionidenti�er and returns the version identi�er of the newly created version. In particular, the newversoperation receives as input an object identi�er when the new version is derived from the latest versionof the object, rather it receives as input a version identi�er when the new version should be derivedfrom a speci�c version of the object. Operator pdelete can be used to delete both an entire objector 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 functionDprev 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 e�ect of the newvers call can be described pictorially asin Figure 1. In that �gure, dotted boxes denote objects and they encapsulate all versions (representedby circles) of objects. Current versions are represented by double circles. Arrows pointing to boxesrefer 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 temporalrelationship, 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

p

v 01

v

v

2Figure 2: Creation of version v2 derived from v0p

v 01

v

v

2

v3Figure 3: Creation of version v3 derived from v1where vp0 is the identi�er of version v0. The e�ect of the call is to derive a new version v2 derivedfrom 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, v1and v0 represent a version history.4 Overall Description of the ApproachThe main objective of our work is to implement the temporal object-oriented data model T Chimerawith a conventional OODBMS. In particular, we consider the OODBMS Ode and its version mech-anism. 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 supposeit contains a temporal attribute salary. This means that the whole temporal history of attributesalarymust be recorded, rather than its current value only. Conventional databases do not supportthis possibility, since if we introduce a new value for an attribute, the old value is overwritten by thenew one.In order to implement our temporal model on top of the conventional OODBMS Ode, we haverealized 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, andtranslates it into an equivalent set of Ode classes, stored in an output �le f 0. This process isgraphically depicted in Figure 4. This translation allows the management of temporal data.8

schema definition

in T_Chimera

file f

our program

file f’ schema in O++,

able to manage

temporal dataFigure 4: Overall structure of the approachTemporal 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 interpretit. De�nitions of classes in f are copied in f 0. Moreover, the management of temporal data is realizedby introducing some attributes and methods for each class in f . In particular, we have introducedexplicitly the concept of time in constructors and destructors and in all methods which we haveadded. In the following sections, we examine in detail these modi�cations.Note that, our implementation only consider classes whose instances are persistent objects. Thischoice is due to the implicit correlation between a temporal database which memorizes the values ofthe attributes with reference to time and the concept of objects which persist in time.Two di�erent 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 inSection 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 boththe approaches.4.1 Notion of Time SupportedIt is important to emphasize that in T Chimera, and consequently in our implementation, we consideronly valid time (that is, the time in which an event is true in the reality), and we do not considertransaction time (that is, the time in which an event is stored in the database). However, ourimplementation 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 conceptslike hours, minutes and seconds. This choice also means that a temporal attribute is updated atmost once every day. However, our implementation can be easily extended to the consideration ofany temporal granularity.Time is represented by means of the following record structure:struct datefint day, month, year;gWhenever 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 OperationsIn 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 di�erent types of deletion of temporal objects (that is, objects containing at least onetemporal 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 thedatabase but it can no more be updated and it cannot be accessed at times subsequent to itsdeletion.In our implementation we adopt the second approach. The reason is that with this approachqueries requiring values of a temporal attribute of a deleted object on times preceding its deletioncan 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 MechanismsOur �rst approach to implement the T Chimera model is based on the version mechanism of Ode. Inparticular, whenever we want to add a new value to the temporal history of an attribute X of a givenobject, we create a new version of the object, derived from the latest object version. The new versionis a copy of the previous version except that it contains the new value of the temporal attribute X. Inthis way, we create a particular version hierarchy which is composed of a single branch and whoseroot is the initial version, implicitly generated at the moment of the object creation. Moreover, theunique leaf of the version hierarchy stores the latest values of the temporal attributes of the givenobject.Time is not explicitly supported by the notion of version. Therefore, in order to keep track ofthe 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 timeat 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 thede�nition of all user-de�ned class containing at least a temporal attribute. This attribute is initializedto 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 otherones.5.1 Constructors and DestructorsWe 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 initializeand delete the additional attributes we have introduced. In particular, the attribute is alive isinitialized and deleted, respectively, in all user-de�ned constructors and destructors. The attributevalid time is managed in two di�erent ways. In particular, we assign the current time to thisattribute in constructors and destructors without parameters. On the contrary, in constructors anddestructors with parameters, we add a new parameter of type date; the user can use this parameterto specify the creation and deletion time, respectively. If this parameter is null, the current time isconsidered. 10

5.2 Update OperationFor each temporal attribute we de�ne a method which allows to update the temporal history of theattribute. Given an object, the call of the update methods associated with its temporal attributesimplies the following operations:1. creation of a new version of the object derived from the latest version in the version hierarchyof 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 updatemethod.5.3 Delete OperationWe recall that, in our model, the delete operation does not physically delete an object, rather it marksthe object as deleted, without removing its data, which may be accessed by subsequent temporalqueries. 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 isnot 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 thespeci�ed object has been deleted; if its value is false, then an error message is returned and theoperation is not performed.5.4 Search OperationFor every user-de�ned class, we have introduced a search operation which can be used to retrievethe value of a temporal attribute at a given time. This operation consists of a search in the versionhierarchy of the object. In particular, the search operation considers the latest version (which isreturned by the operation vlatest(pthis)) and compares the value of attribute valid time withthe date speci�ed as parameter of the search operation. In this way, we can decide if the informationwe are looking for is in the considered version or if it is necessary to proceed backwards in thehierarchy.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 getsbound to the value of the object attribute at the speci�ed time. Moreover, the method also returns aninteger value which can be used to check whether the search operation has been successfully executed.11

6 Management of Temporal Data through Auxiliary StructuresIn the previous section we have examined an implementation of T Chimera in Ode relying on theOde version mechanism. The main advantage of that approach is the possibility of using featuresprovided by the system, as object versioning and the related member functions. In this way, thee�ective storage of information is a task left to the system; in particular, allocation of structures isan implicit operation. Therefore, the user has the possibility of using temporal data ignoring taskssuch as storage allocation. However, in that approach it is necessary to create a new version (whichin Ode implies to create a new object) every time the value of a temporal attribute is updated. Thisapproach thus implies data duplication, waste of memory and ine�cient search for the value of anattribute at a given date. For these reasons, in this section, we introduce an alternative approachto the implementation of T Chimera on top of Ode. This approach is based on the use of auxiliarystructures to store temporal information. The main di�erence with the versioning approach is theintroduction, in each user-de�ned class, of auxiliary structures to store temporal data.6.1 Auxiliary StructuresThe 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 eachtemporal 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 tothe number of elements in the list. Moreover, the current value of the attribute is stored at the headof the list; in this way, the current value of a temporal attribute can be obtained with a constantcost.A temporal attribute X, with type type X, is thus replaced by a pointer to an ordered list, calledX < class name >, which stores the temporal history of the attribute. For each value, alsothe 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 versioningapproach, 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 storedat the level of each single attribute value. By contrast, the attribute is alive is used as in theversioning approach.Note that the introduction of the auxiliary structures requires to specify appropriate allocationand 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 classattribute valid time which becomes a slot of the auxiliary structures. Therefore, whenever anobject is deleted it is necessary to store of the �nal valid time of the last value of all the temporalattributes. 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 thetime at which an object has been deleted. In Sections 6.2 and 6.4 we will describe its use.6.2 Constructors and DestructorsThe introduction of auxiliary structures to store temporal information implies a relevant change ofthe proper type of a temporal attribute. In particular, the value of a temporal attribute becomes apointer to an appropriate structure. This change implies a substantial transformation of user-de�nedclass 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 usercode, especially to adapt the new types of temporal attributes to the user-de�ned types used in theconsidered 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-temporalattributes and that temporal attributes are completely managed by our program. We examineseparately as we have handled constructors and destructors; moreover, we consider two di�erentcases of constructors, distinguishing whether they are parametric or not.In constructors without parameters we initialize all temporal attributes (which are pointers toappropriate structures) to NULL. Therefore, the call of a constructor without parameters impliesthe creation of an object of the class, whose temporal attributes are set to null. Constructors withparameters are handled in a particular way so that the user can create a new object and initializeall attributes (or only not-temporal attributes) through one of his methods. For each constructorwith parameters in the user-de�ned class two di�erent constructor de�nitions are included in theoutput �le: the original user-de�ned constructor (which has only non-temporal parameters) and anew constructor which adds to the original parameters (speci�ed by the user) all temporal attributesde�ned for the considered class. Note that in both cases we initialize in an appropriate way alltemporal 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 anappropriate structure to store the initial value for each temporal attribute. Moreover, it is necessaryto introduce a parameter time of type date to store the initial valid time of the speci�ed value foreach attribute. As we have said previously, if the speci�ed date is 0/0/0, we consider the currentdate.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 to0/0/0. This attribute will be used in update and access operations, to verify that the object has stillnot 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. Inparticular, note that, besides the recursive deallocation of all the elements of the lists which areassociated to the temporal attributes, we have provided the operations to deallocate the dynamicstructures used as proper types of the temporal attributes as persistent objects or lists.6.3 Update OperationThe update operation allows to update the temporal history of a particular temporal attribute. Eachnew 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 theobject 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 theconsidered attribute in the associated list. In particular, we consider the date of the latest updateand we verify that the date of the new operation is subsequent. If this is not the case, the operationfails 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 parameterof the corresponding update method.6.4 Delete OperationThe operation delete object has been realized in a simple way using the attribute del time. Inparticular, function delete object has a parameter of type date which allows to specify the �nal validtime of the latest value of all temporal attributes of the considered object. This parameter is usedto set the attribute del time.Note that the delete operation of the object must be subsequent to all update operations thatare already stored in the database. For this reason, we have introduced an appropriate check; inparticular, the dates of the latest updates of every temporal attribute are compared with the dateof the delete operation. This check is realized by considering the elements in the head of the listsof values associated with temporal attributes. If the check is not satis�ed, the delete operation failsand an appropriate error message is returned.6.5 Search OperationFor each user-de�ned class we have introduced a search operation which allows to retrieve the valueof a temporal attribute on a given date. This operation consists in a search in the list associatedwith the considered temporal attribute.In particular, the search operation considers the element in the head of the list and comparesits date with the date speci�ed as parameter of the operation. In this way we can decide if theinformation we are looking for is in the considered element, or if it is necessary to consider otherelements of the list. Note that before proceeding in the search, it is necessary to verify that theconsidered 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 aparameter of the method and the method returns, besides the requested attribute value, an integervalue which can be used to check whether the search operation has been successfully executed.7 An Illustrative ExampleConsider a class employeewith the temporal attributes: salary, department and manager. Supposethe following events should be modeled:� On 1/1/90, Mr Paul Smith is employed in the department 3 of the �rm XX; his monthly salaryis $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

code name salary department manager valid_timetime

1578535

*2.500

2.500

* Diana

*3.000

3.000

state 1

state 2

state 3

state 4

state 5

state 6

* it specifies the attribute which is modified

1/1/90 3 Paul 2.000 Mark

1578535

1578535

1578535

1578535

1578535

Paul

Paul

Paul

Paul

Paul

2.500

3

*1

1

1

1

Mark

Mark

Diana

Diana

15/10/95

12/12/93

10/10/92

8/8/91

6/6/90

Table 1: Updates on the employee object corresponding to Mr Paul SmithThese events are summarized in Table 1.Figure 5 illustrates the temporal evolution of the object which represents employee Paul Smithunder the versioning mechanism. Note that each baloon represents a new version created upon anattribute update.Figure 7 illustrates the approach based on axiliary structures. In particular, each temporalattribute is a pointer to an appropriate structure.8 InheritanceThere are some di�erences between the notion of inheritance supported by T Chimera and inheritancemanagement in C++. In both cases, inherited concepts may be rede�ned (overwritten) in a subclassbut it is important to note that in T Chimera the rede�nition of the signature of an attribute ispossible by specializing, that is, re�ning, the domain of the attribute with respect to the notions ofcovariance rule for result parameters and contravariance rule for the input ones. The main idea isthat attribute domains can be replaced in subclasses by re�ned types. This means that, as suggestedin [10], a non-temporal attribute can be re�ned in a temporal attribute (on the same domain or ona most speci�c one), but not vice-versa.In C++, each subclass must contain all attributes and operations of all its superclasses but thepossibility of re�ning an attribute domain is not supported. In particular, an attribute which isde�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 di�erent tokens and in their use the notion ofenvironment is crucial.In the following subsections we examine as we have realized the inheritance concepts of T Chimerain our approaches. In particular, we deal with single and multiple inheritance with respect to temporalattributes. The discussion applies to both our implementation approaches.8.1 Single InheritanceA derived class inherits all temporal attributes which are de�ned in its base class, moreover, wewould like to support the re�nement of attribute domains. In particular, we have handled thefollowing 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 amore speci�c domain); 15

1578535

Paul Smith

2.000

3

Mark Trent

1

1/1/90

1578535

Paul Smith

2.500

3

Mark Trent

1

6/6/90

1578535

Paul Smith

2.500

1

Mark Trent

1

8/8/91

1578535

Paul Smith

2.500

3

Diana Conrad

1

10/10/92

1578535

Paul Smith

3.000

3

Diana Conrad

1

12/12/93

1578535

Paul Smith

3.000

3

Diana Conrad

0

15/10/95

*

*

*

*

*

* it specifies the attribute which is modified

this attribute (is_life) specifies the modificability of the object

Figure 5: Temporal updates through the versioning mechanism16

3.000

2.500

2.000

1/1/90

6/6/90

12/12/93

NULL

t_salary

3

1

1/1/90

8/8/91

NULL

t_department

Mark Trent

Diana Conrad

1/1/90

10/10/92

NULL

t_manager

Figure 6: Temporal updates through auxiliary structures17

A

C

D

B

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 (onthe same domain or on a more speci�c one), but not vice-versa. This restriction has been realizedby checking that any non-temporal attribute which is speci�ed in a subclass has not previously beende�ned in any superclass. Otherwise, an appropriate error message is returned and the derived classis not speci�ed in the output �le.8.2 Multiple InheritanceThe introduction of multiple inheritance causes some di�culties. In particular, there is an ambiguoussituation when an attribute is de�ned in several superclasses of a derived class. In C++, thisambiguity can be solved through the notion of environment, that is, by explicitly specifying in theattribute access the superclass where the considered attribute is de�ned. This allows to manage allattributes referring to the superclasses where they are de�ned. We prefer to solve the ambiguity atschema 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 derivedclass.In particular, a particular ambiguity to be managed arises when in a superclass an attribute isde�ned as temporal whereas it is de�ned as non-temporal in a di�erent superclass. In this case, theonly 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 attributenames involved in some ambiguities. Moreover, those derived classes are ignored in the generationof the output �le.Moreover, the notion of virtual class typical of C++ has been extended with respect to theintroduction of temporal attributes. We start from the assumption that if a class is present in moreinheritance 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 thefollowing we discuss all possible cases that can arise and our solutions with respect to the introductionof 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 orwith a more speci�c one) in B and/or C, the use of this attribute in D is ambiguous, then it isrequired 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 useof 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 isnot ambiguous: our program manages this situation and allows the implicit inheritance of thistemporal 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 notambiguous.9 Comparisons and DiscussionIn the previous sections we have examined two di�erent approaches to implement T Chimera inOde. In this section we analyze and compare the proposed implementations. Moreover, we compareour approaches with two implementation approaches proposed in the literature: the one of Steinerand Norrie [27], and that of K�afer and Sch�oning [19, 20, 21]. Though for other temporal object-oriented models prototypal implementations have been developed [18, 24] not enough details of suchimplementations are available to allow an in-depth comparison with ours.9.1 Comparison between our ApproachesThe �rst implementation approach is based on the versioning mechanism of Ode. This solution allowsto realize the management of time according to the attribute timestamping approach, as suggested inT Chimera, using the object versioning mechanism provided by Ode. In other words, this approachallows to create and manipulate temporal attributes by \hiding" these information in the context ofobject versioning. In this way, the management of temporal attributes is simpli�ed as the storing oftemporal data is a task left to the system, which relies on the notion of version. In particular, eachupdate of a temporal attribute implies the creation of a new version of the corresponding object. Inthis way, we create a hierarchy of versions whose root is the �rst version implicitly created upon thecreation of the object, and whose (unique) leaf is the latest version which stores the latest values theobject temporal attributes.The main disadvantage of this approach is that an high number of versions must be created inorder to store the temporal history of an attribute. In particular each element of the history requiresthe creation of a new version. In Ode each version is implicitly realized by the creation of a newobject of a system class. Therefore, the use of a great number of versions implies the creation ofa great number of persistent objects. Moreover, we need to consider the duplication of informationand, in particular, of values of temporal attributes in di�erent versions. In fact, the update of aparticular temporal attribute implies the creation of a new version whose state is identical to that ofthe previous version, except for the updated attribute. The values of the other objec attributes, bothtemporal 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 e�ciency. Consider thesearch of the value of a temporal attribute at a given date. This operation implies the scanning ofthe hierarchy of versions of the considered object. In particular, the latest version is examined andthen we proceed backwards in the hierarchy until a version is found whose valid time is less than orequal to the date speci�ed in the search operation. The computational cost of the scanning of thehierarchy is proportional to the number of object versions; therefore, it depends on the total numberof updates to temporal attributes of the object rather than on the updates to the considered attributeonly.The second implementation approach is based on the use of auxiliary structures to store temporalinformation. This alternative has made the management of information more di�cult but it hasimproved both memory occupation and the computational cost of the search operation. The mainidea of this second approach is to maintain an ordered list of values for each temporal attribute. Inthis way, duplication of information is avoided as the update of a temporal attribute implies only theintroduction of a new element in the head of the corresponding list. Moreover, searching the value ofa temporal attribute at a given date is realized by scanning the list associated with the consideredattribute. Obviously, the number of elements in the list depends on the number of updates to theconsidered attribute.It is important to note that the di�erences for the user between the two implementation approachesare minimal. In fact, in both cases, the management of the temporal data is realized by appositemethods.9.2 Comparisons with the Implementation Approach of Steiner and NorrieThe 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 O2system. It is very important to note that their implementation approach is deeply in uenced by theconsidered timestamping granularity. In particular, Steiner and Norrie have proposed to generalizetheir idea also to attribute timestamping. Our main objective is to compare their proposal with ourrealization 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 systemarchitecture of O2 is divided into several layers and the base of O2 is the O2Engine which providesall the features of a database system and all the features of an object-oriented system. Severalprogramming interfaces are built on top of the O2Engine as O2 and OQL. Such interfaces have beenused to support temporal functionalities. In particular, a new class TempObject, subclass of the rootclass Object, common to all system and user-de�ned classes, has been de�ned to manage temporaldata. Therefore, if the user wants to de�ne a class of temporal objects, he can specify this new classas 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 isnot a common root class and the code of the system class to implement versioning mechanism is notavailable.Note that the approach of Steiner and Norrie, like ours, only considers the concept of valid time. InTOM the temporal approach based on attribute timestamping is supported through a generalizationof the approach based on object timestamping. In particular, if a user wants to maintain the historyof an attribute, this must be stored as an object. For instance, the salary history of an employee canbe represented as a set of temporal objects, where each object is used to represent a particular value20

in the salary temporal history. As an attribute can have the same value in di�erent, not necessarilycontiguos, 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 historyof an employee can be modeled. First the classes employee and salary history are de�ned. Thevalues of attribute salary are modeled by objects of the class salary history, This implies thatseveral objects of this class (one for each distinct value) must be created to model the temporalhistory of attribute salary. First, note that the transformation of the type of the attribute impliesthe substitution of an integer with a persistent object. This implies the creation of a great numberof persistent objects. Moreover, consider that a value of an attribute is repeated for the same objectin very unusual cases. For example, if we consider the attribute salary of the class employee, itis unusual that the salary of an employee is reduced exactly to a previous salary. Thus, an highnumber of objects need to be created to model the di�erent 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 representingthe set of instants in which this value is valid for a particular employee. In this way, several objectsof the class salary history must be created, representing the same value for di�erent employees.Note that this choice implies the duplication of the same value for all objects employee in whichthe temporal attribute assumes this value. For example, suppose that 10 employees receive or havereceived in the past a salary of $2000, then we have 10 objects of the class salary history torepresent this value.Let us now consider the access to temporal information. As we have already said, each value istransformed in a persistent object in the database. Therefore, if we query the database searching forthe value of an attribute of a particular object, wemust look for the considered object and successivelylook for the related object which models the value. This approach implies two successive memoryaccesses which would involve two di�erent physic cylinders unless we use appropriate clusters togroup these information and speed up queries.To express temporal operations, Steiner and Norrie introduce appropriate function. For examplemethods to calculate intersection or union of sets of temporal objects are provided. Unfortunately, inO2 only classes and named objects may be exported from schemas. This means that all the temporalfunctions have to be methods of an exported class. Adding them as methods to class TempObjectmeans 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 whichare 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 temporalattributes. 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 themonthly 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 ofobjects, like the one we support, which marks the object as deleted and allows no more modi�cationson it, need to be supported.9.3 Comparisons with the Implementation Approach of K�afer and Sch�oningIn this subsection we examine the temporal data model TMAD and its implementation, and wecompare it with our implementations. The main objective of K�afer and Sch�oning [19, 20, 21] is toshow that a complex object data model is an appropriate means for handling temporal data. Inparticular, they explain the mapping of time sequences onto recursively structured complex objects21

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 themodel, called PRIMA. Note that T MAD is based on object timestamping as time is associated withthe whole object. Note that in all models based on the concept of version, the temporal notion ismaintained implicitly by a temporal order of the object versioning. T MAD, by contrast, introducesthe concept of valid time and transaction time.The main idea behind the approach of K�afer and Sch�oning, is the concept of Time Sequence(TS), that is, a time-ordered sequence of all snapshots of a real word entity. In particular, a TSrepresents the history of an entity of the real world and can be seen as an extension of a tuple inthe 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 onlyvalid 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 capturesome characteristic values at single moments. Based on these characteristic values, the history hasto be reconstructed by a function, for example, linear interpolation.It is particularly interesting to note that the implementation choices to model the concept of timesequence are similar to our implementation approach to realize T Chimera in Ode by the versionmechanism. The de�nition of the type time to represent the temporal concept and the introductionof some system attributes to manage the temporal information are analogous to our proposal. Inparticular, K�afer and Sch�oning introduce the attributes valid and timestamp to memorize the validand the transaction time with respect to a particular event, respectively; in a similar way, we introducethe attribute valid time which represents the valid time of a value of a temporal attribute. Moreoverthe attribute alive used in T MAD corresponds to our attribute is alive. Note that these analogiesallow to handle in the same way the delete operation; in particular, the attribute alive representsthe concept of updatability of an object which is used to delete an object with at least a temporalattribute.The analogy between the two implementation approaches implies the same drawbacks such as dataduplication. T MAD presents some suggestions to reduce the amount of storage space. K�afer andSch�oning suggest to store only the di�erences between two adjacent tuples instead of the completeinformation. In particular, instead of storing the full data only the result of an EXOR operationbetween the current tuple and the predecessor tuple is stored. Note that the youngest tuple iscompletely stored whereas all older tuples are represented only by di�erences. The EXOR operationis only applicable at the byte level of the database management system. This has three majordrawbacks:� 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 recon-structed by traversing a chain of di�erences starting with the current tuple;� the di�erences are \unstructured" tuples for the higher levels of the database managementsystem.Thus, conventional access path structures cannot be used on history data. Hence, they suggest usinglogical rather than physical di�erences, that is assigning null-values to those attributes which are notaltered 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 tuplesin which the requested value is stored; 22

� in PRIMA, the PRototype Implementation of the MAd model, null-values do not need anystorage 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 di�erences between a version and the previousversion.Finally, it is interesting to note that in all temporal data models that we have considered in thissection, only a linear notion of time is considered. In [20], K�afer and Sch�oning show that the non-linearity found in versioning models can be implemented using the same approach. This characteristiccan be an interesting development also for our approach.10 Conclusions and Future WorkIn this report we have described and compared two di�erent approaches to implement a temporalobject model on top of an existing OODBMS provided with a version mechanism. This work is partof a wider research e�ort we are carrying on temporal object-oriented database systems. Thus, weplan to extend this work in several directions. For what concerns the data model, we are currentlyinvestigating how ad-hoc storage structures and indexing techniques developed for temporal relationalmodel [14, 22] can be integrated with those developed for object-oriented databases [7] so thattemporal object-oriented databases can be e�ciently indexed and accessed. Then, we would like toextend the developed system to support event-based temporal object models [6]. An event-basedtemporal object model allows to keep track of selected values within the temporal history of a dataobject attribute. The portions, within the temporal history of a data object, which are actually storedinto 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 ofthe OQL object query language [9]. The implementation of this query language on top of our systemis another direction of future work.References[1] R. Agrawal and N. Gehani. ODE (Object Database and Environment): The Language and theData 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. SeventhIEEE 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. InP. 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 Tem-poral Data. Technical Report, Department of Computer Science, University of Milano, January1997.[7] E. Bertino andW. Kim. Indexing Techniques for Queries on Nested Objects. IEEE Transactionson 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, Object-Oriented 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 theInt'l Workshop on an Infrastrutcture for Temporal Databases, 1993.[11] J. Cli�ord and A. Crocker. Objects in Time. In Proc. Fourth IEEE Int'l Conf. on DataEngineering, pages 11-18, 1988.[12] J. Cli�ord and A. Crocker. The Historical Relational Data Model (HRDM) Revisited. InA. Tansel, J. Cli�ord, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass, editors, TemporalDatabases: 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. InA. Tansel, J. Cli�ord, S. Gadia, S. Jajodia, A. Segev, and R. Snodgrass, editors, Temporaldatabases: 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. Clif-ford, 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. �Ozsu. Temporal Extensions to a Uniform Behavioral Object Model.In R. Elmasri, V. Kouramajian, and B. Thalheim, editors, Proc. Twelfth Int'l Conf. on theEntity-Relationship Approach, volume 823 of Lecture Notes in Computer Science, pages 110{121. Springer-Verlag, Berlin, 1993.[19] W. K�afer, N. Ritter and H. Sch�oning. Support for Temporal Data by Complex Objects. InD. McLeod editor, Proc. Sixteenth Int'l Conf. on Very Large Data Bases, pages 24-35, 1990.[20] W. K�afer and H. Sch�oning. 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. K�afer and H. Sch�oning. Realizing a Temporal Complex-Object Data Model. In M. Stoneb-racker 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. Cli�ord, S. Gadia,S. Jajodia, A. Segev, and R. Snodgrass, editors, Temporal databases: Theory, Design, andImplementation, pages 418-432. Benjamin/Cummings, 1993.[23] M. T. �Ozsu, R. Peters, D. Szafron, B. Irani, A. Lipka, and A. Munoz, TIGUKAT: A UniformBehavioral 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 TemporalConstraints. 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. Addison-Wesley/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. Oliv�e and J. A. Pastor,editors, Advanced Information Systems Engineering, Proc. Ninth Int'l Conf. CAiSE'97, LectureNotes in Computer Science, Vol. 1250, pages 245-258, 1997.[29] S. Su and H. Chen. A Temporal Knowledge Representation Model OSAM*/T and its QueryLanguage 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 Granu-larities. In Proc. International Conference on Information and Knowledge Management, pages304-311, 1995.[32] G. Wiederhold, S. Jajodia and W. Litwin. Dealing with Granularity of Time in Temporal Data-bases. In R. Andersen and J.A. Bubenko, editor, Advanced Information Systems Engineering.Solvberg, pages 124-140, 1991.25