JP5550654B2 - データベースにおいて大量の更新をリアルタイムで統合する方法 - Google Patents

Description

本発明は、概して、データベースの管理に関し、より具体的には、稼働させて多くのエンドユーザへのサービス提供に使用しながら、データベースに持ち込まれる多くの更新をリアルタイムで受け入れる方法に関するものである。

データベースは、７０年代に導入され広く採用され始めて、工学、科学、商業、ビジネスでの応用を含めて、あらゆる分野で急増した。その大きさは、パソコンで個人により例えば個人財政状況を記録しておくために用いられる小さなデータベースから、様々な団体、企業、商業組織によりその活動をサポートするために設立される大規模や超大規模のデータベースまで、あらゆるものがある。すべてが相互に接続されている世の中においては、一般的に、そのような大規模データベースは、常にというわけではないが、遠く離れたところにいる多くのエンドユーザでもアクセス可能になっており、データベースにより提供されるどのような情報でも照会することができる。

航空業界の場合のそういった超大規模データベースの例は、航空運賃をその使用制限規則と共に保持しているものである。運賃データベースは、主として、従来の旅行代理店やその他あらゆる種類のオンライン旅行サービス業者を含むすべての旅行産業関係者に対して旅行サービスを提供する、世界各地のいくつかの国際予約システム（ＧＤＳ： Ｇｌｏｂａｌ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ）によって構成されている。このようなＧＤＳの例として、スペインのマドリッドに本社を置くヨーロッパの旅行サービス業者であるアマデウス（ＡＭＡＤＥＵＳ）がある。

そのような大規模データベースは、相反する要求に耐えるものでなければならない。それらは、眠らない世界中のビジネスを支えるためには２４時間週７日体制で稼動していなければならないが、一方、何百もの大小航空会社により公示される新運賃を常に取得する必要もある。図１に示すように、データ提供者（１２０）すなわち航空会社あるいは航空会社を代行する運賃提供業者と、データ要求者すなわちデータベース（１００）の遠隔のエンドユーザと、その両方が同時に同じリソースにアクセスしようとしており、データベース・コンテンツが更新されていく一方で問合せに応えるという相反する状況が生じる。

この問題を回避するために実施されてきた方法として、バッチモードで作動させるということがある。すなわち、やり方はさまざまであるが、受け取ったすべての更新を下処理して蓄積しておき、定期的に（例えば、毎晩あるいは予定の間隔で）エンドユーザが使用できないようにデータベースを停止させて、それまでに蓄積されたすべての更新の埋め込みを管理者に実行させる。その後、データベースは再び使用可能な状態に戻されて、エンドユーザの要求への応答が再開できるようになる。しかしながら、これは、２４時間週７日体制での稼働を維持するという目的を明らかに果たしていない。

同じく実施されている別の解決法として、フリップ／フロップ機構を導入するということがある。２つの同一のデータベースを維持し、１つをエンドユーザの問合せに応えるために提供する一方で、もう１つは更新されていく。バッチモードの場合のような予定された間隔で、データベースの役割を入れ替える。この方法の明らかな利点は、エンドユーザにとっての停止時間がなくなる（あるいは、入れ替えを行うほんの少しの間である）ということである。しかしながら、これらの解決法はいずれも、入ってくる更新をリアルタイムで伝えることができるものではない。エンドユーザは、大きく遅れて時間がたってからしか変更を見ることができない。遅延時間は、基本的に、バッチモードあるいはフリップ／フロップモードに設定される時間間隔によって決まる。

そこで、本発明は、データ提供者から受け取った更新を継続的に統合することを可能とし、さらにそれを、コヒーレントに、かつ迅速に、データベースのエンドユーザからの問合せへの応答に使用できるように伝播(propagation)することを可能にする機構を開示することを主な目的とする。

本発明のさらなる目的、特徴、および効果は、添付の図面を参照して以下の説明を検討することで、当業者に明らかになるであろう。何らかの追加的利点を本書に組み込むことを意図するものである。

本発明は、データベースにおいて大量の更新を統合する方法を提供することにより、本発明の上記目的を達成する。個々の更新は、データ提供者により供給されるデータレコードのコヒーレント・セットからなる。データベースシステムは、マスターファイル・リポジトリと、アクティブイメージ・リポジトリとを有している。当該方法は、データ提供者により供給される更新を、最初にマスターファイル・リポジトリのマスターファイル（ＭＦ）に統合するステップを含んでいる。この統合ステップは、以下のステップを含んでいる。
‐ マスターファイルに更新を受け取る。
‐ マスターファイルにおいて、個々の更新についての、データレコードのコヒーレント・セットを定義する。この目的のため、プロセスの応用部分により、データがコヒーレントであるかどうかを調整し、データレコードのコヒーレント・セットを統合する順序を与える。
データレコードのコヒーレント・セットを定義する際には、個々の更新に対して、当該データベースシステムのロジスティック・テーブルにより、データレコードのコヒーレント・セットを一意的に識別するための固有の変更識別子を生成する。このように、変更識別子により、データレコードの各コヒーレント・セットが識別される。変更識別子は、マスターファイルでの更新の到着順に割り当てられる。
‐ 変更識別子をマスターファイルに受け取る。
‐ マスターファイルにおいて、変更識別子をデータレコードのコヒーレント・セットに割り当てる。
‐ 個々の更新のデータレコードのコヒーレント・セットと、このデータレコードのコヒーレント・セットに割り当てられた変更識別子とで、マスターファイルを更新することにより、個々の更新をコミットする。

