View source for Temporal database

{{short description|Database that stores information relating to past, present and future time}}
A '''temporal database''' stores data relating to time instances. It offers temporal data types and stores information relating to past, present and future time.
Temporal databases can be uni-temporal, bi-temporal or tri-temporal.

More specifically the temporal aspects usually include [[valid time]], [[transaction time]] and/or [[decision time]].

* '''Valid time''' is the time period during or event time at which a fact is true in the real world.
* '''Transaction time''' is the time at which a fact was recorded in the database.
* '''Decision time''' is the time at which the decision was made about the fact. Used to keep a history of decisions about valid times.

==Types==
===Uni-temporal===
A uni-temporal database has one axis of time, either the validity range or the system time range.

===Bi-temporal===
{{main|Bitemporal modeling}}
A bi-temporal database has two axes of time:
* Valid time
* Transaction time or decision time

===Tri-temporal===
{{see|Decision time}}

A tri-temporal database has three axes of time:
* Valid time
* Transaction time 
* Decision time

This approach introduces additional complexities.

Temporal databases are in contrast to [[current database]]s (not to be confused with currently available databases), which store only facts which are believed to be true at the current time.

==Features==
Temporal databases support managing and accessing temporal data by providing one or more of the following features:<ref name="SQL2011"/><ref name="DB2"/>

* A time period datatype, including the ability to represent time periods with no end (infinity or forever)
* The ability to define valid and transaction time period attributes and bitemporal relations
* System-maintained transaction time
* Temporal [[primary keys]], including non-overlapping period constraints
* Temporal constraints, including non-overlapping uniqueness and [[referential integrity]]
* Update and deletion of temporal records with automatic splitting and coalescing of time periods
* Temporal queries at current time, time points in the past or future, or over durations
* Predicates for querying time periods, often based on [[Allen's interval algebra#Relations|Allen's interval relations]]

==History==
With the development of [[SQL]] and its attendant use in real-life applications, database users realized that when they added date columns to key fields, some issues arose. For example, if a table has a primary key and some attributes, adding a date to the primary key to track historical changes can lead to creation of more rows than intended. Deletes must also be handled differently when rows are tracked in this way. In 1992, this issue was recognized but standard database theory was not yet up to resolving this issue, and neither was the then-newly formalized [[SQL-92|SQL-92 standard]].

