CN103493076B - 用于优化重复的搜索请求的改进预订系统的方法和系统 - Google Patents

Abstract

按照本发明的优选实施例的方法可以实现对向全球分销系统(GDS)请求旅行建议的最终用户的改进的旅行请求服务。这使用了新的旅行请求，与现有技术的以前的旅行请求相比，所述新的旅行请求包含每个搜索参数的更宽范围。新的旅行请求把许多不同范围的参数包含在相同的旅行请求中，而现有的旅行请求必须关于每个搜索参数的每个不同请求值被重复。按照本发明的优选实施例的方法提供两个模块，主模块和工人模块的组合来实现改进的旅行请求服务。

Description

用于优化重复的搜索请求的改进预订系统的方法和系统

技术领域

本发明涉及预订系统的领域，尤其涉及用于优化重复的搜索请求的大规模计算平台的方法和系统。

背景技术

例如与为如航班订票之类的购物业务提供航班搜索应用的航空公司预订系统一样，现有的预订系统的状态通常基于专用的全球分销系统(GDS)。来自客户的航班搜索请求要求穷举搜索GDS数据。这涉及大量的计算，从而会花一些时间。为了使延迟降至最小，客户通常自由度极少：他们必须指定所请求的旅程的出发城市和到达城市，出发日期和返回日期，承运人，舱位等级。尽管这有利于系统性能和响应时间，但是对肯定重视参数选择中自由度更高的更加用户友好的交互作用的用户来说并不理想。

航空公司和旅行社开发的高度重视用户请求的管理的另一个业务领域是所谓的预购。就术语“预购”来说，我们指的是需要通过预订系统，询问数据库，但是不一定导致适当的预约的那些活动。这些活动对航空公司或者旅行社至关重要，因为即使它们不产生直接的收入，也会影响潜在顾客的未来选择。能够向客户的具有许多自由度的查询提供零延迟响应的工具会得到高度肯定。例如，假定客户请求在6月和9月之间，到某个阳光灿烂之地2周之久的始发于巴黎航班的信息。就常规的航班搜索应用来说，客户需要指定明确的目的地，并进行与期望的目的地和可能日期的各种组合一样多的请求。

再一种可能的应用会是具有目的在于提高盈利能力，而不是简单地增加航班订票的收益管理处理的预订系统。例子：航空公司可能想根据依赖于航空公司提出的航班(例如，所有日期，所有城市)的所有价格的计算机模型，和根据订票预测，调整其价格。就现有系统来说，该活动会非常复杂，会花费大量的资源和工作人员劳动。

另一种可能的应用是为了统计起见的费用分析，即，按照提交给GDS的更新，密切注意票价的演变。例子：通过根据提交的费用和规则计算的旅程价格的比较，相似项目的当前价格与先前价格的比较，与自己的成本估计的比较，评估提出的价格。

上述应用例子的共同特性是需要非常大量的相关的航班推荐。

例如，预购应用需要较大的一组解决方案，以向客户提供吸引人的结果，收益管理应用需要航班推荐的穷举列表，因为其动态定价策略依赖于该模型，而费用分析应用需要航班推荐的穷举列表，以便有效地跟踪价格演变。

与购物业务领域相反，这些应用的目的不是预约。因而，不需要对每个客户的查询进行产生航班推荐的计算：可以用响应精度换响应时间。由于不需要为每个客户的查询重新计算航班推荐，因此其GDS的预计算会延续几个小时。另外，由于这些应用依赖于预先计算的航班推荐，因此GDS会使支持这些系统所需的数据处理延续数小时。

一种实现上述应用的已知方法是所谓的事务外部射手(shooter)。为了穷举地支持其预购或收益管理系统，顾客可向GDS提供的购物应用投射一系列的事务。待投射的事务必须覆盖所有期望的出发日期、所有期望的市场等的组合。这种方法具有一些明显的缺陷，例如，查询数目的微小增大就会导致计算复杂性大大增大，从而增大顾客必须投射的事务的数目。对应于全局请求的投射事务收集对于每个事务必须计算的公共部分：从而进行冗余检查，冗余数据存取和冗余处理。计算数据的量越大，这些冗余操作的成本越高(就资源消耗来说)。即使投射应用提供扩展的日历或者多选项选择，由于缺少关于要投射的所有事务的全盘了解，因此优化机会仍然是局部的。对顾客来说，结果的计算需要更多的处理时间。对GDS来说，由于冗余计算，它导致不必要的资源消耗。此外，由于射手在GDS之外，因此资源消耗不受控制。并且由于预购、收益管理或费用分析系统对数据的需求巨大，预料之外的大量流量会危及与其他顾客的服务水平协定。

