将非结构化数据实时聚集为结构化数据以便关系数据库引擎进行SQL处理转让专利
申请号 : CN200480007597.7
文献号 : CN1761962B
文献日 : 2010-04-28
发明人 : 阿瑟·乔依 , 托德·莱巴 , 比特·伯斯特 , 阿密特·R·索玛尼
申请人 : 国际商业机器公司
摘要 :
用于搜索非结构化数据的方法、系统和程序产品。通过由扩展搜索协调器首先搜索非结构化数据，来搜索作为文本数据或图像数据的非结构化数据。扩展搜索协调器具有非结构化数据搜索的搜索请求者和搜索代理之间的中间部件。搜索代理返回搜索结果给协调器以进行聚集。协调器聚集搜索结果并将搜索结果返回给包装器。包装器然后从聚集的搜索结果中提取结果属性，并使所述属性作为例如别名表中的一个或多个列。关系数据库使用结构化查询语言(SQL)可以搜索所述别名表。
权利要求 :
1.一种在包含非结构化数据系统和结构化数据系统的计算机系统中搜索非结构化数据的方法，包括：a.通过对非结构化数据搜索的扩展搜索协调器和搜索代理搜索非结构化的数据；
b.从对非结构化数据搜索的扩展搜索协调器和搜索代理返回具有属性的搜索结果以便进行聚集；
c.聚集搜索结果；
d.将聚集的搜索结果返回给包装器，该包装器被配置为将搜索结果的属性输入到别名表；以及e.在别名表中输入搜索结果属性，通过结构化数据搜索引擎可以搜索所述别名表。
2.根据权利要求1中的方法，包括利用非结构化数据搜索系统搜索非结构化数据，所述非结构化数据搜索系统包括扩展搜索协调器和搜索代理，所述方法包括利用搜索代理搜索非结构化数据，利用扩展搜索协调器聚集由此获得的搜索结果。
3.根据权利要求2中的方法，包括将搜索结果从搜索代理返回给扩展搜索协调器以进行聚集，以及将聚集的搜索结果和搜索结果属性传送给包装器。
4.根据权利要求3中的方法，包括使搜索结果属性成为别名表中的至少一列。
5.根据权利要求1中的方法，其中别名表是关系数据库别名表。
6.根据权利要求5中的方法，其中别名表是关系数据库管理系统表，结构化数据搜索引擎是关系数据库管理系统，并且别名表可由关系数据库管理系统使用结构化查询语言进行搜索。
7.根据权利要求6中的方法，其中结构化查询语言是SQL。
8.一种在包含非结构化数据系统和结构化数据系统的计算机系统中搜索非结构化数据的方法，包括：a.通过结构化数据搜索引擎、非结构化数据搜索代理和两者之间的扩展搜索协调器来搜索非结构化数据；
b.将具有搜索结果属性的搜索结果从搜索代理返回给扩展搜索协调器以进行聚集；以及c.在别名表中使用包装器输入搜索结果属性，该包装器被配置为将搜索结果的属性输入到所述别名表，所述别名表可由关系数据库管理系统使用结构化查询语言进行搜索。
9.根据权利要求8中的方法，其中所述扩展搜索协调器输入搜索结果属性到别名表中。
10.根据权利要求9中的方法，包括输入搜索结果属性作为别名表中的一列。
11.根据权利要求9中的方法，其中结构化数据搜索引擎在别名表中查询搜索结果属性。
12.根据权利要求9中的方法，其中结构化查询语言是SQL。
13.一种计算机系统，包括非结构化数据搜索代理、结构化数据搜索引擎和别名表，其中a.所述计算机系统适用于从结构化数据搜索引擎、通过非结构化数据搜索代理，来启动非结构化数据的搜索；
b.所述非结构化数据搜索代理适用于从非结构化数据中接收具有搜索结果属性的搜索结果，并聚集搜索结果；
c.所述计算机系统适用于在别名表中输入搜索结果属性；以及d.所述结构化数据搜索引擎适用于使用包装器在别名表中搜索属性，该包装器被配置为将搜索结果的属性输入到别名表。
14.根据权利要求13中的计算机系统，其中结构化数据搜索引擎是关系数据库管理系统搜索引擎。
15.根据权利要求14中的计算机系统，其中关系数据库管理系统搜索引擎是联合搜索引擎。
16.根据权利要求15中的计算机系统，其中非结构化数据搜索代理包括扩展搜索协调器。
17.根据权利要求13中的计算机系统，其中将搜索结果属性输入到别名表中作为别名表中的列。
18.一种包括非结构化数据搜索系统、结构化数据搜索引擎和别名表的计算机系统，其中：a.所述计算机系统适用于从结构化数据搜索引擎、通过非结构化数据搜索系统，来启动非结构化数据的搜索；
b.所述非结构化数据搜索系统包括扩展搜索协调器和非结构化数据搜索代理；所述非结构化数据搜索系统适用于从搜索代理中接收具有搜索结果属性的搜索结果，并将具有搜索结果属性的搜索结果返回给扩展搜索协调器以进行聚集，并适用于聚集搜索结果和搜索结果属性；
c.所述计算机系统适用于在别名表中输入搜索结果属性；以及d.所述结构化数据搜索引擎适用于在别名表中使用包装器搜索搜索结果属性，该包装器被配置为将搜索结果的属性输入到别名表。
19.根据权利要求18中的计算机系统，其中结构化数据搜索引擎是关系数据库管理系统搜索引擎。
20.根据权利要求19中的计算机系统，其中关系数据库管理系统搜索引擎是联合搜索引擎。
21.根据权利要求18中的计算机系统，其中非结构化数据搜索系统包括扩展搜索协调器。
22.根据权利要求18中的计算机系统，其中将搜索结果属性输入到别名表中作为其中的一列。
说明书 :
技术领域
本发明涉及搜索(即查询)存储在数据库中的非结构化(unstructured)数据的方法，包括将SQL查询转换为非结构化数据的适当查询。本发明的另一个方面是将结构化关系数据库所标识的外部SQL访问类型转换为非结构化数据库或文件的内部访问，并且将SQL外部查询格式转换为中间或内部查询格式。本发明的方法、系统和程序产品特别应用于文本搜索和索引。
背景技术
通过SQL访问结构化数据与例如web上文档的非结构化数据的全文本搜索是非常不同的。在具有行和列的二维表中维护关系模型中的结构化数据。表中每行代表对象的一个实例(instance)，而每列代表该对象的属性。给列赋予符号化名称，并分配特定的数据类型(例如整数、日期等)。可以对列施加完整性限制，以进一步指示有效值。
由于以固定格式命名和表示了列值，可以非常精确地基于其内容选择行。所述能力在处理数字数据中非常有用。可以基于匹配列值将来自不同表的数据结合在一起。可以进行有用类型的分析，例如在一个表中列出在相关表中遗漏的(或在相关表中呈现的，或具有指定属性的)对象。可以从一张大表中提取感兴趣的特定行，重新组合所述行，并对其产生简单的统计。
相反，不总是以固定的并且可预测的方式组织非结构化数据。非结构化数据以各种形状和格式被存储，在整个企业中分布，并由针对正在进行的任务最合适的软件进行管理。趋向于以自由文本格式记录数据(例如，包含于电子邮件、笔记和文档中的文本)，所述格式具有很少或没有编成字段的元数据。因此，搜索实际上是较少地参数化，而更多的是基于关键字的。搜索结果更多的是得自于“匹配”给定关键字集合，而很少得自于计算标准。
然而，希望以结构化方式查询非结构化数据，以将更多的值增加到结果集合中。将web看作可以使用标准SQL查询的关系数据库是有益的。同样重要的是，能够通过SQL接口统一地处理多个异构和非结构化数据源也是有益的，因此消除了数据集成的模糊性。
解决所述问题的常规技术是从非结构化数据源中提取预期数据，对数据应用任何必要的转换，然后将如此转换的数据放置到关系数据库中，以进行以后处理。实际上，这种仓储(warehousing)技术是现在针对各种应用所使用的一种通用方法。
然而，所述技术没有涉及使非结构化数据可用于参数化查询的构建(overarching)问题。
由于以固定格式命名和表示了列值，可以非常精确地基于其内容选择行。所述能力在处理数字数据中非常有用。可以基于匹配列值将来自不同表的数据结合在一起。可以进行有用类型的分析，例如在一个表中列出在相关表中遗漏的(或在相关表中呈现的，或具有指定属性的)对象。可以从一张大表中提取感兴趣的特定行，重新组合所述行，并对其产生简单的统计。
相反，不总是以固定的并且可预测的方式组织非结构化数据。非结构化数据以各种形状和格式被存储，在整个企业中分布，并由针对正在进行的任务最合适的软件进行管理。趋向于以自由文本格式记录数据(例如，包含于电子邮件、笔记和文档中的文本)，所述格式具有很少或没有编成字段的元数据。因此，搜索实际上是较少地参数化，而更多的是基于关键字的。搜索结果更多的是得自于“匹配”给定关键字集合，而很少得自于计算标准。
然而，希望以结构化方式查询非结构化数据，以将更多的值增加到结果集合中。将web看作可以使用标准SQL查询的关系数据库是有益的。同样重要的是，能够通过SQL接口统一地处理多个异构和非结构化数据源也是有益的，因此消除了数据集成的模糊性。
解决所述问题的常规技术是从非结构化数据源中提取预期数据，对数据应用任何必要的转换，然后将如此转换的数据放置到关系数据库中，以进行以后处理。实际上，这种仓储(warehousing)技术是现在针对各种应用所使用的一种通用方法。
然而，所述技术没有涉及使非结构化数据可用于参数化查询的构建(overarching)问题。
发明内容
我们通过用于参数化搜索非结构化数据的方法、系统和程序产品解决了上述问题。通过由扩展搜索协调器(Extended Search Broker)首先搜索非结构化数据，来搜索例如文本数据或图像数据的非结构化数据。扩展搜索协调器具有用于非结构化数据搜索的搜索请求者和搜索代理(agent)之间的中间部件。搜索代理返回搜索结果给协调器以进行聚集(aggregation)。协调器聚集搜索结果并将其返回给包装器(wrapper)。包装器然后从聚集的搜索结果中提取属性，并使所述属性作为别名(nickname)表中的一个或多个列。关系数据库使用结构化查询语言(SQL)可以搜索所述别名表。
本发明的一个方面是一种搜索非结构化数据的方法。所述方法包括通过扩展搜索协调器搜索非结构化的数据。所述扩展搜索协调器具有用于非结构化数据搜索的搜索请求者和搜索代理之间的中间部件。搜索代理返回来自搜索代理的搜索结果给协调器以聚集搜索结果到包装器中。接着，在别名表中输入结果属性，其中关系数据库使用结构化查询语言可以搜索所述别名表。
本发明的另一个方面是一种计算机系统，所述系统具有非结构化数据搜索系统、和结构化数据搜索引擎，两者由别名表在逻辑上或虚拟地结合在一起。计算机系统适用于启动通过结构化数据搜索引擎启动的非结构化数据的搜索。非结构化数据搜索系统包括用于非结构化数据搜索的扩展搜索协调器和搜索代理。非结构化数据搜索系统从搜索代理接收搜索结果，并发送搜索结果和搜索结果属性给扩展搜索协调器以聚集到包装器中。计算机系统适用于将包装器属性输入别名表中。结构化数据搜索引擎适用于在别名表中进行搜索结果属性的搜索。
本发明的又一个方面是一种计算程序产品，包括计算机可读代码以编程并配置计算机系统通过非结构化数据搜索系统搜索非结构化数据，所述系统包括用于非结构化数据搜索的扩展搜索协调器和搜索代理。程序产品还包括能够使搜索结果和搜索结果属性从搜索代理返回给协调器以进行聚集、并将搜索结果和搜索结果属性聚集在包装器中的代码。代码然后在别名表中输入搜索结果属性，作为别名表中的一个或多个列，其中关系数据库使用结构化查询语言可以搜索所述别名表，以搜索非结构化数据。
根据本发明，可以通过联合(federated)关系数据库引擎和扩展搜索引擎的组合来搜索非结构化数据，分别例如IBM DB2联合数据库和IBM Lotus扩展搜索。联合关系数据库引擎和扩展搜索引擎的组合提供了到在整个企业中分布的非结构化数据的关系接口。
RDBMS联合(federation)提供了可扩展体系结构，通过所述体系结构，内部和外部开发者可以编写包装器以集成外部数据源。联合RDBMS包装器是封装(或包装)所需原始API调用以从外部服务器取回数据的模块。当参考数据的相关联的别名表中的数据以在远端数据源上处理查询时，通过在SQL处理周期中各个点上的回调(callback)来激活包装器。
别名表是专门用于联合的特殊类型的RDBMS表。别名表不包括固定数据而是由包装器根据需要向其中填充数据。在本上下文中，别名表是虚拟表，并不真实存在于物理意义中，但是仍支持大多(或者全部)可以在SQL表达式中表达的表操作。
扩展搜索引擎，例如IBM Lotus扩展搜索，是这样一种产品，通过允许用户搜索和取回所有类型信息，而不仅是主机软件所管理的数据，“扩展”了其它搜索产品的标准能力。扩展搜索引擎是基于协调搜索技术(brokered search technology)的，所述技术提供了贯穿整个企业分布的数千数据源的高效的并行搜索。扩展搜索引擎代理以后端数据库系统的原始语法来执行远端搜索。代理返回结果给协调器，以进行聚集并递送给原始调用方(original caller)-在所述情况下是扩展搜索引擎包装器。
通过如上所述集成所述两种技术，可以实现几个好处。第一，通过扩展搜索引擎别名表的加载，包括实时加载，使得来自不同数据源类型集合的非结构化数据，对于RDBMS引擎而言为实时可用的。通过所述手段，数据是当前的并且是更新的。虽然其它联合包装器针对单个源提供了当前数据，但是仅有扩展搜索引擎包装器同时针对多个数据源启用这种能力。以这种方式，将扩展搜索引擎包装器接收的数据作为单个标准化的数据集合呈现出来，即使在其形成中包括了多个源。
第二个好处是数据保持分布在整个企业中，在逻辑上或虚拟地离执行工作的地点最近。扩展搜索引擎而不是关系数据库引擎负责搜索存储在不同位置上的数千数据源。与扩展搜索协调器结合使用的扩展搜索包装器作为所述大量非结构化信息的网关。
第三个好处是针对非结构化信息的聚集应用关系概念的能力。单独通过扩展搜索引擎不可能将接收于一个源的结果和接收于其它离散源的结果关联起来，以获取从属(subordinate)结果集合。例如，不可能基于匹配字段值将来自不同源的数据结合起来。扩展搜索引擎仅对返回数据执行聚集(类似于SQL中的UNION查询)，以产生单个的结果集合。但是，一旦通过扩展搜索引擎包装器，使得数据对于别名表为可用的，则通过RDBMS引擎，数据可以自由与数据库中任何其它表，包括其它别名表结合。
所述能力具有深远意义。通过使用本发明概念，针对可由扩展搜索引擎取回的每种不同类型的数据配置别名表，现在可以利用关系引擎的能力来轻易地在数据的主机环境之外集成所述数据。
本发明的一个方面是一种搜索非结构化数据的方法。所述方法包括通过扩展搜索协调器搜索非结构化的数据。所述扩展搜索协调器具有用于非结构化数据搜索的搜索请求者和搜索代理之间的中间部件。搜索代理返回来自搜索代理的搜索结果给协调器以聚集搜索结果到包装器中。接着，在别名表中输入结果属性，其中关系数据库使用结构化查询语言可以搜索所述别名表。
本发明的另一个方面是一种计算机系统，所述系统具有非结构化数据搜索系统、和结构化数据搜索引擎，两者由别名表在逻辑上或虚拟地结合在一起。计算机系统适用于启动通过结构化数据搜索引擎启动的非结构化数据的搜索。非结构化数据搜索系统包括用于非结构化数据搜索的扩展搜索协调器和搜索代理。非结构化数据搜索系统从搜索代理接收搜索结果，并发送搜索结果和搜索结果属性给扩展搜索协调器以聚集到包装器中。计算机系统适用于将包装器属性输入别名表中。结构化数据搜索引擎适用于在别名表中进行搜索结果属性的搜索。
本发明的又一个方面是一种计算程序产品，包括计算机可读代码以编程并配置计算机系统通过非结构化数据搜索系统搜索非结构化数据，所述系统包括用于非结构化数据搜索的扩展搜索协调器和搜索代理。程序产品还包括能够使搜索结果和搜索结果属性从搜索代理返回给协调器以进行聚集、并将搜索结果和搜索结果属性聚集在包装器中的代码。代码然后在别名表中输入搜索结果属性，作为别名表中的一个或多个列，其中关系数据库使用结构化查询语言可以搜索所述别名表，以搜索非结构化数据。
根据本发明，可以通过联合(federated)关系数据库引擎和扩展搜索引擎的组合来搜索非结构化数据，分别例如IBM DB2联合数据库和IBM Lotus扩展搜索。联合关系数据库引擎和扩展搜索引擎的组合提供了到在整个企业中分布的非结构化数据的关系接口。
RDBMS联合(federation)提供了可扩展体系结构，通过所述体系结构，内部和外部开发者可以编写包装器以集成外部数据源。联合RDBMS包装器是封装(或包装)所需原始API调用以从外部服务器取回数据的模块。当参考数据的相关联的别名表中的数据以在远端数据源上处理查询时，通过在SQL处理周期中各个点上的回调(callback)来激活包装器。
别名表是专门用于联合的特殊类型的RDBMS表。别名表不包括固定数据而是由包装器根据需要向其中填充数据。在本上下文中，别名表是虚拟表，并不真实存在于物理意义中，但是仍支持大多(或者全部)可以在SQL表达式中表达的表操作。
扩展搜索引擎，例如IBM Lotus扩展搜索，是这样一种产品，通过允许用户搜索和取回所有类型信息，而不仅是主机软件所管理的数据，“扩展”了其它搜索产品的标准能力。扩展搜索引擎是基于协调搜索技术(brokered search technology)的，所述技术提供了贯穿整个企业分布的数千数据源的高效的并行搜索。扩展搜索引擎代理以后端数据库系统的原始语法来执行远端搜索。代理返回结果给协调器，以进行聚集并递送给原始调用方(original caller)-在所述情况下是扩展搜索引擎包装器。
通过如上所述集成所述两种技术，可以实现几个好处。第一，通过扩展搜索引擎别名表的加载，包括实时加载，使得来自不同数据源类型集合的非结构化数据，对于RDBMS引擎而言为实时可用的。通过所述手段，数据是当前的并且是更新的。虽然其它联合包装器针对单个源提供了当前数据，但是仅有扩展搜索引擎包装器同时针对多个数据源启用这种能力。以这种方式，将扩展搜索引擎包装器接收的数据作为单个标准化的数据集合呈现出来，即使在其形成中包括了多个源。
第二个好处是数据保持分布在整个企业中，在逻辑上或虚拟地离执行工作的地点最近。扩展搜索引擎而不是关系数据库引擎负责搜索存储在不同位置上的数千数据源。与扩展搜索协调器结合使用的扩展搜索包装器作为所述大量非结构化信息的网关。
第三个好处是针对非结构化信息的聚集应用关系概念的能力。单独通过扩展搜索引擎不可能将接收于一个源的结果和接收于其它离散源的结果关联起来，以获取从属(subordinate)结果集合。例如，不可能基于匹配字段值将来自不同源的数据结合起来。扩展搜索引擎仅对返回数据执行聚集(类似于SQL中的UNION查询)，以产生单个的结果集合。但是，一旦通过扩展搜索引擎包装器，使得数据对于别名表为可用的，则通过RDBMS引擎，数据可以自由与数据库中任何其它表，包括其它别名表结合。
所述能力具有深远意义。通过使用本发明概念，针对可由扩展搜索引擎取回的每种不同类型的数据配置别名表，现在可以利用关系引擎的能力来轻易地在数据的主机环境之外集成所述数据。
附图说明
在附图中说明了本发明的特定实施例和示例。
图1说明各种硬件和软件平台，所述平台可能用在本发明的实施中。示出了两个终端用户客户端，其中一个通过World Wide Web和web服务器连接到数据服务器上，另一个客户端通过局域网连接到数据服务器上。Web服务器连接到两个关系数据库管理系统上，并且连接到扩展搜索服务器上，所述搜索服务器依次连接到两个非结构化数据库上。
图2是说明本发明的方法和系统的各种元件的框图，其中用户输入SQL查询到关系数据库管理系统中。关系数据库管理系统是联合关系数据库管理系统，并且使用具有扩展搜索协调器和代理的扩展搜索系统，来搜索非结构化数据。通过扩展搜索别名表和扩展搜索数据库来访问所述结果。
图3说明了通过使用结构化数据搜索引擎产生非结构化数据的查询以执行查询处理的方法。结构化数据搜索引擎输入查询到扩展搜索协调器中。扩展搜索协调器然后将查询传输给搜索代理，所述代理搜索非结构化数据，并返回搜索的结果，在包装器中聚集搜索结果。将结果属性分配给包装器，并且将结果属性输入到结构化数据搜索引擎可搜索的别名表中。结构化数据搜索引擎然后查询别名搜索表。
图1说明各种硬件和软件平台，所述平台可能用在本发明的实施中。示出了两个终端用户客户端，其中一个通过World Wide Web和web服务器连接到数据服务器上，另一个客户端通过局域网连接到数据服务器上。Web服务器连接到两个关系数据库管理系统上，并且连接到扩展搜索服务器上，所述搜索服务器依次连接到两个非结构化数据库上。
图2是说明本发明的方法和系统的各种元件的框图，其中用户输入SQL查询到关系数据库管理系统中。关系数据库管理系统是联合关系数据库管理系统，并且使用具有扩展搜索协调器和代理的扩展搜索系统，来搜索非结构化数据。通过扩展搜索别名表和扩展搜索数据库来访问所述结果。
图3说明了通过使用结构化数据搜索引擎产生非结构化数据的查询以执行查询处理的方法。结构化数据搜索引擎输入查询到扩展搜索协调器中。扩展搜索协调器然后将查询传输给搜索代理，所述代理搜索非结构化数据，并返回搜索的结果，在包装器中聚集搜索结果。将结果属性分配给包装器，并且将结果属性输入到结构化数据搜索引擎可搜索的别名表中。结构化数据搜索引擎然后查询别名搜索表。
具体实施方式
本发明有助于通过关系数据库管理系统使用结构化查询语言来搜索非结构化数据。本发明包括使用结构化查询语言和关系数据库管理系统通过扩展搜索协调器来搜索非结构化数据。扩展搜索协调器具有用于非结构化数据搜索的搜索请求者和搜索代理之间的中间部件。搜索代理返回其搜索结果给扩展搜索协调器，以聚集搜索结果到具有结构化查询语言可搜索属性的包装器中。将包装器属性输入到别名表中，其中关系数据库使用结构化查询语言可以搜索别名表。
本发明的另一个方面是一种计算机系统，所述计算机系统具有至少两个搜索引擎，一个是非结构化数据搜索引擎，另一个是结构化数据搜索引擎。别名表在逻辑上，即虚拟地将所述搜索引擎结合在一起。计算机系统适用于通过非结构化数据搜索引擎和结构化数据搜索引擎的别名表的协同交互，来进行非结构化数据的搜索。
本发明的另一个方面是一种计算机程序产品，所述产品包括计算机可读代码，所述代码用于编程和配置计算机系统，以通过非结构化数据搜索系统，从用于结构化数据的关系数据库管理系统中搜索非结构化数据，所述非结构化数据搜索系统包括扩展搜索协调器，所述扩展搜索协调器具有非结构化数据搜索的搜索请求者和搜索代理之间的中间部件。所述程序产品还包括代码，所述代码能够使来自搜索代理的搜索结果返回给协调器以进行聚集，并将搜索结果和搜索结果属性聚集在包装器中。所述代码然后将结果属性输入到别名表中，其中关系数据库使用结构化查询语言可以搜索别名表以搜索非结构化数据。
联合关系数据库管理系统和扩展搜索系统的集成系统
根据本发明，通过联合关系数据库引擎和扩展搜索引擎之间的组合和交互来搜索非结构化数据，所述引擎例如为IBM DB2联合数据库和IBM Lotus扩展搜索。联合关系数据库引擎和扩展搜索引擎的组合提供了对可能贯穿整个企业分布的非结构化数据的关系接口。
RDBMS联合提供了可扩展体系结构，内部和外部开发者可以通过所述体系结构编写包装器以集成外部数据源。联合的RDBMS包装器是封装(即包装)所需原始API调用以从外部服务器上取回数据的模块。当参考相关联别名表中的数据时，通过在SQL处理周期中战略(strategic)点上的回调来激活包装器。
别名表是专门用于数据库联合的特定类型的RDBMS表。别名表不包括固定数据而是由包装器根据需要向其中填充数据。在本上下文中，别名表是虚拟表，并不真实存在于物理意义中，但是仍支持大多数(或者全部)可以在SQL表达式中表达的表操作。
扩展搜索引擎，例如IBM Lotus扩展搜索，是一种产品，所述产品通过允许用户搜索和取回所有类型信息，而不仅是主机软件所管理的数据，“扩展”了其它搜索产品的标准能力。扩展搜索引擎是基于协调搜索技术的，所述技术提供了贯穿整个企业分布的数千数据源的高效的并行搜索。扩展搜索引擎代理以后端数据库系统的原始语法来执行远端搜索。代理返回结果给协调器，以进行聚集并递送给原始调用方-在所述情况下是扩展搜索引擎包装器。
在附图中说明了本发明的特定实施例和示例。
图1是说明各种硬件和软件平台的框图，所述平台可以用在本发明的一个实施示例中。示出了两个终端用户客户端101和102，其中一个101通过World Wide Web 105和web服务器111连接到数据服务器121上，另一个客户端通过局域网连接到数据服务器121上。Web服务器111连接到两个关系数据库管理系统131、132上，并且连接到扩展搜索服务器141上，所述搜索服务器141依次连接到两个非结构化数据库服务器151和152上。非结构化数据库服务器151或152可能包括一个或多个非结构化数据库，以及可选地是web客户端，其中另外的web服务器和数据服务器的组合包括将被搜索的非结构化数据。
图2是说明本发明的方法和系统的各种元件的框图，其中用户201输入SQL查询202到关系数据库管理系统203中。关系数据库管理系统203是联合关系数据库管理系统，并且使用具有扩展搜索协调器204和代理205、205’的非结构化数据搜索系统，来搜索非结构化数据206和206’。结果存储在扩展搜索别名表207和扩展搜索数据库208中。
图3说明了在步骤301中通过使用结构化数据搜索引擎产生非结构化数据的查询以执行查询处理的方法。在步骤303中结构化数据搜索引擎将查询输入到包括扩展搜索协调器的非结构化搜索系统中。在步骤305中扩展搜索协调器然后将请求传输给搜索代理，在步骤307中所述代理搜索非结构化数据，并在步骤309中返回搜索的结果和结果属性，在步骤311中将搜索结果和结果属性聚集到包装器中。在步骤313中将结果属性分配给包装器，并且在步骤315中将结果属性输入到结构化数据搜索引擎可搜索的别名表中。结果属性被输入到别名表中，作为一列。在步骤317中结构化数据搜索引擎然后查询别名搜索表，并返回查询结果给请求者。
通过如上所述集成联合数据库和扩展搜索技术，可以实现几个好处。第一，通过扩展搜索引擎别名表的加载，包括实时加载，使得来自不同数据源类型集合的非结构化数据，对于RDBMS引擎而言为实时可用的。呈现给结构化数据库搜索引擎(关系数据库管理系统)的数据是当前的并且是更新的。虽然其它联合包装器针对单个源提供了当前数据，但是仅扩展搜索引擎包装器同时针对多个数据源启用该能力。以这种方式，将扩展搜索引擎包装器接收的数据作为单个标准化的数据集合呈现出来，即使在其形成中包括了多个源。
第二个好处是数据保持分布在整个企业中，逻辑上离执行工作的地点最近。扩展搜索引擎而不是关系数据库引擎负责搜索存储在不同位置上的数千数据源。与扩展搜索协调器结合使用的扩展搜索包装器作为所述大量非结构化信息的网关。
第三个好处是针对非结构化信息的聚集应用关系概念的能力。单独通过扩展搜索引擎不可能将接收于一个源的结果和接收于其它离散源的结果关联起来，以获取从属结果集合。例如，不可能基于匹配字段值将来自不同源的数据结合起来。扩展搜索引擎仅在返回数据上执行聚集，以产生单个的结果集合。但是，一旦通过扩展搜索引擎包装器，使得数据可用于别名表，则通过RDBMS引擎，数据可以自由与数据库中任何其它表，包括其它别名表结合。
所述能力具有深远意义。通过使用本发明概念，针对可由扩展搜索引擎取回的每个不同类型数据配置别名表，现在可能使用关系引擎的能力来轻易地在数据的主机软件之外集成所述数据。
说明示例
通过举例的方式，假设智能代理试图识别可能是潜在恐怖分子的个人。在所述代理能够访问各种敏感源的情况下，他们可能提出如下问题：“列出下述人员的姓名：所述人员在一定时间内获得签证、从这些天起购买了大量化肥、与有关炸药制造的人员进行过e-mail通信、并且申请了B类(卡车)驾照。”
需要搜索的源是很多的，并且具有各种等级的结构。然而每个源具有可以用于执行结合(join)的人员的概念(通过姓名标识)。扩展搜索系统将用来执行到远端数据源的协调搜索(brokered search)以及返回合适的数据，但是然后将依赖于关系引擎以执行结合。为了进行结合，需要将数据组织成为分离的别名表，每类要搜索的数据源使用一个表。
上述例子中需要4个别名表。配置一个别名表来代表e-mail结果，另一个别名表代表驾照信息，另一个代表化肥购买，还一个代表签证申请。每个别名表与一个或多个类似目的的扩展搜索源相关联。例如，应用于驾照别名表的查询可能实际上导致了50个机动车辆注册数据源(每个州一个)的扩展搜索。
假设每个别名表将包括针对个人姓名的外来关键字(foreignkey)，执行结合将基于所述个人姓名。扩展搜索字段映射将用来通过后端源(此后将详细解释)中遇到的语句构成不同，来标准化别名表中的外来关键字。给定以所述方式配置所述4个别名表，则现在可能在SQL中提出如下询问：
表格：签证
名 姓 日期 国家
Bill Stalwart 09/05/2001 德国
Mary Boutreaux 07/21/2001 法国
Ali Mohammed 09/10/2001 伊拉克
表格：驾照
名 姓 日期 类型 州
Bill Stalwart 09/05/2001 A MD
Mary Boutreaux 07/21/2001 A NY
Ali Mohammed 09/10/2001 B CA
表格：邮件
来自 发往 日期 内容
Bill Stalwart sally cruthers 09/05/2001 邮件文本
Mary Boutreaux MartinJones 09/05/2001 邮件文本
Ali Mohammed Mark Billsman 09/05/2001 邮件文本
表格：购买
名 姓 日期 描述 金额
Bill Stalwart 09/05/2001冰箱$673.00
Ali Mohammed 09/05/2001化肥$2230.00
SELECT N1.FirstName，N1.LastName
FROM INS as N1，
DRIVER as N2，
EMAIL as N3，
FERTILIZER as N4
WHERE ES_SEARCH(N1.DOC_RANK，‘DATE_OF_ISSUE＞＝
“01/01/2000”’)＝1AND
ES_SEARCH(N2.DOC_RANK，‘LICENSETYPE＝“B”)＝1
AND
ES_SEARCH(N3.DOC_RANK，‘DOCUMENT TOKEN“bomb”
and DOMCUMENT TOKEN“fabrication”’)＝1
AND
ES_SEARCH(N4.DOC_RANK，‘ProductType＝“FERTILIZER”
and Quantity＞500and
Date＞“01/01/2000”’)＝1
AND
N1.LastName＝N2.LastName AND
N2.LastName＝N3.LastName AND
N3.LastName＝N4.LastName
如前面提到的，扩展搜索具有将通用字段名映射到后端上一个或多个语义上相同但是句法不同的字段的能力。在从别名表中产生有意义的数据模型中，这将是非常有用的。
例如，50个驾照数据库中的个人姓名的符号标识大多可能不同，特别是由于各个州自由构建它们自己的MVA数据库。通过扩展搜索，可以定义持照者名称的单个字段，并将其映射到驾照数据库中合适的原始字段。然后在驾照别名表中可以使用针对持照者名称单个映射的字段。如果没有该映射特征，将被迫在后端数据库中为每个唯一定义的名称字段定义一个别名列。所述表将水平增长出许多列，并且将不会为第3种正常形式。由于任何一行一次仅填充一个姓名列，则将稀疏地填充所述表。
然而存在可能利用来自许多离散数据源的大量字段的应用。对于所述应用，数据(特别是非结构化数据)之间的关系不是预先已知的，因此定义和结构化别名表是非常困难的。通过填充所谓的垂直别名表，扩展搜索可以支持所述类型应用。
垂直别名表包括4个预定义列。它们是：字段名称、字段值、字段类型和源名称。不是使用前面例子建议的映射字段，而是通过使扩展搜索返回原始字段名称/值对来进行反向操作。也返回元数据，例如字段类型(例如日期、整数等)和数据的来源。现在密集地通过许多数据行填充了别名表-针对每个数据源的每个字段使用一行。
但是如何在关系模型中使用这些垂直别名表？假设相同的智能代理询问一系列问题，所述问题有助于所述代理发现数据之间的有用关系，而不管所述数据从何处而来。所述代理已经建立了扩展搜索系统，以在上千个具有自己的数据模型和字段集合的各种类型数据源上进行查询。在不知道哪些字段将与你的搜索有关的情况下，可以配置扩展搜索来搜索并返回所有字段。以刚才所述的垂直格式返回这些字段。
现在智能代理可以使用关系引擎来发现并分析数据关系自身。所述代理可能要求包含词“化肥”的所有字段，通过数据源名称排列结果。
联合关系数据库管理系统
联合数据库管理系统，也称作联合数据库系统或联合系统，是其中每个数据库服务器是自治并且独立的集中的DBMS的系统，所述DBMS具有自己的本地用户、本地业务、数据库管理员并且因此具有高度的本地自治性。在联合数据管理系统中，每个单独服务器可以通过指定“输出计划(export schema)”来授权其服务器的指定部分的访问，所述输出计划指定可以由非本地用户的指定集合访问的其数据库部分，以及所述非本地用户具有的规范。在联合数据库管理系统中，用户基本上是到几个本地数据库管理系统的额外接口，由此允许全局用户访问多个本地、自治数据库。
联合数据库管理系统，例如IBM DB2全球数据库联合系统，支持提交SQL语句的应用和用户，其中在单个语句中引用两个或多个DBMS或数据库。一个例子是两个不同DB2数据库中的表之间的结合。这种语句称作分布式请求。
DB2全球数据库联合系统提供对数据库和DBMS的分布式请求的支持。用户例如可以在DB2表和Oracle视图之间执行UNION操作。
联合数据库管理系统，例如IBM DB2联合系统。提供数据库对象的位置透明度。如果移动了信息(在表中和视图中)，可以更新对所述信息的参考(称作别名)，而无需对请求所述信息的应用的任何改变。联合数据库管理系统的另一个方面是数据源的补偿，所述数据源不支持所有特定SQL方言(dialect)、人为缺陷(artifact)、或相互之间的特定优化能力。在所述DBMS下不能执行的操作(例如，不能实现GROUP BY条款的文件系统)在DB2下运行。
可以提交半自治方式的联合系统功能，即包含对Oracle对象的参考的IBM DB2查询，而同时Oracle应用访问相同的服务器。联合系统不会独占或限制访问(除了完整性和锁定限制)远端数据源上的其它对象。
在IBM DB2全球数据库联合系统的情况下，所述系统包括IBMDB2UDB实例，一种将作为联合数据库的数据库以及一个或多个数据源。联合数据库包括标识数据源和它们特征的目录条目(catalogentries)。数据源包括DBMS和其数据。应用连接到联合数据库上，正如连接到任何其它数据库一样。
联合数据库目录条目包括关于数据源对象的信息：被称作什么，包括了什么信息，在什么条件下可以被使用。由于联合数据库目录存储了关于许多数据源中的对象的信息，所以被称作全局目录。对象属性被存储在目录中。被引用的实际数据源、用于与数据源通信的模块以及将访问的DBMS数据对象(例如表)在数据库之外。在这方面，应当注意到一个例外是联合数据库可以是联合系统的数据源。具体地，IBM DB2支持远端数据源和远端DBMS的联合。
可以使用例如IBM DB2UDB控制中心或SQL数据定义语言(“DDL”)语句来产生联合对象。作为通用规则，所需联合数据库对象是包装器、服务器和别名。包装器识别用于访问特定类别的数据源的模块(DLL、库等等)。在本上下文中，服务器定义数据源。服务器数据包括包装器名称、服务器名称、服务器类型、服务器版本、授权信息、和服务器选项。别名是在联合数据库中存储的标识，所述标识参考了特定的数据源对象(表、化名、视图)。应用程序在查询中参考了别名，正如参考表和视图一样。
在建立了联合系统之后，可以访问数据源中信息，就像所述信息在一个大的数据库中一样。用户和应用程序发送请求给一个联合数据库，如果需要，所述数据库然后从DB2家族和Oracle系统中取回数据。用户和应用程序在查询中指定了别名；所述别名提供了对位于数据源中的表和视图的参考。从终端用户的角度出发，别名类似于化名(aliase)。
许多联合系统在一些限制之下操作。例如，分布式请求可能被限制为只读操作。在一些联合系统中，不能针对别名执行实用操作(LOAD，REORG，REORGCHK，IMPORT，RUNSTATS等等)。然而，请求者可以使用传递工具(pass-through facility)来通过使用与所述数据源相关联的SQL方言，将DDL(数据定义语言)和DML(数据处理语言)语句直接提交给数据库管理者。
联合系统容忍并行环境。性能增益受到联合数据库查询可以在语义上被分解为本地对象(表、视图)参考和别名参考的程度。连续处理别名数据的请求；可以并行处理本地对象。例如，给定查询
SELECT＊FROM A，B，C，D
其中A和B是本地表，而C和D是引用Oracle数据源上的表的别名，一个可能的计划是通过并行结合来结合表A和B。然后将结果与别名C和D顺序结合。
扩展搜索引擎和扩展搜索应用
扩展搜索引擎通过允许终端用户搜索并取回所有类型信息，而不仅是主机软件所管理的数据，“扩展”了其它搜索产品的标准能力。例如，使用标准web浏览器，终端用户可以轻易地并且迅速地定位和阅览包含于散布在组织中的数千数据仓库中的信息。所述仓库可能是各种内容和结构，并且所述仓库可能在地理上散布于全球。
通过单个查询，终端用户可以同时搜索内部和外部web站点、全文索引、Microsoft索引、文档管理系统、e-mail系统、文件系统、关系数据库、LDAP目录和Lotus数据库的完全补充。扩展搜索引擎可以被认为是代表用户进行工作的协调代理(brokered agent)；所述引擎搜索原始形式的每个数据储备(data store)，并在单个聚集结果集合中返回结果。
扩展搜索引擎对终端用户屏蔽数据源多样性。这是因为终端用户与单个、通常是功能丰富的扩展搜索引擎接口进行交互，所述接口将终端用户搜索透明地分发给潜在的数千个不同种类的数据储备。可以以各种方式呈现结果。
比起终端用户从典型搜索应用中所期待的，通过扩展搜索，终端用户经历了更多。终端用户发现其触及范围已经进一步扩展到企业中，并且可以访问以前不能轻易获得的信息。
几乎所有搜索系统都包括对将要搜索的信息进行分类的索引的使用。如果没有索引，执行搜索的时间将大大增加，很像在没有卡片目录的情况下试图在图书馆中查找一本书。但是虽然大多搜索解决方案需要终端用户重新索引信息到一个新的索引中，但是扩展搜索引擎，例如IBM Lotus扩展搜索，影响了(leverage)企业的当前数据管理投资。
应注意企业信息通常以许多外形和形式存在，并且贯穿整个企业分布，以及对于正在进行的任务通常由任务特定软件进行管理。扩展搜索引擎，例如IBM Lotus扩展搜索，进入数据源和数据访问模式的迷宫，并将现有的集合处理为一个具有单个入口(entry)点的虚拟索引。
不管入口的模式，扩展搜索引擎将查询转化为目标数据源的原始搜索语言，并使用对于每个数据源是原始的搜索和取回方法来返回结果。
但是需要认识到，不是相同地产生后端数据源，所述数据源可以具有完全不同的体系结构、方法、方案、元数据和能力(例如全文本索引vs.关系数据库vs.e-mail系统)。任何可能的时候，扩展搜索工具和引擎试图最小化所述不同，并获得大于最小公分母的效果。
例如，在查询多个数据源中，扩展搜索引擎，例如IBM Lotus扩展搜索，可能针对一个数据源合并两个或多个操作，以达到在对一个不同源的单个操作中可获得的效果。所述技术使用户可以通过单个查询并行搜索多个数据源，所述数据源具有不同类型、体系、结构、能力和格式。通过所述手段，可能维护原始数据库或搜索引擎的机制，并保留信息的完整性和流通性，同时避免将分散数据复制成集中索引，以减少整体存储需求并消除重新索引资源的花费和开销。此外，数据保持与正在执行的工作的近距离(逻辑上和虚拟上)，并且各个数据特定的和任务特定的数据源和搜索引擎可以并行执行搜索操作，由此改善搜索响应时间。
扩展搜索引擎范例也提供了比围绕集中索引构建的多个数据源范例更大的可缩放性。随着域内文档数目的增加，索引信息所需的时间也增加了。对较大域的索引使得搜索不可实现的情况并不少见。
在这种情况下，扩展搜索引擎的能力补充了索引的深度：首先，将索引稳定在最大容量上，然后结合其它数据储备来搜索索引。通过这种技术，终端用户可以仅对需要索引的内容进行索引，同时使用扩展搜索引擎来搜索索引的和非索引的源。
连接新的源到搜索域中使得扩展搜索引擎引起的开销较小，并且当与实际搜索操作自身的花费进行比较时，这将是可忽略的。由于使用现有搜索操作在已经存在于网络(互联网或内部网)中的一个或多个机器上执行搜索，因此连接新的源的增加花费是可忽略的。
扩展搜索引擎通过使用企业现有数据管理软件，实现了访问企业的所有信息的策略，无论其处于什么位置。通过这个策略，造成了固有的事实，即，不是所有的后端数据源被生成为相同的数据源。存在通用区域，其中大多系统在搜索和取回方面有所不同。建立在这些共性上，扩展搜索引擎提供了通用平台(ground)，使系统实现者能够在以下领域互补工作：(1)搜索语言，即如何表达查询；(2)数据模型支持，即如何组织、关联和呈现数据；(3)应用程序接口(API)支持，即如何执行信息访问。
至于搜索语言，几乎所有数据管理系统都使用某种语法或查询语言来表达搜索标准。根据数据的结构和成分，所述语法可能大大地不同。例如，在例如web的自由文本系统中，例如通常将搜索表达为关键字列表。使用额外的概念，以表达boolean条件(与，或，非)或位置信息，例如必须在相同句子或段落中出现的特定词。通过比较和对比的方式，如果数据被高度地整理和结构化了，则语法可能是更加参数化的，并且可能支持字段化操作(例如，数量字段的值大于100)。
显然，对于用户而言，知道扩展搜索中使用的搜索语法的全部集合的句法是不现实的。让用户以单个通用搜索语言来表达查询是更易实现的。在IBM Lotus扩展搜索中，通用语言是通用化查询语言(GQL)。可以将该语言当成能够表达大多查询的搜索语法的扩展集。
以GQL格式内部表达所有IBM Lotus扩展搜索查询(除了将要简要讨论的“传递”查询)。当GQL表达式到达特定数据源时，扩展搜索将其转变为所述源的原始查询语言。所述转变处理将GQL的词汇元素映射到原始语法的等同元素上。
虽然IBM Lotus扩展搜索的所有部件支持全部的GQL语法，但是不是所有后端搜索引擎能够支持GQL语法的所有元素。当扩展搜索引擎，例如IBM Lotus扩展搜索，遇到所述不一致时，所述搜索引擎通过合并两个或多个原始操作来试图补偿，以到达相同的效果。只有在扩展搜索引擎已经用尽所有可选方法之后，才忽略表达式的不支持部分。在所述情况下，终端用户可以替代地传递不能得到转换的查询。
通用数据模型
正如搜索语法可以随每个不同的后端系统而不同一样，数据模型可以用来组织和存储信息。典型地针对其所服务的应用等级来设计特定数据管理系统使用的数据模型。这确定了其信息中所得到的结构和粒度的程度。
例如，自由文本系统往往使用具有低数据粒度的松散结构化的文档模型。文档可能包括几个字段(例如标题、作者和正文)，但是文档的文本保持形式自由，并且是非结构化的。通过比较，可以高度结构化信息，例如在关系数据库中所得到的。这里，将数据组织为可以以任意种方式相关联的行和列，这导致了很高的数据粒度。
现代扩展搜索引擎，例如IBM Lotus扩展搜索，将不同数据模型集合标准化为单个模型，所述单个模型易于理解并可由大多搜索应用所使用。搜索应用设计者仅需要与这一个数据概念模型进行竞争，而不会被许多模型所混淆。
通常将源映射到常规意义的数据库上，但是可以将源轻易地映射到web站点上、文件系统目录上、或LDAP体系中的节点上。同样地，将文档方便地映射到基于文本的但是可以轻易地表示数据示例的所述系统上，所述数据示例例如是关系数据库的表中的一行。
在将不同类型的数据源相关联时，通常遇到的问题是，字段标签不匹配。例如，作者名在一个数据源中可能被标记为AUTH NAME，在另一个中标记为CREATOR，而在另一个中表示为3个字段(名、中间首字母、姓)。
通用数据模型的重要特征是定义映射字段的能力。映射字段是一个或多个原始字段的合成。为了解决前面例子中的模糊问题，终端用户可以定义具有标签AUTHOR的单个映射字段。终端用户然后可以映射所述字段到支持作者姓名的语义的每个数据源中一个或多个原始字段上。
当在搜索表达式中使用所述特征时，所述特征的好处是令人信服的。用户仅需要在查询中指定映射字段。IBM Lotus扩展搜索将在后端自动将映射的字段与正确的原始字段相关联起来。所述技术大大简化了查询表达式，并当数据源的数目增加时，提供了更多的好处。
为了说明所述特征，考虑将要显示指示器(barometer)的应用的情况，测量所述指示器以反映文档的使用年限(即，文档越新，将具有越高的指示器读数)。如果在每个后端源中不同地标记了“产生日期”的字段，则该应用将需要一个穷尽的条件语句集合，每一个针对每个离散的日期字段名称。但是，通过映射字段，仅需要识别一个映射的“产生日期”字段，以便取回并对其进行后续测试。通过参考所述单个映射字段，结果将包含正确的日期值，因为其与源的原始日期值相关联。
在另一方面，如果结果来自e-mail系统，终端用户可能希望返回日期、主题和作者。可以通过使用原始源字段标识，选择性地取回这些语义不同的数据字段。当原始字段标记对于显示目的而言太过保密(例如$Doc Abstract)，则再次将映射的字段用作原始字段名称的化名(例如，Document Abstract)。
扩展搜索引擎的另一个方面是通用API的提供。通用API回答了“我如何与所有这些不同的后端系统交互，以搜索并取回它们的管理信息？”的问题。通过调用方法、句法、语法和编程语言，每个后端系统的API可以大大不同。通过扩展搜索引擎通用接口发布的功能由系统自动转换为后端系统的原始方法，非常类似于转换GQL为原始搜索语法的过程。
扩展搜索引擎寻求以可能的最佳方式与后端上每个不同机制接口，以获得所有数据源之间的最佳平衡，并同时考虑到每个原始搜索API的操作策略。通过使用主机软件的公布的API，保持了数据源的完整性和安全性。
为了获得所述可通信性，针对每类后端数据源产生链路模块，并使用所述模块来封装所述类型所需的所有原始API调用。
使用基于代理的技术来将这些链路模块应用到它们的各数据源中。代理代表协调搜索工作，并通常是透明的(将在后面更详细地描述链路和代理)。从设计者的角度，终端用户通过单个API与一个可搜索的后端系统接口。
在IBM Lotus扩展搜索的情况下，可获得两种形式的通用API。第一种并且是最灵活的一种是Java bean接口。通过所述方法，bean与Java编程语言的能力相结合，以开发宽广范围的从简单到高复杂度并且专门化的搜索和取回应用程序。该产品展示了这些bean在使用JavaServer Page(JSP)的示例web应用程序中的使用。
或者，可以使用一组类似HTML的标签，其允许终端用户将扩展搜索引擎功能嵌入到新的或现有的web页面中。这些便于使用的标签可以授权web管理员并且使用户可以输入指定各种搜索选项的查询。终端用户可以在web页面的任何地方嵌入扩展搜索引擎标签，所述标签不与周围的HTML标签相干扰。
可以以各种方式呈现来自扩展搜索应用程序的搜索结果。作为配置系统的一部分，可以编程并配置系统，以确定允许用户查询、在结果页面上观看以及从数据源种取回哪些字段。向用户呈现包含来自多个源的结果的单个、合并的页面。针对关联性对所述列表进行预先剪裁(pre-pruned)，因此保证了用户首先看见最匹配的。
扩展搜索系统的特征在于可缩放性。具体地，例如IBM Lotus扩展搜索的扩展搜索系统的分布式部件体系结构，提供了根据变化的需求对系统进行缩放的灵活性。它也允许以与环境匹配的拓扑结构安排扩展搜索引擎部件，使得终端用户可以根据需要来混合IBM AIX、SunSolaris、Windows 2000和Windows NT平台。
示例性可缩放扩展搜索体系结构包括：
纵向上，在单个扩展搜索服务器中，终端用户可以配置多个服务器处理实例，以影响服务器可以处理的同时请求的数量。
横向上，通过多个机器，终端用户可以建立额外的扩展搜索服务器以及额外的web服务器。对于每个扩展的搜索服务器，终端用户可以确定终端用户希望运行的服务器任务类型。通过拥有多个服务器，终端用户可以分布和均衡处理负载。
扩展搜索体系结构
20世纪末期所经历的巨大经济增长归功于信息技术所获得的进步以及投资信息技术的那些公司。由于技术原来(并且现在仍然)以惊人的速度在改变，公司频繁地投资并再投资他们的信息技术(“IT”)预算到不断进化的产品中，以管理他们的信息。这样做的结果经常是，贯穿整个组织分布的信息岛--针对正在进行的任务是高度专门化的，但是不易基于企业范围对所述信息进行访问。即使一个公司能够决定企业的通用IT策略，但是使用不同IT体系结构的公司的单次收购将会阻碍所述策略。
这里构想的由IBM Lotus扩展搜索例示的扩展搜索引擎，具有多层设计。例如，IBM Lotus扩展搜索系统使用4层体系结构。消息开始于第一层中的搜索应用程序，并通过后续的层连续进行到后端。在大多情况下，后端是IBM Lotus扩展搜索所连接到的第三方数据源，但是后端也可以是扩展搜索配置数据库(CDB)、由关系数据库管理系统所管理的私有后端，例如IBM DB2RDBMS。
层间的消息流可以分割为两个基本类别：
运行时间消息，这是通常由用户团体所发布的消息，以执行搜索并取回文档。
管理消息，这是由管理员发布的，并导致配置数据库的更新。
链路是将针对搜索和取回的原始API调用封装到特定数据管理系统的软件模块。它们包括与后端数据系统接口所需的所有数据结构、编程对象和程序逻辑。
单独地组装一个链路模块以支持(最小化)通常存在于所有数据管理系统中的可调用方法：
连接到主机系统并从主机系统断开连接的方法
从系统中搜索内容并取回数据的方法
对于后端源不支持的方法，链路模块执行空操作。例如，文件系统搜索不支持连接和断开连接的概念。
转换器(translator)是负责将进入的GQL表达式转换为后端数据系统的原始搜索语法的软件模块。它们也包括产生句法正确的搜索表达式所需的所有数据结构、编程对象和分析逻辑。
在一些情况下，同一转换器模块应用于几个不同后端系统，和SQL转换器和许多各种支持标准SQL语法的系统的情况一样。
代理是响应旨在特定数据源的搜索和取回操作的程序。当第一次提出针对特定数据源类型的请求时，代理加载合适的链路和转换器模块。代理然后调用用于进行转换(XLAT)、连接、断开连接、搜索和取回操作的这些模块库。
对于搜索操作，代理将按照相关度等级来对结果集合进行分类(sort)，然后将集合截取(truncate)为最大数量的命中(hit)，如原始搜索请求中所指定的。所述命中列表的分类和随后的截取是聚集的重要前期操作(precursor)，将对其进行简要讨论。
代理可以位于与数据源相同的机器上(推荐)，或使用数据源的远端API进行访问。可以在单个计算机上运行代理的不止一个拷贝，以处理同时的搜索和取回请求。一个代理可以用于单个数据源、特定类型的一组源或具有混合链路需求的某一范围的源上。
协调器是存在于服务请求者和通过后端实际执行服务的代理之间的中间部件。协调器作为特殊用途资源协调者进行工作，被设计用来管理从单个请求产生的，例如由类别搜索(category search)引起的多个搜索。
协调器典型地执行下面任务：
验证请求。
扩展类别以获得应用程序可用的数据源列表，并解析源地址。(标记1)
将查询分发给代理，以进行高效、并行的搜索。(标记2)
将由各个代理返回的搜索结果聚集并任意分类为单个搜索结果集合。(标记3)
高速缓存搜索结果，以进行后续分页(paging)的操作。(标记4)
向代理发布请求，以便为用户取回源文档(注意到在大多情况下，web浏览器使用在结果列表中返回的URL，以取回文档)。
示意超时(timeout)和响应选项。
在引起单个请求的后端系统的大的集合中，响应程度可能大大不同。一些数据管理系统比其它系统响应的快，而一些则不，-可能由于服务条件之外的原因。为了解决这种情况，协调器被设计为与它们的代理异步通信。
为了支持性能和可缩放性，扩展搜索系统可能包括多个协调器。这种建立协调器体系的能力，连同建立与所支持的源共同存在的代理的能力，或指定代理到特定源或源的类型的能力，为扩展搜索系统，例如IBM Lotus扩展搜索，提供了关于改变和扩展环境的无穷灵活性。在多个协调器的方案下，源被所有协调器分区，这是一种防止任何一个协调器被淹没(overwhelm)的设计。
在单个协调器环境中，针对6打源的搜索将导致72个查询被发送给远端机器，以及72个搜索结果集合返回给协调器。如果每个结果集合包括最大数量的结果，则当协调器合并和聚集返回给请求者的列表的数据时(协调器截取结果，并仅保持顶部项目，直到搜索应用所允许的最大数量)，将丢弃大多数据。
通过多个协调器，入口(entry)协调器发送单个消息给远端机器的协调器。远端协调器然后将该消息分离为针对它们各自机器上的源(由代理所指向)的多个请求。不是将所有结果集合返回给一个协调器，而是每个协调器合并、聚集并剪裁由其代理返回的结果，并然后仅将单个列表-包含顶部命中-返回给入口协调器。入口协调器仅需要从其自己的本地源中产生最终结果集合，以及由远端协调器返回的合并的列表。
协调器从扩展搜索应用的配置数据库中获得关于其管理的资源的信息。所述数据库包括关于数据源以及应该如何搜索数据源的信息。所述数据库也存储网络地址、保存的查询、保存的搜索结果以及webcrawler下载的数据。
终端用户通过使用直观(intuitive)管理接口，可以轻易地更新关于网络拓扑、数据源和搜索应用的信息。所述接口也提供网关，终端用户通过所述网关可以运行发现(下面讨论)、观看错误消息和事件数据、调度查询，和利用保存的查询和搜索结果工作。
虽然已经关于一定的优选实施例和示例描述了本发明，但是这不是旨在由此限制本发明的范围，本发明的范围仅由后附的权利要求限定。
本发明的另一个方面是一种计算机系统，所述计算机系统具有至少两个搜索引擎，一个是非结构化数据搜索引擎，另一个是结构化数据搜索引擎。别名表在逻辑上，即虚拟地将所述搜索引擎结合在一起。计算机系统适用于通过非结构化数据搜索引擎和结构化数据搜索引擎的别名表的协同交互，来进行非结构化数据的搜索。
本发明的另一个方面是一种计算机程序产品，所述产品包括计算机可读代码，所述代码用于编程和配置计算机系统，以通过非结构化数据搜索系统，从用于结构化数据的关系数据库管理系统中搜索非结构化数据，所述非结构化数据搜索系统包括扩展搜索协调器，所述扩展搜索协调器具有非结构化数据搜索的搜索请求者和搜索代理之间的中间部件。所述程序产品还包括代码，所述代码能够使来自搜索代理的搜索结果返回给协调器以进行聚集，并将搜索结果和搜索结果属性聚集在包装器中。所述代码然后将结果属性输入到别名表中，其中关系数据库使用结构化查询语言可以搜索别名表以搜索非结构化数据。
联合关系数据库管理系统和扩展搜索系统的集成系统
根据本发明，通过联合关系数据库引擎和扩展搜索引擎之间的组合和交互来搜索非结构化数据，所述引擎例如为IBM DB2联合数据库和IBM Lotus扩展搜索。联合关系数据库引擎和扩展搜索引擎的组合提供了对可能贯穿整个企业分布的非结构化数据的关系接口。
RDBMS联合提供了可扩展体系结构，内部和外部开发者可以通过所述体系结构编写包装器以集成外部数据源。联合的RDBMS包装器是封装(即包装)所需原始API调用以从外部服务器上取回数据的模块。当参考相关联别名表中的数据时，通过在SQL处理周期中战略(strategic)点上的回调来激活包装器。
别名表是专门用于数据库联合的特定类型的RDBMS表。别名表不包括固定数据而是由包装器根据需要向其中填充数据。在本上下文中，别名表是虚拟表，并不真实存在于物理意义中，但是仍支持大多数(或者全部)可以在SQL表达式中表达的表操作。
扩展搜索引擎，例如IBM Lotus扩展搜索，是一种产品，所述产品通过允许用户搜索和取回所有类型信息，而不仅是主机软件所管理的数据，“扩展”了其它搜索产品的标准能力。扩展搜索引擎是基于协调搜索技术的，所述技术提供了贯穿整个企业分布的数千数据源的高效的并行搜索。扩展搜索引擎代理以后端数据库系统的原始语法来执行远端搜索。代理返回结果给协调器，以进行聚集并递送给原始调用方-在所述情况下是扩展搜索引擎包装器。
在附图中说明了本发明的特定实施例和示例。
图1是说明各种硬件和软件平台的框图，所述平台可以用在本发明的一个实施示例中。示出了两个终端用户客户端101和102，其中一个101通过World Wide Web 105和web服务器111连接到数据服务器121上，另一个客户端通过局域网连接到数据服务器121上。Web服务器111连接到两个关系数据库管理系统131、132上，并且连接到扩展搜索服务器141上，所述搜索服务器141依次连接到两个非结构化数据库服务器151和152上。非结构化数据库服务器151或152可能包括一个或多个非结构化数据库，以及可选地是web客户端，其中另外的web服务器和数据服务器的组合包括将被搜索的非结构化数据。
图2是说明本发明的方法和系统的各种元件的框图，其中用户201输入SQL查询202到关系数据库管理系统203中。关系数据库管理系统203是联合关系数据库管理系统，并且使用具有扩展搜索协调器204和代理205、205’的非结构化数据搜索系统，来搜索非结构化数据206和206’。结果存储在扩展搜索别名表207和扩展搜索数据库208中。
图3说明了在步骤301中通过使用结构化数据搜索引擎产生非结构化数据的查询以执行查询处理的方法。在步骤303中结构化数据搜索引擎将查询输入到包括扩展搜索协调器的非结构化搜索系统中。在步骤305中扩展搜索协调器然后将请求传输给搜索代理，在步骤307中所述代理搜索非结构化数据，并在步骤309中返回搜索的结果和结果属性，在步骤311中将搜索结果和结果属性聚集到包装器中。在步骤313中将结果属性分配给包装器，并且在步骤315中将结果属性输入到结构化数据搜索引擎可搜索的别名表中。结果属性被输入到别名表中，作为一列。在步骤317中结构化数据搜索引擎然后查询别名搜索表，并返回查询结果给请求者。
通过如上所述集成联合数据库和扩展搜索技术，可以实现几个好处。第一，通过扩展搜索引擎别名表的加载，包括实时加载，使得来自不同数据源类型集合的非结构化数据，对于RDBMS引擎而言为实时可用的。呈现给结构化数据库搜索引擎(关系数据库管理系统)的数据是当前的并且是更新的。虽然其它联合包装器针对单个源提供了当前数据，但是仅扩展搜索引擎包装器同时针对多个数据源启用该能力。以这种方式，将扩展搜索引擎包装器接收的数据作为单个标准化的数据集合呈现出来，即使在其形成中包括了多个源。
第二个好处是数据保持分布在整个企业中，逻辑上离执行工作的地点最近。扩展搜索引擎而不是关系数据库引擎负责搜索存储在不同位置上的数千数据源。与扩展搜索协调器结合使用的扩展搜索包装器作为所述大量非结构化信息的网关。
第三个好处是针对非结构化信息的聚集应用关系概念的能力。单独通过扩展搜索引擎不可能将接收于一个源的结果和接收于其它离散源的结果关联起来，以获取从属结果集合。例如，不可能基于匹配字段值将来自不同源的数据结合起来。扩展搜索引擎仅在返回数据上执行聚集，以产生单个的结果集合。但是，一旦通过扩展搜索引擎包装器，使得数据可用于别名表，则通过RDBMS引擎，数据可以自由与数据库中任何其它表，包括其它别名表结合。
所述能力具有深远意义。通过使用本发明概念，针对可由扩展搜索引擎取回的每个不同类型数据配置别名表，现在可能使用关系引擎的能力来轻易地在数据的主机软件之外集成所述数据。
说明示例
通过举例的方式，假设智能代理试图识别可能是潜在恐怖分子的个人。在所述代理能够访问各种敏感源的情况下，他们可能提出如下问题：“列出下述人员的姓名：所述人员在一定时间内获得签证、从这些天起购买了大量化肥、与有关炸药制造的人员进行过e-mail通信、并且申请了B类(卡车)驾照。”
需要搜索的源是很多的，并且具有各种等级的结构。然而每个源具有可以用于执行结合(join)的人员的概念(通过姓名标识)。扩展搜索系统将用来执行到远端数据源的协调搜索(brokered search)以及返回合适的数据，但是然后将依赖于关系引擎以执行结合。为了进行结合，需要将数据组织成为分离的别名表，每类要搜索的数据源使用一个表。
上述例子中需要4个别名表。配置一个别名表来代表e-mail结果，另一个别名表代表驾照信息，另一个代表化肥购买，还一个代表签证申请。每个别名表与一个或多个类似目的的扩展搜索源相关联。例如，应用于驾照别名表的查询可能实际上导致了50个机动车辆注册数据源(每个州一个)的扩展搜索。
假设每个别名表将包括针对个人姓名的外来关键字(foreignkey)，执行结合将基于所述个人姓名。扩展搜索字段映射将用来通过后端源(此后将详细解释)中遇到的语句构成不同，来标准化别名表中的外来关键字。给定以所述方式配置所述4个别名表，则现在可能在SQL中提出如下询问：
表格：签证
名 姓 日期 国家
Bill Stalwart 09/05/2001 德国
Mary Boutreaux 07/21/2001 法国
Ali Mohammed 09/10/2001 伊拉克
表格：驾照
名 姓 日期 类型 州
Bill Stalwart 09/05/2001 A MD
Mary Boutreaux 07/21/2001 A NY
Ali Mohammed 09/10/2001 B CA
表格：邮件
来自 发往 日期 内容
Bill Stalwart sally cruthers 09/05/2001 邮件文本
Mary Boutreaux MartinJones 09/05/2001 邮件文本
Ali Mohammed Mark Billsman 09/05/2001 邮件文本
表格：购买
名 姓 日期 描述 金额
Bill Stalwart 09/05/2001冰箱$673.00
Ali Mohammed 09/05/2001化肥$2230.00
SELECT N1.FirstName，N1.LastName
FROM INS as N1，
DRIVER as N2，
EMAIL as N3，
FERTILIZER as N4
WHERE ES_SEARCH(N1.DOC_RANK，‘DATE_OF_ISSUE＞＝
“01/01/2000”’)＝1AND
ES_SEARCH(N2.DOC_RANK，‘LICENSETYPE＝“B”)＝1
AND
ES_SEARCH(N3.DOC_RANK，‘DOCUMENT TOKEN“bomb”
and DOMCUMENT TOKEN“fabrication”’)＝1
AND
ES_SEARCH(N4.DOC_RANK，‘ProductType＝“FERTILIZER”
and Quantity＞500and
Date＞“01/01/2000”’)＝1
AND
N1.LastName＝N2.LastName AND
N2.LastName＝N3.LastName AND
N3.LastName＝N4.LastName
如前面提到的，扩展搜索具有将通用字段名映射到后端上一个或多个语义上相同但是句法不同的字段的能力。在从别名表中产生有意义的数据模型中，这将是非常有用的。
例如，50个驾照数据库中的个人姓名的符号标识大多可能不同，特别是由于各个州自由构建它们自己的MVA数据库。通过扩展搜索，可以定义持照者名称的单个字段，并将其映射到驾照数据库中合适的原始字段。然后在驾照别名表中可以使用针对持照者名称单个映射的字段。如果没有该映射特征，将被迫在后端数据库中为每个唯一定义的名称字段定义一个别名列。所述表将水平增长出许多列，并且将不会为第3种正常形式。由于任何一行一次仅填充一个姓名列，则将稀疏地填充所述表。
然而存在可能利用来自许多离散数据源的大量字段的应用。对于所述应用，数据(特别是非结构化数据)之间的关系不是预先已知的，因此定义和结构化别名表是非常困难的。通过填充所谓的垂直别名表，扩展搜索可以支持所述类型应用。
垂直别名表包括4个预定义列。它们是：字段名称、字段值、字段类型和源名称。不是使用前面例子建议的映射字段，而是通过使扩展搜索返回原始字段名称/值对来进行反向操作。也返回元数据，例如字段类型(例如日期、整数等)和数据的来源。现在密集地通过许多数据行填充了别名表-针对每个数据源的每个字段使用一行。
但是如何在关系模型中使用这些垂直别名表？假设相同的智能代理询问一系列问题，所述问题有助于所述代理发现数据之间的有用关系，而不管所述数据从何处而来。所述代理已经建立了扩展搜索系统，以在上千个具有自己的数据模型和字段集合的各种类型数据源上进行查询。在不知道哪些字段将与你的搜索有关的情况下，可以配置扩展搜索来搜索并返回所有字段。以刚才所述的垂直格式返回这些字段。
现在智能代理可以使用关系引擎来发现并分析数据关系自身。所述代理可能要求包含词“化肥”的所有字段，通过数据源名称排列结果。
联合关系数据库管理系统
联合数据库管理系统，也称作联合数据库系统或联合系统，是其中每个数据库服务器是自治并且独立的集中的DBMS的系统，所述DBMS具有自己的本地用户、本地业务、数据库管理员并且因此具有高度的本地自治性。在联合数据管理系统中，每个单独服务器可以通过指定“输出计划(export schema)”来授权其服务器的指定部分的访问，所述输出计划指定可以由非本地用户的指定集合访问的其数据库部分，以及所述非本地用户具有的规范。在联合数据库管理系统中，用户基本上是到几个本地数据库管理系统的额外接口，由此允许全局用户访问多个本地、自治数据库。
联合数据库管理系统，例如IBM DB2全球数据库联合系统，支持提交SQL语句的应用和用户，其中在单个语句中引用两个或多个DBMS或数据库。一个例子是两个不同DB2数据库中的表之间的结合。这种语句称作分布式请求。
DB2全球数据库联合系统提供对数据库和DBMS的分布式请求的支持。用户例如可以在DB2表和Oracle视图之间执行UNION操作。
联合数据库管理系统，例如IBM DB2联合系统。提供数据库对象的位置透明度。如果移动了信息(在表中和视图中)，可以更新对所述信息的参考(称作别名)，而无需对请求所述信息的应用的任何改变。联合数据库管理系统的另一个方面是数据源的补偿，所述数据源不支持所有特定SQL方言(dialect)、人为缺陷(artifact)、或相互之间的特定优化能力。在所述DBMS下不能执行的操作(例如，不能实现GROUP BY条款的文件系统)在DB2下运行。
可以提交半自治方式的联合系统功能，即包含对Oracle对象的参考的IBM DB2查询，而同时Oracle应用访问相同的服务器。联合系统不会独占或限制访问(除了完整性和锁定限制)远端数据源上的其它对象。
在IBM DB2全球数据库联合系统的情况下，所述系统包括IBMDB2UDB实例，一种将作为联合数据库的数据库以及一个或多个数据源。联合数据库包括标识数据源和它们特征的目录条目(catalogentries)。数据源包括DBMS和其数据。应用连接到联合数据库上，正如连接到任何其它数据库一样。
联合数据库目录条目包括关于数据源对象的信息：被称作什么，包括了什么信息，在什么条件下可以被使用。由于联合数据库目录存储了关于许多数据源中的对象的信息，所以被称作全局目录。对象属性被存储在目录中。被引用的实际数据源、用于与数据源通信的模块以及将访问的DBMS数据对象(例如表)在数据库之外。在这方面，应当注意到一个例外是联合数据库可以是联合系统的数据源。具体地，IBM DB2支持远端数据源和远端DBMS的联合。
可以使用例如IBM DB2UDB控制中心或SQL数据定义语言(“DDL”)语句来产生联合对象。作为通用规则，所需联合数据库对象是包装器、服务器和别名。包装器识别用于访问特定类别的数据源的模块(DLL、库等等)。在本上下文中，服务器定义数据源。服务器数据包括包装器名称、服务器名称、服务器类型、服务器版本、授权信息、和服务器选项。别名是在联合数据库中存储的标识，所述标识参考了特定的数据源对象(表、化名、视图)。应用程序在查询中参考了别名，正如参考表和视图一样。
在建立了联合系统之后，可以访问数据源中信息，就像所述信息在一个大的数据库中一样。用户和应用程序发送请求给一个联合数据库，如果需要，所述数据库然后从DB2家族和Oracle系统中取回数据。用户和应用程序在查询中指定了别名；所述别名提供了对位于数据源中的表和视图的参考。从终端用户的角度出发，别名类似于化名(aliase)。
许多联合系统在一些限制之下操作。例如，分布式请求可能被限制为只读操作。在一些联合系统中，不能针对别名执行实用操作(LOAD，REORG，REORGCHK，IMPORT，RUNSTATS等等)。然而，请求者可以使用传递工具(pass-through facility)来通过使用与所述数据源相关联的SQL方言，将DDL(数据定义语言)和DML(数据处理语言)语句直接提交给数据库管理者。
联合系统容忍并行环境。性能增益受到联合数据库查询可以在语义上被分解为本地对象(表、视图)参考和别名参考的程度。连续处理别名数据的请求；可以并行处理本地对象。例如，给定查询
SELECT＊FROM A，B，C，D
其中A和B是本地表，而C和D是引用Oracle数据源上的表的别名，一个可能的计划是通过并行结合来结合表A和B。然后将结果与别名C和D顺序结合。
扩展搜索引擎和扩展搜索应用
扩展搜索引擎通过允许终端用户搜索并取回所有类型信息，而不仅是主机软件所管理的数据，“扩展”了其它搜索产品的标准能力。例如，使用标准web浏览器，终端用户可以轻易地并且迅速地定位和阅览包含于散布在组织中的数千数据仓库中的信息。所述仓库可能是各种内容和结构，并且所述仓库可能在地理上散布于全球。
通过单个查询，终端用户可以同时搜索内部和外部web站点、全文索引、Microsoft索引、文档管理系统、e-mail系统、文件系统、关系数据库、LDAP目录和Lotus数据库的完全补充。扩展搜索引擎可以被认为是代表用户进行工作的协调代理(brokered agent)；所述引擎搜索原始形式的每个数据储备(data store)，并在单个聚集结果集合中返回结果。
扩展搜索引擎对终端用户屏蔽数据源多样性。这是因为终端用户与单个、通常是功能丰富的扩展搜索引擎接口进行交互，所述接口将终端用户搜索透明地分发给潜在的数千个不同种类的数据储备。可以以各种方式呈现结果。
比起终端用户从典型搜索应用中所期待的，通过扩展搜索，终端用户经历了更多。终端用户发现其触及范围已经进一步扩展到企业中，并且可以访问以前不能轻易获得的信息。
几乎所有搜索系统都包括对将要搜索的信息进行分类的索引的使用。如果没有索引，执行搜索的时间将大大增加，很像在没有卡片目录的情况下试图在图书馆中查找一本书。但是虽然大多搜索解决方案需要终端用户重新索引信息到一个新的索引中，但是扩展搜索引擎，例如IBM Lotus扩展搜索，影响了(leverage)企业的当前数据管理投资。
应注意企业信息通常以许多外形和形式存在，并且贯穿整个企业分布，以及对于正在进行的任务通常由任务特定软件进行管理。扩展搜索引擎，例如IBM Lotus扩展搜索，进入数据源和数据访问模式的迷宫，并将现有的集合处理为一个具有单个入口(entry)点的虚拟索引。
不管入口的模式，扩展搜索引擎将查询转化为目标数据源的原始搜索语言，并使用对于每个数据源是原始的搜索和取回方法来返回结果。
但是需要认识到，不是相同地产生后端数据源，所述数据源可以具有完全不同的体系结构、方法、方案、元数据和能力(例如全文本索引vs.关系数据库vs.e-mail系统)。任何可能的时候，扩展搜索工具和引擎试图最小化所述不同，并获得大于最小公分母的效果。
例如，在查询多个数据源中，扩展搜索引擎，例如IBM Lotus扩展搜索，可能针对一个数据源合并两个或多个操作，以达到在对一个不同源的单个操作中可获得的效果。所述技术使用户可以通过单个查询并行搜索多个数据源，所述数据源具有不同类型、体系、结构、能力和格式。通过所述手段，可能维护原始数据库或搜索引擎的机制，并保留信息的完整性和流通性，同时避免将分散数据复制成集中索引，以减少整体存储需求并消除重新索引资源的花费和开销。此外，数据保持与正在执行的工作的近距离(逻辑上和虚拟上)，并且各个数据特定的和任务特定的数据源和搜索引擎可以并行执行搜索操作，由此改善搜索响应时间。
扩展搜索引擎范例也提供了比围绕集中索引构建的多个数据源范例更大的可缩放性。随着域内文档数目的增加，索引信息所需的时间也增加了。对较大域的索引使得搜索不可实现的情况并不少见。
在这种情况下，扩展搜索引擎的能力补充了索引的深度：首先，将索引稳定在最大容量上，然后结合其它数据储备来搜索索引。通过这种技术，终端用户可以仅对需要索引的内容进行索引，同时使用扩展搜索引擎来搜索索引的和非索引的源。
连接新的源到搜索域中使得扩展搜索引擎引起的开销较小，并且当与实际搜索操作自身的花费进行比较时，这将是可忽略的。由于使用现有搜索操作在已经存在于网络(互联网或内部网)中的一个或多个机器上执行搜索，因此连接新的源的增加花费是可忽略的。
扩展搜索引擎通过使用企业现有数据管理软件，实现了访问企业的所有信息的策略，无论其处于什么位置。通过这个策略，造成了固有的事实，即，不是所有的后端数据源被生成为相同的数据源。存在通用区域，其中大多系统在搜索和取回方面有所不同。建立在这些共性上，扩展搜索引擎提供了通用平台(ground)，使系统实现者能够在以下领域互补工作：(1)搜索语言，即如何表达查询；(2)数据模型支持，即如何组织、关联和呈现数据；(3)应用程序接口(API)支持，即如何执行信息访问。
至于搜索语言，几乎所有数据管理系统都使用某种语法或查询语言来表达搜索标准。根据数据的结构和成分，所述语法可能大大地不同。例如，在例如web的自由文本系统中，例如通常将搜索表达为关键字列表。使用额外的概念，以表达boolean条件(与，或，非)或位置信息，例如必须在相同句子或段落中出现的特定词。通过比较和对比的方式，如果数据被高度地整理和结构化了，则语法可能是更加参数化的，并且可能支持字段化操作(例如，数量字段的值大于100)。
显然，对于用户而言，知道扩展搜索中使用的搜索语法的全部集合的句法是不现实的。让用户以单个通用搜索语言来表达查询是更易实现的。在IBM Lotus扩展搜索中，通用语言是通用化查询语言(GQL)。可以将该语言当成能够表达大多查询的搜索语法的扩展集。
以GQL格式内部表达所有IBM Lotus扩展搜索查询(除了将要简要讨论的“传递”查询)。当GQL表达式到达特定数据源时，扩展搜索将其转变为所述源的原始查询语言。所述转变处理将GQL的词汇元素映射到原始语法的等同元素上。
虽然IBM Lotus扩展搜索的所有部件支持全部的GQL语法，但是不是所有后端搜索引擎能够支持GQL语法的所有元素。当扩展搜索引擎，例如IBM Lotus扩展搜索，遇到所述不一致时，所述搜索引擎通过合并两个或多个原始操作来试图补偿，以到达相同的效果。只有在扩展搜索引擎已经用尽所有可选方法之后，才忽略表达式的不支持部分。在所述情况下，终端用户可以替代地传递不能得到转换的查询。
通用数据模型
正如搜索语法可以随每个不同的后端系统而不同一样，数据模型可以用来组织和存储信息。典型地针对其所服务的应用等级来设计特定数据管理系统使用的数据模型。这确定了其信息中所得到的结构和粒度的程度。
例如，自由文本系统往往使用具有低数据粒度的松散结构化的文档模型。文档可能包括几个字段(例如标题、作者和正文)，但是文档的文本保持形式自由，并且是非结构化的。通过比较，可以高度结构化信息，例如在关系数据库中所得到的。这里，将数据组织为可以以任意种方式相关联的行和列，这导致了很高的数据粒度。
现代扩展搜索引擎，例如IBM Lotus扩展搜索，将不同数据模型集合标准化为单个模型，所述单个模型易于理解并可由大多搜索应用所使用。搜索应用设计者仅需要与这一个数据概念模型进行竞争，而不会被许多模型所混淆。
通常将源映射到常规意义的数据库上，但是可以将源轻易地映射到web站点上、文件系统目录上、或LDAP体系中的节点上。同样地，将文档方便地映射到基于文本的但是可以轻易地表示数据示例的所述系统上，所述数据示例例如是关系数据库的表中的一行。
在将不同类型的数据源相关联时，通常遇到的问题是，字段标签不匹配。例如，作者名在一个数据源中可能被标记为AUTH NAME，在另一个中标记为CREATOR，而在另一个中表示为3个字段(名、中间首字母、姓)。
通用数据模型的重要特征是定义映射字段的能力。映射字段是一个或多个原始字段的合成。为了解决前面例子中的模糊问题，终端用户可以定义具有标签AUTHOR的单个映射字段。终端用户然后可以映射所述字段到支持作者姓名的语义的每个数据源中一个或多个原始字段上。
当在搜索表达式中使用所述特征时，所述特征的好处是令人信服的。用户仅需要在查询中指定映射字段。IBM Lotus扩展搜索将在后端自动将映射的字段与正确的原始字段相关联起来。所述技术大大简化了查询表达式，并当数据源的数目增加时，提供了更多的好处。
为了说明所述特征，考虑将要显示指示器(barometer)的应用的情况，测量所述指示器以反映文档的使用年限(即，文档越新，将具有越高的指示器读数)。如果在每个后端源中不同地标记了“产生日期”的字段，则该应用将需要一个穷尽的条件语句集合，每一个针对每个离散的日期字段名称。但是，通过映射字段，仅需要识别一个映射的“产生日期”字段，以便取回并对其进行后续测试。通过参考所述单个映射字段，结果将包含正确的日期值，因为其与源的原始日期值相关联。
在另一方面，如果结果来自e-mail系统，终端用户可能希望返回日期、主题和作者。可以通过使用原始源字段标识，选择性地取回这些语义不同的数据字段。当原始字段标记对于显示目的而言太过保密(例如$Doc Abstract)，则再次将映射的字段用作原始字段名称的化名(例如，Document Abstract)。
扩展搜索引擎的另一个方面是通用API的提供。通用API回答了“我如何与所有这些不同的后端系统交互，以搜索并取回它们的管理信息？”的问题。通过调用方法、句法、语法和编程语言，每个后端系统的API可以大大不同。通过扩展搜索引擎通用接口发布的功能由系统自动转换为后端系统的原始方法，非常类似于转换GQL为原始搜索语法的过程。
扩展搜索引擎寻求以可能的最佳方式与后端上每个不同机制接口，以获得所有数据源之间的最佳平衡，并同时考虑到每个原始搜索API的操作策略。通过使用主机软件的公布的API，保持了数据源的完整性和安全性。
为了获得所述可通信性，针对每类后端数据源产生链路模块，并使用所述模块来封装所述类型所需的所有原始API调用。
使用基于代理的技术来将这些链路模块应用到它们的各数据源中。代理代表协调搜索工作，并通常是透明的(将在后面更详细地描述链路和代理)。从设计者的角度，终端用户通过单个API与一个可搜索的后端系统接口。
在IBM Lotus扩展搜索的情况下，可获得两种形式的通用API。第一种并且是最灵活的一种是Java bean接口。通过所述方法，bean与Java编程语言的能力相结合，以开发宽广范围的从简单到高复杂度并且专门化的搜索和取回应用程序。该产品展示了这些bean在使用JavaServer Page(JSP)的示例web应用程序中的使用。
或者，可以使用一组类似HTML的标签，其允许终端用户将扩展搜索引擎功能嵌入到新的或现有的web页面中。这些便于使用的标签可以授权web管理员并且使用户可以输入指定各种搜索选项的查询。终端用户可以在web页面的任何地方嵌入扩展搜索引擎标签，所述标签不与周围的HTML标签相干扰。
可以以各种方式呈现来自扩展搜索应用程序的搜索结果。作为配置系统的一部分，可以编程并配置系统，以确定允许用户查询、在结果页面上观看以及从数据源种取回哪些字段。向用户呈现包含来自多个源的结果的单个、合并的页面。针对关联性对所述列表进行预先剪裁(pre-pruned)，因此保证了用户首先看见最匹配的。
扩展搜索系统的特征在于可缩放性。具体地，例如IBM Lotus扩展搜索的扩展搜索系统的分布式部件体系结构，提供了根据变化的需求对系统进行缩放的灵活性。它也允许以与环境匹配的拓扑结构安排扩展搜索引擎部件，使得终端用户可以根据需要来混合IBM AIX、SunSolaris、Windows 2000和Windows NT平台。
示例性可缩放扩展搜索体系结构包括：
纵向上，在单个扩展搜索服务器中，终端用户可以配置多个服务器处理实例，以影响服务器可以处理的同时请求的数量。
横向上，通过多个机器，终端用户可以建立额外的扩展搜索服务器以及额外的web服务器。对于每个扩展的搜索服务器，终端用户可以确定终端用户希望运行的服务器任务类型。通过拥有多个服务器，终端用户可以分布和均衡处理负载。
扩展搜索体系结构
20世纪末期所经历的巨大经济增长归功于信息技术所获得的进步以及投资信息技术的那些公司。由于技术原来(并且现在仍然)以惊人的速度在改变，公司频繁地投资并再投资他们的信息技术(“IT”)预算到不断进化的产品中，以管理他们的信息。这样做的结果经常是，贯穿整个组织分布的信息岛--针对正在进行的任务是高度专门化的，但是不易基于企业范围对所述信息进行访问。即使一个公司能够决定企业的通用IT策略，但是使用不同IT体系结构的公司的单次收购将会阻碍所述策略。
这里构想的由IBM Lotus扩展搜索例示的扩展搜索引擎，具有多层设计。例如，IBM Lotus扩展搜索系统使用4层体系结构。消息开始于第一层中的搜索应用程序，并通过后续的层连续进行到后端。在大多情况下，后端是IBM Lotus扩展搜索所连接到的第三方数据源，但是后端也可以是扩展搜索配置数据库(CDB)、由关系数据库管理系统所管理的私有后端，例如IBM DB2RDBMS。
层间的消息流可以分割为两个基本类别：
运行时间消息，这是通常由用户团体所发布的消息，以执行搜索并取回文档。
管理消息，这是由管理员发布的，并导致配置数据库的更新。
链路是将针对搜索和取回的原始API调用封装到特定数据管理系统的软件模块。它们包括与后端数据系统接口所需的所有数据结构、编程对象和程序逻辑。
单独地组装一个链路模块以支持(最小化)通常存在于所有数据管理系统中的可调用方法：
连接到主机系统并从主机系统断开连接的方法
从系统中搜索内容并取回数据的方法
对于后端源不支持的方法，链路模块执行空操作。例如，文件系统搜索不支持连接和断开连接的概念。
转换器(translator)是负责将进入的GQL表达式转换为后端数据系统的原始搜索语法的软件模块。它们也包括产生句法正确的搜索表达式所需的所有数据结构、编程对象和分析逻辑。
在一些情况下，同一转换器模块应用于几个不同后端系统，和SQL转换器和许多各种支持标准SQL语法的系统的情况一样。
代理是响应旨在特定数据源的搜索和取回操作的程序。当第一次提出针对特定数据源类型的请求时，代理加载合适的链路和转换器模块。代理然后调用用于进行转换(XLAT)、连接、断开连接、搜索和取回操作的这些模块库。
对于搜索操作，代理将按照相关度等级来对结果集合进行分类(sort)，然后将集合截取(truncate)为最大数量的命中(hit)，如原始搜索请求中所指定的。所述命中列表的分类和随后的截取是聚集的重要前期操作(precursor)，将对其进行简要讨论。
代理可以位于与数据源相同的机器上(推荐)，或使用数据源的远端API进行访问。可以在单个计算机上运行代理的不止一个拷贝，以处理同时的搜索和取回请求。一个代理可以用于单个数据源、特定类型的一组源或具有混合链路需求的某一范围的源上。
协调器是存在于服务请求者和通过后端实际执行服务的代理之间的中间部件。协调器作为特殊用途资源协调者进行工作，被设计用来管理从单个请求产生的，例如由类别搜索(category search)引起的多个搜索。
协调器典型地执行下面任务：
验证请求。
扩展类别以获得应用程序可用的数据源列表，并解析源地址。(标记1)
将查询分发给代理，以进行高效、并行的搜索。(标记2)
将由各个代理返回的搜索结果聚集并任意分类为单个搜索结果集合。(标记3)
高速缓存搜索结果，以进行后续分页(paging)的操作。(标记4)
向代理发布请求，以便为用户取回源文档(注意到在大多情况下，web浏览器使用在结果列表中返回的URL，以取回文档)。
示意超时(timeout)和响应选项。
在引起单个请求的后端系统的大的集合中，响应程度可能大大不同。一些数据管理系统比其它系统响应的快，而一些则不，-可能由于服务条件之外的原因。为了解决这种情况，协调器被设计为与它们的代理异步通信。
为了支持性能和可缩放性，扩展搜索系统可能包括多个协调器。这种建立协调器体系的能力，连同建立与所支持的源共同存在的代理的能力，或指定代理到特定源或源的类型的能力，为扩展搜索系统，例如IBM Lotus扩展搜索，提供了关于改变和扩展环境的无穷灵活性。在多个协调器的方案下，源被所有协调器分区，这是一种防止任何一个协调器被淹没(overwhelm)的设计。
在单个协调器环境中，针对6打源的搜索将导致72个查询被发送给远端机器，以及72个搜索结果集合返回给协调器。如果每个结果集合包括最大数量的结果，则当协调器合并和聚集返回给请求者的列表的数据时(协调器截取结果，并仅保持顶部项目，直到搜索应用所允许的最大数量)，将丢弃大多数据。
通过多个协调器，入口(entry)协调器发送单个消息给远端机器的协调器。远端协调器然后将该消息分离为针对它们各自机器上的源(由代理所指向)的多个请求。不是将所有结果集合返回给一个协调器，而是每个协调器合并、聚集并剪裁由其代理返回的结果，并然后仅将单个列表-包含顶部命中-返回给入口协调器。入口协调器仅需要从其自己的本地源中产生最终结果集合，以及由远端协调器返回的合并的列表。
协调器从扩展搜索应用的配置数据库中获得关于其管理的资源的信息。所述数据库包括关于数据源以及应该如何搜索数据源的信息。所述数据库也存储网络地址、保存的查询、保存的搜索结果以及webcrawler下载的数据。
终端用户通过使用直观(intuitive)管理接口，可以轻易地更新关于网络拓扑、数据源和搜索应用的信息。所述接口也提供网关，终端用户通过所述网关可以运行发现(下面讨论)、观看错误消息和事件数据、调度查询，和利用保存的查询和搜索结果工作。
虽然已经关于一定的优选实施例和示例描述了本发明，但是这不是旨在由此限制本发明的范围，本发明的范围仅由后附的权利要求限定。