JP2005524909A - データベースシステムにおける変更データ収集のための方法および装置 - Google Patents

Abstract

変更データ収集の方法が開示されており、オンライントランザクション処理（ＯＬＴＰ）テーブルに対して行なわれた修正（たとえば挿入、更新、および削除）は、変更テーブルと呼ばれるデータベースオブジェクトに保持される。変更テーブルの変更データは次に、パブリケーション−サブスクリプションモデルに従ったような制御された態様で、分析アプリケーションに利用されるようになる。

Description

発明の分野
この発明はデータベースシステムに関し、より特定的には、データベースシステムにおける変更データ収集のための方法および装置に関する。

発明の背景
多くの企業および他の大きな組織は今日、リレーショナルデータベース管理システムを用いて商取引を実行し、追跡する。これらのシステムは、オンライントランザクション処理（ＯＬＴＰ）システムとして公知である。たとえば、インターネットを通して製品またはサービスを販売する会社が、ＯＬＴＰシステムを用いて、各商品についての価格情報、各購入者についての請求および出荷情報、ならびに購入者が行なった各発注についての販売情報を記録する場合がある。ＯＬＴＰシステムを用いる企業の他の例は、航空会社、銀行、通信販売会社、スーパーマーケット、および製造業者を含む。たとえば１秒あたりのトランザクション数といったＯＬＴＰシステムの性能は企業にとって非常に重要であり、したがって、絶対に必要でない限り、ＯＬＴＰシステムの性能を低下させないことが望ましい。

ＯＬＴＰシステムにおいて生成および記録されたデータは、大抵の企業にとって貴重である。なぜなら、企業はこのデータを集約および分析して、ある特定の月についての製品販売を把握し、製品の人気における変化する傾向を予測し、収益性の高い、または儲からない製品ラインを識別し、もしくは他のやり方で業務を評価することができるためである。しかしながら、このデータを集約および分析することはコンピュータ的に不経済であり、ＯＬＴＰシステム自体において実行されると、ＯＬＴＰシステムの性能を低下させる。したがって、ＯＬＴＰシステムを有する企業にとっては、ＯＬＴＰデータベースに含まれる情報を集め、集約し、分析するために、「データウェアハウス」として一般に公知である別個のコンピュータシステムを設立することが一般的になっている。データウェアハウスは、ギガバイト〜多テラバイト単位のデータ（何兆ものバイト）の範囲にわたって非常に大きく増大可能である。データをＯＬＴＰシステムにおけるその元のソースからデータウェアハウスに動かすタスクは一般に、データ抽出、伝送およびロード（ＥＴＬ）と呼ばれている。

従来のデータ抽出、伝送およびロードメカニズムは煩わしい。典型的なアプローチでは、データベースアドミニストレータは一般に、ＯＬＴＰシステムのテーブルの内容全体をフラットファイルにダンプし、そのフラットファイルをステージングシステムに伝送し、次に、フラットファイル内のデータをデータウェアハウスにロードする。このアプローチでは、抽出、伝送およびロードされたデータの量は、ＯＬＴＰシステム上のデータが実際にはほんの少しの割合しか新しくなっていない場合でさえ、ＯＬＴＰシステム内のデータの量と同様に莫大である。したがって、ＯＬＴＰシステムのデータベーステーブルに対して変更されたデータのみを収集することによって抽出、伝送およびロードされたデータの量を削減する方法を考案することに、多大な関心が寄せられてきた。

ＯＬＴＰシステムデータベーステーブルに対して変更されたデータを収集するための典型的な一アプローチは、ＯＬＴＰシステムデータベーステーブルに列を追加して、タイムスタンプまたは連続番号を記憶させ、最新のタイムスタンプまたは連続番号を有するデータを条件付きで抽出することである。このアプローチはいくつかの欠点を有する。第１に、このアプローチは、変更を追跡するためにタイムスタンプを保有する追加の列を加える
といった、スキーマへの変更を必要とする。管理上の悪夢はこのスキーマ変更だけではなく、ＯＬＴＰシステムの多くのベンダーは、機密保護、保守、および責任という理由で、顧客がスキーマに変更を加えることを一切禁止している。

第２に、新しい、または変更されたデータのすべての行についてタイムスタンプを記憶させる際に性能瞬断が起こるが、性能はＯＬＴＰシステムにとって重大である。第３に、タイムスタンプは、挿入または更新によってどの行が変更したかを容易に識別できるが、新しく挿入された行と更新された古い行とを区別できない。さらに、タイムスタンプは削除された行を識別できない。なぜなら、削除された行はもはやデータベースに存在しないためである。この種の変更情報の欠如により、ＯＬＴＰデータのサマリーを適正に更新することは困難になっており、サマリーデータの不経済な再計算を結果としてもたらす。

従来のフラットファイルアプローチは、データ伝送にとっても不利である。フラットファイルはデータベース管理システムの管理外にある。このため、フラットファイルは、頑強なデータ保護のためのクラッシュ回復、および、効率よいデータ処理のためのデータ区分化ならびに索引付けといった、最新のデータベース管理システムによって提供されるコード化したファイル管理機能を利用できない。したがって、変更されたデータをフラットファイルに記憶させることは、そのデータが失われる、または壊されるリスクを高め、データ分析アプリケーションによる使用のために変更データをデータウェアハウスに記憶されたデータと結合させる、または組合せるタスクを非常に複雑にする。

データロードに関しては、従来のフラットファイルアプローチはまた、データ損失および二重カウントを被っている。フラットファイルアプローチでは、追加的な変更データを有するフラットファイルを更新するプロセスと、変更データを消費および分析するアプリケーションとの間に連係がない。フラットファイルがデータウェアハウスシステムにとって大きくなりすぎると、システムアドミニストレータは自由裁量によってフラットファイル内の最も古いデータを削除しがちである。データ分析アプリケーションが削除されたデータをまだ処理していなかった場合、そのデータはアプリケーションに対して永久に失われ、結果としてＯＬＴＰデータの不正確なサマリーをもたらす。他方、データ分析アプリケーションがデータを処理するためにフラットファイル上で多数のパスを行なう必要がある場合、データ分析アプリケーションは、フラットファイルに新しく追加されたデータを識別できない。通常、データ分析アプリケーションは、フラットファイル内の全データを再処理するようにされ、結果として古いデータの二重カウントをもたらす。

したがって、効率よく、スキーマ変更を必要とせず、頑強で、データ損失または二重カウント問題を被っていないデータ抽出、伝送およびロード手法に対する要望がある。

