CN103370710A - 根据规则属性提供票价检测的方法、系统及计算机程序 - Google Patents

Abstract

在本发明的一个方面，示例性的实施例提供了一种数据处理系统，包括：至少一个数据处理器；与数据处理器连接的并且存储可由该至少一个数据处理器执行的计算机软件的至少一个存储器；存储多个票价的以及用于建立能够在其下应用至少一个票价的条件的规则的至少一个数据库；以及到至少一个用户的且被配置用于接收来自用户的票价查询的接口。数据处理器以计算机软件来配置以促使数据处理系统接收含有至少一个规则属性的票价查询，执行第一搜索以确定可应用于该至少一个规则属性的规则数据，以及使用规则数据来执行第二搜索以检索出可应用于规则数据的票价列表。

Description

根据规则属性提供票价检测的方法、系统及计算机程序

技术领域

本发明的示例性实施例一般地涉及计算机化的预定系统及方法，例如，用于进行航空预定的系统及方法，并且更具体地，涉及用于检测及检索票价的技术。

背景技术

下列缩略语被定义如下：

下列术语被定义如下：

票价（Fare）    给出从给定的出发地到目的地的行程的价格的信息集。票价同样可以称为票价实体（Fare Entity）。

票价关键字（Fare Key）    票价的识别字段。

规则（Rule）    票价可以应用的条件集。规则同样可以称为规则实体。

记录1（Record1）    票价应用（Fare Application）实体：用于补充票价以及描述票价的利用准则的数据集（例如，票价有效的星期几或季节）。一个给定的记录1可以对应m个票价，该m个票价每个都继承在记录1中定义的利用准则。

记录2（Record2）    规则类别（季节性、最短停留等）

记录3（Record3）    规则规定：由规则类别使用的数据/值（例如，对于季节性规则类别，规则规定可以是“夏季”）。

票价记录1（FareRec1）    具有附加的记录1信息的票价

票价报价（fare quotation）的目的是给用户提供某些路线的价目表。这样的价目表是基于票价及以上所定义的规则实体来计算出的。

如图1所示，标准的票价报价提供使用输入数据实现的信息显示环境。这些输入数据能够进行如下分类：

在票价报价中用作搜索准则的以及用来初始化过程的路线输入数据（或路线属性）（例如：出发地（Origin）、目的地（Destination）、出行日期（Travel Dates）等）；以及

在票价报价过程中用作过滤准则的限制性输入数据（或限制性属性）。限制性属性能够链接至旅客（例如，年龄、企业等）和/或链接至正发送请求的销售点。

目前，在航空业中，票价报价过程/系统首先检索票价，然后应用规则以便执行票价报价。规则的应用允许系统过滤检索到的票价。规则的应用能够分解成三个主要步骤。

第一步骤涉及票价应用的检索以及执行在票价与相应的票价应用之间的合并操作。票价应用（也称为记录1）是用于补充票价以及描述票价的利用准则的数据集（例如，票价有效的星期几或季节）。一个给定的记录1可以对应m个票价，该m个票价每个都继承在记录1中定义的利用准则。因此，记录1含有已经进行因素分解（factorize）的票价数据，并且票价在没有其相应的记录1的情况下不能存在。

第二步骤涉及规则类别的应用（也称为记录2）。规则类别能够是，例如，季节性、最短停留等。

第三步骤涉及规则规定的应用（也称为记录3）。规则规定是由规则类别使用的数据/值（例如，对于季节性规则类别，规则规定可以是>夏季=）。

规则类别和规则规定是取决于定价背景的应用规则，然而无论是什么背景，票价应用都是有效的。例如，假定票价Y按照其票价应用每周七天都是有效的。如果该票价的报价在夏季进行，则规则类别及关联的规则规定将会将其使用限制为只是周末。

在某些条件下，票价应用于其票价应用的限制区域上。结果，某些常见的概念能够出现于票价应用和规则类别/规定两者中。

图2示出了常规的票价报价和票价报价引擎的主要步骤/要素。从路线属性开始，票价被检索以获得票价。然后，票价应用被检索并且与检索到的票价合并。然后，规则类别被应用，随后是规则规定的应用（考虑了限制性属性）。最终结果是所期望票价的输出。

目前，问题存在于：航空公司没有看到由规则的提交或者规则的更新造成的对定价的影响。例如，假定航空公司想要制定对欧洲内的所有旅行都有效的促销计划。航空公司在规则中提交折扣，但是没有办法检查该折扣是否在欧洲的所有市场中都有效。

