引言

　　将 XML 数据作为字符型大对象（character Large Object，CLOB）存储或缩减为关系表的日子已经一去不复返了。这种方法的问题在于，对 XML 文档进行分解并存储后，如果随后将其重新组合起来，并不会得到最初的文档。SQL 语句无法像 XQuery 语句一样对海量数据进行搜索和排序的日子也一去不复返了。与采用混合数据服务器相比，之前处理关系数据服务器的查询（缩减和非缩减）以及向模式添加字段所需时间太长了。

　　为了减少存储时间和需求，IBM 推出了 DB2® 9，这是一个混合数据库系统，能够分别以各自的格式存储结构化和非结构化数据。XML 文档的完整性得到了保留，而且不需要对其进行缩减或分解。用户可以在数据量大时从 SQL 切换到 XQuery。

　　混合数据类型

　　您可以同时访问关系数据和 XML 数据，不过，将这些数据混合在单个请求中会比单独访问上述任何一种数据类型更快，即使数据量增加也没有问题。为了遵守相关的法律法规要求，现在需要较长时间保留越来越多的数据。

　　通过将这些数据类型组合到一起，IBM 利用其混合 XML/关系存储机制，可大幅度减少数据存储需求和处理 XQuery 和 SQL 查询的时间。可以通过在单个表下放置多个表空间来创建和管理大得多的数据库，将数据分布在多个计算机上，以及通过参与机制按维度组织数据。

　　为了增强安全性，DB2 9 提供了创新的基于标签的访问控制（Label-Based Access Control，LBAC），可将用户权限分配给每个行或包含跨不同计算机的多个表空间的表。它允许按分区管理数据加载和备份。不过，DB2 9 存在一些可通过 Web 服务予以克服的限制。我们需要对每个限制进行分析，并了解其可能的解决方案。

　　Web 服务数据分析

　　用户无法知道是否应使用 SQL 或 XQuery 形成查询。他并不知道要查询的相关数据的量。他需要确定数据量是否非常大。

　　我建议 Web 服务数据分析最好能根据系统如何分析跨多台计算机、按维度组织或属于一个表的多个表空间中的数据来建议用户使用何种语句格式。如果分析表明，要查询的数据或部分数据非常大，则将发送一条消息，建议使用 XQuery 语句作为首选方法。

　　Web 服务转换器

　　如果用户更习惯使用 SQL 语句，而 XQuery 语句方面的使用经验很少或没有，该怎么办呢？如果用户使用 XQuery，而不习惯使用 SQL 语句又该如何呢？如果用户习惯于使用不同数据库管理系统的 SQL，而已迁移到 DB2 9 时该怎么办呢？

　　此决策者可能没有足够的时间等着去学习 XQuery，因为可能会要求立即做出决定。DB2 9 无法将 SQL 查询转换为 XQuery（反之亦然），也无法检查经过转换的 SQL 或 XQuery 查询是否已经过了优化而使用的资源最少。

　　我们已经知道，结构不合理的 SQL 查询会降低关系数据库的性能。这对于嵌入到结构良好的 SQL 语句内的 XQuery 语句也是如此。即使使用混合数据服务器，结构不合理的查询也将无法执行。

　　子检查器

　　在 SQL 和 XQuery 语句之间进行转换前，或将 XQuery 语句嵌入 SQL 查询中时，我们需要检查二者的语法。显然，SQL 和 XQuery 具有不同的语法和范围约定。

　　与典型的关系系统目录相比，XML 模式信息经常更为复杂，并可能发生变化。XQuery 可以对形成不同模式或同个模式的不同版本的多个文档进行操作。有些文档可能没有模式。

　　因此，我们需要为父 Web 服务转换器创建三个子 Web 服务。它们分别是：

Web 服务 SQL 检查器
Web 服务 XQuery 检查器
Web 服务嵌入式 XQuery 检查器
子处理器

　　检查器在混合数据库服务器上验证了 SQL 或 XQuery 语句结构良好后，下一步就是将结果作为输入发送到以下子 Web 服务之一中去：

