Temporal database

Temporal database stores data relating to time instances. It offers temporal data types and stores information relating to past, present
and future time. the tamporal data base has two major notions or attributes. 1. valid time. 2. transection time. More specifically the
temporal aspects usually includevalid time and transaction time. These attributes can be combined to form bitemporal data.

Valid time is the time period during which a fact is true in the real world.
Transaction time is the time period during which a fact stored in the database was known.
Bitemporal data combines both Valid and Transaction Time.
It is possible to have timelines other than Valid Time and Transaction Time, such as Decision Time, in the database. In that case the
database is called a multitemporal database as opposed to a bitemporal database. However, this approach introduces additional
complexities such as dealing with the validity of (foreign) keys.

Temporal databases are in contrast to current databases (a term that doesn't mean currently available databases, some do have
temporal features, see also below), which store only facts which are believed to be true at the current time.

Contents
1 Features
2 History
3 Example
3.1 Using a current database
3.2 Using Valid time
3.3 Using Transaction time
4 Bitemporal relations
5 Schema evolution
6 Implementations in notable products
6.1 Alternatives
7 Further reading
8 See also
9 References
10 External links

Features
Temporal databases support managing and accessing temporal data by providing one or more of ethfollowing features:[1][2]

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 pointsin the past or future, or over durations
Predicates for querying time periods, often based onAllens 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 formalizedSQL-92 standard.

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.[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). 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
, 1994[4]
Language Specification was published in September

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.[3] The TSQL2 approach was heavily criticized by
Chris Date and Hugh Darwen.[5] 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
date or timestamp columns can be bound together using a PERIOD FOR declaration. Another difference is replacement of the
[1]
controversial (prefix) statement modifiers from TSQL2 with a set of temporal predicates.

Example
For illustration, consider the following short biography of a fictional man, John Doe:

John Doe was born on April 3, 1975 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 August 26, 1994, 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 December 27, 1994. Although
John had a promising future, his story ends tragically. John Doe was accidentally hit by a
truck on April 1, 2001. The coroner reported his date of death on the very same day.

Using a current database

To store the life of John Doe in a current (non-temporal) database we use a table Person (Name, Address). (In order to simplify Name
is defined as the primary key of Person.)

John's father officially reported his birth on April 4, 1975. 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 December
27, 1994, 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 December 28, 1994 would be told that
John lives in Bigtown. More technically: if a database administrator ran the query SELECT ADDRESS FROM PERSON WHERE
NAME='John Doe' on December 26, 1994, 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 April 1, 2001, the coroner deletes the John Doe entry from the
database. After this, running the above query would return no result at all.

What the database

Date Real world event Database Action
shows
April 3, There is no person
John is born Nothing
1975 called John Doe
April 4, Inserted:Person(John John Doe lives in
John's father officially reports John's birth
1975 Doe, Smallville) Smallville
August 26, After graduation, John moves to Bigtown, but John Doe lives in
Nothing
1994 forgets to register his new address Smallville
December John Doe lives in
Nothing Nothing
26, 1994 Smallville
December Updated:Person(John John Doe lives in
John registers his new address
27, 1994 Doe, Bigtown) Bigtown
April 1, Deleted:Person(John There is no person
John dies
2001 Doe) called John Doe

Using 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, thePerson 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 April 4, 1975 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 4th, the
database states that the information is valid since the 3rd. 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:

Person(John Doe, Smallville, 3-Apr-1975, ).

On December 27, 1994 John reports his new address in Bigtown where he has been living since August 26, 1994. A new database
entry is made to record this fact:

Person(John Doe, Bigtown, 26-Aug-1994, ).

The original entry Person (John Doe, Smallville, 3-Apr-1975, ) is not deleted, but has the Valid-To attribute
updated to reflect that it is now known that John stopped living in Smallville on August 26, 1994. The database now contains two
entries for John Doe

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).

Person(John Doe, Bigtown, 26-Aug-1994, ).

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

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).

Person(John Doe, Bigtown, 26-Aug-1994, 1-Apr-2001).
Using 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. 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 bitemporal
a 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 1-Jun-1995 to 3-Sep-2000, 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:

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).

Person(John Doe, Bigtown, 26-Aug-1994, 1-Jun-1995).
Person(John Doe, Beachy, 1-Jun-1995, 3-Sep-2000).
Person(John Doe, Bigtown, 3-Sep-2000, 1-Apr-2001).

However, this leaves no record that the database ever claimed that he lived in Bigtown during 1-Jun-1995 to 3-Sep-2000. 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:

Name, City, Valid From, Valid Till, Entered, Superseded

Person(John Doe, Smallville, 3-Apr-1975, , 4-Apr-1975, 27-Dec-1994).

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994, 27-Dec-1994, ).
Person(John Doe, Bigtown, 26-Aug-1994, , 27-Dec-1994, 2-Feb-2001 ).
Person(John Doe, Bigtown, 26-Aug-1994, 1-Jun-1995, 2-Feb-2001, ).
Person(John Doe, Beachy, 1-Jun-1995, 3-Sep-2000, 2-Feb-2001, ).
Person(John Doe, Bigtown, 3-Sep-2000, , 2-Feb-2001, 1-Apr-2001 ).
Person(John Doe, Bigtown, 3-Sep-2000, 1-Apr-2001, 1-Apr-2001, ).

The database records not only what happened in the real world, but also what was ficially
of recorded at different times.

