JP2015170076A - データベースシステム - Google Patents

Abstract

【課題】キャッシュテーブルを効率的に更新するデータベースシステムを提供することにある。
【解決手段】実施形態によれば、第１テーブルおよび当該第１テーブルを事前に参照要求に適するように変形をした第２テーブルを用いてデータの参照要求に応答するデータベースシステムは、第１テーブルを管理する第１管理手段と、第２テーブルを管理する第２管理手段とを具備する。第１管理手段は、第１テーブルのデータが更新された場合、その更新内容を示す更新通知を第２管理手段に送信する通知手段を具備する。第２管理手段は、更新通知で示される更新内容に該当する第２テーブルのデータを無効化する無効化手段と、データの参照要求に応答するために必要な第２テーブルのデータが無効化されている場合、そのデータを第１テーブルから取得して第２テーブルに格納する更新手段とを具備する。
【選択図】図１６

Description

本発明の実施形態は、データベースシステムに関する。

リレーショナル型データベースは、表形式で管理されるデータ（テーブル）を、ＳＱＬ（Structured query language）を使って操作するデータベースである。リレーショナル型データベースは、ＳＱＬで結合条件を指定することにより、複数のテーブルを動的に関連付けることができる。

複数のテーブルを関連付ける処理（結合：JOIN）は、条件によっては、その負荷が非常に大きくなるため、このような条件に備えて、複数のテーブルを結合したキャッシュテーブルを予め用意しておくといったことも行われている。

特開２００６−３４３７９８号公報

キャッシュテーブルの基となるテーブルが更新された場合の対処法には、同期型と、非同期型とが存在する。同期型では、テーブルの更新時に、キャッシュテーブルを即応的に更新する。一方、非同期型では、一定期間毎に、各期間の更新分を一括して更新する。

しかしながら、同期型は、更新時間の増大を招くおそれがあり、一方、非同期型は、更新前の古いデータが参照されるおそれがある。

本発明が解決しようとする課題は、キャッシュテーブルを効率的に更新するデータベースシステムを提供することにある。

実施形態によれば、データベースシステムは、第１テーブルおよび当該第１テーブルを事前に参照要求に適するように変形をした第２テーブルを用いて、データの参照要求に応答する。データベースシステムは、第１管理手段と、第２管理手段とを具備する。前記第１管理手段は、前記第１テーブルを管理する。前記第２管理手段は、前記第２テーブルを管理する。前記第１管理手段は、通知手段を具備する。前記通知手段は、前記第１テーブルのデータが更新された場合、その更新内容を示す更新通知を前記第２管理手段に送信する。前記第２管理手段は、無効化手段と、更新手段とを具備する。前記無効化手段は、前記更新通知を受信した場合、前記更新通知で示される更新内容に該当する前記第２テーブルのデータを無効化する。前記更新手段は、前記第１テーブルのデータの参照要求を受けた場合であって、そのデータの参照要求に応答するために必要な前記第２テーブルのデータが無効化されている場合、そのデータを前記第１テーブルから取得して前記第２テーブルに格納する。

第１実施形態のデータベースシステムのシステム構成を示す図。 更新用テーブルから参照用テーブルを生成する一例を示す図。 更新用テーブルが更新された場合に同期的に参照用テーブルを更新する一般的な例を示す図。 更新用テーブルが更新された場合に非同期的に参照用テーブルを更新する一般的な例を示す図。 更新用テーブルが更新された場合の参照用テーブルの更新についての一般的な考え方を説明するための図。 第１実施形態のデータベースシステムにおける更新用テーブルが更新された場合の参照用テーブルの更新についての基本的な考え方を説明するための図。 更新用テーブルが局所的に頻繁に更新された場合の一例を示す図。 「更新側主導」における更新用テーブルの更新に伴う参照用テーブルの更新に関する処理の流れを示す図。 「更新側主導」の場合に更新用テーブルの更新時に必要となる計算を説明するための第１の図。 「更新側主導」の場合に更新用テーブルの更新時に必要となる計算を説明するための第２の図。 「参照側主導」における更新用テーブルの更新に伴う参照用テーブルの更新に関する処理の流れを示す図。 更新用テーブルが局所的に更新された場合の参照用テーブルの更新に関する処理の流れを「更新側主導」と「参照側主導」とで比較する図。 第１実施形態のデータベースシステムにおける参照用テーブルの一構成例を示す図。 「更新側主導」における典型的な参照用テーブルの一構成例を示す図。 「更新側主導」おいて図１４の参照用テーブルを更新用テーブルの更新に伴って更新する手順を説明するための図。 第１実施形態のデータベースシステムの参照用テーブルの更新に関する機能ブロック図。 第１実施形態のデータベースシステムで実行される参照用テーブルの生成を要求するクエリの解析を説明するための図。 第１実施形態のデータベースシステムによる参照用テーブルの「参照側主導」での更新手順を説明するための第１の図。 第１実施形態のデータベースシステムによる参照用テーブルの「参照側主導」での更新手順を説明するための第２の図。 第１実施形態のデータベースシステムによる参照用テーブルの「参照側主導」での更新手順を説明するための第３の図。 第１実施形態のデータベースシステムによる参照用テーブルの「参照側主導」での更新手順を説明するための第４の図。 第１実施形態のデータベースシステムによる参照用テーブルの「参照側主導」での更新手順を説明するための第５の図。 第１実施形態のデータベースシステムによる参照用テーブルの「参照側主導」での更新手順を説明するための第６の図。 第１実施形態のデータベースシステムによる参照用テーブルの「参照側主導」での更新手順を説明するための第７の図。 第１実施形態のデータベースシステムによる参照用テーブルの「参照側主導」での更新手順を説明するための第８の図。 第１実施形態のデータベースシステムにおける更新側データベースエンジンの参照用テーブルの生成時の動作手順を示す図。 第１実施形態のデータベースシステムにおける参照側データベースエンジンの参照用テーブルの生成時の動作手順を示す図。 第１実施形態のデータベースシステムにおける更新側データベースエンジンの更新用テーブルの更新時の動作手順を示す図。 第１実施形態のデータベースシステムにおける参照側データベースエンジンの更新用テーブルの更新時および参照要求の受け付け時の動作手順を示す図。 更新用テーブルの更新に伴う参照用テーブルの更新を「更新側主導」で行った場合と「参照側主導」で行った場合との処理量を比較する図。 更新用テーブルの更新に伴う参照用テーブルの更新を「更新側主導」で行った場合と「参照側主導」で行った場合との所要時間を比較する図。 第２実施形態のデータベースシステムにおける参照用テーブルの一構成例を示す図。 第２実施形態のデータベースシステムによる参照用テーブルの「参照側主導」での更新手順を説明するための第１の図。 第２実施形態のデータベースシステムによる参照用テーブルの「参照側主導」での更新手順を説明するための第２の図。 第３実施形態のデータベースシステムにおける参照用テーブルの一構成例を示す図。

以下、実施の形態について図面を参照して説明する。

（第１実施形態）
図１は、本実施形態に係るデータベースシステム１のシステム構成を示す図である。

