CN100440218C - Lob中存储的xml内容的有效提取 - Google Patents

Abstract

提供了一种用于提取存储在数据库管理系统中的XML文档中的节点的有效的、自含式片段的方法和系统。XML索引用于识别对应于节点的XML片段数据所处的位置。识别和检查节点的祖先节点，以获得片段的适当解释所需的任何信息。如果祖先节点包含这样的所需信息，则将该信息修补成XML片段以确保片段是有效的、自含式的XML片段。

Description

LOB中存储的XML内容的有效提取

技术领域

本发明涉及管理信息，并且更具体地，涉及从存储的XML数据中提取由XPath路径表达式识别的有效的、自含式XML片段。

背景技术

近年来，已经开发了能够存储和查询可扩展标记语言数据(“XML数据”)的数据库系统。虽然存在许多关于查询XML的正在演化的标准，但是它们均包括某些XPath变量。XPath是描述基于通过文档的逻辑结构或层级的路径通过使用寻址语法来定位和处理XML文档中的项的方法的语言。由XPath“路径表达式”识别的XML文档的部分，是存在于XML文档的结构中的与路径表达式匹配的任意路径的末端的部分。

由关系数据库服务器管理的XML文档通常以某一形式的LOB(大对象)数据类型存储为非结构化的序列化数据。例如，XML文档可以存储在诸如CLOB(字符LOB)或BLOB(二进制LOB)的非结构化存储器中，或者该文档可以存储为O-R(使用XML模式的对象关系结构)。

无论如何存储XML文档，为了实现多种XPath查询，需要一种识别和提取与XPath路径表达式相匹配的存储的XML文档的片段的方法。

遗憾的是，即使对存储XML数据具有内置支持的数据库系统，对于处理基于路径的查询通常也没有最优化，并且数据库系统的查询性能还有许多不足之处。在可以使用XML模式定义的特定情况下，可以使用在XML实例文档中所使用的结构和数据类型来使XPath查询最优化。然而，在XML模式定义不可用，并且待搜索的文档不符合任何模式的情况下，没有用于基于路径查询的有效技术。

当没有XML模式定义可用时，可以使用点对点机制(例如，所有文档的全扫描或基于文本关键字的索引)来增强查询文档的性能。然而，这些机制不能满足快速识别和提取存储的XML文档的片段的有效方法的需要，其中，存储的XML文档与XPath路径表达式相匹配。

即使快速识别存储的XML数据的片段位置的方法可用，仍然需要从识别的位置有效地提取片段的方法。存在于识别的位置的片段，可能不是有效的自含式XML文档。例如，可以在片段外声明在该片段内使用的命名空间前缀，因此从该识别的位置检索的片段将不会具有所有需要的声明。

基于上述内容，很显然需要一种用于识别和提取与XPath路径表达式匹配的有效的、自含式XML片段的系统和方法。

本部分描述的方法是可以推行的方法，但未必是先前已经构思或推行的方法。因此，除非另外指出，不应该仅仅因为本部分中描述的方法包含在该部分中而将其认为是现有技术。

附图说明

在附图中通过实例来示出本发明而不是为了限制本发明，在附图中相同的参考标号表示相同的元件，其中：

图1是可以实施此处所述技术的系统的框图；以及

图2是示出响应于请求有效地提供自含式XML片段的步骤的流程图。

具体实施方式

在以下描述中，为了说明的目的，叙述了大量具体细节以提供对本发明的全面理解。然而，很显然，没有这些具体细节也可以实施本发明。在其他实例中，以框图形式示出了众所周知的结构和装置，以避免不必要的使本发明不清楚。

XML文档实例

为了说明的目的，以下将参照如下两个XML文档给出实例：

po1.xml

<PurchaseOrder>

  <Reference>SBELL-2002100912333601PDT</Reference>

  <Actions>

    <Action>

      <User>SVOLLMAN</User>

    </Action>

  </Actions>

....

</PurehaseOrder>

po2.xml

<PurchaseOrder>

  <Reference>ABEL-20021127121040897PST</Reference>

  <Actions>

    <Action>

      <User>ZLOTKEY</User>

    </Action>

    <Action>

      <User>KING</User>

    </Action>

  </Actions>

....

</PurchaseOrder>

如上面指出的，po1.xml和po2.xml仅仅是XML文档的两个实例。在此所述的技术不限于具有任何特定类型、结构或内容的XML文档。下面将根据本发明各种实施例给出如何索引和存取这种文档的实例。

XML索引

于2004年7月2日提交的题为INDEX FOR ACCESSING XMLDATA的第10/884,311号美国专利申请(下文中称为“XML索引应用”)，描述了可以用于基于XPath查询有效地存取由关系数据库服务器管理的XML文档的索引的各种实施例。这样的索引在本文中将称为XML索引。

在XML索引应用中描述的XML索引可以用于处理XPath查询，而与用于存储实际的XML数据的格式和数据结构(“基本结构”)无关。例如，实际的XML数据可以以诸如CLOB(用于存储实际的XML文本的字符LOB)、O-R(XML模式下的对象关系结构形式)、或BLOB(用于存储某些二进制形式的XML数据的二进制LOB)的任意形式存在于数据库内部或外部的结构中。

根据一个实施例，XML索引是改善包括基于XPath的谓词和/或基于XPath的片段提取的查询的性能的域索引。例如，可以在存储为CLOB或结构化存储器的基于XML模式和无模式XMLType的列上建立XML索引。在一个实施例中，XML索引是通过共同使用路径索引、值索引、和次序索引而产生的逻辑索引。

路径索引提供了基于简单(导航)路径表达式来查找节点的机制。值索引提供了基于值相等或范围的查找。可能存在多个二级值索引-每种数据类型一个。次序索引使层级排序信息与索引的节点相关联。次序索引用于确定XML节点之间的父-子、祖先-子孙、以及兄弟关系。

当用户提交含有XPath(作为谓词或片段标识符)的查询时，XPath语句被分解成存取XML索引表的SQL查询。所生成的查询通常执行一组受路径、值、和次序约束的查找并将其结果适当地合并。

为了说明的目的，在上下文中描述了此处所描述的技术，在所述上下文中，如在XML索引应用中所描述的XML索引用于索引XML文档。然而，在此描述的技术不限于任何具体索引结构或机制，并且可以用于识别和提取有效的、自含式XML片段，而与使用何种查询方法无关。

路径表

