Database Reference
In-Depth Information
To generate an XQuery that reflects the relationship between the structure of
the supermodel and the structure of the document, we order all the (root and
complex) elements that are gathered in
s.for
according to their hierarchical
structure in the source document (line 5 of the algorithm shown in Figure 5).
We differentiate between rootElements and complexElements, which correspond
to different constructs in the supermodel (lines 7-12) when generating the path
expression in the for clause. We assume in Figure 5 that the (variable) name of
aconstruct
c
queried can be obtained through
c.name
.
Using the algorithms presented, the XQueries posed over
S
2
that correspond
to the example queries
Q
1
,
Q
2
and
Q
3
are shown in Figure 6. The
let
and
return
clauses are omitted for XQueries
Q
2
and
Q
3
. As there are two alter-
natives for mapping
city
in the integration schema to
city
in
S
2
,namely,
capital_city/city
or
other_city/city
, two subqueries are to be evaluated
over the respective data source with schema
S
2
and their results unioned. Both
subqueries are shown in Figure 6.
4.2 SMql Query over Supermodel into SQL Query over Relational
Model
Based on the three parts of an SQL query, namely the
Select
,
From
and
Where
clauses, the following data structure is introduced to gather the information that
is needed for each of the three clauses.
A SQL query is a triple
<
select, from, where
>
,where
select
is a list of fully
qualified lexical/column names, either qualified with the name of the aggrega-
tion/table the lexical belongs to or with the corresponding variable name,
from
is a list of aggregations/tables, and
where
is a list of conjunctive predicates.
Lists support the operator
add
. As the correspondences between model specific
constructs and model generic constructs are trivial for relational data sources,
the rewriting algorithm is straightforward.
In the first step, a recursive algorithm (omitted here due to space constraints;
for the corresponding algorithm for XQuery see Algorithm 4) traverses the
SMql
algebra and places the appropriate information into the data structures corre-
sponding to each part of the SQL query, e.g., predicates of FILTER and JOIN
operators are added to s.where, and all lexicals in REDUCE are added to s.select.
In the second step of the query rewriting, the gathered information is trans-
lated into a string for evaluation. As this step is straightforward for SQL, the
algorithm is omitted here.
5 Related Work
Various contributions on query rewriting for data integration have been made
over the years (e.g., [11,14]). In addition, some of the model management plat-
forms have been extended to support query evaluation (e.g., Automed [7] and
GeRoMe [12]).
GeRoMe, utilises a role based metamodel in which multiple model-independent
roles can be attached to each model-specific schema element thereby specifying
