JPH10326284A - データベース・システムおよびプログラム記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】複数のユーザと複数のデータベースを仲介する
機能を持つデータベース・システムに関し，ユーザの増
加やデータベースの追加などに対するスケーラビリティ
が確保可能であり，動作負荷や運用管理コストが分散可
能であり，かつ情報の機密も保持可能な仲介機能を実現
することを目的とする。 【解決手段】ユーザ11〜13とデータベース51〜54との仲
介機構を，ユーザと仲介機構全体とのインターフェイス
を取り持つユーザ・エージェント21〜24と，各ユーザ・
エージェントとＤＢエージェントとの間を仲介する仲介
エージェント31〜38と，各データベース51〜54とエージ
ェント群との間のインターフェイスを取り持つＤＢエー
ジェント41〜44の３種類のエージェントによって分散的
に構成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，複数のユーザと複
数のデータベースが存在する場合に，ユーザとデータベ
ースとの間を仲介する機能を，エージェントと呼ぶプロ
セスを分散して複数動作させることによって実現したデ
ータベース・システムおよびそれを実現するプログラム
を格納したプログラム記憶媒体に関する。

【０００２】

【従来の技術】近年のコンピュータおよびコンピュータ
・ネットワークの発達により，多数のコンピュータが高
速なネットワークで結合された環境が整いつつある。こ
のようなネットワークを通して，コンピュータ上で動作
する多数のデータベースが利用可能になりつつある。

【０００３】しかし，これら多数のデータベースは，そ
れぞれ異なる内容を異なる利用手順で提供している。し
たがって，ユーザにとっては，まず自分の要求にもっと
も合致したデータベースを探索すること自体が，困難に
なってきている。また，データベース毎に異なる利用手
順を習得するのも，ユーザにとって大きな負担になって
きている。

【０００４】例えば，今日インターネット上には多数の
文献データベースが存在するが，これらを利用するため
には，ユーザは，まずどこにデータベースがあるのかを
知る必要がある。また，データベースには，網羅的に文
献を登録してあるデータベースもあるし，特定の分野に
偏って情報を保持しているものもある。したがって，多
数存在するデータベースから，自分の要求を満たした適
切なものを選択しなくてはならない。さらに，個々のデ
ータベースの利用手順は一般に異なる。したがって，利
用者は各データベースの利用の手引等を参照しつつ，個
別に検索を行うことになる。

【０００５】また最近では，ＣＡＬＳやＥＣと呼ばれる
動きが活発である。これらでは，電子的に物品の調達，
管理や広告，売買などを行う仕組みが盛んに開発され，
運用され始めている。しかし，これらの電子的な商取引
の場合にも，データベースの選択や，利用手順に関する
問題が発生している。

【０００６】例えば，商取引の発注者側は，複数の生産
者のデータベースから最新の製品情報を入手したり，自
分の期待に最も満足する生産者を選択して，その生産者
から製品を購入したいという要求がある。また生産者側
は，自分の持つ製品に興味を持つような適切な顧客を見
つけ出したり，発注者に自社製品を納入した後で，保守
のために納入先のデータベースにアクセスして，製品の
稼動情報を取得したいといった要求がある。このよう
に，会社間にまたがって，データベースを相互に参照・
利用しようという要求は，現実のものとして強く存在す
る。

【０００７】しかしながら，データベースの形式や利用
手順の差が，会社間はもとより，社内にも存在する場合
があり，相互利用の大きな障害になっている。また，実
際の業務に用いる場合には，情報の機密の確保や，利用
権限の管理を厳しく行う必要があり，これらの点も問題
となっている。

【０００８】このような問題を解決する方法として，ネ
ットワーク上にエージェント（代理人）と呼ばれるプロ
グラムを用いて，エージェントにユーザとデータベース
との間を仲介させる方法が提案されている。エージェン
トは多数のデータベースの内容や利用手順を知ってお
り，データベースの選択や，利用手順の差異の吸収や，
利用権限のチェックは，エージェントが行う。ユーザか
ら見た場合，エージェントは多数のデータベースを統合
したような，仮想統合データベースとして見える。

【０００９】

【発明が解決しようとする課題】以上のような技術的背
景のもとで，本発明は，複数のユーザと複数のデータベ
ースが存在する場合に，ユーザとデータベースの間を仲
介する機構を対象としている。本仲介機構は，以下のよ
うなユーザやデータベースを仮定している。機種の異な
る計算機上で複数のデータベースが動作するような，い
わゆる異機種分散データベース環境では，ごく自然にこ
のような状況が発生する。

【００１０】・ユーザは一般に複数存在し，ユーザの発
行する要求や受け取る回答の形式が複数存在する。 ・データベースは一般に複数存在し，データベースの発
行する要求や受け取る回答の形式が複数存在する。

【００１１】本仲介機構は，このような仮定の下で以下
の機能の実現を図る。これらの機能を図２７に示す。図
中，８０はユーザ，８１は仲介機構，８２〜８５はデー
タベースを表す。なお，本明細書では要求側をユーザ，
回答側をデータベースと呼んでおり，本発明は狭義のユ
ーザ，狭義のデータベースに限定されるわけではない。
一般には適切な要求や回答が行える人間，情報機器，プ
ログラム等が，要求側（本発明でのユーザ）や回答側
（本発明でのデータベース）になり得る。

【００１２】（１）ユーザ８０の指定する出力手順に沿
って要求を受け取る。 （２）ユーザ８０の要求に基づいて，データベース８２
〜８５の中から，その要求を処理する適切なデータベー
スを選択する。なお，選択されたデータベースは複数の
場合もあり得る。

【００１３】（３）データベースの指定する入力手順に
合わせて，要求を送る。 （４）データベースの指定する出力手順に合わせて，回
答を受け取る。選択されたデータベースが複数の場合に
は，複数の回答を取りまとめる。

【００１４】（５）ユーザ８０の指定する入力手順に沿
って回答を送付する。このような仲介機構を単純に実現
する方法として，集中構成による実装を行う方法が考え
られる。図２８は，集中構成による仲介機構の説明図で
ある。

【００１５】仲介機能の集中構成とは，図２８のよう
に，一つのプログラムで実現される仲介機構９３がすべ
てのユーザ９０〜９２からの出力を受信し，すべてのデ
ータベース９４〜９７に入力する構成を指す。データベ
ース９４〜９７からの回答は，この逆の道筋を通り，一
度，仲介機構９３に集められたあとで，質問をしたユー
ザ９０〜９２に送られる。しかし，このような集中構成
では，以下のような問題が発生する。

【００１６】・「動作時の負荷の集中」すべての仲介作
業を一つのプログラムで行うため，負荷が大きくなりや
すい。また，ユーザ，データベースの増加が直接負荷の
増加になり，負荷を分散させることができない。

【００１７】・「運用管理コストの集中」ユーザやデー
タベースを登録するような運用形態の場合，それぞれが
増加するたびにプログラムの設定変更が必要になり，シ
ステム全体に対して影響が発生する。また，入出力形式
が変更，削除されたり新規に追加される場合にも，プロ
グラムの変更が必要となるため，システム全体に対して
影響が発生する。

【００１８】・「情報の機密を保持できない」例えば，
どのデータベースがどのような要求を受け付けられるか
は，場合によっては機密情報となりえるが，集中構成で
はそのような情報が一箇所に集められるため，情報の機
密が保持できない。例えば，図２８に示す仲介機構９３
は，すべてのデータベース９４〜９７に対してアクセス
することができ，仲介機構９３の管理者は，データベー
ス９４〜９７の情報を何らの制限なしに得ることができ
る。

【００１９】本発明は，仲介機構を分散構成にすること
によって，動作時の負荷の集中，運用管理コストの集
中，情報の機密を保持できないという集中構成の問題点
を解決することを目的とする。

【００２０】

【課題を解決するための手段】図１は本発明の原理説明
図である。本発明では，一つの仲介機構を，エージェン
トと呼ばれる通信機能を持ったプロセスを複数用いるこ
とにより実現する。エージェントは，一般に複数の計算
機上で動作するが，１台の計算機上で一つのエージェン
トのみが動作する場合もあるし，複数のエージェントが
動作する場合もあり得る。

【００２１】図１に示すように，分散構成による仲介機
構を，３種類のエージェントを用いて構成する。エージ
ェントの分類と役割は，以下の通りである。 ・ユーザ・エージェント ユーザ・エージェント２１〜２４は，ユーザ１１〜１３
とエージェント群（仲介機構全体）とのインターフェイ
スを取り持つエージェントである。ユーザ毎にアクセス
の方法や必要とする回答の書式が異なる場合には，その
差異はユーザ・エージェント２１〜２４が吸収する。ユ
ーザ数が増加した場合にも，ユーザ・エージェントを局
所的に増加させることで，エージェント群全体を変更せ
ずに対応できる。

【００２２】・仲介エージェント 仲介エージェント３１〜３８は，ユーザ・エージェント
２１〜２４とデータベース・エージェント（以下，ＤＢ
エージェントと記す）４１〜４４との間を仲介するエー
ジェントである。ユーザ・エージェント２１〜２４は，
仲介エージェント３１〜３８に要求を送付することで，
ＤＢエージェント４１〜４４を選択する。

【００２３】・ＤＢエージェント ＤＢエージェント４１〜４４は，データベース５１〜５
４とエージェント群との間のインターフェイスを取り持
つエージェントである。データベース５１〜５４毎の利
用手順の差異や，回答形式の差異は，ＤＢエージェント
４１〜４４が吸収する。データベースが追加された場合
でも，対応するＤＢエージェントを追加することで，エ
ージェント群全体を変更せずに対応できる。

【００２４】以上のユーザ・エージェント，仲介エージ
ェントおよびＤＢエージェントを実現するプログラム
は，計算機が読み取り可能な適当な記憶媒体に格納する
ことができる。そのプログラムを記憶媒体から計算機の
メモリにローディングし，実行することにより，ユーザ
・エージェント，仲介エージェントおよびＤＢエージェ
ントを動作させることができる。

【００２５】

