JP2013143114A - プログラム、情報処理装置およびアクセス支援方法 - Google Patents

Abstract

【課題】ＲＤＢへのアクセス支援を効率的に行うこと。
【解決手段】生成手段１ｂは、キーＭ１および値Ｍ２の組み合わせを設定したオブジェクト４ａとテーブル２ａに対するクエリの雛型５であって当該キーＭ１に対応する文字列Ｍ３を含むクエリの雛型５を示す情報４ｂとを含むアクセス要求４を受け付けると、記憶手段１ａに記憶されたマッピング情報３を参照して、文字列Ｍ３に対応するキーＭ１がマッピング情報３に含まれる何れかのキーと一致するか判定する。生成手段１ｂは、マッピング情報３に含まれる何れかのキーと一致すると判定すると、オブジェクト４ａから当該キーＭ１に対応する値Ｍ２を取得し、クエリの雛型５に含まれる文字列Ｍ３を当該キーＭ１に対応するデータ型の値Ｍ４に置換したクエリ６を生成する。アクセス手段１ｃは、生成した当該クエリ６を用いてテーブル２ａにアクセスする。
【選択図】図１

Description

本発明は、オブジェクト指向言語で開発されたソフトウェアから、複数の項目が定義された関係データベースのテーブルへのアクセスを支援するプログラム、情報処理装置およびアクセス支援方法に関する。

現在、オブジェクト指向言語で開発されたソフトウェアには、関係データベース（ＲＤＢ：Relational DataBase）へアクセスするものがある。このようなソフトウェアを含むシステム開発では、ＲＤＢへのアクセスに係る開発効率を向上するため、ＯＲＭ（Object - Relational Mapping）ツールが利用されることがある。ＯＲＭツールは、オブジェクトとＲＤＢのテーブルにおけるレコードとの対応付けを行い、当該ソフトウェアからのＲＤＢへのアクセスを支援する。

ここで、ＯＲＭツールでは、データアクセスの高速化も図られている。例えば、ＯＲＭツールに対して所定のオブジェクトが要求された時点で、当該オブジェクトと直接関連を持つ一次関連オブジェクトが次回の要求で要求される可能性が高い場合、一次関連オブジェクトを次回の要求までに取得してキャッシュする提案がある（例えば、特許文献１の段落［００３３］参照）。この提案では、次回の要求時にキャッシュを参照して応答することで、情報に高速にアクセスできる。

また、例えば、オブジェクトモデルの複数の要素を選択条件に基づいて選択し、選択された複数の要素を関連付けて１つのグループとしてＲＤＢの項目にマッピングすることで、処理の高速化を図る提案もある（例えば、特許文献２の段落［０１１１］〜［０１１２］参照）。

特開２００６−１５５２８７号公報 特開２００７−２４９３４５号公報

ところで、ＯＲＭツールではアクセス対象のテーブルごとに、テーブルの項目に設定するデータや、当該テーブルから取得したデータを格納するための所定のオブジェクトを個別に用意するのが一般的である。

しかし、この場合、アクセス対象のテーブルの追加・更新に柔軟に対応するのが困難であるという問題がある。例えば、テーブルの項目が変更されるとオブジェクトを修正する作業コストが生ずる。また、例えば、アクセス対象とするテーブルが増えるとオブジェクトを追加作成する作業コストが生ずる。

本発明はこのような点に鑑みてなされたものであり、ＲＤＢへのアクセス支援を効率的に行うことができるプログラム、情報処理装置およびアクセス支援方法を提供することを目的とする。

コンピュータが実行するプログラムであって、オブジェクト指向言語で開発されたソフトウェアから、複数の項目が定義された関係データベースのテーブルへのアクセスを支援するプログラムが提供される。このプログラムは、コンピュータに、キーおよび値の組み合わせを設定したオブジェクトとテーブルに対するクエリの雛型であって当該キーに対応する文字列を含むクエリの雛型を示す情報とを含むアクセス要求を受け付けると、記憶手段に記憶された、キーとテーブルの項目に応じたデータ型との対応関係をテーブルの項目ごとに定義したマッピング情報を参照して、文字列に対応するキーがマッピング情報に含まれる何れかのキーと一致するか判定し、マッピング情報に含まれる何れかのキーと一致すると判定すると、オブジェクトから当該キーに対応する値を取得し、クエリの雛型に含まれる文字列を当該キーに対応するデータ型の値に置換したクエリを生成し、生成した当該クエリを用いてテーブルにアクセスする、処理を実行させる。

また、オブジェクト指向言語で開発されたソフトウェアから、複数の項目が定義された関係データベースのテーブルへのアクセスを支援する情報処理装置が提供される。この情報処理装置は、記憶手段と生成手段とアクセス手段とを有する。記憶手段は、キーとテーブルの項目に応じたデータ型との対応関係をテーブルの項目ごとに定義したマッピング情報を記憶する。生成手段は、キーおよび値の組み合わせを設定したオブジェクトとテーブルに対するクエリの雛型であって当該キーに対応する文字列を含むクエリの雛型を示す情報とを含むアクセス要求を受け付けると、記憶手段に記憶されたマッピング情報を参照して、文字列に対応するキーがマッピング情報に含まれる何れかのキーと一致するか判定し、マッピング情報に含まれる何れかのキーと一致すると判定すると、オブジェクトから当該キーに対応する値を取得し、クエリの雛型に含まれる文字列を当該キーに対応するデータ型の値に置換したクエリを生成する。アクセス手段は、生成した当該クエリを用いてテーブルにアクセスする。

また、オブジェクト指向言語で開発されたソフトウェアから、複数の項目が定義された関係データベースのテーブルへのアクセスを支援する情報処理装置が実行するアクセス支援方法が提供される。

ＲＤＢへのアクセス支援を効率的に行うことができる。

第１の実施の形態の情報処理装置を示す図である。 第２の実施の形態の情報処理システムを示す図である。 第２の実施の形態のＯＲＭ提供側サーバのハードウェア例を示す図である。 第２の実施の形態のソフトウェア例を示す図である。 第２の実施の形態のオブジェクトの関連を示す図である。 第２の実施の形態のＥＭＰテーブルの例を示す図である。 第２の実施の形態のマッピング定義ファイルの例を示す図である。 第２の実施の形態のＳＱＬ定義ファイルの例を示す図である。 第２の実施の形態のマッピング定義画面の例を示す図である。 第２の実施の形態のＳＱＬ定義画面の例を示す図である。 第２の実施の形態の匿名オブジェクトの記述例を示す図である。 第２の実施の形態の個別オブジェクトの記述例を示す図である。 第２の実施の形態の個別オブジェクトの記述例（続き）を示す図である。 第２の実施の形態のユーザオブジェクトの記述例を示す図である。 第２の実施の形態のユーザオブジェクトの他の記述例を示す図である。 第２の実施の形態のＤＢアクセス要求を示すフローチャートである。 第２の実施の形態のＤＢアクセスを示すフローチャートである。 第２の実施の形態のＳＱＬ生成前処理を示すフローチャートである。 第２の実施の形態のプリペアドステートメントの例を示す図である。 第２の実施の形態のＳＱＬ生成を示すフローチャートである。 第２の実施の形態のＳＱＬの例を示す図である。 第２の実施の形態の結果オブジェクトの例を示す図である。 第３の実施の形態のマッピング定義ファイルの例を示す図である。 第３の実施の形態のＳＱＬ定義ファイルの例を示す図である。 第３の実施の形態のマッピング定義画面の例を示す図である。 第３の実施の形態の結果オブジェクト選択を示すフローチャートである。 第４の実施の形態のユーザオブジェクトの例を示す図である。 第４の実施の形態のＤＢアクセス要求を示すフローチャートである。 第４の実施の形態の自動生成されるＳＱＬ雛型の例を示す図である。 第５の実施の形態のＥＭＰテーブルの例を示す図である。 第５の実施の形態のＤＥＰＴテーブルの例を示す図である。 第５の実施の形態のマッピング定義ファイルの例を示す図である。 第５の実施の形態のＳＱＬ定義ファイルの例を示す図である。 第５の実施の形態のマッピング定義画面の例を示す図である。

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理装置を示す図である。情報処理装置１は、オブジェクト指向言語で開発されたソフトウェアから、複数の項目が定義された関係データベース（ＲＤＢ）２のテーブル２ａへのアクセスを支援する。具体的には、情報処理装置１は、オブジェクトを用いて入力されたデータを、テーブル２ａで扱う項目およびデータ型へ対応付けて（マッピング）、テーブル２ａへのアクセスを行う。なお、情報処理装置１は、ＣＰＵ（Central Processing Unit）などのプロセッサとＲＡＭ（Random Access Memory）などのメモリとを備えてもよく、メモリに記憶されたプログラムをプロセッサが実行するコンピュータであってもよい。情報処理装置１は、記憶手段１ａ、生成手段１ｂおよびアクセス手段１ｃを有する。

記憶手段１ａは、キーとテーブル２ａの項目に応じたデータ型との対応関係をテーブルの項目ごとに定義したマッピング情報３を記憶する。例えば、マッピング情報３には、キー“ｎｏ”、テーブル２ａの項目“ＮＯ”およびデータ型“数値”が対応付けられている。また、マッピング情報３には、キー“ｎａｍｅ”、テーブル２ａの項目“ＮＡＭＥ”およびデータ型“文字”が対応付けられている。ここで、キーは重複しない。記憶手段１ａは、テーブル２ａに対するクエリの雛型と当該クエリの雛型の識別情報とを対応付けた情報を記憶してもよい。記憶手段１ａは、ＲＡＭやＨＤＤ（Hard Disk Drive）によって実装されてもよい。

生成手段１ｂは、テーブル２ａへのアクセス要求４を受け付ける。アクセス要求４は、キーＭ１および値Ｍ２の組み合わせ（ペア）を一単位として設定したオブジェクト４ａを含む。オブジェクト４ａは、キーＭ１および値Ｍ２の集合を一単位として設定したものということもできる。オブジェクト４ａには、１またはそれ以上の組み合わせ（あるいは集合）を設定できる。キーＭ１は、マッピング情報３と値Ｍ２とを結びつけるための情報である。例えば、キーＭ１は“ｎａｍｅ”であり、値Ｍ２は“ＡＢＣ”である。キーＭ１および値Ｍ２が設定されてメモリ上に配置されたオブジェクト４ａをインスタンスと呼ぶことがある。

また、アクセス要求４は、テーブル２ａに対するクエリの雛型を示す情報４ｂを含む。クエリの雛型を示す情報４ｂは、クエリの雛型５に対応する情報である。クエリの雛型５は、クエリのテンプレートであり、例えば“ＳＥＬＥＣＴ ＮＯ ＦＲＯＭ ＴＡＢＬＥ ＷＨＥＲＥ ＮＡＭＥ ＝？ｎａｍｅ？”というＳＱＬの元となる文字列である。ここで、“ＴＡＢＬＥ”はテーブル２ａのテーブル名である。クエリの雛型５は、キーＭ１に対応する文字列Ｍ３を含む。例えば、文字列Ｍ３は“？ｎａｍｅ？”である。クエリの雛型を示す情報４ｂは、記憶手段１ａに記憶されたクエリの雛型５の識別情報でもよい。この場合、生成手段１ｂは、当該クエリの雛型を示す情報４ｂに基づいて、記憶手段１ａからクエリの雛型５を取得できる。また、クエリの雛型を示す情報４ｂは、クエリの雛型５そのものでもよい。

生成手段１ｂは、アクセス要求４を受け付けると、記憶手段１ａに記憶されたマッピング情報３を参照して、文字列Ｍ３に対応するキーＭ１がマッピング情報３に含まれる何れかのキーと一致するか判定する。例えば、キーＭ１が“ｎａｍｅ”の場合、マッピング情報３に含まれるキー“ｎａｍｅ”に一致する。この場合、生成手段１ｂは、キーＭ１がマッピング情報３に含まれるキーと一致すると判断する。

生成手段１ｂは、マッピング情報３に含まれる何れかのキーと一致すると判定すると、オブジェクト４ａから当該キーに対応する値を取得する。例えば、キーＭ１がマッピング情報３に含まれるキーと一致すると判断した場合、生成手段１ｂは、オブジェクト４ａからキーＭ１に対応する値Ｍ２を取得する。生成手段１ｂは、クエリの雛型５に含まれる文字列Ｍ３を当該キーＭ１に対応するデータ型の値Ｍ４に置換したクエリ６を生成する。ここで、値Ｍ４は、キーＭ１に対応するデータ型“文字”で値Ｍ２を記述した値である。例えば、クエリ６は、“ＳＥＬＥＣＴ ＮＯ ＦＲＯＭ ＴＡＢＬＥ ＷＨＥＲＥ ＮＡＭＥ ＝ ’ＡＢＣ’”というＳＱＬである。

アクセス手段１ｃは、生成手段１ｂが生成したクエリ６を用いてテーブル２ａにアクセスする。すると、アクセス手段１ｃは、アクセス結果７を得る。
生成手段１ｂは、アクセス手段１ｃからアクセス結果７を取得する。生成手段１ｂは、オブジェクト４ｃを用いて要求元のソフトウェア（または装置）に当該アクセス結果７を応答する。当該オブジェクト４ｃの何れのキー、データ型に対応付けるかはマッピング情報３に基づいて判断できる。ここで、オブジェクト４ｃは、オブジェクト４ａと同一のオブジェクトでもよいし、異なるオブジェクトでもよい。生成手段１ｂは、何れのオブジェクトで応答を得るかを指定する情報を、要求元のソフトウェアからアクセス要求４に含めて受け付けてもよい。

情報処理装置１によれば、生成手段１ｂにより、アクセス要求４が受け付けられると、記憶手段１ａに記憶されたマッピング情報３が参照されて、文字列Ｍ３に対応するキーＭ１がマッピング情報３に含まれる何れかのキーと一致するか判定される。生成手段１ｂにより、マッピング情報３に含まれる何れかのキーと一致すると判定されると、オブジェクト４ａから当該キーＭ１に対応する値Ｍ２が取得される。生成手段１ｂにより、クエリの雛型５に含まれる文字列Ｍ３を当該キーＭ１に対応するデータ型の値Ｍ４に置換したクエリ６が生成される。アクセス手段１ｃにより、生成した当該クエリを用いたテーブル２ａへのアクセスが行われる。

ここで、ＯＲＭツールでは、ＲＤＢ２へのアクセスを行う際に、テーブルごとに所定のオブジェクトを作成するのが一般的である。このようなオブジェクトでは、当該オブジェクトで利用する情報の単位である属性（テーブルの項目に対応するもの）ごとに属性値を設定するための操作や、属性値を取得するための操作を定義してテーブルへのアクセスに用いる。例えば、属性“ｎｏ”に対して設定用の操作“ｓｅｔＮｏ（・・・）”や取得用の操作“ｇｅｔＮｏ（）”を定義する。また、属性“ｎａｍｅ”に対して設定用の操作“ｓｅｔＮａｍｅ（・・・）”や取得用の操作“ｇｅｔＮａｍｅ（）”を、定義する。また、他のテーブルがあれば、当該他のテーブルに関しても同様にオブジェクトを定義する。しかし、このようにテーブルごと／テーブルの項目ごとにコーディングが発生すると、テーブルの追加や変更時の作業コストが問題となる。

そこで、情報処理装置１では、キーＭ１と値Ｍ２とをペアで設定可能なオブジェクト４ａを用いたアクセス要求４を許容する。マッピングの際には、オブジェクト４ａからキーＭ１に基づき値Ｍ２を取得し、クエリ６を生成できる。このため、属性ごとに属性値設定用の操作や属性値取得用の操作を定義する手間が省ける。また、アクセス先のテーブルが異なっても、マッピング情報３にテーブルごとの項目名とデータ型とを定義しておけば、何れのテーブルの定義を使用するかをオブジェクト４ａとともに指定することで、複数のテーブルに対してオブジェクト４ａを利用できる。このため、テーブルごとに別個のオブジェクトを定義する手間が省ける。

