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

of the data warehouse after time T1. Similarly,
after time T2, another version (V2.1) is created
from version V1.0. Also assume that after time T3
a third version (V3.2) is created from V2.1.
Figure 7 shows the way in which changes in
structure of dimensional schema can be modeled,
in the presence of overtime changes and evolving
requirements of users. The X-axis represents status
of data warehouse version with the passage of time
and Y-axis represents various dimension and fact
tables. Figure 7 also shows presence of version
V0 at time interval T 0 . At time T 1 version V1.0 is
generated, at T 2 version V2.1 is generated and at
T 3 version V3.2 is generated.
As described in the principles of creation of
versions in data warehouses in section 3.2, different
versions of the data warehouse can share dimension
and fact tables. Shared dimension and fact tables
are surrounded by square boxes, as shown above in
Figure 7 by dotted lines. Also, the label of shared
boxes is extended by adding identification of ver-
sions in curly brackets e.g. {V0, V1.0}.

For relationship between tables, a dotted line
starts from child version headed towards parent
version. For example, the dimension table D 3 L 1 and
D 3 L 2 is part of version V1.0. If shared dimension
table D 3 L 1 is related with dimension D 9 L 2.0 , the
relationship is represented by dotted line (called
relationship line) starting from version V1.0 to
V0. Otherwise, if fact table F v2 is related with
dimension D 14 L 1 and D 13 L 1.0 , the relationship is
represented by a dotted line (called relationship
line) starting from version V3.2 to V2.1.

Instance Sharing

Conventionally, the size of a data warehouse varies
from gigabytes to terabytes (Chaudhury, 1997).
Therefore, physically storing multiple copies of
each record is not practical because, it will im-
mensely increase the size of the data warehouse.
A solution to this problem is found by avoiding
physical storage of redundant data by implement-
ing data sharing techniques between versions.

Figure 7. Modeling schema sharing