JPH10111821A - クライアント・サーバー・システム - Google Patents

Abstract

(57)【要約】 【課題】 データベース検索を効率的に行うクライアン
ト・サーバー・システムを提供する。 【解決手段】 クライアント２０からサーバー１０に検
索コマンドが発行される前に、その検索コマンドと同一
の検索コマンドによる検索結果がキャッシュ記憶部ＣＭ
にあるか否かが第２のテーブルＴ２に基づいて判定さ
れ、その判定結果が肯定である場合には、その検索結果
の対象となる表のバージョン情報がサーバー１０の第１
のデータテーブルＴ１に保持されている表のバージョン
情報と一致するか否かが判定され、その判定結果が肯定
であれば、キャッシュ記憶部ＣＭに保持されている検索
結果がアプリケーションＡ４に提供される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データベース検索
を行うクライアント・サーバー・システムに関する。

【０００２】

【従来の技術】近年、ＬＡＮ(Local Area Network)によ
って構築されたクライアント・サーバー・システムが提
案されており、そのクライアント・サーバー・システム
によって電子メールの送受信、施設予約、電子承認、文
書管理等の様々な処理を効率的に行うアプリケーション
が提供されている。このようなアプリケーションを実行
する際には、クライアント側からサーバー側のデータベ
ースを検索することが多い。データベース検索は、通
常、クライアントからサーバーに対して、ＳＱＬ等で表
現された検索コマンドが発行され、サーバーは、受付け
た検索コマンドに従って検索を行い、その検索結果がサ
ーバーからクライアントに返されるといった手順で処理
される。

【０００３】例えば、電子メールを送信するアプリケー
ションを実行する場合には、次に示すような手順のデー
タベース検索がなされる。すなわち、電子メールの宛先
を指定するために、まず、所属部署名（所属部署コード
を含む）の一覧表を表示させて、その一覧表から目的の
所属部署を指定することにより、選択した所属部署に属
する社員名の一覧表（社員コードを含む）を表示させ、
次いで、その一覧表から目的の社員名を選択するといっ
た検索処理を行う。このような検索処理を行う際には、
社員名簿データベースから所属部署名の一覧表及び社員
名の一覧表を検索する必要がある。ところで、電子メー
ルの宛先を検索する度に、比較的更新頻度が少ない所属
部署名の一覧表や社員名の一覧表等の情報を社員名簿デ
ータベースから検索すると、クライアント及びサーバー
間において更新されていない同一の情報を検索するため
の通信が増えることになる。この結果、通信回線を有効
に活用することができず、クライアント側においては、
検索処理に要する時間が増大し、サーバー側において
は、更新されていない同一の情報に関する検索処理の負
荷が増大するといった問題が生じる。このような問題
は、比較的更新頻度が少ない情報をデータベースから何
度も検索するようなアプリケーションにおいて同様に発
生する。

【０００４】

【発明が解決しようとする課題】上記問題を解消するた
めには、頻繁に検索する情報をクライアント側に予め保
持しておく方法も考えられるが、この方法では、クライ
アント側で保持している情報の内容をサーバーのデータ
ベースと同一に維持するために、情報が更新される度に
各クライアント側のソフトウェアに対する保守作業を個
別に行う必要があるので、実用的ではない。また、他の
方法として、クライアント及びサーバーを同じレベルに
属する分散データベースとして扱い、クライアント及び
サーバーのそれぞれが同一のデータベースを有して管理
するようにすることも考えられる。この方法では、サー
バー又はクライアントのいずれかのデータベースが更新
された際には、残りのサーバー又はクライアントのデー
タベースを同様に更新できるように、サーバー及びクラ
イアントの全てを常時稼働状態に維持する必要があり、
多数のクライアントを有して構成されるシステムとして
は実用的とはいえない。本発明は、このような事情に基
づいてなされたもので、その目的は、データベースを検
索する場合にクライアント・サーバー間の通信量を可及
的に減らすことにより、通信回線を有効に活用すること
ができ、クライアント側においては検索処理スピードを
向上させることができ、かつサーバー側においては検索
処理及び通信処理の負荷を軽減することができるクライ
アント・サーバー・システムを提供することにある。ま
た、本発明の他の目的は、従来システムを大幅に改修す
ることなく上記クライアント・サーバー・システムを実
現できるようにすることにある。

【０００５】

