Temporal Entity-Relationship Models—A Surveypeople.cs.aau.dk/~csj/Papers/Files/1999_gregersenIEEETKDE.pdfAn ER diagram pro-vides a good overview of database design, and the model’s

464 IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING, VOL. 11, NO. 3, MAY/JUNE 1999

Temporal Entity-RelationshipModels—A Survey

Heidi Gregersen and Christian S. Jensen, Senior Member, IEEE

Abstract—The Entity-Relationship (ER) model, using varying notations and with some semantic variations, is enjoying aremarkable, and increasing, popularity in both the research community£the computer science curriculum£and in industry. In stepwith the increasing diffusion of relational platforms, ER modeling is growing in popularity. It has been widely recognized thattemporal aspects of database schemas are prevalent and difficult to model using the ER model. As a result, how to enable the ERmodel to properly capture time-varying information has, for a decade and a half, been an active area in the database-researchcommunity. This has led to the proposal of close to a dozen temporally enhanced ER models. This paper surveys all temporallyenhanced ER models known to the authors. It is the first paper to provide a comprehensive overview of temporal ER modeling andit, thus, meets a need for consolidating and providing easy access to the research in temporal ER modeling. In the presentation ofeach model, the paper examines how the time-varying information is captured in the model and presents the new concepts andmodeling constructs of the model. A total of 19 different design properties for temporally enhanced ER models are defined, and eachmodel is characterized according the these properties.

Index Terms—Conceptual modeling, Entity-Relationship models, database design, temporal databases, temporal data models,design criteria for temporal ER models, time semantics.

——————————�F�——————————

1 INTRODUCTION

HE Entity-Relationship (ER) model [2], in its differentversions, with varying syntax and with some semantic

variations, is enjoying a remarkable, and increasing, popu-larity in both the research community and in industry. Themodel is easy to comprehend and use. An ER diagram pro-vides a good overview of database design, and the model’sfocus on the structural aspects of database schemas,as opposed to their behavioral aspects, also appears tomatch the levels of ambition for documentation adoptedby many users.

The ER model may be used for different but related pur-poses, namely for analysis—i.e., for modeling a mini-world—and for design—i.e., for describing the databaseschema of a computer system. As a third alternative, the ERmodel may be supported directly by a DBMS. In that case,it may be used as an implementation model. However, al-though graphical and textual ER query languages havebeen proposed by the research community, the ER model israrely used as an implementation model. Rather, the typicaluse seems to be one where the model is used primarily fordesign, with the design diagrams also serving as analysisdiagrams, and where the constructed diagrams are mappedto a relational platform. In step with the increasing diffu-sion of relational platforms in industry, ER modeling isgrowing in popularity.

The use of ER modeling is supported by a wealth oftextbook material. For example, most introductory database

textbooks (e.g., [10], [27], [3],) contain chapters on ER mod-eling, and several complete books exist (e.g., [1], [34]) thatare devoted entirely to ER modeling.

Companies either develop their own ER diagrams fromscratch, or they purchase and modify generic, standarddiagrams.1 Indeed, generic diagrams for a variety of typesof applications are commercially available, e.g., the FSDMfrom IBM.

Some companies build ER diagrams using only simpledrawing tools. Other companies use one of the many com-mercially available tools that are more sophisticated andbetter support the building of diagrams and also map dia-grams to implementation platforms. Such tools are eitherstand-alone, e.g., SmartER from Knowledge Based Systems,Inc., and ER/1 from Embarcadero Technologies, or are inte-grated parts of larger CASE tools, e.g., Teamwork/IM SQLfrom Cayenne Software, Inc., and Visible Analyst Work-bench from Visible Systems Corporation. Typical imple-mentation platforms include those provided by major SQL-based database systems.

In the research community, as well as in industry, it hasbeen recognized that temporal aspects of database schemasare both prominent and difficult to capture using the ERmodel. Put simply, when modeling fully the temporal as-pects, the temporal aspects tend to obscure and clutter oth-erwise intuitive and easy-to-comprehend diagrams. As aresult, some industrial users simply choose to ignore alltemporal aspects in their ER diagrams and supplement thediagrams with phrases such as “full temporal support.”The result is that the mapping of ER diagrams to relational

1. In industry, ER diagrams are typically termed ER models. This is incontrast to common usage in the research community and the usage in thispaper, where a data model is a modeling notation and a diagram is a de-scription using some notation.

1041-4347 / 99$10.00 © 1999 IEEE

²²²²²²²²²²²²²²²²

�� H. Gregersen and C.S. Jensen are with the Department of ComputerScience, Aalborg University, Fredrik Bajers Vej 7E, DK–9220 Aalborg Ø,Denmark. E-mail: {gregori, csj}@cs.auc.dk.

Manuscript received 1 Oct. 1996; revised 25 Mar. 1998.For information on obtaining reprints of this article, please send e-mailto: [email protected], and reference IEEECS Log Number 104373.

T

©1999 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or

redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE."

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this

information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder.

GREGERSEN AND JENSEN: TEMPORAL ENTITY-RELATIONSHIP MODELS—A SURVEY 465

tables must be performed by hand; and the ER diagrams donot document well the temporally extended relational da-tabase schemas used by the application programmers.

The research community’s response has been to developtemporally enhanced ER models, and 10 such models havebeen reported in the research literature. Their informativenames include the Temporal Enhanced Entity Relationshipmodel [12], [11], the Temporal Entity Relationship model[33], and the Relationship, Attribute, Keys, and Entitiesmodel [13], to name but a few.

Two general, orthogonal temporal aspects have receivedwidespread attention, namely valid time and transaction time[16]. The valid time of a database fact is the time when thefact is true in the miniworld. (We use the term “mini-world” for the part of reality that the database under con-sideration stores information about.) Thus, all databasefacts have an associated valid time. Different time typesmay be used when modeling the valid-time aspect, e.g.,single time instants, intervals, or sets of intervals.

Perhaps more importantly, the valid time may or maynot be captured explicitly in the database—this is the choiceof the database designer. In ER models, unlike in the rela-tional model, a database is not structured as a collection offacts, but rather as a set of entities and relationships withattributes. Thus, the valid times are associated only indi-rectly with facts. As an example, consider an Employee en-tity “E1” with a Department attribute. A valid time of June1996 associated with value “Shipping” does not say that“Shipping” is valid during June 1996, but rather that thefact “E1 is in Shipping” is valid during June 1996. Thus,when valid time is captured for an attribute such as Depart-ment, the database will record the varying Department val-ues for the Employee entities. If it is not captured, the data-base will record only one department value for each Em-ployee entity.

Orthogonal to valid time, the transaction time of a data-base fact is the time when the fact is current in the databaseand may be retrieved. Unlike valid time, transaction timemay be associated with any structure stored in a database,not only with facts. Still, all structures stored in a databasehave a transaction-time aspect. And again, this aspect mayor may not, at the designers discretion, be captured in thedatabase. The transaction-time aspect has a duration: frominsertion to (logical) deletion.

In addition to valid and transaction time, a data modelmay support arbitrary time attributes with no built-in se-mantics in the data model. For employee entities, such at-tributes could record birth dates, hiring dates, etc. A datamodel that supports such time attributes is said to supportuser-defined time.

In summary, facts stored in a database have a valid timeand a transaction time, although those times may not beexplicitly recorded [16]. We say that a data model supports atemporal aspect, i.e., valid or transaction time, if it providesbuilt-in means for indicating where in an ER diagram thisaspect should be captured.

The temporal ER models attempt to more naturally andelegantly model the temporal aspects, such as valid andtransaction time, of information by changing the semantics

of the ER model or by adding new constructs to the model.The models take quite different approaches to adding built-in temporal support to the ER model.

This paper is the first to survey all known (to theauthors!) temporal ER models. In addition, the paper pro-vides a comprehensive list of possible properties of tempo-ral ER models, and it characterizes the models according tothose properties. With nine models having been proposedover the past 15 years, such a survey is in order. It consoli-dates in a single and easy-to-access source the central ideas,concepts, and insights achieved in temporal ER modeling.The survey makes it easier for future research and devel-opment to maximally build on, benefit from, and extendpast results. Thus, the survey is aimed at researchers andpractitioners interested in temporal data modeling and datamodel design.

Four studies are somewhat related to or complement thestudy reported here:

1)�Theodoulidis and Loucopoulos [36] describe andcompare nine approaches to specify and use time inconceptual modeling, here viewed as both semanticdata modeling and requirement specification, of in-formation systems. Their study includes only two ofthe ER models surveyed here. The comparison of themodels fall in three parts and classifies the models interms of time semantics, model semantics, and tem-poral functionalities. Our criteria also characterize themodels in terms of user-friendliness. The primary fo-cus of their paper is the examination of the ontologyand properties of time in the context of informationsystems, whereas our focus is the examination of howthe extensions of the ER model into temporal ERmodels are shaped.

2)�McKenzie and Snodgrass [23] survey and evaluatetwelve different temporal extensions of the relationalalgebra. They evaluate the algebras against 26 designcriteria. These criteria are mainly concerned with theproperties of the data objects—temporal relations andtheir components—that the algebras manipulate andwith the properties of the algebraic operators them-selves. While their survey concerns internal algebras,our survey concerns notations for conceptual model-ing. In addition, our focus is on the properties of thestructural aspects of the temporal ER models.

3)�Without coauthors, Snodgrass has also conducted acritical comparison of temporal object-oriented datamodels [30]. While ER models do incorporate somestructural object-oriented features, our study does notconsider object-oriented models; for that, we insteadrefer the reader to Snodgrass’ study. Also unlike ourstudy that emphasizes structural aspects, Snodgrass’study focused on the models’ query languages, i.e., onbehavioral aspects.

4)�Roddick and Patrick [26] survey the progress of in-corporating time in various data models at the con-ceptual and, primarily, logical level of database mod-eling, and in artificial intelligence. The work describes


nine different properties of temporal modeling sys-tems, but unlike our survey they do not evaluate themodels against the properties described. Their broadstudy briefly covers two of the temporal ER models inour study.

The descriptions in the literature of the different modelsuse diverse and, at times, incompatible and conflicting ter-minology. In this survey, we adopt the coherent terminol-ogy of the temporal database glossary [16] when possible.In addition, the original definitions of the models are ofteninformal and rely on the reader’s intuition. In part also toachieve a homogeneous survey of a manageable size, wewill give informal descriptions of some aspects. Further, wewill emphasize the common core of features of the temporalER models: the use of ER modeling to capture the structuralaspects of a database schema. We will not cover behavioralaspects such as query and rule languages in detail.

The paper is structured as follows: Section 2 providesan overview of all temporal ER models known to theauthors. Section 3 then identifies a set of 19 evaluationcriteria and evaluates each model according to these crite-ria. Finally, in Section 4, a conclusion and a discussion offuture work is given.

2 EXISTING MODELS

This section describes each existing ER model separatelyand in turn. Initially, an overview is provided that explainsthe structuring of the descriptions and introduces a runningexample that will be used for exemplification throughout.

2.1 OverviewThis section describes all the temporal ER models that weare aware of. We will assume that the reader is familiar withChen’s standard ER model [2] and the various extensions ofthat model, e.g., subtyping (see, e.g., [10]).

The models are presented in chronological order of theirfirst publication. The description of the models all have,with a few exceptions, the same basic layout. First, a shortintroduction of the model is given. Second, we describehow the model captures time. Third, we give an examplediagram built using the model’s notation. For each model,the sample diagram models the same miniworld, to be de-scribed shortly. In order to keep the diagrams simple andstill be able to reach into the corners of the different mod-els, we deviate in some places slightly from the descrip-tion below. This way, it is possible to more concisely pres-ent the special features of the models. When we do devi-ate, we will state this explicitly. Finally, a short summaryof the model is given.

Mappings of ER diagrams to implementation platformsfor the models will only be explained if they are describedin the papers and differ substantially from the typical map-pings from the EER model to relational platforms.

The miniworld that we describe next concerns a com-pany divided into different departments. Each departmenthas a number and a name and is in charge of a number ofprojects. A department keeps track of the profits it makeson its projects. Because the company would like to be able

to make statistics on its profits, each department must rec-ord the history of its profits.

Each project has a manager and some employees work-ing on the project. Each project has an ID, and a budget.Each project is associated with a department which is re-sponsible for the project. Employees belong to a single de-partment. Once an employee is assigned to a department,the employee works for this department for as long as theemployee is with the company. For each employee, thecompany registers the ID, the name, the date of birth, andthe salary. The departments would like to keep records ofthe different employees’ salary histories.

Employees work on one project at the time, but employ-ees may be reassigned to other projects, e.g., due to the factthat a project may require employees with special skills.Therefore, it is important to keep track of who works forwhat project at a given time and what time they are sup-posed to finish working on their current project.

Some of the employees are project managers. Once amanager is assigned to a project, the manager will managethe project until it is completed or otherwise terminated.Fig. 1 presents the ER diagram describing the database de-sign corresponding to this miniworld.

Fig. 2 provides an overview of the surveyed models,along with their main citations, the models on which theyare based, and the identifiers we will be using in the restof the paper.

It is important that the presentation (and definition!) of amodel is precise and complete. The descriptions of the sur-veyed models range from very formal and detailed tovague and abstract.

The models we have found to be described the best areTERM and TERC+, which in [18], [39] are described in greatdetail. models MOTAR, ERT, and TER are presented in arti-cles dedicated to this single purpose, but their descriptionsare not as detailed and comprehensive as that of TERM.models RAKE, TEER, and STEER are also presented in arti-cles only concerning the presentation of the models, buttheir descriptions are less comprehensive. The descrip-tion of TempEER is somewhat incomplete. For example,the description of the mapping algorithm supposed totranslate TEER diagrams to relational schemas does notcover time-varying aspects. The description of TempRTis also incomplete, primarily because this model is notyet fully developed.

2.2 The Temporal Entity-Relationship ModelTERM, the Temporal Entity-Relationship model, was thefirst temporally extended ER model to be proposed [18],[19]. The main motivation for TERM was “to provide data-base designers with a model for data definition and datamanipulation that allows a general and rigorous treatmentof time” [18]. To accomplish this, TERM most notably in-troduces the notion of a history, which is a function from atime domain to some value domain. Histories are then usedfor the modeling of time-varying aspects. For example, the(time-varying) value of an attribute of an entity becomes ahistory, rather than a simple value.

Unlike all the other temporal ER models, TERM does nothave a graphical syntax, but has a Pascal-like syntax.


2.2.1 The Representation of TimeIn its outset, TERM makes a strict distinction between areal-world phenomenon and its ER-model representation.For example, TERM distinguishes between “time” and therepresentation of time—there is one “time,” but many pos-sible representations of time. This distinction extends to theother modeling constructs, e.g., values and histories. Wefocus on the representations.

Domains are termed structures. A time domain is thus atime structure. With TERM, the designer may define timestructures, but TERM also includes a predefined timestructure of Gregorian dates. These dates are equipped witha variety of predicates, termed structure relations, e.g., “be-fore_date” and “is_in_leap” (is the argument date in a leapyear?), and operators, e.g., “next-day” and “least-recent.”Fig. 3 illustrates two value structures, one for employeenames and one for generic identifiers. It also provides a(partial) time structure, termed “date,” with one relation.

A history is a mapping h : T � V where T is a timestructure and V is a value structure. Histories are used forcapturing the variability of time-varying aspects, as weshall see in the next section. Attributes of entities and rolesof relationships have atomic histories while, e.g., entireentities have composite histories, i.e., histories composed ofatomic and composite entities. All composite histories aresets of histories: An entity (relationship) history consistsof an existence history and the set of all its attribute(role) histories.