【発明の実施の形態】以下，本発明の実施の形態を図面
を参照して説明する。 １．システム構成 図２は，本発明の実施の形態におけるシステム構成の例
を示す。

【００２６】図２において，６１〜６８はＣＰＵおよび
メモリ等からなる計算機，ＵＡはユーザ・エージェント
（User Agent) ，ＦＡは仲介エージェント（Facilitate
Agent) ，ＤＡはＤＢエージェント（Database Agen
t），７１，７２はＷＡＮやＬＡＮなどのネットワー
ク，７３はネットワーク間の接続を行うルータを表す。

【００２７】各エージェントＵＡ，ＦＡ，ＤＡは，他の
エージェントと通信する機能を持つ。これらのエージェ
ント群は，一般に複数の計算機上で動作する。１台の計
算機上で一つのエージェントのみが動作する場合もある
し，複数のエージェントが動作する場合もあり得る。複
数の計算機に分散された各データベース５１〜５４に対
応して，これらのデータベース５１〜５４にそれぞれア
クセスするためのＤＢエージェントＤＡが配置される。

【００２８】例えば，計算機６２のユーザが，ユーザ・
エージェントＵＡを介してデータベース選択要求を行う
と，その要求に関する条件に応じて要求の送付先が順次
決定され，データベース５１が該当する場合には，仲介
エージェントＦＡ，ネットワーク７１，ネットワーク７
２および計算機６４の仲介エージェントＦＡとデータベ
ースエージェントＤＡを介してデータベース５１の選択
が行われるようになっている。一つの要求に対して，複
数のデータベースが該当する場合には，複数のデータベ
ースの選択が行われる。

【００２９】２．分散構成による仲介機構の動作 ２．１ ユーザからの要求手順 仲介機構の動作の説明の前に，まず仲介機構に対して与
えられるユーザからの要求について説明する。

【００３０】図３は，本実施の形態で対象とするユーザ
からの要求形式の例を示す図である。本実施の形態で対
象とするユーザからの要求形式は，インターフェイスの
統一のため，例えば図３のような形式に限定する。すな
わち，ユーザからの要求は，まずデータベースを選択す
るための要求が発行され，続いて選択されたデータベー
スに対する要求が必要な回数だけ発行され，最後に選択
したデータベースへの要求を終了する通知がなされるも
のとする。

【００３１】ユーザがデータベースの概要を把握してい
る場合には，ユーザはデータベースを選択するための要
求と，そのデータベースへの要求を区別して意識してい
ると思われる。そのため，このような限定を加えても実
際の利用には大きな不都合は生じない。また，このよう
な限定を加えた事により，仲介機構の動作を，この要求
のパターンに対応した，簡潔な理解しやすいものとする
ことが可能となる。この点は大きな利点である。

【００３２】以下では，データベースを選択する要求を
「ＤＢ選択要求」，選択されたデータベースに対しての
要求を「ＤＢ操作要求」，要求終了の通知を「ＤＢ完了
要求」，これらが複数個つながったものを「ＤＢ複合要
求」，以上すべてをまとめて「ＤＢ関連要求」と呼ぶこ
とにする。

【００３３】また，ＤＢ選択要求からＤＢ完了要求まで
を，ひとつの「セッション」と呼び，ユーザはセッショ
ン毎に一意な識別番号（セッションＩＤ）を割り当てる
ものとする。上記のＤＢ関連要求は，セッションＩＤと
ともに仲介機構に送られるものとする。これは，ＤＢ操
作要求などが単独でなされた場合，どのＤＢ選択要求に
対応するかを識別する必要があるためである。

【００３４】２．２ 個々のエージェント動作 ３種類のエージェントは，それぞれ基本動作と拡張動作
を行う。エージェントの基本動作とは，自分の持つ条件
に応じて，要求を配送し，回答をまとめる動作を指す。
各エージェントは，他のエージェントの宛先と，そのエ
ージェントに要求を送る場合に満たさなくてはならない
条件の組を持つ。この条件と宛先の記述されている表を
「条件表」と呼ぶ。

【００３５】図４は，このエージェントの持つ条件表の
構成例を示している。エージェントに要求が与えられた
場合，そのエージェントは条件表を参照してこの要求が
条件を満たす宛先すべてに対して，その要求を配送す
る。エージェントは，要求の回答をすべてまとめて，も
ともとの要求元に回答する。

【００３６】この基本動作では，同時にタイムアウト処
理や，要求の二重処理の回避も行われるが，これらに関
しては，それぞれ第２．４節，第２．５節において詳し
く説明する。

【００３７】以上の基本動作に加えて，ユーザ・エージ
ェントはユーザとのインターフェイス機能が，ＤＢエー
ジェントにはデータベースとのインターフェイス機能
が，拡張機能として定義されている。

【００３８】２．３ 全体的な仲介機構の動作 仲介機構のエージェント群の動作は，大きく２段階に別
れる。なお，以下のように２段階に分割したのは，一旦
選択した個別ＤＢに対して，異なる要求を何度も繰り返
す可能性が大きいためである。

【００３９】（１）個別ＤＢ群の選択 第１段階では，まず個別のデータベースの選択を行う。
選択されたデータベースを，ＤＢ群と呼ぶ。データベー
スには，まだ実際の要求は転送しない。

【００４０】（２）要求回答処理 第２段階では，第１段階で得られたＤＢ群に対して，実
際の要求を発行し，得られた回答をまとめてユーザに返
答する。

【００４１】このような仲介機構の動作を図５および図
６に従って説明する。図５は，仲介機構の第１段階の動
作例を示している。第１段階ではユーザの要求を満たす
ような，個別のデータベースを選択する。まず，ユーザ
からの要求をもとにして，ＤＢ選択要求をユーザ・エー
ジェントが発行する。ＤＢ選択要求は，その要求を受け
取った仲介エージェントの持つ条件表に基づいて分岐し
ていき，最後にはＤＢエージェントにまで到達する。

【００４２】図５（Ａ）の例では，ユーザ１２のＤＢ選
択要求をユーザ・エージェント２２が受け取り，各エー
ジェントが持つ条件表に従って，順次，仲介エージェン
ト３２，３１，３６へ送られている。仲介エージェント
３６では，条件を満たす仲介エージェント３７とＤＢエ
ージェント４１へ要求を送り，さらに仲介エージェント
３７では，ＤＢエージェント４２，４４へ要求を送って
いる。

【００４３】要求を受け取ったＤＢエージェント４１，
４２，４４は，その要求が自分の持つ条件を満たしてい
る場合には，自分の管理するデータベース５１，５２，
５４の名前をそれぞれ返し，そうでなければエラーを返
す。

【００４４】なお，一度処理した要求が同じエージェン
トに二度来た場合には，そのエージェントがエラーを返
答し，条件表による配送処理は行わない。図５（Ａ）中
の点線の矢印は，同じ要求が二重に到着したためエラー
になった経路である。例えば，仲介エージェント３１に
は，同じ要求が仲介エージェント３２，３４から送付さ
れている。この場合，後からの要求はエラーとして棄却
される。

【００４５】図５（Ｂ）は，ＤＢ選択結果の集約の過程
を示している。各エージェントは，自分が発行したすべ
てのメッセージの回答もしくはエラーがそろった時点
で，それらをまとめて要求元に返答する。この動作が繰
り返され，最終的には，送られてきた経路の逆を通っ
て，すべての回答が最初のユーザ・エージェント２２に
集められる。そのため，最初のユーザ・エージェント２
２は，エージェント群によって選択された個別データベ
ース５１，５２，５４の集合（ＤＢ群）を持つことにな
る。

【００４６】図６は，仲介機構の第２段階の動作例を示
している。第２段階では，図６（Ａ）のように，選択さ
れたＤＢ群に対応するＤＢエージェント４１，４２，４
４に対して，最初のユーザ・エージェント２２から直接
ＤＢ操作要求を送る。各ＤＢエージェント４１，４２，
４４は，送られた要求をデータベース５１，５２，５４
に与え，図６（Ｂ）のように，得られた回答をユーザ・
エージェント２２に返答する。ユーザ・エージェント２
２は，各ＤＢエージェント４１，４２，４４から得られ
た回答をまとめて，ユーザ１２に返答する。以上によ
り，ユーザ１２の発行した質問に対して，仲介機構から
の回答がなされたことになる。

【００４７】２．４ タイムアウト処理 分散構成でシステムを構成した場合には，エージェント
の予期せぬ動作や通信回線のトラブルなどにより，要求
への回答が戻ってこない場合が考えられる。そのような
場合には返答を永久に待ち続けるのではなく，一定時間
待った後に返答がなければあきらめて，エラー処理を行
う必要がある。このような処理を「タイムアウト処理」
と呼ぶ。

【００４８】従来のタイムアウト処理は，一回の通信に
対してあらかじめ決められた時間だけ待つようにする方
式であった。しかし，分散構成で仲介機構を実現する場
合には，通信が何段にも連続して行われる。このような
場合に，途中の通信すべてに同一のタイムアウト時間を
設定すると，それぞれの通信や計算処理に要する時間が
考慮されていないため，ユーザとの間のインターフェイ
スはタイムアウトで終了しているにもかかわらず，内部
では回答を計算し続けるような，無駄な処理を行ってし
まう可能性がある。

【００４９】そのため，通信が何段も中継されるような
場合に，途中の通信時間，計算時間などの処理時間を考
慮して，タイムアウトまでの時間を決める方式を考える
必要がある。ここでは，以下の二つの方式を考案した。

【００５０】［方式１］タイムアウトする時刻を指定す
る方式 この方式は特定の時刻になったときにタイムアウト処理
を行うように指定する方式である。次のエージェントに
渡すタイムアウトの時刻は，自分の回答処理に必要な時
間を差し引いた時刻とする。

