JP2009266147A - データベースと仮想テーブルの整合性を維持する方法および装置。 - Google Patents

Abstract

【課題】データベースの仮想テーブルを有するビューを管理する方法を提供する。
【課題手段】該方法は、インスタンスを追加するための空き容量がないと判断した場合、ＬＲＵアルゴリズムにより破棄候補リスト・テーブルから、破棄候補インスタンスを選択するステップと、前記破棄候補インスタンスについて、更新待ちフラグが立っているか判断するステップと、前記更新待ちフラグが立っていると判断した場合、前記破棄候補リスト・テーブルから、前記破棄候補インスタンスを削除するステップと、前記更新待ちフラグが立っていないと判断した場合、前記インスタンス・プールから前記破棄候補インスタンスを削除して、前記インスタンス・プールに前記インスタンスを追加するステップと、前記記憶領域が十分あると判断した場合、前記追加要求のインスタンスを、前記インスタンス・プールに追加するステップとを含む。
【選択図】図５

Description

本発明は、データベースへの検索問い合わせ文の結果によって内容が定義される仮想テーブルのビューと、データベースの整合性の維持に関する。

データベースへの問い合わせ処理を効率良く行うための技術として、仮想テーブルのビュー（例えば、マテリアライズドビュー）を使用する方法がある。ビューは、データベースへの検索問い合わせ文の結果によって内容が定義される仮想テーブルであり、このテーブルを予め生成しておくことにより、アプリケーション・サーバからの同種の問い合わせ文に対して、直接データベースにアクセスして検索処理を行うことを回避できる。

一方、データベースへの更新処理を効率良く行うための方法として、バッチ更新がある。これは、アプリケーション・サーバなどからの複数のデータ更新操作文を蓄えておき、一定間隔、あるいは一定データサイズごとに1つにまとめてデータベースに送信し、処理させる方法である。一般に、データを送信、あるいはディスクに書き込む際には、一定のデータサイズや処理インターバルを守ることによって処理効率が最適化される。したがって、バッチ更新によって一定のデータサイズや処理インターバルが守られると、アプリケーション・サーバとデータベースとの間の通信が最適化され、システムのパフォーマンスが大きく向上する。

しかしながら、アプリケーション・サーバからデータベースに対して、最新のデータセットを対象とした検索問い合わせ要求がある場合には、その検索要求に正確に応答するために、データベースに対する更新要求数や処理インターバルが十分な量に達していない場合であっても、その時点でバッチ更新を実行（強制フラッシュ）しなければならず、バッチ更新の性能が十分に引き出せない場合がある。

この問題を解決するための一つの方法として、ビューをアプリケーション・サーバ上に保持し、更新要求ごとにビューのメンテナンスを行うことで、ビューを最新に保ち、検索問い合わせ要求をデータベースに送らずに処理が遂行できるようにすることが考えられる。しかし、この方法ではバッチ更新されるレコードに関連するすべての検索結果がアプリケーション・サーバ上に存在しなければならず、したがって、そのデータ量が記憶容量よりも大きい場合にはこの方法を用いることができなかった。

特許文献１では、データ更新要求があった場合、サーバキャッシュを検索し、データバースト・サーバキャッシュをその都度更新しているので、データベースに対する更新処理要求が頻繁に発生してしまう。

ハードウェアで実現される中央処理装置（ＣＰＵ）のキャッシュ機構は、メモリアクセスに対するキャッシュであり、ビューと類似するアドレス解決のためのディレクトリはあるものの、複雑な検索結果をキャッシュすることはなく、まして、二重に処理を行うメンテナンスのような機構を持つことはない。さらに、ライトバック機構を備える場合でも、キャッシュ上の最終結果だけを書き込むため、インスタンス・プールとは別に、更新処理命令を生成するために、これまでの更新をバッチログとして保持する必要もない。従って、ＣＰＵの構成から、これらのアプリケーション・サーバ特有の問題の解を得ることはできない。

特開２００４−２８０４９４号公報

データベースの仮想テーブルを有するビューを管理する方法および装置を提供する。