この方法は、マスターファイルにコミットされた個々の更新に対して、固有のコミット識別子をロジスティック・テーブルから取得するステップをさらに含んでいる。コミット識別子は、個々の更新の上記コミット・ステップが完了した順序を示す数である。より正確に言えば、マスターファイルの更新が完了すると、コミット・サービスが呼び出され、その中でコミット識別子が割り当てられる。

この方法は、データベースシステムのアクティブイメージ（ＡＩ）に、個々の更新をロードするステップをさらに含んでいる。より具体的には、上記ロード・ステップは、以下のステップを含んでいる。
‐ 一意的に識別される個々の更新のデータレコードのコヒーレント・セットを、マスターファイルから取り出す。
‐ コミット識別子により指定される順序で、連続して、個々の更新をアクティブイメージに伝播していくことにより、アクティブイメージとマスターファイルを同期させる。
‐ 個々の更新のアクティブイメージへの伝播を完了させる。

これによって、本発明は、データベースシステムのエンドユーザが、伝播された更新のアクティブイメージからの検索を、直ちに開始することを可能にする。

本発明によると、連続的に更新をマスターファイル・リポジトリに統合して、遅れることなくアクティブイメージに伝播することができるので、それらを、データベースのエンドユーザにリアルタイムで提供することができる。よって、エンドユーザは、更新がアクティブイメージ・リポジトリでコミットされると、直ちにそれらの更新の検索を開始することができ、その一方で、データ提供者がマスターファイルを更新し続けることも可能であり、その新たな更新は直ちに伝播されることになる。

本発明は、オプションとして、つぎの特徴のうち少なくとも１つを備えることができる。
‐ データレコードのコヒーレント・セットは、例えば、輸送サービスの出発地と目的地、運賃、サービス提供業者の参照、運賃クラス、および各運賃が適用される輸送時期を含むことができる。
‐ 個々の更新は、ＭＦキーと呼ばれる少なくとも１つの属性セットの形式で、マスターファイルのテーブルに記憶される。このＭＦキーは、マスターファイルのレコード粒度を決定するものであり、更新の情報データと関連付けられるものである。
‐ ＭＦキーは、例えば、輸送サービスの出発地と目的地、サービス提供業者の参照、および運賃クラスを含むことができる。ＭＦキーは、運賃および各運賃が適用される輸送時期を含む情報データと関連付けられる。
‐ 更新は、アクティブイメージ（ＡＩ）のテーブルにロードされ、ＡＩキーと呼ばれる１つ以上の属性セットの形式で、記憶される。このＡＩキーは、アクティブイメージのレコード粒度を決定するものであり、更新の情報データと関係付けられるものである。
‐ １つのＡＩキーは、１つ以上のＭＦキーを含んでいる。
‐ ＡＩキーは、例えば、輸送サービスの出発地と目的地、サービス提供業者の参照を含むことができる。ＡＩキーは、運賃、運賃クラス、および各運賃が適用される輸送時期を含む情報データと関連付けられる。
‐ マスターファイルは、すべての更新の履歴を含んでいる。
‐ マスターファイルからアクティブイメージへの更新の伝播は、ロジスティック・テーブルによるコミット識別子の割り当てによって、トリガされる。
‐ コミット識別子は、個々の更新がマスターファイル・リポジトリでコミットされた順序と全く同じ順序で、ロジスティック・テーブルにより割り当てられる。
‐ あるいは、コミット識別子は、優先度に基づいて、ロジスティック・テーブルにより割り当てられる。例えば、実行の早い個別更新が優先される。

さらに、本発明は、大量の更新を統合するためのデータベースシステムを記載しており、これは、マスターファイル（ＭＦ）を有するマスターファイル・リポジトリと、アクティブイメージ（ＡＩ）を有するアクティブイメージ・リポジトリとを備えている。マスターファイル・リポジトリは、マスターファイルが更新を受け取って、各更新についてのデータレコードのコヒーレント・セットを定義するように構成されていることを特徴とし、また、マスターファイル・リポジトリはロジスティック・テーブルを備えており、これは、各更新に対して、データレコードのコヒーレント・セットを定義する際に、このデータレコードのコヒーレント・セットを一意的に識別するための固有の変更識別子を生成するように構成されていることを特徴としている。さらに、このデータベースシステムは、つぎのステップを実行するように構成されている。
‐ マスターファイルにおいて、変更識別子を受け取り、この変更識別子をデータレコードのコヒーレント・セットに割り当てる。
‐ 各更新のデータレコードのコヒーレント・セットと、このデータレコードのコヒーレント・セットに割り当てられた変更識別子とで、マスターファイルを更新することにより、各更新をコミットする。
‐ さらに、マスターファイルでコミットされた各更新に対して、固有のコミット識別子をロジスティック・テーブルから取得する。このコミット識別子は、各更新について上記コミット・ステップが完了した順序を示す数である。
‐ 更新を、アクティブイメージ・リポジトリのアクティブイメージ（ＡＩ）にロードする。これは、各更新のデータレコードのコヒーレント・セットをマスターファイルから取り出すこと、コミット識別子により指定される順序で次々と各更新をアクティブイメージに伝播することにより、アクティブイメージとマスターファイルを同期させること、各更新に対応するデータレコードの各セットのロードがアクティブイメージでコミットされたときに、各更新のアクティブイメージへの伝播を完了させること、を含んでいる。

