CN102043852B

CN102043852B - 一种基于路径信息的可扩展标记语言祖先后代索引方法

Info

Publication number: CN102043852B
Application number: CN2010106009798A
Authority: CN
Inventors: 张恩德; 赵相国; 刘辉林; 孙永佼
Original assignee: Northeastern University China
Current assignee: Northeastern University China
Priority date: 2010-12-22
Filing date: 2010-12-22
Publication date: 2012-07-18
Anticipated expiration: 2030-12-22
Also published as: CN102043852A

Abstract

一种基于路径信息的可扩展标记语言祖先后代索引方法，包括以下步骤：步骤一：解析XML文档；步骤二：建立B+树索引；步骤三：使用B+树索引进行祖先后代关系查询。本发明是一个实用的索引，基于计算机数据库领域内的B+树结构，该结构保证了在绝大多数情况下，采用索引都会比不采用索引查询效率有很大的提高，该索引无论对于基于关系数据库的XML数据库管理系统还是基于Native存储的XML数据库管理系统，都易于实现；该结构实现简单，只需要进行一次节点扫描，对于文档的数据是否有数据倾斜状况，都有很好的性能；还可以很好的处理A₁//A₂//…//A_n这类复杂的路径查询，避免了把长路径分成若干个祖先后代对的做法，有效的实现了对索引节点一次扫描即可得到查询结果。

Description

一种基于路径信息的可扩展标记语言祖先后代索引方法

技术领域

本发明属于计算机数据库技术领域，特别涉及一种XML(可扩展标记语言，ExtensibleMarkup Language)数据索引方法，具体涉及一种基于路径信息来实现XML祖先后代结构关系的数据索引方法。

背景技术

随着网络数据的海量增长，网络数据的格式越来越多样，由于XML具有良好的可扩展性以及自描述性，因此在当前Internet上，XML已经成为事实上的数据表示和数据交换标准。在具体应用中，越来越多的应用系统采用XML标准格式来发表和交换数据。对于XML查询，现在已经有了标准的XML查询语言XPath和XQuery，为了加速XPath和XQuery查询，需要对XML数据建立索引。

XML文档是一个树形结构的文档，在XPath和XQuery查询中，一个比较困难的问题就是解决XML文档中祖先后代关系的结构查询。如下面的查询表达式：

book//editor

直观的办法是对于book标签节点和editor标签节点分别建立对应的一个链表，然后对这两个链表中的元素进行嵌套循环一一匹配，这样的算法的复杂度为O(N²)。

一个更为精巧和典型的解决办法是采用Shurug Al-Khalifa等人提出的Structural Joins(结构连接)办法来完成。结构连接算法对每一个XML元素进行编码，其编码形式为(DocId，StartPos，EndPos，LevelNum)。对于两个元素节点Element1：(DocId 1，StartPos 1，EndPos 1，LevelNum 1)和Element2：(DocId 2，StartPos 2，EndPos2，LevelNum2)。Element1和Element1满足祖先后代关系当且仅当：DocId1＝DocId2，StartPos1＜StartPos2，EndPos1＞EndPos2。在结果连接算法中，基本想法是对两个标签节点链表按照(DocId，Startpos)进行排序，算法采用一个栈数据结构保留中间结果。

之后又相继提出很多算法来解决祖先后代结构连接问题，不过后来算法的核心思想都是在Shurug Al-Khalifa等人提出一个栈加上XML元素标签链表的基础上加以改进。

上面的各种算法在进行祖先后代关系查询的时候，都需要为祖先标签节点和后代标签节点建立一个链表，并且通常需要遍历这两个链表。另外，对于更加复杂的查询诸如A₁//A₂//A₃…An之类，结构连接算法通常是把它们分成A1//A2，A2//A3这样的祖先后代对，然后对这些运算结果进一步进行连接操作，效率比较低。

发明内容

本发明也是为了解决XML查询语言XPath和XQuery中祖先后代关系查询而提出，不同于那些传统算法，本发明基于XML解析中产生的路径信息来进行祖先后代关系查询。

