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

Description

本発明は、データベースに接続するアプリケーションを構築するための情報処理装置と、その処理方法及びプログラムに関する。

従来、入出力定義やデータモデル定義などを設定し、アプリケーションを構築するツールやサービスが存在する。

それらのツールやサービスを用いて構築したアプリケーションは、設定されたデータモデル定義を用いてデータベースのデータを操作（検索、挿入、更新、削除等）する。また、その操作のうち、登録、更新（論理削除を含む）等を行った場合、監査用の証跡情報として、データベースにおける当該データの「登録ユーザＩＤ」「登録日時」「更新ユーザＩＤ」「更新日時」等のカラムに処理ユーザＩＤ又は処理日時の値を記憶することが一般的である。

特許文献１には、監査用の証跡情報として、「承認者ＩＤ」及び「承認日時」を複数のテーブルに登録する仕組みが開示されている。

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

しかし、特許文献１には、監査用の証跡情報を容易に取得することについては開示されているが、監査用の証跡情報を持つ複数テーブルを利用するアプリケーションの構築については触れられていない。つまり、上記のようなアプリケーション構築ツールで、このようなテーブル構造のデータベースを利用するアプリケーションを構築するには、同じ証跡情報項目を持つデータモデルをテーブルの数分設定し、それらのデータモデルを介して証跡情報の登録及び更新をしなければならず、大変面倒である。

そこで、本発明の目的は、データモデル定義を利用するアプリケーションを容易に構築する仕組みを提供することである。

データベースのデータの操作に用いるデータモデルの定義を記憶するデータモデル記憶手段を備え、前記データベースに接続するアプリケーションを構築する情報処理装置であって、前記構築するアプリケーションで用いる第２データモデルの定義に任意の定義の設定を受け付ける定義受付手段と、前記定義受付手段により受け付けた定義と組み合わせる、前記データモデル記憶手段に記憶されている第１データモデルの定義を、前記アプリケーションで用いる第２データモデルの定義の一部として設定を受け付ける設定受付手段と、前記定義受付手段により設定を受け付けた定義と前記設定受付手段により設定を受け付けた前記第１データモデルの定義を用いて第２データモデルに対応するアプリケーションを構築するアプリケーション構築手段とを備えることを特徴とする情報処理装置。

本発明によれば、データモデル定義を利用するアプリケーションを容易に構築する仕仕組みを提供することができる。

本発明に係る情報処理装置、アプリケーションサーバ、データベースサーバ、アプリケーションクライアントの構成の一例を示すシステム構成図である。 本発明に係る情報処理装置、アプリケーションサーバ、データベースサーバ、アプリケーションクライアントとして適用可能な各ハードウェア構成の一例を示すブロック図である。 本発明の実施の形態のソフトウェア構成を示すブロック図の一例である。 本発明に係るプログラム生成装置の構成図である。 アプリケーション生成のフローチャートの一例を示す図である。 ＳＱＬ文生成のフローチャートの一例を示す図である。 日付時刻更新のフローチャートの一例を示す図である。 データモデル定義画面の一例を示す図である。 データモデル定義ＸＭＬの一例を示す図である。 ＩＮＳＥＲＴ押下前画面、ＩＮＳＥＲＴ押下後画面の一例を示す図である。 ＩＮＳＥＲＴ ＳＱＬ文、ＩＮＳＥＲＴ押下後ＤＢレコードの一例を示す図である。 ＵＰＤＡＴＥ押下前画面、ＵＰＤＡＴＥ押下後画面の一例を示す図である。 ＵＰＤＡＴＥ押下前ＤＢレコード、ＵＰＤＡＴＥ ＳＱＬ文、ＵＰＤＡＴＥ押下後ＤＢレコードの一例を示す図である。 継承関係を持つデータモデル定義画面の一例を示す図である。 継承関係を持つデータモデル定義画面の一例を示す図である。 継承関係を持つデータモデル定義ＸＭＬの一例を示す図である。

以下、本発明の実施の形態を、図面を参照して詳細に説明する。

図１は、本発明に係る情報処理装置（開発者がＷｅｂアプリケーション生成のために操作するプログラム開発装置）、アプリケーションサーバ、データベースサーバ、アプリケーションクライアントの構成の一例を示すシステム（情報処理システム）構成図である。

情報処理装置１０１は、開発者の操作に従って画面レイアウト及びデータベース検索指示などを定義する。情報処理装置１０１は、プログラム生成、アプリケーション生成を行う。

なお、この実施形態においては、情報処理装置１０１で生成するアプリケーションはＷｅｂアプリケーションとしたが、これに限定するものではなく、携帯電話・スマートフォン・タブレットなどの情報処理装置で動作するアプリケーションや組込みソフトウェアなど、Ｗｅｂ技術による通信を利用したアプリケーションでなくてもよい。

アプリケーションサーバ１０２は、情報処理装置１０１で開発されたアプリケーションを実行する。また、データベースサーバ１０３と接続して動作することが可能である。

データベースサーバ１０３は、開発されたアプリケーションが使用するデータベースであり、また本発明では開発時にも動作確認などのために利用してもよい。例えば、開発者が利用するためにデータベースサーバ１０３は、情報処理装置１０１や、アプリケーションサーバ１０２と同一の装置で構成されていてもよいし、ＬＡＮなどのネットワーク１０５内に配置されてもよい。

アプリケーションクライアント１０４（情報処理装置）は、アプリケーションサーバ１０２と協調して情報処理装置１０１で開発したアプリケーションプログラムを動作させる、エンドユーザの入力端末である。この、アプリケーションクライアント１０４は、携帯端末などの情報処理装置であってもよいこととする。

なお、情報処理装置１０１、アプリケーションサーバ１０２、データベースサーバ１０３、および、アプリケーションクライアント１０４の何れかを、クラウドなどのインターネット上に配置してもよい。

