JP2012141891A - データベース・システム、並びにそのクライアント - Google Patents

Abstract

【課題】サーバを用いず、負荷分散を図りながら、差分検索方式によるデータベースの検索、データベースの更新を可能とする。
【解決手段】クライアントは、記憶手段、最新保証通知手段、最新保証切れ通知手段、最新保証情報管理手段、差分通知要求手段、差分通知手段、判定手段を有する。最新保証通知手段は、更新権が自己が更新権を有していること示している場合、他のクライアントにデータベース内容が最新であることが保証された状態であることを通知する最新保証通知を送信する。判定手段は、差分通知要求を受信した場合、最新保証情報の内容がそのデータベースの内容が最新であることが保証された状態を示す情報であるとき差分通知を送信させ、最新保証情報の内容がそのデータベースの内容が最新であることが保証されない状態であることを示す情報であるとき差分通知要求を送信させる。
【選択図】図７４

Description

本明細書に記載の実施の形態は、データベース・システム、並びにそのクライアントに関する。

最近、家電機器等において、組込み機器製品が高機能化し、機器自体がサーバになることが求められている。一方、サーバを利用するクライアント機器は、サーバが有するデータベースと同期するデータベースを有し、サーバと協働してデータベースの検索、データベースの更新を行い、ユーザが常に最新の内容のデータベースを利用できるシステムが提案されている。

このような、サーバを利用するデータベースシステムにおいて、検索において、クライアントが所有する最新でないデータベースを活用して、少ないデータの送受信量で最新のデータを検索することができたり、データベースの更新において、クライアントが大量のデータを更新したいとき、更新したことだけを通知することで、少ないデータの送受信量で更新データをデータベースに反映する技術も提案されている。

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

従来のサーバを利用するシステムでは、サーバの集中管理が必要であり、サーバの負荷を究極的に減らすことが困難であるという問題があった。サーバの負荷を究極的に減らす方法としては、サーバを利用しないシステムとすることが考えられるが、そのようなシステムにおいては、ある１クライアントに集中して問い合わせが発生して負荷がそのクライアントに集中してしまうという問題が発生する。

本実施の形態は、固定のサーバとなる装置を用いず、１つのクライアントに負荷が集中することなく、差分検索方式によるデータベースの検索、データベースの更新が可能な技術を提供することを目的とする。

一の実施の形態によれば、サーバを用いなくとも使用可能なデータベースシステムのためのクライアントが提案される。

このクライアントは、記憶手段と、最新保証通知手段と、最新保証切れ通知手段と、最新保証情報管理手段と、差分通知要求手段と、差分通知手段と、判定手段とを有する。

記憶手段は、自己が最新のデータベースの内容を保有しているか否かを示す情報である更新権と、差分検索又はデータベースの同期の相手となる他のクライアントを特定する情報である問い合わせ先と、自己のデータベースの内容がデータベース・システム内で最新であるか否かを示す情報である最新保証情報を記憶する。
最新保証通知手段は、前記更新権が自己が更新権を有していること示している場合、自己のデータベースと同一のバージョンであるデータベースを有する他のクライアントに、そのデータベースの内容が最新であることが保証された状態であることを通知する最新保証通知を送信する。
最新保証切れ通知手段は、前記更新権の内容が自己が更新権を有していることを示す情報から自己が更新権を有していないこと示している情報に書き換えられた場合、前記最新保証通知を送信した他のクライアントに、そのデータベースの内容が最新であることが保証されない状態であること通知する最新保証切れ通知を送信する
最新保証情報管理手段は、前記最新保証通知を受信した場合前記最新保証情報の内容をそのデータベースの内容が最新であることが保証された状態を示す情報に書き換え、前記最新保証切れ通知を受信した場合前記最新保証情報の内容をそのデータベースの内容が最新であることが保証されない状態であることを示す情報に書き換える。
差分通知要求手段は、前記問い合わせ先に差分通知要求を送信する。
差分通知手段は、自己のデータベースと当該他のクライアントのデータベースの差分を通知する差分通知を生成し、差分通知を当該他のクライアントに送信する。
判定手段は、他のクライアントから差分通知要求を受信した場合、前記最新保証情報の内容がそのデータベースの内容が最新であることが保証された状態を示す情報であるときには前記差分通知手段に差分通知を当該他のクライアントに送信させ、前記最新保証情報の内容をそのデータベースの内容が最新であることが保証されない状態であることを示す情報であるときには、前記差分通知手段に前記問い合わせ先に宛てて差分通知要求を送信させる。

本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図 本発明の実施形態に係るクライアントサーバシステムの機能ブロック図 第１の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図 情報端末装置の情報管理装置に対する要求処理の流れを示すフローチャート 情報管理装置のユーザ情報端末装置の更新要求処理の流れを示すフローチャート データベースの構造(中身）を模式化した図 データ量の比較を模式化した図 データ量の比較を模式化した図 データ量の比較を模式化した図 データ量の比較を模式化した図 変更履歴の追加がなされた場合のデータベースの構造（中身）の変化を例示する図 変更発生時の変更履歴欄の更新処理の流れを示すフローチャート 同期処理におけるデータベースの構造（中身）の変化を例示する図 無効化処理におけるデータベースの構造（中身）の変化を例示する図 探索要求時におけるデータベースの構造（中身）の変化を例示する図 探索実行におけるデータベースの構造（中身）の変化を例示する図 情報管理装置側における差分把握処理の流れを示すフローチャート 情報端末装置側における差分除去処理の流れを示すフローチャート 情報端末装置側における差分検索処理の流れを示すフローチャート 情報管理装置における差分検索処理の流れを示すフローチャート 変更履歴を用いた差分データからの検索処理を説明する図 第２の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図 変更発生時の変更履歴欄の更新処理の流れを示すフローチャート 変更発生時の変更履歴欄の更新処理の流れを示すフローチャート 変更発生時の変更履歴欄の更新処理の流れを示すフローチャート 更新要求を受けつけた後の変更履歴処理全体の流れを示すフローチャート 第３の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図 変更発生時の変更履歴欄の更新処理の流れを示すフローチャート 変更履歴の上位概念によるまとめ処理の流れを示すフローチャート 第４の実施形態に係るクライアントサーバ型検索システムを説明する図 情報管理装置における差分検索処理の流れを示すフローチャート 第５の実施形態に係るクライアントサーバ型検索システムを説明する図 情報管理装置における差分検索処理の流れを示すフローチャート 送信データの決定処理の流れを示すフローチャート Ａ）は、ネットワーク環境が弱い状況下でのサーバ、クライアントＢを示した図、Ｂ）はネットワーク環境が強い状況下でのサーバ、クライアントＢを示した図 図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントクライアントＡがサーバに検索要求を行ったときの動作を示す図 クライアント同士が通信可能場合の同期実行前検索時のシステムの動作例を示す図 クライアント同士が通信可能場合の同期実行前検索時のシステムの別の動作例を示す図 クエリキャッシュを利用した場合の、図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントクライアントＡがサーバに検索要求を行ったときの動作を示す図 図３８の状態の後、さらに別のクライアントＣがクライアントＡと同じ検索要求をした場合の本検索システムの動作例を示す図 本システムの基本的な動作の概要を示した図 更新要求クライアントによる遠距離更新時のユーザ更新要求の処理例を示したフローチャート サーバによる遠距離更新時のユーザ更新要求受付の例を示したフローチャート 検索要求クライアントによる検索実行の例を示したフローチャート サーバによるユーザ参照要求受付の例を示したフローチャート ステップＳ４４０１のより具体的な処理内容を示したフローチャート サーバによる差分検索要求、更新要求クライアントによる差分検索応答の処理例を示したフローチャート 新要求クライアントによる更新要求、サーバによるユーザ更新要求受付処理例を示したフローチャート 第６の実施の形態のシステム構成例を示したブロック図 クライアントの機能ブロック図 命令制御部の一構成例を示す機能ブロック図 変更履歴の記憶内容の例を示すブロック図 １つのマスター・クライアントと、１つのノード・クライアントの間での責任の移転の例を示す図 あるデータａについての「責任」が移転する例を示す図 図５３の状態から責任が移転した後の状態を示す図 図５４の状態の後、つなぎかえが行われた状態を示す図 クライアント間でのデータベース更新前のある状態を示す図 図５６の後につなぎかえが行われた状態を示す図 条件判定式の計算例を説明するための図 条件判定式の計算例を説明するための別の図 サーバを用いることなく検索を行う場合の、本実施の形態に係るデータベース・システムの動作例を示すシーケンス図 差分通知と差分検索を同時に送信するようにした場合の、サーバを用いることなく検索を行う場合の本実施の形態に係るデータベースシステムの動作例を示したシーケンス図 本データベースシステムにおいて、あるノード・クライアントがデータの検索（差分検索）を行うときの動作例を示したフローチャート 問い合わせ先クライアントの差分通知要求に対する対応処理の一例を示したフローチャート 問い合わせ先クライアントのつなぎかえ要求に対する応答処理を示したフローチャート 更新要求を受信した問い合わせ先クライアントの動作例を示したフローチャート （Ａ）は最新保証前のマスター・クライアントと２つのノード・クライアントの関係を示す図、（Ｂ）は最新保証実行時のマスター・クライアントと２つのノード・クライアントの関係を示す図 最新保証処理を行わない場合の、データベース内の問い合わせ関係を示した図 最新保証処理を行う場合の、データベース内の問い合わせ関係を示した図 データベース更新時の最新保証処理について説明するための、データベースにおけるクライアントの状態を示す図 図６９の状態からクライアントが新たのマスター・クライアントとなり、つなぎかえにより問い合わせ先が変更されたデータベース・システムの構成を示す図 最新保証処理のコストと効果を説明するための状態遷移図 第７の実施の形態にかかるデータベース・システムの一例を示す図 第７の実施の形態にかかるデータベース・システムの別の例を示す図 第７の実施の形態における命令制御部の機能ブロック図 第７の実施の形態に係るデータベース・システムの動作例をシーケンス図 第７の実施の形態に係るデータベース・システムの動作例をシーケンス図 最新保証通知処理の一例のフローチャート 最新保証切れ通知処理の一例のフローチャート 最新保証切れ通知処理の一例のフローチャート 差分検索通知受信時処理の一例のフローチャート

[差分検索システム]
まず、本実施の形態の基本となる差分検索システムについて説明する。
図1は、本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図である。図１に示すように、クライアントサーバシステム１００は、サーバとなる情報管理装置２と、例えばインターネット網あるいは無線通信網３でクライアント機器となる情報端末装置１とから構成されている。情報管理装置（以下の説明では、サーバとも称する）２は、図１に示すように、データベース２４に接続されている。データベース２４は、都度、更新され、現在のバージョンと変更履歴が管理されている。情報管理装置２は、専用機器である必要はない。所謂、家電機器と称される機器であってもネットワーク網に繋がり、バージョンの管理ができてサーバ機能を果たすものであればよい。さらに変更履歴は、各バージョンとそのバージョンで対象となるデータのＩＤとで把握されるようになっている。これらの詳細については、後述する。

情報端末装置（以下の説明では、クライアントとも称する）１は、データベース機能を備えるものであれば、携帯電話や携帯プレーヤが好適である。所謂、ウルトラモバイルＰＣと称されるものである。図１に示すように、各情報端末装置１も、それぞれデータベース１４に接続されているが、データベース１４は、情報管理装置２のデータベース２４と同期したときのバージョンとなっている。

図２は、本発明の実施形態に係るクライアントサーバシステム１００の機能ブロック図である。情報管理装置２は、接続部２１とデータベース２４を備え、情報端末装置１の要求を受け、結果を送信する。接続部２１は、インターネット網を介して、情報端末装置１と通信をする。情報端末装置１は、ユーザインターフェース１０と接続部１１及びデータベース１４を備える。ユーザインターフェース１０は、ユーザの要求を受け、結果を表示するものである。接続部１１は、インターネット網を介して、情報管理装置２と通信をする。

さらに、情報管理装置２は、命令制御部２２とSQL実行部２３を有している。命令制御部２２は、情報端末装置１の要求に応じて、SQL実行部２３や接続部２１に命令を出し、結果をユーザインターフェース１０に表示する。命令としては、接続受付、差分通知、SQL受付、結果送信、同期送信、接続停止がある。SQL実行部２３は、データベース２４に対する命令であるSQL文を用いて、命令制御部２２からの要求にしたがってデータベース２４への操作や定義づけを行うものである。データベース２４は、情報端末装置１から操作によって追加・変更・削除されたデータ２４１と変更履歴２４３とバージョン２４２を保有する。さらに、情報端末装置１は、命令制御部１２とSQL実行部１３を有している。命令制御部１２は、ユーザインターフェース１０の要求に応じて、SQL実行部１３や接続部１１に命令を出し、結果をユーザインターフェース１０に表示する。命令としては、接続開始、差分除去、差分検索、結果取得、同期受信、接続終了がある。詳細は後述する。SQL実行部１３は、データベース１４に対する命令であるSQL文を用いて、命令制御部１２からの要求にしたがってデータベース１４への操作を行うものである。データベース１４は、情報管理装置２と同期して取得したデータ１４１とバージョン１４２を保有する。本実施形態で使用する用語は、特にことわりのない場合、以下の意味で理解する。「同期」とは、サーバとクライアント機器との間で、データベース内のデータを共有している状態、若しくは共有化するための処理を意味する。「差分把握」とは、クライアントとサーバのデータの差分を互いのバージョンから把握し、検索処理において重複したデータを検索しないようにすることである。「差分検索」とは、差分データ、すなわち同期がとれていないデータに対する検索をいい、サーバが実行するものである。因みに、差分があるかどうか検索するわけではない。「変更履歴」とは、データベース内のデータについて変更履歴で変更した差分を管理する。変更履歴は、「バージョン」と「データＩＤ」の組を持っている。「バージョン」とは、サーバ側で一意に発行する数字で、データベース内のデータについて変更が行われたらバージョンが１つあがる。本実施形態において「バージョン」は、「差分把握」及び「差分検索」を簡単にするための仕組みである。

以下、いくつかの実施形態に分けて説明する。
（第１の実施形態）
図３は、第１の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図である。クライアント機器である情報端末装置１はサーバである情報管理装置２において、データベースの更新が行われると、現在のバージョンに対して１つインクリメント（バージョンを＋１する）とされる。更新の内容は変更履歴として管理される。変更履歴は、バージョンと対象となるデータのＩＤから成り立っている。更新に併せて、差分把握可能範囲が設定される。この差分把握可能範囲は、言わば、差分検索が可能な範囲を意味する。極端に古いバージョンのデータベースしか保持していないクライアント機器をケアする場合に対応するためのものである。クライアント機器が自ら保有しているデータベースに対して検索を行う際に、既にサーバ側ではデータベースが更新された結果、削除あるいは変更済みのデータが未だ存在している可能性がある。これら削除あるいは変更済みのデータに対して検索を行うことは全く無意味である。そこで、クライアント機器が自ら保有しているデータベースに対して検索を行う前に、クライアント機器において、該当データの「無効化処理」を行う。「無効化処理」は、サーバで「差分把握」を行い、クライアント機器はサーバから該当するデータＩＤを受け取って「無効化処理」をする。「差分検索」では、情報管理装置と情報端末装置間で、それぞれのデータベースのデータに差分が存在するか否か問い合わせを行う。情報管理装置は「変更履歴」から差分データについて検索して、情報端末装置に検索結果を送信する。

図４は、上記のように構成された検索システムにおけるユーザである情報端末装置の情報管理装置に対する要求処理の流れを示すフローチャートである。まず、情報管理装置は情報端末装置からの接続処理を行う（ステップＳ４１）。情報管理装置は、処理がまだあるか否かを判断する（ステップＳ４２）。処理がなければ、情報端末装置との接続を解除する切断処理を実行する（ステップＳ４６）。処理があれば（ＹＥＳならば）、更新処理か否かを判断する（ステップＳ４３）。ＹＥＳならば、更新処理を実行する（ステップＳ４４）。ＮＯであれば、検索処理を実行する（ステップＳ４５）。更新処理あるいは検索処理の実行後は、ステップＳ４２に戻る。

図５は、情報管理装置のユーザである情報端末装置の更新要求処理の流れを示すフローチャートである。情報管理装置は情報端末装置からデータの更新要求を受付、更新処理を実行する（ステップＳ５１）。更新に伴い、情報管理装置は変更履歴を更新する（ステップＳ５２）。データの更新要求に対する結果が返却され（ステップＳ５３）、更新完了が情報管理装置から情報端末装置に返される。

図６は、データベースの構造(中身）を模式化した図である。図６に示すデータベースは、“Ｔａｂｌｅ”、“Ｐａｇｅ”、“ｎｏｄｅ”と階層化されている。例えば、図書館に収蔵されている“本”のデータベースを考えると、“Ｔａｂｌｅ”は“市立図書館”であり、“Ｐａｇｅ”は“本棚”であり、“ｎｏｄｅ”は個々の“本”に該当する。今、サーバのデータベースが更新され、バージョンは“３”となり、当該更新によって、“ｎｏｄｅ４”が“Ｐａｇｅ Ｂ”の本棚から、取り除かれた。クライアントのバージョンは“１”であり、サーバのバージョンとは一致していない。

このような状況のもとで、データの検索処理の流れについて説明する。まず、クライアント機器がサーバに対して、現在のバージョンの問い合わせを行う。バージョンの問い合わせを受けたサーバは変更履歴を確認し、変更したノードを探索する。すると、サーバはバージョン３となっており、“ｎｏｄｅ４”が変更されているので、クライアント機器に対して、差分把握として“ｎｏｄｅ４”が削除されているデータであることを知らせる。“Ｐａｇｅ Ｂ”との差分把握を受け取ったクライアント機器は、自らのデータベースから“ｎｏｄｅ４”に対して無効化する。クライアント機器は、無効処理後のデータベースについて全件探索を行う。一方、サーバでは、クライアント機器のバージョン１との差分データである“ｎｏｄｅ４”に対して全件探索、すなわち“ｎｏｄｅ４”に対して検索条件を満たすかどうかを判定する差分検索を行う。この差分検索の結果を受領したクライアント機器は、最新のデータベースに対する検索結果を得ることができる。

最新のデータについて検索を行うには、サーバ及びクライアント機器間で、必ず通信が必要である。差分把握、差分検索によれば、完全同期やサーバ全問い合わせに比べて格段に小さな通信量で、最新のデータに対する検索が実現できる。一般的に、完全同期データ量≧差分検索結果データ量であり、且つ、全件検索結果データ量≧差分検索結果データ量であることによる。これら、データ量の比較を模式化したものを図７乃至図１０に示す。図７は、サーバとクライアント機器が近距離に位置し、しかも両者間の通信環境が高速通信を行う状況であることを例示している。この場合には、両者のデータベースの更新は、完全同期させるのが好適である。なお、差分同期であっても支障はないといる。図８は、クライアント機器では検索せずにサーバに検索を委ねる、全問い合わせの状況であることを例示している。この場合には、サーバは１Ｇバイトのデータ容量のデータベースに対して検索を実行し、１Ｍバイトの検索結果を得ている。したが、ヒット率：ｈ＝０．１％となる。ここでは、検索結果がそのまま、クライアント機器に送られるが、通信容量はさほど大きくないので、低速通信であっても支障はないといる。図９は、サーバとクライアント機器との間で、差分データについて同期をとることを例示している。サーバのデータベースが更新された結果、更新前後の差分データが１Ｍバイトである状況を例示している。１Ｍバイトの差分データの更新前のデータベースに対する差分割合は０．１％となる。１Ｍバイトの差分データは、通信容量としてはさほど大きくないので、低速通信であっても支障はないといる。クライアント機器は、受け取った１Ｍバイトの差分データを加えた１Ｇバイトのデータベースに対して検索を実行し、１Ｍバイトの検索結果を得ている。次に、図１０は、差分検索を例示している。サーバからクライアント機器に対して差分ＩＤ群として１００バイトが送られる。この差分ＩＤ群とは、無効化処理すべきデータのＩＤのまとまりを意味している。さらに、サーバは、変更履歴に基づいて差分データ１Ｍバイトを抽出し、クライアント機器のために差分検索を実行する。得られた１Ｋバイト差分検索の結果は、クライアント機器に送られる。一方、クライアント機器は、差分ＩＤ群に基づいて自己のデータベースを更新して、検索を実行する。クライアント機器は、差分検索の結果１Ｋバイトと併せて、１Ｍバイトの検索結果を得ている。例えば、１つのデータ長が４０００ビット、データＩＤ長が４ビットとすると、あるＩＤを特定するためには、１／１０００の情報量で済むことになる。したが、差分ＩＤ群及び差分検索結果のデータ容量は、極めて少ない量となるから、低速通信であっても何等支障はなく、特に１つのデータが大きく、差分割合が少ないときに好適である。

次に、上記した処理に伴い、データベースの構造（中身）がどのように変化していくか、図を用いて例示する。図１１は、変更履歴の追加がなされた場合のデータベースの構造（中身）の変化を例示する。クライアント機器がデータベースを保有しており、同期させる場合の処理である。今、サーバのデータベースに対して、”Ｐａｇｅ Ｂ“に“ｎｏｄｅ４”を追加する変更が行われた。係る変更に伴い、変更履歴欄には、最新のバージョンは“３”から”Ｖｅｒ＝４”に、その変更内容として、“ｎｏｄｅ４”が更新されている。図１２は、変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。図１２に示すように、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている。そして、バージョンを＋１している。 図１３は、同期処理におけるデータベースの構造（中身）の変化を例示する。サーバのバージョンは“４”であるのに対し、クライアント機器のバージョンは“３”である。そこで、変更履歴から更新後の“ｎｏｄｅ４”のデータが、サーバのバージョン情報と共に、クライアント機器に送られる。クライアント機器では、“ｎｏｄｅ４”の内容を更新する。

図１４は、無効化処理におけるデータベースの構造（中身）の変化を例示する。クライアント機器のバージョンは“３”である。サーバは、変更履歴から自身の現在のバージョン“４”と、その変更内容である“ｎｏｄｅ４”の削除を確認する。サーバのバージョン情報及び差分ＩＤ群情報は、クライアント機器に送られる。クライアント機器では、保有するデータベースに対してバージョン“４”の内容を反映させるために、バージョン“３”との差分である“ｎｏｄｅ４”を削除する。

図１５は、探索要求時におけるデータベースの構造（中身）の変化を例示する。サーバのデータベースに対するＳＥＬＥＣＴは、ＳＥＬＥＣＴ文 ＷＨＥＲＥ Ｖｅｒ＞３ ＡＮＤ Ｖｅｒ≦４となる。バージョン“３”でのデータベースに対する探索（検索）は、クライアント機器自身に割り当て、バージョン“４”を反映した探索（検索）は、サーバに割り当てられる。

図１６は、探索実行におけるデータベースの構造（中身）の変化を例示する。図１６に示すように、サーバのデータベースに対して、ＳＥＬＥＣＴ文 ＷＨＥＲＥ Ｖｅｒ＞３ ＡＮＤ Ｖｅｒ≦４で表される命令が発せられると、バージョン“４”の変更内容である“ｎｏｄｅ４”に対して検索を実行し、検索結果Ｓをクライアント機器に送る。一方、クライアント機器は、ＳＥＬＥＣＴ文によりバージョン“３”でのデータベースに対する検索を実行し、検索結果Ｃを得る。したが、検索結果Ｃ＋検索結果Ｓが、最新のデータに対する検索結果として得ることができる。

次に、検索システムにおける情報管理装置と情報端末装置で実行される各処理の流れについて詳述する。

図１７は、情報管理装置側における差分把握処理の流れを示すフローチャートである。 まず、情報端末装置のバージョン：Ｖｃを取得する（ステップＳ１７０１)。次いで、情報管理装置のバージョン：Ｖｓを取得する（ステップＳ１７０２)。次いで、両者のバージョンを比較する（ステップＳ１７０３)。Ｖｃ＝Ｖｓであれば、Ｖｓと結果：Ｒ＝「変更データ無し」を情報端末装置に通知する（ステップＳ１７０５)。Ｖｃ＝Ｖｓでなければ、変更履歴から差分把握可能範囲：Ｖａを取得する（ステップＳ１７０４)。次いで、Ｖａ＞Ｖｃかどうかを判断する（ステップＳ１７０６)。Ｖａ＞Ｖｃであれば、結果：Ｒ＝「差分検索不可」を情報端末装置に通知する（ステップＳ１７１１)。Ｖａ＞Ｖｃでなければ、データベースから変更履歴を使い、差分ＩＤsを作成する（ステップＳ１７０７)。次いで、変更が削除のみかどうかを判断する（ステップＳ１７０８)。変更が削除のみでなければ、Ｖｓと差分ＩＤ：ＩＤsを情報端末装置に通知する（ステップＳ１７０９)。変更が削除のみであれば、結果：Ｒ＝「差分削除のみ」Ｖｓと差分ＩＤ：ＩＤｓを情報端末装置に通知する（ステップＳ１７１０)。

図１８は、情報端末装置側における差分除去処理の流れを示すフローチャートである。まず、情報管理装置の差分ＩＤの結果：Ｒを取得する（ステップＳ１８０１)。次いで、Ｒ＝「差分削除のみ」かどうかを判断する（ステップＳ１８０２)。Ｒ＝「差分削除のみ」であれば、差分ＩＤｓを取得する（ステップＳ１８０３)。続いて、ＩＤｓに対応するデータをデータベースから削除する（ステップＳ１８０４)。続いて、サーバフラグ＝ＯＦＦと設定する（ステップＳ１８０５)。このサーバフラグは、サーバに検索要求をする必要があるか否かを示すもので、サーバに検索要求をする場合、ＯＮとなる。続いて、Ｖｃ＝Ｖｓとする（ステップＳ１８０６)。そして、差分把握完了フラグ＝ＯＮとする（ステップＳ１８０７)。一方、Ｒ＝「差分削除のみ」でない場合には、まず、Ｒ＝「差分検索不可」かどうかを判断する（ステップＳ１８０８)。Ｒ＝「差分検索不可」でなければ、続いて、Ｒ＝「変更データ無し」かどうかを判断する（ステップＳ１８０９)。Ｒ＝「変更データ無し」でなければ、差分ＩＤｓを取得する（ステップＳ１８１０)。続いて、ＩＤsに対応するデータをデータベースから削除する（ステップＳ１８１１)。 続いて、サーバフラグ＝ＯＮと設定（ステップＳ１８１２)した後、ステップＳ１８０７に移る。一方、Ｒ＝「差分検索不可」の場合には、サーバフラグ＝ＯＮと設定（ステップＳ１８１３)。続いて、Ｖｃ＝０と設定（ステップＳ１８１４)した後、ステップＳ１８０７に移る。また、Ｒ＝「変更データ無し」の場合には、サーバフラグ＝ＯＦＦと設定する（ステップＳ１８１５)。続いて、Ｖｃ＝Ｖｓと設定（ステップＳ１８１６)した後、ステップＳ１８０７に移る。

図１９は、情報端末装置側における差分検索処理の流れを示すフローチャートである。 まず、差分把握完了フラグ＝ＯＮかどうか判断する（ステップＳ１９０１)。差分把握完了フラグ＝ＯＮでなければ、接続処理（情報管理装置にＶｃを渡す）を行う（ステップＳ１９０２)。続いて、差分ＩＤの送受信を行い（ステップＳ１９０３)、差分ＩＤの除去を実行する（ステップＳ１９０４)。一方、差分把握完了フラグ＝ＯＮであれば、Ｖｃ≠０かどうか判断する（ステップＳ１９０５)。Ｖｃ≠０であれば、情報端末装置のデータベースから検索を実行する（ステップＳ１９０６)。次いで、サーバフラグ＝ＯＮかどうか判断する（ステップＳ１９０７)。一方、Ｖｃ≠０でなければ、直ちにステップＳ１９０７のサーバフラグ＝ＯＮかどうかの判断に移る。サーバフラグ＝ＯＮであれば、情報管理装置から検索を行う（ステップＳ１９０８)。そして、検索結果を表示する（ステップＳ１９０９)。 図２０は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でＶｃとＶｓを用いてＳＱＬ文を作成し（ステップＳ２００１)、ＳＱＬ文を情報管理装置側へ送信する（ステップＳ２００２)。情報管理装置側では、ＳＱＬ文を受信する（ステップＳ２００３)と、変更履歴を用いて差分データから検索を実行する（ステップＳ２００４)。情報管理装置は、検索結果を送信し（ステップＳ２００５)、情報端末装置は検索結果を取得する（ステップＳ２００６)。図２１は、上記したステップＳ２００４の変更履歴を用いた差分データからの検索処理を説明する図である。情報管理装置は、ＳＥＬＥＣＴ ＷＨＥＲＥ ２＜Ｖｅｒ ＡＮＤ Ｖｅｒ≦４とのＳＱＬ文を受信すると（ステップＳ２１０１)、ＳＥＬＥＣＴ文を実行する（ステップＳ２１０２)。図２１に示す例では、変更履歴から、バージョン３ではｎｏｄｅ２に変更を加え、バージョン４ではｎｏｄｅ４に変更が加えられている。よって、情報管理装置が実行すべき差分検索は、ｎｏｄｅ２、ｎｏｄｅ４のみを検索対象とすることがわかる。したが、検索に要する時間も極めて短時間である。このように、本実施形態によれば、差分処理なので検索対象が少なくて済み、差分検索結果のデータサイズは差分データサイズよりもはるかに小さいのでサーバの処理量が著しく減少させることができ、多くのクライアント機器をケアすることができる。さらに、バージョン管理により、効率よく最新データの把握ができる。

クライアント側では検索のためのこと前処理として無効化処理するので、効率的な検索が可能となる。また、サーバの処理量が少ないので、高性能でない機器でもデータベースサーバとして使用することができるので、低廉な検索システムを構築することができる。

（第２の実施形態）
図２２は、第２の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図である。第２の実施形態では、言わば、変更履歴を管理するために必要となるメモリの削減をその狙いとするものである。そのため、（１）変更履歴欄がいっぱいであれば、古いものを削除する、（２）変更履歴欄に同じデータＩＤが存在していたら、最新のものにまとめる、（３）変更履歴で把握できる範囲外のバージョンならば、あえて差分検索しない等を骨子としている。図２３は、変更発生時の変更履歴欄の更新処理であって、削除のみの変更の場合の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２３０１)。次いで、変更内容が削除以外にないかどうか判定する（ステップＳ２３０２)。ＹＥＳであれば、ＤＥＬＥＴＥ ＯＮＬＹフラグをＯＮにする（ステップＳ２３０３)。ここでは、ｎｏｄｅ４を削除するのみの変更が、バージョン“３”として、行われ、ＤＥＬＥＴＥ ＯＮＬＹフラグをＯＮにしている。次いで、バージョンを＋１している（ステップＳ２３０４)。図２４は、変更発生時の変更履歴欄の更新処理であって、データを節約する場合の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２４０１)。次いで、変更履歴に同じデータＩＤが存在するかどうか判定する（ステップＳ２４０２)。ＹＥＳであれば、変更履歴の古いものを削除する（ステップＳ２４０３)。ここでは、ｎｏｄｅ４を対象とする変更が過去においてバージョン“２”でなされているので、バージョン“２”の履歴を削除し、ｎｏｄｅ４を対象とする変更履歴をバージョン“４”のものにまとめている。次いで、バージョンを＋１している（ステップＳ２４０４)。図２５は、変更発生時の変更履歴欄の更新処理であって、古い差分情報は削除する場合の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２５０１)。次いで、変更履歴がいっぱいかどうか判定する（ステップＳ２５０２)。ＹＥＳであれば、古い差分情報を削除する（ステップＳ２５０３)。ここでは、ｎｏｄｅ１２を対象とするバージョン“１”の変更履歴を消すことになる。バージョン“１”の変更履歴が消されると、変更履歴の最も古いバージョン：Ｖｏを差分把握可能範囲：Ｖａ に代入する（ステップＳ２５０４)。ここでは、最も古いバージョンが“２”となり、差分把握可能範囲もバージョン“２”となっている。次いで、バージョンを＋１している（ステップＳ２５０５)。

図２６は、ユーザから更新要求を受けつけた後の変更履歴処理全体の流れを示すフローチャートである。
まず、更新要求の受付後、更新処理を実行する（ステップＳ２６０１)。次いで、変更したノードを変更履歴に追加する（ステップＳ２６０２)。次いで、サーバのバージョンを＋１し、Ｖｓ＝Ｖｓ＋１と設定する（ステップＳ２６０３)。続いて、変更内容は削除以外にないかを判断する（ステップＳ２６０４)。削除のみならば、ＤＥＬＥＴＥ ＯＮＬＹフラグをＯＮにする（ステップＳ２６０５)。フラグ設定後、変更履歴に同じＩＤがあるかを判断する（ステップＳ２６０６)。変更内容が削除以外にもある場合もステップＳ２６０６に移る。変更履歴に同じＩＤがあれば、変更履歴の古いものを削除する（ステップＳ２６０７)。削除後、変更履歴がいっぱいかどうかを判断する（ステップＳ２６０８)。変更履歴に同じＩＤがない場合もステップＳ２６０８に移る。変更履歴がいっぱいであれば、古い差分情報を削除し（ステップＳ２６０９)、変更履歴の最も古いバージョンを差分可能範囲に代入する（ステップＳ２６１０)。次いで、変更履歴を上位概念でまとめ（ステップＳ２６１１)、結果を返却する（ステップＳ２６１２)。変更履歴がいっぱいでない場合には、ステップＳ２６１１以降に移る。第２の実施形態によれば、第１の実施形態での効果に加えて、変更履歴の管理をより効率的に行うことができる。
（第３の実施形態）

図２７は、第３の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新及びバージョンを説明するための模式図である。第３の実施形態では、バージョンアップに伴う処理をより効率的に行うことに狙いがある。そのため、変更履歴の管理をより上位の概念で行う、例えば、図６のＴａｂｌｅ単位あるいはＰａｇｅ単位でまとめるものである。

図２８は、変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２８０１)。次いで、同じＰａｇｅに所属するものが一定値以上かどうか判定する（ステップＳ２８０２)。一定値以上であれば、同じＰａｇｅのＩＤを削除し（ステップＳ２８０３)、Ｐａｇｅ ＩＤを追加する（ステップＳ２８０４)。ここでは、ｎｏｄｅ１２とｎｏｄｅ１３を対象とする変更履歴が、Ｐａｇｅ Ａを変更対象とするバージョン“４”として上位概念化している。次いで、バージョンを＋１している（ステップＳ２８０５)。

図２９は、変更履歴の上位概念によるまとめ処理の流れを示すフローチャートである。 まず、同じページのＩＤをカウントする（ステップＳ２９０１)。Ｐａｇｅでまとめられるかどうかを判断する（ステップＳ２９０２)。Ｐａｇｅでまとめられる場合には、同じページのＩＤを変更履歴から削除する（ステップＳ２９０３)。次いで、同じテーブルのＩＤをカウントする（ステップＳ２９０４)。Ｐａｇｅでまとめられない場合には、直ちにステップＳ２９０４に移る。次いで、Ｔａｂｌｅでまとめられるかどうかを判断する（ステップＳ２９０５)。Ｔａｂｌｅでまとめられる場合には、同じテーブルのＩＤを変更履歴から削除し（ステップＳ２９０６)、上位概念でのまとめを終了する。Ｔａｂｌｅでまとめられない場合にも、上位概念でのまとめを終了する。

なお、情報端末装置におけるバージョンアップを簡単にするための工夫として、差分把握に関してデータＩＤを受け取って、ＤＥＬＥＴＥ ＯＮＬＹのフラグをチェックし、フラグがたっているならば、差分データを受け取ったのと同じなのでバージョンアップし、あるいは、差分データを受け取ったら、反映し、バージョンアップするようにすることもできる。第３の実施形態によれば、バージョンアップに伴う処理をより効率的に行うことができる。

（第４の実施形態）
図３０は、第４の実施形態に係る検索システムを説明する図である。第４の実施形態では、情報管理装置での検索結果の通信量のさらに低減を図るもので、差分検索に関して、検索結果と差分データから同期判断し、同期した方がよいと判断した場合には、同期データを送信し、係る同期判断は段階的に行ってもよい、等を骨子としている。ここでは、図３０に示すように、差分データＤｓと、差分検索結果Ｒｓのデータサイズを比較する。図３１は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でＶｃとＶｓを用いてＳＱＬ文を作成し（ステップＳ３１０１)、ＳＱＬ文を情報管理装置側へ送信する（ステップＳ３１０２)。情報管理装置側では、SQL文を受信する（ステップＳ３１０３)と、変更履歴を用いて差分データから検索を実行する（ステップＳ３１０４)。次いで、差分データサイズ：Ｓｄを取得する（ステップＳ３１０５）。続いて、検索結果データサイズ：Ｓｒを取得する（ステップＳ３１０６）。そして、差分データサイズ：Ｓｄと積分の差分検索データサイズ：ΣＳｒについて、Ｓｄ＞ΣＳｒかどうかを判断する（ステップＳ３１０６）。情報管理装置は、Ｓｄ＞ΣＳｒでなければ、検索結果の代わりに差分データを送信し（ステップＳ３１０８)、Ｓｄ＞ΣＳｒであれば検索結果を送信する（ステップＳ３１０９)。情報端末装置はデータを取得し（ステップＳ３１１０)、データが差分データかどうかを判断する（ステップＳ３１１１）。差分データであれば、差分データをデータベースにアップデートする（ステップＳ３１１２）。Ｖｃ＝Ｖｓとし（ステップＳ３１１３）、サーバフラグ＝ＯＦＦと設定する（ステップＳ３１１４）。

繰り返しの検索によって、検索結果データが差分データよりも大きくなってしまう可能性がある。そのような場合には、（積算の差分検索結果データサイズ）≦（差分データサイズ）となり、積算の差分検索結果データサイズを送信した方が結果的にデータ量は少ないので、検索結果を送信した方が得である。一方、（積算の差分検索結果データサイズ）＞（差分データサイズ）ならば、差分データを送り、以降の通信量は無しとすることにより、本実施形態によれば、繰り返しによる通信量を低減することができる。なお、上述では、積算の検索結果データと差分データの大小関係による判定について説明したが、これに限られない。例えば、差分データの８０％で比較する、あるいは検索要求を予測するようにしてもよい。

（第５の実施形態）
第５の実施形態では、情報管理装置での検索結果の通信量のさらに低減を図るものである。図３２は、第５の実施形態に係る検索システムを説明する図である。ここでは、図３２に示すように、バージョンごとのデータで、差分データＤｓと、差分検索結果Ｒｓのトータルサイズを比較する。

図３３は、情報管理装置における差分検索処理の流れを示すフローチャートである。
まず、情報管理装置への検索要求は、情報端末装置側でＶｃとＶｓを用いてＳＱＬ文を作成し（ステップＳ３３０１)、ＳＱＬ文を情報管理装置側へ送信する（ステップＳ３３０２)。情報管理装置側では、ＳＱＬ文を受信する（ステップＳ３３０３)と、Ｎ＝Ｎ＋１とカウントアップ（ステップＳ３３０４)した後、変更履歴を用いて差分データから検索を実行し、データを作成する（ステップＳ３３０５)。情報管理装置は、情報端末装置に送信データ：S の送信を行う（ステップＳ３３０６)。情報端末装置はデータを取得し（ステップＳ３３０７)、データに差分データがあるかどうかを判断する（ステップＳ３３０８）。差分データがあれば、差分データをデータベースにアップデートする（ステップＳ３３０９）。Ｖｃ＝Vdと設定し（ステップＳ３３１０）、Ｖｃ＝Ｖｓかどうかを判断する（ステップＳ３３１１）。Ｖｃ＝Ｖｓであれば、サーバフラグ＝ＯＦＦとする（ステップＳ３３１２）。一方、データに差分データがない場合には、ステップＳ３３１２に移る。Ｖｃ＝Ｖｓでない場合には終了する。

次に、検索結果と同期データの比較による送信データの決定について説明する。図３４は、送信データの決定処理の流れを示すフローチャートである。まず、ｉ＝Ｖｃ＋１とする（ステップＳ３４０１）。次いで、Ｖｓ＝ｉかどうかを判断する（ステップＳ３４０２）。Ｖｓ＝ｉでなければ、ｉ＝ｉ＋1とし（ステップＳ３４０３）、バージョンｉの差分データ量：Ｄｄとしたとき、Ｓｄ＝Ｓｄ＋Ｄｄとする（ステップＳ３４０４）。次いで、ｉの差分データが検索にヒットしたかどうかを判断する（ステップＳ３４０５）。ヒットした場合には、ｉの差分検索結果データ量：Ｒｄを求めた（ステップＳ３４０６）後、積算検索結果データ量Ｓｒに足し上げ、Ｓｒ＝Ｓｒ＋Ｒｄとする（ステップＳ３４０７）。続いて、Ｓｄ＞Ｓｒかどうかを判断する（ステップＳ３４０８）。ステップＳ３４０５において、ｉの差分データが検索にヒットしなければ、ステップＳ３４０８に移る。Ｓｄ＞Ｓｒでなければ、どのバージョンまで差分を送るか確保し、Ｖｄ＝ｉとする（ステップＳ３４０９）。その後、ステップＳ３４０２に戻る。Ｓｄ＞Ｓｒであれば、直ちに、ステップＳ３４０２に戻る。

一方、Ｖｓ＝ｉであれば、Ｖｄまでのバージョンの差分データを送信データ：Ｓにコピーする（ステップＳ３４１０）。続いて、Ｖｄ以降の検索結果を送信データ：Ｓに追記コピーする（ステップＳ３４１１）。

第５の実施形態によれば、部分的なバージョンアップをするので、差分検索処理量が減り、差分データ量を減少させることができる。また、以降の通信量も減少させることができる。上述では、差分データと差分検索結果のトータルサイズの大小関係による判定について説明したが、これに限られない。例えば、差分データの８０％で比較する、あるいは検索要求を予測するようにしてもよい。

[本差分検索システムのデータ更新]
次に、上記の差分検索を行うことが可能な差分検索システムでのデータ更新方法について説明する。

対サーバ間でのネットワーク環境が弱い状況下では、クライアントは、サーバに更新したデータの一部、例えばデータＩＤのみ送信し、更新したデータ全体の送信は行わずにおき、後刻そのクライアントが対サーバ間でのネットワーク環境が強い状況下にきたときに、サーバのデータベースと、クライアントのデータベース間の完全同期を行うよう更新したデータの送受信を実行する。

図３５（Ａ）は、ネットワーク環境が弱い状況下でのサーバ、クライアントＢを示し、図３５（Ｂ）は、ネットワーク環境が強い状況下でのサーバ、クライアントＢを示している。

ネットワーク環境が弱い状況下(本実施の形態の第１のネットワーク環境下に相当する)は、例えば移動体通信網のみ利用可能な通信環境であって、通信はできるがネットワーク環境が強い場合に比して通信速度が低速な環境である。一方、ネットワーク環境が強い状況下(本実施の形態の第２のネットワーク環境下に相当する)は、例えば第１の通信環境下に比して通信速度が高速な通信環境であって、例えば有線ＬＡＮ,トランスファージェットによるネットワーク利用可能時である。

なお、ネットワーク環境が弱い状況下であるか、ネットワーク環境が強い状況下にあるかは、どのような手段によってクライアントが判断するようにしてもよく、例えば通信状況(回線の混雑具合含む)、有線接続であるか否か、ＧＰＳによる位置情報、ユーザの手動による切り替え操作によりどちらのネットワーク環境下にあるかを判断するようにしてもよい。

図３５（Ａ）の状態で、クライアントにユーザが新たなデータを追加入力し、クライアントのデータベースが更新されたものとする。このときクライアントは更新したデータの一部（例えば、更新したデータのデータＩＤのみ）をサーバに送信する。この弱いネットワーク環境下では送信可能な通信量が少なく、コストも係るためである。このとき、サーバはクライアントＢによって更新されたことを記憶しておく。後刻、図３５（Ｂ）のように、クライアントがサーバと強いネットワーク環境下になったとき、サーバとクライアントは互いのデータベースの記憶内容を同期させる。強いネットワーク環境下では送信可能な通信量も十分であり、通信コストも低いためである。

図３６は、図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントであるクライアントＡがサーバに検索要求を行ったときの動作を示す。まず、クライアントＡは、サーバにある内容の検索要求を行う。サーバは自己のデータベースについて依頼された検索を実行するとともに、先に更新通知をしてきたクライアントＢに、クライアントＢが記憶している更新分のデータについて検索するよう差分検索要求を行う。クライアントＢはその差分検索要求に応じて、自己のデータベースを検索し、検索結果をサーバに戻す。サーバはクライアントＢからの検索結果と自己のデータベースの検索結果を合わせて、クライアントＡに検索結果を返す。これで、同期前であってもシステム内の検索が完了できる。

クライアント同士が通信可能である環境であれば、図３６の例のようにサーバを介すことなく、クライアントとサーバのデータベース同期実行前であっても、システム内の検索を行うことが可能である。図３７Ａは、クライアント同士が通信可能である場合の同期実行前検索時のシステムの動作例を示す。まず、クライアントＡは、ある内容の検索要求をサーバに行う(図中丸数字１）。サーバは先に更新通知をしてきたクライアントＢに差分検索を要求するよう、クライアントＡに通知する（図中丸数字２）。クライアントＡはサーバからの通知に基づいて、クライアントＢに差分検索要求を送信する（図中丸数字３）。クライアントＢはその差分検索要求に応じて、自己のデータベースを検索し、検索結果をクライアントＢに戻す（図中丸数字４）。これで、同期前であってもシステム内の検索が完了できる。
また、本実施の形態は、図３６の例、図３７Ａの例を組み合わせた構成を採用することも可能である。

図３７Ｂに図３６の例、図３７Ａの例を組み合わせた構成を採用した場合の差分検索システムの動作例を示す。図３７Ｂの例も、クライアント同士が通信可能である場合の同期実行前検索時のシステムの動作例である。

まず、クライアントＡは、ある内容の検索要求をサーバに行う(図中丸数字１）。サーバは、現在持っているデータ内での最新の差分結果をクライアントＡに送信し、且つ最新データを持っているクライアントＢに差分検索を要求するよう、クライアントＡに通知する（図中丸数字２）。このとき、サーバからクライアントＡにどのバージョンでの最新結果かも提示される。クライアントＡはサーバからの通知に基づいて、クライアントＢに差分検索要求を送信する（図中丸数字３）。ここで、クライアントＡはサーバ〜通知されたバージョンでクライアントＢに問い合わせを行う。クライアントＢはその差分検索要求に応じて、自己のデータベースを検索し、検索結果をクライアントＢに戻す（図中丸数字４）。

上記図３７Ｂの例をより具体的に説明する。今、クライアントＡの保有するデータのバージョンは３、サーバの保有するデータのバージョンは４、クライアントＢの保有するデータのバージョンは５とする。なお、データのバージョンの数字が大きくなるほど、データは最新の内容である。

図中丸数字１の動作において、クライアントＡはサーバに問い合わせる際、「クライアントＡの保有するデータのバージョンは３」を示す情報を渡す。この情報を受け取ったサーバは、丸数字２の動作において、「最新データを保有するのはクライアントＢ」、「バージョン４とバージョン３の差分検索結果」、「サーバの保有するデータのバージョンは４」のそれぞれに相当する情報をクライアントＡに渡す。

丸数字３の動作において、クライアントＡはクライアントＢに「クライアントＡの保有するデータのバージョンは４」に相当する情報を渡す。丸数字４の動作においてクライアントＢは「バージョン５とバージョン４の差分検索結果」をクライアントＡに返す。

また、本実施の形態ではクエリキャッシュを利用することにより通信量が少なくデータを更新することもできる。図３８は、クエリキャッシュを利用した場合の、図３５に示したクライアントＢがサーバに更新通知を行った後、別のクライアントであるクライアントＡがサーバに検索要求を行ったときの動作を示す。まず、クライアントＡは、サーバにある内容の検索要求を行う。サーバは自己のデータベースについて依頼された検索を実行するとともに、先に更新通知をしてきたクライアントＢに、クライアントＢが記憶している更新分のデータについて検索するよう差分検索要求を行う。クライアントＢはその差分検索要求に応じて、自己のデータベースを検索し、検索結果をサーバに戻す。サーバはクライアントＢからの検索結果と自己のデータベースの検索結果を合わせて、クライアントＡに検索結果を返す。さらにサーバは、検索結果をクエリキャッシュとして保存しておく。図３９は、図３８の状態の後、さらに別のクライアントＣがクライアントＡと同じ検索要求をした場合の本検索システムの動作例を示す。クライアントＣは同じ検索要求をサーバに送信する。サーバはクエリキャッシュを参照して同じ検索要求である場合は、クライアントＢに問い合わせを行うことなく、クライアントＣにクエリキャッシュを検索結果として送信する。これによりクライアントＢ、サーバ間の通信を省略することができ、結果として通信量を抑えておくことが可能となる。

先にあるクライアントが更新をサーバに通知したのち、更新が通知されたデータは別のクライアントによって更新されないようロック（更新禁止処理）される。あるデータがロックされている状態で、別のクライアントにおいて更新する必要が生ずることもある。その場合には、本実施の形態は複数の対応方法を取りうる。
１．後発のロックはあきらめる。
２．先にロックを係たクライアントによるロックを解除して、後発のクライアントによるロックを行う。後発のクライアントは先にロックを係たクライアントに問い合わせて、内容を確認し、上記１．又は２．のいずれかを選択する。

[稼働率]
本実施の形態では、クライアントが更新データをサーバに送信するか否かを判定するための情報の一つとして、「稼働率」を利用する。稼働率は以下の式で算出される。

上記式で、「ＭＴＢＦ」は、完全同期から更新が発生するまでの時間である。MTBF = システムの稼動時間 / 故障回数という計算式で算出でき、これはMTBF =システムの稼動時間 / 更新回数 （＝1/更新率）に等しい。

また、「ＭＴＴＲ」は、更新から完全同期するまでの時間である。同期自体に係る時間は一瞬だが、同期を実行できるようになるまで時間が係る。これを「ＭＴＴＲ」として考慮に入れる。

稼働率の計算例を説明する。例えば、更新が5日に1回されるとして、MTBF=システムの稼動時間／更新回数＝5/1＝５となる。また、同期されるまでは半日係るとすると、MTTR＝1/2（日）よってこの例の場合の稼働率は

この稼働率を「p」とする。稼働率「ｐ」であるシステムでは、確率「p」で差分検索が実行できる。逆に、確率 (1 - p)のとき、サーバだけでは差分検索できない。よって、このサーバだけでは差分検索できない確率 (1 - p)のとき、更新者に問い合わせをする方法を採る。

更新したデータをサーバに反映するためのデータ量をＤとし、ある期間での検索発生回数をｎ、差分検索のためのデータ量をＲ、更新者への問い合わせをした差分検索量を２Ｒとすると、更新データを送付した場合の送信データ量はＤ＋ｎ・Ｒであり、更新データを送付しない場合の送信データ量は、ｎ・（Ｒ・ｐ＋２Ｒ・（１−ｐ））で表すことができる。
前回と同様、更新データは同期のためのデータであり、（更新データを送付しない場合の送信データ量）≦更新データを送付した場合の送信データ量が成立するとき、本実施の形態の方式は効率的となる。よって

が成立するとき、本実施の形態による方式は効率的で得あると判定できる。
また、上記式は

と変形できる。一般に更新データは、差分検索結果データに比べ数倍大きい。この式により、検索要求頻度と更新頻度がデータ量の比より小さければ、効率できであるといる
この判定式を使った予測によってデータを送信すべきかどうか決定できる。とりわけ最初の判断と、検索要求が多く来たときに利用可能である。

更新時にＤが決まり、Rとpとnが履歴から予測できれば更新時に上記式に基づいて効果的かどうかが判定できる。効果がないと判定された場合には、更新データをサーバに反映させるよう送信すればよい。

また、更新データに対して検索回数が増えるとｎが増加する。Dは更新時に決まっており、Rとpが予測から求められ、増加したｎによって上記式の不等号が成り立たなくなったら、更新データをサーバに反映するようにすればよい。

上記判定の具体例を挙げる。２４時間中、１時間だけ更新が反映されない状況が生ずるとする。例えば、通勤移動時間が朝と夜で１時間係るとする。この場合稼働率ｐは上記稼働率の計算式より

ｐ＝２３／（２３＋１）＝０．９５８
さらに、更新データ量Ｄは、差分検索のためのデータ量Ｒの１０倍（Ｄ＝１０Ｒ）とすると、前記不等式を変形してｎ≦Ｄ／（Ｒ×（１−ｐ））＝１０／０．０４＝２５０となり、結局２５０回／日の検索要求が一定間隔できても、結果効果的であることがわかる。

[本システムの基本的な動作]
以下、本システムの基本的な動作例について説明する。
図４０は、本システムの基本的な動作の概要を示した図である。この例では、サーバと、データ更新を行うクライアント（以下、区別のため更新要求クライアントと呼ぶ）と、検索を行うクライアント（以下、区別のため検索要求クライアントと呼ぶ）とでシステムが構成されているものとする。

更新要求クライアント（より詳しくは命令制御部１２、以下同じ）は最初にデータ更新要求を行ったときにはネットワーク環境が弱い環境下に存在しているが、その後移動してネットワーク環境が強い環境下に存在するようになるものとする。

ここでは、以下の順にそれぞれの処理が行われる
（１）更新要求クライアントによる遠距離更新時のユーザ更新要求
（２）サーバによる遠距離更新時のユーザ更新要求受付
（３）検索要求クライアントによる検索実行
（４）サーバによるユーザ参照要求受付
（５）サーバによる差分検索要求、更新要求クライアントによる差分検索応答
（６）更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付

以下、上記手順の具体的内容について述べる。
[（１）更新要求クライアントによる遠距離更新時のユーザ更新要求]
図４１は、上記（１）更新要求クライアントによる遠距離更新時のユーザ更新要求の処理例を示したフローチャートである。以下このフローチャートを参照しながら更新要求クライアントによる遠距離更新時のユーザ更新要求を説明する。

サーバのデータベース更新を行う必要が生ずると、まず、更新要求クライアントは更新を行うために送信しなければならない送信データ量Ｄの算出を行う（Ｓ４１０１）。次に、更新要求クライアントは、検索発生回数ｎ、差分検索のためのデータ量Ｒ、稼働率ｐを取得する（Ｓ４１０２）。検索発生回数ｎ、差分検索のためのデータ量Ｒ、稼働率ｐ(以下、これらの値をまとめて実績値（ｎ，Ｒ，ｐ）とする）はサーバが過去データなどから算出して保持しており、各クライアントはこの実績値（ｎ，Ｒ，ｐ）のレプリカをサーバから取得し所持する。また、実績値は複数あってもよく、例えばテーブルごとに実績値（ｎ，Ｒ，ｐ）が保持されるようにしてもよい。

次に、更新クライアントは上記データ量Ｄ、及び実績値（ｎ，Ｒ，ｐ）に基づいて更新通知のみの方が効率的かどうかを判定する（Ｓ４１０３）。この判定は、上述の判定式

に値を当てはめ、この不等式が成立するかどうかにより行う。不等式が成立する場合は更新通知のみの方が効率的であるとの判定となり（Ｓ４１０３，Ｙｅｓ）、不等式が成立しない場合は更新通知のみの方が効率的でないとの判定となる（Ｓ４１０３，Ｎｏ）。

更新通知のみの方が効率的であるとの判定をした場合（Ｓ４１０３，Ｙｅｓ）、更新要求クライアントはサーバに更新通知を送信する（Ｓ４１０５）。例えば、更新したデータのＩＤのみ送信し、データの内容の送信は行わない。一方、更新通知のみの方が効率的でないと判定した場合（Ｓ４１０３，Ｎｏ）、更新要求クライアントはサーバに対して通常更新を実行する（Ｓ４１０４）。

[（２）ユーザ更新要求受付]
上記通常更新（更新データ）若しくは更新通知を受け付けたサーバ（より詳しくは命令制御部２２、以下同じ）は、ユーザ更新要求受付を実行する。図４２は、上記（２）サーバによる遠距離更新時のユーザ更新要求受付の例を示したフローチャートである。以下このフローチャートを参照しながらサーバによる遠距離更新時のユーザ更新要求受付の処理内容を説明する。

更新要求クライアントから送信された通常更新若しくは更新通知を受け付けたサーバは、まず受け付けた内容が更新通知であるか否かを判定する（Ｓ４２０１）。更新通知でないと判定した場合（Ｓ４２０１、Ｎｏ），サーバは受信した更新データに基づいてデータベースを通常に更新する（Ｓ４２０２）。一方、更新通知であると判定した場合（Ｓ４２０１、Ｙｅｓ），サーバは更新通知に含まれる情報(例えば、更新対象のデータＩＤなど）に基づいて、更新対象のデータを無効化(検索対象からはずす処理)し、当該データについては更新したユーザである更新要求クライアントに問い合わせるように設定(例えば、データベース中に要問い合わせフラグを記述し、問い合わせ先クライアント特定情報を付加する、など）する（Ｓ４２０３）。さらに、サーバは更新対象のデータを管理する（Ｓ４２０４）。

サーバ側は更新通知の対象のデータを覚えておく。他のクライアントからの最新データへの検索要求に対してサーバ自身は最新のデータを持っていいないことを覚えとかなければならない。具体的には、サーバは更新通知されたデータに対して、更新者をそのデータとペアにして（例えば、メモリ上で）管理する。
以上で、サーバによるユーザ更新要求受付が終了する。

[（３）検索要求クライアントによる検索実行]
上記サーバがユーザ更新要求受付を終了したのち、検索要求クライアントが検索要求をサーバに送信したものとする。このとき検索要求クライアントによる検索実行が行われる。図４３は、上記（３）検索要求クライアントによる検索実行の例を示したフローチャートである。以下このフローチャートを参照しながら検索要求クライアントによる検索実行の処理内容を説明する。

検索要求クライアントはサーバにデータベースにVersionの問い合わせを行う（Ｓ４３０１）。サーバが自己のデータベースのVersionを検索要求クライアントに返す。検索要求クライアントはサーバから取得したVersionから、サーバに問い合わせるか否かを判断する（Ｓ４３０２）。具体的には、例えば、検索要求クライアント自身のデータベースより新しいVersionであれば問い合わせする。

検索要求クライアントが問い合わせ必要であると判定した場合（Ｓ４３０３、Ｙｅｓ）、検索要求クライアントはサーバに差分検索を実行させ、検索結果を取得する（Ｓ４３０４）。その後、検索要求クライアントは自分が所持するデータベースを検索する（Ｓ４３０５）。
一方、検索要求クライアントが問い合わせ必要でないと判定した場合（Ｓ４３０３、Ｎｏ）、検索要求クライアントはサーバに差分検索を求めることなく直ちに自分が所持するデータベースを検索する（Ｓ４３０５）。

最後に、検索要求クライアントは検索結果を出力する。差分検索の結果をサーバから取得している場合には、自己のデータベースの検索結果と差分検索の結果を結合して検索結果として出力する（Ｓ４３０６）。
以上で、検索要求クライアントによる検索実行が終了する。

[（４）サーバによるユーザ参照要求受付]
検索要求クライアントから検索要求を受け付けたサーバは、ユーザ参照要求受付処理を実行する。図４４は、上記（４）サーバによるユーザ参照要求受付の例を示したフローチャートである。以下このフローチャートを参照しながらユーザ参照要求受付処理の内容を説明する。

検索要求を受け付けたサーバはまず、自己のデータベースを参照し、問い合わせしないと得られないデータを列挙する（Ｓ４４０１）。図４５は、このステップＳ４４０１のより具体的な処理内容を示したフローチャートである。サーバは自己のデータベース内のデータのうち、更新対象のデータを検索する（Ｓ４５０１）。検索して抽出されたデータについて、サーバは検索対象となるか否かを判定する（Ｓ４５０２）。検索対象となると判定した場合（Ｓ４５０２，Ｙｅｓ）には、サーバは当該データを問い合わせリストに追加する（Ｓ４５０３）。ここでいう「問い合わせリスト」は、どのユーザ（クライアント）に問い合わせすればいいか判断するためのリストである。一方、検索対象とならないと判定した場合（Ｓ４５０２，Ｙｅｓ）には、サーバは次の更新対象のデータに進む。上記Ｓ４５０２、Ｓ４５０３を全ての更新対象のデータについて終了するまで繰り返す。これでＳ４４０１のデータの列挙が終了する。

図４４に戻り、ユーザ参照要求受付処理の説明を続ける。データの列挙（Ｓ４４０１）が終了すると、サーバは問い合わせ先リストにしたがい、各ユーザ(クライアント)に差分検索を要求し、返される差分検索結果を取得する（Ｓ４４０２）。

次にサーバは、サーバ自身のデータベースを参照し、更新済みのデータを検索する（Ｓ４４０３）。さらにサーバは検索結果を出力する。差分検索の結果をクライアントから取得している場合には、自己のデータベースの検索結果と差分検索の結果を結合して検索結果として出力する（Ｓ４４０４）。

最後に、サーバは検索頻度ｎの値を1だけ増加させ、新しい検索頻度ｎとして記憶する（Ｓ４４０５）。実績値（ｎ，Ｒ，ｐ）を最新の状態に保っておくためである。
以上で、ユーザ参照要求受付処理が終了する。

[（５）サーバによる差分検索要求、更新要求クライアントによる差分検索応答]
検索要求クライアントから検索要求を受け付けたサーバは、更新クライアントに対して差分検索要求を出し、この差分検索要求を受け付けた更新要求クライアントは差分検索応答を行う。

図４６は、上記（５）サーバによる差分検索要求、更新要求クライアントによる差分検索応答の処理例を示したフローチャートである。以下このフローチャートを参照しながらサーバによる差分検索要求、更新要求クライアントによる差分検索応答の内容を説明する。

まず、サーバ側で行われる差分検索要求について先に説明する。検索要求クライアントから検索要求を受け付けたサーバはまず、他のクライアント（先の問い合わせリストにより決定する）に対して差分検索要求を送信する（Ｓ４６０１）。その後、差分検索要求を受け付けたクライアント(この例では更新要求クライアントのみとしたが、実際には更新要求クライアントに限られるわけではない）から結果を受け取る（Ｓ４６０２）。この「結果」は差分検索結果である場合と、更新データである場合と2通りある。

結果を受け取ったサーバは、その結果が更新データであるか否かを判定する（Ｓ４６０３）。その結果が更新データであると判定した場合（Ｓ４６０３、Ｙｅｓ）、サーバは受け取った更新データを自己のデータベースに反映させ（Ｓ４６０４）、差分検索のために送られたデータ量の合計Ｒ_ｓｕｍ、及び差分検索の実行回数ｎ_Ｒをリセットする（Ｓ４６０５）。なお、合計Ｒ_ｓｕｍ、及び差分検索の実行回数ｎ_Ｒは更新データに対してのデータなので、更新した場合は不要となる。これで、サーバ側で行われる差分検索要求は終了する。

一方、ステップＳ４６０３の判定において、その結果が更新データでない（検索結果である）と判定した場合（Ｓ４６０３、Ｎｏ）、サーバは、受け取った検索結果のデータＲを差分検索のために送られたデータ量の合計Ｒ_ｓｕｍに加算して新たなデータ量の合計Ｒ_ｓｕｍとして記憶する（Ｓ４６０６）。次に、サーバは差分検索の実行回数ｎ_Ｒを1増加させ、新たな差分検索の実行回数ｎ_Ｒとして記憶する（Ｓ４６０７）。実績値（ｎ，Ｒ，ｐ）を最新の状態に保っておくためである。これで、サーバ側で行われる差分検索要求は終了する。

次に、更新要求クライアントによる差分検索応答の処理例について説明する。
まず、更新要求クライアントは、サーバ側の差分検索要求のステップＳ４６０１においてサーバから送信された差分検索要求を受け取る（Ｓ４６０８）。次に、更新要求クライアントは、この差分検索要求に応じて、自己のデータベースを用いて差分検索を実行する（Ｓ４６０９）。次に、更新要求クライアントは今まで送った更新データのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えているか否かを判定する（Ｓ４６１０）。
具体的には、下記式に基づいてＳ４６１０の判定が行われる。

但し、上記式においてR_iはi番目に行われた更新データのデータ量、Ｄはサーバに送るべき更新データのデータ量である。

上記Ｓ４６１０において更新要求クライアントは今まで送ったデータのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えている(上記式が成立している）と判定した場合（Ｓ４６１０、Ｙｅｓ）、更新要求クライアントはサーバに更新データを返す（Ｓ４６１１）。これで更新要求クライアントによる差分検索応答は終了する。

一方、上記Ｓ４６１０において更新要求クライアントは今まで送ったデータのデータ量の合計値が、サーバに送るべき更新データのデータ量を超えていない（上記式が成立していない)と判定した場合（Ｓ４６１０、Ｎｏ）、Ｓ４６０９で得られた差分検索結果をサーバに返す（Ｓ４６１２）。さらに更新要求クライアントは送ったデータ量Ｒ_ｉを保持する。後に、今まで送った更新データのデータ量の合計値を算出し、Ｓ４６１０の判定を行うためである。これで更新要求クライアントによる差分検索応答は終了する。

[（６）更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付]
弱いネットワーク環境下にあった更新要求クライアントが強いネットワーク環境下に入った場合、更新要求クライアントによる更新要求並びにサーバによるユーザ更新要求受付が行われる。図４７は、上記更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付処理例を示したフローチャートである。以下このフローチャートを参照しながら更新要求クライアントによる更新要求、サーバによるユーザ更新要求受付を説明する。

更新要求クライアントはまず、更新通知のみの更新データをサーバに送信する（Ｓ４７０１）。次に、更新要求クライアントはサーバから実績値（ｐ，ｎ，Ｒ）を取得する（Ｓ４７０２）。その後、更新クライアントは自己のデータベースとサーバのデータベースとの完全同期を実行する（Ｓ４７０３）。この完全同期の内容については後述する。完全同期終了後、更新要求クライアントは更新要求を終了する。

次に、サーバの更新要求受付について説明する。更新要求クライアントから送信された更新データを受信したサーバは、更新データを自己のデータベースに反映させる（Ｓ４７０４）。次に、サーバは前回の完全同期時刻と、更新通知日時と、現在時刻から稼働率ｐを算出する（Ｓ４７０５）。サーバは、差分検索のために送られたデータ量の合計Ｒｓｕｍを差分検索の実行回数ｎＲで割って、平均データ量Ｒを算出する（Ｓ４７０６）。次に、サーバは更新された実績値（ｎ，Ｒ，ｐ）を更新要求クライアントに送信する（Ｓ４７０７）。その後、サーバは更新要求クライアントとの間でデータベース内容の完全同期を実行する（Ｓ４７０８）。この完全同期の内容については後述する。完全同期終了後、サーバは更新要求受付を終了する。

最後に、更新要求クライアント及びサーバ間での完全同期処理について説明する。
完全同期処理を開始した更新要求クライアントはまず、自分のデータベースのVersionをサーバに通知する（Ｓ４７０９）。サーバは更新要求クライアントからデータベースのVersionを得る（Ｓ４７１０）と、更新要求クライアントに渡すべき差分となるデータを生成する（Ｓ４７１１）。次にサーバは、差分となるデータを更新要求クライアントに送信する（Ｓ４７１２）。更新要求クライアントはサーバから差分となるデータを受信する（Ｓ４７１３）。更新クライアントは受信した差分となるデータを自己のデータベースに更新させる（Ｓ４７１４）。これで、更新クライアント及びサーバ間のデータベース完全同期が完了する。

[本実施の形態の効果的な状況]
本実施の形態は、下記のような状況下でとりわけ有効である。
１．サーバ、クライアント間が近距離では安価で高速な通信ができ、遠距離では高価で低速でも通信が可能であること。
このような環境下で、本実施の形態は、近距離では同期による更新をし、遠距離では本提案を実施する。
２．一定間隔で、データベースがリフレッシュできること
充電のついでに完全同期できるなど、そのような完全同期がある期間内には行われる環境であること。
３．クライアント側で入力されるような、更新データが大量であるが、検索対象になりにくい環境下であること。
同期するまで、当面、検索されないようなものほど本実施の形態は効果がある。
上記において「近距離」とは例えば、（通信の）コストが小さい環境を意味し、「遠距離」とは例えば、（通信の）コストが大きい環境を意味する。
ここでいう「コスト」とは、通信に伴う料金（課金額）や、通信速度、レイテンシィ、電力消費量などを一つ乃至は複数考慮して決定する定量的なものを意味する。

[本差分検索システムのデータ更新のまとめ]
本実施の形態によれば、以下のメリットを享受できる。
１．データを更新する際、悪い通信環境での通信量を減らすことができるため、ネットワーク管理者から見てネットワークトラフィックが減り、ユーザから見た場合に通信費用が減る。
２．サーバの負担を減らすことも可能となる。
なお、[本差分検索システムのデータ更新]は、第１の実施から第５の実施の更新時に適用でき、また第６の実施にも適用できる。

（第６の実施の形態）
次に、本実施の形態に係る第６の実施の形態について述べる。第６の実施の形態は、基本的に前述の第１の実施の形態から第５の実施の形態と同様の構成及び動作をするデータベースシステムであるが、本実施の形態は、サーバを使用することなく、クライアント間で差分検索を行い、及び／又は、クライアント間でデータベースを最新の状態に更新できるデータベースシステムである点で異なっている。

[第６の実施の形態の構成例]
第６の実施の形態は、第１から第５の実施の形態における情報管理装置（以下の説明では、サーバとも称する）に相当する装置を有する構成としても成立するが、サーバを設けない構成としても本実施の形態は成立する。以下の説明ではサーバを設けない場合の構成として、本実施の形態の説明を行う。

［用語］
本実施の形態の説明で使用する用語は、特にことわりのない場合、以下の意味を有する。

「同期」とは、マスター・クライアントとノード・クライアントとの間で、データベース内のデータを共有している状態、若しくは共有化するための処理を意味する。

「差分把握」とは、ノード・クライアントとマスター・クライアントのデータの差分を互いのバージョンから把握し、検索処理において重複したデータを検索しないようにすることである。

「差分検索」とは、差分データ、すなわち同期がとれていないデータに対する検索をいい、マスター・クライアントが実行するものである。因みに、差分があるかどうか検索するわけではない。

「変更履歴」とは、データベース内のデータについて変更履歴で変更した差分を管理する。変更履歴は、「バージョン」と「データＩＤ」の組を持っている。

「バージョン」とは、本データベースシステム内でマスター・クライアントが一意に発行する数字で、データベース内のデータについて変更が行われたらバージョンが１つあがる。本実施形態において「バージョン」は、「差分把握」及び「差分検索」を簡単にするための仕組みである。

図４８に、第６の実施の形態のシステム構成例を示したブロック図を示す。図４８に図示するように、システム４８００は、マスターとなる情報端末装置（以下、区別のためマスター・クライアントとも呼ぶ）４８０１と、例えばインターネット網、無線通信網、無線ＬＡＮなどの通信網４８０２でクライアント機器となる情報端末装置（以下、区別のためノード・クライアントとも呼ぶ）４８０３とから構成されている。各クライアントは同一の通信網で接続されてもよいし、異なる通信網により接続されてもよい。例えば、マスター・クライアント４８０１と全てのノード・クライアント４８０３が無線ＬＡＮに接続されていても本実施の形態は成立し、またあるクライアント同士はインターネット網で接続されており、別のクライアント同士は無線ＬＡＮで接続されている状態でも本実施の形態は成立する。

マスター・クライアント４８０１は後述する「責任」を有するクライアントである。ノード・クライアント４８０３は、「責任」を有さないクライアントである。マスター・クライアント４８０１とノード・クライアント４８０３とは、「責任」の有無について異なるだけであって、装置構成、機能は共にクライアントであって差異はない。マスター・クライアント４８０１とノード・クライアント４８０３を区別しない場合には、単に「クライアント４８０１（４８０３）」と呼ぶこととする。

「責任」を有するクライアント、すなわちマスター・クライアント４８０１は、ノード・クライアント４８０３の求めに応じて、後述する「つなぎかえ指定」、「差分検索」、データベースの同期を行うことができる唯一の装置である。なお、「責任」を有するか否かは、後述する「更新権」の有無によって識別される。「責任」を有するクライアントは、「更新権」を有するクライアントである。

クライアント４８０１（４８０３）は、通信機能を有する情報処理装置、より詳しくは演算処理装置（ＣＰＵ）、主メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、入出力装置（Ｉ／Ｏ）、必要な場合にはハードディスク装置等の外部記憶装置を具備している情報処理装置、あるいはそのような情報処理装置を含む装置である。クライアント４８０１（４８０３）は、データベース機能を備えるものであれば、どのような情報処理装置であってもよく、例えば携帯電話や携帯プレーヤが好適である。所謂、ウルトラモバイルＰＣと称されるものでもよい。

図４９は、本実施形態に係るクライアント４８０１（４８０３）の機能ブロック図である。クライアント４８０１（４８０３）は、ユーザインターフェース４９０１、接続部４９０２、命令制御部４９０３、ＳＱＬ実行部４９０４、及びデータベース４９０５を有している。ユーザインターフェース４９０１及び接続部４９０２は命令制御部４９０３に接続されている。命令制御部４９０３はＳＱＬ実行部４９０４に接続されており、ＳＱＬ実行部４９０４はデータベース４９０５に接続されている。接続部４９０２は無線回線、あるいは有線回線を介して通信網４８０２に接続可能である。また、データベース４９０５は、データ４９０６、バージョン４９０７、変更履歴４９０８を記憶している。

ユーザインターフェース４８０１は、ユーザの入力を受け付けるとともに、処理結果を表示する機能を有する。例えば、液晶ディスプレイ装置及びタッチパネルなどである。接続部４９０２は、通信網４８０２を介して他のクライアント４８０１（４８０３）と通信する機能を有する。

命令制御部４９０３は、ユーザや他のクライアント４８０１（４８０３）からの要求や命令に応じて、所定の命令を実行し、必要に応じてＳＱＬ実行部４９０４や接続部４９０２に命令を出し、あるいは結果をユーザインターフェース４９０１に表示させる。図５０は、命令制御部４９０３の一構成例を示す機能ブロック図である。命令制御部４９０３は、接続開始部５００１、接続受付部５００２、接続停止部５００３、接続終了部５００４、差分通知部５００５、差分除去部５００６、差分検索部５００７、ＳＱＬ受付部５００８、結果取得部５００９、結果送信部５０１０、ネットワーク利用判断部５０１１、同期送信部５０１２、同期受信部５０１３、更新権利取得部５０１４、更新権利破棄部５０１５、つなぎかえ指定部５０１６、つなぎかえ処理部５０１７、最新保証処理部５０１８、つなぎかえ要求部５０１９、最新保証通知部５０２０、最新保証切れ通知部５０２１、判定部５０２２という各命令処理部を有している。また、命令制御部４０９３は、同期内ノード５０２３、更新権５０２４、問い合わせ先５０２５、最新保証フラグ５０２６、予測データ５０２７を記憶しており、本実施の形態の記憶手段として機能する。

以下に、上記命令処理部のそれぞれについて説明する。
接続開始部５００１は、あるクライアントが他のクライアントとの通信を確立させるための処理を行う。

接続受付部５００２は、他のクライアントからの接続要求を受けた場合、当該クライアントとの通信を確立する処理を行う。

接続終了部５００３は、接続開始後、必要な処理が終了したのちに他のクライアントとの通信を解除する処理を行う。
接続停止部５００４は、接続のために用意していたメモリや通信部などの資源を解放するために他のクライアントからの求めに応じて確立させた通信を解除する処理を行う。
差分通知部５００５は、ノード・クライアント４８０３が自己のデータベースのバージョンをマスター・クライアント４８０１に通知して、互いのバージョンからデータの差分をマスター・クライアントに把握させる処理を行う。
差分除去部５００６は、差分データを無効化する処理を行う。
差分検索部５００７は、差分検索処理を実行する。
ＳＱＬ受付部５００８は、他のクライアントからＳＱＬ文を取得し、取得したＳＱＬ文をＳＱＬ実行部４９０４に渡す処理を行う。
結果取得部５００９は、前述の結果送信により送信されたデータを取得する処理を行う。
結果送信部５０１０は、ＳＱＬ実行部４９０４がＳＱＬ文を実行した結果をＳＱＬ文の送信元である他のクライアント４８０１（４８０３）に送信させる処理を行う。
ネットワーク利用判断部５０１１は、そのクライアント４８０１（４８０３）が使用しているネットワーク（通信網４８０２に相当）が「強いネットワーク環境」であるのか、「弱いネットワーク環境」であるのかを判定する。
同期送信部５０１２は、他のクライアント４８０１（４８０３）から同期を求められた場合、同期させるためのデータベースのデータを当該クライアント４８０１（４８０３）に送信させる処理を行う。
同期受信部５０１３は、上記「同期送信」に他のクライアント４８０１（４８０３）から送信されたデータを受信し、データベース４９０５の内容を同期させる処理を行う。
更新権利取得部５０１４は、「責任」を有するマスター・クライアント４８０１からその「責任」を取得する処理を行う。具体的には、「責任」の有無に応じて更新権５０２４の書き換えを行う。
更新権利破棄部５０１５は、自己の更新権５０２４を責任を有さないことを示すように書き換える。具体的には、「責任」の有無に応じて更新権５０２４の書き換えを行う。
つなぎかえ指定部５０１６は、つなぎかえ要求を送信したクライアント４８０３に対して、新しい「問い合わせ先」となるクライアントを通知する処理を行う。つなぎかえ指定５０１６は、本実施の形態のつなぎかえ指定手段に相当する。
つなぎかえ処理部５０１７は、つなぎかえ指定を受信したノード・クライアント４８０３が、問い合わせ先５０２５を更新する処理を行う。つなぎかえ処理５０１７は、本実施の形態のつなぎかえ処理手段に相当する。
つなぎかえ要求部５０１９は、現在「責任」を有しているマスター・クライアント４８０１を通知するよう求める処理を行う。つなぎかえ要求部５０１９は、本実施の形態のつなぎかえ要求手段に相当する。

判定部５０２２は、予測データ５０２７に基づいて、つなぎかえ要求の要否の判定を行う。

次に、命令制御部４９０３が有する各データについて説明する。
同期内ノード５０２３は、データベース４９０５の同期を行っている他のクライアント４８０１（４８０３）のリストである。

更新権５０２４は、そのクライアント４８０１（４８０３）が「責任」、すなわち更新権利があるかどうかを示す情報である、例えば、更新権の内容が「１」なら自分が責任を有するマスター・クライアント４８０１であることを示し、「０」であれば自分は「責任」を有さないノード・クライアント４０８３であることを示す。更新権５０２４を所有するクライアントは、その時点でデータベース４９０５の内容が最新の内容であるクライアントであり、同時に複数は存在しえない。但し、「責任」、すなわち更新権は、データベースが更新されるごとに、クライアント間で移転していく。

問い合わせ先５０２５は、自分よりも新しいバージョンのクライアント４８０１（４８０３）をひとつ覚えておくためのノードの連結情報である。但し、問い合わせ先であるクライアントがその時点でまだ責任を有しているかどうかはわからない。

予測データ５０２７は、つなぎかえを行うか否かを判断するための予測値・実績値である。予測データには、ノード全体数、自分に属している子のノード数、更新確率・検索確率などが含まれる。予測データ５０２７については、クライアント４８０１（４８０３）は同期時に互いに情報交換することができるので、同期している他のノードの情報を使うことが可能である。

図４９に戻り、クライアントの構成例の説明を続ける。
ＳＱＬ実行部４９０４は、データベース４９０５に対する命令であるＳＱＬ文を用いて、命令制御部４９０３からの要求にしたがってデータベース４９０５への操作や定義づけを行う機能を有する。

データベース２４は、追加・変更・削除されたデータ４９０６と変更履歴４９０８とバージョン４９０７を記憶する。データ４９０６は、データベースを構成する個々のデータ要素の集合である。バージョン４９０７は、データ４９０６に対応する現在のバージョンを表す情報である。変更履歴４９０８は、データベース４９０５内のデータ４９０６について、変更した差分を管理するための情報である。図５１は、変更履歴４９０８の記憶内容の例を示すブロック図である。変更履歴は、差分把握可能範囲５１０１と、バージョン５１０２とデータＩＤ５１０３とを含む。差分把握可能範囲５１０１は、極端に古いバージョンのデータベースしか保持していないクライアント機器をケアする場合に対応するための情報であって、差分検索が可能な範囲を示す情報である。バージョン５１０２とデータＩＤ５１０３とは組になっており、データＩＤ５１０３は対応するバージョンにおいて追加・変更・削除されたデータ要素を特定する識別情報である。

[本実施の形態の動作例について]
次に、本実施の形態に係るデータベースシステム４８００の動作例を説明する。
[責任の移転：２クライアント間の場合]
本実施の形態では、サーバを使用することなく、クライアント間で検索を行い、及びデータベースを最新の状態に更新できることを特徴の一つとしている。このための仕組みとして、本実施の形態では最新データを所持するクライアントが「責任」を有する。「責任」の有無は前述の更新権５０２４の内容によって識別される。前述の通り、「責任」を有するクライアントはマスター・クライアント４８０１となり、そうでないクライアントはノード・クライアント４８０３となるが、「責任」が移動することによって、マスター・クライアント４８０１はノード・クライアント４８０３となり、一方ノード・クライアント４８０３がマスター・クライアント４８０１になる。

図５２に、１つのマスター・クライアントと、１つのノード・クライアントの間での責任の移転の例を示す。あるクライアントＡ（この時点ではノード・クライアント）が自己のデータベースを最新の状態にするべく、データベースの更新処理を行おうとする場合、その時点で「責任」を有するマスター・クライアントＢに対して更新要求を送信する（Ｓ５２０１）。更新要求を受信したマスター・クライアントＢはノード・クライアントＢにデータベースの更新をさせるとともに、更新要求の送信元であるノード・クライアントＡに「責任」を渡す。データベースの内容を最新の内容に更新し、新たに「責任」を保有したノード・クライアントＡは、以後マスター・クライアントＡとして振る舞うことになり、「責任」を保有しなくなったマスター・クライアントＢは以後ノード・クライアントＢとして振る舞うことになる。すなわち、以後、ノード・クライアントＢは、「責任」を受け取ったマスター・クライアントＡに問い合わせを行う。なお、「責任」の受け渡しに相当するデータ処理方法については後述する。

[責任の移転：３クライアントの場合]
次に、３つのクライアントが関与する場合の「責任」の移転について説明する。図５３は、あるデータａについての「責任」が移転する例を示す。図５３に示した例では、３つのクライアントは相互に通信可能な状態にあるものとする。クライアントＡはデータａについて責任を有している。残りの２つのクライアント、クライアントＢ、クライアントＣは共にデータａについてデータベース記憶内容の更新を必要としている状態にあり、クライアントＢ、クライアントＣはデータａについてクライアントＡが責任を有すると記憶している。図中の矢印は、矢印の元にあるクライアントから見た、責任を有するクライアント、すなわち「問い合わせ先」に記述されたクライアントを示している。

ここで、クライアントＢがクライアントＡに対してデータａについて更新要求を行ったものとする。クライアントＡはクライアントＢに対して最新の内容のデータａを送信する。クライアントＢの有するデータベース内容はデータａについて更新され、最新の内容となる。このときクライアントＡはデータａについての「責任」をクライアントＢに渡す。クライアントＢはこの「責任」を取得し、データａについて自分が「責任」を有すると記憶する。また、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶する。図５４は図５３の状態から責任が移転した後の状態を示す図である。クライアントＢはこの「責任」を取得し、データａについて自分が責任を有すると記憶し、クライアントＡは、自分は「責任」を破棄し、データａについての責任はクライアントＢが有するものと記憶した状態を示す。クライアントＣは以前と変わらず、データａについてクライアントＡが責任を有すると記憶している状態が継続する。

[最新の検索（差分把握）]
本実施の形態は、サーバ不要で、最新の内容のデータベースの検索することができる。

各クライアントは、最新のデータベースの内容を検索をするためには、責任を有するクライアントに問い合わせすることが必要である。これは、前述した実施の形態における差分検索でいう「差分把握」に相当する処理である。先の図５４で示した例に基づいて、本実施の形態における最新の検索について説明する。

クライアントＣは、最新のデータであるデータａについてクライアントＡが責任を有していると記憶している。クライアントＢはデータａについて自分が責任を有すると記憶し、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶している状態である。

クライアントＣはクライアントＡがデータａについて責任を有していると記憶しているので、クライアントＣはクライアントＡに問い合わせ(差分通知)を送信する。

問い合わせ（差分通知）を受信したクライアントＡはデータａについて責任を持っておらず、且つ、クライアントＡはクライアントＢに聞くという情報を持っているので、クライアントＢにデータａについて問い合わせ（差分通知）を送信(転送、中継)する。クライアントＢはデータａについて責任を有しているので、自己が記憶する最新のデータａとの差分内容をクライアントＣに送信する。よって、クライアントＣは「責任」を有するクライアントとの差分を把握することができる。

[連鎖問い合わせ：（差分検索）のつなぎかえ]
本実施の形態では、クライアントがデータベースを検索する場合において、最新のマスター・クライアント４８０１がどのクライアントであるかを把握することができるようになる。

図５４は、クライアントＣは、最新のデータであるデータａについてクライアントＡが責任を有していると記憶している。クライアントＢはデータａについて自分が責任を有すると記憶し、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶している状態である。

ここで、クライアントＣがデータａについて検索を行おうとする場合、まずデータａについて責任を有する（とクライアントＣが記憶している）クライアントＡに問い合わせる。クライアントＡはデータａについての責任はクライアントＢが有するものと記憶しているので、データａについてクライアントＢに問い合わせる。すなわち、それぞれのクライアントにおいて「問い合わせ先」となっているクライアントに対して連鎖的に問い合わせが行われる。問い合わせに対してマスター・クライアント４８０１から応答がなされ、各クライアントは、今現在「責任」を有するクライアントを示す情報である問い合わせ先５０２５を更新する（「つなぎかえ」と呼ぶ）ことができる。但し、つなぎかえはつなぎかえをした方が有利な場合と判定された場合に行われ、常につなぎかえが行われるわけではない。図５４の状態の後、つなぎかえが行われた状態を図５５に示す。クライアントＣの「問い合わせ先」が更新され、現在のマスター・クライアントＢが新たな「問い合わせ先」として登録される。クライアントＡについて「問い合わせ先」の変更はない。

[連鎖問い合わせ：更新の際のつなぎかえ]
本実施の形態では、クライアントがデータベースを更新する場合において、サーバを用いることなく更新を行うことができ、更新の際には、最新のマスター・クライアント４８０１がどのクライアントであるかを把握することができるようになる。

図５６は、クライアント間でのデータベース更新前のある状態を示す図である。クライアントＣは、最新のデータであるデータａについてクライアントＡが責任を有していると記憶している。クライアントＢはデータａについて自分が責任を有すると記憶し、クライアントＡはデータａについての責任はクライアントＢが有するものと記憶している状態である。

ここで、クライアントＣがデータａについてデータベースの更新を行おうとする場合、まずデータａについて責任を有する（とクライアントＣが記憶している）クライアントＡに問い合わせる。クライアントＡはデータａについての責任はクライアントＢが有するものと記憶しているので、データａについてクライアントＢに問い合わせる。すなわち、「問い合わせ先」となっているクライアントに対して連鎖的に問い合わせが行われる。

クライアントＣがクライアントＢよりデータを取得し、データベースの内容を最新の内容に更新すると、データａについての責任はクライアントＢからクライアントＣに渡され、クライアントＣが新たに責任を有する状態になる。

この場合、経由したクライアント（問い合わせに関与したクライアント）は、責任を有するクライアントの情報である問い合わせ先５０２５を書き換える（「つなぎかえ」と呼ぶ）。すなわち、クライアントＡ、クライアントＢはデータａについてクライアントＣが責任を有すると、記憶するように問い合わせ先５０２５を書き換える。但し、つなぎかえはつなぎかえをした方が有利な場合と判定された場合に行われる。図５６の後につなぎかえが行われた状態を図５７に示す。クライアントＡ，クライアントＢの「問い合わせ先」が更新され、現在のマスター・クライアントＣが新たな「問い合わせ先」として登録される。

[つなぎかえの要否]
各クライアントは、以下の判定条件式に基づいて、つなぎかえを行うか否かを判定し、判定結果に基づいてつなぎかえ処理を実行する。

判定条件式は以下の通り
(投資)＜（同期するまでに検索する回数）×（問い合わせ通信の減る量）
上記式の投資は本実施の形態の第１の送信データ量に相当し、上記式の右辺は本実施の形態の第２の送信データ量に相当する。

上記判定条件式が満たされる場合には、クライアント、より詳しくは判定部５０２２は、つなぎかえ処理を実行すると判定する。同期すれば、1段化にされるためである。

「投資」は、つなぎかえを行うために必要な送信データ量であって、dと表す。「同期するまでに検索する回数」は予測値を用いる。予測値は予測データ５０２７から過去の平均値を算出することなど適宜な方法によって得る。「問い合わせ通信の減る量」は（h-１）dにより算出される値である。ｈはそのクライアントから最新ノード（実際に責任を有するクライアント）までの高さ(階層差）である。また、「同期するまでに検索する回数」は、そのクライアントに属している子ノードの数Ｃに比例する。なお、高さ(階層差）及び子ノードは、本実施の形態に係るデータベースシステムを、最新ノード（実際に責任を有するクライアント）を根ノードとし、問い合わせ先のクライアントを親ノードとする木構造と見た場合の概念である。

[つなぎかえの判定例]
上記判定条件式による判定例を以下に述べる。

投資＝つなぎかえを行うために必要な送信データ量dとし、「同期するまでに検索する回数」は、（（属している子の数）＋１（自分））×（平均問い合わせ確率）×（同期していない確率）により算出するものとする。

問い合わせ通信の減る量は、（（自分の高さ）−１）×ｄ
属している子の数＝C、平均問い合わせ確率＝ｎ、データベースのデータが完全である確率＝ｐ、自分の高さをｈとすると、条件判定式は以下のように表現される。
d ≦ (C+1)×ｎ×(1-p)×（h-1）×d …(条件判定式)

なお、最新ノード（マスター・クライアント）に直結している場合は、h=1となり、つなぎかえの必要性は生じない(右辺＝０となるため、ｄ＞０なら条件判定式は常に不成立）。また、属している子の数Ｃと問い合わせ確率ｎが大きいほど、判定条件式が満たされる可能性が高まる。これは、子の数だけ問い合わせ頻度が大きくなるためである。

上記条件判定式の確率ｐについて説明する。
マスター・クライアント４８０１（他の実施の形態のサーバに相当する）のデータベース中のデータが完全である確率をｐとすると、他のクライアントに更新データの存在を確認しなければいけない確率、すなわち「同期していない確率」は（１−ｐ）となる。具体例で説明すると、１日のうち９割はマスター・クライアント４８０１とノード・クライアント４８０３とが同期できる環境となると設定すれば、確率ｐは０．９であり「同期していない確率」（１−ｐ）は０．１となる。

次に平均問い合わせ確率ｎについて説明する。平均問い合わせ確率ｎは、１クライアントあたりのある一定期間での検索回数である。平均して1日あたり0.4回の検索をした場合では、平均問い合わせ確率ｎは0.4（/日）である。

図５８に、条件判定式の計算例を説明するための図を掲げる。この例では、最新データを有し、「責任」を有するマスター・クライアント４８０１(図中、Ｒと表示する)、このマスター・クライアント４８０１を問い合わせ先５０２５に記憶しているノード・クライアント４８０３(図中、Ｎ１と表示)、ノード・クライアントＮ１を問い合わせ先５０２５に記憶しているノード・クライアント４８０３(図中、Ｎ２と表示)、ノード・クライアントＮ２を直接、又は間接に問い合わせるノード・クライアント４８０３の集団（ノード・クライアントＮ２の下位ノード集団と呼ぶ）がある。このとき、ノード・クライアントＮ１の高さｈ＝１、ノード・クライアントＮ２の高さｈ＝２となる。また、ノード・クライアントＮ２の下位ノード集団に含まれるノード・クライアント数Ｃ＝２９とする。

ここで、上記条件下においてノード・クライアントＮ２が条件判定式を用いてつなぎかえの要否を判定するとどのようになるかを述べる。

ノード・クライアントＮ２について、d ≦ (C+1)×ｎ×(1-p)×（h-1）×d の式を考えると、
Ｃ＝２９、ｎ＝０．４、Ｐ＝０．９、ｈ＝２であるからこれらを代入して
d ≦ (29+1)×0.4×0.1×(2-1)×d = 1.2d …(式１）
となる。よってｄ＞０であれば上記不等式１は成立し、式１の結果より、ノード・クライアントＮ２はつなぎかえを実施すると判定する。

次に、上記条件下においてノード・クライアントＮ１が条件判定式を用いてつなぎかえの要否を判定するとどのようになるかを述べる。

ノード・クライアントＮ１について、条件判定式、d ≦ (C+1)×ｎ×(1-p)×（h-1）×d の式を考えると、
Ｃ＝３０、ｎ＝０．４、Ｐ＝０．９、ｈ＝１であるからこれらを代入して
d ≦ (30+1)×0.4×(1-0.9)×(1-1)×d =0 …(式２）

送信データ量ｄは０以下ではありえないので、式２の不等式は成立しない。
したが、ノード・クライアントＮ１はつなぎかえを実施しないと判定することになる。

さらに別の例で条件判定式の計算例を説明する。図５９に条件判定式の計算例を説明するための別の図を掲げる。図５９に示す例は、マスター・クライアントＲ，ノード・クライアントＮ１、ノード・クライアントＮ２については先の図５８に示した例と同じ条件とする。ノード・クライアントＮ２には、その子ノードである、ノード・クライアントＮ２を問い合わせ先５０２５とするノード・クライアント４８０３(区別のためＮ３と呼ぶ）が存在し、ノード・クライアントＮ３には、直接又は間接に問い合わせを送信するノード・クライアント４８０３の集団（ノード・クライアントＮ３の子ノード集団と呼ぶ)が存在する。なお、ノード・クライアントＮ３の子ノード集団の個数Ｃ＝９であるとする。ノード・クライアントＮ３の高さｈ＝３である。

ノード・クライアントＮ３について、条件判定式、d ≦ (C+1)×ｎ×(1-p)×（h-1）×d の式を考えると、
Ｃ＝９、ｎ＝０．４、Ｐ＝０．９、ｈ＝３であるからこれらを代入して
d ≦ (9+1)×0.4×0.1×(3-1)×d = 0.8d …(式３)
である。つなぎかえに必要な送信データ量は常にｄ＞０であるから、上記式３の不等式は成立せず、子の条件下ではノード・クライアントＮ３はつなぎかえを実施しないと判定することになる。但し、前述の通り、ノード・クライアントＮ２において判定すると、式２に示した結果より、ノード・クライアントＮ２はつなぎかえを実施する。すなわち、同じノード内でも、つなぎかえを行うクライアントと行わないノードが混在することありうる。

[つなぎかえの処理例]
次に、本実施の形態におけるつなぎかえの動作例について説明する。
図６０にサーバを用いることなく検索を行う場合の、本実施の形態に係るデータベース・システムの動作例をシーケンス図として示す。図６０に示す例では、１つのマスター・クライアント４８０１、及び３つのノード・クライアント４８０３（互いを区別するため、マスター・クライアント４８０１をクライアントＲ、３つのノード・クライアント４８０３をクライアントＮ１、クライアントＮ２，クライアントＮ３と呼ぶ）が存在している。

クライアントＮ３は責任を有するのはクライアントＮ２であると記憶しており、クライアントＮ２は責任を有するのはクライアントＮ１であると記憶しており、クライアントＮ１は責任を有するのはクライアントＲであると記憶しており、実際に責任を有しているのはクライアントＲである。

ここで、クライアントＮ３がデータベースの検索を行おうとしたとする。まず、検索を実行しようとするクライアントＮ３は、差分通知要求（Ｓ６００１）とつなぎかえ要求（Ｓ６００２）をクライアントＮ２に送信する。
つなぎかえ要求には、つなぎ換えを行った方が有利となるか否かを判定してもらうために必要なデータ（判定用データと呼ぶ）が含まれている。ここではクライアントＮ３の高さｈ、子ノード集団の個数Ｃがつなぎかえ要求のメッセージに付加されているとする。具体例としては
Ｎ３：ｈ＝１、Ｃ＝９
のような判定用データである。

クライアントＮ３から差分通知要求とつなぎかえ要求を受信したクライアントＮ２は自分は責任を有していないので、責任を有すると記憶しているクライアントＮ１に差分通知要求を送信（転送）する（Ｓ６００３）。また、クライアントＮ２は差分通知要求（Ｓ６００３）とともに、クライアントＮ３から受信した判定用データとともに、自己分の判定用データを含めたつなぎかえ要求（Ｓ６００４）をクライアントＮ１に送信する。具体的にはクライアントＮ３分の判定用データと、自己（Ｎ２)の判定用データが含まれる。その内容は以下の通りである。
Ｎ３：ｈ＝２、Ｃ＝９
Ｎ２：ｈ＝１、Ｃ＝２９
なお、他のクライアントから受け取った判定用データ中のｈの値は1だけ増加された値に変更される。

クライアントＮ２から差分通知要求とつなぎかえ要求を受信したクライアントＮ１は自分は責任を有していないので、責任を有すると記憶しているクライアントＲに差分通知要求を送信（転送）する（Ｓ６００５）。また、クライアントＮ１は、差分通知要求（Ｓ６００５）を転送するとともに、他のクライアントから受信した判定用データ及び自己分の判定用データを含めたつなぎかえ要求（Ｓ６００６）をクライアントＲに送信する。具体的にはクライアントＮ３分の判定用データ、クライアントＮ２分の判定データと、自己（Ｎ１)の判定用データが含まれる。その内容は以下の通りである。
Ｎ３：ｈ＝３、Ｃ＝９
Ｎ２：ｈ＝２、Ｃ＝２９
Ｎ１：ｈ＝１、Ｃ＝３０
なお、他のクライアントから受け取った判定用データ中のｈの値は1だけ増加された値に変更される。

クライアントＲは自己が責任を有するクライアントであると記憶しているので、受信したつなぎかえ要求に応答する。すなわち、クライアントＲは、責任を有するクライアントをクライアントＲとして記憶するように指令するつなぎかえ指定をクライアントＮ２に送信する（Ｓ６００７）。つなぎかえ指定を受信したクライアントＮ２は責任を有するクライアントをクライアントＲとするように記憶内容、すなわち問い合わせ先５０２５の内容を更新するつなぎかえ処理を行う（Ｓ６００８）。

さらにクライアントＲはクライアントＮ３にもつなぎかえ指定を送信する（Ｓ６０１０）し、また差分通知要求（Ｓ６００１）に対応する結果送信（Ｓ６００９）を行う。

つなぎかえ指定（Ｓ６０１０）を受信したクライアントＮ３は責任を有するクライアントをクライアントＲとするように記憶内容、すなわち問い合わせ先５０２５の内容を更新する（Ｓ６０１１）。また、クライアントＮ３は結果送信（Ｓ６０１１）の内容に基づいて差分除去を行う（Ｓ６０１２）。

次に、クライアントＮ３は差分除去（Ｓ６０１２）後のデータベースの内容に基づいて、差分検索の要求をクライアントＲに送信する（Ｓ６０１３）。差分検索の要求を受信したクライアントＲはＳＱＬ受付を行う（Ｓ６０１４）。ＳＱＬの内容に基づいてデータベース検索を実行し差分検索結果を生成したクライアントＲは、結果をクライアントＮ３に送信する（Ｓ６０１５）。クライアントＲから差分検索結果を受信（Ｓ６０１６）したクライアントＮ３は自己のデータベース検索内容とクライアントＲの差分検索内容により、完全な最新のデータベース内容についての検索結果を得られることになる。

また、検索に関する処理の一方、つなぎかえ処理（Ｓ６００８、Ｓ６０１１）が行われたクライアントＮ３，Ｎ２については責任を有するクライアントＲに次回からはダイレクトに問い合わせを送信することが可能となる。

[変形例]
上記の検索処理においては、差分通知要求と差分検索要求を別々に送信するものとして説明したが、本実施の形態では差分通知要求と差分検索要求を同時に送信するようにしても、サーバを用いない検索を成立させることができる。検索クエリが小さい場合はこのように同時に送信する方が有効(1パケット内に収まる)からである。

図６１は、差分通知要求と差分検索要求を同時に送信するようにした場合の、サーバを用いることなく検索を行う場合の本実施の形態に係るデータベースシステムの動作例を示したシーケンス図である。

ここで説明する例において、１つのマスター・クライアント４８０１、及び３つのノード・クライアント４８０３（互いを区別するため、マスター・クライアント４８０１をクライアントＲ、３つのノード・クライアント４８０３をクライアントＮ１、クライアントＮ２，クライアントＮ３と呼ぶ）が存在している。

クライアントＮ３は責任を有するのはクライアントＮ２であると記憶しており、クライアントＮ２は責任を有するのはクライアントＮ１であると記憶しており、クライアントＮ１は責任を有するのはクライアントＲであると記憶しており、実際に責任を有しているのはクライアントＲである。

まず、検索を実行しようとするクライアントＮ３は、差分通知要求及び検索要求（Ｓ６１０１）と、つなぎかえ要求（Ｓ６１０２）をクライアントＮ２に送信する。つなぎかえ要求には、自己分の判定用データが含まれている。

差分通知要求及び検索要求（Ｓ６１０１）とつなぎかえ要求（Ｓ６１０２）を受信したクライアントＮ２は、自分は責任を有していないので、責任を有するクライアント、すなわち問い合わせ先５０２５に記憶しているクライアントＮ１に差分通知要求及び検索要求を送信する（Ｓ６１０３）。また、クライアントＮ２はクライアントＮ３から受信した判定用データとともに、自己分の判定用データを含めたつなぎかえ要求をクライアントＮ１に送信する（Ｓ６１０４）。具体的にはクライアントＮ３分の判定用データと、自己（Ｎ２)の判定用データが含まれる。

差分通知要求及び検索要求（Ｓ６１０３）とつなぎかえ要求（Ｓ６１０４）を受信したクライアントＮ１は、自分は責任を有していないので、責任を有すると記憶しているクライアントＲに差分通知要求及び検索要求（Ｓ６１０５）を送信する。また、クライアントＮ１は他のクライアントから受信した判定用データ及び自己分の判定用データを含めたつなぎかえ要求（Ｓ６１０６）をクライアントＲに送信する。具体的にはクライアントＮ３分の判定用データ、クライアントＮ２分の判定データと、自己（Ｎ１)の判定用データが含まれる。

差分通知要求及び検索要求、つなぎかえ要求を受信したクライアントＲは、差分通知要求に応じたＳＱＬ受付を行う（Ｓ６１０７）。

また、クライアントＲは自己が責任を有するクライアントであると記憶しているので、つなぎかえ要求に応答する。すなわち、クライアントＲは、責任を有するクライアントをクライアントＲとして記憶するように指令するつなぎかえ指定をクライアントＮ２及びクライアントＮ３に送信する（Ｓ６１０８、Ｓ６１１１）。なお、この例ではクライアントＮ１についてはつなぎ換えを行っても有利にならないと判定されたため、クライアントＮ１についてはつなぎ換え指定は送信されないものとする。
つなぎ換え指定を受信したクライアントＮ２は、つなぎかえ指定（Ｓ６１０８）に応じて、問い合わせ先２０５５をクライアントＲとするように記憶内容を更新するつなぎかえ処理を行う（Ｓ６１０９）。

次に、クライアントＲは差分通知要求に応答する差分把握を生成するとともに、ＳＱＬ受付（Ｓ６１０７）に基づいてデータベース検索を実行し差分検索結果を生成し、これらをクライアントＮ３に送信する（Ｓ６１１０）。また、クライアントＲはクライアントＮ３にもつなぎかえ指定を送信する（Ｓ６１０８）。

クライアントＮ３は、クライアントＲから送信された結果送信の内容に基づいて差分除去を行う（Ｓ６１１４）。また、クライアントＮ３は、つなぎかえ指定（Ｓ６１１１）に応じて、問い合わせ先２０５５をクライアントＲとするように記憶内容を更新するつなぎかえ処理を行う（Ｓ６１１３）。

最後に、クライアントＮ３は差分除去後の自己のデータベース検索内容とクライアントＲから受信した差分検索内容により、最新のデータベース内容についての検索結果を得られることになる。

また、それぞれのつなぎかえ処理（Ｓ６１０８、Ｓ６１１１）により、クライアントＮ２，Ｎ３は、最新のデータを有するクライアントＲに次回からは他のクライアントを経由することなくダイレクトに問い合わせを送れるようになる。

[クライアントの動作例]
次に、個々のクライアント４８０１（４８０３）の動作例について説明する。
[クライアントの動作例：検索の場合]

図６２は、本データベースシステムにおいて、あるノード・クライアント４８０３がデータの検索（差分検索）を行うときの動作例を示したフローチャートである。

検索（差分検索）を行う場合、ノード・クライアント４８０３（以下、区別のため起点クライアントと呼ぶ）、より詳しくは接続開始部５００１が問い合わせ先５０２５に記述されたクライアント４８０１（４８０３）（以下、「問い合わせ先クライアント」と称す）との通信を確立する（図略）。

次にこの起点クライアント、より詳しくは差分通知部５００５は、問い合わせ先クライアントに差分通知要求を送信する（Ｓ６２０１）。

次に、起点クライアント、より詳しくはそのつなぎかえ要求部５０１９は、問い合わせ先クライアントにつなぎかえ要求を送信する（Ｓ６２０２）。起点クライアント、より詳しくはそのつなぎかえ処理部５０１７は、データに対して「責任（更新権）」を有するクライアントからつなぎかえ指定が送信されてくるのを待ち受ける（Ｓ６２０３）。

「責任（更新権）」を有するクライアントからつなぎかえ指定を受信すると、起点クライアント、より詳しくはそのつなぎかえ処理部５０１７は、つなぎかえ指定に記述されたクライアントを新たな問い合わせ先クライアントとするように、問い合わせ先５０２５の内容を書き換える処理であるつなぎかえ処理を実行する（Ｓ６２０５）。

また、起点クライアント、より詳しくはその差分通知部５００５は、先に送信した差分通知要求（Ｓ６２０１）に応答する結果を待ち受ける（Ｓ６２０６）。「責任（更新権）」を有するクライアントから前記差分通知要求に対する結果を受信する（Ｓ６２０７）と、起点クライアント、より詳しくはその差分除去部５００５は、受信した結果に基づいてデータベースの４９０５の差分除去を行う（Ｓ６２０８）。

次に、起点クライアント、より詳しくはその差分検索部５００７は、「責任（更新権）」を有するクライアントへ差分検索の要求を送信し（Ｓ６２０９）、「責任（更新権）」を有するクライアントから差分検索の結果を受信する（Ｓ６２１０）。

次に、前述した起点クライアントから差分通知要求、つなぎかえ要求を受信する問い合わせ先クライアントの動作例について説明する。なお、問い合わせ先クライアントは、差分通知、つなぎかえ要求の双方に対応処理するのであるが、ここでは差分通知、つなぎかえ要求の対応を分けて説明する。

［差分通知に対する対応］
図６３は問い合わせ先クライアントの差分通知要求に対する対応処理の一例を示したフローチャートである。まず、問い合わせ先クライアントは差分通知要求を受信する（Ｓ６３０１）。問い合わせ先クライアントは自己の更新権５０２４の内容を参照して、自己が更新権を保有しているか否かを判定する（Ｓ６３０２）。自己が更新権を保有していると判定した場合（Ｓ６３０２、Ｙｅｓ）、この問い合わせ先クライアントは、「責任（更新権）」を有するクライアントであるので、差分通知要求に応答して、差分通知を起点クライアントに送信し（Ｓ６３０３）、処理を終了する。

一方、ステップＳ６３０２において自己が更新権を保有していないと判定した場合（Ｓ６３０２、Ｎｏ）、問い合わせ先クライアントは、自己の問い合わせ先５０２５に記述されたクライアント（区別のため、次段問い合わせ先クライアントと呼ぶ）に対して、起点クライアントから受信した差分通知要求を転送し（６３０４）、処理を終了する。この差分通知要求を転送された次段問い合わせ先クライアントは、同様にステップＳ６３０１からステップＳ６３０４までの処理を実行する。差分通知要求の転送は「責任（更新権）」を有するクライアントに到達するまで繰り返される。

［つなぎかえ要求に対する対応］
次に、問い合わせ先クライアントのつなぎかえ要求に対する応答処理について説明する。図６４は、問い合わせ先クライアントのつなぎかえ要求に対する応答処理を示したフローチャートである。

まず、問い合わせ先クライアントはつなぎかえ要求を受信する（Ｓ６４０１）。問い合わせ先クライアントは自己の更新権５０２４の内容を参照して、自己が更新権を保有しているか否かを判定する（Ｓ６４０２）。自己が更新権を保有していると判定した場合（Ｓ６４０２、Ｙｅｓ）、この問い合わせ先クライアントは、ステップＳ６４０１において受信したつなぎかえ要求に含まれるデータから、ノード１件分のデータを取得する（Ｓ６４０４）。
問い合わせ先クライアントは、取得したノード１件分のデータに基づいて当該ノードについてつなぎ換えを行わせた方が有利になるか否かを判定する（Ｓ６４０５）。有利にならないと判定した場合（Ｓ６４０５、Ｎｏ）、この問い合わせ先クライアントはそのまま処理を終了する。一方、有利になると判定した場合（Ｓ６４０５、Ｙｅｓ）、この問い合わせ先クライアントは、前記取得したノード１件分のデータに対応するクライアントに、自己を問い合わせ先とするようにつなぎかえ処理を行うよう指示するつなぎかえ指定を送信する（Ｓ６４０７）。
次に、この問い合わせ先クライアントはステップＳ６４０１において受信したつなぎかえ要求に含まれる、全てのノード分のデータを処理したか否かを判定する（Ｓ６４０７）。全て処理したと判定した場合（Ｓ６４０７，Ｙｅｓ）、この問い合わせ先クライアントは処理を終了する。一方、全て処理していないと判定した場合（Ｓ６４０７，Ｎｏ）、この問い合わせ先クライアントはステップＳ６４０４に戻り、未処理のノードのデータについてステップＳ６４０４からＳ６４０７の処理を繰り返し行う。
「責任（更新権）」を有するクライアントであるので、つなぎかえ要求に応答して、つなぎかえ指定を起点クライアントに送信し（Ｓ６４０３）、処理を終了する。

一方、ステップＳ６３０２において自己が更新権を保有していないと判定した場合（Ｓ６３０２、Ｎｏ）、問い合わせ先クライアント、より詳しくはその判定部５０２２は起点クライアントから受信しているつなぎかえ要否判定に要するデータ、自己分のつなぎかえ要否判定に要するデータを含むつなぎかえ要求を、自己の問い合わせ先（すなわち、次段問い合わせ先クライアント）に送信するか否かを判定するため、前述の判定条件式を用いて、つなぎかえを行った方が送信データ量削減の観点等から有利であるか否かを判定する（Ｓ６４０４）。

ステップＳ６４０２において、更新権を保有していないと判定した場合（Ｓ６４０２、Ｎｏ）、問い合わせ先クライアント、より詳しくはそのつなぎかえ要求部５０１９は、次段問い合わせ先クライアントにつなぎかえ要求を送信する（Ｓ６４０３）。なお、このつなぎかえ要求には、起点クライアントから受信しているつなぎかえ要否判定に要するデータ、自己分のつなぎかえ要否判定に要するデータが含まれるように構成される。

問い合わせ先クライアント、より詳しくはそのつなぎかえ処理部５０１７は、データに対して「責任（更新権）」を有するクライアントからつなぎかえ指定が送信されてくるのを待ち受ける（Ｓ６４０６）。

「責任（更新権）」を有するクライアントからつなぎかえ指定を受信する（Ｓ６４０７）と、問い合わせクライアント、より詳しくはそのつなぎかえ処理部５０１７は、つなぎかえ指定に記述されたクライアントを新たな問い合わせ先クライアントとするように、問い合わせ先５０２５の内容を書き換える処理である問い合わせ処理を実行する（Ｓ６４０８）。

問い合わせ先クライアントからつなぎかえ要求を送信若しくは転送された次段問い合わせ先クライアントは、同様にステップＳ６４０１からステップＳ６４０８までの処理を実行する。つなぎかえ要求の転送は「責任（更新権）」を有するクライアントに到達するまで繰り返される。

[クライアントの動作例：更新（同期）の場合]
次に、本実施の形態に係るデータベースシステムにおいて、あるノード・クライアント４８０３がデータの更新（同期）を行うときの動作例について述べる。

起点クライアントが更新要求を送信するに先だって、差分通知要求を行うため、更新（同期）の場合におけるつなぎかえ要求の送信、つなぎかえ要求の転送、つなぎかえ要求への応答は、図６２、図６４において説明した処理と同様となるので、ここでは詳細な内容の説明は省略する。

次に、更新要求を受信した問い合わせ先クライアントの動作例について説明する。図６５は、更新要求を受信した問い合わせ先クライアントの動作例を示したフローチャートである。

まず、問い合わせ先クライアントは更新要求を受信する（Ｓ６５０１）。問い合わせ先クライアントは自己の更新権５０２４の内容を参照して、自己が更新権を保有しているか否かを判定する（Ｓ６５０２）。自己が更新権を保有していると判定した場合（Ｓ６４０２、Ｙｅｓ）、この問い合わせ先クライアント、より詳しくは同期送信部５０１２は、「責任（更新権）」を有するクライアントであるので、更新要求に応答して、更新に必要なデータ（差分データ）を起点クライアントに送信し（Ｓ６５０３）、更新権利破棄部５０１５が更新権破棄処理を実行して、更新権５０２４の内容を更新権を保有しないことを示す情報を示すものに書き換え（Ｓ６５０４）、問い合わせ先５０２５の内容を新たに最新のデータベース内容を有することになった起点クライアントを示す情報に書き換え（Ｓ６５０５）、これを持って処理を終了する。

一方、ステップＳ６５０２において自己が更新権を保有していないと判定した場合（Ｓ６５０２、Ｎｏ）、問い合わせ先クライアントは、自己の問い合わせ先５０２５に記述されたクライアント（区別のため、次段問い合わせ先クライアントと呼ぶ）に対して、起点クライアントから受信した更新要求を転送し（Ｓ６５０６）、処理を終了する。この更新要求を転送された次段問い合わせ先クライアントは、同様にステップＳ６５０１からステップＳ６５０６までの処理を実行する。更新要求の転送は「責任（更新権）」を有するクライアントに到達するまで繰り返される。

［第６の実施の形態のまとめ］
（１）本実施の形態は、サーバレスなシステムを構築することを可能とする。
（２）本実施の形態では、クライアント間で検索や更新のための通信をするときコストが発生するが、それを無駄にしないことを可能とする。クライアント間で通信するときに、今後の負担（データベースシステム全体における送信データ量）を減らすデータのやり取りも実施するためである。

[第７の実施の形態]
次に、本発明の第７の実施の形態について説明する。第７の実施の形態は、前述した第６の実施の形態と同様の構成を有するデータベース・システムである。但し、各クライアントは後述する最新保証を実行するための構成をさらに有している点で、第６の実施の形態と異なる。

第７の実施の形態の特徴は、第６の実施の形態の特徴に加えて最新保証を行うデータベース・システムであることにある。「最新保証」とは、データベース・システム内のクライアントにおいて、最新のデータを保持しているクライアントが、そのクライアントを問い合わせ先にしている他のクライアントに対して、データが最新であることを保証する通知を行うことによって、検索要求を抑える処理である。

図６６を参照しながら、最新保証処理の概略を示す。図６６（Ａ）は最新保証前のマスター・クライアントと２つのノード・クライアントの関係を示す図であり、図６６（Ｂ）は最新保証実行時のマスター・クライアントと２つのノード・クライアントの関係を示す図である。今、データベース・システムに３つのクライアントが存在するものとする。クライアントＡはマスター・クライアントであり、クライアントＢ,ＣはクライアントＡを問い合わせ先とするノード・クライアントである。また、クライアントＡのデータベースのバージョンと、クライアントＢ,Ｃにおけるデータベースのバーションは同一になっているものとする。

クライアントＢ,Ｃはデータの検索を行う必要が生じた時、クライアントAに問い合わせを送信することになる（Ｓ６６０１）。このとき、クライアントAのデータベースバージョン(内容)に変更がなければ、この問い合わせは無駄なものである。そこで、第７の実施の形態においては、クライアントＡは、クライアントＢ,Ｃに対してデータベースのバーション(内容）が当該データベース内において最新であることを保証することを通知である最新保証通知を行う（Ｓ６６０２）。

最新保証通知を受信したクライアントＢ,Ｃは自己のデータベースを検索することにより最新データの検索を行うことができることを把握できるため、検索が必要となった場合でも、差分検索要求をクライアントＡに送信することを抑制可能となる。

かかる最新保証を行うことにより、責任を有するノードであるマスター・クライアントに検索問い合わせが集中することを回避することができ、クライアント間での無駄なやり取りを減少させ、データベース・システム内での負荷分散を図ることが可能となる。

なお、上記の例において、クライアントＡの責任が他のクライアントに移転した場合は、クライアントＡはクライアントＢ，Ｃに最新保証を解除する通知を行う。

図６７は、最新保証処理を行わない場合の、データベース内の問い合わせ関係を示した図である。図６７に示す例では、７つのクライアントがデータベースを構成している。クライアント４８０１Ａはマスター・クライアントである。クライアント４８０３Ｂ、４８０３Ｃはクライアント４８０１Ａを問い合わせ先として記憶しているノード・クライアントである。クライアント４８０３Ｄ、４８０３Ｅはクライアント４８０３Ｂを問い合わせ先と記憶しているノード・クライアントである。クライアント４８０３Ｆ、４８０３Ｇはクライアント４８０３Ｃを問い合わせ先と記憶しているノード・クライアントである。図中のクライアントを示す円内に数字を示しているが、この数字はそのクライアントが記憶しているデータベースのバージョンを示している。図６７に示した例では、クライアント４８０１Ａ、４８０３Ｂ、４８０３Ｃのそれぞれがバージョン「５」でありこれがこのデータベース・システム内の最新のデータベースバージョンである。

さて、このデータベース・システム内のクライアント４８０３Ｇがデータベースの検索を行おうとしたものとする。クライアント４８０３Ｇは問い合わせ先をクライアント４８０３Ｃと記憶しているため、問い合わせをクライアント４８０３Ｃに送信する。

問い合わせを受信したクライアント４８０３Ｃは、自己は責任を有するマスター・クライアント４８０１ではないため、問い合わせ先として記憶しているクライアント４８０１Ａに問い合わせを送信する。クライアント４８０１Ａは問い合わせに応じて、クライアント４８０３Ｇに差分結果通知等を送信することになる。

しかし、クライアント４８０３Ｃのデータベースのバージョンとクライアント４８０３Ａのデータベースのバージョンはともに「５」であり、クライアント４８０１Ｃが責任を有するクライアント４８０１Ａに代わって、クライアント４８０１Ｇに差分結果通知等を送信しても、最新のデータベース内容に基づいた正しい検索結果をクライアント４８０１Ｇは得られる。

最新保証処理を行わない場合では、図６７に示したデータベース・システム内では、ノード・クライアント４８０３Ｃ〜４８０３Ｇ各機全部からの差分検索要求がマスター・クライアント４８０１Ａに到達することになる。

図６８は、最新保証処理を行う場合の、データベース内の問い合わせ関係を示した図である。データベースを構成するクライアント、各クライアントの問い合わせ先は図６７に示した例と同様である。ノード・クライアント４８０３Ｂ，４８０３Ｃのそれぞれは、マスター・クライアント４８０１Ａから最新保証通知を受信済みであるとする。

先に上げた図６７の例と同様に、このデータベース・システム内のクライアント４８０３Ｇがデータベースの検索を行おうとしたものとする。クライアント４８０３Ｇは問い合わせ先をクライアント４８０３Ｃと記憶しているため、問い合わせをクライアント４８０３Ｃに送信する。
問い合わせを受信したクライアント４８０３Ｃは、自己は責任を有するマスター・クライアント４８０１Ａではないが、最新保証通知を受信済みであるため、クライアント４８０３Ｃは問い合わせに応じてクライアント４８０３Ｇに差分結果通知等を送信することになる。クライアント４８０３Ｆからの差分要求も同様に、マスター・クライアント４８０１Ａでなく、クライアント４８０３Ｃによって処理される。

同様にクライアント４８０３Ｄ，４８０３Ｅから差分検索要求がクライアント４８０３Ｂに送信された場合にも、クライアント４８０３Ｂはマスター・クライアント４８０１Ａに差分検索要求を送信せずに、問い合わせに応じてクライアント４８０３Ｄ，４８０３Ｅに差分結果通知等を送信することになる。したが、最新保証をおこなわない場合には差分検索要求がマスター・クライアント４８０１Ａに集中したが、最新保証を行う場合には、クライアント４８０３Ｂ、４８０Ｃに分散されて負荷も分散されることになる。

[データベース更新時の最新保証処理]
次に、第７の実施の形態におけるデータベース更新時の最新保証処理について説明する。なお、最新保証処理は、後述する最新保証通知、最新保証切れ通知、最新保証フラグ処理からなる処理をいう。

図６９は、データベース更新時の最新保証処理について説明するための、データベースにおけるクライアントの状態を示す図である。図６９に示す状態は、図６８に示す状態と基本的に同様であり、ノード・クライアント４８０３Ｂ，４８０３Ｃのそれぞれは、マスター・クライアント４８０１Ａと同一バーションのデータベースの記憶内容を有し、かつノード・クライアント４８０３Ｂ，４８０３Ｃのそれぞれは、マスター・クライアント４８０１Ａから最新保証通知を受信済みであるとする。上記状態においてクライアント４８０３Ｇが更新要求を送信し、これに応じたマスター・クライアント４８０１Ａから差分データを受信して最新バージョン「６」となるデータベース内容としたとする。ここでマスター・クライアント４８０１Ａから更新権利がクライアント４８０３Ｇに移り、クライアント４８０３Ｇは新たなマスター・クライアントとなり、マスター・クライアント４８０１Ａは以後ノード・クライアントとして振る舞うことになる。

このクライアント４８０３Ｇのデータベース内容の更新に伴い、クライアント４８０１Ａはクライアント４８０３Ｇのデータベース内容と同期を行い、バージョンを「６」にするとともに前述した第６の実施の形態で行うつなぎかえを行い、問い合わせ先をクライアント４８０３Ｇとする。同様に、更新要求が伝達される経路上に存在したノードであるクライアント４８０３Ｃもクライアント４８０３Ｇのデータベース内容と同期を行い、バージョンを「６」にするとともに前述した第６の実施の形態で行うつなぎかえを行い、問い合わせ先をクライアント４８０３Ｇとする。
なお、この例では、非常に小さいデータ量の更新データを扱ったとし、前掲の[数５]の式に従い、通知のみよりも同期した方が得と判定されたため、更新と同様に最新保証通知時に更新データを加え、同期を実現している。

また、クライアント４８０１Ａは、バージョンが一致しなくなった子ノードであるクライアント４８０３Ｂに最新保証切れを送信する。最新保証切れを受信したクライアント４８０３Ｂは、以後クライアント４８０１Ａに代わって差分検索要求の処理を行わず、差分検索要求を通常通りクライアント４８０１Ａに送信するように動作する。

図７０は、図６９の状態からクライアント４８０３Ｇが新たのマスター・クライアントとなり、つなぎかえにより問い合わせ先が変更されたデータベース・システムの構成を示す。マスター・クライアント４８０３Ｇと同一のデータベースのバージョンを有し、マスター・クライアント４８０３Ｇから最新保証通知を受信しているクライアント４８０１Ａ、４８０３Ｃは差分検索要求を受信した場合、マスター・クライアント４８０３Ｇに代わって差分検索要求に対して結果を送信するように動作する。更新が行われマスター・クライアントの入れ替わりが起こっても、クライアント間での無駄なやり取り(メッセージ送受信)を減少させ、データベース・システム内での負荷分散を図ることが可能となる。

[最新保証の実行要否判断]
第７の実施の形態では、上述の最新保証通知、最新保証切れ等の最新保証処理を行うか否かを、最新保証を行うために必要なデータ送信量が、最新保証を行うことによって減少させることができるデータ送信量より小さいか、という判定に基づいて判断するようにしてもよい。以下に、最新保証処理を行うか否かを判定する方法の具体例を述べる。

クライアント４８０１，４８０３は以下の条件判定式を計算することにより、最新保証処理を判定する。条件判定式が満たされる場合は、最新保証処理を実行すると判定する。
条件判定式は以下の通りである。
(投資) ＜ （更新するまでに検索する回数）×（問い合わせ通信の減る量）
ここで「投資」とは、最新保証を行うために必要なデータ送信量である。「問い合わせ通信」とは、差分検索要求のための通信である。

ここで、「投資」＝２ｄ(１−ｐ)により定まる値を用いる。「ｄ」は最新保証通知に要するデータ送信量、「ｐ」サーバが完全である確率である。「更新するまでに検索する回数」は予測値を用い、「問い合わせ通信の減る量」は前述のｄを用いる。ここでは、更新するまでに検索する回数は属している子供の数に比例し、更新の確率は、全ノード数に比例する。また、更新するまでに検索する回数＝（検索の確率）/（更新の確率）により定まるものと考えられる。

[条件判定式について]
上記条件判定式について説明する。図７１は最新保証処理のコストと効果を説明するための状態遷移図である。
まずコストについて説明する。コストとは、最新保証を行うために必要なデータ送信量である。第７の実施の形態では、状態「最新保証前」から状態「最新保証中」、状態「最新保証後」に状態遷移が起こりうる。状態「最新保証前」から状態「最新保証中」に遷移する場合には、最新保証通知を送信するため、コストとしてデータ送信量ｄが発生する。また、状態「最新保証中」から状態「最新保証後」に遷移する場合には、最新保証切れ通知を送信するため、コストとしてデータ送信量ｄが発生する。よって最新保証を行うためにかかるコストはｄ＋ｄ＝２ｄとなる。

次に、効果について説明する。効果とは、最新保証を行うことによって減少させることができるデータ送信量である。最新保証を行わない場合には１回の検索が生ずるごとにデータ送信量２ｄが発生する。したが、次の更新が行われるまでに検索が行われるごとに２ｄのデータ送信量が発生するところを抑止して、データ送信量の削減を図ることができる。これが最新保証の効果であり、２ｄ×（更新までに検索が発生する回数）と表すことができる。
条件判定式は、コストが効果以下になるかを判定するので、
２ｄ≦２ｄ×（更新までに検索が発生する回数）、すなわち
１≦（更新までに検索が発生する回数）
が満たされれば、最新保証を行うと判定すればよい。

[更新までに検索が発生する回数]
次に、更新までに検索が発生する回数について説明する。
まず、正規化済みの検索確率をＰとし、更新確率を（１−Ｐ）とする。
更新まで行われる検索の回数と、その確率を対応付けて表すと
０回：1-P
１回：P(1-P)
２回：P・P(1-P)
…
これを展開すると
となる。
上記を等比級数の和により
となる。
したがって、
が１より大きければ条件判定式が満たされる。これは検索確率Ｐが更新確率（１−Ｐ）より大きければ最新保証をした方が有利であること意味する。

[具体例１(最新保証をした方がよい場合）]
図７２は、第７の実施の形態にかかるデータベース・システムの一例を示す図である。この例では、最新データを有し、「責任」を有するマスター・クライアント４８０１(図中、Ｒと表示する)、このマスター・クライアント４８０１を問い合わせ先５０２５に記憶しているノード・クライアント４８０３(図中、Ｎ１と表示)、ノード・クライアントＮ１を問い合わせ先５０２５に記憶しているノード・クライアント４８０３(図中、Ｎ２と表示)、ノード・クライアントＮ１を直接、又は間接に問い合わせるノード・クライアント４８０３の集団（ノード・クライアントＮ１の下位ノード集団と呼ぶ）及びノード・クライアントＮ２を直接、又は間接に問い合わせるノード・クライアント４８０３の集団（ノード・クライアントＮ２の下位ノード集団と呼ぶ）がある。また、ノード・クライアントＮ１の下位ノード集団、ノード・クライアントＮ１の下位ノード集団に含まれるノード・クライアント数はともにＣ＝２９とする。

さて、検索確率はある一定期間の検索の頻度、更新確率はある一定期間の検索の頻度に置き換えてよい。よって、更新の確率≦検索の頻度が成立すれば、条件判定式が満たされると判定できる。ここで、検索の頻度は、対象となるノード・クライアントの子ノード(対象となるノードを含む)に比例するので、
検索の頻度＝（子ノードの数）×ｎ×（１−ｐ）
で表すことができる。

上記式におけるｐ、ｎについて以下に述べる。
＜確率pについて＞
マスター・クライアント４８０１のデータが完全である確率をｐとすると、マスター・クライアント４８０１がノード・クライアント４８０３に更新データを確認しなければいけない確率が（１−ｐ）と表せる。具体例を示すと、１日のうち９割は同期できる環境と設定すれば、確率ｐは０．９であり、（１−ｐ）は０．１である。

＜確率ｎについて＞
確率ｎは、１クライアントあたりのある一定期間での検索回数である。平均して、1日あたり0.4回の検索をした場合、確率nは0.4である。

次に、更新の頻度について述べる。
更新の頻度は、全ノードに比例するので、更新の頻度＝（全ノード数）×ｕ×（１−ｐ）と表せる。
以下に、上記式のｐ、ｕについて述べる。ｐは前述と同様にマスター・クライアント４８０１のデータが完全である確率である。確率ｕは１クライアントあたりのある一定期間での更新回数である。平均して、1日あたり0.15回の更新をした場合、確率uは0.15となる。

図７２に示した例を上記２式に当てはめてみる。検索の頻度は（子ノードの数）×ｎ×（１−ｐ）＝(29+1)×0.4×0.1＝1.2である。更新の頻度は（全ノード数）×ｕ×（１−ｐ）＝(29×2+2)×0.15×0.1＝0.9である。
よってこの条件では、更新確率≦検索確率なのでマスター・クライアントＲはノード・クライアントＮ１に対して、最新保証をした方がよいと判定することになる。

[具体例２(最新保証をしない方がよい場合）]
図７３は、第７の実施の形態にかかるデータベース・システムの別の例を示す図である。この例では、最新データを有し、「責任」を有するマスター・クライアント４８０１(図中、Ｒと表示する)、このマスター・クライアント４８０１を問い合わせ先５０２５に記憶しているノード・クライアント４８０３(図中、Ｎ１と表示)、マスター・クライアント４８０１を問い合わせ先５０２５に記憶している別のノード・クライアント４８０３(図中、Ｎ２と表示)、マスター・クライアント４８０１を問い合わせ先５０２５に記憶しているさらに別のノード・クライアント４８０３(図中、Ｎ３と表示)、ノード・クライアントＮ１、Ｎ２，Ｎ３のそれぞれを直接、又は間接に問い合わせるノード・クライアント４８０３の集団（ノード・クライアントＮ１の下位ノード集団、ノード・クライアントＮ２の下位ノード集団、ノード・クライアントＮ３の下位ノード集団と呼ぶ）また、ノード・クライアントＮ１の下位ノード集団、ノード・クライアントＮ２の下位ノード集団、ノード・クライアントＮ３の子ノード集団に含まれるノード・クライアント数はいずれもＣ＝１９とする。

前述の確率ｐ、ｎ、ｕを図７２の場合と同様として、図７３に示した例における条件判定式の成否を検討する。
検索の頻度は（子ノードの数）×ｎ×（１−ｐ）＝(19+1)×0.4×0.1＝0.8である。更新の頻度は（全ノード数）×ｕ×（１−ｐ）＝(19×3+3)×0.15××0.1＝0.9である。よって、更新確率≦検索確率ではないのでマスター・クライアントＲはノード・クライアントＮ１に対して、最新保証をしない方がよいと判定することになる。

[第７の実施態様におけるデータベース・システムの構成例]
次に、第７の実施態様におけるデータベース・システムの構成例について説明する。第７の実施態様におけるデータベース・システムの構成例は、図４８に示した第６の実施の形態におけるデータベース・システムの構成例と同様であり、第７の実施態様における各クライアントの構成も、図４９に示した構成と同様であるので、これらの構成要素の詳細な説明は省略する。

但し、命令制御部４９０３の構成については、異なる点がある。図７４に第７の実施の形態における命令制御部４９０３の機能ブロック図を示して説明する。
第７の実施の形態における命令制御部４９０３は、第６の実施の形態における命令制御部４９０３が有する各構成要素に加えてさらに、差分通知要求部５００Ａ，最新保証フラグ処理部５０１８、最新保証通知部５０２０、最新保証切れ通知部５０２１、及び記憶されうるデータとして最新保証フラグ５０２６を有している点で異なっている。

差分通知要求部５００Ａは、問い合わせ先５００５Ａである他のクライアントに、自己のデータベースと当該他のクライアントのデータベースの差分の通知を求めるメッセージである差分通知要求を送信する機能を有する。差分通知要求部５００５Ａは、本実施の形態の差分通知要求手段に相当する。なお、差分通知部５００５は、本実施の形態の差分通知手段に相当する。

最新保証フラグ処理部５０１８は、最新保証通知又は最新保証切れ通知を受信したときに、最新保証フラグ５０２６の内容を最新保証があることを示す情報、又は最新保証がないことを示す情報に書き換える機能を有する。最新保証フラグ処理部５０１８は本実施の形態の最新保証情報管理手段に相当する。

最新保証通知部５０２０は、自分のデータベース４９０５の内容と同期済みである他のクライアントが記憶しているデータベース４９０５の記憶内容が最新であることを通知する処理を行う。最新保証通知部５０２０は、本実施の形態の最新保証通知手段に相当する。

最新保証切れ通知部５０２１は、自分のデータベース４９０５の内容と同期済みである他のクライアントが記憶しているデータベース４９０５の記憶内容が最新でなくなったことを通知する処理を行う。最新保証切れ通知部５０２１は、本実施の形態の最新保証切れ通知手段に相当する。

最新保証フラグ５０２６は、最新保証を受けているか否かを示す情報である。例えば、「最新保証フラグ」が「１」なら当該クライアントはそのデータベースの内容が最新であるという保証がある状態を示し、「０」であればそのような保証がない状態を示す。最新保証フラグ５０２６は、本実施の形態の最新保証情報に相当する。

なお、第７の実施の形態においては、判定部５０２２は、予測データ５０２７に基づいて、つなぎかえ要求の要否、最新保証通知の要否、最新保証切れの要否の判定を行う。また、判定部５０２２は最新保証フラグの内容によって、他のクライアントから差分通知要求を受信したときに、当該他のクライアントにこの差分通知要求に応答して差分通知を送信するか、或いは問い合わせ先５０２５に定められたクライアントに差分通知要求を送信するかを判定し、判定に基づいて差分通知部５００５に差分通知を送信させ、或いは差分通知要求部５００５Ａに差分通知要求を送信させる。判定部５０２２は、本実施の形態の判定手段に相当する。
その他の構成要素については第６の実施の形態と同様であるので、それらの詳細な説明は省略する。

[第７の実施態様におけるデータベース・システムの動作例１]
次に、第７の実施態様におけるデータベース・システムの動作例を説明する。ここでは、最新保証処理と同時には、つなぎかえ処理を行わない設定であるとして説明する。図７５に本実施の形態に係るデータベース・システムの動作例をシーケンス図として示す。図７５に示す例では、１つのマスター・クライアント４８０１、及び３つのノード・クライアント４８０３（互いを区別するため、マスター・クライアント４８０１をクライアントＲ、３つのノード・クライアント４８０３をクライアントＮ１、クライアントＮ２，クライアントＮ３と呼ぶ）が存在している。但し、後述するクライアントＲによる更新権利取得（Ｓ７５０７）前においては、クライアントＮ１がマスター・クライアントであり、クライアントＲはノード・クライアントとして振る舞っている(図略）。

後述するステップＳ７５０１実行時点において、クライアントＮ３は責任を有するのはクライアントＮ２であると記憶しており、クライアントＮ２は責任を有するのはクライアントＮ１であると記憶しており、実際に責任を有しているのはクライアントＮ１である。

この時点ではマスター・クライアントであるクライアントＮ１は、任意のタイミングで最新保証通知を行うか否かの判定処理を実行する（Ｓ７５０１）。具体的には、クライアントＮ１の判定部５０２２は、予測データ５０２７から必要なデータを読み取り、クライアントＮ２について前述した条件判定式の成立・非成立の判定を実行する。

条件判定式が成立していると判定した場合は、クライアントＮ１はクライアントＮ２に最新保証通知メッセージを送信する（Ｓ７５０２）。具体的には、クライアントＮ１の判定部５０２２が最新保証通知部５０２０に最新保証通知メッセージをクライアントＮ２に送信することを命令し、最新保証通知部５０２０は接続開始部５００１による通信の確立後、最新保証通知メッセージをクライアントＮ２に送信する。

なお、条件判定式が成立していないと判定した場合は、クライアントＮ１、より詳しくはその判定部５０２２は処理を終了し、次の判定実行タイミングの到来まで待機する。

前記最新保証通知メッセージを受信したクライアントＮ２は最新保証フラグ処理を実行する（Ｓ７５０３）。具体的にはクライアントＮ２の最新保証処理部５０１８は、最新保証通知メッセージの受信を検出すると、最新保証フラグ５０２６を最新保証されている状態が開始したことを示す情報に書き換える。

このステップＳ７５０３が実行された後、クライアントＮ３においてデータベース検索の必要性が生じ、クライアントＮ３は差分通知要求を問い合わせ先として記憶しているクライアントＮ２に送信する（Ｓ７５０４）。

差分通知要求を受信したクライアントＮ２は差分通知要求に応答してよいか否か判定するため、まず更新権５０２４を参照して、更新権を有しているか否かを調べ、有していない場合には最新保証フラグ５０２６を参照して最新保証されている状態が開始しているか否かを調べる。いずれかを有している場合には、クライアントＮ２は差分通知要求に応答して差分通知を送信する。

この例では、この時点ではクライアントＮ１が更新権を所有しており、クライアントＮ２は更新権は有していないが、最新保証されている状態が開始しているので、クライアントＮ２は差分通知をクライアントＮ３に送信する（Ｓ７５０５）。

差分通知を受信したクライアントＮ３は、受信した内容を用いて自己のデータベース４９０５の差分除去を実行する（Ｓ７５０６）。
さて、この状態の後、この時点ではノード・クライアントの一つであったクライアントＲが自己のデータベース４９０５の更新を実行し、データベースの内容が本データベース・システム内で最新のバージョンになったものとする。クライアントＲは更新権取得処理を実行する（Ｓ７５０７）。具体的にはクライアントＲの更新権取得部５０１４が更新権５０２４のデータを更新権保有を示す情報に書き換えるとともに、従前更新権を保有していたクライアント(本例ではクライアントＮ１）に、自己が更新権保有したことを通知するメッセージ（以下、更新権保有通知メッセージという）を送信する。

更新権保有通知メッセージを受信したクライアントＮ１は、更新権利破棄処理を実行する（Ｓ７５０８）。具体的には、クライアントＮ１の更新権利破棄部５０１５が更新権保有通知メッセージの受信を検出すると、更新権５０２４のデータ内容を、更新権を保有していないことを示す情報に書き換える。

次に、クライアントＮ１は更新権利破棄の実行をトリガーとして、最新保証切れメッセージをクライアントＮ２に送信する（Ｓ７５０９）。なお、最新保証切れメッセージは当該クライアントが直近の更新権保有後に最新保証通知メッセージを送信したクライアントそれぞれの送信するのであるが、本例ではクライアントＮ２のみ送信対象となる。

最新保証切れメッセージを受信したクライアントＮ２は、最新保証フラグ処理を実行し（Ｓ７５１０）、自己の最新保証フラグ５０２６の記憶内容を、最新保証が終了していることを示す内容に書き換える。これにより、クライアントＮ２は他のクライアントから差分検索要求を受信した場合、問い合わせ先５０２５が示すクライアントに差分検索要求を送信するようになる。

[第７の実施態様におけるデータベース・システムの動作例２]
次に、第７の実施態様におけるデータベース・システムの動作例を説明する。ここでは、最新保証に関する処理と同時につなぎかえ処理を行う設定であるとして説明する。図７６に本実施の形態に係るデータベース・システムの動作例をシーケンス図として示す。

図７６に示す例において、１つのマスター・クライアント４８０１、及び３つのノード・クライアント４８０３（互いを区別するため、マスター・クライアント４８０１をクライアントＲ、３つのノード・クライアント４８０３をクライアントＮ１、クライアントＮ２，クライアントＮ３と呼ぶ）が存在している。但し、後述するクライアントＲによる更新権利取得（Ｓ７６０８）前においては、クライアントＮ１がマスター・クライアントであり、クライアントＲはノード・クライアントとして振る舞っている(図略）。

後述するステップＳ７６０１実行時点において、クライアントＮ３は責任を有するのはクライアントＮ２であると記憶しており、クライアントＮ２は責任を有するのはクライアントＮ１であると記憶しており、実際に責任を有しているのはクライアントＮ１である。

この時点ではマスター・クライアントであるクライアントＮ１は、任意のタイミングで最新保証通知を行うか否かの判定処理を実行する（Ｓ７６０１）。具体的には、クライアントＮ１の判定部５０２２は、予測データ５０２７から必要なデータを読み取り、クライアントＮ２について前述した条件判定式の成立・非成立の判定を実行する。

条件判定式が成立していると判定した場合は、クライアントＮ１はクライアントＮ２に最新保証通知メッセージを送信する（Ｓ７６０２）。具体的には、クライアントＮ１の判定部５０２２が最新保証通知部５０２０に最新保証通知メッセージをクライアントＮ２に送信することを命令し、最新保証通知部５０２０は接続開始部５００１による通信の確立後、最新保証通知メッセージをクライアントＮ２に送信する。

なお、条件判定式が成立していないと判定した場合は、クライアントＮ１、より詳しくはその判定部５０２２は処理を終了し、次の判定実行タイミングの到来まで待機する。

前記最新保証通知メッセージを受信したクライアントＮ２は最新保証フラグ処理を実行する（Ｓ７６０３）。具体的にはクライアントＮ２の最新保証処理部５０１８は、最新保証通知メッセージの受信を検出すると、最新保証フラグ５０２６を最新保証されている状態が開始したことを示す情報に書き換える。

このステップＳ７６０３が実行された後、クライアントＮ３においてデータベース検索の必要性が生じ、クライアントＮ３は差分通知要求及びつなぎかえ要求を問い合わせ先として記憶しているクライアントＮ２に送信する（Ｓ７６０４、Ｓ７６０５）。

差分通知要求及びつなぎかえ要求を受信したクライアントＮ２は差分通知要求に応答してよいか否か判定するため、まず更新権５０２４を参照して、更新権を有しているか否かを調べ、有していない場合には最新保証フラグ５０２６を参照して最新保証されている状態が開始しているか否かを調べる。いずれかを有している場合には、クライアントＮ２は差分通知要求に応答して差分通知を送信する（Ｓ７６０６）。この例では、この時点ではクライアントＮ１が更新権を所有しており、クライアントＮ２は更新権は有していないが、最新保証されている状態が開始しているので、クライアントＮ２は差分通知をクライアントＮ３に送信する（Ｓ７６０６）。差分通知を受信したクライアントＮ３は、受信した内容を用いて自己のデータベース４９０５の差分除去を実行する（Ｓ７６０７）。

また、つなぎかえ要求（Ｓ７６０５）に対しては、クライアントＮ２は第６の実施の形態において説明した通り、マスター・クライアントに到達するまでつなぎかえ要求の転送が繰り返され、マスター・クライアント（この例のこの時点ではクライアントＮ１）にて第６の実施の形態において述べた条件判定式に基づいてつなぎかえの要否が判定され、判定の結果に基づいて必要な場合にはつなぎかえ指示がつなぎかえ要求を発したそれぞれのクライアントに送信される（図略）。

さて、ステップＳ７６０５の後、この時点ではノード・クライアントの一つであったクライアントＲが自己のデータベース４９０５の更新を実行し、データベースの内容が本データベース・システム内で最新のバージョンになったものとする。クライアントＲは更新権取得処理を実行する（Ｓ７６０８）。具体的にはクライアントＲの更新権取得部５０１４が更新権５０２４のデータを更新権保有を示す情報に書き換えるとともに、従前更新権を保有していたクライアント(本例ではクライアントＮ１）に、自己が更新権保有したことを通知するメッセージ（以下、更新権保有通知メッセージという）を送信する。

更新権保有通知メッセージを受信したクライアントＮ１は、更新権利破棄処理を実行する（Ｓ７６０８）とともにつなぎかえ処理を実行する（Ｓ７６１０）。具体的には、クライアントＮ１の更新権利破棄部５０１５が更新権保有通知メッセージの受信を検出すると、更新権５０２４のデータ内容を、更新権を保有していないことを示す情報に書き換える。また、つなぎかえ処理部５０１７が更新権保有通知メッセージの受信を検出すると、問い合わせ先５０２５のデータ内容を、更新権保有通知メッセージの送信元であるクライアントを示す情報に書き換える。

次に、クライアントＮ１は更新権利破棄の実行をトリガーとして、最新保証切れメッセージ及びつなぎかえ指定メッセージをクライアントＮ２に送信する（Ｓ７６１１、Ｓ７６１２）。なお、最新保証切れメッセージは当該クライアントが直近の更新権保有後に最新保証通知メッセージを送信したクライアントそれぞれに送信するのであるが、本例ではクライアントＮ２のみ送信対象となる。

最新保証切れメッセージを受信したクライアントＮ２は、最新保証フラグ処理を実行し（Ｓ７６１３）、自己の最新保証フラグ５０２６の記憶内容を、最新保証が終了していることを示す内容に書き換える。

また、つなぎかえ指定メッセージを受信したクライアントＮ２は、つなぎかえ処理を実行し（Ｓ７６１４）、自己の問い合わせ先５０２５の記憶内容を、つなぎかえ指定メッセージにおいて指定されているクライアント（この例ではクライアントＮ１）を示す内容に書き換える。

上記ステップＳ７６１３、Ｓ７６１４により、クライアントＮ２は他のクライアントから差分検索要求を受信した場合、問い合わせ先５０２５が示すクライアントに差分検索要求を送信するようになる。

[クライアントの動作例]
次に、個々のクライアント４８０１（４８０３）の最新保証処理における動作例について説明する。

[クライアントの動作例：最新保証通知処理]
図７７にクライアント４８０１（４８０３）、より詳しくは最新保証通知部５０２０が実行する最新保証通知処理の一例のフローチャートを示す。
最新保証通知処理において、クライアント４８０１（４８０３）、より詳しくは最新保証通知部５０２０はまず最新保証通知実行トリガーがあるか否かを判定する（Ｓ７７１０）。最新保証通知実行トリガーは、最新保証通知をなすのに適したとき又は条件などを判定できるようなものであれば、どのようなものであってもよく、所定時間の経過であってあってもよいし、他のクライアントから受信した差分検索要求数が所定値をこえたことであってもよい。

最新保証通知実行トリガーがないと判定される場合（Ｓ７７１０，Ｎｏ）は再びＳ７７１０に戻り最新保証通知実行トリガーの発生を待つ。
最新保証通知実行トリガーがないと判定される場合（Ｓ７７１０，Ｎｏ）は、クライアント４８０１（４８０３）、より詳しくは最新保証通知部５０２０は判定部５０２２に第７の実施の形態における条件判定式が成立するか否かを判定させる（Ｓ７７２０）。判定部５０２２は、予測データ５０２７から判定に必要なデータ（例えば、検索の頻度、更新の頻度、など）を読み出し、このデータに基づいて条件判定式が成立するか否かを判定する。

条件判定式が成立すると判定された場合（Ｓ７７２０、Ｙｅｓ）、クライアント４８０１（４８０３）、より詳しくは最新保証通知部５０２０は自己と同一バーションのデータベース内容を有する他のクライアント４８０１（４８０３）に最新保証通知メッセージを送信する（Ｓ７７３０）。条件判定式が成立しないと判定された場合（Ｓ７７２０、Ｙｅｓ）は、クライアント４８０１（４８０３）、より詳しくは最新保証通知部５０２０はなにも行わず再びステップＳ７７１０に戻り最新保証通知実行トリガーの発生を待つ。
以上で、最新保証通知処理の説明を終了する。

[クライアントの動作例：最新保証通知処理]
図７８にクライアント４８０１（４８０３）、より詳しくは最新保証切れ通知部５０２１が実行する最新保証切れ通知処理の一例のフローチャートを示す。
最新保証切れ通知処理において、クライアント４８０１（４８０３）、より詳しくは最新保証切れ通知部５０２０はまず自己が更新権を有しているか否かを更新権５０２４を参照して判定する（Ｓ７８１０）。更新権を有していると判定した場合（Ｓ７８１０、Ｙｅｓ）、従前に発した最新保証は有効な状態なので、なにもせずステップＳ７８１０に戻る。

更新権を有していないと判定した場合（Ｓ７８１０、Ｎｏ）、最新保証切れ通知処理において、クライアント４８０１（４８０３）、より詳しくは最新保証切れ通知部５０２０は、他のクライアントに送信した最新保証通知が存続しているか否かを判定する（Ｓ７８２０）。最新保証通知が存続していないと判定した場合（Ｓ７８２０、Ｎｏ）、取り消すべき最新保証通知は存在していないため、なにもせずステップＳ７８１０に戻る。

一方、最新保証通知が存続していると判定した場合（Ｓ７８２０、Ｙｅｓ）、クライアント４８０１（４８０３）、より詳しくは最新保証切れ通知部５０２０は、存続している最新保証通知の送信先であるクライアントに最新保証切れ通知を送信する（Ｓ７８３０）。
以上で、最新保証切れ通知処理の説明を終了する。

[クライアントの動作例：最新保証フラグ処理]
図７９にクライアント４８０３、より詳しくは最新保証フラグ部５０２１が実行する最新保証切れ通知処理の一例のフローチャートを示す。

最新保証フラグ処理において、クライアント４８０３、より詳しくは最新保証フラグ処理部５０１８はまず通知待ち受けを実行する（Ｓ７９１０）。他のクライアントから通知を受信したか否かを判定（Ｓ７９２０）し、通知を受信していないと判定した場合（Ｓ７９２０，Ｎｏ）は、ステップＳ７９１０に戻り通知待ち受けを継続する。一方、通知を受信したと判定した場合（Ｓ７９２０、Ｙｅｓ）、クライアント４８０３、より詳しくは最新保証フラグ処理部５０１８はその通知が最新保証通知か否かを判定する（Ｓ７９３０）。その通知が最新保証通知であると判定した場合（Ｓ７９３０、Ｙｅｓ）、クライアント４８０３、より詳しくは最新保証フラグ処理部５０１８は最新保証フラグ５０２６の内容を最新保証があることを示す情報に書き換える（Ｓ７９４０）。

一方、その通知が最新保証通知ではないと判定した場合（Ｓ７９３０、Ｎｏ）、クライアント４８０３、より詳しくは最新保証フラグ処理部５０１８はその通知が最新保証切れ通知か否かを判定する（Ｓ７９５０）。その通知が最新保証切れ通知であると判定した場合（Ｓ７９４０、Ｙｅｓ）、クライアント４８０３、より詳しくは最新保証フラグ処理部５０１８は最新保証フラグ５０２６の内容を最新保証がないことを示す情報に書き換える（Ｓ７９６０）。一方、その通知が最新保証切れ通知でないと判定した場合（Ｓ７９４０、Ｙｅｓ）、クライアント４８０３、より詳しくは最新保証フラグ処理部５０１８はステップＳ７９１０に戻り通知待ち受けを続行する。
以上で、最新保証フラグ処理の説明を終了する。

[クライアントの動作例：差分検索通知受信時処理]
図８０にクライアント４８０１（４８０３）が実行する差分検索通知受信時処理の一例のフローチャートを示す。
他のクライアントから差分通知要求を受信すると、クライアント４８０１（４８０３）は自己の更新権５０２４を参照して、更新権を保有しているか否かを判定する（Ｓ８０１０）。更新権を保有していると判定した場合（Ｓ８０１０）、クライアント４８０１（４８０３）は差分通知要求の送信元であるクライアントのバージョンと自己のバージョンの差分を知らせる差分通知を、当該差分通知要求の送信元である他のクライアントに送信し（Ｓ８０３０）、処理を終了する。

一方、更新権を保有していないと判定した場合（Ｓ８０１０、Ｎｏ）、クライアント４８０１（４８０３）は自己の最新保証フラグ５０２６を参照し、最新保証を受けているか否かを判定する（Ｓ８０２０）。最新保証を受けていると判定した場合（Ｓ８０２０、Ｙｅｓ）、クライアント４８０１（４８０３）は差分通知要求の送信元であるクライアントのバージョンと自己のバージョンの差分を知らせる差分通知を、当該差分通知要求の送信元である他のクライアントに送信し（Ｓ８０３０）、処理を終了する。

一方、最新保証を受けていないと判定した場合（Ｓ８０２０、Ｎｏ）、クライアント４８０１（４８０３）は自己の問い合わせ先５０２５を参照し、問い合わせ先５０２５に記憶されたクライアントに対して、差分通知要求を送信する（Ｓ８０４０）。
以上で、差分検索通知受信時処理の説明を終了する。

［第７の実施の形態のまとめ］
本実施の形態によれば、サーバレスなデータベース・システムを構築できるとともに、１クライアントに集中して問い合わせ（差分検索要求）が発生することのないように、処理の負荷を分散を図ることが可能なデータベース・システムを提供できる。
［備考］
上記第１から第７の実施の形態は、いずれか２以上の実施の形態を適宜選択し、それらを組み合わせても、本発明の実施の形態の範囲内であり、発明の一態様として成立する。

４８００…データベース・システム
４８０１…マスター・クライアント
４８０３…ノード・クライアント
４９０３…命令制御部
４８０５…データベース
５０２０…最新保証通知部
５０２１…最新保証切れ通知部
５０１８…最新保証フラグ部
５０２２…判定部
５０２６…最新保証フラグ
５０２７…予測データ

Claims (5)

1. 自己が最新のデータベースの内容を保有しているか否かを示す情報である更新権と、差分検索又はデータベースの同期の相手となる他のクライアントを特定する情報である問い合わせ先と、自己のデータベースの内容がデータベース・システム内で最新であるか否かを示す情報である最新保証情報を記憶する記憶手段と、
   前記更新権が自己が更新権を有していること示している場合、自己のデータベースと同一のバージョンであるデータベースを有する他のクライアントに、そのデータベースの内容が最新であることが保証された状態であることを通知する最新保証通知を送信する最新保証通知手段と、
   前記更新権の内容が自己が更新権を有していることを示す情報から自己が更新権を有していないこと示している情報に書き換えられた場合、前記最新保証通知を送信した他のクライアントに、そのデータベースの内容が最新であることが保証されない状態であること通知する最新保証切れ通知を送信する最新保証切れ通知手段と、
   前記最新保証通知を受信した場合前記最新保証情報の内容をそのデータベースの内容が最新であることが保証された状態を示す情報に書き換え、前記最新保証切れ通知を受信した場合前記最新保証情報の内容をそのデータベースの内容が最新であることが保証されない状態であることを示す情報に書き換える最新保証情報管理手段と、
   前記問い合わせ先に差分通知要求を送信する差分通知要求手段と、
   自己のデータベースと当該他のクライアントのデータベースの差分を通知する差分通知を生成し、差分通知を当該他のクライアントに送信する差分通知手段と、
   他のクライアントから差分通知要求を受信した場合、前記最新保証情報の内容がそのデータベースの内容が最新であることが保証された状態を示す情報であるときには前記差分通知手段に差分通知を当該他のクライアントに送信させ、前記最新保証情報の内容をそのデータベースの内容が最新であることが保証されない状態であることを示す情報であるときには、前記差分通知手段に前記問い合わせ先に宛てて差分通知要求を送信させる判定手段と
   を有することを特徴とするクライアント。
2. 前記判定手段は、最新保証を行うために必要なデータ送信量が、最新保証を行うことによって減少させることができるデータ送信量以下であるか否かを判定し、最新保証を行うために必要なデータ送信量が、最新保証を行うことによって減少させることができるデータ送信量以下である場合に、前記最新保証通知手段に最新保証通知の送信を行わせる
   ことを特徴とする、請求項１に記載のクライアント。
3. 前記判定手段は、正規化済みの検索確率Ｐが更新確率（１−Ｐ）以上であれば、最新保証を行うために必要なデータ送信量が、最新保証を行うことによって減少させることができるデータ送信量以下であると判定する
   ことを特徴とする、請求項２に記載のクライアント。
4. 前記判定手段は、前記検索確率Ｐとしてある一定期間の検索の頻度を用い、前記更新確率（１−Ｐ）として更新の頻度を用いて、正規化済みの検索確率Ｐが更新確率（１−Ｐ）以上であるか否かを判定する
   ことを特徴とする、請求項３に記載のクライアント。
5. 前記請求項１から４までのいずれかに記載の複数のクライアントを有するデータベース・システム。