特許 5997269 データベースを修正するためにデータを処理するための方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5997269

(24)【登録日】2016年9月2日

(45)【発行日】2016年9月28日

(54)【発明の名称】データベースを修正するためにデータを処理するための方法およびシステム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20160915BHJP

   G06F 17/30 20060101ALI20160915BHJP

   G06F 9/48 20060101ALI20160915BHJP

   G06F 12/00 20060101ALI20160915BHJP

【ＦＩ】

   G06F9/46 462A

   G06F17/30 240A

   G06F9/46 452F

   G06F12/00 511C

【請求項の数】24

【全頁数】18

(21)【出願番号】特願2014-517643(P2014-517643)

(86)(22)【出願日】2012年6月26日

(65)【公表番号】特表2015-501456(P2015-501456A)

(43)【公表日】2015年1月15日

(86)【国際出願番号】EP2012062295

(87)【国際公開番号】WO2013000883

(87)【国際公開日】20130103

【審査請求日】2015年6月12日

(31)【優先権主張番号】11305822.6

(32)【優先日】2011年6月28日

(33)【優先権主張国】EP

(31)【優先権主張番号】13/178,957

(32)【優先日】2011年7月8日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】509228994

【氏名又は名称】アマデウス エス．アー．エス．

【氏名又は名称原語表記】ＡＭＡＤＥＵＳ Ｓ．Ａ．Ｓ．

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100064908

【弁理士】

【氏名又は名称】志賀 正武

(74)【代理人】

【識別番号】100089037

【弁理士】

【氏名又は名称】渡邊 隆

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(72)【発明者】

【氏名】ルネ・ジュリアン

(72)【発明者】

【氏名】ヴァンサン・モロー

(72)【発明者】

【氏名】ミュリエル・ベッカー

【審査官】 大塚 俊範

(56)【参考文献】

【文献】 特開２００８−１２３２０５（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ ９／４８

Ｇ０６Ｆ １２／００

Ｇ０６Ｆ １７／３０

(57)【特許請求の範囲】

【請求項1】

データベースを修正するためにデータを処理するための方法であって、
データのセットを受信するステップと、
データの前記セットを変換されたデータに変換するために、複数の連続ジョブを備える処理チェーンを実行するステップと、
前記変換されたデータに関する生産データベースを修正するステップとを備え、
前記連続ジョブの前記実行の目標処理時間を設定するステップと、
第1のジョブに着手する前に、前記連続ジョブごとに並列化レベルを定義する現在の構成として元の構成を適用するステップと、
実際の残りの処理時間が許容できる残り処理時間の範囲外になると、適合された構成を、前記処理チェーン内に残っている前記ジョブごとに適合された並列化レベルを定義する新しい現在の構成として適用するステップとをさらに備え、前記適合された構成が前記現在の構成とは異なる、
方法。

【請求項2】

前記第1のジョブの後、全てのさらなるジョブに着手する前に、実際の残りの処理時間が許容できる残り処理時間の範囲外になると、適合された構成を、前記処理チェーン内に残っている前記ジョブごとに適合された並列化レベルを定義する新しい現在の構成として適用するステップを備え、前記適合された構成が前記現在の構成とは異なる、
請求項1に記載の方法。

【請求項3】

許容できる残り処理時間の前記範囲が、前記目標処理時間の決定された割合を下回る時間の範囲として定義される、請求項1または2に記載の方法。

【請求項4】

前記元の構成および前記適合された構成が、履歴データおよび制約データを備える情報に基づいて決定される、請求項1から3のいずれか一項に記載の方法。

【請求項5】

前記履歴データが、データの前記セットと同じタイプのデータのセットについての処理チェーンの以前の実行についての情報を備える、請求項4に記載の方法。

【請求項6】

データ量のいくつかの範囲について、ジョブごとに適用されるべき並列インスタンスの数を指定する少なくとも1つの構成定義を含む構成定義区分を備える構成表を作成するステップを備える、請求項5に記載の方法。

【請求項7】

前記実際の残りの処理時間が許容できる残り処理時間の前記範囲を下回ると、前記残りのジョブに適用されるべき並列インスタンスの前記数が、前記現在の構成の前記残りのジョブに適用されるべきインスタンスの数を上回る前記構成表の少なくとも1つの構成の中から前記適合された処理構成を選択するステップを備える、請求項6に記載の方法。

【請求項8】

前記実際の残りの処理時間が許容できる残り処理時間の前記範囲を上回ると、前記残りのジョブに適用されるべき並列インスタンスの前記数が、前記現在の構成の前記残りのジョブに適用されるべきインスタンスの数を下回る前記構成表の少なくとも1つの構成の中から前記適合された処理構成を選択するステップを備える、請求項6に記載の方法。

【請求項9】

少なくとも別のデータのセットを受信するステップと、
データの前記セットの前記処理チェーンの少なくとも1つの所与のジョブに従属する前記別のデータのセットの処理チェーンの少なくとも1つの従属ジョブを検出するステップと、
前記1つの所与のジョブの完了後、前記従属ジョブの着手をスケジューリングするステップと
を備える、請求項1から8のいずれか一項に記載の方法。

【請求項10】

それぞれが運賃定義の1つの構成要素を記述するデータエンティティを含むデータのセットを使用するステップを備える請求項1から9のいずれか一項に記載の方法。

