特許 5963780 データウェアハウスから統計を提供する方法およびシステム

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

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

(11)【特許番号】5963780

(24)【登録日】2016年7月8日

(45)【発行日】2016年8月3日

(54)【発明の名称】データウェアハウスから統計を提供する方法およびシステム

(51)【国際特許分類】

   G06F 17/30 20060101AFI20160721BHJP

【ＦＩ】

   G06F17/30 220Z

   G06F17/30 414A

【請求項の数】25

【全頁数】34

(21)【出願番号】特願2013-553965(P2013-553965)

(86)(22)【出願日】2012年2月20日

(65)【公表番号】特表2014-509008(P2014-509008A)

(43)【公表日】2014年4月10日

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

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

(87)【国際公開日】20120830

【審査請求日】2015年2月9日

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

(32)【優先日】2011年2月21日

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

(73)【特許権者】

【識別番号】509228994

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

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

(74)【代理人】

【識別番号】100108453

【弁理士】

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

(74)【代理人】

【識別番号】100064908

【弁理士】

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

(74)【代理人】

【識別番号】100089037

【弁理士】

【氏名又は名称】渡邊 隆

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(72)【発明者】

【氏名】ゴーラブ・ナート

【審査官】 吉田 誠

(56)【参考文献】

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

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

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

【文献】 米国特許出願公開第２００３／００９３４２４（ＵＳ，Ａ１）

【文献】 JOACHIM HAMMER，CUBIST++: EVALUATING AD-HOC CUBE QUERIES USING STATISTICS TREES，DISTRIBUTED AND PARALLEL DATABASES，KLUWER ACADEMIC PUBLISHERS，２００３年１１月 １日，V14 N3，P221-254

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

Ｇ０６Ｆ １７／３０

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

【請求項1】

データウェアハウス(410)から統計データを提供する方法であって、少なくとも1つのデータ処理装置が実行する以下のステップ、すなわち
複数の索引フィールド(114)を定義するステップであって、各索引フィールドが複数の索引フィールド値を受け入れる、定義するステップと、
複数のファイル(432)を作成し、前記ファイルを索引の木(300)として階層的に索引付けるステップであって、各木に対して、
前記索引フィールド(201)を階層的に順序付けるステップ、
それぞれ索引フィールドに関連付けられ、その索引フィールドに対する1つまたは複数の索引フィールド値を収集するビンを定義するステップ、
階層的に順序付けられた索引フィールドの階層に従って1つまたは複数のビンを連結してビンのシーケンスを形成することによって、索引フィールドごとに1つのビンのみを含む索引を作成するステップ、ならびに
前記ファイルを索引の木(300)として階層的に索引付けるステップを含み、各索引が、0以上の子索引および/または最大で1つの親索引を有し、各子索引が、その親索引の索引と同じビンのシーケンスと、追加の索引フィールドに関連付けられた少なくとも1つの追加のビンとを含む、索引付けるステップと、
統計データを記憶するように構成されたデータコンテナ(325、335)を各索引に提供するステップであって、各データコンテナが索引付けられ、階層的に索引付けられた前記ファイル内から直接アドレス指定可能である、提供するステップと、
生データから構成された1つまたは複数の入力ファイル(434)を受け取り(436)、前記入力ファイル(434)で前記データコンテナを更新するステップであって、各入力ファイルに対して1つまたは複数の処理装置を使用することを含み、前記処理装置が、
統計によって分析すべき少なくとも1つの属性、および前記属性を特徴付ける1つまたは複数の入力ファイルパラメータを、前記生データから識別および抽出するステップ、
それぞれ少なくとも1つの属性、および前記属性を特徴付ける前記1つまたは複数の入力ファイルパラメータを含む少なくとも1つの個別記録(620)を、前記入力ファイル(434)から作成するステップ、
各入力ファイルパラメータを少なくとも1つの索引フィールドに関連付けるステップ、
各入力ファイルパラメータと、その入力ファイルパラメータに関連付けられた前記少なくとも1つの索引フィールドのビンとの間で対応関係を確立するステップ、
すべて前記個別記録(620)の入力ファイルパラメータに対応する前記1つまたは複数のビンで索引付けられたデータコンテナを識別するステップ、ならびに
前記識別されたデータコンテナ(325、335)を、前記個別記録(620)の前記少なくとも1つの属性でインクリメンタルに更新して、前記属性を記述する統計データを得るステップを、実行するように構成される、更新するステップと
を含むことを特徴とする、方法。

【請求項2】

照会を受け取り、各照会に対して1つまたは複数の処理装置を使用する追加のステップを含み、前記処理装置が、
前記照会内で、1つまたは複数の照会フィールド、および前記照会フィールドに関連付けられた少なくとも1つの照会フィールド値を識別し、
各照会フィールドと索引フィールドとの間で対応関係を確立し、
各照会フィールド値と、前記1つまたは複数の識別された照会フィールドに対応する各索引フィールドのビンとの間で対応関係を確立し、それによって前記照会に対応するビンを定義し、
前記照会に対応する前記ビンを含む索引で索引付けられた関連するデータコンテナを探索および識別し、
前記識別された関連するコンテナの前記統計データを検索してユーザへ送る
ようにプログラムされる、請求項1に記載の方法。

【請求項3】

統計データが、前記属性の頻度分布、または前記属性の前記分布の代表値（measures of central tendency）、または前記属性の前記分布の分散の測定に関する、請求項1または2に記載の方法。

【請求項4】

統計データが、輸送サービスに対して旅行者によって実際に支払われた価格に関する統計データに基づく、請求項3に記載の方法。

【請求項5】

索引フィールドが、最初の出発都市、最初の出発国、最初の出発地域、目的都市、目的国、目的地域、文化的目的地、スポーツ活動、美食、野生生物の観察、娯楽、正確な出発日別の出発日、月別の出発期間、週別の出発期間、正確な日付別の帰着日、月別の帰着期間、週別の帰着期間、到着後の旅行期間、事前購入カテゴリのうちの少なくとも1つである、請求項1から4のいずれか一項に記載の方法。

【請求項6】

少なくとも2つのビンを連結することによって、親索引をもたない少なくとも1つの索引が作成される、請求項1から5のいずれか一項に記載の方法。

【請求項7】

親索引をもたない索引が、最初の出発都市に関する索引フィールドに関連付けられたビンと、出発前の旅行期間に関する索引フィールドに関連付けられたビンと、航空便の出発週に関する索引フィールドに関連付けられたビンとを含む、請求項6に記載の方法。

【請求項8】

ビンが、最初の出発都市、出発都市、出発日、出発週、帰着日、帰着週、旅行期間の日数、事前購入の日数のうちの1つに関するいくつかの索引フィールド値を収集する、請求項7に記載の方法。

【請求項9】

親索引をもたない少なくとも1つの索引が、1つのビンのみを含む、請求項1から5のいずれか一項に記載の方法。

【請求項10】

入力ファイルが、輸送サービスの電子チケットであり、前記輸送の一区分に対するすべての情報を組み入れる少なくとも1つのクーポン(434)を含む、請求項1から9のいずれか一項に記載の方法。

【請求項11】

前記属性が、前記チケットまたは前記クーポンに対して実際に支払われた価格であり、前記入力ファイルパラメータが、最初の出発都市、出発都市、出発日、帰着日、出発日、帰着日、旅行期間、予約から出発までの日数というフィールドのうちの少なくとも1つを記述する、請求項10に記載の方法。

【請求項12】

照会フィールドが、最初の出発都市、最初の出発国、最初の出発地域、目的都市、目的国、目的地域、文化的目的地、スポーツの目的地、美食、野生生物の観察、娯楽、正確な出発日別の出発日、月別の出発期間、週別の出発期間、正確な日付別の帰着日、月別の帰着期間、週別の帰着期間、到着後の旅行期間、予約から出発までの日数というフィールドのうちの少なくとも1つに関する、請求項11に記載の方法。

【請求項13】

単一の索引フィールド値を、複数の索引フィールドに関連付けることができる、請求項1に記載の方法。

【請求項14】

目的都市を記述する索引フィールド値が、最初の出発都市、最初の出発国、最初の出発地域、文化的目的地、スポーツ活動、美食、野生生物の観察、娯楽という索引フィールドのうちの少なくとも2つに関連付けられる、請求項13に記載の方法。

【請求項15】

個別記録(620)を作成するステップが、日付または週または月または学期または年を各個別記録に割り当てるステップであって、前記日付が前記入力ファイルの受け取りに対応する、割り当てるステップと、前記個別記録(620)をデータ記憶手段内に記憶するステップとを含む、請求項1から14のいずれか一項に記載の方法。

【請求項16】

前記個別記録(620)で前記データコンテナを更新するステップが、同じ日付を有するまたは同じ日付期間を有する個別記録(620)のバッチを作成するステップと、個別記録(620)のバッチごとに前記データコンテナを更新するステップとを含む、請求項15に記載の方法。

【請求項17】

正確な統計データを維持することのために、記憶された個別記録(620)の日付を読み取るステップと、所与の日付より古い日付に割り当てられた以前の個別記録(620)を識別するステップと、これらの識別された以前の個別記録(620)の前記入力ファイルパラメータを通じて、これらの識別された以前の個別記録(620)で更新された前記データコンテナを位置決めするステップと、これらの識別された以前の個別記録(620)を削除することによって、前記位置決めされたデータコンテナを更新するステップとを含む、請求項15または16に記載の方法。

【請求項18】

前記識別されたデータコンテナ(325、335)をインクリメンタルに更新するステップが、以前に演算された統計データおよび前記個別記録(620)の前記少なくとも1つの属性から、更新された統計データをインクリメンタルに演算するステップを含む、請求項1から17のいずれか一項に記載の方法。

【請求項19】

データコンテナが前記入力ファイルの入力ファイルパラメータの数以下の複数のビンで索引付けられた場合、これらの1つまたは複数のビンのそれぞれが前記入力ファイルの入力ファイルパラメータに対応するという条件で、前記データコンテナが入力ファイルによって更新のために識別される、請求項1に記載の方法。

【請求項20】

個別記録(620)の入力ファイルパラメータが既存の索引フィールドに関連付けられているが、この関連付けられた既存の索引フィールドのいずれのビンにも対応しない場合、前記関連付けられた既存の索引フィールドに対して追加のビンを作成し、前記追加のビンで索引付けられた追加のデータコンテナを作成し、前記追加のデータコンテナを前記個別記録で更新する、請求項1に記載の方法。

【請求項21】

個別記録(620)の各入力ファイルパラメータがビンに対応するが、索引に対応しない前記入力ファイルパラメータに対応する1つまたは複数のビンの組合せが存在する場合、1つまたは複数の対応するビンのこの組合せで索引付けられた追加のデータコンテナを作成し、前記追加のデータコンテナを前記個別記録で更新する、請求項1に記載の方法。

【請求項22】

データコンテナ内に記憶されているすべてのデータが、フラットファイルの形式で記憶される、請求項1から21のいずれか一項に記載の方法。

【請求項23】

1つまたは複数のビンのシーケンスを形成することによって索引を作成するステップを含み、このシーケンスの少なくとも1つのビンが、前記少なくとも1つのビンに関連付けられた前記索引フィールドによって受け入れられるすべての可能な索引フィールド値を収集する、請求項1に記載の方法。

【請求項24】

