JP3277654B2 - 異種データベース・アクセス・システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、データベースをアクセ
スするための情報処理システムおよびその制御方法に係
り、特に、クライアントの情報処理装置からネットワー
クを介して複数の異種データベース・サーバーをアクセ
スする場合に好適な、異種データベース・アクセス・シ
ステム、及びその制御方法に関する。

【０００２】

【従来の技術】企業におけるデータベース・システム
は、ダウンサイジング化に伴い、メインフレームを用い
た全社システムから、各業務を担当する部門に分散され
た部門システムへと移行が進んでいる。部門システムで
は、業務内容に応じた最適なシステムを構築するため、
各部門毎に異なるベンダのデータベース管理システム
(ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔ
ｅｍ： ＤＢＭＳ)を採用することも珍しくない。一
方、意志決定支援などのアプリケーション・ソフトウェ
アにおいては、企業内の各部門に分散したデータベース
上の種々のデータを必要に応じて収集し分析する必要が
ある。

【０００３】データベースのアクセスに用いるアプリケ
ーション プログラム インタフェース(ＡＰＩ) とし
ては、ストラクチャード クイアリ ランゲージ Ｓｔ
ｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ(Ｓ
ＱＬ)が一般に用いられている。ＳＱＬは、ＪＩＳ規格
などで標準仕様が定められているが、実際のＤＢＭＳの
製品では細かな点でＤＢＭＳベンダ毎にその仕様が異な
っている。このため、同一のＳＱＬで異なるベンダのＤ
ＢＭＳ上のデータベースにアクセスすることはできな
い。そこで、一種類のＳＱＬを各ベンダ固有のＳＱＬに
変換するゲートウェイが製品化されている。なお、ＳＱ
Ｌの仕様の相違点については、Ａｄｄｉｓｏｎ-Ｗｅｓ
ｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏｍｐａｎｙ、Ｉｎ
ｃ発行の「ＴＨＥ ＰＲＡＣＴＩＣＡＬ ＳＱＬ ＨＡ
ＮＤＢＯＯＫ」ｐｐ.３２９〜３４１にて開示されてい
る。

【０００４】図２は、ゲートウェイを用いた異種データ
ベース・アクセス・システムの一従来例である。この従
来例では、アプリケーション・ソフトウェア１１１が動
作するクライアント情報処理装置１１０にゲートウェイ
機能を搭載している。１２０ａ、１２０ｂは、それぞれ
ＤＢＭＳ＿Ａ １２１ａ、ＤＢＭＳ＿Ｂ １２１ｂが動
作するサーバ情報処理装置であり、クライアント情報処
理装置１１０とＬＡＮ(Ｌｏｃａｌ Ａｒｅａ Ｎｅｔ
ｗｏｒｋ)１００で接続されている。ＤＢＭＳ＿Ａ、Ｄ
ＢＭＳ＿Ｂによって管理されているデータベースのデー
タは、外部記憶装置１２４ａ、１２４ｂにそれぞれ格納
されている。アクセス管理コンポーネント１１２は、ア
クセス先がＤＢＭＳ＿Ａの時はアプリケーション・ソフ
トウェア１１１がデータベース・アクセスのため発行す
るＳＱＬ文をＳＱＬ変換＿Ａとし、アクセス先がＤＢＭ
Ｓ＿Ｂの時はＳＱＬ変換＿Ｂの各コンポーネントに引き
渡すように動作する。ＳＱＬ変換＿Ａ、ＳＱＬ変換＿Ｂ
の各コンポーネントは、受け取ったＳＱＬ文をターゲッ
トＤＢＭＳの仕様に変換し、各ＤＢＭＳ用のデータベー
ス・ドライバＡ １２２ａ、データベース・ドライバＢ
１２２ｂおよびＬＡＮドライバ１２３、ＬＡＮ１００
を介して、各ターゲットのサーバ情報処理装置１２０ａ
または１２０ｂに変換を行ったＳＱＬ文を送信する。ク
ライアント情報処理装置１１０のデータベース・ドライ
バＡ、データベース・ドライバＢおよびＬＡＮドライバ
１２３と同じものが各サーバ情報処理装置１２０ａ、１
２０ｂにも搭載されており、通信プロトコルの階層に従
った処理を行い、クライアント情報処理装置１１０が送
信したＬＡＮ１００上のパケットデータからＤＢＭＳ＿
ＡまたはＤＢＭＳ＿Ｂ宛のＳＱＬ文を取り出し、各ＤＢ
ＭＳにＳＱＬ文を送る。各ＤＢＭＳでの処理結果は、上
述の経路を逆に辿り、ＳＱＬ変換＿ＡまたはＳＱＬ変換
＿Ｂによって、標準のデータ形式、および標準のリター
ン・コードに変換した後、アクセス管理コンポーネント
１１２を介してアプリケーション・ソフトウェア１１１
に送られる。このように、ゲートウェイ機能をクライア
ント情報処理装置１１０上のアクセス管理コンポーネン
ト１１２とＳＱＬ変換＿Ａコンポーネント１１５ａ、Ｓ
ＱＬ変換＿Ｂコンポーネント１１５ｂによって実現する
ことにより、単一のＳＱＬ仕様だけを用いて、異なるＳ
ＱＬ仕様を持つＤＢＭＳにアクセスすることが可能とな
っている。

【０００５】これらのゲートウェイ機能をクライアント
情報処理装置１１０上ではなく、専用のゲートウェイ情
報処理装置１３０を用いて実現した従来例を図３に示
す。この従来例では、アプリケーション・ソフトウェア
１１１が発行したＳＱＬ文は、まず、データベース・ド
ライバＣ １２２ｃ、ＬＡＮドライバ１２３、ＬＡＮ１
００を介してゲートウェイ情報処理装置１３０に送られ
る。ゲートウェイ情報処理装置１３０上では、ＬＡＮド
ライバ、データベース・ドライバＣによってＳＱＬ文が
取り出され、アクセス管理コンポーネント１１２に送ら
れる。この後の動作は、図２で説明した従来例と同様で
あり、ＳＱＬ変換＿Ａ、ＳＱＬ変換＿Ｂ、データベース
・ドライバＡ、データベース・ドライバＢ、ＬＡＮドラ
イバ１２３を介してターゲットのサーバ情報処理装置１
２０ａまたは１２０ｂ上のデータベースをアクセスし、
結果がクライアント情報処理装置１１０上のアプリケー
ション・ソフトウェア１１１に返される。

【０００６】これらの異種データベース・アクセス・シ
ステムについては、日経エレクトロニクス １９９３年
２月１５日号ｐｐ.１３８〜ｐｐ.１４５に述べられてい
る。

【０００７】

【発明が解決しようとする課題】以上述べたように、タ
ーゲットＤＢＭＳのＳＱＬの仕様へＳＱＬ文の変換を行
うゲートウェイ機能をクライアント情報処理装置上に搭
載する、あるいは前記ゲートウェイ機能を実現するゲー
トウェイ情報処理装置を設けることによって、アプリケ
ーション・ソフトウェアは単一のＳＱＬ仕様だけを用い
て、異なるＳＱＬ仕様を持つ複数のＤＢＭＳで管理され
たデータベースをアクセスすることが可能となってい
る。

【０００８】しかし、図２で示した従来の構成では、ア
クセスするＤＢＭＳに対応したＳＱＬ変換コンポーネン
トおよびデータベース・ドライバを、すべてのクライア
ントが具備する必要がある。このため、システム内のＤ
ＢＭＳの種類の追加やバージョンアップ毎に、各クライ
アントのＳＱＬ変換コンポーネントおよびデータベース
・ドライバをメンテナンスする必要があり、保守性のよ
いものではなかった。

