Managing Temporal Data

Managing Temporal Data

Abdullah Uz Tansel (Baruch College – CUNY, USA)
DOI: 10.4018/978-1-60566-242-8.ch004
OnDemand PDF Download:
No Current Special Offers


In general, databases store current data. However,the capability to maintain temporal data is a crucial requirement for many organizations and provides the base for organizational intelligence. A temporal database maintains time-varying data, that is, past, present, and future data. In this chapter, we focus on the relational data model and address the subtle issues in modeling and designing temporal databases. A common approach to handle temporal data within the traditional relational databases is the addition of time columns to a relation. Though this appears to be a simple and intuitive solution, it does not address many subtle issues peculiar to temporal data, that is, comparing database states at two different time points, capturing the periods for concurrent events and accessing times beyond these periods, handling multi-valued attributes, coalescing and restructuring temporal data, and so forth, [Gadia 1988, Tansel and Tin 1997]. There is a growing interest in temporal databases. A first book dedicated to temporal databases [Tansel at al 1993] followed by others addressing issues in handling time-varying data [Betini, Jajodia and Wang 1988, Date, Darwen and Lorentzos 2002, Snodgrass 1999].
Chapter Preview

Time In Databases

The set T denotes time values and it is a total order under ‘≤’ relationship. Because of its simplicity, we will use natural numbers to represent time {0, 1 ... now}. The symbol 0 is the relative origin of time and now is a special symbol that represents the current time. Now advances according to the time granularity used. There are different time granularities, such as seconds, minutes, hours, days, month, year, etc. (for a formal definition see [Betini, Jajodia and Wang 1988]).

A subset of T is called a temporal set. A temporal set that contains consecutive time points {t1, t2... tn} is represented either as a closed interval [t1, tn] or as a half open interval [t1, tn+1). A temporal element [Gadia 1988] is a temporal set that is represented by the disjoint maximal intervals corresponding to its subsets having consecutive time points. Temporal sets, intervals, and temporal elements can be used as time stamps for modeling temporal data and are essential constructs in temporal query languages. Temporal sets and temporal elements are closed under set theoretic operations whereas intervals are not. However, intervals are easier to implement. Time intervals, hence temporal elements and temporal sets, can be compared. The possible predicates are before, after, meet, during, etc. [Allen 1983]. An interval or a temporal set (element) that includes now expends in its duration. Other symbols such as forever or until changed are also proposed as alternatives to the symbol now for easier handling of future data.

There are various aspects of time in databases [Snodgrass 1987]. Valid time indicates when a data value becomes effective. It is also known as logical or intrinsic time. On the other hand, the transaction time (or physical time) indicates when a value is recorded in the database. User defined time is application specific and is an attribute whose domain is time. Temporal databases are in general append-only that is, new data values are added to the database instead of replacing the old values. A database that supports valid time keeps historical values and is called a valid time (historical) database. A rollback database supports transaction time and can roll the database back to any time. Valid time and transaction time are orthogonal. Furthermore, a bitemporal database that supports both valid time and transaction time is capable of handling retroactive and post-active changes on temporal data. In the literature, the term temporal database is generically used to mean a database with some kind of time support.

In this chapter we focus our discussion on the valid time aspect of temporal data in relational databases. However, our discussion can easily be extended to databases that support transaction time or both as well.

Complete Chapter List

Search this Book: