使用SQL查询DB2 9中的XML数据

虽然 DB2 的混合体系结构与之前的版本有很大的不同，但是要利用它的新 xml(标准化越来越近了) 功能并不难。如果您已经熟悉 SQL，那么很快就可以将这方面的技能转化到对存储在 DB2 中的本地 xml(标准化越来越近了) 数据的处理上。通过本文就可以知道如何实现这一点。

DB2 Viper（就是DB2 9）中的 xml(标准化越来越近了) 特性包括新的存储管理、新的索引技术以及对查询语言的支持。在本文中，学习如何使用 SQL 或带 xml(标准化越来越近了) 扩展的 SQL（SQL/xml(标准化越来越近了)）查询 DB2 xml(标准化越来越近了) 列中的数据。接下来的文章将讨论 DB2 中新引入的对新兴的业界标准 XQuery 的支持，并探索 XQuery 在什么时候最有用。

您也许会感到惊讶，DB2 还支持双语查询 —— 即组合了来自 SQL 和 XQuery 的表达式的查询。至于应该使用哪种语言（或两种语言结合使用）取决于应用程序的需要，同时也取决于您本身所掌握的技能。其实，将两种查询语言中的元素组合到一个查询中并没有您想像的那么难。这样做还可以为搜索和集成传统 SQL 和 xml(标准化越来越近了) 数据提供强大的能力。

Sample 数据库

本文中的查询将访问在 “DB2 Viper 快速入门”（developerWorks，2006 年 4 月）中创建的 sample 数据库。这里我们简短地回顾一下，sample 数据库中 "items" 和 "clients" 表的定义：

create table items (

id int Prima(最完善的虚拟主机管理系统)ry key not null, 

brandname varchar(30), 

itemname varchar(30), 

sku int, 

srp decimal(7,2), 

comments xml(标准化越来越近了)

)

create table clients(

id int Prima(最完善的虚拟主机管理系统)ry key not null, 

name varchar(50), 

status varchar(10), 

contactinfo xml(标准化越来越近了)

)

图 1 显示了 "items.comments" 列中的示例 xml(标准化越来越近了) 数据，图 2 显示了 "clients.contactinfo" 列中的示例 xml(标准化越来越近了) 数据。随后的查询例子将引用其中某个 xml(标准化越来越近了) 文档或这两个文档中某些特定的元素。

查询环境

本文中的所有查询都是交互式地发出的，您可以通过 DB2 命令行处理器或 DB2 Control Center 中的 DB2 Command Editor 发出查询。本文中的屏幕图像和说明主要基于后一种方式。（DB2 Viper 还附带了一个基于 Eclipse 的 Developer Workbench，它可以帮助程序员图形化地构造查询。但是，本文不讨论应用开发问题或 Developer Workbench。）

要使用 DB2 Command Editor，需启动 Control Center 并选择 Tools > Command Editor。这时将弹出如 图 3 所示的窗口。在上面的面板中输入查询，单击左上角的绿色箭头运行查询，然后在下面的面板或 "Query results" 标签页中查看输出。

纯 SQL 查询

即使您对 SQL 所知有限，也仍然可以很轻松地查询 xml(标准化越来越近了) 数据。例如，下面的查询选择 "clients" 表中的全部内容，包括存储在 "contactinfo" 列的 xml(标准化越来越近了) 信息：

select * from clients

当然也可以编写更具选择性的 SQL 查询，使之包含关系投影和限制操作。下面的查询检索所有具有 "Gold" 状态的客户的 ID、姓名和联系方式。请注意，"contactinfo" 列包含 xml(标准化越来越近了) 数据，而其他两列不包含 xml(标准化越来越近了) 数据：

select id, name, contactinfo 

from clients

where status = 'Gold'

正如您所预料，您可以基于这样的查询创建视图，下面的 "goldview" 可以说明这一点：

create view goldview as 

select id, name, contactinfo 

from clients

where status = 'Gold'