The (atomic) history h is represented by the history struc-ture 2T�V, i.e., by a set of (time, value) pairs. To achieve afinite history structure in situations were time structureT represents continuous time, it is possible to introduceas part of the history structure a derivation function thatuses the stored (time, value) pairs to compute values foradditional times.

Fig. 1. ER diagram describing the running example.

Fig. 2. Short presentation of the surveyed models.


Fig. 4 exemplifies histories. First, a generic existencehistory for entities and relationships is defined as a historystructure with two variables t and v and a somewhat com-plex condition. The domain of the variable t is date, and thedomain of the variable v is Boolean/Kleenean. This domainconsists of the values false, true, and unknown. The conditioninvolving the three universally quantified variables “s1,”“s2,” and “s” disallows holes in existence histories. To theright, a salary history, sal_history, is defined that uses astep-wise constant derivation function, deriv_sal(least_recent_date, when applied to a pair of a set of datesand a date “z,” returns the largest date in the set that is notlarger than “z”).

All data items within a database will not change at thesame time. Moreover, for some database items, only thecurrent value is of interest, whereas for others, only somevalues in the past may be known, while still other itemsrequire a history of the entire past. For these reasons, histo-ries are applied to individual database items instead of tothe database as a whole.

2.2.2 The Model ComponentsThe next step is to consider the association of histories withtime-varying database items.

The basic modeling constructs of TERM are those ofthe ER model. Entities model the interesting objects fromthe miniworld; values model the properties of the mini-world objects. The values are associated with the entitiesvia attributes.

If an attribute has no history, that is, if the value of anattribute never changes once it is assigned, it is referredto as a constant attribute; otherwise it is variable. Con-stant attributes are represented by a (attribute, value)pair, and variable attributes are represented by a (attrib-ute, history) pair.

Entity types are declared by a name and a set of(constant and variable) attributes. The attribute namedexistence is mandatory and describes the existence ofthe entity type. If the existence attribute is specifiedas constant, the attribute has Boolean/Kleenean as its do-main. A variable existence attribute has an associatedBoolean/Kleenean-valued history.

Two or more entities can enter into a relationship in whicheach entity plays a role. Like attributes of entity types, rolesof relationship types are represented by values, now entityreferences, or by histories, now entity-reference valued.

Relationship types are declared by a name, an existencedescription, a set of roles, and a set of attributes. Binaryrelations may be declared to express participation con-straints such as 1:1, 1:N, and N:1, where the constraints areenforced for each database state in isolation. Writing a oneafter the role name restricts participation to at most one (ata time). By placing a total after a role name, total participa-tion is indicated.

A TERM schema consists of a set of entity type defini-tions and a set of relationship type definitions. Fig. 5 showsthe two entity types, Project and Employee, and the rela-tionship type, Works_for, between them.

Fig. 3. Sample value and time structures.

Fig. 4. TERM history definitions [19].


A general bottom-up procedure for designing TERMschemas has been provided. There are four steps. The firststep is to define all nonstandard component value sets.Fig. 3 exemplifies this step. As illustrated by the datestructure, it is possible to express constraints on the valuesof the value sets. A so-called relation is also shown thatdetermines whether or not a given date is in a leap year.The next step is to define histories. As illustrated, in part,by Fig. 4, histories have a name, a time structure, a valuestructure, an optional list of predicates for restricting theset of pairs forming a history, a list of relations, and a listof operations. The third step is to define patterns. A pat-tern is a value structure together with at least one asser-tion, at most one derivation function, and zero or more ap-proximation functions, or it is a history structure togetherwith at most one derivation function and zero or more ap-proximation functions. The sal_history shown at Fig. 4 is anexample of the latter. The final step is to define entity andrelationship types. These consist of a name and a list ofcomponents. The components are specified as either exis-tence, attributes, or roles. Fig. 5 give an example of thisstep.

2.2.3 SummaryTERM was the first temporal ER model and has a Pascal-like syntax. It allows database designers to model tempo-ral aspects through the use of history structures as valuesof attributes and relationship-type roles. In addition, his-tories are employed to model the existence of entities andrelationships.

2.3 The Relationships, Attributes, Keys, and EntitiesModel

The Relationships, Attributes, Keys, and Entities (RAKE)model [13] was developed in 1984 as part of a project at theU.S. Federal Reserve Board. One of the tasks in the projectwas to design a database to “store data on the history, at-tributes, and interrelationships of American and foreignfinancial institutions,” and the model was developed toprovide better support for this work than the ER model.

RAKE fundamentally adopts the ER model, but re-places some of the ER model’s modeling constructs withnew ones and adds entirely new constructs. Most promi-nently, RAKE introduces so-called key fields in diagrams:Key attributes of entity types are places in “key boxes” in

the upper-left corners of the entity-type rectangles. Thisexplicit representation of the entity-keys was unexpectedlyfound to also be useful when modeling time-varying data,to record multiple states of entities and relationships inthe same application.

All new constructs are defined in terms of their mappingto relational tables and in terms of existing ER constructs.Following a discussion of the representation of the timedomain in RAKE, we consider in turn the modeling of time-varying relationships and attributes.

2.3.1 The Representation of TimeThe time type used in RAKE corresponds to the type '$7((or 7,0(67$03) supported by, e.g., various SQL imple-mentations of relational DBMSs. This type is used for mod-eling of valid time and user-defined time, but it could alsobe used to capture transaction time.

It is noted that the history of entities and relationshipsconsists of series of states succeeding one another in time.The series are punctuated by events that transform onestate into another. The states have duration while the eventsdo not. The valid times of states are thus modeled using apair of time attributes, BEGINstamp and ENDstamp, andthe valid times of events are modeled using an attributeTstamp. Next, we shall see how these time attributes areused in RAKE diagrams.

2.3.2 The Model ComponentsAs usual, entity types are represented by rectangles. Theprimary key of an entity type is placed, in a so-called key-box, in the upper-left corner of its rectangle. Weak entitytypes are also represented by rectangles. For these, the par-tial key is placed in the keybox, and the primary keys of theidentifying relationships are stacked on top of the keybox.

Nonprimary-key attributes of entity types are represent-ed by circles that, as usual, are linked to the entity types. Ifan attribute circle is enclosed by a square (also a rectan-gle), this means that the attribute may be treated as anentity type. As in the ER model, relationship types are rep-resented by diamonds. As for attributes, if a relationship-type diamond is enclosed by a rectangle, this implies thatthe relationship type may also be treated as an entity type.

In nontemporal databases, only the current, or last-known, state of entities and relationships are stored. When

Fig. 5. Sample TERM entity and relationship types.


recording multiple states, entities, and relationships areidentified differently. Entities are identified by nonreusableidentifiers (e.g., serial numbers). In contrast, RAKE distin-guishes between different relationships—that are instancesof the same relationship type—solely by their timestamps.Below, we delve into these and other temporal aspects.

Modeling Time-Varying Relationships. When changing abinary relationship type where only a single state is re-corded, to record multiple states, the relationship type turnsternary. To see this, consider Fig. 1. The Responsible_forrelationship type consists of a set of pairs of Departmentand Project entities, with the entities being representedby their primary-key values. In contrast, because wewant to record project assignments for different times, itis necessary for Works_for to be ternary: Only with athird work_period entity is it possible to representproject assignments of the same employee to the sameproject, at different times.

Thus, the ternary relationship type in Fig. 6a is the cor-rect way to represent a temporal relationship between twoentities in RAKE. To avoid cluttering the diagrams withtime-period rectangles, RAKE eliminates this notation andinstead introduces the semantically equivalent notation inFig. 6b. In this way, RAKE represents temporal relation-ship types as weak entity types owned by a time-periodentity type that is not explicitly represented in the dia-grams (pp. 282–283 in [13]). Together with the primarykeys of the other entity types participating in the relation-ship type, the ENDstamp, which is part of the key of the

owner entity type, is sufficient to uniquely identify in-stances of the relationship type. The BEGINstamp, also apart of the owner entity type, is therefore simply treatedas an ordinary attribute.

Modeling Time-Varying Attributes. The use of a circle forrepresenting an attribute may be seen as a shorthand for arelationship between a set of entities and a domain of at-tribute values. With this view, the domain of attribute val-ues becomes an entity type, and the technique for modelingtemporal relationship types may be used for modelingtemporal attributes as well. Fig. 7a illustrates this corre-spondence. When applying the transformation techniquefrom relationship types, we arrive at Fig. 7b. Again, byhaving made the entity attribute relationship explicit, therelationship is treated as a weak entity with an implicit timeperiod as owner. This, in turn, is abbreviated to Fig. 7c,where the BEGINstamp attribute is made implicit. This ishow RAKE models temporal attributes. Although theBEGINstamp attribute is implicit in diagrams, the attributeis not eliminated, but is assumed to be implicitly present.The BEGINstamp thus reappears when diagrams aremapped to relational schemas.

Next, observe that the approach here is to use attribute-value timestamping. Each attribute is treated in isolation.RAKE also has special provisions for timestamping sets ofattributes of an entity type. Assume that the Salary andAddress of Employee are both temporal and that we wantto timestamp them together. Fig. 8 illustrates how this isaccomplished. Fig. 8b illustrates the new construct, and

Fig. 6. The representation of time-varying relationship types in RAKE.

(a) (b) (c)

Fig. 7. Modeling time-varying atributes in RAKE.


Fig. 8a shows the equivalent old construct. When mappingthe two diagrams to a relational database schema, Fig. 8awould be mapped to two relation schemas, while Fig. 8bwould only be mapped to a single table. These databaseschemas have different advantages. Indeed, this is the ra-tionale for permitting both modeling constructs.

Finally, it is also possible to timestamp attributes andrelationships with time points, to model temporal events.This is done simply be using an attribute Tstamp in placeof ENDstamp and omitting BEGINstamp from temporalrelationships.

2.3.3 SummaryRAKE retains most of the constructs of the ER model, withtheir usual semantics, but modifies the handling of primarykeys by introducing special keyboxes on entity types andweak entity types. RAKE also introduces special constructsfor modeling temporal relationship and attribute types.These are modeled as weak entity types owned by implicittime-period entity types. The new constructs of RAKE aredefined in terms of their mapping to the relational modeland of existing ER constructs.

2.4 The Model for Objects with Temporal Attributesand Relationships

The motivation for the development of the model for Objectswith Temporal Attributes and Relationships (MOTAR) [24]was to integrate database research in areas such as object-oriented databases, knowledge-based systems, and tempo-ral databases. MOTAR database schemas, termed DataModel Diagrams (DMDs), are graphical and extend the ERmodel with temporal relationships and attributes, and withrules. A tool for building DMDs is provided, as is a map-ping of DMDs to relation schemas.

2.4.1 The Representation of TimeMOTAR provides built-in features for describing the tem-poral aspects of a database application, both at the concep-tual and the logical level.

MOTAR concentrates on the modeling of the valid-time aspect of data. If the application at hand requirestransaction-time support in the database, the approach isto simply add time columns (a single column, registration

time, is suggested) to the appropriate relational schemasthat result from mapping the DMD to the implementa-tion schema.

At the conceptual level, explicit notation is added todescribe the temporal aspects of a miniworld and data-base design. With this notation, valid-time timestampsbecome implicit.

The meaning of the new modeling constructs followsfrom their mapping to logical-level relational schemas. Forevery temporal aspect described at the conceptual level,corresponding timestamp attributes are added to the rela-tional tables by the mapping algorithm. At the logical level,valid-time is modeled using SQL '$7( columns; detailswill be given when the temporal constructs are discussed inthe following.

2.4.2 The Model ComponentsMOTAR includes four kinds of data types:

1)� regular entity types,2)� relationship types (nonprocedural relationship types),3)�attribute types, and4)� rules (procedural relationship types).

The model provides separate notations for temporal attrib-ute types and temporal relationship types. When describingthese constructs in the following, we will use the DMD inFig. 9 for exemplification.

Entity and Relationship Types. Entity types are repre-sented by circles and may be primitive or composite. Com-posite entity types are built from primitive and compositeentity types. In Fig. 9, Employee is a primitive entity type.Entity type Department is, as we shall see next, related toProject by means of a Component-Composite relationship.Department entities thus contain Project entities, and De-partment is a composite entity type.

MOTAR proposes a wider definition of relationshiptypes than do the usual ER models. This more general no-tion of relationship is introduced to make MOTAR generalenough to support a wider variety of applications.

MOTAR relationship types are procedural (rules) ornonprocedural. Briefly, the former operate on attribute val-ues of entities or relationships, and they produce results

Fig. 8. Modeling time-varying attributes together in RAKE.


that may update the attribute values of the same entity orrelationship, or the attribute values of other sets of entitiesor relationships.

There are three kinds of nonprocedural relationshiptypes, each of which is illustrated in Fig. 9 and ex-plained next.

�� Superclass-Subclass (SS) Relationship Types. Theseare represented by linking two entity types with adashed line, with an arrow pointing from the super-class to the subclass. In SS relationship types, the in-stances of the subclass are of the same type as the in-stances of the superclass, but additional informationis needed for instances of the subclass. In the figure,Manager is a subclass of Employee.

Inheritance of attributes is supported. Thus in-stances of the subclass has the same attributes as in-stances of the superclass, in addition to the attributesspecified for the subclass. This inheritance is built intothe mapping of SS relationship types to relational ta-bles. For example, the Employee-Manager relation-ship generates the following table.

EMP_SUBCLASS_MGR(EMP_ID, MGR_ID)

Each tuple in this table links information about amanager, in a Manager table, with information, storedin an Employee table, about the manager. Joining thistable with an Employee table on EMP_ID and thenwith a Manager table on MGR_ID will retrieve all theattributes of a manager.

�� Component-Composite (CC) Relationship Types. Theseare represented by linking two entity types with asolid line, with an arrow pointing from the compositeto the component.

The notation allows for specifying different con-straints. Components being optional is indicated byusing a double, solid line for linking the componentand the composite. If the composite entities may

contain multiple occurrences of the component entitytype, the line linking the entity types is given a smallcircle at the component end. This is exemplified inFig. 9 by letting Project be a component of Depart-ment (this is a deviation from the running example).The CC relationship type between Department andProject results in the following relational table beinggenerated.

DEP_COMPONENT_PROJ(DEP_NUM, PROJ_ID)

If the composite only contains at most one occurrenceof the component, the key of the above relational tablewill be reduced to the composite identifier only.Whether the component object is optional or not doesnot matter to the mapping algorithm.

�� General Relationship (GR) Types. These are relation-ships between entity types that are neither of typeSS nor type CC. They are represented by linking theinvolved entity types to a diamond with solid lines.N-ary GR types are allowed.

Each entity type that participates in a GR type hasa cardinality ratio that can be either 1 or N. A cardi-nality ratio of 1 is represented by linking the entitytype to the diamond with a solid line, as mentionedbefore. A cardinality ratio of N is represented using asolid line ending with a small circle at the diamondside. The meanings of the cardinality radios are asusual. The DMD in the figure indicates that a depart-ment may have more than one employee, but that oneemployee belongs to at most one department. Themeaning of cardinality ratios for time-varying GRs isnot given.

All GR types have one reference entity type thatindicates to which entity type the attributes of the GRtype refer. The reference entity type is determinedfrom the semantics of the GR type. Fig. 9 exemplifiesthis: because hours/week is meant to describe howmany hours per week an employee is working on a

Fig. 9. Describing the running example using MOTAR.


project, Employee is the reference entity type of therelationship type Works_for. A reference entity type ofrelationship is indicated with a small line perpen-dicular to the line connecting the entity type to thediamond; see the figure.