根据一个实施例，逻辑XML索引包括PATH表和一组次级索引。如上所述，每个索引XML文档可以包括许多索引节点。对于每个索引节点，PATH表包含一行。对于每个索引节点，该节点的PATH表中的行包含与该节点相关的各段信息。

根据一个实施例，PATH表中包含的信息包括：(1)指示到节点的路径的PATHID；(2)用于对基本结构内的节点的片段数据进行定位的“位置数据”；以及(3)指示包含节点的XML文档的结构层级中该节点的位置的“层级数据”。可选地，PATH表还可以包含与值相关的那些节点的值信息。以下将更详细的描述每种类型的信息。

路径

XML文档结构在XML文档内的节点之间建立父-子关系。XML文档中节点的“路径”反映从“根”节点开始到特定节点的一系列父-子链路。例如，到po2.xml中的“User”节点的路径为/PurchaseOrder/Actions/Action/User，这是因为“User”节点是“Action”节点的子节点，“Action”节点是“Actions”节点的子节点，以及“Actions”节点是“PurchaseOrder”节点的子节点。

XML索引所索引的一组XML文档在此称为“索引XML文档”。根据一个实施例，可以在所有索引XML文档中的所有路径上或索引XML文档中的路径子集上建立XML索引。下文中描述了用于指定索引哪条路径的技术。由特定XML索引所索引的一组路径在此称为“索引XML路径”。

PATHID

根据一个实施例，为每条索引XML路径都分配唯一路径标识符(“PATHID”)。例如，可以为po1.xml和po2.xml中的路径分配如下表中所示的PATHID：

PATHID	PATH
		1	/PurchaseOrder
2	/PurchaseOrder/Reference
		3	/PurchaseOrder/Actions
4	/PurchaseOrder/Actions/Action
		5	/PurchaseOrder/Actions/Action/User

可以使用各种技术来识别路径并且为路径分配PATHID。例如，用户可以明确地列举路径，并且为这样识别的路径指定相应的PATHID。可选地，当文档添加至一组索引XML文档时，数据库服务器可以解析每个XML文档。在解析操作期间，数据库服务器识别还没有被分配PATHID的任何路径，并且自动地为这些路径分配新PATHID。可以以各种方法将PATHID到路径的映射存储在数据库中。根据一个实施例，将PATHID到路径的映射存储为与XML索引本身分离的元数据。

根据一个实施例，相同的存取结构用于符合不同模式的XML文档。因为索引XML文档可能符合不同模式，因此每个XML文档通常将仅包含分配了PATHID的路径的子集。

位置数据

与节点相关的位置数据表明：(1)包含该节点的XML文档在基本结构中位于何处；以及(2)对应于该节点的XML片段在存储的XML文档中位于何处。因此，位置数据的性质将基于基本结构的性质随着实施方式的不同而不同。当解析XML文档时，通常将位置信息添加到PATH表。

为了说明的目的，将假设：(1)基本结构是关系数据库内的表；以及(2)每个索引XML文档都存储在基本表的相应行中。在这样的情境中，节点的位置数据可以包括，例如，(1)基本表中的行的标识符(“RID”)，其中，基本表中存储有包含该节点的XML文档；以及(2)定位符，在存储的XML文档内提供到对应于节点的片断数据的快速存取。

定位符概念上是“指向”原始文档的一条信息，并且通常用于检索从那点开始的片段数据。定位符取决于用于XML文档的实际存储器，并且对于CLOB、O-R、或BLOB形式的存储器可能不同。例如，存储在CLOB中的XML文档中的节点的定位符可以是CLOB中的起始字符偏移量，其中，节点从该起始字符偏移量开始。此外，节点的字节长度可以被存储为定位符的部分。同时，该信息提供所存储的XML文档内的起始位置和结束位置，并且可以用于有效地提取XML片段。例如，定位符可以用于通过提取从由定位符指定的字符偏移量处开始的数据，并且读取由定位符指示的字节数的数据来检索包含与特定XPath查询相匹配的节点的XML片段。

然而，定位符可以比字符或字节偏移量更复杂。例如，定位符可以包括某些标记。作为另一实例，如果XML文档被分割成碎片存储到关系表中，则定位符可包括适当表和/或行标识符等。

层级数据

节点的PATH表行还包括表明节点位于包含该节点的XML文档的层级结构中何处的信息。本文中，将这种层级信息称为节点的“次序键(OrderKey)”。

根据一个实施例，使用Dewey型值来表示层级次序信息。具体地，在一个实施例中，通过对节点的直接父节点的次序键添加值来创建节点的次序键，其中，添加的值表示该父节点的子节点中该特定子节点的位置。

例如，假设特定节点D是节点C的子节点，其中，节点C本身是节点B的子节点，节点B又是节点A的子节点。进一步假设节点D具有次序键1.2.4.3。次序键中末尾的“3”表示节点D是其父节点C的第三个子节点。类似地，“4”表示节点C是节点B的第四个子节点。“2”表示节点B是节点A的第二个子节点。最前面的“1”表示节点A是根节点(即，没有父节点)。

如上所述，通过对父节点的次序键添加对应于子节点数目的值，可以容易地创建子节点的次序键。类似地，通过去除子节点的次序键中的末尾数字，可以容易地从子节点的次序键得出父节点的次序键。

根据一个实施例，由每个次序键所表示的合成数被转换成字节可比较值(byte-comparable value)，使得两个次序键之间的数学比较表示XML文档的结构层级中次序键对应的节点的相对位置。

例如，在XML文档的层级结构中，与次序键1.2.7.7相关的节点在与次序键1.3.1相关的节点之前。因此，数据库服务器使用将次序键1.2.7.7转换成第一值以及将次序键1.3.1转换成第二值的转换机制，其中，第一值小于第二值。通过将第二值与第一值进行比较，数据库服务器可以容易地确定与第一值相关的节点在与第二值相关的节点之前。可以使用多种转换技术来实现该结果，并且本发明不限于任何特定的转换技术。

值信息

索引文档中的一些节点可以是属性节点或对应于简单元素的节点。如在此所使用的，“简单元素”是没有任何属性元素或子元素并且其值是单文本字符串的元素。例如，在“po1.xml”中，“Refeence”元素是具有单文本值为“SBELL_2002100912333601PDT”的简单元素。

