创新杯论文——面向中文专利信息的关系数据库检索优化策略研究及应用

面向中文专利信息的关系数据库检索优化策略研究及应用

目 录

1     引言... 3

2     中文专利信息检索优化概述... 4

2.1      中文信息检索的概念... 4

2.2      中文信息检索的现状... 4

2.3      中文专利信息检索概述... 5

2.3.1    中文专利信息的内涵... 5

2.3.2    中文专利信息的特点... 6

2.3.3    中文专利信息检索的意义... 6

2.4      中文专利信息检索优化... 7

2.4.1中文专利信息检索优化的必要性... 8

2.4.2中文专利信息检索优化理论... 8

3     WanFangData中文专利信息检索简介... 10

3.1      WanFangData专利文献多维检索与分析软件... 10

3.1.1    专利信息统计分析模块... 11

3.1.2    专利信息多维检索模块... 11

3.2      WanFangData专利信息检索需求... 11

3.2.1    专利信息多维检索需求... 12

3.2.2    专利信息统计分析需求... 13

3.3      Lucene中文索引技术简介... 14

3.3.1   Lucene结构简介... 15

3.3.2    中文自动分词技术... 16

3.3.3    基于Lucene的中文索引技术... 18

3.4      SQL Server 2005查询优化简介... 20

3.4.1    查询处理流程... 20

3.4.2   SQL查询语句优化... 21

3.4.3    查询优化器... 24

4     WanFangData中文专利信息检索优化策略... 26

4.1      WanFangData专利检索优化模型... 26

4.2      数据清洗和组织存储优化... 27

4.2.1    数据清洗... 27

4.2.2    存储优化... 29

4.2.3    数据组织优化... 32

4.3      建立索引... 33

4.3.1   SQL Server索引技术... 33

4.3.2   Lucene索引技术... 35

4.4      SQL查询语句的优化... 40

4.4.1    存储过程使用... 40

4.4.2   SQL语句技巧的使用... 41

4.5      用户输入信息的优化... 42

4.5.1   “主申请人地址”输入优化... 43

4.5.2   “IPC分类号”输入优化... 43

4.5.3    其他中文信息输入优化... 44

5     总结和展望... 45

5.1      工作的创新点... 45

5.2      存在的不足... 45

5.3      展望... 46

致  谢... 47

参考文献... 48

 

 

 

 

 

 

摘  要：在知识经济时代，专利信息已成为各国发展经济技术不可缺少的重要信息资源。然而，中文数据库查全率和查准率一直是需要解决的前沿，尤其是海量数据的中文专利数据库，如何高效而快速的满足用户检索和分析需求，对中文专利数据库的检索进行优化已势在必行。本文将基于关系数据库的检索优化理论和中文信息的处理技术，基于Lucene技术探索一种适用于中文专利信息的检索方式。同时，结合南理工万方数据实验室“WanFangData专利文献多维检索与分析软件”的检索优化工作，提出相应的方案，并予以实施。本文根据资源特点和业务流程的需求将传统的关系数据库技术和Lucene全文索引技术相结合，并首次将用户输入信息的优化纳入检索优化策略之中。

关键字：中文专利信息 关系数据库 检索优化 Lucene

1         引言

中文信息检索是现代信息检索的一个非常重要的方面，它是以中文信息为主要处理对象，根据建立的索引进行查找，并将查找的结果反馈给用户的检索方式。中文信息检索技术在原理上同西文信息检索是一致的，但汉字本身的特点使中文系统的实现比西文系统更为复杂，且中国的信息检索技术起步较晚，和国外的检索系统还有很大的差距，如检索效率、结果排序等存在很大的问题，因此需要针对数据库的检索策略进行优化。

专利作为中文信息的重要组成部分，是科学技术成果的重要表现形式。随着世界经济和技术竞争的加剧，拥有自主知识产权，提升自主创新能力，日渐成为各个国家和企业制定技术发展战略的重点和逐鹿竞争市场的利器。因此，专利信息的研究与利用被世界各国置于战略发展的基点上。然而，如何在海量的专利信息中快速检索到用户所需信息已经逐渐成为人们关注的热点，例如百度、维普、CNKI等著名网站都已推出了专利信息搜索引擎。

本文将基于关系数据库检索优化的理论基础上，重点结合 “WanFangData专利文献多维检索与分析系统”中的专利数据库来研究，提出相应的检索优化策略并进行实证分析。

2         中文专利信息检索优化概述

在我国，专利信息已经开始逐渐被人们利用和研究。但是，人们很难从大量的专利信息中快速找到满足自己需要的信息。为了提高检索效率，人们迫切需要一种策略对中文专利信息检索进行优化。

2.1       中文信息检索的概念

中文信息检索就是对中文文献进行储存、检索和各种管理的方法和技术。中文文献检索技术出现在1974年，20世纪80年代得到了快速增长，90年代主要研究支持复合文档的文档管理系统。中文信息检索在90年代之前都被称为情报检索，其主要研究内容有：包括布尔检索模型、向量空间模型和概率检索模型在内的信息检索数学模型；如何进行自动录入和其它操作的文献处理；进行词法分析的提问和词法处理；实现技术；对查全率和查准率研究的检索效用；标准化；扩展传统信息检索的范围等。中文信息检索主要是书目的检索，用于政府部门、信息中心等部门^[1]。

2.2       中文信息检索的现状

汉语在世界上属于汉藏语系，较之英语、法语是一种孤立语，汉语的独一无二的特色是完全使用由象形文字演化而来的方块汉字。中国的汉字是示意文字，总数有几万个，在由国家标准总局颁布的《信息交换用汉字编码字符集——基本集》(即GB2312280) 中共收录了一级和二级常用汉字共6 763个，而在Unicode 编码中更是收录多达20 902个汉字^[2]。因此，信息检索的难点表现在以下几个方面：

1)        词语没有形态标记。汉语是以字为基本单位，词之间没有明显的标记，词本身也没有明显的形态标志。所以中文信息检索时必须进行分词，分词本身的也有一定的错误率，这无疑降低了后续处理的实际效果。

2)        结构松散，中文信息检索时需要先过滤掉大量的标点符号以及虚词、介词等没有实际意义的词，占用了大量的系统资源。

3)        语义灵活，一方面语法的灵活主要来源于语义的灵活；另一方面同一结构可以表达不同的意思，同一意思可以用不同结构表达。中文信息检索时必须从词语的语义层次理解，这样就需要编制汉语词典，然而要构造完备的词典是不可能的。

4)        长期以来，对汉语的研究方法基本上是列举性的，而非穷尽的；材料和对象基本上是书面的，而非口语的。这主要是因为基于语义理解的研究方向，受领域的约束较大，研究进展速度缓慢^[3]。

5)        中文信息检索研究力量分散而且存在着低层次重复、缺乏统一规范和标准的问题。

6)        另外比较重要的一点是，现有的自然语言处理理论和技术大多都是以英语为研究对象语言发展起来的。而汉语无论在语音、文字表示，还是在词汇、语法、语义及其语用等各个层面上，都与之存在着很大的差异。这使得无法直接套用西方已成熟的信息检索理论和技术。

总的来说，基于以上中文信息的特点，在进行中文信息检索之前需要完成两方面的任务：

(1)     信息的规范化。

必须对中文信息按照一定的方式进行组织管理，使之成为可以高效检索的信息库。信息的规范化包括分词和索引(以及资料的搜集和整理) 、更新(维护) 两部分；信息的检索包括搜索、结果输出两部分。

(2)     信息的检索和表达。

以索引好的中文信息库作为信息基础，利用信息库已被索引的特点，实施快速检索，同时根据用户的需求将检索结果进行输出。

2.3       中文专利信息检索概述

在知识经济时代，新技术、新产品的开发活动总是与专利申请活动密切相关。作为知识成果利益享有者的权利，专利几乎囊括了一切科学技术应用领域的创新成果。在当今国际市场竞争极为激烈的情况下，专利信息更是各国发展经济技术不可缺少的重要信息资源。

2.3.1        中文专利信息的内涵

中文专利信息是指以专利文献作为主要内容或以专利文献为依据，经过分解、加工、标引、统计、分析整合和转化等信息化手段处理而形成的与专利有关的各种信息^[4]。专利信息主要分为专利文献与专利加工信息两大类。

(1)专利文献是记载发明创造内容的科学技术文献，是各国专利局及国际性专利组织在审批专利过程中产生的官方文件及其出版物的总称。一般包括专利公报、专利申请文件、专利说明书、专利索引、专利分类表、专利文摘等有关专利和专利权人的已出版或未出版的资料。专利文献技术信息含量较高，一般包括两方面内容：专利技术信息特征和专利法律信息特征，其仅报导技术成果，而不报导理论成果。

(2)专利加工信息主要包括各种专利数据库、专利专题信息资料、专利分析统计图表以及专利被引数据和专利引文数据等等。其中，专利数据库是最主要的专利文献加工信息。

2.3.2        中文专利信息的特点

专利信息是泛指与发明事务有关的各种信息，与其他科技文献相比，专利信息具有以下特点：数量巨大，内容包罗万象；内容新颖可靠；信息快，时间性强；分类科学、系统；格式规范，语言严谨；便于检索。因此专利信息所公开的内容成为比诸如学术报告、学术论文等任何信息的内容更加重要和珍贵的信息资源^[5]。

一般专利信息是以专利数据库的形势展现给人们的。例如，一条中文专利信息记录包含以下几个字段：专利名称、申请号、申请日期、申请人、发明人、申请人地址以及审定公告号等常见的专利特征信息和说明书页数、主权项权利要求等内容信息。目前，现有的专利检索系统大多是针对特征信息进行开发的。

