想要在准备查询混合数据库系统时将SQL Server转换为 XQuery 和进行反向转换吗?了解如何开发 Web 服务来从SQL Server映射到 XQuery、将 XQuery 编译为SQL Server并将SQL Server查询的各个部分转换为嵌入式 XQuery 语句。您将看到一些示例，以了解如何将 IBM® Rational® Requisite Pro 和 IBM Rational ClearCase 用作转换过程中协作工作的组成部分。

引言

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

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

混合数据类型

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

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

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

Web 服务数据分析

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

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

Web 服务转换器

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

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

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

子检查器

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

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

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

1、Web 服务 SQL 检查器

2、Web 服务 XQuery 检查器

3、Web 服务嵌入式 XQuery 检查器

子处理器

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

1、Web 服务 SQL-XQuery 转换器

2、Web 服务 XQuery-SQL 编译器

3、Web 服务嵌入式 XQuery 编译器

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

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

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

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

Web 服务性能分析器

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

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

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

评论 (0) All

登陆 还没注册？