発明の概要
この発明は、変更テーブルと呼ばれるデータベースオブジェクト内のＯＬＴＰテーブルになされた修正（たとえば挿入、更新、および削除）を収集することによって、これらのおよび他の要望に対処する。変更テーブル内の変更データは次に、変更データの損失または二重カウントを防止するために、たとえばパブリケーション−サブスクリプションモデルに従った制御された方法で分析アプリケーションに利用されるようになる。

あるパブリケーション−サブスクリプションモデルでは、パブリケーションは、変更テーブルの作成および保持を含む。好ましい一実施例では、変更テーブルは、ＯＬＴＰシステム上の対応する「ソーステーブル」に対する変更データを含むデータウェアハウス上の
データベースオブジェクトである。変更テーブルはトランザクションの一貫性のために「変更セット」に論理的にグループ化されてもよく、変更テーブルには時折、ＯＬＴＰシステム上の対応するソーステーブルから抽出された新しい変更データがロードされる。変更テーブルが無制限に大きくなるのを防止するため、および、データ損失問題に対処するために、変更テーブルの内容は、その内容がもはやどのサブスクライバからも必要とされなくなった場合にのみ削除される。

サブスクリプションは、変更データがデータ損失または二重カウントなく検索されるように分析アプリケーションが変更テーブル内の変更データへのアクセスを要求するためのメカニズムを含む。具体的には、（たとえば変更データが処理済であるために）変更データはもはや必要ではないとサブスクライバアプリケーションのすべてが示した場合にのみ、変更データは変更テーブルから削除される。さらに、新しい変更データに対する要求に応答して変更データをサブスクライバに提供するだけで、二重カウントは回避される。このため、サブスクライバは、変更テーブルに収集中およびロード中の新しい変更に関係なく、変更テーブルの同じ行を必要に応じて何度でも再読出できる。

したがって、この発明の一局面は、データベースシステムのソースオブジェクトに対応するデータベースオブジェクトを保持することによって、データベースシステムから収集された変更データを管理するための方法およびソフトウェアに関する。このデータベースオブジェクトは、ソースオブジェクトに対して実行された（たとえば挿入、削除、または更新といった）少なくとも１つの修正を示す変更データを含む。あるアプリケーションに関して、変更データのウィンドウが、第１の時点と第２の時点との間でコミットされたデータベースオブジェクト内のすべての変更データを含むように規定される。第１および第２の時点は、日付の物理的時間（たとえば２０００年７月１４日の正午１２時）、または論理的時間（たとえばシステム変更番号１２３４２３、この場合、データベースシステム上の各動作は単調に増加するシステム変更番号で印される）に関して規定されてもよい。ウィンドウは、第２の時点を前に動かすことによって拡張可能であり、または、第１の時点を第２の時点と一致させることによってパージ可能である。アプリケーションからの問合せに応答して、ウィンドウに含まれるデータベースオブジェクトからの変更データのみがアプリケーションに提示される。ソースオブジェクトからの新しい変更データはデータオブジェクトに追加されてもよい。しかしながら、その新しい変更データのみが、ウィンドウの拡張後、アプリケーションに提示される。

さまざまな実施例において、データベースオブジェクトは変更テーブルとして実現可能であり、変更テーブルは、ここで「変更セット」と呼ばれる変更テーブルのグループに関連付けられ得る。変更セットは、トランザクションの一貫性のために、および、変更セットにおける変更テーブルの各々がたとえば２００１年６月といったある規定された期間内の変更データのみを含むように保持され得る。データベースシステム上の同じソースオブジェクトを、異なる変更セットにおける多数の変更テーブルと関連付けることができる。さらに、多数のアプリケーションがそれらのそれぞれのウィンドウを同じデータベースオブジェクト上に規定することが可能であり、それらの各ウィンドウは異なる範囲の変更データに対するものであり得る。

この発明のさらに別の局面、特徴、および利点は、この発明を実行するために考えられる最良の態様を含む多数の特定の実施例および実現化例を単に例示することにより、以下の詳細な説明から容易に明らかとなる。この発明は他のおよび異なる実施例でも可能であり、そのいくつかの詳細は、この発明の精神および範囲から全く逸脱することなく、さまざまな明らかな点において修正可能である。したがって、図面および説明は本質的に例示的なものであって、限定的なものではないと考えられるべきである。

この発明を、限定のためではなく例示のために、添付図面の図に示す。図中、同様の参照番号は同様の要素を示す。

好ましい実施例の説明
変更データ収集のためのシステム、方法、およびソフトウェアを説明する。以下の記載では、説明のため、この発明の完全な理解を提供するために多数の特定の詳細について述べる。しかしながら、当業者には、この発明がこれらの特定の詳細なしで、または同等の構成で実践され得ることは明らかである。他の点では、この発明を不必要に不明瞭にしないよう、周知の構造および装置をブロック図の形で示す。

データベース管理システムでは、データは１つ以上のデータコンテナに記憶され、各コンテナはレコードを含み、各レコード内のデータは１つ以上のフィールドに編成される。リレーショナルデータベースシステムでは、データコンテナはテーブルと呼ばれ、レコードは行と呼ばれ、フィールドは列と呼ばれる。オブジェクト指向データベースでは、データコンテナはオブジェクトクラスと呼ばれ、レコードはオブジェクトと呼ばれ、フィールドは属性と呼ばれる。他のデータベースアーキテクチャは他の用語を使う場合がある。

この発明を実現するシステムは、どの特定の種類のデータコンテナまたはデータベースアーキテクチャにも限定されない。しかしながら、説明のため、ここで用いられる用語および例はリレーショナルデータベースに典型的に関連するものとする。このため、「テーブル」、「行」、および「列」という用語は、ここではそれぞれ、データコンテナ、レコード、およびフィールドを指すために使用されるものとする。

アーキテクチャ概要
図１は、ソースシステム１１０とステージングシステム１２０とを含むこの発明の一実施例のアーキテクチャを示す。ソースシステム１１０は、典型的には、ある企業についてのトランザクションを実行し追跡するためのオンライントランザクション処理（ＯＬＴＰ）である。たとえば、ソースシステム１１０は、企業の従業員または顧客と対話する責任のある業務アプリケーション１１１のホストとして働く。業務アプリケーション１１１のユーザからのコマンドおよび問合せに応答して、業務アプリケーション１１１は、データを記憶および検索するためにＯＬＴＰデータベース１１３と相互作用する。