【０００９】図３で示した従来の構成では、ゲートウェ
イ情報処理装置上のＳＱＬ変換コンポーネント、データ
ベース・ドライバだけをメンテナンスすればよいので、
上記の課題は解決される。しかし、常にゲートウェイ情
報処理装置を介してデータベースをアクセスするので、
ゲートウェイ情報処理装置に負荷が集中し、ＬＡＮ上の
トラフィックが増加するため、該アクセスの性能がゲー
トウェイ情報処理装置を介さない場合に比べて低下する
という課題があった。

【００１０】また、従来のゲートウェイ情報処理装置を
用いた方式では、それぞれ仕様の異なるＳＱＬを発行す
る複数のクライアントから、それぞれ仕様の異なる複数
のＤＢＭＳにアクセスすることができないという課題が
あった。

【００１１】本発明の目的は、複数のゲートウェイ情報
処理装置に負荷を分散可能な異種データベース・アクセ
ス・システム及びその制御方法を提供することにある。

【００１２】また、本発明の他の目的は、ゲートウェイ
情報処理装置を経由することのオーバーヘッドを低減可
能な異種データベース・アクセス・システムを提供する
ことにある。

【００１３】さらに本発明の他の目的は、非標準仕様の
ＳＱＬを用いたアプリケーション・ソフトウェアから非
標準仕様のＳＱＬを用いたＤＢＭＳにアクセスすること
が可能な異種データベース・アクセス・システムを提供
することにある。

【００１４】

【課題を解決するための手段】上記目的は、ＲＰＣを用
いた標準仕様のＳＱＬアクセスを受け付け、前記標準仕
様のＳＱＬをターゲットＤＢＭＳが用いる非標準仕様の
ＳＱＬに変換し、該ＤＢＭＳへのアクセスを実行するＳ
ＱＬ変換手段と、ＲＰＣを用いた標準仕様のＳＱＬアク
セスを受け付け、ターゲットのＤＢＭＳの種類を決定
し、該ターゲットＤＢＭＳに対応した前記ＳＱＬ変換手
段をＲＰＣを用いてアクセスするアクセス管理手段とを
設けることによって達成される。

【００１５】また、上記他の目的は、ＲＰＣを用いた標
準仕様のＳＱＬアクセスを受け付け、ターゲットのＤＢ
ＭＳの種類を決定するアクセス管理手段と該アクセス管
理手段を搭載したゲートウェイ情報処理装置と、ＤＢＭ
Ｓを搭載した情報処理装置上で動作し、ＲＰＣを用いた
標準仕様のＳＱＬアクセスを受け付け、標準仕様のＳＱ
ＬをＤＢＭＳが用いる非標準仕様のＳＱＬに変換し、Ｄ
ＢＭＳへのアクセスを実行するＳＱＬ変換手段と、ユー
ザー・アプリケーション・ソフトウェアが搭載された情
報処理装置上で動作し、ユーザー・アプリケーション・
ソフトウェアから発行されるＳＱＬを、ＲＰＣを用いて
他の情報処理装置に実行依頼するクライアントＳＱＬ処
理手段とを設けることによって達成される。

【００１６】さらに上記他の目的は、ＲＰＣを用いた非
標準仕様のＳＱＬアクセスを受け付け、非標準仕様のＳ
ＱＬを標準仕様のＳＱＬに変換する非標準ＳＱＬ変換手
段と、ＲＰＣを用いた標準仕様のＳＱＬアクセスを受け
付け、ターゲットのＤＢＭＳの種類を決定するアクセス
管理手段と、ＲＰＣを用いた標準仕様のＳＱＬアクセス
を受け付け、標準仕様のＳＱＬをターゲットＤＢＭＳが
用いる非標準仕様のＳＱＬに変換し、ＤＢＭＳへのアク
セスを実行するＳＱＬ変換手段と、前記アクセス管理手
段とＳＱＬ変換手段を搭載した複数のゲートウェイ情報
処理装置手段とを設けることによって達成される。

【００１７】

【作用】アクセス管理手段は、標準仕様のＳＱＬをＲＰ
Ｃのパラメータとしたアクセスを受け付け、ターゲット
のＤＢＭＳの種類を決定し、ＤＢＭＳの種類に対応した
ＳＱＬ変換手段に標準仕様のＳＱＬをパラメータとした
ＲＰＣを発行する。ＳＱＬ変換手段は、アクセス管理手
段から発行されたＲＰＣによって引き渡された標準仕様
のＳＱＬを、ターゲットＤＢＭＳが用いる非標準仕様の
ＳＱＬに変換し、ＤＢＭＳへのアクセスを実行する。こ
のように、アクセス管理手段とＳＱＬ変換手段との接続
をＲＰＣを用いて行い、しかもアクセス管理手段への処
理依頼と、ＳＱＬ変換手段への処理依頼の各ＲＰＣのパ
ラメータ仕様を同一とする事によって、ターゲットＤＢ
ＭＳが明確でしかも単一の場合には、ユーザー・アプリ
ケーション・ソフトウェアから、アクセス管理手段を介
すること無く直接ＳＱＬ変換手段へアクセスすることが
できるので、オーバーヘッドを低減することができる。

【００１８】また、アクセス管理手段とＳＱＬ変換手段
は、複数の情報処理装置上に置くことができ、第一の情
報処理装置上のアクセス管理手段から他の情報処理装置
上のＳＱＬ変換手段へＲＰＣによる処理依頼を行うこと
もできる。これによって、処理負荷を複数の情報処理装
置に分散できる。

【００１９】また、アクセス管理手段が搭載されたすべ
ての情報処理装置上にすべての種類のＤＢＭＳに対応し
たＳＱＬ変換手段を搭載しなくてもよく、どれかの情報
処理装置上に必要な種類のＳＱＬ変換手段を用意して置
けばよいので、導入、保守が容易となる。

【００２０】また、ユーザー・アプリケーション・ソフ
トウェアが搭載された情報処理装置上で動作し、ユーザ
ー・アプリケーション・ソフトウェアから発行されるＳ
ＱＬをＲＰＣを用いて他の情報処理装置に実行依頼する
クライアントＳＱＬ処理手段は、ユーザー・アプリケー
ション・ソフトウェアから発行されるＳＱＬをパラメー
タとするＲＰＣを、単一のＤＢＭＳに対するものである
ときはターゲットＤＢＭＳと同一情報処理装置上のＳＱ
Ｌ変換手段に発行し、単一のＤＢＭＳに対するものでな
いときはターゲットＤＢＭＳとは別のゲートウェイ情報
処理装置上のアクセス管理手段に発行するように動作す
る。これによって、単一のＤＢＭＳに対してのアクセス
は、ゲートウェイ情報処理装置を介することによるオー
バーヘッドを生じることなく実行することができる。

【００２１】さらに、非標準ＳＱＬ変換手段は、非標準
ＳＱＬを用いたユーザー・アプリケーション・ソフトウ
ェアからのアクセスを、アクセス管理手段が処理できる
標準仕様のＳＱＬに変換する。これによって、非標準Ｓ
ＱＬを用いたユーザー・アプリケーション・ソフトウェ
アから、別の非標準ＳＱＬを用いたＤＢＭＳへアクセス
できる。

【００２２】

【実施例】以下、本発明の第１の実施例を図１、図４お
よび図５を用いて説明する。

