JPH0667867A - アプリケーションプログラムのデータべースアクセス方式 - Google Patents

Abstract

(57)【要約】 【目的】複数のＤＢＭＳへ同一のアプリケーションプロ
グラムからのアクセスが共通のアクセスモジュールで可
能となるアプリケーションプログラムのデータベースア
クセス方式を提供する。 【構成】データベース管理システムの種別に依存しない
インタフェース処理を行うアプリケーションプログラム
インタフェースと、複数の各々のデータベース管理シス
テムに対してそれぞれにアクセス処理を行う各処理実行
部と、前記アプリケーションプログラムインターフェイ
スからの接続要求に基づいて、対象のデータベース管理
システムに対するアクセス処理を行う処理実行部とアプ
リケーションプログラムと間の接続を行うサーバーとを
備える。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、アプリケーションプロ
グラムのデータベースアクセス方式に関し、さらに詳し
くは、データベースを操作するデータベース管理システ
ム（以下、ＤＢＭＳと略称する）へのアクセス処理を伴
うアプリケーションプログラムを開発する場合におい
て、そのアプリケーションプログラムにおけるデータベ
ースアクセスモジュールの開発が効率よく行え、しかも
アプリケーションプログラムにおけるデータベースのア
クセス処理が能率よく行えるアプリケーションプログラ
ムのデータベースアクセス方式に関するものである。

【０００２】

【従来の技術】従来、ＤＢＭＳを操作する処理を含むア
プリケーションプログラムを開発するためには、アプリ
ケーションプログラムの開発者が各々のＤＢＭＳのベン
ダーから提供されるＤＢＭＳアクセス用の開発支援ツー
ルを利用するという形態で、ソフトウェア（アプリケー
ションプログラム）を開発している。この各々のデータ
ベース提供者であるＤＢＭＳベンダーから提供される開
発支援ツール（以下、ＤＢＭＳ用開発支援ツールと略称
する）は、その各々のＤＢＭＳベンダーのＤＢＭＳをア
クセスし、当該ＤＢＭＳベンダーから提供されるデータ
ベースを利用するソフトウェアの開発の生産性の向上を
目的としたものであり、いわゆるＤＢＭＳのアクセスモ
ジュールとして提供されている。

【０００３】しかし、各々のＤＢＭＳ用開発支援ツール
には、それぞれに固有の差異があるため、アプリケーシ
ョンプログラムの開発者が複数のＤＢＭＳベンダーのＤ
ＢＭＳのアクセス処理を含むプログラムを開発する場合
に、利用対象とするＤＢＭＳによって、その対応のＤＢ
ＭＳ用開発支援ツールに替えて、各々のＤＢＭＳ用開発
支援ツールを個別に利用したアプリケーションプログラ
ムの開発を行なわなければならない。

【０００４】このように、ＤＢＭＳを操作する処理を含
むアプリケーションプログラムを開発する場合、各々の
ＤＢＭＳによって、それぞれにその対応のＤＢＭＳ用開
発支援ツールに用いて、プログラム開発を行なわなけれ
ばならないため、ソフトウェア作成作業の生産性の向上
が図かれない。このため、プログラム開発の生産性を向
上させるため、それぞれに異なるＤＢＭＳを意識させな
いアプリケーションプログラム開発方式が提案されてい
る。例えば、特開平３−９０９３３号公報に記載されて
いる「ソフトウェアプログラム自動生成方式」では、ア
クセスするファイルの属性情報に従い、そのＤＢＭＳに
合った形のアクセス言語を自動生成する方式を提案して
いる。

【０００５】特開平３−９０９３３号公報に記載されて
いる「ソフトウェアプログラム自動生成方式」によれ
ば、データベース処理を指定する機能を有するソフトウ
ェアプログラムの開発を能率よく行うため、アクセスす
るファイルの属性情報から生成するデータベース言語の
種別を判別し、該当のデータベース言語を自動生成する
開発支援ツールが提供される。このため、このような開
発支援ツールを用いることにより、利用者は、ＤＢＭＳ
の構造，種別の相違と、これに依存するデータベース言
語の相違を意識せずに、プログラム開発を行うことがで
きる。この開発支援ツールには、対象のデータベース表
とＤＢＭＳ種別の対応テーブルが備えられており、ユー
ザが対象とするデータベースのファイル名を指示する
と、開発支援ツールがアクセスするデータベースに対応
して、データベース表からＤＢＭＳ種を判別し、そのＤ
ＢＭＳに合った形のデータベース言語によるアクセス文
を自動生成する。

【０００６】

【発明が解決しようとする課題】ところで、上述したよ
うに、従来におけるＤＢＭＳ用開発支援ツールでは、複
数の異種ＤＢＭＳがネットワーク上で接続される分散型
のデータベースシステムを構成するソフトウェア動作環
境におけるアプリケーションプログラムを開発するため
には、まず、各々のＤＢＭＳごとの開発支援ツールの利
用法を学習する必要があり、また、常に各々のＤＢＭＳ
を意識した上でのプログラム開発が必要となっている。
そのため、データベースに対する操作の処理を伴うプロ
グラム開発は、効率的に行うことはできず、ソフトウェ
ア開発の生産性が向上していないという問題がある。

【０００７】これに対して、前述の特開平３−９０９３
３号公報に記載の提案例に見られるように、各々に異な
るＤＢＭＳを意識せずにアプリケーションプログラムが
生成できる開発支援ツールの提案がなされており、この
ような開発支援ツールを用いてプログラム開発を行うこ
とにより、ある程度に、ソフトウェアの生産性を向上さ
せたプログラム開発も可能となっている。

【０００８】しかしながら、このような開発支援ツール
を用い、個々のＤＢＭＳの特徴などを特に意識せず、異
なる複数のＤＢＭＳに対するアクセス処理を含むアプリ
ケーションプログラムを作成する場合、プログラム作成
における生産性の向上は期待できるが、この開発支援ツ
ールを用いて、複数のＤＢＭＳに対する操作を行うアプ
リケーションプログラムが作成されると、作成されたア
プケーションプログラムは、複数のＤＢＭＳに対する個
々のアクセスモジュールを、アプリケーションプログラ
ムの側でそれぞれに持つ構造のプログラムが作成され
る。

