Temporal Databases

Richard Snodgrass, University of North Carolina at Chapel Hill

llsoo Ahn, AT&T Bell Laboratories

Databasemanagement systemsshould providetemporal supportdirectly. Four types ofdatabases aredifferentiated by theirability to representtemporal information.

Time is an essential part of infor-mation about the constantly evolv-ing real world. Facts or data need to

be interpreted in the context of time.Causal relationships among events orentities are embedded in the temporalinformation. Time is a universal attributein most information management applica-tions and deserves special treatment assuch.

Databases supposedly model reality,but conventional database managementsystems (DBMSs) lack the capability torecord and process time-varying aspects ofthe real world. With increasing sophistica-tion of DBMS applications, the lack oftemporal support raises serious problemsin many cases. For example, conventionalDBMSs cannot support historical queriesabout past status, let alone trend analysis(essential for applications like decisionsupport systems). There is no way to repre-sent retroactive or proactive changes,while support for error correction or audittrail necessitates costly maintenance ofbackups, checkpoints, or transaction logsto preserve past states. There is a growinginterest in applying database methods forversion control and design management incomputer-aided design, requiring capa-bilities to store and process time-dependent data. Without temporal sup-port from the system, many applicationshave been forced to manage temporalinformation in an ad-hoc manner.

The need to provide temporal supportin DBMSs has been recognized for at leasta decade. A bibliographical survey in 1982contained about 70 articles relating timeand information processing, I and at least90 more articles have appeared since then.Recently, the rapid decrease of storage

costs, coupled with the emergence ofpromising new mass storage technologiessuch as optical disks,2 has amplified in-terest in database management systemswith version management or temporalsupport. George Copeland maintainedthat

... as the price of hardware continuesto plummet, thresholds are eventuallyreached at which these compromises [toachieve hardware efficiency] must be re-balanced in order to minimize the totalcost of a system. . . . If the deletionmechanism common to most databasesystems today is replaced by a non-dele-tion policy .. ., then these systems willrealize significant improvements infunctionality, integrity, availability, andsimplicity. 3

Gio Wiederhold also observed, in a reviewofthe present state ofdatabase technologyand its future, that

The availability of ever greater and lessexpensive storage devices has removedthe impediment that prevented keepingvery detailed or extensive historicalinformation in on-line databases....An immediate effect of these changeswill be the retention of past data ver-sions over long periods. 4In the past five years, numerous

schemes have been proposed to supporttemporal information processing indatabase management systems by incor-porating one or more time attributes.However, there has been some confusionconcerning terminology and the definitionof these time attributes. In this article wedescribe a taxonomy of time consisting ofthree distinct time concepts for use in data-bases.5 Using the taxonomy, we defimefour types of databases, differentiated bytheir ability to support these time conceptsand processing of temporal information.

001891602/86/0900e003590100 © 1986 IEEE 35Septembe3r 1986

I I l II

___7

Figure 1. A snapshot relation.

Figure 3. An historical relation.

transactiontime

Figure 2. A rollback relation.

v.£K ~~~vali& vff vitime time tme tine

transactiontime

Figure 4. A temporal relation.

The taxonomy

Although the following discussion isbased on the relational model, analogousarguments also apply to hierarchical ornetwork models.

Snapshot databases. Conventionaldatabases model an enterprise as itchanges dynamically by a snapshot at aparticular point in time. A state or an in-stance of a database is its current content,which does not necessarily reflect the cur-rent status of the enterprise. The state of adatabase is updated using data manipula-tion operations such as insertion, deletion,or replacement, taking effect as soon asthey are committed. In this process, paststates of the database, representing thoseof the enterprise, are discarded and for-gotten. We term this type of database asnapshot database.

In the relational model, a database is acollection of relations. Each relation con-sists of a set of tuples with the same set ofattributes and is usually represented as atwo-dimensional table (see Figure 1). Aschanges occur in the enterprise, this tableis updated appropriately. For example, ata certain moment an instance of the rela-tion Faculty with the two attributes Nameand Rank may be

Name Po*

Merie Associate ProfessorTom Assodate Professor

and a query in Quel (a tuple calculus-basedlanguage for the Ingres database manage-ment system 6) as to Merrie's rank,

