JP5492146B2 - データベースシステム及び制御方法 - Google Patents

Description

本発明は、データベースシステム及び制御方法に関する。

レコードを複数蓄積したデータベースと、データベース応答を高速化するためのキャッシュを連携させる場合のキャッシュ検索技術がある。例えば、オープンハッシュ法によるデータ構造を用いる手法や、ｋ−ｄ木を用いる手法がある。なお、オープンハッシュ法は、外部ハッシュ法とも称される。

キャッシュ検索技術は、例えば、認証要求やネットワークを制御するためのデータ要求の処理において用いられる。

図２７は、検索アルゴリズムを用いて目的となるレコードを抽出することになる場面の一例を示す図である。図２７に示す例では、ネットワーク機器５０１が、ユーザ５０２からの要求に基づいて、ネットワーク機器５０３を特定したり、ユーザ５０２を認証したりする場合を例に示した。また、図２７に示す例では、ネットワーク機器５０１が、ネットワーク機器５０３を特定したり、ユーザ５０２を認証したりする場合に、認証サーバ５０４や網制御サーバ５０５に問い合わせる場合を例に示した。図２７に示す例では、認証サーバ５０４や網制御サーバ５０５がデータベースと接続され、レコードを抽出する場合を用いて説明する。

この場合、認証サーバ５０４や網制御サーバ５０５は、ネットワーク機器５０１によって送信される情報に基づいて、データベースからレコードを抽出することで、どのような認証を行うかを特定したり、どのような網制御を行うかを特定したりする。

以下では、レコードの抽出に用いられる情報を「サービス特定情報」とも記載する。「サービス特定情報」により提供されるサービスを「制御サービス」とも記載し、「制御サービス」の提供に用いられる情報を「制御サービスデータ」とも記載する。「サービス特定情報」は、一つ又は複数の「サービス特定情報要素」から構成され、サービス特定情報を構成するサービス特定情報要素が、Ｎ個あり、それぞれを、サービス特定情報要素（Ｅ１、Ｅ２、・・・ＥＮ）と記載する。

図２７に示す例に当てはめると、例えば、ネットワーク機器５０１は、サービス特定情報を認証サーバ５０４や網制御サーバ５０５に送信する。ここで、認証サーバ５０４や網制御サーバ５０５は、ネットワーク機器５０１から受信したサービス特定情報に基づいて、データベースからレコードを抽出する。

なお、サービス特定情報要素を「特定情報」とも記載する。ここで、制御サービスには、全てのサービス特定情報要素により制御サービスデータが決定されるものもあれば、一部のサービス特定情報要素の集合により制御サービスデータが決定されるものもある。例えば、ネットワーク機器５０１によって送信されたサービス特定情報に含まれる複数の特定情報のうち、すべてが用いられる場合もあれば、一部が用いられる場合もある。

図２８を用いて、オープンハッシュ法について簡単に示す。図２８は、オープンハッシュ法の基本的なデータ構造の一例を示す図である。図２８に示すように、オープンハッシュ法では、検索対象となるカラムをキーとして、このキーがＢ個の有限個のクラスに分割される。また、Ｂ個に分割したクラス各々に対して、０、１、・・・Ｂ−１の整数の番号をつける。更に、キーになり得るｘに対して、０からＢ−１までの整数ｈ（ｘ）を与えるようなハッシュ関数ｈを用意する。ｈ（ｘ）がｘの属するクラスを表す。ここで、ｈ（ｘ）は、ｘのハッシュ値とも称される。ｘは、バケットｈ（ｘ）に属するとも称される。図２８に示すように、同一のハッシュ値を持つキーを含むレコードは、言い換えると、同一のバケットに属するキーを含むレコードは、リストとして管理される。

図２８に示すデータ構造を用いて、オープンハッシュ法におけるレコードの追加操作、削除操作、検索操作の一例を順に説明する。オープンハッシュ法における追加操作の一例について説明する。この場合、（１）追加対象のレコードのキーｘのハッシュ値ｈ（ｘ）を計算し、バケットを特定する。そして、（２）特定されたバケットのリストを順に調査し、リストの最後まで同一のキーのレコードがリストに存在しない場合に、リストの最後に追加対象のレコードを連結する。言い換えると、追加対象となるレコードを追加する。

次に、オープンハッシュ法における検索操作の一例について説明する。この場合、（１）追加対象のレコードのキーｘのハッシュ値ｈ（ｘ）を計算し、バケットを特定する。そして、（２）特定されたバケットのリストを順に調査し同一のキーであるかの判定を行う。その後、（３）同一のキーが存在すれば、検索対象のレコードと判定する。

続いて、オープンハッシュ法における削除操作の一例について説明する。この場合、（１）追加対象のレコードのキーｘのハッシュ値ｈ（ｘ）を計算し、バケットを特定する。そして、（２）特定されたバケットのリストを順に調査し同一のキーであるかの判定を行う。その後、（３）同一のキーが存在すれば、リストから該当するキーのレコードを削除する。

図２９を用いて、ｋ−ｄ木法について簡単に示す。図２９は、ｋ−ｄ木を用いた方法のデータ構造の一例を示す図である。ｋ−ｄ木法では、ｋ個のカラムが検証対象となる。以下では、検証対象となるｋ個のカラムを、それぞれ、ｃ０、ｃ１、・・・ｃｋ−１と記載する。図２９には、ｋを３とした場合を例に示した。図２９の丸に示すデータ構造にあるノードには、レコードが登録される。各ノードには、木のルートとなるノードからの深さに応じたディスクリミネータと呼ばれる値が割り当てられる。ルートであるノードＡのディスクリミネータは、「０」である。また、ノードＢ、Ｃのディスクリミネータは、「１」である。ノードＤ、Ｅ、Ｆのディスクリミネータは、「２」である。更に、ノードＧのディスクリミネータは、「０」である。この例のように、ルートとなるノードのディスクリミネータを「０」とし、深さに応じて一つずつｋ−１まで増加させ、その後、「０」に戻ることを繰り返しながら、ディスクリミネータをノードに割り当てる。

ここで、ディスクリミネータは、割り当てられているノードで比較すべきカラムを示す。例えば、ディスクリミネータが１のノードでは、カラムｃ１が比較対象となる。

以下では、ノードＰのカラムｃｉの値を、Ｋｉ（Ｐ）と記載する。また、各ノードＰには、２つの子ノードが存在し、ＬＯＳＯＮ（Ｐ）及びＨＩＳＯＮ（Ｐ）と記載する。また、ノードＰのディスクリミネータが「ｉ」であるとき、ＬＯＳＯＮ（Ｐ）以下の任意のノードについて、カラムｃｉの値が、Ｋｉ（Ｐ）よりも小さくなるようにノードを配置する。また、ＨＩＳＯＮ（Ｐ）以下の任意のノードについて、カラムｃｉの値が、Ｋｉ（Ｐ）よりも大きくなるようにノードを配置する。

図２９に示すデータ構造を用いて、ｋ−ｄ木法におけるレコードの追加操作、完全一致検索、部分一致検索、削除の一例を順に説明する。なお、完全一致検索とは、全てのカラムの条件が指定された場合における検索を示し、部分一致検索とは、一部のカラムの条件が指定された場合における検索を示す。

ｋ−ｄ木を用いた方法における追加操作の一例について説明する。この場合、（１）追加対象のレコードをｋ−ｄ木に組み込んだときのノードをノードＰと表すものとして説明する。ここで、（２）ルートノードが存在しなければ、追加対象のレコードをルートノードとし、ＬＯＳＯＮ（Ｐ）とＨＩＳＯＮ（Ｐ）には、「空」を割り当て、終了する。一方、ルートノードが存在する場合は、ルートノードをノードＱとして以下を実施する。具体的には、（３）全てのカラムｃｉについて、Ｋｉ（Ｐ）とＫｉ（Ｑ）を比較し、全て同じ場合には、既に存在するため追加を行わない。（４）一方、Ｋｉ（Ｐ）＜Ｋｉ（Ｑ）ならば、ＬＯＳＯＮ（Ｑ）をＳＯＮ（Ｑ）とし、Ｋｉ（Ｐ）＞Ｋｉ（Ｑ）ならば、ＨＩＳＯＮ（Ｑ）をＳＯＮ（Ｑ）とする。また、（５）ＳＯＮ（Ｑ）が「空」であれば、ＳＯＮ（Ｑ）にノードＰを連結し、ＬＯＳＯＮ（Ｐ）とＨＩＳＯＮ（Ｐ）には、「空」を割り当て、終了する。ＳＯＮ（Ｑ）が「空」でない場合、ＳＯＮ（Ｑ）をＱとして、上記の（３）を実行する。Ｋｉ（Ｐ）＝Ｋｉ（Ｑ）ならば、全てのカラムを繋げた値で、Ｋｉ（Ｐ）とＫｉ（Ｑ）を比較する。

ｋ−ｄ木を用いた方法における完全一致検索操作の一例について説明する。（１）検索対象のレコードをｋ−ｄ木に組み込んだと仮定したときのノードをノードＰと表すものとして説明する。ここで、（２）ルートノードが存在しない場合には、検索対象なしとして終了し、ルートノードが存在する場合には、ルートノードをノードＱとして以下の処理を実行する。具体的には、（３）全てのカラムｃｉについて、Ｋｉ（Ｐ）とＫｉ（Ｑ）を比較し、全て同じ場合は、Ｑに割り当てられたレコードを検索結果とする。（４）もし、Ｋｉ（Ｐ）＜Ｋｉ（Ｑ）となる場合には、ＬＯＳＯＮ（Ｑ）をＳＯＮ（Ｑ）とし、Ｋｉ（Ｐ）＞Ｋｉ（Ｑ）となる場合には、ＨＩＳＯＮ（Ｑ）をＳＯＮ（Ｑ）とする。（５）その上で、ＳＯＮ（Ｑ）が「空」であれば、検索対象なしとして終了する。また、ＳＯＮ（Ｑ）が「空」でない場合、ＳＯＮ（Ｑ）をＱとして、上記の（３）を実行する。また、Ｋｉ（Ｐ）＝Ｋｉ（Ｑ）ならば、全てのカラムを繋げた値で、Ｋｉ（Ｐ）とＫｉ（Ｑ）を比較する。

ｋ−ｄ木を用いた方法における部分一致検索操作の一例について説明する。この場合、（１）検索対象のレコードをｋ−ｄ木に組み込んだと仮定したときのノードをノードＰと表すものとして説明する。ここで、（２）ルートノードが存在しない場合には、検索対象なしとして終了する。ルートノードが存在する場合は、ルートノードをノードＱとして以下を実施する。具体的には、（３）検索条件となっている全てのカラムｃｉについて、検索条件とＫｉ（Ｑ）を比較し、全て条件に合致すれば、Ｑを検索対象とし、以下を実施する。すなわち、（４）ＱのディスクリミネータがＪであり、カラムｃＪが検索条件として指定されているとき、カラムｃＪの検索条件とＫｉ（Ｑ）を比較する。比較の結果、Ｋｉ（Ｑ）が大きければ、ＬＯＳＯＮ（Ｑ）について、（３）の処理を再帰的に実行する。比較の結果、Ｋｉ（Ｑ）が小さければ、ＨＩＳＯＮ（Ｑ）について、（３）の処理を再帰的に実行する。カラムｃＪが検索条件として指定されていないとき、ＬＯＳＯＮ（Ｑ）とＨＩＳＯＮ（Ｑ）の双方について、（３）の処理を再帰的に実行する。ここで、（５）もし、Ｋｉ（Ｐ）＜Ｋｉ（Ｑ）ならば、ＬＯＳＯＮ（Ｑ）をＳＯＮ（Ｑ）とし、Ｋｉ（Ｐ）＞Ｋｉ（Ｑ）ならば、ＨＩＳＯＮ（Ｑ）をＳＯＮ（Ｑ）とする。（６）ＳＯＮ（Ｑ）が「空」であれば、検索対象なしとして終了する。ＳＯＮ（Ｑ）が「空」でない場合、ＳＯＮ（Ｑ）をＱとして、上記の（３）を実行する。Ｋｉ（Ｐ）＝Ｋｉ（Ｑ）ならば、全てのカラムを繋げた値で、Ｋｉ（Ｐ）とＫｉ（Ｑ）を比較する。

ｋ−ｄ木を用いた方法における削除操作の一例について説明する。この場合、（１）削除対象のレコードを持つノードをノードＰと表すものとして説明する。ここで、（２）ノードＰについて、ＬＯＳＯＮ（Ｐ）とＨＩＳＯＮ（Ｐ）が共に、「空」の場合、ノードＰを指し示している親ノードＲのＬＯＳＯＮ（Ｒ）又はＨＩＳＯＮ（Ｒ）を「空」とし、ノードＰをｋ−ｄ木から取り除く。そして、（３）ノードＰについて、ＬＯＳＯＮ（Ｐ）とＨＩＳＯＮ（Ｐ）のうち少なくとも、一方が「空」でないの場合、ノードＰのディスクリミネータをＪとすると、ＬＯＳＯＮ（Ｐ）をルートとする部分木の中で、カラムｃＪの最も大きいノードをＱとするか、ＨＩＳＯＮ（Ｐ）をルートとする部分木の中で、カラムｃＪの最も小さいノードをＱとし、ノードＰをノードＱで置き換える。Ｑは、同様に、ｋ−ｄ木の元の位置から取り除く。

なお、レコードを抽出する上で必要となる特定情報の集合が受信時点において不明である場合がある。図２７に示す例では、認証サーバ５０４や網制御サーバ５０５は、ネットワーク機器５０１からサービス特定情報を受信した時点において、サービス特定情報に含まれる特定情報のうち、レコードを抽出する上で必要となるサービス特定情報要素の集合が不明である場合がある。更に、ネットワーク機器５０１についても、認証サーバ５０４や網制御サーバ５０５に制御サービスを送信する時点において、送信するサービス特定情報に含まれる特定情報のうち、レコードを抽出する上で必要となるサービス特定情報要素の集合不明である場合もある。

「データ構造とアルゴリズム」、Ａ．Ｖ．エイホ、Ｊ．Ｅ．ホップクロフト、Ｊ．Ｄ．ウルマン著、大野義夫訳、培風館、１９８７年発行 「Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ Ｂｉｎａｒｙ Ｓｅａｒｃｈ Ｔｒｅｅｓ Ｕｓｅｄ ｆｏｒ Ａｓｓｏｃｉａｔｉｖｅ Ｓｅａｒｃｈｉｎｇ」、Ｊ．Ｌ．Ｂｅｎｔｌｅｙ著、Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｏｆ ｔｈｅ ＡＣＭ、Ｖｏｌ． １８、Ｎｏ． ９、 ｐｐ． ５０９−５１７、Ｓｅｐｔｅｍｂｅｒ １９７５年

ここで、データベースからレコードを抽出する上で必要となる特定情報の集合が不明である場合に、上述した従来の検索アルゴリズムを応用し、以下に説明する処理を実行することが考えられるが、適切に検索できないという課題がある。

なお、以下では、説明の便宜上、サービス特定情報要素に（Ｅ１、Ｅ２、Ｅ３）が含まれている場合を用いて説明する。また、Ｅ１に依存して、制御サービスデータの特定に必要なサービス特定情報要素の集合が、｛Ｅ１｝となるか、｛Ｅ１， Ｅ２｝となるか、｛Ｅ１， Ｅ２， Ｅ３｝となるかが決定される場合を用いて説明する。

例えば、上述した従来の検索アルゴリズムを用いた検索を２回行う２回手法が考えられる。この場合、制御サービスデータの特定に用いられるサービス特定情報要素の集合を示すテーブルが予め作成される。図３０は、制御サービスデータの特定に用いられるサービス特定情報要素の集合を示すテーブルの一例を示す図である。図３０に示す例では、Ｅ１が「ＳｅｒｖｉｃｅＮａｍｅ−００１」である場合には、サービス特定情報要素の集合として｛Ｅ１｝が用いられることになる場合を示した。同様に、図３０に示す例では、Ｅ１が「ＳｅｒｖｉｃｅＮａｍｅ−００２」である場合には、サービス特定情報要素の集合として｛Ｅ１， Ｅ２， Ｅ３｝が用いられることになる場合を示した。

２回手法では、まず、予め作成したテーブルから、サービス特定情報要素の集合を検索する。その後、１回目の検索結果となるサービス特定情報要素の集合を一つのカラムとして２回目の検索を行うことで、制御サービスデータを特定する。図３１−１〜図３１−３は、２回目の検索にて用いられるサービス特定情報要素の組み合わせの一例を示す図である。図３１−１〜図３１−３は、それぞれ、サービス特定情報要素の集合が、｛Ｅ１｝｛Ｅ１， Ｅ２｝｛Ｅ１， Ｅ２， Ｅ３｝となる場合各々に対応する。なお、図３１−１〜図３１−３に示す例では、サービス特定情報要素の組み合わせに対応付けて、制御サービスデータの一例を併せて示した。

このように、２回手法を用いる場合には、検索アルゴリズムを２回実行することになり、検索性能が低下する。

また、公知の検索アルゴリズムによる検索において、サービス特定情報要素の組み合わせ全てをキーとして、全てのキーについて検索を行う全手法が考えられる。図３２は、全手法においてキーとして用いられるサービス特定情報要素の組み合わせを示すテーブルの一例を示す図である。図３２に示すテーブルの場合、Ｅ１が「ＳｅｒｖｉｃｅＮａｍｅ−００１」となる場合には、Ｅ２やＥ３に関係なく同じ制御サービスデータとなることを踏まえ、Ｅ１の値に対応付けられた制御サービスデータは、Ｅ２とＥ３との組み合わせ全てについて、同じ値が登録される。図３２に示す例では、Ｅ１として「ＳｅｒｖｉｃｅＮａｍｅ−００１」を含むレコードが６つ登録され、６つのレコードの制御サービスデータがどれも「データ１」となる。なお、図３２に示す例では、サービス特定情報要素の組み合わせに対応付けて、制御サービスデータの一例を併せて示した。全手法の場合、｛Ｅ１， Ｅ２， Ｅ３｝を一つのカラムとして検索が行われることで、制御サービスデータを特定する。

このように、全手法を用いる場合には、同じ制御サービスデータを有するレコードを複数登録されることになり、サーバのメモリまたはハードディスクなどのサーバの記憶域が浪費される。また、キャッシュ技術を用いて、制御サービスデータを格納して高速に処理する設計にした場合、キャッシュサーバのメモリに同じ制御サービスデータを持つレコードが複数登録されることになり、キャッシュサーバのメモリが重複した制御サービスデータにより浪費される結果、キャッシュサーバにキャッシュ可能なレコード数が減少し、少数の制御サービスデータによる処理しか受け持つことができなくなる。

また、全手法に対してｋ−ｄ木を用いた手法を適用し、レコードを集約して完全一致と部分一致とを併用する集約手法も考えられる。図３２を参照して説明すると、図３２に示すテーブルにおいて、同じ制御サービスデータを持つレコードを一つに集約し、且つ、検索方法として、完全一致検索と部分一致検索とを併用することで、制御サービスデータを特定する手法が考えられる。

図３３は、図３２に示すテーブルにおいて、同じ制御サービスデータを持つレコードを一つに集約したテーブルの一例を示す図である。図３２に示す例では、制御サービスデータ「データ１」を含むレコードが６であるのに対して、図３３に示す例では、１つのレコードに集約されている。

集約手法では、全てのサービス特定情報要素の組み合わせについて、完全一致検索と部分一致検索とを行い、制御サービスデータの検索を行う。例えば、集約手法では、まず、｛Ｅ１， Ｅ２， Ｅ３｝を指定した完全一致検索を行い、レコードが検索できない場合は、｛Ｅ１， Ｅ２｝を指定して、部分一致検索を行い、更に、レコードが検索できない場合は、｛Ｅ１｝のみを指定した部分一致検索を行うことで、制御サービスデータを特定する。また、集約手法では、｛Ｅ１｝のみを指定してもレコードが検索できない場合には、該当レコードが存在しないと判断する。

このように、集約手法を用いる場合には、複数回の制御サービスデータの検索を行うことがあり、検索性能が低下する場合がある。また、集約手法を用いる場合には、部分一致検索を用いた場合、ｋ−ｄ木の中で、２つある検索経路のうち、ＨＩＳＯＮ及びＬＯＳＯＮの双方を検索しなければならないことになり、検索のための処理負荷が増大し、検索性能が低下する。

開示の技術は、上述に鑑みてなされたものであって、適切に検索可能となるデータベースシステム及び制御方法を提供することを目的とする。

開示するデータベースシステムは、一つの態様において、データベースと、キャッシュサーバとを有する。データベースは、記憶部と、キャッシュ応答部とを有する。キャッシュサーバは、キャッシュと、判定部と、特定情報送信部と、格納部と、データ送信部とを有する。記憶部は、データごとに、該データを特定するための特定情報と、前記特定情報の複数の種類のうち該データを特定する際に用いられない種類である非特定種類を示す非特定種類情報との組み合わせを記憶する。キャッシュは、前記データベースに記憶された前記データの少なくとも一部について、前記特定情報と前記非特定種類情報との組み合わせと、複数種類の前記特定情報の組み合わせとのうち少なくとも一つと対応付けて記憶する。判定部は、データ要求を受信すると、該データ要求に含まれる複数種類の前記特定情報各々の組み合わせが前記キャッシュに記憶されているかを判定する。特定情報送信部は、前記判定部により記憶されていないと判定された場合に、前記データ要求に含まれる組み合わせを前記データベースに送信する。キャッシュ応答部は、前記特定情報送信部により送信された組み合わせである組み合わせを受信すると、受信した組み合わせである受信組み合わせに相当する前記記憶部に記憶された前記特定情報と前記非特定種類情報との組み合わせと、該特定情報と該非特定種類情報との組み合わせに対応付けられた前記データとを前記記憶部から取得し、前記キャッシュサーバに応答する。格納部は、前記キャッシュ応答部により送信された前記特定情報と前記非特定種類情報との組み合わせが前記キャッシュに記憶されている場合には、記憶されていた前記特定情報と前記非特定種類情報との組み合わせに対応付けられるデータと対応付けて、前記受信組み合わせを前記キャッシュに格納し、前記キャッシュに記憶されていない場合には、前記キャッシュ応答部により送信されたデータと対応付けて、前記キャッシュ応答部により送信された前記特定情報と前記非特定種類情報との組み合わせと、前記受信組み合わせとを前記キャッシュに格納する。データ送信部は、前記判定部により記憶されていると判定された場合には、前記キャッシュから前記データを取得して前記データ要求の送信元に送信し、前記判定部により記憶されていないと判定された場合には、前記キャッシュ応答部により送信された前記データを前記データ要求の送信元に送信する。

開示するデータベースシステムの一つの態様によれば、適切に検索可能となるという効果を奏する。

図１は、実施例１におけるデータベースシステムの全体像の一例を示す図である。 図２は、実施例１におけるデータベースサーバの構成の一例を示すブロック図である。 図３は、実施例１におけるユーザ情報ＤＢに記憶された情報の一例を示す図である。 図４は、実施例１におけるＩＲ情報ＤＢに記憶された情報の一例を示す図である。 図５は、実施例１におけるキャッシュ応答部により用いられる応答データ判定表の一例を示す図である。 図６は、実施例１におけるキャッシュサーバの構成の一例を示す図である。 図７−１は、実施例１におけるキャッシュに記憶された情報の一例を示す図である。 図７−２は、実施例１におけるキャッシュに記憶された情報の一例を示す図である。 図７−３は、実施例１におけるキャッシュに記憶された情報の一例を示す図である。 図８−１は、実施例１におけるキャッシュ判定部によりレコードが追加された後のキャッシュに記憶された情報の一例を示す図である。 図８−２は、実施例１におけるキャッシュ判定部によりレコードが追加された後のキャッシュに記憶された情報の一例を示す図である。 図８−３は、実施例１におけるキャッシュ判定部によりレコードが追加された後のキャッシュに記憶された情報の一例を示す図である。 図９は、実施例１におけるデータベースサーバのキャッシュ応答処理による処理の流れの一例を示すフローチャートである。 図１０は、実施例１におけるＩＲ情報応答部による処理の流れの一例を示すフローチャートである。 図１１は、実施例１におけるデータベースサーバのＩＲ情報削除部による流れの一例を示すフローチャートである。 図１２は、実施例１におけるデータベースサーバのユーザ情報更新部による処理の流れの一例を示すフローチャートである。 図１３は、実施例１におけるキャッシュサーバのキャッシュ判定部による処理の流れの一例を示すフローチャートである。 図１４は、実施例１におけるキャッシュ登録処理の流れの一例を示すフローチャートである。 図１５は、実施例１におけるキャッシュ削除処理の流れの一例を示すフローチャートである。 図１６は、実施例１におけるキャッシュサーバのＩＲ情報判定部による処理の流れの一例を示すフローチャートである。 図１７は、実施例１におけるキャッシュサーバの応答部による処理の流れの一例を示すフローチャートである。 図１８−１は、実施例２におけるキャッシュに記憶された情報の一例を示す図である。 図１８−２は、実施例２におけるキャッシュに記憶された情報の一例を示す図である。 図１８−３は、実施例２におけるキャッシュに記憶された情報の一例を示す図である。 図１９は、実施例２における事前に決定されているサービス特定要素の値の一覧の例である。 図２０−１は、実施例２におけるキャッシュ判定部によるレコード登録処理後のキャッシュに記憶された情報の一例を示す図である。 図２０−２は、実施例２におけるキャッシュ判定部によるレコード登録処理後のキャッシュに記憶された情報の一例を示す図である。 図２０−３は、実施例２におけるキャッシュ判定部によるレコード登録処理後のキャッシュに記憶された情報の一例を示す図である。 図２１は、実施例２におけるキャッシュ登録処理の一例を示すフローチャートである。 図２２は、実施例３におけるユーザ情報ＤＢに記憶された情報の一例を示す図である。 図２３は、実施例３におけるＩＲ情報ＤＢに記憶された情報の一例を示す図である。 図２４は、実施例３におけるデータベースサーバのキャッシュ応答部による処理の流れの一例を示すフローチャートである。 図２５は、実施例３におけるキャッシュ削除処理の流れの一例を示すフローチャートである。 図２６は、データベースシステムによる処理をプログラムにて実行するための制御プログラムによる情報処理が、コンピュータを用いて具体的に実現されることを示す図である。 図２７は、検索アルゴリズムを用いて目的となるレコードを抽出することになる場面の一例を示す図である。 図２８は、オープンハッシュ法の基本的なデータ構造の一例を示す図である。 図２９は、ｋ−ｄ木を用いた方法のデータ構造の一例を示す図である。 図３０は、制御サービスデータの特定に用いられるサービス特定情報要素の集合を示すテーブルの一例を示す図である。 図３１−１は、２回目の検索にて用いられるサービス特定情報要素の組み合わせの一例を示す図である。 図３１−２は、２回目の検索にて用いられるサービス特定情報要素の組み合わせの一例を示す図である。 図３１−３は、２回目の検索にて用いられるサービス特定情報要素の組み合わせの一例を示す図である。 図３２は、全手法においてキーとして用いられるサービス特定情報要素の組み合わせを示すテーブルの一例を示す図である。 図３３は、図３２に示すテーブルにおいて、同じ制御サービスデータを持つレコードを一つに集約したテーブルの一例を示す図である。

以下に、開示するデータベースシステム及び制御方法の実施例について、図面に基づいて詳細に説明する。なお、本実施例により開示する発明が限定されるものではない。各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

［実施例１における全体構成］
図１を用いて、実施例１におけるデータベースシステムの像を簡単に説明する。図１は、実施例１におけるデータベースシステムの全体像の一例を示す図である。図１に示すように、データベースシステムは、クライアント１００と、データベースサーバ２００と、キャッシュサーバ３００とを有する。クライアント１００と、データベースサーバ２００と、キャッシュサーバ３００とは、ネットワークを介して接続される。なお、図１に示す例では、クライアント１００が１つあり、データベースサーバ２００が１つあり、キャッシュサーバ３００が２つある場合を示したが、これに限定されるものではなく、各装置は任意の数あって良い。

クライアント１００は、キャッシュサーバ３００又はデータベースサーバ２００に格納されているデータを要求するデータ要求をキャッシュサーバ３００に送信する。また、クライアント１００は、キャッシュサーバ３００又はキャッシュサーバ３００からのデータ応答を受信する。その後、例えば、クライアント１００は、データ応答に含まれるデータを用いて、各種サービスを実行する。クライアント１００は、例えば、利用者により用いられる情報処理端末が該当する。

データベースサーバ２００は、大容量の記憶部を有する。データベースサーバ２００は、クライアント１００により参照されるデータを記憶部に記憶する。具体的には、データベースサーバ２００は、データごとに、データを特定するための特定情報と、特定情報の複数の種類のうちデータを特定する際に用いられない種類である非特定種類を示す非特定種類情報との組み合わせを記憶部に記憶する。

また、データベースサーバ２００は、図１の（ｉ）に示すように、データが更新されると、Ｉｎｖａｌｉｄａｔｉｏｎ Ｒｅｐｏｒｔ技術を用い、データベース上で変更となった情報（ＩＲ情報）を生成する。なお、以下に説明するように、データベースサーバ２００とキャッシュサーバ３００とは、ＩＲ情報を用いて、データベースサーバ２００に記憶された情報のうち更新された情報を共有する。ただし、これに限定されるものではなく、ＩＲ情報を用いるのではなく、任意の手法を用いてデータベースサーバ２００とキャッシュサーバ３００とが共有しても良い。

キャッシュサーバ３００は、データベースサーバ２００に記憶されたデータのうち、過去にキャッシュサーバ３００が使用したデータをキャッシュ３１１に記憶する。具体的には、キャッシュサーバ３００は、データベースサーバ２００に記憶されたデータの少なくとも一部について、特定情報と非特定種類情報との組み合わせと、複数種類の特定情報の組み合わせとのうち少なくとも一つと対応付けてキャッシュ３１１に記憶する。キャッシュサーバ３００は、過去に使用したデータをキャッシュ３１１に記憶して用いることで、高速なアクセスを実現する。

キャッシュサーバ３００は、クライアント１００からデータ要求を受信すると、データ要求により要求されたデータを自装置のキャッシュ３１１に記憶している場合には、図１の（４）に示すように、キャッシュ３１１に記憶されたデータをデータ応答として送信する。一方、キャッシュサーバ３００は、データ要求により要求されたデータを自装置のキャッシュ３１１に記憶していない場合には、図１の（２）に示すように、データ検索要求をデータベースサーバ２００に送信する。その後、キャッシュサーバ３００は、図１の（３）に示すように、データ検索要求に対する応答となるデータ応答をデータベースサーバ２００から受信することで、データ要求により要求されたデータをデータベースサーバ２００から取得する。キャッシュサーバ３００は、受信したデータを自装置のキャッシュ３１１に格納した上で、図１の（４）に示すように、クライアント１００にデータ応答として送信する。

つまり、キャッシュサーバ３００は、データ要求を受信すると、データ要求に含まれる複数種類の特定情報各々の組み合わせがキャッシュ３１１に記憶されているかを判定する。ここで、キャッシュサーバ３００は、記憶されていないと判定した場合に、データ要求に含まれる組み合わせをデータベースサーバ２００に送信する。その後、データベースサーバ２００は、キャッシュサーバ３００により送信された組み合わせである組み合わせを受信すると、受信した組み合わせである受信組み合わせに相当する特定情報と非特定種類情報との組み合わせと、特定情報と非特定種類情報との組み合わせに対応付けられたデータとを記憶部から取得し、キャッシュサーバ３００に応答する。その後、キャッシュサーバ３００は、データベースサーバ２００により送信された特定情報と非特定種類情報との組み合わせがキャッシュ３１１に記憶されている場合には、記憶されていた特定情報と非特定種類情報との組み合わせに対応付けられるデータと対応付けて、受信組み合わせをキャッシュに格納する。また、キャッシュサーバ３００は、キャッシュ３１１に記憶されていない場合には、データベースサーバ２００により送信されたデータと対応付けて、データベースサーバ２００により送信された特定情報と非特定種類情報との組み合わせと、受信組み合わせとをキャッシュ３１１に格納する。また、キャッシュサーバ３００は、キャッシュ３１１に記憶されていると判定した場合には、キャッシュ３１１からデータを取得してデータ要求の送信元に送信し、キャッシュ３１１に記憶されていないと判定された場合には、データベースサーバ２００により送信されたデータをデータ要求の送信元に送信する。

また、キャッシュサーバ３００は、図１の（ａ）に示すように、ＩＲ情報を要求するＩＲ情報要求をデータベースサーバ２００に送信し、図１の（ｂ）に示すように、ＩＲ情報要求に対する応答であるＩＲ情報応答を受信する。すなわち、キャッシュサーバ３００は、自装置に対するＩＲ情報の有無を確認する。ここで、自装置に対するＩＲ情報がある場合とは、データベースサーバ２００に記憶されたデータが更新され、キャッシュサーバ３００のキャッシュ３１１に記憶されたデータが過去のデータとなっていることを示す。キャッシュサーバ３００は、ＩＲ情報がデータベースサーバ２００に存在する場合には、自装置のキャッシュ３１１に記憶された過去のデータをクライアント１００に送信しないよう、キャッシュ３１１に記憶されているデータを削除する。

また、キャッシュサーバ３００は、ＩＲ情報が自装置のキャッシュ３１１に適用された場合には、図１の（ｃ）に示すように、ＩＲ情報を削除する要求であるＩＲ情報削除要求をデータベースサーバ２００に送信する。その後、データベースサーバ２００では、キャッシュサーバ３００に適用されたＩＲ情報が削除され、キャッシュサーバ３００が、図１の（ｄ）に示すように、ＩＲ情報削除要求に対する応答であるＩＲ情報削除応答をデータベースサーバ２００から受信する。

［実施例１におけるデータベースサーバの構成］
図２は、実施例１におけるデータベースサーバの構成の一例を示すブロック図である。図２に示すように、データベースサーバ２００は、通信制御Ｉ／Ｆ部２０１と、記憶部２１０と、制御部２２０とを有する。

通信制御Ｉ／Ｆ部２０１は、制御部２２０と接続される。通信制御Ｉ／Ｆ部２０１は、キャッシュサーバ３００との間でやりとりする各種情報に関する通信を制御する。具体的には、通信制御Ｉ／Ｆ部２０１は、制御部２２０による制御に基づき、データ要求やＩＲ情報要求、ＩＲ情報削除要求をキャッシュサーバ３００に送信する。また、通信制御Ｉ／Ｆ部２０１は、制御部２２０による制御に基づき、キャッシュ３１１応答やＩＲ情報応答、ＩＲ情報削除応答をキャッシュサーバ３００に送信する。

記憶部２１０は、制御部２２０と接続される。記憶部２１０は、制御部２２０による各種処理に用いるデータを記憶する。記憶部２１０は、例えば、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）、フラッシュメモリ（Flash Memory）などの半導体メモリ素子、又は、ハードディスクや光ディスクなどである。図２に示す例では、記憶部２１０は、ユーザ情報ＤＢ２１１と、ＩＲ情報ＤＢ２１２とを有する。

ユーザ情報ＤＢ２１１は、少なくとも１種類の特定情報により特定されるデータごとに、該データを特定するための特定情報と、複数ある特定情報の種類のうちデータを特定する際に用いられない種類である非特定種類を示す非特定種類情報との組み合わせを記憶する。例えば、ユーザ情報ＤＢ２１１は、データごとに、データを特定する際に用いられる特定情報種類に属する特定情報と、非特定種類情報との組み合わせを記憶する。

例えば、ユーザ情報ＤＢ２１１は、キー情報と属性値とを対応付けて記憶する。属性値とは、クライアント１００により参照されるデータである。言い換えると、データ要求により要求される対象となるデータである。キー情報とは、属性値を一意に特定するための情報である。キー情報は、一つ又は複数の特定要素を含む。キー情報を「サービス特定情報」とも記載し、キー情報に含まれる要素各々を「サービス特定情報要素」や「特定情報」とも記載する。キー情報は、クライアント１００により送信されるデータ要求に含まれる。なお、データ要求には、複数の種類の特定情報が含まれており、データ要求に含まれる特定情報の全てがキー情報として用いられない場合もある。言い換えると、データ要求には、データを特定する際に用いられない種類である非特定種類に属する特定情報が含まれる場合もある。

なお、データ要求に含まれるキー情報に、Ｎ個の要素が含まれる場合を例に用いて、属性値とキー情報との関係について簡単に説明する。属性値には、Ｎ個の要素のうちＮ個の要素全てによって特定される属性値もあれば、Ｎ個の要素のうち一部の要素により特定される属性値もある。

図３は、実施例１におけるユーザ情報ＤＢに記憶された情報の一例を示す図である。図３に示すように、ユーザ情報ＤＢ２１１は、キー情報と属性値とを対応付けて記憶する。なお、図３に示す例では、キー情報に３つの要素が含まれる場合を示したが、これに限定されるものではなく、要素の数は任意であって良い。図３に示す例では、キー情報に含まれる３つの要素をそれぞれ「Ｋ１」「Ｋ２」「Ｋ３」と示した。なお、図３における「ＡＮＹ」は、任意の要素に合致することを示す。言い換えると、非特定種類であることを示す。「ＡＮＹ」を「ＡＮＹ要素」「非特定種類情報」とも記載する。同様に、図３に示す例では、キー情報ごとに一つの属性値が対応付けられた場合を示したが、これに限定されるものではなく、属性値の数は任意であって良い。

図３に示す例では、ユーザ情報ＤＢ２１１は、Ｋ１「ＳｅｒｖｉｃｅＮａｍｅ−００１」とＫ２「ＡＮＹ」とＫ３「ＡＮＹ」とを含むキー情報と、属性値「データ１」とを対応付けて記憶する。すなわち、ユーザ情報ＤＢ２１１は、キー情報が「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」や、「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＵｓｅｒＴｙｐｅ−００２、ＡｃｃｏｕｎｔＴｙｐｅ−００２」である場合には、属性値「データ１」が特定されることを記憶する。言い換えると、「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」や、「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＵｓｅｒＴｙｐｅ−００２、ＡｃｃｏｕｎｔＴｙｐｅ−００２」がキー情報に含まれるデータ要求がクライアント１００により送信された場合には、クライアント１００に属性値「データ１」が送信されることを記憶する。

また、図３に示す例では、ユーザ情報ＤＢ２１１は、Ｋ１「ＳｅｒｖｉｃｅＮａｍｅ−００２」とＫ２「ＵｓｅｒＴｙｐｅ−００１」とＫ３「ＡｃｃｏｕｎｔＴｙｐｅ−００１」とを含むキー情報と、属性値「データ１００」とを対応付けて記憶する。言い換えると、ユーザ情報ＤＢ２１１は、「ＡＮＹ」が含まれないキー情報に対応づけて属性値を記憶する。この場合、「ＳｅｒｖｉｃｅＮａｍｅ−００２」と「ＵｓｅｒＴｙｐｅ−００１」と「ＡｃｃｏｕｎｔＴｙｐｅ−００１」とをキー情報にデータ要求がクライアント１００により送信された場合に、クライアント１００に属性値「データ１００」が送信されることを記憶する。

ＩＲ情報ＤＢ２１２は、ＩＲ情報を記憶する。具体的には、ＩＲ情報ＤＢ２１２は、ＩＲ情報の適用先となるキャッシュサーバ３００を識別するキャッシュサーバ名と、更新された属性値を特定するキー情報とを含むＩＲ情報を記憶する。

図４は、実施例１におけるＩＲ情報ＤＢに記憶された情報の一例を示す図である。図４に示すように、ＩＲ情報ＤＢ２１２は、キャッシュサーバ名「キャッシュサーバＡ」と、Ｋ１「ＳｅｒｖｉｃｅＮａｍｅ−００１」とＫ２「ＡＮＹ」とＫ３「ＡＮＹ」とを含むキー情報とを含むＩＲ情報を記憶する。すなわち、ＩＲ情報ＤＢ２１２は、Ｋ１「ＳｅｒｖｉｃｅＮａｍｅ−００１」とＫ２「ＡＮＹ」とＫ３「ＡＮＹ」とにより特定される属性値が更新されたことを示し、キャッシュサーバＡに適用されるＩＲ情報を記憶する。

ＩＲ情報ＤＢ２１２に記憶されるＩＲ情報は、ユーザ情報ＤＢ２１１が更新される際に格納され、キャッシュサーバ３００に適用された後に削除される。

制御部２２０は、通信制御Ｉ／Ｆ部２０１及び記憶部２１０と接続される。制御部２２０は、ＯＳ（Operating System）などの制御プログラム、各種の処理手順などを規定したプログラム及び所要データなどを格納するための内部メモリを有し、種々の処理を制御する。制御部２２０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）などである。図２に示す例では、制御部２２０は、キャッシュ応答部２２１と、ＩＲ情報応答部２２２と、ＩＲ情報削除部２２３と、ユーザ情報更新部２２４とを有する。

キャッシュ応答部２２１は、キャッシュサーバ３００からデータ検索要求を受信すると、データ検索要求に含まれるキー情報が、ユーザ情報ＤＢ２１１に記憶されているか否かを判定する。言い換えると、キャッシュ応答部２２１は、ユーザ情報ＤＢ２１１を検索することで、データ検索要求に含まれるキー情報と一致するレコードを検索結果として取得する。

例えば、キー情報にサービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）が含まれる場合には、キャッシュ応答部２２１は、ユーザ情報ＤＢ２１１を検索することで、サービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）に相当するキー情報を含むレコードを検索結果とする。

なお、ユーザ情報ＤＢ２１１は、特定情報として「ＡＮＹ」を記憶する場合がある。この結果、サービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）に相当するキー情報を含むレコードが複数ある場合がある。このことを踏まえ、キャッシュ応答部２２１は、複数のレコードのうち優先するレコードを決定するための判定表である応答データ判定表を生成し、生成した応答データ判定表と合致するレコード全てをユーザ情報ＤＢ２１１から検索した上で、最も優先度の高いレコードを一つ検索結果として選択する。

図５は、実施例１におけるキャッシュ応答部により用いられる応答データ判定表の一例を示す図である。図５に示す例では、サービス特定情報要素として、「Ｋ１」「Ｋ２」「Ｋ３」とがキー情報に含まれる場合を例に示した。言い換えると、例えば、ユーザ情報ＤＢ２１１に記憶されているデータのうち、「Ｋ１」「Ｋ２」「Ｋ３」をキー情報として含むレコードだけでなく、「Ｋ１」「Ｋ２」「ＡＮＹ」をキー情報として含むレコードや、「Ｋ１」「ＡＮＹ」「Ｋ３」をキー情報として含むレコード、「Ｋ１」「ＡＮＹ」「ＡＮＹ」をキー情報として含むレコードなどについても検索結果となる場合を例に示した。図５に示す例では、応答データ判定表に記憶されたサービス特定情報要素の組み合わせのうち検索結果となり得る組み合わせと、優先度とが対応付けられた表となる。図５に示す例では、優先度の数字が大きければ大きい程、優先して検索結果とする場合を示した。すなわち、図５に示す例では、「Ｋ１」「Ｋ２」「Ｋ３」をキー情報として含むレコードが検索結果となる場合には、かかるレコードが検索結果とされることを示す。次に、「Ｋ１」「Ｋ２」「ＡＮＹ」をキー情報として含むレコードが検索結果となる場合には、かかるレコードが検索結果とされることを示す。

なお、図５に示す例では、キャッシュ応答部２２１が、応答データ判定表を用いて検索結果を一つ選択する場合を示したが、キャッシュ応答部２２１による処理はこれに限定されるものではなく、任意の手法を用いて良い。例えば、データ問い合わせ言語などで実現しても良い。

ここで、図３に示すユーザ情報ＤＢ２１１と図５に示す応答データ判定表とを用いて、詳細な一例を説明する。また、キャッシュサーバ３００からのデータ検索要求に含まれるキー情報が、「ＳｅｒｖｉｃｅＮａｍｅ−００３、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎＴｙｐｅ−００３」である場合を用いて説明する。この場合、キャッシュ応答部２２１は、図５の応答データ判定表を用いてユーザ情報ＤＢ２１１を検索することで、優先度「４」の「ＳｅｒｖｉｃｅＮａｍｅ−００３、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎＴｙｐｅ−００３、データ１０５」を含むレコードと、優先度「３」の「ＳｅｒｖｉｃｅＮａｍｅ−００３、ＵｓｅｒＴｙｐｅ−００１、ＡＮＹ、データ１０」を含むレコードとが得られる。ここで、図５に示す応答データ判定表では、優先度「４」は優先度「３」と比較して高優先として扱われることとなり、キャッシュ応答部２２１は、検索結果として、「ＳｅｒｖｉｃｅＮａｍｅ−００３、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎＴｙｐｅ−００３、データ１０５」を含むレコードを選択する。

キャッシュ応答部２２１は、キャッシュサーバ３００から受信したデータ検索要求に含まれるキー情報に相当するレコードをユーザ情報ＤＢ２１１が記憶している場合には、ユーザ情報ＤＢ２１１に記憶されたレコードを取得し、キャッシュサーバ３００にデータ応答として送信する。例えば、キャッシュ応答部２２１は、検索結果となるレコードのキー情報と属性値とをユーザ情報ＤＢ２１１から取得し、データ応答をキャッシュサーバ３００に送信する。また、キャッシュ応答部２２１は、キャッシュサーバ３００から受信したデータ検索要求に含まれるキー情報を含むレコードをユーザ情報ＤＢ２１１が記憶していない場合には、「キー情報なし」をキャッシュサーバ３００に応答する。

なお、キャッシュ応答部２２１により送信されるデータ応答に含まれるキー情報は、データ検索要求に含まれるキー情報とは異なるキー情報と同一とはならない場合がある。例えば、キャッシュ応答部２２１が、ユーザ情報ＤＢ２１１から「ＡＮＹ」を含むレコードを検索結果として選択した場合には、データ検索要求に含まれるキー情報と同一とはならない。データ検索要求に含まれるキー情報には「ＡＮＹ」は含まれないからである。このことを踏まえ、以下では、データ応答に含まれるキー情報に含まれる特定情報各々について、「部分特定情報要素」「Ｄ１」「Ｄ２」「Ｄ３」などと記載する。

上述したように、キャッシュ応答部２２１は、キャッシュサーバ３００により送信されたデータ検索要求に含まれる特定情報の組み合わせを受信すると、受信した組み合わせである受信組み合わせに相当する特定情報と非特定種類情報との組み合わせと、特定情報と非特定種類情報との組み合わせに対応付けられたデータとをユーザ情報ＤＢ２１１から取得し、キャッシュサーバ３００に応答する。より詳細には、キャッシュ応答部２２１は、キャッシュサーバ３００により送信された受信組み合わせを受信すると、組み合わせに相当する特定情報と非特定種類情報との組み合わせ各々のうち一つを選択し、選択した特定情報と非特定種類情報との組み合わせと、選択した組み合わせに対応付けて記憶されたデータとを送信する。

ＩＲ情報応答部２２２は、キャッシュサーバ３００からＩＲ情報要求を受信すると、ＩＲ情報要求の送信元となるキャッシュサーバ３００のキャッシュサーバ名を含むＩＲ情報がＩＲ情報ＤＢ２１２に記憶されているか否かを判定する。そして、ＩＲ情報応答部２２２は、ＩＲ情報ＤＢ２１２に記憶されていると判定した場合には、送信元となるキャッシュサーバ名を含む全てのＩＲ情報から、キー情報を取得し、取得したキー情報を含むＩＲ情報応答をキャッシュサーバ３００に送信する。ここで、ＩＲ情報応答に含まれるキー情報は、ユーザ情報ＤＢ２１１において更新された属性値を特定するキー情報となる。また、ＩＲ情報応答部２２２は、ＩＲ情報ＤＢ２１２に記憶されていないと判定した場合には、「ＩＲ情報なし」をキャッシュサーバ３００に応答する。

ＩＲ情報削除部２２３は、キャッシュサーバ３００からＩＲ情報削除要求を受信すると、ＩＲ情報削除要求の送信元となるキャッシュサーバ３００のキャッシュサーバ名を含むＩＲ情報をＩＲ情報ＤＢ２１２から削除し、削除結果をキャッシュサーバ３００に応答する。

ユーザ情報更新部２２４は、ユーザ情報ＤＢ２１１が更新されるごとに、更新されたレコードを示すキー情報と、データベースサーバ２００に接続されたキャッシュサーバ３００のキャッシュサーバ名とを含むＩＲ情報を生成してＩＲ情報ＤＢ２１２に格納する。ユーザ情報ＤＢ２１１が更新される場合とは、例えば、利用者によって、ユーザ情報ＤＢ２１１に記憶されたレコードが更新された場合や、ユーザ情報ＤＢ２１１に新たなレコードが追加された場合や、ユーザ情報ＤＢ２１１に記憶されたレコードが削除された場合などが該当する。

［実施例１におけるキャッシュサーバの構成］
図６は、実施例１におけるキャッシュサーバの構成の一例を示す図である。図６に示す例では、キャッシュサーバ３００は、通信制御Ｉ／Ｆ部３０１と、記憶部３１０と、制御部３２０を有する。

通信制御Ｉ／Ｆ部３０１は、制御部３２０と接続される。通信制御Ｉ／Ｆ部３０１は、データベースサーバ２００、クライアント１００との間でやりとりする各種情報に関する通信を制御する。具体的には、通信制御Ｉ／Ｆ部３０１は、制御部３２０による制御に基づき、クライアント１００からデータ要求を受信し、データ応答をクライアント１００に送信する。また、通信制御Ｉ／Ｆ部３０１は、制御部３２０による制御に基づき、データベースサーバ２００にデータ検索要求やＩＲ情報要求、ＩＲ情報削除要求を送信しデータ応答やＩＲ情報応答、ＩＲ情報削除応答を受信する。

記憶部３１０は、制御部３２０と接続される。記憶部３１０は、制御部３２０による各種処理に必要なデータ及びプログラムを格納する。記憶部３１０は、例えば、キャッシュ３１１が該当する。図６に示す例では、記憶部３１０は、キャッシュ３１１を有する。

キャッシュ３１１は、データベースサーバ２００のユーザ情報ＤＢ２１１に記憶された情報のうち一部を記憶する。つまり、キャッシュ３１１は、データベースに記憶されたデータの少なくとも一部について、特定情報と非特定種類情報との組み合わせと、複数種類の特定情報の組み合わせとのうち少なくとも一つと対応付けて記憶する。具体的には、ユーザ情報ＤＢ２１１に記憶された情報のうち、キャッシュサーバ３００により用いられたデータのキャッシュを記憶する。以下では、オープンハッシュ法によるデータ構造を例に説明する。

図７−１〜図７−３は、実施例１におけるキャッシュに記憶された情報の一例を示す図である。図７に示す例では、キャッシュ３１１が、ハッシュテーブルと、レコードテーブルと、属性情報テーブルとを有する場合を示した。図７−１〜図７−３は、ハッシュテーブルと、レコードテーブルと、属性情報テーブルとの一例を示す。それぞれ、図７−１〜図７−３に示すように、ハッシュテーブルと、レコードテーブルと、属性情報テーブルとは、「レコードＩＤ」と「属性情報ＩＤ」とによって連結される。言い換えると、図７−１〜図７−３に示す例では、キャッシュ３１１において、「レコードＩＤ」と「属性情報ＩＤ」とは、キャッシュ３１１に記憶されたデータを識別するためのデータとして用いられる。ただし、これに限定されるものではなく、任意の手法を用いて良く、例えば、レコードごとのメモリ上のアドレスなどを用いても良い。

図７−１に示す例では、ハッシュテーブルは、「ハッシュ値」と「レコードＩＤ」とを対応付けて記憶する。ここで、ハッシュテーブルに記憶されたハッシュ値は、キー情報を所定のハッシュ関数を用いて変換した値である。ハッシュテーブルに記憶されたレコードＩＤは、ハッシュテーブルとレコードテーブルとの連結に用いられる。図７−１に示す例では、ハッシュテーブルは、ハッシュ値「０」に対応付けてレコードＩＤ「０」を記憶する。また、同様に、ハッシュテーブルは、ハッシュ値「１」に対応付けてレコードＩＤ「１」を記憶する。

図７−２に示すように、レコードテーブルは、「レコードＩＤ」とキー情報と「属性情報ＩＤ」とを対応付けて記憶する。レコードテーブルに記憶されたレコードＩＤは、ハッシュテーブルに記憶されたレコードＩＤと対応する。「属性情報ＩＤ」は、レコードテーブルと属性情報テーブルとの連結に用いられる。図７−２に示す例では、レコードテーブルは、レコードＩＤ「０」と、Ｋ１「ＳｅｒｖｉｃｅＮａｍｅ−００１」とＫ２「ＡＮＹ」とＫ３「ＡＮＹ」とを含むキー情報と、属性情報ＩＤ「０」とを対応付けて記憶する。

図７−３に示すように、属性情報テーブルは、「属性情報ＩＤ」と、「属性値」と、属性値の有効期限を示す「有効期限」と「参照元レコード一覧」とを対応付けて記憶する。ここで、「参照元レコード一覧」は、同一の属性情報ＩＤに対応付けられたレコードテーブルに含まれるレコードのレコードＩＤの一覧を示す。参照元レコード一覧は、可変長配列のような、複数の要素を含むことのできる構造をとる。図７−３に示す例では、属性情報テーブルは、属性情報ＩＤ「０」と属性値「１」と有効期限「２０１１／１／１」と参照元レコード一覧「０、１」とを対応付けて記憶する。なお、有効期限は、例えば、キャッシュ３１１にレコードが追加される時点から一定期間後の期日が用いられる。ただし、これに限定されるものではなく、任意の期日を用いて良い。

なお、図７では、ハッシュテーブルの構造として、オープンハッシュ法を用いて記憶させる例を示したが、データ構造はこれに限るものではない。例えば、クローズドハッシュ法を用いても良い。また、図７に示す例では、キー情報が３個、属性値が１個の情報である場合を図示しているが、これに限定されるものではなく、任意の数の情報によって構成されても良い。

制御部３２０は、通信制御Ｉ／Ｆ部３０１及び記憶部３１０と接続される。制御部３２０は、ＯＳなどの制御プログラム、各種の処理手順などを規定したプログラム及び所要データを格納するための内部メモリを有し、種々の処理を制御する。制御部３２０は、例えば、ＡＳＩＣ、ＦＰＧＡ、ＣＰＵ、ＭＰＵなどである。また、図６に示す例では、制御部３２０は、キャッシュ判定部３２１と、ＩＲ情報判定部３２２と、応答処理部３２３とを有する。

キャッシュ判定部３２１は、クライアント１００からデータ要求を受信すると、受信したデータ要求に含まれるサービス特定情報要素を取得し、取得したサービス特定情報要素をキー情報としてキャッシュ３１１を検索する。つまり、キャッシュ判定部３２１は、データ要求を受信すると、データ要求に含まれる複数種類の特定情報各々の組み合わせがキャッシュ３１１に記憶されているかを判定する。

また、キャッシュ判定部３２１は、判定結果に応じて、以下に説明する処理を実行する。具体的には、キャッシュ判定部３２１は、キャッシュ３１１に記憶されていないと判定した場合に、データ要求に含まれる組み合わせをデータベースサーバ２００に送信する。その後、キャッシュ判定部３２１は、データベースサーバ２００により送信された特定情報と非特定種類情報との組み合わせを受信する。ここで、キャッシュ判定部３２１は、データベースサーバ２００により送信された特定情報と非特定種類情報との組み合わせがキャッシュ３１１に記憶されている場合には、記憶されていた特定情報と非特定種類情報との組み合わせに対応付けられるデータと対応付けて、受信組み合わせをキャッシュ３１１に格納する。一方、キャッシュ判定部３２１は、キャッシュに記憶されていない場合には、データベースサーバ２００により送信されたデータと対応付けて、データベースサーバ２００により送信された特定情報と非特定種類情報との組み合わせと、受信組み合わせとをキャッシュ３１１に格納する。

また、キャッシュ判定部３２１は、キャッシュ３１１に記憶されていると判定した場合には、キャッシュ３１１からデータを取得してデータ要求の送信元に送信する。また、キャッシュ判定部３２１は、キャッシュ３１１に記憶されていないと判定した場合には、データベースサーバ２００により送信されたデータをデータ要求の送信元に送信する。なお、キャッシュ判定部３２１は、「判定部」や「特定情報送信部」、「格納部」「データ送信部」とも称する。

ここで、キャッシュ判定部３２１は、キャッシュ３１１の検索結果に応じて実行する一連の処理について、場合分けした上で、更に具体的に説明する。

以下では、まず、キャッシュ３１１にキー情報が記憶されていた場合における処理について説明する。次に、キャッシュ判定部３２１による処理のうち、キャッシュ３１１にキー情報が記憶されておらず、データベースサーバ２００から属性情報を取得できた場合における処理について説明する。続いて、キャッシュ判定部３２１による処理のうち、キャッシュ３１１にキー情報が記憶されておらず、データベースサーバ２００から属性情報を取得できなかった場合における処理について説明する。

キャッシュ判定部３２１による処理のうち、キャッシュ３１１にキー情報が記憶されていた場合における処理について説明する。この場合、キャッシュ判定部３２１は、キャッシュ３１１に記憶されていたキー情報に対応する属性値をキャッシュ３１１から取得し、データ応答をクライアント１００に送信する。

なお、ここで、キャッシュ判定部３２１は、取得した属性値に対応付けられた有効期限が有効期限切れとなっている場合には、データ応答を実行することなく、該当するレコードを削除する処理を実行する。キャッシュ判定部３２１は、取得した属性値に対応付けられたキー情報全てをキャッシュ３１１から特定し、特定したキー情報と属性値とを削除する。例えば、キャッシュ判定部３２１は、属性情報ＩＤ「２」に対応付けられた参照元レコード一覧に含まれるレコードＩＤ「３」を取得し、取得したレコードＩＤを含むレコードをキャッシュ３１１のレコードテーブルから削除する。この場合、その後、後述するキャッシュ３１１にキー情報が記憶されていない場合の処理を行う。

図３と図７を用いて具体的に説明する。また、クライアント１００から受信したデータ要求にＫ１「ＳｅｒｖｉｃｅＮａｍｅ−００２」とＫ２「ＵｓｅｒＴｙｐｅ−００１」とＫ３「ＡｃｃｏｕｎｔＴｙｐｅ−００２」とが含まれていた場合を用いて説明する。この場合、キャッシュ判定部３２１は、キー情報となる「ＳｅｒｖｉｃｅＮａｍｅ−００２、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００２」からハッシュ値を算出する。以下では、ハッシュ値「Ｂ−１」が算出されたものとして説明する。キャッシュ判定部３２１は、ハッシュ値「Ｂ−１」を用いてキャッシュ３１１のハッシュテーブルを検索することで、レコードＩＤ「３」を取得する。そして、キャッシュ判定部３２１は、レコードＩＤ「３」を用いてキャッシュ３１１のレコードテーブルを検索し、検索結果となるレコードに含まれるキー情報と、クライアント１００からのデータ要求から取得したキー情報とを比較し、検索対象となるキー情報が既に記憶されていると判定する。その後、キャッシュ判定部３２１は、キャッシュ３１１のレコードテーブルに記憶されたレコードのうち、レコードＩＤ「３」を含むレコードから属性情報ＩＤ「２」を取得し、キャッシュ３１１の属性情報テーブルから属性情報ＩＤ「２」に対応付けられた属性値「データ１０１」を取得する。また、キャッシュ判定部３２１は、取得した属性値「データ１０１」を応答処理部３２３に出力する。

なお、ここで、キャッシュ判定部３２１は、属性情報ＩＤ「２」に対応付けられた有効期限が有効期限切れとなっていた場合には、キャッシュを削除する処理を実行する。その後、後述するキャッシュ３１１にキー情報が記憶されていない場合の処理を行う。

次に、キャッシュ判定部３２１による処理のうち、キャッシュ３１１にキー情報が記憶されておらず、データベースサーバ２００から属性情報を取得できた場合における処理について説明する。すなわち、例えば、キャッシュ３１１にキー情報が記憶されていた場合における処理において説明したように、キャッシュ判定部３２１は、検索対象となるキー情報が既に記憶されていると判定する。この際、クライアント１００からのデータ要求から取得したキー情報が記憶されていないと判定する場合が該当する。

この場合、キャッシュ判定部３２１は、データ要求から取得したキー情報を含むデータ検索要求をデータベースサーバ２００に送信する。例えば、キャッシュ判定部３２１は、サービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）を含むデータ検索要求をデータベースサーバ２００に送信する。その後、キャッシュ判定部３２１は、データベースサーバ２００から、データ検索結果として、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）と属性値とを含むデータ応答を受信する。

ここで、受信したデータ応答に含まれる部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）が、自装置のキャッシュ３１１にキー情報として既に記憶されている場合について説明する。この場合、キャッシュ判定部３２１は、データ要求から取得したサービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）を、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）に対応付けて既に記憶されていた属性値に対応付けてキャッシュ３１１に格納する。より詳細な一例をあげて説明すると、キャッシュ判定部３２１は、データ要求から取得したサービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）をキー情報とし、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）に対応付けて既に記憶されていた属性値と、新たに付与したレコードＩＤとを含むレコードをキャッシュ３１１のレコードテーブルに格納する。また、キャッシュ判定部３２１は、新たに付与したレコードＩＤを、サービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）から算出したハッシュ値に対応付けてハッシュテーブルに格納する。また、キャッシュ判定部３２１は、キャッシュ３１１の属性情報テーブルに記憶されたレコードのうち、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）に対応付けて既に記憶されていた属性値を含むレコードについて、「参照元レコード一覧」に、新たに付与したレコードＩＤを追加する。そして、キャッシュ判定部３２１は、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）に対応付けて既に記憶されていた属性値を応答処理部３２３に出力する。

図３と図７を用いて具体的に説明する。また、クライアント１００から受信したデータ要求にＫ１「ＳｅｒｖｉｃｅＮａｍｅ−００１」とＫ２「ＵｓｅｒＴｙｐｅ−００１」とＫ３「ＡｃｃｏｕｎｔＴｙｐｅ−００２」とが含まれていた場合を用いて説明する。この場合、キャッシュ判定部３２１は、キー情報となるＫ１「ＳｅｒｖｉｃｅＮａｍｅ−００１」とＫ２「ＵｓｅｒＴｙｐｅ−００１」とＫ３「ＡｃｃｏｕｎｔＴｙｐｅ−００２」とからハッシュ値を算出する。以下では、ハッシュ値「２」が算出されたものとして説明する。今回の場合、キャッシュ３１１のハッシュテーブルは、ハッシュ値「２」に対応付けられたレコードＩＤを記憶していないため、キャッシュ判定部３２１は、Ｋ１「ＳｅｒｖｉｃｅＮａｍｅ−００１」とＫ２「ＵｓｅｒＴｙｐｅ−００１」とＫ３「ＡｃｃｏｕｎｔＴｙｐｅ−００２」とを含めた上でデータ検索要求をデータベースサーバ２００に送信する。その後、例えば、キャッシュ判定部３２１は、データベースサーバ２００から、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）として、「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＡＮＹ、ＡＮＹ」とを含み、属性値「データ１」とを含むデータ応答を受信する。その後、キャッシュ判定部３２１は、部分特定要素（Ｄ１、Ｄ２、Ｄ３）からハッシュ値をキー情報として、自装置のキャッシュ３１１のハッシュテーブルを検索する。ここで、キャッシュ判定部３２１は、レコードＩＤ「０」が得られた場合には、部分特定要素（Ｄ１、Ｄ２、Ｄ３）がキー情報として既に記憶されていると判定することとなる。この結果、キャッシュ判定部３２１は、例えば、レコードＩＤ「０」を用いて、キャッシュ３１１のレコードテーブルから属性情報ＩＤ「０」を取得する。そして、キャッシュ判定部３２１は、キャッシュ３１１のレコードテーブルに、新たに付与したレコードＩＤ「４」と、Ｋ１「ＳｅｒｖｉｃｅＮａｍｅ−００１」とＫ２「ＵｓｅｒＴｙｐｅ−００１」とＫ３「ＡｃｃｏｕｎｔＴｙｐｅ−００２」と、属性情報ＩＤ「０」とを含む新たなレコードをキャッシュ３１１のレコードテーブルに格納する。また、キャッシュ判定部３２１は、Ｋ１「ＳｅｒｖｉｃｅＮａｍｅ−００１」とＫ２「ＵｓｅｒＴｙｐｅ−００１」とＫ３「ＡｃｃｏｕｎｔＴｙｐｅ−００２」により算出されるハッシュ値が「２」である場合には、キャッシュ３１１のハッシュテーブルに対して、ハッシュ値「２」に対応付けてレコードＩＤ「４」を格納する。また、キャッシュ判定部３２１は、キャッシュ３１１の属性情報テーブルのうち、属性情報ＩＤ「０」を含むレコードの参照元レコード一覧にレコードＩＤ「４」を追加する。その後、キャッシュ判定部３２１は、属性情報ＩＤ「０」に対応付けられた属性値「データ１」を取得し、応答処理部３２３に出力する。

図８−１〜図８−３は、実施例１におけるキャッシュ判定部によりレコードが追加された後のキャッシュに記憶された情報の一例を示す図である。図８−１〜図８−３は、それぞれ、図７−１〜図７−３に対応する。なお、図８−１〜図８−３に示す例では、レコードＩＤ「４」に加えて、レコードＩＤ「５」「６」についても追加されている場合を示した。

なお、属性情報ＩＤ「２」に対応付けられた有効期限が有効期限切れとなっていた場合には、参照元レコード一覧に含まれるレコードＩＤ「０」「１」「３」に対応するレコードを、キャッシュ３１１のレコードテーブルやハッシュテーブルから削除し、属性情報ＩＤ「２」を含むレコードを属性情報テーブルから削除する。

ここで、受信したデータ応答に含まれる部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）が、自装置のキャッシュ３１１にキー情報として既に記憶されていなかった場合について説明する。この場合、キャッシュ判定部３２１は、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）と、データベースサーバ２００から取得した属性値を対応付けて、自装置のキャッシュ３１１に格納する。その後、キャッシュ判定部３２１は、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）に対応付けて格納した属性値を、サービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）に対応させてキャッシュ３１１にレコードを格納し、属性値を応答処理部３２３に出力する。

図３と図８を用いて具体的に説明する。また、クライアント１００から受信したデータ要求にＫ１「ＳｅｒｖｉｃｅＮａｍｅ−００３」とＫ２「ＵｓｅｒＴｙｐｅ−００１」とＫ３「ＡｃｃｏｕｎｔＴｙｐｅ−００１」とが含まれていた場合を用いて説明する。この場合、キャッシュ判定部３２１は、キー情報となるＫ１「ＳｅｒｖｉｃｅＮａｍｅ−００３」とＫ２「ＵｓｅｒＴｙｐｅ−００１」とＫ３「ＡｃｃｏｕｎｔＴｙｐｅ−００１」とからハッシュ値を算出する。以下では、ハッシュ値「３」が算出されたものとして説明する。今回の場合、キャッシュ３１１のハッシュテーブルは、ハッシュ値「３」に対応付けられたレコードＩＤを記憶していないため、キャッシュ判定部３２１は、Ｋ１「ＳｅｒｖｉｃｅＮａｍｅ−００３」とＫ２「ＵｓｅｒＴｙｐｅ−００１」とＫ３「ＡｃｃｏｕｎｔＴｙｐｅ−００１」とを含めた上でデータ検索要求をデータベースサーバ２００に送信する。その後、例えば、キャッシュ判定部３２１は、データベースサーバ２００から、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）として、「ＳｅｒｖｉｃｅＮａｍｅ−００３、ＵｓｅｒＴｙｐｅ−００１、ＡＮＹ」を含み、属性値「データ１０」を含むデータ応答を受信する。その後、キャッシュ判定部３２１は、部分特定要素（Ｄ１、Ｄ２、Ｄ３）からハッシュ値をキー情報として、自装置のキャッシュ３１１のハッシュテーブルを検索する。ここで、キャッシュ判定部３２１は、レコードＩＤ「３」が得られない場合には、部分特定要素（Ｄ１、Ｄ２、Ｄ３）がキー情報として既に記憶されていないと判定することとなる。この結果、キャッシュ判定部３２１は、新たに付与した属性情報ＩＤ「３」と属性値「データ１０」とを含むレコードをキャッシュ３１１の属性情報テーブルに格納する。また、キャッシュ判定部３２１は、キャッシュ３１１のレコードテーブルに対して、新たに付与したレコード「５」と、キー情報として部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）「ＳｅｒｖｉｃｅＮａｍｅ−００３、ＵｓｅｒＴｙｐｅ−００１、ＡＮＹ」と、属性情報ＩＤ「３」とを含むレコードを新たに格納する。また、キャッシュ判定部３２１は、キャッシュ３１１のハッシュテーブルに対して、新たに格納したレコードＩＤ「５」をハッシュ値「４」に対応付けて格納する。その後、キャッシュ判定部３２１は、キャッシュ３１１のレコードテーブルに対して、新たに付与したレコード「５」と、データ要求に含まれるキー情報（Ｋ１、Ｋ２、Ｋ３）「ＳｅｒｖｉｃｅＮａｍｅ−００３、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」、属性情報ＩＤ「３」とを含むレコードを格納する。また、キャッシュ判定部３２１は、キャッシュ３１１のハッシュテーブルに対して、データ要求に含まれるキー情報（Ｋ１、Ｋ２、Ｋ３）から算出されたハッシュ値が「３」である場合には、ハッシュ値「３」に対応付けてレコードＩＤ「６」を対応付けて格納する。その後、キャッシュ判定部３２１は、属性情報ＩＤ「３」の属性情報から、属性値「データ１０」を取得し、応答処理部３２３に出力する。

最後に、キャッシュ判定部３２１による処理のうち、キャッシュ３１１にキー情報が記憶されておらず、データベースサーバ２００から属性情報を取得できなかった場合における処理について説明する。この場合、キャッシュ判定部３２１は、「データなし」をクライアント１００に送信する。

ＩＲ情報判定部３２２は、データベースサーバ２００にＩＲ情報要求を送信する。例えば、ＩＲ情報判定部３２２は、定期的にＩＲ情報要求を送信したり、任意のタイミングにてＩＲ情報要求を送信したりする。また、ＩＲ情報判定部３２２は、ＩＲ情報要求に対するＩＲ情報をデータベースサーバ２００から受信することで、データベースサーバ２００から、自キャッシュサーバ３００向けのＩＲ情報として、ユーザ情報ＤＢ２１１に記憶された属性値のうち更新された属性値を示す「キー情報（Ｋ１、Ｋ２、Ｋ３）」を取得する。

ＩＲ情報判定部３２２は、データベースサーバ２００から受信したＩＲ情報を用いて、キャッシュ３１１を更新する。つまり、ＩＲ情報判定部３２２は、キャッシュ３１１情報の最新化を行う。ＩＲ情報に含まれるキー情報が（Ｋ１、Ｋ２、Ｋ３）である場合を用いて説明する。ＩＲ情報判定部３２２は、ＩＲ情報の「キー情報（Ｋ１、Ｋ２、Ｋ３）」に基づき、自装置のキャッシュ３１１にキー情報（Ｋ１、Ｋ２、Ｋ３）と一致するキー情報が記憶されている場合には、自装置のキャッシュ３１１から「キー情報（Ｋ１、Ｋ２、Ｋ３）」と、「キー情報（Ｋ１、Ｋ２、Ｋ３）」に対応付けられた「属性値」とを削除する。つまり、ＩＲ情報判定部３２２は、後述するキャッシュ削除処理を実行したり、キャッシュ判定部３２１にキャッシュ削除処理を実行させたりする。

また、ＩＲ情報判定部３２２は、ＩＲ情報に基づいてキャッシュ３１１を更新すると、ＩＲ情報に含まれるキー情報を含むＩＲ情報削除要求をデータベースサーバ２００に送信することで、データベースサーバ２００から受信したＩＲ情報をデータベースサーバ２００から削除する。

図８を用いて具体的に説明する。また、ＩＲ情報に含まれるキー情報（Ｋ１、Ｋ２、Ｋ３）が、「ＳｅｒｖｉｃｅＮａｍｅ−００１、Ｕｓｅｒ Ｔｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」である場合を用いて説明する。言い換えると、「ＳｅｒｖｉｃｅＮａｍｅ−００１、Ｕｓｅｒ Ｔｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」により特定される属性値が、更新されたか、新たに格納された場合を用いて説明する。この場合、例えば、ＩＲ情報判定部３２２は、最初に、キー情報からハッシュ値を算出する。以下では、ハッシュ値「１」が算出された場合を用いて説明する。ＩＲ情報判定部３２２は、ハッシュ値「１」に対応するレコードＩＤ「１」をキャッシュ３１１のハッシュテーブルから取得し、レコードＩＤ「１」に対応するレコードをキャッシュ３１１のレコードテーブルから取得する。そして、ＩＲ情報判定部３２２は、レコードＩＤ「１」を含むレコードをキャッシュ３１１のレコードテーブルから削除する。また、ＩＲ情報判定部３２２は、このタイミングにて、ハッシュテーブルからも、該当のレコードを削除するという動作を行う。また、ＩＲ情報判定部３２２は、取得したレコードＩＤ「１」を含むレコード内にある属性情報ＩＤ「０」を取得し、属性情報ＩＤ「０」を含むレコードをキャッシュ３１１の属性情報テーブルから取得し、参照元レコード一覧からレコードＩＤ「１」を削除する。ここで、上述した例では、属性情報テーブルから取得したレコードの参照元レコード一覧には、レコードＩＤ「０」「４」が残っており、ＩＲ情報判定部３２２は、属性情報テーブルから取得したレコードそのものは削除しない。ただし、ＩＲ情報判定部３２２は、参照元レコード一覧からレコードＩＤを削除することで、参照元レコードＩＤ一覧にレコードＩＤが存在しなくなる場合には、取得したレコードそのものを属性情報テーブルから削除する。また、ＩＲ情報判定部３２２は、データベースサーバ２００に、キー情報として「ＳｅｒｖｉｃｅＮａｍｅ−００１、Ｕｓｅｒ Ｔｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」を含むＩＲ情報削除要求を送信する。

ここで、キー情報（Ｋ１、Ｋ２、Ｋ３）にＡＮＹ要素が含まれている場合について説明する。この場合、ＩＲ情報に含まれるキー情報により示される属性値に、複数のレコードが対応付けられていることがある。このことを踏まえ、ＩＲ情報判定部３２２は、削除対象の属性値の参照元レコード一覧を用いて、ＩＲ情報に含まれるキー情報により示される属性値を参照する全てのキー情報を削除する。

例えば、ＩＲ情報に含まれるキー情報（Ｋ１、Ｋ２、Ｋ３）が、「ＳｅｒｖｉｃｅＮａｍｅ−００３、Ｕｓｅｒ Ｔｙｐｅ−００１、ＡＮＹ」である場合を用いて説明する。言い換えると、「ＳｅｒｖｉｃｅＮａｍｅ−００３、Ｕｓｅｒ Ｔｙｐｅ−００１、ＡＮＹ」により特定される属性値が、更新されたか、新たに格納された場合を用いて説明する。この場合、ＩＲ情報判定部３２２は、最初に、キー情報からハッシュ値を算出する。以下では、ハッシュ値「４」が算出された場合を用いて説明する。ＩＲ情報判定部３２２は、ハッシュ値「４」に対応するレコードＩＤ「５」をキャッシュ３１１のハッシュテーブルから取得し、レコードＩＤ「５」に対応するレコードをキャッシュ３１１のレコードテーブルから取得する。そして、ＩＲ情報判定部３２２は、取得したレコードに含まれる属性情報ＩＤ「３」を取得し、属性情報ＩＤ「３」を含むレコードをキャッシュ３１１の属性情報テーブルから取得する。そして、ＩＲ情報判定部３２２は、属性情報テーブルから取得したレコードの参照元レコード一覧に含まれるレコードＩＤ「５」「６」のレコードを、キャッシュ３１１のレコードテーブルから削除する。また、ＩＲ情報判定部３２２は、このタイミングにて、ハッシュテーブルからも、該当のレコード（レコードＩＤ「５」「６」のレコード）を削除するという動作を行う。また、ＩＲ情報判定部３２２は、属性情報テーブルから、属性情報ＩＤ「３」のレコードを削除する。その後、ＩＲ情報判定部３２２は、データベースサーバ２００に、キー情報として「ＳｅｒｖｉｃｅＮａｍｅ−００３、Ｕｓｅｒ Ｔｙｐｅ−００１、ＡＮＹ」を含むＩＲ情報削除要求を送信する。

応答処理部３２３は、キャッシュ判定部３２１から受信した属性値をクライアント１００に送信する。具体的には、応答処理部３２３は、キャッシュ判定部３２１から受信した属性値と、クライアント１００から受信したデータ要求に含まれるキー情報とを含むデータ応答をクライアント１００に送信する。なお、上述した説明では、応答処理部３２３が、クライアント１００から受信したデータ要求に含まれるキー情報を含むデータ応答を送信する場合を例に示したが、これに限定されるものではなく、キー情報を含めなくても良い。

［データベースサーバのキャッシュ応答部による処理の流れ］
図９は、実施例１におけるデータベースサーバのキャッシュ応答処理による処理の流れの一例を示すフローチャートである。

図９に示すように、キャッシュ応答部２２１は、キャッシュサーバ３００からデータ検索要求を受信すると（ステップＳ１０１）、受信したデータ検索要求から、キー情報Ｋ１〜ＫＮを取得する（ステップＳ１０２）。

そして、キャッシュ応答部２２１は、キー情報から、応答データ判定表を得る（ステップＳ１０３）。具体的には、キャッシュ応答部２２１は、取得したキー情報をもとに、図５に示すような応答データ判定表を作成する。そして、キャッシュ応答部２２１は、ユーザ情報ＤＢ２１１から、応答データ判定表に合致するデータを全て取得する（ステップＳ１０４）。具体的には、キャッシュ応答部２２１は、応答データ判定表に記載されたキー情報と合致するデータが自装置内のユーザ情報ＤＢ２１１に存在するかを検索し、合致したデータ全てを取得する。

ここで、キャッシュ応答部２２１は、データが存在する場合には（ステップＳ１０５肯定）、検索結果のうち、応答データ判定表の最も優先度が高いデータをデータ応答とする（ステップＳ１０６）。具体的には、キャッシュ応答部２２１は、応答データ判定表の優先度が最も高いデータとなる属性値を検索結果として選択し、検索結果として属性値を選択した際に用いられた応答データ判定表のキー情報を部分特定情報要素（Ｄ１〜ＤＮ）として含むデータ応答であって、検索結果として取得した属性値を含むデータ応答をキャッシュサーバ３００に送信する。一方、キャッシュ応答部２２１は、データが存在しない場合には（ステップＳ１０５否定）、キー情報なしを応答する（ステップＳ１０７）。つまり、キャッシュ応答部２２１は、データ検索要求に含まれるキー情報が自装置のユーザ情報ＤＢ２１１に存在しない旨を示すデータ応答をキャッシュサーバ３００に送信する。

［データベースサーバのＩＲ情報応答部による処理の流れ］
図１０は、実施例１におけるＩＲ情報応答部による処理の流れの一例を示すフローチャートである。

図１０に示すように、ＩＲ情報応答部２２２は、キャッシュサーバ３００からＩＲ情報要求を受信すると（ステップＳ２０１）と、受信したＩＲ情報要求から、要求元のキャッシュサーバ名を取得する（ステップＳ２０２）。つまり、ＩＲ情報応答部２２２は、ＩＲ情報要求の送信元となるキャッシュサーバ３００のキャッシュサーバ名を取得する。

そして、ＩＲ情報応答部２２２は、自装置のＩＲ情報ＤＢ２１２から、ＩＲ情報一覧を取得する（ステップＳ２０３）。つまり、ＩＲ情報応答部２２２は、取得したキャッシュサーバ名に対応するＩＲ情報を全て取得する。

ここで、ＩＲ情報応答部２２２は、自装置のＩＲ情報ＤＢ２１２に該当のデータが存在する場合には（ステップＳ２０４肯定）、つまり、取得したキャッシュサーバ名を含むＩＲ情報がＩＲ情報ＤＢ２１２に記憶されており、ＩＲ情報を取得した場合には、ＩＲ情報応答部２２２は、キャッシュサーバ名に対応するＩＲ情報の一覧をＩＲ情報応答としてキャッシュサーバ３００に送信する（ステップＳ２０５）。言い換えると、ＩＲ情報応答部２２２は、ＩＲ情報要求の送信元となるキャッシュサーバ３００に適用されるＩＲ情報の一覧を送信する。一方、自装置のＩＲ情報ＤＢ２１２に該当のデータが存在しない場合には（ステップＳ２０４否定）、ＩＲ情報応答部２２２は、「ＩＲ情報なし」を、キャッシュサーバ３００に応答する（ステップＳ２０６）。つまり、ＩＲ情報がないことを示すＩＲ情報応答をキャッシュサーバ３００に送信する。

［データベースサーバのＩＲ情報削除部による流れ］
図１１は、実施例１におけるデータベースサーバのＩＲ情報削除部による流れの一例を示すフローチャートである。

図１１に示すように、ＩＲ情報削除部２２３は、キャッシュサーバ３００からＩＲ情報削除要求を受信すると（ステップＳ３０１）、受信したＩＲ情報削除要求から、要求元キャッシュサーバ名と、削除対象となるキー情報（Ｋ１〜ＫＮ）を取得する（ステップＳ３０２）。

そして、ＩＲ情報削除部２２３は、自装置のＩＲ情報ＤＢ２１２から、取得したキャッシュサーバ名とキー情報（Ｋ１〜ＫＮ）とに該当するレコードを削除する（ステップＳ３０３）。つまり、ＩＲ情報削除部２２３は、取得した「キャッシュサーバ名」及び「キー情報」に対応するＩＲ情報がＩＲ情報ＤＢ２１２に記憶されている場合には、ＩＲ情報ＤＢ２１２から該当のＩＲ情報を削除する。そして、ＩＲ情報応答部２２２はＩＲ削除応答をキャッシュサーバ３００に送信する（ステップＳ３０４）。

［データベースサーバのユーザ情報更新部による処理］
図１２は、実施例１におけるデータベースサーバのユーザ情報更新部による処理の流れの一例を示すフローチャートである。

図１２に示すように、ユーザ情報更新部２２４は、登録対象データを受信すると（ステップＳ４０１）、受信した登録対象データから、対象データの操作（追加、更新、削除等）、操作対象となるレコードの「キー情報（Ｋ１〜ＫＮ）」及び「属性値」を取得する（ステップＳ４０２）。例えば、ユーザ情報更新部２２４は、利用者から登録対象データを受信する。なお、登録対象データには、例えば、操作内容を特定するための情報や、キー情報、属性値などが含まれる。

そして、ユーザ情報更新部２２４は、ユーザ情報ＤＢ２１１の「キー情報（Ｋ１〜ＫＮ）」のレコードを編集する（ステップＳ４０３）。具体的には、操作内容が「追加」である場合には、ユーザ情報更新部２２４は、登録対象データから取得した「キー情報」と「属性値」とを対応付けてユーザ情報ＤＢ２１１に格納する。また、操作内容が「更新」である場合には、ユーザ情報更新部２２４は、ユーザ情報ＤＢ２１１に記憶されたレコードのうち更新対象となるレコードの属性値を更新する。また、操作内容が「削除」である場合には、ユーザ情報更新部２２４は、登録対象データから取得したキー情報により特定されるレコードをユーザ情報ＤＢ２１１から削除する。

そして、ユーザ情報更新部２２４は、自装置に接続されるキャッシュサーバ名の一覧を取得する（ステップＳ４０４）。そして、ユーザ情報更新部２２４は、キャッシュサーバ名の一覧の先頭のキャッシュサーバ名を取得する（ステップＳ４０５）。そして、ユーザ情報更新部２２４は、ＩＲ情報ＤＢ２１２へ、ユーザ情報ＤＢ２１１へ格納した情報のキー情報部分を格納する（ステップＳ４０６）。つまり、ユーザ情報ＤＢ２１１は、取得したキャッシュサーバ名と、ユーザ情報ＤＢ２１１に対する操作対象となったレコードを特定するキー情報とを含むＩＲ情報を生成し、ＩＲ情報ＤＢ２１２に格納する。例えば、ユーザ情報更新部２２４は、レコードを削除した場合には、削除されたレコードに含まれていたキー情報とキャッシュサーバ名とを含むＩＲ情報を生成して格納する。

そして、ユーザ情報更新部２２４は、キャッシュサーバ名の一覧を全て処理したかを判定し、処理していない場合には（ステップＳ４０７否定）、キャッシュサーバ名の一覧から次のキャッシュサーバ名を取得し（ステップＳ４０８）、上述したステップＳ４０６に戻り、処理を繰り返す。一方、ユーザ情報更新部２２４は、キャッシュサーバ名の一覧を全て処理した場合には（ステップＳ４０７肯定）、処理を終了する。

［キャッシュサーバのキャッシュ判定部による処理の流れ］
図１３は、実施例１におけるキャッシュサーバのキャッシュ判定部による処理の流れの一例を示すフローチャートである。

図１３に示すように、キャッシュ判定部３２１は、クライアント１００からデータ要求を受信すると（ステップＳ５０１）、受信したデータ要求からサービス特定情報要素（Ｅ１〜ＥＮ）を取得し、取得したサービス特定情報要素をキー情報として、キャッシュ３１１のハッシュテーブルを検索する（ステップＳ５０２）。例えば、キャッシュ判定部３２１は、データ要求から取得したサービス特定情報要素（Ｅ１〜ＥＮ）各々を事前に決定しておいた手法にて連結し、連結した値をｘとして、ハッシュ関数ｈ（ｘ）の入力とする。そして、キャッシュ判定部３２１は、ハッシュ関数ｈ（ｘ）で計算されたハッシュ値を用いて、キャッシュ３１１のハッシュテーブルに記憶されたレコードを絞り込む。そして、キャッシュ判定部３２１は、絞り込んだレコードのリストにおいて、サービス特定要素（Ｅ１〜ＥＮ）と一致するキー情報（Ｋ１〜ＫＮ）を有するレコードを検索する。なお、キャッシュ判定部３２１は、「ｘ」として、「Ｅ１〜ＥＮ」の連結を用いる場合を用いて説明したが、これに限定されるものではなく、任意の手法を用いて良い。例えば、キャッシュ判定部３２１は、「Ｅ１〜ＥＮ」に対する特定の演算により「ｘ」を導出して用いても良く、「Ｅ１〜ＥＮ」までのＮ個の値をパラメータとする関数を、ハッシュ関数として用いても良い。

ここで、キャッシュ３１１のハッシュテーブルにキー情報として「Ｅ１〜ＥＮ」を持つレコードが存在しない場合には（ステップＳ５０３否定）、キャッシュ判定部３２１は、サービス特定情報要素（Ｅ１〜ＥＮ）をキー情報として含むデータ検索要求をデータベースサーバ２００に送信する（ステップＳ５０４）。そして、キャッシュ判定部３２１は、データベースサーバ２００から、データ検索要求に対するデータ応答として、部分特定情報要素（Ｄ１〜ＤＮ）と、属性値を受信する（ステップＳ５０５）。ここで、データベースサーバ２００からのデータ応答が、検索結果なしの場合には（ステップＳ５０６否定）、キャッシュ判定部３２１は、キー情報なしとし（ステップＳ５０９）、応答処理部３２３に結果を出力する（ステップＳ５１４）。

一方、上述したステップＳ５０６に戻り、データベースサーバ２００からの検索結果が検索結果ありの場合には（ステップＳ５０６肯定）、キャッシュ判定部３２１は、サービス特定情報要素（Ｅ１〜ＥＮ）、データベースサーバ２００からのデータ応答に含まれる部分特定情報要素（Ｄ１〜ＤＮ）、データベースサーバ２００からのデータ応答に含まれる属性値、有効期限情報として、事前に決定しておく有効期限情報計算方法の結果を用いて、キャッシュ登録処理を行う（ステップＳ５０７）。なお、キャッシュ登録処理の流れについては、図１４を用いて後述する。

キャッシュ登録処理が完了すると、キャッシュ判定部３２１は、キャッシュ登録処理の結果としてキャッシュ３１１に登録されたレコードを取得し、取得したレコードに含まれる属性情報ＩＤから属性情報を取得（ステップＳ５０８）し、属性情報から属性値を取得する（ステップＳ５１３）。つまり、キャッシュ判定部３２１は、取得したレコードに含まれる属性情報ＩＤを含むレコードをキャッシュ３１１の属性情報テーブルから取得し、取得したレコードに含まれる属性値を取得する。そして、キャッシュ判定部３２１は、応答処理部３２３へ結果を出力する（ステップＳ５１４）。つまり、キャッシュ判定部３２１は、取得した属性値を応答処理部３２３に出力する。

また、上述したステップＳ５０３に戻り、キャッシュ３１１のハッシュテーブルにキー情報としてＥ１〜ＥＮを持つレコードが存在する場合には（ステップＳ５０３肯定）、キャッシュ判定部３２１は、レコード内の属性情報ＩＤから属性情報を取得し、属性情報から有効期限情報を取得する（ステップＳ５１０）。ここで、属性情報の有効期限が切れていない場合（ステップＳ５１１否定）、キャッシュ判定部３２１は、属性情報から属性値を取得（ステップＳ５１３）し、取得した属性値を用いて、応答処理部３２３へ属性値を出力する（ステップＳ５１４）。

また、上述したステップＳ５１１に戻り、属性情報の有効期限が切れていた場合には（ステップＳ５１１肯定）、キャッシュ判定部３２１は、サービス特定情報要素（Ｅ１〜ＥＮ）を、キー情報として、キャッシュ削除処理を行う（ステップＳ５１２）。なお、キャッシュ削除処理については、図１５を用いて後述する。キャッシュ削除処理では、指定されたキー情報のレコードがキャッシュ３１１のハッシュテーブルに存在する場合、該当するレコードをハッシュテーブルから削除する。その後、キャッシュ判定部３２１は、キャッシュ削除処理が完了すると、ステップＳ５０４以降の処理を継続する。

［キャッシュ登録処理の流れ］
図１４は、実施例１におけるキャッシュ登録処理の流れの一例を示すフローチャートである。

図１４に示すように、キャッシュ判定部３２１は、サービス特定情報要素（Ｅ１〜ＥＮ）、部分特定情報要素（Ｄ１〜ＤＮ）、属性値、有効期限情報を取得する（ステップＳ６０１）。そして、キャッシュ判定部３２１は、部分特定情報要素（Ｄ１〜ＤＮ）をキー情報としてハッシュ値を算出し、キャッシュ３１１のハッシュテーブルを検索する（ステップＳ６０２）。

ここで、キャッシュ３１１のハッシュテーブルにレコードが存在しない場合には（ステップＳ６０３否定）、キャッシュ判定部３２１は、属性値、有効期限情報を用いて新たな属性情報を作成する（ステップＳ６０４）。例えば、キャッシュ判定部３２１は、取得した属性値と有効期限情報に加えて、新たに付与した属性情報ＩＤを含むレコードをキャッシュ３１１の属性情報テーブルに格納する。そして、作成した属性情報の属性情報ＩＤを取得（ステップＳ６０５）し、キャッシュ３１１のレコードテーブルに、新たなレコードＩＤを付与した上で、キー情報（Ｄ１〜ＤＮ）と作成した属性情報ＩＤとを対応付けてレコードを追加するとともに、新たに付与したレコードＩＤをハッシュテーブルに追加する（ステップＳ６０６）。

具体的には、キャッシュ判定部３２１は、部分特定情報要素（Ｄ１〜ＤＮ）を、事前に決定しておいた方法を用いて連結し、連結した値をｘとして、ハッシュ関数ｈ（ｘ）の入力とする。そして、キャッシュ判定部３２１は、ハッシュ関数ｈ（ｘ）で計算されたハッシュ値を用いて、ハッシュテーブルのレコードを絞り込み、絞り込んだレコードのリストに、レコードのキー情報としてＤ１〜ＤＮ、属性情報ＩＤを設定したレコードを追加する。また、キャッシュ判定部３２１は、新たなレコードＩＤをハッシュテーブルに追加する。

そして、キャッシュ判定部３２１は、キャッシュ３１１のレコードテーブルに追加したレコードのレコードＩＤを取得し（ステップＳ６０７）、属性情報の参照元レコード一覧に、レコードＩＤを追加する（ステップＳ６０８）。つまり、キャッシュ判定部３２１は、上述したステップＳ６０４にて属性情報テーブルに格納したレコードの参照元レコード一覧に対して、上述したステップＳ６０６にてレコードテーブルに格納したレコードのレコードＩＤを追加する。

そして、キャッシュ判定部３２１は、ステップＳ６０１にて取得しているサービス特定情報要素（Ｅ１〜ＥＮ）と、部分特定情報要素（Ｄ１〜ＤＮ）の各要素をそれぞれ比較し、各要素が全て等しい場合には（ステップＳ６１３肯定）、ハッシュテーブルに新たに追加したレコードを返却（ステップＳ６１７）し、処理を終了する。

また、ステップＳ６１３に戻り、サービス特定情報要素（Ｅ１〜ＥＮ）と、部分特定情報要素（Ｄ１〜ＤＮ）の各要素が異なった場合には（ステップＳ６１３否定）、キャッシュ判定部３２１は、レコードテーブルに、新たにレコードＩＤを付与した上で、キー情報としてサービス特定情報要素（Ｅ１〜ＥＮ）と、属性情報ＩＤとを対応付けてレコードを追加し、新たに付与したレコードＩＤをハッシュテーブルに追加する（ステップＳ６１４）。

そして、キャッシュ判定部３２１は、キャッシュ３１１のレコードテーブルに追加したレコードのレコードＩＤを取得し（ステップＳ６１５）、属性情報の参照元レコード一覧に、レコードＩＤを追加する（ステップＳ６１６）。その後、ハッシュテーブルに新たに追加したレコードを返却（ステップＳ６１７）し、処理を終了する。

また、ステップＳ６０３に戻り、レコードテーブルにレコードが存在する場合には（ステップＳ６０３肯定）、キャッシュ判定部３２１は、該当するレコード内の属性情報ＩＤから、属性情報を取得し、属性情報に含まれる有効期限情報を取得する（ステップＳ６０９）。そして、キャッシュ判定部３２１は、属性情報の有効期限情報が、有効期限切れでない場合には（ステップＳ６１０否定）、該当するレコードの属性情報ＩＤから、属性情報を取得し（ステップＳ６１１）、ステップＳ６１３以降の処理を継続する。

一方、ステップＳ６１０に戻り、属性情報の有効期限情報が有効期限切れであった場合には（ステップＳ６１０肯定）、部分特定情報要素（Ｄ１〜ＤＮ）をキー情報として、キャッシュ削除処理を行う。キャッシュ削除処理では、キャッシュ判定部３２１は、指定されたキー情報のレコードがハッシュテーブルに存在する場合、そのレコードをハッシュテーブルから削除する。その後、キャッシュ判定部３２１は、キャッシュ削除処理が完了すると、ステップＳ６０４以降の処理を継続する。

［キャッシュ削除処理の流れ］
図１５には、実施例１におけるキャッシュ削除処理の流れの一例を示すフローチャートである。以下では、サービス特定情報要素（Ｋ１〜ＫＮ）をキー情報として、キャッシュ削除処理を行う場合を例に説明する。以下では、キャッシュ判定部３２１を例に説明するが、これに限定されるものではなく、ＩＲ情報判定部３２２が実行しても良い。

図１５に示すように、キャッシュ判定部３２１は、削除対象を示すキー情報であるサービス特定情報要素（Ｋ１〜ＫＮ）を取得する（ステップＳ７０１）。そして、キャッシュ判定部３２１は、サービス特定情報要素（Ｋ１〜ＫＮ）をキー情報としてハッシュ値を算出し、キャッシュ３１１のハッシュテーブルを検索する（ステップＳ７０２）。そして、キャッシュ判定部３２１は、ハッシュテーブルにレコードが存在しない場合には（ステップＳ７０３否定）、削除対象のレコードは存在しないため、処理を終了する。

一方、ハッシュテーブルにレコードが存在する場合には（ステップＳ７０３肯定）、キャッシュ判定部３２１は、有効期限切れに基づく削除として呼び出されたものかを判定する（ステップＳ７０４）。ここで、有効期限切れによる削除ではない場合には（ステップＳ７０４否定）、キャッシュ判定部３２１は、キー情報Ｋ１〜ＫＮ対応するレコードの中に、ＡＮＹ要素があるかを判定する（ステップＳ７０５）。ここで、キー情報Ｋ１〜ＫＮにＡＮＹ要素がない場合には（ステップＳ７０５否定）、キャッシュ判定部３２１は、キー情報Ｋ１〜ＫＮに対応するレコードから属性情報ＩＤを取得し（ステップＳ７０６）、属性情報ＩＤで示される属性情報から、参照元レコード一覧を取得する（ステップＳ７０７）。つまり、キャッシュ判定部３２１は、属性情報ＩＤを含むレコードを属性情報テーブルから取得し、取得したレコードに含まれる参照元レコード一覧を取得する。

そして、キャッシュ判定部３２１は、参照元レコード一覧からレコードを削除する（ステップＳ７０８）。つまり、キャッシュ判定部３２１は、参照元レコード一覧に存在するレコードＩＤから、キー情報Ｋ１〜ＫＮに対応するレコードＩＤを削除する。ここで、ステップＳ７０８の結果、参照元レコード一覧が空のリストとなった場合には（ステップＳ７０９肯定）、キャッシュ判定部３２１は、参照元レコード一覧が空となった属性情報を削除する（ステップＳ７１０）。つまり、キャッシュ判定部３２１は、参照元レコード一覧が空となったレコードを属性情報テーブルから削除する。そして、キャッシュ判定部３２１は、キー情報Ｋ１〜ＫＮを用いて、レコードテーブルからレコードを削除するとともに、ハッシュテーブルからレコードＩＤを削除する（ステップＳ７１１）。一方、ステップＳ７０９に戻り、参照元レコード一覧が空のリストとならなかった場合（ステップＳ７０９否定）、ステップＳ７１１からの処理を継続する。

次に、ステップＳ７０４に戻り、有効期限切れによる削除の場合（ステップＳ７０４肯定）、又は、ステップＳ７０５に戻り、キー情報の中にＡＮＹ要素がある場合（ステップＳ７０５肯定）について説明する。なお、有効期限切れによる削除の場合とは、例えば、図１３のステップＳ５１１において、有効期限切れであるとしてキャッシュ削除処理が実行される場合が該当する。

この場合、キャッシュ判定部３２１は、該当のレコードから属性情報ＩＤを取得（ステップＳ７１２）し、属性情報ＩＤで示される属性情報から参照元レコード一覧を取得する（ステップＳ７１３）。そして、キャッシュ判定部３２１は、参照元レコード一覧の最初のレコードＩＤを取得する（ステップＳ７１４）。その後、キャッシュ判定部３２１は、取得したレコードＩＤで示されるレコードをキャッシュ３１１のレコードテーブルから取得し、取得したレコードのキー情報がキー情報Ｋ１〜ＫＮと合致する場合に取得したレコードをレコードテーブルから削除するとともに、ハッシュテーブルからレコードＩＤを削除する（ステップＳ７１５）。

そして、キャッシュ判定部３２１は、参照元レコード一覧の全てのレコードＩＤをハッシュテーブルから削除していない場合には（ステップＳ７１６否定）、参照元レコード一覧の次のレコードＩＤを取得し（ステップＳ７１７）、ステップＳ７１５の処理を継続する。

また、ステップＳ７１６に戻り、参照元レコードの全てのレコードＩＤで示されるレコードをハッシュテーブルから削除した場合には（ステップＳ７１６肯定）、キャッシュ判定部３２１は、属性情報を削除し（ステップＳ７１８）、処理を終了する。つまり、キャッシュ判定部３２１は、ステップＳ７１２にて取得した属性情報ＩＤを含むレコードを属性情報テーブルから削除する。

［キャッシュサーバのＩＲ情報判定部による処理の流れ］
図１６は、実施例１におけるキャッシュサーバのＩＲ情報判定部による処理の流れの一例を示すフローチャートである。

図１６に示すように、ＩＲ情報判定部３２２は、定期的にデータベースサーバ２００へＩＲ情報要求を送信し（ステップＳ８０１）、データベースサーバ２００からＩＲ情報の一覧を受信する（ステップＳ８０２）。

そして、ＩＲ情報判定部３２２は、受信したＩＲ情報一覧が存在する場合（ステップＳ８０３肯定）、つまり、データベースサーバ２００からＩＲ情報を受信したＩＲ情報応答にＩＲ情報が含まれている場合には、ＩＲ情報の一覧の先頭のＩＲ情報を取得し（ステップＳ８０４）、ＩＲ情報から、キー情報Ｋ１〜ＫＮを取得する（ステップＳ８０５）。そして、ＩＲ情報判定部３２２は、キー情報Ｋ１〜ＫＮを用いて、図１５で示されるキャッシュ削除処理を行い（ステップＳ８０６）、キャッシュ削除処理終了後、データベースサーバ２００に該当のＩＲ情報について、ＩＲ情報削除要求を送信する（ステップＳ８０７）。つまり、ＩＲ情報判定部３２２は、キャッシュサーバ３００においてキー情報Ｋ１〜ＫＮを含むレコードについて削除されたことを踏まえ、キャッシュサーバ３００に適用済みとなったＩＲ情報を削除する旨の指示をデータベースサーバ２００に送信する。

その後、全てのＩＲ情報を処理していない場合には（ステップＳ８０８否定）、ＩＲ情報判定部３２２は、ＩＲ情報の一覧から次のＩＲ情報を取得し（ステップＳ８０９）、ステップＳ８０５からの処理を繰り返す。

一方、ステップＳ８０３に戻り、ＩＲ情報の一覧が存在しない場合には（ステップＳ８０３否定）、又は、ステップＳ８０８に戻り、全てのＩＲ情報を処理した場合には（ステップＳ８０８肯定）、ＩＲ情報判定部３２２は、処理を終了する。

［キャッシュサーバの応答部による処理の流れ］
図１７は、実施例１におけるキャッシュサーバの応答部による処理の流れの一例を示すフローチャートである。

図１７に示すように、応答処理部３２３は、キャッシュ判定部３２１から指定された属性情報をクライアントへの応答として組み立てる（ステップＳ９０１）。つまり、応答処理部３２３は、キャッシュ判定部３２１から受信した属性値と、クライアント１００から受信したデータ要求に含まれるキー情報とを含むデータ応答を生成したり、キー情報がないことを示すデータ応答を生成したりする。なお、上述した説明では、応答処理部３２３が、クライアント１００から受信したデータ要求に含まれるキー情報を含むデータ応答を送信する場合を例に示したが、これに限定されるものではなく、キー情報を含めなくても良い。

そして、応答処理部３２３は、生成したデータ応答をクライアント１００に送信し（ステップＳ９０２）、処理を終了する。

［実施例１による効果］
少なくとも１種類の特定情報により特定されるデータごとに、データを特定するための特定情報と、複数ある特定情報の種類のうちデータを特定する際に用いられない種類である非特定種類を示す非特定種類情報との組み合わせと対応付けて記憶する。また、キャッシュサーバ３００は、データベースサーバ２００に記憶されたデータの少なくとも一部について、特定情報と非特定種類情報との組み合わせと、複数種類の特定情報の組み合わせとのうち少なくとも一つと対応付けて記憶するキャッシュ３１１を有する。ここで、キャッシュサーバ３００は、データ要求を受信すると、データ要求に含まれる複数種類の特定情報各々の組み合わせがキャッシュに記憶されているかを判定し、記憶されていないと判定した場合に、データ要求に含まれる組み合わせをデータベースサーバ２００に送信する。また、データベースサーバ２００は、キャッシュサーバ３００により送信された組み合わせである組み合わせを受信すると、受信した組み合わせである受信組み合わせに相当する特定情報と非特定種類情報との組み合わせと、特定情報と非特定種類情報との組み合わせに対応付けられたデータとを記憶部から取得し、キャッシュサーバ３００に応答する。また、キャッシュサーバ３００は、データベースサーバ２００により送信された特定情報と非特定種類情報との組み合わせがキャッシュ３１１に記憶されている場合には、記憶されていた特定情報と非特定種類情報との組み合わせに対応付けられるデータと対応付けて、受信組み合わせをキャッシュ３１１に格納する。また、データベースサーバ２００は、キャッシュ３１１に記憶されていない場合には、データベースサーバ２００により送信されたデータと対応付けて、データベースサーバ２００により送信された特定情報と非特定種類情報との組み合わせと、受信組み合わせとをキャッシュ３１１に格納する。また、キャッシュサーバ３００は、キャッシュ３１１に記憶されていると判定された場合には、キャッシュ３１１からデータを取得してデータ要求の送信元に送信し、記憶されていないと判定した場合には、データベースサーバ２００により送信されたデータをデータ要求の送信元に送信する。この結果、適切に検索可能となる。

具体的には、ＡＮＹ要素を有するデータ構造のデータベースサーバとキャッシュサーバとを組み合わせ可能となる。また、データベースサーバからデータを抽出する上で必要となる特定情報の集合が受信時点において不明である場合が想定される状況下においても、キャッシュの容量を節約することが可能であり、一度の検索で抽出できることで検索性能の低下を防止可能となる。

すなわち、例えば、キャッシュ３１１では、データが複数のキー情報と共有される結果、キャッシュ３１１の容量を節約することが可能となる。また、キャッシュサーバ３００は、一度の検索において、キャッシュにデータが記憶されているか否かを判定可能となり、検索性能の低下を防止可能となる。

また、データベースサーバ２００では、｛Ｅ１，ＡＮＹ，…ＡＮＹ｝という１レコードで複数のキー情報を表現可能となり、データベースサーバ２００の記憶装置の消費を防止可能となる。また、キャッシュサーバ３００では、複数の属性値が複数のキー情報と対応付けられる結果、メモリ等の記憶装置に冗長に持つことを防止可能となる。このように、実施例１によれば、属性値が複数のキー情報にて共有される結果、キャッシュ３１１の容量を節約可能となる。

また、上述したように、データ要求に含まれる複数種類の特定情報各々の組み合わせがキャッシュ３１１に記憶されているかの判定を、ハッシュ値を用いて実行することで、キャッシュ３１１に記憶されているかを迅速に判定可能となる。

また、データベースサーバ２００は、データごとに、データを特定する際に用いられる特定情報種類に属する特定情報と、非特定種類情報との組み合わせを対応付けて記憶する。また、データベースサーバ２００は、キャッシュサーバ３００により送信された受信組み合わせを受信すると、組み合わせに相当する特定情報と非特定種類情報との組み合わせ各々のうち一つを選択し、選択した特定情報と非特定種類情報との組み合わせと、選択した組み合わせに対応付けて記憶されたデータとを送信する。この結果、データベースサーバ２００が、ＡＮＹ要素を含むレコードを記憶することで、記憶部にて使用される容量を節約することが可能となる。

実施例１に加えて、キャッシュサーバ３００が、非特定種類情報を含む組み合わせと属性値とを受信した場合に、受信した属性値を、非特定種類情報に適用される可能性がある特定情報各々に特定種類情報を置き換えた組み合わせ各々と共有する場合について説明する。

すなわち、例えば、ＡＮＹ要素を含む組み合わせをキャッシュサーバ３００が受信すると、受信した組み合わせに含まれるＡＮＹ要素を、ＡＮＹ要素に適用される可能性がある特定情報各々に置き換えた組み合わせ各々を生成し、生成した組み合わせ各々についても、受信したデータと対応付けてキャッシュ３１１に格納しても良い。以下では、実施例１と異なる点について説明し、その他の点については適宜説明を省略する。

［実施例２におけるキャッシュサーバの構成］
実施例２におけるキャッシュサーバでは、キャッシュ判定部３２１ｂ以外については、実施例１と同様であり、説明を省略する。

実施例２において、キャッシュ判定部３２１ｂは、クライアント１００から受信したデータ要求から、サービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）を取得し、これを、キー情報として、キャッシュ３１１に記憶される属性情報を検索する。キャッシュ判定部３２１ｂはキャッシュ３１１検索の結果に応じた処理を行い、応答を行う。

キャッシュ３１１にキー情報が記憶されておらず、データベースサーバ２００から属性情報を取得できた場合における処理について説明する。すなわち、クライアント１００からのデータ要求から取得したキー情報がキャッシュ３１１に記憶されていない場合について説明する。

この場合、キャッシュ判定部３２１ｂは、データ要求から取得したキー情報を含むデータ検索要求をデータベースサーバ２００に送信する。例えば、キャッシュ判定部３２１は、サービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）を含むデータ検索要求をデータベースサーバ２００に送信する。その後、キャッシュ判定部３２１は、データベースサーバ２００から、データ検索結果として、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）と属性値とを含むデータ応答を受信する。

ここで、キャッシュ判定部３２１ｂは、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）が、自装置のキャッシュ３１１に既に存在する場合には、事前にキャッシュ３１１上に展開されるべき、サービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）と、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）の対応が取れていないと判断し、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）を用いてキャッシュ３１１を削除した上で、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）がキャッシュ３１１に既に存在しない場合における処理を実行する。なお、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）がキャッシュ３１１に既に存在しない場合における処理については後述する。

なお、実施例２の場合には、ＡＮＹ要素が得られた場合には、ＡＮＹ要素に適用される可能性のある特定情報の組み合わせ各々を生成し、受信した属性値と対応付けてキャッシュ３１１に予め登録しておくことになる。この結果、データベースサーバ２００に問い合わせる際には、キャッシュ３１１に対応するレコードが何も記憶されていない場合となり、データベースサーバ２００に問い合わせが行われない際には、キャッシュ３１１に対応するレコードがすべて記憶されている場合となる。このことを踏まえ、キャッシュ判定部３２１ｂは、問い合わせたにもかかわらず、データベースサーバ２００から受信した部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）が、自装置のキャッシュ３１１に既に存在する場合には、おかしいと判断し、キャッシュ３１１から削除した上で一連の処理を実行する。

図７を用いて具体的に説明する。データ要求から取得したキー情報（Ｋ１、Ｋ２、Ｋ３）が「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００２」である場合を用いて説明する。キャッシュ判定部３２１ｂは、キー情報からハッシュ値を算出する。以下では、キャッシュ判定部３２１ｂにより算出されたハッシュ値が「２」である場合を用いて説明する。ここで、キャッシュ判定部３２１ｂは、キャッシュ３１１のハッシュテーブルには、ハッシュ値「２」に対応付けられたレコードＩＤが存在しないため、キー情報（Ｋ１、Ｋ２、Ｋ３）を含むデータ検索要求をデータベースサーバ２００に送信する。例えば、キャッシュ判定部３２１ｂは、データベースサーバ２００から、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）として、「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＡＮＹ、ＡＮＹ」とを含み、属性値「データ１」とを含むデータ応答を受信する。その後、キャッシュ判定部３２１は、部分特定要素（Ｄ１、Ｄ２、Ｄ３）をキー情報として、自装置のキャッシュ３１１のハッシュテーブルを検索する。ここで、キャッシュ判定部３２１は、レコードＩＤ「０」が得られた場合には、キャッシュ３１１のレコードテーブルからレコードＩＤ「０」に対応付けられる属性情報ＩＤ「０」を取得する。そして、キャッシュ判定部３２１ｂは、属性情報ＩＤ「０」を含むレコードを属性情報テーブルから取得し、取得したレコードの参照元レコード一覧に含まれるレコードＩＤ「０」「１」を取得し、レコードＩＤ「０」「１」を含むレコードをキャッシュ３１１のレコードテーブルから削除する。また、キャッシュ判定部３２１ｂは、属性情報ＩＤ「０」を含むレコードを属性情報テーブルから削除する。

キャッシュ３１１にキー情報が記憶されておらず、データベースサーバ２００から受信したデータ応答に含まれる部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）がキャッシュ３１１に存在しない場合における処理について説明する。以下では、データベースサーバ２００からデータ応答を受信した後の処理について説明する。

キャッシュ判定部３２１ｂは、データベースサーバ２００から受信した部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）と、データベースサーバから取得した属性値とについて、キャッシュ登録処理を実行する。

また、キャッシュ判定部３２１ｂは、データベースサーバ２００から受信した部分特定情報要素のうち、ＡＮＹ要素となっているカラムを取得する。そして、キャッシュ判定部３２１ｂは、ＡＮＹ要素が存在する各々のカラムの位置から、事前に決定されているＡＮＹ要素に入る可能性があるサービス特定情報要素の値の一覧を取得する。そして、キャッシュ判定部３２１ｂは、カラム各々のサービス特定情報要素の値の一覧を組み合わせ、ＡＮＹ要素を展開したサービス特定情報要素の一覧を算出する。その後、キャッシュ判定部３２１ｂは、既にキャッシュ３１１に格納した属性情報を、算出したサービス特定情報要素の一覧のそれぞれのサービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）の組み合わせに対応させたレコードを登録する。すなわち、キャッシュ判定部３２１ｂは、算出したサービス特定情報要素の一覧各々と、データベースサーバ２００から取得した属性値とについて、キャッシュ登録処理を実行する。また、この際、キャッシュ判定部３２１ｂは、キャッシュ３１１の属性情報テーブルの参照元レコード一覧に、算出したサービス特定情報要素の一覧各々に対応するレコードＩＤを追加する。その後、キャッシュ判定部３２１ｂは、データベースサーバ２００から受信した属性値を応答処理部３２３に出力する。

図１８−１〜図１８−３を用いて具体的に説明する。図１８−１〜図１８−３は、実施例２におけるキャッシュに記憶された情報の一例を示す図である。図１８−１〜図１８−３に示す例では、キャッシュ３１１が、ハッシュテーブルと、レコードテーブルと、属性情報テーブルとを有する場合を示した。図１８−１〜図１８−３は、実施例２におけるハッシュテーブルと、レコードテーブルと、属性情報テーブルとの一例を示す。また、以下では、キャッシュ判定部３２１ｂが、クライアント１００から受信したデータ要求にキー情報（Ｋ１、Ｋ２、Ｋ３）が「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」が含まれていた場合を用いて説明する。また、以下では、キャッシュ判定部３２１ｂが、データベースサーバ２００から、部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）として、「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＡＮＹ、ＡＮＹ」を含み、属性値「データ１」を含むデータ応答を受信した場合を用いて説明する。

この場合、キャッシュ判定部３２１ｂは、データベースサーバ２００からのデータ応答に含まれる部分特定要素（Ｄ１、Ｄ２、Ｄ３）をキー情報として、自装置のキャッシュ３１１を確認する。つまり、キャッシュ判定部３２１ｂは、部分特定要素（Ｄ１、Ｄ２、Ｄ３）からハッシュ値を算出し、算出したハッシュ値を用いてキャッシュ３１１のハッシュテーブルを検索する。以下では、算出されたハッシュ値が「０」であるものとして説明する。図１８−１に示す例では、ハッシュテーブルのハッシュ値「０」にはレコードＩＤが存在しない。この場合、キャッシュ判定部３２１ｂは、新たに付与した属性情報ＩＤ「０」と属性値「データ１」とを含むレコードをキャッシュ３１１の属性情報テーブルに格納する。そして、キャッシュ判定部３２１ｂは、新たに付与したレコードＩＤ「０」と、キー情報として部分特定情報要素（Ｄ１、Ｄ２、Ｄ３）「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＡＮＹ、ＡＮＹ」と、属性情報ＩＤ「０」とを含むレコードをキャッシュ３１１のレコードテーブルに格納する。また、キャッシュ判定部３２１ｂは、属性情報ＩＤ「０」を含む属性情報テーブルに記憶されたレコードの参照元レコード一覧に対して、レコードＩＤ「０」を追加し、キャッシュ３１１のハッシュテーブルのハッシュ値「０」に対応付けてレコードＩＤ「０」を格納する。

また、キャッシュ判定部３２１ｂは、部分特定要素（Ｄ１、Ｄ２、Ｄ３）のうち、ＡＮＹとなっている要素である、Ｄ２、Ｄ３の要素の、事前に決定されているサービス特定要素の値の一覧をそれぞれ得る。図１９は、実施例２における事前に決定されているサービス特定要素の値の一覧の例である。図１９に示す例では、部分特定要素「Ｄ２」がＡＮＹであった場合には、「ＵｓｅｒＴｙｐｅ−００１」又は、「ＵｓｅｒＴｙｐｅ−００２」を取りうることを示し、Ｄ３がＡＮＹであった場合には、「ＡｃｃｏｕｎｔＴｙｐｅ−００１」又は、「ＡｃｃｏｕｎｔＴｙｐｅ−００２」を取りうることを示す。図１９に示す一覧は、例えば、予め生成されたり、キャッシュ判定部３２１ｂにより適宜生成されたりする。ここで、キャッシュ判定部３２１ｂは、ＡＮＹとなっているカラムの全ての組み合わせをサービス特定要素の一覧として算出する。例えば、ＡＮＹではない要素（Ｄ１）の値である「ＳｅｒｖｉｃｅＮａｍｅ−００１」と、図１９により示されるＤ２及びＤ３のサービス特定要素の値の一覧から、以下に記載する組み合わせ各々を算出する。なお、図１９に示す一覧は、データベースシステム一意の情報であり、キャッシュサーバ内に格納されている。

組み合わせ（１）｛ＳｅｒｖｉｃｅＮａｍｅ−００１， ＵｓｅｒＴｙｐｅ−００１， ＡｃｃｏｕｎｔＴｙｐｅ−００１｝，
組み合わせ（２）｛ＳｅｒｖｉｃｅＮａｍｅ−００１， ＵｓｅｒＴｙｐｅ−００１， ＡｃｃｏｕｎｔＴｙｐｅ−００２｝，
組み合わせ（３）｛ＳｅｒｖｉｃｅＮａｍｅ−００１， ＵｓｅｒＴｙｐｅ−００２， ＡｃｃｏｕｎｔＴｙｐｅ−００１｝，
組み合わせ（４）｛ＳｅｒｖｉｃｅＮａｍｅ−００１， ＵｓｅｒＴｙｐｅ−００２， ＡｃｃｏｕｎｔＴｙｐｅ−００２｝

以下では、上述した組み合わせ（１）〜組み合わせ（４）から算出されるハッシュ値が、それぞれ「１」〜「４」であるものとして説明する。この場合、例えば、キャッシュ判定部３２１ｂは、キャッシュ３１１のレコードテーブルに対して、レコードＩＤ「１」と、キー情報として組み合わせ（１）と、属性情報ＩＤ「０」とを含むレコードを追加し、属性情報ＩＤ「０」を含む属性情報テーブルに格納されたレコードの参照元レコード一覧にレコードＩＤ「１」を追加し、ハッシュテーブルのハッシュ値「１」に対応付けてレコードＩＤ「１」を格納する。また、同様に、キャッシュ判定部３２１ｂは、他の組み合わせについても処理を実行する。図２０−１〜図２０−３は、実施例２におけるキャッシュ判定部によるレコード登録処理後のキャッシュに記憶された情報の一例を示す図である。図２０−１〜図２０−３は、それぞれ、キャッシュ３１１のハッシュテーブルと、レコードテーブルと、属性情報テーブルとに対応する。

［キャッシュ登録処理の流れ］
図２１は、実施例２におけるキャッシュ登録処理の一例を示すフローチャートである。なお、図２１に示す一連の処理のうち、Ｓ１００１〜Ｓ１００３、Ｓ１００５〜Ｓ１０１０、Ｓ１０１９は、それぞれ、図１４におけるステップＳ６０１〜Ｓ６０３、Ｓ６０４〜Ｓ６０８、Ｓ６１３、Ｓ６１７に対応する。以下では、図１４に示す一連の処理と異なる点について説明し、同様の点については適宜省略する。

図２１に示すように、キャッシュ判定部３２１ｂは、サービス特定情報要素（Ｅ１〜ＥＮ）、部分特定情報要素（Ｄ１〜ＤＮ）、属性値、有効期限情報を取得し（ステップＳ１００１）。部分特定情報要素（Ｄ１〜ＤＮ）をキー情報としてキャッシュ３１１のハッシュテーブルを検索する（ステップＳ１００２）。

ここで、キャッシュ３１１のハッシュテーブルにレコードが存在しない場合には（ステップＳ１００３否定）、キャッシュ３１１のレコードテーブルや属性情報テーブルにレコードを格納する（ステップＳ１００５〜Ｓ１００９）。その後、キャッシュ判定部３２１ｂは、サービス特定情報要素（Ｅ１〜ＥＮ）と、部分特定情報要素（Ｄ１〜ＤＮ）の各要素をそれぞれ比較し、各要素が全て等しい場合には（ステップＳ１０１０肯定）、ハッシュテーブルに新たに追加したレコードを返却し（ステップＳ１０１９）、処理を終了する。

一方、ステップＳ１０１０に戻り、キャッシュ判定部３２１ｂは、サービス特定情報要素（Ｅ１〜ＥＮ）と、部分特定情報要素（Ｄ１〜ＤＮ）の各要素が異なった場合について説明する（ステップＳ１０１０否定）。キャッシュ判定部３２１ｂは、部分特定情報要素（Ｄ１〜ＤＮ）の中で、ＡＮＹとなっているカラムに対応したサービス特定情報要素の値の一覧を取得する（ステップＳ１０１１）。例えば、キャッシュ判定部３２１ｂは、予め生成された図１９に示す表に基づいて、サービス特定情報要素の一覧を取得する。

そして、キャッシュ判定部３２１ｂは、ＡＮＹ要素となっている全てのカラムのサービス特定情報要素の値の一覧と、非ＡＮＹ要素となっているカラムのサービス特定情報をもとに、ＡＮＹ要素が示す、サービス特定情報要素の全ての組み合わせの一覧を取得する（ステップＳ１０１２）。そして、キャッシュ判定部３２１ｂは、サービス特定情報要素の全ての組み合わせの一覧の最初のサービス特定情報要素を取得する（ステップＳ１０１３）。

そして、キャッシュ判定部３２１ｂは、キャッシュ３１１のハッシュテーブルに、キー情報としてサービス特定情報要素（Ｅ１〜ＥＮ）と、属性情報ＩＤを対応付けてレコードを追加する（ステップＳ１０１４）。つまり、キャッシュ判定部３２１ｂは、取得した組み合わせをキー情報として含み、ステップＳ１００５にて付与した属性情報ＩＤを含み、新たに付与したレコードＩＤを含むレコードをキャッシュ３１１のレコードテーブルに格納する。

そして、キャッシュ判定部３２１ｂは、キャッシュ３１１のレコードテーブルに追加したレコードのレコードＩＤを取得し（ステップＳ１０１５）、属性情報の参照元レコード一覧に、レコードＩＤを追加する（ステップＳ１０１６）。

そして、サービス特定情報要素の全ての組み合わせの一覧を全て処理した場合には（ステップＳ１０１７肯定）、キャッシュ判定部３２１ｂは、ハッシュテーブルに新たに追加したサービス特定情報要素（Ｅ１〜ＥＮ）に対応したレコードを返却（ステップＳ１０１９）し、処理を終了する。一方、ステップＳ１０１７に戻り、サービス特定情報要素の全ての組み合わせの一覧を全て処理していない場合には（ステップＳ１０１７否定）、キャッシュ判定部３２１ｂは、サービス特定情報要素の全ての組み合わせの一覧から、次のサービス特定情報要素を取得し、ステップＳ１０１４以降を継続する（ステップＳ１０１８）。

ステップＳ１００３に戻り、ハッシュテーブルにレコードが存在する場合（ステップＳ１００３肯定）について説明する。この場合、キャッシュ判定部３２１ｂは、部分特定情報要素（Ｄ１〜ＤＮ）をキー情報として、キャッシュ削除処理を行う（ステップＳ１００４）。なお、キャッシュ削除処理の流れは、実施例１と同様であり、説明を省略する。そして、キャッシュ削除処理が完了すると、キャッシュ判定部３２１ｂは、ステップＳ１００５以降の処理を継続する。

［実施例２の効果］
上述したように、実施例２によれば、キャッシュサーバ３００は、組み合わせに含まれる非特定種類情報を、非特定種類情報に適用される可能性がある特定情報各々に置き換えた組み合わせ各々を生成し、生成した組み合わせ各々についても、データベースサーバ２００により送信されたデータと対応付けてキャッシュ３１１に格納しておく。この結果、その後、キャッシュサーバ３００には、ＡＮＹ要素に対応する特定情報の組み合わせ各々が予めキャッシュ３１１に格納されることになり、キャッシュ３１１のヒット率を向上することが可能となる。

実施例３では、データベースサーバ２００のユーザ情報ＤＢ２１１ｃが、複数の要素からなるキー情報と属性値とに加えて、非特定要素情報を更に対応付けて記憶する。すなわち、以下では、データベースサーバ２００が、データごとに、データが特定される複数種類の特定情報の組み合わせと、組み合わせに含まれる特定情報の種類に含まれる非特定種類を示す非特定種類情報との組み合わせを記憶する場合について説明する。以下では、実施例１と差分がある個所以外の点については、適宜省略する。

［実施例３におけるデータベースサーバの構成］
ユーザ情報ＤＢ２１１ｃは、複数の要素からなるキー情報と属性値とに加えて、非特定要素情報を更に対応付けて記憶する。つまり、ユーザ情報ＤＢ２１１ｃは、データごとに、データが特定される複数種類の特定情報の組み合わせと、組み合わせに含まれる特定情報の種類に含まれる非特定種類を示す非特定種類情報との組み合わせを記憶する。ここで、非特定要素情報とは、キー情報のうち、ＡＮＹとして扱われるサービス特定情報要素を示す情報である。

図２２は、実施例３におけるユーザ情報ＤＢに記憶された情報の一例を示す図である。図２２に示す例では、ユーザ情報ＤＢ２１１ｃは、「キー情報（Ｋ１、Ｋ２、Ｋ３）」と、「非特定要素情報（Ｋ２、Ｋ３）」と、「属性値」とを対応付けて記憶する。図２２に示す例では、非特定要素情報として、「Ｋ２」又は「Ｋ３」がＡＮＹ要素か否かを記憶する場合を示したがこれに限定されるものではなく、任意の情報を用いて良い。

図２２に示す例では、ユーザ情報ＤＢ２１１ｃは、キー情報「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」と、非特定要素情報「Ｋ２：ＡＮＹ」「Ｋ３：ＡＮＹ」と、属性値「データ１」とを含むレコードを記憶する。すなわち、ユーザ情報ＤＢ２１１ｃは、サービス特定情報要素のうち、「ＵｓｅｒＴｙｐｅ−００１」と「ＡｃｃｏｕｎｔＴｙｐｅ−００１」とについては、ＡＮＹ要素であることを記憶する。つまり、ユーザ情報ＤＢ２１１ｃは、属性値「データ１」が、「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＡＮＹ、ＡＮＹ」と共有されることを記憶する。

また、ユーザ情報ＤＢ２１１ｃは、キー情報「ＳｅｒｖｉｃｅＮａｍｅ−００２、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」と属性値「データ１００」とを含み、非特定要素情報にデータがないレコードを記憶する。すなわち、ユーザ情報ＤＢ２１１ｃは、属性値「データ１００」が、「ＳｅｒｖｉｃｅＮａｍｅ−００２、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」以外のキー情報と共有されないことを記憶する。言い換えると、ユーザ情報ＤＢ２１１ｃは、非特定要素情報「ＡＮＹ」がない場合には、属性値が共有されないことを示す。

ＩＲ情報ＤＢ２１２ｃは、ＩＲ情報を記憶する。図２３は、実施例３におけるＩＲ情報ＤＢに記憶された情報の一例を示す図である。図２３に示すように、ＩＲ情報ＤＢ２１２ｃは、「キャッシュサーバ名、キー情報（Ｋ１、Ｋ２、Ｋ３）」として、「キャッシュサーバＡ、ＳｅｒｖｉｃｅＮａｍｅ−００１、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」などを記録する。

キャッシュ応答部２２１ｃは、キャッシュサーバ３００からデータ検索要求を受信すると、受信したデータ検索要求に含まれるサービス特定情報要素（Ｅ１、Ｅ２、Ｅ３）をキー情報として、キー情報がユーザ情報ＤＢ２１１ｃに記憶されているか否かを検索する。ここで、ユーザ情報ＤＢ２１１ｃには、上述したように、非特定要素情報を記憶している。このことを踏まえ、キャッシュ応答部２２１ｃは、データが存在する場合には、キー情報のうち、非特定要素情報がＡＮＹであるカラムの値をＡＮＹ要素に置き換えた上で、置き換えた後のキー情報を部分特定情報要素として属性値とともにキャッシュサーバ３００に送信する。

図２２に示すユーザ情報ＤＢ２１１ｃを例に更に説明する。また、キャッシュサーバ３００からのデータ検索要求に含まれるキー情報が、「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＵｓｅｒＴｙｐｅ−００１、ＡｃｃｏｕｎＴｙｐｅ−００１」である場合を用いて説明する。この場合、キャッシュ応答部２２１ｃは、データ応答として、部分特定情報要素「ＳｅｒｖｉｃｅＮａｍｅ−００１、ＡＮＹ、ＡＮＹ」と属性値「データ１」とを送信する。

つまり、キャッシュ応答部２２１ｃは、キャッシュサーバ３００により送信された受信組み合わせを受信すると、組み合わせと一致する複数種類の特定情報の組み合わせと非特定種類情報との組み合わせを記憶部から取得し、取得した特定情報各々のうち取得した非特定種類情報により示される特定情報を非特定種類情報に置き換えた上で、置き換えた後の組み合わせと、組み合わせに対応付けて記憶されたデータとを送信する。

［実施例３におけるキャッシュサーバの構成］
ＩＲ情報判定部３２２ｃは、データベースサーバ２００から受信したＩＲ情報を用いて、キャッシュ３１１を更新する。例えば、受信したＩＲ情報に「キー情報（Ｋ１、Ｋ２、Ｋ３）」が含まれる場合を用いて説明する。この場合、ＩＲ情報判定部３２２ｃは、受信したＩＲ情報に含まれるキー情報と一致するキー情報が自装置のキャッシュ３１１に存在する場合には、該当する「キー情報（Ｋ１、Ｋ２、Ｋ３）」と、該当するキー情報に対応付けられた属性値を削除することで、キャッシュ３１１を最新化する。

ここで、ＩＲ情報判定部３２２ｃは、削除対象となる属性値に対応付けられた参照元レコード一覧を用いて、削除対象となる属性値を参照する全てのキー情報を削除する。そして、ＩＲ情報判定部３２２ｃは、キャッシュ３１１からレコードを削除した後、受信したＩＲ情報に含まれる「キー情報」をもとに、データベースサーバ２００からＩＲ情報を削除する。つまり、ＩＲ情報判定部３２２ｃは、受信したＩＲ情報に含まれるキー情報を含むＩＲ情報削除要求をデータベースサーバ２００に送信する。

図２０を用いて具体的に説明する。ＩＲ情報に含まれるキー情報（Ｋ１、Ｋ２、Ｋ３）が、「ＳｅｒｖｉｃｅＮａｍｅ−００１、Ｕｓｅｒ Ｔｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」であった場合を用いて説明する。言い換えると、データベースサーバ２００において、「ＳｅｒｖｉｃｅＮａｍｅ−００１、Ｕｓｅｒ Ｔｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」により示される属性値が更新された場合を用いて説明する。

この場合、ＩＲ情報判定部３２２ｃは、該当するキー情報は、任意のカラムが他のキー情報と共有されている可能性があるため、属性値を共有している全てのレコードを削除する。具体的には、ＩＲ情報判定部３２２ｃは、「ＳｅｒｖｉｃｅＮａｍｅ−００１、Ｕｓｅｒ Ｔｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」からハッシュ値を算出する。以下では、算出されたハッシュ値が「１」であるものとして説明する。この場合、ＩＲ情報判定部３２２ｃは、キャッシュ３１１のハッシュテーブルからハッシュ値「１」に対応付けられたレコードＩＤ「１」を取得し、レコードＩＤ「１」を含むレコードをレコードテーブルから取得する。そして、ＩＲ情報判定部３２２ｃは、取得したレコード内の属性情報ＩＤ「０」を取得し、属性情報ＩＤ「０」を含むレコードを属性情報テーブルから取得し、取得したレコードに含まれる参照元レコード一覧で示されるレコードＩＤ「０」「１」「４」を取得する。そして、ＩＲ情報判定部３２２ｃは、レコードＩＤ「０」「１」「４」を含むレコードをレコードテーブルから削除し、属性情報ＩＤ「０」を含むレコードを属性情報テーブルから削除する。そして、ＩＲ情報判定部３２２ｃは、データベースサーバ２００に、「ＳｅｒｖｉｃｅＮａｍｅ−００１、Ｕｓｅｒ Ｔｙｐｅ−００１、ＡｃｃｏｕｎｔＴｙｐｅ−００１」をキー情報として含むＩＲ情報削除要求を送信する。

［実施例３におけるデータベースサーバのキャッシュ応答部による処理の流れ］
図２４は、実施例３におけるデータベースサーバのキャッシュ応答部による処理の流れの一例を示すフローチャートである。

図２４に示すように、キャッシュ応答部２２１ｃは、クライアント１００からデータ検索要求を受信すると（ステップＳ１１０１）、受信したデータ検索要求から、キー情報Ｋ１〜ＫＮを取得する（ステップＳ１１０２）。

そして、キャッシュ応答部２２１ｃは、受信したキー情報を持つレコードが自装置内のユーザ情報ＤＢ２１１ｃに存在するかを検索し、合致したデータを取得する（ステップＳ１１０３）。ここで、キャッシュ応答部２２１ｃは、データが存在する場合には（ステップＳ１１０４肯定）、検索結果の非特定要素情報カラムを”ＡＮＹ要素”に置き換えて、部分特定情報要素と属性値を応答する（ステップＳ１１０５）。つまり、キャッシュ応答部２２１ｃは、検索結果として得られたレコードに含まれるキー情報のうち、非特定要素情報「ＡＮＹ」に対応する要素について、ＡＮＹ要素に置き換えた上で、置き換えられた後のキー情報と属性値とを含むデータ応答をキャッシュサーバ３００に送信する。

一方、ステップＳ１１０４に戻り、自装置内のユーザ情報ＤＢ２１１ｃにデータが存在しない場合には（ステップＳ１１０４否定）、キャッシュ応答部２２１ｃは、キー情報なしを応答する（ステップＳ１１０６）。

［実施例３におけるキャッシュ削除処理の流れ］
図２５は、実施例３におけるキャッシュ削除処理の流れの一例を示すフローチャートである。

図２５に示すように、ＩＲ情報判定部３２２ｃは、削除対象を示すキー情報であるサービス特定情報要素（Ｋ１〜ＫＮ）を取得する（ステップＳ１２０１）。そして、ＩＲ情報判定部３２２ｃは、取得したＫ１〜ＫＮをキー情報としてハッシュ値を算出し、キャッシュ３１１のハッシュテーブルを検索する（ステップＳ１２０２）。

ここで、ＩＲ情報判定部３２２ｃは、ハッシュテーブルに、キー情報Ｋ１〜ＫＮに該当するレコードが存在しない場合には（ステップＳ１２０３否定）、削除対象のレコードは存在しないため、処理を終了する。

一方、キー情報Ｋ１〜ＫＮに対応するレコードが、自装置内のハッシュテーブルに存在する場合には（ステップＳ１２０３肯定）、ＩＲ情報判定部３２２ｃは、該当するレコードから属性情報ＩＤを取得し（ステップＳ１２０４）、属性情報ＩＤで示される属性情報から、参照元レコード一覧を取得する（ステップＳ１２０５）。そして、ＩＲ情報判定部３２２ｃは、参照元レコード一覧の最初のレコードＩＤを取得する（ステップＳ１２０６）。

そして、ＩＲ情報判定部３２２ｃは、取得したレコードＩＤで示されるレコードをレコードテーブルから削除するとともに、削除したレコードのレコードＩＤをハッシュテーブルから削除する（ステップＳ１２０７）。そして、ＩＲ情報判定部３２２ｃは、参照元レコード一覧の全てのレコードＩＤをハッシュテーブルから削除していない場合には（ステップＳ１２０８否定）、参照元レコード一覧の次のレコードＩＤを取得し（ステップＳ１２０９）、ステップＳ１２０７の処理を継続する。一方、ステップＳ１２０８に戻り、参照元レコードの全てのレコードＩＤで示されるレコードをハッシュテーブルから削除した場合には（ステップＳ１２０８肯定）、属性情報テーブルから取得したレコードを削除し（ステップＳ１２１０）、処理を終了する。

［実施例３の効果］
上述したように、実施例３によれば、データベースサーバ２００は、データごとに、データが特定される複数種類の特定情報の組み合わせと、組み合わせに含まれる特定情報の種類に含まれる非特定種類を示す非特定種類情報との組み合わせを記憶する。また、データベースサーバ２００は、特定情報送信部により送信された受信組み合わせを受信すると、組み合わせと一致する複数種類の特定情報の組み合わせと非特定種類情報との組み合わせを記憶部から取得し、取得した特定情報各々のうち取得した非特定種類情報により示される特定情報を非特定種類情報に置き換えた上で、置き換えた後の組み合わせと、組み合わせに対応付けて記憶されたデータとを送信する。この結果、データベースサーバ２００における検索処理を迅速に実行可能となる。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、その他の実施例にて実施されても良い。そこで、以下では、その他の実施例を示す。

例えば、上述した実施例３において、キャッシュサーバ３００が、非特定種類情報を含む組み合わせを受信した場合に、特定情報に含まれる非特定種類情報に適用される可能性がある特定情報各々に特定種類情報を置き換えた組み合わせ各々をデータベースに送信しても良い。

［システム構成］
また、本実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については（図１〜図２５）、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。例えば、キャッシュサーバ３００とデータベースサーバ２００との一部を統合しても良い。

［プログラム］
図２６は、データベースシステムによる処理をプログラムにて実行するための制御プログラムによる情報処理が、コンピュータを用いて具体的に実現されることを示す図である。図２６に例示するように、コンピュータ３０００は、例えば、メモリ３０１０と、ＣＰＵ（Central Processing Unit）３０２０とを有する。コンピュータ３０００の各部はバス３１００によって接続される。

メモリ３０１０は、図２６に例示するように、ＲＯＭ３０１１及びＲＡＭ３０１２を含む。ＲＯＭ３０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。

ここで、図２６に例示するように、ハードディスクドライブ３０８０は、例えば、ＯＳ３０８１、アプリケーションプログラム３０８２、プログラムモジュール３０８３、プログラムデータ３０８４を記憶する。すなわち、開示の技術に係る制御プログラムは、コンピュータによって実行される指令が記述されたプログラムモジュール３０８３として、例えばハードディスクドライブ３０８０に記憶される。具体的には、上記実施例で説明した制御部２２０や制御部３２０と同様の情報処理を実行する手順各々が記述されたプログラムモジュールが、ハードディスクドライブ３０８０に記憶される。

また、上記実施例で説明した記憶部２１０や記憶部３１０に記憶されるデータのように、制御プログラムによる情報処理に用いられるデータは、プログラムデータ３０８４として、例えばハードディスクドライブ３０８０に記憶される。そして、ＣＰＵ３０２０が、ハードディスクドライブ３０８０に記憶されたプログラムモジュール３０８３やプログラムデータ３０８４を必要に応じてＲＡＭ３０１２に読み出し、各種の手順を実行する。

なお、制御プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ハードディスクドライブ３０８０に記憶される場合に限られない。例えば、プログラムモジュール３０８３やプログラムデータ３０８４は、着脱可能な記憶媒体に記憶されても良い。この場合、ＣＰＵ３０２０は、ディスクドライブなどの着脱可能な記憶媒体を介してデータを読み出す。また、同様に、制御プログラムに係るプログラムモジュール３０８３やプログラムデータ３０８４は、ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）等）を介して接続された他のコンピュータに記憶されても良い。この場合、ＣＰＵ３０２０は、ネットワークインタフェース３０７０を介して他のコンピュータにアクセスすることで各種データを読み出す。

［その他］
なお、本実施例で説明した制御プログラムは、インターネットなどのネットワークを介して配布することができる。また、制御プログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

１００ クライアント
２００ データベースサーバ
２０１ 通信制御Ｉ／Ｆ部
２１０ 記憶部
２１１ ユーザ情報ＤＢ
２１２ ＩＲ情報ＤＢ
２２０ 制御部
２２１ キャッシュ応答部
２２２ ＩＲ情報応答部
２２３ ＩＲ情報削除部
２２４ ユーザ情報更新部
３００ キャッシュサーバ
３０１ 通信制御Ｉ／Ｆ部
３１０ 記憶部
３１１ キャッシュ
３２０ 制御部
３２１ キャッシュ判定部
３２２ ＩＲ情報判定部
３２３ 応答処理部
５０１ ネットワーク機器
５０２ ユーザ
５０３ ネットワーク機器
５０４ 認証サーバ
５０５ 網制御サーバ

Claims (5)

1. データごとに、該データを特定するための特定情報と、前記特定情報の複数の種類のうち該データを特定する際に用いられない種類である非特定種類を示す非特定種類情報との組み合わせを記憶する記憶部を有するデータベースと、
   前記記憶部に記憶された前記データの少なくとも一部について、前記特定情報と前記非特定種類情報との組み合わせと、複数種類の前記特定情報の組み合わせとのうち少なくとも一つを対応付けて記憶するキャッシュを有するキャッシュサーバとを有し、
   前記キャッシュサーバは、
   データ要求を受信すると、該データ要求に含まれる複数種類の前記特定情報各々の組み合わせが前記キャッシュに記憶されているかを判定する判定部と、
   前記判定部により記憶されていないと判定された場合に、前記データ要求に含まれる組み合わせを前記データベースに送信する特定情報送信部とを有し、
   前記データベースは、
   前記特定情報送信部により送信された組み合わせを受信すると、受信した組み合わせである受信組み合わせに相当する前記特定情報と前記非特定種類情報との組み合わせと、該特定情報と該非特定種類情報との組み合わせに対応付けられた前記データとを前記記憶部から取得し、前記キャッシュサーバに送信するキャッシュ応答部を有し、
   前記キャッシュサーバは、
   前記キャッシュ応答部により送信された前記特定情報と前記非特定種類情報との組み合わせが前記キャッシュに記憶されている場合には、記憶されていた前記特定情報と前記非特定種類情報との組み合わせに対応付けられるデータと対応付けて、前記受信組み合わせを前記キャッシュに格納し、前記キャッシュに記憶されていない場合には、前記キャッシュ応答部により送信されたデータと対応付けて、前記キャッシュ応答部により送信された前記特定情報と前記非特定種類情報との組み合わせと、前記受信組み合わせとを前記キャッシュに格納する格納部と、
   前記判定部により記憶されていると判定された場合には、前記キャッシュから前記データを取得して前記データ要求の送信元に送信し、前記判定部により記憶されていないと判定された場合には、前記キャッシュ応答部により送信された前記データを前記データ要求の送信元に送信するデータ送信部と
   を有することを特徴とするデータベースシステム。
2. 前記データベースの前記記憶部は、前記データごとに、該データを特定する際に用いられる特定情報種類に属する前記特定情報と、前記非特定種類情報との組み合わせを対応付けて記憶し、
   前記キャッシュ応答部は、前記特定情報送信部により送信された前記受信組み合わせを受信すると、該組み合わせに相当する前記特定情報と前記非特定種類情報との組み合わせの一つを選択し、選択した前記特定情報と前記非特定種類情報との組み合わせと、選択した該組み合わせに対応付けて記憶された前記データとを送信することを特徴とする請求項１に記載のデータベースシステム。
3. 前記データベースの前記記憶部は、前記データごとに、該データが特定される複数種類の前記特定情報の組み合わせと、該組み合わせに含まれる特定情報の種類のうち非特定種類となる特定情報を示す非特定種類情報との組み合わせを記憶し、
   前記キャッシュ応答部は、前記特定情報送信部により送信された前記受信組み合わせを受信すると、該組み合わせと一致する前記特定情報の組み合わせと前記非特定種類情報との組み合わせを前記記憶部から取得し、取得した該特定情報各々のうち取得した該非特定種類情報により示される特定情報を該非特定種類情報に置き換えた上で、置き換えた後の該組み合わせと、該組み合わせに対応付けて記憶された前記データとを送信することを特徴とする請求項１に記載のデータベースシステム。
4. 前記格納部は、前記キャッシュ応答部により送信された前記組み合わせに含まれる前記非特定種類情報を、該非特定種類情報に適用される可能性がある特定情報各々に置き換えた組み合わせ各々を生成し、生成した組み合わせ各々についても、該キャッシュ応答部により送信されたデータと対応付けて前記キャッシュに格納することを特徴とする請求項１〜３のいずれか一つに記載のデータベースシステム。
5. データごとに、該データを特定するための特定情報と、前記特定情報の複数の種類のうち該データを特定する際に用いられない種類である非特定種類を示す非特定種類情報との組み合わせを記憶する記憶部を有するデータベースと、
   前記データベースに記憶された前記データの少なくとも一部について、前記特定情報と前記非特定種類情報との組み合わせと、複数種類の前記特定情報の組み合わせとのうち少なくとも一つを対応付けて記憶するキャッシュを有するキャッシュサーバとを有するデータベースシステムで実行される制御方法であって、
   前記キャッシュサーバが、データ要求を受信すると、該データ要求に含まれる複数種類の前記特定情報各々の組み合わせが前記キャッシュに記憶されているかを判定する判定工程と、
   前記キャッシュサーバが、前記判定工程により記憶されていないと判定された場合に、前記データ要求に含まれる組み合わせを前記データベースに送信する特定情報送信工程と、
   前記データベースが、前記特定情報送信工程により送信された組み合わせを受信すると、受信した組み合わせである受信組み合わせに相当する前記記憶部に記憶された前記特定情報と前記非特定種類情報との組み合わせと、該特定情報と該非特定種類情報との組み合わせに対応付けられた前記データとを前記記憶部から取得し、前記キャッシュサーバに送信するキャッシュ応答工程と、
   前記キャッシュサーバが、前記キャッシュ応答工程により送信された前記特定情報と前記非特定種類情報との組み合わせが前記キャッシュに記憶されている場合には、記憶されていた前記特定情報と前記非特定種類情報との組み合わせに対応付けられるデータと対応付けて、前記受信組み合わせを前記キャッシュに格納し、前記キャッシュに記憶されていない場合には、前記キャッシュ応答工程により送信されたデータと対応付けて、前記キャッシュ応答部により送信された前記特定情報と前記非特定種類情報との組み合わせと、前記受信組み合わせとを前記キャッシュに格納する格納工程と、
   前記キャッシュサーバが、前記判定工程により記憶されていると判定された場合には、前記キャッシュから前記データを取得して前記データ要求の送信元に送信し、前記判定工程により記憶されていないと判定された場合には、前記キャッシュ応答工程により送信された前記データを前記データ要求の送信元に送信するデータ送信工程と
   を含むことを特徴とする制御方法。

Images