図２は、本発明に係る情報処理装置１０１、アプリケーションサーバ１０２、データベースサーバ１０３、アプリケーションクライアント１０４として適用可能な各ハードウェア構成の一例を示すブロック図である。

図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。

また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバ、クライアント、装置など情報処理装置の後述する各種機能を実現するためのプログラムが記憶されている。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。

入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、情報処理装置では、キーボード、マウス等のポインティングデバイス、タッチパネルが挙げられる。
なお、入力部２０９がタッチパネルの場合、ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下（指等でタッチ）することにより、各種の指示を行うことができることとする。
また、タッチパネルは、マルチタッチスクリーン等の、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。

出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶ディスプレイ等が挙げられる。尚、本体と一体になったノート型パソコンのディスプレイも含まれるものとする。また、プロジェクタであってもよいこととする。

外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。外部メモリ２１１には、各サーバ、クライアント、装置等の各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０２内の表示情報用領域へアウトラインフォント展開（ラスタライズ）処理を実行することにより、出力部２１０上での表示を可能としている。また、ＣＰＵ２０１は、出力部２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器との通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。

図３は、本発明の実施の形態のソフトウェア構成を示すブロック図の一例である。

情報処理装置１０１は、以下の機能部を備える。

データモデル記憶部３０１は、データベースのデータの操作に用いるデータモデルの定義を記憶する機能部である。

継承設定受付部３０２は、データモデル記憶部３０１に記憶されている第１データモデルの定義を第２データモデルが継承する設定を受け付ける機能部である。

アプリケーション構築部３０３は、継承設定受付部３０２により設定を受け付けた第２データモデルを用いてデータの操作を行う場合には第１データモデルの定義に基づく定義を用いてデータの操作を行うアプリケーションを構築する機能部である。

データモデル編集受付部３０４は、データモデルの定義の編集を受け付ける機能部である。

アプリケーション構築部３０３は、データモデル編集受付部３０４により第１データモデルの定義の編集を受け付けた後に継承設定受付部３０２により設定を受け付けた第２データモデルを用いてデータの操作を行う場合にはデータモデル編集受付部３０４により受け付けた編集に従って変更した第１データモデルの定義に基づく定義を用いてデータの操作を行うアプリケーションを構築する機能部である。

データモデル編集受付部３０４は、第２データモデルの定義の編集を受け付ける画面に表示された第１データモデルの定義の編集を抑止するよう制御する機能部である。

データモデル生成部３０５は、第１データモデルの定義に基づき、継承設定受付部３０２により設定を受け付けた第２データモデルの定義を生成する機能部である。

アプリケーション構築部３０３は、データモデル生成部３０５により生成された第２データモデルの定義を用いてデータの操作を行うアプリケーションを構築する機能部である。

データモデル生成部３０５は、データモデル編集受付部３０４により受け付けた編集に従って変更した第１データモデルの定義に基づき、継承設定受付部３０２により設定を受け付けた第２データモデルの定義を生成する機能部である。

データモデル編集受付部３０４は、第２データモデルの定義の編集を受け付ける画面に第１データモデルの定義を識別して表示する機能部である。

図４は、情報処理装置１０１の構成図である。

情報処理装置１０１は、リポジトリ定義部４０１及びＷｅｂアプリケーション生成部４０７を備える。

情報処理装置１０１は、Ｗｅｂアプリケーションを開発する開発者により設定されたリポジトリ定義部４０１の各定義を用いて、Ｗｅｂアプリケーション生成部４０７によりＷｅｂアプリケーションを生成する。

リポジトリ定義部４０１には、アプリケーション定義４０２、入出力定義４０３、データモデル定義４０４、ビジネスプロセス定義４０５、データベース定義４０６が記憶されている。これら４０２〜４０６の定義は、Ｗｅｂアプリケーション構築ツールを介して、開発者によって入力設定または配置される。

なお、入出力定義４０３は、入力項目定義情報及び出力項目定義情報を含む。入力項目定義情報は、生成されたＷｅｂアプリケーションの画面を介して当該Ｗｅｂアプリケーションのユーザが入力する入力項目を定義した情報である。出力項目定義情報は、生成されたＷｅｂアプリケーションの画面に出力する出力項目を定義した情報である。以降、「入力項目定義情報」及び「出力項目定義情報」をまとめて「入出力項目定義情報」と呼ぶ。

Ｗｅｂアプリケーション生成部４０７は、Ｗｅｂアプリケーション生成用のリポジトリ定義解析部４０８を用いてリポジトリ定義部４０１に記憶されている各定義を解析し、Ｗｅｂアプリケーションコード生成部４１０及びソースコードコンパイル部４１１を介し、コンパイル済Ｊａｖａ（登録商標）コード４１３及びＨＴＭＬ／ＪＳＰ／ＪａｖａＳｃｒｉｐｔ（登録商標）４１２を含むＷｅｂアプリケーションを生成する。すなわち、設定された定義を用いて、アプリケーションとして用いられるプログラムを生成する手段の一例である。

図５は、アプリケーション生成のフローチャートの一例を示す図である。

情報処理装置１０１は、ディレクトリ構造を用いて、リポジトリ定義部４０１の各定義をファイルとして管理する。なお、本実施形態においては、ディレクトリ構造６００を用いて、リポジトリ定義部４０１の各定義をファイルとして管理するとしたが、これに限定するものではなく、例えば、データベースを用いてリポジトリ定義部４０１の各定義を管理してもよいし、クラウドなどネットワーク上の記憶装置を用いて管理する等としてもよい。

アプリケーション生成のフローチャートについて説明する。

ステップＳ５０１において、情報処理装置１０１は、アプリケーション定義４０２の設定を受け付ける。具体的には、アプリケーション構築ツールの画面を介して、アプリケーション開発者から入出力定義４０３、データモデル定義４０４、ビジネスプロセス定義４０５及びデータベース定義４０６の設定を受け付ける。

