Temporality Types
They
are several ways of interpreting the time frame associated with the facts
contained in a temporal database. These interpretations are captured by several
temporality types.
Valid
time (VT)
specifies the period of time in which a fact is true in the modeled reality;
for example, it allows one to capture when a specific salary was paid to an
employee. The valid time is usually supplied by the user.
Transaction
time (TT)
indicates the period of time in which a fact is current in the database and may
be retrieved. The transaction time of a fact begins at the time when it is
inserted or updated and ends when the fact is deleted or updated. The
transaction time is generated by the database system.
Valid
time and transaction time can be combined to define bitemporal time (BT).
This indicates both when a fact is true in reality and when it is current in
the database.
In
many applications it is necessary to capture the time during which an object
exists. This is represented by the lifespan (LS) or existence time;
for example, it can be used to represent the duration of a project. The
lifespan of an object o may be seen as the valid time of the related
fact, “o exists.” Lifespan also applies to relationships, for example,
it may be used to capture the time during which an employee has worked for a
project. In addition to a lifespan, an object or relationship can also record a
transaction time,indicating the time when it is current in the database.
In addition, since data in data
warehouses is neither modified nor deleted,we proposed the loading time (LT),
which indicates the time since when thedata is current in a data warehouse.
This time can differ from the transaction time of the source systems owing to
the delay between the time when a change occurs in a source system and the time
when this change is integrated into a temporal data warehouse. The loading time
can help users to know the time since when an item of data has been available
in a data warehouse for analysis purposes.
Overview of the Model
The
MultiDim model allows users to determine which temporal data they need by
including in the schema the symbols of the corresponding temporality types. For
example, in the schema in Fig. users are not interested in keeping track of
changes to clients’ data; thus, this dimension does not include any temporal
support. On the other hand, changes in the values of measures and changes in
data related to products and stores are important for analysis purposes, as
indicated by the various temporality types included in the schema. the MultiDim
model allows both temporal and nontemporal attributes, levels, parent-child
relationships, hierarchies, and dimensions. The definitions of the nontemporal
elements of the model remain the same.
we
define a temporal level as a level for which the application needs to
store the time frame associated with its members. The schema in Fig includes
four temporal levels (as shown by the LS symbol next to the level name): Product,
Category, Store, and Sales district. This allows users to track changes in a
member as a whole, for example inserting or deleting a product or a category.
The usual nontemporal levels are called conventional levels e.g. Client.
A
temporal attribute is an attribute that keeps track of the changes in
its values and the time when they occur. For instance, the valid time support for
Size and Distributor in the Product level indicates that the history of changes
in these attributes will be kept. As in the spatial case, in our model we adopt
an orthogonal approach where a level may be temporal independently of the fact
that it has temporal attributes.
A
temporal parent-child relationship keeps track of the time frame associated
with the links relating a child and a parent member. For example, in Fig. The symbol LS in the relationship linking Product
and Category indicates that the evolution in time of the assignments of
products to categories will be stored.
Cardinalities
in
parent-child relationships constrain the minimum and the maximum number of
members in one level that can be related to a member in another level. Temporal
support for parent-child relationships leads to two interpretations of
cardinalities. The instant cardinality is valid at every time instant,
whereas the lifespan cardinality is valid over the entire member’s
lifespan. The instant cardinality is represented using the symbol for the
temporality type (for example, LS in Fig. next to the line for the parent-child
relationship, whereas the lifespan cardinality includes the symbol LS surrounded
by an ellipse. When the two cardinalities are the same, this is represented
using only one cardinality symbol. the instant cardinality between Store and Sales
district levels is one-to-many, while the lifespan cardinality is many-to-many.
These cardinalities indicate, in particular, that a store belongs to only one
sales district at any time instant, but may belong to many sales districts over
its lifespan, i.e., its assignment to sales districts may change. On the other
hand, the instant and lifespan cardinalities between the Product and Category levels
are both one-to-many. They indicate, in particular, that products may belong to
only one category over their lifespan.
We
define a temporal hierarchy as a hierarchy that has at least one temporal
level or one temporal parent-child relationship. Thus, temporal hierarchies can
combine temporal and nontemporal levels. Similarly, a temporal dimension is
a dimension that has at least one temporal hierarchy. The usual nontemporal
dimensions and hierarchies are called conventional dimensions and conventional
hierarchies.
A
temporal fact relationship is a fact relationship that requires a
temporal join between two or more temporal levels. This temporal join can be based
on various synchronization relationships: an icon in the fact relationship indicates
the synchronization relationship used for specifying the join. For example,the
temporal fact relationship Sales in Fig. relates two temporal levels: Product and
Store. The overlaps synchronization icon in the relationship indicates that
users focus their analysis on those products whose lifespan overlaps the
lifespan of their related store. If a synchronization icon is not included in a
fact relationship, there is no particular synchronization constraint in the
instances of that relationship. In our example, this could allow users to analyze
whether the exclusion of some products from stores affects sales.
