Data Warehouse Maintenance, Evolution and Versioning - Data Warehousing Design and Advanced Engineering Applications - page 179

tions may take quite a long time. The versioning
approach allows multiversion queries, and data
does not have to be transformed when applying
modifications. On the other hand, when running a
multiversion query, data may have to be adapted,
which leads to worse performance, compared to
the evolutionary approach. Furthermore, keeping
track of past versions is a non-negligible data
management effort.

provide very little support for changing
structures.

Data warehouse maintenance mostly deals with
the third aspect, i.e. valid time of structure data.
Subsuming the above the following definition
can be given for data warehouse maintenance,
evolution and versioning:The process and meth-
odology of performing changes on the schema
and instance level to represent changes in the
data warehouse's application domain or require-
ments is called Data Warehouse Maintenance .
Data Warehouse Evolution is a form of data
warehouse maintenance where only the newest
data warehouse state is available. Data Warehouse
Versioning is a form of data warehouse mainte-
nance where all past versions of the data warehouse
are kept available. Dealing with changes on the
data level, mostly insertion of new data, is not
part of data warehouse maintenance, but part of
a data warehouse's normal operation. (Eder and
Wiggisser, 2009, p. 1)

Aspects of Time in the
Data Warehouse

Time is a key issue in data warehousing, because
when supporting the decision process, comput-
ing historical trends may be necessary (Rizzi and
Golfarelli, 2006). In data warehouses one can
distinguish three different kinds of time:

1. Valid Time of Cell Data: In a multidimen-

sional cube usually the Time dimension is
used to represent the history of changing
transaction data. Cell data, which is related
to a specific dimension member from the
time dimension is valid at the time point or
interval represented by that member.

THE COMET TEMPORAL
DATA WAREHOUSE

2. Transaction Time of Cell Data: Based on

the assumption of nonvolatility, for most
application the transaction time of cell
values, i.e. the time when data is current in
the data warehouse, is not considered to be
relevant. When this assumption is violated
and transaction data which is already stored
in the data warehouse is changed afterwards,
transaction time bay become an important
aspect, as it allows traceability for query
results (Rizzi and Golfarelli, 2006).

Eder and Koncilia (Eder & Koncilia, 2001; Eder,
Koncilia, & Morzy, 2002) suggest the COMET
Metamodel for temporal data warehouses. This
model is based on the multidimensional data
model. All elements (dimensions, categories,
dimension members, …) and relations between
them get assigned a timestamp [T s ; T e ] where T s
identifies the first point in time where the given
element is valid, and T e defines the last point in
time of the validity of the element. An ending
timestamp of NOW defines elements for which
the end of validity is yet unknown. Operations
for inserting, deleting, and updating structure
elements are provided, as well as operations for
changing hierarchical relations between these
elements, for instance creating a new aggregation
hierarchy. On the member level, also the complex

3. Valid Time of Structure Data: Data ware-

house structures need to be maintained.
Structure elements may be inserted, deleted
or changed. To be able to determine the data
warehouse's structure at a given point in time,
structures have to be assigned a valid time.
Today's data warehouse systems typically