RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Beyond Tables: Dealing with the Convergence of Relational and XML Data : Page 2

Developers are under increasing pressure to work with heterogeneous information. The advent of XML provided a data representation suitable for both regular (database tables) and irregular content, and was a significant step forward, but representation alone is not enough. We need a powerful standardized method for querying that data as well. XQuery fulfills that need.

Do We Really Need Another Query Language?
I think we do, and here's why. Put simply, working with XML using SQL and available SQL extensions imposes significant developer productivity constraints, forcing developers to think using two vastly different data models. Combining XQuery's ability to abstract any data source formatted as XML, and XQuery's highly optimized language and manipulative capabilities frees developers from the pain of data integration and lets them concentrate on building data-rich applications.

As recently as the SQL-99 specification, SQL was extended to permit support for structured data types. Although it remains possible that SQL could be extended further to meet many of the XQuery requirements, thus allowing enterprises to maintain their significant investment in SQL code in their deployed applications, that's unlikely to happen any time soon. Couple this fact with the following observations, and you begin to gain an understanding of why developers need XQuery:

  • Relational data can represent nested hierarchical XML data by using tables with structured types and foreign keys. To search an XML structure stored this way, it is necessary to know the specific key required to locate a specific data item. XML has a much less formal arrangement for data, one that does not require prior knowledge of where the data exists.
  • Relational data is regular and consistent, which allows the data to be described separately using metadata. XML data can be quite irregular but it is self-describing.
  • The result of querying relational data is presented in a table; however XQuery results are exclusively hierarchical.
  • Relational tables do not have any notion of ordering; XML documents regard ordering as a fundamental facet of the data description.
  • Traditional application development requires a significant investment in data integration time. Transposing developer cycles away from tackling any number of integration challenges using XQuery offers significant productivity boosts.
  • XQuery allows developers to work directly with XML, which exposes many developers to a new set of challenges.
  • XQuery was designed as separate language optimized to work with XML data rather than as an SQL extension.
XQuery Expressions
XQuery is not simply an XML flavor of SQL. Having discovered how XQuery came about, many readers are likely wondering what this new language can do. Here are a few highlights:

Fundamentally, XQuery is a declarative language that uses expressions as central components for assembling queries. Each query is a set of expressions that may be nested to assemble a desired result.

Developers who have worked with relational data before, most likely encountered JDBC or the ODBC API to channel SQL statements to your chosen RDBMS. In the following section, we introduce some fundamental concepts of XQuery and draw comparisons as to how they map to already familiar concepts in JDBC, ODBC or common languages such as Java or C.

  • Literal—a direct syntactic representation of an atomic value similar to a String object in the Java programming language or a source code representation of a value in C# such as an integer or string literal.
  • Function Call—a library method call in Java
  • Path Expression—a concept unique to XQuery, which is used to locate nodes on a given tree in an XML document. (A SQL developer might think in terms of a foreign key to express a specific table row.)
  • FLWOR Expressions—XQuery provides the ability to combine information from many sources, reshape the data, and present it as a result. FLWOR expressions (pronounced 'flower') stands for For, Let, Where, Order by, Return. These key XQuery expression clauses let you to specify a set of criteria to retrieve a desired set of information. In many respects, FLWOR expressions can be considered as equivalent to SQL SELECT...FROM...WHERE... statements, with the exception that FLWOR expressions are optimized to deal with XML data.
  • Conditional Expressions—Using a conditional expression permits expressions that use if...then...else... clauses familiar to developers in most languages. There are two ways to assemble a conditional expression in a typical JDBC application—either you can call a stored procedure through the CallableStatement interface to manipulate the data within the relational data store, or you factor out a number of result sets from SQL queries and apply the necessary conditions in Java. XQuery allows you to quickly and easily articulate conditional expressions.
  • Quantified Expression—In XQuery, there are two types of quantifiers to remember:
    1. Existential—An existential quantifier lets expression determine whether a sequence satisfies a particular result for each item in a result.
    2. Universal—A universal quantifier lets an expression determine whether every node in a sequence satisfies a particular result.
A JDBC application might typically contain a quantified expression in a stored procedure accessed through the CallableStatement interface. Typically the stored procedure is configured to return a Boolean value by applying a test between two or more criteria.

XQuery in a Nutshell
XQuery provides a flexible, well-rounded means to manipulate XML data. In the short term, relational data stores will continue to be the dominant data storage model given the widespread and considerable investment in established and highly optimized enterprise applications. But XML is here to stay, it is growing, and XQuery will let developers unlock its tremendous potential while leveraging the significant established base of relational data.

At the time of this article's publication, the W3C XQuery specification is poised to move forward to full "Recommendation" status. Codification of this standard will trigger significant activity in the data integration space, in particular in the area of unifying relational and XML data. Future iterations of major RDBMSs will see XQuery become an integral part of tomorrow's relational data stores. This presents the implicit advantage of surfacing relational data as XML and the provision of database-optimized XQuery engines for XML query processing. XQuery-enabled middle-tier components will quickly be able to leverage the database-level implementations while supplying the optimal integration end-point for an arbitrary set of data sources.

XML continues to find its way into more of today's applications, with developers finding new innovative applications for XML an effective data integration technology. Fortunately, the XQuery language is impartial as to where the XML to be manipulated is stored—leaving the relational data base investments secure. The power of the XQuery language and the importance of middle-tier XQuery implementations will result in significant productivity gains for developers of evolving and deployed applications alike.

Jonathan Bruce is XQuery Technology Evangelist for DataDirect Technologies and its parent company Progress Software Corporation. He is focused on advancing the XQuery and XQJ standards and driving the adoption of DataDirect's new XML query technologies. Jonathan joined DataDirect after seven years at Sun Microsystems where he served as the JDBC Specification Lead and Architect for the Java platform. A technical and specification architect with significant experience in leading industry standards such as Java, J2EE and SQL, he led four Java specification request efforts that have contributed to the J2SE and J2EE platforms. His background also includes business development, sales support as well as inbound and outbound licensing consulting for the Java platform and database-dependent components of Sun�s Java Enterprise System.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date