XML Database Products:

XML-Enabled Databases

Copyright 2000-2010 by Ronald Bourret

WARNING!

This list has not been updated since roughly 2010. As a result, information may be out of date and products may no longer be available. If you are interested in a product whose link does not work, search for it on the Web, as product pages frequently change and products/companies are frequently sold.

Overview

XML-enabled databases contain extensions for transferring data between XML documents and their own data structures. They are used by data-centric applications, except when the database also supports native XML storage. (The difference between XML-enabled and native storage is that XML- enabled storage uses schema-specific structures that must be mapped to the XML document at design time. Native XML storage uses generic structures that can contain any XML document. For more information, see the overview in XML Database Products: Native XML Databases.)

Products

Access 2007
Developer: Microsoft
URL: http://office.microsoft.com/en-us/access/HA101656301033.aspx
License: Commercial
Database type: Relational
Entry last updated: December, 2008

Access 2007 can import data from an XML document and export data to an XML document through its External Data tab. When importing data, you can choose to import only the structure or both the structure and data of an XML document. You can also create a table based on an XML Schema. When exporting data, you can choose to export only the structure or both the structure and data of a table. Database structure is exported as an XML Schema, which can be embedded in the XML document or in a separate document.

It appears that a table-based mapping is used to map between the XML schema and the database schema, and that element type names must match table and column names. (Attributes are ignored.) The document can apparently contain data from multiple tables, but it appears that this must all be at the same level, rather than deeply nested.

The ability to import and export XML data is also available in Visual Basic, with the ImportXML and ExportXML functions.

Earlier versions of Access (Access 2002 and Access 2003) have similar functionality.
Cache
Developer: InterSystems Corp.
URL: http://www.intersyste ms.com/cache/technology/components/xml/index.html
License: Commercial
Database type: Post-relational
Entry last updated: March, 2004

Cache is a "post-relational" database that stores data in multi-dimensional arrays and provides SQL, object-oriented, and multi-dimensional access to that data.

Cache supports XML in three ways. First, it provides an implementation of XML data binding, which uses the object-oriented view of the data. This contains tools for creating DTDs and XML Schemas from classes stored in Cache and for creating classes from XML Schemas. Data can then be transferred between XML documents and objects stored in the database. Second, methods on any class stored in Cache can be exposed as Web services. Third, Cache's Web application server (Cache Server Pages) can use the data binding functionality of Cache classes to expose data as XML over the Web.
DB2
Developer: IBM
URL: http://www.ibm.com/software/data/db2/
http://www.ibm.com/software/data/d b2/extenders/netsearch/
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0409cline/
License: Commercial
Database type: Relational, native XML
Entry last updated: March, 2007

DB2 version 9 supports XML in the base DB2 product, in the Net Search Extender, and in its Web Services Object Runtime Framework for DB2 (DB2 WORF). DB2 Express-C is a free version of DB2 version 9 that includes full XML support.

XML support in DB2 itself (known as pureXML) consists of native XML storage, XQuery, the publishing functions in SQL/XML (XMLELEMENT, XMLATTRIBUTE, XMLFOREST, XMLAGG, etc.), various other SQL/XML functions (XMLVALIDATE, XMLQUERY, XMLEXISTS, XMLCAST, etc.), and a decomposition engine. Native XML storage is used to store columns whose type is XML and is implemented through a proprietary, hierarchical storage mechanism. XML values are indexed by identifying the nodes to be indexed (using a subset of XPath) and specifying whether they are to be indexed as strings, numeric values, dates, or timestamps.

XML values can be queried with XQuery, which can be used as a standalone query language or called from SQL statements with the SQL/XML XMLQUERY function. XML values can also be used as a source of tabular data for SQL statements via the SQL/XML XMLTABLE function. Relational values can be queried with XQuery by first constructing an XML view of the data with the SQL/XML publishing functions, then querying the view with XQuery. Node-level updates are supported through a stored procedure that uses a path expression to identify the nodes to be updated and an XML value (element, attribute, etc.) to specify the new value.

The decomposition engine in DB2 is used to extract values from an XML document and store them in columns in relational tables. Values are transferred according to mappings defined by annotations in XML Schema documents. These annotations support object-relational mappings, with some additional capabilities, such as mapping multiple elements or attributes to the same table/column or mapping a single element or attribute to more than one table/column. Additional features include support for user-defined functions to modify values before insertion and conditional expressions to insert rows only if their values meet certain criteria.

Other XML support in DB2 includes a repository for managing XML Schemas to be used for validation and document decomposition, use of DTDs for resolving external entities and retrieving default values (but not for validation), and access to XML values through a variety of APIs, including JDBC 4.0, SQLJ, .NET, CLI, embedded SQL, and PHP.

The DB2 Net Search Extender contains a variety of search technologies, such as fuzzy searches, synonym searches, and searches by sentence or paragraph. It can be used when an XML document is stored in a single column and is XML-aware to the extent that searches can be limited to specific sections of XML documents, identified by their paths.

DB2 WORF allows users to define Web services through DADX documents. DADX documents extend the functionality of DAD documents (as used in the XML Extender -- see below) and describe how a Web service accesses data in the database. Supported functionality includes storing and retrieving documents with the XML Extender, executing SQL queries, and calling stored procedures. DB2 WORF can also generate WSDL documents from DADX documents.

Earlier versions of DB2 support the SQL/XML publishing functions and the XML Extender. The XML Extender can store XML documents in a single column as character data, extracting values into "side tables", which can then be queried with SQL statements. It can also decompose documents using a proprietary, XML-based mapping language called DAD (Data Access Definition). DAD supports object-relational mappings for transferring data to and from the database and a template-based language with embedded SELECT statements for transferring data from the database to XML. The XML Extender also supports MQSeries, validation, and XSLT.
eXtremeDB
Developer: McObject LLC
URL: http://www.mcobject.com/standardedition.shtml#eXtremeDB%20XML%20Extensions
License: Commercial
Database type: Object-oriented
Entry last updated: June, 2005

