XML与数据库[收藏]

1.0 简介
    本论文简要的探讨了XML和数据库之间的关系，同时罗列出一些可以使用数据库处理
XML文档的软件工具。虽然在这里不可能详尽地介绍和提供对这些软件更深层次的评价，
但是我希望它能够描述使用数据库处理XML文档中的主要部分。这里有点偏向与关系数据
库，因为我的经验如此。

2.0 为什么使用数据库？
    当你考虑到要使用XML和数据库时的第一个要问你自己的问题应该是：为什么我需要
使用数据库。你是需要显示数据？你是需要一个保存你主页的空间？数据库在电子商务运用
程序中时把XML当做数据传输格式传送吗？这些问题的答案都将直接影响到你对数据库和中间件
（如果使用了的话）的选择。
    举例说明，假设你是把XML做为一种数据传输格式使用在你的电子商务运用程序中。
那么意味着你需要传输的数据格式将主要是具有高度规范结构，那么在XML中的那些自己的编码规
范对你而言并不重要了，这样你的兴趣就仅仅是在数据上而不是在这些数据如何物理存储在文
档中了。如果你的运用程序关系简单，那么一个关系数据库和数据传输中间件将能够满足你的需
求；如果关系庞大和复杂，那么你就需要一个完全支持XML的开发环境了。
    从另一方面来说，假设你是要实现从杂散的XML文件中创建一个网站的功能。你不仅
需要管理这个网站，你还要提供给用户查询其中内容的功能。这时你的文件的格式将是高度
的不规范，而实体的使用对你来说变得很重要，因为这些文件的结构是网站的基本功能需求。
在这个例子中，你就需要一些"native XML"数据库而不是普通的关系数据库，执行解释
、XML实体使用和支持查询语言（例如XQL）。


3.0 数据和文档的对比
    也许在大多数情况下，判断是否采用数据库的最重要的因素是你使用数据库是用来
保存数据呢还是保存文件。如果你想保存数据， 你需要的数据库则主要是面向数据存储的，例如一
个关系数据库或则一个面向对象的数据库，或则也可以是一个在数据库和XML文档之间传递数据的
中间件。从另一个角度来说，如果你想存储文件，你需要一个专门设计用来存储文件的内容管理
系统。虽然可以把文件保存在关系数据库或则面向对象的数据库中，但你会发现你的工作
经常是在重复实现一个内容管理系统中的功能而已。简单说，虽然一个内容管理系统通常是建立
在一个面向对象数据库或则关系数据库的顶层，但是如果只是把一个内容管理系统当做数据库
来使用被证明是失败的。
    你是否需要存储数据或则文件经常取决与你的XML文件。原因是XML文件分为两类：
数据为主和文档为主。

3.1 数据为主的文件
    数据为主的文件表现出来的特点是结构相当规范，数据格式良好（就是说，数据中
最小的独立单元是PCDATA-only元素级别或则是一个属性），和一些或则没有混合内容。其中同
类型元素和PCDATA的出现顺序并不重要。例如XML文件内容是销售单、飞行计划、餐馆菜单等等。
数据为主的文件经常被用来设计机器消费，这时XML的调用是多余的---它仅仅是一种数
据传输。
    例如，下面的销售单就是一个数据为主的文档：
   <Orders>
      <SalesOrder SONumber="12345">
         <Customer CustNumber="543">
            <CustName>ABC Industries</CustName>
            <Street>123 Main St.</Street>
            <City>Chicago</City>
            <State>IL</State>
            <PostCode>60609</PostCode>
         </Customer>
         <OrderDate>981215</OrderDate>
         <Line LineNumber="1">
            <Part PartNumber="123">
               <Description>
                  <p><b>Turkey wrench:</b><br />
                  Stainless steel, one-piece construction,
                  lifetime guarantee.</p>
               </Description>
               <Price>9.95</Price>
            </Part>
            <Quantity>10</Quantity>
         </Line>
         <Line LineNumber="2">
            <Part PartNumber="456">
               <Description>
                  <p><b>Stuffing separator:<b><br />
                  Aluminum, one-year guarantee.</p>
               </Description>
               <Price>13.27</Price>
            </Part>
            <Quantity>5</Quantity>
         </Line>
      </SalesOrder>
   </Orders>
    注意在XML世界中，许多（其实应该是大量）的文件实际上都是数据为主的。例如，
考虑在Amazon.com网站上显示一本书的各种信息的页面，虽然这个页面是一个相当巨大的文
本，但是这个文本的结构是高度规范的，所有页面都包含有介绍书的共同点，并且每一页中文本
的大小是受限制的。也就是说，它可以从一个简单的、数据为主的XML文档 + 包含有每一页信息
的数据库+ XSL样板文件 就能够实现这个网站的结构了。通常，目前任何一个动态建立HTML的网
站都可以被上面介绍的这种结构来实现的。
   下面是一个很简单的例子：
   <Lease>
      <Lessee>ABC Industries</Lessee> agrees to lease the property at
      <Address>123 Main St., Chicago, IL</Address> from <Lessor>XYZ
      Properties</Lessor> for a term of not less than <LeaseTerm
      TimeUnit="Months">18</LeaseTerm> at a cost of <Price
      Currency="USD" TimeUnit="Months">1000</Price>.
   </Lease>
它是使用下面的这个XML文档和一个简单的样板文件实现的：
   <Lease>
      <Lessee>ABC Industries</Lessee>
      <Address>123 Main St., Chicago, IL</Address>
      <Lessor>XYZ Properties</Lessor>
      <LeaseTerm TimeUnit="Months">18</LeaseTerm>
      <Price Currency="USD" TimeUnit="Months">1000</Price>
   </Lease>

3.2 以文档为主的文件
    以文档为主的文件表现出来的特点是：不规范的结构，大量的原始数据（就是说，
最小的独立数据单元是包含有混合内容的元素级或则本身就是一个文档），和大量混合内容。其中
同类型元素和PCDATA出现顺序是非常重要的。例如一本书，一封电子邮件，广告，以及几乎所有的
XHTML文档。以文档为主的文件通常是用来设计人文消费：
    例如，下面的产品描述就是一个以文档为主的文件：
   <Product>
   <Name>Turkey Wrench</Name>
   <Developer>Full Fabrication Labs, Inc.</Developer>
   <Summary>Like a monkey wrench, but not as big.</Summary>
   <Description>
   <Para>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.</Para>
   <Para>You can:</Para>
   <List>
   <Item><Link URL="Order.html">Order your own turkey wrench</Link></Item>
   <Item><Link URL="Wrenches.htm">Read more about wrenches</Link></Item>
   <Item><Link URL="catalog.zip">Download the catalog</Link></Item>
   </List>
   <Para>The turkey wrench costs just $19.99 and, if you
   order now, comes with a hand-crafted shrimp hammer as a
   bonus gift.</Para>
   </Description>

3.3 数据（Data）、文件(Documents)和数据库(Databases)
    事实上，数据为主的文件和文档为主的文见之间的区别并不是很清晰。例如，虽然
一个数据为主的文件（例如一张发票），也有可能包含大量的不规范结构的数据，例如发票的描
述部分。而一个以文档为主的文件（例如用户手册），也可能包含有规范的数据结构(通常是元数
据metadata),例如作者名和再版日期。除了这些，你用来判断是否是两者中其一的另外
一个重要特点是你是对数据还是对文档感兴趣，这也将决定你要采用什么样的系统。
    要存储和获取数据，你可以使用一个数据库（通常是关系数据库，面向对象数据库
或则树状体系数据库）和中间件，或则你也可以使用XML服务器（你可以把它看成是将数据库
和中间件捆绑在一起）。要保存文档，你将需要一个内容管理系统。有关各种系统的探讨
在第4.0小节中, "存储和获取数据"和第5.0小节 "存储和获取文档".你能够在第6.0小节找到
一些可使用的软件列表"可利用的软件"。

4.0 存储和获取数据
    数据的类型可以在数据为主的文件的原始定义或则从数据库中的字段类型中得到。
    前者的例子是你想把数据库中的数据保存成XML文件放到网站上；后者的例子是你需
