CN103403714B - 处理复合查询的系统和方法 - Google Patents

Abstract

本发明涉及处理复合查询的方法和系统，每个复合查询对应于待组合的多个组成部分。搜索对应于这些组成部分的元素。元素具有不同的元素类型，并且最好由具有不同数据结构的定义数据描述。转换步骤把不同种类的定义数据变换成一种单一格式的转换后的定义数据。引擎随后取回各个元素，并根据转换后的定义数据，建立与查询参数匹配的元素的关联，从而最佳地提供对查询的答复。

Description

处理复合查询的系统和方法

技术领域

本发明涉及数据处理的领域。更具体地，本发明涉及复合查询的处理，这里，所述复合查询意味每个查询涉及搜索数据库，并从数据库取回将被关联在一起的多个项目，从而向用户呈现逻辑地组合在一起的多组所述项目。

一种非限制性应用是当用户希望预订一系列服务，比如性质极其不同的航空旅行服务与旅馆食宿和/或租车的组合时，旅行观光行业领域中的搜索请求的处理。

背景技术

对处理关于一种类型的项目的请求来说，目前的搜索系统相当高效。在旅行行业领域中，目前在广泛使用搜索引擎，并且响应最终用户请求，发送返程方案。对专用于航空公司的引擎，比如向用户提供将显示在友好的图形界面上的一组低价格飞行方案的低费用搜索引擎来说，情况就是这样。这些技术的成功导致航空公司提出计算机化工具，以扩大搜索的范围，返回组合产品。在当旅行时消费者通常需要一系列服务的旅游业中，情况尤其如此。待组合的产品可包括机票、酒店住宿和观光活动。

图1描述现有技术如何构成产品组合。使用多个数据储存库Da、Db和Dc，每个数据储存库保存一种旅行产品。例如，Da、Db和Dc分别包含关于飞机座位、关于酒店房间和关于租车服务的信息。服务器S用作系统的中心节点。它通过网络，比如广域网(最好是因特网)，从最终用户接收用户请求，并返回旅行组合方案。当收到请求时，服务器S传送多个单独的查询，每个查询以分别与储存库Da、Db和Dc之一相关的一个搜索引擎Ea、Eb和Ec为目标。在搜索引擎Ea、Eb和Ec的层面进行本地并且独立的搜索，产品被返回给服务器S。服务器随后聚合产品，从而构成由多个产品构成的旅行组合。

这样的搜索系统复杂，并且涉及多个硬件/软件计算机资源。

发明内容

本发明目的在于克服处理复合查询的现有技术的至少一些缺陷。

本发明意图解决的一个技术问题是优化其中需要搜索不同性质的多个项目并组合所述多个项目，以产生对用户请求的响应的复合查询的处理。本发明提供基于不同种类的数据，并由复合查询触发的搜索的高效解决方案。

更具体地，本发明涉及一种处理数据搜索的方法，所述数据搜索以对匹配搜索参数的至少一组组合元素的复合查询为基础，组合元素中的至少两个元素具有不同的元素类型。所述方法最好包括以下查询处理步骤：

i)获得至少两种不同元素类型的元素的定义数据，所述定义数据具有不同的数据结构，所述定义数据包含每个元素的至少一个元素费用，

ii)把所述定义数据转换成共有一种通用数据结构的转换后的定义数据，

iii)在搜索引擎接收复合查询，

iv)在搜索引擎，查找其转换后的定义数据匹配所述查询的至少两种不同元素类型的元素，并组合所述元素，组合步骤包括：

-关联所述元素的元素费用，

-根据元素费用的关联，构成至少一组付费的组合元素，

v)返回所述至少一组付费的组合元素。

所述至少一组要求的组合元素最好是就评估参数，比如(但不是非偶然的)集合的价格来说最佳的集合。在后一情况下，最佳的集合是最廉价的集合。

由于本发明，能够根据不同种类的数据源进行搜索。这里，不同种类的数据结构意味着元素类型中的至少两种元素类型由不同数据结构的数据定义。从而，一种数据源和至少另一个数据源在数据的表示和/或描述所述元素类型的元素的数据字段方面不同，这意味通常没有任何单一的搜索引擎能够在这些不同种类的数据源之中进行搜索。尽管当前的系统通过增加搜索引擎(一个搜索引擎用于一个数据源)，并通过实现后处理装置，以聚合从多个引擎获得的结果，克服该问题，不过本发明显著节省计算机资源，因为一个搜索引擎就足够了。另外，该搜索引擎直接产生元素关联，而不需要聚合的后处理步骤。