[[Richard T. Snodgrass|Richard Snodgrass]] proposed in 1992 that temporal extensions to SQL be developed by the temporal database community. In response to this proposal, a committee was formed to design extensions to the 1992 edition of the SQL standard (ANSI X3.135.-1992 and ISO/IEC 9075:1992); those extensions, known as TSQL2, were developed during 1993 by this committee.<ref name="snodgrass9">Snodgrass, 1999, p. 9</ref> In late 1993, Snodgrass presented this work to the group responsible for the American National Standard for Database Language SQL, ANSI Technical Committee X3H2 (now known as NCITS H2). The preliminary language specification appeared in the March 1994 ACM SIGMOD Record. Based on responses to that specification, changes were made to the language, and the definitive version of the TSQL2 Language Specification was published in September, 1994<ref>{{cite web | url = http://www.cs.arizona.edu/~rts/tsql2.html | title = TSQL2 Temporal Query Language | work = www.cs.arizona.edu | author = Richard T. Snodgrass | author-link = Richard T. Snodgrass | publisher = Computer Science Department of the University of Arizona | access-date = 14 July 2009}}</ref>

An attempt was made to incorporate parts of TSQL2 into the new SQL standard [[SQL:1999]], called SQL3. Parts of TSQL2 were included in a new substandard of SQL3, ISO/IEC 9075-7, called SQL/Temporal.<ref name="snodgrass9"/> The TSQL2 approach was heavily criticized by [[Chris Date]] and [[Hugh Darwen]].<ref>Hugh Darwen, C.J. Date, “[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.116.7598 An overview and Analysis of Proposals Based on the TSQL2 Approach]”, In ''Date on Database: Writings 2000-2006'', C.J. Date, Apress, 2006, pp. 481-514</ref> The ISO project responsible for temporal support was canceled near the end of 2001.

As of December 2011, ISO/IEC 9075, Database Language [[SQL:2011]] Part 2: SQL/Foundation included clauses in table definitions to define "application-time period tables" ([[valid time]] tables), "system-versioned tables" ([[transaction time]] tables) and "system-versioned application-time period tables" ([[bitemporal]] tables). A substantive difference between the TSQL2 proposal and what was adopted in SQL:2011 is that there are no hidden columns in the SQL:2011 treatment, nor does it have a new data type for intervals; instead two columns with [[datestamp]]s (DS) or [[date-timestamp]]s (DTS) can be bound together using a <code>PERIOD FOR</code> declaration. Another difference is replacement of the controversial (prefix) statement modifiers from TSQL2 with a set of temporal predicates.<ref name="SQL2011"/>

Other features of [[SQL:2011]] standard related to temporal databases are automatic time period splitting, temporal primary keys, temporal referential integrity, temporal predicates with [[Allen's interval algebra]] and time-sliced and sequenced queries.

==Example==
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 {{code|person (name, address)}}. (In order to simplify, <code>name</code> is defined as the [[primary key]] of <code>person</code>.)

John's father officially reported his birth on 1975-04-04. On this date a Smallville official inserted the following entry in the database: <code>Person(John Doe, Smallville)</code>.
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 <code>person</code> table now contains <code>Person(John Doe, Bigtown)</code>. 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 {{code|1=SELECT ADDRESS FROM PERSON WHERE NAME='John Doe'|2=sql}} on 1994-12-26, the result would be <code>Smallville</code>. Running the same query 2 days later would result in <code>Bigtown</code>.

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.

{| class="wikitable"
|-
!Date!!Real world event!!Database action!!What the database shows
|-
|style="text-align:right;"|{{nowrap|1975-04-03}}||John is born||{{CNone|Nothing}}||There is no person called John Doe
|-
|style="text-align:right;"|{{nowrap|1975-04-04}}||John's father officially reports John's birth||Inserted:Person(John Doe, Smallville)||John Doe lives in Smallville
|-
|style="text-align:right;"|{{nowrap|1994-08-26}}||After graduation, John moves to Bigtown, but forgets to register his new address||{{CNone|Nothing}}||John Doe lives in Smallville
|-
|style="text-align:right;"|{{nowrap|1994-12-26}}||Nothing||{{CNone|Nothing}}||John Doe lives in Smallville
|-
|style="text-align:right;"|{{nowrap|1994-12-27}}||John registers his new address||Updated:Person(John Doe, Bigtown)||John Doe lives in Bigtown
|-
|style="text-align:right;"|{{nowrap|2001-04-01}}||John dies||Deleted:Person(John Doe)||There is no person called John Doe
|}

===Using a single axis: valid time or transaction time===
{{Main article|Valid 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 <code>person</code> table has two fields added, <code>valid_from</code> and <code>valid_to</code>. 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 <code>valid_to</code> field is set to [[infinity]] (∞). The entry in the database is:
{| class="wikitable"
!Name
!City
!Valid from
!Valid to
|-
|John Doe
|Smallville
|1975-04-03
|∞
|}
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:
{| class="wikitable"
!Name
!City
!Valid from
!Valid to
|-
|John Doe
|Bigtown
|1994-08-26
|∞
|}
The original entry <code>Person (John Doe, Smallville, 1975-04-03, ∞)</code> is not deleted, but has the <code>valid_to</code> 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:
{| class="wikitable"
!Name
!City
!Valid from
!Valid to
|-
|John Doe
|Smallville
|1975-04-03
|1994-08-26
|-
|John Doe
|Bigtown
|1994-08-26
|∞
|}
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:
{| class="wikitable"
!Name
!City
!Valid from
!Valid to
|-
|John Doe
|Smallville
|1975-04-03
|1994-08-26
|-
|John Doe
|Bigtown
|1994-08-26
|2001-04-01
|}

===Using two axes: valid time and transaction time===
{{Main article|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: <code>transaction_from</code> and <code>transaction_to</code>. Here, <code>transaction_from</code> is the time a transaction was made, and <code>transaction_to</code> 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_relations|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:
{| class="wikitable"
!Name
!City
!Valid from
!Valid to
|-
|John Doe
|Smallville
|1975-04-03
|1994-08-26
|-
|John Doe
|Bigtown
|1994-08-26
|1995-06-01
|-
|John Doe
|Beachy
|1995-06-01
|2000-09-03
|-
|John Doe
|Bigtown
|2000-09-03
|2001-04-01
|}
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:
{| class="wikitable"
!Name
!City
!Valid from
!Valid to
!Entered
!Superseded
|-
|John Doe
|Smallville
|1975-04-03
|∞
|1975-04-04
|1994-12-27
|-
|John Doe
|Smallville
|1975-04-03
|1994-08-26
|1994-12-27
|∞
|-
|John Doe
|Bigtown
|1994-08-26
|∞
|1994-12-27
|2001-02-02
|-
|John Doe
|Bigtown
|1994-08-26
|1995-06-01
|2001-02-02
|∞
|-
|John Doe
|Beachy
|1995-06-01
|2000-09-03
|2001-02-02
|∞
|-
|John Doe
|Bigtown
|2000-09-03
|∞
|2001-02-02
|2001-04-01
|-
|John Doe
|Bigtown
|2000-09-03
|2001-04-01
|2001-04-01
|∞
|}
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.<ref>Mario A. Nascimento, Margaret H. Eich, “[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.8187 Decision Time in Temporal Databases]”, In ''Proceedings of the Second International Workshop on Temporal Representation and Reasoning'', 1995, pp. 157-162</ref>

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: <code>decision_from</code> and <code>decision_to</code>. Here, <code>decision_from</code> is the time a decision was made, and <code>decision_to</code> 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_relations|tritemporal table]].
The following is a list of real events that occurred between the 1964 and 1976 [[United States presidential election]]s:
{| class="wikitable" 
!Date
!Decision maker
!Real world event
|-
|1964-11-03
|[[United States Electoral College|Electoral College]]
|[[1964 United States presidential election|Election of 1964]]
|-
|1968-11-05
|Electoral College
|[[1968 United States presidential election|Election of 1968]]
|-
|1972-11-07
|Electoral College
|[[1972 United States presidential election|Election of 1972]]
|-
|1973-10-10
|[[Spiro Agnew]]
|[[Spiro Agnew#Criminal investigation and resignation|Agnew resigns]]
|-
|1973-10-12
|[[Richard Nixon]]
|[[Gerald Ford#Vice presidency (1973–1974)|Nixon nominates Ford]]
|-
|1973-12-06
|[[United States Congress|Congress]]
|Congress confirms Ford
|-
|1974-08-09
|Richard Nixon
|[[Richard Nixon#Resignation|Nixon resigns]]
|-
|1974-08-20
|[[Gerald Ford]]
|[[Nelson Rockefeller#Vice President of the United States (1974–1977)|Ford nominates Rockefeller]]
|-
|1974-12-19
|Congress
|Congress confirms Rockefeller
|-
|1976-11-02
|Electoral College
|[[1976 United States presidential election|Election of 1976]]
|}

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:
{| class="wikitable"
| colspan="2" |
! colspan="2" |Valid
! colspan="2" |Decision
! colspan="2" |Transaction
|-
!President
!Vice
!From
!To
!From
!To
!From
!To
|- style="border-bottom:double"
|Johnson
|Humphrey
|1965-01-20
| style="color:red" |1969-01-20
|1964-11-03
|∞
|1964-11-10
|∞
|- style="border-bottom:double"
|Nixon
|Agnew
| style="color:red" |1969-01-20
| style="color:orange" |1973-01-20
|1968-11-05
|∞
|1968-11-12
|∞
|- style="border-bottom:double"
|Nixon
|Agnew
| style="color:orange" |1973-01-20
|1977-01-20
|1972-11-07
|∞
|1972-11-14
| style="color:red" |1973-10-17
|-
|Nixon
|Agnew
| style="color:orange" |1973-01-20
|1977-01-20
|1972-11-07
| style="color:red" |1973-10-10
| style="color:red" |1973-10-17
|∞
|-
|Nixon
|Agnew
| style="color:orange" |1973-01-20
| style="color:lime" |1973-10-10
| style="color:red" |1973-10-10
|∞
|1973-10-17
|∞
|- style="border-bottom:double"
|Nixon
|(Vacant)
| style="color:lime" |1973-10-10
|1977-01-20
|1973-10-10
|∞
|1973-10-17
| style="color:orange" |1973-12-13
|- style="border-bottom:double"
|Nixon
|Ford
|∞
|1977-01-20
|1973-10-12
|∞
|1973-10-19
| style="color:lime" |1973-12-13
|-
|Nixon
|(Vacant)
| style="color:lime" |1973-10-10
|1977-01-20
|1973-10-10
| style="color:orange" |1973-12-06
| style="color:orange" |1973-12-13
|∞
|-
|Nixon
|(Vacant)
| style="color:lime" |1973-10-10
| style="color:green" |1973-12-06
| style="color:orange" |1973-12-06
|∞
|1973-12-13
|∞
|-
|Nixon
|Ford
|∞
|1977-01-20
|1973-10-12
| style="color:lime" |1973-12-06
| style="color:lime" |1973-12-13
|∞
|- style="border-bottom:double"
|Nixon
|Ford
| style="color:green" |1973-12-06
|1977-01-20
| style="color:lime" |1973-12-06
|∞
|1973-12-13
| style="color:green" |1974-08-15
|-
|Nixon
|Ford
| style="color:green" |1973-12-06
|1977-01-20
|1973-12-06
| style="color:green" |1974-08-08
| style="color:green" |1974-08-15
|∞
|-
|Nixon
|Ford
| style="color:green" |1973-12-06
| style="color:blue" |1974-08-09
| style="color:green" |1974-10-08
|∞
|1974-08-15
|∞
|- style="border-bottom:double"
|Ford
|(Vacant)
| style="color:blue" |1974-08-09
|1977-01-20
|1974-10-08
|∞
|1974-08-15
| style="color:blue" |1974-12-26
|- style="border-bottom:double"
|Ford
|Rockefeller
|∞
|1977-01-20
|1974-10-20
|∞
|1974-08-27
| style="color:purple" |1974-12-26
|-
|Ford
|(Vacant)
| style="color:blue" |1974-08-09
|1977-01-20
|1974-10-08
| style="color:blue" |1974-12-19
| style="color:blue" |1974-12-26
|∞
|-
|Ford
|(Vacant)
| style="color:blue" |1974-08-09
| style="color:purple" |1974-12-19
| style="color:blue" |1974-12-19
|∞
|1974-12-26
|∞
|-
|Ford
|Rockefeller
|∞
|1977-01-20
|1974-08-20
| style="color:purple" |1974-12-19
| style="color:purple" |1974-12-26
|∞
|- style="border-bottom:double"
|Ford
|Rockefeller
| style="color:purple" |1974-12-19
|1977-01-20
| style="color:purple" |1974-12-19
|∞
|1974-12-26
|∞
|-
|Carter
|Mondale
|1977-01-20
|1981-01-20
|1976-11-02
|∞
|1976-11-09
|∞
|}
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==
{{Main article|Bitemporal modeling}}
A [[bitemporal model]] contains both valid and transaction time. This provides both ''historical'' and ''rollback'' information. Historical information (e.g.: "Where did John live in 1992?") is provided by the valid time. Rollback (e.g.: "In 1992, where did the database believe John lived?") is provided by the transaction time. The answers to these example questions may not be the same{{snd}} the database may have been altered since 1992, causing the queries to produce different results.

The valid time and transaction time do not have to be the same for a single fact. For example, consider a temporal database storing data about the 18th century. The valid time of these facts is somewhere between 1701 and 1800. The transaction time would show when the facts were inserted into the database (for example 1998-01-21).

==Schema evolution==
{{Main article|Schema evolution}}
A challenging issue is the support of temporal queries in a transaction time database under evolving [[database schema|schema]]. In order to achieve perfect archival quality it is of key importance to store the data under the schema version under which they first appeared. However, even the most simple temporal query rewriting the history of an attribute value would be required to be manually rewritten under each of the schema versions, potentially hundreds as in the case of [[MediaWiki]].<ref>[http://yellowstone.cs.ucla.edu/schema-evolution/index.php/Schema_Evolution_Benchmark Schema Evolution Benchmark - Schema Evolution]</ref> This process would be particularly taxing for users. A proposed solution is to provide automatic query rewriting,<ref name="curino-vldb-prima2008">{{cite conference| title=Managing and querying transaction-time databases under schema evolution |author1=Hyun J. Moon |author2=Carlo A. Curino |author3=Alin Deutsch |author4=C.-Y. Hou |author5=Carlo Zaniolo |name-list-style=amp | conference= Very Large Data Base VLDB | year = 2008 | url = http://yellowstone.cs.ucla.edu/schema-evolution/index.php/Prima }}</ref><ref name="curino-sigmod-aims2010">{{cite conference | title=Scalable Architecture and Query Optimization for Transaction-time DBs with Evolving Schemas |author1=Hyun J. Moon |author2=Carlo A. Curino |author3=Carlo Zaniolo |name-list-style=amp | conference= SIGMOD | year = 2010 | url = http://yellowstone.cs.ucla.edu/schema-evolution/index.php/AIMS }}</ref> although this is not part of SQL or similar standards.

Approaches to minimize the complexities of [[schema evolution]] are to: 
* Use a [[Semi-structured model|semi-structured database]]/[[NoSQL]] database which reduces the complexities of modeling attribute data but provides no features for handling multiple time axes.<ref name="mlw-talk-why-banks-need-bitemporal-2015">{{cite conference | title=Why Banks Care About Bitemporality | author=Anthony B. Coates | conference=MarkLogic World 2015 | year=2015 | url=https://www.youtube.com/watch?t=28&v=n29Gtit3lMU}}</ref>
* Use a database capable of storing both [[semi-structured data]] for attributes and [[structured data]] for time axes (e.g., [[Snowflake Inc.|SnowflakeDB]], [[PostgreSQL]])

==Implementations in notable products==
The following implementations provide temporal features in a relational database management system (RDBMS).

* [[MariaDB]] version 10.3.4 added support for [[SQL:2011]] standard as "System-Versioned Tables".<ref>{{Cite web|url=https://mariadb.com/kb/en/library/system-versioned-tables/|title = System-Versioned Tables}}</ref>
* [[Oracle Database]]{{snd}} Oracle Workspace Manager is a feature of Oracle Database which enables application developers and DBAs to manage current, proposed and historical versions of data in the same database.
* [[PostgreSQL]] version 9.2 added native ranged data types that are capable of implementing all of the features of the pgFoundry temporal contributed extension.<ref>{{cite web|last1=Paquier|first1=Michael|title=Postgres 9.2 highlight: range types |url=http://michael.otacoo.com/postgresql-2/postgres-9-2-highlight-range-types/ |date=1 November 2012 |archive-url=https://web.archive.org/web/20160423215529/http://michael.otacoo.com/postgresql-2/postgres-9-2-highlight-range-types/ |archive-date=2016-04-23 |work=Michael Paquier<!-- skip this, as name already in, change to website url, or not, as seems down..?--> - Open source developer based in Japan}}</ref><ref>{{cite web|last1=Katz|first1=Jonathan S.|title=Range Types: Your Life Will Never Be The Same|url=https://wiki.postgresql.org/images/7/73/Range-types-pgopen-2012.pdf|access-date=14 July 2014}}</ref> The PostgreSQL range types are supported by numerous native operators and functions.
* [[Teradata]] provides two products. Teradata version 13.10 and [[Teradata#Teradata Database 14|Teradata version 14]] have temporal features based on TSQL2<ref>Al-Kateb, Mohammed et al. "[https://openproceedings.org/2013/conf/edbt/Al-KatebGCBCP13.pdf Temporal Query Processing in Teradata]". EDBT/ICDT ’13 March 18–22, 2013, Genoa, Italy</ref> built into the database.
* [[IBM Db2]] version 10 added a feature called "time travel query"<ref name="DB2">{{cite web|title=A matter of time: Temporal data management in DB2 10 |last1=Saracco|first1=Cynthia M. |last2=Nicola|first2=Matthias |last3=Gandhi|first3=Lenisha |website=[[IBM]] |date=3 April 2012 |url=http://www.ibm.com/developerworks/data/library/techarticle/dm-1204db2temporaldata/|archive-url=https://web.archive.org/web/20121025082348/http://www.ibm.com/developerworks/data/library/techarticle/dm-1204db2temporaldata/|language=en|access-date=2020-10-27|archive-date=2012-10-25}}</ref> which is based on the temporal capabilities of the [[SQL:2011]] standard.<ref name="SQL2011">Kulkarni, Krishna, and Jan-Eike Michels. "[https://sigmodrecord.org/publications/sigmodRecord/1209/pdfs/07.industry.kulkarni.pdf Temporal features in SQL: 2011]". ACM SIGMOD Record 41.3 (2012): 34-43.</ref>
* [[Microsoft SQL Server]] introduced Temporal Tables as a feature for SQL Server 2016. The feature is described in a video on Microsoft's "Channel 9" web site.<ref name="SQLServerVideo">{{Citation|title=Temporal in SQL Server 2016|url=https://channel9.msdn.com/Shows/Data-Exposed/Temporal-in-SQL-Server-2016|language=en|access-date=2019-07-19}}</ref>

Non-relational, NoSQL database management systems that provide temporal features including the following:
* [[TerminusDB]] is a fully featured [[Open-source software|open source]] [[graph database]] that natively supports version control, time-travel queries and diffing functions. It has an immutable layer architecture based on [[delta encoding]] and [[succinct data structure]]s.<ref>{{Cite web|title=terminusdb/terminusdb-server|url=https://github.com/terminusdb/terminusdb-server|access-date=2020-09-04|website=GitHub|language=en}}</ref> 
* [[MarkLogic]] introduced bitemporal data support in version 8.0. Time stamps for Valid and System time are stored in JSON or XML documents.<ref>{{cite web|last1=Bridgwater|first1=Adrian|title=Data Is Good, 'Bidirectionalized Bitemporal' Data Is Better|website=[[Forbes]] |url=https://www.forbes.com/sites/adrianbridgwater/2014/11/24/data-is-good-bidirectionalized-bitemporal-data-is-better/#5424ff9b567b |date=24 November 2014}}</ref>
* [https://sirix.io SirixDB] stores snapshots of (currently) XML- and JSON-documents very efficiently in a binary format due to a novel versioning algorithm called sliding snapshot, which balances read-/write-performance and never creates write peaks. Time-travel queries are supported natively as well as diffing functions.
* [https://github.com/xtdb/xtdb XTDB] (formerly Crux) provides point-in-time bitemporal [[Datalog]] queries over transactions and documents ingested from semi-immutable Kafka logs. Documents are automatically indexed to create [[Entity–attribute–value model]] indexes without any requirement to define a schema. Transaction operations specify the effective Valid times. Transaction times are assigned by Kafka and enable horizontal scalability via consistent reads.
* [https://github.com/RecallGraph/RecallGraph RecallGraph] is a point-in-time, unitemporal (transaction time) graph database, built on top of [[ArangoDB]]. It runs on ArangoDB's [https://www.arangodb.com/why-arangodb/foxx/ Foxx Microservice] sub-system. It features [[Version Control System|VCS]]-like semantics in many parts of its interface, and is backed by a [[Atomicity (database systems)|transactional]] event tracker. Bitemporality is listed as one of the items in its [https://github.com/RecallGraph/RecallGraph#development-roadmap development roadmap].
* [https://docs.datomic.com/cloud/index.html Datomic] "is a distributed database that provides ACID transactions, flexible schema, [...] Datalog queries, complete data history, and SQL analytics support." For every change made to the data, it records the responsible transaction and the point in time when it happened.<ref>{{cite web|title=Datomic Data Model: Time Model|url=https://docs.datomic.com/cloud/whatis/data-model.html#time-model|date=29 April 2024}}</ref>

Temporal databases were one of the earliest forms of [[data version control]], and influenced the development of modern data versioning systems.<ref>{{Cite arXiv |last1=Bhardwaj |first1=Anant |last2=Bhattacherjee |first2=Souvik |last3=Chavan |first3=Amit |last4=Deshpande |first4=Amol |last5=Elmore |first5=Aaron J. |last6=Madden |first6=Samuel |last7=Parameswaran |first7=Aditya G. |date=2014-09-02 |title=DataHub: Collaborative Data Science & Dataset Version Management at Scale |class=cs.DB |eprint=1409.0798 }}</ref> 

===Alternatives===
[[File:Scd model.png|thumb|Example of [[slowly changing dimension]] (SCD) model]]

[[Slowly changing dimension]]s can be used to model temporal relations.

==Further reading==
{{refbegin}}
* [[C.J. Date]], [[Hugh Darwen]], [[Nikos Lorentzos]] (2002). ''Temporal Data & the Relational Model, First Edition'' (The Morgan Kaufmann Series in Data Management Systems); Morgan Kaufmann; 1st edition; 422 pages. {{ISBN|1-55860-855-9}}.
* [[Joe Celko]] (2014). ''Joe Celko's SQL for Smarties: Advanced SQL Programming'' (The Morgan Kaufmann Series in Data Management); Morgan Kaufmann; 5th edition. {{ISBN|978-0-12-800761-7}}.—Chapters 12 and 35 in particular discuss temporal issues.
* Snodgrass, Richard T. (1999). {{cite web|url= https://www2.cs.arizona.edu/~rts/tdbbook.pdf |title=''Developing Time-Oriented Database Applications in SQL '' }}&nbsp;{{small|(4.77&nbsp;[[Mebibyte|MiB]])}}  (Morgan Kaufmann Series in Data Management Systems); Morgan Kaufmann; 504 pages; {{ISBN|1-55860-436-7}}
{{refend}}

==See also==
* [[Anchor modeling]]
* [[Database theory]]
* [[Data warehouse]]
* [[Event store]]
* [[Spatiotemporal database]]
* [[Time series database]]
* [[Extended Date Time Format]]

==References==
{{reflist}}

==External links==
{{Commons category|Temporal databases}}
*{{cite web |title=TimeCenter Home |url=https://www2.cs.arizona.edu/projects/timecenter/ |website=TimeCenter |publisher=University of Arizona Computer Science |archive-url=https://web.archive.org/web/20200224020921/http://www2.cs.arizona.edu/projects/timecenter/ |archive-date=Feb 24, 2020 |language=English}}
*[https://web.archive.org/web/20060714164621/http://blogs.sun.com/roller/page/bblfish/20060320 Temporal Relations in RDF]
*[http://www.jenitennison.com/blog/node/101 Temporal Scope for RDF Triples]
*[http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db2z10.doc/db2z_10_prodhome.htm IBM DB2 10 for z/OS]
*[http://www.inbaseinc.com/dm-series.htm Time and Time Again]  series of articles by Randy Weis and Tom Johnston
*[http://martinfowler.com/eaaDev/timeNarrative.html Temporal Patterns] by Martin Fowler

{{Navboxes
|title = Articles related to Temporal database
|list=
{{Database models}}
{{Time topics}}
}}
{{Authority control}}

{{DEFAULTSORT:Temporal database}}
[[Category:Database management systems]]
[[Category:Database theory]]
[[Category:Transaction processing]]
[[Category:Temporal databases]]