上記課題を解決するため、本発明においては、データベースの仮想テーブルを有するビューを管理する装置で実行される方法を提案する。該方法は、前記ビューのインスタンス・プールにレコード・データのインスタンスを追加する要求を受信するステップと、前記インスタンス・プールの記憶領域に、前記インスタンスを追加するための空き容量があるか判断するステップと、前記空き容量があるか判断するステップで、前記インスタンスを追加するための空き容量がないと判断した場合、ＬＲＵ（Least Recently Used）アルゴリズムにより破棄候補リスト・テーブルから、破棄候補インスタンスを選択するステップと、前記破棄候補インスタンスについて、破棄候補リスト・テーブルに、更新待ちフラグが立っているか判断するステップと、前記更新待ちフラグが立っているか判断するステップで、前記更新待ちフラグが立っていると判断した場合、前記破棄候補リスト・テーブルから、前記破棄候補インスタンスを削除するステップと、前記更新待ちフラグが立っているか判断するステップで、前記更新待ちフラグが立っていないと判断した場合、前記インスタンス・プールから前記破棄候補インスタンスを削除して、前記インスタンス・プールに前記インスタンスを追加するステップと、前記空き容量があるか判断するステップで、前記記憶領域が十分あると判断した場合、前記追加要求のインスタンスを、前記インスタンス・プールに追加するステップとを含む。

本発明の方法により、検索結果のデータ量に対してメモリが十分でない場合でも、最新のデータセットや最も最近アクセスされたデータセットを優先してビューに保持することで、最新のデータセットを対象とした検索問い合わせ要求がきても、データベースに対してバッチ更新をその時点で行うことなく、検索問い合わせに応答することを可能にする。

以上、本発明の概要を、方法として説明したが、本発明は、装置、プログラム、またはプログラム製品として把握することもできる。プログラム製品は、例えば、前述のプログラムを格納した記憶媒体を含め、あるいはプログラムを伝送する媒体を含めることができる。

上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの構成要素のコンビネーションまたはサブコンビネーションもまた、発明となり得ることに留意すべきである。

図１は、本発明の、アプリケーション・サーバの検索問合せに対する検索結果によって内容が定義されるビューの仮想テーブルを有するシステム１００の高水準の概要図である。ビューの仮想テーブルのレコード・データは、データベースのデータを基に作成される。ＤＢサーバ１２１、１２２はデータベースを有する。ここでは、ＤＢサーバは複数存在するが、１台のみでも良い。ＤＢサーバは、ネットワーク１０１を介して、アプリケーション・サーバ１１０と接続する。通常、アプリケーション・サーバ１１０がビュー・プールおよびインスタンス・プールを含む仮想テーブルを有するキャッシュを持つ形態が、最も処理効率が高くなるが、他のサーバがこのキャッシュを有する形態であっても良い。

アプリケーション・サーバ１１０は、データベース（ＤＢサーバ）に対し検索要求を出す。実際には、まず、検索キーで、対応する検索結果が無いかビュー・プールからインスタンスＩＤを検索し、対応するインスタンスＩＤがあれば、インスタンス・プールから対応するインスタンスＩＤのレコード・データを応答として返し、対応するインスタンスＩＤが無ければ、ＤＢサーバを直接検索することになる。ＤＢサーバの検索結果は、ビュー・プールおよびインスタンス・プールに蓄積される。また、アプリケーション・サーバ１１０から更新処理があった場合、ビュー・プールおよびインスタンス・プールを更新し、データベース（ＤＢサーバ）への書き込み命令をバッチ処理として蓄積し、所定のルールに従ってデータベースにバッチ処理を実行する。

図２は、本発明の構成および処理を、高水準で概念的に示したものである。アプリケーション・プログラム２０１、ビュー・プール２１１、インスタンス・プール２２１およびバッチ処理機構２３１は、アプリケーション・サーバにあるほうが好ましいが、他のサーバに分散していても良い。また、データベース２５０はＤＢサーバであるが、このデータベースも、同一のサーバ上にあっても良いし、分散されたサーバ環境に配置しても良い。ここでは、アプリケーション・サーバ上に検索結果を保持し、検索キーおよびインスタンスＩＤを有するビュー・プール２１１と、検索結果によって参照されるレコードの実態を保持するインスタンス・プール２２１を有する。