Bitemporal relations
A bitemporal relation 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 the database
may have been altered since 1992, causing the queries to produce dif
ferent 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, January 21, 1998).

Schema evolution
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 firstly 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 [1]. This process would be particularly taxing
[6][7] although this is not part of SQL or similar standards.
for users. A proposed solution is to provide automatic query rewriting,

A suggested approach to supposedly minimize the complexities of schema evolution is to use a so-called "schema-agnostic" NoSQL
[8]
database which allegedly reduces the complexities of modeling bitemporal data.

Implementations in notable products

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

Oracle Database 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.[9][10] The PostgreSQL range types are supported by numerous native
operators and functions.
Teradata provides two products. Teradata version 13.10 and Teradata version 14 have temporal features based on
TSQL2[11] built into the database.
[2] which is based on the temporal capabilities of the
IBM DB2 version 10 added a feature called "time travel query"
SQL:2011 standard.[1]
Microsoft SQL Server introduced Temporal Tables as a feature for SQL Server 2016. The feature is described ina
video on Microsoft's "Channel 9" web site.[12]
Non-relational, NoSQL database management systems that provide temporal features including the following:

MarkLogic introduced bitemporal data support in version 8.0. T

ime stamps for Valid and System time are stored in
JSON or XML documents.[13]

Alternatives
Sometimes the Slowly changing dimensionis used as a method, this is an example:
Scd model

Further reading
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). "Developing Time-Oriented Database Applications in SQL" (PDF). (4.77 MiB) (Morgan
Kaufmann Series in Data Management Systems); Morgan Kaufmann; 504 pages; ISBN 1-55860-436-7

See also
Anchor Modeling
Database theory
Event Sourcing and Event store
Spatiotemporal database
Time series database

References
1. Kulkarni, Krishna, and Jan-Eike Michels. Temporal
" features in SQL: 2011(http://www.sigmod.org/publications/sigmo
d-record/1209/pdfs/07.industry.kulkarni.pdf)". ACM SIGMOD Record 41.3 (2012): 34-43.
2. http://www.ibm.com/developerworks/data/library/techarticle/dm-1204db2temporaldata/
3. Snodgrass, 1999, p. 9
 4. Richard T. Snodgrass. "TSQL2 Temporal Query Language"(http://www.cs.arizona.edu/~rts/tsql2.html).
www.cs.arizona.edu. Computer Science Department of the University of Arizona
. Retrieved 14 July 2009.
5. Hugh Darwen, C.J. Date, An overview and Analysis of Proposals Based on the TSQL2 Approach (http://citeseerx.is
t.psu.edu/viewdoc/summary?doi=10.1.1.116.7598) , In Date on Database: Writings 2000-2006, C.J. Date, Apress,
2006, pp. 481-514
6. Hyun J. Moon; Carlo A. Curino; Alin Deutsch; C.-Y
. Hou & Carlo Zaniolo (2008).Managing and querying transaction-
time databases under schema evolution(http://yellowstone.cs.ucla.edu/schema-evolution/index.php/Prima)
. Very
Large Data Base VLDB.
7. Hyun J. Moon; Carlo A. Curino & Carlo Zaniolo (2010).Scalable Architecture and Query Optimization for
Transaction-time DBs with Evolving Schemas(http://yellowstone.cs.ucla.edu/schema-evolution/index.php/AIMS)
.
SIGMOD.
8. Anthony B. Coates (2015).Why Banks Care About Bitemporality(https://www.youtube.com/watch?t=28&v=n29Gtit3l
MU). MarkLogic World 2015.
9. Paquier, Michael (1 November 2012)."Postgres 9.2 highlight: range types"(https://web.archive.org/web/2016042321
5529/http://michael.otacoo.com/postgresql-2/postgres-9-2-highlight-range-types/). Michael Paquier - Open source
developer based in Japan. Archived from the original (http://michael.otacoo.com/postgresql-2/postgres-9-2-highlight-
range-types/) on 2016-04-23.
10. Katz, Jonathan S. "Range Types: Your Life Will Never Be The Same"(https://wiki.postgresql.org/images/7/73/Range-
types-pgopen-2012.pdf)(PDF). Retrieved 14 July 2014.
11. Al-Kateb, Mohammed et al. "Temporal Query Processing in Teradata (http://www.edbt.org/Proceedings/2013-Genov
a/papers/edbt/a51-al-kateb.pdf)". EDBT/ICDT 13 March 1822, 2013, Genoa, Italy
12. http://channel9.msdn.com/Shows/Data-Exposed/T
emporal-in-SQL-Server-2016
13. Bridgwater, Adrian (24 November 2014)."Data Is Good, 'Bidirectionalized Bitemporal' Data Is Better"(https://www.for
bes.com/sites/adrianbridgwater/2014/11/24/data-is-good-bidirectionalized-bitemporal-data-is-better/#5424f
f9b567b).

External links
TimeCenter
Temporal Relations in RDF
Temporal Scope for RDF Triples
IBM DB2 10 for z/OS
Time and Time Again series of articles by Randy Weis and Tom Johnston
Temporal Patterns by Martin Fowler

Retrieved from "https://en.wikipedia.org/w/index.php?title=T

emporal_database&oldid=806489449"

This page was last edited on 22 October 2017, at 10:38.

Text is available under theCreative Commons Attribution-ShareAlike License ; additional terms may apply. By using this
site, you agree to the Terms of Use and Privacy Policy. Wikipedia is a registered trademark of theWikimedia
Foundation, Inc., a non-profit organization.