根据一个实施例，对于属性节点和简单元素，PATH表行还存储属性元素和简单元素的实际值。这种值可以存储在，例如，PATH表的“值列(value column)”中。在值列上建立将在下文中更详细描述的次级“值索引”。

PATH表实例

根据一个实施例，PATH表包括定义为下表中所列举的列：

列名称	数据类型	描述
			PATHID(路径ID)	RAW(8)	路径标志的ID。通过系统为每个不同的路径(例如，/a/b/c)分配唯一的ID。
RID	UROWD/ROWID	存储包含有该节点的XML文档的基本表中的行的标识符。
			ORDER_KEY(次序键)	RAW(100)	节点的Dewey次序键，例如3.21.5表示根节点的第3个子节点的第21个子节点的第5个子节点。
LOCATOR(定位符)	RAW(100)	对应于片段的起始位置的信息。在片段提

		取期间使用该信息。
			VALUE(值)	RAW(2000)/BLOB	在属性元素和简单元素情况下的节点的值。可以由用户指定类型(以及RAW列的大小)

如上所述，PATHID是分配给节点的标识符，并且唯一地表示到节点的完全扩展路径。ORDER KEY是与节点相关的DEWEY次序号的系统表示。根据一个实施例，次序键的内部表示还保存文档次序。

VALUE列存储简单元素(即，没有子元素)节点和属性节点的有效文本值。根据一个实施例，相邻的文本节点通过连接接合起来。如在XML索引应用中描述的，提供允许用户通过在索引创建期间指定选项来定制存储在VALUE列中的有效文本值的机制，例如，可以定制混合文本的行为、空格、区分大小写等。用户可以以包括有界RAW列或BLOB的许多种格式来存储VALUE列。如果用户选择了有界存储，则在索引创建期间的任何溢出都将被标记为错误。

下面的表是PATH表的实例，该PATH表(1)具有上述的列，以及(2)由po1.xml和po2.xml的项(entry)构成。具体地，PATH表的每一行都对应于po1.xml或po2.xml的索引节点。在该实例中，假设po1.xml和po2.xml分别存储在基本表的行R1和R2中。

构成的PATH表

行内部地址	路径ID	行标识(RID)	次序键	定位符	值
						1	1	R1	1	1,350
2	2	R1	1.1		SBELL-2002100912333601PDT
						3	3	R1	1.2	64,56
4	4	R1	1.2.1	73,37
						5	5	R1	1.2.1.1		SVOLLMAN
6	1	R2	1	1,400

7	2	R2	1.1		ABEL-20021127121040897PST
						8	3	R2	1.2	63,89
9	4	R2	1.2.1	72,36
						10	5	R2	1.2.1.1		ZLOTKEY
11	4	R2	1.2.2	109,33
						12	5	R2	1.2.2.1		KING

在该实例中，行内部地址列存储PATH表的每行的唯一标识符。根据其中创建有PATH表的数据库系统，行内部地址列可以是隐含列。例如，行的磁盘位置可用作行的唯一标识符。如下文将要更详细描述的，次级次序和值索引使用PATH表的行内部地址值，来定位PATH表中的行。

在上述实施例中，节点的PATHID、ORDER_KEY、和VALUE都包括在单个表中。在可选的实施例中，可使用独立的表将PATHID、ORDER_KEY、和VALUE信息映射到相应的位置数据(例如，基本表行标识(RID)和定位符(LOCATOR))。

在上述实施例中，PATH表的“RID”和“LOCATOR”列中的信息可以用于标识索引节点所存储的位置。在该实例中，基本表中的每行都对应于索引XML文档。基本表行中的每行都使用CLOB来存储相关的XML文档。PATH表中的RID列标识将XML文档存储为CLOB的基本表中的行，并且LOCATOR列将字符偏移量和节点的字符长度存储到索引节点开始的CLOB中。

例如，上述样本XML文档po1.xml和po2.xml在基本表的行R1和R2中以非结构化的序列化形式存储为CLOB数据结构。PATH表中行内部地址“1”标识的节点被定位在开始于存储在基本表行R1中的CLOB的字符1，并且具有350个字符的长度。作为另一实例，由行内部地址“9”标识的节点被定位在基本表的行R2中，并且开始于字符72，其长度为36个字符。PATH表的该行对应于po2.xml的第一<Action>节点，如下所示：

<Action>

<User>ZLOTKEY</User>

</Action>

在以上构成的PATH表中示出的实例示出了不为简单元素和属性节点存储定位符信息的实施例。在另一实施例中，可以为包括简单元素在内的所有节点存储和保持定位符信息。另外，在构成的PATH表中示出的实例示出了LOCATOR列存储偏移量和长度信息的实施例。在可选实施例中，可以仅存储偏移量信息。可选地，如上所述，可以在LOCATOR列中存储其它类型的定位符信息。在此所述的技术不依赖于任何特定类型的位置数据。

次级索引

PATH表包括定位XML文档和/或XML片段所需的信息，其满足大范围查询。然而，如果没有次级存取结构，使用PATH表来满足这种查询将会常常需要对PATH表进行全扫描。因此，根据一个实施例，由数据库服务器创建多个次级索引来加速查询，其中查询(1)执行路径查找和/或(2)识别基于次序的关系。根据一个实施例，在PATH表上创建下面的次级索引。

·PATHID_INDEX on(PATHID，RID)

·ORDERKEY_INDEX on(RID，ORDER_KEY)

·VALUE INDEXES

·PARENT_ORDERKEY_INDEX on(RID，

SYS_DEWEY_PARENT(ORDER_KEY))

PATHID_INDEX(PATHID_索引)

PATHID_INDEX建立在PATH表的PATHID、RID列上。因此，PATHID_INDEX中的项的形式为(键值，行内部地址)，其中，键值是表示特定PATHID/RID组合的合成值，并且行内部地址标识PATH表的特定行。

当(1)基本表行和(2)节点的PATHID已知时，PATHID_INDEX可用于在PATH表中快速定位该节点的行。例如，基于键值“3.R1”，可遍历PATHID_INDEX以找到与键值“3.R1”相关的项。假设PATH表如上所述构成，则索引项具有值为3的行内部地址。值为3的行内部地址指向PATH表的第三行，该行是与PATHID 3和RID R1相关的节点的行。

ORDERKEY_INDEX(次序键索引)

ORDERKEY_INDEX建立在PATH表的RID和ORDER_KEY列上。因此，ORDERKEY_INDEX中的项的形式为(键值，行内部地址)，其中，键值是表示特定RID/ORDER_KEY组合的合成值，并且行内部地址标识PATH表的特定行。

