数据库技术在信息管理当中的地位不言而喻，它已经成为先进信息技术的重要组成部分，是现代计算机信息系统和计算机应用系统的基础和核心。数据库技术最初产生于20世纪60年代中期，根据数据模型的发展，可以划分为若干个阶段：从第一代的网状数据库系，到层次数据库系统，到关系数据库系统，到当代的以面向对象模型为主要特征的数据库系统。
当代数据库，[1]尽管由于互联网应用的兴起，导致XML数据的大量出现，但就目前来讲关系型数据库依旧占据主流的地位，可随着数据库更广泛的应用，以及和多学科技术的结合，新的数据库技术是层出不穷，如面向对象与对象-关系数据库系统、移动数据库系统、实时数据库系统、XML和半结构化数据库系统、并行和分布式数据库系统、多媒体数据库等等。本报告将阐述与移动数据库和XML数据库相关的内容。
一. 移动数据库的由来
社会进入信息时代，人们的生活方式也发生了巨大的变化，现代科技已经为人们的交流和沟通提供了方便的工具，时代要求人们随时随地访问信息并得到服务，实现无约束自由通信和共享资源的理想目标，这是一种更加灵活、复杂的分布计算环境，人们称之为移动计算(Mobile Computing) 。移动计算系统不同于传统分布计算系统，它是由固定结点和移动结点构成的分布计算系统，具有移动性，频繁断接性，网络条件多样性、网络通信的非对称性、系统的高伸缩性和低可靠性以及电源能力的有限性等特点。这些特点使得传统的分布式数据库技术不能支持或是不能有效地支持移动计算环境。因此，必须对已有的传统的分布式数据库加以改进，或者重新设计，形成一种能全面支持移动计算环境的数据库技术，即移动数据库(Mobile Database)。[5]
二. 移动数据库典型系统模型
移动数据库系统由三类结点组成，即：
(1 ) 服务器( Server，简称SVR) ： 一般为固定结点， 每个服务器维护一个本地数据库，服务器之间由可靠的高速互联网络连接在一起，构成一个传统意义上的分布式数据库系统。 服务器可以处理客户的联机请求， 并可以保持所有请求的历史记录。
(2) 移动支持结点(Mobile Support Station ， 简称MSS) ：MSS 也位于高速网络中，并具有无线联网能力，它们用于支持一个无线网络单元(cell) ，该单元内的移动客户机既可以通过无线链路与一个MSS 通信， 从而与整个固定网络连通，也可以接收由MSS 发送的广播信息。 服务器与MSS 可以是同一台机器。
(3) 移动客户机(Mobile Client ，简称MC) ：MC 的处理能力与存储能力相对于服务器来说非常有限，且具有移动性(即可以出现在任意一个无线单元中) ，经常与服务器断接(指MC 无法与服务器联机通信) 。 即使在与服务器保持连接时，由于MC 所处的网络环境多变，MC 与服务器之间的网络带宽相差很大，且可靠性较低、网络延迟较大。
三. 移动数据库技术的发展现状以及发展趋势
1. 移动数据库的关键技术
移动数据库涉及的理论和技术涵盖了当今通信和计算机发展的最新成果,其中,在移动环境下如何进行数据管理是实现移动数据库的关键,根据目前国际上有关机构的研究表明,这些关键技术主要集中在如下几个方面: 复制与缓存技术，数据广播技术，移动查询优化和事务处理技术，移动数据库的安全技术。[5]
2. 嵌入式移动数据库，移动数据库系统中的一个组成部分
翻阅诸多资料，发现不少作者笼统地把嵌入式移动数据库和移动数据库混为一谈，甚至说嵌入式移动数据库简称为移动数据库。我发现其实这两者是相关而不相同的概念。
我认为移动数据库是一个更为抽象一点的概念。我们可以理解凡是涉及移动环境中所需的数据库，就可以称为移动数据库。而嵌入式移动数据库的概念我认为是在移动技术应用环境中所产生的一个概念。由于人们面向不同的应用而去开发移动数据库时，数据库的管理模型设计得有所不同，有的数据库模型用分布式的特点，有的使用智能代理，有的用B/A/S多层结构等等。而目前移动数据库比较典型的应用模式是三级数据库应用模式。下面两个图一个给出一个比较典型应用的三级移动数据库系统结构图，[12]另一个则清晰地表示出在数据库三级应用模式中嵌入式移动数据库系统部分。[4] 可以看到，人们将嵌入于移动设备当中的数据库部分称为嵌入式移动数据库，它只是整个移动数据库系统中的一个组成部分。
(1) 数据库服务器DBSVR (Database Server) : 可以是大型数据库系统, 如: O racle, Sybase, DB2, SQL Server, 一般为固定结点。每个DBSVR 上维护本地数据库的一个完整的副本, 服务器之间由可靠的高速互联网连接在一起, 构成一个传统意义上的分布数据库系统。
( 2 ) 移动支持结点MSS (Mob ile Suppo rt Stat ion ) : 进行分布式事务处理, 控制EMDB 和DBSVR 之间的数据交换并支持一个无线单元(cell) , 具有无线联网能力和同步功能,MSS 也位于高速网络中。服务器可以与MSS 为同一台机器。
(3) 位置服务器L S (Locat ion Server).
(4) 可信部分: 由固定网络以及网络上的固定主机组成, 固定主机分为两类: 一类是不带无线通讯的主机, 如DSSVR 和LS; 另一类是带有无线通讯接口MSS.
(5) 移动客户机MC (Mob ile Clien t) :MC 的处理能力与存储能力相对于服务器来说非常有限, 且具有移动性(即可以出现在任意一个无线单元中) , 在它上面保存一部分数据库副本, 并通过EMDB 对本地数据进行管理, 可以通过无线链路与一个M SS 通信, 通过M SS 上的ODBC 接口, EMDB 可以与DBSVR 进行数据交换。从而与整个固定网络连通, 也可以接受由MSS 发送的广播信息。它会经常与服务器断接(指MC 无法与任意一个联机通信) 即使在与服务器保持连接时, 由于MC 所处的网络环境多变,MC 与服务器之间的网络带宽相差很大, 且可靠性较低, 网络延迟较大。
(6) 本地数据库Rep (Rep licat ion) : 数据库副本。
(7) EMDB: 嵌入式移动数据库, 工作方式为: 每当MC 发出一个查询请求Q 1 时, 它首先查询本地数据库(移动子集上) , 若满足查询条件要求则直接返回给MC, 否则就向VS 提交查询请求, 由VS 代替MC 完成查询并将结果返回给MC (前提是两者处于连接状态)。若MC 处于断接状态, 则也只能在MC 上执行本地查询。若在断接期间更新了MC 上的数据, 则该数据将在VS 再次连接时, 进行数据重集成, 通过一致性维护算法来保证一致性。[12]
主要EMDB 的应用模式都是立足于嵌入式设备作客户端, 在嵌入式设备上运行一个精巧的EMDB, 在通过同步或复制技术与企业级数据库连接。这种应用模式在支持嵌入式设备的同时, 还支持移动设备, 甚至无线移动设备, 构成基于移动环境的应用。在数据库三级应用模式中, EMDB 系统一般采用EMDB + 同步/复制服务器+ 企业级DB, 如图2 所示。
3. 移动数据库技术的发展现状:从研究走向应用
移动数据库技术固然还存在有待于进一步研究改进的地方，不过随着市场的需求，以及技术研究方面取得的诸多成就，移动数据库技术已经从研究领域向广泛的应用领域发展。各种嵌入式移动数据库产品纷纷涌现。尤其是对移动数据处理和管理需求的不断提高，紧密结合各种智能设备的嵌入式移动数据库技术已经得到了学术界、工业界、军事领域、民用部门等各方面的重视，不断实用化。[7]
4. 嵌入式移动数据库应用中的特点和关键技术
从上述的嵌入式移动数据库的数据管理模式中，可以看到嵌入式移动数据库是一个一端嵌入在移动设备中，另一端是固定的同步/复制数据库的分布式数据库系统。移动设备这端的数据库一方面需要进行移动终端设备上的数据处理查询事务等，一方面解决和同步/复制数据库的数据一致性问题，而同步/复制数据库则既要和移动终端交互，也要和企业DB进行交互。嵌入式移动数据库管理系统在移动计算的环境下应用在嵌入式操作系统之上，由于移动设备的资源限制，它一般和应用系统集成在一起，作为整个应用系统的前端而存在，而它所管理的数据集可能是后端服务器中数据集的子集或子集的副本，所以它有自己的特征以及必须要解决的关键技术：[7][18]
l 微小内核结构：考虑到嵌入式设备的资源有限，EMDBMS应采用微型化技术实现，在满足应用的前提下紧缩其系统结构以满足嵌入式应用的需求。
l 事务处理：EMDBMS应具有事务处理功能，自动维护事务的完整性、原子性等特性；支持实体完整性和引用完整性，但事务处理应尽可能地简单化，在整个应用系统中可能需要结合移动计算环境的特征进行事务处理控制。
l 备份恢复：嵌入式数据库的备份和恢复与大型DBMS管理数据库不同，不能简单以独立的服务或类似形式进行，而要按照某种简化方式完成。EMDBMS应具有自动恢复功能，基本无需人工干预进行嵌入式数据库管理并能够提供数据的备份和恢复，保证用户数据的安全可靠。
l 完善的数据同步机制：数据同步是嵌入式数据库最重要的特点。通过数据复制，可以将嵌入式数据库或主数据库的变化情况应用到对方，保证了数据的一致性。移动数据库的一个显著特点是移动终端之间以及与服务器之间的连接是一种弱连接，即低带宽、长延迟、不稳定和经常性的断开。为了支持用户在弱环境下对数据库的操作，现在普遍采用乐观复制方法（Optimistic replication 或 Lazy replication）允许用户对本地缓存上的数据副本进行操作。待网络重新连接后再与数据库服务器或其他终端交换数据修改信息，并通过冲突检测和协调来恢复数据的一致性。
l 支持多种连接协议：EMDBMS应支持多种通信连接协议。可以通过串行通信、TCP/IP、红外传输、蓝牙等多种连接方式实现与嵌入式设备和数据库服务器的连接。
l 支持多种嵌入式操作系统：嵌入式移动DBMS应能支持Windows CE、Palm OS等多种目前流行的嵌入式操作系统，这样才能使嵌入式移动数据库管理系统不受移动终端的限制。
l 安全性：许多应用领域的嵌入式设备是系统中数据管理或处理的关键设备，因此嵌入式设备上的数据库系统对存取权限的控制较严格。同时，许多嵌入式设备具有较高的移动性、便携性和非固定的工作环境，也带来潜在的不安全因素。同时，某些数据的个人隐私性又很高，因此在防止碰撞、磁场干扰、遗失、盗窃等对个人数据安全的威胁上需要提供充分的安全性保证。保证数据安全的主要措施是 ：第一，对移动终端进行认证，防止非法终端的欺骗性接入 ；第二 ，对无线通信进行加密，防止数据信息泄漏 ；第三，对下载的数据副本加密存储，以防移动终端物理丢失后的数据泄密。
l 系统快速启动：嵌入/移动设备的系统可靠性和可用性相对于固定主机而言一般相对偏低，因此发生系统故障的概率可能大大提高。因此，在这样的计算环境或计算平台上必须保证系统在发生不可软件纠错的情况下能够通过硬件进行系统的快速启动。
l 接口简明实用：EMDBMS和应用一体，必需提供支持应用开发的接口。
l 支持JAVA技术：目前在很多智能手机上有基于Java的开发应用，应该考虑Java或类似支持。
l 有效的系统处理优化：在硬件存在较强限制的情况下，EDBMS必需实现某些查询优化技术，如使用简单索引等。
l 此外，如果系统所嵌入的某种移动设备支持实时应用，则嵌入式数据库系统还要考虑实时处理的要求。这是因为设备的移动性，如果应用请求的处理时间过长，任务就可能在执行完成后得到无效的逻辑结果，或有效性大大降低。因此，处理的及时性和正确性同等重要。
l 另外，一种理想的状态是用户只用一台移动终端（如手机）就能对与他相关的所有移动数据库进行数据操作和管理，这就要求前端系统具有通用性，而且要求移动数据库的接口有统一、规范的标准。前端管理系统在进行数据处理时自动生成统一的事务处理命令，提交当前所连接的数据服务器执行。这样就有效的增强了移动数据库的通用性，扩大了嵌入式移动数据库的应用前景。
5. 嵌入式移动数据库的发展趋势
从目前嵌入式应用的发展趋势来看，嵌入式移动数据库技术将使得数据库技术更为客户化（可定制）和平民化，即：系统选择的技术路线要面向具体的行业应用，不能走“大而全”的通用的路线。[7]
四. XML和XML数据库
1. XML
XML称为可扩展标记语言(eXtensible Markup Language)。它是从标准通用标记语言SGML (Standard Generalized Markup Language) 简化并改进而来的一种新的描述型标记语言，由W3C组织发布的标准。W3C组织制定XML标准的初衷是，定义一种互联网上交换数据的标准。而由于XML语言自身简单、开放、可扩展、灵活、自描述等特性，如今XML在数据库的学术领域以及在商业应用领域都占据了及其重要的位置。
2. XML的几个重要特性
可扩展性。XML是设计标记语言的元语言，它允许用户根据自己的需求，甚至允许各企业各行业或者特定的工业界，根据自身领域的独特需要制定属于该领域的一套特殊标记，以创建在该领域内信息共享与交换的基础。如用于数学表达式描述的MathML，用于生物信息描述的BSML等等。
自描述性。XML文档是自描述的，不仅人能读懂XML文档，而且计算机也能处理。XML文档中的数据可以被解析程序所提取、分析、处理，并使用所需格式显示。XML表示数据的方式真正做到了独立于应用系统，并且这些数据能重用，所以XML适合开放的信息管理。因为它的自描述性，文档里的数据可以由XML能使的（XML-aware）应用来创建、查询和更新，跟处理传统的关系型数据库、面向对象数据库里的数据类似。XML甚至还能用来表示那些以前不被看作文档但是对传统的数据库来说又过于复杂而难以处理的数据。所以，XML文档被看作是文档的数据库化和数据的文档化。
3. XML数据库
XML 之所以可以被称为数据库，我们可以从Ronald Bourret那篇著名的《XML AND DATABASE》一文中得知。XML文档本身是数据的集合，并且在某种程度上，XML和与之相关的周边技术的相结合可以说是组成了一个数据库管理系统, 它包括四个方面，一是数据存储，XML文档相当于XML 数据库的数据区, 一个XML 文档就是一个基本的存储单元, 相当于关系数据库中的一个表格；二是模式，DTD或是 XML schema等等是XML 数据库的逻辑模型的描述；三是查询语言，Xquery、 Xpath、 XQL、 XML-QL、 QUILT等等都可以充当XML数据库的查询语言；最后是编程接口，通过SAX和DOM这两种编程接口，可以实现对XML数据库的诸多管理功能。而今XML 数据库在技术上已经有了长足的进步，已经从最初简单的查询引擎，不断地加入查询优化、事务处理、触发器、并发控制、代数系统等传统的数据库技术，一步步地从性能和功能上完善自己。[36]
4. XML 数据库产品的分类
对于XML 数据库产品分类, Ronald Bourret在他的《XML Database Products》中[35]，将XML数据库产品分为中间件（Middleware）、支持XML的数据库（XML-Enabled Databases）、原生XML数据库（Native XML Databases）、XML服务器（XML Servers）、Wrappers、内容管理系统（Content Management Systems）六种，在业界影响很大。但是在XML数据库的研究和开发人员眼里，大多比较赞同三类分法：原生XML数据库、支持XML 的数据库、混合XML 数据库，或者是两类：原生XML数据库、支持XML 的数据库。在这里我主要介绍论文中可能会涉及到的三种数据库产品：原生XML数据库、支持XML的数据库、XML服务器。
什么是原生XML数据库呢？它是专门设计用于存储XML 文档的数据库, 它以XML 文档自身的形式来存储XML 文档, 支持事务、安全、多用户访问、编程的A P I 和查询语言等, 其内部模型是基于XML 文档格式的。
支持XML数据库是传统的关系和面向对象数据库的扩展, 是在传统数据库的基础上, 由数据库厂商或是第三方增加了XML 映射层, 由这个映射层管理XML 数据的存储, 实现传统数据库与XML 文档之间的转换, 特别适合以数据为中心的应用。
至于XML服务器是什么？我们知道传统的Web服务器都是基于HTML文本进行信息传送的，随着XML技术的出现，对于基于XML的Web服务器的需求也就产生了。那么到底什么是XML服务器呢？准确定义XML Server这个概念是困难的，因为这实在是一个比较新，而且概念很广泛的东西，虽然已经有许多的产品称自己为XML Server，比如DataChannel公司的DataChannel Server 4.1；Software AG公司的Tamino；Excelon公司的excelon，但在应用的范围上以及功能上，每种产品都各不相同，因此这里也就不为XML Server进行定义，而是归纳这几种产品的共同拥有的一些特点，以说明的方式来向大家解释XML Server这个概念。 简单地讲，XML Server是一个提供数据的平台，它能够以XML文档的形式与分布式的应用进行数据交互。比如电子商务这一类的应用。这听上去和传统的数据库非常的相似，它和数据库一样提供数据的存贮与提取功能，但数据的格式的是基于XML的，因此在数据的处理方面，所用的是和传统数据库完全不同的技术了，XML服务器通常包括了一个完整的应用开发环境，并通过各种数据存储方式来使应用程序可以方便的获取和使用这些数据。存储的数据包括传统的数据库数据、电子邮件信息和文件系统等等。
五. 与XML相关的技术问题
1. 文档类型
我们认为存在两种类型的XML文档，以数据为中心的文档（data-centric documents）和以文档为中心的文档(document-centric documents)，区分它们的目的在于它们各自不同的特性将影响到我们如何选择XML在数据库中的存储方式。
以数据为中心的文档：数据为中心的文档有非常规则的结果，比如关于销售订单或者是饭店菜单的XML文档。以数据为中心的文档通常是为机器设计的，也就是说主要是方便机器进行处理。通常，任何Web站点可以动态的构建HTML文档，其步骤如下，根据用户的查询请求找到相关的面向数据的XML文档，然后通过XSL对XML文档进行转化，让基于HTML的浏览器能够方便的浏览结果。
以文档为中心的文档：以文档为中心的文档具有不规则的结构，而且数据的粒度也比较大。具体的例子如书本、电子邮件、广告等等。以文档为中心的文档主要是用人类而设计的。
在现实当中，以数据为中心和以文档为中心的文档之间的差别不一定很明显。例如，另一种以数据为中心的文档比如发票，可能含有大粒度的、结构不规则的数据比如零件说明；另一种以文档文中心的文件如用户手册，可能包含细粒度的结构规则的数据（通常为元数据）比如作者和修订日期。其它例子包括法律和医学文书，虽然以松散的形式写成但是却包含离散的数据块例如日期、名称和操作程序，出于法规的原因通常要以完整的文件形式存储。
2. 文档的存储
数据采用XML格式的优势便在于能够很好地表达数据的结构和内容，不管XML文档是以数据为中心，还是以文档为中心，也不论以数据为中心的是结构化数据还是半结构化数据，最终我们都需要考虑的问题是如何将XML表达的数据很好地保存下来，当然这就涉及到文档存储的问题了。专家们在这个方面提出一些建议，可以描述如下：
以数据为中心的我们通常将数据存储于传统的数据库，例如关系型，面向对象型或层次型数据库。这可由第三方的中间件完成数据转换或由数据库本身提供内在支持（即支持XML数据库）来实现数据格式的转换和存储。但对于半结构化数据，如果将其映射到关系数据库，结果是要么出现大量空值(null)的字段，要么表格的数量过多，浪费空间或效率低下。虽然半结构化的数据可存储到面向对象的或层次型数据库中，或是存入关系数据库的BLOB中，不过也可以选择将它以XML文件的形式存储于原生XML数据库。
以文档为中心的，可被存储在原生XML数据库（专为存储XML而设计的数据库）或内容管理系统(建在原生XML数据库之上专门用来管理文档的程序)。不过也可以存储到支持XML的数据库中，这时通常不需要映射，而是以BLOB的形式将XML文档写入关系数据库的表中。
3. 文档和数据库之间的转换
在我们上述提到的将XML文档存储到传统数据库中，或是从数据库中取出数据，结果文件要被转换成应用程序所需的XML文档，另外利用XML文档做为数据库之间的数据中介，这些时候完成XML文档和数据库之间的转换软件是通过XML文档和数据库之间的映射来完成的。这种映射分成两种：模板驱动和模型驱动。
模板驱动的映射：事先文档和数据库之间没有预先的映射，而是在数据转换软件处理的模板中嵌入命令，通用数据传输中间件进行处理。比如，考虑下面的模板：
<?xml version="1.0"?>
<FlightInfo>
<Introduction>The following flights have available seats:</Introduction>
<SelectStmt>SELECT Airline, FltNumber, Depart, Arrive FROM Flights</SelectStmt>
<Conclusion>We hope one of these meets your needs</Conclusion>
</FlightInfo>
注意其中嵌入了一个SELECT语句。当用数据传输中间件进行处理的时候，每一个SELECT语句都会被它的结果所代替，用XML格式化形式表现为：
<?xml version="1.0"?>
<FlightInfo>
<Introduction>The following flights have available seats:</Introduction>
<Flights>
<Row>
<Airline>ACME</Airline>
<FltNumber>123</FltNumber>
<Depart>Dec 12, 1998 13:43</Depart>
<Arrive>Dec 13, 1998 01:21</Arrive>
</Row>
...
</Flights>
<Conclusion>We hope one of these meets your needs.</Conclusion>
</FlightInfo>
基于模板驱动的映射可以是相当灵活的，比如，一些产品允许你把结果集放到XML文档的任何位置，同时可以对SELECT语句设置参数，并且可以使用for循环语句和if条件语句等。值得注意的是，当前基于模板驱动的映射只能应用于在关系数据库和XML文档之间传递数据。
模型驱动的映射：是指XML文档中的数据根据预先定义的模型，明确或者隐含地把数据映射到数据库中。在XML文档中，这两种模型是很常见的：表格模型(table model)和专用数据对象模型(data-specific object model)。
表格模型是基于表格的映射，许多中间件软件包用表格模型在XML文档和关系数据库之间传递数据。它把XML文档表示为一个单一的表格或者是表格的集合。这样，一个XML文档的结构可以用如下的形式表示：
＜database＞
＜table＞
＜row＞
＜column1＞...＜/column1＞
＜column2＞...＜/column2＞
...
＜/row＞
...
＜/table＞
...
＜/database＞
这里关键字"talbe"在把数据从数据库传递到XML文档的时候，表示一个单一的结果集，把数据从XML文档传递到数据库的时候，表示表示一个单一的表格或者视图。但是，当结果集合不只一个的时候，或者当XML文档包括多个复杂嵌套的时候，这种传递方式就不能适应了，并且这种转换不能保留文档的物理结构（如字符和实体引用、CDATA部分或字符编码）、文档信息（如文档类型或DTD）、注释信息和处理指令等。
专用数据对象模型也就是基于对象-关系的映射，它用于支持XML的关系数据库和一些在XML文档和关系数据库之间转换数据的中间件产品中。在这个模型中，将XML 文档中的数据作为一个对象树，把具有属性的元素类型、元素内容或混合内容（复杂数据类型）作为类进行建模，把仅具有PCDATA内容的元素类型（简单数据类型）、属性和PCDATA 作为分级属性进行建模， 然后使用传统的对象--关系映射技术或SQL3 视图将这个模型映射到关系数据库，其中类被映射成一个表，分级属性映射成表中的字段列， 对象值的属性被映射成主键/外键对。在XML 文档、对象和数据库表之间有着明显的对应关系，如下所示：
XML文档元素A 对象 A
<A> OBJECT A{
<B>DATAB</B> B=”DATAB”
<C>DATAC</C> C=”DATAC”
<D>DATAD</D> D=”DATAD”
</A> }
实际上在XML和数据库之间进行数据转化的时候，需要考虑两个过程：一个是从数据库模式中产生DTD，另外一个是根据DTD生成数据库模式
从一个DTD中生成一个关系模式的步骤如下：
l 对每一个元素，产生一个表和一个主键列。
l 对每一个有混合内容的元素，产生一个独立的表格，用来存储PCDATA，并通过父表的主键和父表相联。
l 对元素类型中的每一个单一值的属性，对具有只有PCDATA内容的子元素（该子元素按顺序出现），产生一个单独的列，如果子元素类型或者值是可以选择的话，该列就应该可以允许为NULL类型。
l 对有多个值的属性和可以出现多次的子元素（该子元素PCDATA）的话，需要创建一个单独的表来存储这些值，并通过父表的主键和父表相联。
l 对每一个包含元素或者混合内容的子元素来说，通过父表的主键把父元素和子元素联接起来。
从一个关系数据库模式构建DTD步骤如下：
l 对每一个表，创建一个元素。
l 对表中的每一列，创建一个属性或者是一个只有PCDATA 内容的子元素。
l 根据表中的每一主键／外键关系，创建该表元素的子元素。
- 查询语言
自从1995年XML技术的研究和开发逐渐升温以来，形形色色的XML查询语言不断问世。比较有代表性的如早期的XML-QL、XQL、UnQL，后来的Quilt、Xpath，以及由Quilt发展而来的XQuery。在W3C的极力推动和学术界、工业界的大力支持下，XQuery逐渐在这些查询语言中脱颖而出，成为事实上的工业标准。 XQuery的FLWR语句规范，有着与关系数据库的SQL完全类似的表达方式，使得它在一般用户眼里，也变得友好起来。而Xpath可以理解为是XQuery的一个子集。Xpath表达式在相关文献中被证明与查询模式树是等价的，这也与学术界推崇的模式树查询方式一致，使得实验室系统可以毫不困难地处理Xpath查询表达式，并能进行查询优化，这一点在XML数据库研究中显得颇有价值。
- 文档解析
对于XML文档之上的任何处理，比如转换后装入数据库，或是查询，都会经过一个XML数据解析器。数据解析器会依据一定的规则对XML数据进行解析后完成相应的应用。目前的数据解析器一般提供SAX（simple API for XML）和DOM（document object model）两种方式。SAX和DOM是针对XML文档的两种不同的应用程序编程接口API。目前的XML数据库产品均支持这两种解析方式。
DOM解析器由W3C制定的标准。它的解析过程是将整个XML文档读入，然后构建一个驻留内存具有层次的树结构，应用程序则可用DOM提供的一组接口来操作这个树结构，因而DOM被认为是基于树或基于对象的解析。DOM最大的问题是解析后得到的DOM文档非常大，DOM文档与XML文档长度之比很容易超过10（实际的系数取决于文件中文本的平均长度，文本的平均长度较小的文件其系数较高），显然这对于大型的XML文档来讲，采用DOM解析会要求有极大的内存，因而一定程度上受内存容量的限制，此外DOM解析器必须在代码运行前读取整个文档，对于非常大的文档，若用户只关注文档的小部分内容，那么创建那些永远不被使用的对象是极其浪费的，而且大文档还会引起显著延迟。
为了解决DOM问题，XML-DEV邮件列表成员创建了SAX接口。SAX是基于事件的解析，SAX采用一种顺序访问快速读写XML数据的方式，解析文档时，会针对不同对象触发一系列事件，并激活相应的事件处理函数（程序员编写），从而完成对XML文档的访问。由此可见，SAX的解析器不创建任何对象，而是让你自己决定采用什么类型的数据结构来保存来自这些事件的数据，不需要的就丢弃，另外当你找到自己需要的数据后，可以抛出一个异常，停止SAX解析器，因而不需要访问完整个文档，SAX解析器是边读入边解析，带有一定的实时性，特别适合于XML流数据的处理。当然我们同样也看到SAX的不足，SAX事件是无状态的，事件仅仅给你发现的文本，但它不会告诉你什么元素包含这文本，你必须自己编写状态管理代码；另外SAX事件不是持久的，这点不同于DOM，DOM解析一次，所有的数据可以持久的保存下来，SAX解析XML文档是顺序进行的，解析过程中事件不断发生，用户需要自己编写代码把事件传递过来的数据保存下来，如果没有把数据存下来，那么对于分析过的数据就没法再去处理，只能重新进行一次解析。
针对DOM和SAX的各自优缺点，对于大型的XML文档，我们往往采用先使用SAX解析，获取所需的部分数据，而后对结果数据（XML文档）采用DOM解析。
六. 有关原生 XML 数据库
人们已经越来越倾向于认为XML数据库就是原生XML数据库。
1. 什么是原生 XML数据库？
出自XML:DB mailing list的一个成员这样定义原生XML数据库：它为 XML 文档（而不是文档中的数据）定义了一个(逻辑)模型，并根据该模型存取文件。这个模型至少应包括元素、属性、PCDATA 和文件顺序。这种模型的例子有XPath数据模型、XML Infoset 以及 DOM 所用的模型和SAX 1.0的事件。它以 XML 文件作为其基本(逻辑)存储单位，正如关系数据库以表中的行作为基本(逻辑)存储单位。它对底层的物理存储模型模型没有特殊要求。例如，它可以建在关系型、层次型或面向对象的数据库之上，或者使用专用的存储格式，比如索引或压缩文件。
2. 原生XML数据库的结构
原生XML数据库的结构可分为两大类：基于文本的和基于模型的。
基于文本的原生XML数据库将XML作为文本存储。它可以是文件系统中的文件、关系数据库中的BLOB或特定的文件格式。（事实上，就其能力来说，一个增加了支持CLOB(Character Large Object)字段的XML处理功能的关系数据库也可以是原生XML数据库了。）
基于模型的原生XML数据库。它们不是用纯文本存储文件，而是根据文件构造一个内部模型并将这个模型存储于数据库。这类原生XML数据库的文件存取性能与这些数据库相似，原因显而易见，其存取要依赖这些数据库。但是这个数据库，特别是建立在其他数据库之上的原生XML数据库的设计有很大的变化余地。
3. 选择使用原生XML数据库的几个理由 [25] [48][49]
l XML是元语言。XML 能定义并且描述任何种类的信息。
l XML支持多种语言。XML是基于UNICODE的。
l 实现数据的多样性显示。用户获得一份XML数据，可以根据不同需要进行多样化的呈现。比如，对一段数据，可以显示成文本，也可以用表格显示，甚至用语音读出。
l 对数据尤其是半结构化数据（如网页、书信等）具有有力描述和搜索能力。XML允许嵌套定义，可以描述复杂结构的数据。
l XML是基于文本的，容易读出。根据XML数据库存储数据的物理方式的不同，数据的读出速度可以做到比关系型数据库的读取速度快得多。
l XML是开放的，获得几乎所有主流数据库的支持，容易实现不同数据源的数据交换和集成。
l XML有助于电子商务的发展。以往电子商务采用的数据交换技术是EDI，这是一项成本昂贵的技术，对多数企业来说采用EDI是困难的，XML的到来显然降低这种难度。我国已投入去制订基于XML的电子商务标准。
4. 原生XML数据库核心技术的发展 [36]
l 数据存储
在XML数据库研究的早期，业界曾存在一个争论，到底将XML数据存储在关系库中，还是另外开发存储XML的物理数据库。这在一定程度上影响着XML的研究者，在设计索引结构时必须考虑使索引过的XML数据可以存储在多种数据库结构中。现有的主流XML数据库产品都在底层提供collection数据结构，以存储XML元素节点，通过B+树结构来索引这些元素节点。这一点与关系库系统的底层处理如出一辙。在collection之上一般还会有一级或两级索引，以加快查询处理速度，比较高效实用。
l 查询处理
查询处理的方式和效率，一直是XML数据库研究和开发者关注的首要问题。
XML数据库的查询处理一般是从解析查询语言（如XQuery）的查询语句表达式开始的。XML数据库的查询解析器将表达式解析为一棵查询模式树（有的系统叫做语法树）。在如何匹配模式树的技术上，出现了几种新的技术。比如，在Timber中，提出了一种叫做“结构化联接”的技术，在学术界引起过较大的反响。自2002年以来不断有技术上的改进文章出现在数据库的三大国际会议（VLDB、SIGMOD/PODS、ICDE）上，其中较有影响的成果是隐检整枝联接（holistic twig join）技术，可以用相互连接的多栈结构一次性生成查询结果文档。
在查询处理阶段，研究模式树的最小化。它的主要思想就是，模式树的匹配效率依赖于模式树的规模（元素节点的多少）。而一般的模式树均存在一定量的冗余节点，可以通过最小化算法予以去除。根据复旦大学数据库研究中心XML小组的实验结果表明，在随机建立的XML查询模式树集合中，最小化算法平均可以消除30%的冗余节点。 当然，模式树最小化算法的时间复杂度比较高，目前的关注点主要在于时间复杂度的降低上。最新算法的时间复杂度已经降低到低阶的多项式时间了。这项技术的实用化是值得期待的。
l .事务处理和版本控制
事务处理应该遵循ACID性质 (原子性、一致性、独立性和持久性) 以保证大部分事务处理稳定地运行。
目前的XML数据库一般提供事务处理功能，包括提交、撤回和日志文件。XML数据库通过提供事务日志机制，纪录系统执行的每个事务的详细情况，保证在系统出现问题后可以完全恢复。
XML数据库还包含对XML文档的版本控制功能。使用版本控制，用户或应用程序可以检入(check in)或检出(check out)XML文档，利用版本号、日期或者标签获得以前版本的文档，以及显示XML文档的版本历史信息。每一个处于版本控制之下的文档都有自己的历史信息，纪录了修改文档的作者以及时间等。使用者可以根据文档或用户或日期来查看整个的版本历史信息。版本控制允许用户通过查询更新原信息。通过更新引擎可以注释、修改和精炼信息。内置的版本系统跟踪信息的变化，提供这些变化的历史信息。
有一个需要说明的是多事务并发控制机制和加锁协议。这项技术的研发目前刚刚起步。现今的商用XML数据库只在逻辑层面提供并发加锁协议，但粒度为整个文档。随着单个XML文档的增大，这个粒度显然太粗。这一点可能要等待研究界开发出粒度为文档元素节点的并发协议了。
l .代数系统和模式规范化
代数表达式和数据库模式设计理论曾经是关系数据库理论的精髓。代数系统成为关系库查询优化的重要工具，而范式理论的提出也曾为RDBMS设计优化的库结构提供了依据。那么，人们不禁要问，在XML数据库中是否存在相类似的理论和方法？
学术界公认的三大实验系统（密歇根大学安阿伯分校的Timber、西雅图华盛顿大学的Tukwila和威斯康星大学麦迪逊分校的Niagara）都设计了相应的代数系统，其中影响最为广泛的是Timber中实现的TAX（Tree Algebra for XML）。TAX以整个文档树作为操作的基本单位，在逻辑层提供选择、投影、联接等类似关系库的9种基本操作和5种附加操作，以匹配模式树得到实例树（witness tree）为基本操作方法。在物理层提出7种基本操作实现上述逻辑运算。
Timber依据TAX对XML查询语句进行改写和优化，但是效果并不理想。业界对TAX存在问题的看法是，过分地模仿了关系库的代数系统而忽略了对XML文档本身特点的考虑。
XML模式规范化理论的早期开拓者是宾夕法尼亚大学的樊文飞等人。从定义XML的键（key）和函数依赖，到XML和DTD范式，再到基于约束的XML数据库的模式规范化，XML数据库的模式规范化理论在稳步地推动着。国内的复旦大学数据库研究中心等单位也有着不错的研究进展。在未来两年内，估计会有较成熟的XML数据库模式设计理论投入到实验室产品和商用系统中。
l 多数据源的集成
多数据源的集成是数据库市场对XML数据库系统提出的要求。而进行多数据源的集成恰恰是XML数据库的优势之一。 从2001年以后，面对多数据源的集成这个传统关系型数据库系统做不了的事情，Ipedo等商用数据库系统将自己的数据库系统扩展为一个集成平台，它可以将关系数据库系统、MIS系统、OA系统、文件系统等集成在同一个平台上，给用户提供统一的界面。如Ipedo公司的Ipedo XML智能平台，为用户提供XML View来统一访问底层的异构数据。人们也从这一点上进一步看到了XML技术的力量。
5. 未来的技术发展方向
经过近5年业界同仁的共同努力，XML数据库技术取得了很大的进展，已经有若干种XML数据库产品问世并服务于社会生活的各个方面。但是，XML数据库的事业才刚刚开始，还有很多问题等待着我们去解决。 未来几年，XML数据库技术有可能在下述方面取得进展：
● 异构数据源的集成。XML数据库对多数据源的集成，是对XML技术可扩展性这一长处的极好发挥。但是，就目前的集成程度和在应用层上所提供的功能来看还是远远不够的。如何从对数据的集成过渡到对系统的集成，从而在远景目标上实现类似于网格计算（grid computing）概念的系统，恐怕是XML数据库工作者的核心任务之一。
● 底层索引结构。目前的商用XML数据库系统优于实验室原型系统的特点之一就是其底层的索引结构。但是，现有的商用XML数据库的底层索引结构一般都是B+树。虽然B+树索引是一种成熟的索引结构，但是，研究结果显示，在XML数据库中，它的性能表现并不是最好的。学术界已经开发出了若干种适用于XML数据的索引结构，如XR树、XB树等，需要XML数据库工作者来进一步关注。
● 并发加锁协议。在现有的XML数据库系统中，加锁的粒度是整个文档，事务并发的层次也在文档一级。随着应用级文档的日益增大，这个粒度在一定程度上将会成为系统效率的瓶颈。如何通过边锁（edge lock）机制来实现元素节点级粒度的加锁？这一工作现在吸引了不少研究者的目光,而且，上述的锁协议是在逻辑层，如何将它映射到底层的B+树索引（或者XR树索引）上，也是必须要做的一件事情。
● XML模式规范化是一个值得关注的方向。一旦取得突破，将会使我们可以像在关系库中那样方便地设计XML数据库的结构，消除数据的冗余和不一致现象。目前，这一领域已经成为学术界关注的热点。但是，完整的、为业界所公认的理论体系尚未建立。
七. 和移动或者嵌入式系统有关的原生XML数据库产品列表
| 产品 | 开发者 | 数据库类型 |
| Berkeley DB XML | Sleepycat Software | Key-value |
| Birdstep RDM XML | Birdstep | Object-oriented |
| TEXTML Server | IXIA, Inc. | Proprietary (Text-based) |
| AGiLiENCE XPEERION mobile XML | AGiLiENCE | 不详 |
八. 参考文献
[1] 向海华 数据库技术发展综述 [J]现代情报 2003，（12）
[2] 王珊 丁治明 张孝 移动数据库及其应用 [J] 计算机应用 2000，（9）
[3] 李东 曹忠升等 移动数据库技术研究综述 [J] 计算机应用研究 2000，（10）
[4] 王彤 王良 嵌入式移动数据库的综述及评价 [J] 计算机工程 2001，（12）
[5] 王宗江 乐嘉锦 移动数据库的最新发展 [J] 郑州纺织工学院学报 2001，（2）
[6] Jacob Christfort 移动和分布式解决方案 [N]计算机世界报 第11期 B2
[7] 李安渝 林立杰等 嵌入式移动数据库：从研究走向应用 [J] 中国计算机报 2003，（2）
[8] 冯玉才 李东等 一种移动数据库管理系统的体系结构 [J] 计算机研究与发展 2001，（5）
[9] 林怀忠,陈纯,等 移动环境下事务一致性的动态实现 [J] 计算机研究与发展 2002,（1）
[10] 王珊 丁治明. 移动计算中的移动数据库 [N]. 微电脑世界 2001,（8）
[11] 张孝 王珊 杜小勇. 嵌入式数据库处处留芳香[N]. 中国计算机报 2001，（8）
[12] 朱英 嵌入式移动数据库及其相关问题 [J] 贵州电子工业学院学报 2003，（6）
[13] 刘德贵 移动计算技术发展综述 [J] 微型机与应用 1999，（9）
[14] 佚名 移动计算技术及其应用 [J] 软件世界 2000，（11）
[15] 蔡忠善 移动计算和移动数据库在我国的应用前景 [J]软件世界 2001，（4）
[16] 徐立臻. 江明菲等 移动计算环境下的数据库事务管理 [J]东南大学学报 2002，（6）
[17] 熊焰. 苗付友等 移动计算中基于Mobile Agent的数据库访问技术 [J]小型微型计算机系统 2002，（10）
[18] 黄军政 蔡瀛捷 嵌入式移动数据库的应用研究 [J]东华大学学报 2002，（10）
[19] 郑昊 XML数据库 [N]个人电脑 2002，（9）
[20] 李英梅等XML数据库及相关问题研究 [J]哈尔滨师范大学自然科学学报 2002，（6）
[21] 周勇等 .XML数据库与关系数据库协作研究 [J]计算机工程与应用 2002，（13）
[22] 赵俊岚 XML与数据库 [J]内蒙古大学学报(自然科学版) 2003，（3）
[23] 张素智 卢正鼎 李春林. XML 数据库及其应用研究 [J ] 计算机工程与应用, 2002, (8)
[24] 朱亮 Native XML数据库技术 2003，（2）
http://www-900.ibm.com/developerWorks/cn/xml/x-nxd/index.shtml
[25] Ronald Bourret XML and Databases 2004，（7）
http://www.rpbourret.com/xml/XMLAndDatabases.htm
[26] AGiLiENCE XPEERION mobile XML database Version: 1.0 Company: AGiLiENCE
http://www.xml.com/pub/p/690
[27] Berkeley DB /Berkeley DB XML http://www.sleepycat.com/download/whichdownload.shtml
[28] 罗谦等 基于移动数据库的异构数据一致性技术研究 [J]重庆师范学院学报2003，（4）
[29] 宋绮虹. 刘宏 SyncML同步协议分析 [N] 电信快报 2003，（7）
[30] 任立刚. 宋俊德 浅析数据同步协议——SyncML [J] 中国数据通信 2002，（10）
[31] Birdstep Database Management Software
http://www.birdstep.com/database_technology/index.php3
[32] Andy Sjöström Manage XML Using .NET Compact Framework，May 2003
http://msdn.microsoft.com/mobility/understanding/articles/default.aspx?pull=/library/en-us/dnppc2k3/html/mgexmlnetcpctfrmwrk.asp
[33] http://www.ixiasoft.com/default.asp?xml=/xmldocs/webpages/textml-server.xml
[34] Ronald Bourret XML Database Products:Discontinued 2004，（1）
http://www.rpbourret.com/xml/ProdsDiscontinued.htm
[35] Ronald Bourret XML Database Products 2004，（9）
http://www.rpbourret.com/xml/XMLDatabaseProds.htm
[36] 庞引明 XML数据库：最新进展和发展方向 [N]计算机世界报 2004，（9）
http://www2.ccw.com.cn/04/0436/b/0436b52_1.asp
[37] 李由等 XML数据库存储技术的研究与实现 [J]计算机工程 2002，（7）
[38] 贾福林等 基于DOM的XML数据库的索引技术研究 [J]计算机研究与发展 2004，（1）
[39] Ronald Bourret Mapping DTDs to Databases 2001，
http://www.rpbourret.com/ xml/DTDToDatabase.htm
[40] 童咪娜. 金远平 XML数据库查询语言特性研究 [J]计算机应用 2001，（09）
[41] 骆炎民. XML的关系数据库技术与应用 [J]华侨大学学报(自然科学版) 2003，（3）
[42] Nicholas Chase 理解DOM http://www-900.ibm.com/developerWorks/cn/cnedu.nsf/xml-onlinecourse-bytitle/386674F65A47844C48256BD10023D453?OpenDocument
[43] Nicholas Chase 理解SAX http://www-900.ibm.com/developerWorks/cn/cnedu.nsf/xml-onlinecourse-bytitle/CA45E09F1E2EF41E48256B1B000C6C7B?OpenDocument
[44] http://www.ipedo.com/html/ipedo_xml_database.html
[45] http://www.perfectxml.com/soft.asp?cat=15
[46] Kevin Williams Native-XML 数据库：一个关于数据的坏主意 2001，（10）http://www-900.ibm.com/developerWorks/cn/xml/x-xdata/part5/index.shtml
[47] Kevin Williams 用于数据的 XML：灵活体系结构的四点技巧 2001，（8）http://www-900.ibm.com/developerWorks/cn/xml/x-xdata/part4/index.shtml
[48] http://www.ipedo.com.cn/product/Faq.jsp?menu=2
[49] Seven good reasons to choose XML http://www2.softwareag.com/Corporate/products/tamino/prod_info/7goodreasons.asp
2970
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
