ADVANCED DBMS

ETCS-423

CASE STUDY - 2

TEMPORAL DATABASE CONCEPTS

Department of Computer Science and Engineering

(7th SEMESTER)

Bharati Vidyapeeth’s College of Engineering,

New Delhi

Submitted to Submitted By
Ms. Sakshi Jindal Anmol Saxena
65311502716
 1. INTRODUCTION

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. Assume we would like to store data about our employees
with respect to the real world. Then, the following table could result:

Emp ID Name Department Salary Valid Time Start Valid Time End
10 John Research 11000 1985 1990
10 John Sales 11000 1990 1993
10 John Sales 12000 1993 INF
11 Paul Research 10000 1988 1995
12 George Research 10500 1991 INF
13 Ringo Sales 15500 1988 INF

The above valid-time table stores the history of the employees with respect to the real world.
The attributes Valid Time Start and Valid Time End actually represent a time interval which
is closed at its lower and open at its upper bound. Thus, we see that during the time period
[1985 - 1990), employee John was working in the research department, having a salary of
11000. Then he changed to the sales department, still earning 11000. In 1993, he got a salary
raise to 12000. The upper bound INF denotes that the tuple is valid until further notice. Note
that it is now possible to store information about past states. We see that Paul was employed
from 1988 until 1995. In the corresponding non-temporal table, this information was
(physically) deleted when Paul left the company.
More specifically the temporal aspects usually include valid time, transaction time or decision
time

• 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.
• Decision time is the time period during which a fact stored in the database was decided to
be valid.

2. Different Forms of Temporal Databases

The two different notions of time - valid time and transaction time - allow the distinction of
different forms of temporal databases. A historical database stores data with respect to valid
time, a rollback database stores data with respect to transaction time. A bitemporal
database stores data with respect to both valid time and transaction time.

As we mentioned above, commercial DBMS are said to store only a single state of the real
world, usually the most recent state. Such databases usually are called snapshot databases. A
snapshot database in the context of valid time and transaction time is depicted in the following
picture:
 Fig. 1 represents valid time and transaction time

On the other hand, a bitemporal DBMS such as Time DB stores the history of data with respect
to both valid time and transaction time. Note that the history of when data was stored in the
database (transaction time) is limited to past and present database states, since it is managed by
the system directly which does not know anything about future states.

A table in the bitemporal relational DBMS Time DB may either be a snapshot table (storing
only current data), a valid-time table (storing when the data is valid wrt. the real world), a
transaction-time table (storing when the data was recorded in the database) or a bitemporal
table (storing both valid time and transaction time). An extended version of SQL allows to
specify which kind of table is needed when the table is created. Existing tables may also be
altered (schema versioning). Additionally, it supports temporal queries, temporal modification
statements and temporalconstraints.

The states stored in a bitemporal database are sketched in the picture below. Of course, a
temporal DBMS such as Time DB does not store each database state separately as depicted in
the picture below. It stores valid time and/or transaction time for each tuple, as described above.
 Fig. 2 Represents valid and transaction time

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

2.2 Bi-Temporal
A bi-temporal database has two axis of time.

• valid time.
• transaction time or decision time.

2.3 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.
 3. 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

4. Time Representation, Calendars, and Time Dimensions

Temporal database researchers have used the term chronon instead of point to describe this
minimal granularity for a particular application. The main consequence of choosing a minimum
granularity—say, one second—is that events occurring within the same second will be
considered to be simultaneous events, even though in reality they may not be. Other
interpretations can also be intended, but these are considered to be the most common ones, and
they are referred to as time dimensions. In some applications, only one of the dimensions is
needed and in other cases both time dimensions are required, in which case the temporal
database is called a bitemporal database. If other interpretations are intended for time, the
user can define the semantics and program the applications appropriately, and it is called
a user-defined time.

5. Incorporating Time in Relational Databases Using Tuple Versioning

Valid Time Relations. Let us now see how the different types of temporal data-bases may be
represented in the relational model. First, suppose that we would like to include the history of
changes as they occur in the real world. Consider again the database in Figure 3, and let us
assume that, for this application, the granularity is day. Then, we could convert the two
relations EMPLOYEE and DEPARTMENT into valid time relations by adding the
attributes Vst (Valid Start Time) and Vet (Valid End Time), whose data type is DATE in order
to provide day granularity. This is shown in Figure 3, where the relations have been
renamed EMP_VT and DEPT_VT, respectively.

Consider how the EMP_VT relation differs from the nontemporal EMPLOYEE relation
(Figure 3). In EMP_VT, each tuple V represents a version of an employee’s
 Fi

Fig. 3 Temporal databases

6. Incorporating Time in Object-Oriented Databases Using Attribute

Versioning
The object lifespan would also include both valid and transaction time dimensions. Therefore,
the full capabilities of bitemporal databases can be available with attribute versioning.
Mechanisms similar to those discussed earlier for updating tuple versions can be applied to
updating attribute versions.
class TEMPORAL_SALARY
{ attribute Date Valid_start_time;
attribute Date Valid_end_time;
attribute float Salary;
};
class TEMPORAL_DEPT
{ attribute Date Valid_start_time;
attribute Date Valid_end_time;
attribute DEPARTMENT_VT Dept;
};
class TEMPORAL_SUPERVISOR
{ attribute Date Valid_start_time;
attribute Date Valid_end_time;
attribute EMPLOYEE_VT Supervisor;
};
class TEMPORAL_LIFESPAN
{ attribute Date Valid_ start time;
attribute Date Valid end time;
};
class EMPLOYEE_VT
( extent EMPLOYEES )
{ attribute list<TEMPORAL_LIFESPAN> lifespan;
attribute string Name;
 attribute string Ssn;
attribute list<TEMPORAL_SALARY> Sal_history;
attribute list<TEMPORAL_DEPT> Dept_history;
attribute list <TEMPORAL_SUPERVISOR> Supervisor_history;
};

7. Temporal Querying Constructs and the TSQL2 Language

Finally, we give a brief overview of the TSQL2 query language, which extends SQL with
constructs for temporal databases. The main idea behind TSQL2 is to allow users to specify
whether a relation is nontemporal (that is, a standard SQL relation) or temporal. The CREATE
TABLE statement is extended with an optional AS clause to allow users to declare different
temporal options. The following options are avail-able:
<AS VALID STATE <GRANULARITY> (valid time relation with valid time period)
<AS VALID EVENT <GRANULARITY> (valid time relation with valid time point)

<AS TRANSACTION (transaction time relation with transaction time period)

<AS VALID STATE <GRANULARITY> AND TRANSACTION (bitemporal relation,

valid time period)

8. Time Series Data

Time series data is used very often in financial, sales, and economics applications. They involve
data values that are recorded according to a specific predefined sequence of time points.
Therefore, they are a special type of valid event data, where the event time points are
predetermined according to a fixed calendar.
More recently, some commercial DBMS packages are offering time series extensions, such as
the Oracle time cartridge and the time series data blade of Informix Universal Server. In
addition, the TSQL2 language provides some support for time series in the form of event tables.