并且，该搜索引擎返回的结果更加可靠。这是因为该搜索引擎直接作用于利用相同数据结构的定义数据描述的元素，以致在相同的处理中集成元素的搜索和组合。

下面介绍可以累加地或者替换地使用的更多可选特征：

-所述方法包括把定义数据保存在储存库中的步骤，和使搜索引擎访问所述储存库的步骤。

-组合步骤包括检查元素费用的关联是否遵守组合规则。

-复合查询包括数据，该数据定义从搜索参数得到的、并且将为其搜索至少一个元素的多个组成部分。

-组合步骤包括：

-对于每个组成部分，取回一组匹配元素，

-关联匹配元素费用，

-检查匹配元素费用的关联是否遵守组合规则，

-如果所述关联遵守组合规则，那么使匹配元素费用的关联生效，

-如果所述关联未能遵守组合规则，那么使匹配元素费用的关联无效。

-所述方法包括对于匹配元素费用的至少另一个关联，重复前述步骤。

-它包括定义从搜索参数得到的、并且将为其搜索至少一个元素的多个组成部分，并且为每个组成部分定义将为其搜索至少一个元素的至少一种元素类型。

-进行以下步骤：

执行用于多个查询的查询处理步骤，以建立匹配元素的关联，

当收到最终用户的请求时，取回匹配所述请求的所述关联中的至少一个关联，

检查所述关联中的所述至少一个关联是否遵守组合规则，

如果所述关联中的所述至少一个关联遵守组合规则，那么使所述关联中的所述至少一个关联生效，

如果所述关联中的所述至少一个关联未能遵守组合规则，那么使所述关联中的所述至少一个关联无效

向最终用户返回所述关联中的所述至少一个关联，如果所述至少一个关联是生效的关联。

-执行以下步骤：

执行用于多个查询的查询处理步骤，以建立匹配元素费用的关联，

根据匹配元素费用的关联，建立匹配元素的关联，

检查匹配元素的关联是否遵守组合规则，

对匹配元素的每个关联来说，如果它遵守组合规则，那么使所述关联生效，而如果它未能遵守组合规则，那么使所述关联无效，

保存生效的关联，或者它们中的至少一些；按照评估标准，比如价格进行选择，以便只保存最佳的生效关联，

当收到最终用户的请求时，取回与所述请求匹配的所述最佳的生效关联中的至少一个关联，

向最终用户返回所述最佳的生效关联中的所述至少一个关联。

-定义数据包括费用数据、可用性数据和申请规则数据。

-元素类型包括下述中的至少两种：航空旅行元素类型、铁路旅行元素类型、食宿元素类型、租车元素类型。

-通过由至少一个数据处理器执行计算机软件来进行所述方法，所述计算机软件被保存在非临时性计算机可读存储介质中，这里，所述计算机可读存储介质包括任何计算机可读介质，比如ROM或RAM存储器。

本发明还涉及一种处理基于复合查询的数据搜索的系统，包括执行本发明的方法的装置。

按照优选实施例，搜索引擎是低费用搜索引擎。

所述系统可包含保存在非临时性计算机可读存储介质中的计算机软件，所述计算机软件由构成所述系统的一部分的至少一个数据处理器执行。

本发明还涉及一种保存计算机程序的计算机程序产品，所述计算机程序包括适合于进行本发明的方法的指令。

附图说明

为了图解说明优选实施例，现在将参考附图，详细说明本发明。

图1是聚合查询结果的现有系统的例子。

图2表示与定义数据的转换相关的本发明的一个方面的优选实施例。

图3描述定义数据的转换的例子。

图4是图解说明方法的步骤的示图。

图5表示检查步骤。

图6图解说明与元素的关联的数据库的构成有关的本发明的实施例

图7表示图6中给出的实施例的备选例。

具体实施方式