而且，OLTA不可能去查看具有给定的规则特征的票价的全局视图。例如，在规则中可以限定被授权销售某些票价的售卖商。但是，如果没有传达这些授权，则售卖商可能不会注意到（从而忽略）他们被允许销售这些票价的事实。

发明内容

根据本发明的实施例，上述及其他问题得到了克服，并且实现了其他优点。

在本发明的第一方面，示例性的实施例提供一种用于检索至少一个票价的计算机实现的方法。该方法包括：接收含有至少一个规则属性的票价查询；执行第一搜索以确定可应用于该至少一个规则属性的规则数据；并且使用规则数据来执行第二搜索以检索出可应用于规则数据的票价列表。

在本发明的另一个方面，示例性实施例提供一种数据处理系统，包括：至少一个数据处理器；与数据处理器连接的并且用于存储可由至少一个数据处理器执行的计算机软件的至少一个存储器；至少一个数据库，用于存储多个票价，以及用于建立能够在其下应用至少一个票价的条件以及到至少一个用户的且被配置用于接收来自用户的票价查询的接口的规则。数据处理器以计算机软件来配置以促使数据处理系统接收含有至少一个规则属性的票价查询，执行第一搜索以确定可应用于该至少一个规则属性的规则数据，以及使用规则数据来执行第二搜索以检索出可应用于规则数据的票价列表。

附图说明

当结合附图来阅读时，本发明的实施例的上述及其他方面在下面的具体实施方式部分中将变得更明显，在附图中：

图1示出了标准的票价报价的输入和输出。

图2示出了由票价报价引擎执行的标准的票价报价的主要步骤。

图3示出了规则层次和规则的组织。

图4示出了根据规则属性的票价检测的输入和输出。

图5是示出根据本发明的示例性实施例的计算机执行的过程的逻辑流程图。

图6是根据规则属性的票价检测的技术实现方式的整体视图。

图7示出了数据扫描加速器的原理。

图8示出了规则类别35的实例。

图9是用于规则类别35的加速器的实例。

图10是示出EDIT子过程的启动的示意图。

图11是示出数据收集前期（PRE DATA COLLECTION）子过程的启动的示意图。

图12A示出了阈值的实例。

图12B是示出N个数据收集子过程的启动的示意图，其中图12A的阈值被示为任务管理器的输入。

图13示出了单独的数据域的实例。

图14是示出合并子过程的启动的示意图。

图15是示出适用于实现本发明的示例性实施例的各种构件的简化的系统层框图。

具体实施方式

本发明的示例性实施例提供了在没有任何路线信息的情况下根据规则属性来检索出基础票价的能力，并从而克服以上所讨论的问题。

以介绍的方式，图3示出了规则的一个示例性组织。在该表示中示出了规则层次，其中某些规则具有某些相关的类别。对于类别X的情形，能够有具有关联的字符串（Strings）的规则序列（RuleSequences），该字符串具有进而能够被表示为序列（Sequence）的规定（Provisions）。

与图1和2所示的常规的标准的票价报价相反，本发明的实施例在数据库环境中没有PNR信息的情况下使用规则方法。

示例性实施例的使用允许应用（计算机实现的应用）提供受一个规则属性（或其组合）影响的票价的显示。示例性实施例因而提供一种至少部分基于预定的规则及相关的规则属性来允许对至少一个票价的识别和/或检测和/或检索的计算机实现的系统及方法。

在操作中，并参照图4，应用的用户指定其感兴趣的规则属性10。用户还可以提供一个或多个附加的过滤器12，用于限制待获得的视图。附加的过滤器12能够是，例如：其中用户想要使票价显现的市场（默认情况下，所有市场都能够考虑）；票价的发布载体（默认情况下，来自所有载体的票价都能够考虑）；用于考虑何处的数据来源（例如，仅来自Amadeus的数据）（默认情况下，来自任何来源的数据都考虑）；以及在检索数据时要考虑的有效期（默认情况下，有效期能够是[当前日期B无限期]）。

规则属性10（搜索准则和过滤准则）以及附加的（其他）过滤器12由规则属性过程/引擎14输入票价检测，该规则属性过程/引擎14作为响应输出所期望的票价16。

本发明的示例性实施例可应用于众多技术领域，并且通过提供检查提交的逻辑以及数据如何在市场上传播的能力能够用作例如用于航空公司和OLTA两者的审计工具。实施例因而能够被看作是在本发明的一个方面提供互补的提交工具，用来简化及优化提交。对于OLTA，示例性的实施例还能够用于具有给定的规则特征的票价的类别。

