CN104169950A - 利用面向批处理的计算的数据库系统 - Google Patents

Abstract

一种数据库系统，包括计算平台和搜索平台。计算平台从搜索平台接收批量再计算指令。每个批量再计算指令指示计算平台计算多个数据库查询结果。计算平台通过在给定时间范围内，按照批处理时间表计算多个数据库查询结果，来处理批量再计算指令。计算平台把由批量再计算指令产生的计算的数据库查询结果返回给搜索平台。搜索平台把计算的数据库查询结果保持在存储器中，并使计算的数据库查询结果对连接到搜索平台的客户端可用。搜索平台向计算平台传送批量再计算指令。

Description

利用面向批处理的计算的数据库系统

技术领域

本发明涉及数据库技术的领域。更具体地，本发明涉及预先计算数据库查询结果，把预先计算的数据库查询结果保存在存储器中，管理存储器，使其最新，并使客户端可以获得预先计算的数据的复合系统。

背景技术

数据库技术中的常见问题是确保对需要处理大量数据的数据库查询的响应时间短。例如，必须响应所谓“开放查询”进行这种消耗计算能力的处理，所述开放查询只包含很少的输入信息(例如，只指定一打可能参数中的一个或两个参数和/或参数的指定值范围较宽)，从而通常产生大量的结果。通过提高硬件性能来加速数据处理的可能性有限。从而，促使关注改进成为大数据量处理的基础的机制。

提高查询处理性能的一种途径是并行性。如果可能，输入的数据库查询被分成几个子查询，并被分配给多个数据库客户端，所述数据库客户端并行地处理所述子查询。US 5,495,606记载了这种系统的一个例子。该专利公开一种数据库系统，所述数据库具有主处理器，主处理器具有分离器和调度器，以及几个并行工作的从属查询处理器模块。主查询处理器接收查询，把响应回送给最终用户。分离器把查询分成多个分离的查询。调度器把分离的查询分配给适当的从属查询处理器，所述适当的从属查询处理器并行地处理所述分离的查询。从属查询处理器的处理结果由分离器重新聚集，主处理器返回对整个查询的答案。

WO 98/32064 A2和US 5,822,747 A描述了类似的系统。

缩短查询时间的一种不同途径是预先计算预期的查询，并把对应的查询结果保存在存储器系统中。从而在发生数据库查询时，并不基于大量数据实际处理查询，而是把查询引导到存储器系统。从而，处理基础数据域和实际服务查询解耦。相反地，响应输入的查询，需要搜索预先计算的查询结果的存储器。

例如，US 2008/0262878 A1记载了这种存储器系统。该专利申请公开一种利用顾客旅行查询询问的旅行价格和可行性数据的存储器。所述存储器包括负责通过与一个或多个旅行产品预订系统的链接，更新存储器的管理器。通过轮询预订系统，进行保存在存储器中的数据的更新，所述更新或者在处理指向高速缓存的顾客查询的过程中进行(如果与基准日相比，相应的存储器数据过时的话)，或者当数据过期或者被认为“陈旧”或“过时”时，与所述顾客查询无关地进行。

US 2005/0108069 A1记载了这种存储器系统的另一个例子。这里，存储器平台连接到基础数据的一个或多个供应者。存储器具备预取器，所述预取器把查询提交给供应者数据库，并更新保持在存储器中的价格和可行性数据。当网络带宽和计算能力可用时，预取器例如可在夜间运行。它可被定期调用或者人工调用。

US 2003/0200194 A1、WO 2008/086146 A2、US 2009/0234682 A2和US 2008/0167906 A1进一步公开了类似的存储器系统。

伴随这种预先计算方法而来的问题是如何使预先计算的查询结果最新，以便确保利用预先计算的结果响应的查询正确地反映对应的大数据基础的状态。在基础数据变化的情况下，预先计算的查询结果变得过时，存储器系统会返回不正确的结果。从而，需要如何能够使存储器系统保持最新的策略。

现在技术中已知各种相对简单的更新策略，比如频繁地再计算整个数据域，人工建立和维护再计算时间表，当数据变得过于陈旧时，重新计算它们。例如，US 2005/0108069 A1记载了这样的策略。

提出了稍微更复杂的更新策略，例如如WO 01/33472和WO02/25557所述。

WO 01/33472涉及在旅行规划系统中使用的可行性系统。该系统包括具有关于航班座位的可选信息条目的存储器。管理器管理存储器中的条目信息，以便使存储器中的信息保持正确、最新、完整或者尽可能有用。响应指向存储器的查询，管理器判定保存的答案是否陈旧，如果是，那么把可用性查询发送给可用性信息的源头。依据来自外部系统的异步通知获得并利用确定性、预测性或统计性模型确定要修改的存储器条目。

类似地，WO 02/25557涉及一种信息检索系统，其中从信息源接收的信息被预先计算，供未来使用，比如用于未来的客户端请求。可以产生主动查询，以填充存储器和/或更新当前预先计算的信息。在航班信息系统中，根据统计数据或预测指示，比如起飞时间的接近，预先计算的数据的寿命，飞机中的剩余座位，节假日或特殊活动，或者设备种类，指令主动查询。另外，依据来自航空公司的外部通知，比如AVS消息，接收更新。

发明内容

为了确保有效地处理大量的数据，而不需要密集的操作员工作和不可接受的资源使用，需要一种能够避免查询的无用重复而进行大规模搜索的改进型预订系统。

按照本发明，提供一种复合数据库系统。该数据库系统由几个组件，即，计算平台和一个或多个搜索平台构成。可选地，另外还存在再计算触发平台。

计算平台被布置成接收来自搜索平台，和来自再计算触发平台(可选)的批量再计算指令(batch re-computation order)。每个批量再计算指令指示计算平台计算多个数据库查询结果。计算平台还被布置成通过按照在给定时间范围内的批处理时间表计算在批量再计算指令中指示的数据库查询结果，来处理批量再计算指令，并把由批量再计算指令引起的再计算的数据库查询结果返回给至少一个搜索平台。

所述至少一个搜索平台被布置成把预先计算的数据库查询结果保存在存储器中，使连接到搜索平台的客户端可以得到预先计算的数据库查询结果，和把批量再计算指令传送给计算平台。

可选地，存在再计算触发平台，再计算触发平台被布置成维持利用计算平台计算的预先计算的数据库查询结果的镜像，确定镜像的预先计算的数据库查询结果过时的可能性，和关于与其它预先计算的数据库查询结果相比，过时的可能性较高的一部分预先计算的数据库查询结果，向计算平台发出批量再计算指令。

作为另一个方面，提供一种处理和显示数据库搜索结果的系统。按照该系统，首先按照给定类别对数据库搜索结果分类，随后作为第二步骤，在所述类别之内对数据库搜索结果排序。这样，可按照结构化并且用户有用的方式，在客户端呈现数据库查询结果。

附图说明

现在举例参考附图，附图中：

图1图解说明分布式数据库系统的例证概况；

图2是计算平台的例子的示图；

图3表示实现本发明的例子的系统的软件组件，和按照本发明的例子的方法的所有步骤的全景；

图4-9表示由计算平台执行的计算方法的各个部分的示意例子；

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

图11是是按照本发明的一个实施例的预购预订系统的大规模搜索平台的示图；

图12表示实现本发明的大规模搜索平台的可能的预订系统；

图13-18表示按照本发明的一个实施例的预购预订系统的大规模搜索平台的各个模块组件的细节；

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

图20表示就再计算触发平台而论的数据库系统的例子的更详细示图；

图21图解说明再计算触发平台的例子的各个组件；

图22描述触发再计算的例证方法的流程图；

图23表示用于进行再计算的计算平台的资源可用性的例子；

图24是表示旅行选项搜索结果选择系统的工作环境的方框图；

图25是旅行选项搜索结果选择系统的例子的高级功能图；

图26是可由旅行选项搜索结果选择系统执行的特色结果选择算法的流程图；

图27是利用图3的选择算法提供的特色结果的网页展示的示意图；

图28表示分别实现计算平台、搜索平台和再计算触发平台的计算机的示意例证表示。

具体实施方式

本发明总体涉及布置成使客户端(比如最终用户计算机，顾客，例如门户网站，或者其它查询实体)可以得到大量的数据集的信息处理系统。为了能够处理需要基于大量基础数据的计算的数据库查询，通常预先计算与预期的查询对应的数据库查询结果，并保存在存储器中，以便允许快速访问预先计算的数据库查询结果。响应实际发生的查询，预先计算的结果被返回给查询实体。

图1中表示了本发明的信息处理和数据库系统1的示意体系结构。基本数据被保持在连接到搜索平台3的计算平台2中。尽管图1只表示了一个搜索平台，不过实际上可存在多个搜索平台3。搜索平台3保持预先计算的数据库查询结果的存储器，并连接到把数据库查询引向搜索平台3的客户端。搜索平台3被布置成根据保存的预先计算的数据处理这些查询，并把相应的查询结果返回给客户端。响应预先计算请求，计算平台2进行数据库查询结果的预先计算。所述预先计算请求或者由搜索平台本身产生，或者由本发明的系统1的另一个可选元件，即，再计算触发平台4产生。再计算触发平台4也连接到计算平台2。尽管图1把再计算触发平台4表示成物理独立的实体，不过，它也可或者并入计算平台2中，或者并入搜索平台3中。

随后，利用术语“查询”作为指的是事务信息检索的术语。这种事务查询由数据库系统立即、与查询的发生同步地处理。对应结果被尽可能快地返回给查询实体。面向事务的数据库系统广泛普及。例如，US5,495,606记载一种事务计算系统，它能够把事务查询分解成子查询要素，在子查询要素的层面，进行查询的处理。

一种不同的信息检索处理是批处理。按照这种方案，异步地、即稍后进行查询的处理。从而，处理实体不立即，而是稍后向查询实体返回对应结果。换句话说，查询的发生与其处理及对应响应是解耦的。面向批处理的处理允许例如产生确定何时、如何和由谁处理查询的处理“计划”。这样，能够考虑到在处理实体的可用计算资源。下面把面向批处理的查询称为“批量计算请求”或者“批量再计算指令”。

通常，如图1中所示的本发明的数据库系统1如下工作：计算平台2保持大量的基本数据，响应批量计算请求，预先计算数据库查询结果。在下面进一步详细说明的一个例子中，计算平台2保持的基本数据是与旅行相关的数据，比如包括城市对、日期、可选座位、机票价格等的航班数据。根据所述与旅行相关的数据，计算平台2计算包括特定价格的特定旅行提议。在这个例子中，这种附有价格的旅行提议构成由计算平台2提供给搜索平台3并保存在搜索平台3中的预先计算的数据库查询结果。搜索平台3使客户端可以得到保存的预先计算的数据库查询结果。连接到计算平台2的再计算触发平台4负责触发保持在搜索平台3中的预先计算的数据库查询结果的再计算，以便尽可能地使存储器内容最新。尽管搜索平台3中已包含基本的更新机制，不过，通过判定搜索平台3保存的预先计算的数据库查询结果是否过时的可能性，再计算触发平台4提供更复杂的存储器更新策略。为了作出这些判定，再计算触发平台4镜像利用计算平台2预先计算的预先计算数据库查询结果(另外，还可保持另外的管理数据和元数据)。这在下面进一步详细说明。

按照本发明的系统1，借助再计算指令，触发计算平台2进行的预先计算的数据库查询结果的计算，所述再计算指令或者由搜索平台3产生，或者由再计算触发平台4产生。再计算指令及其计算遵循面向批量的处理。这意味搜索平台3或再计算触发平台4发出的再计算指令指示保持或将包含在搜索平台3中的预先计算的数据库查询结果的整个集合或范围要被预先计算或再计算。可选地，再计算指令指示其中必须进行计算，并等待计算结果，以便处理再计算指令的时间范围。另一方面，计算平台2自主地确定相应的时间范围，或者计算平台2和搜索平台3/再计算触发平台4协商在再计算指令之外的时间范围。这种情况下，这意味再计算指令不指示执行所述指令和返回结果的时间范围。在收到批量再计算指令之后，计算平台2按照批处理时间表，处理该指令。可在分析再计算指令之后，并且考虑到在计算平台2的可用计算资源，设立批处理时间表。

在处理批量再计算指令之后，计算的相应数据库查询结果被返回给搜索平台3和再计算触发平台4两者(假定实际存在和实现了可选的再计算触发平台4)。从而，在再计算指令由搜索平台3发起的情况下，结果不仅被返回给搜索平台3，而且被返回给再计算触发平台4。另一方面，在再计算指令由再计算触发平台4发起的情况下，结果不仅被返回给再计算触发平台4，而且被返回给保持相应的预先计算的数据库查询结果的搜索平台3。特别地，如果存在多个搜索平台3，那么计算平台2把再计算的数据库查询结果传送给实际保持相应的预先计算的数据库查询结果的所有搜索平台3。如果特定的搜索平台3只保持一部分的再计算数据库查询结果，那么计算平台2只把相应部分转发给该搜索平台3。如果特定的搜索平台3不保持任何再计算的数据库查询结果，那么再计算的数据库查询结果不被转发给该搜索平台。按照这种方式，再计算触发平台4始终保持由计算平台2计算并保存在搜索平台3中的数据库查询结果的一致镜像。

计算平台2进行的计算通常适合于两个用途：主要地，当设立新的搜索平台3时，或者当计算平台2保持的基础数据域被扩大并且可获得另外的数据库查询结果时，它最初向搜索平台3供给预先计算的数据库查询结果。其次并且对本发明的系统更相关的是，它使更新或重新计算搜索平台已保持的预先计算的数据库查询结果更容易。这是必需的，因为本发明的高速缓存预先计算的查询结果，并且只通过处理预先计算的数据对输入的查询作出响应的方法导致基础数据域的数据会随着时间而变化，从而预先计算的查询结果变得过时的一般性问题。下面把仍然最新的，即，与对应的实时计算等同物(实际按需计算的结果，而不具有可用的高速缓存的预先计算结果)匹配的预先计算查询结果称为“准确的”保存的预先计算结果。从而，当存储器正确地表示成为预先计算查询结果的基础的数据域的当前状态时，预先计算结果的存储器通常准确。

通常，为了根据预先计算的数据库查询结果返回正确结果，想要维持响应数据库查询而提供给查询实体的预先计算的数据库查询结果和它们的实时计算等同物之间的高调度相关性。不过，同时理想的是使重新计算导致的计算资源消耗降至最少，即，避免任何不必要的再计算，比如仍然准确的预先计算查询结果的再计算。计算资源有限，从而通常没有足够的计算资源来时时重新计算所有保存的预先计算查询结果。从而，需要找出存储器中的数据库查询结果的准确表示和可用计算能力的利用之间的折衷。换句话说，需要何时生成再计算请求和生成什么再计算请求并引导到计算平台2的复杂方法。

在最初已简要说明的使预先计算的查询结果的存储器保持最新的简单方法具有几个缺点。

取决于数据量和可用计算资源，频繁地(例如，每天一次)重新计算整个数据域可确保存储器准确性和实时响应之间的合理平衡。不过，这种方法既难以缩放，硬件资源消耗方面又低效率。特别地，由于对应的基础数据未变，因此仍然有效的那些查询结果也被重新计算。

管理人员人工地精心策划再计算时间表，以确定在什么时候重新计算哪些查询结果证明对于特定用途来说是高效的，但是僵化，不灵活。当成为时间表的基础的假设和条件变化时，需要重新策划时间表。还不能动态跟踪在基础数据域(underlying data domain)巨大变化的情况下发生的保存的预先计算结果的正确性的突然恶化。另外难以人工设计这种时间表(例如，归因于缺少客观的质量标准)，和从人力成本来看难以维持。

另一种方法是当数据变得过于陈旧时，重新计算数据。不过，取决于基础数据和要预先计算的查询结果的性质，可能难以评估良好的“陈旧”阈值。为了使再计算更高效，应定义指标，以评估再计算有多“不必要”。例如，如果不到一半的计算查询结果变得过时，那么每天重新进行整个大规模的预先计算并不值得。另一方面，如果已知特定种类的查询结果频繁变化，那么每天几次重新计算它们有益于准确性。从而，考虑到准确性的关联增益和再计算的成本，需要评估或估计查询结果准确性的有效方式。

在本发明的系统中，可以采用各种更复杂的更新策略。基本策略可由搜索平台3实现，以致使搜索平台3本身能够把批量再计算请求引导到计算平台2。可选地，再计算触发平台4可采用另一种更新策略。再计算触发平台4实现的机制可以比在搜索平台3中预见的那些机制更复杂。

按照下面更详细说明的一个例子，搜索平台3通过向每个查询结果赋予更新频度，管理更新保存的预先计算的数据库查询结果的需要。更新频度是根据随机模型确定的，所述模型根据过去的统计数据，模拟相应的基础数据的变动性。另一方面，按照下面详细说明的例子，再计算触发平台4采用的更新策略另外还考虑会增大保持在搜索平台3中的一个或整个范围的预先计算数据库查询结果过时的可能性的实时事件。

按照在再计算触发平台4中实现的更新策略，根据预先计算的数据库查询过时(即，可能不同于利用另一个再计算获得的结果)的可能性，确定数据库查询结果的再计算。只有具有一定的已知不准确可能性的那些预先计算的查询结果才被重新计算，而可能仍然准确地反映基础数据(即，变得过时的可能性较低)的其它高速缓存的查询结果不被重新计算。

从而，取决于在搜索平台3和再计算触发平台4中实现的具体模型和高速缓存更新策略，这两个实体可在不同的时候向计算平台提出发起不同的预先计算数据库查询结果的再计算的再计算指令。

提交给计算平台2的批量再计算指令的一个例子是在最多24小时之内，重新计算约一百万个数据库查询结果的指令(当然，计算平台通常能够比约定的时间范围更早地交付其结果)。不过，取决于实际的系统，数据量(即，计算平台2中的基础数据域的数量，以及搜索平台3保持的预先计算的数据库查询结果的数目)，采用的硬件和软件，再计算约束可能显著更有挑战性。从而，批量再计算指令的另一个例子是在仅仅两个小时之内，重新计算约一亿个预先计算的数据库查询结果。借助目前可用的硬件和软件系统，24小时之内重新计算多达1亿个预先计算的数据库查询结果实际上是可能的。可想象随着计算资源的增大，甚至数量更大的批量再计算也是可能的。