ステージングシステム１２０は、この例ではデータウェアハウスとして機能しながら、１つ以上のサブスクライバアプリケーション１２１、１２３のホストとして働く。一般性を失うことなく、２つのサブスクライバアプリケーション１２１、１２３が図示されているが、この発明の一実施例の動作の過程において任意の数が作り出されてもよい。サブスクライバアプリケーション１２１、１２３は、ＯＬＴＰデータベース１１３から抽出され、ステージングシステム１２０に伝送され、分析データベース１２５にロードされた変更データを集約および分析する責任を有する。好ましくは、ＯＬＴＰデータベース１１３からフラットファイルを用いずにデータを抽出するために、２つのメカニズムのうちの一方が採用される。これらのメカニズムはそれぞれ、「同期抽出」および「非同期抽出」と呼ばれる。

同期抽出メカニズムでは、ＯＬＴＰデータベース１１３に各変更が行なわれてステージングシステム１２０に伝送される際にその変更を収集するために、トリガ１１５が採用される。ステージングシステム１２０において、これらの変更は次に、パブリッシャプロセス１２７によって統合され、分析データベース１２５の変更テーブル（図示せず）にロードされる。

非同期抽出メカニズムについては、動作の通常過程においてＯＬＴＰデータベース１１３により生成される回復ログ１１７を、ログシッパー１１９が定期的に複製する。回復ログ１１７は、ＯＬＴＰデータベース１１３に適用されたすべての変更を含んでおり、ＯＬＴＰデータベース１１３内のデータをバックアップし、システムクラッシュの場合にデータを復元するために用いられる。ログシッパー１１９は、オペレーティングシステムディレクトリとして実現可能な、変更ソース１３１と呼ばれるステージングシステム１２０の領域に、回復ログ１１７を複製する。パブリッシャ１２７はログビューワプロセス１２９と相互作用して、回復ログの内部実現詳細を認識する必要なく、変更ソース１２９内の運ばれた回復ログから変更データを得る。パブリッシャ１２７は次に、ログビューワプロセス１２９を介して得た変更データを、分析データベース１２５内の変更テーブルにロードする。

変更データを管理するためのオブジェクト
この発明の一局面によれば、ＯＬＴＰデータベース１１３から抽出された変更データは、フラットファイル内にではなく、たとえば分析データベース１２５などのデータベース管理システムの管理下にある「変更テーブル」としてここに言及される１つ以上のデータベースオブジェクト内に保持される。データベース管理システムは機密保護のためのクラッシュ回復、性能のための索引付けなどの特徴を提供するため、変更データを有利に保有するためにデータベースオブジェクトを使用することは、フラットファイルを使用する場合と比較して、これらの有益な特徴を追加的なプログラミングなしで達成する。

例として図２を参照すると、変更データ収集の対象であるＯＬＴＰデータベース１１３上の各ソーステーブルまたはデータベースオブジェクトは、分析データベース１２５内の対応する変更テーブル２１１、２１３、２２１、２２３、２２５と関連付けられている。トランザクションの一貫性のため、変更テーブル２１１、２１３、２２１、２２３、２２５は１つ以上の「変更セット」２１０、２２０の組にグループ化され、同じ変更セット内の変更テーブル（たとえば変更セット２１０の変更テーブル２１１、２１３）に追加される新しい変更データがすべて同時に追加されること、たとえばこれらの変更テーブルへの修正が同じトランザクションにおいて行なわれコミットされることを、パブリッシャ１２５が保証するようになっている。図２に示す例では、２つの変更セット、つまり変更セット２１０と変更セット２２０とがある。変更セット２１０は変更テーブル２１１と変更テーブル２１３とを含み、それらはＯＬＴＰデータベース１１３上のそれぞれのテーブル（図示せず）に対応している。同様に、変更セット２２０は変更テーブル２２１、変更テーブル２２３、および変更テーブル２２５を含んでおり、それらもＯＬＴＰデータベース１１３上のそれぞれのテーブル（図示せず）に対応している。変更セット２１０、２２０、および変更テーブル２１１、２１３、２２１、２２３、２２５の構造を規定する情報は、システムメタデータ２３０内に保持される。

各変更テーブルは、ＯＬＴＰデータベース１１３内の対応するソーステーブルの列から値が抽出、伝送およびロードされたソーステーブル列に加えて、多数の制御列を採用している。図２の例では、変更テーブル２２５は、１組のソーステーブル列２３１と、制御列ＳＣＮ２３３、ＴＩＭＥ２３５、ＯＰ２３７、およびＲＯＷ２３９とを有するとして図示されている。ソーステーブル列２３１は、対応するソーステーブルの列のすべてまたは一部を含んでいてもよい。さまざまな実現化例において、制御列は、ソーステーブル列を含んでいるのと同じデータベースオブジェクトの一部であってもよく、または、（たとえば行識別子または一次キーによって）ソーステーブル列と結合され得る平行な関連データベースオブジェクトの一部であってもよい。

制御列ＳＣＮ２３３、ＴＩＭＥ２３５、ＯＰ２３７、およびＲＯＷ２３９は、好ましくは、たとえばドル符号（＄）などの予約文字を有する名前といった、顧客が自分の列に使
用できない予約名を有する。この予約名はもちろん、任意の有効な文字列であってもよく、この例では、覚えるのに便利なように、ＳＣＮ２３３、ＴＩＭＥ２３５、ＯＰ２３７、およびＲＯＷ２３９と名付けられている。

ＳＣＮ２３３列は、変更データを引起こしたＯＬＴＰデータベース１１３上のトランザクションについてのコミットのシステム変更数を保有する。システム変更数は、データベースシステムにおいて実行される動作を指示するために使用可能な、たとえば更新、挿入、削除およびコミットといった、データベースシステム上で実行されるあらゆる動作を識別する、単調に増加する数である。この発明はシステム変更数のどの特定の実現化例にも限定されておらず、ここに開示された概念は、タイムスタンプ、インクリメントする連続番号などに有益に採用可能である。

ＴＩＭＥ２３５列は、変更データを引起こしたトランザクションのコミット時間を含む。この列は、サブスクライバアプリケーション１２１が特定の期間に起こる変更データを選択または閲覧するのを助ける。