図８は、データモデル定義４０４の設定を受け付けるデータモデル定義画面８００の一例を示す図である。アプリケーション開発者は、データモデル定義画面８００を介して、データモデル定義４０４の設定をする。すなわち、データモデル定義４０４は、データベースのデータの操作に用いるデータモデルの定義を記憶する手段の一例である。
図８の加工式８０１のようにして、テーブルのカラムに対応する項目コード毎にタイムゾーンの指定をする。

これにより、データベースの１つのテーブルにおいても、複数のタイムゾーンを使い分けるアプリケーションを構築する仕組みを提供することができる。つまり、構築したアプリケーションをクラウド環境で動作させるケース等、エンドユーザが閲覧する日時情報（例：画面に表示する日時情報）には、エンドユーザの住む地域とのタイムゾーンを利用し、それ以外の日時情報（監査用等）には、異なるタイムゾーン（例：システム日時）を利用したいケースにおいても、複数のタイムゾーンを使い分けるアプリケーションを構築する仕組みを提供することができるようになる。また、世界各国のエンドユーザがアプリケーションを利用するケースであっても、複数のタイムゾーンを使い分けるアプリケーションを構築する仕組みを提供することができるようになる。

タイムゾーンの指定を指定する場合、加工式８０１に“＠ＤＢＺＯＮＥＤＡＴＥ：［ＩＮＳＥＲＴ］［：タイムゾーン文字列］”形式で設定をする。この設定方法について、具体的に説明する。“ＩＮＳＥＲＴ”を付けると、レコード挿入時のみこの項目コードに日時が記録される（つまり、レコード更新時には記録されない）。“ＩＮＳＥＲＴ”を省略する場合は“＠ＤＢＺＯＮＥＤＡＴＥ：：タイムゾーン文字列”と設定する（つまり、レコード挿入時及びレコード更新時にタイムゾーン日時が記録される）。

タイムゾーン文字列として、“＠ＬＯＣＡＬ”が指定された場合は、データベースサーバ１０３のシステム日時を使用する。（つまり、ＳＱＬ文に、“ＡＴ ＴＩＭＥ ＺＯＮＥ”句を付加しない）。タイムゾーン文字列は、ＳＱＬ文にそのまま渡される（つまり、ＤＢＭＳに準拠したタイムゾーンを指定することができる）。

タイムゾーン文字列を省略すると、ＳＱＬ生成時、ＳＱＬ文にタイムゾーンが付加されない。つまり、データベースサーバ１０３のシステム日時が登録される。

また、タイムゾーン日時に未対応のＤＢＭＳの場合、データベースサーバ１０３又はアプリケーションサーバ１０２の日時を登録する。具体的には、データベース定義４０６に定義された接続先データベースサーバ１０３のＤＢＭＳがタイムゾーン日時に対応しているか否かを判定し、対応していない場合はＳＱＬ生成時にタイムゾーン日時の指定を行わないようにする。これにより、タイムゾーン日時に未対応のＤＢＭＳであっても、ＳＱＬエラーにならず、処理を続けることが可能になる。

また、アプリケーション実行時、アプリケーション利用者のＨＴＴＰセッションにセッションキー“＠ＴＩＭＥ＿ＺＯＮＥ”として値が設定されている場合は、“タイムゾーン文字列”の指定の有無にかかわらず、セッション値を使用する。

以上から、項目コード８０４〜８０６の加工式は、“＠ＤＢＺＯＮＥＤＡＴＥ：：タイムゾーン文字列”形式であるため、レコード挿入時及びレコード更新時に指定された各タイムゾーンで処理日時を記録する。項目コード８０７の加工式は、“＠ＤＢＺＯＮＥＤＡＴＥ：：＠ＬＯＣＡＬ”形式であるため、レコード挿入時及びレコード更新時に指定された各タイムゾーンでデータベースサーバ１０３のシステム日時を記録する。項目コード８０８〜８１０の加工式は、“＠ＤＢＺＯＮＥＤＡＴＥ：ＩＮＳＥＲＴ：タイムゾーン文字列”形式であるため、レコード挿入時に指定された各タイムゾーンで処理日時を記録する。項目コード８１１の加工式は、“＠ＤＢＺＯＮＥＤＡＴＥ：ＩＮＳＥＲＴ：＠ＬＯＣＡＬ”形式であるため、レコード挿入時に指定された各タイムゾーンでデータベースサーバ１０３のシステム日時を記録する。

なお、本実施形態においては、“＠ＬＯＣＡＬ”が指定された場合は、データベースサーバ１０３のシステム日杖ｋを使用するとしたが、これに限定するものではなく、アプリケーションサーバ１０２であっても、アプリケーションサーバ１０２又はデータベースサーバ１０３を選択できるとしてもよい。

また、本実施形態においては、各データモデルの各項目コード（各テーブルの各カラムに対応）にタイムゾーン設定をするとしたが、これに限定するものではなく、複数のデータモデルや複数の項目コードに対して、一括的にタイムゾーンを指定できるとしてもよい。

ステップＳ５０１にて、受け付けたアプリケーション定義４０２（入出力定義４０３、データモデル定義４０４、ビジネスプロセス定義４０５及びデータベース定義４０６）の設定は、リポジトリ定義部４０１にＸＭＬファイル形式で記憶する。例えば、データモデル定義画面８００を介して受け付けた「商品データモデル」は、リポジトリ定義部４０１にデータモデル定義ＸＭＬ９００（図９）のような形式で記憶する。

図９は、データモデル定義ＸＭＬの一例を示す図である。項目コード毎の設定が、＜ｄｍ−ｉｔｅｍ＞〜＜／ｄｍ−ｉｔｅｍ＞部分に記載されている。加工式８０１の設定は、＜ｓｔａｔｅｍｅｎｔ＞〜＜／ｓｔａｔｅｍｅｎｔ＞部分に記載される。

なお、本実施形態においては、データモデル定義４０４等のアプリケーション定義４０２をＸＭＬファイル形式で記憶するとしたが、これに限定するものではなく、他のファイル形式やデータベースに登録する等の他の記憶方法であってもよい。