另一种已知技术是实现预购系统，其中能够捕捉购物流量以更新该系统。对客户出于预约而请求的任何事务来说，如果它匹配预约系统的要求，那么其结果就既被返回给客户，又被返回给预购服务器。这种现有方法的缺陷在于顾客不能控制用于计算的数据。从而，不适合于支持收益管理系统，因为不能保证结果是穷举的。此外，捕捉流量是一种静态方法，不适合于具体的约束条件。预购和收益管理系统只能受益于现有产品的特性。

为了确定有效地处理上面说明的大量的数据，而不需要密集的操作人员活动和不可接受的资源使用，需要一种改进的能够实现大规模搜索，同时避免查询的无用重复的预订系统。

专利US5,495,606公开一种改善数据库中的搜索处理的系统。该系统可被增加到现有技术的现存系统中，以改善现存系统的处理时间。US5,495,606公开一种包括都能够并行工作的几个查询处理器模块的系统。每个查询处理器模块包括主查询处理器和从属处理器。主查询处理器接收查询，并把响应送回给最终用户。主查询处理器包含查询分解器，以把查询分成多个分解查询。主查询处理器还包含调度器，以便在适当的从属查询处理器上处理所述分解查询。每个从属查询处理器随后可把每个分解查询提交给特定的数据库管理器，以便只读地访问数据库。结果，每个查询处理器模块能够并行地处理所有的分解查询，从而优化处理时间。由于数据库为只读配置，因此在分解查询的处理期间，不会发生数据库的更新；这也改善了分解查询的处理时间。在US5,495,606中公开的方法需要具有多个处理器的非常强大的数据处理系统，未解决搜索请求的可能重复的问题：相同的查询可能被重复数次，因为不存在系统进行的请求的优化。

发明内容

本发明的目的是减轻与现有系统相关的至少一些问题。

按照本发明的一个方面，提供一种在预订系统中管理预购旅行查询的方法，所述预订系统具有按照多个参数到包含关于旅行可行性和费用的信息的多个旅行数据库的访问，每个旅行查询包括一组优先选择，每个优先选择与从所述多个参数中选择的一个参数相关，所述方法包括：接收多个旅行查询，每个旅行查询与用户相关；预处理所述多个旅行查询，所述预处理包括：从每个查询中提取至少一个简单请求要素；按照至少一个参数，对多个请求要素分类；在不止一个请求要素包含对于相同的至少一个参数的相同优先选择的情况下，删除重复的请求要素；按照预定标准，把请求要素分成子集；把请求要素的每个子集转发给处理模块，所述处理模块通过询问多个数据库，完成该请求要素；从各个处理模块收集结果，并对于每个旅行查询向用户发送响应。

按照本公开的第二方面，提供一种包含适合于实现上述方法的一个或多个组件的系统。

按照本发明的另一个实施例，提供一种计算机程序，所述计算机程序包含当在计算机系统上执行所述计算机程序时，实现上述方法的指令。

按照本发明的优选实施例的方法可以实现对向全球分销系统(GDS)请求旅行建议的最终用户的改进的旅行请求服务。这使用了新的旅行请求，与现有技术的以前的旅行请求相比，所述新的旅行请求包含每个搜索参数的更宽范围。新的旅行请求把许多不同范围的参数包含在相同的旅行请求中，而现有的旅行请求必须关于每个搜索参数的每个不同请求值被重复。

按照本发明的优选实施例的方法提供两个模块，主模块和工人模块的组合来实现改进的旅行请求服务。主模块提取来自所有用户的旅行请求。主模块把旅行请求分成单一的请求，并除去重复的旅行请求，从而获得优化的旅行请求。主模块随后把优化的旅行请求转发给工人模块。根据优化的旅行请求的内容，工人模块直接运行用于所需计算的对应处理模块，比如旅程处理模块，可行性处理模块或费用引擎处理模块。结果，工人模块根据优化的旅行请求，提供搜索结果。工人模块随后把优化的旅行请求的结果提供给主模块。主模块随后向最终用户显示所述结果。

按照本发明的优选实施例的方法基于处理来自用户的广泛旅行查询的两个模块，主模块和工人模块的实现。主模块分析来自所有用户的所有旅行查询，以提供优化的旅行请求。工人模块处理优化的旅行请求，并提交给特定的处理模块。

用于预购、收益管理和费用分析系统支持的数据计算方法与已在购物业务中使用的其它GDS子系统(旅程解答处理、可行性检查处理、计费处理…)交互作用。

利用本发明方法的优选实施例获得的一些优点是：

-平台提供的产品能够实现预购和收益管理系统的穷举并且一致的支持。由于业务规则和实现业务逻辑的适用插件，本发明允许对顾客需求快速作出反应。对GDS来说，支持关于大规模的航班和价格计算的新应用较为简单。

-对GDS来说，由于数据计算的优化，使资源消耗合理化，从而降低成本。

-此外，资源受到控制。资源是按照待处理的量和待考虑的时间范围动态分配的，而不会达到系统的极限。

附图说明

下面将参考附图，举例进行说明，附图中：

图1是按照本发明的一个实施例的预订系统的大规模计算平台的示图；

图2是适合于支持本发明的优选实施例的一般计算机系统的示图；

图3表示实现本发明的优选实施例的系统的软件组件，和按照本发明的优选实施例的方法的所有步骤的整体示图；

图4-9示意地表示方法的各个步骤；

图10是按照本发明的一个实施例的处理的方法步骤的流程图。

具体实施方式

图1表示按照本发明的优选实施例的专用于大规模的航班和价格计算的子系统101。数据处理与专用于订票的购物业务分离。

该子系统管理具有高自由度的查询，而不是用于订票应用的事务。自由度应用于例如日期组合(一年中的所有出发日期，出发日期之后的数周内的所有返程日期)，出发地和到达点的地理区域，所请求的承运人(所请求的一对城市的一个、几个或者所有的可能承运人)，所有可用的订票代码，所有可能的乘客类型。由于对这样的数据计算来说，低等待时间不是强制性的，因此时间范围可不同于真实的时间。处理和资源消耗从而可能延续更长的时间范围。结果的返回也会延续该时间范围。

在本发明的优选实施例中，按照批量模型组织子系统，所述批量模型的资源可被动态例示，以应付大量的数据。子系统根据全局查询分析，进行数据处理优化。

另外，子系统是通用并且可扩展的。不同的业务逻辑可被容易地插入子系统中，以满足不同的顾客要求(预购、收益管理、费用分析)。

在本发明的优选实施例中，子系统101包括一个或多个Massive Master103和多个Massive Worker105。Massive Master103全局分析查询，查询随后被分解成优化的请求。请求随后由一个或多个Massive Worker处理，结果被返回给始发的Massive Master，该Massive Master把结果集合成旅程解答加上价格。

参考图2，系统的普通计算机(例如，计算机、预订服务器、Massive Master服务器、Massive Worker服务器、数据库管理子系统、路由器、网络服务器)用250表示。计算机250由并联连接到系统总线253的几个单元构成。具体地，一个或多个微处理器256控制计算机250的操作；RAM259被微处理器256直接用作工作存储器，ROM262保存计算机250的基本引导代码。外围单元群集在局域总线265周围(借助相应的接口)。特别地，大容量存储器由硬盘268和读取CD-ROM274的驱动器271组成。此外，计算机250包括输入装置277(例如，键盘和鼠标)，和输出装置280(例如，监视器和打印机)。网络接口卡283用于把计算机250连接到网络。桥接单元286连接系统总线253和局部总线265。每个微处理器256和桥接单元286可起请求访问系统总线253，以便传送信息的主代理作用。仲裁器289管理对系统总线253的互斥访问的准许。如果系统具有不同的拓扑，或者系统基于其它网络，那么类似的考虑因素也适用。另一方面，计算机具有不同的结构，包括等同的单元，或者由其它数据处理实体(比如PDA、移动电话机等)构成。