【００２３】図１は、本実施例における異種データベー
ス・アクセス・システムの一構成例である。１１０は、
アプリケーション・ソフトウェア１１１が動作するクラ
イアント情報処理装置、１３０はゲートウェイ情報処理
装置、１２０ａ、１２０ｂは、それぞれＤＢＭＳ＿Ａ、
ＤＢＭＳ＿Ｂが動作するサーバ情報処理装置、１５０は
ＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌ
ｌ）で呼び出す各サーバ・コンポーネントのネットワー
ク上の物理位置との対応情報を提供するネームサーバ１
５１が動作するネームサーバ情報処理装置である。前記
各情報処理装置はＬＡＮ１００で接続されている。ＤＢ
ＭＳ＿Ａ、ＤＢＭＳ＿Ｂによって管理されているデータ
ベースのデータは、従来例と同様に外部記憶装置に格納
されるが、図１では該外部記憶装置を省略している。
（以下の実施例についても同様に省略する。） クライアント情報処理装置からサーバ情報処理装置への
アクセスは、アプリケーション・ソフトウェア１１１か
らのデータベース・アクセスは、ＳＱＬ文に対応したＲ
ＰＣを実行することによって行う。本実施例では、アプ
リケーション・ソフトウェア１１１が使用するＳＱＬ仕
様は、本システムでの標準仕様とし、各ＤＢＭＳ＿Ａ、
ＤＢＭＳ＿ＢのＳＱＬ仕様は、標準仕様とは異なるもの
とする。このＲＰＣを以下ＳＱＬ＿ＲＰＣと呼ぶ。クラ
イアント情報処理装置１１０上のＲＰＣドライバ１０２
は、まずネームサーバ情報処理装置１５０上のネームサ
ーバ１５１に、ＳＱＬ＿ＲＰＣを処理するサーバのネッ
トワーク・アドレスとサーバ・コンポーネントへの接続
のためのポート番号を問い合わせる。ＳＱＬ＿ＲＰＣを
処理するサーバは、ゲートウェイ情報処理装置１３０上
のアクセス管理コンポーネント１１２ｖであるので、前
記問い合わせに対して、ネームサーバ１５１はゲートウ
ェイ情報処理装置１３０のネットワーク・アドレス情報
とアクセス管理コンポーネント１１２ｖのポート番号を
返すように動作する。このアドレス情報とポート番号を
もとに、クライアント情報処理装置１１０上のＲＰＣド
ライバ１０２は、ゲートウェイ情報処理装置１３０上の
アクセス管理コンポーネント１１２ｖとＲＰＣの接続を
行い、ＳＱＬ＿ＲＰＣの処理をアクセス管理コンポーネ
ント１１２ｖへ依頼する。アクセス管理コンポーネント
１１２ｖは、ＳＱＬ＿ＲＰＣのパラメータに含まれるタ
ーゲットＤＢＭＳの名称から、使用すべきＳＱＬ変換コ
ンポーネントをネームサーバ１５１に問い合わせる。本
実施例では、ＳＱＬ変換＿Ａコンポーネント１１５ａま
たは、ＳＱＬ変換＿Ｂコンポーネント１１５ｂのネット
ワーク・アドレス情報とポート番号が返される。アクセ
ス管理コンポーネント１１２ｖは、ネームサーバ１５１
から返された情報をもとに、何れかのＳＱＬ変換コンポ
ーネントにＳＱＬ文の変換と、ターゲットＤＢＭＳへの
アクセス処理をＲＰＣを用いて依頼する。

【００２４】ＳＱＬ変換＿Ａコンポーネント１１５ａま
たはＳＱＬ変換＿Ｂコンポーネント１１５ｂが行った各
ＤＢＭＳへのアクセス結果は、上述の経路を逆に辿り、
ＳＱＬ変換＿ＡコンポーネントまたはＳＱＬ変換＿Ｂコ
ンポーネントによって、標準のデータ形式、および標準
のリターン・コードに変換した後、アクセス管理コンポ
ーネントを介してアプリケーション・ソフトウェア１１
１に送られる。

【００２５】図４は、ＳＱＬ＿ＲＰＣの処理を示すフロ
ーチャートである。まず、ステップ４５０で、ネームサ
ーバ情報処理装置１５０上のネームサーバ１５１に、Ｓ
ＱＬ＿ＲＰＣを処理するサーバの物理位置すなわちネッ
トワーク・アドレスとサーバ・コンポーネントのポート
番号を問い合わせる。ネットワーク・アドレスとサーバ
・コンポーネントのポート番号をもとに、ステップ４５
１でクライアント情報処理装置１１０上のＲＰＣドライ
バは、ゲートウェイ情報処理装置１３０上のアクセス管
理コンポーネント１１２ｖとＲＰＣ接続を行い、ＳＱＬ
＿ＲＰＣの処理をアクセス管理コンポーネントへ依頼す
る。ステップ４０１以下は、アクセス管理コンポーネン
ト１１２ｖでの処理内容である。ステップ４０１では、
ＲＰＣのパラメータとして送られてきたＳＱＬ文を解析
し、アクセス先のテーブルが含まれるＤＢＭＳの名称を
得る。本実施例におけるアクセス管理コンポーネント１
１２ｖは、単一のＤＢＭＳ上のテーブルに対する操作だ
けでなく、複数のＤＢＭＳ上に跨る複数のテーブルに対
するデータの結合などの操作を行えるようするため、ス
テップ４０２、４０３、４０４では、アクセス先がＤＢ
ＭＳ＿ＡとＤＢＭＳ＿Ｂの両方か、ＤＢＭＳ＿Ａだけ
か、ＤＢＭＳ＿Ｂだけかをそれぞれ判断する。アクセス
先がＤＢＭＳ＿ＡとＤＢＭＳ＿Ｂの両方の場合はステッ
プ４０６で、ＳＱＬ文をＤＢＭＳ＿Ａに対するアクセス
と、ＤＢＭＳ＿Ｂに対するアクセスに分割したＳＱＬ文
を作成する。そして、ステップ４０７ではＤＢＭＳ＿Ａ
に対して、ステップ４０８ではＤＢＭＳ＿Ｂに対するＳ
ＱＬ文をパラメータとしたＲＰＣ（それぞれＳＱＬ＿Ａ
＿ＲＰＣ、ＳＱＬ＿Ｂ＿ＲＰＣと呼ぶ）を実行し、その
結果を得る。ステップ４０９では、ステップ４０７、４
０８で得た結果をマージし、分割前のＳＱＬ文に対応す
る結果を作成し、ステップ４１２でＳＱＬ＿ＲＰＣを完
了する。アクセス先がＤＢＭＳ＿ＡあるいはＤＢＭＳ＿
Ｂだけであった場合は、ステップ４１０、４１１でそれ
ぞれＳＱＬ文をパラメータとしたＲＰＣ（ＳＱＬ＿Ａ＿
ＲＰＣまたはＳＱＬ＿Ｂ＿ＲＰＣ）を発行し、アクセス
結果を得、ステップ４１２でＳＱＬ＿ＲＰＣを完了す
る。なお、アクセス先がＤＢＭＳ＿ＡでもＤＢＭＳ＿Ｂ
でもない場合は、ステップ４０５でエラーコードをセッ
トし、ＳＱＬ＿ＲＰＣを終了する。

【００２６】図５は、ＳＱＬ＿Ａ＿ＲＰＣおよびＳＱＬ
＿Ｂ＿ＲＰＣの処理を示すフローチャートである。

