• TABLE OF CONTENTS
HIDE
 Title Page
 Table of Contents
 Main






Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: An Interpretation and implementation of temporal databases with two-dimensional time
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095197/00001
 Material Information
Title: An Interpretation and implementation of temporal databases with two-dimensional time
Series Title: Department of Computer and Information Science and Engineering Technical Report ; 93-030
Physical Description: Book
Language: English
Creator: Kim, Seung-Kyum
Chakravarthy, Sharma
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: September, 1993
Copyright Date: 1993
 Record Information
Bibliographic ID: UF00095197
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.

Downloads

This item has the following downloads:

1993112 ( PDF )


Table of Contents
    Title Page
        Page i
    Table of Contents
        Page ii
        Page iii
    Main
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
        Page 12
        Page 13
        Page 14
        Page 15
        Page 16
        Page 17
        Page 18
        Page 19
        Page 20
        Page 21
        Page 22
        Page 23
        Page 24
        Page 25
        Page 26
        Page 27
        Page 28
        Page 29
        Page 30
        Page 31
        Page 32
        Page 33
        Page 34
        Page 35
        Page 36
        Page 37
        Page 38
        Page 39
        Page 40
        Page 41
        Page 42
        Page 43
Full Text















University of Florida
Computer and Information Sciences


... Department of Computer and Information Sciences
t_ Computer Science Engineering Building
SUniversity of Florida
Gainesville, Florida 32611


. V ..


An Interpretation and Implementation
of Temporal Databases with
Two-Dimensional Time

Seung-Kyum Kim
Sharma Chakravarthy
email: sharma@snapper.cis.ufl.edu

Tech. Report UF-CIS-TR-93-030
September 1993
(Submitted for publication)










Contents


1 Introduction


2 One-dimensional temporal validity

2.1 Tem poral validity . . . . . . . . . . . . . . . . . . .
2.2 Interpretation-based validity .. . . . ........................


3 Preservation of multiple past states

3.1 E vent tim e . . . . . . . . . . . . . . . . . . . . .
3.1.1 Classification of events . . . . . . . . . . . . . . . .

3.1.2 Multiple pasts generated by the time difference .. . .............
3.2 Transaction tim e . . . . . . . . . . . . . . . . . . .

3.2.1 Error corrections and delayed updates .. . . ................

3.2.2 Orthogonality of event time and transaction time .. . ............

3.3 M axim al set of time concepts .. . . . .......................


4 Temporal databases with two-dimensional time
4.1 Relations with two-dimensional time . . . . . . .....

4.2 Viewpoint time ............. . . . . . . . ......

4.2.1 Multiple viewers ........ . . . . . . .....

4.2.2 Two-dimensional snapshot.. . . . . . . .....
4.2.3 Fixed-viewpoint history .... . . . . . . .....

4.3 Temporal data manipulation operations . . . . . . .....

4.3.1 Step-wise evolution....... . . . . . . .....
4.3.2 Isochronal history update .. . . . . . . .....

4.3.3 Special time points....... . . . . . . .....

4.3.4 Indefinite future ........ . . . . . . .....


4.3.5 Information carried by temporal data manipulation operations
4.4 Two-dimensional (2-D) temporal validity . . . ..........

4.5 Derivation of valid patterns . . . .................

4.5.1 Derivation of typical valid patterns . . . .........
4.5.2 Derivation from acquisition and release points with non-current

4.6 M ultihistory . . . . . . . . . . . . . . . . .

4.7 Implementation of data manipulation operations . . . .....

4.7.1 Rectangular representation of valid patterns . . . ....
4.7.2 Implementation of insert, update, and delete operation . . .


. . . . 22
. . . . 24

. . . . 25
. . . . 25

snapshots . 28
. . . . 29

. . . . 31
. . . . 31
. . . . 32


10
10
15

16

16
17
18
19
19

20

20










4.8 Error corrections ................... . . . . . ..... 35
4.8.1 Error corrections in valid time and transaction time combination ...... . 35
4.8.2 Error corrections in valid time and event time combination . . . ... 38
4.9 Set operations on multihistory .............. . . . . . 38

5 Conclusions 40













An Interpretation and Implementation of Temporal Databases with

Two-Dimensional Time*


Seung-Kyum Kim


Sharma Chakravarthy


Database Systems Research and Development Center
Department of Computer and Information Sciences
University of Florida, Gainesville, FL 32611
e-mail: {skk, sharma}@cis.ufl.edu

September 28, 1993



Abstract
In this paper, we present an interpretation of the temporal database with two-dimensional
time and propose an implementation. We define the notions of two-dimensional temporal valid-
ity and valid pattern. Using valid patterns, the notion of multihistory, which is a collection of a
data object's history at every viewpoint, is developed. We define temporal data manipulation
operations. It is shown how a multihistory is algorithmically implemented on the relational data
model from the temporal data manipulation operations. Lastly, set operations over multihistory
are demonstrated.


Index Terms: Temporal databases, valid, event, and transaction times, multiple past states,
valid pattern, history of an object, multihistory, set operations.




