不幸的是，很多事情光用 SQL 是无法解决的。通过纯 SQL 语句可以检索整个 xml(标准化越来越近了) 文档（刚才已证明这一点），但是却不能指定基于 xml(标准化越来越近了) 的查询谓词，也不能检索 xml(标准化越来越近了) 文档的某一部分或者 xml(标准化越来越近了) 文档中特定的元素值。换句话说，使用纯 SQL 不能对 xml(标准化越来越近了) 文档中的片段进行投影、限制、连接、聚集或排序操作。例如，您不能单独检索 Gold 客户的 email 地址或居住在邮政编码为 "95116" 的地区的客户的姓名。为了表达这些类型的查询，需要使用带 xml(标准化越来越近了) 扩展的 SQL（SQL/xml(标准化越来越近了)）、XQuery 或结合使用这两种查询语言。

下一节将探讨 SQL/xml(标准化越来越近了) 的几个基本特性。在接下来的文章中，我们将学习如何编写 XQuery 以及如何将 XQuery 与 SQL 结合使用。

SQL/xml(标准化越来越近了) 查询

顾名思义，SQL/xml(标准化越来越近了) 被设计用来为 SQL 和 xml(标准化越来越近了) 两者之间搭一座桥。它首先是 SQL 标准的一部分，经过演化现在包括将 XQuery 或 XPath 表达式嵌入 SQL 语句的规范。XPath 是用于导航 xml(标准化越来越近了) 文档以便发现元素或属性的一种语言。XQuery 包括对 XPath 的支持。

请务必注意，XQuery（和 XPath）表达式是大小写敏感的。例如，引用 xml(标准化越来越近了) 元素 "zip" 的 XQuery 并不适用于名为 "ZIP" 或 "Zip" 的 xml(标准化越来越近了) 元素。SQL 程序员有时候很难记住大小写敏感这一点，因为 SQL 查询语法允许使用 "zip"、"ZIP" 和 "Zip" 来引用同一个列名。

DB2 Viper 提供了超过 15 个 SQL/xml(标准化越来越近了) 函数，通过这些函数可以搜索 xml(标准化越来越近了) 文档中的特定数据，将传统数据转换成 xml(标准化越来越近了)，将 xml(标准化越来越近了) 数据转换成关系数据，以及执行其他有用的任务。本文不讨论 SQL/xml(标准化越来越近了) 的所有方面，而只是谈到几种常见的查询挑战，以及一些关键的 SQL/xml(标准化越来越近了) 函数如何解决这些挑战。

根据 xml(标准化越来越近了) 元素值 “限制” 结果

SQL 程序员常常编写根据某种条件限制从 DBMS 返回的行的查询。例如，清单 3 中的 SQL 查询限制从 "clients" 表中检索的行，使之只包括那些具有 "Gold" 状态的客户。在这个例子中，客户的状态可在 SQL VARCHAR 列中捕捉。但是，如果您想根据某种应用于 xml(标准化越来越近了) 列中数据的条件对搜索进行限制，那么应该怎么做呢？SQL/xml(标准化越来越近了) 的 xml(标准化越来越近了)Exists 函数为完成该任务提供了一种手段。

通过 xml(标准化越来越近了)Exists 可以在 xml(标准化越来越近了) 文档中找到一个元素，并测试它是否满足某个特定的条件。如果用在 WHERE 子句中，则 xml(标准化越来越近了)Exists 可以限制返回的结果，使之只包括那些包含具有特定 xml(标准化越来越近了) 元素值的 xml(标准化越来越近了) 文档的行（换句话说，指定的值等于 "true"）。

让我们看看早先遇到的一个查询问题。假如您想找到居住在具有特定邮政编码的地区的所有客户的姓名。您也许还记得，"clients" 表的一个 xml(标准化越来越近了) 列中存储了客户的地址（包括邮政编码）。（见 图 2。）通过使用 xml(标准化越来越近了)Exists，可以从 xml(标准化越来越近了) 列中搜索目标邮政编码，并相应地限制返回的结果集。下面的 SQL/xml(标准化越来越近了) 查询返回居住在邮政编码为 95116 的地区的客户的姓名：

select name from clients

where xml(标准化越来越近了)exists('$c/Client/Address[zip="95116"]'

passing clients.contactinfo as "c")