可选地，计算平台2还被布置成分析批量再计算指令，并将其分解成与多个数据库查询结果的子集相关的较小计算包。通过全局分析批量再计算指令，并考虑到待处理数据的数量、必须在其间执行计算的时间范围以及可用的计算资源，进行所述分解。从而允许并行地处理整个批量计算请求的较小部分。计算平台2随后把分解获得的计算包分配给处理模块，以便执行计算包的计算。从而，与整个批量再计算指令相反，在较小的计算包的层面进行实际计算。处理模块可以是仅仅松散地耦接到计算平台2的从属计算站，比如局域网中的其它主机，或者是计算平台本身的集成部分，例如呈在计算平台2上运行的进程实例的形式。在后一情况下，有利的是计算平台2配备有多个处理单元，比如多核计算机。

处理模块随后大体并行地计算分配给它们的计算包，并把计算结果返回给计算平台2。计算平台2重新聚集计算包的这些计算结果，从而构成对批量再计算指令的总响应。最后，计算平台把重新聚集的结果返回给搜索平台3和再计算触发平台4。

在一种例证实现中，按照模块的两级分层结构，即主模块和一个或几个工作者模块，形成计算平台。在这个实现例子中，主模块负责接收批量再计算指令，进行全局分析、分解和把作为结果的计算包分配给工作者模块。工作者模块负责进行计算包的实际计算，和把计算结果返回给主模块。主模块还负责重新聚集工作者模块的结果，并把重新聚集的结果返回给搜索平台3和再计算触发平台4。

可选地，计算平台2分析并把批量再计算指令分解成较小的计算包包括把批量再计算指令分成原子计算事务的结构。这些原子计算事务可对应于诸如SQL语句之类通常的事务处理数据库查询。这些事务查询随后可被直接分配和转发给处理单元，并按照与批量处理相反的事务方式被处理。从而，尽管批量再计算指令指示计算平台2按照批处理模型再计算相应的数据库查询结果，不过，在细分的计算包层面的实际计算是面向事务进行的。可选地，在通过分解批量再计算指令来形成原子计算事务的过程中，进行关于冗余原子计算事务的分析。随后抛弃识别出的这种冗余原子计算事务。这样，避免多个相同查询的不必要计算，从而更有效地利用计算资源。可选地，进行原子计算事务到更大的计算包的分组(与把原子计算事务直接转发给处理模块相反)。从而，计算包通常由多个原子计算事务组成，不过通常小于总的批量再计算指令。在这种情况下，利用处理模块处理这些重新分组的计算包或者是按照批量计算进行的(即，计算平台2利用在分解之后的该较低层面的一种批处理指令，指示处理模块按批处理方式计算所述计算包)，或者是按事务方式进行的(即，计算平台2把查询提交给处理模块，处理模块立即处理计算包并立即返回相应结果)。可选地，计算平台被布置成按照批处理时间表，把计算包分配给处理模块，批处理时间表通过考虑到在给定时间范围内计算模块的可用计算资源，提供负荷分配。

按照一个实现例子，搜索平台3配有如下工作的基本更新机制：搜索平台3向它保存的每个预先计算的数据库查询结果赋予表示刷新频度的参数值。所述刷新频度分数基本上并且最初是根据关于保存的预先计算的数据库查询结果的变动性的过去经验设定的。例如，这些经验可用预测模型和/或统计数据模拟。刷新频度分数通过向计算平台2指示批量再计算指令，触发一部分的预先计算的数据库查询结果的更新。所述一部分的预先计算的数据库查询结果，即，待更新的具体的预先计算的数据库查询结果是根据赋予的分数确定的。即，每当刷新频度分数值指示，搜索平台3就把预先计算的数据库查询结果包含在批量再计算指令中。

按照其主要任务，搜索平台3响应从客户端收到的查询，在其存储器中进行数据库搜索。数据库搜索揭示满足包含在客户端的查询中的优先选择的那些预先计算的数据库查询结果。在处理查询并且找到对应结果之后，搜索平台3把响应发给查询客户端。不过同时，搜索平台3可被布置成更新赋予返回给客户端的那些预先计算的数据库查询结果的分数参数。例如，每当响应数据库查询，把搜索平台3保持的特定的预先计算的数据库查询结果返回给客户端时，可增大所述特定的预先计算的数据库查询结果的刷新频度分数。这样，刷新频度分数也适应于客户端的实际兴趣和需求：与客户端不太感兴趣，从而很少被客户端查询和返回给客户端的预先计算的数据库查询结果相比，受到更多客户端查询的预先计算的数据库查询结果通常被更频繁地更新。

如上所述，再计算触发平台4采用的更新策略可不同于搜索平台3实现的更新策略。可选地，利用再计算触发平台4更新预先计算的结果的策略一方面依赖于根据预测模型，估计预先计算的数据库查询结果的整个存储器的准确性的手段。另一方面，还检查这些估计是否通常和现实一致，从而核实在发生实际的实时(和真实)事件时，基于模型的再计算策略仍然有效，所述实时事件可充当成为保存的预先计算的数据库查询结果的基础的数据的相当大一部分已变化-从而归因于这些变化-对应保存的预先计算的数据库查询结果也过时的指示。

可选地，预先计算结果的准确性的估计所依赖于的预测模型模拟预先计算的查询结果和假定的实际数据库查询结果之间的差异，即，它近似任意高速缓存的查询结果的准确性或不准确性。例如，所述模型模拟预先计算结果随着时间的可能变动性。根据过去对于相应数据域的主题的现实世界体验，断定和推测关于预先计算结果的变动性的假设。

按照下面进一步详细说明的一个特定实现例子，基础数据可位于空中旅行的领域中，并包含关于航班的信息，比如出发机场和目的地机场，航空公司，发出日期和返回日期，票价，订位舱等等。所述与空中旅行相关的数据被保持在计算平台2中。根据基本航班数据计算价格是消耗资源和时间的。从而，预先计算实际价格并保存在搜索平台3中。用户为了了解航班的可用性和价格的旅行查询于是不被引导到计算平台2，而是被引导到搜索平台3。如上所述，再计算触发平台4负责更新搜索平台3的存储器(除了搜索平台3本身的基本更新机制之外)。

在这个例子中，再计算触发平台4利用的概率模型模拟航班价格随着时间的变动性。建立这种模型所需的知识可以从关于起飞日期之前的航班价格的情况和发展的现实经验获得。例如，可能知道在相应起飞日期一个月之前的时段内，航班价格保持相对稳定，但是在所述起飞日期前一个月之内会变得更易变。从而，概率模型指示与和在更遥远未来的航班相关的预先计算的价格相比，应更频繁地重新计算属于在接下来一个月中即将来临的航班的保存的预先计算的价格。除了利用概率模型来模拟预先计算的查询结果的准确性之外，通过对实时事件作出反应，避免准确性的严重降低。当收到可能影响预先计算的查询结果的正确性的预先确定的实时事件时，细化再计算决策。实时事件是异步的，即，实时事件的发生时刻不是给定的-它们可能在任何时候发生。为了能够接收和处理到来的实时事件，再计算触发平台4配有与通信源的外部接口，所述通信源相应地把有关信息通知再计算触发平台4。

这种实时事件和在再计算触发平台4的预测模型中未考虑的特定情况有关。例如，一部分的预先计算的价格可能受促销影响，而其它价格可能在一年中的特定时候(比如，休假旺季，圣诞节等)变得更加易变。另外，诸如商品交易会、体育活动之类的“例外”情况，诸如罢工或自然灾难之类的随机事件会改变成为“正常”模型因果关系的基础的假设。当响应表示这种例外情况的相应实时事件，判定保存的预先计算的查询结果过时的可能性时，可考虑这些特殊影响。另一方面，可在诸如商品交易会、休假旺季、体育活动之类预定事件的日期之前，即时地把所述事件的影响引入概率模型中。

重要的是注意可选地，再计算触发平台4的更新策略能够考虑到“不确定的”事件，即，不会确定地使一个或多个预先计算的查询结果无效，而是只指示预先计算的数据库查询结果过时的可能性增大的那些事件。换句话说，这些事件就预先计算的数据库查询结果来说不是确定性的，只是对保持在搜索平台3中的预先计算的数据库查询结果和由计算平台2的假想再计算产生的推测的实际数据库查询结果之间的差异存在概率影响。这和在WO 01/33472和WO 02/25557中记载的其中AVS消息指示特定航班已被取消的提议不同。从而，当收到这种AVS消息时，确定地知道相应的飞机座位不再可订。

例如，参照如上所述的与旅行相关的数据存储的情形，对预先计算的查询结果的准确性只有潜在影响的实时事件是票价更新。票价是包括诸如出发城市和目的地城市，订位舱等，航班种类(单程或往返)，金额和定义为了实际应用该票价而必须被满足的约束条件的规定之类参数的一组数据。从而，票价代表用于特定航班的价格计算的基本数据，并由计算平台2保持。如果航空公司更新关于特定的出发城市-目的地城市对的票价，那么保存在一个或多个搜索平台3中的关于该城市对的预先计算的航班价格不再正确的可能性增大。不过，从再计算触发平台4的观点看，这是不确定的，因为当预先计算保存的价格时，计算平台2实际应用的票价对再计算触发平台4来说是未知的。例如，对计算平台的在先预先计算应用的票价可能实际上一直没有变化，从而票价变化事件指示的票价变化不改变先前有关的票价仍然适用的事实，从而以前计算的价格仍然有效。或者，以前应用的票价实际上被改变，不过归因于所述变化，另一个票价现在适用于所讨论的航班价格的计算，从而最后具有预先计算的价格实际上仍然有效的效果。

从而，当观察到这样的实时事件时，再计算触发平台4只是可能性不确定地猜测某些预先计算的数据库查询结果现在过时，从而有利的是重新计算它们，以便使搜索平台3的存储器保持准确。不过，这不是确实无疑的事实，很可能相应的预先计算的查询结果-尽管其过时的可能性已增大-实际上仍然准确，从而不必被重新计算。

可选地，预先计算的数据库查询结果过时的可能性的判定由再计算触发平台4按两个逻辑步骤进行：通常，在第一个逻辑步骤，利用概率预测模型，识别所述可能性。随后，在第二个逻辑步骤，响应到来的实时事件，修正这些确定的可能性。

根据按照这种方式确定的概率，再计算触发平台4自动生成批量再计算指令，并通过再计算触发平台4和计算平台2之间的适当网络接口(参见上面的图1)，把批量再计算指令发送给计算平台2。通常，对于与过时的可能性较低的其它预先计算的数据库查询结果相比，过时的可能性较高的那些预先计算的数据库查询结果，产生批量再计算指令。

通过利用概率的阈值，可选地在再计算触发平台4中实现这种经验法则：保存在搜索平台3中的确定的过时概率高于所述阈值的预先计算查询结果需要被重新计算。因而，向计算平台2发送出相应的批量再计算指令。确定的过时概率等于或小于所述阈值的预先计算查询结果被认为可能仍然准确，从而不需要被重新计算。因而，不把它们包含在待发送给计算平台2的下一个批量再计算指令中。

可选地，在发送批量再计算指令之前，在再计算触发平台4已考虑了在特定时候，在计算平台的可用计算能力。为了能够考虑可用资源，再计算触发平台4分别掌握计算平台2的容量利用率和空闲计算资源的程度和/或时间表。通过这两个平台之间的通信链路，填充相关信息。

可选地，再计算触发平台4被布置成在响应特定的实时事件，判定是否修正或推翻再计算决策之前，考虑概率模型和发生的实时事件之间的关系。基本上，关于实时事件是否已存在于概率模型中以及达到什么程度，分析实时事件。对于在模型中被充分表现的这种事件，不需要任何修正，因为当根据概率模型确定相应的预先计算的数据库查询结果的可能性时，已考虑了所述事件的发生。另一方面，如果概率模型根本没有预测实时事件，即，模型中不存在该实时事件，那么立即考虑该实时事件，并尽可能快地修正关于相应的预先计算的数据库查询结果的再计算指令。

可选地，再计算触发平台4被布置成把存在于概率模型中的发生的事实事件累积到一定程度，以便评估趋势。如果通常用概率模型模拟的实际发生的实时事件的累积指示其程度超出模型所考虑的程度之外的突发，那么修正可能性，并且如果适用的话，相应地推翻再计算指令。

可选地，再计算触发平台还被布置成分组地累积和分析事件，以便滤出使搜索平台3保存的太少的预先计算数据库查询结果过时，从而被认为不相干的事件。另外由于该原因，记录、随着时间的过去收集并聚合地处理事件。这样，防止响应影响低的事件，过于大量地产生批量再计算指令，从而避免在计算平台2的计算资源成本的失调增大。

总之，再计算触发平台4把可能至少超过给定程度地影响预先计算的数据库查询结果的准确性的实时事件加以考虑，可改善在搜索平台3侧对预先计算的数据库查询结果的准确性的恶化的反应。

按照上面简要提及和下面更详细地说明的特定实现例子，本发明的数据库系统1是旅行信息管理和预订系统。下面关于这样的实现例子，更详细地说明本发明的数据库系统的各个组件，即，计算平台2、搜索平台3和再计算平台4。在这个例子中，计算平台2保持旅行信息，比如与航班相关的数据，即，出发机场和到达机场，航班日期，座位等级和可用性数据，航班票价等。根据这些基本数据，计算平台2预先计算附有价格的旅行选项。搜索平台3可以是预购平台。在实际预订旅行之前，旅游业的最终用户通常希望被告知可订航班，包括当前航班价格，而不承诺实际预订该航班。对预订信息的这种非绑定请求经常采取开放并且宽泛的数据库查询的形式，当只在查询时才被计算时，所述查询需要数量巨大的计算资源。此外，顾客期待响应其查询，几乎立即提供所请求的信息。从而，诸如附有价格的空中旅行推荐之类的预购查询结果适合于被预先计算，并保存在快速存取存储器中。

预先计算的数据库查询结果，即，计算平台2产生的附有价格的旅行推荐不仅被转发给预购搜索平台3，而且被复制，并保存在再计算触发平台4，以便进行更新分析。再计算决策可由预购搜索平台3作出，不过尤其可由再计算触发平台4根据概率模型作出，所述概率模型本身是根据从其它Amadeus服务获得的统计数据构成的。另外，把诸如航班票价变化，飞机座位空余情况变化，订位舱等无效，客户端机票请求，用户质量反馈事件和/或航班取消之类的实时事件考虑在内。

按照另一个方面，本发明的系统配备有按照特定方式，处理和显示数据库搜索结果的结构。更具体地，首先按照特定类别，对数据库搜索结果分类，随后作为第二步，在所述类别内对数据库搜索结果排序。这样，可按照结构化并且用户有用的方式，在客户端呈现数据库查询结果。这在图1中，是用称为“特色结果”的云状图案指示的。向客户端提供“特色结果”的相应机制可在搜索平台3中实现，并且可选地和另外地，可在计算平台2中实现。

下面，在子章节“搜索结果处理和显示子系统”中，进行更详细的说明。

详细说明

计算平台

图2表示按照本发明的计算平台的例子的专用于大规模的航班和价格计算的计算平台2的实现例子。数据处理与专用于订票的购物流量分离。

计算平台2管理具有高自由度的查询，而不是用于订票应用的事务。自由度应用于例如日期组合(一年中的所有出发日期，出发日期之后的数周内的所有返程日期)，出发地和目的地的地理区域，所请求的承运人(所请求的一对城市的一个、几个或者所有的可能承运人)，所有可用的订票代码，所有可能的乘客类型。

由于对这种数据计算来说，低等待时间不是强制性的，因此时间范围可不同于真实时间。处理和资源消耗从而可被延续更长的时间范围，比如2小时、4小时、8小时、12小时、24小时或者甚至更长的时间范围。结果的返回也相应地遍布该时间范围。

按照批量模型组织本发明的计算平台2，所述批量模型的资源可被动态例示，以应付大量的数据。计算平台2根据全局分析，进行数据处理优化。另外，计算平台2是通用并且可扩展的。不同的业务逻辑-取决于在之上进行计算的基础数据的性质-可被容易地插入计算平台2中，以满足不同的顾客要求(比如旅行领域中的预购、收益管理、费用分析，或者其它领域中的完全不同的逻辑)。

在一个例子中，计算平台2包括一个或多个大规模主模块(massivemaster)20和多个大规模工作模块(massive worker)22。大规模主模块20全局分析输入的批量再计算指令，所述批量再计算指令随后被分解成优化的请求。请求随后由一个或多个大规模工作模块22处理，结果被反馈给发端大规模主模块20，该大规模主模块20把结果聚集成旅程解答加上价格。

在一个例子中，本发明的计算平台2把批量再计算指令分解成原子查询，并进行目的在于识别原子查询之间的相关冗余以避免无用的再处理的全局分析。冗余查询部分的合并必须在资源消耗方面和在处理期间的数据存取方面是高效的。计算平台2必须同时满足功能和技术要求：它必须一方面考虑与搜索平台3建立的服务水平协定(时间约束，质量)，另一方面考虑运营要求(资源控制，对其它组件的影响)。图2描述的例子的计算平台2包括两种服务器/实体：

大规模主模块20，其托管为最佳地管理输入和输出所需的全局智能。

大规模工作模块22，其实现插在计算平台2上的各个产品的业务逻辑。

图3表示按照本发明的计算平台2的例子的处理的流程。整个流程可被分成可并行进行的以下6个步骤/操作：

-分解(SPLIT)，其中大规模主模块20从顾客查询中提取所有的单一请求；

-优化(OPTIMIZATION)，其中大规模主模块20进行全局分析，以便实现智能的请求合并；

-分派(ASSIGNATION)，其中大规模主模块20智能地把请求路由到大规模工作模块；

-计算(COMPUTATION)，其中大规模工作模块22处理优化的请求；

-流式传输(STREAMING)，其中大规模工作模块22管理结果量；

-聚合(AGGREGATION)，其中大规模主模块20按照客户查询聚合结果。

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

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

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

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

提取模块202根据顾客在查询中给出的语义信息，创建单一请求。提取取决于产品和顾客给出的输入。于是，该步骤是可插入的。此外，对于一些顾客功能约束，可以应用业务规则。

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

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

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

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

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

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

调步和优先级模块207通过避免使大规模工作模块22过载，按照可用资源调整大规模工作模块22的活动。它还管理待处理请求之间的优先级。例如，已按快速跟进模式请求了一组查询，从而必须以比一组标准查询更高的优先级处理该组查询。更多的资源专用于这些查询的计算。

大规模工作锁定器模块208选择请求必须在该处被处理的大规模工作模块群。该选择既基于技术考虑(大规模工作模块22的资源可用性)，又基于功能考虑(大规模工作模块群专用于某些市场、产品或顾客)。

图7表示票价计算操作，即，业务逻辑的示意图。大规模工作模块22实现由按照本发明的计算平台的例子的方法提供的所有产品的业务逻辑。请求解码模块220对大规模主模块20提供的优化请求解码。随后通过调用已存在于GDS中的不同模块，驱动该处理。被调用模块和调用顺序取决于产品。每个被调用模块基于特定于每种产品的适用插件。旅程处理模块221实现请求的航班解答的计算。它负责根据在请求中给出的日期、地理和选项信息，识别旅程组合。旅程处理依赖于最新的数据。可用性处理模块222实现旅程解答可用性的检查。为了获得更好的质量水平，可以直接对航空公司进行请求，以依赖于更新的数据。费用引擎处理模块223按照在请求中给出的信息和选项，实现对请求的各个可能解答的价格计算。如果只要求较好的解答，那么费用引擎处理模块223还比较价格，以便只保留最好的解答。

图8表示流式传输操作，即，管理原始结果的示意图。为了管理利用批量再计算指令和相关计算产生的大量结果，需要优化与大规模主模块20的通信和结果的存储的操作。下面详细说明的大规模工作模块22上的几个模块允许这种优化。压缩模块224降低结果的大小，从而降低大规模工作模块22和大规模主模块20之间的通信量。保存的数据量也被减小。由于该操作消耗处理资源，因此只有当计算的增益和存储资源消耗相关时，才应用该操作。分解/缓冲模块225也允许资源消耗优化。如果产生的结果的结果量太高，那么产生的结果被分成几堆。从而同时进行与大规模主模块20的通信和数据存储。如果结果量太低，那么缓冲结果，直到适合由大规模主模块20管理为止。由于只需要处理相关结果量的很少的存储模块，因此通信更加高效。大规模主锁定器226选择大规模主模块20。该选择既基于技术考虑(大规模主模块20的资源可用性)，又基于功能考虑(大规模主模块群专用于某些市场、产品或顾客)。

图9表示聚合操作，即，管理顾客输出的示意图。一旦产生了查询的所有结果，这些结果就必须被聚合，并按照适当的格式返回给顾客。聚合结果模块209把来自大规模工作模块22的原始结果变换成价格导向的结果。随后按照顾客查询聚合结果：顾客获得对其问题的回答，而不是混乱的结果。例如，如果顾客以几种选项，并且关于一年中的所有出发日期，在查询中请求特定市场的解答，那么与查询的所有选项和所有出发日期对应的所有解答将被聚合在答复中。插件为每种产品和每个顾客定义预期的结果格式。Diff模块210是选择已从先前的处理变化的结果的价格打包选项。只有新的更新的反对结果才被返回给顾客。插件按照产品定义分化标准。这种选项允许GDS和顾客之间的高效网络传输。此外，由于要管理的结果量较少，因此顾客系统上的活动被减少。压缩和加密模块211通过减少返回的结果量并使结果保密，允许高效并且安全的网络传输。滴流返回模块212通过对处理过的查询的全局结果分组，定期进行传输。从而，返回遍布在较长的时间内。由于结果的数量巨大(例如，超过一百万条再计算的附有定价的旅程建议)，因此搜索平台不想在结合结果之前等候处理的结束。于是，在开始处理之后的几分钟，产生并返回第一批结果。传输遍布整个处理时间范围。从而，结果可被逐渐结合到顾客预购或收益管理系统中。

可选地，计算平台2包含其中缓冲数据库查询结果/利用计算平台2再计算的附有定价的旅程建议的高速缓存(图2中未图示)。可直接从计算平台2的所述高速缓存供给从搜索平台3和/或再计算触发平台4到达的批量再计算指令。计算平台2的高速缓存可包含高速缓存管理器，如下结合图25进一步所述。

计算平台的更具体使用例子：

例1：预购系统的产品

我们考虑专用于预购系统馈送的产品。对于与指定的一对城市和承运人匹配的每个航班解答，它计算出发日期和停留时间的所有组合的最低适用价格。计算依赖于通过价目表发布者的中介，自动提交给GDS的所有数据。只有当航班有空座位时，才返回推荐。由于检查空座位会消耗许多资源，因此只对把顾客的合伙人作为承运人的查询才进行该操作。通过创建单一请求，归因于业务规则，分解模块能够识别请求中的合伙人，并标记这些请求，以便能够实现“空座位检查”。优化模块合并旅程请求，以防止由日期组合引起的冗余。合并操作利用考虑到特定于该产品的费用引擎处理的优化的插件。

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

我们考虑专用于收益管理馈送的产品。对于与指定市场匹配的每个航班解答，它计算出发日期、停留时间、提前购买条件和预约订位代码(下面称为RBD)的所有组合的最低适用价格。在整个旅行中必须使用相同的RBD。该计算依赖于通过价目表发布者的中介，自动提交给GDS的所有数据。出发日期在接下来的45天内的请求的计算必须依赖于在一天中的办公时间内，由顾客手动提交给GDS的所有数据。优化模块捆绑日期组合和提前购买，以优化旅程解答的计算。在合并时，它应用业务规则来分离出发日期在接下来的45天内的请求。其处理被延迟到顾客结束办公之后，以考虑到提交给GDS的手动更新。费用计算模块利用返回航班解答的RBD的专用旅程处理插件。它不使用可用性处理插件，因为产品并不专用于购物或预购业务。由于对于每个优化的请求，该产品产生数千个结果(归因于日期，提交购买和RBD的组合)，因此流式传输模块在大规模工作模块上进行原始结果的分解。

在图10中所示的图中也表示了实现本发明的计算平台2的例子的上述方法。所述方法始于实心圆23，随后进入方框24，在方框24，计算平台2接收批量再计算请求。在本例中，所述再计算请求包括由搜索平台3或再计算触发平台4发送的一批旅行查询。在本发明的数据库系统的例子中，接收批量计算请求并进行计算以满足搜索平台3的需求的计算平台2与实际的搜索平台3本身分离，不过本领域的技术人员会理解这两个平台(计算平台2和搜索平台3)可以结合在一起。此外，本发明的数据库系统1包括其中不止一个搜索平台3连接到计算平台2的配置。在一个例子中，存在两个搜索平台3，向用户提供关于可用航班和旅行的预订前信息的预购平台，和负责在预购之后进行实际预订的预订平台。一旦收到批量再计算请求，控制就转到方框25，在方框25，进行批量再计算请求的预处理。调用预处理的时刻或者触发开始预处理的事件可取决于几个因素，预处理甚至可由系统管理员或者由各个用户定制：例如，可以每隔预定的一段时间(例如，在一天结束时，或者每小时)进行预处理；当收到大量的紧要查询时，或者当达到最大容量时，可以自动进行预处理；或者同样可由管理员或者由用户请求。按照本发明的例子，批量再计算请求的预处理包括包含多个旅行查询的批量再计算请求的全局分析，所述批量再计算请求被分解成简单的请求要素(在图3中也称为“单一请求”)，以便优化数据库查询活动。在本发明的计算平台的例子中，每个查询由提取一个或多个简单请求要素的大规模主模块20(预处理模块)分析。这些简单请求要素随后被重新排列，以避免重复，和按照考虑到几个因素的预定标准以及业务规则，被组织(分割)成子集(在图3中也称为“优化请求”)，如上参考图5所述。继续该预处理，直到预处理了所有旅行查询为止(方框26)。一旦请求已被优化，大规模主模块20就把每个子集分配给适当的大规模工作模块22，并把请求子集转发给选择的适当大规模工作模块(方框27)。每个大规模工作模块22随后在数据库中进行查询，以满足用户的请求，例如，旅行费用、旅行可用性。查询的结果随后被收集，并被传回给大规模主模块20，以便通过发出响应而提供给提出旅行查询的搜索平台3和再计算触发平台4(方框28)。在本发明的计算平台的例子中，在被提供给其它平台之前，结果由大规模主模块20聚合，如上所述。处理随后在步骤29结束。在上面参考图10说明的例子中，进行所述方法的计算平台2包括一个大规模主模块20和多个大规模工作模块22，不过其它实现也是可能的，例如，不止一个大规模主模块20并行地工作，或者甚至只有一个大规模工作模块22处理多个子集。另外，大规模工作模块22和大规模主模块20不一定对应于不同的物理机器，相反它们可以仅仅是在相同的计算机系统上工作的应用。

总之，这里介绍的计算平台2可用以下要点表征：

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

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

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

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

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

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

-按照预定标准，把多个请求要素分成子集；

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

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

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

3、按照任意前述要点所述的方法，其中多个处理模块并行地进行执行请求要素的每个子集的请求要素的步骤。

4、按照要点3所述的方法，其中分割多个请求要素的步骤包括按照给定标准，把每个子集分派给多个处理模块之一。

5、按照任意前述要点所述的方法，其中多个预处理模块并行地进行预处理多个旅行查询的步骤。

6、按照要点5所述的方法，还包括：

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

7、按照任意前述要点所述的方法，其中所述多个参数包括日期和地理位置。

8、一种计算机程序，所述计算机程序包含当在计算机系统上执行所述计算机程序时，实现按照任意上述要点所述的方法的各个步骤的指令。

9、一种计算机程序产品，包括含有按照要点8所述的计算机程序的计算机可读装置。

10、一种专用于馈送预购系统的包括按照要点1-7任意之一所述方法的软件工具。

11、一种专用于馈送收益管理系统的包括按照要点1-7任意之一所述方法的软件工具。

12、一种专用于馈送费用分析系统的包括按照要点1-7任意之一所述方法的软件工具。

13、一种管理预购旅行查询的数据处理系统，所述数据处理系统可以按照多个参数，访问包含关于旅行可用性和费用的信息的多个旅行数据库，每个旅行查询包括一组优先选择，每个优先选择与在所述多个参数中选择的一个参数相关，其中所述系统包含适合于实现按照要点1-7任意之一所述方法的一个或多个组件。

14、一种部署在数据处理系统中，实现按照要点1-7任意之一所述方法的服务。

搜索平台

在一个实现例子中，本发明的搜索平台3目的在于保存预先计算的空中旅行选项，和提供几个优点。不过，使用户可以得到的任何其它各种应用的数据也是可能的。注意，这里说明的搜索平台的技术特征不受搜索平台保持的数据的种类及其内容驱动或限制。

按照随后说明的例子，搜索平台3用来保持空中旅行的全部目录。能够保存下一年的所有各天的成千上万个市场的最佳价格，每天数个可能的价格(取决于旅行的停留时间)。搜索平台3可以是分布式的，这使其能够按照待保存的市场的数目扩展。这优化了空中旅行数据的存储，具有以下益处：

-旅行搜索效果：能实现的搜索事务的响应时间为几十毫秒，无论搜索事务如何复杂(开放式目的地，全年搜索…)。

-旅行数据更新效率：更新对整个存储器影响有限，使得能够实现连续更新，新数据即时可用。

-旅行数据存储效率：数据可被分解(如果在许多目录中共有的话)，以进一步降低存储成本。

它能够以可承受的成本，维持高质量的预购旅行推荐。搜索平台3具有检测需要再计算的旅行价格的各种引擎。这可驱动部分再计算，以节约硬件资源。节约的资源可被重新投入其它再计算中，以实现从用户的观点看，准确性更高的预先计算的数据库查询结果(在80-90％的范围中)。

按照本例的搜索平台3提供不同种类的搜索产品，取决于其顾客和旅行提供者的需要。对本例来说，承运人需要检索对其航线和其合作伙伴的航线的推荐的搜索产品。相反，在线旅行社需要检索任何种类的空中旅行，而没有承运人过滤的搜索产品。这两种产品可具有内部特殊性，并可被相应地优化。

图11表示按照本发明的搜索平台的例子的保存和搜索空中旅行推荐的搜索平台3。保存的目录或空中旅行推荐遍布在构成分布式系统的所有机器中。在每台机器上，全局数据的一部分被保存在快速存取存储单元(例如，RAM)中，以便进行快速数据存取。图11表示本发明的搜索平台3的例证体系结构的逻辑视图。尽管系统可以是物理分布的，或者可以不是物理分布的，不过，系统的逻辑视图可被分成两个主要的组：

数据库301及方框302和303代表搜索平台3的典型部分。

数据库301表示逻辑上聚合到推荐池中，并且物理上保存在不同机器中的所有空中旅行推荐。

方框302和302代表馈送引擎和搜索引擎：

-馈送引擎20索引各组预先计算的空中旅行推荐(例如，关于相同城市对的所有旅行)，并把它们保存在分布式系统中的机器之一中。

-搜索引擎303在物理机器之间定位各组数据，并提供索引搜索工具，以回答起源于用户的查询。

椭圆形项目6、8、304、305代表一系列的分析引擎。它们的用途是优化数据库系统的硬件成本：它们目的在于实现每天要再计算的数据库查询结果的数目和保存在搜索平台3中的预先计算的价格的正确性(最新性)之间的良好折衷。这些引擎分析馈送操作和搜索操作，并产生关于保存在搜索平台3中的数据的变动性和质量的指标。这些引擎中的一些引擎利用可访问的其它服务，比如可在全球分销系统(不是本发明的一部分)中获得的服务。具体地，所述引擎是：

-学习引擎304，它每天分析保存在平台中的旅行推荐，以提取关于某些价格随日期和市场的变动性，即，价格多长时间保持不变的信息；

-受欢迎度引擎6，它跟踪请求最多或者返回最多的旅行推荐(按日期、市场)，以获得关于保存在系统中的最相关数据的指标；

-准确性引擎8，它试图检测保存在系统中的旅行推荐和真实的购买价格(即，不再可订的航班或价格已变化的那些航班)之间的差异；

-报告协调器305，它聚集并保存上游引擎的结果。其作用是在给定可用资源的情况下，根据在先引擎的结果，确定全部航班数据中的哪个部分必须被重新计算。这种确定是按照算法进行的。

在搜索平台2的例子中，所有的分析引擎与馈送引擎和搜索引擎(302和303)并行工作，从而对客户端来说，其工作不存在负面性能影响(不存在响应时间恶化)。

参见图12，图中表示了搜索平台3和计算平台2之间的耦合的例子。这种系统包括由计算平台2，比如上面在子章节“计算平台”中说明的计算平台2进行供给的搜索平台3。两个平台还可以与其它服务5，比如由全球分销系统(GDS)提供的服务交互作用。图12描述把旅行推荐的全部目录保存在搜索平台中的高级流程。

作为平台的顾客，旅行提供者(航空公司、旅行社…)确定他们要把其旅行业务范围中的哪个部分并入搜索平台中。据此，它们向旅行推荐计算系统发送所谓的大规模查询，所述大规模查询是一系列的再计算指令。这些指令详细说明要考虑的市场(例如，下一年的所有各天的城市对的名单)，以及要产生的旅行推荐(例如，每一天，1-20天长的旅程的最佳推荐)。这样的指令可由顾客频繁地重新评估，或者它们可以充当重新发生的计算的基础。

旅行推荐计算系统利用GDS的内部服务来计算请求的推荐。除了其它之外，为了产生推荐，它可利用旅程服务来检索现有航班的名单；利用定价服务来找出票价和航班的最佳组合；利用可用性服务来咨询可供预订的当前座位，等等。

当产生推荐时，计算平台2把结果发送给搜索平台3，以便集成。接收的推荐被保存在专用存储单元中，以填充预先计算的旅行推荐的全局存储器，从而变得可用于最后的客户端的搜索查询。一旦旅行推荐被集成，就在后台进行一些监控任务，以检测归因于与等同的购买推荐的低一致性，而应重新计算的预先计算的旅行推荐。这种监控可利用GDS提供的内部服务5。

当检测到不一致的推荐时，搜索平台3产生一系列的批量再计算指令(也称为“大规模查询”)，并把它们发送给计算平台2。计算平台2将产生有助于维持预先计算的旅行推荐的良好一致性(与再计算的结果相比)的更新推荐。

图13表示馈送引擎302(参见图11)的结构和功能。馈送引擎302接收由计算平台2返回的各组重新计算的空中旅行推荐，例如在一段时间内，从巴黎到伦敦(也称为“市场PAR-LON”)的所有航班的所有价格。分几个步骤，进行这些重新计算的数据库查询结果的集成：

-调度重新计算的旅行推荐

在搜索平台3中，相关的数据目标被保存在相同的物理机器上，以提供很快的搜索响应时间。例如，具有相同发出城市的两个市场(PAR-LON和PAR-NYC)将落在相同的物理机器上。馈送引擎302从一组推荐中提取信息(旅行提供者ID、营业所ID、市场、地理位置…)，以确定将托管数据的物理机器。这种数据均衡机制利用诸如循环或者一致性散列之类的公知分布技术。如公知的数据复制方案中所示，许多机器可托管相同的一组推荐，以改善可靠性、容错性或者可访问性。

-组织重新计算的旅行推荐

馈送引擎302接收来自计算平台2的一批重新计算的旅行推荐。到来的数据随后按照更好地适合搜索平台3的方式被分入称为数据集的组中。由搜索平台3的当前所述例子提供的各个搜索产品具有唯一的数据组织策略，以优化其性能。对该例子来说，为了特殊的需要，可按多组相同的城市对，组织来自计算平台2的一组航班，随后分配给两种数据集：1)相同的城市对和仅仅直飞；和2)相同的城市对和中转航班。

-建立加速器

紧接着所述组织，搜索平台3创建另外的数据集，所述另外的数据集只包含关于预先计算的旅行推荐的元信息。这些数据有助于实现极快的搜索。例如，元信息的数据集可托管可从始发城市到达的城市，和对于每个可达城市，该城市对的最低价格。最终，输入的客户端的搜索请求可受益于该信息，以避免在返回解答之前，查看过多的旅行推荐。

-建立索引

类似于数据库，搜索平台3在数据集之上建立索引，以提供快速访问时间。对于预先计算的空中旅行推荐来说，搜索标准非常开放：可以在给定日期范围中，对于给定的价格范围，对于任意目的地城市等，搜索价格。代替每个搜索标准创建一个索引，搜索平台3利用多维数据结构(比如K-D-B树)每个数据集构成一个索引，同时不管什么搜索标准，都维持对数据的同样高效访问。这种方法限制使用的存储量。如果两个旅行提供者共享公共的旅行推荐，并且票价是公开的(与只适用于特定营业所ID的旅行提供者的协议票价相反)，那么这些可在系统存储器中被共享，以增大空间和降低硬件成本。

-一致性管理器

当可从计算平台获得新的预先计算的旅行推荐时，用新的或者较少的预先计算的旅行推荐更新对应数据集，并重建其索引。同时，搜索受影响的数据集，寻找旅行推荐。为了避免影响进行中的搜索(在性能和一致性方面)，馈送引擎302管理数据集的修订。在对数据集的修订版n进行搜索时，馈送构成修订版n+1。当修订的数据集被构成和索引时，它变成供搜索的新的参考数据集。之后立刻从托管在先数据集的分布式系统的所有物理机器的存储器中删除该在先数据集。这确保在进行中的搜索结束之前，保持这些数据可供进行中的搜索之用，从而避免一致性问题。

图14表示搜索引擎303(参见图11)。搜索引擎303从连接的客户端接收空中旅行搜索请求，并爬入所有数据，以返回最佳的预先计算的推荐。该过程分几个步骤进行：

-服务器亲和

输入的搜索请求必须由搜索平台3提供的特定搜索产品处理。据此，输入的搜索请求被路由到包含答复所述请求所必需的数据的物理机器(假定搜索平台3的分布性)。如上所述，事先，预先计算的空中旅行推荐被馈送引擎302根据所述推荐针对的搜索产品的特异性，分派到物理机器。搜索引擎303现在进行互补操作：它分析要答复的搜索查询，并根据搜索查询的种类，确定要搜索的数据，和所述数据所位于的物理机器。

-确定搜索范围

一旦搜索请求被转发给相关物理机器，搜索引擎就确定在那里寻找与搜索查询相关的元信息的数据集。元信息用于定位包含搜索查询的可能解答的空中旅行推荐的所有数据集。

-搜索执行

一旦所有可能的预先计算的空中旅行推荐被定位，搜索引擎303就解析所有的多维索引，以根据在搜索查询中表述的标准，例如，价格区间、日期范围、航班承运人等，收集最佳的预先计算的旅行推荐。搜索引擎303可利用以前的元信息来决定不调查所有可能的预先计算的旅行解答。对本例来说，假定搜索查询寻找从特定城市NCE起飞的最佳价格。假定在搜索中，找到值100欧元的到目的地城市PAR的旅行。如果元信息说明对城市NYC来说的最低价格为500欧元，那么搜索引擎3甚至不尝试搜索从NCE到NYC的解答。这进一步降低搜索事务的响应时间。

-相关搜索

在搜索执行步骤未返回预先计算的旅行推荐的情况下，用户的查询可能限制性过大：从而对于先前考虑的各个城市对，分析缺少匹配物的原因。例如，原因可能是在指定的日期范围中无航班，或者有航班，但是比在查询中表示的价格限额贵。在用户的查询限制性过大的情况下，搜索引擎303实现回退策略，以返回与在初始查询中表示的约束条件紧密相关的推荐。它放松对多个参数的约束条件(更宽的时间范围，更高的价格限额…)，并循环回到搜索执行步骤。当找到一些推荐，当达到配置的重试次数，或者当达到允许的最大重试时间时，结束循环。在回退策略未返回任何推荐的情况下，合适时实现另一个回退策略。在所请求的目的地具有地理含义的情况下(例如，城市、国家)，搜索引擎303利用GDS(不是本发明的一部分)提供的地理服务确定接近的地理区域，按照上面说明的方式，它扩展原始查询的目的地约束，并循环回搜索执行步骤。如果两个回退策略都未能检测到推荐，那么返回空结果。

-旅行解答聚合

一旦找出搜索查询的所有预先计算的解答，搜索引擎303合并一遍本可以已从不同的数据集返回的相同结果。例如，如果搜索必须调查包含城市对的最廉价直飞的数据集和包含所有航班的另一个数据集(直飞和经停)，那么会出现这种情况。

最后，根据搜索查询的要求，组织找到的预先计算的旅行解答：按目的地城市、按日期、按上升价格、按航线(直飞或中转)对解答分组。结果随后被返回给客户端。

图15表示学习引擎304(参见图11)。学习引擎304包括学习和统计量数据库。学习引擎304的用途是检测其价格不频繁变化，从而不需要由计算平台2频繁重新计算，以保持准确性(即，保存在搜索平台3中的预先计算的数据库查询结果对应于计算平台2的假定再计算的结果)的预先计算的空中旅行。

学习引擎304使其逻辑分析基于空中旅行航班的一般性质：安排在即将到来的几天中的航班的价格非常易变，即，如果在一天之后再次询问相同航班(相同起飞日期)的价格，那么其价格可能被改变。相反，如果在一天之后或者一周之后再次询问安排在几周之后的航班的价格，那么该价格不太可能变化。学习引擎304根据上面详细说明的性质，使变动性模型与各个市场关联。它根据它每天收到的预先计算的施行推荐，维持变动性模型(参见图21)(并且修正该模型，如果需要的话)。类似的考虑可适用于由搜索平台3的其它例子保持的其它种类的数据，其中数据变动性的具体模型取决于数据的性质和内容。

-记录旅行推荐的价格

当收到到来的预先计算的旅行推荐时，所述旅行推荐被复制，一份副本转到学习引擎304。按市场对预先计算的旅行推荐分组，即，下一年各天，关于一个城市对的旅行的推荐。注意，不是一年的所有各天都产生推荐，因为系统可能指令计算平台2只跨较小的日期范围，重新计算易变的航班。学习引擎304提取到来的旅行推荐的价格，并把它们连同其计算日期一起记录在专用的学习和统计量数据库中。这些价格充当用于未来的空中旅行数据聚合的价格比较的基础。

-加载市场数据和修正变动性模型

学习引擎304为输入的市场，加载预先保存在其专用数据库中的所有预先计算的附有价格的旅行推荐。它比较保存的价格和可获得的输入价格。学习引擎304根据价格比较的结果，修改市场的变动性模型：

当两个相同的航班具有不同的价格时，差分作为统计量被保存在学习和统计量数据库中。当过于频繁地出现差分时，更新变动性模型：日期范围跨度被标记成更易变。保存关于变化频度的统计量有助于减轻由定期出现的事件，比如休假旺季引起的价格变化的影响。如果两个相同的航班持续比根据所述模型预期的时间长的时间具有相同的价格，那么模型也被更新；日期范围跨度被标记为不太易变。

-产生变动性报告

一旦完成所有到来的预先计算的旅行推荐的分析，学习引擎304就产生报告，所述报告包含刚刚集成到这里说明的分布式搜索平台中的数据的修正后的变动性。变动性报告是按顾客ID(数据的提供者)生成的，并按市场，按出发日期组织的。

产生的报告被发送给称为报告协调器305的另一个引擎。报告协调器引擎305将最终利用该信息源，根据计算平台2上的可用计算资源，确定必须被重新计算的预先计算的空中旅行推荐的子集。

图16表示受欢迎度引擎6(参见图1)。受欢迎度引擎6包括受欢迎度数据库。根据输入的客户端的搜索请求，受欢迎度引擎6获得从用户事务中提取搜索趋势的机会。这可了解保存在搜索平台3中的旅行价格的受欢迎度。分步地进行该分析：

-输入和输出分析

在到达搜索引擎303之前，输入搜索查询被复制，一个副本转到受欢迎度引擎6。对称地，在被送回用户之前，搜索事务的输出被复制，副本转到受欢迎度引擎6。受欢迎度引擎6分析事务的输入和输出，以获得一些受欢迎度指标和统计量。分析产生不同的信息，取决于输入搜索查询的标准。例如：如果搜索查询请求特定市场(城市对)的旅行推荐，那么该引擎能够从查询中提取按市场的受欢迎出发日期的排序。如果搜索查询请求从单个始发城市的旅行推荐，那么该引擎能够从解答中提取按始发城市和按价格、日期范围等的优选目的地城市(或目的地国家)的排序。

-把统计量保存在数据库中

从输入查询和输出解答中提取的趋势被保存在专用受欢迎度数据库中。这种存储可以是分布的，以致任何物理机器(受欢迎度引擎6工作之处)能够受益于在系统的其它物理机器上产生的数据。

-聚合记录和产生受欢迎度报告

并行地，受欢迎度引擎6的复发作业是从分布式数据库中提取以前计算的统计量，并建立一些系统受欢迎度指标。例如，根据关于受欢迎度分析的搜索查询的总数提取受欢迎市场(即，输入查询对象最多的市场，在输出的旅行解答中返回的廉价市场等)的排序。另一种可能性是产生关于对全年的给定日期范围最受欢迎的市场的统计量，提取关于特定事件，比如休假旺季的趋势，或者产生关于世界的不同地理区域的最受欢迎市场的统计量。这种修正帮助提取更相关的受欢迎度指标(例如，关于国内航班)。

产生的报告随后被发送给报告协调器305，以使他可以访问受欢迎度指标。

图17表示准确性引擎8(参见图11)。准确性引擎8包括价格准确性数据库。准确性引擎8的目标是控制预先计算的空中旅行推荐，并检测其价格偏离真实(即，当前)购买价格太多的那些预先计算的空中旅行推荐。该引擎的原理是利用外部购买服务(不是本发明的一部分)进行购买事务，和比较返回的价格与预先计算的旅行推荐的存储价格。

准确性引擎8分步骤地工作。

-节流地利用输入和输出事务

类似于受欢迎度引擎6，准确性引擎8接收复制的输入搜索查询的副本，并把搜索平台3返回的旅行解答输出给请求客户端。为了避免进行硬件成本和响应时间高的过多真实购买事务，应用节流通道，以作用于通过这里说明的搜索平台3的自然流量的子集。

-生成票价搜索事务

准确性引擎8应生成足够多样化的票价搜索事务，以分析保存在系统中的旅行推荐的典型子集。为此，生成策略有两个方面：根据旅行受欢迎度产生票价搜索事务：准确性引擎8访问受欢迎度数据库6(前面已介绍)，以分析输出解答的受欢迎度，并只保持最受欢迎的解答供未来分析之用。这使用户体验的预先计算和保存的价格与真实的购买价格的一致性达到最大。

根据预先计算的旅行推荐的存储器的内容产生随机事务。供分析之用的旅行的随机选择目的在于提供预先计算的旅行推荐的整个存储器的最终准确性。它确保用户的良好旅行可发现性，即，还监控不受欢迎的航班的准确性，尽管不那么经常限制硬件成本。

-聚合数据

收集的准确性指标被保存在专用的分布式准确性数据库中。复发作业把所有的准确性指标合并到几个报告中(按顾客、按市场、按出发日期…的解答的准确性)，并把它们发送给报告协调器305，供未来使用。

图18表示报告协调器305(参见图11)。报告协调器305是按照这里说明的例子的搜索平台3的最后分析引擎。其作用是根据在先的各个引擎报告的所有指标和按照计算平台2的可用计算资源，确定搜索平台3中的数据的哪个部分要被重新计算，和产生并发出指向计算平台2的再计算指令。

再计算的决定是分几个步骤进行的。

保存报告

出自输入的变动性、受欢迎度和准确性报告的所有指标被本地保存在专用报告数据库中。由于报告协调器305根据以前的指标作出其决定，因此进行所述存储。例如，报告协调器305根据变动性报告，推断保存在预先计算的旅行推荐的存储器中的数据的年龄。该信息随后被保存在报告数据库中。

再计算决定

报告协调器305作出的决定基于平衡存储器的数据准确性和计算平台2上的计算资源的试探法。这种基本方法考虑到计算平台2上的可用资源，重新计算最不准确的预先计算的旅行推荐(即，搜索平台3保存的最不可能仍然对应于计算平台2的假想再计算的结果的那些预先计算的旅行推荐)。在最不准确的数据之中，为生成再计算指令而首先考虑最受欢迎的数据。再计算候选者由报告协调器305选择，以便形成航班域中的多组邻近旅行(每个市场的接近的数据范围)。这允许计算平台2使一些再计算相互间发生关系，从而进一步优化其资源消耗。

在各个再计算指令之间，报告协调器305利用变动性模型7(保存在报告数据库中)和推断的预先计算的旅行推荐的寿命，以更新搜索平台3中的所有剩余数据的预测准确性。

在图19中所示的图中，也表示了实现上述搜索平台3的例子的方法。所述方法是可以在分布式预订系统中工作的预购工具(即，用于按照非绑定旅行查询产生附有价格的旅行推荐)的例子，所述分布式预订系统可以按照多个参数访问包含关于旅行可用性和票价的信息的多个旅行数据库，每个旅行查询包括一组优先选择，每个优先选择与在多个参数之中选择的参数相关。分布式预订系统包括保持旅行推荐的选择的多个快速存取存储单元，以致用户可以获得对其查询的快速响应。随后，我们用术语“由预先计算的旅行推荐组成的高速缓存”表示这些快速存取存储器，即使本领域的技术人员会认识到该术语技术上并不完全适当，因为与高速缓存相比，保存在快速存储存储器中的内容代表预先计算的附有价格的旅行数据集的整个旅行目录，而不仅仅是由存取最多的旅行目录构成的子集。换句话说，术语高速缓存指的是“购买事务高速缓存”。类似地，保存在这些快速存取存储器上的信息被称为“预先计算的信息”(例如，“预先计算的旅行推荐”)。预先计算的旅行推荐的存储器的问题在于包含在推荐中的数据需要被更新，以便使其价格与在购买中发现的真实价格保持一致。这是代价非常高(就时间和系统性能来说)的活动，从而必须找到信息的一致性和系统性能之间的平衡。本发明的搜索平台3(和尤其是本发明的包括下面进一步说明的更复杂方法的再计算触发平台4)的特征之一在于不同的旅行推荐不在相同的时间以相同的频度被更新；而是向各个旅行推荐分派“频度”分数，并按照所述频度分数安排更新：可能更易变的信息将被更频繁地刷新。该方法始于实心圆30，随后转到方框31，在方框31，搜索平台把由预先计算的旅行推荐组成的存储内容保持在多个快速存取存储单元上，每个旅行推荐包括依据多个参数中的至少一个参数分类的关于特定旅行的可用性和价格的信息。可按照如上所述的几个方式，进行存储器中的预先计算的旅行推荐的分类和索引：这对在可能的最短时间中识别正确的信息来说非常重要。随后向各个预先计算的旅行推荐分配表示所需的刷新频度的分数(方框32)。该分数将用于判定何时应进行信息的刷新。利用如上所述的批处理进行按照本发明的搜索平台3的例子的刷新(方框33)：在本发明的搜索平台3的例子中，通过专用子系统，例如，如上详细说明的计算平台2的例子，发起批量再计算指令。所述批量再计算指令的发起(方框34)可在固定时间进行，或者可由用户调用，或者通过特定事件触发：例如，可以每隔预定一段时间(例如，在每天结束时，或者每小时)进行大规模查询；当收到临界的大量查询时，或者当达到最大容量时，它可被自动进行；或者同样地，它可由系统的管理人员或者由旅行提供者请求。当系统收到用户查询时(方框35)，它首先在快速存取存储单元内尝试所述搜索(方框36)。如果未发现解答(方框37)，那么可以发起可选的回退动作(方框38)：如果不提供回退动作，那么给用户的消息将通知在搜索平台3上不存在任何结果。替代地，在认为用户的查询限制性过大的情况下，可用调整后的参数发起新的搜索：从而对于先前考虑的每个城市对分析缺少匹配物的原因。例如，原因可能是在指定的日期范围中无航班，或者存在航班，但是比在查询中表示的价格限额贵。

在用户的查询限制性过大的情况下，搜索引擎303实现回退策略，以返回与在原始查询中表示的约束条件密切相关的推荐。它放松对多个参数的约束条件(更宽的时间范围，更高的价格限额…)，并循环回到搜索执行步骤。当找到一些推荐，当达到配置的重试次数，或者当达到允许的最大重试时间时，结束循环。在回退策略未返回任何推荐的情况下，合适时实现另一个回退策略。在所请求的目的地具有地理含义的情况下(例如，城市、国家)，搜索引擎303利用GDS提供的地理服务确定接近的地理区域，按照上面说明的方式，它扩展原始查询的目的地约束，并返回搜索执行步骤。如果两个回退策略都未能检索到推荐，那么返回空结果。另一种可能的解决方案是发起对外部数据库的查询，以寻找所请求的旅行推荐，和丰富保存在搜索平台3中的预先计算的旅行推荐的高速缓存。如果获得结果，那么用该新信息丰富预先计算的旅行推荐的存储器。在任何情况下，都向用户发出响应(步骤39)。旅行推荐的分数可能也需要更新。在这里说明的例子中，查询由寻找预购信息(即，例如关于旅行可用性、价格、时间的信息)或者不一定目的在于完成预订的一般信息的客户端发送。在本发明的数据库系统1的例子中，接收查询并进行数据库查询以满足用户查询的搜索平台3与实际的预订系统分离，不过本领域的技术人员会认识到这两个搜索平台3(一个用于预购，另一个用于预订)可被结合在一起，如上简要所述。

总之，这里介绍的搜索平台3可用以下要点表征：

1、分布式预订系统中的一种按照非绑定旅行查询，产生附有价格的旅行推荐的方法，所述分布式预订系统可以按照多个参数访问包含关于旅行可用性和票价的信息的多个旅行数据库，每个旅行查询包括一组优先选择，每个优先选择与在多个参数之中选择的参数相关，所述方法包括：

-维持包括预先计算的旅行推荐的选择的多个快速存取存储单元，每个旅行推荐包括依据多个参数中的至少一个参数分类的关于特定旅行的票价和/或可用性的信息；

-向各个预先计算的旅行推荐分配表示所需的刷新频度的分数；

-通过在多个数据库中发起大规模查询，更新预先计算的旅行推荐的选择，以便刷新包含在至少一些旅行推荐中的信息，其中各个旅行推荐的刷新频率取决于分配的分数；

-响应系统收到的旅行查询搜索所述多个快速存取存储单元，以找出满足包含在旅行查询中的优先选择的那些旅行推荐；

-向用户发出对于旅行查询的响应，并更新旅行推荐的选择的分数。

2、按照要点1所述的方法，其中表示所需的刷新频度的分数包括指示关于旅行推荐的可用性和/或票价的信息的变动性的值。

3、按照任意前述要点所述的方法，其中表示所需的刷新频度的分数包括指示旅行推荐的受欢迎度的值。

4、按照任意前述要点所述的方法，其中对多个旅行数据库的访问和丰富预先计算的旅行推荐的选择的步骤是借助专用子系统进行的。

5、按照任意前述要点所述的方法，还包括：

-把预先计算的旅行推荐的选择分成多个同类组，其中同类组中的各个旅行推荐至少具有给定数目的值相同的参数，和把每个组保存在快速存取存储位置之一中。

6、按照任意前述要点所述的方法，其中间隔给定时间地进行发起大规模查询的步骤。

7、按照任意前述要点所述的方法，其中利用批处理进行大规模查询。

8、按照任意前述要点所述的方法，其中按照多维数据结构索引保存在多个快速存取存储位置上的旅行推荐。

9、按照任意前述要点所述的方法，还包括：

-响应通过搜索多个快速存取存储位置未获得任何结果，放松关于多个参数的约束条件地发起一系列密切相关的查询，目的在于返回信息的近似结果。

10、按照1-8任意之一所述的方法，还包括：

-响应通过搜索多个快速存取存储位置未获得任何结果，向用户发出报警消息。

11、一种计算机程序，所述计算机程序包含当在计算机上执行所述计算机程序时，执行按照任意前述要点所述的方法的各个步骤的指令。

12、一种包括计算机可读装置的计算机程序产品，所述计算机可读装置包含按照权利要求10所述的计算机程序。

13、一种包括按照要点1-10任意之一所述的方法的预购系统用软件工具。

14、一种用于管理预购旅行查询的分布式数据处理系统，所述分布式数据处理系统可以按照多个参数访问包含关于旅行可用性和票价的信息的多个旅行数据库，每个旅行查询包括一组优先选择，每个优先选择与在多个参数之中选择的参数相关，其中所述系统包括适合于进行按照要点1-10任意之一所述的方法的一个或多个组件。

15、一种部署在数据处理系统中的实现按照要点1-10任意之一所述方法的服务。

再计算触发平台

图20表示分布式数据库系统1的例子的另一概况。下面说明的例子同样涉及旅游业中的数据库。具体地，介绍其中计算平台2保持关于空中旅行建议的数据，再计算触发平台4保存计算平台2根据计算规则(尤其是航班票价及其相关计算规则)计算的与这些空中旅行建议相关的价格的例子，从而与上面详细说明的计算平台2和搜索平台3的例子保持一致的例子。不过，应注意这只是用于更详细地举例说明本发明的再计算策略的例子。这里介绍的再计算策略可以应用于任意种类的数据以及与数据的结构和/或语义以及高速缓存的结果无关的数据库查询结果。

如上所述，数据库系统1的主要实体中的两个实体是再计算触发平台4和计算平台2。在图20的例子中，计算平台2对应于如上在子章节“计算平台”中说明的计算平台2的例子。再计算触发平台4和计算平台2通过至少一个通信链路耦接，所述至少一个通信链路用于把再计算指令从再计算触发平台4传送给计算平台2，和作为响应，把预先计算的附有价格的旅行推荐(下面也简称为“价格”)从计算平台2回送给再计算触发平台4以及发送给搜索平台3。

再计算触发平台4配备有用于并入它用于确定镜像的预先计算的数据库查询结果的准确率的数据的额外通信接口。例如，这些接口包括用于并入构成概率模型的基础的统计数据，和用于接收异步实时事件(比如由航空公司或顾客促销活动填充的票价变化和航班可用性通告)的通信链路。

另外，数据库系统1包含至少一个搜索平台3，所述搜索平台3组织并维持可被最终用户或者诸如旅行社之类的外部顾客查询的数据。搜索平台3由计算平台2通过计算平台2和搜索平台3之间的相应通信链路填充和更新。这种填充和更新一方面可由搜索平台3本身控制，因为搜索平台3可选地包括以更新频度分数为基础的更新机制，如上详细所述。从而，搜索平台3本身能够向计算平台2发送批量再计算指令。另外，所述填充和更新可由再计算触发平台4向计算平台2发出的再计算指令触发。

如上概述和下面更详细说明，响应从再计算触发平台4收到的再计算指令，计算平台2重新计算旅行推荐的价格，并把它们返回给再计算触发平台4。不过同时，计算平台2还把重新计算的附有价格的旅行推荐转发给搜索平台3，搜索平台3也保存所述旅行推荐(如图20中用“旅行推荐集成”所示)。从而，搜索平台3还根据再计算触发平台4实现的再计算和更新策略，保存用户查询的预先计算的附有价格的旅行推荐。从而，本发明的再计算和更新策略被充分利用于向用户提供益处(比如以对开放式查询的即时响应的形式(除了如上在子章节“搜索平台”中详细说明的已在搜索平台3本身中实现的更新和再计算方法之外))的应用。在这种方案中，再计算触发平台4充当布置成控制和触发搜索平台3的存储器的更新的控制平台。从而，保存在再计算触发平台4中的预先计算的镜像数据库查询结果实际上不被任何用户或顾客访问或查询，而是仅仅构成对其执行再计算策略的控制数据基础。

不过，在其它方案中，再计算触发平台4也可被用户或顾客直接查询，或者换句话说，与单独的控制实体相反，也可在一个或几个搜索平台3中直接实现本发明的预先计算更新策略。从而，在这些方案中，再计算触发平台4被结合到一个或几个(如果有的话)搜索平台3中。这种情况下，再计算触发平台4可直接作用于保存在搜索平台3的快速存储存储器中的预先计算的数据库查询结果/附有价格的旅行推荐(与保持用于作出再计算决定的数据的自有副本相反)。用于实现再计算触发平台4的再计算和更新策略的另外的管理、控制或元数据可被保持在专用于再计算触发平台4的单独存储器中，或者被保持在搜索平台3的用于保存预先计算的附有价格的旅行推荐的快速存取存储器中，或者被保持在组合的搜索和再计算平台3和4的任意其它适当的存储器中。

搜索平台3例如包括预购应用平台，票价分析应用平台和其它平台。预购应用平台由希望找出关于航班可用性和价格的信息的最终用户查询。例如，最终用户可把查询指向预购应用，以便获得在休假旺季，从Nice起飞的低于500欧元的旅行建议的价格概况。归因于与本发明的再计算更新策略一致地更新的、保存在预购搜索平台2中的预先计算的附有价格的旅行推荐，在发生所述查询的时候，不需要计算各个航班的价格。相反，可根据高速缓存在预购应用平台中的附有价格的旅行推荐，可以很快地返回满足这些相当不确定的约束条件的旅行建议的列表。用户随后可从返回的列表中选择最适合于他/她的旅行，随后发出实际预订该旅行的进一步请求。该第二请求随后由预订引擎(未图示)处理，所述预订引擎计算当前的实际价格，并向用户提出有约束力的意向书。

现在进一步说明图21描述的再计算触发平台4的结构，再计算触发平台4由3个模块构成：

-输入管理器40负责接收输入，比如来自计算平台2的预先计算的数据库查询结果，异步的实时事件，和其它信息，比如要馈送给和更新概率模型的统计数据。

-分析器41利用概率模型，分析器被布置成根据所述概率模型，确定要更新的候选的高速缓存查询结果。

-最后，合并器42修正利用分析器41确定的概率，并且-当需要时-还根据观察到的实时事件，修正概率模型(图21中未表示后者)。

另外，再计算触发平台4包括保持高速缓存的附有价格的旅行推荐数据的内部数据库43。这种表示只保留了与评估过时可能性和根据再计算决策决定相关的价格信息的属性，比如：城市对、出发日期、停留时间和最后计算日期，所有这些都是由计算平台2返回的计算的输出。计算平台2为了进行其计算而利用的其它数据，比如票价未被镜像到再计算触发平台4，因为它们不是进行再计算更新策略所必需的。不过，另一方面，再计算触发平台4利用元数据属性(它们不是计算平台2返回的数据集的一部分)，比如初始假设的准确性(计算平台2刚刚重新计算的价格不同于预订用计算的可能性)，变动性(自从价格的最后计算以来，价格不同于预订用计算的概率的指示)，和受欢迎度(航班每隔多久就被搜索和预订)，来丰富其数据。设定这些属性所需的数据被保持在外部数据库中，比如变动性数据库10、初始准确性数据库11和统计数据服务器9中。元数据属性代表分析器41根据其确定高速缓存的价格是否过时的可能性(如下更详细所述)的概率模型。变动性数据库10可以与如上结合搜索平台3所述的学习引擎304(参见图11和15)相连和相互作用。统计数据服务器9对应于或者甚至等同于如上结合搜索平台3所述的受欢迎度引擎6(参见图11和16)，或者由受欢迎度引擎6馈送。初始准确性数据库11对应于或者甚至等同于如上结合搜索平台3所述的准确性引擎8(参见图11和17)。

输入管理器40被布置成把所有不同类的信息源转换和合并成由计算平台2返回的价格的本地表示数据库43。它记录可能影响模拟的价格的事件和行动。这些事件包括顾客促销和顾客差异反馈。此外，类似航班取消的航班可用性事件不仅使直接基于被取消航班的高速缓存旅行推荐无效，而且还影响并行保存的数据，比如在被取消航班的同时调度的相同城市对的航班。这些实时事件随后被转发给合并器42，合并器42进一步处理这些实时事件，以便修正过时可能性和再计算决定。

归因于高速缓存附有价格的旅行推荐所涉及的信息量，有益的是采用编码技术。这样，高速缓存在再计算触发平台4中的附有价格的数据被全局映射到保持在计算平台2中的基础数据域，同时显著降低存储资源的成本。例如，利用Bloom过滤器实现概率编码。这种编码的效果有两个方面。首先，Bloom过滤器是保守的。它们允许至少并且在任何情况下确实地跟踪可能受例如指示票价变化的实时事件影响的那些价格，不过反过来它们并不错误，被认为不受影响的价格实际上不受影响。从而不存在未能识别可能受这种票价变化事件影响的价格的风险。其次，伪正指示的数量严格取决于分配的Bloom过滤器的大小，从而能够根据需要限制其发生。

第二个模块，分析器41，根据保持在再计算触发平台4中的预先计算的价格的准确性的概率恶化模型，进行高速缓存的附有价格的旅行推荐是否过时的可能性的第一次的一般水平的判定。分析器41检查并评价如上所述由输入管理器40加入价格中的元数据。利用所述元数据表示的概率模型从而包括关于变动性数据库10包括的价格变动性、从初始准确性数据库11并入的价格的初始准确性和由来自统计数据服务器9的受欢迎度报告返回的航班推荐的受欢迎度的指标。分析器41把关于高速缓存的价格的概率和优先级信息输出给合并器42，即，仅仅根据静态概率信息(即，不考虑任何事件)的哪些价格需要被优先重新计算的指示。

利用概率模型的信息，以便区分价格的优先次序，和决定接下来重新计算哪些价格的方式有几种。分析器41可配置成应用取决于情形(例如，按照与拥有计算平台2中的基础旅行数据的顾客的协议，取决于数据的数量，取决于可用计算资源，取决于高速缓存应按哪种方式被优化的缺陷(objection))的那些策略和混合策略。可以应用以下策略：

·价格的准确性：目的在于使数据域的全局准确性达到最大。假定不正确的价格首先被重新计算。

·用受欢迎度加权的价格的准确性：在可能不准确的价格之中，与不太受欢迎的价格相比，优先重新计算更受欢迎的价格。

·用受欢迎度和其年龄加权的价格的准确性：类似于前一策略，不过还考虑了最后再计算的时间。这种策略避免了由非常易变的价格引起的再计算饥饿，尤其是在与通常应被重新计算的价格的数量相比，再计算资源有限的情况下。

·根据受欢迎的城市对的地理位置和再计算时间，调整受欢迎的城市对：这种策略另外考虑了在一天的特定时间，哪些城市对航班更经常被查询的统计数据。效果是在特定城市对的航班很少被访问的那些时间，避免频繁的再计算(因为不准确的高速缓存数据无害，只要实际上不发生相应查询)。

附带效果是分析器41根据从计算平台2接收的并且并入再计算触发平台4中的最近重新计算的价格的值，更新变动性模型数据库10。由于分析器能够根据重复的再计算，跟踪高速缓存价格的实际变动性，因此它能够把这些统计信息回送给变动性模型数据库10。为了更新变动性模型，分析器41计数新计算的价格结果和先前接收的价格值之间的差异的数目。根据所述差异，它更新被分析价格的各个部分的变动性参数。

同样地，分析器41可按照相同的方式更新初始准确性数据库11。分析器41还可请求其它受欢迎度报告，例如如果新的城市对的价格已被首次结合到再计算触发平台4中的话。在不存在于分别关于价格的变动性、准确性和受欢迎度的历史和统计数据的情况下，分析器41尽可能保守地利用默认参数进行其处理。

现在转到第三个模块，合并器42通过考虑到输入的实时事件进行第二水平的概率判定。另外，合并器42是产生再计算指令并把再计算指令发出给计算平台2的实体。合并器42把分析器41的输出作为其决策的基础。这些数据提供关于数据域的所有价格的再计算优先级的第一估计。随后，合并器42叠加从实时事件的各个来源收集的所有信息，以修正再计算优先级。这导致增强的再计算优先级。

可选地，再计算触发平台4可考虑任何顾客服务水平协议，比如“保证每周至少一次重新计算所有价格”，和相应地修正优先级。再计算触发平台4首先选择内部价格数据表示43中的优先级最高的那些条目，并标记它们，以便重新计算。由于合并器优选了解在计算平台2的可用计算资源，因此它能够标记与在特定时间间隔中计算平台2能够重新计算的价格一样多的高速缓存价格。再计算触发平台4随后把作为结果的再计算指令发送给计算平台2。

来自实时事件的信息是在严格的统计模拟之上提高高速缓存数据的准确性的手段。它们可被用于跟踪实际会发生什么，而不仅仅是预计会发生什么。它是控制统计模型的预测，和当预测被证明是错误或者不适当的时候，修正所述统计模型的预测的手段。对于本例来说，可以设想几类实时事件：

参与者的事件通常是有选择地发生的(即，因时而异)，但是对再计算决定具有显著影响。外部顾客可提供关于高速缓存和顾客在他自己的平台上体验的购买之间的差异的反馈。所述反馈可用于修正利用统计模型预测的准确性，从而当需要时，强制更快的再计算。当保存在计算平台2中的数据的提供者(例如，提供旅行的旅行提供者)进行推销某个城市对的航班的促销活动时，可以认为这些价格更易变，从而更经常变得过时。从而，需要增大在促销活动期间的这些价格的再计算频率。再例如，有时可能需要计算平台2的维护操作，或者在系统1内可能遇到操作问题。在这种情况下，可以命令再计算触发平台4产生较少的再计算指令或者不产生再计算指令，分别直到维护结束和问题被恢复为止。

可用性事件指示高速缓存航班的准确性的实时状态。取决于事件的表述，可以肯定地知道计算平台2中的基础数据域的特定价格已变化，由此再计算触发平台4高速缓存的价格变得无效。不过，其它价格也可能受到影响，其中所述影响是不确定的，于是，这些价格过时的可能性可能被增大。例如，“舱位关闭”事件指示对特定航班来说，特定的预订舱位已满。该航班和舱位的座位不再可预订，从而再计算触发平台4高速缓存的相应价格肯定变得无效。不过，这也可能被视为相同航班的其它舱位和/或在该航班前后不久起飞的其它航班的相同舱位的座位可能变得更易变的指示。从而，它们变得过时的可能性增大，这些价格的再计算可能是有益的。再例如，低成本承运人根据航班上座率设定其座位的价格。依据上座率变化的通知，可以快速重新计算相应的高速缓存价格，从而提高/恢复高速缓存准确性。

票价变化事件的暗示难以估计。简单地说，票价包含诸如用于计算特定航班的价格的规则之类的信息和逻辑。从而，当计算特定航班的实际价格时，访问一组票价，确定哪个票价相关并实际被应用，最后，计算价格。从而，存在关系“航班<->票价”(不过，所述关系也可随时间而变化，因为哪个票价适用于特定航班的约束条件会变化)。不过，另一个方向“票价<->航班”的关系通常未被跟踪，即，不清楚哪种票价确实适用于哪些航班。此外，票价的变化可能影响根据基础数据域计算的大量价格。

为了确定票价事件的影响，可以利用计算平台2和再计算触发平台4之间的通信，向再计算触发平台4提供到计算平台2为计算价格而应用的票价的映射。当响应再计算指令计算价格时，计算平台2记录为了计算所请求的价格而被访问的所有票价。该信息随后被全局地保存在映射票价<->航班中，并且在计算平台2的每次计算中被保持。在收到票价变化事件时，输入管理器40搜索该全局映射，以便确定受票价变化事件影响的航班，并把它们标记为“已更新”。注意，票价变化不一定意味旅行推荐的价格变化，如上简要所述。

合并器42首先评估实时事件对高速缓存价格的潜在影响，而不是在未考虑事件与基本概率模型的关系的情况下，发起高速缓存的旅行推荐的再计算。首先关于所述事件在概率模型中的表示，分析所述事件。对于不可预测、从而根本未被包含在概率模型中的事件，比如促销活动或维护事件来说，所述事件被尽可能快地处理。不过，至少在一定程度上(如票价或可用性变化)在概率模型中表示的事件被累积，并比较其表现和概率模型的预测。当事件峰值局部和模型不相符时，即，事件的突发明显在成为概率模型的基础的统计量之外时，受影响的价格被标记为可能过时，以便尽可能快地重新计算它们。这样，由已存在于概率模型中、从而已被分析器41进行的判定预先考虑的事件引起的“噪声”被滤除。

可选地，为了优化起见，合并器42作用于内部数据表示43的网格视图，即，在其算法中，它一起考虑多组相邻的价格，而不是隔离地作用于一组价格。在这种方法中，相邻的价格数据集被视为具有聚合的特性值的单一数据集。作用于聚合的数据集限制稀少的再计算指令的产生，从而增大在计算平台2的互助化和优化机会。这降低计算成本。

图22总结了上述详细说明，给出了这里介绍的高速缓冲存储器更新方法的概况。

使预先计算的数据库查询结果的高速缓存保持最新的处理始于高速缓存的查询结果的不准确性的概率的确定44。所述确定由位于两个逻辑层面的两个活动构成：首先并且一般地，采用基于统计和概率数据的预测模型，以便估计特定的高速缓存查询结果不对应于重新计算的查询结果(假想地)的可能性。其次并且更具体地，考虑可能影响从而相应地增大高速缓存的查询结果过时的可能性的实时事件。这些实时事件由它们通常不确定地指示特定的高速缓存查询结果的不准确性，而是在这方面是非确定性的事实表征。从而依据其发生，只能分别得出准确和不准确的可能性的概率结论。

根据确定的预先计算的镜像数据库查询结果过时的可能性，再计算触发平台4自动发出45批量再计算指令。这些指令被计算平台2接收，计算平台2随后再计算相应的结果，并把它们返回46给再计算触发平台4。计算平台2还相应地更新搜索平台3的存储器。再计算触发平台4再接收所述结果，并把它们保存47在本地表示43中。这结束一个更新循环，下一个循环重复概率判定44。

下面参考图23，说明本发明的高速缓存更新策略的过程的定时的具体例子。在这个例子中，再计算触发平台4被配置成每20分钟产生批量再计算指令，即，判定高速缓存数据是否过时并产生和发出再计算指令的周期或循环用时20分钟。整个一天事前知道在计算平台2的资源，并且再计算触发平台4知道在计算平台2的可用计算资源，于是能够使再计算的数量与计算平台2的可用资源同步。

在再计算循环的开始，再计算触发平台4分析预先计算的镜像数据库查询结果，即，保存在内部数据库43中的附有价格的旅行推荐的当前准确性。该循环将产生由计算平台2在20分钟的循环结束时处理的一组再计算指令。同时，在计算平台一侧，正在计算来自最后一次循环的指令，从而产生新的价格推荐，并传回给再计算触发平台，这些新的价格推荐被保存在再计算触发平台，并可用于下一循环中的复发信息的分析和更新。

图23表示在04:00～05:00a.m.的时段中，计算平台2具有相当多的可用资源，从而在这一个小时中可以进行大量的再计算。不过之后，一直到9:00a.m.，都不存在可用的资源，从而此时不可能进行再计算。稍后在所述一天中，从09:00a.m.～7:00p.m.，在计算平台2一些资源可用。

在始于04:20a.m.的循环中，分析器41分析高速缓存准确性，同时合并器42相应地产生再计算指令。这些指令将由计算平台2在04:40a.m.实现。分析器41聚焦于它在所述循环的开始收到的MCP价格推荐。它计数接收的价格和其值已被保存在内部储存库中的在先价格之间的差异。根据所述差异，它修正信息的“变动性”复发源。输入管理器40保存接收的MCP价格，以便进一步检查。在4:40～5:00a.m.的周期中，计算平台2处理在时间间隔04:20～4:40a.m.期间从再计算触发平台4接收的再计算指令。再计算触发平台4知道对于接下来的时间片(05:00a.m.)及后续时间片，它不能产生任何再计算指令，直到09:00a.m.为止。不过，它仍然不断分析数据模型，以更新所有高速缓存的附有价格的旅行推荐的当前准确性。它将对未来的一直到08:40a.m.的每个循环进行所述相同的操作。

在08:40a.m.，分析器41判定在没有任何再计算的前4个小时期间，高速缓存的准确性降低。它从而在接下来的周期内产生再计算指令，不过只较低程度地产生再计算指令，因为从09:00a.m.～7:00p.m，在计算平台2的可用资源的数量有限。随后，在09:00a.m.，计算平台2开始处理它在之前的时间间隔(即，08:40～09:00a.m.)中接收的新的再计算指令，并将在从6:40～7:00p.m的循环结束之后停止。

之后，在整个夜晚，在计算平台2不存在任何更多的可用资源。从而，再计算触发平台4不产生任何另外的再计算指令，而是根据概率模型和可能到来的实时事件，继续分析高速缓存准确性。

本发明的再计算更新策略提供自动产生高速缓存再计算决定的手段。它确定哪些高速缓存的查询结果要被重新计算，并通过考虑到在计算平台的可用计算资源，按时间控制再计算。从而，通常凭借随着时间的过去而分别模拟最新性和过时性的概率模型，来估计高速缓存的查询结果的准确性。这种过时性分析能够每小时处理数十亿组数据，从而成为预先计算的镜像数据库查询结果的再计算的基础。

总之，这里介绍的再计算触发平台可用以下要点表征：

1、一种更新分布式数据库系统中的预先计算的镜像数据库查询结果的方法，其中所述分布式数据库系统包括再计算触发平台，所述再计算触发平台保持预先计算的数据库查询结果，和计算平台，所述计算平台根据保持在计算平台中的数据，计算预先计算的镜像数据库查询结果，所述方法包括：

-利用数据高速缓存平台，确定预先计算的镜像数据库查询结果过时的可能性，其中

-所述确定取决于概率模型和异步的实时事件的发生，

-所述概率模型模拟保持在再计算触发平台中的预先计算的镜像数据库查询结果和假想的实际数据库查询结果之间的差异，

-实时事件就预先计算的镜像数据库查询结果的期满来说是非确定性的，只对保持在再计算触发平台中的预先计算的镜像数据库查询结果和假想的实际数据库查询结果之间的差异具有概率影响，

-所述可能性通常是根据概率模型确定的，可能在发生异步的实时事件时被修正；

-根据确定的预先计算的数据库查询结果过时的可能性，数据高速缓存平台自动向计算平台发出再计算指令，以便更新预先计算的镜像数据库查询结果，其中指令再计算与其它预先计算的镜像数据库查询结果相比，过时的可能性更高的预先计算的镜像数据库查询结果；和

-在数据高速缓存平台，接收作为再计算指令的结果的更新的预先计算的数据库查询结果。

2、按照要点1所述的方法，其中概率模型根据统计历史数据，模拟保持在计算平台中的数据的变动性。

3、按照要点1或2所述的方法，所述方法还包括

-在数据高速缓存平台，分析在概率模型中是否表现了输入的异步实时事件；

-对于未在概率模型中表现的实时事件，尽可能快地发出关于各个特定的预先计算的镜像数据库查询结果的再计算指令；

-对于在概率模型中表现的实时事件，在一段时间内累积这样的实时事件，比较实际发生并且累积的实时事件和它们在概率模型中的表现，如果实际发生的累积的实时事件偏离其在概率模型中的表现达到给定程度，那么尽可能快地发出关于可能受影响的预先计算的镜像数据库查询结果的再计算指令。

4、按照前述要点任意之一所述的方法，其中在确定预先计算的镜像数据库查询结果过时的可能性，并发出再计算指令时，数据高速缓存平台考虑与保持在计算平台中的各组相邻的数据集对应的预先计算的镜像数据库查询结果的网格。

5、按照前述要点任意之一所述的方法，其中再计算触发平台根据在计算平台的可用计算资源的数量，发出再计算指令。

6、按照前述要点任意之一所述的方法，其中分布式数据库系统是旅行预订系统，其中计算平台保持关于旅行可用性和票价的信息，再计算触发平台保持根据旅行可用性信息和票价计算的附有价格的旅行推荐。

7、按照要点6所述的方法，其中实时事件包括航班票价变化，飞机座位空余情况变化，客户端机票请求和/或航班取消。

8、按照前述要点任意之一所述的方法，其中分布式数据库系统包括连接到计算平台的至少一个应用平台，所述至少一个应用平台保持和组织预先计算的数据库查询结果，数据库查询结果被保存在作为数据高速缓存平台发出的再计算指令的结果，而由计算平台填充和/或更新的至少一个应用平台中。

9、一种保持由计算平台根据保持在计算平台中的数据计算的预先计算的数据库查询结果的再计算触发平台，所述再计算触发平台被配置成：

-确定预先计算的镜像数据库查询结果过时的可能性，

-其中所述确定取决于概率模型和异步的实时事件的发生，

-其中所述概率模型模拟保持在再计算触发平台中的预先计算的镜像数据库查询结果和假想的实际数据库查询结果之间的差异，

-其中实时事件就预先计算的镜像数据库查询结果的期满来说是非确定性的，只对保持在再计算触发平台中的预先计算的镜像数据库查询结果和假想的实际数据库查询结果之间的差异具有概率影响，

-其中所述可能性通常是根据概率模型确定的，并可能在发生异步的实时事件时被修正；

-根据确定的预先计算的数据库查询结果过时的可能性，自动向计算平台(3)发出再计算指令，以便更新预先计算的镜像数据库查询结果，其中指令再计算与其它预先计算的镜像数据库查询结果相比，过时的可能性更高的预先计算的镜像数据库查询结果；和

-接收作为再计算指令的结果的更新的预先计算的数据库查询结果。

10、按照要点9所述的再计算触发平台，被进一步配置成

-分析在概率模型中是否表现了输入的异步实时事件；

-对于未在概率模型中表现的实时事件，尽可能快地发出关于各个特定的预先计算的镜像数据库查询结果的再计算指令；

-对于在概率模型中表现的实时事件，在一段时间内累积这样的实时事件，比较实际发生并且累积的实时事件和它们在概率模型中的表现，如果实际发生的累积的实时事件偏离其在概率模型中的表现达到给定程度，那么尽可能快地发出关于可能受影响的预先计算的镜像数据库查询结果的再计算指令。

11、一种保存在计算机程序指令的非临时性计算机可读存储介质，其中当在计算机系统上执行时，所述计算机程序指令使计算机系统：

-确定预先计算的镜像数据库查询结果过时的可能性，

-其中所述确定取决于概率模型和异步的实时事件的发生，

-其中所述概率模型模拟保持在计算机系统中的预先计算的镜像数据库查询结果和假想的实际数据库查询结果之间的差异，

-其中实时事件就预先计算的镜像数据库查询结果的期满来说是非确定性的，只对保持在计算机系统中的预先计算的镜像数据库查询结果和假想的实际数据库查询结果之间的差异具有概率影响，

-其中所述可能性通常是根据概率模型确定的，并可能在发生异步的实时事件时被修正；

-根据确定的预先计算的数据库查询结果过时的可能性，自动发出再计算指令，以便更新预先计算的镜像数据库查询结果，其中指令再计算与其它预先计算的镜像数据库查询结果相比，过时的可能性更高的预先计算的镜像数据库查询结果；和

-接收作为再计算指令的结果的更新的预先计算的数据库查询结果。

11、一种指令计算机进行按照要点1-8任意之一所述方法的计算机程序。

搜索结果处理和显示子系统

按照另一个方面，在搜索平台提供处理和显示客户端的请求的方式。该处理允许以结构化方式返回并显示满足由客户端的数据库查询指示的标准的预先计算的数据库查询结果。

这种方法通常基于具有一个或多个类别的数据库查询结果的思想，其中每个类别对用户具有特定的含义。例如，一个类别可以是“最新更新的查询结果”。另一个类别可以是“最经常返回给客户端的查询结果”。按照这种方法，在第一层面，满足客户端请求指定的标准的数据库查询结果被分成这样的类别。在第二层面，每个类别内的结果被分类或排序。分类和排序的结果随后被返回给客户端，客户端可按照特定方式，至少显示每个类别中的最前面的结果或者几个最前面的结果(例如，前3个或前5个)。例如，可突出地呈现这些“类别优胜者”，以致用户能够识别哪个是最新的结果，哪个是客户端请求最经常请求的结果。

处理并显示随后呈现的客户端查询结果的这种方法的例子由计算机化旅行预订系统(CRS)实现。不过，应注意通常可与成为数据库查询请求的基础的数据的特定性质和内容无关地实现这种方法。当然，要定义的具体类别取决于数据的内容。不过，在总体上获得类别并对这些类别内的结果排序的方法可用于任何类别的数据。

CRS可用于保存和检索信息，并进行与商品和服务相关的在线交易，比如由访问旅行服务提供者的顾客发起的机票的在线购买。在空中旅行的情况下，CRS被配置成通过识别满足给定路线的特定航班，对来自旅行服务提供者的路线查询作出反应，并进行或登记预订。CRS可被包含在全球分销系统(GDS)中，GDS是一种预订和销售多个航空公司的机票的CRS。客户端查询结果显示处理和显示方法的例子便于从大量的可能旅行选项中选择一个或多个特定的旅行选项，并通过旅行服务提供者把特定的旅行选项提供给提交路线查询的顾客。

旅行服务提供者(比如旅行社)与CRS交互作用，以便响应来自预期顾客的查询，搜索旅行选项。响应包含在搜索请求中的询问，CRS从一个或多个数据库中搜索包括满足请求中的检索词的旅行选项的搜索结果。CRS随后把包含在搜索结果中的旅行选项分类成属于一个或多个类别。例如，代表搜索返回的航班路线的旅行选项可被分类成属于低成本航班类别，和属于最快速旅行选项类别。随后利用基于排序的拣选，选择出自每个类别的一个或多个旅行选项，并包含在该类别的最佳旅行选项子集中。

这些子集中的旅行选项从而被认为代表在该子集的各个旅行选项类别内的最佳或最好的旅行选项。每个子集从而提供更大的一类旅行选项内的被认为对可能的顾客来说更合意的一个或多个旅行选项。这些选择的旅行选项随后被传送给旅行服务提供者，以便作为特色结果显示给可能的顾客。所述一个或多个最好或最佳的选项子集从而是按照类别分类的更大的一组旅行选项的子集，所述更大的一组旅行选项又是满足搜索标准的更大一组所有可能的旅行选项的子集。通过应用逻辑来按照类别对旅行选项分类，并随后对类别内的旅行选项排序，以便呈现该类别中的排在最前面的N个旅行选项，选择包含这些最佳选项子集的旅行选项。通过把向顾客显示的选择限制于所有可能的旅行选项的子集，实现向客户端的更有价值的改进显示。

为此，客户端查询结果显示处理和显示方法的例子目的在于选择更大一组旅行选项的子集，作为数据库搜索引擎返回的特色结果，以致旅行服务提供者的顾客不会因选择过多而不知所措。这些特色结果随后可以和进行特定选择的邀请一起，由旅行服务提供者在显示器上可见的网页中呈现给其顾客。搜索结果的处理根据消除不太相关的产品或选项的适当逻辑，除去不太合意的旅行选项。一种方法是利用单一参数，比如票价、旅行时间、发出时间或者到达时间来处理搜索结果。不过，诸如此类的简单参数的操作可能对顾客来说过于透明，从而不能传递足够的感知价值。通过组合地利用对呈现给顾客的旅行选项的分类和排序，可以使搜索结果选择公式或算法的操作不那么透明。另外，通过基于与保存在系统可访问的数据库中的过去的顾客行为相关的各种数据的“自动学习”，可改善关于未来的搜索结果的选择算法性能。为了进一步提高顾客对呈现的旅行选项的信任，实施例还可用向顾客提供有形的信心来源的“可靠性标记”，来证明每个提议。

搜索结果处理和显示系统的例子可包括在CRS的搜索引擎，所述搜索引擎在对旅行选项搜索结果的相关性打分或排序时，考虑过去的顾客选择。在空中旅行的具体情况下，航班搜索结果可以从公开和私下协商的费率数据库获得，并至少部分根据在先销售数据、预订数据、购票数据和对类似航班的需求数据被排序。例如，搜索特定一对出发地和目的地位置之间的航班的顾客或旅行社已示范提供关于对于试图预订航班的当前系统用户来说，哪些航班最可能感兴趣和相关的选择模式。哪些航班更可能(即，具有相对高的概率)被请求具有相似一组搜索参数的搜索的顾客选择的历史从而可被用于对当前的航班搜索结果分类，从而缩小待呈现给顾客的选择的数目。历史上不太可能(即，具有相对低的概率)被顾客选择的航班可被从显示的结果中滤出，从而减小视觉混乱，和向顾客提供更易管理的一组旅行选项选择，作为特色结果。

CRS的搜索结果选择系统也可利用其它参数来确定旅行服务提供者应向顾客呈现哪些旅行选项。例如，对于给定出发地、目的地和旅行日期，搜索结果选择系统可从一个或多个类别的旅行选项中，选择要显示的特色结果。这些可包括显示作为特色结果的最受欢迎的航班路线，作为特色结果的总的来说最快或者最短时间的航班路线，作为特色结果的为旅行服务提供者与一个或多个选择的航空公司协商的专属提议的一部分的航班路线，作为特色结果的全部最廉价可行航班或旅行解答，作为特色结果的对于所请求的旅行日期、出发地和目的地，所有分销者中的最后或者最新预订的航班路线，和/或作为特色结果的由旅行服务提供者赞助的代表特定推荐的航班路线。

在备选例子中，从CRS向旅行服务提供者传送限制条件标记或紧迫感指示符，以便显示给顾客，作为其决策的帮助。紧迫感指示符代表特色结果中的一个或多个航班路线的受欢迎度。例如，CRS使已预订特定航班路线的人数的指示，作为紧迫感指示符被传送给旅行服务提供者，以便显示给顾客。另一方面，CRS使指示对于某个航班或类似航班，最后预订机票的时候的时间戳，作为紧迫感指示符被传送给旅行服务提供者，以便显示给顾客。替代地，CRS可使对于某个航班路线，目前有多少个空座位的报警指示，作为紧迫感指示符被传送给旅行服务提供者，以便显示给顾客。CRS还可使多个紧迫感指示符同时被返回，以便显示给顾客。

参考图24，并且按照本发明的实施例，对应于图1的数据库系统1的搜索结果选择系统的例证工作环境包括呈CRS 12形式的旅行选项搜索系统平台、用户平台14和至少一个数据库平台16。硬件平台12、14、16通过网络18相互通信。硬件平台12可包括处理器61、存储器91、大容量存储器件77、网络接口69和人机接口(HMI)50。硬件平台14可包括处理器63、存储器89、大容量存储器件83、网络接口71和HMI 51。硬件平台16可包括处理器67、存储器93、大容量存储器件81、网络接口73和HMI 52。

每个处理器61、63、67可包括一个或多个处理电路，所述处理电路选自微处理器、微控制器、数字信号处理器、微计算机、中央处理器、现场可编程门阵列、可编程逻辑器件、状态机、逻辑电路、模拟电路、数字电路、和/或根据保存在相关的平台存储器89、91、93中的操作指令处理信号(模拟和/或数字)的任何其它装置。每个存储器89、91、93可包含单个存储器件或多个存储器件，包括(但不限于)只读存储器(ROM)、随机存取存储器(RAM)、易失性存储器、非易失性存储器、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、闪存、高速缓冲存储器、和/或能够保存数字信息的任何其它器件。各个大容量存储器件77、81、83可包含一个或多个大容量存储器件，包括(但不限于)硬盘驱动器、光盘驱动器、磁带驱动器、非易失性固态器件和/或能够保存数据(比如数据结构85、87)的任何其它装置。

