Temporal Database Modeling:

An Object-Oriented Approach

Ramez Elmami* Vram Kouramajian ~ Shian Fernando~

Abstract

This work proposes a number of different approaches

for incorporating temporal extensions to object-oriented

databases. One important question that arises when dealing

with temporal databases in the context of objec&oriented

systems is whether to associate time with objects or with

attributes. Results of previous work comparing tuple (ob

ject) versioning and attribute versioning — such as whether

to extend flat (F’NF) or nested (NF’NF) relational models —

are not applicable to temporal object-oriented databases.

This is because object-oriented models provide more power-

ful constructs than traditional modeis for structuring com-

plex objects.

Our goal in this paper is to study alternative temporal

object-oriented database representations by identifying the

different techniques for representing temporal databases in

an object-riented framework. This is in contrast to other

work that adopts a single particular approach. Our goal is

to determine the particular situation for which each repr~

sentation is applicable. We define the concepts of object ver-

sioning and attribute versioning in temporal object-oriented

models, and we concentrate on identifying the various rep-

resentations of temporal relationships between objects.

Another contribution of this paper is to analyze our dif-

ferent temporal representations and to determine their stor-

age requirement. A general framework is defined in which

the characteristics of various temporal models are studied.

A simulation study is performed comparing storage costs of

our various temporal representations, and also a temporal

FNF relational representation.

* Computer Science Engineering Department ,The University

of Texas at Arlington, Arlington, Texas 76019, Fax: (817) 273-

3784, Telephone: (817) 273-3785, Email: ehnasri@cse.uta.edu.

t Office Of The Vice President for Resemch & Information

Technology, Rice University, P.O. Box 1892, Houston, Texas

77251, Fax: (713) 523-0259, Telephone: (713) 523-0080, Email:

vram@rice .edu. This work was done while the author was *oci-

ated with The University of Texas at Arlington.

~ Computer Science Engineering Department ,The University

of Texas at Arlington, Arlington, Texas 76019, Fax: (817) 273-

3784, Telephone: (81 7) 2733785, Email: fernando@cse.uta.edu.

Permission to copy without fee afl or pwt of this material is

grantad providatf that tho copies aro not made or cfistributad fordirect commercial advantaga, tha ACM cop~ight notico ●nd tha

titla of the publication and ita date appeor, ●nd notice is @venthat copying ia by parmkion of tha Association for ComputingMachinary. 10 copy otherwise, or to rapublish, requires a faaarrdlor specific permission.

CIKM ’93-1 l/93/O. C., USA

@ 1993 ACM 0-89791-626-3/93/001 1 .. ..$1.50

1 Introduction

Temporal databases and object-oriented databases will

play an important role in next generation database sys-

tems. If their capabilities are fully utilized and their fea-

tures merged, they will provide the ultimate database

systems to users. The goal of temporal databases is

to uniformly integrate past, current and future infor-

mation in a unified system [Snod87, Jens90, E1WU90,

WuDa92, Pisa91, PiMa92]. A key feature of object–

oriented databases is to provide support for complex

objects by specifying both the structure and the oper-

ations that can be applied to these objects [BeGe91,

Deux91, Catt91].

Advances in storage technology will soon support ef-

ficient implementations of temporal databases. With

the continuing advances in optical and magnetic disk

technologies, keeping the full history of all changes

on-line and readily available on disk is becoming a

practical possibility. In parallel, research in tem-

poral database models and languages haa increased

rapidly; and has been applied primarily in the con-

text of the relational model of data [Snod87, GaYe88,

NaAh89, Jens90], and to a lesser extent, in conceptual

and object-oriented data models [E1WU90, E1EK90,

RoSe91, Piaa91, PiMa92, WuDa92].

A question that arises when dealing with temporal

databases in the context of object-oriented systems is

whether to associate time with objects (tuples) or with

attributea. In the context of other data models, the

work in [Snod87, NaAh89, Jens90] supports object (tu-

ple) versioning; whereas that in [GaYe88, E1WU90] sup-

ports attribute versioning. While there have been var-

ious arguments in favor of both represent at ions, the

most prominent one — whether it is better to extend

flat (FiVF) or nested (NFNF) relational models — does

not hold in temporal object-oriented databases, since

object-oriented databases support powerful construc-

tors for complex objects [LeRV88].

Our approach in this paper is different from previous

work. Instead of adopting a specific object-oriented

temporal model [WuDa92], we study a number of al-

ternative temporal representations for object-oriented

databases. One of the main contributions of this paper

574

is to identify the different techniques for representing

temporal databases in an object-oriented framework.

We define the concepts of object versioning and at-

tribute versioningin temporal object–oriented models,

and we concentrate on identifying the various represen-

tations of temporal relationships between objects. We

do not study the representation of temporal subclasses,

which is discussed in [E1EK90].

Another contribution of this paper is to analyze

our different temporal representations and to determine

their storage requirement. A general framework is de

fined in which the characteristics of various temporal

models are studied, A simulation study is performed

comparing storage costs of our various temporal repre-

sentations, and also a temporal FNF relational repre-

sentation [Snod87].

This paper is organized as follows. In section 2,

we review object-oriented data model constructs and

previous temporal representations. In section 3, we

discuss the various alternatives in Temporal Object–

Oriented DataBases ( TOODB) representation. In sec-

tion 4, we analyze in detail two TOODB representa-

tions, one based on object versioning and the other on

attribute versioning. Finally, section 5 contains a con-

clusion and planned future work.

2 Review of Object-Oriented

and Temporal Models

In this section, we briefly review objectmmiented and

temporal data models. Section 2.1 discusses object–

oriented data model constructs and section 2.2 reviews

time representation and temporal databases.

2.1 Object-Oriented Data Model Con-

structs

The features and advantages of 00DB are discussed