eXtremeDB is an object-oriented in-memory database. It supports a standard navigational API, as well as being able being able to generate an application-specific API from a database schema. An SQL implementation is available as an add-on. eXtremeDB is available in three versions: a standard version (which is available for conventional or shared memory), a single-threaded version, and a high-availability version. Transaction logging is available as an add-on.

eXtremeDB supports XML through XML data binding. From a database schema, it can generate methods to create new objects from XML documents, serialize existing objects as XML documents, and update existing objects from XML documents. In addition, it can generate XML Schema documents for the generated XML documents. The mapping from objects to an XML Schema was "developed in accordance with the W3C SOAP encoding recommendations" so that serialized objects can be used inside SOAP messages.
FileMaker
Developer: FileMaker
URL: http://www.filemaker.com/help/12-Import%20export32.html
License: Commercial
Database type: FileMaker
Entry last updated: December, 2008

FileMaker can export data as XML using one of two pre-defined XML schemas:

  • The FMPDSORESULT schema uses field names as element names, although the results of repeating and portal fields are wrapped in <DATA> tags. (A portal field apparently links to another data record, like a foreign key in a relational database.)

  • The FMPXMLRESULT schema is more generic, returning first a database schema, then the data wrapped in <ROW>, <COL>, and <DATA> tags. The metadata can then be used to transform the actual data. In addition, the query can specify the stylesheet to be used; a processing instruction referencing this stylesheet is placed in the returned document.

FileMaker can also import data, using the FMPXMLRESULT schema. Data from the XML document can be inserted into the database or used to update existing records.
FoxPro
Developer: Microsoft
URL: http://msdn.microsoft.com/en-us/library/we9s91f8.aspx
License: Commercial
Database type: Relational
Entry last updated: April, 2002

Visual FoxPro has three methods for transferring data between an XML document and a FoxPro table: CURSORTOXML, XMLTOCURSOR, and XMLUPDATEGRAM. CURSORTOXML and XMLTOCURSOR transfer data between a FoxPro cursor or table and an XML document using a table-based mapping. Column data can be represented either as attributes or as child elements. If an XML Schema is present, FoxPro determines the mapping from the schema. Otherwise, it makes two passes through the XML document -- one to determine the structure of the document and construct the mapping, and one to transfer the data. When transferring data from the database to XML, FoxPro can generate an inline schema describing the data.

XMLUPDATEGRAM generates an XML updategram from tables and cursors in the current session that have buffered changes. The updategram represents the before and after conditions of the table or cursor and can be used to propagate changes, such as to COM controls or other products (like SQL Server) that understand updategrams.
Informix
Developer: IBM
URL: http://www- 01.ibm.com/software/data/informix/ids/
http://www.ibm.com/software/data/infor mix/blades/web/
http://www.ibm.com/developerworks/db2/zones/informix/library/techarticle/0303cline/0303cline. html
License: Commercial
Database type: Relational
Entry last updated: December, 2008

Informix supports XML through the Web DataBlade, which allows Informix to act as a Web application server. XML documents are written as templates with special tags that the Web DataBlade executes. The MISQL tag executes an SQL statement. The template can specify where to put the results of a SELECT statement in the final XML document, or output the results using a table-based mapping.

The Web DataBlade supports most major Web server APIs.
Matisse
Developer: Matisse Software
URL: http://www.matisse.com/product_information/
License: Commercial
Database type: Object-oriented
Entry last updated: December, 2008

Matisse is an object-oriented database with support for a number of languages, including Java, C#, C/C++, Visual Basic, Delphi, Eiffel, Smalltalk, Perl, Python and PHP. Matisse also supports queries in SQL 99, which is available through JDBC and ODBC. (Of interest, SQL can be used to enforce the referential integrity of objects.)

XML is supported through XML data binding, in which complex elements are mapped to objects. The XML schema must closely match the object schema -- for example, it appears that names must match exactly -- although some deviations are allowed. For example, a child element with no corresponding property in the database is ignored when importing data from XML into the database.

When importing XML data into the database, the user can choose to use the XML data to create new objects in the database or update existing objects. An optional processing instruction and optional Matisse-specific attributes in the XML document control how the data is imported:

  • The processing instruction can specify whether to ignore the root element. This is useful when an XML document contains elements corresponding to more than one object. For example, if the root element is Employees and this contains multiple Employee elements, ignoring the root element allows Matisse to convert each Employee element into an Employee object, but not create an Employees object.

  • The processing instruction can also specify which object property is to be used as a primary key for the object. This is used to identify objects to be updated, as well as to identify the primary key in relationships between objects.

  • When an XML document contains relationships between objects (such as through the nesting of objects), a special attribute (MtRelationship) must be used to specify the relationship between each pair of objects. A second attribute (MtAction) specifies how that relationship is to be handled in the database during import. For example, this can specify whether to replace or delete an existing relationship, or add to the list of existing relationships.

When exporting data, users can export the entire database, or identify the objects to be exported through a SQL SELECT statement or by object ID. Export options include whether to export object IDs, whether to store binary data (such as images) in a separate document or the XML document, and whether to split the data across multiple XML documents.

Exported data uses object and property names as element type names. It uses the MtBasicType attribute to identify the data type of each element and the oid attribute to include object IDs. The XML document created when exporting data is flat. That is, all elements that correspond to objects are children of the root element. Relationships between objects are specified through MtRelationship and oid attributes.

Importing and exporting data can be performed by a command line utility or through a C API. In addition, Matisse has a command line utility for importing data from a single XML document into multiple databases.

Matisse also includes a simple API for manipulating XML documents. This API contains classes corresponding to elements, attributes, and relationships, and has functions for opening and closing XML documents and finding the next sibling of a given element.
MonetDB/SQL
Developer: CWI Database Group
URL: http://monetdb.cwi.nl/SQL/index.html
License: Open Source
Database type: Relational
Entry last updated: June, 2010

MonetDB is a database built on a proprietary data store. The data store vertically fragments data, storing data in Binary Association Tables (BATs); each BAT holds the data for a single column. BATs are designed to be held in main memory to increase query speed. The data store is accessed with the MonetDB Assembly Language (MAL). Because queries are compiled into MAL instructions, MonetDB is able to support multiple query languages. Currently, it supports SQL (MonetDB/SQL) and XQuery (MonetDB/XQuery).

