Temporal features in SQL:2011

Krishna Kulkarni, Jan-Eike Michels (IBM Corporation)

{krishnak, janeike}@us.ibm.com

ABSTRACT implement temporal support as part of the application

logic, which often resulted in expensive development
SQL:2011 was published in December of 2011, cycles and complex, hard-to-maintain code.
replacing SQL:2008 as the most recent revision of the In 1995, the ISO SQL committee initiated a project to
SQL standard. This paper covers the most important create a new part of SQL standard devoted to the lan-
new functionality that is part of SQL:2011: the ability to guage extensions for the temporal data support. A set of
create and manipulate temporal tables. language extensions based on (but not identical to)
TSQL2 [8] were submitted for standardization at that
time. Unfortunately, these proposals generated consider-
1. Introduction able controversy (see [9] for more details), and failed to
get adequate support from the ISO SQL committee’s
SQL is the predominant database query language stan- membership. In addition, there was no indication that
dard published jointly by ISO (the International Organi- key DBMS vendors were planning to implement these
zation for Standardization) and IEC (the International extensions in their products. Eventually, the work on
Electrotechnical Commission). In December 2011, ISO/ this new part was cancelled in 2001.
IEC published the latest edition of the SQL standard, Recently, a new set of language extensions for tempo-
SQL:2011. A recent article in SIGMOD Record pro- ral data support were submitted to and accepted by the
vides a brief survey of the new features in SQL:2011 ISO SQL committee. These language extensions are
[1]. Because of space constraints, it did not cover the now part of SQL:2011 Part 2, SQL/Foundation [10],
most important new feature in SQL:2011: the ability to instead of appearing as a new part. There is currently at
create and manipulate temporal tables, i.e., tables whose least one commercial implementation [5] based on these
rows are associated with one or more temporal periods. extensions that the authors are aware of.
This is the subject of the current article.
2.1 Periods
2. Temporal data support The cornerstone of temporal data support in SQL:2011
is the ability to define and associate time periods with
Extensions to support temporal data1 in SQL have the rows of a table. Essentially, a time period is a mathe-
long been desired. There is a large body of research matical interval on the timeline, demarcated by a start
papers, conference publications, and books on this topic, time and an end time.
some dating back to the early 1980s. For more details, Many treatments of temporal databases introduce a
we refer the readers to an extensive (but outdated) bibli- period data type, defined as an ordered pair of two
ography [2] and to books such as [3] and [4]. datetime values, for the purpose of associating time
Though the previous academic research produced a periods with the rows of a table. SQL:2011 has not
large number of solutions, the commercial adoption has taken this route. Adding a new data type to the SQL
been rather slow. It is only recently that commercial standard (or to an SQL product) is a costly venture
database management systems (DBMSs) have begun to because of the need to support the new data type in the
offer SQL extensions for managing temporal data [5, 6, tools and other software packages that form the ecosys-
7]. Prior to this development, users were forced to tem surrounding SQL. For example, if a period type
were added to SQL, then it would have to also be added
to the stored procedure language, to all database APIs
1. Note that there is no single, commonly
such as JDBC, ODBC, and .NET, as well as to the sur-
accepted definition of the term “temporal
rounding technology such as ETL products, replication
data”. For the purposes of this article, we
solutions, and others. There must also be some means of
define “temporal data” to mean any data
communicating period values to host languages that do
with one or more associated time periods
not support period as a native data type, such as C or
during which that data is deemed to be
Java. These factors can potentially slow down the adop-
effective or valid along some time dimen-
tion of new type for a long time.
sion.

34 SIGMOD Record, September 2012 (Vol. 41, No. 3)

 Instead of adding a period type, SQL:2011 adds using a pair of columns of datetime data type. It would