本発明は、さらに、第１と第２のリポジトリを備えるデータベースシステムを記載しており、第１のリポジトリは、データ提供者からの更新を受け取るように構成されており、第２のリポジトリは、該データベースシステムのエンドユーザにより発せられる問合せに応答するように構成されている。当該システムは、ロジスティック・テーブルを備えており、このロジスティック・テーブルは、さらに以下のものを含んでいる。
‐ 変更識別子を生成する手段。変更識別子は、第１のリポジトリにおいて個々の更新を一意的に識別するために用いられる。
‐ コミット識別子を生成する手段。コミット識別子は、第２のリポジトリへの更新のロードを制御するために用いられる。
また、このデータベースシステムの第１のリポジトリは、ＭＦキーごとに整理されており、第２のリポジトリは、ＡＩキーごとに整理されている。

本発明は、さらに、コンピュータ読取り可能な記憶媒体に記憶されたコンピュータプログラム・プロダクトを含んでおり、これは、データベースシステムにおいて大量の更新を統合する上記方法を少なくとも１つのコンピュータに実施させるコンピュータ読取り可能コード手段を有している。

図１は、大量データの継続的取得を、同時に、多くのエンドユーザにサービスを提供することに努めながら持続しなければならない、従来技術のシングルリポジトリ・データベースを示している。 図２は、コンピュータ化された環境における本発明のデータベースシステムのモデルを示している。 図３は、ＭＦキーごとに整理されたマスターファイル（ＭＦ）リポジトリであって、さらにロジスティック・テーブルも含むものと、ＡＩキーごとに整理されたアクティブイメージ（ＡＩ）リポジトリとを備える、データベースシステム・モデルの詳細を示している。 図４は、変更識別子およびコミット識別子を用いてデータをマスターファイルからアクティブイメージに伝播する、データベースシステムの全体的動作を説明している。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。 図５ａ‐５ｌは、データベースシステムの動作の形態の説明に用いる詳細例である。

以下、添付の図面を参照して、本発明の詳細な説明を行う。この説明は、典型例となる実施形態を含んでいるが、他の実施形態も可能であり、記載の実施形態は、本発明の趣旨および範囲から逸脱することなく変更することができる。

図２は、本発明のデータベース・モデル（２００）を示しており、これはデュアルリポジトリを備えている。よって、本発明のデータベースシステムは、デュアルリポジトリ・データベースとも呼ばれる。一方のリポジトリはデータコンテンツの更新用に最適化されており、他方はデータ検索を迅速に処理できるように設計されている。

マスターファイルすなわちＭＦ（２１０）は、データ提供者（２２０）によって更新されるコンテナである。本発明の説明のために例として選択した状況、すなわち、いくつかのＧＤＳにより維持されている航空業界の大規模な運賃データベースにおいては、データ提供者は、Ａｉｒｌｉｎｅ Ｔａｒｉｆｆ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏｍｐａｎｙ（ＡＴＰＣＯ）といった運賃提供業者である可能性があるが、これは多くの国内航空会社および国際航空会社により所有されている機関であって、一日に何度も世界中の多くの航空会社の最新の航空運賃を収集して配信する機関である。運賃およびその適用規則は、航空会社により提供され、ＡＴＰＣＯによりコード化され、そして、電子的に伝送されることで、自動的にＧＤＳ運賃データベースに組み込まれる。他の運賃提供者としては、運賃をデータベースに直接登録する権限を与えられている、データベースの管理者あるいはオペレータが考えられ、一般的に運賃の登録は、専用のグラフィカルユーザインタフェース（ＧＵＩ）およびこれに対応する入力アプリケーションを介して行われる。

データがどのソースから提供される場合でも、データの更新および変更の追跡が容易であるように、ＭＦレジストリ（２１０）は設計されている。この目的のため、それは、マスターファイルに取り込まれたすべての変更の履歴も含んでいる。

アクティブイメージすなわちＡＩ（２３０）は、データベースのエンドユーザ（２４０）により発せられた要求が入ってくるのに応えて、データ検索を容易に行うことができるように設計されているリポジトリである。航空業界の運賃データベースにとってのエンドユーザは、ＧＤＳの支援を受けている正規の旅行代理店のほか、増加し続けるオンライン旅行サイトを実現しているソフトウェアアプリケーションおよびオンライン旅行サービス業者である。

本発明のデータベース・モデルの主要な目的は、データ提供者（２２０）からの大量データを調整して迅速にデータ要求者に伝播すること（２５０）を可能とし、これにより、変更や新運賃を、これらが公表され次第できるだけ早くデータベースのエンドユーザ（２４０）が利用できるようにすることである。

他のデータベースと同様に、本発明のデータベースシステムはコンピュータ化されたシステムの一部として実現され、そのシステムは、この種の大規模データベース、より具体的には本発明の考える大規模データベースを保持し稼働させるのに十分な、内部および外部の記憶装置（２０１）と処理資源とを備えた少なくとも１つのコンピュータを含むものである。

図３は、デュアルリポジトリ・データベース・モデルの詳細を示している。

新しいデータのマスターファイルへの統合（３０５）は、データレコードのコヒーレント・セットで行われなければならない。この統合は、固有の番号で表される'ＭｏｄｉｆＩＤ'（３６２）と呼ばれる変更識別子を各セットに割り当てることによって、達成される。このように、各更新がＭｏｄｉｆＩＤにより一意的に識別されることで、本発明のシステムは、ＭＦの同時更新をサポートすることが可能である。ＭｏｄｉｆＩＤは、マスターファイル・リポジトリでの更新の到着順に割り当てられる。