【００２７】以下、ＳＱＬ＿Ａ＿ＲＰＣとＳＱＬ＿Ｂ＿
ＲＰＣを合わせてＳＱＬ＿ｘ＿ＲＰＣと呼ぶ。ＳＱＬ＿
ｘ＿ＲＰＣが呼ばれると、まず、ステップ５０１でＲＰ
Ｃドライバ１０２がＳＱＬ＿ｘ＿ＲＰＣを処理するサー
バ・コンポーネント（本実施例ではＳＱＬ変換コンポー
ネント）のネットワーク・アドレス情報とポート番号
を、ネームサーバ１５１に問い合わせることによって取
得する。次にステップ５０２では、問合わせたネットワ
ーク・アドレス情報とポート番号によって得たＳＱＬ変
換コンポーネントに対し、ＳＱＬ＿ｘ＿ＲＰＣを引き渡
し、その処理を依頼する。ステップ５０３、５０４、５
０５はＳＱＬ変換コンポーネントでの処理である。ステ
ップ５０３ではＲＰＣのパラメータとして受け取った標
準仕様のＳＱＬ文をターゲットＤＢＭＳのＳＱＬ仕様に
変換する。次に変換によって作成したＳＱＬ文をステッ
プ５０４でターゲットＤＢＭＳに送り、ターゲットＤＢ
ＭＳでのＳＱＬ文の実行結果を得る。さらにステップ５
０５で実行結果として得たデータおよびリターンコード
を、ターゲットＤＢＭＳのＳＱＬ仕様から標準のＳＱＬ
仕様に変換する。変換結果をリターンデータ、リターン
コードとしてステップ５０６でＳＱＬ＿ｘ＿ＲＰＣを終
了する。

【００２８】このように、アクセス管理コンポーネント
１１２ｖ、ＳＱＬ変換＿Ａコンポーネント１１５ａ、Ｓ
ＱＬ変換＿Ｂコンポーネント１１５ｂを具備することに
よって、アプリケーション・ソフトウェア１１１から
は、仕様の異なる複数のＤＢＭＳ上のテーブルを、その
仕様の違いを意識すること無く単一の標準仕様のＳＱＬ
文を用いてアクセスすることができる。

【００２９】図１０は、本実施例におけるゲートウェイ
情報処理装置１３０内のプログラムの動作の一例を示す
図である。ここでは、クライアント情報処理装置を２台
接続し、クライアント情報処理装置１１０ａからはサー
バ情報処理装置１２０ａ上のＤＢＭＳ＿Ａとサーバ情報
処理装置１２０ｂ上のＤＢＭＳ＿Ｂを、クライアント情
報処理装置１１０ｂからはサーバ情報処理装置１２０ｂ
上のＤＢＭＳ＿Ｂをアクセスする場合を示す。アクセス
管理コンポーネント１１２ｖは、クライアント情報処理
装置との接続単位にプロセスが生成される。ＳＱＬ変換
＿Ａ １１５ａ、ＳＱＬ変換＿Ｂ １１５ｂについて
も、アクセス管理コンポーネントの各プロセスからのア
クセス要求がＲＰＣを用いて発行される毎にプロセスが
生成される。また、データベース・ドライバＡ、データ
ベース・ドライバＢは、それぞれＳＱＬ変換＿Ａ、ＳＱ
Ｌ変換＿Ｂの各１プロセスに対して１プロセスが生成さ
れるように動作する。これらのプロセスは、アクセスの
終了と共に消滅する。このようなプロセス生成・消滅を
ゲートウェイ情報処理装置１３０で行うことによって、
複数のクライアント情報処理装置から複数のサーバ情報
処理装置へのアクセスを同時に処理することができる。

【００３０】図１８は、第一の実施例を用いたシステム
の他の構成例である。６００ａは、ＤＢＭＳ＿Ａを用い
たサーバ情報処理装置１２１ａとＤＢＭＳ＿Ａ専用のデ
ータベースドライバＡ、アプリケーション・ソフトウェ
アＡが搭載されたクライアント情報処理装置１１０ａか
ら構成される既存のシステム。６００ｂは、ＤＢＭＳ＿
Ｂを用いたサーバ情報処理装置１２１ｂと前記ＤＢＭＳ
＿Ｂ専用のデータベースドライバＢ、アプリケーション
・ソフトウェアＢが搭載されたクライアント情報処理装
置１１０ｂから構成される既存のシステムである。これ
らの既存のシステムに、上述のゲートウェイ情報処理装
置１３０、ネームサーバ情報処理装置１５０、クライア
ント情報処理装置１１０からなる付加システム５００を
付加することによって、既存のシステム６００ａ、６０
０ｂの構成を何等変更することなく、追加したクライア
ント情報処理装置１１０から単一の標準仕様のＳＱＬ文
を用いて、仕様の異なる二つの既存のＤＢＭＳにアクセ
スすることができる。

【００３１】ところで、本発明ではアプリケーション・
ソフトウェア１１１からアクセス管理コンポーネント１
１２ｖへのアクセスと、アクセス管理コンポーネントか
らのＳＱＬ変換コンポーネント１１５へのアクセスにＲ
ＰＣを用いている。これによって、図１に示した本発明
による異種データベース・アクセス・システムは、ゲー
トウェイ情報処理装置１３０への負荷集中によるデータ
ベース・アクセス性能の低下を、ゲートウェイ情報処理
装置１３０の追加によって容易に実現できる。以下、ゲ
ートウェイ情報処理装置１３０を追加した場合の動作を
第２の実施例として図９を用いて説明する。

【００３２】図９に示す実施例では、ＳＱＬ変換＿Ａコ
ンポーネント１１５ａを具備したゲートウェイ情報処理
装置１３０ａと、ＳＱＬ変換＿Ｂコンポーネント１１５
ｂを具備したゲートウェイ情報処理装置１３０ｂの２台
のゲートウェイ情報処理装置を用いる。クライアント情
報処理装置１１０上のＲＰＣドライバ１０２は、第一の
実施例と同様、アプリケーション・ソフトウェア１１１
が発行するＳＱＬ＿ＲＰＣを受け付けると、まず、ＳＱ
Ｌ＿ＲＰＣを処理するサーバの物理位置すなわちネット
ワーク・アドレスとポート番号をネームサーバ１５１に
問い合わせる。本実施例では、ＳＱＬ＿ＲＰＣを処理す
るサーバすなわちアクセス管理コンポーネント１１２ｖ
は、ゲートウェイ情報処理装置１３０ａと１３０ｂの両
方に搭載されており、ネームサーバからはＲＰＣドライ
バ１０２の問合わせに対して２個のアクセス管理コンポ
ーネント１１２ｖの物理位置が返答される。クライアン
ト情報処理装置１１０上のＲＰＣドライバ１０２は返答
された複数のアクセス管理コンポーネント１１２ｖの中
から処理を依頼するサーバを一つ選択する。

【００３３】本実施例では、ゲートウェイ情報処理装置
１３０ａ上のアクセス管理コンポーネント１１２ｖが選
択された場合について以下説明する。

【００３４】アプリケーション・ソフトウェア１１１か
ら発行されるＳＱＬ＿ＲＰＣは、まず、ゲートウェイ情
報処理装置１３０ａ上のアクセス管理コンポーネント１
１２ｖに送られる。アクセス管理コンポーネントは、す
でに図４を用いて説明したように、ターゲットのＤＢＭ
Ｓに応じてＳＱＬ＿Ａ＿ＲＰＣまたはＳＱＬ＿Ｂ＿ＲＰ
Ｃを発行する。図９で示したシステムでは、ＳＱＬ＿Ｂ
＿ＲＰＣを処理するＳＱＬ変換＿Ｂコンポーネント１１
５ｂは、アクセス管理コンポーネント１１２ａが存在す
るゲートウェイ情報処理装置１３０ａとは別のゲートウ
ェイ情報処理装置１３０ｂに存在する。従って、ＳＱＬ
＿Ｂ＿ＲＰＣは、ＬＡＮ１００を経由してゲートウェイ
情報処理装置１３０ｂ上のＳＱＬ変換＿Ｂコンポーネン
ト１１５ｂで実行される。

