Database Reference
In-Depth Information
In client-server scenarios where the query is generated on the client side, it is not
even necessary to send the schema back to the client, as it can be derived from the
client's query, i.e., we expect our approach to get an even higher data transfer rate.
5 Related Work
For a given SQL/XML query, our approach calculates the schema of the result docu-
ment as well as an SQL query that retrieves all the data that is needed to compute a
compressed representation of the result document. Then, both are used for computing
the compressed result document.
Approaches that also try to build a bridge from the relational world to the XML
world are the approaches [2], [3] that translate SQL queries into XQuery expressions
that query the same data or that provide SQL-based access to relational data via rela-
tional views over XML data [4]. The other direction of the bridge, i.e., XML views
over relational data is discussed in [5], [6], or storing XML data in form of relational
tables is discussed in [7], [8], [9].
The problem of deriving schema information not for a given query but for a collec-
tion of documents is discussed for DTDs in [10].
None of these approaches are being used for directly transforming SQL/XML que-
ries in such a way to SQL queries that the SQL query result can be used for generat-
ing compressed XML instead of generating XML. To the best of our knowledge, our
approach is the first that provides this property.
6 Conclusions
In this paper, we have presented an approach that allows generating a compressed
XML document directly as the result of an SQL/XML query that is applied to a rela-
tional database. In contrast to computing the uncompressed XML query result first
and compressing it as a second step, our approach yields the compressed data in less
time. In contrast to only creating the uncompressed XML document and sending it in
uncompressed format, creating the compressed XML data directly and sending it in
compressed format takes total times of 23% down to 12% of the time needed to create
and transfer the uncompressed XML depending on the available data rate.
As today only a few DBMSs (e.g. Oracle 11g and IBM DB2) support the evalua-
tion of SQL/XML queries, while the majority of DBMSs do not yet support
SQL/XML, a further advantage of our approach is that it requires only SQL support.
This means that in addition to DBMSs that support SQL/XML all other DBMSs that
only support SQL can be used to produce the compressed XML document as a result
to an SQL/XML query. Together with our XSDS decompressor, this technique can
even be used as a fairly fast substitute for an SQL/XML implementation that supports
a subset of SQL/XML, as our generation of compressed XML together with an addi-
tional decompression step using our XSDS decompressor at least for some SQL/XML
queries outperforms the DB2 and the Oracle SQL/XML implementation.
Our approach contains parts that are generic, while other parts are specific for the
XML compression approach being used. By changing the parts that are specific for