range of f is Facultyretrieve (f.Rank)

where f.Name = "Merrie"yields the rank of associate professor.

In many situations this snapshot data-base is inadequate. For example, it cannotanswer queries such as

* What was Merrie's rank two yearsago? (historical query)

* How did the number of facultychange over the last five years? (trendanalysis)

nor record facts like* Merrie was promoted to a full pro-

fessor starting last month. (retro-active change)

* Lee is joining the faculty next month.(proactive change)

Without system support in this respect,many applications have had to maintainand handle temporal information in an ad-hoc manner. For instance, many person-nel databases attempt to record the entireemployment history of the company'semployees. That some of the attributesrecord time and that only a subset of theemployees actually work for the companyat any particular point in time do not con-cern theDBMS itself. TheDBMS providesno facility for interpretation or manipula-tion of this information; such operationsmust be handled by specially-writtenapplication programs. The fact that datavary over time is not an application-

specific aspect. This aspect should be sup-ported in a general fashion by the DBMS,rather than by application programs.

Rollback databases. One approach toresolving the above deficiencies is to storeall past states, indexed by time, of thesnapshot database as it evolves. Such anapproach requires a representation oftransaction time, the time the informationwas stored in the database. Under this ap-proach a relation can be illustrated con-ceptually in three dimensions (see Figure2), with transaction time serving as thethird axis. The relation can be regarded asa sequence of snapshot relations (termedsnapshotstates) indexed by time. By mov-ing along the time axis and selecting a par-ticular snapshot state, it is possible to get asnapshot ofthe relation at some time in thepast and make queries about it (a snapshotrelation). The operation of selecting asnapshot state is termed rollback, and adatabase supporting it is termed a rollbackdatabase.Changes to a rollback database may be

made only to the most recent snapshotstate. The relation illustrated in Figure 2had three transactions applied to it, start-ing from a null relation: (1) addition ofthree tuples, (2) addition of one tuple, and(3) deletion of one tuple (entered in thefirst transaction) and addition of anothertuple. Each transaction results in a newshapshot state being appended to the frontof the time axis. Once a transaction is com-mitted, the snapshot states in the rollbackrelation may not be altered.

36COMPUTER

The distinction between snapshot data-bases and rollback databases is that the lat-ter have the ability to return to any previ-ous state to execute a snapshot query. Anyquery language can be converted to onethat can query a rollback database byadding a clause effecting the rollbackoperation. TQuel (for Temporal QUEryLanguage),7 an extension of Quel fortemporal databases, augments the retrievestatement with an as of clause to specifythe relevant transaction time. The TQuelquery

range of f is Facultyretrieve (f.Rank)where f.Name = "Merrie"as of 'September 1978"

on a rollback Faculty relation will findMerrie's rank as of September 1978. Theresult ofa query on a rollback database is apure snapshot relation.One limitation of supporting transac-

tion time is that the history of databaseactivities, rather than the history of thereal world, is recorded. A tuple becomeseffective as soon as it is entered into thedatabase, as in a snapshot database. Thereis no way to record retroactive/proactivechanges, nor to correct errors in pasttuples. Errors can sometimes be over-ridden (if they are in the current state), butthey cannot be forgotten. For instance, ifit were discovered that Merrie's promo-tion had occurred earlier than previouslyrecorded, this error could not be correctedin a rollback database; the query givenabove would continue to respond with theincorrect rank.

Historical databases. While rollbackdatabases record a sequence of snapshotstates, historical databases record a singlehistorical state per relation. As errors arediscovered, they are corrected by modify-ing the database. Previous states of thedatabase itself are not retained, so it is notpossible to view the database as it was inthe past. No record is kept of the errorscorrected. Historical databases resemblesnapshot databases in this respect.Historical databases support valid time,the time when the relationship in the enter-prise being modeled was valid.The semantics of valid time are closely

related to reality, hence more complexthan the semantics of transaction timeconcerned with database activities. There-fore, historical databases need sophisti-cated operations to manipulate the com-

plex semantics of valid time adequately.TQuel supports such queries (termed his-torical queries) by augmenting the retrieve

statement with a valid clause to specifyhow the implicit time attribute is com-puted and a when predicate to specify thetemporal relationship of tuples participa-ting in a derivation. These added con-structs handle complex temporal relation-ships such as begin of, precede, andoverlap. For example, the TQuel queryrequesting Merrie's rank when Tom ar-rived is

