クエリ実行システム
【課題】性能チューニングに必要なコストを削減することのできるクエリ実行システムを得る。
【解決手段】クエリチューンアップ部１０２は、アプリケーションから受けたクエリを解析し、クエリ内の命令に代替手段がある場合、代替手段に対応したクエリに変更する。ＤＢＭＳアクセス部１０３は、クエリチューンアップ部１０２で変更されたクエリをデータベース管理システムに要求し、その応答を受け取る。代替処理実行部１０５は、マッピング情報記憶部１０６に記憶されている変換ルールに基づいてＤＢＭＳアクセス部１０３からの応答内容に対して書き換えを行い、アプリケーションへの結果とする。
【解決手段】クエリチューンアップ部１０２は、アプリケーションから受けたクエリを解析し、クエリ内の命令に代替手段がある場合、代替手段に対応したクエリに変更する。ＤＢＭＳアクセス部１０３は、クエリチューンアップ部１０２で変更されたクエリをデータベース管理システムに要求し、その応答を受け取る。代替処理実行部１０５は、マッピング情報記憶部１０６に記憶されている変換ルールに基づいてＤＢＭＳアクセス部１０３からの応答内容に対して書き換えを行い、アプリケーションへの結果とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オブジェクトリレーショナルマッピング（Object Relational Mapping）ツールに代表される、データベース管理システムへクエリを発行し、その結果をデータベース管理システムから受けて、アプリケーションへ返すミドルウェアであるクエリ実行システムに関する。
【背景技術】
【０００２】
オブジェクトリレーショナルマッピングと呼ばれる、オブジェクト指向プログラミング言語のオブジェクトをリレーショナルデータベース管理システム（Relational Database Management System）内のレコードにマッピングして格納するツールがある。代表的なツールとして、例えばＨｉｂｅｒｎａｔｅ（例えば、非特許文献１参照）がある。
【０００３】
このようなツールにおいて、例えば特許文献１のマッピング方法ではオブジェクトモデルもしくはリレーショナルモデルの一方が変更された場合でも、ハッシュテーブルを利用することにより、他方の変更を回避している。また、特許文献２のマッピング方法では、複数のクラスを１つのテーブルへマッピングすることで処理の高速化を実現している。さらに、特許文献３では、マッピングツールにおいて、複数のクエリを１つに統合して実行することで、処理の高速化を実現している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０００−１４８５５５号公報
【特許文献２】特開２００７−２４９３４５号公報
【特許文献３】特開２００８−１７１３１６号公報
【非特許文献】
【０００５】
【非特許文献１】Hibernate Reference Documentation 3.5.6-Final、［平成２２年１１月１１日検索］、インターネット＜ＵＲＬ：http://docs.jboss.org/hibernate/stable/core/reference/en/pdf/hibernate_reference.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記のような従来のツールではデータベース管理システムから得られた結果をオブジェクトモデルにマッピングすることのみに焦点を当てている。従って、例えばデータベース管理システムにおけるソート処理が遅い場合、性能改善が困難である。
このような課題に対処する一般的な解決方法として、マッピングツールを使用するアプリケーションにて、クエリの変更によるデータベース管理システムの問題の回避、データベース管理システムにて省略した処理の実行、といったチューニングが挙げられる。しかし、これらの作業には手間がかかるという問題点があった。さらに、チューニングによる効果が必ずあるとは限らず、チューニングに効果がない場合を考えると、コストの高い作業となってしまう。また、これらのチューニングは個々のクエリに対して行うため、クエリの数が多いと、その分コストもかかってしまうという問題点があった。
【０００７】
この発明は上記のような課題を解決するためになされたもので、性能チューニングに必要なコストを削減することのできるクエリ実行システムを得ることを目的とする。
【課題を解決するための手段】
【０００８】
この発明に係るクエリ実行システムは、データベース管理システムにクエリを発行し、その結果をデータベース管理システムから受け取るクエリ実行システムにおいて、アプリケーションから受けたクエリを解析し、クエリ内の命令に代替手段がある場合、代替手段に対応したクエリに変更するクエリチューンアップ部と、クエリチューンアップ部で変更されたクエリをデータベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、応答に対して、代替手段で書き換えてアプリケーションに結果として出力する代替処理実行部とを備えたものである。
【発明の効果】
【０００９】
この発明のクエリ実行システムは、クエリ内の命令に代替手段がある場合、代替手段に対応したクエリに変更してデータベース管理システムに要求するようにしたので、性能チューニングに必要なコストを削減することができる。
【図面の簡単な説明】
【００１０】
【図１】この発明の実施の形態１によるクエリ実行システムを用いたデータベース検索システムを示す構成図である。
【図２】この発明の実施の形態１によるクエリ実行システムのアプリケーション検索要求のパラメータの一例を示す説明図である。
【図３】この発明の実施の形態１によるクエリ実行システムを示す構成図である。
【図４】この発明の実施の形態１によるクエリ実行システムの動作を示すフローチャートである。
【図５】この発明の実施の形態１によるクエリ実行システムの変更後のデータ検索要求を示す説明図である。
【図６】この発明の実施の形態１によるクエリ実行システムの変換ルールの一例を示す説明図である。
【図７】この発明の実施の形態１によるクエリ実行システムのマッピング部の動作を示すフローチャートである。
【図８】この発明の実施の形態１によるクエリ実行システムの代替処理実行部の動作を示すフローチャートである。
【図９】この発明の実施の形態２によるクエリ実行システムを用いたデータベース検索システムを示す構成図である。
【図１０】この発明の実施の形態２によるクエリ実行システムを示す構成図である。
【図１１】この発明の実施の形態２によるクエリ実行システムのデータ検索定義の一例を示す説明図である。
【図１２】この発明の実施の形態２によるクエリ実行システムのクエリチューンアップ部の動作を示すフローチャートである。
【図１３】この発明の実施の形態３によるクエリ実行システムを用いたデータベース検索システムを示す構成図である。
【図１４】この発明の実施の形態３によるクエリ実行システムの解析後データ検索定義の一例を示す説明図である。
【図１５】この発明の実施の形態３によるクエリ実行システムを示す構成図である。
【図１６】この発明の実施の形態３によるクエリ実行システムのクエリ解析ツールの動作を示すフローチャートである。
【発明を実施するための形態】
【００１１】
実施の形態１．
図１は、この発明の実施の形態１によるクエリ実行システムを用いたデータベース検索システムを示す構成図である。
データベース検索システムは、クエリ発行ミドルウェア１、データベース管理システム（ＤＢＭＳ）２、アプリケーション３を備える。また、各機能ブロック間では、アプリケーション検索要求４、データベース検索要求５、検索結果リスト６、検索結果オブジェクトリスト７を送受信する。
【００１２】
クエリ発行ミドルウェア１は、本実施の形態のクエリ実行システムを構成するもので、アプリケーション３から送信されたアプリケーション検索要求４に応じてＤＢＭＳ２へデータベース検索要求５を発行すると共に、ＤＢＭＳ２から受信した検索結果リスト６を検索結果オブジェクトリスト７に格納し、アプリケーション３へ応答する。
【００１３】
ＤＢＭＳ２は、例えばＳＱＬなどのデータベース管理言語を理解する装置であり、データベース管理言語によりデータベース管理要求に基づいてデータベース（図示せず）を管理する。データベース管理要求には、例えばテーブルまたはインデックスを定義するデータ定義要求、データベースを検索するデータ検索要求、データベースを更新するデータ更新要求、などがある。
【００１４】
アプリケーション３は、クエリ発行ミドルウェア１に対し、当該アプリケーション３に必要なアプリケーション検索要求４を送信し、その結果を格納した検索結果オブジェクトリスト７を受信する。
【００１５】
アプリケーション検索要求４について説明する。
図２は、この実施の形態におけるアプリケーション検索要求４のパラメータの一例を示す図である。アプリケーション検索要求４のパラメータは、データ検索要求と要求オプションを備える。
データ検索要求は、例えばＳＱＬなどのデータベース管理言語により記述する。図２では、ＴＢＬ＿ＰＥＲＳＯＮテーブルから、ＴＹＰＥ＿ＣＯＤＥカラムの値が３であるすべてのレコードを対象に、ＰＥＲＳＯＮ＿ＩＤカラム及びＮＡＭＥカラムの値を、ＮＡＭＥカラムの値順で返すことを記述している。
要求オプションは、データ検索要求を実行する際の動作オプションを示すパラメータ群である。図２に示す要求オプションの１つであるＤＢＭＳ外ソートパラメータは、「ＤＢＭＳ２でソートさせる代わりにクエリ発行ミドルウェア１でソートするか否か」を示す、ＴＲＵＥもしくはＦＡＬＳＥの２値のいずれかを取るパラメータである。図２では、この値がＴＲＵＥであるため、クエリ発行ミドルウェア１がソートを実行することになる。
【００１６】
図１に戻り、データベース検索要求５は、前記データ検索要求と同じく、例えばＳＱＬなどのデータベース管理言語で記述されたものである。ただし、アプリケーション検索要求４のデータ検索要求とまったく同じ内容であるとは限らない。
検索結果リスト６は、ＤＢＭＳ２が提供する検索結果である。
検索結果オブジェクトリスト７は、検索結果リスト６を、アプリケーション３が利用可能な形式に変換したものである。例えば、検索結果リスト６に格納された各カラムの値を、クラスや構造体のメンバに設定したものである。
【００１７】
次に、クエリ発行ミドルウェア１について説明する。
図３は、クエリ発行ミドルウェア１の一例を示す構成図である。
クエリ発行ミドルウェア１は、要求受付・応答部１０１、クエリチューンアップ部１０２、ＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６を備える。
【００１８】
要求受付・応答部１０１は、アプリケーション３とのインタフェースであり、アプリケーション３から送信されたアプリケーション検索要求４を受信すると、受信したアプリケーション検索要求４をクエリチューンアップ部１０２に対して出力する。また、代替処理実行部１０５から検索結果オブジェクトリスト７が入力されると、入力された検索結果オブジェクトリスト７をアプリケーション３に送信する。
【００１９】
クエリチューンアップ部１０２は、アプリケーション検索要求４に含まれるデータ検索要求及び要求オプションを解析し、チューンアップ可能であれば、前記データ検索要求及び要求オプションに基づきデータ検索要求を変更し、変更後のデータ検索要求を、データベース検索要求５としてＤＢＭＳアクセス部１０３へと出力する。また、チューンアップ可能であれば、代替処理実行部１０５の実行内容を記述した代替処理情報を作成する。これらの処理の詳細については後述する。
【００２０】
ＤＢＭＳアクセス部１０３は、クエリチューンアップ部１０２から入力されたデータベース検索要求５をＤＢＭＳ２へ送信する。そして、ＤＢＭＳ２からデータベース検索要求５に対する応答である検索結果リスト６を受信し、受信した検索結果リスト６をマッピング部１０４へと出力する。
【００２１】
マッピング部１０４は、検索結果リスト６を、アプリケーション３の扱い易い検索結果オブジェクトリスト７に変換し、代替処理実行部１０５に対して出力する。この際の変換ルールについては、マッピング情報記憶部１０６から取得する。また、前記変換ルールも代替処理実行部１０５へと出力する。マッピング部１０４の処理の詳細については後述する。
【００２２】
代替処理実行部１０５は、クエリチューンアップ部１０２が作成した代替処理情報及びマッピング部１０４から入力された変換ルールに基づき、検索結果オブジェクトリスト７に対して代替処理を行う。代替処理実行部１０５の処理の詳細については後述する。
【００２３】
マッピング情報記憶部１０６は、検索結果リスト６を、検索結果オブジェクトリスト７へ変換するための情報を記憶する。この情報は、アプリケーション開発者が予め作成し、マッピング情報記憶部１０６へ保存しておく。
【００２４】
次に、クエリチューンアップ部１０２の動作について、図１〜図４を用いて説明する。
図４は、この実施の形態におけるクエリチューンアップ部１０２の動作を示すフローチャートである。
［ステップＳＴ２００］：クエリチューンアップ部１０２は、要求受付・応答部１０１からのアプリケーション検索要求４を入力すると、処理を開始する。
［ステップＳＴ２０１］：クエリチューンアップ部１０２は、アプリケーション検索要求４に含まれる要求オプションを参照し、チューンアップ要求の有無を判定する。図４のフローチャートでは「ＤＢＭＳ外ソート」を参照する例を示している。判定結果が「要求有」の場合はステップＳＴ２０２に進む。一方、判定結果が「要求無」の場合はステップＳＴ２０５に進む。
【００２５】
［ステップＳＴ２０２］：クエリチューンアップ部１０２は、アプリケーション検索要求４に含まれるデータ検索要求を参照し、チューンアップの実施可否を判定する。図４の例では「ＤＢＭＳ外ソート」のチューンアップについて判定するため、データ検索要求内に“ＯＲＤＥＲ ＢＹ”命令が含まれている場合にチューンアップ可能と判定する。判定結果が「可能」の場合はステップＳＴ２０３に進む。一方、判定結果が「不可」の場合はステップＳＴ２０５に進む。
【００２６】
［ステップＳＴ２０３］：クエリチューンアップ部１０２は、代替処理実行部１０５が代替処理を行うのに必要な情報を収集し、代替処理情報として作成する。図４の例では「ＤＢＭＳ外ソート」に対応する代替処理情報を作成する。具体的には、“ＯＲＤＥＲ ＢＹ”命令に継続するカラム名を代替処理情報に設定する。すなわち、“ＯＲＤＥＲ ＢＹ”命令の後ろにある“ＮＡＭＥ”を代替処理情報に設定する。
【００２７】
［ステップＳＴ２０４］：クエリチューンアップ部１０２は、代替処理実行部１０５にて実行する処理をＤＢＭＳ２で実行しないように、アプリケーション検索要求４に含まれるデータ検索要求を変更する。図４の例では「ＤＢＭＳ外ソート」を代替処理実行部１０５にて実行するため、“ＯＲＤＥＲ ＢＹ”命令とそれに続くカラム名を、データ検索要求（ＳＱＬ文）から削除する。図２のデータ検索要求を、本工程で変更した場合のデータ検索要求を図５に示す。
【００２８】
［ステップＳＴ２０５］：クエリチューンアップ部１０２は、データ検索要求をＤＢＭＳアクセス部１０３に対して出力する。本工程におけるデータ検索要求は、ステップＳＴ２０３及びステップＳＴ２０４を実行している場合はステップＳＴ２０４で変更されたものである。一方、ステップＳＴ２０３及びステップＳＴ２０４を実行していない場合はクエリ発行ミドルウェア１が受信したアプリケーション検索要求４のデータ検索要求そのものである。
［ステップＳＴ２９９］：クエリチューンアップ部１０２は処理を終了する。
【００２９】
次に、マッピング部１０４の動作について、図１〜図３、図６、図７に基づき説明する。
図６は、この実施の形態におけるマッピング情報記憶部１０６が提供する変換ルールの一例を示したものである。変換ルールは、図６の左から順番に、ＤＢＭＳ２に格納しているテーブル名、ＤＢＭＳ２に格納しているテーブルのカラム名、アプリケーション３に渡す検索結果オブジェクト名、検索結果オブジェクトが持つメンバ名、で構成される。なお、検索結果オブジェクトとは、検索結果オブジェクトリスト７の個々の要素を指す。
【００３０】
図７は、この実施の形態におけるマッピング部１０４の動作を示すフローチャートである。
［ステップＳＴ３００］：マッピング部１０４は、ＤＢＭＳアクセス部１０３から検索結果リスト６が入力されると、処理を開始する。
［ステップＳＴ３０１］：マッピング部１０４は、データ検索要求から抽出したテーブル名及びカラム名を用いて、マッピング情報記憶部１０６に問い合わせを行う。問い合わせの結果としてマッピング情報記憶部１０６から変換ルールを取得する。
［ステップＳＴ３０２］：マッピング部１０４は、（ａ）検索結果オブジェクトリスト７を作成し、（ｂ）ステップＳＴ３０１で取得した変換ルールに記述されたオブジェクトを生成し、検索結果リスト６の個々の要素から取得したカラムの値をステップＳＴ３０１で取得した変換ルールに記述されたメンバに設定し、前記生成したオブジェクトを検索結果オブジェクトリスト７に追加する。（ｂ）の処理は検索結果リスト６に格納された要素の個数分実行する。
［ステップＳＴ３９９］：マッピング部１０４は、代替処理実行部１０５へ検索結果オブジェクトリスト７及び変換ルールを出力すると、処理を終了する。
【００３１】
次に、代替処理実行部１０５の動作について、図１、図３、図６、図８に基づき説明する。
図８は、この実施の形態における代替処理実行部１０５の動作を示すフローチャートである。
［ステップＳＴ４００］：代替処理実行部１０５は、マッピング部１０４から検索結果オブジェクトリスト７及び変換ルールが入力されると、処理を開始する。
［ステップＳＴ４０１］：代替処理実行部１０５は、クエリチューンアップ部１０２が代替処理情報を作成したか否かを判定する。作成している場合はステップＳＴ４０２に進む。一方、作成していない場合はステップＳＴ４９９に進む。
［ステップＳＴ４０２］：代替処理実行部１０５は、マッピング部１０４から入力された変換ルールと、クエリチューンアップ部１０２が作成した代替処理情報を用いて、代替処理に用いるメンバ名を決定する。本実施の形態では、「ＤＢＭＳ外ソート」に用いるカラムの名称が“ＮＡＭＥ”であるため、検索結果オブジェクトのメンバ“ｎａｍｅ”をソートに用いることになる。
［ステップＳＴ４０３］：代替処理実行部１０５は、ステップＳＴ４０１で決定したメンバを用いて、検索結果オブジェクトリスト７に対する代替処理を実行する。本実施の形態では、検索結果オブジェクトのメンバ「ｎａｍｅ」を用いたソートを実行する。
［ステップＳＴ４９９］：代替処理実行部１０５は、要求受付・応答部１０１に検索結果オブジェクトリスト７を出力すると、処理を終了する。
【００３２】
このように、実施の形態１のクエリ発行ミドルウェア１は、アプリケーション検索要求４を解析し、データ検索要求を変更し、ＤＢＭＳ２から取得した検索結果リスト６とマッピング情報記憶部１０６から取得した変換ルールに基づき検索結果オブジェクトリスト７を作成し、アプリケーション検索要求４の解析結果に基づき検索結果オブジェクトリスト７に対して代替処理を実行する。従って、アプリケーション３からはアプリケーション検索要求４の要求オプションのみを変更すれば、直ちにクエリ発行ミドルウェア１による代替処理を実行できることになり、結果としてアプリケーション３の開発工数を削減できる。具体的には、チューニングのためにデータ検索要求の分析及び変更を行う必要がなくなる、オブジェクト毎またはデータ検索要求毎に必要なチューニング処理（例えばソート）をアプリケーション３で実装する必要がなくなる、などの点でアプリケーション３の開発工数を削減できる。さらに、データ検索要求の変更が不要なため、アプリケーション３の保守性も向上する。
【００３３】
また、上記説明では、代替処理情報にカラム名のみを設定したが、他の項目を設定しても構わない。例えば、ソート順序（昇順・降順）を設定したり、複数のカラムを設定したりしても構わない。同様に、取得レコード数及び検索結果リスト内の取得範囲を示す“ＬＩＭＩＴ”及び“ＯＦＦＳＥＴ”についても、データ検索要求にそれらの記述がある場合は、代替処理情報に設定し、代替処理実行部１０５にて代替処理を実行することで、アプリケーション３からの要求を満たす検索を実行できる。
【００３４】
また、上記説明では、「ＤＢＭＳ外ソート」について述べたが、他の要求オプションを用いたチューニングも考えられる。
例えば、「ＤＢＭＳ外重複レコード削除」という要求オプションが有効になっている場合は、クエリチューンアップ部１０２にて、データ検索要求に重複を取り除く「ＤＩＳＴＩＮＣＴ」が記述されているかを検査し、記述されている場合は代替処理情報を作成し、さらに、代替処理実行部１０５にて代替処理情報を参照し、「ＤＢＭＳ外重複レコード削除」が設定されている場合は、指定カラムの値を検査し、検索結果オブジェクトリスト７に既に同じ値を持つレコードが存在すると当該検索結果オブジェクトを検索結果オブジェクトリスト７に追加しないとすることで、クエリ発行ミドルウェア１による「ＤＩＳＴＩＮＣＴ」の代替処理を実現できる。
【００３５】
また、上記説明ではデータ検索要求に“ＴＹＰＥ＿ＣＯＤＥ＝３”などのように検索条件に用いる値を直接記述していたが、“ＴＹＰＥ＿ＣＯＤＥ＝？”のように記述し実行時に設定するようにしてもよい。このとき、アプリケーション検索要求４には設定する値を記述し、ＤＢＭＳアクセス部１０３にてＤＢＭＳ２への設定値の指定を行えばよい。なお、上述の“ＬＩＭＩＴ”及び“ＯＦＦＳＥＴ”などのように、クエリチューンアップ部１０２によりデータ検索要求から削除される部分に対応する設定値については、代替処理情報に設定し、代替処理実行部１０５にて使用する。
【００３６】
以上のように、実施の形態１のクエリ実行システムによれば、データベース管理システムにクエリを発行し、その結果をデータベース管理システムから受け取るクエリ実行システムにおいて、アプリケーションから受けたクエリを解析し、クエリ内の命令に代替手段がある場合、代替手段に対応したクエリに変更するクエリチューンアップ部と、クエリチューンアップ部で変更されたクエリをデータベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、応答に対して、代替手段で書き換えてアプリケーションに結果として出力する代替処理実行部とを備えたので、性能チューニングに必要なコストを削減することができる。
【００３７】
また、実施の形態１のクエリ実行システムによれば、クエリチューンアップ部は、アプリケーションからの代替処理の要求に基づいてクエリの変更を行うようにしたので、クエリ実行システムにおいて代替処理を行うか否かをアプリケーションから容易に指定することができる。
【００３８】
実施の形態２．
実施の形態１では、アプリケーション３が送信するアプリケーション検索要求４にデータ検索要求（例えばＳＱＬ）が含まれていた。これは、アプリケーション３の内部にデータ検索要求が埋め込まれていることを意味している。
これに対し、実施の形態２では、アプリケーション３がユーザに提供する機能と、その詳細な実現手段としてのデータ検索要求を分離させ、アプリケーション３の保守性を向上させようとするものである。
【００３９】
すなわち、実施の形態２では、実施の形態１におけるアプリケーション検索要求４に相当する情報をクエリ発行ミドルウェアに予め登録し、アプリケーション３はアプリケーション検索要求４に相当する情報を特定するためのＩＤ（要求識別情報）をクエリ発行ミドルウェアに送信することにより、アプリケーション３における機能を分離し、アプリケーション３の保守性を向上させるものである。
【００４０】
実施の形態２に係るクエリ発行ミドルウェアを備えるデータベース検索システムの全体構成を図９に示す。
データベース検索システムは、クエリ発行ミドルウェア１ａ、ＤＢＭＳ２、アプリケーション３を備える。また、各機能ブロック間では、データベース検索要求５、検索結果リスト６、検索結果オブジェクトリスト７、検索要求ＩＤ８を送受信する。
【００４１】
クエリ発行ミドルウェア１ａは、実施の形態２のクエリ実行システムを構成するもので、アプリケーション３から送信された検索要求ＩＤ８に応じてＤＢＭＳ２へデータベース検索要求５を発行すると共に、ＤＢＭＳ２から受信した検索結果リスト６を検索結果オブジェクトリスト７に格納し、アプリケーション３へ応答する。検索要求ＩＤ８は、クエリ発行ミドルウェア１ａに予め登録されているアプリケーション検索定義を一意に特定するための識別情報である。例えば、整数値などを用いる。
なお、ＤＢＭＳ２、アプリケーション３、データベース検索要求５、検索結果リスト６、検索結果オブジェクトリスト７については実施の形態１と同様であるためその説明を省略する。
【００４２】
図１０は、実施の形態２に係るクエリ発行ミドルウェア１ａの一例を示す構成図である。
クエリ発行ミドルウェア１ａは、要求受付・応答部１０１、クエリチューンアップ部１０２ａ、ＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６、データ検索定義記憶部１０７を備える。ここで、ＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６については、実施の形態１と同様であるためその説明を省略する。
【００４３】
要求受付・応答部１０１は、アプリケーション３から検索要求ＩＤ８を受信すると、受信した検索要求ＩＤ８をクエリチューンアップ部１０２ａへと出力する。また、代替処理実行部１０５から検索結果オブジェクトリスト７が入力されると、入力された検索結果オブジェクトリスト７をアプリケーション３に送信する。
【００４４】
クエリチューンアップ部１０２ａは、要求受付・応答部１０１から入力された検索要求ＩＤ８を用いて、データ検索定義記憶部１０７から検索に用いるアプリケーション検索要求４を取得する。アプリケーション検索要求４を取得した後の処理は、実施の形態１と同様である。これらの処理の詳細については後述する。
【００４５】
データ検索定義記憶部１０７は、データ検索定義９を記憶する。データ検索定義９の構成の一例を図１１に示す。データ検索定義９は、アプリケーション検索要求４と、検索要求ＩＤ８で構成される。データ検索定義９は、アプリケーション開発者が予め作成し、データ検索定義記憶部１０７へ保存しておく。
【００４６】
次に、図９〜図１２を用いて、実施の形態２におけるクエリ発行ミドルウェア１ａの動作を詳細に説明する。
図１２は、この実施の形態におけるクエリチューンアップ部１０２ａの動作を示すフローチャートである。
［ステップＳＴ２００ａ］：クエリチューンアップ部１０２ａは、要求受付・応答部１０１から検索要求ＩＤ８が入力されると、処理を開始する。
［ステップＳＴ２０６］：クエリチューンアップ部１０２ａは、検索要求ＩＤ８を用いてデータ検索定義記憶部１０７に問い合わせを行う。問い合わせの結果としてデータ検索定義記憶部１０７からデータ検索定義９を取得する。ここで、検索要求ＩＤ８の値が１００とすると、図１１に示すデータ検索定義９が得られる。
【００４７】
ステップＳＴ２０１以降の工程では、クエリチューンアップ部１０２ａは、データ検索定義記憶部１０７から取得したデータ検索定義９に含まれるアプリケーション検索要求４を用いるため、ステップＳＴ２０１〜ステップＳＴ２９９の動作は実施の形態１と同様である。このため、ステップＳＴ２０１以降の工程についての説明は省略する。
【００４８】
また、クエリチューンアップ部１０２ａからＤＢＭＳアクセス部１０３にクエリ発行要求を行った後のＤＢＭＳアクセス部１０３の動作や、ＤＢＭＳアクセス部１０３から検索結果リスト６を受け取った場合のマッピング部１０４や代替処理実行部１０５の動作は実施の形態１と同様であるため、ここでの説明は省略する。
【００４９】
実施の形態２に係るクエリ発行ミドルウェア１ａには次のような効果がある。すなわち、アプリケーション３から検索要求ＩＤ８を受信し、受信した検索要求ＩＤ８に基づきデータ検索定義記憶部１０７からアプリケーション検索要求４を取得する。アプリケーション検索要求４及び要求オプションをクエリ発行ミドルウェア１ａに登録させることにより、複数のアプリケーション検索要求及び要求オプションをクエリ発行ミドルウェア１ａにて一括して管理することになる。従って、アプリケーション検索要求４もしくは要求オプションを変更する際に、対象となるアプリケーション検索要求４もしくは要求オプションを探索することが、アプリケーション３から該当する箇所を探索するよりも容易に可能となる。
【００５０】
また、実施の形態２では、アプリケーション３の開発においてクエリ発行ミドルウェア１ａから得られる検索結果オブジェクトリストの仕様のみを把握していればよい。すなわち、アプリケーション検索要求４の詳細（例えばＳＱＬの内容）に対する知識がなくてもアプリケーション３の開発が可能となるといった利点もある。
【００５１】
以上のように、実施の形態２のクエリ実行システムによれば、データベース管理システムにクエリを発行し、その結果をデータベース管理システムから受け取るクエリ実行システムにおいて、予め定められた要求識別情報に対応したクエリを格納するデータ検索定義記憶部と、アプリケーションから要求識別情報を受けた場合、要求識別情報に対応したクエリをデータ検索定義記憶部から取得し、取得したクエリ内の命令に代替手段がある場合、代替手段に対応したクエリに変更するクエリチューンアップ部と、クエリチューンアップ部で変更されたクエリをデータベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、応答に対して、代替手段で書き換えてアプリケーションに結果として出力する代替処理実行部とを備えたので、実施の形態１の効果に加えて、アプリケーションの保守性を向上させることができるという効果がある。
【００５２】
実施の形態３．
実施の形態１や実施の形態２では、クエリチューンアップ部１０２（１０２ａ）にて、アプリケーション３から送信されたアプリケーション検索要求４もしくは検索要求ＩＤ８を受信する度に、アプリケーション検索要求４を解析してデータ検索要求の変更、及び代替処理情報の生成を行っていた。ここで、同じ検索を頻繁に実行する場合は、クエリチューンアップ部１０２（１０２ａ）の処理も同じであるため、このような場合は、クエリチューンアップ部１０２（１０２ａ）の処理を削減したいという要望がある。
そこで、実施の形態３では、クエリチューンアップ部１０２（１０２ａ）で実行していた処理をクエリ発行ミドルウェアの外部で事前に実行し、その結果をクエリ発行ミドルウェアで管理することで、クエリ発行ミドルウェアによるデータ検索要求の解析処理などが不要となり、検索処理に要する時間の短縮化を実現する。
【００５３】
実施の形態３に係るクエリ発行ミドルウェアを備えるデータベース検索システムの全体構成を図１３に示す。実施の形態２と実施の形態３の違いは、クエリ発行ミドルウェア１ｂが解析後データ検索定義１１を使用すること、及び解析後データ検索定義１１を作成するクエリ解析ツール１０が存在することである。
図１３に示すように、データベース検索システムは、クエリ発行ミドルウェア１ｂ、ＤＢＭＳ２、アプリケーション３を備え、外部にクエリ解析ツール１０を備える。クエリ解析ツール１０は、データ検索定義９を入力し、チューンアップを行って解析後データ検索定義１１を出力するツールである。すなわち、解析後データ検索定義１１は次のような定義である。
解析後データ検索定義１１の構成の一例を図１４に示す。解析後データ検索定義１１は、データ検索定義９から要求オプションを削除し、代替処理情報を追加したものである。また、解析後データ検索定義１１のデータ検索要求は、クエリ解析ツール１０により、データ検索要求及び要求オプションに応じて、データ検索定義９のデータ検索要求を加工したものである。
【００５４】
クエリ発行ミドルウェア１ｂは、実施の形態３のクエリ実行システムを構成するもので、アプリケーション３から検索要求ＩＤ８を受けた場合、その検索要求ＩＤ８に対応した解析後データ検索定義１１を得て、この解析後データ検索定義１１をＤＢＭＳ２に送信するよう構成されている。
図１５は、実施の形態３のクエリ発行ミドルウェア１ｂの一例を示す構成図である。
クエリ発行ミドルウェア１ｂは、要求受付・応答部１０１、ＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６、解析後データ検索定義取得部１０８、解析後データ検索定義記憶部１０９を備える。
要求受付・応答部１０１は、検索要求ＩＤ８を受信した場合の送信先が解析後データ検索定義取得部１０８であること以外は実施の形態２の要求受付・応答部１０１と同様である。また、ＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６については、実施の形態２と同様の構成であるため、ここでの説明は省略する。
【００５５】
解析後データ検索定義取得部１０８は、要求受付・応答部１０１から入力された検索要求ＩＤ８を用いて、解析後データ検索定義記憶部１０９から解析後データ検索定義１１を取得する。その後、取得した解析後データ検索定義１１に含まれるデータ検索要求をＤＢＭＳアクセス部１０３に対して出力する。解析後データ検索定義記憶部１０９は、解析後データ検索定義１１を記憶する記憶部である。解析後データ検索定義１１は、アプリケーション開発者がクエリ解析ツール１０を用いて予め作成し、解析後データ検索定義記憶部１０９へ保存しておく。
【００５６】
図１３に戻り、データベース検索要求５、検索結果リスト６、検索結果オブジェクトリスト７、検索要求ＩＤ８については実施の形態２と同様であるため、これらの説明は省略する。
【００５７】
次に、実施の形態３のクエリ実行システムの動作について説明する。
先ず、クエリ解析ツール１０の動作について、図１１、図１３、図１４、図１６を用いて説明する。
図１６は、実施の形態３におけるクエリ解析ツール１０の動作を示すフローチャートである。
［ステップＳＴ５００］：クエリ解析ツール１０は、データ検索定義９が入力されると、処理を開始する。
［ステップＳＴ５０１］：クエリ解析ツール１０は、データ検索定義９に基づき解析後データ検索定義１１を作成する。検索要求ＩＤ及びデータ検索要求については、データ検索定義９に格納されている値をそのまま解析後データ検索定義１１に設定する。代替処理情報については、何も設定しない。
［ステップＳＴ５０２］：クエリ解析ツール１０は、データ検索定義９に含まれる要求オプションを参照し、チューンアップ要求の有無を判定する。図１１に示した例では「ＤＢＭＳ外ソート」を参照する。判定結果が「要求有」の場合はステップＳＴ５０３に進む。一方、判定結果が「要求無」の場合はステップＳＴ５９９に進む。
【００５８】
［ステップＳＴ５０３］：クエリ解析ツール１０は、データ検索定義９に含まれるデータ検索要求を参照し、チューンアップの実施可否を判定する。図１１の例では「ＤＢＭＳ外ソート」のチューンアップについて判定するため、データ検索要求内に“ＯＲＤＥＲ ＢＹ”命令が含まれている場合にチューンアップ可能と判定する。判定結果が「可能」の場合はステップＳＴ５０４に進む。一方、判定結果が「不可」の場合はステップＳＴ５９９に進む。
［ステップＳＴ５０４］：クエリ解析ツール１０は、クエリ発行ミドルウェア１ｂが代替処理を行うのに必要な情報を収集し、解析後データ検索定義１１の代替処理情報に設定する。図１１の例では「ＤＢＭＳ外ソート」に対応する代替処理情報を設定する。具体的には、“ＯＲＤＥＲ ＢＹ”命令に継続するカラム名を解析後データ検索定義１１の代替処理情報に設定する。
［ステップＳＴ５０５］：クエリ解析ツール１０は、クエリ発行ミドルウェア１ｂにて実行する処理をＤＢＭＳ２で実行しないように、データ検索定義９のデータ検索要求を変更し、解析後データ検索定義１１のデータ検索要求に設定する。図１１の例では「ＤＢＭＳ外ソート」をクエリ発行ミドルウェア１ｂにて実行するため、“ＯＲＤＥＲ ＢＹ”命令とそれに続くカラム名を、データ検索要求から削除し、解析後データ検索定義１１のデータ検索要求に設定する。
［ステップＳＴ５９９］：クエリ解析ツール１０は処理を終了する。
【００５９】
このように、クエリ解析ツール１０の動作は、基本的に実施の形態１のクエリチューンアップ部１０２の動作（図４）と同様であるが、入力として用いる情報が、実施の形態１ではアプリケーション検索要求４であるのに対し、クエリ解析ツール１０ではデータ検索定義９である点が異なっている。
【００６０】
次に、図１３〜図１５に基づき、実施の形態３におけるクエリ発行ミドルウェア１ｂの動作について説明する。
要求受付・応答部１０１は、アプリケーション３から検索要求ＩＤ８を受け取ると、これを解析後データ検索定義取得部１０８に出力する。解析後データ検索定義取得部１０８は、要求受付・応答部１０１から入力された検索要求ＩＤ８を用いて、解析後データ検索定義記憶部１０９からその検索要求ＩＤ８に対応した解析後データ検索定義１１を取得する。その後、取得した解析後データ検索定義１１に含まれるデータ検索要求をＤＢＭＳアクセス部１０３に出力する。これ以降のＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６に関する動作については、実施の形態１，２と同様であるためこれらの説明を省略する。
【００６１】
このように、実施の形態３におけるクエリ発行ミドルウェア１ｂは、アプリケーション３から検索要求ＩＤ８を受信し、受信した検索要求ＩＤ８に基づき解析後データ検索定義記憶部１０９から解析後データ検索定義１１を取得し、ＤＢＭＳアクセス部１０３への入力などを行う。従って、クエリ発行ミドルウェア１ｂの内部でデータ検索要求の解析及び変更を行わないため、その分クエリ発行ミドルウェア１ｂの処理に要する時間が減少し、データベース検索システムの性能向上を実現する。
【００６２】
以上のように、実施の形態３のクエリ実行システムによれば、データベース管理システムにクエリを発行し、その結果をデータベース管理システムから受け取るクエリ実行システムにおいて、クエリ内の命令に代替手段がある場合に代替手段に対応したクエリを要求識別情報に関連付けて定義する解析後データ検索定義記憶部と、アプリケーションから要求識別情報を受けた場合、要求識別情報に対応したクエリを解析後データ検索定義記憶部より取得する解析後データ検索定義取得部と、解析後データ検索定義取得部で取得したクエリをデータベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、応答に対して、代替手段で書き換えてアプリケーションに結果として出力する代替処理実行部とを備えたので、実施の形態２の効果に加えて、例えば、同じ検索を頻繁に実行するといった場合の処理量を削減することができるといったように、データベース検索システムの性能向上に寄与することができる効果がある。
【００６３】
なお、本願発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。
【符号の説明】
【００６４】
１，１ａ，１ｂ クエリ発行ミドルウェア、２ データベース管理システム（ＤＢＭＳ）、３ アプリケーション、４ アプリケーション検索要求、５ データベース検索要求、６ 検索結果リスト、７ 検索結果オブジェクトリスト、８ 検索要求ＩＤ、９ データ検索定義、１０ クエリ解析ツール、１１ 解析後データ検索定義、１０１ 要求受付・応答部、１０２，１０２ａ クエリチューンアップ部、１０３ ＤＢＭＳアクセス部、１０４ マッピング部、１０５ 代替処理実行部、１０６ マッピング情報記憶部、１０７ データ検索定義記憶部、１０８ 解析後データ検索定義取得部、１０９ 解析後データ検索定義記憶部。
【技術分野】
【０００１】
本発明は、オブジェクトリレーショナルマッピング（Object Relational Mapping）ツールに代表される、データベース管理システムへクエリを発行し、その結果をデータベース管理システムから受けて、アプリケーションへ返すミドルウェアであるクエリ実行システムに関する。
【背景技術】
【０００２】
オブジェクトリレーショナルマッピングと呼ばれる、オブジェクト指向プログラミング言語のオブジェクトをリレーショナルデータベース管理システム（Relational Database Management System）内のレコードにマッピングして格納するツールがある。代表的なツールとして、例えばＨｉｂｅｒｎａｔｅ（例えば、非特許文献１参照）がある。
【０００３】
このようなツールにおいて、例えば特許文献１のマッピング方法ではオブジェクトモデルもしくはリレーショナルモデルの一方が変更された場合でも、ハッシュテーブルを利用することにより、他方の変更を回避している。また、特許文献２のマッピング方法では、複数のクラスを１つのテーブルへマッピングすることで処理の高速化を実現している。さらに、特許文献３では、マッピングツールにおいて、複数のクエリを１つに統合して実行することで、処理の高速化を実現している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０００−１４８５５５号公報
【特許文献２】特開２００７−２４９３４５号公報
【特許文献３】特開２００８−１７１３１６号公報
【非特許文献】
【０００５】
【非特許文献１】Hibernate Reference Documentation 3.5.6-Final、［平成２２年１１月１１日検索］、インターネット＜ＵＲＬ：http://docs.jboss.org/hibernate/stable/core/reference/en/pdf/hibernate_reference.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記のような従来のツールではデータベース管理システムから得られた結果をオブジェクトモデルにマッピングすることのみに焦点を当てている。従って、例えばデータベース管理システムにおけるソート処理が遅い場合、性能改善が困難である。
このような課題に対処する一般的な解決方法として、マッピングツールを使用するアプリケーションにて、クエリの変更によるデータベース管理システムの問題の回避、データベース管理システムにて省略した処理の実行、といったチューニングが挙げられる。しかし、これらの作業には手間がかかるという問題点があった。さらに、チューニングによる効果が必ずあるとは限らず、チューニングに効果がない場合を考えると、コストの高い作業となってしまう。また、これらのチューニングは個々のクエリに対して行うため、クエリの数が多いと、その分コストもかかってしまうという問題点があった。
【０００７】
この発明は上記のような課題を解決するためになされたもので、性能チューニングに必要なコストを削減することのできるクエリ実行システムを得ることを目的とする。
【課題を解決するための手段】
【０００８】
この発明に係るクエリ実行システムは、データベース管理システムにクエリを発行し、その結果をデータベース管理システムから受け取るクエリ実行システムにおいて、アプリケーションから受けたクエリを解析し、クエリ内の命令に代替手段がある場合、代替手段に対応したクエリに変更するクエリチューンアップ部と、クエリチューンアップ部で変更されたクエリをデータベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、応答に対して、代替手段で書き換えてアプリケーションに結果として出力する代替処理実行部とを備えたものである。
【発明の効果】
【０００９】
この発明のクエリ実行システムは、クエリ内の命令に代替手段がある場合、代替手段に対応したクエリに変更してデータベース管理システムに要求するようにしたので、性能チューニングに必要なコストを削減することができる。
【図面の簡単な説明】
【００１０】
【図１】この発明の実施の形態１によるクエリ実行システムを用いたデータベース検索システムを示す構成図である。
【図２】この発明の実施の形態１によるクエリ実行システムのアプリケーション検索要求のパラメータの一例を示す説明図である。
【図３】この発明の実施の形態１によるクエリ実行システムを示す構成図である。
【図４】この発明の実施の形態１によるクエリ実行システムの動作を示すフローチャートである。
【図５】この発明の実施の形態１によるクエリ実行システムの変更後のデータ検索要求を示す説明図である。
【図６】この発明の実施の形態１によるクエリ実行システムの変換ルールの一例を示す説明図である。
【図７】この発明の実施の形態１によるクエリ実行システムのマッピング部の動作を示すフローチャートである。
【図８】この発明の実施の形態１によるクエリ実行システムの代替処理実行部の動作を示すフローチャートである。
【図９】この発明の実施の形態２によるクエリ実行システムを用いたデータベース検索システムを示す構成図である。
【図１０】この発明の実施の形態２によるクエリ実行システムを示す構成図である。
【図１１】この発明の実施の形態２によるクエリ実行システムのデータ検索定義の一例を示す説明図である。
【図１２】この発明の実施の形態２によるクエリ実行システムのクエリチューンアップ部の動作を示すフローチャートである。
【図１３】この発明の実施の形態３によるクエリ実行システムを用いたデータベース検索システムを示す構成図である。
【図１４】この発明の実施の形態３によるクエリ実行システムの解析後データ検索定義の一例を示す説明図である。
【図１５】この発明の実施の形態３によるクエリ実行システムを示す構成図である。
【図１６】この発明の実施の形態３によるクエリ実行システムのクエリ解析ツールの動作を示すフローチャートである。
【発明を実施するための形態】
【００１１】
実施の形態１．
図１は、この発明の実施の形態１によるクエリ実行システムを用いたデータベース検索システムを示す構成図である。
データベース検索システムは、クエリ発行ミドルウェア１、データベース管理システム（ＤＢＭＳ）２、アプリケーション３を備える。また、各機能ブロック間では、アプリケーション検索要求４、データベース検索要求５、検索結果リスト６、検索結果オブジェクトリスト７を送受信する。
【００１２】
クエリ発行ミドルウェア１は、本実施の形態のクエリ実行システムを構成するもので、アプリケーション３から送信されたアプリケーション検索要求４に応じてＤＢＭＳ２へデータベース検索要求５を発行すると共に、ＤＢＭＳ２から受信した検索結果リスト６を検索結果オブジェクトリスト７に格納し、アプリケーション３へ応答する。
【００１３】
ＤＢＭＳ２は、例えばＳＱＬなどのデータベース管理言語を理解する装置であり、データベース管理言語によりデータベース管理要求に基づいてデータベース（図示せず）を管理する。データベース管理要求には、例えばテーブルまたはインデックスを定義するデータ定義要求、データベースを検索するデータ検索要求、データベースを更新するデータ更新要求、などがある。
【００１４】
アプリケーション３は、クエリ発行ミドルウェア１に対し、当該アプリケーション３に必要なアプリケーション検索要求４を送信し、その結果を格納した検索結果オブジェクトリスト７を受信する。
【００１５】
アプリケーション検索要求４について説明する。
図２は、この実施の形態におけるアプリケーション検索要求４のパラメータの一例を示す図である。アプリケーション検索要求４のパラメータは、データ検索要求と要求オプションを備える。
データ検索要求は、例えばＳＱＬなどのデータベース管理言語により記述する。図２では、ＴＢＬ＿ＰＥＲＳＯＮテーブルから、ＴＹＰＥ＿ＣＯＤＥカラムの値が３であるすべてのレコードを対象に、ＰＥＲＳＯＮ＿ＩＤカラム及びＮＡＭＥカラムの値を、ＮＡＭＥカラムの値順で返すことを記述している。
要求オプションは、データ検索要求を実行する際の動作オプションを示すパラメータ群である。図２に示す要求オプションの１つであるＤＢＭＳ外ソートパラメータは、「ＤＢＭＳ２でソートさせる代わりにクエリ発行ミドルウェア１でソートするか否か」を示す、ＴＲＵＥもしくはＦＡＬＳＥの２値のいずれかを取るパラメータである。図２では、この値がＴＲＵＥであるため、クエリ発行ミドルウェア１がソートを実行することになる。
【００１６】
図１に戻り、データベース検索要求５は、前記データ検索要求と同じく、例えばＳＱＬなどのデータベース管理言語で記述されたものである。ただし、アプリケーション検索要求４のデータ検索要求とまったく同じ内容であるとは限らない。
検索結果リスト６は、ＤＢＭＳ２が提供する検索結果である。
検索結果オブジェクトリスト７は、検索結果リスト６を、アプリケーション３が利用可能な形式に変換したものである。例えば、検索結果リスト６に格納された各カラムの値を、クラスや構造体のメンバに設定したものである。
【００１７】
次に、クエリ発行ミドルウェア１について説明する。
図３は、クエリ発行ミドルウェア１の一例を示す構成図である。
クエリ発行ミドルウェア１は、要求受付・応答部１０１、クエリチューンアップ部１０２、ＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６を備える。
【００１８】
要求受付・応答部１０１は、アプリケーション３とのインタフェースであり、アプリケーション３から送信されたアプリケーション検索要求４を受信すると、受信したアプリケーション検索要求４をクエリチューンアップ部１０２に対して出力する。また、代替処理実行部１０５から検索結果オブジェクトリスト７が入力されると、入力された検索結果オブジェクトリスト７をアプリケーション３に送信する。
【００１９】
クエリチューンアップ部１０２は、アプリケーション検索要求４に含まれるデータ検索要求及び要求オプションを解析し、チューンアップ可能であれば、前記データ検索要求及び要求オプションに基づきデータ検索要求を変更し、変更後のデータ検索要求を、データベース検索要求５としてＤＢＭＳアクセス部１０３へと出力する。また、チューンアップ可能であれば、代替処理実行部１０５の実行内容を記述した代替処理情報を作成する。これらの処理の詳細については後述する。
【００２０】
ＤＢＭＳアクセス部１０３は、クエリチューンアップ部１０２から入力されたデータベース検索要求５をＤＢＭＳ２へ送信する。そして、ＤＢＭＳ２からデータベース検索要求５に対する応答である検索結果リスト６を受信し、受信した検索結果リスト６をマッピング部１０４へと出力する。
【００２１】
マッピング部１０４は、検索結果リスト６を、アプリケーション３の扱い易い検索結果オブジェクトリスト７に変換し、代替処理実行部１０５に対して出力する。この際の変換ルールについては、マッピング情報記憶部１０６から取得する。また、前記変換ルールも代替処理実行部１０５へと出力する。マッピング部１０４の処理の詳細については後述する。
【００２２】
代替処理実行部１０５は、クエリチューンアップ部１０２が作成した代替処理情報及びマッピング部１０４から入力された変換ルールに基づき、検索結果オブジェクトリスト７に対して代替処理を行う。代替処理実行部１０５の処理の詳細については後述する。
【００２３】
マッピング情報記憶部１０６は、検索結果リスト６を、検索結果オブジェクトリスト７へ変換するための情報を記憶する。この情報は、アプリケーション開発者が予め作成し、マッピング情報記憶部１０６へ保存しておく。
【００２４】
次に、クエリチューンアップ部１０２の動作について、図１〜図４を用いて説明する。
図４は、この実施の形態におけるクエリチューンアップ部１０２の動作を示すフローチャートである。
［ステップＳＴ２００］：クエリチューンアップ部１０２は、要求受付・応答部１０１からのアプリケーション検索要求４を入力すると、処理を開始する。
［ステップＳＴ２０１］：クエリチューンアップ部１０２は、アプリケーション検索要求４に含まれる要求オプションを参照し、チューンアップ要求の有無を判定する。図４のフローチャートでは「ＤＢＭＳ外ソート」を参照する例を示している。判定結果が「要求有」の場合はステップＳＴ２０２に進む。一方、判定結果が「要求無」の場合はステップＳＴ２０５に進む。
【００２５】
［ステップＳＴ２０２］：クエリチューンアップ部１０２は、アプリケーション検索要求４に含まれるデータ検索要求を参照し、チューンアップの実施可否を判定する。図４の例では「ＤＢＭＳ外ソート」のチューンアップについて判定するため、データ検索要求内に“ＯＲＤＥＲ ＢＹ”命令が含まれている場合にチューンアップ可能と判定する。判定結果が「可能」の場合はステップＳＴ２０３に進む。一方、判定結果が「不可」の場合はステップＳＴ２０５に進む。
【００２６】
［ステップＳＴ２０３］：クエリチューンアップ部１０２は、代替処理実行部１０５が代替処理を行うのに必要な情報を収集し、代替処理情報として作成する。図４の例では「ＤＢＭＳ外ソート」に対応する代替処理情報を作成する。具体的には、“ＯＲＤＥＲ ＢＹ”命令に継続するカラム名を代替処理情報に設定する。すなわち、“ＯＲＤＥＲ ＢＹ”命令の後ろにある“ＮＡＭＥ”を代替処理情報に設定する。
【００２７】
［ステップＳＴ２０４］：クエリチューンアップ部１０２は、代替処理実行部１０５にて実行する処理をＤＢＭＳ２で実行しないように、アプリケーション検索要求４に含まれるデータ検索要求を変更する。図４の例では「ＤＢＭＳ外ソート」を代替処理実行部１０５にて実行するため、“ＯＲＤＥＲ ＢＹ”命令とそれに続くカラム名を、データ検索要求（ＳＱＬ文）から削除する。図２のデータ検索要求を、本工程で変更した場合のデータ検索要求を図５に示す。
【００２８】
［ステップＳＴ２０５］：クエリチューンアップ部１０２は、データ検索要求をＤＢＭＳアクセス部１０３に対して出力する。本工程におけるデータ検索要求は、ステップＳＴ２０３及びステップＳＴ２０４を実行している場合はステップＳＴ２０４で変更されたものである。一方、ステップＳＴ２０３及びステップＳＴ２０４を実行していない場合はクエリ発行ミドルウェア１が受信したアプリケーション検索要求４のデータ検索要求そのものである。
［ステップＳＴ２９９］：クエリチューンアップ部１０２は処理を終了する。
【００２９】
次に、マッピング部１０４の動作について、図１〜図３、図６、図７に基づき説明する。
図６は、この実施の形態におけるマッピング情報記憶部１０６が提供する変換ルールの一例を示したものである。変換ルールは、図６の左から順番に、ＤＢＭＳ２に格納しているテーブル名、ＤＢＭＳ２に格納しているテーブルのカラム名、アプリケーション３に渡す検索結果オブジェクト名、検索結果オブジェクトが持つメンバ名、で構成される。なお、検索結果オブジェクトとは、検索結果オブジェクトリスト７の個々の要素を指す。
【００３０】
図７は、この実施の形態におけるマッピング部１０４の動作を示すフローチャートである。
［ステップＳＴ３００］：マッピング部１０４は、ＤＢＭＳアクセス部１０３から検索結果リスト６が入力されると、処理を開始する。
［ステップＳＴ３０１］：マッピング部１０４は、データ検索要求から抽出したテーブル名及びカラム名を用いて、マッピング情報記憶部１０６に問い合わせを行う。問い合わせの結果としてマッピング情報記憶部１０６から変換ルールを取得する。
［ステップＳＴ３０２］：マッピング部１０４は、（ａ）検索結果オブジェクトリスト７を作成し、（ｂ）ステップＳＴ３０１で取得した変換ルールに記述されたオブジェクトを生成し、検索結果リスト６の個々の要素から取得したカラムの値をステップＳＴ３０１で取得した変換ルールに記述されたメンバに設定し、前記生成したオブジェクトを検索結果オブジェクトリスト７に追加する。（ｂ）の処理は検索結果リスト６に格納された要素の個数分実行する。
［ステップＳＴ３９９］：マッピング部１０４は、代替処理実行部１０５へ検索結果オブジェクトリスト７及び変換ルールを出力すると、処理を終了する。
【００３１】
次に、代替処理実行部１０５の動作について、図１、図３、図６、図８に基づき説明する。
図８は、この実施の形態における代替処理実行部１０５の動作を示すフローチャートである。
［ステップＳＴ４００］：代替処理実行部１０５は、マッピング部１０４から検索結果オブジェクトリスト７及び変換ルールが入力されると、処理を開始する。
［ステップＳＴ４０１］：代替処理実行部１０５は、クエリチューンアップ部１０２が代替処理情報を作成したか否かを判定する。作成している場合はステップＳＴ４０２に進む。一方、作成していない場合はステップＳＴ４９９に進む。
［ステップＳＴ４０２］：代替処理実行部１０５は、マッピング部１０４から入力された変換ルールと、クエリチューンアップ部１０２が作成した代替処理情報を用いて、代替処理に用いるメンバ名を決定する。本実施の形態では、「ＤＢＭＳ外ソート」に用いるカラムの名称が“ＮＡＭＥ”であるため、検索結果オブジェクトのメンバ“ｎａｍｅ”をソートに用いることになる。
［ステップＳＴ４０３］：代替処理実行部１０５は、ステップＳＴ４０１で決定したメンバを用いて、検索結果オブジェクトリスト７に対する代替処理を実行する。本実施の形態では、検索結果オブジェクトのメンバ「ｎａｍｅ」を用いたソートを実行する。
［ステップＳＴ４９９］：代替処理実行部１０５は、要求受付・応答部１０１に検索結果オブジェクトリスト７を出力すると、処理を終了する。
【００３２】
このように、実施の形態１のクエリ発行ミドルウェア１は、アプリケーション検索要求４を解析し、データ検索要求を変更し、ＤＢＭＳ２から取得した検索結果リスト６とマッピング情報記憶部１０６から取得した変換ルールに基づき検索結果オブジェクトリスト７を作成し、アプリケーション検索要求４の解析結果に基づき検索結果オブジェクトリスト７に対して代替処理を実行する。従って、アプリケーション３からはアプリケーション検索要求４の要求オプションのみを変更すれば、直ちにクエリ発行ミドルウェア１による代替処理を実行できることになり、結果としてアプリケーション３の開発工数を削減できる。具体的には、チューニングのためにデータ検索要求の分析及び変更を行う必要がなくなる、オブジェクト毎またはデータ検索要求毎に必要なチューニング処理（例えばソート）をアプリケーション３で実装する必要がなくなる、などの点でアプリケーション３の開発工数を削減できる。さらに、データ検索要求の変更が不要なため、アプリケーション３の保守性も向上する。
【００３３】
また、上記説明では、代替処理情報にカラム名のみを設定したが、他の項目を設定しても構わない。例えば、ソート順序（昇順・降順）を設定したり、複数のカラムを設定したりしても構わない。同様に、取得レコード数及び検索結果リスト内の取得範囲を示す“ＬＩＭＩＴ”及び“ＯＦＦＳＥＴ”についても、データ検索要求にそれらの記述がある場合は、代替処理情報に設定し、代替処理実行部１０５にて代替処理を実行することで、アプリケーション３からの要求を満たす検索を実行できる。
【００３４】
また、上記説明では、「ＤＢＭＳ外ソート」について述べたが、他の要求オプションを用いたチューニングも考えられる。
例えば、「ＤＢＭＳ外重複レコード削除」という要求オプションが有効になっている場合は、クエリチューンアップ部１０２にて、データ検索要求に重複を取り除く「ＤＩＳＴＩＮＣＴ」が記述されているかを検査し、記述されている場合は代替処理情報を作成し、さらに、代替処理実行部１０５にて代替処理情報を参照し、「ＤＢＭＳ外重複レコード削除」が設定されている場合は、指定カラムの値を検査し、検索結果オブジェクトリスト７に既に同じ値を持つレコードが存在すると当該検索結果オブジェクトを検索結果オブジェクトリスト７に追加しないとすることで、クエリ発行ミドルウェア１による「ＤＩＳＴＩＮＣＴ」の代替処理を実現できる。
【００３５】
また、上記説明ではデータ検索要求に“ＴＹＰＥ＿ＣＯＤＥ＝３”などのように検索条件に用いる値を直接記述していたが、“ＴＹＰＥ＿ＣＯＤＥ＝？”のように記述し実行時に設定するようにしてもよい。このとき、アプリケーション検索要求４には設定する値を記述し、ＤＢＭＳアクセス部１０３にてＤＢＭＳ２への設定値の指定を行えばよい。なお、上述の“ＬＩＭＩＴ”及び“ＯＦＦＳＥＴ”などのように、クエリチューンアップ部１０２によりデータ検索要求から削除される部分に対応する設定値については、代替処理情報に設定し、代替処理実行部１０５にて使用する。
【００３６】
以上のように、実施の形態１のクエリ実行システムによれば、データベース管理システムにクエリを発行し、その結果をデータベース管理システムから受け取るクエリ実行システムにおいて、アプリケーションから受けたクエリを解析し、クエリ内の命令に代替手段がある場合、代替手段に対応したクエリに変更するクエリチューンアップ部と、クエリチューンアップ部で変更されたクエリをデータベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、応答に対して、代替手段で書き換えてアプリケーションに結果として出力する代替処理実行部とを備えたので、性能チューニングに必要なコストを削減することができる。
【００３７】
また、実施の形態１のクエリ実行システムによれば、クエリチューンアップ部は、アプリケーションからの代替処理の要求に基づいてクエリの変更を行うようにしたので、クエリ実行システムにおいて代替処理を行うか否かをアプリケーションから容易に指定することができる。
【００３８】
実施の形態２．
実施の形態１では、アプリケーション３が送信するアプリケーション検索要求４にデータ検索要求（例えばＳＱＬ）が含まれていた。これは、アプリケーション３の内部にデータ検索要求が埋め込まれていることを意味している。
これに対し、実施の形態２では、アプリケーション３がユーザに提供する機能と、その詳細な実現手段としてのデータ検索要求を分離させ、アプリケーション３の保守性を向上させようとするものである。
【００３９】
すなわち、実施の形態２では、実施の形態１におけるアプリケーション検索要求４に相当する情報をクエリ発行ミドルウェアに予め登録し、アプリケーション３はアプリケーション検索要求４に相当する情報を特定するためのＩＤ（要求識別情報）をクエリ発行ミドルウェアに送信することにより、アプリケーション３における機能を分離し、アプリケーション３の保守性を向上させるものである。
【００４０】
実施の形態２に係るクエリ発行ミドルウェアを備えるデータベース検索システムの全体構成を図９に示す。
データベース検索システムは、クエリ発行ミドルウェア１ａ、ＤＢＭＳ２、アプリケーション３を備える。また、各機能ブロック間では、データベース検索要求５、検索結果リスト６、検索結果オブジェクトリスト７、検索要求ＩＤ８を送受信する。
【００４１】
クエリ発行ミドルウェア１ａは、実施の形態２のクエリ実行システムを構成するもので、アプリケーション３から送信された検索要求ＩＤ８に応じてＤＢＭＳ２へデータベース検索要求５を発行すると共に、ＤＢＭＳ２から受信した検索結果リスト６を検索結果オブジェクトリスト７に格納し、アプリケーション３へ応答する。検索要求ＩＤ８は、クエリ発行ミドルウェア１ａに予め登録されているアプリケーション検索定義を一意に特定するための識別情報である。例えば、整数値などを用いる。
なお、ＤＢＭＳ２、アプリケーション３、データベース検索要求５、検索結果リスト６、検索結果オブジェクトリスト７については実施の形態１と同様であるためその説明を省略する。
【００４２】
図１０は、実施の形態２に係るクエリ発行ミドルウェア１ａの一例を示す構成図である。
クエリ発行ミドルウェア１ａは、要求受付・応答部１０１、クエリチューンアップ部１０２ａ、ＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６、データ検索定義記憶部１０７を備える。ここで、ＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６については、実施の形態１と同様であるためその説明を省略する。
【００４３】
要求受付・応答部１０１は、アプリケーション３から検索要求ＩＤ８を受信すると、受信した検索要求ＩＤ８をクエリチューンアップ部１０２ａへと出力する。また、代替処理実行部１０５から検索結果オブジェクトリスト７が入力されると、入力された検索結果オブジェクトリスト７をアプリケーション３に送信する。
【００４４】
クエリチューンアップ部１０２ａは、要求受付・応答部１０１から入力された検索要求ＩＤ８を用いて、データ検索定義記憶部１０７から検索に用いるアプリケーション検索要求４を取得する。アプリケーション検索要求４を取得した後の処理は、実施の形態１と同様である。これらの処理の詳細については後述する。
【００４５】
データ検索定義記憶部１０７は、データ検索定義９を記憶する。データ検索定義９の構成の一例を図１１に示す。データ検索定義９は、アプリケーション検索要求４と、検索要求ＩＤ８で構成される。データ検索定義９は、アプリケーション開発者が予め作成し、データ検索定義記憶部１０７へ保存しておく。
【００４６】
次に、図９〜図１２を用いて、実施の形態２におけるクエリ発行ミドルウェア１ａの動作を詳細に説明する。
図１２は、この実施の形態におけるクエリチューンアップ部１０２ａの動作を示すフローチャートである。
［ステップＳＴ２００ａ］：クエリチューンアップ部１０２ａは、要求受付・応答部１０１から検索要求ＩＤ８が入力されると、処理を開始する。
［ステップＳＴ２０６］：クエリチューンアップ部１０２ａは、検索要求ＩＤ８を用いてデータ検索定義記憶部１０７に問い合わせを行う。問い合わせの結果としてデータ検索定義記憶部１０７からデータ検索定義９を取得する。ここで、検索要求ＩＤ８の値が１００とすると、図１１に示すデータ検索定義９が得られる。
【００４７】
ステップＳＴ２０１以降の工程では、クエリチューンアップ部１０２ａは、データ検索定義記憶部１０７から取得したデータ検索定義９に含まれるアプリケーション検索要求４を用いるため、ステップＳＴ２０１〜ステップＳＴ２９９の動作は実施の形態１と同様である。このため、ステップＳＴ２０１以降の工程についての説明は省略する。
【００４８】
また、クエリチューンアップ部１０２ａからＤＢＭＳアクセス部１０３にクエリ発行要求を行った後のＤＢＭＳアクセス部１０３の動作や、ＤＢＭＳアクセス部１０３から検索結果リスト６を受け取った場合のマッピング部１０４や代替処理実行部１０５の動作は実施の形態１と同様であるため、ここでの説明は省略する。
【００４９】
実施の形態２に係るクエリ発行ミドルウェア１ａには次のような効果がある。すなわち、アプリケーション３から検索要求ＩＤ８を受信し、受信した検索要求ＩＤ８に基づきデータ検索定義記憶部１０７からアプリケーション検索要求４を取得する。アプリケーション検索要求４及び要求オプションをクエリ発行ミドルウェア１ａに登録させることにより、複数のアプリケーション検索要求及び要求オプションをクエリ発行ミドルウェア１ａにて一括して管理することになる。従って、アプリケーション検索要求４もしくは要求オプションを変更する際に、対象となるアプリケーション検索要求４もしくは要求オプションを探索することが、アプリケーション３から該当する箇所を探索するよりも容易に可能となる。
【００５０】
また、実施の形態２では、アプリケーション３の開発においてクエリ発行ミドルウェア１ａから得られる検索結果オブジェクトリストの仕様のみを把握していればよい。すなわち、アプリケーション検索要求４の詳細（例えばＳＱＬの内容）に対する知識がなくてもアプリケーション３の開発が可能となるといった利点もある。
【００５１】
以上のように、実施の形態２のクエリ実行システムによれば、データベース管理システムにクエリを発行し、その結果をデータベース管理システムから受け取るクエリ実行システムにおいて、予め定められた要求識別情報に対応したクエリを格納するデータ検索定義記憶部と、アプリケーションから要求識別情報を受けた場合、要求識別情報に対応したクエリをデータ検索定義記憶部から取得し、取得したクエリ内の命令に代替手段がある場合、代替手段に対応したクエリに変更するクエリチューンアップ部と、クエリチューンアップ部で変更されたクエリをデータベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、応答に対して、代替手段で書き換えてアプリケーションに結果として出力する代替処理実行部とを備えたので、実施の形態１の効果に加えて、アプリケーションの保守性を向上させることができるという効果がある。
【００５２】
実施の形態３．
実施の形態１や実施の形態２では、クエリチューンアップ部１０２（１０２ａ）にて、アプリケーション３から送信されたアプリケーション検索要求４もしくは検索要求ＩＤ８を受信する度に、アプリケーション検索要求４を解析してデータ検索要求の変更、及び代替処理情報の生成を行っていた。ここで、同じ検索を頻繁に実行する場合は、クエリチューンアップ部１０２（１０２ａ）の処理も同じであるため、このような場合は、クエリチューンアップ部１０２（１０２ａ）の処理を削減したいという要望がある。
そこで、実施の形態３では、クエリチューンアップ部１０２（１０２ａ）で実行していた処理をクエリ発行ミドルウェアの外部で事前に実行し、その結果をクエリ発行ミドルウェアで管理することで、クエリ発行ミドルウェアによるデータ検索要求の解析処理などが不要となり、検索処理に要する時間の短縮化を実現する。
【００５３】
実施の形態３に係るクエリ発行ミドルウェアを備えるデータベース検索システムの全体構成を図１３に示す。実施の形態２と実施の形態３の違いは、クエリ発行ミドルウェア１ｂが解析後データ検索定義１１を使用すること、及び解析後データ検索定義１１を作成するクエリ解析ツール１０が存在することである。
図１３に示すように、データベース検索システムは、クエリ発行ミドルウェア１ｂ、ＤＢＭＳ２、アプリケーション３を備え、外部にクエリ解析ツール１０を備える。クエリ解析ツール１０は、データ検索定義９を入力し、チューンアップを行って解析後データ検索定義１１を出力するツールである。すなわち、解析後データ検索定義１１は次のような定義である。
解析後データ検索定義１１の構成の一例を図１４に示す。解析後データ検索定義１１は、データ検索定義９から要求オプションを削除し、代替処理情報を追加したものである。また、解析後データ検索定義１１のデータ検索要求は、クエリ解析ツール１０により、データ検索要求及び要求オプションに応じて、データ検索定義９のデータ検索要求を加工したものである。
【００５４】
クエリ発行ミドルウェア１ｂは、実施の形態３のクエリ実行システムを構成するもので、アプリケーション３から検索要求ＩＤ８を受けた場合、その検索要求ＩＤ８に対応した解析後データ検索定義１１を得て、この解析後データ検索定義１１をＤＢＭＳ２に送信するよう構成されている。
図１５は、実施の形態３のクエリ発行ミドルウェア１ｂの一例を示す構成図である。
クエリ発行ミドルウェア１ｂは、要求受付・応答部１０１、ＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６、解析後データ検索定義取得部１０８、解析後データ検索定義記憶部１０９を備える。
要求受付・応答部１０１は、検索要求ＩＤ８を受信した場合の送信先が解析後データ検索定義取得部１０８であること以外は実施の形態２の要求受付・応答部１０１と同様である。また、ＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６については、実施の形態２と同様の構成であるため、ここでの説明は省略する。
【００５５】
解析後データ検索定義取得部１０８は、要求受付・応答部１０１から入力された検索要求ＩＤ８を用いて、解析後データ検索定義記憶部１０９から解析後データ検索定義１１を取得する。その後、取得した解析後データ検索定義１１に含まれるデータ検索要求をＤＢＭＳアクセス部１０３に対して出力する。解析後データ検索定義記憶部１０９は、解析後データ検索定義１１を記憶する記憶部である。解析後データ検索定義１１は、アプリケーション開発者がクエリ解析ツール１０を用いて予め作成し、解析後データ検索定義記憶部１０９へ保存しておく。
【００５６】
図１３に戻り、データベース検索要求５、検索結果リスト６、検索結果オブジェクトリスト７、検索要求ＩＤ８については実施の形態２と同様であるため、これらの説明は省略する。
【００５７】
次に、実施の形態３のクエリ実行システムの動作について説明する。
先ず、クエリ解析ツール１０の動作について、図１１、図１３、図１４、図１６を用いて説明する。
図１６は、実施の形態３におけるクエリ解析ツール１０の動作を示すフローチャートである。
［ステップＳＴ５００］：クエリ解析ツール１０は、データ検索定義９が入力されると、処理を開始する。
［ステップＳＴ５０１］：クエリ解析ツール１０は、データ検索定義９に基づき解析後データ検索定義１１を作成する。検索要求ＩＤ及びデータ検索要求については、データ検索定義９に格納されている値をそのまま解析後データ検索定義１１に設定する。代替処理情報については、何も設定しない。
［ステップＳＴ５０２］：クエリ解析ツール１０は、データ検索定義９に含まれる要求オプションを参照し、チューンアップ要求の有無を判定する。図１１に示した例では「ＤＢＭＳ外ソート」を参照する。判定結果が「要求有」の場合はステップＳＴ５０３に進む。一方、判定結果が「要求無」の場合はステップＳＴ５９９に進む。
【００５８】
［ステップＳＴ５０３］：クエリ解析ツール１０は、データ検索定義９に含まれるデータ検索要求を参照し、チューンアップの実施可否を判定する。図１１の例では「ＤＢＭＳ外ソート」のチューンアップについて判定するため、データ検索要求内に“ＯＲＤＥＲ ＢＹ”命令が含まれている場合にチューンアップ可能と判定する。判定結果が「可能」の場合はステップＳＴ５０４に進む。一方、判定結果が「不可」の場合はステップＳＴ５９９に進む。
［ステップＳＴ５０４］：クエリ解析ツール１０は、クエリ発行ミドルウェア１ｂが代替処理を行うのに必要な情報を収集し、解析後データ検索定義１１の代替処理情報に設定する。図１１の例では「ＤＢＭＳ外ソート」に対応する代替処理情報を設定する。具体的には、“ＯＲＤＥＲ ＢＹ”命令に継続するカラム名を解析後データ検索定義１１の代替処理情報に設定する。
［ステップＳＴ５０５］：クエリ解析ツール１０は、クエリ発行ミドルウェア１ｂにて実行する処理をＤＢＭＳ２で実行しないように、データ検索定義９のデータ検索要求を変更し、解析後データ検索定義１１のデータ検索要求に設定する。図１１の例では「ＤＢＭＳ外ソート」をクエリ発行ミドルウェア１ｂにて実行するため、“ＯＲＤＥＲ ＢＹ”命令とそれに続くカラム名を、データ検索要求から削除し、解析後データ検索定義１１のデータ検索要求に設定する。
［ステップＳＴ５９９］：クエリ解析ツール１０は処理を終了する。
【００５９】
このように、クエリ解析ツール１０の動作は、基本的に実施の形態１のクエリチューンアップ部１０２の動作（図４）と同様であるが、入力として用いる情報が、実施の形態１ではアプリケーション検索要求４であるのに対し、クエリ解析ツール１０ではデータ検索定義９である点が異なっている。
【００６０】
次に、図１３〜図１５に基づき、実施の形態３におけるクエリ発行ミドルウェア１ｂの動作について説明する。
要求受付・応答部１０１は、アプリケーション３から検索要求ＩＤ８を受け取ると、これを解析後データ検索定義取得部１０８に出力する。解析後データ検索定義取得部１０８は、要求受付・応答部１０１から入力された検索要求ＩＤ８を用いて、解析後データ検索定義記憶部１０９からその検索要求ＩＤ８に対応した解析後データ検索定義１１を取得する。その後、取得した解析後データ検索定義１１に含まれるデータ検索要求をＤＢＭＳアクセス部１０３に出力する。これ以降のＤＢＭＳアクセス部１０３、マッピング部１０４、代替処理実行部１０５、マッピング情報記憶部１０６に関する動作については、実施の形態１，２と同様であるためこれらの説明を省略する。
【００６１】
このように、実施の形態３におけるクエリ発行ミドルウェア１ｂは、アプリケーション３から検索要求ＩＤ８を受信し、受信した検索要求ＩＤ８に基づき解析後データ検索定義記憶部１０９から解析後データ検索定義１１を取得し、ＤＢＭＳアクセス部１０３への入力などを行う。従って、クエリ発行ミドルウェア１ｂの内部でデータ検索要求の解析及び変更を行わないため、その分クエリ発行ミドルウェア１ｂの処理に要する時間が減少し、データベース検索システムの性能向上を実現する。
【００６２】
以上のように、実施の形態３のクエリ実行システムによれば、データベース管理システムにクエリを発行し、その結果をデータベース管理システムから受け取るクエリ実行システムにおいて、クエリ内の命令に代替手段がある場合に代替手段に対応したクエリを要求識別情報に関連付けて定義する解析後データ検索定義記憶部と、アプリケーションから要求識別情報を受けた場合、要求識別情報に対応したクエリを解析後データ検索定義記憶部より取得する解析後データ検索定義取得部と、解析後データ検索定義取得部で取得したクエリをデータベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、応答に対して、代替手段で書き換えてアプリケーションに結果として出力する代替処理実行部とを備えたので、実施の形態２の効果に加えて、例えば、同じ検索を頻繁に実行するといった場合の処理量を削減することができるといったように、データベース検索システムの性能向上に寄与することができる効果がある。
【００６３】
なお、本願発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。
【符号の説明】
【００６４】
１，１ａ，１ｂ クエリ発行ミドルウェア、２ データベース管理システム（ＤＢＭＳ）、３ アプリケーション、４ アプリケーション検索要求、５ データベース検索要求、６ 検索結果リスト、７ 検索結果オブジェクトリスト、８ 検索要求ＩＤ、９ データ検索定義、１０ クエリ解析ツール、１１ 解析後データ検索定義、１０１ 要求受付・応答部、１０２，１０２ａ クエリチューンアップ部、１０３ ＤＢＭＳアクセス部、１０４ マッピング部、１０５ 代替処理実行部、１０６ マッピング情報記憶部、１０７ データ検索定義記憶部、１０８ 解析後データ検索定義取得部、１０９ 解析後データ検索定義記憶部。
【特許請求の範囲】
【請求項１】
データベース管理システムにクエリを発行し、その結果を当該データベース管理システムから受け取るクエリ実行システムにおいて、
アプリケーションから受けたクエリを解析し、当該クエリ内の命令に代替手段がある場合、当該代替手段に対応したクエリに変更するクエリチューンアップ部と、
前記クエリチューンアップ部で変更されたクエリを前記データベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、
前記応答に対して、前記代替手段で書き換えて前記アプリケーションに結果として出力する代替処理実行部とを備えたクエリ実行システム。
【請求項２】
クエリチューンアップ部は、アプリケーションからの代替処理の要求に基づいてクエリの変更を行うことを特徴とする請求項１記載のクエリ実行システム。
【請求項３】
データベース管理システムにクエリを発行し、その結果を当該データベース管理システムから受け取るクエリ実行システムにおいて、
予め定められた要求識別情報に対応したクエリを格納するデータ検索定義記憶部と、
前記アプリケーションから要求識別情報を受けた場合、当該要求識別情報に対応したクエリを前記データ検索定義記憶部から取得し、当該取得したクエリ内の命令に代替手段がある場合、当該代替手段に対応したクエリに変更するクエリチューンアップ部と、
前記クエリチューンアップ部で変更されたクエリを前記データベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、
前記応答に対して、前記代替手段で書き換えて前記アプリケーションに結果として出力する代替処理実行部とを備えたクエリ実行システム。
【請求項４】
データベース管理システムにクエリを発行し、その結果を当該データベース管理システムから受け取るクエリ実行システムにおいて、
クエリ内の命令に代替手段がある場合に当該代替手段に対応したクエリを要求識別情報に関連付けて定義する解析後データ検索定義記憶部と、
アプリケーションから要求識別情報を受けた場合、当該要求識別情報に対応したクエリを前記解析後データ検索定義記憶部より取得する解析後データ検索定義取得部と、
前記解析後データ検索定義取得部で取得したクエリを前記データベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、
前記応答に対して、前記代替手段で書き換えて前記アプリケーションに結果として出力する代替処理実行部とを備えたクエリ実行システム。
【請求項１】
データベース管理システムにクエリを発行し、その結果を当該データベース管理システムから受け取るクエリ実行システムにおいて、
アプリケーションから受けたクエリを解析し、当該クエリ内の命令に代替手段がある場合、当該代替手段に対応したクエリに変更するクエリチューンアップ部と、
前記クエリチューンアップ部で変更されたクエリを前記データベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、
前記応答に対して、前記代替手段で書き換えて前記アプリケーションに結果として出力する代替処理実行部とを備えたクエリ実行システム。
【請求項２】
クエリチューンアップ部は、アプリケーションからの代替処理の要求に基づいてクエリの変更を行うことを特徴とする請求項１記載のクエリ実行システム。
【請求項３】
データベース管理システムにクエリを発行し、その結果を当該データベース管理システムから受け取るクエリ実行システムにおいて、
予め定められた要求識別情報に対応したクエリを格納するデータ検索定義記憶部と、
前記アプリケーションから要求識別情報を受けた場合、当該要求識別情報に対応したクエリを前記データ検索定義記憶部から取得し、当該取得したクエリ内の命令に代替手段がある場合、当該代替手段に対応したクエリに変更するクエリチューンアップ部と、
前記クエリチューンアップ部で変更されたクエリを前記データベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、
前記応答に対して、前記代替手段で書き換えて前記アプリケーションに結果として出力する代替処理実行部とを備えたクエリ実行システム。
【請求項４】
データベース管理システムにクエリを発行し、その結果を当該データベース管理システムから受け取るクエリ実行システムにおいて、
クエリ内の命令に代替手段がある場合に当該代替手段に対応したクエリを要求識別情報に関連付けて定義する解析後データ検索定義記憶部と、
アプリケーションから要求識別情報を受けた場合、当該要求識別情報に対応したクエリを前記解析後データ検索定義記憶部より取得する解析後データ検索定義取得部と、
前記解析後データ検索定義取得部で取得したクエリを前記データベース管理システムに要求し、その応答を受け取るＤＢＭＳアクセス部と、
前記応答に対して、前記代替手段で書き換えて前記アプリケーションに結果として出力する代替処理実行部とを備えたクエリ実行システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１２−１３３４６４（Ｐ２０１２−１３３４６４Ａ）
【公開日】平成２４年７月１２日（２０１２．７．１２）
【国際特許分類】
【出願番号】特願２０１０−２８３２１１（Ｐ２０１０−２８３２１１）
【出願日】平成２２年１２月２０日（２０１０．１２．２０）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
【公開日】平成２４年７月１２日（２０１２．７．１２）
【国際特許分類】
【出願日】平成２２年１２月２０日（２０１０．１２．２０）
【出願人】（０００００６０１３）三菱電機株式会社 (33,312)
【Ｆターム（参考）】
[ Back to top ]