第一行是一个 SQL 子句，指定仅检索 "clients" 表 "name" 列中的信息。WHERE 子句调用 xml(标准化越来越近了)Exists 函数，指定一个 XPath 表达式，这个表达式使 DB2 找到 "zip" 元素并检查元素值是否为 95116。"$c/Client/Address" 子句表明 DB2 用于定位 "zip" 元素的 xml(标准化越来越近了) 文档层次结构中的路径。通过使用可以从节点 "$c"（稍后将会解释）访问的数据，DB2 将从 "Client" 元素中找到它的子元素 "Address"，以便检查邮政编码（"zip" 值）。最后一行决定 "$c" 的值：它是 "clients" 表的 "contactinfo" 列。因此，DB2 检查 "contactinfo" 列中的 xml(标准化越来越近了) 数据，从根元素 "Client" 深入到 "Address" 子元素再找到 "zip" 子元素，然后判断客户是否居住在目标地区。如果客户住在目标地区，则 xml(标准化越来越近了)Exists 函数的返回值为 "true"，DB2 将返回与那一行相关的客户的姓名。

在使用 xml(标准化越来越近了)Exists 查询谓词时经常会出现一个错误，如 清单 6 所示。

select name from clients

where xml(标准化越来越近了)exists('$c/Client/Address/zip="95116" '

passing clients.contactinfo as "c")

虽然这个查询也可以成功地执行，但是它不能限制结果，使之仅包含居住在邮政编码为 95116 的地区的客户。（这是由于标准中规定的语义造成的，而且这并不是 DB2 所特有的。）为了限制结果，使之仅包含居住在邮政编码为 95116 的地区的客户，需要使用前面 清单 5 中展示的语法。

您可能很想知道如何在应用程序中包括限制 xml(标准化越来越近了) 数据的查询。虽然本文不详细讨论应用开发话题，但还是提供了一个 简单的 Java 例子，这个例子在一条 SQL/xml(标准化越来越近了) 语句中使用一个参数标记位将输出限制为居住在给定地区的客户的信息。

“投影” xml(标准化越来越近了) 元素值

现在让我们考虑一种稍微有些不同的情景，假设您想将 xml(标准化越来越近了) 值投影到返回的结果集。换句话说，我们要从 xml(标准化越来越近了) 文档中检索一个或多个元素值。有很多方法可以做这件事。首先我们使用 xml(标准化越来越近了)Query 函数来检索一个元素的值，然后使用 xml(标准化越来越近了)Table 函数来检索多个元素的值，然后将这些映射到一个 SQL 结果集的列。

我们来考虑如何解决之前摆在我们面前的一个问题：如何创建一个列出 Gold 客户的 email 地址的报告。下面 清单 7 中的查询调用 xml(标准化越来越近了)Query 函数来完成这项任务：

select xml(标准化越来越近了)query('$c/Client/email' 

passing contactinfo as "c") 

from clients 

where status = 'Gold'

第一行指定要返回根元素 "Client" 的 "email" 子元素的值。第二行和第三行表明 DB2 在哪里可以找到该信息 —— 在 "clients" 表的 "contactinfo" 列中。第四行进一步限制查询，表明您只对 Gold 客户的 email 地址感兴趣。这个查询将返回一组 xml(标准化越来越近了) 元素和值。例如，如果有 500 名 Gold 客户，每个客户有一个 email 地址，那么输出将是一个单列的结果集，一共有 500 行，如 清单 8 所示：

1

--------------------------------------------

<email>user5976@anyprovider.com</email>

. . . 

<email>someID@yahoo.com</email>

如果每个 Gold 客户有多个 email 地址，那么需要指示 DB2 只返回首要的地址（也就是在客户的 "contactinfo" 文档中找到的第一个 email 地址）。为此，可以修改查询的第一行中的表达式：

select xml(标准化越来越近了)query('$c/Client/email[1]' 

passing contactinfo as "c") 

from clients 

where status = 'Gold'

最后，如果有些 Gold 客户没有 email 地址，那么可能要编写一个查询从结果集中排除 null 值。为此可以修改之前的查询，添加另一个谓词到 WHERE 中，以测试是否缺少 email 信息。您已经熟悉了一个可以帮您实现这一点的 SQL/xml(标准化越来越近了) 函数 —— 那就是 xml(标准化越来越近了)Exists。清单 10 展示了如何重新编写之前的查询，以便过滤掉那些联系方式（存储为 xml(标准化越来越近了) 文档）中缺少 email 地址的 Gold 客户的行：

select xml(标准化越来越近了)query('$c/Client/email[1]' 

passing contactinfo as "c") 