period definitions as metadata to tables. A period defini- be very expensive for users invested in such solutions to
tion is a named table component, identifying a pair of replace them with a solution that uses a single column of
columns that capture the period start and the period end period type.
time. CREATE TABLE and ALTER TABLE statements
are enhanced with syntax to create or destroy period 2.2 Application-time period tables
definitions. The period start and end columns are con-
Application-time period tables are intended for meet-
ventional columns, with separate names. The period
ing the requirements of applications that are interested
name occupies the same name space as column names,
in capturing time periods during which the data is
i.e., a period cannot have the same name as a column.
believed to be valid in the real world. A typical example
SQL:2011 has adopted a closed-open period model,
of such applications is an insurance application, where it
i.e., a period represents all times starting from and
is necessary to keep track of the specific policy details
including the start time, continuing to but excluding the
of a given customer that are in effect at any given point
end time. For a given row, the period end time must be
in time.
greater than its period start time; in fact, declaring a
A primary requirement of such applications is that the
period definition in a table implies a table constraint that
user be put in charge of setting the start and end times of
enforces this property.
the validity period of rows, and the user be free to assign
The literature on temporal databases recognizes two
any time values, either in the past, current or in the
dimensions of time for temporal data support, e.g., see
future, for the start and end times. Another requirement
[3]:
of such applications is that the user be permitted to
• valid time, the time period during which a row is
update the validity periods of the rows as errors are dis-
regarded as correctly reflecting reality by the user of the
covered or new information is made available.
database.
Any table that contains a period definition with a
• transaction time, the time period during which a
user-defined name is an application-time period table.
row is committed to or recorded in the database.
For example:
For any given row, its transaction time may arbitrarily
CREATE TABLE Emp(
differ from its valid time. For example, in an insurance
ENo INTEGER,
database, information about a policy may get inserted
EStart DATE,
much before that policy comes into effect.
EEnd DATE,
In SQL:2011, transaction time support is provided by
EDept INTEGER,
system-versioned tables, which in turn contain the sys-
PERIOD FOR EPeriod (EStart, EEnd)
tem-time period, and valid time support is provided by
)
tables containing an application-time period2. The name Users can pick any name they want for the name of
of the system-time period is specified by the standard as the period as well as for the names of columns that act
SYSTEM_TIME.The name of an application-time as the start and end columns of the period. The data
period can be any user-defined name. Users are allowed types of the period start and end columns must be either
to define at most one application-time period and at DATE or a timestamp type, and data types of both col-
most one system-time period per table. umns must be the same.
One of the advantages of the SQL:2011 approach over The conventional INSERT statement provides suffi-
an approach based on the period data type is that it cient support for setting the initial values of application-
allows existing databases that capture period informa- time period start and end columns. For example, the fol-
tion in a pair of datetime columns to take advantage of lowing INSERT statement inserts one row into the Emp
the SQL:2011 extensions more easily. Ever since table:
DBMSs have been on the scene, users have been build- INSERT INTO Emp
ing their own solutions for handling temporal data as VALUES (22217,
part of their application logic. Since most DBMSs do DATE ‘2010-01-01’,
not support a period type, applications dealing with tem- DATE '2011-11-12', 3)
poral data have tended to capture the period information The resulting table looks as shown below (assuming it
was empty before):
2. Interestingly, SQL:2011 manages to pro-
vide this support without actually defining Eno EStart EEnd EDept
or using the terms “temporal data” or “tem-
22217 2010-01-01 2011-11-12 3
poral table”.

SIGMOD Record, September 2012 (Vol. 41, No. 3) 35

 The conventional UPDATE statement can be used to are regarded as newly inserted rows, so INSERT trig-
modify the rows of application-time period tables gers fire for them.
(including the application-time period start and end The DELETE statement is similarly enhanced with
times). Similarly, the conventional DELETE statement FOR PORTION OF syntax to facilitate deletes that are
can be used to delete rows of application-time period only effective within a specified period. For example,
tables. the following DELETE statement removes the employee
A new feature in SQL:2011 is the ability to specify whose number is 22217 for the period from Feb. 3, 2011
changes that are effective within a specified period. This to Sept. 10, 2011:
is provided by a syntactic extension to both UPDATE DELETE Emp
and DELETE statements that lets users specify the FOR PORTION OF EPeriod
period of interest. For example, the following UPDATE FROM DATE '2011-02-03'
statement changes the department of the employee TO DATE '2011-09-10'
whose number is 22217 to 4 for the period from Feb. 3, WHERE ENo = 22217
2011 to Sept. 10, 2011: Similar to the UPDATE example, any row whose
UPDATE Emp application-time period is contained in P from Feb. 3,
FOR PORTION OF EPeriod 2011 to Sept. 10, 2011 is simply deleted. If an overlap-
FROM DATE '2011-02-03' ping row whose application-time period has a portion
TO DATE '2011-09-10' either strictly before or strictly after P, then that row gets
SET EDept = 4 split into two or three contiguous rows, and of these, the
WHERE ENo = 22217 row whose application-time period is contained in P is
To execute this statement, the DBMS locates all rows deleted. For example, suppose the following is the only
whose application-time period overlaps the period P overlapping row:
from Feb. 3, 2011 to Sept. 10, 2011. Recall that periods
follow closed-open semantics in SQL:2011, so P ENo EStart EEnd EDept
includes Feb. 3, 2011 but excludes Sept. 10, 2011. Any
overlapping row whose application-time period is con- 22217 2010-01-01 2011-11-12 3
tained in P is simply updated. If an overlapping row
whose application-time period has a portion either The result of the statement will be these two rows:
strictly before or strictly after P, then that row gets split
into two or three contiguous rows depending on the
extent of overlap, and of these, the row whose applica- ENo EStart EEnd EDept
tion-time period is contained in P is updated. For exam- 22217 2010-01-01 2011-02-03 3
ple, suppose the following is the only overlapping row:
22217 2011-09-10 2011-11-12 3
ENo EStart EEnd EDept
In this example, the result is the deletion of the origi-
22217 2010-01-01 2011-11-12 3 nal row and the insertion of two new rows; DELETE
triggers fire for the deleted row and INSERT triggers
Note that the application-time period of the above row fire for the newly inserted rows.
extends beyond P at both ends. The result of the
UPDATE statement will be these three rows: 2.2.1 Primary keys on application-time
period tables
The last section gave an example of an Emp table in
ENo EStart EEnd EDept
which one might expect that ENo is the primary key.
22217 2010-01-01 2011-02-03 3 However, looking at the sample result of the UPDATE
statement, there are three rows all with ENo 22217. This
22217 2011-02-03 2011-09-10 4 example shows that the primary key must also include
the application-time period columns EStart and
22217 2011-09-10 2011-11-12 3
EEnd.