【００５１】［方式２］タイムアウトまでの猶予時間を
引き継ぐ方式 この方式では，要求を受け取る際に，この要求に対する
返答を行うまでの猶予時間を同時に受け取る。要求を受
け取ったエージェントは，この猶予時間から自分の要求
処理および回答処理に必要な時間を差し引いて，新しい
猶予時間を計算する。次のエージェントに要求を配送す
る際には，要求と同時に新しい猶予時間を与え，自分も
新しい猶予時間だけ返答を待ち，返答が時間内に到着し
なければ，エラーを要求元に返答する。

【００５２】方式１は，タイムアウトを時刻で管理する
ために，エージェントが自分の処理に必要な時間を不正
確に見積もった場合にも，ユーザの指定した時刻を越え
て不必要な処理が行われない点が利点である。逆に欠点
としては，エージェントの参照する時計の時刻を，すべ
てのエージェントにおいて正しく設定しておく必要があ
る点が挙げられる。

【００５３】方式２は，時刻ではなく時間間隔でタイム
アウトを管理するために，各エージェントの参照する時
計の時刻を正しく設定しておく必要が必ずしもない点が
利点である。分散構成でエージェントを動作させる場合
には，すべての時計が正しく設定されていることが期待
できない場合が多い。このような場合には，時刻を用い
る方式１は採用不可能である。逆に欠点としては，エー
ジェントが自分の処理に必要な時間を短く見積もった場
合には，ユーザの指定した時刻を過ぎても，回答を生成
するための処理が，引き続き行われてしまう可能性があ
る。

【００５４】ここでは，以上の点を総合的に考慮した結
果，タイムアウトまでの猶予時間を引き継ぐ方式を採用
した。 ２．５ 要求の二重処理の回避方式 各エージェントは，図４に示すような条件表に基づい
て，ＤＢ選択要求の次の配送先を決定するが，条件表の
複数の項目が満たされた場合には，それぞれの配送先に
同じ要求を配送する。このような同じ要求は，要求配送
の経路がループ状につながってしまった場合には，その
ままでは同じ要求がタイムアウトになるまで繰り返し処
理され続けることになり，非効率的である。また，もと
は同じ要求から複製されたいくつもの要求が，同じエー
ジェントに配送される可能性もある。この場合も同じ要
求が何度も処理されるため，同様に非効率的である。

【００５５】このような事態を避けるため，ここでは要
求を最初に発行するユーザ・エージェントが，要求に識
別番号（要求ＩＤ）を付加する方式を採用する。識別番
号はすべてのエージェント群を通して，重複することの
ないような番号にする。このような番号は，ユーザ・エ
ージェントの動作する計算機のネットワーク上での名前
（ホスト名など）と，シーケンス番号または要求を発行
する時刻などを組み合わせることにより，容易に生成可
能である。

【００５６】各エージェントは，自分が過去に処理した
要求の要求ＩＤを記録している。新たに要求が与えられ
た場合には，その要求ＩＤと記録中の番号とを比較す
る。一致した要求ＩＤが発見された場合には，二重に要
求が届いた場合であるので，エラーを返答する。

【００５７】古い要求の要求ＩＤを記憶から除去する方
法には何通りか考えられる。例えば，記憶している要求
ＩＤの個数が，あらかじめ定めておいた上限に達した場
合に，古い要求ＩＤを除去する方式や，要求処理後一定
時間を経過した場合にその要求ＩＤを除去する方法など
が挙げられる。前者は，古い要求ＩＤが必ず一定数存在
することになるので，新しい要求ＩＤとの比較に時間を
要する。また後者は，消去するまでの待ち時間を適切に
定める必要がある。

【００５８】本実施の形態では，主に後者を用いる。す
なわち，ある要求の要求ＩＤは，その要求に付属してい
るタイムアウト猶予時間が経過した後に消去するものと
する。この方法で要求の二重処理が発生しないことは，
以下のように説明できる。

【００５９】まず，一つの要求が二つに分岐したのち，
あるエージェントに別々に到着した場合を想定しよう。
そのエージェントは，先に到着した方の要求の要求ＩＤ
を，その要求のタイムアウト猶予時間以上の間，保持し
ておく。このタイムアウト猶予時間は，「この時間が経
過した時にメッセージを送ると，最初に要求を生成した
ユーザ・エージェントがタイムアウトする直前にメッセ
ージが到着するような時間」を意味している。

【００６０】さて，このタイムアウト猶予時間が経過し
たのちに，同じ要求ＩＤを持つ要求が，そのエージェン
トに到達する場合があるかどうかを考えよう。この要求
は，はじめの要求と比べて遠回りをしてこのエージェン
トに到着している。そのため，このエージェントから回
答がなされる場合にも，同じ経路を通って，遠回りで回
答が伝達される。したがって，あとからの要求に付属す
るタイムアウト猶予時間は，はじめの要求のものと比べ
て，短くなっているはずである。つまり，あとの要求の
回答は，はじめの回答の要求よりも，早い時刻に回答し
なければ間に合わないはずである。したがって，はじめ
に到着した要求のタイムアウト猶予時間が経過した後
で，同じ要求ＩＤを持つ別の要求が到着することは，原
理的には有り得ない。そのため，要求ＩＤを保持してお
く時間は，先に到着した要求のタイムアウト猶予時間で
十分であるといえる。

【００６１】ただし，実際にはタイムアウト猶予時間を
次のエージェントに伝える際に，自分のエージェントの
処理に必要な時間を正確に予測できない場合が発生する
と予想される。そのため，現実的には，与えられたタイ
ムアウト猶予時間よりも多少長めに要求ＩＤを記録して
おくのが望ましい。

【００６２】なお，要求ＩＤの記憶数には限界があるた
め，記憶している一定数を越えた場合には古い要求ＩＤ
から消去していく方法も，併せて採用する。これは十分
な記憶容量が確保できない場合に用いられるものであ
り，補助的なものである。

【００６３】３．各エージェントのモジュール構成およ
びフローチャート ３．１ ユーザ・エージェントの場合 ユーザ・エージェントのモジュール構成は，図７に示す
ようになっている。ユーザ・エージェントは，内部的に
は複数のプロセスで構成されている。図７において，入
力受付部２０１，条件部２０３，要求ＩＤ記録部２０
４，ＤＢ群記録部２０５は，常駐型のプロセスであり，
ユーザ・エージェントが起動されてから終了要求が来る
までの間，外部からの入力を待ちながら動作し続けてい
る。入力処理部２０２は，外部からの入力が入力受付部
２０１に来るたびに生成されるプロセスである。

【００６４】実際の処理は，主に入力処理部２０２が，
他の内部プロセスや他のエージェントと通信を行いなが
ら実行する。このように入力処理部２０２が外部入力の
たびに生成されるのは，一つのプロセスで入力を処理し
ようとすると，一つの入力の処理が終らない限り，次の
処理に進めなくなり，ユーザから見た時の仲介機構の反
応が，鈍くなるのを避けるためである。なお，以下の説
明において「〜部」と称する場合には独立して動作する
内部プロセスを指し，「〜ルーチン」と称する場合に
は，ある内部プロセスの一部を構成するサブルーチンを
表す。

【００６５】入力受付部２０１は，図８に示すＤＢエー
ジェントの入力受付部３０１と同じ仕様である。要求を
チェックし，入力処理部２０２を起動して，要求の処理
を依頼する。終了要求が管理者によって与えられた場合
には，処理を終了する。またデバッグのための情報や，
アクセス記録などの内部情報が要求された場合には，そ
れらの情報を返答する。内部情報とは，具体的にはデバ
ッグのための経路トレース情報や管理運用のための時間
帯別の処理件数などの情報である。

【００６６】入力処理部２０２は，ＤＢ複合要求が来た
場合には個々のＤＢ関連要求に分解し，それぞれを個別
要求処理ルーチンに渡して，要求に対する処理を行う。
ＤＢ群記録部２０５は，ＤＢ選択要求によって選択され
たＤＢ群をセッションＩＤをキーにして記録し，ＤＢ群
の検索，削除などに対応する。記録情報は，例えば次の
ようなものである。

【００６７】 （セッションＩＤ１，｛ＤＢ１１，ＤＢ１２，…｝） （セッションＩＤ２，｛ＤＢ２１，ＤＢ２２，…｝） …… 条件部２０３，要求ＩＤ記録部２０４の仕様は，仲介エ
ージェント（図８）の条件部３０３，要求ＩＤ記録部３
０４，およびＤＢエージェント（図９）の条件部４０
３，要求ＩＤ記録部４０４と共通である。

【００６８】条件部２０３は，図４で説明したような要
求の配送先を決定する条件表を保持し，入力処理部２０
２からの要求に応じて条件表を回答する。また，エージ
ェントの管理者からの条件の登録，削除要求なども処理
する。要求ＩＤ記録部２０４は，過去に処理を行ったこ
とのある要求の識別番号（要求ＩＤ）と，その要求に対
するタイムアウト猶予時間を記録しておく内部プロセス
である。主に登録要求，検索要求を受け付ける。要求Ｉ
Ｄ記録部２０４には，記録できる要求ＩＤの個数に上限
が設定されており，その上限を越えて記録しようとした
場合には，古い要求ＩＤを上書きする。また，検索要求
がなされた場合には，記憶している過去の要求ＩＤと順
に照合して行くが，一致する要求ＩＤが見つかればその
ＩＤを，そうでなければ見つからなかった旨を返答す
る。

【００６９】なお，第２．５節で述べたように，要求Ｉ
Ｄは，そのエージェントのタイムアウト猶予時間を経過
したものは削除してよい。本実施の形態では，削除処理
を別個に設けることはせず，検索中に，十分古い要求Ｉ
Ｄが見つかった場合には，その要求ＩＤを削除すること
にする。

【００７０】他に，内部プロセスではないが，大きな処
理単位として，個別要求処理ルーチン，ＤＢ操作要求処
理ルーチンがある。これについては，処理フローチャー
トの説明で後述する。

【００７１】３．２ 仲介エージェントの場合 仲介エージェントは，図８に示すように，入力受付部３
０１，入力処理部３０２，条件部３０３および要求ＩＤ
記録部３０４の４種類の内部プロセスから構成されてい
る。ユーザ・エージェントの場合と同様に，入力処理部
３０２は，外部からの入力が入力受付部に来るたびに生
成されるプロセスであり，他は常駐プロセスである。