对于一条完整的专利特征信息来说，又包含着中文信息（如专利名称、申请人地址）和非中文信息（如申请日期、主分类号）。中文信息处理的难点在专利信息的文字段的处理上凸现出来了。

2.3.3        中文专利信息检索的意义

随着企业对专利知识产权保护意识的增强，专利信息越来越受重视。企业对专利信息的需求使专利信息检索也因此备受关注。目前国内对专利信息的检索、分析和应用大多是基于专利外部特征进行的。专利信息检索的意义主要体现为以下几点：

1)        专利信息检索是企业技术创新的前提。通过对国内外现有专利的检索，及时掌握企业所属领域技术发展趋势，借鉴别人的发明专利，积极开发属于本企业的专利，响应国家自主创新的号召。

2)        专利信息检索是企业内部产品开发、科学研究之前的决策依据。企业在开发一个新产品之前应通过专利文献检索，检查自己即将开发的新产品是否侵犯了他人的专利权，以免发生专利纠纷，避免不必要的麻烦和损失。

3)        专利检索是申请专利之前的必经步骤，是撰写权利要求书的基础。技术开发之后，企业将研究、开发成果抢先申请专利，取得专利保护，这是企业参与技术竞争的一项重要工作。企业只有充分了解了是否有类似专利，才能撰写好相应的专利权利要求书。

4)        通过专利信息检索可以了解竞争对手在相关产品专利中申请方面所涵盖的权利要求内容。通过专利信息检索可以了解同行业的产品发展水平，对本技术领域的相关专利资料进行统计和分析，了解同类及相关技术的分布、专利申请频率及同族专利情况，然后预测该技术的发展趋势，从而修正或明确企业的研发方向，确保产品技术处于领先，填补市场空白，做到知己知彼，百战不殆。

5)        通过专利检索可以掌握某项专利技术所处的法律保护状态，是技术转让、专利许可的重要依据。企业为了快速发展，取得市场竞争的优势地位，可以通过引进技术来达到目的，企业在购买专利技术和得到专利许可之前，一定要进行专利检索，掌握对方专利的法律保护状态，防止购买过期或即将过期的专利而造成不必要的经济损失。

6)        通过专利信息的检索可以掌握失效专利公知的权利要求内容，有效利用失效专利，拓宽企业发展之路，减少企业发展资本。专利的保护期是有限的，一旦过期即为失效专利，企业就可以免费的使用这些专利里面蕴含的成熟技术，减少开发成本。

总之，专利是企业的生命，企业不但要重视专利的申请、专利信息的检索，还要重视对专利信息的应用，企业的发展离不开专利信息检索及专利信息应用。

2.4       中文专利信息检索优化

随着用户对专利信息需求的不断增加，他们对专利信息检索的要求也在不断地提高，突出表现为对检索速度和检索精度等均有了较高的要求。

中文专利信息检索优化就是在这种情况下提出的，最终目标是能够快速、高效地检索出符合用户需求的专利信息。

2.4.1 中文专利信息检索优化的必要性

随着专利信息的累积、需求的拓展和系统的更新换代，对系统数据处理效率的要求越来越高。尽管当前关系数据库管理系统技术成熟，能够自动对海量数据查询进行自动优化处理。但是，如果数据库设计不合理，或者没有按照需求特性运用相应的优化策略，不仅会增加客户端和服务器端的编程和维护的难度，而且还会影响系统实际运行性能，严重时将导致系统瘫痪。

专利信息检索的目的在于提供满足用户要求的专利信息，但是却由于检索过程中一些不确定性因素（中文专利信息的特点）而使得该目标难以实现。影响一个中文专利信息检索系统性能的因素包括：基础数据的存储和组织方式、查询条件的表示方法、查询相关性的匹配策略以及查询结果的排序方法等。这些因素的根源均来自于中文专利信息的模糊性和复杂性。

此外，用户通常希望用最小的努力获得自己最满意的专利信息。因此，查询通常具有简短、概要以及不精确三个特点。如何尽量减小这些因素给信息检索质量带来的影响从而优化关系数据库检索策略就成为了中文专利信息领域的研究重点与发展动力。

2.4.2中文专利信息检索优化理论

中文专利信息检索优化是一种代价的均衡，某一方面性能的提高往往是以牺牲另一方面的性能为代价的，并且随着软硬件技术的发展，优化的代价也在不断变化中。目前，中文专利信息检索优化策略主要是对数据库进行优化以及为中文信息建立有效的索引。

一方面，数据库是专利信息存储和处理的核心，数据库设计的好坏直接影响着信息检索系统总体的性能。因此，一个好的中文专利数据库必须建立在良好的数据库设计基础上，必须针对系统的应用特点、系统软硬件环境、专利信息特性和数据库管理系统本身特点进行综合考虑，采取合理的优化策略，才能充分发挥数据库的作用，提高系统整体性能。

另一方面，我们必须针对中文信息处理的难点，通过采取一定的策略为中文字段建立合理有效的索引，从而可以根据系统的需求、环境，将每个检索操作占用的磁盘I/O时间、CPU处理时间、内存量等系统资源减少到最合理，使每个查询、统计分析等处理的响应时问尽量短，以充分利用系统软硬件资源，最大限度地提高整个系统的数据吞吐量和处理能力，避免出现数据传输、存储和处理瓶颈。降低系统的成本，提高数据库系统的性价比^[6]。

基于以上分析我们可以总结出专利数据库优化的主要策略分为以下四种方式：数据清洗和组织存储优化、建立索引、SQL查询语句优化以及用户输入信息的优化。

1)        数据清洗和组织存储优化

影响专利检索系统效率最为关键的是数据库中的基础数据，数据清洗的目的就是减少数据库中的难以辨识的信息和非法信息。组织优化是将数据以便于处理的形式进行组织。例如，将部分中文信息转换为数字或字符信息，从而为检索优化的实行提供基础。

专利数据库存储优化的重点是对数据文件和数据表进行合理的设计。当前，系统的大部分数据都是集中在少数的几个数据表上，造成数据表的记录条数达到千万，甚至是数亿。如何对数据库进行合理设计，避免全表扫描、降低表之间的连接查询开销是数据库优化的关键。

2)        建立索引

建立合理的索引也是提高专利检索效率的重要举措。就中文专利信息而言，合理的索引不仅可以避免扫描大量数据，同时可以帮助用户快速找到所需信息。

3)        SQL查询语句优化

查询优化也是数据库优化的重要方面。关系数据库系统为用户访问和修改数据提供了强有力的关系查询语言。SQL作为一种结构化的数据库查询语言，具有易于使用的、非过程化的、描述性等特点。结构良好的查询语句将会减少系统自动优化的开销。因此，对查询语句进行优化是必不可少的。

4)        用户输入信息的优化

对用户输入信息的优化主要是规范用户的输入信息，尽量减少用户输入非法数据的可能性。这样，不仅可以避免大量无效的查询，同时也可以保证系统的稳定性。

总而言之，中文专利信息检索优化策略应遵循以下规则：

               i.         设立合理的性能目标。在优化之前，需要确定合理的目标。设立目标最重要的是可量化和可达到。

             ii.         确定影响系统性能的瓶颈。当系统运行了一段时间后，会发生性能低下，这时需要把握问题关键，分析找出当前性能瓶颈的所在。

           iii.         找出影响数据库性能的因素。由于改善数据库性能所采用的方法都可能带来严重的负面影响，因此在达到预定目标时，应停止所有的工作。在对数据库进行性能调整时，如果某个成分不是瓶颈源，就不要对它进行更改。

下文将在检索优化理论的指导下，对已开发的专利检索软件进行检索优化，从而提高检索效率，提高软件的用户满意度。

3         WanFangData中文专利信息检索简介

WanFangData中文专利信息检索是“WanFangData专利文献多维检索与分析软件”的主要功能模块之一，本文对中文专利信息检索优化策略的研究就是在此模块上进行的。

3.1       WanFangData专利文献多维检索与分析软件

WanFangData专利文献多维检索与分析软件是南理工万方数据实验室一期项目的成果，该软件以专利信息分析、竞争情报和知识挖掘等理论为基础，利用数理统计方法和计算机软件技术，对专利信息进行多维统计加工、智能化定量分析和内容的深度挖掘，并将分析结果以可视化界面提供给用户。在此基础上，用户能够追踪最新的技术发展动态，分析技术发展的演变趋势，甚至预测未来技术发展的方向。该系统以顾客需求为起点，以服务流程为驱动，既考虑软件产品的独立性、完整性，又兼顾可拓展性。

该软件主要分为专利信息统计分析模块、专利信息多维检索模块以及系统配置模块，下面介绍最主要的两个功能模块。

3.1.1        专利信息统计分析模块

专利信息统计分析模块是WanFangData的核心功能模块，其分析角度是WanFangData区别于现有专利分析软件的关键所在。它从不同层级用户（国家或地区、行业、企业）的专利分析需求出发，设计了与之相匹配的专利分析指标体系，为各层级用户进行专利分析提供强有力的数据支持。

3.1.2        专利信息多维检索模块

WanFangData专利信息检索模块提供强大的统一资源搜索引擎，支持快速检索、二次检索、高级组合检索等常用检索方式，方便用户从海量专利信息资源中快速获得所需专利信息。用户还可以通过WanFangData拥有的数据导出功能，将检索结果导出到本机上，形成Excel文档，从而方便编辑和保存检索结果。

3.2       WanFangData专利信息检索需求