ステップＳ５０２において、情報処理装置１０１は、アプリケーション生成の指示を受け付ける。

ステップＳ５０３において、情報処理装置１０１は、リポジトリ定義部４０１からアプリケーション定義４０２を取得する。リポジトリ定義解析部４０８は、読み込んだ定義を解析したうえでメモリに保管しておき、解析された定義は各生成部から適宜参照される。

ステップＳ５０４において、情報処理装置１０１は、リポジトリ定義部４０１からデータモデル定義４０４を取得する。

ステップＳ５０５において、情報処理装置１０１は、リポジトリ定義部４０１から入出力定義４０３を取得する。

ステップＳ５０６において、情報処理装置１０１は、リポジトリ定義部４０１からビジネスプロセス定義４０５を取得する。

ステップＳ５０７において、情報処理装置１０１は、リポジトリ定義部４０１からデータベース定義４０６を取得する。

ステップＳ５０８において、情報処理装置１０１は、Ｗｅｂアプリケーション生成部４０７を用いて、Ｗｅｂアプリケーションに用いるプログラムを生成する。すなわち、ステップＳ５０８は、アプリケーションを構築する処理の一例を示すステップである。

ステップＳ５０９において、情報処理装置１０１は、ＳＱＬ文を生成する（詳細は、図６の説明にて後述する）。

ステップＳ５１０において、情報処理装置１０１は、ステップＳ５０８にて生成したプログラム及びステップＳ５０９にて生成したＳＱＬ文をアプリケーションサーバ１０２に配置（デプロイ）する。これにより、複数のタイムゾーンを使い分けるアプリケーションを構築する仕組みを提供することができる。

以上で、図５の説明を終了する。

図６は、ＳＱＬ文生成のフローチャートの一例を示す図である。

ステップＳ６０１において、情報処理装置１０１は、ステップＳ５０４にて取得したデータモデル定義４０４の加工式８０１（図９の＜ｓｔａｔｅｍｅｎｔ＞〜＜／ｓｔａｔｅｍｅｎｔ＞部分）に“＠ＤＢＺＯＮＥＤＡＴＥ”が設定されているかを判定し、設定されている場合はステップＳ６０２に進み、設定されていない場合は図６の処理を終了する。

ステップＳ６０２において、情報処理装置１０１は、ステップＳ５０４にて取得したデータモデル定義４０４の加工式８０１に“＠ＬＯＣＡＬ”が設定されているか判定し、設定されている場合はステップＳ６０３に進み、設定されていない場合はステップＳ６０４に進む。

ステップＳ６０３において、情報処理装置１０１は、データベースサーバ１０３の日付を取得するＳＱＬ文を作成する（例：図１１の１１１０又は図１３の１３２０の対象カラム名＝ＣＵＲＲＥＮＴ＿ＴＩＭＥＳＴＡＭＰ）。なお、本実施形態においては、データベースサーバ１０３の日付を“ＣＵＲＲＥＮＴ＿ＴＩＭＥＳＴＡＭＰ”としたが、これに限定するものではなく、ＤＢＭＳの種類によっては、“ＳＹＳＴＩＭＥＳＴＡＭＰ”等、他の表現方法であってもよい。

ステップＳ６０４において、情報処理装置１０１は、“ＡＴ ＴＩＭＥ ＺＯＮＥ”付のＳＱＬ文を作成する（例：図１１の１１１０又は図１３の１３２０の対象カラム名＝ＣＵＲＲＥＮＴ＿ＴＩＭＥＳＴＡＭＰ ＡＴ ＴＩＭＥ ＺＯＮＥ タイムゾーン文字列）。すなわち、ステップＳ６０４は、データモデル定義に第１の所定の値（タイムゾーン文字列）が設定されている場合に、当該第１の所定の値に応じたタイムゾーンを指定するクエリを用いてデータベースのデータを操作するアプリケーションを構築する処理の一例を示すステップである。

なお、本実施形態においては、データベースサーバ１０３の日付を“ＣＵＲＲＥＮＴ＿ＴＩＭＥＳＴＡＭＰ ＡＴ ＴＩＭＥ ＺＯＮＥ タイムゾーン文字列”としたが、これに限定するものではなく、ＤＢＭＳの種類によっては、“ＳＹＳＴＩＭＥＳＴＡＭＰ ＡＴ ＴＩＭＥ ＺＯＮＥ タイムゾーン文字列”等、他の表現方法であってもよい。ただし、タイムゾーン文字列については、データベースの種類によってその指定方法が異なる場合があるため、加工式８０１に設定されたタイムゾーン文字列をそのまま利用するとした方が、汎用性が高まるため好ましい。

ステップＳ６０５において、情報処理装置１０１は、データモデル定義４０４の加工式８０１の“＠ＤＢＺＯＮＥＤＡＴＥ”に“ＩＮＳＥＲＴ”が設定されているか判定し、設定されている場合はステップＳ６０６に進み、設定されていない場合はステップＳ６０７に進む。つまり、“＠ＤＢＺＯＮＥＤＡＴＥ”に“ＩＮＳＥＲＴ”が設定されている場合は、レコード挿入時のみこの項目コードに日時が記録される。すなわち、ステップＳ６０５は、記憶されているデータモデル定義に第２の所定の値（“ＩＮＳＥＲＴ”）が設定されているか否かを判定する処理の一例を示すステップである。また、ステップＳ６０５は、判定に従って、データベースのデータを更新するときにタイムゾーンを指定するクエリを用いるアプリケーションを構築するか、データベースのデータを更新するときにタイムゾーンを指定しないクエリを用いるアプリケーションを構築するかを制御する処理の一例を示すステップである。