【００７２】入力受付部３０１は，要求ＩＤをもとに二
重要求（以前処理したことのある要求）かどうかをチェ
ックし，そうならばエラーを返す。要求がＤＢ選択要求
であれば，入力処理部３０２を起動し，処理を依頼す
る。

【００７３】入力処理部３０２は，自分に与えられる要
求はＤＢ選択要求のみであるので，そのままＤＢ選択要
求処理ルーチン（後述する）を呼ぶ。条件部３０３，要
求ＩＤ記録部３０４は，全エージェントに共通であり，
図７のユーザ・エージェントで説明した処理と同様な処
理を行う。

【００７４】３．３ ＤＢエージェントの場合 ＤＢエージェントは，図９に示すように，入力受付部４
０１，入力処理部４０２，条件部４０３，要求ＩＤ記録
部４０４およびＤＢインターフェイス部４０５の５種類
の内部プロセスから構成されている。ユーザ・エージェ
ントの場合と同様に，入力処理部４０２は，外部からの
入力が入力受付部４０１に来るたびに生成されるプロセ
スである。

【００７５】入力受付部４０１は，図７に示すユーザ・
エージェントの入力受付部２０１と同じ仕様である。入
力処理部４０２は，ＤＢ選択要求が来ればＤＢ選択要求
処理ルーチン（後述）を呼ぶ。ＤＢ操作要求であれば，
ＤＢインターフェイス部４０５に要求を転送する。

【００７６】ＤＢインターフェイス部４０５は，実際の
データベース５１と通信を行って，要求を依頼し，回答
を受け取る。ＤＢインターフェイス部４０５は，同時に
一度の要求しか処理しないようになっているので，複数
の要求を同時に受け取れないようなデータベースにも対
応している。

【００７７】条件部４０３，要求ＩＤ記録部４０４は，
全エージェントに共通であり，上述した処理を行う。 ３．４ 各部の処理フロー 図１０は，ユーザ・エージェントの入力受付部２０１お
よびＤＢエージェントの入力受付部３０１の処理フロー
チャートである。

【００７８】入力受付部２０１，３０１への入力情報
は，(a) セッションＩＤとＤＢ関連要求，(b) 終了要
求，(c) 内部情報要求のいずれかの情報である。入力受
付部２０１，３０１は，入力待ちの状態（図１０のステ
ップＳ１０）において，外部からの入力があると，まず
ステップＳ１１により二重要求チェックを行う。二重要
求であれば，その要求を廃棄するエラー（ＥＲＲＯＲ）
処理を行い（Ｓ１２，Ｓ１３），ステップＳ２０へ進
む。

【００７９】二重要求でない場合，ＤＢ関連要求である
かどうかを判定し（Ｓ１４），ＤＢ関連要求であれば入
力処理部２０１，３０１を生成して，その要求を引数と
して入力処理部２０１，３０１に渡す。その後，ステッ
プＳ２０へ進む。

【００８０】終了要求であれば，処理を終了する（Ｓ１
６）。デバッグや管理運用のための内部情報要求であれ
ば（Ｓ１７），要求された内部情報を要求元へ送り（Ｓ
１８），ステップＳ２０へ進む。内部情報要求でもなけ
れば，その要求をエラーとしてＥＲＲＯＲ処理を行い
（Ｓ１９），ステップＳ２０へ進む。ステップＳ２０で
は，内部情報として提供するための処理件数やエラー情
報などのアクセス記録の更新を行い，その後，ステップ
Ｓ１０の入力待ち状態に戻る。

【００８１】図１１は，ユーザ・エージェントの入力処
理部２０２の処理フローチャートである。入力処理部２
０２への入力情報は，セッションＩＤとＤＢ関連要求で
ある。ステップＳ３０では，ＤＢ関連要求を内部形式に
変換する。ステップＳ３１では，要求がＤＢ複合要求か
どうかを判定し，ＤＢ複合要求でなければ，ステップＳ
３２によって，個別要求処理ルーチン（図１２）を呼び
出し，個別のＤＢ関連要求を処理する。その後，ステッ
プＳ３７へ進む。

【００８２】ＤＢ複合要求であれば，ステップＳ３３へ
進み，一連の要求を個別要求に分解する。そして，分解
した個別要求について，先頭から順番にすべての個別要
求についての処理を行う（Ｓ３４〜Ｓ３６）。すべての
個別要求について処理をしたならばステップＳ３７へ進
む。

【００８３】ステップＳ３７では，結果をユーザの要求
する形式に変換して回答し，その後，処理を終了する。
図１２は，ユーザ・エージェントの個別要求処理ルーチ
ンの処理フローチャートである。

【００８４】個別要求処理ルーチンへの入力情報は，
(a) セッションＩＤとＤＢ選択要求，(b) セッションＩ
ＤとＤＢ操作要求，(c) セッションＩＤとＤＢ完了要求
のいずれかの情報である。

【００８５】最初に，ＤＢ選択要求であるかどうかを判
定し（Ｓ４０），ＤＢ選択要求であれば，新規に要求Ｉ
Ｄ，タイムアウト猶予時間を設定した後に，ＤＢ選択要
求処理ルーチン（図１３）を呼び，条件表に基づいてＤ
Ｂ選択要求を仲介エージェント，ＤＢエージェントに配
送し，条件を満たすＤＢ群を選択し，ＤＢ群記録部２０
５にセッションＩＤとともに記録する（Ｓ４１〜Ｓ４
４）。

【００８６】要求がＤＢ操作要求であれば（Ｓ４５），
ＤＢ操作要求処理ルーチン（図１５）を呼ぶ（Ｓ４
６）。要求がＤＢ完了要求であれば（Ｓ４７），付属す
るセッションＩＤを使って，対応するＤＢ群を，ＤＢ群
記録部２０５に要求して削除する（Ｓ４８）。

【００８７】図１３は，ＤＢ選択要求処理ルーチンの処
理フローチャートである。なお，ＤＢ選択要求処理ルー
チンは，全エージェントに共通のサブルーチンである。
ＤＢ選択要求処理ルーチンへの入力情報は，ＤＢ選択要
求と要求ＩＤとタイムアウト猶予時間の情報である。ま
ず，ステップＳ５０では，入力したタイムアウト猶予時
間を自分の処理に必要な時間だけ減少させる。次に，ス
テップＳ５１では，タイムアウト猶予時間が０以下であ
るかどうかをチェックし（Ｓ５１），０以下になってい
れば，エラー（ＥＲＲＯＲ）処理を行い（Ｓ５２），処
理を終了する。

【００８８】タイムアウト猶予時間が０以下になってい
なければ，条件部から条件表を取得し（Ｓ５３），条件
に合う出力先のリストを作成する（Ｓ５４）。そして，
すべての出力先に対してステップＳ５５１〜Ｓ５５３を
実行する（Ｓ５５）。すなわち，出力先が自分でなけれ
ば（Ｓ５５１），出力先に要求を送付する（Ｓ５５
２）。出力先が自分となっている場合，ここでは特別な
意味を持たせており，自分の宛先を回答する（Ｓ５５
３）。すなわち，ＤＢエージェントの場合，自分が管理
するデータベースの名前を回答する処理を行う。

【００８９】次に，ステップＳ５６では，回答待ちルー
チン（図１４）を呼び出し，その後，ステップＳ５７に
よって回答をまとめて，その回答を要求元へ返送する。
図１４は，回答待ちルーチンの処理フローチャートであ
る。回答待ちルーチンは，全エージェントに共通のサブ
ルーチンである。

【００９０】回答待ちルーチンの入力情報は，タイムア
ウト猶予時間と回答を行うエージェント群の情報であ
る。回答待ちルーチンは，タイムアウト処理を行う部分
であり，返答がくるか，またはタイムアウト猶予時間が
経過するのを待つ（Ｓ６０）。すべての返答が揃うか，
タイムアウト猶予時間が経過するかのいずれかが満たさ
れると，その時点までに得られている回答を返答し（Ｓ
６１〜Ｓ６３），処理を終了する。

【００９１】図１５は，ユーザ・エージェントのＤＢ操
作要求処理ルーチンの処理フローチャートである。ＤＢ
操作要求処理ルーチンへの入力情報は，セッションＩＤ
とＤＢ操作要求である。ＤＢ操作要求処理ルーチンは，
実際にＤＢ操作要求を処理する部分である。ステップＳ
７０では，ＤＢ群記録部２０５から与えられたセッショ
ンＩＤに対応するＤＢ群を取得する。次に，ステップＳ
７１では，要求ＩＤを新規に登録し，続いてステップＳ
７２では，タイムアウト猶予時間を決定する。

【００９２】ステップＳ７３では，ＤＢ群記録部２０５
から得たＤＢ群内のすべてのＤＢエージェントに（ＤＢ
操作要求，要求ＩＤ，タイムアウト猶予時間）の要求メ
ッセージを発行する。その後，ステップＳ７４では，図
１４の回答待ちルーチンを呼び出し，ステップＳ７５で
は，結果を集計してユーザへ回答する。

【００９３】図１６は，ユーザ・エージェントのＤＢ群
記録部２０５の処理フローチャートである。ＤＢ群記録
部２０５への入力情報は，検索または削除時の場合には
セッションＩＤ，登録時の場合にはセッションＩＤとＤ
Ｂ群の情報である。または内部情報要求であることを示
す要求種別情報である。ＤＢ群記録部２０５は，入力待
ち状態（Ｓ８０）において要求があると，登録要求に対
しては，セッションＩＤとＤＢ群の登録処理（Ｓ８１，
Ｓ８２），削除要求に対しては，該当するセッションＩ
Ｄのエントリの削除処理（Ｓ８３，Ｓ８４），検索要求
に対しては，該当するセッションＩＤのエントリを回答
し（Ｓ８５，Ｓ８６），終了要求に対しては，処理を終
了する（Ｓ８７）。また，デバッグや管理運用のための
内部情報要求に対しては，要求された内部情報を提供す
る（Ｓ８８，Ｓ８９）。以上の要求に該当しない場合に
ついては，所定のエラー処理を行う（Ｓ９０）。

