XML和数据库作者：onecenter
作者：Ronald
摘要：本论文简要的探讨了XML和数据库之间的关系，同时列出一些可以使用数据库处理XML文档的软件。虽然这里不打算详尽地介绍这些软件，但是笔者希望它能够描述使用数据库处理XML文档中的主要部分。
内容：
目录
1.0 简介
2.0 XML是数据库吗?
3.0 为什么使用数据库?
4.0 数据和文档的对比
4.1 以数据为中心的文件
4.2 以文档为中心的文件
4.3 数据、文档和数据库
5.0 存储和检索数据
5.1 转移数据
5.2 将文档结构映射为数据库结构
5.2.1 模板驱动的映射
5.2.2 模型驱动的映射
5.2.2.1 表格模型
5.2.2.2 特定数据对象模型
5.3 数据类型、空值、字符集和其他
5.3.1 数据类型
5.3.2 二进制数据
5.3.3 空值
5.3.4 字符集
5.3.5 处理指令
5.3.6 存储标记
5.4 从数据库的结构生成DTD及其互逆过程
1.0 简介
本论文简要的探讨了XML和数据库之间的关系，同时列出一些可以使用数据库处理XML文档的软件。虽然这里不打算详尽地介绍这些软件，但是笔者希望它能够描述使用数据库处理XML文档中的主要部分。这里有点偏向与关系数据库，因为我的经验如此。
2.0 XML是数据库吗?
在开始讨论XML和数据库之前，我们需要回答一个萦绕在很多心头的问题: "XML是数据库吗?"在严格意义上将，如果"XML"是指XML文档时，答案是"否"。尽管XML文档包含了数据，但是如果没有其他的软件来处理这些数据，它对于数据库的意义和其他文本文件没有什么区别。
如果在更为宽泛一些的意义上将，当"XML是指XML文档以及所有相关的XML的工具和技术时，答案则是"是"。 之所以肯定是由于XML提供了许多数据库中所需要的部分:存储(XML文档),结构(DTD,
XML schema语言),查询语言(XQL, XML-QL, QUILT等), 编程接口(SAX, DOM),等等。不过...XML还缺少很多在真实的数据库中所必备的内容: 有效的存储、索引、安全、交易、数据完备性、多用户访问、触发、多文档查询等。
因此如果在数据量一般、用户较少、性能要求不高的环境下可以把XML当作数据库来使用；而在大多产品的环境中，要求有许多的用户使用、需要严格的数据完整性并且对性能有很高的要求，XML就不能胜任了。而且，考虑到象dBase和Access等数据库既便宜又十分易用，因此甚至在第一种情况下XML都很少有理由充当数据库的角色。
3.0 为什么使用数据库?
当在考虑使用XML和数据库时，第一个要问自己的问题应该是：为什么我需要使用数据库？你需要将原有的数据导出？你需要保存你的Web主页？你是要在一个电子商务应用中使用数据库，而且其中XML当做传输的数据格式？这些问题的答案都将直接影响到你对数据库和中间件(如果有的话)的选择。
例如，假设你在电子商务应用程序中使用XML来进行数据传输。这是很好的方案，因为你的数据具有高度规范的结构，而XML中的那些实体和编码对你而言并不重要了。毕竟样你关心的仅仅是数据而不在于这些数据如何在文档中进行物理的存储。如果你的应用程序相对比较简单的话，关系数据库和数据传输中间件将可以满足你的需求；如果应用程序庞大而且复杂，那么你就需要一个完全支持XML的开发环境了。
从另一方面来说，假设你有一个从零散的XML文件创建的网站。你不仅需要管理这个网站，你还要提供方法让用户可以查询其中的内容。这时你的文件将非常的不规范，而实体的使用对你来说将变得很重要，因为这些文件的结构是网站的根本。在这个例子中，你就需要某类"原生
XML"数据库可以执行版本化、跟踪实体的使用并且支持如XQL这样的查询语言。
4.0 数据和文档的对比
笔者认为，在选择数据库时，最重要的判断因素可能是你是利用数据库来保存数据还是保存文档。如果你想保存数据，你需要的数据库主要是面向数据存储(例如关系型数据库或者面向对象型数据库)以及在数据库和XML文档之间相互转换。从另一个角度来将，如果你想存储文档，你需要一个专门设计用来存储文件的内容管理系统。
虽然你可以自己把文件保存在关系数据库或面向对象数据库中，可是你常会发现你的工作是在重复内容管理系统的功能。类似的，虽然一个内容管理系统通常是建立在面向对象数据库或关系数据库之上，但要是把一个内容管理系统当做数据库来使用就可能非常的令人困绕。
你需要存储数据还是文档，答案常常取决于你的XML文档。原因是XML文件分为两大类：以数据为中心和以文档为中心。.
4.1 以数据为中心的文件
以数据为中心的文件的特点是结构相当规范、数据颗粒度好(也就是说，数据中最小的独立单元是PCDATA元素或者是属性)、很少或者没有混合内容。其中同层次元素和PCDATA的出现顺序并不重要。典型的例子是，XML文档包含了销售定单、飞行安排、餐馆菜单等等。数据为中心的文档常被用于机器的使用，这时XML可能是多余的---它仅仅是数据传输的手段而已。
例如，下面的销售定单的文档就是以数据为中心的：
ABC Industries
123 Main St.
Chicago
IL
60609
981215
Turkey wrench:
Stainless steel, one-piece construction,
lifetime guarantee.
9.95
10
Stuffing separator:
Aluminum, one-year guarantee.
13.27
5
在XML的世界中，许多内容丰富的文档实际上都是数据为中心的。我们以显示图书信息的Amazon.com网站为例。虽然这个页面是相当巨大的文本，但是这个文本的结构是高度规范的，其中许多的部分对任何的书本描述页面都是相同的，并且特点页面中的各部分的大小都是有限的。也就是说，该页面可以通过一个简单的、数据为中心的XML文档来建立，其中包含了从数据库中检索得到的文本信息以及一个XSL样式表。通常，目前任何通过在模板中填充数据库数据而动态构造HTML页面的网站都可以被上面介绍的用以数据为中心的XML文档和一个或者多个的XSL样式表方式替代。
例如，我们来看下面的租房(Lease)文档:
ABC Industries agrees to lease the property at
123 Main St., Chicago, IL from XYZ
Properties for a term of not less than TimeUnit="Months">18 at a cost of Currency="USD" TimeUnit="Months">1000.
可以从下面的XML文档和简单的样式表得到:
ABC Industries
123 Main St., Chicago, IL
XYZ Properties
18
1000
4.2 以文档为中心的文件
以文档为中心的文档的特点是:结构不规范、数据颗粒度更大(即，最小的独立数据单元是包含有混合内容的元素或者就是整个XML文档)以及含有大量的混合内容。其中相同层次的元素和PCDATA出现顺序是非常重要的。典型的例子是书、电子邮件、广告以及大多数XHTML文档。以文档为中心的文档是用于人的使用。
例如，下面的产品描述文档就是以文档为中心：
Turkey Wrench
Full Fabrication Labs, Inc.
Like a monkey wrench, but not as big.
The turkey wrench, which comes in both right- and
left-handed versions (skyhook optional), is made of the finest
stainless steel. The Readi-grip rubberized handle quickly adapts
to your hands, even in the greasiest situations. Adjustment is
possible through a variety of custom dials.
You can:
Order your own turkey wrench
Read more about wrenches
Download the catalog
The turkey wrench costs just $19.99 and, if you
order now, comes with a hand-crafted shrimp hammer as a
bonus gift.
4.3 数据、文档和数据库
在现实情况中，以数据为中心的文件和文档为中心的文件之间的区别并不是很严格。例如，一个以数据为中心的文件(如一张发票)，也有可能包含粗颗粒度、不规则的数据(如发票的描述部分)。而一个以文档为中心文件(如用户手册)也可能包含有良好颗粒度、规则的结构化数据(通常是元数据),例如作者和修订日期。除此之外，让你的文档具有以数据为中心或者以文档为中心的特点有助于你判断是关心数据还是文档，这也将决定你需要采用什么样的系统。
要存储或检索数据，你可以使用一个数据库(通常是关系型、面向对象型或者是层次型)和中间件(字带或者是采用第三方)，你也可以使用XML服务器(即创建分布式应用的平台，例如利用XML进行数据传输的电子商务应用)。要保存文档，你将需要一个内容管理系统或者是一致性的DOM实现系统。有关各类系统的探讨在5.0
"存储和检索数据" 小节和6.0 "
href="#storingretrievingdocs">存储和检索文档 " 小节。你也能够在
href="http://www.rpbourret.com/xml/XMLDatabaseProds.htm">
XML数据库产品 中了解详细的相关产品列表。
5.0 存储和检索数据
在以数据为中心的文档中的数据内容可能来自数据库(此时你想把数据导出为XML格式)，也可能是XML文档(此时你想把数据存储在数据库中)。前者的例子是在关系型数据库中存储的大量现有数据(或称遗产数据);后者的例子是将数据作为XML发布在Web中，而且你想要在你的数据库中进行存储以进行更多的处理。如此，根据你的需求，你可能需要将XML文档转移到数据库的软件，也可能需要从数据库转移到XML文档的软件，或者两者都支持。
5.1 转移数据
将数据存储在数据库中时，经常需要丢弃大量与文档有关的信息，例如文档名称和DTD，同时还有其物理结构，例如实体的定义和使用、属性值和同层元素的顺序、二进制数据的存储方式(是Base64编码、是未析实体或他方式)、字符数据段和其他的编码信息。类似的，当从数据库中检索数据时，生成的XML文档结果除了非预定义实体lt(<"),gt(">"), amp("&"), apos("’"), quot(""")不包含任何CDATA或实体引用。而同层元素和属性的出现顺序也常常就是从数据库中返回的数据的次序。
尽管一开始有些让你吃惊，但是这常常是合理的。例如，假设你需要用XML作为数据格式把一张销售从一个数据库中转移到另一个数据库中。在这种情况下，在XML文档中并不关心销售单的编号是保存在销售单的日期的前面还是后面，也不用关心是否将顾客的名称保存在字符数据(CDATA)段还是作为一个外部实体，或者直接当成一个PCDATA。最重要的在于相关的数据是从第一个数据库转移到第二个数据库中。这样，这个数据传输软件就需要考虑数据的层次结构(该结构将销售单的有关进行进行了分组)，而其他则不必过多考虑。
忽略文档信息以及其物理结构的后果之一是
文档的"逆反回归"的不一致效应，即将一个文档的数据存储在数据库中，然后根据这些数据重新组织成新的文档。而即便是根据标准格式处理，得到的也常常是和前面不同的文档。这是否可以接受要取决于你的需求，而且也将影响到你对数据库和数据传输中间件的选择。
5.2
从文档结构到数据库结构的映射
为了在XML和数据库之间传输数据，需要在文档结构和数据库结构之间进行相互的映射。这样的映射通常分为两大类: 模板驱动和模式驱动。
5.2.1 模板驱动的映射
在以模板驱动的映射中,没有预先定义文档结构和数据库结构之间的映射关系
，而是使用将命令语句内嵌入模板的方法，让数据传输中间件来处理该模板。例如，考虑下面的模板(注意该模板并不适用任何实际的产品)，在<SelectStmt>元素中内嵌了SELECT语句：
<?xml version="1.0"?>
<FlightInfo>
<Intro>The following flights have available seats:</Intro>
<SelectStmt>SELECT Airline, FltNumber, Depart, Arrive FROM Flights</SelectStmt>
<Conclude>We hope one of these meets your needs</Conclude>
</FlightInfo>
当数据传输中间件处理到该文档时,每个SELECT语句都将被各自的执行结果所替换，得到下面的XML格式:
<?xml version="1.0"?>
<FlightInfo>
<Intro>The following flights have available seats:</Intro>
<Flights>
<Row>
<Airline>ACME</Airline>
<FltNumber>123</FltNumber>
<Depart>Dec 12, 1998 13:43</Depart>
<Arrive>Dec 13, 1998 01:21</Arrive>
</Row>
...
</Flights>
<Conclude>We hope one of these meets your needs</Conclude>
</FlightInfo>
这种以模板驱动的映射可以相当的灵活。例如,有些产品可以允许你在任何结果集合中替换你想要的内容(包括在SELECT中使用参数),而不是象上面的例子中简单地格式化结果。另外它还支持使用编程来进行构造，例如循环和条件判断结构。还有一些还支持SELECT语句的参数化，例如通过HTTP来传递参数。
目前，以模板驱动的映射只支持从一个关系型数据库转换成XML文档的情况。
5.2.2 模型驱动的映射
在以模型驱动的映射中,利用XML文档结构对应的数据模型显式或隐式地将映射成数据库的结构，而且反之亦然。它的缺点是灵活性不够，但是却简单易用，这是因为它是基于具体的数据模型来进行映射的，通常能够为用户实现很多地转换工作。由于将数据从数据库转换成XML的结果依照了单个模型,
因此通常在这种方式下通常结合XSL来提供模板驱动的系统中所具有的灵活性。
在XML文档中的数据视图通常有两种模型:表格模型和特定数据对象模型。有时候也可能会出现其他的模型。例如，通过采用ID和IDREF属性，一个XML文档可以用来一个指定的图形。不过，很多现有的中间件并不支持这些模型。
5.2.2.1 表格模型
许多中间件软件包都采用表格模型在XML和关系型数据库之间进行转换。它把XML的模型看成是一个单独的表格或者是一系列的表格。也就是说，XML的文档的结构和下面的例子相类似，其中在单个表格的情况下，<database>并不出现:
<database>
<table>
<row>
<column1>...</column1>
<column2>...</column2>
...
</row>
...
</table>
...
</database>
其中的术语"table"可理解为单个的结果集(当从数据库向XML中转换数据时)，或者是一个单独的表格或可更新的视图(当从XML向数据库转换数据时)。如果数据需要来自多个结果集(当数据来自数据库中时)或者与仅仅表达成一系列表格的集合(当转换数据到数据库时)相比，XML的文档包含有更深层次的嵌套元素，那么类似的转换几乎是不可能的。
5.2.2.2 特定数据对象模型
XML文档中第二种普遍的数据模型是特定数据对象的树型结构。在该模型中,元素类型通常对应对象，而XML中的内容模型、属性和PCDATA则对应对象的属性。这种模型直接映射成面向对象的数据库和层次型数据库，当然借助于传统的对象-关系映射技术和SQL
3对象视图也可以映射成关系数据库。要注意的是，这种模型并不是文档对象模型(DOM)。DOM是对文档本身进行建模，而不是对文档中的数据。如
href="#writeyourown">6.1.2小节所述,DOM用来在关系型数据库的基础上建立内容管理系统。
例如，上面的销售定单文档就可以看作是由五个类所组成的树型结构。如下面的视图所示，包括Orders, SalesOrder, Customer,
Line和Part类:
Orders
|
SalesOrder
/ | Customer Line Line
| |
Part Part
当把一个XML文档建模为一棵特定数据对象树时，就没有必要要求元素一定要对应于对象。例如，如果一个元素只包含PCDATA，如销售定单文档中的CustName元素，它可以当作一个属性进行处理，因此属性只包含单一的、标量型数值。类似的，有时将混合元素或元素内容模型化成属性也是非常有用的。一个现成的例子就是在销售定单文档中对Description元素的处理：尽管它在XHTML的格式中有混合内容，但是将Description元素看作单个的属性会更有用些，因为它的组成部分本身并没有什么意义。
5.3 数据类型、空值、字符集合和其它
本节将探讨一些有关来自数据库的XML文档的存储问题。通常，你决定不了你选择的中间件是如何解决这些问题的，但是你最好应该意识到这些问题的存在，因为这有助于你正确选择你的中间件。
5.3.1 数据类型
XML不支持任何有实际意义的数据类型。除了未析实体，所有XML文档中的数据都被当成文本来对待，即便它能够用其他的数据类型(如日期或者整数)来表示。通常，数据转换中间件将把XML文档中的文本转换成其它数据库中的数据类型，反之亦然。然而，特定的数据类型所识别的文本格式是有限制的，例如受到提供的JDBC
Driver所支持的数据类型的限制。在这些众多的数据类型中，日期类型通常会导致麻烦。不同国际地区的数字格式的差异也可能产生问题。
5.3.2 二进制数据
通常有两种方法将二进制数据保存到XML文档中的：未析实体和Base64编码处理(一种MIME编码方法，可以将二进制数据映射成US-ASCII的子集)。
对于关系型数据库，这两种方法都可能存在问题，因为从数据库中保存和检索二进制数据的规则非常的严格，这样对会导致中间件出现问题。
另外，并没有一种标准的符号用来说明一个XML文档中的元素包含有Base64编码数据，从而使得中间件可能根本就不能够识别这种编码。最后，在存储数据到数据库时，可能会忽略与未析实体或Base64编码元素相关的符号。所以，如果对你而言二进制数据非常重要的话，请务必要确认你的中间件是否支持二进制数据。
5.3.3 空值
在数据库世界中，空值(null)数据意味着数据不存在值。但是这与一个值为0的数字或长度为0的字符串有很大的区别。例如，假设你的数据来自一个气象站，
如果气象站的温度计出了毛病读不出温度值，那么你的数据库中将存储一个null值而不是一个0。显然，值为0完全是另外一回事了
。
XML中空值概念的支持可以通过设置可选的元素类型或属性来实现。如果元素类型或属性值为null，XML只要在文档不包含该元素或者属性就可以了。但是对数据库而言，空的元素或包含0长度字符串的属性并不是空值null：它们的值为长度为0的字符串。
当在XML文档和数据库结构之间相互映射过程中，你必须特别注意那些可选的元素类型或属性是否对应于数据库中的空值项。如果不这么做的话，很可能出现插入错误(当将数据转换到数据库中时)或者无效文档错误(当将数据从数据库读出时)。
因为同样要用符号空值，XML中相对与数据库而言更为灵活。具体来讲，许多XML用户很可能包含空字符串的空元素或属性是空值。这个时候你必须考虑如何选择合适的中间件来解决这个问题。一些中间件可以让用户选择在XML文档中定义用什么来组成空值。
5.3.4 字符集
根据定义，除了一些控制字符，XML文档能够包含任何的Unicode字符。但是不幸的是，许多数据库都限制或则不支持Unicode，而且需要一些特殊的配置才能够处理非ASCII编码的字符数据。如果你的数据包含了非ASCII字符，那么务必要核实你的数据库和中间件是否能够处理这些字符。
5.3.5 处理指令
处理指令并不属于XML文档中的“数据”部分，因此目前许多中间件可能不能正常的处理。问题是，尤其是在将XML文档结构严格映射成数据库结构时，处理指令通常是很难处理的，因为它们可以虚拟地出现在文档的任何位置。因此，中间件就很难判断将它们保存到什么位置以及在什么时候检索读取出来。如果处理指令和文档的循环回复("round-tripping")对你而言是非常重要的话，就务必检查你的中间件是如解决这个问题的。
5.3.6 存储标记
在
href="#markup">4
href="#markup">.2.2
小节中提到，有时候将包含元素或者混合内容的元素不作进一步的解析而直接保存到数据库中是非常有用的。最常见的方法是简单的把这个标记本身直接保存到数据库中。不幸的是，当从数据库中检索数据时将产生问题：不可能判断数据库中的标记到底是真的标记还是代表了标记字符的实体，如由lt和gt转义的字符。
例如，下面的description元素:
<description>
<b>Confusing example:</b> <foo/>
</description>
在数据库中存储为:
<b>Confusing example:</b> <foo/>
这时数据库就不能判断<b>和<foo>是标记还是文本。有几种可能的解决方法，如以一定的方式来标志标记或者对非标记的标记字符使用实体。但是这时你要格外注意这样的方式是否和使用这些的数据的其它应用兼容。例如，如果你想查询数据库中的小于号("<")和
lt实体("<")时就要特别留心。
5.4 从数据库的结构生成DTD及其互逆过程
在XML文档和数据库之间转换数据时，一个普遍问题是：如何从数据库的结构(Schema)生成XML的DTD,如果从XML的DTD产生数据库的结构。简而言之，这是非常直接的操作，但是产生的结果通常离许多用户的期望值还有一些距离。
(还要注意这通常是一次性操作，而大多数应用，尤其是所有的垂直性应用都结合了已知的DTD和关系型Schema的集合。显而易见的特例是在关系数据库中存储随机XML文档或者将关系型数据发布为XML文档的工具;而在后面的情况中，DTD的作用并不明显。)
对于元素类型中每个有单一数值的属性和只包含有PCDATA内容的子元素类型在该ta
ble中新建立一列（字段）。如果子元素类型或则属性是可选的，让该字段允许为空。
对于每个有多值的属性或则多仅含有PCDATA内容的子元素类型，再建立一个分开的
table来保存他们的值，通过它们的父表的主关键字连接到父表。
对于每个子元素，这些子元素本身还有元素或则混合内容，使用父表中的关键字将
父元素表连接到子元素表中。
而下面则是一个从关系数据库的结构生成XML文档的过程（简化过的）：
对每个table，新建一个元素。
对表中的每列，建立一个属性或则只含PCDATA的子元素
对每个包含有在主键/外键关键字关系中主键值的列，新建一个子元素。
例如，下面的过程(经简化）说明了如何从一个DTD生成一个关系型结构:
对于每种包含元素或者混合内容的元素类型，新建一个表格和一个主键字段。
对于每个包含混合内容的元素类型，创建一个单独的表格，其中存放未析数据，通过父元素主键链接到父表格。
对于此元素类型的每个单值属性和只包含未析数据内容、只出现一次的子元素，在该表格中创建一个字段。如果元素类型或者属性是可选的，可以让设置该字段为空值。
对于每个多值属性和多次出现的子元素，创建一个单独的表格来存储数值，并且通过父元素主键链接到父表格。
对每个有元素或者混合内容的子元素，通过父元素主键将父元素表格和子元素表格相连接。
下面的过程(经简化)说明了如何从一个关系型的结构生成一个DTD:
对于每个表格，新建一个元素；
对于表格中的每个字段，新建一个属性或者是只包含未析数据的子元素；
对于每个表格字段中提供主键的主键/外键的关系都新建一个子元素。
不幸的是，这些过程还存在着一些缺陷。例如，DTD中没有方法预先准确地规定数据类型或者字段长度。
因为任何的预先定义(例如通过读取一个示例文档)在读取其它“类型”的文档或者其他文档中包含有超过字长内容的文档时就会产生错误。(长久之策是使用XML schema文档的数据类型。)简单来说，当从一关系型结构生成DTD时，是没有办法预先判断子元素“应该”出现的顺序或者字段(如数据库内部的行标识)是否该进行完全转换。
在以上两种情况中都可能产生命名的冲突。
尽管有这样那样的缺陷，但是这些方法仍然能够很好地奠定在关系型结构和DTD之间互相转换的起点。
