JP5542857B2 - クエリ発行装置、クエリ発行プログラム、クエリ発行方法 - Google Patents

Description

本発明の実施形態は、参照、挿入、更新、削除の各操作を行うためのクエリを生成し、データベースに発行する技術に関する。

企業業務に用いられるデータは、一般的に関係データベース管理システム（ＲＤＢＭＳ）で管理されており、ＲＤＢＭＳへＳＱＬ文（クエリ）を発行することで、データ取得や登録、削除、更新の処理が行われる。また業務システムは、複数のクライアントと１つまたは複数のサーバ群により構成されるクライアント−サーバシステムが採用される。

また業務システムでは、システム運用時に利用者がデータベース（以下、ＤＢと称す）内のデータを操作する際、使用上の手間や各テーブル間、カラム間のデータ不整合を防止するため、利用者が直接ＳＱＬ文を記述してＤＢへ発行することは稀である。通常は、利用者の観点で分類（カテゴリ化）された業務内容や処理内容に関する情報をシステムが受け付け、この情報に基づき、システムがＳＱＬ文を作成してＤＢへ発行する、という実装が採用される。よって、ＳＩベンダー等、ＤＢの設計や構築に携わる者は、利用者の観点に立脚して業務内容や処理内容を分類し、この分類分けに基づきＤＢを設計、構築していく。

関連技術として、以下の文献が開示されている。

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

ＤＢを構築する際、依頼元の企業ごとに、その企業に適合するようにＤＢを構築する必要があり、企業に適合したクエリを生成し、発行するシステムを、企業ごとに都度実装する必要がある。また依頼元の企業に現存のＤＢがあり、新規システムに移行する場合、現存ＤＢ内の各データを新設のＤＢへ移行する作業が発生する。この際、既存ＤＢの物理構造に応じた検索、更新、登録、削除のクエリを実装する必要がある。

本発明が解決しようとする課題は、利用者観点である論理視点と、ＤＢの物理的定義（物理視点。実データが保持されているＤＢ内のテーブル定義やカラム定義）とを対応付けた情報を用いることで、物理データを意識しないアクセスを実現するとともに、この対応情報を用いることで、データアクセス処理の機能を一部汎用化させ、構築期間の短縮を図ることが可能な技術を提供することである。

実施形態のクエリ発行装置は、保持部と、処理部とを有する。保持部は、利用者の観点で区分けされた処理内容に関する情報である論理情報と、操作対象となるデータベースのテーブル定義情報およびカラム定義情報を少なくとも含む情報である物理情報と、を対応付けて保持する。処理部は、論理情報を特定する情報である第１情報を取得し、保持部で保持された対応付けおよび第１情報に基づき、データベース内のデータを操作するクエリを作成し、クエリをデータベースに発行する。

また実施形態のクエリ発行装置は、保持部と、処理部とを有する。保持部は、第１のデータベースのテーブル定義情報およびカラム定義情報を少なくとも含む第１物理情報と、第２のデータベースのテーブル定義情報およびカラム定義情報を少なくとも含む第２物理情報と、を対応付けて保持する。処理部は、第１物理情報を特定する第１情報を取得し、保持部で保持された対応情報および第１情報に基づき、第２のデータベース内のデータを操作するクエリを作成し、クエリを第２のデータベースに発行する。

実施形態の業務システムの構成例を示す図である。 実施形態の業務システムのブロック図の一例を示す図である。 実施形態のメタＤＢのデータモデルの一例を示すＥＲ図である。 実施形態のメンテナンス項目エンティティの一例を示す図である（その１）。 実施形態のメンテナンス項目エンティティの一例を示す図である（その２）。 実施形態の画面表示部が表示するテーブル型レイアウトの一例を示す図である。 実施形態の画面表示部が表示するツリー型レイアウトの一例を示す図である。 実施形態の業務システムの物理データ抽出時（検索時）の動作例を示すフローチャートである。 実施形態の抽出用クエリ生成処理の動作例を示すフローチャートである。 実施形態の物理データ抽出処理の動作例を示すフローチャートである。 実施形態の抽出データ表示処理の動作例を示すフローチャートである。 実施形態の業務システムの物理データ登録、更新、削除時の動作例を示すフローチャートである。 実施形態の物理データの登録、更新、削除の可否を検証する処理の動作例を示すフローチャートである。 実施形態の物理データの登録、更新、削除用のクエリを生成する処理の動作例を示すフローチャートである（その１）。 実施形態の物理データの登録、更新、削除用のクエリを生成する処理の動作例を示すフローチャートである（その２）。 実施形態の態様を適用させた応用例の構成を示す図である。

図１は、業務システムのハードウェア構成例を示す図である。本実施形態の業務システムは、主に顧客からの問い合わせや相談、受注や修理等の窓口であるコールセンター業務を管理するシステムである。また以下では、主にコールセンター業務で用いられるＤＢのマスタデータ（物理データ）の検索、登録、更新、削除を行うときの操作例について説明する。尚、マスタデータの更新等の作業は、専らシステム保守時（メンテナンス時）に行われるため、以下の実施形態ではテーブルやエンティティに「メンテナンス」という用語が用いられているが、態様は保守時等に限定されない。また上記の業務システム以外にも本実施形態の態様を適用することができる。

業務システム１００は、クライアント端末１、アプリケーションサーバ２（クエリ発行装置）、ＤＢサーバ３の３階層システム（３層アーキテクチャ）で実装されている。これら各装置は、それぞれがプロセッサやメモリ、ハードディスクドライブ等の従前のユニットで構成されるコンピュータである。また必要に応じて、それぞれ複数台で構成されてもよい。

クライアント端末１とアプリケーションサーバ２とは、本実施形態ではネットワーク４Ａを介して互いに通信可能であり、アプリケーションサーバ２とＤＢサーバ３とは、本実施形態ではネットワーク４Ｂを介して互いに通信可能である。このネットワーク構成はあくまでも一例である。

クライアント端末１は、例えば据え置き型ＰＣ（ＰＣ：パーソナルコンピュータ）やスレートＰＣ、タブレットＰＣであり、演算処理装置であるプロセッサ、主記憶装置であるメモリ、フラッシュメモリやＨＤＤ（ハードディスクドライブ）等の補助記憶装置を有する。またクライアント端末１は、外部とのデータ通信を制御する通信デバイス、モニター等の表示装置、キーボード、マウス等の入力装置を有する。表示装置、入力装置はタッチパネルディスプレイであっても構わない。これら各ユニットはデータバスを介して互いにコマンド送受信、データ送受信を行っている。

アプリケーションサーバ２は、クライアント端末１と同様にプロセッサ、メモリ、補助記憶装置や通信デバイスを有する据え置き型のコンピュータである。アプリケーションサーバ２は、クライアント端末１からの指示に基づき、ＤＢサーバ３に保持されている物理データを検索、登録、削除、更新（以下、必要に応じてこれらを「操作」と総称する）を行うためのクエリを生成する。またアプリケーションサーバ２は、生成したクエリをＤＢサーバ３へ発行して検索結果や処理後のステータスを受信し、クライアント端末１へ送信する。アプリケーションサーバ２内のメモリには、メタ情報が記憶される。メタ情報とは、ＤＢサーバ３に格納されているＤＢのテーブル名やカラム名等の物理的な定義情報と、利用者の観点に立脚して処理内容が分類された情報とを対応付けたＤＢである。詳細については後述する。

ＤＢサーバ３は、ＲＤＢＭＳが事前に導入されており、操作対象となる物理データ（実データ）を永続的に保持している。本実施形態で用いられるＲＤＢＭＳとして、現在市場に流通しているＲＤＢＭＳを流用することができる。ＤＢサーバ３は、アプリケーションサーバ２からの検索用クエリに応じて、保持している物理データをアプリケーションサーバ２へ送信し、また、アプリケーションサーバ２からの登録、削除、更新用のクエリに応じて、物理データの登録、削除、更新を行う。