*This work was supported in part by the NSF Research Initiation Grant (IRI-9011216) and by a Grant from the
Florida High Technology and Industrial Council (UPN# 900911013).










1 Introduction


Over the past decade extensive research has been done on the temporal database that incorporates
time concepts into the conventional database [23]. The most predominant direction of the research
has been the extension of the relational data model to a temporal one and/or the extension of
the relational query languages SQL and Quel to temporal versions. Work on this area includes
[5, 2, 21, 12, 16, 17, 18]. Besides the emphasis on the relational model, there have been several
extensions of ER or semantic data models to temporal counterparts [14, 9, 18, 25]. The formalization
of temporal data model [19, 6, 26, 11] and the physical data organization for temporal databases
[15, 20, 1, 10, 8] have also been investigated.
Although it has long been recognized that more than one time notion is necessary for a temporal
database to precisely capture the time-varying real world [7, 22, 4, 3], most of the previous work
on temporal databases has dealt with only one time notion, usually called valid time. Only a
few researchers seriously pursued the issues of multiple time notions (or multidimensional time)
[21, 12, 24, 18].
The work by Snodgrass [21] is considered a pioneer on multiple time notions, in which the valid
time and transaction time were employed in order to keep the database states before and after
error corrections and to model retroactive and proactive updates. The work also described the
effect (or semantics) of data manipulation operations, as well as queries, on temporal databases
with the two time notions. However, as we have already addressed in [13, 4], with the valid time
and transaction time, retroactive and proactive updates cannot be properly modeled, while error
corrections are modeled with them. Further, even though the effect of data manipulation operations
(insert, delete, and update) were described, it is hard to know by what procedures a real temporal
relation is changed to reflect the effect of the operations. It is also not clear how to make an
error correction. As a result, these problems seem to have been causes for the incomplete example
relations in [21]. Other work on the two time notions suffers similar problems.
In this paper, we try to resolve the above problems in a more perspective view. In [4] we
have proposed the event time to capture retroactive and proactive updates. The transaction time
and the event time are regarded as kinds of viewpoint time, from which evolution of a data object
is observed. Combining the valid time and the viewpoint time, we obtain two-dimensional time
on which the rest of the work is described. We define temporal data manipulation operations
including error correction operation. The temporal validity of a data value introduced in [13, 4]
is extended into two-dimensional one, which further yields the notion of valid pattern. Based on
valid patterns, the notion of multihistory is defined, which is a congregation of an object's history
observed at every viewpoint. And importantly, an implementation of data manipulation operations
is presented, thereby the construction of a multihistory is clearly understood. It is also shown that










set operations over multihistory are feasible and meaningful.


The rest of this paper is organized as follows. In section 2 and 3, we give a brief review of
one-dimensional temporal validity and the issues of preservation of multiple past states to make
this paper self-contained. Indepth discussion on these issues is found in either [4] or [3]. Section 4
is the core of this paper that includes all issues mentioned in the previous paragraph. Finally, in
section 5, we make concluding remarks about our work.


2 One-dimensional temporal validity

In this section we present in brief the notion of one-dimensional temporal validity. Throughout this
paper we assume an equi-distant discrete time domain T, termed integer time domain and having
0 (zero) as the origin of time. The integer time domain T is isomorphic to the Gregorian calendar
time domain. Therefore, without loss of generality, we use the integer time and the calendar time
interchangeably in this paper. Until other time notions are introduced in 3, the time domain
being discussed in this section is assumed to be of valid time in that it deals only with validity of
data values.
In our discussion on temporal validity, we use some terms that, in spite of their salient traits,
can be mapped without much discrepancy to the traditional ones as below.


Object An object is an entity, a relationship, or an attribute. All objects are considered to be
able to change with time.


Object set An object set is similar to an entity class. Using the set notation, that an object e
is in an object set A is denoted by e E A.


Property A property, denoted P, matches with a data value of an object.1 When an object e
has a property P, that is denoted by e E P.


Property set A property set roughly corresponds to either a domain of attribute value or a
domain of entity (relationship) name, depending on object set. When a property P is included in
a property set P of an object set, that is denoted by P E P. A property set is said to be '- .1" ',
when it is guaranteed that no object has more than one property simultaneously; otherwise the
property set is said to be ,,.' ,,/,/',j' .;,

1In fact, a property may be either a value or a name depending on object. However, such a meticulous distinction
is not very critical for our discussion. In this paper, we tend to use property in formal situations and data value for
informal descriptions.









2.1 Temporal validity


Informally, the temporal validity of a data value for a given object is the object's possession of
the value along the time dimension. For example, the validity of associate professor property for
Smith's rank is a state of whether or not Smith possesses the associate professor property with
time.


Temporal validity The temporal validity of property P of an object set A is a characteristic
function of P,

VP: (Ax T) {0,1}

given by


VP(e, t) 0 ifecP att

where e is an object in A, t is a time point in the time domain T, P is in P, and P is a property
set of A.
If (e, t) is mapped onto 1 by a characteristic function VP, then property P is said to be valid
for object e at time t by VP. It is assumed that for each property in a property set there exists at
least one characteristic function.


Valid period A valid period, T of property P for object e, characterized by a characteristic
function VP, is defined to be a set of time points t, t E T, such that

{t I VP(e,t)= 1}.

In other words, a valid period is a time interval or a set of disjoint time intervals over which a
given property is valid. Figure l(a) shows a valid period of a property, associate professor for an
object, Smith, while Figure l(b) shows a recurring valid period of a property, $100 (which is in a
property set, Stock-price) for an object, say IBM stock.

2.2 Interpretation-based validity

An interpretation-based validity defines a legitimate validity for an object set by restricting relevant
characteristic functions so as to always yield non-overlapping valid periods.


Definition: Given a disjoint property set, P = {P1,P2,. ,P,} and an object set A, an inter-
pretation-based validity, 1p for P is defined to be a set of characteristic functions,

Ip = {ViPi, VjP2, -, VkPn}









1/4/86 6/5/89

Associate
(a)


5/3 5/6 5/9 5/13 5/15
I--I IH-I I-
$100.00 $100.00 $100.00

(b)

Figure 1: Valid periods

such that if VIPm(, t) = 1, VIPm E Ip, then for all VP, E -p, VuPw # V1Pm, VPw(e, t) = 0.
According to the above definition, for a set of characteristic functions to be a legitimate
interpretation-based validity, the following conditions need to be satisfied.

1. At most one characteristic function maps (e, t) onto 1.

2. The property set P is disjoint.

The first condition is necessary to prevent an object from having more than one property
simultaneously, which belong to a property set. For example, in general it does not make sense for
a faculty member to have two different ranks, say, associate and full, at the same time. In fact, this
condition is the minimum requirement that the characteristic functions defined should satisfy. The
second condition is imposed because if the property set itself is overlapping one, the first condition
cannot be satisfied semantically.
As an example, suppose an object set Faculty and a property set {Instructor, Assistant, As-
sociate, Full} are given. Then, an interpretation-based validity is a set of characteristic functions
for each property that determine when and how a faculty member acquires and releases a rank
(property).
In addition, if more than one characteristic function can be defined for a property, an object set
may have multiple interpretation-based validities. For instance, depending on policies (i.e., char-
acteristic functions) a bank adopts, there may be several legitimate interpretation-based validities
for a wire-deposit, such as transaction-time validity and working-hour validity.


3 Preservation of multiple past states

As the temporal database is intended to capture all past database states including the current
one, preserving past states is an essential premise. The preservation of past states, however, is not
guaranteed by just not deleting previously entered data. There are two different causes that have










a bearing on the preservation. One is the retroactive update, and the other is the error correction
operation and the delayed update. The primary reason why the preservation can be incomplete is
that these operations generate multiple past states as performed. If a temporal database system
is not capable of recording and retrieving all the past states, naturally some of the past states will
get lost.
In this section, we redefine the event time in order to precisely model retroactive and proactive
updates, and show why the transaction time cannot capture their precise meanings while still
appropriate for modeling of error corrections and delayed updates. Also, more importantly, we
show what combinations of time concepts are necessary for preservation of different multiple past
states.

3.1 Event time

An event can be viewed as an abrupt change of database statess. In our work the event has a
slightly tailored meaning that it generates certain new properties relevant to a database object.
For example, a promotion event for a faculty member's rank generates a new property, i.e., a new
rank, and a relocation event generates a new address. We call the time an event happens event
time.


3.1.1 Classification of events

Although it is preferred that a property generated by an event become valid as soon as the event
happens, there may be situations in which the time a property becomes valid differs from the time
the event happens (i.e., event time). Based on this time difference, we can classify events into three
categories, on-time events, retroactive events, and proactive events. When a database is updated
with a property generated by a retroactive event, we call the update a retroactive update. Similarly,
if a property is generated by a proactive event, we call the update a proactive update.


On-time events This is the most general case. For an event classified into this category, the
property generated by the event becomes valid simultaneously with the event (or immediately after
the event happens). For example, if a promotion event which promotes a faculty member Smith to
an associate professor happened on 11/89, unless otherwise stated, his rank of associate professor
would become valid on 11/89.


Retroactive events For some events, the time a property becomes valid may be prior to the
time at which the property is generated, i.e., the time an event generating the property occurs. We
call such events retroactive events. For example, Smith's promotion might be a retroactive one so










8/89
/ i. Valid Time
(a) Associate ',. Full
(a)
1.1/89
A Event Time
Promotion Event

8/89
(b) I
Associate Full

11/89
------> ( 10/89)
Associate
(c)
8/89
I am (11/89 co)
Associate Full
Event Time

Figure 2: Retroactive event


that the promotion became valid from 8/89 while the promotion itself was proclaimed in 11/89.
The time difference is depicted in Figure 2(a).


Proactive events In contrast to retroactive events, a property may become valid at a later time
than the time at which the event generating the property occurs. We call such events proactive
events. Examples for the proactive event may be drawn from a temporal database for weather
forecasting. Whenever a forecasting is made, the forecast will not be valid until some time later.


3.1.2 Multiple pasts generated by the time difference

The time difference inherent to a retroactive event is one reason for the generation of multiple
pasts. Figure 2(a) depicts a retroactive promotion of Smith. Until 7/89, Smith's rank is no doubt
Associate. After the promotion on 11/89, his rank is Full. But, what about from 8/89 to 10/89?
Before the promotion, the rank during that period was Associate, whereas after the promotion, the
rank was revised to Full. As a result, we have two different pasts during that time period.
Figures 2(b) and (c) show possible representations of the retroactive update. Figure 2(b) repre-
sents the resultant database state after the update, and is in fact the most reasonable representation
for temporal databases with one-dimensional time. A shortcoming of this representation is that
the intermediate database state, Associate, during 8/89 through 10/89 disappears and cannot be
retrieved. Moreover, the fact that the promotion was retroactive cannot be recalled.
Figure 2(c) shows an alternative in which two histories are kept, one each for the updated
and the previous state. In this approach, the updated state can be retrieved as usual, and the
previous state also can be retrieved if necessary. In addition, the fact that the recorded event was










a retroactive one can be represented in some way and identified later.
A problem with the second approach shown in Figure 2(c) is that one time (or one-dimensional
time) is not sufficient to uniquely qualify a data value at a given time point. For example, at 10/89
Smith's rank may be interpreted as either Associate or Full. However, taking a closer look at the
multiple histories, we can see each history has its own 1.'-;,',/I effective period in terms of event
time. For instance, until 10/89 in event time, only the history of the upper figure in Figure 2(c)
will be effective. Such an event time period is shown on the right side of each history. As such, the
event time is now able to be a qualifier to single a history out of multiple histories. Once a history
is selected, then we can examine it to get a data value at a specific time point. Consequently, if
two time values, one each in the valid time and the event time, are given, we are able to retrieve
a unique data value from a temporal database without losing past states generated by the time
difference of retroactive events.

3.2 Transaction time

Although the transaction time is defined in the literature simply to be the time at which data
values are recorded in a database, our definition of transaction time is more restrictive in that it is
used, in conjunction with the valid time, only for the preservation of multiple pasts generated by
error corrections and delayed updates.


3.2.1 Error corrections and delayed updates

The error correction operation may be the most conspicuous one among those operations generating
multiple pasts. Assume that Smith was promoted to associate professor on 1/', but the rank was
wrongly recorded as full professor. The error was found later and corrected on 9/' ". Figure 3(a)
illustrates that situation. The error correction induces two different pasts. During 1/t' through
8/- ". we have an incorrect past in which Smith's rank is viewed as full professor, whereas from 1/t -.
up to 10/89 we have a correct past where the rank is viewed as associate professor. Figures 3(b)
and (c) show two different histories caused by the error correction.
The delayed update, on the other hand, happens as a data value (property) is not recorded
immediately after its generation. As a matter of fact, every update operation has an inevitable
delay varying from a few milliseconds to several months or more. The delayed update also generates
multiple pasts in a similar way to the error correction. In Figure 3(a), Smith's promotion to full
professor on 8/89 was not recorded until 11/89. As a result, during 8/89 to 10/89, his rank
may be thought of as either associate or full professor. Figures 3(c) and (d) show the duality in
interpretation.
As in the case of retroactive updates, we can see in Figure 3 that using only valid time does not
give a unique data value at a time point. By adding the transaction time, we can obtain a unique















(a)


1/85 8/89

Assistant Full Full
SAssociate


92/85 1
i ..


I I


Valid Time




Transaction
m-; ^


1/89


i it II IL=LLe
Updated Corrected Updated (Delayed)



1/85 9/85
(b) -- --- ------------- ( 8/85)
Assistant Full

1/85 11/89
(c) I I --- (9/85 ~ 10/89)
Assistant Associate

1/85 8/89
(d) I I (11/89 co)
Assistant Associate Full
Transaction
Time

Figure 3: Consolidation of error correction and delayed update


data value at two time points, one in the valid time and the other in the transaction time, without

losing past database states generated by error corrections and delayed updates.


3.2.2 Orthogonality of event time and transaction time

It is interesting to see that in previous work [22, 21] the retroactive update and the delayed update

have been treated in the same way; in other words, the two were not differentiated at all. In

their work, the time a property is generated and the time it is recorded are indistinguishable and

represented by the transaction time. However, the two operations should be different.

To comprehend the inadequacy of transaction time for modeling of retroactive/proactive update,

let's see Figure 4 which shows a proactive event, Grant-Award and its three different transaction

times. Depending on transaction time, the proactive event can be wrongly interpreted as other

proactive event, on-time event, or even retroactive event.


3.3 Maximal set of time concepts

As we have seen thus far, the valid time alone is not enough for the preservation of multiple pasts.

In order to achieve the preservation of multiple pasts, we need at least two- or three-dimensional

time made up by:


1. Combination of valid and transaction times.










7/92
------------
Not Effective ..-':. Effective

10/99-

Grant-Award Evenl

1,


Valid Time


Event Time


Trana cti on Time


12/91 7/92 10/92

Figure 4: Misinterpretation of a proactive event




2. Combination of valid and event times.

3. Combination of valid, event, and transaction times.

Using (1), we can preserve multiple pasts generated by error corrections and delayed updates.
But we lose incomplete pasts generated by retroactive updates. Of course, the database does not
keep any information concerning when events happened, much less the types of events.
Using (2), we can preserve multiple pasts generated by retroactive updates. But erroneous pasts
generated by error corrections and delayed updates cannot be preserved.
Lastly, using all the three times (case (3)), all multiple pasts generated by those operations can
be preserved. This approach will give us the most general interpretation of temporal databases.
However, the generality needs to be weighed against the increased complexity in interpretation from
users' viewpoint. While the implementation of three-dimensional time is still possible, we do not
believe that four- (or higher) dimensional time is manageable and that benefits from its generality
would offset the far increasing intricacy of interpretation. From this practical standpoint, we claim
that the valid, event, and transaction times are a maximal set of times, which are needed and can
be implemented in temporal databases.


4 Temporal databases with two-dimensional time

Based on the discussion so far, we present a two-dimensional time interpretation of temporal
databases that preserve multiple past states generated either by error corrections and delayed
updates or by retroactive updates.


4.1 Relations with two-dimensional time

Before presenting full facets of two-dimensional (2-D) time interpretation of temporal databases,
we first give glimpse how 2-D time temporal relations (in short, 2-D relations) look like and how
to query against such relations. In the following, two 2-D relations are taken as examples. One










3/1 3/2 3/3 3/4 3/5 3/6 3/7
I I I I I I I Valid time
3/1 60 65 70 65

3/2 60 62 70 70 75

3/3 60 62 65 65 70 75

3/4 60 62 65 63 65 70 70


Event time

Figure 5: Temperature I


is TEMPERATURE that keeps records of high temperature measured and forecast 3 days ahead.
The other is TEACHERS that keeps track of changes of each faculty member's rank.
The relation TEMPERATURE employs a 2-D time composed of the valid and event times,
thereby it naturally captures the meaning of proactive events in weather forecasting. Figure 5 gives
values of temperature which were measured and forecast between Mar. 1 and Mar. 4. On 3/1,
the measured temperature is 600F, and forecast ones on 3/2, 3/3, and 3/4 are 650, 700, and 65,
respectively. Note that the measured value, 60, corresponds to a property generated by an on-time
event in that the value (property) becomes valid as soon as the measurement is carried out (i.e.,
occurring a measurement event). The forecast values, on the other hand, correspond to properties
generated by proactive events, because although the values are generated (forecast) on 3/1 they
are valid on 3/2, 3/3, and 3/4, respectively. The four values appear in the first row of the figure.
Similarly, new values are obtained on 3/2; that is, a measured value, 620, and forecast values,
700, 700, and 75. The previous measured value, 600, is also maintained. The five values appear in
the second row. The rest of values in the figure are obtained in similar manner. It should be noted
that given any point in event time, one can see the entire history values (including future ones) of
temperature by following the valid time axis of Figure 5. In other words, Figure 5 keeps all histories
of a data object, temperature, each conceived everyday. Figure 6 is a more readable equivalent of
Figure 5, using rectangular patterns in place of explicit discrete values. In the remainder of this
paper, we will use this pattern-based representation.
The multiple histories represented by Figure 6 are also equivalently expressed by a relational
table, yielding a 2-D relation shown in Figure 7. In the relation, a couple of time-stamp attributes
are associated with every non-time-stamp attribute. One of the time-stamp attributes is the one
named Valid time and it represents a valid period of the associated attribute value. The other
time-stamp attribute, named Event time, represents the effective period of a pair of an attribute
value and the value's valid period. For example, according to the current extension of the relation,
data value 600 in the first row is valid only on 3/1 and such a fact is effective forever from 3/1.










3/1 3/2 3/3 3/4 3/5 3/6 3/7
I I I I I I I Valid time
3/1

3/2

3/3 -- 60 -

3/4 -


Event time

Figure 6: Temperature II


650 in the second row is valid on 3/2, but such a fact is effective only on 3/1. In the relation
TEMPERATURE, no key is defined.
Unlike TEMPERATURE, the 2-D relation TEACHERS shown in Figure 8 employs a 2-D time
composed of the valid and transaction times. As already discussed, this combination of 2-D time
enables us to preserve multiple pasts generated by error corrections and delayed updates. The
relation TEACHERS, having "Name" as a key, shows evolution of faculty members' rank. In the
relation, two time-stamp attributes, each named Valid time and Transaction time, are associated
with each non-time-stamp attribute. Valid time represents a valid period of the associated attribute
value as before. Transaction time denotes the effective period of a pair of an attribute value
and its valid period; however, interpretation of this pair should be differentiated from that of
TEMPERATURE.
Figure 9 depicts multiple histories of Smith's rank excerpted from Figure 8. A notable difference
between Figure 6 and Figure 9 is that in Figure 9 error corrections always leave traces, which enable
such operations to be tracked later. In Figure 9, for instance, the value Full* that was entered in
8/>". is a typo. The error was corrected to be Associate in 4/86. Note that a pattern for the
erroneous value still remains in the figure. This is not the case for multiple histories, such as
Figure 6, employing the valid time and event times. Suppose that, in Figure 6, 650 on 3/2 that
was forecast on 3/1 is a typo and it is actually 630. And that the error is corrected later, say on
3/3. In this case, however, the incorrect value would not remain in Figure 6, because although it
is corrected on 3/3 the event time of the value (i.e., 3/1) must be recorded with the valid time;
that is, the old pattern is entirely replaced by the new one. This is why the detection of correction
operations is not possible in Figure 6.
Given 2-D relations TEMPERATURE and TEACHERS, we can make various queries against
them. The simplest query is to retrieve values of attributes that are valid at a certain time point
and known at another time point. For instance, the following TQuel [21] query retrieves Smith's















TEMPERATURE


Temp. Valid time Event time
60 (3/1 ~ 3/1) (3/1 o)
65 (3/2 3/2) (3/1 ~ 3/1)
70 (3/3 3/3) (3/1 3/1)
65 (3/4 3/4) (3/1 3/1)
62 (3/2 3/2) (3/2 oo)
70 (3/3 3/3) (3/2 3/2)
70 (3/4 3/4) (3/2 3/2)
75 (3/5 3/5) (3/2 3/2)
65 (3/3 3/3) (3/3 oo)
65 (3/4 3/4) (3/3 3/3)
70 (3/5 3/5) (3/3 3/3)
75 (3/6 3/6) (3/3 3/3)
63 (3/4 3/4) (3/4 oo)
65 (3/5 3/5) (3/4 oo)
70 (3/6 3/6) (3/4 oo)
70 (3/7 3/7) (3/4 oo)


Figure 7: 2-D relation: TEMPERATURE


TEACHERS


Name Valid time Transaction time Rank Valid time Transaction time
John (8/88 oo) (8/88 oo) Instructor (8/88 oo) (8/88 12/90)
(8/88 12/90) (1/91 oo)
Assistant (1/91 o) (1/91 0)
Smith (1/81 oo) (1/81 oo) Assistant (1/81 oo) (1/81 7/85)
(1/81 12/84) (8/85 oo)
Full* (1/85 oo) (8/85 3/86)
Associate (1/85 oo) (4/86 5/89)
(1/85 7/89) (6/85 oo)
Full (8/89 oo) (6/89 oo)
Jane (8/85 oo) (8/85 1/89) Assistant (8/85 oo) (8/85 1/89)
(8/85 4/89) (2/89 oo) (8/85 4/89) (2/89 oo)
Jane (8/91 oo) (8/91 oo) Associate (8/91 oo) (8/91 oo)


Figure 8: 2-D relation: TEACHERS










1/81 1/85 8/89
I-I I Valid time
1/81
Assistant
8/85
Full*
4/86
Associate
6/89
Full


Transaction time

Figure 9: Evolution of rank


rank which is valid and known in 1/86.


range of F is TEACHERS
retrieve F.Rank
where F.Name = "Smith"
when F.Rank overlap 1/86
as of 1/86


In the query, the when clause specifies that only attributes whose valid periods, denoted by Valid
time, contain the valid time point 1/86 be selected. The as-of clause imposes a similar restriction
on the selection process; but this time, the restriction is applied to the time period denoted by
Transaction time. It is easy to see that only Full* of Smith's ranks satisfies the two clauses at
the same time. Therefore, the answer should be "Full*". Note that although the wrong value was
corrected on 4/86, the correction didn't happen (i.e., not recorded) yet as of 1/86, accordingly, not
known at that time. However, if we change the time point of as-of clause to 6/86, the answer will
be different, i.e., "Associate".
Similar queries can be issued for TEMPERATURE. The difference is that the restriction of
as-of clause is now applied to Event time. The following query retrieves the temperature of 3/4
which was forecast on 3/2. According to the relation, the answer is 70.


range of F is TEMPERATURE
retrieve F.Temp
when F.Temp overlap 3/4
as of 3/2










Object: Associate Full
Smith's rank
S I/ ) 4-- valid time
6/89.8/89 11/89 ,2/90

