Temporal database
It offers temporal data types and stores information relating to past, present and future time.
Temporal databases support managing and accessing temporal data by providing one or more of the following features:[1][2] 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.
[3] 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).
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[4] An attempt was made to incorporate parts of TSQL2 into the new SQL standard SQL:1999, called SQL3.
Another difference is replacement of the controversial (prefix) statement modifiers from TSQL2 with a set of temporal predicates.
More technically: if a database administrator ran the query SELECT ADDRESS FROM PERSON WHERE NAME='John Doe' on 1994-12-26, the result would be Smallville.
An official then inserts a new entry into the database stating that John lives in Smallville from April 3.
Only new records can be inserted, and existing ones updated by setting their transaction end time to show that they are no longer current.
Transaction time allows capturing this changing knowledge in the database, since entries are never directly modified or deleted.
Support for decision time preserves the entire history and prevents the loss of information during updates.
Only new records can be inserted, and existing ones updated by setting their decision end time to show that they are no longer current.
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: A bitemporal model contains both valid and transaction time.
The answers to these example questions may not be the same – the database may have been altered since 1992, causing the queries to produce different results.
A challenging issue is the support of temporal queries in a transaction time database under evolving 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.
A proposed solution is to provide automatic query rewriting,[8][9] although this is not part of SQL or similar standards.
Approaches to minimize the complexities of schema evolution are to: The following implementations provide temporal features in a relational database management system (RDBMS).
Non-relational, NoSQL database management systems that provide temporal features including the following: Temporal databases were one of the earliest forms of data version control, and influenced the development of modern data versioning systems.