本发明可以用计算机硬件和软件装置实现。它可包括发生数据的处理的服务器端。可由一个或多个计算机设备构成的服务器端最好通过网络资源，与至少一个远程用户设备，比如(但不限于)桌上型计算机、智能电话机等通信。用于数据传输的通信网络可包括局域网和/或广域网，比如因特网。

下面给出一些定义：

-“最终用户请求”或请求意味从系统的一个设备发送的，意图获得与搜索参数对应的结果的搜索请求。在优选实施例中，所述请求基于至少部分由用户-比如通过网络与系统的其它部分通信的远程用户-在用户设备输入的搜索参数。在一种优选应用中，所述请求针对的是包含待关联的多个项目(参见下面的“组成部分”)的旅行安排方案。

-“查询”意味发送给搜索引擎的指定搜索条件的消息。取决于工作环境，查询可以基于或者源于最终用户的请求，或者可在服务器端自动生成，而不与用户请求的实际通信量直接联结。

-“组成部分”意味用于形成答复用户请求的解决方案的各个项目的关联中的一个项目。就旅行安排来说，多个组成部分一般是多个分段，其中每个分段都满足由搜索参数定义的旅行安排的一个部分。例如，复合旅行请求可包括外出旅行组成部分，食宿组成部分和返家旅行组成部分。一个组成部分可包括一组项目，所述一组项目可被聚合以构成待搜索的单一实体。例如，连续的酒店住宿可存在于一个组成部分中。

-“元素类型”意味共有相同的性质或结构的元素的通用类别定义。在旅游观光业的领域中，元素类型一般是向消费者提供的一类服务，比如航空旅行服务、铁路旅行服务、酒店食宿服务、租车服务、午餐服务、和在旅行期间消费者可能需要的任何其它服务。元素类型用于对元素分类，元素是用于建立匹配复合请求的完全解决方案的单位砖块。在优选实施例中，多个元素是可以组合在一起以满足用户在请求中表达的需求的产品。例如，元素可以是：一段空中旅行航程(对应于始发地和目的地之间的一次飞行)，租车服务，酒店(或者其它住处)住宿一晚(或者连续几晚)，出租车预约，除航空分段外的旅行分段(铁路、公共汽车…)。多个组成部分可以与一种元素类型或者多种元素类型匹配。例如，与请求的一个组成部分对应的始发地和目的地之间的旅行会导致搜索匹配搜索参数的班机和火车。

下面在旅行产品的情况下详细说明优选实施例。

因此，我们说明在航空业领域，如何构成典型的旅行产品。航空公司采用要购票的旅行产品的相当复杂的定义。这种定义是围绕费用定义概念组织的，所述费用定义概念不仅给出关于旅行产品的价格信息，而且在更一般的数据(始发地和目的地，舱位等级和服务级别…)上面，给出费用的申请、可用性指示的有关细节。

这些数据的一个方面是申请规则，下面提供所述申请规则的例子：在每个规则内，存在用数字指定的类别。一个类别描述特定范围中的多个条件。例如，我们具有：1-适当性…19儿童折扣…等。在类别内，存在称为记录2的多个项目，下面，记录2也被简单地称为记录。每个项目由称为匹配元素的一组元素(loc1，loc2，有效日期和终止日期…)构成，匹配元素定义哪个记录2适用于特定旅程。一个记录2包含一串记录3。每个记录3定义关于该类别的给定一组限制。

这里给出一个例子：

-规则AF01

o类别1-适当性

■记录2

●在巴黎和伦敦之间

●具有利用'或'链接的2个记录3的串

o乘客必须是军人

o或

o乘客必须是牧师

o类别12-附加费

■记录2

●在巴黎和伦敦之间

●具有1个记录3的串

o如果乘客乘坐商务舱，那么他要支付2000$的附加费。

这显示当元素由用费用定义的航空旅行产品构成时，元素的定义的复杂性。另外，数据结构，从而元素类型会因航空公司或旅行提供商而异。其它的旅行元素(比如火车票、租车或酒店房间)具有不同的定义数据结构，以致一个技术问题是在响应查询的相同过程中处理各种数据结构。

