On Querying Data and Metadata in Multiversion Data Warehouse - Data Warehousing Design and Advanced Engineering Applications - page 211

Figure 2. The example schema of a data warehouse on sales of products

a level instance, reclassifying a level instance,
merging n instances of a given level into a new
instance of the same level, splitting an instance
of a given level into n new instances of the same
level.
In order to illustrate some of the version
change operations let us consider a DW schema
from Figure 2. In this schema, the central Sales
fact table references via foreign keys three level
tables, namely Products (in dimension Product ),
Time (in dimension Time ), and Shops (in dimen-
sion Location ).
Case 1: Reclassifying level instances. Let us
assume that initially, in April 2004, in real ver-
sion denoted as R_April , there existed 3 shops
(instances of the Shops level table), namely ShopA ,
ShopB , and ShopC . These shops were selling
porotherm bricks (the instance of the Products
level table) with 7% of VAT (the instance of the
Categories level table). Let us further assume
that in May, porotherm bricks were reclassified
to 22% VAT category. This reclassification was
reflected in a new real DW version, denoted as
R_May . The reclassification was also registered

in a dedicated dictionary table storing mappings
between new and old level instances.
Case 2: Merging or splitting level instances.
Let us assume that in June, shops ShopA and ShopC
were merged into one shop ShopAC in a new real
DW version R_June . Similarly as in Case 1, map-
pings between shops in DW versions R_May and
R_June are stored in a dedicated dictionary table.
For more advanced splitting or merging opera-
tions it will be necessary to provide backward and
forward conversion methods for converting fact
records from an old to a new DW version. If such
methods are explicitly implemented and provided
by a DW user/administrator, then their names are
registered in a dedicated dictionary table.
Splitting level instances is handled in a similar
way as merging, by storing appropriate records
in a dedicated dictionary table.
Case 3: Different table names. In this case, a
table (either fact or level) in a parent DW version
and its equivalent table in a child DW version dif-
fer only with respect to their names. The change
of a fact table and a level table name is registered
in a dedicated dictionary table.