２つのリポジトリ（ＭＦとＡＩ）の同期は、同じく固有の番号で表される'ＣｏｍｍｉｔＩＤ'（３６４）と呼ばれるコミット識別子を用いて制御される。ＣｏｍｍｉｔＩＤの役割は、（図２でデータ伝播と呼んでいる）ＭＦからＡＩへの更新のロード（３５０）の順序を管理することである。各統合プロセスは、コミット時に、つまり、図２で説明しているデータ提供者によってデータレコードのコヒーレント・セットが実際にマスターファイル（２１０）に完全に書き込まれた時に、その"ＣｏｍｍｉｔＩＤ"を取得する。このようにして、本発明は、ロードプロセスの複数のインスタンスの実行を可能としている。各ＣｏｍｍｉｔＩＤは、変更が実際にＭＦにコミットされたシーケンスの順序が、ＡＩへの更新のロードの際に守られるように、割り当てられる。これによって、両方のリポジトリにおいて更新が同じシーケンスの順序で行われることが保証される。

ＭｏｄｉｆＩＤおよびＣｏｍｍｉｔＩＤは、ＭＦと関連付けられたロジスティック・テーブルすなわちＬＴ（３６０）に保持され、管理される。より正確に言うと、ロジスティック・テーブルは、マスターファイル・リポジトリに納められているテーブルの１つである。このため、ＭｏｄｉｆＩＤおよびＣｏｍｍｉｔＩＤは、ロジスティック・テーブルから迅速に取り出して、マスターファイルの他のテーブルに送ることができる。ＭｏｄｉｆＩＤとＣｏｍｍｉｔＩＤの割り当てが行われると、ロジスティック・テーブルには徐々に進めたＩＤが追加されていく。

両方のリポジトリにおいて、データレコードは、決められた粒度レベルで操作される。マスターファイル（ＭＦ）は、変更履歴を含んでおり、'ＭＦｋｅｙ（ＭＦキー）'ごと（３１２）に整理されている。各ＭＦｋｅｙは、属性のセットであり、データの有意最小セットからなる。ＭＦｋｅｙはマスターファイルの粒度を決定し、これにより、ＭＦｋｅｙ粒度で変更履歴が管理される。ＭＦｋｅｙの形式は、プロダクト（例えば、ＡＴＰＣＯのレコード形式、あるいはＧＤＳのレコード形式）と関連している。マスターファイルは、多くのテーブルを含んでいる。各テーブルは、１つのレコード形式専用のものである。各テーブルは、特定のＭＦｋｅｙ識別子に関連付けられている。

マスターファイルの１つのテーブルは、特定のデータ提供者により提供される特定のレコード形式に専用のものとすることができる。この場合、特定のＭＦｋｅｙがこのテーブルに割り当てられる。

例えば、マスターファイル（２１０）の１番目のテーブルは、ＡＴＰＣＯにより提供される一等運賃クラス（運賃クラス"Ｆ"）の運賃に専用のものとすることができ、２番目のテーブルは、同じくＡＴＰＣＯにより提供される別の運賃クラス（運賃クラス"Ｃ"）の運賃に専用のものとすることができ、３番目のテーブルは、ＡＴＰＣＯにより提供される規則に専用のものとすることができる。この場合、このテーブルに割り当てられるＭＦｋｅｙは、つぎのデータを含むことができる： 所定の出発地／目的地、所定のサービス提供業者（例えば航空会社）、および所定の運賃クラス。このＭＦｋｅｙに関連付けられるテーブルは、ＭＦｋｅｙの属性に関する情報データを含んでいる。図５ａ〜５ｌに例を示す。例えば、図５ａにおいて、マスターファイルの１つ目のＭＦｋｅｙは、所定の出発地／目的地（"ＮＣＥ／ＰＡＲ"）、所定のサービス提供業者（"ＡＦ"）、および所定の運賃クラス（"Ｆ"）を含んでいる。このＭＦｋｅｙに関連付けられる情報データには、運賃（"２００ユーロ"）と、この運賃に対応する旅行時期（"１０／０２／０８"）とが含まれる。マスターファイルの２つ目のＭＦｋｅｙは、所定の出発地／目的地（"ＮＣＥ／ＰＡＲ"）、所定のサービス提供業者（"ＡＦ"）、および所定の運賃クラス（"Ｃ"）を含んでいる。このＭＦｋｅｙに関連付けられている情報データには、運賃（"１５０ユーロ"）と、この運賃に対応する旅行時期（"１５／０３／０８"）とが含まれる。

別のデータ提供者により提供される運賃を含むレコードは、マスターファイルの他のテーブルに統合されることになる。

データ検索のため、アクティブイメージ（ＡＩ）は、'ＡＩｋｅｙ（ＡＩキー）'により（３３２）識別される多くのテーブルを含んでいる。ひとつのＡＩｋｅｙレコードは、一般的に、１つ以上のＭＦｋｅｙレコードを含んでいる。ひとつのＡＩｋｅｙは、ひとつのＭＦｋｅｙと同じものであってもよい。ＡＩｋｅｙは、ＡＩイメージのレコード粒度である。それは、データベースのエンドユーザにより要求されてＡＩから取り出す（３２５）ことができる、データの有意最小セットである。アクティブイメージの各テーブルは、１つのレコード形式専用のものである。アクティブイメージの各テーブルは、１つのＡＩｋｅｙ識別子に関連付けられている。