図１に示すように、本データベースシステム１は、各々がアプリケーションプログラム２からのデータ処理要求を受け付ける１以上のデータベース１０によって構成される。ここでは、２つのデータベース１０を示しているが、単なる例示であって、これに限定されるものではない。つまり、本データベースシステム１は、１つのデータベース１０によっても構成され得るし、３つ以上のデータベース１０によっても構成され得る。

データベース１０は、複数のテーブルを結合させることが可能なリレーショナル型データベースであり、コントローラ１１およびファイルシステム１２を有している。アプリケーションプログラム２は、ＧＵＩ（Graphical user interface）部２１および論理・算術演算部２２を有し、例えば、ＧＵＩ部２１により受け付けたユーザからの指示に応じて、論理・算術演算部２２が、ＳＱＬで記述したデータ処理要求をデータベース１０に発行し、返却されたデータ処理結果をＧＵＩ部２１によりユーザに提示する。アプリケーションプログラム２により発行されるデータ処理要求には、大きく分けて、データの参照要求と、データの更新要求とが存在し、データの更新要求には、データの追加要求および削除要求が含まれる。また、ＳＱＬで記述されるデータ処理要求は、ＳＱＬ文やクエリなどと称される。

データベース１０のコントローラ１１は、アプリケーションプログラム２からのデータ処理要求の受付窓口の役割を担うモジュールである。コントローラ１１は、要求されたデータ処理を実行するデータベースエンジン１００を有している。また、コントローラ１１は、他のデータベース１０のコントローラ１１との間で通信する機能を有している。したがって、アプリケーションプログラム２は、データ処理要求の発行先であるデータベース１０で管理されるテーブルと、このデータベース１０とは異なるデータベース１０で管理されるテーブルとの結合を伴うデータ処理要求を発行することもできる。換言すれば、アプリケーションプログラム２は、本データベースシステム１を構成する１以上のデータベース１０内に存在するテーブルのすべてをデータ処理の対象とすることができる。データベース１０のファイルシステム１２は、データベース１０内に存在する、テーブルのデータを含む各種データの記憶媒体上における配置場所を管理するモジュールである。

本データベースシステム１は、データベース１０の各々が、テーブルを事前に参照要求に適するように変形をしたキャッシュテーブルを予め用意しておき、テーブルおよびキャッシュテーブルを使って、データの参照要求に応答する機能を有している。変形とは、典型的には、２以上のテーブルを結合することである。そして、本データベースシステム１は、キャッシュテーブルの基となるテーブルが更新された場合のキャッシュテーブルの更新を効率的に行う仕組みを実装するものであり、以下、この仕組みについて詳述する。

まず、本データベースシステム１が実装する、キャッシュテーブルを効率的に更新する仕組みの理解を助けるために、図２乃至図４を参照して、キャッシュテーブルの基となるテーブルが更新された場合の一般的な対処法について説明する。

図２は、２つのテーブル（テーブルＡ，Ｂ）を結合してキャッシュテーブルを生成する一例を示している。以下、キャッシュテーブルを参照用テーブル２０１（マテリアライズドビュー：MATERIALIZED VIEW [MVIEW]）、キャッシュテーブルの基となるテーブルを更新用テーブル２０２と称する。

図２中、「CREATE MATERIALIZED VIEW READABLE AS SELECT 名前、場所 FROM A,B WHERE a2=1 and a3=b0 and b2=’今’」は、更新用テーブル２０２から参照用テーブル２０１を生成するためのクエリである。本クエリ中、”WHERE”部に条件文が記述され、条件文は、結合条件と絞り込み条件とを含み得る。”a3=b0”が、結合条件であり、テーブルＡの３つ目のフィールドに格納される値とテーブルＢの行番号とが一致する行を結合する旨を指定するものである。”a2=1”および”b2=’今’”は、絞り込み条件であり、テーブルＡの２つ目のフィールドに格納される値が「１」、テーブルＢの２つ目のフィールドに格納される値が「今」の行に絞り込む旨を指定するものである。なお、”SELECT”部には、抽出すべき項目名（フィールド名）が記述され、また、”FROM”部には、対象とすべきファイル名（テーブル名）が記述される。ここでは、テーブルＡの１つ目のフィールドの項目名が「名前」であり、また、テーブルＢの１つ目のフィールドの項目名が「場所」であるものとする。

図２に示す参照用テーブル２０１を予め生成しておくことにより、以降、「SELECT 名前、場所 FROM A,B WHERE a2=1 and a3=b0 and b2=’今’」を含むデータの参照要求であるクエリが発行された場合、テーブルＡとテーブルＢとの結合を行わなくとも、要求されたデータを速やかに返却することが可能となる。

ところで、前述したように、アプリケーションプログラム２により発行されるクエリには、データの参照要求のみならず、データの更新要求も存在する。したがって、参照用テーブル２０１を生成した後に、更新用テーブル２０２が更新されることも考えられる。この場合、その更新内容を参照用テーブル２０１に反映させる必要が生じる。ここで、参照用テーブル２０１の基となる更新用テーブル２０２であるテーブルＡの行番号「２」の行の１つ目のフィールドが「田中」から「里中」に更新された場合を想定する。なお、以下では、行番号を主キー値と称することがある。

図３は、更新用テーブル２０２の更新内容を参照用テーブル２０１に同期的に反映させる場合の例を示している。

図３に示すように、更新用テーブル２０２が更新された場合に、参照用テーブル２０１を即応的に更新すれば、データの参照要求に対して返却されるデータは、常に最新のデータとなる。一方で、参照用テーブル２０１の更新を頻繁に行うことになりかねず、更新時間の増大を招くおそれがある。

また、図４は、更新用テーブル２０２の更新内容を参照用テーブル２０１に非同期的に反映させる場合の例を示している。

更新用テーブル２０２が更新されても、参照用テーブル２０１を即応的に更新するのではなく、図４に示すように、一定期間毎に、各期間の更新分を一括して更新すれば、更新時間は想定範囲内に収めることができる。一方で、データの参照要求に対して返却されるデータが、更新前の古いデータとなるおそれがある。

このような、参照用テーブル２０１の基となる更新用テーブル２０２が更新された場合の一般的な対処法である同期型および非同期型の双方の特長を踏まえた上で、続いて、図５および図６を参照して、本データベースシステム１における更新用テーブル２０２が更新された場合の参照用テーブル２０１の更新についての基本的な考え方を説明する。

まず、図５に、更新用テーブル２０２が更新された場合の参照用テーブル２０１の更新についての一般的な考え方を示す。

前述した、更新用テーブル２０２の更新内容を同期的に参照用テーブル２０１に反映させる対処法（同期型）および更新用テーブル２０２の更新内容を非同期的に参照用テーブル２０１に反映させる対処法（非同期型）のいずれも、更新用テーブル２０２の更新というイベントの発生を契機として、参照用テーブル２０１の更新を実行するという、言うなれば「更新側主導」の考え方である。

