(57)【要約】【課題】ネットワーク環境が十分でなくても、少ない通信量でサーバの処理量が少ない検索システムおよび検索方法を提供する。【解決手段】データベースを備え、データの変更履歴をバージョンで管理している情報管理装置と、通信回線網を介して前記情報管理装置と接続され、情報管理装置に同期して取得したデータとバージョンで構成されるデータベースを備えた情報端末装置とから成るクライアントサーバ型システムの検索システムであって、情報管理装置では、情報端末装置からの検索要求に対し、情報端末装置とのデータの差分をバージョンの違いで把握して、該差分データに対する検索のみを実行し、情報端末装置に検索結果を送信する。【選択図】図１
2010282360.tif 000002
【特許請求の範囲】
【請求項１】
データベースを備え、データの変更履歴をバージョンで管理している情報管理装置と、通信回線網を介して前記情報管理装置と接続され、前記情報管理装置に同期して取得したデータとバージョンで構成されるデータベースを備えた情報端末装置とから成るクライアントサーバ型システムの検索システムであって、
前記情報管理装置では、前記情報端末装置からの検索要求に対し、前記情報端末装置とのデータの差分をバージョンの違いで把握して、該差分データに対する検索のみを実行し、前記情報端末装置に検索結果を送信することを特徴とする検索システム。
【請求項２】
前記変更履歴は、バージョンとデータＩＤの組によって、データの差分を管理していることを特徴とする請求項１記載の検索システム。
【請求項３】
前記バージョンは、前記情報管理装置側で、一意に発行され、データの変更が行われる毎にバージョンアップすることを特徴とする請求項１または２記載の検索システム。
【請求項４】
前記情報端末装置は、更新もしくは削除によって前記情報管理装置側のデータベースから既に変更された差分データのデータＩＤを受け取って、自己のデータベースから該データを削除した後に、検索を実行することを特徴とする請求項１乃至３のいずれか１項に記載の検索システム。
【請求項５】
前記変更履歴に同じデータＩＤが存在している場合に、最新の変更に纏めることを特徴とする請求項１乃至４のいずれか１項に記載の検索システム。
【請求項６】
前記変更履歴が一定値を越える場合には、最も古い差分データから削除していくことを特徴とする請求項１乃至５のいずれか１項に記載の検索システム。
【請求項７】
前記情報管理装置は、前記差分データの把握可能範囲外であれば、前記差分データに対する検索を行わないことを特徴とする請求項１乃至６のいずれか１項に記載の検索システム。
【請求項８】
前記データベースは階層化されており、同じ階層に属するデータの変更が一定値以上であれば、前記変更履歴をより上位概念で纏めなおすことを特徴とする請求項１乃至７のいずれか１項に記載の検索システム。
【請求項９】
前記情報端末装置におけるバージョンの管理は、前記情報管理装置からデータＩＤを受信し、削除のみの変更が確認できた場合あるいは差分データを受信した場合に、バージョンアップすることを特徴とする請求項１乃至８のいずれか１項に記載の検索システム。
【請求項１０】
前記情報管理装置において、差分データと差分検索の結果のデータサイズを比較し、差分データが小さければ、該差分データを前記情報端末装置に送信して、前記情報管理装置と記情報端末装置のデータベース間で同じデータを保有するように同期させることを特徴とする請求項１乃至９のいずれか１項に記載の検索システム。
【請求項１１】
前記差分データと差分検索の結果のデータサイズの比較は、前記バージョンごとのデータでトータルして実行することを特徴とする請求項１０記載の検索システム。
【請求項１２】
前記情報端末装置は、前記情報管理装置との通信回線網の環境に応じて、データベースの同期と前記情報管理装置に対する前記差分データについての検索要求とを使い分けることを特徴とする請求項１乃至１１のいずれか１項に記載の検索システム。
【請求項１３】
データベースを備え、データの変更履歴をバージョンで管理している情報管理装置と、通信回線網を介して前記情報管理装置と接続され、前記情報管理装置に同期して取得したデータとバージョンで構成されるデータベースを備えた情報端末装置とから成るクライアントサーバ型システムにおける検索方法であって、
前記情報端末装置は、前記情報管理装置のデータベースと同期したときのバージョン情報を前記情報管理装置に送信し、
前記情報端末装置は、前記情報管理装置とのバージョンの違いに基づいて一定の削除データ情報を前記情報管理装置から受信し、
前記情報端末装置は、前記削除データ情報にもとづいて、前記一定の削除データをデータベースから削除し、
前記情報管理装置は、バージョンの違いに基づいて把握される差分データについて検索を実行し、
前記情報端末装置は、前記情報管理装置から前記差分データについての検索結果を受け取ると共に、前記一定のデータ削除後のデータベースに対して、検索を実行することを特徴とする検索方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、検索システムに関し、特にクライアントサーバ型データベースにおける検索システムおよび検索方法に関する。
【背景技術】
【０００２】
最近、家電機器等において、組込み機器製品が高機能化し、機器自体がサーバになることが求められている。一方、サーバを利用するクライアント機器は、サーバ機器同様もしくはそれ以上の性能を有することが多いが、それら機器を取り巻くネットワーク環境においては、まだまだ十分とはいえない。クライアント機器は高性能であるが、サーバ機器はさほど高性能でなく、ネットワーク環境は低水準にあるのが、現状である。
【０００３】
ネットワーク環境が高速かつ安価な時には、クライアント機器とサーバ間で、データベースの保有データを共通化するために、同期をとるのが望ましい。同期をとる際、例えば有線の利用が可能な状況では、通信上の問題は生じないが、クライアント機器がサーバから遠く離れている場合には、通信費用やトラフィック等の問題がネックとなる。
【０００４】
サーバの処理量を減らすデータベースの更新方法が提案されている（例えば、特許文献１参照。）。これは、クライアントの独自性を確保しつつ、サーバによる高速なバージョンアップを実現するもので、アップデート処理を内容とする論理コピーと物理コピー（ｍｅｍｃｐｙ）の差を利用したものである。
【０００５】
また、データベースの更新のための同期量を削減する為の工夫として、差分同期をとるＳＱＬ Ａｎｙｗｈｅｒｅ／Ｕｌｔｒａ Ｒｉｇｈｔがよく知られている(例えば、非特許文献１参照。）。
【０００６】
これらは、完全同期に対する工夫であり、どのデータを同期対象とするか指定可能とし、例えばテーブル単位で、同期対象テーブルの指定が可能である。また、更新時の複数クライアントからのデータベースの更新の衝突において、解決ルールを記述することにより、競合を解決するものである。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−２０８７３号公報
【非特許文献】
【０００８】
【非特許文献１】RDBMSパッケージの最新版「SQL Anywhere 10」日本語版の発売2007/05/10 20:05 :<ＵＲＬ: http://codezine.jp/article/detail/1328?p=1/>
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかし、最近では、クライアントとなる機器は、携帯電話や携帯プレーヤの高性能化、ＵＭＰＣの登場によって、データベース機能を所有することが多く、非常に高性能となっているのに対し、サーバとなる機器に高性能を求めることは難しく、ネットワーク環境も十分ではない場合には対応できていない。
【００１０】
そこで、本発明は、上記の問題に鑑みてなされたもので、ネットワーク環境が十分でなくても、少ない通信量でサーバの処理量が少ない検索システムおよび検索方法を提供するものである。
【課題を解決するための手段】
【００１１】
本発明の一態様によれば、データベースを備え、データの変更履歴をバージョンで管理している情報管理装置と、通信回線網を介して前記情報管理装置と接続され、前記情報管理装置に同期して取得したデータとバージョンで構成されるデータベースを備えた情報端末装置とから成るクライアントサーバ型システムの検索システムであって、前記情報管理装置では、前記情報端末装置からの検索要求に対し、前記情報端末装置とのデータの差分をバージョンの違いで把握して、該差分データに対する検索のみを実行し、前記情報端末装置に検索結果を送信することを特徴とする検索システムが提供される。
【００１２】
また、本発明の別の一態様によれば、データベースを備え、データの変更履歴をバージョンで管理している情報管理装置と、通信回線網を介して前記情報管理装置と接続され、前記情報管理装置に同期して取得したデータとバージョンで構成されるデータベースを備えた情報端末装置とから成るクライアントサーバ型システムにおける検索方法であって、前記情報端末装置は、前記情報管理装置のデータベースと同期したときのバージョン情報を前記情報管理装置に送信し、前記情報端末装置は、前記情報管理装置とのバージョンの違いに基づいて一定の削除データ情報を前記情報管理装置から受信し、前記情報端末装置は、前記削除データ情報にもとづいて、前記一定の削除データをデータベースから削除し、前記情報管理装置は、バージョンの違いに基づいて把握される差分データについて検索を実行し、前記情報端末装置は、前記情報管理装置から前記差分データについての検索結果を受け取ると共に、前記一定のデータ削除後のデータベースに対して、検索を実行することを特徴とする検索方法が提供される。
【発明の効果】
【００１３】
本発明によれば、ネットワーク環境が十分でなくても、クライアント機器とサーバ間の通信量が少なくでき、サーバがクライアント機器をケアするための処理量が少なくできるので、通信費用を低廉化でき、サーバ機器を専用機器でなくとも検索システムを構築できる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図である。
【図２】本発明の実施形態に係るクライアントサーバシステムの機能ブロック図である。
【図３】第１の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。
【図４】情報端末装置の情報管理装置に対する要求処理の流れを示すフローチャートである。
【図５】情報管理装置のユーザである情報端末装置の更新要求処理の流れを示すフローチャートである。
【図６】データベースの構造(中身）を模式化した図である。
【図７】データ量の比較を模式化した図である。
【図８】データ量の比較を模式化した図である。
【図９】データ量の比較を模式化した図である。
【図１０】データ量の比較を模式化した図である。
【図１１】変更履歴の追加がなされた場合のデータベースの構造（中身）の変化を例示する図である。
【図１２】変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。
【図１３】同期処理におけるデータベースの構造（中身）の変化を例示する図である。
【図１４】無効化処理におけるデータベースの構造（中身）の変化を例示する図である。
【図１５】探索要求時におけるデータベースの構造（中身）の変化を例示する図である。
【図１６】探索実行におけるデータベースの構造（中身）の変化を例示する図である。
【図１７】情報管理装置側における差分把握処理の流れを示すフローチャートである。
【図１８】情報端末装置側における差分除去処理の流れを示すフローチャートである。
【図１９】情報端末装置側における差分検索処理の流れを示すフローチャートである。
【図２０】情報管理装置における差分検索処理の流れを示すフローチャートである。
【図２１】変更履歴を用いた差分データからの検索処理を説明する図である。
【図２２】第２の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。
【図２３】変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。
【図２４】変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。
【図２５】変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。
【図２６】更新要求を受けつけた後の変更履歴処理全体の流れを示すフローチャートである。
【図２７】第３の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。
【図２８】変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。
【図２９】変更履歴の上位概念によるまとめ処理の流れを示すフローチャートである。
【図３０】第４の実施形態に係るクライアントサーバ型検索システムを説明する図である。
【図３１】情報管理装置における差分検索処理の流れを示すフローチャートである。
【図３２】第５の実施形態に係るクライアントサーバ型検索システムを説明する図である。
【図３３】情報管理装置における差分検索処理の流れを示すフローチャートである。
【図３４】送信データの決定処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明の一実施の形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１６】
本発明は、完全同期やサーバ全問い合わせに比べて格段に小さな通信量で最新のデータを検索でき、サーバの処理量が少なく、低スペックの機器でもサーバになることができ、サーバ費用を安く抑えることができる、検索システムを得るものである。
【００１７】
図1は、本発明の実施形態に係るクライアントサーバシステムの構成例を示す概念図である。図１に示すように、クライアントサーバシステム１００は、サーバとなる情報管理装置２と、例えばインターネット網あるいは無線通信網３でクライアント機器となる情報端末装置１とから構成されている。情報管理装置（以下の説明では、サーバとも称する）２は、図１に示すように、データベース２４に接続されている。データベース２４は、都度、更新され、現在のバージョンと変更履歴が管理されている。情報管理装置２は、専用機器である必要は無い。所謂、家電機器と称される機器であってもネットワーク網に繋がり、バージョンの管理ができてサーバ機能を果たすものであればよい。さらに変更履歴は、各バージョンとそのバージョンで対象となるデータのＩＤとで把握されるようになっている。これらの詳細については、後述する。
【００１８】
情報端末装置（以下の説明では、クライアントとも称する）１は、データベース機能を備えるものであれば、携帯電話や携帯プレーヤが好適である。所謂、ウルトラモバイルＰＣと称されるものである。図１に示すように、各情報端末装置１も、それぞれデータベース１４に接続されているが、データベース１４は、情報管理装置２のデータベース２４と同期したときのバージョンとなっている。
【００１９】
図２は、本発明の実施形態に係るクライアントサーバシステム１００の機能ブロック図である。情報管理装置２は、接続部２１とデータベース２４を備え、情報端末装置１の要求を受け、結果を送信する。接続部２１は、インターネット網を介して、情報端末装置１と通信をする。情報端末装置１は、ユーザインターフェース１０と接続部１１及びデータベース１４を備える。ユーザインターフェース１０は、ユーザの要求を受け、結果を表示するものである。接続部１１は、インターネット網を介して、情報管理装置２と通信をする。
【００２０】
更に、情報管理装置２は、命令制御部２２とSQL実行部２３を有している。命令制御部２２は、情報端末装置１の要求に応じて、SQL実行部２３や接続部２１に命令を出し、結果をユーザインターフェース１０に表示する。命令としては、接続受付、差分通知、SQL受付、結果送信、同期送信、接続停止がある。SQL実行部２３は、データベース２４に対する命令であるSQL文を用いて、命令制御部２２からの要求にしたがってデータベース２４への操作や定義づけを行うものである。データベース２４は、情報端末装置１から操作によって追加・変更・削除されたデータ２４１と変更履歴２４３とバージョン２４２を保有する。更に、情報端末装置１は、命令制御部１２とSQL実行部１３を有している。命令制御部１２は、ユーザインターフェース１０の要求に応じて、SQL実行部１３や接続部１１に命令を出し、結果をユーザインターフェース１０に表示する。命令としては、接続開始、差分除去、差分検索、結果取得、同期受信、接続終了がある。詳細は後述する。SQL実行部１３は、データベース１４に対する命令であるSQL文を用いて、命令制御部１２からの要求にしたがってデータベース１４への操作を行うものである。データベース１４は、情報管理装置２と同期して取得したデータ１４１とバージョン１４２を保有する。本実施形態で使用する用語は、特にことわりのない場合、以下の意味で理解する。「同期」とは、サーバとクライアント機器との間で、データベース内のデータを共有している状態、もしくは共有化するための処理を意味する。「差分把握」とは、クライアントとサーバのデータの差分を互いのバージョンから把握し、検索処理において重複したデータを検索しないようにすることである。「差分検索」とは、差分データ、すなわち同期がとれていないデータに対する検索をいい、サーバが実行するものである。因みに、差分があるかどうか検索するわけではない。「変更履歴」とは、データベース内のデータについて変更履歴で変更した差分を管理する。変更履歴は、「バージョン」と「データＩＤ」の組を持っている。「バージョン」とは、サーバ側で一意に発行する数字で、データベース内のデータについて変更が行われたらバージョンが１つあがる。本実施形態において「バージョン」は、「差分把握」および「差分検索」を簡単にする為の仕組みである。
【００２１】
以下、いくつかの実施形態に分けて説明する。
【００２２】
（第１の実施形態）
図３は、第１の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。クライアント機器である情報端末装置１はサーバである情報管理装置２において、データベースの更新が行われると、現在のバージョンに対して１つインクリメント（バージョンを＋１する）とされる。更新の内容は変更履歴として管理される。変更履歴は、バージョンと対象となるデータのＩＤから成り立っている。更新に併せて、差分把握可能範囲が設定される。この差分把握可能範囲は、言わば、差分検索が可能な範囲を意味する。極端に古いバージョンのデータベースしか保持していないクライアント機器をケアする場合に対応するためのものである。クライアント機器が自ら保有しているデータベースに対して検索を行う際に、既にサーバ側ではデータベースが更新された結果、削除あるいは変更済みのデータが未だ存在している可能性がある。これら削除あるいは変更済みのデータに対して検索を行うことは全く無意味である。そこで、クライアント機器が自ら保有しているデータベースに対して検索を行う前に、クライアント機器において、該当データの「無効化処理」を行う。「無効化処理」は、サーバで「差分把握」を行い、クライアント機器はサーバから該当するデータＩＤを受け取って「無効化処理」をする。「差分検索」では、情報管理装置と情報端末装置間で、それぞれのデータベースのデータに差分が存在するか否か問い合わせを行う。情報管理装置は「変更履歴」から差分データについて検索して、情報端末装置に検索結果を送信する。
【００２３】
図４は、上記のように構成された検索システムにおけるユーザである情報端末装置の情報管理装置に対する要求処理の流れを示すフローチャートである。まず、情報管理装置は情報端末装置からの接続処理を行う（ステップＳ４１）。情報管理装置は、処理がまだあるか否かを判断する（ステップＳ４２）。処理がなければ、情報端末装置との接続を解除する接断処理を実行する（ステップＳ４６）。処理があれば（ＹＥＳならば）、更新処理か否かを判断する（ステップＳ４３）。ＹＥＳならば、更新処理を実行する（ステップＳ４４）。ＮＯであれば、検索処理を実行する（ステップＳ４５）。更新処理あるいは検索処理の実行後は、ステップＳ４２に戻る。
【００２４】
図５は、情報管理装置のユーザである情報端末装置の更新要求処理の流れを示すフローチャートである。情報管理装置は情報端末装置からデータの更新要求を受付、更新処理を実行する（ステップＳ５１）。更新に伴い、情報管理装置は変更履歴を更新する（ステップＳ５２）。データの更新要求に対する結果が返却され（ステップＳ５３）、更新完了が情報管理装置から情報端末装置に返される。
【００２５】
図６は、データベースの構造(中身）を模式化した図である。図６に示すデータベースは、“Ｔａｂｌｅ”、“Ｐａｇｅ”、“ｎｏｄｅ”と階層化されている。例えば、図書館に収蔵されている“本”のデータベースを考えると、“Ｔａｂｌｅ”は“市立図書館”であり、“Ｐａｇｅ”は“本棚”であり、“ｎｏｄｅ”は個々の“本”に該当する。いま、サーバのデータベースが更新され、バージョンは“３”となり、当該更新によって、“ｎｏｄｅ４”が“Ｐａｇｅ Ｂ”の本棚から、取り除かれた。クライアントのバージョンは“１”であり、サーバのバージョンとは一致していない。
【００２６】
このような状況のもとで、データの検索処理の流れについて説明する。まず、クライアント機器がサーバに対して、現在のバージョンの問い合わせを行う。バージョンの問い合わせを受けたサーバは変更履歴を確認し、変更したノードを探索する。すると、サーバはバージョン３となっており、“ｎｏｄｅ４”が変更されているので、クライアント機器に対して、差分把握として“ｎｏｄｅ４”が削除されているデータであることを知らせる。“Ｐａｇｅ Ｂ”との差分把握を受け取ったクライアント機器は、自らのデータベースから“ｎｏｄｅ４”に対して無効化する。クライアント機器は、無効処理後のデータベースについて全件探索を行う。一方、サーバでは、クライアント機器のバージョン１との差分データである“ｎｏｄｅ４”に対して全件探索、すなわち“ｎｏｄｅ４”に対して検索条件を満たすかどうかを判定する差分検索を行う。この差分検索の結果を受領したクライアント機器は、最新のデータベースに対する検索結果を得ることができる。
【００２７】
最新のデータについて検索を行うには、サーバおよびクライアント機器間で、必ず通信が必要である。差分把握、差分検索によれば、完全同期やサーバ全問い合わせに比べて格段に小さな通信量で、最新のデータに対する検索が実現できる。一般的に、完全同期データ量≧差分検索結果データ量であり、かつ、全件検索結果データ量≧差分検索結果データ量であることによる。これら、データ量の比較を模式化したものを図７乃至図１０に示す。図７は、サーバとクライアント機器が近距離に位置し、しかも両者間の通信環境が高速通信を行える状況であることを例示している。この場合には、両者のデータベースの更新は、完全同期させるのが好適である。尚、差分同期であっても支障はないといえる。図８は、クライアント機器では検索せずにサーバに検索を委ねる、全問い合わせの状況であることを例示している。この場合には、サーバは１Ｇバイトのデータ容量のデータベースに対して検索を実行し、１Ｍバイトの検索結果を得ている。したがって、ヒット率：ｈ＝０．１％となる。ここでは、検索結果がそのまま、クライアント機器に送られるが、通信容量はさほど大きくないので、低速通信であっても支障は無いといえる。図９は、サーバとクライアント機器との間で、差分データについて同期をとることを例示している。サーバのデータベースが更新された結果、更新前後の差分データが１Ｍバイトである状況を例示している。１Ｍバイトの差分データの更新前のデータベースに対する差分割合は０．１％となる。１Ｍバイトの差分データは、通信容量としてはさほど大きくないので、低速通信であっても支障は無いといえる。クライアント機器は、受け取った１Ｍバイトの差分データを加えた１Ｇバイトのデータベースに対して検索を実行し、１Ｍバイトの検索結果を得ている。次に、図１０は、差分検索を例示している。サーバからクライアント機器に対して差分ＩＤ群として１００バイトが送られる。この差分ＩＤ群とは、無効化処理すべきデータのＩＤのまとまりを意味している。さらに、サーバは、変更履歴に基づいて差分データ１Ｍバイトを抽出し、クライアント機器のために差分検索を実行する。得られた１Ｋバイト差分検索の結果は、クライアント機器に送られる。一方、クライアント機器は、差分ＩＤ群に基づいて自己のデータベースを更新して、検索を実行する。クライアント機器は、差分検索の結果１Ｋバイトと併せて、１Ｍバイトの検索結果を得ている。例えば、１つのデータ長が４０００ビット、データＩＤ長が４ビットとすると、あるＩＤを特定するためには、１／１０００の情報量で済むことになる。したがって、差分ＩＤ群および差分検索結果のデータ容量は、極めて少ない量となるから、低速通信であっても何等支障は無く、特に１つのデータが大きく、差分割合が少ない時に好適である。
【００２８】
次に、上記した処理に伴い、データベースの構造（中身）がどのように変化していくか、図を用いて例示する。図１１は、変更履歴の追加がなされた場合のデータベースの構造（中身）の変化を例示する。クライアント機器がデータベースを保有しており、同期させる場合の処理である。いま、サーバのデータベースに対して、”Ｐａｇｅ Ｂ“に“ｎｏｄｅ４”を追加する変更が行われた。かかる変更に伴い、変更履歴欄には、最新のバージョンは“３”から”Ｖｅｒ＝４”に、その変更内容として、“ｎｏｄｅ４”が更新されている。図１２は、変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。図１２に示すように、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている。そして、バージョンを＋１している。  図１３は、同期処理におけるデータベースの構造（中身）の変化を例示する。サーバのバージョンは“４”であるのに対し、クライアント機器のバージョンは“３”である。そこで、変更履歴から更新後の“ｎｏｄｅ４”のデータが、サーバのバージョン情報と共に、クライアント機器に送られる。クライアント機器では、“ｎｏｄｅ４”の内容を更新する。
【００２９】
図１４は、無効化処理におけるデータベースの構造（中身）の変化を例示する。クライアント機器のバージョンは“３”である。サーバは、変更履歴から自身の現在のバージョン“４”と、その変更内容である“ｎｏｄｅ４”の削除を確認する。サーバのバージョン情報および差分ＩＤ群情報は、クライアント機器に送られる。クライアント機器では、保有するデータベースに対してバージョン“４”の内容を反映させるために、バージョン“３”との差分である“ｎｏｄｅ４”を削除する。
【００３０】
図１５は、探索要求時におけるデータベースの構造（中身）の変化を例示する。サーバのデータベースに対するＳＥＬＥＣＴは、ＳＥＬＥＣＴ文 ＷＨＥＲＥ Ｖｅｒ＞３ ＡＮＤ Ｖｅｒ≦４となる。バージョン“３”でのデータベースに対する探索（検索）は、クライアント機器自身に割り当て、バージョン“４”を反映した探索（検索）は、サーバに割り当てられる。
【００３１】
図１６は、探索実行におけるデータベースの構造（中身）の変化を例示する。図１６に示すように、サーバのデータベースに対して、ＳＥＬＥＣＴ文 ＷＨＥＲＥ Ｖｅｒ＞３ ＡＮＤ Ｖｅｒ≦４で表わされる命令が発せられると、バージョン“４”の変更内容である“ｎｏｄｅ４”に対して検索を実行し、検索結果Ｓをクライアント機器に送る。一方、クライアント機器は、ＳＥＬＥＣＴ文によりバージョン“３”でのデータベースに対する検索を実行し、検索結果Ｃを得る。したがって、検索結果Ｃ＋検索結果Ｓが、最新のデータに対する検索結果として得ることができる。
【００３２】
次に、検索システムにおける情報管理装置と情報端末装置で実行される各処理の流れについて詳述する。
【００３３】
図１７は、情報管理装置側における差分把握処理の流れを示すフローチャートである。
【００３４】
まず、情報端末装置のバージョン：Ｖｃを取得する（ステップＳ１７０１)。次いで、情報管理装置のバージョン：Ｖｓを取得する（ステップＳ１７０２)。次いで、両者のバージョンを比較する（ステップＳ１７０３)。Ｖｃ＝Ｖｓであれば、Ｖｓと結果：Ｒ＝「変更データ無し」を情報端末装置に通知する（ステップＳ１７０５)。Ｖｃ＝Ｖｓでなければ、変更履歴から差分把握可能範囲：Ｖａを取得する（ステップＳ１７０４)。次いで、Ｖａ＞Ｖｃかどうかを判断する（ステップＳ１７０６)。Ｖａ＞Ｖｃであれば、結果：Ｒ＝「差分検索不可」を情報端末装置に通知する（ステップＳ１７１１)。Ｖａ＞Ｖｃでなければ、データベースから変更履歴を使い、差分ＩＤsを作成する（ステップＳ１７０７)。次いで、変更が削除のみかどうかを判断する（ステップＳ１７０８)。変更が削除のみでなければ、Ｖｓと差分ＩＤ：ＩＤsを情報端末装置に通知する（ステップＳ１７０９)。変更が削除のみであれば、結果：Ｒ＝「差分削除のみ」Ｖｓと差分ＩＤ：ＩＤｓを情報端末装置に通知する（ステップＳ１７１０)。
【００３５】
図１８は、情報端末装置側における差分除去処理の流れを示すフローチャートである。まず、情報管理装置の差分ＩＤの結果：Ｒを取得する（ステップＳ１８０１)。次いで、Ｒ＝「差分削除のみ」かどうかを判断する（ステップＳ１８０２)。Ｒ＝「差分削除のみ」であれば、差分ＩＤｓを取得する（ステップＳ１８０３)。続いて、ＩＤｓに対応するデータをデータベースから削除する（ステップＳ１８０４)。続いて、サーバフラグ＝ＯＦＦと設定する（ステップＳ１８０５)。このサーバフラグは、サーバに検索要求をする必要があるか否かを示すもので、サーバに検索要求をする場合、ＯＮとなる。続いて、Ｖｃ＝Ｖｓとする（ステップＳ１８０６)。そして、差分把握完了フラグ＝ＯＮとする（ステップＳ１８０７)。一方、Ｒ＝「差分削除のみ」でない場合には、まず、Ｒ＝「差分検索不可」かどうかを判断する（ステップＳ１８０８)。Ｒ＝「差分検索不可」でなければ、続いて、Ｒ＝「変更データ無し」かどうかを判断する（ステップＳ１８０９)。Ｒ＝「変更データ無し」でなければ、差分ＩＤｓを取得する（ステップＳ１８１０)。続いて、ＩＤsに対応するデータをデータベースから削除する（ステップＳ１８１１)。  続いて、サーバフラグ＝ＯＮと設定（ステップＳ１８１２)した後、ステップＳ１８０７に移る。一方、Ｒ＝「差分検索不可」の場合には、サーバフラグ＝ＯＮと設定（ステップＳ１８１３)。続いて、Ｖｃ＝０と設定（ステップＳ１８１４)した後、ステップＳ１８０７に移る。また、Ｒ＝「変更データ無し」の場合には、サーバフラグ＝ＯＦＦと設定する（ステップＳ１８１５)。続いて、Ｖｃ＝Ｖｓと設定（ステップＳ１８１６)した後、ステップＳ１８０７に移る。
【００３６】
図１９は、情報端末装置側における差分検索処理の流れを示すフローチャートである。
【００３７】
まず、差分把握完了フラグ＝ＯＮかどうか判断する（ステップＳ１９０１)。差分把握完了フラグ＝ＯＮでなければ、接続処理（情報管理装置にＶｃを渡す）を行う（ステップＳ１９０２)。続いて、差分ＩＤの送受信を行い（ステップＳ１９０３)、差分ＩＤの除去を実行する（ステップＳ１９０４)。一方、差分把握完了フラグ＝ＯＮであれば、Ｖｃ≠０かどうか判断する（ステップＳ１９０５)。Ｖｃ≠０であれば、情報端末装置のデータベースから検索を実行する（ステップＳ１９０６)。次いで、サーバフラグ＝ＯＮかどうか判断する（ステップＳ１９０７)。一方、Ｖｃ≠０でなければ、直ちにステップＳ１９０７のサーバフラグ＝ＯＮかどうかの判断に移る。サーバフラグ＝ＯＮであれば、情報管理装置から検索を行う（ステップＳ１９０８)。そして、検索結果を表示する（ステップＳ１９０９)。  図２０は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でＶｃとＶｓを用いてＳＱＬ文を作成し（ステップＳ２００１)、ＳＱＬ文を情報管理装置側へ送信する（ステップＳ２００２)。情報管理装置側では、ＳＱＬ文を受信する（ステップＳ２００３)と、変更履歴を用いて差分データから検索を実行する（ステップＳ２００４)。情報管理装置は、検索結果を送信し（ステップＳ２００５)、情報端末装置は検索結果を取得する（ステップＳ２００６)。図２１は、上記したステップＳ２００４の変更履歴を用いた差分データからの検索処理を説明する図である。情報管理装置は、ＳＥＬＥＣＴ ＷＨＥＲＥ ２＜Ｖｅｒ ＡＮＤ Ｖｅｒ≦４とのＳＱＬ文を受信すると（ステップＳ２１０１)、ＳＥＬＥＣＴ文を実行する（ステップＳ２１０２)。図２１に示す例では、変更履歴から、バージョン３ではｎｏｄｅ２に変更を加え、バージョン４ではｎｏｄｅ４に変更が加えられている。よって、情報管理装置が実行すべき差分検索は、ｎｏｄｅ２、ｎｏｄｅ４のみを検索対象とすることがわかる。したがって、検索に要する時間も極めて短時間である。このように、本実施形態によれば、差分処理なので検索対象が少なくて済み、差分検索結果のデータサイズは差分データサイズよりもはるかに小さいのでサーバの処理量が著しく減少させることができ、多くのクライアント機器をケアすることができる。さらに、バージョン管理により、効率よく最新データの把握ができる。
【００３８】
クライアント側では検索のための事前処理として無効化処理するので、効率的な検索が可能となる。また、サーバの処理量が少ないので、高性能でない機器でもデータベースサーバとして使用することができるので、低廉な検索システムを構築することができる。
【００３９】
（第２の実施形態）
図２２は、第２の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。第２の実施形態では、言わば、変更履歴を管理するために必要となるメモリの削減をその狙いとするものである。そのため、（１）変更履歴欄がいっぱいであれば、古いものを削除する、（２）変更履歴欄に同じデータＩＤが存在していたら、最新のものにまとめる、（３）変更履歴で把握できる範囲外のバージョンならば、あえて差分検索しない等を骨子としている。図２３は、変更発生時の変更履歴欄の更新処理であって、削除のみの変更の場合の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２３０１)。次いで、変更内容が削除以外にないかどうか判定する（ステップＳ２３０２)。ＹＥＳであれば、ＤＥＬＥＴＥ ＯＮＬＹフラグをＯＮにする（ステップＳ２３０３)。ここでは、ｎｏｄｅ４を削除するのみの変更が、バージョン“３”として、行われ、ＤＥＬＥＴＥ ＯＮＬＹフラグをＯＮにしている。次いで、バージョンを＋１している（ステップＳ２３０４)。図２４は、変更発生時の変更履歴欄の更新処理であって、データを節約する場合の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２４０１)。次いで、変更履歴に同じデータＩＤが存在するかどうか判定する（ステップＳ２４０２)。ＹＥＳであれば、変更履歴の古いものを削除する（ステップＳ２４０３)。ここでは、ｎｏｄｅ４を対象とする変更が過去においてバージョン“２”でなされているので、バージョン“２”の履歴を削除し、ｎｏｄｅ４を対象とする変更履歴をバージョン“４”のものにまとめている。次いで、バージョンを＋１している（ステップＳ２４０４)。図２５は、変更発生時の変更履歴欄の更新処理であって、古い差分情報は削除する場合の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２５０１)。次いで、変更履歴がいっぱいかどうか判定する（ステップＳ２５０２)。ＹＥＳであれば、古い差分情報を削除する（ステップＳ２５０３)。ここでは、ｎｏｄｅ１２を対象とするバージョン“１”の変更履歴を消すことになる。バージョン“１”の変更履歴が消されと、変更履歴の最も古いバージョン：Ｖｏを差分把握可能範囲：Ｖａ に代入する（ステップＳ２５０４)。ここでは、最も古いバージョンが“２”となり、差分把握可能範囲もバージョン“２”となっている。次いで、バージョンを＋１している（ステップＳ２５０５)。
【００４０】
図２６は、ユーザから更新要求を受けつけた後の変更履歴処理全体の流れを示すフローチャートである。
【００４１】
まず、更新要求の受付後、更新処理を実行する（ステップＳ２６０１)。次いで、変更したノードを変更履歴に追加する（ステップＳ２６０２)。次いで、サーバのバージョンを＋１し、Ｖｓ＝Ｖｓ＋１と設定する（ステップＳ２６０３)。続いて、変更内容は削除以外にないかを判断する（ステップＳ２６０４)。削除のみならば、ＤＥＬＥＴＥ ＯＮＬＹフラグをＯＮにする（ステップＳ２６０５)。フラグ設定後、変更履歴に同じＩＤがあるかを判断する（ステップＳ２６０６)。変更内容が削除以外にもある場合もステップＳ２６０６に移る。変更履歴に同じＩＤがあれば、変更履歴の古いものを削除する（ステップＳ２６０７)。削除後、変更履歴がいっぱいかどうかを判断する（ステップＳ２６０８)。変更履歴に同じＩＤがない場合もステップＳ２６０８に移る。変更履歴がいっぱいであれば、古い差分情報を削除し（ステップＳ２６０９)、変更履歴の最も古いバージョンを差分可能範囲に代入する（ステップＳ２６１０)。次いで、変更履歴を上位概念でまとめ（ステップＳ２６１１)、結果を返却する（ステップＳ２６１２)。変更履歴がいっぱいでない場合には、ステップＳ２６１１以降に移る。第２の実施形態によれば、第１の実施形態での効果に加えて、変更履歴の管理をより効率的に行うことができる。
【００４２】
（第３の実施形態）
図２７は、第３の実施形態に係るクライアントサーバ型検索システムにおけるデータベースの更新およびバージョンを説明するための模式図である。第３の実施形態では、バージョンアップに伴う処理をより効率的に行うことに狙いがある。そのため、変更履歴の管理をより上位の概念で行う、例えば、図６のＴａｂｌｅ単位あるいはＰａｇｅ単位でまとめるものである。
【００４３】
図２８は、変更発生時の変更履歴欄の更新処理の流れを示すフローチャートである。まず、変更したノード＝ｎｏｄｅ４が変更履歴欄に追加されている（ステップＳ２８０１)。次いで、同じＰａｇｅに所属するものが一定値以上かどうか判定する（ステップＳ２８０２)。一定値以上であれば、同じＰａｇｅのＩＤを削除し（ステップＳ２８０３)、Ｐａｇｅ ＩＤを追加する（ステップＳ２８０４)。ここでは、ｎｏｄｅ１２とｎｏｄｅ１３を対象とする変更履歴が、Ｐａｇｅ Ａを変更対象とするバージョン“４”として上位概念化している。次いで、バージョンを＋１している（ステップＳ２８０５)。
【００４４】
図２９は、変更履歴の上位概念によるまとめ処理の流れを示すフローチャートである。
【００４５】
まず、同じページのＩＤをカウントする（ステップＳ２９０１)。Ｐａｇｅでまとめられるかどうかを判断する（ステップＳ２９０２)。Ｐａｇｅでまとめられる場合には、同じページのＩＤを変更履歴から削除する（ステップＳ２９０３)。次いで、同じテーブルのＩＤをカウントする（ステップＳ２９０４)。Ｐａｇｅでまとめられない場合には、直ちにステップＳ２９０４に移る。次いで、Ｔａｂｌｅでまとめられるかどうかを判断する（ステップＳ２９０５)。Ｔａｂｌｅでまとめられる場合には、同じテーブルのＩＤを変更履歴から削除し（ステップＳ２９０６)、上位概念でのまとめを終了する。Ｔａｂｌｅでまとめられない場合にも、上位概念でのまとめを終了する。
【００４６】
尚、情報端末装置におけるバージョンアップを簡単にするための工夫として、差分把握に関してデータＩＤを受け取って、ＤＥＬＥＴＥ ＯＮＬＹのフラグをチェックし、フラグがたっているならば、差分データを受け取ったのと同じなのでバージョンアップし、あるいは、差分データを受け取ったら、反映し、バージョンアップするようにすることもできる。第３の実施形態によれば、バージョンアップに伴う処理をより効率的に行うことができる。
【００４７】
（第４の実施形態）
図３０は、第４の実施形態にかかる検索システムを説明する図である。第４の実施形態では、情報管理装置での検索結果の通信量のさらなる低減を図るもので、差分検索に関して、検索結果と差分データから同期判断し、同期したほうが良いと判断した場合には、同期データを送信し、かかる同期判断は段階的に行ってもよい、等を骨子としている。ここでは、図３０に示すように、差分データＤｓと、差分検索結果Ｒｓのデータサイズを比較する。図３１は、情報管理装置における差分検索処理の流れを示すフローチャートである。まず、情報管理装置への検索要求は、情報端末装置側でＶｃとＶｓを用いてＳＱＬ文を作成し（ステップＳ３１０１)、ＳＱＬ文を情報管理装置側へ送信する（ステップＳ３１０２)。情報管理装置側では、SQL文を受信する（ステップＳ３１０３)と、変更履歴を用いて差分データから検索を実行する（ステップＳ３１０４)。次いで、差分データサイズ：Ｓｄを取得する（ステップＳ３１０５）。続いて、検索結果データサイズ：Ｓｒを取得する（ステップＳ３１０６）。そして、差分データサイズ：Ｓｄと積分の差分検索データサイズ：ΣＳｒについて、Ｓｄ＞ΣＳｒかどうかを判断する（ステップＳ３１０６）。情報管理装置は、Ｓｄ＞ΣＳｒでなければ、検索結果の代わりに差分データを送信し（ステップＳ３１０８)、Ｓｄ＞ΣＳｒであれば検索結果を送信する（ステップＳ３１０９)。情報端末装置はデータを取得し（ステップＳ３１１０)、データが差分データかどうかを判断する（ステップＳ３１１１）。差分データであれば、差分データをデータベースにアップデートする（ステップＳ３１１２）。Ｖｃ＝Ｖｓとし（ステップＳ３１１３）、サーバフラグ＝ＯＦＦと設定する（ステップＳ３１１４）。
【００４８】
繰り返しの検索によって、検索結果データが差分データよりも大きくなってしまう可能性がある。そのような場合には、（積算の差分検索結果データサイズ）≦（差分データサイズ）となり、積算の差分検索結果データサイズを送信したほうが結果的にデータ量は少ないので、検索結果を送信した方が特である。一方、（積算の差分検索結果データサイズ）＞（差分データサイズ）ならば、差分データを送り、以降の通信量は無しとすることにより、本実施形態によれば、繰り返しによる通信量を低減することができる。尚、上述では、積算の検索結果データと差分データの大小関係による判定について説明したが、これに限られない。例えば、差分データの８０％で比較する、あるいは検索要求を予測するようにしてもよい。
【００４９】
（第５の実施形態）
第５の実施形態では、情報管理装置での検索結果の通信量のさらなる低減を図るものである。図３２は、第５の実施形態にかかる検索システムを説明する図である。ここでは、図３２に示すように、バージョンごとのデータで、差分データＤｓと、差分検索結果Ｒｓのトータルサイズを比較する。
【００５０】
図３３は、情報管理装置における差分検索処理の流れを示すフローチャートである。
【００５１】
まず、情報管理装置への検索要求は、情報端末装置側でＶｃとＶｓを用いてＳＱＬ文を作成し（ステップＳ３３０１)、ＳＱＬ文を情報管理装置側へ送信する（ステップＳ３３０２)。情報管理装置側では、ＳＱＬ文を受信する（ステップＳ３３０３)と、Ｎ＝Ｎ＋１とカウントアップ（ステップＳ３３０４)した後、変更履歴を用いて差分データから検索を実行し、データを作成する（ステップＳ３３０５)。情報管理装置は、情報端末装置に送信データ：S の送信を行う（ステップＳ３３０６)。情報端末装置はデータを取得し（ステップＳ３３０７)、データに差分データがあるかどうかを判断する（ステップＳ３３０８）。差分データがあれば、差分データをデータベースにアップデートする（ステップＳ３３０９）。Ｖｃ＝Vdと設定し（ステップＳ３３１０）、Ｖｃ＝Ｖｓかどうかを判断する（ステップＳ３３１１）。Ｖｃ＝Ｖｓであれば、サーバフラグ＝ＯＦＦとする（ステップＳ３３１２）。一方、データに差分データがない場合には、ステップＳ３３１２に移る。Ｖｃ＝Ｖｓでない場合には終了する。
【００５２】
次に、検索結果と同期データの比較による送信データの決定について説明する。図３４は、送信データの決定処理の流れを示すフローチャートである。まず、ｉ＝Ｖｃ＋１とする（ステップＳ３４０１）。次いで、Ｖｓ＝ｉかどうかを判断する（ステップＳ３４０２）。Ｖｓ＝ｉでなければ、ｉ＝ｉ＋1とし（ステップＳ３４０３）、バージョンｉの差分データ量：Ｄｄとしたとき、Ｓｄ＝Ｓｄ＋Ｄｄとする（ステップＳ３４０４）。次いで、ｉの差分データが検索にヒットしたかどうかを判断する（ステップＳ３４０５）。ヒットした場合には、ｉの差分検索結果データ量：Ｒｄをもとめた（ステップＳ３４０６）後、積算検索結果データ量Ｓｒに足し上げ、Ｓｒ＝Ｓｒ＋Ｒｄとする（ステップＳ３４０７）。続いて、Ｓｄ＞Ｓｒかどうかを判断する（ステップＳ３４０８）。ステップＳ３４０５において、ｉの差分データが検索にヒットしなければ、ステップＳ３４０８に移る。Ｓｄ＞Ｓｒでなければ、どのバージョンまで差分を送るか確保し、Ｖｄ＝ｉとする（ステップＳ３４０９）。その後、ステップＳ３４０２に戻る。Ｓｄ＞Ｓｒであれば、直ちに、ステップＳ３４０２に戻る。
【００５３】
一方、Ｖｓ＝ｉであれば、Ｖｄまでのバージョンの差分データを送信データ：Ｓにコピーする（ステップＳ３４１０）。続いて、Ｖｄ以降の検索結果を送信データ：Ｓに追記コピーする（ステップＳ３４１１）。
【００５４】
第５の実施形態によれば、部分的なバージョンアップをするので、差分検索処理量が減り、差分データ量を減少させることができる。また、以降の通信量も減少させることができる。上述では、差分データと差分検索結果のトータルサイズの大小関係による判定について説明したが、これに限られない。例えば、差分データの８０％で比較する、あるいは検索要求を予測するようにしてもよい。
【００５５】
なお、本発明は上記の実施形態のそのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記の実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【００５６】
１…情報端末装置、１０…ユーザインターフェース、１１…接続部、１２…命令制御部、１３…SQL実行部、１４…データベース、２…情報管理装置、２１…接続部、２２…命令制御部、２３…SQL実行部、２４…データベース、１００…クライアントサーバシステム。
【図２】
2010282360.tif 000003
【図３】
2010282360.tif 000004
【図４】
2010282360.tif 000005
【図５】
2010282360.tif 000006
【図６】
2010282360.tif 000007
【図７】
2010282360.tif 000008
【図８】
2010282360.tif 000009
【図９】
2010282360.tif 000010
【図１０】
2010282360.tif 000011
【図１１】
2010282360.tif 000012
【図１２】
2010282360.tif 000013
【図１３】
2010282360.tif 000014
【図１４】
2010282360.tif 000015
【図１５】
2010282360.tif 000016
【図１６】
2010282360.tif 000017
【図１７】
2010282360.tif 000018
【図１８】
2010282360.tif 000019
【図１９】
2010282360.tif 000020
【図２０】
2010282360.tif 000021
【図２１】
2010282360.tif 000022
【図２２】
2010282360.tif 000023
【図２３】
2010282360.tif 000024
【図２４】
2010282360.tif 000025
【図２５】
2010282360.tif 000026
【図２６】
2010282360.tif 000027
【図２７】
2010282360.tif 000028
【図２８】
2010282360.tif 000029
【図２９】
2010282360.tif 000030
【図３０】
2010282360.tif 000031
【図３１】
2010282360.tif 000032
【図３２】
2010282360.tif 000033
【図３３】
2010282360.tif 000034
【図３４】
2010282360.tif 000035
【図１】
2010282360.tif 000036