JP5492909B2 - リリース前に新規入力データを有する大規模プロダクションデータベースにおける大量の更新処理の検証を可能とする方法 - Google Patents

Description

本発明は、一般的に大規模データベースの更新処理に関し、さらに具体的にはリリース前に新規入力データを有する大規模プロダクションデータベース(production database)における検証を可能とする方法に関する。

ますます相互関連の度合いが増す世界において、商品やサービスの全ての大規模プロバイダは、その企業のプロダクト、サービスおよび世界的規模の業務上のオファーの特徴、仕様、およびコストを把握するために、大規模データベース、そして殆どの場合、超大規模データベースを構築する必要がある。データベース管理システム(DBMS)の制御下で扱われるコンテンツは、世界の各地における多くのオンライン顧客に対して、且つ更新されたデータベースのコンテンツの維持を担当する権限を与えられた管理者に対しても、同時にアクセスすることが可能な状態となっている。上記のような環境において、データベースは、リアルタイムで、1日24時間、1週7日間形態で、多くの場合、動作させる必要がある。

航空業界には、上記超大規模データベースのプラットフォームの例としては、その使用を限定するルールを伴った航空料金を管理するプラットフォームがある。料金データベースは、旅行サービスを旅行産業の全関係者に対して、且つさらに具体的には従来の旅行代理店に対するとともにもろもろのオンライン旅行サービスプロバイダに対しても提供している僅かにしか存在しない世界的規模のGDS(global distribution system)によって、主に構成されている。例えば、AMADEUSは、世界トップレベルのGDSである。

大規模料金プロバイダの一つが、多数の国内線および国際線の航空会社が所有している組織、ATPCO(airline tariff publishing company)である。ATPCOは、日に複数回、世界中の多数の航空会社の最新の航空料金を収集および配信している。別の料金プロバイダには、同じく国際組織であるSITAと呼ばれるものがある。ATPCOおよびSITAは、コンピュータ処理に適している電子形態にて、これらの料金に関連したあらゆるルールを含む料金データを提供している。航空会社によって提供され、且つATPCOおよびSITAによって符号化された料金およびルールは、航空会社の料金データベースで利用するために、前述したGDSに電子化されて送信される。

しかしながら、ATPCOおよびSITAは、GDS料金データベースのための料金情報源だけとして存在しているわけではない。AMADEUSのようなGDSも、ソフトウェアツールを提供している。そのソフトウェアは、サードパーティ料金プロバイダが、その料金および価格設定データベースプラットフォームに、直接料金を登録できるようにするものである。実際、航空会社によって、および航空会社に代わり旅行サービス会社によって、1日単位で設定される大量の料金は、随意契約料金である。公開料金とは反対に、随意契約料金は、例えば航空会社と、特定の旅行代理店又はプライベート利用目的の旅行団体との間で契約されたものである。その料金は、GDS料金データベースに、つまりATPCOおよびSITA経由で、しばしば直接登録される。

しかしながら、料金の直接登録処理が、一連の問題を伴わずに進行することはない。上記料金および価格設定データベースプラットフォームは、複雑、且つ超大規模なデータベースである。そのデータベースは、絶え間なく使用されるものであり、且つ更新処理中もリアルタイムな商取引を維持しなければならないものである。特に、その使用を限定するルールおよび利用可能な経路などの関連データを伴った新規料金を登録する処理は、利用可能な新規料金へと変更することができる一貫性のある更新データテーブルセットを実際に取得する以前に、多数のトランザクション全てが正常に完了する必要がある。

したがって、本発明の目的は、更新処理（すなわち、新規料金の入力）を進行している最中も通常稼動を阻害することなく、GDS料金データベースなどの大規模データベースを更新するための技術を記載することにある。新規料金が可視化され、且つデータベースのエンドユーザによって実際に利用可能な状態となる前に新規料金の検証を可能とすることが、本発明の具体的な目的である。