【請求項11】

前記構成要素が、運賃および運賃ルールならびにルートの設定の中から選択される、請求項10に記載の方法。

【請求項12】

前記処理チェーンが、
データの前記セットを内部構造のフォーマットに変換されたデータのセットに変換する第1のジョブと、
前記変換されたデータのセットに基づいて、少なくとも1つの予備表を構築する第2のジョブと、
前記少なくとも1つの予備表に基づいて参照データベースを更新する第3のジョブと、
前記参照データベースの前記更新を生産データベースにロードする第4のジョブと
を備える、請求項10または11に記載の方法。

【請求項13】

前記第1のジョブが、データの前記セットを含むファイルを入力として使用することである、請求項12に記載の方法。

【請求項14】

前記第4のジョブが、たとえ全ての前記データエンティティについて前記第3のジョブが完了しなくても、前記第3のジョブが完了される少なくとも1つのデータエンティティについて着手される、請求項12または13に記載の方法。

【請求項15】

運賃定義の構成要素ごとにデータのセットを受信し、前記構成要素に対して並列処理チェーンを実行するステップを備える、請求項12から14のいずれか一項に記載の方法。

【請求項16】

少なくとも1つのデータプロセッサによってコンピュータソフトウェアを実行する結果として実行され、前記コンピュータソフトウェアが持続性コンピュータ可読メモリ媒体に格納されている、請求項1から15のいずれか一項に記載の方法。

【請求項17】

プロバイダシステムからデータの前記セットを送信するステップを備える、請求項1から16のいずれか一項に記載の方法。

【請求項18】

エンドユーザデバイスから検索エンジンを介して前記生産データベースのデータにアクセスするステップを備える、請求項1から17のいずれか一項に記載の方法。

【請求項19】

請求項1から18のいずれか一項に記載の方法を実行するように構成された手段を備える、データベースを修正するためにデータを処理するためのシステム。

【請求項20】

リソースアロケータを具備し、該リソースアロケータが、
前記連続ジョブを実行する目標処理時間を設定するための手段と、
第1のジョブに着手する前に、前記連続ジョブごとに並列化レベルを定義する現在の構成として元の構成を適用するための手段と、
実際の残りの処理時間が許容できる残り処理時間の範囲外になると、前記処理チェーン内に残っている前記ジョブごとに適合された並列化レベルを定義する新しい現在の構成として適合された構成を適用するための手段とを備え、前記適合された構成が前記現在の構成とは異なる、請求項19に記載のシステム。

【請求項21】

前記ジョブの前記着手をトリガするための手段を有するジョブスケジューラを備える、請求項20に記載のシステム。

【請求項22】

前記ジョブスケジューラが、少なくとも別のデータのセットを受信すると、データの前記セットの前記処理チェーンの少なくとも1つの所与のジョブに従属する前記別のデータのセットの処理チェーンの少なくとも1つの従属ジョブを検出するための手段と、前記1つの所与のジョブの完了後、前記従属ジョブの着手をスケジューリングするための手段とを備える、請求項21に記載のシステム。

【請求項23】

前記システムの一部である少なくとも1つのデータプロセッサによって実行される持続性コンピュータ可読メモリ媒体に格納されているコンピュータソフトウェアを備える、請求項22に記載のシステム。

【請求項24】

持続性コンピュータ可読メモリ媒体に格納されており、請求項1から18のいずれか一項に記載の方法を実行するように適合された命令を備える、コンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、特に大量で容量が可変であるデータが、変換されデータベースにロードされる必要がある場合のデータ処理の分野に関する。

【背景技術】

【0002】

データベースは、1970年代に導入されて広く採用され始めて以来、エンジニアリング、科学、商業、およびビジネスアプリケーションを含むあらゆる種類の分野で急増している。データベースのサイズは、たとえば個人資産を把握するためにパーソナルコンピュータ上で1人の個人によって使用される小規模なデータベースから、活動をサポートするために様々な団体、企業、および商業組織によって設定される大規模な、および非常に大規模なデータベースまでの範囲のいずれでもよい。全てが相互接続された世界では、必ずしもというわけではないが、一般的にそれらの大規模なデータベースも、多数の遠隔に配置されたエンドユーザがデータベースによって利用可能な何らかの情報を問い合わせるためにアクセスできるように作成される。

【0003】

航空業界では、このような非常に大規模なデータベースの例は、航空運賃に加えて、それらの使用を制限するルールを保持するデータベースである。運賃データベースは、従来の旅行代理店およびあらゆる種類の他のオンライン旅行サービスプロバイダを含む旅行業界の関係者に旅行サービスを提供する、いくつかの世界的なグローバル流通システム(GDS)によって主に設定される。それらの大規模なデータベースは、決して眠らない世界的なビジネスを維持するために、一般的に週に7日、24時間モードで操作可能でなければならず、多数の大規模な、およびより小規模な航空会社によって発表される新しい運賃を常に取得することも必要である。データベースに組み込まれるべき膨大な量の航空運賃データが毎日受信される。受信されるデータは、ファイル数、量(0から数百万のレコード)、および機能コンテンツ(運賃、ルール、ルートの設定…)の点で可変であり、予測不能なので、それらのデータはプロバイダによる同じ方法ではファイルされない。

【0004】