图2描述与转换阶段对应的本发明的第一部分。D1、D2和D3代表数据储存库-数据储存库的数目不受限制-并且包含元素的定义数据。例如，航空旅行元素被保存在D1中，酒店房间元素被保存在D2中，而租车元素被保存在D3中。保存在D1、D2和D3中的元素的定义数据具有不同的数据结构。

例如，空中旅行元素可以是由以下定义的元素类型：

-费用数据

-可用性数据

-规则

-TLA数据，即，来自低成本承运人的数据

-OAG数据，即，航班数据

D2数据源的酒店房间元素可以是由以下定义的元素类型：

-一个或多个费用数据

-酒店和酒店房间定义数据

-规则

D3的租车元素可以是由以下定义的元素类型：

-一个或多个费用数据

-汽车定义

-规则

所有这些元素对应于不共有通用数据结构的不同种类的项目。一般，每个元素类型的数据结构由所讨论的元素的提供商的管理人员指定。

按照本发明，进行元素的定义数据的转换。如图2中描述的转换器可用于这种用途。转换器被配置成输出转换后的定义数据，以致用单一的通用数据结构描述所有元素。

按照优选实施例，通用数据结构包括：

-描述元素类型(比如，航空、汽车、酒店…)并且可能还有与该元素相关的品牌的标识数据。

-至少，一个元素费用集合由以下构成：

●费用数据(费用额)

●可用性

●申请规则

申请规则可被分成两种类别：

-内部规则，内部规则告知元素费用的申请条件；例如，规则可包括请求者的年龄；

-外部规则，外部规则是受另一种元素在待构成的关联中的存在或不存在约束的元素费用申请的条件(例如，要求乘坐特定航线的酒店费用)。外部规则依据以下内容，指定组合是否可能：

-所述元素，

-所述品牌

-所述费用

-或者这些标准的组合。

外部规则用于检查各个元素之间的关联的有效性。下面把它们称为组合规则。在一个实施例中，组合规则和其它申请规则被保存在相同的存储区中。在一个备选实施例中，它们被保存在不同的层级。它们可由与元素的提供者不同的人管理。例如，组合规则可由基于web的实体，比如在线旅行代理处的管理人员定义。

如果未按通用格式保存组合规则，那么转换器将按照修改剩余的元素定义数据的相同方式，修改组合规则。

对组合规则来说，通用数据格式与如IATA(国际航空运输协会)定义的规则的类别10类似，以便可以与航空费用组合。

这里是关于具有促销价的租车元素的组合规则的另一个例证情况：

●与酒店元素的组合

“只有当汽车来自或者去往酒店时，才可使用该费用”。

●与航班元素的组合

“只有当汽车接送在上午8点和11点之间，或者在下午2点和5点之间到达的航班时，才可使用该费用”。

转换器进行的转换步骤的结果可被保存在适当的储存库，比如图2中描述的包含元素的转换后的定义数据(cd₁、cd₂、cd₃)的c d数据库中。

图3图解说明定义数据转换步骤的另一个例子。这种情况下，酒店元素经历从在图2的表中描述的结构到转换后的格式的格式变换，在所述转换后的格式中，创建和表中的行数一样多的转换后的元素。

现在参见图4，利用从收到用户请求开始，到提供结果为止的数据流，图解说明实施例。

最终用户-比如潜在的旅行者-借助计算机设备输入搜索参数。最好，该步骤利用借助浏览器显示的图形用户界面。注意不是所有可用于处理请求的搜索参数都需要由用户输入。一些参数可由系统根据例如默认值，或者根据从用户请求的环境推断的值(例如，始发地可被定义成利用卫星定位系统或IP地址确定的用户设备位置)来确定。

在一个实施例中，最终用户连接到航空公司或者其它提供商网站，可利用产品选择按钮选择他想要预订的组成部分。一旦选择了产品，图形用户界面就请求用户输入与对应组成部分相关的更多细节。例如，如果组成部分是航空产品，那么它导致所述界面请求出发城市和到达城市，以及日期或时间窗口。随后提议用户增加另一个组成部分。类似地，每个新的组成部分涉及与请求的这部分相关的细节的输入。

出于举例说明的目的，考虑从始发地到纽约带食宿的请求，那么请求的输入会涉及对应于两种元素类型的3个组成部分：航空(离港)、酒店、航空(返港)。