このように、汎用的なオブジェクト４ａを定義しておけば、複数のテーブルや複数の項目へのアクセスに利用できる。このため、テーブルの追加や変更時の作業コストを軽減し、ＲＤＢへのアクセス支援を効率的に行うことができる。その結果、システム開発の一層の効率化を図れる。

［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、あるシステムの開発に用いられる。第２の実施の形態の情報処理システムは、ＯＲＭ提供側サーバ１００およびＯＲＭ利用側サーバ２００を有する。ＯＲＭ提供側サーバ１００およびＯＲＭ利用側サーバ２００は、ネットワーク１０を介して接続されている。例えば、ネットワーク１０はＬＡＮ（Local Area Network）である。ネットワーク１０は、インターネットなどの広域ネットワークでもよい。

ＯＲＭ提供側サーバ１００は、ＲＤＢの利用環境をＯＲＭ利用側サーバ２００に提供するサーバコンピュータである。
ＯＲＭ利用側サーバ２００は、ソフトウェアの開発を行うためのサーバコンピュータである。ユーザは、ＯＲＭ利用側サーバ２００を操作して、システムの機能を実現するためのソフトウェアの開発（プログラムのコーディングやテストなど）を行う。ここで、ソフトウェアの開発は、オブジェクト指向言語を用いて行われるとする。オブジェクト指向言語として、ＪＡＶＡ（登録商標）を想定する。なお、以下の説明において「オブジェクト」という場合、ＯＲＭ提供側サーバ１００やＯＲＭ利用側サーバ２００のメモリ上に配置されたオブジェクトの実体（インスタンス）を含む。ただし、処理内容を明確にするために、オブジェクトのインスタンス化を明示することもある。

図３は、第２の実施の形態のＯＲＭ提供側サーバのハードウェア例を示す図である。ＯＲＭ提供側サーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、ディスクドライブ１０６および通信部１０７を有する。各ユニットがＯＲＭ提供側サーバ１００のバスに接続されている。ＯＲＭ利用側サーバ２００もＯＲＭ提供側サーバ１００と同様のハードウェアを用いて実装できる。

ＣＰＵ１０１は、ＯＲＭ提供側サーバ１００の情報処理を制御するプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されているプログラムやデータの少なくとも一部を読み出し、ＲＡＭ１０２に展開してプログラムを実行する。なお、ＯＲＭ提供側サーバ１００は、複数のプロセッサを設けて、プログラムを分散して実行してもよい。

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムや処理に用いるデータを一時的に記憶する揮発性メモリである。なお、ＯＲＭ提供側サーバ１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えていてもよい。

ＨＤＤ１０３は、ＯＳ（Operating System）プログラムやアプリケーションプログラムなどのプログラムおよびデータを記憶する不揮発性の記憶装置である。ＨＤＤ１０３は、ＣＰＵ１０１の命令にしたがって、内蔵の磁気ディスクに対してデータの読み書きを行う。なお、ＯＲＭ提供側サーバ１００は、ＨＤＤ以外の種類の不揮発性の記憶装置（例えば、ＳＳＤ（Solid State Drive）など）を備えてもよく、複数の記憶装置を備えていてもよい。

画像信号処理部１０４は、ＣＰＵ１０１の命令にしたがって、ＯＲＭ提供側サーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、例えば、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイを用いることができる。

入力信号処理部１０５は、ＯＲＭ提供側サーバ１００に接続された入力デバイス１２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス１２としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。

ディスクドライブ１０６は、記録媒体１３に記録されたプログラムやデータを読み取る駆動装置である。記録媒体１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。ディスクドライブ１０６は、例えば、ＣＰＵ１０１の命令にしたがって、記録媒体１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

通信部１０７は、ネットワーク１０を介してＯＲＭ利用側サーバ２００と通信を行う通信インタフェースである。通信部１０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。

図４は、第２の実施の形態のソフトウェア例を示す図である。図４に示すユニットの一部または全部は、ＯＲＭ提供側サーバ１００およびＯＲＭ利用側サーバ２００が実行するプログラムのモジュールである。ただし、図４に示すユニットの一部または全部は、ＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）などの電子回路であってもよい。

ＯＲＭ提供側サーバ１００は、記憶部１１０、ＲＤＢ１２０、ＧＵＩ（Graphical User Interface）提供部１３０、ＤＡＯ（Data Access Object）処理部１４０およびＯＲＭ処理部１５０を有する。

記憶部１１０は、マッピング定義ファイルおよびＳＱＬ定義ファイルを記憶する。マッピング定義ファイルは、オブジェクト指向言語（ここでは、ＪＡＶＡ）で扱うオブジェクトとＲＤＢのレコードとの対応関係を定義したファイルである。ＳＱＬ定義ファイルは、ＲＤＢに対する操作内容（クエリ）の雛型を定義したファイルである。ここで、第２の実施の形態ではクエリはＳＱＬで記述される。このため、ＳＱＬの雛型（ＳＱＬ雛型）は、クエリの雛型（クエリ雛型）と同義である。また、記憶部１１０は、ＧＵＩ提供部１３０、ＤＡＯ処理部１４０およびＯＲＭ処理部１５０を実現するためのプログラムを記憶する。記憶部１１０は、例えばＲＡＭ１０２上やＨＤＤ１０３上の記憶領域に実装される。

ＲＤＢ１２０は、ＯＲＭ利用側サーバ２００で開発されるソフトウェアがアクセス対象とするテーブルを記憶する。例えば、ＲＤＢ１２０はＨＤＤ１０３上の記憶領域に実装される。ＲＤＢ１２０には当該ＲＤＢ１２０を制御するＤＢＭＳ（DB Management System）が含まれる。ＲＤＢ１２０は、ＯＲＭ提供側サーバ１００に接続されたストレージ装置に格納されてもよい（この場合、ＤＢＭＳは例えばＯＲＭ提供側サーバ１００で実行する）。

ＧＵＩ提供部１３０は、マッピング定義およびＳＱＬ定義を入力するためのＧＵＩをＯＲＭ利用側サーバ２００に提供する。ＧＵＩ提供部１３０は、Ｗｅｂサーバ機能を有しており、ＯＲＭ利用側サーバ２００で動作するＷｅｂブラウザに当該ＧＵＩを提供できる。

ＤＡＯ処理部１４０は、ＯＲＭ利用側サーバ２００の要求に応じてＲＤＢ１２０に対するアクセス要求をＯＲＭ処理部１５０に出力する。アクセス要求は、ＲＤＢ１２０に対する所定の操作を行うための要求である。ＤＡＯ処理部１４０は、ＲＤＢ１２０に対して主要な操作を行うためのメソッドをＯＲＭ利用側サーバ２００に提供する。主要な操作とは、作成（Create）、読み出し（Read）、更新（Update）、削除（Delete）である（これらをまとめてＣＲＵＤ操作と呼ぶことがある）。ＯＲＭ利用側サーバ２００では、当該メソッドを利用することで、システム固有のロジックとＣＲＵＤ操作とを分離して開発できる。ただし、ＤＡＯ処理部１４０の機能は、ＯＲＭ利用側サーバ２００で開発されるソフトウェアの機能に含まれてもよい。ＤＡＯ処理部１４０は、ＲＤＢ１２０へのアクセス結果をＯＲＭ処理部１５０から取得し、ＵＰ（User Program）処理部２３０に応答する。

ＯＲＭ処理部１５０は、ＤＡＯ処理部１４０が出力したアクセス要求、記憶部１１０に記憶されたマッピング定義ファイルおよびＳＱＬ定義ファイルに基づいて、ＲＤＢ１２０のテーブルに対する操作内容を記述したＳＱＬを生成する。ＯＲＭ処理部１５０は、生成したＳＱＬを用いてＲＤＢ１２０のテーブルにアクセスする。ＯＲＭ処理部１５０は、アクセス結果をＤＡＯ処理部１４０に応答する。

ＯＲＭ利用側サーバ２００は、記憶部２１０、ブラウザ２２０およびＵＰ処理部２３０を有する。
記憶部２１０は、ブラウザ２２０およびＵＰ処理部２３０を実現するためのプログラムを記憶する。記憶部２１０は、例えばＯＲＭ利用側サーバ２００が備えるＲＡＭ上やＨＤＤ上の記憶領域に実装される。

ブラウザ２２０は、Ｗｅｂブラウザである。ユーザは、ブラウザ２２０が表示する画面を操作して、マッピング定義やＳＱＬ定義をＯＲＭ提供側サーバ１００に入力できる。
ＵＰ処理部２３０は、ＯＲＭ利用側サーバ２００で開発されるソフトウェアの機能の全部または一部である。ＵＰ処理部２３０は、ＤＡＯ処理部１４０が提供するＣＲＵＤ操作のメソッドを用いてＲＤＢ１２０へのアクセスをＯＲＭ提供側サーバ１００に依頼できる。

図５は、第２の実施の形態のオブジェクトの関連を示す図である。図５では、図４に示した各ユニットを実現するプログラムの関連を示している。
記憶部１１０には、マッピング定義ファイル１１１およびＳＱＬ定義ファイル１１２を記憶する。マッピング定義ファイル１１１のファイル名は、例えば“ＭａｐｐｉｎｇＣｏｎｆｉｇ”の文字列を含む。ＳＱＬ定義ファイル１１２のファイル名には、例えば“ＳＱＬＣｏｎｆｉｇ”の文字列を含む。

ＤＡＯ処理部１４０の機能は、ＤＡＯオブジェクト１４１により実現される。ＤＡＯオブジェクト１４１は、ＣＲＵＤ操作を行うためのメソッドを実装する。ＤＡＯオブジェクト１４１の名称を“ＰｒｏｖｉｄｅｒＤＡＯ”とする。

ＯＲＭ処理部１５０の機能は、ＯＲＭオブジェクト１５１により実現される。ＯＲＭオブジェクト１５１は、例えば検索系（レコードの検索）のクエリを実行するためのメソッドおよび更新系（レコードの登録、更新、削除など）のクエリを実行するためのメソッドの２種類のメソッドを実装する。ＯＲＭオブジェクト１５１の名称は“ＯＲＭＥｎｇｉｎｅ”とする。

ＵＰ処理部２３０の機能は、所定のユーザプログラムをＯＲＭ利用側サーバ２００のＣＰＵが実行することで実現される。ＵＰ処理部２３０のＲＤＢ１２０へのアクセス機能は、ユーザオブジェクト２３１により実現される。ユーザオブジェクト２３１では、どのようなマッピングルールで、どのようなＳＱＬを、どのような条件で実行するかを指定する。ユーザオブジェクト２３１の名称は“ＯＲＭＵｓｅｒ”とする。

ここで、ＲＤＢ１２０に対するアクセスは、ＵＰ処理部２３０が起点となる。このとき、ＵＰ処理部２３０は当該アクセスに係る条件を条件オブジェクトと呼ばれるオブジェクトに設定してＤＡＯ処理部１４０に渡す。条件オブジェクトは、クエリ条件を設定するためのオブジェクトである。条件オブジェクトに設定される情報は、ＲＤＢ１２０のテーブルの項目に対する条件である。ＤＡＯ処理部１４０は当該条件オブジェクトをアクセス要求３３０に含めて、ＯＲＭ処理部１５０に渡す。ＯＲＭ処理部１５０は、条件オブジェクトに設定された内容に基づいてＳＱＬを生成し、ＲＤＢ１２０へアクセスする。

また、ＯＲＭ処理部１５０はアクセス結果を結果オブジェクトに設定して、結果オブジェクトを含むＬｉｓｔオブジェクトなどをＤＡＯ処理部１４０に応答する（アクセス応答３４０）。

条件オブジェクトおよび結果オブジェクトには、２種類のオブジェクトを用い得る。第１のオブジェクトは、匿名オブジェクト３１０である。第２のオブジェクトは、個別オブジェクト３２０である。

匿名オブジェクト３１０は、キーと値との組み合わせ（ペア）を１単位の属性として保持可能なオブジェクトである。以下では、匿名オブジェクト３１０の名称を“Ａｎｏｎｙｍｏｕｓ”とする。例えば、キーの設定は当該組み合わせを単位として行われる。値の取得はキーを指定することで行われる。より具体的には、“ｎａｍｅ”（名前）というキーに対して“ＹＡＭＡＤＡ”という値を設定する場合、設定用の操作内容を定義したメソッド“Ａｎｏｎｙｍｏｕｓ＃ｓｅｔＶａｌｕｅ（“ｎａｍｅ”，“ＹＡＭＡＤＡ”）”を実行する。ここで、“Ａｎｏｎｙｍｏｕｓ＃”は、“ｓｅｔＶａｌｕｅ（）”が匿名オブジェクト３１０のメソッドであることを示す（以下、同様）。また、例えば、“ｅｍｐＮｏ”（従業員番号）というキーの値を取得したい場合、取得用の操作内容を定義したメソッド“Ａｎｏｎｙｍｏｕｓ＃ｇｅｔＶａｌｕｅ（“ｅｍｐＮｏ”）”を実行する。すると、“ｅｍｐＮｏ”をキーに、匿名オブジェクト３１０から対応する値を取得できる。

ここで、匿名オブジェクト３１０では、システム開発に用いる言語でのデータの型（開発言語型ということがある）の取り扱いを考慮して、値のデータ型を意識したメソッドを提供する。

例えば、キー“ｎａｍｅ”に対して文字列型（Ｓｔｒｉｎｇ）の値を設定するために、文字列型で値を設定するためのメソッド“Ａｎｏｎｙｍｏｕｓ＃ｓｅｔＶａｌｕｅＡｓＳｔｒｉｎｇ（“ｎａｍｅ”，“ＹＡＭＡＤＡ”）”を実装する。また、キー“ｅｍｐＮｏ”に対して数値型（Ｉｎｔｅｇｅｒ）の値を取得するために、数値型で値を取得するためのメソッド“Ａｎｏｎｙｍｏｕｓ＃ｇｅｔＶａｌｕｅＡｓＩｎｔｅｇｅｒ（“ｅｍｐＮｏ”）”を実装する。このようにすれば、ＪＡＶＡのようにタイプセーフ（型に厳格）な言語でのシステム開発を円滑に行える。

個別オブジェクト３２０は、アクセス対象とするテーブルの項目に対応する属性を個々のデータとして保持し、各データに対する属性値の設定・取得に係る操作を個別に提供するオブジェクトである。以下では、個別オブジェクト３２０の名称を“Ｅｍｐｌｏｙｅｅ”とする。個別オブジェクト３２０を用いるとき、“ｎａｍｅ”という属性名に対して“ＹＡＭＡＤＡ”という属性値を設定する場合、当該属性への設定用のメソッド“Ｅｍｐｌｏｙｅｅ＃ｓｅｔＮａｍｅ（“ＹＡＭＡＤＡ”）”を実行する。また、例えば、“ｅｍｐＮｏ”という属性名の属性値を取得したい場合、取得用のメソッド“Ｅｍｐｌｏｙｅｅ＃ｇｅｔＥｍｐＮｏ（）”を実行する。

ここで、匿名オブジェクト３１０で扱うキーは、個別オブジェクト３２０で扱う属性の属性名に対応付けられる。以下の説明では、匿名オブジェクト３１０のキーと個別オブジェクト３２０の属性名とが同一であれば、ＲＤＢ１２０のテーブルの同一の項目に対応付けるとする。このため、匿名オブジェクト３１０に設定する組み合わせのキーに相当する情報を、便宜的に「属性名」と呼ぶこととする。また、匿名オブジェクト３１０に設定する組み合わせの値に相当する情報を、便宜的に「属性値」と呼ぶこととする。

アクセス要求３３０は、ＤＡＯ処理部１４０からＯＲＭ処理部１５０へのデータの引き渡しに利用されるコンテキスト情報である。当該アクセス要求３３０を実現するオブジェクトの名称を“ＯＲＭＣｏｎｔｅｘｔ”とする。