SViewer --- Viewpoint time
11/89

Figure 10: Viewpoint


4.2 Viewpoint time

In 3, we have discussed two kinds of multiple histories generated along the event time and the
transaction time. We have pointed out that such multiple histories are begotten by a common
cause, the time difference that may exist between the time a property becomes valid and the time
an event (or transaction) relevant to the property happens. In this section, we introduce the concept
of viewpoint in order to handle this problem from a more general perspective.
Whenever we behold a real world object as of a certain time point, another important time
point must be involved in the observation. That is a time point at which the viewer is. We call
such a time point viewpoint, and the time from which viewpoints are taken viewpoint time.
Figure 10 illustrates a situation where a viewer is beholding an object, Smith's rank. In the
figure, the viewer's viewpoint is currently 11/89, and he beholds the object as of three time points,
6/89, 11/89, and 2/90. The viewer will see Smith's rank as Associate, Full, and another Full at
each of the three time points. In other words, given a time point the viewer has the knowledge
about values of the object through its entire lifespan, regardless of completeness (or fidelity) of the
knowledge. If the viewpoint changes, the viewer may see different history of the object as the value
of object changes by updates or error corrections. We observed the same thing in Figure 6. By
moving our viewpoint from 3/1 through 3/4 along the event time axis, we, as viewers, could see
different histories of temperature.


Non-futuristic viewpoint. One important restriction naturally imposed on a viewer's view-
point is that the viewpoint be less than or equal to the current time; i.e., no future viewpoint.
This restriction, however, does not forbid predictions or prospects. As discussed in 4.1, we can
make a weather forecast today, or might have done it yesterday; that is, as of current or past
viewpoint. What the non-futuristic viewpoint disallows is to say as of today "A forecast has been
made tomorrow". A ramification of imposing the non-futuristic viewpoint is to forbid storing and
retrieving information as of a future viewpoint.










4.2.1 Multiple viewers


Although in Figure 10 we assumed only one viewer, in a temporal database there may be several
viewers2 participating in building and interpreting the database. In our work, we identify two
viewers, decision-maker and recorder. The decision-maker is one who beholds real world objects
and/or makes decisions concerning when events happen. The recorder is one who records facts
generated from events (and events themselves) into the database.


Event time as decision-maker's viewpoint time. As a viewer, the decision-maker has his
own viewpoint from which real world objects are directly beheld.3 This implies that the event time
coincides with the decision-maker's viewpoint time, for we assumed that events causing changes
to objects are directly observed or even such events are given rise to by the decision-maker. In
other words, events happen along with the decision-maker's viewpoint time, or the event time is
the decision-maker's viewpoint time.


Transaction time as recorder's viewpoint time. The second viewer, recorder, also has her
own viewpoint from which changes to objects and events causing the changes are beheld on behalf
of her. Note that, however, changes to objects are observed or determined by the decision-maker,
and the changes are just carried over to the recorder with events that caused the changes. Again,
we can see that the recorder's viewpoint time coincides with the transaction time since the recorder
is the very agent who executes transactions. In other words, the transaction time is the recorder's
viewpoint time.


4.2.2 Two-dimensional snapshot

The one-dimensional snapshot was defined to be a function returning a property (data value) for a
given time point in the valid time [3]. We extend the one-dimensional snapshot to two-dimensional
one by adding the viewpoint time. That is, the two-dimensional snapshot (2-D snapshot) is a
function returning a property for given two time points, each in the valid time and the viewpoint
time. A 2-D snapshot is denoted by sn(tv,tp), where tv and tp are a valid time point and a
viewpoint time point, respectively. The 2-D snapshot is used as a metaphor to describe information
with the two time concepts being transferred between real world and database world. A non-loss
2-D temporal database may be defined to be a database that records real world 2-D snapshots
taken by a specific type of viewer at every moment and retrieve them without loss.