【００９４】その後，終了要求以外についてはアクセス
記録を更新し（Ｓ９１），ステップＳ８０の入力待ち状
態に戻る。図１７は，条件部の処理フローチャートであ
る。条件部の処理手続きは，全エージェントに共通であ
る。

【００９５】条件部への入力情報は，(a) 条件登録要
求，(b) 条件削除要求，(c) 条件表取得要求，(d) 終了
要求，(e) 内部情報要求のいずれかの情報である。ま
ず，ステップＳ１００では，初期条件として与えられた
条件表を所定のファイルから読み込み，ステップＳ１０
１で入力待ち状態に入る。何らかの要求があると，ステ
ップＳ１０２へ移り，要求が条件登録要求または条件削
除要求であるかどうかを判定する。条件登録要求または
条件削除要求の場合，要求元がアクセス権限を持つかど
うかをチェックし（Ｓ１０３），アクセス権限がなけれ
ばエラー処理を行う（Ｓ１０４）。アクセス権限があれ
ば，要求された条件表への条件の登録または条件の削除
を行い，書き換えた結果をファイルに書き込み，処理し
た旨を回答する（Ｓ１０５，Ｓ１０６）。

【００９６】要求が条件表取得要求の場合，条件表を要
求者に回答する（Ｓ１０７，Ｓ１０８）。終了要求に対
しては，処理を終了する（Ｓ１０９）。

【００９７】また，デバッグや管理運用のための内部情
報要求に対しては，要求された内部情報を提供する（Ｓ
１１０，Ｓ１１１）。以上の要求に該当しない場合につ
いては，所定のエラー処理を行う（Ｓ１１２）。

【００９８】その後，終了要求以外についてはアクセス
記録を更新し（Ｓ１１３），ステップＳ１０１の入力待
ち状態に戻る。図１８は，要求ＩＤ記録部の処理フロー
チャートである。要求ＩＤ記録部の処理手続きは，全エ
ージェントに共通である。

【００９９】要求ＩＤ記録部への入力情報は，(a) 登録
要求と要求ＩＤ，(b) 検索要求と要求ＩＤのいずれかの
情報である。ステップＳ１２０の入力待ち状態におい
て，何らかの要求があると，その要求種別に応じて以下
の処理を行う。

【０１００】登録要求の場合（Ｓ１２１），要求ＩＤの
記憶個数が上限に達したかどうかによって（Ｓ１２
２），最も古いＩＤへの新しい要求ＩＤの上書き（Ｓ１
２３），または空き領域への新しい要求ＩＤの追加登録
（Ｓ１２４）を行う。

【０１０１】検索要求の場合（Ｓ１２５），記録してい
る要求ＩＤと順に照合し（Ｓ１２６），同一ＩＤを発見
したときには該当エントリを回答する（Ｓ１２７）。全
ＩＤと照合しても要求ＩＤが見つからないときは，該当
無しを回答する（Ｓ１２８）。この照合の途中で，タイ
ムアウト猶予時間よりも十分に古い要求ＩＤを発見した
ときには，その要求ＩＤを削除する（Ｓ１２９）。

【０１０２】終了要求の場合，処理を終了する（Ｓ１３
０）。また，デバッグや管理運用のための内部情報要求
に対しては，要求された内部情報を提供する（Ｓ１３
１，Ｓ１３２）。以上の要求に該当しない場合について
は，所定のエラー処理を行う（Ｓ１３３）。

【０１０３】その後，終了要求以外についてはアクセス
記録を更新し（Ｓ１３４），ステップＳ１２０の入力待
ち状態に戻る。図１９は，仲介エージェントの入力受付
部３０１の処理フローチャートである。

【０１０４】入力受付部３０１は，外部から入力情報と
して，(a) ＤＢ選択要求と要求ＩＤとタイムアウト猶予
時間，(b) 終了要求，(c) 内部情報要求のいずれかの情
報を受け取る。入力待ち状態（Ｓ１５０）において，要
求を受け取ると，要求ＩＤをもとに二重要求かどうかを
チェックし（Ｓ１５１），二重要求であればエラー処理
を行う（Ｓ１５２，Ｓ１５３）。

【０１０５】二重要求でない場合，ＤＢ選択要求に対し
ては，入力処理部３０２を生成し，要求を引数として入
力処理部３０２に渡す（Ｓ１５４，Ｓ１５５）。終了要
求に対しては，処理を終了する（Ｓ１５６）。

【０１０６】また，デバッグや管理運用のための内部情
報要求に対しては，要求された内部情報を提供する（Ｓ
１５７，Ｓ１５８）。以上の要求に該当しない場合につ
いては，所定のエラー処理を行う（Ｓ１５９）。

【０１０７】その後，終了要求以外についてはアクセス
記録を更新し（Ｓ１６０），ステップＳ１５０の入力待
ち状態に戻る。図２０は，仲介エージェントの入力処理
部３０２の処理フローチャートである。

【０１０８】入力処理部３０２は，入力情報としてＤＢ
選択要求，その要求ＩＤおよびタイムアウト猶予時間の
情報を受け取ると，ステップＳ１４０において，ＤＢ選
択要求処理ルーチンを呼び出す。ＤＢ選択要求処理ルー
チンでは，図１３で説明した処理を行う。

【０１０９】図２１は，ＤＢエージェントの入力処理部
４０２の処理フローチャートである。入力処理部４０２
は，入力情報として，(a) ＤＢ選択要求，その要求ＩＤ
およびタイムアウト猶予時間，(b) ＤＢ操作要求，その
要求ＩＤおよびタイムアウト猶予時間のいずれかの情報
を受け取る。

【０１１０】ＤＢエージェントの入力処理部４０２は，
ＤＢ選択要求に対しては，ＤＢ選択要求処理ルーチン
（図１３）を呼び出す（Ｓ１６１，Ｓ１６２）。ＤＢ操
作要求に対しては，ＤＢインターフェイス部４０５に要
求を転送し，ＤＢインターフェイス部４０５からの回答
を要求元に転送する（Ｓ１６３〜Ｓ１６５）。それ以外
の要求に対しては，所定のエラー処理を行い（Ｓ１６
６），処理を終了する。

【０１１１】図２２は，ＤＢエージェントのＤＢインタ
ーフェイス部４０５の処理フローチャートである。ＤＢ
インターフェイス部４０５の入力情報は，(a) ＤＢ操作
要求，その要求ＩＤおよびタイムアウト猶予時間，(b)
終了要求，(c) 内部情報要求のいずれかの情報である。

【０１１２】ＤＢインターフェイス部４０５は，ステッ
プＳ１７０の入力待ちの状態において，ＤＢ操作要求を
受け取ると，データベース（ＤＢ）毎に指定された形式
でデータベース（ＤＢ）に要求する（Ｓ１７１，Ｓ１７
２）。ここで，指定された形式とは，例えばＤＢの種類
によって定まるアクセス言語等を用いることを意味す
る。ＤＢからの回答があれば，本システムにおいてあら
かじめ定められている内部形式に変換し，要求元に返答
する（Ｓ１７３，Ｓ１７４）。

【０１１３】終了要求に対しては，処理を終了する（Ｓ
１７５）。また，デバッグや管理運用のための内部情報
要求に対しては，要求された内部情報を提供する（Ｓ１
７６，Ｓ１７７）。以上の要求に該当しない場合につい
ては，所定のエラー処理を行う（Ｓ１７８）。

【０１１４】その後，終了要求以外についてはアクセス
記録を更新し（Ｓ１７９），ステップＳ１７０の入力待
ち状態に戻る。４．分散構成による仲介機構の特長およ
び効果以上の分散構成による仲介機構の要点を列挙する
と，以下のとおりである。

【０１１５】(1) 仲介機構を，ユーザ・エージェント，
仲介エージェント，ＤＢエージェントの３種類のエージ
ェントによって分散的に構成する。 (2) ３種類のエージェントの基本動作は同一とし，ユー
ザ・エージェント，ＤＢエージェントは，それらに拡張
機能を付与した構成とする。

【０１１６】(3) 複数のエージェントを別個の計算機上
で動作させることにより，負荷を分散させる。 (4) 各エージェントの内部を処理毎にプロセスに分割
し，並列動作を可能にする。

【０１１７】(5) ユーザからの要求を，ＤＢ選択のため
の要求と，選択したＤＢに対する要求に分割する。 (6) 仲介機構の動作を，個別ＤＢの選択と，選択したＤ
Ｂへの要求の２段階とする。

【０１１８】(7) 複数の仲介エージェントを経由した通
信により，複数の仲介エージェントの保持する条件を合
わせて用いて，データベースを選択する。 (8) エージェントが，自分に与えられたタイムアウトま
での猶予時間から，自分の処理に要する時間を差し引い
て，要求を転送したエージェントからの回答のタイムア
ウト猶予時間とすることにより，分散構成において，最
初に指定された時間内に間に合わないような無駄な処理
を回避する。

【０１１９】(9) 要求に識別番号を付与することで，要
求の二重処理を回避する。 (10)要求の識別番号を記録しておく時間を，そのエージ
ェントに与えられたタイムアウト猶予時間以上とするこ
とにより，不要な要求ＩＤを消去する。

【０１２０】(11)ユーザ・エージェントにより，ユーザ
との間の様々な入出力手順の差異を一括して吸収する。 (12)ＤＢエージェントにより，データベースとの間の様
々な入出力手順の差異を一括して吸収する。

【０１２１】(13)ユーザの設定情報の変更を，対応する
ユーザ・エージェントにより処理し，エージェント群全
体の設定変更は不要とする。 (14)データベースの設定情報の変更を，対応するＤＢエ
ージェントにより処理し，エージェント群全体の設定変
更は不要とする。

【０１２２】(15)全エージェントに新規エージェントや
エージェントの変更を登録することなしに，個別にエー
ジェントの追加，拡張を許す。 (16)エージェント全体をエージェント群に分割し，エー
ジェント群毎に機密保持を可能にする。

