What are Temporal Databases?
Non-Temporal Databases
Commercial database management systems (DBMS) such as Oracle, Sybase, Informix and O2 allow the storage of huge amounts of data. This data is usually considered to be valid now. Past or future data is not stored. Past data refers to data which was stored in the database at an earlier time instant and which might has been modified or deleted in the meantime. Past data usually is overwritten with new (updated) data. Future data refers to data which is considered to be valid at a future time instant (but not now).A DBMS stores the data in a well-defined format. A relational DBMS, for example, stores data in tables (also called relations). Thus, a relational database actually contains a set of tables. Each table contains rows (tuples) and columns (attributes). A row contains data about a specific entity, for example, an employee. Each column specifies a certain property of these entities, for example, the employee's name, salary etc. The following table stores data about employees:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
15500 |
Object-oriented DBMS store data about entities in objects. So each employee is actually an object. The type of an object specifies the properties the object has. An employee object thus has properties such as a name, a salary etc. Sets of objects of the same type are called collections. Thus - in an object-oriented DBMS - a database contains a set of collections.
Temporal Databases
Temporal data strored in a temporal database is different from the data stored in non-temporal database in that a time period attached to the data expresses when it was valid or stored in the database. As mentioned above, conventional databases consider the data stored in it to be valid at time instant now, they do not keep track of past or future database states. By attaching a time period to the data, it becomes possible to store different database states.A first step towards a temporal database thus is to timestamp the data. This allows the distinction of different database states. One approach is that a temporal database may timestamp entities with time periods. Another approach is the timestamping of the property values of the entities. In the relational data model, tuples are timestamped, where as in object-oriented data models, objects and/or attribute values may be timestamped.
What time period do we store in these timestamps? As we mentioned already, there are mainly two different notions of time which are relevant for temporal databases. One is called the valid time, the other one is the transaction time. Valid time denotes the time period during which a fact is true with respect to the real world. Transaction time is the time period during which a fact is stored in the database. Note that these two time periods do not have to be the same for a single fact. Imagine that we come up with a temporal database storing data about the 18th century. The valid time of these facts is somewhere between 1700 and 1799, where as the transaction time starts when we insert the facts into the database, for example, January 21, 1998.
Assume we would like to store data about our employees with respect to the real world. Then, the following table could result:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The above valid-time table stores the history of the employees with respect to the real world. The attributes ValidTimeStart and ValidTimeEnd actually represent a time interval which is closed at its lower and open at its upper bound. Thus, we see that during the time period [1985 - 1990), employee John was working in the research department, having a salary of 11000. Then he changed to the sales department, still earning 11000. In 1993, he got a salary raise to 12000. The upper bound INF denotes that the tuple is valid until further notice. Note that it is now possible to store information about past states. We see that Paul was employed from 1988 until 1995. In the corresponding non-temporal table, this information was (physically) deleted when Paul left the company.
Different Forms of Temporal Databases
The two different notions of time - valid time and transaction time - allow the distinction of different forms of temporal databases. A historical database stores data with respect to valid time, a rollback database stores data with respect to transaction time. A bitemporal database stores data with respect to both valid time and transaction time.As we mentioned above, commercial DBMS are said to store only a single state of the real world, usually the most recent state. Such databases usually are called snapshot databases. A snapshot database in the context of valid time and transaction time is depicted in the following picture:
On the other hand, a bitemporal DBMS such as TimeDB stores the history of data with respect to both valid time and transaction time. Note that the history of when data was stored in the database (transaction time) is limited to past and present database states, since it is managed by the system directly which does not know anything about future states.
A table in the bitemporal relational DBMS TimeDB may either be a snapshot table (storing only current data), a valid-time table (storing when the data is valid wrt. the real world), a transaction-time table (storing when the data was recorded in the database) or a bitemporal table (storing both valid time and transaction time). An extended version of SQL allows to specify which kind of table is needed when the table is created. Existing tables may also be altered (schema versioning). Additionally, it supports temporal queries, temporal modification statements and temporal constraints.
The states stored in a bitemporal database are sketched in the picture below. Of course, a temporal DBMS such as TimeDB does not store each database state separately as depicted in the picture below. It stores valid time and/or transaction time for each tuple, as described above.
Back to overview