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 could be uni-temporal, bi-temporal or tri-temporal. More specifically the temporal aspects usually include valid time, transaction time 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. Uni-temporal A uni-temporal database has one axis of time, either the validity range or the system time range. Bi-temporal A bi-temporal database has two axes of time: valid time transaction time or decision time Tri-temporal 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 databases (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: 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 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 standard. Richard Snodgrass proposed in 1992 that temporal extensions to SQL be developed by the temporal database community. In