专利信息检索与专利信息统计分析是WanFangData专利文献多维检索与分析软件的两大功能模块，它们都是在专利数据库信息检索的基础上，分别将用户所需的数据以表格和可视化图形的形势表现出来。

WanFangData数据库DBPat2007中的数据是从1985年至2007年的在中国申请的专利，累计已经超过了200万条记录。随着时间的推移，记录数据量必将继续快速增长。这些原始数据最初是存放在Access数据库中的，因此需要我们通过ETL（EXTRACT-TRANSFORM-LOAD）将数据导入到SQL Server 2005中，由于不是本文的重点，这里不予详述。

由于数据在录入之前的格式本身就不规范，若将导入的数据直接提供给应用程序进行检索和分析，结果显然不是用户所需要的，而且这样这势必会影响检索和分析的精确度，同时检索的效率将会非常低下。

我们在对中文信息检索优化的过程中除了使用上述优化理论中提到的数据清洗和存储优化、建立索引、SQL Server查询语句的优化以及用户输入信息的优化等一般方法外，还必须针对WanFangData专利文献多维检索与分析软件自身的特点进一步细化优化的策略，因此我们必须分析软件对数据检索的需求。

3.2.1        专利信息多维检索需求

专利信息检索是直接针对专利数据的外在特征（如专利名称、申请人、发明人、主分类号等）进行的，用户是通过输入检索条件得到满足自己需要的相关专利信息。检索界面如图1所示，图中我们不难看出，一般非专业用户很难明确知道自己所需专利信息的IPC分类号及其格式，因此优化的过程中应尽量减少用户输入不规范或违法信息的可能性，从而保证检索的效率。

 

图1 检索界面

根据上文对专利信息特点的描述，可以看出，大量的专利信息在数据库中以中文字符的形式存在，而对中文信息的处理一直是限制检索效率的瓶颈。因此在系统优化的过程中，必须将中文字符尽可能地转换为易于处理的英文字符或阿拉伯数字，例如专利类型、行政区域代码。

对于不能转换的中文信息，利用SQL Server数据库管理系统自带的工具（分词、建立索引）还远远不能解决中文信息处理的难点问题，我们必须借助其它技术来更好地对中文专利信息进行处理。Lucene就是在传统数据管理系统不能有效解决中文索引的情况下产生的，下一节将作具体介绍。

此外，专利信息检索的结果是以序列化表格的形式展现给用户（图2所示），因此如何选择检索结果的显示方式和排序方式来达到较高的效率也是系统优化必须面对的问题。

 

图2 检索结果

3.2.2        专利信息统计分析需求

专利信息统计分析模块分为“企业”、“国家”和“地区”三个层次设计了相应的指标，根据用户的选择从数据库中查询和计算相关信息得到用户所需的数据，然后通过可视化图形的形式直观地反映给用户。

在统计分析中，用户选定相应的指标（如图3所示）后，系统根据输入的信息对数据库中相关的数据进行分析。分析过程中，用户感兴趣的专利信息不再仅仅局限于专利数据库提供的原有属性上，而更多则是根据用户的习惯与偏好进行分析，如专利的主申请人的国别、地区等。而这些信息最初都是包含在主申请人地址中，我们应当对这些数据进行预处理，从主申请人地址中提取国别和地区信息，这样在分析的过程中就避免了大量的操作，提高了分析的效率。

 

 

图3 指标分析界面

3.3     Lucene中文索引技术简介

由于“WanFangData专利文献多维检索与分析软件”的数据库是通过微软SQL Server 2005 Enterprise管理的，虽然能够较方便地对专利数据进行组织和操作，但是我们无法控制其信息索引的方式。由于是针对西文字符开发的，SQL Server 2005突出表现在对中文信息索引时问题较大，因此我们采用了目前流行的Lucene技术，并与SQL Server 2005结合使用一起管理专利数据库。

Lucene是apache软件基金会jakarta项目组的一个子项目，是一个开放源代码的全文检索引擎工具包，即它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。

3.3.1        Lucene结构简介

Lucene本身没有定义数据源，而是定义一个通用的文档结构，所以只要为相应的文件编写一个文档转换器，Lucene可以对任何文件进行索引。总体上看：可以先把Lucene当成一个支持全文索引的数据库系统。

1)        与关系型数据库比较

从表1可以看出， Lucene和传统的关系型数据库在数据组织结构上相似，这样一来，将Lucene和SQL Server 2005结合管理专利数据库就比较容易了。

 

表1 Lucene与数据库的比较

2)        Lucene索引结构

Lucene索引index由若干段(segment)组成，每一段由若干的文档（document）组成，每一个文档由若干的域（field）组成，每一个域由若干的项（term）组成。项是最小的索引概念单位，它直接代表了一个字符串以及其在文件中的位置、出现次数等信息。域是一个关联的元组，由一个域名和一个域值组成，域名是一个字串，域值是一个项，比如将“标题”和实际标题的项组成的域。文档是提取了某个文件中的所有信息之后的结果，这些组成了段，或者称为一个子索引，子索引可以组合为索引。下图是Lucene索引的概念结构图。

 

图4 Lucene索引的概念结构图^[12]

虽然Lucene最初是用java开发并且不支持中文，但是随着技术的发展，Lucene技术已经冲破了开发语言的限制，人们可以通过扩充它的语言分析器实现对中文的检索。

3.3.2        中文自动分词技术

目前的搜索引擎，大多是基于一种称为倒排索引的结构。以什么作为索引的Key值，直接影响到整个搜索引擎的准确度、召回率、速度。

对于中文，如果不使用分词，可以采用单个汉字索引方式。例如“专利”，先索引“专”字，然后再索引“利”字。同样，对于一个中文专利字段，先把所有的汉字都单独索引一次，并记录他们的位置。搜索过程中，也是先找“专”字的所有记录，再找“利”字的所有记录，然后做交叉“与”运算，即包含这两个字，而且位置连续的记录才会作为符合要求的结果。这种方式是最基本的索引方式（SQL Server2005的全文索引即采用该方式）。但这里存在一个很有挑战性的问题：总共的常用汉字是3000多个，我们每次查询过程中，进行“与”操作的计算量会相当大，对于大数据量搜索引擎来说(超过200万的记录)，这样的索引结构，无疑是对硬件和算法的极大挑战。

考虑到速度问题，如果不使用分词，还有另外一种选择：n元组合索引方式，如2元、3元等。拿2元来说，计算机，先索引“计算”，再索引“算机”。同样，对于一个专利中文字段，以2为单位，把所有相邻的汉字都索引起来，并记录它们的位置。搜索过程中，也是先找包含“计算”的所有记录，再找“算机”的所有记录，然后做交叉“与”运算，即包含这两个单元，而且位置连续的记录才会作为符合要求的结果。这样以两个字作为索引单元，可以大大减少在搜索过程中的计算量。

以上两种方式，都可以不需要分词，也能实现搜索引擎的索引和搜索。但是这里存在一个不可忽视的问题：准确度。一个很常见的例子：和服，如果按照上面两种方式，都会查到包含“主板和服务器”的记录；“北大”也会得到“东北大学”。对于大数据量的搜索引擎来说，每个搜索次都会有成千上万条记录，用户已经很难挑选他真正想要的信息，如果这里还要增加许多错误，用户体验会极差。这时候，我们需要中文分词。

分词就是将连续的字序列按照一定的规范重新组合成词序列的过程。在英文的行文中，单词之间是以空格作为自然分界符的，而中文只是字、句和段可以通过明显的分界符来简单划界，唯独词没有一个形式上的分界符，虽然英文也同样存在短语的划分问题，但是在词这一层上，中文比之英文要复杂的多、困难的多。

词是中文语言中最小的语义单位，以词为单位作为搜索引擎索引的Key值，会大大提高搜索引擎结果的准确性，同时保证了搜索过程中计算量小。其实还有一个优点，以词为单位的索引，索引库会比上两种方式小很多。

目前现有的分词算法可分为三大类：基于字符串匹配的分词方法、基于理解的分词方法和基于统计的分词方法。考虑到技术的可行性我们选择易于实现的基于字符串匹配的分词方法。

基于字符串匹配的分词方法又叫做机械分词方法，它是按照一定的策略将待分析的汉字串与一个机器词典中的词条进行配，若在词典中找到某个字符串，则匹配成功（识别出一个词）。这里需要说明的是，由于该方法需要建立词典，因此和领域联系非常密切。

按照扫描方向的不同，串匹配分词方法可以分为正向匹配和逆向匹配；按照不同长度优先匹配的情况，可以分为最大（最长）匹配和最小（最短）匹配。虽然实验表明，对于汉语来说，逆向最大匹配法比正向最大匹配法更有效。考虑到算法实现的复杂程度，我们选用正向最大匹配法（由左到右的方向），流程如图5所示。

 

图5 最大正相匹配分词流程

由于Lucene项目是开源的，我们可以根据上述的分词算法在结构中添加识别中文词语的分析器，进行分词从而建立有效的索引。

3.3.3        基于Lucene的中文索引技术

Lucene.net就是将Lucene整体架构用微软.net技术实现的。目前，人们通过扩充它的语言分析器已经初步完成了支持中文索引的项目——Lucene.China。

为了尽量减少索引表的长度，Lucene.China为一条中文信息建立索引时，分为以下几个步骤：

l  过滤掉待索引信息中的空格和标点符号。

l  对照主题词表（sDict.txt），将该条信息分成单个词。

l  对照噪音词表（sNoise.txt），过滤掉上述单个词中无意义的词，如英文中的“in”“too”等，中文中的“的”“是”“你”“我”等。

l  若包含英文单词时，英文字母大小写一致看待，不区别英文名词单复数，不考虑英文动词时态。