MonetDB/SQL supports "major parts" of SQL/XML, including the XML data type, publishing functions, and schema registration. The XML data type is implemented using the string data type; it does not use the XML storage found in MonetDB/XQuery. XML data can be inserted directly into an XML column. It can also be shredded on input. By default, shredding appears to use a strict object-relational mapping; a simple scheme that maps a complex element to a table and simple child elements to columns is also available.

MonetDB/SQL relies on libxml2 for much of its XML functionality, including XPath support.

MonetDB/XQuery supports native XML storage and XQuery. For more information, click here.
MySQL
Developer: Sun Microsystems
URL: http://dev.mysql.com/doc/refman/5.1/en/xml-functions.html
License: Open Source
Database type: Relational
Entry last updated: December, 2008

MySQL supports XML through the mysql and mysqldump utilities, which use a table-based mapping to return the results of a SELECT statement or entire tables as XML, and the ExtractValue and UpdateXML functions in SQL. Because MySQL does not have a dedicated XML data type, XML values are stored as text.

ExtractValue accepts an XML value and an XPath expression. It returns the first text child of each element identified by the XPath expression. If the XPath expression identifies multiple elements, the text children are concatenated into a single, space-delimited string.

UpdateXML accepts an original XML value, an XPath expression, and a new XML value. It uses the XPath expression to identify a section of the original XML value. If the XPath expression identifies a single section -- that is, it returns a single node -- it replaces this section with the new XML value and returns the entire modified value. If the XPath expression returns multiple nodes or no nodes, UpdateXML returns the original XML value.
Objectivity/DB
Developer: Objectivity
URL: http://www.objectivity.com/pages/object ivity/xml.asp
License: Commercial
Database type: Object-oriented
Entry last updated: February, 2002

From the Web site:

"The Objectivity XML Interface Tool supports export of objects from the latest version of Objectivity/DB (Release 6) in XML format and import of XML formatted data into Objectivity DB. Objectivity will provide open source for the XML Interface Tool free of charge to its customer base."
OpenInsight
Developer: Revelation Software
URL: http://www.revelation.com/Revelation.nsf/
1f484fef89cd63e1852569c900787d0e/be0c2876a6f1056b85256dc500587dd5?OpenDocument
License: Commercial
Database type: Multi-valued
Entry last updated: January, 2003

OpenInsight is a development environment that can access data in its own "native tables", as well as Oracle, Lotus Notes, and ODBC and OLE/DB databases. The native tables, which are the same as those used by the DOS-based Advanced Revelation development environment, are a multi-valued database. It appears that XML support is limited to data stored in the native tables.

The mapping between XML documents and native tables tables appears to be table-based, in which a single document can contain multiple rows from the same table. Because columns in the native tables can be multi-valued, child elements in the XML document can occur multiple times. It also appears that only child elements (and not attributes) are supported. Users can map XML documents to the database in one of two ways. Either they can map individual child elements to individual columns, or they can map the entire document to a single column and map child elements to calculated columns.

OpenInsight can retrieve data from the database in three ways. First, it can execute a query and return the data as XML. Second, it can execute XPath queries against the database, presumably viewing the database as a set of virtual XML documents defined by a particular mapping. Third, it can retrieve data from specific columns in a particular row according to the element types to which those columns have been mapped.

An XML Schema is required to store data from an XML document in the database. (DTDs are not supported.) OpenInsight can generate an XML Schema for a given table.

OpenInsight includes GUI-based tools for importing XML documents into native tables, retrieving the result of queries as XML, viewing data stored in the database as XML, and executing XPath queries against the database.
Oracle
Developer: Oracle
URL: http://www.oracle.co m/technology/products/database/oracle11g/index.html
http://www.oracle. com/technology/tech/xml/xmldb/Current/xmldb_11g_twp.pdf
License: Commercial
Database type: Relational, native XML
Entry last updated: December, 2008

Oracle 11g provides support for an XML data type, SQL/XML, XQuery, XSLT, the DOM, XML indexes, the XML DB Repository, and XML Schemas. Oracle 10g Express Edition is a free version of Oracle that includes full XML support; see below for the differences in XML support between Oracle 10g and Oracle 11g.

XML support starts with the XMLType data type, which implements the XML data type defined by SQL/XML. Data in XMLType columns can be stored in one of three ways:

  • Object-relational storage. In object-relational storage, XML documents are shredded into or constructed from data in relational columns. The mapping between XML documents and relational data is defined with an annotated XML Schema. Annotations can be made by the user or generated automatically. Annotating schemas by hand generally results in more efficient mappings and also allows users to create XML "views" over existing relational data. In either case, when the schema is registered with the database, the database automatically creates any tables and columns needed to store documents conforming to the schema. Unlike most software that uses an object-relational mapping to store XML in relational tables, Oracle can round-trip XML documents at the level of the DOM. To do this, it uses hidden columns to store information that is not directly modeled by SQL, such as sibling order, processing instructions, and comments.

  • Binary XML storage. Binary XML storage uses a post-parse binary format -- that is, the document is parsed at insert time and a binary representation of it is constructed and stored in the database. This appears to be stored as a BLOB, but the exact storage mechanism is not clear.

  • CLOB storage. The XML document is stored in a CLOB column.

Regardless of which storage option is chosen, application code is the same. However, changing from one storage type to the other requires a database export and import. In addition, there are a number of significant differences between the storage mechanisms. For example:

  • CLOB storage round trips documents exactly, while object-relational and binary XML storage round trips documents at the level of the DOM.
  • Binary XML and CLOB storage can store any document, while object-relational storage can only store documents that conform to a particular XML Schema.
  • Object-relational and binary XML storage can often perform node-level updates, while CLOB storage always performs document-level updates.
  • CLOB storage has fewer indexing options and may be significantly slower to query than object- relational and binary XML storage.