アクセス応答３４０は、ＯＲＭ処理部１５０からＤＡＯ処理部１４０へのＲＤＢ１２０へのアクセス結果の応答である。例えば、ＯＲＭ処理部１５０が検索系の処理を行った場合、アクセス結果のレコードを結果オブジェクトにマッピングし、当該結果オブジェクトをＬｉｓｔオブジェクトなどに格納してＤＡＯ処理部１４０へ応答する。また、例えば、ＯＲＭ処理部１５０が更新系の処理を行った場合、処理件数を示す情報をＤＡＯ処理部１４０へ応答する。

なお、以上で説明した、ＤＡＯオブジェクト１４１、ＯＲＭオブジェクト１５１、匿名オブジェクト３１０、個別オブジェクト３２０、アクセス要求３３０およびアクセス応答３４０は、ＯＲＭ提供側サーバ１００上のＪＡＶＡの実行環境で実現される。また、ユーザオブジェクト２３１、匿名オブジェクト３１０および個別オブジェクト３２０は、ＯＲＭ利用側サーバ２００上のＪＡＶＡの実行環境で実現される。

図６は、第２の実施の形態のＥＭＰテーブルの例を示す図である。ＥＭＰテーブル１２１は、ＲＤＢ１２０に格納される。ＥＭＰテーブル１２１は、ＥＭＰＮＯ、ＮＡＭＥ、ＳＥＸ、ＨＩＲＥＤＡＴＥおよびＳＡＬＡＲＹの項目を含む。

ＥＭＰＮＯの項目には、従業員番号が登録される。ＮＡＭＥの項目には、従業員の名前が登録される。ＳＥＸの項目には、性別が設定される。ＨＩＲＥＤＡＴＥの項目には、就業日が設定される。ＳＡＬＡＲＹの項目には、月当たりの給料が設定される。

例えば、１人の従業員に対して、ＥＭＰＮＯが“１”、ＮＡＭＥが“ＹＡＭＡＤＡ”、ＳＥＸが“Ｍａｌｅ”、ＨＩＲＥＤＡＴＥが“１９９８０４０１”、ＳＡＬＡＲＹが“３５００００”が登録されている。

図７は、第２の実施の形態のマッピング定義ファイルの例を示す図である。マッピング定義ファイル１１１は、記憶部１１０に記憶される。マッピング定義ファイル１１１のファイル名は、例えば、“ＭａｐｐｉｎｇＣｏｎｆｉｇ．ｘｍｌ”である。拡張子“．ｘｍｌ”は、マッピング定義ファイル１１１がＸＭＬ（Extensible Markup Language）形式で記述されていることを示す。以下、マッピング定義ファイル１１１の各行の左側に付した番号（行番号）を用いて、各行の記述を指し示す（図８以降に説明する各ファイルも同様）。

マッピング定義ファイル１１１では、ユーザが登録したマッピング定義を要素＜ｅｎｔｒｙ＞と子要素＜ｉｔｅｍ＞とで表現している。以下では、オブジェクトで用いる属性の用語と区別するため、ＸＭＬの記述においてタグ内に定義される属性をタグ属性と呼ぶこととする。

要素＜ｅｎｔｒｙ＞は、次のタグ属性を持つ。
（１）ｉｄ：マッピング定義を識別するためのマッピングＩＤ（IDentifier）。
（２）ｔａｂｌｅ：アクセス対象のテーブルの名称。

（３）ｃｌａｓｓ：テーブルへのアクセスに用いるオブジェクトを指定する情報。
要素の定義は、３行目に対応している。マッピング定義ファイル１１１の例では、３行目〜１２行目がマッピングＩＤ“ＭＡＰＰＩＮＧ００１”に対応する１つのマッピング定義を示す。

子要素＜ｉｔｅｍ＞は、次のタグ属性を持つ。
（１）ａｔｔｒｉｂｕｔｅ：属性名。
（２）ｔｙｐｅ：開発言語型。

（３）ｃｏｌｕｍｎ：テーブルの項目（カラム）名。
（４）ｄｂｔｙｐｅ：ＤＢＭＳデータ型。ＤＢＭＳで扱うためのデータ型である。
（５）ｓｉｚｅ：データサイズ（桁）。

子要素の定義は、４行目〜１１行目に対応している。
ここで、９行目〜１１行目には、ＥＭＰテーブル１２１に存在しない項目に対する属性が定義されている。具体的には、“ｗｓａｌａｒｙ”、“ｓｅｌｅｃｔＩｔｅｍｓ”および“ａｄｄＣｏｎｄｉｔｉｏｎ”の属性名の属性である。これらは、マッピング以外の用途に用いる属性であり、これらを「任意属性」と呼ぶこととする。すなわち、マッピング定義においてｃｏｌｕｍｎに“＊”や“＠”が設定されている属性が任意属性である。ｃｏｌｕｍｎに“＊”が設定された任意属性はバインド属性であり、後述するＳＱＬ雛型に含まれ得るバインド変数に対応している。ｃｏｌｕｍｎに“＠”が設定された任意属性は単純置換属性であり、後述するＳＱＬ雛型に含まれ得る単純置換変数に対応している。なお、バインド変数は、ＳＱＬ実行時に具体的な値を設定することを示す変数である。単純置換変数は、単に文字列に置換可能な変数である。単純置換変数に代入する値は文字列型である。バインド属性と単純置換属性とは、用途に応じて使い分けることができる。使い分けの詳細は後述する。また、任意属性以外の通常のバインド属性（ＥＭＰテーブル１２１の項目名が対応付けられたもの）を「通常属性」と呼ぶこととする。通常属性もＳＱＬ雛型に含まれ得るバインド変数に対応するものである。

図８は、第２の実施の形態のＳＱＬ定義ファイルの例を示す図である。ＳＱＬ定義ファイル１１２は、記憶部１１０に記憶される。ＳＱＬ定義ファイル１１２のファイル名は、例えば、“ＳＱＬＣｏｎｆｉｇ．ｘｍｌ”である。ＳＱＬ定義ファイル１１２では、ユーザが登録したＳＱＬ雛型を要素＜ｅｎｔｒｙ＞で表現している。

要素＜ｅｎｔｒｙ＞は、次のタグ属性を持つ。
（１）ｉｄ：ＳＱＬ雛型を識別するためのクエリＩＤ。
（２）ｃｌａｓｓ：テーブルへのアクセスに用いるオブジェクトを指定する情報。

また、要素の内容（＜ｅｎｔｒｙ＞および＜／ｅｎｔｒｙ＞で囲われた部分）がＳＱＬ雛型を示す。なお、ＳＱＬ定義ファイル１１２では、“＜”記号は文字列“＆ｌｔ；”に、“＞”は文字列“＆ｇｔ；”にエスケープしている。

ＳＱＬ雛型には、マッピング定義ファイル１１１で定義される属性名に対応する文字列（属性名の最初と最後に“？”を付加したもの）が含まれる。この文字列は変数を示す。
例えば、クエリＩＤ“ＳＥＬＥＣＴ００１”のＳＱＬ雛型（４行目）は、属性名“ｅｍｐＮｏ”に対応する文字列“？ｅｍｐＮｏ？”を含む。マッピング定義ファイル１１１によれば“ｅｍｐＮｏ”は通常属性である。これに対する文字列“？ｅｍｐＮｏ？”はバインド変数である。

また、クエリＩＤ“ＳＥＬＥＣＴ００３”のＳＱＬ雛型（１０行目）は、属性名“ｓｅｌｅｃｔＩｔｅｍｓ”に対応する文字列“？ｓｅｌｅｃｔＩｔｅｍｓ？”を含む。マッピング定義ファイル１１１によれば“ｓｅｌｅｃｔＩｔｅｍｓ”は単純置換属性である。これに対する文字列“？ｓｅｌｅｃｔＩｔｅｍｓ？”は単純置換変数である。また、当該ＳＱＬ雛型は、属性名“ａｄｄＣｏｎｄｉｔｉｏｎ”に対応する文字列“？ａｄｄＣｏｎｄｉｔｉｏｎ？”を含む。マッピング定義ファイル１１１によれば“ａｄｄＣｏｎｄｉｔｉｏｎ”は単純置換属性である。これに対する文字列“？ａｄｄＣｏｎｄｉｔｉｏｎ？”は単純置換変数である。

更に、クエリＩＤ“ＵＰＤＡＴＥ００２”のＳＱＬ雛型（１６行目）は、属性名“ｗｓａｌａｒｙ”に対応する文字列“？ｗｓａｌａｒｙ？”を含む。マッピング定義ファイル１１１によれば“ｗｓａｌａｒｙ”は任意属性のバインド属性である。これに対する文字列“？ｗｓａｌａｒｙ？”はバインド変数である。

図９は、第２の実施の形態のマッピング定義画面の例を示す図である。マッピング定義画面４１０は、ブラウザ２２０によりＯＲＭ利用側サーバ２００に接続されたディスプレイに表示される。ブラウザ２２０は、ＧＵＩ提供部１３０が提供する所定のＷｅｂページを示すＵＲＬ（Uniform Resource Locator）にアクセスすることで、ＯＲＭ提供側サーバ１００からマッピング定義画面４１０の情報を取得できる。ユーザは、マッピング定義画面４１０を操作して、アクセス対象のテーブル（ＥＭＰテーブル１２１）のマッピング定義をＯＲＭ提供側サーバ１００に入力できる。

マッピング定義画面４１０には、マッピング定義入力領域４１１、作成ボタン４１２およびダウンロードボタン４１３が含まれる。ユーザは、ＯＲＭ利用側サーバ２００に接続されたポインティングデバイスを操作することで、ポインタＰ１を操作して、何れかの入力領域およびボタンに対する選択操作やボタン押下操作を行える（図１０以降に示す画面の説明でも同様である）。

マッピング定義入力領域４１１は、マッピング定義を入力するための領域である。マッピング定義入力領域４１１の入力内容は、マッピング定義ファイル１１１のマッピングＩＤ“ＭＡＰＰＩＮＧ００１”のマッピング定義に対応している。マッピング定義入力領域４１１には、入力ボックスＣ１，Ｃ２，Ｃ３および入力ボックス群Ｃ４が設けられている。

入力ボックスＣ１は、マッピングＩＤを入力するための領域である。入力ボックスＣ１には、ＧＵＩ提供部１３０がマッピングＩＤを自動採番してもよい。例えば、ＧＵＩ提供部１３０は、記憶部１１０に記憶されたマッピング定義ファイル１１１を参照して、使用済のマッピングＩＤの最大値を取得し、当該最大値よりも大きな値を、新たなマッピング定義に採番することが考えられる。

入力ボックスＣ２は、ＲＤＢ１２０へのアクセスに用いるオブジェクト（条件／結果オブジェクトとして使用するオブジェクト）の名称を入力するための領域である。個別オブジェクトを使用する場合、入力ボックスＣ２に“Ｅｍｐｌｏｙｅｅ”などの名称を入力する。匿名オブジェクトを使用する場合、入力ボックスＣ２を未入力（“−”）とする。または、入力ボックスＣ２に“Ａｎｏｎｙｍｏｕｓ”を入力してもよい。

入力ボックスＣ３は、アクセス対象テーブルの名称を入力するための領域である。ＥＭＰテーブル１２１の名称は“ＥＭＰ”である。
入力ボックス群Ｃ４は、ＯＲＭ利用側サーバ２００のソフトウェアで扱うデータの日本語名称および型の日本語名称、入力ボックスＣ２で指定されたオブジェクトで扱うデータの属性名およびデータの型（開発言語型）、入力ボックスＣ３で指定されたテーブル上でのデータの項目名とデータの型（ＤＢＭＳ型）とサイズ（桁）との対応関係を入力するための領域である。開発言語型は、ここでは属性値をＪＡＶＡで扱うためのデータ型である。なお、アクセス対象テーブルのＤＢＭＳ型およびサイズ（桁）の設定は任意である。

作成ボタン４１２は、マッピング定義入力領域４１１に入力された情報に基づいて、マッピング定義ファイル１１１に対するマッピング定義（ここではマッピングＩＤ“ＭＡＰＰＩＮＧ００１”）の登録と個別オブジェクト３２０の生成を、ＧＵＩ提供部１３０に実行させるためのボタンである。ブラウザ２２０は、作成ボタン４１２の押下を受け付けると、マッピング定義入力領域４１１に入力された情報をＧＵＩ提供部１３０に送信する。ＧＵＩ提供部１３０は、ブラウザ２２０から取得した情報に基づいて、マッピング定義ファイル１１１にマッピング定義を追加する。入力ボックスＣ２に個別オブジェクトのオブジェクト名が入力された場合、マッピング定義の“ｃｌａｓｓ”のタグ属性に、当該個別オブジェクトを指定する情報を登録すると共にオブジェクト（クラスファイル）を自動生成（例えば、属性の設定［取得］メソッド名を「ｓｅｔ［ｇｅｔ］＋属性名の先頭を大文字にしたもの」とルール化することで実現可能である）して記憶部１１０に配置する。入力ボックスＣ２にオブジェクト名が入力されなかった場合（または、匿名オブジェクトの名称“Ａｎｏｎｙｍｏｕｓ”が入力された場合）、マッピング定義の“ｃｌａｓｓ”のタグ属性に、匿名オブジェクト３１０を指定する情報を登録する。

ダウンロードボタン４１３は、ＯＲＭ提供側サーバ１００から個別オブジェクト３２０をダウンロードするためのボタンである。ＧＵＩ提供部１３０は、ダウンロードボタン４１３の押下に応じた要求に対して、自動生成した個別オブジェクト３２０をＯＲＭ利用側サーバ２００に提供する。ダウンロードした個別オブジェクト３２０は記憶部２１０に配置し、ＯＲＭ利用側サーバ２００上のプログラム（ＵＰ処理部２３０）から利用できるようにしておく。尚、匿名オブジェクト３１０は、予め記憶部１１０と記憶部２１０に配置しておき、ＯＲＭ利用側サーバ２００で実行されるプログラム（ＵＰ処理部２３０）およびＯＲＭ提供側サーバ１００で実行されるプログラム（ＤＡＯ処理部１４０、ＯＲＭ処理部１５０）から利用できるようにしておく。

図１０は、第２の実施の形態のＳＱＬ定義画面の例を示す図である。ＳＱＬ定義画面４２０は、ブラウザ２２０によりＯＲＭ利用側サーバ２００に接続されたディスプレイに表示される。ブラウザ２２０は、ＧＵＩ提供部１３０が提供する所定のＷｅｂページを示すＵＲＬにアクセスすることで、ＯＲＭ提供側サーバ１００からＳＱＬ定義画面４２０の情報を取得できる。ユーザは、ＳＱＬ定義画面４２０を操作して、アクセス対象のテーブル（ここではＥＭＰテーブル１２１）に対するＳＱＬ雛型をＯＲＭ利用側サーバ２００に入力できる。ＳＱＬ定義画面４２０には、ＳＱＬ定義入力領域４２１および作成ボタン４２２が含まれる。

ＳＱＬ定義入力領域４２１は、ＳＱＬ雛型に関する情報を入力するための領域である。ＳＱＬ定義入力領域４２１の入力内容は、ＳＱＬ定義ファイル１１２のクエリＩＤ“ＳＥＬＥＣＴ００３”のＳＱＬ雛型に対応している。ＳＱＬ定義入力領域４２１には、入力ボックスＣ５，Ｃ６，Ｃ７が設けられている。

入力ボックスＣ５は、クエリＩＤを入力するための領域である。クエリＩＤは、ＧＵＩ提供部１３０が自動採番してもよい。例えば、ＧＵＩ提供部１３０は、記憶部１１０に記憶されたＳＱＬ定義ファイル１１２を参照して、使用済のクエリＩＤの最大値を取得し、当該最大値よりも大きな値を、新たなＳＱＬ雛型に採番することが考えられる。

入力ボックスＣ６は、ＲＤＢ１２０へのアクセスに用いるオブジェクトの名称を入力するための領域である。個別オブジェクトを使用する場合、入力ボックスＣ６に“Ｅｍｐｌｏｙｅｅ”などの名称を入力する。匿名オブジェクト３１０を使用する場合、入力ボックスＣ６を未入力（“−”）とする。または、入力ボックスＣ６に“Ａｎｏｎｙｍｏｕｓ”を入力してもよい。