図２に、業務システム１００の機能ブロックの一例を示す。業務システム１００は、画面表示部１０、処理部２０、ＤＢ制御部３０の機能部を有し、またＤＢとして、メタＤＢ２３、物理ＤＢ３１を有する。図２に示す各機能部は、クライアント端末１、アプリケーションサーバ２、ＤＢサーバ３に事前に導入されたアプリケーションが、各装置内のメモリにロードされ、各装置内のプロセッサで演算実行されることで実現される。

画面表示部１０は、図１のクライアント端末１に相当し、利用者に所定のレイアウトでメタＤＢ２３や物理ＤＢ３１内のデータを表示し、また利用者からの入力を受け付け、ＤＢ操作の指示電文を生成し、処理部２０へ指示電文を送信する。

処理部２０は、データ送受信部２１、クエリ生成部２２を有する。データ送受信部２１は、画面表示部１０、クエリ生成部２２、ＤＢ制御部３０間のデータの送受信を司る機能部である。データ送受信部２１は、クエリ生成部２２が生成したクエリをＤＢ制御部３０へ発行し、また必要に応じて自らがクエリを生成し、ＤＢ制御部３０へ発行する。クエリ生成部２２は、メタＤＢ２３内で定義されている情報に基づき、ユーザからの要求に対応したクエリを生成する。尚、処理部２０（データ送受信部２１およびクエリ生成部２２）が、図１のアプリケーションサーバ２に相当する。また、以下に説明する処理が行われる際、メタＤＢ２３のデータは、アプリケーションサーバ２内のメモリ（保持部）にロードされ、アプリケーションサーバ２に取り込まれる。

ＤＢ制御部３０は、クエリ生成部２２で生成されたクエリを、データ送受信部２１を介して受信し、クエリに応じた操作を物理ＤＢ３１に行う。ＤＢ制御部３０は、受信したクエリが検索用のクエリである場合、物理ＤＢ３１から対象となる物理データを検索し、検索結果である物理データを処理部２０に送信する。またＤＢ制御部３０は、受信したクエリが登録、更新、削除用のクエリである場合、物理ＤＢ３１内のデータについて、登録、更新、削除の処理を行い、処理成功や失敗等のステータスデータを処理部２０に送信する。

物理ＤＢ３１は、運用時に用いられる実データや、更新日、更新者、権限等の管理データを定義付けて蓄積するＤＢである。物理ＤＢ３１では、１：Ｎや１：Ｎ：Ｎ（Ｎは複数を意味する）などのテーブル間の関連性（リレーション）も管理される。

ＤＢ制御部３０、物理ＤＢ３１を含んだ構成が、図１のＤＢサーバ３に相当し、ＤＢ制御部３０、物理ＤＢ３１でＲＤＢＭＳパッケージが構成される。またメタＤＢ２３は、本実施形態では、ＤＢサーバ３内のハードディスクドライブに永続的に記憶されている。上述通り、メタＤＢ２３内のデータは、実行処理時にはアプリケーションサーバ２内のメモリ（保持部）にロードされ、アプリケーションサーバ２内に記憶される。図２の例は、メタＤＢ２３がアプリケーションサーバ２内に取り込まれている状態を示しており、以降の説明も同様とする。尚、メタＤＢ２３を永続的にアプリケーションサーバ２内のハードディスクドライブに記憶させる実装でもよい。

図３は、メタＤＢ２３内で管理されるデータモデルを具体的に示した図であり、メタＤＢ２３内に記憶されている各エンティティの関係を、ＩＥ表記法（ＩＥ：インフォメーション・エンジニアリング）で示したＥＲ図である。尚、図３に示す各ブロックは、実際にはメタＤＢ２３内ではテーブルとして実装されているが、以下の説明では、物理ＤＢ３１内の各テーブルと区別するため、エンティティと称する。また図３の各ブロック最上段には、「メンテナンス種別マスタ／ＭＮＴ＿ＴＹＰＥ＿ＭＳＴ」等のエンティティ名称やエンティティ物理名（テーブル名）が示されており、その下段には当該エンティティ内で定義されているデータ項目が示されている。データ項目の欄は、例えば「（ＰＫ）メンテナンス種別ＩＤ」、「ＭＮＴ＿ＴＹＰＥ＿ＩＤ」、「ＮＵＭＢＥＲ（ＮＮ）」など、データ項目名称、物理名（カラム名）、データ型の順で示されている。データ項目内の（ＰＫ）の表記は、当該エンティティのプライマリキー（主キー）であることを意味し、また（ＦＫ）の表記は外部キーを意味する。

また図３には、エンティティ間のリレーションも示されており（エンティティ同士の関係が、いわゆる「鳥の足」で示されている）、１：１の関係や、１：Ｎ、１：Ｎ：Ｎ関係も示されている。

図３に示されているエンティティ名やデータ項目、リレーションは、あくまでメタＤＢ２３内で管理されているテーブルやカラム、リレーションを示すものであり、物理ＤＢ３１のテーブルやカラムを示すものではないことに留意する。

メタＤＢ２３は、利用者観点に立脚した情報である論理情報と、物理データに関する情報である物理情報とを、エンティティやリレーションで対応付けたデータ構造を有している。論理情報とは、本実施形態では、例えば「商品Ａの値段に関する問い合わせの内容をＤＢに登録する」、「特定部署に所属している社員の情報を更新する」、「所定商品の販売を行うため情報を登録する」、「所定製品の単価を変更する」等の利用者側に立脚したＤＢ操作や、このような操作を行うためのＤＢへの操作順番などを定義した情報である。論理情報には、画面表示部１０の表示レイアウトや表示用の文字列（ラベル）も含まれる。

一方、物理情報とは、上述の通り、実データを保持している物理ＤＢ３１内のテーブル定義、カラム定義である。尚、本実施形態では、複数テーブルの結合方法や、テーブル操作を行うことができるか否かのフラグデータもテーブル定義（物理情報）に含め、また当該カラムがキーであるかの情報もカラム定義（物理情報）に含める。

図３を参照して、より具体的に説明すると、論理観点についての定義情報は、主にメンテナンス種別マスタエンティティ、メンテナンスユニット、メンテナンス情報、メンテナンス項目の各エンティティに具現化されている。また物理ＤＢ３１で管理されているテーブルやカラム等の定義情報（物理情報）は、主に、対象テーブル、対象テーブルカラムの各エンティティに具現化されている。クエリ生成部２２は、この対応関係に基づきＤＢ制御部３０へ発行するためのクエリを生成する。

ここで、主要となるエンティティについて説明する。
まずは、メンテナンス種別マスタエンティティ内の各データ項目について説明する。メンテナンス種別マスタエンティティは、主に画面表示部１０の表示に関して定義付けするためのエンティティである。
・メンテナンス種別ＩＤ・・・メンテナンス時の方式や画面表示部１０で表示されるレイアウト（テーブル型やツリー型等）を区別するＩＤ。
・メンテナンス種別名・・・メンテナンス種別を表す名前である。メンテナンス種別には、１：単純ツリー構造、２：複層ツリー構造、３：一覧、がある。
・メンテナンスモジュール生成クラス・・・メンテナンスレイアウトなどを生成、定義するためのクラス。
・メンテナンスモジュールクライアントクラス・・・物理ＤＢ３１内のデータを編集するエディタプログラムのＦＱＣＮ（完全修飾クラス名）。
尚、本実施形態において、クラスとは実行モジュールのことである。上記のようにデータ項目名に「クラス」とあるものは、実行モジュールを特定するための情報（例えばＦＱＣＮで示した文字列やフォルダ名、ファイル名）が格納される（以下同様）。導入先企業に応じた特殊なカスタマイズが必要となる場合があるため、本実施形態では、カスタマイズが必要となる機能については、外部の実行モジュールとして指定し、その外部実行モジュールを起動させる実装となっている。このように、カスタマイズが必要なものについては外部へ出し、そのインターフェイスとなる部分をデータで保持することで、システムとしてはより汎用性を高めることができる。実行モジュールは、システムを導入する先々に応じて作成されてもよいし、予め作成済みのモジュールであってもよい。

