NXDB与XEDB殊途同归

清华大学 李骅竞 邢春晓 张志强

XML的兴起使得不少新兴公司进入了XML数据库市场，但传统关系数据库厂商也没有坐视不管，而是以同样的速度迅速向XML数据库领域进军。由于实现方式不同，常用的XML数据库系统据此形成NXDB和XEDB两大阵营。

NXDB：纯粹的XML存取

NXDB是专门针对XML格式文档进行存取管理和数据操作的数据库，数据库中的数据和元数据完全采用XML结构表示，与其底层的数据存储格式（如对象模型、关系模型等）无关。NXDB的逻辑模型是建立在XML文档而非文档中的数据之上，根据它来存取数据，其数据存取必须采用XML及其相关标准。目前主流的NXDB产品有Tamino、eXcelon、TEXTML server、Lore等，主要用于以数据和文档为中心的应用。

虽然NXDB专门为XML文档存储而设计，不过它也兼有一般数据库的特性，如支持事务、并发控制、安全机制、二次开发接口等，惟一的不同之处在于其内部存储模型基于XML文档树型结构，而非关系模型。NXDB通常具有以下特性：

文档集合　很多NXDB产品都支持“文档集合”的概念，类似于文件系统中的一个目录或RDBMS中的一张表。一个“文档集合”把一类文档聚集在一起，方便用户操作，集合级别上的查询、修改等操作都会反映到集合内的每个文档。通常一个“文档集合”关联一种模式，将文档加入到有模式的“文档集合”时，会对要加入的文档进行模式检查。同时，NXDB也提供“无模式”的文档集合，即将文档放入该集合时，无需检查该文档的模式，大大方便了用户存储格式难以统一的、半结构化的XML文档。

查询语言　XPath和XQuery是W3C推荐的针对XML文档的查询语言。目前大部分NXDB产品都支持Xpath，也有一些NXDB提供专有的查询语言。XPath是基于XML文档树形模型，给出从某个节点起的查询路径，然后搜索文档。不过，XPath作为数据库查询语言还存在不少缺陷，比如不能分组、排序、连接等。而XQuery更像一种编程语言，支持循环等逻辑和分组、排序、连接等操作。相对于传统数据库的标准SQL语句，XQuery在对XML数据的查询方面，是一种功能更强大、更易于编程的方法。

事务处理和并发控制　一般NXDB都支持事务处理。但是，事务的粒度通常比较大，一般是针对整个文档而不是文档片断，所以多用户并发性的支持相对较低。具体的并发程度取决于应用程序以及“文档”的构成。

二次开发接口　几乎所有NXDB都提供编程接口，包括数据库连接、浏览元数据、执行查询、返回结果等方法。返回结果通常是XML字符串、DOM树或返回文档的SAX解析器。如果查询的返回结果是多个文档或文档片断的话，通常都会提供枚举这些结果的方法。对于以Client/Server模式运行的数据库产品，还可以将结果通过网络协议（如HTTP）回传给客户端。

Round-tripping NXDB一个重要特性是它为XML文档提供了Round-tripping功能：将XML文档存放在NXDB中，然后再取回“同样的”文档。这对以“文档为中心”的应用程序非常重要，因为易被XEDB忽略的CDATA（字符数据）部分、实体应用、注释和处理指令是这些文档不可缺少的组成部分。特别是对法律和医学领域中不允许随意窜改格式的数据文档。所有NXDB都能够在元素、属性、CDATA和文件顺序的级别上为文档提供Round-tripping，其实现的具体程度取决于数据库产品。

更新和可持久化的DOM　大多数NXDB对XML文档的更新是通过API调用完成，或通过简单地替换整个文档来实现。某些NXDB还提供了可持久化的DOM（Persistent DOM，PDOM）：在某种持久性存储介质上实现了DOM模型，对PDOM所进行的改变将直接反映到数据库中。由于PDOM树是“现场”的，所以数据库通常和应用程序在同一个进程空间。

XEDB：在关系数据库上打补丁

XEDB是在关系数据库基础之上扩展了XML支持模块，从而实现XML数据和数据库之间的格式转换和传输，支持对XML数据的相关操作。简单地说，用户在进行XEDB操作时将经历如下过程：把XML文档存到XEDB中时，必须将XML文档的模式转换成关系数据库模式，如果将数据从XEDB中取出来则必须完成相反的操作，重新组合成XML文档提供给用户。