from clients 

where status = 'Gold'

and xml(标准化越来越近了)exists('$c/Client/email' passing contactinfo as "c")

现在我们考虑一个稍微不同的情景，假设您要检索多个 xml(标准化越来越近了) 元素值。xml(标准化越来越近了)Table 可以从 xml(标准化越来越近了) 列中的数据生成标量输出，可以为程序员提供 xml(标准化越来越近了) 数据的 “关系” 视图，因此非常有用。与 xml(标准化越来越近了)Exists 和 xml(标准化越来越近了)Query 一样，xml(标准化越来越近了)Table 函数使 DB2 在 xml(标准化越来越近了) 文档层次结构中定位到感兴趣的数据。然而，xml(标准化越来越近了)Table 还包括一些子句，用于将目标 xml(标准化越来越近了) 数据映射到 SQL 数据类型的结果集列。

考虑以下查询（清单 11），该查询投影存储在 "items" 表中的关系数据和 xml(标准化越来越近了) 数据。（关于 "items" 表请查看 图 1）。评论 ID、客户 ID 和评语存储在 "comments" 列中的 xml(标准化越来越近了) 文档中。商品名称存储在一个 SQL VARCHAR 列中。

  

select t.Comment#, i.itemname, t.CustomerID, Message from items i, 

xml(标准化越来越近了)table('$c/Comments/Comment' passing i.comments as "c"

columns Comment# integer path 'CommentID',

CustomerID integer path 'CustomerID',

Message varchar(100) path 'Message') as t

第一行指定将包含在结果集中的列。查询中后面的几行表明，用引号括起来、并且以变量 "t" 为前缀的列是基于 xml(标准化越来越近了) 元素值的列。第二行调用 xml(标准化越来越近了)Table 函数指定包含目标数据（"i.comments"）的 DB2 xml(标准化越来越近了) 列和在该列的 xml(标准化越来越近了) 文档中的路径，通过该路径可以定位感兴趣的元素（在根元素 "Comments" 的子元素 "Comment" 中）。第 3 到 5 行的 "columns" 子句标识出将被映射到第一行指定的 SQL 结果集中的输出列的特定 xml(标准化越来越近了) 元素。这个映射需要指定 xml(标准化越来越近了) 元素值将被转换成的数据类型。在这个例子中，所有 xml(标准化越来越近了) 数据被转换成传统的 SQL 数据类型。

图 4 展示了运行该查询得到的示例结果。可以看到，输出是一个简单的 SQL 结果集。注意，列名已经被变成大写形式 —— 这在 SQL 中是很常见的。

如果需要的话，还可以使用 xml(标准化越来越近了)Table 创建包含 xml(标准化越来越近了) 文档的结果集。例如，以下语句产生类似于上述结果的结果集，不同的是 "Message" 数据被包含在一个 xml(标准化越来越近了) 列中，而不是包含在一个 SQL VARCHAR 列中。

  

select t.Comment#, i.itemname, t.CustomerID, Message from items i, 

xml(标准化越来越近了)table('$c/Comments/Comment' passing i.comments as "c"

columns Comment# integer path 'CommentID',

CustomerID integer path 'CustomerID',

Message xml(标准化越来越近了) by ref path 'Message') as t 

创建 xml(标准化越来越近了) 数据的关系视图

正如您可能想像到的那样，SQL/xml(标准化越来越近了) 函数可用于定义视图。如果要为 SQL 应用程序的程序员提供本地 xml(标准化越来越近了) 数据的关系模型，那么这种功能特别有用。

为 xml(标准化越来越近了) 列中的数据创建关系视图并不比投影 xml(标准化越来越近了) 元素值复杂多少。您只需编写一个 SQL/xml(标准化越来越近了) SELECT 语句，在语句中调用 xml(标准化越来越近了)Table 函数，并以此作为视图定义的基础。下面 清单 13 中的例子基于 "items" 表的 xml(标准化越来越近了) 列和非 xml(标准化越来越近了) 列中的信息创建一个视图。（这类似于 清单 11 中的查询。）

 

create view commentview(itemID, itemname, commentID, message, mustrespond) as 

select i.id, i.itemname, t.CommentID, t.Message, t.ResponseRequested from items i, 