【０００９】この場合、アプリケーションプログラムに
おいて作成された各ＤＢＭＳ用アクセス用プログラム
は、それぞれが各ＤＢＭＳに依存するプログラムであ
り、統一されたユーザインタフェースから各ＤＢＭＳア
クセスを行う場合には、当該ユーザインタフェースと生
成された各々のＤＢＭＳ用アクセス用のプログラムとを
リンクする必要がある。また、複数のＤＢＭＳ用のアク
セスモジュールをアプリケーションプログラムの側で持
つことになるため、データベースの種類に応じて、操作
対象のＤＢＭＳの数が増加すると、アクセス対象のＤＢ
ＭＳおよびデータベース表の増加に伴い、アプリケーシ
ョンプログラムの性能が落ちてしまう。更には、各ＤＢ
ＭＳのデータ型の相違を吸収する部分がないため、ユー
ザインタフェースが同じ内容のプログラムとならないと
いう問題がある。

【００１０】図２により具体的に説明すると、図２は、
上述したようなＤＢＭＳ用開発支援ツールを用いて作成
されたアプリケーションプログラムによるデータベース
アクセス処理を説明する図である。図２において、１は
データベースに対するアクセス処理を伴うアプリケーシ
ョンプログラムが走るワークステーション、２は第１の
データベース提供者のワークステーション、３は第２の
データベース提供者のワークステーション、４はローカ
ルエリアネットワークを構成するネットワークである。
１５はベンダ１のデータベース管理システム（ＤＢＭＳ
１）、１６はベンダ１のデータベース本体部、１７はベ
ンダ２のデータベース管理システム（ＤＢＭＳ２）、１
８はベンダ２のデータベース本体部である。また、２０
はアプリケーションプログラム本体部、２１はベンダー
１のＤＢＭＳをアクセスするベンダー１用アクセスイン
タフェースであり、２２はベンダー２のＤＢＭＳをアク
セスするベンダー２用アクセスインタフェースである。

【００１１】このようなシステム要素により、ソフトウ
ェア動作環境が形成され、ここで動作するアプリケーシ
ョンプログラム２０のソフトウェア動作環境は、複数の
異種ＤＢＭＳがネットワーク上で接続される分散型のデ
ータベースシステムとなっている。アプリケーションプ
ログラム２０は、上述のような各ＤＢＭＳ用開発支援ツ
ールにより生成されたものであり、ここでのアプリケー
ションプログラム２０には、２つの異なるＤＢベンダー
のデータベースを操作するため、ベンダー１のＤＢＭＳ
をアクセスするベンダー１用アクセスインタフェース２
１と、ベンダー２のＤＢＭＳをアクセスするベンダー２
用アクセスインタフェースとが、それぞれ個別に設けら
れたプログラム構造で作成されたものとなっている。

【００１２】また、各々のＤＢＭＳで異なるデータ型の
相違を吸収するためには、アプリケーョンプログラム２
０において、そのデータ型の解釈を行う処理プログラム
を備える。そのため、アプリケーョンプログラム２０
は、ベンダー１のＤＢＭＳに対して、ベンダー１データ
型解釈処理２０ａのプログラムが設けられ、ベンダー２
のＤＢＭＳに対して、ベンダー２データ型解釈処理２０
ｂのプログラムが設けられた構造のプログラムとなって
いる。これらのデータ型解釈を行う処理プログラムは、
必要に応じてアプリケーョンプログラム２０内に埋め込
まれる。

【００１３】各ベンダー用のアクセスインタフェースに
より、各々のＤＢＭＳをアクセスする場合、各ベンダー
用のデータ型解釈処理部（２０ａ，２０ｂ）がそれぞれ
のアクセスインタフェースとリンクされ、アプリケーシ
ョンプログラムにおけるデータ型の解釈を行い、アプリ
ケーションプログラムのデータ型を各々のベンダー用の
データ型に合せて、アクセスインタフェース（２１，２
２）が各々のＤＢＭＳに対するアクセス処理を行う。

【００１４】したがって、ここでのアプリケーションプ
ログラム２０は、操作対象の各ベンダー用のアクセスイ
ンタフェース，各ベンダー用のデータ型解釈処理の処理
プログラムを備える結果、プログラム自体が重くなり、
全体的な性能が低下する。また、アクセスする対象のデ
ータベースが増加した場合など、これらの各ベンダー用
のＤＢＭＳのアクセスインタフェースに対応して装備す
るデータ型解釈処理のプログラムは、アプリケーション
プログラムの開発者の側で作成しなければならず、将来
のバージョンアップなどに容易に対応できないなど、プ
ログラムの保守性が悪いという問題がある。

【００１５】本発明の上述のような問題点を解決するた
めになされたもので、本発明の目的は、データベースを
操作するＤＢＭＳへのアクセス処理を伴うアプリケーシ
ョンプログラムを開発する場合において、そのアプリケ
ーションプログラムにおけるデータベースアクセスモジ
ュールの開発が効率よく行え、しかもシステム全体とし
て各々のアプリケーションプログラムのデータベースの
アクセス処理が能率よく行え、プログラムの保守性が向
上したアプリケーションプログラムのデータベースアク
セス方式を提供することにある。

【００１６】本発明の他の目的は、複数のＤＢＭＳへ同
一のアプリケーションプログラムからのアクセスが共通
のアクセスインタフェースで可能となるアプリケーショ
ンプログラムのデータベースアクセス方式を提供するこ
とにある。

【００１７】また、本発明の別の他の目的は、複数のＤ
ＢＭＳへ同一のアプリケーションプログラムからのアク
セスが可能となる開発支援ツール（共通ライブラリ）を
提供することにより、アプリケーションプログラムの開
発者に各ＤＢＭＡの構造や各アプリケーションインタフ
ェースの違いを意識させず、更に、データ型の違いを意
識させない（データ型の違いを吸収してしまう）構造の
アプリケーションプログラムのデータベースアクセス方
式を提供することにある。