例えば、アクティブイメージ（２３０）の１つのテーブルは、所定の運賃提供者により提供される運賃に専用のものとすることができる。この場合、このテーブルに割り当てられるＡＩｋｅｙは、つぎのデータを含むことができる： 所定の出発地／目的地、および所定のサービス提供業者（例えば航空会社）。このＡＩｋｅｙに関連付けられるテーブルは、ＡＩｋｅｙのデータに関する情報データを含んでいる。例えば、図５ｋにおいて、アクティブイメージのＡＩｋｅｙは、所定の出発地／目的地（"ＮＣＥ／ＰＡＲ"）、および所定のサービス提供業者（"ＡＦ"）を含んでいる。このＡＩｋｅｙに関連付けられる情報データには、フライトごとの、運賃クラス（"Ｆ"または"Ｃ"）と、運賃（"２００ユーロ"，"１５０ユーロ"など）と、旅行時期（"１０／０２／０８"，"１５／０３／０８"など）とが含まれる。ＡＩｋｅｙの属性を提示しているＭＦｋｅｙに含まれているすべての情報データが、そのＡＩｋｅｙに関連付けられているアクティブイメージのテーブルに集められる。

図４は、更新の継続的取得を可能とする識別子（ＭｏｄｉｆＩＤおよびＣｏｍｍｉｔＩＤ）とキー（ＭＦｋｅｙおよびＡＩｋｅｙ）の利用について、例を挙げて示している。

この例においては、データベースのデータ提供者（４２０）により、３つの更新がトリガされる。時間（４０２）の関数として、更新には、図３に示すロジスティック・テーブルにより３つのＭｏｄｉｆＩＤが次々と与えられる。固有のＭｏｄｉｆＩＤにより識別される各更新は、さまざまな数の異なるレコードすなわちＭＦｋｅｙを含むことができる（４６１，４６３および４６５）。

ＭＦリポジトリに更新がコミットされると、それらには、図示のように固有のＣｏｍｍｉｔＩＤが割り当てられる（４６２，４６４，および４６６）。関連の様々なプロセスの実行時間によっては、それらのＣｏｍｍｉｔＩＤは、必ずしもＭｏｄｉｆＩＤと同じ順序で割り当てられるとは限らない。従って、アクティブイメージへのロードは、ＣｏｍｍｉｔＩＤによって規定される順序で実行されるので、この例では、ＭｏｄｉｆＩＤ＃３は、ＭｏｄｉｆＩＤ＃２よりも先にＡＩにロードされる（４６８）。コミット時に導入される関連付けられたＡＩｋｅｙが、ＡＩにおける対応する粒度の要素を決定する。

図５ａ〜５ｌは、ＭＦの同時更新を可能とし、ＡＩへのロードの複数起動処理を可能とする識別子の利用についてより詳細に説明する、ひと続きの例を示している。

図５ａでは、２つの運賃の取得によるマスターファイルの更新を示している。２つの新しい運賃（５１１）は、運賃データ提供者により、すなわちこの場合はＡＴＰＣＯにより、送信される。この新運賃の送信は、本発明による更新に相当し、図示の例では２００８年１月１日に発生する。そして、ロジスティック・テーブルにより、１番目の変更識別子が提供され（５１３）、ＭｏｄｉｆＩＤ＃２が次に提供可能な識別子となる（５１７）。２つの新運賃は、同じ識別子すなわちＭｏｄｉｆＩＤ＃１により識別されて、マスターファイルに書き込まれる（５１５）。

制限するものではないこの例において、データレコードのコヒーレント・セットは"ＮＣＥ／ＰＡＲ／ＡＦ／Ｆ ２００ユーロ, ｆｏｒ ｔｒａｖｅｌ ｄａｔｅ ｆｒｏｍ １０／０２／０８"と"ＮＣＥ／ＰＡＲ／ＡＦ／Ｃ １５０ユーロ, ｆｏｒ ｔｒａｖｅｌ ｄａｔｅ ｆｒｏｍ １５／０３／０８"からなる。このデータレコードのコヒーレント・セットは、２つの運賃と、各運賃がその日から適用可能となる日付と、関連する運賃クラス（"Ｆ"）とを含んでいる。データレコードのコヒーレント・セットは、各運賃について、つぎのようなフライトの参照を含んでいる： "出発地／目的地／航空会社名／サービスのカテゴリ"。また、データ提供者の参照も含んでいる。

この例では、ＭＦｋｅｙ（５１９）は、"ＮＣＥ／ＰＡＲ／ＡＦ／Ｆ"である。関連付けられた情報データは、旅行日および運賃（"２００ユーロ, ｆｏｒ ｔｒａｖｅｌ ｄａｔｅ ｆｒｏｍ １０／０２／０８"）であり、割り当てられた変更識別子は、"ＭｏｄｉｆＩＤ＃１"である。もう１つのＭＦｋｅｙ（５１９）は、"ＮＣＥ／ＰＡＲ／ＡＦ／Ｃ"である。関連付けられた情報データは、旅行日および運賃（"１５０ユーロ,ｆｏｒ ｔｒａｖｅｌ ｄａｔｅ ｆｒｏｍ １５／０３／０８"）である。これら２つの更新は、１つのデータのコヒーレント・セットに属するものであると見なされる。そのため、第１と第２のＭＦｋｅｙの両方に、同じ変更識別子（"ＭｏｄｉｆＩＤ＃１"）が関連付けられる。