Using special time-varying GR types, it is possibleto describe relations that vary over time, such as proj-ect assignments of employees and marriages. Time-varying GRs are represented by double diamonds. InFig. 9, the relationship type Works_for is time vary-ing, stating that employees may be reassigned toother projects. The meaning of time-varying GRs isrevealed by their mapping to relational tables inwhich '$7( type attributes Start_date and End_dateare introduced. Specifically, the Works_for relation-ship type will be mapped to the following two tables.

REL_WORKS_FOR(EMP_ID, PROJ_ID)

WORKS_FOR(EMP_ID, PROJ_ID,EMP_Hours/week, EMP_Start_date,EMP_End_date)

From the second table, it can be seen that employeesmay only work for the same project once because thekey of the relation WORKS_FOR only consists ofEMP_ID and PROJ_ID. Almost all the attribute namesare prefixed with EMP because Employee is the refer-ence entity type of Works_for.

Attributes. There are four types of attributes in the model.They are initially divided into identifiers and simple attrib-utes; and simple attributes are either regular, aperiodic, orperiodic. Identifiers are represented by rectangles and areconsidered time-invariant. For example, ID is the identifierof, e.g., the entity type Project. Regular attributes do notchange over time and are thus nontemporal. They are rep-resented by squares. For example, as departments’ namesare not expected to change, Name of Department in Fig. 9 ismodeled as a simple, regular attribute.

Aperiodic attributes are expected to change over time, atirregular intervals. A double square without a letter insiderepresents an aperiodic attribute. Attribute Salary of Em-ployee is an example of an aperiodic attribute; it is mappedto the following table.

EMP_Salary(EMP_ID, Salary_date, Salary)

This mapping, with only one time attribute, results in sev-eral interpretations of the meaning of aperiodic attributes.For example, aperiodic attributes may be assumed to bestep-wise constant. For example, the value of a salary re-mains constant between updates. The Salary_date value ofa tuple then indicates when the tuple’s Salary value takeseffect. Another interpretation is that aperiodic attributes areassumed to be discrete. For the Salary attribute, this meansthat a tuple’s Salary value is valid only at the time indicatedby the value of its Salary_date attribute. The intendedmeaning is not clear from the description of the model.

Periodic attributes are expected to change over timewithin specific intervals, e.g., monthly or weekly. A doublesquare with a letter inside represents a periodic attribute.

The letter indicates the intervals with which the attribute ismonitored. Two periodic attributes, Profits, are used forrecording departments’ profits. One is sampled monthly,and the other is sampled annually. Rule-1 computes theannual profits, taking the monthly profits as input. Entitytype Department is mapped to the following tables.

DEP(DEP_NUM, Name)DEP_Annual_Profit(DEP_NUM, Profit_Year,Annual_Profit)

DEP_Monthly_Profit(DEP_NUM, Profit_Month, Profit_Year,Monthly_Profit)

From this it can be seen that it is possible to specify agranularity for periodic attributes.

Rules. The notion of rules as known from knowledge-basedsystems is used for the modeling of procedural relation-ships. Narasimhalu [24] provides argumentation for whyrules are thought of as data in MOTAR. Rules are repre-sented using an arrow head that points from the conditionof the rule to its conclusion. In Fig. 9, Rule-1 exemplifiesthis; for further details, see [24].

2.4.3 SummaryMOTAR provides the database designer with new model-ing constructs for describing time-varying attributes, bothperiodic and aperiodic, and for describing time-varyingrelationships. These constructs “hide” the time attributesthat would otherwise be necessary.

2.5 The Temporal EER ModelThe motivation for developing the Temporal EER (TEER)model [12], [11] was that its authors believe that it would bemore natural to specify temporal data and temporal queriesin a conceptual, entity-oriented model than in a tuple-oriented relational data model. TEER does not add newsyntactical constructs to the EER model; instead, it givesnew meaning to the existing EER modeling constructsmaking them temporal.

2.5.1 The Representation of TimeThe time representation is similar to that proposed byGadia and Yeung [14] for the relational model, but isadapted to the requirements of the ER model. A time inter-val, denoted by [t1, t2], is defined to be a set of consecutiveequidistant time instants, where t1 is the starting instantand t2 the ending instant. The distance between two con-secutive time instants can be adjusted based on the granu-larity of the application to be equal to months, days, orother suitable time units. A temporal element is a finite unionof time intervals denoted by, {I1, I2, ¡, In} where Ii is an in-terval in [0, now]. A temporal database stores historical infor-mation for a time interval [0, now] where 0 represents thestarting time, of the database miniworld application, and nowrepresent the current time which is continuously expanding.

The authors state that the TEER model has no limitationsregarding support of time dimensions, but due to spacelimitations, the articles consider only valid time.


2.5.2 The Model ComponentsThe TEER model extends the EER model [10] to includetemporal information on entities, relationships, superclass/subclasses, and attribute. Since the graphical representationof TEER model components is similar to that of the EERmodel presented by Elmasri and Navathe [10], we will notexplain it in detail. Instead, we will concentrate our atten-tion on the new meaning given to the syntactical constructsof the EER model.

Entities and Entity types. In the TEER model, each entitye of entity type E is associated with a temporal elementT(e) ² [0, now] that gives the lifespan of the entity. Thelifespan of an entity can be a continuous time interval, or itcan be the union of a number of disjoint time intervals. InTEER, each entity type has a system-defined SURROGATEattribute whose value is unique for every entity in the data-base. The value of this attribute is hidden from the user anddoes not change throughout the lifespan of the entity. Thetemporal element of the SURROGATE attribute of entity edefines the lifespan T(e) of the entity.

The temporal properties of weak entities are similar tothose of regular entities, except that the temporal elementT(e) of each weak entity must be a subset of the temporalelement of its owner entity.

Attributes and Keys. The attribute types of the TEERmodel are the same as those of the EER model, althoughthey are all temporal. The temporal value of each attribute Ai

of e, denoted by Ai(e), is a partial function Ai(e) : T(e) �dom(Ai). This is also referred to as a temporal assignment. Thesubset of T(e) in which Ai(e) is defined and denoted byT(Ai(e)) is called the temporal element of the temporal assign-ment. It is assumed that Ai has the value NULL or UN-KNOWN during the time intervals T(e) - T(Ai(e)).

To give an example of the above, consider the databasedescribed by Fig. 10, and assume that the chosen granular-ity of time is a day. A particular EMPLOYEE entity e withlifespan T(e) = [7/1/90, now] may have the temporal attrib-ute values given in Fig. 11.

The following constraint apply to attributes and keys inthe TEER model. Simple single-valued attributes have atmost one atomic value for each entity at each time instant[t]. Multivalued attributes can have more that one value foran entity at a given time instant [t]. For a given time instant[t], the value of a composite attribute of an entity is the con-catenation of the values of its components. The temporalelement of a temporal assignment of a composite attributeis the union of the temporal elements of the temporal as-signments of its components. A key attribute is an attributeof an entity type with the constraint that at any time instant[t] in [0, now], no two entities will have the same value forthis attribute. TEER allows updates of key attributes sinceeach entity is uniquely identified by its system-definedSURROGATE.

Relationship Types. Like entities of entity types, each rela-tionship instance r is associated with a temporal element

Fig. 10. A TEER schema modeling the running example.

Fig. 11. Example of a lifespan of an entity.


T(r) that defines the lifespan of the relationship instance. Aconstraint states that T(r) must be a subset of the intersec-tion of the temporal element of the participating entities.That is, T(r) ² (T(e1) > T(e2) > ¡ > T(en)) where T(ei) is thelifespan of the ith entity participating in r. Relationship at-tributes are treated similarly to entity attributes; the tempo-ral value Ai(r) of each simple attribute Ai is a partial func-tion Ai(r) : T(r) � dom(Ai) and its temporal element T(Ai(r))must be a subset of T(r). The cardinality ratios of the par-ticipating entity types have not been given any newmeaning.

The TEER model also offers user-defined and predicate-defined superclass/subclass relationships. An entity e of asuperclass E will belong to a predicate-defined subclass Cthroughout all time intervals where the defining predicateevaluates to true for that entity. For a user-defined sub-class, the user specifies when the entity is to be a memberof the subclass. In either case, the entity will have a tem-poral element T(e/C) that specifies the time intervalsduring which it is a member of the subclass C. The con-straint T(e/C) ² T(e) on temporal elements must hold. At-tributes of a subclass are treated similarly to other attrib-utes; the temporal elements of their temporal assignmentsmust be subsets of T(e/C).

2.5.3 SummaryTEER does not add any new syntactical constructs to theEER model, but changes the semantics of all the standardEER constructs, making them temporal. TEER do not pro-vide any mapping from TEER diagrams to any implemen-tation model.

2.6 The Semantic Temporal EER ModelThe Semantic Temporal EER model (STEER) [8], [9] wasdeveloped in order to compensate for a lack of considera-tion of the semantics associated with time in previous re-search that had concentrated on temporal data models andquery languages in the context of the relational model andnot so much in the context of conceptual data models.STEER introduces a new classification concept for temporaland conceptual objects and provides guidelines for identi-fying objects as conceptual or temporal.

2.6.1 The Representation of TimeThe representation of time in STEER is very similar tothe representation of time in the TEER model just sur-veyed. Actually, the only difference is that the time do-main T of the database application is expanded from T ={t0, t1, t2, ¡, tnow} to T = {t0, t1, t2, ¡, tnow, tnow+1, ¡}. Thatis, it is now possible to reference future time points.NULL is used to represent the unknown time point, andtnow is used to represent the current time point. STEERonly supports valid time.

2.6.2 The Model ComponentsThe STEER model distinguishes between conceptual andtemporal entities. A conceptual entity is treated as an objectwith permanent existence. That is, once an entity is createdin the database, it can be referenced at any future point intime. A temporal entity—also called an entity role becauseit models one of the several roles that a conceptual entity

can participate in over time—on the other hand, has a spe-cific lifespan describing its existence. STEER distinguishesbetween temporal and nontemporal attributes, and it dif-ferentiates between temporal and conceptual relationshipsas well. It also defines temporal constraints among entityroles and conceptual and temporal relationships.

Conceptual Entities and Their Entity Roles. To understandthe idea behind the distinction between conceptual entitiesand entity roles, consider an example. Initially, note thatentities from the modeled miniworld need to be repre-sented in the database when they become of interest. Forexample, students exist in the miniworld as persons. How-ever, they do not become of interest to a university beforethey have been accepted at the university. At that point, theuniversity might want to record previous informationabout the students. Then, when students leave the univer-sity, they often remain of interest to the university for sometime. So the conceptual existence of an entity does not di-rectly correspond to the birth, dead, or change of the entity.In this example, persons are modeled as conceptual entities,and (persons in their roles as) students are modeled as en-tity roles.

Conceptual entities describe the conceptual aspects ofthe real world. A conceptual entity type is a set of concep-tual entities of the same type. Conceptual entity types arerepresented by rectangles in STEER diagrams; in Fig. 12,Employee is an example.

The temporal aspects of the real world are described bytemporal entities which are also called entity roles becausethey represent the active roles a conceptual entity can par-ticipate in. A role type is a set of entity roles of the sametype. Each role type is associated with a single entity typecalled its owner entity. A role type is represented by a filledrectangle and connected to its owner entity type.W_Employee in Fig. 12 is an example. W_Employee modelsall the employees currently employed by the company.

Each conceptual entity e is associated with an existencetime, ET. The start time point ST of the existence time re-fers to the time when the entity was recorded in the da-tabase. The end time point of an existence time is infinitybecause an entity once created never ceases to exist.Hence, ET = [ST, �[.

Each entity role ro of a role type RO is associated with atemporal element T(ro) ± [t0, �[ that gives the lifespan ofthe entity role. The lower bound (start time) tl of a lifespan[tl, tu] of an entity role must be closed; tl cannot be NULLbecause the start time of an entity role cannot be unknown;nor can it be tnow, since the current time is a dynamic con-cept. The upper bound (end time) tu can either be closed oropen; tu can be tnow if tl � tnow or NULL if tl > tnow.

The association between a conceptual entity and its en-tity roles can be viewed as some sort of superclass/subclassrelationship with mutual inheritance of attributes and rela-tionship instances. The following set of rules clarify thisrelationship.

1)�A role type has exactly one entity type as owner.2)�The start time of the lifespan of en entity role must

be greater than or equal to the start time of theowner entity.


3)�A role type can only have temporal attributes.4)�Attributes of a role type are “public” to the owner en-

tity type, and attributes (temporal and nontemporal)of the owner entity type are “public” to all the associ-ated role types.

5)�An entity role can access all relationship instances ofrelationship types in which the owner entity partici-pates, and, reversely, an entity can access all relation-ship instances of relationship types in which the asso-ciated entity roles participates.

Nontemporal and Temporal Attributes. Nontemporalattributes can only be properties of conceptual entitytypes. The value of a nontemporal attribute of an entityholds over the entire existence time of the entity. Non-temporal attributes are represented with circles in dia-grams. An example is the nontemporal attribute ID ofEmployee in Fig. 12.

Each entity is provided with a system-defined nontem-poral SURROGATE attribute whose value is unique forevery entity in the database. The value is not visible to theuser and is never altered.

Each entity type E or role type RO may have a set oftemporal attributes TA1, TA2, ¡, TAn, and each temporal

attribute TAi is associated with a domain of values,dom(TAi). In STEER diagrams, temporal attributes are rep-resented by ellipses; an example is the temporal attributeprofit of Act_Department in Fig. 12.

The next definitions are very similar to those presentedin Section 2.5. For entity roles, the temporal value of eachattribute TAi of ro, referred to as TAi(ro) is a partial functionfrom T(ro) to dom(TAi). The subset of T(ro) in which TAi(ro)is defined is denoted by T(TAi(ro)). It is assumed that TAihas NULL or UNKNOWN as its value during the intervalsT(ro) - T(TAi(ro)). The similar definitions apply to entities,the only difference being that T(ro) is replaced by ET(e) (i.e.,the lifespan of entity e).

The partial function that describes the value of a tempo-ral attribute is also called a temporal assignment. The sub-set of time points during which a temporal attribute is de-fined is called the temporal element of the temporal as-signment. The different types of temporal attributes aresimilar to those of the TEER model. For nontemporal at-tributes of an entity, the temporal element of the temporalassignment is equal to the existence time of the entity.

For an example of the above, consider the database de-scribed in Fig. 12 and assume that the chosen granularity oftime is a day. A particular Employee entity e with existence

Fig. 12. The running example modeled using the STEER model.

Fig. 13. Temporal attribute values of the entity e.