【００１８】

【課題を解決するための手段】上述のような目的を達成
するため、本発明のアプリケーションプログラムのデー
タベースアクセス方式は、アプリケーションプログラム
（１０）においてデータベース管理システム（１５，１
７）のアクセス処理を行うアプリケーションプログラム
のデータベースアクセス方式であって、データベース管
理システムの種別に依存しない形でインタフェース処理
を行うアプリケーションプログラムインタフェース（１
１）と、複数の各々のデータベース管理システムに対し
てそれぞれにアクセス処理を行う各処理実行部（１３）
と、前記アプリケーションプログラムインターフェイス
からの接続要求に基づいて操作対象のデータベース管理
システムに対するアクセス処理を行う処理実行部とアプ
リケーションプログラムインターフェイスとの間の接続
を行うサーバー（１２）とを備えることを特徴とする。

【００１９】また、ここでは、前記サーバー（１２）
が、前記アプリケーションプログラムインターフェイス
からの接続要求に基づいて、処理実行部とアプリケーシ
ョンプログラムインターフェイスとの間の接続を行う際
に、参照する各データベースに対する管理情報を格納し
たテーブル（１４）を更に備えることを特徴とする。

【００２０】また、前記アプリケーションプログラムイ
ンタフェース（１１）には、共通データ型の定義情報を
含み、前記各処理実行部（１３）には、データベース管
理システムに固有のデータ型と共通データ型との変換を
行う変換部（６，８）を更に備えたことを特徴とする。

【００２１】

【作用】本発明のアプリケーションプログラムのデータ
ベースアクセス方式によると、複数のデータベース管理
システム（１５，１６）のアクセス処理を行うアプリケ
ーションプログラム（１０）には、データベース管理シ
ステムの種別に依存しない形で、各処理実行部とのイン
タフェース処理を行うアプリケーションプログラムイン
タフェース（１１）が設けられ、アプリケーションプロ
グラム（１０）が動作するソフトウェア動作環境を提供
するシステム内に、各アプリケーションプログラムが共
通に使用できる各々のデータベース管理システムとの間
のアクセス処理を行う各処理実行部（１３）と、サーバ
ー（１２）とが備えられる。

【００２２】アプリケーションプログラム（１０）に備
えられたアプリケーションプログラムインタフェース
（１１）は、データベース管理システムの種別に依存し
ないインタフェース処理を行い、各処理実行部（１３）
が複数の各々のデータベース管理システムに対してそれ
ぞれのアクセス処理（５，７）を行う。また、サーバー
（１２）は、アプリケーションプログラムインターフェ
イス（１１）からの接続要求に基づいて、対象のデータ
ベース管理システムに対するアクセス処理を行う個別の
処理実行部（１３ａ，１３ｂ）と接続要求を出したアプ
リケーションプログラムインターフェイス（１１）との
間の接続を行う。

【００２３】このため、サーバーが処理実行部とアプリ
ケーションプログラムとの接続を行う際に参照する各デ
ータベースに対応する管理情報を格納したテーブル（１
４）が備えられおり、サーバー（１２）は、テーブル
（１４）の内容を参照して、サーバーが処理実行部とア
プリケーションプログラムインターフェイスとの間の接
続を行う。

【００２４】アプリケーションプログラム（１０）にお
いては、アプリケーションプログラムインタフェース
（１１）が、複数のデータベース管理システムに対して
その種別に依存しないインタフェース処理を行うが、こ
の際、操作者に対して共通の操作によるデータベース操
作の処理が可能なように、データ型の相違に対する制約
を吸収して、アプリケーションプログラムインタフェー
ス（１１）は共通データ型でのインタフェース処理を行
う。このため、アプリケーションプログラムインタフェ
ース（１１）には共通データ型の定義情報を含んでお
り、この定義情報を利用してデータ型変換を行う変換部
（６，８）が、更に各処理実行部（１４）に備えられて
いる。変換部（６，８）はデータベース管理システムに
固有のデータ型と共通データ型との変換を行う。この定
義情報による共通データ型でアプリケーションプログラ
ムインタフェース（１１）と各処理実行部（１４）との
間の連絡を行い、その後、データ型変換を行い、各処理
実行部（１４）が、各データベース管理システムとの間
でそれぞれのデータベース管理システムの固有のデータ
型で連絡を行う。

【００２５】したがって、変換部（６，８）により、各
々のデータベース管理システムの間のデータ型はその相
違が吸収されるので、アプリケーションプログラムの開
発者は、特に、各ＤＢＭＡの構造や各アプリケーション
プログラムインタフェースの違い、更には、データ型の
違いを意識せず、アプリケーションプログラムの開発を
行うことができ、その開発負担が軽減され、開発の生産
性を向上させることができる。

【００２６】このように、アプリケーションプログラム
においてデータベースアクセス処理を行う場合、サーバ
ーがアプリケーションプログラムインターフェイスから
の接続要求に基づいて、対象のＤＢＭＳに対するアクセ
ス処理を行う処理実行部との間の接続を行い、アプリケ
ーションプログラムインタフェースおよび処理実行部を
介して、対象となる１つのＤＢＭＳベンダーの１つのデ
ータべースに対するアクセス処理を行う。アクセスする
対象のデータベースが異なる場合には、そのＤＢＭＳに
対応する処理実行部への接続の切換えをサーバーが行
い、アプリケーションプログラムからは共通のアプリケ
ーションプログラムインタフェースを介して、データベ
ースに対するアクセス処理が行なわれる。

【００２７】ここでは、アプリケーションプログラム側
には、アプリケーションプログラムインタフェースのみ
が備えられており、アプリケーションプログラムにおい
けるデータベースに対するアクセス処理は、アプリケー
ションプログラムインタフェース，各処理実行部，およ
びサーバーを用いて行なわれる。このため、データベー
スに対する操作を含むアプリケーションプログラムを開
発する場合、特に、アプリケーションプログラムには、
各々のＤＢＭＳの操作に共通なアプリケーションプログ
ラムインタフェースのみを備えていれば良いので、アプ
リケーションプログラム開発者に各ＤＢＭＳの構造や各
ＤＢＭＳ用のアプリケーションプログラムインタフェー
スを意識しないで済む。