本发明采用的技术方案是：设计并实现了一个新的XML结构信息索引XStrctIdx。算法对解析过的XML文档每个节点存储为(Key，Value)形式，其中Key为XML文档的节点标签，Value包含了当前XML文档节点的从父节点到根节点的路径。对于这些XML文档节点，在Key上面建立B+树索引，在查询过程中，对于指定的标签，只需要判断其对应的Value中是否含有满足条件的祖先节点即可。该索引主体采用B+树数据结构，既可以很容易的嵌入到关系型数据库中，又可以在Native类型的XML数据库中使用。

本发明所需要存储的具体节点信息如图2所示，具体步骤如下：

步骤1解析XML文档

本发明首先需要对XML文档进行解析，得到文档节点的具体信息。对于XML文档解析有两种方法，DOM解析与SAX解析。DOM是对XML文档在内存中建立树结构，这对系统的资源消耗很大，一般说来，所建立的树结构占用的内存大小可能是文档本身的几倍到数十倍。对于大型文档可能根本没法应用DOM解析。因此我们采用SAX解析。

在SAX解析过程中，我们使用一个栈结构。在SAX解析中，会产生以下类型事件：

①文档开始；②遇到元素节点开始标签；③遇到元素节点结束标签；④文档结束。

每当遇到元素节点开始标签，即判断是否对该标签进行字典映射，也就是说把标签的字符流转化成对应的数字ID。如果需要进行映射变换，即把该标签转化为数字ID，并存储到系统的数据字典中，然后把该数字ID入栈；如果不需要进行映射变换，直接把该数字入栈，并且对该节点形成(Key，Value)对。其中Key即为该元素节点对应的数字ID，Value是一个结构体，Value结构体包括当前节点从其父节点到根节点的路径信息，以及指向该节点具体存储位置的指针。

每当遇到元素节点的结束标签，即判断该标签与栈顶元素是否是同一元素节点，如果相同，则把栈顶元素弹出，否则不做操作。

由于XML文档的嵌套性质，即只有<Element1><Element2>……</Element2></Element1>这种形式的文档，没有<Element1><Element2>……</Element1></Element2>形式的文档，因此，在我们使用SAX文档时，当解析某一个元素节点的时候，在从栈顶到栈底的元素，正好对应了该元素从父节点到根节点元素。(因为在遇到开始标签的时候压栈，在遇到结束标签的时候弹栈，故有此特性)。

在文档结束的时候，文档所有的元素节点解析完毕，每个元素节点都形成了我们需要的(Key，Value)对。

步骤2建立B+树索引

对于步骤1解析出来的每个(Key，Value)对，其实就对应了XML文档中的每个元素节点，，需要把这些元素节点用B+树索引起来。

如果该算法应用于关系数据库环境，那么我们可以把我们的(Key，Value)对变成关系数据库系统中的表结构。该表有三个字段，其模式为(CurrentNode，Path，XPointer)，CurrentNode字段对应于我们(Key，Value)中的Key，PathInfo和XPointer组合对应于我们(Key，Value)对中的Value结构体，其中PathInfo为该节点的父亲节点到根节点的路径信息，XPointer为一个指针，指向该节点所存储的具体物理地址。B+树索引的Key即建立在(Key，Value)对中Key字段上。

如果该算法应用于Native XML数据库环境，我们的每个(Key，Value)对在存储的时候要采用B+树来进行索引，其中Key对应于B+树中的索引键值，所对应的值即Value结构体，Value结构体包括每个元素节点的从父亲节点到根节点的路径信息以及指向该节点所存储的具体物理地址信息。

无论是使用关系型数据库来管理XML数据，还是采用Native系统来管理XML数据，我们的索引都可以应用，并且整体都为B+树作为索引。

需要注意的是，虽然我们把步骤1和步骤2分开来写，但是在实际实现中，每解析一个元素节点，相应的就把这个节点按照通用B+树算法插入到B+树当中，在文档解析完成，一个完整的B+树索引也就建立完毕。按照B+树通用算法，我们的(Key，Value)对是聚簇存储的，也就是说相同的Key，他们的物理存储结构是存储在同一个磁盘块或者相邻的磁盘块上面。

步骤1和步骤2介绍了结构索引生成算法，所对应的算法具体描述如下：

步骤3使用索引进行祖先后代关系查询