l  为剩余的词建立索引。

Lucene是一个高性能的全文检索工具包，它的高性能很大一部分得归功于它所使用倒排文件索引结构。Lucene.China是在Lucene.net基础上扩展的，也采用了倒排索引，为简单起见，我们采用两条专利信息中的专利名称字段作为例子说明：

1)        设有两篇文章f1 和f2记录专利名称字段

文章f1的内容为：一种快速聚合优良基因的水稻育种方法

文章f2的内容为：一种检测水稻种子纯度的方法

2)        首先获取这两篇文章的关键词。包括如下几个步骤：

a. 找出文章中的所有词。

b. 过滤掉文章中没有什么实际意义的词，如“一种”、“的”。

在Lucene.China中以上措施由ChineseAnalyzer类完成。经过上面处理后，

文章f1的所有关键词为：[快速] [聚合] [优良] [基因] [水稻] [育种] [方法]，

文章f2的所有关键词为：[检测] [水稻] [种子] [纯度] [方法]。

3)        有了关键词后，就可以建立倒排索引。

上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来，变成：“关键词”对“拥有该关键词的所有文章号”。同时，还要记录关键词在文章中出现次数和出现的位置，即记录该词是文章中第几个关键词（优点是节约索引空间、词组查询快）。因此，文章f1，f2经过倒排后变成表2所示的索引列表 ：

表2 Lucene索引表结构

关键词	文章号[出现频率]	出现位置
快速	f1[1]	2
聚合	f1[1]	4
优良	f1[1]	6
基因	f1[1]	8
水稻	f1[1]，f2[1]	11，4
育种	f1[1]	13
方法	f1[1]，f2[1]	15，10
检测	f2[1]	2
种子	f2[1]	6
纯度	f2[1]	8

 

 以“水稻”这行为例我们说明一下该结构：水稻在文章f1中出现了1次，文章f2中出现了1次，它的出现位置为“11，4”，其中“11”就表示“水稻”在文章f1中出现的位置，剩下的“4”就表示“水稻”是文章f2中的位置。

以上就是Lucene.China索引结构中最核心的部分。我们注意到关键字是按字符顺序排列的，因此Lucene可以用二元搜索算法快速定位关键词。实现时Lucene将上面三列分别作为词典文件（Term Dictionary）、频率文件(frequencies)、位置文件 (positions)保存。其中词典文件不仅保存有每个关键词，还保留了指向频率文件和位置文件的指针，通过指针可以找到该关键字的频率信息和位置信息。

下面我们可以通过对该索引的查询来解释一下为什么要建立索引。

假设要查询名称包含“水稻”的专利，Lucene先对词典二元查找、找到该词，通过指向频率文件的指针读出所有记录号，然后返回结果。词典通常非常小，因而，整个过程的时间是毫秒级的。

而用普通的顺序匹配算法，不建索引，而是对所有记录的内容进行字符串匹配，这个过程将会相当缓慢，当文章数目很大时，时间往往是无法忍受的。

3.4     SQL Server 2005查询优化简介

WanFangData专利文献多维检索与分析软件的大部分数据是通过SQL Server 2005来管理的，该管理软件本身已经集成了查询优化的工具。因此在对专利信息检索优化之前，我们还必须了解SQL Server 2005是如何处理用户提交查询请求的机制。

3.4.1        查询处理流程

当用户向SQL Server提交一个查询语句后，数据库服务器处理的基本步骤包括：

1)       分析器扫描 SELECT 语句并将其分成逻辑单元（如关键字、表达式、运算符和标识符）。

2)       生成查询树（有时称为“序列树”），以描述将源数据转换成结果集需要的格式时所用的逻辑步骤。

3)       查询优化器分析访问源表的不同方法，然后选择返回结果速度最快且使用资源最少的一系列步骤。更新查询树以确切地记录这些步骤。查询树的最终、优化的版本称为“执行计划”。

4)       关系引擎开始执行“执行计划”。在处理需要基表中数据的步骤时，关系引擎请求存储引擎向上传递从关系引擎请求的行集中的数据。

5)       关系引擎将存储引擎返回的数据处理成为结果集定义的格式，然后将结果集返回客户端。^[11]

从上述的5个步骤中可以看出，SQL Server 2005的查询优化主要集中在执行计划的选择上，这些功能集中在查询优化器上。在第2步生成的查询树后，查询优化器利用基于启发式规则的代数优化方法，得到接近最低成本的查询“执行计划”，从而提高查询效率。

3.4.2        SQL查询语句优化

所谓查询优化，就是在查询执行引擎生成一个执行策略的过程中，尽量使查询的总开销和总时间达到最小。查询优化在关系数据库系统中有着非常重要的地位。

在关系数据库中，数据查询步骤一般如图6：

 

图6 查询处理步骤^[8]

实际查询的优化主要步骤如图7。

 

查找空间生成的等价计划

输入查询

查找策略

查询重写

优化的逻辑查询计划

转化规则

代价模型

 

图7 查询优化处理过程^[9]

SQL语句是对关系数据库进行操作的唯一途径。通常SQL语句消耗70％到90％的数据库资源。对数据库系统的性能起着决定性的作用。目前，大部分数据库管理系统都具备语句自动分析优化功能。但由于SQL语句十分灵活，因此优化器的功能对许多劣质的SQL语句仍是无能为力。劣质的SQL语句和优质的SQL语句之间的速度差别可以达到上百倍。构造优质的SQL语句通常需要遵守四个原则：

l  查询语句要尽量用到索引。尤其是对大数据表的查询，要充分利用索引，绝对避免全表扫描。

l  尽量避免相关子查询。如果子查询不可避免。要在子查询中过滤掉尽可能多的行。

l  尽量减少多表连接，在必须进行连接的操作时。要先使用选择、投影等操作把不需要的行剔除，以减少连接所产生的中间数据。

l  语句不能苛求简洁。简洁的语句具有易于理解、书写方便等优势，但简洁不等于高效。为了优化数据库的性能，往往需要以增加语句的复杂度为代价。

虽然专利数据有着自身的特点，但关系数据库的检索模型对专利数据库同样适用。下面，我们从两个方面来介绍一下SQL Server专利数据库的检索优化模型。

1)    基于启发式规则的查询优化

通常，多个不同的关系代数表达式可以是等价的：也就是说，它们对应于同一个查询，查询解析器一般会生成一个对应于SQL查询的标准初始查询树（initial query tree），而不做任何优化。普通的查询树是一种很容易创建的简单标准形式。现在要由启发式查询优化器把这个初始查询树转换为一个可以高效执行的最终查询树^[10]。

查询优化器必须包括可用于初始查询树的关系代数表达等价规则。而启发式查询优化规则就是利用这些等价表达式将初始树转换为最终的优化查询树。

基于启发式规则的代数优化方法，主要遵循一下规则：

(1)     选择运算应尽可能先做；

(2)     投影运算和选择运算同时进行；

(3)     把投影统其前或其后的双目运算结合起来，没有必要为了去掉某些字段而扫描一边关系；

(4)     把某些选择同在它前面要执行的笛卡尔积结合起来成为一个连接运算。

(5)     找出公共子表达式。

主要的启发式规则是首先应用能够减少中间结果规模的操作，这包括：尽早完成SELECT操作来减少元组数，尽早完成PROJECT操作来减少属性数。通过在树中把SELECT和PROJECT操作尽可能下移，可以做到这一点。此外，应该在其他类似操作之前先执行限制最严格的SELECT和JOIN操作。为此通常要重排查询树中叶节点的顺序，同时避免笛卡尔积操作，并对余下的树进行适当调整。

2)    基于代价估计的查询优化

基于代价的优化主要计算各种操作算法的执行代价，他与数据库的状态密切相关。在数据字典中存储了优化器需要的统计信息。

(1)     统计信息

               i.         每个基本表的元组数、元组长度、占用的块数、占用的溢出块数；

             ii.         对基表的每个列，该列的不同值的个数、选择率、该列的最大值、最小值，该列上是否已经建立的索引，是哪种索引（B+树索引、Hash索引、聚集索引）；

           iii.         对于索引，例如B+树索引，该索引的层数、不同索引值的个数、索引的选择基数、索引的叶节点数；

(2)      代价估算模型

                    i.              全表扫描算法代价估算

如果基本表大小为B块，全表扫描算法的代价cost=B ；

如果选择条件是码 = 值，那么平均搜索代价cost=B/2 。

                  ii.              索引扫描算法的代价估算

如果选择条件是码 = 值，则采用该表的主索引，若为B+树，层数为L，需要存取B+树中从根节点到叶节点L块，再加上基本表中该元组所在的那一块，所以cost=L+1。

如果选择条件涉及非码属性，若为B+树索引，选择条件是相等比较，S是索引的选择基数（有S个元组满足条件）。因为满足条件的元组可能会保存在不同的块上，所以（最坏的情况）cost=L+S 。

如果比较条件是>，>=，<，<=操作，假设有一半的元组满足条件，那么就要存取一半的叶节点，并通过索引访问一半的表存储块。所以cost=L+Y/2+B/2 。如果可以获得更准确的选择基数，可以进一步修正Y/2与B/2 。

3.4.3        查询优化器

查询优化器是用来处理SQL语句优化的组件，是 SQL 数据库系统中最重要的组件之一。SELECT 语句是非程序性的，它不规定数据库服务器检索请求的数据的确切步骤，这就是查询优化器存在的意义。优化器的输入包括查询、数据库方案（表和索引的定义）以及数据库统计信息，优化器的输出称为“查询执行计划”。