ＯＰ２３７列は、変更データをもたらした動作の種類を示す符号を含む。たとえば、ＯＰ２３７列が記号「Ｉ」を含む場合、動作は挿入動作で、ソーステーブル列２３１内の変更データは挿入されたデータを含んでいる。ＯＰ２３７列が記号「Ｄ」を含む場合、動作は削除動作で、ソーステーブル列２３１内の変更データは削除されたデータを含んでいる（これによりサマリーはサブスクライバアプリケーション１２１によって適正に再調節される）。ＯＰ２３７列が記号「ＵＯ」を含む場合、動作は更新動作で、ソーステーブル列２３１内の変更データは修正された古いデータを含んでいる。同様に、ＯＰ２３７列が記号「ＵＮ」を含む場合、動作は更新動作で、ソーステーブル列２３１内の変更データは修正された新しいデータを含んでいる。このため、ソーステーブル上の更新動作は、変更テーブルにおける２つの入力、つまり、一方は古いデータ用、もう一方は新しいデータ用の入力をもたらし、そのため、サブスクライバアプリケーション１２１は、ＯＬＴＰデータのそのサマリーを再調整するのに十分な情報を有している。状況次第では、ソーステーブルが図形および画像などの「ラージオブジェクト」（ＬＯＢ）を含む場合がある。このＬＯＢは通常サマライズされておらず、そのため、メモリを節約するには、新しいＬＯＢのみが（ＯＰ２３７列に記号「ＵＬ」を有して）変更テーブルに記録される。ＯＰ２３７列のこれらの記号（「Ｉ」、「Ｄ」、「ＵＯ」、「ＵＮ」、「ＵＬ」）は、覚えるのに便利なように選択され、この発明の範囲から逸脱することなく、他の記号に任意の一意的な値（たとえば数）を自由裁量で割当てることが可能である。

ＲＯＷ２３９列は、変更テーブルにおける変更についての一意的な行シーケンス番号を含む。この列は、サブスクライバアプリケーション１２１が同じトランザクションにおいてコミットされた動作を指示するのを助ける。また、同じ動作の古い更新値についてのレコード（「ＵＯ」を有するＯＰ２３７列）と、新しい更新値についてのレコード（「ＵＮ」を有するＯＰ２３７列）とは双方とも、同じ行シーケンス番号を有する。なぜなら、これら２つのレコードは、ＯＬＴＰデータベース１１３上での同じ変更動作（更新動作）に関するためである。

図２には示されていないが、この発明の実施例の実現を容易にするために、追加の制御列が設けられてもよい。たとえば、どのコラムが変更したかを迅速に識別するために、更新された列のビットマスクが使用可能である。別の例として、動作を引起こしたユーザの名前を制御列に記録してもよい。ソーステーブル内の影響された行の行識別子も、制御列に含まれ得る。

しかしながら、図１のサブスクライバアプリケーション１２１、１２３は、変更テーブ
ルの内容すべてを見る必要はない。特に、サブスクライバアプリケーション１２１、１２３がそれぞれのサブスクライバビューにおいて見る行の範囲は、変更データが失われないよう、かつ、サブスクライバアプリケーション１２１、１２３に対して二重カウントされないよう、以下に詳細に説明するように制限され、慎重に制御されている。図２の例では、２つのサブスクライバビュー２４１、２４３が示されているが、この発明の一実施例の動作中、任意の数のサブスクライバビューが作成されてもよい。サブスクライバビュー２４１、２４３を使用することは、それぞれのサブスクライバアプリケーション１２１、１２３を、変更テーブル２２５の実現詳細から有益に遮断する。いくつかの先行技術のアプローチとは異なり、ＯＬＴＰデータベース１１３上のソーステーブル自体に制御列または情報を追加する必要は一切なく、分析データベース１２０上の変更テーブルへ制御列を提供するだけで十分である。したがって、この特徴により、変更データ収集はＯＬＴＰデータベース１１３のスキーマを変更せずに実行可能であり、それは多くのターンキーＯＬＴＰデータベースにとって望ましいことである。

パブリケーション
この発明の一実施例では、収集された変更データを管理するためにパブリケーション−サブスクリプションモデルが採用されている。図１のパブリッシャ１２７は、関連するプログラムの組として、および、データベースアドミニストレータまたはデータベースを管理する同様の特権を有する者による使用が意図されたユーザインターフェイスとして実現されてもよい。図３は、パブリッシャ１２７によって実行され得るさまざまなパブリケーション動作を示す。パブリケーションは、変更テーブル（図２の要素２１１、２１３、２２１、２２３、２２５）の作成および保持、変更テーブルの変更セット（図２の要素２１０、２２０）への論理的グループ化、変更データのソースである、データベースシステムを表わすデータベースオブジェクトとして実現可能な変更ソース１３１の作成および保持、ならびに、同期および非同期データ収集のためのメカニズムを伴う。さらに、パブリケーションはまた、変更テーブルが無制限に大きくはならず、変更テーブルの内容がサブスクライバアプリケーション１２１、１２３からもはや必要とされなくなった場合に削除されるように、変更テーブルが使用するディスクストレージを制限するためのメカニズムも伴う。

ステップ３０１で、パブリッシャは１つ以上の変更ソース１３１を作成し、その情報をシステムメタデータ２３０に記録する。各変更ソースは、変更データのソースを一意的に識別する。たとえば、ボストン市から生じる変更データは、ＢＯＳＴＯＮという名前で変更ソースを作成することによって表すことができ、一方、シカゴから生じる変更データは、ＣＨＩＣＡＧＯと名付けられた変更ソースによって表すことができる。ステージングシステム１２０は複数の変更ソースを含んでいてもよい。この発明の好ましい一実施例では、変更ソースは同期的または非同期的のいずれかである。非同期変更ソースの値は、その変更ソース用の運ばれた回復ログの場所（たとえばオペレーティングシステムディレクトリへのパスネーム）を識別する。変更テーブルは回復ログを使用せずに同期変更データ収集の下でトリガ事象に応答して更新されるため、同期変更データ収集のための変更ソースは通常、回復ログについて任意の場所を特定する必要がないことを示す、ＳＹＮＣ＿ＳＯＵＲＣＥといった任意の名前である。

