Professional Writing Service http://StudyHub.vip/A-Conceptual-Model-For-The-Logical-Desi

1. ELSEVIER Decision SupportSystems15(1995)305-321
A conceptual model for the logical design of temporal
databases
Debabrata Dey a.*, Terence M. Barron b, Veda C. Storey c
aDepartmentof Information Systemsand DecisionSciences,Louisiana State University,Baton Rouge, LA 70803,USA
bDepartmentof Information Systemsand OperationsManagement, Universityof Toledo, Toledo, OH 43606, USA
c GraduateSchoolof BusinessAdministration, Unit,ersityof Rochester, Rochester,NY 14627, USA
Abstract
Although widely advocated as a tool for the conceptual modelling of data, the Entity-Relationship (E-R) model
[4] and its extensions are generally lacking in constructs to model the dynamic nature of the real world, making them
inadequate for designing temporal databases. This research first extends the E-R model to a Temporal Event-Entity-
Relationship Model (TEERM), by introducing events as an additional construct. Second, a method is proposed for
mapping this conceptual model into a temporal relational model for the logical design of temporal relational
databases with a corresponding set of integrity constraints. The model is illustrated with an example and evaluated
using a set of criteria proposed by Batini et al. [2]. The model appears to be expressive, simple and easy to use, and
should, therefore, aid the temporal database design process significantly.
Keywords: Temporal ER model; Conceptual design; Temporal database
I. Introduction
Recent years have seen a rapid growth of
research interest in the area of temporal
databases. Most of these research efforts have
concentrated on representing temporal data by
extending the relational model. However, the de-
sign process of temporal relational databases has
This research was partially supported by the William E.
Simon Graduate Schoolof Business Administration, Univer-
sityof Rochester.Thisworkhas greatlybenefitedfromdiscus-
sions with Prof. Yair Wand, Universityof British Columbia,
Canada, and from the commentsof the reviewers. The au-
thors wishto thank them all.
*Corresponding author
not received much attention in the literature. On
the other hand, the design process for conven-
tional static or snapshot databases has been stud-
ied extensively [2,25,26,28]. In static database de-
sign, the designer starts with the well-known en-
tity-relationship (E-R) model [4] for specifying
the data requirements, and then transforms it
into relational schemes according to a set of
rules. This process has also been automated with
the help of expert systems, such as the View
Creation System [25]. Unfortunately, this process
does not work for temporal relational databases.
For example, consider the temporal relation
shown in Table 1. The last column in this table,
designated TS, represents the time-stamp at-
tribute which is appended to a static relation
scheme to capture the time-varying nature of the
0167-9236/95/$09.50 © 1995ElsevierScienceB.V. All rights reserved
SSDI 0167-9236(94)00044-1

2. 306 D. De),,et al. / Decision Support Systems 15 (1995) 305-321
Table 1
EMPLOYEE: A temporal relation
EMP# ssn LName FName salary dept TS
3025 086630763 Lyons James 15K depl [1,3)
3025 086630763 Lyons James 15K dep2 [3,5)
3025 086630763 Lyons James 20K dep2 [5,9)
3025 086630763 Lyons James 22K dep2 [9,13)
information. Although this scheme (without the
time-stamp attribute) would have been an accept-
able design for a static relational database, 1 it
clearly suffers from data redundancy as a tempo-
ral relation scheme. Data redundancy is a serious
problem in any database, since it poses problems
in terms of preservation of data integrity and
occupies extra storage. Hence, the above scheme
is not a good design for a temporal relational
database.
We attribute this problem to the lack.of a
design theory for temporal relational databases.
For static databases, there exists a well-estab-
lished design process, along with normalization
theory to evaluate the quality of a design thus
obtained. To develop a general theory for design-
ing temporal databases, three issues have to be
addressed: (i) representation of temporal data in
a conceptual model, (ii) transformation of the
conceptual model to a set of temporal relation
schemes, and (iii) evaluation of the design using a
temporal extension of the existing normalization
theory. Dey [7] proposes a structure for temporal
relations, and extends normalization theory to
include temporal relations. However, the design
process for temporal relational databases is not
examined there.
Thus, the objectives of this research are to
develop a temporal conceptual model, and to show
how this model can be used for the logical design of
temporal relational databases. To these ends, we
propose an extension of the E-R model, which
has been widely advocated as a tool for the con-
ceptual modelling of data. The E-R model, how-
In a static relation, the information about each employee
is stored as a snapshot at a single point in time. Since this can
be stored in exactly one tuple, there is no replication of data.
ever, can at best model a "snapshot" of the real
world at any point of time; it does not contain
specific constructs to model the dynamic aspects
of the real world. As a result, the E-R model is
an inadequate tool for temporal database design.
Schiel [22] makes a useful observation regard-
ing the required constructs in a data model. He
notes that there are three kinds of objects in the
real world: (i) Entities, (ii) Relationships and (iii)
Events. In the Entity-Relationship (E-R) model,
data about objects are stored in two ways. Infor-
mation about a single entity is captured in its
attributes. Information about an association be-
tween two or more entities is captured in the
relationship (and its attributes) that binds them.
Because the viewpoint of the E-R model is the
design of "snapshot" databases, i.e. those that
reflect the state of affairs at a single time point
(usually the present), it omits events. Informally,
events are those occurrences that induce changes
in one or more instances of an entity or a rela-
tionship; so they take on considerable importance
when designing a temporal database. Further-
more, even in snapshot databases, knowledge of
the relevant events is useful in defining transac-
tions and some kinds of integrity constraints. Since
events by nature belong to the time domain, their
incorporation as an addition to entities and rela-
tionships must strictly increase the semantic ex-
pressiveness of the resulting conceptual mod-
elling language.
This paper makes two contributions to the
literature. First, we propose a temporal concep-
tual model, called the Temporal Event-Entity-Re-
lationship Model (TEERM). The TEERM adapts
the usual constructs of the E-R model (entities
and relationships), with events added to enhance
the semantic richness of the model. This model is
thus a strict superset of the conventional E-R
model, and allows us to model the dynamic be-
haviour of entities and relationships in addition
to incorporating advanced modelling techniques
such as aggregation, generalization and special-
ization that are available in Extended E-R mod-
elling [28]. Second, we demonstrate how the
TEERM can be used for the logical design of
temporal relational databases by showing how to
translate each construct of the TEERM into a

