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