Difference (from revision 1 to 2)

Changed: 1c1

This page gives a general introduction to representing temporal information using the valid time temporal model. We first describe the representation of temporal information in general, and we follow this discussion by a more detailed description of how these concepts can be represented in the valid time model. {nid AON}
This page gives a general introduction to representing temporal information using the valid time temporal model. We first describe the representation of temporal information in general, and we follow this discussion by a more detailed description of how these concepts can be represented in the valid time model. {nid AON}

Added: 84a85,87

The smallest granularity in a system will be the granularity of the time-line clock
chronon. All other granularities will ultimately be described in terms of this granularity. {nid AQC}

Changed: 123,187c126

The relationship between granularities within a calendar is usually represented using a
lattice. Each connecting arrow in the lattice describes the mapping between the
granularities at each end of the arrow. {nid AP3}

Granularities are calendar-dependent but they may be related by a single multi-calendar
granularity lattice. In other words, different calendars may share the same granularities.
In some cases, we may wish to specify calendars that are tailored to particular domains.
For example, in the diabetes domain, we are frequently interested in the cycle of hours
within a day, and are less interested in absolute time. Similarly, for other domains, we
may be more concerned with the cycle of weeks within a month. {nid AP4}

= Representing Temporal Information {nid AP5} =

This section outlines an approach for the representation of some of the temporal concepts
that we have just discussed. {nid AP6}

== Instants {nid AP7} ==

An instant is a point on the time-line and may be modeled with an instant timestamp. For
example, the DATETIME data type in SQL can be used to hold an instant timestamp. {nid AP8}

== Periods {nid AP9} ==

We can model periods using a period timestamp. Each period timestamp is composed of
two instant timestamps, which are assumed to have the same granularity. This granularity
is also the granularity of the associated period. Null periods are allowed, so the start and
end timestamp may be equal. {nid APA}

== Intervals {nid APB} ==

Intervals are modeled by an interval timestamp. An interval timestamp is a count of
granules and is assumed to have a particular granularity. The count may be positive
(representing time heading into the future) or negative (representing time heading into the
past). {nid APC}

== Temporal Tables {nid APD} ==

Conceptually, we may represent a temporal table by adding a valid-time column to a non
temporal table. This column holds the set of valid periods for each tuple in the table.
For example, a temporal table representing a history of employees and their job titles
could look as follows:
Name Title ValidTime
Fred Mechanic {[June,10,1995-May,12,1996],
[Jan,1,1997-April,10,1997]}
Joe Mechanic [April,1,1994-February,12,1997]
Value-equivalent tuples are not allowed by the data model, so any rows with the same
non temporal information will automatically be coalesced by the system. Coalescing will
ensure that all overlapping or adjacent intervals for tuples with the same values are
merged and that suitable new intervals are generated.
The above representation is conceptual -it will probably not be the appropriate
representation at the physical database level. However, the above representation (or
something very close to it) should be what a user of the temporal query system sees. {nid APE}

== Granularity {nid APF} ==

In SQL, granularities are referenced when specifying the schema. In the SQL-92
standard, these are: DATE (year, month, day), TIME (hour, minute, second, and,
optionally, fractions of a second), TIMESTAMP (a DATE concatenated with a TIME),
INTERVAL (duration of time), TIME WITH TIME ZONE (a TIME concatenated with
an INTERVAL HOUR TO MINUTE), and TIMESTAMP WITH TIMEZONE. With all
but DATE one can specify the number of fractional digits. {nid APG}

The smallest granularity in a system will be the granularity of the time-line clock
chronon. All other granularities will ultimately be described in terms of this granularity.
As described above, a calendar is responsible for defining the granularities that it contains
As mentioned, a calendar is responsible for defining the granularities that it contains

Changed: 190c129

at different granularities in a single database is common. This mixing creates various
at different granularities is common. This mixing creates various

Changed: 199c138,140

We will return to these issues in a later section. {nid APN}
The relationship between granularities within a calendar is usually represented using a
lattice. Each connecting arrow in the lattice describes the mapping between the
granularities at each end of the arrow. {nid AP3}

Changed: 201c142,147

== Indeterminacy {nid APO} ==
Granularities are calendar-dependent but they may be related by a single multi-calendar
granularity lattice. In other words, different calendars may share the same granularities.
In some cases, we may wish to specify calendars that are tailored to particular domains.
For example, in the diabetes domain, we are frequently interested in the cycle of hours
within a day, and are less interested in absolute time. Similarly, for other domains, we
may be more concerned with the cycle of weeks within a month. {nid AP4}