それゆえ、本発明は、大規模データベースにおける大量のデータ更新処理の問題に特に対処する。本発明において、大規模データベース、又は大規模プロダクションデータベースは、1テラバイト(1024ギガバイト)以上の容量を有するか又は、10億件以上有しているデータベースをさす。本発明において、大量の更新処理とは、1日あたり500,000件以上の更新処理、および／又は1日あたり数百万件の読み込みアクセス処理のフローを意味している。

その上、本発明の目的、特徴、および利点は、添付の図面を参照して以下の記載を精査することで、当業者に対して明らかなものとなる。いかなる付加的利点も本願明細書に援用されることを意図している。

本発明は、1又は2以上のソフトウェアアプリケーションによって同時に使用される大規模プロダクションデータベースに対して、リアルタイムにもたらされた大量の更新処理の完全性を保証する方法について記載する。上記プロダクションデータベースは、オブジェクトの定義条項に関係する複数のプロダクトを含む。上記プロダクションデータベースは、上記方法を以下のステップで実行するように手配されたマイクロプロセッサに接続されている。まず、上記方法は、プロダクションデータベースのエンドユーザに複数の更新処理が可視化しないようにする一方で、複数の更新処理のドラフト状態(draft state)バージョンに関連する固有の登録番号の発行を要求するステップを備える。次に、全てを固有の登録番号によって識別するプロダクト・アイテム群が、作成され、又はプロダクションデータベースから複製、プロダクションデータベースに記録、および複数の更新処理に適用されるメタ・プロダクト(meta-product)の形式で収集される。上記複製は、検証を経て更新されることが必須であるデータセットに限定される。更新処理が完了した場合、上記メタ・プロダクトを、複数の更新処理の相互検証を実行するため、1又は2以上の検証状態(validation state)のカスタマイズ可能なフローに正常に設定する。相互検証とは、複数の検証が実行されることを意味している。上記複数の検証は、同一又は異なる団体又はチームによって実行してもよい。上記複数の検証は、同一又は異なる検証ステップを備えていてもよい。相互検証は、複数のプロダクトに関係してもよい。その結果、価格計算処理で関係する多くの異なるプロダクトを更新することも、および一気に更新処理を全て検証することも許されている。相互検証は、実行された全更新処理の組み合わせを検証できるようにしてもよい。

最後に、検証が完了した場合、上記メタ・プロダクトは、実働状態(production state)に設定される。実働状態では、一意に識別されるメタ・プロダクトは、即座に可視化されるとともに、1又は2以上のソフトウェアアプリケーションのエンドユーザによって利用可能となる。

本発明は、場合によっては、以下の特徴のうち一つを備えていてもよい。
・大規模プロダクションデータベースは、1テラバイト(1024ギガバイト)以上の容量を有するか、又は10億件以上有している。
・大規模データベースは、1日あたり500,000件以上の更新処理要求、且つ望ましくは1日あたり200万件以上の更新処理要求を受信することが可能である。
・大規模データベースは、1日あたり500万件以上の読み込みアクセス要求、且つ望ましくは1日あたり1500万件以上の読み込みアクセス要求を受信することが可能である。
・1又は2以上の検証状態のカスタマイズ可能なフローは、マニュアル検証状態(manual validation state)を含む。本状態は、メタ・プロダクトの更新処理が許可されていない。
・1又は2以上の検証状態のカスタマイズ可能なフローは、応用検証状態(applicative validation state)を含む。本状態は、メタ・プロダクト形式で1又は2以上のソフトウェアアプリケーションをシミュレートすることを許可している。
・メタ・プロダクトは、メタ・プロダクト形式で1又は2以上のソフトウェアアプリケーションをシミュレートする必要のある非更新実働プロダクトのいずれかと結合される。
・応用検証状態は、更新およびメタ・プロダクトからのデータ削除を許可している。
・応用検証状態は、あたかも実働プロダクトかのように、1又は2以上のアプリケーションによってメタ・プロダクトを表示することを許可している。
・1又は2以上の検証状態のカスタマイズ可能なフローは、複数の更新処理の相互検証が失敗した場合、メタ・プロダクトをドラフト状態へ差し戻すことを許可している。
・1又は2以上の検証状態のカスタマイズ可能なフローは、メタ・プロダクトを実働状態に設定することを許可している。
・実働状態は、エキスパートチームのみがメタ・プロダクトを更新することを許可している。
・実働状態は、あらゆるプロダクトの更新処理を許可している。
・1又は2以上の検証状態のカスタマイズ可能なフローは、マニュアル検証状態のみを含む。
・プロダクションデータベースは料金のデータベースであり、且つ1又は2以上のソフトウェアアプリケーションは価格設定エンジンを具備している。

本発明は、コンピュータ読み取り可能記憶媒体に格納されたコンピュータプログラムにも関する。コンピュータ読み取り可能記憶媒体は、少なくとも1つのコンピュータにて前述の方法を動作させるためのコンピュータ読み取り可能コード手段を備える。

したがって、本発明は、検証コンテキストに対応する全データ、すなわち検証コンテキストにおいて更新されたデータ、および実働データを、価格設定トランザクションに提供することを目的として、データベースエンジンと価格設定トランザクションとの間に「レイヤ」を追加している。

本発明は、あらゆるデータベースの複製を必要としない。本発明は、データベースを増設する必要が無い。データベースが絶え間なく且つエンドユーザの要求に応答するために同時に使用されている最中でも、単一のデータベースにおいて大量の更新処理を行うことを可能とする。データの複製は、検証コンテキストにおいて更新される予定のデータセットに限定される。これは、システムの複雑化を増大させることなく、ユーザの更新処理をより容易とすることを目的としている。

本発明の他の目的は、少なくとも1つのプロダクションデータベースに格納された1又は2以上のデータ格納手段を具備するシステムである。上記システムは、データ格納手段に接続されるとともに、前述した方法を実行するように手配されたマイクロプロセッサも具備する。

本発明は、コンピュータ読み取り可能記憶媒体上に格納されたサーバサイド又はクライアントサイドのコンピュータプログラムにさらに関する。そのコンピュータプログラムは、コンピュータ読み取り可能コード手段、および少なくとも1つのコンピュータにて前述の方法を動作させるように手配されたマイクロプロセッサを備える。

本発明の更新処理技術を最良な形で適用した連続稼動可能な大規模データベースの例を示す図である。 更新処理が実働状態に設定されるまでその更新処理の可視性を制御する登録処理サイクルフロー中でも、連続稼動可能なデータベースのプロダクトを更新するように本発明によって用いられる手段を記載した図である。 対応する遷移を有する最大4つの状態からなる更新処理サイクルフローの例を示す図である。

本発明の以下の詳細な記載は、添付の図面を参照する。記載内容は例示的な実施形態である一方で、他の実施形態であることも可能であり、且つ本発明の精神および範囲を逸脱しないよう記載された実施形態を変形してもよい。

図１は、本発明の更新処理技術を最良な形で適用した連続稼動可能な大規模データベースの例を示している。

本発明を図示するために用いられた例示におけるデータベース(110)は、旅行ソリューションにおける価格設定を可能とする大規模なコンピュータ資源およびストレージ資源(150)を用いてGDSによって設定されるような料金データベースである。本実施形態は、本発明の理解を高めるために選択しているのであり、料金データベースに対し又は業務上のオファーに対して本発明を限定するものではない。

GDS資源は、インターネット(160)およびそれに対応する標準プロトコルの利用を含むネットワークのあらゆる組み合わせを介することで、オンラインで利用可能となっている。旅行者、旅行代理店の顧客に代わって、旅行関係の商取引を完了するために、例えば、GDSと提携している従来の旅行代理店から、価格設定要求(120)を受信する。価格設定要求は、前記サイトのエンドユーザによって選択された旅行ソリューションの価格設定をするため、多数のオンライン旅行サイトからも受信する。いずれの価格設定要求源であっても、GDSによって動作する価格設定エンジンアプリケーション(130)は、旅行ソリューションの料金を定めるため、料金データベースを利用する。価格設定要求は、コンピュータ端末から旅行代理店業者によって、および標準的なクライアントアプリケーション(すなわち、ウェブブラウザ又はナビゲータ(135))を介してパソコンから様々なオンライン旅行サイトにアクセスするエンドユーザによって、発行される。

それゆえ、本発明のコンテキストにおいて、「業務上のオファー」は、業界（例えば、航空業界）によって、ウェブサイト、旅行代理店、又は企業などそのような分散ネットワークに対してもたらされるあらゆる種別の料金請求を含んでいる。上記業務上のオファーは、価格設定トランザクションの広範囲にわたってGDSによって周知される。また、結果の数やコンテンツの条件(適切な最低価格X、又は旅行プランに利用可能な最低価格Xのような)において、様々な結果を条件とする様々な顧客のニーズに応答するための商取引とも呼ばれる。

背景技術に記載したように、新規料金は、日ごとに設定される。料金の直接登録処理は、標準的なクライアント／サーバ形態におけるGDSコンピュータ資源には含まれていない専用ソフトウェアプラットフォーム(140)を介して実施される。その結果、直接登録ソフトウェアプラットフォームは、随意契約料金をグラフィカル・ユーザー・インターフェース(GUI)を介して、対応するクライアントアプリケーション(145)から料金プロバイダが手動で登録できるようにしている。随意契約料金は、例えば航空会社と、旅行代理店との間で、そして一般的にはあらゆる料金プロバイダと、ATPCO又はSITAによって提供されるサービスを使用していないあらゆる旅行サービスプロバイダとの間で、結ばれた合意および契約の結果である。

新規料金の導入は、リアルタイムで実施されなければならない。一方で、本願明細書で前述した旅行代理店およびオンライン旅行サイトから、すなわち旅行代理店業者および前記サイトの個人エンドユーザ(122)によって発行された業務上の要求(120)に応答するため、価格設定エンジン(130)を介して絶え間なくクエリなどの問合せがなされているデータベースの通常稼動を妨げてはならない。上記料金データベースは、いくつかの要素からなる、以後プロダクトとして称する。上記プロダクトは、例えば、前述した実施形態における世界的規模の業務上のオファーといったオブジェクトの定義条項に関係している。上記プロダクトは、業務上有用となる有効な料金を最終的に取得するため、絶え間なく更新されていなければならない。上記プロダクトは、データベースとの独立した専用トランザクション(144)を介して更新される。トランザクションは、GDSによって提供された直接登録ソフトウェアプラットフォーム(140)介し、料金を入力、更新又は削除することを担当している人によって発行される。以降では、その担当者たちを、概して登録処理チーム(142)と称する。データの作成、更新、又は削除は、手動で実行される。上記プロダクトは、新規料金で購入する際に適用される制限事項の形式で随意契約の諸条件を言い換えたルール(112)を含む。新規料金が適用される経路は、第2のプロダクト(114)として定義されている。一方、個別の料金総額は、第3のプロダクト(116)である。少なくとも更新するプロダクトと、同じくらいの発行されるトランザクションが存在する。その結果、主な問題が、新規料金が設定されている最中に全プロダクトの変更が価格設定エンジン(130)に対し即座に可視化される、ということがそのまま残ることになる。全プロダクトが新規料金に対し一貫性が存在する形で更新されるとともに既に存在する料金と互換性があるように必ずしも全トランザクションが実際に完了しないというのであれば、このことは、一貫性が存在しない要因となる可能性がある。

