SQL Server 全文检索技术Word文件下载.docx
《SQL Server 全文检索技术Word文件下载.docx》由会员分享，可在线阅读，更多相关《SQL Server 全文检索技术Word文件下载.docx（27页珍藏版）》请在冰豆网上搜索。
一般的OLAP类分析型应用
面向Internet、Intranet的松散耦合SOA应用
企业内部知识管理类应用
索引
大量使用非聚簇索引，一般保存在数据库中。
通过层次型、保存中间结果的方式，通过不同的轴向快速定位信息剖面。
基于XPath的索引，索引一般保存在数据库中。
基于关键字的索引，保存在文件系统中。
每个表仅支持一个索引。
表1：
全文检索与关系数据库查询、多维数据查询、XML查询的对比
2.全文检索技术简要介绍
2.1基本概念
如上文所说，全文检索主要应用领域如下：
（1）大数据量、超大数据量的结构化平文本数据和模糊匹配查找（Char、Varchar、Nvarchar）。
（2）大数据量、超大数据量的层次型XML数据展开后的查找---含模糊查找（Xmltype）。
（3）标准格式的二进制非结构化Word数据的查找（VarBinary[max]、Image）。
与其他检索技术不同的是，全文检索不仅仅提供词汇层次的查询支持，而且可以根据语言环境、不同语言的特点，甚至于用户自定义的配置提供不同语义级的大容量数据模糊匹配检索支持。
为了提供语义层次的检索，SQLServer2005的全文检索明确了如下几个概念：
（1）断字符（WordBreaker）：
因为对于不同的语言，哪些符号可以用于词汇的分割是不同的，因此全文检索支持不同语言环境的不同断字符。
（2）标记（Token）：
是由断字符标识的词或字符串。
由于划分是基于特定语言完成的，因此也可以做到语义层次的支持。
（3）干扰词（NoiseWord）：
主要是那些经常出现，但是对于检索没有多少帮助的词汇。
例如：
英语中的“a”、“and”、“is”、“the”，汉语中的“的”、“不”、“以”、“了”等。
SQLServer2005中提供配置文件，允许用户自定义自己语言、甚至与本行业、本企业的检索干扰词。
（4）词干分析器（Stemmer）：
通过断字符分割后，根据具体的语言和该语言的语法规程生成的特定词汇的变形。
（5）同义词：
即便是同一个语言，在检索的情况下也存在同义词如何处理的问题。
如果一个检索系统不能够识别近义词，而只能识别完全匹配的词汇，那对于我们中文这种表义的语言而言会带来很大不便。
同样的，一个行业内部也有很多同义词或者是缩略语。
例如如下的词语。
广播行业：
“ABC”与“英国ABC广播公司”基本上类似，但是也可能和“澳大利亚广播公司”混淆。
政府行文：
“ABC”与南美的“阿根廷、巴西、智利三国”是同义词。
军事领域：
“ABC”与“原子、生物、化学战”同义。
不仅如此，由于日常使用的习惯，我们在口语表达和书面语表达上也有区别，这个也需要预先定义。
例如，很多口头常用的技术产品“Win2K”、“WinXP”等，虽然说起来很习惯，但是在行文的时候，一般都很正式的称为“Windows2000”和“WindowsXP”，因此SQLServer2005上也提供类似词汇替换的支持，而且这些支持也是与具体语言相关的。
2.2SQLServer2005全文检索的技术架构
SQLServer2005的全文检索其实是由三个进程共同完成的，它们的总体逻辑架构如下：
图2：
SQLServer2005的总体逻辑架构
其中，三个进程分别为：
（1）SQLServerprocess（Sqlservr.exe）
（2）MicrosoftFull-TextEngineforSQLServerprocess（Msftesql.exe）
（3）MicrosoftFull-TextEngineFilterDaemonprocess（Msftefd.exe）
Msftefd主要是负责监控Msftesql进程，同时从具体的数据源根据通过使用对应的过滤器，把其中的文本信息根据断字符拆分成词汇列表（Wordlist）反馈给Msftesql进程。
整个全文检索的简要执行过程如下：
（1）从客户端发送的全文查询会转到SQLServer进程中的SQLServer查询处理器。
（2）查询处理器再将它传递给全文查询组件，该组件将创建OLEDB命令树，并将它发送到MicrosoftFull-TextEngineforSQLServer（MSFTESQL）服务。
（3）在MSFTESQL进程中，全文引擎查询处理器将使用同义词库和干扰词文件以及断字符和词干分析器来处理查询。
（4）处理此查询之后，MSFTESQL服务将结果集返回到SQLServer进程。
此结果集可以用于进一步进行处理，也可以返回到客户端。
3.规划您的全文检索
由于全文检索概念相对较多，与多数读者日常接触的关系数据库查询有所区别，因此上文笔者简单介绍了SQLServer全文检索技术的几个要点，下面笔者介绍一下面对国际化趋势，在本政府或企业的分布式异构信息系统环境下，如何规划全文检索服务的建设。
3.1全文检索服务的需求收集
抛开其他需求分析内容不谈，仅全文检索服务自身就有很多特定的需求需要明确，下面是笔者列举的一些内容。
功能性的需求：
（1）哪些业务数据需要提供全文的检索服务？
（2）这些业务数据中那些关键信息是业务人员关心的？
（3）需要支持哪些国家的语言？
（4）有哪些行业术语、常用缩略词、替换词？
（5）需要哪些检索功能，分别基于什么范畴的关键字展开检索？
非功能性的需求：
（1）业务上以前是否尝试过关系数据库查询、多维数据分析解决手头的问题？
（2）检索时效性要求。
（3）习惯的检索操作平台（浏览器/桌面），查询结果的展示方式。
（4）授权控制。
（5）查询结果的导出和发布方式要求。
3.2全文检索服务的需求分析
作为系统分析人员，在收集到这些信息后，需要从技术的角度考虑现有的技术储备是否可以完成业务的要求，根据上面的业务需求，下面是笔者认为需要考虑的技术要点：
（1）是否真的有必要使用全文检索技术，以往的关系数据库查询、多维数据分析、XML数据检索是否可以满足上述功能。
（2）用户要求的数据是否分布在不同的系统中，是否分布在不同的数据库上。
（3）数据源是否位于异构的操作系统和数据库上。
（4）不同语言的信息如何存储呢，拆分到不同的表，还是在应用层合并。
还是直接通过跨语言的同义词解决不同语言之上的关键词查找。
（5）如何选择现成的产品来集成，并完成操作台开发、信息发布、查询结果导出。
（6）通过数据库授权、证书系统授权还是应用自定义授权解决访问的安全性。
3.3数据源的规划
SQLServer2005可以同时支持如下三种数据：
（1）Char、Varchar、Nvarchar
（2）XML
（3）VarBinary（max）、Image
对于第一种，由于都是SQLServer的内置类型，因此数据提取很容易。
对于后两种，为了保证Word、Excel、PowerPoint之类的格式化二进制数据可以被检索，一般在规划上还要增加伪列来标明对应的文件扩展名。
这样，可以保证SQLServer2005全文检索的过滤器可以从对应的文件中提取出需要的文本内容，并把它通过断字符拆分成有效的词汇列表（Wordlist）。
集成方式如下：
图3：
标准VarBinary（max）、Image、XML类型的集成方式
通过查询视图sys.fulltext_document_types可以获得已经安装的过滤器（即支持的文档类型），下面是现有SQLServer2005默认支持的文档类型：
（1）.ascx、.asm、.asp、.aspx、.bat、.c、
（2）.cmd、.cpp、.cxx、.def、.dic、.doc、
（3）.dot、.h、.hhc、.hpp、.htm、.html、
（4）.htw、.htx、.hxx、.ibq、.idl、.inc、
（5）.inf、.ini、.inx、.js、.log、.m3u、.mht、
（6）.obd、.obt、.odc、.pl、.pot、.ppt、.rc、
（7）.reg、.rtf、.stm、.txt、.url、.vbs、.wtx、
（8）.xlb、.xlc、.xls、.xlt、.xml
对于远程的SQLServer，可以通过链接服务器方式访问远端数据源的全文检索系统。
若要对链接服务器执行全文查询，必须先对远程服务器上的目标表和列创建全文索引。
然后，将远程服务器添加为链接服务器。
完成这些操作后，可以在包括CONTAINS或FREETEXT这些全文查询的语句中使用，不过检索对象的命名是由四部分组成的名称对链接服务器上的目标表和列进行查询。
此外，对于以往保存在Oracle、DB2、MySQL等数据库产品上的text、image数据，也可以通过SQLServer的复制或者集成服务来进行数据同步。
这个同步要根据文本内容的更新频率、业务许可间隔、数据类型进行配置。
常用的同步方式如下：
（1）通过SQLJob，基于ODBC/OLEDB的分布式查询定期更新。
该方式可以视为从SQLServer端，定期批量从异构数据库“拉”出数据。
（2）通过IIOP、HTTP、Trigger+JOB、ExternalServer等方式向SQLServer写入。
该方式可以视为异构数据库根据配置定期向SQLServer端写入，即向SQLServer“推”数据。
（3）复制：
该方式可以提供更为实时的同步，即可以通过具有事务性（Transactional）的单票数据更新实现，也属于向SQLServer“推”数据。
（4）通过中间介质Export/Import：
通过平文本之类的中间介质，配合FTP、Queue等发送方式，完成异构数据库的导出和SQLServer端的异步入库。
图4：
异构数据库与SQLServer的同步方式
另外，对于大型的政府行业和企业而言，还存在多数据中心间的全文检索数据源同步的问题。
对于这种远程的系统，异构数据源的导入要本着就近原则，全文检索上需要考虑尽量在集中的某个中心上执行。
图5：
多数据中心的全文检索部署体系
说明如下：
每个中心内部的异构数据源的导入在本数据中心内部完成；
不同数据中心间通过双向的LinkedServer完成；
但是对于每个点视为其他中心对自己的单向LinkedServer；
客户端全文检索在就近的SQLServer2005服务器上执行。
3.4引入政府行业或者企业自身的的数据字典
为了让SQLServer2005的全文检索更适于本政府行业或者企业使用，还需要把自己特色的缩略语、书面替换语进行配置。
但是，在此之前，还要把主要使用的语言的相关信息进行配置，主要是配置相关的断字符和干扰字。
SQLServer2005的断字符配置是根据语言分析规则而异，可以为每个全文索引列指定不同的语言。
每种语言的断字符能够使得为该语言生成的词更加准确。
如果断字符用于整个语系而不是特定的子语言，将使用该语系中的主要语言。
例如，使用法语断字符来处理加拿大法语文本。
如果某一特定语言没有可用的断字符，将使用非特定语言断字符。
使用非特定语言断字符时，词将在非特定语言字符（如空格和标点符号）处断开。
SQLServer2005包含23种区域设置的断字符。
通过参阅sys.fulltext_languages就可以获得所有支持语言的列表。
地区编号
语言
2052
SimplifiedChinese
1028
TraditionalChinese
1031
German
2057
BritishEnglish
1033
English
3082
Spanish
1036
French
1040
Italian
1041
Japanese
1042
Korean
Neutral
1043
Dutch
1053
Swedish
1054
Thai
3076
Chinese（HongKongSAR,PRC）
5124
Chinese（MacauSAR）
4100
Chinese（Singapore）
表2：
SQLServer2005支持的23种区域语言
注：
所查询的全文索引列的语言决定了对CONTAINS、FREETEXT、CONTAINSTABLE和FREETEXTTABLE等全文查询函数的参数执行的语言分析。
如果未指定列的语言，默认值是配置选项defaultfull-textlanguage的值。
对于SQLServer2005的本地版本，SQLServer安装程序将把defaultfull-textlanguage选项设置为操作系统使用的语言；
对于SQLServer的非本地化版本，defaultfull-textlanguage选项为“英语”。
在明确了区域语言之后，还需要进行本政府行业或者企业的定制化操作：
（1）在$<
SQLServerInstallPath>
\MicrosoftSQLServer\MSSQL.1\MSSQL\FTDATA\中配置对应的干扰词，可以在对应的noise***.文件中增加或者修改干扰词。
例如，对以一家IT公司而言，查询的时候就直接说服务器的名字，而把“服务器”作为干扰词，查询某个网站的时候也就直接称呼网站的名字，把“网站”也可以作为干扰词。
（2）更为重要的是配置自己的同义词和替换词，同样在$<
\MicrosoftSQLServer\MSSQL.1\MSSQL\FTDATA\中配置对应区域语言的ts***.xml文件即可。
例如，把tsCHS.xml修改为如下内容：
<
?
xmlversion="
1.0"
encoding="
utf-8"
>
XMLID="
MicrosoftSearchThesaurus"
<
thesaurusxmlns="
x-schema:
tsSchema.xml"
diacritics_sensitive>
0<
/diacritics_sensitive>
expansion>
sub>
InternetExplorer<
/sub>
IE<
IE5<
/expansion>
replacement>
pat>
NT5<
/pat>
W2K<
Windows2000<
/replacement>
北京站<
北京火车站<
北京东站<
/thesaurus>
/XML>
对于同义词在检索的时候，如果用户的查询关键字是“北京站”，那么记录内容为“北京火车站”和“北京东站”的信息也会被查询出来；
对于替换词，如果用户查找的是“NT5”或“W2K”的时候，只有包括“Windows2000”的内容会被提取出来，而包括“NT5”或“W2K”自身的内容反而不会被提取出来。
4.设计全文检索的统一视图
4.1设计统一的全文检索结果Schema
如果要实现统一的检索视图，第一步要从后端统一检索结果的Schema。
笔者这里设计一个简易的Schema，另外预留一个扩展字段，作为各种信息的扩展需要。
设计上该扩展字段最好设计为XML类型，因为一方面它是可以进一步扩展的，另一方面它也是结构良好的，可以通过Xpath的索引快速查询。
Schema如下：
图6：
一个统一的查询结果Schema
说明如下。
URL：
定义信息的来源。
Title：
定义检索到的信息的Title（文章标题、数据信息的说明内容）。
DocumentType：
定义检索结果的文档类型。
Content：
定义包括关键字的一个相关的句子内容。
InventoryDate：
定义该检索内容的入库登记时间。
Extension：
扩展信息。
例如，如果您的全文检索系统是面向采购的，那么这个Extensionn您可以用来保存联系人的各种信息。
设计上首先可以定义该字段的XSD，然后通过这个XSD对输入的数据进行验证，下面是笔者给出的一个示例XSD和示例Extension内容。
联系人的示例XSD和一个示例的数据
URL
Title
Doc
Type
Content
Inventory
Date
Extension
Http:
//
www.ViT.com
Full-text
Data
Definition
Language
PDF
MicrosoftSQLServer2005introducesnewTransact-SQLdatadefinitionlanguage（DDL）statementsforcreating,implementing,andmanagingfull-textcatalogsandindexes.ThefollowingisalistofthenewFull-TextSearchDDLstatements.
2006-10-10
1
4.2多个全文检索结果的前期设计
受到全文检索仅仅支持单个表的限制，每个全文检索的结果相对有限。
但是，对于用户而言他们常常做的是一个模糊的关键词在通盘信息中的检索，这些工作应该由开发人员在应用层通过搜索引擎帮助用户进行后台的合并。
此外，对于整个政府行业和大型的企业而言，非结构化文本数据和结构化二进制信息资源很可能物理上分散在不同的物理位置上。
因此，对于高层的决策者和信息工作者而言，他们也需要查询引擎内部提供检索结果合并的支持。
这里，基于上文笔者提出的统一检索结果Schema，统一全文检索系统需要提供一个配置库，用于保存不同全文检索功能需要把哪些检索命令的执行结果进行合并，此外考虑到个别高级用户的需要，还需要提供给这一部分用户Ad-Hoc同时全文检索多个数据内容（甚至是多个信息源）的支持。
为了说明这个数据合并的过程，这里笔者假设了一个业务应用情形：
l
（1）AdventureWorks公司的高管、人事、财务等部门位于A城的总部（Headquarter），使用的是SQLServer2005。
l
（2）AdventureWorks公司的仓库位于B城，但是生产系统与总部是互联的，使用的是SQLServer2005。
l（3）AdventureWorks公司的1号工厂位于C城，但是生产系统与总部是互联的，使用的是SQLServer2005。
l（4）AdventureWorks公司最近收购了Northwind的工厂，作为它的2号工厂，这个工厂也位于B城，但是生产系统与AdventureWorks总部和原有的仓库也是互联的，使用的是Oracle9i，但是产品信息很少，相关产品绝大多数都是在本地销售。
图7：
示例应用的地理分布关系
那么根据各地的信息，如果要查询和“中国”相关的信息，各自相关的全文检索命令类似下表。
ID
编号
Title
检索内容
Site位置
DB
数据库
Command
检索命令示例
Q_01
A点人事信息
A
Adventureworks
SELECTComments，StartWorkDate
FROM<
prefix>
HR.Employee
WHERECONTAINS（Comments,'
"
fromchina"
'
）;
GO
Q_02
A点财务信息
SELECTNotes，AccountDate
Finance.Expanse
WHERECONTAINS（Notes,'
china"
Q_03
B点仓库信息
B
SELECTNote,RegisterDate
Warehouse.Inventory
WHERECONTAINS（Note,'
from
升级会员 