url - Universität zu Lübeck

148 CHAPTER 8. KEYX IMPLEMENTATION DETAILS
a task of the XDBMS Infonyte DB so that the developer of an application has not
to regard any persistency aspects like invoking serializations, etc.
Compared to highly sophisticated commercial database products, Infonyte DB is a
rudimentary database management system. Infonyte DB does not offer advanced
features like multi-user control mechanisms or transactions. In particular, it
cannot be guaranteed that some stored XML data is always valid concerning a
given schema, because elements can be inserted or deleted in the DOM without
consistency controls. Validation is always performed on demand and then on
the whole XML data so that it is too expensive to validate the data after each
modification. Infonyte comes with no satisfying indexing approach; it supports
some structural queries in a rudimentary way. The performance measurements
of section 5.5 show that the query execution time of Infonyte DB without a KeyX
index can become very long. Infonyte offers no XML update language like XUPdate.
Therefore, all manipulations must be performed in a low level manner on
the DOM tree. Recapitulating, one can say that Infonyte’s state of development is
not comparable to commercial relational products, so a company typically would
not use it in productive environments. But this holds for most XML DBMS that
are often initiated as research projects. An exception could be Tamino from the
Software AG that is a fully commercial XDBMS. Anyhow, because Infonyte DB
offers all features required for KeyX and the Software AG published only very few
technical informations about Tamino the choice to use Infonyte DB was no fault.
KeyX uses the Infonyte DB interfaces DOM and XPath. The XPath engine is
used to evaluate queries when building an index or when no index is available for
processing a query. For a selected node in the DOM tree Infonyte can return a
unique id. The time to dereference an id is constant and not dependent on the
size of the XML data or the position of the element. Any XDBMS that offers these
two features may be used with the KeyX implementation in principle. The XPath
interface of the XDBMS is handed over to the database applications of the highest
layer with the difference that covered queries are executed upon an index. The
database application is not aware if an index is used or not because it still sends
XPath queries and gets XML nodes. This architecture makes it easy to integrate
an indexing system in existing applications. Therefore, the results of this thesis
may be used universally for native XDBML; they do not dependent on the specific
DBMS Infonyte DB. A block diagram of the KeyX system can be found in
figure 8.2.
The architecture consists mainly of three parts: the query engine with the query
optimizer as the central part, the ISP Tool that analyzes the workloads and optimizes
the index configuration and a collection of the XML data, the workload and
statistics. These data have to be stored persistently in order to survive system
restarts. In a realistic environment it makes sense to log the workload for several
weeks or months to get an impression of the typical usage of the database.
The workload is a compressed file logging all occurred database operations in a