在优化单个 SELECT 语句期间查询优化器的输入和输出如下图中所示：

 

图8 查询优化器

在这个过程中查询执行计划定义了访问源表的顺序。数据库服务器一般可以按许多不同的序列访问基表以生成结果集，而根据查询条件访问基表时也有不同的析取数据的方法，既可以使用索引也可以执行表扫描。这部分就是应用了代价估计的查询优化算法，从而得到优化的估计执行计划。

优化的过程就是从潜在的多个可能的计划中选择一个执行计划。使用查询优化器会在分析查询和选择计划时要使用一些开销，但当查询优化器选择了有效的执行计划时，这一开销将节省数倍。

SQL Server 查询优化器是基于成本的优化器，因此必须分析可能的计划并选择一个预计成本最低的计划。如果查询存在过多的计划，此时查询优化器会使用复杂的算法查找一个执行计划：其成本合理地接近最低可能成本。此时最低可能成本就是根据上文介绍的基于启发式规则的代数优化方法计算得到的。

SQL Server 的查询优化器将选择执行具有最低估计处理开销的查询计划。查询优化器基于以下两个主要因素来确定执行查询计划的开销：

l  查询计划每个级别上处理的总行数，称为该计划的基数。

l  由查询中所使用的运算符规定算法的开销模式。

其中，基数用作开销模式的输入参数。因此，增大基数将减少估计开销，从而加快执行计划。因此找准基数，使得开销准确的计算，生成理想的查询计划是在使用SQL Server应该注意的问题。一般在下列情况下，SQL Server 无法精确计算基数。避免在查询中使用这些构造可以提高查询性能：

1)        带谓词的查询，这些查询在同一表的不同列之间使用比较运算符。

2)        带谓词的查询，谓词使用不等于 (!=) 比较运算符或 NOT 逻辑运算符。

3)        使用 SQL Server 内置函数、标量值函数或用户定义的函数（其参数不是常量值）的查询。

这些容易生成不理想的查询计划的构造，在下文所述的SQL查询优化将会得到具体的提出改正措施。此外，SQL Server 2005还提供了计划强制功能，可以手动的选择查询执行计划。

结合上文中介绍的有关SQL Server的相关知识，下文将结合其特点在WanFangData专利数据库检索优化的过程中发挥其优势。

4         WanFangData中文专利信息检索优化策略

通过上一节对“WanFangData专利文献多维检索与分析软件”中文专利信息检索的介绍，无论是检索模块还是统计分析模块，软件对专利信息检索的需求已经很明确，对中文专利信息检索的优化已经确定了理论上的可行性。下面我们将把上文介绍的Lucene技术和SQL查询优化技术应用到实际软件的专利信息检索优化的过程中。

4.1       WanFangData专利检索优化模型

“WanFangData专利文献多维检索与分析软件”的专利搜索引擎结构比较简单，存在多处可优化的环节，如图9。

中文专利数据库

数据库管理系统

查询分析器

用户

获取搜索条件

返回搜索结果

SQL查询语句语优化

数据清洗和组织存储优化

建立索引

用户输入信息优化

 

图9 WanFangData专利检索系统架构图(优化前)

现在我们尝试着根据中文专利信息检索的优化理论的四个方面，对原专利搜索引擎进行优化，优化后的模型如图10所示。

 

 

 

 

预处理 模块

中文专利数据库

数据库管理系统

查询分析器

用户

获取并优化搜索条件

排序并返回搜索结果

聚集索引

非聚集索引

全文索引

抽取中文字段

Lucene中文信息全文库

分词、建立索引

业务模块

查询优化器

“à”表示非中文信息搜索流程 “-->”表示中文信息搜索流程

 

图10 WanFangData专利检索系统架构图(优化后)

下面主要从数据库的数据清洗和组织存储优化、建立索引、SQL查询语句的优化以及用户输入信息的优化四个方面来详细阐述专利信息检索的优化策略。

4.2     数据清洗和组织存储优化

专利数据库是“WanFangData专利文献多维检索与分析软件”的正常运行依赖的基础。我们要想在专利信息检索优化上取得较好的效果，基础数据的优化则起着至关重要的作用。一般对基础数据的优化可以从数据清洗、组织优化和存储优化等几个方面进行。

4.2.1        数据清洗

数据清洗一般是指通过某种措施将原来不规范的难以利用的数据转换成规范程度高、便于识别和利用的数据。这里数据清洗的目的是希望减小用户检索过程中的出现的误差，这是数据库提供服务的基础，也是建立索引以及进行检索的基础。此外，下文建立索引的质量很大程度上取决于基础数据的规范性。

在将数据从原始的Access数据库转换到SQL Server 2005数据库的过程中，由于专利在早期的数据信息不规范，因此为了实现专利检索和统计分析的应用需求，首先需要完成的基础工作就是对不规范的数据进行清洗，尽量减小噪音数据的影响。

在早期的专利数据库中会存在大量不规范的数据，几种典型的不规范现象如下表：

表3 数据清洗格式

原始数据格式	规范数据格式
主申请人地址(561000贵州省安顺市66号信箱吕景新转杨麟)	国别+省份(直辖市)+地级市(或直辖市下的区)+县级市(或地级市下的区)+(街道+门牌号)(可以省略)+行政区划编号
申请日期、记录生成日期、进入国家日期、颁证日期	申请日期、记录生成日期、进入国家日期、颁证日期(1998.06.09)
申请人(罗锦兴%∴志坚)	申请人(罗锦兴%志坚[1])
发明人(孙钟岳%曾昆铭)	发明人(孙钟岳;曾昆铭[2])

 

注[1]：个人与个人，个人与企业，企业与企业之间共同为申请人的请以’%’作为分隔符

[2]：个人与个人，个人与企业，企业与企业之间共同为发明人的请以’;’作为分隔符

这些不规范数据中，其中关于主申请人地址的清洗是所有清洗工作中最困难的，也是最紧迫的，因为在专利统计分析阶段所需要国别、省市地区以及可以精确到市的行政区划编码都是基于主申请人地址。因此在进行主申请人地址清洗过程中，需要将在中国申请的专利精确到县级市（或者区）。

在清洗数据库的过程中，所做的辅助工作是将现在国家存入数据库中的country表中，将中国最新的行政区划数据存放到数据库的xzqh数据表中，并且根据这两张表，用专利数据表中的主申请人地址字段与它们进行匹配，从而得到比较准确的数据（仍然有数据需要手工维护）。

例如，一条专利信息中主申请人地址是“江苏省南京市钟灵街50号”，我们人工通过互联网找到“钟灵街50号”是处在南京市的玄武区，因此这条记录的主申请人地址修改为“江苏省南京市玄武区钟灵街50号”。

除此之外，有关企业的数据也清洗难度也相当高，比如：“清华大学”和“北京清华大学”、“上海华为”和“华为技术有限公司” 其实它们都是一家单位，但如何自动将它们识别出来目前就很难解决，而且对于200多万条记录通过人工清洗显然也是不科学的。

因此，我们对这些数据的清洗工作仍是一项长期而艰巨的任务。

4.2.2        存储优化

Microsoft SQL Server 2005采用内存中的排序和哈希联接技术执行排序、交集、联合、差分等操作。这种类型的查询计划支持垂直表分区（有时称为分列存储）。将数据库分区可提高其性能并易于维护，我们将一个大表拆分成更小的单个的表，只访问小部分数据的查询可以执行查询时更快，因为需要扫描的数据少了。根据这个原理采用的分区可以分为以下几个方面：

l  硬件分区：执行多线程操作的多处理器，使得可以同时运行许多查询，以及RAID（独立磁盘冗余阵列）设备使得数据在多个磁盘驱动器中条带化，使更多的读写磁头同时读取数据，因此可以更快地访问数据。

l  水平分区：水平分区将表分为多个表。这样，每个表包含的列数相同，但是行更少。这样扫描的范围就会减少，提高了检索速度。例如将数据库中的专利按时间进行水平分区存储，这样在检索某一年份的在中国申请的专利数据量，就可以只访问该年份专利数据分表，大大提高了速度。

l  垂直分区：垂直分区将一个表分为多个表，每个表包含较少的列。垂直分区的两种类型是规范化和行拆分。规范化理论在专利数据库中的应用，降低数据库的数据冗余，消除数据库中的更新异常、插入异常以及删除异常。在数据库规范化过程中，可以将原始的一个数据模式分解为满足某一模式的多个数据模式。同理在实际应用当中，还可以根据应用需求，根据字段的使用频度，将数据表拆分为几张表。显而易见，这样设计后的数据库使得查询需要扫描的数据变少了。

在WanFangData中文专利数据库中，存储优化策略主要体现在：

1)        根据物理分区的思想，将数据表分为主数据文件和次数据文件，其中主数据文件是用来存放主要的数据，次数据文件是一般存放主数据文件中容纳不下的数据（在主数据文件未满的情况下，也可以存放数据），这样数据库就能继续增长。通过创建多种的数据文件，将每个文件放在不同的磁盘驱动器上，就相当于将数据分散到多个磁盘上。同时，在SQL Server 2005中的每个数据库有拥有一个主要文件组。此文件组包含主要数据文件和未放入其他文件组的所有次要文件。此外，它还可以创建用户定义的文件组，用于将数据文件集合起来，以便于管理、数据分配和放置。

在DBPat2007数据库中，创建了2个自定义文件组，即SECOND和THIRD文件组，同时创建了两个次要数据文件分属于这两个文件组，这两个自定义文件组的物理位置与主要文件组所放置的位置不同，从而对表中数据的查询将分散到多个磁盘上，从而提高了性能。并且出于安全性方面的考虑，我们将数据和日志文件放在不同的磁盘上。