XMLType columns can be constrained by an XML Schema. Multiple schemas can be used to constrain a column using binary XML storage, while only one schema can be used to constrain a column using CLOB or object-relational storage. In addition to limiting the documents that can be stored in the column to those that conform to the schema, schema constraints allow the query engine to optimize queries based on the information in the schema.

XMLType columns can be indexed in one of four ways. First, when object-relational storage is used, the columns to which the XML elements and attributes are mapped can be indexed using conventional B-tree indexes. Second, XMLIndex indexes can be constructed over XML values stored in binary XML or CLOB storage. These index paths, values, and order information. By default, XMLIndexes index the entire document. However, they can be constrained to index a specified set of paths, or the entire document except a specified set of paths. In addition, XMLIndex maintenance can be deferred to increase update performance. Third, function-based indexes can be used over any XML values. These use pre-defined XPath queries to identify values in the XML document to be indexed and are (apparently) evaluated by matching XPath expressions in queries to those used to define the index. Finally, Oracle Text indexes provide full-text indexing of the values in elements and attributes.

XML values can be queried with XQuery, which is called from SQL statements with the SQL/XML XMLQUERY function. XML values can be used as a source of tabular data for SQL statements via the SQL/XML XMLTABLE function and as a source of boolean values via the SQL/XML XMLEXISTS function. Updates are performed via proprietary SQL functions for inserting, appending, and deleting nodes as well as updating node values. These identify nodes by XPath expressions. Oracle also defines the XQuery ora:contains function and the SQL contains function for performing full-text searches over values in XML documents. Both of these functions use Oracle Text indexes if they are available.

Relational values can be used to construct XML values via the SQL/XML publishing functions (XMLELEMENT, XMLATTRIBUTE, XMLFOREST, XMLAGG, etc.) They can also be queried with XQuery by first constructing an XML view of the data, then querying the view with XQuery. Views can be constructed with the SQL/XML publishing functions, an annotated XML Schema, or the proprietary ora:view function in XQuery, which (apparently) uses the table-based mapping defined by SQL/XML to map a table to a virtual XML document.

Oracle includes two implementations of XQuery: a mid-tier implementation and an implementation that is part of the database engine. The mid-tier implementation is commonly used to query individual XML values, such as XML messages, while the engine implementation is optimized for querying values stored in the database. The engine implementation attempts to rewrite both XPath and XQuery expressions as SQL statements. This is possible only when the XML value is stored using object- relational storage or the expression can be resolved by querying an index. Otherwise, the query is evaluated directly. XML values stored in binary XML storage can be queried by querying XMLIndex indexes, function-based indexes, or using a streaming XPath implementation that scans the binary XML data. XML values stored in CLOB storage can be queried by querying XMLIndex indexes or by parsing the XML, building a DOM tree, and querying the DOM tree; the latter method can be "very expensive".

Oracle also features the XML DB Repository, which provides a file-system like view over objects in the database. Although designed specifically for accessing XML values, the XML DB Repository can be used to access any object stored in the database. Objects are assigned a path and corresponding URL and can be accessed via HTTP, WebDAV, and FTP, as well as JDBC, PL/SQL, OCI, and ODP.NET. (SQL- based access uses the exists_path and under_path operators to query the RESOURCE_VIEW and PATH_VIEW views of the tables describing the repository.) In addition, the repository maintains system- defined metadata for each object (owner, creation date, etc.) and optional user-defined metadata in the form of an XML document, as well as providing versioning, access control lists, and hierarchical indexes for optimizing repository access.

The support described above is for Oracle 11g. The major XML feature added in Oracle 11g is binary XML storage. The major XML features added in Oracle 10g release 2 are XQuery support and XMLIndex indexes. Most of the other features have been supported since Oracle 9i release 2. Oracle 8i and Oracle 9i release 1 support the XML SQL Utility for Java, the Internet File System (iFS) (which provides functionality similar to the XML Repository), and searching XML documents stored as CLOBs with Oracle Intermedia XML Search. In addition, Oracle 9i release 1 supports the XMLType data type (stored as a CLOB) and XPath searches over XMLType columns.
Orient ODBMS
Developer: Orient Technologies
URL: http://www.orientechnologies.com/cms/?Solutions:Orient_ODBMS
License: Open Source
Database type: Object-oriented
Entry last updated: January, 2009

Orient ODBMS is an object-oriented database with support for C++ and Java. It includes Java tools for exporting data as an XML document and importing data from an XML document. The export tool can export data from the entire database, a particular class, or that result from a query. It appears that the XML schema must be an exact mapping of the object schema.
PostgreSQL
Developer: PostgreSQL Global Development Group
URL: http://www.postgresql.org/docs/8.2/static/datatype-xml.html
http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/xml2/README.xml2?rev=1.7
http://www.throwingbeans.org/postgresql _and_xml.html
License: Open Source
Database type: Relational
Entry last updated: December, 2006

PostgreSQL provides functions for executing for XPath queries and XSLT processing over XML values, as well as checking if an XML value is well-formed. XML values can be values stored in character (CHAR, VARCHAR, CLOB, etc.) columns or passed as character input values.

There are a number of XPath functions. The xpath_string, xpath_bool, and xpath_number functions execute an XPath query and return the result as a string, boolean, or floating point number. These can be used, for example, in a select list or a WHERE clause. The xpath_nodeset function executes an XPath query and returns the value as a string; it optionally accepts the name of a root element and an element to wrap each value in the node set returned by the query. The xpath_list function is similar, except that it returns values separated by a user-specified separator, such as a comma. Finally, the xpath_table function accepts the name of a table, column, and key column, as well as a list of XPath queries and criteria to be used in a WHERE clause. It returns a table (specified in an AS clause) that uses the primary key and has one column for each XPath query; this can be used in the FROM clause of another query.

There is a single XSLT function, xslt_process, which accepts an XML value (or the URL of an XML document), an XSLT stylesheet (or the URL of an XSLT stylesheet), and an optional set of parameters. It returns the result of applying the stylesheet to the XML value.

