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 Valid Time Valid Time

Name  Department  Salary 
ID  Start 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
Georg
12 Research 10500 1991 INF
e
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 26.1, 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 26.7(a), 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 26.1). 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.