3. D. Dey et al. /Decision Support Systems 15 (1995) 305-321 307
temporal relational model. We believe that de-
signers of temporal as well as snapshot databases
will greatly benefit from the results of this re-
search.
The remainder of this paper is organized as
follows. A brief review of previous work on tem-
poral conceptual models is presented in section 2.
Section 3 formally describes the components of
the model. Section 4 discusses the role of the
TEERM in logical database design. The model is
then illustrated with a banking example in section
5. Section 6 concludes the paper and offers sug-
gestions for future research.
2. Previous research
Conceptual design has long been recognized as
a crucial phase of database design [2], with the
entity-relationship (E-R) model [4] widely used
for this purpose. The E-R model, however, is an
inadequate tool for temporal database design.
Extensions to the E-R model have been pro-
posed that allow one to model temporal data to a
limited extent. Klopprogge and Lockemann
[18,19] attempt to extend the E-R model to in-
clude time based on perception and representa-
tion. Elmasri et al. [11-13] propose an extended
E-R model for temporal data. They classify ob-
jects as conceptual and temporal. The former is
used to capture the static nature of the world,
whereas the latter materializes the active role
that conceptual objects play in the temporal di-
mension. These researchers also discuss temporal
constraints among the roles that an entity can
play, and extend the GORDAS language for tem-
poral E-R databases. Kouramajian and Elmasri
[20] discuss how their temporal E-R model can be
mapped into temporal extensions of the rela-
tional model. Ferg [14] proposes RAKE (Rela-
tionship-Attribute-Key-Entity) diagrams that rep-
resent temporal attributes as relationships be-
tween entities and attribute domains, and tempo-
ral relationships by introducing time as another
entity participating in the relationship. Tauzovich
[27] introduces the concepts of snapshot and life-
time cardinalities for representing temporal rela-
tionships.
While the above extensions are improvements
over the traditional E-R model, none of them
explicitly models events. The incorporation of
events into the E-R model was first proposed by
Dubois et al. [10] in their ERAE (Entity-Rela-
tion-Attribute-Event) data model. There are,
however, some basic differences between that
model and our proposal. The ERAE data model,
designed primarily for requirement analysis, em-
phasizes instances, not types of entities, relation-
ships and events. Since the designer of a tempo-
ral database is more concerned with the database
schemes and hence with the classes of different
kinds of objects, ERAE model is not directly
useful for temporal database design. Further-
more, the ERAE model uses events only to ex-
press dynamic constraints, whereas we use events
to provide an enriched view of the data in addi-
tion to expressing certain integrity constraints.
Theodoulidis et al. [29] use events as a type of
object in their ERT (Entity-Relationship-Time)
model. Events were also used in the context of
active databases by Gehani et al. [16]. These
researchers, however, use events to represent in-
ternal processes; they do not provide real world
events as a data abstraction mechanism. Dey et
al. [9] examine how real world events, in addition
to capturing the temporal semantics of data, can
provide useful information on the nature of data
items and integrity constraints. Different types of
event classification are described in terms of their
significance within a data model.
3. Temporal event entity relationship model
This section describes the different compo-
nents of the Temporal Event-Entity-Relationship
Model (TEERM). The symbolic representations
of these components are shown in Fig. 1. The
following definitions are required. The term uni-
uerse refers to the entire real world. The object
system refers to the information system that is to
be built, so the object system is the subset of the
universe that represents the application at hand.
We sometimes refer to the object system simply
as the system. It is assumed that the time line is
continuous, i.e., isomorphic to the set of real

4. 308 D. Dey et al./ DecisionSupportSystems15 (1995)305-321
Symbol Meaning
Entity
Static Relationship
Quasi-static Relationship
TemporalRelationship
name Static Attribute
san SurrogateAttribute
0 last_check_no Quasi-static
Attribute
O ~ TemporalAttribute
addre~ss street
city CompositeAttribute
zip
Event
Fig. 1. Basic symbols for temporal event entity relationship
model
numbers. In other words, it is the metric space of
(0,~). The time horizon of an object system refers
to a subset of the time line during which the
object system serves its useful purpose.
3.1. Components adapted from the E-R model
The three basic components are adapted from
the E-R model: (i) entities, (ii) relationships, and
(iii) attributes.
Entity An entity is a "thing" or an object that
has a separate identity in the universe. Each
entity typically possesses certain properties. An
entity type is defined as a set of entities with a
similar set of properties. For brevity, we refer to
an entity type as an entity in the remainder of the
paper; an entity instance is specifically distin-
guished from an entity type.
Relationship A relationship type is an associa-
tion among two or more entity types. The number
of entities that are associated is called the arity
of the relationship. We will use the term relation-
ship to refer to a relationship type, and, when
appropriate, mention relationship instances
specifically.
In order to formally describe the dynamic na-
ture of certain relationships, we introduce the
concept of a null relationship instance, which is a
relationship instance of any arity whose entity
instances are all null. 2A change of a relationship
instance is then defined as a change in some or
all of the participating entities. Thus, a change in
a relationship instance could be of three types:
(1) a birth, where all entity instances of a null
relationship instance change to non-null val-
ues,
(2) a death, where all entity instances of a non-
null relationship change to null values, and
(3) a transition, where some entity instances of a
non-null relationship change to non-null val-
ues.
A relationship is static if none of its non-null
instances changes over time (within the time hori-
zon of the object system); otherwise it is dynamic.
The relationship between a mother and a child is
static, whereas the relationship between a man-
ager and an employee is dynamic.
Each entity that participates in a relationship
has min.max cardinalities attached to it. The min-
imum (maximum) cardinality represents the least
(most) number of relationship instances in which
any instance of that entity can participate at any
given time point. The min-max cardinalities are
typically written next to the line joining the entity
with the relationship. A cardinality is represented
by a " *" if it is greater than 1 (i.e., many) and
not known at design time.
Attribute: Attributes represent properties of
entities and relationships. We consider only sin-
gle-valued attributes, that is, any attribute can
have at most one value at any time point. (Multi-
valued attributes are modeled as entities.)
2A null relationshipinstance can be of any arity, and is
always a member of any relationship. As a result, if a null
relationship instance changes to a non-null relationships in-
stance, then a new null relationship instance is generated. An
alternative interpretation is that each relationship has an
infinite number of null instances; since only the non-null
instances are relevant, the nulls do not have to be enumer-
ated.