In addition to the functions described above, Pavel Stehule has written a patch supporting the SQL/XML publishing functions (XMLELEMENT, XMLFOREST, etc.). It is based on the CString type and "hasn't high quality, but can be useful for testing functionality."
RDM Embedded
Developer: Raima, Inc.
URL: http://www.raima.com/products/rdm-embedded/
License: Commercial
Database type: Network, relational
Entry last updated: January, 2009

RDM Embedded is "a high-performance, real-time, small footprint embedded database library... [It has] ... support for both disk based and in-memory tables [and has] a high level data definition language, native support for C arrays and structures, multi-user access, [and ] fully ACID transaction[s]." It supports the relational and network data models.

RDM Embedded supports XML import and export using a direct mapping between XML and the network data model schema. The mapping is performed as follows:

  • The root element's name is the database name.
  • Each record is mapped to an element whose name is the record name.
  • Record fields are mapped to child elements of the record element.
  • Fields that are structures are mapped to a child element whose name is the structure name and whose children correspond to the fields in the structure.
  • Array fields are mapped to repeated child elements.
  • Binary data is output using Base64.

Relationships between records in RDM Embedded are represented by "sets", which are a list of all the member records that belong to a particular owner record. For example, suppose there is a relationship between a sales order record and sales order line number records. This would be represented by a set whose owner is the sales order record and whose members are the line number records. Sets are implemented as linked lists. The head of the list points to the owner record and the other members of the list point to the member records.

Sets are mapped to XML by including a child element in each element corresponding to a member record. This element -- which we will call the pointer element -- points to the element of the corresponding owner record. In our sales order example, each line number element would have a pointer element child that points to the sales order element. If the owner record has a primary key, then the pointer element's name is the name of the primary key field; its value is the primary key value. If the owner record does not have a primary key, then the pointer element's name is ROWID; its value is the ROWID (internal database ID) of the owner record. All pointer elements have an attribute named "set", whose value is the name of the set that describes the relationship.

The XML import and XML export functions can be run from a command line utility or called through C/C++ and Java APIs. The import utility and import API can both import data from an XML document into the database. The import API also supports callback functions for custom data conversion and custom record handling. (The default record handling behavior is to insert the record into the database; a custom record handling function could, for example, use the record to update existing data.)

The export utility and export API can both export data from the database to an XML document. The export API exports a single record at a time as XML. This allows the calling application to control which records as exported. The export utility can export the entire database, a single table, or the result of a SELECT statement as XML. The export utility and export API can both export a database schema as an XML Schema or DTD. The export API can also export record schemas as an XML Schema or DTD.
RDM Server
Developer: Raima, Inc.
URL: http://www.raima.com/products/rdm- server/
License: Commercial
Database type: Network, relational
Entry last updated: January, 2009

RDM Server is "an embeddable database management system employing a client/server architecture". It supports the relational and network data models.

RDM Server supports XML import and export using a table-based mapping. Users can specify whether to export data as child elements or attributes. The root element is named BIRDSTEP-SQL. The next level of elements, which correspond to rows of data, can be named ROW or the table name. Lower level elements (or attributes of row elements) can be column names or COLUMN-n, where n is the column number. Other options include how to handle NULL data and whether to generate a DTD or XML Schema.
Sentences
Developer: Lazy Software, Ltd.
URL: http://www.lazysoft.com/technology_sentence s.htm
License: Free
Database type: Associative
Entry last updated: January, 2009

Sentences is a database that uses the associative data model, which is similar to RDF. It consists of entities and associations. Entities have an identifier, a type, and a name. For example, an entity's type might be "airline" and its name might be "ABC Airlines". Associations have an identifier for themselves and identifiers for the association's source, verb, and target. For example, an association's source might be the airline entity "ABC Airlines", its verb might be "flight number", and its target might be the value "181". Another association might use the previous association as its source, the verb "landed", and the "airport" entity whose name is "SFO" as its target. In other words, it might provide the information that ABC Airlines flight 181 has landed in San Francisco.

Queries in Sentences are trees of conditions. For example, if we want to know what flights have landed in San Francisco, we start with an airline entity, then choose the flight number association; this restricts our query to airline flights (as opposed to airline customers, pilots, employees, and so on). We then choose the landed association, and then restrict the target of this association to "SFO".

Sentences provides support for XML in several ways: it can export a Sentences database schema as XML (presumably using Sentences-specific markup), generate a DTD from a query, export the result of a query as an XML document, and import data from an XML document.

When exporting data, Sentences creates elements that correspond to entities and associations; associations are modeled as children of entity elements. For example, in the example above, the airline would be modeled with an element named airline. The flight number association would be modeled as a child element named flight_number with a value of 181.

Sentences can also export two types of identifiers. Element identifiers are ID attributes used to identify individual elements. These are used with IDREF attributes to eliminate data redundancy. For example, if multiple flights land in San Francisco, all of them could use IDREF attributes that refer to the landed_in element whose value is "SFO". The second type of identifier is Sentences' internal IDs, which identify individual entities and associations. These allow applications to retrieve data as XML, modify it, and return it to the database.

When importing data, the XML document must conform to the DTD of a particular Sentences query; the query is used to map data in the XML document to the database. (In particular, Sentences cannot import data from arbitrary XML documents.) If the XML document uses Sentences IDs, these identify the individual entities and associations to be modified. If Sentences IDs are not used, data is identified by entity type and name, or by association source, verb, and target.

By default, Sentences will check if a particular entity or association exists in the database. If it does, Sentences will update it; if it does not, Sentences will create the entity or association. Entity or association elements can contain action attributes that specify different actions. The other actions are to always create a new entity or association, to update an existing entity or association and fail if it does not exist, and to delete an existing entity or association.

SQL Server
Developer: Microsoft
URL: http://www.microsoft.com/sqlserve r/2008/en/us/default.aspx
http://msdn.microsoft.com/en- us/library/ms345117.aspx
http://msdn.microsoft.com/en- us/library/aa286527.aspx
License: Commercial
Database type: Relational, native XML
Entry last updated: December, 2008

SQL Server 2008 provides supports XML in a number of ways: the XML data type, the FOR XML clause in SELECT statements, the OPENXML clause, XQuery, and SQLXML. SQL Server 2008 Express is a free version of SQL Server 2008 that includes full XML support.