通过本发明的示例性实施例的使用识别的票价列表16展示出了众多有价值的特征。这些特征包括，例如，价格相干性，因为标准的票价报价的应用逻辑应当遵守；所保证的有效性，因为该过程保证指定的规则属性将不会使所产生的基础票价无效；以及穷尽性，因为匹配给定的规则属性的基础票价的详尽列表被提供。此外，票价列表16能够依据资源使用量以最优的成本来提供，并且还能够提供因动态并行处理的使用（将在下文详细描述）所致的可控的处理时间。

示例性的实施例解决了众多复杂度相关的问题。例如，由于通常大量的数据待处理，因而能够出现性能问题，至少从处理时间和资源使用量来说。

例如，一种已知类型的生产数据库除了别的数据以外还含有超过2亿个票价、300万个规则类别以及50种不同类型的3亿个规则规定。另外，对于定价相干的结果还需要考虑标准的票价报价的应用逻辑。

解决这些问题的其他方法也可以尝试，例如，通过使用票价引擎或者数据仓库。但是，由于可能性的数量，执行定价事务并不保证是穷尽的。此外，重要的是了解所有市场。在仅获得几个样本的情形中，结果是不可靠的。但是，如果许多样本被获得以便是穷尽的，则需要大量的处理，这是耗时的且昂贵的。至少由于必须应用的标准的票价报价的应用逻辑，因而数据仓库方法并不是足够的。

示例性的实施例能够被用作例如审计工具。例如，假定航空公司（载体）提交将要应用于欧洲内的所有旅行上的促销。在输入中提供下列信息：规则属性：促销（折扣），以及附加的过滤器：地理位置（Geography）=欧洲且载体=航空公司名称。本发明的使用在输出中提供在欧洲的获益于该促销的航空公司（载体）的基础票价的列表。航空公司因而能够检查并验证该促销在欧洲的所有市场上都得到了良好推荐，并且从而使他们的提交生效。

另一个实例涉及用来获得票价的类别。假定特定的OLTA办事处（office）想要了解他们被授权在全球范围内销售的所有票价。下列信息能够作为输入来提供：规则属性：售卖商=OLTA办事处标识符，且附加的过滤器：无。在这种情况下，输出是授权给OLTA办事处的全球范围的基础票价的列表。以此方式，OLTA办事处可获得办事处被授权在全球范围销售的票价的类别。

现在将参照至少图5-14来更详细地描述示例性的实施例。

图5给出了本发明的示例性实施例的实现方式的整体功能视图。该过程以处于两个不同层面（宏观层面和数据层面）的两个主要步骤来执行。第一步骤20是关系搜索步骤。在关系搜索步骤20中，匹配给定的规则属性10的规则规定被检索（22）并被扫描。该过程一直操作到票价关键字。在24处，规则类别基于附加的过滤器12来检索，而在26处，该过程由规则驱使来检索票价28。第一步骤（关系搜索步骤20）的目标是检索出合格的票价28。

第二步骤30处于数据层面（数据应用-过滤步骤），其中标准的票价报价的应用逻辑被应用。在该步骤中，将检索到的票价应用与票价28合并（32），在34处应用检索到的规则类别24，根据规则属性（过滤准则）10在36处应用规则规定以得到最终的票价列表16。该第二步骤30的目标是检查所识别的合格票价28不会由在输入中给定的规则属性10置为无效。有利的是执行在这两个步骤20和30中执行该过程，因为需要了解票价以便保证它们不会被规则属性置为无效。

以上所描述的功能原理说明票价根据位于规则内的属性来识别。但是，从规则属性开始到得到票价会在至少处理时间和存储器空间使用方面会引起与待由应用处理的数据量相关的问题以及相关的性能问题。这些问题在常规的票价报价系统中不会出现，因为规则属性被用作过滤准则，而不是用作搜索准则。

因而，一种示例性的实现方式被提供用于处理与在具有大量数据的数据库环境中的根据规则属性的票价检测相关的这些及其他问题。

在该示例性的实现方式中，如图6所示，根据规则属性的票价检测过程被划分成四个子过程，具体为编辑子过程40、前期数据收集子过程50、数据收集子过程60及合并子过程70。现在将依次简要地描述这些子过程。

编辑40：在该子过程中，所有的规则都以选定的属性来收集并且存储于工作文件42内。这涉及根据基于多个子数据库（或者简单的数据存储）44A-44C的内容（分别地，记录2-规则类别、加速器，以及记录3-规则规定）的限制性属性来检索（44）规则。编辑子过程40采用基于在规则与数据之间的交叉引用表的数据扫描加速器。

数据收集前期50：对于在工作文件42中的每个先前识别的规则，规则针对输入数据（附加的过滤器12）来过滤（52）。结果是规则集成数据表54。

