From Conventional to Multiversion Data Warehouse - Evolving Application Domains of Data Warehousing and Mining - page 46

certain period of time. The status of version
depends upon validity time of the change
that brought the version. Therefore, the va-
lidity time of a version depends upon the
period for which the change is valid for the
business. If status of a version is 'not val-
id', it can not be used for analysis and deci-
sion support purposes, whereas if the status
of a version is 'valid', it can be used for
analysis and decision support purposes.
◦

a new version of the data warehouse is also
created.

• Principle 6: A version of the data ware-

house represents decision-support data
between two real-world events. A data
warehouse stores decision support data
(Chaudhuri, 1997), whereas in the MVDW
each version of the data warehouse repre-
sents a state of business at a certain time
period. The state of business is valid for
a certain period and, with the creation of
another version, the validity of the previ-
ous version expires. So, each version of the
MVDW represents decision-support data
between two real-world events.

Practical guideline: The label of a
version should also include status of
the version. This can be done by add-
ing a bit to version-label. Value 1 of
the status bit shows that the version is
valid and value 0 shows that the ver-
sion is not valid. levels of Abstraction in the MvdW

• Principle 4: Versions of a data warehouse

share their data and schema with other
versions. Each version of the data ware-
house consists of a schema version and an
instance version (Bebel, 2004). The schema
version is the description of the structure of
the version, in the form of dimensions and
facts, whereas an instance version contains
information about events (see section 5.1
and 5.2 for details about data sharing and
schema sharing respectively). The purpose
of dividing a version into schema version
and instance version is to keep the size of
the data warehouse conveniently small.
◦

Each version of the multiversion data warehouse
consists of a schema version and an instance ver-
sion (Wrembel, 2005a). For each schema version,
if every instance-version is stored separately,
the size of the data warehouse may increase im-
mensely. Therefore, in order to reduce the size of
the data warehouse, versions are urged to share
data-instance by using a data sharing scheme
(Morzy, 2004). Data sharing schemes reduce
the size of the data warehouse by binding data-
instances with multiple versions, in this way the
common data is shared between versions.
Figure 2 shows different levels of abstraction
in the MVDW. The levels are: abstract level,
concrete level and physical level. These levels are
defined according to the information details which
each level provides: a) the abstract-level con-
tains information about high-level relationships
(parent-child relationships) between versions;
b) the concrete-level contains information about
versioning and data sharing between versions;
c) the physical level contains information about
physical storage of data.

Practical guideline: The size of a data
warehouse can be reduced by binding
instance versions with several sche-
ma versions and vice versa.

• Principle 5: The process of versioning is

continued as long as changes in a business
are originated i.e. operational sources
are evolved. The purpose of versioning is
to keep the data warehouse in consistent
states along with keeping track of histori-
cal records. Therefore, for each business
change that evolves the operational source,