range of fl is Faculty-range of f2 is Facultyretrieve (fl.Rank)where fl.Name = 'Merrie' and

f2.Name = 'Tom'when fl overlap begin of f2

The derived relation is also a historical re-lation that can be used in further historicalqueries.

Another distinction between historicaland rollback databases is that historicalDBMSs support arbitrary modification,whereas rollback DBMSs only allow snap-shot states to be appended. The same se-quence of transactions that resulted in therollback relation in Figure 2 will result inthe historical relation in Figure 3, wherethe label of the time axis indicates the validtime. However, the historical relation canshow that a later transaction has changedthe time when a tuple takes effect in therelation, which is not possible on a roll-back relation. Rollback DBMSs can rollback to an incorrect previous snapshotrelation; historical DBMSs can representcurrent knowledge about the past.

Temporal databases. Benefits of bothapproaches can be combined by support-ing both transaction time and valid time inthe same relation. While a rollbackdatabase views stored tuples, whethervalid or not, as of some moment in time,and a historical database always viewstuples valid at some moment as of now, atemporal database can view tuples valid atsome moment seen as of some other mo-ment, thereby completely capturing thehistory of retroactive/proactive changes.The user of a temporal DBMS can exam-ine historical information from the view-point of a previous state of the database;both kinds of time may be manipulated ina query.We use the term temporal database to

emphasize the need for both valid time andtransaction time in handling temporal in-formation. Since there are two orthogonaltime axes involved now, temporal rela-tions should be illustrated in four dimen-sions (Figure 4 shows a single temporalrelation).

A temporal relation may be regarded asa sequence of historical states, each a com-plete historical relation. The rollbackoperation on a temporal relation selects aparticular historical state, on which a his-torical query can be executed. Each trans-action causes a new historical state to becreated; hence, temporal relations areappend-only. The temporal relation inFigure 4 is the result of four transactions,starting from a null relation: (1) threetuples were added, (2) one tuple wasadded, (3) one tuple was added and an ex-isting one deleted, and (4) one tuple wasmodified so that it started at a later validtime.

Since TQuel supports both historicalqueries and rollback operations, it can beused to query temporal databases. An ex-ample is the TQuel query

range of fl is Facultyrange of f2 is Facultyretrieve (fl.Rank)

where fl.Name = "Merrie' andf2.Name = 'Tom'

when fl overlap begin of f2as of 'January 1979"

that determines Merrie's rank when Tomarrived, according to the state of thedatabase as of January 1979. This derivedrelation is a temporal relation, so furthertemporal relations can be derived from it.The answer may differ if a similar query ismade as of October 1978 and if her pro-motion was not yet recorded by that time.

User-defined time. User-defined time isnecessary when additional temporal infor-mation, not handled by transaction orvalid time, is stored in the database. Thevalues of user-defined temporal attributesare not interpreted by the DBMS and arethus the easiest to support; only an inter-nal representation and input/output func-tions are needed. Such attributes will thenoccur in the relation scheme. Multiple rep-resentations are also possible, each associ-ated with input and output functions. Asan example of user-defined time, considera Promotion relation with three attributes:Name, Rank, and Approved-Date. TheApproved-Date (a user-defined time) isthe date when the promotion committeeapproved the promotion; the valid time isthe date when the promotion will take ef-fect; and the transaction time is the datethe information concerning the promo-tion was stored in the database.

An analogy. A simple analogy will helpclarify the subtle differences among thefour types ofdatabases categorized above.

September 1986 37

No rollback Rollback

Current Snapshot Rollback

Historical Historical Temporalqueries

Figure 5. Types of databases.

| Transaction ValidSnapshot

Rollback

Historical

Temporal

Figure 6. Attributes of the four types ofdatabases.

First, a snapshot relation can be com-pared to the latest payroll stub showing thecurrent position of the recipient. If theperson gets a promotion, the next stubshows the new rank, but there is no way tofind out about a past rank from the lateststub.