アプリケーション・プログラム２０１は、更新要求および検索要求をデータベース２５０に送るが、実際には、ビュー・プール２１１およびインスタンス・プール２２１に送ることになる。ビュー・プール２１１は、検索キーを含むインデックス２１５を持つビュー２１３を含む。インデックス２１５はインスタンスＩＤも含む。インスタンス・プール更新部２１７は、必要に応じてインスタンス・プール２２１にインスタンスを追加削除する。インスタンス・プール２２１は、インスタンス２２３とロック・マネージャ２２５を有する。インスタンス２２３は、データベースのレコードの一部であるデータの他に、ロック状態フラグおよび更新待ちフラグを有しても良い。バッチ処理機構２３１は、更新要求をバッチログ２３３として保持し、所定のルールに従いデータベース２５０にバッチ更新処理を行なう。

図３は、ビュー・プールとインスタンス・プールの検索時の処理フローを例示したものである。ステップ３０１でアプリケーション・プログラムから検索要求が発せられ、フローがスタートする。ステップ３０３で、検索問い合わせ要求に対応する検索結果がビュー・プールの中に含まれているか確認する。ステップ３０５で、ビューに検索結果の実体を指すＩＤのリストが存在するか判断する。ステップ３０５で、検索キーに対応するＩＤが存在しないと判断した場合（Ｎｏ）、ステップ３３１に進み、nullを返す。一方、ステップ３０５で、検索キーに対応するＩＤが存在すると判断した場合（Ｙｅｓ）、ステップ３０７に進む。ステップ３０７で、ビュー・プールから対応する検索結果のＩＤリストを取得する。次に、各ＩＤについて、ステップ３０９から３１９を繰り返す。

ステップ３１１で、該当するキーがインスタンス・プールにあるか判断する。ステップ３１３で、該当するＩＤをキーにインスタンス・プール中のインスタンス・テーブルからインスタンスを取得する。ステップ３１５で、アプリケーション・プログラムに返送するための検索結果リストに、取得したインスタンスのＩＤを追加する。一方、ステップ３１１で該当するキーのインスタンスがインスタンス・プールにないと判断した場合、ＩＤをキーにデータベースからインスタンスを取得する。その後、ステップ３１５に進み、検索結果リストに、取得したインスタンスのＩＤを追加する。ステップ３１９で、各ＩＤについて、インスタンスの取得が終了していない場合は、ステップ３０９に進む。各ＩＤについて、インスタンスの取得が終了している場合は、ステップ３２１に進む。ステップ３２１で、インスタンスが入った結果リストをアプリケーション・サーバに返す。ステップ３４１でこのフローの処理を終了する。

図４は、検索問合せの際の動作を概念的に示した図である。アプリケーション・プログラムから、検索問合せ文４０３がアプリケーション・サーバ４０５に発せられる。ここで、問い合わせ文の条件部分（検索キー）は、WHERE句の（ｓ１、２）となる。このキー（ｓ１、２）でビュー・プール４０７内の各ビュー４０９に含まれるキー４１１を検索する。ここで、キー（ｓ１、２）に対応する検索結果であるインスタンスＩＤ４１３は、（１００、１０７、２１１）となる。このＩＤで、まず、インスタンス・プール４２１内のインスタンス４２３を検索する。該当するインスタンスが、インスタンス・プールに存在すれば、インスタンスのレコード・データの実体を取得し、検索結果としてアプリケーション・プログラムに返す。該当するインスタンスが、インスタンス・プール４２１に無い場合は、直接データベース４３１のインスタンスを検索し、データの実体を取得し、検索結果としてアプリケーション・プログラムに返す。