次に、図６に、本データベースシステム１における更新用テーブル２０２が更新された場合の参照用テーブル２０１の更新についての基本的な考え方を示す。

本データベースシステム１では、更新用テーブル２０２の更新時、旧データを無効化するだけで、参照用テーブル２０１の更新は実行しない。図６では、旧データを含むデータセットの配置場所を示すポインタの値を「０」に更新している。ここで、「０」は、無効を示す値として定義されているものとする。

そして、本データベースシステム１では、参照用テーブル２０１の参照時、該当データが無効化されていた場合に、新データを更新用テーブル２０２から取得し、参照用テーブル２０１を更新する。このように、本データベースシステム１では、言うなれば「参照側主導」の考え方を採用する。

図７に、参照用テーブル２０１の基となる更新用テーブル２０２が局所的に頻繁に更新された場合の一例を示す。

いま、ある時点（図７のａ１）で参照されたデータの同一箇所が頻繁に更新された場合を考える（図７のａ２〜ａ６）。ここでは、参照時の「３」が、「３」→「８」→「９」→「５」→「９」→「６」と更新されている。この間、このデータが参照されることはなく、その後、このデータが２度参照されたとする（図７のａ７，ａ８）。

このような場合、「更新側主導」では、特に「同期型」においては、更新回数分、このデータに関する参照用テーブル２０１の更新が実行される。「非同期型」においても、各更新が互いに異なる期間内に行われたならば、「同期型」と同様、更新回数分、このデータに関する参照用テーブル２０１の更新が実行される。この間、このデータは参照されていないので、「３」→「８」→「９」→「５」→「９」の更新は無駄となる。

一方、「参照側主導」では、更新後の最初の参照時（図７のａ７）に新データを取得して参照用テーブル２０１を更新するので、上記のような参照用テーブル２０１の無駄な更新の実行を排除できる。また、以降の参照時（図７のａ８）には、参照用テーブル２０１に格納された新データを速やかに参照することができる。

このように、「参照側主導」は、データの参照要求に対して常に最新のデータを返却することを保証しつつ、データの更新に関するオーバヘッドを最小化する。

図８は、「更新側主導」における更新用テーブル２０２の更新に伴う参照用テーブル２０１の更新に関する処理の流れを示す図である。なお、ここでは、データの参照要求に対応するモジュールと、データの更新要求に対応するモジュールとが各々設けられているものとする。データの参照要求に対応するモジュールとは、即ち参照用テーブル２０１の管理を司るモジュールであり、データの更新要求に対応するモジュールとは、即ち更新用テーブル２０２の管理を司るモジュールである。

図８に示すように、「更新側主導」では、更新用テーブル２０２の更新が要求された場合（図８のｂ１）、更新用テーブル２０２の更新に加え、概ねその都度（「同期型」であれば毎回）、新データが参照用テーブル２０１の条件に合うか（参照用テーブル２０１の条件から外れたか）を確認するための計算が行われ（図８のｂ２）、必要であれば、参照用テーブル２０１を更新するためのデータの転送が行われる（図８のｂ３）。この更新データの参照用テーブル２０１への反映（図８のｂ４）も、更新用テーブル２０２の更新を契機として実行される。そして、これらの処理は、参照用テーブル２０１の参照（図８のｂ５）の有無に関係なく実行される。

ここで、まず、図９および図１０を参照して、「更新側主導」の場合に必要となる、更新用テーブル２０２の更新時に新データが参照用テーブル２０１の条件に合うか（参照用テーブル２０１の条件から外れたか）を確認するための計算について説明する。

図９では、テーブルＡの行番号「２」の行の３つめのフィールド（a3）が「１」から「３」に変更された例を示している。このフィールドは、結合条件に関わるフィールドであり、また、結合先のテーブルＢの２つ目のフィールド（b2）が、絞り込み条件に関わるフィールトであるので、新データに基づき改めて結合を行い、結合先のテーブルＢの２つ目のフィールドの値を確認する。その値は「昔」であり、絞り込み条件を満たさない。

この時、更新前の旧データ「１」により結合されるテーブルＢの２つ目のフィールドの値を確認すると、その値は「今」であり、絞り込み条件を満たしている。これにより、参照用テーブル２０１から１つの行を削除する必要があることが分かる。

一方、図１０では、テーブルＡの行番号「３」の行の３つ目のフィールド（a3）が、「３」から「１」に変更された例を示している。このフィールドは、結合条件に関わるフィールドであり、また、結合先のテーブルＢの２つ目のフィールド（b2）が、絞り込み条件に関わるフィールトであるので、新データに基づき改めて結合を行い、結合先のテーブルＢの２つ目のフィールドの値を確認する。その値は「今」であり、絞り込み条件を満たしている。

この時、更新前の旧データ「３」により結合されるテーブルＢの２つ目のフィールドの値を確認すると、その値は「昔」であり、絞り込み条件を満たさない。これにより、参照用テーブル２０１に１つの行を追加する必要があることが分かる。なお、絞り込み条件を満たしている場合には、参照用テーブル２０１側に存在するデータセットを更新する必要があることが分かる。例えば更新前の旧データが「２」であった場合、参照用テーブル２０１側の該当データセット内の「横浜」を「川崎」に更新しなければならない。

このように、「更新側主導」の場合には、更新用テーブル２０２の更新時、負荷の大きい結合を伴う計算が必須となる。

図１１は、「参照側主導」における更新用テーブル２０２の更新に伴う参照用テーブル２０１の更新に関する処理の流れを示す図である。

図１１に示すように、「参照側主導」では、更新用テーブル２０２の更新が要求された場合（図１１のｃ１）、更新用テーブル２０２の更新（図１１のｃ２）と、その更新の通知（図１１のｃ３）とが行われる。また、参照用テーブル２０１については、更新が通知されたデータに関わる行の削除（図１１のｃ４）、つまり無効化のみが行われ、参照用テーブル２０１の更新は実行されない。

また、更新用テーブル２０２の更新（図１１のｃ２）が、同一テーブルの同一レコードに対する２箇所目以降の更新である場合や、そもそも参照用テーブル２０１と関係のないデータを対象とするものである場合、その更新の通知（図１１のｃ３）は行われず、参照用テーブル２０１の該当行の削除（図１１のｃ４）も行われない。

そして、参照用テーブル２０１の参照時（図１１のｃ５）、該当のデータが存在しない場合に限り、そのデータを更新用テーブル２０２から取得して、参照用テーブル２０１を更新する（図１１のｃ６）。

図１２は、更新用テーブル２０２が局所的に更新された場合の参照用テーブル２０１の更新に関する処理の流れを「更新側主導」と「参照側主導」とで比較する図である。

参照用テーブル２０１を更新した後、そのデータが参照されなかった場合、その更新は無駄に終わる。したがって、図１２に示すように、「更新側主導」では、例えば更新用テーブル２０２が局所的に更新された場合、無駄な参照用テーブル２０１の更新が多く発生する。これに対して、「参照側主導」では、参照用テーブル２０１の更新が、参照される必要分に止まる。このことから、「参照側主導」は、バースト処理に対して効果的であるといえる。