入力ボックスＣ７は、ＳＱＬ雛型の文字列を入力するための領域である。
作成ボタン４２２は、ＳＱＬ定義入力領域４２１に入力された情報に基づいて、ＳＱＬ定義ファイル１１２に対するＳＱＬ定義の登録を、ＧＵＩ提供部１３０に実行させるためのボタンである。ブラウザ２２０は、作成ボタン４２２の押下を受け付けると、ＳＱＬ定義入力領域４２１に入力された情報をＧＵＩ提供部１３０に送信する。ＧＵＩ提供部１３０は、ブラウザ２２０から取得した情報に基づいて、ＳＱＬ定義ファイル１１２にＳＱＬ雛型を追加する。なお、入力ボックスＣ６に個別オブジェクトのオブジェクト名が入力された場合、ＳＱＬ雛型の“ｃｌａｓｓ”のタグ属性には、当該個別オブジェクトを指定する情報が登録される。また、入力ボックスＣ６にオブジェクト名が入力されていない場合（または、匿名オブジェクトの名称“Ａｎｏｎｙｍｏｕｓ”が入力された場合）、ＳＱＬ雛型の“ｃｌａｓｓ”のタグ属性には、匿名オブジェクトを指定する情報が登録される。

図１１は、第２の実施の形態の匿名オブジェクトの記述例を示す図である。匿名オブジェクト３１０のオブジェクトファイルは、記憶部１１０，２１０に記憶される。図１１では匿名オブジェクト３１０のソースプログラム“Ａｎｏｎｙｍｏｕｓ．ｊａｖａ”（一部）を例示している。

匿名オブジェクト３１０では、属性名（キー）と属性値（値）とを組み合わせて扱うためにＭａｐを用いる（９行目）。ただし、同様のキーと値との組み合わせを扱えるＭａｐ以外の他のオブジェクトを用いてもよい。

匿名オブジェクト３１０の新たなインスタンスを作成する（１１行目〜１３行目）。
更に、指定された属性名に対応する属性値を所定の型で設定するための次のようなメソッドが実装される。

１５行目〜１９行目に記述されたメソッド“ｓｅｔＶａｌｕｅＡｓＳｔｒｉｎｇ（Ｓｔｒｉｎｇ ｎａｍｅ，Ｓｔｒｉｎｇ ｖａｌｕｅ）”は、属性名に対応する属性値を文字列型で設定するためのメソッドである。このような属性値の設定用のメソッドは、Ｓｅｔｔｅｒメソッドと呼ばれることもある。

２７行目〜３１行目に記述されたメソッド“ｓｅｔＶａｌｕｅＡｓＩｎｔｅｇｅｒ（Ｓｔｒｉｎｇ ｎａｍｅ，Ｉｎｔｅｇｅｒ ｖａｌｕｅ）”は、属性名に対応する属性値を数値型で設定するためのメソッドである。

３９行目に記述されたメソッド“ｓｅｔＶａｌｕｅＡｓＤａｔｅ（Ｓｔｒｉｎｇ ｎａｍｅ，Ｄａｔｅ ｖａｌｕｅ）”は、属性名に対応する属性値を日付型で設定するためのメソッドである。

４２行目に記述されたメソッド“ｓｅｔＶａｌｕｅ（Ｓｔｒｉｎｇ ｎａｍｅ，Ｏｂｊｅｃｔ ｖａｌｕｅ）”は、属性名に対応する属性値を任意の型として設定するためのメソッドである。なお、３９行目および４２行目のメソッドに関しては、１５行目〜１９行目および２７行目〜３１行目のメソッドと記述形式が同様であるため、図示を省略している。

また、指定された属性名に対応する属性値を所定の型で取得するための次のようなメソッドが実装される。
２１行目〜２５行目に記述されたメソッド“ｇｅｔＶａｌｕｅＡｓＳｔｒｉｎｇ（Ｓｔｒｉｎｇ ｎａｍｅ）”は、属性名に対応する属性値を文字列型で取得するためのメソッドである。このような属性値の取得用のメソッドは、Ｇｅｔｔｅｒメソッドと呼ばれることもある。

３３行目〜３７行目に記述されたメソッド“ｇｅｔＶａｌｕｅＡｓＩｎｔｅｇｅｒ（Ｓｔｒｉｎｇ ｎａｍｅ）”は、属性名に対応する属性値を数値型で取得するためのメソッドである。

４０行目に記述されたメソッド“ｇｅｔＶａｌｕｅＡｓＤａｔｅ（Ｓｔｒｉｎｇ ｎａｍｅ）”は、属性名に対応する属性値を日付型で取得するためのメソッドである。
４３行目に記述されたメソッド“ｇｅｔＶａｌｕｅ（Ｓｔｒｉｎｇ ｎａｍｅ）”は、属性名に対応する属性値を任意の型で取得するためのメソッドである。なお、４０行目および４３行目のメソッドに関しては、２１行目〜２５行目および３３行目〜３７行目のメソッドと記述形式が同様であるため、図示を省略している。

なお、例えばＭａｐへの非同期アクセスを防いでデータ整合性を確保するために、属性値の設定・取得前に同期処理“ｓｙｎｃｈｒｏｎｉｚｅｄ（ａｔｔｒＳｅｔ）”を行う。
次に、個別オブジェクト３２０のプログラムの記述例を説明する。

図１２は、第２の実施の形態の個別オブジェクトの記述例を示す図である。個別オブジェクト３２０のオブジェクトファイルは、記憶部１１０，２１０に記憶される。図１２では個別オブジェクト３２０のソースプログラム“Ｅｍｐｌｏｙｅｅ．ｊａｖａ”（一部）を例示している。

個別オブジェクト３２０では、属性名とデータ型とを定義する（５行目〜１２行目）。個別オブジェクト３２０の新たなインスタンスを作成する（１４行目〜１５行目）。
更に、各属性に値を設定するための次のようなメソッドが実装される。例えば、メソッド“ｓｅｔＥｍｐＮｏ（Ｉｎｔｅｇｅｒ ｅｍｐＮｏ）”（１７行目〜１９行目）は、属性“ｅｍｐＮｏ”への属性値（数値型）を設定するためのメソッドである。また、例えば、メソッド“ｓｅｔＮａｍｅ（Ｓｔｒｉｎｇ ｎａｍｅ）”（２５行目〜２７行目）は、属性“ｎａｍｅ”への属性値（文字列型）を設定するためのメソッドである。“ｓｅｔＳｅｘ（Ｓｔｒｉｎｇ ｓｅｘ）”（３３行目）、“ｓｅｔＨｉｒｅＤａｔｅ（Ｄａｔｅ ｈｉｒｅＤａｔｅ）”（３６行目）および“ｓｅｔＳａｌａｒｙ（Ｉｎｔｅｇｅｒ ｓａｌａｒｙ）”（３９行目）の各メソッドも同様である。

また、各属性から値を取得するための次のようなメソッドが実装される。例えば、メソッド“ｇｅｔＥｍｐＮｏ（）”（２１行目〜２３行目）は、属性“ｅｍｐＮｏ”から属性値（数値型）を取得するためのメソッドである。また、例えば、メソッド“ｇｅｔＮａｍｅ（）”（２９行目〜３１行目）は、属性“ｎａｍｅ”から属性値（文字列型）を取得するためのメソッドである。“ｇｅｔＳｅｘ（）”（３４行目）、“ｇｅｔＨｉｒｅＤａｔｅ（）”（３７行目）および“ｇｅｔＳａｌａｒｙ（）”（４０行目）の各メソッドも同様である。

図１３は、第２の実施の形態の個別オブジェクトの記述例（続き）を示す図である。個別オブジェクト３２０には、任意属性に対する属性値の設定用のメソッドも実装される。例えば、メソッド“ｓｅｔＷｓａｌａｒｙ（Ｉｎｔｅｇｅｒ ｗｓａｌａｒｙ）”（４３行目〜４５行目）は、属性“ｗｓａｌａｒｙ”への属性値（数値型）を設定するためのメソッドである。また、メソッド“ｓｅｔＳｅｌｅｃｔＩｔｅｍｓ（Ｓｔｒｉｎｇ ｓｅｌｅｃｔＩｔｅｍｓ）”（５１行目〜５３行目）は、属性“ｓｅｌｅｃｔＩｔｅｍｓ”への属性値（文字列型）を設定するためのメソッドである。また、メソッド“ｓｅｔＡｄｄＣｏｎｄｉｔｉｏｎ（Ｓｔｒｉｎｇ ａｄｄＣｏｎｄｉｔｉｏｎ）”（５９行目〜６１行目）は、属性“ａｄｄＣｏｎｄｉｔｉｏｎ”への属性値（文字列型）を設定するためのメソッドである。

更に、個別オブジェクト３２０には、任意属性に対する属性値の取得用のメソッドを実装する。例えば、メソッド“ｇｅｔＷｓａｌａｒｙ（）”（４７行目〜４９行目）は、属性“ｗｓａｌａｒｙ”からの属性値（数値型）を取得するためのメソッドである。また、メソッド“ｇｅｔＳｅｌｅｃｔＩｔｅｍｓ（）”（５５行目〜５７行目）は、属性“ｓｅｌｅｃｔＩｔｅｍｓ”からの属性値（文字列型）を取得するためのメソッドである。また、メソッド“ｇｅｔＡｄｄＣｏｎｄｉｔｉｏｎ（）”（６３行目〜６５行目）は、属性“ａｄｄＣｏｎｄｉｔｉｏｎ”からの属性値（文字列型）を取得するためのメソッドである。このようにして、個別オブジェクト３２０でも任意属性を扱えるようにする。

以上のように、個別オブジェクト３２０では属性ごと（テーブルの項目ごと）に操作用のメソッドを定義するのに対し、匿名オブジェクト３１０では属性名と属性値とのペアに対して属性値のデータ型ごとの操作を行うメソッドを定義する点が異なる。

図１４は、第２の実施の形態のユーザオブジェクトの記述例を示す図である。ユーザオブジェクト２３１のオブジェクトファイルは、記憶部２１０に記憶される。図１４ではユーザオブジェクト２３１のソースプログラム“ＯＲＭＵｓｅｒ．ｊａｖａ”（一部）を例示している。ユーザオブジェクト２３１は、ＥＭＰテーブル１２１に対して、ＳＱＬ定義ファイル１１２で定義されたクエリＩＤ“ＳＥＬＥＣＴ００３”を用いたアクセス（検索）を依頼するものである。当該依頼を行うメソッド“ｓｅｌｅｃｔ００３ＵｓｉｎｇＡｎｏｎｙｍｏｕｓ（ｄａｏ）；”（６行目）は、９行目〜１６行目に記述されている。“ｄａｏ”はＤＡＯオブジェクト１４１のインスタンスである。ユーザオブジェクト２３１は、所定のリモートコールにより、ＤＡＯオブジェクト１４１を利用できる。

メソッド“ｓｅｌｅｃｔ００３ＵｓｉｎｇＡｎｏｎｙｍｏｕｓ（ＰｒｏｖｉｄｅｒＤＡＯ ｄａｏ）”では、匿名オブジェクト３１０をインスタンス化（インスタンス名“ｃｏｎｄｉｔｉｏｎ”）して条件オブジェクトとする（１０行目）。匿名オブジェクト３１０に対して、属性名“ｅｍｐＮｏ”と数値型の属性値“１”とのペアを設定する（１１行目）。また、属性名“ｓｅｘ”と文字列型の属性値“Ｍａｌｅ”とのペアを設定する（１２行目）。更に、属性名“ｓｅｌｅｃｔＩｔｅｍｓ”と文字列型の属性値“ＥＭＰＮＯ，ＮＡＭＥ”とのペアを設定する（１３行目）。

そして、マッピングＩＤ“ＭＡＰＰＩＮＧ００１”、クエリＩＤ“ＳＥＬＥＣＴ００３”、上記３種類のペアを設定した匿名オブジェクト３１０を指定して、検索用のｆｉｎｄメソッドの実行をＤＡＯオブジェクト１４１に依頼する。Ｌｉｓｔオブジェクトでアクセス結果を取得する（１４行目）。アクセス結果を示すメッセージ（ログ）を標準出力する（１５行目）。

なお、ｆｉｎｄメソッドに渡す４つ目の引数は結果オブジェクトの情報（“Ａｎｏｎｙｍｏｕｓ．ｃｌａｓｓ”）を示している。当該情報は省略してもよい。第２の実施の形態では、当該結果オブジェクトの情報に関わらず、条件オブジェクトと同一種類の結果オブジェクトでアクセス応答を返すためである。例えば、条件オブジェクトが匿名オブジェクト３１０であれば、結果オブジェクトも匿名オブジェクト３１０とする。

次に、個別オブジェクト３２０を用いてＲＤＢ１２０へのアクセスをＯＲＭ提供側サーバ１００に依頼するユーザオブジェクトの他の記述例を説明する。
図１５は、第２の実施の形態のユーザオブジェクトの他の記述例を示す図である。ユーザオブジェクト２３１ａのオブジェクトファイルは、記憶部２１０に記憶される。図１５ではユーザオブジェクト２３１ａのソースプログラム“ＯＲＭＵｓｅｒ２．ｊａｖａ”（一部）を例示している。ユーザオブジェクト２３１ａは、ＥＭＰテーブル１２１に対して、ＳＱＬ定義ファイル１１２で定義されたクエリＩＤ“ＳＥＬＥＣＴ００３”を用いたアクセス（検索）を依頼するものである。当該依頼を行うメソッド“ｓｅｌｅｃｔ００３ＵｓｉｎｇＥｍｐｌｏｙｅｅ（ｄａｏ）”（６行目）は、９行目〜１６行目に記述されている。

メソッド“ｓｅｌｅｃｔ００３ＵｓｉｎｇＥｍｐｌｏｙｅｅ（ｄａｏ）”では、個別オブジェクト３２０をインスタンス化（インスタンス名“ｃｏｎｄｉｔｉｏｎ”）して条件オブジェクトとする（１０行目）。個別オブジェクト３２０に対して、属性“ｅｍｐＮｏ”に数値型の属性値“１”を設定する（１１行目）。個別オブジェクト３２０に対して、属性“ｓｅｘ”に文字列型の属性値“Ｍａｌｅ”を設定する（１２行目）。個別オブジェクト３２０に対して、属性“ｓｅｌｅｃｔＩｔｅｍｓ”に文字列型の属性値“ＥＭＰＮＯ，ＮＡＭＥ”を設定する（１３行目）。

そして、マッピングＩＤ“ＭＡＰＰＩＮＧ００１”、クエリＩＤ“ＳＥＬＥＣＴ００３”、上記３つの属性に対する属性値を設定した個別オブジェクト３２０を指定して、検索用のｆｉｎｄメソッドの実行をＤＡＯオブジェクト１４１に依頼する。Ｌｉｓｔオブジェクトでアクセス結果を取得する（１４行目）。アクセス結果を示すメッセージ（ログ）を標準出力する（１５行目）。

なお、ｆｉｎｄメソッドに対して渡されている４つ目の引数（結果オブジェクトの情報）は、匿名オブジェクト３１０の場合と同様に省略してもよい。
次に、以上の構成の情報処理システムの処理手順を説明する。まず、ＵＰ処理部２３０とＤＡＯ処理部１４０との間の処理手順を説明する。ＲＤＢ１２０へアクセスするユーザオブジェクトとして、図１４，図１５で説明したユーザオブジェクト２３１，２３１ａを想定する。

図１６は、第２の実施の形態のＤＢアクセス要求を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。
（ステップＳ１１）ＵＰ処理部２３０は、ユーザオブジェクト２３１（または、ユーザオブジェクト２３１ａ）で指定された条件オブジェクトが個別オブジェクト３２０であるか否かを判定する。個別オブジェクト３２０である場合、処理をステップＳ１２に進める。個別オブジェクト３２０でない場合、処理をステップＳ１４に進める。例えば、ユーザオブジェクト２３１ａの場合、“Ｅｍｐｌｏｙｅｅ”（“Ａｎｏｎｙｍｏｕｓ”以外のオブジェクト名）が条件オブジェクトに用いられている。この場合、条件オブジェクトは個別オブジェクト３２０である。また、ユーザオブジェクト２３１の場合、匿名オブジェクト３１０として予め定義された“Ａｎｏｎｙｍｏｕｓ”が条件オブジェクトに用いられている。この場合、条件オブジェクトは匿名オブジェクト３１０である。