5. D. Dey et al. / Decision Support Systems 15 (1995) 305-321 309
Relationships/Attributes
I
I I
Static Dynamic
I
I I
Temporal Quasi-static
Fig. 2. Classification of relationships and attributes.
An attribute is static if it does not change over
time (within the time horizon of the object sys-
tem); otherwise it is dynamic. For example,
"date-of-birth" is a static attribute, whereas
"salary" is dynamic. An attribute may be com-
posed of several elementary attributes. Such an
attribute is referred to as a composite attribute,
for example "address." If a set of one or more
attributes uniquely identifies an entity, then it is
called a candidate key of that entity. Components
of any candidate key must be static. One such
candidate key is chosen for the object system as a
unique identifier of that entity, and is called the
surrogate or the key.
Although dynamic attributes and relationships
usually change over time, the history of only some
of these attributes and relationships may be rele-
vant for an object system. For example, it may be
useless in a banking system to store the complete
history of a customer's address. Any dynamic
relationship or attribute whose history is not rele-
vant for an object system is referred to as quasi-
static. The remainder of the dynamic relation-
ships and attributes, whose temporal behaviour is
of interest for a given system, are referred to as
temporal. 3 (Fig. 2).
Since an entity may be viewed as an aggrega-
tion of attributes, we assume that the temporal
behaviour of an entity is expressible in terms of
3 Success of a design depends on the design time decisions
about which dynamic attributes and relationships should be
treated as quasi-static and which ones as temporal. While it is
clear that storing temporal data has its benefits, it comes at
the cost of extra storage and processing. The designer of a
temporal database should perform some type of cost-benefit
analysis when deciding which attributes and relationships
should be treated as quasi-static.
the time-dependency of its attributes, so it is not
necessary to include any extra construct such as a
temporal entity in our model.
3.2. Ecents in TEERM
In order to understand the nature of events
and represent them correctly, different types of
events must be defined and classified.
Definition 3.1 An event is an occurrence that
results in changes in the states of one or more of
the following within the object system: entity in-
stances, relationship instances, and attribute values
(of entity and / or relationship instances).
An event type is defined to be a set of event
occurrences that induce changes in the same set
of entities and relationships. For example, the
event type "Promotion" represents the set of all
promotions granted to the set of all employees
during the time horizon of the system. In the
remainder of this discussion, an event type is
referred to simply as an event; an event occur-
rence is specified and clearly distinguished from
an event type. An event type is represented as a
rounded rectangle as shown in Fig. 1.
The distinction among events, entities and re-
lationships depends largely on the perception of
the user. It is possible that a few events may be
viewed as entities (or relationships) by certain
users. For example, an event "Sale" may also be
viewed either as an entity "SALE," or as a rela-
tionship "sale" between two entities
"CUSTOMER" and "PRODUCT," implying that
there might not exist any unique representation
of an object system. This, however, need not be
considered as a shortcoming of the model. It is
well-known that, in the E-R model, the distinc-
tion between entities and relationships is not
always clear [2,17]. For instance, consider the
following relationships that can also be modeled
as entities:
Relationships Entity
EMPLOYEE works on PROJECT ASSIGNMENT
CUSTOMER buys PRODUCT SALE
PATRON borrows BOOK LOAN
Clearly, the E-R model does not possess the
uniqueness property; 4 neither does the rela-

6. 310 D. De),et al. / Decision Support Systems 15 (1995) 305-321
Events
I
Singular Rec!rrent
I
I I
Periodic Aperiodic
Fig. 3. Classification of events.
tional model, since an E-R representation of a
system could result in several alternative rela-
tional schema. As a general guideline, we recom-
mend that, in cases where an entity or a relation-
ship can also be represented as an event, it should
be modeled as an event. This is because events
can specify useful integrity constraints in addition
to providing an alternative view of data.
Each event must have a time attribute repre-
senting the time of occurrence of event instances.
Certain events may also have attributes other
than the time attribute. For example, the event
"Promotion" may have "granting-Manager,"
"promoted-employee," etc. as attributes. Since
events have indeterminate lifetimes, their proper-
ties are independent of time [10], therefore, all
attributes of an event must be static. Event at-
tributes are denoted in a fashion similar to entity
and relationship attributes.
Classification of euents
We classify events based on the instances of
the different entities needed to model the system,
as shown in Fig. 3. Each event can be classified as
either singular or recurrent for every entity rela-
tive to the system being modeled.
Definition 3.2 An euent V is said to be singular
for an entity E associated with the event V,, relatiue
to system X, if and only if during the lifetime of
euery instance e ~ E within X, at most one event
instance u ~ V occurs.
4Database design may be viewed as a mapping from the
real world to a data model. The data model typically possesses
a high degree of forma!ity, whereas, for all practical purposes,
the real world is not a formal system [6]. As a result, a real
world situation may be mapped to several alternative repre-
sentations in the data model
Definition 3.3 An event V is said to be recur-
rent for an entity E relative to system X if and only
if it is not singular for E relative to X.
The distinction between singular and recurrent
events depends on the entities associated with the
events. As a result, an event may be recurrent
with respect to some entity while it is singular for
some other. For example, the event "Publication
of books" has associated entities "BOOK,"
"AUTHOR" and "PUBLISHER." For every in-
stance of a book, 5 there exists only one occur-
rence of publication, although there may be more
than one occurrence of publication for a specific
author or publisher instance. As a result, this
event is singular for the entity "BOOK," but
recurrent for the entities "AUTHOR" and
"PUBLISHER."
Recurrent events can again be divided into two
classes. Periodic events have a fixed time interval
between any two successive event occurrences;
aperiodic events do not have this property.
Monthly payroll processing is an example of a
periodic event, whereas transfer of employees
among departments may be considered as an
aperiodic event.
Connection of events with other components
Events are connected to other components of
the model. These connections capture the seman-
tics of the data and are classified as:
Event-to-event: An arrow from one event to
another implies that every occurrence of the for-
mer is accompanied by an occurrence of the
latter. Similarly, a double-sided arrow between
two events implies that they occur simultane-
ously. Such connections may lead to useful in-
tegrity constraints. For example, an arrow from
"Promotion" to "Pay-raise" indicates that every
promotion is accompanied by an increase in
salary.
Event-to-entity: Event-to-entity connections
are represented by a line. Typically, a connection
between an event and an entity indicates that the
5Different editions of the same book are treated as differ-
ent instances of the entity book for the purposes of this
analysis.

7. D. Dey et al. /Decision Support 5)'stems 15 (1995) 305-321 311
ss...~n
r
Fig. 4. Connections between events and attributes.
entity takes part in the event. The letter (within a
circle) on the line joining the event to the entity
indicates whether the event is singular or recur-
rent for that entity, with "S" representing singu-
lar and "R," recurrent. As shown in Fig. 4, the
event "Pay Revision" is recurrent for the entity
"PH.D. STUDENT."
Event-to-relationship/attribute: A dashed ar-
row from an event to a relationship (or an at-
tribute) represents that the event causes the rela-
tionship (or the attribute) to change. For in-
stance, a dashed arrow from "Pay-raise" to
"salary" implies that salary changes with pay-
raise. Similarly, an event "Project Assignment"
might change the relationship "EMPLOYEE
works on PROJECT."
Relationship/Attribute-to-event: A dashed ar-
row from a relationship (or an attribute) to an
event represents the fact that a change in the
relationship (or the attribute) causes the event to
occur. For example, if the stipend of a Ph.D.
student is determined based on his/her grade
point, then a change in the grade point should
result in revising the stipend. This is modeled by
a dashed arrow from the attribute "'grade-point"
to the event "Pay Revision," and another dashed
arrow from the event "Pay Revision" to the at-
tribute "stipend" as shown in Fig. 4. This connec-
tion implies that a report should be generated for
pay revision every time the grade point of a
student changes. Since we assume that the tem-
poral nature of an entity is completely expressible
in terms of its attributes and relationships, it
suffices to consider only relationship-to-event and
attribute-to-event connections; we do not have to
consider entity-to-event connections.
Data modelling techniques such as aggrega-
tion, generalization and specialization can also be
used with events. For example, a generalization
hierarchy of events where every instance of a
"Transaction" event could be either a "Deposit,"
a "Withdrawal," or a "Fund Transfer" may be
useful in a banking system.
3.3. Design implications of events in the TEERM
Each event that interacts with (or occurs
within) the system affects the internal states of
some information objects in the system. These
changes take effect by changing one or more
attributes or relationships. Thus, each event can
be used effectively to identify some of these at-
tributes and relationships that might be over-
looked otherwise. Furthermore, as discussed be-
low, more information about these attributes and
relationships is available from studying the nature
of these events. The following design implications
are easily verified:
Implication 3.1 Let 1/l, V2..... Vn be the only
ecents that affect an attribute A of entity E. If 1/l,
V: ..... V, all occur simultaneously, and if V1 is
singular for E, then A is static.
An example is "date of birth" of a person.
The only singular event that affects this attribute
is the birth of a person.
Implication 3.2 Let R be a relationship connect-
ing entities E1,E 2..... E,. If V is the only event that
affects R, and if V is singular for at least one Ei,
1 < i < n, then R is a static relationship.
An example of a static relationship is that
between the entities "MOTHER" and "CHILD;"
the associated event is "Child Birth." This event
is singular for the entity "CHILD," whereas it
may be recurrent for the entity "MOTHER".
Implication 3.3 A static attribute or a static
relationship must not be updated.
Implication 3.4 If an attribute or a relationship
is affected by two or more events all of which are
not simultaneous, then it is dynamic.
Implication 3.5 If event V is recurrent for entity