次に、本データベースシステム１が、この「参照側主導」を実現する基本原理について説明する。

図１３は、「参照側主導」である本データベースシステム１における参照用テーブル２０１の一構成例を示す図である。

ここで、図１３に示す参照用テーブル２０１の一構成例と比較するために、一旦、図１４および図１５を参照して、「更新側主導」における典型的な参照用テーブル２０１の一構成例および更新用テーブル２０２の更新に伴う当該参照用テーブル２０１の更新手順を説明する。

図１４に示すように、「更新側主導」の場合、参照用テーブル２０１は、通常、結合した各テーブルの行番号（主キー値）の組み合わせである行番号（rowid）と、データセットの配置場所を示すポインタ（ptr）とを備える。

いま、更新用テーブル２０２のデータであって、参照用テーブル２０１側にキャッシュされているデータが「田中」から「里中」に更新されたものとする。

この場合、図１５に示すように、更新されたデータを含む行について結合を実行し、参照用テーブル２０１における行番号を計算して、参照用テーブル２０１用の更新データとして転送する。そして、この更新データに付される行番号に基づき、参照用テーブル２０１を更新する。

再び、図１３を参照する。

この参照用テーブル２０１について、「参照側主導」である本データベースシステム１では、行番号（rowid）とは別に、主キー値を格納するキーフィールドをテーブル（更新用テーブル２０２）毎に持つ（rA,rB）。そして、本データベースシステム１では、第１に、キャッシュが有効か否かのフラグを行毎に持つ（cache）。第２に、主キー値による行番号のダイレクトサーチを可能とするためのインデックスをテーブル（更新用テーブル２０２）毎に持つ（index_rA,index_rB）。第３に、絞り込み条件としての主キー値の指定が有効な状態か否かのフラグをテーブル（更新用テーブル２０２）毎に持つ。

以下、図１３に示したように参照用テーブル２０１を構成することで、本データベースシステム１が、当該参照用テーブル２０１を「参照側主導」でどのように更新するのかについて説明する。

図１６は、本データベースシステム１の参照用テーブル２０１の更新に関する機能ブロック図である。

本データベースシステム１における参照用テーブル２０１および更新用テーブル２０２の管理は、データベースエンジン１００が司る。図１６中、（Ａ）は、データの参照要求に対応するモジュール、つまり参照用テーブル２０１の管理を司るモジュールとして動作するデータベースエンジン１００の機能ブロックを示し、（Ｂ）は、データの更新要求に対応するモジュール、つまり更新用テーブル２０２の管理を司るモジュールとして動作するデータベースエンジン１００の機能ブロックを示している。１つのデータベースエンジン１００を、データの参照要求に対応するモジュールおよびデータの更新要求に対応するモジュールの双方として動作させてもよいし、２つのデータベースエンジン１００を、一方をデータの参照要求に対応するモジュールとして、他方をデータの更新要求に対応するモジュールとして動作させてもよい。以下、データの参照要求に対応するモジュールとして動作するデータベースエンジン１００を参照側データベースエンジン１００と称し、データの更新要求に対応するモジュールとして動作するデータベースエンジン１００を更新側データベースエンジン１００と称する。

図１６（Ａ）に示すように、参照側データベースエンジン１００は、ＳＱＬ文解析部１１１、データ制御部１１２、データ変更部１１３、データ要求部１１４およびメモリ１１５を有している。

ＳＱＬ文解析部１１１は、ＳＱＬで記載されるデータの参照要求、つまりクエリを解析するモジュールである。ＳＱＬ文解析部１１１は、その参照要求が参照用テーブル２０１を適用可能なものであるか否かを判定する。参照用テーブル２０１を適用可能なデータの参照要求は、参照用テーブル２０１からデータが取得されて返却され、参照用テーブル２０１を適用不可なデータの参照要求は、更新用テーブル２０２からデータが取得されて返却されることとなる。

データ制御部１１２は、参照が要求されたデータを返却するモジュールであり、当該参照が要求されたデータが参照用テーブル２０１に存在するか否か（参照用テーブル２０１のデータは有効か否か）を判定する機能を有している。データ変更部１１３は、更新側データベースエンジン１００から更新用テーブル２０２の更新通知を受け取った場合に、参照用テーブル２０１の該当データを無効化する等の参照用テーブル２０１の更新を実行するモジュールである。また、データ変更部１１３は、更新通知として送られてくるスキーマに基づき、参照用テーブル２０１を作成する機能を有している。

データ要求部１１４は、データ制御部１１２により、参照が要求されたデータが参照用テーブル２０１に存在しないと判定された場合、該当データを更新用テーブル２０２から取得して、参照用テーブル２０１に格納するモジュールである。メモリ１１５は、参照用テーブル２０１を格納する記憶領域である。

また、更新側データベースエンジン１００は、図１６（Ｂ）に示すように、ＳＱＬ文解析部１２１、データ制御部１２２、更新通知部１２３およびメモリ１２４を有している。

ＳＱＬ文解析部１２１も、参照側データベースエンジン１００のＳＱＬ文解析部１１１と同様、クエリを解析するモジュールである。データの更新要求の中には、キャッシュテーブルの生成要求、つまり参照用テーブル２０１の生成要求も含まれ、ＳＱＬ文解析部１２１は、クエリが参照用テーブル２０１の生成を要求するものか否かを判定する機能を有している。また、ＳＱＬ文解析部１２１は、参照用テーブル２０１の生成を要求するクエリから、絞り込み条件と結合条件とを含む条件文を抽出する機能を有している。この条件文の抽出は、更新用テーブル２０２の更新に伴う参照用テーブル２０１の更新を「参照側主導」で行うための事前準備として行うものであり、この点については後述する。

データ制御部１２２は、更新が要求された更新用テーブル２０２のデータを更新するモジュールである。この更新時、データ制御部１２２は、データを更新した行の行番号を示す更新行情報２１０をメモリ１２４に格納する。データ制御部１２２は、参照用テーブル２０１の生成が要求された際、当該参照用テーブル２０１のスキーマを作成する。

更新通知部１２３は、データ制御部１２２により作成されたスキーマと、メモリ１２４に格納された更新行情報２１０とを、更新通知として参照側データベースエンジン１００に送信するモジュールである。メモリ１２４は、更新行情報２１０を格納する記憶領域である。

ここで、図１７を参照して、更新側データベースエンジン１００のＳＱＬ文解析部１２１による参照用テーブル２０１の生成を要求するクエリの解析について説明する。

いま、「CREATE MATERIALIZED VIEW READABLE AS SELECT 名前、場所 FROM A,B WHERE a2=1 and a3=b0 and b2=’今’」といったクエリが発行されたものと想定する。ＳＱＬ文解析部１２１は、このクエリから、条件文、つまり「WHERE a2=1 and a3=b0 and b2=’今’」のみを抽出する。また、ＳＱＬ文解析部１２１は、抽出した条件文に含まれる結合条件（a3=b0）で指定される各テーブルのキー（a3,b0）と、結合対象の各テーブルの主キー（a0,b0）とを、結合に関わるキーとして取得する。