図５は、ビュー・プールとインスタンス・プールの、インスタンス追加の処理フローを例示したものである。ステップ５０１で処理を開始する。ステップ５０１では、インスタンスの追加要求を受取った場合がトリガーになる。例えば、インスタンス・プールに存在しないインスタンスをデータベースから検索してきた場合などが、このトリガーにあたる。ステップ５０３で、インスタンスを追加するのに使用可能な領域があるか調べる。ステップ５０５で、インスタンスを追加するための記憶領域が十分か判断する。ステップ５０５で記憶領域が十分であると判断した場合（Ｙｅｓ）、ステップ５２１に進む。ステップ５２１で、インスタンスを作成し、インスタンス・プールに追加する。そして、ステップ５３１でこの処理フローを終了する。なお、他のインスタンス追加要求が残っていれば、ステップ５０１から処理を繰り返す。一方、ステップ５０５で記憶領域が十分ではないと判断した場合（Ｎｏ）、ステップ５０７に進み、ＬＲＵ（Least Recently Used）アルゴリズムにより、インスタンスの破棄候補リストから、破棄の対象となるインスタンスを選択する。これは、最も使われていないインスタンスを破棄するためである。

ステップ５０９で、破棄候補のインスタンスがロックされているか判断する。ステップ５０９で破棄候補のインスタンスがロックされていると判断した場合（Ｙｅｓ）、ステップ５１３で破棄候補リストから、破棄候補のインスタンスを削除し、ステップ５０７に戻る。インスタンスがロックされているということは、そのインスタンスが他からアクセスがあるということを意味する。一方、ステップ５０９で破棄候補のインスタンスがロックされていないと判断した場合（Ｎｏ）、ステップ５１１に進む。

ステップ５１１で、破棄候補のインスタンスの更新待ちフラグが立っているか判断する。ステップ５１１で、更新待ちフラグが立っていると判断した場合、ステップ５４１に進み、バッチ処理機構の更新要求数（バッチログ）が所定の数を超えているか判断する。ステップ５４１で、所定の数を超えていると判断した場合（Ｙｅｓ）、ステップ５４３に進み、キー毎にバッチログを集めて整理し最新（最終）のデータ値をバッチ更新文にセットする（詳細は後述する）。ステップ５４５で、バッチ処理機構は、バッチ更新文で実際にデータベースを更新する。ステップ５１３に進み、破棄候補リストから当該インスタンスを削除する。ステップ５４１で、所定の数を超えていないと判断した場合（Ｎｏ）、ステップ５１３に進み、破棄候補リストから当該インスタンスを削除する。なお、ステップ５４１からステップ５４５は、更新待ちフラグが立っているインスタンスが多くある場合もあるので、バッチ処理によりデータベースに更新内容を反映するために実行されるが、ここで、必ずしもこれらのステップを実行する必要は無い。また、ステップ５１３で、破棄候補リストから当該インスタンスを削除するのは、更新待ちフラグが立っているインスタンスはデータベースに更新内容が反映されていないので、インスタンス・プールの内容が最新となり、従って、インスタンス・プールからの削除を防ぐ必要があるからである。

ステップ５１１で、更新待ちフラグが立っていないと判断した場合、ステップ５１５に進み、破棄候補のインスタンスをインスタンス・プールから削除する。再び、インスタンスを追加するために、ステップ５０５に戻り、記憶領域が十分であると判断した場合（Ｙｅｓ）、ステップ５２１、インスタンスを作成し、インスタンス・プールに追加する。一方、ステップ５０５で記憶領域が十分ではないと判断した場合（Ｎｏ）、ステップ５０７からステップ５１５までの処理を繰り返すことになる。なお、図５のフローは、アプリケーション・サーバからの検索文および更新文で、該当するインスタンスがインスタンス・プールに無い場合に実行される。

図６は、ビュー・プールの更新要求の処理を概念的に示した図である。アプリケーション・プログラムから、更新文６０３がアプリケーション・サーバ６０５に発せられる。ここで、キーは、更新文の条件部分、すなわち、WHERE句の（ｓ１、２）となる。このキー（ｓ１、２）でビュー・プール６０７内の各ビュー６０９に含まれるキー６１１を検索する。ここで、キー（ｓ１、２）に対応する結果ＩＤ６１３は、（１００、１０７、２１１）となる。このＩＤをキーに、インスタンス・プール６２１内のインスタンスを検索し、またデータベース６３１内のインスタンスを検索してＶａｌｕｅ＝３に更新する。なお、インスタンス・プールのインスタンスを更新する際は、競合を防ぐため、インスタンスに対してロックを取得する。ロックの取得にはロック・マネージャのキュー（図示せず）に入ることになる。