and well documented in the literature [BeGe91, Deux91,

Catt91, ElNa93]. Basically, each real-world entity is

modeled by an object, which has a unique identity. Each

object has a set of attribute values and a set of meth-

ods. Objects sharing the same structure and behavior

are grouped together into a class, and the objects of

that class have the same object type definition. In ad-

dition object-oriented models support the concepts of

clsm/subclasa inheritance, encapsulation, and informa-

tion hiding.

In object-oriented databases, the value of a complex

object may be constructed from other objects by us-

ing certain type constructors [LeRV88, Deux9 1]. Each

object may be viewed as a triple (i, c, v), where i is a

unique object identifier, c is a constructor that indicates

how the object value is constructed, and v is the object

value. The standard constructors are the atom, tuple,

and collection (set, list, bag, array). If c = atom, then

the value v is an atomic value from the domain D of

all possible basic values that are represented in the sys-

tem. If c = tuple, then the value v will be a tuple of

the form < al : il,az : iz, . . ..a~ : L >, where each

aj is an attribute name and each ij is an object identi-

fier, If c = set, then the value v will be a set of object

identifiers {il, iz, . . . . in}. A list is an ordered set, and

hence we can refer to the first, second, or ith object

in a list. A bag is also similar to a set, except that it

allows duplicate values to exist. An Array is a multi–

dimensional collection. The internal representation of

collections is transparent to users; and for performance

tuning purposes, it may be represented as B-trees or

hash tables [LaLa91]; or even as a time index [E1WK90]

or a monotonic B+-tree [E1JK92] for efficient temporal

representation.

The above model allows arbitrary nesting of con-

structors. In this model, all values in non-atomic ob-

jects refer to other objects by their object identifiers.

This implies that the system must generate a unique

identifier for every non-atomic object. In practice, most

systems will allow both object identifiers and structured

values with no unique identities [Deux91]. Built-in lit-

eral (or structural) values cannot be shared among ob-

jects.

One of the main issues in object-oriented database

systems is how to represent relationships among objects.

The enforcement of complete encapsulation in early

object-oriented systems led to models in which relation-

ships were not explicitly represented, but were described

by defining appropriate methods to access related ob-

jects. However, this approach does not work well for

complex databases with multiple relationships, because

it is useful to identify these relationships and make them

visible to users. Most object-oriented database systems

allow the representation of two main types of relation-

ships: (a) is–part-of and (b) is–associated-with. The

is-part-of relationship has an ownership semantic and

describes how a complex object is made up of comp~

nent objects. The is–associated–with relationship has a

reference semantic and describes an equal association

among objects. Our work concentrates on identifying

various representations of is–ssaociated-with relation-

ship in temporal databases.

Example 1: All temporal object-oriented database

examples given in the rest of the paper will be

based on the non-temporal object-oriented Em-

ployee/Department database given in Figure 1, which

describes a simplified organization for part of a company

databrd. An employee belongs to only one depart-

ment at a time, but may currently be working for sev-

I For ~mphcity, we will not distinguish between private and

public class members.

575

class Emp

string ssn;

string name;

real salary;

ref Dept manages; // inverse of Dept. manager

ref Dept belongs. to; // inverse of Dept. stafl’

// inverse of Dept. workers

set <t uple (ref Dept dept-of, real hours)> works.for;

method void give-raise(percent: real);

end class Emp;

class Dept

string dname;

string dphone;

ref Emp manager; // inverse of Emp.manages

set <ref Emp> staff // inverse of Emp. belongs-to

// inverse of Emp.works.for

set <t uple (ref Emp emp.of, real hours)> workers;

end class Dept;

Figure 1: An Employee/Department Database

eral departments (on different projects). Furthermore,

each department is managed by a single employee at a

time. In Figure 1, we use a notation similar to [Deux91,

ElNa93]. The keywords tuple, set and list are used to

specify the various constructors. The comments identify

reference attributes that are inverses of each other since

they describe a particular relationship in two directions.

This is a common technique for describing relationships

in object-oriented models2.

2.2 Review of Temporal Databases

In this section, we briefly review the representation of

time in temporal relational models. Section 2.2.1 de-

scribes the abstract data type time used in this paper.

Section 2.2.2 reviews temporal representations.

2.2.1 Representing Time

Let T be a countably infinite set of totally or-

dered discrete time points3, where T is denoted as

T = {t-m ,.. ., fo, il, ~now,tnow+ljw+lj. . .,t+m}, and

t” ow represents the current time point which is con-

tinuously increasing. We define a time interval, de-

noted by [t/,t.) [WiJL91], to be a set of consecutive

equidistant time instances, that is the totally ordered

set {ti, tt+l, ..., t“-1} c T.

2 some ~ ODBMSS, such M Object Store [LaLa91], WOW the

specification of inverse relationships in the schema.

3A time point is really the smallest possible interval, which is

considered atomic or indivisible. This has been called a chronon

[JCGS92]. An application cannot distinguish between different

points within the chronon. We will use the terms time point and

chronon interchangeably.

Smith

Brown

Brown

LBrown

Jones

Engineer

Analyst

DBA

DBA

CEO L48K 9/91 - now

32K 8/89 - 6/90

40K 6/90 – 1/92

46K 1/92 – now

80K 1/91 – now

(a)

Name Title Time-Interval I Salary Time-Interval

Smith Engineer 9/90 – now 35K 9/90 - 9/91

48K 9/91 – IiOW

Brown AnaJyst 8/89 - 6/90 32K 8/89 – 6/90

DBA 6/90 – now 40K 6/90 - 1/92

46K 1/92 – now

I Jones I CEO 1/91 - now I 80K 1/91 - now I

(b)

Figure 2: Temporal Representations

In temporal databases, it is customary to include

a number of different time dimensions. Two of the