数据收集60：对于每个先前识别的规则，检索票价62。正是在此时标准的票价报价的应用逻辑被应用。该子过程优选地采用与中间的数据检索和数据缓存结合的动态并行处理。数据收集子过程60使用多个子数据库（或简单的数据存储）64A-64C（分别为票价，记录1-票价应用实体，以及记录3-规则规定）。在66处，存在将票价与记录1合并的操作；在68A处，存在票价与规则属性10及记录3（规则规定）匹配的操作；而在68B处，存在创建被作为票价列表68C来输出的票价列表的操作。

注意，这些过程与多个同时执行的数据收集子过程60并行地执行，并且因而存在多个票价列表68C，数据收集子过程60的每次执行就输出一个。

合并70：在该子过程中，该多个票价列表68C在72处合并，并且最终输出是票价16（参见图4）。

现在将更详细地描述以上四个子过程40-70。

子过程1-编辑40。编辑子过程收集所有规则数据并将它们存储于工作文件42内。规则数据的检索能够使用数据扫描加速器（在下文描述）来执行。

步骤1：从限制性属性10中检索规则。基于该输入，获得了关于记录2的序列和数据以及记录3的数据（对应于给定的规则属性）的列表。这些数据在本步骤期间检索以避免多次数据库访问。它们然后被存储于在随后的步骤中使用的工作文件42内。

子过程2B数据收集前期50：数据收集前期子过程操作，使得，对于一个先前识别的规则，该规则针对输入数据来过滤。然后，剩余的规则（在过滤之后）被存储于数据库54内。子过程2从而执行步骤2，按照附加的过滤器12来过滤规则并且去除不适用的规则。

子过程3B数据收集60：数据收集过程操作，使得，对于一个先前识别的规则，从票价数据库64A中检索出票价。优选地，使该子过程并行化以便优化处理时间。并行化，以及在该子过程中使用的中间的数据检索和存储器缓存，将在下文更详细地描述。该子过程执行下列步骤（并行地）：

步骤3（根据规则来检索票价）从一个记录2的序列中检索相应的票价关键字的列表。附加的过滤器同样可以应用于此。

步骤4（将票价与记录1合并）对于每个剩余的票价关键字，检索出票价（数据库64A）以及关联的记录1的数据（数据库64B），并且合并匹配的序列。所产生的实体称为票价记录1。

步骤5（票价匹配）获得每个合并的票价记录1并且将其与来自数据库64C的记录2及记录3的数据（对应于给定的规则属性10）匹配。该子过程然后检索记录2的数据并且将每个票价记录1的序列与记录2的序列匹配。如果首先匹配的记录2的序列之前已经在编辑及数据收集前期子过程40和50中被识别，则票价记录1被保留。

然后，该子过程检索出与记录2对应的记录3的数据并且将记录3的数据与在输入中给定的票价记录1及规则属性匹配。如果该数据匹配，则票价记录1被保留。如果所有控制都有效，则所保留的票价记录1被存储于输出列表内。

步骤6（创建票价列表）创建含有已经由过程验证的票价的票价列表68C。

子过程4B合并70：合并子过程收集由N个数据收集过程生成的所有票价列表68C并且执行通过拣选和去除任何重复项来合并所有提供的票价列表68C的步骤7（合并票价列表）。

关于待处理的数据量（被扫描以从限制性属性中检索出规则规定），前面所提及的性能问题通过使用在数据被集成于数据库内时动态创建的数据扫描加速器来处理和解决。附加的性能问题与检索到的规则规定相关，这些规则规定具有尺寸可变的（且不可预见的）数据量。此外，一个检索到的规则规定能够导致可变的票价量（从几个到可能数百万个票价）。这个问题通过使用存在于数据收集子过程60内的并行处理，以及通过使用中间的数据检索和数据缓存来处理和解决，其中该N个数据收集过程每个都工作（同时地）于单独的数据域上。也就是，本发明的示例性实施例的一个方面是：该N个数据收集过程操作于不相交的数据集（域）上，这避免了在相同的数据上执行冗余的操作。

处理时间和处理资源使用是可控的，有可能在两个方面之间获得平衡。因而，待处理的数据量对总体执行影响有限。

现在将参照图7对数据扫描加速器原理进行更详细的描述。规则（如同图3中的）被组织成树形结构。在本发明的范围内，树叶作为输入（即，规则属性）来提供，并且有必要从树叶到树根（即，到规则本身）遍历该树。操作包括：用于获得函数索引82和规则84的扫描80，以及包括与函数索引82和规则84的同步操作以及写操作的更新86。