The XML data type is a first class data type that follows the specifications in ISO SQL-2003 (SQL/XML). This allows instances to be either well-formed XML documents or to be a forest of element, text, comment, and processing instruction nodes; the latter matches the content of an element and is used for handling document fragments. The XML data type may be used as a column, parameter, or variable data type. It has a modify() method that is used in UPDATE statements and uses a proprietary language to insert, delete, or modify nodes.

XML values are stored as BLOBs, using a proprietary binary format that is optimized for parsing. For faster access, they can also be indexed in several ways. A "primary" index is a table that can store one node per row (similar to mapping a DOM tree to a single table). "Secondary" indexes are relational indexes built on the "primary" index table. These can be used to optimize searches along a particular path, for particular values along a known path, and for particular values on unknown paths. In addition, full-text indexes can be built directly over XML columns. These index tokens in text nodes and ignore attribute values and markup. They can be used for full-text searches in SQL (the CONTAINS functions) or XQuery (the fn:contains function).

XML values can be constrained by an XML Schema collection, which contains one or more schemas. These are usually related to each other, such as by using <xs:import>. Which schema is used depends on the namespace of the root element(s) of an XML value. (Because of the one-to-one relationship between namespaces and schemas, each schema in a collection must have a different target namespace. As a result, different versions of the same schema cannot use the same namespace.) Schemas provide type information that is used to optimize queries and storage, as well as to validate XML values during insertion or modification.

SQL Server adds two clauses to SQL for working with XML: FOR XML and OPENXML. The FOR XML clause specifies how the result of a SELECT statement is mapped to XML. The TYPE directive (FOR XML TYPE) specifies whether values are returned as the XML or VARCHAR data type. (Remember that the XML data type contains a binary representation of the XML value; VARCHAR values contain the string form of XML.) Returning values using the XML data type allows SELECT ... FOR XML statements to be nested; the XML value returned by a nested statement is treated as a child node in the XML value constructed by the parent statement. A ROOT directive specifies a root node in which to return the other elements.

The FOR XML clause has four modes, each of which maps the result set in different ways:

  • RAW mode models the result set as a table. One element is returned for each row. This contains either attributes or child elements for each column.

  • PATH mode is the same as RAW mode except that column aliases contain path expressions that specify how to return column values relative to the row element. For example, the alias "Address/@Street" will create an Address child of the row element and return the column value as the Street attribute of this child. Many (most?) desired XML documents can be constructed using nested SELECT ... FOR XML statements and either RAW or PATH mode.

  • AUTO mode is also similar to RAW mode except that, when the SELECT statement joins two or more tables, it attempts to construct a deeply nested XML document from the results. That is, the elements for child tables are nested inside the elements for parent tables. This requires the result set to contain values that uniquely identify each row in each table. Without such values, it is not possible to determine when to construct a new parent element in each parent-child relationship.

  • EXPLICIT mode uses SELECT statements that are UNIONed together. The result sets for each SELECT statement contain the number that identifies that SELECT statement, as well as the number that identifies its parent SELECT statement. The results of each SELECT statement are returned as "tabular" XML, with one element for each row and child elements or attributes for each column. Each row element is placed beneath the element for the corresponding row in the parent table. EXPLICIT mode is largely obsolete; it has been replaced by PATH mode and nested SELECT ... FOR XML statements.

The OPENXML clause performs the opposite function of the SELECT ... FOR XML statement. That is, it constructs relational data (in the form of a result set) from an XML document instead of constructing XML values from relational data. OpenXML accepts an XPath query that specifies the set of elements that correspond to rows. It can then retrieve column values for each row in one of three ways: from child elements, from attributes, or from XPath queries that are relative to the row element. A WITH clause allows the user to specify the schema (column name and data type) of the result set.

OpenXML can be used wherever a rowset provider, such as a table or view name, can be used. For example, an application that normally uses relational data could use it in the FROM clause of a SELECT statement to retrieve data from an XML document as a result set. Or it could be used in the FROM clause of an INSERT INTO table SELECT ... statement to extract data from an XML document and insert it into a table.

SQL Server supports XQuery through methods on the XML data type:

  • query() executes an XQuery expression and returns the results as an XML value.
  • value() executes an XQuery expression and returns a scalar value.
  • exist() checks if an XQuery expression returns a non-empty sequence.
  • nodes() returns a sequence of XML values that can be iterated over.

It also supports two proprietary XQuery functions -- sql:variable and sql:column -- to allow users to use SQL variable and column values in XQuery expressions.

In addition to the server-side functionality described above, SQLXML is a client-side utility (ADO and .NET) that transfers data between XML documents and the database. This can be downloaded separately; it is not clear if it is shipped with SQL Server as well. For more information, click here.

The description above applies to SQL Server 2008 and SQL Server 2005. (SQL Server 2008 has more better XML Schema and XQuery support and minor improvements in the ability to modify XML values.) SQL Server 2000 supports the FOR XML RAW, AUTO, and EXPLICIT clauses, the OPENXML clause, and SQLXML; it does not support the XML data type, XQuery, the PATH clause, the TYPE directive, or the ability to nest SELECT ... FOR XML statements.
Sybase ASE 15.0
Developer: Sybase
URL: http://www.sybase .com/products/databasemanagement/adaptiveserverenterprise
http://infocent er.sybase.com/help/topic/com.sybase.dc30020_1251/pdf/xmlb.pdf
License: Commercial
Database type: Relational
Entry last updated: January, 2009

Sybase Adaptiver Server Enterprise (ASE) 15.0 can store XML documents either as text or in a proprietary binary format, which contains both a binary representation of the document and an index of the document. (The xmlparse function is used to create the binary form of a document.) Binary documents can (apparently) be used only with the xmlextract function (see below). As a general rule, operations on binary documents will be faster than operations on text documents.

Text documents can be stored in text or binary columns; binary documents must be stored in binary columns. Because a binary column can contain both text and binary documents, the xmlrepresentation function can be used to determine if a given document is a text document or a binary document.