most common ones are valid time and transaction time

[Snod87]. Additional time dimensions are also possible

and sometimes necessary [JeSn91]. In this work, an ab-

stract data type will be assumed to represent the Time

type, which may describe any time dimension. We will

not be concerned with the exact representation of time

because the semantics of the type Time does not affect

our various temporal object-oriented models.

2.2.2 Temporal Representation

Research in temporal models haa moved in two direc-

tions. The work in [Snod87, NaAh89, Jens90] supports

object versioning; whereas that in [GaYe88, E1WU90]

supports attribute versioning. Most previous represen-

tations are limited to the relational model and mainly

address the issue of adding temporal capabilities to the

query language. We review the two representations be-

low:

1.

2.

Object versioning: Each object is augmented with

two chronons tzand tu,which specify a time inter-

val [t~,tu) during which an object version is valid

(See Figure 2 (a)). Each temporal real-world ob-

ject is represented by a number of object versions

in the database.

Attribute versioning: Each attribute is represented

as a list of (value, interval) pairs, where the in-

terval [tr,t.) is associated with each version of an

attribute value rather than with a complete object

version (See Figure 2 (b)).

world object is represented

(nested) database object.

Each temporal r~al-

by a single complex

576

Relationship Object Used?

J /’ Main Diagonal

Ye . . . . . . .. . . ...”....---

NIxi...........!: . . . .

v , + Type of VersioningAttribute Object

Figure 3: The Representation Matrix

3 Alternative Temporal 00DB

Models

Instead of espousing a particular approach for tempo-

ral representation in an 00DB, our aim is to study a

number of alternatives. We try to identify the funda-

mental features of various representations and provide

a general framework in which performance comparisons

can be made. We use a representation rnatm”x to define

the alternatives. Figure 3 shows the representation ma-

trix. The x-axis represents the two main techniques of

temporal representation, namely, attribute and object

versioning. The y-axis denotes the various techniques of

representing a relationship between two objects. This

can be accomplished either by relating entity objects

together through reference (link or pointer) attributes

(i.e., without defining a relationship object), or by defin-

ing an explicit relationship object. The representation

matrix gives us four frameworks to compare the various

alternatives. They are: (a) attribute versioning without

relationship object, (b) attribute versioning with rela-

tionship object, (c) object versioning without relation-

ship object, and (d) object versioning with relationship

object. Additional variations of these frameworks are

also possible. In sections 3.1 and 3.2 we will only cover

the points along the main diagonal of the matrix (see

Figure 3) mainly because of space limitations, and also

since our initial estimates show them to be the promis-

ing approaches to temporal object-oriented representa-

tions. (For a complete discussion, see [KoEF94]).

3.1 Approach 1: Attribute Versioning

without Relationship Object

3.1.1 Object Representation

We consider this approach to be the pure temporal

object-oriented based represent at ion. This is because,

in attribute versioning, each database object captures

class Objeet

// non-temporal attributes

TypeAttrl attrl;

. . .

// methods

Type_Methodl Methodl;

. . .

// temporal attributes

list <tuple (Type_TAttrl attrl, Time time)> t_attrl;

. . .

// one-to-one and many-to-one relationship directions

list <tuple (ref tol-Objeet 1 tol-objl,

Type-Rel_Attrl rattrl, . . . .

Type_Rel-TAttrl rtattrl, . . . .

Time time)> t-tol-objl;

. . .

// one-t~many and many-t~many relationship directions

list <tuple (set <tuple(ref toN_Objeet 1 toN.objl,

Type-Re14ttrl rattrl, . . . .

TypeRel_TAttrl rtattrl, . . . )>

toN-objsl, Time time)> t.toN-objsl;

end class Object;

Figure 4: A Template for Attribute Versioning without

Relationship Object

the full history of a real-world object, In this repre-

sentation, each class in a non-temporal object-oriented

database will be modeled by a single tempoml class in

the corresponding temporal object-oriented database,

and therefore a temporal class will group together the

temporal and non-temporal properties of a real-world

entity. A template for attribute versioning without re-

lationship object is given in Figure 4.

Each temporal attribute is modeled by a list of tuples,

where each tuple consists of the pair ( attribut e-type,

time-type). For instance, in Figure 5, the saIary of an

employee (in the class Emp) is described as a list of

tuples t_sa/ary, where each tuple consists of the pair

(sa/ay, time).

Each time a (temporal) attribute value of an object

is modified, a new pair ( attn”bute, time) is created and

inserted at the beginning of the list representing the

temporal attribute. The new value pair (attribute, time)

represents the current state of the attribute and can be

readily accessed since the list is kept in descending order

of timevalue, We analyze the storage cost of temporal

objects in section 4.

A snapshot of a temporal object at a particular time

t is captured by retrieving the values of its non-temporal

attributes, and by selecting the values of its temporal

attributes through querying at time t on the (attribute,

time) value pairs of each of its attribute lists.

Relationships are not treated as first class objects in

this approach since they are modeled through reference

(link) attributes. The modeling of temporal relation-

577

class Emp

string ssn;

string name;

list <tuple (real salary, Time time)> t-salary;

list <tuple (ref Dept manages, Time time)> t-manages;

list <tuple (ref Dept belongs.to, Time time)>

t.belongs-to;

list <tuple (set <tuple (ref Dept dept-of, real hours)>

works_for, Time time)> t.works_for;

method void give_raise(percent: real);

end class Emp;

class Dept

string dname;

list <tuple (string dphone, Time time)> t.dphone;

list <tuple (ref Emp manager, Time time)> t-manager;

list <tuple (set <ref Emp> stti, Time time)> t=taff

list <tuple (set <tuple (ref Emp emp-of, real hours)>

workers, Time time) > t-workers;

end class Dept;

Figure 5: Attribute Versioning without Relationship

