Querying XML Views of Relational Data

1
Querying XML Views of Relational Data
Speaker Andrew Ellis
2
Contributions
1) A framework for processing XQuery queries over
XML views, and 2) A technique for
efficiently evaluating XML queries by
pushing down query computation to the relational
engine.
3
The problem XML - the standard data exchange
format for Internet-based business
applications. Existing business data - currently
stored in relational database systems.
A solution XML views are a way of providing an
alternative, application-specific view of
relational data - allows business partners, etc
to access relational data as though it were in an
industry-standard XML format.
4
Approaches to Generating XML Views -
Materialise the XML view on request and return an
XML document of the results of a query. -Too
expensive, may not need to materialise the whole
view eg partner may only be interested in one
particular 'item' (out of say,
1000's), materialising all the 'items' in the
relational database into an XML view
would be wasteful - unnecessary
computation. -Better, support queries over XML
views (subject of this paper)
5
Paper considers views and queries specified using
XQuery, W3C standardized, to focus on 1) The
design of a general framework for processing
arbitrarily complex queries (with features such
as -nested expressions and -nested order)
2) Performance issues - techniques for
evaluating queries such as, - XML view
compostion mechanism, which eliminates the
construction of all intermediate XML
fragments that don't appear in
the final query result, - "Computation
push-down", performance-enhancing
technique that pushes all data-intensive and
memory intensive computation in
a query down to the relational
database engine.
6

• Most commercial database systems provide a way to
  materialize XML views, however, most don't
  support queries over views
• -Microsoft's SQL Server does have limited
  support but the queries are
• specified in XPath, which is a subset
  of XQuery (for example, XPath
• doesn't support joins whereas XQuery
  does..)
• SilkRoute is a related system that supports
  queries over XML views but the authors'
  contribution
• -supports a more powerful query facility based
  on XQuery,
• -SilkRoute's view composition mechanism
  produces SQL queries
• with redundant predicates and joins,
• -uses a complete view composition technique
  that produces minimal
• SQL queries,
• -provides a more general computation push-down
  mechanism that
• takes into account the greater flexibility
  of XQuery,
• -unlike SilkRoute, it uses an internal XML
  query model that naturally
• extends the relational model.

7
High-level query processing architecture
8
XPERANTO automatically generates a default XML
view, a low-level view that users can define
their own views on top of (using XQuery). The
advantage is that a standard XML query language
is used to create and query views rather than
some proprietary language to create views (as is
the case in other approaches)
9
Creating a user-defined view (with an XQuery FLWR
expression)..
10
The result..
Querying the user-defined view..
11
Query Processing Architecture
12
Query Processing Components
13
Query Parsing

• Intermediate query representation model, needs
  to be-
• -powerful enough to capture the full generality
  of a
• sophisticated query language (such as
  XQuery)
• -amenable to a translation to SQL

14
Query Parsing

• Intermediate query representation model, needs
  to be-
• -powerful enough to capture the full generality
  of a
• sophisticated query language (such as
  XQuery)
• -amenable to a translation to SQL

...XQGM -an extension of QGM (SQL internal
query representation used in commercial
dbs's) -also borrows from work on XML query
algebras
15
View graph (in detail) and summary of XQGM
operators.
16
Query graph
17
View composition
The authors' have developed a complete set of
composition rules involving XQGM functions that
can be used to remove XML navigation operations.
18
The advantages of eliminating navigational
operations are that -intermediate XML fragments
(that don't appear in the final result) are
not constructed eg, say you select the 'item's
in 'order' elements, the construction of
the order element is removed (as it is
not required to be materialized in the
final result' -query rewrite transformations
such as predicates and joins can pushed down
to the relational engine (next module) once
navigation has been removed
19
(No Transcript)
20
Computation Push-down
Goal to push all data and memory intensice
operations down into the relational engine as an
efficient SQL query
Query Decorrelation
Complex expressions in XQuery are represented
using correlations. It has been shown that
executing XML queries as correlated queries over
relational db's leads to poor performance. Therefo
re, query decorrelation is a necessary step for
efficient execution.
21
Tagger Pull-up
When producing the relational content the "Sorted
outer union" SQL query is one of the most
efficient and stable techniques for this
purpose -however, generation from XQGM graph is
complicated as tagger and SQL operations
are mixed -therefore, need to be seperated
before the sorted outer union query can
be generated -ie. tagger pull-up Push
relational opertations to the bottom of the
graph -gt convert to SQL, send to database Pull
XML construction (tagging) to the top by repeated
tagger pull-up transformations -gt convert to
"tagger run-time" graph, send to tagger run-time
22
Implementation Authors' used Java to implement
the techniques as part of XPERANTO middle-ware
system. By using JDBC to connect to a relational
dbs, the implementation works on top of most
commercial database systems including DB2,
Oracle, Microsoft SQL Server. Performance -Query
Compilation Time the time spent on parsing the
query, performing view compsotiion, generating
the SQL query and tagger run-time graph -Query
execution time the time spent executing the SQL
query and tagging the results
23
Results Queries considered up to 4 views, where
each view nests 3 relational talbes
-compilation time always less than 0.5
seconds eg 12 relational tables through 4 XML
views took 450ms and less time to
compile queries that access fewer views.
-therefore, small compile-time overhead but
offset by performance gains proposed in the
paper by "many orders of magnitude" Conclusion Pa
per has focused on evaluation of complex nested
XML queries and described a general
framework. -a view composition mechanism that
eliminates the construction of
intermediate fragments that don't appear in the
final result -a computation pushdown mechanism
that allows all data and memory intensive
computation to be pushed down to the
underlying relational
engine as a query...
24
However, certain XML queries cannot be directly
pushed down, -meta-data queries (eg column and
table na,es) although higher-order
operators can be provided in the
middleware. -those that perform user-defined
operations on intermediate XML
fragments, the solution is to add
primitves to construct fragments inside the
relational engine
The End