ステップＳ６０６において、情報処理装置１０１は、ステップＳ５０５にて取得した入出力定義４０３のアクション定義に“＠ＩＮＳＥＲＴ”が定義されているか判定し、設定されている場合はステップＳ６０８に進み、設定されていない場合は図６の処理を終了する。つまり、レコード挿入を行うアクション（例；挿入ボタン押下時）によって実行される処理の場合は、ＩＮＳＥＲＴ ＳＱＬ文に日付時刻のＳＱＬを付加すべく、ステップＳ６０８に進む。

ステップＳ６０７において、情報処理装置１０１は、ステップＳ５０５にて取得した入出力定義４０３のアクション定義に“＠ＩＮＳＥＲＴ”又は“＠ＵＰＤＡＴＥ”が定義されているか判定し、設定されている場合はステップＳ６０８に進み、設定されていない場合は図６の処理を終了する。つまり、レコード挿入又はレコード更新を行うアクション（例；挿入ボタン又は更新ボタン押下時）によって実行される処理の場合は、ＩＮＳＥＲＴ ＳＱＬ文又はＵＰＤＡＴＥ ＳＱＬ文に日付時刻のＳＱＬを付加すべく、ステップＳ６０８に進む。

ステップＳ６０８において、情報処理装置１０１は、ステップＳ６０３又はステップＳ６０４で作成した日付時刻のＳＱＬを処理ＳＱＬ文に付加する。

以上で、図６の説明を終了する。

図７は、図５・図６の処理により構築されたアプリケーションが日付時刻を更新する処理のフローチャートの一例を示す図である。

ステップＳ７０１において、アプリケーションサーバ１０２は、デプロイしたコンパイル済Ｊａｖａ（登録商標）コード４１３を実行し、生成されたＳＱＬ文に“ＡＴ ＴＩＭＥ ＺＯＮＥ”句が無い且つアプリケーション利用者のＨＴＴＰセッションにセッションキー“＠ＴＩＭＥ＿ＺＯＮＥ”として値が設定されているか判定し、Ｙｅｓの場合はステップＳ７０３に進み、Ｎｏの場合はステップＳ７０２に進む。すなわち、ステップＳ７０１は、アプリケーションを利用するユーザのセッションに所定のセッションキーが存在するか否かを判定する処理の一例を示すステップである。

ステップＳ７０２において、アプリケーションサーバ１０２は、図６の処理により生成されたＳＱＬ文を実行する。

具体的には、「ＩＮＳＥＲＴ押下前画面１０１０（図１０）」でＩＮＳＥＲＴボタン１０１１の押下を受け付けた場合、このＩＮＳＥＲＴボタン１０１１（＝ＩＮＳＥＲＴアクション）に対応付けられて生成された「ＩＮＳＥＲＴ ＳＱＬ文 １１１０（図１１）」が実行されることによって、「ＩＮＳＥＲＴ後 ＤＢレコード１１２０（図１１）」がデータベースに登録され、「ＩＮＳＥＲＴ押下後画面１０２０（図１０）」のような画面が表示される。

同様に、「ＵＰＤＡＴＥ押下前画面１２１０（図１２）」でＵＰＤＡＴＥボタン１２１１の押下を受け付けた場合、このＵＰＤＡＴＥボタン１２１１（＝ＵＰＤＡＴＥアクション）に対応付けられて生成された「ＵＰＤＡＴＥ ＳＱＬ文 １３２０（図１３）」が実行されることによって、データベースに記憶されている「ＵＰＤＡＴＥ前 ＤＢレコード１３１０（図１３）」が、「ＵＰＤＡＴＥ後 ＤＢレコード１３３０（図１３）」に更新され、ＵＰＤＡＴＥ押下後画面１２２０（図１２）」のような画面が表示される。つまり、データモデル定義画面８００の加工式８０１に“ＩＮＳＥＲＴ”を付けた項目コードについては、レコード更新時に日付は記録されない。

これにより、アプリケーション開発者が定義したデータモデル定義４０４の加工式８０１のタイムゾーン文字列に従って、挿入日時又は更新日時を記録することができるようになる。つまり、アプリケーション設計のタイムゾーンに合わせた日時の記録及びその後の日時表示ができるようになる。

ステップＳ７０３において、アプリケーションサーバ１０２は、図６の処理により生成されたＳＱＬ文とセッションキー“＠ＴＩＭＥ＿ＺＯＮＥ”の値とを用いて動的にＳＱＬ文を生成し実行する。すなわち、ステップＳ７０３は、所定のセッションキーが存在する場合、当該セッションキーに対応する値に応じたタイムゾーンを指定するクエリを用いてデータベースのデータを操作するアプリケーションを構築する処理の一例を示すステップである。また、ステップＳ７０３は、所定のセッションキーが存在する場合、当該セッションキーに対応する値に応じたタイムゾーンを指定するクエリを用いてデータベースのデータを操作するアプリケーションを構築する処理の一例を示すステップである。

具体的には、アプリケーション利用者のＨＴＴＰセッションに＠ＴＩＭＥ＿ＺＯＮＥ＝“Ａｍｅｒｉｃａ／Ｎｅｗ＿Ｙｏｒｋ”と記録されていた場合、図８の加工式８０１の“タイムゾーン文字列”の指定に関わらず、図６の処理により生成されたＳＱＬ文中のタイムゾーン文字列を“Ａｍｅｒｉｃａ／Ｎｅｗ＿Ｙｏｒｋ”に置換して、動的にＳＱＬ文を生成し実行する。これにより、アプリケーション開発者が定義したデータモデル定義４０４の加工式８０１のタイムゾーン文字列に関わらず、アプリケーション利用者のタイムゾーン文字列に従って、挿入日時又は更新日時を記録することができるようになる。つまり、アプリケーション利用者のタイムゾーンに合わせた日時の記録及びその後の日時表示ができるようになる。

以上で、図７の説明を終了する。