在本发明的优选实施例中，子系统进行目的在于识别查询之间的相关冗余，以避免无用的再处理的全局分析。冗余查询部分的合并必须在资源消耗方面和在处理期间的数据存取方面是高效的。子系统必须同时满足功能和技术要求：它必须一方面考虑到与顾客建立的服务级别协定(时间约束，质量)，另一方面考虑到运营要求(资源控制，对其它组件的影响)。本发明的优选实施例的子系统包括两种服务器：

Massive Master服务器，该服务器托管(host)为最佳地管理输入和输出所需的全局智能。

Massive Worker服务器，该服务器实现插在大规模计算平台上的每个产品的业务逻辑。

图3表示按照本发明的优选实施例的处理的流程。整个流程可被分成可并行进行的以下6个步骤/操作：

-分离（SPLIT），其中Massive Master服务器从顾客查询中提取所有的单一请求；

-优化（OPTIMIZATION），其中Massive Master服务器进行全局分析，以便实现智能的请求合并；

-分配（ASSIGNATION），其中Massive Master服务器灵活地把请求路由到MassiveWorker服务器；

-计算（COMPUTATION），其中Massive Worker服务器处理优化的请求；

-流式传输（STREAMING），其中Massive Worker管理结果量；

-聚合（AGGREGATION），其中Massive Master服务器按照客户查询，聚合结果。

在以下的段落中详细说明各个步骤。

图4表示分离操作，即，从顾客接收的查询中提取单一请求的示意图。分离操作由把查询转换成单一请求组成。单一请求是无自由度的事务的逻辑等同物：每个日期、地理、乘客、承运人信息被设定。

输入管理模块401检测顾客提出的一组查询。如果在给定时间，未收到任何查询，那么输入管理模块401也可决定处理先前处理过的一组查询。借助该特征，不强迫顾客在预定的时间间隔(例如，每天)内提出一组查询。输入管理步骤还决定每个查询的处理频度：例如1天1次或几次。输入管理模块401还确定处理输入量的任务例示。按照查询数目和关于该顾客建立的处理时间范围，评估后续各个步骤的所需资源。这保证以限定的延迟计算大规模的数据。

输入检查模块403依照句法和语义地检查输入。由于该步骤取决于产品，因此添加不同的插件，以管理不同的输入类型。对于新产品或新产品型式，增加新的插件。

提取模块405根据顾客在查询中给出的语义信息，创建单一请求。提取取决于产品和顾客给出的输入。于是，该步骤是可插入的。

此外，对于一些顾客功能约束，可以应用业务规则。

在这种情况下应用的业务规则的例子可以是：关于国内市场请求更好的可行性质量(例如，向航空公司轮询可行性)。

图5表示优化操作，即，顾客的请求的全局分析的示意图。一旦生成了单一请求，另一个阶段关注合并冗余部分，以便实现计算优化。该操作由下面详细说明的几个步骤组成。全局分析模块501识别单一请求中的冗余。为了实现有效的优化，该步骤基于为每个产品定义将被聚合成组的最相关的冗余的插件。

合并模块503将各单一请求聚合成组，以避免冗余处理。几种智能合并都是可能的。聚合成组的选择从而既基于定义特定于产品的的最佳规则的插件，又基于适合顾客功能约束的业务规则。

业务规则例子：请求聚合成组基于顾客期望的时间范围处理。国内市场请求必须在结束办公之后、从而在最后的可能的手动更新之后被处理，而其它市场请求可以立即被处理。

对定期处理的查询来说，生成的结果的重要部分将在每次处理都相同。试探模块505统计地识别应产生除在前次处理返回给顾客的那些结果之外的相同结果的请求。这些请求将不被处理。从而减少不必要的价格计算。该模块节约资源消耗。仍然保证全局结果的良好准确性。

图6表示分配操作，即，驱动请求处理的示意图。一旦产生了第一个合并的请求，就处理该请求。与前面说明的步骤并行进行的分配步骤驱动按照资源把请求分派给MassiveWorker服务器。该操作由如下所述的不同模块实现的几个步骤组成。请求提供器模块601按照根据其生成请求的查询，选择要发送给Massive Worker服务器的请求。该模块的用途是允许系统逐渐地把顾客的查询的结果返回给顾客。选择请求，以计算查询的全局结果。一旦计算了该查询的结果，就选择与另一个查询相关的请求。另一个选择标准是每个合并请求的规定的处理时间范围。例如，一些请求处理被延迟到航空公司结束办公之后。于是，用于结果计算的数据的最后的手动更新可被考虑到。

调步（pacing）和优先权模块603通过避免使Massive Worker 服务器过载，按照可用资源调整Massive Worker服务器活动。它还管理待处理的请求之间的优先权。例如，已按快速跟踪模式请求了一组查询，从而必须以比一组标准查询更高的优先权处理该组查询。更多的资源专用于这些查询的计算。

Massive Worker服务器锁定器模块605选择处理必须在该处被处理的MassiveWorker服务器群。该选择既基于技术考虑(Massive Worker服务器的资源可用性)，又基于功能考虑(Massive Worker服务器专用于一些市场、产品或顾客)。

图7表示费用计算（FARE COMPUTATION）操作，即，业务逻辑的示意图。MassiveWorker服务器实现由按照本发明的优选实施例的方法提供的所有产品的业务逻辑。

请求解码模块701对Massive Master服务器提供的优化的请求解码。随后通过调用GDS中的现有的不同模块，驱动该处理。被调用的模块和调用顺序取决于产品。每个被调用的模块基于特定于每种产品的适用插件。

旅程处理模块703实现请求的航班解答的计算。它负责根据在请求中给出的日期、地理和选项信息，识别旅程组合。旅程处理依赖于最新的数据。

可行性处理模块705实现旅程解答可用性的检查。为了获得更好的质量水平，可以直接对航空公司进行请求，以依赖于更加最新的数据。

费用引擎处理模块707按照在请求中给出的信息和选项，实现对该请求的各个可能解答的价格计算。如果只要求较好的解答，那么费用引擎处理模块707还比较价格，以只保留最好的解答。

图8表示流式传输操作，即，管理原始结果的示意图。

为了管理计算产生的大量结果，需要优化与Massive Master服务器的通信和结果的存储的操作。下面详细说明的Massive Worker服务器上的几个模块允许这种优化。

压缩模块801减小结果的大小，从而降低Massive Worker服务器和MassiveMaster服务器之间的通信量。保存的数据量也被减小。由于该操作消耗处理资源，因此只有当计算的增益和存储资源消耗相应时，才应用该操作。

分离/缓冲模块803也允许资源消耗优化。如果产生的结果的结果量太高，那么产生的结果被分成几堆。从而同时进行与Massive Master服务器的通信和数据存储。

如果结果量太低，那么缓冲该结果，直到适合由Massive Master服务器管理为止。由于只需要处理相关结果量的很少的存储模块，因此通信更加高效。

Massive Master服务器锁定器805选择Massive Master服务器。该选择既基于技术考虑(Massive Master服务器的资源可用性)，又基于功能考虑(Massive Master服务器群专用于一些市场、产品或顾客)。

图9表示聚合操作，即，管理顾客输出的示意图。

一旦产生了查询的所有结果，这些结果就必须被聚合，并按照适当的格式返回给顾客。聚合结果模块901把来自Massive Worker服务器的原始结果变换成价格导向的结果。随后按照顾客查询聚合结果：顾客获得对其问题的回答，而不是混乱的结果。例如，如果顾客以几种选项，并且关于一年中的所有出发日期，在查询中请求特定市场的解答，那么与查询的所有选项和所有出发日期对应的所有解答将被聚合在答复中。插件为每种产品和每个顾客定义预期的结果格式。

Diff模块903是选择已从先前的处理变化的结果的价格打包选项。只有反对结果的新的更新才被返回给顾客。插件按照产品定义区别的标准。这种选项允许GDS和顾客之间的高效网络传输。此外，由于要管理的结果量较少，因此顾客系统上的活动被减少。

压缩和加密模块905通过减少返回的结果量，并使结果保密，允许高效并且安全的网络传输。

滴流返回模块907通过对处理过的查询的全局结果聚合成组，定期进行传输。从而，返回延续较长的时间。