次に、メンテナンスユニットエンティティ内の各データ項目について説明する。メンテナンスユニットエンティティは、１つのメンテナンス機能（後述のメンテナンス情報エンティティ）を論理的にまとめ、グループ化するためのエンティティである。
・メンテナンスユニットＩＤ・・・このメンテナンスユニットを識別するための情報。
・メンテナンスユニット名・・・このメンテナンスユニットの名前。画面表示部１０には、このメンテナンスユニット名がメンテナンス名として表示される。
・メンテナンス種別ＩＤ・・・メンテナンス種別を表す名前。メンテナンス種別マスタエンティティを参照する外部キー。

メンテナンス情報エンティティ内の各データ項目について説明する。メンテナンス情報エンティティは、１つのメンテナンス機能において、データ内容や処理を論理的に区別するためのエンティティである。メンテナンス機能は、例えば「全ての商品に関する問い合わせデータは、同じメンテナンス機能で行う」や、「商品Ａに関する全ての情報は、同じメンテナンス機能で行う」等、利用者の観点で区分される。
・メンテナンスＩＤ・・・このメンテナンス情報を識別するための情報。
・メンテナンスユニットＩＤ・・・メンテナンス種別を表す名前。上記メンテナンスユニットエンティティを参照する外部キー。
・ユニット内順番・・・メンテナンスユニット内での、このメンテナンス情報の順位を示す値であり、データ処理の順番や画面表示時の順番などを示す。
・メンテナンス名・・・このメンテナンス情報を表す名称であり、画面表示部１０で表示する際に使用される文字列（ラベル）である。
・権限オブジェクトＩＤ・・・利用者が操作を行えるかどうかを定義したＩＤ。メンテナンス権限エンティティの主キーが定義される。
・最小有効階層・・・ツリー構造であるとした場合に、データとして最低限何階層必要かを示す値である。
・最大有効階層・・・ツリー構造であるとした場合に、データとして最大何階層必要かを示す値である。
・下位データ接続種別ＩＤ・・・下位データに接続する方法を区別するＩＤ。下位データ接続種別マスタエンティティを参照する外部キーである。
・抽出条件ＳＱＬ・・・メンテナンス対象のデータ（物理ＤＢ３１内の物理データ）を抽出するためのＳＱＬが定義されており、各エンティティで定義されない、カスタマイズされたＳＱＬ（ＷＨＥＲＥ句への追加条件）が定義される。

メンテナンス項目エンティティ内の各データ項目について説明する。メンテナンス項目エンティティは、主に、論理情報の最小単位を定義したエンティティであり、論理情報と物理ＤＢ３１内のカラムとを対応付けるためのエンティティである。
・メンテナンス項目ＩＤ・・・このメンテナンス項目を区別するＩＤである。
・メンテナンスＩＤ・・・上記メンテナンス情報エンティティを参照する外部キーである。
・メンテナンス情報内順番・・・メンテナンス情報内での順番を表し、メンテナンス情報のくくりで、このメンテナンス項目のデータ処理順や画面表示の際の表示順が定義されている。
・メンテナンス項目名・・・メンテナンス対象カラムの物理キー名を表し、データ取得の際のキーとして利用される。ここに、物理ＤＢ３１のカラム名が定義される。
・メンテナンス項目論理名・・・メンテナンス対象カラムを表す名称。画面表示部１０で表示する際に使用される。
・下位メンテナンス項目ＩＤ・・・下位のメンテナンス項目に接続する際の、結合先キーとなるＩＤである。
・ソート順・・・メンテナンス情報を取得する際のレコードのソート順を決める項目が定義される。
・ソート種別コード・・・ソート種別を示すコード。１：正順、２：逆順。
・表示フラグ・・・この項目を画面表示部１０に表示させるかを定義するフラグデータ。
・編集種別コード・・・この項目を編集可否などのモードを指定するコード。０：編集不可、１：常時編集可能、２：新規のみ編集可能、３：更新時のみ編集可能、のいずれかの値が定義される。
・ラベルデータ項目フラグ・・・画面表示部１０でメンテナンス情報を編集する際に、画面上に表示されるラベル項目（ツリー表示におけるフォルダ名、一覧表示における固定スクロール項目など）であるかどうかを表すフラグ。
・ラベルデータ項目順番・・・ラベルデータを画面表示に使用する際の、表示する順番が定義されている。この順番を利用することで、ラベルデータの表示する範囲や方法を変えることが可能となる。
・入力フォーム形式ＩＤ・・・画面表示部１０で表示される入力フォームの形式を区別するＩＤ。入力フォームには、テキスト型、複数行テキスト型、選択リスト型、入力可能選択リスト型、チェックボックス型、ラジオボックス型、年月日型、時間型などがある。
・参照選択肢ＩＤ・・・参照選択肢を区別するＩＤ。メンテナンス参照選択肢エンティティを参照する外部キーである。
・選択肢ＩＤ・・・選択肢を区別するＩＤ。
・標準値指定種別ＩＤ・・・標準値指定種別を区別するＩＤであり、標準値指定種別マスタエンティティを参照する外部キーである。１：ログイン者ユーザＩＤ、２：ログイン者組織ＩＤ、３：ＳＹＳＤＡＴＥ、９９：固定値がＩＤとして定義され、いずれかの数値が格納されている。
・標準値・・・標準値指定種別ＩＤで「９９：固定値」が定義されている場合に、この標準値には、適用される固定値が定義される。
・シーケンス名・・・物理ＤＢ３１へのレコードの新規登録を行う際、シーケンスからの発番を必要とするカラムの場合、そのシーケンス名が定義される。尚、シーケンスは発番プログラムであり、ＤＢ制御部３０の機能として提供される。
・シーケンス発番クラス・・・物理ＤＢ３１へのレコード新規登録時に特殊な方法でのシーケンス発番を必要とするカラムの場合に、そのクラス名（発番する実行モジュール）を指定する。
・下位データ接続項目ＩＤ・・・このメンテナンス情報における子孫データ（下位データ）に接続する際に使用するカラムを特定するための項目ＩＤ。
・書式種別ＩＤ・・・カラムの書式種別を区別するＩＤであり、カラム書式種別マスタエンティティを参照する外部キーである。書式種別ＩＤには、例えば「半角入力」、「西暦年月日」、「整数」、「メールアドレス」等がある。

次に、対象テーブルエンティティ内の各データ項目について説明する。対象テーブルエンティティには、物理ＤＢ３１内の各テーブル名が定義されており、複数の物理テーブルを指定する場合はどのように結合するか、またここで定義された物理テーブルを操作することが可能か否かを定義するエンティティである。
・メンテナンステーブルＩＤ・・・この対象テーブルエンティティを区別するためのＩＤである。
・メンテナンスＩＤ・・・メンテナンス情報エンティティを参照する外部キーである。
・メンテナンス順番・・・メンテナンス実行時の順番を示す。登録、更新時は正順、削除時は逆順で処理される。
・メンテナンステーブル名・・・物理ＤＢ３１内のテーブル物理名。
・メンテナンステーブル別名・・・物理テーブルを一意に特定できるテーブル別名。
・テーブル結合順番・・・メンテナンス情報エンティティ内でのテーブル結合の順番を示す値であり、ＦＲＯＭ句内の順番を表す。
・テーブル結合インデント・・・１つのメンテナンス機能内で結合される各テーブルのインデントであり、ＦＲＯＭ句内での結合の包含関係を表す。
・テーブル結合種別コード・・・テーブルの結合方式を示すコードであり、０：結合不要、１：内部結合、２：外部結合のコードが定義される。
・テーブル結合条件ＳＱＬ・・・テーブル結合のＯＮ句内に記述されるＳＱＬである。
・作成可能フラグ、更新可能フラグ、削除可能フラグ・・・物理テーブルに対して各操作が可能か否かを表すフラグである。

