XML+SQL=数据库的未来？

XML标准和文档的出现为关系数据库出了一道难题，以访问二维表数据为主的SQL和XML的结合就成了一条中和之路。于是乎，漫长的SQL/XML结合之旅开始了。 　　随着新XML文档规范的问世，厂商正在加大在RDBMS(关系型数据库管理系统)中对XML支持的力度。 　　当XML五年前推出时，它所具有的改写数据管理规则的前景引起了关系型数据库厂商的注意，不过他们并没有恐慌。十年前就经历过这一幕，当时对象数据库被人们赋予了范例改变者的作用。这种新软件规范的确出现了，并普及了持久性概念：即无需费劲地转换关系表格就能保存和检索编程语言对象的能力。但结果是，RDBMS学会了新“把戏”，那就是找到了如何利用SQL:1999对象模型保存复杂的数据类型的办法。现在已经有了用于关系型数据库和对象数据库的JDO(Java 数据对象)应用。微软表示，即将推出的Yukon版SQL Server将能够保持.Net对象。 　　吸收了对象后，RDBMS厂商现在正为吸收XML文档而努力工作。不过，不要指望历史能够简单重演。我们都知道运营企业的大部分信息存储在我们创建和交换的文档中，这些文档很少被保存在企业数据库中。既然XML既可以代表我们看到和接触到的文档(如采购订单)，又可以代表在Web服务网络上交换这些文档的信息，因此我们的数据库能否保存和管理XML文档比以往更加至关重要。一枚真正的重磅炸弹正在制造中,没人准确知道它将生产什么影响，但是目前可以分析它，做出一些有根据的猜测。 SQL/XML结合之旅第一步 　　漫长的SQL/XML结合之旅第一步,是将关系型数据作为XML格式发布。XML发布是合乎逻辑的起点，因为它可以容易地在XML中代表SQL结果集合，因为那么多的动态网页都是由SQL查询来提供的。传统的方法要求用程序访问结果集合和用程序构建网页。新方法以完全公布的方式制作动态网页，利用SQL-to-XML查询生成数据的XML表示,并利用XSLT(可扩展样式表语言转换)将XML溶入到HTML中。 　　最初这些虚拟文档是利用专有的SQL扩展来创建的。现在有了一种叫做SQL/XML的新ISO/ANSI标准，这项标准定义了一种通用的方法。目前，SQL/XML得到了Oracle和DB2的支持。它定义了用于这些产品中的本机XML数据类型的面向XML的操作符。SQL Server现在还不支持XML数据类型或SQL/XML扩展，微软定于2004年推出的Yukon将支持它们。 存储文档的方式 　　企业中的大多数信息保存在存储文档中，而不是关系型数据库中。将这些文档输入到数据库中的理由始终存在，那就是集中式管理和全文本搜索，但是在缺少一种将文档中的数据与数据库中的数据建立关系方法的情况下，这些理由不具有说服力。而XML则为人们提供了论据。 　　当企业文档从已有格式映射到XML时(这是一条才刚刚开始的漫长路程)，将两种风格的数据建立关系成为了可能。比如说，有一种在关系型表格中保存索赔数据和以XML格式保存索赔文档的保险应用。混合型SQL/XML数据库使这个应用可以从文档子集中提取XML段落。这个子集可以通过将文档中的XML元素与关系型表格中的列值结合在一起来创建。 　　利用一些不同类型的存储和查询战略，目前取得了巨大的进展。在存储方面，存在两种通用的方法。一种是可以将整个文档输入到数据库的列中，或者可以将文档“撕碎”后放到多个关系型表格中。后一种方法充分利用了数据库的查询引擎和强大的更新功能，但是从不规则XML数据到SQL的映射比从SQL到XML的映射要困难得多。如果你的XML文档由XML模式描述控制的话，将对映射有所帮助。XML模式描述为XML-to-SQL映射器提供了线索，并且用户可以向这类描述添加注释来更准确地控制映射。如果数据库支持可以接收形状不规则的XML数据对象的话，也将对映射有所帮助。Oracle公司扩展了关系型数据库技术，使它包括了作为SQL：1999一部分的对象。在其8i和9i上已经成熟到了这种程度，那就是可以在对象/关系类型中表示XML 模式的类型系统。 查询战略 　　XPath是所有面向XML查询战略的基础，这是一种用于向下生成树型结构和删除树枝的语法。当一张XSLT样式表转换XML文档时，它使用XPath来隔离文档的分段。支持XML查询的关系型数据库(包括老牌产品Oracle、DB2和SQL Server以及像OpenLink Software的Virtuoso这样的新军，但还不包括MySQL)以同样的方式使用XPath。起初，这种对XPath的支持是以专有扩展的形式提供的。最近，SQL/XML标准定义了具有XPath意识的SQL扩展的通用集合。XPath还在W3C即将发布的XQuery标准中得到了应用。XQuery标准致力于使SQL数据连接功能适应半结构化XML数据世界。IBM公司表示，其正在努力开发XQuery，以使SQL开发人员可以他们熟悉的方式处理XML内容。 　　尽管厂商急不可待地等待XQuery 1.0的最终完成，但是它们的XQuery应用在某些方面将不如目前的SQL/XML应用强大。最明显的是，XQuery 没有定义用于更新XML文档中的元素的语法。虽然SQL/XML的更新机制还没有得到批准，但它已经被定义了，已被应用在Oracle和DB2中。 　　SQL/XML抢走了XQuery的风头吗？从短期看，XQuery看起来只是一种完成可能用SQL和XPath同样可以完成工作的替代方法。但是，从长期看，开发人员可能希望在他们的所有数据源上保持XML抽象。在这种情况下，作为一种为处理复杂的数据而开发的丰富而全面的编程语言，XQuery可能将成为一种重要的范例。 文档的未来 　　让我们假设2005年的某个时刻，有一张正在流经业务过程的采购订单。这是一个利用像InfoPath这样的工具创建的XML文档，它上面混合记录着核心数据和上下文元数据。包括商品号和部门代码的核心数据将输入到一张关系型表格的列中。可能包含由请求人、审查人和批准人参加的包括讨论的上下文元数据将仍以文档形式保存。目前，这种上下文内容从来没有被保存在RDBMS中。重要的是了解数据怎样到达那里以及它的含意。 　　一旦填写后，这张采购订单就被输入到在Web服务网络上流动的工作流中。安全服务可以通过更新SOAP头来执行授权政策，编排服务可以搜索具有同样相关ID的SOAP头的文档集合。这些活动的中间阶段将需要某种数据库技术来管理透明地出现在查询中的XML，不过这可能不是Oracle或DB2的任务。这时，一个专门的XML数据库，如Software AG的Tamino 或Sleepycat Software的Berkeley DB XML，可能更适于完成这项任务。它们的速度很快，可以很好地用于动态XML文档，甚至在这些文档缺少RDBMS SQL/XML映射器所依赖的模式时。 　　在工作流过程以及在完成后，文档将通过某个URL可以供有关各方访问。这个URL可以决定文档的映射，从混合的SQL/XML RDBMS到一台Intranet Web服务器或WebDAV存储库；或者可以决定本机保存在RDBMS中的文档基础实例。不管是哪一种情况，业务过程的状态(核心数据和上下文元数据)将在任何时候都可以为对它感兴趣并获得授权的人员所访问。此外，文档中保存的两种类型的数据将可以跨越企业查询，从而将SQL和XML数据源整合在一起，创建融合的视图。 　　企业数据管理风格正在发生重大改变，有许多重要的架构问题还没有得到解决。毫不奇怪，Oracle希望将各种东西都保存在集中式混合DBMS中。而IBM则表示宁愿让你能够跨多种来源将数据结合在一起。每一种战略都有自己的长处，而大多数企业最终将由于不同的原因以不同的方式购买这两种技术。尽管存在这些不同，我们正在见证一次神圣的结合。SQL和XML结为夫妻，蜜月开始了。