ステップ３０３で、各変更ソース１３１に対して１つ以上の変更セット２１０、２２０が作成され、その情報をシステムメタデータ２３０に記録する。変更セット２１０、２２０は、少なくとも２つの独立した目的、つまり、トランザクションの一貫性を維持するため、および、個々のトランザクションのコミット時間に応じて変更データを隔離するために使用可能である。変更テーブルの関連するグループへの更新がすべて、同じトランザクションにおいてコミットされた場合に、トランザクションの一貫性は達成される。このため、変更セット２１０、２２０により、パブリッシャはそのような論理的に関連する変更
テーブルを識別できるようになる。変更セット２１０、２２０はまた、開始日および終了日を有していてもよく、変更セット２１０、２２０の変更テーブルがすべて、開始日と終了日との間に該当するトランザクションからのみ変更データを記憶するようになっていてもよい。たとえば、変更セットＣＨＩＣＡＧＯ＿ＪＵＮＥは、開始日が２０００年６月１日、終了日が２０００年６月３０日で作成され得る。このため、２０００年６月に該当するＣＨＩＣＡＧＯ変更ソースからの変更データはすべて、ＣＨＩＣＡＧＯ＿ＪＵＮＥに属する変更テーブルに記憶される。開始日および終了日はシステムメタデータテーブルに記憶されてもよく、部分的にまたは完全に無限の期間を可能とするよう、いずれの日も終りが設定されていなくてもよい。変更セット同士が同じ変更ソースの同じソーステーブルを参照する場合でも、変更セットの各々は、別の変更セットに対して異なる開始日または終了日を有する期間について変更を収集してもよい。したがって、この特徴は、独立し、かつ他の変更セットの期間に影響されない、期間の多大なる柔軟性を提供する。

ステップ３０５で、パブリッシャは次に、変更テーブル２１１、２１３、２２１、２２３、２２５を作成し、変更テーブル２１１、２１３、２２１、２２３、２２５の各々に変更セット２１０、２２０のうちの１つを割当て、その情報をシステムメタデータ２３０に記録する。変更テーブル２１１、２１３、２２１、２２３、２２５の各々は、変更テーブルが属する対応する変更セット２１０、２２０の同じ開始日および終了日を共有している。さらに、同じ変更セット内の変更テーブル同士は、トランザクション的に一貫した態様で保持される。たとえば、ある変更ソース（たとえば１組の運ばれた回復ログ）が６月１５日に起こった変更についての変更データを含むと仮定する。その場合、変更セットのデータが収集されると、変更セット内の変更テーブルの各々は、対応するソーステーブルに６月１５日になされた変更を反映するよう更新される。具体的には、ある変更セットの１つの変更テーブルが６月１１日中の変更のみを含み、同じ変更セットの別の変更テーブルが６月１４日までの変更を含む、などといったような状況はあり得ない。

変更オブジェクトの作成後、変更データは定期的に変更テーブルに追加され（ステップ３０７）、変更テーブルから削除される（ステップ３０９）。より具体的には、非同期変更データがステージングシステム１２０上の変更ソース１３１に伝送されるにつれ、パブリッシャ１２７は定期的に変更セットを「進める」。変更セットを進めることは、変更ソース１３１において運ばれた回復ログを処理することを伴う。ある非同期的実現化例では、ＳＱＬ ＳＥＬＥＣＴステートメントがログビューワ１２９プロセスに発行され、それはある特定の範囲の時間についての変更データを、変更セットの適切な変更テーブルに挿入するために戻す。サブスクライバアプリケーション１２１、１２３からのパージコマンドに応答して、変更データは変更テーブルから削除される。具体的には、サブスクライバアプリケーション１２１、１２３によってまだパージされていない変更データの最も古い行を追跡するために、各変更テーブルに対して低いウォーターマークが維持されている。進める、および削除する動作の作用（ステップ３０７、３０９）を、機能例に関して以下により詳細に説明する。

サブスクリプション
パブリケーション−サブスクリプションモデルによれば、サブスクリプションは、サブスクライバアプリケーション１２１、１２３が、たとえばコミット順などの制御された態様で、データ損失または二重カウントなく、変更データへのアクセスを要求するメカニズムと、多数のサブスクライバアプリケーション１２１、１２３が所与の変更テーブルを共有できるようにサブスクライバアプリケーション１２１、１２３間で調整するメカニズムと、変更テーブルに収集中の新しいデータの突然の出現に関係なく、多数のサブスクライバアプリケーション１２１、１２３が、変更テーブル内の変更データの同じ行を必要に応じて読出または再読出できるようにするメカニズムと、パブリッシャが変更データの行を効率よくかつ正しく除去できるよう、サブスクライバアプリケーション１２１、１２３が
変更データの行で終わった場合にパブリッシャに通知するメカニズムとを含む。

ここで、一実現化例の動作を示す図４を参照すると、サブスクライバアプリケーション１２１、１２３は、たとえば制御された態様で変更データにアクセスするという、変更データのサブスクライバになるという要求を、パブリッシャ１２７に登録する（ステップ４０１）。サブスクライバアプリケーション１２１、１２３は、同じ変更セットに属する複数の変更テーブルをサブスクライブしてもよい。加えて、サブスクライバアプリケーション１２１、１２３は、関与するソーステーブル列の１つ以上を特定できる。たとえば、変更テーブルがソーステーブル列Ａ、Ｂ、Ｃ、Ｄを含む場合、サブスクライバは、列Ａ、Ｄを省略して列Ｂ、Ｃのみをサブスクライブするよう選択してもよい。

サブスクリプション要求をパブリッシャ１２７に登録することに応答して、サブスクライバアプリケーション１２１、１２３は、変更データの行にアクセスできる態勢となる。サブスクライバアプリケーション１２１、１２３による変更データへの要求はすべて、それぞれの「サブスクリプションウィンドウ」を介して仲介される。サブスクリプションウィンドウは、最も古いまたは最も初期の変更行と最新のまたは最近の変更行との間の変更データのすべての行を例外なく含む、変更データの１つ以上の行を提示する。サブスクリプションウィンドウに属する変更データの範囲は、サブスクライバアプリケーション１２１、１２３が行なうサブスクリプションウィンドウ拡張コールによって管理される（ステップ４０３）。

サブスクリプションウィンドウ拡張コールに応答して、パブリッシャ１２７は、（サブスクライバアプリケーションに関して）これまで見たことがない変更データの１つ以上の行をサブスクライバが利用可能となるよう、サブスクリプションウィンドウを未来の方向にさらに動かす。変更行を閲覧するために、サブスクライバアプリケーション１２１、１２３はサブスクライバビュー用意コールを行ない（ステップ４０５）、それはサブスクリプションウィンドウに含まれるすべての変更行を含むリレーショナルビュー２４１、２４３をインスタンス生成する。サブスクライバビュー２４１、２４３内の変更データを使用するために、サブスクライバアプリケーション１２１、１２３は、“ＳＥＬＥＣＴ^*ＦＲＯＭ ＳＵＢＳＣＲＩＢＥＲ＿ＶＩＥＷ ＯＲＤＥＲ ＢＹ ＳＣＮ＄”などのＳＱＬ ＳＥＬＥＣＴステートメントを発行でき、ここで、ＳＵＢＳＣＲＩＢＥＲ＿ＶＩＥＷは、サブスクライバビュー２４１、２４３の名前またはエイリアスである。これに応答して変更データが戻され、サブスクライバアプリケーション１２１、１２３はそれに応じてデータを処理する（ステップ４０７）。