図５ｂは、データベース・トランザクションがコミットされたとき（５２１）の処理を示している。ロジスティック・テーブル（ＬＴ）により、１番目のコミット識別子が割り当てられ（５２３）、これは、ＭｏｄｉｆＩＤ＃１に対応する上記２つのＭＦｋｅｙを参照している。そして、ＣｏｍｍｉｔＩＤ＃２が、次に割り当て可能なコミット識別子となる（５２５）。

図５ｃは、新しく送信された運賃をエンドユーザが見ることができるようにするために、アクティブイメージを同期させる方法を示している。保留されているコミット識別子が、ＬＴから取得されて、これによって、この保留されているコミット識別子（ＣｏｍｍｉｔＩＤ＃１）と関連付けられている変更識別子（ＭｏｄｉｆＩＤ＃１）によって特定される運賃の取り出し（５３３）がトリガされる。２つのＭＦｋｅｙが取り出されたら、これらがＡＩにロードされて、ＭＦとＡＩが同期された状態となる（５３５）。

そして、次に、ＡＩトランザクションがコミットされたときには（５３７）、新しく送信された運賃が、単一のＡＩｋｅｙ（５３９）という形で、データベースのエンドユーザに提供可能となる。この例では、ＡＩｋｅｙ（５３９）は、２つのＭＦｋｅｙに含まれるすべての情報データ（すなわち、"ＮＣＥ／ＰＡＲ／ＡＦ／Ｆ ２００ユーロ, ｆｏｒ ｔｒａｖｅｌ ｄａｔｅ ｆｒｏｍ １０／０２／０８"と"ＮＣＥ／ＰＡＲ／ＡＦ／Ｃ １５０ユーロ,ｆｏｒ ｔｒａｖｅｌ ｄａｔｅ ｆｒｏｍ １５／０３／０８"）と、同期の日付とを含んでいる。

図５ａ〜５ｃに示す動作は、すべて同日（５０１）に短時間で実行されたものである。

図５ｄおよび、これに続く２つの図は、後の２００８年３月１５日に（５０２）さらに受け取った運賃（５４１）の統合を示している。先の場合と同様に、新しく受け取った運賃には、これがＭＦに書き込まれる（５４５）より前に、最初に固有の変更識別子（ＭｏｄｉｆＩＤ＃２）が割り当てられる（５４３）。この新しい運賃は、既存のＭＦｋｅｙを参照しているので、当該ＭＦｋｅｙが図示のように更新されて（５４９）新しい運賃アイテムを含むようになる。ＭｏｄｉｆＩＤ＃３が、次に割り当て可能な変更識別子となる（５４７）。

図５ｅにおいて、データベース・トランザクションがコミットされると（５５１）、ＬＴによって、次のコミット識別子（ＣｏｍｍｉｔＩＤ＃２）が割り当てられる（５５３）。ＭＦｋｅｙは更新されて、ＭｏｄｉｆＩＤ＃１とＭｏｄｉｆＩＤ＃２に対応する変更を含むようになる（５５９）。そして、ＣｏｍｍｉｔＩＤ＃３が、次に割り当て可能なコミット識別子となる（５５５）。

図５ｆは、図５ｃに類似している。この場合の最終結果では、ＡＩｋｅｙ"ＮＣＥ／ＰＡＲ／ＡＦ"（５６８）は、今や新しくロードされた運賃をその時点の日付である適用日"１５／０３／０８"と共に、さらに含むようになっている（５６９）。

例は図５ｇに続いており、ここでは、二人の運賃提供者が後にＭＦを同時に更新している（この時点での日付は２００８年３月３０日である）。先に述べたように、航空運賃データベースの場合、運賃の出所は、ＡＴＰＣＯ（５７２）による送信である。運賃は、権限を与えられたデータベースのオペレータ（５７１）が専用のＧＵＩで直接入力することもできる。この特定の例において、最初に、ＧＵＩを介したトランザクションにＭｏｄｉｆＩＤ＃３が割り当てられ（５７３）、そしてＡＴＰＣＯによる送信にＭｏｄｉｆＩＤ＃４が割り当てられる（５７５）。これは、更新がまずＧＵＩを介して送信され、次に、ＡＴＰＣＯにより送信されたことを意味している。これらに相当する更新は、それぞれ、ＭＦｋｅｙ"ＮＣＥ／ＰＡＲ／ＡＦ／Ｆ／"の中（５７７）とＭＦｋｅｙ"ＮＣＥ／ＰＡＲ／ＡＦ／Ｃ／"の中（５７８）に見られる。

図５ｈに示すように、ＡＴＰＣＯによる更新が最初にコミットされて（５８１）、ＭｏｄｉｆＩＤ＃４（５８５）と関連付けられたＣｏｍｍｉｔＩＤ＃３（５８３）がＬＴにより割り当てられ、このとき、もう一方のＧＵＩを介したトランザクションは、まだ完了していない。

図５ｉは、ＧＵＩを介して行われた、さらなる更新を示している。今度は、ＭＦｋｅｙ"ＮＣＥ／ＰＡＲ／ＡＦ／Ｃ／"（５９１）と、ＧＵＩインタフェースを用いた運賃提供者に先に割り当てられたＭｏｄｉｆＩＤ＃３（５９３）とに関わる更新である。

