(57)【要約】  データベース内でいつ事象が発生したかを確定するための方法および装置が提供される。データベースの少なくとも一部が、事象より前の時点に復元される。回復ログが、回復ログ内に記述される変更をもたらすことが可能なデータベース操作（たとえばＳＱＬ）に翻訳される。命令文の実行に基づいて事象を検出するためのメカニズムが作成される。たとえば、事象を検出するためのデータベーストリガが作成される。復元されたデータベースに対してデータベース操作が実行されて、メカニズムに事象を検出させる。
2009529729.tif 000002
【特許請求の範囲】
【請求項１】
データベース内の事象の発生を検出するための、コンピュータによって実現される方法であって、
データベースの少なくとも一部のコピーを、事象の発生より前の点に復元するステップと、
前記データベースに対する変更を記述するやり直しログ記録を、前記データベースに対する前記変更をもたらすことが可能なデータベース操作を反映する命令文に翻訳するステップと、
前記命令文の実行に基づいて前記事象を検出するためのメカニズムを発生させるステップと、
前記メカニズムに、前記命令文を実行することによって前記事象を検出させるステップとを含む、方法。
【請求項２】
前記メカニズムはデータベーストリガを含む、請求項１に記載の方法。
【請求項３】
前記命令文はＳＱＬに準拠している、請求項１に記載の方法。
【請求項４】
時間クエリ内に指定される時間にわたってデータベースオブジェクトにどの変更が加えられたかを確定することによって、前記時間クエリに応答するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記事象は時間クエリの開始事象である、請求項１に記載の方法。
【請求項６】
前記命令文の実行に基づいて前記時間クエリの終了事象を検出するための第２のメカニズムを発生させるステップをさらに含む、請求項５に記載の方法。
【請求項７】
前記時間クエリに基づいたベースクエリにアクセスするステップと、
前記開始事象を検出した後に、
前記第２のメカニズムに、前記命令文を実行することによって前記終了事象を検出させ、
前記第２のメカニズムが前記終了事象を検出するのに応答して、前記時間クエリに対する応答を計算するために前記ベースクエリを発行するステップとをさらに含み、前記ベースクエリの結果は、前記時間クエリに対する前記応答を与える、請求項６に記載の方法。
【請求項８】
前記開始事象を検出した後に、
前記時間クエリに基づいてビューを活性化させ、
前記命令文のセットを実行し、前記命令文のセットは、前記開始事象の後に発生した前記データベースに対する前記変更をもたらすことが可能なデータベース操作を反映し、さらに、
前記命令文のセットが実行されると前記ビュー内のデータに対する変更を分析して、前記時間クエリに対する応答を確定し、
前記第２のメカニズムが前記終了事象を検出するのに応答して、前記時間クエリに対する前記応答を与えるステップをさらに含む、請求項６に記載の方法。
【請求項９】
データベース内の事象の発生を検出する、コンピュータによって実現される方法であって、
データベースの少なくとも一部のコピーを、時間クエリの開始事象の発生より前の点に復元するステップと、
前記データベースに対する変更を記述するやり直しログ記録を、前記データベースに対する前記変更をもたらすことが可能なデータベース操作を反映する命令文に翻訳するステップと、
前記命令文の実行に基づいて前記開始事象を検出するための第１のデータベーストリガを発生させるステップと、
前記第１のデータベーストリガに、前記命令文を実行することによって前記開始事象を検出させるステップとを含む、方法。
【請求項１０】
前記時間クエリに応答するためのメカニズムを発生させるステップをさらに含み、
前記メカニズムは、前記開始事象で始まる時間範囲にわたってデータベースオブジェクトに加えられた変更を確定する、請求項９に記載の方法。
【請求項１１】
前記時間クエリに応答するための前記メカニズムは、ビューを含む、請求項１０に記載の方法。
【請求項１２】
前記ビューは、具体化されたビューである、請求項１１に記載の方法。
【請求項１３】
前記ビュー内の現在のデータを前記ビュー内の以前のデータと比較して、前記データベースオブジェクトに加えられた変更を確定するステップをさらに含む、請求項１１に記載の方法。
【請求項１４】
前記第１のデータベーストリガは、前記時間クエリに応答するための前記メカニズムを活性化する、請求項１０に記載の方法。
【請求項１５】
前記命令文の実行に基づいて前記時間クエリの終了事象を検出するための第２のデータベーストリガを発生させるステップをさらに含む、請求項９に記載の方法。
【請求項１６】
前記時間クエリに基づいたベースクエリにアクセスするステップと、
前記第１のデータベーストリガが前記開始事象を検出した後に、
前記第２のデータベーストリガに、前記命令文を実行することによって前記終了事象を検出させ、
前記第２のデータベーストリガが前記終了事象を検出するのに応答して、前記時間クエリに対する応答を確定するために前記ベースクエリを発行するステップとをさらに含み、前記ベースクエリの結果は、前記時間クエリに対する前記応答を与える、請求項１５に記載の方法。
【請求項１７】
前記時間クエリに対する応答を確定するために前記ベースクエリを発行するための条件として、前記開始事象と前記終了事象との間に前記データベースオブジェクトに対する更新または削除がないことを確定するステップをさらに含む、請求項１６に記載の方法。
【請求項１８】
前記時間クエリに対する応答を確定するために前記ベースクエリを発行するための条件として、前記ベースクエリが単調であることを確定するステップをさらに含む、請求項１６に記載の方法。
【請求項１９】
前記開始事象を検出した後に、
前記時間クエリに基づいてビューを活性化させ、
前記命令文のセットを実行し、前記命令文のセットは、前記開始事象の後に発生した前記データベースに対する前記変更をもたらすことが可能なデータベース操作を反映し、さらに、
前記命令文のセットが実行されると前記ビュー内のデータに対する変更を分析して、
前記時間クエリに対する応答を確定し、
第２のデータベーストリガが終了事象を検出するのに応答して、前記時間クエリに対する前記応答を与えるステップをさらに含む、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
この発明はデータベース管理システムに関する。特に、この発明の実施例は、データベース回復ログを用いたデータベース内の事象の検出に関する。
【背景技術】
【０００２】
背景
データベース管理システム（ＤＢＭＳ）の重要な機能は、法医学的分析のため、または法的な要求事項を満たすためのいずれかのために、データベース内で発生した事象の過去のシーケンスを再構築することである。そのような事象の構築は、時間クエリに応答する（ＤＢＭＳ）を含み得る。時間クエリは、結果が１つ（またはそれ以上）前のデータベース状態からのみ計算され得るクエリである。ＤＢＭＳが購入注文およびユーザ役割を追跡する状況を考える。ユーザの役割は、購入注文するなどの、データベースシステム内の機能または行為を実行するユーザの権限を確定する。何らかの点で、営業マンに、購入注文を承認する権限が誤って与えられる。たとえば、データベース内のテーブルに記憶される営業マン役割が、購入注文権限を与えるよう誤って変更される。営業マンはそれから購入注文を承認し始め、ＤＢＭＳは購入注文を記録する。後の何らかの点で、監査人が、営業マンにはこの権限が与えられるべきではなかったことを発見する。監査人は、この役割変更がまだ加えられていない場合、購入注文承認をこれ以上許可しないように営業マンの役割を変更させ得る。監査人はまた、誤った権限を有する営業マンによって承認された購入注文のすべてを知る必要がある。この情報は現在の状態のデータベースでは入手できないことがある。なぜなら、購入注文の記録が削除されていたり、記録内の権限付与情報が、正当な権限を有する人による購入注文承認を反映するように上書きされていたりするからである。どの購入注文が営業マンによって承認されたかを確定するため、監査人は以下のような時間クエリの使用を望むことがある。
【０００３】
″ジョン・ドウ（John Doe）が営業マンであった間に彼によって承認されたすべての購入注文を見る。″
【発明の開示】
【発明が解決しようとする課題】
【０００４】
時間クエリの実際のフォーマットはこの例とは異なり得る。この例示的な時間クエリの始まり時間は、営業マンの役割が″営業マン（Salesman）″になったときである。この時間クエリの終了時間は、営業マンの役割が″Salesman″を含まないときである。したがって、ＤＢＭＳは、始まりおよび終了時間の間に営業マンによって承認されたすべての購入注文を返すことになる。
【０００５】
ＤＢＭＳが時間クエリに応答する必要がある他の状況がある。たとえば、オペレータがある商品を″特価″と誤って表示したかもしれない。この場合、誤った値段でなされた、ＤＢＭＳによって記録されるこの商品のすべての販売を確定することが望ましい。
【０００６】
そのような時間クエリに対する答えの確定には多数の課題がある。一貫性のある読み出し、フラッシュバッククエリなどの技術はこの問題に対する実行可能な解決策ではない。一貫性のある読み出しまたはフラッシュバッククエリは、過去の特定的な時点でのクエリを実行する。しかし、時間クエリに関連する開始および／または終了時間はわからないことがある。たとえば、営業マンの例を用いると、その特定の営業マンの雇用日および問題が発見された時間はわかっているかもしれない。しかし、権限が誤って与えられた時間は
わからないことがある。また、権限が訂正された時間がわからないことがある。
【０００７】
さらに、時間クエリに対する応答は、始まり時間と終了時間との間の対象のすべての結果を与えるべきである。たとえば、営業マンが誤って認めた購入注文のすべてが対象である。したがって、一貫性のある読み出し、フラッシュバッククエリなどの技術はこの問題に対する実行可能な解決策ではない。
【０００８】
また、過去のある時間へのデータベースの時点回復（point-in-time recovery）は実行可能な解決策ではない。上述のように、関連の時間がわからないことがある。また、時点回復は、ある範囲の時間にわたる情報を与えない。
【０００９】
時間クエリの問題に対する１つの従来の解決策は、アプリケーションのプログラマが、タイムスタンプされた変更の詳細な痕跡をアプリケーション内に維持することである。たとえば、プログラマは、データの更新前イメージおよび変更が加えられたときのタイムスタンプのログを取る前処理または後処理ステップを含むよう、すべての更新または削除命令文を内部で変換する。これによりデータベース内に付加的な列および行が作成され、これらを用いて時間クエリに答えることができる。
【００１０】
上記の例示的な時間クエリを用いると、属性″役割名（role name）″を有する役割テーブル（″役割（role）″）があり得、役割名は″Salesman″の値を有し得、この役割を有する個人が購入注文権限を有することを示す。また、注文テーブル（″注文（order）″）が属性″承認者＿名（approver_name）″を有し得、この値が、注文を承認した個人を示す。時間クエリに答えるため、アプリケーションのプログラマは両テーブル内に２つの新たな列、″いつ（when）″および″いつ＿削除された（when_deleted）″を作成し得る。プログラマは、更新または挿入命令文の一部として″when″列内に現在の時間を含める。さらに、プログラマは、行が削除されると″when_deleted″列内に現在の時間を含める。（代替的に、プログラマは、状態列を″削除された（ＤＥＬＥＴＥＤ）″に設定して、行の削除を新たな行の挿入に変更してもよい。）データベースに対するこれらの変更により、以下のＳＱＬ命令文を発行することによって上記の例示的な時間クエリに答えることができる：
【００１１】
【数１】
2009529729.tif 000003
【００１２】
しかし、そのような従来の技術には多数の欠点がある。データベーススキーマを拡張し、データベース行への変更の痕跡を正確に維持するには、アプリケーションのプログラマにとてつもない負担がかかる。すべての変更がアプリケーションによって監査されるため、性能が低下する。さらに、データベーステーブルのサイズが増大する。サイズ増大の１つの理由は、タイムスタンプ情報をテーブルから削除できない、つまりその行を削除できないためである。
【００１３】
アプリケーションに上記の変更を加えるのではなく、別の従来の方策では、データベースバックエンド内のコードを実行するデータベーストリガを作成して同様の結果を達成する。リチャードＴ．スノッドグラス（Richard T. Snodgrass）は、″ＳＱＬにおける時間順データベースアプリケーションの開発（Developing Time Oriented Database Applicat
ions in SQL）″において、そのような方法および他の関連事項を説明している。しかし、データベーストリガの作成は、アプリケーションのプログラマに負担がかかる技術と同様の問題に悩まされる。
【００１４】
多くのデータベースアプリケーションは、テーブルに固有の制約を課す。たとえば、テーブルは、特定のユーザが単一の特権しか有することができないように制約される。しかしこのため、データベースが、同一のテーブル内で特定のユーザについて複数の行を有することができない。したがって、上記の例では、同一のテーブルを用いてジョン・ドウに２つの異なる役割を割当てることができない。
【００１５】
１人のユーザに１つの役割しか許可しないテーブルの制限に対する解決策は、別個の履歴テーブルを作成することである。このペナルティは、″履歴″行を異なる区分に移動させることによって緩和され得る。しかし、スキーマ設計者は依然としてデータを区分する負担に直面する。
【００１６】
１人のユーザに１つの役割しか許可しないテーブルの制限に対する別の解決策は、タイムスタンプを加えるように制約を変更することであり、これは困難なプロセスである。しかし、この制約の適用は多数の規則の適用を含み、それらはＳＱＬ命令文に対する大幅な修正によって実施される。ＳＱＬに対するそれらの修正により、そのような機能性がＤＢＭＳに対して埋込まれれば、アプリケーションまたはＤＢＭＳに大幅なオーバーヘッドおよび複雑度が加えられる。
【００１７】
上記の技術に関連付けられたペナルティは、時間クエリが稀にしか発行されなくても生じる。たとえば、時間クエリは、監査時の調査の一部としてのみ発生し得る。さらに、クエリはデータベースオブジェクトの小さなサブセットに対して発行され得るのに対して、ペナルティはすべてのオブジェクトに対する変更について生じる。
【００１８】
したがって、ＤＢＭＳが時間クエリに応答する必要がある。アプリケーションのプログラマに多大な負担がかからない、またはデータベースバックエンドに対する大幅な変更を必要とする技術が必要である。さらに、データベースの通常操作に深刻な性能ペナルティをもたらさない技術が必要である。またさらに、データベースサイズの大幅な増大を必要としない技術が必要である。
【課題を解決するための手段】
【００１９】
この節で説明された方策は、追求され得る方策だが、先に想到または追求された方策とは限らない。したがって、特に断らない限り、この節で説明された方策のいずれも、単にこの節に含まれているからといって先行技術としての資格があると仮定されるべきではない。
【００２０】
この発明は、同様の参照番号が同様の要素を指す添付の図面において、限定としてではなく例として示される。
【発明を実施するための最良の形態】
【００２１】
詳細な説明
以下の説明では、説明のため、多数の特定的な詳細を記載してこの発明の完全な理解を与える。しかし、この発明はこれらの特定的な詳細がなくても実施され得ることが明らかになるであろう。他の場合では、この発明を不必要に不明瞭にするのを避けるため、周知の構造および装置がブロック図形態で示される。
【００２２】
概要
この発明の実施例は、データベース内でいつ事象が発生したかを確定するための方法である。データベースの少なくとも一部が、事象より前の時点に復元される。回復ログが、回復ログ内に記述される変更をもたらすことが可能なデータベース操作を表わす命令文（たとえばＳＱＬ命令文）に翻訳される。この命令文の実行に基づいて事象を検出するためのメカニズムが作成される。たとえば、事象を検出するためのデータベーストリガが作成される。復元されたデータベースに対して命令文が実行されて、メカニズムに事象を検出させる。
【００２３】
この発明の別の実施例は、時間クエリに応答するための方法である。ユーザは、開始事象、終了事象を有する時間クエリ、ならびに開始および終了事象の間の時間に関連するクエリを与える。開始事象は、先の段落で述べられた実施例と同様の態様で検出され得る。終了事象を検出するためのトリガ事象が発生され、クエリブロックに対する結果を確定するためのメカニズムが発生される。たとえば、回復ログに基づいたデータベース操作を表わす命令文（たとえばＳＱＬ）を実行することによって、具体化されたビューが発生されて投入される。具体化されたビュー内の情報の分析に基づいて、時間クエリが答えられる。
【００２４】
例示的な時間クエリ
１つの実施例では、ＤＢＭＳへの時間クエリに対する応答が与えられる。例示のため、以下の例示的な時間クエリが用いられる。ユーザは、以下の時間クエリに対する答えを知りたいことがある：
″ジョン・ドウが営業マンであった間に彼によって承認されたすべての購入注文を見る。″
時間クエリの実際のフォーマットは、データベース操作に容易に変換されるフォーマットに基づき得る。たとえば、時間クエリは、以下の例のようにＳＱＬに基づき得る。一般的に、時間クエリのフォーマットは“ＢＥＧＩＮ  ＱＵＥＲＹ  ＥＮＤ”である。ＢＥＧＩＮおよびＥＮＤブロックは、開始および終了点を指定する。一般的に、ＢＥＧＩＮおよびＥＮＤブロックは事象指定であり得る。換言すれば、時間は指定されない。開始または終了時間が指定される例を含む特別の場合が以下に説明される。この例では、開始事象は、役割″Salesman″をユーザ″John Doe″に割当てるデータベーステーブル内の行の更新または挿入である。したがって、以下のＢＥＧＩＮブロックが事象を記述するのに好適である。″開始事象″は、ＢＥＧＩＮブロック内の条件が真になるときであると規定される。
【００２５】
roles.name=“John Doe”およびroles.role_name=“Salesman”である場合、ＢＥＧＩＮは役割のＡＦＴＥＲ  ＩＮＳＥＲＴまたはＵＰＤＡＴＥである。
【００２６】
この例を続けて、ＥＮＤブロックは、いつジョン・ドウがもはや営業マンの役割を有しなくなるかを記述するデータベース事象を反映する。以下の例示的なＥＮＤブロックは、更新または削除によってユーザ″John Doe″から役割″Salesman″が除去されるときを指定する。″終了事象″は、ＥＮＤブロック内の条件が真になるときであると規定される。
【００２７】
roles.name=“John Doe”およびroles.role_name=“Salesman”である場合、ＥＮＤは役割のＡＦＴＥＲ  ＤＥＬＥＴＥまたはＵＰＤＡＴＥである。
【００２８】
この例を続けて、以下の例示的なＱＵＥＲＹブロックが、どの販売がジョン・ドウによって承認されたかの質問に答えるのに好適である。
【００２９】
【数２】
2009529729.tif 000004
【００３０】
時間クエリは、１つまたはそれ以上のクエリが開始事象と終了事象との間に発行されるという前提で、ＱＵＥＲＹブロックに基づいたそのクエリの結果を分析することによって答えられ得る。本明細書中において、１つ以上のクエリはベースクエリと称される。ＢＥＧＩＮ  ＱＵＥＲＹ  ＥＮＤブロックはＳＱＬと同様のフォーマットを有するが、これは必須ではない。
【００３１】
いつデータベース事象が発生したかを確定するプロセスフロー
図１は、データベース内でいつ事象が発生したかを検出するためのプロセス１００を図示するフローチャートである。１つの実施例では、プロセス１００は、時間クエリを受けることに応答して開始される。プロセス１００は、ジョン・ドウに購入注文承認権限の役割が誤って与えられた時間中にどの販売がジョン・ドウによって承認されたかをユーザが知りたがっている例を用いて説明される。プロセス１００の説明を助けるため、上記のＢＥＧＩＮおよびＥＮＤブロックが用いられる。このように、プロセス１００を用いて、ジョン・ドウに購入注文承認権限を有する役割が与えられるなどの事象がいつ発生したかを確定することができる。上述のように、ＢＥＧＩＮブロックはこの条件を記述する。しかし、プロセス１００によって検出される事象は、時間クエリの開始事象に限定されない。より一般的に、プロセス１００を用いて、いずれかの指定された事象がいつデータベース内で起こったかを検出することができる。図２のプロセス２００および図３のプロセス３００は、どの注文がジョン・ドウによって承認されたかなどの時間クエリに対する答えを確定する詳細を与える。
【００３２】
図１のステップ１０２において、データベースの少なくとも一部が、調査中の事象より前の時間に復元される。いくつかの場合、好適な時間が仮定され得る。事象が、ジョン・ドウに購入注文権限の役割が割当てられた時間である場合、好適な時間はジョン・ドウの雇用日であり得る。より最近の時間に到達しない場合、データベースの最も古いバージョンが復元され得る。全データベースを復元することは必須ではない。たとえば、営業マンの例では、関連の情報は販売テーブルまたは役割テーブルのいずれかであろう。したがって、それらのテーブルが復元される。販売または役割テーブルへのアクセスは、インデックスなどの他のオブジェクト（従属しているオブジェクト）に依存し得る。したがって、従属しているオブジェクトも復元する必要があり得る。本明細書中で用いられるように、″従属しているオブジェクト″という用語は、別のデータオブジェクトへのアクセスもしくは編集を促進するため、またはより効率的にそうするために用いられるいずれかのオブジェクトを意味する。復元するデータベースの部分を限定するさらなる詳細が以下に述べられる。
【００３３】
ステップ１０４において、ＢＥＧＩＮブロック内の条件（開始事象）を検出するための１つ以上のデータベーストリガが作成される。ＤＢＭＳでは、トリガは、特定的な事象が発生すると自動的に実行されることになる一連の行為を指定するオブジェクト（たとえばプロシージャ）である。トリガによって指定される一連の行為は典型的に、ＳＱＬまたはＰＬ／ＳＱＬ（カリフォルニア州レッドウッドショア（Redwood Shores, California）のオラクル社（Oracle Corporation）から入手可能なＳＱＬの手続型言語拡張）などのハイレベルデータベース言語で命令として書かれる。たとえば、リレーショナルデータベースでは、トリガは、データベーステーブルまたはテーブルビューの行が更新、挿入、または
削除されると発火するように設計され得る。したがって、トリガは典型的に、単一のデータベーステーブルに関連付けられる。営業マンの例を用いると、関連のテーブルは、ＢＥＧＩＮブロック内に指定される役割テーブルである。したがって、役割テーブルについてのデータベーストリガが作成され得る。ＢＥＧＩＮブロックが複数のテーブルを参照した場合、各テーブルについてのデータベーストリガが作成される。
【００３４】
他のテーブルについてのデータベーストリガが作成され得る。たとえば、ユーザは事象を指定するのではなく、ＢＥＧＩＮブロック内に壁時計時間を指定してもよい。したがって、営業マンの例では、役割テーブルに対して設定するトリガはない。しかし、壁時計時間とＤＢＭＳによって保たれる論理時間との間の変換を有するテーブルについてのトリガが設定され得る。たとえば、特定のテーブルが、現実のまたは壁時計時間の１００秒おきくらいにＳＣＮ（システム変更番号）または他の論理時間を記録し得る。このテーブルは、各ＳＱＬ命令文がコミットされたときについての正確な壁時計時間を有するとは限らないが、非常に近い近似を与えることができる。トリガは、壁時計時間が打たれる（またはほぼ打たれる）ときを確定するように設定される。
【００３５】
トリガは、ＢＥＧＩＮブロック内に指定される列が修正されるときにのみトリガが実行されることを指定するように最適化され得る。営業マンの例では、ＢＥＧＩＮブロック内の列は″名（name）″および″役割＿名（role_name）″である。一般的に、ステップ１０４において発生されるトリガは、ＢＥＧＩＮブロック内の条件が真になるときを検出することになるいずれかのメカニズムであり得る。
【００３６】
トリガは、ＢＥＧＩＮブロック内の条件を検出すると所望の行為が起こるように実現される。たとえば、所望の行為は、時間クエリに対する応答の確定であり得る。データベーストリガの実現は、以下に説明するように多数の要因に依存する。データベーストリガは、１つの実施例では、ＥＮＤブロックを調べることによって実現される。ＢＥＧＩＮブロックがＥＮＤブロックと等しいことがわかっている場合は、トリガの本体をＱＵＥＲＹブロック自体に基づいて実現して、時間クエリに答えてもよい。しかし、ＱＵＥＲＹブロックに基づいた１つ以上のクエリを発行する結果を計算しなければならない時間範囲（ＥＮＤ−ＢＥＧＩＮ）がある場合は、トリガの本体が、開始事象が検出されたことを示すフラグを設定し得る。フラグを用いる一例が図３のプロセス３００に記載されており、このフラグを用いて、具体化されたビューの投入をトリガする。
【００３７】
任意のステップ１０６において、ＥＮＤブロック内の条件（″終了事象″）を検出するためのトリガが作成される。プロセス１００の最終目標が、開始事象が発生した壁時計時間を確定することである場合は、ステップ１０６を実行する必要はない。しかし、プロセス１００は時間クエリに答えるための始点として用いられ得るため、終了トリガを作成することによって時間クエリについての関連の範囲を確定することができる。終了トリガは所望のアプリケーションに従って実現され、以下に説明される。
【００３８】
ステップ１０８において、データベースの回復ログから、データベース操作を表わす命令文が再構築される。１つの実施例では、回復ログからＳＱＬ命令文が再構築される。たとえば、カリフォルニア州レッドウッドショアのオラクル社によって提供されるOracle LogMinerを用いて回復ログからＳＱＬを発生させてもよい。しかし、LogMinerを用いることは必須ではない。
【００３９】
再構築されるＳＱＬ命令文は、ログ内に記録されるデータベース変更を加えるのに用いられたのと同一のＳＱＬ命令文であるとは限らない。たとえば、データベースに対する特定の変更をもたらし得る多くの異なるＳＱＬ命令文があり、回復ログ情報は、その変更をもたらした正確なＳＱＬ命令文を確定することができないことがある。しかし、それでも
事象は検出され得る。特定の例として、多くの異なるＳＱＬ命令文が、ジョン・ドウに営業マンの役割を割当て得る。しかし、プロセス１００は、その変更をもたらしたＳＱＬ命令文にかかわらず、ジョン・ドウへの営業マンの役割に対する変更を検出することができる。
【００４０】
データベース操作を表わす命令文を、データベースに関連付けられたすべての回復ログについて再構築することは必須ではない。たとえば、例示的な時間クエリについての開始事象を検出するためにプロセス１００が用いられている場合、処理される必要があるのは、ＢＥＧＩＮブロック内のオブジェクトのセットに属する回復ログのみである。例示的な時間クエリについての終了事象を検出するためにプロセス１００が用いられている場合は、ＥＮＤブロック内のオブジェクトのセットに属する回復ログが処理される必要がある。上述のように、プロセス１００は開始事象の確定に限定されず、より一般的に事象検出に当てはまる。したがって、より一般的に、データベース操作が再構築される回復ログは、検出中の事象に関連付けられたオブジェクトに属するログのみである。たとえば、データベース操作は、以下に関連付けられたオブジェクトについて再構築され得る：１）開始事象、２）終了事象、３）ＱＵＥＲＹブロック、４）開始事象、終了事象、およびＱＵＥＲＹブロックの実行を検出するために用いられるカタログオブジェクトおよびインデックスなどのメタデータ。
【００４１】
ステップ１１０において、データベースに対する変更を適用するため、再構築されたデータベースにデータベース操作が適用される。上述のように、適用される必要があるのは関連の変更のみである。たとえば、販売テーブル、役割テーブル、または従属しているオブジェクトに関連した変更のみがデータベースに適用される。
【００４２】
ステップ１１２においてＢＥＧＩＮトリガが発火する場合、次にステップ１１４において、トリガ行為がトリガの本体に規定されているように適用される。上述のように、トリガは広範な行為を実行することができる。１つの実施例では、トリガ行為は、いつ事象が起こったかを確定して報告する。たとえば、ＳＣＮ（システム変更番号）を壁時計時間と相関させることによって、ジョン・ドウに購入を承認する権限が与えられた時間が確定されて報告される。別の実施例では、開始トリガの発火に応答して、連続した行為が取られ、開始事象の後から別の時間までにデータベースに加えられた変更を確定する。このように、時間クエリに答えることができる。たとえば、ＤＢＭＳは、ジョン・ドウに購入注文権限が与えられた後から権限が剥奪されたときまでにどの購入注文がドウよって承認されたかを確定する。
【００４３】
時間クエリに応答するためのプロセスフロー
開始事象が検出された後、ＱＵＥＲＹブロックに基づいた１つ以上のクエリが発行され、その結果が分析される。データベースの１つ以上のバージョンに対してベースクエリが実行される。ベースクエリの意味、およびベースクエリが実行されるデータベースのバージョンは、（ａ）ＱＵＥＲＹブロック内の命令文、ならびに（ｂ）開始および終了事象の間にデータベースの行が更新または削除されたかどうか、に依存する。
【００４４】
時間クエリに応答するための技術は、少なくとも一部分において、ベースクエリが単調であるかどうかに依存する。クエリＱｍについて、単調なクエリは、Ｑｍ（ｔ１）の結果セットが、ｔ２＞ｔ１である場合Ｑｍ（ｔ２）の結果セットのサブセットであるか、またはそれに等しいクエリである。ベースクエリが単調であり、時間クエリに関連した行の更新または削除がない場合は、次に終了事象時のデータベースのバージョンに対して単一のベースクエリが実行され得る。すなわち、回復ログ内の変更が、終了事象がトリガされるまで、回復されたデータベースに適用され、ＱＵＥＲＹブロックの実行結果は、単一の点で−終了事象時に−ＱＵＥＲＹブロックを実行することによって確定され得る。図２は、
この第１の場合についてのこの発明の実施例を説明する。
【００４５】
どの注文がジョン・ドウによって承認されたかを確定する例を考える。以下のベースクエリが、以下のＳＱＬ命令文を用いて終了事象時に発行され得る。
【００４６】
【数３】
2009529729.tif 000005
【００４７】
上記の命令文は、ジョン・ドウによって承認されたすべての注文を返すことになる。これにより、この特別の場合についての正確な結果が与えられる。しかし、ベースクエリが単調でない場合、または行の更新もしくは削除がある場合は、終了事象時のデータベースの状態は、時間クエリに答えるための情報のすべてを含むわけではない。たとえば、ジョン・ドウが購入注文を承認したときに行が挿入されたが、その後注文を修正したためその行が更新された場合、その更新された行は、当初の注文情報を含んでいない。図３は、具体化されたビューを用いて、このより一般的な場合についての結果を与えるこの発明の実施例を説明する。
【００４８】
Ａ）  単調なクエリおよびデータベースの削除／更新なし
図２は、この発明の実施例に従った、時間クエリに対する結果を与えるプロセス２００を説明する。プロセス２００の説明を容易にするため、営業マンに関する例示的な時間クエリが用いられるが、プロセス２００はこの例に限定されない。プロセス２００は、プロセス１００におけるＢＥＧＩＮトリガの発火に応答して開始され得るが、プロセス２００を開始するためにプロセス１００を用いることは必須ではない。また、プロセス２００のステップのいくつかはトリガの発火より前に実行され得る。プロセス２００はトリガ自体の行為のいくつかまたはすべてを含み得るが、これは必須ではない。
【００４９】
ステップ２０２において、ＱＵＥＲＹブロックに関連付けられたベースクエリが単調であるかどうかについて確定がなされる。単調でない場合、次にプロセス２００は結果を与えることなく終了する。所望であれば、トリガの発火より前にステップ２０２を実行してもよい。非単調なクエリを単調なクエリに変換するための技術が説明されている。たとえば、テリー等（Terry et al.）による論文″追記型データベースにわたる連続的なクエリ（Continuous Queries over Append-Only Databases）″は、非単調なクエリを単調なクエリに変換するための技術を説明している。ユーザの時間クエリに応答するために形成される当初のベースクエリが非単調である場合、ベースクエリを単調な形態に変換することが可能であり得る。しかし、ベースクエリを単調な形態に変換する代わりに、プロセス２００は終了してもよい。プロセス２００が終了する場合、次に図３のプロセス３００が実行されて結果が与えられ得る。
【００５０】
ベースクエリが単調である場合、次にステップ２０４において、データベースについての回復ログからデータベース操作が再構築される。処理される必要がある回復ログは、ＱＵＥＲＹブロック、終了事象に関連したオブジェクト、ならびにＱＵＥＲＹブロックまたは終了事象トリガを実行するために必要なカタログオブジェクトおよびインデックスなどの他の従属しているオブジェクトについての回復ログのみである。たとえば、例示的なＱＵＥＲＹブロックは注文テーブルを指定しており、したがって、注文テーブルについての回復ログ、注文テーブル、カタログオブジェクトおよび役割についてのいずれかのインデックスのみが処理される。
【００５１】
ステップ２０６は、ベースクエリに関連した行に削除または更新があるかどうかについての確定である。そうである場合、プロセス２００は、時間クエリに対する結果を与えることなく終了する。たとえば、ジョン・ドウの承認者名を有する注文テーブルの行に削除または更新がある場合、次にプロセスは終了する。プロセス２００が結果なしで終了する場合、図３のプロセス３００が実行されて結果が与えられ得る。
【００５２】
プロセス２００は、ステップ２０８において、終了トリガが発火するまで、さらにデータベース操作を再構築し、関連の削除または更新が発生したかどうか確定し続ける。したがって、終了トリガは、ベースクエリが単調であり、関連の更新または削除がない場合にのみ発火する。終了トリガが発火する場合、次にステップ２１０において、データベースに対してベースクエリが実行される。たとえば、ジョン・ドウに権限が与えられた時間と権限が取り消された時間との間にドウがどの注文を承認したかを確定するため、以下のベースクエリが実行され得る：
【００５３】
【数４】
2009529729.tif 000006
【００５４】
Ｂ）  具体化されたビューを用いる一般的な場合
図３は、この発明の実施例に従った、具体化されたビューを用いて時間クエリに対する結果を与えるプロセス３００のステップを図示するフローチャートである。プロセス３００の説明を容易にするため、営業マンについての例示的な時間クエリを用いるが、プロセス３００はこの例に限定されない。プロセス３００は、上述のように、図２のプロセス２００が時間クエリに対する結果を与えることなく終了する場合に実行され得る。しかし、先にプロセス２００を実行することなくプロセス３００を実行してもよい。
【００５５】
ステップ３０２において、ビューおよびステージング領域が作成される。具体化されたビューとは、データが最初に収集および導出されたベーステーブルとは別個にビューデータのコピーが記憶されるビューである。具体化されたビューに含まれるデータは本明細書中において（″具体化されたデータ″）と称される。具体化されたビューを用いることにより、ベースクエリを繰返し発行する必要がなくなる。
【００５６】
具体化されたビューは、開始および終了事象の間に加えられた変更によるベースクエリに対する結果のサブセットを同定するのを助ける。具体化されたビューは、回復ログがデータベースに再適用されると自動的に投入され得る。しかし、他の解決策を用いてもよい。また、具体化されたビューが自動的に投入されることは必須ではない。１つの実施例では、回復ログはＳＱＬ層を通じて適用され、これにより、具体化されたビューが自動的に投入される。
【００５７】
具体化されたビューは、ＱＵＥＲＹブロックに基づいて作成される。１つの実施例に従って、具体化されたビューはブール列を有する。ブール列は、ビュー内の結果行が時間クエリを満たした間の時間窓を記憶することになる。以下は、営業マンの例における時間クエリについての例示的な具体化されたビューである。
【００５８】
【数５】
2009529729.tif 000007
【００５９】
この例示的な具体化されたビューでは、″ＦＬＡＧ″は、orders_viewが作成されると０に設定されるグローバル状態変数である。ＦＬＡＧは、ＢＥＧＩＮ事象に達した後に１に設定される。ＦＬＡＧは、ＢＥＧＩＮトリガの本体の実行によって設定され得る。
【００６０】
ステップ３０２の説明を続けて、終了事象に達するとユーザに返されることになる結果を記憶するためのステージング領域が作成される。営業マンの例では、営業マンは承認権限が与えられた開始点ではまったく注文を承認していないと推定されるため、ステージング領域は当初は空であることになる。明らかに、時間クエリの指定に依存して、開始点でステージング領域が空でない場合もあり得る。
【００６１】
具体化されたビューおよびステージング領域は、説明を容易にするため、および具体化されたビューの実現例を再び用いるため、別個のオブジェクトとして説明される。しかし、両方について同一のオブジェクトを用いてもよい。たとえば、具体化されたビューは状態列で増強され得、ステージング領域として作用し得る。具体化されたビューを投入するコードは、状態列に対処するよう適切に修正されるべきである。
【００６２】
ステップ３０４において、データベースの回復ログから、データベース操作を表わす命令文が再構築される。１つの実施例では、回復ログからＳＱＬ命令文が再構築される。換言すれば、回復は、ブロックレベルにおける物理的アプリケーションではなく、ＳＱＬ層における論理的アプリケーションである。
【００６３】
ステップ３０６において、データベース操作を表わす命令文がデータベースに適用される。コミット操作が発生するたびに、ステップ３０８において、具体化されたビューが自動的に投入される。
【００６４】
上述のように、プロセス３００は、削除および更新操作がある、ならびに／またはベースクエリが非単調である状況に対処するよう適合される。これらの条件に対処するため、ステップ３１０が用いられる。ステップ３１０において、結果のステージング領域および具体化されたビュー内の行間の設定された差がステージング領域に加えられる。具体化されたビュー内には見つけられるがステージング領域内には見つけられないいずれの行も、ステージング領域にコピーされる。営業マンの例を用いると、ステージング領域は、営業マンに注文を承認する権限が与えられたまさにその瞬間は空である。したがって、具体化されたビュー内には現われるがステージング領域内には現われない行は、営業マンがそのような権限を与えられた後に注文を承認したことを示す。
【００６５】
ステージング領域内には見つけられるが具体化されたビュー内には見つけられないいずれの行も、状態フラグをＤＥＬＥＴＥＤにセットして、ステージング領域内に保持される。営業マンの例を用いると、ステージング領域内には現われるが具体化されたビュー内には現われない行は、営業マンによって承認された注文が後に処理され、かつ注文処理が完了したためその行が後に削除されたことを示し得る。これは時間クエリに関連しているので、そのような情報はユーザに返されるべきである。実質上、ステージング領域を修正すると、ユーザにとっての対象の期間中の時間テーブルがもたらされる。
【００６６】
プロセス３００は、ステップ３１２において終了トリガに達するまで、さらに他の回復ログを評価し続ける。そして制御はステップ３１４に進み、ここで、ステージング領域内に配置される結果がユーザに返される。そしてプロセス３００は終了する。
【００６７】
具体化されたビューを用いない代替的な実施例
プロセス３００のステップ３０２において作成されるビューが具体化されたビューであることは必須ではない。具体化されたビューを用いずに、ＱＵＥＲＹブロック内に指定されるベースクエリを直接実行してもよい。ベースクエリが、開始事象後に修正される行のみを返すようにするため、ベースクエリは開始事象がトリガされた直後に実行され、その結果は別個のテーブルに保存される。その後、やり直しログが処理され、各ＣＯＭＭＩＴの後、ベースクエリが直接実行され、先のステップで保存された行のセットがベースクエリの結果セットから除去される。この行のセットは、具体化されたビューメカニズムによって増分的に投入されたであろう行を構成する。この方法では、具体化されたビューの機能性は、各ＣＯＭＭＩＴ操作の後にＱＵＥＲＹブロックを再実行することによってシミュレートされる。
【００６８】
ベースクエリの実行後、ベースクエリ結果がステージング領域に対して比較されて設定された差が計算され、これはプロセス３００のステップ３１０と同様の態様でステージング領域に加えられる。
【００６９】
データベースのどの部分を復元するかの限定
上述のように、データベースに回復ログを適用する前にデータベースの全部分を復元することは必須ではない。一般的に、ＢＥＧＩＮ、ＱＵＥＲＹおよびＥＮＤブロックが分析されて、復元しなければならないテーブルのセットおよび従属しているオブジェクトが確定される。営業マンの例では、復元しなければならないのは注文および役割テーブルのみである。しかし、ＢＥＧＩＮ、ＱＵＥＲＹおよびＥＮＤブロックを評価するために用いられ得るインデックスなどの、いずれの従属しているオブジェクトも復元すべきである。さらに、ＢＥＧＩＮ、ＱＵＥＲＹおよびＥＮＤブロックをコンパイルおよび実行するために必要なすべてのカタログまたは辞書オブジェクトも復元される。ほとんどのデータベースシステムでは、カタログまたは辞書オブジェクトは、Oracle ＳＹＳＴＥＭまたはＳＹＳスキーマなどの特別のスキーマに属し、容易に同定され得る。
【００７０】
データベースのサブセットのみを復元するために１つ以上の条件が満たされるべきである。第１の条件は、データベースが、テーブルのサブセットの復元を許可すべきであるというものである。第２の条件は、回復ログから発生されるデータベース操作を表わす命令文（たとえばＳＱＬ）が単一のテーブル内の列の値を参照するというものである。換言すれば、一般的なＳＱＬ命令文は複数のテーブルを参照すべきでない。しかし、変更を最初にもたらしたＳＱＬ命令文が複数のテーブルを参照した可能性がある。
【００７１】
単一のテーブルを参照するＳＱＬ命令文を発生させる回復の種類を示すため、通常の実行時間中に発行された以下の単純なＳＱＬ命令文を考える：
【００７２】
【数６】
2009529729.tif 000008
【００７３】
上のＳＱＬ命令文において、″myseq″はＳＥＱＵＥＮＣＥ変数である。回復中に、やり直しログが調べられ、以下のＳＱＬ命令文が発生される：
【００７４】
【数７】
2009529729.tif 000009
【００７５】
なお、回復中に発生されるＳＱＬ命令文は″myseq″に依存しない。したがって、順方向進行中に発行されるＳＱＬ命令文は″myseq″に依存するが、回復中に発行されるＳＱＬは依存しない。
【００７６】
別の例として、順方向進行中に発行されるＳＱＬ命令文が、サイドテーブルを参照して注文テーブルを更新する場合を考える。この場合、回復中に発生されるＳＱＬはサイドテーブルを含まないことがある。たとえば、サイドテーブル″emp″を参照する以下のＳＱＬ命令文が順方向進行中に発行される。
【００７７】
【数８】
2009529729.tif 000010
【００７８】
順方向進行中、ＳＱＬ命令文は、テーブル″emp″がアクセスされて役割テーブルを更新するようにする。特に、値″John Doe″がempテーブルからアクセスされ得る。しかし、回復プロセス中に発生されるＳＱＬが″emp″テーブルを参照することはない。たとえば、回復中に以下のＳＱＬが発生され得、これは、順方向進行中に用いられたＳＱＬと同一の効果を有することになる。
【００７９】
【数９】
2009529729.tif 000011
【００８０】
時間クエリについての特別の場合
ユーザが発行する時間クエリは、開始事象および終了事象を必ずしも指定しているとは限らない。たとえば、ユーザは、ＢＥＧＩＮブロックまたはＥＮＤブロックを事象の発生（すなわち条件が真になる）として規定する代わりに、これらのブロックに壁時計時間を割当てることがある。図１のステップ１０４において先に述べたように、データベーストリガの性質は、ユーザが開始および終了事象を指定する方法に依存し得る。
【００８１】
別の場合では、ユーザが、開始または終了事象のいずれについても全く情報を与えないことがある。ユーザが開始事象を指定しない場合、データベースは、時間の開始または何らかの実質的な始まり時間に復元され得る。終了事象が指定されない場合、終了事象はデフォルトで現在の時間または別の実質的な終了時間となり得る。
【００８２】
別の場合では、ユーザが、ある変更がいつ加えられたかを確定することのみを望んでいることがある。この場合、開始事象は終了事象と等しく、時間クエリに答える結果は、他のデータベース情報を用いて壁時計時間と相関され得る値（たとえばＳＣＮまたはログシーケンス番号）である。
【００８３】
別の場合では、ユーザが、ある変更が加えられたときに時点クエリを実行することを望んでいることがある。たとえば、列が誤って更新された場合、時間クエリは、その誤った更新前の最新の値を要求し得る。または、時間クエリは、その指定された変更が加えられたときの何らかの他のデータベース状態を要求し得る。この場合、ＱＵＥＲＹブロックに基づいたクエリが、ＢＥＧＩＮブロックによって記述される変更がデータベースに適用される直前に実行されることになる。この場合、開始事象に出会う際に実行されるトリガの本体は、ＱＵＥＲＹブロック自体であり得る。
【００８４】
ハードウェア概要
図４は、本発明の実施例が実現され得るコンピュータシステム４００を図示するブロック図である。コンピュータシステム４００は、情報を通信するためのバス４０２または他の通信メカニズムと、バス４０２に結合される、情報を処理するためのプロセッサ４０４とを含む。コンピュータシステム４００はまた、バス４０２に結合される、プロセッサ４０４によって実行されるべき情報および命令を記憶するための、ランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置などのメインメモリ４０６も含む。メインメモリ４０６はまた、プロセッサ４０４によって実行されるべき命令の実行中に、一時変数または他の中間情報を記憶するために用いられ得る。コンピュータシステム４００はさらに、バス４０２に結合される、プロセッサ４０４のための静的情報および命令を記憶するための読出専用メモリ（ＲＯＭ）４０８または他の静的記憶装置を含む。情報および命令を記憶するための、磁気ディスクまたは光学ディスクなどの記憶装置４１０が設けられ、バス４０２に結合される。
【００８５】
コンピュータシステム４００は、コンピュータユーザに情報を表示するための、陰極線管（ＣＲＴ）などのディスプレイ４１２にバス４０２を介して結合され得る。プロセッサ４０４に情報および指令選択を通信するための、英数字および他のキーを含む入力装置４１４がバス４０２に結合される。別の種類のユーザ入力装置は、プロセッサ４０４に方向情報および指令選択を通信するため、ならびにディスプレイ４１２上のカーソルの動きを制御するためのマウス、トラックボール、またはカーソル方向キーなどのカーソル制御部４１６である。この入力装置は典型的に、第１の軸（たとえばｘ）および第２の軸（たとえばｙ）の２本の軸における２自由度を有し、これにより、この装置が平面内の位置を指定することできる。
【００８６】
本発明は、本明細書中において説明される技術を実現するためのコンピュータシステム４００の使用に関する。本発明の１つの実施例によると、それらの技術は、プロセッサ４０４がメインメモリ４０６に含まれる１つ以上の命令の１つ以上のシーケンスを実行するのに応答して、コンピュータシステム４００によって行われる。そのような命令は、記憶装置４１０などの別の機械読取可能媒体からメインメモリ４０６に読込まれ得る。メインメモリ４０６に含まれる命令のシーケンスの実行により、プロセッサ４００が、本明細書中において説明されるプロセスステップを実行することになる。代替的な実施例では、ソフトウェア命令の代わりに、またはソフトウェア命令と組合せて、配線による回路構成を用いて本発明を実現してもよい。したがって、本発明の実施例は、ハードウェア回路構成およびソフトウェアのいずれの特定的な組合せにも限定されない。
【００８７】
本明細書中で用いられるような″機械読取可能媒体″という用語は、機械に特定的な態様で操作させるデータを与えるのに関与するいずれかの媒体を指す。コンピュータシステム４００を用いて実現される実施例では、たとえばプロセッサ４０４に実行用の命令を与える際に、さまざまな機械読取可能媒体が含まれる。そのような媒体は、不揮発性媒体、揮発性媒体、および送信媒体を含む多くの形態を取り得るがこれらに限定されない。不揮発性媒体は、たとえば、記憶装置４１０などの光学または磁気ディスクを含む。揮発性媒
体は、メインメモリ４０６などの動的記憶装置を含む。送信媒体は、バス４０２を備える配線を含む、同軸ケーブル、銅線および光ファイバを含む。送信媒体はまた、電波および赤外線データ通信中に発生されるような音波または光波の形態も取り得る。すべてのそのような媒体は、媒体によって搬送される命令が、機械に命令を読込む物理メカニズムによって検出され得るように具体的である必要がある。
【００８８】
機械読取可能媒体の一般的な形態は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、もしくはいずれかの他の磁気媒体、ＣＤ−ＲＯＭ、いずれかの他の光学媒体、パンチカード、紙テープ、孔のパターンを有するいずれかの他の物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、いずれかの他のメモリチップもしくはカートリッジ、後で説明されるような搬送波、またはそこからコンピュータが読込可能ないずれかの他の媒体を含む。
【００８９】
実行用の１つ以上の命令の１つ以上のシーケンスをプロセッサ４０４に搬送する際、さまざまな形態の機械読取可能媒体が含まれ得る。たとえば、命令は当初、リモートコンピュータの磁気ディスクで搬送され得る。リモートコンピュータは、自身の動的記憶装置に命令をロードし、モデムを用いて電話線で命令を送ることができる。コンピュータシステム４００にローカルなモデムが電話線上のデータを受け、赤外線送信機を用いてそのデータを赤外線信号に変換することができる。赤外線検出器が、赤外線信号内に搬送されるデータを受信することができ、適切な回路構成がそのデータをバス４０２に乗せることができる。バス４０２は、データをメインメモリ４０６に搬送し、そこからプロセッサ４０４が命令を取出して実行する。メインメモリ４０６が受けた命令は、プロセッサ４０４による実行の前または後のいずれかに、記憶装置４１０に任意で記憶され得る。
【００９０】
コンピュータシステム４００はまた、バス４０２に結合される通信インターフェイス４１８も含む。通信インターフェイス４１８は、ローカルネットワーク４２２に接続されるネットワークリンク４２０に、双方向データ通信結合を与える。たとえば、通信インターフェイス４１８は、対応する種類の電話線にデータ通信接続を与えるための統合サービスデジタル網（ＩＳＤＮ）カードまたはモデムであり得る。別の例として、通信インターフェイス４１８は、互換性のあるＬＡＮにデータ通信接続を与えるためのローカルエリアネットワーク（ＬＡＮ）カードであり得る。無線リンクも実現され得る。いずれのそのような実現例においても、通信インターフェイス４１８は、さまざまな種類の情報を表わすデジタルデータストリームを搬送する電気、電磁または光学信号を送受信する。
【００９１】
ネットワークリンク４２０は典型的に、１つ以上のネットワークを通じて他のデータ装置にデータ通信を与える。たとえば、ネットワークリンク４２０は、ローカルネットワーク４２２を通じてホストコンピュータ４２４に、またはインターネットサービスプロバイダ（ＩＳＰ）４２６によって操作されるデータ機器に接続を与え得る。ＩＳＰ４２６は次に、現在一般的に″インターネット″４２８と称される広域パケットデータ通信網を通じてデータ通信サービスを与える。ローカルネットワーク４２２およびインターネット４２８は両方とも、デジタルデータストリームを搬送する電気、電磁または光学信号を用いる。さまざまなネットワークを通る信号、ならびにコンピュータシステム４００との間でデジタルデータを搬送し合うネットワークリンク４２０上のおよび通信インターフェイス４１８を通る信号は、情報を移送する搬送波の例示的な形態である。
【００９２】
コンピュータシステム４００は、ネットワーク、ネットワークリンク４２０および通信インターフェイス４１８を通じて、メッセージを送り、プログラムコードを含むデータを受信することができる。インターネットの例では、サーバ４３０が、インターネット４２８、ＩＳＰ４２６、ローカルネットワーク４２２および通信インターフェイス４１８を通じてアプリケーションプログラムについての要求コードを送信し得る。
【００９３】
受けたコードは受信時にプロセッサ４０４によって実行され得、および／または後で実行するために記憶装置４１０もしくは他の不揮発性記憶装置に記憶される。この態様で、コンピュータシステム４００は、搬送波の形態のアプリケーションコードを得ることができる。
【００９４】
上記の明細書では、本発明の実施例が、実現例ごとに異なり得る多数の特定的な詳細を参照して説明された。したがって、発明であるもの、および出願人によって発明であると意図されるものを唯一および独占的に示すものは、いずれの後の訂正も含む、この出願から生じる一組の請求項であり、そのような請求項が生じる特定的な形態におけるものである。そのような請求項に含まれる用語について本明細書中において明示的に記載されるいずれの定義も、請求項において用いられるようなそのような用語の意味を決定するものとする。したがって、請求項において明示的に列挙されていない限定、要素、性質、特徴、利点または属性は、そのような請求項の範囲を如何なる意味でも限定するものではない。明細書および図面はしたがって、限定的ではなく例示的に認識されるべきである。
【図面の簡単な説明】
【００９５】
【図１】この発明の実施例に従った、データベース内で事象が発生したかどうかを確定するためのプロセスを図示するフローチャートである。
【図２】この発明の実施例に従った、時間クエリに対する結果を与えるプロセスのステップを図示するフローチャートである。
【図３】本発明の実施例に従った、具体化されたビューを用いて時間クエリに対する結果を与えるプロセスのステップを図示するフローチャートである。
【図４】本発明の実施例が実現され得るコンピュータシステムを図示するブロック図である。
【図１】
2009529729.tif 000012
【図２】
2009529729.tif 000013
【図３】
2009529729.tif 000014
【図４】
2009529729.tif 000015
【国際調査報告】
2009529729.tif 000016
2009529729.tif 000017
2009529729.tif 000018