Web 服务 SQL-XQuery 转换器
Web 服务 XQuery-SQL 编译器
Web 服务嵌入式 XQuery 编译器
SQL-XQuery 转换器将 SQL 映射到 XQuery。如果输出给出了转换问题列表，则必须解决这些问题。SQL 和 XQuery 具有不同的语法和范围约定。

　　虽然 XQuery-SQL 编译器处理转换工作更快，但更可能产生给出相同输出的多个 SQL 代码片段。编译器应该具有检测产生冗余结果的 SQL 代码片段的机制。这意味着将有必要减少 SQL 代码。应该有这样的机制，能建议哪些 SQL 代码片段性能最佳，使用的资源非常少，即使在网络流量出现突然变化也不会造成系统过载。

　　嵌入式 XQuery 编译器设计用于将经过转换的部分 SQL 语句替换为 XQuery 对等项。这对于处理即使在混合数据库系统上 SQL 也无法处理的海量数据尤其有用，而且更加灵活。

　　对于所有三个子 Web 服务，在所有转换问题得到解决以满足用户需求前，非常有必要提供反馈信息。必须配备更改管理，以提高效率。

　　Web 服务性能分析器

　　用户无法确定 SQL 和 XQuery 语句间的差异在资源使用方面是否影响很小。DB2 9 并不具有执行各种测试类型来确定哪个查询类型（SQL 或 XQuery）最优的功能。它无法提供有关磁盘碎片对分区或跨计算机的语句执行的影响的信息。

　　解决了转换问题后，最后一步是创建 Web 服务性能分析器，在实际对海量数据执行操作前，开发人员可以使用此分析器来在非生产环境中比较 SQL 和 XQuery 代码的性能。独立数据的查询性能中一定要防止对不相关数据的扫描。

　　以下给出了性能测试类型的一个部分列表。开发人员执行某个测试类型时，可以会发现其他类型无法发现的问题。对于这些测试，应该进行容量和压力测试，以确保生产环境中的查询将不会导致系统过载。

表 1. 性能测试类型

  类型              问题

功能测试	查询是否正常工作？结果是否是最终用户预期的结果？是否是业务执行人员所预期的结果？哪种查询类型（SQL 或 XQuery）所得到的结果更好？
容量测试	在数据量很大的情况下查询是否正常工作？每个查询能够处理多少数据量？
压力测试	可用资源少是否会带来问题？哪种查询类型表明其能够比其他查询更好地处理资源压力？
备份和恢复测试	备份和恢复流程是否正常工作？每个查询类型从预期和非预期停机情况恢复需要多长时间？
配置测试	每个查询类型的流程在使用经过更新的操作系统和相关 Web 服务应用程序版本时是否正常工作？哪个查询类型配置性能更好？
文档测试	联机文档是否足够帮助系统管理员和用户了解用户如何使用 Web 服务来检查相关数据的量、检查查询的语法和范围约定、从一种查询类型转换为另一种查询类型并解决转换问题？
负载测试	系统是否能处理通信流量的突然变化？
信息保证测试	Web 服务能否满足保密性、完整性和可用性条件？
安全访问控制	授权用户是否能够按照指定的方式访问 LBAC 指定的行或表？
后端接口测试	查询与后端应用程序和数据库的接口是否正常工作？

　　结束语

　　开发 Web 服务来将 SQL 转换为 XQuery（以及反向转换）要求开发人员、业务分析人员、系统管理员和潜在用户进行协作。这要求事先进行计划，以创建、测试和部署 Web 服务来分析数据、自动转换和测试各种条件下结果的性能。应该进行多个性能测试，因为不同测试类型可能会发现其他类型未发现的问题。在这些测试中，应该进行容量和压力测试来确保生产环境中的查询将不会导致系统过载。

　　您会发现，通过解决这些问题，会使得您开发 Web 服务来分析数据、转换查询和执行测试变得更加容易。您可以使用 IBM Rational RequisitePro 来管理需求层次结构。还可以使用 IBM Rational ClearCase 来通过更高效的变更管理来缩短构建/发布周期，从而提高工作效率。