最近の傾向では、それぞれの送信の量と頻度との両方が増加している。たとえば、ATPCo(履歴運賃プロバイダであるAirline Tariff Publishing Companyの略)は、以前は1日に10回だったが、2010年には毎時送信を行ったと発表しており、これは以前の送信頻度の2倍以上である。

【0005】

通常、運賃定義は、運賃(運賃額を備える一般的データ)、ルール(運賃に適用できる基準を指定する)、およびルートの設定(典型的には、起点から終点への旅行が通過しうる中間都市の順序付きリスト)を含む、いくつかの構成要素で構成される。

【0006】

新しい運賃定義は、通常はプロバイダによってファイルの形式で提供され、新しい運賃(その時はデータベースに格納されている)が、例を挙げると、旅行のソリューションの情報を返す観点から、旅行者または旅行代理店などのエンドユーザの要求を処理するコンピュータ化された予約システムの一部である生産システムにとって利用可能になる書込み段階の前に、コンピュータシステムによって処理されることを必要とする。

【0007】

データベースにロードされるべき新しい運賃定義を処理するための現在の技法は、固定コンピュータリソースを含む。このようなリソースは、通常、旅行会社(典型的には航空会社)とコンピュータサービスプロバイダ(GDS等)との間のサービスレベル契約(SLA)で設定される最大処理時間をできるだけ頻繁に考慮するのに大きすぎるが、運賃ファイリングのピーク期間の場合には、SLAは履行すらされない。その時には警告が発せられ、即時の措置が必要となる。

【発明の概要】

【発明が解決しようとする課題】

【0008】

したがって、たとえ処理されるべきデータ量が大部分で異なっている場合でも、あらゆる状況におけるリソース消費を最適化するために、データベースにロードされるべきデータを処理するための改善された技法が必要である。

【0009】

本発明の実施形態によれば、上記および他の問題のうちの少なくともいくつかが克服され、他の利点が実現される。

【課題を解決するための手段】

【0010】

本発明の一態様では、例示的実施形態は、データのセットを受信するステップと、データのセットを変換されたデータに変換するために、複数の連続ジョブを備える処理チェーンを実行するステップと、変換されたデータに関する生産データベースを修正するステップとを備え、連続ジョブの実行の目標処理時間を設定するステップと、第1のジョブの後、少なくとも1つのさらなるジョブに着手する前に、連続ジョブごとに並列化レベルを定義する現在の構成として元の構成を適用するステップと、実際の残りの処理時間が許容できる残り処理時間の範囲外になると、処理チェーン内に残っているジョブごとに適合された並列化レベルを定義する新しい現在の構成として適合された構成を適用するステップとをさらに備え、前記適合された構成が現在の構成とは異なる、データベースを修正するためにデータを処理するための方法およびシステムを提供する。

【0011】

本発明の目的は、処理チェーンの余裕(leeway)を検出すると、必要な措置を取ることである。

【0012】

本発明の他の態様では、例示的実施形態は、本方法を実行するように構成された手段を備える、データベースを修正するためにデータを処理するためのシステムを提供する。他の態様では、例示的実施形態は、持続性（non-transitory）コンピュータ可読メモリ媒体に格納された、本方法を実行するように適合された命令を備えるコンピュータプログラム製品を提供する。

【0013】

次に、好ましい実施形態を例示する目的で、図面を参照して本発明を詳細に説明する。

【図面の簡単な説明】

【0014】

【図1】好ましい実施形態で本発明が実装されうる、コンピュータ化されたアーキテクチャを示す図である。

【図2】ジョブに着手し、ジョブにコンピュータリソースを割り当てるためのステップの一実施形態を示す図である。

【図3】本発明のいくつかの態様において処理されうる、処理フローの一実施形態を示す図である。

【図4】本発明のいくつかの実施形態において処理されうる、並列フローの概略図である。

【図5】ジョブの従属性が対処される、本発明の別の態様を示す図である。

【図6a】ジョブの並列化レベルの構成を定義するための好ましい実施形態を示す表である。

【図6b】ジョブの並列化レベルの構成を定義するための好ましい実施形態を示す表である。

【図6c】ジョブの並列化レベルの構成を定義するための好ましい実施形態を示す表である。

【図6d】ジョブの並列化レベルの構成を定義するための好ましい実施形態を示す表である。

【図6e】ジョブの並列化レベルの構成を定義するための好ましい実施形態を示す表である。

【図6f】ジョブの並列化レベルの構成を定義するための好ましい実施形態を示す表である。

【図6g】ジョブの並列化レベルの構成を定義するための好ましい実施形態を示す表である。

【図6h】ジョブの並列化レベルの構成を定義するための好ましい実施形態を示す表である。

【図6i】ジョブの並列化レベルの構成を定義するための好ましい実施形態を示す表である。

【発明を実施するための形態】

【0015】

本発明は、コンピュータハードウェアおよびソフトウェアの手段で実装されうる。本発明は、データの処理が行われるサーバサイドを含みうる。このサーバサイド(単一または複数のコンピュータデバイスで構成されうる)は、ネットワークリソースを介して、これらに限定されないが、管理者のデスクトップコンピュータ、および/またはデータプロバイダデバイス、ならびに/あるいは他の任意のユーザデバイスなどの、少なくとも1つの遠隔デバイスと通信することが好ましい。