Object

ships is different from that of temporal attributes. Each

temporal relationship is described by a list of tuples,

where each tuple consists of the pair (relationship-type,

time_type). The relationship-type is represented either

as a single reference attribute (case of 1 :1, IV : 1) or as

a set of reference attributes (case of 1 : N, Al : A’). If

the relationship has attributes, they are included with

the reference using the tuple constructor.

Example 2: In Figure 5, the three relationships be-

tween an employee and a department are depicted as

follows:

1.

2.

3.

The 1 : 1 relationship (a single employee man-

ages a department) is represented by “list <tuple

(ref Dept manages, Time time)> t-manages” in

the Emp class and “list <tuple (ref Emp manager,

Time time)> t_manageP in the Dept class.

The N : 1 relationship (an employee belongs to

only one department) is captured by “list <tuple

(ref Dept belongs_to, Time time)> t_belongs_to” in

the Emp class and “list <tuple (set <ref Emp>

stafl, Time time)> t-stafl in the Dept class.

The h4 : A’ relationship (an employee may cur-

rently be working for several departments) is de-

scribed by “list <tuple (set <tuple (ref Dept

dept. of, real hours)> works-for, Time time)>

t.works-fo#’ in the Emp class and “list <tuple (set

<tuple (ref Emp emp.oj real hours)> workers,

Time iime)> Lworkers” in the Dept class.

3.1.2 Constraints

The only restriction imposed on a temporal attribute is

that for any two pairs (U1, tl ) and (U2, tz) in its version

list, we have tl (li’z = 0. The restrictions that must hold

between reference (link) attributea of related objects

are given below, where we assume that re f erence-iistl

in Cl and reference_list2 in C2 are inverse temporal

reference attributes representing the same relationship.

These constraints specify the inverse property on two

temporal reference attributes.

1. 1:1 relationship between Cl : C?:

(a) V (Vi, t;) in reference_ /ist~, 3 (Vj, tj) in

reference-list2 such that ii= tj

(b) V (vi, ti) in referenceJist2, 3 (t)j, tj) in

referenceJistl such that ti= tj

2. 1: N relationship between C’l : C2:

(a) V (Vi,ti)in reference-list~, 3 (Vj,tj) in

referenceJist2 such that ti~ tj

(b) V (t)i, ti) in referenceJist2, 3 U(vj, tj) in

referenceJistl such that ti= utj

3. M : N relationship between Cl : CP:

(a) V (Vi, ti) in referenceJist~, 3 U(vj, tj) in

reference_ list2 such that ti= Utj

(b) V (vi, ti) in reference_list2, 3 U(vj, i!j) in

reference-list 1 such that ti= u j

3.2 Approach 2: Object Versioning

with Relationship Object

3.2.1 Entity Object Representation

In this representation, each entity class in a non-

temporal object-oriented database will be modeled by a

pair of (parent, child) classes in the corresponding tem-

poral object-oriented database. A parent class groups

together the non-temporal attributes of a real-world

concept and a child class the temporal ones. Each (non-

temporal) parent object will include (a) a lifespan Time

value, (b) the non-temporal attribute values and meth-

ods of an object, (c) a list of references to its child ob-

jects (versions), and (d) a number of sets where each set

denotes a relationship and refers to all parent relation-

ship objects of the child relationship objects4 in which

the child objects participated during their lifespan.

Each child object of a parent object is a temporal

version, and includes (a) a time attribute value specify-

ing the version time interval, (3) the temporal attribute

4 (parent, child) relationship classes will be discussed later.

578

class Parent-Entity

Time lifespan;

Type-Attrl attrl;

class Parent .Rel

Time lifespan;

Type_Attrl attrl;

!..

Type-Methodl methodl;

. . .set < ref ParentRell > prl;

. . .list < ref Child-Entity > child-versions;

end class Parent-Entity;

class ChHdXntit y

Time time;

Type-TAttrl tattrl;

. . .ref Child-to l-Rell ctolrl;

. . .set < ref Chlld40NJtell > ctonrl;

. . .end Class Cldld-Entity;

Figure 6: A Template for Entity Object Representation

values of the object5, (c) a number of references where

each reference refers to a child relationship object of a

particular child relationship class in the case of a 1 :1

or N : 1 relationship, and (d) a number of sets where

each set refers to a set of child relationship objects of a

particular child relationship class in the case of an 1: IV

or A4 : iV relationship.

Figure 6 shows a template for this representation. An

object of a child class together with the corresponding

object of its parent class portrays a snapshot (unique

state) of a real-world object. Each time a (temporal)

attribute value of a child object is modified, a new child

object version is created with the same state and be-

havior, except for the time value and the modified at-

tribute value. This new child object is inserted at the

beginning of the list of object versions referenced by the

parent object since the list is kept in descending order

of time values.

Example 3: In Figure 8 the employee real-world

concept is modeled as the Emp (parent) class and the

Emp-Version (child) class. The Emp (parent) class in-

cludes the non-temporal attributes ssn and name and

the Emp-Version (child) class includes the temporal

attribute salary. While the employee’s static (non-

temporal) attributes may be directly accessed through

the Employee class, its dynamic (temporal) attributes

may be reached by traversing the emp-versions list of

referencw from the Employee class to the Emp-Version

class.

s~eatment of tempor~ methods is beyond the scope of this

paper.

. . .Type-Methodl methodl;

. . .ref Parent_Entityl pel;

. . .list < ref CMdRel > child-versions;

end class Parent-Rel;

class ChildRel

Time time;

Type_TAttrl tattrl;

. . .list <ref Child-Entityl> eel;

. . .end Claas ChHdR.el;

Figure 7: A Template For Relationship Object Repre-

sent at ion

3.2.2 Relationship Object Representation

Relationships are represented as first class database ob-