【００２８】これにより、アプリケーションプログラム
開発者は、各ＤＢＭＳの構造や各ＤＢＭＳ用のアプリケ
ーションプログラムインタフェースを意識しないで済
み、また、データ型の相違も意識しないで済むので、ア
プリケーションプログラムの開発者の負担が軽減され
る。このため、ソフトウェア開発の生産性を向上させる
ことができる。また、アプリケーションプログラムが複
数のデータベースに対する操作を行う場合にも、アプリ
ケーションプログラムインタフェースがサーバーに対す
るデータベースへの接続要求のみを発行すればよいの
で、アプリケーションプログラム自体が重くなり、性能
が落ちてしまうことはない。更にアクセスする対象のデ
ータベースが新たに増加した場合には、新たに増加した
ＤＢＭＳに対するＤＢＭＳ用の処理実行部のみを、ＤＢ
ＭＳベンダーから提供される開発支援ツールを用いて作
成し、必要であればデータ型変換部を含んだ処理実行部
を作成して、システム内にインストールするだけで良
く、格別にアプリケーションプログラムの修正作業を行
うことなく対応できる。このため、将来のバージョンア
ップなどに容易に対応でき、プログラムの保守性が良
い。

【００２９】

【実施例】以下、本発明の一実施例を図面を参照して具
体的に説明する。図１は、本発明の一実施例にかかるア
プリケーションプログラムのデータベースアクセス方式
の要部の構成を示すプロック図である。図１において、
１はデータベースのアクセス処理を伴うアプリケーショ
ンプログラムが走るワークステーション、２は第１のデ
ータベース提供者のワークステーション、３は第２のデ
ータベース提供者のワークステーション、４はローカル
エリアネットワークを構成するネットワークである。ま
た、１０はアプリケーションプログラム、１１はアプリ
ケーションプログラムインタフェース、１２はサーバ
ー、１３（１３ａ，１３ｂ）は各々のＤＢＭＳベンダ用
処理実行部、１４は処理実行部エントリテーブルをそれ
ぞれ示している。１５はベンダ１のデータベース管理シ
ステム（ＤＢＭＳ）、１６はベンダ１のデータベース本
体部、１７はベンダ２のデータベース管理システム（Ｄ
ＢＭＳ）、１８はベンダ２のデータベース本体部であ
る。なお、各々のＤＢＭＳベンダ用処理実行部１３は各
ベンダー向けアクセス処理（１３ａ，１３ｂ）に対応し
て、ＤＢＭＳ１アクセス処理実行部５，ＤＢＭＳ１／共
通データ型変換処理部６，ＤＢＭＳ２アクセス処理実行
部７，ＤＢＭＳ２／共通データ型変換処理部８をそれぞ
れ備えている。

【００３０】ここでのアプリケーションプログラム１０
が走るソフトウェア動作環境は、図１に示すように、各
ワークスーション１，２，３がネットワーク４により相
互に接続されたネットワークシステムとなっており、ワ
ークステーション２，３で複数の異種ＤＢＭＳがネット
ワーク上に接続された分散型のデータベースシステムを
構成している。アプリケーションプログラム１０は、２
つの異なるＤＢベンダーのＤＢＭＳにおけるデータベー
スを操作する場合にも、それぞれに対応したアクセスイ
ンタフェースは必要とせず、共通に用いるアプリケーシ
ョンプログラムインタフェース１１のみで良い。また、
データベース処理では、共通データ型でデータベース操
作を行うため、共通データ型解釈処理を行い、アプリケ
ーションプログラムインタフェース１１とのリンクを行
う。データベースのアクセス処理を伴うアプリケーショ
ンプログラム１０が走るワークステーション１には、図
示するように、サーバー１２，各々のＤＢＭＳベンダ用
処理実行部１３，および処理実行部エントリテーブル１
４が備えられている。

【００３１】ＤＢＭＳベンダ用処理実行部１３には、各
々のＤＢＭＳに対するアクセス処理を行うための処理実
行部として、第１のＤＢＭＳベンダ用処理実行部５，第
１のＤＢＭＳ用データ型と共通データ型との間のデータ
型変換を行うＤＢＭＳ１／共通データ型変換処理部６，
第２のＤＢＭＳベンダ用処理実行部７，第２のＤＢＭＳ
用データ型と共通データ型との間のデータ型変換を行う
ＤＢＭＳ２／共通データ型変換処理部８が備えられてい
る。ここでの共通データ型の定義情報は、アプリケーシ
ョンプログラムインタフェース１１に含まれており、必
要に応じて参照される。

【００３２】なお、データベースに対するアクセス処理
を伴うアプリケーションプログラム１０には、データベ
ースのアクセスのために、アプリケーションプログラム
インタフェース１１のみが付加された形態でのプログラ
ム開発が行なわれ、サーバー１２，各々のＤＢＭＳベン
ダ用処理実行部１３（５，６，７，８）および処理実行
部エントリテーブル１４が備えられたワークステーショ
ン１の上で、当該アプリケーションプログラム１０が走
ることになる。

【００３３】アプリケーションプログラムインターフェ
イス１１は、アプリケーションプログラム開発におい
て、ＤＢＭＳ非依存のインタフェース機能を提供してい
るプログラムモジュールであり、プログラム開発者は、
この共通のインタフェース機能を習熟することにより、
複数のＤＢＭＳを扱う場合にも、各ＤＢＭＳの構造や各
ＤＢＭＳ用アプリケーションプログラムインタフェー
ス，データ型を意識することなく、プログラム開発を行
うことができる。