【0016】

いくつかの用語の定義を以下に提供する:
- 本明細書では、「ジョブ」は、コンピュータ手段によって実行されるデータ処理のステップの少なくとも1つのグループを意味する。例示の目的で、ジョブは、フォーマット変換、構文チェック、ファイル抽出、およびファイルから抽出されたデータを備える表更新にあってもよく、それらを備えてもよい。
- 「データのセット」は、同じ処理チェーン内で処理されるべきデータエンティティの任意のグループでよい。運賃処理の場合、それぞれの運賃定義は、一般的に、これらに限定されないが、運賃、または運賃ルール、あるいはルートの設定などの、いくつかの構成要素(本明細書では、名前付きデータエンティティ)に分割される。運賃は、名前および金銭的価値を含む運賃定義の一般的データに対応する。運賃ルールは、一般的にレコード(レコード1、レコード2)と呼ばれ、それぞれの運賃ルールは、運賃に適用できるいくつかの基準(季節性、旅行者カテゴリ、特別サービス…)の仕様専用である。新しい運賃定義の全てのデータは、通常は単一のファイル内で提供されない。実際、いくつかの新しい運賃定義はしばしば同時に提供され、それらのデータは、それぞれがデータエンティティの1つのカテゴリまたは特定のカテゴリ専用(レコード1、またはレコード3、あるいは運賃などのカテゴリ)である複数のファイルに分散される。このような適用では、「データのセット」は、典型的には、複数の運賃定義について同時に受信された同じカテゴリのデータエンティティ(一般的には同じファイル内)のグループである。
- 本明細書では、「処理チェーン」は、所与のデータエンティティについて連続的に実行される複数のジョブを意味し、処理チェーンは通常複数のデータエンティティで構成されるデータのセットを含む。このような場合、ジョブは少なくとも1つのデータエンティティについて連続的であるが、ジョブは、少なくともいくつかのデータエンティティについて次のジョブを開始する前にデータのセットの全てのエンティティについて必ずしも完了される必要がない。
- 本明細書では、「持続性コンピュータ可読メモリ媒体」は、プログラム命令を格納するための任意の格納手段を意味し、ランダムアクセスメモリまたは読出し専用メモリ、あるいは同等物などの、あらゆる種類のメモリを含む。
- 本明細書では、「データベース」は、大量のデータを格納および取り出すように適合された任意のデータリポジトリを備える。本明細書では、「生産データベース」は、エンドユーザデバイスの検索要求に返答することを目的とする検索エンジンなどの生産設備によってアクセスできるように作成されたデータベースを意味する。

【0017】

以下で、好ましい実施形態による本発明の態様に対応するいくつかの特徴を紹介するが、後に詳細に説明する:
- 第1のジョブの後、全てのさらなるジョブに着手する前に、実際の残りの処理時間が許容できる残り処理時間の範囲外になると、処理チェーン内に残っているジョブごとに適合された並列化レベルを定義する新しい現在の構成として適合された構成を適用し、前記適合された構成は現在の構成とは異なる。
- 許容できる残り処理時間の範囲が、目標処理時間の決定された割合を下回るおよび/または上回る時間の範囲として定義されることが好ましい。
- 元の構成および適合された構成が、履歴データおよび制約データを備える情報に基づいて決定される。
- 履歴データは、データのセットと同じタイプのデータのセットについての処理チェーンの以前の実行についての情報を備える。
- 構成表を作成するステップが、データ量のいくつかの範囲について、ジョブごとに適用されるべき並列インスタンスの数を指定する少なくとも1つの構成定義を含む構成定義区分を備える。
- 実際の残りの処理時間が許容できる残り処理時間の範囲を下回ると、残りのジョブに適用されるべき並列インスタンスの数が、現在の構成の残りのジョブに適用されるべきインスタンスの数を上回る構成表の少なくとも1つの構成の中から適合された処理構成を選択する。
- 実際の残りの処理時間が許容できる残り処理時間の範囲を上回ると、残りのジョブに適用されるべき並列インスタンスの数が、現在の構成の残りのジョブに適用されるべきインスタンスの数を下回る構成表の少なくとも1つの構成の中から適合された処理構成を選択する。
- 本発明は、以下のステップを実行するステップを備える:
- 少なくとも1つの別のデータのセットを受信するステップ
- データのセットの処理チェーンの少なくとも1つの所与のジョブに従属する別のデータのセットの処理チェーンの少なくとも1つの従属ジョブを検出するステップ
- 1つの所与のジョブの完了後、従属ジョブの着手をスケジューリングするステップ
- それぞれが運賃定義の1つの構成要素を記述するデータエンティティを含むデータのセットを使用するステップ
- この構成要素は、運賃および運賃ルールならびにルートの設定の中から選択される。
- 処理チェーンは、以下を備える:
- データのセットを内部構造のフォーマットに変換されたデータのセットに変換する第1のジョブ
- 変換されたデータのセットに基づいて、少なくとも1つの予備表を構築する第2のジョブ
- 少なくとも1つの予備表に基づいて参照データベースを更新する第3のジョブ
- 参照データベースの更新を生産データベースにロードする第4のジョブ
- 第1のジョブは、データのセットを含むファイルを入力として使用する。
- 第4のジョブは、たとえ全てのデータエンティティについて第3のジョブが完了しなくても、第3のジョブが完了される少なくとも1つのデータエンティティについて着手される。
- 運賃定義の構成要素ごとにデータのセットを受信し、前記構成要素の並列処理チェーンを実行するステップ