（ステップＳ１２）ＵＰ処理部２３０は、個別オブジェクト３２０（“Ｅｍｐｌｏｙｅｅ”）をインスタンス化する。
（ステップＳ１３）ＵＰ処理部２３０は、ユーザオブジェクト２３１ａで指定された属性値を個別オブジェクト３２０の各属性に設定する。ＵＰ処理部２３０は、ユーザオブジェクト２３１ａで指定されたマッピングＩＤ、クエリＩＤおよび属性値を設定した個別オブジェクト３２０をＤＡＯ処理部１４０に送信する。このとき、ＵＰ処理部２３０は、ユーザオブジェクト２３１ａで指定されるメソッド（ここでは、ｆｉｎｄメソッド）の実行をＤＡＯ処理部１４０に依頼する。そして、処理をステップＳ１６に進める。

（ステップＳ１４）ＵＰ処理部２３０は、匿名オブジェクト３１０（“Ａｎｏｎｙｍｏｕｓ”）をインスタンス化する。
（ステップＳ１５）ＵＰ処理部２３０は、ユーザオブジェクト２３１で指定された属性名と属性値とのペアを匿名オブジェクト３１０に設定する。ＵＰ処理部２３０は、ユーザオブジェクト２３１で指定されたマッピングＩＤ、クエリＩＤおよび属性名／属性値のペアを設定した匿名オブジェクト３１０をＤＡＯ処理部１４０に送信する。このとき、ＵＰ処理部２３０は、ユーザオブジェクト２３１で指定されるメソッド（ここでは、ｆｉｎｄメソッド）の実行をＤＡＯ処理部１４０に依頼する。

（ステップＳ１６）ＤＡＯ処理部１４０は、ＵＰ処理部２３０から依頼された処理内容（ここでは、検索系のｆｉｎｄ）に応じてＲＤＢ１２０へのアクセス要求３３０を生成し、ＯＲＭ処理部１５０に出力する。このとき、ＤＡＯ処理部１４０は、依頼された処理内容に応じたＯＲＭ処理部１５０のメソッド（例えば、検索系のＳＱＬを実行するためのメソッド）を呼び出す。アクセス要求３３０は、ＵＰ処理部２３０から依頼されたマッピングＩＤ、クエリＩＤおよび条件オブジェクトを含む。

（ステップＳ１７）ＯＲＭ処理部１５０は、アクセス要求３３０に基づいて、条件オブジェクトのＳＱＬ雛型へのマッピングを行い、生成したＳＱＬを用いてＲＤＢ１２０へアクセスする。ＯＲＭ処理部１５０は、Ｌｉｓｔなどを用いて生成したアクセス応答３４０（アクセス結果を含むもの）をＤＡＯ処理部１４０に返す。

（ステップＳ１８）ＤＡＯ処理部１４０は、ＯＲＭ処理部１５０から取得したアクセス結果をＵＰ処理部２３０に応答する。ＵＰ処理部２３０は、アクセス結果を示すメッセージを標準出力する。

このようにして、ＯＲＭ利用側サーバ２００からＯＲＭ提供側サーバ１００のＲＤＢ１２０へのアクセスが行われる。次に、上記ステップＳ１７のＤＢアクセス処理の手順を説明する。

図１７は、第２の実施の形態のＤＢアクセスを示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。
（ステップＳ２１）ＯＲＭ処理部１５０は、記憶部１１０に記憶されたマッピング定義ファイル１１１に基づいて、アクセス要求３３０に設定されたマッピングＩＤに対応するマッピング定義を取得する。ユーザオブジェクト２３１の例でいえば、マッピングＩＤは“ＭＡＰＰＩＮＧ００１”である。この場合、ＯＲＭ処理部１５０は、マッピング定義ファイル１１１の要素＜ｅｎｔｒｙ＞の“ｉｄ”のタグ属性が“ＭＡＰＰＩＮＧ００１”に一致するマッピング定義を取得する。

（ステップＳ２２）ＯＲＭ処理部１５０は、記憶部１１０に記憶されたＳＱＬ定義ファイル１１２に基づいて、アクセス要求３３０に設定されたクエリＩＤに対応するＳＱＬ雛型を取得する。ユーザオブジェクト２３１の例でいえば、クエリＩＤは“ＳＥＬＥＣＴ００３”である。この場合、ＯＲＭ処理部１５０は、ＳＱＬ定義ファイル１１２の要素＜ｅｎｔｒｙ＞の“ｉｄ”のタグ属性が“ＳＥＬＥＣＴ００３”に一致するＳＱＬ雛型を取得する。

（ステップＳ２３）ＯＲＭ処理部１５０は、ＳＱＬ雛型および条件オブジェクトに設定された単純置換属性を用いてプリペアドステートメントを生成する。プリペアドステートメントとは、ＲＤＢ１２０のＤＢＭＳに事前にキャッシュさせる命令文である。

（ステップＳ２４）ＯＲＭ処理部１５０は、プリペアドステートメント、条件オブジェクトに設定された任意属性のバインド属性および通常属性を用いてＳＱＬを完成させる。
（ステップＳ２５）ＯＲＭ処理部１５０は、生成したＳＱＬを用いてＲＤＢ１２０へのアクセスを実行する。ＯＲＭ処理部１５０は、アクセス内容に応じたアクセス結果を得る。例えば、検索（ｆｉｎｄ）であれば検索結果を示すレコードを得る。また、登録（ｉｎｓｅｒｔやｃｒｅａｔｅ）であれば登録完了件数を得る。また、更新（ｕｐｄａｔｅ）であれば更新完了件数を得る。更に、削除（ｄｅｌｅｔｅ）であれば削除完了件数を得る。

（ステップＳ２６）ＯＲＭ処理部１５０は、結果オブジェクトを用いてアクセス結果をＤＡＯ処理部１４０に応答するかを判定する。結果オブジェクトを用いる場合、処理をステップＳ２７に進める。結果オブジェクトを用いない場合、処理をステップＳ２９に進める。結果オブジェクトを用いる場合とは、例えばアクセス結果として検索結果のレコードを得る場合である。結果オブジェクトを用いない場合とは、例えばアクセス結果として処理件数（登録完了件数、更新完了件数および削除完了件数の何れか）を得る場合である。

（ステップＳ２７）ＯＲＭ処理部１５０は、条件オブジェクトと同一のオブジェクトを結果オブジェクトとする。ＯＲＭ処理部１５０は、結果オブジェクトをインスタンス化する。ＯＲＭ処理部１５０は、検索結果のレコードを結果オブジェクトにマッピングする。結果オブジェクトに対するマッピングの具体例は図２２で説明する。ＯＲＭ処理部１５０は、結果オブジェクトをＬｉｓｔオブジェクトに設定する。

（ステップＳ２８）ＯＲＭ処理部１５０は、ＬｉｓｔオブジェクトをＤＡＯ処理部１４０に応答する（アクセス応答３４０に対応する）。そして、処理を終了する。
（ステップＳ２９）ＯＲＭ処理部１５０は、処理件数をＤＡＯ処理部１４０に応答する（アクセス応答３４０に対応する）。そして、処理を終了する。

このようにして、ＯＲＭ処理部１５０は、アクセス要求３３０に対するアクセス応答３４０を行う。ここで、ＯＲＭ処理部１５０は、上記ステップＳ２３，Ｓ２４で示したようにＳＱＬの生成を２段階で行う。すなわち、まず、プリペアドステートメントによりＳＱＬの文法を予め定義する。次に、当該プリペアドステートメントに値をセットして実行する。これにより、ＤＢＭＳによるＳＱＬ文の解析処理の負担を軽減でき、ＲＤＢ１２０へのアクセスにつきスループットの向上を図れる。次に、このようなＳＱＬ生成の手順を説明する。まず、上記ステップＳ２３のＳＱＬ生成の前処理の手順を説明する。

図１８は、第２の実施の形態のＳＱＬ生成前処理を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。
（ステップＳ３１）ＯＲＭ処理部１５０は、ステップＳ２２で取得したＳＱＬ雛型に単純置換変数が含まれているか否かを判定する。単純置換変数が含まれている場合、処理をステップＳ３２に進める。単純置換変数が含まれていない場合、処理をステップＳ３６に進める。例えば、クエリＩＤ“ＳＥＬＥＣＴ００３”の例でいえば、文字列“？ｓｅｌｅｃｔＩｔｅｍｓ？”や“？ａｄｄＣｏｎｄｉｔｉｏｎ？”は単純置換変数である。この場合、ＯＲＭ処理部１５０は、ＳＱＬ雛型に単純置換変数が含まれていると判断する。

（ステップＳ３２）ＯＲＭ処理部１５０は、条件オブジェクトとして個別オブジェクト３２０が指定されているか否かを判定する。個別オブジェクト３２０が指定されている場合、処理をステップＳ３３に進める。個別オブジェクト３２０が指定されていない場合、処理をステップＳ３４に進める。ステップＳ１１と同様に、ＯＲＭ処理部１５０は、条件オブジェクトの名称に基づいて、当該条件オブジェクトが個別オブジェクト３２０であるか否かを判断できる。

（ステップＳ３３）ＯＲＭ処理部１５０は、個別オブジェクト３２０から単純置換変数の属性値を取得する。例えば、“ｓｅｌｅｃｔＩｔｅｍｓ”であれば、“ｇｅｔＳｅｌｅｃｔＩｔｅｍｓ（）”メソッドを実行して当該属性値を取得できる。また、“ａｄｄＣｏｎｄｉｔｉｏｎ”はユーザオブジェクト２３１ａで値がセットされていないため、“ｇｅｔＡｄｄＣｏｎｄｉｔｉｏｎ（）”メソッドを実行しても値は取得されない。そして、処理をステップＳ３５に進める。

（ステップＳ３４）ＯＲＭ処理部１５０は、匿名オブジェクト３１０から単純置換変数の属性値を取得する。例えば、“ｓｅｌｅｃｔＩｔｅｍｓ”であれば、“ｇｅｔＶａｌｕｅＡｓＳｔｒｉｎｇ（“ｓｅｌｅｃｔＩｔｅｍｓ”）”メソッドを実行して当該属性値を取得できる。

（ステップＳ３５）ＯＲＭ処理部１５０は、ＳＱＬ雛型の単純置換変数をステップＳ３３またはステップＳ３４で取得した文字列型の属性値に置換する。単純置換変数に対応する属性値を取得していない場合には、当該単純置換変数の箇所は空欄となる。

（ステップＳ３６）ＯＲＭ処理部１５０は、ＳＱＬ雛型にバインド変数があるか否かを判定する。バインド変数がある場合、処理をステップＳ３７に進める。バインド変数がない場合、ＳＱＬ雛型をＲＤＢ１２０のＤＢＭＳに出力し、処理を終了する。

（ステップＳ３７）ＯＲＭ処理部１５０は、ＳＱＬ雛型に含まれるバインド変数をプレースホルダに変換する。ここで、プレースホルダは、ＤＢＭＳで事後的に値をセットする箇所を示す文字として許容される文字であり、例えばＳＱＬでは“？”の文字が用いられる。これにより、ＳＱＬ雛型に基づくプリペアドステートメントが完成する。ＯＲＭ処理部１５０が生成したプリペアドステートメントはＲＤＢ１２０のＤＢＭＳでキャッシュされる。

このようにして、ＯＲＭ処理部１５０はプリペアドステートメントを生成する。
なお、ステップＳ３６において、ＳＱＬ雛型にバインド属性がないと判定された場合、ＲＤＢ１２０のＤＢＭＳに出力されるＳＱＬの情報は、ＳＱＬの完成形である。

図１９は、第２の実施の形態のプリペアドステートメントの例を示す図である。ＳＱＬ雛型５０１は、クエリＩＤ“ＳＥＬＥＣＴ００３”に対応するＳＱＬ雛型の内容を示したものである。ＳＱＬ雛型５０１は、図１７のステップＳ２２でＯＲＭ処理部１５０により取得される。プリペアドステートメント５０２は、図１８のステップＳ３６の処理後の状態であり、ＳＱＬ雛型５０１に基づいてＯＲＭ処理部１５０により生成されたプリペアドステートメントである。

例えば、匿名オブジェクト３１０を用いる場合、ＯＲＭ処理部１５０は、次のようにしてプリペアドステートメント５０２を生成する。
ＯＲＭ処理部１５０は、単純置換属性“ｓｅｌｅｃｔＩｔｅｍｓ”および“ａｄｄＣｏｎｄｉｔｉｏｎ”をＳＱＬ雛型５０１から抽出する。単純置換属性の属性名は、単純置換変数から両側の文字“？”を除外した文字列である。ＯＲＭ処理部１５０は、匿名オブジェクト３１０が提供するメソッドにより、単純置換属性の各属性名をキーに、匿名オブジェクト３１０から属性値を取得する。ユーザオブジェクト２３１による匿名オブジェクト３１０への設定内容によれば、メソッド“ｇｅｔＶａｌｕｅＡｓＳｔｒｉｎｇ（“ｓｅｌｅｃｔＩｔｅｍｓ”）”により“ｓｅｌｅｃｔＩｔｅｍｓ”に対し“ＥＭＰＮＯ，ＮＡＭＥ”を得る。また、メソッド“ｇｅｔＶａｌｕｅＡｓＳｔｒｉｎｇ（“ａｄｄＣｏｎｄｉｔｉｏｎ”）”により“ａｄｄＣｏｎｄｉｔｉｏｎ”に対する属性値は得られない。よって、ＯＲＭ処理部１５０は、単純置換変数“？ｓｅｌｅｃｔＩｔｅｍｓ？”を文字列型の“ＥＭＰＮＯ，ＮＡＭＥ”に置換する。また、単純置換変数“？ａｄｄＣｏｎｄｉｔｉｏｎ？”を設定なし（空欄）とする。

更に、ＯＲＭ処理部１５０は、バインド変数“？ｅｍｐＮｏ？”および“？ｓｅｘ？”をプレースホルダ“？”に置換する。このようにして、プリペアドステートメント５０２を生成する。

なお、個別オブジェクト３２０を用いる場合、個別オブジェクト３２０から属性値を取得するために用いるメソッドが異なる。例えば、属性“ｓｅｌｅｃｔＩｔｅｍｓ”であれば“ｇｅｔＳｅｌｅｃｔＩｔｅｍｓ（）”を用いる。属性“ａｄｄＣｏｎｄｉｔｉｏｎ”であれば“ｇｅｔＡｄｄＣｏｎｄｉｔｉｏｎ（）”を用いる。

なお、ＯＲＭ処理部１５０は、何れのプレースホルダが、何れの属性名に対応するかを保持する。例えば、プリペアドステートメント５０２の最初の（紙面の左側から数えて１つ目の）プレースホルダ“？”は、属性名“ｅｍｐＮｏ”に対応する。また、２番目の（紙面の左側から数えて２つ目の）プレースホルダ“？”は、属性名“ｓｅｘ”に対応する。

このように、単純置換変数を用いて、プリペアドステートメント５０２で代入しておくべき文字列（ここでは、“ＥＭＰＮＯ，ＮＡＭＥ”の部分）を容易に指定可能となる。当該単純置換変数の部分にプレースホルダなどが含まれると、プリペアドステートメントが不完全となり、ＤＢＭＳの文法チェックでエラーとなることがある。単純置換変数によって、当該単純置換変数の部分を適切に文字列型の条件に置換することで、このようなエラーを回避できる。

次に、プリペアドステートメントに基づいてＳＱＬを完成させる処理を説明する。
図２０は、第２の実施の形態のＳＱＬ生成を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。