【００３４】また、サーバー１２は、当該ワークステー
ション１において、アプリケーションプログラムインタ
フェース１１からの接続要求を見張り、その接続要求が
発行された場合に、対象となる各ＤＢＭＳベンダ用処理
実行部１３における各々のアクセス処理部（１３ａ，１
３ｂ）との接続サービスを行う機能を提供する。ここで
は、データ型の相違を吸収するため、アプリケーション
プログラムインタフェース１１と各々のＤＢＭＳアクセ
ス処理実行部（５，７）との間の接続は、各々のＤＢＭ
Ｓ／共通データ型変換処理部（６，８）を介して行う。

【００３５】ＤＭＢＳベンダ用処理実行部１３の各々の
ＤＢＭＳアクセス処理実行部は、各ベンダーからの開発
支援ツールにより各ベンダーＤＢＭＳ用アプリケーショ
ンインタフェースを利用して作成されており、当該ワー
クステーション１において、各ＤＢＭＳのアクセスメソ
ッドの相違，データ型の相違を吸収して、データベース
を操作する対象のＤＢＭＳに対するアクセス処理（発
行，受取り）機能を提供する。

【００３６】また、処理実行部エントリテーブル１４
は、サーバー１２がアプリケーションプログラム１０か
らのデータベース接続要求に対して接続処理を行う場合
に参照される管理情報が登録されているテーブルであ
り、接続要求されるＤＢＭＳ名に対して、ＤＢＭＳベン
ダ用処理実行部名を対応させて登録してある。アプリケ
ーションプログラム１０における処理の中からの接続要
求に対して、ＤＢＭＳベンダ用処理実行部１３の何れの
ＤＢＭＳのアクセス処理部（１３ａ，１３ｂ）との接続
を行うかの対応が参照される。

【００３７】図３は処理実行部エントリテーブルの構成
例を示す図である。処理実行部エントリテーブル１４
は、具体的に説明すると、図３に示すように、ＤＢＭＳ
の名前を登録するＤＢＭＳ名フィールド３１と、対応Ｄ
ＢＭＳのアクセスツールを登録するＤＢＭＳアクセス処
理実行部名フィールド３２とから構成されており、ＤＢ
ＭＳ名に対応して起動すベきＤＢＭＳアクセス処理実行
部の名前を登録してあるエントリテーブルである。ま
た、この分散型データベースシステムにおいて接続可能
な各々のＤＢＭＳを管理している管理情報となってい
る。前述したように、アプリケーションプログラムイン
タフェース１１からＤＢＭＳ名を指定した接続要求が発
行された場合、サーバー１２が、処理実行部エントリテ
ーブル１４を参照して、ＤＢＭＳ名から対応するＤＢＭ
Ｓアクセス処理実行部プログラム名を知り、該当のＤＢ
ＭＳアクセス処理実行部プログラムを起動する。

【００３８】次に、このような動作環境で動作するアプ
リケーションプログラム１０におけるデータベースに対
するアクセス処理の概略を説明する。まず、アプリケー
ションプログラム１０の処理において、データベース操
作での共通データ型の解釈処理が行なわれ、ＤＢＭＳの
アクセス処理を行うステップに処理が進行すると、アプ
リケーションプログラムインタフェース１１が、アプリ
ケーションプログラム本体部分とのインタフェース処理
により、サーバー１２に対してＤＢＭＳに接続要求を発
行する。サーバー１２は、アプリケーションプログラム
インターフェイス１１からの接続要求に基づいて、処理
実行部エントリテーブル１４における対応情報を参照し
て、対象のデータベース管理システムに対するアクセス
処理を行うＤＢＭＳベンタ用処理実行部１３の対応のア
クセス処理部を起動し、次にアプリケーションプログラ
ムインタフェース１１を介してアプリケーションプログ
ラム１０の本体部との間の接続を行う。これにより、接
続されたＤＢＭＳベンタ用処理実行部１３の例えばＤＢ
ＭＳアクセス処理部１３ｂは、操作対象のＤＢＭＳに対
してのアクセス処理を行う。

【００３９】このように、アプリケーションプログラム
１０においてデータベースアクセスを行う場合、サーバ
ー１２がアプリケーションプログラムインターフェイス
１１からの接続要求に基づいて、対象のＤＢＭＳに対す
るアクセス処理を行う個別ＤＢＭＳベンダ用処理実行部
（１３ａまたは１３ｂ）を起動し、例えばＤＢＭＳベン
ダ用アクセス処理実行部１３ｂとアプリケーションプロ
グラムインターフェイス１１との間の接続を行い、ＤＢ
ＭＳベンダ用処理実行部１３が対象のＤＢＭＳとの間の
アクセス処理を行ってその間の接続を行う。したがっ
て、データベースアクセス処理では、アプリケーション
プログラムインタフェース１１およびＤＢＭＳベンダ用
処理実行部１３を介して、対象となるＤＢＭＳのデータ
べース操作を行うことになる。

【００４０】次に、図４〜図７を参照して、各々の処理
モジュールの間の接続を行い、順次にデータベースに対
するアクセス処理を進んで行く様子の各状態を説明す
る。図４は、アプリケーションプログラムが実行された
直後の時点の状態を示す図であり、図５は、アプリケー
ションプログラムがアプリケーションプログラムインタ
ーフェイスの接続要求を行った時点の状態を示す図であ
る。図６は、サーバ一が操作対象のＤＢＭＳベンダ用処
理実行部を起動した時点の状態を示す図であり、また、
図７は、アプリケーションプログラムがアプリケーショ
ンプログラムインターフェイスを通してアクセス要求を
行った場合の状態を示す図である。

【００４１】まず、図４に示すような初期状態から、ア
プリケーションプログラム１０が、各ベンダから提供さ
れているデータベースへのアクセス動作を行う場合、図
５に示すように、まず、アプリケーションプログラム１
０がアプリケーションプログラムインターフェイス１１
を介してサーバー１２に接続要求を発行する。接続要
求が発行されると、サーバー１２は、この接続要求
をキャッチする。サーバー１２は接続要求の要求パラ
メータ（どのＤＢＭＳに接続するのか）を判別し、その
内容から処理実行部エントリテーブル１４を参照して、
対象のＤＢＭＳに対してアクセス処理を実行するＤＢＭ
Ｓベンダ用処理実行部プログラム名を確定する処理を
行う。