データウェアハウス(410)から統計データを提供するシステムであって、処理手段を備えるシステムにおいて、前記処理手段が、
複数の索引フィールド(114)を定義するステップであって、各索引フィールドが複数の索引フィールド値を受け入れる、定義するステップと、
複数のファイル(432)を作成し、前記ファイルを索引の木(300)として階層的に索引付けるステップであって、各木に対して、
前記索引フィールド(201)を階層的に順序付けるステップ、
それぞれ索引フィールドに関連付けられ、その索引フィールドに対する1つまたは複数の索引フィールド値を収集するビンを定義するステップ、
階層的に順序付けられた索引フィールドの階層に従って1つまたは複数のビンを連結してビンのシーケンスを形成することによって、索引フィールドごとに1つのビンのみを含む索引を作成するステップ、ならびに
前記ファイルを索引の木(300)として階層的に索引付けるステップを含み、各索引が、0以上の子索引および/または最大で1つの親索引を有し、各子索引が、その親索引の索引と同じビンのシーケンスと、追加の索引フィールドに関連付けられた少なくとも1つの追加のビンとを含む、索引付けるステップと、
統計データを記憶するように構成されたデータコンテナ(325、335)を各索引に提供するステップであって、各データコンテナが索引付けられ、階層的に索引付けられた前記ファイル内から直接アドレス指定可能である、提供するステップと、
生データから構成された1つまたは複数の入力ファイル(434)を受け取り(436)、前記入力ファイル(434)で前記データコンテナを更新するステップであって、各入力ファイルに対して1つまたは複数の処理装置を使用することを含み、前記処理装置が、
統計によって分析すべき少なくとも1つの属性、および前記属性を特徴付ける1つまたは複数の入力ファイルパラメータを、前記生データから識別および抽出するステップ、
それぞれ少なくとも1つの属性、および前記属性を特徴付ける前記1つまたは複数の入力ファイルパラメータを含む少なくとも1つの個別記録(620)を、前記入力ファイル(434)から作成するステップ、
各入力ファイルパラメータを少なくとも1つの索引フィールドに関連付けるステップ、
各入力ファイルパラメータと、その入力ファイルパラメータに関連付けられた前記少なくとも1つの索引フィールドのビンとの間で対応関係を確立するステップ、
すべて前記個別記録(620)の入力ファイルパラメータに対応する前記1つまたは複数のビンで索引付けられたデータコンテナを識別するステップ、ならびに
前記識別されたデータコンテナ(325、335)を、前記個別記録(620)の前記少なくとも1つの属性でインクリメンタルに更新して、前記属性を記述する統計データを得るステップを、実行するように構成される、更新するステップと
を実行するように構成されることを特徴とする、システム。

【請求項25】

請求項1から23のいずれか一項に記載の統計データを提供する方法の各ステップをコンピュータに実行させるためのコンピュータプログラムであって、非一時的コンピュータ可読記憶媒体に記憶されたコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般に、データウェアハウスおよびビジネスインテリジェンスに関し、より詳細には、統計データを提供することを考慮して大きなデータのリポジトリからの照会をリアルタイムで処理するためにデータ検索を促進するという問題に対処する。

【0002】

本発明は、ビジネスインテリジェンスで一般に使用される大量のデータに対して統計的なオンライン分析処理(OLAP)の照会の応答時間において相当な高速化を可能にする特殊なメモリ内データ構造に関する。

【背景技術】

【0003】

すべての大会社および大企業は、営業活動を行う過程で、大量の情報を毎日収集して蓄積する必要がある。広く採用されている1つの解決策は、データベースの形式、最も一般的にはリレーショナルデータベースと呼ばれるデータベースのモデルで、この情報を記憶することである。すべての実際的な目的のため、リレーショナルデータベースは表の集まりであり、表と表の関係が定義されており、特有のリレーショナルデータベース管理システム(RDBMS)の制御下にあり、情報を効率的に記憶、更新、および検索できる構造化照会言語(SQL)を備える。階層モデルのような他のモデルも存在する。どのモデルが使用される場合でも、記憶および組織化すべき全体的なデータ量が著しく増えたときは、データベースの集まりをさらに組織化する必要がある。実際、現在では一般に、それらの大会社の毎日の業務を可能にするためだけに、数テラバイト(すなわち、10¹²バイト)の情報データを記憶し、コンテンツを永久的かつ容易にアクセス可能にする必要があり、したがってこれが、80年代から開発されてきたデータウェアハウスの概念である。データウェアハウスおよびデータマートは、戦略的な業務データおよびビジネスデータを保持するために任意の大規模な組織によって設定されたリポジトリである。ウェアハウスが組織化される方法は、ビジネスインテリジェンスに大いに関係する。検索した情報を提示および報告しながらリポジトリへ／からデータを抽出、変換、およびロードするように考案されたウェアハウス構造およびツールは、膨大な量のデータが含まれる可能性があるにもかかわらず、すべてのウェアハウスユーザが十分に情報を得た上で決定を下すことができるように、そのコンテンツのあらゆる徹底的な分析を可能にするための鍵である。

【0004】

旅行業界では、大量のデータを記憶および組織化する必要があるそのような大規模な組織は、一般に航空会社、またはGDS、すなわち「グローバルディストリビューションシステム」である。GDSとは、航空会社、ホテルチェーン、レンタカー会社、従来の旅行代理店、他のオンライン旅行サービス提供業者などを含む旅行業界のすべての行為者に世界規模で対応する少数の大規模旅行サービス提供業者のいずれかである。そのようなGDSには、たとえばスペインのマドリードに本社を置くAMADEUSという欧州の旅行サービス提供業者がある。したがってGDSは、場合によっては数百万人の旅行者、数千の旅行代理店およびオンラインサービス提供業者、ならびに数十の航空会社および輸送会社に関するデータの状況を、独自の大規模な記憶、演算、およびネットワーク化資源から、常に把握していなければならない。このため、いずれのGDSも、対応する輸送会社のすべての予定、それらの輸送会社が提供する毎日更新される無数の運賃、および数百万の旅行者のすべての発券データなどを保持する多数の大規模なデータベースを設定する必要がある。

【0005】

航空会社またはGDSなどの組織は、その方策を定めるために統計に依拠する必要があることが多い。統計はまた、購入を容易にするサービスとしてエンドユーザに提供することができる。統計では、多数のデータベース内に拡散した膨大な量のデータを分析して航空会社またはGDSなどの組織のデータウェアハウスを形成する必要があることが多い。

【0006】

さらに、膨大な量の拡散データのそのような分析は、容易なタスクではない。データの検索を容易にするようにデータベースが具体的に考案されているにもかかわらず、ウェアハウスのコンテンツの分析はやはり、そのような照会に応答して意味のある情報を抽出してエンドユーザに提示できるようにするためには、場合によっては多くの大きな表を含む異なるデータベースからのデータを相互比較する必要があることを暗黙的に意味する。通常、リレーショナルデータベースでは、これは、表のエントリで結合動作が実行されることを示唆する。これらの動作は、資源の処理および実行時間の点でコストがかかることが知られている。また、場合によっては別個のコンピュータ化されたプラットフォームから複数のデータベースにアクセスすることで、単一のコンピュータ化された内部ユニットに処理を制限できる場合より、本質的にはるかに遅い多数のI/O(入出力)動作を引き起こす。そして、これはすべて、常に動作して多くのユーザを同時に取り扱える必要があるウェアハウスデータベースの通常の生産作業に干渉する。これにより、毎日の統計データの収集および演算のような大量の情報のフェッチを含む高度な照会をリアルタイムで、すなわち数ミリ秒から１０分の数ミリ秒の期待時間枠内で処理することが、不可能ではない場合でも困難になる。

【発明の概要】

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

【0007】

したがって、本発明の目的は、場合によっては大量のデータが含まれるにもかかわらず、さらに高度な照会を処理してリアルタイムで応答できるように、統計データの検索を促進することを目的として、データベースのウェアハウスから更新され続けるデータ構造を開示することである。

【0008】

本発明のさらなる目的、特徴、および利点は、添付の図面を参照して以下の説明を考査すれば当業者には明らかになるであろう。本明細書には、任意の追加の利点が組み込まれるものとする。

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

【0009】

上記の目的を実現するために、本発明は、1つまたは複数のデータ記憶手段と、データ記憶手段に結合された1つまたは複数の処理装置とを含むデータウェアハウスから、統計データを提供する方法について説明する。

【0010】

本発明について説明するために使用される用語集および参考文献については、図面の簡単な説明の前に示す。

【0011】

この方法は、
・ 複数の索引フィールドを定義するステップであって、各索引フィールドが複数の索引フィールド値を受け入れる、定義するステップと、
・ 複数の索引ファイルを作成し、これらのファイルを索引の木として階層的に索引付けるステップであって、各木に対して、
- 索引フィールドを階層的に順序付けるステップ、
- それぞれ索引フィールドに関連付けられ、その索引フィールドに対する1つまたは複数の索引フィールド値を収集するビンを定義するステップ、
- 階層的に順序付けられた索引フィールドの階層に従って1つまたは複数のビンを連結してビンのシーケンスを形成することによって、索引フィールドごとに1つのビンのみを含む索引を作成するステップ、ならびに
- ファイルを索引の木として階層的に索引付けるステップを含み、各索引が、0以上の子索引および/または最大で1つの親索引を有し、各子索引が、その親索引の索引と同じビンのシーケンスと、追加の索引フィールドに関連付けられた少なくとも1つの追加のビンとを含む、索引付けるステップと、
・ 統計データを記憶するように構成されたデータコンテナを各索引に提供するステップであって、各データコンテナが索引付けられ、階層的に索引付けられたファイル内から直接アドレス指定可能である、提供するステップと、
・ 生データから構成された1つまたは複数の入力ファイルを受け取り、それらの入力ファイルでデータコンテナを更新するステップであって、各入力ファイルに対して1つまたは複数の処理装置を使用することを含み、これらの処理装置が、
- 統計によって分析すべき少なくとも1つの属性、およびその属性を特徴付ける1つまたは複数の入力ファイルパラメータを、生データから識別および抽出するステップ、
- それぞれ少なくとも1つの属性、および前記属性を特徴付ける1つまたは複数の入力ファイルパラメータを含む少なくとも1つの個別記録(individual record)を、入力ファイルから作成するステップ、
- 各入力ファイルパラメータを少なくとも1つの索引フィールドに関連付けるステップ、
- 各入力ファイルパラメータと、その入力ファイルパラメータに関連付けられた少なくとも1つの索引フィールドのビンとの間で対応関係を確立するステップ、
- すべて前記個別記録の入力ファイルパラメータに対応する1つまたは複数のビンで索引付けられたデータコンテナを識別するステップ、ならびに
- 識別されたデータコンテナを、前記個別記録の少なくとも1つの属性でインクリメンタルに更新して、属性を記述する統計データを得るステップを、実行するように構成される、更新するステップと
を含むことを特徴とする。

【0012】

好ましくは、この方法は、照会を受け取り、各照会に対して1つまたは複数の処理装置を使用する追加の任意選択のステップを含み、これらの処理装置は、
- 照会内で、1つまたは複数の照会フィールド、およびその照会フィールドに関連付けられた少なくとも1つの照会フィールド値を識別し、
- 各照会フィールドと索引フィールドとの間で対応関係を確立し、
- 各照会フィールド値と、前記1つまたは複数の識別された照会フィールドに対応する各索引フィールドのビンとの間で対応関係を確立し、それによって照会に対応する1組のビンを定義し、
- 照会に対応する1組のビンを含む索引で索引付けられた関連するデータコンテナを探索および識別し、
- 識別された関連するコンテナの統計データを検索してユーザへ送るようにプログラムされる。

【0013】

統計データは、頻度分布、または分布の代表値（measures of central tendency）、または分布の分散の測定に関することが有利である。有利な例によれば、統計データは、輸送サービスに対して旅行者によって実際に支払われた価格に関する統計データに基づく。

【0014】

輸送、より具体的には乗客輸送に関する特定の実施形態では、本発明は、任意選択の以下の特徴のいずれか1つを含むことができる。

【0015】

- 索引フィールドは、最初の出発都市(city of origin)、最初の出発国(country of origin)、最初の出発地域(geographical area of origin)、目的都市(city of destination)、目的国(country of origin)、目的地域(geographical area of destination)、文化的目的地(cultural destination)、スポーツ活動(sport activity)、美食(gastronomy)、野生生物の観察(wildlife observation)、娯楽(entertainment)、正確な出発日別の出発日(departure date by exact departure date)、月別の出発期間(departure period by month)、週別の出発期間(departure week by month)、正確な日付別の帰着日(return date by exact date)、月別の帰着期間(return period by month)、週別の帰着期間(return period by week)、到着後の旅行期間(duration of the trip after arrival)、事前購入カテゴリ(advance purchase category)のうちの少なくとも1つである。

【0016】

