JPH07234812A - 分散システムにおけるデータコンペア方式 - Google Patents

Abstract

(57)【要約】 【目的】 少ない転送量で、かつ短時間で高精度なデー
タ整合性を保証する分散システムにおけるデータコンペ
ア方式を提供する。 【構成】 ホスト計算機において、更新前及び更新後の
ファイル全体チェックサム、レコード更新に関する情報
を含む更新レコードから成る更新ログファイルと、レコ
ードの変更件数に関する管理情報を含む管理ファイル
と、を生成、更新し分散計算機に転送する。分散計算機
において、転送された更新ログファイルに含まれる更新
レコードに従い自計算機のマスタファイルのレコード更
新を行うとともに更新ログファイル及び管理ファイルを
生成、更新する。レコード更新の際に算出された更新前
及び更新後のファイル全体チェックサム、更新後トータ
ルレコード件数等の各データと、ホスト計算機から転送
された当該各データと、をコンペアすることによりデー
タの整合性を確認する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は分散システムにおいて、
主局のデータベースの内容と各従局のデータベースの内
容とをより少ないデータ転送量でかつより短時間で比較
しうるデータコンペア方式に関する。

【０００２】

【従来の技術】１つの主局たるホスト計算機と従局たる
１乃至複数の分散計算機から成る分散システムにおい
て、そのうち、例えば商品管理システムにおける商品在
庫データベース、証明書自動交付装置システムにおける
住民記録データベース等においては、各分散計算機にお
いてもホスト計算機が有するデータベースの内容とある
時点において全く同一内容のデータベースを持たなくて
はならない。

【０００３】従来、各計算機の有するデータベースの内
容が同一であることを確認する方法として、ホスト計算
機が有するデータベースの全データを各分散計算機に転
送し、比較していた。

【０００４】また、特開昭６３−２７８１５５号公報に
は、データベース更新の際に更新ログ情報を収集して他
の計算機システムに転送し、他の計算機システムでは、
自計算機システムの更新ログ情報と転送された更新ログ
情報との差分を取ることでマージした後、レコードを更
新しデータ整合性を保証する構成が開示されている。

【０００５】また、特開平２−２９４７６５号公報に
は、データベースの更新回数を管理して、ホストシステ
ムにおける更新回数と分散システムにおける更新回数と
を比較してデータの整合性を図る構成が開示されてい
る。

【０００６】

【発明が解決しようとする課題】しかしながら、従来の
全データを転送しデータを比較する方式では、データの
転送に時間がかかり、また、データの比較にも多くの時
間がかかってしまうという問題があった。証明書自動交
付装置システムの有するマスタファイルは、１千文字程
度のレコードサイズのレコードを１万件以上のデータを
有しており、ピーク時には１日１千件以上にのぼること
もあるのでより少ない転送量で、かつ迅速なデータコン
ペア方式が望まれる。

【０００７】また、更新ログ情報の差分を取り最新のデ
ータでのみレコードを更新してしまうと、レコードが更
新される順番も重要なデータであるシステムには流用す
ることはできないという問題があった。

【０００８】また、更新回数のみの比較では、偶然によ
る一致の場合異常であることを発見することはできない
という問題があった。

【０００９】本発明は以上のような問題を解決するため
になされたものであり、その目的は、少ない転送量で、
かつ短時間で高精度なデータ整合性を保証する分散シス
テムにおけるデータコンペア方式を提供することにあ
る。

【００１０】

【課題を解決するための手段】以上のような目的を達成
するために、請求項１記載の発明は、主局と少なくとも
１つ以上の従局とを有し各局それぞれにデータベースを
有する分散システムにおいて前記主局のデータベースの
データと前記各従局のデータベースのデータとを比較す
るデータコンペア方式において、前記各従局は、チェッ
クサムデータとレコード変更件数に関する管理情報とに
よりデータを比較することを特徴とする。

【００１１】請求項２記載の発明は、請求項１記載の分
散システムにおけるデータコンペア方式において、前記
チェックサムデータは、レコード更新毎に作成されるレ
コード更新前のチェックサムデータと当該レコード更新
後のチェックサムデータとを含むことを特徴とする。

【００１２】請求項３記載の発明は、請求項２記載の分
散システムにおけるデータコンペア方式において、前記
各従局は、自局で算出するレコード更新前及びレコード
更新後のチェックサムデータと、前記主局のレコード更
新前及びレコード更新後のチェックサムデータと、をレ
コード更新毎にそれぞれ比較することを特徴とする。

【００１３】請求項４記載の発明は、主局と少なくとも
１つ以上の従局とを有し各局それぞれにデータベースを
有する分散システムにおいて前記主局のデータベースの
データと前記各従局のデータベースのデータとを比較す
るデータコンペア方式において、前記主局は、レコード
更新に関する更新情報と、レコードの変更件数に関する
管理情報と、チェックサムデータと、を前記各従局に転
送することを特徴とする。

【００１４】請求項５記載の発明は、請求項１乃至４記
載の分散システムにおけるデータコンペア方式におい
て、前記チェックサムデータは、データベースに記録さ
れているレコード毎に求められたチェックサムから算出
するファイル全体チェックサムを含むことを特徴とす
る。

【００１５】

【作用】以上のように、本発明に係るデータコンペア方
式においては、主局から各従局に対して更新情報と管理
情報とチェックサムデータとのみを転送する。更新情報
にはレコード更新前及びレコード更新後のチェックサム
データが含まれている。管理情報にはレコード変更件数
が、また、チェックサムデータにはファイル全体チェッ
クサムが含まれている。

【００１６】各従局では、主局の更新情報に従いデータ
ベースの内容を更新する。更新により作成された管理情
報及びチャックサムデータと、主局に関する管理情報及
びチャックサムデータと、を比較することで更新終了時
におけるデータの整合性を確認することができる。

【００１７】また、各従局において、更新時に作成され
るレコード更新前及びレコード更新後のチェックサムデ
ータと、主局の更新情報に含まれるレコード更新前及び
レコード更新後のチェックサムデータと、を１レコード
更新毎に比較することでデータの整合性を確認すること
ができる。

【００１８】また、更新情報と管理情報とチャックサム
データとのみでデータの整合性を確認することができる
ので、主局から各従局へのデータ転送量を少なくするこ
とができる。

【００１９】

【実施例】以下、図面に基づいて、本発明の好適な実施
例を説明する。

【００２０】図１は、本発明に係るデータコンペア方式
が実施される分散システムの構成図である。ホスト計算
機２は、実際のデータが格納されているマスタファイル
４と、マスタファイル４の内容（レコード）を更新する
際のログ等レコード更新に関する更新情報を収集する更
新ログファイル６と、マスタファイル４内のレコードの
変更件数に関する変更情報、後述するファイル全体チェ
ックサム等のデータを管理するマスタファイル管理ファ
イル（以下、管理ファイルという）８と、を有する。分
散計算機１２は、ホスト計算機２と同様のマスタファイ
ル１４と更新ログファイル１６と管理ファイル１８とを
有する。ホスト計算機２と分散計算機１２とは、公衆回
線等を介して接続されている。なお、分散計算機１２
は、複数有する場合もあるが、全ての分散計算機におい
て同様に動作するので本実施例においては１台のみで説
明する。また、マスタファイル４、１４は各計算機２、
１２に複数個作成されてもよいが、説明上、各計算機
２、１２に各１つで説明する。

【００２１】チェックサムの計算方法 本実施例においては、チェックサムを有効に使用するこ
とでデータ転送量並びに高精度なデータコンペアを行う
データ数をより少なくすることを特徴とする。以下、本
実施例におけるチェックサムの計算方法について図２、
３を用いて説明する。

【００２２】取り扱うデータが数字のみであればそのま
ま数字データとして取り扱えばよいが、例えば住民票等
の証明書自動交付装置システムにおいては漢字等の文字
データをも取り扱う必要がある。この場合、文字データ
をＥＢＣＤＩＣ、ＪＩＳコード等で取り扱えばよい。本
実施例においては１レコードがカナ文字データと数字デ
ータとで生成された例で説明する。

【００２３】図２は、マスタファイル４に格納されてい
るレコードの内容を示した図である。各レコードはカナ
文字データ９文字と数字データ６桁とで構成されてい
る。図３は、カナ文字データを数字データに変換するた
めに用いるテーブルの例を示す。本実施例では、計算し
やすいように５行１０列の１０進数コードで表現する。
なお、スペースは‘００’とする。

【００２４】図３のテーブルを用いてカナ文字データを
数字データに変換する。例えば、「アイカワ イチロ
ウ」は「０１，０２，１１，９１，００，０２，３２，
８５，０３」と変換される。この数字データと数字デー
タ「０６４０００」とで生成されたレコードを一定単位
に区切り、その単位毎を数値に見立てて総和を算出する
ことでレコード単位チェックサムを算出する。この例で
は、８ずつに区切り‘０１０２１１９１’、‘０００２
３２８５’、‘０３０６４０００’とし、その総和１０
２１１９１＋２３２８５＋３０６４０００＝４１０８４
７６がこのレコードのレコード単位チェックサムとな
る。

【００２５】次に、ファイル全体チェックサムは、レコ
ード毎に算出したレコード単位チェックサムの総和を算
出することで求める。図２によれば、４１０８４７６＋
３６８７９２９５＋、・・・、＋７２７４７６９９＝４
８６０６３７０３となる。なお、本実施例におけるチェ
ックサムは８桁までを有効桁数としているので、ファイ
ル全体チェックサムは、最上位桁の‘４’を無視し８６
０６３７０３となる。

【００２６】このようにして、容量の大小に関係なく各
データベースにたった１つのチェックサムを算出するこ
とができる。

【００２７】更新ログファイルの生成、更新 図４は、更新ログファイル６、１６の内容を示した図で
ある。本実施例における更新ログファイル６、１６は、
計算機２、１２毎に１つ生成される。この更新ログファ
イル６、１６には、マスタファイル４、１４のレコード
が更新される度に更新ログ情報として１つのレコード
（以下、更新レコードという）が生成される。更新レコ
ード６０は、「追加」、「変更」、「削除」等の更新種
別６０ａと、「更新未」、「更新済ＯＫ」、「更新済Ｎ
Ｇ」を示す更新フラグ６０ｂと、マスタファイル名６０
ｃと、更新レコードキー６０ｄと、を含む。また、前述
したファイル全体チェックサムであって、レコードを更
新する前に算出した更新前ファイル全体チェックサム６
０ｅと、レコードを更新した後に算出した更新後ファイ
ル全体チェックサム６０ｆと、を含む。更に、更新後の
全レコード件数を示す更新後トータルレコード件数６０
ｇと、更新後における種別毎のレコード件数６０ｈ、６
０ｉ、６０ｊと、更新後の実際のレコードの内容を示す
更新後レコード内容６０ｋと、を含む。

【００２８】図５は、ホスト計算機２における更新ログ
ファイル６への更新レコード６０の生成処理及び後述す
る管理ファイル８の更新レコードの更新処理を示したフ
ローチャートであり、更に主なデータの流れをも示して
いる。

【００２９】以下、ホスト計算機２において更新レコー
ド６０が生成される動作について図５のフローチャート
を用いて説明する。

【００３０】マスタファイル４のレコード更新が発生す
ると、更新レコードが生成され、更新ログファイル６に
収集され順次蓄積される。ステップ１０１においては、
この更新レコード６０に更新種別６０ａ、マスタファイ
ル名６０ｃ、更新レコードキー６０ｄ、更新後レコード
内容６０ｋ、がセットされる。ステップ１０２におい
て、更新対象となるレコードのレコード単位チェックサ
ムを算出する。ステップ１０３において、更新前ファイ
ル全体チェックサム６０ｅを算出するが、もし、マスタ
ファイルを初めて生成するケースでなければ、直前の更
新レコード６０の更新後ファイル全体チェックサム６０
ｆあるいは後述するファイル全体チェックサム８０ａを
流用することができる。ステップ１０４において、計算
済みのレコード単位チェックサムを用いて更新後ファイ
ル全体チェックサム６０ｆを算出する。更新後ファイル
全体チェックサム６０ｆは、更新前ファイル全体チェッ
クサム６０ｅから対象となるレコードの更新前のレコー
ド単位チェックサムを減算し、更新後のレコード単位チ
ェックサムを加算することで容易に算出することができ
る。ステップ１０５において、更新後トータルレコード
件数６０ｇを算出する。これは、更新種別６０ａが「追
加」であれば１を加算、「変更」であれば変更せず、
「削除」であれば１を減算する。ステップ１０６におい
ては、更新種別６０ａに対応したレコード件数に１を加
算する。すなわち、更新種別６０ａが「追加」であれば
更新後追加レコード件数６０ｈに、「変更」であれば更
新後変更レコード件数６０ｉに、「削除」であれば更新
後削除レコード件数６０ｊに、１を加算する。

【００３１】ここで、更新フラグ６０ｂに「更新未」を
セットし（ステップ１０７）、マスタファイル４のレコ
ードを実際に更新し（ステップ１０８）、その後、更新
フラグ６０ｂを正常終了であれば「更新ＯＫ」をセット
する（ステップ１０９）。

【００３２】このようにして、レコード更新のある度に
更新レコードを収集し順次蓄積していくことで更新ログ
ファイル６を更新する。なお、分散計算機１２において
もほぼ同様に更新ログファイル１６を生成する。

【００３３】前述したように、各更新ログファイル６、
１６には、計算機２、１２毎に１つ生成されるため複数
のマスタファイルが存在してもいいようにマスタファイ
ル名６０ｃのフィールドが設けられているが、マスタフ
ァイル名６０ｃのフィールドを削除し、複数ある各マス
タファイルそれぞれに対応させて複数個の更新ログファ
イルを生成するようにしてもよい。

【００３４】管理ファイルの生成、更新 図６は、管理ファイル８、１８の内容を示した図であ
る。本実施例における管理ファイル８、１８は、計算機
２、１２毎に１つ生成され、各管理ファイル８、１８に
は、各計算機２、１２に存在するマスタファイルの数の
レコード（以下、管理レコードという）が作成される。
前述した更新ログファイル６、１６がレコード更新前後
に関する情報に対して、管理ファイル８、１８は、マス
タファイル４、１４の現時点の内容に関する情報を有し
ている。従って、更新ログファイル６、１６のレコード
更新後に関するデータは、管理ファイル８、１８の内容
と一部重複する。更新レコード８０は、前述したファイ
ル全体チェックサム８０ａと、「ＯＫ」、「ＮＧ」、
「未チェック」を示すチェック結果フラグ８０ｂと、マ
スタファイル内の全レコード数を示すトータルレコード
件数８０ｃと、更新種別毎のレコード件数８０ｄ、８０
ｅ、８０ｆと、を含む。

【００３５】以下、ホスト計算機２において管理ファイ
ル８の管理レコードが更新される動作について図５のフ
ローチャートを用いて説明する。

【００３６】前述したように、マスタファイル４が更新
されると（ステップ１０７）、ステップ１１１におい
て、上記方法でファイル全体チェックサム８０ａを算出
する。これは、更新ログファイル６にセットされた更新
後ファイル全体チェックサム６０ｆを流用することがで
きる。ステップ１１２において、現時点におけるマスタ
ファイル４内の全レコード件数（トータルレコード件
数）８０ｃを算出する。これは、直前のトータルレコー
ド件数８０ｃに更新種別が「追加」の場合は１を加算、
「削除」の場合は１を減算することで求めることができ
る。「変更」の場合は加減しない。ステップ１１３にお
いて、更新種別に対応したレコード件数８０ｄ、８０
ｅ、８０ｆに加算する。すなわち、「追加」であれば追
加レコード件数８０ｄに、「変更」であれば変更レコー
ド件数８０ｅに、「削除」であれば削除レコード件数８
０ｆに、１を加算する。その後、ステップ１１４におい
て、チェック結果フラグ８０ｂに「未チェック」をセッ
トする。

【００３７】このようにして、レコード更新がある度に
管理ファイル８内のレコード更新されたマスタファイル
に対応した管理レコード８０が更新される。なお、分散
計算機１２においても同様に管理ファイル１８が生成さ
れ、管理レコード８０が更新される。

【００３８】前述したように、各管理ファイル８、１８
は、計算機２、１２毎に１つ作成されるているが、各マ
スタファイルそれぞれに対応させて複数個の管理ファイ
ルを作成するようにしてもよい。

【００３９】なお、詳細は後述するが、管理ファイル８
を分散計算機１２に転送するときまでに更新を終了させ
ておけばよいので、上記のようにレコード更新毎に更新
しなくてもデータ転送時に作成するようにしてもよい。

【００４０】また、更新ログファイル６、１６と管理フ
ァイル８、１８との重複部分は、適当に運用することで
いずれかのデータを削除してもよい。

【００４１】データコンペア方式の動作 以下、本実施例における動作について説明する。

【００４２】前述したように、ホスト計算機２において
レコード更新が発生すると、前述したように、更新ログ
ファイル６と管理ファイル８とを生成、更新する。そし
て、一定のタイミング（例えば日次処理）あるいは要求
によりホスト計算機２から各分散計算機１２にデータを
転送する。

【００４３】本実施例において特徴的なことは、この転
送されるデータは、更新レコード６０を含む前記更新ロ
グファイル６と、管理レコード８０を含む管理情報前記
管理ファイル８と、のみであることである。これによ
り、データベース全体のデータを転送する必要がなく、
より少ない転送量ですむ。従って、転送にかかる時間の
短縮化を図ることができる。また、使用する通信サービ
スによっては通信料金の削減にもつながる。

【００４４】図７は、分散計算機１２における更新ログ
ファイル１６への更新レコード６０の生成処理及び管理
ファイル１８の更新レコード８０の更新処理を示したフ
ローチャートであり、更に主なデータの流れをも示して
いる。

【００４５】以下、分散計算機１２におけるデータコン
ペア方式の動作について説明する。

【００４６】分散計算機１２は、ホスト計算機２からデ
ータを受信すると、分散計算機１２におけるマスタファ
イル１４の更新を開始する。この更新処理は、ホスト計
算機２から受信した更新ログファイル１６に従って行わ
れる。まず、ステップ２０１において、受信した更新ロ
グファイルから更新レコード６０を読み取る。ステップ
２０２においては、更新ログファイル１６に生成され、
受信した更新レコード６０に従い更新処理を行う。この
更新処理、すなわち更新ログファイル１６内への更新レ
コード６０の生成は、前述したのと同様、該当するレコ
ードのレコード単位チェックサムの算出、更新前ファイ
ル全体チェックサム６０ｅの算出、更新後ファイル全体
チェックサム６０ｆの算出、更新後トータルレコード件
数６０ｇの算出、更新種別６０ａに対応したレコード件
数６０ｈ、６０ｉ、６０ｊの加算、を行う。ステップ２
０３においては、マスタファイル名６０ｃに指定された
マスタファイルの当該レコードの更新を行う。なお、更
新フラグ６０ｂに関しては後述する。ステップ２０４に
おいては管理ファイル１８の管理レコード８０の更新を
行う。この更新処理は、前述したのと同様、ファイル全
体チェックサム８０ａの算出、トータルレコード件数８
０ｃの算出、更新種別に対応したレコード件数８０ｄ、
８０ｅ、８０ｆいずれかの加算、を行う。なお、チェッ
ク結果フラグ８０ｂに関しては後述する。

【００４７】次に、ホスト計算機２から送られてきた更
新ログファイル６及び管理ファイル８と、分散計算機１
２において前述した手順で生成、更新された更新ログフ
ァイル１６及び管理ファイル１８と、を比較する。ま
ず、更新前ファイル全体チェックサム６０ｅを比較し
（ステップ２０５）、一致していなければ更新フラグ６
０ｂに「更新済ＮＧ」をセットする（ステップ２０
６）。同様に、更新後ファイル全体チェックサム６０
ｆ、更新後トータルレコード件数６０ｇ、更新種別６０
ａに対応したレコード件数６０ｈ、６０ｉ、６０ｊ、を
比較し（ステップ２０７、２０９、２１１）、一致して
いなければ更新フラグ６０ｂに「更新済ＮＧ」をセット
する（ステップ２０８、２１０、２１２）。なお、更新
レコード６０の更新後ファイル全体チェックサム６０ｆ
と管理レコード８０のファイル全体チェックサム８０
ａ、また、更新レコード６０の更新後トータルレコード
件数６０ｇと管理レコード８０のトータルレコード件数
８０ｃ、更には更新種別６０ａに対応したレコード件数
６０ｈ、６０ｉ、６０ｊとレコード件数８０ｄ、８０
ｅ、８０ｆ、は同じデータとなるので管理ファイルの比
較として取り扱ってもよい。また、前述したように、い
ずれかのデータを削除することもできる。あるいは、各
ファイルの機能を無視してデータ量の削減のみに注目す
れば１つにマージすることもできる。

【００４８】ここで、更新フラグ６０ｂに「更新済Ｎ
Ｇ」がセットされていなければ、この時点においてマス
タファイルの４、１４のデータは一致していると判断
し、更新フラグ６０ｂに「更新済ＯＫ」をセットし（ス
テップ２１３）、更にチェック結果フラグ８０ｂに［Ｏ
Ｋ」をセットする（ステップ２１４）。また、更新フラ
グ６０ｂに「更新済ＮＧ」がセットされていれば、この
時点においてマスタファイル４、１４のデータを比較し
た結果、一致していないと判断し、チェック結果フラグ
８０ｂに［ＮＧ」をセットする（ステップ２１５）。そ
して、マスタファイル４、１４が一致していない旨をプ
リンタ等に表示させ何らかの一致対応処理をするよう警
告を発する（ステップ２１６）。この警告には、更新ロ
グファイル１６及び管理ファイル１８の内容を表示して
もよい。以上の処理が終了すると、ホスト計算機２から
受信した更新ログファイルに含まれている次の更新レコ
ード６０を取り出す。個の処理を繰り返し行い、更新レ
コード６０がなくなれば処理は終了する。

【００４９】以上のように、本実施例においては、ホス
ト計算機２から転送された更新ログファイル６内の更新
レコード６０に従いチェックサムデータを用いることで
分散計算機１２のマスタファイル１４を確実に更新でき
データコンペアによるデータ整合性を保証することがで
きる。更に、データコンペアを更新レコード６０毎に行
うので高精度なデータ整合性を保証することができる。
また、データコンペアの際に使用されるデータ、更新レ
コード６０並びに管理レコード８０のデータは非常に簡
単な計算であり、また前回の計算結果をも利用できるの
でデータコンペアに要する時間も短時間で行うことがで
きる。

【００５０】もちろん、単に全レコード更新処理終了後
に管理ファイル８と更新処理によって更新された管理フ
ァイル１８との比較、若しくはホスト計算機２から転送
された更新ログファイル６と更新処理によって作成され
た更新ログファイル１６との比較、あるいはその両方の
比較を行ってもよい。

【００５１】しかしながら、全レコード更新処理終了後
にのみデータコンペアを行う場合は、一定のタイミング
内に、例えばあるレコードのデータＡがデータＢに更新
されその後データＣに更新された場合は、データＡがデ
ータＣに更新された場合、あるいはデータＡがデータＤ
に更新されその後データＣに更新された場合、との差が
なくなり同じ更新処理がされたことになる。これは、時
々刻々と変動する単価、あるいは住民票の住所の変遷等
中途の更新処理を無視できない場合に不都合が生じる。

【００５２】そこで、本実施例においては、１レコード
更新毎にデータコンペアを行い、一連の更新処理途中に
おける不都合をも発見可能にした。このように、本実施
例におけるデータコンペア方式によれば、データコンペ
アをチェックサムデータを用いレコード更新毎に行うこ
とでより少ないデータで高精度なデータコンペアを行う
ことができる。従って、これに伴いホスト計算機２から
分散計算機１２に転送すべき転送量も削減することがで
きる。

【００５３】

【発明の効果】以上のように、本発明に係るデータコン
ペア方式によれば、実際のデータの比較は行わずチェッ
クサムデータ等を用いてデータコンペアするので、確実
にしかも短時間でデータコンペアを行うことが可能とな
る。従って、転送すべきデータ量をも少なくすることが
可能となる。

【００５４】また、更新前及び更新後のチェックサムデ
ータを用い１レコード更新毎にデータコンペアを行うこ
とができるようにしたので、一連のレコード更新処理途
中における不都合をも発見することが可能である。

【００５５】また、データベースの容量に関係なく１つ
のみのチェックサム、すなわちファイル全体チェックサ
ムを生成し、これを用いてデータコンペアを行うように
したので、データの転送量を削減できるとともにコンペ
アすべきデータをも削減することができるので短時間で
データコンペアを行うことが可能となる。

【図面の簡単な説明】

【図１】本発明に係るデータコンペア方式が実施される
分散システムの構成図である。

【図２】本実施例におけるマスタファイルに格納されて
いるレコードの内容を示した図である。

【図３】本実施例において、カナ文字データを数字デー
タに変換するために用いるテーブルの例を示した図であ
る。

【図４】本実施例における更新ログファイルの内容と更
新レコードの項目を示した図である。

【図５】本実施例において、ホスト計算機における更新
ログファイルへの更新レコードの生成処理及び管理ファ
イルの更新レコードの更新処理を示したフローチャート
であるとともに主なデータの流れを示した図である。

【図６】本実施例における管理ファイルの内容と管理レ
コードの項目を示した図である。

【図７】本実施例において、分散計算機における更新ロ
グファイルへの更新レコードの生成処理及び管理ファイ
ルの更新レコードの更新処理を示したフローチャートで
あるとともに主なデータの流れを示した図である。

【符号の説明】

２ ホスト計算機 ４、１４ マスタファイル ６、１６ 更新ログファイル ８、１８ マスタ管理ファイル １２ 分散計算機 ６０ 更新レコード ６０ｂ 更新フラグ ６０ｅ 更新前ファイル全体チェックサム ６０ｆ 更新後ファイル全体チェックサム ８０ 管理レコード ８０ａ ファイル全体チェックサム ８０ｂ チェック結果フラグ ８０ｃ トータルレコード件数

Claims (5)

【特許請求の範囲】
1. 【請求項１】 主局と少なくとも１つ以上の従局とを有
   し各局それぞれにデータベースを有する分散システムに
   おいて前記主局のデータベースのデータと前記各従局の
   データベースのデータとを比較するデータコンペア方式
   において、 前記各従局は、チェックサムデータとレコード変更件数
   に関する管理情報とによりデータを比較することを特徴
   とする分散システムにおけるデータコンペア方式。
2. 【請求項２】 請求項１記載の分散システムにおけるデ
   ータコンペア方式において、 前記チェックサムデータは、レコード更新毎に作成され
   るレコード更新前のチェックサムデータと当該レコード
   更新後のチェックサムデータとを含むことを特徴とする
   分散システムにおけるデータコンペア方式。
3. 【請求項３】 請求項２記載の分散システムにおけるデ
   ータコンペア方式において、 前記各従局は、自局で算出するレコード更新前及びレコ
   ード更新後のチェックサムデータと、前記主局のレコー
   ド更新前及びレコード更新後のチェックサムデータと、
   をレコード更新毎にそれぞれ比較することを特徴とする
   分散システムにおけるデータコンペア方式。
4. 【請求項４】 主局と少なくとも１つ以上の従局とを有
   し各局それぞれにデータベースを有する分散システムに
   おいて前記主局のデータベースのデータと前記各従局の
   データベースのデータとを比較するデータコンペア方式
   において、 前記主局は、レコード更新に関する更新情報と、レコー
   ドの変更件数に関する管理情報と、チェックサムデータ
   と、を前記各従局に転送することを特徴とする分散シス
   テムにおけるデータコンペア方式。
5. 【請求項５】 請求項１乃至４記載の分散システムにお
   けるデータコンペア方式において、 前記チェックサムデータは、データベースに記録されて
   いるレコード毎に求められたチェックサムから算出する
   ファイル全体チェックサムを含むことを特徴とする分散
   システムにおけるデータコンペア方式。