図５ｊは、更新（５１０１）のコミットメント段階を示しており、ここでは、ＭｏｄｉｆＩＤ＃３と関連付けられたＣｏｍｍｉｔＩＤ＃４（５１０３）が、ＧＵＩを介したトランザクションに割り当てられる。

そして、先の例と同様に、次にＡＩリポジトリをＭＦに同期させる。図５ｋに示すように、この段階で、２つのコミット識別子、すなわち、ＣｏｍｍｉｔＩＤ３とＣｏｍｍｉｔＩＤ４（５１１１）が、ＬＴに保留されている。最初の１つが処理されることにより、これに対応する更新がＭＦから、つまりＭｏｄｉｆＩＤ＃４（５１１３）から取り出され、これにより、ＡＩを同期させる（５１１５）。

最後に、図５ｌに示すように、未だＬＴに保留されているＣｏｍｍｉｔＩＤ＃４（５１２１）が処理されることになる。これに対応する変更の２つのＭＦｋｅｙ（５１２３）がＭＦから取り出され、これを用いてＡＩを同期させる（５１２５）。

ＡＩの運賃リストの最後のアイテム、すなわち適用日付が"３０／０３／０８"である情報データが、この最後の例の同期によって上書きされたことに気づくであろう。図５ｋに示す前回の同期（５１１５）により設定された旅行日（"ｆｒｏｍ １８／０５／０８"）が、ＧＵＩを介したトランザクションにより後に行われた更新によって置き換えられており、これによって、旅行日が新しい値、すなわち"ｆｒｏｍ ２０／０５／０８"に変更されている。この例において、ＧＵＩインタフェースを用いる提供者は、例えば、ＡＴＰＣＯにより提供される更新と同じデータに関する更新を手動で提供することができる代理業者である。規則の訂正も手動で行うことができる。このようにして、ＧＵＩインタフェースからの更新とＡＴＰＣＯからの更新の両方を、同じＭＦｋｅｙに統合して、同じＡＩｋｅｙに伝播することができる。

変更がアクティブイメージによりユーザに提供可能となる順序は、コミット識別子によって決まる。このコミット識別子なしでは、同期が間違って行われる。すなわち、"ＮＣＥ／ＰＡＲ／ＡＦ／Ｃ"の旅行日が"ｆｒｏｍ ２０／０５／０８"ではなく"ｆｒｏｍ １８／０５／０８"となる恐れがある。

運賃データベースをリアルタイムで更新する上記の方法によると、実際に、膨大な数の運賃変更を受け入れることが可能である。ＡＴＰＣＯのような機関が、何百万もの運賃をそれらの関連規則と共にＧＤＳに転送しなければならないことは、往々にしてある。本発明の機構によると、新しい運賃を継続的に供給し、迅速に統合して、データベースのエンドユーザに提供可能とすることができ、この間の経過時間は、ほんの数分間である場合から、数百万の運賃が詰め込まれた最大運賃送信の場合の数時間まで、さまざまである。これは、エンドユーザによる運賃データベースへの問合せを継続しながらでも達成される。また、直接用ＧＵＩの複数起動の（通常、数百の）により実現されると考えられる、同時更新が可能であり、これによって、データベースの稼働中に、権限を与えられた運賃データベースのオペレータが更新を行うことも可能である。

例えば、本発明によると、ＡＴＰＣＯといったデータ提供者からの１回の送信から受け取る１，０００，０００の運賃と１００，０００の規則を３０分ほどで統合することが可能である。このような統合は、送信やＧＵＩを用いるユーザに影響を与えることなく達成される。

以上、運賃に関するデータのみを用いる例により、本発明について詳述したが、本発明はどのような種類のデータをリアルタイムで統合し伝播するためにでも実施できることは、当業者には明らかであろう。

Claims (11)

1. データベースシステム（２００）において大量の更新を統合する方法であって、該方法は以下を含んでいる：
   データ提供者（２２０）により供給される更新を、前記データベースシステム（２００）のマスターファイル（ＭＦ）（２１０）に統合することであって、この統合ステップは、以下のステップを含んでいる：
   前記マスターファイル（２１０）に前記更新を受け取る；
   前記マスターファイル（２１０）において、各更新についての、データレコードのコヒーレント・セット（５１１）を定義する；
   前記データレコードのコヒーレント・セット（５１１）を定義する際には、各更新に対して、前記データベースシステムのロジスティック・テーブル（３６０）により、前記データレコードのコヒーレント・セット（５１１）を一意的に識別するための固有の変更識別子を生成する；
   前記マスターファイル（２１０）において、前記変更識別子を受け入れる；
   前記マスターファイル（２１０）において、前記変更識別子を前記データレコードのコヒーレント・セット（５１１）に割り当てる；
   各更新のデータレコードのコヒーレント・セット（５１１）と、このデータレコードのコヒーレント・セット（５１１）に割り当てられた変更識別子とで、前記マスターファイル（２１０）を更新すること（５１５）により、各更新をコミットする；
   前記マスターファイル（２１０）にコミットされた各更新に対して、固有のコミット識別子（５２３）を前記ロジスティック・テーブル（３６０）からさらに取得する；前記コミット識別子（５２３）は、各更新の前記コミット・ステップが完了した順序を示す数である；
   前記更新を、前記データベースシステムのアクティブイメージ（ＡＩ）（２３０）にロードすることであって、このロード・ステップは、以下のステップを含んでいる：
   前記マスターファイル（２１０）から、各更新のデータレコードのコヒーレント・セットを取り出す（５３３）；
   前記コミット識別子により指定される順序で、次々と、各更新を前記アクティブイメージ（２３０）に伝播していくことにより、前記アクティブイメージ（２３０）と前記マスターファイル（２１０）を同期させる（５３５）；
   各更新に対応するデータレコードの各セットのロードが前記アクティブイメージ（２３０）でコミットされた（５３７）ときに、各更新の前記アクティブイメージ（２３０）への伝播を完了させる。
