JP2014026368A - 情報処理装置、その制御方法、及びプログラム - Google Patents

Abstract

【課題】異種データベースに対応したパッケージソフトウェアを開発する場合に、メンテナンス性を向上させつつ、各社ベンダが提供する特定のＳＱＬ文を利用することの可能な仕組みを提供すること
【解決手段】アプリケーションサーバ１０２は、クライアント端末１０１からデータの取得要求を受け付け、取得要求に基づいて共通エンティティファイル６２０を参照する。取得要求に対応するＳＱＬ文６２２が他ＤＢＭＳ用エンティティファイル６３０を参照するよう指示されていれば、当該他ＤＢＭＳ用エンティティファイル６３０を参照してＳＱＬ文を作成し、指示されていなければ、共通エンティティファイル６２０から異種データベースで利用可能な共通のＳＱＬ文を使用する。
【選択図】図５

Description

本発明は、異なる種別のデータベースにアクセスする仕組みに関し、特にメンテナンス性を向上させつつ、各社ベンダが提供する特定のＳＱＬ文を利用することの可能な情報処理装置、その制御方法、及びプログラムに関する。

従来、パッケージソフトウェアにおいて、データベースサーバに対してクライアント端末からＳＱＬ文を発行し、データベースサーバのリレーショナルデータベースから必要なデータを取得し、表示する仕組みが存在する。このような仕組みは、生産管理や在庫管理など様々な仕組みで利用されている。

しかしながら、ユーザはデータベースサーバが稼働しているか否かを確認することなく、当該データベースサーバに対してＳＱＬ文を発行するため、何らかのエラーでデータベースサーバが稼働していない場合には、データを取得できない。

そこで、下記の特許文献１では、データベースサーバに対してＳＱＬ文を発行し、発行されたＳＱＬ文を監視し予め定められた期間に実行されなかった場合には、データベースサーバを再起動する仕組みが開示されている。

特開２０１２−８３８４１号公報

一方、パッケージソフトウェア開発において、異なるベンダが提供するデータベースへの対応が求められる。その対応には、それぞれのデータベースに応じたＳＱＬ（以下、方言ＳＱＬと呼ぶ）を個別に開発する、もしくは標準ＳＱＬにて開発することが一般的である。

これら対応方法の問題点として、前者は対応するデータベースの種類だけＳＱＬを開発する必要があるため、コストが大きくなり、また、メンテナンス性も悪くなると言った点が挙げられる。一方後者は、標準ＳＱＬの整備より方言ＳＱＬの拡張が早くから進められたという時代背景から、開発現場に置いては方言ＳＱＬに慣れ親しんだ開発者が多く、開発者の調達が難しくなる、また、方言ＳＱＬに慣れ親しんだ開発者が標準ＳＱＬで開発することで、逆に開発コストが大きくなる、といった点が挙げられる。

本発明は上記の課題を解決するためになされたもので、本開発の目的は、異種データベースに対応したパッケージソフトウェアを開発する場合に、メンテナンス性を向上させつつ、各社ベンダが提供する特定のＳＱＬ文を利用することの可能な仕組みを提供することである。

上記の目的を達成するために、本発明の情報処理システムは、データベースを備えるデータベースサーバと通信可能に接続された情報処理装置であって、前記データベースサーバに対してデータの取得要求を受け付けるデータ取得要求受付手段と、前記データ取得要求受付手段でデータの取得要求を受け付けた場合、異なる種類の複数データベースで共通に利用可能な取得命令と当該異なる種類のデータベースごとに特有の取得命令とを記憶したエンティティ情報を参照し、前記取得要求に対応する前記特有の取得命令が使用可能か否かを判定する判定手段と、前記判定手段で前記取得要求に対応する前記特有の取得命令が使用可能であると判定された場合には、当該特有の取得命令を用いてデータベースサーバに対してデータの取得命令を送信し、前記判定手段で前記取得要求に対応する前記特有の取得命令が使用可能でないと判定された場合には、前記共通に利用可能な取得命令を用いてデータベースサーバに対してデータの取得命令を送信する送信手段とを備えることを特徴とする。

本発明によれば、異種データベースに対応したパッケージソフトウェアを開発する際に、プログラムソースを変更することなく異種データベースが利用できる。また各社ベンダが提供する方言ＳＱＬの利用ができ、開発コスト抑制を計ることができる。