XEDB的核心仍然是关系数据库，只不过是加上了一层XML的转换接口。IBM、Oracle、Microsoft等主流关系数据库厂商都推出了XEDB系统，因为本质上仍然是关系数据库，所以它们主要用于以数据为中心的应用。

XEDB对XML文档的处理主要通过XML网关模块完成，它处于用户逻辑模块和数据库逻辑模块之间，将传统数据库包装起来，给用户提供了一个透明的XML数据源。从存储粒度上看，可以把整个XML文档作为RDBMS（关系数据库管理系统）表中的一行，或把XML文档进行解析后，存储到相应的表格中。XEDB存取XML文档的主要技术特点如下：

XML文档模式和XEDB模式的映射　从XML文档模式到关系数据库模式的映射及其反操作显然是XEDB中最核心的问题。这种转化将发生在元素、属性和文本上，由于XEDB注重的是数据而非格式，所以在这个过程中，XML文档的大部分物理结构（如CDATA、实体等）和一部分逻辑结构（如处理指令、注释等）都将被忽略，而数据被保存，所以这种转换可能会丢失信息，当一个XML文档存储到XEDB中再取出来，很可能会变成另一种格式。像对于NXDB提供的Round-tripping功能，XEDB只能在数据层面实现信息的保留。

对XML数据的查询支持　由于XML文档模式和XEDB模式很难保持一致，所以在存取过程中经常用XSLT（eXtensible Stylesheet Language Transformations，可扩展样式表语言转换）完成转换。但XSLT非常耗时，会对查询性能造成很大影响。所以较好的解决方法是XEDB提供一种查询语言来返回XML文档。目前已经有很多XEDB产品提供了这种语言，主要分三类：

● 基于模板（Template-Based）的查询　这是目前RDBMS XEDB最流行的处理方法，将SQL语句嵌入到已写好的XML文档模板中，在实际查询时用结果替换。

● 基于SQL（SQL-Based）的查询　通过在SQL语句的实现中增加对XML的支持完成对XML数据的查询。例如Oracle9iR2中，增加了XMLTYPE类型和一些新的函数包以支持XML数据库。

● XML查询　包括XPath和XQuery。与上面两种不同，这种查询是建立在XML文档模型上。也就是说，如果XEDB要支持这种查询方式，必须提供虚拟的XML文档。而目前的XEDB基本上只支持XPath。

数据类型、空值、字符集的处理　在XML文档和XEDB的转换过程中，还会遇到数据类型的匹配、空值、字符集的处理等问题，如受到JDBC驱动模块的限制、日期的不同国际化表示等。XML文档中除了不被解析的一些实体外，所有数据的类型都以文本来表示。XML文档可以以非常灵活的方式来支持空值，如省略某个元素、零长度的元素和属性等。而这些在XEDB中则有不同的意义。同样问题还出现在字符集、二进制数据、对XML文档标签等情景的处理上。

NXDB和XEDB：孰优孰劣

虽然NXDB和XEDB之间的竞争非常直接，但它们孰优孰劣并没有标准答案，而是和具体的应用相关。

在开发格式较简单、数据内容比格式更重要的应用中，XEDB是不错的选择，特别是当原有系统中已经存在传统数据库，而要提供XML访问接口的情况下。相反，如果XML文档格式复杂，数据本身存在层次性关系，或者系统重新开始建立，就可以考虑NXDB，因为它能提供对XML更完备的支持和更好的性能。

由于NXDB在事务、数据恢复等传统数据库技术方面还没有得到时间的检验，所以对数据安全要求较高的一些应用，如银行、金融系统的数据库应用，NXDB并不适合，而这恰恰是XEDB所擅长的。

从技术上来说，NXDB技术发展的时间毕竟还很短，技术基础也不是很牢固，所以相对于XEDB来说，NXDB并没有非常明显的技术优势。只是NXDB的特殊能力使得它在某些领域中具有天生的应用优势，而且随着NXDB相关技术的完善，这种优势会越来越明显，甚至会有所扩张。

XEDB的优、劣势

优势：无需将传统数据库中的原有数据重新移植到新系统中，只需稍加扩展就可以支持XML应用；传统数据库技术，如并发控制、事务处理、结构化查询等已经很成熟；传统数据库知识和经验依然有效，用户无需为了应用XML再去学习一套新的数据库技术。

劣势：XML文档存入到数据库时需要将其分解并进行数据映射，取出时需要重新组合，开销大，且文档的格式可能会改变，甚至丢失某些信息；XML文档和数据库之间的模式转换复杂，在前期开发阶段需要很大投入;对“以文档为中心”、格式复杂的XML文档处理性能较差；在相关XML技术标准的采用方面较滞后。