対象テーブルカラムエンティティ内の各データ項目について説明する。対象テーブルカラムエンティティは、物理ＤＢ３１内で管理されているテーブルの物理カラムを定義したエンティティである。
・メンテナンスカラムＩＤ・・・この対象テーブルカラムエンティティを区別するためのＩＤである。
・メンテナンステーブルＩＤ・・・対象テーブルエンティティを参照する外部キーである。
・メンテナンス項目ＩＤ・・・メンテナンス項目エンティティを参照する外部キーである。
・メンテナンス項目代表フラグ・・・ここで定義された物理カラムをメンテナンス項目として表示、利用するかを定義したフラグである。メンテナンス項目は、複数の物理カラムに紐づく場合があることから、ここで代表として指定されているものを使用する。
・カラム名・・・物理ＤＢ３１のカラムの物理名が定義される。
・検索カラム名定義・・・メンテナンス項目をデータベースから取得する際に使用するカラム名。通常は物理ＤＢ３１のカラム物理名であるが、必要があれば関数を含む文字列であってもよい。
・論理カラム名・・・物理ＤＢ３１のカラムの論理名が定義される。
・キーカラムフラグ・・・ここで定義される物理カラムが、レコードを一意に判別できるキーカラム（主キー相当）であるか示すフラグ。
・キーカラム順番・・・物理ＤＢ３１内のレコードを判別できるキーカラムの順番。
・シーケンス名・・・物理ＤＢ３１内にレコードを新規登録するときに、発番を必要とするカラムである場合、そのシーケンス名が定義される。
・シーケンス発番クラス・・・物理ＤＢ３１内にレコードを新規登録するときに特殊な発番を必要とするカラムである場合、その発番を行う実行モジュールが定義される。

下位データ接続種別マスタエンティティについて説明する。下位データ接続種別マスタエンティティは、メンテナンス情報の括りを跨ぐ操作を可能とするための機能を提供するための定義情報であり、上位データと下位データとの関連について定義したエンティティである（上位データ、下位データの関連については後述する。）
・下位データ接続種別ＩＤ・・・この下位データ接続種別マスタエンティティを区別するためのＩＤである。
・下位データ接続種別名・・・この下位データ接続種別マスタエンティティの名称である。
・接続情報生成クラス・・・メンテナンス情報を跨いだ操作を行うときに実行されるクラスを定義する。

メタＤＢ２３には、図３に示すように、これら以外にもメンテナンス権限や値の型を定義したエンティティ、画面表示部１０の表示用入力フォームを定義したエンティティ等、様々な定義情報が記憶されている。

図３により、メンテナンス情報エンティティと対象テーブルエンティティとがリレーション関係にあること、および、メンテナンス項目エンティティと対象テーブルカラムとがリレーション関係にあることがわかる。このことから、本実施形態では、管理上の層（レイア）の構成としては、メンテナンス情報エンティティと物理ＤＢ３１のテーブルとが対応し、メンテナンス項目エンティティと物理ＤＢ３１のカラムとが対応する。

メタＤＢ２３には、論理視点（メンテナンス情報の括り）を跨いだ関係も定義されており、クエリ生成部２２は、この対応関係も考慮してクエリを生成する。本実施形態では、この論理視点を跨いだ関係を、必要に応じて上下関係と称する（上下関係の構築例については、後述の画面説明の際に詳説する。）

この上下関係について、図４、図５を参照しつつ説明する。図４、図５は、メンテナンス項目エンティティ（テーブル）に格納されているデータの具体例を示している。すなわち図４、図５は、図３のメンテナンス項目エンティティ内に列挙されている各データ項目をカラムとし、具体的データをレコードで保持しているテーブルを示している。この図４、図５は、メンテナンス項目ＩＤについての上下関係も例示されている（図中の矢印参照）。

利用者が、例えばメンテナンス情報Ａについての更新処理を行う場合（尚、本実施形態は、利用者がメンテナンス情報Ａを直接的に意識することなく指定することが可能な実装となっている）、メンテナンス情報Ａに関連するメンテナンス項目エンティティや、対象テーブルエンティティ、対象テーブルカラムエンティティ等のレコードが収集され、更新用のクエリが作成される。このとき、クエリ生成部２２は、物理ＤＢ３１の所定のテーブル内で保持されている「ＯＲＧ＿ＩＤ」、「ＯＲＧ＿ＣＯＤＥ」、・・・、「ＶＥＲＳＩＯＮ＿ＮＯ」のカラムを対象に、変更が発生したものについては更新を行うＳＱＬ文を生成する。

ここで、下位メンテナンス項目ＩＤについて説明する。下位メンテナンス項目ＩＤは、テーブル間のリレーション（外部キー）を示すものであり、同一メンテナンスユニットエンティティ内の他の（下位の）メンテナンス情報エンティティに属するＩＤが設定されている。よって、（上位の）下位メンテナンス項目ＩＤにＩＤ値が設定されている場合、（下位の）メンテナンス情報エンティティ内のデータも更新される。下位メンテナンス項目ＩＤの使用方法は、以下となる。

上記以外の図４、図５内において、矩形枠で囲まれ、矢印で示されている関係も、同様の動作となる。尚、この例では「ＯＲＧ_ＩＤ」のカラム名が同じであるため、同一の物理テーブル内の「ＯＲＧ_ＩＤ」カラムのように感じられるが、上述したように、メンテナンス情報と物理ＤＢ３１の物理テーブルとが対応付けられていることから、これら「ＯＲＧ_ＩＤ」は、物理ＤＢ３１内のそれぞれ異なった物理テーブルの物理カラムとなる。

尚、下位データ接続項目ＩＤが自身のメンテナンス情報を指し示しているもの（図の例では、メンテナンス項目ＩＤが「１００４０００２」のもの）は、組織コード（物理データ）の上位桁が「部」を示し、下位桁が「課」を示す等、コード自体で階層構造を有するデータ（自己参照型）となっている場合の対処である。

また図４、図５からも明らかなように、メンテナンス項目エンティティには、メンテナンス項目ＩＤやメンテナンスＩＤという、利用者視点のカラムを有し、且つ、メンテナンス項目名、メンテナンス項目論理名という、物理視点のカラムを有する。これは、論理視点のデータと、物理視点のデータとを少なくとも対応付けてレコードで保持していることを意味する。

次に、画面表示部１０での表示例を図６、図７に示す。図６は、物理ＤＢ３１に保持されている内容を、上段をテーブル型、下段を編集型で表示したものである。上段テーブル型画面の任意の行をユーザが指定すると、画面表示部１０は、下段編集型画面に、内容（プロパティ）や値を表示する。この下段画面は編集可能な領域となっており、利用者は、キーボードやマウスを用いて値を設定する。

また図７（Ａ）は、利用者視点で区分された構造をツリー型で表示した例であり、図７（Ｂ）は、ツリー型およびテーブル型で表示した例である。図７（Ａ）に示す各表示画面も、上段に表示されたツリー項目を利用者が選定することで、下段の編集型画面にこの選定された内容や値が表示される。図７（Ｂ）については、上段左側のうちからツリー項目（本例では「管理グループ」）が選定されると、上段右側のテーブル型画面に、代表項目が表示される。テーブル型画面に表示された項目のうちの一つが選定されると、下段に、編集可能な形式で詳細項目が表示される。