（ステップＳ４１）ＯＲＭ処理部１５０は、プリペアドステートメントにプレースホルダがあるか否かを判定する。プレースホルダがある場合、処理をステップＳ４２に進める。プレースホルダがない場合、処理を終了する。なお、図１８のステップＳ３６でＳＱＬの完成形が得られている場合には、当該ＳＱＬ生成に係る以降の処理をスキップして処理を終了する。

（ステップＳ４２）ＯＲＭ処理部１５０は、プレースホルダに対応する属性名がマッピング定義で定義されているか否かを判定する。定義されている場合、処理をステップＳ４３に進める。定義されていない場合、処理をステップＳ４８に進める。複数のプレースホルダがある場合、全てのプレースホルダに対応する属性名がマッピング定義で定義されている場合に、処理をステップＳ４３に進める。何れかのプレースホルダに対応する属性名がマッピング定義に定義されていない場合は、処理をステップＳ４８に進める。

（ステップＳ４３）ＯＲＭ処理部１５０は、ステップＳ４２で判定した各属性名に対応する開発言語型（マッピング定義の“ｔｙｐｅ”のタグ属性の設定）を取得する。
（ステップＳ４４）ＯＲＭ処理部１５０は、条件オブジェクトとして個別オブジェクト３２０が指定されているか否かを判定する。個別オブジェクト３２０が指定されている場合、処理をステップＳ４５に進める。個別オブジェクト３２０が指定されていない場合、処理をステップＳ４６に進める。ステップＳ１１と同様に、ＯＲＭ処理部１５０は、条件オブジェクトの名称に基づいて、当該条件オブジェクトが個別オブジェクト３２０であるか否かを判断できる。

（ステップＳ４５）ＯＲＭ処理部１５０は、個別オブジェクト３２０からステップＳ４２で判定した各属性の属性値を取得する。例えば、“ｅｍｐＮｏ”であれば、“ｇｅｔＥｍｐＮｏ（）”メソッドを実行して当該属性値“１”を取得できる。そして、処理をステップＳ４７に進める。

（ステップＳ４６）ＯＲＭ処理部１５０は、匿名オブジェクト３１０からステップＳ４２で判定した各属性名に対応する属性値を取得する。例えば、“ｅｍｐＮｏ”であれば、ｇｅｔＶａｌｕｅＡｓＩｎｔｅｇｅｒ（“ｅｍｐＮｏ”）”メソッドを実行して当該属性値“１”を取得できる。なお、数値型用や文字列型用など何れのメソッドを用いるかは、ステップＳ４３で取得した開発言語型による。例えば、属性名“ｅｍｐＮｏ”に対応する開発言語型（“ｔｙｐｅ”のタグ属性）は“Ｉｎｔｅｇｅｒ”なので、“ｇｅｔＶａｌｕｅＡｓＩｎｔｅｇｅｒ（“ｅｍｐＮｏ”）”を用いる。

（ステップＳ４７）ＯＲＭ処理部１５０は、プリペアドステートメントのプレースホルダをステップＳ４５またはステップＳ４６で取得した属性値で置換する。このとき、ステップＳ４３で取得されたデータ型で当該属性値を挿入する。プリペアドステートメント５０２の例でいえば、最初のプレースホルダ“？”は属性名“ｅｍｐＮｏ”に対応している。よって、最初のプレースホルダ“？”を数値型の“１”に置換する。また、２番目のプレースホルダ“？”は属性名“ｓｅｘ”に対応している。よって、２番目のプレースホルダ“？”を文字列型の“Ｍａｌｅ”に置換する。これにより、ＳＱＬが完成する。

（ステップＳ４８）ＯＲＭ処理部１５０は、ＳＱＬ生成エラーをＤＡＯ処理部１４０に応答する。ＤＡＯ処理部１４０は、当該エラーをＵＰ処理部２３０に通知する。そして、処理を終了する。

このようにして、ＯＲＭ処理部１５０はＳＱＬを生成する。
なお、ステップＳ４３では、開発言語型（マッピング定義の“ｔｙｐｅ”のタグ属性）を取得するものとした。これは、ＲＤＢ１２０のＤＢＭＳが提供するドライバプログラム（Ｊａｖａの場合、ＪＤＢＣドライバ）が、開発言語型で入力された値をＤＢＭＳデータ型に自動的に変換してＳＱＬを実行するためである。

図２１は、第２の実施の形態のＳＱＬの例を示す図である。ＳＱＬ５０３は、プリペアドステートメント５０２に基づいて生成されたＳＱＬである。ＳＱＬ５０３は、ステップＳ４７の処理後の状態である。

匿名オブジェクト３１０および個別オブジェクト３２０を用いる場合の何れも、プリペアドステートメント５０２を生成したときと同様にして、プレースホルダ“？”に代入する属性値を取得できる。例えば、プリペアドステートメント５０２の最初のプレースホルダ“？”は、属性名“ｅｍｐＮｏ”に対応する。よって、匿名オブジェクト３１０を用いる場合は、“ｇｅｔＶａｌｕｅＡｓＩｎｔｅｇｅｒ（ｅｍｐＮｏ）”メソッドを実行すればよい。各プレースホルダは、マッピング定義ファイル１１１で定義された、（各プレースホルダに対応する属性名の）開発言語型の属性値に置換される。

このように、ＳＱＬ生成を２段階で行うことで、上述したようにＲＤＢ１２０へのアクセスのスループット向上を図れる。特に、同様のアクセス処理を何度も実行する場合に有効である。

また、通常属性に係るバインド変数に加えて任意属性に係るバインド変数を利用できる。このため、ＥＭＰテーブル１２１の同一項目に対して２つ以上の条件を与えたい場合にも１つのインスタンスで対応できる。例えば、ＳＱＬ定義ファイル１１２ではクエリＩＤ“ＵＰＤＡＴＥ００２”のＳＱＬ雛型が定義されている。当該ＳＱＬ雛型では、“ＳＡＬＡＲＹ”の項目につき“？ｓａｌａｒｙ？”および“？ｗｓａｌａｒｙ？”の２種類の属性値を設定することができる。これらは、匿名オブジェクト３１０または個別オブジェクト３２０の１つのインスタンスで設定可能である。一方、任意属性に係るバインド変数が利用できない場合は、例えば、更新値用（“？ｓａｌａｒｙ？”に相当）のインスタンスと、検索条件用（“？ｗｓａｌａｒｙ？”に相当）のインスタンスと、を別個に作成することが考えられる。しかし、複数のインスタンスを作成することになり、メモリ使用量が増大し得る。これに対し、任意属性のバインド変数を利用可能とすることで、作成するインスタンス数を軽減でき、メモリ使用量を低減できる。

ＯＲＭ処理部１５０は、検索処理を行った場合、アクセス結果として得たレコードを結果オブジェクトにマッピングして、ＤＡＯ処理部１４０に応答する。ＤＡＯ処理部１４０は、当該結果オブジェクトをＵＰ処理部２３０に応答する。

図２２は、第２の実施の形態の結果オブジェクトの例を示す図である。図２２では、ＥＭＰテーブル１２１に対してＳＱＬ５０３を実行したときのアクセス結果を例示している。図２２（Ａ）はＯＲＭ処理部１５０によって得られた検索結果レコード群１２１ａを示す。

図２２（Ｂ）は結果オブジェクトに匿名オブジェクト３１０を用いる場合を示している。この場合、ＳＱＬ５０３では項目“ＥＭＰＮＯ”および“ＮＡＭＥ”の設定値を取得するものとしている。ＯＲＭ処理部１５０は、マッピング定義ファイル１１１（マッピングＩＤ“ＭＡＰＰＩＮＧ００１”のマッピング定義）に基づき、検索結果レコード群１２１ａの各レコードの項目“ＥＭＰＮＯ”および“ＮＡＭＥ”の設定値を匿名オブジェクト３１０にマッピングする。

具体的には、当該マッピング定義によれば、項目名“ＥＭＰＮＯ”に対応する属性名は“ｅｍｐＮｏ”であり、開発言語型は“Ｉｎｔｅｇｅｒ”である。また、項目名“ＮＡＭＥ”に対応する属性名は“ｎａｍｅ”であり、開発言語型は“Ｓｔｒｉｎｇ”である。この情報を基に１つ目の検索結果レコードにつき、結果オブジェクトとして匿名オブジェクト３１１を生成する。匿名オブジェクト３１１には、属性名“ｅｍｐＮｏ”と数値型の属性値“３”とのペアおよび属性名“ｎａｍｅ”と文字列型の属性値“ＳＵＺＵＫＩ”とのペアを設定する。設定のために実行するメソッドは、“ｓｅｔＶａｌｕｅＡｓＩｎｔｅｇｅｒ（“ｅｍｐＮｏ”，３）”および“ｓｅｔＶａｌｕｅＡｓＳｔｒｉｎｇ（“ｎａｍｅ”，“ＳＵＺＵＫＩ”）”である。

また、２つ目の検索結果レコードにつき、結果オブジェクトとして匿名オブジェクト３１２を生成する。匿名オブジェクト３１２には、属性名“ｅｍｐＮｏ”と数値型の属性値“４”とのペアおよび属性名“ｎａｍｅ”と文字列型の属性値“ＩＮＡＢＡ”とのペアを設定する。設定のために実行するメソッドは、“ｓｅｔＶａｌｕｅＡｓＩｎｔｅｇｅｒ（“ｅｍｐＮｏ”，４）”および“ｓｅｔＶａｌｕｅＡｓＳｔｒｉｎｇ（“ｎａｍｅ”，“ＩＮＡＢＡ”）”である。

図２２（Ｃ）は結果オブジェクトに個別オブジェクト３２０を用いる場合を示している。ＯＲＭ処理部１５０は、マッピング定義ファイル１１１（マッピングＩＤ“ＭＡＰＰＩＮＧ００１”のマッピング定義）に基づき、検索結果レコード群１２１ａの各レコードの項目“ＥＭＰＮＯ”および“ＮＡＭＥ”の設定値を個別オブジェクト３２０にマッピングする。

具体的には、１つ目の検索結果レコードにつき、結果オブジェクトとして個別オブジェクト３２１を生成する。個別オブジェクト３２１には、属性名“ｅｍｐＮｏ”の属性に数値型の属性値“３”を、属性名“ｎａｍｅ”の属性に文字列型の属性値“ＳＵＺＵＫＩ”を設定する。実行するメソッドは、“ｓｅｔＥｍｐＮｏ（３）”および“ｓｅｔＮａｍｅ（“ＳＵＺＵＫＩ”）”である。

また、２つ目の検索結果レコードにつき、結果オブジェクトとして個別オブジェクト３２２を生成する。個別オブジェクト３２２には、属性名“ｅｍｐＮｏ”の属性に数値型の属性値“４”を、属性名“ｎａｍｅ”の属性に文字列型の属性値“ＩＮＡＢＡ”を設定する。実行するメソッドは、“ｓｅｔＥｍｐＮｏ（４）”および“ｓｅｔＮａｍｅ（“ＩＮＡＢＡ”）”である。

個別オブジェクト３２１，３２２の他の属性の設定値は、設定なし（“−”）となる。
なお、結果オブジェクトに属性値を設定する際に、ＥＭＰテーブル１２１から実際に取得したＤＢＭＳデータ型と、マッピング定義ファイル１１１に定義されたＤＢＭＳデータ型と、が整合しているかをチェックしてもよい。例えば、実際に取得した“ＥＭＰＮＯ”のＤＢＭＳデータ型が“ＶＡＲＣＨＡＲ”であり、マッピング定義の“ｅｍｐＮｏ”のＤＢＭＳデータ型（“ｄｂｔｙｐｅ”のタグ属性）が“ＩＮＴＥＧＥＲ”であれば、両者のデータ型の不整合を検出する。不整合の場合にエラーを発するようにすれば、意図しないマッピングを未然に防ぐことができ、定義などの見直しをユーザに促すことができる。

ＲＤＢ１２０へのアクセスを行うにあたっては、アクセス対象とするテーブル毎に個別オブジェクト３２０を作成しても構わない。しかし、テーブルが増えればオブジェクトの管理に係るコストやテーブル追加・変更時の作業コストが問題になる。匿名オブジェクト３１０を提供することにより、こうしたコストを軽減し、ＲＤＢ１２０へのアクセス支援を効率的に行うことができる。その結果、システム開発の一層の効率化が図れる。

［第３の実施の形態］
以下、第３の実施の形態を説明する。前述の第２の実施の形態との相違点を主に説明し、同様の事項の説明を省略する。

第２の実施の形態では、条件オブジェクトと同じオブジェクトを結果オブジェクトとして用いるものとした。一方、ＥＭＰテーブル１２１に対する個別オブジェクト３２０を作成した場合に、匿名オブジェクト３１０と使い分け可能としてもよい。例えば、条件オブジェクトに匿名オブジェクト３１０を利用し、結果オブジェクトに個別オブジェクト３２０を利用してもよい。また、例えば、条件オブジェクトに個別オブジェクト３２０を利用し、結果オブジェクトに匿名オブジェクト３１０を利用してもよい。匿名オブジェクト３１０および個別オブジェクト３２０の何れを結果オブジェクトに用いるかユーザが選択できれば、システム開発をより柔軟化できる。そこで、第３の実施の形態では、匿名オブジェクト３１０および個別オブジェクト３２０を使い分け可能とする機能を提供する。

ここで、第３の実施の形態の情報処理システム、ＯＲＭ提供側サーバおよびＯＲＭ利用側サーバのハードウェア／ソフトウェアの構成は、図２〜図４で説明した第２の実施の形態の情報処理システム、ＯＲＭ提供側サーバ１００およびＯＲＭ利用側サーバ２００の構成と同様である。第３の実施の形態では、第２の実施の形態と同一の符号・名称を用いて、同一の構成を指し示すものとする。

図２３は、第３の実施の形態のマッピング定義ファイルの例を示す図である。マッピング定義ファイル１１１ａは、記憶部１１０に記憶される。マッピング定義ファイル１１１ａは、第２の実施の形態で説明したマッピング定義ファイル１１１に対応する（マッピング定義ファイル１１１に代えて利用される）。第３の実施の形態では、ＥＭＰテーブル１２１に対する個別オブジェクト３２０を作成している。このため、要素＜ｅｎｔｒｙ＞の“ｃｌａｓｓ”のタグ属性の設定がマッピング定義ファイル１１１と異なる。マッピング定義ファイル１１１ａでは、“ｃｌａｓｓ”のタグ属性に個別オブジェクト３２０を示す情報が設定される。

図２４は、第３の実施の形態のＳＱＬ定義ファイルの例を示す図である。ＳＱＬ定義ファイル１１２ａは、記憶部１１０に記憶される。ＳＱＬ定義ファイル１１２ａは、第２の実施の形態で説明したＳＱＬ定義ファイル１１２に対応する（ＳＱＬ定義ファイル１１２に代えて利用される）。マッピング定義ファイル１１１ａと同様に、ＳＱＬ定義ファイル１１２ａでは、要素＜ｅｎｔｒｙ＞の“ｃｌａｓｓ”のタグ属性に個別オブジェクト３２０を示す情報が設定される。この点がＳＱＬ定義ファイル１１２と異なる。

図２５は、第３の実施の形態のマッピング定義画面の例を示す図である。マッピング定義画面４１０ａは、ブラウザ２２０によりＯＲＭ利用側サーバ２００に接続されたディスプレイに表示される。マッピング定義画面４１０ａは、第２の実施の形態で説明したマッピング定義画面４１０と同様の画面構成である。

マッピング定義画面４１０ａでは、入力ボックスＣ２に個別オブジェクト３２０のオブジェクト名“Ｅｍｐｌｏｙｅｅ”が入力されている点が、マッピング定義画面４１０と異なる。ユーザは、当初、入力ボックスＣ２にオブジェクト名を入力せずにマッピング定義を作成したとしても、事後的にオブジェクト名を入力することもできる。