NXDB的优、劣势

优势：XML文档存取无需模式转换，存取速度快；对格式复杂的XML文档有很好的支持；支持大多数最新的XML技术标准;支持层次化的数据模型;支持基于标签和路径的操作，传统数据库技术采用的查询语言可以对某个特定属性的值进行查询，但是不能对属性的其他特征进行查询（如相对位置等）。而半结构化数据的查询条件则可以包括相关标签的信息，比如标签的父亲结点、儿子结点的信息。

劣势：在传统数据库技术方面比较薄弱，没有经过时间的考验;知识比较新，相应的支持人员和文档资源都比较少;应用范围仅局限在XML应用领域中。

用户:需求决定选择

是采用NXDB系统还是采用XEDB系统，用户可以根据自己的应用开发需求来决定。在选择的过程中，下面一些原则可以帮助用户选择合适的数据库系统。

不同应用类型的需求　NXDB系统更适合处理以文档为中心的XML数据，如数字图书馆、音/视频媒体中心、电子邮件管理、企业信息和知识管理中心等领域的应用；XEDB系统则更适合处理以数据为中心类型的XML文档，文档中的相关数据可以从数据库的关系表中按一定的规则提取。

查询速度要求　当比较查询的速度时，两个影响查询速度的因素是查询空间的范围和对象文档的结构。

存储尺寸和文档粒度要求　目前大多数XEDB系统采取把文档内容以类似BLOB或者CLOB的形式存储在数据库里，同时将BLOB、CLOB数据和存储文档数据的关系表相关联。对那些结构不是很复杂的XML文档来说，这种方法是可行而且有效的。但是为了实现这些功能，数据库系统通常需要提供额外的服务处理映射关系或者其他诸如安全方面的支持，从而存在数据冗余的现象，所以当文档复杂性增加时，数据库存储的磁盘空间和内存开销就会成为一个不可忽视的问题。对NXDB系统来说，由于存储的逻辑单元就是XML文档本身，文档的结构数据不会在存储过程丢失，所以并不存在上面所说的数据冗余，从而比较适合处理复杂多变的文档结构。

静态和动态结构的需求　XEDB一般要求预先确定文档的结构，如果文档结构发生了变化，那数据库系统必须适应这种变化，修改相应的模式定义。对文档结构稳定或者变化范围在人为控制范围之内的应用来说，这种处理方案是可行的。但是如果文档结构的变化是不可知的，那就只能采用NXDB系统，它不要求数据库开发人员事先定义好结构信息。

持久化存储和临时存储的要求　在进行事务处理时，存储在数据库中的XML文档必须经过很多阶段的操作，所以要将数据临时存储。对NXDB系统来说，临时存储的数据也可以用XML文档的形式进行组织，这样就避免了XML文档和关系表数据之间的多次映射过程（尤其是对那些需要对XML文档数据进行多次临时存储的情况）；同时，系统可以借助指定的XML Schema或者DTD对临时数据进行有效性校验。

题外话:NXDB的尴尬之处

前面说到的选择标准完全是从技术角度来评价的，但除了技术因素之外，企业遗留系统的存在，以及传统关系数据库厂商的实力，都会直接影响用户的决定。而且在NXDB不断进步的同时，XEDB也在不断改进。

从关系数据库的发展来看，那些主流厂商一直在增加对对象数据的支持，并不断将Java语言特征加入其关系数据库产品，它们为其关系数据库增加了更多的可扩展性,同样可以存储空间信息、图像、HTML等信息，可以看到，XEDB的市场优势远远超过了只能存取一种数据形式的NXDB。有专家认为，在很长一段时间以内，关系引擎都会非常适合XML数据和非XML数据。

而且XML最终只是数据交换的标准，有人声称，当应用程序数据都开始采用XML格式时，可能就不再需要一个本地的XML数据库来保留它们。

NXDB因为XML而绚烂，但与建立在传统关系数据库之上的XEDB相比，它在人们的心目中始终是一个新事物，甚至到现在，它仍然没有脱去“新人”的印记。所以NXDB目前的境地有些尴尬，不过认为它会“昙花一现”的论调又过于悲观，毕竟不算完美的NXDB还是找到了自己的一席之地，而且正试图继续扩展其应用领域。

（计算机世界报 第11期 B6、B7）