XML documents can be queried with the xmlextract and xmltest functions. These accept a document argument (such as the name of a column containing XML documents) and a query. The xmlextract function can operate on binary or text documents; xmltest can operate only on text documents. Queries are written in a subset of XPath 1.0. xmlextract returns the result of the query. xmltest returns true if the result was the Boolean value true or a non-empty sequence; it returns false if the result was the Boolean value false or an empty sequence.

Sybase ASE does not support partial updates of XML documents. Instead, the entire document must be replaced, such as through an SQL UPDATE statement, or by deleting and reinserting the document.

Sybase ASE can return relational data as XML using the SELECT ... FOR XML statement. This returns relational data using a table-based mapping. Users can specify whether to return values as child elements or attributes, whether to include a root element, the name of the root element (the default is resultset), and the name of row elements (the default is row). Results can be returned as a single document or one row at a time.

SELECT ... FOR XML statements can be used in subqueries. For example, by using a SELECT ... FOR XML subquery in an xmlextract function, it is possible to execute an XPath query against relational data. Note, however, that SELECT ... FOR XML subqueries cannot be used in SELECT ... FOR XML statements, which would have allowed users to build deeply nested XML documents.

There are two other forms of the SELECT ... FOR XML statement. SELECT ... FOR XML SCHEMA returns an XML Schema document that describes the XML document returned by a SELECT ... FOR XML statement. SELECT ... FOR XML ALL returns a single XML document that contains the DTD (as PCDATA in an element), the XML Schema, and the data itself.

Sybase ASE also includes a number of Java functions for working with XML:

  • forxmlj, forxmldtdj, and forxmlschemaj provide the same functionality as the SELECT ... FOR XML statement; these can be used in places that a SELECT statement cannot be used, such as in an INSERT statement VALUE list. The forxmlallj stored procedure provides the same functionality as the SELECT ... FOR XML ALL statement.

  • forxmlmultiplej accepts a query that returns multiple result sets. It returns these as a single XML document, which presumably uses a table-based mapping.

  • forsqlcreatej accepts an XML Schema for a document of the type returned by SELECT ... FOR XML. It returns a CREATE TABLE statement that can be used to create the corresponding relational table. forsqlinsertj accepts an XML document of the type returned by SELECT ... FOR XML. It returns a set of INSERT statements that can be used to insert the data in the document into the database. forsqlscriptj combines the functionality of forsqlcreatej and forsqlinsertj.

  • ForXmlTree returns data from multiple result sets as a deeply nested XML document. As input, it accepts a special XML document that describes the SELECT statements used to retrieve each level of data, and information about the columns used to join the data. For example, to return an XML document describing a sales order containing multiple line items, it would contain the SELECT statements that query the sales order and line item tables, as well as the names of the columns used to link these tables.

  • The OpenXml function performs the reverse of the ForXmlTree function. That is, it extracts data from an XML document for insertion into a relational table. In particular, it returns a script containing a CREATE TABLE statement and one or more INSERT statements; it also optionally executes this script. As input, it accepts a file that specifies the name of the table, an XPath statement describing the elements that correspond to rows of data, and XPath statements describing the elements or attributes that correspond to columns of data.

UniData
Developer: IBM
URL: http://www- 306.ibm.com/software/data/u2/unidata/
License: Commercial
Database type: Nested relational
Entry last updated: April, 2004

UniData is a nested relational database, which is a relational database that does not follow first normal form. That is, it allows columns to have multiple values for a single row. Multi-valued columns may be grouped together into "associations", which are effectively nested tables. There are two different types of multi-valued columns -- multi-valued and multi-subvalued -- and these types determine the degree of nesting in an association. The multi-valued columns in an association effectively form a sub-table, while the multi-subvalued columns in an association effectively form a sub-sub-table; deeper nesting is not supported. Note that a table may contain multiple associations and that multi-valued columns are not required to be in an association.

When retrieving data from the database, UniData uses what is effectively a table-based mapping, although this is modified to handle the nested tables that can occur in UniData tables. As in a table-based mapping, one element is created in the XML document for each row in the table. Because UniData tables can effectively contain sub-tables and sub-sub-tables, child and grandchild elements are created for each sub-table "row" and sub-sub-table "row" as needed.

There are three options for mapping data to an XML document. In an attribute-centric mapping (the default), data from single-valued columns is stored as an attribute of the row element, data from multi-valued columns is stored as an attribute of the association (sub-table) element, and data from multi-subvalued columns is stored as an attribute of the sub-sub-table element. The element- centric mapping is the same as the attribute-centric mapping except that data is stored in child elements instead of attributes. In both the attribute- and element-centric mappings, UniData generates element and attribute names from table, association, and column names. The last mapping option is "mixed" mapping, in which the user specifies whether to map columns to attributes or elements using an XML-based mapping language. Users can also specify element and attribute names (including namespace name), as well as how data is to be converted and formatted before it is placed in the XML document.

Applications specify that they want data returned as XML with a TOXML clause on the LIST command in UniQuery or the SELECT statement in UniData SQL. This clause allows users to specify whether they want to use an attribute-centric, element-centric, or mixed mapping, as well as whether to include a DTD in the resulting XML document. If a SELECT statement retrieves data from multiple tables, UniData nests data according to a hierarchy defined by the order of columns in the select list. In particular, if a column in the select list comes from a different table than the previous column in the list, UniData creates a new child element for that column's table. Thus, if columns are grouped by table in the select list, data is nested in the XML document by table and the nesting hierarchy is defined by the order in which the tables occur. If columns are not grouped by table, nesting still occurs, but is unlikely to give the desired result.

UniData can also treat an XML document as a source of data. The user specifies how this is done with a different XML-based mapping language. The user uses an XPath expression to specify the start node in the XML document; this node corresponds to a row of data. The user then uses relative XPath expressions to map descendant elements and attributes to columns in the row. Normal XPath syntax is used to map an element or attribute to a single-valued column, while a modified XPath syntax is used to map a set of elements or attributes to multi-valued or multi-subvalued columns.