jects in this approach. Each relationship is described

by a pair of (parent, child) classes. A new relationship

child object is created only when one of its attributes

is modified. If new versions of the participating entity

objects are created, no new version of the relationship

object is needed. Instead, we maintain a list structure

that refers to the child object entity versions that par-

ticipate in the relationship. For example, in Figure 8

we declare a list of type Emp_Version and Dept_Version

in the relationship class Works.For-Version.

Each parent relationship object will include (a) a

lifespan Time value, (b) the temporal attribute values

and methods of a relationship object, (c) a list of refer-

ences to its child relationship objects, and (d) a number

of references where each refers to a parent entity object

of a particular parent class.

Each child relationship object will include (a) a time

attribute value, (b) the non-temporal attribute values

of a relationship object, and (c) a number of lists where

each refers to child entity objects of a particular child

entity class (see Figure 7).

The rules that dictate the modeling of relation-

ships in temporal and non-temporal object-riented

databases are not only dissimilar, but also often contra-

dictory. In this representation (approach 2), temporal

relationships are represented at two levels (see Figure 8):

1. At the parent class level, all references are sets in

entity objects (Emp and Dept), and single refer-

ences in relationship objects (Managea, Works-For,

Belongs_To) regardless of the cardinality ratio of

579

class Emp class Emp.Version

Time lifespan; Time time;

string ssn; real salary;

string name; ref Manages-Version manages-version;

set < ref Manages > manages; ref Belongs-To-Version belongs.to_version;

set < ref Belongs_To > belongs.to; set < ref Works _J?or_Versio~ works-for-versions;

set < ref Workslor > works_for; end class Emp_Version;

listi ref Emp-Version > emp.versions;

met hod void give-raise(percent: real);

end class Emp;

I class Dept class Dept-Version ITime lifespan; Time time;

string dname; string dphone;

set< ref Manages > manager; ref Manages-Version manages-version;

set < ref Belongs_To > stafi set <ref Belongs -To_Version > belongs-to_versions;

set c ref Works ._For > workers; set <ref Works _For_Version > works_on-versions;

list < ref Dept-Version > dept-versions; end class Dept -Version;

end class Dent:

class Manages class Manages_Version

Time lifespan; Time time;

ref Emp emp; list < ref Emp-Version > emP_versions;

ref Dept dept; list < ref Dept _Version > dept-versions;

list < ref Manages_Versiom end class Manages.Version;

manages_versions;

end class Manages:

class Works-For class Works_For-Version

Time lifespan; Time time;

ref Emp emp; real hours;

ref Dept dept; list < ref Emp_Version > emp-versions;

list < ref Works-For_Version > list < ref Dept -Version> dept-versions;

works-for-versions; end class Works_For_Version;

end class Works_For;

class Belongs-To class Belongs-To-Version

Time lifespan; Time time;

ref Emp emp; list < ref Emp.Version > emp-versions;

ref Dept dept; list < ref Dept_Version > dept_versions;

list < ref Belongs_To-Version > end class Belongs_To_Version;

belongs_to_versions;

end class Belongs-To;

Figure 8: Object Versioning with Relationship Object

580

Object

A:

{+

: ei ei6employee

nA

Ii ““J;djs dj4 :

department n

mi. =(ei, d.) Imanages

Figure9: A Relationship Instance

the relationship (1 :1, 1: iV, IV :1, M : iV).

2. At the child class level, the references are in-

fluenced by the relationship cardinality. All

references in child entity objects (Emp-Version

and Dept_Version) depend on relationship cardi-

nality similar to non-temporal object references

(see Section 2.1); whereas all references are lists

in child relationship objects (Manages.Version,

Works-For-Version, Belongs-To-Version), regard-

less of cardinality.

Example 4: In Figure 1, the one-to-one non-

temporal relationship between Emp and Dept (i.e., a

single employee manages a department) is modeled by

the reference (link) attributes manages in the Emp class

and manager in the Dept class. However, in the tem-

poral example of Figure 8, the same one-t~one rela-

tionship is modeled as follows: (a) the manages in the

Emp (parent) class and manager in the Dept (parent)

class are sets because although an employee can manage

only one department at a time (1:1), he may manage

many departments during his life-span value, (b) the

ernp and dept are included as single references in the re-

lationship (parent) class Manages because they refer to

singIe participating entities, (c) the manages_ version in

the Emp_Version (child) class and manages-version in

the Dept_Version (child) class are single values, and (d)

the emp-versions and dept.versions in the relationship

(child) class Manages_Version maintain a list of depart-

ment and employee versions because although each re-

lates one employee to one department, several versions

may exist during the relationship lifespan.

3.2.3 Constraints

There are two restrictions that apply to the (parent,

child) database entity and relationship objects. They

are:

1. The union of the time values of the child objects (i.e.,

the snapshots) must be equal to the lifefipan value

of the parent object.

object.lif e-span = u~=~object+object-versions[i] .tirne

where maz is the number of object versions

2. The intersection of the time values of any two child

objects of the same parent object must be empty.

This ensures that each version covers a unique time

interval.

Vi, j,i#j, l<i<max, l<j<maz

object+object_versions[i] time n

object-+object-versions~] .t ime = 0

There are two restrictions that must hold between re-

lationships and entities to maintain inverse constraints.

They are:

1. The lifespan of a parent relationship object must be

contained within the intersection of the lifespans of

the participating parent entity objects.

parent-rel.li f e_span ~

fl&l’parentme/[i] -+parent_entity ./ifespan

where max is the number of participating

parent entity objects

2. The time value of a child relationship object must

be equal to the union of the time values for each of

its participating child entity version objects.

child.rel.time =