要把大量的数据保存到关系数据库中。根据你的具体需求，你需要的软件或则是把XML数据
读入到数据库或则是把数据库中的数据输出到XML文件，或则两者都支持。

4.1 转录数据
    当将数据保存在数据库中，它经常需要抛弃与文档信息有关的大量内容，例如它的
名称和DTD，同时还有它的物理结构，例如实体的定义和使用、属性值和相同类型元素的出现顺
序，还有二进制数据的存储方式 (是经过Base64编码的还是没有经过编码的实体或则其他方式),
 CDATA的内容和其他编码信息。简单而言，当从数据库中获取信息时，最后生成的XML文档结果可
能不包含任何CDATA或则实体运用（entity usage） (除非预先定义了实体lt（就是符号"<"
）,gt(">"), amp("&"), apos("'"),  quot("""))和同类型元素、属性出现的顺序。
   例如，假设你需要把一个销售单的信息使用XML格式从一个数据库中获取数据然后转
录到另外一个数据库中，在这个例子中，在XML文档中并不关心销售单的编号是保存在销售单的日
期的前面还是后面，也不用关心是否将顾客的名称保存在CDATA section作为一个扩展入口,
 或则甚至直接当成一个PCDATA. 但是，对于将这些相关数据从第一个数据库中转录到第二个数据
库的过程中，这些信息都是非常重要的。这样，这个数据传输软件就需要考虑使用树状结构
（它将一个单独的销售单的信息用组(group)来实现）。
    另一个当忽略文档信息和它的物理结构会带来麻烦的例子是---"借贷套利"文档，它
保存的数据是从一个数据库中的文档中获取，并且需要重新组装这些数据成为一个新的文档，
而这个过程经常会导致新的文档的结构和原来的文档会不一致。
    从上面的例子可以看出，对于数据库和数据传输中间件的选择是根据你的需求而变
化的。

4.2 将文档结构映射成数据库结构
    为了能够在XML文档和数据库之间传递数据，有必要将文档的结构映射成数据库的结
构，反之亦然，这种映射关系又分两类：模板驱动和模型驱动
4.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</Se
lectStmt>
      <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中使用参数 -- 而不是象上面的例子中简单地格式化结果。
另外它还支持使用编程结构例如循环和条件判断结构。还有就是它支持通过HTTP的传递
参数。
    目前，以模板驱动的映射仅仅只支持从一个关系数据库转换成XML文档的情况。
4.2.2 以模型驱动的映射
    在以模型驱动的映射模式中,它的原理就是利用XML文档中的数据模型的结构显性或
隐性地将其映射成数据库的结构，反之亦然。它的缺点是灵活性不如模板驱动方式，但是优点
是简单易用，这是因为它是基于具体的数据模型来进行映射的，通常它能够自己完成很多地转
换工作，从而简单易用。因为将数据从数据库转换成XML的工作是根据单一的一个模型（模型），
所以通常在这种方式下还要综合搭配XSL来提供灵活性。
    在XML文档中有两种模型是非常普遍的。第一种是被许多中间件包在转换XML文档成
关系数据库数据所使用到的模型，就是将XML文档当成一个单独的表（Table）对象或则一系列表对
象。也就是说，真正的XML文档必须类似于下面的格式，如果是单一的表对象的话，<databa
se>元素就不需要出现了
   <database>
      <table>
         <row>
            <column1>...</column1>
            <column2>...</column2>
            ...
         </row>
         ...
      </table>
      ...
   </database>
    其中的"table"可理解为单个的结果集 (当数据是从数据库往XML中传输时)或则是
一个单独的表对象或则一个可更新的视图（view）(当数据是从XML往数据库传输时)。如果数
据是来自多个结果集的描述中(当数据来自数据库中时)或则XML的文档包含有更深层次的嵌套
元素，有必要表现成一系列表对象 (当数据要转换到数据库中时)，那么类似与上面例子那么
简单的传输是不可能的。
     第二种普遍的数据模型是XML文档种的对象树，在这种模型下，元素通常对对应了
一个对象或则属性或则PCDATA对象。这种模型直接映射成面向对象的数据库和树状结构
数据库，当然借助传统的对象-关系映射技术和SQL 3对象视图也可以映射成关系数据库。要注意
的是，这种模型并不是文档对象模型(DOM)，DOM是指文档本身是个模型，而不是指文档中的数
据。
    举例，在上面介绍的销售单文档可以被看成是有5个类的对象树---Orders, SalesO
rder,
Customer, Line, and Part -- 入下图所示：
                       Orders
                         |
                     SalesOrder
                    /    |    /
             Customer   Line   Line
                         |      |
                        Part   Part
    当一个XML文档模型化处理成一个对象树时，对元素和对象不需要什么特殊的要求。
例如，如果一个元素只包含有PCDATA，例如销售单文档中的CustName元素，它能够被看做一个
属性进行处理（就是仅仅只包含有单独的数值）。简单来说，有时将混合元素或则元素内容
模型化处理成属性是非常有用的方法。一个现成的例子就是在销售单文档中对Description元素
的处理：尽管它在XHTML的Form中有混合的内容，但是将description元素看作一个单独的属性来
处理会更有用些，因为它的组成部分就本身而言没有什么意义。

4.3 数据类型, 空值（Null）, 字符集设置和其他所有的类似集
    本节将探讨一些和将XML文档转换成数据库之间有关存储数据的内容。通常，你在选
择什么样的中间件来解决这些问题的时候是不会考虑到这些问题的，但是如果你注意到这些问
题的存在时，希望下面的讨论对与你在选择中间件时有所帮助。
4.3.1 数据类型
    XML不支持任何有意义的数据类型，除非是不能够解释的实体，所有XML文档中的数
据都被当成文本（text）来对待，虽然它能够用其他的数据类型来表示，例如可以表示成日期
或则整数。通常，数据转换中间件将把文本（在XML文档中的文本）转换成其它的数据类型（数据库
中的数据类型），反之亦然。然而，一些特定的数据类型在转换的过程中是受限制的，例如受那
些提供数据支持的JDBC驱动的限制。在这些众多的有可能的数据类型中，日期类型通常会导致
麻烦。数字，特别是由于国际地域不同的数字格式，也可能导致问题。
4.3.2 二进制数据
    有两种比较普遍的方法将二进制数据保存到XML文档中：对实体不做任何编码处理和
对实体进行Base64编码处理(一种MIME编码方法，可以将二进制数据影射成US-ASCII的子集)。
对于关系数据库，这两种方法都被证明是有可能存在问题的，因为大家都知道当保存和获取二进
制数据到数据库中的规则是非常严格的，这样对中间件将有可能导致问题。另外，并没有一种标准的符
号用来说明一个XML文档中的元素包含有Base64编码数据，从而中间件可能根本就不能够识别这
种编码。最后，还有可能有些中间件在将数据存储入数据库的过程中根本就会忽略没有编码实体
中的符号或则Base64编码中的元素。所以，如果对你而言，二进制数据非常重要的话，请千万要
确认你的中间件是否支持二进制数据。
4.3.3 空值（Null）
    在数据库世界中，null数据意味着数据不在那。这不同与一个值为0(对数字类型数
据)或则长度为0(对字符串类型)。例如，假设你的数据是收集自一个气象站， 如果气象站的温
度计出毛病了，那么你的数据库中将存储一个null值而不是一个0，值为0完全是另外一回事了
。
    XML也支持空值的概念，可以通过设置元素的类型和属性来实现。如果元素类型或属
性的值为null，XML的处理方法是简单地不将其包含到文档中。但是对数据库来说，空的元素
或则包含0长度字符串的属性并不意味着null：他们的值是长度为0的字符串。
    当将一个XML文档结构映射成数据库或则反过程中，你必须特别注意那些可选的数据
类型和本来表示空值的属性。如果不这么做的话，结果将是可能出现插入错误(当将数据转换
到数据库中时)或则非法文档错误(当将数据从数据库读出时)。
    因为XML中相对与数据库而言在对符号意义的申明有更好的灵活性 --- 具体来说，
就是XML用户愿意将空元素或则包含长度为0内容的属性认为是"null" -- 你必须根据这个考虑选
择什么样的中间件来处理这个问题。一些中间件提供给用户自定义在XML文档中什么标志是表示
"null"的。
4.3.4 字符集设置
    根据定义，一个XML文档能够包含任何Unicode字符，除了一些特殊的控制字符。但
是不幸的是，许多数据库都限制或则不支持Unicode并且需要一些特殊的配置才能够处理非ASC
II 编码的数据字符。如果你的数据包含有非ASCII字符，那么请确保你的数据库和中间件是否能够
处理这些字符集。
4.3.5 处理指令（Processing Instructions）
    处理指令不是XML文档中的“数据”部分，目前许多中间件都不能够正常的处理它们
。问题是这样的，尤其是在一个严格的将XML文档结构映射成数据库结构中，处理指令通常
是很难处理的，因为题目可以出现在文档的任何位置，于是，中间件就非常困难的需要判
断将它们保存到什么位置和读取的时候取回到什么位置。如果处理指令和文挡的"round-t
ripping"对你而言是非常重要的话，你就必须确保你选择的中间件能够处理这个问题。
4.3.6 存储标志（Storing Markup）
    在4.2.2小节中提到，有时候直接将包含有元素或则混合内容的元素不进行进一步的
解析直接保存到数据库中是非常有用的。最普遍的实现方法是简单的把这个标志本身直接保
存到数据库中。不幸的是，这将带来另外一个问题，当从数据库中读取这些数据时：将很难
判断数据库中的标志到底是真是假，特别是一些由lt和gt转义的字符。
    例如下面的描述：
   <description>
      <b>Confusing example:</b> <foo/>
   </description>
   保存到数据库中将变成这样：
   <b>Confusing example:</b> <foo/>
   这时数据库将不能够判断<b>和<foo>是标志还是文本了。解决方法有以下几种，例如
将标志的符号使用其它非标志符号替代，但是这时你要非常的小心，因为也许别的运用程
序在使用这些数据时就会出现不兼容的现象。例如，如果你想查询数据库中的小于号("<")和
lt标志("<")时就要特别小心了。
4.4 从数据库的结构生成DTDs和逆反过程
      在XML文档和数据库之间转换数据的一个普遍问题是：如何从数据库的结构生成D
TDs和其逆反过程。简而言之，目前有许多软件都提供了可以直接使用的操作功能，但是它
产生的结果对许多用户来说用处和帮助不大，也许没有多少人喜欢。
    例如，下面的过程（已经简化过的）就是从一个XML文档到关系数据库中生成DTD的
：对每一种包含有元素或则混合内容的元素类型，新建立一个table和一个主关键字段。
    对混合内容种的每一个元素，建立一个分开的table,在其中保存PCDATA,通过主关键
字连接到父表中。
    对于元素类型中每个有单一数值的属性和只包含有PCDATA内容的子元素类型在该ta
ble中新建立一列（字段）。如果子元素类型或则属性是可选的，让该字段允许为空。
    对于每个有多值的属性或则多仅含有PCDATA内容的子元素类型，再建立一个分开的
table来保存他们的值，通过它们的父表的主关键字连接到父表。
    对于每个子元素，这些子元素本身还有元素或则混合内容，使用父表中的关键字将
父元素表连接到子元素表中。
    而下面则是一个从关系数据库的结构生成XML文档的过程（简化过的）：
    对每个table，新建一个元素。
    对表中的每列，建立一个属性或则只含PCDATA的子元素
    对每个包含有在主键/外键关键字关系中主键值的列，新建一个子元素。
    不幸的是，在这些过程中存在许多缺陷。例如，其中没有实现对数据类型的预先定
义和在DTD中没有实现对列长度的预先定义的方法。因为任何的预先定义，例如通过读一个
示例文档，当读取其他“类型”的文档或则其他文档中包含有超过字段长度内容的文档时，
就会发生错误。(解决这个问题的办法时使用XML schema文档中数据类型定义)简单来说，当从一
个关系结构中生成DTD时，是没有办法预先判断子元素“应该”出现的顺序或则类似数据库中的
行标识。
    尽管有这些陷，根据数据库结构生成DTDs的软件能够给我们带来了一个很好的开端
，特别是对与那些非常庞大和复杂的系统