They need not be different persons.
3If there are any other intermediate viewers between real world and the decision-maker, the decision-maker's view
toward real world might be indirect one, which is carried over by another viewer being ahead of him. However, we
exclude such a case from our discussion.










p p
1 2 3 4 5 6
I j I j J Valid time
sn(2,3)\ ',\4.sn(2,5) sn(6, 5)
\,s'(3,3) ,sn(.55,
I "' -- Viewpoint time
1 3 5

Figure 11: Two-dimensional snapshots


Figure 11 shows 2-D snapshots at two viewpoints, 3 and 5. In the figure, sn(2, 3), (3, 3), and
(2,5) have value Pi, whereas sn(5,5) and sn(6,5) have value Pj.


Classification of snapshots. Based on the time difference between valid time and viewpoint
time, we are able to classify 2-D snapshots as follows.

Current snapshot : tv = tp.

Retrospective snapshot : tv < tp.

Prospective snapshot : tv > tp.

The current snapshot is the current data value of object as of the time of viewpoint. Similarly,
the retrospective snapshot is a past data value, and the prospective snapshot is a future data value,
each as of the time of viewpoint. For example, in Figure 11, sn(3, 3) is a current snapshot, sn(2, 5)
is a retrospective snapshot, and sn(6, 5) is a prospective snapshot.
As such, all retrospective snapshots and the current snapshot of the real world are assumed to
be known for sure to the viewer at each viewpoint. Some prospective snapshots may be known by
prediction or assertion. The rest of prospective snapshots are usually unknown but assumed to have
a certain value. The unknown prospective snapshots are called indefinite prospective snapshots.
Other known snapshots are called definite snapshots.


4.2.3 Fixed-viewpoint history

As illustrated in Figures 10 and 11, given any viewpoint we can observe evolution of a data object
through its lifespan. The evolution, then, can be represented by a set of 2-D snapshots with the
same viewpoint. We call such a set a fized-viewpoint history of the data object.
As a data object and the viewpoint change, the object has different fixed-viewpoint histories.
For example, from Figure 11, we can extract two fixed-viewpoint histories shown in Figure 12. The
two fixed-viewpoint histories have viewpoints, 3 and 5, respectively. It should be noted that other
fixed-viewpoint histories also can be extracted besides the two.












P,
(a)


1 4
I I -


Viewpoint : 3





Viewpoint : 5


P, P
(b)

Figure 12: Fixed-viewpoint histories


Preservation of fixed-viewpoint histories The notion of fixed-viewpoint history is central to
the preservation of multiple pasts. A fixed-viewpoint history is our perception of history of object
at a single moment. Therefore, preserving multiple pasts is nothing but preserving fixed-viewpoint
histories of all viewpoints. Or the latter is more general in that it preserves not only retrospective
and current snapshots but also prospective snapshots.
Also, we have discussed that the event time and the transaction time are equal to viewpoint
times of decision-maker and recorder, respectively. Thus, if we preserve all fixed-viewpoint histories
with decision-maker's viewpoint, multiple pasts generated by retroactive updates will be preserved.
Similarly, if all fixed-viewpoint histories with recorder's viewpoint are preserved, it amounts to
preserving multiple pasts generated by error corrections and delayed updates.

4.3 Temporal data manipulation operations

As an object is created, evolves, and eventually terminates its existence in the real world, we should
be able to replicate this process in the temporal database in order to query about the modeled real
world at later times. Insert, update, and delete operations of the traditional database can be used
for this purpose. As such, insert operation is to create an data object by assigning the first data
values) to the object. Whenever a change is observed in the real world object, the same change
is made to the data object in the database by applying an update operation. As the real world
object ceases its existence, a delete operation is performed to invalidate the data object.
The non-trivial part hidden in the above scenario is two-fold. Firstly, as a replica of the real
world is built in the temporal database, we will inevitably err; such errors may come from the
incorrect observation of the real world or even from inadvertent key strokes. Handling this problem
will be addressed in a subsequent subsection. Secondly, as more fundamental aspects, we should
worry about what temporal information the data manipulation operations need to carry and how to
build a temporal database from the information. In this subsection, we address what information
temporal data manipulation operations need to carry and what assumptions are involved in the
operations.










1 4 6 8
P
I -

P P
I P' I P _

II I~ -

I P I P-


Viewpoint : 3

4

S

6


P, P
I I I 7I

1 4 6 8

Figure 13: Evolving fixed-viewpoint histories


4.3.1 Step-wise evolution

A basic assumption we employ in this paper is that all data objects change their data values

(properties) in the step-wise fashion. Suppose that at time point 5 an object acquired a data value
200. And at time point 10, it acquired a new data value 250 (or released the current value 200).
Then, the step-wise evolution states that the object retains data value 200 up to time point 9, just
before time point 10. As another example, let's see Figure 12(b). In the figure, an object acquires
data value Pi at time point 1 and Pj at time point 4. According to the step-wise evolution, the
object is assumed to have Pi at time points 1, 2, and 3. From time point 4, it retains Pi until
another change happens. Although not all data objects display this behavior of evolution, we
believe most of them can be modeled with this assumption. Other evolution types can be found in
[20].


4.3.2 Isochronal history update

In order to attain the complete preservation of fixed-viewpoint histories, ideally one needs to record
into the database the fixed-viewpoint history at every viewpoint. This approach, however, causes
great redundancy because history usually does not change frequently.
A more practical way is to record the fixed-viewpoint history precisely when (and only when)
a change in the history is observed. We call this approach isochronal history update. With the
isochronal history update, we have a rationale to deduce a fixed-viewpoint history at a viewpoint
at which no information about the history is provided into the database. The fixed-viewpoint
history at that viewpoint is the same with that of the previous viewpoint.
Figure 13(a) shows evolving fixed-viewpoint histories observed at viewpoint 3 through 8. In
the figure, the history has changed only at viewpoints 4, 7, and 8. With the isochronal history
update, only those changed histories and the very first one are required to be recorded, and the










other histories are deduced from the recorded ones.
The isochronal history update largely coincides with the practice of database update in the
traditional database, in which the punctuality of recording is less stringent. Updating database is
to reflect changes in the real world being modeled. If the real world did not change, the database
should maintain its previous (current) state. Conversely, if the database state did not change, it is
assumed that the real world did not change either.


4.3.3 Special time points

As mentioned in the step-wise evolution, it is assumed that a data object acquires a property at
a certain time point and releases it at a later time point. And the acquisition, as well as release,
of a property involves a viewpoint at which such a fact is observed. Hence, we can think that a
property is acquired at a 2-D time point consisting of a valid time point and a viewpoint time
point. Similarly, a data object releases a property at a 2-D time point. Definitions of these 2-D
time points, each called acquisition point and release point, are given below:

acquisition point time point (tv, tpa) at which a new property becomes valid at
tv, and that fact is observed at tp,,

release point time point (tv,, tp,) at which an existing property turns invalid at tv,
and that fact is observed at tp,

where tv, and tv, are time points in valid time and tp, and tp, are time points in viewpoint time.
In Figure 13, we can see (4,4) and (8,8) are acquisition points of properties Pj and Pk, respec-
tively. (4,4) and (6,7) are respectively release points of Pi and Pj. Note that (4,4) is a release point
and an acquisition point of adjoining properties Pi and Pj, respectively.
Among release points, the one which is not an acquisition point of the other property is called
a death point. Similarly, among acquisition points, the very first one in the history or the first one
immediately after a death point is called a birth point. As the names -,i,. -1 a birth point is a
time point at which an object is begotten and a death point is where the object ceases its existence.
An object may have multiple birth and death points, having multiple lifespans. In figure 13, (6,7)
is a death point and (8,8) is a birth point.


4.3.4 Indefinite future

Although one never knows the future in a strict sense, in the database world data value of an object
may become known in advance through prediction or assertion, as in the case of proactive event.
Therefore it is desirable that the temporal database is harnessed to handle such future information
too.










1 4 1 4 6
P ] P P
I I II| Viewpoint : 4 Viewpoint : 4
UC
P P P P
I II s I I I s5
UC
P P P P
II II 6 I 6
UC
PI P
7

(a) (b)

Figure 14: UC future end points in fixed-viewpoint histories


However, a major problem with the future information is the representation of indefiniteness.
Let's compare Figure 6 and Figure 9. In Figure 6, all prospective snapshots are definite ones in
that all forecast values were explicitly given or asserted. The fidelity of the values themselves
is not a concern of database system. In contrast, in Figure 9, most prospective snapshots are
indefinite in that such snapshot values have not been asserted. For instance, a prospective snapshot,
sn(9/81, 1/81) has value, Assistant, according to the figure. However, this value is not an assured
one as of viewpoint 1/81 (in transaction time); all we know as of 1/81 is that the rank may change
someday and until then the current value will be valid. Unless the end point of a valid period is
pre-specified when a data value is updated, we always run into this problem.
Several methods for denoting the future end point of a valid period have been proposed. Among
them are to use Now, UC (Until Changed), or the conventional one, oo (infinity). However, we
view using Now or UC has no benefit compared to oo while making the implementation complex.
In fact, Now has an apparent deficit for representation of a future information and is excluded from
our discussion.
UC may be considered as giving a more precise interpretation of future information than oo,
but that is not true. Figure 14(a) is a part of Figure 13, which uses UCto represent the future end
point in place of oc. At viewpoint 4, in Figure 14(a), a new property Pj becomes valid from (valid)
time point 4, i.e., sn(4,4) = Pj. But it is not sure what values prospective snapshots, such as
sn(5, 4), sn(6, 4), and sn(7, 4), would have, they are just assumed to be Pj until a change is made
in some future time. The same is true at viewpoints 5 and 6. Figure 14(b) depicts fixed-viewpoint
histories after a delete operation performed at viewpoint 7 thereby the valid period of Pj has a
definite end point 6. By the delete operation, UC's in all fixed-viewpoint histories are changed to 6.
Now we have a problem. That is, before the deletion we had no idea what future values exactly
would be (or assumed to be Pj forever), but after the deletion, as we go back to the past we will
find that Pj has a definite end point. This is against a basic assumption for temporal databases,
namely, the preservation of past states.