図７（Ｂ）の場合、「管理グループ」が選択されると、処理部２０は、「管理グループ」に関連した物理データを一括で取得し、画面表示部１０へ送信する。画面表示部１０は、一括で取得されたデータのうちから、現時点で必要な内容のみを表示するように制御する。例えば図７（Ｂ）の場合、「管理グループ」が選定された際には、「管理グループ」に関連した物理データが一括で取得されるが、テーブル型画面の表示領域に「ログインＩＤ」、「利用者名」の各値のみを表示し、下段の領域には何も表示しない。テーブル型画面の「ログインＩＤ」や「利用者名」が選択されて初めて下段領域に詳細内容が表示される。このように複数段階で表示される方式においても、一括で物理データが取得されることで、ＤＢに対しての問い合わせ数を削減することができる。この一括取得は、図７（Ａ）の表示形式でも同様である。例えば「テレビ問合せ（業務用）」がユーザにより選択された場合、当該ツリー内に属しているプロパティや値の全てが一括で取得される。

また上記図７（Ａ）の場合、「テレビ問合わせ（業務用）」がメンテナンス情報エンティティ内のメンテナンス名に相当し、「テレビ問合せ（業務用）」とメンテナンス情報エンティティのＩＤ（メンテナンスＩＤ）とが紐付けられている。上記図７（Ｂ）の場合、「管理グループ」がメンテナンス情報エンティティ内のメンテナンス名に相当し、「管理グループ」とメンテナンス情報エンティティのＩＤ（メンテナンスＩＤ）とが紐付けられている。このように、画面に表示されている項目が選択されると、メンテナンス情報エンティティが特定される。

また図７（Ｂ）に示される「相談事業部」もメンテナンス情報に相当させることで、「相談事業部」と「管理グループ」とを上下関係とすることも可能である。このように、本実施形態では、同列のエンティティでもネスト構成、上下関係とさせることができる。

図８〜図１５を参照しつつ、業務システム１００の動作を説明する。まず初めに、物理ＤＢ３１内で保持されているデータの検索処理、および検索結果の表示処理について、図８〜図１１を用いて説明し、登録、更新、削除の処理については、図１２〜図１５を用いて説明する。

図８は、検索、表示処理の概要を示すフローチャートである。尚、検索処理は、利用者が画面表示部１０で表示されている項目のうちの一つ（例えば図７（Ａ）の上段に表示されるツリーの「テレビ問合せ（業務用）」）を選択した後に実行される。尚、画面表示部１０に表示される各表示項目は、メンテナンスユニットエンティティに基づき取得されている。尚、ここでも上述通りデータは一括で取得される。すなわち、「テレビ問合せ（業務用）」が選択指定されると、第２階層、第３階層で定義された物理情報も含め一括でデータが取得され、アプリケーションサーバ２のメモリ内に格納され、その後の利用者の操作に対応して必要な情報が当該メモリから取得され画面表示される。

データ送受信部２１は、画面表示部１０から送信されたメンテナンスＩＤを取得し、クエリ生成部２２は、メンテナンスＩＤに基づき、メンテナンス対象に関する定義情報を取得する（Ｓ１０１）。次にクエリ生成部２２は、物理データ抽出用のクエリを生成する（Ｓ１０２）。データ送受信部２１は、生成されたクエリをＤＢ制御部３０に発行することで、物理ＤＢ３１から物理データを抽出する（Ｓ１０３）。データ送受信部２１は、抽出結果（検索結果）を画面表示部１０に送信し、画面表示部１０は、図６、図７で示すレイアウト上に、抽出結果を表示する（Ｓ１０４）。この処理は、ネストデータ（上下関係において、下位のデータ）が有る限り実行される。

ステップＳ１０２のクエリ生成処理の詳細動作を、図９を参照しつつ説明する。クエリ生成部２２は、対象となるテーブル（物理ＤＢ３１内のテーブル）が複数テーブルであるか単一テーブルであるかを判定する（Ｓ１１１）。この判定は、メンテナンス情報エンティティに紐付けられた対象テーブルエンティティが１つであるか複数であるかを基に判定される。

単一テーブルである場合（Ｓ１１１、単一テーブル）、クエリ生成部２２は、その対象テーブルエンティティで指定された物理テーブルを処理対象と定義する（Ｓ１１２）。一方、複数テーブルである場合（Ｓ１１１、複数テーブル）、クエリ生成部２２は、対象テーブルエンティティ内部の各データ項目を参照し、結合方法（単純結合／等価結合／外部結合）、結合順番、インデント（結合時の階層）を定義し、対象となるテーブル（物理テーブル）を、対象テーブルエンティティの対象テーブル結合順番の順で結合する（Ｓ１１３）。この際、対象テーブルエンティティの結合条件ＳＱＬに値が設定されている場合、結合条件ＳＱＬの設定値も結合条件に加えられる。尚、ステップＳ１１１、Ｓ１１２、Ｓ１１３の処理は、抽出対象となる物理テーブルを決定する処理であり、対象テーブルエンティティのテーブル結合順番、テーブル結合インデント、テーブル結合種別コード、テーブル結合条件ＳＱＬが主に用いられる。

次にクエリ生成部２２は、対象テーブルカラムエンティティで定義されているカラム（物理カラム）を抽出対象として指定する（Ｓ１１４）。クエリ生成部２２は、ここでは、ステップＳ１１２やＳ１１３で指定されている対象テーブルエンティティとリレーション関係を確認したり、また、メンテナンス項目エンティティ内で定義されているメンテナンス項目名に基づくことで、対象テーブルカラムエンティティを特定し、当該対象テーブルカラムエンティティ内のデータ項目を取得する。ステップＳ１１４の処理は、抽出対象となる物理テーブルの物理カラムを決定する処理となり、対象テーブルカラムエンティティのカラム名、検索カラム名定義、論理カラム名等が参照される。

クエリ生成部２２は、メンテナンス情報エンティティで定義された抽出条件（抽出条件ＳＱＬ）を取得し（Ｓ１１５）、メンテナンス項目エンティティで定義されたソート条件（ソート順、ソート種別コード）を取得する（Ｓ１１６）。ステップＳ１１５〜Ｓ１１６の処理は、抽出条件、ソート条件を決定する処理となる。

クエリ生成部２２は、上位データから下位データに向けた接続条件の指定の有無を判定する（Ｓ１１７）。ここでは、メンテナンス項目エンティティ内の下位メンテナンス項目ＩＤに値が設定されているか否かで接続条件の指定の有無を判定する。指定が無い場合（Ｓ１１７、指定なし）、処理はステップＳ１１９へ進み、指定がある場合（Ｓ１１７、指定あり）、クエリ生成部２２は、当該下位メンテナンス項目ＩＤによって、テーブル間リレーション（１：Ｎ）のキーカラムであるメンテナンスＩＤを特定し、これに基づき、データを絞り込む条件を指定する（Ｓ１１８）。下位データは、現在におけるクエリ生成対象となる。上位データからは、下位メンテナンス項目ＩＤとその値内容が渡されているため、下位においては、同じメンテナンス項目ＩＤのカラムに対して、その値を条件に指定される。

クエリ生成部２２は、上記各ステップにより指定される項目を組み合わせることにより、クエリ（セレクト文）を作成する（Ｓ１１９）。

次に、図８のステップＳ１０３（メンテナンスデータ抽出処理）について、図１０を参照しつつ詳説する。尚、この処理は、データ送受信部２１が主体となって動作するものとして説明するが、データ送受信部２１とクエリ生成部２２とが互いに連携して動作する実装でもよい。

データ送受信部２１は、生成されたクエリをＤＢ制御部３０に送信することで、当該クエリに基づいた物理データを取得する（Ｓ１３１）。尚、データ送受信部２１のクエリ送信処理、ＤＢ制御部３０のクエリの解釈処理や検索処理は既知の技術が採用される。

