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

version of data warehouse), therefore, it
should be reconfigured to populate the new
version of the data warehouse.

the way in which schema sharing and changes
in dimension schema can be represented, while
modeling MVDW.
The size of the data warehouse can be reduced
by sharing schema between different versions.
Before describing a way of modeling versions, a
set of constructs that are used for modeling are
presented in Figure 6. Solid nodes (filled node or
colored node) are used to represent a fact table
with a label F vi , where F is the name of the fact
and vi is the identification number of the version
to which the Fact table belongs. In contrast, an
empty node (hollow node) is used to represent a
dimension table with label D y L z . p , where D y is the
name of the dimension and in L z , z is the level to
which the dimension table belongs. To represent
two tables at the same dimension level, p is an
integer value added to make each label unique.
Within a version, a straight line is used to
represent a relationship between dimension and
fact tables, whereas dotted lines (with arrows)
are used for relationships between tables across
the version. Furthermore, to clearly identify
schema-sharing tables, those are encircled by a
dotted rectangle.
For modeling MVDW, consider a root version
V0 of the DW at time T0 having fact table F v1
and dimensions {D1, D2… D5}. The details of
dimensions are as follows:
D1 = { D 1 L 1.0 }, D2 = { D 2 L 1.1 , D 2 L 2.0 ,
D 2 L 2.1 },
D3 = { D 3 L 1 , D 3 L 2 }, D4 = { D 4 L 1 },
D5 = { D 5 L 1 , D 5 L 2 } D6 = { D 6 L 1 , D 6 L 2 }
Assume that a business change occurs that ul-
timately triggers creation of a new version (V1.0)

ModelIng the MultIverSIon
dAtA WArehouSe

The versioning graph presented in the section
4.2 gives a high-level view of versions of data
warehouse and identifies relationships between
versions. However, the versioning graph doesn't
give detailed information about sharing dimen-
sions and facts between versions. In addition to
that, changes in dimensional schemas cannot be
represented by the versioning graph.
Modeling dimensional schemas of a multiver-
sion data warehouse addresses the problem of
specifying overtime changes in the data warehouse
due to evolution operations. It is also important
to note that modeling dimensional schemas of a
conventional data warehouse is neglected here
to keep the focus on modeling structural changes
and schema sharing between versions. Interested
readers may read (Tryfona, 1999) for more insight
into modeling of a dimensional schema.

Modeling Schema Sharing

Various approaches for modeling of a single
dimensional schema have been presented in the
literature (Tryfona, 1999. Feyer, 2002). However,
those approaches are not appropriate for modeling
multiple versions of a data warehouse, because
schema sharing and changes in dimensional sche-
mas are not included. In this section, we discuss

Figure 6. Modeling constructs