当(1)基本表行和(2)节点的ORDERKEY已知时，ORDERKEY_INDEX可用于在PATH表中快速定位该节点的行。例如，基于键值“R1.’1.2’”，可以遍历ORDERKEY_INDEX以找到与键值“R1.’1.2’”相关的项。假设PATH表如上所述构成，则索引项将具有值为3的行内部地址。值为3的行内部地址指向PATH表的第三行，该行是与ORDERKEY1.2和RID R1相关的节点的行。

值索引

正如可以使用PATHID_INDEX加快基于路径查找的查询，通过建立在PATH表的VALUE(值)列上的索引可以加快基于值查找的查询。然而，PATH表的VALUE列可以保持多种数据类型的值。因此，根据一个实施例，为存储在VALUE列中的每种数据类型建立单独的值索引。所以，在VALUE列保持字符串、数字、和时戳的实施方式中，还创建下面的值(次级)索引：

·STRING_INDEX on

SYS_XMLVALUE_TO_STRING(value)

·NUMBER_INDEX on

SYS_XMLVALUE_TO_NUMBER(value)

·TIMESTAMP_INDEX on

SYS_XMLVALUE_TO_TIMESTAMP(value)

这些值索引用于执行基于数据类型的比较(相等和范围)。例如，NUMBER值索引用于处理用户XPath中基于数字的比较。例如，NUMBER_INDEX中的项可以为(数字，行内部地址)的形式，其中，行内部地址指向PATH表中与“数字”的值相关的节点的行。类似地，STRING_INDEX中的项可以具有(字符串，行内部地址)的形式，并且TIMESTAMP_INDEX中的项可以具有(时戳，行内部地址)的形式。

PATH表中的值的格式可能与数据类型的原始格式不对应。因此，当使用值索引时，数据库服务器可以调用转换函数，以将值字节从存储的格式转换为指定的数据类型。另外，如下文中将要描述的，数据库服务器应用任何必要的变换。根据一个实施例，转换函数对RAW值和BLOB值进行运算，并且在不能转换时返回NULL。

缺省情况下，在创建XML索引时创建值索引。然而，用户可以基于对查询工作量的了解来取消一个或多个值索引的创建。例如，如果所有的XPath谓词仅包括字符串比较，则可以取消NUMBER和TIMESTAMP值索引。

PARENT_ORDERKEY_INDEX

根据一个实施例，建立在PATH表上的次级索引组包括PARENT_ORDERKEY_INDEX。与ORDER_KEY索引类似，PARENT_ORDERKEY_INDEX建立在PATH表的RID和ORDER_KEY列上。因此，PARENT_ORDERKEY_INDEX的索引项具有(键值，行内部地址)的形式，其中，键值是对应于特定的RID/ORDER_KEY组合的合成值。然而，不同于ORDER_KEY索引，PARENT_ORDERKEY_ INDEX项中的行内部地址不指向具有特定RID/ORDER_KEY组合的PATH表行。相反，每个PARENT_ORDERKEY_INDEX项的行内部地址都指向作为与RID/ORDER_KEY组合相关的直接父节点的节点的PATH表行。

例如，在上述构成的PATH表中，RID/ORDER_KEY组合“R1.’1.2’”对应于PATH表的第3行中的节点。PATH表的第3行中的节点的直接父节点是由PATH表的第1行所表示的节点。因此，与“R1.’1.2’”键值相关的PARENT_ORDERKEY_INDEX项将具有指向PATH表的第1行的行内部地址(即，行内部地址＝1)。

使用XML索引来处理XPATH查询

如上所述，XML索引通过捕获PATH、VALUE、和ORDER索引中XML文档的主要部分，即，标记、值、和嵌套信息，来提高基于XPath的查询和片断提取的性能。PATH索引用于索引标记，并且提供基于简单路径表达式来识别片段的机制。VALUE索引允许索引XML值。ORDER索引使层级排序信息与索引的节点相关，并用于确定XML节点之间的父-子、祖-孙、以及兄弟关系。

当用户提交包括XPath的查询时，可以将XPath表达式分解成存取XML索引表的SQL查询。所生成的查询通常执行一组受路径、值、和次序约束的查找，并将其结果适当地合并。

特别地，于2004年9月16日提交的标题为“EFFICIENT QUERYPROCESSING OF XML DATA USING XML INDEX”的第10/944,170号共同未决的美国专利申请(下文中称为“QueryProcessing”申请)，描述了使用XML索引来执行“索引-使能”查询以识别对应于特定路径的XML数据的方法的各种实施例。特别地，Query Processing申请描述了使用XML索引来评价XPath运算符的技术。

更具体地，Query Processing申请描述了用于以下方面的技术：(1)将一般路径表达式分解为诸如简单路径、谓词和结构结合点的更简单的要素；(2)生成对XML索引表的SQL查询，其可能涉及使用关于索引的路径要素的Dewey次序键的SQL谓词来表示的结构结合点；以及(3)使用指向原始数据的定位符进行的片段提取。

基于路径表达式生成索引-使能查询，并且该索引-使能查询存取XML索引的PATH表。基于路径查询的路径表达式或其片段与模板匹配。每个模板均与规则相关。当指定路径的片段为与模板匹配的格式时，使用相应的规则生成索引-使能查询的SQL。在QueryProcessing申请中详细描述了该过程。

使用XML索引来处理EXTRACT()运算符

可以使用在Query Processing申请中描述的技术来评价的一个XPath运算符是extract()运算符。XPath extract()运算符的结果是包含满足指定XPath表达式的XML文档的XML片段的XMLType。

如在Query Processing申请中描述的，可以将extract()运算符重写为对XML索引表的SQL查询。例如，可以将对/PurchaseOrder/Actions的XPath查询的extract()运算符译为如下的SQL查询：

select extract(value(p)，‘/PurchaseOrder/Actions’)

from po_tab p；

     →

select xmlagg(select SYS_XMLINDEX_MKXML(rid，order_key，locator，

value)

  from path_table

  where pathid＝:B 1 and rid＝p.rowid)

from po_tab p

其中，:B1＝pathid(‘/PurchaseOrder/Actions’)(pathid()是用于查找与所关注的路径相关的PATHID的内部函数)，po_tab是包含存储的XML文档的基本表。