【課題を解決するための手段】請求項１に係る発明は、
図６に示されているように、１以上の表から構成される
データベースを管理するサーバー１０と、データベース
ＤＢに対する検索コマンドをサーバーに発行するアプリ
ケーションＡＰを備えたクライアント２０とを有してな
るクライアント・サーバー・システムにおいて、サーバ
ー１０には、データベースの表名と、データベースの表
の改訂を識別するためのバージョン情報とを対応して格
納する第１のデータテーブルを設け、クライアント２０
には、データベースの検索結果ファイルを格納するキャ
ッシュ記憶部と、サーバー１０に既に発行した検索コマ
ンド、その検索コマンドの検索対象となったデータベー
スＤＢの表のバージョン情報及び検索コマンドにより検
索されてキャッシュ記憶部ＣＭに格納された検索結果フ
ァイルの名称を関連付けて格納する第２のデータテーブ
ルＴ２とを設けるとともに、アプリケーションＡＰによ
って生成された検索コマンドが第２のデータテーブルＴ
２に存在するか否かを判定する検索コマンド照合手段Ａ
１と、検索コマンド照合手段Ａ１の判定結果が肯定であ
るときに、サーバー１０から取得した第１のデータテー
ブルＴ１より検索コマンドに対応する表のバージョン情
報を読出すバージョン情報読出手段Ａ２と、読出したバ
ージョン情報と、第２のデータテーブルＴ２に存在する
検索コマンドに対応する表のバージョン情報とが一致す
るか否かを判定するバージョン情報判定手段Ａ３と、バ
ージョン情報判定手段Ａ３によって双方のバージョン情
報が一致すると判定されたときに、第２のデータテーブ
ルＴ２から検索コマンドに対応する検索結果ファイルの
名称を特定し、その検索結果ファイルの名称に基づい
て、キャッシュ記憶部ＣＭに格納されている検索結果フ
ァイルを読出してアプリケーションＡＰに提供するキャ
ッシュ読出手段Ａ４と、検索コマンド照合手段Ａ１又は
バージョン情報判定手段Ａ３の判定結果が否定であると
きに、アプリケーションＡＰにより生成された検索コマ
ンドをサーバー１０に発行してサーバー１０から取得し
た検索結果ファイルをキャッシュ記憶部ＣＭに格納する
とともに、取得した検索結果ファイルに対応する検索コ
マンド、バージョン情報及び検索結果ファイルの名称を
第２のデータテーブルＴ２に格納する検索処理手段Ａ５
とを設けたことを特徴としている。上記構成によれば、
クライアント２０からサーバー１０に検索コマンドが発
行される前に、その検索コマンドと同一の検索コマンド
による検索結果がキャッシュ記憶部ＣＭにあるか否かが
第２のテーブルＴ２に基づいて判定され、その判定結果
が肯定である場合には、その検索結果の対象となる表の
バージョン情報がサーバー１０の第１のデータテーブル
Ｔ２に保持されている表のバージョン情報と一致するか
否かが判定され、その判定結果が肯定であれば、キャッ
シュ記憶部ＣＭに保持されている検索結果がアプリケー
ションに提供される。したがって、クライアントからサ
ーバーに対する検索コマンドの発行はなされない。

【０００６】

【発明の実施の形態】次に、本発明の実施の形態につい
て図面を参照して説明する。図１は、本実施の形態のク
ライアント・サーバー・システムのブロック図である。
サーバー１０は、ＣＰＵ１１、キーボード等の入力装置
１２、ディスプレイ等の出力装置１３及び記憶装置１４
を有している。記憶装置１４は、１以上の表からなる従
来と同様のデータベースＤＢと、本発明において新たに
追加された第１のデータテーブルＴ１とから構成されて
いる。また、ＣＰＵ１１には、制御プログラム等を記憶
保持するためのＲＯＭ及び作業領域を提供する主記憶メ
モリを構成するＲＡＭが接続されているが、これらのＲ
ＯＭ及びＲＡＭについては、図示を省略している。

【０００７】上記サーバー１０に複数のクライアント２
０が接続されることによりＬＡＮが構成されている。各
クライアント２０は、ＣＰＵ２１、キーボード等の入力
装置２２、ディスプレイ等の出力装置２３及び記憶装置
２４を有している。記憶装置２４には、従来と同様にア
プリケーションプログラムを記憶するアプリケーション
部ＡＰの他に、本発明において新たに追加されたキャッ
シュ記憶部ＣＭ及び第２のデータテーブルＴ２を有して
いる。なお、サーバー１０の記憶装置１４及びクライア
ント２０の記憶装置２４は、従来システムと同様に、い
ずれも電源切断時に記憶内容が失われない記憶装置であ
ればよく、ハードディスク装置によって構成されている
のが普通であるが、これに限定されるものではない。ま
た、サーバー１０側と同様に、ＣＰＵ２１には、制御プ
ログラム等を記憶保持するためのＲＯＭ及び作業領域を
提供する主記憶メモリを構成するＲＡＭが接続されてい
るが、これらのＲＯＭ及びＲＡＭについても、図示を省
略している。

【０００８】図２は、サーバー１０のデータベースＤＢ
を構成する表の説明図である。データベースＤＢは、表
形式で表現されるリレーショナルデータベース（関連デ
ータベース）の形式であり、図２に示すように、表は、
属性名（例えば、職員コード、職員名、室課コード、室
課名）に対応して属性値（変数）を配列することにより
構成される。通常、データベースＤＢは、図２と同様の
形式の表を複数個有している。各表には、その表の改訂
を識別するためのバージョン情報Ｄｖが付されている。
このバージョン情報Ｄｖは、その表の内容が更新される
度に変更されるようになっている。バージョン情報Ｄｖ
の形式は限定されるものではなく、例えば更新年月日等
でもよいし、更新の度に変更されるバージョン番号であ
ってもよい。

【０００９】図３は、サーバー１０の記憶装置１４に設
けられている第１のデータテーブルＴ１の一例を示す説
明図である。データテーブルＴ１は、上記データベース
ＤＢに格納されている表の表名Ｔｎと、当該表のバージ
ョン情報Ｄｖとが対応して格納されている。したがっ
て、データテーブルＴ１に基づいて表名Ｔｎからそれに
対応するバージョン情報Ｄｖを読み出すことができるよ
うになっている。

【００１０】図４は、クライアント２０の記憶装置２４
に設けられている第２のデータテーブルＴ２の一例を示
す説明図である。データテーブルＴ２は、クライアント
２０のアプリケーション部ＡＰに格納されているアプリ
ケーションから発行される検索コマンドＣｓと、その検
索コマンドによって検索される対象となるデータベース
ＤＢの各表のバージョン情報Ｄｖと、上記検索コマンド
Ｃｓによって検索された検索結果のデータを保持する検
索結果ファイルのファイル名Ｆｎとをそれぞれ関連付け
て記憶するものである。検索結果ファイルは、そのファ
イル名Ｆｎとともに、図１に示されているクライアント
２０の記憶装置２４のキャッシュ記憶部ＣＭに格納され
るようになっている。なお、図４において、表のバージ
ョン情報Ｄｖを格納する欄には、次述するような検索コ
マンドＣｓに記述されている１又は複数の表名に対応す
る表のバージョン情報が、検索コマンドＣｓに記述され
ている表名の順番に対応する順番で格納されるようにな
っている。図４においては、表のバージョン情報Ｄｖが
４個格納される場合を示しているが、バージョン情報Ｄ
ｖの格納数は、検索コマンドＣｓに記述される表名の個
数に合わせて適宜設定すればよい。

【００１１】図５は、この実施の形態によるクライアン
ト・サーバー・システムによるデータベースの検索処理
を示すフローチャートである。この検索処理は、クライ
アント２０側でアプリケーションが実行される過程にお
いて、データベースＤＢに対する検索が必要となった場
合に実行されるようになっている。まず、クライアント
２０のＣＰＵ２１は、アプリケーションが必要とする情
報を得るために必要な検索コマンドＣｓを生成する（ス
テップＳ１）。この検索コマンドは、次に例示するよう
なＳＱＬ文によって示される。 「select 職員コード，職員名 from 表１ where 室
課コード＝“10”」 すなわち、selectの次に検索対象となる属性名を１又は
複数記述し、fromの次に検索対象となる表名を１又は複
数記述し、where の次に条件を記述する。この条件とし
ては、例えば、検索対象となる表における属性値（変
数）を記述する。上述の例では、条件として、selectの
次に記述した属性名（職員コード及び職員名）と異なる
属性名（室課コード）の属性値（“10”）を記述してい
る。なお、実際のＳＱＬ文は、文字列で記述される。

【００１２】次に、クライアント２０のＣＰＵ２１は、
上記検索コマンドＣｓが、第２のデータテーブルＴ２に
存在するか否かを判定する（ステップＳ２）。同一の検
索コマンドがデータテーブルＴ２に存在していれば（ス
テップＳ２で肯定（“Ｙ”））、クライアント側のＣＰ
Ｕ２１は、サーバー１０の記憶装置２４に格納されてい
る第１のデータテーブルＴ１を読出して取得する（ステ
ップＳ３）。

【００１３】そして、ステップＳ３で取得した第１のデ
ータテーブルＴ１にある上記検索コマンドＣｓに対応す
る表名のバージョン情報Ｄｖを、第２のデータテーブル
Ｔ２に存在する上記検索コマンドＣｓに対応する表名の
バージョン情報Ｄｖと一致するか否かを判定する（ステ
ップＳ４）。

【００１４】次いで、ステップＳ４の判定結果が肯定
（“Ｙ”）であれば、第２のデータテーブルＴ２に保持
されている検索結果ファイル名Ｆｎに基づいて、キャッ
シュ記憶部ＣＭに格納されている検索結果ファイルを読
出す（ステップＳ５）。この後、アプリケーションは、
ステップＳ５で読出した検索結果ファイルを検索コマン
ドＣｓに対応する検索結果として用いて処理を実行す
る。

【００１５】一方、ステップＳ２の判定結果が否定
（“Ｎ”）である場合、又は、ステップＳ４の判定結果
が否定（“Ｎ”）である場合には、キャッシュ記憶部Ｃ
Ｍに目的とする検索結果のファイルが存在しないことを
示している。したがって、上記検索コマンドＣｓをサー
バー１０に発行し（ステップＳ６）、サーバー１０から
検索結果を取得する（ステップＳ７）。この検索結果に
は、検索対象となった表のバージョン情報Ｄｖも含まれ
ている。そして、取得した検索結果をキャッシュ記憶部
ＣＭに格納する（ステップＳ８）とともに、ステップＳ
６で発行した検索コマンドＣｓと、その検索コマンドＣ
ｓによって検索された表名のバージョン情報Ｄｖと、キ
ャッシュ記憶部ＣＭに格納した検索結果のファイル名Ｆ
ｎとを関連付けて第２のデータテーブルＴ２に記憶する
（ステップＳ９）。この後、前述の場合と同様に、アプ
リケーションは、ステップＳ７で読出した検索結果ファ
イルを検索コマンドＣｓに対応する検索結果として用い
て処理を実行する。なお、データテーブルＴ１の取得を
行うステップＳ３は、ステップＳ２の前に実行してもよ
い。しかし、その場合には、ステップＳ２の判定結果が
否定となった場合に、取得したデータテーブルＴ１が用
いられないので、処理が無駄になる欠点がある。

【００１６】また、クライアントからサーバーに対して
データベースの内容を更新する更新コマンド、データベ
ースの内容にデータを付け加える挿入コマンド、及びデ
ータベースの内容を部分的に削除する削除コマンドのい
ずれかが発行された場合には、サーバー側においてその
コマンドが実行された後、表のバージョン情報Ｄｖが更
新されるとともに、第１のデータテーブルＴ１におい
て、該当する表に対応するバージョン情報Ｄｖも更新さ
れるようになっている。また、クライアント２０側にお
いて、上述の手順によって内容の更新、挿入又は削除が
なされた後のデータベースを用いて処理を行う必要が生
じた場合には、クライアント２０からサーバー１０に対
して改めて検索コマンドを発行する。すると、図５のス
テップＳ４でデータテーブルＴ１，Ｔ２のバージョン情
報が不一致となるため、ステップＳ６〜Ｓ９が実行され
ることにより、クライアント２０側の第２のデータテー
ブルＴ２のバージョン情報Ｄｖが更新される。なお、ク
ライアントからのコマンドによらず、サーバー単独でデ
ータベースの内容を更新する際にも、第１のデータテー
ブルのバージョン情報Ｄｖの更新がなされることはもち
ろんである。

【００１７】上述した実施の形態によれば、クライアン
ト側から検索コマンドが発行される前に、その検索コマ
ンドと同一の検索コマンドによる検索結果がキャッシュ
記憶部ＣＭにあり、かつ、その検索結果の対象となる表
のバージョン情報Ｄｖがサーバー側に保持されている表
のバージョン情報Ｄｖと一致すれば、キャッシュ記憶部
ＣＭの検索結果がアプリケーションに提供される。した
がって、サーバーに対する検索コマンドの発行を行わな
くて済む。この結果、クライアント・サーバー間におい
て、更新されていない同一の情報に関する通信を減らす
ことにより通信回線を有効に活用することができる。ま
た、クライアント側においては、キャッシュ記憶部ＣＭ
に保持されている検索結果をアプリケーションに提供す
ればよいので、サーバーから検索結果を取得する場合に
比較して検索処理スピードを向上させ、かつ、通信処理
の負荷を軽減することができる。さらに、サーバー側に
おいても、検索処理の負荷が軽減される。また、同一の
クライアントからサーバーへの検索は、同一の表を検索
対象とすることが多いので、クライアント・サーバー・
システム全体としてサーバーへの検索回数を大幅に低下
させることが可能である。したがって、クライアント・
サーバー間を結ぶ通信回線の容量が小さな場合でも、ま
た、クライアント及びサーバーの処理能力が低い場合で
も、データベースの検索処理を効率的に行うことができ
る。

【００１８】本実施の形態では、サーバー１０側の記憶
装置１４にデータベースＤＢの表名と、データベースＤ
Ｂの表の改訂を識別するためのバージョン情報Ｄｖとを
対応して格納するデータテーブルＴ１を設けるととも
に、クライアント２０側の記憶装置２４にデータベース
Ｄｖの検索結果ファイルを格納するキャッシュ記憶部Ｃ
Ｍ及びサーバー１０に既に発行した検索コマンドＣｓ、
その検索コマンドＣｓの検索対象となったデータベース
ＤＢの表のバージョン情報Ｄｖ及び検索コマンドＣｓに
より検索されてキャッシュ記憶部ＣＭに格納された検索
結果ファイルの名称を関連付けて格納する第２のデータ
テーブルＴ２を設けているので、新たに記憶手段を構成
するハードウェアを増設する必要がないという利点があ
る。

【００１９】また、クライアント及びサーバー間の通信
処理と、データベースＤＢに対する検索処理とは、従来
システムと概ね同じで済むため、検索処理のソフトウェ
アの変更は最小限で済む。したがって、既に開発済みの
クライアント・サーバー・システムに本発明を適用する
場合であっても、ソフトウェアの改修量は少なくてよ
い。

【００２０】なお、キャッシュ記憶部の記憶容量が不足
した場合には、キャッシュ記憶部に格納されている検索
結果ファイルを削除する必要が生じる。この場合には、
使用する可能性の低い検索結果ファイルから順次削除す
ることが、クライアント・サーバー間における通信処理
を減らすことができる点で好ましい。このような機能を
実現するための構成の一例を示すと、クライアント２０
側に、キャッシュ記憶部ＣＭに格納されている検索結果
ファイルの読出回数を計数するとともに、その読出回数
を検索結果ファイルに対応して保持する読出回数計数手
段と、キャッシュ記憶部ＣＭに検索結果ファイルを書き
込むためにキャッシュ記憶部ＣＭに格納されている検索
結果ファイルを削除する必要が生じた場合に、上記読出
回数計数手段が保持する読出回数が少ない検索結果ファ
イルを優先して削除するとともに、所定期間毎（例えば
１か月毎）に読出回数計数手段が保持する各検索結果フ
ァイルの読出回数を一定率で減少させる検査結果ファイ
ル管理手段とを設ければよい。上記構成例によれば、キ
ャッシュ記憶部ＣＭの記憶容量が不足した場合には、使
用回数の少ない検索結果ファイルから順次削除され、使
用回数の多い検索結果ファイルは残される。また、所定
期間毎に読出回数計数手段が保持する各検索結果ファイ
ルの読出回数を一定率で減少させるので、当初の読出回
数が同一であっても、時間経過に伴って、直近の読出時
期が古い検索結果ファイルから順番に削除される。した
がって、使用する可能性の高い、すなわち読出回数が高
く、かつ、直近の読出時期が新しい検索結果ファイルが
キャッシュ記憶部ＣＭに優先的に保存される。

【００２１】ここで、図５のフローチャート及び図６の
クレーム対応図を参照して、上述した実施の形態と請求
の範囲の記載との対応を説明する。図５のフローチャー
トで示したステップＳ２の処理を行うクライアント側の
ＣＰＵ２１が図６の検索コマンド照合手段Ａ１に相当し
ている。同様に図５のステップＳ３の処理を行うＣＰＵ
２１が、図６のバージョン情報読出手段Ａ２に相当して
いる。また、図５のステップＳ４の処理を行うＣＰＵ２
１が、図６のバージョン情報判定手段Ａ３に相当してい
る。図５のステップＳ５の処理を行うＣＰＵ２１が図６
のキャッシュ読出手段Ａ４に相当している。図５のステ
ップＳ６〜Ｓ９の処理を行うＣＰＵ２１が、図６の検索
処理手段Ａ５に相当している。

【００２２】ところで、本発明に類似した技術として、
インターネットの情報検索システムにおける検索ソフト
ウェア（ブラウザ）によって提供されるキャッシュ機能
がある。このキャッシュ機能と本発明との相違について
説明しておく。上記キャッシュ機能は、ユーザ側のパー
ソナルコンピュータの記憶装置（ハードディスク）にキ
ャッシュ領域を設定しておき、ユーザ側がＵＲＬ(Unifo
rum Resource Locator) を入力してインターネットのサ
ーバーから該当する情報を転送するように要求したとき
に、サーバーは、情報を送り出す前に、その情報の最終
更新日時をユーザに送り、ユーザは、その最終更新日時
とキャッシュ領域に保持している情報の更新日時とを比
較して、キャッシュ領域の情報が最新であれば、キャッ
シュの情報を読込んで表示し、最新でなければ、要求し
た情報をサーバーから受け取って表示するとともに、キ
ャッシュ領域の情報を更新するものである。

【００２３】したがって、このキャッシュ機能では、ユ
ーザからの情報転送の要求に対してサーバーから提供さ
れた情報がファイル単位でキャッシュ領域に格納されて
いるに過ぎない。したがって、ユーザ側がサーバー側へ
コマンドを発行し、そのコマンドに対応した処理がなさ
れた情報を受け取るような用途では、受け取った情報を
キャッシュ領域に保持するのみであって、ユーザ側は、
その情報がどのようなコマンドによって取得されたとい
う関係付けを認識していない。このため、あるコマンド
を発行しようとする際に、以前に同一のコマンドにより
取得された情報がキャッシュ領域に保持されていたとし
ても、同一のコマンドを再度発行して情報を検索し直さ
なければならないという欠点がある。

【００２４】これに対して、本発明に係るクライアント
・サーバー・システムでは、クライアントからサーバー
に発行された検索コマンドをクライアントの第２のデー
タテーブルに保持しているので、検索コマンドに対応す
る検索結果がキャッシュ記憶部ＣＭに存在するか否かを
判定することができる。したがって、本発明システム
は、上述したようなインターネットの情報検索システム
における検索ソフトウェアの場合とは異なり、クライア
ント側が、既にキャッシュ領域に同一の情報を保持して
いるにも関わらず、再度検索し直す必要がないという利
点がある。

【００２５】

【発明の効果】以上詳述したように、本発明のクライア
ント・サーバー・システムによれば、クライアントから
サーバーのデータベースに検索コマンドを発行して、サ
ーバーから検索結果を得る場合に、クライアントのキャ
ッシュ記憶手段に上記検索コマンドに対応した検索結果
が保持されていれば、クライアントからサーバーに対す
る検索コマンドの発行を行わないので、クライアント・
サーバー間における通信を減らすことができるため、通
信回線を有効に活用することができ、クライアント側に
おいてはサーバーから検索結果を取得する場合に比較し
て検索処理スピードを向上させることができ、かつサー
バー側においても検索処理及び通信処理の負荷を軽減す
ることができる。また、同一のクライアントからサーバ
ーへの検索は、同一の表を検索対象とすることが多いの
で、クライアント・サーバー・システム全体としてサー
バーへの検索回数を大幅に低下させることが可能であ
る。したがって、クライアント・サーバー間を結ぶ通信
回線の容量が小さな場合でも、また、クライアント及び
サーバーの処理能力が低い場合でも、データベースの検
索処理を効率的に行うことができる。

【００２６】また、本発明によれば、従来システムにお
ける検索処理及び通信処理については、これを大幅に変
更する必要がない。したがって、既に完成されているク
ライアント・サーバー・システムに本発明を適用する場
合には、新たに第１及び第２のデータテーブルと、キャ
ッシュ記憶部とを設けるといったごく簡単な改修を行う
だけでよく、ソフトウェアの改修量が少なくて済むとい
う利点がある。

【００２７】また、クライアント及びサーバーのそれぞ
れに同一のデータベースを設けることにより、クライア
ント及びサーバー間の通信処理及び検索処理を軽減を図
ろうとする場合には、各データベースの内容を同一に維
持するためにサーバ及びクライアントの全てを常時稼働
状態に維持しておくとともに、クライアント側にも、サ
ーバー側と同じ記憶容量の記憶手段を設ける必要がある
のに対して、本発明では、クライアント及びサーバーに
同一のデータベースを設けないから、サーバー及びクラ
イアントを常時稼働状態に維持する必要はなく、かつ、
クライアント側の記憶手段の記憶容量は、サーバー側の
それに比較して大幅に少ないものでよいという利点があ
る。

【図面の簡単な説明】

【図１】図１は、本実施の形態のクライアント・サーバ
ー・システムの構成を示すブロック図である。

【図２】サーバーのデータベースを構成する表の説明図
である。

【図３】サーバーの第１のデータテーブルの説明図であ
る。

【図４】クライアントの第２のデータテーブルの説明図
である。

【図５】データベースの検索処理を示すフローチャート
である。

【図６】本発明のクレーム対応図である。

【符号の説明】

１０ サーバー ＤＢ データベース Ｔ１ 第１のデータテーブル ２０ クライアント ＣＭ キャッシュ記憶部 ＡＰ アプリケーション Ｔ２ 第２のデータテーブル Ａ１ 検索コマンド照合手段 Ａ２ バージョン情報読出手段 Ａ３ バージョン情報判定手段 Ａ４ キャッシュ読出手段 Ａ５ 検索処理手段

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 ＦＩ Ｇ０６Ｆ 15/40 ３８０Ｄ 15/401 ３４０Ｂ

Claims (1)

【特許請求の範囲】
1. 【請求項１】 １以上の表から構成されるデータベース
   を管理するサーバーと、前記データベースに対する検索
   コマンドを前記サーバーに発行するアプリケーションを
   備えたクライアントとを有してなるクライアント・サー
   バー・システムにおいて、 前記サーバーには、前記データベースの表名と、前記デ
   ータベースの表の改訂を識別するためのバージョン情報
   とを対応して格納する第１のデータテーブルを設け、 前記クライアントには、前記データベースの検索結果フ
   ァイルを格納するキャッシュ記憶部と、前記サーバーに
   既に発行した検索コマンド、その検索コマンドの検索対
   象となった前記データベースの表のバージョン情報及び
   前記検索コマンドにより検索されて前記キャッシュ記憶
   部に格納された検索結果ファイルの名称を関連付けて格
   納する第２のデータテーブルとを設けるとともに、前記
   アプリケーションによって生成された検索コマンドが前
   記第２のデータテーブルに存在するか否かを判定する検
   索コマンド照合手段と、前記検索コマンド照合手段の判
   定結果が肯定であるときに、前記サーバーから取得した
   前記第１のデータテーブルより前記検索コマンドに対応
   する表のバージョン情報を読出すバージョン情報読出手
   段と、前記読出したバージョン情報と、前記第２のデー
   タテーブルに存在する前記検索コマンドに対応する表の
   バージョン情報とが一致するか否かを判定するバージョ
   ン情報判定手段と、前記バージョン情報判定手段によっ
   て前記双方のバージョン情報が一致すると判定されたと
   きに、前記第２のデータテーブルから前記検索コマンド
   に対応する前記検索結果ファイルの名称を特定し、その
   検索結果ファイルの名称に基づいて、前記キャッシュ記
   憶部に格納されている検索結果ファイルを読出して前記
   アプリケーションに提供するキャッシュ読出手段と、前
   記検索コマンド照合手段又は前記バージョン情報判定手
   段の判定結果が否定であるときに、前記アプリケーショ
   ンにより生成された検索コマンドを前記サーバーに発行
   して前記サーバーから取得した検索結果ファイルを前記
   キャッシュ記憶部に格納するとともに、取得した検索結
   果ファイルに対応する検索コマンド、バージョン情報及
   び検索結果ファイルの名称を第２のデータテーブルに格
   納する検索処理手段とを設けたこと、 を特徴とするクライアント・サーバー・システム。