网络接口69、71、73可采用一种或多种适当的通信协议通过网络18通信，比如用户数据报协议/网际协议(UDP/IP)，和/或传输控制协议/网际协议(TCP/IP)。网络接口69、71、73可通过硬连线链路，比如IEEE802.3(以太网)链路，利用无线网络协议的无线链路，比如802.11(Wi-Fi)链路，或者允许硬件平台12、14、16与网络18面接的任何其它适当链路，连接到网络18。网络18可包括多个互连网络，比如一个或多个局域网(LAN)、广域网(WAN)、和/或诸如因特网之类的公共网络。因特网是互连计算机网络的全球系统。万维网是通过因特网访问的互相链接的超文本文档的系统，更具体地，是通常从web服务器，利用web浏览器访问的利用超链接和统一资源定位符(URL)链接的文本文档和其它资源的集合。利用web浏览器，用户/顾客可查看由可以是托管在硬件平台14上的应用程序的CRS产生的网页，所述网页可包含文本、图像、视频和其它多媒体，并且通过超链接在它们之间导航。

各个处理器61、63、67可在相应操作系统88、97、99的控制下工作，操作系统88、97、99可驻留在相应平台14、16、18的对应存储器89、91、93中。操作系统88、97、99可管理相应平台14、16、18的计算机资源，以致体现为驻留在存储器89、91、93中的一个或多个计算机软件应用程序54-57的计算机程序代码具有由处理器61、63、67执行的指令。HMI 50-52可按照已知方式，操作上耦接到相应硬件平台12、14、16的处理器61、63、67。HMI 50-52可包括诸如字母数字显示器、触摸屏和其它视觉指示器之类的输出装置，和能够接受来自操作者的命令或输入，并把输入的输入传送给处理器61、63、67的输入装置和控件，比如字母数字键盘、指示装置、小键盘、按钮、控制旋钮等。

参考图25，CRS 14的旅行选项搜索系统(TOSS)60包括搜索平台3的实例(大规模搜索平台，MSP)，和计算平台2的实例(大规模计算平台，MCP)。图25中所示的包括TOSS 60的功能可通过由TOSS平台12托管的一个或多个搜索应用54、55提供，和/或可由在通过网络或其它通信介质连接的独立硬件平台上运行的应用提供。计算平台2包括高速缓存管理模块68、定价引擎插件65和票价搜索引擎插件66。高速缓存管理模块68管理来自搜索平台3的再计算指令以及插件65、66，并把计算的数据库查询结果返回给搜索平台3。

如上结合计算平台2详细所述，计算平台的主要功能是在给定的时间范围内计算众多的价格，并把这些计算结果提供给搜索平台3。在图25的例子中，插件65、66被设计成满足这两个目的，和实现上面详细说明的功能。为了简单起见，图25未描述大规模主模块20和大规模工作模块22。计算平台2从而提供允许搜索平台3访问任意大量的数据和/或进行任意大量的价格计算的完全可缩放性。票价搜索引擎插件66可连续运行，以致最低票价旅行选项不断被计算平台2更新，和在搜索平台3中被刷新。另外或者替代地，可以采用更新再计算触发平台4的预先计算的数据库查询结果的智能方法(为了简单起见，图25未说明)。搜索平台3中的旅行选项数据从而可反映实时或近实时票价。对于包括需要最低票价旅行选项之中的根本未被预先计算或者最近被更新的数据的独特路线的搜索请求，定价引擎插件65可依据高速缓存管理器68的内部请求，计算所述独特路线的唯一价格。唯一定价的路线随后可由高速缓存管理模块68提供给搜索平台3。

定价引擎插件65和票价搜索引擎插件66都可与包含和航空公司航班相关的数据的一个或多个数据库操作性通信，比如Travel AgencyOriginating Commission(TAOC)费用数据库70，航班票价数据库72，航班时间表数据库74，和航班可用性数据库75。TAOC费用数据库70可包括关于由与TOSS运营者具有预先存在的关系的在线旅行社提供的辅助服务的信息。票价数据库72可包括公布和协商的票价，例如，公布的航空公司票价，和由旅行社协商的票价。类似地，时间表数据库74可包括航空公司航班时间表，航班可用性数据库可包括和航班的可用性和/或航班上的空座位有关的信息。各个数据库70、72、74、75都可包括包含在TOSS 60内可访问，但是从系统60之外接触不到的专有数据的数据库。各个数据库70、72、74、75还包括可从可公开访问的数据库获得的数据。数据库70、72、74、75中的两个或者更多的数据库可被结合成单个数据库，比如时间表数据库74和航班可用性数据库75。

为了检索旅行选项数据，票价搜索引擎插件66(它一般一次处理众多的路线)和/或定价引擎65(它一般每次处理单一路线)中的一个或多个查询数据库70、72、74、75，进行低票价搜索处理，并传送搜索结果。这些结果随后被发送给搜索平台3。在搜索结果处理和显示子系统的例子中，计算平台2的插值65、66返回包括与搜索请求中的检索词匹配的航班的价格、可用性和时间表数据的结果。典型的检索词可包括各种不同的路线(例如，出发地/目的地和旅行日期)。

为了使确定旅行选项的受欢迎度，最后的预约日期，和/或最后时间戳索引功能更容易，高速缓存管理器68可以与最后预约日期/时间戳(LBDT)数据库80通信。LBDT数据库80可保持和/或访问包含与系统用户预约的旅行选项相关的历史数据的一个或多个专有数据库。在图25中所示的例子中，LBDT数据库80包括预约信息数据库82、专有购票信息数据库84，和市场情报数据库86。预约信息数据库82可包括用户通过TOSS 60进行的旅行预约的所有乘客姓名记录(PNR)数据。专有购票信息数据库84可包括与通过旅行预约系统销售的所有机票相关的数据。专有的预约信息和购票信息数据库82、84中的数据可以是当预订机票时，由TOSS 60捕捉的数据。于是，该数据可以是对在TOSS 60之外的系统不直接可用的数据。市场情报信息数据库86可包括可由例如旅行社、航空公司和/或其它旅行预约系统操作的所有可全局访问的PNR数据库的库存。

在图25的例子中，搜索平台3包括旅行解答智能索引(TSSI)76，TSSI76按照一个或多个公式、算法、规则和/或标准，对从数据库70、72、74、75、80获得的搜索结果进行索引和/或分类。TSSI可对应于如上结合图11说明的搜索平台3的内存存储器(In Memory Storage)301。高速缓存管理器68可按照上面详细说明的方式，把搜索结果提供给TSSI 76。高速缓存管理器68管理由定价引擎和票价搜索引擎插件65、66返回的数据库查询结果。高速缓存管理器68定期从LBDT数据库80刷新搜索平台3中的数据，以致当预约、购票和市场情报数据被更新时，使TSSI 76中的数据保持实时或近实时最新。通过利用排序-比如从一个或多个数据库或子数据库获得的历史旅行预约数据-TSSI可进一步对分类的搜索结果进行分类或排序，以便于把显示的结果限制于易管理的数目。例如，TSSI76可根据选择的排序参数，对特定搜索的结果分类。特色结果事务79可利用该索引或排序，在一个或多个类别的每个中显示一个或多个选择的结果，同时所述选择的结果代表适合于给定的初始搜索类别的“最佳”选择。可以定期重新计算和/或刷新排序，以致按照可获得的最新预约和购票数据，对搜索结果排序。通过在TOSS 60内设置托管和索引搜索结果数据的本地数据库-例如，以内存存储器301的形式-TSSI 76可向最终用户提供对搜索请求的更快响应时间。从而与每当系统用户提交搜索请求时，必须从外部数据库检索旅行选项信息的系统相比，改善了系统的感知性能。

旅行服务提供者可通过网站与TSSI 76交互作用，以响应来自顾客的询问搜索旅行选项。通常，网站是通常位于公共服务器上，并作为信息的集合而准备和维持的互连网页的集合。响应来自旅行服务提供者的查询，可以向显示功能78提供特色结果事务，显示功能78再在显示器上，以可读格式把特色结果提供给请求实体。请求实体可以是旅行社网站，旅行选项预约应用56，或者系统用户或顾客可用于搜索和预约旅行选项的任何其它应用。显示功能78还可提供应用编程接口(API)，所述API被外部资源或应用，比如旅行选项预约应用56、web服务器应用(未图示)或任何其它适当的应用用作与TOSS 60的接口。

在开发搜索结果选择、索引和/或排序公式时，在历史旅行选项选择数据的初步分析中，可以考虑数据的所有可能来源和种类。根据该分析，可以根据旅行选项特性对顾客选择的影响或者与顾客选择的相关性，选择旅行选项特性。分析的旅行选项数据可包括(但不限于)票价、旅行时间、航空公司和旅行选项被预约的次数，这仅仅是列举几个参数。例如，旅行选项过去被预约的次数可被用于定义旅行选项分类的类别，以及对该类别或另一个不同类别内的搜索结果排序。系统随后可定义可以区分预约的一个或多个选项与未被预约或者以较低的选择率被预约的其它备选旅行选项的所有可能标准。例如，可以使航班预约率与飞行时间、起飞时间、返回时间、经停数、总价格、航空公司、出港机场、到港机场、星期几起飞、星期几返回、出发日期、返回日期等关联。这些旅行选项特性中的每一个都可被组合，以确定与对应的旅行选项被选择的频度相关联的复合值。该复合值又可以是用于选择旅行选项搜索的特色结果的几个值之一。

用于区分预约的旅行选项的类别并不局限于上述列表任意之一，可包括表征旅行选项的任意标准。系统可分析数据集，并根据分析选择有关的类别。所述分析可考虑到数据集的不同维度，并取决于可用于每个数据点的数据量，平衡分级(rating)。如果对于给定的数据点，不存在足够的数据，那么处理可以抽取或内插变量，直到该变量由相当大量的数据表示为止。选择的类别可被应用于搜索结果，以确定哪些结果作为特色结果呈现给系统用户。有影响的类别组合也可被聚合，以形成提供给系统用户的提议旅行选项选择的多样性。

为此，TSSI 76用于对计算平台2(预先)计算的数据库查询结果分类的类别可包括(但不限于)以下类别：

最快-TSSI 76可处理来自计算平台2的计算的数据库查询结果，以识别有限的规定数目的旅行选项，作为待包括在特色结果事务79中的一组特色结果，所述有限的规定数目的旅行选项具有从出发点到最终目的地的最短耗用时间。另一方面，TSSI 76可识别对于所请求的日期，具有从出发点到最终目的地的最短耗用时间的旅行选项，它可被显示成单一的特色结果。作为数值例子，所述一组特色结果中的旅行选项的有限的规定数目可以是10个最快的旅行选项。耗用时间(elapsed time)可包括路线的飞行时间，和路线中的任何中转之间的留地时间。可以严格地利用类别的分类(例如，从最快的旅行选项到最慢的旅行选项)，对所述一组特色结果分类，以便显示。另一方面，可以利用诸如旅行选项费用之类的排序，从最便宜到最贵对特色结果分类，以便显示。例如，一组特色结果中的10个最快的旅行选项可被排序，以便从最便宜的旅行选项到最贵的旅行选项地显示。

受欢迎-TSSI 76可处理来自计算平台2的计算的数据库查询结果，以识别有限的规定数目的旅行选项，作为待包括在特色结果事务79中的一组特色结果，所述有限的规定数目的旅行选项例如是被最频繁预约或者最频繁购票，即，最受欢迎的旅行选项。另一方面，TSSI 76可识别单一旅行选项，该旅行选项是被最频繁预约或者最频繁购票的旅行选项，它可被显示成单一的特色结果。这种类别可把不同的粒度用于编译的预约和购票数据，比如全球预约或购票的机票，只在预定市场内预约或购票的机票，或者只在某个销售点预约或购票的机票。受欢迎度的这些子类别也可被组合，以产生复合的受欢迎评级。可以严格地利用依据类别提供的分类(即，从最受欢迎的旅行选项到最不受欢迎的旅行选项)，或者与限定供显示的特色结果的另一个参数，比如旅行者期望的路线、承运人、时间表和/或费用组合地拣选所述一组特色结果，以便显示。

专属-TSSI 76可处理来自计算平台2的计算的数据库查询结果，以识别有限的规定数目的旅行选项，作为待包括在特色结果事务79中的一组特色结果，所述有限的规定数目的旅行选项包括联营旅行社与一家或几家航空公司协商的辅助服务。另一方面，TSSI 76可识别包括协商的辅助服务的单一旅行选项，它可被显示成单一的特色结果。例证的辅助服务可包括专属于旅行者的任何附加服务，比如补充的贵宾服务、升级的餐食和/或座位升级。联营的旅行社可以是可访问TOSS 60的一个或多个选择的旅行社。可根据与航空公司的附属于这些辅助服务的票价匹配的最低费用推荐-即，根据旅行选项的总费用和/或仅仅根据相关的机票票价的费用，对该类别中的特色结果排序，以便显示。

最便宜-TSSI 76可处理来自计算平台的计算的数据库查询结果，以识别公开的票价和在一家或多家航空公司与参与的旅行社之间商定的协议价之中的有限的规定数目的最便宜旅行选项(例如，10个最便宜的旅行选项)，以便包含在特色结果事务79中。另一方面，可用单一的最便宜旅行选项填充特色结果事务79，所述单一的最便宜旅行选项可作为单一的特色结果被显示给用户。在多个票价定价相同的情况下，可根据受欢迎度，比如关于上述“受欢迎”类别所述地对各个选项排序，以便显示。

最后预约-TSSI 76可处理来自计算平台2的计算的数据库查询结果，以识别特色结果事务79中，在所述分销商之中最近预约的有限的规定数目的旅行选项(例如，10个最近预约的旅行选项)。另一方面，TSSI 76可识别预约的单一的最新(例如，最晚)的旅行选项，该旅行选项可被显示成单一的特色结果。如果特定顾客过去预约过具有相同或相似特性的旅行-例如在相同的出发地和目的地之间-那么“最后预约”选项也可显示该特定用户最后选择的航班选项，或者可因特定顾客过去的相同或相似预约而有倾向性。

赞助-TSSI 76可处理来自计算平台2的计算的数据库查询结果，以识别由赞助实体，比如旅行社选择的有限的规定数目的旅行选项(例如，10个旅行选项)，以包含在特色结果事务79中。另一方面，TSSI 76可识别单一的赞助旅行选项，它可被显示成单一的特色结果。这些旅行选项可包括特定路线、承运人或票价，可以基于赞助实体和旅行选项提供者之间的协商交易，比如从航空公司向旅行社支付的更高佣金。

在搜索结果处理和显示子系统的例子中，可按照受欢迎度排名，对搜索结果的每个类别排序。即，按照诸如受欢迎度之类的排序，拣选某个类别的搜索的子集，比如类别内的排在前面的规定数目N个结果。随后可向顾客显示出自该排序子集中的最前面的一个或几个结果，作为特色结果。这样，呈现给顾客的选择数可被限于易管理的数目。这种限制可降低由过于大量的选择数引起的顾客的焦虑，从而便于更快速、不太有压力的决策。除了过去预约过特定航班的顾客的数目之外，LBDT数据库80还可包括关于预约特定路线的最后机票的时间，特定购票选项的剩余座位的数目，和与特定标准，比如预约或者购买某个日期、时间、价格、目的地等的机票的旅行者的数目相关的受欢迎度的信息。可根据一年中的时间(例如，人们在3月预约航班的地方)；出发地(例如，人们从芝加哥飞向哪里)；价格(最便宜的目的地是哪里)，或者任何其它旅行参数，以表示最受欢迎目的地的地图形式，显示特色结果。

现在参见图26，流程图90图解说明按照本发明的实施例的特色结果选择算法。在方框92，TOSS 60接收搜索查询。搜索查询一般起源于托管在用户平台14上的应用，比如预订应用56。不过，搜索查询也可起源于托管在旅行选项搜索系统平台12上的应用，比如web服务器应用(未示出)，或者可以访问TOSS 60的某个其它适当平台上的应用，比如第三方机票预订系统。例如，响应顾客请求在期望的旅行日期，出发地和目的地之间的旅行选项，运行于旅行社web服务器或旅行选项预约系统上的应用可发出搜索查询。

在方框94，TOSS 60从TSSI 76数据库检索搜索结果。在搜索查询包括不匹配在TSSI 76中索引的旅行选项的检索词的情况下，TOSS 60可通过计算平台2，搜索另外的数据库70、72、74、75、80，并把更新的数据提供给TSSI 76。这些搜索结果可包括满足搜索参数的所有旅行选项，数目达到成千上万。搜索结果可由TSSI 76如上索引到类别中。

在方框96，TOSS 60加载第一类别。可用上述类别之一，比如耗用时间最短的旅行选项，受欢迎度，专属提议的存在，费用，最后预约和/或赞助，对第一类别分类。在方框98，TOSS 60选择和加载的类别匹配的搜索结果，并进入方框100。在方框100，根据等级，在类别内排列或拣选选择的搜索结果。所述等级例如可以基于预先选择的搜索结果的受欢迎度，所述受欢迎度可由TSSI 76如前所述确定。所述等级也可基于旅行选项的参数和对应旅行选项过去被预约或购票的频度之间的相关性。关联的组合可以严格基于预约率和旅行选项参数之间的相关性。为了提供一组特色结果，选择类别内的排在最前面的给定数目N的结果，以便呈现给搜索查询请求者。所述给定数目一般小于类别内的结果的总数，并且可以是最前面的一个结果。

在方框102，TOSS 60判定搜索结果的所有类别是否都已被浏览。如果否(判定框102的“否”分支)，那么TOSS 60进入方框104，加载搜索结果的下一个类别。TOSS 60随后返回方框98，以利用新加载的类别，重复特色结果选择处理。如果已关于特色结果浏览了所有搜索结果类别(判定框103的“是”分支)，那么TOSS 60进入方框106。在方框106，检索为呈现给请求方而选择的旅行选项，并为类别内的每个特色结果或一组结果，计算紧迫感指示符。TOSS 60随后进入方框108，在方框108，特色结果通过显示功能78，被提供给请求方。

通过匹配搜索参数和每个公式的数据集维度，搜索结果选择处理从而把一个或多个公式应用于给定的搜索请求，每个公式对应于特定类别。搜索结果选择处理随后对利用每个公式产生的结果的列表排序，并确定类别内的前N个结果。每个公式可对应于限定类别，可相应地限定每个提出的结果。