xml(标准化越来越近了)table('$c/Comments/Comment' passing i.comments as "c"

columns CommentID integer path 'CommentID',

Message varchar(100) path 'Message',

ResponseRequested varchar(100) path 'ResponseRequested') as t;

虽然在 xml(标准化越来越近了) 列中的数据上创建关系视图很容易，但是用起来要小心。在对那样的视图发出查询时，DB2 不使用 xml(标准化越来越近了) 列索引。因此，如果以 ResponseRequested 列为索引，并发出一条将 "mustrespond" 列的结果限制为某个特定值的 SQL 查询，那么 DB2 将读取所有的 xml(标准化越来越近了) 文档，并搜索适当的 "ResponseRequested" 值。除非数据量不大，否则这样做会降低运行时性能。然而，如果在那些视图上运行的查询还包含有严格限制性的谓词，且参与索引的项中有传统的 SQL 类型的项（在这个例子中可以是 "i.id" 或 "i.itemname"），那么可以缓解潜在的运行时性能问题。DB2 使用关系索引将符合条件的行过滤到一个较小的量，然后在返回最终结果之前，将更多的 xml(标准化越来越近了) 查询谓词应用到这些临时的结果上。

连接 xml(标准化越来越近了) 数据和关系数据

现在，您可能想知道如何连接 xml(标准化越来越近了) 数据和非 xml(标准化越来越近了) 数据（例如基于传统 SQL 类型的关系数据）。DB2 使您可以仅用一条 SQL/xml(标准化越来越近了) 语句来做到这一点。有很多方法可用来制定那样的连接，这取决于数据库模式和工作负载需求，不过这里我们只谈论一个例子。您也许会感到惊讶，其实您已经知道足够多关于 SQL/xml(标准化越来越近了) 的东西，完全可以实现这种连接。

还记得吗，"items" 表中的 xml(标准化越来越近了) 列包含一个 "CustomerID" 元素。这可以作为与 "clients" 表中基于整数的列 "id" 的一个连接键。因此，如果要获得一个报告，其中列出对您的一件或多件产品发表了评论的客户的姓名和状态，那么需要将一个表中的 xml(标准化越来越近了) 元素值与来自另一个表中的 SQL 整数值相连接。实现这一点的一种方法是使用 xml(标准化越来越近了)Exists 函数，如 清单 14 所示：

 

select clients.name, clients.status from items, clients

where xml(标准化越来越近了)exists('$c/Comments/Comment[CustomerID=$p]'

passing items.comments as "c", clients.id as "p")

第一行标识出要包括在查询结果集中的 SQL 列以及查询中所引用的源表。第二行包括了连接子句。这里，xml(标准化越来越近了)Exists 决定在一个目标源中的 "CustomerID" 值是否等于来自另一个目标源的值。第三行指定这两个源：第一个目标源是 "items" 表中的 xml(标准化越来越近了) 列 "comments"，第二个目标源是 "clients" 表中的整数列 "id"。因此，如果客户对任何产品发表了评论，并且 "clients" 表中存在关于该客户的信息，那么 xml(标准化越来越近了)Exists 表达式将等于 "true"，报告中将包括该客户的姓名和状态。

使用 SQL/xml(标准化越来越近了) 中的 "FLWOR" 表达式

虽然我们只讨论了几个函数，其实 SQL/xml(标准化越来越近了) 为查询 xml(标准化越来越近了) 数据和将 xml(标准化越来越近了) 数据与关系数据集成提供了很多强大的功能。实际上，您已经看到了这方面的一些例子，但是这里我们还要再讨论一些例子。

通过 xml(标准化越来越近了)Exists 和 xml(标准化越来越近了)Query 函数都可以将 XQuery 嵌入到 SQL 中。前面的例子展示了如何使用这些函数和简单的 XPath 表达式访问 xml(标准化越来越近了) 文档中感兴趣的某个部分。现在我们考虑一个简单的例子，这个例子将 XQuery 包括在 SQL 查询中。

XQueries 可以包含 "for"、"let"、"where" "、"order by" 和 "return" 子句中的一些或者全部。这些子句一起形成了 FLWOR （发音为 flower）表达式。SQL 程序员会发现，将 XQueries 嵌入到 SELECT 列表中以便将 xml(标准化越来越近了) 文档的片段提取（或投影）到结果集是很方便的。虽然 xml(标准化越来越近了)Query 函数的用法不止于此，不过本文只讨论这种情况。（将来的文章将更深入地讨论 XQuery。）