time ET(e) = [7/1/90, � [ may have the temporal attributevalues shown in Fig. 13.

Conceptual and Temporal Relationships. A conceptualrelationship type R of degree n has n participating entitytypes E1, E2, ¡, En. Conceptual relationship types cannothave role types as participants. Each relationship instancer in R is an n-tuple Æe1, e2, ¡, enÖ with ei ³ Ei. Each rela-tionship instance r in R has an existence time ET. The starttime must be greater or equal to the start time of the exis-tence time of each of the n participating entities, i.e., ST(r)� ST(ei) for all ei. Conceptual relationships are representedby diamonds in STEER diagrams. Worked_for in Fig. 12 isan example.

A temporal relationship type TR of degree n has n par-ticipating entity types or role types O1, O2, ¡, On where Oiis either an entity type or a role type. Thus, each temporalrelationship instance tr in TR is a n-tuple Æo1, o2, ¡, onÖ withoi ³ Oi. Temporal relationships are represented by filleddiamonds, and an example in Fig. 12 is Belongs_to. Eachtemporal relationship instance tr is associated with a tem-poral element T(tr) that give the lifespan of the temporal rela-tionship instance. This lifespan must be a subset of the inter-section of the lifespans of the involved entity roles and entities.

As for entities and entity roles, the association between aconceptual relationship type and a temporal relationshiptype can be seen as some sort of superclass/subclass rela-tionship. Two constraints are enforced on temporal andconceptual relationships.

First, there is the R-existence Constraint. This constraint,denoted by R/TR, holds between a conceptual relationshiptype R and temporal relationship type TR where all theparticipating object types are role types if for each tri = Æro1, ro2, ¡, ronÖ in TR, the following two conditions hold.

�� There exists a corresponding conceptual relationshipri = Æe1, e2, ¡, enÖ in R such that owner(roj) = ej for eachroj in tri.

�� The start time of the lifespan of tri must be greaterthan or equal to the start time of the existence time ofthe corresponding conceptual relationship ri.

Second, there is the R-lifespan Constraint, denoted byTR/R. This constraint holds between a temporal relation-ship type TR where all the participating objects are roletypes and a conceptual relationship type R if for each ri = Æe1, e2, ¡, enÖ in R, the following two conditions hold.

�� There exists a corresponding temporal relationship tri= Æro1, ro2, ¡, ronÖ in TR such that ej = owner(roj) foreach ej in ri.

�� The start time of the existence time of the conceptualrelationship ri must be greater than or equal to thestart time of the lifespan of the corresponding tempo-ral relationship tri.

The R-lifespan constraint is used to model the caseswhere a conceptual relationship cannot exist until after atemporal relationship has started. For, example studentscannot get transcript entries for courses until after they haveenrolled. R-existence and R-lifespan constraints are repre-sented in STEER diagrams by placing an oval with an e an al, respectively, on the line connecting the involved relation-ship types.

Superclass/Subclass Relationships. Like the EER model,STEER supports the concepts of subclasses and super-classes and the related concepts of specialization and gen-eralization. A class is any set of entities; hence, an entitytype is also a class.

A member entity of a conceptual subclass represents thesame real-world entity as some member entity in its con-ceptual superclass. Thus, an entity cannot exists in the da-tabase as a member of a subclass without also being amember of the superclass. This implies that an entity that isa member of a subclass will have the same existence time asthe corresponding entity in its superclass.

Attributes of a superclass are inherited by its subclasses.A subclass entity also inherits all relationship instances inwhich its corresponding entity in the superclass partici-pates. The graphical notation for superclass/subclass rela-tionships is similar to that of the EER model [10]. However,one should notice that when converting a nontemporal EERdiagram into an STEER diagram, many or most of the sub-classes are likely to become role types. An example of this isgiven in Fig. 14, where the nontemporal EER schema to theleft is converted to the STEER diagram to the right. This isalso the reason why no conceptual entity type Managerexists in Fig. 12 and why the nontemporal attribute Rankhas to be moved to Employee.

When role types participate in superclass/subclass rela-tionships, two temporal constraints may be indicated. Anexistence constraint holds between two role types ROi (su-perclass) and ROj (subclass) if for all roles rojk in ROj, thereexists a role roil in ROi such that rojk � roil. Next, a lifespanconstraint holds if the lifespan of any entity role rojk in ROjis a subset of the lifespan of the entity role roil in ROi withrojk � roil. Notice that the lifespan constraint implies the ex-istence constraint, but not vice versa. In STEER diagramsexistence and lifespan constraints are represented the sameway as R-existence and R-lifespan constraints. Fig. 12 con-tains an example of a lifespan constraint betweenW_Employee and W_Manager is shown. The l in the oval isreplaced by an e if an existence constraint is to be indicated.

2.6.3 SummarySTEER is a semantic temporal model where conceptual en-tities are considered to exist forever (or more precisely, fromwhen they become of interest to the application), whereasthe roles they participate in, i.e., the temporal entities, havelifespans to determine their existence. The same distinctionholds for relationships. A general set of constraints for pre-serving temporal consistency is presented.

2.7 The Entity-Relation-Time ModelThe Entity-Relation-Time (ERT) model exists in two ver-sions, the original version [35], [37], and a recent refinement[22]. We survey first the original model and then discuss therefinements at the end.

The motivation for the development of the original ERTmodel was to meet the need for conceptual models of en-hanced system functionality. In ERT, this need is addressedthrough the use of a conceptual modeling formalism thatcaters for the modeling of business rules, time, and complexobjects. This formalism is supported at the database level by


an extension of the relational model with temporal seman-tics and an execution mechanism that provides active-database functionality.

In the description of ERT, the term class is used insteadof the term type. We will follow the description. The basicstructures of ERT are those of the binary Entity-Relationship model, with the exception that it regards anyassociation between objects as a relationship. Specifically,the distinction between “attributeships” and relationshipsis avoided. The ERT model extends the ER model both inits semantics and graphical notation in two directions: themodeling of time-varying information; and the modeling ofcomplex objects.

In the ERT model, the term time-varying information re-fers to pieces of information where the modeler wants tokeep track of their evolution, i.e., wants to record theirvariation over time.

2.7.1 The Representation of TimeTime is introduced in the ERT model via a distinguishedentity class, the time period class, and the time period is con-sidered the most primitive temporal notion in the model. Atime period starts and ends in a tick and also has a durationexpressed in ticks, i.e., a tick is defined as the smallest unitof time permitted in ERT. Each time-varying entity classand relationship class is timestamped with a time periodclass. That is, a time period with a specified granularity isassigned to every time-varying piece of information thatexists in an ERT schema.

When a time period class is associated with an entityclass, it models the lifespans of the entities in the class. Thelifespan of an entity is also referred to as its existence period.When a time period class is associated with a relationshipclass, it models the time period during which a relationshipis valid. This is referred to as the validity period of a relation-ship instance and models the period in time that the rela-tionships holds. This latter time notion thus corresponds tovalid time.

A number of assumptions were made in order to in-crease the feasibility and practicality of the proposed ap-proach, including the following:

1)�System-generated surrogates are used for uniqueidentification of entities.

2)�Reincarnation of entities is permitted, i.e., if an en-tity no longer is in the database, meaning that theexistence period of the entity ends in a tick less thanthe current time, it can return using the same surro-gate. This implies that entities keep their identitythrough time.

3)�Existence and validity periods should always bemapped onto the calendar axis, i.e., they should bespecified in absolute terms. That is,

�� if the existence period of a timestamped entity isnot specified explicitly as an absolute value, thenthe current time is taken as start point of the exis-tence period, and

�� if the validity period of a timestamped relationshipis not specified explicitly as an absolute value, thenthe most recent starting point of the existence timesof the involved entities is taken as start point of thevalidity period of the relationship.

4) Nontimestamped entities and relationships are as-sumed to always exist, i.e., they exist from the systemstart-up time until the current time.

2.7.2 The Model ComponentsThe most central concept of the ERT model is that of a class,defined in the usual way. This means that the most primi-tive data abstraction is classification of individual objects.Thus, in ERT schemas, entity classes, value classes, complexentity classes, complex value classes, and relationshipclasses are specified.

Simple Entity Classes and Simple Value Classes. A simpleobject cannot be decomposed into other objects and hencehas independent existence—it is irreducible. The simple

Fig. 14. Mapping nontemporal superclass/subclass relationships to the TEER model.


objects classes of the ERT model are divided into twogroups: simple entity classes and simple value classes.

A simple entity class is represented by a rectangle, and ifthe entity class is time-varying, the rectangle is expandedwith a “time box.” An example of a time-varying, simpleentity class is Employee (shown in Fig. 15), and an exampleof nontimestamped entity class is Project.

A simple entity class can be derived. This implies that itsinstances are not stored by default, but can be obtained dy-namically when needed, by using derivation formulas. A de-rived entity class is represented by a dashed rectangle. De-rived entity classes can be time-varying as well. For eachderived entity class, there is exactly one derivation formulathat gives the members of that entity class at any time. Ifthe derived entity class is not timestamped, the corre-sponding derivation formula instantiates this entity class atall times; whereas if the entity class is timestamped then thederivation formula obtains instances of this class togetherwith their existence periods.

A simple value class is represented by a rectangle witha black triangle placed in the bottom right corner. Simplevalue classes cannot be time-varying. An example of asimple value class is Name in Fig. 15. A simple value classcan, like a simple entity class, be derived and is then rep-resented by a dashed rectangle with a black triangleplaced as before.

Complex Entity Classes and Complex Value Classes. Acomplex object is an object that can be decomposed intoother objects, and thus its existence depends of the exis-tence of its component objects. The relationship betweenthe complex object and its component objects is modeledusing IS_PART_OF relationships. The complex objectclasses, like the simple objects classes, are divided into twogroups, complex entity classes and complex value classes.

Complex value classes are represented by a double rec-tangle with the black triangle placed (as usual) in the innerrectangle. Complex value classes can only have complexvalue classes or simple value classes as components, andhence a complex value class cannot be time-varying. Anexample of a complex value class is Name in Fig. 15. TheIS_PART_OF relationship cannot be seen at this level ofabstraction; an example of unfolding a complex class willbe given later.

A complex entity class is represented by a double rectan-gle, and if it is time-varying, the “time box” is added to theinner rectangle. The components of a complex entity classcan be both simple and complex, and they can be of valueclass and entity class type. The time semantics of timestam-ped complex objects will be explained in detail after theexplanation of the IS_PART_OF relationship.

In the presentation of MOTAR, Project was described asa component of the composite entity type Department. Thiscould also have been done in ERT by making Department acomplex entity class, but then it would not have been pos-sible to describe the relationship between Project and, e.g.,Employee.

Relationships Classes. In ERT there are four kinds of rela-tionship classes. There are the user-defined relationshipclasses, the IS_PART_OF relationships between complexobjects and their composite objects, the ISA relationshipsbetween subclasses and their super classes, and the objecti-fied relationships. We explain each in turn.

User-defined relationship classes are binary and are rep-resented by small filled rectangles; if they are time-varying,a “time box” is added. There are two constraints on the va-lidity periods of a relationship class’ instances. First, theintersection of the existence periods of the participatingentities must be nonempty. Second, the validity period of

Fig. 15. ERT schema description of the running example.


the relationship instance must be a subperiod of the inter-section of the existence periods of the involved entities.

An instance of a user-defined relationship class isviewed as a named set of two (entity or value, role) pairs,where each role expresses the way that a specific entity orvalue is involved in the relationship. These two namedroles are called relationship involvements and are required ina ERT schema for completeness reasons. In addition to therelationship involvements, a cardinality constraint is re-quired to be specified for each entity class participating inthe relationship class. Each cardinality constraint is a pair(a, b ) where a indicates the minimum and b the maximumnumber of times that an entity or value can participate in arelationship. The cardinality constraints are also used tospecify whether the involvement is optional or mandatory. Ifthe involvement is mandatory then a = 1, whereas if a = 0,the involvement is optional.

As an example, see the relationship class between Em-ployee and Department shown in Fig. 15. The two relation-ship involvements are “belongs_to” and “employs.” Thetwo corresponding cardinality constraints state that eachEmployee instance is related to (i.e., belongs_to) preciselyone Department instance, yielding a uniqueness constraint onEmployee; and each Department instance is related to (i.e.,employs) from one to N Employee instances. If both thecardinality constraints of a relationship class between a en-tity class and a value class are (1, 1), this corresponds to thenotion of a key in database theory.

User-defined relationship classes can, like simple entityclasses, be derived and are then represented by dashed,nonfilled rectangles; and they can be time varying. As for aderived timestamped entity class, the derivation formula ofa derived timestamped relationship class specifies a valid-ity period for each instances of the class.

ISA relationship classes are first divided into two groups,partial and total, that are further subdivided into overlap-ping and disjoint, yielding four types of ISA relationshipclasses. The partial ISA relationship class is represented bya nonfilled circle with arrows flowing from the subclass to

the circle and an arrow flowing from the circle to the super-class. The total ISA relationship class is represented by afilled circle. If there is more than one subclass and morethan one arrow is pointing into the circle, the relationshipclass is disjoint; otherwise the relationship class is overlap-ping. The existence time of a specialized entity should be asubperiod of the existence time of the corresponding parententity.

IS_PART_OF relationship classes are used to specify therelationships between the components of a complex objectand the complex object itself. Each directly subordinate ob-ject class is IS_PART_OF-related to the complex object class,which in turn is HAS_COMPONENT-related to the com-posite object class. This composition mechanism does notmake any distinction between aggregation and grouping,but is rather general. Whether the HAS_COMPONENTinvolvement is one of aggregation or grouping can be indi-cated using cardinality constrains. That is, if the cardinalityis one of (1, 1) or (0, 1), the component is an aggregate,whereas if it is (0, N) or (1, N) the component is a set.Fig. 16 gives an example.

In ERT, complex objects can be used to model both logicalpart hierarchies, where the same component can be part ofmore that one complex object, and physical part hierarchies,in which an object cannot be part of more than one complexobject at the same time. To achieve this, four differentIS_PART_OF relationship classes are defined using combi-nations of two orthogonal types of constraints, namely de-pendency and exclusiveness. The dependency constraint de-pendent states that when a complex object ceases to exist, allits components also cease to exist (dependent compositereference), and the dependency constraint independent statesthat if a complex object ceases to exist, this does not implythat the components cease to exist (independent compositereference). The exclusiveness constraint exclusive states thata component object can be part of at most one complexobject (exclusive composite reference) at a time, and theexclusiveness constraint shared states that it can be partof more than one complex object at a time (shared com-posite reference).

Fig. 16. Unfolding a complex entity class.


No specific notation is introduced for these constraints.Rather, they are given by the cardinality constrains of theIS_PART_OF relationship. That is, assume that the cardi-nality constraint of the IS_PART_OF relationship is (a, b).Then a = 0 implies independent dependency, a � 0 impliesdependent dependency, b = 1 implies exclusive exclusive-ness, and b � 1 implies shared exclusiveness.

Timestamping in a time-varying IS_PART_OF relation-ship of a complex object is subject to different time con-straints depending on whether it has dependent or inde-pendent dependency semantics and exclusive or sharedexclusiveness semantics. The dependency constraint de-pendent in time-varying IS_PART_OF relationships impliesthat the existence time of the complex object and the com-ponent object should end at the same time as does the va-lidity period of the IS_PART_OF relationship. The exclu-siveness constraint exclusive implies that if an object A ispart of objects B and C, then the period during which A ispart of B should have empty intersection with the periodduring which A is part of C.

In ERT, only binary relationship classes can be specified.Thus attributes cannot be attached to relationship classessince this would make the relationship class “ternary.” Asillustrated in Fig. 17a, this may yield problems. If we wantto add the class GRADE to this schema, we will face theproblem of where to add it. Specifically, GRADE has to beattached to either STUDENT or SUBJECT, both of which areproblematic. There is thus a need to model ternary relation-ships. To achieve this, ERT permits relationship classes toparticipate in relationships. This is called nominalization,and the particular construct in which a relationship class isviewed as an entity class is called an objectified relationship.An objectified relationship must include the two corre-sponding involvements. The relationship class that is ob-jectified should always be many to many (the cardinalityconstraints on both of the involvements must be (1, N)). Thestatus of an objectified relationship is that of an entity class.As such, it may participate in any relationship except thatof an ISA relationship. Also, the existence periods of the

objectified timestamped relationship class’ instances are thesame as the validity periods of the corresponding nomi-nalized relationship class instances. The graphical notationof objectified relationships is depicted in Fig. 17b.

2.7.3 Refining the Original ERT ModelThe original ERT model has recently been refined [22] intwo respects. First, the definitions of temporal objects (enti-ties or relationships) are given mathematically, by specify-ing what constraints are placed on the existence or validityperiods of an object when a temporal marking is applied to it.Second, temporal markings are used to represent temporalvariation of object with respect to each other. In particular,the period in which a relationship involvement can exist isrelated to the period in which the associated entities exist,and the periods in which entity subclasses exist are relatedto the period in which their superclass exists. Two distinctaspects of the temporal nature of relationship involve-ments, called historical perspective and temporal variation, areidentified. As a precursor to delving further into this, weconsider a refinement of ERT’s time periods.