U~l’child_rel[~ -+child_entity.time

where max is the number of versions of

participating child entity objects

Example 5: Figure 9 illustrates the second restric-

tion that must hold between relationships and entities.

Suppose that object version mij represents the fact that

the employee ei manages department dj during [tl, t.).

Then, mjj keeps a list of emp-versions = ei7 + ei6 +

ei5 and dept-versions = dj4 + djs; and [t/, t.) =

(eiT.time Uejs.time U ei~.iime) = (dj4.time U dj3.time),

to cover all versions of ei and dj during the relationship

lifespan.

4 Analysis of Temporal Repre-

sentations

In this section we compare both temporal object-

oriented database models presented in section 3. In

section 4.1, we compare the complexity of the two rep-

resentations. In section 4.2, we analyze the storage cost.

581

4.1 Comparing the Temporal Represen-

tations

C; clsss i (i= 1,2)

n~ number of objects in Ci

al number of non-temDoral attributes of Cl

Below, we consider four criteria for comparing the two

represent ations. Following each criterion, we discuss the

advantages and disadvantages of each representation.

Criterion one: the number of additional

classes needed to model the specific temporal

model— The second approach suffers from the fact

that there is no one-to-one correspondence between

real-world concepts and classes, whereas the first ap-

proach follows closely the original non-temporal object–

oriented representation. In the object versioning ap-

proach, each class and relationship in a non-temporal

object-oriented database is mapped to a pair of (par-

ent, child) classes in the corresponding objectariented

database. Therefore, the total number of classes is equal

to 2 x #E + 2 x #R, where #E is the number of

entity classes in the non-temporal representation and

#R is the number of relationships. For example, the

non-temporal database in Figure 1 has two classes re-

lated to each other through three reference attributes,

whereaa its temporal representation in Figure 8 has ten

classes (2 x (#n = 2) + 2 x (#R = 3) = 10). In

the attribute versioning approach, each CISSS in a non-

temporal object-oriented database is mapped to a sin-

gle temporal class in the corresponding object-oriented

database, and relationships are modeled through refer-

ence (link or pointer) attributes. Therefore, no addi-

tional classes are created.

Criterion two: the number of database ob-

jects representing a real-world object— Each real-

world object is represented by one parent object and

many child objects in approach 2, in addition to many

parent and child relationship objects. In approach 1,

there is one-t~one correspondence between real-world

and database objects.

Criterion three: the granularity of the tem-

poral unit of information— The attribute version-

ing model permits temporal attributes of a class to have

different time granularities. For example, an employee’s

salary may need to change annually, and he may man-

age different departments each month (see Figure 5).

On the contrary, the object versioning model restricts

us to a single time granularity because a single time

attribute is associated with the whole object.

Criterion four: the number of additional

constraints int reduced to enforce the temporal

constraints— Both approaches introduce temporal in-

tegrity checks to enforce constraints on objects and be-

tween objects. Although the constraints look different,

they both support similar temporal rules.

tai I number of temporal attributes of C,

ari; number of reference attributes of Ci of tv~e Ri I

va, average number of versions for each taiVarij average number of versions for each ari~

R1 1:1 relationship between Cl : Cz

R, 1: N relationship between C* : C~

R; N :1 relationsh~p between C; : C;

& M : N relationship between Cl : Cz

nrl number of inst antes of each relationship of

type Rj (j = 1,2, 3,4)

ra j number of non-temporal attributes of R,s

traJ number of temporal attributes of R,s

vra, average number of versions for each traj

A average size of an attribute in bytes

P size of a Dointer in bvtes

T size of a time attribute in bytes

F average number of distinct objects from class Cl

(C$) than an object from class Cz (CI ) will be

related over its lifetime for each relationship

Figure 10: Cost Assumptions

4.2 Storage costs

In section 4.2.1 we outline the various assumptions made

in the cost model. Section 4.2.2 analyses the storage

cost. secticm 4.2.3 compares the storage costs through

simulation.

4.2.1 Assumptions

Figure 10 outlines the various assumptions made. To

estimate the storage costs, assume that we have two

classes Cl and C2, with nl objects in Cl and n2 objects

in C’2. For a 1 :1 relationship R1, the number of rela-

tionship instances is assumed to be nrl = min(nl, nz).

For a 1: N relationship R2 between C’l : C2, we assume

that nr2 = n2. For a N : 1 relationship ~3 between

Cl : Cz, we aasume that nrs = nl. Finally, for a M : N

relationship R4, assume that we have nr4 relationship

instances where nr4 << nl x n2. The numbers nl, nz,

nrl, nr2, nr3 and nr4 represent the number of non-

temporal instances of Cl, C2, RI, R2, R3 and R4 re-

spectively, and could be considered the average number

of these instances at a particular point in time.

For temporal entities, assume that each object in C~

(i = 1, 2) haa tai temporal attributes and ai non-

temporal attributes, and each temporal attribute has

vai versions on the average. Each reference attribute

arij of an object oi of type Rj (j = 1, 2, 3, 4) can also

change with time, so let varij be the average number of

versions for each arij. The versions varij may be cre-

ated aa a result of modifying reference (link) attributes

582

of entities. Each reference attribute can either be a sin-

gle reference (case of 1:1 and IV :1 relationships) or a

set of references (case of 1: IV and M : IV relationships).

Then, the total number of references ari in which ob-

ject Oi participates (at a particular time point) can be

written as (aril + ari2 + aris + ariQ), where aril, ari2,

ari3, and aria are the number of reference attributes

of each type of relationship (1 : 1, 1 : If, IV : 1, and

M : IV, respectively), We assume that each relation-

ship object in Rj (j = 1, 2, 3, 4) has i!raj temporal

attributes and raj non-temporal attributes, and each

temporal attribute has vraj versions on the average.

Let the size of each attribute be A bytes on average,

time attribute be T bytes, and address (link or pointer)

be P bytes. Assume that F1 (F’z) is the average number

of distinct objects from class C2 (C’l ) that an object

from class Cl (C2) will be related over its lifetime for

each relationship. For simplicity, we assume that Fi

(i= 1, 2) is the same for Rx, R2, R3 and R,, and that

F= FI=F2.

4.2.2 Storage Cost Anrdysis

Approach 1: Attribute Versioning without

Relationship Object

In this approach, each real world-object is repre-

sented by a complex database object. The storage SOi

occupied by each object oi of class Ci (i = 1, 2) is

equal to SAi + STAi + SA&, where SAi is the stor-

age occupied by its non-temporal attributes, STAi by

its temporal attributes and SA& by its reference at-

tributes. Each object oi has on average ai non-temporal

attributes, and therefore SAi is equal to ai x A. Each

object oi has on average tai temporal attributes that

are represented by a list of (ati!ribut e, time) pairs. If we

sssume that each temporal attribute has tiai versions,

then on average the storage occupied by each temporal

attribute list is equal to vai x (A + T), and therefore

STAi is equal to tai x Vai x (A+ T).

Temporal relationships are embedded in complex ob-

jects and are represented by lists of (relat ionship-type,

tirne.t~pe) pairs. At a particular point in time, a ref-

erence attribute arij points to ~ objects on average

(j = 1, 2, 3, 4; i = 1, 2), and therefore the stor-age SARLij occupied by the current element of a refer-

ence list is equal to T + (P+ (raj + traj) x A) X (~).

Since we assume that on average ~ch temporal relation-

ship attribute raj has traj versions and each reference

attribute arij has varij versions, then the total stor-

age SA&j occupied by a reference list arij is equal to

SARLij x (t)raj x traj) x Varij. Finally, if we sum over

the four types of relationships, the total storage SA@

occupied by all reference attributes of an object oi is

Z;=l (ari~ x SA% ). TO summarize, we have:

SAi = aix A

STAi = tai X Vai X (A+ T)

SARLij = (T+ (P+ (raj +traj) x A) x (~) )

SA&j = SARLij x (tiraj x traj ) x tiarij

SA& = ~ (arij X SA~j )

j=l

SOi = SAi + STAi + SA&

total-space = & (ni X SOi)

i= 1

Approach 2: Object Versioning with Relationship

Object

If we consider that all attributes and relationships

change asynchronously, then we will have, on the av-

erage, (t ai x t)ai + ari x Vari ) object versions for each

object. We use SPOi (i = 1, 2) for the average size of

a parent entity object, SCOi for child objects, and SOi

for total storage per entity object on average.

SPOi = T+(ai xA)+(ari xFx P)+( (tai xvai+ari xvari) xP)

SCOi=T+(tai xA)+&(arijx~x P)

j=l

SOi = SPOi + (SCOi X (tai X VCli + cl?’i X Va?’i) )

If we consider that all relationship temporal at-

tributes change asynchronously, then we will have, on

the average, (traj x Vraj ) (j = 1, 2, 3, 4) object child

versions for each relationship parent object. Below, we

use SPRj for the average size of a parent relationship

object, SCRj for child objects, and SRj for total stor-

age per relationship object on average.

SPRj = T + (raj x A)+ (2 X P)+ (traj X vraj X P)

SCRj = T+(traj xA)+~ (tai x ‘ai + ‘~ – 1) x ‘ari xP)