データ送受信部２１は、メンテナンス項目エンティティの下位データ接続項目ＩＤやメンテナンス情報エンティティの下位データ接続種別ＩＤに値が設定されているかを判定する（Ｓ１３２）。値が設定されている場合（Ｓ１３２、指定有り）、下位データ接続種別マスタエンティティを参照して接続情報生成クラス（実行モジュール）を特定し、当該実行モジュールを実行することで、データの階層構造を生成する（Ｓ１３３）。接続情報生成クラスにより、例えば上記自己参照型にも対応させることができる。自己参照型の階層構造を生成する実行モジュールである場合、値の何桁までを上位部署のコードとし、何桁までを下位部署のコードとするかを判別し、上位部署のコードと下位部署のコードとをＣＳＶデータで出力する、などの処理を行う。

このように取得される物理ＤＢ３１内の値、および階層構造は、画面表示部１０に送信される。尚、ステップＳ１３２で下位データ接続種別ＩＤに値が設定されていない場合（Ｓ１３２、指定なし）、データ送受信部２１は、物理データ３０内の値のみを画面表示部１０に送信する。ここで示される送信処理では、データの型や表示レイアウトに関するデータ等、画面表示部１０で表示を行う際に必要となるデータも同時に送信される。

次に、図８のステップＳ１０４の表示処理について、図１１を参照しつつ詳細動作を説明する。

画面表示部１０は、イメージを作成する対象部位がテーブル型やツリー型を表示する領域か、またはデータ編集可能な領域かを判定する（Ｓ１４１）。テーブル型やツリー型を作成する部位である場合（Ｓ１４１、テーブル／ツリー型）、画面表示部１０は、事前に取得している、メンテナンスユニットエンティティで定義されたメンテナンス種別を判定する（Ｓ１４２）。メンテナンス種別がテーブル型である場合（Ｓ１４２、テーブル型）、画面表示部１０は、図６の画面上段に示すようにテーブル一覧の画面レイアウトを作成する（Ｓ１４５）。一方、メンテナンス種別がツリー型である場合（Ｓ１４２、ツリー型）、画面表示部１０は、図７（Ａ）の画面上段や図７（Ｂ）の画面上段左側に示すように、１：Ｎ型や１：Ｎ：Ｎ型（すなわちツリー型）に対応する画面レイアウトを作成する（Ｓ１４３）。次に画面表示部１０は、データ送受信部２１から送信された物理データを、作成した画面レイアウト上に表示する（Ｓ１４４）。

また一方、ステップＳ１４１で、作成部位がデータ編集用の領域である場合（Ｓ１４１、データ編集型）、画面表示部１０は、編集対象項目数に達するまで以下のステップＳ１４６〜Ｓ１４８の処理をループさせる。

画面表示部１０は、データ編集形式を判定する（Ｓ１４６）。ここでは、メンテナンス項目エンティティで定義されている入力フォーム形式ＩＤの値に基づき判定する。ここでデータ編集形式がテキスト型である場合（Ｓ１４６、テキスト形式）、画面表示部１０は、メンテナンス項目エンティティの書式種別ＩＤで指定されたデータ書式（日付、時刻、カンマ区切りの数値、その他の設定）に補正して、現在の設定内容を表示する（Ｓ１４７）。またデータ編集形式が選択肢型である場合（Ｓ１４６、選択肢形式）、メンテナンス項目エンティティの参照選択肢ＩＤの参照先であるメンテナンス参照選択肢エンティティと、メンテナンス項目エンティティの選択肢ＩＤに基づくメンテナンス選択肢マスタエンティティとを用いて、固定値、または任意のマスタデータ内容を動的に参照して選択肢を作成する（Ｓ１４８）。

尚、図１１のステップＳ１４１〜Ｓ１４４は、メンテナンスユニットエンティティのメンテナンス種別ＩＤ、メンテナンス種別マスタエンティティのメンテナンスモジュール生成クラス、メンテナンスモジュールクライアントクラスが主に用いられる。またステップＳ１４３、Ｓ１４５では、メンテナンスユニットエンティティの権限オブジェクトＩＤ、およびメンテナンス権限エンティティの作成可能フラグ、参照可能フラグ、更新可能フラグ、削除可能フラグも用いられ、利用者が操作可能かも判定される。さらに、図１１に示されるループ処理やステップＳ１４６〜Ｓ１４８は、メンテナンス項目エンティティの表示フラグ、編集種別コード、入力フォーム形式ＩＤ、参照選択肢ＩＤ、選択肢ＩＤ、書式種別ＩＤ、カラム書式種別マスタエンティティのカラム書式種別名、カラム書式種別名バリエーションクラス、メンテナンス参照選択肢エンティティの抽出用ＳＱＬ、メンテナンス選択肢マスタエンティティの選択値が用いられる。

次に、業務システム１００の登録、削除、更新処理の概要について図１２に示す。以降、登録、削除、更新の動作を区別する必要のないものについては、「更新」の用語を用いる。

まずは更新処理の概要について、図１２のフローチャートを参照しつつ説明する。尚、更新処理は、画面制御部１０の編集型表示領域に表示されているデータが変更されたときに、随時行われる。更新処理において、まずデータ送受信部２０（画面表示部１０でもよい）は、更新可能かを検証し（Ｓ２０２）、クエリ生成部２２は、メタＤＢ２３に基づき更新用のクエリを生成する（Ｓ２０３）。その後、データ送受信部２０は、クエリ生成部２２で生成されたクエリをＤＢ制御部３０へ送信し、ＤＢ制御部３３が物理データ３１に対して更新処理を行う（Ｓ２０４）。更新処理の結果（ステータス）は、画面表示部１０まで送信され、随時利用者に通知される実装でもよいし、エラー時のみ通知される実装でもよい。

引き続き、ステップＳ２０２、Ｓ２０３の処理の詳細を図１３〜図１５を参照しつつ説明する。尚、ステップＳ２０４の処理は既存技術であるため、これ以上の説明を割愛する。

まずステップＳ２０２の更新検証処理について、図１３を用いて説明する。データ送受信部２０は、変更種別を識別する（Ｓ２１１）。この変更種別は、利用者の、表示データに対しての操作（更新や削除、または登録）に応じて、画面表示部１０によって付与されるデータである。

変更種別が更新、削除である場合（Ｓ２１１、更新、削除）、データ送受信部２１は、物理ＤＢ３１の更新対象データのレコードを取得してロックをかける（Ｓ２１２）。ロックの制御はＤＢ制御部３０の機能を用いてもよいし、データ送受信部２０の機能として提供されてもよい。尚、レコードが他のユーザによって削除されている場合、データ送受信部２０は排他エラーとして扱い、画面表示部１０にその旨の電文を送信する（Ｓ２１３）。尚、変更種別が登録である場合（Ｓ２１１、登録）、ロック制御は不要であるため、そのままＳ２０２は終了する。

次に、ステップＳ２０３の更新用クエリ生成処理について、図１４、図１５のフローチャートを用いて説明する。また図１４、図１５に示される各ステップは、メンテナンス情報のレコード分、ネスト構造も含めて実行される。

クエリ生成部２２は、メンテナンス情報ごとに、データの変更が発生したか否かを判定する（Ｓ２３１）。ここでの判定は、下位のネスト構造も含めてデータ変更の有無が判定される。データ変更が無い場合、当該メンテナンス情報についての処理は終了し、次のメンテナンス情報についての処理が行われる。

データに変更がある場合（Ｓ２３１、あり）クエリ生成部２２は、次に変更種別の値を用いて、当該変更が更新、削除、登録のいずれであるかを判定する（Ｓ２３２）。変更種別が登録である場合（Ｓ２３、登録）、クエリ生成部２２は、メンテナンス情報エンティティのユニット内順番、対象テーブルエンティティのメンテナンス順番で定義された順番の正順となるように準備する（Ｓ２３３）。ここでの準備とは、最終的に生成するクエリの一部分を生成したり、また順番を定義付けた中間データを作成したりすることである。