Applications use the mapping file in UniBASIC, LIST commands, and SELECT statements. In each case, they specify the name of the mapping file and the XML file and UniData returns the data as if it were rows of data retrieved from a UniData table.
UniVerse
Developer: IBM
URL: http://www- 306.ibm.com/software/data/u2/universe/
License: Commercial
Database type: Nested relational
Entry last updated: April, 2004

UniVerse is a nested relational database, which is a relational database that does not follow first normal form. That is, it allows columns to have multiple values for a single row. Multi-valued columns may be grouped together into "associations", which are effectively nested tables. There are two different types of multi-valued columns -- multi-valued and multi-subvalued -- and these types determine the degree of nesting in an association. The multi-valued columns in an association effectively form a sub-table, while the multi-subvalued columns in an association effectively form a sub-sub-table; deeper nesting is not supported. Note that a table may contain multiple associations and that multi-valued columns are not required to be in an association.

When retrieving data from the database, UniVerse uses what is effectively a table-based mapping, although this is modified to handle the nested tables that can occur in UniVerse tables. As in a table-based mapping, one element is created in the XML document for each row in the table. Because UniVerse tables can effectively contain sub-tables and sub-sub-tables, child and grandchild elements are created for each sub-table "row" and sub-sub-table "row" as needed.

There are three options for mapping data to an XML document. In an attribute-centric mapping (the default), data from single-valued columns is stored as an attribute of the row element, data from multi-valued columns is stored as an attribute of the association (sub-table) element, and data from multi-subvalued columns is stored as an attribute of the sub-sub-table element. The element- centric mapping is the same as the attribute-centric mapping except that data is stored in child elements instead of attributes. In both the attribute- and element-centric mappings, UniVerse generates element and attribute names from table, association, and column names. The last mapping option is "mixed" mapping, in which the user specifies whether to map columns to attributes or elements using an XML-based mapping language. Users can also specify element and attribute names (including namespace name), how data is to be converted and formatted before it is placed in the XML document, and whether to include the root and/or sub-table elements.

Applications specify that they want data returned as XML with a TOXML clause on the LIST command in RetrieVe or the SELECT statement in UniVerse SQL. This clause allows users to specify whether they want to use an attribute-centric, element-centric, or mixed mapping, as well as whether to include a DTD or XML Schema in the resulting XML document.

UniVerse also supports an XML-based object-relational mapping language. This allows multiple tables to be mapped to a single XML document, with primary key / foreign key relationships in the database determining the nesting structure in the document. The language handles single- and multi-valued columns in the same way as the language described above. That is, single-valued columns can be mapped to child elements or attributes of a row element, and multi-valued columns can be mapped to child elements or attributes of an association element.

Applications can use object-relational mapping documents with TCL and UniVerse BASIC. In TCL, there are commands to transfer the data for entire documents to/from the database. In BASIC, there are functions to transfer data from entire documents to/from the database, as well as the XMAP API, which gives applications row-by-row control over what data is transferred.
Versant Object Database
Developer: Versant Corp.
URL: http://www.versant.com/en_US/products/o bjectdatabase
License: Commercial
Database type: Object-oriented
Entry last updated: December, 2008

From the documentation:

"The Versant XML Toolkit (VXML) adds XML/object mapping support to the Versant Object Database product. Via command line tools or Java APIs users can generate XML from defined object graphs and likewise generate objects from XML."
ViewDS
Developer: eB2Bcom
URL: http://www.viewds.com/overview.php
License: Commercial
Database type: Proprietary
Entry last updated: March, 2010

ViewDS is directory service that uses a proprietary data store. (A directory service is a hierarchical database in which values are associated with a particular name. For example, a directory service could be used to store a telephone directory, where a record consists of name, address, and telephone number fields and the name field is the key. Directory services are optimized for searching and retrieving data.)

ViewDS supports access through both DAP (Directory Access Protocol) and LDAP (Lightweight Directory Access Protocol). These define the format of commands sent to the directory service, such as requests to search, insert, update, or delete data.

ViewDS supports XML by implementing the XED (XML Enabled Directory) specification. XED provides three primary features to support XML:

  • XED defines an XML version of the LDAP protocol (XLDAP). This allows applications to send commands to the directory as XML. It can be used directly or sent over SOAP using HTTP.

  • XED defines an XML encoding for ASN.1 values, called the Robust XML Encoding Rules (RXER). This allows directory data to be expressed as XML and is what "XML-enables" ViewDS. That is, it allows directory data to be sent or retrieved as XML. (Note that data must be sent or retrieved in XLDAP documents; data transfer between ViewDS and generic XML documents is not supported.)

  • XED allows users to define data types for directory attributes (database fields) using XML Schemas, DTDs, or RELAX NG schemas. (ViewDS also supports data types defined in ASN.1.) This allows ViewDS to function as a native XML database, where XML documents are stored in directory attributes.

(XED is an alternative to DSML (Directory Services Markup Language), which was developed through OASIS. The primary functional differences between XED and DSML are (a) XED represents XML values as XML, while DSML represents them in hexadecimal format, and (b) XED supports attributes constrained by XML schemas. Although XED has been published through the IETF, no other products implement it.)

ViewDS (and XLDAP) supports the same search filters as LDAP. These allow applications to specify searches on directory attributes using a variety of matching algorithms: equality, substring, ordering, existence, and so on. In addition, ViewDS (and XLDAP) supports the following kinds of approximate matching: synonym matching, abbreviation matching, phonetic matching (including Mandarin Chinese), prefix matching, and spelling correction. These can be applied to entire attribute values or tokens within attribute values.

To support searches on attributes whose values are XML documents, ViewDS (and XLDAP) allows all types of matches to be applied to specific elements or attributes in these XML documents. To increase performance, users can specify that specific elements or attributes be indexed.

In addition to XED, ViewDS supports a number of X.500, LDAP, and ASN.1 specifications. It also supports multiple hierarchical views of the same data, transactions, full-text searches, security (including XACML and role- and time-based access control), and distributed operation. It has C/C++, Perl, PHP, Java, JavaScript, and HTML APIs. It ships with a configurable Web-based client, as well as clients for command-line access and report generation.