【００３５】このように、本発明では、ＳＱＬ変換コン
ポーネント１１５へのアクセスをＲＰＣを用いて行い、
ゲートウェイ情報処理装置１３０上のＲＰＣドライバ１
０２が、処理を依頼するＳＱＬ変換コンポーネント１１
５の選択を行うので、ＳＱＬ変換コンポーネント１１５
が複数のゲートウェイ情報処理装置１３０上に分散して
いても、アプリケーション・ソフトウェア１１１がその
位置を意識することなくアクセスすることができる。し
たがって、システム内に存在する種々のＤＢＭＳに対応
したＳＱＬ変換コンポーネント１１５は、システム内の
どれかのゲートウェイ情報処理装置１３０にあればよ
く、すべてのＳＱＬ変換コンポーネント１１５を各ゲー
トウェイ情報処理装置１３０が持つ必要はない。これに
よって、各ゲートウェイ情報処理装置１３０への負荷集
中の回避、ＳＱＬ変換コンポーネント１１５の導入やメ
ンテナンス工数の低減を図ることができる。

【００３６】上述のネームサーバ１５１が、サーバ・コ
ンポーネントのネットワーク・アドレスとポート番号を
返答するためにネームサーバ情報処理装置１５０内に持
つサーバ情報テーブル１７００の一例を図１７に示す。

【００３７】ここでは、１７０１の列にサーバ・コンポ
ーネントの名称、１０７２の列にそのネットワーク・ア
ドレス、１７０３の列にポート番号が格納されている。
なお、１７０４の列には、各コンポーネントのステータ
スが格納してあり、動作中のサーバは”ＲＵＮ”、停止
中のサーバは”ＳＴＯＰ”、故障中のサーバは”ＦＡＵ
ＬＴ”となっている。

【００３８】クライアント情報処理装置１１０上のＲＰ
Ｃドライバ１０２はアクセス管理コンポーネント１１２
ｖの選択は、ゲートウェイ情報処理装置１３０ａおよび
１３０ｂ上のＲＰＣドライバはＳＱＬ変換＿ＡまたはＳ
ＱＬ変換＿Ｂをそれぞれ選択するように実行するが、ネ
ームサーバ１５１への問い合わせの結果、複数の候補が
ネームサーバ１５１から返答されたときの選択方法の例
について以下に示す。

【００３９】第一の選択方法は、複数の候補からランダ
ムに選択する方法である。図１２に示すように、候補の
数が２以上のときは乱数を発生させ（ステップ１２０
２）、発生された乱数を候補の数Ｎで割りその剰余を求
め（１２０３）、剰余＋１番目の候補をサーバコンポー
ネントとして選択（１２０４）すればよい。

【００４０】第二の選択方法は、予め登録した優先順位
を用いる方法である。これは、サーバコンポーネントの
優先順位を例えば図１３に示すようなテーブル形式で、
ファイルなどに予め格納しておき、ネームサーバ１５１
から返答された複数の候補の内、優先順位の高いサーバ
・コンポーネントを選択すればよい。ここで１３０１の
列は優先順位、１３０２の列はサーバ名称である。この
方法では、ＲＰＣを発行するコンポーネントと同じ情報
処理装置上にサーバコンポーネントが存在する場合は、
そのサーバ・コンポーネントを高い優先順位に設定する
ことができ、ネットワークを経由することによるオーバ
ーヘッドを抑えることができる。

【００４１】第三の方法は、各ゲートウェイサーバ情報
処理装置１３０の負荷の状態によって、選択する方法で
ある。この方法では、各ゲートウェイ・サーバのオペレ
ーティング・システム（ＯＳ）が提供するＣＰＵや外部
記憶装置などの負荷状態を、問い合わせに対して返答す
る手段をサーバ・コンポーネントに設ける。この方法で
の選択フローを図１４に示す。ステップ１４０１では、
サーバ・コンポーネント候補の数Ｎ、カウンタ用変数
ｃ、最小負荷サーバ・ナンバー記憶変数ｎ、最小負荷記
憶変数ＬＭＩＮを初期化する。ステップ１４０２では、
サーバ・コンポーネント候補が複数かどうかを調べ、１
個だけなら負荷を調べる必要がないのでステップ１４１
０に制御を移す。サーバ・コンポーネント候補が複数の
場合には、ステップ１４０３でｃ番目の候補のサーバ・
コンポーネントに負荷情報を問い合わせ、ステップ１４
０４でサーバ・コンポーネントから返された負荷状態を
示す数値を変数Ｌに格納する。次にステップ１４０５
で、それまでに調べた他のサーバの負荷の最小値ＬＭＩ
Ｎとｃ番目の候補のサーバ・コンポーネントに負荷情報
である変数Ｌとを比較し、変数Ｌの方が小さければステ
ップ１４０６でＬＭＩＮにＬの値を格納し、ステップ１
４０７で最小負荷サーバ・ナンバーｎに上記調査を行っ
たサーバ・コンポーネントの候補番号すなわちｃの値を
格納する。ステップ１４０８では、カウンタ用変数ｃを
インクリメントし、ステップ１４０９で最後の候補まで
負荷の調査が終わったかどうかを調べ、まだの場合には
ステップ１４０３以下を繰り返すように動作する。この
ようにして、最小の負荷であったサーバ・コンポーネン
トの候補番号がｎに格納されるので、ステップ１４１０
で候補番号で示されるサーバ・コンポーネントを選択し
処理を終了する。この方法によれば、負荷の小さな情報
処理装置上のサーバ・コンポーネントを選択できるの
で、負荷が一台の情報処理装置に集中することを回避で
き、高速に処理を実行できる。

【００４２】第四の選択方法は、各ゲートウェイサーバ
情報処理装置１３０からの応答時間をもとに選択する方
法である。この方法での選択フローを図１５に示す。ス
テップ１５０１では、サーバ・コンポーネント候補の数
Ｎ、カウンタ用変数ｃ、最小応答時間サーバ・ナンバー
記憶変数ｎ、最小応答時間記憶変数ＲＭＩＮを初期化す
る。ステップ１５０２ではサーバ・コンポーネント候補
が複数かどうかを調べ、１個だけなら応答時間を調べる
必要がないのでステップ１５１０に制御を移す。サーバ
・コンポーネント候補が複数の場合には、ステップ１５
０３でｃ番目の候補のサーバ・コンポーネントに応答時
間計測のためのダミーのＲＰＣを発行し、ステップ１５
０４でダミーＲＰＣに対する応答時間を変数Ｒに格納す
る。次にステップ１５０５でそれまでに調べた他のサー
バ・コンポーネントの応答時間の最小値ＲＭＩＮと変数
Ｒとを比較し、変数Ｒの方が小さければステップ１５０
６でＲＭＩＮにＲの値を格納する。ステップ１５０７で
は最小応答時間サーバ・ナンバーｎに調査を行ったサー
バ・コンポーネントの候補番号すなわちｃの値を格納す
る。ステップ１５０８ではカウンタ用変数ｃをカウント
アップし、ステップ１５０９で最後の候補まで応答時間
の調査が終わったかどうかを調べ、まだの場合にはステ
ップ１５０３以下を繰り返すように動作する。このよう
にして最小の応答時間であったサーバ・コンポーネント
の候補番号がｎに格納されるので、ステップ１５１０で
候補番号で示されるサーバ・コンポーネントを選択し処
理を終了する。上述の応答時間は、サーバ・コンポーネ
ントが搭載された情報処理装置の負荷状態及び情報処理
装置までの通信経路の距離、通信経路の混み具合などを
反映したものであるので、応答時間が最小のサーバ・コ
ンポーネントを採用することによって、最適な処理を行
うことができる。