【０１２３】(17)特定のユーザの情報を，対応するユー
ザ・エージェントや，エージェント群の一部に限定して
保持することにより，ユーザの機密保持を可能にする。 (18)特定のデータベースの情報を，対応するＤＢエージ
ェントや，エージェント群の一部に限定して保持するこ
とにより，ユーザの機密保持を可能にする。

【０１２４】以上のように構成される仲介機構の特長と
しては，次のような点が挙げられる。 (a) 適用分野に依存しない構成 適用分野に依存するデータは，エージェントの持つ条件
表にすべて押し込められており，他の部分は適用分野に
依存しない。

【０１２５】(b) エージェントの追加，拡張が容易 全エージェントに登録する必要があるような，グローバ
ルなデータが存在しない。そのためエージェントの追加
などの拡張が容易である。

【０１２６】(c) 一定時間内での動作が期待可能 各エージェントの動作は，条件表を引いて出力先を決定
し，その出力先に入力を転送するだけなので，エージェ
ントの動作時間が見積もりやすい。また，ループなどの
要求の二重処理を禁止しているため，一定時間内での動
作が期待できる。

【０１２７】(d) 異なる機種の混在した機器構成によっ
て対応可能 各エージェントは，通信によって情報をやりとりし，共
有のデータを持たない。そのため，エージェントが動作
する計算機の機種などが異なるような，ヘテロな環境で
も動作させることが可能である。大規模なシステムを構
成する際には，単一の機種のみで構成するのは困難であ
る場合が多いため，異なる機種の混在を許す点は，大き
な利点である。

【０１２８】

【実施例】次に本発明の具体的な実施例について，図２
３〜図２６に従って説明する。図２３は，Ｃ１，Ｃ２，
Ｃ３の３社によるエージェント構成例を示す。

【０１２９】図２３において，Ｃｏｍｐａｎｙは会社で
あり，Ｃ１，Ｃ２，Ｃ３は会社名である。ｇｒｏｕｐ
は，会社の系列を表し，ここではＧａ企業グループとＧ
ｂ企業グループのどちらかである。ｒｅｇｉｏｎは，会
社の所在地，例えば関東地域，ｘｘ県またはｙｙ市とい
うような地域であり，ここではＲａ地域とＲｂ地域のど
ちらかである。ｃｏｎｔｅｎｔは，その会社の扱ってい
る商品分類（Ｘ，Ｙ，Ｚのどれか）であり，例えば乗用
車，食料品というようなものである。

【０１３０】会社Ｃ１は，Ｇａ企業グループに所属して
いて，場所はＲａ地域にある。会社Ｃ２は，Ｇｂ企業グ
ループに所属していて，場所はＲａ地域にある。会社Ｃ
３は，Ｇｂ企業グループに所属していて，場所はＲｂ地
域にある。

【０１３１】すなわち，会社Ｃ２と会社Ｃ３とは，同じ
企業グループの仲間同士であり，会社Ｃ１と会社Ｃ２と
は，同じ地域にある。会社Ｃ１が管理するエージェント
は，ユーザ・エージェントＵＡ１ａ，ＵＡ１ｂ，仲介エ
ージェントＦＡ１ｃ，ＤＢエージェントＤＡ１ｄ，ＤＡ
１ｅである。会社Ｃ１のデータベース１ｆ，１ｇは，そ
れぞれＸのｃｏｎｔｅｎｔ，ＹとＺのｃｏｎｔｅｎｔを
持つ。

【０１３２】会社Ｃ２が管理するエージェントは，ユー
ザ・エージェントＵＡ２ａ，ＵＡ２ｂ，仲介エージェン
トＦＡ２ｃ，ＤＢエージェントＤＡ２ｄである。会社Ｃ
２のデータベース２ｅは，ＸとＹとＺのｃｏｎｔｅｎｔ
を持つ。

【０１３３】会社Ｃ３が管理するエージェントは，ユー
ザ・エージェントＵＡ３ａ，仲介エージェントＦＡ３
ｂ，ＦＡ３ｃ，ＤＢエージェントＤＡ３ｄ，ＤＡ３ｅ，
ＤＡ３ｆである。会社Ｃ１のデータベース３ｇ，３ｈ，
３ｉは，それぞれＸのｃｏｎｔｅｎｔ，Ｙのｃｏｎｔｅ
ｎｔ，Ｚのｃｏｎｔｅｎｔを持つ。

【０１３４】これらのエージェントおよびデータベース
は，技術的には１台の計算機で実現することも可能であ
るが，現実には，次のような要素が考慮される。 (1) 異なる会社で同じ計算機上にサービスを実現するの
は，機密上，好ましくない。

【０１３５】(2) ユーザ・エージェントは，負荷分散の
観点からは複数用いるのが望ましい。 (3) 仲介エージェントの負荷は，あまり大きくないと予
想される。

【０１３６】(4) データベースは，通常大きなアプリケ
ーションであるので，１台の計算機に一つのみを動作さ
せるのが望ましい。 (5) ＤＢエージェントは，対応するデータベースの近く
で動作するほうがよい。

【０１３７】以上の点を考慮すると，図２３に示すエー
ジェントを実装するための好ましい計算機構成は，次の
ようになる。 (a) ユーザ・エージェント毎に１台の計算機を割り当て
る。

【０１３８】(b) データベースごとに１台の計算機を割
り当て，対応するＤＢエージェントも同じ計算機上で動
作させる。 (c) 仲介エージェントは，独立に計算機を割り当てる
か，ユーザ・エージェントの動作する計算機上，または
ＤＢエージェントの動作する計算機上で動作させる。

【０１３９】図２４〜図２６は，各会社Ｃ１，Ｃ２，Ｃ
３の各エージェントが持つ条件表の例を示している。条
件で“＊”とあるのは，どのような条件（あるいは値）
の場合にも，対応する出力先に要求を回送することを表
す。また，ＤＢエージェントの条件表で，出力先が自分
自身になっているのは，自分の管理下にあるデータベー
スにアクセスすることを示す。

【０１４０】会社Ｃ１のユーザ・エージェントＵＡ１ａ
は，図２４（Ａ）に示すような条件表を持つ。ユーザ・
エージェントＵＡ１ａは，どのような条件の要求に対し
ても，仲介エージェントＦＡ１ｃに要求を転送する。会
社Ｃ１のユーザ・エージェントＵＡ１ｂの条件表も同様
である（図２４（Ｂ））。

【０１４１】会社Ｃ１の仲介エージェントＦＡ１ｃは，
図２４（Ｃ）に示すような条件表を持つ。要求での指定
が会社Ｃ１，グループＧａまたは地域Ｒａのいずれかで
あり，かつ商品分類がＸであれば，要求の出力先をＤＢ
エージェントＤＡ１ｄとする。要求での指定が会社Ｃ
１，グループＧａまたは地域Ｒａのいずれかであり，か
つ商品分類がＹまたはＺであれば，要求の出力先をＤＢ
エージェントＤＡ１ｅとする。

【０１４２】また，要求での指定が会社Ｃ２，グループ
Ｇｂまたは地域Ｒａのいずれかであれば，要求の出力先
を会社Ｃ２の仲介エージェントＦＡ２ｃとする。要求で
の指定が会社Ｃ３，グループＧｂまたは地域Ｒｂのいず
れかであれば，要求の出力先を会社Ｃ３の仲介エージェ
ントＦＡ３ｂとする。

【０１４３】会社Ｃ１のＤＢエージェントＤＡ１ｄは，
図２４（Ｄ）に示すような条件表を持つ。ＤＢエージェ
ントＤＡ１ｄは，どのような条件の要求に対しても，出
力先が自分自身であるので，データベース１ｆを対象と
する処理を行い，結果を要求元へ返送する。会社Ｃ１の
ＤＢエージェントＤＡ１ｅの条件表も同様である（図２
４（Ｅ））。

【０１４４】会社Ｃ２のユーザ・エージェントＵＡ２ａ
は，図２５（Ａ）に示すような条件表を持つ。ユーザ・
エージェントＵＡ２ａは，どのような条件の要求に対し
ても，仲介エージェントＦＡ２ｃに要求を転送する。会
社Ｃ２のユーザ・エージェントＵＡ２ｂの条件表も同様
である（図２５（Ｂ））。

【０１４５】会社Ｃ２の仲介エージェントＦＡ２ｃは，
図２５（Ｃ）に示すような条件表を持つ。要求での指定
が会社Ｃ１，グループＧａまたは地域Ｒａのいずれかの
場合，要求の出力先を仲介エージェントＦＡ１ｃとす
る。要求での指定が会社Ｃ２，グループＧｂまたは地域
Ｒａのいずれかであれば，要求の出力先を自会社Ｃ２の
ＤＢエージェントＤＡ２ｄとする。要求での指定が会社
Ｃ３，グループＧｂまたは地域Ｒｂのいずれかであれ
ば，要求の出力先を会社Ｃ３の仲介エージェントＦＡ３
ｂとする。

【０１４６】会社Ｃ２のＤＢエージェントＤＡ２ｄは，
図２５（Ｄ）に示すような条件表を持つ。ＤＢエージェ
ントＤＡ２ｄは，どのような条件の要求に対しても，出
力先が自分自身であるので，データベース２ｅを対象と
する処理を行い，結果を要求元へ返送する。

【０１４７】会社Ｃ３のユーザ・エージェントＵＡ３ａ
は，図２６（Ａ）に示すような条件表を持つ。ユーザ・
エージェントＵＡ３ａは，要求での指定が会社Ｃ３でな
いか，地域Ｒａの場合に，仲介エージェントＦＡ３ｂに
要求を転送する。また，要求での指定が会社Ｃ３である
か，グループＧｂであるか，または地域Ｒｂである場合
に，仲介エージェントＦＡ３ｃに要求を転送する。

