For illustration, consider the following short biography of a fictional man, John Doe: :John Doe was born on 1975-04-03 in the Kids Hospital of Medicine County, as son of Jack Doe and Jane Doe who lived in Smallville. Jack Doe proudly registered the birth of his first-born on April 4, 1975 at the Smallville City Hall. John grew up as a joyful boy, turned out to be a brilliant student and graduated with honors in 1993. After graduation, he went to live on his own in Bigtown. Although he moved out on 1994-08-26, he forgot to register the change of address officially. It was only at the turn of the seasons that his mother reminded him that he had to register, which he did a few days later on 1994-12-27. Although John had a promising future, his story ends tragically. John Doe was accidentally hit by a truck on 2001-04-01. The coroner reported his date of death on the very same day.
Using a non-temporal database To store the life of John Doe in a current (non-temporal) database we use a table . (In order to simplify, name is defined as the
primary key of person.) John's father officially reported his birth on 1975-04-04. On this date a Smallville official inserted the following entry in the database: Person(John Doe, Smallville). Note that the date itself is not stored in the database. After graduation, John moves out, but forgets to register his new address. John's entry in the database is not changed until 1994-12-27, when he finally reports it. A Bigtown official updates his address in the database. The person table now contains Person(John Doe, Bigtown). Note that the information of John living in Smallville has been overwritten, so it is no longer possible to retrieve that information from the database. An official accessing the database on 1994-12-28, would be told that John lives in Bigtown. More technically: if a database administrator ran the query on 1994-12-26, the result would be Smallville. Running the same query 2 days later would result in Bigtown. Until his death, the database would state that he lived in Bigtown. On 2001-04-01, the coroner deletes the John Doe entry from the database. After this, running the above query would return no result at all.
Using a single axis: valid time or transaction time Valid time is the time for which a fact is true in the real world. A valid time period may be in the past, span the current time, or occur in the future. For the example above, to record valid time, the person table has two fields added, valid_from and valid_to. These specify the period when a person's address is valid in the real world. On 1975-04-04, John's father registered his son's birth. An official then inserts a new entry into the database stating that John lives in Smallville from April 3. Note that although the data was inserted on the fourth, the database states that the information is valid since the third. The official does not yet know if or when John will move to another place, so the valid_to field is set to
infinity (∞). The entry in the database is: On 1994-12-27, John reports his new address in Bigtown where he has been living since 1994-08-26. A new database entry is made to record this fact: The original entry Person (John Doe, Smallville, 1975-04-03, ∞) is not deleted, but has the valid_to attribute updated to reflect that it is now known that John stopped living in Smallville on 1994-08-26. The database now contains two entries for John Doe: When John dies his current entry in the database is updated stating that John does not live in Bigtown any longer. The database now looks like this:
Using two axes: valid time and transaction time Transaction time records the time period during which a database entry is accepted as correct. This enables queries that show the state of the database at a given time. Transaction time periods can only occur in the past or up to the current time. In a transaction time table, records are never deleted. Only new records can be inserted, and existing ones updated by setting their transaction end time to show that they are no longer current. To enable transaction time in the example above, two more fields are added to the Person table: transaction_from and transaction_to. Here, transaction_from is the time a transaction was made, and transaction_to is the time that the transaction was superseded (which may be infinity if it has not yet been superseded). This makes the table into a
bitemporal table. What happens if the person's address as stored in the database is incorrect? Suppose an official accidentally entered the wrong address or date? Or, suppose the person lied about their address for some reason. Upon discovery of the error, the officials update the database to correct the information recorded. For example, from 1995-06-01 to 2000-09-03, John Doe moved to Beachy. But to avoid paying Beachy's exorbitant residence tax, he never reported it to the authorities. Later during a tax investigation, it is discovered on 2-Feb-2001 that he was in fact in Beachy during those dates. To record this fact, the existing entry about John living in Bigtown must be split into two separate records, and a new record inserted recording his residence in Beachy. The database would then appear as follows: However, this leaves no record that the database ever claimed that he lived in Bigtown during 1995-06-01 to 2000-09-03. This might be important to know for auditing reasons, or to use as evidence in the official's tax investigation. Transaction time allows capturing this changing knowledge in the database, since entries are never directly modified or deleted. Instead, each entry records when it was entered and when it was superseded (or logically deleted). The database contents then look like this: The database records not only what happened in the real world, but also what was officially recorded at different times.
Using three axes: valid time, decision time, and transaction time Decision time is an alternative to the transaction time period for recording the time at which a database entry may be accepted as correct. This enables queries that show the officially recognized facts at a given time, even if there was a delay in committing those facts to the database. Support for decision time preserves the entire history and prevents the loss of information during updates. Decision time periods can only occur in the past or up to the transaction time. As in a transaction time table, records are never deleted. Only new records can be inserted, and existing ones updated by setting their decision end time to show that they are no longer current. To enable decision time, two more fields are added to a database table: decision_from and decision_to. Here, decision_from is the time a decision was made, and decision_to is the time that the decision was superseded (which may be infinity if it has not yet been superseded). When combined with transaction time, this makes the table into a
tritemporal table. The following is a list of real events that occurred between the 1964 and 1976
United States presidential elections: In this example, a constant 7-day delay is assumed between the decision time and the transaction time when the data is committed to the database. Given those conditions, the database would have contained the following information after the election in 1976: Given the 7-day delayed table above, the question "who was president and vice president for the valid time of 1977-01-01" (which given the 7-day delay could provide data for 1976-12-25) would be: • Nixon/Agnew when using a decision time and transaction time of 1972-11-14 • Nixon/(Vacant) when using a decision time and transaction time of 1973-10-17 • Nixon/Ford when using a decision time and transaction time of 1974-08-08 • Ford/(Vacant) when using a decision time of 1974-08-08 and transaction time of current • Ford/Rockefeller when using a decision time and transaction time of current ==Bitemporal modelling==