2)        应用水平分区的思想，结合应用需求，将基本的统计出来的数据信息放入辅助表。为了避免检索的速度受到联合查询的影响，放弃了直接对原始的基本数据的水平分区，而是针对专利数据的特点，面向国家、地区、专利类型以及专利的主分类号分别进行统计，放入对应的辅助表中。当然这些表针对主要数据文件的修改都会及时更新，以保证数据库状态得一致性。

为了提高专利统计分析的速度，我们采用水平分区的思想，将总的专利特征表pattzb中专利类型为发明专利和实用新型的专利数据记录根据国际专利八大部分类分为8个专利特征表，外观设计的专利则单独存放与一张表中，详细如下表所示：

表4 水平分区列表

pattzbA	分类号部为A的专利特征表
pattzbB	分类号部为B的专利特征表
pattzbC	分类号部为C的专利特征表
pattzbD	分类号部为D的专利特征表
pattzbE	分类号部为E的专利特征表
pattzbF	分类号部为F的专利特征表
pattzbG	分类号部为G的专利特征表
pattzbH	分类号部为H的专利特征表
wgsjtzb	专利类型为外观设计的专利特征表

 

3)        根据垂直分区所介绍的方法，专利数据库中的数据表的模式在这之前的模式是：

专利（id ，专利名称，发明人，申请人，主申请人地址，国别省市代码，申请号，申请日期，审定公告号，审定公告日，法律状态，分类号，主分类号，范畴分类号，优先权项，权项数，变更事项，授权日，授权公告日，说明书页数，附图页数，胶片光点号，摘要，权利要求，主权项-权利要求，分案原申请号，颁证日期，说明书光盘号，国际申请，国际公布，进入国家日期，代理机构地址，代理人，专利类型，数据库标识，记录生成日期）

从上面这个模式可以看出，在数据库中如果将所有的属性字段都放在同一张数据表中，势必会影响检索速度。同时针对数据检索的需求根据主申请人字段添加的国别（gb）、地区(dq)以及行政区划代码（postcode）。将专利原数据的一张统一的表根据应用需求分解为如下的模式：

 

图11 数据结构

从上图中可以看出在数据库DBPat2007中，采用的是将数据库中的专利数据分为两张数据表（pattzb表和patnrb表），在专利的分析与检索过程中主要使用的数据表是pattzb数据表，同时应用水平分区思想建立的dqnum（地区分区统计结果），ipcnum（IPC主分类号分区统计结果），countrynum（国家，申请人以及专利类型进行分区统计的结果）。由于patnrb数据表只是在检索后的查看全文时才用到，因此将patnrb数据放在SECOND文件组中，并且将其存放在此数据文件中，以此来提高检索效率。

4.2.3        数据组织优化

数据组织优化是指把数据库中的信息以更好的形式组织起来，方便数据的管理和使用。我们这里的组织优化是针对部分字段的信息进行的，主要是通过转换它们的格式来达到组织上的优化。

因为专利数据库是通过微软SQL Server 2005管理的，利用SQL语句对中文信息的查询效率要远小于非中文信息，因此，这里我们主要针对专利信息的中文字段进行类型转换。

1)        “主申请人地址”转换

通过上面数据清洗的步骤，我们可以将“主申请人地址”字段的信息严格按照规范格式存储，如“浙江省杭州市西湖区浙大路38号”。虽然“主申请人地址”已经较规范，但由于该字段信息较长，故不利于专利信息的搜索。

我们对照最新的国家行政区划表，将“主申请人地址”转换成相应的地区代码(postcode)，如上述地址转换为“330106”，其中“33”表示“浙江省”，“01”表示“杭州市”，“06”表示“西湖区”。

经过转化后，用户通过“主申请人地址”检索专利时只需要将检索词转换成相应的数字代码即可在数据库中快速匹配。例如用户想搜索主申请人在“杭州”的专利信息，那么我们只需要在数据库中找到postcode字段前四位是“3301”的记录。

2)        “专利类型”转换

专利类型共有三种，即“发明专利”、“实用新型”和“外观设计”。最初数据库中的zllx字段类型是char，长度为8，并且以中文的形式存储。根据中文专利信息检索优化的理论，我们将专利类型用英文字母代替，即“f”表示“发明专利”，“s”表示“实用新型”，“w”则表示“外观设计”。这样，zllx只须1个字符长度即可，既节省了存储空间，又为以后建立索引提供了便利。

4.3     建立索引

建立合理的索引也是专利信息检索优化的主要手段，使用索引可快速访问数据库表中的特定信息。由于专利数据库采用了SQL Server 2005和Lucene相结合的管理方式，并且它们都提供了较方便的索引工具。下面，我们结合这两种工具的优势，详细介绍索引的建立过程。

4.3.1        SQL Server索引技术

SQL Server数据库中的索引与书的目录相似，可以快速定位到表或索引视图中的特定信息。创建设计良好的索引，可以显著提高数据库查询和应用程序的性能。索引可以减少为返回查询结果集而必须读取的数据量。

根据分析，目前适合于DBPat2007数据库的索引主要有：聚集索引，非聚集索引、组合索引以及全文索引。对于专利数据库，我们要根据检索需求并结合字段本身特点，选择最佳索引类型。总的来说，建立索引时我们应考虑以下几个问题：

l  在经常进行连接的列上建立索引。

l  在数据量较少的表上不宜建立索引。

l  在频繁进行排序或分组(即进行group by或order by操作)的列上建立索引。如果待排序的列有多个，可以在这些列上建立复合索引，并且注意复合索引中列的顺序，使第一列有较高的选择性，以加快查询速度。

l  有大量重复值、且经常有范围查询（ between， >，< ， >=，< = ）和 order by、 group by 发生的列，可考虑建立群集索引。

l  在不同值较少的列上不宜建立索引，重复值太多，建立索引不会提高查询效率。

l  选择长度较短的列建立索引。因为在较短列上建立索引，缓存中能放置更多的索引页，可以减少I/O操作，提高查询速度。

l  经常进行插入、删除和修改操作的列上不宜建立索引。

由于SQL Server 2005目前对中文信息索引的效率并不高，不仅对索引存储空间需求较大，而且在信息查询时容易造成检全率和检准率的下降。因此，这里我们主要针对数据库表pattzb中的几个常用非中文字段建立索引。

pattzb（专利特征表）在检索过程中用到的字段为id（序列号）、zflh（主分类号）、sqh（申请号）、zlmc（专利名称）、zllx（专利类型）、zsqrdz（主申请人地址）、postcode（申请人地区代号）、sqrq（申请日期）、sqren（申请人）、fmr（发明人）。经过前面数据清洗的工作，这里能够建立索引的非中文字段包括id，zflh，sqh，zllx，postcode和sqrq。

1)        建立聚集索引

聚集索引就是指索引项的顺序与表中记录的物理顺序一致的索引组织， 检索效率比普通索引高。但对数据新增/修改/删除的影响比较大，因此建立该索引后，如果对表更新，可能导致表中记录物理顺序的变更。

由于一张表只能有一个聚集索引，所以必须对其检索的效率进行权衡。

 

图12 软件检索界面

通过软件检索模块的界面（如图12）来看，所有的检索过程都会在数据库中进行从“开始时间”到“结束时间”的记录查找，即频繁地和sqrq（申请日期）匹配。因此，在字段sqrq上建立聚集索引。

在群集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。

2)        建立非聚集索引

不同于聚集索引，非聚集索引不影响表中的数据存储顺序，检索效率比聚集索引低，对数据新增/修改/删除的影响很少。

根据检索的需要，我们分别对sqh（申请号）、zflh（主分类号）、zllx（专利类型）、postcode（申请人地区代号）建立了不唯一的非聚集索引。

此外，在软件检索过程中为了减少计算机内存的使用从而提高检索速度，我们使用了分页显示，这里用到了id（序列号），因此对id建立索引很有必要，并且由于id是唯一标识，故将其设为主键，这样系统就自动为其建立非聚集索引。

3)        全文索引和组合索引

全文索引是一种特殊类型的基于标记的功能性索引，它是由 Microsoft SQL Server 全文引擎生成和维护的。不同于生成其他类型的索引，全文引擎并非基于特定行中存储的值来构造 B 树结构，而是基于要编制索引的文本中的各个标记来生成倒排、堆积且压缩的索引结构。

由于Microsoft SQL Server对中文字段建立全文索引技术尚不健全，尤其是针对中文信息的分词技术还有待完善，这里我们没有对检索字段建立全文索引。

组合索引就是使用表中的不止一个列对数据进行索引的索引，覆盖的查询可以提高性能。由于软件检索模块的程序比较单一，未将不同检索项类型的检索分类，因此不利于组合索引的建立。

综上所述，在DBPat2007数据库中建立的索引以及键如下表：

表3 数据库索引

类型	名称	涉及到的字段
主键	PK_pattzb	Id
非聚集索引	IX_pattzb_sqh	sqh
	IX_pattzb_zflh	zflh
	IX_pattzb_zllx	zllx
	IX_pattzb_postcode	postcode
聚集索引	IX_pattzb_sqrq	sqrq

 

4.3.2        Lucene索引技术

对于专利信息检索中用到的中文字段，我们则采用了Lucene索引技术。Lucene采用的是全文索引技术，与SQL Server 2005不同的是，我们利用Lucene建立索引时，可以自主确定建立索引的方式以及存储位置。而SQL Server 2005建立的索引我们是看不到的，并且无法对索引过程进行控制。下面我们将把关系数据库技术和Lucene技术相结合，这也是本编文章的主要创新点。