2. 前記データレコードのコヒーレント・セット（５１１）は、輸送サービスの出発地と目的地、運賃、サービス提供業者の参照、運賃クラス、および各運賃が適用される輸送時期を含んでいる、請求項１に記載の方法。
3. 各更新は、ＭＦキー（４６１、４６３、および４６５）と呼ばれる少なくとも１つの属性セットの形式で、前記マスターファイル（２１０）のテーブルに記憶され、前記ＭＦキーは、前記マスターファイル（２１０）のレコード粒度を決定するものであり、前記更新の情報データと関連付けられるものである、請求項１または２に記載の方法。
4. 前記ＭＦキーは、輸送サービスの出発地と目的地、サービス提供業者の参照、および運賃クラスを含んでおり、
   前記ＭＦキーは、運賃および各運賃が適用される輸送時期を含む情報データと関連付けられている、請求項１ないし３のいずれか１つに記載の方法。
5. 前記更新は、前記アクティブイメージ（ＡＩ）（２３０）のテーブルにロードされ、ＡＩキー（４６２、４６４、４６６）と呼ばれる１つ以上の属性セットの形式で記憶され、前記ＡＩキーは、前記アクティブイメージ（２３０）のレコード粒度を決定するものであり、前記更新の情報データと関係付けられるものである、請求項３または４に記載の方法。
6. １つのＡＩキーは、１つ以上のＭＦキーを含んでいる、請求項１ないし５のいずれか１つに記載の方法。
7. 前記ＡＩキーは、輸送サービスの出発地と目的地、サービス提供業者の参照を含んでおり、
   前記ＡＩキーは、運賃、運賃クラス、および各運賃が適用される輸送時期を含む情報データと関連付けられている、請求項５または６に記載の方法。
8. 前記マスターファイル（２１０）は、前記更新すべての履歴を含んでいる、請求項１ないし７のいずれか１つに記載の方法。
9. 前記マスターファイル（２１０）から前記アクティブイメージ（２３０）への前記更新の伝播は、前記ロジスティック・テーブル（３６０）による前記コミット識別子の割り当てによって、トリガされる、請求項１ないし８のいずれか１つに記載の方法。
10. 大量の更新を統合するためのデータベースシステム（２００）であって、マスターファイル（ＭＦ）（２１０）を有するマスターファイル・リポジトリと、アクティブイメージ（ＡＩ）（２３０）を有するアクティブイメージ・リポジトリとを備え、前記マスターファイル・リポジトリは、前記マスターファイル（２１０）が更新を受け取り、各更新についてのデータレコードのコヒーレント・セット（５１１）を定義するように、構成されていることを特徴とし、さらに、前記マスターファイル・リポジトリはロジスティック・テーブル（３６０）を備えており、これは、各更新に対して、前記データレコードのコヒーレント・セット（５１１）を定義する際に、このデータレコードのコヒーレント・セット（５１１）を一意的に識別するための固有の変更識別子を生成するように構成されていることを特徴とし、さらに、当該データベースシステム（２００）は、以下のステップを実行するように構成されている：
    前記マスターファイル（２１０）において、前記変更識別子を受け取り、この変更識別子を前記データレコードのコヒーレント・セット（５１１）に割り当てる；
    各更新のデータレコードのコヒーレント・セットと、このデータレコードのコヒーレント・セットに割り当てられた変更識別子とで、前記マスターファイル（２１０）を更新すること（５１５）により、各更新をコミットする；
    さらに、前記マスターファイル（２１０）でコミットされた各更新に対して、固有のコミット識別子（５２３）を前記ロジスティック・テーブル（３６０）から取得する；前記コミット識別子（５２３）は、各更新について前記コミット・ステップが完了した順序を示す数字である；
    前記更新を、前記アクティブイメージ・リポジトリの前記アクティブイメージ（ＡＩ）（２３０）にロードする；これは、各更新のデータレコードのコヒーレント・セットを前記マスターファイル（２１０）から取り出すこと（５３３）、前記コミット識別子により指定される順序で次々と各更新を前記アクティブイメージ（２３０）に伝播することにより、前記アクティブイメージ（２３０）と前記マスターファイル（２１０）を同期させること（５３５）、各更新に対応するデータレコードの各セットのロードが前記アクティブイメージ（２３０）でコミットされた（５３７）ときに、各更新の前記アクティブイメージ（２３０）への伝播を完了させること、を含んでいる。
11. コンピュータ読取り可能な記憶媒体（２０１）に記憶されたコンピュータプログラムであって、請求項１ないし８のいずれかに記載の、データベースシステムにおいて大量の更新を統合する方法を、少なくとも１つのコンピュータに実施させるコンピュータ読取り可能コードを有している、コンピュータプログラム。

Images