(57)【特許請求の範囲】
【請求項１】
複数のプロセス状態を有する組織的プロセスの複数のインスタンスについての情報のサマリーを作成するために、複数のデータベース・レコードからのデータを集約する方法であって、前記複数のデータベース・レコードの各々は前記組織的プロセスの複数のインスタンスの１つに対応しかつ当該レコードに対応する組織的プロセスの特性を表すデータを含み、当該複数のインスタンスの１つの前記複数のプロセス状態の１つを示す値を含むフィールドを有し、前記方法は少なくとも１つのコンピュータにおいて複数のプログラミング・スレッドにより実施され、前記方法は、
複数の区画を含む少なくとも１つの集約テーブルを作成するステップであって、前記区画の各々は複数の集約レコードを含み、前記集約レコードの各々は前記複数のデータベース・レコードの内の何れかのデータベース・レコードのフィールドに収められた値の集約を表す集約値を含む、ステップと、
前記複数のデータベース・レコードの内の第１のデータベース・レコードの挿入または更新があった後に、前記複数の区画のうちの第１の区画を選択するステップであって、前記複数のプログラミング・スレッドのうちの前記複数の区画のうちの１つへアクセスして前記複数のデータベース・レコードの内の第１のデータベース・レコードの挿入または更新を前記集約値に反映する第１のプログラミング・スレッドからの要求に応答して、当該第１のプログラミング・スレッドを識別するシステム識別子に基づいて前記第１の区画を選択し、ここで当該第１の区画は当該第１のプログラミング・スレッドを識別するシステム識別子の前記複数の区画の数の剰余に等しい識別子を有しており、前記第１のプログラミング・スレッドが前記第１の区画へアクセスする必要がなくなるまで、前記複数の区画と同数の行を有するテーブル中の前記第１のプログラミング・スレッドを識別するシステム識別子の前記複数の区画の数の剰余に等しい行にマーキングして、他のプログラミング・スレッドが前記第１の区画へアクセスすることを防止する、ステップと、
前記第１のプログラミング・スレッドが、前記挿入または更新があった第１のデータベース・レコード内の１つまたは複数の値に基づく前記第１の区画の更新トランザクションとして、前記第１の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新するステップと、
前記第１の区画の更新トランザクションを実行している間に、前記複数の区画のうちの第２の区画を選択するステップであって、前記複数のプログラミング・スレッドのうちの前記複数の区画のうちの１つへアクセスする第２のプログラミング・スレッドからの要求に応答して、前記第２のプログラミング・スレッドを識別するシステム識別子に基づいて前記第２の区画を選択する、ステップと、
前記第２のプログラミング・スレッドが、挿入または更新があった第２のデータベース・レコード内の１つまたは複数の値に基づく前記第２の区画の更新トランザクションとして、前記第１の区画の更新トランザクションの実行中に、前記第２の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新するステップと、
前記複数の区画の複数の集約値を集約し、当該集約された集約値を前記組織的プロセスの複数のインスタンスについての情報のサマリー出力するステップと
を備えることを特徴とする方法。
【請求項２】
前記少なくとも１つの集約テーブルを作成するステップは、互いに独立した複数の独立集約テーブルを作成するステップであり、前記複数の区画の各々は、前記複数の独立集約テーブルの１つに含まれることを特徴とする請求項１に記載の方法。
【請求項３】
前記複数のデータベース・レコードの内の前記第１のデータベース・レコードの前記挿入または更新の後に前記第１のデータベース・レコードの次の更新があったときに、前記複数の区画のうちの第３の区画を選択するステップであって、前記複数のプログラミング・スレッドのうちの前記複数の区画のうちの１つへアクセスする第３のプログラミング・スレッドからの要求に応答して、前記第３のプログラミング・スレッドを識別するシステム識別子に基づいて前記第３の区画を選択するステップと、
前記第３のプログラミング・スレッドが、前記次の更新により更新された第１のデータベース・レコード内の１つまたは複数の値に基づく前記第３の区画の更新トランザクションとして、前記第３の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新するステップと
をさらに備えることを特徴とする請求項１に記載の方法。
【請求項４】
前記複数の集約値を集約するステップは、複数のレコードを有する単一テーブルを生成し、前記単一テーブルの各レコードに、前記複数の区画のそれぞれの前記集約レコードの複数の値を集約することを特徴とする請求項１に記載の方法。
【請求項５】
少なくとも１つの集約テーブルを作成する前記ステップは、少なくとも３つの区画を作成することを含むことを特徴とする請求項１に記載の方法。
【請求項６】
少なくとも１つの集約テーブルを作成する前記ステップは、少なくとも１０個の区画を作成することを含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記方法の各ステップは少なくとも１つのプロセッサを有するコンピュータで使用され、少なくとも１つの集約テーブルを作成する前記ステップは、前記コンピュータが有するプロセッサの数を越える数の区画を作成することを特徴とする請求項１に記載の方法。
【請求項８】
前記区画へアクセスする前記第１のプログラミング・スレッドからの前記要求を受け取ると、前記第１のプログラム・スレッドを識別するシステム識別子を取得するステップと、
前記取得されたシステム識別子に基づいて、前記第１のプログラム・スレッドへ前記第１の区画の識別子を割り当てるステップと
をさらに備えることを特徴とする請求項１に記載の方法。
【請求項９】
各区画は、時間で分類された集約レコードを含み、時間で分類された各集約レコードは、前記時間で分類された集約レコードに関連付けられた期間中の、前記複数のプロセス状態のうちの１つのプロセス状態にある複数のインスタンスに対する集約値を含む
ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記複数のプロセス状態のうちの１つのプロセス状態は、インスタンスが完了していることを含み、
前記第１の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新する前記ステップは、前記更新後の集約値から、事前選択された時間枠外にある完了した複数のインスタンスに対応するレコードの影響が除外されるように、前記時間で分類された集約レコードの複数の集約値を更新するステップ
を備えることを特徴とする請求項９に記載の方法。
【請求項１１】
複数のプロセス状態を有する組織的プロセスの複数のインスタンスについての情報のサマリーを作成するために、複数のデータベース・レコードからのデータを集約する方法であり、前記複数のデータベース・レコードの各々は前記組織的プロセスの複数のインスタンスの１つに対応しかつ当該レコードに対応する組織的プロセスの特性を表すデータを含み、当該複数のインスタンスの１つの前記複数のプロセス状態の１つを示す値を含むフィールドを有し、少なくとも１つのコンピュータにおいて複数のプログラミング・スレッドの実行により実施される方法を、プロセッサに実行させるプログラムを記録した記録媒体において、
前記プログラムは、前記プロセッサに、
複数の区画を含む少なくとも１つの集約テーブルを作成するステップであって、前記区画の各々は複数の集約レコードを含み、前記集約レコードの各々は前記複数のデータベース・レコードの内の何れかのデータベース・レコードのフィールドに含まれた値を集約した集約値を含む、ステップと、
前記複数のデータベース・レコードの内の第１のデータベース・レコードの挿入または更新があった後に、前記複数の区画のうちの第１の区画を選択するステップであって、前記複数のプログラミング・スレッドのうちの前記複数の区画のうちの１つへアクセスして前記複数のデータベース・レコードの内の第１のデータベース・レコードの挿入または更新を前記集約値に反映する第１のプログラミング・スレッドからの要求に応答して、当該第１のプログラミング・スレッドを識別するシステム識別子に基づいて前記第１の区画を選択し、ここで当該第１の区画は当該第１のプログラミング・スレッドを識別するシステム識別子の前記複数の区画の数の剰余に等しい区画ＩＤを有しており、前記第１のプログラミング・スレッドが前記第１の区画へアクセスする必要がなくなるまで、前記複数の区画と同数の行を有するテーブル中の前記第１のプログラミング・スレッドを識別するシステム識別子の前記複数の区画の数の剰余に等しい行にマーキングして、他のプログラミング・スレッドが前記第１の区画へアクセスすることを防止する、ステップと、
前記第１のプログラミング・スレッドが、前記挿入または更新があった第１のデータベース・レコード内の１つまたは複数の値に基づく前記第１の区画の更新トランザクションとして、前記第１の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新するステップと、
前記第１の区画の更新トランザクションを実行している間に、前記複数の区画のうちの第２の区画を選択するステップであって、前記複数のプログラミング・スレッドのうちの前記複数の区画のうちの１つへアクセスする第２のプログラミング・スレッドからの要求に応答して、前記第２のプログラミング・スレッドを識別するシステム識別子に基づいて前記第２の区画を選択する、ステップと、
前記第２のプログラミング・スレッドが、挿入または更新があった第２のデータベース・レコード内の１つまたは複数の値に基づく前記第２の区画の更新トランザクションとして、前記第１の区画の更新トランザクションの実行中に、前記第２の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新するステップと、
前記複数の区画の複数の集約値を集約し、当該集約された集約値を前記組織的プロセスの複数のインスタンスについての情報のサマリー出力するステップと
を実行させることを特徴とする記録媒体。
【請求項１２】
前記少なくとも１つの集約テーブルを作成するステップは、互いに独立した複数の独立集約テーブルを作成するステップであり、前記複数の区画の各々は、前記複数の独立集約テーブルの１つに含まれることを特徴とする請求項１１に記載の記録媒体。
【請求項１３】
前記プログラムは、前記プロセッサに、
前記複数のデータベース・レコードの内の前記第１のデータベース・レコードの前記挿入または更新の後に前記第１のデータベース・レコードの次の更新があったときに、前記複数の区画のうちの第３の区画を選択するステップであって、前記複数のプログラミング・スレッドのうちの前記複数の区画のうちの１つへアクセスする第３のプログラミング・スレッドからの要求に応答して、前記第３のプログラミング・スレッドを識別するシステム識別子に基づいて前記第３の区画を選択するステップと、
前記第３のプログラミング・スレッドが、前記次の更新により更新された第１のデータベース・レコード内の１つまたは複数の値に基づく前記第３の区画の更新トランザクションとして、前記第３の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新するステップと
をさらに実行させることを特徴とする請求項１１に記載の記録媒体。
【請求項１４】
前記複数の集約値を集約するステップは、複数レコードを有する単一テーブルを生成し、前記単一テーブルの各レコードに、前記複数の区画のそれぞれの前記集約レコードの複数の値を集約することを特徴とする請求項１１に記載の記録媒体。
【請求項１５】
少なくとも１つの集約テーブルを作成する前記ステップは、少なくとも３つの区画を作成することを含むことを特徴とする請求項１１に記載の記録媒体。
【請求項１６】
少なくとも１つの集約テーブルを作成する前記ステップは、少なくとも１０個の区画を作成することを含むことを特徴とする請求項１１に記載の記録媒体。
【請求項１７】
前記プログラムは、前記プロセッサに、
前記区画へアクセスする前記第１のプログラミング・スレッドからの前記要求を受け取ると、前記第１のプログラム・スレッドを識別するシステム識別子を取得するステップと、
前記取得されたシステム識別子に基づいて、前記第１のプログラム・スレッドへ前記第１の区画の識別子を割り当てるステップと
をさらに実行させることを特徴とする請求項１１に記載の記録媒体。
【請求項１８】
前記プロセスの複数の状態の１つはインスタンスが完了している状態に対応し、前記複数のデータベース・レコードの各々は完了時刻フィールドを含み、前記プルグラムは、前記プロセッサに、
前記第１の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新する前記ステップにおいて、前記更新後の集約値から、事前選択された時間枠外にある完了した複数のインスタンスに対応するレコードの影響が除外されるように、時間で分類された集約レコードの複数の集約値を更新させることを特徴とする請求項１１に記載の記録媒体。
【請求項１９】
複数のプロセス状態を有する組織的プロセスの複数のインスタンスについての情報のサマリーを作成するために、複数のデータベース・レコードのフィールドからのデータを集約するデータ処理装置であって、前記複数のデータベース・レコードの各々は前記組織的プロセスの複数のインスタンスの１つに対応しかつ当該レコードに対応する組織的プロセスの特性を表すデータを含み、当該複数のインスタンスの１つの前記複数のプロセス状態の１つを示す値を含むフィールドを有し、前記データ処理装置は、
少なくとも１つのデータ記憶装置と、
少なくとも１つのユーザ入力装置と、
前記記憶装置と前記ユーザ入力装置に動作可能に結合されたプロセッサと
を備え、
前記少なくとも１つのデータ記憶装置は、
複数の区画を含む少なくとも１つの集約テーブルを作成するステップであって、前記区画の各々は複数の集約レコードを含み、前記集約レコードの各々は前記複数のデータベース・レコードの内の何れかのデータベース・レコードのフィールドに収められた値の集約を表す集約値を含む、ステップと、
前記複数のデータベース・レコードの内の第１のデータベース・レコードの挿入または更新があった後に、前記複数の区画のうちの第１の区画を選択するステップであって、前記複数の区画のうちの１つへアクセスして前記複数のデータベース・レコードの内の第１のデータベース・レコードの挿入または更新を前記集約値に反映する前記複数のプログラミング・スレッドのうちの第１のプログラミング・スレッドからの要求に応答して、当該第１のプログラミング・スレッドを識別するシステム識別子に基づいて前記第１の区画を選択し、ここで当該第１の区画は当該第１のプログラミング・スレッドを識別するシステム識別子の前記複数の区画の数の剰余に等しい識別子を有しており、前記第１のプログラミング・スレッドが前記第１の区画へアクセスする必要がなくなるまで、前記複数の区画と同数の行を有するテーブル中の前記第１のプログラミング・スレッドを識別するシステム識別子の前記複数の区画の数の剰余に等しい行にマーキングして、他のプログラミング・スレッドが前記第１の区画へアクセスすることを防止する、ステップと、
前記第１のプログラミング・スレッドが、前記挿入または更新があった第１のデータベース・レコード内の１つまたは複数の値に基づく前記第１の区画の更新トランザクションとして、前記第１の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新するステップと、
前記第１の区画の更新トランザクションを実行している間に、前記複数の区画のうちの第２の区画を選択するステップであって、前記複数のプログラミング・スレッドのうちの前記複数の区画のうちの１つへアクセスする第２のプログラミング・スレッドからの要求に応答して、前記第２のプログラミング・スレッドを識別するシステム識別子に基づいて前記第２の区画を選択する、ステップと、
前記第２のプログラミング・スレッドが、挿入または更新があった第２のデータベース・レコード内の１つまたは複数の値に基づく前記第２の区画の更新トランザクションとして、前記第１の区画の更新トランザクションの実行中に、前記第２の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新するステップと、
前記複数の区画の複数の集約値を集約し、当該集約された集約値を前記組織的プロセスの複数のインスタンスについての情報のサマリー出力するステップと
を前記プロセッサに実行させるプログラムを記憶している
ことを特徴とするデータ処理装置。
【請求項２０】
前記プログラムは、前記プロセッサに、
前記複数のデータベース・レコードの内の前記第１のデータベース・レコードの前記挿入または更新の後に前記第１のデータベース・レコードの次の更新があったときに、前記複数の区画のうちの第３の区画を選択するステップであって、前記複数のプログラミング・スレッドのうちの前記複数の区画のうちの１つへアクセスする第３のプログラミング・スレッドからの要求に応答して、前記第３のプログラミング・スレッドを識別するシステム識別子に基づいて前記第３の区画を選択するステップと、
前記第３のプログラミング・スレッドが、前記次の更新により更新された第１のデータベース・レコード内の１つまたは複数の値に基づく前記第３の区画の更新トランザクションとして、前記第３の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新するステップと
を実行させることを特徴とする請求項１９に記載のデータ処理装置。
【請求項２１】
前記複数の集約値を集約するステップは、複数のレコードを有する単一テーブルを生成し、前記単一テーブルの各レコードに、前記複数の区画のそれぞれの前記集約レコードの複数の値を集約することを特徴とする請求項１９に記載のデータ処理装置。
【請求項２２】
前記プログラムは、前記プロセッサに、
前記区画へアクセスする前記第１のプログラミング・スレッドからの前記要求を受け取ると、前記第１のプログラム・スレッドを識別するシステム識別子を取得するステップと、
前記取得されたシステム識別子に基づいて、前記第１のプログラム・スレッドへ前記第１の区画の識別子を割り当てるステップと
を実行させることを特徴とする請求項１９に記載のデータ処理装置。
【請求項２３】
前記プログラムは、前記プロセッサに、
前記第１の区画の前記複数の集約レコードのうちの少なくとも１つの集約レコード内の集約値を更新する前記ステップにおいて、前記更新後の集約値から、事前選択された時間枠外にある完了した複数のインスタンスに対応するレコードの影響が除外されるように、時間で分類された集約レコードの複数の集約値を更新させることを特徴とする請求項１９に記載のデータ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本特許文書の開示の一部には、著作権保護対象の材料が含まれる。著作権所有者は、特許商標局の特許ファイルまたはレコードに表示された本特許文書または本特許開示の何人による複製にも異議を唱えるものではないが、これ以外はいかなるものであれすべての著作権を保有する。
【０００２】
本発明は、ビジネスまたは他の組織のワークフローを監視する方法およびコンピュータ・システムに関する。より詳細には、本発明は、ある活動の多様な複数のインスタンスに関する情報を集約（aggregating）し、その集約（aggregation）を維持（maintaining）する方法に関する。
【背景技術】
【０００３】
コンピュータ、具体的にはコンピュータ・データベース・アプリケーションは、ある組織の活動に関する情報を監視・レコードするために、ビジネスまたは他の組織により使用される。組織というものには、しばしば、実行の必要性がある様々な処理または活動がある、これらは頻繁に繰り返される。実際、一般に、組織は、任意の所与の時点において完了までの様々な段階で、活動についての多数のインスタンスを有することが普通である。一例として、あるビジネスが、顧客から受け取った注文に基づいて商品を販売することがある。対象となる活動はこれらの顧客の注文を履行することであり、この場合、各買い注文（書）（purchase order）がその活動の個々のインスタンスを表す。任意の特定の時点で、このビジネスは完了までの様々な段階でその活動についての多様な複数のインスタンス（すなわち、複数の顧客からの多様な複数の注文）を有する。しかし別の一例として、金融機関は、顧客からの申し込みに基づいて顧客に資金を貸し付ける場合がある。対象となる活動は、完了（例えば、承認または拒否）までの貸付の申し込みの処理であり、この場合、各申し込みが活動の個々のインスタンスを表す。任意の特定の時点で、複数の貸付申し込みのインスタンスは様々な処理段階がある。さらに別の一例として、許可証の発行を担当する行政体は、様々な段階で処理中の複数の許可申請書を有する。
【０００４】
活動についての多数のインスタンスを監視するために、多くの組織はそれらの活動インスタンスに関する情報をデータベース・プログラムに格納する。具体的には、レコードまたは他のデータオブジェクトを活動のインスタンスごとに作成することができる。この場合、各インスタンスに共通したある種の情報に対する値を保持するために、そのレコードについての個々のフィールドまたは他の構成要素が設定される。例として上記例の１つを使用すると、商品を販売するビジネスは、顧客の注文ごとに個々のデータベース・レコードを作成することができる。そのレコードの中には、その注文の受付時刻、その注文の受付場所、注文品、注文品が何時発送されたかなどに関する個別フィールドがある場合がある。データベース・プログラムのこのような使用は、しばしばテーブルとして概念化される。活動の各インスタンスは、テーブルの別々の行（または、タプル）に割り当てられる。多様な複数のインスタンスに共通した各種情報は、この場合、テーブルの別々の列（column）に割り当てられる。
【０００５】
【特許文献１】２００２年５月３１日出願、「Support for Real-Time Queries Concerning Current State, Data and History of a Process」という名称の米国特許出願第１０／１５７，９６８号
【非特許文献１】<http:://www.microsoft.com/sql/techinfo/productdoc/2000/>で入手可能なＫａｒｅｎ  ＤｅｌａｎｅｙによるＩｎｓｉｄｅ  Ｍｉｃｒｏｓｏｆｔ（登録商標）ＳＱＬ  ＳＥＲＶＥＲ（商標）２０００（２００１  Ｍｉｃｒｏｓｏｆｔ  Ｐｒｅｓｓ）およびＭｉｃｒｏｓｏｆｔ（登録商標）ＳＱＬ  ＳＥＲＶＥＲ（商標）２０００Ｂｏｏｋｓ  Ｏｎｌｉｎｅ
【発明の開示】
【発明が解決しようとする課題】
【０００６】
個々のレコードの個々のフィールドの値が必要とされる場合が時にはあるが、多くの組織は、レコードのグループに関する情報を頻繁に必要とする。さらに、この情報はしばしばリアルタイムで必要とされる。例えば、商品を販売する多くのビジネスは、現在保留中の注文（書）数、完了した注文（書）数、完了までの１つまたは複数の中間段階にある注文（書）数、を知ることを必要とする。ある種のデータベース・プログラムは、データベースの複数のレコード内の値を集約すること（aggregating）によってこのような報告を提供することができる。しかし、データベースが非常に大きい場合、これはしばしば受け入れがたい解決策となる。
【０００７】
多くのレコードが蓄積するに連れて、データベースにアクセスできる速度は大幅に低下する。一日に数百、数千の注文を受ける商品販売業者のような大規模なビジネス
の場合、レコード数は、数十万件、数百万件にのぼる可能性がある。データベースが照会される度に、ディスク・ドライブまたは他の記憶装置を検索するための限られた時間が必要となる。同様に、新しいレコードが作成され、既存のレコードが更新される際には、それらのレコードのそれぞれを作成し、または更新するための限られた期間が必要となる。レコード数が増えるにしたがって、特定のレコードを見つけるために必要となる時間も増加する。数百人（または、数千人）のユーザと数十万（または、数億）のデータベース・レコードを持つビジネスまたは組織では、データベース・システム・アクセスに対する待ち時間が非常に長くなる場合がある。さらに、多数のユーザがデータベースの同じ情報にアクセスしようとしている場合、同じレコードにアクセスしようとするユーザ間にデッドロックが生じる危険性がある。他のユーザが様々なフィールドの要約（summary）を生成するためにデータベースにアクセスしようとしている一方で、多数のユーザが大きなデータベースにレコードを挿入したり、更新したりした場合、すべてのユーザが、満足できないデータベース性能に直面することになる。
【０００８】
別の可能な解決策は、データベースのデータに対するオンライン分析処理（ＯＬＡＰ）キューブを生成することである。しかし、ＯＬＡＰキューブを生成するために必要な処理は、多大な時間を必要とする可能性もある。非常に多数のデータベース・レコードがある場合、ＯＬＡＰキューブは日毎（場合によっては１時間毎）にしか生成できないことがしばしばである。集約された情報を組織がリアルタイムに必要とする場合、ＯＬＡＰキューブでは十分でない場合がよくある。
【課題を解決するための手段】
【０００９】
本発明は、１つの活動の多様な複数のインスタンスに関する集約された情報を維持することに関する上記および他の課題に対処する。少なくとも１つの実施形態では、本発明は、複数のデータベース・レコードの複数のフィールドに収められた値の集約を維持する方法を含む。この方法は、複数の集約グループを作成することを含む。各グループは複数の集約レコードを含み、各集約レコードは、複数のデータベース・レコードの異なるサブセットの複数のフィールドに収められた値の集約としての１つの値を含む。この方法は、複数のデータベース・レコードの第１のデータベース・レコードについての挿入または更新に基づいて、第１の集約グループを選択することを含む。この方法は、挿入または更新された第１のデータベース・レコード内の１つまたは複数の値に基づいて、また第１の集約グループの更新トランザクションの部分として、第１の集約グループの複数の集約レコードのうちの１つの集約レコードの集約値を改定することも含む。第１の集約グループのその後の選択は、第１の集約グループの更新トランザクションが完了するまで防止される。第１の集約グループの更新トランザクションが実行中で、複数のデータベース・レコードのうちの第２のデータベース・レコードの挿入または更新に基づいて、第２の集約グループが選択される。挿入または更新された第２のデータベース・レコード内の１つまたは複数の値に基づいて、第１の集約グループの更新トランザクション中に、第２の集約グループの複数の集約レコードのうちの１つの集約レコードの集約値が改定される。本発明の他の態様では、集約グループは結合されて集約レコードの単一テーブルにされる。
【００１０】
少なくとも１つの別の一実施形態では、本発明は、組織の活動の多様な複数のインスタンスに関する集約されたデータを維持する方法を含み、この場合、活動の各インスタンスは複数のプロセス状態のうちの１つを有する。この方法は、集約されたデータ・テーブル内に複数のレコードを作成することを含み、この場合、各レコードは、同一期間中に同じプロセス状態の多様な複数のインスタンスのサブセットに対しての集約された値を含んでいる。この方法は、事前選択された時間枠（preselected time window）外の複数のプロセス状態のうちの１つのプロセス状態の複数のインスタンスに対応するデータの削除を反映するために、集約されたデータ・テーブルを更新することをさらに含む。
【００１１】
本発明のこれらおよび他の特徴および利点は、以下の好ましい実施形態の詳細な説明を添付の図面と共に読めば、容易に明らかになり、十分に理解されるだろう。
【発明を実施するための最良の形態】
【００１２】
本発明は、参照によりその内容を本明細書に組み込んだ（例えば、特許文献１参照。）文献に記載の方法、装置、およびシステムと組み合わせて有利に使用することができる。
【００１３】
本発明は、構造化照会言語（ＳＱＬ）命令、およびＲｅｄｍｏｎｄ、ＷａｓｈｉｎｇｔｏｎのＭｉｃｒｏｓｏｆｔ社製、ＳＱＬ  ＳＥＲＶＥＲ（商標）２０００リレーショナル・データベース管理システム（ＲＤＢＭＳ）ソフトウェアおよび関連するオンライン分析処理（ＯＬＡＰ）サービス・ソフトウェアに見られる他のデータ分析機能、を参照して説明する。本明細書では、本発明の特定の実施形態を実装するために使用することができるＳＱＬ命令のいくつかの態様を説明するが、本発明を実装するために使用される他の命令、プログラミングアルゴリズム、およびプロシージャは、当業者ならば本明細書の説明を読めば明らかになろう。ＳＱＬ  ＳＥＲＶＥＲ（商標）２０００ＲＤＢＭＳソフトウェアおよび関連するＯＬＡＰサービス・ソフトウェアの一般的な説明は様々なソース（例えば、非特許文献１参照。）から入手可能である。本発明は、ＳＱＬ  ＳＥＲＶＥＲ（商標）２０００  ＲＤＢＭＳソフトウェアおよび関連するＯＬＡＰサービス・ソフトウェアを使用した実施態様に限定されず、他のタイプのＲＤＢＭＳおよびＯＬＡＰソフトウェアを使用して実装することができる。
【００１４】
本発明をさらに、１つのサーバ上で動作し、１つまたは複数のクライアントによってアクセスされるＲＤＢＭＳソフトウェア（上記のＳＱＬ  ＳＥＲＶＥＲ（商標）２０００ソフトウェアなど）を参照して説明する。このような構成は当技術分野では周知であり、例えば既に組み込まれた文献（例えば、特許文献１参照。）に記載されている。しかし、クライアント・サーバ構成は、本発明を実装することのできる方法の一例に過ぎない。本発明は、他の物理システム構成でも実装することができる。
【００１５】
図１は、顧客の買い注文に基づいて顧客に商品を販売する、仮想の卸売ビジネスにおける顧客の買い注文の処理を示すブロック図である。便宜上、本明細書ではこのビジネスを「ビジネスＸ」と呼ぶことにする。ビジネスＸは複数の顧客から買い注文を受け取る。各買い注文を受け取ると、ビジネス社Ｘはその注文に関する情報を、データベース・サーバで維持されるデータベースに入力する。具体的には、ビジネスＸは、データベース内にその買い注文に関する新しいレコードを、個々の買い注文に共通した各種タイプの情報用のフィールドを使用して、作成する。この実施例では、各レコードは、買い注文（書）番号用のフィールド、受付日時用のフィールド、顧客がいる市（city）用のフィールド、注文された商品の量用のフィールドを含む。ビジネスＸは、各買い注文が受理されるか拒否されるかを決定し、次いで受理または拒否を反映するためにデータベースの１つまたは複数の他のフィールドを更新する。買い注文が受理された場合、対応する売り注文（書）（sales order）が生成され、注文主である顧客のいる市のビジネスＸの倉庫に送られる。商品が顧客に向けて発送されると、発送時刻がレコードの別のフィールドに（複数の倉庫のうちの１つの倉庫のクライアント・コンピュータにより）入力される。商品が納品されると、さらに別のフィールドが更新される。
【００１６】
本発明を説明するために上記実施例を作成したが、この実施例は（本明細書に記載のさらなる態様を含めて）、簡単な形式で示してはいるが、多くの実際のビジネスを表すものである。さらに、当業者には、仮想のビジネスＸに関して説明された概念は、ビジネスおよび他の組織の活動の広範囲に適用可能なことが理解されよう。実際に、本発明は、「ビジネスＸ」でなく「組織」という総称によって説明することができる。同様に、買い注文および注文の実現（order fulfillment）についての様々な段階に言及する代わりに、本発明は、「組織的プロセスのインスタンス（instance of an organizational process）」、組織プロセス・インスタンスの「状態」、組織プロセス・インスタンスの完了、などのような総称を使用して説明することができる。さらに読みやすい説明を提供するために実際のビジネス・タイプを簡略化した例を使用するが、本発明は特定タイプの組織または組織的な活動には限定されない。
【００１７】
図２は、図１のデータベースのテーブルの一部であり、会社Ｘによって維持され、個々の注文インスタンスに関するデータを記憶するために使用される。このインスタンス・データ・テーブルは、各買い注文に関する個々のレコード（例えば、行）および様々なタイプのデータに関する個々のフィールド（例えば、列）を有する。この実施例では、「ＰＯ＃」は買い注文（書）番号である。「ＲｅｃｖＴｉｍｅ」は注文を受け取った日時、「Ｃｉｔｙ」は買い注文を発行した顧客に最も近い倉庫がある市、および「Ｑｕａｎｔｉｔｙ」は注文品目数である。「ＳｈｉｐＴｉｍｅ」は買い注文の商品が発送された時間であり、「ＤｅｌｉｖｅｒＴｉｍｅ」はそれらの商品が納品された時間である。「ＰｒｏｃｅｓｓＳｔａｔｅ」は、買い注文が現在処理されているプロセスの部分を説明するために使用される変数である。買い注文は受け取り済みだが、商品がまだ発送されていない場合、買い注文は「ＩｎＰｒｏｃｅｓｓ」である。商品は発送済みだが、まだ納品されていない場合、買い注文は「Ｓｈｉｐｐｅｄ」である。商品が納品された場合、買い注文は「Ｄｅｌｉｖｅｒｅｄ」である。図には示さないが、ＰｒｏｃｅｓｓＳｔａｔｅ（処理状態）には他の値があってもよい（例えば、買い注文が拒否された場合のための「Ｄｅｎｉｅｄ」）。商品がまだ発送されていない買い注文は、ＳｈｉｐＴｉｍｅフィールドが＜ＮＵＬＬ＞値である。同様に、商品がまだ納品されていない買い注文は、ＤｅｌｉｖｅｒｙＴｉｍｅフィールドが＜ＮＵＬＬ＞値である。買い注文が発送および／または納品されると、これらのフィールドは適切な時間値で更新される。
【００１８】
図２から分かるように、また限られたレコード数しかないが、集約された情報が望まれる場合に生データのテーブルは扱いにくい可能性がある。例えば、特定の倉庫から納品された商品合計（total goods）が必要な場合、各行を確認する必要がある。集約されたデータを入手するためにさらに有用なテーブルの形式を図３に示す。具体的には、図３は、現在、納品中、処理中、または発送済みの買い注文書の合計数（「Ｃｏｕｎｔ」）を倉庫ごとに示す。図３は、Ｑｕａｎｔｉｔｙ列に、各倉庫が納品済み、発送済み、発送処理中の商品の合計数も示す。
【００１９】
図４は、Ｒｅｄｍｏｎｄからの新しい買い注文番号１３５の３０単位の受付を反映するように図３のテーブルが更新される方法を示す。具体的には、Ｒｅｄｍｏｎｄの「ＩｎＰｒｏｃｅｓｓ」の合計が３０増やされ、Ｃｏｕｎｔの合計が１増やされる。図５は、注文番号１３５が発送される際の図４のテーブルの更新を示す。Ｒｅｄｍｏｎｄ／ＩｎＰｒｏｃｅｓｓの買い注文の「Ｑｕａｎｔｉｔｙ」および「Ｃｏｕｎｔ」の合計は、それぞれ３０、および１が減らされ、Ｒｅｄｍｏｎｄ／Ｓｈｉｐｐｅｄの買い注文に関する同じフィールドは、それぞれ３０および１が増やされる。
【００２０】
図４および５の更新は比較的相対的単純であるけれども、複数のプログラミング・スレッドが同時に同じ集約されたデータ・テーブルにアクセスする場合に、問題が発生する場合がある。図６は、同じテーブルで同時に複数のトランザクションを実行しようとする２つのプログラム・スレッドを示す。簡略にするため、ＣｉｔｙおよびＰｒｏｃｅｓｓＳｔａｔｅ上にクラスタ化されたインデックスが存在し（すなわち、クラスタ化されたインデックス・キーに基づいてデータ行が順番に記憶されている）、そのレコードは図６に示す順番で上から下にアクセスされるようになっている、と想定する。多くのデータベース環境では、複数のレコードは、テーブルにアクセスする単一トランザクションの部分として、修正される。各トランザクションに対して処理オーバーヘッドが要求されるため、複数のレコードをバッチ処理することがさらに効率的である場合がしばしばある。そのトランザクションを「すべてか無か」の方式で実行することを要求することも、通例である。すなわち、トランザクションのすべての部分が完了しない限り、レコードは修正されない。そうでない場合、テーブルの整合性が損なわれる場合がある。
【００２１】
これらのデータベース処理の制約は、デッドロックの原因となりうる。プログラム・スレッドＡが１つのトランザクションで３つのレコードを更新しようとする場合、すなわち、買い注文１３４が発送済みであることを反映するためにＲｅｄｍｏｎｄ／ＩｎＰｒｏｃｅｓｓおよびＲｅｄｍｏｎｄ／Ｓｈｉｐｐｅｄを更新し、新しい買い注文１３６を反映するためにＳｅａｔｔｌｅ／ＩｎＰｒｏｃｅｓｓを更新しようとする場合に、図６でデッドロックが発生する。同時に、プログラム・スレッドＢも、１つのトランザクションで３つのレコードを更新しようとする。すなわち、買い注文１３３が発送済みであることを反映するためにＳｅａｔｔｌｅ／ＩｎＰｒｏｃｅｓｓおよびＳｅａｔｔｌｅ／Ｓｈｉｐｐｅｄを更新し、次いで新しい買い注文１３５を反映するためにＲｅｄｍｏｎｄ／ＩｎＰｒｏｃｅｓｓを更新しようとする。そのトランザクションを実行するために、スレッドＡは、スレッドＡが更新中のレコードに他のスレッドが影響を与えないようにするために、Ｒｅｄｍｏｎｄ／ＩｎＰｒｏｃｅｓｓおよびＲｅｄｍｏｎｄ／Ｓｈｉｐｐｅｄに対して排他的ロックを入手する。次いでスレッドＡは、Ｓｅａｔｔｌｅ／ＩｎＰｒｏｃｅｓｓに対する排他的ロックの入手を試みる。同時に、スレッドＢは、レコードＳｅａｔｔｌｅ／ＩｎＰｒｏｃｅｓｓおよびＳｅａｔｔｌｅ／Ｓｈｉｐｐｅｄに対する排他的ロックを入手して修正を行い、次にＲｅｄｍｏｎｄ／ＩｎＰｒｏｃｅｓｓに対する排他的ロックの入手を試みる。スレッドＡは既にＲｅａｄｍｏｎｄ／ＩｎＰｒｏｃｅｓｓをロックしているので、スレッドＢはそのトランザクションの第１の部分を完了することはできない。しかし、スレッドＢは、スレッドＡがＳｅａｔｔｌｅ／ＩｎＰｒｏｃｅｓｓのロックを試みる前に、Ｓｅａｔｔｌｅ／ＩｎＰｒｏｃｅｓｓおよびＳｅａｔｔｌｅ／Ｓｈｉｐｐｅｄをロックすることができる。したがって、スレッドＡがそのトランザクションの第２の部分を完了することが妨げられる。要するに、各スレッドは他方が終了するまで待機し、どちらもそのトランザクションを完了することができなくなる。いくつかのシステムは、スレッドの１つをデッドロックのビクティム（deadlock victim：デッドロックの犠牲者）に選び、そのビクティムのトランザクションの一部完了した任意の部分を後退（ロールバック）し、そのビクティムにエラーを報告する。これによって他のスレッドは先に進むことができ、またそのビクティムはそのトランザクションをもう一度繰り返すことができるようになるが、それでも尚、システム性能が低下することはない。具体的には、資源とメモリの処理は、一部完了したトランザクションを取り消すことによって浪費され、次いで１つのトランザクションの既に完了した部分を反復することによってさらに浪費される。
【００２２】
図７は、本発明の少なくとも一実施形態によりデッドロックを防ぐ方法を示す。集約された値の１つのテーブルは、区画されて別々のテーブルとされる。図７は、（太線で区画された）２つの区画（partition）を示しており、さらなる区画があることを縦の省略記号で示してある。個々の区画されたテーブル０、１などは、それぞれに同じレコードを含んでいるが、それらのレコード中の値は通常は区画間では異なっている。図７の実施例では、区画（partition）０は、Ｒｅｄｍｏｎｄ／Ｄｅｌｉｖｅｒｅｄ、Ｒｅｄｍｏｎｄ／ＩｎＰｒｏｃｅｓｓ、Ｒｅｄｍｏｎｄ／Ｓｈｉｐｐｅｄ、Ｓｅａｔｔｌｅ／Ｄｅｌｉｖｅｒｅｄ、Ｓｅａｔｔｌｅ／ＩｎＰｒｏｃｅｓｓ、およびＳｅａｔｔｌｅ／Ｓｈｉｐｐｅｄに関するレコードを有する。区画（partition）１も、Ｒｅｄｍｏｎｄ／Ｄｅｌｉｖｅｒｅｄ、Ｒｅｄｍｏｎｄ／ＩｎＰｒｏｃｅｓｓ、Ｒｅｄｍｏｎｄ／Ｓｈｉｐｐｅｄ、Ｓｅａｔｔｌｅ／Ｄｅｌｉｖｅｒｅｄ、Ｓｅａｔｔｌｅ／ＩｎＰｒｏｃｅｓｓ、およびＳｅａｔｔｌｅ／Ｓｈｉｐｐｅｄに関するレコードを有する。しかし、区画（partition）０のＲｅｄｍｏｎｄ／ＤｅｌｉｖｅｒｅｄのＱｕａｎｔｉｔｙとＣｏｕｎｔの値は、区画（partition）１などのＲｅｄｍｏｎｄ／ＤｅｌｉｖｅｒｅｄのＱｕａｎｔｉｔｙとＣｏｕｎｔの値と異なる。一度に特定の区画にアクセスすることが許可されるのは、１つのプログラム・スレッドだけである。説明のため、次に、図６のスレッドＡおよびＢを図７に示す。図７で、スレッドＡはそのトランザクションを区画（partition）０で実行し、同時にスレッドＢはそのトランザクションを区画（partition）１で実行する。これら複数のスレッドが同じレコードに対するアクセスで競合することは最早ないので、デッドロックは回避される。
【００２３】
ＳＱＬ  ＳＥＲＶＥＲ（商標）２０００  ＲＤＢＭＳソフトウェアを使用して実装される本発明の一実施形態では、図７の区画されたテーブルが、図８に示すように個々のＳＱＬテーブルとして実装される。区画（partition）番号は追加フィールド（「ＰａｒｔｉｔｉｏｎＩＤ」）として含まれる。この複数区画集約テーブル（multi-partition aggregation table）は、図２のインスタンス・データ・テーブル上のトリガによって維持される。当技術分野で周知の通り、「トリガ」は、ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、またはＤＥＬＥＴＥステートメントによって自動的に呼び出される、特別なタイプのＳＱＬのストアード・プロシージャ（SQL stored procedure）である。新しいレコードが図２のインスタンス・データ・テーブルに挿入されたときは何時でも、このトリガは、対応する寄与（contribution）が図８の複数区画集約テーブルの複数の区画のうちの１つの区画に対してなされることを引き起こす。同様に、インスタンス・データ・テーブル（図２）のレコードが更新されると、複数区画集約テーブル（図８）の対応するレコードも更新される。
【００２４】
どのような時点であっても、図８のテーブルの個々の区画は、ビジネスＸに関する完全な情報を持たない。インスタンス・データ・テーブル（図２）の更新が、区画０内の更新を引き起こす場合があり、一方、インスタンス・データ・テーブルに対する別の更新は、区画１の更新を引き起こすことがある、など。さらに、インスタンス・データ・テーブルのレコードの作成は、図８の１つの区画のテーブル内のレコードの更新を引き起こす場合があり、同じインスタンス・データ・レコードについてのその後の更新は、異なる区画のレコードの更新を引き起こす場合がある。例えば、新しい買い注文（書）番号１４０（Ｒｅｄｍｏｎｄ、Ｑｕａｎｔｉｔｙ＝２００）を図２に追加することによって、図８の<PartitionID=1>/<City=Redmond>/<ProcessState=InProcess>レコードのＱｕａｎｔｉｔｙフィールドとＣｏｕｎｔフィールドは、２００および１が増やされる。しかし、買い注文１４０用の商品が発送されると、図８の＜ＰａｒｔｉｔｉｏｎＩＤ＝３＞／＜Ｃｉｔｙ＝Ｒｅｄｍｏｎｄ＞／＜ＰｒｏｃｅｓｓＳｔａｔｅ＝ＩｎＰｒｏｃｅｓｓ＞レコードのＱｕａｎｔｉｔｙフィールドとＣｏｕｎｔフィールドは、２００と１減らされ、＜ＰａｒｔｉｔｉｏｎＩＤ＝３＞／＜Ｃｉｔｙ＝Ｒｅｄｍｏｎｄ＞／＜ＰｒｏｃｅｓｓＳｔａｔｅ＝Ｓｈｉｐｐｅｄ＞レコードの同フィールドは２００と１増やされる。したがって、これらの区画は、ビジネスＸに関する完全なデータ集約テーブルを提供するために、結合される。具体的には、少なくとも１つの実施形態では、次のＳＱＬコードが使用される。
CREATE VIEW<view_name>  
AS  
SELECT City, ProcessState, SUM(Quantity),SUM(Count)  
FROM<multi_partition_table>  
GROUP BY City, ProcessState  
【００２５】
最初のイタリック体の名称（「ｖｉｅｗ＿ｎａｍｅ」）は、個々の区画が結合されたビュー（view）の名称である。２番目のイタリック体の名称（「ｍｕｌｔｉ＿ｐａｒｔｉｔｉｏｎ＿ｔａｂｌｅ」）は、図８の複数区画集約テーブルの名称である。この結果得られたテーブル（「ｖｉｅｗ＿ｎａｍｅ」）は、図９に示す形式をとる。複数区画集約テーブルの各区画に含まれるレコードは、比較的少ないレコードしか含まないので、これらの区画は比較的迅速に組み合わせることができる。実際、それらの集約された区画は集約される。他の実施形態では、各区画を個々のテーブルとして実装し、次いでＳＱＬ  ＪＯＩＮステートメントによってＣＲＥＡＴＥ  ＶＩＥＷコマンドに加えることができる。
【００２６】
各区画を一度に１つのプログラム・スレッドしかアクセスしないように、スレッドは区画にアクセスするために仮想トークンを所有しなければならない。本発明の一実施形態では、トークンはＧｅｔ＿Ｍｕｔｅｘという名称の特別なストアード・プロシージャに対する呼び出しによって得られる。前述のように、複数区画集約テーブルはＳＱＬトリガによって維持される。複数区画集約テーブル内の行を更新することができるようになる前に、トリガ内の１つまたは複数の命令はどの行を更新すべきかを示さなければならない。これらの命令の一部として、Ｇｅｔ＿Ｍｕｔｅｘというストアード・プロシージャが呼び出される。次いでＧｅｔ＿Ｍｕｔｅｘプロシージャは、そのテーブルのＰａｒｔｉｔｉｏｎＩＤ列に対する値を戻す。スレッドが、その戻されたＰａｒｔｉｔｉｏｎＩＤ値を有するレコードに対するトランザクションを実行している間、他のスレッドがその同じ値を入手することが防止され、したがって別のスレッドによって更新中の区画にアクセスすることが防止される。
【００２７】
前の実施例に戻って、買い注文１４０に関するレコードがインスタンス・データ・テーブル（図２）で最初に作成されたとき、トリガが発せられる。次いで、このトリガは、  
Ｇｅｔ＿Ｍｕｔｅｘを呼び出して、ＰａｒｔｉｔｉｏｎＩＤに対する値を受け取り；  
更新されるべき区画内の１つまたは複数の行を決定し；  
複数区画集約テーブルの、ＰａｒｔｉｔｉｏｎＩＤがＧｅｔ＿Ｍｕｔｅｘプロシージャによって戻されたＰａｒｔｉｔｉｏｎＩＤ値に等しく、Ｃｉｔｙが注文書１４０に対するインスタンス・データ・レコードのＣｉｔｙの値に等しく、ＰｒｏｃｅｓｓＳｔａｔｅが「ＩｎＰｒｏｃｅｓｓ」に等しい、行を識別し；  
その行のＱｕａｎｔｉｔｙに対する値を、買い注文１４０に対するインスタンス・データ・レコードのＱｕａｎｔｉｔｙの値だけ増やし；  
その行のＣｏｕｎｔに対する値を１だけ増やす。
【００２８】
さらなる例として、買い注文１４０に対する既存のインスタンス・データ・テーブルレコードは、ＰｒｏｃｅｓｓＳｔａｔｅをＩｎＰｒｏｃｅｓｓからＳｈｉｐｐｅｄに変更するよう後で更新される。この場合、トリガ内のさらなる論理は、  
Ｇｅｔ＿Ｍｕｔｅｘを呼び出して、ＰａｒｔｉｔｉｏｎＩＤに対する値を受け取り；  
更新されるべき区画内の１つまたは複数の行を決定し；  
複数区画集約テーブルの、ＰａｒｔｉｔｉｏｎＩＤがＧｅｔ＿Ｍｕｔｅｘプロシージャによって戻された値に等しく、Ｃｉｔｙが買い注文１４０に対するインスタンス・データ・レコードのＣｉｔｙの値に等しく、ＰｒｏｃｅｓｓＳｔａｔｅがＩｎＰｒｏｃｅｓｓに等しい、行を特定し；  
その行のＱｕａｎｔｉｔｙに対する値を、注文１４０に対するインスタンス・データ・レコードのＱｕａｎｔｉｔｙに対する値だけ減らし；  
その行のＣｏｕｎｔの値を１だけ減らし；  
複数区画集約テーブルの、ＰａｒｔｉｔｉｏｎＩＤがＧｅｔ＿Ｍｕｔｅｘプロシージャによって戻された値に等しく、Ｃｉｔｙが注文１４０に対するインスタンス・データ・レコードのＣｉｔｙの値に等しく、ＰｒｏｃｅｓｓＳｔａｔｅがＳｈｉｐｐｅｄに等しい、行を特定し；  
その行のＱｕａｎｔｉｔｙに対する値を、注文書１４０に対するインスタンス・データ・レコードのＱｕａｎｔｉｔｙに対する値だけ増やし；  
その行のＣｏｕｎｔの値を１だけ増やす。
【００２９】
類似の論理が、買い注文１４０ＰｒｏｃｅｓｓＳｔａｔｅがＳｈｉｐｐｅｄからＤｅｌｉｖｅｒｅｄに変更した場合、複数区画集約テーブルの適切な行を識別して修正する。
【００３０】
Ｇｅｔ＿Ｍｕｔｅｘに関する一実施態様を図１０に示す。最初に、ＲＴＡ＿Ｍｕｔｅｘという名称の単一列テーブルが作成される（create table RTA_Mutex）。ＲＴＡ＿Ｍｕｔｅｘテーブルは、図８の複数区画集約テーブルの区画にあるのと同数の行を有する。この場合、各フィールドはＰａｒｔｉｔｉｏｎＩＤ値の１つに割り当てられる。図１０の実施例では、図８のテーブルが１０個の区画を含むものと想定する（すなわち、ＰａｒｔｉｔｉｏｎＩＤは０から９の整数値を有する）。次に、Ｇｅｔ＿Ｍｕｔｅｘというストアード・プロシージャが作成される。ローカル変数＠ｐａｒを宣言した後、ローカル＠ｐａｒ変数はＲＴＡ＿Ｍｕｔｅｘテーブルの複数の行のうちの１つの行の値に割り当てられる。具体的には、「ｓｅｌｅｃｔ」ステートメントは、＠ｐａｒにＲＴＡ＿Ｍｕｔｅｘテーブルからの、「＠＠ｓｐｉｄ％１０」に等しいＰａｒｔｉｔｉｏｎＩＤの値を割り当てる。システム・ファンクション＠＠ｓｐｉｄは、現行のユーザ・プロセスのサーバ・プロセス識別子を戻す。すなわち、＠＠ｓｐｉｄファンクションは、Ｇｅｔ＿Ｍｕｔｅｘというストアード・プロシージャを呼び出したプログラム・スレッドを特定する番号を戻す。次いでモジュロ算術演算子（「％」）は、そのプログラム・スレッド識別子を１０で割った剰余を戻す。次いでこのプロシージャは、ＰａｒｔｉｔｉｏｎＩＤの値がその剰余に等しいＲＴＡ＿Ｍｕｔｅｘの行を見つけ、排他的ロッキング・ヒント（「（ｘｌｏｃｋ）」）でその行をロックする。そのロックされたＲＴＡ＿Ｍｕｔｅｘ行のＰａｒｔｉｔｉｏｎＩＤの値は次いで、Ｇｅｔ＿Ｍｕｔｅｘというストアード・プロシージャの結果として戻される。その行に排他的ロックがあるので、他のプログラミング・スレッドは、ＲＴＡ＿Ｍｕｔｅｘテーブルのその行にアクセスすることは許可されず、したがってそのＰａｒｔｉｔｉｏｎＩＤ値を既に入手したトランザクションが完了するまで、そのＰａｒｔｉｔｏｎＩＤ値を入手することはできない。
【００３１】
一例として、２３１という識別子を有するプログラム・スレッドがＧｅｔ＿Ｍｕｔｅｘを呼び出す。２３１を１０で割った剰余は１である。Ｇｅｔ＿Ｍｕｔｅｘによってプログラミング・スレッドに戻されたこの値は、したがって、ＰａｒｔｉｔｏｉｎＩＤが１に等しいＲＴＡ＿Ｍｕｔｅｘのフィールドの値である。Ｇｅｔ＿Ｍｕｔｅｘから値が戻る際に、プログラム・スレッド２３１は図８の区画１の１つまたは複数の行を更新することができる。スレッド２３１が区画１を更新している間、プログラム・スレッド１６１はＧｅｔ＿Ｍｕｔｅｘを呼び出す。しかし、スレッド２３１のトランザクションがまだ完了していないので、スレッド１６１はＰａｒｔｉｔｉｏｎＩＤに対する値１を保持するＲＴＡ＿Ｍｕｔｅｘの行にアクセスすることはできない。スレッド１６１は次いで、必須のＲＴＡ＿Ｍｕｔｅｘ行に対する排他的ロックが解放されるまで（すなわち、スレッド２３１のトランザクションが完了するまで）待ち行列に入れられる。追加スレッドがそのＲＴＡ＿Ｍｕｔｅｘ行にアクセスしようとする場合、それら追加スレッドも、先入れ先出し（または他の）方式で待ち行列に入れられる。特に、スレッド１６１は、値がその呼び出しからＧｅｔ＿Ｍｕｔｅｘに戻されるまでは先に進まず、したがってスレッド１６１は、スレッド２３１が区画１にアクセスしている間は区画１へのアクセスを試みない。ｘｌｏｃｋが解放されるのをスレッド１６１が待ち行列で待機している間、スレッド１５４はＧｅｔ＿Ｍｕｔｅｘを呼び出す。現行では、ＰａｒｔｉｔｏｎＩＤ＝４のＲＴＡ＿Ｍｕｔｅｘの行にはロックがないので、Ｇｅｔ＿Ｍｕｔｅｘは値（４）をスレッド１５４に戻す。
【００３２】
図１０は、Ｇｅｔ＿Ｍｕｔｅｘプロシージャを実装することができる方法の一例だけを示す。別の例として、区画へのアクセスを試みるすべてのスレッドは、先入れ先出し待ち行列に入ることができる。次いで、その待ち行列内の各スレッドは、最初に使用可能な区画に割り当てられる。
【００３３】
一実施形態では、区画数は、データベース・サーバ上のプロセッサの数に少なくとも等しく、このプロセッサ数よりも多いことが好ましい。
【００３４】
既に指摘したように、インスタンス・データ・テーブル（図２）のサイズは、より多くの買い注文が受け取られるにつれて、経時的に増大する。しかし、図９の集約テーブル（または、図８の複数区画集約テーブル）のサイズは、追加の集約フィールドが加えられない限り増大しない（例えば、Ｒｅｄｍｏｎｄ／ＤｅｎｉｅｄおよびＳｅａｔｔｌｅ／Ｄｅｎｉｅｄ）。テーブルのサイズは増大しないが、ＱｕａｎｔｉｔｙとＣｏｕｎｔ列の値は増加する。組織は、ある特定の時間「枠」内のイベントに対して集約されたデータを要求するだけの場合がしばしばある。例えば、ビジネスＸは、現在処理中の買い注文、現在発送中の買い注文、および過去２４時間以内に納品された買い注文に関する集約されたデータを要求する可能性がある。さらに、ビジネスＸは、そのイベントが発生した時刻などに基づいて、そのデータをさらに分類することを要求する可能性がある。図１１を参照すると、ビジネスＸの責任者は、最近午前８：００台にＲｅｄｍｏｎｄおよびＳｅａｔｔｌｅで処理中になり未発送の買い注文（書）数（この実施例では０）、最近午前９：００台における数（この実施例では同じく０）、最近午前１０：００台における数（２および１）などを知ろうとする。同様に、この責任者は、午前８：００の発送済み未納品の買い注文（書）数、午前９：００の発送済みであるが未納品の買い注文（書）数なども知ろうとする。また、この責任者は、これら時間間隔中にこれらの場所から納品された買い注文（書）数も知ろうとする。しかし、このことは、集約テーブルが毎時増加することを意味している。「ＩｎＰｒｏｃｅｓｓ」または「Ｓｈｉｐｐｅｄ」であって、最終的に「Ｄｅｌｉｖｅｒｅｄ」になることになっている買い注文と異なり、「Ｄｅｌｉｖｅｒｅｄ」の買い注文は別の状態に遷移しない。別の例で言えば、買い注文が特定日の特定時に「Ｄｅｌｉｖｅｒｅｄ」になってしまうと、何らかの処置が取られない限り、その時／日に関する集約テーブル内のレコードは保持される。時が経つにつれ、そのテーブルは増大し、照会するのが遅くなる。一方、責任者は、長期に亘るほど（例えば、先週中などの）、ある場所から納品された注文（書）の合計数を知ろうという関心が薄れる。このような情報は目的によっては有用な場合があるが、比較的まれにしか必要とされない。
【００３５】
図１２は、本発明の一実施形態で、非活動状態の買い注文インスタンス（例えば、納品済みの買い注文）に関するデータがある一定期間経過すると、そのデータをリアルタイム集約テーブルから除去する方法を示す。簡略化のために、単一区画だけを示す。しかし、当業者は、以下の説明により、図１２の実施形態が既に説明した複数区画の実施形態と共に実装することができることを理解するだろう。
【００３６】
図１２に示すように、ＴｉｍｅＳｌｉｃｅおよびＨｏｕｒの列が、図９のリアルタイム集約テーブルに追加された。ＴｉｍｅＳｌｉｃｅは、インスタンス・データ・テーブル（図２）が、インスタンスが完了したことを反映するために更新された際の、サーバの日付けと時刻（時間精度を有する）である。この実施例では、買い注文は、注文の商品が顧客に納品された時点で完了する。時刻とは、対象イベントが発生し日の時刻である。この実施例では、ＴｉｍｅＳｌｉｃｅの時間成分は完了したレコード用のＨｏｕｒと同じだが、これは必ずしもこの通りである必要はない。
【００３７】
上述の実施例にあるように、図１２のリアルタイム集約テーブルのデータは、インスタンス・データ・テーブルのデータ・レコードが挿入または更新された時点で発せられるトリガによって修正される。ＴｉｍｅＳｌｉｃｅ列の値は、２つの規則に従うトリガにより自動的に生成される。レコードに対してさらに多くの更新が予想される場合（例えば、商品が未納品の場合）、ＴｉｍｅＳｌｉｃｅはＮＵＬＬである。そうでない場合、現在の時刻（正時）と日付を表す数字が生成される。特に、完了した買い注文に対する非ＮＵＬＬのＴｉｍｅＳｌｉｃｅ値は、完了した注文に関するデータの集約を妨げない。ＴｉｍｅＳｌｉｃｅの時間成分は時間精度を有するだけなので、同じ１時間内に同じ倉庫から納品された注文を、単一レコード内に集約することができる。例えば、買い注文の１２６および１２８（図２）は、それぞれ午後３：１０および午後３：０５に納品された。図１２に示すように、Ｊａｎ  ２０  ３ｐ．ｍ．／３／Ｓｅａｔｔｌｅ／Ｄｅｌｉｖｅｒｅｄに関するレコードは２というＣｏｕｎｔと７９０というＱｕａｎｔｉｔｙを示すが、このレコードは、図２の注文１２６および注文１２８に関するデータ・レコードに関係する。
【００３８】
トリガが図１２のリアルタイム集約テーブルを修正するたびに、そのトリガは、そのテーブルの完了したインスタンス集約データのどれかが古いか否か、すなわち最早必要ないか否かについても決定する。この実施例では、２４時間以前に完了したインスタンスに関する集約されたデータは古く、集約されたデータ・テーブルから除去すべきであると仮定する。したがって、トリガが図１２のテーブルを修正するたびに、そのトリガは、そのタイムスライスの期間の最新時刻が現時点より２４時間以前であるＴｉｍｅＳｌｉｃｅ値を有するレコードを削除する。そのトリガが１月２１日の午後１：０５に図１２のテーブルを更新する場合、Ｊａｎ  ２０  １２ｐ．ｍ．／１２／Ｓｅａｔｔｌｅ／Ｄｅｌｉｖｅｒｅｄに関するレコードは削除される。これは、このレコード内のすべてのデータは、２４時間以前に完了した注文に対応するからである。少なくとも１つの実施形態では、図１２のテーブルは、ＴｉｍｅＳｌｉｃｅデータをユーザから隠すビューで表示される。
【００３９】
図１３は、（図１２に示すような）複数の区画によるリアルタイム・データ集約テーブルを維持するトリガに関する論理を示すフローチャートである。具体的には、図１３の流れ図は、１つの区画内の１つまたは複数の集約されたデータ・レコードを更新するために、トランザクション中に個々のプログラミング・スレッドで、トリガに付随する論理を示す。各スレッドは、図１２のテーブルに類似の形式を備えた、個々の区画を更新する。実行中、トリガは、ＳＱＬデータベース・サーバによってメモリ（例えば、ＲＡＭ）に維持されている「挿入済み」および「削除済み」という名称の２つのシステム・テーブルにアクセスする。この挿入済みテーブルと削除済みテーブルは、データベース・サーバによって自動的に生成されて、インスタンス・データ・テーブルにレコードを挿入したり、または（図２に示すような）インスタンス・データ・テーブルの既存のレコードを更新したりした前回の試みの期間に影響を受けた行のデータのコピーを一時的に記憶する。具体的には、挿入済みテーブルは、インスタンス・データ・テーブルの行に挿入された値を含み、削除済みテーブルは、インスタンス・データ・テーブルの更新された行で置き換えられた値を含む。
【００４０】
開始後、トリガはまずブロック１０２でトークンを得る。このトリガは、上述のように、Ｇｅｔ＿Ｍｕｔｅｘのようなプロシージャに対する呼び出しによってそのトークンを得る。ブロック１０４で、トリガは、インスタンス・データ・レコードが更新中か否かを決定する。具体的には、トリガは、削除済みテーブルが空か否かを決定する。削除済みテーブルが空でない場合、削除済みテーブルのＱｕａｎｔｉｔｙ値は、区画の適切なレコードに対するＱｕａｎｔｉｔｙ値を減らすためにブロック１０６で使用される。具体的には、トリガは区画内の、Ｈｏｕｒが、インスタンス・データ・レコードがその前回のＰｒｏｃｅｓｓＳｔａｔｅ値に更新された時刻に等しく、Ｃｉｔｙが、更新されたインスタンス・データ・レコードの市に等しく、ＰｒｏｃｅｓｓＳｔａｔｅが、更新されたレコードの前回のプロセス状態に等しい、レコードを特定する。そのレコードに対するＣｏｕｎｔ値も１減らされる。ブロック１０８で、トリガは、区画内のレコードがＮＵＬＬ値のＴｉｍｅＳｌｉｃｅと０のＣｏｕｎｔ値を有するか否かを決定する。あるレコードがそれらを有する場合、それらのレコードは削除される。
【００４１】
ブロック１１０で、トリガは、更新中（または挿入中）のインスタンス・データ・レコードが完了したか否かを決定する。すなわち、トリガは、さらなる更新が予想されるか否かを決定する。これは様々な方法で実行することができる。例えば、「ＩｓＣｏｍｐｌｅｔｅ」列を各インスタンスレコードに追加して、その更新が最終の場合、それを「１」に設定することができる。他の実施形態では、様々なプロセス状態値（例えば、「Ｄｅｌｉｖｅｒｅｄ」または「Ｄｅｎｉｅｄ」）は、このインスタンスに関するプロセス完了を信号で伝えることができる。インスタンス・データ・レコードが完了していない場合（すなわち、プロセスが、更新中の注文インスタンスに関してまだ活動状態にあり、さらなる更新が予想される場合）、ブロック１１２で、集約テーブル区画のレコードのＱｕａｎｔｉｔｙ値を増やすために、「挿入済み」テーブルのＱｕａｎｔｉｔｙ値が使用される。ここで、この集約テーブル区画のレコードは、ＴｉｍｅＳｌｉｃｅがＮＵＬＬに等しく、Ｈｏｕｒが、インスタンス・データ・レコードがその現在のＰｒｏｃｅｓｓＳｔａｔｅ値に更新された時刻に等しく、Ｃｉｔｙが、更新されたインスタンス・データ・レコードの市に等しく、ＰｒｏｃｅｓｓＳｔａｔｅが、更新されたインスタンス・データ・レコードの現在のＰｒｏｃｅｓｓＳｔａｔｅ値に等しい、レコードである。その区画のレコードのＣｏｕｎｔ値も１増やされる。これでトリガは完結する。
【００４２】
ブロック１１０で、更新中のインスタンス・データ・レコードが完了したとトリガが決定した場合、ブロック１１４でＴｉｍｅＳｌｉｃｅ値が生成される。ブロック１１６で、トリガは、選択された時間枠外の（例えば、２４時間以前の）ＴｉｍｅＳｌｉｃｅ値を有するすべてのレコードを削除する。次いでトリガは、ＴｉｍｅＳｌｉｃｅの値が、生成されたばかりのＴｉｍｅＳｌｉｃｅ値に等しい区画レコードを特定する（または、必要に応じて作成する）。ここで、このレコードは、Ｈｏｕｒが完了時刻に等しく、Ｃｉｔｙが更新されたインスタンス・データ・レコードの市に等しく、ＰｒｏｃｅｓｓＳｔａｔｅが、完了したインスタンス・データ・レコードの値（この実施例では「Ｄｅｌｉｖｅｒｅｄ」）に等しい、レコードである。次いで、特定された（または、作成された）区画レコードのＱｕａｎｔｉｔｙ値を増やすために、「挿入済み」テーブルのＱｕａｎｔｉｔｙ値が使用される。その区画レコードに対するＣｏｕｎｔ値も１増やされる。これでトリガは完結する。
【００４３】
他の実施形態では、図１３のトリガ論理を、インスタンス・データ・テーブルの複数のレコードの更新に合わせて修正することができる。ブロック１１２または１１８の後で終了する代わりに、トリガは、インスタンス・データ・テーブルのバッチ更新の部分として更新中の追加のインスタンスレコードがあるか否かを決定する。ある場合、トリガ論理はブロック１０４にループ・バックする。ない場合、これでトリガは完結する。さらに別の実施形態では、ユーザが時間枠を調整することができる。
【００４４】
以上、本発明を、仮想の業種を例に用いて説明したが、本発明は特定タイプのビジネス、組織、または活動に限定されないことを銘記されたい。さらに、本発明は、データベース・レコードのフィールドの値を合計することによって値が集約される、実施態様には限定されない。一例として、集約された値がデータベース・レコードのフィールドの値の平均値を表す集約テーブルを作成することができる。したがって、本発明を実行する具体的な複数の実施例を説明したが、当業者には、特許請求の範囲に記載の本発明の趣旨および範囲に含まれる、上記システムおよび技術の多数の変形形態および置き換えがあることが理解されよう。これらおよび他の修正形態は、特許請求の範囲によって定義される本発明の範囲に含まれる。
【図面の簡単な説明】
【００４５】
【図１】仮想の卸売のビジネスにおける顧客注文の処理を示すブロック図である。
【図２】図１のビジネスのインスタンス・データ・テーブルの一部を示す図である。
【図３】図２のテーブルの様々なフィールドからデータを集約したテーブルである。
【図４】新しいインスタンス・データ・レコードを反映するための集約されたデータ・テーブルの更新を示す図である。
【図５】既存のインスタンス・データ・レコードの更新を反映するための集約されたデータ・テーブルの更新を示す図である。
【図６】複数のプログラム・スレッド間のデッドロックを示す図である。
【図７】本発明の少なくとも一実施形態による複数区画集約テーブルを示す図である。
【図８】本発明の少なくとも一実施形態による図７の集約テーブルの実施態様を示す図である。
【図９】本発明の少なくとも一実施形態による複数区画集約テーブルの複数の区画を結合したビューを示す図である。
【図１０】プログラム・スレッドに区画を割り当てるためのストアード・プロシージャの一実施態様を示す図である。
【図１１】集約されたデータを提供し、ビジネスのマイルストーン・タイム・スタンプが集約基準として使用される別のテーブルを示す図である。
【図１２】本発明の一実施形態により、古い集約されたデータの削除を容易にするテーブルである。
【図１３】本発明の少なくとも一実施形態により、トリガがリアルタイム・データ集約テーブルを維持する論理を示すフローチャートである。
【図１】
0004828102.tif 000002
【図２】
0004828102.tif 000003
【図３】
0004828102.tif 000004
【図４】
0004828102.tif 000005
【図５】
0004828102.tif 000006
【図６】
0004828102.tif 000007
【図７】
0004828102.tif 000008
【図８】
0004828102.tif 000009
【図９】
0004828102.tif 000010
【図１０】
0004828102.tif 000011
【図１１】
0004828102.tif 000012
【図１２】
0004828102.tif 000013
【図１３】
0004828102.tif 000014