【００４２】次に、図６に示すような状態となり、サー
バ１２が処理実行部エントリテーブル１４により確定さ
れたプログラム名から当該するＤＢＭＳ２アクセス処理
実行部７を起動する。起動されたＤＢＭＳ２アクセス
処理実行部７は、アプリケーションプログラム１０のア
プリケーションプログラムインタフェース１１との間の
接続を行うため、対応のＤＢＭＳ２のデータ型と共通デ
ータ型との間のデータ型変換を行うＤＢＭＳ２／共通デ
ータ型変換処理部８を起動し、このＤＢＭＳ２／共通デ
ータ型変換処理部８を介して、この間のデータベースア
クセス処理を行うパスを確立する。この時点でサーバ
ー１２は、他のアプリケーションプログラムがそのアプ
リケーションプログラムインタフェースを通して要求を
してくる次の接続要求の発行を待つ状態となる。

【００４３】そして、次の状態は図７に示すような状態
となり、起動されたＤＢＭＳ２アクセス処理実行部７
は、アプリケーションプログラムインタフェース１１か
らの要求により対象とするＤＢＭＳ２（１７）との接続
処理を行い、その間のデータベースアクセス処理を行う
パスを確立する。この結果、先に確立されたアプリケ
ーションプログラムインタフェース１１とのアクセスパ
スおよびその後に確立されたＤＢＭＳ２（１７）との
アクセスパスを通して、アプリケーションプログラム
１０がアプリケーションプログラムインタフェース１１
およびＤＢＭＳ２ベンダ用処理実行部１３ｂの各処理モ
ジュール（ＤＢＭＳ２アクセス処理実行部７，ＤＢＭＳ
２／共通データ型変換処理部８）を介して、操作対象の
データベース本体部１８のＤＢＭＳ２（１７）に対して
アクセス処理を行う状態となる。ここでのＤＢＭＳ２
（１７）に対するアクセス処理が終了すると、その後、
アプリケーションプログラム１０がアプリケーションプ
ログラムインタフェース１１を通して、切断要求を行っ
た後、ＤＢＭＳ２アクセス処理実行部７が接断処理を行
い、処理を終了して、図４に示すような状態に戻る。

【００４４】次に、図８〜図１１を参照して、アプリケ
ーションプログラムからのデータベースのアクセス処理
において各々のベンダーのＤＢＭＳ固有のデータ型の違
いがどのように吸収されるかを、前述の説明と同様に順
を追って説明する。図８は、アプリケーションプログラ
ムから検索命令を発行した時の状態を示す図であり、図
９は、ＤＢＭＳアクセス処理実行部から操作対象のＤＢ
ＭＳに対して検索命令を発行する時の状態を示図であ
る。図１０は、検索命令を発行したＤＢＭＳアクセス処
理実行部に操作対象のＤＢＭＳからの検索結果が返って
きた時の状態を示す図であり、また、図１１は、ＤＢＭ
Ｓアクセス処理実行部が検索命令を発行したアプリケー
ションプログラムに検索結果を返す時の状態を示す図で
ある。

【００４５】ここでは、データベースに対してアプリケ
ーションプログラムから検索命令を発行する場合を例に
して具体的に説明する。まず、図８に示すように、アプ
リケーションプログラム１０において発行されるデータ
ベースの検索命令４１は、アプリケーションプログラム
インタフェース１１から発行されるが、この場合、検索
結果は共通データ型で受け取ることを指定して、ＤＢＭ
Ｓ２のアクセス処理を行うＤＢＭＳ２アクセス処理部１
３ｂに対して検索命令４１を発行する。すなわち、アプ
リケーションプログララム１０では、検索命令４１のパ
ラメータで、アプリケーションプログラムインタフェー
ス１１において自分の受け取る検索結果のデータ型を定
義情報で定義されている共通データ型から、例えば共通
の文字列型とういうように指定して検索命令を発行す
る。

【００４６】ＤＢＭＳ２アクセス処理部１３ｂは、先の
接続要求によりアクセス対象のＤＢＭＳ２に対するアク
セス実行処理を行うＤＢＭＳ２アクセス処理実行部７お
よびＤＢＭＳ２／共通データ型変換処理部８が起動され
ており、この共通データ型による検索命令４１を、ＤＢ
ＭＳ２アクセス処理実行部７はＤＢＭＳ２／共通データ
型変換処理部８を介して、共通データ型からベンダー２
用データ型の検索命令に変換して受け付ける。

【００４７】次に、ベンダー２用データ型の検索命令に
変換して受け付けたＤＢＭＳ２アクセス処理実行部７
は、データベース管理システム（ＤＢＭＳ２）１７に対
するアクセス処理を行い、図９に示すように、ベンダー
２用データ型の検索命令４２をデータベース管理システ
ム（ＤＢＭＳ２）１７に送信する。これにより、データ
ベース管理システム（ＤＢＭＳ２）１７においては、検
索命令４２によりベンダー２データベース本体部１８に
対して、データベース検索処理が行なれ、その検索結果
が返される。

【００４８】この結果、図１０に示すように、検索結果
は、データベース管理システム（ＤＢＭＳ２）１７から
ベンダー２用データ型で検索結果４３が返される。ベン
ダー２用データ型での検索結果４３は、ＤＢＭＳ２アク
セス処理実行部７において受け取られる。次に、ＤＢＭ
Ｓ２アクセス処理実行部７は、図１１に示すように、ベ
ンダー２用データ型での検索結果４３をＤＢＭＳ２／共
通データ型変換処理部８を介して共通データ型の検索結
果へのデータ型変換を行い、共通データ型の検索結果４
４として、アプリケーションプログラムインタフェース
１１に検索結果を返す。これにより、アプリケーション
プログラム１０においては、共通データ型の検索結果を
利用する。このようにして、データベースの検索処理に
おける各々のデータ型の変換が行なわれる。また、デー
タベースに対して入力操作を行う場合、更新操作を行う
場合には、共通データ型から各ベンダーのＤＢＭＳに対
応するデータ型への変換が行なわれて、処理される。