本发明不止可以处理类似于A//D这类祖先后代关系查询，也可以处理A₁//A₂//…A_n-1//A_n这类复杂的路径查询。

对于A//D这类祖先后代关系查询，在使用我们的索引的时候，先通过B+树找到所有标签名称是D的节点，然后对于每个节点，依次检索该节点的Value结构，看看Value结构中的路径信息是否包含A标签，因为在我们进行解析和存储的时候，路径信息包含了某节点从父节点到根节点所有节点标签，如果该路径信息包含了A标签，则说明这个D节点满足查询条件，通过Value结构体中的指针找到该D节点具体的物理存储地址，找到查询结果。

对于A₁//A₂//…//A_n这类复杂的路径查询，在使用我们的索引的时候，先通过步骤2中的B+树找到所有标签名称是An的节点，然后对于这些节点，依次检索该节点的Value结构，对于Value结构中的路径信息，与我们路径查询中的A₁//A₂//…//A_n-1进行匹配。这里的匹配即判断A₁//A₂//…//A_n-1是否是Value结构中的路径的有序子集。因为我们的Value结构中的路径信息是有序存储的，另外对于绝大多数XML文档来说，文档的层次都不会很深，另外查询语句中的路径信息也不会太长，因此这样的匹配是很容易完成的。

本发明的收益是：

对于XML祖先后代进行结构查询，目前所采用的方法都是对每个涉及到的同名元素节点建立一个有序的标签链表，即标签流，然后基于祖先后代标签流，对它们同时进行扫描，完成结构连接。这样的做法的问题是，首先，如果为每个同名元素节点都建立一个标签流，那么在XML文档中的同名节点可能很多，建立标签流的代价太大；如果不是为每个同名节点都建立标签流，那么很可能查询的时候因为没有该标签流而无法使用结构连接算法；其次，在进行结构连接的时候，需要对祖先后代节点标签流同时扫描一次，虽然有一些算法在标签流上建立了B+树索引，但是理论和实验都表明，除了结构特殊的文档，对于大部分XML文档，查询效率提高有限，基于这种标签流上的B+树通常只能处理数据倾斜严重的文档；最后，对于长路径的查询，如A₁//A₂//…//A_n这类复杂的路径查询，目前对此并没有太好的解决办法，通常的做法是把这个路径分解为A₁//A₂，A₂//A₃，…，A_n-1//A_n这样的祖先后代对，然后再进行连接，这样的查询代价是十分大的。

本发明是一个实用的索引，首先本发明的索引基于计算机数据库领域内技术已经十分成熟的B+树结构，这个结构保证了在绝大多数情况下，采用索引都会比不采用索引查询效率有很大的提高，另外，该索引无论对于基于关系数据库的XML数据库管理系统还是基于Native存储的XML数据库管理系统，都易于实现；其次，该结构实现简单，只需要进行一次节点扫描，无论对于文档的数据是否有数据倾斜状况，都有很好的性能；最后，该索引可以很好的处理A₁//A₂//…//A_n这类复杂的路径查询，对于这种复杂查询，目前并没有太好的解决办法，该索引避免了把长路径分成若干个祖先后代对的做法，有效的实现了对索引节点一次扫描即可得到查询结果。

附图说明

图1为本发明实施例XML结构索引生成流程；

图2本发明实施例XML文档对应的文档树形结构；

图3本发明实施例文档节点存储数据字典；

图4本发明实施例XStrctIdx索引逻辑结构图。

具体实施方式

结合附图对本发明做进一步描述：

以下给出了一个XML文档示例，文档来自于http://www.w3.org/TR/xquery-use-cases/，该

网站为World Wide Web Consortium(W3C)官方网站，XML标准即为W3C制定。

1 <bib>

2 <book year＝″1994″>

3 <title>TCP/IP Illustrated</title>

4 <author><last>Stevens</last><first>W.</first></author>

5 <publisher>Addison-Wesley</publisher>

6 <price>65.95</price>

7 </book>

8 <book year＝″1992″>

9 <title>Advanced Programming in the Unix environment</title>

10 <author><last>Stevens</last><first>W.</first></author>

11 <publisher>Addison-Wesley</publisher>

12 <price>65.95</price>

13 </book>

14 <book year＝″2000″>