【０１４８】会社Ｃ３の仲介エージェントＦＡ３ｂは，
図２６（Ｂ）に示すような条件表を持つ。要求での指定
が会社Ｃ１，グループＧａまたは地域Ｒａのいずれかで
あれば，要求の出力先を仲介エージェントＦＡ１ｃとす
る。要求での指定が会社Ｃ２，グループＧｂまたは地域
Ｒａのいずれかであれば，要求の出力先を会社Ｃ２の仲
介エージェントＦＡ２ｃとする。また，要求での指定が
会社Ｃ３，グループＧｂまたは地域Ｒｂのいずれかであ
れば，要求の出力先を会社Ｃ３の仲介エージェントＦＡ
３ｃとする。

【０１４９】会社Ｃ３の仲介エージェントＦＡ３ｃは，
図２６（Ｃ）に示すような条件表を持つ。仲介エージェ
ントＦＡ３ｃは，要求された商品分類Ｘ，Ｙ，Ｚに応じ
て，それぞれ要求の出力先を，ＤＢエージェントＤＡ３
ｄ，ＤＡ３ｅ，ＤＡ３ｆとする。

【０１５０】会社Ｃ３のＤＢエージェントＤＡ３ｄ，Ｄ
Ａ３ｅ，ＤＡ３ｆは，それぞれ図２６（Ｄ），（Ｅ），
（Ｆ）に示すような条件表を持つ。これらは，どのよう
な条件の要求に対しても，出力先が自分自身であるの
で，それぞれデータベース３ｇ，３ｈ，３ｉを対象とす
る処理を行い，結果を要求元へ返送する。

【０１５１】次に，(1) 会社名を直接指定する場合，
(2) 会社のブランドを優先する場合など，企業グループ
のみを対象とする場合，(3) 近くにある会社から購入し
たい場合など，特定の地域にある会社を対象とする場合
を想定し，それぞれについて，順に上記の条件を使った
要求の回送例を説明する。

【０１５２】(1) 会社名を直接指定する場合の要求の回
送例 例えばユーザ・エージェントＵＡ１ａに接続しているユ
ーザが，「company =C1 and content = X」というＤＢ
選択要求を発行したとする。

【０１５３】この要求は，まず図２４（Ａ）に示す条件
表によって，仲介エージェントＦＡ１ｃへ回送され，次
に図２４（Ｃ）に示す条件表によって，ＤＢエージェン
トＤＡ１ｄへ回送される。結果として，データベース１
ｆが選択される。

【０１５４】(2) 企業グループのみを対象とする場合の
回送例 例えばユーザ・エージェントＵＡ２ａに接続しているユ
ーザが，「group = Gband content = Y」というＤＢ選
択要求を発行したとする。

【０１５５】この要求は，まず図２５（Ａ）に示す条件
表によって，仲介エージェントＦＡ２ｃへ回送され，次
に図２５（Ｃ）に示す条件表によって，ＤＢエージェン
トＤＡ２ｄと会社Ｃ３の仲介エージェントＦＡ３ｂへ回
送される。仲介エージェントＦＡ３ｂからは，図２６
（Ｂ）に示す条件表によって，仲介エージェントＦＡ２
ｃと仲介エージェントＦＡ３ｃへ回送される。このうち
仲介エージェントＦＡ２ｃへ回送された要求は，二重要
求チェックにより廃棄される。

【０１５６】さらに，仲介エージェントＦＡ３ｃから図
２６（Ｃ）に示す条件表によって，ＤＢエージェントＤ
Ａ３ｅへ回送され，結果として，会社Ｃ２のデータベー
ス２ｅと会社Ｃ３のデータベース３ｈが選択される。

【０１５７】(3) 特定の地域にある会社を対象とする場
合の回送例 例えばユーザ・エージェントＵＡ３ａに接続しているユ
ーザが，「region = Ra and content = Z 」というＤＢ
選択要求を発行したとする。

【０１５８】この要求は，まず図２６（Ａ）に示す条件
表によって，仲介エージェントＦＡ３ｂへ回送され，次
に図２６（Ｂ）に示す条件表によって，仲介エージェン
トＦＡ１ｃと仲介エージェントＦＡ２ｃへ回送される。
仲介エージェントＦＡ１ｃからは，図２４（Ｃ）に示す
条件表によって，ＤＢエージェントＤＡ１ｅへ回送さ
れ，仲介エージェントＦＡ２ｃからは，図２５（Ｃ）に
示す条件表によって，ＤＢエージェントＤＡ２ｄへ回送
される。結果として，会社Ｃ１のデータベース１ｇと会
社Ｃ２のデータベース２ｅが選択される。

【０１５９】以上のように，要求で指定された条件によ
って，該当するデータベースが自動的に選択される。な
お，条件表への条件として，例えばユーザの識別情報や
パスワードや回送元の情報などの条件を登録することも
可能であり，会社間での各種条件による機密保護を条件
表によって実現することも可能である。

【０１６０】

【発明の効果】以上説明したように，本発明によれば，
従来の集中構成の仲介機構と比較して，以下のような効
果が得られる。

【０１６１】(1) 動作時の負荷の分散が可能である。個
々のエージェントを別々の計算機上で動作させることに
より，仲介作業の負荷を分散できるため，ユーザから見
た場合に，待ち時間の少ない迅速な回答が期待できる。

【０１６２】(2) 運用管理コストの分散が可能なスケー
ラブルな構成を実現できる。ユーザ，データベースを登
録するような運用形態でも，登録が必要なのは，特定の
ユーザ・エージェントやＤＢエージェントであるため，
システム全体に対して設定変更などの作業をする必要は
ない。また，入出力形式が変更，削除，追加される場合
にも，特定のユーザ・エージェント，ＤＢエージェント
の変更や，削除，追加で対応可能であり，これもシステ
ム全体に対して設定変更などの作業をする必要はない。
したがって，ユーザ数やデータベース数の増加にも容易
に対応できるような，スケーラブルな構成を実現でき
る。

【０１６３】(3) 情報の機密を保持可能である。本機構
では情報をどこかに集めて管理するようなことは行わな
いため，機密が必要な単位でエージェント群を分割すれ
ば，その情報が外部に漏れることはなく，機密を保持で
きる。

【図面の簡単な説明】

【図１】本発明の原理説明図である。

【図２】本発明の実施の形態におけるシステム構成の例
を示す図である。

【図３】本実施の形態で対象とするユーザからの要求形
式の例を示す図である。

【図４】エージェントの持つ条件表の構成例を示す図で
ある。

【図５】仲介機構の動作例を説明するための図である。

【図６】仲介機構の動作例を説明するための図である。

【図７】ユーザ・エージェントのモジュール構成図であ
る。

【図８】仲介エージェントのモジュール構成図である。

【図９】ＤＢエージェントのモジュール構成図である。

【図１０】ユーザ・エージェントの入力受付部およびＤ
Ｂエージェントの入力受付部の処理フローチャートであ
る。

【図１１】ユーザ・エージェントの入力処理部の処理フ
ローチャートである。

【図１２】ユーザ・エージェントの個別要求処理ルーチ
ンの処理フローチャートである。

【図１３】ＤＢ選択要求処理ルーチンの処理フローチャ
ートである。

【図１４】回答待ちルーチンの処理フローチャートであ
る。

【図１５】ユーザ・エージェントのＤＢ操作要求処理ル
ーチンの処理フローチャートである。

【図１６】ユーザ・エージェントのＤＢ群記録部の処理
フローチャートである。

【図１７】条件部の処理フローチャートである。

【図１８】要求ＩＤ記録部の処理フローチャートであ
る。

【図１９】仲介エージェントの入力受付部の処理フロー
チャートである。

【図２０】仲介エージェントの入力処理部の処理フロー
チャートである。

【図２１】ＤＢエージェントの入力処理部の処理フロー
チャートである。

【図２２】ＤＢエージェントのＤＢインターフェイス部
の処理フローチャートである。

【図２３】本発明の実施例におけるエージェント構成例
を示す図である。

【図２４】会社Ｃ１の各エージェントが持つ条件表の例
を示す図である。

【図２５】会社Ｃ２の各エージェントが持つ条件表の例
を示す図である。

【図２６】会社Ｃ３の各エージェントが持つ条件表の例
を示す図である。

【図２７】本発明が対象とする仲介機構に求められる機
能の説明図である。

【図２８】集中構成による仲介機構の説明図である。

【符号の説明】

１１〜１３ ユーザ ２１〜２４ ユーザ・エージェント ３１〜３８ 仲介エージェント ４１〜４４ データベース・エージェント ５１〜５４ データベース

───────────────────────────────────────────────────── フロントページの続き (72)発明者 藤井 裕之 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 田渕 敬三 岡山県岡山市磨屋町10番12号 株式会社富 士通岡山システムエンジニアリング内 (72)発明者 河野 慎也 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内

Claims (22)

【特許請求の範囲】
1. 【請求項１】 １または複数の計算機においてユーザと
   データベースとを仲介する機能を実現するデータベース
   ・システムであって，ユーザとデータベースとの仲介機
   構を，１または複数のユーザ・エージェントと，１また
   は複数の仲介エージェントと，アクセス対象となるデー
   タベース対応に設けられる１または複数のデータベース
   ・エージェントとによって分散的に構成し，前記ユーザ
   ・エージェントは，データベースに対する要求をユーザ
   から受け付けて，その要求を他のエージェントへ送り，
   結果をユーザに対して出力する手段を持ち，前記仲介エ
   ージェントは，前記ユーザ・エージェントからのデータ
   ベース選択要求を受け付け，要求を送付すべき他の仲介
   エージェントまたはデータベース・エージェントを選択
   してその要求を送付する手段を持ち，前記データベース
   ・エージェントは，他のエージェントからの要求により
   データベースに対してアクセスし，結果を要求元へ返送
   する手段を持つことを特徴とするデータベース・システ
   ム
2. 【請求項２】 請求項１記載のデータベース・システム
   において，前記ユーザ・エージェント，前記仲介エージ
   ェントおよび前記データベース・エージェントを含む複
   数のエージェントを，エージェントの数と同じまたはエ
   ージェントの数より少ない複数の計算機上に配置し，複
   数のエージェントを別個の計算機上で動作させることに
   より，負荷を分散させるようにしたことを特徴とするデ
   ータベース・システム。