In our work, we choose the simple v1il',1-[;, ,; method using oo for denotation of end point. If
the end point of valid period is not pre-specified, all indefinite prospective snapshots are considered
to be the same with the newest definite snapshot. For example, in Figure 9, the newest definite
snapshot as of viewpoint 6/89 is sn(8/89, 6/89), which was probably given by a proactive promotion.
Then, indefinite prospective snapshots, such as sn(9/89, 6/89), sn(10/89, 6/89), have value, Full,
instead of null or unknown. Note that sn(7/89, 6/89) is not regarded as indefinite since, as of
viewpoint 6/89, it is known to be Associate. Except in Figure 14, we are already using the valid-
forever method.
The valid-forever method is, in fact, not a compromise, it expresses our perception toward future
more naturally than UC. The stored future information keeps the same uncertainty that one has in
the real world. If prospective snapshots of the real world are definite ones, the stored prospective
snapshots are definite too. Otherwise if the real world prospective snapshots are indefinite, so are
the stored ones. In order to see whether a stored prospective snapshot sn(tv, tp), whose value is
P, is a definite or an indefinite one, we just need to check if there is a release point (tv, tp,) of P
stored, where tv, > tv and tp, < tp. If there is, the snapshot is definite, otherwise it is indefinite.


4.3.5 Information carried by temporal data manipulation operations

While other variations are possible, in this work we define a simple form of temporal data manip-
ulation operations. Basically insert and update operations are assumed to convey a new property
with an acquisition point and with a release point if the release point is known in advance. If the
release point is not available, only a property and an acquisition point are conveyed to the database.
In this case, the missing release point will be provided by a future update or delete operation. An
update operation not only specifies an acquisition point of a new property to be added but also
effectively gives a release point of the previous property because at most one property can be valid
at a given instant.
If a release point is specified in an insert or update operation, the release point is regarded as
a death point of the relevant object under the assumption that a data object with no property
does not exist.4 In addition, the viewpoint times of acquisition and release points are regarded
as being equal. That is, we assume that the acquisition point and release point become known
at the same time if the release point is to be known in advance. Also the two viewpoint times
are assumed not to be greater than the current time, Now, in accordance with the restriction of
non-futuristic viewpoint. If the viewpoint time is the transaction time, then the viewpoint time is
further restricted to be equal to Now by the definition of transaction time.
4This assumption might be an over-simplification in that the existence of an object does not depend on the fact
that whether the object has a certain property. This simplification, however, keeps the discussion manageable at the
expense of modeling accuracy.










The delete operation, on the other hand, conveys a release point without a new property to be
added. The release point is that of the current property -or equivalently, it is to add an empty
property (c) with the specified release point as acquisition point.
Furthermore, the acquisition point of update and the release point of delete operations are
required to be greater than the acquisition point of the lastly recorded property in both valid time
and viewpoint time. Likewise, the acquisition point of insert operation is required to be greater than
the death point of the lastly invalidated property by a delete operation, if any. These requirements
are necessary for evolution of data objects to proceed forward. In Figure 13, the evolution of history
satisfies these requirements. For instance, the acquisition point (8,8) of Pk is greater than the death
point (6,7) of Pj.
Now data manipulation operations are defined as follows (object identification is assumed and
not explicitly shown)5:

I : P (tv, tp,) {(tv,,tp,)}
U : P (t,, tp,) {(t,,tp,)}
D : (t,, tp,)

where I, U, and D denote insert, update, and delete operations, respectively, and P is a property
to be added into the database. In the definition, items in braces ({}) are optional. The restrictions
on viewpoint times of acquisition and release points are given below:

tp, = tp, if (tv,,tp,) is specified
tp, < Now if tp is event time point
tp, = Now if tp is transaction time point

While the simple I, U, and D operations defined above would be satisfactory in most situations,
there are cases in which more than one change in history happen at a viewpoint. For example, in
Figure 6, the temperature history changes at four time points at each viewpoint. At viewpoint 3/2
(event time), the history changes at (valid) time points, 3/2, 3/3, 3/4, and 3/5. In order to record
such multiple changes, I and U operations need to be extended to carry multiple properties and
their respective acquisition and release points. In the following, extended I and U operations
denoted as I* and U* are defined.

IP : {P (tv0,,tp,); Pj (tVatp0, ); }.; Pk (tvak,tPak) {(tvk,t rk)}
U* : {P (tv,,tp0,); P] (tVa0,tp0a); .. ; Ph (tVak,tPak) {(tvktp,k)}

5In practical situations, insert and update operations would carry information about several data objects (i.e.,
attributes of a tuple in the relational DBMS) together. And delete operation would take effect on a whole entity
(tuple). In this paper, however, we focus on the effect on individual data object.









In the above definition, properties Pi, Pj, - -, Pk are adjoining each other in the presented order.
Thus, the release point of Pi is the same with the acquisition point (tv,, tp, ) of Pj, and so on. The
last property's release point may be omitted. The acquisition point of the first property Pi should
be greater than the acquisition point (or death point) of lastly recorded property. The restrictions
on viewpoint time are applied similarly.

4.4 Two-dimensional (2-D) temporal validity

The one-dimensional temporal validity introduced in [3] is now extended to a two-dimensional one.
Informally, the 2-D temporal validity of a data value for a given object is the object's possession
of the value along 2-D time.
Let T2 be a 2-D time domain composed of as,

T2 = (T, x Tp)

where T, is the valid time domain, Tp is the viewpoint time domain. Tp is in turn either Tt or T,,
where Tt and T, are the transaction time domain and the event time domain, respectively.
Similarly, a 2-D time point, t2 E T2, is represented by a pair, (tv, tp), where tv E T, is a valid
time point and tp E Tp is a viewpoint time point. tp is either it or te, where it E Tt is a transaction
time point and te E T, is an event time point. Thus, a t2, in fact, would be either (tv, tt) or (tv, te)
according to T2


2-D temporal validity The 2-D temporal validity of property P of an object set A is a charac-
teristic function of P,

VP: (Ax T2) {0,1}

given by

VP(e, t2) if e P at t2

where e is an object in A, t2 is a 2-D time point in T2, P is in 7, and 7 is a property set of A.
If (e, t2) is mapped onto 1 by a characteristic function VP, then property P is said to be valid
for object e at time t2 by VP. It is assumed that for each property Pi in property set P of object
set A, there exists one or more characteristic functions, such as V1Pi, V2P, and so on.


Valid pattern A valid pattern, T2, of property P for object e, characterized by a characteristic
function VP, is defined to be a set of 2-D time points t2's, t2 E T2, such that

{t2 V(e, t2)= }.









A valid pattern is a partially bounded (2-D) time plane or a disjoint set of such planes over
which a given property is valid.
Two valid patterns, r2 and r2, are said to be equal if any t2 in T2 is also in r2 and vice versa.
A subdimension of a valid pattern r2 onto a viewpoint time point tp is defined to be a set of
valid time points {tv (tv, tp) E r2}. A subdimension of a valid pattern is semantically a valid
period of the relevant property observed at a given viewpoint.
With the valid pattern, the 2-D temporal validity is extended as follows.

V'P: (A x 2 ) {0,1}

given by

V'P(, T2) 1 ifr2 =2 = 2 Vp, t2)= }
S 0 otherwise

where e E A, a valid pattern r2 E 2T and the power set of T2, 2 T, is the domain of valid pattern.
We call functions such as V'P extended characteristic functions. Note that existence and defi-
nition of an extended characteristic function, V'P, depends on its matrix VP.


2-D extension of the interpretation-based validity Given a disjoint property set, P =
{P1, P2, -- P,} and an object set A, an interpretation-based validity, Ip for P is defined to be a
set of characteristic functions,