サブスクライバアプリケーション１２１、１２３がサブスクライバウィンドウ内のデータで終わったことを示すために、サブスクライバアプリケーション１２１、１２３はウィンドウドロップコールを行ない（ステップ４０９）、続いてウィンドウパージコールを行なう（ステップ４１１）。ステップ４１１のウィンドウパージコールは、変更行がサブスクライバアプリケーション１２１、１２３からもはや必要とされていないことをパブリッシャ１２７に知らせ、そのため、サブスクライバアプリケーション１２１、１２３のすべてがそう合図すると、パブリッシャ１２７は、どのサブスクライバアプリケーション１２１、１２３ももはや使用していない変更行を削除でき、それにより、変更テーブルが無制限に増大することを防止する。サブスクライバアプリケーション１２１、１２３がウィンドウ拡張コールを行なう（ステップ４０３）かまたはウィンドウパージコールを行なう（ステップ４１１）前に問合せが再発行されると、変更行の同じ組がサブスクライバアプリケーション１２１、１２３に戻される。したがって、たとえばウィンドウ拡張コール（ステップ４０３）またはウィンドウパージコール（ステップ４１１）などのサブスクライバアプリケーション１２１、１２３側での確認行為の後で、異なる変更行のみがサブスクライバアプリケーション１２１、１２３に戻されるため、サブスクライバアプリケーション
１２１、１２３は、変更データの二重カウントおよび変更データの紛失をそれぞれ回避できる。

機能例
図５Ａ、５Ｂ、５Ｃ、５Ｄ、５Ｅおよび５Ｆは、パブリケーション−サブスクリプションモデルの一実施例がいかに動作するかを示す機能例の一連の段階を示している。図５Ａでは、変更テーブル５００は、変更データの４つの行５０１、５０２、５０３、５０４を含んでいる。第１のサブスクライバアプリケーション１２１は、変更テーブル５００のサブスクリプションを起動し（ステップ４０１）、サブスクリプションウィンドウを現在に至るまで拡張し（ステップ４０３）、サブスクライバビュー５１０を得る（ステップ４０５）。したがって、第１のサブスクライバアプリケーション１２１は、４つの行５０１、５０２、５０３、５０４を処理できる（ステップ４０７）。

次に、図５Ｂでは、行５０５、５０６を含む追加の変更データが届き、変更テーブル５００に追加される（ステップ３０７）。第１のサブスクライバアプリケーション１２１は現在、サブスクライバ５１１をそのサブスクリプションウィンドウに基づいて扱っているため、第１のサブスクライバアプリケーション１２１には変更テーブル５００内の追加の変更データ５０５、５０６が見えない。このため、第１のサブスクライバアプリケーション１２１は、警告なしに出現する新しい変更データについて心配する必要なく、ＳＥＬＥＣＴコールを必要なだけたくさん自由に行なうことができ、それにより二重カウント問題を回避する。一方、第２のサブスクライバアプリケーション１２３は、変更テーブル５００のサブスクリプションを起動し（ステップ４０１）、サブスクリプションウィンドウを現在に至るまで拡張し（ステップ４０３）、サブスクライバビュー５２０を得る（ステップ４０５）。したがって、第２のサブスクライバアプリケーション１２３は、６つの行５０１、５０２、５０３、５０４、５０５、５０６を処理できる（ステップ４０７）。

図５Ｃでは、行５０７、５０８を含む追加の変更データが届き、変更テーブル５００に追加される（ステップ３０７）。第１のサブスクライバアプリケーション１２１にも第２のサブスクライバアプリケーション１２３にも、変更テーブル５００内のこの追加の変更データ５０７、５０８が見えない。なぜなら、この追加の変更データ５０７、５０８はそれぞれ、第１のサブスクライバビュー５１０、５２０の一部ではないためである。

図５Ｄでは、第１のサブスクライバアプリケーション１２１は変更データ５０１、５０２、５０３、５０４の処理を終了し、したがって、サブスクライバビュー５１０をドロップし（ステップ４０９）、変更行５０１、５０２、５０３、５０４を含むサブスクライバウィンドウをパージし（ステップ４１１）、サブスクリプションウィンドウを現在に至るまで拡張し（ステップ４０３）、新しいサブスクライバビュー５１０を得る（ステップ４０５）。このサブスクライバビュー５１０は、元のサブスクライバビュー５１０の一部ではなかった変更行５０５、５０６、５０７、５０８を含む。第１のサブスクライバアプリケーション１２１によってパージされた行５０１、５０２、５０３、５０４は依然として第２のサブスクライバアプリケーション１２３によって使用されているため、これらの行５０１、５０２、５０３、５０４は削除されない。

図５Ｅでは、第２のサブスクライバアプリケーション１２３は変更データ５０１、５０２、５０３、５０４、５０５、５０６の処理を終了し、したがって、サブスクライバビュー５２０をドロップし（ステップ４０９）、変更行５０１、５０２、５０３、５０４、５０５、５０６を含むサブスクライバウィンドウをパージし（ステップ４１１）、サブスクリプションウィンドウを現在に至るまで拡張し（ステップ４０３）、新しいサブスクライバビュー５２１を得る（ステップ４０５）。このサブスクライバビュー５２１は、元のサブスクライバビュー５２０の一部ではなかった変更行５０７、５０８を含む。

第２のサブスクライバアプリケーション１２３によってパージされた変更行５０１、５０２、５０３、５０４は、もはやどのサブスクライバアプリケーションにも使用されていない。したがって、これらの行５０１、５０２、５０３、５０４は削除され、図５Ｆに示す段階が結果としてもたらされる。これらの行５０１、５０２、５０３、５０４はサブスクライバアプリケーションによるウィンドウパージコールに応答してのみ削除されるため、サブスクライバアプリケーション１２１、１２３は、現在の変更データが警告なく消滅することを心配する必要なく、ＳＥＬＥＣＴコールを必要なだけたくさん自由に行なうことができ、それによりデータ損失問題を回避する。他方、行５０５、５０６は依然として第１のサブスクライバアプリケーション１２１によって使用されているため、これらの行５０５、５０６は削除されない。