全更新が即座に可視化状態になるということに関連した他の問題は、新規価格の検証が実際にはなされない可能性が存在するということである。航空料金は、特に複雑で、且つ多数のルールの適用が前提となっている。しかしながら、随意契約料金の関係者(例えば、航空会社および旅行代理店)は、実際に通常商取引で即座に利用可能とならない限り、どのように契約が新規料金に変わったかを、都合よく確認することはできない。新規料金を、予め登録処理チームによって、言い換えれば、リリースされるとともに実働状態の形態となる予定日より前に、実施および検証することはできない。

図2は、更新処理が実働状態に設定されるまでその更新処理の可視性を制御する登録処理サイクルフロー中でも、連続稼動可能なデータベースのプロダクトを更新するように本発明によって用いられている手段を記載した図である。

ある世界的規模の商取引に関連したいくつかのプロダクト上における更新処理の一貫性は、登録番号(210)を用いることによって達成される。上記登録番号は、一意であり、且つ、更に言えば、その正当性は、登録番号が属する登録処理サイクルフロー(220)に対して関連付けられている。上記登録番号は、データベースにて定義されたあらゆるプロダクトに実施されたあらゆる更新処理に対して付加されている。それゆえ、登録番号は、更新処理群の中から特定の更新処理を一意に識別する。したがって、同一の登録番号がタグ付けされたデータ全ては、システムによって固有のエンティティとして扱われるメタ・プロダクト(230)の形式となる。登録処理チームは、更新処理群の識別およびその機能的一貫性に責任を負っている。

登録処理サイクルフロー(220)は、状態と遷移とでできている。
・状態(240)は、登録番号(210)に関連付けられている。上記登録番号によって識別するデータセット(230)について実施することができるアクションを決定する。登録処理サイクルフローの最終状態は、更新処理が実働状態に設定されるデータの公開(260)に相当する。上記状態に至ると、登録番号は使用しなくなる。新規の固有の登録番号は、より多くの更新処理を処理しなければならない場合に必要となる。
・遷移(250)は、データセットの状態を別の状態に変更するアクションである。さらに以下で述べるように、ある状態から、更新処理が最終的に実働状態となる前段階である他の中間状態に至ることを目的として、いくつか遷移を登録処理チームに対して提示している。あらゆる状態から実働状態のデータを公開することが常に可能であるとともに、もし更新処理セッションをキャンセルすべきであるならば、対応する全データセットを削除することが常に可能である。既に実働状態(200-260)にあるデータだけは、それらのデータを価格と販売チケットとして既に使用してもよいので、システムから削除することはできない。

状態と遷移の前述の概念に基づいて、ある特定の登録処理チームのニーズやその組織の働き方に合うように、登録処理サイクルフローをカスタマイズしてもよい。このような理由で、上記フローは、カスタマイズ可能なフローと称されている。上記カスタマイズ可能なフローの検証状態については、図３において更に述べる。

システムの一貫性を保証するためには、以下のことを介していくつかの制限事項が適用される。
・各マスターファイル(あるプロダクトのためのデータベースのテーブルセット)における更新処理の粒度は、Mkey(270)と称する一連の識別子フィールドによって決定される。場合によっては、所定のデータセット(230)において、ある時刻におけるただ1つのサイクルの更新処理がアクティブとなるように、ただ1つの登録番号(210)をMkeyと関連付けてもよい。
・あらゆる新規登録処理は、もし存在するのであれば、既存データ(200)から常に開始しなければならない。進行中の登録処理サイクルフローの終了では、新規データは、旧データと結合される。それらには一貫性が維持されている必要がある。

実施形態の観点では、状態(240)は、データベースのテーブルに格納されているフィールドである。それは、データセットを固有の登録番号によって識別させるのに適している。登録番号と状態の関係は、別のテーブルに格納されている。既知の登録番号に対する上記状態が更新されるたびに、新規関係は、作成されるとともに、登録処理サイクルフロー(220)に保存される。登録番号は、登録処理リサイクルフローの初期段階で設定されるとともに、データベース中のいくつかのプロダクトに関する更新処理群を識別するため登録処理チームによって使用される。直近に設定された登録番号は、専用のテーブルに格納される。