Removed: 203,244d148

We would like the ability to capture the uncertainty associated with some temporal
information. A temporal uncertainty model to describe this uncertainty will depend on the
type of uncertainty we are trying to model. Often, the type of uncertainty that we have to
deal with typically involves events that are known to have happened – the exact time of
their occurrence is usually what is in question. A model that describes this type of
uncertainty is outlined by Curtis Dyreson and Richard Snodgrass in “Supporting Valid-
Time Indeterminacy” [5]. {nid APP}

This model represents an indeterminate instant with three components: a lower support,
an upper support, and a probability mass function (p.m.f.). While we may not know
exactly when the event occurred, we do know that it did not happen before the lower
support; similarly, we know that it did not happen after the upper support. The supports
have a particular granularity and represent the lower and upper bound on when an
indeterminate instant is known to have occurred, respectively. Between the supports lies a
period of indeterminacy, which identifies a set of possible instants in which the event
occurred. The p.m.f. describes the distribution of probabilities in this set of possible
instants. Periods and intervals may also be indeterminate and can be modeled using a
similar approach. {nid APQ}

We will consider indeterminacy in detail in a later section. {nid APR}

== Calendars {nid APS} ==

Calendars define granularities. The Gregorian calendar provided by SQL defines the
granularities of decades, years, months, fortnights, weeks, days, hours, minutes, seconds
and fractions of a second. {nid APT}

To support multiple coexisting calendars, we envision that a calendar will be defined in a
specification file. These specification files can be provided by a database vendor, third
party suppliers, local database administrators, or may perhaps be defined by the user.
The calendar specification file must provide a full definition of all the granularities it
contains. Each granularity will be described as a further partitioning of some other
granularity using either a regular or irregular mapping. Ultimately, the granularities will
map to the finest granularity provided by the DBMS, which will be the resolution of the
time-line clock. Anchor points must also be given for each granularity.
In essence, a calendar is a collection of mapping function that are to be linked with the
DBMS and the specification file.
If we are to have multiple coexisting calendars in a DMBS, we will quickly want a means
of converting a time representation in one calendar to a time representation in another.
We will go into further detail on this issue, in addition to discussing both granularity and
calendar representation, in later sections. {nid APU}

Changed: 251c155,156

from minutes to seconds to account for leap second insertions.
from minutes to seconds to account for leap second insertions. {nid AQD}

Changed: 255c160,161

associated calendar. However, in many cases this assumption proves to be false.
associated calendar. However, in many cases this assumption proves to be false. {nid AQE}

Changed: 262c168,169

anchor point would be the start of the year A.D. 1000.
anchor point would be the start of the year A.D. 1000. {nid AQF}

Changed: 265c172,173

finer granularity.
finer granularity. {nid AQG}

Changed: 269,272c177,181

approaches:
- Give a mismatched granularity error. Given that operations over different
granularities will be common, this solution is not useful.
- Perform the operation at the granularity of the first operand. Thus, the granularity of
approaches: {nid AQH}

* Give a mismatched granularity error. Given that operations over different
granularities will be common, this solution is not useful. {nid AQI}
* Perform the operation at the granularity of the first operand. Thus, the granularity of

Changed: 274,275c183,184

loss of symmetry in operations.
- Perform the operation at the finest granularity. All instants are thus converted to the
loss of symmetry in operations. {nid AQJ}
* Perform the operation at the finest granularity. All instants are thus converted to the

Changed: 279,280c188,189

indeterminacy into the result.
- Alternatively, we could perform the operation at the coarsest granularity. We thus
indeterminacy into the result. {nid AQK}
* Alternatively, we could perform the operation at the coarsest granularity. We thus

Changed: 283c192,193

coarser granularity.
coarser granularity. {nid AQL}

Changed: 288c198

== Scale {nid APX} ==
=== Scale {nid APX} ===

Changed: 295c205

=== Scaling from Fine to Coarse {nid APZ} ===
==== Scaling from Fine to Coarse {nid APZ} ====

Changed: 319c229

=== Scaling from Coarse to Fine {nid AQ6} ===
==== Scaling from Coarse to Fine {nid AQ6} ====