- 一実施形態によれば、少なくとも2つのビンを連結することによって、親索引をもたない少なくとも1つの索引が作成される。たとえば、親索引をもたない索引は、最初の出発都市に関する索引フィールドに関連付けられたビンと、出発前の旅行期間に関する索引フィールドに関連付けられたビンと、航空便の出発週に関する索引フィールドに関連付けられたビンとを含む。特有のユースケースによれば、ビンは、最初の出発都市、出発都市、出発日、出発週、帰着日、帰着週、旅行期間の日数、事前購入の日数のうちの1つに関するいくつかの索引フィールド値を収集する。

【0017】

- 別の実施形態によれば、親索引をもたない少なくとも1つの索引は、1つのビンのみを含む。

【0018】

- 入力ファイルは、輸送サービスの電子チケットであり、輸送の一区分に対するすべての情報を組み入れる少なくとも1つのクーポンを含む。

【0019】

- 属性は、各チケットまたはクーポンに対して実際に支払われた価格である。入力ファイルパラメータは、最初の出発都市、出発都市、出発日、帰着日、出発日、帰着日、旅行期間、予約から出発までの日数というフィールドのうちの少なくとも1つを記述する。

【0020】

- 照会フィールドは、最初の出発都市、最初の出発国、最初の出発地域、目的都市、目的国、目的地域、文化的目的地、スポーツの目的地、美食、野生生物の観察、娯楽、正確な出発日別の出発日、月別の出発期間、週別の出発期間、正確な日付別の帰着日、月別の帰着期間、週別の帰着期間、到着後の旅行期間、予約から出発までの日数というフィールドのうちの少なくとも1つに関する。

【0021】

- 単一の索引フィールド値を、複数の索引フィールドに関連付けることができる。たとえば、目的都市を記述する索引フィールド値は、最初の出発都市、最初の出発国、最初の出発地域、文化的目的地、スポーツ活動、美食、野生生物の観察、娯楽という索引フィールドのうちの少なくとも2つに関連付けられる。

【0022】

任意選択で、本発明による方法は、次の特徴およびステップのいずれか1つを含むことができる。

【0023】

- 個別記録を作成するステップは、日付または週または月または学期または年を各個別記録に割り当てるステップであって、この日付が入力ファイルの受け取りに対応する、割り当てるステップと、この個別記録をデータ記憶手段内に記憶するステップとを含む。

【0024】

- 個別記録でデータコンテナを更新するステップは、同じ日付を有するまたは同じ日付期間を有する個別記録のバッチを作成するステップと、個別記録のバッチごとにデータコンテナを更新するステップとを含む。

【0025】

- 更新するステップは、すべての以前の記録の演算を必要とするわけではない。したがって、最小の演算が必要とされる。通常、統計は、すべての入力ファイルを受け取った後の毎日の終わりの更新である。これにより、前日までに行われた演算を取り消すことなく、翌日に、毎日のトランザクションデータを、使用可能なはずのデータ範囲内へシームレスに組み込むことを可能にする。

【0026】

- 好ましくは、索引フィールド値および属性は、整数、10進数、または区間であり、適当なカウントまたは新しい値で更新される。

【0027】

コンテナへの新しい個別記録の追加は、最小の変更しか伴わず、それぞれの頻度のビン内のカウント値のみが変更される。したがって、個別記録の総数の大幅な増大にもかかわらず、コンテナのサイズおよびファイルのサイズは、使用される頻度分布表現およびインクリメンタル機構のため、それほど増大しない。他のデータは追加されない。

【0028】

- 正確な統計データを維持するために、本発明は、記憶された個別記録の日付を読み取るステップと、所与の日付より古い日付に割り当てられた以前の個別記録を識別するステップと、これらの識別された以前の個別記録の入力ファイルパラメータを通じて、これらの識別された以前の個別記録で更新されたデータコンテナを位置決めするステップと、これらの識別された以前の個別記録を削除することによって、位置決めされたデータコンテナを更新するステップとを含むことができる。より正確には、データコンテナは、識別された以前の個別記録の属性を有する位置決めされたデータコンテナをインクリメンタルに削除することによって更新される。記録を削除することは、すべての以前の記録の演算を必要とするわけではない。したがって、過去の演算を破棄することなく過去のデータを破棄して関連する統計データを維持するには、最小の演算しか必要とされない。

【0029】

- 識別されたデータコンテナをインクリメンタルに更新するステップは、以前に演算された統計データおよび前記個別記録の少なくとも1つの属性から、更新された統計データをインクリメンタルに演算するステップを含む。

【0030】

- データコンテナが入力ファイルパラメータの数以下の複数のビンで索引付けられた場合、これらの1つまたは複数のビンのそれぞれが前記入力ファイルの入力ファイルパラメータに対応するという条件で、データコンテナが入力ファイルによって更新のために識別される。

【0031】

- 個別記録の入力ファイルパラメータが既存の索引フィールドに関連付けられているが、この関連付けられた既存の索引フィールドのいずれのビンにも対応しない場合、この関連付けられた既存の索引フィールドに対して追加のビンを作成し、この追加のビンで索引付けられた追加のデータコンテナを作成し、追加のデータコンテナを前記個別記録で更新する。

【0032】

たとえば、索引NBOおよびNBO05で索引付けられたデータコンテナが存在する場合で、かつ個別記録の入力ファイルパラメータがビンNBO、05、および40に対応する場合、データコンテナNBO0540が作成される。その個別記録の属性は、索引NBO、NBO05、および新しく作成されたNBO0540で索引付けられたデータコンテナを更新する。NBO0532およびNBO0540で索引付けられたデータコンテナは、この索引の木の同じレベルに位置する。

【0033】

- 個別記録の各入力ファイルパラメータがビンに対応するが、索引に対応しない前記入力ファイルパラメータに対応する1つまたは複数のビンの組合せが存在する場合、1つまたは複数の対応するビンのこの組合せで索引付けられた追加のデータコンテナを作成し、追加のデータコンテナを前記個別記録で更新する。

【0034】

たとえば、索引NBOおよびNBO05で索引付けられたデータコンテナが存在する場合で、かつ個別記録の入力ファイルパラメータがビンNBO、05、および32に対応する場合、ビンのNBO 05 32の組合せは既存の索引に対応しない。次いで、データコンテナNBO0532が作成される。その個別記録の属性は、索引NBO、NBO05、および新しく作成されたNBO0532で索引付けられたデータコンテナを更新する。

【0035】

- GDS、航空会社、旅行代理店などの異なる実体(Entity)が、同じまたは部分的に重複するデータに対して異なる索引を必要とする場合、各企業実体に対する索引が作成され、別個の事前演算により異なるファイルが作成され、これらのファイル全体で照会を行うことができる。

【0036】

- データコンテナ内に記憶されているすべてのデータは、フラットファイルの形式で記憶される。

【0037】

- 照会は、1つまたは複数の照会フィールドに対する照会フィールド値としてワイルドカードを認める。本発明では、ワイルドカードを「*」で示す。ワイルドカードは、その照会フィールドに対応する索引フィールドの*またはワイルドカードビンのみが探索されることを意味する。したがって、照会フィールド値NBO、*、32による照会の場合、本発明は、第1および第3の索引フィールドに対してビンNBOおよび32の索引ならびに第2の索引が*またはワイルドカードビンを有するすべてのコンテナを位置決めする。これは、照会が高速化される理由の1つである。すべてのビンを探索すると、応答は遅くなったはずである。データ変換時に探索の組合せを集約することによって、参照時間中の莫大な演算時間が節約される。

【0038】

- 照会は、1つまたは複数の照会フィールドに対するワイルドカード照会フィールド値を認め、ワイルドカード照会フィールド値は、その索引フィールドに対するワイルドカードビンに対応する統計が探索されることを意味する。より正確には、この方法は、1つまたは複数のビンのシーケンスを形成することによって索引を作成するステップを含み、これらのビンの少なくとも1つは、索引フィールドに対するすべての索引フィールド値を受け入れる。そのようなビンは、ワイルドカードビンと呼ばれる。したがって、本発明は、追加の索引を自動的に作成し、データコンテナはそれほど具体的でない索引を有する。

【0039】

本発明者らのシステムからの1つの索引、たとえばNCE 01 52を検討してみる。これは、NCEから旅行タイプ01でその年の第52週に予約されたすべての旅行のグループ化された詳細に対する索引である。同様に、NCE 06 02は、NCEから旅行タイプ6でその年の第2週に予約されたすべての旅行のグループ化された詳細に対する索引である。本発明は、索引付けプロセス中にワイルドカード索引を作成する。たとえば、以下の索引NCE*52が作成され、NCEからその年の第52週に予約された任意の旅行タイプのすべての旅行のグループ化された詳細に対する索引であり、NCE2**は、NCEからその年の52週のうちの任意の週に予約されたタイプ2のすべての旅行のグループ化された詳細に対する索引であり、NCE***は、NCEからその年の52週のうちの任意の週に予約された任意の旅行タイプのすべての旅行のグループ化された詳細に対する索引である。ワイルドカードとも呼ばれる星印は、すべての索引フィールド値が受け入れられることを示す。ワイルドカードはまた、索引値「all」によって表すこともできる。意味論的に、ワイルドカードは、NCE***が各NCE xx DDに対する記録のすべてを含むことを意味し、ここで、xxは、第2の索引フィールド(たとえば、旅行タイプ)に対する任意の所与の値であり、DDは、第3の索引フィールド(たとえば、その年の週数)に対する任意の所与の値である。この特徴により、一定の時間内で大規模な照会に対する応答を検索することができる。

【0040】

本発明の別の主題は、前述の方法に従って格納されたデータウェアハウスから、統計データを検索する方法であり、1つまたは複数の処理装置を含み、
- 照会内で、1つまたは複数の照会フィールド、およびその照会フィールドに関連付けられた少なくとも1つの照会フィールド値を識別するステップと、
- 各照会フィールドと索引フィールドとの間で対応関係を確立するステップと、
- 各照会フィールド値と、前記1つまたは複数の識別された照会フィールドに対応する各索引フィールドのビンとの間で対応関係を確立し、それによって照会に対応する1組のビンを定義するステップと、
- 照会に対応する1組のビンを含む索引で索引付けられた関連するデータコンテナを探索および識別するステップと、
- 識別された関連するコンテナの統計データを検索してユーザへ送るステップと
を含むことを特徴とする。

【0041】

本発明の別の目的は、1つまたは複数のデータベースを含むデータウェアハウスから、統計データを収集する方法およびシステムであり、収集された統計データは、複数の索引付きのフラットファイル内で保持され、この方法は、統計データをカテゴリビン内へ収集するステップと、カテゴリビンをインクリメンタルに更新するステップと、フラットファイルを索引の木として階層的に索引付けるステップと、索引の各木の根で1次索引を定義するステップと、統計データまたは別の索引のコンテナのどちらかを索引から直接アドレス指定するステップとを含むことを特徴とする。

【0042】

任意選択で、この方法およびシステムは、次の随意の特徴およびステップの少なくともいずれか1つを含む。

【0043】

- 索引付きのフラットファイルは、コンピュータ化されたサービスプラットフォームの主メモリ内へインポートされ、引き続き常駐する。

【0044】

- エンドユーザからの照会は、コンピュータ化されたサービスプラットフォームの主メモリ内に引き続き常駐している複数の索引付きのフラットファイルから包括的に供される。

【0045】

- 統計データは、データウェアハウスから予定の間隔で収集される。

【0046】

- 統計データは、航空会社の航空便で輸送すべき旅行者によって支払われた実際の運賃価格である。

【0047】

- カテゴリビンは、航空便の出発地、航空便の目的地、旅行タイプ、開始週、および事前購入カテゴリである。

【0048】

- 1次索引は、航空便の出発地、旅行タイプ、および開始週を含む。

【0049】

- フラットファイル索引は、航空便の目的地および事前購入カテゴリを含む。

【0050】

- 索引は、少なくとも1つのワイルドカード文字を含む。

【0051】

本発明の別の目的は、前述のステップのいずれか1つによる統計データを提供する方法を少なくとも1つのマイクロプロセッサに実行させるように指示されたコンピュータ可読コード手段を含む、非一時的コンピュータ可読記憶媒体上に記憶されたコンピュータプログラム製品である。

【0052】

好ましくは、コンピュータプログラム製品は、オンラインウェブサイトを通じて提供される。