更新後のデータをインスタンス・プール６２３のインスタンスに書き込む。この更新要求をバッチ処理機構６２５に渡し、更新要求はバッチ更新テーブル（バッチログ）６２７に追加される。インスタンスの更新待ちフラグを立てられる。トランザクションが終了したら、ロックは解除される。そして、このバッチ更新要求は任意のタイミング（例えば定期的に、または更新要求が一定量溜まった後）で、データベース６３１に反映される。

図７は、インスタンスの更新をデータベースに反映させるためのバッチ更新方法を例示的に説明したものである。例として、データベースのテーブルＴ１（７０１）に対しての更新処理を示す。インスタンスに対する蓄積された更新文の例として７０３を示す。７０５はバッチログである。バッチログは、レコード（ｋｅｙ）毎に整理され、最終（最新）の値がセットされ、データベースを実際に更新するためのバッチ更新文（７０７）が作成される。たとえば、ｋｅｙ＝Ａでは、ｖａｌｕｅ＝５に更新された後、さらにｖａｌｕｅ＝１０に更新されている。この場合、予めパターンごとに用意されている７０７のバッチ更新文では、（ｋｅｙ、ｖａｌｕｅ）＝（１０、Ａ）で値をセットし、データベースを更新する。

図８は、本システムの機能構成図を、整理して例示的に示したものである。本システムは、アプリケーション・プログラム８０１、ビュー・プール８０３、ビュー８０５、インスタンス・プール８０７、ロック・マネージャ８０９、インスタンス８１１、インスタンス・プール更新部８１５、バッチ処理機構８２１、バッチログ８２１、データベース８２５を含む。インスタンス・プール更新部８１５は、図５のフローを中心的に実行するものである。その他については、既に説明したので、詳細な説明は省略する。これらの構成ブロックは、各機能を融合、またはより細分化することで、これらの機能ブロック以外でも表現できることは当業者には自明である。

図９は、破棄候補リストのテーブル９００を例示的に示したものである。９０１は破棄候補のインスタンスＩＤを示す。９０２は、インスタンスへの最終アクセス時刻を示す。ＬＲＵアルゴリズムでは、この時刻の一番小さい値を持つインスタンスＩＤから順番に選択することになる。９０３は更新待ちフラグである。このフラグが１の場合、データベースにインスタンスの更新内容が反映されていないことを意味する。破棄候補リスト・テーブル９００の各カラムは、１つのテーブルに含まれるように表現しているが、実際には一つのテーブルにある必要はない。たとえば、更新待ちフラグはインスタンス・プールのインスタンスが持つようにしても良い。

以上の説明により、本発明の実施の形態によるシステムを実現するのに好適な情報処理装置は、通常のパーソナルコンピュータ、ワークステーション、メインフレームなどの情報処理装置、または、これらの組み合わせによって実現されることが容易に理解されるであろう。ただし、これらの構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。

本発明の実施の形態において使用される情報処理装置の各ハードウェア構成要素を、複数のマシンを組み合わせ、それらに機能を配分し実施する等の種々の変更は当業者によって容易に想定され得ることは勿論である。それらの変更は、当然に本発明の思想に包含される概念である。

本発明の実施形態によるシステムは、マイクロソフト・コーポレーションが提供するＷｉｎｄｏｗｓ（登録商標）オペレーティング・システム、アップル・コンピュータ・インコーポレイテッド提供するＭａｃＯＳ（Ｒ）、Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍを備えるＵＮＩＸ（登録商標）系システム（例えば、インターナショナル・ビジネス・マシーンズ・コーポレーションが提供するＡＩＸ（Ｒ）など）のような、ＧＵＩ（グラフィカル・ユーザー・インターフェース）マルチウインドウ環境をサポートするオペレーティング・システムを採用することができる。

以上から、本発明の実施の形態において使用されるシステムは、特定のオペレーティング・システム環境に限定されるものではないことを理解することができる。