A notation for describing the ticks when an instance of atemporal entity class exists or a temporal relationship classholds is introduced. The period over which an instance ofa temporal entity class or temporal relationship class xexists/holds is a set Ix = {ta, tb, ¡, tz} where ta, tb, ¡, tz arethe ticks at which x exists/holds. Since the series of ticksusually is continuous, Ix is called an interval although whatactually has been defined is a set of intervals [22]. Thisdefinition of “intervals” allows for the use of the usualset operators. To ensure a discrete bounded model, thepossible ticks of an interval are limited to the finite set of ¥= {0 … t }, and for all x, the interval Ix will satisfy Ix ² ¥.

In the original ERT model, a relationship class couldonly be marked with a T-mark indicating that the relation-ship was time-varying. The temporal marking is refined in[22] to include H-marks and TH-marks. In the following,interval i.e., ranges over all intervals associated with entity

Fig. 17. Objectified relationship.


class E; and the properties of intervals that we give musthold for all instances of the entity class. Thus stating IE ² ¥means that for all entities e in E, Ie ² ¥.

If a relationship involvement exists for a subset of theticks for which both the entities it associates exist, andonly associate entities which exist at the same time tick,then the relationship is said to undergo temporal variationwith respect to the entities it associates, and the relation-ship is T-marked.

If a relationship involvement exists at certain ticks be-tween entity E1, which exists at those ticks, and a entity E2,which exists at other ticks, then the relationship is said tohave historical perspective, and the relationship is H-marked.Note that such relationships are asymmetric, since at anytick only E1 is required to exist; the inverse relationship(from E2 to E1) may not hold at the same tick.

The above-mentioned terms can be combined. Sayingthat a historical perspective has temporal variation meansthat that one of the entities involved does not have the per-spective for its entire existence.

Four constraints on the validity period of an instance ofa relationship class results. Initially, let IE1

and IE2 be the

intervals for which entity classes E1 and E2 exist. First, if IR

is the interval over which the instances of E1 and E2 are in-

volved in an unmarked relationship, then IR = IE1 > IE2

.

Second, if IR is the interval over which the instances of E1

and E2 are involved in a T-marked relationship class, then IR

² IE1 > IE2

. Third, assume that instances of entity classes E1

and E2 are related by R. If the instances of E1 and E2 are in-volved in R over period IE1

and IE2, respectively, and the

relationship class R is H-marked, then IE1 � IE2

is allowed.

To exemplify an H-marked relationship class, consider thegrandparent/grandchild relationship between persons.Here, related persons need not exist simultaneously for anytick; a grandparent may die before the birth of a grandchild.As we shall see next, the historical perspective of a relation-ship has a temporal direction. An H-marked relationshipclass R relating E1 and E2 is described as

�� past, if E2 holds at ticks before the ticks at whichE1 holds,

�� current, if E2 holds at the same ticks for which E1holds, and

�� future, if E2 holds at ticks after the ticks at whichE1 holds.

Finally, Boolean combinations of the above are possible. Itfollows that an unmarked relationship class is merely a cur-rent historical perspective relationship class. In the aboveexample the temporal direction could be past and current

(depending on what is E1 and E2). The characteristics of H-marked relationships can be described using derived entityclasses, for details see [22]. Fourth, assume that instances ofE1 are involved in R over period IE R1

² IE1 and instances of

E2 are involved in the same relationship instance for IE2

and relationship R is TH-marked. Then, IE R1 � IE2

is al-

lowed. This TH-mark can be used to model that we do notwant the grandparent to be related to the grandchild beforethe grandchild is actually born.

2.7.4 SummaryThe data model ERT extends a binary Entity-Relationshipmodel with complex entity classes and complex valueclasses. ERT provide the users with temporal markings oftime-varying entity and relationship classes, and instancesof these classes are timestamped with time periods. Thetemporal markings of classes have later been refined.

2.8 The Temporal ER ModelThe Temporal ER model (TER) [33] has it origin in the ERmodel. Most centrally, TER replaces the ordinary cardinal-ity constraints with snapshot and lifetime cardinality con-straints. This permits a refinement of the classification ofrelationship types, thereby obtaining a total of six differentclasses of relationship types; and it leads to a refinement ofthe optionality of relationship participation.

Designing a database using the TER model includesthree steps. First, a TER diagram is constructed that usesthe two new types of constraints for describing the time-varying aspect of relationship types. No time attributes areincluded. Then, based on how often historic data is ex-pected to be accessed, a particular algorithm that translatesTER diagrams into traditional ER diagrams is applied,leading to a diagram with only regular cardinality con-straints and with explicit time attributes. Third, the ERdiagrams is translated into relational tables using a stan-dard mapping.

2.8.1 The Model ComponentsThe key differences between TER and the (binary) ERmodel are the inclusion of snapshot and lifetime cardinalityconstraints, and the intermediate step of transforming TERdiagrams to ER diagrams. Time is thus implicit in TER dia-grams. The TER diagram describing the running example isshown in Fig. 18. In the remainder of this subsection, weconsider the cardinalities; the next subsection considers theintermediate step.

The modeling of time-varying information is improvedin TER by replacing the traditional cardinality constraintsby two new types of constraints, the lifetime cardinality,denoted by L[minL, maxL], and the snapshot cardinality,denoted by S[minS, maxS]. For an example, consider therelationship type between entity types Department andProject in Fig. 18. Relationship types have two directions,with each direction having a source and a target. In TERdiagrams, the cardinality constraints are with respect to adirection of a relationship type, and they are placed next tothe target entity type, by the relationship type.

A lifetime cardinality constraint L[minL, maxL] states thatthe minimum and maximum number of instances of thetarget entity related to one instance of the source entityover all of time is minL and maxL, respectively. Similarly, asnapshot cardinality constraint S[minS, maxS] states that the


minimum and maximum number of instances of the tar-get entity related to one instance of the source entity atany single point in time is minS and maxS, respectively.Below, the conditions that define any valid combinationof cardinalities for any given relationship direction inTER are defined:

0 < maxS and 0 < maxL0 � minS � maxS � maxL0 � minS � minL � maxL

In the relationship type between Department and Proj-ect, a Department instance (a “department”) may have from1 to n associated Project instances (“projects”) during itslifetime, but it may have at most 10 associated projects atany single point in time. A project is associated with pre-cisely one department at any single point in time; and aproject is associated with precisely one departmentthroughout its lifetime. Thus, projects cannot be reassignedfrom one department to another.

As it is the case for cardinality constraints in the ERmodel, cardinality constraints in the TER model can alsoexpress connectivity. Thus, a set of connective values of re-lationship type directions are defined as follows.

one for (maxS =) maxL = 1oneT for maxS = 1 and maxL > 1many for maxS > 1

The introduction of the new connective value oneT (“oneat a time”) leads to a refined classification of relationshiptypes. Traditionally, there are three distinct and exhaustiveclasses of relationship types: one-to-one, one-to-many, andmany-to-many. While still disjoint, these classes are nolonger exhaustive when snapshot and lifetime cardinalityconstraints are used, as the classes no longer cover allvalid combinations of values for minS and minL in both

directions. Therefore, three new relationship classes areadded to the before mentioned three, namely one-to-oneT,oneT-to-oneT, and oneT-to-many.

Up until now, the optionality of a relationship-type direc-tion has been implicit. It has been assumed that if minS = 0in a direction, this implies that participation is optional inthat direction. But given the definitions of snapshot andlifetime cardinalities, the notion of optionality can be re-fined. A relationship-type direction is snapshot optional(optS) if minS = 0; otherwise, it is snapshot mandatory(mandS). A relationship-type direction is lifetime optional(optL) if minL = 0; otherwise, it is lifetime mandatory (mandL).The refinement implies that columns in the relational tables,that result from snapshot mandatory directions of relation-ship types are not allowed to have null values. The follow-ing holds for the refined optionalities:

optL implies optSmandS implies mandLmandS and optL are incompatible

In TER diagrams such as that in Fig. 18, the entitytypes do not include attributes that make is possible todistinguish different states of entities. For example, thereare no means of recording different states of Employeeentities. These means are implicit, and they are broughtout by the mapping of TER diagrams to ER diagrams, asdescribed next.

2.8.2 Mapping TER Diagrams to ER DiagramsOne consequence of introducing the temporal aspects ofrelationships into TER is that there now exists a basis forthe semiautomatic incorporation of time-varying data inrelational tables. How applications are to deal with time-varying data largely depends on the volume of such data,the frequency of access to it, etc. TER provides three generalapproaches of dealing with time-varying data. They arebased on the frequency of access to noncurrent data.

Fig. 18. A TER diagram of the running example.


Never If there is no interest in the noncurrentdata, there is no reason for storing it. Noprovisions for retaining noncurrent dataare needed; old data is simply overwrit-ten by new.

Occasional If the noncurrent data is accessed infre-quently, it would be rather inefficient tostore it together with the much more fre-quently accessed current data. Thus, sepa-rating the current data from the noncur-rent data at the conceptual level simplifiesthe design process.

Frequent If the noncurrent data is anticipated to beaccessed almost as frequently as the cur-rent data, it is most efficient to store themtogether.

TER then provides three different algorithms for trans-lating TER diagrams into ER diagrams, one for each cate-gory. Fig. 19 shows the result of using the algorithms on afraction of the running example.

The mappings only provide means of recording multiplestates of time-varying TER relationship types; while notdocumented, it should be straightforward to extend them toalso provide means of recording multiple states of time-varying entities and attributes. Note how lifetime andsnapshot constraints are replaced with appropriate regularcardinality constraints.

2.8.3 SummaryThe TER model provides means for better time-varyingdata modeling. Specifically, ordinary cardinality constraints

are replaced with snapshot and lifetime cardinality con-straints. Using these, TER redefines the classification of re-lationships and the notion optionality. Specifically, a new,oneT cardinality is introduced. Time is implicit in TER dia-grams, but the temporal aspects are made explicit throughthe mapping of TER diagrams to ER diagrams.

2.9 The TempEER ModelThe motivation behind TempEER2 [21] is to be able to cap-ture temporal information in a conceptual model (specifi-cally, the EER model) and then, via an appropriate map-ping, in the relational data model.

In achieving this, TempEER does not add new syntacti-cal constructs to the EER model, but assumes a temporaldimension to the existing EER constructs. The mapping tothe relational-model level, adds two attributes, ValidTimeand TransTime, to all the relation schemas that a conven-tional mapping algorithm yields. It is an underlying as-sumption that the TempEER model is a design model onlyand that the implementation platform is relational.

2.9.1 The Representation of TimeTempEER captures both valid and transaction time, both ofwhich are assumed to have discrete domains, and differentgranularities may be specified for both of these domains.Time intervals are used as valid-time values, and time in-stants are used as transaction-time values.

Valid-time intervals are a subset of [0, UNTIL], withUNTIL being a time value greater than or equal to the

2. The authors gave their model the same name as the TEER already pro-posed by Elmasri et al. We adopt the name “TempEER.”

Fig. 19. Mappings of TER diagrams to ER diagrams.

Fig. 20. The relational representation of an Employee entity.


current time. Thus, the time domain for valid times extendsbeyond that used in the TEER model (Section 2.5). Transac-tion times never exceed the current time.

2.9.2 The Model ComponentsThe TempEER model does not add any new syntacticalconstructs to the EER model; rather, the temporal aspectsare implicit in TempEER diagrams. The TempEER dia-gram of the running example is therefore identical to thatof Fig. 10.

Entities and Entity Types. In TempEER diagrams, eachentity of an entity type is associated with a lifespan captur-ing the valid time of the entity. The lifespan can be a timeinterval or a temporal element.

When mapped to a relational platform, an entity is rep-resented by a set of tuples where each tuple describes onestate of the entity over time. An entity type is mapped to arelation schema with the attributes dictated by a standardmapping and with an interval-valued ValidTime attribute.Thus, any change to an attribute of an entity results in thecreation of new tuple capturing the new state of the entity.The lifespan of an entity is then the union of the ValidTimeintervals in the set of tuples that represent the entity. Inaddition to the ValidTime attribute, each tuple has aTransTime attribute that records the insertion time of thetuple, making it possible to capture the transaction timeof each tuple.

To exemplify, let us reconsider the entity described bythe example given in Fig. 11. This entity has lifespan T =[7/1/90, UNTIL] and is represented at the relational levelby the two tuples in Fig. 20.

The temporal information of weak entity types is storedexactly as for ordinary entity types. The constraint that thelifespan of a weak entity must be a subset of the lifespan ofits owner entity is enforced (the interaction with transactiontime is not considered).

Attributes. The attribute types of TempEER are those of theEER model, with the exception that their changing valuesover time are retained.

A single-valued attribute has one atomic value for anypoint in time; multivalued attributes can have more thatone value at a given point in time; and the value of a com-posite attribute at a given point in time is the concatenationof the values of its components at that point in time.

The valid time associated with an attribute value canbe deduced from the tuples at the relational level repre-senting the entity. For example, the temporal element asso-ciated with the attribute value Johnson in Fig. 20 is [7/1/90,UNTIL], whereas the temporal element associated with thevalue 20K is [7/1/90, 6/30/92]. The temporal element of anattribute value of an entity must be a subset of the lifespanof the entity.

Relationships Types. Each relationship instance of a rela-tionship type is associated with a lifespan defined in thesame way as for entities. The lifespan of a relationship in-stance must be a subset of the intersection of the lifespansof the participating entities.

Finally, TempEER also has superclass/subclass relation-ships. The lifespan of a subclass entity must be a subset ofthe lifespan of its superclass entity.

2.9.3 SummaryThe sparsely documented TempEER model does notadd any new syntactical constructs to the EER model,but instead changes the meaning of the existing con-structs. TempEER diagrams are mapped to tuple-timestamped bitemporal relation schemas. Temporal con-straints are introduced.

2.10 The TempRT ModelIn a working paper, Kraft [20] proposes TempRT3 that incor-porates valid time support into a binary ER model. To mo-tivate his approach, he first considers capturing valid timeusing explicit timestamp attributes, which is unattractive.

In his approach, valid time is captured through temporalrelationships, temporal entities, and temporal attributes.The basic temporal construct is the temporal relationshiptype. While ER diagrams are usually translated to relationalschemas, in this model there is an extensional level with isown graphical notation associated with the ER diagrams. Inthis notation, nodes represent the instances of entities andthe edges represent relations between instances.

The valid time domain employed is discrete, but is nototherwise described.

2.10.1 The Model ComponentsThe model is based on a binary ER model, and Fig. 21 ex-emplifies the notation. In this model only entity types, de-scribed by rectangles, and relationship types, described by“crows’ feet,” may be specified. The attributes in Fig. 21 areactually shorthand for one-to-many relationship types be-tween an entity type with all possible values of some valuedomain as instances and the entity type having the attrib-ute. Two diagonal lines are used to indicate that a constructis temporal. For example, the relationship type betweenEmployee and Emp_Proj is marked as temporal. The tem-poral markings of Employee and Emp_Proj are deviationsfrom the running example.

Temporal Relationship Types. The basic temporal struc-ture is the temporal relationship. The semantics of a tempo-ral relationship is an extension of the semantics of an ordi-nary relationship.

In Fig. 22a, on the left-hand side, the nontemporal rela-tionship between Employee and Department is repeated,and on the right-hand side, some instances are shown. Themeaning of the relationship is that every instance of Em-ployee must at any point in time be related to one and onlyone instance of Department, and every instance of Depart-ment may be related to zero or more instances of Employee.Only one (the current) department assignment of an em-ployee is recorded. Thus, if an employee is reassigned to anew department, the previous assignment is lost.