【0018】

本方法は、少なくとも1つのデータプロセッサによってコンピュータソフトウェアを実行する結果として実行されることが好ましく、コンピュータソフトウェアは持続性コンピュータ可読メモリ媒体に格納されている。

【0019】

本発明は、プロバイダシステムからデータのセットを送信するステップを含むことができ、エンドユーザデバイスから検索エンジンを介して生産データベースのデータにアクセスするステップを備えることができる。

【0020】

システムは、連続ジョブを実行する目標処理時間を設定するための手段と、第1のジョブに着手する前に、連続ジョブごとに並列化レベルを定義する現在の構成として元の構成を適用するための手段と、実際の残りの処理時間が許容できる残り処理時間の範囲外になると、処理チェーン内に残っているジョブごとに適合された並列化レベルを定義する新しい現在の構成として適合された構成を適用するための手段とを備える、リソースアロケータを有利に含み、前記適合された構成が現在の構成とは異なる。

【0021】

いくつかの好ましいケースでは、本システムは、
- ジョブスケジューラがジョブの着手をトリガするための手段を有するようなシステムであり、
- ジョブスケジューラは、少なくとも別のデータのセットを受信すると、データのセットの処理チェーンの少なくとも1つの所与のジョブに従属する別のデータのセットの処理チェーンの少なくとも1つの従属ジョブを検出するための手段と、1つの所与のジョブの完了後、従属ジョブの着手をスケジューリングするための手段とを備え、
- コンピュータソフトウェアが、本システムの一部を備える少なくとも1つのデータプロセッサによって実行される持続性コンピュータ可読メモリ媒体に格納されている。

【0022】

本発明の一実施形態では、適合された構成の適用は、第1のジョブの後に少なくとも1つのさらなるジョブに着手する前にトリガされる。しかし、この適合は処理チェーンの間いつでも生じる可能性があることが好ましい。特に、並列化レベルは、ジョブの実行の間に適合された構成の適用を介して適合されうる。次いで、適合された構成は現在のジョブおよび次のジョブのリソースパラメータを修正する。この状況では、現在のジョブおよび次のジョブは残りのジョブで構成される。

【0023】

図1は、生産データベース1にアクセスする必要があるアーキテクチャを示している。旅行および観光業界への適用において(以下に記述する好ましい実施形態に対応する)、生産データベースは、これらに限定されないが、飛行機旅行区分、鉄道旅行区分、レンタカーサービス、ホテル客室予約、または前述の例に関連するサービスを含みうる少なくとも1つの旅行サービスで構成される、旅行の推薦についての運賃額および条件を決定するために使用される運賃データ等の旅行ソリューションデータを格納しうる。飛行機旅行に関する限り、典型的には、旅行はシステム(概して、GDSによって実装されうるコンピュータ化された予約システムの一部)によって決定され、運賃条件で旅行に価格を割り当てることができるように運賃見積もりがトリガされる。旅行ソリューション(または複数の旅行ソリューション)が要求者に返され、旅行ソリューションは旅行について提案される旅行区間の記述、ならびに価格額を備える。価格額は、旅行に運賃定義を適用することによって決定される。

【0024】

運賃定義はいくつかの区分を含み、以下では等しく構成要素または製品と呼ばれる:
- 主に旅行の価格を与える運賃区分
- 運賃定義に適用できるルールを提供するルール区分(ルール区分は、典型的には、上記で示されたようにレコードと名付けられるいくつかのサブ区分を備える。)

【0025】

再び図1を参照すると、生産データベース1はこのような運賃定義のリポジトリでよい。生産データベース1は、旅行代理店または顧客のコンピュータデバイス(スマートフォン、サーバ、またはパーソナルコンピュータなどの任意のタイプのデバイスを含む)などのエンドユーザデバイス5からの要求があると、検索エンジン2(運賃見積もりエンジンなど)によって、旅行要求処理フロー内で使用される。

【0026】

ユーザデバイス5、検索エンジン2、およびデータベース1の間の送信は、図1に示されるようにネットワーク3を介するなど、従来の技法を使用して処理されうる。点線は、データベース1および検索エンジン2が、よりグローバルな予約システム6の一部であってよいことを示している。また、図1は、データベース1に含まれるデータの管理のために、少なくとも1つのプロバイダシステム4が考慮に入れられるべきであることを示している。航空運賃は、非常に競争力の強い業界によって販売される、消耗製品に接続されることは先に説明した。

【0027】

本発明が、プロバイダのデータ修正に関連して、生産データベース1のコンテンツを修正するために、柔軟で効率的なソリューションを提供する方法をさらに説明する。データプロバイダシステム4によって送信されるデータ修正の全てまたはいくつかは、やはり予約システム6の一部であることが好ましく、任意の十分な通信手段を介してデータプロバイダシステム4と生産データベース1との間のインターフェースとして機能する、入力構成要素20によって処理されうる。

【0028】

