(57)【特許請求の範囲】
【請求項１】
データベースの論理構造データを、ディスク装置のファイルに格納される物理構造としてのページとして、バージョンごとに管理するデータベース管理部を、センタ装置および端末にそれぞれ有し、互いに同一のバージョンを稼働するデータベースシステムにより実行されるデータ更新方法であって、
前記センタ装置は、
前記各端末で共通する更新内容をセンタ装置が代表して受け付けるセンタ装置側受付命令の入力に応じて、前記論理構造データに適用した結果をファイルのＤＢ領域内のページに格納し、
前記ＤＢ領域内のページについて、前記センタ装置側受付命令による更新前バージョンから更新後バージョンへのデータ変更がなされた差分ページを示す更新差分ファイルを作成する場合に、前記センタ装置側受付命令を適用更新前バージョンの前記ＤＢ領域内のページに適用するときに、ページが更新されたことを示す更新フラグを、ページの配列に対応する更新フラグ配列の更新されたページに対応する箇所について更新済と設定し、前記更新フラグ配列を順に参照し、前記更新フラグが更新済となっているページを差分ページとして抽出し、
前記端末は、
前記センタ装置から通知された前記更新差分ファイルの差分ページを、前記端末のＤＢ領域上のページに上書きコピーすることにより、前記センタ装置側受付命令が適用された後である前記更新後バージョンに更新することを特徴とするデータ更新方法。
【請求項２】
前記端末は、
前記端末に適用される更新内容を示す端末側受付命令の入力に応じて、前記論理構造データに適用した結果をファイルの前記ＤＢ領域内のページに格納し、
前記ＤＢ領域内のページについて、前記端末側受付命令による更新前バージョンから前記更新後バージョンへのデータ変更がなされたページについて、更新前バージョンのページをバックアップページとしてバックアップファイルに格納し、
前記更新差分ファイルを使ったデータ更新の前に、前記端末側受付命令により前記更新後バージョンへのデータ変更がなされたページについて、前記バックアップページを上書きし、
前記端末側受付命令の入力に応じて、前記論理構造データに適用する工程にて、さらに、入力された前記端末側受付命令を順序づけて更新命令履歴ファイルに記録し、
前記端末のＤＢ領域上のページに差分ページを上書きする工程の後に、さらに、前記更新後バージョンのページから構成される前記論理構造データに対して、更新命令履歴ファイルから読み取った前記端末側受付命令を順序づけて適用することを特徴とする
請求項１に記載のデータ更新方法。
【請求項３】
前記端末は、
端末側受付命令の入力に応じて、前記論理構造データに適用した結果をファイルの前記ＤＢ領域内のページに格納し、
前記ＤＢ領域内のページについて、前記端末側受付命令による更新前バージョンから前記更新後バージョンへのデータ変更がなされたページについて、更新前バージョンのページをバックアップページとしてバックアップファイルに格納し、
前記更新差分ファイルを使ったデータ更新の前に、前記端末側受付命令により前記更新後バージョンへのデータ変更がなされたページについて、前記バックアップページを上書きし、
バックアップファイルに格納する工程は、
今回の前記端末側受付命令により更新対象のページが前記バックアップページとして格納されると、格納されたことを示す更新対象のページのバックアップフラグを格納済に設定し、
次回以降の前記端末側受付命令により前記バックアップフラグが格納済のページに対する更新がなされたときには、そのページに対する前記バックアップページの格納処理を省略することを特徴とする
請求項１に記載のデータ更新方法。
【請求項４】
データベースの論理構造データを、ディスク装置のファイルに格納される物理構造としてのページとして、バージョンごとに管理するデータベース管理部を、センタ装置および端末にそれぞれ有し、互いに同一のバージョンを稼働するデータベースシステムであって、
前記センタ装置は、
前記各端末で共通する更新内容をセンタ装置が代表して受け付けるセンタ装置側受付命令の入力に応じて、前記論理構造データに適用した結果をファイルのＤＢ領域内のページに格納し、
前記ＤＢ領域内のページについて、前記センタ装置側受付命令による更新前バージョンから更新後バージョンへのデータ変更がなされた差分ページを示す更新差分ファイルを作成する場合に、前記センタ装置側受付命令を適用更新前バージョンの前記ＤＢ領域内のページに適用するときに、ページが更新されたことを示す更新フラグを、ページの配列に対応する更新フラグ配列の更新されたページに対応する箇所について更新済と設定し、前記更新フラグ配列を順に参照し、前記更新フラグが更新済となっているページを差分ページとして抽出し、
前記端末は、
前記センタ装置から通知された前記更新差分ファイルの差分ページを、前記端末のＤＢ領域上のページに上書きコピーすることにより、前記センタ装置側受付命令が適用された後である前記更新後バージョンに更新することを特徴とするデータベースシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ更新方法、および、データ更新システムに関する。
【背景技術】
【０００２】
データベース（以下、適宜ＤＢ（Database）と省略する）のデータ更新には、ＣＰＵ（Central Processing Unit）やメモリなどのリソース（計算機資源）を必要とする。組み込みシステムのようなリソースに制約がある端末上のデータベースに対して、データを大量に更新する処理は、負担となる。
【０００３】
これまで、組み込みシステム内のデータベースは、データベース管理システムのようなミドルウェアで管理するのではなく、組み込みシステム内のアプリケーションが独自に処理を作りこむような手法を用いていた。
【０００４】
ところが、近年のストレージ技術の進歩、組込みシステムの高機能化により、扱うデータの大容量化、多様化が進み、組み込みシステム内のアプリケーション独自のデータ管理では、組込みシステムに要求されるより高い性能や信頼性に応えることは困難になりつつある。また、組込みシステム市場における競争の激化により、製品開発のスピードが更に重要になっていきている。
【０００５】
このような状況の中、端末上のデータベースについて、組み込みシステム内のアプリケーション内に実装するのではなく、センタなどのリソースが豊富なコンピュータで動作するような高機能なＲＤＢ（Relational Database）を適用して、アプリケーションとデータ管理を分離し、ソフトウェア開発の生産性を高めようとする認識が広がっている。
【０００６】
ここで、前記センタよりは低性能な組み込みシステムに、高機能なＲＤＢを動作させるために、処理を軽減させる必要がある。処理を軽減させる方法の一例として、更新命令のログデータを活用する方法が挙げられる。例えば、特許文献１では、自局への更新を実施するときに、その更新命令をログとして記録しておき、他局への更新を実施するときにもそのログを活用する。
【特許文献１】特開２００４−１４５８２７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来の技術では、組み込みシステムでＲＤＢを動作させるほどには、充分に処理が軽減させていなかった。
【０００８】
例えば、特許文献１では、複数の装置でログを再利用するが、ログの適用にはＳＱＬ（Structured Query Language）などにより記述された更新命令（以下、ＳＱＬ更新命令と略す）を解釈して適用する処理が、各装置で個別に必要となる。この更新命令に関する処理が高負荷な理由は、更新命令の演算対象がＲＤＢのテーブルという論理構造を対象とするためである。
【０００９】
つまり、各装置は、自装置に格納された物理構造としてのファイルから論理構造としてのテーブルを組み立てる処理が必要となるが、この処理が高負荷となってしまう。
【００１０】
そこで、本発明は、前記した問題を解決し、高性能なコンピュータおよび前記センタよりは低性能なコンピュータが協働するシステムにおいて、前記センタよりは低性能なコンピュータへのデータベース処理の負荷を軽減することを主な目的とする。
【課題を解決するための手段】
【００１１】
前記課題を解決するため、本発明は、２次元の表により構成されるＲＤＢ（Relational Database）の論理構造としてのテーブルを、ディスク装置のファイルに格納される物理構造としてのページとして、バージョンごとに管理するＤＢＭＳ（Data Base Management System）を、高性能な１台のセンタ、および、前記センタよりは低性能な１台以上の端末において、互いに同一のバージョンで稼働を開始するデータベースシステムにより実行されるデータ更新方法であって、
前記センタが、
入力されたセンタ側受付命令を前記テーブルに適用した結果をファイルのＤＢ領域内のページに格納し、
前記ＤＢ領域内のページについて、前記センタ側受付命令による更新前バージョンから更新後バージョンへのデータ変更がなされた差分ページを示す更新差分ファイルを作成する場合に、前記センタ装置側受付命令を適用更新前バージョンの前記ＤＢ領域内のページに適用するときに、ページが更新されたことを示す更新フラグを、ページの配列に対応する更新フラグ配列の更新されたページに対応する箇所について更新済と設定し、前記更新フラグ配列を順に参照し、前記更新フラグが更新済となっているページを差分ページとして抽出し、
各前記端末が、
入力された端末側受付命令を前記テーブルに適用した結果をファイルの前記ＤＢ領域内のページに格納し、
前記ＤＢ領域内のページについて、前記端末側受付命令による更新前バージョンから前記更新後バージョンへのデータ変更がなされたページについて、更新前バージョンのページをバックアップページとしてバックアップファイルに退避し、
前記センタ側受付命令が発行されたときに、前記端末側受付命令により前記更新後バージョンへのデータ変更がなされたページについて、前記バックアップページを上書きコピーすることにより、前記端末側受付命令が適用される前である更新前バージョンに書き戻し、
前記センタから通知された前記更新差分ファイルの差分ページを、前記端末のＤＢ領域上のページに上書きコピーすることにより、前記センタ側受付命令が適用された後である前記更新後バージョンに更新することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【００１２】
本発明によれば、高性能なセンタおよび前記センタよりは低性能な端末が協働するシステムにおいて、前記センタよりは低性能なコンピュータへのデータベース処理の負荷を軽減することができる。
【発明を実施するための最良の形態】
【００１３】
以下に、本発明が適用されるデータベースシステムの一実施形態について、図面を参照して詳細に説明する。
【００１４】
図１は、本実施形態のデータベースシステム全体の概要を示す説明図である。本システムは、１台のセンタと、１台以上の端末とがネットワークで接続されている。センタ、および、端末は、それぞれ所定のバージョンのデータが格納されているＤＢを有している。以下、センタが有するＤＢをセンタＤＢとし、端末が有するＤＢを端末ＤＢとする。
【００１５】
センタ、および、端末は、それぞれＤＢを格納する記憶手段、および、制御処理などを実行するＣＰＵを備えたコンピュータとして実現される。
【００１６】
なお、図１では、各コンピュータが有するＤＢ内のデータのバージョンを、楕円内の数値にて表現している。例えば、図１（ａ）の左側（更新前）におけるセンタ、および、全端末は、バージョン「１．０」のデータを有している。つまり、同じ内容データが、各コンピュータに格納されている。
【００１７】
次に、更新の影響範囲に着目した２種類の更新（センタ側受付更新、および、端末側受付更新）について、説明する。
【００１８】
図１（ａ）は、端末側受付更新を示す説明図である。端末側受付更新は、図１（ｂ）に示すセンタ側受付更新が対象とする大量のデータ更新とは異なり、組み込みシステム上でも十分実行可能な、負荷が大きくない更新を、主な対象とする。
【００１９】
センタＤＢと端末ＤＢは、初期状態では同一のバージョン「１．０」を保持する。３台の端末のうち、１台の端末Ａが、ＳＱＬの更新命令の入力を受け付ける。すると、端末Ａは、自装置の端末ＤＢに対して、ＳＱＬの更新命令を反映する。この更新命令の反映処理は、端末ＡのＤＢ管理部２１（図８）によって実行される。その結果、端末Ａの端末ＤＢのバージョンが「１．０」から「１．１」へと更新される。
【００２０】
このバージョン「１．１」への更新は、他の端末やセンタへは反映されず、端末Ａに閉じた（換言すると、ローカルな）更新である。端末側受付更新により、各ＤＢでは、独立した更新が行われる。よって、端末が複数ある場合でも、各端末の端末ＤＢは、それぞれ独立して運用され、互いに影響を与えることはない。本実施形態では、端末側受付更新について、バージョン番号の小数値の増加で表現する。
【００２１】
図１（ｂ）は、センタ側受付更新を示す説明図である。図１（ａ）の端末側受付更新だけを個別に行うと、端末のリソースを圧迫する。そこで、センタ側受付更新は、全ての端末で共通する更新を、リソースの豊富なセンタが代表して行うことにより、端末への負担を軽減する。
【００２２】
センタＤＢと端末ＤＢは、初期状態では同一のバージョン「１．０」を保持する。３台の端末を管理するセンタが、ＳＱＬの更新命令の入力を受け付ける。すると、センタは、自装置のセンタＤＢに対して、ＳＱＬの更新命令を反映する。この更新命令の反映処理は、センタのＤＢ管理部１１（図８）によって実行される。その結果、センタのセンタＤＢのバージョンが「１．０」から「２．０」へと更新される。
【００２３】
このバージョン「２．０」への更新は、センタが管理する全端末へと反映される。つまり、全端末に反映される（換言すると、グローバルな）更新である。本明細書では、センタ側受付更新について、バージョン番号の整数値の増加で表現する。
【００２４】
ここで、端末側受付更新が行われた後に、センタ側受付更新が行われたときについて、説明する。図１（ａ）の端末側受付更新により、端末Ａの端末ＤＢのバージョン「１．１」と、端末Ｂ，Ｃの端末ＤＢのバージョン「１．０」とが混在する。センタ側受付更新では、センタＤＢのバージョン「１．０」→「２．０」への更新を、全端末に反映する必要がある。
【００２５】
まず、端末Ｂ，Ｃでは、更新前のバージョンがセンタと同一な「１．０」であるため、センタの更新と同等の処理を端末でも行うことにより、バージョン「２．０」へと問題なく更新される。
【００２６】
一方、端末Ａでは、更新前のバージョンがセンタとは異なり「１．１」である。よって、センタの更新と同等の処理を行っても、更新前のデータが異なることにより、端末ＤＢをバージョン「２．０」へ更新することはできない。つまり、２種類の更新（端末側受付更新とセンタ側受付更新）を併用するときの問題となる。
【００２７】
図１（ｃ）は、２種類の更新を併用するときの問題への対処法を示す説明図である。この図は、端末Ａの端末ＤＢのバージョンに着目した状態遷移図であり、楕円の中に記載された数値は、バージョン番号を示す。
【００２８】
まず、バージョン「１．０」→「１．１」への状態遷移を説明する。端末ＤＢは、図１（ａ）に示す端末側受付更新を行う。この端末側受付更新は、端末ＡのＤＢ管理部２１（図８）によって実行される。この際、データを書き換えるページを特定すると、実際に書き換える前のページをバックアップファイルとして退避する。このバックアップファイルの退避（格納）処理は、バックアップファイル作成部２３（図８）によって実行される。なお、同一箇所のページに対して、複数回の端末側受付更新が行われたときには、バックアップファイルの退避は、各ページにつき最初の一度だけよい。
【００２９】
次に、バージョン「１．１」→「１．０」への状態遷移を説明する。この状態遷移は、図１（ｂ）で示すバージョン「１．０」→「２．０」のセンタ側受付更新を、端末Ａに反映するための前準備である。このセンタ側受付更新を端末Ａにも反映するときには、端末Ａの端末ＤＢのバージョン「１．１」と、センタＤＢの更新元バージョン「１．０」と、を同一バージョンにする必要がある。
【００３０】
そのため、端末Ａの端末ＤＢのバージョンを「１．１」から「１．０」へと書き戻す。この書き戻し処理は、端末Ａのページ書き戻し部２５（図８）によって実行される。具体的には、バージョン「１．０」→「１．１」への状態遷移のときの、バージョン「１．０」のバックアップファイルを「１．１」のページに上書きすることで、実現される。
【００３１】
そして、バージョン「１．０」→「２．０」への状態遷移を説明する。この状態遷移は、図１（ｂ）で示すバージョン「１．０」→「２．０」のセンタ側受付更新を、端末Ａに反映する処理である。センタは、バージョン「１．０」→「２．０」の差分データを作成し、差分データを端末Ａに入力する。
【００３２】
具体的には、センタは、あらかじめ用意していた初期状態「１．０」のデータベースと、更新が施された「２．０」のデータベースをページごとに比較し、ページが異なるページのうち、被更新データベースのページをファイルに格納する。このファイルが差分データとなる。この差分データの格納処理は、センタの更新差分ファイル作成部１３（図８）によって実行される。センタのデータベースを「１．０」から「２．０」へ更新する処理は、ＤＢ管理部１１（図８）によって実行される。
【００３３】
センタからの差分データを入力された端末Ａは、バージョン「１．０」の端末ＤＢに、差分データを適用することにより、バージョン「２．０」へと更新する。この更新処理は、端末Ａのページ更新部２６（図８）によって実行される。これにより、センタ側受付更新が端末Ａにも反映される。
【００３４】
さらに、バージョン「２．０」→「２．１」への状態遷移を説明する。この状態遷移は、バージョン「１．０」→「１．１」の端末側受付更新の内容を、バージョン「２．０」に適用することにより、バージョン「２．１」とする処理である。
【００３５】
具体的には、端末Ａは、既に行ったバージョン「１．０」→「１．１」への端末側受付更新の際のＳＱＬ更新命令を記憶しておき、そのＳＱＬ更新命令を、バージョン「２．０」へ適用することにより、バージョン「２．１」とする。これにより、１回のＳＱＬ更新命令が、２回の端末側受付更新で再利用されるため、端末ＡへＳＱＬ更新命令を入力する手間が省ける。なお、ＳＱＬ更新命令を記憶する処理は、更新命令履歴管理部２７（図８）によって実行される。
【００３６】
つまり、バージョン「２．１」とすることにより、センタ側受付更新処理の実行後に、バージョン「１．０」への書き戻しの際に失われた端末側受付更新の内容を、回復させることができる。
【００３７】
ここで回復できる更新内容は、一部に限られる。例えば、端末側受付更新で所定のページを書き換えた場合、もしその所定のページが、センタ側受付更新処理の結果削除されていた場合、所定のページはなくなっているため、そのような端末側受付更新は、バージョン「２．１」では回復できない。
【００３８】
一方、ある端末側受付更新が対象としている特定のページが、物理センタ側受付更新処理によって、論理構造上影響を受けない場合、すなわち、表中のどの行にも変更が加わらない場合は、その端末側受付更新の内容は、バージョン「２．１」で回復することができる。
【００３９】
【表１】
0005108637.tif 000002
表１は、ＳＱＬ更新命令の更新命令履歴ファイルの一例である。更新命令履歴ファイルには、更新の順序を識別するための更新ＩＤと、指定されたＳＱＬ文と、ＳＱＬ文の入力パラメータ値とを対応づけて格納する。更新ＩＤは、例えば、ＳＱＬ更新命令の発行時の時間を識別するように作成される。例えば、第１列の更新ＩＤ「2006-1223-0123」は、2006年12月23日01時23分という発行時の時間をもとに作成されたものである。更新ＩＤによって順序を一意に規定することにより、その順序でＳＱＬ文を適用することができる。
【００４０】
図２は、ＲＤＢにおける論理構造のテーブルと、物理構造のページとの関係を示す説明図である。
【００４１】
ＲＤＢは、今日、情報システムにて運用されている最も一般的なデータベースである。ＲＤＢでは、データベースの論理構造を２次元の表（テーブル）形式で表す。テーブルの横方向を行（レコード）、縦方向を列（フィールド）と呼ぶ。行は、表を操作するときの単位であり、一つ以上の列から構成される。各行の同じ列には、同じ形式のデータが格納される。
【００４２】
ＲＤＢでは、データの操作は、ＳＱＬという言語を用いて、操作対象となる表および行を指定することで行う。データベース中のデータを操作するには、ＲＤＢの操作者は、２次元で示される表の行や列といった論理構造を意識にするだけでよい。
【００４３】
つまり、テーブルを格納する物理構造のファイル中において、どこにどのような形で格納されているかといった物理構造を意識しなくてよい。論理構造と物理構造との対応づけは、ミドルウェアであるデータベース管理システムが行う。
【００４４】
データベースのアクセス対象となるデータは、論理構造のテーブルとして表現される。このテーブルを格納しているＤＢ領域は、オペレーションシステムから見た場合は、物理領域に格納される１つまたは複数のファイルで構成されている。
【００４５】
なお、ＤＢ領域が複数のファイルから構成される場合は、ＤＢ領域に対して行っている更新などの操作を、ＤＢ領域を構成する複数のファイルそれぞれに対して行うようにすればよい。ファイルは、固定の大きさ（セグメントとも呼ばれる）を持ったページという単位で区切られている。物理構造上でのデータ操作は、ページごとに行われる。
【００４６】
図２（ａ）は、更新前のテーブルを示す。テーブルは、行と列とを軸とした２次元の表形式で表現される。このテーブルに対して、ＳＱＬ形式で記述された更新命令が適用可能である。なお、図２（ａ）では、１つのテーブルの一部に着目して説明するが、ＤＢ領域は複数のテーブルを格納することとしてもよい。
【００４７】
図２（ｂ）は、図２（ａ）のテーブルと同じデータであり、ＤＢ領域に格納するときのページである。ページは、例えば、テーブルを構成するデータを順番に詰めて保存する。このページに対して、ＳＱＬ形式で記述された更新命令は適用不可能である。なお、図２（ｂ）では１つのページを抽出して説明したが、１つのテーブルが連続する複数のページにまたがって保存されていてもよい。
【００４８】
図２（ｃ）は、図２（ａ）に対してＳＱＬの更新命令を適用した結果である更新後のテーブルを示す。ＳＱＬの更新命令「ＳＱＬの更新命令「第１列が１１のレコードを選択し、そのレコードの第２列を９９９−９９９に変更」により、各行の第２列の値が「９９９−９９９」に更新されている。
【００４９】
データの更新について、データベース管理システムは、ＳＱＬの更新命令を受けると、該当ページの特定、および、該当ページ内の該当個所の特定を実行する。まず、該当ページの特定とは、ＳＱＬの更新命令で指定されたテーブルが格納されている該当ページを特定すること、換言すると、論理構造から物理構造へ変換することである。
【００５０】
次に、該当ページ内の該当個所の特定とは、例えば、該当ページの中にある各行の第１列の値が、「１１」であるか確認し、値が「１１」の行を見つけると、その行の第２列の値が格納されている領域を値「９９９−９９９」に書き換えることである。このように、ＲＤＢの更新処理には、該当ページ、およびそのページ内の該当個所の特定というオーバーヘッドが生じてしまう。
【００５１】
図２（ｄ）は、図２（ｃ）のテーブルと同じデータであり、ＤＢ領域に格納するときのページである。図２（ｂ）と比較すると、第２列のデータに該当する箇所が「９９９−９９９」に書き換わっている。
【００５２】
ここで、本明細書の特徴としては、１回目に論理的更新を行い、２回目以降はその論理的更新の結果を流用して、物理的更新を行うことである。
【００５３】
まず、論理的更新とは、図２（ｂ）の更新前のページから図２（ｄ）の更新後のページに更新するときに、ページをテーブルに変換して（図中の実線矢印、図２（ｂ）→図２（ａ）で示す）、変換したテーブルに対してＳＱＬの更新命令を適用し（図中の実線矢印、図２（ａ）→図２（ｃ）で示す）、適用されたテーブルをページに変換する（図中の実線矢印、図２（ｃ）→図２（ｄ）で示す）処理である。つまり、論理構造であるテーブルを用いた更新方法なので、論理的更新という。
【００５４】
一方、物理的更新とは、図２（ｂ）の更新前のページから図２（ｄ）の更新後のページに更新するときに、更新前のページが記憶されているＤＢ領域に対して、更新後のページをコピー（上書き）する処理である。つまり、論理構造であるテーブルを用いず、物理構造であるページをそのまま用いた更新方法なので、物理的更新という。
【００５５】
なお、物理的更新には、更新前から更新後に更新する（バージョンアップする）ページ更新と、更新後から更新前に書き戻すページ書き戻しとがある。いずれの物理的更新でも、計算機の処理としては、ＳＱＬの解釈を行わずに、記憶装置に対するデータコピーだけで済むので、高速な処理が可能となる。つまり、ＳＱＬによる更新処理で発生していた論理構造から物理構造への変換によるオーバーヘッドが生じず、更新にかかる時間をほぼディスクの入出力時間と見積もることができる。
【００５６】
従来では、組み込みシステムなどの前記センタよりは低性能な端末に対するデータ更新について、全て論理的更新を適用していた。そのとき、大量のデータに対する更新処理を、システムとして許容できる時間内に終えることは困難である。これは、ＲＤＢのデータ更新では、論理構造から物理構造への変換を行うオーバーヘッドが生じるためである。
【００５７】
組み込みシステム、とりわけ、コンシューマー向け組み込みシステムでは、コストや消費電力などの要因により、エンタープライズ系サーバなどと比べ、利用できるＣＰＵや記憶装置などのリソースに制約があるため、前記のオーバーヘッドがシステムの性能に大きな影響を与えるからである。
【００５８】
ところで、図１（ｃ）で示した２種類の更新を併用するときの問題への対処法において、図２で示した論理的更新および物理的更新を適切に適用することにより、更新処理の高速化を実現できる。以下、高速化処理の詳細を説明する。
【００５９】
まず、バージョン「１．０」→「１．１」への端末側受付更新には、論理的更新を適用する。これは、入力されたＳＱＬ更新命令を解釈する第１回目であるためである。
【００６０】
次に、バージョン「１．１」→「１．０」への端末側受付更新の書き戻しには、バックアップファイルを更新元ページとして、物理的更新のページ書き戻しを適用する。物理的更新なので、高速な処理が可能となる。
【００６１】
そして、バージョン「１．０」→「２．０」へのセンタ側受付更新には、センタは論理的更新を適用し、各端末は物理的更新を適用する。センタ側は自装置に入力されたＳＱＬ更新命令を解釈する第１回目であるため、論理的更新を行う。そして、各端末は第１回目の論理的更新の結果を流用する物理的更新のページ更新を行う。物理的更新なので、高速な処理が可能となる。
【００６２】
さらに、バージョン「２．０」→「２．１」への端末側受付更新には、論理的更新を適用する。入力されたＳＱＬ更新命令を解釈するため、物理的更新が適用できないためである。
【００６３】
以上説明したように、センタ側受付更新を各端末に反映するときに、物理的更新を適用することができるため、高速な処理が可能となる。さらに、端末側受付更新を持たない仕様で端末を構成するときには、ＳＱＬ更新命令を解釈する機能を持たせず、全ての更新を物理的更新で済ますことができるため、装置の小型化および高速化が実現できる。
【００６４】
図３は、２種類の更新を併用する説明図である。図３（ａ）は更新前の８つのページを示す。図３（ｂ）は、図３（ａ）に対して、ページＣ，Ｄに対する端末側受付更新が行われた後のページを示す。更新されたページＣ，Ｄのバージョン番号が「１．１」になっている。
【００６５】
図３（ｃ）は、図３（ｂ）の状態において、前処理としてのページ書き戻しを実行せずに、センタ側受付更新「ページＢ，Ｄ，Ｇ，Ｈ」を適用した状態を示す。ページＢ，Ｄ，Ｇ，Ｈは、バージョン「２．０」に更新されるものの、ページＣは、センタ側受付更新の対象ではないので、バージョン「１．１」のままである。しかし、センタＤＢのページＣは、端末側受付更新が行われないのでバージョン「１．０」であり、図３（ｃ）の端末ＤＢとデータの不整合が発生してしまう。
【００６６】
図３（ｄ）は、図３（ｂ）の状態において、前処理としてのページ書き戻しを実行してから、センタ側受付更新「ページＢ，Ｄ，Ｇ，Ｈ」を適用した状態を示す。ページＣは、ページ書き戻し処理によりバージョン「１．０」へと戻る。よって、センタＤＢのページＣとデータ内容が同一となり、不整合は解消される。
【００６７】
図４は、端末側受付更新（バージョン「１．０」→「１．１」）およびその書き戻し（バージョン「１．１」→「１．０」）のために使用されるバックアップファイルを説明する説明図である。
【００６８】
バックアップファイル２４は、端末側受付更新が行われる際に、更新が行われるページの更新前のページを退避するファイルである。ただし、更新前ページの退避は、各ページにつき１度だけであり、各ページに対して最初に更新が行われるときにのみ行う。
【００６９】
図４（ａ）は、端末側受付更新の指示を受け付けたときに、ページを更新するためにバックアップファイル２４に退避する旨を示す。８つのページ（ページＡ〜ページＨ）のうち、２つのページ（ページＣ，ページＤ）に影響されるＳＱＬ更新命令を受け付けたとする。更新対象の２つのページは、更新する前にバックアップファイル２４としてコピーすることにより、退避される。
【００７０】
図４（ｂ）は、端末側受付更新の指示を実行し、ページを更新した後のページを示す。８つのページ（ページＡ〜ページＨ）のうち、２つのページ（ページＣ，ページＤ）が変更される。
【００７１】
図４（ｃ）は、センタ側受付更新の指示を受け付けたときに、その前準備としてページを書き戻す旨を示す。図４（ａ）で退避されていた２つのバックアップファイル２４（ページＣ，Ｄ）を、それぞれ該当箇所に上書きすることにより、高速なページ書き戻しが実現される。
【００７２】
図５は、更新差分ファイルの説明図である。この更新差分ファイル１４は、ＤＢ領域の各ページについて、更新前から更新後への更新処理を実施した結果、ページの書き換え（ページの追加、ページの削除、および、ページの内容変更）が行われたページを差分として抽出したものである。
【００７３】
更新差分ファイル１４は、センタ側受付更新を実行したセンタから各端末へと通知される。この通知において、更新されないページを含めて全てのページを一括して通知する方式に比べ、差分だけなのでデータ量が少なくて済む。
【００７４】
図５（ａ）に示す８ページのうち、４ページ（ページＢ，Ｄ，Ｇ，Ｈ）が変更され、２ページ（ページＩ，Ｊ）が追加されたとする。図５（ｂ）に示す更新差分ファイルがセンタから各端末へと通知され、各端末は通知された更新差分ファイルを、各自の端末ＤＢに反映する。これにより、図５（ｃ）に示すように端末ＤＢが更新される。
【００７５】
図６は、更新差分ファイルの合成処理を示す説明図である。複数の更新差分ファイル１４は、バージョン番号に従って、１つの更新差分ファイル１４へと合成することが可能である。例えば、更新差分ファイル１４Ｘはバージョン「７．０」→「８．０」の更新を行うためのものであり、更新差分ファイル１４Ｙはバージョン「８．０」→「９．０」の更新を行うためのものである。更新差分ファイル１４Ｘの更新後のバージョン「８．０」と、更新差分ファイル１４Ｙの更新前のバージョン「８．０」とが一致するため、両者は合成が可能である。
【００７６】
更新差分ファイル１４Ｘは、差分ページとして、ページ０１ａおよびページ０６を有する。更新差分ファイル１４Ｙは、差分ページとして、ページ０１ｂ、ページ０７、ページ０８を有する。ページ０１ａとページ０１ｂとは、ともに同じページ０１の位置に格納されるデータである。
【００７７】
更新差分ファイル１４Ｚは、更新差分ファイル１４Ｘおよび更新差分ファイル１４Ｙのいずれか一方にあるページの集合（ページ０６，０７，０８）を有する。さらに、更新差分ファイル１４Ｘおよび更新差分ファイル１４Ｙの双方で同じ位置にあるページ（ページ０１ａ、ページ０１ｂ）については、バージョン番号が新しい（大きい）更新差分ファイル１４Ｙのページ０１ｂが、更新差分ファイル１４Ｚに含まれる。
【００７８】
更新差分ファイル１４の合成処理により、センタ上で、すべてのバージョンのＤＢ領域を保持しておく必要がなくなり、ディスクサイズを節約することができる。新しく作成する更新差分ファイル１４Ｙについて、既に作成されている更新差分ファイル１４のうち、最も新しいものの更新後バージョン（例えば、更新差分ファイル１４Ｘの「８．０」）を、新しく作成する更新差分ファイル１４Ｙの更新前バージョンとする。その結果差分量が少なくて済むので、高速に更新差分ファイル１４Ｚを作成することができる。
【００７９】
例えば、バージョン「７．０」からバージョン「９．０」への更新など、バージョン番号が２バージョン以上離れているＤＢ領域への更新用の更新差分ファイル１４が必要になったら、バージョン「７．０」→「８．０」、および、「８．０」→「９．０」の更新差分ファイル１４Ｚを合成すればよい。
【００８０】
また、端末の更新元バージョンが統一されていない場合、センタは、それらの更新元バージョンごとに更新差分ファイル１４を合成する。なお、更新元バージョンをセンタが取得する方法として、センタ側で各端末の更新元バージョンを保持する方法、または、各端末から更新元バージョンを通知される方法がある。
【００８１】
図７は、センタおよび端末をそれぞれ構成するためのコンピュータのハードウェアを示す構成図である。コンピュータは、ＣＰＵ１０７ａ、ＮＩＣ（Network Interface Card）１０７ｂ、ＲＡＭ（Random Access Memory）などの主記憶装置１０７ｃ、および、ＨＤＤ（Hard Disk Drive）などの補助記憶装置１０７ｇを備える。
【００８２】
ＣＰＵ１０７ａは、主記憶装置１０７ｃ上のＯＳ（Operating System）１０７ｆおよびアプリケーションプログラムを実行することで、ＤＢＭＳ（Data Base Management System）１０７ｄを実現する。ＤＢＭＳ１０７ｄは、通信管理部１０７ｅを用いることで、ＮＩＣ１０７ｂを介して他装置とのデータ通信を行う。
【００８３】
なお、センタと端末とのデータのやりとりについて、図７で示すように、ＮＩＣを介するネットワークのデータ通信網を活用した通信処理を実現するかわりに、記憶媒体を用いてもよい。例えば、センタからのデータ出力（更新差分ファイルなど）をＤＶＤ−ＲＯＭ（Digital Versatile Disc-Read Only Memory）などの記憶媒体に書き込み、その記憶媒体が端末に挿入されると、端末は、記憶媒体からデータを読み取ることにより、データが入力される。
【００８４】
図８は、センタ１および端末２をそれぞれ構成するためのコンピュータの機能部に着目した構成図である。これらの各機能部は、図７の主記憶装置１０７ｃのＤＢＭＳ１０７ｄの内部または外部に搭載される。
【００８５】
センタ１は、ＤＢ管理部１１、ＤＢ領域１２、更新差分ファイル作成部１３、および、更新差分ファイル１４を有する。端末２は、ＤＢ管理部２１、ＤＢ領域２２、バックアップファイル作成部２３、バックアップファイル２４、ページ書き戻し部２５、ページ更新部２６、更新命令履歴管理部２７、および、更新命令履歴ファイル２８を有する。
【００８６】
ＤＢＭＳ内部に実装されるＤＢ管理部１１，２１は、ＤＢ領域１２，２２へのＳＱＬ処理要求を受け付けて、その要求に応じたデータ操作処理をＤＢ領域に対して実施する。ＳＱＬ処理要求は、論理構造であるテーブルおよびその中の行を指定する形式である。ここで、センタ１のＤＢ管理部１１はセンタ側受付更新を処理し、端末２のＤＢ管理部２１は端末側受付更新を処理する。
【００８７】
ＤＢ領域１２，２２は、図３で示すようなページを格納する記憶領域である。ＤＢ管理部１１，２１は、図２に示すように、論理構造であるテーブルに対するデータ操作処理を実施するときには、ＤＢ領域１２，２２内の物理構造であるページに対する操作に変換し、その操作を実行する。
【００８８】
更新差分ファイル作成部１３は、図５に示す更新差分ファイル１４を作成する。バックアップファイル作成部２３は、図４で示すバックアップファイル２４を作成する。ページ書き戻し部２５、および、ページ更新部２６は、それぞれ図２（ｂ）（ｄ）で説明した物理的更新を実行する。
【００８９】
更新命令履歴管理部２７は、図１（ｃ）の（１）端末側受付更新要求のＳＱＬ更新命令を更新命令履歴ファイル２８に記録した後、その要求をＤＢ管理部２１に通知する。また、図１（ｃ）の（４）端末側受付更新要求を再度実行のときには、更新命令履歴ファイル２８からＳＱＬ更新命令を読み取り、その要求をＤＢ管理部２１に通知する。
【００９０】
図９は、ＤＢ領域のデータ構造をツリー形式で示す説明図である。ツリーのルート方向を左側に配置している。また、ノード間には多重度を設定している。例えば、１つのＤＢ領域１２は、１つのページ管理情報と、１つ以上のページ個別情報とから構成される。
【００９１】
ページ管理情報は、１つのテーブルに関する情報を示す。前記したように、１つのテーブルは、１つ以上のページに格納されるが、このページ管理情報は、各ページに共通する情報を示す。ページ数は、テーブルを構成するページの数である。ページサイズは、固定長のページのディスクに格納するときの容量を示す。削除ページ番号は、更新前のＤＢ領域のあるページ番号以降のページを削除するための、削除を開始するページのページ番号を示す。更新フラグ配列は、後記する。
【００９２】
ページ個別情報は、１つのページに関する情報を示す。ページ番号は、ＤＢ領域中のページの位置を示す。
【００９３】
１つの更新フラグは、センタ１のＤＢ領域１２が更新されたか（値「１」）か、否か（値「０」）を設定する。更新フラグ配列は、更新フラグをまとめて配列にしたものである。ページ数分の更新フラグと、１つの更新フラグ配列とは同じ内容を示すので、後記するようにいずれか一方を構成すればよい。ページデータは、ページのデータ内容を示す。更新フラグ配列または更新フラグの値は、更新差分ファイル１４が作成されるときに参照される。更新差分ファイル１４が作成された後は、値「０」にクリアされる。
【００９４】
ＤＢ領域１２と、ＤＢ領域２２との違いは、ＤＢ領域１２における更新フラグが、ＤＢ領域２２におけるバックアップフラグに変更された点である。バックアップフラグは、ページが更新されたときに、そのページがバックアップファイル２４に退避されたか（値「１」）か、否か（値「０」）を設定する。
【００９５】
ページの更新処理について、最初の１回では、バックアップするページに対応するバックアップフラグを値「０（バックアップされていない）」から、値「１（バックアップされている）」へと変更する。２回目以降では、バックアップするページに対応するバックアップフラグを参照し、値「１」なら、バックアップ処理を省略する。そして、バックアップファイル２４が書き戻し処理に利用されたときには、値「０」へと戻し、使用して不要となったバックアップファイル２４を削除してもよい。
【００９６】
図１０は、図９で説明した更新フラグおよび更新フラグ配列の説明図である。図１０（ａ）に示す８つのページに対して、６カ所の更新（ページＢ，Ｄ，Ｇ，Ｈ，Ｉ，Ｊ）が行われたとする。図１０（ｂ）は、それらの更新の有無を更新フラグ配列としてまとめたものであり、図１０（ｃ）は、それらの更新の有無を各ページの左上に更新フラグとして個別に格納したものである。
【００９７】
図１１（ａ）は、図５に示す更新差分ファイル１４を格納するためのデータ構造を示す。１つの更新差分ファイル１４は、１つのバージョン情報と、１つのページ管理情報と、１つ以上の差分ページから構成される。
【００９８】
バージョン情報は、更新前バージョンおよび更新後バージョンの組から構成されている。バージョン情報は、バージョン番号や作成日といった情報から構成される。
【００９９】
ページ管理情報は、更新差分ファイル１４に格納されている差分ページに共通する情報である。ページ管理情報は、更新差分ファイル１４に格納しているページのページ数や、格納しているページのページサイズ、および物理センタ側受付更新処理時に、対象ＤＢ領域から削除するページの先頭ページ番号から構成されている。
【０１００】
差分ページは、ＤＢ領域中のページであり、更新後のページである。差分ページは、ページ番号順になっている。この差分ページを順番に更新先のＤＢ領域へコピーしていくようにすれば、ディスクヘッダの移動量を最小にでき更に更新処理の性能を高めることができる。また、各差分ページには、配置される該当箇所を示すページ番号が対応づけられている。よって、端末上でのＤＢ領域の更新処理としては、更新ページをページ番号で指定された場所にコピーしていくだけで済む。
【０１０１】
図１１（ｂ）は、図４に示すバックアップファイル２４を格納するためのデータ構造を示す。１つのバックアップファイル２４は、１つのバックアップ管理情報と、１つ以上のバックアップページから構成される。バックアップページは、ＤＢ領域から退避した更新前のページ内容を示す。
【０１０２】
バックアップ管理情報は、空き容量、ページサイズ、ページ数、および、新規ページ割り当て情報を有する。空き容量は、バックアップファイル２４の空き容量を記憶する領域である。
【０１０３】
ページサイズは、バックアップファイル２４で格納しているバックアップページの大きさ（ページサイズ）を記憶している領域である。ページ数は、バックアップファイル内のバックアップページの数を記憶する領域である。
【０１０４】
新規ページ割り当て情報は、ＤＢ領域を更新した過程において、ＤＢ領域を拡張し、新規ページを追加して割り当てたときの情報を記憶する領域である。割り当てフラグは、新規ページを追加した（値「１」）か、否か（値「０」）かを示すフラグである。開始位置は、追加した新規ページの開始位置を示すページ番号である。ページ数は、追加した新規ページのページ数である。
【０１０５】
図１２は、図１（ｃ）の「（３）センタ側受付更新」を実施するときのセンタ１および端末２の動作を示す説明図である。この図では、端末側受付更新が行われておらず、更新前バージョンがセンタ１および端末２で同一であるときを説明する。例えば、図１（ａ）の端末Ｂ，Ｃがこの図の説明に該当する。
【０１０６】
端末２のＤＢ領域２２は、一定期間以上を経るごとに、センタ１のＤＢ領域１２と内容の同一化を行う。端末２は、工場出荷時などのタイミングでＤＢ領域１２のコピーであるＤＢ領域２２を作成する。このときのデータベースの状態をバージョン「１．０」とする。
【０１０７】
センタ１のＤＢ管理部１１は、ＤＢ領域１２に対してセンタ側受付更新を繰り返し、適当な段階で、更新を一旦凍結する。そのときのＤＢ領域１２をバージョン「２．０」とする。そして、センタ１の更新差分データ作成部１３は、バージョン「１．０」とバージョン「２．０」との更新差分ファイル１４を抽出する。
【０１０８】
例えば、差分データ作成部１３は、あらかじめ退避しておいたバージョン「１．０」と、最新のバージョン「２．０」とをページごとに比較し、違いがあったページのバージョン「２．０」のページを更新差分ファイル１４に含める。
【０１０９】
端末２のページ更新部２６は、センタ１から更新差分ファイル１４を受け取ると、更新差分ファイル内にあるページを、ＤＢ領域２２内の該当するページ上に上書きする。この処理によって、センタ１および端末２のバージョンが同じ「２．０」となる。
【０１１０】
図１３は、図１（ｃ）の「（１）端末側受付更新」から「（４）端末側受付更新を再度実行」まで順に実施するときのセンタ１および端末２の動作を示す説明図である。この図では、端末側受付更新が行われることにより、更新前バージョンがセンタ１および端末２で不一致であるときを説明する。例えば、図１（ａ）の端末Ａがこの図の説明に該当する。
【０１１１】
まず、図１２で説明したように、センタ１のＤＢ領域１２と、端末２のＤＢ領域２２は、バージョン「１．０」とする。
【０１１２】
端末２のＤＢ管理部２１は、「（１）端末側受付更新」を実施する。具体的には、ＳＱＬ更新命令を受けつけると、その命令に基づいたデータ操作をＤＢ領域２２に対して行うことにより、バージョン「１．１」に更新する。ここで、バックアップファイル作成部２３は、バージョン「１．１」への更新を実行する前に、バージョン「１．０」のページをバックアップファイル２４に退避する。なお、バックアップフラグが「１」であるページは、既にバックアップされているので、重複してバックアップする必要はない。
【０１１３】
端末２のページ書き戻し部２５は、「（２）端末側受付更新の書き戻し」を実施する。具体的には、バージョン「１．０」のバックアップファイル２４を、バージョン「１．１」へ更新されたＤＢ領域２２に上書きすることにより、バージョン「１．０」に書き戻す。これにより、更新前バージョンがセンタ１および端末２で同一となる。
【０１１４】
センタ１は、図１３で説明したように「（３）センタ側受付更新」を実施する。これにより、ＤＢ領域２２は、バージョン「１．０」からバージョン「２．０」へと更新される。
【０１１５】
端末２の更新命令履歴管理部２７は、「（１）端末側受付更新」のときのＳＱＬ更新命令を更新命令履歴ファイル２８に記録しておき、その更新命令履歴ファイル２８を再度ＤＢ管理部２１に実行させることで、「（４）端末側受付更新を再度実行」を実施する。その結果、ＤＢ領域２２は、バージョン「２．０」からバージョン「２．１」へと更新される。
【０１１６】
図１４は、センタ１の更新差分データ作成部１３が更新差分ファイル１４を作成する処理を実現する３つの方式を説明するものである。この３つの方式のうち、いずれか１つの方式を適用することにより、更新差分ファイル１４は作成される。
【０１１７】
図１４（ａ）は、更新フラグを使用せず、全文比較する方式である。
【０１１８】
更新差分データ作成部１３は、更新前（バージョン「１．０」）のＤＢ領域の全データを退避しておき、ＳＱＬ更新命令を適用するときは、とくに何もしない。更新差分データ作成部１３は、更新差分ファイル１４の作成時に、更新前後の全データを互いに比較することにより、一致しないページを抽出し、更新差分ファイル１４を作成する。
【０１１９】
この方式により、ＳＱＬ更新命令を適用するときに処理が発生しないので、ＳＱＬ更新命令のスループットを向上させることができる。また、更新フラグを用いる必要がないため、単純なデータ構造で済むため、既存システムへの拡張による影響を少なくすることができる。
【０１２０】
図１４（ｂ）は、更新フラグをＤＢ領域のページ外に設定する方式である。更新差分データ作成部１３は、ＳＱＬ更新命令を適用するときは、更新されたページに対応する更新フラグを、ページ外の更新フラグ配列（図１０（ｂ）参照）に設定する。更新差分データ作成部１３は、更新差分ファイル１４の作成時に、更新フラグが設定された更新後のページを抽出し、更新差分ファイル１４を作成する。
【０１２１】
この方式により、更新フラグ配列を読み取ることにより、更新対象のページを特定するため、ページのデータ内容にアクセスする必要が無く、高速な更新差分ファイル１４の作成処理が可能となる。更新フラグ配列は、１カ所にまとまっているため、ディスクアクセスが高速となる。さらに、更新前（バージョン「１．０」）のＤＢ領域の全データを退避しておく必要がないため、ディスク容量を節約することができる。
【０１２２】
図１４（ｃ）は、更新フラグをＤＢ領域のページ内に設定する方式である。図１４（ｂ）との違いは、更新フラグ配列を用いる代わりに、ページ内に設定される更新フラグ（図１０（ｃ）参照）を用いることである。
【０１２３】
この方式により、図１４（ｂ）で説明したディスク容量の節約の効果に加え、更新フラグがページ単位の情報として埋め込まれており、更新フラグ配列のように別のデータを作成する必要がないため、既存システムからの変更量を少なくすることができ、開発コストを削減することができる。
【０１２４】
図１５は、端末２のＤＢ管理部２１が実行する端末側受付更新処理を示すフローチャートである。
【０１２５】
まず、ＳＱＬ更新命令を受け付け、更新対象のページをＤＢ領域から特定する（Ｓ１０１）。次に、特定したページのバックアップフラグが「１」か否かを判定する（Ｓ１０２）。Ｓ１０２でＹｅｓならＳ１０８に、ＮｏならＳ１０３に、それぞれ移行する。
【０１２６】
そして、バックアップファイル内の新規ページ割り当てフラグが「１」かつバックアップファイル内の新規ページ割り当て情報の開始位置が特定したページのページ番号より小さい（Ｓ１０３）か否かを判定する。Ｓ１０３でＹｅｓならＳ１０７に、ＮｏならＳ１０４に、それぞれ移行する。
【０１２７】
さらに、バックアップファイル内の空き容量が充分にある（Ｓ１０４）か否かを判定する。Ｓ１０４でＹｅｓならＳ１０６に、ＮｏならＳ１０５に、それぞれ移行する。そして、更新処理をエラー状態として中断し（Ｓ１０５）、処理を終了する。
【０１２８】
Ｓ１０４でＹｅｓのときは、特定したページのコピーをバックアップファイル内のバックアップページに格納する（Ｓ１０６）。そして、特定したページのバックアップフラグを「１」にする（Ｓ１０７）。そして、特定したページの内容を更新する（Ｓ１０８）。
【０１２９】
ここで、ＤＢ領域の空き領域が残り少ない（Ｓ１０９）か否かを判定する。Ｓ１０９でＹｅｓならＳ１１０に、Ｎｏなら処理終了に、それぞれ移行する。そして、Ｓ１０９でＹｅｓのときには、ＤＢ領域に新たにページを割り当て（Ｓ１１０）、新規ページ割り当て情報を更新し（Ｓ１１１）、処理を終了する。
【０１３０】
図１６（ａ）は、バックアップファイル作成部が実行するバックアップファイルの更新処理を示すフローチャートである。
【０１３１】
まず、バックアップファイル内の新規ページ割り当て情報の割り当てフラグが「１」（Ｓ２０１）か否かを判定する。Ｓ２０１でＹｅｓならＳ２０３に、ＮｏならＳ２０２に、それぞれ移行する。次に、バックアップファイル内の新規ページ割り当て情報について、開始位置を設定し、割り当てフラグを「１」にする（Ｓ２０２）。そして、バックアップファイル内の新規ページ割り当て情報について、ページ数の値に、今回割り当てるページ数を加算する（Ｓ２０３）。
【０１３２】
図１６（ｂ）は、ページ書き戻し部が実行するバックアップファイルを用いたページ書き戻し処理を示すフローチャートである。
【０１３３】
まず、バックアップファイルから、バックアップページをページ番号順に選択する（Ｓ３０１）。次に、選択したバックアップページをＤＢ領域上の同じページ番号をもつページに上書きコピーする（Ｓ３０２）。
【０１３４】
ここで、バックアップファイル内に未選択のバックアップページがある（Ｓ３０３）か否かを判定する。Ｓ３０３でＹｅｓならＳ３０１に、ＮｏならＳ３０４に、それぞれ移行する。また、バックアップファイル内の割り当てフラグが「１」（Ｓ３０４）か否かを判定する。Ｓ３０４でＹｅｓならＳ３０５に、ＮｏならＳ３０６に、それぞれ移行する。
【０１３５】
そして、バックアップファイル内の開始位置のページ番号以降のページ番号をもつ、ＤＢ領域上のページをすべて削除する（Ｓ３０５）。さらに、バックアップファイルをクリア、つまり、空き容量をファイルのサイズに、ページ数を「０」に、新規ページ割り当て情報を０クリアする（Ｓ３０６）。
【０１３６】
図１７は、更新差分ファイル作成部が実行する更新差分ファイルの作成処理のうち、更新フラグを使用せず全文比較する方式（図１４（ａ）参照）を示すフローチャートである。
【０１３７】
まず、更新後のＤＢ領域に未選択のページが存在する（Ｓ４０１）か否かを判定する。Ｓ４０１でＹｅｓならＳ４０２に、ＮｏならＳ４０７に、それぞれ移行する。次に、更新後のＤＢ領域から未選択のページを選択する（Ｓ４０２）。そして、選択した更新後のページと同じページ番号のページが更新前のＤＢ領域に存在（Ｓ４０３）するか否かを判定する。Ｓ４０３でＹｅｓならＳ４０４に、ＮｏならＳ４０６に、それぞれ移行する。
【０１３８】
そして、更新前のＤＢ領域から同じページ番号のページを選択する（Ｓ４０４）。ここで、選択した更新前および更新後のページの内容が互いに一致（Ｓ４０５）するか否かを判定する。Ｓ４０５でＹｅｓならＳ４０１に、ＮｏならＳ４０６に、それぞれ移行する。さらに、更新後のＤＢ領域から選択したページを差分ページとして、更新差分ファイルに格納し（Ｓ４０６）、Ｓ４０１に戻る。
【０１３９】
ところで、Ｓ４０１でＮｏなら、更新前のＤＢ領域に未選択のページが存在する（Ｓ４０７）か否かを判定し、Ｓ４０７でＹｅｓなら、未選択ページの最初のページを削除開始ページとして設定する（Ｓ４０８）。
【０１４０】
図１８（ａ）は、更新差分ファイルの作成処理のうち、更新フラグをページ外に設定する方式（図１４（ｂ）参照）を実行するための、ＤＢ管理部が更新時に実行する更新フラグ設定処理を示すフローチャートである。
【０１４１】
まず、更新ページを特定し（Ｓ５０１）、その特定したページを書き換える（Ｓ５０２）。次に、ページ外に位置する更新フラグ配列で、特定したページのページ番号に対応するビットを「１」に変更する（Ｓ５０３）。他に更新するページが存在するときには（Ｓ５０４、Ｙｅｓ）、その更新するページについてＳ５０１に戻って処理を実行する。
【０１４２】
図１８（ｂ）は、更新差分ファイルの作成処理のうち、図１８（ａ）で設定された更新フラグをもとに、更新差分ファイル作成部が実行する更新差分ファイルの作成処理を示すフローチャートである。
【０１４３】
まず、更新フラグ配列の中で値が「１」であるビットが存在しないときには（Ｓ５１１、Ｎｏ）処理を終了する。次に、更新フラグ配列の中の値が「１」であるビットの配列位置から対応するページ番号を求める（Ｓ５１２）。そして、求めたページ番号をもつ書き換えたページをＤＢ領域から取り出し、そのページを更新差分ファイルの差分ページに追加し（Ｓ５１３）、処理をＳ５１１に戻す。
【０１４４】
図１９（ａ）は、更新差分ファイルの作成処理のうち、更新フラグをページ内に設定する方式（図１４（ｃ）参照）を実行するための、ＤＢ管理部が更新時に実行する更新フラグ設定処理を示すフローチャートである。
【０１４５】
まず、更新ページを特定し（Ｓ６０１）、その特定したページを書き換える（Ｓ６０２）。次に、特定したページに対応するページ個別情報の更新フラグを、値「１」に変更する（Ｓ６０３）。他に更新するページが存在するなら（Ｓ６０４、Ｙｅｓ）、その更新するページについてＳ６０１に戻って処理を実行する。
【０１４６】
図１９（ｂ）は、更新差分ファイルの作成処理のうち、図１６（ａ）で設定された更新フラグをもとに、更新差分ファイル作成部が実行する更新差分ファイルの作成処理を示すフローチャートである。
【０１４７】
まず、ＤＢ領域中のページを先頭から順番に１ページ選択する（Ｓ６１１）。次に、選択したページに対応するページ個別情報の更新フラグが「１」（Ｓ６１２）か否かを判定する。Ｓ６１２でＹｅｓならＳ６１３に、ＮｏならＳ６１５に、それぞれ移行する。
【０１４８】
そして、選択したページのコピーをＤＢ領域から取り出し、そのページを更新差分ファイルの差分ページに追加する（Ｓ６１３）。さらに、選択したページの更新フラグを「０」に戻す（Ｓ６１４）。ここで、選択していないページが存在する（Ｓ６１５）か否かを判定する。Ｓ６１５でＹｅｓならＳ６１１に、Ｎｏなら処理終了に、それぞれ移行する。
【０１４９】
図２０は、ページ更新部が実行するセンタ側受付更新処理のページ更新処理を示すフローチャートである。
【０１５０】
まず、更新差分ファイルからページ番号順に差分ページを選択する（Ｓ７０１）。次に、選択した差分ページをＤＢ領域上の同じページ番号をもつページ上に上書きコピーする（Ｓ７０２）。ここで、未選択の差分ページがあるときには（Ｓ７０３，Ｙｅｓ）、処理をＳ７０１に戻し、ないときには（Ｓ７０３，Ｎｏ）、処理を終了する。
【０１５１】
図２１は、本実施例におけるセンタおよび端末について、それぞれ実現するコンピュータの構成を示す。コンピュータは、ＣＰＵ１０７ａ、ＮＩＣ（Network Interface Card）１０７ｂ、ＲＡＭ（Random Access Memory）などの主記憶装置１０７ｃ、および、ＨＤＤ（Hard Disk Drive）などの補助記憶装置１０７ｇを備える。
【０１５２】
ＣＰＵ１０７ａは、主記憶装置１０７ｃ上のＯＳ（Operating System）１０７ｆおよびアプリケーションプログラムを実行することで、ＤＢＭＳ（Data Base Management System）１０７ｄを実現する。ＤＢＭＳ１０７ｄは、通信管理部１０７ｅを用いることで、ＮＩＣ１０７ｂを介して他装置とのデータ通信を行う。
なお、ＤＢＭＳ１０７ｄは、データベース管理部に該当する。データベース管理部は、データベースの論理構造データに対するデータアクセスを実行する。論理構造データは、例えば、図２で示したように、テーブル形式としてもよいし、ＸＭＬ（Extensible Markup Language）データの格納に適したツリー構造のデータなど、他の形式としてもよい。
【０１５３】
なお、センタと端末とのデータのやりとりについては、ＮＩＣを介するネットワークのデータ通信網を活用した通信処理を実現するかわりに、記憶媒体を用いてもよい。例えば、センタからのデータ出力（更新差分ファイルなど）をＤＶＤ−ＲＯＭ（Digital Versatile Disc-Read Only Memory）などの記憶媒体に書き込み、その記憶媒体が端末に挿入されると、端末は、記憶媒体からデータを読み取ることにより、データが入力される。
【０１５４】
センタ１は、ＤＢＭＳ１０７ｄの構成としてＤＢ管理部１１、および、更新差分ファイル作成部１３を有し、補助記憶装置１０７ｇの構成としてＤＢ領域１２、および、更新差分ファイル１４を有する。本実施例では、ＤＢ管理部１１、更新差分ファイル作成部１３は、プログラムで実現した一例を示しているが、オブジェクト、その機能を有するハードウェアで実現しても良い。
【０１５５】
端末２は、ＤＢＭＳ１０７ｄの構成としてＤＢ管理部２１、バックアップファイル作成部２３、ページ書き戻し部２５、ページ更新部２６、および、更新命令履歴管理部２７を有し、補助記憶装置１０７ｇの構成としてＤＢ領域２２、バックアップファイル２４、および、更新命令履歴ファイル２８を有する。本実施例では、ＤＢ管理部２１、バックアップファイル作成部２３、ページ書き戻し部２５、ページ更新部２６および更新命令履歴管理部２７は、プログラムで実現した一例を示しているが、オブジェクト、その機能を有するハードウェアで実現しても良い。これらのプログラムは、CD―ROMやDVD-ROMなどの記憶媒体に記憶し、本システムを稼動する前に記憶装置にインストールしても良い。
【０１５６】
ＤＢＭＳ内部に実装されるＤＢ管理部１１，２１は、ＤＢ領域１２，２２へのＳＱＬ処理要求を受け付けて、その要求に応じたデータ操作処理をＤＢ領域に対して実施する。ＳＱＬ処理要求は、論理構造であるテーブルおよびその中の行を指定する形式である。ここで、センタ１のＤＢ管理部１１はセンタ側受付更新を処理する。
【０１５７】
端末２におけるＤＢ管理部２１は端末側受付更新を処理する。
【０１５８】
ＤＢ領域１２，２２は、図３で示すようなページを格納する記憶領域である。ＤＢ管理部１１，２１は、図２に示すように、論理構造であるテーブルに対するデータ操作処理を実施するときには、ＤＢ領域１２，２２内の物理構造であるページに対する操作に変換し、その操作を実行する。
【０１５９】
更新差分ファイル作成部１３は、図５に示す更新差分ファイル１４を作成する。バックアップファイル作成部２３は、図４で示すバックアップファイル２４を作成する。ページ書き戻し部２５、および、ページ更新部２６は、それぞれ図２（ｂ）（ｄ）で説明した物理的更新を実行する。
【０１６０】
更新命令履歴管理部２７は、図１（ｃ）の（１）「端末側受付更新要求」のＳＱＬ更新命令を更新命令履歴ファイル２８に記録した後、その要求をＤＢ管理部２１に通知する。また、図１（ｃ）の（４）「端末側受付更新要求」を再度実行のときには、更新命令履歴ファイル２８からＳＱＬ更新命令を読み取り、その要求をＤＢ管理部２１に通知する。
なお、図１（ｃ）の（４）「端末側受付更新要求」を再度実行する動作主体について、端末２としてもよいし、センタ１としてもよい。センタ１が「端末側受付更新要求」を再度端末２に実行させるときには、その旨を示す制御命令を端末２に送信する。端末２は、制御命令の受信を待ってから、自らが過去に受信した「端末側受付更新要求」を再度適用する。
【図面の簡単な説明】
【０１６１】
【図１】本実施形態に関するデータベースシステム全体の概要を示す説明図である。
【図２】本実施形態に関するＲＤＢにおける論理構造のテーブルと、物理構造のページとの関係を示す説明図である。
【図３】本実施形態に関する２種類の更新を併用する旨を示す説明図である。
【図４】本実施形態に関するバックアップファイルを示す説明図である。
【図５】本実施形態に関する更新差分ファイルを示す説明図である。
【図６】本実施形態に関する更新差分ファイルの合成処理を示す説明図である。
【図７】本実施形態に関するセンタおよび端末のハードウェア構成を示す構成図である。
【図８】本実施形態に関するセンタおよび端末の機能構成を示す構成図である。
【図９】本実施形態に関するＤＢ領域のデータ構造を示す説明図である。
【図１０】本実施形態に関する更新フラグおよび更新フラグ配列を示す説明図である。
【図１１】本実施形態に関する更新差分ファイルおよびバックアップファイルのデータ構造を示す説明図である。
【図１２】本実施形態に関するセンタ側受付更新の動作を示す説明図である。
【図１３】本実施形態に関する端末側受付更新から端末側受付更新を再度実行まで順に実施するときの動作を示す説明図である。
【図１４】本実施形態に関する更新差分ファイルを作成する３つの方式を示す説明図である。
【図１５】本実施形態に関する端末側受付更新処理を示すフローチャートである。
【図１６】本実施形態に関するバックアップファイルの更新処理およびそのバックアップファイルを用いたページ書き戻し処理を示すフローチャートである。
【図１７】本実施形態に関する更新差分ファイルの作成処理のうち、更新フラグを使用せず全文比較する方式を示すフローチャートである。
【図１８】本実施形態に関する更新差分ファイルの作成処理のうち、更新フラグをページ外に設定する方式を示すフローチャートである。
【図１９】本実施形態に関する更新差分ファイルの作成処理のうち、更新フラグをページ内に設定する方式を示すフローチャートである。
【図２０】本実施形態に関するセンタ側受付更新処理のページ更新処理を示すフローチャートである。
【図２１】本実施形態に関するセンタおよび端末のコンピュータの構成を示す構成図である。
【符号の説明】
【０１６２】
１      センタ
１１    ＤＢ管理部
１２    ＤＢ領域
１３    更新差分ファイル作成部
１４    更新差分ファイル
２      端末
２１    ＤＢ管理部
２２    ＤＢ領域
２３    バックアップファイル作成部
２４    バックアップファイル
２５    ページ書き戻し部
２６    ページ更新部
２７    更新命令履歴管理部
２８    更新命令履歴ファイル
【図１】
0005108637.tif 000003
【図２】
0005108637.tif 000004
【図３】
0005108637.tif 000005
【図４】
0005108637.tif 000006
【図５】
0005108637.tif 000007
【図６】
0005108637.tif 000008
【図７】
0005108637.tif 000009
【図８】
0005108637.tif 000010
【図９】
0005108637.tif 000011
【図１０】
0005108637.tif 000012
【図１１】
0005108637.tif 000013
【図１２】
0005108637.tif 000014
【図１３】
0005108637.tif 000015
【図１４】
0005108637.tif 000016
【図１５】
0005108637.tif 000017
【図１６】
0005108637.tif 000018
【図１７】
0005108637.tif 000019
【図１８】
0005108637.tif 000020
【図１９】
0005108637.tif 000021
【図２０】
0005108637.tif 000022
【図２１】
0005108637.tif 000023