In Fig. 22b, the relationship type is considered to betemporal. The semantics of the temporal relationship typeis almost the same as for the nontemporal relationship type.

3. The author has not given the model a name. To clearly identify themodel, we adopt the name “TempRT.”


Every Employee instance still has to be related to one andonly one instance of Department at any point in time. Thedifference is that temporal relationships are timestampedand retained. As an illustration of this, the right-hand sideof Fig. 22b gives the employment history of Alice. At timet1, Alice becomes associated with Sales, and at time t2she is associated with Development. Then at t3 she is at-tached to Administration, and lastly, at time t4 she returnsto Sales. The union of all the timestamps of a temporal

relationship between two instances describes the lifespanof the relationship.

Temporal Entity Types and Attributes. Entity types donot have to be temporal. A nontemporal entity that par-ticipates in a temporal relationship cannot ever be changedor deleted. If this consequence is unwanted, the conceptof lifespans has to be added to the instances, makingthem temporal.

Fig. 21. TempRT diagram modeling the running example.

Fig. 22. Temporal relationships.


The lifespan of an instance is modeled through temporalrelationships. Specifically, a universal entity type U withonly one instance is introduced. This entity type is con-nected, using a temporal relationship type, with the entitytype we want to be temporal. Fig. 23a illustrates this. Thetime in which an Employee instance references the U in-stance gives the lifespan of the Employee instance. Fig. 23bshows the shorthand used in the model.

Temporal attributes are also defined using temporalrelationships. As mentioned, a (nontime-varying) attributeis a shorthand for a regular many-to-one relationship be-tween an entity with all possible values of some valuedomain as instances and the entity having the attribute. Inorder to make an attribute temporal, the ordinary rela-tionship between the entity having the attribute and theentity modeling the value domain is replaced by a tempo-ral relationship.

2.10.2 SummaryThe TempRT model makes it possible to specify temporalrelationships, temporal entities, and temporal attributes.The temporal entities and attributes are defined by tempo-ral relationships.

2.11 TERC+The motivation for the development of TERC+ [39] was toprovide users with a temporal conceptual model bettersuited for the design of temporal application than the tem-poral relational data models described in the literature.

TERC+ is a temporal extension of the ERC+ model [25],and it is part of a methodology for developing temporalapplications.

2.11.1 The Representation of TimeTERC+ adopts a linear and discrete model of time, and timepoints are called instants. TERC+ also defines intervals andtemporal elements: an interval is represented by a pair ofinstants, and a temporal element is a union of disjoint in-tervals. The model support different granularities, e.g.,year, day, hour, and minute, but supports valid time only.

The meaning of the new modeling constructs of TERC+follow from their mapping to corresponding ERC+ model-ing constructs, making explicit the information implied bythe new modeling constructs. ERC+ diagrams may be fur-ther mapped to the relational model.

2.11.2 The Model ComponentsTERC+ includes four kinds of modeling constructs, eachwith a temporal counterpart: attribute types, entitytypes, relationship types, and dynamic relationshipstypes. The model provides new notations for the tempo-ral counterparts of these construct. When describingthese constructs in the following, we use the diagram inFig. 24 for exemplification.

Attributes. There are two types of attributes in the model:simple and complex (composite) attributes. Both types of at-tributes can be either single-valued or multivalued, and thepresence of an attribute value can be mandatory (nonnull)

(a) (b)

Fig. 23. Temporal entity types.

Fig. 24. Describing the running example using TERC+.


or optional (null allowed). This is expressed by static cardi-nality constraints in the diagrams. A static cardinality con-straint for an attribute is expressed by the lines connectingthe attribute to its entity/relationship type, and the syntaxis given in Fig. 25. The meaning is given by the pairs ofnumbers in parentheses to the right of the lines. The firstinteger indicates if the attribute value is mandatory (1)or optional (0). The second integer indicates if the attrib-ute is single-valued (1) or multivalued (n). A static cardi-nality constraint for an attribute has to hold at any point intime. The same notation is used to express static participa-tion constraints for the participation of entity types in rela-tionship types.

Identifiers (key attribute values) of entity types cannotever be reused, e.g., once an employee entity is assigned avalue of the ID attribute, this value cannot be assigned toanother employee entity, not even if the entity is deleted.Key attributes are underlined in the diagrams.

Attributes can be temporal, which is indicated by plac-ing a clock symbol behind the attribute names. Forexample, the Salary attribute of the Employee entity type inFig. 24 is temporal. This means that the valid time of theattribute is captured. For this purpose, each value of a tem-poral attribute is associated with a temporal element re-cording the times during which the value is valid. It is as-sumed that the attribute value is undefined (unknown orinapplicable) for points in time that are not included in itstemporal elements.

For temporal attributes, a temporal cardinality, h(max),can be specified, limiting the number of values an attributecan have over the life-time of its entity. The default tempo-ral cardinality is h(n) and is omitted from the diagrams. Fora complex attribute, the temporality may be attached at anylevel. That is, a nontemporal, complex attribute may havetemporal components.

The meaning of the temporal attributes are defined interms of composite attributes in the ERC+ model where the

temporal information becomes explicit. The translationfrom TERC+ diagrams to an equivalent ERC+ diagram isvery simple. Fig. 26 shows the transformation for temporalattributes.

Entity and Relationship Types. Entity types are repre-sented by rectangles and may be regular or composite.Composite entity types are built from regular and compos-ite entity types. In Fig. 24, Employee is a temporal regularentity type. Entity type Department is related to Project bymeans of an aggregation link (part-of-relationship, de-scribed in the following). Department entities thus containProject entities, and Department is a composite entity type.

Both regular and composite entity types can be tempo-ral. A temporal entity has associated a life cycle that en-codes three possible states that an entity can be in. Eachstate is associated with a temporal element that recordsthe time the entity is in that particular state. The threestates are: active, e.g., an employee is active in the company;suspended, e.g., an employee is on sabbatical, and dead (de-leted), e.g., an employee is no longer with the company.That is, a life cycle consists of up to three different (state,temporal element) pairs.

The meaning of a temporal entity type as shown inFig. 27. The temporal information is made explicit byadding a multivalued composite attribute, called life-cycle, to an entity type in a ERC+ diagram.

TERC+ supports dynamic and traditional relationshiptypes. Briefly, the former are used to describe interobjectbehavior. There are four types of dynamic relationshiptypes. Transition relationships express that entities maychange their classification, e.g., a student graduates andbecomes an alumni. Generation relationships express the gen-eration of entities by others, e.g., a land parcel may be splitinto several smaller parcels. Timing relationships describetemporal relations between entities, e.g., before or after.For example, a Storm may precede a Landslide. Finally,Time-based aggregations link entities to their snapshots, thatis, the composite entity type is temporal while the compo-nent (the snapshot) is not. For further description of thedynamic relationship types, see [39].

There are three kinds of traditional relationship types,each of which is illustrated in Fig. 24 and is explained next:

1)� Is-a Relationships. These are represented by linkingtwo entity types with a solid line, with an arrow

Fig. 25. The static cardinality constraints for attributes and relation-ship types.

Fig. 26. Transforming temporal attributes to ERC+ diagrams [39].


pointing from the subclass to the superclass. In an is-arelationship, the instances of the subclass representthe same real-world instances as the instances ofthe superclass. In Fig. 24, Manager is a subclass ofEmployee.

Inheritance of attributes and temporal specifica-tions are supported. Thus instances of the subclasshave the same attributes and temporal support as theinstances of the superclass, in addition to the attrib-utes specified for the subclass. A subclass cannot benontemporal if the superclass is temporal.

2) Relationship Types. These are relationships betweenentity types and are represented by linking the par-ticipating entity types to a rectangle with roundedcorners. The lines linking the entity types and the re-lationship type express the static participation con-straints that apply, as discussed for attributes. n-aryrelationship types are allowed.

Relationship types can be specified as temporal,and the instances of temporal relationship types areassociated with a life cycle in the same manner as in-stances of temporal entity types. For temporal rela-tionship types, as for temporal attributes, a temporalcardinality may be specified for each entity type par-ticipating in the relationship type, stating how manyrelationships an entity is allowed to participate induring the life cycle of the entity. For example, theh(10) in Fig. 24 is limiting the number of projects anemployee can work on over his/her employment to10. Only temporal entity types can participate in tem-poral relationship types. The meaning of a temporalrelationship type is captured in the same manner asfor temporal entity types.

3) Aggregation Links. These are special, directed binaryrelationships linking two entity types, also known aspart-of relationships. Aggregation links are repre-sented by linking the component entity type to a rela-tionship type with an arrow pointing towards the

component entity type, and the usual participationconstraint linking the composite entity type to the re-lationship type. To further indicate that the relation-ship type is an aggregation link, the relationship typeis marked with a small diamond. In Fig. 24, the rela-tionship type Responsible_for is an aggregation link.

Aggregation links can be specified as temporal;and as for temporal relationship types, only temporalentity types can participate in temporal aggrega-tion links.

2.11.3 SummaryTERC+ provides the database designer with new modelingconstructs for describing temporal attributes, temporal en-tities, and temporal relationships. Furthermore, TERC+provides notation for describing interobject behavior.

3 DESIGN CRITERIA AND EVALUATION OF THEMODELS

In Section 2.3 to Section 2.11, we described all temporal ERmodels known to us. It is a common characteristic that fewor no specific requirements to the models were given bytheir designers. To compare and better understand themodels, this section defines a comprehensive set of designcriteria for temporal ER models and evaluates the modelsagainst these criteria. We have chosen to also evaluate theEER model against the criteria. When doing so, the modelwill be treated as a temporal model, capturing time throughtimestamp attributes.

We have identified a total of 19 design criteria coveringtime semantics, model semantics, temporal functionality,and user-friendliness. The criteria are numbered C1 to C19.With each criterion defined, we indicate its source, if possi-ble. We have attempted to only include criteria that have anobjective basis for being evaluated. Together, the criteriaidentify important aspects of designing a temporal ER model.The possible outcomes of an evaluation of a model with

Fig. 27. Transforming temporal entity and relationship types to ERC+ diagrams [39].


respect to each criterion will be stated explicit together withthe definition of each criterion, unless the possible out-comes are N.A., Yes, and No.

Fig. 28, Fig. 29, and Fig. 30 present the results of theevaluations of evaluating the models with respect to criteriaC1–C3, C4–C13, and C14–C19, respectively. (This groupingof the criteria into three tables is purely pragmatic.)

C1—Time Dimensions With Built-In Support. Valid andtransaction time are general—rather than application spe-cific—aspects of all database facts. As such, they are primecandidates for being built into a temporal ER model that isto be used for both analysis and database design. Beingorthogonal and independent aspects of database facts, it ispossible to support the two times independently. Supportfor these times may take different shapes and may be more

or less elaborate. Another kind of time exists, namely theso-called user-defined time (UDT). This refers to “support”for temporal aspects with no built-in support in the model.User-defined times are supported when time-valued attrib-utes are available. These are then employed for giving tem-poral semantics—not captured in data model, but only ex-ternally, by the database designer—to the the ER diagrams.We will say that a time is supported simply if some supporthas been documented. The possible outcomes of evaluatinga model against this criterion are UDT, VT, TT, and N.A.(and combinations of VT and TT).

For a model to be considered temporal, at least one timedimension must be supported. Almost all the models sup-port valid time. The only model that does not is the EERmodel that only supports user-defined time. All the models

Fig. 28. Evaluation of criteria C1, C2, and C3.

Fig. 29. Evaluation of criteria C4 to C13.

Fig. 30. Evaluation of criteria C14 to C19.


support user-defined time. Transaction time is supported byonly TempEER. That is, the valid-time aspect of a databaseapplication seems to be regarded as the most interestingaspect to support, thereby aiming at high-fidelity modelingof the miniworld.

C2—New Temporal Constructs. Two general approaches toproviding temporal support exist. With implicit temporalsupport, explicit timestamp attributes are “hidden” in thetemporal semantics of the modeling constructs. For exam-ple, no timestamp attributes are necessary on a temporalrelationship type to indicate that the instances of the typerecord their variation over time. With this approach, it ispossible to obtain a temporal ER model without adding anynew syntactical constructs to the ER model. Rather, the ex-isting ER constructs are simply made temporal by changingtheir semantics. For example, ordinary relationship typesare given temporal semantics, making their instances rec-ord variation over time, rather than just single states. It isalso possible with this approach to retain the existing ERconstructs and their semantics and add new temporal con-structs to capture the time-varying information. The newnotation for a temporal relationship type in MOTAR is anexample. The extent of the changes made to the ER modelmay range from minor changes to a total redefinition ofthe model.

With explicit temporal support, the semantics of the ex-isting ER constructs are retained. With this approach, time-stamp attributes are explicit. Any new modeling constructsare notational shorthands introduced to make the modelingof temporal aspects more convenient.

Nearly all the models have added new temporal con-structs. Some of the models have changed the semantics ofthe ordinary ER model constructs entirely. These modelsare TEER and TempEER. Other models have retained theold ER constructs and have added new temporal con-structs. These models include TERM, MOTAR, ERT, TER,TempRT, and TERC+. RAKE does not add any new con-structs to the ER model; instead, it introduces notationalshorthands for certain patterns made up of ordinary ERconstructs. However, we will consider these notationalshorthands to be temporal constructs. One model has bothchanged the semantics of the ER constructs and added newtemporal constructs, namely STEER. The specific namesof the added constructs can be seen in the third column ofFig. 28 (they are mentioned in the order in which they areintroduced in this paper). The EER model has not addedany new constructs—it captures time solely through time-stamp attributes.

C3—Mandatory vs. Optional Use of Temporal Constructs.The extent of changes made to the notation of the ER modeldetermines whether the use of the temporal constructsadded to the model are mandatory or optional. If all theoriginal ER modeling constructs have simply been madetemporal, the original constructs are no longer available.Mandatory use of the temporal constructs means that thedesigner cannot use nontemporal constructs in diagrams.Optional use of the temporal constructs provides the desig-ner with the possibility of mixing temporal and nontemporal

constructs in the same diagram. The possible outcomes ofevaluating the models against this criterion are N.A., Man-datory, and Optional.

The models with mandatory use of the temporal con-structs are TEER, STEER, TempEER, and TER. TEER andTempEER have changed the semantics of all the original ERmodel constructs to be temporal. STEER has—besidesmaking the original ER constructs temporal—added newtemporal constructs to the model. Since TER has replacedthe ordinary cardinality constraints with two new ones, andit is mandatory to specify the constraints, it becomes man-datory to use the temporal constructs, even if the users laterdecide to only record a single state of data.

The models that have retained the ordinary ER con-structs and have added new temporal construct have op-tional use of temporal constructs. Thus, it is possible to mixtemporal and nontemporal constructs in these models thatinclude MOTAR, ERT, TempRT, and TERC+. TERM hasoptional use of history structures and history patterns sinceall attributes (inclusive the existence and roles attributes)can be declared as constant. RAKE also has optional use ofthe temporal constructs since these are notational short-hands for patterns made up of ordinary ER constructs.Since the EER model has not added new constructs, N.A. isthe result of evaluating the model against this criterion.

C4—Data Types Supported for Valid Time. Different datatypes for implicit or explicit timestamps may be used forindicating the valid time of an object, e.g., an attribute valueor a relationship. Possible time data types include instants,intervals, and temporal elements. For example, one optionis to associate valid-time intervals with attribute values ofentities. Another option is to timestamp attribute valueswith valid-time elements, finite unions of intervals. An at-tribute value may also be defined as a function from a timedomain to a value domain. In this way, an attribute mayassociate a value with a set of time instants. We will con-sider this element timestamping, and we will also considerthe timestamping with sets of instants and intervals as be-ing element timestamping. Since all models surveyed adopta discrete model of time, we will not distinguish betweensupport for closed versus open or half-open intervals.