構成要素20の入力データは、生産データベースが考慮に入れることをデータプロバイダシステム4が望む、新しいデータである。新しいデータは、全く新しい運賃定義、または既存の運賃定義の修正を含みうる。構成要素20で受信されたデータは、少なくとも1つのファイルの形式であることが好ましい。それぞれのファイルは少なくとも1つのデータのセットを含む。データのセットは、1つの運賃定義の1つの構成要素(または製品)を記述する少なくとも1つのデータエンティティを含む。プロバイダから空のファイルが受信されることもある。この場合、このタイプのデータの処理に関連する全てのジョブは、他のデータが有する可能性がある従属性をすぐに解消するために、「完了」に自動的に設定される。それぞれのデータプロバイダシステム4が、運賃定義の構成要素についての別々のファイルを送信して、それぞれのファイルが複数の(また、しばしば大量の)データエンティティ(すなわち、生産データベース1において修正または作成されるべき運賃定義につき1つのデータエンティティ)を含むことが好ましい。

【0029】

次に図2を参照すると、プロバイダから受信したデータのセットを、生産データベース1によって要求されるフォーマットに適合するために、いくつかのジョブ9、10、11、12が実行される実施形態が示されている。ジョブ9、10、11、12の別の潜在的なタスクは、データの完全性および構文に関していくつかのチェックを実行することである。

【0030】

ジョブ9、10、11、12の詳細な例は、運賃定義の1つの構成要素のデータエンティティで構成されるデータのセットについて、図3で与えられる。少なくとも1つのデータのセットを含むファイルが入力13で受信される。そこで、送信されたファイルを制御するために編集/変換ステップを実行するために、第1のジョブ9が着手される。第1のジョブ9は、以下を含みうる:
- データのセットの、全てのフィールドの構文チェック(チェックが失敗すると、エラーが生じて、レコードが拒否されうる。)
- 内部データ構造に対応するデータエンティティへの、ファイルのレコードの変換
- このジョブは、入力ファイルの無用なレコードを省略することによって処理されるべきデータもフィルタリングしうる。無用なレコードとは、たとえば、中止データおよび有効なデータがファイルの送信データの前である、過去のレコードである。
- いくつかの構成要素についてのデータのセットを含むファイルの場合、ジョブ9は、それぞれの構成要素データの別の処理ができるように、そのデータを分割する。
- アイコン14は、データエンティティに変換されるデータのセットを備えるジョブ9の出力を反映する。

【0031】

任意のジョブ9aは、それらの処理を最適化するためにデータをソートしうる。ソート基準はデータのセットのタイプに特有である。このステップの役割は、次のステップ(統合前)の並列化、および適用されるべき変更プロトコルと互換性がある順序でデータをソートすることである。実際、並列化を効率的にするために、システムが別個のデータドメインを処理することを保証する必要がある。変更プロトコルに関しては、データは、適切に操作するために所与の順序でソートされなければならない。たとえば、運賃は、所有者/キャリア/関税/ルール/運賃クラス/起点/終点/…でソートされる。次いで、洗練された内部構造15が取得される。

【0032】

ジョブ10は、データベース内で効率的に更新する前にデータが準備される、統合前ステップに対応する。これによって、データベース内の統合のための再開始点を有することができるようになる。さらに、運賃が新しいルールを参照する場合などにさらなる動作を行うことができ、次いでこのステップでこの参照がチェックされる。これによって、運賃定義の一貫性を保証できるようになる。ジョブ10の出力は、予備データベースに格納された少なくとも1つの表16内にある。この段階で、さらなるジョブがデータベース内のそれらの入力データを取るので、高い並列性因子を使用でき、前記データは潜在的に任意の実行している並列インスタンスによって交換可能に処理される可能性がある点に留意されたい。反対に、ジョブ9、9a、10は、それぞれのジョブの並列化がファイル分割前を意味するようにファイルを処理している。

【0033】

図3に示されるジョブ11は、データ統合を目的とする。ジョブ11は以下を含むことができる:
- データベース予備表16からのデータ検索
- データプロバイダによって指定される変更プロトコルの適用(このプロトコルは、運賃定義(新しい、または更新された)が、データベース内にすでに存在するデータのセットと統合されなければならない方法を記述する。このプロトコルは、運賃定義がデータのセットに基づいてデータベース内で変更されなければならない方法を記述する。)
- クロス制御チェック(cross control check)などのいくつかのチェックの実行

【0034】

次いで、データは参照データベース17の形式で更新されうる。

【0035】

次いで、参照表のデータのアクティブなイメージを作成することによって、ジョブ12がデータを生産データベース1にロードする。ジョブ12は、いくつかのルール情報を運賃に非正規化することなどの、いくつかのさらなる動作も実行できる。

【0036】

上述の処理チェーンは、本発明のおかげで管理されうる処理時間、(ジョブの時間の長さを考慮する)目標時間、データのセットを処理する処理チェーン内および/または並列処理チェーンの間の潜在的なジョブの従属性を含む。

【0037】

これを行うために、図2は、入力構成要素20を含みうるいくつかの特徴を示している。第1の特徴は、ジョブの着手を制御するジョブスケジューラ7である。データが別のジョブによって最初に処理される必要があるのでジョブが実行可能ではない場合があり、その理由を以下で詳細に記述する。ジョブスケジューラ7は、前記ジョブの全ての従属性が解消されると、そのジョブに着手できる。これは、インスタンスジョブ10に着手する、図2における矢印「a」に対応する。

