Temporal Database Concept

Introduction

• Temporal databases, encompass all database applications that require some aspect of time when organizing their information.
• They provide a good example to illustrate the need for developing a set of unifying concepts for application developers to use.
• Temporal database applications have been developed since the early days of database usage.
• In creating these applications, it is mainly left to the application designers and developers to discover, design, program, and implement the temporal concepts they need.
• There are many examples of applications where some aspect of time is needed to maintain the information in a database.
• These include healthcare, where patient histories need to be maintained; insurance, where claims and accident histories are required as well as information about the times when insurance policies are in effect; reservation systems in general (hotel, airline, car rental, train, and so on), where information on the dates and times when reservations are in effect are required; scientific databases, where data collected from experiments includes the time when each data is measured; and so on.
• Even the two examples used in this book may be easily expanded Into temporal applications. 
• In the COMPANY database, we may wish to keep SALARY, JOB, and PROJECT histories on each employee. 
• In the UNIVERSITY database, Time is already included in the SEMESTER and YEAR of each SECTION of a COURSE, the grade history of a STUDENT, and the information on research grants.
• In fact, it is realistic to conclude that the majority of database applications have some temporal information.

Time Representation, Calendars,and Time Dimensions

• For temporal databases, time is considered to be an ordered sequence of points in some granularity that is determined by the application. 
• For example, suppose that some temporal application never requires time units that are less than one second.
• Then, each time point represents one second using this granularity. In reality, each second is a (short) time duration, not a point, since it may be further divided into Milliseconds, microseconds, and so on. 
• 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.
• Because there is no known beginning or ending of time, one needs a reference point from which to measure specific time points.  
• Various calendars are used by various cultures (such as gregorian (western), chinese, islamic, hindu, jewish, coptic, and So on) with different reference points. 
• A calendar organizes time into different time units for convenience. Most calendars group 60 seconds into a minute, 60 minutes into an hour, 24 hours into a day (based on the physical time of earth’s rotation around its axis), and 7 days into a week. 
• Further grouping of days into months and Months into years either follow solar or lunar natural phenomena, and are generally Irregular. 
• In the gregorian calendar, which is used in most western countries, days are grouped into months that are 28, 29, 30, or 31 days, and 12 months are grouped into a year. 
• Complex formulas are used to map the different time units to one another.

Event Information versus Duration (or State) Information

• A temporal database Will store information concerning when certain events occur, or when certain Facts are considered to be true. There are several different types of temporal information.
• Point events or facts are typically associated in the database with a single Time point in some granularity. For example, a bank deposit event may be associated With the timestamp when the deposit was made, or the total monthly sales of a Product (fact) may be associated with a particular month (say, february 2010).
• Note that even though such events or facts may have different granularities, each is still associated with a single time value in the database. This type of information is often represented as time series data as we will discuss in section 26.2.5. 
• Duration events Or facts, on the other hand, are associated with a specific time period in the database.
• 12 for example, an employee may have worked in a company from august 15, 2003 until november 20, 2008.
• A time period is represented by its start and end time points [START-TIME, ENDTIME].
• For example, the above period is represented as [2003-08-15, 2008-11-20].
• Such a time period is often interpreted to mean the set of all time points from start time to end-time, inclusive, in the specified granularity. 
• Hence, assuming day granularity, the period [2003-08-15, 2008-11-20] represents the set of all days from August 15, 2003, until November 20, 2008, inclusive.

Valid Time and Transaction Time Dimensions

• Given a particular event or fact that is associated with a particular time point or time period in the database, the association may be interpreted to mean different things. 
• The most natural interpretation is that the associated time is the time that the event occurred, or the period during which the fact was considered to be true in the real world. 
• If this interpretation is used, the associated time is often referred to as the valid time. 
• A temporal database using this interpretation is called a valid time database
• A different interpretation can be used, where the associated time refers to the time when the information was actually stored in the database; that is, it is the value of the system time clock when the information is valid in the system.
• In this case, the associated time is called the transaction time. 
• A temporal database using this interpretation is called a transaction time database.
• 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.

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.
• Consider the example of closing daily stock prices of a particular company on the 
• New York stock exchange. The granularity here is day, but the days that the stock market is open are known.
• Typical queries on time series involve temporal aggregation over higher granularity intervals—for example, finding the average or maximum weekly closing stock price or the maximum and minimum monthly closing stock price from the Daily information.
• As another example, consider the daily sales dollar amount at each store of a chain of stores owned by a particular company. Again, typical temporal aggregates would be retrieving the weekly, monthly, or yearly sales from the daily sales information (Using the sum aggregate function), or comparing same store monthly sales with previous monthly sales, and so on.