IP = {ViPi, VjP2, ..., kPnI

such that if VPm(e, t2) = 1, VIPm E Ip, then for all VPw E Ip, VP, V1Pm, VuPw(e, t2) = 0.
The above definition requires that valid patterns generated within an interpretation-based va-
lidity be disjoint.

4.5 Derivation of valid patterns

The definition of valid pattern per se does not tell us how to obtain such patterns, nor does what
forms they are of. In this subsection we discuss how to derive valid patterns from data manipulation
operations.


4.5.1 Derivation of typical valid patterns

Fortunately, valid patterns generated by data manipulation operations have simple regular forms.
Here we explore three typical valid patterns generated by data manipulation operations. A 2-D
time plane, shown in Figure 15, in which x-axis denotes the valid time and y-axis denotes the
viewpoint time, is used for our discussion.










Valid time


(1,1) (2,1) (3,1) (4,1) (5,1)
(1,2) (2,2) (3,2) (4,2) (5,2)
(1,3) (2,3) (3,3) (4,3) (5,3)
(1,4) (2,4) (3,4) (4,4) (5,4)
(1,5) (2,5) (3,5) (4,5) (5,5)


Viewpoint time

Figure 15: Two-dimensional time plane


Pattern-1: This form of pattern is generated when a property is added to the database by
insert or update operations specifying only an acquisition point. Assume that an insert operation,
I : P(1, 1) is to be executed and no update operation with viewpoint less than 4 is executed.6 Then,
since (1,1) is the acquisition point of property Pi, we know that a current snapshot, sn(1, 1) = Pi.
By the assumptions of indefinite prospective snapshot and isochronal history update, all prospective
snapshots with viewpoint 1 have value Pi, which is the value of the newest snapshot at viewpoint 1
(sn(1, 1)). That is, sn(m, 1) = Pi, 1 < m. At viewpoint 2, no update operation is performed.
This implies the history observed at viewpoint 2 is the same with that of viewpoint 1. In the same
fashion, the history at viewpoint 3 is equal to that of viewpoint 2.
From these snapshot values, we can draw a valid pattern for property Pi on the 2-D time plan.
Figure 16(a) is the valid pattern. Note that as time passes (i.e., Now is moving forward), the
pattern grows downwards unless an update or delete operation affecting validity of Pi is carried
out. Despite this continuing growth, we have one shape of valid pattern called pattern-1. Note that
the top-left corner of the pattern is the acquisition point of the relevant property.
Valid patterns of pattern-1 have two open boundaries at the right and the bottom sides, each
denoted by oc. The right side open boundary (along valid time axis) is just the reflection of valid-
forever scheme for indefinite future. The bottom side open boundary (along viewpoint time axis),
in fact, should be Now rather than infinity, as we assumed that the temporal database does not
handle information of future viewpoint. However, using Now as a boundary value makes things
unnecessarily complicated because Now is a moving point. Instead, we treat the bottom side open
boundary as an infinity and enforce the restriction of non-futuristic viewpoint on all queries and
data manipulation operations. By doing so, we have the same effect as using Now.
6If the viewpoint time is the transaction time, then it is equivalent to say that no update operation is executed
until time point 4.










1 2 3 4 5 6 1 2 3 4 5 6
I Valid time I I I I I Valid time
1 1
2 2
3 Pi 3 Pi
4 4
Now ^

6 6
Now

Viewpoint time Viewpoint time

(a) pattern-1 (b) pattern-2

Figure 16: Pattern-1 and pattern-2


Pattern-2: Now suppose that a release point, (4,4) of Pi is given by an update operation, U
Pj(4,4) (at viewpoint 4). Then, we know that sn(4,4) Pi (= Pj). Also, sn(m,4) = Pi, 1 <
m < 4 ( f Pi, m > 4). If no more update (or delete) operation affecting validity of property
P; is performed at viewpoint 5 and onwards, this implies that Pi's part in histories observed at
these viewpoints retains the previous state in accordance with the assumption of isochronal history
update. Hence, we have sn(m, n) = P, 1 < m < 3, n > 4.
As a result of the update (or delete) operation, a valid pattern of pattern-1 is changed to a
new one shown in Figure 16(b). We call this new shape of valid pattern pattern-2. Note that the
release point is the bottom-right concave corner indicated by a small arrow. Pattern-2 has two
open boundaries at the right and the bottom sides as pattern-1.


Pattern-3: The third form of valid pattern is generated when an insert or update operation
specifies a release point of a property as well as its acquisition point. Suppose that the update
operation, exemplified in the discussion on pattern-2, were U : Pj(4, 4)(6, 4). That is, we also know
when property Pj becomes invalid as of viewpoint 4. Here we are dealing with valid pattern for
property Pj (not Pi). From the acquisition point and release point, we know sn(4, 4) = sn(5, 4) = Pj
and sn(6, 4) P. If no operation affecting validity of Pj is performed later, by the assumption of

isochronal history update we have sn(m, n) = Pj, 4 < m < 6, n > 4.
From the snapshot values, we obtain another shape of valid pattern, called pattern-3, shown
in Figure 17 (valid pattern for Pj). Unlike pattern-1 and pattern-2, pattern-3 has only one open
boundary at bottom side, which grows downwards as time passes. The acquisition and release
points of property are, respectively, the top-left and top-right corners of the valid pattern.










1 2 3 4 5 6
| | | | | Valid time

2
3 Pi




Now

Viewpoint time

Figure 17: Pattern-3

1 2 3 4 5 6 7 1 2 3 4 5 6 7







Now
6 6

Now
ValidViewpoint time Viewpoint Valid time






(a) (b)
Figure 18: Valid patterns derived from retrospective and prospective snapshots










4.5.2 Derivation from acquisition and release points with non-current snapshots

It is noticeable that through the discussion in the previous subsection, we did not make any assump-

tion that all acquisition and release points need be of current snapshots. Indeed, such a restriction

is not necessary. We can draw valid patterns from acquisition and release points with retrospective

and prospective snapshots using the same analogy.

Suppose that acquisition point (1,3) and release point (6,5) of property Pi were given by two

successive insert (or update) and update (or delete) operations. Then, from the acquisition point

we know sn(l, 3) = Pi. Also, sn(2, 3) and sn(3, 3) should be Pi, since the fact that the acquisition

point (1,3) is the only time point where the history changed at viewpoint 3 implies that the two

snapshots have the same value as sn(l, 3). Further, all prospective snapshots at viewpoint 3 are

assumed to be Pi, according to the assumption of indefinite prospective snapshots. As a result, we

have snapshot values at viewpoint 3, sn(m, 3) = Pi, m > 1. From these snapshot values, a valid

pattern of pattern-1 is obtained. Figure 18(a) shows that valid pattern grown up to viewpoint 5

by the passage of time.

At viewpoint 5, the release point (6,5) of Pi is given. Since the release point is the only time
2 2
3 3
4 P 4 P1
5 5 --
6 6 6

Now
Viewpoint time Viewpoint time
(a) (b)

Figure 18: Valid patterns derived from retrospective and prospective snapshots


4.5.2 Derivation from acquisition and release points with non-current snapshots

It is noticeable that through the discussion in the previous subsection, we did not make any assump-

tion that all acquisition and release points need be of current snapshots. Indeed, such a restriction

is not necessary. We can draw valid patterns from acquisition and release points with retrospective

and prospective snapshots using the same analogy.

Suppose that acquisition point (1,3) and release point (6,5) of property P; were given by two
successive insert (or update) and update (or delete) operations. Then, from the acquisition point

we know sn(1, 3) = P. Also, sn(2, 3) and sn(3, 3) should be P;, since the fact that the acquisition

point (1,3) is the only time point where the history changed at viewpoint 3 implies that the two

snapshots have the same value as sn(1, 3). Further, all prospective snapshots at viewpoint 3 are
assumed to be P;, according to the assumption of indefinite prospective snapshots. As a result, we

have snapshot values at viewpoint 3, sn(m, 3) = P, m > 1. From these snapshot values, a valid

pattern of pattern-1 is obtained. Figure 18(a) shows that valid pattern grown up to viewpoint 5

by the passage of time.
At viewpoint 5, the release point (6,5) of P; is given. Since the release point is the only time









point at which history changes at viewpoint 5, we can see that sn(m,5) = Pi, 1 < m < 6.
Also, sn(n, 5) 5 Pi, n > 6. From the snapshot values, a valid pattern of pattern-2 is obtained.
Figure 18(b) shows the valid pattern grown up to viewpoint 7.
This homogeneous derivation of valid patterns from acquisition and release points given by data
manipulation operations, regardless of time difference between valid time point and viewpoint time
point, has a great consequence that valid patterns can be uniformly derived from retroactive and
proactive updates and delayed updates as well as normal on-time updates.

4.6 Multihistory

Notice that the fixed-viewpoint history introduced in 4.2.3 is a history of an object observed at
a viewpoint. If we somehow congregate fixed-viewpoint histories at all viewpoints, we may have
one history that contains information no less than all the fixed-viewpoint histories. We call such a
congregated history multihistory.
In this paper, we define the multihistory of a data object to be a set of pairs, each of which
consists of a property and its valid pattern that the object has possessed during its lifetime. A
formal definition of multihistory is given below.


Multihistory Given object set A and its property set P and given an interpretation-based validity
Ip, a multihistory MH of object e in A is a set of pairs,

MH = {(P, 2) I V'P,(e, 2) = 1, VIP, E Ip}

where property Pi E 7, r2 is the valid pattern of Pi, and V'jP, is the extended characteristic func-
tion of VjP, ( 4.4).


Due to the restriction of interpretation-based validity, it is guaranteed that valid patterns con-
stituting a multihistory do not overlap one another. Hence, these valid patterns can be readily
drawn on a 2-D time plane.
Based on the definition of multihistory, we obtain formal definitions of the fixed-viewpoint
history and 2-D snapshot.


Definition of fixed-viewpoint history. Given a multihistory MH and a fixed viewpoint ctp,
the fixed-viewpoint history at ctp is a restriction of MH over the viewpoint time such that

MHw,, = {(Ps, r2/ce,) I (P, i2) E MH}

where r2 /Ct, is a subdimension of r2 onto a fixed viewpoint ct, ( 4.4).










1 2 3 4 5 6 7 8 9
123456789
I | | | | | | | = Valid time
1 *
2
3 --



6 Pj-
7 ---------------+ --sn(6,7)
8
9 - P

Viewpoint time

Figure 19: A multihistory


Definition of 2-D snapshot. Given a property set P and a multihistory MH, the 2-D snapshot
is a function,

sn : T2 P

given by

sn(t2 P, if t2 E and (P, ,rT) G MH
e otherwise

where t2 is a 2-D time point in the 2-D time domain T2, Pi is a property in P and C is the empty
property.
Figure 19 shows a multihistory generated by a series of data manipulation operations, I

Pi(1, 1), U : Pj(4,4), and U : Pk(6, 8). Valid patterns for properties, Pi, Pj, and Pk are denoted by
2, Fr2, and ,-, respectively (not explicitly shown in the figure). Notice that valid patterns do not
overlap in a multihistory.
Each horizontal dissection of a multihistory along the viewpoint time axis yields a fixed-
viewpoint history. Conversely, a multihistory is a collection of all such fixed-viewpoint histories.
In Figure 19, cutting the multihistory at viewpoint 3 and 5 gives us the fixed-viewpoint histories
shown in Figures 12(a) and (b), respectively. In order to show this, we obtain subdimensions of
the three valid patterns at viewpoints 3 and 5 as below:

r /3= {1,2, 3,4,.. .}, rF/3=0, /3= 0

2/5= {1,2,3}, /5 {4, 5, 6, ..., /5 = 0

From the subdimensions, the same fixed-viewpoint histories are obtained as follows.

MH/3 = {(P,(1,2,3,4,...)}
MH/5 = {(Pi, (1, 2, 3)), (Pj, (4, 5, 6, .)}











Value Valid time Viewpoint time
P | (1 ~ 00) (1 ~ 00)


Figure 20: Representation for a valid pattern of pattern-1


Value Valid time Viewpoint time
Pj (4 -5) (4- ~ )


Figure 21: Representation for a valid pattern of pattern-3


On the other hand, a 2-D snapshot can be pictorially represented on a multihistory as an
intersection of the two time axes. A snapshot sn(6, 7), whose value is Pj, is depicted in Figure 19.
The simple queries exemplified in 4.1 are, in fact, to obtain 2-D snapshots on multihistories
of Figure 6 and Figure 9.

4.7 Implementation of data manipulation operations

In this subsection, we present how to construct 2-D relations, such as TEMPERATURE and
TEACHERS, from data manipulation operations. However, the method described here can be
applied to any data model.


4.7.1 Rectangular representation of valid patterns

A straightforward way to represent a valid pattern, we call ,., ,,,i.lJ.r representation, is to decom-
pose the valid pattern horizontally into several rectangles, if it is already not a rectangle. Once
divided, each rectangle is easily represented by a pair of time intervals, each of which is on the valid
time and the viewpoint time, respectively. We denote such a rectangle, being a partial represen-
tation of a valid pattern, by P : (tv, ~ tv,)(tps ~ tp,), where P is a property followed by a valid
time interval and a viewpoint time interval. The valid time interval denoted by (tv, ~ tv,) starts
at tv, and ends at tve. Similarly, tp5 and tpe are respectively the start point and end point of the
viewpoint time interval. If a rectangle has an open boundary, the end point of the open boundary
(i.e., tve or tpe) is denoted by oc.
Representations for pattern-1 and pattern-3 are trivial since these patterns are already rectan-
gles. Figure 20 shows the representation for pattern-1, the valid pattern of Figure 16(a). Likewise,
Figure 21 is the representation for pattern-3, the valid pattern of Figure 17.
For a valid pattern of pattern-2, we cut it horizontally into two rectangles as shown Figure 22.
Then, the two rectangles are represented in the same fashion. Figure 23 shows the representation









1 2 3 4 5 6
| | | | | | Valid time

2



5 Pi2
6

Viewpoint time

Figure 22: Decomposition of pattern-2


Value Valid time Transaction time
Pi, (1- oo) (1- 3)
Pi, (1 ~ 3) (4 ~ 0c)


Figure 23: Representation for a valid pattern of pattern-2


of the valid pattern of Figure 22.


4.7.2 Implementation of insert, update, and delete operation

We are now ready for implementing insert, update, and delete operations defined in 4.3.5. Fig-
ure 24 shows an algorithm implementing the three operations using the rectangular representation
of valid patterns. In the algorithm we assume that the information to be added to the database is
given by the form of {Pi(tv, tpp); Pj(tv,, tp, ); ...; } Pk(tvak, tpak){(tvk, tprk)} and we call it a
property list. Each (tv,, tp,) in the property list is the acquisition point of an associated property
(data value). Likewise, (tv,, tp,) denotes the release point of a property, and as shown only the last
property may have a release point. Recall that all viewpoint times specified in the property list
are equal. For simple (not extended) I and U operations and D operation, only the last property
with its acquisition (and release) point, i.e., Pk(tvak,tpa,){(tv.k,tp,,)}, need be specified. For D
operation Pk is empty (C).
The algorithm begins execution at line 1 by extracting the first property and its acquisition
point from the property list. At line 4, the algorithm locates those valid patterns in the database,
which are valid beyond the valid time point of the first property's acquisition point (tva < tvZ) as
of the viewpoint time of the acquisition point (tp, < tp,.). Once such valid patterns are located,
they are horizontally cut at line 5. This is because all properties in the property list have the same
viewpoint time. Further, if the last property has a specified release point, this means that the
lifespan of the relevant object terminates at the valid time point of the release point. Accordingly,














Given property list to be added
fPi(tVa,, tpa,); Pj (tV,, tpa, ); . ; I Pk(tV,,, tpa,){(tv,,, tp,,)I,

(1) get next property Pm from property list;
(2) P Pm;
(3) (t,, tp,) (tVa tp'a );
(4) for all valid patterns PW :(tvs( ~ tv)(tps, ~ tpe)
such that tv, < tv,. and tp, < tp. do
{
(5) tpe, tp P 1;
(6) if tv. < tva then
Add P, : (tv. ~- tv 1)(tp, 00);
}

(7) while loop
{
(8) peep next property P, in property list;
(9) if P, exists then
(tv,,tp,) (tVn,tpan;
(10) else
(11) if Pm has a release point then
(tV,,tp) (tVym,tpr,);
(12) else
(tV,,tp') (00,00);

(13) if P c then
(14) if tv, f 0o then
Add P: (tv, ~ tv, 1)(tp, ~ o);
(15) else
Add P: (tv, N )(tp, Do);

(16) if property list exhausted then
exit loop;
(17) get next property P, from property list;
(18) P P,;
(19) (tv,,tp,) (tVm ,tp'a);

Figure 24: Implementation of insert, update, and delete operations
Figure 24: Implementation of insert, update, and delete operations










no property should be valid beyond that valid time point at (and onward) the viewpoint time.
Otherwise if the release point of the last property is omitted, the last property is regarded as valid
up to infinity. Thus, in either case, those valid patterns in the database need be cut off not to
overlap the newly added ones.
After cutting off a valid pattern, if the acquisition point (of the first property) is in the middle of
the valid pattern, a fraction of the original valid pattern is added back at line 6 (see the valid pattern
of Pi, in Figure 22). This is the process of changing a valid pattern of pattern-1 to pattern-2.
In the while loop at line 7, the algorithm adds each property in the property list into the database
if the property is not empty (i.e., not a delete operation). If the property list is all consumed, the
while loop terminates at line 16. At line 8 through 12, the acquisition point and release point, each
denoted by (tv0a,tp) and (tv,,tp,), of a new property (P) are determined. The release point of
the new property is equal to the acquisition point of the next property in the property list, if the
next property is there. If the new property is the last one, it may have a release point or may not.
If it has one, the release point is just copied. Otherwise if the release point was not specified, the
release point of the new property is set to (oo, oo), resulting a valid pattern with open boundaries.
The get operation extracts a property and its acquisition point from the property list, whereas
the peep operation simply returns the acquisition point of the first property in the property list
without consuming it.
Let's take a look at 2-D relation TEACHERS shown in Figure 8. The relation TEACHERS has
a time granularity of one month and its viewpoint time is the transaction time. In the relation,
Jane's rank has been evolved by the following three operations.

I: Assistant (8/s,- 8/$,-.)
D : (5/89, 2/89)
I: Associate (8/91, 8/91)

Note that the rank (or an entity, Jane itself) has been reincarnated after a deletion in 2/89.
On the other hand, the relation TEMPERATURE of Figure 7, which has a time granularity
of one day and the event time as the viewpoint time, is growing by a sequence of extended insert
operations. The first eight tuples are created by two extended insert operations below.

I : 60 (3/1, 3/1); 65 (3/2, 3/1); 70 (3/3, 3/1); 65 (3/4, 3/1) (3/5, 3/1)
I : 62 (3/2, 3/2); 70 (3/3, 3/2); 70 (3/4, 3/2); 75 (3/5, 3/2) (3/6, 3/2)

Note that this relation has no explicit key. Rather than updating an existing object (entity), a new
object is inserted everyday.










tV1 t3 V1t tV2 tV3
S I Valid time a Valid time
tt,-- tt,--

P P
tt2 J tt2 P
Pk Pk
Now
P,

Transaction time Transaction time

(a) (b)

Figure 25: Effect of error corrections (I)


4.8 Error corrections

Although the term, error correction, is being used frequently, it is unrealistic to come up with a
universal definition of it because determining whether an operation is an error correction or not is
quite subjective a matter. For example, a retroactive promotion (retroactive event in general) can
be regarded as an error correction since it is anyway to rectify some incorrect fact that one has
already known to be correct. A delayed update also can be interpreted as an error correction if the
delay is too long, say, one year. Therefore, rather than having a fixed definition of error correction,
it would be more desirable to give the user the freedom of interpretation. Nonetheless, a powerful
query language is still needed in order to locate all singular points in a multihistory that can be
regarded as time points of error corrections.
In this subsection, we only deal with problems of how to make error corrections in temporal
databases with 2-D times. In order to correct errors in a multihistory, we adopt a simple over-
writing method. That is, an erroneous part of multihistory is overwritten with corrective valid
patterns. While we could handle insert, update, and delete operations with an algorithm for both
combinations of 2-D times, for error correction operation separate algorithms are needed due to
the differences in transaction time and event time.


4.8.1 Error corrections in valid time and transaction time combination

A distinctive feature of transaction time is that it bounds the viewpoint time of any operation to
Now. The error correction operation is no exception.
Figures 25 and 26 illustrate effects of error correction operations in which viewpoint time of the
operations are set to Now. Figure 25(a) shows the original erroneous multihistory. This multihistory
is changed to that of Figure 25(b) by an error correction operation. In Figure 25(b), the acquisition
point of corrective valid pattern Pi is (tv2, Now) and the release point is not determined yet. Thus,
Pi is regarded as valid forever.










tv1 tv2 tv3 tv4 tv1 tv2 tv3
I I I Valid time Valid time


P P
tt2 tt2
Pk Pk
Now - Now -
P, Ir P,

Transaction time Transaction time

(a) (b)

Figure 26: Effect of error corrections (II)


Several corrective valid patterns may be applied simultaneously. Figure 26(a) shows the case
in which two corrective valid patterns, Pi and P1, are added by partially overwriting valid patterns

P, and Pk of the original multihistory. In addition, corrective valid patterns may be of the empty
property thereby they make effects of delayed delete operations. Figure 26(b) shows such a case
where the relevant object of the multihistory terminates its lifespan at (tv3, Now).
The error correction operation, denoted by C, is defined as follows.

C : {P, (tv,, Now); Pj (tva, Now); ...; } Pk (tak, Now) {(tv,,, Now)}

As I* and U* operations, properties Pi, Pj, Pk are adjoining each other in the presented
order. Therefore, the release point of Pi is equal to the acquisition point (tv,, tp0 ) of Pj, and
so on. All viewpoint times of the specified acquisition (release) points are fixed to Now. The last
property's release point may be omitted. Also, any property can be empty (c).
The algorithm shown in Figure 27 is largely similar to that of Figure 24. One of differences is
that in Figure 27 viewpoint time of every operation is fixed to oo as it uses the transaction time
as viewpoint time. Also, unlike Figure 24, only those valid patterns that explicitly overlap a given
corrective valid pattern are horizontally cut at line 10 and 11. Consequently, the right side fragment
of an original valid pattern may be added back at line 13.
Multihistories of Figures 26(a) and (b) are obtained by applying the following two error correc-
tion operations, respectively.

C : P (tv2, Now); PI (tv3, Now) (tv4, Now)
C : Pi (tv2, Now); C (tv3, Now)

On the other hand, Smith's rank in the relation TEACHERS (Figure 8) evolved by the following
four operations.

I : Assistant (1/81, 1/81)
U : Full* (1/;, 8/,-.)















Given corrective property list
{Pi (tv,, Now); Pj (tv, Now); ...; } Pk (tvk, Now) {(tvk,N ow)},

(1) while loop
{
(2) get next property P, from property list;
(3) P Pm;
(4) (tv,,tt,) (tV,,,tt,, );
(5) peep next property P, in property list;
(6) if P, exists then
(tv,,ttr) (tV,,attj;
(7) else
(8) if P, has a release point then
(tv",,tt,) (tv,, tt, );
(9) else
(tVr, ttr) (o00, 00o);

(10) for all valid patterns Pw : (tvs,, ~ tve)(tts,, tte,)
such that tvw < tv, and tv, < tve and ttw = 0 do
{
(11) tt ,w tt, 1;
(12) if tvw < tv, then
Add P : (ts,, ~ tv, 1)(Now ~ ~o);
(13) if tvr < tvw then
Add Pw : (tv, ~ tvJ)(Now ~ o0);
}

(14) if P e5 then
(15) if tVr 50 o then
Add P: (tv, ~ tv, 1)(Now ~ ~o);
(16) else
Add P: (tv, oo)(Now ~ o0);

(17) if property list exhausted then
exit loop;
I


Figure 27: Implementation of error correction operation










1/81 1/85 8/89
I I :: Valid time
1/81 *
Assistant Assistant Assistant Assistant
8/85
Full Full" Full"
4/86
Associate 9 Associate
Full
(a) (b) (c)
Transaction time

(d)

Figure 28: An evolving multihistory


C: Associate (1/", 4/86)
U : Full (8/89, 6/89)

Figures 28(a), (b), (c), and (d) illustrate a multihistory evolving by the four operations, respec-
tively. Note that by the first U operation the relation gets a wrong data value, Full*, and this error
is rectified later (in 4/86) by C operation.


4.8.2 Error corrections in valid time and event time combination

Error correction operations in valid and event time combination can be much more complex than
the previous case. The complexity mainly stems from the fact that the viewpoint time (i.e., event
time) of corrective properties can be any past time point, unlike the valid and transaction time
combination in which the viewpoint time (transaction time) is fixed to Now. In other words, the
error correction operation need be general enough so that any part of a multihistory can be changed.
For example, in a multihistory as Figure 6, the whole or parts of any valid patterns may be changed
by error corrections. Due to this arbitrariness, any descriptive form of error correction operation
seems to be impractical, at least for the valid and event time combination. Instead, we believe a
graphic or window based approach would be more appropriate. By displaying a multihistory on
a graphic window and letting users edit the multihistory, the error correction operation can be a
simple work, which otherwise could be very awkward and error-prone. In the light of this, we do
not go further on this issue in our current work.

4.9 Set operations on multihistory

One of salient features of multihistory is that it allows set operations, such as union, intersection,
and set difference, in a straightforward way. Figure 29(a) is the same multihistory as Figure 9, i.e., a
multihistory of Smith's rank shown in relation TEACHERS. Similarly, Figure 29(b) is a multihistory
of Jane's rank. From these two multihistories, we can easily obtain a union of two valid patterns of










1/81 1/85 8/85 5/89 8/89 8/91 1/81 1/85 8/85 5/89 8/89 8/91
I I- I I I I Valid time I II II I Valid time
1/81 1/81

Assistant

8/85 8 8/85
Full*
4/86 - 4/86 Assistant

2/89 Associate 2/89-
6/89 6/89

8/91 Full 8/91 -*
Associate

Transaction time Transaction time

(a) (b)

Figure 29: Two multihistories


property Assistant. Figure 30(a) shows the result of the union operation. Likewise, Figure 30(b)
illustrates the result of an intersection operation of the property Associate of Figure 29(a) and the
property Assistant of Figure 29(b).
Interpretation of resultant multihistories is very intuitive. For Figure 30(a), 2-D time points
within the multihistory are those time points that Smith or Jane was assistant professor at the
valid time point and that fact was observed at the transaction time point. For example, if we set
our viewpoint back to 6/89 (in transaction time), we can see a fixed-viewpoint history defined over
two time periods, (1/81 ~ 12/84) and (8/,". ~ 4/89). During these time periods, either Smith
or Jane (or possibly both) was assistant professor. Interpretation of an intersection operation is
straightforward too. In Figure 30(b), 2-D time points within the resultant multihistory occur when
Smith's rank was associate professor and Jane's, assistant professor, at the same time. When the
viewpoint is set back to 4/86, both Smith's rank, associate professor, and Jane's rank, assistant
professor, are valid at the same time only during the time period (8/' -. oc).
It is also noticeable that the set operations maintain the property of indefinite future discussed
in 4.3.4 in an intuitive way. Generally speaking, union of definite future and indefinite future yields
indefinite future, and intersection of definite and indefinite yields definite. This rule holds for each
time axis. For instance, observe that the associate professor property of Smith (Figure 29(a)) has
indefinite future during 4/86 through 5/89 in transaction time and the assistant professor property
of Jane (Figure 29(b)) has definite future since 2/89 in transaction time. Then, in the result of
intersection operation shown in Figure 30(b), we can see that intersection of these indefinite future
and definite future contributed to a portion of definite future during 2/89 to 5/89 in transaction
time. Further, if we perform another intersection operation of Full* of Figure 29(a) and Assistant










1/81 1/85 8/85 5/89 8/89 8/91 1/81 1/85 8/85 5/89 8/89 8/91
I I- I I I I Valid time I II II I Valid time
1/81 1/81


8/85 8/85
4/86 4/86

2/89 2/89
6/89 6/89

8/91 8/91


Transaction time Transaction time

(a) (b)

Figure 30: Union and intersection operations


of Figure 29(b), we will obtain a multihistory equivalent to the valid pattern of Full*. This result
also coincides with our intuition.
The application of set operations, however, may result in a multihistory with very complex
shape as such operations are applied repeatedly. Figure 30(a) is already not a simple form. While
implementation of unrestricted set operations would be very difficult due to the complex multi-
history produced, the multihistory still provides us with a good understanding of the semantics of
set operations over temporal databases with 2-D time. It should be noted that the complexity is
inherent to the set operations, and the multihistory just reveals the hidden complexity.


5 Conclusions


In this paper, we have presented an interpretation of the temporal database with two-dimensional
time and its implementation. We have proposed the notion of viewpoint time that encompasses the
transaction time and the event time and, in conjunction with the valid time, constitutes 2-D time.
Upon the 2-D time, the 1-D temporal validity has been extended to 2-D temporal validity and the
notion of valid pattern drawn out. The important notion of multihistory, being a congregation of
a data object's history observed at every viewpoint, has been introduced using the valid pattern.
We have defined temporal data manipulation operations and shown how to derive valid patterns
from the information carried by the operations. Further, we have presented an algorithm that
directly yields time-stamps implementing the multihistory on the relational data model from data
manipulation operations. We have also shown an implementation of error correction operation
for 2-D time consisting of valid and transaction times. Lastly, the feasibility and semantics of set
operations over multihistory have been demonstrated.










Several issues are open or are not handled in this paper. First, we could extend this work to the
case of three-dimensional time consisting of valid, event, and transaction times, thereby all multiple
past states generated by retroactive/proactive updates, error corrections, and delayed updates can
be preserved. However, we realized that without help of a proper graphic interface it would be
hard to formulate correct and meaningful queries and data manipulation operations (including
error correction operations). Extension for such a graphic interface is beyond the scope of our
current work. Second, as mentioned, the implementation of set operations is quite difficult due to
the complex-shaped multihistory (valid patterns) produced. Although we may use the techniques
developed in AI or other disciplines, it is questionable whether such an overhead can be justified
compared to possible benefits from the set operations. Lastly, in this work we did not focus on
queries on temporal databases with 2-D time. Even though some researchers have paid attention
to this area, we feel more investigation is still necessary.


References

[1] I. Ahn. Towards An Implementation of Database Management Systems with Temporal Sup-
port. In Proceedings International Conference on Data Ei,',.. i ',-i pages 374-381, Los An-
geles, 1l'i'i

[2] G. Ariav. A Temporally Oriented Data Model. AC if Transactions on Database Systems,
11(4):499-527, 1',i.

[3] S. Chakravarthy and S.-K. Kim. Resolution of Time Concepts in Temporal Databases. Techni-
cal Report UF-CIS-TR-93-004, Database Systems R&D Center, CIS Department, University
of Florida, January 1993.

[4] S. Chakravarthy and S.-K. Kim. Semantics of Time-varying Information and Resolution of
Time Concepts in Temporal Databases. In International Workshop on an Infrastructure for
Temporal Databases, Arlington, TX, 1993.

[5] J. Clifford and A. Tansel. On An Algebra for Historical Relational Databases: Two Views. In
Proceedings International Conference on 1I,, ... ir. 1I of Data, pages 247-265, Austin, Texas,



[6] J. Clifford and D. Warren. Formal Semantics for Time in Databases. AC if Transactions on
Database Systems, 8(2):214-2". L, 1',.;

[7] G. Copeland and D. Maier. Making Smalltalk a Database System. In Proceedings International
Conference on 1i1,..-. i'. I of Data, pages 316-325, Boston, MA, 1', L.










[8] R. Elmasri, M. Jaseemuddin, and V. Kouramajian. Partitioning of Time Index for Optical
Disks. In Proceedings International Conference on Data Ei',. i i pages 574-583, Tempe,
Arizona, 1992.

[9] R. Elmasri and G. Wuu. A Temporal Model and Query Language for ER Databases. In
Proceedings International Conference on Data Ei.',, ',-i pages 76-83, Los Angeles, 1990.

[10] R. Elmasri, G. Wuu, and Y.-J. Kim. The Time Index: An Access Structure for Temporal Data.
In Proceedings International Conference on Very Large Data Bases, pages 1-12, Brisbane,
Australia, 1990.

[11] D. Gabbay and P. McBrien. Temporal Logic & Historical Databases. In Proceedings Interna-
tional Conference on Very Large Data Bases, pages l'.; .;lii Barcelona, Spain, 1991.

[12] S. Gadia. A Homogeneous Relational Model and Query Languages for Temporal Databases.
AC I[ Transactions on Database Systems, 13(4):418-448, i'"-

[13] Seung-Kyum Kim. A Formal Appproach to Two-Dimensional Temporal Databases. Master's
thesis, Department of Computer and Information Sciences, University of Florida, Gainesville,
FL 32611, December 1992.

[14] M. Klopprogge. Term: An Approach to Include the Time Dimension in the Entity-Relationship
Model. In P. P. Chen, editor, Entity-Relationship Approach to I,1,, 1...1',, Modeling and
Analysis, pages 473-508. Elsevier Science Publishers, Amsterdam, 1''-.;

[15] V. Lum, P. Dadam, R. Erbe, J. Guenauer, P. Pistor, G. Walch, H. Werner, and J. Woodfill. De-
signing DBMS Support for the Temporal Dimension. In Proceedings International Conference
on 1, ..i. t. ,/ of Data, pages 115-130, Boston, MA, 1',i L.

[16] S. B. Navathe and R. Ahmed. A Temporal Relational Model and a Query Language. Infor-
mation Sciences, 49:147-175, 1','-

[17] N. Sarda. Extensions to SQL for Historical Databases. IEEE Transactions on Knowledge and
Data E,.i',,.. -, ", 2(2):220-230, June 1990.

[18] L. Schafers and G. Schlageter. Toward Full Support of Modeling and Querying Temporal As-
pects in Relational Database Systems. Technical report, University of Hagen, West Germany,
1991.

[19] A. Sernadas. Temporal Aspects of Logical Procedure Definitions. I,,',,, ni. i/', Systems, 5:167
187, 1980.










[20] A. Shoshani and K. Kawagoe. Temporal Data Management. In Proceedings International
Conference on Very Large Data Bases, pages 7', Kyoto, Japan, 1'',-

[21] R. Snodgrass. The Temporal Query Language TQuel. AC if Transactions on Database Systems,
12(2):247-"' ,June 1' l;.

[22] R. Snodgrass and I. Ahn. A Taxonomy of Time in Databases. In Proceedings International
Conference on i,,.... it., ,I of Data, pages 236-246, Austin, Texas, 1I'l,

[23] M. D. Soo. Bibliography on Temporal Databases. AC if SI(, IOD Record, 20(1):14-23, March
1991.

[24] S. Sripada. A Logical Framework for Temporal Deductive Databases. In Proceedings Interna-
tional Conference on Very Large Data Bases, pages 171-182, Los Angeles, 1''-

[25] C. Theodoulidis and P. Loucopoulos. The Time Dimension in Conceptual Modelling. Infor-
mation Systems, 16(3):273-300, 1991.

[26] A. Tuzhilin and J. Clifford. A Temporal Relational Algebra as a Basis for Temporal Relational
Completeness. In Proceedings International Conference on Very Large Data Bases, pages 13
23, Brisbane, Australia, 1990.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs