不断演化的Web环境对Web应用程序或服务底层的数据库提出了如何适应新功能、新数据类型的挑战。对于XML数据库，每六个月可能就要发布新的模式版本。本文讨论了适用于XML模式演化过程的变化的分类。然后分析了这些变化对模式验证过程（包括向前和向后兼容）以及查询求值的影响。从案例研究出发，本文提出了XML模式演化以及编写跨模式版本查询的基本原则。

　　随着XML越来越多地作为信息交换标准，持久、验证和查询XML文档的功能也越来越重要。此外，随着Web服务和mash-up应用程序的泛滥，Web应用开发人员也更多地需要转换XML消息，不论这些消息直接来自Web服务还是间接来自持久这些消息的数据库。

　　多数商业数据库管理系统已经以某种形式支持XML持久性。比如，IBM DB2 pureXML（请参阅参考资料）天生就支持在XML类型列中存储XML文档、用XML模式验证XML文档、使用XQuery和SQL/XML查询语言查询XML文档。可以在同一列中存储和查询模式不同但结构良好的XML文档。

　　此外，不断变化的Web环境要求数据库适应新的功能（比如组织业务的扩展）和新数据类型（比如RSS提要消息）。可能每六个月就出现新的模式版本—有时候甚至只有两周。信息技术架构师、应用程序开发人员和数据库管理员经常发现，如果应用程序操作的XML文档列使用不同版本的模式，管理起来就非常乱。另外，数据库之上的应用程序及其用户仍然需要和其交互，不论模式如何变化。

　　由于上述这些原因，模式演化作为一项重要课题需要在关系、面向对象和XML数据库环境中加以研究。具体来说，对于XML数据库，模式演化是XML的迫切要求。虽然以前的大部分工作考虑的是模式演化的技术方面（即如何有效存储不同的模式，在变化中保持数据一致性），本文的目标是讨论如何在不断演化的模式中保持查询的完整性。只要按照这里提供的建议操作，数据库就能跟上Web应用程序发展的需要，Web应用程序仍然能够保持与数据库的交互（通过查询）。这方面研究具有重要的意义：

　　·我们考虑了在XML模式演化过程中最常见的变化类型并提出了一种分类方法。
　　·按照这种分类，说明每种变化对模式验证的影响。同时考虑到了向前兼容（即旧模式的文档和新模式兼容）和向后兼容（即新模式的文档和旧模式兼容）。
　　·我们提出并讨论了模式演化对查询公式的影响。换句话说，对旧模式文档执行的查询不一定能用于新模式文档（反之亦然）。
　　·我们提出了管理XML模式演化的基本原则，说明如何控制模式变化以及如何编写跨越不同模式版本的查询。

　　下面介绍XML和XQuery的一些基本概念。“XML模式变化分类” 一节提出了模式演化过程中可能出现的变化类型。“XML模式演化对查询的影响” 讨论了这种影响，并通过保险业的例子说明了模式变化、查询和查询结果之间的交互。为了让查询在模式演化的时候仍然返回预期的结果，“管理XML模式演化的基本原则” 就此提出了管理模式演化的基本原则。

　　背景

　　XML（可扩展标记语言）是源于SGML的一种标记语言，其规范由W3C管理。使用 XML有利于开发适用于多种环境的应用程序。XML一直在Web服务应用程序中使用，RSS提要是一个典型的例子。Web服务也从消息传递环境中的结构化数据获益。另外，XML有助于建立文件格式的公开标准，促进不同平台、不同应用程序间的数据交换。此外，通用XML数据结构可以改进电子商务参与方之间的集成，更有效地交换订单、库存信息和发货细节。XML数据封装也提高了访问的机密性和可靠性，无论通过Web还是桌面应用程序访问。

　　最后，可以为结构化XML数据实现高效的文档搜索方法。和二进制数据不同，XML是高度结构化的，很多解析器和工具针对XML数据搜索和查询进行了优化。清单1是关于图书馆的一个简单XML文档。

　　清单1. 简单的XML文档
               
　　<?xml version=”1.0″ encoding=”UTF-8″?>
　　<library>
　　 <book edition=”5″>
　　 <title>Fundamentals of Database Systems</title>
　　 <author>Ramez Elmasri</author>
　　 <author>Shamkant B. Navathe</author>
　　 <year>2006</year>
　　 <publisher>Benjamin/Cummings</publisher>
　　 <category>Computer Science
　　 <subcategory>Databases</subcategory>
　　 </category>
　　 </book>
　　 <book edition=”3″ format=”hardcover”>
　　 <title>Mists of Avalon</title>
　　 <info>Marion Zimmer Bradley, published by Del Rey</info>
　　 <category>Fiction</category>
　　 </book>
　　</library>
 
　　从这个例子可以看出，与关系数据不同，XML数据通常是无模式和自描述的，但是展现出一种固有结构。这种结构主要通过元素（<library>和<book>）和属性（edition和format）来定义。每个元素都有很多属性（以及相应的值），元素中嵌套元素和文本内容。

　　通常，只有结构良好和有效的XML文档才能被应用程序处理。符合XML语法规则的文档是结构良好的。比如，XML文档必须有且只有一个根元素。符合XML模式的文档是有效的。模式定义了文档的组织规则和内容。比如，图书馆中的每个<book>必须有一个<title>元素，而且不能嵌套在其他<book>中。定义XML模式的多种语言之中，最常用的一种被简称为XML Schema。

　　如果信息用XML文档给出，可以用XML查询语言如XQuery检索数据。XQuery使用XPath表达式访问文档的特定部分。清单2中给出了一个简单的XPath表达式，检索2006年出版的图书。

　　清单2. 简单的XPath表达式
               
　　    /library/book[year=”2006″]//subcategory
 
　　XPath表达式并入到通过FLWOR（For、Let、where、Order by、Return）表达式指定的XQuery语句中。比如，清单3中的XQuery表达式按标题顺序返回2006年Benjamin/Cummings出版的图书。

　　清单3. XQuery
               
　　    for $b in doc(“mylibrary.xml”)//book
　　 where $b/publisher=”Benjamin/Cummings”
　　 order by $b/year
　　 return $b/title
 
　　XML模式变化的分类

　　在模式演化过程中，模式的任何成分都可能随着版本的不同而变化。这一节介绍和验证有关的不同的模式变动类型。首先可以分为基本变化和复杂变化。然后说明它们对验证文档的影响。

　　基本变化

　　FpML Architecture Working Group围绕FpML提出把模式的变化分为五种类型，FpML是定义信息共享、处理、交换、派生及其他结构化产品的商业产品标记语言（关于这种分类的更多信息请参阅 参考资料）。表1列出了模式定义最常见的变化类型。同时说明对于每种变化，旧模式的文档实例根据新模式是否有效（向前兼容），新模式的文档实例根据旧模式是否有效（向后兼容）。

　　这些变化反映了不同行业的实际情况。但必须认识到，由于XML模式语言（比如DTD和XML Schema）是扩展的，也可能出现其他类型的变化。此外，虽然一些复杂变化可归为基本变化的组合（比如删除后的精化），但为了 下一节 中更好的理解仍然单独列出。请注意，大部分复杂变化，旧模式的文档实例对于新模式通常都不再有效，或者需要应用程序的某些支持。通过 下一节 中的例子可以很清楚地看到这点。此外，基本变化中，只有精化和删除可能引起兼容性问题，通过示例分析将很清楚看到这点。

　　表1. 基本的模式变化及其对验证的影响

　　复杂变化

　　表1中的变化很常见，但是没有涵盖所有可能的情况。本文扩展了这种分类，增加了几种更复杂的变化类型，如表2所示。

　　表2. 复杂的模式变化及其对验证的影响

　　XML模式演化对查询的影响

　　模式变化除了影响验证之外，各种变化还影响查询公式：针对旧模式文档的查询不一定适用于新模式文档（反之亦然）。这一节通过一系列基于ACORD（Association for Cooperative Operations Research and Development）模式（请参阅 参考资料）的例子，讨论模式演化对查询及其结果的影响。ACORD协会为保险、再保险及相关金融服务业制定标准。实际上，ACORD平均每月发布一次新模式，示例中使用的变化仅仅是为了说明问题，不代表实际模式的变化。查询的是金融交易中参与者的个人信息而不是ACORD标准的金融信息。

　　一般查询

　　我们首先给出两个一般的查询，不访问修改的模式元素。每个查询都有自己的规范（类似于XQuery表达式）和基于清单4所示实例文档的结果（包括旧模式和新模式的文档实例）。为了清晰，清单中包括实例的图形化表示而不是模式规范。

　　清单5、6和7表明如果查询不访问修改过的元素，结果差不多。其中，清单5检索每个实例的全部交易，对查询没有限制；清单6检索交易的特定元素（姓氏），清单7和清单6相同，但是按交易ID对结果分组。这些例子很简单，说明如果查询中不涉及模式的演化部分就没有什么问题。但是，情况并非总是如此，如下一组例子所示。

　　清单4. 模式修改的文档实例：精化<SSN>元素，删除<BirthDate>元素

　　旧模式的文档实例
                           
　　<TXLife>
　　<TXLifeRequest id=”TXLifeRequest1001″>
　　 <TransRefGUID>2006-0712-1001</TransRefGUID>
　　 <TransType tc=”103″>Schema Evolution </TransType>
　　 <OLifE>
　　 <Party id=”ID1101″>
　　 <Person>
　　 <FirstName>Alan</FirstName>
　　 <LastName>Bird</LastName>
　　 <Gender>MALE</Gender>
　　 </Person>
　　 </Party>
　　 <Party id=”ID1102″>
　　 <Person>
　　 <FirstName>Anthony</FirstName>
　　 <LastName>Bell</LastName>
　　 <Gender>MALE</Gender>
　　 <BirthDate>1975-11-14</BirthDate>
　　 </Person>
　　 </Party>
　　 </OLifE>
　　</TXLifeRequest>
　　</TXLife>
 
　　新模式的文档实例
                           
　　<TXLife>
　　<TXLifeRequest id=”TXLifeRequest1002″>
　　 <TransRefGUID>2006-0712-1001</TransRefGUID>
　　 <TransType tc=”103″>Schema Evolution </TransType>
　　 <OLifE>
　　 <Party id=”ID1103″>
　　 <Person>
　　 <FirstName>Carl</FirstName>
　　 <LastName>Devon</LastName>
　　 <Gender>MALE</Gender>
　　 <SSN>606-23-0987</SSN>
　　 </Person>
　　 </Party>
　　 <Party id=”ID1104″>
　　 <Person>
　　 <FirstName>Cinthia</FirstName>
　　 <LastName>Din</LastName>
　　 <Gender>FEMALE</Gender>
　　 </Person>
　　 </Party>
　　 </OLifE>
　　</TXLifeRequest>
　　</TXLife>
 
　　清单5. 检索Schema Evolution示例中全部交易
　　XQuery for $trans in //TXLifeRequest return $trans
 
　　结果

　　结果是包含旧文档和新文档中都有的交易的 return 元素。 

　　清单6. 检索所有<LastName>元素的值

　　XQuery for $trans in //TXLifeRequest//LastName
　　return <result>{$trans}</result>
 
　　结果

　　<result>
　　<LastName>Bird</LastName><LastName>Bel</LastName>
　　<LastName>Devon</LastName><LastName>Din</LastName>
　　</result>
　
　　清单7. 检索所有<LastName>元素的值，按交易分组

