JPH09237209A - データ格納方法 - Google Patents

Abstract

(57)【要約】 【課題】処理装置、プログラム間で送受信されるメッセ
ージデータと、１または複数の処理装置に格納されたデ
ータを、各プログラム等から統合的に扱えるようにす
る。また、データ格納装置の自律的な判断と処理によっ
て、各プログラムが意識しなくとも一連の関連するデー
タの格納や配付を可能とし、異常データの波及を防止す
ることを可能とする。 【解決手段】メッセージデータやDB中のデータを操作し
たり参照したりするプログラムに対して、メッセージデ
ータとDB中の格納データを同一のインタフェースや同一
のデータ名称、構造で操作したり、利用したりさせる。
さらに、DB側に自律的なデータ操作やその判断機能をも
たせることで、受信したメッセージデータを元にして関
連する自内のデータ格納テーブルを書き換えたり、新し
いメッセージデータを作成して送信したり、これらの処
理を実行するか判断したりさせる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、分散処理システム
において各処理装置において発生したデータを該処理装
置又は他の処理装置に保存しておき、必要に応じて保存
されたデータを任意の装置が取得し、利用するようにさ
れた分散処理システムにおけるデータの格納方法及びデ
ータアクセス方法に関する。

【０００２】

【従来の技術】従来、分散処理システムにおいてデータ
を格納する装置またはプログラムとしてはデータベース
ソフトウェアがあり、例えば、ネットワークコンピュー
ティング1994年6月号，PP．9-23「ミドルウェアを使い
こなす」に記載されるようなものが知られている。ここ
に挙げられているようなデータベースシステムでは、格
納するデータとその構造をデータベース（DB）ごとに定
義し、データの格納及びデータの検索、取得等もDBを指
定して行われる。

【０００３】

【発明が解決しようとする課題】従来のシステムでは、
分散処理を行う処理装置やプログラム間でやりとりされ
るメッセージデータとDBは全く別に設計されるため、DB
側のプログラムが、受信したメッセージデータを解析し
てDBの構造にあわせて格納する必要があった。さらに構
造の定義も、メッセージ側とDB側で２重に行う必要があ
った。

【０００４】DBのデータを利用するプログラムは、必要
とするデータを格納しているDB中のデータと、伝送媒体
に流されるメッセージデータ両方の構造やデータ内容を
意識する必要がある。また、あるプログラムからDB中の
データを操作する場合は、相手先処理装置、DB、及びテ
ーブルを指定する必要があった。このため、あるデータ
に関連した複数のデータ格納テーブルがある場合や、デ
ータ格納テーブルを多重化した場合は、DBのデータを操
作するプログラムが全てのテーブルを指定してデータの
格納や取得を行う必要があり、データ格納テーブルを拡
張したり多重度を増したりするのにプログラムを変更す
る必要があったため、システムの柔軟性が低かった。

【０００５】また、従来のDBはデータを格納しておくた
めのものであり、自律的なデータ取得や送信が行なえ
ず、データの格納や送信は、全て、ある処理装置やプロ
グラムから要求を発行して行なう必要があった。このた
め、DB中のデータを操作して、結果を他の処理装置に伝
える必要がある場合は、DBのデータを操作したプログラ
ムが他の処理装置に対して変更を伝える必要があり、プ
ログラムの処理が煩雑になったり、システムの改造に伴
いプログラム改造が必要になったりして、システムの柔
軟性が低かった。さらにDBが自律的な判断を行わず、処
理装置やプログラムからのデータ操作要求をそのまま実
行するのみであるため、あるプログラムが誤ったデータ
操作をしたために、その影響が他のプログラムに及んで
しまうことも多く発生していた。

【０００６】一方、各DBが自律的にデータを取得する方
法として、例えば特開昭62-169242号公報に記載されて
いる方法がある。これによると各DBは自律的にデータを
取得したりすることは可能であるが、DBの構造について
は規定がなく、このためデータを発生するプログラムや
データを取得するプログラムからは、DBのデータ構造や
メッセージのデータ構造について意識する必要があっ
た。

【０００７】このように、分散処理システムにおいてデ
ータを格納するために、従来は、データ格納テーブルの
構造をDB専用に定義する必要があった。

【０００８】したがって、本発明の目的は、分散処理装
置間やプログラム間でやりとりするメッセージデータの
構造や名称を、DB中のデータ格納テーブルの名称や構造
と透過にすることで、メッセージデータ及びDB中のデー
タを利用する処理装置やプログラムに対して、システム
内で統一されたデータアクセス方法とデータ名称、デー
タ構造を提供することにある。

