As outlined in the previous two sections, a temporal database can be regarded as an enhancement of a conventional database: it `only' sets the data into a context of time, i.e. it adds a time dimension. In a relational database environment, a relation can be considered as a table with rows representing individual tuples and columns holding the respective attribute values. Over time, such a table is updated, i.e. new rows are inserted, some rows are deleted and some attribute values might be modified. This means that the data in the table changes over time. If a copy of the table was taken each time before it is updated and if the date of the copy was added to all rows we could actually follow the evolution of the table. And in fact, this is what many users require: just recall the share-prices-example in section 2.1. In contrast, in many databases, one would only keep the current copy of a table or - as it is frequently called - the current snapshot . They are therefore referred to as snapshot databases .
Brooks was the first person to elaborate this comparison by regarding the series of snapshots / table copies as a time cube [Brooks, 1956]: a snapshot is then a time slice of such a cube. See figure 2.4. In terms of this analogy, a conventional database always holds one slice whereas a temporal database holds the entire cube. Without going into implementational details, one can imagine that - whenever an update occurs - a conventional database physically updates, i.e. throws old values away and stores the new ones, whereas a temporal database is updated logically, i.e. it marks the old and new values with timestamps that indicate to which snapshot the actually belong: the current or a previous, historic one. This is also called the concept of physical vs. logical deletion .
What we have described so far is a time dimension that represented the time dimension from the DBMS's point of view, i.e. the time when (update) transactions in the database take place. This type of time is therefore called transaction time . A transaction timestamp indicates the time when the associated tuple is current in the database. Naturally, the most recent value of transaction time is always the current moment, e.g. represented as now in figure 2.1. In terms of the time cube, this means that the current snapshot is the front one if time runs from the background to the foreground as in figure 2.4.
There is, however, a second notion of time which is called valid time . Whereas transaction time is restricted to the present and the past, valid time extends to the future as well. Imagine a hotel reservation system that stores room bookings in a table. For the staff that run the hotel, it is not really important to know when a room was booked, i.e. when the booking transaction took place (transaction time), but for which time a room is booked (valid time) which naturally must cover the future. Additionally, past bookings might be stored as well, as the management might want to analyse this information in order to analyse customer characteristics.
In the case of valid time the current snapshot - if it is supposed to be the snapshot giving, for example, the current hotel room allocation - might be a slice in the time cube such as the one shown in figure 2.4. As valid time extends to the future it is not necessarily the front one, however.
Whereas a snapshot relation can be considered as a slice of a transaction time cube, a similar connection cannot be drawn for a valid time cube. The contents of a valid time relation that is currently held in the database cannot be regarded as slice. It might be the entire data represented by the cube or parts of it. Remember the example of the hotel reservation system: it suggests that many conventional databases would store a significant amount of the data represented by the valid time cube. This means that the latter are actually valid time databases which treat valid time just as any other attribute. This underlines again that temporal DBMSs emphasise and efficiently support the time dimension(s) but do not extend the expressive power of conventional databases. This is the fact on which many critics build their argument. There is, however, no doubt about the existence and widespread usage of and demand for temporal databases.