If all the payroll stubs are carefully col-lected without discarding any of them, assome people do, it is possible to determinethe rank as of some time in the past fromthe stub of that period. This collection ofpayroll stubs can be compared to a roll-back relation, a slice ofwhich is a snapshotrelation comparable to a payroll stub.These stubs will be printed in indelible ink,so that it will not be possible to makechanges to payroll stubs of the past, evenwhen there is a retroactive promotion oran error in last year's salary.A historical relation can be compared to

a resume, containing the history of jobpositions a person held up through themoment the resume was prepared. If anerror is found in the resume, or if the per-son gets a promotion, a new resume re-flecting the change is in order. The currentresume should always be up to date.A temporal relation can be considered

as a collection of all such resumes markedby the date when each of them was pre-pared. It is possible and often interestingto go back to an old resume and readabout the personal data as known at somepast moment.

An analogy for user-defined time wouldbe the date printed on each payroll stub in-dicating when the pay period started. Notethat this date does not necessarily corre-spond to the date the check (or the pre-vious one) was issued.

Summary of taxonomy. Three kinds oftime-transaction time, valid time, anduser-defined time-were introduced, re-sulting in a categorization of the types ofdatabase management systems based ontheir support for handling temporal infor-mation. As shown in Figure 5, transactiontime and valid time define the two orthog-onal capabilities of rollback operationsand historical queries, thereby differen-tiating four types of databases: snapshot,rollback, historical, and temporal.

Support of rollback operations requiresthe incorporation of transaction time,which concerns the representation. Sup-port of historical queries requires the in-corporation of valid time, which is associ-ated with reality. Support of user-definedtime is orthogonal to support of historicalqueries or rollback operations. Hence, thethree kinds of time actually define eightdifferent types of databases. The taxon-omy presented here defines four typesbased on their support of transaction andvalid time (see Figure 6). Each of thesetypes may or may not support user-defined time. However, we note that user-defined time is much closer to valid timethan to transaction time, in that both validtime and user-defined time are concernedwith reality itself, whereas transactiontime involves only the model of reality (thedatabase). DBMSs (and their query lan-guages) purporting to provide full tempor-al support should handle all three kinds oftime.

An exampleThe following example highlights the

similarities and differences among thefour types of relations, snapshot, roll-back, historical, and temporal. We firstcreate an empty relation for each of thefour types using TQuel create statements:

create Snapshot (Name = c20, Rank =c20)

create persistent Rollback (Name = c20,Rank = c20)

create interval Historical (Name = c20,Rank = c20)

create persistent interval Temporal (Name= c20, Rank = c20)

These are the relations alluded to earlier,namely, the latest payroll check (snapshot),

the collection of all past payroll stubs(rollback), the most current resume(historical), and the collection of all pastresumes (temporal).

Starting with these empty relations, aseries of update operations are applied toeach of them. After each update opera-tion, the states of four relations are dis-played: the snapshot relation in a conven-tional format as a single snapshot state,the rollback relation as a sequence of snap-shot states, the historical relation as asingle historical state, and the temporalrelation as a sequence of historical states.Several queries on these relations focus onwhat information is and, more important-ly, is not represented in each relation.

Meme joins as an instructor. In Sep-tember 1973, the following statement isexecuted:

append to ? (Name = 'Merrie", Rank =" Instructor if)

In these examples, the "?" symbol wouldbe replaced by the name of a relation:snapshot, rollback, historical, or tem-poral.The four relations resulting from the

execution of this statement are almostidentical (see Figure 7). The snapshot rela-tion shows that Merrie is currently an in-structor. The rollback relation contains asingle snapshot state created on September1973 (the transaction time that indexes thesnapshot states is shown following thestate), indicating that Merrie startedreceiving payroll checks made out to "In-structor Merrie" from September 1973.The historical relation indicates that Mer-rie has been hired as an instructor (thevalid time for each tuple in the historicalstate is shown to the left ofthe tuple); thereis currently one line on Merrie's resume.The temporal relation contains onehistorical state, containing one tuple;analogously, there is one resume with oneentry in Merrie's resume file.

If we asked back in October 1973"What was Merrie's rank?",

range of f is ?retrieve (f.Rank)

where f.Name = "Merrie"the same information would be returnedfrom all four relations ("Instructor"), butin rather different ways. For the rollbackrelation, the current snapshot state is used;for the historical relation, the tuples cur-rently valid are searched; and for the tem-poral relation, the tuples currently valid inthe current historical state are searched.The defaults defined in TQuel ensure thatqueries containing only where clauses will

COMPUTER38

return the same information regardless ofrelation types.7

Merrie is promoted to fuil professor. InDecember ofthat year, a replace statementis executed:

replace f (Rank = 'Full Professor')where f.Name = "Merrie"

Figure 8 illustrates the changes in the fourrelations. Since the snapshot relationrecords only the current information, theexisting tuple is modified, as is the nextpayroll check made out to Merrie. A newsnapshot state is appended to the rollbackrelation; Merrie's pay stubs for September1973 through November 1973 still read"Instructor Merrie," but the December1973 paycheck is made out to "Full Pro-fessor Merrie." Snapshot states within therollback relation are separated by dottedlines. A tuple is added to the historicalrelation with a valid time of December1973; an entry is also added to Merrie's re-sume. The historical relation always con-tains only one historical state, so no dottedlines will appear in its illustration.The historical relation is an interval rela-

tion. In the representation shown in Figure8, a tuple is valid until the next tuple withthe same key becomes effective. Hence,the historical relation in this figure indi-cates that Merrie was an instructor fromSeptember 1973 until December 1973,when she became a full professor. Thetemporal relation contains two historicalstates: one current from Septemberthrough November 1973 and the longerone created in December 1973. Merrie'sresume file now contains two resumes, onedated September 1973 containing one jobpdsition, and the more recent one datedDecember 1973 containing two job posi-tions. Only one transaction time is neededfor each historical state, even if it containsmultiple tuples.When we ask the next month, January

1974, about Merrie's rank,retrieve (f.Rank)

where f.Name = "Merrie"we again get the same result from all fourrelations ("Full Professor"), except thatwe also get the past rank of Instructorfrom the historical and the temporal rela-tions. If we ask in January, "What wasMerrie's rank last October ?":

retrieve (f. Rank)where f.Name = "Merrie"when f overlap "October, 1973"

we run into some difficulties. This querycannot be executed on a snapshot relation,since information about the past is not

Snapshot: Nee Instructor

Rollback:Nwre F~k R(Transaction Time)Meme Instructor (September 1973)

Hlstorical:Valid Time) Nm Rwk'(SeptemberF1973)Meme Instructor

Temporal:(Valid Timea Fbk Trnction Time)(September- 1973) rems Instructor (September 1973)-

Snapshot:N~ RwkMeme Full Professor

Rollback:Nam ark{Transaction Time)

Morrie Instructor (September 1973)-................................ ....... ............................

Merrie Full Professor (December 1973)

Historical:VYalid time) Nff tc(September 1973) Merrie Instructor(Decemrber 1973) Merrie Full Professor

Temporal:lid Time) Rrk (Transaction Time)tSoptr r 1973) Meme Instructor (September 1973)

(September 1973) Morrie Instructor (Decembr ij(December 1973) Meme Full Professor

Figure 8. Merrie is promoted to full professor.

stored (looking at Merrie's pay stub fromJanuary won't tell us what the paycheckread three months earlier). The rollbackrelation can't give us an answer either. Ofcourse, we could flip through the payrollstubs, but such a search won't tell us ifMerrie was given a retroactive promotion(such a situation will be examined shortly).Both the historical and temporal relationscan provide the answer "Instructor" byexamining the current resume (the histori-cal relation records only the current oneanyway).

Still interacting with the DBMS in Jan-uary 1974, we ask "What did we thinkMerrie's current rank was three monthsago?":

retrieve (f.Rank)where f.Name = "Merrie"as of "October, 1973"

This query effectively turns back the clockto October; all changes after October arenot considered. A result is not forthcom-ing from either the snapshot or the histori-cal relations, because they both recordonly current knowledge (in the case ofhistorical relations, current knowledgeabout the past). In this case, however, flip-ping through the pay stubs or the stack ofresumes (the rollback and temporal rela-tions, respectively) will allow us to deter-mine what we knew in October 1973: thatMerrie was then an instructor.

39September 1986

Snapshot:Nam RankMerrie Assistant Professor

Rollback:Nam Rark (Transaction Time)Merrie Instructor (September 1973)

.......................... ................................ .-*.*@.

Merrie Full Professor (December 1973)Merrie Assistant Professor (February 1974)

Historical:(Valid Time) Namn FbkSeptember 1973) Merrie InstructorDecember 1973) Merrie Assistant Professor

Temporal:Valid Time) Name Ra ransaction Time)September 1973) Merrie Instructor (Setember 1973)............................... ........... ........................................ ...................................September 1973) Merrie Instructor (December 1973)December 1973) Merrie Full Professor

September 1973) Merrie Instructor (February 1974)(December 1973) Merrie Assistant Professor

Figure 9. A correction.

A correction. In the next month,however, we realize that we made a mis-take. Last December, Merrie wasn't pro-moted from instructor to full professor;she was only promoted to assistant pro-fessor. We modify the historical and thetemporal relations in February 1984 by

replace f (Rank = "Assistant Professor")valid from begin of "December 1973"where f.Name = "Merrie"

but we can correct only the current state ofthe snapshot and rollback relations by

replace f (Rank = "Assistant Professor")where f.Name = "Merrie"

Figure 9 shows that the next paycheck willindicate a new rank, paychecks issuedfrom February 1974 on will bear the cor-rect title, and the current resume is cor-rected.Note that the pay stubs for December

1973 and January 1974 still mention "FullProfessor Merrie" and that the resume filestill contains an old resume with the incor-rect promotion rank; both of these rela-tions are by definition append-only.We perform three queries in August.

We first ask about Merrie's current rank:retrieve (f.Rank)

where f.Name = "Merrie"All four relations respond with "AssistantProfessor," except that we also get thepast rank of "Instructor" from the

historical and temporal relations. Whenasked what Merrie's rank was in January,

retrieve (f.Rank)where f.Name = "Merrie"when f overlap "January 1974"

the snapshot and rollback relations cannotprovide an answer. However, the histori-cal and temporal relations both respondwith the corrected rank, "Assistant Pro-fessor. "

If we ask a different question, "Whatwas Merrie's current rank as best knownlast January?",

retrieve (f.Rank)where f.Name = "Merrie"as of "January 1974"

then the snapshot and historical relationscannot reply, since they only record infor-mation as currently known. Both the roll-back and temporal relations can providethe information we request ("Full Profes-sor"), while the temporal relation alsoprovides the past rank of "Instructor."

Merne is promoted retroactively. InDecember 1978, Merrie is promoted toassociate professor, retroactive from June1978. We record the fact in the historicaland temporal relations by

replace f (Rank = "Associate Professor")valid from begin of "June 1978"where f.Name = " Merrie"

but we can modify only the current state ofthe snapshot and rollback relations by

replace f (Rank = "Associate Professor")where f.Name = "Merrie"

As shown in Figure 10, the fact that thepromotion was retroactive is irrelevant inthe snapshot and rollback relations. Inparticular, the pay stubs (the rollback rela-tion) from February 1974 to November1978 still specify "Assistant ProfessorMerrie." However, the current resume(the historical relation) and the most re-cent resume in the resume file (the tem-poral relation) will both record the promo-tion date as June 1978.When we query the relations in the fol-

lowing March, all four will list Merrie'scurrent rank as "Associate Professor."The historical and temporal relations willlist her rank in October 1978 as "AssociateProfessor. " The rollback and temporal re-lations will list her current rank, as bestknown in October 1978, as "Assistant Pro-fessor," indicating that the promotion hadnot been made. However, the temporalrelation can answer even more involvedqueries, such as "What was Merrie's rankin October 1978, as best known inNovember 1978?":

retrieve (f.Rank)when f overlap "October, 1978"where f.Name = "Merrie"as of "November 1978 "

This query can only be answered by thetemporal relation, which returns a rank of"Assistant Professor." If the as of clausewere omitted, the result would be "Asso-ciate Professor."We have examined the information rep-

resented by each of the four types of rela-tions and have shown how each relationresponds to various update and retrievaloperations. A few tautologies should nowbe defensible:

* The most recent snapshot state in therollback relation is always identical tothe entire contents of the snapshotrelation.

* Similarly, the most recent historicalstate in the temporal relation isalways identical to the entire contentsof the historical relation.