具体的には、入力ボックスＣ１にマッピングＩＤを入力して当該マッピングＩＤに対応するマッピング定義をマッピング定義入力領域４１１に表示させる。そして、オブジェクト名（当該表示時は“Ａｎｏｎｙｍｏｕｓ”）の設定を個別オブジェクト３２０のオブジェクト名に変更して、作成ボタン４１２を押下操作する。すると、マッピング定義ファイル１１１ａで示したように、“ｃｌａｓｓ”のタグ属性が個別オブジェクト３２０のオブジェクト名に書き換わる。マッピング定義の“ｃｌａｓｓ”のタグ属性は、デフォルトの結果オブジェクトを指定する情報として利用される。

また、ＳＱＬ定義画面についても同様の操作により、“ｃｌａｓｓ”のタグ属性を個別オブジェクト３２０のオブジェクト名に設定することができる。
ここで、匿名オブジェクト３１０および個別オブジェクト３２０の何れを結果オブジェクトに用いるかは、ユーザオブジェクト２３１，２３１ａで指定可能とする。具体的には、図１４で示したユーザオブジェクト２３１で、ＤＡＯ処理部１４０のｆｉｎｄメソッドを呼び出す際（１４行目）、当該ｆｉｎｄメソッドに入力する４つ目の引数で結果オブジェクトを指定する。当該引数に、“Ｅｍｐｌｏｙｅｅ．ｃｌａｓｓ”を指定すれば、個別オブジェクト３２０を指定できる。この場合、当該１４行目の記述を、“Ｌｉｓｔ＜Ｏｂｊｅｃｔ＞ ｒｅｓｕｌｔＬｉｓｔ ＝ ｄａｏ．ｆｉｎｄ（“ＭＡＰＰＩＮＧ００１”，“ＳＥＬＥＣＴ００３”，ｃｏｎｄｉｔｉｏｎ，Ｅｍｐｌｏｙｅｅ．ｃｌａｓｓ）”と書き換えればよい。図１５で示したユーザオブジェクト２３１ａの場合も同様にして、匿名オブジェクト３１０を指定することができる。ＤＡＯ処理部１４０は、アクセス要求３３０に当該結果オブジェクトを指定する情報を含める。

次に、第３の実施の形態の情報処理システムの処理手順を説明する。ここで、第３の実施の形態では、図１７で説明したステップＳ２６とステップＳ２７との間に、結果オブジェクトの選択処理を実行する点が第２の実施の形態と異なる。

図２６は、第３の実施の形態の結果オブジェクト選択を示すフローチャートである。以下、図２６に示す処理をステップ番号に沿って説明する。
（ステップＳ５１）ＯＲＭ処理部１５０は、アクセス要求３３０に結果オブジェクトを指定する情報があるか否かを判定する。結果オブジェクトを指定する情報がある場合、処理をステップＳ５３に進める。結果オブジェクトを指定する情報がない場合、処理をステップＳ５２に進める。

（ステップＳ５２）ＯＲＭ処理部１５０は、アクセス要求３３０で指定されたマッピング定義にデフォルトの結果オブジェクトの指定があるか否かを判定する。デフォルトの結果オブジェクトの指定がある場合、処理をステップＳ５３に進める。デフォルトの結果オブジェクトの指定がない場合、処理をステップＳ５４に進める。

（ステップＳ５３）ＯＲＭ処理部１５０は、指定されたオブジェクトを結果オブジェクトとして選択する。そして、処理を終了する。
（ステップＳ５４）ＯＲＭ処理部１５０は、匿名オブジェクト３１０を結果オブジェクトとして選択する。そして、処理を終了する。

このようにして、ＯＲＭ処理部１５０は、匿名オブジェクト３１０と個別オブジェクト３２０のうちの何れを結果オブジェクトに用いるかを選択する。図１７で説明したステップＳ２７では、選択された方のオブジェクトを結果オブジェクトとして用いて、それ以降の処理を実行する。

このように、結果オブジェクトを選択可能とすることで、ユーザのシステム開発を一層効率的に支援可能となる。例えば、ＯＲＭ利用側サーバ２００で開発するソフトウェアによっては、条件オブジェクトを匿名オブジェクト３１０とし、結果オブジェクトを個別オブジェクト３２０として、アクセス結果を取得したい場合も考えられる。また、条件オブジェクトを個別オブジェクト３２０として、結果オブジェクトを匿名オブジェクト３１０として、アクセス結果を取得したい場合も考えられる。第３の実施の形態によれば、ユーザのこのようなニーズにも柔軟に対応することができる。

［第４の実施の形態］
以下、第４の実施の形態を説明する。前述の第２，第３の実施の形態との相違点を主に説明し、同様の事項の説明を省略する。

第２，第３の実施の形態では、ＯＲＭ提供側サーバ１００は、クエリＩＤを指定したアクセスの依頼をＯＲＭ利用側サーバ２００から受け付ける場合を想定した。一方、クエリＩＤの指定がなくても、定型的なアクセスであれば、ＯＲＭ提供側サーバ１００でＳＱＬを自動生成してＲＤＢ１２０へのアクセスを行うことが考えられる。そこで、第４の実施の形態では、ＳＱＬを自動生成してＲＤＢ１２０へアクセスする機能を提供する。

ここで、第４の実施の形態の情報処理システム、ＯＲＭ提供側サーバおよびＯＲＭ利用側サーバのハードウェア／ソフトウェアの構成は、図２〜図４で説明した第２の実施の形態の情報処理システム、ＯＲＭ提供側サーバ１００およびＯＲＭ利用側サーバ２００の構成と同様である。第４の実施の形態では、第２の実施の形態と同一の符号・名称を用いて、同一の構成を指し示すものとする。

図２７は、第４の実施の形態のユーザオブジェクトの例を示す図である。図２７（Ａ）はユーザオブジェクト２３１ｂのソースプログラム“ＯＲＭＵｓｅｒ３．ｊａｖａ”（一部）を例示している。ユーザオブジェクト２３１ｂは、ＥＭＰテーブル１２１の全てのレコードを取得するための処理“ｓｅｌｅｃｔＡｌｌ（ＰｒｏｖｉｄｅｒＤＡＯ ｄａｏ）”をＤＡＯ処理部１４０に依頼する。この処理では、マッピングＩＤ“ＭＡＰＰＩＮＧ００１”、クエリＩＤ“ｎｕｌｌ”、条件オブジェクト“ｎｕｌｌ”、結果オブジェクト“Ａｎｏｎｙｍｏｕｓ．ｃｌａｓｓ”を引数としてｆｉｎｄメソッドを呼び出している（３行目）。

図２７（Ｂ）はユーザオブジェクト２３１ｃのソースプログラム“ＯＲＭＵｓｅｒ４．ｊａｖａ”（一部）を例示している。ユーザオブジェクト２３１ｃは、ＥＭＰテーブル１２１に１つのレコードを登録するための処理“ｉｎｓｅｒｔＵｓｉｎｇＡｎｏｎｙｍｏｕｓ（ＰｒｏｖｉｄｅｒＤＡＯ ｄａｏ）”をＤＡＯ処理部１４０に依頼する。この処理では、条件オブジェクトに匿名オブジェクト３１０を用いている（３行目〜８行目）。ここで、“ＯＲＭＵｔｉｌ．ｃｒｅａｔｅＳｑｌＤａｔｅ（）”メソッド（７行目）は、引数として入力された日付（例えば、ＹＹＭＭＤＤ形式）をＳＱＬで利用可能な形式に変換するためのメソッドである。

また、マッピングＩＤ“ＭＡＰＰＩＮＧ００１”、クエリＩＤ“ｎｕｌｌ”、条件オブジェクト“ｃｏｎｄｉｔｉｏｎ”（匿名オブジェクト３１０のインスタンス名）を引数としてｃｒｅａｔｅメソッドを呼び出している（９行目）。ここで、ｃｒｅａｔｅメソッドはＤＡＯ処理部１４０が提供するメソッドであり、指定されたテーブルにレコードを追加するためのメソッドである。また、アクセス結果として、登録完了件数を取得する。すなわち、ＯＲＭ処理部１５０はアクセス結果のレコードを結果オブジェクトにマッピングして応答しないため、結果オブジェクトを指定する情報は引数に含まれていない。

図２７（Ｃ）はユーザオブジェクト２３１ｄのソースプログラム“ＯＲＭＵｓｅｒ５．ｊａｖａ”（一部）を例示している。ユーザオブジェクト２３１ｄは、ＥＭＰテーブル１２１の全てのレコードを削除するための処理“ｄｅｌｅｔｅＡｌｌ（ＰｒｏｖｉｄｅｒＤＡＯ ｄａｏ）”をＤＡＯ処理部１４０に依頼する。この処理では、マッピングＩＤ“ＭＡＰＰＩＮＧ００１”、クエリＩＤ“ｎｕｌｌ”、条件オブジェクト“ｎｕｌｌ”を引数として、ｒｅｍｏｖｅメソッドを呼び出している（３行目）。ここで、ｒｅｍｏｖｅメソッドはＤＡＯ処理部１４０が提供するメソッドであり、指定されたテーブルの全レコードを削除するためのメソッドである。また、アクセス結果として、削除完了件数を取得する。すなわち、ＯＲＭ処理部１５０はアクセス結果のレコードを結果オブジェクトにマッピングして応答しないため、結果オブジェクトを指定する情報は引数に含まれていない。

次に、第４の実施の形態の情報処理システムの処理手順を説明する。以下では、ユーザオブジェクト２３１ｂ，２３１ｃ，２３１ｄで例示したように、ＤＡＯ処理部１４０への処理依頼時に、クエリＩＤが指定されない場合を説明する。この場合、図１６で説明したＤＢアクセス要求の処理手順が第２，第３の実施の形態と異なる。

図２８は、第４の実施の形態のＤＢアクセス要求を示すフローチャートである。以下、図２８に示す処理をステップ番号に沿って説明する。
（ステップＳ６１）ＵＰ処理部２３０は、ＲＤＢ１２０へのアクセス依頼に伴い、条件オブジェクトを利用するか否かを判定する。利用する場合、処理をステップＳ６２に進める。利用しない場合、処理をステップＳ６７に進める。例えば、ユーザオブジェクト２３１ｃは、条件オブジェクトを利用する（匿名オブジェクト３１０が利用されている）。一方、ユーザオブジェクト２３１ｂ，２３１ｄは、条件オブジェクトを利用しない。

（ステップＳ６２）ＵＰ処理部２３０は、条件オブジェクトとして個別オブジェクト３２０が指定されているか否かを判定する。個別オブジェクト３２０が指定されている場合、処理をステップＳ６３に進める。個別オブジェクト３２０が指定されていない場合、処理をステップＳ６５に進める。なお、ステップＳ１１と同様に、ＵＰ処理部２３０は、条件オブジェクトの名称に基づいて、当該条件オブジェクトが個別オブジェクト３２０であるか否かを判断できる。

（ステップＳ６３）ＵＰ処理部２３０は、指定された個別オブジェクト３２０をインスタンス化する。
（ステップＳ６４）ＵＰ処理部２３０は、指定された属性値を個別オブジェクト３２０の各属性に設定する。ＵＰ処理部２３０は、ユーザオブジェクトで指定されたマッピングＩＤおよび属性値を設定した個別オブジェクト３２０をＤＡＯ処理部１４０に送信する（クエリＩＤは指定されない）。ＵＰ処理部２３０は、ユーザオブジェクトで指定されるメソッド（例えば、ユーザオブジェクト２３１ｂの例ではｆｉｎｄメソッド）の実行をＤＡＯ処理部１４０に依頼する。そして、処理をステップＳ６７に進める。

（ステップＳ６５）ＵＰ処理部２３０は、匿名オブジェクト３１０をインスタンス化する。
（ステップＳ６６）ＵＰ処理部２３０は、ユーザオブジェクトで指定された属性名と属性値とのペアを匿名オブジェクト３１０に設定する。ＵＰ処理部２３０は、ユーザオブジェクトで指定されたマッピングＩＤおよび属性名／属性値のペアを設定した匿名オブジェクト３１０をＤＡＯ処理部１４０に送信する（クエリＩＤは指定されない）。このとき、ＵＰ処理部２３０は、ユーザオブジェクトで指定されるメソッド（例えば、ユーザオブジェクト２３１ｃの例ではｃｒｅａｔｅメソッド）の実行をＤＡＯ処理部１４０に依頼する。

（ステップＳ６７）ＤＡＯ処理部１４０は、メソッドに対する引数にクエリＩＤが含まれていないことを検知する。すると、ＤＡＯ処理部１４０は、ＵＰ処理部２３０から取得したマッピングＩＤおよび記憶部１１０に記憶されたマッピング定義ファイル１１１に基づいて、アクセス対象のテーブル名を取得する。例えば、マッピングＩＤ“ＭＡＰＰＩＮＧ００１”であれば、テーブル名（ｔａｂｌｅ属性の設定）は“ＥＭＰ”である。なお、本ステップＳ６７でメソッドに対する引数にクエリＩＤが含まれている場合は、図１６のステップＳ１６以降の処理を行う。

（ステップＳ６８）ＤＡＯ処理部１４０は、ＵＰ処理部２３０から依頼されたメソッドを実行して、ステップＳ６７で取得したテーブル名を指定したＳＱＬ雛型を生成する。図２７で示したｆｉｎｄ、ｃｒｅａｔｅおよびｒｅｍｏｖｅの各メソッドが自動生成するＳＱＬ雛型の例は、図２９で説明する。

（ステップＳ６９）ＤＡＯ処理部１４０は、ＵＰ処理部２３０から依頼された処理内容に応じてＲＤＢ１２０へのアクセス要求３３０を生成し、ＯＲＭ処理部１５０に出力する。アクセス要求３３０は、ステップＳ６８でＤＡＯ処理部１４０が生成したＳＱＬ雛型を含む。

（ステップＳ７０）ＯＲＭ処理部１５０は、ＤＡＯ処理部１４０から取得したＳＱＬ雛型に基づいてＳＱＬを生成し、当該ＳＱＬを用いてＲＤＢ１２０へアクセスする。ＯＲＭ処理部１５０は、アクセス結果を含むアクセス応答３４０をＤＡＯ処理部１４０に出力する。ＯＲＭ処理部１５０による当該アクセス処理の手順は、図１７で説明した手順と同様である。ただし、ステップＳ２２〜Ｓ２４では、ＤＡＯ処理部１４０から取得したＳＱＬ雛型に基づいてＳＱＬの生成を行う点が異なる。

（ステップＳ７１）ＤＡＯ処理部１４０は、ＯＲＭ処理部１５０から取得したアクセス結果をＵＰ処理部２３０に応答する。ＵＰ処理部２３０は、アクセス結果を示すメッセージを標準出力する。

このように、ＤＡＯ処理部１４０はクエリＩＤの指定がない場合には、依頼されたメソッドに応じたＳＱＬ雛型を自動生成する。なお、ＤＡＯ処理部１４０の代わりにＯＲＭ処理部１５０がＳＱＬ雛型を自動生成してもよい。例えば、ＯＲＭ処理部１５０は、アクセス要求３３０にクエリＩＤが含まれていない場合に、ＳＱＬ雛型を自動生成することが考えられる。

図２９は、第４の実施の形態の自動生成されるＳＱＬ雛型の例を示す図である。図２９（Ａ）はＤＡＯ処理部１４０に実装されるｆｉｎｄメソッドが生成するＳＱＬ雛型５１１を例示している。図２９（Ｂ）はＤＡＯ処理部１４０に実装されるｃｒｅａｔｅメソッドが生成するＳＱＬ雛型５１２を例示している。図２９（Ｃ）はＤＡＯ処理部１４０に実装されるｒｅｍｏｖｅメソッドが生成するＳＱＬ雛型５１３を例示している。

なお、ＳＱＬ雛型５１１，５１３は、“？”で囲まれた文字列を含んでいない。したがって、ＯＲＭ処理部１５０がＳＱＬ雛型５１１，５１３に基づいて生成するＳＱＬの内容はＳＱＬ雛型５１１，５１３と同一となる。

このように、ＤＡＯ処理部１４０は、クエリＩＤの指定を受けない場合には、ＳＱＬ雛型を自動生成してＯＲＭ処理部１５０に渡す。このため、ＲＤＢ１２０に対する定型的な処理の依頼を容易に行える。その結果、システム開発を一層効率化できる。