3. 【請求項３】 請求項１記載のデータベース・システム
   において，前記ユーザ・エージェント，前記仲介エージ
   ェントおよび前記データベース・エージェントの各エー
   ジェントの内部を処理毎にプロセスに分割し，各エージ
   ェントにおける処理の並列動作を可能にしたことを特徴
   とするデータベース・システム。
4. 【請求項４】 請求項１記載のデータベース・システム
   において，前記ユーザ・エージェント，前記仲介エージ
   ェントおよび前記データベース・エージェントによる仲
   介機構は，個別データベースの選択を処理する第１段階
   の処理手段と，選択したデータベースへの要求を処理す
   る第２段階の処理手段とを持ち，前記仲介機構の動作を
   個別データベースの選択と，選択したデータベースへの
   要求の２段階としたことを特徴とするデータベース・シ
   ステム。
5. 【請求項５】 請求項１記載のデータベース・システム
   において，前記ユーザ・エージェントは，ユーザからの
   要求を，データベース選択のための要求と，選択したデ
   ータベースに対する要求とに分割し，データベース選択
   のための要求は，その要求によって定められる前記仲介
   エージェントへ送付し，選択したデータベースに対する
   要求は，そのデータベースにアクセスする前記データベ
   ース・エージェントへ送付するようにしたことを特徴と
   するデータベース・システム。
6. 【請求項６】 請求項１記載のデータベース・システム
   において，複数の仲介エージェントを経由した通信によ
   り，複数の仲介エージェントの保持する条件を合わせて
   用いて，データベースを選択するようにしたことを特徴
   とするデータベース・システム。
7. 【請求項７】 請求項１記載のデータベース・システム
   において，前記各エージェントは，自分に与えられたタ
   イムアウトまでの猶予時間から，自分の処理に要する時
   間を差し引いて，要求を転送したエージェントからの回
   答のタイムアウト猶予時間とし，タイムアウトを処理す
   る手段を持つことを特徴とするデータベース・システ
   ム。
8. 【請求項８】 請求項１記載のデータベース・システム
   において，前記ユーザ・エージェントは，要求に識別番
   号を付与する手段を持ち，前記仲介エージェントおよび
   前記データベース・エージェントは，要求の識別番号を
   検査することにより異なる経路で伝達された同じ要求の
   二重処理を回避する手段を持つことを特徴とするデータ
   ベース・システム。
9. 【請求項９】 請求項８記載のデータベース・システム
   において，前記各エージェントは，自エージェントにお
   いて前記要求の識別番号を記録しておく時間を，そのエ
   ージェントに与えられたタイムアウト猶予時間以上と
   し，かつタイムアウト猶予時間が過ぎた要求の識別番号
   を消去する手段を持つことを特徴とするデータベース・
   システム。
10. 【請求項１０】 請求項１記載のデータベース・システ
    ムにおいて，前記ユーザ・エージェントは，ユーザから
    の要求を所定の内部形式のデータに変換する手段を持
    ち，ユーザとの間の様々な入出力手順の差異を一括して
    吸収するようにしたことを特徴とするデータベース・シ
    ステム。
11. 【請求項１１】 請求項１記載のデータベース・システ
    ムにおいて，前記データベース・エージェントは，内部
    形式で表されたデータベースに対する要求を，データベ
    ースに対応して定められる要求形式に変換する手段と，
    データベースからのアクセス結果を所定の内部形式のデ
    ータに変換する手段とを持ち，各データベースとの間の
    様々な入出力手順の差異を一括して吸収するようにした
    ことを特徴とするデータベース・システム。
12. 【請求項１２】 請求項１記載のデータベース・システ
    ムにおいて，ユーザの設定情報の変更を，対応する前記
    ユーザ・エージェントにより処理し，エージェント群全
    体の設定変更を不要としたことを特徴とするデータベー
    ス・システム。
13. 【請求項１３】 請求項１記載のデータベース・システ
    ムにおいて，データベースの設定情報の変更を，対応す
    る前記データベース・エージェントにより処理し，エー
    ジェント群全体の設定変更を不要としたことを特徴とす
    るデータベース・システム。
14. 【請求項１４】 請求項１記載のデータベース・システ
    ムにおいて，エージェント全体をエージェント群に分割
    し，エージェント群毎に機密保持を可能にしたことを特
    徴とするデータベース・システム。
15. 【請求項１５】 請求項１記載のデータベース・システ
    ムにおいて，特定のユーザの情報を，対応するユーザ・
    エージェントまたはエージェント群の一部に限定して保
    持することにより，ユーザの機密保持を可能にしたこと
    を特徴とするデータベース・システム。
16. 【請求項１６】 請求項１記載のデータベース・システ
    ムにおいて，特定のデータベースの情報を，対応するデ
    ータベース・エージェントまたはエージェント群の一部
    に限定して保持することにより，ユーザの機密保持を可
    能にしたことを特徴とするデータベース・システム。
17. 【請求項１７】 請求項１記載のデータベース・システ
    ムにおいて，前記ユーザ・エージェントは，ユーザから
    の入力を受け付ける入力受付部と，入力情報に基づいて
    出力先を決定する条件を管理する条件部と，入力した要
    求に付与した識別番号を記録する要求ＩＤ記録部と，入
    力情報から選択されたデータベース群を記録するＤＢ群
    記録部と，前記入力受付部からの入力毎に生成され，前
    記条件部，前記要求ＩＤ記録部および前記ＤＢ群記録部
    を利用し，他のエージェントとの通信によりその入力に
    対する処理を行う入力処理部とを備えたことを特徴とす
    るデータベース・システム。
18. 【請求項１８】 請求項１記載のデータベース・システ
    ムにおいて，前記仲介エージェントは，他のエージェン
    トからの入力を受け付ける入力受付部と，入力情報に基
    づいて出力先を決定する条件を管理する条件部と，入力
    した要求に付与した識別番号を記録する要求ＩＤ記録部
    と，前記入力受付部からの入力毎に生成され，前記条件
    部および前記要求ＩＤ記録部を利用し，他のエージェン
    トとの通信によりその入力に対する処理を行う入力処理
    部とを備えたことを特徴とするデータベース・システ
    ム。
19. 【請求項１９】 請求項１記載のデータベース・システ
    ムにおいて，前記データベース・エージェントは，他の
    エージェントからの入力を受け付ける入力受付部と，入
    力情報に基づいて出力先またはアクセス先を決定する条
    件を管理する条件部と，入力した要求に付与した識別番
    号を記録する要求ＩＤ記録部と，選択されたデータベー
    スへのアクセスを行うＤＢインターフェイス部と，前記
    入力受付部からの入力毎に生成され，前記条件部，前記
    要求ＩＤ記録部および前記ＤＢインターフェイス部を利
    用し，他のエージェントとの通信によりその入力に対す
    る処理を行う入力処理部とを備えたことを特徴とするデ
    ータベース・システム。
20. 【請求項２０】 ユーザとデータベースとの仲介機構
    を，１または複数のユーザ・エージェントと，１または
    複数の仲介エージェントと，アクセス対象となるデータ
    ベース対応に設けられる１または複数のデータベース・
    エージェントとによって分散的に構成したデータベース
    ・システムにおけるユーザ・エージェントを実現するプ
    ログラムを格納したプログラム記憶媒体であって，ユー
    ザからの入力を受け付ける入力受付部と，入力情報に基
    づいて出力先を決定する条件を管理する条件部と，入力
    した要求に付与した識別番号を記録する要求ＩＤ記録部
    と，入力情報から選択されたデータベース群を記録する
    ＤＢ群記録部と，前記入力受付部からの入力毎に生成さ
    れ，前記条件部，前記要求ＩＤ記録部および前記ＤＢ群
    記録部を利用し，他のエージェントとの通信によりその
    入力に対する処理を行う入力処理部として，計算機を機
    能させるためのプログラムを格納したことを特徴とする
    プログラム記憶媒体。
21. 【請求項２１】 ユーザとデータベースとの仲介機構
    を，１または複数のユーザ・エージェントと，１または
    複数の仲介エージェントと，アクセス対象となるデータ
    ベース対応に設けられる１または複数のデータベース・
    エージェントとによって分散的に構成したデータベース
    ・システムにおける仲介エージェントを実現するプログ
    ラムを格納したプログラム記憶媒体であって，他のエー
    ジェントからの入力を受け付ける入力受付部と，入力情
    報に基づいて出力先を決定する条件を管理する条件部
    と，入力した要求に付与した識別番号を記録する要求Ｉ
    Ｄ記録部と，前記入力受付部からの入力毎に生成され，
    前記条件部および前記要求ＩＤ記録部を利用し，他のエ
    ージェントとの通信によりその入力に対する処理を行う
    入力処理部として，計算機を機能させるためのプログラ
    ムを格納したことを特徴とするプログラム記憶媒体。
22. 【請求項２２】 ユーザとデータベースとの仲介機構
    を，１または複数のユーザ・エージェントと，１または
    複数の仲介エージェントと，アクセス対象となるデータ
    ベース対応に設けられる１または複数のデータベース・
    エージェントとによって分散的に構成したデータベース
    ・システムにおけるデータベース・エージェントを実現
    するプログラムを格納したプログラム記憶媒体であっ
    て，他のエージェントからの入力を受け付ける入力受付
    部と，入力情報に基づいて出力先またはアクセス先を決
    定する条件を管理する条件部と，入力した要求に付与し
    た識別番号を記録する要求ＩＤ記録部と，選択されたデ
    ータベースへのアクセスを行うＤＢインターフェイス部
    と，前記入力受付部からの入力毎に生成され，前記条件
    部，前記要求ＩＤ記録部および前記ＤＢインターフェイ
    ス部を利用し，他のエージェントとの通信によりその入
    力に対する処理を行う入力処理部として，計算機を機能
    させるためのプログラムを格納したことを特徴とするプ
    ログラム記憶媒体。