Database Reference
In-Depth Information
Fig. 2. Example schemas and queries in SMql
Table 2. SMql algebra
Operator
SCAN(Abstract
|
Aggregation
|
StructOfAttributes)
Collection
REDUCE(Collection,
{
Lexical
}
)
Collection
FILTER(Collection, Predicate)
Collection
JOIN(Left Collection, Right Collection, Predicate)
Collection
UNION(Left Collection, Right Collection) Collection
EvaluateSQL(SQLqueryString, Predicate, { tuple } ) →{ tuple }
EvaluateXQuery(XqueryString, Predicate, { tuple } ) →{ tuple }
and p is a conjunctive predicate. Figure 2 shows two simplified schemas, S 1 of a
relational data source and S 2 of an XSD data source and some example queries
in SMql . The figure also shows the corresponding constructs in the supermodel
for the two relational tables in S 1 , as well as the root element ( country )and
the complex elements ( capital_city , other_city , city )in S 2 .Thecolumns
in S 1 and the simple elements in S 2 all correspond to Lexical , but for clarity not
all those correspondences are shown in Figure 2.
SMql queries are translated into the algebra from Table 2 following standard
translation schemes [10]. For example, query Q 1 in Figure 2 is translated into RE-
DUCE( FILTER( SCAN(country), population > 5000000),
{
}
)
and query Q 2 is translated into REDUCE( JOIN( SCAN(country o), FILTER(
SCAN(city c), c.name = 'Manchester'), o.code = c.country),
name, code, capital
).
The UNION operator will be used later in the context of query unfolding whereas
EvaluateSQL and EvaluateXQuery will be used later in the context of evaluation
of the rewritten source-specific subqueries (see Section 4 for an example).
{
o.name, c.name
}
4 Query Rewriting
This section introduces the approach to rewriting a SMql query posed over con-
structs of the supermodel and expressed in the algebra shown in Table 2 into
potentially multiple SQL or XQuery queries, respectively, depending on the con-
structs which are queried and their respective sources. For example, if a SMql
 
Search WWH ::




Custom Search