SYS_XMLINDEX_MKXML()运算符基于索引列值建立XMLType图像。在一个实施例中，可以使用SYS_XMLINDEX_GETFRAG()运算符来执行该查找。指定行标识符和定位符，则SYS_XMLINDEX_GETFRAG()运算符构造由对应于行标识符和定位符的XML片段组成的XMLType图像。

XMLAGG()是连接由SYS_XMLINDEX_MKXML()运算符生成的片段的运算符。使用上面的实例，对于包含节点‘/PurchaseOrder/Actions’的每个行，从基本表检索片段，并且将其聚集到单个XMLType图像中。

例如，使用上述构成的PATH表，下面的输出：

select extract(value(T)，‘/PurchaseOrder/Reference’)

from xmltab T

将产生下面的结果：

<Reference>SBELL-2002100912333601PDT</Reference>

<Reference>ABEL-20021127121040897PST</Reference>

在一个实施例中，返回的输出是通过连接上述结果创建的包括开始标记和结束标记的单个长字符串。

本文描述的技术用于实施获得对应于节点的实际文本片段的SYS_XMLINDEX_GETFRAG()运算符。

有效提取过程

图2中所示的过程200示出了根据本发明实施例的一种用于提取XML片段的技术的步骤。如图所示，在步骤S210首先识别节点。例如在XML Index申请和Query Processing申请中描述的任何技术都可以用于识别与路径表达式匹配的节点。

接下来，在步骤S215检查节点，以确定该节点是简单元素还是复合元素。如上所述，简单元素是没有子或属性并且其值是单文本值的元素。复合元素是具有属性或子元素的元素。

如果节点是简单元素，则如步骤S220所示，可以使用存储在XML索引中的信息，在不查询原始XML文档的情况下构造片段。如果节点是复合元素，则如步骤S230所示，查询存储在基本表中的原始XML文档以提取片段，并且根据需要修补所提取的片段以适当解释。以下将更详细地描述每个过程。

虽然在图2中示出的过程的实施例利用存储在XML索引中的信息，以在不查询原始XML文档的情况下构造片段，但是不需要对简单元素和复合元素进行不同的处理。可以从存储的XML数据中提取与任何类型的元素(简单元素或复合元素)匹配的片段。

简单元素片段

当用XML索引来索引存储的XML文档时，在PATH表的VALUE列中显示简单元素的值。因此，可以在不查询存储了原始XML文档的基本表的情况下构造简单元素的XML片段。通过向从所识别节点的PATH表的VALUE列获得的值添加适当的开始标记和结束标记来建立片段。

例如，节点‘/PurchaseOrder/Reference’是上述XML文档po1.xml和po2.xml中的简单元素。首先确定表达式‘/PurchaseOrder/Reference’的PATHID。在该实例中，PATHID是“2”。检查PATH表以确定是否存在对应于该PATHID的节点(步骤210)。在该实例中，行内部地址为“2”和“7”的节点与PATHID＝2匹配。对每个匹配节点执行图2的过程。

在步骤215，对于节点2和节点7，通过检查这些行的LOCATOR列和VALUE列，可以确定每个节点都是简单元素，这是因为没有Locator(定位符)信息，并且VALUE列包含简单文本字符串。对于这些简单元素节点中的每个节点，过程继续到步骤220。在步骤220中，可以通过创建包含开始标记、值、和结束标记的字符串来建立该节点的片段。通过提取与该PATHID相关的路径的末尾部分来创建开始标记(在该实例中为“Reference”)。对应于PATH表中的该节点的VALUE放在开始标记之后的片段中。例如，节点2的片段的VALUE部分是“SBELL-2002100912333601PDT”。由结束符“/”和以上确定的部分字符串构成的结束标记完成了片段字符串。通过遵循该过程，节点2的片段确定为“<Reference>SBELL-2002100912333601PDT</Reference>”。这与对应于该节点的原始XML文档po1.xml的片段相匹配。

可以像简单元素那样处理仅提取属性的查询。然而，包含属性的元素将像复合元素一样被处理，这将在以下更详细描述。

由于系统可以添加命名空间和生成的前缀，因此无需为了适当解释来修补简单元素，并且对于简单元素，过程继续进行到步骤290。

使用XML索引提取复合元素

对于复合元素节点，必须从存储了与复合元素相关的XML文档的基本表解析片段。如上所述，PATH表中的每行都对应于XML文档中的节点，并且包括包含有原始XML文档的基本表中的行的RID和用于查找存储于基本表中的XML文档内的节点的定位符。

例如，关于节点/PurchaseOrder/Reference/Actions的XPathextract()将产生如下集合片段：

<Actions>

   <Action>

     <User>SVOLLMAN</User>

   </Action>

</Actions>

<Actions>

   <Action>

     <User>ZLOTKEY</User>

   </Action>

   <Action>

     <User>KING</User>

   </Action>

</Actions>

然而，与上述简单元素不同，这些片段是从存储的XML文档中提取的。例如，路径表达式“/PurchaseOrder/Reference/Actions”对应于PATHID 3。从该PATH表，行内部地址为3和8的节点与该PATHID匹配。这些行的VALUE列为空，并且LOCATOR列提供用于提取片段的偏移量和长度信息。因此在步骤215，确定了这些节点中的每个都对应于复合节点，并且过程继续进行到步骤230。

在步骤230，定位并读取对应于该节点的片段文本。例如，对于节点3，RID列表明存储的XML数据位于基本表的行R1，并且LOCATOR字段表明片段开始于字符64，并且长度为56。因此，可以通过从包含“po1.xml”的基本表的行R1中的CLOB提取字符64-120，来创建对应于节点3的片段文本。同样可以通过从包含“po2.xml”的基本表的行R2中的CLOB提取字符63-152，来创建对应于节点8的XML片段。

在这些实例中，所提取的XML片段恰好是有效的。然而，在许多情况下，使用这些方法提取的XML片段可能不是自含式的。例如，所提取的片段可能包含或使用片段中未定义的引用(reference)。在此所述的方法允许“修补”使用上述技术创建的片段，以确保产生的片段是有效和自含式的。

前缀和命名空间

由于XML中元素的名称是不固定的，因此当两个不同文档使用相当名称来描述两种不同元素时，会发生名称冲突。一种避免名称冲突的标准方法是对名称使用前缀。

例如，表1和表2示出了均使用“table”元素的XML文档。

1	<table>
		2	<tr>