* Queries containing only a target listand a where clause will return thesame information when applied toany of the four types of relations.

An implementationThere are several approaches to imple-

menting a DBMS supporting the opera-

40 COMPUTER

tions described above. When confrontedwith the task of adding temporal supportto a DBMS, one reasonable initial strategywould be to interpose a layer of code be-tween the user and the database system.This layered approach has the significantadvantage of not requiring any change tothe complex data structures and algo-rithms within the DBMS proper. How-ever, the petformance of such a systemmay be inadequate. An immediate con-

cern is the monotonically increasing andpotentially enormous storage require-ments. In addition, there are multiple ver-

sions for some tuples, rendering conven-

tional storage schemes such as indexing or

hashing less effective. Performance willdeteriorate rapidly not only for temporalqueries but also for nontemporal queries.An alternative is to integrate temporal

support into the DBMS itself, developingnew query evaluation algorithms and ac-

cess methods to achieve reasonable perfor-mance for a variety of temporal querieswithout penalizing more frequent non-

temporal queries. This approach clearlyinvolves substantial research and imple-mentation effort, yet promises to addressdeficiencies in performance.We have adopted an intermediate strat-

egy in implementing our prototype tem-poral lMBS. We modified portions of thesnapshot DBMS Ingres, 6 but still used theconventional access methods and query

evaluation algorithms available in it. Sucha strategy may also be useful when addingtemporal support to a conventional hierar-chical or network DBMS. This prototypehelps identify problems with conventionalaccess methods and query evaluation al-gorithms in providing temporal support,and serves as a comparison point for fullyintegrated DBMSs developed in thefuture. We also used it to run the examplequeries above, where it flagged a few sub-tle errors that had escaped our scrutiny.One of the most important decisions

was determining how to embed a four-dimensional temporal relation into a two-dimensional snapshot relation as sup-ported by Ingres. There are at least fiveways to embed a temporal relation in a

snapshot relation.7 Our prototype adoptedthe scheme of augmenting each tuple withtwo transaction time attributes for a roll-back and a temporal relation, and one or

two valid time attributes for a historicaland a temporal relation, depending on

whether the relation modeled events or in-

tervals. Each update operation on an exist-

ing tuple generates a new version of the

tuple, marked with appropriate values of

Figure 10. Merrie is promoted retroactively.

time attributes indicating the period theversion is active. Although this tuple ver-

sioning scheme appears to have a highdegree of redundancy, in that the entiretuple is duplicated whenever the value ofany attribute changes, analysis reveals thatthis scheme consumes less space than at-tribute versioning when the database is notvolatile.8

For the prototype, the parser of Ingreswas modified to accept TQuel statementsand generate an extended syntax tree withsubtrees for valid, when, and as of clauses.Some of the query evaluation moduleswere changed to handle the newly definednode types and the implicit temporal at-tributes. Functions to handle the temporaloperators begin of, end of, precede, over-

lap, extend, and as ofwere added in the in-terpreter. The system relation was modi-fied to support the various combinationsof implicit temporal attributes accordingto the type of relation as specified by itscreate statement, an example of which ap-peared earlier. The temporal attribute hasa distinct type, so that input and output of

time values can be done in human readableform by automatically converting to andfrom the internal representation. Variousformats of date or time are accepted for in-put, and resolutions ranging from secondto year are selectable for output. The copystatement was also modified to supportbatch input and output of relations havingtemporal attributes.The resulting prototype supports all the

TQuel statements, including the aug-mented create, append, delete, replace,and retrieve statements. The valid, when,and as of clauses are fully supported. Allthree kinds oftime are supported, as are all

four types of relations. Proposed exten-sions to the language, including indeter-minacy and aggregate functions, are notyet supported.To evaluate the performance of the

prototype, we ran a benchmark with a setof queries on the four types of databasesusing various access methods. We deter-mined the fixed portion, the variable por-tion, and the growth rate of the disk access

cost for various types of queries, as the

Septemnber 1986

Snapshot:Nam RankMerrie Associate Professor

Rollback:Nam Rark (Transaction Time)Merrie Instructor (September 1973)

............................. ...................................

Merrie Full Professor (December 1973)

Merrie Assistant Professor (February 1974)

Merrie Associate Professor (December 1978)

Historical:Valid Time) Nare Frk