本発明の情報処理システム１００の構成の一例を示す構成図である。 図１に示すクライアント端末１０１、アプリケーションサーバ１０２、データベースサーバ１０３のハードウェア構成の一例を示す構成図である。 図１に示すクライアント端末１０１、アプリケーションサーバ１０２、データベースサーバ１０３のモジュール構成の一例を示す構成図である。 本発明の実施形態における一連の処理の流れを示すフローチャートである。 実行ＳＱＬ文作成処理の詳細な処理手順の一例を示すフローチャートである。 本実施例における実行ＳＱＬ文作成処理の一例を示す模式図である。 問い合わせ結果表示画面７００の一例を示す模式図である。 ストアドプロシージャを活用しエンティティファイルを共通化する一例を示す模式図である。

以下、図面を参照しながら、本発明の実施の形態について説明する。

図１は、本発明の実施形態に係る情報処理システム１００の構成の一例を示す構成図である。情報処理システム１００は、クライアント端末１０１、並びにアプリケーションサーバ１０２、データベースサーバ１０３から構成されており、クライアント端末１０１、並びにアプリケーションサーバ１０２、データベースサーバ１０３はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０４を介して通信可能に接続されている。

図１のネットワーク上に接続される各種端末あるいはサーバの構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。本実施例では、クライアント端末１０１とアプリケーションサーバ１０２がＬＡＮ１０３を介して通信可能に接続される構成となっているが、クライアント端末１０１がアプリケーションサーバ１０２、及びデータベースサーバ１０３の機能を含み、クライアント端末１０１のみで動作する仕組みであってもよいし、アプリケーションサーバ１０２、及びデータベースサーバ１０３のみでもよい。また、ＬＡＮ１０４は、クライアント端末１０１、並びにアプリケーションサーバ１０２、データベースサーバ１０３の通信が可能となれば、他の通信形態でもよい。

クライアント端末１０１は、ユーザからの操作に応じてデータ問い合わせをアプリケーションサーバ１０２に命じ、当該データ問い合わせ結果を受信して表示する装置である。クライアント端末１０１には、データ問い合わせ命じるためのプログラムがインストールされており、当該プログラムの処理によって、アプリケーションサーバ１０２と通信することで動作する。

アプリケーションサーバ１０２は、クライアント端末１０１からのデータ問い合わせに応じて、ＳＱＬを作成した後、データベースサーバ１０３にデータ問い合わせを命じ、当該データ問い合わせ結果を受信して、またその結果をクライアント端末１０１に送信する装置である。

データベースサーバ１０３は、アプリケーションサーバ１０２からのデータデータ問い合わせ要求に応じて、実際にデータベースへの問い合わせを実行し、アプリケーションサーバ１０２へ送信する装置である。

図２は、本発明の実施形態における各種端末のハードウェア構成を示す図である。

ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。

ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。

また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。

ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。

メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフロッピーディスク（登録商標 ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュメモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明の各種装置が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルは外部メモリ２１１に格納されている。

次に、クライアント端末１０１、並びにアプリケーションサーバ１０２、データベースサーバ１０３のモジュール構成を示す機能構成図について、図３を用いて説明する。尚、図３の各種装置のモジュール構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。

クライアント端末１０１は、画面表示部３０１、及び送受信部３０２を備える。

画面表示部３０１は、各種画面をクライアント端末１０１のディスプレイ２１０に表示させるためのモジュールである。

送受信部３０２は、ＬＡＮ１０４を介してアプリケーションサーバ１０２と各種情報を送受信するためのモジュールである。

アプリケーションサーバ１０２は、ディスパッチャ部３１１、Ｗｅｂサービス部３１２、データアクセスコンポーネント部３１３、データエンティティ部３１４を備える。

ディスパッチャ部３１１は、クライアント端末１０１の送受信部３０２とアプリケーションサーバ１０２のＷｅｂサービス部３１２のデータ送受信を処理する。

Ｗｅｂサービス部３１２は、クライアント端末１０１より送信される要求に対応する具体的な処理を行う。

データアクセスコンポーネント部３１３は、各社ベンダが提供するＤＢＭＳとデータアクセス処理を行う。

データエンティティ部３１４は、データアクセスコンポーネント部３１３にて行われるデータアクセス処理の元になるＳＱＬ文をＸＭＬファイル化して管理する。

データベースサーバ１０３は、各社ベンダが提供するＤＢＭＳ（Ｄａｔａ Ｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）を備える。