8. 312 D. Dey et al. / Decision Support Systems 15 (1995) 305-321
E, and if V affects attribute A of E, then A is a
dynamic attribute.
"Salary" is an example of a dynamic attribute
of the entity "EMPLOYEE" and "EMPLOYEE"
works on "PROJECT" is an example of a dy-
namic relationship. Events such as "Promotion"
and "Pay-raise" affect "salary," whereas the rela-
tionship "works on" is affected by the event "Pro-
ject Assignment." Existence of dynamic attributes
and relationships usually imply that there are
some events that affect these attributes and rela-
tionships. This could be used for checking the
completeness of a design.
Implication 3.6 If there exists a set of attributes
affected by the same set of simultaneous events,
then these attributes have the same time-depend-
ency (i.e., when they change, they all change simul-
taneously).
For example, whenever a person moves to a
new address, all of the attributes constituting the
address (i.e., street, city, state, zip) change. Of
course, if the attributes constituting the address
do not change together, then the recurrent event
"moving" may be partitioned into several events
such as moving to a new state, moving to a new
city, moving to a new street, etc.
Implication 3.7 If a connection exists from event
VI to V2 (V1~V2), and if only V,. affects the
attribute A i, i = 1,2, then a change in A 1 of some
entity or relationship instance is accompanied by a
change in A 2 of that (or some other) entity or
relationship instance.
Since every occurrence of V1 is accompanied
by an occurrence of I/2, a change in A 1 (which
implies an occurrence of VI) is accompanied by a
change in A 2. For example, if every "Promotion"
comes with a "Pay-raise", then a change in "rank"
would imply a change in "salary."
Implication 3.8 If two entities E 1 and E 2 are
connected to the same event V, then usually there is
a relationship that connects E 1 and E 2.
For some applications, a few events may be of
primary importance. For example, consider the
event "Flight" of a specific airline, having associ-
ated attributes flight#, city_from, cityto, depar-
turetime, arrival_time, equipment, etc. Such
events are typically modeled as entities in the
E-R model. Other examples include events such
as marriages, births, and matches between any
two sports teams. In general, if an event has
attributes of interest, this indicates that it is of
considerable importance to the system.
4. Logical design for temporal relational
databases
This section discusses how the TEERM can be
used for the logical design of temporal relational
databases. In order to design such a database,
two major decisions are required. First, we must
decide on the structure (or the view) of the tem-
poral relations; and second, we must decide on
how to represent each component of the TEERM
in the temporal relational model.
Two major approaches have been proposed for
the structure of temporal relations: (i) the tuple
time-stamping (or, 1NF) view [3,24,21] which the
time-stamps are part of each tuple and character-
ize the whole tuple, and (ii) the attribute time-
stamping (or, non-lNF) view [5,15] where the
time-stamps are associated with every attribute.
Both approaches have their merits and limita-
tions. This research employs the tuple time-
stamping (1NF) view because it is very close to
the view of relations in the traditional relational
model. Several other reasons for favouring the
tuple time-stamping method can be found in
[23,21,7]. Dey [7] proposes a structure for tempo-
ral relations based on tuple time-stamping that is
used as the target model for this research. As
Alan [1] shows, however, the above two views of
temporal relations are equivalent in the sense
that one can be transformed into the other with-
out loss of information. We first describe briefly
the formal structure of temporal relations and
then discuss how the TEERM can be mapped
into that structure.
4.1. Formalization of relations
This subsection summarizes the approach
adopted in this research. It is assumed that the
time space is formed by one or more orthogonal
time lines. For example, if both transaction time
and valid time are supported, then these time

9. D. Dey et al. / Decision Support Systems 15 (1995) 305-321 313
lines serve as the basis vectors of the two-dimen-
sional time space. An elementary subset of the
time space is formed by the union of a finite
number of time intervals and time points. Let 3-
denote the family of all elementary subsets of the
time space. The time-stamp attribute is denoted
by TS and assumes values in 3-.
A relation scheme R is a set of attribute names
{A1,A 2..... An}, only one of which may be a time-
stamp TS. Corresponding to each attribute name
Ai, is a set Di, 1 < i < n, called the domain of A~.
If A i=TS, then Di=3-. Let D=D 1× D 2×
...Dn. D is called the domain of R. Then, a tuple
x over R is a function from R to its domain D.
Two tuples x and y on a relation scheme R
are value-equivalent (written x = y ) if for all A E
R, (A ~ TS ~ y(A)=x(A)) holds. Value-equiv-
alent tuples are not allowed in a legal temporal
relation; they must be coalesced into a single
tuple. This is analogous to the elimination of
duplicates in the relational model. The coales-
cence operation (denoted by O) on two value-
equivalent tuples, x and y, on relation scheme R
produces a tuple z on R given by:
z =xOy = (x =y) A (VA ~R(A 4=TS ~z(A)
=x(A))) A (TS ~R = z(TS)
=x(TS) Uy(TS))
A relation r on the scheme R is a finite
collection of tuples x on R, such that no two of
its members are value-equivalent.
The usual meaning of a candidate key as a
minimal object surrogate is retained. In other
words, a candidate key of a relation of this struc-
ture is one that is a candidate key (in the usual
static sense) of all possible snapshots derivable
from that relation. This implies that a candidate
key, as in the static case, is time-invariant. Only
one of several candidate keys is chosen as the
primary key. A primary key no longer uniquely
identifies each tuple (which represents only one
of several possible states of an object). A combi-
nation of primary key and time-stamp TS can
however uniquely identify each tuple. Let r be
any relation on scheme R with primary key K.
The following constraints on r and K are im-
posed:
(1) For all x,y~r ,x(K)=y(K)~(x=y)V
(TS ~ R ~x(TS) ny(TS) = 0). This implies
that no object can exist in two temporal states
simultaneously. For static relations, this con-
dition reduces to key uniqueness for each
tuple.
(2) For all x ~ r, x(K) cannot be null. This en-
sures that information is stored only for the
identifiable objects.
(3) For all x ~ r, TS ~ R =~x(TS) ~ null. In other
words, information is not stored for any tem-
poral state of an object if that state cannot be
identified.
Definition 4.1 (Temporal Dependency) Let r be
a relation on scheme R, TS ~ R, and let K be its
primary key. Let X, Yc (R-{TS}). The relation r
is said to satisfy the temporal dependency (TD)
T
X ~ Y if there exist tuples t 1,t2 E r such that (i)
tl(K U Y) = te(K U Y) and (ii) tl(S ) :-if=
t2(X). The
temporal dependency is trivial if Y c K.
Existence of temporal dependencies implies
that values of certain attributes must be dupli-
cated across tuples even when they do not change.
This will result in redundancy and extra storage.
Such problems can be avoided by restricting rela-
tions to be in temporal normal form as defined
below.
Definition 4.2 (Temporal Normal Form) Let R
be a relation scheme, and let F be a set of func-
tional multi-valued and temporal dependencies
over R. R is in temporal normal form (TNF) with
respect to F if R is in 4NF with respect to F and all
temporal dependencies implied by F over the at-
tributes of R are trivial.
4.2. Conceptual modelling
In this section, we suggest a step-by-step pro-
cess of conceptual modelling leading to develop-
ment of the temporal event-entity-relationship di-
agram for the application. Note that this is not a
one-pass procedure. Sometimes, identification or
analysis of a construct at some step may lead to a
revision of the results from a prior step. In other
words, the process is iterative. The basic steps
are:
Step 1. Identification of entities and their at-
tributes: As in the case of static database design,