クエリ生成部２２は、次に登録値がシーケンス番号か、標準値か、これら以外であるかを判定する（Ｓ２３４）。ここでは、登録対象の実データ（登録値）に対応するメンテナンス項目エンティティ内で、標準値やシーケンス名、シーケンス発番クラスに値が設定されているか否かで判定される。登録値とメンテナンス項目エンティティとの対応は、メンテナンス項目エンティティ内のメンテナンス項目名で紐付けることができる。登録値がシーケンス番号、標準値以外の場合（Ｓ２３４、シーケンス・標準値以外）、処理はＳ２４０に進む。

登録値がシーケンス番号である場合（Ｓ２３４、シーケンス）、クエリ生成部２２は、メンテナンス項目エンティティで定義されているシーケンス発番方法に基づいてシーケンス発番を行い、その値をクエリに設定する（Ｓ２３５）。ここでは、メンテナンス項目エンティティのシーケンス名、シーケンス発番クラスが参照され、発番される。また登録値が標準値である場合（Ｓ２３４、標準値）、メンテナンス項目エンティティで定義された標準値をクエリに設定する（Ｓ２３６）。ステップＳ２３５、Ｓ２３６が行われた後は、Ｓ２４３に処理が進む。

ステップＳ２３２の変更種別判定処理に説明を戻す。変更種別が更新、または削除である場合（Ｓ２３２、更新・削除）、クエリ生成部２２は、メンテナンス情報エンティティ、対象テーブルエンティティで設定された順番の逆順となるように設定する（Ｓ２３７）。ステップＳ２３３の登録処理の場合は正順とし、ステップＳ２３７では逆順とする理由について説明する。例えば所定部署と、当該所定部署に所属する社員の情報とを登録、更新、削除する場合、登録は、上位となる所属部署をまず確定させ、下位の社員情報を登録した方が、データの整合が取りやすい。一方、更新、削除の場合、下位となる社員情報をまず更新、削除をしてから上位となる所属部署を更新、削除する方がデータの整合が取りやすい。よって本実施形態では、登録の場合は正順となるように設定し、更新、削除の場合は逆順となるように設定する。

次にクエリ生成部２３は、登録する値、更新する値が、利用者が直接入力／選択した値であるか、または上位データの変更に伴い、変更されるものであるかを判定する（Ｓ２４０）。図４、図５を用いて説明したように、下位メンテナンス項目ＩＤに値が設定されている場合、これに起因して処理が行われる。ステップＳ２４０では、対象となる登録値、更新値が、利用者が直接入力したものであるか上位データの変更に基づいたものであるかが判定される。

引き続き図１５に示す処理について説明する。図１５に示すステップＳ２４３、Ｓ２４４は、メンテナンス項目に対応付けられた対象テーブルカラムの数だけループ処理を行う。

クエリ生成部２３は、テーブル対象エンティティの作成可能フラグ、更新可能フラグ、削除可能フラグに値が設定されているかを確認することで、データが変更可能であるかを判定する（Ｓ２４３）。ここで変更可能である場合（Ｓ２４３、変更可）、対象テーブル、対象テーブルカラム、メンテナンス項目の各エンティティで設定されている、物理テーブルカラムに対する変更を行うクエリを作成する（Ｓ２４４）。

本実施形態のアプリケーションサーバ２は、上述の通り、保持部と、処理部とを有する。保持部は、メタＤＢ２３やメタＤＢ２３を記憶するメモリである。保持部には、利用者の観点で区分けされた処理内容に関する情報である論理情報と、操作対象となるデータベースのテーブル定義情報およびカラム定義情報を少なくとも含む情報である物理情報とが対応付けられ、対応情報として保持されている。

論理情報は、本実施形態ではメンテナンス種別マスタエンティティ、メンテナンスユニットエンティティやメンテナンス情報エンティティ、メンテナンス項目エンティティに相当する。物理情報は、本実施形態では対象テーブルエンティティ、対象テーブルカラムエンティティに相当する。

処理部は、論理情報を特定する情報である第１情報を取得し、保持部で保持された対応情報および第１情報に基づき、データベース内のデータを操作するクエリを作成し、クエリをデータベースに発行する。第１情報とは、本実施形態では、例えば、利用者が画面表示部１０を用いて指定したメンテナンス情報のメンテナンスＩＤである。

本実施形態の利用者観点は、物理ＤＢ３１内部のテーブル定義、カラム定義を利用者に意識させないよう、また利用者の業務や作業上の効率性に重きを置いた観点となる。また、利用者にとって理解しやすい、利用者にとって使い勝手がよい、ユーザビリティを有する、等の観点で纏められることもある。

ＤＢシステムを構築する際、通常、論理設計、物理設計の各設計フェーズがあるが、この論理設計の段階で、ＳＩベンダーは導入先企業にどのような処理内容になるのかを確認し、処理内容を区分けする。これが、本実施形態でいう利用者の観点で区分けされた処理内容となる。

このような利用者観点は、利用者とシステムとの間を取り持つユーザインターフェイス（本実施形態では画面表示部）の表示内容に反映される。表示内容とは、例えばレイアウトや表示用の文字列ラベル、アイコンやボタン等がある。本実施形態のメンテナンス種別マスタ、メンテナンスユニットエンティティ、メンテナンス情報エンティティ、メンテナンス項目エンティティ等には、表示用の文字列ラベルやレイアウト等の定義情報も含んでいる。すなわち、本実施形態のアプリケーションサーバは、画面表示部から、画面の定義情報に関する情報を取得する、という捉え方も可能となり、物理ＤＢを操作する際、表示内容を特定する情報をアプリケーションサーバが取得し、メタＤＢ内の対応情報と、取得した情報とを基にクエリを生成する、という捉え方も可能となる。

また、従前より用いられるインデックス（ポインタ情報と総称される場合もある）は、データベースで管理されているテーブルのレコード（行）を指し示す情報であるが、本実施形態のメタＤＢは、データベースで管理されているテーブルのカラム（列）の情報を保持するものである。

上記例では、システム導入後の運用フェーズ時の物理ＤＢへのアクセスについて言及したが、システムの構築フェーズでも適用できる。すなわち、上記メタＤＢを導入先の企業ごとに構築することで、アプリケーション（上記例での処理部２０の機能に相当）は、一度作成すれば他企業へ導入する際にも相当部分を流用させることができる。特殊なケース等、細部についてはクラスファイル（実行モジュール）を作成し、メタＤＢ内で定義する。

（応用例）
上記実施形態は、ＤＢの移設作業にも応用できる。図１６は、既存のＤＢサーバ３Ａ内の物理ＤＢ３１Ａに格納されているデータを、新設のＤＢサーバ３Ｂ内の物理ＤＢ３１Ｂへ移行するときの構成例を示す図である。ＤＢサーバ３Ａ内のＤＢ制御部３０Ａ、物理ＤＢ３１Ａと、ＤＢサーバ３Ｂ内のＤＢ制御部３０Ｂ、物理ＤＢ３１Ｂとは、同じ仕様（例えばＲＤＢＭＳの提供ベンダーが同一）であってもよく、異なる仕様であっても構わない。

物理ＤＢ３１Ａと物理ＤＢ３１Ｂとの間で、テーブル、カラムの定義が異なっている場合、構築担当者はデータ移行プログラムを作成する必要がある。このようなデータ移行プログラムは、型変換や型チェック、既存の物理ＤＢ３１Ａのカラム内データを新設のＤＢ３１Ｂのいずれのテーブルのいずれのカラムに格納させるか、等の処理を実行する。このデータ移行プログラムは、導入先の企業に応じて、都度作成する必要がある。