【0053】

本発明の別の目的は、データウェアハウス内に統計データを作成するシステムに関し、このシステムは、処理手段と、処理手段に結合された1つまたは複数のデータ記憶手段とを備える。このシステムは、データ記憶手段および処理手段が、
・ 複数の索引フィールドを定義するステップであって、各索引フィールドが複数の索引フィールド値を受け入れる、定義するステップと、
・ 複数の索引ファイルを作成し、これらのファイルを索引の木として階層的に索引付けるステップであって、各木に対して、索引フィールドを階層的に順序付けるステップ、それぞれ索引フィールドに関連付けられ、その索引フィールドに対する1つまたは複数の索引フィールド値を収集するビンを定義するステップ、階層的に順序付けられた索引フィールドの階層に従って1つまたは複数のビンを連結してビンのシーケンスを形成することによって、索引フィールドごとに1つのビンのみを含む索引を作成するステップ、ならびにファイルを索引の木として階層的に索引付けるステップを含み、各索引が、0以上の子索引および/または最大で1つの親索引を有し、各子索引が、その親索引の索引と同じビンのシーケンスと、追加の索引フィールドに関連付けられた少なくとも1つの追加のビンとを含む、索引付けるステップと、
・ 統計データを記憶するように構成されたデータコンテナを各索引に提供するステップであって、各データコンテナが索引付けられ、階層的に索引付けられたファイル内から直接アドレス指定可能である、提供するステップと、
・ 生データから構成された1つまたは複数の入力ファイルを受け取り、それらの入力ファイルでデータコンテナを更新するステップであって、各入力ファイルに対して1つまたは複数の処理装置を使用することを含み、これらの処理装置が、統計によって分析すべき少なくとも1つの属性、およびその属性を特徴付ける1つまたは複数の入力ファイルパラメータを、生データから識別および抽出するステップ、それぞれ少なくとも1つの属性、および前記属性を特徴付ける1つまたは複数の入力ファイルパラメータを含む少なくとも1つの個別記録を、入力ファイルから作成するステップ、各入力ファイルパラメータを少なくとも1つの索引フィールドに関連付けるステップ、各入力ファイルパラメータと、その入力ファイルパラメータに関連付けられた少なくとも1つの索引フィールドのビンとの間で対応関係を確立するステップ、すべて前記個別記録の入力ファイルパラメータに対応する1つまたは複数のビンで索引付けられたデータコンテナを識別するステップ、ならびに識別されたデータコンテナを、前記個別記録の少なくとも1つの属性でインクリメンタルに更新して、属性を記述する統計データを得るステップを、実行するように構成される、更新するステップと
を実行するように構成されることを特徴とする。

【0054】

好ましくは、このシステムはまた、照会を受け取る手段を備え、この手段は、1つまたは複数の処理装置を使用することによって各照会に対して以下のステップを実行するように構成され、これらの処理装置は、照会内で、1つまたは複数の照会フィールド、およびその照会フィールドに関連付けられた少なくとも1つの照会フィールド値を識別し、各照会フィールドと索引フィールドとの間で対応関係を確立し、各照会フィールド値と、前記1つまたは複数の識別された照会フィールドに対応する各索引フィールドのビンとの間で対応関係を確立し、それによって照会に対応する1組のビンを定義し、照会に対応する1組のビンを含む索引で索引付けられた関連するデータコンテナを探索および識別し、識別された関連するコンテナの統計データを検索してユーザへ送り、それによって、含まれるデータの量とは独立して、数ミリ秒程度の経過時間内で、エンドユーザ照会に応答して統計データの検索を可能にするようにプログラムされる。

【0055】

本発明はそれによって、高度な照会、すなわち毎日の統計データの収集および演算のような膨大な量の情報のフェッチを含む照会に、非常に短い時間で応答することを可能にする。

【0056】

本発明の別の目的は、前述のステップのいずれか1つによる統計データを提供する方法を少なくとも1つのマイクロプロセッサに実行させるように指示されたコンピュータ可読コード手段を含む、非一時的コンピュータ可読記憶媒体上に記憶されたコンピュータプログラム製品である。

【0057】

本発明の様々な特徴について、説明および定義により以下に詳述する。

【0058】

統計データ
本発明は、多数の生データから演算された統計データを作成し、記憶し、インクリメンタルに更新し、かつ検索するシステムを提供する。所与の変数に対して、これらの統計データは、たとえば、頻度分布、分布の代表値、たとえば平均値または中央値、分布の分散、たとえば標準偏差の測定、百分位数/四分位数によって識別される分布自体の性質などに関することができる。

【0059】

そのような統計データは、限定的ではない。統計によって調査されるデータの性質もまた、限定的ではない。

【0060】

典型的な例は、販売中の、または顧客によって支払われた、任意の所与の製品またはサービスの価格に関する統計に関する。本発明の特に有利な用途は、乗客によって実際に支払われた輸送チケットの価格に関する統計データに関する。

【0061】

索引、索引フィールド、索引フィールド値、およびビン
索引フィールド(IF)とは、分析すべき別のパラメータの統計を特徴付けることに関するパラメータである。たとえば、旅行の価格に関する統計データの場合、索引フィールドは、旅行の出発地(たとえば、索引フィールド=「都市」、「国」、「地域」など)、旅行の位置的な目的地(たとえば、索引フィールド=「都市」、「国」、「地域」)および/もしくはテーマ別の目的地(たとえば、索引フィールド=「文化的目的地」、「スポーツの目的地」、「美食の目的地」、「野生生物の観察」、「娯楽」など)、出発日(たとえば、索引フィールド=「正確な出発日」)もしくは「出発期間」(たとえば、索引フィールド=「正確な出発日」、「出発月」、「出発週」)、帰着日(たとえば、索引フィールド=「正確な帰着日」)もしくは「帰着期間」(特有の月または週または週末)、あるいは「旅行タイプカテゴリ」(到着後の旅行期間)、「予約日」もしくは「予約期間」、「事前購入カテゴリ」(予約から出発までの期間)に関することができる。記載の例で以下に挙げる索引フィールドは、理解のために選択されたものであり、限定的ではない。

【0062】