次に、本発明の実施例における一連の処理について、図４に示すフローチャートを用いて説明する。尚、Ｓ１０１、Ｓ１１２、Ｓ１１３の各ステップは、クライアント端末１０１におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１０２乃至Ｓ１０５、Ｓ１０９乃至Ｓ１１１の各ステップは、アプリケーションサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１０６乃至Ｓ１０８の各ステップは、データベースサーバ１０３におけるＣＰＵ２０１の制御の下、処理が行われる。

まず、ステップＳ１０１では、クライアント端末１０１は、アプリケーションサーバ１０２に対してデータ問い合わせ要求を受け付けて、当該要求を送信する（データ取得要求受付手段）。データ問い合わせ要求はどのような形式でもよいが、本実施例では図６のデータ問い合わせ要求６００に示すような形式のデータをアプリケーションサーバ１０２に送信する。例えば、生産管理システムであれば、ある製品に関するデータを取得するために、その旨のデータ取得命令をアプリケーションサーバ１０２に送信する。

ステップＳ１０２では、アプリケーションサーバ１０２は、クライアント端末１０１から送信された問い合わせ要求６００（図６参照）を受信し、ステップＳ１０３では、データ問い合わせ要求６００のサーバ処理ＩＤ６０１と、サーバ前処理６１０から対応するエンティティＩＤ６１２とタグＩＤ６１３を決定する。サーバ前処理６１０では、データ問い合わせ要求６００を受けて、後述する共通エンティティファイル（エンティティ情報）内にあるＳＱＬ文で、今回使用するＳＱＬ文を決定するためにエンティティＩＤ６１２とタグＩＤ６１３を決定している。また、エンティティＩＤ６１２は、共通エンティティファイルのファイル名を示す。共通エンティティファイルとは、異なる種類のデータベースで使用可能な共通のＳＱＬ文が格納されているファイルである。また、データベースごとに特有のＳＱＬ（方言ＳＱＬ）については、当該データベースごとに用意されたエンティティファイルを参照するように設定してある。

ステップＳ１０４では、エンティティＩＤ６１２とタグＩＤ６１３より実行ＳＱＬ文６４１を作成する。実行ＳＱＬ文作成処理の詳細は、図５を用いて後述する。

ステップＳ１０５では、ステップＳ１０４にて作成した実行ＳＱＬ文をデータベースサーバ１０３が備えるＤＢＭＳに送信する（送信手段）。ここで、Ａ社のＤＢＭＳを利用している場合にはＡ社のＤＢＭＳに送信され、Ｂ社のＤＢＭＳを利用している場合にはＢ社のＤＢＭＳに送信される。

ステップＳ１０６では、アプリケーションサーバ１０２から送信された実行ＳＱＬ文を受信し、ステップＳ１０７では、各社ＤＢＭＳが実行ＳＱＬ文６４１を実行し該当データを検索する。図６の例では実行ＳＱＬ文６４１がＳＥＬＥＣＴ文であるためデータ検索するが、ＵＰＤＡＴＥ文やＩＮＳＥＲＴ文など一般的なＳＱＬであれば使用可能であり制限はない。

ステップ１０８では、データベースサーバ１０３は、アプリケーションサーバ１０２に対してデータ問い合わせ結果を送信する。

ステップＳ１０９では、データベースサーバ１０３が備える各社ＤＢＭＳからのデータ問い合わせ結果を受信する。ステップＳ１１０では、データ問い合わせ結果を受けて、編集処理や異常処理など実行する。データ問い合わせ結果に応じた処理が不要な場合は、ステップＳ１１０は省略される。Ｓ１１１では、アプリケーションサーバ１０２は、クライアント端末１０１に対してデータ問い合わせ結果を送信する。

ステップＳ１１２では、クライアント端末１０１は、アプリケーションサーバ１０２からデータ問い合わせ結果を受信し、ステップＳ１１３では、受信したデータ問い合わせ結果を元に画面７００（図７参照）を表示する。以上が、本一連の処理の流れの説明である。

次に、アプリケーションサーバ１０２によって実行される実行ＳＱＬ文作成処理の処理手順について説明する。図５は、図１に示すアプリケーションサーバ１０２によって実行される実行ＳＱＬ文作成処理の処理手順の一例を示すフローチャートである。尚、Ｓ２０１乃至Ｓ２１１の各ステップは、アプリケーションサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。