また、本発明は、ハードウェア、ソフトウェア、またはハードウェア及びソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアの組み合わせによる実行において、所定のプログラムを有するデータ処理システムにおける実行が典型的な例として挙げられる。かかる場合、該所定プログラムが該データ処理システムにロードされ実行されることにより、該プログラムは、データ処理システムを制御し、本発明にかかる処理を実行させる。このプログラムは、任意の言語・コード・表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接、または１．他の言語・コード・表記への変換、２．他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行することを可能にするものである。

もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記憶した媒体もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハードディスク装置、ＲＯＭ、ＭＲＡＭ、ＲＡＭ等の任意のコンピュータ読み取り可能な記憶媒体に格納することができる。かかるプログラムは、記憶媒体への格納のために、通信回線で接続する他のデータ処理システムからダウンロードしたり、他の記憶媒体から複製したりすることができる。また、かかるプログラムは、圧縮し、または複数に分割して、単一または複数の記憶媒体に格納することもできる。また、様々な形態で、本発明を実施するプログラム製品を提供することも勿論可能であることにも留意されたい。

以上、本発明の実施形態によれば、検索結果のデータ量に対してメモリが十分でない場合でも、最新のデータセットや最も直近にアクセスされたデータセットを優先してビューに保持することで、最新のデータセットを対象とした検索問い合わせ要求がきても、データベースに対してバッチ更新をその時点で行うことなく、検索問い合わせに応答できることが理解される。

上記の実施の形態に、種々の変更または改良を加えることが可能であることが当業者に明らかである。そのような変更または改良を加えた形態も当然に本発明の技術的範囲に含まれることに留意されたい。

本発明の、アプリケーション・サーバの検索問合せに対する検索結果によって内容が定義されるビューの仮想テーブルを有するシステム１００の高水準の概要図である。 本発明の構成および処理を、高水準で概念的に示したものである。 ビュー・プールとインスタンス・プールの検索時の処理フローを例示したものである。 検索問合せの際の動作を概念的に示した図である。 ビュー・プールとインスタンス・プールの、インスタンス追加の処理フローを例示したものである。 ビュー・プールの更新要求の処理を概念的に示した図である。 インスタンスの更新をデータベースに反映させるためのバッチ更新方法を例示的に説明したものである。 本システムの機能構成図を、整理して例示的に示したものである。 破棄候補リストのテーブル９００を例示的に示したものである。

Claims (13)

1. データベースの仮想テーブルを有するビューを管理する装置で実行される方法であって、
   前記ビューのインスタンス・プールにレコード・データのインスタンスを追加する要求を受信するステップと、
   前記インスタンス・プールの記憶領域に、前記インスタンスを追加するための空き容量があるか判断するステップと、
   前記空き容量があるか判断するステップで、前記インスタンスを追加するための空き容量がないと判断した場合、ＬＲＵ（Least Recently Used）アルゴリズムにより破棄候補リスト・テーブルから、破棄候補インスタンスを選択するステップと、
   前記破棄候補インスタンスについて、更新待ちフラグが立っているか判断するステップと、
   前記更新待ちフラグが立っているか判断するステップで、前記更新待ちフラグが立っていると判断した場合、前記破棄候補リスト・テーブルから、前記破棄候補インスタンスを削除するステップと、
   前記更新待ちフラグが立っているか判断するステップで、前記更新待ちフラグが立っていないと判断した場合、前記インスタンス・プールから前記破棄候補インスタンスを削除して、前記インスタンス・プールに前記インスタンスを追加するステップと、
   前記空き容量があるか判断するステップで、前記記憶領域が十分あると判断した場合、前記追加要求されたインスタンスを、前記インスタンス・プールに追加するステップと
   を含む方法。
2. 前記方法はさらに、
   前記破棄候補インスタンスが、ロックされているか判断するステップと、
   前記ロックされているか判断するステップで、前記破棄候補インスタンスがロックされていると判断した場合、前記破棄候補リストから、前記破棄候補インスタンスを削除するステップと
   を含む請求項１に記載の方法。