i=l

SRj = SPRj + (SCRj x traj X Vraj )

Finally, the total space, denoted by total-space, is

equal to the space occupied by database entities and

relationship objects.

2 4

total_space = ~ (ni x Soi)+z (nrj x SRj X arj X Varj )

i=l j=l

583

nl = 5000 C61=5 tal = 7 val =6

nz = 500 az=5 taz = 7 va2 = 6

arll = 1 arlz = 1 arls = 1 ar14 = 1

arzl = 1 arzz = 1 arzs = 1 arzq = 1

varll = 6 varlz =6 varls = 6 var14 = 6

var21 = 6 var22 = 6 avr23 = 6 var24 = 6

nrl = 500 ral = 1 tral = 1 vrfxl = 2

nrz = 500 raz = 1 traz = 1 vrq = 2

nrs = 5000 ras = O tra~ = O vras = O

nrA = 125000 rad = 1 traq = 1 vraq = 1

A=8 P=5 T=5 F=14

Figure 11: Simulation Parameters

Temporal Relational Approach

We include this approach for comparison purposes

only. In this approach each entity and relationship is

modeled by a relation. The entity tuple size STE is

equal to T+ (ai + i!ai) x A, and therefore each entity ob-

ject SOi requires (tai x vai ) x STE bytes. The relation-

ship tuple size STR is equal to T+2 x A+(raj +traj ) x A.

(The factor 2x A is for the foreign keys.) The total space

S& nee~d for the four types of relationships is equal to

(*) x Zj=l (nrj x (traj +vra~) x (arii x ‘ari~) x ‘TR)bytes. Therefore, the total amount of space needed is

equal tO ~~=1 (ni X SOi + S&).

4.3 Performance Comparisons

Using our sample database in which there are two

classes and four relationship types, we compared the

performance of the three approaches via simulation.

The typical parameters used are given in Figure 11.

During our simulation, we separately varied the number

of (a) temporal attributes, (b) temporal attribute ver-

sions, (c) reference attribute versions, and (d) temporal

relationship attributes, and we observed the following

results:

Graph 1: When the average number of temporal at-

tributes of an entity increases, the second approach de-

grades rapidly due to the increasing number of object

versions required to capture the modifications to the

temporal attributes. However, since the first’ approach

avoids replication of all other attributes of an entity

when one of its temporal attribute is modified, its stor-

age requirements grow less dramatically as the number

of temporal attributes increases.

Graph 2: We observed similar results to that of the

first graph. When the average number of versions for