プロダクトサイドにおいて、新規バージョンが、登録処理リサイクルフローの初期段階で、各Mkey(270)用に作成される。前記Mkeyは、マスターファイルに既に存在していない場合においては新規Mkeyとなるか、実働状態の既存データの複製であるかのどちらかである。終始登録処理リサイクルフローでは、データの最終更新のみ、データベースに保存される。既知の登録番号に対して、ただ1つのMkeyのバージョンが存在する。しかしながら、プロダクトのいくつかのMkeyは、同一の登録番号によって識別される可能性がある。

図３でさらに述べるように、それゆえ、本発明の登録処理システムは、新規料金がリリースされ且つ実働状態として使用されることの前段階である中間検証状態の適した数を有することによって、ある組織において新規料金を作成することを担当している登録処理チームが、それらが属する組織のニーズに合うように登録処理リサイクルフロー(220)のカスタマイズを可能とするには十分なほどオープン且つフレキシブルになっている。上記登録処理アクティビティの管理は、プロダクションデータベース内で直接行われる。既知のデータセットのため、2つのバージョンが一緒にデータベース内に存在してもよい。1つは、実働アクティビティに対応するものであり、1つは、登録処理アクティビティに対応するものである。検証においてバージョンが上がれば、それが価格設定エンジンによって対象とされる新規バージョンとなる。

登録処理の上記方法は、多くの利点を有している。上記データベースは、複製を用意する必要がない。更新されたプロダクトは、2つバージョンに存在するのみである。実際には、本発明によって解決される問題に対する可能な解決策には、予備の複製データベースを有することも考えられる。予備のデータベースを、定期的にアクティブなデータベースと切り替えて、入れ替わりに実働状態とする以前には、予備のデータベースでは全更新が行われるとともにキャッシュされる。上記方法の実施には、本発明と比べて欠点が存在している。実際には、上記解決策は、2つの大規模且つ複雑なデータベースを管理する必要がある。また、本発明の登録処理システムのフレキシブルさとは違って、データベースのエンドユーザに可視化されるようにするため次の定期的な切り替わりを待つ必要があるので、更新処理がチェックを完全に終了したとしても同時に実働状態とすることができなくなる。

また、登録処理チームは、データベースに定義された全てのプロダクト用のバージョンを作成する必要はない、ただし更新されるはずのプロダクト用のバージョンは除く。プロダクトは全てが更新されないにもかかわらず、更新処理の検証を通常通りに実施することが可能である。このような場合、本発明の登録処理システムは、検証を実施することが必須である上記非更新プロダクトをまさに回収する。したがって、必須の非更新プロダクトおよび更新プロダクトは、更新プロダクトの検証を可能とするために、結合される。

本発明を図示するために用いられた例示において、ルールプロダクト(232)と料金プロダクト(236)のみが更新される必要があるならば、その結果、本実施形態の他の非更新プロダクト、すなわち経路プロダクト(234)は、固有の登録番号(210)によって識別するメタ・プロダクト中に実際には(図2に示されるように)含まれる必要はないということになる。上記のケースにおいて、本発明の登録処理システムは、更新処理の検証を実施するため、非更新プロダクト(204)の実働バージョン(production version)の代わりにデフォルトでまさに選別する。このことは、データベース中に役に立たないデータの作成を回避している。言い換えれば、更新しない場合の実働バージョンの複製を回避している。

図3は、対応する遷移を有する最大4つの状態からなる登録処理サイクルフローの例を示す図である。

定義された状態を以下に示す。

上記で例示した登録処理サイクルは、任意の組織のニーズに適合させてもよい。状態の数は、限定されない。新規要求を考慮してもよいし、必要であれば、新規状態を追加してもよい。状態は、データを更新、削除、処理、又はただ単に読み取りできるように、データ上で許可するアクションを定義している。また、許可された状態から状態への遷移は、登録処理サイクルの定義条項の一部である。新規状態の定義条項は、既存のフローに対して一貫性がなければならない。且つ、新規アクションの開発を暗に含むものであってもよい。