　　XQuery for $trans in //TXLifeRequest
　　for $tid in $trans/@id let $t:=$trans//LastName
　　return
　　<TX>
　　 {$tid}
　　 <Names>
　　 {$t}
　　 </Names>
　　</TX>
 
　　结果<result>

　　<LastName>Bird</LastName><LastName>Bel</LastName>
　　<LastName>Devon</LastName><LastName>Din</LastName>
　　</result>
 
　　基本变化

　　在前述五种基本变化类型中，我们主要讨论精化 和删除，因为它们影响查询公式和结果。其他变化对查询计算没有显著的影响（扩展 不会产生问题，除非新元素使用新的结构定义 — 这样就相当于进行了精化；重释 和重定义 对元素的结构没有影响）。因此只有精化和删除和下一节有关。这一节中讨论的所有示例都是后面所述 基本原则 的基础。

　　精化

　　清单4中的第一种基本变化是ACORD模式的扩展，增加了一个可选元素表示参与者的社会安全号码（SSN）。清单8返回参与交易的所有人的姓氏，如果有SSN的话同时返回。因此，检索了四个参与者（包括旧文档和新文档）和一个SSN。虽然查询访问新元素，它的访问也仅限于return子句 — 就是说是非限定性的。换句话说，清单10的where语句中有一个exist子句，要求具有SSN的那些人的名字。因此，查询处理仅限于新模式文档实例，因为旧模式的所有实例计算where语句的结果都是false。清单10还说明如何编写查询才能保持跨模式的能力。

　　清单8. 检索姓氏和SSN，按参与者和交易分组

　　XQuery for $trans in //TXLifeRequest
　　for $tid in $trans/@id
　　return
　　<TX>
　　 { $tid }
　　 { for $P in $trans//Party
　　 return
　　 <Party>
　　 {$P//LastName}
　　 {$P//SSN}
　　 </Party> }
　　</TX>
 
　　结果<TX id=”TXLifeRequest1001″>
　　 <Party><LastName>Bird</LastName></Party>
　　 <Party><LastName>Bell</LastName></Party>
　　</TX>
　　<TX id=”TXLifeRequest1002″>
　　 <Party>
　　 <LastName>Devon</LastName>
　　 <SSN>606-23-0987</SSN>
　　 </Party>
　　 <Party><LastName>Din</LastName>
　　 </Party>
　　</TX>
 
　　清单9. 模式变化的文档实例：元素组合

　　旧模式的文档实例
                           
　　<TXLife>
　　<TXLifeRequest id=”TXLifeRequest1001″>
　　 <TransRefGUID>2006-0712-1001</TransRefGUID>
　　 <TransType tc=”103″>Schema Evolution</TransType>
　　 <OLifE>
　　 <Party id=”ID1101″>
　　 <Person>
　　 <FirstName>Alan</FirstName>
　　 <LastName>Bird</LastName>
　　 <Gender>MALE</Gender>
　　 </Person>
　　 <Address>
　　 <Line1>998 Mamaroneck Ave</Line1>
　　 <City>White Plains</City>
　　 <AddressStateTC tc=”60″>NY</AddressStateTC>
　　 <Zip>10605</Zip>
　　 </Address>
　　 </Party>
　　 </OLifE>
　　</TXLifeRequest>
　　</TXLife>
　
　　新模式的文档实例
                           
　　<TXLife>
　　<TXLifeRequest id=”TXLifeRequest1002″>
　　 <TransRefGUID>2006-0712-1001</TransRefGUID>
　　 <TransType tc=”103″>Schema Evolution</TransType>
　　 <OLifE>
　　 <Party id=”ID1103″>
　　 <Person>
　　 <FirstName>Carl</FirstName>
　　 <LastName>Devon</LastName>
　　 <Gender>MALE</Gender>
　　 </Person>
　　 <Address>20 Fifth Ave, New York, NY 10011</Address>

　　 </Party>
　　 </OLifE>
　　</TXLifeRequest>
　　</TXLife>