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

Case 1: Reclassifying Level Instance 3. Executing SVQs: Every SVQ i constructed

in step 2 is executed in its own DW version
V i . Let us consider the MVQ given below that com-

putes net and gross total sales of products in DW
versions fromApril ( R_April ) until May ( R_May ).
Notice that the DW versions are selected by means
of using their validity times. Recall that in May
porotherm bricks were reclassified to 22% VAT
category and the information about this reclassi-
fication is stored in a dedicated dictionary table.

4. Returning SVQ results: The results of

singleversion queries obtained in step 3 are
returned and presented to a user separately.
Additionally, every result is annotated with:
(1) an information about a DW version the
result was obtained from, (2) metadata about
schema (e.g., attribute/table renaming, at-
tribute domain modification) and dimension
instance changes (e.g., reclassifying, split-
ting, or merging level instances) between
adjacent DW versions addressed by the
MVQ.

SELECT sum(sa.amount *
pr.item_price * vc.vat_value),
sum(sa.amount * pr.item_price),
pr.name product
FROM sales sa, products pr,
vat_categories vc
WHERE sa.prod_id=pr.prod_id
AND pr.cat_id=vc.cat_id
GROUP BY pr.name
VERSION FROM '01-04-2004'
to '30-05-2004'

5. Integrating SVQ results: Results of single-

version queries obtained in step 3 may be in
some cases integrated into one consistent set
that is represented as if it was stored in a DW
version specified by a user. It must be stressed
that in many cases such an integration will
not be possible since DW versions may differ
with respect to their schemas and structures
of dimension instances (Morzy & Wrembel,
2004). The integration of SVQ results will be
possible if a MVQ addresses attributes that
are present (or have equivalent attributes) in
all queried DW versions and if there exist
conversion methods between adjacent DW
versions (if such conversions are needed).
Integrating results obtained by SVQs is de-
fined by including in a MVQ the MERGE
INTO VID i clause, where VID i denotes the
identifier of a DW version whose schema
version will be used as a destination schema
for all the obtained results of SVQs.

During a parsing phase, the query is decom-
posed into two SVQs: one for version R_April and
one for R_May . Next, the two SVQs are executed
in their proper DW versions. After executing
the SVQs, the result of SVQ addressing version
R_May is augmented and returned to a user with
metadata describing changes in the structure of the
Product dimension instance made in R_May , as
shown below. This way, a sales analyst will know
that a gross sales increase from April to May was
at least partially caused by VAT increase.

Reclassified key [br1(porotherm) ->
vc7(VAT 7%)] to
[br1(porotherm)) -> vc22(VAT 22%)]
in table PRODUCTS

Querying Heterogeneous
DW Versions

In this section we will illustrate how a MVQ is
executed on heterogeneous DW versions. Five
typical cases will be considered.