15 <title>Data on the Web</title>

16 <author><last>Abiteboul</last><first>Serge</first></author>

17 <author><last>Buneman</last><first>Peter</first></author>

18 <publisher>Morgan Kaufmann Publishers</publisher>

19 <price>39.95</price>

20 </book>

21 <book year＝″1999″>

22 <title>The Economies of Technology for Digital TV</title>

23 <editor>

24 <last>Gerbarg</last><first>Darcy</first>

25 <affiliation>CITI</affiliation>

26 </editor>

27 <publisher>Kluwer Academic Publishers</publisher>

28 <price>129.95</price>

29 </book>

30 <magazine month＝″2010-09″>

31 <name>TIME</name>

32 <editor>

33 <name>somebody</name>

34 </editor>

35 <publisher>Time Magazine Publishers</publisher>

36 <price>10.00</price>

37 </magazine>

38 </bib>

前述XML文档描述了一个图书馆图书信息文档片段。为了说明问题，对于网站上的原文档稍微有些改动。XML通过标签(tagname)组织数据结构，在标签之间可以包括字符数据或者下一层次的标签，在XML文档中，以<></>标记的分别为开始标签、结束标签，标签必须成对出现。XML中有元素、属性、文本等几种基本的数据类型。每个XML文档只有唯一的根元素，任何元素都是根元素的后代，出现在根元素内部。在该文档中的第一列的序号为了说明问题方便，并不是真正的XML文档内容。

在这个文档中，标签为bib的元素即为根元素。bib元素有四个book子元素，一个magazine子元素。每个book元素中的year为属性节点。图中每个<title></title>里面的内容为文本节点。

图1给出了XML结构索引生成流程，这个流程和前面的算法1是对应的。

图2为上面XML文档所对应的文档树结构，任何一个规范的XML文档都可以转换为一棵XML文档树，在文档树中的节点对应了图2中的XML文档中对应的元素，在一个标准的XQuery和Xpath查询中，/和//分别对应于树中的父子关系和祖先后代关系，例如图中book节点和editor节点满足父子关系(也同时满足祖先后代关系)，bib节点和editor节点满足祖先后代关系。

图3为系统所用的存储数据字典，有了这个数据字典之后，在存储的时候不需要对字符串存储，减少存储空间，查询的时候不需要对字符串匹配，而只是对数字进行匹配，提高了查询效率。

图4对应于上面给出XML的索引逻辑结构图。图中右侧是XML文档的文档结构图，一般情况下，不同的系统存储结构不同，但是一般的XML数据库管理系统都会以XML节点为单位进行存储，否则也就失去作为XML数据库管理系统的意义(如果以XML文档为单位进行存储，那就和文件管理方式类似，不能直接进行节点查询)。所以我们的索引中的每一项会有一个指针，指向XML文档中的对应的节点。另外，在真正进行物理存储的时候，无论是查询的键值Key标签，还是Value结构体中的路径标签，每个标签都通过图3中的数据字典，被映射成具体的数字ID，以数字形式进行存储。

我们的发明具体实施步骤如下。首先是步骤1，对文档进行解析。以前面给出的文档为例，采用步骤1里面所描述的SAX解析方式。在进行文档解析的时候，对每个节点生成了步骤1中描述的(Key，Value)对。假设现在解析第23行标签名为editor的节点，经过SAX解析，形成当前editor元素节点的一个(Key，Value)对，这个editor的结构内容是(editor，bib/book，指向第一个editor节点实际物理存储的指针)，然后经过图3中数据字典的映射，这个结构的实际内容是(10，[1，2]，指向该editor节点实际物理存储的指针)，其中[1，2]表示一个数组。然后继续进行SAX解析，当解析到32行标签名为editor节点的时候，形成当前editor元素节点的(Key，Value)对，然后经过图3中数据字典的映射，实际的结构内容是(10，[1，12]，指向第二个editor节点的指针)。其它节点类似，每个节点都生成了一个这样的结构。

然后按照步骤2所描述，对步骤1中解析每个节点所生成的(Key，Value)对，都按照传统的B+树算法，以解析到的节点建立一棵B+树，B+树中的Key即为上面结构中的Key。以上面的第一个editor节点为例，这个节点插入到B+树当中的时候，所对应的Key就是10。最终文档中所有的节点组成了一棵B+树，索引建立完毕。