票价报价过程（由ATPCO定义）的固有复杂度防止有人由于应用逻辑（例如，几种属性的可结合性）的引入而使用简单的索引技术（例如，关系数据库索引）。根据本发明的示例性实施例的方法使这样的能力能够不脱离现有票价报价系统的设计。示例性的实施例采用插入在规则专用的属性集上创建的附加的复杂的函数索引，由此使系统能够容易且高效地检索出相关的规则。这些索引含有充当预检查的预先计算的结果的某些部分。例如，通过该索引从属性中检索到的规则是接下来要经过数据应用过程（图6中的步骤2）的潜在规则。而且，能够事前知道通过该索引从属性中检索不到的规则，从而不能传递给步骤2的数据应用过程。

在优选的实施例中，每个属性集都有一个索引（也称为函数索引82）。由于规则规定按类别来组织，因而可考虑给作为在本文所描述的过程中的搜索准则的且属于同一类别的属性集创建新索引。

使用该子过程的一个优点是：作为必须扫描规则层次树的全部叶子，并然后遍历整棵树以至规则的根部的替代，数据扫描加速器提供了在规则属性与规则之间的直接关联（由图6中的规则交叉引用表54表示）。

例如，票价只可以由某些特定的售卖商销售。这种类型的限制被编码于特定的规则类别中（"协议票价"B类别35（Cat35））。考虑将售卖商作为搜索准则，在对该安全性进行编码的混杂的字段上建立的索引允许从给定的售卖商中快速地检索规则。

基于他们的标识类型，售卖商能够按多种方式来分类。售卖商分类的某些非限制性的实例包括：

按地理位置（基于销售点的地理位置的安全性）；

按IATA标识（基于由IATA标准化的标识的安全性）；以及

按GDS所有权标识（基于由GDS管理的标识的安全性）。

这种多形性（polymorphism）的一个结果能够是复杂的解码阶段以便使给定的售卖商标识与按类别存储的数据匹配。

图8示出了规则类别35的一个实例。在该非限制性的实例中，规则类别35“AF/528/DZ25”含有3个安全表：

在安全表#1中，使用IATA标识（IATA编号08491275）；

在安全表#2中，连同售卖商代码0AF100一起使用地理参数（城市巴黎B C PAR B）。这对应于特定的所有权售卖商标识（在本例中，售卖商Amadeus S.A.S.的办事处为Id 1A 0FRPAR100）；以及

在安全表#3中，使用两个地理参数（国家比利时B N BE B和城市Nice B C NCE B）。

应当能够意识到，标准的数据库索引机制在本例中并不是很有效率，因为需要索引许多字段，从而消耗了存储空间并且引入了更新期间的开销。

由于匹配并不是直接的，而是复杂的，因而根据示例性的实施例的系统不会尝试从给定的售卖商中检索出所有匹配数据。相反，含有适用于待执行的期望搜索的解码格式的索引被构造。这些索引允许直接匹配，并且因此更加有效率。而且，为了避免必须处理大量数据，能够为每个售卖商构造单独的索引，并且当对单个售卖商执行搜索时，能够只使用相关的索引。

图9是用于图8所示的规则类别35的加速器的非限制性实例。对于每个索引条目（图中示出了四个），所有需要的数据都被存储（在此为规则的标识）。

使用这种方法的优点有几个。例如，在搜索期间不需要解码，相反只需要执行直接的匹配；有可能使用标准的数据库索引机制；有可能将数据量分解成几个索引；进一步的导航通过存储所有与每个索引条目关联的必要数据来避免。

现在描述的是在图6所示的数据收集子过程60的并行处理背后的原理。如同以上所解释的，处理代表检索到的规则规定的数据量（使用以上所述的数据扫描加速器来进行）能够是一个重要的考虑因素。因此，总的处理时间直接取决于数据量。只要数据量是低的，处理时间就能够是可接受的（例如，几分钟）。但是当数据量增加时，处理时间能够延长到大于几分钟，这通常是不可接受的。确实是这样，有几方面的原因。例如，该过程在生产数据上工作，该生产数据很可能在过程运行时改变。再如，在请求报告时，用户通常想要尽可能快地接收到报告。

为了减少处理时间，一旦规则规定被检索到，就进行并行化。这些规则规定存储于逻辑表（logistic table）55内（示于图11中），该逻辑表55使每个数据与指示其处理进度的状态关联。因而，所有并行工作的实例不会在相同的数据上多次工作。相反，并且取决于图12A所示的某些预定的阈值55A，过程被分成将逻辑表55内的数据当作输入的N个过程。

由于规则规定关键字被用来识别每个数据，并且由于每个票价和票价应用对应于一个且只有一个规则规定关键字，因而这保证了并行化的实例在域之间没有重叠的完全分离的数据域上工作。

