Conference PaperPDF Available

A Taxonomy of Time in Databases.



The need for supporting time varying information in databases has been recognized for quite some time. Many authors have proposed numerous schemes to satisfy this need by incorporating one or two time attributes in the database. Unfortunately, there has been confusion concerning the terminology and definition of these time attributes. This paper proposes a new taxonomy of three times for use in databases, one that is more cleanly defined, that may be conceptualized in a pictorial fashion, and that defines several kinds of databases differentiated by their ability to represent temporal information. The paper argues that future database management systems should support all three times to fully capture time varying behavior.
A Taxonomy of Time m Databases
March, 1985
Richard Snodgrassf
IIsoo Ahn
Department of Computer Science
University of North Carolina
Chapel H111, NC 27514
The need for aupporttng trme varying :njormation
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
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
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
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
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-
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
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
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-
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
(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
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
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
2 A Static Relation
For example, an Instance of a relation ‘faculty’ at a
certain moment may be
and a query m Quel, a tuple calculus based
language for the INGRES database management
system [Held et al 19751, requestmg Merrle’s rank,
off is faculty
retrieve (frank)
where f name -
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
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
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 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
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
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
[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
6 A Historical Relation
The TQuel query requestmg Merne’s rank when
Tom arrived,
range of
(fl rank)
fl name - “Merrre”
f2 name - “Tom”
when fl overlap start of
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
4.4. Temporal
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
e Id
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
associate 12105182
cm 12/01/82 12/07/82
00 12/07/82 00
transaction time
Mike assistant 01/01/83 00 01/10/83 02125184
Mrke assistant 01/01/83 03/01/84 02125184 00
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
range of f2 is
retrieve (fl rank)
name = “Merrle”
f2 name = “Tom”
when fl overlap start of
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
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
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
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
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
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
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
Attributes of the New Kinds of Databases
Attributes of the New Kinds of Time
[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
TRM : v
4 d
Gemstone v
LEGOL 2 0 s v
- v
TQuel v v
Flgure lg
Time Support m Exrstmg or Proposed Systems
[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
[Bubenko 19771 Bubenko, J A, Jr The Temporal
hmensron tn Znformatzon Modelrng, in
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
the srgmod ‘84
Conference, June 1984 pp 316-325
[Dadam et al 19841 Dadem, P , V Lum and H-D
Werner Zntegratron
hme Ver82ons tnto
a Relatronal Databacle System In Proceed-
the Conference on Verg Large Data
Baeea, 1984
[Fmdler t Chen 19711 Fmdler, N and D Chen
On the problem8
ttme retrteual, temporal
relattons, causalttg, and coezrstence In
of fhe hternattonal
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
[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.
[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
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
[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
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
... The first dimension of time we investigate is transaction time [34], which records how the state of the database changes over time. The key idea behind transaction time databases is that update operations are non-destructive, so we can always view a database as it stood at a particular point in time. ...
... Finally we mention two immediate next steps. First, we plan to investigate bitemporal databases [34] allow transaction and valid time to be used together, allowing us to write queries such as "when was it recorded that Bob's contract length was extended?"; bitemporal databases are considerably more difficult to formalise and reason about, so we aim to investigate how bitemporal support can be added in a compositional manner. ...
Full-text available
Modern applications often manage time-varying data. Despite decades of research on temporal databases, which culminated in the addition of temporal data operations into the SQL:2011 standard, temporal data query and manipulation operations are unavailable in most mainstream database management systems, leaving developers with the unenviable task of implementing such functionality from scratch. In this paper, we extend \emph{language-integrated query} to support writing temporal queries and updates in a uniform host language, with the language performing the required rewriting to emulate temporal capabilities automatically on any standard relational database. We introduce two core languages, $\lambda_{\mathsf{TLINQ}}$ and $\lambda_{\mathsf{VLINQ}}$, for manipulating transaction time and valid time data respectively, and formalise existing implementation strategies by giving provably correct semantics-preserving translations into a non-temporal core language, $\lambda_{\mathsf{LINQ}}$. We show how existing work on query normalisation supports a surprisingly simple implementation strategy for \emph{sequenced joins}. We implement our approach in the Links programming language, and describe a non-trivial case study based on curating COVID-19 statistics.
... Spatiotemporal data types (Schneider, 2009) are used to represent the temporal evolution of spatial objects over time, for example, as in the case of moving objects. Different temporal types are classified including user-defined time (which has no special semantics, e.g January 1, 1963 when John has his birthday), valid time (which is the time a fact is true in the application domain, e.g. the time 2000-2012 when John is a professor), transaction time (which is the time when a fact is current in the database, e.g. the system time that gives the exact period when the tuple representing that John is a professor from 2000 to 2012 is current in the database), combination of transaction time and valid time (Snodgrass & Ahn 1985;Date et al., 2002). These evolutions can be discrete or continuous. ...
... The values of this datatype are spatial literals that encode geometric objects using the WKT format. Also, stRDF i allows the presence of time in the object part of a triple (this is called user-defined time in the terminology of temporal databases (Snodgrass & Ahn 1985)), where the objects can have the following XML Schema datatypes: xsd:dateTime, xsd:time, xsd:date, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gDay, 28 F . Z H A N G E T A L . ...
Currently, a large amount of spatial and spatiotemporal RDF data has been shared and exchanged on the Internet and various applications. Resource Description Framework (RDF) is widely accepted for representing and processing data in different (including spatiotemporal) application domains. The effective management of spatial and spatiotemporal RDF data are becoming more and more important. A lot of work has been done to study how to represent, query, store, and manage spatial and spatiotemporal RDF data. In order to grasp and learn the main ideas and research results of spatial and spatiotemporal RDF data, in this paper, we provide a comprehensive overview of RDF for spatial and spatiotemporal data management. We summarize spatial and spatiotemporal RDF data management from several essential aspects such as representation, querying, storage, performance assessment, datasets, and management tools. In addition, the direction of future research and some comparisons and analysis are also discussed in depth.
... For example, the evolution of the Recording relation type can not be modelled in this approach. Evolution of other application model elements than from the population, must then be described by using a meta modelling approach ( [SA85]). ...
... In this paper, the difference between recording and event time[SA85], and the ability to correct stored information are not taken into consideration. For more details, see[FOP92a] or[FOP92b]. ...
Full-text available
In this article we focus on evolving information systems. First a delimitation of the concept of evolution is provided, resulting in a first attempt to a general theory for such evolutions. The theory makes a distinction between the underlying information structure at the conceptual level, its evolution on the one hand, and the description and semantics of operations on the information structure and its population on the other hand. Main issues within this theory are object typing, type relatedness and identification of objects. In terms of these concepts, we propose some axioms on the well-formedness of evolution. In this general theory, the underlying data model is a parameter, making the theory applicable for a wide range of modelling techniques, including object-role modelling and object oriented techniques.
... Temporal data management involves all methods and techniques to model, query and store temporal data [32]. There is a vast literature on this topic since the 80's focusing on relational database management systems (RDBMS) [33][34][35][36][37][38]. By contrast, it is not extensively studied in the context of graph management systems. ...
Real-world graphs are often dynamic and evolve over time. To trace the evolving properties of graphs, it is necessary to maintain every change of both vertices and edges in graph databases with the support of temporal features. Existing works either maintain all changes in a single graph or periodically materialize snapshots to maintain the historical states of each vertex and edge and process queries over proper snapshots. The former approach presents poor query performance due to the ever-growing graph size as time goes by, while the latter one suffers from prohibitively high storage overheads due to large redundant copies of graph data across different snapshots. In this paper, we propose a hybrid data storage engine, which is based on the MVCC mechanism, to separately manage current and historical data, which keeps the current graph as small as possible. In our design, changes in each vertex or edge are stored once. To further reduce the storage overhead, we simply store the changes as opposed to storing the complete snapshot. To boost the query performance, we place a few anchors as snapshots to avoid deep historical version traversals. Based on the storage engine, a temporal query engine is proposed to reconstruct subgraphs as needed on the fly. Therefore, our alternative approach can provide fast querying capabilities over subgraphs at a past time point or range with small storage overheads. To provide native support of temporal features, we integrate our approach into Memgraph, and call the extended database system TGDB(Temporal Graph Database). Extensive experiments are conducted on four real and synthetic datasets. The results show TGDB performs better in terms of both storage and performance against state-of-the-art methods and has almost no performance overheads by introducing the temporal features.
... Substantial research has been undertaken in the area of temporal relational databases since the 1980s, producing a significant body of work, so much so that a large portion of the definitive Encyclopedia of Database Systems [41] is dedicated to temporal topics. This work includes representation of time [19,30,51], semantics of temporal models [11], temporal algebras [22], and access methods [48]. Results of some of this work are part of the SQL:2011 standard [35]. ...
Full-text available
In the last decade, substantial progress has been made towards standardizing the syntax of graph query languages, and towards understanding their semantics and complexity of evaluation. In this paper, we consider temporal property graphs (TPGs) and propose temporal regular path queries (TRPQ) that incorporate time into TPGs navigation. Starting with design principles, we propose a natural syntactic extension of the MATCH clause of popular graph query languages. We then formally present the semantics of TRPQs, and study the complexity of their evaluation. We show that TRPQs can be evaluated in polynomial time if TPGs are time-stamped with time points. We also identify fragments of the TRPQ language that admit efficient evaluation over a more succinct interval-annotated representation. Our work on the syntax, and the positive complexity results, pave the way to implementations of TRPQs that are both usable and practical.
... During the same period, the integration of time also became the main research topic, for example, in Hägerstrand's work on Time geography [12]. In the 1980s, IT solutions started to add temporal information into relational databases [13][14][15][16]. These initial proposals to integrate time had a significant impact on the first attempts to model spatio-temporal phenomena in GIS. ...
Full-text available
Over the last decade, innovative computer technologies and the multiplication of geospatial data acquisition solutions have transformed the geographic information systems (GIS) landscape and opened up new opportunities to close the gap between GIS and the dynamics of geographic phenomena. There is a demand to further develop spatio-temporal conceptual models to comprehensively represent the nature of the evolution of geographic objects. The latter involves a set of considerations like those related to managing changes and object identities, modeling possible causal relations, and integrating multiple interpretations. While conventional literature generally presents these concepts separately and rarely approaches them from a holistic perspective, they are in fact interrelated. Therefore, we believe that the semantics of modeling would be improved by considering these concepts jointly. In this work, we propose to represent these interrelationships in the form of a hierarchical pyramidal framework and to further explore this set of concepts. The objective of this framework is to provide a guideline to orient the design of future generations of GIS data models, enabling them to achieve a better representation of available spatio-temporal data. In addition, this framework aims at providing keys for a new interpretation and classification of spatio-temporal conceptual models. This work can be beneficial for researchers, students, and developers interested in advanced spatio-temporal modeling.
... We may obviously have properties of type Date (like, birth-date, election-date, etc.) but also temporal information that may represent temporal contexts, provenance information as well as temporal validity information. Färber et al. [8] adapted the concepts presented by [19] to define the most important types of temporal information that can be stored in KBs. According to [8], there are three types of temporal aspects that can be linked to facts in a KG which are: validity time (when the fact is valid), insertion time (when the fact was inserted into the KG), relevance time (the time that is relevant for an application). ...
Conference Paper
Full-text available
Recently, attention has been focused on temporal databases, representing an enterprise over time. We have developed a new language, TQuel, to query a temporal database. TQuel was designed to be a minimal extension, both syntactically and semantically, of Quel, the query language in the Ingres relational database management system. This paper discusses the language informally, then provides a tuple relational calculus semantics for the TQuel statements that differ from their Quel counterparts, including the modification statements. The three additional temporal constructs defined in TQuel are shown to be direct semantic analogues of Quel's where clause and target list. We also discuss reducibility of the semantics to Quel's semantics when applied to a static database. TQuel is compared with ten other query languages supporting time.
The information in the data base represents a snapshot of it at an unspecified instant of time and the information is deemed to be the 'current' data. While such an approach is satisfactory in many applications, recent studies in new data base applications have revealed that it is not satisfactory in many cases. New functions for new requirements are needed. Among these new requirements is the need to have temporal, or time domain, support. This paper deals specifically with this particular subject. The authors, without distinction, refer to the support of the time domain as temporal support, history data support, or simply time support. They refer to queries with reference to the time domain as time, temporal or history queries. 23 refs.
Conference Paper
Eine wesentliche Rolle im Fertigungsbereich spielt der Begriff der Version. Bedingt durch häufige technische Änderungen sind die Eigenschaften gängiger Objekte wie z.B. “Teil” oder “Arbeitsplan” zeitabhängig. In einer CAM-Datenbank ist deshalb die Bereitstellung geeigneter Datenstrukturen und adäquater Operationen erforderlich. Das im folgenden vorgestellte System zur Handhabung versionsbehafteter Objekte wurde für den Prototyp einer CAM-Datenbank entwickelt.
Conference Paper
The repository described in this paper is a component of a distributed data storage system for a network of many autonomous machines that might run diverse applications. The repository is a server machine that provides very large, very reliable long-term storage for both private and shared data objects. The repository can handle both very small and very large data objects, and it supports atomic update of groups of objects that might be distributed over several repositories. Each object is represented as a history of its states; in the actual implementation, an object is a list of immutable versions. The core of the repository is stable append-only storage called Version Storage (VS). VS contains the histories of all data objects in the repository as well as all information needed for crash recovery. To maintain the current versions of objects online, a copying scheme was adopted that resembles techniques of real-time garbage collection. VS can be implemented with optical disks.
This paper reports on the design and implementation of a time expert for a relational data base system. It demonstrates that a sophisticated expert can be written easily and cause minimal performance degradation. As a result, extending a data base system to support user defined data types is an easy operation.
The concept of an historical database is introduced as a tool formodelling the dynamic nature of some part of the real world. Just as first-orderlogic has been shown to be a useful formalism for expressing andunderstanding the underlying semantics of the relational database model,intensional logic is presented as an analogous formalism for expressing andunderstanding the temporal semantics involved in an historical database.The various components of the relational model, as extended to includehistorical relations, are discussed in terms of the model theory for the logicILs, a variation of the logic IL formulated by Richard Montague. Themodal concepts of intensional and extensional data constraints andqueries are introduced and contrasted. Finally, the potential application ofthese ideas to the problem of Natural Language Database Querying is discussed.
SDM is a high-level semantics-based database description and structuring formalism (database model) for databases. This database model is designed to capture more of the meaning of an application environment than is possible with contemporary database models. An SDM specification describes a database in terms of the kinds of entities that exist in the application environment, the classifications and groupings of those entities, and the structural interconnections among them. SDM provides a collection of high-level modeling primitives to capture the semantics of an application environment. By accommodating derived information in a database structural specification, SDM allows the same information to be viewed in several ways; this makes it possible to directly accommodate the variety of needs and processing requirements typically present in database applications. The design of the present SDM is based on our experience in using a preliminary version of it. SDM is designed to enhance the effectiveness and usability of database systems. An SDM database description can serve as a formal specification and documentation tool for a database; it can provide a basis for supporting a variety of powerful user interface facilities, it can serve as a conceptual database model in the database design process; and, it can be used as the database model for a new kind of database management system.
During the last three or four years several investigators have been exploring “semantic models” for formatted databases. The intent is to capture (in a more or less formal way) more of the meaning of the data so that database design can become more systematic and the database system itself can behave more intelligently. Two major thrusts are clear. In this paper we propose extensions to the relational model to support certain atomic and molecular semantics. These extensions represent a synthesis of many ideas from the published work in semantic modeling plus the introduction of new rules for insertion, update, and deletion, as well as new algebraic operators.
Ttme Relatronal Model PhD Diss UCLA
  • J Ben-Zvl
  • The
  • Ben-Zvl
A language of defintng conceptual schemarr, m Data Base Architecture Amsterdam North Holland , Inc , 1979 Breutmann, B , E F Falkenberg and R Mauer CSL A language of defintng conceptual schemarr, m Data Base Architecture
  • B Breutmann
  • E F Falkenberg
  • R Mauer
  • Breutmann B