假设您要检索 "Gold" 客户的姓名和首要 email 地址。在某些方面，这个任务类似于我们前面在探索如何投影 xml(标准化越来越近了) 元素值的时候完成过的一个任务（参见 清单 9）。而在这里，我们将 XQuery （带有 "for" 和 "return" 子句）作为 xml(标准化越来越近了)Query 函数的输入：

 

select name, xml(标准化越来越近了)query('for $e in $c/Client/email[1] return $e' 

passing contactinfo as "c") 

from clients

where status = 'Gold'

第一行指定结果集中将包括客户姓名和 xml(标准化越来越近了)Query 函数的输出。第二行表明将返回 "Client" 元素的第一个 "email" 子元素。第三行标识出 xml(标准化越来越近了) 数据的源 —— "contactinfo" 列。第四行说明这个列在 "clients" 表中，最后，第五行表明我们只对 "Gold" 客户感兴趣。

因为这个例子很简单，在这里您可以这样编写这个查询。不过，也可以用一种更紧凑的方式编写这个查询：

 

select name, xml(标准化越来越近了)query('$c/Client/email[1]' 

passing contactinfo as "c") 

from clients

where status = 'Gold'

不过，通过 XQuery 的 return 子句可以按照需要转换 xml(标准化越来越近了) 输出。例如，您可以提取 email 元素值并将它们发布为 HTML。下面的查询将产生一个结果集，其中每个 Gold 客户的第一个 email 地址以 HTML 段落的形式返回。

 

select xml(标准化越来越近了)query('for $e in $c/Client/email[1]/text() 

return <p>{$e}</p>' 

passing contactinfo as "c") 

from clients

where status = 'Gold'

第一行表明您只对符合条件的客户的第一个 email 地址的文本表示形式感兴趣。第二行指定该信息在返回之前需要用 HTML 段落标记括起来。具体来说，花括号（{ }）指示 DB2 计算被括起来的表达式（在这里是 "$e"）的值，而不是将其视作一个文字字符串。如果省略了花括号，对于每个符合条件的客户记录，DB2 将返回一个包含 "<p>$e</p>" 的结果。

将关系数据发布为 xml(标准化越来越近了)

到到目前为止，我们一直都在着重讨论查询、提取或转换存储在 DB2 xml(标准化越来越近了) 列中的数据的方法。而且您已经看到，这些功能都可以通过 SQL/xml(标准化越来越近了) 提供。

SQL/xml(标准化越来越近了) 还提供了其他非常方便的特性。其中一个特性是将关系数据转换或发布为 xml(标准化越来越近了)。本文只讨论这方面的三个 SQL/xml(标准化越来越近了) 函数：xml(标准化越来越近了)Element、xml(标准化越来越近了)Agg 和 xml(标准化越来越近了)Forest。

通过 xml(标准化越来越近了)Element 可以将存储在传统的 SQL 列中的数据转换成 xml(标准化越来越近了) 片段。也就是说，可以基于基本的 SQL 数据构造 xml(标准化越来越近了) 元素（带 xml(标准化越来越近了) 属性或者不带 xml(标准化越来越近了) 属性）。下面的例子嵌入了 xml(标准化越来越近了)Element 函数来创建一系列的 item 元素，每个 item 元素包含一些子元素，分别存放从 "items" 表获得的 ID、品牌和库存单位（"sku"）值：

 

select xml(标准化越来越近了)element (name "item", 

xml(标准化越来越近了)element (name "id", id), 

xml(标准化越来越近了)element (name "brand", brandname), 

xml(标准化越来越近了)element (name "sku", sku) ) from items 

where srp < 100

运行该查询将产生类似以下的结果：

 

<item>

<id>4272</id>

<brand>Classy</brand>

<sku>981140</sku>

</item>

. . . 

<item>

<id>1193</id>

<brand>Natural</brand>

<sku>557813</sku>

</item>