In this example, the row whose EDept value is

updated to 4 is regarded as the original row and hence,
UPDATE triggers fire for this row. The other two rows

36 SIGMOD Record, September 2012 (Vol. 41, No. 3)

 Simply adding EStart and EEnd to the primary key look at some sample data. Assume the Emp table
will not be sufficient though. Consider the following contains the following rows:
data:
ENo EStart EEnd EDept
ENo EStart EEnd EDept
22218 2010-01-01 2011-02-03 3
22217 2010-01-01 2011-09-10 3
22218 2011-02-03 2011-11-12 4
22217 2010-02-03 2011-11-12 4
Assume the Dept table contains the following rows:
The triples (22217, 2010-01-01, 2011-09-10) and
(22217, 2010-02-03, 2011-11-12) are not duplicates so DNo DStart DEnd DName
they would be acceptable values for a conventional pri-
mary key on these three columns. But note that the 3 2009-01-01 2011-12-31 Test
application-time periods of these rows overlap. Seman-
tically, this says that the employee with ENo 22217 4 2011-06-01 2011-12-31 QA
belongs to two departments, 3 and 4, during the period
from Feb. 3, 2010 through Sept. 10, 2011. Perhaps the Looking strictly at the values of EDept column of the
user wishes to allow an employee to belong to two Emp table and the DNo column of the Dept table, we
departments; however, the more typical requirement is may conclude that the conventional referential integrity
that an employee belongs to exactly one department at constraint involving the two tables is satisfied. But note
any given time. To achieve that, it must be possible to that the employee with ENo 22218 is assigned to the
forbid overlapping application-time periods, which can department with DNo 4 from Feb. 3, 2011 to Nov. 12,
be specified with this syntax: 2011, but there is no department with DNo 4 for the
ALTER TABLE Emp period from Feb. 3, 2011 to June 1, 2011. Clearly, this
ADD PRIMARY KEY (ENo, violates our requirement that every value of EDept col-
EPeriod WITHOUT OVERLAPS) umn in Emp table corresponds to some value of DNo
With this primary key definition, the sample data is column in Dept table at every point in time. To disal-
prohibited as a constraint violation. low such a situation, it must be possible to forbid a row
in a child table whose application-time period is not
2.2.2 Referential constraints on applica- contained in the application-time period of a matching
tion-time period tables row in the parent table, which can be specified with this
syntax:
Continuing the preceding example, suppose there is ALTER TABLE Emp
another table with the following definition: ADD FOREIGN KEY
CREATE TABLE Dept( (Edept, PERIOD EPeriod)
DNo INTEGER, REFERENCES Dept
DStart DATE, (DNo, PERIOD DPeriod)
DEnd DATE, With this referential constraint definition, the sample
DName VARCHAR(30), data is prohibited as a constraint violation.
PERIOD FOR DPeriod (DStart, DEnd), More generally, for a given child row, it is not neces-
PRIMARY KEY (DNo, sary that there exists exactly one matching row in the
DPeriod WITHOUT OVERLAPS) parent table whose application-time period contains the
) application-time period of the child row. As long as the
Assume also that we want to make sure that at every application-time period of a row in the child table is
point in time, every value in EDept column contained in the union of application-time periods of
corresponds to some value of DNo column in Dept two or more contiguous matching rows in the parent
table, i.e., every employee at every point in time during table, the referential constraint is considered satisfied.
her employment belongs to a department that actually
exists at that point in time. How should this work? Let’s 2.2.3 Querying application-time period
tables
In SQL:2011, application-time period tables can be
queried using the regular query syntax. For example, to

SIGMOD Record, September 2012 (Vol. 41, No. 3) 37