3	<td>Apples</td>
		4	<td>Bananas</td>
5	</tr>
		6	</table>

表1

1	<table>
		2	<name>Coffee Table</name>
3	<width>80</width>
		4	<length>120</length>
5	</table>

表2

如果这两个XML文档均存储在数据库中，将潜在地存在元素名称冲突，这是因为两个文档都包含具有不同的内容和定义的<table>元素。一种解决和预防这些类型的冲突的标准方法是使用命名空间前缀。例如，下面的表1A和表2A示出了如何修改表1和表2的XML文档以避免元素名称冲突。

1	<h:table>
		2	<h:tr>
3	<h:td>Apples</h:td>
		4	<h:td>Bananas</h:td>
5	</h:tr>
		6	</h:table>

表1A

1	<f:table>
		2	<f:name>Coffee Table</f:name>
3	<f:width>80</f:width>
		4	<f:length>120</f:length>
5	</f:table>

表2A

如表1A和表2A所示，元素名称冲突不再是问题，这是因为这两个文档对它们的<table>元素使用不同的名称(即，<h:table>和<f:table>)。通过使用前缀，使得可以有两种不同类型的<table>元素。

前缀通常指的是承载关于元素的信息的XML文档。表1B和表2B示出了如何定义前缀来指特定命名空间。

1	<h:table xmlns:h＝”http://www.w3.org/TR/html4/”>
		2	<h:tr>
3	<h:td>Apples</h:td>
		4	<h:td>Bananas</h:td>
5	</h:tr>
		6	</h:table>

表1B

1	<f:tablexmlns:f＝”http://www.w3schools.com/furniture”>
		2	<f:name>Coffee Table</f:name>
3	<f:width>80</f:width>
		4	<f:length>1 20</f:length>
5	</f:table>

表2B

将xmlns属性添加至<table>标记，以将与命名空间相关的合格名称给予元素前缀，而不是仅使用前缀。通常，以如下语法将命名空间属性放置在元素的开始标记中：

xmlns:namespace-prefix＝“namespace”

如表1B和表2B所示，尽管可以使用任意统一资源标识符(URI)，但是命名空间本身可以使用互联网地址来定义。可以将多个命名空间前缀声明为单个元素的属性。

当将命名空间定义为元素的开始标记中的属性时，将所有带有相同前缀的子元素与相同的命名空间相关联。另外，如表1C和表2C所示，对于元素可以使用缺省命名空间。当使用缺省命名空间时，不必在所有子元素中使用前缀。缺省命名空间声明应用于在其范围之内的所有无前缀元素名称。

1	<table xmlns＝”http://www.w3.org/TR/html4/”>
		2	<tr>
3	<td>Apples</td>
		4	<td>Bananas</td>
5	</tr>
		6	</table>

表1C

1	<table xmlns＝”http://www.w3schools.com/furniture”>
		2	<name>Coffee Table</name>
3	<width>80</width>
		4	<length>120</length>
5	</table>

表2C

前缀提供了合格名称的命名空间前缀部分，并且必须与命名空间声明中的命名空间引用相关。前缀函数仅仅作为命名空间名称的占位符。使用命名空间名称而不是前缀来构造其范围扩展超出了所含文档的名称。前缀和命名空间声明可以应用于属性以及元素。

声明前缀的命名空间声明的范围从开始标记出现的起点扩展至对应于结束标记的终点，排除了使用相同前缀名称的任何内部声明的范围。这样的命名空间声明应用于其范围内的所有元素和属性名称，其前缀与声明中指定的前缀匹配。

命名空间前缀必须已经在命名空间声明属性中声明，其中，命名空间声明属性在使用前缀的元素的开始标记中或者在祖先元素中。在命名空间声明属性不是直接在XML文档中提供而是经由在外部实体中声明的缺省属性提供的情况下，这种限制可能会引起困难。

在片段提取的情境下，这尤其是有问题的。不仅仅外部文档中的声明是个问题，而且提取的XML片段可能使用在文档(从其提取了片段)的较早部分中声明的前缀。另外，可能提取这样的片段，即，当提取的该片段没有对任何命名空间的直接引用时，其表面上看是有效的；然而，如果所提取的片段在祖先元素的范围内，则所提取的片段将使用祖先的缺省命名空间声明。

本文描述的技术通过从期望节点和其所有祖先建立命名空间声明列表，解决了该问题。通过查询PATH表来建立该列表。该列表然后被接合成在步骤230创建的片段以获得完整的、有效的、自含式XML片段。

处理片段提取中的命名空间声明

如上所述，当相对于简单元素评价XPath extract()运算符时，可以仅使用PATH表来构造期望的片段。当提取了复合元素时，使用来自PATH表的位置信息从原始数据读取片段。然而，当在提取的XML片段中使用前缀时，所提取的片段还必须说明(account for)前缀。另外，必须考虑在将被提取的节点的祖先元素中使用的任何缺省命名空间声明。

例如，考虑表3中的实例XML文档“po3.xml”：

1	<po:purchaseOrder xmlns:po＝”po.xsd”xmlns:po2＝”po2.xsd”actionDate＝”04-04-04”>
			...
100	<po:LineItem>
		101	<myns:SomeOtherTag xmlns:myns＝”MyNs”xmlns:ns2＝”MyNs2”>
102	<myns:MoreTags>foo</myns:MoreTags>
		103	<po:quantity>1200</po:quantity>
104	</myns:SomeOtherTag>
		105	<po:USPrice>148.95</po:USPrice>
106	</po:LineItem>
		107	<po:LineItem>
	...
		150	</po:LineItem>
	...
		180	</po:PurchaseOrder>

表3

如果仅使用上述的过程来评价XPath查询“extract(/po:purchaseOrder/po:lineItem/myns:SomeOtherTag)”，则由查询返回的作为结果的片段将构成表3的行101-104。然而，该XML片段引用命名空间前缀“po”，其在根据定位符信息(即，行101-104)提取的片段中任何地方都没有定义。相反，该前缀被声明并被映射到表1的行1中的命名空间“po.xsd”。

需要将声明‘xmlns:po＝”po.xsd”’接合到在步骤230中创建的片段，以使片段被适当地解释，即，“自含式”。