可以将 xml(标准化越来越近了)Element 与其他 SQL/xml(标准化越来越近了) 发布函数结合使用来构造 xml(标准化越来越近了) 值以及将这些值分组，使它们嵌套成一定的层次结构。清单 20 中的例子使用 xml(标准化越来越近了)Element 创建 customerList 元素，该元素的内容按照 "status" 列中的值分组。对于每个 "customerList" 记录，xml(标准化越来越近了)Agg 函数返回一系列的 customer 元素，每个 customer 元素包含基于 "name" 和 "status" 列的子元素。而且可以看到，customer 元素的值是按照客户姓名排序的。

 

select xml(标准化越来越近了)element(name "customerList",

xml(标准化越来越近了)agg (xml(标准化越来越近了)element (name "customer", 

xml(标准化越来越近了)forest (name as "fullName", status as "status") )

order by name ) )

from clients 

group by status 

假设 "clients" 表包含三个不同的 "status" 值："Gold"、"Silver" 和 "Standard"。运行上述查询将导致 DB2 返回三个 customerList 元素，每个 customerList 元素可能包含多个 customer 子元素，每个 customer 子元素又进一步包含姓名和状态信息。因此，输出将类似于以下内容：

 

<customerList>

<customer>

<fullName>Chris Bontempo</fullname>

<status>Gold</status>

</customer>

<customer>

<fullName>Ella Kimpton</fullName> 

<status>Gold</status>

</customer>

. . . 

</customerList>

<customerList>

<customer>

<fullName>Lisa Hansen</fullName>

<status>Silver</status>

</customer>

. . .

</customerList>

<customerList>

<customer>

<fullName>Rita Gomez</fullName>

<status>Standard</status>

</customer>

. . .

</customerList>

更新和删除操作

虽然本文的重点是使用 SQL 搜索和检索存储在 xml(标准化越来越近了) 列中的数据，不过这里仍然值得花一点时间考虑一下另外两项常见的任务：更新和删除 xml(标准化越来越近了) 列中的数据。

DB2 允许用户使用 SQL 和SQL/xml(标准化越来越近了) 语句更新和删除 xml(标准化越来越近了) 数据。实际上，由于 XQuery 标准的初稿没有解决这些问题，DB2 用户必须依赖 SQL 来完成这些任务。

更新 xml(标准化越来越近了) 数据

DB2 允许用 SQL UPDATE 语句或通过使用系统提供的存储过程（DB2xml(标准化越来越近了)FUNCTIONS.xml(标准化越来越近了)UPDATE）来更新 xml(标准化越来越近了) 列。不管使用哪种方式，对 xml(标准化越来越近了) 列的更新都发生在元素级。然而，使用存储过程更新 xml(标准化越来越近了) 数据的程序员不需要提供整个 xml(标准化越来越近了) 文档给 DB2；他们只需指定要更新的 xml(标准化越来越近了) 元素。发出 UPDATE 语句的程序员则需要指定整个文档（而不仅仅是要更改的元素）。

例如，如果要发出一条 UPDATE 语句来更改某个特定客户的联系方式信息中的 email 地址，就必须在 xml(标准化越来越近了) 列中提供全部联系方式信息，而不仅仅是新的 email 元素值。根据 图 2，提供的信息将包括 "Address" 信息、"phone" 信息、"fax" 信息和 "email" 信息。

考虑以下语句：

 

update clients set contactinfo=( 

xml(标准化越来越近了)parse(document '<email>newemail@someplace.com</email>' ) )

where id = 3227

回忆一下在 “DB2 Viper 快速入门” 中我们是如何插入 xml(标准化越来越近了) 数据的，这里的语句大部分仍然是类似的。与任何 SQL UPDATE 语句一样，这个例子首先标识出要更新的表和列。由于目标列包含 xml(标准化越来越近了) 数据，因此需要提供一个格式良好的 xml(标准化越来越近了) 文档作为新的目标值。虽然大多数生产环境在应用程序中使用主机变量或参数标记位来更新 xml(标准化越来越近了) 数据，但是在这里我展示了用一种简单的方式来交互式地完成该任务。第二行使用 xml(标准化越来越近了)Parse 函数将输入字符串转换成 xml(标准化越来越近了)。对于 beta 版的 Viper，需要显式地调用 xml(标准化越来越近了)Parse。当 Viper 变得普遍可用时，显式调用应该只是成为一种选择。最后一行是一个标准的 SQL 子句，规定只更新表中特定的一行。