1)        建立词表

通过上节对Lucene的介绍，针对中文信息索引是利用Lucene内部的语言分析器对中文信息进行分词，我们采用的是基于最大正向匹配分词算法。因此索引建立之前，必须建立两张词表：主题词表（sDict.txt）和噪音词表（sNoise.txt）。

词表是某一主题法实体的具体体现。所谓创制一种主题检索语言，就是编制一部完整的词表。词表对一个文献主题概念可以用什么词标引，不可以用什么词标引作了严格限定。因而，它是一种主题检索系统用词的主要依据。

主题词表（sDict.txt）用来匹配和切分中文信息中的关键词，而噪音词表（sNoise.txt）则是用来匹配和过滤中文信息中无意义的虚词、介词和代词等。它们必须根据要索引信息的特征来建立。在“WanFangData专利文献多维检索与分析软件”专利信息检索模块中，需要建立索引的字段除了通过SQL Server 2005建立索引的非中文字段，还包括zlmc（专利名称）、fmr（发明人）和sqren（申请人）中文字段。此外，从检索界面上可以看出，sqrq（申请日期）和zllx（专利类型）也要重新建立索引。

数据库中的发明人一般以中文姓名的形式存在，没有明显的特征。申请人除了个人外还包括企业、学校、科研单位和政府部门，从中可以抽取相关的主题词，如“南京大学”、“南京情报所”等专有名词。

根据前期用户对软件使用情况的反馈信息来看，专利名称搜索是大多数用户搜索专利的主要方式。因此，提高专利名称搜索的效率是改善用户对该软件评价的主要方式。

 

图13 专利主题词表的一部分

 

图14 噪音词表的一部分

如何根据专利特征建立优质的主题词表至今为止是一个难点。在专利领域，国家相关部门还没有建立完善的词表，因此我们只能在主题词表（sDict.txt）中加入一些常用的关键词，如计算机、纳米、机器人等，如图13。为了尽可能地保证索引的质量，我们致力于通过人工的方法分析和找出专利名称中无意义的词，建立噪音词表（sNoise.txt），如图14。例如以下三个专利名称：

l  用于温室的可去除保护膜技术

l  一种可在苗期监控的水稻种植方法

l  百合绿豆糕及其制作工艺

通过分析，我们可以找出“用于”、“一种”、“在”、“的”、“及其”等五个无意义词，并把它们加入到噪音词表中。由于DBPat2007数据库中专利条数已经超过200万，我们在建立噪音词表时不可能对每条信息都进行人工分析，但随着优化工作的进行，噪音词表将会越来越完善。

2)        创建索引

Lucene.net.Index是建立全文索引的核心，它的工作就为每个切出来的词建索引，查询时就只需要遍历索引，而不需要去正文中遍历，从而极大的提高检索效率，索引建设的质量关键整个系统的质量。Lucene常被用来对文本文件，如.txt/.doc/.xml等格式文件中的内容建立全文索引，不能直接对SQL Server数据库索引，需要将数据库中的记录逐条取出，再建立索引。需要指出的是，为了减少数据的冗余，我们仅在Lucene中存储字段id的值和zlmc、sqrq、zllx、fmr以及sqren的索引信息。

以document对象方式传入

专利数据库

通过select语句将记录逐条传入

调用

生成document对象，将各数据表字段加入对应的field对象

生成field对象，根据其性质决定是否分词创建索引

准备阶段

加入document对象

生成document小段

分析document、切词

记录排序位置信息

写出索引信息

写出标准化因子

顺序调用

建立索引阶段

内存文件系统

字节流输入

索引文件

合并输出

 

图15 Lucene索引建立数据流逻辑^[12]

下面是我们建立索引的步骤，如图15：

(1)     初始化全文库

初始化全文库的语句为：

     IndexWriter  writer = new IndexWriter(”全文目录的位置”，new ChineseAnalyzer()， true);

其中，第二个参数是专门为中文信息建立索引的一个分析对象，与上面建立的词表相结合，主要用于从文本中抽取那些需要建立索引的内容，把不需要参与建索引的文本内容去掉。第三个参数用于确定是否覆盖原有索引的。

(2)     记录加载

记录加载的语句为：indexWriter.addDocument(doc);IndexWriter主要用于写库，当需要读取库内容时，就需要用到IndexReader这个类了。

索引的单位是Document对象，每个Document对象包含多个字段Field对象，针对不同的字段属性和数据输出的需求，对字段还可以选择不同的索引/存储字段规则，列表如下：

表4 索引方式说明

Field.Index	Field.Store	说明
TOKENIZED	YES	被分词索引且存储
TOKENIZED	NO	被分词索引但不存储，只是利用了索引功能
NO	YES	这是不能被搜索的，它只是被搜索内容的附属物。
UN_TOKENIZED	YES/NO	不被分词，它作为一个整体被搜索，搜一部分是搜不出来的。

 

我们建立索引主要代码如下：

     SqlDataReader myred = ExecuteQuery("select id， zlmc，sqrq，zllx，fmr，sqren from DBPat2007.dbo.pattzb");//从特征表中逐条取出专利信息

     while (myred.Read())

    {

Document doc = new Document();//创建记录对象

      doc.Add(new Field("id"， myred["id"].ToString()， Field.Store.YES， Field.Index.NO));//存储，不索引

       doc.Add(new Field("zlmc"， myred["zlmc"].ToString()， Field.Store.NO， Field.Index.TOKENIZED));//不存储，分词索引_中文字段

       doc.Add(new Field("sqrq"， myred["sqrq"].ToString()， Field.Store. NO， Field.Index.TOKENIZED));//不存储，分词索引_字符类型字段

       doc.Add(new Field("zllx"， myred["zllx"].ToString()， Field.Store. NO， Field.Index.UN_TOKENIZED));//不存储，整体索引(不分词)_字符类型

       doc.Add(new Field("fmr"， myred["fmr"].ToString()， Field.Store. NO， Field.Index.TOKENIZED));//不存储，分词索引_中文字段

       doc.Add(new Field("sqren"， myred["sqren"].ToString()， Field.Store. NO， Field.Index.TOKENIZED));//不存储，分词索引_中文字段

   writer.AddDocument(doc);//加载记录

}

这里，Lucene索引过程是从内存中读取记录信息，将记录中的id字段进行存储，但不被索引。对记录中的其余几个字段则分别索引，为了节省存储空间，这里不保存它们的信息。

由于Lucene全文库中并没有保存检索结果（图2）所要显示的信息，因此我们必须将Lucene全文库与SQL Server数据库结合起来。换句话说，我们这里仅仅利用了Lucene的全文索引功能。

用户输入检索条件，系统接收并分析用户输入的条件，若用户进行的是基于中文字段的检索，那么系统直接连接到Lucene全文库上。根据用户的搜索条件，系统自动到Lucene全文库中的索引表去匹配，这样我们就可以很快得到保存在Lucene全文库中的专利的唯一标识id。然后根据id信息，系统就可以在SQL Server数据库中快速检索出所需要的信息。由于id在SQL Server数据库专利特征表中是唯一的主键，因此这样的检索方式效率是很快的。

4.4     SQL查询语句的优化

第三章介绍了SQL Server 2005查询优化的原理，这里我们根据这些理论对SQL Server 2005数据库的优化策略进一步阐述。SQL查询语句的优化包括存储过程的使用和SQL语句技巧的使用。

4.4.1        存储过程使用

存储过程是存储在数据库服务器中的，通过了服务器注册，并且分配用户相应的权限以保证数据库的安全。存储过程的使用明显的提高了应用程序的响应速度，这样就允许开发者进行模块化设计，从而可以多次调用。

存储过程最重要的一个特点在与一般的查询语句执行比较中即可看出。在数据库中执行查询语句一般都经历三个过程，即翻译、优化和处理，其中最耗费时间的是优化这个环节，而存储过程正是在绕过了这个问题。

存储过程创建之后，只在首次执行时进行解析和编译，查询优化器生成了执行该存储过程的最优的执行计划，在下一次调用该存储过程时可以直接按该计划执行，这样就减少了翻译和优化两个步骤，节省了大量时间。不过如果数据库中出现了变动，存在比现有的存储过程的执行计划更优的方案时，就必须对存储过程进行重新编译，若没用强制进行重新编译，数据库将会在下此执行该存储过程时，自动重新编译。

在DBPat2007专利数据库中，我们针对软件功能模块的需求，对检索和分析中涉及到的对数据库的查询操作都写成了存储过程，同时提供调用数据库中存储过程的公用方法类，从而提高了检索与分析的速度。

4.4.2        SQL语句技巧的使用

SQL语句技巧也是检索优化的一个重要方面，如果建立了索引却没有很好的使用它，或者使用了存储过程，但是存储过程中的语句消耗的时间却非常长，这些问题都反映出SQL语句技巧的重要性。而目前对DBPat2007的查询操作都集中在存储过程中，因此也就是对存储过程中的sql语句进行优化，以提高检索效率。

优化的主要对象是SQL语句中“不充分的连接条件”和“不可优化的 where 子句”，原则是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的 I/O 次数，尽量避免表搜索的发生。

目前，针对专利数据库DBPat2007中的SQL语句，优化主要从下面几个方面：

(1)     尽量避免反复访问同一张或几张表，尤其是数据量较大的表（如pattzb数据表，数据量已经超过了200万条），可以考虑先根据条件提取数据到临时表中，然后再做连接进行查询运算。

(2)     尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该改写；如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。

(3)     充分应用索引，注意where子句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小，同时group by和order by后面的字段也应该与索引顺序一致。