10. 314 D. Dey et al. / Decision Support Systems 15 (1995) 305-321
the modelling starts with identification of the
relevant entities and their attributes. Attributes
of an entity describe its relevant properties. It is
not always clear whether a real-world object
should be modeled as an entity or as an attribute
and a good heuristic is that, if several properties
could be associated with an object, it should be
modeled as an entity [2]; the associated proper-
ties become attributes of the entity. If the object
is single-valued with an atomic structure, it should
be modeled as an attribute. Multi-valued or re-
peating attributes are modeled as entities [25].
Step 2. Identification of relationships and their
attributes: In this step, we find the relationships
among the relevant entities and the min-max
cardinalities of these relationships. Some of these
relationships may have attributes of their own. It
is possible that this step may lead to discovery of
new entities. The designer should verify whether
relationships of arity greater than two could be
broken into several binary relationships. It is also
necessary that all the redundant relationships be
removed from the model. For example, consider
the three relationships shown in Fig. 5. Clearly,
the relationship "resident of" between entities
"PERSON" and "STATE" is redundant. For,
once we know the name of the city in which a
person lives in and the state to which that city
belongs to, the state of residency for that person
is automatically known. The relationship between
"PERSON" and "STATE" is then redundant
and must be removed from the model.
Step 3. Identification of events: In this step,
the relevant events are identified and then classi-
fied according to the scheme presented in Fig. 3.
Various connections (namely, event-to-event,
event-to-entity, event-to relationships and event-
to-attributes) are established. If an event can also
1
Fig. 5. A redundant relationship.
be modeled as an entity or as a relationship, it
should be modeled as an event. Identification of
events may lead to discovery of entities, relation-
ships and attributes that might have been over-
looked during the earlier steps. This may, in turn,
lead to identification of other missing events.
Step 4. Classification of relationships and at-
tributes: In this step, all the relationships and
attributes identified so far should be classified
into static and dynamic. Further classification of
dynamic relationships and attributes into tempo-
ral and quasi-static should be postponed till later.
The design implications of events, as outlined in
section 3.3, could be used in this step to analyze
the nature of the relationships and the attributes.
Once these steps are applied repetitively, to
the satisfaction of the designer, an integrated
view of the application will result in the form of a
TEER diagram. This diagram could now be used
to obtain the logical scheme of the database. We
recommend application of the following guide-
lines before the formal mapping is carried out.
(1) Decompose all composite attributes into their
more elementary components. Identify any
multi-valued or repeating attributes, and con-
vert them to entities.
(2) Infer any integrity constraints that can be
derived from the TEER diagram; for exam-
ple, a static attribute can never be changed.
(3) Classify all dynamic relationships and at-
tributes as temporal and quasi-static. Note
that such a classification is often based on the
trade-off between the cost of storing extra
data and the benefit of having more informa-
tion. More discussion on such trade-off analy-
sis is found in [8].
(4) Verify that all relationships have rain-max
cardinalities specified for all participating en-
tities.
(5) Retain only those events that have attributes
(other than the implicit time attribute) of
their own, and delete all other events.
(6) Determine whether it is possible to represent
some of the attributes of the remaining events
as attributes of other entities and relation-
ships. If so, check whether the event view is a
natural view for the user. If not, eliminate
these events also. Note that a representation