retrieve the department where the employee 22217 This is not true for Allen’s overlaps operator. In con-
worked as of January 2, 2011, one can express the query trast, SQL:2011’s OVERLAPS predicate is a true test of
as: period overlap. Also, SQL:2011’s OVERLAPS predi-
SELECT Name, Edept cate is symmetric, i.e, if “X OVERLAPS Y” is true,
FROM Emp then “Y OVERLAPS X” is also true. This is again not
WHERE ENo = 22217 true for Allen’s overlaps operator.
AND EStart <= DATE '2011-01-02' • The predicate “X CONTAINS Y” in SQL:2011 is
AND EEnd > DATE '2011-01-02' equivalent to the Boolean expression using Allen’s
A simpler way to formulate the above query would be operators “(X contains Y) OR (X starts Y)
to employ one of the period predicates provided in OR (X finishes Y) OR (X equal Y)”. Note
SQL:2011 for expressing conditions involving periods: that Allen’s contains operator is not a true test of
CONTAINS, OVERLAPS, EQUALS, PRECEDES, period containment. Intuitively, period X is considered
SUCCEEDS, IMMEDIATELY PRECEDES, and containing period Y if every time point in Y is also in X.
IMMEDIATELY SUCCEEDS. For example, the above This is not true for Allen’s contains operator. In con-
query could also be expressed using the CONTAINS trast, SQL:2011’s CONTAINS predicate is a true test of
predicate, as shown below: period containment.
SELECT Ename, Edept • The predicate “X PRECEDES Y” in SQL:2011 is
FROM Emp equivalent to the Boolean expression using Allen’s
WHERE ENo = 22217 AND operators “(X before Y) OR (X meets Y)”.
EPeriod CONTAINS DATE '2011-01-02' • The predicate “X SUCCEEDS Y” in SQL:2011 is
If one wanted to know all the departments where the equivalent to the Boolean expression using Allen’s
employee whose number is 22217 worked during the operators “(X after Y) OR (X met_by Y)”.
period from January 1, 2010 to January 1, 2011, one • The predicates “X EQUALS Y”, “X IMMEDI-
could formulate the query as: ATELY PRECEDES Y”, and “X IMMEDIATELY
SELECT Ename, Edept SUCCEEDS Y” in SQL:2011 are equivalent to the
FROM Emp Allen’s operators “X equal Y”, “X meets Y”, and
WHERE ENo = 22217 “X met_by Y”, respectively.
AND EStart < DATE '2011-01-01'
AND EEnd > DATE '2010-01-01' 2.3 System-versioned tables
Note that the period specified in the above query uses
System-versioned tables are intended for meeting the
the closed-open model, i.e., the period includes January
requirements of applications that must maintain an
1, 2010 but excludes January 1, 2011. Alternatively, the
accurate history of data changes either for business rea-
same query could be expressed using the OVERLAPS
sons, legal reasons, or both. A typical example of such
predicate as:
applications is a banking application, where it is neces-
SELECT Ename, Edept
sary to keep previous states of customer account infor-
FROM Emp
mation so that customers can be provided with a
WHERE ENo = 22217 AND
detailed history of their accounts. There are also plenty
EPeriod OVERLAPS
of examples where certain institutions are required by
PERIOD (DATE '2010-01-01',
law to preserve historical data for a specified length of
DATE '2011-01-01')
time to meet regulatory and compliance requirements.
Period predicates are functionally similar to (but not
A key requirement of such applications is that any
identical to) the well-known Allen’s interval operators
update or delete of a row must automatically preserve
[11]. The correspondence between SQL’s period predi-
the old state of the row before performing the update or
cates and Allen’s operators is as follows:
delete. Another important requirement is that the sys-
• The predicate “X OVERLAPS Y” in SQL:2011 is
tem, rather than the user, maintains the start and end
equivalent to the Boolean expression using Allen’s
times of the periods of the rows, and that users be unable
operators “(X overlaps Y) OR (X
to modify the content of historical rows or the periods
overlapped_by Y) OR (X during Y) OR (X
associated with any of the rows. Any updates to the peri-
contains Y) OR (X starts Y) OR (X
ods of rows in a system-versioned table must be per-
started_by Y) OR (X finishes Y) OR (X
formed only by the system as a result of updates to the
finished_by Y) OR (X equal Y)”. Note that
non-period columns of the table or as a result of row
Allen’s overlaps operator is not a true test of period
deletions. This provides the guarantee that the recorded
overlap. Intuitively, two periods are considered overlap-
ping if they have at least one time point in common.

38 SIGMOD Record, September 2012 (Vol. 41, No. 3)