［第５の実施の形態］
以下、第５の実施の形態を説明する。前述の第２〜第４の実施の形態との相違点を主に説明し、同様の事項の説明を省略する。

第２〜第４の実施の形態で説明した匿名オブジェクト３１０は、テーブルの結合（ｊｏｉｎ）を行って結果を取得する場合にも利用できる。第５の実施の形態では、結合を行う場合の匿名オブジェクト３１０の利用方法を例示する。

ここで、第５の実施の形態の情報処理システム、ＯＲＭ提供側サーバおよびＯＲＭ利用側サーバのハードウェア／ソフトウェアの構成は、図２〜図４で説明した第２の実施の形態の情報処理システム、ＯＲＭ提供側サーバ１００およびＯＲＭ利用側サーバ２００の構成と同様である。第５の実施の形態では、第２の実施の形態と同一の符号・名称を用いて、同一の構成を指し示すものとする。

図３０は、第５の実施の形態のＥＭＰテーブルの例を示す図である。ＥＭＰテーブル１２１ｂは、記憶部１２０に記憶される。ＥＭＰテーブル１２１ｂは、第２の実施の形態で説明したＥＭＰテーブル１２１に対応する。ＥＭＰテーブル１２１ｂは、ＥＭＰＮＯ、ＮＡＭＥ、ＳＥＸ、ＨＩＲＥＤＡＴＥ、ＳＡＬＡＲＹおよびＤＥＰＴＮＯの項目を含む。

ここで、ＥＭＰＮＯ、ＮＡＭＥ、ＳＥＸ、ＨＩＲＥＤＡＴＥおよびＳＡＬＡＲＹの項目は、ＥＭＰテーブル１２１で説明した同名の項目と同じ内容が設定される。ＤＥＰＴＮＯの項目には、所属する部門の部門番号（例えば、“１０”など）が設定される。

図３１は、第５の実施の形態のＤＥＰＴテーブルの例を示す図である。ＤＥＰＴテーブル１２２は、記憶部１２０に記憶される。ＤＥＰＴテーブル１２２は、部門のマスタ情報である。ＤＥＰＴテーブル１２２は、ＤＥＰＴＮＯおよびＤＮＡＭＥの項目を含む。

ＤＥＰＴＮＯの項目には、部門番号が設定される。ＤＮＡＭＥの項目には、部門の名称が設定される。例えば、ＤＥＰＴテーブル１２２には、ＤＥＰＴＮＯが“１０”、ＤＮＡＭＥが“ＤＥＶＥＬＯＰ”という情報が設定されている。

図３２は、第５の実施の形態のマッピング定義ファイルの例を示す図である。マッピング定義ファイル１１１ｂは、記憶部１１０に記憶される。マッピング定義ファイル１１１ｂは、第２の実施の形態で説明したマッピング定義ファイル１１１に、ＥＭＰテーブル１２１ｂとＤＥＰＴテーブル１２２との結合用のマッピング定義を追加したものである。マッピング定義ファイル１１１ｂの４行目〜９行目が追加部分である（マッピングＩＤ“ＭＡＰＰＩＮＧ００２”の定義）。ここで、結合の場合、複数のテーブルを扱い、テーブルを１つに特定できないため、“ｔａｂｌｅ”のタグ属性には任意のテーブルを示す“＊”を設定する。なお、マッピング定義ファイル１１１ｂでは、結合で利用する属性名や項目名のみを定義している。

図３３は、第５の実施の形態のＳＱＬ定義ファイルの例を示す図である。ＳＱＬ定義ファイル１１２ｂは、記憶部１１０に記憶される。ＳＱＬ定義ファイル１１２ｂは、第２の実施の形態で説明したＳＱＬ定義ファイル１１２に、ＥＭＰテーブル１２１ｂとＤＥＰＴテーブル１２２とを結合してレコードを抽出するためのＳＱＬ雛型を追加したものである。ＳＱＬ定義ファイル１１２ｂの４行目〜６行目が追加部分である（クエリＩＤ“ＳＥＬＥＣＴ００４”の定義）。

図３４は、第５の実施の形態のマッピング定義画面の例を示す図である。マッピング定義画面４１０ｂは、ブラウザ２２０によりＯＲＭ利用側サーバ２００に接続されたディスプレイに表示される。マッピング定義画面４１０ｂは、第２の実施の形態で説明したマッピング定義画面４１０に対応する。

また、マッピング定義画面４１０ｂの入力内容は、マッピング定義ファイル１１１ｂの記述に対応する。マッピング定義画面４１０ｂでは、入力ボックスＣ１に“ＭＡＰＰＩＮＧ００２”が入力される。入力ボックスＣ２に“Ａｎｏｎｙｍｏｕｓ”が入力される。入力ボックスＣ３に“＊”が入力される。また、入力ボックス群Ｃ４に結合で利用するデータの名称／型、オブジェクトで扱う属性名／開発言語型、テーブルで扱う項目名／ＤＢＭＳ型／サイズ（桁）を定義する。

このように、結合の場合も第２〜第４の実施の形態で説明した匿名オブジェクト３１０と同様に定義できる。また、ＳＱＬ定義ファイル１１２ｂで示したＳＱＬ雛型の登録は、ＳＱＬ定義画面４２０を用いて行える。

ここで、個別オブジェクトを用いて結合を扱う場合、個別オブジェクト間（ここでは、ＥＭＰテーブル１２１ｂに関する個別オブジェクトとＤＥＰＴテーブル１２２に関する個別オブジェクト）の関連を定義することが考えられる。例えば、ＳＱＬ定義ファイル１１２ｂのクエリＩＤ“ＳＥＬＥＣＴ００４”で示したような結合の場合、マッピング定義に多対１の関連（一方の個別オブジェクトの属性として他方の個別オブジェクトを持つ構造）を定義する。１対多の関連の場合も、同様に当該関連を意識したマッピング定義を行う。

これに対し、匿名オブジェクト３１０を用いれば、ＳＱＬ雛型に結合条件を記述して、条件となる項目や取得する項目をマッピング定義に記述しさえすれば、テーブルの結合を容易に扱える。すなわち、個別オブジェクト間の多対１や１対多の関連といった複雑な考え方を意識せずにマッピング定義を行える。このように匿名オブジェクト３１０を用いれば、結合に係るマッピング定義も容易化でき、ユーザの負担を軽減して効率的なアクセス支援を行える。その結果、システム開発を一層効率化できる。

以上、第２〜第５の実施の形態で説明したように、匿名オブジェクトを利用することで、個別オブジェクトの作成が不要となり、アクセス対象テーブルの変化に影響を受けず、マッピング定義やＳＱＬ定義のみでＯＲＭを利用することができる。

例えば、個別オブジェクトを用いるとすると、アクセス対象テーブルの数が増えた場合に個別オブジェクトを新たに作成したり、テーブル構造が更新された場合に個別オブジェクトを修正したりする作業コストが生じてしまう。これに対して、匿名オブジェクトを予め用意しておけば、当該匿名オブジェクトを用いて容易に追加されたテーブルや更新後のテーブルへアクセスできる。したがって、個別オブジェクトを作成したり修正したりするユーザの負担を軽減できる。

また、従来のＯＲＭではオブジェクトで扱う属性をレコードとマッピングすることに重点をおいており、それ以外の文字列置換など汎用的に利用することができなかった。これに対して、任意属性を追加することで、当該マッピングに限定されずに条件オブジェクトを利用可能となる。

このような仕組みにより、ＯＲＭツールの導入やシステム開発に係る工数を削減するとともに、データの変更や機能仕様の変更に柔軟に対応できる変化に強いシステム開発に貢献することができる。

なお、ＯＲＭ提供側サーバ１００の機能はコンピュータに所定のプログラムを実行させることで実現できる。当該プログラムは、コンピュータ読み取り可能な可搬型の記録媒体１３に記録しておくことができる。当該プログラムを流通させるには、例えば、そのプログラムが記録された記録媒体１３を配布する。または、そのプログラムをサーバコンピュータに格納しておき、ネットワーク１０経由でＯＲＭ提供側サーバ１００に転送する。ＯＲＭ提供側サーバ１００は、例えば、記録媒体１３に記録されたプログラムまたはネットワーク１０から取得したプログラムを、自装置の不揮発性の記憶媒体（例えば、ＨＤＤ１０３）に格納する。そして、当該不揮発性の記憶媒体からプログラムを読み取り実行する。ただし、ＯＲＭ提供側サーバ１００は、取得したプログラムを、不揮発性の記憶媒体に格納せずに逐次、ＲＡＭ１０２に展開して実行することも可能である。

１ 情報処理装置
１ａ 記憶手段
１ｂ 生成手段
１ｃ アクセス手段
２ 関係データベース
２ａ テーブル
３ マッピング情報
４ アクセス要求
４ａ，４ｃ オブジェクト
４ｂ クエリの雛型を示す情報
５ クエリの雛型
６ クエリ
７ アクセス結果
Ｍ１ キー
Ｍ２，Ｍ４ 値
Ｍ３ 文字列

Claims (12)

1. オブジェクト指向言語で開発されたソフトウェアから、複数の項目が定義された関係データベースのテーブルへのアクセスを支援するプログラムであって、コンピュータに、
   キーおよび値の組み合わせを設定したオブジェクトと前記テーブルに対するクエリの雛型であって当該キーに対応する文字列を含む前記クエリの雛型を示す情報とを含むアクセス要求を受け付けると、記憶手段に記憶された、キーと前記テーブルの項目に応じたデータ型との対応関係を前記テーブルの項目ごとに定義したマッピング情報を参照して、前記文字列に対応するキーが前記マッピング情報に含まれる何れかのキーと一致するか判定し、
   前記マッピング情報に含まれる何れかのキーと一致すると判定すると、前記オブジェクトから当該キーに対応する前記値を取得し、前記クエリの雛型に含まれる前記文字列を当該キーに対応するデータ型の前記値に置換したクエリを生成し、生成した当該クエリを用いて前記テーブルにアクセスする、
   処理を実行させるプログラム。
2. 前記マッピング情報は、前記テーブルの項目に対応付けられていない任意キーとデータ型との対応関係を含み、
   前記文字列に対応するキーが任意キーと一致するかを更に判定し、一致すると判定すると前記文字列を当該任意キーに対応するデータ型の前記値に置換したクエリを生成する、
   請求項１記載のプログラム。
3. 前記オブジェクトは第１のキーおよび第１の値の組み合わせが設定され、前記クエリの雛型は前記第１のキーに対応する第１の文字列を含み、また、前記マッピング情報は前記テーブルの項目に対応付けられていない任意キーとデータ型との対応関係を含み、
   前記第１のキーが第１の任意キーと一致すると判定すると前記第１の文字列を当該第１の任意キーに対応するデータ型の前記第１の値に置換して、前記クエリの雛型からプリペアドステートメントを生成し、当該プリペアドステートメントに基づいてクエリを生成する、
   請求項１記載のプログラム。
4. 前記オブジェクトは第２のキーおよび第２の値の組み合わせが更に設定され、前記クエリの雛型は前記第２のキーに対応する第２の文字列を更に含み、
   前記プリペアドステートメントを生成する際に、前記第１の文字列を前記第１の値に置換するのに加え、前記第２のキーが任意キーと一致しないと判定すると前記第２の文字列をプレースホルダに置換することで、前記クエリの雛型から前記プリペアドステートメントを生成し、
   前記第２のキーが前記マッピング情報に含まれる何れかのキーと一致すると判定すると前記プリペアドステートメントに含まれる前記プレースホルダを当該キーに対応するデータ型の前記第２の値に置換することで、前記プリペアドステートメントからクエリを生成する、
   請求項３記載のプログラム。
5. 前記マッピング情報に定義された前記対応関係にはキーと前記テーブルの項目との対応付けが含まれており、
   前記テーブルへアクセスして前記テーブルの何れかの項目の設定値を取得すると、前記マッピング情報を参照して、当該項目に対応するキーを取得し、前記オブジェクトに当該キーと前記設定値との組み合わせを設定して前記アクセス要求に対する応答とする、
   請求項１乃至４の何れか一項に記載のプログラム。
6. 前記オブジェクトには、キーおよびデータ型を指定した値の設定操作がデータ型ごとに定義されており、
   前記オブジェクトに前記テーブルの項目に対応する前記設定値を設定する際に、前記マッピング情報を参照して得た当該項目に対応するデータ型での当該設定値の前記設定操作を実行する、
   請求項５記載のプログラム。
7. 前記アクセス要求には当該アクセス要求に対する応答で用いるオブジェクトを指定する情報を設定可能であり、
   前記テーブルの項目に対応しキーに対応する名称をもつ属性と当該属性に対する属性値の設定操作および取得操作とを定義した個別オブジェクトを指定する情報が前記アクセス要求に含まれる場合、前記テーブルへアクセスして取得した前記設定値を、前記マッピング情報に基づき前記個別オブジェクトに設定して前記アクセス要求に対する応答とする、
   請求項５または６記載のプログラム。
8. 前記アクセス要求に、前記オブジェクトに代えて前記テーブルの項目に対応する属性の属性値を設定した前記個別オブジェクトが含まれる場合、前記マッピング情報を参照して、前記クエリの雛型に含まれる前記文字列を当該属性に対応するキーに対するデータ型の前記属性値に置換したクエリを生成する、
   請求項７記載のプログラム。
9. 前記オブジェクトには、キーに基づくデータ型を指定した値の取得操作がデータ型ごとに定義されており、
   前記オブジェクトからキーに対応する前記値を取得する際に、前記マッピング情報を参照して得た当該キーに対応するデータ型での当該値の前記取得操作を実行する、
   請求項１乃至８の何れか一項に記載のプログラム。
10. 前記テーブルへのアクセスを依頼する装置からの当該アクセスの依頼に前記クエリの雛型を示す情報が含まれていない場合に前記クエリの雛型を生成し、生成した当該クエリの雛型を前記アクセス要求に追加する、
    請求項１乃至９の何れか一項に記載のプログラム。
11. オブジェクト指向言語で開発されたソフトウェアから、複数の項目が定義された関係データベースのテーブルへのアクセスを支援する情報処理装置であって、
    キーと前記テーブルの項目に応じたデータ型との対応関係を前記テーブルの項目ごとに定義したマッピング情報を記憶する記憶手段と、
    キーおよび値の組み合わせを設定したオブジェクトと前記テーブルに対するクエリの雛型であって当該キーに対応する文字列を含む前記クエリの雛型を示す情報とを含むアクセス要求を受け付けると、前記記憶手段に記憶された前記マッピング情報を参照して、前記文字列に対応するキーが前記マッピング情報に含まれる何れかのキーと一致するか判定し、前記マッピング情報に含まれる何れかのキーと一致すると判定すると、前記オブジェクトから当該キーに対応する前記値を取得し、前記クエリの雛型に含まれる前記文字列を当該キーに対応するデータ型の前記値に置換したクエリを生成する生成手段と、
    生成した当該クエリを用いて前記テーブルにアクセスするアクセス手段と、
    を有する情報処理装置。
12. オブジェクト指向言語で開発されたソフトウェアから、複数の項目が定義された関係データベースのテーブルへのアクセスを支援する情報処理装置が実行するアクセス支援方法であって、
    キーおよび値の組み合わせを設定したオブジェクトと前記テーブルに対するクエリの雛型であって当該キーに対応する文字列を含む前記クエリの雛型を示す情報とを含むアクセス要求を受け付けると、記憶手段に記憶された、キーと前記テーブルの項目に応じたデータ型との対応関係を前記テーブルの項目ごとに定義したマッピング情報を参照して、前記文字列に対応するキーが前記マッピング情報に含まれる何れかのキーと一致するか判定し、
    前記マッピング情報に含まれる何れかのキーと一致すると判定すると、前記オブジェクトから当該キーに対応する前記値を取得し、前記クエリの雛型に含まれる前記文字列を当該キーに対応するデータ型の前記値に置換したクエリを生成し、生成した当該クエリを用いて前記テーブルにアクセスする、
    アクセス支援方法。

Images