図3の例示的な登録処理サイクルは、検証状態がただ1つしか存在しない符号350に示すような単純化をしてもよい。その上、既に前述した単一の実働状態は、符号360で見られる。そこでは、更新処理がレガシーシステムと同様に価格設定に対し即座に反映される。

それゆえ、前述のデータベースの登録処理システムは、データベースの更新処理を符号360のように即座に行うことすら可能なので、登録処理チームおよびその組織が競争相手に対しリアルタイムに応答する能力をレガシーシステムのまま保持している。

しかし、新規契約の登録処理は、任意の組織の管理ニーズに合うようにできるオプションとしての準備および検証の段階を含んでいてもよい。
・上記新規契約の登録処理は、入力に数日にも及びかねない大量のデータ容量で表わしてもよい。その一方で、本発明の登録処理システムは、新規入力データが価格設定エンジンによってアクセスされることを防止している。
・全契約がデータベースに登録された時点で、契約を公開する以前に実際の実働環境にて内容をさらに完全にチェックしてもよい。本発明を記載するにあたり用いた例示的な料金データベースにおいて、この部分は、旅行業界のクライアント会社のエキスパートによって、又は登録処理が適用除外されている場合は航空会社自身によって、ほとんど行われる。マニュアル検証と呼ばれる単純化した検証を備える登録処理サイクル(350)を、データベースに格納されたデータの参照、又は報告としてデータベースからの抽出したものに基づいて実施してもよい。応用検証状態(330)と呼ばれる追加の検証を、既に公開されているかのように価格設定エンジンによるデータの実処理に基づいて、同様にオプションとして実施してもよい。
・最後に、本発明のデータベース登録処理システムは、契約を予め安全に準備できるように且つ場合によっては最終状態(実働状態)とならない間は非可視化となるように、登録処理チーム又はエキスパートチームに、検証が完了した後であればいつでも新規契約の公開を制御することを認めている。
・本発明の提供する機能強化は特に航空業界で有利であるとはいえ、本発明の範囲は、電車、自動車、バス、フェリーなどの他の輸送手段にまで及ぶ。その結果、更新されるデータは、空、地、鉄道、又は海の産物に関連した料金に相当するものであってもよい。

前述した実施形態は、2テラバイト、1256テーブル、1774インデックスを有し、240万件以上の更新処理、および2300万の読み込みアクセスが一日で行われるという特徴を有する、単一のデータベース中の大量のデータの更新処理において非常に効果的であることが分かる。

本発明の範囲は、ホテル業界にも及ぶとともに、更新されるデータは、ホテル料金／相場に相当する。本発明は料金および業務上のオファーに関連して上記されているが、その範囲は、リアルタイムでプロダクションデータベースにもたらされる更新の完全性を保証する利点が存在するあらゆる種類のデータに及ぶ。例えば、プロダクションデータベースは、工業生産プロセスの定義条項に関係するプロダクトを含んでいてもよい。このような場合、エンドユーザは、工業機械、又は技術者となる。

310 ドラフト状態
320 マニュアル検証状態
330 応用検証状態
340 実働状態
312 登録処理チーム
322, 332, 342 エキスパートチーム

Claims (15)