A data model may provide the database designer with achoice of data types. This may increase the utility of themodel. Possible outcomes include N.A., instant, interval,and temporal element. All three data types mentioned mayencode validity for durations, and the instant data typemay also encode validity for single instants of time. In theformer case, instants have associated interpolation func-tions (see Criterion C8). The impact of which data types areavailable is dependent on whether the model under consid-eration is used solely as a design model or is also used as animplementation model, complete with database instancesand a query language.

The models that timestamp with instants include RAKE(events), TERM, MOTAR, and TER. The models RAKE,TERM, ERT, TempEER, and TempRT timestamp with inter-vals. The models TEER, STEER, and TERC+ timestamp withtemporal elements. Finally, this criterion is not applicable tothe EER model, since it does not support valid time.


C5—Data Types Supported for Transaction Time. As validand transaction time have different semantics, the time-stamp types available for the two times may differ. Thepossible outcomes are as for valid time. TempEER is theonly model that supports transaction time. The timestampused for transaction time in TempEER is instants (that en-code durations). N.A. is indicated in the figure for all theother models.

C6—Support for Multiple Granularities. It may be that thetemporal variability of different objects in the miniworldare captured using times of different granularities [38], [6].They should then also be captured in the database usingthese different granularities. For example, the granularity ofa minute may be used when recording the actual workinghours of employees, while the granularity of a day may beused when recording the department assignments of em-ployees. Notice that this criterion relates to valid time.

There are three models in which it is possible, at theconceptual level, to specify the granularity of the time-stamps. In MOTAR, the user is allowed to specify the fre-quency of the recording of periodic attributes. In TERM,atomic histories can have different time domains. InTERC+ the authors state that the granularity of time-stamps has to be specified but does not explain how this isdone. The rest of the models only briefly state that thegranularity of the timestamps should be suitable for spe-cific applications and hence postpone the choice ofgranularity to the logical design phase.

C7—Support for Temporal (Im-) Precision. The temporalvariability of different objects in the miniworld may beknown with different precisions [18], [4], [7], [5]. Althoughsome imprecision may be captured using multiple granu-larities, granularities are not a general solution. For exam-ple, the variability of an attribute may be recorded usingtimestamps with the granularity of a second, but the vary-ing values may only be known to the precision of ±5 secs ofthe recorded value. This phenomenon may be prevalentand important to capture in scientific and monitoring ap-plications that store measurements made by instruments.

The only model which support temporal precision isTERM, where it is possible to specify precision on the time-stamps (and also the values of attributes).

C8—Temporal Interpolation Functions. Temporal inter-polation functions derive information about times forwhich no data is explicitly stored in the database (see, e.g.,[18] and (pp. 35–40 of [17]). For example, it is possible torecord times when new salaries of employees take effectand then define an interpolation function (using so-calledstep-wise constant interpolation) that gives the salaries ofemployees at any time during their employment. In thescientific domain, interpolation is particularly important,e.g., when variables are sampled at different rates.

User-definable temporal interpolation functions are sup-ported by TERM, MOTAR, and ERT. In TERM, functionshandle both incomplete and not-explicitly-stored data,while the derivation functions in ERT only handle data notexplicitly stored. In MOTAR, rules can be considered as

some sort of derivation functions. The other models do notconsider how to handle incomplete and not-explicitly-stored data.

C9—Lifespans of Entities. The lifespan of an entity is thetime over which the entity exists in the miniworld. Entitiesmay exist beyond the times when their attributes have(nonnull) values, making it impossible to infer lifespansfrom the assignments of timestamps to attribute values. Ifthe concept of lifespan of entities is supported, this meansthat the model has built-in support for capturing the timeswhen entities exist.

Five models support the concept of lifespan for all entitytypes, namely TERM, RAKE, TEER, ERT, and TempEER.The lifespans for the entity types with constant existence inTERM and the lifespans for nontimestamped entity types inERT are given implicitly as the lifespan of the database.Some models support selective specification of lifespans ofentity types, indicated by an Yes+, thus letting the databasedesigner decide whether or not to capture the lifespan of anentity type. These models are STEER, TempRT, and TERC+.The models that do not support lifespans of entity typesinclude MOTAR, TER, and EER.

C10—Lifespans of Relationships. The concept of lifespanis also applicable to relationships, with the same meaningas for entities. When a model provides a built-in notion ofrelationship lifespans, it may also enforce certain temporalconstraints that involve these lifespans. For example, itdoes not make sense for an entity to have an attribute valueat a time when the entity does not exist.

The models that support lifespans for all relationshiptypes include TERM, TEER, ERT, and TempEER. STEER,TempRT, and TERC+ support selective specification oflifespan of relationship types—for these, a Yes+ is indi-cated. The models that do not support lifespans of Relation-ship types include RAKE, MOTAR, TER, and EER.

C11—Temporal Constraints. A temporal data model mayinclude built-in temporal constraints and facilities for user-definable temporal constraints. If built-in temporal con-straints are not present, then the possibility of having illegaldata is present. For example, a (binary) relationship be-tween two entities can usually not exist if the entities do notexist. The presence of an appropriate set of (built-in) con-straints on the built-in temporal constructs is thus of es-sence. Next, it should be possible for the database designerto specify additional temporal constraints. For example, wehave seen that the TER model (Section 2.8) supports twotypes of temporal constraints on relationship types, namelysnapshot and lifetime cardinality constraints.

Temporal constraints are supported by TERM, TEER,ERT, STEER, TER, TempEER, and TERC+ while the modelsRAKE, MOTAR, TempRT, and EER do not support tempo-ral constraints.

C12—User-Specifiable Temporal Support. A temporal ERmodel offers user-specifiable temporal support if it is up tothe database designer to decide which temporal aspects ofdata to capture. For example, a temporal ER model mayprovide built-in support for both valid and transaction


time, but a specific application may only require supportfor transaction time. It should then be possible to omit sup-port for valid time.

The models RAKE, MOTAR, ERT, TempRT, and TERC+partly satisfy this criterion. In RAKE, MOTAR, ERT,TempRT, and TERC+ the temporal support is valid time,but only if the database designer uses the temporal con-structs of the models. So does TER, but not at the concep-tual level—only when translating the TER diagram to ERdiagrams. If the designer wants to record the variations ofdata, the temporal dimension supported is valid time; andif no access is wanted, no temporal support is given. Thiscriterion is not applicable to the EER model which supportsonly user-defined-time. The remaining models have en-forced temporal support.

C13—Upward Compatibility. A temporal ER model is up-ward compatible with respect to the conventional ER modelif any legal conventional ER diagram is also a legal ER dia-gram in the temporal model and if the meanings of the dia-gram in the two models is the same. Upward compatibilityis very important because it enables legacy ER diagrams tobe used immediately in the new temporal model. Invest-ments in legacy systems are protected, and a basis for asmooth transition to a temporally enhanced ER model isprovided [32].

When evaluating a model against this criterion, we willevaluate whether the model is upward compatible withrespect to the ER model that it extends, if specified; other-wise, we will use Chen’s ER model [2] for models withoutsuperclass/subclass relationships and the EER model [10]for models with superclass/subclass relationships.

Six models—RAKE, MOTAR, ERT, TempRT, and TERC+—are upward compatible with respect to their basic mod-els. In these models, no syntactical constructs from the basicmodels have been given new semantics. The EER is alsoupward compatible with itself; this holds trivially true.TERM is not upward compatible since its existence attrib-utes have to be specified for all entity and relationshiptypes. TEER and TempEER are not upward compatible withrespect to the EER model because these models havechanged the semantics of the existing EER modeling con-structs. STEER has both changed the semantics of the origi-nal model and added new syntactical constructs. Due to thechange of semantics of the original model, STEER is notupward compatible with the EER model. TER is not up-ward compatible with the ER model since it has replacedthe ordinary cardinality constraints with the snapshot andlifetime cardinality constraints.

C14—Snapshot Reducibility of Attribute Types. TemporalER models that add temporal support implicitly may in-clude temporal counterparts of the ordinary attribute types,i.e., provide temporal single valued, temporal multivalued,temporal composite, and temporal derived attribute types.These temporal attribute types may be snapshot reducible[28] with respect to their corresponding snapshot attributetypes. This occurs if snapshots of the databases describedusing the temporal ER diagram constructs are the same asdatabases described by the corresponding snapshot ER

diagram where all temporal constructs are replaced by theirsnapshot counterparts. For example, a temporal single-valued attribute is snapshot reducible to a snapshot single-valued attribute if the temporal single-valued attribute issingle valued at each point in time.

Generalizing snapshot constructs this way yields a natu-ral temporal model that is easily understood in terms of theconventional ER model.

The models that have snapshot reducible attribute typesare RAKE, TERM, MOTAR, TEER, STEER, TempEER,TempRT, and TERC+. RAKE has only single-valued attrib-ute types. These are snapshot reducible since the temporalattributes are modeled through relationships treated asweak entity types owned by time-period entity types,thereby having ENDstamp as part of the key. This structurecannot have more than one value at any point in time.TERM has only single-valued attributes, and all variableattributes have a atomic history structure to ensure that theattribute only have one value at a time. The temporal at-tributes of MOTAR are also snapshot reducible since themapping algorithm ensures that timestamps are made partof the key in the relations representing the attributes. TEER,STEER, TempEER, and TERC+ all have temporal single-valued, multivalued, and composite attribute types. TEER,STEER, and TempEER have the mutually same semanticsfor these attribute types, and the semantics state that theyare snapshot reducible. The semantics of the static cardi-nality constraints for TERC+ ensure that the attributes ofthis model are snapshot reducible. TempRT only has single-valued attribute types, and since the temporal attributes ofthis model are defined using the temporal relationship thatis snapshot reducible, see the next criterion, the temporalattributes must be snapshot reducible. Because ERT, TER,and EER do not have temporal attributes, this concept isinapplicable to these models.

C15—Snapshot Reducibility of Relationship Constraints.Snapshot reducibility also applies to the various constraintsthat may be defined on relationship types, includingspecialized relationship types such as ISA (superclass/subclass) and PART-OF (composite/component) rela-tionships. For example, the temporal cardinality constraint1 – N on a binary temporal relationship type is snapshotreducible to the snapshot cardinality constraint 1 – N on abinary snapshot relationship type if at any single point intime, the 1 – N snapshot constraint applies to the possibleinstances of the temporal relationship type.

Only four models have snapshot reducible relationshipconstraints:

1)�TER, by virtue of the semantics of the snapshot cardi-nality constraint;

2)�TempRT, due to the semantics given to its temporalrelationships (these semantics explicit states that thecardinality constraints given by the relationshipshould hold at any point in time);

3)�TERC+, by the semantics which explicit state that thestatic cardinality constraints hold at any point in time;and

4)�EER, trivially, because it does not propose any addi-tional types of relationships and constraints.


The models RAKE, TERM, MOTAR, TEER, ERT, andTempEER do not describe what the meaning of the differ-ent relationship constraints that can be specified are in atemporal database. This is the reason for the questionmarks in Column C15 of Fig. 30. The STEER model does notinclude cardinality constraints on relationship types, mak-ing this criterion inapplicable.

C16—Mapping Algorithms Available. A mapping algo-rithm translates an arbitrary ER diagram in a temporal ERmodel into a corresponding database schema in anotherdata model. The temporal ER models are typically consid-ered to be design models. Upon designing an ER diagram,the diagram is accordingly mapped to a schema of anavailable DBMS, i.e., is mapped to an implementationplatform. The most popular type of mapping is to the re-lational model (or the platform of a specific relationalproduct). The benefit of a mapping algorithm for a tempo-rally extended ER model to the relational model is that asingle mapping algorithm controls the resulting relationaldatabase schema. As an alternative, it is also possible tomap temporal ER diagrams to conventional ER diagrams.The benefit of this approach is that the wide selection ofmappings from the conventional ER model to the rela-tional model may be exploited.

Most of the models provide mappings to regular ER dia-grams or the relational model. The only model where tem-poral ER diagrams can be mapped into both ER diagramsand the relational model is RAKE. The TER model providean algorithm that transforms TER diagrams into ER dia-grams, which may then be transformed into relationalschemas by a standard algorithm. It is demonstrated how totransform TERC+ diagrams into ERC+ diagrams. The mod-els that provide an algorithm for translation into a rela-tional schema include MOTAR, ERT, and TempEER. modelsTERM, TEER, STEER, and TempRT do not specify anymappings of their diagrams. One good reason for an ab-sence of mappings is that the models themselves may beconsidered implementation models, see the discussion ofthe next criterion.

C17—Query Language Provided. As an alternative tomapping ER diagrams to the schema of a separate imple-mentation platform, another approach is to assume a sys-tem that implements the ER model directly. With this ap-proach a mapping to an implementation platform is notrequired. Instead, a query language should be available forquerying ER databases.

No query languages is provided for the followingmodels: RAKE, TERM, MOTAR, TER, TempRT, andTERC+. A temporal extension of the query languageGORDAS is provided as query language for the modelsTEER and STEER. The ERT model is provides with aquery language called the External Rule Language. Asquery language for the TempEER model, a temporal ex-tension of SQL is proposed.

C18—Graphical Notation Provided. While it is usuallyassumed that a graphical notation is available for describ-ing ER diagrams, this needs not be so. It is also possible to

provide only a textual notation for describing ER diagrams.It is generally believed that ER models with a graphicalnotation have an advantage over ER models with a pro-gramming language-like notation. Graphical notations tendto be easier to learn, and we believe that the simplicity ofthe graphical ER notation is one of the main reasons forits success.

The only model that does not have a graphical notationis the TERM model, which has a Pascal-like syntax.

C19—Graphical Editor Available. If the notation of amodel is graphical, then the presence of an editor support-ing the model is very important if the model is to beused widely. Potential users should have the opportunity totry and use at least some prototype of an editor supportingthe model.

Two models, namely TER and ERT, come with aneditor to support their use. The editor for TER is calledMODELLER [33] and is a commercially available product;and the editor for ERT is called the ERT-TOOL. Theauthors of the TERC+ model states that an editor forthe model is currently under development and for thisreason Yes in parentheses has been indicated for thismodel. Models TEER and TempEER can use editors thatsupports the EER model for schema design, but not formapping to their implementation models. Thus, a Yes inparentheses has been indicated for these models. Editorsfor EER exist in the public domain. No other model is ac-companied by an editor.

4 CONCLUSIONS AND RESEARCH DIRECTIONS

This section first concludes on the paper, then discussesresearch directions.

4.1 ConclusionsThis paper has surveyed ten proposals for extending the ERmodel to better capture the temporal aspects of data. Al-though the detailed motivation for the development of eachproposal varies, it is a general observation that while tem-poral aspects of data are prevalent, the basic ER (and EER)model in itself does not provide adequate support for ele-gantly and concisely capturing these aspects.

The survey has emphasized the common aspect of thetemporal ER models, namely their use as design modelsthat are employed to capture, in a conceptual model, a da-tabase design that is implemented in a separate data model,typically the relational model. This yields a focus on struc-tural aspects, rather than on ER query languages.

The proposed extensions are based on quite differentapproaches. One approach is to devise new notationalshorthands that replace some of the patterns that occur fre-quently in ER diagrams when temporal aspects are beingmodeled. One example is the pattern that occurs whenmodeling a time-varying attribute in the ER model. An-other approach is to change the semantics of the existingER model constructs, making them temporal. In its ex-treme form, this approach does not result in any newsyntactical constructs—all the original constructs have