history of data changes cannot be tampered with, which example, assume that the following INSERT state-
is critical to meet auditing and compliance regulations. ment executed in a transaction whose transaction
Any table that contains a period definition with the timestamp is 2012-01-01 09:00:004:
standard-specified name, SYSTEM_TIME, and includes INSERT INTO Emp (ENo, EName)
the keywords WITH SYSTEM VERSIONING in its VALUES (22217, 'Joe')
definition is a system-versioned table. Similar to appli- The resulting table looks as shown below (assuming it
cation-time period tables, users can pick any name they was empty before):
want for the names of columns that act as the start and
end columns of the SYSTEM_TIME period. Though
ENo Sys_Start Sys_End EName
SQL:2011 allows the data types of the period start and
end columns to be either DATE or a timestamp type (as 22217 2012-01-01 9999-12-31 Joe
long as the data types of both columns are the same), in 09:00:00 23:59:59
practice, most implementations will provide the
TIMESTAMP type with the highest fractional seconds
3) UPDATE and DELETE on system-versioned tables
precision as the data type for the system-time period
only operate on current system rows. Users are not
start and end columns. For example:
allowed to update or delete historical system rows.
CREATE TABLE Emp
Users are also not allowed to modify the system-time
ENo INTEGER,
period start or the end time of both current system
Sys_start TIMESTAMP(12) GENERATED
rows and historical system rows.
ALWAYS AS ROW START,
4) UPDATE and DELETE on system-versioned tables
Sys_end TIMESTAMP(12) GENERATED
result in the automatic insertion of a historical system
ALWAYS AS ROW END,
row for every current system row that is updated or
EName VARCHAR(30),
deleted.
PERIOD FOR SYSTEM_TIME (Sys_start,
An UPDATE statement on a system-versioned table
Sys_end)
first inserts a copy of the old row with its system-time
) WITH SYSTEM VERSIONING
period end time set to the transaction timestamp, indi-
Similar to application-time periods, system-time peri-
cating that the row ceased to be current as of the transac-
ods use closed-open period model. At any given point in
tion timestamp. It then updates the row while changing
time, a row in a system-versioned table is regarded as
its system-period start time to the transaction timestamp,
current system row if the system-time period of that row
indicating that the updated row to be the current system
contains the current time. A row that is not a current sys-
row as of the transaction timestamp. For example, sup-
tem row is regarded as a historical system row.
pose the current system row with ENo 22217 is as
System-versioned tables differ from application-time
shown below:
period tables in the following respects:
1) In contrast to the application-time period tables,
users are not allowed to assign or change the values ENo Sys_Start Sys_End EName
of Sys_start or Sys_end columns; they are
22217 2012-01-01 9999-12-31 Joe
assigned (and changed) automatically by the database
09:00:00 23:59:59
system. This is the reason why the definitions of
Sys_start or Sys_end columns must include
the keywords GENERATED ALWAYS. The following UPDATE statement changes the name
2) INSERT into a system-versioned table automatically of the employee whose number is 22217 from Joe to
sets the value of Sys_start column to the transac- Tom effective from the transaction timestamp of the
tion timestamp, a special value associated with every transaction in which the UPDATE statement was exe-
transaction3, and sets the value of Sys_end column cuted:
to the highest value of the column’s data type. For UPDATE Emp
SET EName = 'Tom'
WHERE ENo = 22217
3. SQL:2011 leaves it up to SQL-implementa- A historical system row that corresponds to the state
tions to pick an appropriate value for the of the row prior to the update is first inserted and then
transaction timestamp of a transaction, but it
does require the transaction timestamp of a 4. Note that we are not showing the fractional
transaction to remain fixed during the entire part of seconds in any of the examples in
transaction. this Section.

SIGMOD Record, September 2012 (Vol. 41, No. 3) 39

the update is performed. Assuming the above statement Note that in contrast to the application-time period
is executed in a transaction with the transaction times- tables, FOR PORTION OF SYSTEM_TIME is not
tamp 2012-02-03 10:00:00, the final result will be these needed (and hence not allowed) for the UPDATE and
two rows: DELETE statements on system-versioned tables.