(4)     不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

(5)     尽量使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。

(6)     尽量使用“>=”，不要使用“>”。

(7)     在对两张表进行连接操作时，应尽量先使用子查询，以减少进行连接的数据量，尽量避免直接进行数据表的连接。

(8)     关于时间（sqrq）的条件限制，一般放在where条件的最后面（效率越低的放在越后面），一般的数据有多个限制条件时，后一个条件是在前一个条件选择后的关系上进行的，也就是说，这样从整体上进行了优化。

(9)     注意系统自带一些工具的使用，比如在进行分页时，SQL Server 2005提供了一种ROW_NUMBER()，比一般自己编写的程序效率就要高很多。

根据对整个软件系统的存储过程详细分析，在检索过程中几乎用不到联合查询，因此我们将优化的重点放在where子句的优化上。

where 子句中对列的任何操作结果都是在 SQL 运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被 SQL 优化器优化，使用索引，避免了表搜索。

所谓优化即 where 子句利用了索引，不可优化即发生了表扫描或额外开销，其优化原则如下：

l 任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

l in 、or 子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把子句拆开；拆开的子句中应该包含索引。

这里，列出优化过程中常见的两种情况：

① 优化前，set @sql ='select … where … and (year(sqrq) between ' + @shijian1 + ' and ' + @shijian2 +' )'

优化后，充分利用了sqrq上建立的聚集索引，set @sql ='select … where … and sqrq >='' ' + @shijian1 + '-01-01'' and sqrq <=''' + @shijian2 +'-12-30'''

② 优化前，set @sql ='select … where …'  set @sql1='select … where id in '+ @sql+' and …'

优化后，将两个SQL语句合并，set @sql = 'select … where … and …'

经过测试人员对数据库系统的测试，优化后的存储过程效率是原来的2倍以上。由此证明，SQL语句的优化在整个系统优化工作中是比较成功的。

4.5     用户输入信息的优化

对用户输入信息的优化主要是规范用户的输入信息，尽量减少用户输入非法数据的可能性。优化工作分为两种类型：一种是直接限定用户信息的输入，另一种是系统自动过滤用户输入的非法信息。

4.5.1        “主申请人地址”输入优化

对用户输入“主申请人地址”信息的优化属于第二种优化类型。系统第一步先将对照国家行政区划表，将用户输入的检索词（如“杭州”等）转换成地区代码。

第二步，存储过程接收到传进的postcode参数（如“3301%”），就可以到数据库特征表pattzb中查询postcode字段前四位是“3301”的所有专利记录。由于postcode是数字类型的，索引的效率要远远大于zsqrdz（主申请人地址）的效率。

4.5.2        “IPC分类号”输入优化

由于非专业用户不了解IPC分类号的具体含义，因此IPC分类号检索对于大部分用户来说，使用起来较困难，而且用户输入的信息极有可能存在书写不规范的情况，这样对于不规范信息的检索效率显然是低下的。

经过反复思考，我们决定为用户提供IPC分类表辅助定位功能，它将全程伴随用户的检索过程，随时为用户提供辅助导航支持。在用户进行检索的过程中，WanFangData左侧一直会出现IPC分类表（如图16），用户可以根据自己的需要随时点击IPC分类表查看某领域专利在IPC分类表中的类目归属，从而对检索范围形成更加明确的认识。

这样，用户只要在IPC分类树上点击自己感兴趣的内容节点，系统就会在右侧检索词文本框中自动填上相应的分类号，既减少了用户的输入错误，有增强了用户的体验功能。

 

图16 IPC分类号检索

4.5.3        其他中文信息输入优化

对于其它中文信息输入时，软件采用了Lucene体系里面的搜索分析器，它能自动分析用户输入的中文信息，并过滤掉非法字符、空格以及无意义的虚词等。主要代码如下：

Lucene.China.ChineseAnalyzer ChAnalyzer = new ChineseAnalyzer();//中文分析器

IndexSearcher mysea = new IndexSearcher(index_store_path);//索引路径

QueryParser q = new QueryParser("zlmc"， ChAnalyzer);//创建"sqren"的中文解析器实例

Query queryJsc = q.Parse(keyword);//检索词搜索，解析keyword

Filter filterTime = new RangeFilter("sqrq"， beginYear， endYear， true， true);//把时间作为过滤条件

Hits myhit = mysea.Search(queryJsc， filterTime);//主查询+条件过滤(实验证明，采用条件过滤的效率高于多条件检索)

第一步，创建Lucene.China的对象，即中文分析器。

第二步，利用IndexSearcher打开索引文件用于后面搜索，其中的参数是索引文件的路径。

第三步，使用QueryParser将可读性较好的查询语句(比如查询的词“计算机”，以及一些高级方式“计算机” AND “电脑”)转化为Lucene内部使用的查询对象.

第四步，执行搜索。并将结果返回到hits集合。需要注意的是出于空间考虑，Lucene并不是一次将所有的结果放入hits中而是采取一次放一部分的方式，并且我们取出来的结果只是专利记录的id。

有了id之后，系统便能很快从SQL Server数据库中找出相关数据并返回给用户。

5         总结和展望

5.1     工作的创新点

本文是在分析了中文专利信息检索重要意义的基础上，针对中文信息的难点问题，运用中文自动标引技术、SQL关系数据库技术以及.NET技术，根据南理工万方数据联合实验室“WanFangData专利文献多维检索与智能分析软件”的检索优化工作并结合大量的检索优化理论，最终通过项目组团队合作完成的。

与其它研究中文信息检索的文章不同，我们非常重视对基础数据的处理。任何算法和策略必须在建立在基础数据规范规则有序的基础上，才能发挥其最佳作用，否则再好的检索策略也只是空中楼阁。

将关系数据库技术的Lucene全文索引技术相结合是本文的一个亮点，我们突破了传统的限制将二者有机结合，使优化工作达到最高效率。

此外，本文从全局出发，全面而深入地对“WanFangData专利文献多维检索与智能分析软件”进行了分析并找出了一切可能影响检索效率的瓶颈。例如“用户输入信息的优化”就是在这种情况下提出的，IPC分类树也可以说是我们的一个创新点。

5.2     存在的不足

中文信息的特点决定了对中文信息的处理难度要远大于西文信息，虽然本文在基础数据的清洗上花了大量经历，但毕竟人工清洗的效率极低，将几百万条数据按照给定的格式清洗不是短时间内所能完成的，这是本文的缺陷之一。

虽然和前期项目相比，我们在中文切分词上取得了较大突破，但是考虑到技术的可行性，本文只采用了效率并非最高的“最大正向匹配算法”。而且，该算法必须依赖完善的专利主题词表，专利领域的主题词成千上万，专利词表的建立已经远远超出了我们的能力所及范围，这是本文的缺陷之二。

5.3     展望

在我国，中文专利信息检索仍然面临着许多问题，这必然限制了人们对专利信息的充分开发与利用，一定程度上也将制约着我国技术创新能力的发展。但随着数据库检索技术和中文信息处理技术的不断发展，中文专利信息检索的问题将逐渐迎刃而解。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

致  谢

 

 

从2008年1月我们小组六位成员进入南理工万方数据联合实验室参与项目开发以来，这中间凝聚了多少的酸甜与苦辣，心血与汗水。而此文也是我们经过一番历练之后，对中文专利数据库的使用情况做的理论总结。

本文能够顺利完成，首先要感谢项目组中的四位老师： 王曰芬 老师、 吴鹏 老师、 岑咏华 老师、 颜端武 老师。如果没有这四位老师在理论及技术上的悉心指导，本文也将只是一个空想。

此外，还要感谢系里的其他各位老师： 甘利人 老师、 李莉 老师、 丁晟春 老师、 戴建华 老师、哈进兵老师、 薛春香 老师、 章成志 老师、 张忠林 老师等。无论是在相关课程知识的积累上，还是日常项目开发过程中，各位老师都给了我们很大的支持与帮助。

另外还要感谢项目组中的其他成员，感谢他们在这个漫长的软件开发过程中，与我们并肩作战。

最后，还要感谢学校与学院的支持，给我们提供了一个潜心钻研、发挥所长的平台。由于我们学识有限，本文难免有疏漏及不妥之处，恳请各位专 家 老师批评指正。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

参考文献

[1] 中文信息检索_百度科[EB/OL] . http://baike.baidu.com/view/920786.html. 2007-12-02 /2008-05-12.

[2] 吴栋，滕育平. 中文信息检索引擎中的分词与检索技术[J]. 计算机应用，2004，24（7）：128-130.

[3] 王建会. 中文信息处理中若干关键技术的研究[D]. 复旦大学，2004.

[4] 许亚玲,付云. 基于专利信息价值的竞争情报研究[J]. 岳阳职业技术学院报. 2007,22(4).

[5] 陈秀莲. 专利信息检索与企业的发展[J]. 科技情报开发与经济.2007，l7(17).

[6] 林建阳. 关系数据库应用系统的优化策略[J]. 福建电脑，2008（2）：51-52.

[7] 徐鑫涛.浅谈数据库优化[J].维普资讯.

[8] 王珊，萨师煊. 数据库系统概论[M].高等教育出版社.2006，5(4).

[9] 刘亚欣. 数据库查询优化技术研究及其应用[D].大连理工大学.2006，12，5.

[10] Elmasri,Navathe. 张伶，杨健康译. 数据库系统基础[M].中国电力出版社. 2006,1,1(1).

[11] SQL Server联机丛书.

[12] 开放源代码的全文检索引擎[EB/OL].http://www.lucene.com.cn/about.htm. 2006-10-12/2008-09-10.