索引フィールドの値(IFV)とは、事前定義された値領域内から索引フィールドを割り当てることができる値である。この値は、特定の実体または実体の集まり(たとえば、空港または都市または目的地のテーマ)を表す数字(日数)または英数字コードとすることができる。索引フィールド値は通常、事前に決定された指定の固定の長さである。たとえば、旅行クーポンの価格に関する統計を分析するとき、
- 索引フィールド「出発地」に対する索引フィールド値は、ナイロビ(最初の出発都市)、ケニア(最初の出発国)、アフリカ(地域)の1つとすることができる。
- 旅行の目的に関する索引フィールド「目的都市」、「地域」、「野生生物の観察」、「鉄道博物館」に対する索引フィールド値は、たとえば「ナイロビ」とすることができる。したがって、1つの単一の索引フィールド値を複数の索引フィールドに関連付けることができることが明らかである。
- 出発日に関する索引フィールド「正確な出発日」、「出発週」、「出発月」に対する索引フィールド値は、「2007年6月14日」とすることができる。
- 索引フィールド「旅行タイプカテゴリ」または「旅行期間」に対する索引フィールド値は、1日間、3日間、2週間、1ヶ月間および3日間などの1つとすることができる。
- 索引フィールド「事前購入カテゴリ」に対する索引フィールド値は、1日間、3日間、2週間、1ヶ月間などの1つとすることができる。
- 索引フィールド値は、適当な固定の長さの*を繰り返すことによって指定されるワイルドカードとすることができる。これは、キャッチオール型の索引値のようなものであり、その意味は、演算で典型的に見られるドントケア(don't-care)記号に対応する。

【0063】

ビンは、索引フィールドの値がその中で割り当てられることが保証される領域を数学的に表す。ビンに割り当てられるラベルは、索引フィールドに対する索引フィールド値と考えられ、この長さに対応する。これは、索引フィールド値が集まりに対応する場合でも当てはまるが、そのラベルの意味は単一の実体ではなく、数字範囲の両端(extremities)によって示すことができる値の個別の集まりまたは連続する集合を表す。たとえば、索引フィールド「月別の出発期間」の領域は、1〜12の範囲の12個のビン内で整数として個別に定義することができ、これにより、1から12までの間に位置する1つのビンラベルにその年のすべての日付を大まかに分類する。

【0064】

同様に、索引フィールド「野生生物の観察」または「テーマ別の目的地」は、狩猟旅行にとって良好な開始点である都市に対応するビン「狩猟旅行(safari)」を有することができる。ビン「狩猟旅行」は、索引フィールド値「ナイロビ」、「マラセレナ(Mara Serena)」、「ハボローネ(Gaborone)」、および狩猟旅行で有名な国立公園付近に位置する他の都市などを収集することができる。

【0065】

入力ファイル、記録、属性、データコンテナ
入力ファイルとは、システムによって分析すべき元のデータセット、生データを含む、システムによって受け取られるファイルである。システムは、入力ファイルを分析し、入力ファイル内の記録の属性を保持し、削除し、または関連する事前定義された索引フィールドの集まりに対応する適当な索引フィールド値に変換し、照会に応答して結果としてシステムによって統計を提供すべきパラメータに関連付ける。入力ファイル内のすべてのデータは、分析される前は生データと呼ばれる。

【0066】

元のデータセット(生データ)では、記録は属性のタプル(tuple)にすぎず、そこから、統計が求められている1組の索引フィールド値またはパラメータを定義し、次いで演算することができる。たとえば、航空便価格と呼ばれるパラメータに影響を与える唯一の索引フィールドとして出発地および目的地をモデル化することに決めた場合、入力データソースファイルをクーポンまたはチケットのどちらかとすることができる。各クーポンは、ちょうど表またはスプレッドシート内の1つの行のような記録であると考えることができ、表の列ヘッダは、出発地、目的地、出発日、発券日、PNR日、客室クラス、運賃クラスなどのような多くの属性に対応し、これらの属性のいくつかは、統計に関心のある索引フィールド、たとえば出発地、所与のパラメータ、たとえば価格に索引付けるための当該目的地になるように選択される。変換プロセスは、選択された索引フィールドの変換された索引フィールド値に到達するように、元のデータセット上の属性値全体で実行される。たとえば、出発までの日数が索引フィールドとして選択された場合、変換プロセスは、出発日およびPNR日(または発券日)と呼ばれる元のデータセット属性を利用して、出発日-PNR日または出発日-発券日として、「出発までの日数」という索引フィールドの値に到達する。

【0067】

変換されたデータセットでは、記録の概念が異なることに留意されたい。変換された記録のリポジトリでは、各記録は、索引の木における経路である。元のデータセット内の多くの記録は、変換されたデータセット内の単一の記録にマッピングされる。一例として、主要な調査パラメータとして価格統計に関心があり、価格の主要な決定要因として出発地および目的地をモデル化することに決めた場合を検討してみる。ここで、第1のレベル索引フィールドが出発地空港である場合、クーポンが解析されるたびに遭遇するいくつかの出発地空港の数が膨大であるため、複数の索引値は、各出発地空港の索引フィールド値として分岐する。第2のレベルが目的地空港である場合、所与の出発地空港に対する各目的地空港に対して複数の索引フィールド値が分岐し、その結果、2レベルの木が生じる。最終的に、各出発地-目的地索引の対に対して、複数の価格が存在可能である。したがって、複数の価格は各目的地ノードから分岐し、その結果、その木の第3のレベルが生じる。すべての固有の出発地-目的地-価格のトリプルまたはこの木における経路それぞれに対して、頻度カウントの結果、木において第4のレベルが生じる。しかし、その木のより高いレベル内の1対多の関係とは異なり、第3のレベル内の各木ノードと第4のレベル内の各ノードとの間の関係は1対1であることに注意されたい。その木における索引経路に対する価格-頻度カウントの対は、「データコンテナ」と呼ばれ、実際には、同じ索引フィールド値、たとえばNCE-NYCを有するすべての元の記録の異なる価格の分布を、出発地-目的地都市として記憶する。(出発地、目的地の集まり)の対および(目的地、価格の集まり)の対を、「索引コンテナ」と呼ぶ。通常、根から開始する木における完全(葉まで)または不完全(葉に届かない)な任意の経路が、通常、コンテナと呼ばれる。

【0068】

照会、照会フィールド、および照会フィールド値
照会は、データに関する統計を入手してそれを統計的に分析するために、ユーザによって充填されて送られる。照会は、本発明で「照会フィールド値」と呼ぶ1つまたは複数の探索基準を含むことができる。照会は、多数の照会フィールド値を含むときは非常に複雑になることがあり、または1つもしくは少数の照会フィールド値を含むときは基本的なものになることがある。

【0069】

照会フィールドとは、照会を特徴付けるパラメータである。各照会フィールド値は、照会フィールドに関する。各照会フィールドは、索引フィールドに対応する。照会フィールド値に対応する索引フィールドがないとき、任意選択のステップが実行される。これらの任意選択のステップについては、以下に詳述する。

【0070】

所与の照会フィールド値は、所与の照会フィールド値の照会フィールドに対応する索引フィールドのビンに対応する。「対応する」とは、照会フィールド値が索引フィールド値(本当の値もしくは記述値)に類似している、索引フィールドのビン内に含まれている、または索引フィールドのビンに等しいことがあることを意味する。照会インターフェースがユーザ入力を受け入れることができる形式または形状がどのようなものであっても、第1にそのままの入力を変換して、変換されたデータセット自体を作成するために使用された索引とまったく同じ順序の索引フィールドの適当なビン値にすることによって、その入力を照会フィールド値のストリングに変換しなければならない。

【0071】

たとえば、変換されたデータリポジトリが2つの索引フィールド値によって索引付けられており、第1の索引フィールド値が出発地、旅行タイプ、および開始週の連結を含む複合タイプであり、第2のレベルの索引が目的都市である場合、「ドバイからナイロビまで、出発日が8月4日であり、旅行期間が25日間である旅行に対して、旅行者によって実際に支払われた価格の頻度分布はどのようなものか?」という照会は、まず第1の索引に対する索引フィールド値としてユーザ入力をDBX532のようなストリングに変換し、次の索引に対応するコンテナを入手し、検索された索引内で第2の索引NBOを累進的に探索して、最終的なデータコンテナを入手することによって答えられる。

【0072】

したがって、本発明の有利な特徴は次の通りである。

【0073】

- 個別記録ではなく記録のグループ(すなわち、ビジネス関連コンテナ)について記憶し、索引付けし、理由付けする。従来のデータベースで行われるものとは異なり、本発明は、個々の微小な記録を記憶する必要なく、記録のグループについて記憶し、索引付けし、検索し、かつ理由付ける能力を有する。

【0074】

- コンテナ索引またはコンテンツの演算は、照会時には実行されない。すべては事前に演算されている。照会時には、関連する記録のみが探索され、発見される場合も、発見されない場合もある。すべての索引、各コンテナに対する再帰的および非再帰的コンテンツは、特定のビジネスの必要に対して個別記録のどのフィールドが重要であるかに基づいて事前に演算されている。照会時には、正しい記録に対応する統計データコンテナのみが検索される。

【0075】

- 異なるビジネスユーザが、同じデータまたは部分的に重複するデータに対して異なる索引を必要とする場合、別個の事前演算により、異なるファイルを作成し、次いでリポジトリの異なる索引付けが行われ、これらのリポジトリについて照会を行うことができる。

【0076】

- 索引は、高速検索のための莫大なメモリ内の索引付きの表にアドレス指定するためのキーとして働き、RAM(ランダムアクセスメモリ)常駐グループ記録データにより、高速検索が可能になり、したがってRAM機械に比べて低速の現在のI/O機械に打ち勝つ。これを実現するために、ファイルサイズは、本発明の以下の説明で述べるように、許容できる制限内で維持される。

【0077】

- 索引は、所与の索引付き変数の値の1つと組み合わせられてワイルドカード文字*になり、その意味は「ドントケア」である。リレーショナルデータベース用語では、これは、関連する表のすべての可能な結合に対する結果を事前に演算することを意味する。

【0078】

- 過去の演算を破棄することなく新しい個別記録を追加する必要があるとき、または古い個別記録を削除する必要があるときに、コンテナを更新するインクリメンタル機構。新しい個別記録を追加する必要があるとき、その対応する索引が作成され、探索される。そのような索引が発見された場合、パラメータに対応する統計が更新される。順序値または区間値のみが、適当なカウントまたは新しい値で更新される。新しい個別記録が、対応する索引付きのコンテナをもたない場合、その対応する索引が作成され、コンテンツが更新される。

【0079】

- 上記の機構を使用してビジネスの必要に関連するすべての基準によって統計的な価格分布を作成し、記憶し、かつ漸インクリメンタルに更新する機構。個別記録の総数の大幅な増大にもかかわらず、コンテナサイズおよびファイルサイズは、使用される頻度分布表現のため、それほど増大しない。新しい個別記録をコンテナに追加することで、変更が最小ですみ、それぞれの頻度ビン内のカウント値のみが変更される。他のデータは追加されない。これにより、ファイルサイズを制御下で維持する。

【図面の簡単な説明】

【0080】

【図1】本発明のデータ構造からリアルタイムで処理されることが意図される種類の照会の例示的な結果を示す図である。

【図2】記憶情報へのリアルタイムアクセスを可能にするために、ウェアハウスデータベースからプリフェッチしたデータがどのように組織化されるかについて説明する図である。

【図3】データ構造の演算された統計データへの高速アクセスを可能にするために、エントリキーがどのように記憶および組織化されるかを示す図である。

【図4】データウェアハウスから収集された統計データの高速の索引付け、検索、および表示を可能にする、本発明によるシステムの全体的なアーキテクチャを示す図である。

【図5】本発明によるシステムの性能について論じる図である。

【図6】入ってくる生データからの索引ファイルのインクリメンタルな更新について論じる図である。

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

【0081】

本発明の以下の詳細な説明は、添付の図面に関する。本説明は例示的な実施形態を含むが、他の実施形態も可能であり、本発明の精神および範囲から逸脱することなく、記載の実施形態に変更を加えることができる。

【0082】

以下の本発明の詳細な説明は、旅行データ、より具体的には航空会社の航空便および運賃を伴うGDSの文脈で示すが、本発明は、あらゆる種類のデータを処理するように容易に適合でき、したがって航空会社の旅行サービスの分野での適用に制限されないことが、情報システムの当業者には明らかになるであろう。

【0083】

図1は、本発明のデータ構造からリアルタイムで処理されることが意図される種類の照会の例示的な結果を示す。図1はまた、その種類の照会に応答して提供される統計データの表示の一例を示す。

【0084】

本発明のデータ構造によって可能になる照会は、実際には、通常のリレーショナルデータベースに対して発行される照会(たとえば、SQL照会)とは大きく異なる。これらの照会は主に、図1の例示的な表示を得るには多くのリレーショナルデータベース表の個々の項目を代わりに収集および処理しなければならないために普通なら必要とされるはずのいかなる後処理も示唆しないという点で異なる。

【0085】

ある大会社を経営するには、担当の管理チームおよび専門家は通常、統計データを収集する必要があり、場合によっては、データウェアハウスの様々なデータベースからデータの断片を組み立てて、毎日更新し続けなければならない。本発明を説明する文脈では、航空業界、予約数、および所与の出発地から所与の目的地までの航空便に対して乗客によって支払われた実際の価格は、専門家が本発明のデータ構造を実施するソフトウェアアプリケーションからリアルタイムで表示したいと考える種類の要求に対応する。

【0086】

したがって、110に示すように、たとえば、フィンランドのヘルシンキ111とノルウェーのオスロ空港112の都市間で、任意の出発日115(エントリフィールドは空)で、すべての予約された帰着日または旅行期間117に対して支払われたすべての予約を表示したいと考えてもよい。出発地、目的地、出発日、帰着/期間、および事前予約時間というフィールド(114)はそれぞれ、照会可能フィールドを構成する。これらの値は、上記で定義した記述テキストコードまたは数字のいずれかである。旅行業界にとって重要な関心のある関連するパラメータは、図示のように8つのビン内に構成される事前予約または事前購入時間119である。この例示的な表示ではすべてが考慮され、したがって、棒グラフ110は、発生頻度と、指定された出発地と目的地の航空会社の都市間で登録されて支払われた実際の予約の価格との関係を示す。明らかに、平均値、標準偏差、最小値、および最大値などを含むこの分布を特徴付けるすべての標準的な統計数を、同じく演算および表示112することができる。

【0087】

ユーザは、特定のタイプの旅行期間127のみを考慮し、2週間以下の事前予約時間の場合、特定の日付125の出発のみを示すように表示をさらに精錬したいと考えることがあり、表示される棒グラフは120に示すようになる。

【0088】

この種類の照会をリアルタイムで表示および更新できるように、以下の図で詳細に説明する本発明のデータ構造は、照会されるとすべての必要な断片を容易に迅速に表示できるように、データウェアハウスからのデータ構造を事前にフェッチし、演算し、かつ組織化しなければならない。本発明を示すために使用される説明の文脈では、航空旅行業界において、110で示す例示的な種類の高度な要求に対して、データ構造は、世界中のすべての航空会社の都市および空港に場合によっては対応するように組織化され、また、データ構造内に直接エントリを提供して、出発日、旅行期間、事前予約時間などのような他の選択されたパラメータの表示を可能にする。さらに、ワイルドカードパラメータが可能であり、したがってユーザは、出発日のような特定のパラメータを指定しないという自由を有する。このデータ構造は、たとえば包括的な出発地および目的地を含む可能性を提供し、したがってユーザは、たとえば厳密な出発地、たとえばヘルシンキから、世界の特定の領域、たとえば北米中のすべての都市および空港へのすべての航空便の予約を確認したいと考えることができる。

【0089】

本発明のデータ構造は、旅行用途でのエンドユーザによっても同様に使用することができ、これはオンラインで利用可能になり、旅行の予想を可能にするはずである。使用されるデータは、GDSデータベースから抽出された実際の価格であり、したがって航空便を予約するために旅行者によって支払われた価格であるため、図1に示す収集および表示は、非常に有用なツールになる。将来の旅行の価格を推定して旅行者の選択を決定するために使用できるツールは、上記の特徴を利用する。たとえば、厳密な日付を選択する必要のない可能性および/または厳密な出発地もしくは目的地を選択する必要のない可能性は、今日の旅行場所に関して大きな自由度を加える。

【0090】

実際には、これらの後者は通常、利用可能性にかかわらず、旅行者によって支払われた実際の価格の範囲および分布は単に無視して、公開された運賃のみを考慮し、さらにより多くの場合、公開された最低運賃のみを考慮する。さらに、データ構造は、出発地および目的地が、たとえば地理的にはまったく共通点のないテーマ別の目的地を含むように強化することができる。そのようなテーマは、たとえば、エジプトのピラミッドならびにメキシコおよびラテンアメリカのコロンブス以前の民族のピラミッドを含む古代文明とすることができる。上記で定義したように、古代文明は、専用の索引フィールド値および照会フィールド値に対応することができる。

【0091】

本発明の以下の説明でさらに述べるように、上記で論じた種類の照会に応答して統計結果を表示する検索プロセスは、関連する大量のデータとはほぼ独立しており、数ミリ秒程度で行われる。類似の応答時間は、分布の特別なパラメトリックサブセットに関する照会に対しても保証され、表示によって、ユーザ選択可能な方法で分布サブセットの容易な視覚的比較が可能になる。

【0092】

図2は、記憶情報へのリアルタイムアクセスを可能にするために、ウェアハウスデータベースからプリフェッチしたデータがどのように組織化されるかについて説明する。

【0093】

この目的を実現するために、プリフェッチされたデータ記録を有限数のデータカテゴリ内に再グループ化することによって、これらのデータ記録の圧縮が実行される。これらのデータカテゴリを本説明ではビンと呼び、考慮されているビジネスのタイプ、すなわち本発明について説明するために選択されたこの例では航空業界に最良適合されている。次いで、プリフェッチされたデータは、旅行代理店、オンライン旅行サービス提供業者、および航空会社自体を含む様々な販売チャネルを通じて毎日発行されるすべての発券データ記録またはクーポン(現在は非物質化された印刷済みチケットクーポンに関する)をウェアハウスから検索することからなる。全体で、相当な期間、たとえば1年間にわたって蓄積されると、これは膨大な量の情報になるが、以下のビンを使用してデータ構造内で圧縮されている。

【0094】

事前購入日は、旅行業界にとって非常に重要なパラメータである。従来、事前購入日は、次のように、わずか8個の標準ビン内に再グループ化される。

【0095】

【表1】

【0096】

別の圧縮ステップは、以下に示すように、旅行タイプを同じく8個の標準ビン内に再グループ化することによって実現される。これにより、その年のすべての日付を出発または到着と見なす365*364の次元から、8次元のデータ空間へ、データ空間を大幅に縮小することができる。

【0097】

【表2】

【0098】

第3の圧縮ステップは、個々の日付ではなく、1年の52週のみを出発日として考慮することによって得られ、したがって各平日は、その年の52個の週ビンの1つに入る。したがって、365次元のデータ空間が、52次元の空間に圧縮される。

【0099】

この例では出発地と目的地の対に対して特殊な圧縮を試行しないが、これは本発明を限定するものではない。本発明は、複数の目的地空港を包含する「アジア」、「アメリカ」などとラベル付けされたより包括的なビンに拡張することもできる。世界中には数千の空港が存在するが、実際にはすべての対の組合せを考慮する必要があるわけではなく、いずれにしても、実際に航空便がその間を運航する空港の対に対してのみ、クーポンの発券を発行すればよい。これにより、考慮すべき組合せの数を劇的に低減させる。

【0100】

次のステップは、データ構造に対する1次索引またはエントリキーを定義することである。1次キーを構造化する方法は、本発明を説明する文脈、すなわち航空業界に適合される。他の構成も明らかに可能である。この例では、1次キーは第1のレベルの索引であり、
- 空港および都市コードに対して通常3文字のIATA(国際航空輸送協会コード)を使用する航空便の出発地(第1の索引フィールド)、
- 上記で示したように0〜7の範囲内の対応するビンの1桁の数である旅行タイプの基準(第2の索引フィールド)、
- 1〜52の範囲内の2桁の数である出発週(第3の索引フィールド)
を連結することによって得られる。

【0101】

データ構造を索引付けるために使用される1次キーの例は、次の通りである。

【0102】

【表3】

【0103】

1次キーは、文字列(text string)、場合によっては非常に長いストリングのフラットファイルの形式をとる参照表をアドレス指定するための主エントリキーであり、各ストリングは、ウェアハウスからプリフェッチされた生データから演算された統計データを圧縮形式で保持し、この1次キーに整合する。その一例を図2に示す。

【0104】

この点で特筆すべきは、圧縮アルゴリズムを使用して文字列をさらに圧縮し、記憶要件を低減させることができ、したがって、最大のデータ構造でもコンピュータの主メモリ内に完全に保持することができ、エントリキーのいずれに対しても非常に速いアクセスを保証することである。

【0105】

この例200では、201、202、および203という3つの1次キーが示されている。第1の1次キーは、週索引フィールド内にワイルドカード文字を有する1次キーである。したがってこの1次キーは、その年のいずれかの週にケニアのナイロビ(NBO)から出発するタイプ5のすべての航空便の統計データを再グループ化する。したがって、この文字列はかなり長い。この文字列は、205で示す位置で終了する。

【0106】

各ストリングは、目的地および事前購入または事前予約ビンごとに演算された統計データの境界を定義する2次キーを含み、したがって、以下に図3で説明するように、ストリング内の対応するキーの索引が検索された後、2次キーを直接アドレス指定することができる。ストリング201のすべての第2のレベルのキーを210で示す。2次キーは、対応する1次キー201に対してデータウェアハウスから航空便の予約が検索されたすべての目的地を表す。出発地の場合と同様に、目的都市および空港も3文字のIATAコードによって表される。3文字のIATAコードはそれぞれ、「最初の出発都市」という索引フィールドの索引フィールド値である。

【0107】

第3のレベルの索引付けは、事前に定義された事前購入ビンコード、すなわち220で示す0〜7の数によって行われる。演算された統計データは、任意の2つのキーによって境界が示される230のようなコンテナ内で保持される。

【0108】

図3は、データ構造の演算された統計データへの高速アクセスを可能にするために、エントリキーがどのように記憶および組織化されるかを示す。

【0109】

各1次キーは、探索木300の根に位置する。木は、簡単な文字列301で例示されている。このとき、1次索引、第1のレベルのキー310はNBO532であり、この参照表エントリが、前述のように出発日に対して旅行タイプ5であり、その年の第32の週に属するNBO(ケニアの
ナイロビ)からのすべての航空便を索引付けていることを意味する。木の1次索引は、この木のすべての索引に対する親索引である。

【0110】

この参照表エントリ内で、この例では、目的地空港によって、すなわち事前に定義された第2のレベルのキー320、すなわちDXB(アラブ首長国連邦のドバイ)、KGL(ルワンダのキガリ)、およびLHR(英国のロンドン)によって索引付けられた3つのコンテナが存在する。目的地空港を有する索引はそれぞれ、1次索引に対する子索引である。より一般には、この技術分野で通常認められるように、木の所与の索引に対して、親索引とは、その木のうち、所与の索引より木の根に近い索引である。前記の所与の索引の場合、子索引とは、その木のうち、所与の索引より木の根から遠い索引である。場合によっては、所与の索引は、複数の親索引および複数の子索引を有することがある。

【0111】

すべての事前購入カテゴリに対して統計が演算された場合、それらの統計は、この時点325で本発明のデータ構造内に挿入されたはずである。したがって、対応するデータコンテナのコンテンツを開いて、コンテンツが属する購入カテゴリにかかわらず、ナイロビからドバイへのすべての旅行に関する統計にアクセスすることができる。

【0112】

そうでない場合、各事前購入カテゴリは、第3のレベルのキー330で別個にアドレス指定される。この例の第1の目的地空港、すなわちDXBの場合、第3のレベルのキーは、この事前購入ビンに対する統計を示すビンコード6である。このコンテナ335に対する統計は、104347-0-104347-104347-3-0というデータブロックであり、このデータに対する頻度分布は104347-3である。これらの数字は、演算された第nの行までの統計パラメータの状態の値であり、後の式で見られるM_n、V_n、S_n、ならびにM_n+1、V_n+1、S_n+1を演算するために使用されるいくつかの他のインクリメンタルな状態に対応する。

【0113】

通常、所与の目的地に対して、複数の事前購入ビンが存在する。次いで、事前購入または事前予約ビンのそれぞれに対して同じ形式335が繰り返される。たとえば、図2のデータ構造では、第2のレベルのキーAMS(オランダのアムステルダム)210に対して、5つの第3のレベルのキー220、すなわち0、1、2、3、4、および6が定義されており、それぞれ独自の統計データセットを保持する。

【0114】

300に示す木のような一連のキーの木(1次キーごとに1つ)は通常、エントリキーの高速検索を可能にするために使用される最も好都合な構造であり、したがって、多次元の参照表内のコンテナを直接アドレス指定することができ、したがってほぼ一定の時間内で検索することができる。しかし、グラフまたはノードのネットワークを含む他の組織構造も同様に考慮することができる。

【0115】

図2および図3に示す多次元のデータ構造により、業界ユーザのグループにとって重要な効率的な探索指向の索引付きのデータの記憶を可能にすることができる。したがって、以下のような高度な照会を処理することができる。

【0116】

【表4】

【0117】

索引は、RAM(ランダムアクセスメモリ)に常駐する埋め込まれた索引付きの表への1次キーとして使用される。索引付きの表は、索引付きの記憶にランダムにアクセスする周知の高速方法であるために使用される。索引付きの表により、一定の時間もしくはほぼ一定の時間、または悪くても、たとえばC、C++などの従来のプログラミング言語のアレイへのランダムアクセスのような対数時間のアクセスを可能にする。これは、本発明の速度にかなり寄与する。

【0118】

さらに、本発明はメモリ-CPUバスを実施し、これもまた、統計データの処理および検索の速度に寄与する。

【0119】

たとえばNBO532のような索引は、本発明による様々な異なる方法を使用して視覚化および実施することができる。

【0120】

第1の方法によれば、索引は、索引フィールドまたは索引の階層として視覚化および処理することができる。たとえば、NBO532は、NBO→5→32という階層と見なすことができる。こう考えると、全体的には、他の潜在的なノードが第3の索引レベルでNBOから出る可能性がある(たとえば、NBO→5→41またはNBO→5→45)。NBO532、NBO541、およびNBO545は、NBO5の子索引である。同様に、他の潜在的なノードが、第2の索引レベルでNBOから出る可能性がある(たとえば、NBO→4→28またはNBO→4→26)。NBO→4→28およびNBO→4→26は、NBOの子索引である。これは木指向の実装形態であり、全体的には、データ構造全体がそのような木からなる森であり、各木の根は特有の出発地である。根は、親索引をもたない。葉は、子索引をもたない。子索引(children index)は子索引(child index)とも呼ばれる。

【0121】

より一般には、フィールドを階層的に順序付けることは、フィールドの階層を決定することを意味する。この階層は自由に決定され、好ましくは期待される照会に応じて決定される。索引の木としてファイルを階層的に索引付けることは、その索引の階層的な順序に応じて各ファイルを木に配置できることを意味する。

【0122】

たとえば、上記の例では、出発地に関するフィールドの階層は、旅行タイプに関するフィールドの階層より大きい。さらに、旅行タイプに関するフィールドの階層は、開始週に関するフィールドの階層より大きい。たとえば、図3に示したように、出発地、旅行タイプ、および開始週に関するフィールドは、目的地空港に関するフィールドより階層的に大きく、目的地空港に関するフィールドは、事前購入カテゴリに関するフィールドより階層的に大きい。

【0123】

索引の木としてファイルを階層的に索引付けることに関して、これらのファイルは、フィールドと同じ階層的順序で、索引に応じて索引付けられる。NBO532という索引は、たとえば、NBO532+DXB、NBO532+KGL、NBO532+DXB+category0、NBO532+KGL+category0という索引より階層的に大きい。したがって、索引の木において、NBO532という索引で索引付けられたファイルは、NBO532+DXB、NBO532+KGL、NBO532+DXB+category0、NBO532+KGL+category0という索引で索引付けられたファイルより根に近い。したがって、NBO532+DXBという索引は、たとえば、NBO532+DXB+category0という索引より階層的に大きい。したがって、このときNBO532+DXBという索引で索引付けられたファイルは、NBO532+DXB+category0という索引で索引付けられたファイルより根に近い。フィールドの階層的な順序付けおよびファイルの階層的な索引付けに関するこれらの説明はすべて、本説明および図にはっきりと示されている。

【0124】

別の実装方法によれば、索引は平坦化されており、索引は、NBO532がいかなる階層もなく単一の索引として処理されるという意味で複合物である。これは、たとえばNBO428またはNBO426が、NBOの階層的な子ではなくなり、独立して他の木の根になることを意味する。

【0125】

これらの2つの極端な方法間では、本発明はまた、索引構造が表す次元のチェーン全体の一部(たとえば、出発地→旅行タイプ→開始週→目的地→事前購入→価格→価格の頻度)が階層的な、かつ平坦化された索引の混合物であるという索引の可能性を提供する。この索引を、ハイブリッド索引と呼ぶ。たとえば、平坦化された索引(たとえば、NBO532)として、すなわち階層なしで、出発地→旅行タイプ→開始週と、次元の残り部分(たとえば、目的地および事前購入)を階層的として表すことを選択することができる。またはたとえば、(出発地-旅行タイプ)を平坦化として、残り部分(開始週→目的地→事前購入)を階層的として選択することができる。

【0126】

通常、階層的表現は、平坦化された表現より多くのメモリを消費するが、より多様な統計的照会を満たすことができる。平坦化された索引にはその逆が当てはまり、通常、それほど柔軟性を提供しないが、それほどメモリを必要としない。いずれにせよ、どの方法が使用される場合でも、すなわち1つの次元または1つの平坦化された複合次元の場合、索引は結局、木における経路または縮退経路になる。

【0127】

上記から、次元のシーケンスと、これらの要素が階層的モードであるか、それとも平坦化モードであるかとの両方に関して、索引木の階層的な順序付けを選択する様々な順列または組合せの可能性が存在することが明らかである。どのハイブリッド索引を選択すべきかは、業務用アプリケーションが必要とする照会の範囲を知り、それに対して妥当なメモリ要件内でそのような要件を収容することに依存する。階層の一部であるすべての索引が、次の次元の可能な索引フィールド値またはビンを索引付けるため、メモリを低減させるための鍵は、無限または有限、個別または連続の1次元における可能な入力ファイルパラメータの範囲を事前に知ることからなる。これは、索引フィールドおよびビンの作成に影響を与え、それによって階層的索引内の木の分岐要因に影響を与え、高い分岐要因はメモリ要件を増大させる。また、1次元のすべての可能な入力ファイルパラメータ/索引フィールド値を保持すること、またはより容易に理解するためにそれらの値をビンにグループ化することは、ビジネスにとって意味があるかという質問をする必要がある。旅行タイプおよび事前購入に対する詳細な例に関して上記で論じたように、ビンに入れることで、現在の次元(たとえば、旅行タイプ)の分岐要因を低減させ、索引付け方式(たとえば、開始週→目的地→事前購入)に従う次元の分岐要因に対する組合せの爆発効果を低減させることによって、メモリ要件を低減させる。

【0128】

1つの当然の疑問は、索引、たとえばNBO532に対応する照会を送った場合にどの値が出力されるかである。出力されるものは、旅行タイプ5および開始週32のNBOから発生したすべての旅程に対する属性、通常は価格の頻度分布を含む統計コンテナである。

【0129】

したがって、本発明の重要な態様は、この細密な輸送サービス提供業者領域依存データ索引付け方式とそれぞれの統計コンテナをリンクさせる関連付けデータ構造をメモリ内に作成することであり、これらの索引が作成され、それぞれの統計データコンテナは、バッチ前処理時に格納される。これらの索引には、選択された索引付けのレベルでデータコンテナを取り付けることができ、したがって、索引のそれらの値の組合せに対する正確な統計を得ることができ、結果的に、ユーザ指定の照会を得ることができる。このようにして、「ニースからどこへ行くことができるか」または「その年の第32の週のNCEから目的地への価格はどのようなものであるか」のような様々な照会に、極めて急速に答えることができる。

【0130】

特にデータ量がメモリ内に収まらない場合、複数の機械のRAMを利用して速度を増大させることができる。2人の異なるユーザが同じデータに対して速い応答時間のアクセスを必要とする場合、それらのユーザに対する異なる索引を異なる索引表内に作成することができ、分散させたRAM上へロードすることができる。

【0131】

図4は、データウェアハウスから収集された統計データの高速の索引付け、検索、および表示を可能にする、本発明によるシステムの全体的なアーキテクチャを示す。

【0132】

本発明を実施するアプリケーションソフトウェアは、コンピュータ化されたプラットフォーム410から実行されるものとする。たとえば、GDSによってその系列の旅行代理店、航空会社、および旅行サービス提供業者に対応するために設定された大きな記憶、演算、およびネットワーク化資源から実行される。本明細書では、このソフトウェアアプリケーションを、標準価格アグリゲータまたはTPA420と呼ぶ。TPA420は、統計コンテナの高速検索を可能にするために、ファイル432、通常は以前の図で説明したように索引付けられた統計データのフラットファイルを作る。索引付けられたファイルは、索引ファイルとも呼ばれる。

【0133】

本発明のこの例示的な実装形態では、アグリゲータが機能する、入ってくる生データは、たとえばGDSによってその顧客のネットワークに対応するために実行される様々なデータベース内へ毎日蓄積されるクーポンファイル434である。通常、クーポンは、系列の旅行代理店、町の航空会社の旅行オフィス、または空港から、遠隔接続された旅行業者440によって予約され、またGDSが対応するオンライン旅行サイトを使用する旅行者から直接予約される。

【0134】

索引付きのフラットファイルは、予定の間隔で、たとえば1日に1回更新され、その結果、すべての毎日のトランザクションが登録されているGDSデータウェアハウス410を実施する記憶および演算設備から、索引付きのフラットファイルを生成するのに必要なクーポンファイルおよび任意のデータがそれに応じてダウンロード436される。これらのデータは、リポジトリ430、通常はFTPリポジトリ内に記憶される。

【0135】

通常、たとえば単一の処理装置上で、1ギガバイトのデータファイルを索引付けるには8分を費やす。

【0136】

索引付きのフラットファイルは、伝達された最新のクーポンファイルからアグリゲータアプリケーション420によって生成および/または更新された後、リポジトリ内に記憶され、インポート452されて、サーバ450の演算資源によって記憶および処理される。サーバは、アグリゲータアプリケーションが、従来の旅行オンラインサイトおよび従来の旅行代理店によって提供されるサービスを向上させるための貴重なツールとして利用可能になったとき、アグリゲータアプリケーションの様々なエンドユーザ、たとえばデータウェアハウス会社ならびにすべての通常の旅行代理店および顧客から統計データを収集する必要のある会社を担当する管理チームおよび専門家の照会に応答することを目的とする。

【0137】

エンドユーザが誰であっても、照会の処理は、インターネットの従来のクライアント/サーバモデルを実施するために開発された標準的なソフトウェア手段のいずれかを実施することによって行われる。エンドユーザ460は通常、サーバの適当なフロントエンドアプリケーション458と通信できるように、端末およびパーソナルコンピュータ上で利用可能なクライアントブラウザの1つを実行している。本発明は、サーバの主メモリ内に完全に収まるように十分に小さい前述のデータ構造のサイズを維持することができる。したがって、索引付きフラットファイルのセットは、ウェブサービス層456を通じてエンドユーザ照会の処理を促進するために、RAM(ランダムアクセスメモリ)から作られた高速主メモリ454内に永久的に留まることができる。

【0138】

図5は、標準価格アグリゲータの性能について論じる。

【0139】

第1の図510は、アグリゲータによる1ヶ月の動作で処理される典型的な量のデータを示す。第1の図510は、処理される生データの量、すなわち1ヶ月間で蓄積する毎日受け取られるクーポンファイルの合計サイズ512と、その結果演算された索引付きフラットファイルサイズ514とを比較する。ハッシュ木の記憶は、10Gb/月の供給(クーポンファイル)に対して118Mb/月のペースで増える。しかし、このグラフは、月の終わりには処理済みデータが2ギガバイトに到達することを示す。

【0140】

日付ごとに、入ってくるクーポンファイル、生データの処理時間は通常、図520で示す通りである。フラットファイルを索引付けるためにアグリゲータアプリケーションによって必要とされる全体的な処理時間は、毎月1時間を超過しない。日付ごとに、必要な総時間を上部の曲線522によって表す。中間の曲線524は、属性の生の値を索引フィールドビン値に変換する際に費やされる総時間の比率を示す。下部の曲線526は、既存の索引の木における経路を演算および挿入するために使用される総時間の比率を示す。

【0141】

図530は、頻度分布表現およびその利益の証明として提出される。図530は、処理の第1の日に空の木から開始し、ますます多くのデータを処理するにつれて、変換されたデータセット内のコンテナ(木における索引経路)の数の勾配が低下することを示す。これは、処理の初めに、空の木を有するとき、存在しない多数の新しい出発地-目的地-価格の経路が活発に追加されるためである。次元の数が少ない場合、旅行タイプおよび開始週のみに対して注意深く選択されたビジネスにとって有意のビンの数も少ないため、すぐにこれらの経路は、出発地都市の数×目的地都市の数×可能な開始週の数×可能な旅行タイプの数のクロス積に対して全適用範囲付近に到達する。したがって、ますます多くのデータに遭遇したとき、少数の新しいコンテナしか木に追加されず、より多くのデータが頻度カウントとして追加され、勾配が0度になったときに全適用範囲の時間になる。グラフ530は、通常はコンテナの数にほとんどまたはまったく成長が見られない毎日の処理における第1の時間の処理に対するコンテナの増加の傾向を示すが、高いレベルのコンテナから開始し、ほぼ同じレベルのコンテナ、完全に平坦な増加曲線で終了する。これは、頻度カウントのみが増分された場合、ファイルサイズは、元のデータセット記録の数の増加に比べて極めて小さい量しか増加しないことを意味する。これは、ファイルサイズが、元のデータセット記録の数とはほぼ独立しており、したがって、記録の数が驚異的に増加した場合でも、やはりRAM内にロードすることができることを意味し、これは、次元の数が少ない限り当てはまる。

【0142】

前述のように、変更に含まれる統計コンテナは、生データの新しい断片が受け取られるたびに、すなわち毎日のクーポンファイルから受け取られるたびに、完全に再演算されるわけではない。フラットファイルの合計サイズを低く維持し、処理時間を図520に示すものに制限するために、統計データはインクリメンタルに更新される。これを実行するために知られている数学的な技法が存在する。主な統計パラメータに対して、いくつかを以下に簡単に再び示す。

【0143】

【表5】

【0144】

これにより、前日までに行われた演算を取り消すことなく、翌日に、毎日のトランザクションを、使用可能なはずのデータの範囲内へシームレスに統合することができる。

【0145】

図6は、入ってくる生データ、すなわちクーポンファイルからの索引ファイルのインクリメンタルな更新について論じる。

【0146】

営業日の終わりに、すべての発券トランザクションが既存の索引付きの表に一括して追加される。このケースを例示するために、記録の追加をはるかに小さい規模で示し、本日が2007年5月29日であると仮定する。クーポンファイルに関する現在の日付に対するトランザクションを、610として示す。

【0147】

生のクーポンファイル記録610が処理によってチケット内へ再構築され、その結果、個々のチケット記録が得られる。2つの個別記録620を620に示す。それぞれの生の入力ファイル610および個別記録620は、属性(8000 KES、25 USD)および入力ファイルパラメータ(NBO、KIS、BLM、2007-Jul-01、2007-Jul-02、04など)を含む。各入力ファイルパラメータは、索引フィールド(最初の出発都市、目的都市、出発日、到着日、旅行のタイプ、事前購入グループなど)に対応する。個別記録620は、図6ではまだグループ化されていない。各個別記録に対して、第1のフィールド621はチケット数であり、第5のフィールド625は、大部分の入力ファイルパラメータを収集し、出発地、旅行タイプビン、開始週、目的地、および事前購入ビンというすべての階層的な索引フィールドをすべてこの順序で連結した表現である。

【0148】

毎日のチケット記録は、日付で名付けられた別個のファイル内に保存される。

【0149】

このチケット記録が作成されるときはいつでも、1次索引NBO027、NBO0**、NBO*27、およびNBO***が存在する場合、これらを更新する。マスタ索引付きの表は、メモリ内にすでにロードされているため、これはO(1)または一定の時間を費やす。索引のいずれかが存在しない場合は作成され、これは単にマスタ索引付きの表内の追加の記録である。内部の実装形態に応じて、これはO(1)時間またはO(log n)時間を費やす可能性があり、ここでnは、索引付きの表内の記録の数である。O(log n)時間は、索引作成のための時間を増大させ、存在しない場合は探索および検索時間には関係しないことに留意されたい。

【0150】

新しいまたは古い表記録が識別された後、埋め込まれた目的地表を探索して、元のキーの一部でもあるキーKISを探す。存在しない場合は作成され、存在する場合は識別される。この時間もまた、O(1)またはO(log n)である。KISキーが識別されるとすぐ、すべての事前購入カテゴリに対する統計記録が更新される。この更新もまた、インクリメンタルな更新に使用される数学的な式のような移動平均、移動標準偏差、および移動百分位数のため、O(1)時間を費やす。

【0151】

同じ階層的な精神で、元のキーのうち、事前購入カテゴリを表す最後の文字0が作成または発見される。この時間もO(1)またはO(log n)であるが、上記のO(log n)またはO((log n)^2)に関する。この中の統計は更新される。

【0152】

頻度分布を更新するための正しい整数の価格ビンの発見はまた、一定の時間内で可能である。これは、頻度分布も価格によって索引付けられた表であるためである。また、価格は、出発地の通貨に対して記録される。適当な換算が行われる。したがってこの場合、第1の記録は、8000 KES(ケニアの現地通貨、ケニアシリング)の価格を有した。頻度分布内に8000がすでに存在する場合、その頻度は、その値を1だけ増分することによって更新され、そうでない場合、頻度分布表内の新しいエントリがキー8000および1の値で作成される。

【0153】

頻度分布表のサイズは、支払われた運賃によって自然に制御され、運賃は、航空会社の運賃クラスに依存することに留意されたい。任意の所与の出発地および目的地に対して、これは小さい数である。

【0154】

典型的な索引作成時間520は、図5にすでに示した。

【0155】

クーポンファイルから毎日構築されるチケット記録は、日付で名付けられた別個のファイル内に保存されるため、自動化された処理で所与の日付に対する記録を位置決めするのは容易である。

【0156】

前述のように、記録が1年間だけ維持される場合、これは、2007年5月29日に対してトランザクションが追加されたとき、2006年5月29日に対する記録を削除しなければならないことを意味する。

【0157】

削除プロセスは、追加プロセスをそのまま逆にしたものである。2006年5月29日に対するチケットファイルが位置決めされ、各チケットがメモリ内へ読み取られる。チケット620が個別記録の索引を記録しているため、これらの埋め込まれた索引を使用して、グループ化コンテナおよびそれらのサブコンテナを位置決めする。この場合、第1の記録に対して、これらの索引はNBO027、次いでKIS、次いで0、次いで8000になるはずである。しかし、追加とは異なり、削除では、最も深いレベルから最も浅いレベルへのボトムアップを進めなければならず、これは、第1にサブコンテナNBO027KIS0内の8000頻度ビンの頻度カウント、次いでNBO027KISの0ビン内の全体的な統計更新、次いでNBO027KISビンに対する全体的な統計更新を減らすことを意味する。すべては、位置決めおよび更新にO(1)時間を費やす。8000ビン内にデータの1つの断片だけが存在する場合、8000頻度ビンは削除されず、そのカウントだけが0に低減される。この最適化により、8000頻度ビンが再び将来発生する場合、追加プロセス中に1つのO(log(n))時間の記録の挿入を節約する。これはまた、0カウントの頻度ビンを有する記録の探索により、前年と本年との間のあらゆる価格変更をビジネスユーザに対して潜在的に示すこともできるという追加の利点を有し、これ自体が、価格に対する毎年の変化を識別する別個のオフラインプロセスである。

【0158】

最終的に、削除プロセスの一部として、NBO*27、NBO0**、またはNBO***に対する埋め込まれた表も更新しなければならない。

【0159】

要約すると、本発明は、
- 大量の毎日の顧客データ(たとえば、航空会社のクーポンおよびGDSからの乗客の発券記録)を考慮して、各個別記録が異なるフィールド(たとえば、予約日、出発日、出発地、目的地、支払われた価格など)を有する特徴と、
- 事前に決定された基準のセット(たとえば、事前購入、旅行のタイプなど)およびそれらの組合せによって、長期間(たとえば、1年)にわたって、テラバイト規模へのデータ量の爆発を示唆する単一の次元(たとえば、支払われた価格)に焦点を当てる(個別記録ではなく)蓄積されたデータのグループを探索および検索できるようにするというビジネス上の必要という特徴と、
- そのようなテラバイト規模のデータに及ぶ複数のオンライン統計サービスを異なる業界ユーザ(たとえば、航空会社、旅行者、旅行業者)に提供するためのさらなるビジネス上の必要という特徴とを含み、
本発明は、
- 業界ユーザのグループにとって重要なそのようなデータの効率的な探索指向の索引付きの記憶のための技術的解決策と、
- 前日までに行われた演算を取り消すことなく、翌日に、毎日のトランザクションデータを、使用可能なはずのデータの範囲内へシームレスに組み込むことも可能にする技術的解決策と、
- 照会に対する統計結果の検索プロセスが、データの量とはほぼ独立しており、数ミリ秒程度である、技術的解決策と、
- 分布のアドホックなパラメトリックサブセットに関する照会の場合でも類似の応答時間が保証される技術的解決策と、
- ユーザ選択可能な方法でサブ分布セットを容易に視覚的に比較できる表示を有する技術的解決策とを提供する。

【0160】

データウェアハウスおよびデータマートに関する従来技術とは対照的に、本発明は、これらのデータリポジトリによって通常使用されるリレーショナルデータベースの1つよりはるかに軽くて簡潔な手法をもたらす。実際には、リレーショナルデータベースは、背景部分で論じたようなビジネス上の問題を解決するのに関係のないあまりに多くの特徴ならびに演算およびI/Oオーバヘッドを備えている。主な違いについて、以下に説明する。

【0161】

- まず第1に、リレーショナルデータベースにより、それぞれの個々の生の記録を検索することができる。ユーザが、データの特定のグループまたはサブグループの概略的な特性のみに関心をもっている場合、照会時の演算は、応答時間を著しく増大させる。本発明は、ビジネス関連グループおよびサブグループを識別し、それらのグループおよびサブグループに対する所望の特性を大きな規模で事前に演算することを提案する。これは、本発明自体とリレーショナルデータベース手法を区別する本発明の1つの重要な特性である。

【0162】

- 本発明の手法をリレーショナルデータベースから遠ざける他の理由は、考慮されるビジネス環境において、ユーザは、このデータベースのみをリアルタイムで読み取ることである。これは、リアルタイムで書き込みが生じないためである。このとき、リレーショナルデータベースの場合のようにリアルタイムのコミット-ロールバック設備のオーバヘッドの必要はない。

【0163】

- リレーショナルデータベースに関して本発明によって考慮される第3の点は、リレーショナルデータベースの最適な正規化-非正規化方式でデータが記憶された場合、照会に応えるには、結合が必要とされることである。リレーショナルデータベースは、数百万、さらには数十億というそのような生の記録を記憶するため、これらの結合は、応答時間に対してあまりにも大きく寄与するはずである。本発明の方式では、すべての可能な結合結果は、ビジネス関連パラメトリック値の範囲内の索引フィールド値で事前に演算される。これを実現するために、上記のように、ワイルドカード索引付け技法が使用される。

【0164】

- 考慮される第4の点は、標準的なリレーショナルデータベースは、照会されたとき、ディスクから生の記録を検索してから、記録のグループ全体の演算をさらに開始する可能性があることである。現在のI/O動作は、RAM機械に比べて依然として数倍遅い。したがって、本発明のデータ構造を常駐のRAMにして、ファイルサイズをRAM限度より低く維持することによって、かなりの速度上の利益を提供する。これは、生の記録ではなくグループで作業し、新しい記録ごとに最大で数バイトが追加されるように頻度分布を記憶することによって実現され、その結果、ファイルサイズの増大の勾配が非常に小さくなる。

【0165】

- さらに、本発明は微小な記録ではなくグループで作業するため(リレーショナルデータベースが行うこととは対照的に)、営業日の終わりのバッチプロセス中に記録の各グループを更新するインクリメンタルな方法が存在する。照会可能ファイルサイズは、限度よりはるかに低く維持されるため、そのファイルの別のコピー(照会されているものではない)を容易に作ることができる。このファイルは、別個の物理的機械内に位置することができ、または、第2のプロセスで、ユーザ照会応答時間に一切影響を与えることなく、すべてのリアルタイム顧客データ更新を受け取って、そのグループおよびサブグループを更新することができる。このプロセスでは、周期的な間隔でデータをファイルに保存することができる。必要なリアルタイム分解能に対応する他の特有の周期的な間隔で、または特定のデータサブグループが有効な照会下にない時間で、第2のプロセスは、ユーザ照会が実行されているファイルへ更新済みパケットを送ることができる。

【0166】

すでに詳述したように、本発明によるオンライン旅行システムは、旅行パラメータとは関係なく旅行を計画する旅行者および旅行業者の能力を大きく向上させることができる。既存のシステムに対する本発明の利点は、以下の質問および応答によってさらに強調される。
質問:「価格に敏感な余暇のための旅行者で、融通のきかない日付で最も安い価格を探している。旅行システムはどのように役に立つか?」
答え:「将来の事前購入日の範囲でより低価格で行われた予約があるかどうか確認するとよい。旅行システムにより、いくつかの航空会社が過去に、本日より出発日(たとえば、2010年7月1日)の近くで低運賃クラスの一部を開放したかどうかがわかる(今日の日付を2009年12月18日とする)。つまり、今すぐ予約したいと考えていない場合、旅行システムにより、いつ(おそらく、出発日の30日前、すなわち、6月1日開始)探索を再開して予約すればこれらの価格を入手できるかがわかる。もちろんこれは、保証されるものではない。しかしこの想定は、乗客によって実際に支払われた価格に対する履歴データに基づく。したがって、非常に高い可能性がある。」
質問:「価格に敏感な余暇のための旅行者で、融通のきく日付で最も安い価格を探している。いつ旅行すべきかを知るために、旅行システムはどのように役に立つか?」
答え:「今すぐ予約したいと考えていて、出発日に融通がきく場合、本日までの最も低い価格が利用可能であった可能な事前予約期間を追加して、それらの日付の航空便を探索するだけである。」
質問:「オーストラリアへの休暇を計画している。日付または旅行期間については未定である。航空旅行の予算はどのくらいになるか?」
答え:「出発地および訪れたいいくつかの主な都市までの価格を使って旅行システムで調べるだけである。異なる事前予約日の中間の価格を予算にされたい。」
質問:「旅行探索中、偽のオンライン広告が魅力的で異常に安いチケット価格でクリックを誘う一方、サイト上ではそのようなチケット価格が見つからず、時間を無駄にしてしまうことに失望している。旅行システムはどのように役に立つか?」
答え:「旅行システムは、出発地から目的地までのチケットの価格範囲全体を、旅行タイプごとに、異なる事前購入期間によって、1年のうちの特有の出発週に対して示すことができる。つまり、その出発地および目的地で稼働しているすべての航空会社のすべての運賃クラスの価格(税込)を入手することができる。つまりまた、リアルタイムで運賃探索を始める前に、本発明による旅行システムを見れば、何を期待すべきかがわかる。不当に誘惑される確率は低くなる。さらに、予約頻度を確認することによって、供給側だけでなく要求側(誰が何を予約するか)の消費者市場の概念を入手することができる。さらに、必ずしも今すぐ予約したいと想定する必要なく、探索および予約するのによい時間はいつであるか(より低い価格)、これに対しよくない時間はいつであるかという概念を得ることができる。」

【0167】

本発明の好ましい実施形態について図示および説明したが、本発明はこれらの実施形態に限定されるものではなく、以下の特許請求の範囲の範囲内で実行するために様々な形態で実施できることが、明白に理解されるものとする。

【符号の説明】

【0168】

111 出発地
113 目的地
114 フィールド
115 出発日
117 旅行期間
119 事前予約または事前購入時間
125 出発日
127 旅行期間
129 事前購入時間
201 1次キー
202 1次キー
203 1次キー
210 第2のレベルのキー
220 事前購入ビンコード、第3のレベルのキー
230 コンテナ
300 探索木
301 文字列
310 1次索引、第1のレベルのキー
320 第2のレベルのキー
325 コンテナ
330 第3のレベルのキー
335 コンテナ
410 プラットフォーム、GDSデータウェアハウス
420 標準価格アグリゲータ、TPA
436 ダウンロード
440 旅行業者
450 サーバ
452 インポート
454 高速主メモリ
456 ウェブサービス層
458 フロントエンドアプリケーション
460 エンドユーザ
512 処理される生データの量、すなわち1ヶ月間で蓄積する毎日受け取られるクーポンファイルの合計サイズ
514 その結果演算された索引付きフラットファイルのサイズ
522 必要な総時間
524 属性の生の値を索引フィールドビン値に変換する際に費やされる総時間の比率
526 既存の索引の木における経路を演算および挿入するために使用される総時間の比率
610 トランザクション、生のクーポンファイル記録、生の入力ファイル
620 個別記録
621 第1のフィールド
625 第5のフィールド

【図6】

【図1】

【図2】

【図3】

【図4】

【図5】