Database Reference
In-Depth Information
Attribute 'TOTAL_PRICE' in table
SALES added
temporary table. While loading a partial result,
data are transformed by conversion methods,
if needed, in order to form a consistent result.
Finally, the integrated result is returned to a user
by a query on the temporary table.
Notice that missing attributes used in the
SELECT, WHERE, GROUP BY, and HAVING
clauses prevent from the full integration of partial
results.
If attribute
a
i
used in the WHERE, GROUP BY,
and HAVING clauses is missing in DW versions
V
i
and
V
j
, then SVQs are not executed in these
versions. In these cases, a user is notified about
missing attributes by means of metadata that are
returned instead of query results. The reason for
such a behavior is to not return to a user data that
he/she is not requesting since excluding missing
attributes from these clauses changes the mean-
ing of a query. SVQs are executed only in these
DW versions where
a
i
exists or has its equivalent
attribute.
If attribute
a
i
used in the ORDER BY clause is
missing in DW versions
V
i
and
V
j
, then the attribute
is excluded from SVQs addressing
V
i
and
V
j
and
the SVQs are executed in their DW versions. The
returned results are not sorted by
a
i
and they are
augmented with metadata notifying a user about
missing attribute
a
i
.
If attribute
a
i
used in the SELECT clause is
missing in DW versions
V
i
and
V
j
, then the at-
tribute is excluded from SVQs addressing
V
i
and
V
j
and such modified SVQs are executed in their
DW versions.
Attributes dropped from tables in some DW
versions are handled in a similar way as added
attributes.
Missing Attributes in SELECT,
WHERE, GROUP BY, and HAVING
Let us assume that attribute
a
m
and
a
n
in fact table
F
are missing in DW versions
V
i
and
V
j
. Let us
further consider a MVQ that selects F.a
m
, F.a
n
,
F.a
o
, F.a
p
, ..., from versions
V
i
,
V
j
,
V
k
, and
V
m
. The
query will be decomposed into four SVQs. SVQs
addressing
V
i
and
V
j
will have attributes
a
m
and
a
n
removed from their SELECT clauses. Such
partial queries will not be integrated in the second
step as the structures of their results differ from
the structures of the results obtained by SVQs
addressing
V
k
and
V
m
.
Missing attributes
a
m
and
a
n
in DW versions
V
i
and
V
j
specified in WHERE, GROUP BY, and
HAVING cause that SVQs can be executed only
in these DW versions that contain
a
m
and
a
n
, i.e.,
V
k
and
V
m
. As a consequence, only the results of
SVQs from
V
k
and
V
m
will be integrated.
Integrating Results of SVQs
QUERYING METADATA IN
MULTIVERSION DATA WAREHOUSE
In order to provide a global view on analyzed
data, SVQs may be integrated into one consistent
result. The integration is done as follows. Firstly,
the system finds out a common set of attributes/
expressions used in the SELECT clause of SVQs.
Tables that changed their names and attributes that
changed their names and/or domains from version
to version are also included in the set. Secondly,
a temporary table is being created for holding
partial results. Next, partial queries are executed
and all obtained partial results are stored in the
With the support of the
MVDWQL
a user can ex-
plicitly query metadata for the purpose of analyz-
ing the change history of either the whole
MVDW
or some DW versions. The functionality of the
language allows to execute two types of queries,
namely: (1) a query searching for DW versions that
include an indicated schema object or a dimension
instance, and (2) a query retrieving the evolution
history of an indicated schema object or a dimension
Search WWH ::
Custom Search