次に、図１８乃至図２６を参照して、事前準備として取得したキーを使った参照用テーブル２０１の「参照側主導」での更新手順について説明する。このうち、図１８乃至図２２は、更新用テーブル２０２の更新時に関する図であり、図２３乃至図２６は、参照用テーブル２０１の参照時に関する図である。

図１８は、事前準備として取得したキー以外の変更となる更新用テーブル２０２の更新の一例を示している。

図１８に示すように、ここでは、テーブルＡの行番号（a0）「２」の行の１つ目のフィールド（a1）が、「田中」から「里中」に更新されている。”a1”は、事前準備として取得したキー以外、つまり結合に関わるキーではないので、更新側データベースエンジン１００の更新通知部１２３は、この行のデータを含むデータセットを無効とするための更新通知（Ｃｌｅａｒ）を参照側データベースエンジン１００に送信する。この更新通知には、テーブルＡの行番号「２」を示す情報（Ａ２）が含まれる。

一方、参照側データベースエンジン１００は、この更新通知を受けると、データ変更部１１３が、テーブルＡ用のインデックスで参照用テーブル２０１の行番号を取得し、その行のフラグ（cache）を無効に更新する。ここで、各フラグは、「１」が有効、「０」が無効を示すものとする。

事前準備として取得したキー以外の変更となる更新用テーブル２０２の更新時には、以上の処理を行うのみで終了する。

図１９は、事前準備として取得したキーの変更となる更新用テーブル２０２の更新であって、更新された行の主キー値がそのテーブル用のインデックスに存在する場合の一例を示している。インデックスに存在する場合とは、その行のデータを含むデータセットが参照用テーブル２０１側に存在する場合または過去に存在した場合である。

図１９に示すように、ここでは、テーブルＡの行番号（a0）「２」の行の３つ目のフィールド（a3）が、何らかの値から「３」に更新されている。”a3”は、事前準備として取得したキー、つまり結合に関わるキーであるので、更新側データベースエンジン１００の更新通知部１２３は、この行との結合を無効とするための更新通知（Ｋｅｙ）を参照側データベースエンジン１００に送信する。この更新通知には、テーブルＡの行番号「２」を示す情報（Ａ２）が含まれる。

一方、参照側データベースエンジン１００は、この更新通知を受けると、データ変更部１１３が、テーブルＡ用のインデックスで参照用テーブル２０１の行番号を取得し、その行のテーブルＡ以外のすべてのキーフィールド（rB）、フラグ（cache）およびポインタ（ptr）を無効に更新する。また、データ変更部１１３は、キーフィールドを無効に更新した場合、そのキーフィールドに対応する、絞り込み条件としての主キー値の指定が有効な状態か否かのフラグを無効に更新する。

また、図２０は、事前準備として取得したキーの変更となる更新用テーブル２０２の更新であって、更新された行の主キー値がそのテーブル用のインデックスに存在しない場合の一例を示している。インデックスに存在しない場合とは、更新前のデータによる結合では絞り込み条件を満たさず、その行のデータを含むデータセットが参照用テーブル２０１側において作成されなかった場合、または、その主キー値を格納していたキーフィールドすべてが無効に更新された場合である。

図２０に示すように、ここでは、テーブルＡの行番号（a0）「２」の行の３つ目のフィールド（a3）が、何らかの値から「１」に更新されている。”a3”は、事前準備として取得したキー、つまり結合に関わるキーであるので、更新側データベースエンジン１００の更新通知部１２３は、この行との結合を無効とするための更新通知（Ｋｅｙ）を参照側データベースエンジン１００に送信する。この更新通知には、テーブルＡの行番号「２」の行を示す情報（Ａ２）が含まれる。

一方、参照側データベースエンジン１００は、この更新通知を受けると、データ変更部１１３が、テーブルＡ用のインデックスで参照用テーブル２０１の行番号を取得しようと試みる。更新された行の主キー値がテーブルＡ用のインデックスに存在しない場合、データ変更部１１３は、参照用テーブル２０１に行を追加するとともに、更新された行の主キー値で当該追加した行の行番号を得られるようにインデックスも追加する。追加した行のテーブルＡのキーフィールド（rA）には更新された行の行番号である主キー値「２」が格納され、それ以外のすべてのキーフィールド（rB）、フラグ（cache）およびポインタ（ptr）には無効を示す値「０」が格納される。また、無効を示す値「０」を格納するキーフィールドが発生したことにより、データ変更部１１３は、そのキーフィールドに対応する、絞り込み条件としての主キー値の指定が有効な状態か否かのフラグを無効に更新する。

図２１は、事前準備として取得したキーの変更となる、更新用テーブル２０２に行が追加された場合の一例を示している。

図２１に示すように、ここでは、行番号（a0）「５」の行がテーブルＡに追加されている。結合に関わるキーである”a0”および”a3”のデータの追加を伴うので、更新側データベースエンジン１００の更新通知部１２３は、この行との結合を無効とするための更新通知（Ｋｅｙ）を参照側データベースエンジン１００に送信する。この更新通知には、テーブルＡの行番号「５」を示す情報（Ａ５）が含まれる。

この場合、この更新通知を受けた参照側データベースエンジン１００のデータ変更部１１３が行う処理は、図２０を参照して説明した、事前準備として取得したキーの変更となる更新用テーブル２０２の更新であって、更新された行の主キー値がそのテーブル用のインデックスに存在しない場合の処理と同様となる。つまり、データ変更部１１３は、参照用テーブル２０１に行を追加するとともに、更新された行の主キー値で当該追加した行の行番号を得られるようにインデックスも追加する。追加した行のテーブルＡのキーフィールド（rA）には更新された行の行番号である主キー値「５」が格納され、それ以外のすべてのキーフィールド（rB）、フラグ（cache）およびポインタ（ptr）には無効を示す値「０」が格納される。また、無効を示す値「０」を格納するキーフィールドが発生したことにより、データ変更部１１３は、そのキーフィールドに対応する、絞り込み条件としての主キー値の指定が有効な状態か否かのフラグを無効に更新する。

逆に、図２２は、事前準備として取得したキーの変更となる、更新用テーブル２０２から行が削除された場合の一例を示している。

図２２に示すように、ここでは、行番号（a0）「２」の行がテーブルＡから削除されている。結合に関わるキーである”a0”および”a3”のデータの削除を伴うので、更新側データベースエンジン１００の更新通知部１２３は、この行との結合を無効とするための更新通知（Ｋｅｙ）を参照側データベースエンジン１００に送信する。この更新通知には、テーブルＡの行番号「２」を示す情報（Ａ２）が含まれる。

この場合、この更新通知を受けた参照側データベースエンジン１００のデータ変更部１１３が行う処理は、図１９を参照して説明した、事前準備として取得したキーの変更となる更新用テーブル２０２の更新であって、更新された行の主キー値がそのテーブル用のインデックスに存在する場合の処理と同様となる。つまり、データ変更部１１３は、テーブルＡ用のインデックスで参照用テーブル２０１の行番号を取得し、その行のテーブルＡ以外のすべてのキーフィールド（rB）、フラグ（cache）およびポインタ（ptr）を無効に更新する。また、データ変更部１１３は、キーフィールドを無効に更新した場合、そのキーフィールドに対応する、絞り込み条件としての主キー値の指定が有効な状態か否かのフラグを無効に更新する。