ここまで、監査用の証跡情報（図８の８０４〜８１１）を持つデータモデル定義４０４を利用したアプリケーションの構築について説明した。このような証跡情報は、データベースの各テーブルに通常持つため、各データモデル定義４０４にも同様に持つ必要がある。また、上記のように証跡情報にタイムゾーンの指定を含む場合は、データ項目の設定だけでなく、加工式８０１等の設定も各データモデル定義４０４に必要となる。

そこで、図１４〜図１６を用いて、監査用の証跡情報を持つ複数テーブルを利用するアプリケーションの構築について説明する。

図１４は、継承関係を持つデータモデル定義画面１４００の一例である。

例えば、継承設定を用いて図８の商品データモデル（ＣＯＭＭＯＤＩＴＹ＿ＤＭ）を定義する場合、図８の商品データモデル（ＣＯＭＭＯＤＩＴＹ＿ＤＭ）から証跡情報（８０４〜８１１）だけをタイムゾーンデータモデル１４１０（ＴＩＭＥＺＯＮＥ＿ＤＭ）として切り出して設定する（１４１１〜１４１８）。一方、残った商品データモデル独自のデータ項目（１４２１及び１４２２）を商品データモデル１４２０として設定する。

図１４の１４２３はデータモデルの継承設定であり、ここでは、商品データモデル１４２０（子データモデル）がタイムゾーンデータモデル１４１０（親データモデル）を継承するという意味を表す。つまり、商品データモデル１４２０は、タイムゾーンデータモデル１４１０のデータ項目（１４１１〜１４１８）を持つという設定である。すなわち、１４２３は、第１データモデルの定義を第２データモデルが継承する設定を受け付ける手段の一例である。これにより、タイムゾーンデータモデル１４１０を親、商品データモデル１４２０を子とする、データモデルの継承設定ができる。

また、商品データモデル独自のデータ項目（１４２１及び１４２２）及び継承設定１４２３は変更可能に表示する。すなわち、図１４の１４２１〜１４２３は、データモデルの定義の編集を受け付ける手段の一例である。

なお、本実施形態においては、子データモデル定義画面において親データモデルを指定するとしたが、この方法に限定するものではなく、その他の親データモデルの指定方法、親データモデル定義画面において子データモデルを指定する方法、又は、親子（継承）関係を定義する画面において親データモデル及び子データモデルの両者を指定する方法等であってもよい。

図１５は、継承関係を持つデータモデル定義画面１５００の一例である。図１４と異なる設定方法であるが、継承の設定内容は同じである。

タイムゾーンデータモデル１４１０の設定画面は、図１４と同じである。

一方、商品データモデル１５２０の設定画面では、継承元となる親データモデルとしてタイムゾーンデータモデル１４１０の選択を受け付けた（図１５の１５４１）場合、商品データモデル独自のデータ項目（１５２１及び１５２２）は変更可能に表示し、継承したタイムゾーンデータモデル１４１０のデータ項目は変更不可能に表示する（１５２３〜１５３０）。ここでは、変更不可能なデータ項目を網掛け１５４０で表示し、変更不可能であることを識別して表示している。

すなわち、図１５の１５２１及び１５２２は、データモデルの定義の編集を受け付ける手段の一例である。また、図１５の１５４０は、第２データモデルの定義の編集を受け付ける画面に表示された第１データモデルの定義の編集を抑止するよう制御する手段の一例である。また、図１５の１５４０は、第２データモデルの定義の編集を受け付ける画面に第１データモデルの定義を識別して表示する手段の一例である。また、図１５の１５４１は、第１データモデルの定義を第２データモデルが継承する設定を受け付ける手段の一例である。

なお、本実施形態においては、変更不可能なデータ項目を網掛け１５４０で識別して表示するとしたが、この方法に限定するものではなく、グレー文字等の異なるフォントで表示したり、１５４０のように枠で囲んだり、変更可能なデータ項目と識別できる方法であれば他の方法であってもよい。

これにより、１５２３〜１５３０はデータモデルの継承であり、商品データモデル１４２０（子データモデル）がタイムゾーンデータモデル１４１０（親データモデル）を継承していることがわかる。

図１６は、データモデル定義画面１４００又は１５００にて設定した、継承関係を持つタイムゾーンデータモデル（親データモデル）及び商品データモデル（子データモデル）のデータモデル定義ＸＭＬの一例を示す図である。

親データモデル定義ＸＭＬ１６１０の記述は、図９の記述方法と同じだが、子データモデル定義ＸＭＬ１６２０の記述には、＜ｐａｒｅｎｔ−ｄｍ＞＜ｄｍ−ｃｏｄｅ＞ＴＩＭＥＺＯＮＥ＿ＤＭ＜／ｄｍ−ｃｏｄｅ＞＜／ｐａｒｅｎｔ−ｄｍ＞のように親データモデルを指定する記述を持つ。

なお、本実施形態においては、子データモデル定義ＸＭＬ１６２０に＜ｐａｒｅｎｔ−ｄｍ＞タグのような親データモデルを指定する記述を持つとしたが、この記述方法に限定するものではなく、その他のタグを用いる方法、親データモデル定義ＸＭＬ１６１０に子データモデルを指定する記述を持つ方法、又は、テーブルやファイル等に親子（継承）関係を記憶する方法等であってもよい。

図１６のようなデータモデル定義ＸＭＬにした場合、ステップＳ５０９にてＳＱＬ文を生成する際に、ステップＳ５０４にて取得したデータモデル定義４０４の継承関係に基づき、親データモデル定義のデータ項目を用いて、子データモデル定義を利用するＳＱＬ文を生成し、アプリケーションを構築する。すなわち、図１４〜図１６を用いたステップＳ５０８〜５１０は、第２データモデルを用いてデータの操作を行う場合には第１データモデルの定義に基づく定義を用いてデータの操作を行うアプリケーションを構築する処理の一例を示すステップである。