由于结果的量巨大，因此在把结果结合到其预购或收益管理系统之前，顾客不能等待处理的结果。于是，在开始处理之后的几分钟，产生并返回第一批结果。传输延续整个处理时间范围。从而，结果可被逐渐结合到顾客的预购或收益管理系统中。

应用例子

例1：预购系统的产品

我们考虑专用于预购系统支持的产品。对于与指定的一对城市和承运人匹配的每个航班解答，它计算出发日期和停留时间的所有组合的最低适用价格。计算依赖于通过价目表发布者的中介自动提交给GDS的所有数据。只有当航班有空座位时，才返回推荐。由于检查空座位会消耗许多资源，因此只对把顾客的合伙人作为承运人的查询才进行该操作。

通过创建单一请求，归因于业务规则，分离模块能够识别请求中的合伙人，并标记这些请求，以便使得能够实现“空座位检查”。

优化模块合并旅程请求，以防止由日期组合引起的冗余。合并操作利用考虑到特定于该产品的费用引擎处理的优化的插件。

例2：收益管理系统的产品

我们考虑专用于收益管理支持的产品。对于与指定市场匹配的每个航班解答，它计算出发日期、停留时间、提前购买条件和预约订位代码(下面称为RBD)的所有组合的最低适用价格。在整个旅行中必须使用相同的RBD。该计算依赖于通过价目表发布者的中介自动提交给GDS的所有数据。出发日期在接下来的45天内的请求的计算必须依赖于在一天中的办公时间内由顾客手动提交给GDS的所有数据。

优化模块捆扎日期组合和提前购买，以优化旅程解答的计算。在合并时，它应用业务规则来分开出发日期在接下来的45天内的请求。其处理被延迟到顾客结束办公之后，以考虑到提交给GDS的手动更新。

费用计算模块利用返回航班解答的RBD的专用旅程处理插件。它不使用可用性处理插件，因为产品并不专用于购物或预购业务。

由于对于每个优化的请求，该产品产生数千个结果(归因于日期，提前购买和RBD的组合)，因此流式传输模块在Massive Worker服务器上进行原始结果的分离。

在图10中所示的图中也表示了上述方法。所述方法始于黑圆1001，随后进入方框1003，在方框1003，系统接收旅行查询。所述查询由寻找预购信息，即，例如关于旅行可行性、费用、时间的信息或者不一定目的在于完成预订的信息的用户发出。在本发明的优选实施例中，接收查询并进行数据库查询以满足用户查询的系统与实际的预订系统分开，不过本领域的技术人员会理解这两个系统(预购和预订)可以结合在一起。一旦收到旅行查询，控制就转到方框1005，在方框1005，进行查询的预处理。调用预处理的时刻或者触发预处理的开始的事件可取决于几个因素，甚至可由系统管理员或者由各个用户定制：例如，可以每隔预定的一段时间(例如，在一天结束时，或者每小时)进行预处理；当收到大量的紧要查询时，或者当达到最大容量时，可以自动进行预处理；或者同样可由管理员或者由用户请求。按照本发明的优选实施例，旅行查询的预处理包括被分解成简单的请求要素(在图3中也称为“单一请求”)，以便优化数据库查询活动的各个查询的全局分析。在本发明的优选实施例中，每个查询由提取一个或多个简单的请求要素的Massive Master服务器(预处理模块)分析。这些简单的请求要素随后被重新排列，以避免重复，和按照考虑到几个因素的预定标准以及业务规则被组织(分割)成子集(在图3中也称为“优化的请求”)，如上参考图5所述。继续该预处理，直到预处理了所有旅行查询为止(步骤1007)。一旦处理已被优化，MassiveMaster服务器就把每个子集分配给合适的Massive Worker服务器，并把请求子集转发给合适的Massive Worker服务器(步骤1009)。每个Massive Worker服务器随后在数据库中进行查询，以满足用户的请求，例如，旅行费用、旅行可行性。查询的结果随后被收集，并被传回给Massive Master服务器，以便通过发送响应，提供给提出旅行查询的用户(步骤1011)。在本发明的优选实施例中，在被提供给用户之前，结果由MassiveMaster服务器聚合，如上所述。处理随后在步骤1013结束。在上面参考图10说明的例子中，进行所述方法的系统包括一个MassiveMaster服务器和多个Massive Worker服务器，不过其它实现也是可能的，例如，不止一个Massive Master服务器并行地工作，或者甚至只有一个Massive Worker服务器处理多个子集。另外，Massive Worker服务器和Massive Master服务器不一定对应于不同的物理机器，相反它们可以仅仅是在相同的系统上工作的应用程序。

