"自己が最新のデータベースの内容を保有しているか否かを示す情報である更新権と、差分検索又はデータベースの同期の相手となる他のクライアントを特定する情報である問い合わせ先と、自己のデータベースの内容がデータベースシステム内で最新であるか否かを示す情報である最新保証情報を記憶する記憶手段と、前記更新権が自己が更新権を有していること示している場合、自己のデータベースと同一のバージョンであるデータベースを有する他のクライアントに、そのデータベースの内容が最新であることが保証された状態であることを通知する最新保証通知を送信する最新保証通知手段と、前記更新権の内容が自己が更新権を有していることを示す情報から自己が更新権を有していないこと示している情報に書き換えられた場合、前記最新保証通知を送信した他のクライアントに、そのデータベースの内容が最新であることが保証されない状態であること通知する最新保証切れ通知を送信する最新保証切れ通知手段と、前記最新保証通知を受信した場合前記最新保証情報の内容をそのデータベースの内容が最新であることが保証された状態を示す情報に書き換え、前記最新保証切れ通知を受信した場合前記最新保証情報の内容をそのデータベースの内容が最新であることが保証されない状態であることを示す情報に書き換える最新保証情報管理手段と、前記問い合わせ先に差分通知要求を送信する差分通知要求手段と、自己のデータベースと当該他のクライアントのデータベースの差分を通知する差分通知を生成し、差分通知を当該他のクライアントに送信する差分通知手段と、他のクライアントから差分通知要求を受信した場合、前記最新保証情報の内容がそのデータベースの内容が最新であることが保証された状態を示す情報であるときには前記差分通知手段に差分通知を当該他のクライアントに送信させ、前記最新保証情報の内容をそのデータベースの内容が最新であることが保証されない状態であることを示す情報であるときには、前記差分通知手段に前記問い合わせ先に宛てて差分通知要求を送信させる判定手段とを有することを特徴とするクライアント。前記判定手段は、最新保証を行うために必要なデータ送信量が、最新保証を行うことによって減少させることができるデータ送信量以下であるか否かを判定し、最新保証を行うために必要なデータ送信量が、最新保証を行うことによって減少させることができるデータ送信量以下である場合に、前記最新保証通知手段に最新保証通知の送信を行わせることを特徴とする、請求項1に記載のクライアント。前記判定手段は、正規化済みの検索確率Pが更新確率1-P以上であれば、最新保証を行うために必要なデータ送信量が、最新保証を行うことによって減少させることができるデータ送信量以下であると判定することを特徴とする、請求項2に記載のクライアント。前記判定手段は、前記検索確率Pとしてある一定期間の検索の頻度を用い、前記更新確率1-Pとして更新の頻度を用いて、正規化済みの検索確率Pが更新確率1-P以上であるか否かを判定することを特徴とする、請求項3に記載のクライアント。前記請求項1から4までのいずれかに記載の複数のクライアントを有するデータベースシステム。従来のサーバを利用するシステムでは、サーバの集中管理が必要であり、サーバの負荷を究極的に減らすことが困難であるという問題があった。サーバの負荷を究極的に減らす方法としては、サーバを利用しないシステムとすることが考えられるが、そのようなシステムにおいては、ある1クライアントに集中して問い合わせが発生して負荷がそのクライアントに集中してしまうという問題が発生する。本実施の形態は、固定のサーバとなる装置を用いず、1つのクライアントに負荷が集中することなく、差分検索方式によるデータベースの検索、データベースの更新が可能な技術を提供することを目的とする。一の実施の形態によれば、サーバを用いなくとも使用可能なデータベースシステムのためのクライアントが提案される。このクライアントは、記憶手段と、最新保証通知手段と、最新保証切れ通知手段と、最新保証情報管理手段と、差分通知要求手段と、差分通知手段と、判定手段とを有する。記憶手段は、自己が最新のデータベースの内容を保有しているか否かを示す情報である更新権と、差分検索又はデータベースの同期の相手となる他のクライアントを特定する情報である問い合わせ先と、自己のデータベースの内容がデータベースシステム内で最新であるか否かを示す情報である最新保証情報を記憶する。最新保証通知手段は、前記更新権が自己が更新権を有していること示している場合、自己のデータベースと同一のバージョンであるデータベースを有する他のクライアントに、そのデータベースの内容が最新であることが保証された状態であることを通知する最新保証通知を送信する。最新保証切れ通知手段は、前記更新権の内容が自己が更新権を有していることを示す情報から自己が更新権を有していないこと示している情報に書き換えられた場合、前記最新保証通知を送信した他のクライアントに、そのデータベースの内容が最新であることが保証されない状態であること通知する最新保証切れ通知を送信する最新保証情報管理手段は、前記最新保証通知を受信した場合前記最新保証情報の内容をそのデータベースの内容が最新であることが保証された状態を示す情報に書き換え、前記最新保証切れ通知を受信した場合前記最新保証情報の内容をそのデータベースの内容が最新であることが保証されない状態であることを示す情報に書き換える。差分通知要求手段は、前記問い合わせ先に差分通知要求を送信する。差分通知手段は、自己のデータベースと当該他のクライアントのデータベースの差分を通知する差分通知を生成し、差分通知を当該他のクライアントに送信する。判定手段は、他のクライアントから差分通知要求を受信した場合、前記最新保証情報の内容がそのデータベースの内容が最新であることが保証された状態を示す情報であるときには前記差分通知手段に差分通知を当該他のクライアントに送信させ、前記最新保証情報の内容をそのデータベースの内容が最新であることが保証されない状態であることを示す情報であるときには、前記差分通知手段に前記問い合わせ先に宛てて差分通知要求を送信させる。差分検索システムまず、本実施の形態の基本となる差分検索システムについて説明する。図1は、本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図である。図1に示すように、クライアントサーバシステム100は、サーバとなる情報管理装置2と、例えばインターネット網あるいは無線通信網3でクライアント機器となる情報端末装置1とから構成されている。情報管理装置以下の説明では、サーバとも称する2は、図1に示すように、データベース24に接続されている。データベース24は、都度、更新され、現在のバージョンと変更履歴が管理されている。情報管理装置2は、専用機器である必要はない。所謂、家電機器と称される機器であってもネットワーク網に繋がり、バージョンの管理ができてサーバ機能を果たすものであればよい。さらに変更履歴は、各バージョンとそのバージョンで対象となるデータのIDとで把握されるようになっている。これらの詳細については、後述する。情報端末装置以下の説明では、クライアントとも称する1は、データベース機能を備えるものであれば、携帯電話や携帯プレーヤが好適である。所謂、ウルトラモバイルPCと称されるものである。図1に示すように、各情報端末装置1も、それぞれデータベース14に接続されているが、データベース14は、情報管理装置2のデータベース24と同期したときのバージョンとなっている。図2は、本発明の実施形態に係るクライアントサーバシステム100の機能ブロック図である。情報管理装置2は、接続部21とデータベース24を備え、情報端末装置1の要求を受け、結果を送信する。接続部21は、インターネット網を介して、情報端末装置1と通信をする。情報端末装置1は、ユーザインターフェース10と接続部11及びデータベース14を備える。ユーザインターフェース10は、ユーザの要求を受け、結果を表示するものである。接続部11は、インターネット網を介して、情報管理装置2と通信をする。さらに、情報管理装置2は、命令制御部22とSQL実行部23を有している。命令制御部22は、情報端末装置1の要求に応じて、SQL実行部23や接続部21に命令を出し、結果をユーザインターフェース10に表示する。命令としては、接続受付、差分通知、SQL受付、結果送信、同期送信、接続停止がある。SQL実行部23は、データベース24に対する命令であるSQL文を用いて、命令制御部22からの要求にしたがってデータベース24への操作や定義づけを行うものである。データベース24は、情報端末装置1から操作によって追加変更削除されたデータ241と変更履歴243とバージョン242を保有する。さらに、情報端末装置1は、命令制御部12とSQL実行部13を有している。命令制御部12は、ユーザインターフェース10の要求に応じて、SQL実行部13や接続部11に命令を出し、結果をユーザインターフェース10に表示する。命令としては、接続開始、差分除去、差分検索、結果取得、同期受信、接続終了がある。詳細は後述する。SQL実行部13は、データベース14に対する命令であるSQL文を用いて、命令制御部12からの要求にしたがってデータベース14への操作を行うものである。データベース14は、情報管理装置2と同期して取得したデータ141とバージョン142を保有する。本実施形態で使用する用語は、特にことわりのない場合、以下の意味で理解する。同期とは、サーバとクライアント機器との間で、データベース内のデータを共有している状態、若しくは共有化するための処理を意味する。差分把握とは、クライアントとサーバのデータの差分を互いのバージョンから把握し、検索処理において重複したデータを検索しないようにすることである。差分検索とは、差分データ、すなわち同期がとれていないデータに対する検索をいい、サーバが実行するものである。因みに、差分があるかどうか検索するわけではない。変更履歴とは、データベース内のデータについて変更履歴で変更した差分を管理する。変更履歴は、バージョンとデータIDの組を持っている。バージョンとは、サーバ側で一意に発行する数字で、データベース内のデータについて変更が行われたらバージョンが1つあがる。本実施形態においてバージョンは、差分把握及び差分検索を簡単にするための仕組みである。以下、いくつかの実施形態に分けて説明する。第1の実施形態図3は、第1の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図である。クライアント機器である情報端末装置1はサーバである情報管理装置2において、データベースの更新が行われると、現在のバージョンに対して1つインクリメントバージョンを1するとされる。更新の内容は変更履歴として管理される。変更履歴は、バージョンと対象となるデータのIDから成り立っている。更新に併せて、差分把握可能範囲が設定される。この差分把握可能範囲は、言わば、差分検索が可能な範囲を意味する。極端に古いバージョンのデータベースしか保持していないクライアント機器をケアする場合に対応するためのものである。クライアント機器が自ら保有しているデータベースに対して検索を行う際に、既にサーバ側ではデータベースが更新された結果、削除あるいは変更済みのデータが未だ存在している可能性がある。これら削除あるいは変更済みのデータに対して検索を行うことは全く無意味である。そこで、クライアント機器が自ら保有しているデータベースに対して検索を行う前に、クライアント機器において、該当データの無効化処理を行う。無効化処理は、サーバで差分把握を行い、クライアント機器はサーバから該当するデータIDを受け取って無効化処理をする。差分検索では、情報管理装置と情報端末装置間で、それぞれのデータベースのデータに差分が存在するか否か問い合わせを行う。情報管理装置は変更履歴から差分データについて検索して、情報端末装置に検索結果を送信する。図4は、上記のように構成された検索システムにおけるユーザである情報端末装置の情報管理装置に対する要求処理の流れを示すフローチャートである。まず、情報管理装置は情報端末装置からの接続処理を行うステップS41。情報管理装置は、処理がまだあるか否かを判断するステップS42。処理がなければ、情報端末装置との接続を解除する切断処理を実行するステップS46。処理があればYESならば、更新処理か否かを判断するステップS43。YESならば、更新処理を実行するステップS44。NOであれば、検索処理を実行するステップS45。更新処理あるいは検索処理の実行後は、ステップS42に戻る。図5は、情報管理装置のユーザである情報端末装置の更新要求処理の流れを示すフローチャートである。情報管理装置は情報端末装置からデータの更新要求を受付、更新処理を実行するステップS51。更新に伴い、情報管理装置は変更履歴を更新するステップS52。データの更新要求に対する結果が返却されステップS53、更新完了が情報管理装置から情報端末装置に返される。図6は、データベースの構造。次いで、情報管理装置のバージョン:Vsを取得するステップS1702。次いで、両者のバージョンを比較するステップS1703。Vc=Vsであれば、Vsと結果:R=変更データ無しを情報端末装置に通知するステップS1705。Vc=Vsでなければ、変更履歴から差分把握可能範囲:Vaを取得するステップS1704。次いで、Va>Vcかどうかを判断するステップS1706。Va>Vcであれば、結果:R=差分検索不可を情報端末装置に通知するステップS1711。Va>Vcでなければ、データベースから変更履歴を使い、差分IDsを作成するステップS1707。次いで、変更が削除のみかどうかを判断するステップS1708。変更が削除のみでなければ、Vsと差分ID:IDsを情報端末装置に通知するステップS1709。変更が削除のみであれば、結果:R=差分削除のみVsと差分ID:IDsを情報端末装置に通知するステップS1710。図18は、情報端末装置側における差分除去処理の流れを示すフローチャートである。まず、情報管理装置の差分IDの結果:Rを取得するステップS1801。次いで、R=差分削除のみかどうかを判断するステップS1802。R=差分削除のみであれば、差分IDsを取得するステップS1803。続いて、IDsに対応するデータをデータベースから削除するステップS1804。続いて、サーバフラグ=OFFと設定するステップS1805。このサーバフラグは、サーバに検索要求をする必要があるか否かを示すもので、サーバに検索要求をする場合、ONとなる。続いて、Vc=VsとするステップS1806。そして、差分把握完了フラグ=ONとするステップS1807。一方、R=差分削除のみでない場合には、まず、R=差分検索不可かどうかを判断するステップS1808。R=差分検索不可でなければ、続いて、R=変更データ無しかどうかを判断するステップS1809。R=変更データ無しでなければ、差分IDsを取得するステップS1810。続いて、IDsに対応するデータをデータベースから削除するステップS1811。続いて、サーバフラグ=ONと設定ステップS1812した後、ステップS1807に移る。一方、R=差分検索不可の場合には、サーバフラグ=ONと設定ステップS1813。続いて、Vc=0と設定ステップS1814した後、ステップS1807に移る。また、R=変更データ無しの場合には、サーバフラグ=OFFと設定するステップS1815。続いて、Vc=Vsと設定ステップS1816した後、ステップS1807に移る。図19は、情報端末装置側における差分検索処理の流れを示すフローチャートである。まず、差分把握完了フラグ=ONかどうか判断するステップS1901。差分把握完了フラグ=ONでなければ、接続処理情報管理装置にVcを渡すを行うステップS1902。続いて、差分IDの送受信を行いステップS1903、差分IDの除去を実行するステップS1904。一方、差分把握完了フラグ=ONであれば、Vc≠0かどうか判断するステップS1905。Vc≠0であれば、情報端末装置のデータベースから検索を実行するステップS1906。次いで、サーバフラグ=ONかどうか判断するステップS1907。一方、Vc≠0でなければ、直ちにステップS1907のサーバフラグ=ONかどうかの判断に移る。サーバフラグ=ONであれば、情報管理装置から検索を行うステップS1908。そして、検索結果を表示するステップS1909。図20は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でVcとVsを用いてSQL文を作成しステップS2001、SQL文を情報管理装置側へ送信するステップS2002。情報管理装置側では、SQL文を受信するステップS2003と、変更履歴を用いて差分データから検索を実行するステップS2004。情報管理装置は、検索結果を送信しステップS2005、情報端末装置は検索結果を取得するステップS2006。図21は、上記したステップS2004の変更履歴を用いた差分データからの検索処理を説明する図である。情報管理装置は、SELECTWHERE2<VerANDVer≦4とのSQL文を受信するとステップS2101、SELECT文を実行するステップS2102。図21に示す例では、変更履歴から、バージョン3ではnode2に変更を加え、バージョン4ではnode4に変更が加えられている。よって、情報管理装置が実行すべき差分検索は、node2、node4のみを検索対象とすることがわかる。したが、検索に要する時間も極めて短時間である。このように、本実施形態によれば、差分処理なので検索対象が少なくて済み、差分検索結果のデータサイズは差分データサイズよりもはるかに小さいのでサーバの処理量が著しく減少させることができ、多くのクライアント機器をケアすることができる。さらに、バージョン管理により、効率よく最新データの把握ができる。クライアント側では検索のためのこと前処理として無効化処理するので、効率的な検索が可能となる。また、サーバの処理量が少ないので、高性能でない機器でもデータベースサーバとして使用することができるので、低廉な検索システムを構築することができる。第2の実施形態図22は、第2の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図である。第2の実施形態では、言わば、変更履歴を管理するために必要となるメモリの削減をその狙いとするものである。そのため、1変更履歴欄がいっぱいであれば、古いものを削除する、2変更履歴欄に同じデータIDが存在していたら、最新のものにまとめる、3変更履歴で把握できる範囲外のバージョンならば、あえて差分検索しない等を骨子としている。図23は、変更発生時の変更履歴欄の更新処理であって、削除のみの変更の場合の流れを示すフローチャートである。まず、変更したノード=node4が変更履歴欄に追加されているステップS2301。次いで、変更内容が削除以外にないかどうか判定するステップS2302。YESであれば、DELETEONLYフラグをONにするステップS2303。ここでは、node4を削除するのみの変更が、バージョン3として、行われ、DELETEONLYフラグをONにしている。次いで、バージョンを1しているステップS2304。図24は、変更発生時の変更履歴欄の更新処理であって、データを節約する場合の流れを示すフローチャートである。まず、変更したノード=node4が変更履歴欄に追加されているステップS2401。次いで、変更履歴に同じデータIDが存在するかどうか判定するステップS2402。YESであれば、変更履歴の古いものを削除するステップS2403。ここでは、node4を対象とする変更が過去においてバージョン2でなされているので、バージョン2の履歴を削除し、node4を対象とする変更履歴をバージョン4のものにまとめている。次いで、バージョンを1しているステップS2404。図25は、変更発生時の変更履歴欄の更新処理であって、古い差分情報は削除する場合の流れを示すフローチャートである。まず、変更したノード=node4が変更履歴欄に追加されているステップS2501。次いで、変更履歴がいっぱいかどうか判定するステップS2502。YESであれば、古い差分情報を削除するステップS2503。ここでは、node12を対象とするバージョン1の変更履歴を消すことになる。バージョン1の変更履歴が消されると、変更履歴の最も古いバージョン:Voを差分把握可能範囲:Vaに代入するステップS2504。ここでは、最も古いバージョンが2となり、差分把握可能範囲もバージョン2となっている。次いで、バージョンを1しているステップS2505。図26は、ユーザから更新要求を受けつけた後の変更履歴処理全体の流れを示すフローチャートである。まず、更新要求の受付後、更新処理を実行するステップS2601。次いで、変更したノードを変更履歴に追加するステップS2602。次いで、サーバのバージョンを1し、Vs=Vs1と設定するステップS2603。続いて、変更内容は削除以外にないかを判断するステップS2604。削除のみならば、DELETEONLYフラグをONにするステップS2605。フラグ設定後、変更履歴に同じIDがあるかを判断するステップS2606。変更内容が削除以外にもある場合もステップS2606に移る。変更履歴に同じIDがあれば、変更履歴の古いものを削除するステップS2607。削除後、変更履歴がいっぱいかどうかを判断するステップS2608。変更履歴に同じIDがない場合もステップS2608に移る。変更履歴がいっぱいであれば、古い差分情報を削除しステップS2609、変更履歴の最も古いバージョンを差分可能範囲に代入するステップS2610。次いで、変更履歴を上位概念でまとめステップS2611、結果を返却するステップS2612。変更履歴がいっぱいでない場合には、ステップS2611以降に移る。第2の実施形態によれば、第1の実施形態での効果に加えて、変更履歴の管理をより効率的に行うことができる。第3の実施形態図27は、第3の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図である。第3の実施形態では、バージョンアップに伴う処理をより効率的に行うことに狙いがある。そのため、変更履歴の管理をより上位の概念で行う、例えば、図6のTable単位あるいはPage単位でまとめるものである。図28は、変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。まず、変更したノード=node4が変更履歴欄に追加されているステップS2801。次いで、同じPageに所属するものが一定値以上かどうか判定するステップS2802。一定値以上であれば、同じPageのIDを削除しステップS2803、PageIDを追加するステップS2804。ここでは、node12とnode13を対象とする変更履歴が、PageAを変更対象とするバージョン4として上位概念化している。次いで、バージョンを1しているステップS2805。図29は、変更履歴の上位概念によるまとめ処理の流れを示すフローチャートである。まず、同じページのIDをカウントするステップS2901。Pageでまとめられるかどうかを判断するステップS2902。Pageでまとめられる場合には、同じページのIDを変更履歴から削除するステップS2903。次いで、同じテーブルのIDをカウントするステップS2904。Pageでまとめられない場合には、直ちにステップS2904に移る。次いで、Tableでまとめられるかどうかを判断するステップS2905。Tableでまとめられる場合には、同じテーブルのIDを変更履歴から削除しステップS2906、上位概念でのまとめを終了する。Tableでまとめられない場合にも、上位概念でのまとめを終了する。なお、情報端末装置におけるバージョンアップを簡単にするための工夫として、差分把握に関してデータIDを受け取って、DELETEONLYのフラグをチェックし、フラグがたっているならば、差分データを受け取ったのと同じなのでバージョンアップし、あるいは、差分データを受け取ったら、反映し、バージョンアップするようにすることもできる。第3の実施形態によれば、バージョンアップに伴う処理をより効率的に行うことができる。第4の実施形態図30は、第4の実施形態に係る検索システムを説明する図である。第4の実施形態では、情報管理装置での検索結果の通信量のさらに低減を図るもので、差分検索に関して、検索結果と差分データから同期判断し、同期した方がよいと判断した場合には、同期データを送信し、係る同期判断は段階的に行ってもよい、等を骨子としている。ここでは、図30に示すように、差分データDsと、差分検索結果Rsのデータサイズを比較する。図31は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でVcとVsを用いてSQL文を作成しステップS3101、SQL文を情報管理装置側へ送信するステップS3102。情報管理装置側では、SQL文を受信するステップS3103と、変更履歴を用いて差分データから検索を実行するステップS3104。次いで、差分データサイズ:Sdを取得するステップS3105。続いて、検索結果データサイズ:Srを取得するステップS3106。そして、差分データサイズ:Sdと積分の差分検索データサイズ:ΣSrについて、Sd>ΣSrかどうかを判断するステップS3106。情報管理装置は、Sd>ΣSrでなければ、検索結果の代わりに差分データを送信しステップS3108、Sd>ΣSrであれば検索結果を送信するステップS3109。情報端末装置はデータを取得しステップS3110、データが差分データかどうかを判断するステップS3111。差分データであれば、差分データをデータベースにアップデートするステップS3112。Vc=VsとしステップS3113、サーバフラグ=OFFと設定するステップS3114。繰り返しの検索によって、検索結果データが差分データよりも大きくなってしまう可能性がある。そのような場合には、積算の差分検索結果データサイズ≦差分データサイズとなり、積算の差分検索結果データサイズを送信した方が結果的にデータ量は少ないので、検索結果を送信した方が得である。一方、積算の差分検索結果データサイズ>差分データサイズならば、差分データを送り、以降の通信量は無しとすることにより、本実施形態によれば、繰り返しによる通信量を低減することができる。なお、上述では、積算の検索結果データと差分データの大小関係による判定について説明したが、これに限られない。例えば、差分データの80で比較する、あるいは検索要求を予測するようにしてもよい。第5の実施形態第5の実施形態では、情報管理装置での検索結果の通信量のさらに低減を図るものである。図32は、第5の実施形態に係る検索システムを説明する図である。ここでは、図32に示すように、バージョンごとのデータで、差分データDsと、差分検索結果Rsのトータルサイズを比較する。図33は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でVcとVsを用いてSQL文を作成しステップS3301、SQL文を情報管理装置側へ送信するステップS3302。情報管理装置側では、SQL文を受信するステップS3303と、N=N1とカウントアップステップS3304した後、変更履歴を用いて差分データから検索を実行し、データを作成するステップS3305。情報管理装置は、情報端末装置に送信データ:Sの送信を行うステップS3306。情報端末装置はデータを取得しステップS3307、データに差分データがあるかどうかを判断するステップS3308。差分データがあれば、差分データをデータベースにアップデートするステップS3309。Vc=Vdと設定しステップS3310、Vc=Vsかどうかを判断するステップS3311。Vc=Vsであれば、サーバフラグ=OFFとするステップS3312。一方、データに差分データがない場合には、ステップS3312に移る。Vc=Vsでない場合には終了する。次に、検索結果と同期データの比較による送信データの決定について説明する。図34は、送信データの決定処理の流れを示すフローチャートである。まず、i=Vc1とするステップS3401。次いで、Vs=iかどうかを判断するステップS3402。Vs=iでなければ、i=i1としステップS3403、バージョンiの差分データ量:Ddとしたとき、Sd=SdDdとするステップS3404。次いで、iの差分データが検索にヒットしたかどうかを判断するステップS3405。ヒットした場合には、iの差分検索結果データ量:Rdを求めたステップS3406後、積算検索結果データ量Srに足し上げ、Sr=SrRdとするステップS3407。続いて、Sd>Srかどうかを判断するステップS3408。ステップS3405において、iの差分データが検索にヒットしなければ、ステップS3408に移る。Sd>Srでなければ、どのバージョンまで差分を送るか確保し、Vd=iとするステップS3409。その後、ステップS3402に戻る。Sd>Srであれば、直ちに、ステップS3402に戻る。一方、Vs=iであれば、Vdまでのバージョンの差分データを送信データ:SにコピーするステップS3410。続いて、Vd以降の検索結果を送信データ:Sに追記コピーするステップS3411。第5の実施形態によれば、部分的なバージョンアップをするので、差分検索処理量が減り、差分データ量を減少させることができる。また、以降の通信量も減少させることができる。上述では、差分データと差分検索結果のトータルサイズの大小関係による判定について説明したが、これに限られない。例えば、差分データの80で比較する、あるいは検索要求を予測するようにしてもよい。本差分検索システムのデータ更新次に、上記の差分検索を行うことが可能な差分検索システムでのデータ更新方法について説明する。対サーバ間でのネットワーク環境が弱い状況下では、クライアントは、サーバに更新したデータの一部、例えばデータIDのみ送信し、更新したデータ全体の送信は行わずにおき、後刻そのクライアントが対サーバ間でのネットワーク環境が強い状況下にきたときに、サーバのデータベースと、クライアントのデータベース間の完全同期を行うよう更新したデータの送受信を実行する。図35Aは、ネットワーク環境が弱い状況下でのサーバ、クライアントBを示し、図35Bは、ネットワーク環境が強い状況下でのサーバ、クライアントBを示している。ネットワーク環境が弱い状況下は、例えば移動体通信網のみ利用可能な通信環境であって、通信はできるがネットワーク環境が強い場合に比して通信速度が低速な環境である。一方、ネットワーク環境が強い状況下は、例えば第1の通信環境下に比して通信速度が高速な通信環境であって、例えば有線LANトランスファージェットによるネットワーク利用可能時である。なお、ネットワーク環境が弱い状況下であるか、ネットワーク環境が強い状況下にあるかは、どのような手段によってクライアントが判断するようにしてもよく、例えば通信状況、有線接続であるか否か、GPSによる位置情報、ユーザの手動による切り替え操作によりどちらのネットワーク環境下にあるかを判断するようにしてもよい。図35Aの状態で、クライアントにユーザが新たなデータを追加入力し、クライアントのデータベースが更新されたものとする。このときクライアントは更新したデータの一部例えば、更新したデータのデータIDのみをサーバに送信する。この弱いネットワーク環境下では送信可能な通信量が少なく、コストも係るためである。このとき、サーバはクライアントBによって更新されたことを記憶しておく。後刻、図35Bのように、クライアントがサーバと強いネットワーク環境下になったとき、サーバとクライアントは互いのデータベースの記憶内容を同期させる。強いネットワーク環境下では送信可能な通信量も十分であり、通信コストも低いためである。図36は、図35に示したクライアントBがサーバに更新通知を行った後、別のクライアントであるクライアントAがサーバに検索要求を行ったときの動作を示す。まず、クライアントAは、サーバにある内容の検索要求を行う。サーバは自己のデータベースについて依頼された検索を実行するとともに、先に更新通知をしてきたクライアントBに、クライアントBが記憶している更新分のデータについて検索するよう差分検索要求を行う。クライアントBはその差分検索要求に応じて、自己のデータベースを検索し、検索結果をサーバに戻す。サーバはクライアントBからの検索結果と自己のデータベースの検索結果を合わせて、クライアントAに検索結果を返す。これで、同期前であってもシステム内の検索が完了できる。クライアント同士が通信可能である環境であれば、図36の例のようにサーバを介すことなく、クライアントとサーバのデータベース同期実行前であっても、システム内の検索を行うことが可能である。図37Aは、クライアント同士が通信可能である場合の同期実行前検索時のシステムの動作例を示す。まず、クライアントAは、ある内容の検索要求をサーバに行うのとき、サーバだけでは差分検索できない。よって、このサーバだけでは差分検索できない確率のとき、更新者に問い合わせをする方法を採る。更新したデータをサーバに反映するためのデータ量をDとし、ある期間での検索発生回数をn、差分検索のためのデータ量をR、更新者への問い合わせをした差分検索量を2Rとすると、更新データを送付した場合の送信データ量はDnRであり、更新データを送付しない場合の送信データ量は、nRp2R1-pで表すことができる。前回と同様、更新データは同期のためのデータであり、更新データを送付しない場合の送信データ量≦更新データを送付した場合の送信データ量が成立するとき、本実施の形態の方式は効率的となる。よってが成立するとき、本実施の形態による方式は効率的で得あると判定できる。また、上記式はと変形できる。一般に更新データは、差分検索結果データに比べ数倍大きい。この式により、検索要求頻度と更新頻度がデータ量の比より小さければ、効率できであるといるこの判定式を使った予測によってデータを送信すべきかどうか決定できる。とりわけ最初の判断と、検索要求が多く来たときに利用可能である。更新時にDが決まり、Rとpとnが履歴から予測できれば更新時に上記式に基づいて効果的かどうかが判定できる。効果がないと判定された場合には、更新データをサーバに反映させるよう送信すればよい。また、更新データに対して検索回数が増えるとnが増加する。Dは更新時に決まっており、Rとpが予測から求められ、増加したnによって上記式の不等号が成り立たなくなったら、更新データをサーバに反映するようにすればよい。上記判定の具体例を挙げる。24時間中、1時間だけ更新が反映されない状況が生ずるとする。例えば、通勤移動時間が朝と夜で1時間係るとする。この場合稼働率pは上記稼働率の計算式よりp=23/231=0.958さらに、更新データ量Dは、差分検索のためのデータ量Rの10倍D=10Rとすると、前記不等式を変形してn≦D/R×1-p=10/0.04=250となり、結局250回/日の検索要求が一定間隔できても、結果効果的であることがわかる。本システムの基本的な動作以下、本システムの基本的な動作例について説明する。図40は、本システムの基本的な動作の概要を示した図である。この例では、サーバと、データ更新を行うクライアント以下、区別のため更新要求クライアントと呼ぶと、検索を行うクライアント以下、区別のため検索要求クライアントと呼ぶとでシステムが構成されているものとする。更新要求クライアントより詳しくは命令制御部12、以下同じは最初にデータ更新要求を行ったときにはネットワーク環境が弱い環境下に存在しているが、その後移動してネットワーク環境が強い環境下に存在するようになるものとする。ここでは、以下の順にそれぞれの処理が行われる1更新要求クライアントによる遠距離更新時のユーザ更新要求2サーバによる遠距離更新時のユーザ更新要求受付3検索要求クライアントによる検索実行4サーバによるユーザ参照要求受付5サーバによる差分検索要求、更新要求クライアントによる差分検索応答6更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付以下、上記手順の具体的内容について述べる。1更新要求クライアントによる遠距離更新時のユーザ更新要求図41は、上記1更新要求クライアントによる遠距離更新時のユーザ更新要求の処理例を示したフローチャートである。以下このフローチャートを参照しながら更新要求クライアントによる遠距離更新時のユーザ更新要求を説明する。サーバのデータベース更新を行う必要が生ずると、まず、更新要求クライアントは更新を行うために送信しなければならない送信データ量Dの算出を行うS4101。次に、更新要求クライアントは、検索発生回数n、差分検索のためのデータ量R、稼働率pを取得するS4102。検索発生回数n、差分検索のためのデータ量R、稼働率pし、当該データについては更新したユーザである更新要求クライアントに問い合わせるように設定に差分検索を要求し、返される差分検索結果を取得するS4402。次にサーバは、サーバ自身のデータベースを参照し、更新済みのデータを検索するS4403。さらにサーバは検索結果を出力する。差分検索の結果をクライアントから取得している場合には、自己のデータベースの検索結果と差分検索の結果を結合して検索結果として出力するS4404。最後に、サーバは検索頻度nの値を1だけ増加させ、新しい検索頻度nとして記憶するS4405。実績値n,R,pを最新の状態に保っておくためである。以上で、ユーザ参照要求受付処理が終了する。5サーバによる差分検索要求、更新要求クライアントによる差分検索応答検索要求クライアントから検索要求を受け付けたサーバは、更新クライアントに対して差分検索要求を出し、この差分検索要求を受け付けた更新要求クライアントは差分検索応答を行う。図46は、上記5サーバによる差分検索要求、更新要求クライアントによる差分検索応答の処理例を示したフローチャートである。以下このフローチャートを参照しながらサーバによる差分検索要求、更新要求クライアントによる差分検索応答の内容を説明する。まず、サーバ側で行われる差分検索要求について先に説明する。検索要求クライアントから検索要求を受け付けたサーバはまず、他のクライアント先の問い合わせリストにより決定するに対して差分検索要求を送信するS4601。その後、差分検索要求を受け付けたクライアントと判定した場合S4610、No、S4609で得られた差分検索結果をサーバに返すS4612。さらに更新要求クライアントは送ったデータ量Riを保持する。後に、今まで送った更新データのデータ量の合計値を算出し、S4610の判定を行うためである。これで更新要求クライアントによる差分検索応答は終了する。6更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付弱いネットワーク環境下にあった更新要求クライアントが強いネットワーク環境下に入った場合、更新要求クライアントによる更新要求並びにサーバによるユーザ更新要求受付が行われる。図47は、上記更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付処理例を示したフローチャートである。以下このフローチャートを参照しながら更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付を説明する。更新要求クライアントはまず、更新通知のみの更新データをサーバに送信するS4701。次に、更新要求クライアントはサーバから実績値p,n,Rを取得するS4702。その後、更新クライアントは自己のデータベースとサーバのデータベースとの完全同期を実行するS4703。この完全同期の内容については後述する。完全同期終了後、更新要求クライアントは更新要求を終了する。次に、サーバの更新要求受付について説明する。更新要求クライアントから送信された更新データを受信したサーバは、更新データを自己のデータベースに反映させるS4704。次に、サーバは前回の完全同期時刻と、更新通知日時と、現在時刻から稼働率pを算出するS4705。サーバは、差分検索のために送られたデータ量の合計Rsumを差分検索の実行回数nRで割って、平均データ量Rを算出するS4706。次に、サーバは更新された実績値n,R,pを更新要求クライアントに送信するS4707。その後、サーバは更新要求クライアントとの間でデータベース内容の完全同期を実行するS4708。この完全同期の内容については後述する。完全同期終了後、サーバは更新要求受付を終了する。最後に、更新要求クライアント及びサーバ間での完全同期処理について説明する。完全同期処理を開始した更新要求クライアントはまず、自分のデータベースのVersionをサーバに通知するS4709。サーバは更新要求クライアントからデータベースのVersionを得るS4710と、更新要求クライアントに渡すべき差分となるデータを生成するS4711。次にサーバは、差分となるデータを更新要求クライアントに送信するS4712。更新要求クライアントはサーバから差分となるデータを受信するS4713。更新クライアントは受信した差分となるデータを自己のデータベースに更新させるS4714。これで、更新クライアント及びサーバ間のデータベース完全同期が完了する。本実施の形態の効果的な状況本実施の形態は、下記のような状況下でとりわけ有効である。1.サーバ、クライアント間が近距離では安価で高速な通信ができ、遠距離では高価で低速でも通信が可能であること。このような環境下で、本実施の形態は、近距離では同期による更新をし、遠距離では本提案を実施する。2.一定間隔で、データベースがリフレッシュできること充電のついでに完全同期できるなど、そのような完全同期がある期間内には行われる環境であること。3.クライアント側で入力されるような、更新データが大量であるが、検索対象になりにくい環境下であること。同期するまで、当面、検索されないようなものほど本実施の形態は効果がある。上記において近距離とは例えば、通信のコストが小さい環境を意味し、遠距離とは例えば、通信のコストが大きい環境を意味する。ここでいうコストとは、通信に伴う料金課金額や、通信速度、レイテンシィ、電力消費量などを一つ乃至は複数考慮して決定する定量的なものを意味する。本差分検索システムのデータ更新のまとめ本実施の形態によれば、以下のメリットを享受できる。1.データを更新する際、悪い通信環境での通信量を減らすことができるため、ネットワーク管理者から見てネットワークトラフィックが減り、ユーザから見た場合に通信費用が減る。2.サーバの負担を減らすことも可能となる。なお、本差分検索システムのデータ更新は、第1の実施から第5の実施の更新時に適用でき、また第6の実施にも適用できる。第6の実施の形態次に、本実施の形態に係る第6の実施の形態について述べる。第6の実施の形態は、基本的に前述の第1の実施の形態から第5の実施の形態と同様の構成及び動作をするデータベースシステムであるが、本実施の形態は、サーバを使用することなく、クライアント間で差分検索を行い、及び/又は、クライアント間でデータベースを最新の状態に更新できるデータベースシステムである点で異なっている。第6の実施の形態の構成例第6の実施の形態は、第1から第5の実施の形態における情報管理装置以下の説明では、サーバとも称するに相当する装置を有する構成としても成立するが、サーバを設けない構成としても本実施の形態は成立する。以下の説明ではサーバを設けない場合の構成として、本実施の形態の説明を行う。[用語]本実施の形態の説明で使用する用語は、特にことわりのない場合、以下の意味を有する。同期とは、マスタークライアントとノードクライアントとの間で、データベース内のデータを共有している状態、若しくは共有化するための処理を意味する。差分把握とは、ノードクライアントとマスタークライアントのデータの差分を互いのバージョンから把握し、検索処理において重複したデータを検索しないようにすることである。差分検索とは、差分データ、すなわち同期がとれていないデータに対する検索をいい、マスタークライアントが実行するものである。因みに、差分があるかどうか検索するわけではない。変更履歴とは、データベース内のデータについて変更履歴で変更した差分を管理する。変更履歴は、バージョンとデータIDの組を持っている。バージョンとは、本データベースシステム内でマスタークライアントが一意に発行する数字で、データベース内のデータについて変更が行われたらバージョンが1つあがる。本実施形態においてバージョンは、差分把握及び差分検索を簡単にするための仕組みである。図48に、第6の実施の形態のシステム構成例を示したブロック図を示す。図48に図示するように、システム4800は、マスターとなる情報端末装置以下、区別のためマスタークライアントとも呼ぶ4801と、例えばインターネット網、無線通信網、無線LANなどの通信網4802でクライアント機器となる情報端末装置以下、区別のためノードクライアントとも呼ぶ4803とから構成されている。各クライアントは同一の通信網で接続されてもよいし、異なる通信網により接続されてもよい。例えば、マスタークライアント4801と全てのノードクライアント4803が無線LANに接続されていても本実施の形態は成立し、またあるクライアント同士はインターネット網で接続されており、別のクライアント同士は無線LANで接続されている状態でも本実施の形態は成立する。マスタークライアント4801は後述する責任を有するクライアントである。ノードクライアント4803は、責任を有さないクライアントである。マスタークライアント4801とノードクライアント4803とは、責任の有無について異なるだけであって、装置構成、機能は共にクライアントであって差異はない。マスタークライアント4801とノードクライアント4803を区別しない場合には、単にクライアント48014803と呼ぶこととする。責任を有するクライアント、すなわちマスタークライアント4801は、ノードクライアント4803の求めに応じて、後述するつなぎかえ指定、差分検索、データベースの同期を行うことができる唯一の装置である。なお、責任を有するか否かは、後述する更新権の有無によって識別される。責任を有するクライアントは、更新権を有するクライアントである。クライアント48014803は、通信機能を有する情報処理装置、より詳しくは演算処理装置CPU、主メモリRAM、読出し専用メモリROM、入出力装置I/O、必要な場合にはハードディスク装置等の外部記憶装置を具備している情報処理装置、あるいはそのような情報処理装置を含む装置である。クライアント48014803は、データベース機能を備えるものであれば、どのような情報処理装置であってもよく、例えば携帯電話や携帯プレーヤが好適である。所謂、ウルトラモバイルPCと称されるものでもよい。図49は、本実施形態に係るクライアント48014803の機能ブロック図である。クライアント48014803は、ユーザインターフェース4901、接続部4902、命令制御部4903、SQL実行部4904、及びデータベース4905を有している。ユーザインターフェース4901及び接続部4902は命令制御部4903に接続されている。命令制御部4903はSQL実行部4904に接続されており、SQL実行部4904はデータベース4905に接続されている。接続部4902は無線回線、あるいは有線回線を介して通信網4802に接続可能である。また、データベース4905は、データ4906、バージョン4907、変更履歴4908を記憶している。ユーザインターフェース4801は、ユーザの入力を受け付けるとともに、処理結果を表示する機能を有する。例えば、液晶ディスプレイ装置及びタッチパネルなどである。接続部4902は、通信網4802を介して他のクライアント48014803と通信する機能を有する。命令制御部4903は、ユーザや他のクライアント48014803からの要求や命令に応じて、所定の命令を実行し、必要に応じてSQL実行部4904や接続部4902に命令を出し、あるいは結果をユーザインターフェース4901に表示させる。図50は、命令制御部4903の一構成例を示す機能ブロック図である。命令制御部4903は、接続開始部5001、接続受付部5002、接続停止部5003、接続終了部5004、差分通知部5005、差分除去部5006、差分検索部5007、SQL受付部5008、結果取得部5009、結果送信部5010、ネットワーク利用判断部5011、同期送信部5012、同期受信部5013、更新権利取得部5014、更新権利破棄部5015、つなぎかえ指定部5016、つなぎかえ処理部5017、最新保証処理部5018、つなぎかえ要求部5019、最新保証通知部5020、最新保証切れ通知部5021、判定部5022という各命令処理部を有している。また、命令制御部4093は、同期内ノード5023、更新権5024、問い合わせ先5025、最新保証フラグ5026、予測データ5027を記憶しており、本実施の形態の記憶手段として機能する。以下に、上記命令処理部のそれぞれについて説明する。接続開始部5001は、あるクライアントが他のクライアントとの通信を確立させるための処理を行う。接続受付部5002は、他のクライアントからの接続要求を受けた場合、当該クライアントとの通信を確立する処理を行う。接続終了部5003は、接続開始後、必要な処理が終了したのちに他のクライアントとの通信を解除する処理を行う。接続停止部5004は、接続のために用意していたメモリや通信部などの資源を解放するために他のクライアントからの求めに応じて確立させた通信を解除する処理を行う。差分通知部5005は、ノードクライアント4803が自己のデータベースのバージョンをマスタークライアント4801に通知して、互いのバージョンからデータの差分をマスタークライアントに把握させる処理を行う。差分除去部5006は、差分データを無効化する処理を行う。差分検索部5007は、差分検索処理を実行する。SQL受付部5008は、他のクライアントからSQL文を取得し、取得したSQL文をSQL実行部4904に渡す処理を行う。結果取得部5009は、前述の結果送信により送信されたデータを取得する処理を行う。結果送信部5010は、SQL実行部4904がSQL文を実行した結果をSQL文の送信元である他のクライアント48014803に送信させる処理を行う。ネットワーク利用判断部5011は、そのクライアント48014803が使用しているネットワーク通信網4802に相当が強いネットワーク環境であるのか、弱いネットワーク環境であるのかを判定する。同期送信部5012は、他のクライアント48014803から同期を求められた場合、同期させるためのデータベースのデータを当該クライアント48014803に送信させる処理を行う。同期受信部5013は、上記同期送信に他のクライアント48014803から送信されたデータを受信し、データベース4905の内容を同期させる処理を行う。更新権利取得部5014は、責任を有するマスタークライアント4801からその責任を取得する処理を行う。具体的には、責任の有無に応じて更新権5024の書き換えを行う。更新権利破棄部5015は、自己の更新権5024を責任を有さないことを示すように書き換える。具体的には、責任の有無に応じて更新権5024の書き換えを行う。つなぎかえ指定部5016は、つなぎかえ要求を送信したクライアント4803に対して、新しい問い合わせ先となるクライアントを通知する処理を行う。つなぎかえ指定5016は、本実施の形態のつなぎかえ指定手段に相当する。つなぎかえ処理部5017は、つなぎかえ指定を受信したノードクライアント4803が、問い合わせ先5025を更新する処理を行う。つなぎかえ処理5017は、本実施の形態のつなぎかえ処理手段に相当する。つなぎかえ要求部5019は、現在責任を有しているマスタークライアント4801を通知するよう求める処理を行う。つなぎかえ要求部5019は、本実施の形態のつなぎかえ要求手段に相当する。判定部5022は、予測データ5027に基づいて、つなぎかえ要求の要否の判定を行う。次に、命令制御部4903が有する各データについて説明する。同期内ノード5023は、データベース4905の同期を行っている他のクライアント48014803のリストである。更新権5024は、そのクライアント48014803が責任、すなわち更新権利があるかどうかを示す情報である、例えば、更新権の内容が1なら自分が責任を有するマスタークライアント4801であることを示し、0であれば自分は責任を有さないノードクライアント4083であることを示す。更新権5024を所有するクライアントは、その時点でデータベース4905の内容が最新の内容であるクライアントであり、同時に複数は存在しえない。但し、責任、すなわち更新権は、データベースが更新されるごとに、クライアント間で移転していく。問い合わせ先5025は、自分よりも新しいバージョンのクライアント48014803をひとつ覚えておくためのノードの連結情報である。但し、問い合わせ先であるクライアントがその時点でまだ責任を有しているかどうかはわからない。予測データ5027は、つなぎかえを行うか否かを判断するための予測値実績値である。予測データには、ノード全体数、自分に属している子のノード数、更新確率検索確率などが含まれる。予測データ5027については、クライアント48014803は同期時に互いに情報交換することができるので、同期している他のノードの情報を使うことが可能である。図49に戻り、クライアントの構成例の説明を続ける。SQL実行部4904は、データベース4905に対する命令であるSQL文を用いて、命令制御部4903からの要求にしたがってデータベース4905への操作や定義づけを行う機能を有する。データベース24は、追加変更削除されたデータ4906と変更履歴4908とバージョン4907を記憶する。データ4906は、データベースを構成する個々のデータ要素の集合である。バージョン4907は、データ4906に対応する現在のバージョンを表す情報である。変更履歴4908は、データベース4905内のデータ4906について、変更した差分を管理するための情報である。図51は、変更履歴4908の記憶内容の例を示すブロック図である。変更履歴は、差分把握可能範囲5101と、バージョン5102とデータID5103とを含む。差分把握可能範囲5101は、極端に古いバージョンのデータベースしか保持していないクライアント機器をケアする場合に対応するための情報であって、差分検索が可能な範囲を示す情報である。バージョン5102とデータID5103とは組になっており、データID5103は対応するバージョンにおいて追加変更削除されたデータ要素を特定する識別情報である。本実施の形態の動作例について次に、本実施の形態に係るデータベースシステム4800の動作例を説明する。責任の移転:2クライアント間の場合本実施の形態では、サーバを使用することなく、クライアント間で検索を行い、及びデータベースを最新の状態に更新できることを特徴の一つとしている。このための仕組みとして、本実施の形態では最新データを所持するクライアントが責任を有する。責任の有無は前述の更新権5024の内容によって識別される。前述の通り、責任を有するクライアントはマスタークライアント4801となり、そうでないクライアントはノードクライアント4803となるが、責任が移動することによって、マスタークライアント4801はノードクライアント4803となり、一方ノードクライアント4803がマスタークライアント4801になる。図52に、1つのマスタークライアントと、1つのノードクライアントの間での責任の移転の例を示す。あるクライアントAこの時点ではノードクライアントが自己のデータベースを最新の状態にするべく、データベースの更新処理を行おうとする場合、その時点で責任を有するマスタークライアントBに対して更新要求を送信するS5201。更新要求を受信したマスタークライアントBはノードクライアントBにデータベースの更新をさせるとともに、更新要求の送信元であるノードクライアントAに責任を渡す。データベースの内容を最新の内容に更新し、新たに責任を保有したノードクライアントAは、以後マスタークライアントAとして振る舞うことになり、責任を保有しなくなったマスタークライアントBは以後ノードクライアントBとして振る舞うことになる。すなわち、以後、ノードクライアントBは、責任を受け取ったマスタークライアントAに問い合わせを行う。なお、責任の受け渡しに相当するデータ処理方法については後述する。責任の移転:3クライアントの場合次に、3つのクライアントが関与する場合の責任の移転について説明する。図53は、あるデータaについての責任が移転する例を示す。図53に示した例では、3つのクライアントは相互に通信可能な状態にあるものとする。クライアントAはデータaについて責任を有している。残りの2つのクライアント、クライアントB、クライアントCは共にデータaについてデータベース記憶内容の更新を必要としている状態にあり、クライアントB、クライアントCはデータaについてクライアントAが責任を有すると記憶している。図中の矢印は、矢印の元にあるクライアントから見た、責任を有するクライアント、すなわち問い合わせ先に記述されたクライアントを示している。ここで、クライアントBがクライアントAに対してデータaについて更新要求を行ったものとする。クライアントAはクライアントBに対して最新の内容のデータaを送信する。クライアントBの有するデータベース内容はデータaについて更新され、最新の内容となる。このときクライアントAはデータaについての責任をクライアントBに渡す。クライアントBはこの責任を取得し、データaについて自分が責任を有すると記憶する。また、クライアントAはデータaについての責任はクライアントBが有するものと記憶する。図54は図53の状態から責任が移転した後の状態を示す図である。クライアントBはこの責任を取得し、データaについて自分が責任を有すると記憶し、クライアントAは、自分は責任を破棄し、データaについての責任はクライアントBが有するものと記憶した状態を示す。クライアントCは以前と変わらず、データaについてクライアントAが責任を有すると記憶している状態が継続する。最新の検索差分把握本実施の形態は、サーバ不要で、最新の内容のデータベースの検索することができる。各クライアントは、最新のデータベースの内容を検索をするためには、責任を有するクライアントに問い合わせすることが必要である。これは、前述した実施の形態における差分検索でいう差分把握に相当する処理である。先の図54で示した例に基づいて、本実施の形態における最新の検索について説明する。クライアントCは、最新のデータであるデータaについてクライアントAが責任を有していると記憶している。クライアントBはデータaについて自分が責任を有すると記憶し、クライアントAはデータaについての責任はクライアントBが有するものと記憶している状態である。クライアントCはクライアントAがデータaについて責任を有していると記憶しているので、クライアントCはクライアントAに問い合わせを送信する。問い合わせ差分通知を受信したクライアントAはデータaについて責任を持っておらず、且つ、クライアントAはクライアントBに聞くという情報を持っているので、クライアントBにデータaについて問い合わせ差分通知を送信する。クライアントBはデータaについて責任を有しているので、自己が記憶する最新のデータaとの差分内容をクライアントCに送信する。よって、クライアントCは責任を有するクライアントとの差分を把握することができる。連鎖問い合わせ:差分検索のつなぎかえ本実施の形態では、クライアントがデータベースを検索する場合において、最新のマスタークライアント4801がどのクライアントであるかを把握することができるようになる。図54は、クライアントCは、最新のデータであるデータaについてクライアントAが責任を有していると記憶している。クライアントBはデータaについて自分が責任を有すると記憶し、クライアントAはデータaについての責任はクライアントBが有するものと記憶している状態である。ここで、クライアントCがデータaについて検索を行おうとする場合、まずデータaについて責任を有するとクライアントCが記憶しているクライアントAに問い合わせる。クライアントAはデータaについての責任はクライアントBが有するものと記憶しているので、データaについてクライアントBに問い合わせる。すなわち、それぞれのクライアントにおいて問い合わせ先となっているクライアントに対して連鎖的に問い合わせが行われる。問い合わせに対してマスタークライアント4801から応答がなされ、各クライアントは、今現在責任を有するクライアントを示す情報である問い合わせ先5025を更新するつなぎかえと呼ぶことができる。但し、つなぎかえはつなぎかえをした方が有利な場合と判定された場合に行われ、常につなぎかえが行われるわけではない。図54の状態の後、つなぎかえが行われた状態を図55に示す。クライアントCの問い合わせ先が更新され、現在のマスタークライアントBが新たな問い合わせ先として登録される。クライアントAについて問い合わせ先の変更はない。連鎖問い合わせ:更新の際のつなぎかえ本実施の形態では、クライアントがデータベースを更新する場合において、サーバを用いることなく更新を行うことができ、更新の際には、最新のマスタークライアント4801がどのクライアントであるかを把握することができるようになる。図56は、クライアント間でのデータベース更新前のある状態を示す図である。クライアントCは、最新のデータであるデータaについてクライアントAが責任を有していると記憶している。クライアントBはデータaについて自分が責任を有すると記憶し、クライアントAはデータaについての責任はクライアントBが有するものと記憶している状態である。ここで、クライアントCがデータaについてデータベースの更新を行おうとする場合、まずデータaについて責任を有するとクライアントCが記憶しているクライアントAに問い合わせる。クライアントAはデータaについての責任はクライアントBが有するものと記憶しているので、データaについてクライアントBに問い合わせる。すなわち、問い合わせ先となっているクライアントに対して連鎖的に問い合わせが行われる。クライアントCがクライアントBよりデータを取得し、データベースの内容を最新の内容に更新すると、データaについての責任はクライアントBからクライアントCに渡され、クライアントCが新たに責任を有する状態になる。この場合、経由したクライアント問い合わせに関与したクライアントは、責任を有するクライアントの情報である問い合わせ先5025を書き換えるつなぎかえと呼ぶ。すなわち、クライアントA、クライアントBはデータaについてクライアントCが責任を有すると、記憶するように問い合わせ先5025を書き換える。但し、つなぎかえはつなぎかえをした方が有利な場合と判定された場合に行われる。図56の後につなぎかえが行われた状態を図57に示す。クライアントA,クライアントBの問い合わせ先が更新され、現在のマスタークライアントCが新たな問い合わせ先として登録される。つなぎかえの要否各クライアントは、以下の判定条件式に基づいて、つなぎかえを行うか否かを判定し、判定結果に基づいてつなぎかえ処理を実行する。判定条件式は以下の通り<同期するまでに検索する回数×問い合わせ通信の減る量上記式の投資は本実施の形態の第1の送信データ量に相当し、上記式の右辺は本実施の形態の第2の送信データ量に相当する。上記判定条件式が満たされる場合には、クライアント、より詳しくは判定部5022は、つなぎかえ処理を実行すると判定する。同期すれば、1段化にされるためである。投資は、つなぎかえを行うために必要な送信データ量であって、dと表す。同期するまでに検索する回数は予測値を用いる。予測値は予測データ5027から過去の平均値を算出することなど適宜な方法によって得る。問い合わせ通信の減る量はh1dにより算出される値である。hはそのクライアントから最新ノード実際に責任を有するクライアントまでの高さ×n××h1×d...なお、最新ノードマスタークライアントに直結している場合は、h1となり、つなぎかえの必要性は生じない、このマスタークライアント4801を問い合わせ先5025に記憶しているノードクライアント4803、ノードクライアントN1を問い合わせ先5025に記憶しているノードクライアント4803、ノードクライアントN2を直接、又は間接に問い合わせるノードクライアント4803の集団ノードクライアントN2の下位ノード集団と呼ぶがある。このとき、ノードクライアントN1の高さh=1、ノードクライアントN2の高さh=2となる。また、ノードクライアントN2の下位ノード集団に含まれるノードクライアント数C=29とする。ここで、上記条件下においてノードクライアントN2が条件判定式を用いてつなぎかえの要否を判定するとどのようになるかを述べる。ノードクライアントN2について、d≦×n××h1×dの式を考えると、C=29、n=0.4、P=0.9、h=2であるからこれらを代入してd≦×04×01××d12d...×n××h1×dの式を考えると、C=30、n=0.4、P=0.9、h=1であるからこれらを代入してd≦×04×××d0...が存在する。なお、ノードクライアントN3の子ノード集団の個数C=9であるとする。ノードクライアントN3の高さh=3である。ノードクライアントN3について、条件判定式、d≦×n××h1×dの式を考えると、C=9、n=0.4、P=0.9、h=3であるからこれらを代入してd≦×04×01××d08d...である。つなぎかえに必要な送信データ量は常にd>0であるから、上記式3の不等式は成立せず、子の条件下ではノードクライアントN3はつなぎかえを実施しないと判定することになる。但し、前述の通り、ノードクライアントN2において判定すると、式2に示した結果より、ノードクライアントN2はつなぎかえを実施する。すなわち、同じノード内でも、つなぎかえを行うクライアントと行わないノードが混在することありうる。つなぎかえの処理例次に、本実施の形態におけるつなぎかえの動作例について説明する。図60にサーバを用いることなく検索を行う場合の、本実施の形態に係るデータベースシステムの動作例をシーケンス図として示す。図60に示す例では、1つのマスタークライアント4801、及び3つのノードクライアント4803互いを区別するため、マスタークライアント4801をクライアントR、3つのノードクライアント4803をクライアントN1、クライアントN2,クライアントN3と呼ぶが存在している。クライアントN3は責任を有するのはクライアントN2であると記憶しており、クライアントN2は責任を有するのはクライアントN1であると記憶しており、クライアントN1は責任を有するのはクライアントRであると記憶しており、実際に責任を有しているのはクライアントRである。ここで、クライアントN3がデータベースの検索を行おうとしたとする。まず、検索を実行しようとするクライアントN3は、差分通知要求S6001とつなぎかえ要求S6002をクライアントN2に送信する。つなぎかえ要求には、つなぎ換えを行った方が有利となるか否かを判定してもらうために必要なデータ判定用データと呼ぶが含まれている。ここではクライアントN3の高さh、子ノード集団の個数Cがつなぎかえ要求のメッセージに付加されているとする。具体例としてはN3:h=1、C=9のような判定用データである。クライアントN3から差分通知要求とつなぎかえ要求を受信したクライアントN2は自分は責任を有していないので、責任を有すると記憶しているクライアントN1に差分通知要求を送信転送するS6003。また、クライアントN2は差分通知要求S6003とともに、クライアントN3から受信した判定用データとともに、自己分の判定用データを含めたつなぎかえ要求S6004をクライアントN1に送信する。具体的にはクライアントN3分の判定用データと、自己N2の判定用データが含まれる。その内容は以下の通りである。N3:h=2、C=9N2:h=1、C=29なお、他のクライアントから受け取った判定用データ中のhの値は1だけ増加された値に変更される。クライアントN2から差分通知要求とつなぎかえ要求を受信したクライアントN1は自分は責任を有していないので、責任を有すると記憶しているクライアントRに差分通知要求を送信転送するS6005。また、クライアントN1は、差分通知要求S6005を転送するとともに、他のクライアントから受信した判定用データ及び自己分の判定用データを含めたつなぎかえ要求S6006をクライアントRに送信する。具体的にはクライアントN3分の判定用データ、クライアントN2分の判定データと、自己N1の判定用データが含まれる。その内容は以下の通りである。N3:h=3、C=9N2:h=2、C=29N1:h=1、C=30なお、他のクライアントから受け取った判定用データ中のhの値は1だけ増加された値に変更される。クライアントRは自己が責任を有するクライアントであると記憶しているので、受信したつなぎかえ要求に応答する。すなわち、クライアントRは、責任を有するクライアントをクライアントRとして記憶するように指令するつなぎかえ指定をクライアントN2に送信するS6007。つなぎかえ指定を受信したクライアントN2は責任を有するクライアントをクライアントRとするように記憶内容、すなわち問い合わせ先5025の内容を更新するつなぎかえ処理を行うS6008。さらにクライアントRはクライアントN3にもつなぎかえ指定を送信するS6010し、また差分通知要求S6001に対応する結果送信S6009を行う。つなぎかえ指定S6010を受信したクライアントN3は責任を有するクライアントをクライアントRとするように記憶内容、すなわち問い合わせ先5025の内容を更新するS6011。また、クライアントN3は結果送信S6011の内容に基づいて差分除去を行うS6012。次に、クライアントN3は差分除去S6012後のデータベースの内容に基づいて、差分検索の要求をクライアントRに送信するS6013。差分検索の要求を受信したクライアントRはSQL受付を行うS6014。SQLの内容に基づいてデータベース検索を実行し差分検索結果を生成したクライアントRは、結果をクライアントN3に送信するS6015。クライアントRから差分検索結果を受信S6016したクライアントN3は自己のデータベース検索内容とクライアントRの差分検索内容により、完全な最新のデータベース内容についての検索結果を得られることになる。また、検索に関する処理の一方、つなぎかえ処理S6008、S6011が行われたクライアントN3,N2については責任を有するクライアントRに次回からはダイレクトに問い合わせを送信することが可能となる。変形例上記の検索処理においては、差分通知要求と差分検索要求を別々に送信するものとして説明したが、本実施の形態では差分通知要求と差分検索要求を同時に送信するようにしても、サーバを用いない検索を成立させることができる。検索クエリが小さい場合はこのように同時に送信する方が有効からである。図61は、差分通知要求と差分検索要求を同時に送信するようにした場合の、サーバを用いることなく検索を行う場合の本実施の形態に係るデータベースシステムの動作例を示したシーケンス図である。ここで説明する例において、1つのマスタークライアント4801、及び3つのノードクライアント4803互いを区別するため、マスタークライアント4801をクライアントR、3つのノードクライアント4803をクライアントN1、クライアントN2,クライアントN3と呼ぶが存在している。クライアントN3は責任を有するのはクライアントN2であると記憶しており、クライアントN2は責任を有するのはクライアントN1であると記憶しており、クライアントN1は責任を有するのはクライアントRであると記憶しており、実際に責任を有しているのはクライアントRである。まず、検索を実行しようとするクライアントN3は、差分通知要求及び検索要求S6101と、つなぎかえ要求S6102をクライアントN2に送信する。つなぎかえ要求には、自己分の判定用データが含まれている。差分通知要求及び検索要求S6101とつなぎかえ要求S6102を受信したクライアントN2は、自分は責任を有していないので、責任を有するクライアント、すなわち問い合わせ先5025に記憶しているクライアントN1に差分通知要求及び検索要求を送信するS6103。また、クライアントN2はクライアントN3から受信した判定用データとともに、自己分の判定用データを含めたつなぎかえ要求をクライアントN1に送信するS6104。具体的にはクライアントN3分の判定用データと、自己N2の判定用データが含まれる。差分通知要求及び検索要求S6103とつなぎかえ要求S6104を受信したクライアントN1は、自分は責任を有していないので、責任を有すると記憶しているクライアントRに差分通知要求及び検索要求S6105を送信する。また、クライアントN1は他のクライアントから受信した判定用データ及び自己分の判定用データを含めたつなぎかえ要求S6106をクライアントRに送信する。具体的にはクライアントN3分の判定用データ、クライアントN2分の判定データと、自己N1の判定用データが含まれる。差分通知要求及び検索要求、つなぎかえ要求を受信したクライアントRは、差分通知要求に応じたSQL受付を行うS6107。また、クライアントRは自己が責任を有するクライアントであると記憶しているので、つなぎかえ要求に応答する。すなわち、クライアントRは、責任を有するクライアントをクライアントRとして記憶するように指令するつなぎかえ指定をクライアントN2及びクライアントN3に送信するS6108、S6111。なお、この例ではクライアントN1についてはつなぎ換えを行っても有利にならないと判定されたため、クライアントN1についてはつなぎ換え指定は送信されないものとする。つなぎ換え指定を受信したクライアントN2は、つなぎかえ指定S6108に応じて、問い合わせ先2055をクライアントRとするように記憶内容を更新するつなぎかえ処理を行うS6109。次に、クライアントRは差分通知要求に応答する差分把握を生成するとともに、SQL受付S6107に基づいてデータベース検索を実行し差分検索結果を生成し、これらをクライアントN3に送信するS6110。また、クライアントRはクライアントN3にもつなぎかえ指定を送信するS6108。クライアントN3は、クライアントRから送信された結果送信の内容に基づいて差分除去を行うS6114。また、クライアントN3は、つなぎかえ指定S6111に応じて、問い合わせ先2055をクライアントRとするように記憶内容を更新するつなぎかえ処理を行うS6113。最後に、クライアントN3は差分除去後の自己のデータベース検索内容とクライアントRから受信した差分検索内容により、最新のデータベース内容についての検索結果を得られることになる。また、それぞれのつなぎかえ処理S6108、S6111により、クライアントN2,N3は、最新のデータを有するクライアントRに次回からは他のクライアントを経由することなくダイレクトに問い合わせを送れるようになる。クライアントの動作例次に、個々のクライアント48014803の動作例について説明する。クライアントの動作例:検索の場合図62は、本データベースシステムにおいて、あるノードクライアント4803がデータの検索差分検索を行うときの動作例を示したフローチャートである。検索差分検索を行う場合、ノードクライアント4803以下、区別のため起点クライアントと呼ぶ、より詳しくは接続開始部5001が問い合わせ先5025に記述されたクライアント48014803以下、問い合わせ先クライアントと称すとの通信を確立する図略。次にこの起点クライアント、より詳しくは差分通知部5005は、問い合わせ先クライアントに差分通知要求を送信するS6201。次に、起点クライアント、より詳しくはそのつなぎかえ要求部5019は、問い合わせ先クライアントにつなぎかえ要求を送信するS6202。起点クライアント、より詳しくはそのつなぎかえ処理部5017は、データに対して責任更新権を有するクライアントからつなぎかえ指定が送信されてくるのを待ち受けるS6203。責任更新権を有するクライアントからつなぎかえ指定を受信すると、起点クライアント、より詳しくはそのつなぎかえ処理部5017は、つなぎかえ指定に記述されたクライアントを新たな問い合わせ先クライアントとするように、問い合わせ先5025の内容を書き換える処理であるつなぎかえ処理を実行するS6205。また、起点クライアント、より詳しくはその差分通知部5005は、先に送信した差分通知要求S6201に応答する結果を待ち受けるS6206。責任更新権を有するクライアントから前記差分通知要求に対する結果を受信するS6207と、起点クライアント、より詳しくはその差分除去部5005は、受信した結果に基づいてデータベースの4905の差分除去を行うS6208。次に、起点クライアント、より詳しくはその差分検索部5007は、責任更新権を有するクライアントへ差分検索の要求を送信しS6209、責任更新権を有するクライアントから差分検索の結果を受信するS6210。次に、前述した起点クライアントから差分通知要求、つなぎかえ要求を受信する問い合わせ先クライアントの動作例について説明する。なお、問い合わせ先クライアントは、差分通知、つなぎかえ要求の双方に対応処理するのであるが、ここでは差分通知、つなぎかえ要求の対応を分けて説明する。[差分通知に対する対応]図63は問い合わせ先クライアントの差分通知要求に対する対応処理の一例を示したフローチャートである。まず、問い合わせ先クライアントは差分通知要求を受信するS6301。問い合わせ先クライアントは自己の更新権5024の内容を参照して、自己が更新権を保有しているか否かを判定するS6302。自己が更新権を保有していると判定した場合S6302、Yes、この問い合わせ先クライアントは、責任更新権を有するクライアントであるので、差分通知要求に応答して、差分通知を起点クライアントに送信しS6303、処理を終了する。一方、ステップS6302において自己が更新権を保有していないと判定した場合S6302、No、問い合わせ先クライアントは、自己の問い合わせ先5025に記述されたクライアント区別のため、次段問い合わせ先クライアントと呼ぶに対して、起点クライアントから受信した差分通知要求を転送し6304、処理を終了する。この差分通知要求を転送された次段問い合わせ先クライアントは、同様にステップS6301からステップS6304までの処理を実行する。差分通知要求の転送は責任更新権を有するクライアントに到達するまで繰り返される。[つなぎかえ要求に対する対応]次に、問い合わせ先クライアントのつなぎかえ要求に対する応答処理について説明する。図64は、問い合わせ先クライアントのつなぎかえ要求に対する応答処理を示したフローチャートである。まず、問い合わせ先クライアントはつなぎかえ要求を受信するS6401。問い合わせ先クライアントは自己の更新権5024の内容を参照して、自己が更新権を保有しているか否かを判定するS6402。自己が更新権を保有していると判定した場合S6402、Yes、この問い合わせ先クライアントは、ステップS6401において受信したつなぎかえ要求に含まれるデータから、ノード1件分のデータを取得するS6404。問い合わせ先クライアントは、取得したノード1件分のデータに基づいて当該ノードについてつなぎ換えを行わせた方が有利になるか否かを判定するS6405。有利にならないと判定した場合S6405、No、この問い合わせ先クライアントはそのまま処理を終了する。一方、有利になると判定した場合S6405、Yes、この問い合わせ先クライアントは、前記取得したノード1件分のデータに対応するクライアントに、自己を問い合わせ先とするようにつなぎかえ処理を行うよう指示するつなぎかえ指定を送信するS6407。次に、この問い合わせ先クライアントはステップS6401において受信したつなぎかえ要求に含まれる、全てのノード分のデータを処理したか否かを判定するS6407。全て処理したと判定した場合S6407,Yes、この問い合わせ先クライアントは処理を終了する。一方、全て処理していないと判定した場合S6407,No、この問い合わせ先クライアントはステップS6404に戻り、未処理のノードのデータについてステップS6404からS6407の処理を繰り返し行う。責任更新権を有するクライアントであるので、つなぎかえ要求に応答して、つなぎかえ指定を起点クライアントに送信しS6403、処理を終了する。一方、ステップS6302において自己が更新権を保有していないと判定した場合S6302、No、問い合わせ先クライアント、より詳しくはその判定部5022は起点クライアントから受信しているつなぎかえ要否判定に要するデータ、自己分のつなぎかえ要否判定に要するデータを含むつなぎかえ要求を、自己の問い合わせ先すなわち、次段問い合わせ先クライアントに送信するか否かを判定するため、前述の判定条件式を用いて、つなぎかえを行った方が送信データ量削減の観点等から有利であるか否かを判定するS6404。ステップS6402において、更新権を保有していないと判定した場合S6402、No、問い合わせ先クライアント、より詳しくはそのつなぎかえ要求部5019は、次段問い合わせ先クライアントにつなぎかえ要求を送信するS6403。なお、このつなぎかえ要求には、起点クライアントから受信しているつなぎかえ要否判定に要するデータ、自己分のつなぎかえ要否判定に要するデータが含まれるように構成される。問い合わせ先クライアント、より詳しくはそのつなぎかえ処理部5017は、データに対して責任更新権を有するクライアントからつなぎかえ指定が送信されてくるのを待ち受けるS6406。責任更新権を有するクライアントからつなぎかえ指定を受信するS6407と、問い合わせクライアント、より詳しくはそのつなぎかえ処理部5017は、つなぎかえ指定に記述されたクライアントを新たな問い合わせ先クライアントとするように、問い合わせ先5025の内容を書き換える処理である問い合わせ処理を実行するS6408。問い合わせ先クライアントからつなぎかえ要求を送信若しくは転送された次段問い合わせ先クライアントは、同様にステップS6401からステップS6408までの処理を実行する。つなぎかえ要求の転送は責任更新権を有するクライアントに到達するまで繰り返される。クライアントの動作例:更新同期の場合次に、本実施の形態に係るデータベースシステムにおいて、あるノードクライアント4803がデータの更新同期を行うときの動作例について述べる。起点クライアントが更新要求を送信するに先だって、差分通知要求を行うため、更新同期の場合におけるつなぎかえ要求の送信、つなぎかえ要求の転送、つなぎかえ要求への応答は、図62、図64において説明した処理と同様となるので、ここでは詳細な内容の説明は省略する。次に、更新要求を受信した問い合わせ先クライアントの動作例について説明する。図65は、更新要求を受信した問い合わせ先クライアントの動作例を示したフローチャートである。まず、問い合わせ先クライアントは更新要求を受信するS6501。問い合わせ先クライアントは自己の更新権5024の内容を参照して、自己が更新権を保有しているか否かを判定するS6502。自己が更新権を保有していると判定した場合S6402、Yes、この問い合わせ先クライアント、より詳しくは同期送信部5012は、責任更新権を有するクライアントであるので、更新要求に応答して、更新に必要なデータ差分データを起点クライアントに送信しS6503、更新権利破棄部5015が更新権破棄処理を実行して、更新権5024の内容を更新権を保有しないことを示す情報を示すものに書き換えS6504、問い合わせ先5025の内容を新たに最新のデータベース内容を有することになった起点クライアントを示す情報に書き換えS6505、これを持って処理を終了する。一方、ステップS6502において自己が更新権を保有していないと判定した場合S6502、No、問い合わせ先クライアントは、自己の問い合わせ先5025に記述されたクライアント区別のため、次段問い合わせ先クライアントと呼ぶに対して、起点クライアントから受信した更新要求を転送しS6506、処理を終了する。この更新要求を転送された次段問い合わせ先クライアントは、同様にステップS6501からステップS6506までの処理を実行する。更新要求の転送は責任更新権を有するクライアントに到達するまで繰り返される。[第6の実施の形態のまとめ]1本実施の形態は、サーバレスなシステムを構築することを可能とする。2本実施の形態では、クライアント間で検索や更新のための通信をするときコストが発生するが、それを無駄にしないことを可能とする。クライアント間で通信するときに、今後の負担データベースシステム全体における送信データ量を減らすデータのやり取りも実施するためである。第7の実施の形態次に、本発明の第7の実施の形態について説明する。第7の実施の形態は、前述した第6の実施の形態と同様の構成を有するデータベースシステムである。但し、各クライアントは後述する最新保証を実行するための構成をさらに有している点で、第6の実施の形態と異なる。第7の実施の形態の特徴は、第6の実施の形態の特徴に加えて最新保証を行うデータベースシステムであることにある。最新保証とは、データベースシステム内のクライアントにおいて、最新のデータを保持しているクライアントが、そのクライアントを問い合わせ先にしている他のクライアントに対して、データが最新であることを保証する通知を行うことによって、検索要求を抑える処理である。図66を参照しながら、最新保証処理の概略を示す。図66Aは最新保証前のマスタークライアントと2つのノードクライアントの関係を示す図であり、図66Bは最新保証実行時のマスタークライアントと2つのノードクライアントの関係を示す図である。今、データベースシステムに3つのクライアントが存在するものとする。クライアントAはマスタークライアントであり、クライアントBCはクライアントAを問い合わせ先とするノードクライアントである。また、クライアントAのデータベースのバージョンと、クライアントBCにおけるデータベースのバーションは同一になっているものとする。クライアントBCはデータの検索を行う必要が生じた時、クライアントAに問い合わせを送信することになるS6601。このとき、クライアントAのデータベースバージョンに変更がなければ、この問い合わせは無駄なものである。そこで、第7の実施の形態においては、クライアントAは、クライアントBCに対してデータベースのバーションを減少させ、データベースシステム内での負荷分散を図ることが可能となる。最新保証の実行要否判断第7の実施の形態では、上述の最新保証通知、最新保証切れ等の最新保証処理を行うか否かを、最新保証を行うために必要なデータ送信量が、最新保証を行うことによって減少させることができるデータ送信量より小さいか、という判定に基づいて判断するようにしてもよい。以下に、最新保証処理を行うか否かを判定する方法の具体例を述べる。クライアント4801,4803は以下の条件判定式を計算することにより、最新保証処理を判定する。条件判定式が満たされる場合は、最新保証処理を実行すると判定する。条件判定式は以下の通りである。<更新するまでに検索する回数×問い合わせ通信の減る量ここで投資とは、最新保証を行うために必要なデータ送信量である。問い合わせ通信とは、差分検索要求のための通信である。ここで、投資=2dにより定まる値を用いる。dは最新保証通知に要するデータ送信量、pサーバが完全である確率である。更新するまでに検索する回数は予測値を用い、問い合わせ通信の減る量は前述のdを用いる。ここでは、更新するまでに検索する回数は属している子供の数に比例し、更新の確率は、全ノード数に比例する。また、更新するまでに検索する回数=検索の確率更新の確率により定まるものと考えられる。条件判定式について上記条件判定式について説明する。図71は最新保証処理のコストと効果を説明するための状態遷移図である。まずコストについて説明する。コストとは、最新保証を行うために必要なデータ送信量である。第7の実施の形態では、状態最新保証前から状態最新保証中、状態最新保証後に状態遷移が起こりうる。状態最新保証前から状態最新保証中に遷移する場合には、最新保証通知を送信するため、コストとしてデータ送信量dが発生する。また、状態最新保証中から状態最新保証後に遷移する場合には、最新保証切れ通知を送信するため、コストとしてデータ送信量dが発生する。よって最新保証を行うためにかかるコストはdd=2dとなる。次に、効果について説明する。効果とは、最新保証を行うことによって減少させることができるデータ送信量である。最新保証を行わない場合には1回の検索が生ずるごとにデータ送信量2dが発生する。したが、次の更新が行われるまでに検索が行われるごとに2dのデータ送信量が発生するところを抑止して、データ送信量の削減を図ることができる。これが最新保証の効果であり、2d×更新までに検索が発生する回数と表すことができる。条件判定式は、コストが効果以下になるかを判定するので、2d≦2d×更新までに検索が発生する回数、すなわち1≦更新までに検索が発生する回数が満たされれば、最新保証を行うと判定すればよい。更新までに検索が発生する回数次に、更新までに検索が発生する回数について説明する。まず、正規化済みの検索確率をPとし、更新確率を1-Pとする。更新まで行われる検索の回数と、その確率を対応付けて表すと0回:1P1回:P2回:PP...これを展開するととなる。上記を等比級数の和によりとなる。したがって、が1より大きければ条件判定式が満たされる。これは検索確率Pが更新確率1-Pより大きければ最新保証をした方が有利であること意味する。具体例1、このマスタークライアント4801を問い合わせ先5025に記憶しているノードクライアント4803、ノードクライアントN1を問い合わせ先5025に記憶しているノードクライアント4803、ノードクライアントN1を直接、又は間接に問い合わせるノードクライアント4803の集団ノードクライアントN1の下位ノード集団と呼ぶ及びノードクライアントN2を直接、又は間接に問い合わせるノードクライアント4803の集団ノードクライアントN2の下位ノード集団と呼ぶがある。また、ノードクライアントN1の下位ノード集団、ノードクライアントN1の下位ノード集団に含まれるノードクライアント数はともにC=29とする。さて、検索確率はある一定期間の検索の頻度、更新確率はある一定期間の検索の頻度に置き換えてよい。よって、更新の確率≦検索の頻度が成立すれば、条件判定式が満たされると判定できる。ここで、検索の頻度は、対象となるノードクライアントの子ノードに比例するので、検索の頻度=子ノードの数×n×1-pで表すことができる。上記式におけるp、nについて以下に述べる。<確率pについて>マスタークライアント4801のデータが完全である確率をpとすると、マスタークライアント4801がノードクライアント4803に更新データを確認しなければいけない確率が1-pと表せる。具体例を示すと、1日のうち9割は同期できる環境と設定すれば、確率pは0.9であり、1-pは0.1である。<確率nについて>確率nは、1クライアントあたりのある一定期間での検索回数である。平均して、1日あたり04回の検索をした場合、確率nは04である。次に、更新の頻度について述べる。更新の頻度は、全ノードに比例するので、更新の頻度=全ノード数×u×1-pと表せる。以下に、上記式のp、uについて述べる。pは前述と同様にマスタークライアント4801のデータが完全である確率である。確率uは1クライアントあたりのある一定期間での更新回数である。平均して、1日あたり015回の更新をした場合、確率uは015となる。図72に示した例を上記2式に当てはめてみる。検索の頻度は子ノードの数×n×1-p=×04×01=12である。更新の頻度は全ノード数×u×1-p=×015×01=09である。よってこの条件では、更新確率≦検索確率なのでマスタークライアントRはノードクライアントN1に対して、最新保証をした方がよいと判定することになる。具体例2、このマスタークライアント4801を問い合わせ先5025に記憶しているノードクライアント4803、マスタークライアント4801を問い合わせ先5025に記憶している別のノードクライアント4803、マスタークライアント4801を問い合わせ先5025に記憶しているさらに別のノードクライアント4803、ノードクライアントN1、N2,N3のそれぞれを直接、又は間接に問い合わせるノードクライアント4803の集団ノードクライアントN1の下位ノード集団、ノードクライアントN2の下位ノード集団、ノードクライアントN3の下位ノード集団と呼ぶまた、ノードクライアントN1の下位ノード集団、ノードクライアントN2の下位ノード集団、ノードクライアントN3の子ノード集団に含まれるノードクライアント数はいずれもC=19とする。前述の確率p、n、uを図72の場合と同様として、図73に示した例における条件判定式の成否を検討する。検索の頻度は子ノードの数×n×1-p=×04×01=08である。更新の頻度は全ノード数×u×1-p=×015××01=09である。よって、更新確率≦検索確率ではないのでマスタークライアントRはノードクライアントN1に対して、最新保証をしない方がよいと判定することになる。第7の実施態様におけるデータベースシステムの構成例次に、第7の実施態様におけるデータベースシステムの構成例について説明する。第7の実施態様におけるデータベースシステムの構成例は、図48に示した第6の実施の形態におけるデータベースシステムの構成例と同様であり、第7の実施態様における各クライアントの構成も、図49に示した構成と同様であるので、これらの構成要素の詳細な説明は省略する。但し、命令制御部4903の構成については、異なる点がある。図74に第7の実施の形態における命令制御部4903の機能ブロック図を示して説明する。第7の実施の形態における命令制御部4903は、第6の実施の形態における命令制御部4903が有する各構成要素に加えてさらに、差分通知要求部500A,最新保証フラグ処理部5018、最新保証通知部5020、最新保証切れ通知部5021、及び記憶されうるデータとして最新保証フラグ5026を有している点で異なっている。差分通知要求部500Aは、問い合わせ先5005Aである他のクライアントに、自己のデータベースと当該他のクライアントのデータベースの差分の通知を求めるメッセージである差分通知要求を送信する機能を有する。差分通知要求部5005Aは、本実施の形態の差分通知要求手段に相当する。なお、差分通知部5005は、本実施の形態の差分通知手段に相当する。最新保証フラグ処理部5018は、最新保証通知又は最新保証切れ通知を受信したときに、最新保証フラグ5026の内容を最新保証があることを示す情報、又は最新保証がないことを示す情報に書き換える機能を有する。最新保証フラグ処理部5018は本実施の形態の最新保証情報管理手段に相当する。最新保証通知部5020は、自分のデータベース4905の内容と同期済みである他のクライアントが記憶しているデータベース4905の記憶内容が最新であることを通知する処理を行う。最新保証通知部5020は、本実施の形態の最新保証通知手段に相当する。最新保証切れ通知部5021は、自分のデータベース4905の内容と同期済みである他のクライアントが記憶しているデータベース4905の記憶内容が最新でなくなったことを通知する処理を行う。最新保証切れ通知部5021は、本実施の形態の最新保証切れ通知手段に相当する。最新保証フラグ5026は、最新保証を受けているか否かを示す情報である。例えば、最新保証フラグが1なら当該クライアントはそのデータベースの内容が最新であるという保証がある状態を示し、0であればそのような保証がない状態を示す。最新保証フラグ5026は、本実施の形態の最新保証情報に相当する。なお、第7の実施の形態においては、判定部5022は、予測データ5027に基づいて、つなぎかえ要求の要否、最新保証通知の要否、最新保証切れの要否の判定を行う。また、判定部5022は最新保証フラグの内容によって、他のクライアントから差分通知要求を受信したときに、当該他のクライアントにこの差分通知要求に応答して差分通知を送信するか、或いは問い合わせ先5025に定められたクライアントに差分通知要求を送信するかを判定し、判定に基づいて差分通知部5005に差分通知を送信させ、或いは差分通知要求部5005Aに差分通知要求を送信させる。判定部5022は、本実施の形態の判定手段に相当する。その他の構成要素については第6の実施の形態と同様であるので、それらの詳細な説明は省略する。第7の実施態様におけるデータベースシステムの動作例1次に、第7の実施態様におけるデータベースシステムの動作例を説明する。ここでは、最新保証処理と同時には、つなぎかえ処理を行わない設定であるとして説明する。図75に本実施の形態に係るデータベースシステムの動作例をシーケンス図として示す。図75に示す例では、1つのマスタークライアント4801、及び3つのノードクライアント4803互いを区別するため、マスタークライアント4801をクライアントR、3つのノードクライアント4803をクライアントN1、クライアントN2,クライアントN3と呼ぶが存在している。但し、後述するクライアントRによる更新権利取得S7507前においては、クライアントN1がマスタークライアントであり、クライアントRはノードクライアントとして振る舞っている図略。後述するステップS7501実行時点において、クライアントN3は責任を有するのはクライアントN2であると記憶しており、クライアントN2は責任を有するのはクライアントN1であると記憶しており、実際に責任を有しているのはクライアントN1である。この時点ではマスタークライアントであるクライアントN1は、任意のタイミングで最新保証通知を行うか否かの判定処理を実行するS7501。具体的には、クライアントN1の判定部5022は、予測データ5027から必要なデータを読み取り、クライアントN2について前述した条件判定式の成立非成立の判定を実行する。条件判定式が成立していると判定した場合は、クライアントN1はクライアントN2に最新保証通知メッセージを送信するS7502。具体的には、クライアントN1の判定部5022が最新保証通知部5020に最新保証通知メッセージをクライアントN2に送信することを命令し、最新保証通知部5020は接続開始部5001による通信の確立後、最新保証通知メッセージをクライアントN2に送信する。なお、条件判定式が成立していないと判定した場合は、クライアントN1、より詳しくはその判定部5022は処理を終了し、次の判定実行タイミングの到来まで待機する。前記最新保証通知メッセージを受信したクライアントN2は最新保証フラグ処理を実行するS7503。具体的にはクライアントN2の最新保証処理部5018は、最新保証通知メッセージの受信を検出すると、最新保証フラグ5026を最新保証されている状態が開始したことを示す情報に書き換える。このステップS7503が実行された後、クライアントN3においてデータベース検索の必要性が生じ、クライアントN3は差分通知要求を問い合わせ先として記憶しているクライアントN2に送信するS7504。差分通知要求を受信したクライアントN2は差分通知要求に応答してよいか否か判定するため、まず更新権5024を参照して、更新権を有しているか否かを調べ、有していない場合には最新保証フラグ5026を参照して最新保証されている状態が開始しているか否かを調べる。いずれかを有している場合には、クライアントN2は差分通知要求に応答して差分通知を送信する。この例では、この時点ではクライアントN1が更新権を所有しており、クライアントN2は更新権は有していないが、最新保証されている状態が開始しているので、クライアントN2は差分通知をクライアントN3に送信するS7505。差分通知を受信したクライアントN3は、受信した内容を用いて自己のデータベース4905の差分除去を実行するS7506。さて、この状態の後、この時点ではノードクライアントの一つであったクライアントRが自己のデータベース4905の更新を実行し、データベースの内容が本データベースシステム内で最新のバージョンになったものとする。クライアントRは更新権取得処理を実行するS7507。具体的にはクライアントRの更新権取得部5014が更新権5024のデータを更新権保有を示す情報に書き換えるとともに、従前更新権を保有していたクライアント本例ではクライアントN1に、自己が更新権保有したことを通知するメッセージ以下、更新権保有通知メッセージというを送信する。更新権保有通知メッセージを受信したクライアントN1は、更新権利破棄処理を実行するS7508。具体的には、クライアントN1の更新権利破棄部5015が更新権保有通知メッセージの受信を検出すると、更新権5024のデータ内容を、更新権を保有していないことを示す情報に書き換える。次に、クライアントN1は更新権利破棄の実行をトリガーとして、最新保証切れメッセージをクライアントN2に送信するS7509。なお、最新保証切れメッセージは当該クライアントが直近の更新権保有後に最新保証通知メッセージを送信したクライアントそれぞれの送信するのであるが、本例ではクライアントN2のみ送信対象となる。最新保証切れメッセージを受信したクライアントN2は、最新保証フラグ処理を実行しS7510、自己の最新保証フラグ5026の記憶内容を、最新保証が終了していることを示す内容に書き換える。これにより、クライアントN2は他のクライアントから差分検索要求を受信した場合、問い合わせ先5025が示すクライアントに差分検索要求を送信するようになる。第7の実施態様におけるデータベースシステムの動作例2次に、第7の実施態様におけるデータベースシステムの動作例を説明する。ここでは、最新保証に関する処理と同時につなぎかえ処理を行う設定であるとして説明する。図76に本実施の形態に係るデータベースシステムの動作例をシーケンス図として示す。図76に示す例において、1つのマスタークライアント4801、及び3つのノードクライアント4803互いを区別するため、マスタークライアント4801をクライアントR、3つのノードクライアント4803をクライアントN1、クライアントN2,クライアントN3と呼ぶが存在している。但し、後述するクライアントRによる更新権利取得S7608前においては、クライアントN1がマスタークライアントであり、クライアントRはノードクライアントとして振る舞っている図略。後述するステップS7601実行時点において、クライアントN3は責任を有するのはクライアントN2であると記憶しており、クライアントN2は責任を有するのはクライアントN1であると記憶しており、実際に責任を有しているのはクライアントN1である。この時点ではマスタークライアントであるクライアントN1は、任意のタイミングで最新保証通知を行うか否かの判定処理を実行するS7601。具体的には、クライアントN1の判定部5022は、予測データ5027から必要なデータを読み取り、クライアントN2について前述した条件判定式の成立非成立の判定を実行する。条件判定式が成立していると判定した場合は、クライアントN1はクライアントN2に最新保証通知メッセージを送信するS7602。具体的には、クライアントN1の判定部5022が最新保証通知部5020に最新保証通知メッセージをクライアントN2に送信することを命令し、最新保証通知部5020は接続開始部5001による通信の確立後、最新保証通知メッセージをクライアントN2に送信する。なお、条件判定式が成立していないと判定した場合は、クライアントN1、より詳しくはその判定部5022は処理を終了し、次の判定実行タイミングの到来まで待機する。前記最新保証通知メッセージを受信したクライアントN2は最新保証フラグ処理を実行するS7603。具体的にはクライアントN2の最新保証処理部5018は、最新保証通知メッセージの受信を検出すると、最新保証フラグ5026を最新保証されている状態が開始したことを示す情報に書き換える。このステップS7603が実行された後、クライアントN3においてデータベース検索の必要性が生じ、クライアントN3は差分通知要求及びつなぎかえ要求を問い合わせ先として記憶しているクライアントN2に送信するS7604、S7605。差分通知要求及びつなぎかえ要求を受信したクライアントN2は差分通知要求に応答してよいか否か判定するため、まず更新権5024を参照して、更新権を有しているか否かを調べ、有していない場合には最新保証フラグ5026を参照して最新保証されている状態が開始しているか否かを調べる。いずれかを有している場合には、クライアントN2は差分通知要求に応答して差分通知を送信するS7606。この例では、この時点ではクライアントN1が更新権を所有しており、クライアントN2は更新権は有していないが、最新保証されている状態が開始しているので、クライアントN2は差分通知をクライアントN3に送信するS7606。差分通知を受信したクライアントN3は、受信した内容を用いて自己のデータベース4905の差分除去を実行するS7607。また、つなぎかえ要求S7605に対しては、クライアントN2は第6の実施の形態において説明した通り、マスタークライアントに到達するまでつなぎかえ要求の転送が繰り返され、マスタークライアントこの例のこの時点ではクライアントN1にて第6の実施の形態において述べた条件判定式に基づいてつなぎかえの要否が判定され、判定の結果に基づいて必要な場合にはつなぎかえ指示がつなぎかえ要求を発したそれぞれのクライアントに送信される図略。さて、ステップS7605の後、この時点ではノードクライアントの一つであったクライアントRが自己のデータベース4905の更新を実行し、データベースの内容が本データベースシステム内で最新のバージョンになったものとする。クライアントRは更新権取得処理を実行するS7608。具体的にはクライアントRの更新権取得部5014が更新権5024のデータを更新権保有を示す情報に書き換えるとともに、従前更新権を保有していたクライアント本例ではクライアントN1に、自己が更新権保有したことを通知するメッセージ以下、更新権保有通知メッセージというを送信する。更新権保有通知メッセージを受信したクライアントN1は、更新権利破棄処理を実行するS7608とともにつなぎかえ処理を実行するS7610。具体的には、クライアントN1の更新権利破棄部5015が更新権保有通知メッセージの受信を検出すると、更新権5024のデータ内容を、更新権を保有していないことを示す情報に書き換える。また、つなぎかえ処理部5017が更新権保有通知メッセージの受信を検出すると、問い合わせ先5025のデータ内容を、更新権保有通知メッセージの送信元であるクライアントを示す情報に書き換える。次に、クライアントN1は更新権利破棄の実行をトリガーとして、最新保証切れメッセージ及びつなぎかえ指定メッセージをクライアントN2に送信するS7611、S7612。なお、最新保証切れメッセージは当該クライアントが直近の更新権保有後に最新保証通知メッセージを送信したクライアントそれぞれに送信するのであるが、本例ではクライアントN2のみ送信対象となる。最新保証切れメッセージを受信したクライアントN2は、最新保証フラグ処理を実行しS7613、自己の最新保証フラグ5026の記憶内容を、最新保証が終了していることを示す内容に書き換える。また、つなぎかえ指定メッセージを受信したクライアントN2は、つなぎかえ処理を実行しS7614、自己の問い合わせ先5025の記憶内容を、つなぎかえ指定メッセージにおいて指定されているクライアントこの例ではクライアントN1を示す内容に書き換える。上記ステップS7613、S7614により、クライアントN2は他のクライアントから差分検索要求を受信した場合、問い合わせ先5025が示すクライアントに差分検索要求を送信するようになる。クライアントの動作例次に、個々のクライアント48014803の最新保証処理における動作例について説明する。クライアントの動作例:最新保証通知処理図77にクライアント48014803、より詳しくは最新保証通知部5020が実行する最新保証通知処理の一例のフローチャートを示す。最新保証通知処理において、クライアント48014803、より詳しくは最新保証通知部5020はまず最新保証通知実行トリガーがあるか否かを判定するS7710。最新保証通知実行トリガーは、最新保証通知をなすのに適したとき又は条件などを判定できるようなものであれば、どのようなものであってもよく、所定時間の経過であってあってもよいし、他のクライアントから受信した差分検索要求数が所定値をこえたことであってもよい。最新保証通知実行トリガーがないと判定される場合S7710,Noは再びS7710に戻り最新保証通知実行トリガーの発生を待つ。最新保証通知実行トリガーがないと判定される場合S7710,Noは、クライアント48014803、より詳しくは最新保証通知部5020は判定部5022に第7の実施の形態における条件判定式が成立するか否かを判定させるS7720。判定部5022は、予測データ5027から判定に必要なデータ例えば、検索の頻度、更新の頻度、などを読み出し、このデータに基づいて条件判定式が成立するか否かを判定する。条件判定式が成立すると判定された場合S7720、Yes、クライアント48014803、より詳しくは最新保証通知部5020は自己と同一バーションのデータベース内容を有する他のクライアント48014803に最新保証通知メッセージを送信するS7730。条件判定式が成立しないと判定された場合S7720、Yesは、クライアント48014803、より詳しくは最新保証通知部5020はなにも行わず再びステップS7710に戻り最新保証通知実行トリガーの発生を待つ。以上で、最新保証通知処理の説明を終了する。クライアントの動作例:最新保証通知処理図78にクライアント48014803、より詳しくは最新保証切れ通知部5021が実行する最新保証切れ通知処理の一例のフローチャートを示す。最新保証切れ通知処理において、クライアント48014803、より詳しくは最新保証切れ通知部5020はまず自己が更新権を有しているか否かを更新権5024を参照して判定するS7810。更新権を有していると判定した場合S7810、Yes、従前に発した最新保証は有効な状態なので、なにもせずステップS7810に戻る。更新権を有していないと判定した場合S7810、No、最新保証切れ通知処理において、クライアント48014803、より詳しくは最新保証切れ通知部5020は、他のクライアントに送信した最新保証通知が存続しているか否かを判定するS7820。最新保証通知が存続していないと判定した場合S7820、No、取り消すべき最新保証通知は存在していないため、なにもせずステップS7810に戻る。一方、最新保証通知が存続していると判定した場合S7820、Yes、クライアント48014803、より詳しくは最新保証切れ通知部5020は、存続している最新保証通知の送信先であるクライアントに最新保証切れ通知を送信するS7830。以上で、最新保証切れ通知処理の説明を終了する。クライアントの動作例:最新保証フラグ処理図79にクライアント4803、より詳しくは最新保証フラグ部5021が実行する最新保証切れ通知処理の一例のフローチャートを示す。最新保証フラグ処理において、クライアント4803、より詳しくは最新保証フラグ処理部5018はまず通知待ち受けを実行するS7910。他のクライアントから通知を受信したか否かを判定S7920し、通知を受信していないと判定した場合S7920,Noは、ステップS7910に戻り通知待ち受けを継続する。一方、通知を受信したと判定した場合S7920、Yes、クライアント4803、より詳しくは最新保証フラグ処理部5018はその通知が最新保証通知か否かを判定するS7930。その通知が最新保証通知であると判定した場合S7930、Yes、クライアント4803、より詳しくは最新保証フラグ処理部5018は最新保証フラグ5026の内容を最新保証があることを示す情報に書き換えるS7940。一方、その通知が最新保証通知ではないと判定した場合S7930、No、クライアント4803、より詳しくは最新保証フラグ処理部5018はその通知が最新保証切れ通知か否かを判定するS7950。その通知が最新保証切れ通知であると判定した場合S7940、Yes、クライアント4803、より詳しくは最新保証フラグ処理部5018は最新保証フラグ5026の内容を最新保証がないことを示す情報に書き換えるS7960。一方、その通知が最新保証切れ通知でないと判定した場合S7940、Yes、クライアント4803、より詳しくは最新保証フラグ処理部5018はステップS7910に戻り通知待ち受けを続行する。以上で、最新保証フラグ処理の説明を終了する。クライアントの動作例:差分検索通知受信時処理図80にクライアント48014803が実行する差分検索通知受信時処理の一例のフローチャートを示す。他のクライアントから差分通知要求を受信すると、クライアント48014803は自己の更新権5024を参照して、更新権を保有しているか否かを判定するS8010。更新権を保有していると判定した場合S8010、クライアント48014803は差分通知要求の送信元であるクライアントのバージョンと自己のバージョンの差分を知らせる差分通知を、当該差分通知要求の送信元である他のクライアントに送信しS8030、処理を終了する。一方、更新権を保有していないと判定した場合S8010、No、クライアント48014803は自己の最新保証フラグ5026を参照し、最新保証を受けているか否かを判定するS8020。最新保証を受けていると判定した場合S8020、Yes、クライアント48014803は差分通知要求の送信元であるクライアントのバージョンと自己のバージョンの差分を知らせる差分通知を、当該差分通知要求の送信元である他のクライアントに送信しS8030、処理を終了する。一方、最新保証を受けていないと判定した場合S8020、No、クライアント48014803は自己の問い合わせ先5025を参照し、問い合わせ先5025に記憶されたクライアントに対して、差分通知要求を送信するS8040。以上で、差分検索通知受信時処理の説明を終了する。[第7の実施の形態のまとめ]本実施の形態によれば、サーバレスなデータベースシステムを構築できるとともに、1クライアントに集中して問い合わせ差分検索要求が発生することのないように、処理の負荷を分散を図ることが可能なデータベースシステムを提供できる。[備考]上記第1から第7の実施の形態は、いずれか2以上の実施の形態を適宜選択し、それらを組み合わせても、本発明の実施の形態の範囲内であり、発明の一態様として成立する。"