ENo Sys_Start Sys_End EName 2.3.1 Primary key and referential con-
straints on system-versioned tables
22217 2012-01-01 2012-02-03 Joe
09:00:00 10:00:00 The definition and enforcement of constraints on sys-
tem-versioned tables is considerably simpler than the
22217 2012-02-03 9999-12-31 Tom definition and enforcement of constraints on applica-
10:00:00 23:59:59 tion-time period tables. This is because constraints on
system-versioned tables need only be enforced on the
In this example, the row whose name is Tom is the current system rows. Historical system rows in a sys-
updated row; UPDATE triggers fire for this row. Note tem-versioned table form immutable snapshots of the
that the insertion of historical system rows does not fire past. Any constraints that were in effect when a histori-
any INSERT triggers for the inserted rows. Note also cal system row was created would have already been
that historical system rows created as a result of checked when that row was a current system row, so
sequence of updates for a given row form one contigu- there is never any need to enforce constraints on histori-
ous chain without any gap between their system-time cal system rows. Consequently, there is no need to
periods. include the system-period start and end columns or the
A DELETE statement on a system-versioned table period name in the definition of primary key and refer-
does not actually delete the qualifying rows; instead it ential constraints on system-versioned tables. For exam-
changes the system-time period end time of those row to ple, the following ALTER TABLE statement specifies
the transaction timestamp, indicating that those rows ENo column as the primary key of Emp table:
ceased to be current as of the transaction timestamp. For ALTER TABLE Emp
example, suppose that the current system row with ENo ADD PRIMARY KEY (ENo)
22217 is as shown below: The above constraint ensures there exists exactly one
current system row with a given ENo value.
Similarly, the following ALTER TABLE statement
ENo Sys_Start Sys_End EName specifies a referential constraint between Emp and
22217 2012-01-01 9999-12-31 Joe Dept tables:
09:00:00 23:59:59 ALTER TABLE Emp
ADD FOREIGN KEY (Edept)
REFERENCES Dept (DNo)
The following DELETE statement simply changes the The above constraint is again enforced only on the
system-time period end time of the current system row current system rows of Emp and Dept tables.
for the employee 22217 to the transaction timestamp of
the transaction in which the DELETE statement was
executed:
2.3.2 Querying system-versioned tables
DELETE FROM Emp Because system-versioned tables are intended prima-
WHERE ENo = 22217 rily for tracking historical data changes, queries on sys-
Assuming the above statement is executed in a trans- tem-versioned tables often tend to be concerned with
action with the transaction timestamp 2012-06-01 retrieving the table content as of a given point in time or
00:00:00, the final result will be the following row: between any two given points in time. SQL:2011 pro-
vides three syntactic extensions for this specific pur-
ENo EStart EEnd EName pose. These are allowed only in queries on system-
versioned tables.
22217 2012-01-01 2012-06-01 Joe The first extension is the FOR SYSTEM_TIME AS
09:00:00 00:00:00 OF syntax that is useful for querying the table content
as of a specified point in time. For example, the follow-
In this example, DELETE triggers fire for the row ing query retrieves the rows of Emp that were current as
selected for deletion. of Jan. 2, 2011:

40 SIGMOD Record, September 2012 (Vol. 41, No. 3)

 SELECT ENo,EName,Sys_Start,Sys_End 2.4 Bitemporal tables