【００４９】図１２はアプリケーショプログラムインタ
フェースに設けられる共通データ型の定義情報の構成例
を示す図である。この定義情報は、図１２に示すよう
に、共通データ型５１の定義情報と、この共通データ型
５１と対応する各々の各ベンダーのＤＢＭＳのデータ型
との対応テーブルとして定義されている。ここでは共通
データ型５１であるＲＣＡデータ型と、このシステムで
アクセス処理が可能となっている第１のＤＢＭＳ１の
「ＯＲＡＣＬＥ」のデータ型５２、第２のＤＢＭＳ２の
「ｉｎｆｏｒｍｉｘ」のデータ型５３、および第３のＤ
ＢＭＳ３の「Ｓｙｂａｓｅ」のデータ型５４が、対応づ
けられている。これらのデータ型の変換は、１対１に対
応づけられるものでなく、アプケーションプログラムの
内容に応じて任意に対応づけられる。

【００５０】図１３，図１４，および図１５は、検索処
理において各々のＤＢＭＳの固有のデータ型がアプリケ
ーションプログラムインタフェースの共通データ型に変
換される場合の対応関係の具体例を示す図である。図１
３に、データベース「ＯＲＡＣＬＥ」のデータ型から共
通データ型への変換関係を示し、図１４には、データベ
ース「ｉｎｆｏｒｍｉｘ」のデータ型から共通データ型
への変換関係を示している。また、図１５に、データベ
ース「Ｓｙｂａｓｅ」のデータ型から共通データ型への
変換関係を示している。これらの図の変換関係から明ら
かなように、本実施例のアプリケーションプログラムの
データベースアクセス方式を用いることにより、各々の
データベースに固有の複雑なデータ型の指定を、共通デ
ータ型により指定で容易に行うことができる。

【００５１】以上に説明したように、アプリケーション
プログラム１０がデータベースの操作を伴うアクセス処
理を行う場合、アプリケーションプログラムインターフ
ェイス１１からの接続要求に基づいて、サーバー１２が
対象のＤＢＭＳに対するアクセス処理を行うＤＢＭＳベ
ンダ用処理実行部１３との間の接続を行い、アプリケー
ションプログラムインタフェース１１およびＤＢＭＳベ
ンダ用処理実行部１３の各々の処理モジュールを介し
て、例えば操作対象となる１つのデータべース本体部１
８に対するアクセス処理を行う。この際に各々のＤＢＭ
Ｓベンダ用処理実行部１３ではデータ型の相違も吸収す
る。

【００５２】各々のアプリケーションプログラム１０で
アクセスする対象のデータベースが異なる場合には、そ
のＤＢＭＳに対応するＤＢＭＳベンダ用処理実行部１３
への接続をサーバー１２が行い、アプリケーションプロ
グラムからは共通仕様のアプリケーションプログラムイ
ンタフェース１１を介して、データベースに対するアク
セス処理が行なう。このため、サーバー１２と共に備え
られ、アプリケーションプログラムインタフェースから
の接続要求を受けて、サーバーがＤＢＭＳベンダ用処理
実行部１３とアプリケーションプログラムインタフェー
ス１１との間の接続を行うための情報を与える処理実行
部エントリテーブル１４が設けられる。

【００５３】以上に説明した本実施例による効果をまと
めると次のようになる。 （１）従来においては、各ベンダー用ＤＢＭＳのアプリ
ケーションプログラムインタフェースが異なるため、ア
プリケーションプログラムもそれに依存したものとな
り、個別にアプリケーションプログラムを開発しなけれ
ばならなかったが、本実施例のようなアクセス方式によ
ると、複数のＤＢＭＳにアクセスするアプリケーション
プログラムが同一のものですむ。すなわち、アプリケー
ションプログラムはアプリケーションプログラムインタ
フェースにより、ＤＢＭＳに対する接続要求を発行する
際に、ＤＢＭＳを指定するだけでよい。また、各ＤＢＭ
Ｓ用のデータ型をアプリケーションプログラムの処理で
それぞれ解釈する必要があったが、共通データ型を用い
ることにより、共通データ型の解釈を行うだけで、各々
のＤＢＭＳ用のデータ型を扱うことが可能になる。

【００５４】（２）従来においては、各ベンダＤＢＭＳ
用開発援ツールにおけるアプリケーションプログラムイ
ンタフェース仕様を修得しなければ、各ＤＢＭＳ用アプ
リケーションプログラムの開発は不可能であったが、本
実施例によるアクセス方式を用いることにより、アプリ
ケーションプログラム開発者は、共通仕様のアプリケー
ションプログラムインタフェースの利用方法を学習する
だけで、各ベンダーのＤＢＭＳ用アプリケーションの開
発が可能となる。このため、ソフトウェア開発効率が向
上する。言い換えると、ひとつのアプリケーションプロ
グラムを作成すれば、それはベンダー１のＤＢＭＳに
も、ベンダー２のＤＢＭＳにも、どちらにもアクセスで
きるアクセスインタフェースを備えていることになる。

【００５５】（３）将来、アプリケーションプログラム
に対して、新たなＤＢＭＳ対応のバージョンアップを行
う場合、その対応のベンダーＤＢＭＳ用処理実行部とし
て、ＤＢＭＳアクセス処理実行部および当該ベンダー用
ＤＢＭＳデータ型と共通データ型との間のデータ型変換
処理部を追加するだけで良く、アプリケーションプログ
ラム自体には手を加える必要はない。新しいベンダー用
ＤＢＭＳ処理実行部が作成された時点で、処理実行部エ
ントリテーブルに新しいベンダーのＤＢＭＳ名，ＤＢＭ
Ｓアクセス処理実行部名を追加すると、新たなＤＢＭＳ
に対するアクセスが可能となる。

【００５６】