以上が、本データベースシステム１の更新用テーブル２０２の更新時における参照用テーブル２０１の更新手順である。なお、更新側データベースエンジン１００は、更新用テーブル２０２が更新された場合であっても、それが参照用テーブルの生成時にＳＱＬ文解析部１２１により抽出された条件文に含まれる絞り込み条件を満たさないデータに対する更新であった場合には、更新通知部１２３による更新通知の参照側データベースエンジン１００への送信は行わない。

図２３は、更新用テーブル２０２上で更新されている行の主キー値を絞り込み条件として指定する参照であって、その更新が、事前準備として取得したキー以外の変更である場合の一例を示している。

図２３に示すように、ここでは、テーブルＡの主キー（a0）値「２」が絞り込み条件として指定されている。このテーブルＡの行番号（a0）「２」の行は、１つ目のフィールド（a1）が「田中」から「里中」に更新されている。”a1”は、事前準備として取得したキー以外、つまり結合に関わるキーではないので、参照用テーブル２０１上では、その行のフラグ（cache）が無効に更新されていることになる。

参照側データベースエンジン１００は、データ制御部１１２により、参照が要求されたデータを返却する。データ制御部１１２は、参照対象の行のフラグ（cache）が有効を示す場合には、その行のポインタ（ptr）で示される配置場所に存在するデータセットを使って、参照が要求されたデータを返却することができる。

一方、参照対象の行のフラグ（cache）が無効を示す場合、データ制御部１１２は、参照が要求されたデータは参照用テーブル２０１に存在しない（参照用テーブル２０１のデータは有効ではない）と判定する。この場合、データ要求部１１４が、その行のキーフィールド（rA,rB）に格納される主キー値（「２」，「１」）を絞り込み条件として指定したクエリを作成し、更新後のデータを含むデータセットを更新用テーブル２０２から取得する。データ要求部１１４は、参照対象の行のポインタ（ptr）を、取得したデータセットの配置場所を示す値に更新して、当該参照対象の行のフラグ（cache）を有効に更新する。そして、データ制御部１１２は、このデータセットを使って、参照が要求されたデータを返却する。

参照対象の行のキーフィールドに格納される主キー値を絞り込み条件として指定したクエリを作成することにより、参照時における、更新用テーブル２０２からの最新のデータセットの取得を迅速に行うことができる。

図２４は、更新用テーブル２０２上で更新されている行と結合された（更新されていない）行の主キー値を絞り込み条件として指定する参照であって、その更新が、事前準備として取得したキー以外の変更である場合の一例を示している。

図２４に示すように、ここでは、テーブルＢの主キー（b0）値「１」が絞り込み条件として指定されている。このテーブルＢの行番号（b0）「１」の行は、更新されていないが、この行が結合されるテーブルＡの行番号（a0）「２」の行と行番号（a0）「３」の行とのうち、行番号（a0）「２」の行は、１つ目のフィールド（a1）が、「田中」から「里中」に更新されている。”a1”は、事前準備として取得したキー以外、つまり結合に関わるキーではないので、参照用テーブル２０１上では、その行のフラグ（cache）が無効に更新されていることになる。

参照対象の行のフラグ（cache）が無効を示すので、参照側データベースエンジン１００は、図２３を参照して説明した、更新用テーブル２０２上で更新されている行の主キー値を絞り込み条件として指定する参照であって、その更新が、事前準備として取得したキー以外の変更である場合と同様の処理を行うことになる。つまり、データ制御部１１２により、参照が要求されたデータは参照用テーブル２０１に存在しない（参照用テーブル２０１のデータは有効ではない）と判定され、データ要求部１１４が、その行のキーフィールド（rA,rB）に格納される主キー値（「２」，「１」）を絞り込み条件として指定したクエリを作成し、更新後のデータを含むデータセットを更新用テーブル２０２から取得する。

この場合も、参照対象の行のキーフィールドに格納される主キー値を絞り込み条件として指定したクエリを作成するので、参照時における、更新用テーブル２０２からの最新のデータセットの取得を迅速に行うことができる。

また、図２５は、主キー値を絞り込み条件として指定する参照であって、参照用テーブル２０１が、当該主キー値の指定が有効な状態にない場合の一例を示している。絞り込み条件としての主キー値の指定が有効な状態に無い場合とは、その主キー値のキーフィールドに無効を示す値を格納する行が存在する場合であり、例えば、事前準備として取得したキーの変更となる更新用テーブル２０２の更新に伴って、行が追加された場合や、ある行の当該主キー値のキーフィールドが無効に更新された場合などが該当する。

図２５に示すように、ここでは、テーブルＢの主キー（b0）値「１」が絞り込み条件として指定されている。また、参照用テーブル２０１の行番号（rowid）「３」の行のテーブルＢ用のキーフィールド（rB）が無効を示していることから、そのキーフィールド（rB）に対応する、絞り込み条件としての主キー値の指定が有効な状態か否かのフラグが無効を示している。この行番号（rowid）「３」の行のテーブルＢ用のキーフィールド（rB）には、「１」が格納されているべきである可能性があり、このようなテーブルＢ用のキーフィールド（rB）が不定である行の有無を、当該テーブルＢ用のキーフィールド（rB）に対応する、絞り込み条件としての主キー値の指定が有効な状態か否かのフラグで即時に判定することができる。

この場合、参照側データベースエンジン１００は、まず、データ制御部１１２が、参照が要求されたデータは参照用テーブル２０１に存在しない（参照用テーブル２０１のデータは有効ではない）と判定する。そして、データ要求部１１４が、参照要求で絞り込み条件として指定されたテーブルＢの主キー（b0）値「１」を用いてクエリを作成し、当該参照要求で絞り込み条件として指定されたテーブルＢの主キー（b0）値「１」に関わるデータセットを更新用テーブル２０２から取得する。参照要求で絞り込み条件として指定された主キー値を用いてクエリを作成することにより、参照時における、更新用テーブル２０２からのデータセットの取得を最小限に抑えることができる。

データ要求部１１４は、キーフィールド（rB）に主キー値「１」が格納され、フラグ（cache）が無効を示していた行については、ポインタ（ptr）を、取得したデータセットの配置場所を示す値に更新して、フラグ（cache）を有効に更新する。また、キーフィールド（rB）に無効を示す値が格納されており、かつ、そのキーフィールド（rB）には主キー値「１」が格納されているべきであった行については、さらに、当該キーフィールド（rB）に主キー値「１」を格納する。この際、キーフィールド（rB）に無効を示す値を格納する行が無くなった場合、データ要求部１１４は、そのキーフィールド（rB）に対応する、絞り込み条件としての主キー値の指定が有効な状態か否かのフラグを有効に更新する。