【００４３】応答時間によるサーバ・コンポーネントの
選択は、ブロードキャスト通信を使うことによって、上
記方法よりも簡単に行うこともできる。この方法での選
択フローを図１６に示す。ステップ１６０１で、処理可
能なサーバ・コンポーネントを募集するブロードキャス
トＲＰＣを発行し、ステップ１６０２で応答を待つ、最
初に応答があった時点でステップ１６０３を実行し応答
したサーバ・コンポーネントのサーバ名を取得し、この
サーバ・コンポーネントを実際に処理を依頼するサーバ
として採用する。なお、二番目以降に応答したサーバ・
コンポーネントは無視される。このブロードキャストＲ
ＰＣを用いて処理を依頼するサーバ・コンポーネントを
選択することによって、図１５で説明した応答時間を比
較する方法と同様、サーバ・コンポーネントが搭載され
た情報処理装置の負荷状態及び情報処理装置までの通信
経路の距離、通信経路の混み具合などを反映した選択が
行える。なお、このブロードキャストＲＰＣはネットワ
ークに接続されたすべてのサーバに対して発行される
が、マルチキャストＲＰＣを用いればネームサーバ１５
１から得たサーバ・コンポーネントの候補だけに発行す
ることもできる。

【００４４】さらに、応答時間による選択操作を複数回
実施し、複数回の平均応答時間が最も短かったサーバ・
コンポーネントを選ぶようにすれば、一時的なネットワ
ークの混み具合の変化などによる影響を防止し、より最
適なサーバ・コンポーネントの選択を行うことができ
る。

【００４５】また、サーバ・コンポーネントがブロード
キャストまたはマルチキャストに対する応答時間をサー
バ・コンポーネントが搭載されている情報処理装置の負
荷状況に応じて変化させることで、ブロードキャストま
たはマルチキャストによるサーバ・コンポーネントの選
択を、より最適に行うことができる。

【００４６】図２０を用いてこの方法によるサーバ・コ
ンポーネントの処理フローを以下説明する。

【００４７】まず、ステップ２００１で受信したブロー
ドキャスト・パケットがサーバ・コンポーネントの処理
対象かどうかを調べ、処理対象でなければ処理を終了す
る。処理対象であった場合には、ステップ２００２でサ
ーバ・コンポーネントが搭載されている情報処理装置の
負荷状態を調べ、ステップ２００３で負荷状態を数値化
したものを変数Ｌに代入する。ステップ２００４、２０
０５では変数Ｌを０になるまでカウントダウンし、変数
Ｌに比例した時間だけ次の処理への移行を遅延させる。
遅延時間経過後、ステップ２００６で処理可能であるこ
とを示す応答パケットを、処理を要求したクライアント
・コンポーネントに発行し、ブロードキャスト・パケッ
トの受信処理を終了する。

【００４８】これによって、上述のように最も早く応答
したサーバ・コンポーネントを選択する場合に、負荷状
態が最も軽い情報処理装置上のサーバ・コンポーネント
を選択することができる。

【００４９】以上述べた各選択方法は、単独で用いても
よいし、組み合わせて使用してもよい。また、これらの
選択手段をネームサーバ１５１に具備し、複数候補があ
る場合にはそのうちの一つを選択してもよいし、優先順
位を付けてネームサーバ１５１への問い合わせ元に返答
するようにしてもよい。

【００５０】次に、第３の実施例について図６、図７を
用いて以下説明する。

【００５１】本実施例では、第１の実施例においてゲー
トウェイ情報処理装置１３０上で動作していたＳＱＬ変
換＿Ａコンポーネント、ＳＱＬ変換＿Ｂコンポーネント
を、それぞれサーバ情報処理装置１２０ａ、１２０ｂで
動作するようにした。すでに説明したように、ＳＱＬ変
換＿Ａコンポーネント、ＳＱＬ変換＿Ｂコンポーネント
へのインタフェースはＲＰＣを用いている。これによ
り、各コンポーネントのプログラムは、第１の実施例と
同じものを用いたまま、図１の構成を図６の構成に変更
することができる。本実施例においては、各サーバ情報
処理装置１２０ａ、１２０ｂがそれぞれＳＱＬ変換＿Ａ
コンポーネント、ＳＱＬ変換＿Ｂコンポーネントを具備
するので、ゲートウェイ情報処理装置１３０を介さなく
ても単一のＳＱＬ仕様で、異なるＳＱＬ仕様を持つＤＢ
ＭＳ＿Ａ １２１ａ、ＤＢＭＳ＿Ｂ１２１ｂにアクセス
することができる。

【００５２】図７は、本実施例においてアプリケーショ
ン・ソフトウェア１１１から発行されるＳＱＬをＲＰＣ
のパラメータとしてデータベースにアクセスするＳＱＬ
＿ＡＰＩ処理プログラム７００の処理を示すフローチャ
ートである。

【００５３】このＳＱＬ＿ＡＰＩ処理プログラム７００
は、クライアント情報処理装置１１０上のＲＰＣドライ
バ１０２に含まれる。まず、ステップ７０１でＳＱＬ文
を解析し、アクセス先のＤＢＭＳ情報を得る。ステップ
７０２、７０３、７０４では、アクセス先がＤＢＭＳ＿
ＡとＤＢＭＳ＿Ｂの両方か、ＤＢＭＳ＿Ａだけか、ＤＢ
ＭＳ＿Ｂだけかをそれぞれ判断する。アクセス先がＤＢ
ＭＳ＿ＡとＤＢＭＳ＿Ｂの両方の場合はステップ７０６
で、ステップ７０１で解析、分析されたＳＱＬ文をパラ
メータとするＳＱＬ＿ＲＰＣを実行する。ＳＱＬ＿ＲＰ
Ｃは、アクセス管理コンポーネント１１２ｖで処理され
る。一方、アクセス先がＤＢＭＳ＿ＡあるいはＤＢＭＳ
＿Ｂだけであった場合は、ステップ７０７でＳＱＬ＿Ａ
＿ＲＰＣ、またはステップ７０８でＳＱＬ＿Ｂ＿ＲＰＣ
を実行し、ゲートウェイ情報処理装置１３０を介するこ
と無くＤＢＭＳ＿ＡまたはＤＢＭＳ＿Ｂをアクセスす
る。このように、ゲートウェイ情報処理装置１３０をＤ
ＢＭＳ＿Ａ、ＤＢＭＳ＿Ｂの両方のデータを同時にアク
セスするＳＱＬ文を処理する場合にのみ使用する事によ
って、ゲートウェイ情報処理装置１３０を介することに
よって生じる性能低下を低減することができる。

【００５４】次に第４の実施例を説明する。上述の実施
例では、単一の仕様のＳＱＬを用いたアプリケーション
・ソフトウェアから種々のＳＱＬ仕様のＤＢＭＳへのア
クセスを実現する例を示したが、本実施例では種々の異
なるＳＱＬ仕様を用いたアプリケーション・ソフトウェ
アからＳＱＬ仕様と同じまたは異なるＤＢＭＳへのアク
セスを実現する。

【００５５】図８に本実施例の一構成例を示す。本構成
例では、図１で示した第一の実施例に対してクライアン
ト情報処理装置１１０ｒとゲートウェイ情報処理装置１
３０上の非標準ＳＱＬ変換コンポーネント１１５ｒを追
加した。１１１ｒは、非標準のＳＱＬ仕様を用いたアプ
リケーション・ソフトウェアである。また、１１５ｒは
非標準のＳＱＬを標準のＳＱＬに変換する非標準ＳＱＬ
変換コンポーネントである。アプリケーション・ソフト
ウェア１１１ｒから発行される非標準仕様のＳＱＬ文を
含むＲＰＣ（以下ＳＱＬ＿ｒ＿ＲＰＣと呼ぶ）は、上述
の実施例と同様に、ＲＰＣドライバ１０２、ＬＡＮドラ
イバ１２３、ＬＡＮ１００を介して非標準ＳＱＬ変換コ
ンポーネント１１５ｒで処理が行われる。非標準ＳＱＬ
変換コンポーネント１１５ｒで非標準ＳＱＬから標準Ｓ
ＱＬへと変換されたＳＱＬは、アクセス管理コンポーネ
ント１１２ｖにＲＰＣで送られる。以後の処理は第一の
実施例と同様であり、ＳＱＬ変換コンポーネント１１５
でターゲットＤＢＭＳの仕様のＳＱＬに変換された後、
ＤＢＭＳをアクセスし、結果を得る。このように、非標
準ＳＱＬから標準ＳＱＬに変換するコンポーネントを設
けることによって、各種のＳＱＬ仕様を用いたアプリケ
ーション・ソフトウェア１１１ｒから、仕様の異なるＳ
ＱＬを用いたＤＢＭＳをアクセスすることができる。