【０００９】また、本発明の他の目的は、DBに自律的な
処理を行わせることで、送信元が意識してデータを書き
込まなくとも、DBが自律的にデータを格納することを可
能にすることにある。

【００１０】さらに、本発明は、データの格納や送信と
いった処理を実行するかしないかを、DBが自律的に判断
し、異常データの波及防止等を可能とすることを目的と
するものである。

【００１１】

【課題を解決するための手段】本発明のデータ格納方法
及びアクセス方法は、処理装置間やプログラム間で送受
信されるメッセージデータの名称や構造の定義情報と、
DB内のデータ格納テーブルの名称や構造の定義情報を透
過に利用可能なものとし、片方の定義が他方の定義とし
て利用可能なものとすることを特徴とする。またこの情
報の定義や、処理装置間及びプログラム間のメッセージ
送受信の関係とデータ格納テーブルを介したデータの流
れを、システム全体にわたって共通の定義プログラムを
用いて定義したり、共通の参照プログラムを用いて参照
したりする。

【００１２】さらに、メッセージデータやDB中のデータ
を操作したり参照したりするプログラムに対して、メッ
セージデータとDB中の格納データを同一のインタフェー
スや同一のデータ名称、構造で操作したり、利用したり
させる。

【００１３】さらに、本発明では、DB側に自律的なデー
タ操作やその判断機能をもたせることで、受信したメッ
セージデータを元にして関連する自内のデータ格納テー
ブルを書き換え、新しいメッセージデータを作成して送
信し、また、これらの処理を実行するか判断したりさせ
ることを特徴とする。

【００１４】

【発明の実施の形態】以下に、本発明の実施の形態を詳
細に説明する。

【００１５】図１は、本発明を適用した分散処理システ
ムの一例を示す構成図である。分散処理システムは、共
通伝送媒体１０１を介して互いにデータの授受を行う処
理装置１１１〜１１３と、ディスプレイやキーボードを
有する端末１２１〜１２３から構成されている。処理装
置１１１〜１１３には、端末１２１〜１２３が接続され
ている。ここで、端末１１１〜１１３は、ディスプレイ
やキーボード等のマンマシンインタフェースを持ち、こ
のインタフェースを介して、処理装置上で実行されるプ
ログラムの制御を行なったり、プログラムの出力を参照
したりする機能を有している。また、処理装置１１１〜
１１３は、メモリやディスク等のデータ記憶媒体を保持
している。

【００１６】処理装置１１１〜１１３は、伝送路上を流
れるデータが自内のプログラムに必要なものであるかど
うかを判定し、必要と判定したときこのデータを保存し
ておき、該プログラムの必要とするデータが揃った時点
で、自装置内のプログラムにデータを渡す。本実施の形
態におけるデータ格納方法を有するプログラム、及びデ
ータアクセス方法を用いるプログラムも同様に必要とな
るデータが揃った時点でデータを受け取る。

【００１７】図２(a)は、伝送路１０１上で送受信され
るメッセージのフォーマットを示している。各メッセー
ジは、データ２０４の他、データ２０４に付加された、
メッセージデータの内容を示す内容コード（CC）２０
１、送信元アドレス（SA）２０２、及び制御コード（Ct
lC）２０３を含んでいる。各処理装置１１１〜１１３
は、これらの情報をもとにして各メッセージが自内のプ
ログラムに必要なデータかを判断する。データ部２０４
は、後述する定義プログラムによって構造が定義されて
おり、各プログラムはCC２０１によってその構造を判断
しデータを操作する。図２(b)は、データ部２０４の構
造の一例である。本例では、データ部は製品ＩＤ２２
１、管理番号２２２、測定値２２３等から構成される。
２２４にもその他の構成データ項目が並ぶ。各処理装置
やプログラムは、このデータ部に対して構造を定義し、
この構造に従ってメッセージデータに値を設定してデー
タをやり取りする。

【００１８】図３は、処理装置内プログラム構成の一例
である。通信管理プログラム３１１が伝送媒体を介した
メッセージデータの送受信を管理し、必要なデータが揃
ったら、データ操作サブプログラムである蓄積処理サブ
プログラム３１３や編集処理サブプログラム３１４を起
動する。サブプログラム３１３〜３１５は、データ管理
プログラム３１２を経由してデータの格納を行ったり、
他のサブプログラムとデータの受け渡しを行ったりす
る。データ管理プログラム３１２は、内部記憶装置内の
データ格納テーブル３２１や、外部記憶装置内のデータ
格納テーブル３２２の名称や構造、アドレスやサイズ等
を管理し、データのアクセスを行う。内部記憶装置はメ
モリ等で、外部記憶装置はディスク等である。