然后是步骤3，使用索引进行查询。以查询book//editor为例。在进行查询的时候，通过我们建立的B+索引，找到所有的标签名为editor的节点，一共有两个，它们分别是节点①(10，[1，2]，指向该editor节点实际物理存储的指针)，节点②(10，[1，12]，指向第二个editor节点的指针)。然后依次对节点①和节点②中的路径信息进行扫描，对于节点①中的路径信息，也就是数组[1，2]，发现满足条件，因为数组中的数字ID 2即对应标签book，对于节点②中的路径信息[1，12]，发现不满足条件，因为该数组中没有数字ID 2，即没有book祖先。因此第一个editor是查询结果，返回给查询执行引擎做进一步操作，而节点②不满足查询条件，直接返回。对于A₁//A₂//…//A_n这样的长路径复杂查询，我们的索引查询方法类似，这里不再一一说明。

本发明具体实施所采用的硬件平台和软件平台如下：

硬件平台：CPU：Intel(R)Core(TM)2 Quad CPU Q82002.33GHz

内存：三星DDR2 800 2G

硬盘：Hitachi 240G

软件平台：操作系统：Linux Redhat5服务器版

开发平台：KDeveloper

调试平台：KDBG

编程语言：C语言。

Claims

1.一种基于路径信息的可扩展标记语言祖先后代索引方法，其特征在于包括以下步骤：步骤一：解析XML文档

采用SAX解析，使用一个栈结构，在SAX解析中会产生以下类型事件：

①文档开始；②遇到元素节点开始标签；③遇到元素节点结束标签；④文档结束；

每当遇到元素节点开始标签，即判断是否对该标签进行数据字典映射，如需要进行映射变换，则将标签的字符流转化成对应的数字ID，并存储到系统的数据字典中，然后把该数字ID入栈；如不需要进行映射变换，直接把该数字ID入栈，并且对该元素节点形成(Key，Value)对，其中Key为该元素节点对应的数字ID，Value是一个结构体，Value结构体包括该元素节点从其父节点到根节点的路径信息及指向该元素节点具体存储位置的指针；

每当遇到元素节点的结束标签，即判断该标签与栈顶元素是否是同一元素节点，如果相同，则把栈顶元素弹出，否则不操作；

在文档结束的时候，文档所有元素节点解析完毕，每个元素节点都形成了(Key，Value)对；

步骤二：建立B+树索引

存储步骤一解析出来的每个(Key，Value)对，若该方法应用于关系数据库环境，则将(Key，Value)对变成关系数据库系统中的表结构，该表有三个字段，其模式为(CurrentNode，Path，XPointer)，CurrentNode字段对应于(Key，Value)对中的Key，PathInfo和XPointer组合对应于(Key，Value)对中的Value结构体，其中PathInfo为该元素节点的父亲节点到根节点的路径信息，XPointer为一个指针，指向该元素节点所存储的具体物理地址；

若该方法应用于Native XML数据库环境，存储每个(Key，Value)对的时候要采用B+树算法来进行存储，其中Key对应于B+树中的索引键值，所对应的值即Value结构体，Value结构体包括每个元素节点从父亲节点到根节点的路径信息以及指向该元素节点所存储的具体物理地址信息；

步骤三：使用B+树索引进行祖先后代关系查询

对于A//D这类祖先后代关系查询，先通过B+树找到所有标签名称是D的元素节点，然后对于每个元素节点，依次检索该元素节点的Value结构，看看Value结构中的路径信息是否包含A标签，如果该路径信息包含了A标签，则说明这个D元素节点满足查询条件，通过Value结构中的指针找到该D元素节点具体的物理存储地址，找到查询结果；对于A₁//A₂//…//A_n这类复杂的路径查询，先通过步骤二中的B+树找到所有标签名称是An的元素节点，然后对于这些元素节点，依次检索该元素节点的Value结构，对于Value结构中的路径信息，与路径查询中的A₁//A₂//…//A_n-1进行匹配，即判断A₁//A₂//…//A_n-1是否是Value结构中的路径的有序子集。