具体的には、ステップＳ６０１及びステップＳ６０２においてデータモデル定義４０４の加工式８０１を取得したり、ステップＳ６０３及びステップＳ６０４においてデータモデル定義４０４を用いたＳＱＬを作成したりする際に、そのデータモデル定義４０４に親データモデル定義の設定が存在する場合は、親データモデル定義に設定されている加工式やデータ項目を参照してＳＱＬを作成する。

また、アプリケーション構築ツールが、データモデル定義４０４に基づき、Ｊａｖａ（登録商標）などのオブジェクト指向言語でアプリケーションプログラムを生成する場合（図５のステップＳ５０８）、親データモデル定義のプログラムを継承するようにして子データモデル定義のプログラムを生成してもよい。すなわち、ステップＳ５０８は、第２データモデルの定義の情報は、第１データモデルの定義の情報を継承することを示す情報を持たせる処理の一例を示すステップである。これにより、継承関係を持つデータモデル定義を、継承関係を維持したままプログラム化することができるため、プログラムの生成方法や管理方法が容易になる。

以上により、証跡情報のような同じ項目を複数のデータモデル定義として設定する必要がなくなるため、同じ証跡情報項目を持つデータモデルをテーブルの数分設定し、それらのデータモデルを介して証跡情報の登録及び更新をしなければならないという問題を解決でき、データモデル定義を利用するアプリケーションを容易に構築することができるようになる。

また、証跡情報のような同じ項目を複数のデータモデル定義として設定する必要がなくなるため、データモデルを定義する設定量も減り、アプリケーションの開発効率を上げることができる。

また、親データモデルに仕様変更が発生した場合であっても、親データモデルの定義のみを変更すればよいため、子データモデルに影響が及ばず、アプリケーションの開発効率を上げることができる。すなわち、図１４〜図１６を用いたステップＳ５０８〜５１０は、第１データモデルの定義の編集を受け付けた後に第２データモデルを用いてデータの操作を行う場合には編集に従って変更した第１データモデルの定義に基づく定義を用いてデータの操作を行うアプリケーションを構築する処理の一例を示すステップである。

なお、本実施形態においては、データモデル間で継承する項目として証跡情報を例に挙げたが、証跡情報に限定するものではなく、例えば、「ＳＥＱ＿ＮＯ」のようなデータ登録の通し番号項目、「ＤＡＴＡ＿ＳＴＡＴＵＳ」のようなデータ状態を表す項目、「ＤＥＬＥＴＥ＿ＦＬＡＧ」のような論理削除を示すフラグ等、証跡情報以外の項目であってもよい。

また、本実施形態においては、親データモデルのデータ項目をすべて子データモデルに継承するとしたが、この継承方法に限定するものではなく、例えば、親データモデルのデータ項目のうち、選択されたデータ項目のみを継承するような継承方法であってもよい。

また、本実施形態においては、継承関係を親データモデル：子データモデル＝１：多としたが、この関係に限定するものではなく、例えば、複数の親データモデルのデータ項目を継承するような親データモデル：子データモデル＝多：多であってもよい。

なお、データモデル定義画面１４００又は１５００にて継承関係を持つと設定した場合であっても、図１６のような継承関係を記憶するデータモデル定義ＸＭＬではなく、図９のように継承関係を持たないデータモデル定義ＸＭＬとして記憶するとしてもよい。その場合は、ステップＳ６０１及びステップＳ６０２においてデータモデル定義４０４の加工式８０１を取得したり、ステップＳ６０３及びステップＳ６０４においてデータモデル定義４０４を用いたＳＱＬを作成したりする際に、データモデルの継承関係を意識する必要はない。

すなわち、図１４、図１５及び図９を用いたステップＳ５０８は、第１データモデルの定義に基づき、第２データモデルの定義を生成する処理の一例を示すステップである。また、図１４、図１５及び図９を用いたステップＳ５０８〜５１０は、第２データモデルの定義を用いてデータの操作を行うアプリケーションを構築する処理の一例を示すステップである。

ただし、図９のようなデータモデル定義ＸＭＬの場合、子データモデルの定義において、＜ｄｍ−ｃｏｄｅ＞ＴＩＭＥＺＯＮＥ＿ＤＭ＜／ｄｍ−ｃｏｄｅ＞のように記述し、どの親データモデルから継承したデータ項目かわかるようにしておき、親データモデルに仕様変更が発生し、親データモデルの定義を変更した場合は、子データモデルにもその変更を反映する。

すなわち、図１４、図１５及び図９を用いたステップＳ５０８は、編集に従って変更した第１データモデルの定義に基づき、設定を受け付けた第２データモデルの定義を生成する処理の一例を示すステップである。

なお、本実施形態においては、親データモデルから継承した網掛け１５４０部分は変更不可能なデータ項目としたが、この方法に限定するものではなく、子データモデルを生成する際にのみ親データモデルのデータ項目を参照しコピーし、子データモデル生成後はコピーしたデータ項目を変更できるとしてもよい。この場合は、図９のように継承関係を持たないデータモデル定義ＸＭＬとして記憶した方が管理し易いため好ましい。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

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

また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ 情報処理装置
１０２ プログラム生成サーバ
１０３ データベースサーバ
１０４ アプリケーションクライアント
１０５ アプリケーションサーバ
１０６ ネットワーク

Claims (11)

1. データベースのデータの操作に用いるデータモデルの定義を記憶するデータモデル記憶手段を備え、前記データベースに接続するアプリケーションを構築する情報処理装置であって、
   前記構築するアプリケーションで用いる第２データモデルの定義に任意の定義の設定を受け付ける定義受付手段と、
   前記定義受付手段により受け付けた定義と組み合わせる、前記データモデル記憶手段に記憶されている第１データモデルの定義を、前記アプリケーションで用いる第２データモデルの定義の一部として設定を受け付ける設定受付手段と、
   前記定義受付手段により設定を受け付けた定義と前記設定受付手段により設定を受け付けた前記第１データモデルの定義を用いて第２データモデルに対応するアプリケーションを構築するアプリケーション構築手段と
   を備えることを特徴とする情報処理装置。