现在于作为规则属性的售卖商（Cat35）以及图6的四个子过程40-70的背景下提供一个实例。

参照图10，任务管理器90处理不同子过程（编辑40、数据收集前期50、数据收集60及合并70）的启动及依赖关系。

图10示出了子过程1（编辑40）经由任务管理器90的启动。基于在上述实例中提供的规则类别35的加速器（图9），所有规则（记录2的Cat35的列表）被获得并被存储于工作文件内（规则42）。任务管理器90然后从编辑子过程40处重新取得控制权。

图11示出了子过程2（数据收集前期50）经由任务管理器90的启动。存储于工作文件内的记录2的Cat35的列表（规则42）被处理成第一表格（规则集成数据表54）。在该步骤中，可以应用某些附加的过滤器12。插入规则集成数据表54内的规则的数量被存储于专用的逻辑表55内。在本实例中，假定所插入规则的数量NB_INSERTED_RULES=3751。任务管理器90然后从数据收集前期子过程40处重新取得控制权。

该过程的下一个步骤是确定待并行启动的数据收集过程的数量（即，确定N的值），随后是由任务管理器90启动数据收集子过程60的N个数据收集过程3。

任务管理器90考虑了存储于逻辑表55内的信息并且将所插入规则的数量与用于确定待启动的数据收集子过程的数量的某些阈值比较。图12A示出了阈值（NB_INSERTED_RULES，NB_插入_规则）对比待启动的数据收集过程的数量（NB_DATA_COLLECTION，NB_数据_收集）的实例。例如，如果NB_INSERTED_RULES=1050，则N的值被设定为2，而对于NB_INSERTED_RULES=2500的情形，N的值被设定为3。在如此所考虑的实例中，考虑到NB_INSERTED_RULES=3751，任务管理器90启动三个数据收集过程。

图12B示出了子过程3（数据收集60）经由任务管理器90的启动。每个启动的数据收集过程从规则集成数据表54中获取数据并且保留它所处理的记录2的Cat35。通过这样做，其他数据收集过程不考虑这些规则并从而在单独的数据域上工作。由此，通过经由记录2来确定待处理的数据域，能够保证每个数据收集过程都将在不同的记录1、票价等上操作，如图13所示。

每个数据收集子过程都将其输出提供为已经由该过程验证的票价的列表68C。任务管理器90然后从N个数据收集过程60处重新获得控制权。

图14示出了子过程4（合并70）经由任务管理器90的启动。由N个数据收集过程生成的N个票价列表68C被合并成最终的票价列表16。在本例中，三个票价列表68C被合并成最终的票价列表16。如同以上所指出的，合并子过程70涉及拣选并去除重复项。任务管理器90然后从合并子过程70处重新获得控制权并且最终的票价列表16能够被存储和/或被发送给用户。

一般地，在子过程40-70的执行过程中所需的所有数据（例如，票价应用、票价、诸如地理位置性质等其他数据）仅在必要时被检索并且然后被放置于数据缓存内。因而，对规则规定关键字、票价关键字及票价应用关键字使用适当的循环，检索被进行因素分解并且是可重用的。由于数据库访问在处理时间方面来说是高成本的，因而减少对数据库的调用次数会提高过程的处理速度。而且，能够防止多重的及不必要的数据检索，这些数据检索能够导致不必要的存储器使用。

显著的性能增益能够通过使用以上所述的根据规则属性的票价检测过程来实现。该性能提高能够通过使用典型使用案例的非限制性实例来说明。

使用案例：提供某个售卖商的A办事处可以在欧洲/美国-加拿大市场上销售的全部票价。对于待处理的数据的初始域，假定有40,000,000个票价、400,000个规则以及50,000,000个规则规定。

通过采用以上所描述的根据规则属性的票价检测过程，可发现其性能为在2分钟内处理1,500个规则以及在30分钟内处理15,000个票价，四个数据收集过程60并行运行（N=4）。相比之下，如果全部票价都直接使用同一硬件平台来处理，则该处理将需要数天来完成。

与常规的票价报价过程相反，根据规则属性的票价检测过程这样来完成：从位于规则内的属性开始到提供票价列表，确保了在列表内的票价不会有指定的规则属性置为无效。根据规则属性的票价检测过程还在能够处理大量数据的数据库的背景下提供了定价导向的功能。但是，尽管是大量的数据，也可使用以上所述的某些技术加速方法来处理性能问题（至少在处理时间和存储器使用方面）。

示例性的实施例能够结合众多有价值的应用及工具（包括但不限于：监测、审计及统计学评价），并且能够形成它们的基础。