3. 前記方法はさらに、
   前記更新待ちフラグが立っているか判断するステップで、前記破棄候補インスタンスに更新待ちフラグが立っていると判断した場合、データベースに更新を反映するバッチ処理の更新要求数が所定の数を越えているか判断するステップと
   前記所定の数を越えているか判断するステップで、所定の数を超えていると判断した場合、
   バッチの更新要求を整理してバッチ更新文にセットするステップと、
   バッチ更新文でデータベースを更新するステップと
   を含む請求項１に記載の方法。
4. 前記インスタンス・プールのインスタンスは、更新待ちフラグとロック状態フラグを持つことを特徴とする請求項１に記載の方法。
5. 前記インスタンスの検索時に、インスタンス・プールに前記インスタンスが存在しない場合に、実行される方法である請求項１に記載の方法。
6. 前記方法はさらに、
   前記ビューの検索キーを含むビュー・プールから前記インスタンスのＩＤを取得するステップと
   前記ＩＤに対応する前記インスタンスのレコードを、前記インスタンス・プールから検索するステップを含む請求項１に記載の方法。
7. 請求項１乃至６のいずれか１項に記載の方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラム。
8. データベースにおいて、仮想テーブルを有するビューを管理するシステムであって、
   検索キーを含むビュー・プールと、
   データベースの少なくとも一部のレコード・データのインスタンスを含むインスタンス・プールと、
   前記インスタンス・プールに保持するレコードの更新を前記データベースに反映するためのバッチ処理部と、
   インスタンス・プールを更新する更新部と
   を有するシステムであって、
   前記更新部は、
   前記ビューのインスタンス・プールにレコード・データのインスタンスを追加する要求を受信する手段と、
   前記インスタンス・プールの記憶領域に、前記インスタンスを追加するための空き容量があるか判断する手段と、 前記空き容量があるか判断する手段で、前記インスタンスを追加するための空き容量がないと判断した場合、ＬＲＵ（Least Recently Used）アルゴリズムにより破棄候補リスト・テーブルから、破棄候補インスタンスを選択する手段と、
   前記破棄候補インスタンスについて、更新待ちフラグが立っているか判断する手段と、
   前記更新待ちフラグが立っているか判断する手段で、前記更新待ちフラグが立っていると判断した場合、前記破棄候補リスト・テーブルから、前記破棄候補インスタンスを削除する手段と、
   前記更新待ちフラグが立っているか判断する手段で、前記更新待ちフラグが立っていないと判断した場合、前記インスタンス・プールから前記破棄候補インスタンスを削除して、前記インスタンス・プールに前記インスタンスを追加する手段と、
   前記空き容量があるか判断する手段で、前記記憶領域が十分あると判断した場合、前記追加要求されたインスタンスを、前記インスタンス・プールに追加する手段と
   を含む更新部と
   を含むシステム。
9. 前記更新部はさらに、
   前記破棄候補インスタンスが、ロックされているか判断する手段と、
   前記ロックされているか判断する手段で、前記破棄候補インスタンスがロックされていると判断した場合、前記破棄候補リストから、前記破棄候補インスタンスを削除する手段と
   を含む請求項８に記載のシステム。
10. 前記更新部はさらに、
    前記更新待ちフラグが立っているか判断する手段で、前記破棄候補インスタンスに更新待ちフラグが立っていると判断した場合、データベースに更新を反映するバッチ処理の更新要求数が所定の数を越えているか判断する手段と、
    前記所定の数を越えているか判断する手段で、所定の数を超えていると判断した場合、前記バッチ処理部が
    バッチの更新要求を整理してバッチ更新文にセットし、
    バッチ更新文でデータベースを更新する
    請求項８に記載のシステム。
11. 前記インスタンス・プールのインスタンスは、更新待ちフラグとロック状態フラグを持つことを特徴とする請求項８に記載の方法。
12. 前記インスタンスの検索時に、インスタンス・プールに前記インスタンスが存在しない場合に、前記更新部が実行される請求項８に記載のシステム。
13. 前記システムはさらに、
    前記ビュー・プールから前記インスタンスのＩＤを取得する手段と
    前記ＩＤに対応する前記インスタンスのレコードを、前記インスタンス・プールから検索する手段とを含む請求項８に記載のシステム。

Images