まず、ステップＳ２０１では、アプリケーションサーバ１０２は、ステップＳ１０３において決定されたエンティティＩＤ６１２とタグＩＤ６１３を取得し、ステップＳ２０２では、エンティティＩＤ６１２とエンティティファイル名を照合し、共通エンティティファイル６２０を探す。

ステップＳ２０３では、共通エンティティファイル６２０が見つかった否かを判定し、見つかった場合はステップＳ２０４に進み、見つからなかった場合は異常処理Ｓ２１０を実行し処理を終了する。

ステップＳ２０４では、タグＩＤ６１３と共通エンティティファイル６２０内のタグＩＤを照合し、ＳＱＬ文６２２を参照する。その参照したＳＱＬ文６２２の記述が他ＤＢＭＳ用エンティティからＳＱＬ文を取得する命令であるか否かを判定し、命令である場合はステップＳ２０５へ進み、命令が無い場合はステップＳ２０９へ進む（判定手段）。共通エンティティファイルは複数のＤＢＭＳで利用可能なＳＱＬ文を格納しているが、あるＤＢＭＳ専用のＳＱＬ文や共通のＳＱＬ文を使用するよりもより早く処理可能なＳＱＬ文だけを格納した他ＤＢＭＳ用エンティティファイルに対する参照先もＤＢＭＳに格納しておくことができる。つまり、ステップＳ２０４では、共通エンティティファイル６２０内にそういった方言ＳＱＬを利用するよう記載されているか否かを判定することになる。

ステップＳ２０５では、参照したＳＱＬ文６２２内に指示された他ＤＢＭＳの名称とエンティティＩＤ６１２をエンティティファイル名に照合し、他ＤＢＭＳ用エンティティファイル６３０を探す。

ステップＳ２０６では、他ＤＢＭＳ用エンティティファイル６３０が見つかったか否かを判定し、見つかった場合ステップＳ２０７に進み、見つからなかった場合は異常処理Ｓ２０８を実行し処理終了する。

ステップＳ２０７では、タグＩＤ６１３と他ＤＢＭＳ用エンティティファイル６３０内のタグＩＤ６３１を照合し、ＳＱＬ文６３２を取得し、ステップＳ２１１へ進む。

一方、ステップＳ２０９では、タグＩＤ６１３と共通エンティティファイル６２０内のタグＩＤ６２１を照合し、ＳＱＬ文６２２を取得し、ステップＳ２１１へ進む。

ステップＳ２１１では、ステップＳ２０７、またはステップＳ２０９で取得したＳＱＬ文とステップＳ１０２において受信した問い合わせ条件６０２から、実行ＳＱＬ文を作成する。例えば、図６の実行ＳＱＬ６４０の上段は、共通エンティティファイル６２０を用いて生成された実行ＳＱＬである。一方、図６の実行ＳＱＬ６４０の下段は、他ＤＢＭＳ用エンティティファイル６３０を用いて生成された実行ＳＱＬである。このように、データベースごとのエンティティファイルを用意しておき、共通エンティティファイルで受け取った命令が共通ＳＱＬで処理できるのであればそのまま処理し、そうでない場合には、データベースごとのエンティティファイルに問い合わせて、データベースごとのＳＱＬ文を取得する。こういう構成にすることで、共通エンティティを作り変えるだけで開発ができるようになる。

また、目的を達するもう一つの手段として、各社ＤＢＭＳのストアドプロシージャを開発して、ＳＱＬ文を共通化する方法がある。図８に示すように、例えば、ＳＱＬ文を作成する際、Ａ社ＤＢＭＳでは関数Ａを使用可能だが、Ｂ社、及びＣ社ＤＢＭＳでは関数Ａは使用できない。そのため、前述のエンティティファイルは、各社ＤＢＭＳ毎に持つ必要がある。しかし、Ｂ社、及びＣ社ＤＢＭＳにＡ社ＤＢＭＳで使用できる関数Ａと同名、同機能のストアドプロシージャを開発することで、Ａ社ＤＢＭＳ用のＳＱＬがＢ社、Ｃ社ＤＢＭＳでも使用可能となり、結果的にＳＱＬ文を共通化することができる。

以上説明したように、本実施形態によれば、異種データベースに対応したパッケージソフトウェアを開発する際に、プログラムソースを変更することなく異種データベースが利用できる。また各社ベンダが提供する方言ＳＱＬの利用ができ、開発コスト抑制を計ることが可能となる効果を奏する。

本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。

なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。

なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

１００ 情報処理システム
１０１ クライアント端末
１０２ アプリケーションサーバ
１０３ データベースサーバ
１０４ ネットワーク
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ システムバス
２０５ 入力コントローラ
２０６ ビデオコントローラ
２０７ メモリコントローラ
２０８ 通信Ｉ／Ｆ（インターフェース）コントローラ
２０９ 入力装置
２１０ ディスプレイ装置
２１１ 外部メモリ

Claims (6)

1. データベースを備えるデータベースサーバと通信可能に接続された情報処理装置であって、
   前記データベースサーバに対してデータの取得要求を受け付けるデータ取得要求受付手段と、
   前記データ取得要求受付手段でデータの取得要求を受け付けた場合、異なる種類の複数データベースで共通に利用可能な取得命令と当該異なる種類のデータベースごとに特有の取得命令とを記憶したエンティティ情報を参照し、前記取得要求に対応する前記特有の取得命令が使用可能か否かを判定する判定手段と、
   前記判定手段で前記取得要求に対応する前記特有の取得命令が使用可能であると判定された場合には、当該特有の取得命令を用いてデータベースサーバに対してデータの取得命令を送信し、前記判定手段で前記取得要求に対応する前記特有の取得命令が使用可能でないと判定された場合には、前記共通に利用可能な取得命令を用いてデータベースサーバに対してデータの取得命令を送信する送信手段と
   を備えることを特徴とする情報処理装置。
2. 前記エンティティ情報は、共通エンティティ情報と専用エンティティ情報とから構成され、前記特有の取得命令は前記専用エンティティ情報から取得し、前記共通に利用可能な取得命令は前記共通エンティティ情報から取得することを特徴とする請求項１に記載の情報処理装置。
3. 前記送信手段は、取得した前記共通に利用可能な取得命令または前記特有の取得命令に基づいてＳＱＬ文を作成し、データベースサーバに送信することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記情報処理装置は、クライアント端末とアプリケーションサーバとから構成され、前記データ取得要求受付手段はクライアント端末において実行され、前記判定手段と前記送信手段はアプリケーションサーバにおいて実行されることを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
5. データベースを備えるデータベースサーバと通信可能に接続された情報処理装置の制御方法であって、
   前記情報処理装置のデータ取得要求受付手段が、前記データベースサーバに対してデータの取得要求を受け付けるデータ取得要求受付ステップと、
   前記情報処理装置の判定手段が、前記データ取得要求受付ステップでデータの取得要求を受け付けた場合、異なる種類の複数データベースで共通に利用可能な取得命令と当該異なる種類のデータベースごとに特有の取得命令とを記憶したエンティティ情報を参照し、前記取得要求に対応する前記特有の取得命令が使用可能か否かを判定する判定ステップと、
   前記情報処理装置の送信手段が、前記判定ステップで前記取得要求に対応する前記特有の取得命令が使用可能であると判定された場合には、当該特有の取得命令を用いてデータベースサーバに対してデータの取得命令を送信し、前記判定ステップで前記取得要求に対応する前記特有の取得命令が使用可能でないと判定された場合には、前記共通に利用可能な取得命令を用いてデータベースサーバに対してデータの取得命令を送信する送信ステップと
   を備えることを特徴とする情報処理装置の制御方法。
6. データベースを備えるデータベースサーバと通信可能に接続された情報処理装置の制御方法をコンピュータに実行させるためのコンピュータに読み取り実行可能なプログラムであって、
   前記情報処理装置を、
   前記データベースサーバに対してデータの取得要求を受け付けるデータ取得要求受付手段と、
   前記データ取得要求受付手段でデータの取得要求を受け付けた場合、異なる種類の複数データベースで共通に利用可能な取得命令と当該異なる種類のデータベースごとに特有の取得命令とを記憶したエンティティ情報を参照し、前記取得要求に対応する前記特有の取得命令が使用可能か否かを判定する判定手段と、
   前記判定手段で前記取得要求に対応する前記特有の取得命令が使用可能であると判定された場合には、当該特有の取得命令を用いてデータベースサーバに対してデータの取得命令を送信し、前記判定手段で前記取得要求に対応する前記特有の取得命令が使用可能でないと判定された場合には、前記共通に利用可能な取得命令を用いてデータベースサーバに対してデータの取得命令を送信する送信手段
   として機能させることを特徴とするコンピュータに読み取り実行可能なプログラム。

Images