ここで、上記のようなメタＤＢ２３Ａを有するサーバ２Ａ（クエリ生成装置）を導入し、サーバ２Ａを介してＤＢサーバ３ＡとＤＢサーバ３Ｂとのデータ移行を行うことで、データ移行プログラムの構築期間を短縮させることができる。メタＤＢ２３Ａ内については、上記利用者視点（論理視点）に関するデータを既存の物理ＤＢ３１Ａのテーブル、カラム定義を有するデータとし（このデータを第１物理情報とする）、上記物理視点に関するデータを移行先の物理ＤＢ３１Ｂのテーブル、カラム定義を有するデータとして（このデータを第２物理情報とする）、これらを対応づけさせる。このようにすることで、データ移行用プログラムに相当する処理部２０Ａの作成時間を短縮させることができる。

尚、処理部２０Ａは、第１物理情報を特定する識別情報を取得し、上記対応情報および識別情報に基づき、物理ＤＢ３１Ｂ内のデータを操作するクエリを作成し、作成したクエリを物理ＤＢ３１Ｂに向けて発行する。

また本実施形態を適用することで、上記のデータ移行以外にも、２つ以上のシステム間のデータ連携を図ることができる。図１６を流用すると、ＤＢサーバ３Ａが例えば会計システムのデータ管理を司るものとし、ＤＢサーバ３Ｂが例えば在庫管理システムのデータ管理を司るものである場合、メタＤＢ２３Ａ内に、物理ＤＢ３１Ａのテーブル、カラム定義と、物理ＤＢ３１Ｂのテーブル、カラム定義とを対応付けて保持させることで、会計システムと在庫管理システムとの間でデータの連携を図ることができ、データ間の不整合の防止を図ることができる。対象範囲を拡大させることで、同一企業内のシステム間連携のみならず、異なる企業間のデータ連携も実現させることができる。

本実施形態のアプリケーションサーバ２、サーバ２Ａには、上記機能を実現するためのクエリ発行プログラムが事前に導入されている。このクエリ発行プログラムは、ハードディスクドライブ、ＵＳＢメモリ、ＣＤ−ＲＯＭ等の記憶媒体に記憶させ、提供されることが可能である。また、ネットワークを介した提供も可能である。

以上、この実施形態で説明した態様により、データアクセス処理の機能を一部汎用化させることができる。

なお、本発明の実施形態を説明したが、当該実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１ クライアント端末、２ アプリケーションサーバ、２Ａ サーバ、３、３Ａ、３Ｂ ＤＢサーバ、４Ａ、４Ｂ ネットワーク、１０ 画面表示部、２０、２０Ａ 処理部、２１ データ送受信部、２２ クエリ生成部、２３、２３Ａ メタＤＢ、３０、３０Ａ、３０Ｂ ＤＢ制御部、３１、３１Ａ、３１Ｂ 物理ＤＢ、１００ 業務システム。

Claims (5)

1. 操作対象となるデータベースのテーブルを定義した情報であり、前記テーブルのテーブル名、各テーブルをそれぞれ結合するための情報を少なくとも含むテーブル定義情報と、前記テーブルの各カラムを定義した情報であり、カラム名を少なくとも含むカラム定義情報とを少なくとも含み、１つのテーブル定義情報に対し１つまたは複数のカラム定義情報となるように対応づけた情報である、複数の物理情報と、
   利用者の観点で区分けされた処理内容に関する情報であり、抽出条件を少なくとも含む、複数の論理情報と
   を、１つの論理情報に対し１つまたは複数の物理情報となるように対応付けて保持する保持部と、
   論理情報を特定する情報である第１情報を取得し、前記第１情報に基づき特定される論理情報と、この論理情報に対応づけられた物理情報とに基づき、前記定義されるテーブル名、結合情報、カラム名、抽出条件のいずれかもしくは全てを組み合わせて前記データベース内のデータを操作するクエリを作成し、該クエリを前記データベースに発行する処理部と、
   を有するクエリ発行装置。
2. 請求項１に記載のクエリ発行装置において、
   前記保持部は、任意の論理情報である第１論理情報と、該第１論理情報とは異なる論理情報である第２論理情報を保持し、さらに、前記第１論理情報には、前記第２論理情報を特定する情報が含まれており、
   前記処理部は、前記第１情報に基づき第１論理情報を特定し、該第１論理情報に基づき第２論理情報を特定し、前記データベース内のデータであり前記第１論理情報に対応付けられたデータを操作するクエリを作成するとともに、前記第２論理情報に対応付けられたデータを操作するクエリを作成する
   クエリ発行装置。
3. 操作対象となるデータベースのテーブルを定義した情報であり、前記テーブルのテーブル名、各テーブルをそれぞれ結合するための情報を少なくとも含むテーブル定義情報と、前記テーブルの各カラムを定義した情報であり、カラム名を少なくとも含むカラム定義情報とを少なくとも含み、１つのテーブル定義情報に対し１つまたは複数のカラム定義情報となるように対応づけた情報である、複数の物理情報と、
   利用者の観点で区分けされた処理内容に関する情報であり、抽出条件を少なくとも含む、複数の論理情報と
   を、１つの論理情報に対し１つまたは複数の物理情報となるように対応付けて保持する保持部からデータを取得するコンピュータに、
   論理情報を特定する第１情報を取得させ、
   前記第１情報に基づき特定される論理情報と、この論理情報に対応づけられた物理情報とに基づき、前記定義されるテーブル名、結合情報、カラム名、抽出条件のいずれかもしくは全てを組み合わせて前記データベース内のデータを操作するクエリを作成させ、
   前記クエリを前記データベースに発行させる
   ためのクエリ発行プログラム。
4. 操作対象となるデータベースのテーブルを定義した情報であり、前記テーブルのテーブル名、各テーブルをそれぞれ結合するための情報を少なくとも含むテーブル定義情報と、前記テーブルの各カラムを定義した情報であり、カラム名を少なくとも含むカラム定義情報とを少なくとも含み、１つのテーブル定義情報に対し１つまたは複数のカラム定義情報となるように対応づけた情報である、複数の物理情報と、
   利用者の観点で区分けされた処理内容に関する情報であり、抽出条件を少なくとも含む、複数の論理情報と
   を、１つの論理情報に対し１つまたは複数の物理情報となるように対応付けて保持する保持部からデータを取得するコンピュータが、
   論理情報を特定する第１情報を取得し、
   前記第１情報に基づき特定される論理情報と、この論理情報に対応づけられた物理情報とに基づき、前記定義されるテーブル名、結合情報、カラム名、抽出条件のいずれかもしくは全てを組み合わせて前記データベース内のデータを操作するクエリを作成し、
   前記クエリを前記データベースに発行する
   クエリ発行方法。
5. 第１のデータベースのテーブルを定義した情報であり、前記テーブルのテーブル名、各テーブルをそれぞれ結合するための情報を少なくとも含むテーブル定義情報、および前記テーブルの各カラムを定義した情報であり、カラム名を少なくとも含むカラム定義情報を少なくとも含み、１つのテーブル定義情報に対し１つまたは複数のカラム定義情報となるように対応づけた情報である、複数の第１物理情報と、
   第２のデータベースのテーブルを定義した情報であり、該テーブルのテーブル名、前記第２のデータベースの各テーブルをそれぞれ結合するための情報を少なくとも含むテーブル定義情報、および前記第２のデータベースのテーブルの各カラムを定義した情報であり、カラム名を少なくとも含むカラム定義情報を少なくとも含み、１つのテーブル定義情報に対し１つまたは複数のカラム定義情報となるように対応づけた情報である、複数の第２物理情報と、を対応付けて保持する保持部と、
   第１物理情報を特定する第１情報を取得し、前記第１情報に基づき特定される第１物理情報と、この第１物理情報に対応づけられた第２物理情報とに基づき、前記定義されるテーブル名、結合情報、カラム名のいずれかもしくは全てを組み合わせて、前記第２のデータベース内のデータを操作するクエリを作成し、該クエリを前記第２のデータベースに発行する処理部と、
   を有するクエリ発行装置。