JP5209001B2

JP5209001B2 - アクティビティの複数のインスタンスに関する情報を維持する方法

Info

Publication number: JP5209001B2
Application number: JP2010160909A
Authority: JP
Inventors: ボノフコズロフゲオルギ; ザカリージェーソンリチャード; アンソニーリールエリック
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2003-09-26
Filing date: 2010-07-15
Publication date: 2013-06-12
Anticipated expiration: 2024-07-15
Also published as: JP2010262670A; CN100437567C; EP1519289A1; KR20050030848A; JP2005108187A; CN1601527A; US8315972B2; US20050071341A1

Description

本特許文書の開示の一部には、著作権保護の対象となる内容が含まれる。著作権所有者は、米国特許庁の特許ファイルまたは記録に記載される通りにいかなる者が本特許文書または特許開示を複製することには異議を持たないが、その他の点ではすべての著作権を保有する。

本発明は、企業または他の組織のワークフローを監視する方法およびコンピュータシステムに関する。より詳細には、本発明は、アクティビティの複数のインスタンスについての情報を閲覧し、その情報を保持する方法に関する。

企業および他の組織で組織の活動についての情報を監視し、記録するために、コンピュータ、特にコンピュータデータベースアプリケーションが使用される。多くの場合、組織は、行わなければならない各種の工程や活動を有し、それらは頻繁に繰返し行われる。実際、組織が、所与の時に様々な完了段階にある多数のアクティビティインスタンスを有することは一般的である。一例として、企業は、顧客から受け取った注文に基づいて商品を販売する場合がある。当該アクティビティは例えばそれらの顧客注文の遂行であり、１件１件の購入注文がそのアクティビティの個別のインスタンスに相当する。ある特定の時に、その企業は、様々な完了段階にあるそのアクティビティの複数のインスタンス（すなわち複数の顧客からの複数の注文）を有する可能性がある。さらに別の例として、金融機関は、顧客からの申請に基づいて顧客に資金を貸し付ける場合がある。当該のアクティビティは、例えば貸付の申請を処理して完了する（すなわち承認または却下する）ことであり、１件１件の申請がそのアクティビティの個別のインスタンスに相当する。任意の特定の時に、様々な処理段階にある複数の貸付申請のインスタンスがある可能性がある。さらに別の例として、許可書の発行を担当する政治機関が、様々な処理中の段階にある複数の許可書の申請を有する場合がある。

あるアクティビティの多数のインスタンスを監視するために、多くの組織では、それらのアクティビティインスタンスについての情報をデータベースプログラムに格納している。詳細には、アクティビティのインスタンスごとにレコードまたは他のデータオブジェクトが作成されることができる。そして、そのレコードの別個のフィールドまたは他のコンポーネントが設定されて、各インスタンスに共通の何らかのタイプの情報についての値を保持する。上記の例の１つを具体例として使用すると、商品を販売する企業は、顧客の注文ごとに別個のデータベースレコードを作成することができる。そのレコード中には、その注文が受け取られた時間、注文者、注文内容、注文が発送された時間などについての個別のフィールドを設けることができる。このようなデータベースプログラムの使用法は、しばしば、テーブルとして概念化される。アクティビティの各インスタンスには、テーブルの別個の行（またはタプル(tuple)）が割り当てられる。そして、複数のインスタンスに共通する各タイプの情報に、テーブルの別個の列が割り当てられる。

各アクティビティインスタンスのデータをデータベーステーブルに入れることにより、そのデータを各種の方式で分析することが可能になる。しかし、蓄積するレコードが増加するにつれてデータベースの有用性が低下する可能性がある。一日に何百あるいは何千件の注文を受け取る商品販売者のような大規模な企業の場合は、レコードの数が何十万あるいは何百万件にも達する場合がある。データベースが照会されるたびに、ディスクドライブまたは他の記憶装置を検索するのに有限量の時間が必要になる。同様に、新しいレコードが作成され、既存のレコードが更新される際には、それらの各レコードを作成または更新するのに有限量の時間が必要とされる。レコード数が増えるに従って、特定のレコードを見つけるのに必要な時間が増大する。何百人（あるいは何千人）ものユーザと何十万（あるいは何百万）ものデータベースレコードを有する企業あるいは組織では、データベースシステムへのアクセスの待ち時間が著しく長くなる場合があり、システムディスクが一杯になる可能性がある。

図１〜図３は、この問題をより詳細に示した図を提供し、且つ下記の「発明を実施するための最良の形態」で説明の拠所とする例も提供する。図１は、顧客の販売注文に応じて顧客に商品を販売する仮想上の卸し業による顧客の購入注文の処理を示すフローチャートである。便宜上、この企業をここでは「企業Ａ」と称する。ブロック１で企業Ａは購入注文を受け取り、その購入注文についてのデータベースレコードを作成し、注文受け取りの時刻も入力される。ブロック２および３で、注文された製品の量と注文者の住む都市に対応するレコードフィールドに追加のデータが入力される。ブロック４で、その購入注文が承認されるかどうかに関する判定が行われる。承認されない場合は、ブロック５でレコードの該当するフィールドにデータがとりこまれ、拒否の時間が記録される。購入注文が承認される場合は、受け付けが記録される。購入注文が承認される場合は、追加の情報が入力されることができる（ブロック６および７）。注文品が発送される際（ブロック８）に、別のフィールドに発送の時刻がとりこまれる。ブロック９および１０でさらなるデータが入力されることができる（発送コンテナのタイプや運送業者など）。注文品が配達されると、配達の時刻が入力される（ブロック１１）。

図２は、企業Ａの購入注文インスタンスのデータベースの一部を表す表である。各注文が個別の行にあり、各列が注文のデータのタイプに対応する。簡潔にするために、図２には、図１のフローチャートで収集された情報の一部についての列だけを示す。あるフィールドはＮＵＬＬ値を含むが、これは、（この例では）特定のイベントについての値が、そのイベントがその特定の購入注文についてまだ行われていないので未知であることを意味する。このデータベースの典型的な照会は、例えば「１０００ドル以上の先週提出された購入注文で、まだ受け付けも拒否もされていないのはどれか」である。このような照会は、テーブルに対するＳＱＬ（構造化照会言語）照会を介して実施されることができる。

付録Ａに、図２のテーブルを作成するＳＱＬコードの一実装（“ｃｒｅａｔｅｔａｂｌｅＰＯ＿ＩｎｓｔａｎｃｅＤａｔａ”）と、図２のテーブルの行を更新するストアドプロシージャ（“ｃｒｅａｔｅｐｒｏｃｅｄｕｒｅＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔ”）を示す。このストアドプロシージャは、あるアクティビティインスタンス（この例では特定の購入注文）に対応するレコードを一意に識別するＰＯＮｕｍ引数と、テーブル中の列ごとに１つのパラメータを受け付ける。このストアドプロシージャの複数の引数により、レコードの更新または挿入を試みる前に、その呼び出しについての名前と値の対が（データを収集するアプリケーションプログラムのトランザクションロジックに基づいて）メモリに蓄積されることが可能になる。データベースレコードをロックして、そのレコードにアクセスするのに必要とされる処理オーバーヘッドのために、１つのコマンドでレコードの可能な限り多くの部分を更新（または挿入）する方が効率的である。ストアドプロシージャは初めに、あるＰＯについての何らかのデータがテーブルに存在すると仮定して、「更新」のステートメントを発行することによりレコードの非ヌルの列をオーバーライドすることを試みる。ここで関数「ｃｏａｌｅｓｃｅ」が使用され、この関数は最初の非ヌルの引数を返す。更新されたレコードがない場合（＠＠ｒｏｗｃｏｕｎｔ＝０）は、それがその購入注文に関連する最初の情報であることになり、すべての引数の値を持つレコードが挿入される（それらの引数がヌルであっても）。

Inside Microsoft(R) SQL SERVERTM 2000 by Karen Delaney (2001 Microsoft Press) Microsoft(R) SQL SERVERTM 2000 Books Online

付録Ａのようなストアドプロシージャ(stored procedure)は、テーブルへの書き込みを試みるユーザまたはプログラミングスレッドが比較的少ない場合、および比較的レコードが少ない場合には十分である。不都合なことに、図３に示すように、テーブル中のレコード数が増加するに従って時間の経過とともにパフォーマンスが低下する。実線は、書き込みパフォーマンス(write perfomance)、すなわち１秒間に書き込まれることができるレコード数を表し、これは低レベルまで急速に低下する。逆に、ディスクＩ／Ｏの平均キュー長（点線）は、短時間で許容できる限界以上まで増大する。このパフォーマンスの低下は、テーブルサイズの増大の結果生じる。レコード数が比較的少ない時には、パフォーマンスは、まず、データベースサーバがトランザクションを行うことができる速度によって制限され、この速度はサーバの中央演算処理装置の容量によって決まる。時間の経過とともにレコード数が増えると（より多くの購入注文が受け取られ、処理されると）、パフォーマンスは急激に低下する。例えば、付録Ａのストアドプロシージャの更新ステートメントが最初に実行されると、テーブル（図２）の一部がディスク（あるいは他の不揮発性メモリソース）からＲＡＭ（あるいは他のメモリシステム）に読み込まれる。総レコード数が少ない限り、サーバは、必要とされるデータの大半あるいはすべてをシステムメモリにキャッシュすることができる。後の更新で、システムメモリにすでにキャッシュされたレコードへのアクセスが必要となった場合、サーバはディスクを再度読み取る必要はない。しかし、レコード数がメモリ容量を超えると、各動作でディスクの物理的な読み取りが必要となる可能性がある。使用されるハードウェアによっては、ディスクの読み取り中はテーブルに対する他の照会（またはテーブルの更新）が妨げられる可能性がある。最終的に、その結果、応答時間がすべてのユーザにとって許容できないほど低速度になる。この問題は、オンライン分析処理（ＯＬＡＰ: On-Line Analytical Processing）やＯＬＡＰキューブ(cube)の作成など、テーブル中のデータのより複雑な操作が行われなければならない場合に悪化する可能性がある。

本発明は、アクティビティ(activity)の複数のインスタンス(instance)についての情報を保持(maintain)することに伴う上記および他の問題に対処する。本発明の一態様では、組織のアクティビティ(organization's activity)のアクティブなインスタンス(active instance)に対応するデータと、組織のアクティビティの非アクティブなインスタンス(inactive instance)に対応するデータに別個のデータベーステーブルが維持(maintain)される。別の態様では、アクティビティの非アクティブなインスタンスに対応するデータに対して複数のデータベーステーブルが維持されることができる。さらに別の態様では、アクティブインスタンステーブルのデータと、１つまたは複数の非アクティブなインスタンスのテーブルのデータが処理されて、組み合わされた分析データを生成する。

一実施形態では、本発明は、アクティビティの複数のインスタンスに関する情報を保持する方法を含む。各アクティビティインスタンスは、そのインスタンスについての情報が変更されるアクティブ状態か、またはそのインスタンスについての情報が変更されない非アクティブ状態を有する。本発明は、アクティブ状態にある複数の各インスタンスに対して第１のデータベーステーブルにレコードを作成することを含み、各レコードは、複数のデータタイプそれぞれに対応するフィールドを含み、各アクティブインスタンスのレコード中のフィールドの１つまたは複数は、アクティブ状態を表す値を有する。本方法はさらに、非アクティブ状態にある複数のインスタンスの各レコードについて、非アクティブ状態を表す値を１つまたは複数のフィールドに割り当てることを含む。本方法は、１つまたは複数のフィールドに非アクティブ状態を表す値を有する複数のインスタンスのレコードを第１のテーブルから削除すること、ならびに第１のテーブルから削除された各レコードに対して、対応するレコードを第２のデータベーステーブルに作成することも含む。

別の実施形態で、本方法は、第３およびそれに続くデータベーステーブルを作成すること、ならびに、後に続くデータベースを作成すると、１つ前に作成されたテーブルにレコードを作成することを中止することを含む。最後に作成されたテーブルを作成した後、かつその次の別のテーブルを作成する前に第１のテーブルから削除された各レコードについて、対応するレコードが最後に作成されたテーブルに作成される。さらに別の実施形態では、本方法は、第１のテーブルのレコードに第１のオンライン分析処理（ＯＬＡＰ）キューブを生成し、第２のテーブルのレコードに第２のＯＬＡＰキューブを生成し、第１のキューブと第２のキューブを組み合わせて仮想ＯＬＡＰキューブとすることを含む。

本発明のこれらおよび他の特徴および利点は、添付図面と併せて以下の好ましい実施形態の詳細な説明を読むことにより容易に明らかになり、完全に理解されよう。

仮想の企業による顧客の購入注文の処理を示すフローチャートである。仮想企業のデータベースの一部を示す図である。時間の経過に伴うデータベースシステムのパフォーマンスの低下を示す線図である。本発明の少なくとも１つの実施形態によるアクティブインスタンスのデータと完了インスタンスのデータについての別個のテーブルを示す図である。本発明の少なくとも１つの実施形態による、まだ進行中のアクティビティについてのレコードを含むデータベーステーブルの一部を示す図である。本発明の少なくとも１つの実施形態による、完了アクティビティのレコードを含むデータベーステーブルの一部を示す図である。本発明の別の実施形態による、アクティブなインスタンスデータと完了インスタンスデータについての別個のテーブルを示す図である。本発明の少なくとも１つの実施形態による、アクティブインスタンスのデータと完了インスタンスのデータを組み合わせたＯＬＡＰ分析のデータ処理の流れを示す図である。

本発明は、２００２年５月３１日に出願された、「Support for Real-Time Queries Concerning Current State, Data and History of a Process」という名称の米国特許出願第１０／１５７，９６８号明細書に記載される方法、装置、およびシステムと組み合わせて有利に使用されることができる。同文献の内容は参照により本明細書に組み込まれる。

本発明は、構造化照会言語（ＳＱＬ）命令、およびワシントン州レドモンドのマイクロソフト社から入手可能なＳＱＬＳＥＲＶＥＲ（商標）２０００リレーショナルデータベース管理システム（ＲＤＢＭＳ）ソフトウェアとそれに関連付けられたＯｎｌｉｎｅＡｎａｌｙｔｉｃａｌＰｒｏｃｅｓｓｉｎｇ（ＯＬＡＰ）サービスソフトウェアで得られるおよび他のデータ分析機能を参照して説明される。ここでは本発明の特定の実施形態を実施するために使用されることができるＳＱＬ命令のいくつかの態様が記載されるが、本発明を実施するために使用される他の命令、プログラミングアルゴリズム、およびプロシージャは、本明細書に提供される説明を得れば当業者には明らかになろう。ＳＱＬＳＥＲＶＥＲ（商標）２０００ＲＤＢＭＳソフトウェアおよびそれに関連付けられたＯＬＡＰサービスソフトウェアについての一般的な説明を＜http://www.microsoft.com/sql/techinfo/productdoc/2000/＞で入手可能な（非特許文献１）および（非特許文献２）を含む各種情報源から得ることができる。本発明は、ＳＱＬＳＥＲＶＥＲ（商標）２０００ＲＤＢＭＳソフトウェアとそれに関連付けられたＯＬＡＰサービスソフトウェアを使用した実施に限定されず、他のタイプのＲＤＢＭＳおよびＯＬＡＰソフトウェアを使用して実施されることができる。

本発明は、サーバ上で動作し、１つまたは複数のクライアントからアクセスされるＲＤＢＭＳソフトウェア（上述のＳＱＬＳＥＲＶＥＲ（登録商標）２０００ソフトウェアなど）を参照しても説明される。そのような構成は、当技術分野で知られ、記載される（前に組み込まれた米国特許出願第１０／１５７，９６８号明細書参照）。ただし、クライアント−サーバ構成は、本発明が実施されることができる方式の一例に過ぎない。本発明は、他の物理的システム構成でも実施されることができる。

本発明は、組織のアクティビティのアクティブなインスタンスに対応するデータと、限られた数の非アクティブなインスタンスに別個のテーブルを維持することにより、上記の問題の多くに対処する。例えば、多くの組織では、最も重要なアクティビティは、現在懸案中のアクティビティ、または最近完了されたアクティビティである。図１〜図３との関係で述べた仮想の企業Ａの例に基づくと、企業Ａの責任者は、現在まだ処理中の購入注文、すなわちまだ商品が配達されていない購入注文に最も関心がある。責任者はまた、比較的最近の期間に完了された（すなわち注文商品が過去数カ月内に配達された）購入注文にも関心がある。企業Ａは本発明を説明するために作った仮想例であるが、実際の企業が、また処理過程にあるか、最近完了したインスタンスに関心を持つことは一般的である。例えば、多くの企業では、配達された商品に関する苦情の大半および支払い金の回収に関する問題の大半は、配達後の短い期間内に発生する。より前の期間内に履行された注文についてのデータが何らかの目的で必要とされる可能性はあるが、その必要性が生じるのは比較的まれである。同様に、多くの他のタイプの企業および組織も、まだ完了していないアクティビティのインスタンスと、限られた数の最近完了したアクティビティインスタンスに最も関心を持つ。

したがって、企業Ａ(Business A)は、アクティブな注文と最近完了した注文についてのデータを別々のデータベーステーブルに保持(maintain)する。それらのテーブルの内容をアクティブな注文と最近完了した注文に限定することにより、データ量が比較的少なく保たれる。このようにすると、アクティブなインスタンスデータについてのテーブルを更新する、あるいはその他の理由でテーブルにアクセスする際のシステムパフォーマンスが図３に示すようには低下せず、完了インスタンスのテーブルにアクセスする際のパフォーマンスが低下しない。これは、このテーブルのレコードは挿入されるのみで、更新されることはないためである。図３の例と異なり、全体のパフォーマンスは時間の経過に伴い安定している。図４は、この概念を表すブロック図である。テーブル１０は、アクティブな購入注文に関するデータについてのレコードを保持する。この例では、購入注文は、購入注文によって注文された商品がまだ顧客に配達されていない場合にアクティブとする。組織アクティビティのアクティブなインスタンスは、他の状況では別の形で定義されることが可能である。購入注文が完了されると、その購入注文のデータがテーブル１２に移される。この例では、購入注文は、注文された商品が顧客に配達された時に完了する。アクティブなインスタンスと同様に、組織アクティビティの完了したインスタンスも他の状況では異なる形で定義されることができる。

新しい購入注文が受け取られると、テーブル１０にレコードが作成される。図４にはテーブル１０をブロックの形態で示し、図５は、テーブル１０の一部をより詳細に示す。図２のテーブルと同様に、テーブル１０は、各購入注文についての個々のレコード（行）と、各種タイプのデータについての個々のフィールド（列）を有する。この例では、「ＰＯＮｕｍ」が購入注文番号である。「ＲｅｃｖＴｉｍｅ」は購入注文が受け取られた日付であり、「Ｃｉｔｙ」は購入注文を発行した顧客が居住する都市であり、「Ｑｕａｎｔｉｔｙ」は注文された品目の数である。「ＳｈｉｐＴｉｍｅ」は、購入注文の商品が発送された日付であり、「ＤｅｌｉｖｅｒｙＴｉｍｅ」は、その商品が配達された日付である。商品がまだ発送されていない注文は、ＳｈｉｐＴｉｍｅフィールドに＜ＮＵＬＬ＞の入力を有する。図５のレコードの一部は、商品がまだ発送されていない購入注文を示す（ＰＯＮｕｍ８６８０および８６８５〜８７）。その購入注文の商品が発送されると「ＳｈｉｐＴｉｍｅ」フィールドが更新される。図２のテーブルと異なり、テーブル１０は、現在アクティブな購入注文、すなわち商品が配達されていない購入注文についてのデータに限定される。したがって、各レコードの「ＤｅｌｉｖｅｒｙＴｉｍｅ」フィールドは、ＮＵＬＬの入力を有する。テーブル１０は、「ＩｓＣｏｍｐｌｅｔｅｄ」フラグのための追加のフィールドも有する。０のＩｓＣｏｍｅｌｅｔｅｄ値は、対応する購入注文が完了されていないことを表す。一部の実施形態では、ＩｓＣｏｍｐｌｅｔｅｄは、テーブルを照会するユーザには表示されない「システム」フラグである。

購入注文が完了すると、その購入注文のレコードがアクティブなインスタンスデータのテーブル１０から削除され、その購入注文の新しいレコードが完了インスタンスデータテーブル１２に作成される（図４）。その新しいレコードは、テーブル１０から削除されたレコードの複製であるが、ＤｅｌｉｖｅｒｙＴｉｍｅのＮＵＬＬ値に優先する新しいデータを含み、ＩｓＣｏｍｐｌｅｔｅｄフィールドを持たない。図６は、テーブル１２の一部をより詳細に示す。図２および５のテーブルと同様に、テーブル１２は、完了した各購入注文についての個々のレコードと、上記の各種タイプのデータについての個々のフィールド（ＰＯＮｕｍ、ＲｅｃｖＴｉｍｅ、Ｃｉｔｙ、Ｑｕａｎｔｉｔｙ、ＳｈｉｐＴｉｍｅ、およびＤｅｌｉｖｅｒｙＴｉｍｅ）を有する。この例では購入注文は注文商品が配達された時に完了するように定義されるので、テーブル１２のＤｅｌｉｖｅｒｙＴｉｍｅフィールドはそれぞれ非ＮＵＬＬの値を有する。テーブル１２は、「ＲｅｃｏｒｄＩＤ」のための追加のフィールドを有する。下記でより詳細に説明するように、この値は、完了した購入注文についての各レコードがテーブル１２に作成される時に増分的に生成される。図６のＰＯＮｕｍフィールドとＲｅｃｏｒｄＩＤフィールドの比較から分かるように、購入注文は、必ずしも、購入注文番号が割り当てられる順序と同じ順序で完了されない。したがって、ＲｅｃｏｒｄＩＤフィールドは、レコードが作成された順序でテーブル１２のレコードを索引付けする機構を提供する。これにより、挿入のパフォーマンスがテーブルのサイズに依存しなくなり、したがって時間の経過とともに低下しないことが保証される。

テーブル１０は現在アクティブな購入注文についてのデータに限定されるので、テーブル１０のサイズは比較的小さいサイズを保つ。テーブルのサイズは企業の業務量が変動するのに伴って変動する可能性があるが、テーブルのサイズは無限に増大することはない。完了インスタンスデータテーブル１２のサイズは、より多くの購入注文がＡｃｔｉｖｅ／Ｉｎｃｏｍｐｌｅｔｅの状態からＩｎａｃｔｉｖｅ／Ｃｏｍｐｌｅｔｅの状態に変化するのに従って増大する。ただし、完了インスタンスデータのテーブル１２の増大は、アクティブなインスタンスと非アクティブなインスタンス両方についてのレコードを含む単一のデータベーステーブル（図２のようなテーブル）の増大ほど問題とならない。テーブル１２にはレコードが挿入されるのみで、その後更新されることはないため、テーブル１２にアクセスするたびに特定のレコードを探索する必要がない。すなわち、レコードが更新中であることがないので、レコードを挿入する前にテーブル１２内で特定のレコードを見つける必要がない。

図４〜図６のテーブルを作成し、更新するＳＱＬコードの一例が付録ＢおよびＣに含まれる。付録Ｂの最初のステートメント（「ｃｒｅａｔｅｔａｂｌｅＰＯ＿Ａｃｔｉｖｅ＿ＩｎｓｔａｎｃｅＤａｔａ」）は、アクティブインスタンスデータのテーブル１０を作成し、ＰＯＮｕｍ、ＲｅｃｖＴｉｍｅ、Ｃｉｔｙ、Ｑｕａｎｔｉｔｙ、ＳｈｉｐＴｉｍｅ、ＤｅｌｉｖｅｒｙＴｉｍｅ、およびＩｓＣｏｍｐｌｅｔｅｄの列を設定する。ＰＯＮｕｍがプライマリキーに指定される。すなわち、テーブル１０の各行は、購入注文番号、すなわちＰＯＮｕｍによって一意に識別される。同様に、次のステートメント（「ｃｒｅａｔｅｔａｂｌｅＰＯ＿Ｃｏｍｐｌｅｔｅｄ＿ＩｎｓｔａｎｃｅＤａｔａ」）は、完了インスタンスデータのテーブル１２を作成し、ＰＯＮｕｍ、ＲｅｃｖＴｉｍｅ、Ｃｉｔｙ、Ｑｕａｎｔｉｔｙ、ＳｈｉｐＴｉｍｅ、ＤｅｌｉｖｅｒｙＴｉｍｅ、およびＲｅｃｏｒｄＩＤの列を設定する。ただしテーブル１２ではＲｅｃｏｒｄＩＤがプライマリキーとされ、ＲｅｃｏｒｄＩＤには、ＳＱＬの「ｉｄｅｎｔｉｔｙ」プロパティを使用することにより、自動的に増分する値が与えられる。すなわち、ＰＯ＿Ｃｏｍｐｌｅｔｅｄ＿ＩｎｓｔａｎｃｅＤａｔａと名づけるテーブル（テーブル１２）に新しい各レコードが追加されると、データベースサーバは１つ前のＲｅｃｏｒｄＩＤ値を自動的に増分し、増分された値を追加されたレコードに挿入する。

次のステートメント「（ｃｒｅａｔｅｐｒｏｃｅｄｕｒｅＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔ）」は、テーブル１０に新しいレコードを作成するか、またはテーブル１０の既存のレコードを更新するために用いられるＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔという名前のストアドプロシージャを作成する。ＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔストアドプロシージャは、テーブル１０の１行の列に対応する５つの引数を有する。例えば、図５で購入注文８６８０を受け取ると、クライアントコンピュータは、データベースサーバに対して次のストアドプロシージャ呼び出しを発行する。

ＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔ（８６８０，０８／２５／２００３１７：１９，Ｒｅｄｍｏｎｄ，２７０．．．）
購入注文８６８１がそれまでＰＯＮｕｍ、ＲｅｃｖＴｉｍｅ、Ｃｉｔｙ、およびＱｕａｎｔｉｔｙのデータとともに入力されていた場合は、次のストアドプロシージャの呼び出しで発送時刻（ＳｈｉｐＴｉｍｅ）を０８／２６／２００３０９１０に更新する。

ＰＯＰｒｉｍａｒｙＩｍｐｏｒｔ（８６８１．．．．０８／２６／２００３０９１０，，）
０８／２６／２００３午後１２時の配達時刻（ＤｅｌｉｖｅｒｙＴｉｍｅ）を反映するように購入注文８６８２のレコードを更新し、この購入注文を完了としてフラグで表す（ＩｓＣｏｍｐｌｅｔｅｄ＝１）には、次の呼び出しが行われる：
ＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔ（８６８２，，，，，０８／２６／２００３１２００，１）
上記の情報をクライアントコンピュータに入力する人間のオペレータは、必ずしも上記のコマンドの１つをタイプ入力しないことに留意されたい。例えば、ユーザは、グラフィカルユーザインタフェースを介して情報を入力することができ、すると中間ソフトウェア（クライアントおよび／またはサーバで実行される）の１つまたは複数のレベルが、適切な構文でストアドプロシージャ呼び出しを生成する。別の例として、インターネットを介して自動的に注文が受け取られることができ、ウェブサーバソフトウェアが必要なＳＱＬコマンドを生成することもできる。

ＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔのストアドプロシージャは、当該ストアドプロシージャに対する呼び出しから値を受け付け、それらの値を、ローカル変数＠ＰＯＮｕｍ、＠ＲｅｃｖＴｉｍｅ、＠Ｃｉｔｙ、＠Ｑｕａｎｔｉｔｙ、＠ＳｈｉｐＴｉｍｅ、＠ＤｅｌｉｖｅｒｙＴｉｍｅ、および＠ＩｓＣｏｍｐｌｅｔｅｄの１つまたは複数に割り当てる。次いで、ストアドプロシージャは、「挿入(insert)」ステートメントを介してそれらのローカル変数値をＰＯ＿Ａｃｔｉｖｅ＿ＩｎｓｔａｎｃｅＤａｔａテーブル（テーブル１０）に挿入することを試みる。ただし、それらのローカル変数を新しいレコードとしてテーブル１０に挿入するのではなく、次いで付録Ｃのトリガ（「ＰＯ＿ＣｏｍｐｌｅｔｅｄＴｒｉｇｇｅｒ」）が発動(fire)される。

付録Ｃを参照すると、ローカルの＠ＰＯＮｕｍ変数および＠ＩｓＣｏｍｐｌｅｔｅｄ変数を宣言した後、トリガは「挿入後の(inserted)」システムテーブルからそれらの変数に値を割り当てる。挿入後のテーブルは自動的にデータベースサーバによって生成され、前に行われたＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔストアドプロシージャの挿入ステートメント中に影響を受けた行のコピーを（ＲＡＭまたは他のシステムメモリに）一時的に格納する。この場合、挿入後のテーブルは、ＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔストアドプロシージャで渡された引数のコピーを含んでいる。すなわち、挿入後のテーブルは、ユーザが現在テーブル１０に挿入あるいは更新しようとしている値を含む。

トリガはまず、渡されたＩｓＣｏｍｐｌｅｔｅｄビットの値が１に等しいかを調べ、１の場合は渡されたＰＯＮｕｍ値のレコードが完了していることを意味する。ＩｓＣｏｍｐｌｅｔｅｄビットが１に等しい場合、トリガは次いで、完了した購入注文のレコードの値をＰＯ＿Ｃｏｍｐｌｅｔｅｄインスタンスデータテーブル１２の新しいレコードに挿入する。新しいテーブル１２のレコードのＰＯＮｕｍの値は、挿入後のテーブルから得られる（「ｓｅｌｅｃｔｉｎｓｅｒｔｅｄ．ＰＯＮｕｍ」）。「ｃｏａｌｅｓｃｅ」関数が使用されて、ＲｅｃｖＴｉｍｅ、Ｃｉｔｙ、Ｑｕａｎｔｉｔｙ、ＳｈｉｐＴｉｍｅ、およびＤｅｌｉｖｅｒｙＴｉｍｅの新しいテーブル１２のレコードの値を得る。詳細には、ｃｏａｌｅｓｃｅ関数は、自身の引数の中から最初の非ヌルの式を返す。例えば、「ｃｏａｌｅｓｃｅ（ｉｎｓｅｒｔｅｄ．ＲｅｃｖＴｉｍｅ，ｐｏ．ＲｅｃｖＴｉｍｅ）」は、新しいテーブル１２のレコードのＲｅｃｖＴｉｍｅの値を提供する。トリガはまず、挿入後のテーブルのＲｅｃｖＴｉｍｅの値が非ＮＵＬＬであるかどうかを調べる。非ＮＵＬＬである場合は、その値が新しいテーブル１２のレコード中のＲｅｃｖＴｉｍｅの値として使用される。挿入後のテーブルのＲｅｃｖＴｉｍｅの値がＮＵＬＬである場合は、トリガは、ユーザがＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔのストアドプロシージャの呼び出しで挿入または更新しようとしていたテーブル１０のレコードからＲｅｃｖＴｉｍｅの値を得る。ｃｏａｌｅｓｃｅ関数の引数の１つは、コード部分「ｆｒｏｍｉｎｓｅｒｔｅｄｌｅｆｔｊｏｉｎＰＯ＿Ａｃｔｉｖｅ＿ＪｎｓｔａｎｃｅＤａｔａｐｏｏｎｉｎｓｅｒｔｅｄ．ＰＯＮｕｍ＝ｐｏ．ＰＯＮｕｍ」により必ず非ＮＵＬＬになる。詳細には、トリガコードのこの部分は、ｃｏａｌｅｓｃｅ関数の各呼び出しにおける引数の値が、「挿入後」のテーブルのすべての行と、ＰＯＮｕｍの値が挿入後のテーブルのＰＯＮｕｍの値と同じであるＰＯ＿Ａｃｔｉｖｅ＿ＩｎｓｔａｎｃｅＤａｔａテーブル（テーブル１０）のすべての行とからなるセットから得られることを指定する。例えば、ＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔのストアドプロシージャが呼び出されて自身のすべての引数に非ＮＵＬＬの値を渡した場合（すなわちその購入注文の商品が、その購入注文についてのデータが最初にシステムに入力された時点までに配達されている場合）、新しいテーブル１２のレコードのＲｅｃｖＴｉｍｅの値は、挿入後のテーブルから得られることになる。しかし、ＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔストアドプロシージャが呼び出されて、ＲｅｃｖＴｉｍｅの値がすでに存在するテーブル１０中の既存レコードを更新した場合（すなわちＲｅｃｖＴｉｍｅの値がＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔストアドプロシージャの呼び出しで渡されなかった場合）は、新しいテーブル１２のレコードのＲｅｃｖＴｉｍｅの値は、テーブル１０のその既存レコードから得られることになる。

ＲｅｃｖＴｉｍｅの値を得ると、トリガは同様に、Ｃｉｔｙ、Ｑｕａｎｔｉｔｙ、ＳｈｉｐＴｉｍｅ、およびＤｅｌｉｖｅｒｙＴｉｍｅのフィールドについて新しいテーブル１２のレコードの値を得る。先に述べたように、サーバが自動的にＲｅｃｏｒｄＩＤフィールドの値を供給する。トリガは次いで、完了した購入注文についてテーブル１０のレコードを削除する（「ｄｅｌｅｔｅｆｒｏｍＰＯ＿Ａｃｔｉｖｅ＿ＩｎｓｔａｎｃｅＤａｔａｗｈｅｒｅＰＯＮｕｍ＝＠ＰＯＮｕｍ」）。ここでトリガは終了する（「ｒｅｔｕｒｎ」）。

トリガを発動したＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔストアドプロシージャの呼び出しで０のＩｓＣｏｍｐｌｅｔｅｄ値が渡された場合、トリガはテーブル１２に新しいレコードを作成しない。代わりに、トリガは、ＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔストアドプロシージャに対する呼び出し中で識別されたテーブル１０のレコードを更新することを試みる（「ｕｐｄａｔｅＰＯ＿Ａｃｔｉｖｅ＿ＩｎｓｔａｎｃｅＤａｔａ」）。テーブル１２に新しいレコードを作成するトリガの部分と同様に、ｃｏａｌｅｓｃｅ関数が使用されて、挿入後のテーブルまたはテーブル１０の既存のレコードから、更新後のテーブル１０のレコードの値を得る。ただし、この場合は、ｃｏａｌｅｓｃｅ関数の引数の値は、コード「ｆｒｏｍＰＯ＿Ａｃｔｉｖｅ＿ＩｎｓｔａｎｃｅＤａｔａｐｏｊｏｉｎｉｎｓｅｒｔｅｄｏｎｐｏ．ＰＯＮｕｍ＝ｉｎｓｅｒｔｅｄ．ＰＯＮｕｍ」によって提供される。詳細には、トリガコードのこの部分は、ｃｏａｌｅｓｃｅ関数の引数の値が、ＰＯ＿Ａｃｔｉｖｅ＿ＩｎｓｔａｎｃｅＤａｔａテーブル（テーブル１０）のすべての行と、ＰＯＮｕｍの値が同じである「挿入後」のテーブルのすべての行とからなるセットから得られることを指定する。

ＰＯ＿ＰｒｉｍａｒｙＩｍｐｏｒｔストアドプロシージャ（付録Ｂ）が呼び出されて、新しい、まだ完了していないレコードをテーブル１０に追加した（すなわち商品がまだ配達されていない新しい購入注文のレコードを挿入した）場合は、トリガコードの「ｕｐｄａｔｅＰＯ＿Ａｃｔｉｖｅ＿ＩｎｓｔａｎｃｅＤａｔａ」の部分で更新される値はない。そのような場合は、ＰＯＮｕｍの値が挿入後のＰＯＮｕｍの値と同じである既存のレコードがテーブル１０にはないことになり、したがってテーブル１０に更新すべきレコードがないことになる。テーブル１０で更新されるレコードがない場合、またはテーブル１２で挿入されるレコードがない場合、トリガは、これを＠＠ｒｏｗｃｏｕｎｔシステム関数で検出する。詳細には、＠＠ｒｏｗｃｏｕｎｔ関数は、前に行われた更新ステートメントで影響された行がない場合は０の値を返す。＠＠ｒｏｗｃｏｕｎｔ関数が０を返す場合、トリガコードの「ｉｎｓｅｒｔＰＯ＿Ａｃｔｉｖｅ＿ＩｎｓｔａｎｃｅＤａｔａｓｅｌｅｃｔ＊ｆｒｏｍｉｎｓｅｒｔｅｄ」部分は、「挿入後」のテーブルの値を用いてテーブル１０に新しいレコードを挿入する。

本発明の別の実施形態では、完了インスタンスデータテーブルのデータ量が制限される。上述のように、このテーブル（図４のテーブル１２）の増大は、テーブル２のようなテーブルの増大ほど問題とならない。しかし、それでもテーブル４は時間の経過とともに増大し続ける。テーブルのレコードが一切更新されない場合（すなわちレコードが挿入されるのみの場合）、テーブルは最終的には非常に大きくなり、システムディスクの容量が超えられるか、またはテーブル中のデータに対する照会が完了するのに許容できないほど長い時間がかかるようになる。先に述べたように、企業Ａの責任者は、完了した購入注文のデータは、比較的最近完了した購入注文のみについて必要であると判断している。しかし、テーブル１２からのレコードの削除には時間がかかる可能性がある。多くのソフトウェア環境では、そのような削除は行単位で行われなければならない。すなわちレコードごとに行ロックを得、その行が完了とマークされなければならない。実際には、行を削除するには、行を挿入または更新する際と同等の時間が必要となる可能性がある。

したがって、図７に示すように、完了インスタンスデータについて複数のテーブルが作成される。この実施形態では、付録ＢおよびＣのコードが先に説明したように動作してテーブル１０から完了した購入注文のレコードを削除し、テーブル１２にそれに対応する新しいレコードを作成する。ただし、テーブル１２は無制限に増大することは許されない。周期的な間隔（例えば毎月など）で、テーブル１２は、一意のパーティション名で名前が付け替えられ、その名前を付け替えたテーブルにはそれ以上のレコードは追加されない。そして、名前を変更したテーブルの以前の名前を持つ新しい（空の）テーブル１２（「ＰＯ＿Ｃｏｍｐｌｅｔｅｄ＿ＩｎｓｔａｎｃｅＤａｔａ」）が作成される。これ以降、トリガは、新しいテーブルにレコードを挿入する。１カ月後（あるいは他の事前に選択された期間後）にこのテーブルも名前を付け替えられ、別のテーブル１２が作成される。名前を付け替えたテーブルが選択された期間（例えば６カ月）にわたり保持されると、テーブル全体が削除される。個々のレコードの削除と異なり、テーブル全体は迅速に削除されることができる。一実施形態では、テーブルは、ＳＱＬの「ｄｒｏｐｔａｂｌｅ」コマンドを使用して除去される。完了インスタンスデータテーブルが削除される際、そのテーブル中のデータは必ずしも失われない。例えば、削除されたテーブルは、ｄｒｏｐｔａｂｌｅ関数を呼び出す前にテーブル中のデータをテープまたは他のタイプの記憶媒体に転送することにより保管されることができる。他の実施形態では、周期的な間隔で新しいテーブル１２を作成するのではなく、テーブル１２のサイズがあるレベルに達すると新しいテーブル１２が作成される。

アクティブインスタンステーブルと完了インスタンステーブル(completed instance table)のすべてのデータを利便に閲覧および照会できるように（すなわち個々のテーブルごとに別個の照会が必要でないように）、アクティブインスタンスと完了インスタンスのテーブル（あるいはそれらのテーブルの何らかの所望の下位グループ化）がパーティションに分割された１つのビューにまとめられることができる。少なくとも１つの実施形態では、テーブルは、「ｕｎｉｏｎａｌｌｓｅｌｅｃｔ＊．．．」のＳＱＬステートメントで組み合わせることができる。テーブルを組み合わせたこのビューは、完了インスタンスデータテーブルの１つが除去されるたび（あるいは、新しい完了インスタンスデータテーブルが作成されるたび）に、再度作成されることができる。

本発明の別の態様では、アクティブなインスタンステーブルおよび完了インスタンステーブルのデータがさらに処理されて追加の分析データを提供する。例示として、企業Ａが、現在アクティブな購入注文データと、最近完了した購入注文のデータをまとめて分析したいとする。企業Ａは、例えば、組み合わせられたデータの１つまたは複数のＯＬＡＰキューブを作成したいと考える。ここでも、本発明を説明するために用いる企業Ａの仮想的な性質に関わらず、実際の組織は、組織のアクティビティのアクティブなインスタンスと完了インスタンスの両方を反映するＯＬＡＰキューブを生成する必要性も有する。

図８は、少なくとも１つの実施形態における、アクティブインスタンスと完了(completed)インスタンスのデータを組み合わせたＯＬＡＰ分析のデータ処理の流れを示す。ストアドプロシージャ（「ＢｅｇｉｎＤａｔａＰｒｏｃｅｓｓｉｎｇ」）が周期的な間隔で、例えば毎晩実行される。このプロシージャはまず、アクティブインスタンスデータテーブル（テーブル１０）のコピーを作成する。このテーブルは比較的小さく保たれるので、このコピーは、比較的迅速に作成されることができる。次いで、そのコピー中のデータがデータ変換サービス（ＤＴＳ）（図示せず）に渡されて、スタースキーマに入れられ、次いで完全に処理されてアクティブインスタンスデータのＯＬＡＰキューブ３０とされる。ＢｅｇｉｎＤａｔａＰｒｏｃｅｓｓｉｎｇのストアドプロシージャは、増分ウィンドウ中にある完了インスタンスデータの一部も得る。詳細には、ＢｅｇｉｎＤａｔａＰｒｏｃｅｓｓｉｎｇプロシージャが完了インスタンスデータを得るたびに、データベースサーバは、得られた最後のレコードのＲｅｃｏｒｄＩＤ値を記憶する。先に述べたように、この値は、レコードが作成された際にサーバによって増分的に割り当てられたものである。前回のＢｅｇｉｎＤａｔａＰｒｏｃｅｓｓｉｎｇプロシージャの実行中に得られた最後の完了インスタンスデータレコードの記憶されたＲｅｃｏｒｄＩＤ値を参照することにより、その前回の実行以降に作成されたレコードだけが現在の操作で得られる。増分ウィンドウは、アクティブなインスタンスデータと完了インスタンスデータについての複数のテーブル／パーティションを含む、パーティション化されたビューの上に作成される特別なビューとして実施される。このようにして、増分ウィンドウは、複数のパーティションからのデータを含むことができる。例えば、ＢｅｇｉｎＤａｔａＰｒｏｃｅｓｓｉｎｇプロシージャが週に一度実行される場合は、前回のＢｅｇｉｎＤａｔａＰｒｏｃｅｓｓｉｎｇストアドプロシージャの実行以降に新しい完了インスタンスデータテーブルが作成されていて、複数の完了インスタンスデータテーブルからのデータが処理される必要がある可能性がある。少なくとも１つの実施形態では、ＢｅｇｉｎＤａｔａＰｒｏｃｅｓｓｉｎｇストアドプロシージャは、アクティブインスタンスデータテーブルのコピーと、完了インスタンスデータテーブルからのレコードを同時に取得する。そうでない場合は、ＢｅｇｉｎＤａｔａＰｒｏｃｅｓｓｉｎｇプロシージャによりコピーした後に、完了インスタンスデータテーブルからのレコードを得る前に、アクティブインスタンスデータテーブルから購入注文が移されることもできる。これが行われる場合は、同じ購入注文が２度処理され、データ分析の精度が損なわれることになる。

ＢｅｇｉｎＤａｔａＰｒｏｃｅｓｓｉｎｇプロシージャは、前回ＢｅｇｉｎＤａｔａＰｒｏｃｅｓｓｉｎｇが実行されて以降に作成された増分していく完了インスタンスデータレコードをＤＴＳに渡す。ＤＴＳは次いで、その増分データを、完了インスタンスデータの以前の処理からのデータをすでに含んでいるスタースキーマに入れる。そして、完了インスタンスデータのスタースキーマ（その時点で、最近完了したインスタンスデータレコードからの増分データを含んでいる）が使用されて完了インスタンスのＯＬＡＰキューブ３２を更新する。完了インスタンスのスタースキーマと同様に、ＯＬＡＰキューブ３２は、以前のセッションで処理されたレコードについての情報を含んでいる。次いでＯＬＡＰキューブ３０と３２が組み合わされて単一の仮想ＯＬＡＰキューブ３４とされる。ＯＬＡＰキューブ３２が情報を含んでいる完了レコードの数は、時間の経過とともに非常に多くなる可能性がある。しかし、完了インスタンスデータを増分的に処理し、その処理の結果を以前に処理された完了インスタンスデータと組み合わせることにより、比較的少ない時間量でＯＬＡＰキューブ３２（およびしたがって仮想ＯＬＡＰキューブ３４）が生成されることができる。すなわち、完了インスタンスデータの再処理が防止されることができる。

仮想(virtual)ＯＬＡＰキューブ３４は、ユーザに、過去の購入注文と進行中（すなわちアクティブな）購入注文両方についての情報を含む企業の「スナップショット」を提供する。キューブ３０〜３４を処理するデータ変換サービス（ＤＴＳ）パッケージが、夜間または他のオフピーク時に実行されるようにスケジュールされることができる。

本発明について仮定的な企業タイプを一例として使用して説明したが、本発明は特定のタイプの企業、組織、あるいはアクティビティに限られないことを思い出されたい。実際、本発明は、完了インスタンスデータが完了インスタンスデータの経過時間に基づいて保持される実施に限定されない。過去数カ月の間に完了した購入注文についてのデータを保持する代わりに、別の組織は、迅速にアクセスできるように非アクティブなインスタンスデータを保持するために何らかの他の基準を使用することができる。単なる一例として、調査会社が、いくつかの土地区画についてのデータには迅速にアクセスしたいが、他の区画についてのデータにはあまり頻繁にアクセスしない場合がある。したがって、本発明を実施する特定の例について説明したが、当業者は、特許請求の範囲に述べられる本発明の主旨および範囲に該当する上記のシステムおよび技術の多数の変形例および交換例があることを理解されよう。それらおよびその他の変更は、頭記の特許請求の範囲で定義される本発明の範囲内にある。

１０アクティブインスタンスデータ
１２完了インスタンスデータ

Claims

中央処理装置（ＣＰＵ）と、メモリと、データ記憶媒体とを少なくとも含むコンピュータシステムによって実行される、アクティビティのインスタンスについて分析データを増分的に生成する方法であって、各インスタンスは、前記インスタンスについての情報が変更されるアクティブ状態か、または前記インスタンスについての情報が変更されない非アクティブ状態を有し、前記方法は、
前記ＣＰＵが、
前記データ記憶媒体にストアされ、前記アクティブ状態にあるインスタンスに関連付けられたデータベースレコードの最初の集合を処理することにより、第１のオンライン分析処理（ＯＬＡＰ）キューブを生成するステップと、
前記データ記憶媒体にストアされ、前記非アクティブ状態にあるインスタンスに関連付けられたデータベースレコードの最初の集合を処理することにより、第２のＯＬＡＰキューブを生成するステップと、
前記第１のＯＬＡＰキューブと前記第２のＯＬＡＰキューブを組み合わせて仮想ＯＬＡＰキューブとするステップと、
前記処理がされた前記非アクティブなインスタンスに関連付けられたデータベースレコードの前記最初の集合に最後に割り当てられたレコードＩＤに基づいて、前記第２のＯＬＡＰキューブを形成するのに処理されていない非アクティブなインスタンスレコードの後の集合を識別するステップと、
前記最後に割り当てられたレコードＩＤを参照することによって、前記後の集合の増分データに基づいて、前記第２のＯＬＡＰキューブを更新するステップと、
アクティブインスタンスのデータベースレコードの後の集合について次の第１のＯＬＡＰキューブを生成するステップと、
前記次の第１のＯＬＡＰキューブと、前記更新された第２のＯＬＡＰキューブとを組み合わせて、引き続く仮想ＯＬＡＰキューブとするステップと
をさらに備え、
前記アクティブインスタンスのデータベースレコードの後の集合は、前記第１のＯＬＡＰキューブを生成するのに処理されていないアクティブインスタンスレコードを含み、
前記非アクティブインスタンスのデータベースレコードの後の集合は、前記第１のＯＬＡＰキューブが生成された時にアクティブであったインスタンスに関連付けられ、かつ、関連付けられたアクティブなインスタンスが処理されて前記第１のＯＬＡＰキューブを生成していたレコードを含むことを特徴とする方法。
前記非アクティブ状態にあるインスタンスに関連付けられたデータベースレコードの前記集合の少なくとも一部は、周期的な間隔で、または、前記データ記憶媒体にストアされた前記データベースレコードが所定のサイズに達したときに、新たな名前を付けられたテーブルのパーティションに移動されることを特徴とする請求項１に記載の方法。