最好，所述请求通过通信网络被传送给服务器端。之后，相关元素类型的定义和搜索参数被用于定义将由搜索引擎处理以搜索匹配元素的查询。引擎可以是常规的搜索引擎，比如在交易环境中用于返回附有定价的产品的费用购物引擎。更精确地，引擎可以是目的在于返回低价方案的低费用搜索引擎。由于本发明，仅仅一个引擎-并且是常规种类的引擎-就足以处理由于涉及多种元素类型因而复杂的查询。

为了搜索匹配元素，引擎访问按照前面说明的转换方法获得的转换后的定义数据。

查询的处理最好由元素的元素费用驱动。如前所述，每个元素由普通的数据(元素的标识；普通的定义数据…)和由至少一个(不过通常多个)元素费用定义。这里，关联以元素费用为基础。当收到查询时，为查询的每个组成部分搜索候选元素。对于找到的元素，系统启动其中使找到的各个元素的元素费用关联的关联机制。系统丢弃失败的关联(当它们的规则不相容时)，并生成成功的元素费用关联。成功的关联随后被用于构建各组组合元素，所述各组组合元素被赋予从元素费用的关联获得的费用。从而，所述各组组合元素被称为付费的各组组合元素。

应注意一个元素可以是一系列元素费用关联的源。例如，具有一个元素费用A和一个元素费用B的一个元素导致基于A和/或B的关联。

在一个实施例中，组合关于每个组成部分找到的最佳元素。

不过，可以推行其它的关联策略。

元素的关联必须遵守组合规则。在优选实施例中，伴随关联处理动态地进行这种检查：从一个匹配元素费用(对应于包含在匹配请求的一个组成部分的一组元素中的一个元素)开始，考虑另一个匹配元素费用(对应于包含在匹配所述请求的另一个组成部分的一组元素中的一个元素)。通过访问组合规则，检查它们的可组合性。图5中描述了所述检查。

如果所述关联无效，那么它被排除在引擎的考虑之外，所述引擎继续其搜索。

如果所述关联有效，那么引擎随后尝试组合该关联和与所述请求的再一个组成部分对应的元素的另一个匹配元素费用。再次检查组合规则，继续该处理，直到确定并且对照组合规则检查了适合整个请求的匹配元素的完整关联为止。

返回图4，所述处理的输出是与搜索参数相符的各个元素的至少一个有效关联。

图6中图解说明了处理用户请求的另一种流程。

按照本实施例，在构造阶段内建立元素的关联。保存所述关联供未来之用。这对应于其中在服务器端生成大量的查询而不存在与实际用户请求的直接联结的预处理。

查询由可以与参考图4说明的引擎相同的引擎处理。在最终用户交易时，另一个引擎将解析具有所有最廉价关联的数据库，并丢弃由于不可组合性而无效的那些关联。

当收到用户请求时，第二搜索引擎访问保存的关联。随后对照组合规则检查匹配的关联，并使不遵守组合规则的关联无效。有效的关联被返回给用户。从用户的观点看，由于本实施例，响应时间被减小。缺陷在于这种后过滤可能使所有计算的关联都无效。

图7中给出了图6的实施例的变形例。按照相同的方式建立元素的关联，不过立即对照组合规则检查所述关联。这导致生效的关联随后被保存，供未来之用。当收到请求时，搜索引擎访问生效的关联，并试图找出与用户请求的搜索参数匹配的关联。这种匹配的生效关联可被返回给用户。从用户的观点来看，由于本实施例，响应时间也被减小。

尽管参考附图，详细说明了本发明的例证实施例，不过，显然本发明并不局限于这些具体实施例，本领域的技术人员可以实现各种变化和修改，而不脱离本发明的范围和精神。

Claims (9)

1.一种处理搜索查询的方法，所述方法包括：

在处理器处获得来自于第一数据存储库和第二数据存储库的包括数据元素的定义数据，其中来自于第一数据存储库的定义数据的数据元素具有第一数据结构，所述第一数据结构不同于来自于第二数据存储库的定义数据的数据元素的第二数据结构，所述第一数据结构包括第一旅行产品类型和一个或多个第一元素费用，所述第二数据结构包括不同于第一旅行产品类型的第二旅行产品类型和一个或多个第二元素费用；