【発明の効果】以上、説明したように、本発明のアプリ
ケーションプログラムのデータベースアクセス方式によ
れば、各々のアプリケーションプログラムの側には、基
本的にはアプリケーションプログラムインタフェースの
みが備えられば良いので、データベースに対する操作を
含むアプリケーションプログラムを開発する場合、アプ
リケーションプログラム開発者に各ＤＢＭＳの構造や各
ＤＢＭＳ用アプリケーションプログラムインタフェース
を意識しないで済む。また、共通データ型へのデータ型
変換処理部が設けられので、データ型の相違を意識しな
いで済む。

【００５７】したがって、アプリケーションプログラム
開発者は、特に、各ＤＢＭＳの構造や各ＤＢＭＳ用アプ
リケーションプログラムインタフェースを意識すること
はなく、データベースのアクセス処理を含むプログラム
の開発を行える。アプリケーションプログラム開発者は
その負担が軽減され、開発の生産性を向上させることが
できる。なお、アプリケーションプログラムが複数のデ
ータベースに対する操作を行う場合、アプリケーション
プログラムインタフェースがサーバーに対するデータベ
ースへの接続要求のみを発行すればよいので、アプリケ
ーションプログラムの性能が落ちてしまうことはない。

【図面の簡単な説明】

【図１】 図１は本発明の一実施例にかかるアプリケー
ションプログラムのデータベースアクセス方式の要部の
構成を示すプロック図、

【図２】 図２は、従来におけるＤＢＭＳ用開発支援ツ
ールを用いて作成されたアプリケーションプログラムに
よるデータベースアクセス処理の流れを説明する図、

【図３】 図３は処理実行部エントリテーブルの構成例
を示す図、

【図４】 図４〜図７は本実施例によるアクセス処理の
各状態を説明する図であり、図４はアプリケーションプ
ログラムが実行された直後の時点の状態を示す図、

【図５】 同じく、図５はアプリケーションプログラム
がアプリケーションプログラムインターフェイスの接続
要求を行った時点の状態を示す図、

【図６】 同じく、図６はサーバ一が操作対象のＤＢＭ
Ｓベンダ用処理実行部を起動した時点の状態を示す図、

【図７】 同じく、図７はアプリケーションプログラム
がアプリケーションプログラムインターフェイスを通し
てアクセス要求を行った場合の状態を示す図である。

【図８】 図８はアプリケーションプログラムからＤＢ
ＭＳアクセス処理実行部に検索命令を発行した時の状態
を示す図、

【図９】 図９はＤＢＭＳアクセス処理実行部から操作
対象のＤＢＭＳに対して検索命令を発行する時の状態を
示図、

【図１０】 図１０は検索命令を発行したＤＢＭＳアク
セス処理実行部に操作対象のＤＢＭＳからの検索結果が
返ってきた時の状態を示す図、

【図１１】 図１１はＤＢＭＳアクセス処理実行部が検
索命令を発行したアプリケーションプログラムに検索結
果を返す時の状態を示す図、

【図１２】 図１２はアプリケーショプログラムインタ
フェースに設けられる共通データ型の定義情報の構成例
を示す図、

【図１３】 図１３は検索処理においてデータベース
「ＯＲＡＣＬＥ」のデータ型からアプリケーションプロ
グラムインタフェースの共通データ型に変換される場合
の対応関係の具体例を示す図、

【図１４】 図１４は検索処理においてデータベース
「ｉｎｆｏｒｍｉｘ」のデータ型からアプリケーション
プログラムインタフェースの共通データ型に変換される
場合の対応関係の具体例を示す図、

【図１５】 図１５は検索処理においてデータベース
「Ｓｙｂａｓｅ」のデータ型からアプリケーションプロ
グラムインタフェースの共通データ型に変換される場合
の対応関係の具体例を示す図である。

【符号の説明】

１…ワークステーション、２…ワークステーション、３
…ワークステーション、４…ネットワーク、５…ＤＢＭ
Ｓ１アクセス処理実行部、６…ＤＢＭＳ１／共通データ
型変換処理部、７…ＤＢＭＳ２アクセス処理実行部、８
…ＤＢＭＳ２／共通データ型変換処理部、１０…アプリ
ケーションプログラム、１１…アプリケーションプログ
ラムインタフェース、１２…サーバー、１３…ＤＢＭＳ
ベンダ用処理実行部、１４…処理実行部エントリテーブ
ル、１５…データベース管理システム（ＤＢＭＳ１）、
１６…データベース本体部、１７…データベース管理シ
ステム（ＤＢＭＳ２）、１８…データベース本体部、２
０…アプリケーションプログラム、２１…ベンダー１用
アクセスインタフェース、２２…ベンダー２用アクセス
インタフェース、３１…データベース名フィールド、３
２…ＤＢＭＳアクセス処理実行部プログラム名フィール
ド。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 アプリケーションプログラムにおいてデ
   ータベース管理システムのアクセス処理を行うアプリケ
   ーションプログラムのデータベースアクセス方式であっ
   て、 データベース管理システムの種別に依存しない形でイン
   タフェース処理を行うアプリケーションプログラムイン
   タフェースと、 複数の各々のデータベース管理システムに対してそれぞ
   れにアクセス処理を行う各処理実行部と、 前記アプリケーションプログラムインターフェイスから
   の接続要求に基づいて操作対象のデータベース管理シス
   テムに対するアクセス処理を行う処理実行部とアプリケ
   ーションプログラムインターフェイスとの間の接続を行
   うサーバーとを備えることを特徴とするアプリケーショ
   ンプログラムのデータベースアクセス方式。
2. 【請求項２】 前記アプリケーションプログラムインタ
   ーフェイスからの接続要求に基づいて、前記サーバーが
   処理実行部とアプリケーションプログラムインターフェ
   イスとの間の接続を行う際に参照する各データベースに
   対する管理情報を格納したテーブルを更に備えることを
   特徴とする請求項１に記載のアプリケーションプログラ
   ムのデータベースアクセス方式。
3. 【請求項３】 前記アプリケーションプログラムインタ
   フェースには、共通データ型の定義情報を含み、 前記各処理実行部には、各データベース管理システムに
   固有のデータ型と共通データ型との変換を行う変換部を
   更に備えたことを特徴とする請求項１に記載のアプリケ
   ーションプログラムのデータベースアクセス方式。