11. D. Dey et al. /Decision Support Systems 15 (1995) 305-321 315
that has events might have some kind of
redundancy due to the duality between event
and entity representations. In some applica-
tions, such redundancies may be desirable;
however, there should be proper enforcement
of a set of integrity constraints to account for
this type of redundancy.
4.3. Mapping of the TEERM components
This section discusses how different compo-
nents of the TEERM can be mapped into the
above temporal relational model.
Representation of entities and events
Let E be an entity that has one or more
temporal attributes. We represent E as
E: [SA ,CA ,TA ]
where the set SA constitutes the surrogate (the
unique identifier of each instance of E); CA is
the set of static and quasi-static attributes; and
TA is the set of temporal attributes. The possibil-
ity that CA and/or TA might be empty is not
excluded. The set TA is now partitioned into k
smaller subsets TAi, 1 < i < k, i.e.,
k k
U TAi= TA, ["1 TA~= G.
i=1 i=1
Here each TAi, 1 < i < k, is a set of attributes
that have the same time dependency; in other
words, all attributes contained in set TA, can
change only simultaneously. Now the entity E can
be transformed into the following temporal rela-
tional schemes.
E:[SA,CA]
ETi:[SA,TS,TAi], ViA _<i < k.
The underlined attributes in each relation
scheme represent the primary key for that scheme.
Integrity constraints
The following integrity constraints should be
enforced:
Existence constraint: Any relation instance on
the schemes E and ETi, 1 _<i_< k, cannot have
null values for SA and TS.
Referential constraint: There should be a ref-
erential constraint from a relation on scheme E
tO a relation on scheme ETa, SA being the foreign
key of ETi, 1 _<i < k. This is because ETi, 1 < i <
k, may be viewed as a weak entity, and its exis-
tence is dependent on E.
Others: Static attributes should not be up-
dated.
Events can be treated in a fashion similar to
entities for representation in the temporal rela-
tional model. For each event, we create a relation
on a scheme that contains all the attributes of
that event including the time attributes. As noted
earlier, events can have only static attributes.
Thus, the relation resulting from an event will
always be a static relation, with a user-defined
time attribute as the event time.
There are several important issues in the rep-
resentation of events in a relational model that
are discussed bellow:
Primary key: Most relevant events typically
have some artificial surrogate to identify each
occurrence uniquely. For example,
"transaction no" is a surrogate for the event
"'Transaction" and "flightno" is a surrogate for
the event "Flight." However, there may be other
events that do not have such artificial surrogates.
Event time and/or keys of entities participating
in the event may be used as the primary key. For
instance, "ssn" of a husband and a wife could be
used as the primary key of the event "Marriage". 6
Event-to.entity connections: If an event is rep-
resented as a relation, then the relevant event-
to-entity connections should be represented for
navigational purposes. If the primary key of the
participating entity already occurs as an attribute
of the event, then the link is automatically estab-
lished. Otherwise, a new relation is created whose
primary key is the concatenation of the primary
keys of the entity and event relations. For exam-
ple, the connection between the event "Flight"
and the entity "PASSENGER" is represented by
creating a new relation with "flightno" and "ssn"
as its primary key.
Redundancy and integrity constraints: Repre-
senting events in relations often causes data re-
It is also possible to use "marriage_license_no" as the
primary key of the event "Marriage."

12. 316 D. Dey et al. / Decision Support Systems 15 (1995) 305-321
dundancy, because the same facts may be stored
twice - once in an event occurrence, and a sec-
ond time in the history of attributes or relation-
ships. Proper integrity constraints should be en-
forced to ensure that the redundant data are
consistent.
Representation of relationships
The transformation rules for relationships
largely depend on the number of entities that
participate in the relationship, the min-max cardi-
nalities, and whether the relationship is temporal
or static, as outlined below.
Unary/binary static and quasi-static relation-
ships: Consider a binary relationship of the form
"E~ verb..phrase E2." The possibility that E 1= E:
is not excluded, that is, unary relationships are
considered as a special case. If the min-max car-
dinalities of an entity that participates in a binary
relationship are (1,1), then the relationship is
represented by adding the surrogate of the other
entity as a foreign key (if it does not already exist)
in the scheme of the relation that represents the
entity with the (1,1) cardinalities. When neither
entity has (1,1) cardinalities, a separate relation is
created to represent the relationship. The pri-
mary key of this relation consists of the concate-
nation of the surrogates of the participating enti-
ties; the relationship attributes are non-keys. 7
Other static and quasi-static relationships:
Relationships involving more than two entities
should be represented by creating a new relation
whose primary key is formed by concatenating
the surrogates of all the entities that take part in
the relationship. 8
Temporal relationships and relationship at-
tributes: Let R be a temporal relationship involv-
ing entities E i, 1 < i < n. Let S A i be the surro-
gate attribute of E i. R is then represented by
creating a new relation whose scheme is given by
R:[SAt, SA2 ..... SAn,TS ]
If R has attributes, they could be partitioned
into two sets: a set CA of static and quasi-static
attributes and a set TA of temporal attributes.
We do not exclude the possibility that CA and/or
TA might be empty. The static attributes of the
relationship can simply be added to the relation
scheme that represents the relationship R.
R: [SA , ,SA 2,...,SA n,TS,CA ]
The set TA is then partitioned into k smaller
subsets TA i, 1 < i < k, i.e.,
k k
U TA,=TA, N TAi= e.
i=1 i=1
Here each TA i, 1 < i < k, is a set of attributes
that have the same time dependency. We now
create k new relations on the relation schemes
given by
RTi:[SA 1,SA 2.....SA.,TS,TA,]Vi,1 <_i < k
Integrity constraints
The following integrity constraints should be
enforced:
Existence constraint: Any relation instance on
the schemes R and RT~, 1 <_i < k, cannot have
null values for SA/, 1 <j < ,t, and TS.
Referential constraint: There should be a ref-
erential constraint from a relation on scheme Ej
to a relation on scheme R, with SA/ being the
foreign key of R, 1 < j < n. There should also be
a referential constraint from a relation on scheme
R to a relation on scheme RT,, with
{SAI,SA 2..... SA,} being the foreign key of RT/,
l <i <k.
Others: The following additional integrity con-
straints are easily derived:
(1) Statistic attributes should not be updated.
(2) If a static relationship is represented using a
foreign key, then the foreign key should not
be updated.
(3) If a static relationship is represented by a new
relation, then no tuple of that relation should
be deleted.
7 For a more detailed discussion on representation of static
relationships and their attributes, see [25,26,28].
s Although, in some cases not all of the keys are necessary
[28].
4.4. Temporal normal form and the TEERM
We will now show that the proposed design
method results in temporal relations that are in

13. D. Dey et al. /Decision Support Systems 15 (1995) 305-321 317
temporal normal form. This further demonstrates
the usefulness of this approach.
Theorem 4.1 Let R be a relation scheme pro-
duced using the representation scheme outlined
above. If R is in fourth normal form, then R is in
temporal normal form.
Proof. The scheme R could be produced from
any one of the several different TEERM con-
structs using the above representation scheme.
Let us first consider the case that R is produced
from an event. Since events do not have dynamic
attributes, TS ~ R, so R must be in TNF if it is in
4NF. A similar argument is true about event-to-
entity connections, because these associations are
also static. It follows that we need to consider
relation scheme R that is produced only from
ssn
cco=y --
1,1)
accoun~ ~ IN
TF~R(~S'~
~
Fig.6.Aportion
ofaTEER
diagram
forabanking
database.

14. 318 D. De)' et al. / Decision Support S~vstems15 (1995) 305-321
either temporal attributes or temporal relation-
ships. Let X,YcR. Assume that the non-trivial
r
TD X--, Y exists. This means that there are
tl,t 2~ r such that t1(KUY)=t2(KuY) and
tl(X) ~ t2(X), where r is a relation on R. Clearly,
the attributes in X and Y have different time-de-
pendencies, i.e., they do not necessarily change
simultaneously. In our design approach, they must
belong to different relation schemes. Therefore,
no non-trivial TD could be satisfied by R. Since
R is in 4NF, it is also in TNF.
5. Illustration of the TEERM
Table 3
Relational schemes for the example banking database
client: [ssn, street, city, zip]
client name: [ssn, TS, name]
account: [account no, date opened]
account balance: [account no, TS, balance]
savings: [a c c o u n t_n o, minbalance]
checking: [a c c o u n t_n o, last_check_no]
interest: [a c c o u n t _s t a t u s, TS, int ratel
transaction: [t r a n s a c t i o n_n o, event_time,
eventdate, type,
amount, from. accountno,
to_accountno]
account owner: [ssn, accountno]
interest schedule: [accountno, account_status, TS]
The model has been successfully applied to
several simulated cases. This section illustrates
the use of the extended model through an appli-
cation to a banking example.
5.I. A case study: banking database
Consider a portion of a banking database as
shown in Fig. 6, having five basic entities, and
four relationships.
The two "/s-a" relationships show the general-
ization from SAVINGS and CHECKING to AC-
COUNT. The relationship "CLIENT has AC-
COUNT" is static because the only event that
affects this relationship is singular for the entity
"ACCOUNT." Lastly, "SAVINGS is paid IN-
TEREST" is a temporal relationship because the
status of a savings account may change over time,
and the rate at which interest is paid would
change accordingly. All of the attributes of the
Table 2
List of attributes and relationships affected by different events
Event Attribute Relationship
Transaction balance (SAVINGS) SAVINGS is paid
balance (CHECKING) INTEREST
last check no
Opening of account no CLIENT has
account date_opened ACCOUNT
Change of int rate
interest rate
relevant entities are illustrated by the small cir-
cles, with the names appearing next to the circles.
The only composite attribute is "address." Three
events, Transaction, Opening of Account and
Change of Interest Rate, are shown. Transaction is
recurrent for both CLIENT and ACCOUNT.
Opening of Account is recurrent for CLIENT, but
singular for ACCOUNT, assuming that an ac-
count is not reallocated to a different client after
the owner of that account chooses to close it.
Change of Interest Rate is recurrent for INTER-
EST. For the sake of clarity, we do not show the
event-to relationship/attribute connections. The
attributes and relationships affected by these
events are given in Table 2.
5.2. Design of banking database
This section illustrates the design process us-
ing the above banking example. The following
changes are made to the TEER diagram in Fig. 6:
(1) The attribute "balance," being common to
both "SAVINGS" and "CHECKING" is
propagated to be an attribute of the entity
"ACCOUNT."
(2) The attribute "address" is identified as a
quasi-static attribute, and is also decomposed
into the constituent elementary attributes.
(3) "Transaction" is the only event with at-
tributes such as "transactionno," "time,"
"date," "type," "amount," "from account

15. D. De),et aL/ DecisionSupportSystems15 (1995)305-321 319
no" and "to account no." Therefore, all
events other t-han "Tra-nsaction" are elimi-
nated. The view of this event is perceived as
being a natural view to the user and, there-
fore, is retained. The only relevant event-
to-entity connection is the one between
"Transaction" and "ACCOUNT." However,
since "Transaction" already has
"from account no" and "to account no" as
attribu-tes, no additional nav-~gational-link is
necessary.
Application of the mapping rules outlined
above results in the schemes shown in Table 3.
The entities CLIENT, ACCOUNT, SAVINGS,
CHECKING and INTEREST are represented by
the relation schemes client, account, savings,
checking and interest, respectively. The relation
scheme client name represents the temporal at-
tribute "name" of entity CLIENT. Similarly, the
relation scheme account balance represents the
temporal attribute "balance" of the entity AC-
COUNT. The temporal attribute "int rate"
was simply appended to the relation scheme
interest since it had only the key attribute
"account status." The relationships "CLIENT
has ACCOUNT" and "SAVINGS is paid IN-
TEREST" are represented by the relation
schemes account owner and interest schedule
respectively. The scheme transaction represents
the only relevant event Transaction.
Integrity constraints
Existence constraint: No relation instance on
the above schemes can have null values for key
attributes and TS. For example, a relation on the
scheme account balance cannot have null values
for account no and TS.
Referential constraint: The following referen-
tial constraints should be enforced:
(1) client to client name (foreign key: s s n)
(2) account to account balance (foreign key:
account no)
(3) account to savings (foreign key:
account no)
(4) account to checking (foreign key:
account no)
(5) account to account owner (foreign key:
account no)
(6) client to account owner (foreign key: ss n)
(7) account to interest schedule (foreign key:
account no)
(8) interest to interest schedule (foreign key:
account st a t us-)
Others: There is some redundancy in the de-
sign, because the relation on the scheme transac-
tion stores information that is also in the relation
on the scheme account balance. The following
additional integrity constraints are needed.
For every tuple x in the relation on the
scheme transaction, there must be two tuples,
Yl and Y2 in the relation on the scheme
account balance such that x(amount) =
lyl(ba l a"nce) -Y2(ba lance)l and one and only
one of the following two holds
(1) x(event_time) E yl(TS) and
x(event t i me) ~ cl(y2(TS))
(2) x(event_t i me) ~y2(TS) and
x(event_t i me) ~ x{cl}(yl(TS)).
Here,la) denotes the absolute value of a real
number a. The closure (denoted as "cl") of a set
b is defined as: cl(b) = b u b', where b' is the set
of all of limit points of b. For example [1,9]
represents the closure of the interval [1,9).
6. Conclusion
Although considerable amount of research has
been carried out in the area of temporal
databases, the topic of temporal database design
has not received much attention in the literature.
The design process for static databases does not
work for temporal databases because of lack of a
temporal conceptual model and a step-by-step
procedure for converting that model into a logical
database scheme. This work makes two contribu-
tion. First, it proposes a conceptual model, called
the Temporal Event-Entity-Relationship Model
(TEERM). The TEERM is based on the E-R
model, and uses events as additional constructs.
Although the representation of events can intro-
duce some redundancy into the model, it allows
one to capture the dynamic behaviour of entities,
relationships and their attributes. Second, this
research also formally describes how the TEERM
can be used for the logical design of temporal

