5.3 原生XML数据库的数据存储(Storing Data in a Native XML Database)
还可以将XML文件中的数据存储在原生XML数据库(native XML database)中。这么做有几个理由。首先，当你的数据是半结构化的数据时。也就是说，它的结构是普通的，但是如果将其映射到关系数据库，结果是要么出现大量空值(null)的字段，要么表格的数量过多，浪费空间或效率低下。虽然半结构化的数据可存储到面向对象的或层次型数据库中，你还可以选择将它以XML文件的形式存储于原生XML数据库。
将数据存储在原生XML数据库中的第二个理由是读出速度。根据XML数据库存储数据的物理方式的不同，数据的读出速度可以做到比关系型数据库[的读取速度]快得多。其原因是，原生XML数据库对整个文件一起进行物理存储，和[表示]文件各个部分的物理(而不是逻辑)指针可采用同一存储策略。这就可以不使用连接(joins)或只使用物理连接读取文件，无论哪种情况都比关系型数据库所用的逻辑联结要快。
以上述销售订单文件为例。在关系型数据库中，它可能被存为四个表格 -- SalesOrders, Items, Customers, 和 Parts -- 读取文件时需要将这些表格结合起来。在原生XML数据库中，整个文件可被存储在磁盘的一个地方，在读取文件或其片断时只需要一次查找和一次读取操作。关系数据库在读取数据时则需要四次查找以及至少四次读取操作。
这样做的一个明显缺点就是，只有数据的读取顺序和写入磁盘的顺序相同时，才可以提高速度。如果你想要的数据视图不同，比如只想要客户及其订单列表，性能可能比关系数据库更差。所以，如果你的应用中是单个数据视图为主， 为了提高性能，才可以考虑将数据存储到原生XML数据库。
将数据存储在原生XML数据库中的第二个理由是你想利用XML的独有特性，如执行XML查询。由于今天以数据为中心的应用几乎没有这样做的，而且关系数据库正在逐步支持XML查询语言，这个理由越来越不充分。
将数据存储在原生XML数据库中的一个问题是，大多数原生数据库只能以XML[的形式]返回数据。（支持元素和属性到应用程序变量绑定的只是少数）。如果你的应用程序需要另一种数据格式（很有可能），使用数据之前必须先解析XML。对本地的应用程序而言显然是个缺点，而这种前期准备在(比如)ODBC中就不存在。对于将XML作为数据载体使用的分布式应用程序而言，这个问题不很严重，因为不管用的是哪种数据库，这种前期工作必须要有。
5.4 数据类型，空值，字符集及其他 (Data Types, Null Values, Character Sets, and All That Stuff)
本节将就在传统数据库中存储XML文件数据的相关问题展开讨论。（有关数据类型和二进制数据存储的讨论同样适用于原生XML数据库）总的说来，你无法选择数据交换软件解决这些问题的方式。然而，你应当明白这些问题确实存在，这样会有助于你选择软件。
5.4.1 数据类型 Data Types
如果单纯从字面上讲，XML不支持任何数据类型。除了非解析实体，XML文件中的所有数据都是文本，尽管它可能表示日期或整数等其他类型。一般来说，数据交换软件负责把(XML文件中的)文本转换成(数据库中的)其他数据类型，反之亦然。但是，能够被识别为特定数据类型的文本格式数目很有限，比如某个JDBC驱动程序所支持的。日期看起来最容易出问题，因为它的格式可能非常多。而数字在各种语言中的格式也不尽相同，也有可能出问题。
5.4.2 二进制数据 (Binary Data)
二进制数据在XML文件中的存储方法一般有两种：非解析实体和Base64编码(一种编码方式，将二进制数据映射到US-ASCII码的一个子集)。对于关系型数据库，这两种方法都可能产生问题，因为数据库中二进制数据的存取规则非常严格，可能导致软件出错。此外，由于XML标准标记中没有哪个能指明某个元素含有以Base64编码的数据，所以软件甚至可能无法识别数据是以Base64编码的。最后，与非解析实体或Base64编码元素相关的标记是大多数(全部?)数据转换软件在往数据库中存储时所忽略的方面之一。因此，如果二进制数据对你来说很重要，就应确认你所用的软件是否支持它的存取。
5.4.3 空数据 (Null Data)
在数据库术语中，空数据(null data)意味着没有数据。这和值为0的数字或长度为零的字符串区别非常大。例如，假设你收集到的是气象数据，如果温度计不能工作，则数据库中存储的就是null而不是0，否则情况就完全不同了。
XML也支持这种空数据的概念(通过可选(optional)元素或属性)。如果一个可选元素或属性的值为空，就不会包含在文件内。而在数据库中，值为零长度字符串的属性和空元素并不是null：它们的值为零长度的字符串。
当你将XML文档的结构映射到数据库(或反过来)时，你当特别留意，可选元素类型或[空值]属性会被映射到允许空值的字段(nullable columns)，反之亦然。如果不是这样的话，可能会产生插入错误(当转换数据到数据库时)或非法文件错误(从数据库中取出数据时)。
与数据库专业相比，XML社区对null含义的表示法更为自由-- 特别是许多XML用户都认为零长度字符串的属性和空元素是“空(null)”的，所以你应该检查一下你的软件是如何处理这种情况的。有些软件为用户提供了选择，可以定义XML中如何表示"null"，以及支持XML Schema中的 xsi:null属性。
5.4.4 字符集 (Character Sets)
根据定义，除了某些控制字符，XML文件可包含任何Unicode字符。不过，许多数据库对Unicode的支持很有限或根本就不支持，而且需要特殊的配置才能处理非ASCII字符。如果你的文件包含非ASCII字符，要确保你的数据库及数据转换软件对这些字符是否支持及如何支持的。
5.4.5 处理指令和注释 (Processing Instructions and Comments)处理指令和注释并不是XML文档“数据”的一部分，大多数(全部?)数据转换软件都不能处理它们。问题在于这些东西可能出现在XML文档中的任何地方，所以不容易进行基于表格或对象-关系型映射。（一个明显行不通的方案是为这些处理指令和注释建立一个表格，在其他表格加上指向这个表格的外部键(foreign key)，每当处理别的表格时，就检查这些表）。所以大多数数据转换软件会简单地忽略它们。如果处理指令和注释对你相当重要，就要检查所用软件对此能否处理及处理方法。或者可以考虑使用原生XML数据库(native XML database)。
5.4.6 对标记的存储 (Storing Markup)正如5.1.2 一节所提到的, 有时候需要在数据库中存储混合内容的元素而无须进一步解析。这时， 标记被存储为标记字符(markup is stored with markup characters)。然而，问题出现在如何存储那些不作为标记使用的标记字符。在XML文档中，这些是以 lt, gt, amp, quot 和 apos 实体存储的。在数据库中也可这么做。例如，下面的description: <description>
<b>Confusing example:</b> <foo/>
</description>
在数据库中可存为：
<b>Confusing example:</b> <foo/>
这样做的一个问题是一些非XML查询语言，如SQL不会在表中搜寻标记和实体的用法并将其正确翻译。这样，如果你打算用SQL来搜索字符串“<foo/>”，你应当知道实际的搜索字符串是“<foo/>”。
另外，如果实体引用被扩展了，数据转换软件无法区别标记和实体。例如，如果上述例子在数据库中按照下面的形式存储，则软件就无法知道<b> , </b> 和<foo/>到底是标记还是文本。 <b>Confusing example:</b> <foo/>
解决这个问题的长久之计就是支持XML的数据库(XML-aware database)，在那里，对真正的标记和看起来很像标记的东西的处理方式是不同的。非XML应用程序处理XML时，总是会出现这种问题。
5.5 从关系[数据库]Schema产生DTD或相反 (Generating DTDs from Relational Schema and Vice Versa)
在XML文件与数据库之间进行数据转换时经常遇到的一个问题是如何从数据库schema产生DTD或相反。在解释如何做之前，必须指出这是设计阶段的任务。其原因是大多数以数据为中心的应用以及几乎所有的盘点应用软件(vertical applications)都是在已知的DTD或数据库模型上工作的，因此，不会在运行时产生schema。再者，如下所述，schema的产生过程不十分严格。如果应用程序需要在数据库中随机存放XML文件，则应考虑使用使用原生XML数据库，而不是在运行时产生schema.
从DTD产生关系模型（或相反）的最简单方法就是直接借助于对象-关系映射，它有几个可选特性。对于面向对象的数据库也有相似的途径。（关于每种方法的逐步演示，请看Mapping DTDs to Databases.）。
从DTD产生关系模型：
对每个复合数据类型, 创建一个表格和主键字段
对每个混合内容的元素类型，另外建一个表用来存储PCDATA，通过其父表格的主键与父表格相连。
对该种数据类型的每个单值属性，以及每个单次出现简单子元素在表中建一个字段。如果子元素或属性是可选的，将该字段设置为可为空值的字段(nullable)。
对每个多值属性(multi-valued attribute)和每个多次出现的简单元素，单独创建一个表，通过其父表格的主键与父表格相连
对每个复合类型的字元素，通过其父表格的主键将父表与该子元素类型的表相连。
从关系[数据库]模型产生DTD:
为每个表创建一种元素类型。
对表中的每个数据(非键)字段以及主键字段，在元素类型上增加一个属性或在内容模型上增加一个PCDADA型的字元素。
对于每个引用该主键的表格，在内容模型上增加一个子元素，继续递归处理表格。
对于每个外来键，在内容模型上增加一个子元素，继续递归处理外来键表格。
这些过程有一些缺点。许多问题都可手工解决，比如名称冲突及指定字段数据类型和长度。（DTD不包含数据类型信息，所以不可能预知数据库中的数据类型。注意，从XML Schema文件可以知道数据类型和长度。）
更加严重的问题是，XML文件所用的数据“模型”通常和数据库中所用的高效率的模型不同(更为复杂)。请看如下XML片断： <Customer>
<Name>ABC Industries</Name>
<Address>
<Street>123 Main St.</Street>
<City>Fooville</City>
<State>CA</State>
<Country>USA</Country>
<PostCode>95041</PostCode>
</Address>
</Customer>
从DTD产生关系模型的一般过程来看，通常会产生两个表：一个是customers，另一个是addresses。然而，大多数情况下把address存放在customer表中更为合理。
<Address>元素就是包装元素(wrapper element)的典型例子。采用包装元素的原因有二：首先，这种结构使得文档更容易理解；其次，它可作为一种数据类型使用。例如，可以将<Address>元素传给一个例程，该例程可以将所有地址转换为Address对象，不管它出现在哪里。
虽然包装元素在XML中很有用，但被映射到数据库中的时候会增加额外的结构，很容易出问题。因此，在产生关系模型之前，一般应将其从DTD中除去。由于DTD一般是不允许改变的，而在映射是又不包含包装元素，所以往往会导致实际文档与数据转换软件所要求的文档不匹配。对此可以在运行时转换文件(比如使用XSLT)：数据被转到数据库之前去掉包装元素，转出后在加上它。
尽管有这些不足，上述步骤还是为DTD和关系模型之间的转换提供了一个起点，对于大型系统尤为如此。
6.0 文件的存取 (Storing and Retrieving Documents)
XML文件的存储方式有两大类：存储于文件系统或作为BLOB存储于关系数据库以获得有限的XML功能，或者将其存储于原生XML数据库。
6.1 将文件存储于文件系统 (Storing Documents in the File System)
如果你的文件比较简单，数量不多，最简便的方法就是存储于文件系统。以后可以使用grep之类的工具进行查询或sed来修改。（对XML文件进行全文检索显然不够精确，比如很难区分文本和标记，而且无法理解实体的用法。然而，对于小型系统，这还是可以接受的）如果你想实现简单的事务管理(transaction control)，可以将文件放在诸如CVS或RCS等版本管理系统中。
6.2 将文件存储于BLOB (Storing Documents in BLOBs)
另一种较为复杂的方法就是将文件存储于关系数据库中的BLOB。这就利用了数据库的一些优点：事务管理、安全、多用户访问等。此外许多关系数据库提供的检索工具可以进行全文检索、近似检索、同义词检索和模糊检索。其中某些工具将会支持XML，这样就可消除将XML文件作为纯文本检索所带来的问题。
如果以BLOB的形式存储XML文件，即使数据库不支持对XML的检索，你也很容易实现自己的XML检索。方法之一是创建两个表：索引表(DB2中的side table)和文件表。文件表包含一个主键和一个存储文件的BLOB字段，索引表内有一个已建立索引值字段以及一个外来键指向文件表中的主键。
文件被存在数据库中之后，就可以搜索所有已建索引的元素和属性实例。每个实例及文件的主键都存于索引表中。这样已建立索引的字段使应用程序可以快速检索某个元素或属性值并获取相应的文件。
举例来说，假如你有一些符合下列DTD的文件，希望建立作者的索引： <!ELEMENT Brochure (Title, Author, Content)>
<!ELEMENT Title (#PCDATA)>
<!ELEMENT Author (#PCDATA)>
<!ELEMENT Content (%Inline;)> <!-- Inline entity from XHTML -->
你可以用下表来存储它： Authors Brochures
---------------------- ---------
Author VARCHAR(50) BrochureID INTEGER
BrochureID INTEGER Brochure LONGVARCHAR
假如你在数据库中插入了一个
brochure，程序就会在
Brochures表中插入该brochure，然后寻找<Author>元素，将它的值和brochure ID存入Authors表中。以后就可通过简单的SELECT语句得到某个Author的所有brochure。比如想得到author为Chen的所有brochure，就可以执行下面的语句： SELECT Brochure
FROM Brochures
WHERE BrochureID IN (SELECT BrochureID FROM Authors WHERE Author='Chen')
更复杂的索引表可包含四个字段：元素类型或属性名、(元素或属性)类型、值和文件ID。这样就可在一个表中存放多个标记[文件], 并按名字、类型和值建立索引。写个操作这个表的SAX程序应该不是件难事。
6.3 原生XML数据库 (Native XML Databases)
上述的简单系统所提供的功能如果不能满足你的需要，你可以考虑使用原生XML数据库(native XML database)。原生XML数据库是专用于存储XML文件的数据库。和其他数据库一样，它支持事务管理、安全、多用户访问、编程API和查询语言等。与其它数据库的唯一区别就是其内部模型是基于XML的，而不是其他的模型--如关系模型。
显然原生XML数据库最适于存储以文档为中心的文件。这是由于原生XML数据库保留了文件[元素？]顺序、处理指令、注释、CDATA块以及实体引用等，而支持XML的数据库(XML-enabled database)无法做到。此外，原生数据库支持XML查询语言，你可以对它提这样的问题：“找出所有第三段内包含粗体字的文件”，用SQL显然很难进行这样的查询。
原生XML数据库还适用于存储那些“天然格式”为XML的文件，而不管这些文件包含什么内容。例如，电子商务系统消息所用的XML文件。尽管这些文件可能是以数据为中心的，而作为消息来说它们的天然格式是XML。这样当它们被存入消息队列后，建立在原生XML数据库上的消息队列使用起来更为方便。原生XML数据库保留了XML的特性比如XML查询语言，通常能更快地取出整条消息。Web cache是这类应用的另一个例子。
原生XML数据库的其他用途是存储半结构化数据、在某种特定情形下提高存取速度以及存储没有DTD的文件(良构的文件)。前两种已经在5.3 原生XML数据库的数据存储中叙述过。而后一种用非XML的数据库是做不好的。也就是说，原生XML数据库无须事先配置即可接受和存储任何XML文件。将XML文件中的数据转换到关系型或面向对象型数据库必须首先建立映射和数据库模型。无须事先配置对于搜索引擎之类的应用程序来说是有利的，因为没有任何DTD能适用于所有搜索文档。
6.3.1 什么是原生数据库(Native XML Database)?"native XML database"这个术语首先在Software AG 为 Tamino 所做的营销宣传中露面。也许由于它的成功，后来这个术语在同类产品的开发商那里成了通用叫法。它是一个营销术语，从来没有正式的技术定义，这是它的一个缺陷。
有一个接近的定义(出自XML:DB mailing list的一个成员)这样定义原生XML数据库(native XML database)：
它为XML文档（而不是文档中的数据）定义了一个(逻辑)模型，并根据该模型存取文件。这个模型至少应包括元素、属性、PCDATA和文件顺序。这种模型的例子有XPath数据模型、XML Infoset以及DOM所用的模型和SAX的事件。
它以XML文件作为其基本(逻辑)存储单位，正如关系数据库以表中的行作为基本(逻辑)存储单位。
它对底层的物理存储模型模型没有特殊要求。例如，它可以建在关系型、层次型或面向对象的数据库之上，或者使用专用的存储格式，比如索引或压缩文件。
该定义的第一部分与其他类型数据库的定义相似，都是关于数据库所用的模型的。不过，原生XML数据库所能存储的信息比模型中定义的多。例如，它可支持基于XPath数据模型的查询，但所用的存储格式是纯文本。CDATA部分和实体用法也可存储在数据库中，但是模型中没有包括。
定义的第二个部分是说原生数据库的基本存储单位是XML文件。看起来似乎也可存储XML文件片断，但几乎所有的原生XML数据库都是以文件方式存储的。
（基本存储单位就是可以容纳一份数据的最低级的上下文(context)，相当于关系数据库中的行。它的存在并不妨碍以更小的数据单位来读取数据，比如文件片断或个别元素，同样也不影响将不同文件中的片断进行组合。从关系数据库的术语来讲，相当于数据虽然以行的形式存放，并不意味着无法读取某个字段的值，或从现有的数据行创建新一行数据。）
该定义的第三部分讲的是底层的数据存储格式并不重要。确实如此，正如关系数据库所使用的物理存储格式与数据库是不是关系型之间毫无关系。
6.3.2 原生XML数据库的结构 (Native XML Database Architectures)
原生XML数据库的结构可分为两大类：基于文本的和基于模型的。
6.3.2.1 基于文本的原生XML数据库(Text-Based Native XML Databases)
基于文本的原生XML数据库将XML作为文本存储。它可以是文件系统中的文件、关系数据库中的BLOB或特定的文件格式。（事实上，就其能力来说，一个增加了支持CLOB(Character Large Object)字段的XML处理功能的关系数据库也可以是原生XML数据库了。）
索引对所有基于文本的原生XML数据库来说都是一样的，它可以使查询引擎很方便地跳到XML文件内的任何地方。这就可以大大提高数据库存取文件或文件片断的速度。这是因为数据库只需进行一次检索、磁头定位，再假如所读的文件在磁盘上是连续[存储]的话，只需一次读盘就可读出整个文件或文件片断。相反，如果像关系数据库或基于模型的原生XML数据库那样，文件由各个部分组合而成，就必须要进行多次查找定位和多次读盘动作。
从这个意义上讲，基于文本的原生XML数据库与层次结构的数据库很相似，当存取预先定义好层次的数据的时候，它比关系数据库更胜一筹。和层次结构的数据库一样，当以其他形式比如转置层次存取数据时，原生XML数据库也会遇到麻烦。这个问题的严重程度尚未可知，很多关系数据库都使用逻辑指针，使相同复杂度的查询以相同的速度完成。由此看来这确实是个问题。
6.3.2.2 基于模型的原生XML数据库 (Model-Based Native XML Databases)第二类原生XML数据库是基于模型的原生XML数据库。它们不是用纯文本存储文件，而是根据文件构造一个内部模型并存储这个模型。至于模型究竟怎样存储取决于数据库。有些数据库将该模型存储于关系型和面向对象的数据库中，例如在关系型数据库中存储DOM时，就会有元素、属性、PCDATA、实体、实体引用等表格。其他数据库使用了专为这种模型作了优化的专有存储格式。
建立在其他数据库之上的基于模型的原生XML数据库的文件存取性能与这些数据库相似，很明显，它的存取要依赖这些数据库。但是这个数据库，特别是建立在其他数据库之上的原生XML数据库的设计有很大的变化余地。例如直接以DOM方式进行对象-关系映射的数据库系统在获取节点的子元素时必须单独执行SELECT语句。另一方面，这种数据库大多对存取模型和软件作了优化。例如Richard Edwards在 system for storing the DOM in a relational database一文中曾经描述只用一个SELECT语句就可获取任意文件片断(或整个文件)。
使用专用存储格式的基于模型的原生XML数据库如果以文件的存储顺序读取文件，其性能与基于文本的原生XML数据库相似。这是因为这种数据库大多在节点间使用了物理指针，这样其读取性能和读取文本差不多。（究竟哪个快一些要取决于数据格式。如果返回文本格式，显然基于文本的系统要快一些；如果希望返回的是DOM，假如该模型很容易映射到DOM，则基于模型的系统更快。)
与基于文本的原生XML数据库一样，如果数据的读取顺序和存储顺序不同，基于模型的原生XML数据库也会遇到性能上的问题。这项种类型的数据库到底哪个快一些仍不清楚。
6.3.3 原生XML数据库的特性 (Features of Native XML Databases)
本节简单讨论原生XML数据库的一些特性，有助于大致了解其现状和未来。
6.3.3.1 文件集 (Document Collections)
许多原生XML数据库都支持集合（collection）的概念，其作用相当于关系数据库中的表和文件系统中的文件夹，例如你想在原生XML数据库中存储销售订单，就可以定义一个销售订单的集合，这样对销售订单的查询就限于这个集合内的文件。
集合是否允许嵌套取决于所用的数据库。
6.3.3.2 查询语言 (Query Languages)
几乎所有的原生XML数据库都至少支持一种查询语言。最常用的有XPath(对多个文件的查询作了扩充)和XQL，以及很多专有的查询语言。在考虑原生XML数据库时应当确定其查询语言是否满足你的需要，比如从全文检索到多个文件片断的合并。
将来大多数原生XML数据库都可能支持W3C的XQuery。
6.3.3.3 更新和删除 (Updates and Deletes)
原生XML数据库对文件的更新和删除方式有许多，从简单的替换或删除现有文件，到修改当前的DOM树，以及用于指定如何修改文件片断的语言。通常每种能修改文件片断的产品都有自己的语言，尽管有几种产品支持XML:DB Initiative 的XUpdate语言。至于文件的更新正是业界和学术界的探讨领域，近期似乎没有完整的解决方案[2002年2月]。
6.3.3.4 事务、锁定和并发 (Transactions, Locking, and Concurrency)
基本上所有的原生XML数据库都支持事务处理（以及回退rollback）。但是，锁定通常是对整个文档的而不是对文件片断的，所以多用户并发性[的支持]相对较低。问题的大小取决于应用程序以及“文件”的构成。
例如用户手册分成几个章节，每个章节都是一个文件，这时并发问题就小一些，因为两个作者同时对同一章节进行更新的情况不大可能发生。而另一方面，如果整个公司的客户数据都放在同一个文件中（糟糕的设计），文件级的锁定很容易造成灾难性的后果。
将来，大多数的原生数据库可能会提供文件片断级的锁定。
6.3.3.5 应用程序接口 (Application Programming Interfaces ,APIs)
几乎所有原生数据库都提供编程接口API。这种API很像ODBC，并提供有连接到数据库、浏览元数据、执行查询和返回结果的方法(methods)。返回结果通常是XML字符串、DOM树、返回文档的SAX解析器或XMLReader。如果查询返回结果是多个文档的话，通常都会提供例举(iterating)这些结果的方法。
对以数据为中心的应用来说比较有趣的特性是将应用程序变量与返回文档的特定元素或属性相关联的能力。这就免除了应用程序为构件内部数据对象而不得不对文档进行解析的工作，随着XML数据绑定技术的应用越来越多，看起来这个特性会得到广泛支持。
虽然大多数原生XML数据库都提供有自己的API，但是XML:DB.org已经开发出一种与供应商无关的XML数据库API(vendor-neutral XML database API)，许多原生XML数据库已经支持它，而且有些非原生的[XML]数据库也可能支持。不管这个或其他的API是否会成为工业标准，此类API的广泛采用最终是不可避免的。
大多数原生数据库还有将查询结果通过HTTP返回的能力。
6.3.3.6 “往返车票”(Round-Tripping)
原生XML数据库的一个重要特性是它可以为XML文档提供了“往返车票(round-trip)”。就是说你可以将XML文件存放在原生XML数据库中，而且再取回“同样的”文件。对于以文档为中心的应用程序来说非常重要，因为CDATA部分、实体应用、注释和处理指令是这些文档不可缺少的组成部分。特别是对于法律和医学文件，按照要求这些文档必须要保持原样。
（对于以数据为中心的应用来说，由于它主要关心的是元素、属性、文本以及层次顺序，这种“往返车票”显得不是很重要。能够在XML文件和数据库之间交换数据的软件都可以处理这些往返问题，如果兄弟元素的顺序对以数据为中心的应用程序来说很重要，在有限的几种情况下也可以保留这种顺序。但是由于它[指一般的交换软件--译者注]一般不保留兄弟元素的顺序，也不确保原样保持处理指令、注释以及物理结构(实体引用、CDATA等等)，所以不适于以文档为中心的应用。）
所有原生XML数据库都能够在元素、属性、CDATA和文件顺序的级别上为文件提供“往返车票”，至于究竟能达到什么程度取决于数据库。一般来说，基于文本的原生XML数据库能够原样存取XML文件，而基于模型的原生XML数据库只能在文件模型的级别上原样存取XML文件。对于特别小的文档模型，意味着比普通的XML原样存取的级别低。
由于你的应用程序要求决定了应当在哪个级别原样存取，所以对原生XML数据库的选择余地相当大。
6.3.3.7 外部数据 (Remote Data)
某些原生XML数据库可包含有外部数据，这些外部数据来自存储在数据库中的文档。通常这些数据通过ODBC、OLE DB或JDBC从关系数据中取出，模型可以是基于表格的或对象-关系型映射。原生XML数据库决定了这些数据是不是即时的(live)--即原生XML数据库中文档的更新是否在外部数据库中反映出来。大多数原生XML数据库大概最终都会支持即时的外部数据。
6.3.3.8 索引 (Indexes)
几乎所有的原生XML数据库都支持元素和属性的索引。像非XML数据库一样，索引用于提高检索速度。
6.3.3.9 外部实体存储 (External Entity Storage)
XML文档存储时的一个棘手问题就是怎样处理外部实体。也就是说，应当将其展开，把它的值存储在文件中，还是保留实体引用原封不动？这个问题没有统一的答案。
例如，假设文档中包含一个外部实体用来调用一个当前天气报告的CGI程序。如果将这个文件用于提供天气预报的网页，那么将这个实体展开就是错误的，因为网页中提供的不是即时的数据。相反，如果文件是气象历史资料的一部分，那么不展开它反而是不对的，否则文件总是含有当前的数据而不是历史资料了。
再看另外一个例子，假设一个产品手册只包含指向手册中其他章节的外部实体引用。如果这些章节又被其他文件（比如该产品的另一种型号的手册）使用，那么展开这些引用就不对了，因为这会造成同一个章节有多份拷贝。
我不知道原生XML数据库如何处理这个问题。最理想的当然是允许你根据不同情况指定是否展开外部实体引用。
6.3.4 规范化，引用完整性和可扩展性 (Normalization, Referential Integrity, and Scalability)
对许多人，特别是有关系型数据库背景的人来说，由原生XML数据库引发出不少争论，特别是围绕数据的存储方面（相对于文档而言）。这里我们就来讨论这些话题。
6.3.4.1 规范化 (Normalization)
规范化指的是数据库模型的设计当中要保证每一份数据只能存储一次。规范化有几个好处，例如可以减少磁盘空间占用，消除可能的数据不一致性。这是关系型数据库技术的基础之一，人们在讨论原生XML数据库的数据存储时认为这点容易出问题。
在进一步讨论规范性之前，需要指出对许多以文档为中心的文件这不是大问题。例如有一些描述公司产品信息的文件，通常各个文件的公用数据很少--比如版权声明、公司地址和电话号码、产品标志等等，其数量相对来说太小了，几乎没有人考虑它的存储规范性。（其他种类的文档可能有许多重复内容有必要进行规范化）。
与关系型数据库一样，原生XML数据库并不要求你一定要规范你的数据，用原生XML数据库你也很容易设计出一个糟糕的存储结构。所以在将文件存入原生XML数据库之前，你应仔细考虑文档的结构。（与关系型数据库相比，原生XML数据库在这点有些优势。因为原生XML数据库没有数据库模式，你可以同时以多种模式存储相似的文件，不过为了简化事务处理，你可能需要重新设计查询并转换你的文件（这相对并不重要））
原生XML数据库的规范化和关系型数据库的规范化差不多一样：你的文档的设计要保证不会有重复数据。两者的不同在于XML支持多值属性而（大多数）关系型数据库不支持。这样就有可能以一种在关系型数据库中无法实现的方式来“规范”原生XML数据库的数据。
例如销售订单，它含有头信息比如订单编号、日期和客户代码，还有具体项目如零件号、数量和总价。在关系型数据库中，头信息和具体项目必须存在于不同的表内。而在原生XML数据库中，这些信息可以存储在同一个文件内，不会产生冗余，因为XML与生俱来就支持一个父元素内包含多个子元素。
不幸的是，现实当中的规范化可没这么简单。例如你想要销售订单包含客户信息如合同名称、收货和付款地址，该怎样做? 你有两种选择：第一，你可以在销售订单中复制一份客户信息，结果带来数据冗余和其他问题；第二，你可以单独存储客户信息，在销售订单中提供一个指向客户信息文件的XLink，或者在查询时再将这两个文件连接起来。这就要求对XLink的支持（虽然正在计划，但大多并不支持）或者查询语言要支持连接(同样并不总能如愿)。
在实践当中答案尚不明确。实际当中出于性能的考虑，数据并不总是规范的，所以有一些不规范的XML数据并不像初看起来那么糟糕，不过你必须做出抉择。如果你存储的是以文档为中心的文件并且在相当程度上做到了规范化，比如将章节或过程单独存储并将它们连接起来创建最终用户所用的文件，那么原生XML数据库可能就是一个不错的解决方案，尤其是它能提供别的数据库中所没有的特性比如XML查询语言。如果你要存储的文件是以数据为中心的，而原生XML数据库能够改进应用程序的性能，或者它提供的半结构化数据存储，而在别的数据库中是无法实现的，你也应当用原生XML数据库。如果你只不过想在原生XML数据库内实现一个关系型数据库，你就应该反思一下，为什么不把关系型数据库列为首选。
6.3.4.2 引用完整性 (Referential Integrity)
与规范性密切相关的是引用完整性(referential integrity)。引用完整性即相关数据的[引用]指针的有效性，是保持数据库数据一致性的必要条件。如果你的销售订单含有一个客户代码，而相应的客户信息并不存在，这对你没什么好处。发货部门不知道往哪里发货，而财务部门不知道给哪里寄发票。
在关系型数据库中，引用完整性意味着确保外部键指向合法的主键，也就是说，对每个外部键都要检查相应的主键记录。在原生XML数据库中，引用完整性意味着XLink或其他专有链接机制指向合法的文件或文件片断。
目前来看，只有少数原生XML数据库强调了引用完整性。原因是大多数原生XML数据库并不支持链接机制，所以引用校验就无从谈起。因而今天采用XLink或其他链接机制的应用程序必须对原生XML数据库在这方面的支持加以强调。
将来，许多原生XML数据库都会支持链接机制和引用完整性。
6.3.4.3 可扩展性 (Scalability)
可扩展性完全不是我的所长，所以下面大多都是我的推测。总的来说，我想原生XML数据库的可扩展性在某些环境下会非常好，而其他场合下可能非常糟糕。
与层次型和关系型数据库类似，原生XML数据库也使用索引来查找数据。这就意味着文件（或文件片断）的定位只与索引的大小有关，而与文件的大小和数量无关，因而原生XML数据库定位文件开始的速度和其他使用索引技术的数据库一样。由此看来，原生XML数据库的可扩展性和其他数据库一样。
与层次型数据库相同而与关系型数据库不同的是，许多原生XML数据库用物理方法链接相关数据。特别是基于文本的原生XML数据库用物理的方法对相关数据分组，使用专用存储格式的基于模型的原生XML数据库通常使用物理指针来对相关数据分组.(建立在关系数据库之上基于模型的原生XML数据库使用的是逻辑链接。)
由于物理链接比逻辑链接速度快，原生XML数据库和层次型数据库一样，数据的读出速度比关系型数据库快得多。因此，从数据的读取方面来看，它应具有同样的可扩展性。事实上，在数据的读取能力上XML数据库比关系型数据库甚至更好，因为可扩展性与单次、原始索引查找有关，而不是关系型数据库所用的多次查找。（需要指出，关系型数据库也以集簇索引(clustered indexes)的形式提供数据的物理链接。不过，这种链接是应用于各个表格而不是整体层次上的。）
令人遗憾的是这种可扩展性是有限的。就像层次型数据库，原生XML数据库中所用的物理连接只能作用于特定的层次。也就是说，如果数据的读取和数据的存储在同一层次下，则读取速度很快，否则就不一定快。例如将客户信息存储在各个销售订单文件中，则读取销售订单时的速度很快，而如果需要的数据视图不同，比如要找出某个客户的所有订单将会很慢，因为此时物理连接已不再适用。）
为了缓解这个问题，原生XML数据库大量使用了索引，经常对所有元素和属性都作了索引。这虽然有助于减少读取时间，却增加了更新时间，因为维护这种索引的代价很高。在只读的环境下这无关紧要，在交易频繁的环境下可能造成麻烦。
最后，对于未索引数据的查找来说，原生XML数据库的可扩展性比关系型数据库差的多。此时这两种数据库都要线性地查找数据，而原生XML数据库的情况更为糟糕，因为它的数据不是完全规范的。比如你要查找某个日期的所有销售订单，而日期是未经索引的。如果用的是关系型数据库，就要读取所有OrderDate字段的值，而对于原生XML数据库，这意味着要读取每个销售订单文件，并从中查找<OrderDate>元素。不但需要读取<OrderDate>元素的内容；而且还要读取所有其它文件的内容。对于基于文本的原生XML数据库，情况更为糟糕：在与目标日期比较之前，必须先对文本进行解析并转换为日期格式。
那么对你来说，可扩展性是不是个问题? 这完全取决于你的应用。如果你的应用程序中所需的数据一般都和其存储形式相同，则原生XML数据库的可扩展性应是不错的。许多以文本为中心的应用就属于这种情形。例如组成产品手册的文档几乎总是作为整体读取的。反之，如果你的应用中数据视图不是很确定，则可扩展性有可能出问题。
对于原生XML数据库的讨论就到此结束。在接下来的两部分中，我们将考察两种特殊的原生XML数据库：可持久化DOM和内容管理系统。
6.3 可持久化DOM (Persistent DOMs, PDOMs)
可持久化DOM(persistent DOM)或PDOM是在某种持久性存储[介质]上实现了DOM的一种特殊的原生XML数据库。与大多数以DOM树返回文档的原生XML数据库不同，PDOM返回的DOM是实时的(live)。也就是说，对DOM所作的改变直接反映在数据库中。（这种改变实际上是否马上做出或者通过调用一个方法来实现取决于数据库）大多数原生XML数据库返回个应用程序的DOM树是一个复制品，而数据库中的改变是通过XML更新语言，或者是通过替换整个文件来实现的。
由于PDOM树是实时的，数据库通常是在本地。这就是说，它和应用程序在同一个进程空间，或者至少在同一部机器（尽管这并不是必需的）。这是出于性能上的考虑，因为外部数据库上的PDOM必须经常向远程服务器发出请求。
PDOM在DOM应用程序中所起的作用和面向对象的数据库在面向对象的应用程序中的作用一样：它为应用程序的数据提供了可持久的存储，也可作为应用程序的虚拟内存。后一种作用对于操作大型文件的DOM应用来说有着特殊的重要性，因为DOM与XML文件长度之比很容易超过10。（实际的系数取决于文件中文本的平均长度，文本的平均长度较小的文件其系数较高。）
6.4 内容管理系统 (Content Management Systems)
内容管理系统是原生XML数据库的另一种特殊形式。它们是为管理手工写成的文件例如用户手册和技术草稿(white paper)而专门设计的，并且建立在原生XML数据库之上。这个数据库一般是处于用户看不到的后台，而提供给用户的功能有：
版本和访问控制。
搜索引擎。
XML/SGML编辑器。
发布引擎。比如以书面、CD或Web上发布。
内容与样式的分离。
可通过脚本或编程扩展。
数据库数据的集成(integration)。
相对于文件管理系统，内容管理系统这个术语道出了这样的事实：它使你可以将文件分为离散的片断（比如示例、过程、章节或旁注）和元数据（例如作者、修订日期、文件编号），而不是以整体管理文件。这不但简化了一个文件多个作者时的协调工作，而且能使你从现有文件部分组合成全新的文件。
7.0 XML 数据库产品 (Database Products)
关于最新的XML数据库产品，参见XML Database Products.
8.0 相关链接 (Additional Links)
有关XML/数据库的相关资源，包括软件和文章，参见XML / Database Links。
9.0 意见和反馈 (Comments and Feedback)
请将意见和反馈发送给Ronald Bourret rpbourret@rpbourret.com。我经常外出旅行，有可能延误两到三个星期。
感谢Michael Champion, John Cowan, Marc Cyrenne, Marc de Graauw, Kelvin Ginn, Ingo Macherius, Lars Martin, Nick Leaton, Evan Lenz, Michael Rys, Walter Perry, Kimbro Staken, Jim Tivy, Phillipe Vauclair, Dylan Walsh, Irsan Widarto, Morten Primdahl 及其他人的意见和耐心。