利用所述处理器把来自于第一数据存储库的定义数据和来自于第二数据存储库的定义数据转换成共用一种通用数据结构的转换后的定义数据；

将所述转换后的定义数据存储在数据库中；

在将所述转换后的定义数据存储在数据库中之后，在搜索引擎处接收所述搜索查询；

用搜索引擎查询所述数据库，以查找其转换后的定义数据匹配所述搜索查询的第一旅行产品类型和第二旅行产品类型的数据元素；

基于遵守组合规则，关联所述第一数据存储库和第二数据存储库的数据元素的所述一个或多个第一元素费用和所述一个或多个第二元素费用；

根据遵守组合规则的所述元素费用的关联，构成第一旅行产品类型的数据元素和第二旅行产品类型的数据元素的至少一个付费的集合；以及

对于所述第一元素费用和所述第二元素费用的第一关联：

确定所述第一关联是否遵守至少一个组合规则；

如果确定所述第一关联遵守所述至少一个组合规则，则使所述第一关联生效；以及

如果确定所述第一关联不遵守所述至少一个组合规则，则使所述第一关联无效，以使得所述第一关联被从所述至少一个付费的集合排除。

2.按照权利要求1所述的方法，其中所述查询包括定义从搜索参数得到的多个组成部分的数据，针对所述多个组成部分的每一个将搜索至少一个数据元素。

3.按照权利要求1所述的方法，包括定义从搜索参数得到的并且将为其搜索至少一个数据元素的多个组成部分；以及

为每个组成部分定义将为其搜索至少一个数据元素的所述第一旅行产品类型和所述第二旅行产品类型。

4.按照权利要求1所述的方法，其中定义数据包括费用数据、可用性数据和申请规则数据。

5.按照权利要求1所述的方法，其中所述第一旅行产品类型和所述第二旅行产品类型包括下述中的至少两种：

-航空旅行元素类型，

-铁路旅行元素类型，

-食宿元素类型，和

-租车元素类型。

6.一种处理数据搜索的系统，包括：

至少一个数据处理器，被配置为执行如权利要求1至5中的任何一个所述的方法。

7.一种用于处理搜索查询的系统，所述系统包括：

用于在处理器处获得来自于第一数据存储库和第二数据存储库的包括数据元素的定义数据的装置，其中来自于第一数据存储库的定义数据的数据元素具有第一数据结构，所述第一数据结构不同于来自于第二数据存储库的定义数据的数据元素的第二数据结构，所述第一数据结构包括第一旅行产品类型和一个或多个第一元素费用，所述第二数据结构包括不同于第一旅行产品类型的第二旅行产品类型和一个或多个第二元素费用；

用于利用所述处理器把来自于第一数据存储库的定义数据和来自于第二数据存储库的定义数据转换成共用一种通用数据结构的转换后的定义数据的装置；

用于将所述转换后的定义数据存储在数据库中的装置；

用于在将所述转换后的定义数据存储在数据库中之后，在搜索引擎处接收所述搜索查询的装置；

用于用搜索引擎查询所述数据库，以查找其转换后的定义数据匹配所述搜索查询的第一旅行产品类型和第二旅行产品类型的数据元素的装置；

用于基于遵守组合规则，关联所述第一数据存储库和第二数据存储库的数据元素的所述一个或多个第一元素费用和所述一个或多个第二元素费用的装置；

用于根据遵守组合规则的所述元素费用的关联，构成第一旅行产品类型的数据元素和第二旅行产品类型的数据元素的至少一个付费的集合的装置；以及

用于对于所述第一元素费用和所述第二元素费用的第一关联执行以下操作的装置：

确定所述第一关联是否遵守至少一个组合规则；

如果确定所述第一关联遵守所述至少一个组合规则，则使所述第一关联生效；以及

如果确定所述第一关联不遵守所述至少一个组合规则，则使所述第一关联无效，以使得所述第一关联被从所述至少一个付费的集合排除。

8.按照权利要求7所述的系统，其中搜索引擎是低费用搜索引擎。

9.按照权利要求7或8所述的系统，包含保存在非临时性计算机可读存储介质中的计算机软件，所述计算机软件由构成所述系统的一部分的至少一个数据处理器执行。