Content uploaded by Richard Snodgrass
Author content
All content in this area was uploaded by Richard Snodgrass
Content may be subject to copyright.
A Taxonomy of Time m Databases
March, 1985
Richard Snodgrassf
IIsoo Ahn
Department of Computer Science
University of North Carolina
Chapel H111, NC 27514
Abstract
The need for aupporttng trme varying :njormation
in
databa8e8 has been recogntzed for qurte
some trme Many authors have propoeed numerous scheme8 to satrujy this need by tncor-
poratrng one or two trme attrrbutes in the database. Unfortunately, there has been conju-
8;on concermng the terminology and definition of theae trme attribute8 Thrs paper pro-
poae8 a new taxonomy of three trmea for u8e
in
databasea, one that 18 more cleanly defined,
that may be conceptuabzed tn a prctoraal fashron, and that defines several krnda of databases
dtferentrated by therr abtbty to
represent
temporal tnjormatton The paper argue8 that ju-
ture database management ayatema should aupport all three ttme8 to fully capture time vary-
Ing behavror
1. Introduction
The need for recordmg time varymg mforma-
tlon m databases has been recognized for quite
some time [Bubenko 19761 There have been
slgmficant research actlvltles m formulatmg a
semantics of time at the conceptual level [Anderson
1982, Breutmann et al 1979, Bubenko 1977, Ham-
mer & McLeod 1981, Klopprogge 19811, developmg
a model for time varying databases analogous to
the relational model for static databases [Chfford
& Warren 1983, Codd 1979, Sernadas 19801, and
the design of temporal query languages [Arlav &
Morgan 1981, Ben-Zvl 1982, Jones & Mason 1980,
Snodgrass 19821 Recently, It has been argued that
a single time attrlbute IS msufficlent, and that two
time attrlbutes are necessary to fully capture
time-varying informatlon Unfortunately, there
t The work of tlus author wan supported by NSF grant
DCR-8402339 and by an IBM Faculty Development Award
Permlulon
to copy wIthout fee all or part of this matenal IS granted
prowded that the copies are not made or dlstnbuted for duzct
commercml advantage, the ACM copyrIght notICe and the Me of the
pubhcatton and I@ date appear, and notxe IS given that copymg IS by
permlsslon of the Assoclatlon for Computmg Machmery To copy
othervnse, or to repubhsh, reqmres a fee and/or specific pernnsslon
@ 1985 ACM 0-89791-160-l/85/005/0236 $00 75
236
has been some confuslon concernmg termmology
and the defimtlon of these time attributes
The next section will discuss the various
characterlstlcs attributed to the two times, the
third section will Illustrate the dlfficultles posed by
the vague defimtlon of these times The fourth sec-
tion will present a new taxonomy of time m data-
bases to replace the two previous times The new
taxonomy consists of three dlstmct time concepts
and four distinct kinds of database management
systems (DBMS), differing m their support of the
new time concepts The final section will compare
the new taxonomy with the old one
2. Prevlour Characterisatlons
In this paper, we WI!! use the terms phyetcal
trme and logtcol trme [Lum et al 19841 to discuss
the concepts as they appear m the literature Phy-
sical time has also been called transaction time
[Copeland & Maler 19841, registration time [Ben-
Zvi 19821, data-valid-time-from/to [Mueller &
Stembauer 19831, and start/end time [Reed 19783
Loglcal time has also been called event time [Cope-
land & Maier 19841, effective time [Ben-Zvl 19821,
state [Clifford & Warren 19831, vahd time
[Snodgrass 19841, and start/end time [Jones et al
1979, Jones & Mason 19801 Each paper has
defined the terms in slightly different ways There
IS general agreement on the definitions, but little
consensus concerning the details The differences
identified by previous authors between physical
and logical time may be characterized m terms of
three related attributes The purpose of this sec-
tion 1s to discuss these attributes and to examine
their contrrbutlons to the concepts of logical and
physlcal trme We will proceed by stating the view
presented m the literature, then follow m the next
section with an analysis of this view This sum-
mary 1s drawn primarily from the works of Cope-
land and Maler [Copeland & Maler 19841, Dadam
et al [Dadam et al 19841, and Lum et al [Lum et
al 19841, although others have also noticed that a
single time stamp or a pair of time stamps IS rnade-
quate
2.1. Reality versus Representation
The correspondence of the model stored m
the database with reality IS one aspect that IS used
to dlstmgulsh between logical and physical time
Logical time IS characterized as the time that an
event occurs m reality, physlcal time IS character-
ized as the time when the data concerning the
event was stored m the database Examples include
retroactive salary changes, release dates of
engineering versions, scheduled events that have
not yet occurred, and scheduled events that were
suppose to occur, yet did not
2.2. Update Flexibility
The types of update permitted to time values
1s another way that logical and physical time have
been dlfferentlated m the literature A physical
time value may be added to the database, yet once
it has been added, it may not be changed The
concept of a non-stop running clock 1s evoked to
indicate how the time values are generated Logl-
cal time values, on the other hand, are always sub-
ject to change, smce discrepancies between the his-
tory (a sequence of events or time Intervals) as it
actually occurred and the representation of the
history as stored m the database will often be
detected after the fact The dlstmctlon then IS
between permitting only appends and permitting
arbitrary modlficatlons
2.3. Application Dependency
The third attribute used to dlstmgulsh
between physlcal and logrcal time 1s that of apph-
cation dependency Logical time IS generaly
characterized m the hterature as being
apphcatlon-dependent, while physical time IS con-
sidered to be apphcatlon-Independent While this
attribute IS the hardest to define precisely, It IS
usually equated with the control the user of the
DBMS has over the value of a temporal domain m
the database If the value can be computed
automatically by the DBMS, the value must neces-
sarily be independent of any particular apphcatlon
and must have a simple semantics An
apphcatlon-dependent time value, on the other
hand, must have been defined exphcltly by the
user Its value must also be specified by the user,
and may thus be quite complex The mtegrlty of
this data must be maintained by the user, the
value must be modifiable by users when a
discrepancy IS discovered between the real world
and the database model Hence, the DBMS cannot
guarantee the integrity of logical time values The
relatlonshlp between the types of time ldentlfied m
the literature and their attributes IS shown m Fig-
ure 1
3. Comparlron
Two of the attributes dlfferentlatmg physical
and loglcal time, those of reality versus representa-
tion and update flexlblhty, are reasonably precise
concepts They are also strongly related to each
other, m that a time value that records when the
data was stored cannot later be changed The
third attribute, that of application dependence, IS
unfortunately fraught with dlfficultles It makes
certain assumptions of which the most crucial IS
that all actlons performed by the DBMS are
apphcatlon-independent This assumption IS not
valid, at least to a certain degree The database
schema, which directs most actlons by the DBMS,
IS certainly apphcatlon-dependent Many DBMS’s
allow the speclficatlon of mtegrlty constramts,
which are apphcatlon-dependent, yet are mter-
preted automatically by the DBMS without user
mterventlon Apphcatlon-dependent values can be
handled by the DBMS if their semantics can be
defined m terms the DBMS can interpret
An example often cited of the dlstmctlon
between apphcatlon-Independent and apphcatlon-
dependent time IS a retroactive salary raise, where
the time at which the raise was recorded (say,
12/l/83) 1s considered application-Independent, as
it IS not under the user’s control, whereas the time
at which the raise was to take effect (say, 8/l/83)
1s considered apphcatlon-dependent, as It IS m some
sense arbitrary and under the user’s control
237
Exammmg this sltuatlon more closely, however,
can result m precisely the reverse semantics In
many commercial settings, salary updates are
batched together and executed against the data-
base only once or twice
a
month, whereas pay-
ments might be made at the last possible date to
mmimlze cashflow problems, and hence may occur
at arbitrary trmes during the month That a
salary update was performed by the DBMS on
12/l/83 may simply be an artifact of when salary
updates are entered, which IS apphcatlon depen-
dent On the other hand, the user has no control
over when the salary was changed, and hence the
effective date IS m thus sense application-
independent
The pomt to be made IS that charactertzmg a
time value as being dependent or independent of
an apphcatlon mvolves fairly subtle Issues of the
semantics of that value, both as interpreted wlthm
the DBMS and as applied to the srtuatlon being
modeled Given these drfficultres, this attribute
appears to be less than ideal m dlfferentlatmg phy-
sical and logical time
Reference Termmology Append Apphcatlon Representation
-Only Independent vs Reality
[Arlav & Morgan 19821 Time Yes Yes Representation
/Ben-Zvr 19821 Reglstratron Yes Yes Representation
Effective No Yes Reality
[Clifford & Warren 19831 State No Yes
[Copeland & Marer 19841 Transaction Yes Yes Representation
Event (1) No No Reality
[Dadam et al 19841 & Physical ON0 yes Representation
[Lum et al 19841 Logical (1) No Reality
[Jones et al 19791 & Start/End Reahty
[Jones & Mason 19801 User Defined MN0 yes No Reality
[Mueller & Stembauer 19831 Data-Vahd- (3) Yes Representation
Time-From/To (4
[Reed 1978) Start/End Yes Yes Representation
[Snodgrass 19841 Valid Time No Yes Reality
Notes
(1) Not actually supported by the system
(2) Can make corrections only
(3) Can make changes only rn the future
(4) Reality 1s indicated only m the future
Figure
1
Types of Trme
4. A New Characterlcation
The previous section argued that physical
and logical time are not well defined, and that
apphcatron time IS partrcularly problematrc In
this section we mtroduce a new taxonomy of time
for use m databases Thus taxonomy 1s more
clearly defined, being based on reahty versus
representation, may be conceptualized In a
238
plctorlal fashion which aids understanding, and
defines several kinds of databases differentiated by
their ability to represent temporal mformatlon
Though the followmg discussion 1s based on the
relational model, slmllar arguments also apply to
hlerarchlcal or network models We WI!! first dls-
cuss static databases, focusmg on their representa-
tional madequacles We then define three new time
concepts to replace the vaguely defined physical
and logical time We introduce each time concept
by discussing the features associated with a partlc-
ular kind of DBMS supporX%g that time concept
4.1. Statfc Database8
Conventional databases model the real world,
as It changes dynamically, by a snapshot at a par-
ticular point In time A 8tote or an tnatance of a
database IS its current contents, which does not
necessarily reflect the current status of the real
world Updatmg the state of a database 1s per-
formed using data mampulatlon operations such as
msertlon, deletion or replacement, takmg effect as
soon as it IS committed In this process, past states
of the database, and those of the real world, are
discarded and forgotten completely We term this
type of database a stattc databa8e
In the relational model, a database 1s a collec-
tion of relotton8 Each relation consists of a set of
tuplee with the same set of ottrtbutes, and 1s usu-
ally represented as a 2-dimensional table (see Fig-
ure 2) As changes occur m the real world, changes
are made m this table
Figure
2 A Static Relation
For example, an Instance of a relation ‘faculty’ at a
certain moment may be
pigi$FJ
and a query m Quel, a tuple calculus based
language for the INGRES database management
system [Held et al 19751, requestmg Merrle’s rank,
range
off is faculty
retrieve (frank)
where f name -
“Merrle”
yields
l.=l
rank
1 full J
There are many situations where this static data-
base relying on snapshots 1s inadequate For exam-
ple, it cannot answer queries such as
What was Merne’s rank 2 years ago?
(hlstoncal query)
How did the number of faculty change
over the last 5 years? (trend analysis)
nor record facts like
Merrle was promoted to a full professor
startmg last month (retroactive change)
James IS Jommg the faculty next month
(postactive change)
Without system support m this respect, many
applications have had to mamtam and handle tem-
poral mformatlon in an ad-hoc manner
4.2. Static Rollback Databaaer
One approach to resolve the above
deficiencies 1s to store all past states, Indexed by
time, of the static database as it evolves Such an
approach requires a representation of tranaactton
trme, the time the mformatlon was stored m the
database A relation under this approach can be
illustrated conceptually m three dimensions (Figure
3) with transaction time serving as the third axis
The relation can be regarded as a sequence of
static relations indexed by time By movmg along
the time axis and taking a vertical slice of the
cube, it IS possible to get a snapshot of the relation
as of some time m the past (a static relation) and
make queries upon it The operation of taking a
vertical slice IS termed rollback, and a database
supporting it is termed a statrc roNbock database
Changes to a static rollback database may only be
made to the most recent static state The relation
illustrated m Figure 3 had three transactions
applied to It, starting from the null relation
(1)
the addition of three tuples, (2) the addltlon of a
tuple, and (3) the deletion of one tuple (entered in
the first transaction) and the addltlon of another
tuple Each transactlon results m a new static rela-
tion being appended to the front of the cube, once
a transaction has completed, the static relations m
the static rollback relation may not be altered
239
ction
Figure 3 A Static Rollback Relatron
One limitation of supporting transaction time
IS that the history of database actrvltles, rather
than the history of the real world, IS recorded A
tuple becomes valid as soon as it IS entered into
the database as m a static database There 1s no
way to record retroactlve/postactrve changes, nor
to correct errors m past tuples Errors can some-
times be overridden (if they are m the current
state) but they cannot be forgotten
Implementing a static rollback relation in this
way 1s lmpractlcal, due to excessive duphcatlon
the tuples that don’t change between states must
be duplicated In the new state Another approach
that partially addresses this difficulty appends the
start and end points of the transaction time to
each tuple, mdlcatmg the points m time when the
tuple was m the database A typical relation in
this approach looks like Figure 4 The double vert-
ical bars separate the non-temporal domains from
the DBMS-maintained temporal domams The
latter domams do not appear m the schema for the
relation, but may rather be considered part of the
overheads associated with each tuple Note the
fact that Merrle was prevrously an associate pro-
fessor, a fact which could not be expressed m the
example for a static database
name rank transaction time
(start) (end)
Merrre associate 08125177 12/15/82
Merrre full 12/15/82 00
Tom associate 12107182 00
Mike assistant 01/10/83 02125184
Figure 4 A Static Rollback Relation
Any query language may be converted to one
which may query a static rollback database by
addmg a clause effecting the rollback TQuel (Tem-
poral QUE+y Language) [Snodgrass 1984,
Snodgrass 19851, an extension of Quel for temporal
databases, augments the retrieve statement with
an 118 of clause to specify the relevant transactron
time The TQuel query
range of
f
is
faculty
retrieve
(frank)
where
f name
= “Merrle”
alB of “12/10/82”
on a ‘faculty’ relation shown in Frgure 4 WI!! find
the rank of Merrre as of 12/10/82
rank
El
associate
Note that the result of a query on a static rollback
database 1s a pure static relation
The concept of transaction time has appeared
m several systems, mcludmg GemStone [Copeland
B Maler 19841, MDMIDB (Model Data
Management/Database) [Anav & Morgan 19821,
and the SWALLOW obJect store [Reed 1978, Svo-
bodova 19811
4.3. Hirtorlcal Databaser
While static rollback databases record a
sequence of static states, histortcoi databases
record a single hrstorrcal state per relation, storing
the history as It IS best known As errors are
discovered, they are corrected by modlfymg the
database Previous states are not retained, so it 1s
not possible to view the database as it was m the
past There 1s no record kept of the errors that
have been corrected Hrstorrcai databases are slml-
lar to static databases in this respect Hlstorrcal
databases must represent ualtd ttme, the time that
the stored mformatlon models I eahty
Figure 5: An Historical Relation
Hlstorlcal databases may also be illustrated
in three dlmenslons (see Figure 5) Though tts
240
illustration looks similar to one for the static roll-
back database (m fact, for many transaction
sequences, it will be identical), the label of the time
axis has been changed to valid time and the
semantics are more closely related to reality,
instead of update history Therefore more sophis-
ticated operations are necessary to manipulate the
complex semantics of valid time adequately, com-
pared to the simple rollback operation
A second dlstmctlon between historical and
static rollback databases IS that historical DBMS’s
support arbitrary modification, whereas static roll-
back DBMS’s only allow static states to be
appended The same sequence of transactions
which resulted in the static rollback relation m
Figure 3 also results m the historical relation m
Figure 5 However, a later transaction (not possible
on a static rollback relation) has removed an
erroneous tuple inserted on the first transaction
(compare Figures 3 and 5 closely) Static rollback
DBMS’s can rollback to an mcorrect previous
static relation, historical DBMS’s can record the
current knowledge about the past
Historical databases also mcorporate user-
defined time, which will be discussed m the context
of temporal databases Both valid time and user-
defined time concern modelmg of reality, and so it
is appropriate that they should appear together
Historical databases require more sophisti-
cated query languages There have been two such
languages developed LEGOL 2 0 [Jones et al
19791, based on the relational algebra, and
TQuel
[Snodgrass 19841, based on Quel [Held et al 19753,
a relational calculus query language LBGOL t 0
[Jones & Mason 19801 was developed for writing
complex rules such as those m leglslatlon or high
level system specification where the correct han-
dling of time is important It also attaches to each
tuple two time attributes which delimit the period
of existence for the associated member of the
entity set
TQuel supports the expression of historical
queries by augmenting the tetrteue statement- with
a ualrd clause to specify how the lmpllcrt time
domain IS computed, and a when predicate to
specify the temporal relationship of tuples partrcl-
patmg m a derivation These added constructs
handle complex temporal relationships such as
start of, precede, and overlap
As with static rollback databases, lmplement-
mg a historical relation directly as above is imprac-
tical Figure 6 illustrates an alternative appending
the endpoints of the valid time to each tuple, mdl-
catmg the points m time when the tuple accurately
modeled reality Like the transaction time in
static rollback databases, the vahd time IS not
mcluded m the relation schema
name rank valid time
(from) (to)
Merrle associate 09/01/77 12/01/82
Merrre full 12/01/82 00
Tom associate 12/05/82 00
Mike assistant 01/01/83 03/01/84
Figure
6 A Historical Relation
The TQuel query requestmg Merne’s rank when
Tom arrived,
range
of
fl
is
faculty
range of
f2
is
faculty
retrieve
(fl rank)
where
fl name - “Merrre”
and
f2 name - “Tom”
when fl overlap start of
f2
on the historical relation ‘faculty’ m Figure 6 yields
Note that the derived relation IS also an his-
torical relation, which may be used m further his-
torical queries While both this query and the
example given for a static rollback relation seem to
query Merne’s rank on 12/05/82, the answers are
different The reason IS that Merrle was promoted
on 12/01/82, but this mformatlon was recorded m
the database two weeks later Hence, the database
was mconsistent with reality for that period of
time In the historical database, the error was
corrected, but it IS not possible to determine that,
at least for a while, the database was mconsrstent
Historical databases have been the subject of
several research efforts, mcludmg CSL (Conceptual
Schema Language) [Breutmann et al 1979], TERM
(Time-extended Entity Relationship Model) [Klop-
progge 19811, the mtenslonal logic IL, [Clifford &
Warren 19831, and AiUPPL-ZZ (Associative Memory
Parallel Language II) [Fmdler t Chen 19711
241
4.4. Temporal
Databases
Benefits of both approaches can be combmed
by supporting both transactron time and valid
time While a static rollback database views tuples
valid at some time as of that time, and a hrstorrcal
database always views tuples valid at some
moment as of nour, a temporal DBMS makes rt
possible to view tuples valid at some moment seen
as of some other moment, completely capturing the
history of retroactrve/postactrve changes
We use the term temporal database to
emphasize the need for both vahd time and tran-
saction trme m handling temporal mformatlon
Since there are two time axes mvolved now, rt
should be illustrated m four drmensrons (Figure 7
d
e Id
time
shows a stngIe temporal relation) A temporal
relation may be thought of as a sequence of hrstor-
rcal states, each of which IS a complete hrstorrcal
relation The rollback operation on a temporal
relation selects a particular hrstorrcal state, on
which an hrstorrcal query may be performed Each
transaction causes a new hrstorrcal state to be
created, hence, temporal relatrons are append-only
The temporal relation m Figure 7 is the result of
four transactions, starting from a null relation (1)
three tuples were added, (2) one tuple was added,
(3) one tuple was added and an exrstmg one
deleted, and (4) a previous tuple was deleted
(presumably rt should not have been there m the
first place)
d I/ valid
e time
Figure 7 A Temporal Relation
name
Merrle
Merrle
Merrle
Tom
Tom
rank
associate
associate
full
full
associate 12105182
I I
12/05/82
time
(to)
12,:,82
00
cm 12/01/82 12/07/82
00 12/07/82 00
transactron
time
transaction time
Mike assistant 01/01/83 00 01/10/83 02125184
Mrke assistant 01/01/83 03/01/84 02125184 00
Flgure
8 A Temporal Relation
For example, the relation m Frgure 6 ~111
look like Frgure 8 after addmg transactron time It
shows that Merrle started workmg on 09/01/77,
mformatron that was entered mto the database on
08125177 as a postactrve data Then she was pro-
moted on 12/01/82, but the fact was recorded on
12/15/82 retroactively Tom was entered mto the
database on 12/01/82 as Jommg the faculty as a
full professor on 12/05/82, the fact that he was
actually an associate professor was noted on
12/07/82 Mike left the faculty effectrve on
03/01/84, whrch was recorded on 02125184 Note
all the details of hlstory captured here, which were
not expressible m other more restrlctlve databases
The TQuel query
range of
fl
is
faculty
range of f2 is
faculty
retrieve (fl rank)
where
fl
name = “Merrle”
and
f2 name = “Tom”
when fl overlap start of
f2
as of “12/10/82”
on this relation determmes Merrre’s rank when
Tom arrived, according to the state of the data-
base as of 12/10/82 The result IS
242
rank valid time transaction time
(from) [to) (start) (end)
associate 09/01/77 co 08/25/77 12/15/82
This derived relation 1s a temporal rela:, )n, so
further temporal relations can be derived from It
If a similar query IS made as of 12/20/82, the
answer would be
full
because the fact was recorded
retroactively by that time
TRM (Time Relational Model) IS another
example of a temporal database [Ben-Zvr 19821
However, the query language defined for TRM 1s
not a temporal query language, because It can
derive only static relations
4.5. User-defined time
User-defined he [Jones & Mason 1980] is
necessary when addltlonal temporal mformatlon,
not handled by transactron or valid time, 1s stored
m the database As an example, consider the ‘pro-
motion’ relation shown m Figure 9 Since it is an
name rank
Merrre associate
Merrle full
Tom full
Tom associate
Mike assrstant
Mike left
T
event relatron, only one valid time IS necessary
The effectrve date IS the date shown on the promo-
tion letter that the promotron was to take effect,
the valid date IS the date the promotron letter was
signed, 1 e , the date the promotron was validated,
and the transaction date IS the date the mforma-
tron concerning the promotron was stored m the
database Merrre’s retroactive promotron to full
was srgned four days before rt was recorded m the
database The effective date IS apphcatron-specrfic,
rt 1s merely a date which appears on the promotron
letter The values of user-defined temporal
domains are not interpreted by the DBMS, and
are
thus the easiest to support, all that IS needed IS an
internal representation and input and output func-
tions Such domains will then be present m the
relation schema Conventronal DBMS’s supporting
apphcatron time mclude the ENFORM DBMS
[Tandem 19831, Query-by-Example [Bontempo
19831, an experimental version of INGRES [Over-
myer & Stonebraker 19821, and MrcroINGRES
[Relational 19841
Figure 9 A Temporal Event Relation
6. Conclusion0
Three kinds of time, transactron time, vahd
time, and user-defined trme, were introduced to
replace the vague formulatron of physical and logr-
cal time found m the hterature Database manage-
ment systems may be categorrzed m terms of their
support for handlmg temporal mformatron As
shown in Figure 10, two orthogonal criteria are
capablhtres for rollback and hlstorrcal queries
These criteria differentrate four types of databases
static, static rollback, hrstorrcal and temporal
Support of the rollback capability requires the
mcorporatron of transactron time, which concerns
the representation, support of hrstorrcal queries
requires the mcorporatron of valid time, whrch IS
assocrated with reality (see Figure 11) DBMS’s
supporting rollback are append-only, whereas those
n time
(end)
00
00
12/07/82
00
00
00
not supporting rollback allow updates of arbrtrary
mformatron The attributes assocrated with the
three kinds of time are rllustrated m Figure 12,
which should be compared to Figure 1
The new time concepts may be loosely com-
pared with those appearing prevrously m the htera-
ture Transaction time IS most closely associated
with physical time, and valid and user-defined time
with logrcal time However, as we have shown m
an earlier section, logrcal and physrcal time have
not been precisely defined, whereas the new terms
have been carefully defined by exammmg the
aspects they model and the lrmltatlons they impose
on the DBMS Figure 13 classrlles the time sup-
ported m exrstmg or proposed systems accordmg to
the new taxanomy
243
While fifteen years of research has focused on the authors’ knowledge, there has been nothing
formahzmg and lmplementmg statrc databases, published on formahzmg static rollback or tem-
only a few researchers have recently studied the poral databases, nor rmplementmg historrcal or
formahzatron of hrstorrcal databases (e g , [Chfford temporal databases The specral opportumtres
& Warren 19831) and the rmplementatlon of static promised by temporal databases are, at this time,
rollback databases (e g , [Lum et al 19841) To matched by the challenges m supportmg them
No Rollback Rollback _
Static Queries Static Statrc Rollback
Hlstorrcal Queries Hrstorrcal Temporal
Figure 10
Types of Databases
;y
Figure
11
Attributes of the New Kinds of Databases
~
Figure
It
Attributes of the New Kinds of Time
Reference
[Arlav & Morgan 19821
[Ben-Zvr 19821
[Bontempo 19831
[Breutmann et al 19791
[Clifford & Warren 19831
ICopeland & Marer 19841
[Fmdler & Chen 19711
[Jones & Mason 19801
[Klopprogge 19811
[Lum et al 19841
(Relatronal 19841
[Mueller & Stembauer 19831
[Overmyer & Stonebraker 19821
[Reed 19781
[Snodgrass 19851
[Tandem 19831
(Wrederhold et al 19751
System or Transaction Valid User-defined
Language Time Time Time
MDM/DB
TRM : v
QBE
d
CSL v
4 d
Gemstone v
AMPPL-II v
LEGOL 2 0 s v
TERM
AIM v
MrcroINGRES Al
- v
INGRES v
SWALLOW d
TQuel v v
ENFORM
TODS v
Flgure lg
Time Support m Exrstmg or Proposed Systems
244
Bibliography
[Anderson 19823 Anderson, T L Modehg Tame at
the Conceptual Level In Zmprovtng Data-
baee usabr[rty and Reqonsruene88, Ed P
Scheuermann Jerusalem, Israel Academic
Press, 1982 pp 273-297
[Ariav & Morgan 19811 Arlav, G and H L Mor-
gan MDM Handlrng the trme drmensron tn
generaltted DBMS Technical Report The
Wharton School, Umversity of Pennsyl-
vania May 1981
[Anav & Morgan 19821 Arlav, G and H L Mor-
gan MDM Embeddtng the hme Dtmen-
81on rn Znformatron System8 Technical
Report 82-03-01 Department of Decision
Sciences, The Wharton School, University
of Pennsylvania 1982
[Ben-Zvl 19821 Ben-Zvl, J The Ttme Relatronal
Model PhD Diss UCLA, 1982
[Bontempo 19833 Bontempo, C J Feature Anafg888
of Query-By-Ezample, m Relational Data-
base Systems New York Springer-Verlag,
1983 pp 409-433
[Breutmann et al 19791 Breutmann, B , E F Falk-
enberg and R Mauer CSL A language of
defintng conceptual schemarr, m Data Base
Architecture Amsterdam North Holland,
Inc , 1979
[Bubenko 19761 Bubenko, J A, Jr The temporal
dtmenston tn rnformatton modelang
Technical Report RC 6187 #26479 IBM
Thomal J Watson Research Center Nov
1976
[Bubenko 19771 Bubenko, J A, Jr The Temporal
hmensron tn Znformatzon Modelrng, in
Architecture
and
Models m Data Base
Management, Systems North-Holland Pub
co , 1977
[Clifford & Warren 19831 Clifford, J and D S
Warren Formal Semantrcs for Tame tn
Databa8eo ACM Tran8actlono
on Database
Syetem8, 8, No 2, June 1983, pp 214-254
[Codd 19791 Codd, EF Eztendrng the Database
Relaftonal Model to Capture More Mean-
rng ACM Transacttons on Database sys-
tem8, 4, No 4, Dee 1979, pp 397-434
[Copeland & Maier 19841 Copeland, G and D
Maler Maktng Smalltalk a Databaee Sy8-
tern In ProceLdrnge
of
the srgmod ‘84
Conference, June 1984 pp 316-325
[Dadam et al 19841 Dadem, P , V Lum and H-D
Werner Zntegratron
of
hme Ver82ons tnto
a Relatronal Databacle System In Proceed-
2ng8
of
the Conference on Verg Large Data
Baeea, 1984
[Fmdler t Chen 19711 Fmdler, N and D Chen
On the problem8
of
ttme retrteual, temporal
relattons, causalttg, and coezrstence In
Proceedtnge
of fhe hternattonal
Jornt
Conference on Arttjicral Zntellrgence,
Imperial College Sep 1971
[Hammer t McLeod 19811 Hammer, M and D
McLeod Database Deacttptron unth SDM
A Semantw Database Model ACM Tran-
sacttona on Database Sgatem8, 6, No 3,
Sep 1981, pp 351-386
[Held et, al 19753 Held, G D , M Stonebraker and
E Wong ZNGRES--A relatronal data base
management syetem Proceedrng8
of the
1975 Natronal Computer Conference, 44
(1975) pp 409-416
[Jones et, al 19791 Jones, S , P Mason and R
Stamper LEGOL 2 0 a relattonal
spectficatton language for complez rule8
Znformatton Systems, 4, No 4, Nov 1979,
pp 293-305
[Jones & Mason 19801 Jones, S and P J Mason
Handlrng the Ttme hmenaton tn a Data
Baee In Proceedrnge of the Znlernatronal
Conference on Data Ba8e8, Ed S M
Deen and P Hammersley British Com-
puter Society University of Aberdeen
Heyden, July 1980 pp 65-83
[Klopprogge 19811 Klopprogge, M R TERM An
approach to rnclude the trme drmensron tn
the entrty-relahonhp model In Proceed-
rnge of the Second Znternat2onal Confer-
ence on the Enhty Relatrond2p Approach,
Ott 1981
245
[Lum et al 19841 Lum, V, P Dadam, R Erbe, J
Guenauer, P Pastor, G Welch, H Werner
and J Woodfill Destgntng DBMS Support
for the Temporal Drmenslon In Proceed-
rnge of the S2gmod ‘84 Conference, June
1984 pp 115130
[Wlederhold et al 19751 Wlederhold, G , J F Fries
and S Weyl Structured organwalton of
cftntcaf data ba8e8 In Proceedtng8 of the
Nattonal Computer Conference, AFIPS.
1975
[Mueller & Stembauer 19831 Mueller, T and D
Stembauer E2ne Sprachochnrttstele zur
Vernonenkontroffe tn CAM-Datanbanken,
in Informatlk-Fachberlchte Berhn
Sprmger, 1983 pp 7695
[Overmyer & Stonebraker 19821 Overmyer, R and
M Stonebraker Zmplementatton
of a
hme
Ezpert rn a Databaee System SZGMod
Record, 12, No 3, Apr 1982, pp 51-59
[Reed 19781 Reed, D Namtng and Synchronztatron
tn a Decentralrted Computer System PhD
Doss M IT , Sep 1978
[RelatIonal 19841 RelatIonal Technologies, Inc
M2croZNGRES Reference Manual 1984
[Sernadas 19801 Sernadas, A Temporal Aspect8 of
Log2cal Procedure Definrtron Znformatton
Systems, 5 (1980) pp 167-187
[Snodgrass 19821 Snodgrass, R Monrtorrng Dtetrt-
buted Syetems A Relatronal Approach
PhD Doss Computer Science Department,
Carnegie-Mellon Umveraty, Dee 1982
[Snodgrass 19841 Snodgrass, R The Temporal
Query Language TQuel In Proceedwags of
the Thcrd ACM SZGAct-SZGMOD Sgmpo-
82um on Prtnctplea of Database Systems,
Waterloo, Ontario, Canada Apr 1984 pp
204-212
[Snodgrass 19851 Snodgrass, R A Temporal Query
Language 1985 (Submitted to Transac-
ttons on Database Systems)
[Svobodova 19811 Svobodova, L A reltable ob,+ect-
ortented data deposrtory
for a
dutrtbufed
computer In Proceedrng8 of 8th Sympo-
82um on Operattng System8 Pr2nctple8,
Dee 1981 pp 47-58
[Tandem 19831 Tandem Computers, Inc ENFORM
Reference Manual Cupertmo, CA, 1983
246