simply become temporal. With this approach, it is alsopossible to add new constructs. Yet another approach is toretain the existing ER constructs.

Many of the models assume that their schemas aremapped to schemas in the relational model that serves asthe implementation platform. The algorithms that map theschemas of these models to the relational model are con-structed to add appropriate time-valued attributes to therelation schemas. This corresponds to how the ER model is(currently) used in industry. In contrast, three of the modelswe have examined are themselves implementation modelsand provide a query language for the model.

We have identified a total of 19 design properties that arerelevant for the evaluation of temporal ER models andshould be taken into consideration when designing a tem-poral ER model. None of the 19 design properties are in-compatible—they can all be simultaneously fulfilled. Wehave evaluated the 10 models against the design properties,and while no single model satisfies all the properties, themodels collectively provide good coverage of the designspace. The models illustrate different ways of conven-iently capturing the temporal aspects of data at the con-ceptual level, and it is our contention that all the temporalER models, to varying degrees, have succeeded in morenaturally capturing the temporal aspects of data than doesthe ER model.

In our work with the models, we have come to the con-clusion that the approach where all existing ER model con-structs are given a temporal semantics is attractive. Thedatabase designers are likely to be familiar with the existingER constructs. So, upon understanding the principle atwork when making these constructs temporal, the design-ers are ready to work with, and benefit from using, thetemporal ER model. However, this approach is not totallywithout problems. This approach rules out the possibility ofdesigning nontemporal databases or databases where somepart of a database is nontemporal and the rest is temporal.Another problem is that old (legacy) ER diagrams becomeinvalid when introducing the temporal ER model—whiletheir syntax is valid, their semantics have changed, andthey therefore no longer describe the existing relationaldatabase schemas.

The models that retain the existing constructs with theirold semantics and introduce new temporal constructs havetheir problems and advantages. If their extensions are com-prehensive, they are likely to be more difficult for the data-base designers to learn and understand. The larger initialinvestment in training that this induces may prevent amodel from being accepted in industry. On the other hand,since the semantics of the existing ER constructs are re-tained with this approach, the models following this ap-proach avoid the problem of legacy diagrams that, withtheir new semantics, no longer describe the existing rela-tional database. This is important for industrial users withmany legacy diagrams. It is also possible to design non-temporal databases as well as databases where some partsare nontemporal and others are temporal.

As stated, most of the models rely on another datamodel as an implementation model: their schemas are

mapped to schemas in these other models, and it is theseother schemas that are subsequently populated and que-ried. The relational model is the implementation modelof choice. Temporal ER diagrams are either mapped torelation schemas directly, or they are mapped to regular ERdiagrams that are then mapped to relation schemas. Thetime-valued attributes that result from mapping ER dia-grams to relation schemas are not interpreted by the rela-tional model, i.e., they have no built-in semantics in therelational model. As a result, queries on time-varying dataare often hard to formulate in SQL [31].

None of the models have one of the many time-extendedrelational models proposed [29] as their implementationmodel. The temporal relational models have data-definitionand query-language capabilities that better support themanagement of temporal data and would thus constitutenatural candidate implementation platforms.

4.2 Research DirectionsA number of topics are the subjects of ongoing research orare candidates for future research.

First, the set of criteria is not necessarily complete, and itmay be feasible to include additional criteria for evaluatingand comparing temporal ER models. This indicates that ataxonomy of evaluation criteria that charts the design spaceof temporal extensions and thus may be used for indicatingareas with missing criteria would be very desirable. Withsuch a taxonomy, it becomes possible to ensure that weevaluate all important properties of temporally extendedER models.

Second, most of the criteria may be applied to exten-sions of the ER model other than temporal ones. In thispaper we have described the criteria in the specific contextof temporal extensions for concreteness. It is an interestingnext step to explore the application of the criteria to othertypes of ER extensions, such as spatial [15], spatio-temporal, multimedia, or security ER models. Anotherpromising direction deserving attention is the applicationof the criteria to extensions of modeling notations otherthan the ER model.

Third, the systematic use of the criteria for the design ofa temporally extended ER model is a very relevant re-search direction. We recommend that designers of futuretemporally extended ER models consciously considertheir ER extension with respect to each criterion. The idealtemporal ER model is easy to understand in terms of theER model; does not invalidate legacy diagrams and data-base applications; and does not restrict database to betemporal, but rather permits the designer to mix temporaland nontemporal parts.

Fourth, since most DBMSs used in industry are rela-tional, temporal ER models should ideally include map-pings to several implementation platforms: the relationalmodel (in the various dialects of the different DBMS prod-ucts), temporal relational models, and emerging models(e.g., SQL3). It is a challenge of high practical relevance todesign mappings that maximally exploit these and othercandidate implementation platforms.


Fifth, we believe that it would be of interest to design a“standard” textual representation of different types of ERdiagrams. This representation could serve a as a middleform: ER-model designers could provide mappings to thisrepresentation, while others could independently providemappings to the various implementation platforms in use.

ACKNOWLEDGMENTS

This work was supported by Grants 9701406 and 9502695from the Danish Natural Science Council and the DanishTechnical Research Council, respectively; and by a grantfrom the Nykredit Corporation.

REFERENCES

[1]� S. Ceri, S.B. Navathe, and C. Batini, Conceptual Database Design, AnEntity-Relationship Approach, Benjamin/Cummings, 1992.

[2]� P.P.-S. Chen, “The Entity-Relationship Model£Toward a UnifiedView of Data,” ACM Trans. Database Systems, vol. 1, no. 1, pp. 9–36, Mar. 1976.

[3]� C.J. Date, An Introduction to Database Systems, vol. I, Systems Pro-gramming Series, fifth ed., Addison-Wesley, 1990.

[4]� C.E. Dyreson and R.T. Snodgrass, “Valid-Time Indeterminacy,”Proc. Ninth Int’l Conf. Data Eng., pp. 335–343, 1993.

[5]� C.E. Dyreson and R.T. Snodgrass, “Temporal Granularity andIndeterminacy: Two Sides of the Same Coin,” Technical Report TR94-06, Univ. of Arizona, Dept. of Computer Science, Feb. 1994.

[6]� C.E. Dyreson and R.T. Snodgrass, “Temporal Granularity,” R.T.Snodgrass, ed., TSQL2 Temporal Query Language, ch. 19, pp. 347–383, Kluwer, 1995.

[7]� C.E. Dyreson and R.T. Snodgrass, “Temporal Indeterminacy,” R.T.Snodgrass, ed., TSQL2 Temporal Query Language, ch. 18, pp. 327–346, Kluwer, 1995.

[8]� R. Elmasri, I. El-Assal, and V. Kouramajian, “Semantics of Tempo-ral Data in an Extended ER Model,” Proc. Ninth Int’l Conf. Entity-Relationship Approach, pp. 239–254, Oct. 1990.

[9]� R. Elmasri and V. Kouramajian, “A Temporal Query Language fora Conceptual Model,” N.R. Adam and B.K. Bhargava, eds., Ad-vanced Database Systems, Lecture Notes in Computer Science 759,ch. 9, pp. 175–195, Berlin: Springer-Verlag, 1993.

[10]� R. Elmasri and S.B. Navathe, Fundamentals of Database Systems.Benjamin/Cummings, second ed., 1994.

[11]� R. Elmasri, G. Wuu, and V. Kouramajian, “A Temporal Modeland Query Language for EER Databases,” A. Tansel et al., eds.,Temporal Databases: Theory, Design, and Implementation, ch. 9, pp.212–229, Database Systems and Applications Series, Benjamin/Cummings, 1993.

[12]� R. Elmasri and G.T.J. Wuu, “A Temporal Model and Query Lan-guage for ER databases,” Proc. Sixth Int’l Conf. Data Eng., pp. 76–83, 1990.

[13]� S. Ferg, “Modeling the Time Dimension in an Entity-RelationshipDiagram,” Proc. Fourth Int’l Conf. Entity-Relationship Approach,pp. 280–286, 1985.

[14]� S.K. Gadia and C.S. Yeung, “A Generalized Model for a RelationalTemporal Database,” Proc. ACM SIGMOD Int’l Conf. Managementof Data, pp. 251–259, June 1988.

[15]� T. Hadzilacos and N. Tryfona, “An Extended Entity-RelationshipModel for Geographic Applications,” technical report, ComputerTechnology Inst., Greece, 1996.

[16]� “A Glossary of Temporal Database Concepts,” C.S. Jensen, J. Clif-ford, R. Elmasri, S.K. Gadia, P. Hayes, and S. Jajodia, eds., ACMSIGMOD Record, vol. 23, no. 1, pp. 52–64, Mar. 1994.

[17]� C.S. Jensen and R.T. Snodgrass, “Semantics of Time-Varying In-formation,” Information Systems, vol. 21, no. 4, pp. 311–352, 1996.

[18]� M.R. Klopprogge, “TERM: An Approach to Include the TimeDimension in the Entity-Relationship Model,” Proc. Second Int’lConf. Entity Relationship Approach, pp. 477–512, Oct. 1981.

[19]� M.R. Klopprogge and P.C. Lockeman, “Modeling InformationPreserving Databases: Consequences of the Concept of Time,”Proc. Ninth Int’l Conf. Very Large Data Bases, pp. 399–416, Oct. 1983.

[20]� P. Kraft, “Temporale Kvaliteter i ER Modeller. Hvordan?”, work-ing paper 93, Dept. of Information Science, Aarhus School ofBusiness, Jan. 1996.

[21]� V.S. Lai, J-P. Kuilboer, and J.L. Guynes, “Temporal Databases:Model Design and Commercialization Prospects,” DATA BASE,vol. 25, no. 3, pp. 6–18, 1994.

[22]� P. McBrien, A.H. Seltveit, and B. Wangler, “An Entity-Relationship Model Extended to Describe Historical Informa-tion,” Proc. Int’l Conf. Information Systems and Management of Data,pp. 244–260, July 1992.

[23]� E. McKenzie and R. Snodgrass, “An Evaluation of RelationalAlgebras Incorporating the Time Dimension in Databases,” ACMComputing Survey, vol. 23, no. 4, pp. 501–543, Dec. 1991.

[24]� A. Narasimhalu, “A Data Model for Object-Oriented Databaseswith Temporal Attributes and Relationships,” technical report,National Univ. of Singapore, 1988.

[25]� C. Parent and S. Spaccapietra, “ERC+: An Object-Based EntityRelationship Model,” P. Loucopoulos and R. Zicari, eds., Concep-tual Modeling, Databases, and CASE, ch. 3, pp. 69–86, John Wiley &Sons, 1992.

[26]� J.F. Roddick and J.D. Patrick, “Temporal Semantics in InformationSystems£A Survey,” Information Systems, vol. 17, no. 3, pp. 249–267, Oct. 1992.

[27]� A. Silberschatz, H.F. Korth, and S. Sudarshan, Database SystemConcepts, third ed., McGraw-Hill, 1996.

[28]� R.T. Snodgrass, “The Temporal Query Language TQUEL,” ACMTrans. Database Systems, vol. 12, no. 2, pp. 247–298, June 1987.

[29]� R.T. Snodgrass, “Temporal Databases,” A.U. Frank, I. Campari,and U. Formanti, eds., Theories and Methods of Spatio-Temporal Rea-soning in Geographic Space, pp. 22–64, Lecture Notes in ComputerScience 639, Springer-Verlag, 1992.

[30]� R.T. Snodgrass, “Temporal Object Oriented Databases: A CriticalComparison,” W. Kim, ed., Modern Database Systems: The ObjectModel, Interoperability, and Beyond, ch. 19, pp. 386–408, Addison-Wesley/ACM Press, 1995.

[31]� R.T. Snodgrass, I. Ahn, G. Ariav, D.S. Batory, J. Clifford, C.E.Dyreson, R. Elmasri, F. Grandi, C.S. Jensen, W. Kafer, N. Kline,K. Kulkanri, T.Y.C. Leung, N. Lorentzos, J.F. Roddick, A. Segev,M.D. Soo, and S.M. Sripada, TSQL2 Temporal Query Language,Kluwer, 1995.

[32]� R.T. Snodgrass, Böhlen M., C.S. Jensen, and A. Steiner, “ChangeProposal to SQL/Temporal: Adding Valid Time” Part A, O.Etzion, S. Jajodia, and S. Sripada, eds., Temporal Databases: Researchand Practice, pp. 150–194, Lecture Notes in Computer Science1,399, Springer-Verlag, 1998.

[33]� B. Tauzovich, “Toward Temporal Extensions to the Entity-Relationship Model,” Proc. 10th Int’l Conf. Entity Relationship Ap-proach, pp. 163–179, Oct. 1991.

[34]� T.J. Teorey, Database Modeling and Design, Data Management Sys-tems Series, Morgan Kaufmann, 1990.

[35]� C. Theodoulidis, B. Wangler, and P. Loucopoulos, “The EntityRelationship Time Model,” Conceptual Modelling, Databases, andCASE: An Integrated View of Information Systems Development, ch. 4,pp. 87–115, John Wiley & Sons, 1992.

[36]� C.I. Theodoulidis and P. Loucopoulos, “The Time Dimension inConceptual Modelling,” Information Systems, vol. 16, no. 3, pp.273–300, 1991.

[37]� C.I. Theodoulidis, P. Loucopoulos, and B. Wangler, “A ConceptualModelling Formalism for Temporal Database Applications,” In-formation Systems, vol. 16, no. 4, pp. 401–416, 1991.

[38]� G. Wiederhold, S. Jajodia, and W. Litwin, “Dealing with Granu-larity of Time in Temporal Databases,” R. Anderson et al., eds.,Proc. Third Int’l Conf. Advanced Information Systems Eng., LectureNotes in Computer Science 498, Springer Verlag, 1991.

[39]� E. Zimanyi, C. Parent, S. Spaccapietra, and A. Pirotte, “TERC+: ATemporal Conceptual Model,” Proc. Int’l Symp. Digital Media In-formation Base, Nov. 1997.


Heidi Gregersen received her BSc degree incomputer science and mathematics, and theMSc and PhD degrees in computer science in1993, 1995, and 1999, respectively£all fromAalborg University in Denmark. She is currentlyan assistant professor in the Department ofComputer Science at Aalborg University. Herresearch interests include data modeling andtemporal databases, with emphasis on designof temporal databases at the conceptual andlogical levels.

Christian S. Jensen is a research professor ofcomputer science at Aalborg University, wherehe directs the Nykredit Center for Database Re-search. He has been with the University of Ari-zona during four sabbaticals and, prior to joiningAalborg University, he conducted his graduatestudies at the University of Maryland. His re-search interests are in the areas of databasesystems, and include issues of semantics, mod-eling, and performance. With his colleagues, hereceives substantial national and international

funding for his research. He is a member of the Editorial Boards ofIEEE Transactions on Knowledge and Data Engineering and the ACMSIGMOD Digital Review; was general chair of the 1995 InternationalWorkshop on Temporal Databases, and a vice program committeechair and best-paper awards committee member for the 1998 IEEEInternational Conference on Data Engineering; and is co-programcommittee chair of the 1999 Workshop on Spatio-Temporal DatabaseManagement, held in conjunction with VLDB 99. He continues to serveon the program committee and other committees for a number of con-ferences, including ACM SIGMOD, CAiSE, EDBT, IEEE Data Engi-neering, SSDBM, and VLDB; and he serves regularly as a reviewer forall the major database journals. He is a senior member of the IEEE,and a member of the ACM and the IEEE Computer Society.

Documents

Temporal Entity-Relationship Models—A Surveypeople.cs.aau.dk/~csj/Papers/Files/1999_gregersenIEEETKDE.pdfAn ER diagram pro-vides a good overview of database design, and the model’s