在一个实施例中，可以在定位符本身中保持命名空间声明。然而，该信息随后可以存在于每一级中。在优选实施例中，使用存储在PATH表中的信息来建立声明信息。在该实施例中，使用SQL查询来识别提取的节点的所有祖先节点，并且从祖先节点收集命名空间声明。另外，本文中所述的技术能够正确地解析命名空间声明，即，以相反的次序用深声明覆盖浅声明，以遵守前述的XML命名空间辖区(scoping)规则。

如图2中的步骤240所示，识别了节点的祖先。如果使用了XML索引，由于使用OrderKey来存储祖先信息，因此这是简单查询。在步骤250，为每个识别的祖先检索XML片段的适当解释所需的信息。如果有从片段的适当解释所需的祖先检索的任何声明或其他信息的话，则该信息在步骤280被修补成片段。例如，从最近的祖先节点检索在片段中使用但是未定义的任何前缀的命名空间声明，并且修补成在步骤230形成的片段。

例如，以下的SQL查询可以用于仔细检查所有祖先节点以收集命名空间声明，并且正确地对其进行解析。(:B 1＝被考虑的文档的RID；:B2＝将被提取的节点的OrderKey)：

from path-table p1

where is_ns_attr(p 1.pathid)＝1

and p1.rid＝:B1

and exists(select 1

     from path-table p2

     where p2.rid＝:B1

     and p2.order_key＝DEWEY_PARENT(p 1.order_key)

     and p2.order_key<＝:B2 and maxchild(p2.order_key)>:B2)

order by orderkey desc；

正如所示出的，外部子查询在给定文档中选择所有命名空间声明。对于每个这种声明，exists()子查询确定祖先元素中是否存在该声明。

为了正确的解释辖区规则，应当忽略同样存在于子孙中的存在于祖先元素中的声明，这是因为子孙声明覆盖父声明。另外，存在于父元素中的声明覆盖祖父声明，等等。通过以适当次序考虑每个祖先并且说明辖区规则，在步骤250中创建需要被添加至片段的声明列表。为了解释辖区规则，从最近到最远的来考虑祖先节点。当在祖先中找到每个声明时，如果其已经被考虑过了，则无论作为片段本身的部分，还是在较早的祖先节点中，其都将被忽略。否则，其被添加至将被修补成片段的字符串。

例如，考虑用于表3中的节点的如下XPath查询：

extract(‘/po:purchaseOrder/po:lineItem/myns:SomeOtherTag’)

在步骤230中从表3提取的片段为：

<myns:SomeOtherTag xmlns:myns＝”MyNs”xmlns:ns2＝”MyNs2”>

  <myns:MoreTags>foo</myns:MoreTags>

  <po:quantity>1200</po:quantity>

</myns:SomeOtherTag>

在该片段中没有定义前缀“po”。

当在步骤250中考虑该片段的祖先时，创建如下的定义列表：

xmlns:po2＝“po2.xsd”xmlns:po＝“po.xsd”

在步骤280在定义列表中连接成片段之后，得到的片段是：

<myns:SomeOtherTag xmlns:myns＝”MyNs”xmlns:ns2＝”MyNs2”

xmlns:po2＝“po2.xsd”xmlns:po＝“po.xsd”>

    <myns:MoreTags>foo</myns:MoreTags>

    <po:quantity>1200</po:quantity>

</myns:SomeOtherTag>

虽然无需声明xmlns:ps2＝“po2.xsd”以使该实例片段为自含式片段，但包含该声明并不会使片段无效或改变片段的含义。在可选实施例中，检查声明以确定在声明被修补成片段之前，被提取的节点是否需要该声明。

在步骤280创建的包含适当解释所需的所有信息的自含式片段在步骤290被返回。

虽然已经在命名空间声明和前缀的情境中描述了本文所述的技术，但是在其他环境下也可以使用该技术。例如，实体或宏引用的存在类似地使片段的自含式特征变得复杂。像命名空间一样，当任何实体引用需要预先考虑DTD(数据类型定义)声明时，不能简单地将由CLOB偏移量识别的片段导出。

硬件综述

图1是示出可以实施本发明的实施例的计算机系统100的框图。计算机系统100包括用于传递信息的总线102或其它通信装置以及用于处理信息的与总线102连接的处理器104。计算机系统100还包括诸如随机存取存储器(RAM)或者其它动态存储装置的主存储器106，其连接至总线102，用于储存信息和将由处理器104执行的指令。在执行将由处理器104执行的指令期间，主存储器106还可用于储存临时变量或其他中间信息。计算机系统100还包括只读存储器(ROM)108或连接至总线102的其他静态存储装置，用于存储静态信息和用于处理器104的指令。提供诸如磁盘或光盘的存储设备110，并连接至总线102，用于存储信息和指令。

计算机系统100可以经由总线102连接至诸如阴极射线管(CRT)的显示器112，用于向计算机用户显示信息。包括字母数字键和其他键的输入装置114连接至总线102，用于将信息和命令选择传递到处理器104。另一种类型的用户输入装置是光标控制器116，诸如鼠标、跟踪球、或光标方向键，用于将方向信息和命令选择传递到处理器104并用于控制显示器112上的光标移动。输入装置通常在两个轴(第一轴(例如X轴)和第二轴(例如Y轴))上具有两个自由度，使装置能指定平面上的位置。

本发明涉及用于执行本文中描述的技术的计算机系统100的使用。根据本发明的一个实施例，通过计算机系统100响应于执行包括在主存储器106中的一个或多个指令的一个或多个序列的处理器104，来实现这些技术。这样的指令可以从诸如存储装置110的其它机器可读介质读入主存储器106中。包括在主存储器106中的指令序列的执行，使得处理器104执行此处所述的处理步骤。在可选实施例中，可以使用硬连线电路(hard-wired circuitry)来取代软件指令或者与软件指令结合来实施该发明。因此，本发明的实施例将不限于硬件电路和软件的任何特定结合。

这里使用的术语“机器可读介质”是指参与提供数据以使机器以特定方式运转的任何介质。在使用计算机系统100执行的实施例中，例如，包括提供指令给处理器104来执行的各种机器可读介质。这种介质可以采取多种形式，包括但不限于非易失性介质、易失性介质、和传输介质。非易失性介质包括，例如，诸如存储装置110的光盘或磁盘。易失性介质包括诸如主存储器106的动态存储器。传输介质包括同轴电缆、铜线、和光纤，包括构成总线102的导线。传输介质还可采取声波或光波形式，例如那些在无线电波和红外线数据通信过程中产生的声波和光波。