应理解可以对上述实施例作出各种变更和修改，而不脱离本公开的范围。自然地，为了满足局部和具体的要求，本领域的技术人员可以上述解决方案应用许多修改和变更。特别地，尽管关于其优选实施例，以一定程度的特殊性说明了本公开，不过应明白形式和细节方面的各种省略、替换和改变，以及其它实施例都是可能的；此外，作为一般的设计选择，结合本公开的任何公开的实施例说明的具体元件和/或方法步骤显然可被包含在任何其它实施例中。

如果按照不同的方式构成程序(所述程序可用于实现本公开的每个实施例)，或者如果提供另外的模块或功能，那么类似的考虑也适用；同样地，存储器结构可以是其它种类的存储器结构，或者可用等同实体替换(不一定由物理存储介质构成)。此外，提出的解决方案适合于利用等同的方法(具有类似或者另外的步骤，甚至顺序不同)实现。总之，程序可以采取适合于由任何数据处理系统使用，或者与任何数据处理系统结合使用的任意形式，比如外部或驻留软件、固件或微代码(目标代码或者源代码)。此外，可以在任何计算机可用介质上提供程序；所述介质可以是适合于包含、保存、传递、传播或传送所述程序的任何元件。这种介质的例子可以是固定磁盘(程序可被预先载入其中)、可拆卸磁盘、磁带、卡、导线、光纤、无线连接、网络、广播波等等；例如，所述介质可以是电子、磁、光、电磁、红外或半导体式介质。

总之按照本公开的解决方案适合于用硬件结构(例如，集成在半导体材料的芯片中)，或者用软件和硬件的组合实现。

Claims (8)

1.一种在预订系统中按照非约束旅行查询产生附有定价的旅行解答的方法，所述预订系统能够按照多个参数访问包含关于旅行可行性和费用的信息的多个旅行数据库，每个旅行查询包括一组优先选择，每个优先选择与从所述多个参数中选择的一个参数相关，所述方法包括：

-接收多个旅行查询，每个旅行查询与用户相关；

-预处理所述多个旅行查询，所述预处理包括：

-从每个查询中提取至少一个简单请求要素；

-按照至少一个参数，对多个请求要素进行分类；

-在不止一个请求要素包含对于相同的至少一个参数的相同优先选择的情况下，删除重复的请求要素；

-按照预定标准，将多个请求要素分割成子集以避免冗余处理；

-将请求要素的每个子集转发给处理模块，所述处理模块通过询问多个数据库执行该请求要素；

-从各个处理模块收集结果，并针对每个旅行查询向用户发送响应。

2.按照权利要求1所述的方法，其中在向用户发送响应之前，从处理模块收集的结果被聚合。

3.按照权利要求1或2所述的方法，其中执行请求要素的每个子集中的请求要素的步骤由多个处理模块并行地进行。

4.按照权利要求3所述的方法，其中分割多个请求要素的步骤包括按照预定标准，将每个子集分配给多个处理模块之一。

5.按照权利要求1或2所述的方法，其中预处理多个旅行查询的步骤由多个预处理模块并行地进行。

6.按照权利要求5所述的方法，还包括：

-对于每个请求要素的结果，处理模块选择多个预处理模块之一，以将结果转发给该预处理模块进行聚合并向用户发送所述响应。

7.按照权利要求1或2所述的方法，其中所述多个参数包括日期和地理位置。

8.一种用于管理预购旅行查询的数据处理系统，所述数据处理系统能够按照多个参数访问包含关于旅行可行性和费用的信息的多个旅行数据库，每个旅行查询包括一组优先选择，每个优先选择与从所述多个参数中选择的一个参数相关，其中所述系统包含适合于执行按照权利要求1-7中任一项所述的方法的一个或多个组件。