参照用于示出适用于实现本发明的示例性实施例的各种构件的简化的系统层框图的图15。在图15中，计算机系统100包括到网络104（例如，因特网）的入口（服务器、网络接口）106，由此用户102能够经由各自的用户终端（例如，个人计算机）进行票价查询。与入口106连接/耦接的是具有用于存储数据和软件（SW）112的关联的存储器110的至少一个数据处理器108。SW112含有在由数据处理器108执行时会产生以上关于图5-14所描述的方法和过程的性能的程序指令。以上所讨论的各种数据缓存、表、阈值、临时存储等能够在存储器110中实现。此外，与该至少一个数据处理器108连接的是含有如同以上讨论的那样来处理的票价相关的及规则相关的数据的票价数据库114和规则数据库116。注意，一个或多个数据库114、116可以定位于远程并且通过网络104和/或通过一个或多个其他网络来访问。还要注意，在某些实现方式中，可以存在用于存储票价和规则数据两者的数据库。假定给适合的数据库管理器赋以：以数据来填充数据库，在需要时修改数据，以及搜索数据库。

数据处理器108可以用在数据收集子过程60的执行过程中能够并行执行的多个处理单元来实现。这些处理单元可以被实现为实体处理单元或者虚拟处理单元（虚拟机）。假定处理单元处于任务管理器90的控制之下，该任务管理器90可以由SW112的一个或多个模块来实现。

一般地，系统100使用一个或多个适合的计算机硬件/软件平台来实现，并且能够被实现为含有一个或多个数据处理器以及用于存储计算机软件和数据的关联存储器的服务器。系统100可以与例如处理旅行查询以及对客运航空公司的预定的特定组织（例如，GDS）关联。用户102可以表示为例如各个OLTA的个体办事处，如同以上所讨论的。用户102还可以与例如各个客运航空公司关联。

计算机系统100的准确的实现方式细节及构造可以采取许多适合的形式，并且不应当被看作是对有关本发明的示例性实施例的实现方式及实施的任何方面的限制。

以上描述已经通过示例性的非限制性实例提供了关于用于实现本发明的示例性实施例的各种方法、装置及计算机程序软件的全面详实的描述。但是，当结合附图和所附的权利要求书来阅读时，在考虑到以上描述的情况下，本领域技术人员可以清楚各种修改和适应。

而且，本发明的示例性实施例的某些特征可以在没有相应地使用其他特征的情况下作为优势来使用。由此，以上的描述应当被看作是仅对本发明的原理、教导和实施例的说明，而不是对它们的限制。

Claims (15)

1.一种用于检索至少一个票价的计算机实现的方法，其特征在于该方法包括：

接收用于指定至少一个规则属性的票价查询；

执行第一搜索以确定可应用于所述至少一个规则属性的规则数据；并且

使用所述规则数据来执行第二搜索以确定可应用于所述规则数据的票价列表，

其中所述第二搜索作为并行地执行的N个搜索过程来执行，并且其中所确定的票价列表是从所述N个搜索过程中的每个搜索过程输出的列表中获得的合并列表。

2.根据权利要求1所述的方法，其中N的值基于在所述第一搜索期间识别的规则的数量以及基于一组预定的阈值来确定，并且其中N是等于或大于1的整数。

3.根据权利要求1或2中的任一权利要求所述的方法，其中执行所述第一搜索包括：

执行用于根据限制性的规则属性来检索规则并获得关联的规则类别和规则规定的编辑子过程；以及

执行其中每个检索到的规则都被过滤以去除不适用的规则并且存储尚存的规则的数据收集前期子过程。

4.根据权利要求3所述的方法，其中执行所述第二搜索包括：

执行作为多个并行的数据收集子过程的数据收集子过程，以对于每个尚存的规则从票价数据库中检索出票价并生成多个票价列表；以及

将所述多个票价列表合并成最终的票价列表并且输出所述最终的票价列表，作为对所接收到的票价查询的响应。

5.根据权利要求4所述的方法，其中执行所述数据收集子过程包括，对于所述多个并行的数据收集子过程中的每一个：

从一个规则类别序列中检索出相应的票价关键字的列表；

对于每个票价关键字，检索票价及关联的票价应用实体，并且合并匹配规则类别序列以形成票价记录；

将每个票价记录与相应的规则类别以及与所述至少一个规则属性对应的规则规定数据匹配；

将每个票价记录序列与所述规则类别序列匹配，并且保留之前在所述第一搜索期间识别的那些票价记录；以及