【0038】

ジョブ10が効率的に開始する前に、矢印「b」で示されるように、リソースアロケータ8が呼び出される。この呼出しは、ジョブ10に関わるデータ量、構成要素(製品とも呼ばれる)の種類、および行われるべき処理のタイプ、すなわちジョブの性質(編集/変換、統合前、書込み)を有利に指定する。

【0039】

次いで、リソースアロケータ8は、所与のジョブに使用される並列インスタンスの数にリンクされる最良のリソースレベル(コンピュータ処理ユニット)を割り当てる。割当ては、処理チェーンの目標処理時間に基づいて行われることが好ましい。したがって、リソースアロケータ8は、処理チェーンの以前のジョブのためにすでに使用された処理時間を考慮して、時間目標に到達するために、割り当てられたリソースを適合できる。システムの最適な反応性を得るために、リソースアロケータ8は、処理チェーンのそれぞれのジョブの前に有利に呼び出される。しかし、これは本発明を限定するものではない。たとえば、これはジョブ11および12だけに行われうる。

【0040】

リソースアロケータ8は、以下を使用することが好ましい:
- 履歴統計データベースに格納された履歴データ(所与の製品および処理のタイプについて、以前の実行についての情報(たとえば、処理時間、処理されたデータ量、使用された並列性因子)を含む。)
- ジョブに適用されるべきパラメータを含みうる制約データ:
・超えるべきでない制限(CPU物理制限、最大処理時間、最大データベース作業負荷…)、
・到達すべき目標(目標とされるCPU利用、目標とされる処理時間、目標とされるデータベース作業負荷…)、
・デフォルト並列性因子、など

【0041】

処理のそれぞれのステップは、履歴統計データベース内の情報(量、処理時間)を記録する。それらの情報は、処理しなければならない量をあらかじめ知るために、次のステップによって使用される。これは、所与のサイクルについての第1のデータ量情報を記録するステップである、第1のステップ(ジョブ9)以外の任意のステップに有効である。

【0042】

所与のジョブがリソースアロケータ8を呼び出す場合、特徴(処理すべきデータ量、処理のタイプ、製品)を与える。この情報で、リソースアロケータ8は、以下に基づいて、ジョブのうちのいくつのインスタンスを並列に実行しなければならないかを決定する:
・ほとんど同じ量の同じジョブの過去の実行の処理の統計
・制約/パラメータ
・現在の処理チェーンの以前のステップの処理の統計(必要に応じて、処理の残りのステップを加速して(並列性因子を増加することによって)、以前のステップの間に何らかの理由で生じた可能性がある遅延を維持する。)

【0043】

量の範囲が広いので、同じデータ量を有する同じ製品の2つの送信を見つけることは事実上、不可能である。したがって、量の範囲は、リソースアロケータ8が統計を計算するスライス/パックに分割される。

【0044】

本発明の結果/利点は、処理すべきデータのタイプ、それらのプロバイダ、それらの量などにかかわらず、利用可能なリソースを考慮に入れた、保証および固定された処理時間である。

【0045】

リソースアロケータ8の計算は、処理チェーンの現在の状況に適合された構成の搬送をもたらし、着手されるジョブによって使用されるべき並列性因子を指定する。この構成送信は、図2における矢印「c」で示される。構成は、他のジョブの並列性因子(いくつかのインスタンスの形式であることが好ましい)を含みうる。

【0046】

図6aから6iは、構成決定の具体的な例を与える。

【0047】

図6aは、所与のタイプのデータ(製品A)について、いくつかのあらかじめ定められた構成が構成1、構成2、構成3にそれぞれ格納されており、それぞれがいくつかのデータの範囲に適用可能であることを示している。それぞれの構成は、ジョブごとに使用されるべきインスタンスの数、および構成の以前の実行の数を指定する。

【0048】

図6bは、それぞれのジョブにおけるデータ量および処理時間に関して、所与の構成についてシステムが保持する統計を示している。

【0049】

図6cの例では、入力において50000個のデータを含むデータのセットが受信される。この処理チェーンの目標時間が履行されると仮定すると、このエントリで履歴データベースを強化するために、構成「構成2」が選択されて、実行が追加される。

【0050】

図6eの代替ケースでは、構成2を使用して50000個のデータを処理する必要がある。ジョブ10を実行している場合(データの85%が処理された段階で)、目標処理時間の80%が経過しているように見える。余裕が検出されて、リソースアロケータ8が次のジョブ11から適用されるべき構成を修正する。

【0051】

リソースアロケータ8は、過去に例外的ケースがないことを決定して、残りのジョブ(ジョブ11および12)により上位の構成(構成3)の並列性レベルを適用することによって構成4という名前の新しい構成を決定する。

【0052】

新しく作成された構成4が処理チェーンの現在の構成となり、これも後に使用するために格納される(図6f参照)。

【0053】

図6gにさらなる例が与えられており、データのセットの入力において45000個のデータが受信される。構成「構成2」が選択される。図6eの例のように、ジョブ10を実行している場合(データの90%がすでに処理されている)、目標処理時間の80%が経過したように見える。再び余裕が検出されて、リソースアロケータ8が構成を変更する。

【0054】

以前の例外的ではあるが類似のケースがすでに発生しているので、構成4が選択される。それにしたがって履歴データベースが更新される(図6gおよび6h)。

