Article:		Going Native: Making the Case for XML Databases
Subject:		XML data model vs. relational model
Date:		2005-04-01 22:55:46
From:		rpbourret
Response to: XML data model vs. relational model
There are actually a number of XML data models. For example, DOM, SAX, XPath 1.0, XQuery 1.0 / XPath 2.0, and the Infoset all explicitly or implicity define data models. What these all have in common is that they are ordered trees of nodes (elements, attributes, text, etc.) and scalar values. (The XQuery data model is actually an ordered forest.) Although it's not quite technically correct, it's easiest to think of the XML data model as a DOM tree. No markup in sight -- just an ordered hierarchy of nodes, with values at the leaves. There is no single XML data model used by all native XML databases. This is because most native XML databases predate XQuery and some even predate XPath. Consequently, many invented their own query languages and corresponding data models. Currently, the most common query language in native XML databases is XPath (with extensions for multi-document queries). In the future it will be XQuery. For information about the XQuery / XPath 2.0 data model, see http://www.w3.org/TR/xpath-datamodel/ As Michael noted, there isn't anything you can model with the XML data model but not the relational data model. In fact, there is a generic mapping from DTDs to relational schemas (see http://www.xml.com/lpt/a/2001/05/09/dtdtodbs.html). The only problem will occur with schemaless XML, and you can always map that to a generic set of tables (Elements, Attributes, etc.) So to quote Michael again, the problem is practical, not theoretical. For example, if you map the XHTML schema to a relational schema, the p element alone is mapped to 36 different tables. As you can imagine, reconstructing an XHTML document requires an impractical number of joins.

Previous Message

Up

Next Message

• XML data model vs. relational model
  2005-04-22 21:22:24 gtnicol [Reply]
  
  >So to quote Michael again, the problem is
  >practical, not theoretical. For example, if you map
  >the XHTML schema to a relational schema, the p >element alone is mapped to 36 different tables. As
  >you can imagine, reconstructing an XHTML document >requires an impractical number of joins.

  
  This is not strictly true... there are a number of ways of mapping XML onto a relational database that don't require joins... especially given that most real-world documents are not as deeply nested as people might think (typically 3-10 levels).

  
  Speaking as someone that has used XML/SGML databases under CMS systems for years (we have 2 XML databases), one of the main reasons I've seen for it is that real-world documents tend to be somewhat variable, even in very tightly constrained environments where DTD/Schema validation is required (such as the military). XML databases, for the most part tend to handle such variability well (especially those that are schema-independent in their storage). Typical RDBMS-based systems tend to be much more rigorous, and hence, less flexible (though that is not always the case).

  
  The other area where, for documents, XML helps, is with the combination of fulltext and structural queries. Given those capabilities, you can build fairly sophisticated hypertext applications, and also enable fine-grained reuse of content in ways that are difficult in most RDBMS-based systems. The tradeoff here is much like the tradeoff between tightly and loosely coupled distributed systems.

  
  In fact, looking at the list of deployments listed, I would say that for all of these, reuse and flexibility would be two of the reasons people used XML. I bet other factors, such as management paradigm, and ease of integration played a significant role as well.