检索与所述规则类别序列数据对应的规则规定数据，并且将所述规则类别序列数据与所述票价记录及规则属性匹配，并仅将发生匹配的那些票价记录存储于票价列表内，其中所述多个并行的数据收集子过程在不相交的数据域上操作以避免执行冗余的操作。

6.根据权利要求5所述的方法，其中合并所述多个票价列表包括：通过拣选并去除重复的票价记录来将由所述多个并行的数据收集子过程中的每个数据收集子过程输出的所述票价列表合并到所述最终的票价列表中。

7.根据权利要求1至6中的任一权利要求所述的方法，其中执行用于所述确定所述规则数据的第一搜索包括使用代表所解码的规则专用的数据的函数索引的直接匹配，并且使用数据扫描加速器来执行以提供在规则属性与规则之间的直接关联。

8.一种含有软件程序指令的非临时性的计算机可读介质，其中所述软件程序指令由至少一个数据处理器执行，导致包括权利要求1至7中的任一权利要求所述的方法的执行的操作的性能。

9.一种数据处理系统，包括：

至少一个数据处理器；

至少一个存储器，与所述数据处理器连接且存储可由所述至少一个数据处理器执行的计算机软件；

至少一个数据库，存储多个票价和用于建立能够在其下应用至少一个所述票价的条件的规则；以及

到至少一个用户且被配置用于接收来自所述用户的票价查询的接口；

其特征在于所述数据处理器以所述计算机软件来配置以促使所述数据处理系统接收含有至少一个规则属性的票价查询、执行第一搜索以确定可应用于所述至少一个规则属性的规则数据、以及使用所述规则数据执行第二搜索以检索出可应用于所述规则数据的票价列表，

并且所述数据处理器以所述计算机软件来进一步配置以促使所述数据处理系统执行作为并行执行的N个搜索过程的所述第二搜索，并且其中所确定的票价列表是从由所述N个搜索过程中的每个搜索过程输出的列表中获得的合并列表。

10.根据权利要求9所述的数据处理系统，其中N的值基于在所述第一搜索期间识别的规则的数量以及基于一组预定的阈值来确定，并且其中N是等于或大于1的整数。

11.根据权利要求9或10中的任一权利要求所述的数据处理系统，其中所述数据处理器以所述计算机软件来进一步配置以促使所述数据处理系统通过以下操作来执行所述第一搜索：执行用于根据限制性的规则属性来检索规则并获得关联的规则类别和规则规定的编辑子过程，并且执行其中每个检索到的规则都被过滤以去除不适用的规则并且存储尚存的规则的数据收集前期子过程。

12.根据权利要求11所述的数据处理系统，其中所述数据处理器以所述计算机软件来进一步配置以促使所述数据处理系统通过以下操作来执行所述第二搜索：执行作为多个并行的数据收集子过程的数据收集子过程以对于每个尚存的规则从票价数据库中检索出票价，并且通过将所述多个票价列表合并成最终的票价列表来生成多个票价列表并且输出所述最终的票价列表作为对所述接收到的票价查询的响应。

13.根据权利要求12所述的数据处理系统，其中所述数据处理器以所述计算机软件来进一步配置以促使所述数据处理系统对于所述多个并行的数据收集子过程中的每一个数据收集子过程通过以下操作来执行所述数据收集子过程：从一个规则类别序列中检索出相应的票价关键字的列表；对于每个票价关键字，检索票价及关联的票价应用实体，并且合并匹配规则类别序列以形成票价记录；将每个票价记录与相应的规则类别以及与所述至少一个规则属性对应的规则规定数据匹配；将每个票价记录序列与所述规则类别序列匹配并且保留之前在所述第一搜索期间识别的那些票价记录；以及检索与所述规则类别序列数据对应的规则规定数据并且将所述规则类别序列数据与所述票价记录及规则属性匹配并仅将发生匹配的那些票价记录存储于票价列表内，其中所述多个并行的数据收集子过程在不相交的数据域上操作以避免执行冗余的操作。

14.根据权利要求13所述的数据处理系统，其中所述数据处理器以所述计算机软件来进一步配置以促使所述数据处理系统执行所述多个票价列表的合并包括：通过拣选并去除重复的票价记录将由所述多个并行的数据收集子过程中的每个数据收集子过程输出的所述票价列表合并到所述最终的票价列表中。

15.根据权利要求9至14中的任一权利要求所述的数据处理系统，其中所述数据处理器以所述计算机软件来进一步配置以促使所述数据处理系统通过以下操作来执行所述用于确定所述规则数据的第一搜索：使用数据扫描加速器使用代表所解码的规则专用的数据的函数索引的直接匹配来提供在规则属性与规则之间的直接关联。

Images