如果执行上述 UPDATE 语句，则客户 3227 的 "contactinfo" 列将只包含 email 信息，如 清单 23 所示：

 

<email>newemail@someplace.com</email>

这位客户的地址、电话号码和传真号码（如 图 2 所示）将丢失。而且，之前编写的用于提取客户的 email 地址的那些查询也无法恢复这些信息。为什么？之前的那些查询包括 XPath 或 XQuery 表达式，这些表达式在一个特定的文档层次结构中导航，而在这个结构中 Client 是根元素，email 是一个子元素。在像上面这样更新该文档之后，email 将变成这个客户的 xml(标准化越来越近了) 记录的根元素；因此，在这个层次结构中再也不能在预期的位置上找到它的值。

如果要交互式地更新这个客户的 email 地址，并且保留所有其他已有的联系方式信息，应该像 清单 24 中那样重写查询：

 

update clients set contactinfo=

(xml(标准化越来越近了)parse(document 

'‘<Client>

<Address>

<street>5401 Julio Ave.</street>

<city>San Jose</city>

<state>CA</state>

<zip>95116</zip>

</Address>

<phone>

<work>4084633000</work>

<home>4081111111</home>

<cell>4082222222</cell>

</phone>

<fax>4087776666</fax>

<email>newemail@someplace.com</email>

</Client>' ) )

where id = 3227

也许您想知道是否可以通过一个视图进行更新，从而避免提供整个 xml(标准化越来越近了) 文档。例如，清单 13 中定义的 commentview 使用 xml(标准化越来越近了)Table 函数提取 xml(标准化越来越近了) 文档中的某些元素，并将这些元素转换成视图中的 SQL 列。那么，是否可以更新这些 SQL 列中某个列的值，并将结果写回到初始的 xml(标准化越来越近了) 文档的适当子元素中呢？答案是否定的。在 DB2 中，基于 SQL 类型的视图列与从一个函数（在这里是 xml(标准化越来越近了)Table 函数）得到的视图列是有区别的。对后者的更新不受支持。

删除 xml(标准化越来越近了) 数据

删除包含 xml(标准化越来越近了) 列的行很简单。SQL DELETE 语句允许通过 WHERE 子句识别（或限制）要删除的行。该子句可以包括简单的谓词来标识非 xml(标准化越来越近了) 列值或包括 SQL/xml(标准化越来越近了) 函数来标识包含在 xml(标准化越来越近了) 列中的 xml(标准化越来越近了) 元素值。

例如，下面展示了如何删除客户 ID 为 3227 的客户的所有信息：

 

delete from clients 

where id = 3227

还记得怎样限制 SQL SELECT 语句，使之仅返回居住在邮政编码为 95116 的地区的客户的行吗？如果还记得的话，很容易知道如何删除与那些客户相关的行。下面看看如何使用 xml(标准化越来越近了)Exists 来做这件事：

 

delete from clients

where xml(标准化越来越近了)exists('$c/Client/Address[zip="95116"]'

passing clients.contactinfo as "c");

建立索引

最后，值得注意的是，您可以创建专门的 xml(标准化越来越近了) 索引来加快对 xml(标准化越来越近了) 列中的数据的访问。由于本文是介绍性的文章，并且示例数据量比较少，所以本文不讨论这个话题。但是，在生产环境中，定义适当的索引对于取得最佳性能是非常重要的。本文的 参考资料 小节可以帮助您了解更多关于新的 DB2 索引技术的知识。

结束语

本文谈到了很多基础知识，提到了 SQL/xml(标准化越来越近了) 的几个关键方面，并展示了如何使用 SQL/xml(标准化越来越近了) 查询 xml(标准化越来越近了) 列中的数据。当然，除了这里讨论的用法外，用 SQL 和 SQL/xml(标准化越来越近了) 函数还可以做更多的事。本文给出了一个 简单的 Java 例子，这个例子解释了如何使用参数标记位和 SQL/xml(标准化越来越近了) 来查询 xml(标准化越来越近了) 列中的数据。在将来的文章中我们将更详细地讨论应用程序开发。但是，接下来的文章将探索 DB2 Viper 支持的一种新的查询语言，即 XQuery 的一些有趣的方面。