ハードウェア概要
図６は、この発明に従った一実施例が実現され得るコンピュータシステム６００を示す。コンピュータシステム６００は、情報を通信するためのバス６０１または他の通信メカニズムと、情報を処理するためにバス３０２と結合されたプロセッサ６０３とを含む。コンピュータシステム６００はまた、プロセッサ６０３により実行されるべき命令および情報を記憶するためにバス６０１に結合された、ランダムアクセスメモリ（ＲＡＭ）または他のダイナミック記憶装置といったメインメモリ６０５も含む。メインメモリ６０５は、プロセッサ６０３により実行されるべき命令の実行中に一時的な変数または他の中間情報を記憶するためにも使用されてもよい。コンピュータシステム６００はさらに、プロセッサ６０３用の命令およびスタティック情報を記憶するためにバス６０１に結合された読出専用メモリ（ＲＯＭ）６０７または他のスタティック記憶装置を含む。磁気ディスクまたは光ディスクといった記憶装置６０９が、情報および命令を記憶するためにバス６０１に追加的に結合されている。

コンピュータシステム６００は、情報をコンピュータユーザに表示するための、ブラウン管（ＣＲＴ）、液晶ディスプレイ、アクティブマトリックスディスプレイ、またはプラズマディスプレイなどのディスプレイ６１１に、バス６０１を介して結合されていてもよい。英数字キーおよび他のキーを含むキーボードなどの入力装置６１３が、情報およびコマンド選択をプロセッサ６０３に通信するためにバス６０１に結合されている。ユーザ入力装置の別の種類は、方向情報およびコマンド選択をプロセッサ６０３に通信し、ディスプレイ６１１上のカーソルの動きを制御するための、マウス、トラックボール、またはカーソル方向キーといったカーソル制御６１５である。

この発明の一実施例によれば、変更データ収集は、プロセッサ６０３がメインメモリ６０５に含まれた命令の構成を実行するのに応答して、コンピュータシステム６００により提供される。そのような命令は、記憶装置６０９などの別のコンピュータ読取可能な媒体からメインメモリ６０５に読込可能である。メインメモリ６０５に含まれる命令の構成の実行により、プロセッサ６０３は、ここに説明された処理手順を行なうようになる。メインメモリ６０５に含まれる命令を実行するために、多重処理構成の１つ以上のプロセッサも採用されてもよい。代替的な実施例では、この発明の実施例を実現するために、ソフトウェア命令の代わりに、またはソフトウェア命令と組合わせて、配線接続回路が使用されてもよい。このため、この発明の実施例は、配線接続回路とソフトウェアとのどの特定の組合せにも限定されない。

コンピュータシステム６００はまた、バス６０１に結合された通信インターフェイス６１７も含む。通信インターフェイス６１７は、ローカルネットワーク６２１に接続されたネットワークリンク６１９に双方向データ通信結合を提供する。たとえば、通信インターフェイス６１７は、データ通信接続を対応する種類の電話回線に提供するデジタル加入者
線（ＤＳＬ）カードまたはモデム、デジタル相互サービス網（ＩＳＤＮ）カード、ケーブルモデム、または電話モデムであってもよい。別の例として、通信インターフェイス６１７は、互換性があるＬＡＭにデータ通信接続を提供するローカルエリアネットワーク（ＬＡＮ）カード（たとえばイーサネット（登録商標）または非同期転送モデル（ＡＴＭ）ネットワーク用）であってもよい。無線リンクも実現可能である。任意のそのような実現化例では、通信インターフェイス６１７は、さまざまな種類の情報を表わすデジタルデータストリームを搬送する電気信号、電磁信号、または光信号を送信および受信する。さらに、通信インターフェイス６１７は、ユニバーサルシリアルバス（ＵＳＢ）インターフェイス、ＰＣＭＣＩＡ（パーソナルコンピュータメモリカード国際協会）インターフェイスなどの周辺インターフェイス装置を含み得る。

ネットワークリンク６１９は通常、１つ以上のネットワークを介して、他のデータ装置にデータ通信を提供する。たとえば、ネットワークリンク６１９は、ネットワーク６２５（たとえば広域ネットワーク（ＷＡＮ）、または現在一般に「インターネット」と呼ばれている全世界的パケットデータ通信ネットワーク）への、もしくは、サービスプロバイダにより運営されるデータ装置への接続性を有するホストコンピュータ６２３に、ローカルネットワーク６２１を介して接続を提供してもよい。ローカルネットワーク６２１およびネットワーク６２５は双方とも、電気信号、電磁信号または光信号を使用して情報および命令を伝搬する。さまざまなネットワークを通る信号、ネットワークリンク６１９上の信号、およびコンピュータシステム６００とデジタルデータを通信する通信インターフェイス６１７を通る信号は、情報および命令を運ぶ搬送波の例示的な形態である。

コンピュータシステム６００は、ネットワーク、ネットワークリンク６１９および通信インターフェイス６１７を介して、メッセージを送信し、プログラムコードを含むデータを受信する。インターネットの例では、サーバ（図示せず）は、この発明の一実施例を実現するためのアプリケーションプログラムに属する要求されたコードを、ネットワーク６２５、ローカルネットワーク６２１、および通信インターフェイス６１７を介して送信してもよい。プロセッサ６０３は送信されたコードを受信中に実行してもよく、および／または、後の実行用に記憶装置６０９または他の不揮発性記憶装置にコードを記憶してもよい。このように、コンピュータシステム６００は、搬送波の形をしたアプリケーションコードを獲得し得る。

ここで用いられるような用語「コンピュータ読取可能な媒体」は、プロセッサ６０３に命令を実行用に提供することに関与するあらゆる媒体を指す。そのような媒体は、不揮発性媒体、揮発性媒体、および通信媒体を含むもののそれらに限定されない多くの形態をとり得る。不揮発性媒体はたとえば、記憶装置６０９などの光ディスクまたは磁気ディスクを含む。揮発性媒体は、メインメモリ６０５などのダイナミックメモリを含む。通信媒体は、バス６０１を構成する配線を含む、同軸ケーブル、銅線および光ファイバを含む。通信媒体は、無線周波数（ＲＦ）および赤外線（ＩＲ）データ通信中に発生するものなどの音波、光波、または電磁波の形も取り得る。コンピュータ読取可能な媒体の一般的な形態は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、任意の他の磁気媒体、ＣＤ−ＲＯＭ、ＣＤＲＷ、ＤＶＤ、任意の他の光媒体、パンチカード、紙テープ、光学マークシート、孔または他の光学的に認識可能な印のパターンを有する任意の他の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、任意の他のメモリチップまたはカートリッジ、搬送波、または、コンピュータが読取可能な任意の他の媒体を含む。