【００１９】図４は、データが格納される格納装置内テ
ーブル（以下テーブル）の構造例である。図４(a)は、
メッセージ中のデータが格納されるデータ格納テーブル
である。図２において説明したように、このテーブルの
構造はCC, SA, CtlC等によって判断されるメッセージの
構造に一致しており、各メッセージごとに作成されるも
のである。本例は、CCが“500”であるデータ格納テー
ブルの例であり、この構造はCCが“500”のメッセージ
にも適用されている。図４(b)は、図４(a)において説明
したテーブルに格納されるメッセージのCC, SA, CtlC等
のメッセージ情報および受信時刻等の情報を格納するテ
ーブルである。ここに格納されるデータは、図４(a)に
格納されるデータと紐付けされている。図４(a)、(b)の
テーブルとも、後に説明する格納方式によって、固定的
に確保することも動的に確保することもできる。またこ
のテーブルは、処理装置内の主記憶装置、補助記憶装置
等任意の記憶装置に確保することができる。

【００２０】次に、メッセージ格納処理の一例について
説明する。

【００２１】図５は、処理装置内の格納データ及び格納
方法登録テーブルの一例である。入力データが外部から
のメッセージか後述する編集処理後のものかを示す入力
フィールド５１１と、入力データ又は編集処理後のデー
タのCCを格納するフィールド５１２、元となる受信メッ
セージの情報を格納するフィールド５１３、５１４、格
納型を格納するフィールド５１５、テーブルＩＤ５１
６、格納タイプに付属した情報を格納する付属項目５１
７から構成されている。各入力データに関するこれらの
項目が、レコード５２１〜５２４に格納されている。レ
コード５２１の例では、CCが“500”である外部からの
メッセージを、送信元処理装置（SA）やメッセージの制
御コード（CtlC）に関わらず蓄積型で格納するよう定義
されている。レコード５２２の例は上書き型であり、付
属項目５１７にあるように、製品ＩＤというデータ項目
の値をキーとして格納するよう指定されている。本例で
は付属項目は１つのデータ項目であるが、これは複数個
指定してもよいし、データを格納するか否かといった条
件を指定しておくことも可能である。

【００２２】図６は、蓄積処理の流れを示すフローチャ
ートである。蓄積処理では、伝送媒体からのメッセージ
または他処理からのデータを受信し（ステップ６０
１）、以降で説明する処理継続判定を行う（ステップ６
０２）。その後、受信した外部または編集処理からのデ
ータに対応する格納テーブルを検索し（ステップ６０
３）、該データをその構造に基づいてデータ項目に分解
して（ステップ６０４）、受信データのCCまたはIDと登
録テーブルから格納型を判断する（ステップ６０５）。
上書き型の場合は、図７にて説明する上書き処理を行
い、蓄積型の場合はテーブルに新規にレコードを追加し
（ステップ６０６）、該レコード中の、登録テーブルに
指定されたフィールドにデータを格納する（ステップ６
０７）。

【００２３】図７は、上書き処理の流れを示すフローチ
ャートである。受信したデータのCCと登録テーブルより
上書き先レコードのキーとなるフィールドを取得し（ス
テップ７０１）、テーブルを検索することにより上書き
先レコードを検索する（ステップ７０２）。次に、上書
き先レコードが存在したかどうか判断し（ステップ７０
３）、上書き先レコードが存在した場合は登録テーブル
より上書き先のフィールドを取得し、該フィールドにデ
ータを上書きする（ステップ７０４）。上書き先レコー
ドが存在しなかった場合は、登録テーブルよりレコード
が存在しなかった場合の処理を判断する（ステップ７０
５）。廃棄処理が指定されていた場合は処理終了とな
り、追加処理が指定されていた場合は新規にレコードを
追加し（ステップ７０６）、登録テーブルより上書き先
のフィールドを取得し、該フィールドにデータを上書き
する（ステップ７０４）。

【００２４】図５〜図７において説明したデータ格納方
法により、各処理装置内のプログラムが相手先や格納方
法を指定せず送信したメッセージデータを格納すること
が可能である。

【００２５】これまで説明した格納処理は、外部からの
メッセージを直接格納することが可能であり、また、な
んらかの編集処理の結果を格納することもできる。以下
に編集処理の例を示す。

【００２６】図８は、編集方法を登録するテーブルの一
例である。図８(a)は、１つの編集処理につき複数の入
力データ各々の条件と構造を示すテーブルである。各入
力データごとに、入力元が外部または他処理からのメッ
セージか、格納済みのテーブルかを示す入力フィールド
８１１、入力データのCC８１２、入力データがテーブル
の場合にレコードの検索条件を示すフィールド８１３、
データを構成する要素となるデータ項目の並び８１４〜
８１７、が設定される。第１列８０１の例では、入力デ
ータがCC“600”のテーブルで、データ項目構成がID、
規格、許容誤差、価格からなり、IDが“26”のレコード
を検索するという設定である。本例では検索条件は定数
を用いた式であるが、定数や入力データ中の値を用いて
条件設定したり、数式以外でも文字列の一致やある文字
列を含むかといった条件も加えることが可能である。ま
た、データが格納された時刻を用いて一定範囲を検索し
たりすることも可能である。

【００２７】図８(b)は、この編集処理による出力デー
タを表すテーブルである。出力データのCC８２１、出力
データを構成するデータ項目へのポインタ８２２〜８２
５から構成される。８２２〜８２５は、該フィールドに
設定される入力元データ項目を示す入力元テーブル中の
項目のポインタが設定される。

【００２８】図９は、編集処理の流れを示すフローチャ
ートである。編集処理では、伝送媒体からのメッセージ
または他処理からのデータを受信し（ステップ９０
１）、該編集モジュールが必要としているデータが全て
揃ったか判断する（ステップ９０２）。ここで、処理装
置が自内テーブルに格納しているデータ、すなわち入力
元がテーブルとなっている入力データについては、既に
揃っているものとみなす。データが揃っていない場合
は、受信したデータをバッファに格納し（ステップ９０
３）、次のデータ受信を待つ。データが揃っていた場合
は、入力元テーブルより必要なデータを検索して揃え
（ステップ９０４）、バッファからも入力データを取得
して（ステップ９０５）、編集処理の登録テーブルに従
って出力データのデータ項目値を設定する（ステップ９
０６）。設定されたデータは、他の編集処理又は格納処
理、後述する送信処理へ送信される（ステップ９０
７）。

【００２９】ここでは、データ項目の選択と配置につい
ての編集処理を示したが、編集処理は本実施例のみに留
まるものでなく、例えばユーザ作成の任意のデータ処理
を行なうプログラムとすることも可能である。

【００３０】次に、データを格納した処理装置からデー
タを送信する場合の例について説明する。

【００３１】図１０は、送信処理方法の登録テーブルの
一例である。入力データが外部からのメッセージか編集
処理後のものかを示す入力フィールド１０１１と、入力
データ又は編集処理後のデータのCCを格納するフィール
ド１０１２、受信メッセージ、または前処理の編集処理
の元となった受信メッセージのCCを格納するフィールド
１０１３、このメッセージの情報を格納するフィールド
１０１４、送信先を指定するフィールド１０１５、受信
したデータに関する条件を格納するフィールド１０１６
で構成される。これらの項目が各入力データに対してレ
コード１０２１〜１０２５に格納されている。例えば、
レコード１０２１は、他編集モジュールからのCC“80
0”の入力データを、伝送媒体からの受信メッセージのS
AやCtlC及びデータの内容に関わらず、相手先処理装置
を特定せずに送信するよう指定されていることを示して
いる。

【００３２】図１１は、送信処理の流れを示すフローチ
ャートである。送信処理では、伝送媒体からのメッセー
ジまたは他処理からのデータを受信し（ステップ１１０
１）、以降で説明する処理継続判定を行う（ステップ１
１０２）。その後、データを登録テーブルに指定された
処理装置を指定して送信する（ステップ１１０３）。送
信されるメッセージは、入力データと同じ構造、同じ識
別子を持って送信される。図１０の登録テーブル中レコ
ード１０２１に対応する処理の例では、前処理となった
編集処理より取得したデータに、CC“800”の識別子を
付けられて送信される。

【００３３】このようなデータ送信方法により、受信側
のプログラムでは、他プログラムから送られるメッセー
ジと、問い合わせメッセージ等の手段により他処理装置
から取得した格納済みメッセージデータを同一のインタ
フェースで受信することが可能となる。

【００３４】次に、これまで説明した編集処理、格納処
理、送信処理を組み合わせて行われる処理装置内の処理
の一例を、以下に説明する。

【００３５】図１２は、複数処理連携のための定義テー
ブルである。図１２(a)は受信メッセージのCCに対して
どの処理を起動するか示すCCと処理の対応を示すＣＣモ
ジュールテーブルである。フィールド１２１１に受信メ
ッセージのCC、該メッセージにより起動される処理のイ
ンデックスがフィールド１２１２に格納されている。こ
こで処理のインデックスは、図１２(b)に示す処理テー
ブル中のインデックスを意味する。各入力メッセージの
CCに対応する起動処理が、レコード１２２１〜１２２３
に格納されている。例えば、レコード１２２１は、CC
“1000”に対し、インデックス“１”の処理を起動する
よう登録されている。

【００３６】図１２(b)は、各処理の情報を格納する処
理テーブルである。インデックス１２５１は、各列の識
別子である。各処理の情報は、処理名１２５２、処理種
別１２５３、処理番号１２５４、各処理のパラメータ定
義テーブルへのポインタ１２５５、入力データの構造を
示すCCを格納するフィールド１２５６、出力データの構
造を示すCCを格納するフィールド１２５７、該処理に続
いて起動される処理のインデックス１２５８、１２５９
で構成される。例えば、列１２６１は、処理名“a”の
編集処理で、インデックス“２”、“３”で示される処
理にCC“700”の構造をもつデータを渡すよう登録され
ている。インデックス“２”、“３”で示される処理
は、インデックス“１”の処理後並行して実行される。
インデックス“２”、“３”の処理を登録してある列１
２６２、１２６３では、入力CCはともに“700”である
必要がある。

【００３７】図１３に、クライアント処理装置からのデ
ータ問い合わせに対する応答処理の一例を示す。この応
答処理は、受信した問い合わせデータに基づく編集処理
１３０１と、生成された応答データを要求元に送信する
処理１３０２からなる。編集処理１３０１では、まず、
受信したメッセージが問い合わせメッセージかどうか判
断する（ステップ１３１１）。問い合わせメッセージで
あった場合は、要求されているデータのCCを取得し（ス
テップ１３１２）、該CCのデータの検索条件を取得する
（ステップ１３１３）。検索条件は、受信した問い合わ
せメッセージデータ中より取得したり、予め当該編集処
理の用いるテーブルに登録しておくことができる。その
後、該CCのデータ格納テーブルよりレコードデータを検
索及び取得し（ステップ１３１４）、送信処理へと渡
す。送信処理においては、編集処理より受け取ったデー
タを、ステップ１３１２で取得したCCを付加して要求元
処理装置、すなわち問い合わせメッセージを送信した処
理装置へ送信する。CCが“500”である場合の、送信処
理の登録テーブルの例が、図１０に示すテーブル中のレ
コード１０２２である。本実施例では、フィールド１０
１１〜１０１４によって、入力データは伝送媒体から受
信したCC“500”の問い合わせメッセージであると判断
され、データは問い合わせ元にのみ送信される。

【００３８】図１４は、受信したデータを用いて新しい
レコードデータを作成し、新しいデータを用いて自処理
装置内データ格納テーブルを書き換え、この最新データ
を他処理装置へ送信する処理の例である。図１２(b)に
示す処理テーブル中の、レコード１２２１〜１２２３に
て示した連携処理の例である。この処理は、例えば、編
集処理１４０１、格納処理１４０２、送信処理１４０３
より構成される。編集処理１４０１では、受信したメッ
セージが問い合わせメッセージかどうか判断し（ステッ
プ１４１１）、問い合わせメッセージでなかった場合は
指定された方法でデータを編集して（ステップ１４１
２）、後の格納処理１４０２及び送信処理１４０２へと
生成したデータを渡す。格納処理１４０２では、取得し
たデータに対応するテーブルに該データを上書きし、送
信処理１４０３では、取得したデータに対応するCCを付
加してメッセージを送信する。

【００３９】以上示した２例のように、複数の処理モジ
ュールを連携させてデータの編集、格納、送信を行なう
ことが可能である。また、１回のメッセージ受信で、複
数のデータ格納テーブル操作やメッセージ送信処理を実
行することも可能である。

【００４０】図１５は、データの格納、送信処理を継続
するか否かを判断する処理の一例を示すフローチャート
である。この処理は、格納処理においては図６のステッ
プ６０２、送信処理においては図１１のステップ１１０
２に対応する処理である。まず、取得したメッセージデ
ータより、メッセージ送信元のアドレスや特定のデータ
項目値等の、処理継続判断に必要な情報を抽出する（ス
テップ１５１１）。これを登録テーブル中の設定項目と
比較し（ステップ１５１２）、条件を満たさない場合は
“NG”を返す。条件を満たす場合、自処理装置内の状態
を取得する（ステップ１５１３）。これは、CPUの負荷
や記憶装置の使用量、データを格納するテーブルの占有
状況、過去の何らかの処理により影響されたデータの信
頼性等である。これらが条件を満たすか判断し（ステッ
プ１５１４）、満たさない場合は“NG”、満たす場合は
“Good”を返す。“Good”が返された場合は処理を継続
し、“NG”が返された場合は処理を中止する。

【００４１】図１６は、データ格納、編集、送信処理
と、メッセージ構造を定義するプログラムのインタフェ
ースの一例である。受信するメッセージデータがCC番号
“640”の計画修正データ１６１１であり、該データを
用いて編集処理１６２１、上書き処理１６２２、送信処
理１６２３が順次実行されることで、データの格納と送
信を行う処理の定義画面例を示している。各々の処理に
渡されるデータは、矢印１６３１〜１６３３で示されて
おり、これらにもその内容や構造に従ってCCが付けられ
ている。本例では、矢印１６３１はCCが“640”であ
り、矢印１６３２、１６３３はCCが“700”である。画
面右側のテーブルの図は、各処理が操作するデータ格納
テーブルを示している。この例では、編集処理１６２１
はCCが“730”のテーブル１６４１を、上書き処理１６
２２はCCが“700”のテーブル１６４２を操作すること
を示している。このように、各処理を矢印でつなぐこと
で処理の流れを定義し、矢印によって処理間で渡される
データを定義する。

【００４２】図１７は、図１６の画面より開かれる詳細
定義画面である。図１７(a)は、データ構造定義画面で
あり、図１６の入力データ表示１６１１、またはデータ
表示矢印１６３１をマウスでクリックすることで表示さ
れる。この例ではCCが“640”のデータ構造を定義して
おり（フィールド１７１１）、構成するデータ項目が、
順に、メーカ名１７１２で２０バイト文字列型（１７２
１）、要求納期１７１３で１０バイト文字列型（１７２
２）、製品コード１７１４で長整数型（１７２３）、本
数１７１５で符号なし長整数型（１７２４）であること
を示している。この定義は、入力メッセージのみに留ま
るものでなく、CCが“640”のデータ格納テーブルの定
義として透過的に利用される。また図１６中のテーブル
表示１６４１、１６４２をマウスでクリックしても、同
様にCCが“730”の構造定義画面、CCが“700”の構造定
義画面を表示し、各々の構造を定義可能である。ここで
定義されたデータ構造は、それぞれCCが“730”のメッ
セージ、CCが“700”のメッセージに透過的に利用され
る。

【００４３】図１７(b)は、データ編集処理の処理内容
の定義画面の一例である。この画面は、例えば、図１６
中の編集処理１６２１をマウスでクリックして表示され
る。入力データが、CC“640”１７３１とCC“730”１７
３２であり、出力データがCC“700”１７３３である。
線１７４１、１７４２は、CC“640”とCC“730”のメー
カ名、およびCC“640”とCC“730”の製品コードが等し
いレコードを検索して、入力データとして用いることを
示している。矢印１７５１〜１７５５は、入力データ項
目と出力データ項目の対応を示しており、例えば、矢印
１７５１によってCC“640”のメーカ名が出力データCC
“700”のメーカ名１７６１に設定されることを示して
いる。フィールド１７６１〜１７６５は、出力データCC
“700”を構成するデータ項目である。

【００４４】図１８は、各処理装置間でメッセージデー
タが入出力される関係を表示するインタフェースの一例
である。図１８(a)は、装置間のメッセージデータ入出
力を表す装置間リンケージ図である。箱１８１１〜１８
１３が各装置を表し、矢印１８３１〜１８３４がメッセ
ージデータを表している。記憶装置１８２１を含んでい
る装置１８１３は、データ格納処理を行っている装置で
ある。矢印１８３１は、装置“１”から送られ、装置
“３”に受信されるメッセージデータを、矢印１８３３
は装置“３”から送られ、装置“２”に受信されるメッ
セージデータを、矢印１８３４は装置“２”から送られ
るメッセージデータをそれぞれ表している。矢印１８３
２は、装置“２”が装置“３”から問い合わせによりデ
ータを取得していることを表している。

【００４５】図１８(b)は、プログラム間のメッセージ
データ入出力、及びプログラムとデータ格納テーブルの
データ入出力関係を表している。箱１８５１〜１８５４
がプログラムを表し、矢印１８６１〜１８６３がプログ
ラム間で送受信されるメッセージデータを表している。
１８７１、１８７２は、データ格納テーブルを表してい
る。メッセージ１８６１を受信したプログラムc１８５
３は、データ格納テーブル１８７１、１８７２にデータ
を格納する。受信データの編集とテーブルへの格納処理
は、これまで説明したようにして行われる。プログラム
d１８５４は、メッセージ１８６２を受信し、データ格
納テーブル１８７１から取得したデータを用いてメッセ
ージデータを作成し、該データを矢印１８６３で表され
るように送信している。このような表示により、各プロ
グラムとテーブルに格納されたデータの関係がわかりや
すくなる。またプログラムdを表す箱１８５４をマウス
でクリックして、図１６や図１７に示すの画面を表示す
ることで、メッセージデータがどのように生成されたか
を示し、データ生成関係をわかりやすく表示することも
可能である。

【００４６】

【発明の効果】処理装置間やプログラム間で送受信され
るメッセージデータの名称や構造の定義と、DB内のデー
タ格納テーブルの名称や構造の定義を透過なものとする
ことで、メッセージ、テーブルといったシステム全体で
共通化するデータ設計が、統合的に可能となる。プログ
ラム間のデータの流れに加え、データ格納テーブルを含
めたデータの流れや、データ生成の関係がシステム全体
で表示可能で、システムの構成や挙動を把握しやすくな
る。

【００４７】また、各プログラムは、メッセージデータ
とDB中の格納データを同一のインタフェースや同一のデ
ータ名称、構造で操作したり、利用したりさせることが
できるため、システム構造が簡単になり、プログラムの
開発量が減少する。データのアクセスや操作も容易にな
る。

【００４８】さらに、DB側が自律的なデータ操作やその
判断機能を持つことで、受信したメッセージデータを元
にして新レコードデータを作成したり、データ格納や送
信を行ったりといった複数の処理を行える。このため各
プログラムが全てのデータ操作を行ったりしなくてもよ
くなり、伝送路の負荷を下げられ、プログラムの開発量
を下げられる。また、システムの改造やDBの拡縮、多重
度の変更も、プログラムを書き換えずに行える。DB側の
自律的な処理継続判断機能により、あるプログラムの送
信した異常データの影響が、他のプログラムに波及しな
いようにできる。

【図面の簡単な説明】

【図１】本発明の一実施例における分散処理システムの
構成を示すブロック図である。

【図２】共通伝送媒体を介して処理装置間で送受信され
るメッセージデータの構成図と構成例の説明図である。

【図３】データ格納方法及びアクセス方法を実現する処
理装置内のプログラム構成例説明図である。

【図４】データ格納テーブルの構造説明図である。

【図５】格納データを登録するテーブル例の説明図であ
る。

【図６】データ蓄積処理を示すフローチャートである。

【図７】データ上書き処理を示すフローチャートであ
る。

【図８】データ編集処理で用いるテーブルの構成例の説
明図である。

【図９】データ編集処理を示すフローチャートである。

【図１０】送信処理で用いるテーブルの構成例の説明図
である。

【図１１】データ送信処理を示すフローチャートであ
る。

【図１２】データ格納処理やデータ編集処理、データ送
信処理の組み合わせを登録するテーブルの構成説明図で
ある。

【図１３】問い合わせ応答処理を実施する編集処理と送
信処理の組み合わせ例を示すフローチャートである。

【図１４】データ格納及び送信処理を実施する編集処理
及び上書き処理、送信処理の組み合わせ例を示すフロー
チャートである。

【図１５】自律的な処理継続判定処理を示すフローチャ
ートである。

【図１６】データ格納方法及びアクセス方法を実現する
処理構成の定義画面例の説明図である。

【図１７】データ構造及びデータ編集方法を定義する画
面例の説明図である。

【図１８】装置又はプログラムと、データ格納装置又は
格納テーブル間のデータフローを表示する保守プログラ
ム画面例の説明図である。

【符号の説明】

111〜113：処理装置、121〜123：端末、101：共通伝送
媒体、311：通信管理プログラム、312：データ管理プロ
グラム、321：内部記憶装置、322：外部記憶装置、401
〜403：データ格納テーブル、431〜433：メッセージ関
連情報格納テーブル。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 松野 強 茨城県日立市大みか町五丁目２番１号 日 立プロセスコンピュータエンジニアリング 株式会社内

Claims (12)

【特許請求の範囲】
1. 【請求項１】共通伝送媒体に接続された複数の処理装置
   により一連の処理を分散して行い、かつ、該一連の処理
   のそれぞれを実行するためのプログラムを上記複数の処
   理装置に分散して記憶させ、該プログラム同士が共通伝
   送媒体を介してメッセージデータの交換により処理を行
   なう分散処理システムにおいて、メッセージデータと同
   一の構造をもつデータ格納テーブルを、１つまたは複数
   の処理装置が有し、受信したメッセージデータをその構
   造に基づいて分類し、対応するテーブルに蓄積すること
   を特徴とするデータ格納方法。
2. 【請求項２】前記処理装置が、受信したメッセージデー
   タに対応する格納テーブルに対して、メッセージデータ
   中のデータ項目の値に従って、自処理装置内の格納テー
   ブルを検索し、該当するレコードを上書きすることを特
   徴とする請求項１記載のデータ格納方法。
3. 【請求項３】前記テーブル内に該当する領域がない場
   合、該レコードデータ用の領域を新たに確保して、受信
   したメッセージデータを格納することを特徴とする請求
   項２記載のデータ格納方法。
4. 【請求項４】前記処理装置が、受信した１つまたは複数
   のメッセージデータと、自処理装置内に格納されている
   データを用いて新たなレコードデータを生成するステッ
   プと、生成されたデータの構造に対応する格納テーブル
   にデータを格納するステップを有することを特徴とする
   請求項１乃至３のいずれかに記載のデータ格納方法。
5. 【請求項５】前記生成ステップ、および前記格納ステッ
   プの処理が、受信した１つまたは複数のメッセージデー
   タを用い複数実行されることを特徴とする請求項４記載
   のデータ格納方法。
6. 【請求項６】前記処理装置が、受信したメッセージに含
   まれる情報または該メッセージに関して記憶されている
   情報を用いて、受信したメッセージデータ、または受信
   したメッセージデータと自処理装置内に格納されている
   データを用いて生成された新たなレコードデータを格納
   するか判断するステップを有することを特徴とする請求
   項１乃至５のいずれかに記載のデータ格納方法。
7. 【請求項７】前記処理装置が、自処理装置の状態によ
   り、受信したメッセージデータ、または受信したメッセ
   ージデータと自処理装置内に格納されているデータを用
   いて生成された新たなレコードデータを格納するか判断
   するステップを有することを特徴とする請求項１乃至５
   のいずれかに記載のデータ格納方法。
8. 【請求項８】前記処理装置が、受信した１つまたは複数
   のメッセージデータと、自処理装置内に格納されている
   データを用いて新たなレコードデータを生成するステッ
   プと、生成されたデータの構造に対応する識別子を付加
   して送信するステップを有することにより、問い合わせ
   元の装置または他の装置において、同一識別子を持つメ
   ッセージの受信と同一のインタフェースによって格納さ
   れているデータの受信を可能とすることを特徴とする請
   求項１記載のデータ格納方法。
9. 【請求項９】前記処理装置が、受信したメッセージに含
   まれる情報または該メッセージに関して記憶されている
   情報を用いて、受信したメッセージデータと自処理装置
   内に格納されているデータを用いて生成された新たなレ
   コードデータを送信するか判断するステップを有するこ
   とを特徴とする請求項８記載のデータ格納方法。
10. 【請求項１０】前記処理装置が、自処理装置の状態によ
    り、受信したメッセージデータ、または受信したメッセ
    ージデータと自処理装置内に格納されているデータを用
    いて生成された新たなレコードデータを送信するか判断
    するステップを有することを特徴とする請求項８記載の
    データ格納方法。
11. 【請求項１１】前記処理装置においてデータを格納する
    テーブルの構造または、共通伝送媒体上を流れるメッセ
    ージデータの構造の定義を入力するインタフェースと、
    いずれかの定義を用いて他方の定義に用いることを可能
    とする定義プログラムを有することを特徴とする、請求
    項１乃至７のいずれかに記載のデータ格納方法。
12. 【請求項１２】各処理装置または各処理装置に格納され
    ているプログラムが入出力するメッセージデータと、デ
    ータ格納するテーブルとのデータ入出力の関係を、全て
    の処理装置にわたって表示するインタフェースを有する
    プログラムを有することを特徴とする請求項１乃至７の
    いずれかに記載のデータ格納方法。