each temporal attribute in the entities increases, the

storage requirements of the second approach increase

rapidly. This is due to the replication of all but one

of the temporal attributes (i.e., the one which is up-

dated) in the newly created object version. Because

the first approach avoids this redundancy when one of

entity temporal attributes is updated, its storage cost

grows slower than the first approach.

Graph 3: When the average number of versions of

each reference attribute increases, the first approach

also degrades. This is because in the first approach, the

relationship attributes are duplicated in both partici-

pating entity objects (for faster access considerations),

and also when a new reference version is created, all

relationship attributes are duplicated. The second ap-

proach avoids replicating relationship attributes by stor-

ing them as first class relationship objects.

Graph 4: When the number of temporal attributes

of the A4 : N relationship increases, the first approach

degrades at a faster rate than the second approach due

to the replication of relationship attributes in both en-

tities as described above. A solution to this problem is

to represent M : N relationships as first class objects in

the first approach.

The traditional relational approach always requires

more storage than approach 1 (attribute versioning),

and generally is comparable to approach 2 (object ver-

sioning). As can be seen, attribute versioning has the

lowest storage cost. We are currently analyzing the

costs of temporal queries and updates on the various

represent at ions.

5 Conclusions and Future Work

In this paper, we described and compared two differ-

ent approaches for representing time in object-oriented

databases. We defined temporal constraints that must

hold in each approach. We analyzed the storage costs of

the two approaches, and compared them with the tem-

poral relational storage costs. The results show that

attribute versioning requires less storage space, and in

general, object versioning requires comparable storage

to temporal relational representation.

We are currently analyzing and comparing the

query and update performance of the above approaches

[KoEF94]. We are also including other representations

from Figure 3 in our analysis. Our goal is to provide

guidelines for choosing the appropriate temporal object-

oriented representation for each application.

References

~eGe91] Bertino, E., and Martino, L. Object-orienteddatabase management systems: concepts and issues.In IEEE Computer, (1991).

[catt91] Cattell, R. Object data management, 2nd Edition.

Addison- Wesley, (13S1).

[Deux91] Deux, O., et al. The 02 system. In CA CM (October1991).

584

@EK90]

@lJK921

@Na93]

pm’vK90]

@lwuw]

[GaYe88]

[Jena8Q]

[JCGS92]

[JeSn91]

[KoEF94]

&aLa91]

&RV88]

[NaAh89]

piaa91]

[PiMa92]

~Se91]

[Snod87]

[WiJL91]

[WuDa92]

Ebnaari, R., E1-Asaal, I., and Kouramajian, V. Se--tics of temporal data in au extended ER model.In 9th Entity-Relationship Conference (1990).

Elmtuu-i, R., J aseenmddin, M., and Kouramajian, V.Partitioning of time index for optical diska. In IEEEData Engineering Conference, (1992).

Elmasri, R., and Navathe, S. llmdamen-tals of Database Systems, ‘Znd Edition. Ben-

@nin/Cwnmin##, (to be published in 1993).

Elmaari, R., Wuu, G., and Kim, Y. The time index:An access stmcture for temporal data. In VLDBConference, (1990).

Elrnaeri, R., and Wuu, G. A temporal model andquery language for ER databasea. In IEEE DataEngineering Con~erence, (1990).

Gadia, S., and Yeung, C. A generalized model fora temporal relational database. In ACM SIGMODConference (1988).

Jensen, C. Towards the realization of transactiontime database systems. Ph.D. Dissertation, Univer-sity o~ Maryland, (1990).

J~, C., Clifford, J., Gadia, S., Segev, A., andSnodgraaa, R. A glossary of temporal database con-cepts. In SIGMOD Record, 21(3), (1992).

Jensen, C., and SnodWass, R. Temporal specializa-tion and generalization. Technical Report, Univer-sity oj Arizona, (1991).

Kouramajian, V., Elmaari, R., and Fernando, S.Temporal object-oriented databaae modeling a per-fornumce perspective. In preparation, (1994).

Lamb, C., Landis, G., Orenstein, J., and Weinreb,D. The ObjectStore database system. In CA CM(1991).

IA-, C., Richard, P., and Velvez, F. 02, anobject-oriented data model. In ACM SIGMOD Con-ference (1988).

Navathe, S., and Abmed, R. A temporal data modeland query language. In Injownation Sciences (1989).

Pkwinou, N. T~e in object databaaes. Ph.D. Dis-sertation, University oj Southern California, (1991).

Piaainou, N., and Maldd, K. T-3DIS: An approach totemporal object databaaes. In International Confer-

ence on Information and Knowledge Management,(1992).

Rose, E., and Segev, A. TOODM - A temporal00 data model with temporal constraints. In f flth

Entity-Relationship Conference, (1991).

Snodgraaa, R. The temporal query languageTQUEL. In ACM TODS lE (2), (1987).

Wkderhold, G., Jajodia, S., and Lltwin, W. Dealingwith granularity of time in temporal databases. In.%d International Conference on Advanced Informa-

tion Systems Engineering (1991).

Wuu, G., and Dayal U. A uniform model for tempc-ral object-oriented databases. In IEEE Data Engi-neering Conference (1992).

Graph 1

04 I3 s 7 9 11

numb.r of WnpOrol .ffdbut..

bln both mdlll-)

Graph 2

.~,SVW%W -t+ df WOdOIU 10,-htemporal dfdbufo (I,I both .IW1..)

Graph 3

a$ —m

z 2m -—Iulaimd

.=.:g.

100-

%s:

2 4 6 8 10.“*W. “Umbu of v.”b”s of 08eh

r. f.mac. .ttrlbut. (in fwth ..01{.s)

Graph 4

0 2nu~b.< d tanp;,al ●ttrIbuta s

(of On f4:N “Iatlanshld

585