16. 320 D. Dey et al. /Decision Support Systems 15 (1995) 305-321
relational databases, and demonstrates the con-
ceptual and logical design process with the help
of an example.
Batini et al. [2] suggest four desirable proper-
ties of conceptual models: (i) expressiveness, (ii)
simplicity, (iii) formality and (iv) minimality. We
believe that our model possesses all of these
properties. The TEERM is at least as expressive
as all the other conceptual data models found in
the literature. It retains the expressive power of
the extended E-R model, and adds to it by cap-
turing the dynamic nature of entities and rela-
tionships using events as an additional construct.
It allows us to specify dynamic constraints and
provide an alternate view of data. Batini et al. [2]
also suggest two desirable properties for graphi-
cal representation schemes: (i) graphic complete-
ness and (ii) ease of reading. The TEERM graph-
ical representation is complete as well as easy to
read.
The issue of completeness of a conceptual
data model is mainly an empirical proposition.
Consider, for example, the E-R model. A long
history of use and refinement (for example, the
introduction of data abstractions such as aggrega-
tion, generalization and specialization) of the
model has shown that the extended E-R model
[28,2] can reasonably model most real world situ-
ations as snapshots. The temporal extension of
the E-R model proposed here is believed to have
the potential to be a useful conceptual model.
Various types of future research are possible.
One direction is the development of a query
language such as GORDAS for this model. An-
other possibility is to describe formally how in-
tegrity constraints can be generated using the
TEERM. The new construct event would be use-
ful in automated verification of consistency and
completeness of the conceptual design.
References
[1] Alan, I., Towards an Implementation of Database Man-
agement Systems with Temporal Support, Proceedings of
the Second International Conference on Data Engineer-
ing, pp. 374-381, February 1986.
[2l Batini, C., S. Ceri, and S.B. Navathe, Conceptual
Database Design, Benjamin/Cummings, 1992.
[3] Ben-Zvi, J., The Time Relational Model, Ph.D. Diss.,
UCLA, 1982.
[4] Chen, P.P.-S., The Entity-Relationship Model - Toward
a Unified View of Data, ACM Transactions on Database
Systems, 1(1), pp. 9-36, March 1976.
[5] Clifford, J. and A.U. Tansel, On an Algebra for Histori-
cal Relational Databases: Two Views, ACM SIGMOD
Record, 14(4), pp. 247-265, December 1985.
[6] Date, C.J., Relational Database: Selected Writings, Ad-
dison-Wesley, 1986.
[7] Dey, D., Temporal Relations and Temporal Normal
Form, Working paper, Louisiana State University, 1994.
[8l Dey, D., T.M. Barron, and A.N. Saharia, Logical Design
of Temporal Databases: A Decision Theoretic Approach,
Working paper, University of Rochester, 1994.
[9] Dey, D., T.M. Barron, and V.C. Storey, Events in Repre-
sentation of Temporal Data, Proceedings of the Second
Annual Workshop on Information Technologies and Sys-
tems, pp. 255-261, Dallas, Texas, December 1992.
[10] Dubois, E., J. Hagelstein, E. Lahou, F. Ponsaert, A.
Rifaut, and F. Williams, The ERAE Model: A Case
Study, in Information Systems Design Methodologies:
Improving the Practice, T.W. Olle, H.G. Sol and A.A.
Verrijn-Stuart (eds.), Elsevier Science Publishers B.V.,
North Holland, pp. 87-105, 1986.
[11] Elmasri, R. and G.T.J. Wuu, A Temporal Model and
Query Language for ER Databases, Proceedings of the
Sixth International Conference on Data Engineering, pp.
76-83, February 1990.
[12] Elmasri, R., I. EI-Assal, and V. Kouramajian, Semantics
of Temporal Data in an Extended ER Model, Entity-Re-
lationship Approach: The Core of Conceptual Modelling,
H. Kangassalo (ed.), Elsevier Science Publishers B.V.,
North Holland, pp. 239-254, 1991.
[13] Elmasri, R., G.T.J. Wuu, and V. Kouramajian, A Tempo-
ral Model and Query Language for EER Databases, in
Temporal Databases, A. Tansel et al. (ed.),
Benjamin/Cummings, 1993.
[14] Ferg, S., Modelling the Time Dimension in an Entity-Re-
lationship Diagram, Proceedings 4th International Con-
ference on Entity-Relationship Approach, Chicago, pp.
280-286, October 1985.
[15] Gadia, S.K., A Homogeneous Relational Model and
Query Languages, ACM Transactions on Database Sys-
tems, 13(4), pp. 418-448, December 1988.
[16] Gehani, N.H., H.V. Jagadish, and O. Shmueli, Event
Specification in an Active Object-Oriented Database,
ACM Sigmod Record, 21(2), pp. 81-90, 1992.
[17] Goldstein, R.C., Database: Technology and Manage-
ment, John Wiley, 1985.
[18] Klopprogge, M.R., Term: An Approach to Include the
Time Dimension in the Entity-Relationship Model, En-
tity-RelationshipApproach to Information Modellingand
Analysis, P.P. Chen (ed.), pp. 477-512, 1981.
[19] Klopprogge, M.R. and P.C. Lockemann, Modelling Infor-
mation Preserving Databases: Consequences of the Con-
cept of Time, Proceedings of the Ninth International

17. D. Dey et al. / Decision Support Systems 15 (1995) 305-321 321
Conference on Very Large Data Bases, pp. 319-416,
November 1983.
[20] Kouramajian, V. and R. Elmasri, Mapping of 2-D Tem-
poral Extended ER Models into Temporal FNF and
NFNF Relational Models, Proceedings of the Tenth In-
ternational Conference on Entity-Relationship Ap-
proach, pp. 671-689, San Mateo, CA, October 23-25,
1991.
[21] Navathe, S.B. and R. Ahmed, A Temporal Relational
Model and a Query Language, Information Sciences, 49,
pp. 147-175, 1989.
[22] Schiel, U., The Time Dimension in Information Systems,
Information Systems: Theoretical and Formal Aspects,
A. Sernadas, J. Bubenko and A. Oiiv6 (eds.), Elsevier
Science Publishers B.V., North-Holland, 1985.
[23] Segev, A. and A. Shoshani, The Representation of a
Temporal Data Model in the Relational Environment,
Proceedings of the Fourth International Working Con-
ference on Statistical and Scientific Database Manage-
ment (SSDBM), M. Rafanelli, J.C. Klensin and P. Svens-
son (eds.), Rome, Italy, June 1988.
[24] Snodgrass, R., The Temporal Query Language TQuel,
ACM Transactions on Database Systems, 12(2), pp. 247-
298, June 1987.
[25] Storey, V.C., View Creation: An Expert System for
Database Design, ICIT Press, 1988.
[26] Storey, V.C., Relational Database Design Based on the
Entity-Relationship Model, Data and Knowledge Engi-
neering, 7, pp. 47-83, 1991.
[27] Tauzovich, B., Towards Temporal Extensions to the En-
tiff-Relationship Model. Proceedings of the Tenth Inter-
national Conference on Entity-Relationship Approach,
T.J. Teorey (ed.), San Mateo, CA, pp. 163-179, October
23-25, 1991.
[28] Teorey, T.J., Database Modelling and Design: The En-
tity-Relationship Approach, Morgan Kaufmann, 1990.
[29] Theodoulidis, C., P. Loucopoulos, and B. Wangler, A
Conceptual Modelling Formalism for Temporal Database
Applications, Information Systems, 16(4), pp. 401-416,
1991.
Debabrata Dey is Assistant Professor of Information Systems
and Decision Sciences at the College of Business Administra-
tion at Louisiana State University. He received his Ph.D.
degree in Computers and Information Systems from the
William E. Simon Graduate School of Business Administra-
tion at the University of Rochester. His current research
interests are in temporal and probabilistic data models and
performance evaluation of database systems. Dr. Dey has
published articles in Information Systems Research and other
conference proceedings.
Terence M. Barron is Associate Professor of Information
Systems and Operations Management at the College of Busi-
ness Administration, University of Toledo. Before this, he was
at the William E. Simon Graduate School of Business Admin-
istration, University of Rochester. His research interests in-
clude economics of information, economics of information
system management, and the impacts of information technol-
ogy on organizations and markets. His research has appeared
in Information Systems Research, Decision Support Systems,
Journal of Organizational Computing, and other journals and
conference proceedings.
Veda C. Storey is Assistant Professor of Computers and
Information Systems at the William E. Simon Graduate School
of Business Administration, University of Rochester. She has
research interests database management systems and artificial
intelligence. Her research has been published in ACM Trans-
actions on Database Systems, Information Systems Research,
Management Information Systems Quarterly, Data and
Knowledge Engineering, and the Very Large Data Base Jour-
nal. She is the author of View Creation: An Expert System for
Database Design, a book based on her doctoral dissertation,
and published by ICIT (International Centre for Information
Technology) Press in 1988. Dr. Storey received her doctorate
in Management Information Systems from the University of
British Columbia, Canada, in 1986.