FROM Emp FOR SYSTEM_TIME AS OF
A table may be both a system-versioned table and an
TIMESTAMP '2011-01-02 00:00:00'
The above query returns all rows whose system-time application-time period table5. For example:
period start time is less than or equal to the specified CREATE TABLE Emp(
timestamp and whose system-time period end time is ENo INTEGER,
greater than the specified timestamp. EStart DATE,
The second and third extensions allow for retrieving EEnd DATE,
the content of a system-versioned table between any two EDept INTEGER,
points in time. The following query returns all rows that PERIOD FOR EPeriod (EStart, EEnd),
were current starting from TIMESTAMP '2011-01- Sys_start TIMESTAMP(12) GENERATED
02 00:00:00’up to (but not including) TIMESTAMP ALWAYS AS ROW START,
'2011-12-31 00:00:00': Sys_end TIMESTAMP(12) GENERATED
SELECT ENo,EName,Sys_Start,Sys_End ALWAYS AS ROW END,
FROM Emp FOR SYSTEM_TIME FROM EName VARCHAR(30),
TIMESTAMP '2011-01-02 00:00:00’TO PERIOD FOR SYSTEM_TIME
TIMESTAMP '2011-12-31 00:00:00' (Sys_start, Sys_end),
In contrast, the following query returns all rows that PRIMARY KEY (ENo,
were current starting from TIMESTAMP '2011-01- EPeriod WITHOUT OVERLAPS),
02 00:00:00’up to (and including) TIMESTAMP FOREIGN KEY
'2011-12-31 00:00:00': (Edept, PERIOD EPeriod)
SELECT ENo,EName,Sys_Start,Sys_End REFERENCES Dept
FROM Emp FOR SYSTEM_TIME BETWEEN (DNo, PERIOD DPeriod)
TIMESTAMP '2011-01-02 00:00:00'AND ) WITH SYSTEM VERSIONING
TIMESTAMP '2011-12-31 00:00:00' Rows in such tables are associated with both the sys-
Note that the period specified in the (FROM ... TO ...) tem-time period and the application-time period. Such
corresponds to a closed-open period model while the tables are very useful for capturing both the periods dur-
period specified in the (BETWEEN ... AND ...) corre- ing which facts were believed to be true in the real
sponds to a closed-closed period model. world as well as the periods during which those facts
If a query on system-versioned tables does not specify were recorded in the database. For example, while
any of the above three syntactic options, then that query employed, an employee may change names. Typically
is assumed to specify FOR SYSTEM_TIME AS OF the name changes legally at a specific time (for exam-
CURRENT_TIMESTAMP by default and the query ple, a marriage) but the name is not changed in the data-
returns only the current system rows as the result. For base concurrently with the legal change. In that case, the
example, the following query returns only the current system-time period automatically records when a partic-
system rows of Emp table: ular name is known to the database, and the application-
SELECT ENo,EName,Sys_Start,Sys_End time period records when the name was legally effec-
FROM Emp tive. Successive updates to bitemporal tables can journal
The choice of returning current systems rows as the complex twists and turns in the state of knowledge cap-
default is especially suited for those applications where tured by the database.
retrieval of current system rows is the most frequent Bitemporal tables combine the capabilities of both
operation. In addition, it also helps with the database system-versioned and application-time period tables. As
migration in that applications running on non-system- in the case of application-time period tables, the user is
versioned tables would continue to work and produce in charge of supplying values for the application-time
the same results when those tables are converted to sys- period start and end columns. As in the case of system-
tem-versioned tables. versioned tables, INSERT into such a table automati-
Finally, to retrieve both current and historical system cally sets the value of system-time period start column
rows of a system-versioned table, one can use a query of to the transaction timestamp, and the value of system-
the kind shown below:
SELECT ENo,EName,Sys_Start,Sys_End
FROM Emp FOR SYSTEM_TIME FROM 5. Though SQL:2011 does not define any spe-
TIMESTAMP '0001-01-01 00:00:00' TO cific term for such tables, we use the term
TIMESTAMP '9999-12-31 23:59:59' “bitemporal tables” in keeping with its use
in the literature as well as in some products.

SIGMOD Record, September 2012 (Vol. 41, No. 3) 41

time period end column to the highest value of the col- 3. Comparison with previous tempo-
umn’s data type.
As in the case of application-time period tables, both
ral proposals
the conventional UPDATE statement as well as UPDATE Earlier, we alluded to the fact that the SQL committee
with FOR PORTION OF app-period, where app- had initiated a temporal project that was eventually can-
period is the name of application-time period, can be celled around 2001. We list below some of the differ-
used to modify the rows of bitemporal tables. Similarly, ences between the approach taken by the previous
the conventional DELETE statement as well as DELETE proposals and the approach taken by SQL:2011 exten-
with FOR PORTION OF app-period can be used to sions:
delete rows from bitemporal tables. As in the case of • In previous proposals, the period information was
system-versioned tables, only current rows in system- associated with the rows of temporal tables using an
time can be updated or deleted and a historical system unnamed hidden column. This design was motivated by
row is automatically inserted for every current system the notion of temporal upward compatibility [12], which
row that is updated or deleted. required a temporal table and its equivalent non-tempo-
Queries on bitemporal tables can specify predicates on ral table to have exactly the same number of columns.
both application-time periods as well as system-time One major drawback of this approach is that it is incom-
periods to qualify rows that will be returned as the query patible with SQL’s notion of tables, which requires all
result. For example, the following query returns the information associated with the rows of a table to be
department where the employee 22217 worked as of captured explicitly as (and only as) column values. The
December 1, 2010, recorded in the database as of July 1, other drawback was that queries of the form “SELECT
2011: * FROM T”, where T is a temporal table, did not return
SELECT ENo, EDept the period information associated with the rows of T in
FROM Emp FOR SYSTEM_TIME AS OF the query result. If users wanted to access the period
TIMESTAMP '2011-07-01 00:00:00' information associated with the rows, they were forced
WHERE ENo = 22217 AND to include invocations of special built-in functions in the
EPeriod CONTAINS DATE '2010-12-01' select list of a query for that purpose. These built-in
functions operated on the range variables associated
2.5 Future directions with temporal tables in a query expression, and returned
Though SQL:2011 has incorporated several signifi- the period value associated with the rows pointed to by
cant extensions for managing temporal data, there is cer- those range variables. In contrast, the period informa-
tainly room for additional extensions. These are left as tion is associated with the rows of temporal tables using
Language Opportunities for future versions of the stan- explicit, user-defined columns in SQL:2011. Also, the
dard. Here is a partial list of such extensions: period information associated with the rows of a tempo-
• Support for period joins, i.e., joining a row from ral table can be accessed in SQL:2011 simply by includ-
one table with a row from another table such that their ing the corresponding period start and end columns in
application-time or system-time periods satisfy a condi- the select list of a query.
tion such as overlap. Note that it is possible to do an • The previous proposals resorted to a controversial
inner join of this kind using SQL:2011’s OVERLAPS technique of prefixing queries, constraints, and insert/
predicate, but outer joins require support for additional update/delete statements with the so-called statement
syntax built into the language. modifiers for changing their normal semantics [12].
• Support for period aggregates and period grouped Unfortunately, previous proposals contained no clear
queries that take into account application-time or sys- rules specifying the semantics of constructs prefixed
tem-time periods of rows. with these statement modifiers, so it was hard to figure
• Support for period UNION, INTERSECT and out the end result [9]. In contrast, SQL:2011 provides a
EXCEPT operators that take into account application- small set of syntactic extensions with clearly-specified
time or system-time periods of rows. scope and semantics.
• Support for period normalization that produces • In previous proposals, query expressions, constraint
semantically-equivalent minimal set of rows for a given definitions, and insert/update/delete statements
table by combining contiguous rows that have exactly expressed without the statement modifier prefixes were
the same values in non-period columns. assumed to operate only on the current rows. This
• Support for multiple application-time periods per applied to both transaction time tables and valid time
table. tables. While this made sense for transaction time
• Support for non-temporal periods. tables, it did not make much sense for valid time tables.
For instance, users were allowed to insert into valid time

42 SIGMOD Record, September 2012 (Vol. 41, No. 3)

tables only those rows whose valid time period started [7] Gregory Sannik, Fred Daniels, “Enabling the Tem-
with the current time. In fact, there was no way for users poral Data Warehouse”, September 2010, http://
to insert rows into valid time tables whose validity peri- www.teradata.com/white-papers/
ods were either in the past or in the future. In contrast, [8] Richard Snodgrass (Ed.), “The TSQL2 Temporal
query expressions, constraint definitions, and insert/ Query Language”, Kluwer Academic Publishers,
update/delete statements on application-time period 1995
tables in SQL:2011 operate on the entire table content [9] Hugh Darwen, C.J. Date, “An overview and Analy-
and follow the standard semantics. Also, SQL:2011 sis of Proposals Based on the TSQL2 Approach”, In
allows users to specify any time values they desire for Date on Database: Writings 2000-2006, C.J. Date,
the application-time period start and end columns as Apress, 2006, also avaliable in http://www.dcs.war-
part of the INSERT statement on application-time wick.ac.uk/~hugh/TTM/OnTSQL2.pdf
period tables. [10] ISO/IEC 9075-2:2011, Information technology—
• The previous proposals relied on adding special Database languages—SQL—Part 2: Foundation
syntax to the table definition for creating temporal (SQL/Foundation), 2011
tables (AS TRANSACTION TIME for transaction-time [11] James F. Allen, “Maintaining knowledge about
support and AS VALIDTIME for valid-time support). temporal intervals”, Communications of ACM, Vol.
Consequently, supporting additional periods in previous 26, No. 11, November 1983
approach would have required extending the table defi- [12] Michael Bohlen, Christian Jensen, Richard
nition syntax every time a new period was added. In Snodgrass, “Temporal Statement Modifiers”, ACM
contrast, supporting additional periods requires no new Trans. on Database Systems, Vol. 25, No. 4, Decem-
syntax in SQL:2011. ber 2000

4. Acknowledgements
The authors thank Fred Zemke and Matthias Nicola
for their valuable comments on the prior versions of this
article.

5. References
[1] Fred Zemke, “What’s new in SQL:2011”, SIGMOD
Record, Vol. 41, No. 1, March 2012, pp. 67-73,
http://www.sigmod.org/publications/sigmod-record/
1203/pdfs/10.industry.zemke.pdf/
[2] Yu Wu, Sushil Jajodia, X. Sean Wang, “Temporal
Database Bibliography Update”, In Temporal Data-
bases: Research and Practice, O. Etzion, S. Jajodia,
and S.Sripada, eds., Springer, 1998
[3] Richard Snodgrass, “Developing Time-Oriented
Database Applications in SQL”, Morgan Kauf-
mann, 1999
[4] C. J. Date, Hugh Darwen, Nikos A. Lorentzos,
“Temporal Data and the Relational Model”, Morgan
Kaufman, 2003
[5] Cynthia Saracco, Matthias Nicola, Lenisha Gandhi,
“A matter of time: Temporal data management in
DB2 10”, April 2012, http://www.ibm.com/devel-
operworks/data/library/techarticle/dm-
1204db2temporaldata/
[6] Kevin Jerrigan, “Oracle Total Recall with Oracle
Database 11g Release 2”, September 2009, http://
www.oracle.com/us/products/database/security/
total-recall-whitepaper-171749.pdf

SIGMOD Record, September 2012 (Vol. 41, No. 3) 43