2. 前記アプリケーション構築手段は、
   前記設定受付手段により設定を受け付けた第２データモデルの前記データの操作を行う場合には前記設定受付手段により設定を受け付けた第１データモデルの定義に基づく定義を用いて前記データの操作を行うアプリケーションを構築すること
   を特徴とする請求項１に記載の情報処理装置。
3. 前記データモデルの定義の編集を受け付けるデータモデル編集受付手段を更に備え、
   前記データモデル編集受付手段は、
   前記第２データモデルの定義の編集を受け付ける画面に表示された前記第１データモデルの定義の編集を抑止するよう制御すること
   を特徴とする請求項１又は２に記載の情報処理装置。
4. データベースのデータの操作に用いるデータモデルの定義を記憶するデータモデル記憶手段を備え、前記データベースに接続するアプリケーションを構築する情報処理装置であって、
   前記構築するアプリケーションで用いる第２データモデルの定義に任意の定義の設定を受け付ける定義受付手段と、
   前記定義受付手段により受け付けた定義と組み合わせる、前記データモデル記憶手段に記憶されている第１データモデルの定義を、前記アプリケーションで用いる第２データモデルの定義の一部として設定を受け付ける設定受付手段と、
   前記第１データモデルの定義に基づき、前記第２データモデルの定義を生成するデータモデル生成手段と、
   前記データモデル生成手段により生成された第２データモデルの定義を用いてアプリケーションを構築するアプリケーション構築手段と
   を備えることを特徴とする情報処理装置。
5. 前記データモデルの定義の編集を受け付けるデータモデル編集受付手段を更に備え、
   前記データモデル生成手段は、
   前記データモデル編集受付手段により受け付けた編集に従って変更した第１データモデルの定義に基づき、前記設定受付手段により設定を受け付けた第２データモデルの定義を生成すること
   を特徴とする請求項４に記載の情報処理装置。
6. 前記データモデル編集受付手段は、
   前記第２データモデルの定義の編集を受け付ける画面に前記第１データモデルの定義を識別して表示すること
   を特徴とする請求項５に記載の情報処理装置。
7. データベースのデータの操作に用いるデータモデルの定義は、前記アプリケーションの実行時にデータの操作に用いるクエリを動的に生成するための条件を含む定義であって、
   前記アプリケーション構築手段は、前記第２データモデルの定義を用いて前記データの操作を行うクエリを動的に生成するアプリケーションを構築することを特徴とする請求項１乃至６に記載の情報処理装置。
8. データベースのデータの操作に用いるデータモデルの定義を記憶するデータモデル記憶手段を備え、前記データベースに接続するアプリケーションを構築する情報処理装置における処理方法であって、
   前記情報処理装置が、
   前記構築するアプリケーションで用いる第２データモデルの定義に任意の定義の設定を受け付ける定義受付ステップと、
   前記定義受付ステップにより受け付けた定義と組み合わせる、前記データモデル記憶手段に記憶されている第１データモデルの定義を、前記アプリケーションで用いる第２データモデルの定義の一部として設定を受け付ける設定受付ステップと、
   前記定義受付ステップにより設定を受け付けた定義と前記設定受付ステップにより設定を受け付けた前記第１データモデルの定義を用いて第２データモデルに対応するアプリケーションを構築するアプリケーション構築ステップ
   を実行することを特徴とする処理方法。
9. データベースのデータの操作に用いるデータモデルの定義を記憶するデータモデル記憶手段を備え、前記データベースに接続するアプリケーションを構築する情報処理装置における処理方法であって、
   前記情報処理装置が、
   前記構築するアプリケーションで用いる第２データモデルの定義に任意の定義の設定を受け付ける定義受付ステップと、
   前記定義受付ステップにより受け付けた定義と組み合わせる、前記データモデル記憶手段に記憶されている第１データモデルの定義を、前記アプリケーションで用いる第２データモデルの定義の一部として設定を受け付ける設定受付ステップと、
   前記第１データモデルの定義に基づき、前記第２データモデルの定義を生成するデータモデル生成ステップと、
   前記データモデル生成ステップにより生成された第２データモデルの定義を用いてアプリケーションを構築するアプリケーション構築ステップ
   を実行することを特徴とする処理方法。
10. データベースのデータの操作に用いるデータモデルの定義を記憶するデータモデル記憶手段を備え、前記データベースに接続するアプリケーションを構築する情報処理装置で実行可能なプログラムであって、
    前記情報処理装置を、
    前記構築するアプリケーションで用いる第２データモデルの定義に任意の定義の設定を受け付ける定義受付手段と
    前記定義受付手段により受け付けた定義と組み合わせる、前記データモデル記憶手段に記憶されている第１データモデルの定義を、前記アプリケーションで用いる第２データモデルの定義の一部として設定を受け付ける設定受付手段と、
    前記定義受付手段により設定を受け付けた定義と前記設定受付手段により設定を受け付けた前記第１データモデルの定義を用いて第２データモデルに対応するアプリケーションを構築するアプリケーション構築手段
    として機能させるためのプログラム。
11. データベースのデータの操作に用いるデータモデルの定義を記憶するデータモデル記憶手段を備え、前記データベースに接続するアプリケーションを構築する情報処理装置で実行可能なプログラムであって、
    前記情報処理装置を、
    前記構築するアプリケーションで用いる第２データモデルの定義に任意の定義の設定を受け付ける定義受付手段と、
    前記定義受付手段により受け付けた定義と組み合わせる、前記データモデル記憶手段に記憶されている第１データモデルの定義を、前記アプリケーションで用いる第２データモデルの定義の一部として設定を受け付ける設定受付手段と、
    前記第１データモデルの定義に基づき、前記第２データモデルの定義を生成するデータモデル生成手段と、
    前記データモデル生成手段により生成された第２データモデルの定義を用いてアプリケーションを構築するアプリケーション構築手段として機能させるためのプログラム。
    

Images