以上が、本データベースシステム１の参照用テーブル２０１の参照時における参照用テーブル２０１の更新手順である。

このように、本データベースシステム１は、更新用テーブル２０２の更新に伴う参照用テーブル２０１の更新を「参照側主導」で行うことを実現する。

図２６は、更新側データベースエンジン１００の参照用テーブル２０１の生成時の動作手順を示す図である。

更新側データベースエンジン１００は、クエリを受け取ると（ブロックＡ１）、ＳＱＬ文解析部１２１が、そのクエリが参照用テーブル２０１の生成を要求するものであるか否かを判定する（ブロックＡ２）。ＳＱＬ文解析部１２１により、参照用テーブル２０１の生成を要求するクエリであると判定されると（ブロックＡ２のＹＥＳ）、データ制御部１２２が、その参照用テーブル２０１のスキーマを作成する（ブロックＡ３）。更新通知部１２３は、データ制御部１２２により作成されたスキーマを、更新通知として参照側データベースエンジン１００に送信する（ブロックＡ４）。

図２７は、参照側データベースエンジン１００の参照用テーブル２０１の生成時の動作手順を示す図である。

参照側データベースエンジン１００は、更新通知としてスキーマを受信すると（ブロックＢ１）、データ変更部１１３が、このスキーマに基づき、図１３に示した構成を持つ参照用テーブル２０１をメモリ１１５に作成する（ブロックＢ２）。

図２８は、更新側データベースエンジン１００の更新用テーブル２０２の更新時の動作手順を示す図である。

更新側データベースエンジン１００は、クエリを受け取ると（ブロックＣ１）、ＳＱＬ文解析部１２１が、そのクエリが更新用テーブル２０２の更新を要求するものであるか否かを判定する（ブロックＣ３）。ＳＱＬ文解析部１２１により、更新用テーブル２０２の更新を要求するクエリであると判定されると（ブロックＣ３のＹＥＳ）、更新対象の行の情報（更新行情報２１０）がメモリ１２４に格納される（ブロックＣ４）。

この更新に対するコミットを要求するクエリを受けると（ブロックＣ２のＹＥＳ）、データ制御部１２２は、コミット処理を実行する（ブロックＣ６）。また、更新通知部１２３は、メモリ１２４に格納された更新行情報２１０に基づき、更新通知を参照側データベースエンジン１００に送信する（ブロックＣ７）。

図２９は、参照側データベースエンジン１００の更新用テーブル２０２の更新時および参照要求の受け付け時の動作手順を示す図である。

参照側データベースエンジン１００は、更新用テーブル２０２の更新通知を更新側データベースエンジン１００から受けると（ブロックＤ１）、データ変更部１１３が、その通知内容に応じて、参照用テーブル２０１を変更する（ブロックＤ２）。この時の参照用テーブル２０１の変更とは、更新データの反映ではなく、参照時に更新データの反映が必要であることを記録するためのものである。

また、参照側データベースエンジン１００は、データの参照を要求するクエリを受けた場合（ブロックＤ３）、ＳＱＬ文解析部１２１が、その要求が参照用テーブル２０１を適用可能なものであるか否かを判定する（ブロックＤ４）。参照用テーブル２０１を適用可能なものであった場合（ブロックＤ４のＹＥＳ）、データ制御部１１２は、参照対象のデータが参照用テーブル２０１に存在すれば（ブロックＣ５のＮＯ）、そのデータを返却する（ブロックＤ８）。

一方、参照対象のデータが参照用テーブル２０１に存在しなかった場合（ブロックＣ５のＹＥＳ）、データ要求部１１４が、参照用テーブル２０１の情報を使って、参照対象のデータを更新用テーブル２０２から取得する（ブロックＣ６）。データ変更部１１３は、データ要求部１１４により取得されたデータを参照用テーブル２０１に格納し（ブロックＤ７）、また、データ制御部１１２は、同データを返却する（ブロックＤ８）。

図３０は、更新用テーブル２０２の更新に伴う参照用テーブル２０１の更新を「更新側主導」で行った場合と「参照側主導」で行った場合との処理量を比較する図であり、図３１は、更新用テーブル２０２の更新に伴う参照用テーブル２０１の更新を「更新側主導」で行った場合と「参照側主導」で行った場合との所要時間を比較する図である。

図３０および図３１から明らかなように、更新用テーブル２０２の更新に伴う参照用テーブル２０１の更新に関する処理量および所要時間は、いずれも、「参照側主導」の方が「更新側主導」よりも格段に少ない。

このように、本データベースシステム１によれば、キャッシュテーブルを効率的に更新することが実現される。

（第２実施形態）
次に、第２の実施の形態について説明する。

図３２は、本実施形態のデータベースシステム１における参照用テーブルの一構成例を示す図である。

図３２に示すように、本データベースシステム１では、参照用テーブル２０１の各行のキャッシュが有効か否かのフラグを、さらにテーブル毎に持つ（cacheA,cacheB）。図３２では、参照用テーブル２０１の行番号（rowid）「Ｂ」の行のテーブルＡに関するフラグ（cacheA）が無効を示している。一方、この行のテーブルＢに関するフラグ（cacheB）は有効を示している。つまり、テーブルＡのデータとテーブルＢのデータとが結合されたデータセット単位ではなく、更新用テーブル２０２のテーブル単位に有効か否かを管理する。まず、図３３を参照して、本データベースシステム１の参照用テーブル２０１が図３２に示す状態となる更新用テーブル２０２の更新時の動作手順を説明する。

図３３に示すように、ここでは、テーブルＡの行番号（a0）「２」の行の１つ目のフィールド（a1）が、「田中」から「里中」に更新されている。”a1”は、事前準備として取得したキー以外、つまり結合に関わるキーではない。この場合、更新側データベースエンジン１００の更新通知部１２３は、この行のデータを無効とするための更新通知（Ｃｌｅａｒ）を参照側データベースエンジン１００に送信する。この更新通知には、テーブルＡの行番号「２」を示す情報（Ａ２）が含まれる。

一方、参照側データベースエンジン１００は、この更新通知を受けると、データ変更部１１３が、テーブルＡ用のインデックスで参照用テーブル２０１の行番号を取得し、その行のテーブルＡ用のフラグ（cacheA）を無効に更新する。これにより、参照用テーブル２０１は、図３２に示す状態となる。

次に、図３４を参照して、参照用テーブル２０１が図３２に示す状態、つまり参照用テーブル２０１の行番号（rowid）「Ｂ」の行のテーブルＡに関するフラグ（cacheA）が無効を示している状態にある状況下において、この行のデータを参照する時の動作手順を説明する。

参照対象の行のいずれかのフラグ（cacheA,cacheB）が無効を示す場合、データ要求部１１４は、参照用テーブル２０１の生成要求に含まれるクエリの条件であって、参照要求のクエリに含まれる条件である「SELECT 名前、場所 FROM A,B WHERE a2=1 and a3=b0 and b2=’今’」のうち、フラグが無効のテーブル（ここでは、テーブルＡ）に関する絞り込み条件（a2=1）のみを適用し、また、そのテーブル用のキーフィールドに格納される主キー値を絞り込み条件として指定したクエリを作成する。これにより、フラグが無効を示すデータを迅速に取得することができる。データ変更部１１３は、その行のデータセットの中の当該データ部分のみを、取得されたデータで更新する。

このように、本データベースシステム１によれば、事前準備として取得した、結合に関わるキー以外の変更となる更新用テーブル２０２の更新に伴う参照用テーブル２０１の更新について、より一層の効率化を図ることが実現される。

（第３実施形態）
次に、第３の実施の形態について説明する。

図３５は、本実施形態のデータベースシステム１における参照用テーブルの一構成例を示す図である。

図３５に示すように、本データベースシステム１では、参照用テーブル２０１の各行について、データセットの配置場所を示すポインタを持つのではなく、更新用テーブル２０２のテーブル毎に、データセットを構成するデータ（同一テーブルの同一行から複数のフィールドのデータが抽出される場合は、当該複数のデータからなるデータセット）の配置場所を示すポインタを持つ（Aptr,Bptr）。このポインタ（Aptr,Bptr）は、キャッシュが有効か否かのフラグの役割を兼ねる。

テーブル形式でデータを格納する場合、異なる行のフィールドに同一のデータが格納されることが発生し得る。そこで、ポインタを更新用テーブル２０２のテーブル毎に持つことにより、このような場合であっても、その行数分、当該同一のデータを格納するための記憶領域を確保することを不要とし、重複の圧縮を実現する。

各実施形態の動作手順は、ソフトウェア（プログラム）によって実現することができるので、このソフトウェアを格納したコンピュータ読み取り可能な記憶媒体を通じてこのソフトウェアを通常のコンピュータにインストールして実行することにより、各実施形態と同様の効果を容易に実現することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…データベースシステム、１０…データベース、１１…コントローラ、１２…ファイルシステム、１００…データベースエンジン、１１１…ＳＱＬ文解析部、１１２…データ制御部、１１３…データ変更部、１１４…データ要求部、１２１…ＳＱＬ文解析部、１２２…データ制御部、１２３…更新通知部、２０１…参照用テーブル、２０２…更新用テーブル

Claims (10)

1. 第１テーブルおよび当該第１テーブルを事前に参照要求に適するように変形をした第２テーブルを用いて、データの参照要求に応答するデータベースシステムであって、
   前記第１テーブルを管理する第１管理手段と、
   前記第２テーブルを管理する第２管理手段と、
   を具備し、
   前記第１管理手段は、前記第１テーブルのデータが更新された場合、その更新内容を示す更新通知を前記第２管理手段に送信する通知手段を具備し、
   前記第２管理手段は、
   前記更新通知を受信した場合、前記更新通知で示される更新内容に該当する前記第２テーブルのデータを無効化する無効化手段と、
   前記第１テーブルのデータの参照要求を受けた場合であって、そのデータの参照要求に応答するために必要な前記第２テーブルのデータが無効化されている場合、そのデータを前記第１テーブルから取得して前記第２テーブルに格納する更新手段と、
   を具備するデータベースシステム。
2. 前記第１テーブルが２以上の第１テーブルを有し、
   前記第２テーブルが、前記参照要求に適するように、前記２以上の第１テーブルを結合して生成されるものである、
   請求項１に記載のデータベースシステム。
3. 前記第２テーブルは、前記２以上の第１テーブルのデータが結合されたデータセット毎に、前記２以上の第１テーブルの主キー値を格納する２以上のキーフィールドと、データセットが有効か否かを示す値を格納する第１フラグとを有し、
   前記無効化手段は、
   前記更新通知で示される更新内容が前記２以上の第１テーブルの結合に関わるキー値以外かつ前記２以上の第１テーブルの主キー値以外の更新である場合、該当するデータセットに対応する前記第１フラグの値を無効を示す値に更新し、
   前記更新通知で示される更新内容が前記２以上の第１テーブルの結合に関わるキー値または前記２以上の第１テーブルの主キー値の更新である場合、該当するデータセットに対応する前記２以上のキーフィールドの中の更新対象となった第１テーブルの主キー値を格納するキーフィールド以外のキーフィールドの値と、前記第１フラグの値とを無効を示す値に更新する、
   請求項２に記載のデータベースシステム。
4. 前記第２テーブルは、前記２以上の第１テーブル毎に、主キー値による当該主キー値を格納するキーフィールドの直接検索を行うためのインデックスをさらに有し、
   前記無効化手段は、前記インデックスを用いて、前記更新通知で示される更新内容に該当するデータセットを検索する、
   請求項３に記載のデータベースシステム。
5. 前記第２テーブルは、前記２以上のキーフィールド毎に、無効を示す値を格納するキーフィールドが存在するか否かを示す値を格納する第２フラグをさらに有し、
   前記無効化手段は、前記２以上のキーフィールドの値を無効を示す値に更新した場合、そのキーフィールドに対応する前記第２フラグの値を、無効を示す値を格納するキーフィールドが存在することを示す値に更新する、
   請求項４に記載のデータベースシステム。
6. 前記更新手段は、前記２以上の第１テーブルの結合を伴うデータの参照要求に応答するために必要な前記第２テーブルのデータセットに対応する前記第１フラグの値が無効を示す値であった場合、そのデータセットに対応する前記２以上のキーフィールドの主キー値を用いた絞り込み条件を含むデータの取得要求を発行して、更新データを前記２以上の第１テーブルから取得する請求項５に記載のデータベースシステム。
7. 前記更新手段は、前記２以上の第１テーブルの結合を伴うデータの参照要求に前記第１テーブルの主キー値を用いた絞り込み条件が含まれ、かつ、その第１テーブルの主キー値を格納するキーフィールドに対応する第２フラグの値が、無効を示す値を格納するキーフィールドが存在することを示す場合、前記データの参照要求に含まれる絞り込み条件に用いられる前記第１テーブルの主キー値を用いた絞り込み条件を含むデータの取得要求を発行して、更新データを前記２以上の第１テーブルから取得する請求項６に記載のデータベースシステム。
8. 前記更新手段は、前記取得した更新データを反映させたデータセットに対応する前記２以上のキーフィールドに主キー値を格納するとともに、前記第１フラグの値を有効を示す値に更新し、この主キー値の格納により無効を示す値を格納するキーフィールドが無くなった場合、そのキーフィールドに対応する前記第２フラグの値を、無効を示す値を格納するキーフィールドが存在しないことを示す値に更新する請求項７に記載のデータベースシステム。
9. 前記通知手段は、前記２以上の第１テーブルから前記第２テーブルを生成する際の絞り込み条件を満たすデータの更新が前記２以上の第１テーブル上で行われた場合、前記更新通知を前記第２管理手段に送信する請求項２に記載のデータベースシステム。
10. 前記通知手段は、同一テーブルの同一行上での複数のデータの更新が行われた場合、当該複数のデータの更新に対して１つの更新通知を前記第２管理手段に送信する請求項２に記載のデータベースシステム。

Images