epem r 1973) errie InstructorDecember 1973) Merrie Assistant ProfessorJune 1978) Merrie Associate Professor

Temporal:

Valid Time) Name Rrt (Transaction Time)September 1 973) -Merrie Instructor (September 1973)

............................... ........... ............................ ...................................

(September 1973) Merrie Instructor (December 1973)(December 1973) Merrie Full Professor

(September 1973) Merrie Instructor (February 1974)(December 1973) Merrie Assistant Professor

(September 1973) Merrie Instructor (December 1978)December 1973 Merrie Assistant ProfessoruJne 1978) Merrie Associate Professor

41

number of versions in each database in-creased using a series of replace opera-tions.9 Performance degraded rapidly forboth temporal and nontemporal queries,as expected for conventional accessmethods such as hashing and indexed se-quential access. We are investigating newaccess methods addressing this problem toenhance the performance.

WA I hile fifteen years of researchhave focused on formalizingand implementing snapshot

databases, only a few researchers haverecently studied the formalization ofhistorical databases and the implementa-tion of rollback databases. Little has beenpublished on formalizing rollback or tem-poral databases, or on implementing his-torical or temporal databases. The specialopportunities promised by temporaldatabases are, at this time, matched by thechallenges in supporting them.

AcknowledgmentsThis work was supported by NSF grant

DCR-8402339. Richard Snodgrass' workwas also supported by an IBM FacultyDevelopment Award.

ReferencesI. A. Bolour et al., "The Role of Time in In-

formation Processing: A Survey," SigArtNewsletter, Vol. 80, Apr. 1982, pp. 28-48.

2. A. Hoagland, "Information StorageTechnology: A Look at the Future,"Computer, Vol. 18, No. 7, July 1985, pp.60-67.

3. G. Copeland, "What If Mass StorageWere Free?," Computer, Vol. 15, No. 7,July 1982, pp. 27-35.

4. G. Weiderhold, "Databases," Comput-er, Vol. 17, No. 10, Oct. 1984, pp.211-223.

5. R. Snodgrass and 1. Ahn, "A Taxonomyof Time in Databases," Proc. Int'l Conf.Management of Data, ACM SIGMOD,Austin, TX, May 1985, pp. 236-246.

6. G. D. Held, M. Stonebraker, and E.Wong, "Ingres-A Relational Data BaseManagement System," Proc. 1975 Nat'lComputer Conf., Vol. 44, 1975, pp.409-416.

7. R. Snodgrass, "The Temporal QueryLanguage TQuel," ACM Trans. Data-base Systems, to appear 1986.

8. 1. Ahn, "Towards an Implementation ofDatabase Management Systems withTemporal Support," Second Int'l Conf.

Data Engineering, Los Angeles, CA, Feb.1986, pp. 374-381.

9. 1. Ahn and R. Snodgrass, "PerformanceEvaluation of a Temporal Database Man-agement System," Proc. Int'l Conf.Management of Data, ACM SIGMOD,Washington DC, May 1986, pp. 96-107.

Richard Snodgrass is currently an assistant pro-fessor at the Department of Computer Science,University of North Carolina, Chapel Hill. Hisresearch interests include temporal databases,programming environments, and softwaremonitoring. He is the director of the SoftLabproject, which is concerned with pragmaticissues in the implementation of programmingenvironments, database management systems,and operating systems.

Snodgrass received the BA degree in physicsfrom Carleton College, Northfield, MN, in1977 and the PhD degree in computer sciencefrom Carnegie-Mellon University, Pittsburgh,PA, in 1982.

llsoo Ahn is a member of the technical staff atBell Laboratories, Columbus, Ohio. His re-search interests include temporal databases,physical database design, performance anal-ysis, distributed systems and computer net-works.Ahn worked as an engineer for telephone

switching systems and as an MVS system pro-grammer in the Korea TelecommunicationsCo. after receiving an MSEE from the KoreaAdvanced Institute of Science in 1977. Hereceived a PhD in computer science from theUniversity of North Carolina at Chapel Hill in1986.

Readers may write to Snodgrass at the Uni-versity of North Carolina at Chapel Hill, Dept.of Computer Science, Chapel Hill, NC 27514.

COMPUTERReader Service Number 4