xml|数据|数据库　　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　"
　　
　　
　　　　 
　　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　存储标记
　　
　　在
　　
　　
　　 
　　<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之间互相转换的起点。