通常形式的机器可读介质包括如软盘、软磁盘、硬盘、磁带，或者任何其他磁性介质、CD-ROM、任何其他光介质、穿孔卡、纸带、或者任何其他带孔图样的物理介质、RAM、PROM、和EPROM、FLASH-EPROM、任何其他存储芯片或者盒式磁带、下文中提到的载波、或者计算机可读的任何其他介质。

各种形式的机器可读介质可参与将一个或者多个指令的一个或多个序列传送到处理器104用于执行。例如，指令最初可承载在远程计算机的磁盘中。远程计算机可以将指令存入其动态存储器中，并且使用调制解调器通过电话线发送指令。计算机系统100本地的调制解调器可接收电话线上的数据，并使用红外发射器将数据转换成红外信号。红外探测器可以接收红外信号携带的数据，并且合适的电路可以将数据放到总线102上。总线102将数据传送到主存储器106，处理器104从主存储器106提取并执行这些指令。在由处理器104执行这些指令之前或之后，由主存储器106接收的指令可随意地储存在存储装置110上。

计算机系统100还包括连接至总线102的通信接口118。连接到与本地网122连接的网络链路120的通信接口118提供双向数据通信。例如，通信接口118可以是综合业务数字网(ISDN)卡或者调制解调器，用于提供到相应类型的电话线的数据通信连接。又如，通信接口118可以是局域网(LAN)卡，用于提供至兼容局域网(LAN)的数据通信连接。也可以使用无线链路。在任何这样的实施中，通信接口118发送和接收传送表示各种类型的信息的数字数据流的电信号、电磁信号、和光信号。

网络链路120通常通过一个或者多个网络向其它数据装置提供数据通信。例如，网络链路120可通过本地网122提供到主机124的连接，或者到互联网服务提供商(ISP)126操作的数据设备的连接。ISP 126又通过目前通称为“互联网”128的全球分组数据通信网络提供数据通信服务。本地网122和互联网128都使用传送数字数据流的电信号、电磁信号、或光信号。通过各种网络的信号和网络链路120上的信号以及通过通信接口118的信号，都传送数字数据给计算机系统100或者传送来自计算机系统100的数字数据，是传输信息的载波的典型形式。

计算机系统100能通过网络、网络链路120、和通信接口118发送消息和接收数据(包括程序代码)。在互联网的实例中，服务器130可通过互联网128、ISP 126、本地网122、和通信接口118，传输应用程序请求的代码。

所接收的代码可以在其被接收时由处理器104执行，和/或储存在存储装置110或者其它非易失性存储器中用于随后执行。按照这种方式，计算机系统100可以获得载波形式的应用程序代码。

在上述的说明书中，参照许多因不同实施而不同的具体细节描述了本发明的实施例。因此，本发明以及申请人所期望的本发明的唯一和专有的标志，是以公布的权利要求的特定形式从该申请所公布的一组权利要求，包括任何后续的修改。对于包含在这样的权利要求中的术语，在此清楚阐述的任何定义都将限定权利要求中所使用的这种术语的含意。因此，在权利要求中没有明确地提到的限定特征、元件、特性、特征、优点或属性不应当以任何方式限制这种权利要求的范围。因此，说明书和附图应当看作说明性的而不是限制性的。

Claims (12)

1.一种用于为由数据库管理系统管理的XML文档中的节点提供自含式XML片段的方法，所述方法包括以下计算机执行的步骤：

接收对XML片段的请求，其中，所述请求包括XML路径表达式；

在由所述数据库管理系统管理的XML文档中识别与所述XML路径表达式匹配的节点；

构造对应于所识别的节点的XML片段，其中，所述XML片段不是自含式的；

识别包括所述XML片段的适当解释所需的信息的所述节点的一个或多个祖先节点，其中，所述所需信息包括在所述XML片段内使用但是未定义的引用的定义；

通过将所述所需信息插入到所述XML片段中来修补所述XML片段，以构造自含式片段；以及

响应于所述请求，提供所述自含式XML片段。

2.根据权利要求1所述的方法，其中，所述数据库管理系统包括用于索引存储在所述数据库管理系统中的所述XML文档的索引，其中，所述识别XML文档中的节点的步骤包括使用所述索引来识别所述节点。

3.根据权利要求2所述的方法，其中，所述索引包括路径索引、值索引、和次序索引。

4.根据权利要求1所述的方法，进一步包括提取XML片段的步骤，该步骤包括：确定对应于所识别的节点的所存储的XML数据的位置；以及从所确定的位置读取XML数据。

5.根据权利要求4所述的方法，其中，所述确定对应于所识别的节点的所存储的XML数据的位置的步骤，包括从用于索引存储在所述数据库管理系统中的所述XML文档的索引读取位置信息。

6.根据权利要求2所述的方法，其中，所述构造XML片段的步骤包括：

使用所述索引中的信息构造XML片段。

7.根据权利要求3所述的方法，其中，所述识别一个或多个祖先节点的步骤包括使用所述次序索引。

8.根据权利要求1所述的方法，其中，所述XML片段的适当解释所需的所述信息是命名空间声明。

9.根据权利要求8所述的方法，其中，所述识别包括适当解释所需信息的一个或多个祖先节点的步骤包括识别包含所述命名空间声明的祖先节点。

10.根据权利要求1所述的方法，其中，所述识别包括适当解释所需的信息的一个或多个祖先节点的步骤包括以从最近祖先节点到根祖先节点的次序检查每个祖先节点。

11.根据权利要求10所述的方法，其中，所述XML片段的适当解释所需的所述信息是命名空间声明，并且如果祖先节点中的命名空间声明与已经考虑的祖先节点中的命名空间声明匹配，则确定所述命名空间声明不是适当解释所需的。

12.一种方法，包括以下计算机执行的步骤：

接收对XML片段的请求，其中，所述请求包括XML路径表达式；

在数据库管理系统中，使用索引来识别与所述XML路径表达式匹配的节点；

其中，所述节点存在于由所述数据库管理系统管理的XML文档中；

其中，所述XML文档存储在由所述数据库管理系统管理的一个或多个基本结构中；

确定所述节点是否为简单元素，其中，简单元素是没有属性或子节点且其值为单文本字符串的元素；以及

如果所述节点为简单元素，则执行以下步骤：

基于包含在所述索引中的信息，构造所述节点的所述XML片段，而无需存取所述一个或多个基本结构；以及

响应于所述请求，提供所述XML片段。

Images