1. 大規模プロダクションデータベース(110)をリアルタイムで1又は2以上のソフトウェアアプリケーション(130)を同時に使用できるようにする複数の更新処理の完全性を保証する方法であって、前記大規模プロダクションデータベースは業務上のオファーの定義条項に関連する複数のプロダクト(112, 114, 116)を含み、
   前記方法は、
   前記大規模プロダクションデータベースのエンドユーザ(122)に前記複数の更新処理が可視化しないようにしつつ、前記複数の更新処理を前記複数の更新処理のドラフト状態バージョン(310)に関連する固有の登録番号の発行を要求するステップと、
   前記大規模プロダクションデータベースにおいて、更新処理および検証を行うためのプロダクト・アイテム群(230)を前記大規模プロダクションデータベースから作成又は複製をするステップとを有し、
   前記プロダクト・アイテム群は、全てを固有の登録番号(210)によって識別されるとともに、複数の更新処理に適用されるメタ・プロダクトの形式で収集され、
   前記メタ・プロダクトの更新処理が完了した場合は、少なくとも前記複数の更新処理の検証を実行することを目的として、前記メタ・プロダクトを1又は2以上の検証状態(320, 330)のフローへと引き続き設定するステップと、
   前記メタ・プロダクトの検証が完了した場合は、即座に可視化されるとともに、前記1又は2以上のソフトウェアアプリケーション(130)の前記エンドユーザ(122)によって使用される一意に識別された前記メタ・プロダクトを実働状態(340)に設定するステップとを有することを特徴とする方法。
2. 前記1又は2以上の検証状態のフローは、前記メタ・プロダクトの更新処理を許可していないマニュアル検証状態(320)を含むことを特徴とする請求項1に記載の方法。
3. 前記1又は2以上の検証状態のフローは、前記メタ・プロダクト形式で前記1又は2以上のソフトウェアアプリケーションをシミュレートすることを許可している応用検証状態(330)を含むことを特徴とする請求項1又は請求項2のいずれか1項に記載の方法。
4. 前記メタ・プロダクトは、前記メタ・プロダクト形式で前記1又は2以上のソフトウェアアプリケーションをシミュレートする必要のある非更新実働プロダクトのいずれかと結合されることを特徴とする請求項3に記載の方法。
5. 前記応用検証状態は、データの更新および前記メタ・プロダクトからのデータ削除(334)を許可されていることを特徴とする請求項3に記載の方法。
6. 前記応用検証状態は、あたかも実働プロダクトかのように、前記メタ・プロダクトを前記1又は2以上のソフトウェアアプリケーションによって表示することを特徴とする請求項3に記載の方法。
7. 前記1又は2以上の検証状態のフローは、前記複数の更新処理の検証が失敗した場合、前記メタ・プロダクトを前記ドラフト状態への差し戻し(324, 336)を許可していることを特徴とする請求項1乃至請求項6のいずれか1項に記載の方法。
8. 前記1又は2以上の検証状態のフローは、前記メタ・プロダクトを前記実働状態へ設定すること(328, 338)を許可していることを特徴とする請求項1乃至請求項7のいずれか1項に記載の方法。
9. 前記実働状態は、エキスパートチームのみが前記メタ・プロダクトを更新すること(342)を許可していることを特徴とする請求項1乃至請求項8のいずれか1項に記載の方法。
10. 前記実働状態は、あらゆるプロダクトの更新処理(342)を許可していることを特徴とする請求項9に記載の方法。
11. 前記1又は2以上の検証状態のフローは、マニュアル検証状態のみを含むこと(350)を特徴とする請求項1に記載の方法。
12. 前記大規模プロダクションデータベースは、料金データベース(110)であるとともに、
    前記1又は2以上のソフトウェアアプリケーションは、価格設定エンジン(130)を具備すること特徴とする請求項1乃至請求項11のいずれか1項に記載の方法。
13. 前記フローは、カスタマイズ可能であることを特徴とする請求項1乃至請求項12のいずれか1項に記載の方法。
14. 前記大規模プロダクションデータベースは、1テラバイト以上の容量を有するか又は、10億件以上有していることを特徴とする請求項1乃至請求項13のいずれか1項に記載の方法。
15. コンピュータ読み取り可能記憶媒体上に格納されたコンピュータプログラムであって、請求項1乃至請求項14のいずれか1項に記載の方法を少なくとも1つのコンピュータによって動作させるようにするためのコンピュータプログラム。

Images