コンピュータ読取可能な媒体のさまざまな形態は、プロセッサに命令を実行用に提供することに関与していてもよい。たとえば、この発明の少なくとも一部を実行するための命令はまず、遠隔コンピュータの磁気ディスク上で運ばれてもよい。そのような筋書きでは
、遠隔コンピュータは命令をメインメモリにロードし、電話回線を通してモデムを用いて命令を送信する。ローカルコンピュータシステムのモデムが電話回線上のデータを受信して、赤外線送信機を用いてデータを赤外線信号に変換し、その赤外線信号を、携帯用情報端末（ＰＤＡ）およびラップトップなどの携帯用コンピュータ装置に送信する。携帯用コンピュータ装置上の赤外線検出器は、赤外線信号によって運ばれた情報および命令を受信し、データをバス上に配置する。バスはデータをメインメモリに搬送し、そこからプロセッサは命令を検索して実行する。メインメモリによって受信された命令は、プロセッサによる実行の前または後のいずれかで、記憶装置上に随意に記憶されてもよい。

多数の実施例および実現化例に関連してこの発明を説明してきたが、この発明はそのように限定されてはおらず、特許請求の範囲内に当てはまるさまざまな明らかな変更および同等の構成を網羅している。

この発明の一実施例の高レベルアーキテクチャ図である。 この発明の一実施例に従った変更オブジェクトを示す概略図である。 この発明の一実施例についてのさまざまなパブリケーション動作を示すフローチャートである。 この発明の一実施例についてのさまざまなサブスクリプション動作を示すフローチャートである。 この発明の一実施例の機能例に従った変更テーブルの状態を示す図である。 この発明の一実施例の機能例に従った変更テーブルの状態を示す図である。 この発明の一実施例の機能例に従った変更テーブルの状態を示す図である。 この発明の一実施例の機能例に従った変更テーブルの状態を示す図である。 この発明の一実施例の機能例に従った変更テーブルの状態を示す図である。 この発明の一実施例の機能例に従った変更テーブルの状態を示す図である。 この発明の一実施例を実現するために使用可能なコンピュータシステムの図である。

Claims (15)

1. データベースシステムから収集された変更データを管理するための方法であって、
   データベースシステムのソースオブジェクトに対応するデータベースオブジェクトを保持するステップを含み、前記データベースオブジェクトは、ソースオブジェクトに行なわれた少なくとも１つの修正を示す変更データを含んでおり、前記方法はさらに、
   あるアプリケーションに関して、第１の時点と第２の時点との間でコミットされたデータベースオブジェクト内の変更データをすべて含む変更データのウィンドウを規定するステップと、
   アプリケーションからの問合せに応答して、ウィンドウに含まれるデータベースオブジェクトから変更データのみを提示するステップとを含む、方法。
2. データベースオブジェクトは変更テーブルを含む、請求項１に記載の方法。
3. 変更テーブルを変更テーブルのグループに関連付けるステップをさらに含む、請求項１に記載の方法。
4. グループ内の変更テーブルの各々がある期間のみにおける変更データを含むように、変更テーブルのグループを保持するステップをさらに含む、請求項３に記載の方法。
5. グループ内の変更テーブルについてトランザクションの一貫性を維持するステップをさらに含む、請求項３に記載の方法。
6. 変更テーブルの別のグループを保持するステップをさらに含み、別のグループ内の変更テーブルのうちの１つはソーステーブルに対応している、請求項３に記載の方法。
7. ウィンドウを規定するステップは、第２の時点を前へ動かすことによってウィンドウを拡張するステップを含む、請求項１に記載の方法。
8. ウィンドウを規定するステップは、第１の時点が第２の時点と一致するように動かすことによってウィンドウをパージするステップを含む、請求項１に記載の方法。
9. 前記ウィンドウを規定するステップの後で、ソースオブジェクトからデータベースオブジェクトに新しい変更データを追加するステップと、
   新しい変更データを含むようにウィンドウを拡張するステップと、
   ウィンドウを拡張した後でのみ、データベースオブジェクトから新しい変更データを提示するステップとをさらに含む、請求項１に記載の方法。
10. 修正は、ソースオブジェクトのレコードの挿入、削除、および更新のうちの１つを含む、請求項１に記載の方法。
11. データベースシステムから収集された変更データを管理するための命令を運ぶコンピュータ読取可能な媒体であって、前記命令は、実行時、請求項１から１０のいずれかに従った方法のステップを１つ以上のプロセッサに実行させるよう構成されている、コンピュータ読取可能な媒体。
12. データベースシステムから収集された変更データを管理するための方法であって、
    データベースシステムのソースオブジェクトに対応するデータベースオブジェクトを保持するステップを含み、前記データベースオブジェクトは、ソースオブジェクトに行なわれた少なくとも１つの修正を示す変更データを含んでおり、前記方法はさらに、
    複数のアプリケーションに関して、それぞれの第１の時点とそれぞれの第２の時点との間でコミットされたデータベースオブジェクト内の変更データをすべて含む変更データのそれぞれのウィンドウを規定するステップと、
    アプリケーションからのそれぞれの問合せに応答して、それぞれのウィンドウに含まれるデータベースオブジェクトから変更データのみを提示するステップとを含む、方法。
13. 第１の時点または第２の時点の少なくとも一方は、それぞれ、別の第１の時点または他の第２の時点とは異なっている、請求項１２に記載の方法。
14. ウィンドウを規定するステップは、
    それぞれの第１の時点がそれぞれの第２の時点と一致するように動かすことによって、それぞれのアプリケーションからのそれぞれのパージ要求に応答して複数のウィンドウをパージするステップと、
    第１の時点のうち最も早いものの前に起こるデータベースオブジェクト内の変更データのレコードを削除するステップとを含む、請求項１２に記載の方法。
15. データベースシステムから収集された変更データを管理するための命令を運ぶコンピュータ読取可能な媒体であって、前記命令は、実行時、請求項１２から１４のいずれかに従った方法のステップを１つ以上のプロセッサに実行させるよう構成されている、コンピュータ読取可能な媒体。
    

Images