【0055】

構成2がもはや標準的な構成として適切ではないことをシステムが検出すると、リソースアロケータ8が、ジョブごとに適合されたリソース割当てを備える、図6iにおける図5などの新しい標準的な構成を決定する。

【0056】

処理において費やされる時間が目標処理時間の80%に達した場合(これはパラメータ化されうる)、余裕が検出されることが好ましい。

【0057】

リソースアロケータ8は、検出された余裕を処理するために必ずしも構成を変更しない。

【0058】

例を挙げると、KOPI(重要操作性能指標(Key Operational Performance Indicator))を保存するために、システムは、目標時間(この目標時間は、それぞれのサービスレベル契約を尊重することを目的とする)内で指定される時間内に処理される送信の90%以上(KOPIに依存する値)を有することが必要であるにすぎない。これは、進行中の余裕によって目標時間内に処理される送信の90%を下回ることにならない限り、全ての余裕を修正するために、全てのリソースをプッシュする必要はないことを意味する。目標時間が依然として尊重される場合、リソースアロケータ8は構成を修正しない。

【0059】

しかし、目標時間が脅かされる場合、リソースアロケータ8が新しい構成を確立する。

【0060】

ケース1:過去に、このような例外的なケースがすでに発生した(同様の理由で、同じステップで余裕が検出されており、いくつかのデータが等しい)。
→対応する構成をとる。

【0061】

ケース2:過去に、このような例外的なケースがない。
→新しい構成が決定されなければならない

【0062】

デフォルトで、より上位の構成(すなわち、より多くのデータを処理する構成)が適用される。このような構成がない場合、線形アプローチが使用される。以下のように計算された所与の因子fに基づいてリソースの数を増加させる:
Tstd=標準的な構成において1つのデータを処理するための平均時間(余裕が検出されたステップの間)
Texc=1つのデータを処理するための平均時間(余裕が検出されたステップの間)
f=Texc/Tstd
進行中のジョブが完了間近の場合(≧80%)、フロー内の次のステップから新しい構成を適用する。
進行中のジョブが完了間近ではない場合(<80%)、フロー内の現在のステップから新しい構成を適用する。

【0063】

図4は、入力においていくつかのプロバイダファイルが受信される、本発明の他の態様を示している。プロバイダファイルAは、第1の処理チェーンをもたらす。並列処理チェーンにおいて、プロバイダファイルBおよびCも実行される。プロバイダファイルBの場合、元のファイルは運賃定義の3つの構成要素または製品についてのデータを含んでいるので、3つの「PSP」ファイルB₁、B₂、B₃に分割される。同様に、プロバイダファイルCは2つの「PSP」ファイルC₁、C₂に分割される。本明細書では、「PSP」という用語は、データのセットに作業するための好ましい内部構造に対応する。

【0064】

並列処理チェーンが個別に実行されることが理想的である。しかし、ある所与の処理チェーンのいくつかのジョブが、少なくとも別の処理チェーンのジョブに従属することが発生する場合がある。この状況は図5に示されており、例を挙げると、3つの並列処理チェーンが見える。あるチェーンは、ルールレコード3に対応するデータのセット用であり、別のチェーンはルールレコード1用であり、別のチェーンは運賃用である。本明細書に示されるジョブ11および12は、いくつかのデータエンティティについてのジョブ12を開始するために、(全てのデータエンティティについての)ジョブ11の完全な完了を待つ必要がないので、実質的に並列ジョブである。しかし、点線はジョブ12がジョブ11よりも前に終了できないことを明らかに示している。

【0065】

また、従属的な理由で、ルールレコード1処理チェーンのジョブ12は、ルールレコード3用のジョブ12が完了する前に開始できない。ルールレコード1用のジョブ12と運賃用のジョブ12との間に同じことが適用される。

【0066】

このようなイントラおよびインター製品の従属性を処理するために、ジョブスケジューラ7は、全ての処理チェーンの状況に応じてどのジョブに着手できるかを決定するために、ジョブ実行のトラッカーの機能を果たす。

【0067】

旅行および観光業界で使用される運賃について上記で与えられた例は、他のデータタイプについて類似の適用を有しうることが明らかである。本発明は、処理時間およびCPU使用が最適化されるべきあらゆる種類の処理フローに適用する。本発明のある利点は、処理チェーンが、有利なリソース割当て段階を構成するいくつかのジョブを備える点にある。

【0068】

添付の図面を参照して本発明の例示的実施形態を詳細に説明してきたが、本発明はそれらの正確な実施形態に限定されず、本発明の範囲および趣旨から逸脱することなしに当業者によって本発明に変更および修正が行われてよいことが理解されるべきである。

【符号の説明】

【0069】

1 生産データベース
2 検索エンジン
3 ネットワーク
4 プロバイダシステム
5 エンドユーザデバイス
6 予約システム
7 ジョブスケジューラ
8 リソースアロケータ
9 ジョブ
9a ジョブ
10 ジョブ
11 ジョブ
12 ジョブ
13 入力
14 アイコン
15 内部構造
16 予備表
17 参照データベース
20 構成要素

【図1】

【図2】

【図3】

【図4】

【図5】

【図6a】

【図6b】

【図6c】

【図6d】

【図6e】

【図6f】

【図6g】

【図6h】

【図6i】