每个类别可以与和结果一起返回的限制条件标记关联。其它紧迫感标记也可和每个特色结果一起被返回。结果公式可具有定性标记和定量标记。在定性公式的情况下，限制条件标记可被固定，以识别与公式相关的特定定性标准。例如，所述标记可把公式的类别识别成最便宜或最快的可用旅行选项。在定量公式的情况下，限制条件标记可包括数值参数。例如，限制条件标记可以基于作为与特色结果中的一个或多个旅行选项相关的紧迫特征的最后预约时间，比如X分钟之前最后预约了旅行选项。又例如，限制条件标记可以基于作为紧迫特征，与特色结果一起供给的特色结果中的各个旅行选项过去被预约的频度。再例如，限制条件标记可指示作为紧迫特征，与特色结果一起供给的特色结果中的各个旅行选项的剩余空座位数。给定结果也可属于多个类别。例如，特定航班可以同时是期望的出发地和目的地对的最便宜和最快的旅行选项，在这种情况下，该航班可被索引成属于这两个类别。搜索结果限定处理可标记各个结果，并在定量结果的情况下查寻数值，并且响应可包括包含相应的限制条件标记的结果选择。

现在参见图27，例证的特色结果页面110，比如可由浏览器应用显示的页面在旅行选项搜索结果类别窗口112a-112f中，提供特色结果。尽管如图27中图解所示的搜索结果页面110包括6个搜索结果类别窗口112a-112f，不过本发明的实施例可包括任何数目的类别窗口，本发明并不局限于特定数目的类别窗口。显示在每个类别中的特色结果的数目也不局限于任何特定数目，例如可以是单个特色结果。作为可如何显示特色结果的另一个例子，响应用户选择或悬停在特定类别之上，系统可展开类别窗口112a-112f，以显示该类别的另外的特色结果。从而，本领域的普通技术人员会理解图27中图解所示的特色结果页面只表示显示特色结果的一种例证方式，本发明的实施例并不局限于所示的显示结构。

每个类别窗口112a-112f可包括识别搜索结果分类的类别标识符标记114a-114f，一个或多个特色旅行选项分段窗口116a-116f、118a-118f，和价格/可用性信息窗口120a-120f。如图27中所示，类别窗口112a-112f包括包含出发分段116a-116f和返回分段118a-118f的旅行选项，不过在类别窗口112a-112f内可显示其它数目的旅行选项和/或分段。例如，本发明的实施例可显示具有一个或多个分段的单程旅行的旅行选项，或者都具有一个或多个分段的多个旅行选项。

特色旅行选项分段窗口116a-116f、118a-118f包括关于对应旅行选项的信息，比如航线承运人124、出发地126、到达地128、持续时间130、票价类型132和计划的中途停留地134。

各个价格/可用性信息窗口120a-120f可包括旅行选项价格136a-136f，基于关于旅行选项的顾客反馈的星级评定138a-138f，和一个或多个紧迫特征。紧迫特征包括指示空座位的数目的标记140a-140f，指示最后预订座位的时间的标记142a-142f，和/或指示有多少人预订了该旅行选项的标记144a-144f。操作中，希望搜索和/或预订航班的顾客可按照已知方式，利用web浏览器登录旅行社网站。旅行社网站可由用户平台14托管，用户平台14可包括一个或多个应用，比如预订应用56和/或web服务器应用(未图示)。顾客可通过web浏览器，输入期望的出发地和目的地，以及旅行时间。预订应用56可接收输入的信息，并据此向TOSS 60发出搜索请求。在本发明的备选实施例中，顾客可登录由TOSS平台12，或者由TOSS 60的运营者所拥有的另一个平台托管的web服务器应用或预订应用。响应收到旅行选项搜索参数，TOSS 60可搜索数据库，寻找与输入的信息匹配的旅行选项。随后可如前关于图25和26所述，对搜索结果排序。TOSS 60随后按一个或多个初始搜索排序类别，把特色结果提供给发出请求的应用。发出请求的应用随后把结果显示成特色结果页面，如上关于图27所述。

总之，处理、返回和显示预先计算的数据库查询结果的方式可用以下要点表征：

1、一种方法，包括：

根据搜索查询中的检索词，从旅行选项数据库中检索多个旅行选项；

按照至少一个类别，对旅行选项分类；

对于每个类别，对旅行选项排序；和

提供每个类别的排序的旅行选项至少之一，以显示给顾客。

2、按照要点1所述的方法，还包括：

确定所述至少一个旅行选项的紧迫感指示符；和

与排序的旅行选项至少之一关联地提供所述紧迫感指示符，以便显示。

3、按照要点2所述的方法，其中紧迫感指示符包含限制条件标记(qualitative flag)。

4、按照要点2所述的方法，其中紧迫感指示符包含包括数值的定量标记。

5、按照要点1所述的方法，其中类别是各个旅行选项的耗用时间，各个旅行选项的受欢迎度，与各个旅行选项相关的专属提议的存在，各个旅行选项的费用，各个旅行选项最近被预订的时间，或者与各个旅行选项相关的赞助。

6、按照要点1所述的方法，其中根据各个旅行选项的耗用时间，各个旅行选项的受欢迎度，各个旅行选项的费用，或者各个旅行选项最近被预订的时间，对旅行选项排序。

7、一种计算机程序产品，包括：

非临时性计算机可读存储介质；和

保存在计算机可读存储介质上的程序指令，当被处理器执行时，所述程序指令使处理器执行按照要点1所述的方法。

8、一种计算设备，包括：

处理器；和

包括指令的存储器，当由所述处理器执行时，所述指令使计算设备执行按照要点1所述的方法。

9、如这里说明的表示的系统、方法和计算机程序产品。

最后，图28是提供如图1所示的计算平台2、搜索平台3和/或再计算触发平台4，或者至少部分的这些模块(比如大规模主模块20或大规模工作模块22)或者整个系统(如果所有平台被结合成一个单体系结构实体)的功能的计算机系统的示意图。在计算机系统内，可以执行使计算机系统进行这里讨论的任意方法的一组指令。计算机系统包括通过总线184相互通信的处理器181、主存储器182和网络接口装置183。可选地，它还可包括静态存储器185和磁盘驱动器186。视频显示器187、字母数字输入装置188和光标控制装置189可构成分配名单导航器用户接口。网络接口装置183例如把再计算触发平台4连接到计算平台2，或者把搜索平台3连接到计算平台2等(如果各个平台是在分离的主机中实现的)，为填充预测模型而需要的统计数据的来源，比如统计数据服务器9，变动性数据库10和初始准确性数据库11，实时事件的来源，因特网和/或任何其它网络。体现任意或者所有上述方法的一组指令(即，软件)190完全或者至少部分地驻留在机器可读介质，例如主存储器182和/或处理器181之上或之中。软件190驻留于的机器可读介质也可以是作为磁盘驱动器单元186的一部分的非易失性数据载体191(例如，非易失性硬盘或者可拆卸的光盘或磁盘)。另外可通过网络接口装置183，经因特网以传播信号192的形式，传送或接收软件190。

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

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

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

Claims (30)

1.一种数据库系统，包括计算平台和搜索平台，其中

-计算平台被布置成

·从搜索平台接收批量再计算指令，每个批量再计算指令指示计算平台计算多个数据库查询结果，

·通过在给定时间范围内，按照批处理时间表计算多个数据库查询结果，处理批量再计算指令，

·把由批量再计算指令产生的计算的数据库查询结果返回给搜索平台；

-搜索平台被布置成

·把计算的数据库查询结果保持在存储器中，和

·使计算的数据库查询结果对连接到搜索平台的客户端可用，和向计算平台传送批量再计算指令。

2.按照权利要求1所述的数据库系统，其中批量再计算指令指示计算平台在最多24小时内，计算至少一百万个数据库查询结果。

3.按照权利要求1或2所述的数据库系统，其中计算平台还被配置成

-分析并把批量再计算指令分解成与多个数据库查询结果的子集相关的小的计算包；

-把计算包分派给处理模块，以便执行计算包的计算；

-重新聚集处理模块进行的计算包计算的结果；和

-把重新聚集的结果返回给搜索平台。

4.按照权利要求3所述的数据库系统，其中计算平台的分析并分解批量再计算指令的结构包括起以下作用的结构

-把批量再计算指令分离成原子计算事务；

-识别冗余的原子计算事务，并丢弃这些冗余的原子计算事务；

-对剩余的非冗余原子计算事务分组，以形成计算包。

5.按照权利要求3或4所述的数据库系统，其中计算平台被布置成按照批处理时间表，把计算包分派给处理模块，批处理时间表通过考虑到给定时间范围内计算模块的可用计算资源，提供负荷分配。

6.按照前述权利要求任意之一所述的数据库系统，其中搜索平台被布置成

-向每个计算的数据库查询结果分派表示所需的刷新频度的分数；

-通过把批量再计算指令引导到计算平台，更新一部分的计算的数据库查询结果，其中待更新的所述一部分的计算的数据库查询结果是根据分派的分数确定的；

-响应搜索平台从客户端接收的查询，进行数据库搜索，以找出满足包含在所述查询中的优先选择的那些计算的数据库查询结果；

-向客户端发出响应，并更新分派给返回给客户端的预先计算的数据库查询结果的分数。

7.按照前述权利要求任意之一所述的数据库系统，其中搜索平台还被布置成

-根据从连接到搜索平台的客户端之一接收的搜索查询中的标准，从存储器中检索多个计算的数据库查询结果；

-按照至少一种类别，对检索到的计算的数据库查询结果分类；

-对每个类别内的检索到的计算的数据库查询结果排序；和

-提供每个类别的排序后的检索到的计算数据库查询结果至少之一，以便显示给客户端。

8.按照前述权利要求任意之一所述的数据库系统，还包括再计算触发平台，所述再计算触发平台或者合并到计算平台或搜索平台中，或者是独立的实体，再计算触发平台被布置成

·保持计算平台计算的计算数据库查询结果的镜像，

·确定镜像的计算数据库查询结果过时的可能性，

·关于与其它预先计算的数据库查询结果相比，过时的可能性更高的一部分的计算数据库查询结果，向计算平台发出批量再计算指令，

其中计算平台还被布置成

·从再计算触发平台接收批量再计算指令，和

·把由批量再计算指令产生的计算的数据库查询结果返回给搜索平台和再计算触发平台两者。

9.按照权利要求8所述的数据库系统，包括连接到计算平台的多个搜索平台，并且再计算触发平台被布置成触发填充连接到计算平台的多个搜索平台任意之一的计算的数据库查询结果的再计算。

10.按照权利要求8或9所述的数据库系统，其中再计算触发平台还被布置成根据概率模型和异步实时事件的发生，确定镜像的计算的数据库查询结果过时的可能性，其中概率模型模拟保持在再计算触发平台中的镜像的计算的数据库查询结果和假想的实际数据库查询结果之间的差异。

11.按照权利要求8-10任意之一所述的数据库系统，其中再计算触发平台还被布置成

-分析在概率模型中是否表现了输入的异步实时事件；

-对于未在概率模型中表现的实时事件，尽可能快地发出关于相应特定的镜像的预先计算的数据库查询结果的再计算指令；

-对于在概率模型中表现的实时事件，在一段时间内累积这样的实时事件，比较实际发生并且累积的实时事件和它们在概率模型中的表现，并且如果实际发生的累积的实时事件偏离其在概率模型中的表现达到预定程度，那么尽可能快地发出关于可能被镜像的计算的数据库查询结果的批量再计算指令。

12.按照前述权利要求任意之一所述的数据库系统，其中数据库系统是旅行搜索系统或旅行预订系统，其中

-计算平台被布置成能访问关于旅行可用性和票价的信息，并被布置成根据旅行可用性信息和票价，计算附有价格的旅行推荐；

-搜索平台被布置成保持响应批量再计算指令，计算和接收自计算平台的计算的附有价格的旅行推荐，并响应查询而把预先计算的附有价格的旅行推荐返回给客户端，返回的预先计算的附有价格的旅行推荐满足包含在查询中的优先选择。

13.按照权利要求12所述的数据库系统，其中搜索平台被布置成

-根据从连接到搜索平台的客户端之一接收的搜索查询中的标准，从存储器检索多个预先计算的附有价格的旅行推荐；

-按照至少一个类别，把检索到的预先计算的附有价格的旅行推荐分类；

-对每个类别内的检索到的预先计算的附有价格的旅行推荐排序；和

-提供每个类别的排序后的检索到的预先计算的附有价格的旅行推荐至少之一，以便显示给客户端。

14.按照权利要求13所述的数据库系统，其中类别是每个预先计算的附有价格的旅行推荐的耗用时间，每个预先计算的附有价格的旅行推荐的受欢迎度，与每个预先计算的附有价格的旅行推荐相关的专属提议的存在，每个预先计算的附有价格的旅行推荐的费用，每个预先计算的附有价格的旅行推荐最近被预订的时间，或者与每个预先计算的附有价格的旅行推荐相关的赞助中的至少一个。

15.一种使预先计算的数据库查询结果客户端可用的方法，包括：

-计算平台从搜索平台接收批量再计算指令，所述批量再计算指令指示计算平台计算多个数据库查询结果，

-计算平台通过在给定时间范围内，按照批处理时间表计算多个数据库查询结果，处理批量再计算指令，

-计算平台把由批量再计算指令产生的计算的数据库查询结果返回给搜索平台；

-搜索平台把从计算平台接收的计算的数据库查询结果包含在存储器中；和

-搜索平台使计算的数据库查询结果对连接到搜索平台的客户端可用。

16.按照权利要求15所述的方法，其中批量再计算指令指示计算平台在最多24小时内计算至少一百万个数据库查询结果。

17.按照权利要求15或16所述的方法，还包括计算平台

-分析并把批量再计算指令分解成与多个数据库查询结果的子集相关的小的计算包；

-把计算包分派给处理模块，以便执行计算包的计算；

-重新聚集处理模块进行的计算包计算的结果；和

-把重新聚集的结果返回给搜索平台。

18.按照权利要求17所述的方法，其中计算平台分析并分解批量再计算指令还包括

-把批量再计算指令分离成原子计算事务；

-识别冗余的原子计算事务，并丢弃这些冗余的原子计算事务；

-对剩余的非冗余原子计算事务分组，以形成计算包。

19.按照权利要求17或18所述的方法，其中计算平台还按照批处理时间表，把计算包分派给处理模块，批处理时间表通过考虑到给定时间范围内计算模块的可用计算资源，提供负荷分配。

20.按照权利要求15-19任意之一所述的方法，还包括搜索平台

-向每个计算的数据库查询结果分派表示所需的刷新频度的分数；

-通过把批量再计算指令引导到计算平台，更新一部分的计算的数据库查询结果，其中待更新的所述一部分的计算的数据库查询结果是根据分派的分数确定的；

-响应搜索平台从客户端接收的查询，进行数据库搜索，以找出满足包含在所述查询中的优先选择的那些计算的数据库查询结果；

-向客户端发出响应，并更新分派给返回给客户端的预先计算的数据库查询结果的分数。

21.按照权利要求15-20任意之一所述的方法，还包括搜索平台

-根据从连接到搜索平台的客户端之一接收的搜索查询中的标准，从存储器中检索多个计算的数据库查询结果；

-按照至少一种类别，对检索到的计算的数据库查询结果分类；

-对每个类别内的检索到的计算的数据库查询结果排序；和

-提供每个类别的排序后的检索到的计算数据库查询结果至少之一，以便显示给客户端。

22.按照权利要求15-21任意之一所述的方法，其中再计算触发平台保持计算平台计算的计算数据库查询结果的镜像，所述再计算触发平台或者合并到计算平台或搜索平台中，或者是独立的实体，所述方法还包括

-再计算触发平台确定镜像的计算数据库查询结果过时的可能性，

-再计算触发平台关于与其它预先计算的数据库查询结果相比，过时的可能性更高的一部分的计算数据库查询结果，向计算平台发出批量再计算指令，

-计算平台从再计算触发平台接收批量再计算指令，和

-计算平台把由批量再计算指令产生的计算的数据库查询结果返回给搜索平台和再计算触发平台两者。

23.按照权利要求22所述的方法，其中多个搜索平台连接到计算平台，并且再计算触发平台触发填充连接到计算平台的多个搜索平台任意之一的计算的数据库查询结果的再计算。

24.按照权利要求22或23所述的方法，其中再计算触发平台还根据概率模型和异步实时事件的发生，确定镜像的计算的数据库查询结果过时的可能性，其中概率模型模拟保持在再计算触发平台中的镜像的计算的数据库查询结果和假想的实际数据库查询结果之间的差异。

25.按照权利要求22-24任意之一所述的方法，还包括再计算触发平台

-分析在概率模型中是否表现了输入的异步实时事件；

-对于未在概率模型中表现的实时事件，尽可能快地发出关于相应特定的镜像的计算的数据库查询结果的再计算指令；

-对于在概率模型中表现的实时事件，在一段时间内累积这样的实时事件，比较实际发生并且累积的实时事件和它们在概率模型中的表现，并且如果实际发生的累积的实时事件偏离其在概率模型中的表现达到预定程度，那么尽可能快地发出关于可能被镜像的计算的数据库查询结果的批量再计算指令。

26.按照权利要求15-25任意之一所述的方法，其中计算平台和搜索平台构成旅行预订系统，其中

-计算平台能访问关于旅行可用性和票价的信息，并根据旅行可用性信息和票价，计算附有价格的旅行推荐；

-搜索平台保持响应批量再计算指令，计算和接收自计算平台的预先计算的附有价格的旅行推荐，并响应查询而把预先计算的附有价格的旅行推荐返回给客户端，返回的预先计算的附有价格的旅行推荐满足包含在查询中的优先选择。

27.按照权利要求26所述的方法，还包括搜索平台

-根据从连接到搜索平台的客户端之一接收的搜索查询中的标准，从存储器检索多个预先计算的附有价格的旅行推荐；

-按照至少一个类别，对检索到的预先计算的附有价格的旅行推荐分类；

-对每个类别内的检索到的预先计算的附有价格的旅行推荐排序；和

-提供每个类别的排序后的检索到的预先计算的附有价格的旅行推荐至少之一，以便显示给客户端。

28.按照权利要求27所述的方法，其中类别是每个预先计算的附有价格的旅行推荐的耗用时间，每个预先计算的附有价格的旅行推荐的受欢迎度，与每个预先计算的附有价格的旅行推荐相关的专属提议的存在，每个预先计算的附有价格的旅行推荐的费用，每个预先计算的附有价格的旅行推荐最近被预订的时间，或者与每个预先计算的附有价格的旅行推荐相关的赞助中的至少一个。

29.一种保存有计算机程序指令的非临时性计算机可读存储介质，当在计算机系统上执行时，所述计算机程序指令实现按照权利要求1-7任意之一所述的计算平台和搜索平台的结构。

30.一种保存有计算机程序指令的非临时性计算机可读存储介质，当在计算机系统上执行时，所述计算机程序指令实现按照权利要求8-14任意之一所述的计算平台、搜索平台和再计算触发平台的结构。