【００５６】次に第５の実施例について図１１を用いて
以下説明する。本実施例ではＲＰＣを用いたクライアン
トとＲＰＣを用いないクライアントの両方を接続する。
図１１は本実施例の一構成例であり、図１で示した第一
の実施例に対してクライアント情報処理装置１１０ａを
追加した。クライアント情報処理装置１１０ａ上のアプ
リケーション・ソフトウェアＡは、ＤＢＭＳ＿Ａ １２
１ａ用のデータベース・ドライバ１２２ａ用に作成され
たものであり、非標準のＳＱＬ仕様を用い、データベー
ス・ドライバ１２２ａのＡＰＩを介してデータベース・
アクセスを行う。一方、ゲートウェイ情報処理装置１３
０上には、データベース・ドライバＡ１２２ａ経由でア
クセスする非標準ＳＱＬ変換＿ＲＡコンポーネント１１
５ｒａを第一の実施例に追加した。アプリケーション・
ソフトウェアＡ １１１ａから発行されるＤＢＭＳ＿Ａ
１２１ａの仕様、すなわち非標準仕様のＳＱＬ文は、
データベース・ドライバ１２２ａ、ＬＡＮドライバ１２
３、ＬＡＮ１００を介してゲートウェイ情報処理装置１
３０上の非標準ＳＱＬ変換＿ＲＡコンポーネントで処理
が行われる。非標準ＳＱＬ変換＿ＲＡコンポーネントで
非標準ＳＱＬから標準ＳＱＬへと変換されたＳＱＬ文
は、アクセス管理コンポーネントにＲＰＣで送られる。
以後の処理は第一の実施例と同様であり、ＳＱＬ変換コ
ンポーネントでターゲットＤＢＭＳの仕様のＳＱＬに変
換された後、ＤＢＭＳ＿ＡあるいはＤＢＭＳ＿Ｂをアク
セスし、結果を得る。このように非標準から標準に変換
するコンポーネントを第一の実施例に追加する事によっ
て、あるＤＢＭＳ固有の非標準ＳＱＬおよび非標準デー
タベース・ドライバを用いたデータベース・アクセス
を、あるＤＢＭＳ専用に構築されたクライアント情報処
理装置のプログラム構成を全く変更する事なく、ＤＢＭ
Ｓとは異なるＳＱＬ仕様、通信プロトコル仕様のＤＢＭ
Ｓをアクセスする事ができる。

【００５７】なお、本実施例ではクライアント情報処理
装置１１０ａとゲートウェイ情報処理装置１３０との接
続をデータベース・ドライバ＿Ａを用いて行ったが、こ
のドライバが上述のＲＰＣとは異なる仕様のＲＰＣを用
いていてもよい。

【００５８】図１９は、上記第５の実施例を用いたシス
テムの他の構成例である。６００ａは、ＤＢＭＳ＿Ａを
用いたサーバ情報処理装置１２１ａとＤＢＭＳ＿Ａ専用
のデータベースドライバ、アプリケーション・ソフトウ
ェアが搭載されたクライアント情報処理装置１１０ａか
ら構成される既存のシステム。６００ｂは、ＤＢＭＳ＿
Ｂを用いたサーバ情報処理装置１２１ｂとＤＢＭＳ＿Ｂ
専用のデータベースドライバ、アプリケーション・ソフ
トウェアが搭載されたクライアント情報処理装置１１０
ｂから構成される既存のシステムである。これらの既存
のシステムに、ゲートウェイ情報処理装置１３０、ネー
ムサーバ情報処理装置１５０からなる付加システム５０
０を付加することによって、既存のシステム６００ａ、
６００ｂの構成を何等変更することなくクライアント情
報処理装置１１０ａから、サーバ情報処理装置１２１ｂ
に搭載されたクライアント情報処理装置１１０ａとはＳ
ＱＬ仕様の異なるＤＢＭＳ＿Ｂをアクセスすることがで
きる。

【００５９】以上述べた実施例では、ＳＱＬ仕様の異な
る２種類のＤＢＭＳが混在した場合について説明した
が、何種類のＤＢＭＳが混在してもよいし、ＳＱＬ仕様
だけでなく、通信プロトコルが異なっていてもよい。ま
た、各情報処理装置がＬＡＮによって接続された例を示
したが、ＬＡＮでなく電話回線などのＷＡＮ(Ｗｉｄｅ
Ａｒｅａ Ｎｅｔｗｏｒｋ)による接続、あるいはＬＡ
ＮとＷＡＮを併用した接続環境にも本発明は適用でき
る。さらに、以上述べた実施例に於けるＲＰＣは、同一
の情報処理装置内のプログラム間か、別の情報処理装置
上のプログラム間かに拘らず処理の依頼と処理結果の受
取が可能なインタフェース機構であれば何を用いてもよ
い。

【００６０】

【発明の効果】以上説明したように、本発明では、ター
ゲットＤＢＭＳが明確でしかも単一の場合には、ユーザ
ー・アプリケーション・ソフトウェアから、前記アクセ
ス管理手段を介すること無く直接ＳＱＬ変換手段へアク
セスすることができるので、オーバーヘッドを低減する
ことができるという効果がある。

【００６１】また、本発明のアクセス管理手段とＳＱＬ
変換手段は、複数の情報処理装置上に置くことができ、
第一の情報処理装置上のアクセス管理手段から他の情報
処理装置上のＳＱＬ変換手段へＲＰＣによる処理依頼を
行うこともできる。これによって、処理負荷を複数の情
報処理装置に分散できるという効果がある。

【００６２】また、本発明では、アクセス管理手段が搭
載されたすべての情報処理装置上にすべての種類のＤＢ
ＭＳに対応したＳＱＬ変換手段を搭載しなくてもよく、
どれかの情報処理装置上に必要な種類のＳＱＬ変換手段
を用意して置けばよいので、導入、保守が容易であると
いう効果がある。

【００６３】さらに、本発明では、非標準ＳＱＬを用い
たユーザー・アプリケーション・ソフトウェアから、別
の非標準ＳＱＬを用いたＤＢＭＳへアクセスできるとい
う効果がある。

【図面の簡単な説明】

【図１】本発明の第一の実施例における異種データベー
ス・アクセス・システムの構成を示す図である。

【図２】従来の異種データベース・アクセス・アクセス
・システムの構成例を示す図である。

【図３】従来の異種データベース・アクセス・アクセス
・システムの他の構成例を示す図である。

【図４】本発明の第一の実施例においてクライアント情
報処理装置からアクセス管理コンポーネントに発行され
るＲＰＣの処理を示すフローチャートである。

【図５】本発明の第一の実施例においてアクセス管理コ
ンポーネントからＳＱＬ変換コンポーネントに発行され
るＲＰＣの処理を示すフローチャートである。

【図６】本発明の第三の実施例における異種データベー
ス・アクセス・システムの構成を示す図である。

【図７】本発明の第三の実施例におけるクライアントで
のＳＱＬ処理を示すフローチャートである。

【図８】本発明の第四の実施例における異種データベー
ス・アクセス・システムの構成を示す図である。

【図９】本発明の第二の実施例における異種データベー
ス・アクセス・システムの構成を示す図である。

【図１０】本発明の第一の実施例におけるゲートウェイ
情報処理装置１３０内のプログラムの動作を示す図であ
る。

【図１１】本発明の第五の実施例における異種データベ
ース・アクセス・システムの構成を示す図である。

【図１２】本発明の第二の実施例において、サーバ・コ
ンポーネントを乱数を用いて選択する場合の処理を示す
フローチャートである。

【図１３】本発明の第二の実施例において、サーバ・コ
ンポーネントを選択するために用意した優先順位テーブ
ルの内容の一例を示す図である。

【図１４】本発明の第二の実施例において、サーバ・コ
ンポーネントを負荷状態に応じて選択する場合の処理を
示すフローチャートである。

【図１５】本発明の第二の実施例において、サーバ・コ
ンポーネントを応答時間に応じて選択する場合の処理を
示すフローチャートである。

【図１６】本発明の第二の実施例において、サーバ・コ
ンポーネントをブロードキャストＲＰＣを用いて選択す
る場合の処理を示すフローチャートである。

【図１７】本発明のネームサーバが、サーバ・コンポー
ネントのネットワーク・アドレスとポート番号を返答す
るためにネームサーバ情報処理装置１５０内に持つテー
ブルの一例を示す図である。

【図１８】本発明の第一の実施例を用いたシステムの他
の構成を示す図である。

【図１９】本発明の第五の実施例における異種データベ
ース・アクセス・システムの他の構成を示す図である。

【図２０】本発明の第二の実施例において、ブロードキ
ャストによる処理依頼への応答を、サーバ・コンポーネ
ントが動作する情報処理装置の負荷状態に応じて遅延さ
せるための処理を示す処理を示すフローチャートであ
る。

【符号の説明】

１００…ＬＡＮ、１０２…ＲＰＣドライバ、１１０…ク
ライアント情報処理装置、１１１…アプリケーション・
ソフトウェア、１１２…アクセス管理コンポーネント、
１１５…ＳＱＬ変換コンポーネント、１２０…サーバ情
報処理装置、１２１…ＤＢＭＳ、１２２…データベース
ドライバ、１２３…ＬＡＮドライバ、１２４…外部記憶
装置、１３０…ゲートウェイ情報処理装置、１５０…ネ
ームサーバ情報処理装置、１５１…ネームサーバ・コン
ポーネント、１３００…サーバ優先順位テーブル、１７
００…サーバ情報テーブル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 橋本 尚 神奈川県横浜市戸塚区戸塚町5030番地株 式会社日立製作所ソフトウェア開発本部 内 (72)発明者 西山 英作 神奈川県横浜市戸塚区戸塚町5030番地株 式会社日立製作所ソフトウェア開発本部 内 (72)発明者 日野 裕介 神奈川県横浜市戸塚区戸塚町5030番地株 式会社日立製作所ソフトウェア開発本部 内 (56)参考文献 特開 平５−46450（ＪＰ，Ａ) 特開 平５−113959（ＪＰ，Ａ) 特開 平５−210643（ＪＰ，Ａ) 特開 平４−128959（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 12/00 513 G06F 15/177 G06F 17/30

Claims (8)

(57)【特許請求の範囲】
1. 【請求項１】ネットワーク上に接続された複数のデータ
   ベースをそれぞれ管理するデータベース管理システムを
   それぞれ有する第１の情報処理装置群と、前記ネットワ
   ークに接続され前記データベース管理システムに対して
   データベース・アクセス言語を用いて前記データベース
   へのアクセスを依頼する複数のユーザー・アプリケーシ
   ョン・ソフトウェアをそれぞれ有する第２の情報処理装
   置群からなるデータベース・アクセス・システムにおい
   て、前記複数のデータベースの一つに前記複数のユーザ
   ー・アプリケーション・ソフトウェアのそれぞれが問合
   せするための第１のデータベース・アクセス言語を、前
   記問合せのあったデータベース管理システムが使用する
   第２のデータベース・アクセス言語へ変換する第１のデ
   ータベース・アクセス言語変換手段と、前記ユーザー・
   アプリケーション・ソフトウェアからのデータベース・
   アクセスを受け付け、前記データベース管理システムの
   種類毎に用意した複数のアクセス言語変換手段の内の、
   前記データベース・アクセスのアクセス先データベース
   管理システムに対応した前記第２のデータベース・アク
   セス言語に変換する前記第１のデータベース・アクセス
   言語変換手段に前記データベース・アクセスを依頼する
   アクセス管理手段と、前記ユーザー・アプリケーション
   ・ソフトウェアと異なる他のユーザー・アプリケーショ
   ン・ソフトウェアからの第３のデータベース・アクセス
   言語を用いたデータベース・アクセスを受け付け、前記
   第１のデータベース・アクセス言語に変換し、前記アク
   セス管理手段に処理を依頼する第２のデータベース・ア
   クセス言語変換手段とを具備することを特徴とする異種
   データベース・アクセス・システム。
2. 【請求項２】請求項１記載の異種データベース・アクセ
   ス・システムにおいて、前記アクセス管理手段から前記
   第１のデータベース・アクセス言語変換手段への処理依
   頼にリモート・プロシージャ・コールを用いたことを特
   徴とする異種データベース・アクセス・システム。
3. 【請求項３】請求項１記載の異種データベース・アクセ
   ス・システムにおいて、前記ユーザー・アプリケーショ
   ン・ソフトウェアからのデータベース・アクセスおよび
   前記アクセス管理手段から前記第１のデータベース・ア
   クセス言語変換手段への処理依頼にリモート・プロシー
   ジャ・コールを用いたことを特徴とする異種データベー
   ス・アクセス・システム。
4. 【請求項４】請求項１記載の異種データベース・アクセ
   ス・システムにおいて、前記アクセス管理手段は、前記
   第２のデータベース・アクセス言御変換手段と、前記第
   １のデータベース・アクセス言語を用いたユーザー・ア
   プリケーション・ソフトウェアからの両方のデータベー
   ス・アクセスを受け付けることを特徴とする異種データ
   ベース・アクセス・システム。
5. 【請求項５】請求項１記載の異種データベース・アクセ
   ス・システムにおいて、前記アクセス管理手段とは異な
   る前記ネットワークに接続された情報処理装置上に前記
   第１のデータベース・アクセス言語変換手段を設けたこ
   とを特徴とする異種データベース・アクセス・システ
   ム。
6. 【請求項６】請求項１記載の異種データベース・アクセ
   ス・システムにおいて、複数の情報処理装置上に前記第
   二のデータベース・アクセス言語変換管理手段を設け、
   ユーザー・アプリケーション・ソフトウェアを搭載した
   情報処理装置上に、前記複数の第２のデータベース・ア
   クセス言語変換管理手段から一つを選択する手段を設け
   たことを特徴とする異種データベース・アクセス・シス
   テム。
7. 【請求項７】請求項１記載の異種データベース・アクセ
   ス・システムにおいて、前記第１のデータベース・アク
   セス言語変換手段を、該第１のデータベース・アクセス
   言語変換手段が対応する前記データベース管理ソフトウ
   ェアと同一の情報処理装置に搭載したことを特徴とする
   異種データベース・アクセス・システム。
8. 【請求項８】請求項１記載の異種データベース・アクセ
   ス・システムにおいて、前記第３のデータベース・アク
   セス言語と前記第２のデータベース・アクセス言語が同
   じ仕様であることを特徴とする異種データベース・アク
   セス・システム