JP2007066017A - データベースに対するアクセスを制御するシステム、およびその方法 - Google Patents

Abstract

【課題】データベースに対するアクセスをこれまでよりも効率化する。
【解決手段】データベースに対するアクセスを制御するシステムであって、データベースに対するアクセス命令を複数含むアクセスプログラムを取得する取得部と、データベースのうち、複数のアクセス命令によってアクセスされる互いに異なる複数のテーブルを検出する検出部と、検出された複数のテーブルを結合した結果テーブルをデータベースから取得する結合命令を、当該複数のアクセス命令に先立って実行させる結合制御部と、複数のアクセス命令によってアクセスされるレコードを結果テーブルから抽出して複数のアクセス命令によってアクセス可能な構造に変換する変換命令を、これら複数のアクセス命令よりも先に実行させる変換制御部とを備えるシステムを提供する。
【選択図】図４

Description

本発明は、データベースにアクセスするシステム、およびその方法に関する。特に、本発明は、そのアクセスを制御するシステム、およびその方法に関する。

ビジネス・アプリケーションプログラムは、データベース（以下、ＤＢ）中の互いに関連する複数のテーブルをアクセスする場合がある。例えば、あるプログラムは、まず顧客の属性を管理するCustomerというテーブルにアクセスしてある特定の顧客データを入手する。次に、そのプログラムは、顧客の口座を管理するAccountというテーブルにアクセスしてその顧客に対応する口座データを取得する。このプログラムにおいて、これらの２つのテーブルに対するクエリは、逐次にかつ別々に発行される。

この例において、２回目のアクセスは、１回目のアクセスにより得られたデータをキーにして行われる。即ち、２回目のアクセスにより得られるデータは、１回目のアクセスにより得られるデータに依存する。このため、変数値のデータ依存性を利用する既存の最適化技術によっては、これらのアクセスは１つに統合できないという問題があった。

この問題は、特に、このビジネスロジックを繰り返すバッチ処理において顕著になる。バッチ処理を最適化するには、バッチ処理のチェックポイント毎に次の処理に用いるデータを予めキャッシュする方法が考えられる。例えば、アクセスキーを示す変数の値を解析することによりアクセスされるデータの範囲を特定し、その範囲のデータを予めＤＢから取得しておくことができる。

しかしながら、上述のAccountというテーブルについては、アクセスキーがCustomerというテーブルに記録されているので、どの範囲のデータがアクセスされるかを予め特定できない。このため、データをＤＢから予め取得することができず、バッチ処理中の繰り返し処理の毎にＤＢに対するアクセスが発生し、プログラム全体として効率が悪くなる場合があった。

また、他の例として、プログラムは、同一のキーにより複数の異なるテーブルをアクセスする場合がある。この場合には、プログラムは、テーブル毎にクエリを発行する。しかしながら、ＤＢに対するクエリは外部の通信回線を経由する場合が多く、その回数が増えるとプログラム全体の効率が悪くなる場合があった。

これに関し、従来、ＤＢに対するアクセスを制御する技術が提案されている。これらの概要を述べる。
１）検査ループ（Ｉｎｓｐｅｃｔｉｏｎ Ｌｏｏｐ）の生成
テーブルＡに対するアクセスの結果得られたデータに基づいてテーブルＢにアクセスする場合に、テーブルＢに対するアクセスを効率化する技術である。この技術においては、プログラムの実行中に、実際にテーブルＡから得られた結果セットに対して検査ループを実行して、テーブルＢをアクセスするキーのセットを求める。そして、そのキーのセットによりアクセスされる範囲のデータをテーブルＢから予め取得する命令コードを動的に生成する。

２）ＣＭＲ（Ｃｏｎｔａｉｎｅｒ Ｍａｎａｇｅｄ Ｒｅｌａｔｉｏｎｓｈｉｐ）を使った先読み（ｒｅａｄ−ａｈｅａｄ）機構の使用
この方法では、アプリケーションサーバーにおいて、互いに関連する複数のテーブルがあることをプログラマが指定できる仕組みが提供される。指定された複数のテーブルは、結合演算によってＤＢから読み出され、プログラムから参照可能なキャッシュに記録される（非特許文献１および２を参照。）。具体的には、プログラマは、deployment descriptorと呼ばれる指定子によって関連ある複数のテーブルを指定する。キャッシュを管理するEJB (Enterprise Java Beans)コンテナは、この指定子に基づいてSQLを発行する。なお、Javaは登録商標である。

WebSphere journal URL, http://websphere.sys-con.com/read/43288.htm WebSphere information center URL, http://publib.boulder.ibm.com/infocenter/wasinfo/v5r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/cejb_read.html

しかしながら、上述の検査ループを生成する技術において、テーブルＡに対するクエリを発行して検査対象のデータを生成する処理は、プログラム本来の処理ではない。また、検査ループを実行させてアクセスキーを解析する処理も、プログラム本来の処理ではない。このため、これらの処理の追加によって、プログラム全体の効率が低下するおそれがある。また、テーブルＢに対して動的にＳＱＬを生成するので、そのＳＱＬ文に対して静的な最適化を行うことができない。また、検査ループの処理によってプログラムが複雑になり、プログラムの保守性・堅牢性が低下するおそれがある。

また、上記のＣＭＲを使った技術においては、プログラマが互いに関係するテーブルを指定しなければならず、プログラマの負担が大きい。また、この技術をバッチ処理に適用する場合において、既存のプログラムの構造を変更しないことを条件とすると、この技術の適用範囲は広くない。即ち、バッチ処理においては同様の処理を繰り返すが、ある繰り返し処理によってアクセスされるレコードと、他の繰り返し処理によってアクセスされるレコードとの間の関係を、このdeployment descriptorによって指定することはできない。従って、繰り返し処理の開始前に必要なレコードを一括して取得するといった最適化を実現できない。

その他、プログラマが手動でＳＱＬを書換える最適化も考えられるが、プログラマの能力・経験によってその効率は様々であり、プログラム毎に費用や時間をかけてプログラムを書き換えなければならず、現実的でない。また、EJB(Enterprise Java Beans)のプログラムにおいてこのような書換えを行うには、プログラムを大幅に変更する必要がある。具体的には、EJB(Enterprise Java Beans)のプログラミングモデルにおいて、ＤＢの各レコードはentity beanで表現され、getterまたはsetterというメソッドでアクセスされる。プログラマは、これらのメソッドを用いれば、ＤＢの構造を意識することなく必要なレコードを取得することができる。複数のアクセスを手動で１つに統合する作業は、このようなプログラミングモデルに反し、例え可能であってもプログラムの保守性を大幅に低下させてしまう。

そこで本発明は、上記の課題を解決することのできるシステム、方法、および、プログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。

上記課題を解決するために、本発明においては、データベースに対するアクセスを制御するシステムであって、データベースに対するアクセス命令を複数含むアクセスプログラムを取得する取得部と、データベースのうち、複数のアクセス命令によってアクセスされる互いに異なる複数のテーブルを検出する検出部と、検出された複数のテーブルを結合した結果テーブルをデータベースから取得する結合命令を、当該複数のアクセス命令に先立って実行させる結合制御部と、複数のアクセス命令の各々に、結果テーブルをアクセスさせる制御を行うアクセス制御部とを備えるシステム、当該システムとして情報処理装置を機能させる方法、および、プログラムを提供する。

なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。

本発明によれば、データベースに対するアクセスをこれまでよりも効率化できる。

以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、情報処理システム１０の全体構成を示す。情報処理システム１０は、アプリケーションサーバシステム３０と、ＤＢ管理サーバ４０と、ＤＢ４５とを備える。アプリケーションサーバシステム３０は、アクセスプログラム２０を取得して実行する。そして、アプリケーションサーバシステム３０は、アクセスプログラム２０に記述された指示に基づいて、ＤＢ４５をアクセスするための要求をＤＢ管理サーバ４０に送信する。より詳細には、アプリケーションサーバシステム３０は、J2EE(Java2 Enterprise Edition)の仕様を実現する仮想マシンを搭載しており、また、JDBC(Java DataBase Connectivity)の機能を搭載している。そして、アプリケーションサーバシステム３０は、Java(登録商標)で記述されたアクセスプログラム２０を取得し、それに対して必要な最適化を行って実行する。

ＤＢ管理サーバ４０は、アプリケーションサーバシステム３０から受けた要求に応じてＤＢ４５からデータを取得し、アプリケーションサーバシステム３０に返信する。ＤＢ４５は、アプリケーションサーバシステム３０によりアクセスされるデータを記録している。例えば、ＤＢ４５は、表形式のデータをキーにより検索可能に格納した、関係データベースと呼ばれる構造を採ってもよい。また、アプリケーションサーバシステム３０は、ＤＢ４５から取得したデータを一時的に格納するバッファメモリ３５を有する。バッファメモリ３５は、例えば、ＥＪＢコンテナのＢｅａｎキャッシュと呼ばれる記憶領域であり、ＤＢ４５を構成するテーブルのレコードを、Ｂｅａｎと呼ばれるオブジェクト形式で記憶する。

ここで、アプリケーションサーバシステム３０およびＤＢ管理サーバ４０間は、電気通信回線で接続されており、その通信速度は比較的低速な場合がある。このような場合には、アプリケーションサーバシステム３０がＤＢ４５に対して頻繁にアクセスすると、通信時間が長くなり処理の効率が低下する。本実施例に係るアプリケーションサーバシステム３０は、アクセスプログラム２０の処理内容を解析することにより、アクセスプログラム２０による処理結果を変更しない限りにおいてＤＢ４５に対するアクセス頻度を低減し、処理を効率化することを目的とする。

図２は、アクセスプログラム２０の一例を示す。１行目から３７行目までのプログラムコードは、全体で１つのバッチ処理を示す。３行目のプログラムコードは、バッチ処理用の入力データを取得する処理を示す。そして、１１行目から３１行目までのプログラムコードは、バッチ処理におけるトランザクション処理の実体を示す。８行目のプログラムコードは、トランザクション処理の開始を示す。

１１行目から３１行目のプログラムコードは、チェックポイントの候補を境界としてバッチ処理を分割した内側ループを示す。チェックポイントの位置は予め静的に定められていなくともよく、チェックポイントの候補の中から管理ポリシーによって動的に定められてもよい。即ち例えば、バッチ処理がオンライン処理と平行する昼間の運用時は、バッチ処理のみを行う夜間の運用時と比較して、チェックポイントの間隔を短く設定してもよい。

内側ループにおいて、１６行目のプログラムコードは、変数ｃｕｓｔｏｍｅｒＫｅｙをプライマリ・キーとしてテーブル中のレコードを取得する処理を示す。同様に、２１行目のプログラムコードは、変数ｃｒｅｄｉｔＫｅｙをプライマリ・キーとしてテーブル中のレコードを取得する処理を示す。同様に、２６行目のプログラムコードは、変数ｄｅｂｉｔＫｅｙをプライマリ・キーとしてテーブル中のレコードを取得する処理を示す。

また、３３行目のプログラムコードは、チェックポイントのためのコンテナサービスを呼び出す処理を示す。３５行目のプログラムコードは、トランザクション処理の処理結果をコミットする処理を示す。

図３は、相互に所定の関係を有する複数のテーブルの例を示す。図３（ａ）は、図２に示すアクセスプログラム２０においてアクセスされる複数のテーブルについて、それらのテーブルから生成されるＢｅａｎの間の関係を示す。ここでＢｅａｎとは、テーブルから読み出されたレコードをＪａｖａプログラムによってアクセス可能な形式に変換したオブジェクトをいう。

図３（ａ）に示すように、Ｂｅａｎ「ｃｕｓｔｏｍｅｒ」は、入力データ「ｉｎｐｕｔ」に依存する。即ち、第１のテーブルの一例であるテーブル「ｃｕｓｔｏｍｅｒ」は、入力データ「ｉｎｐｕｔ」に基づき、第１のアクセス命令によってアクセスされる。また、Ｂｅａｎ「ｃｒｅｄｉｔＡｃｃｏｕｎｔ」は、Ｂｅａｎ「ｃｕｓｔｏｍｅｒ」に依存する。即ち、第２のテーブルの一例であるテーブル「ｃｒｅｄｉｔＡｃｃｏｕｎｔ」は、テーブル「ｃｕｓｔｏｍｅｒ」から読み出したレコード中の要素をキーとして第２のアクセス命令によりアクセスされる。

また、Ｂｅａｎ「ｃｕｓｔｏｍｅｒ」は、入力データ「ｉｎｐｕｔ」に依存する。即ち、第１のテーブルの一例であるテーブル「ｃｕｓｔｏｍｅｒ」は、入力データ「ｉｎｐｕｔ」に基づき、第１のアクセス命令によってアクセスされる。また、Ｂｅａｎ「ｄｅｂｉｔＡｃｃｏｕｎｔ」は、Ｂｅａｎ「ｃｕｓｔｏｍｅｒ」に依存する。即ち、第２のテーブルの一例であるテーブル「ｄｅｂｉｔＡｃｃｏｕｎｔ」は、テーブル「ｃｕｓｔｏｍｅｒ」から読み出したレコード中の要素をキーとして第２のアクセス命令によりアクセスされる。

このように、アクセスプログラム２０によれば、アプリケーションサーバシステム３０は、データベースに対して１回目にアクセスした結果に基づいて２回目のアクセスを行う。ここで、１回目にアクセスするデータの範囲は、バッチ処理の内側ループを開始する前に解析できる場合がある。例えば、テーブル「ｃｕｓｔｏｍｅｒ」は、入力データ「ｉｎｐｕｔ」に基づいてアクセスされ、入力データ「ｉｎｐｕｔ」の内容は内側ループの開始に先立って判明する。このため、内側ループの外側、例えば、９行目において、テーブル「ｃｕｓｔｏｍｅｒ」から予め必要なデータを取得する最適化が可能である。

一方で、２回目にアクセスされるデータの範囲は、１回目にアクセスした結果に依存するので、予め特定できない場合が多い。即ち、アクセスプログラム２０において、Ｂｅａｎ「ｃｒｅｄｉｔＡｃｃｏｕｎｔ」は、Ｂｅａｎ「ｃｕｓｔｏｍｅｒ」に依存する。そして、Ｂｅａｎ「ｃｕｓｔｏｍｅｒ」の内容は、内側ループの開始時には判明していない。このため、内側ループ内の例えば２１行目において、内側ループの繰り返しの毎にテーブル「ｃｒｅｄｉｔＡｃｃｏｕｎｔ」に対するアクセスが発生する。本実施例に係るアプリケーションサーバシステム３０は、このような非効率なアクセスの回数を低減することを目的とする。

図３（ｂ）は、以上の例のほか、本実施例に係るアプリケーションサーバシステム３０により最適化の対象となるテーブル間の関係を示す。図３（ｂ−１）は、アクセスプログラムの他の例を示す。１行目のプログラムコードは、入力データを変数「ｃＩＤ」に格納する処理を示す。２行目のプログラムコードは、この変数をキーとしてＢｅａｎ「Ａ」のホームインターフェイスに対して対応するテーブル中のレコードを取得する処理を示す。３行目のプログラムコードは、同様にこの変数をキーとしてＢｅａｎ「Ｂ」のホームインターフェースに対して対応するテーブル中のレコードを取得する処理を示す。

図３（ｂ−２）は、このアクセスプログラムにおけるテーブル間の関係を示す。テーブルＡおよびテーブルＢは、共に同一のキーｃＩＤを有するアクセス命令によってアクセスされる。本実施例に係るアプリケーションサーバシステム３０は、このような関係にある２つのテーブルについても、複数のアクセス命令によるアクセスを１つに統合して処理を効率化することを目的とする。

図４は、アプリケーションサーバシステム３０の機能構成を示す。アプリケーションサーバシステム３０は、既に述べたようにバッファメモリ３５を有し、更に、取得部３００と、検出部３１０と、解析部３２０と、計測制御部３３０と、結合制御部３４０と、変換制御部３５０と、判断部３６０と、ビュー制御部３７０と、実行部３８０とを有する。取得部３００は、ＤＢ４５に対するアクセス命令を含むアクセスプログラム２０を取得する。検出部３１０は、ＤＢ４５のうち、アクセスプログラム２０に含まれる複数のアクセス命令によってアクセスされる互いに異なる複数のテーブルを検出する。解析部３２０は、アクセスプログラム２０を静的に解析することによりアクセスプログラム２０に含まれるアクセス命令の特徴を判断する。

例えば、解析部３２０は、アクセスプログラム２０を解析することにより、アクセス命令毎に、アクセスプログラム２０が実行されれば必ずそのアクセス命令が実行されるか否かを判断してもよい。計測制御部３３０は、必ずしも実行されないと判断されたアクセス命令について、そのアクセス命令が実行される確率を計測する計測命令を、アクセスプログラム２０の実行中に実行させる。例えば、計測制御部３３０は、その計測命令をアクセスプログラム２０中に挿入してもよい。実行確率を計測する技術はプロファイリング等と呼ばれ、従来公知であるから更に詳しい説明を省略する。

また、解析部３２０は、検出部３１０により検出された複数のテーブルについて、このうち第１のテーブルを第１のアクセス命令がプライマリ・キーによりアクセスし、かつ、このうち第２のテーブルを第２のアクセス命令がプライマリ・キーによりアクセスするか否かを判断してもよい。この場合、計測制御部３３０は、第１のテーブルおよび第２のテーブルの少なくとも一方がプライマリ・キーによりアクセスされないことを条件に、当該一方のテーブルから結合命令によりレコードが冗長に読み出される冗長度を計測する計測命令を実行させる。

結合制御部３４０は、検出した複数のテーブルを結合した結果テーブルをＤＢ４５から取得する結合命令を、当該複数のテーブルにアクセスする複数のアクセス命令に先立って実行させる。この結合命令は、SQL(Structured Query Language)におけるセレクトコマンド(SELECT)である。セレクトコマンドは、第１のテーブルおよび第２のテーブルの各々から、予め指定された関係にある複数のレコードを選択して結合することにより結果テーブルを生成するコマンドである。

変換制御部３５０は、本発明に係るアクセス制御部の一例である。変換制御部３５０は、取得させたその結果テーブルを複数のアクセス命令によってアクセス可能な構造に変換する変換命令を、それら複数のアクセス命令よりも先に実行させる。変換命令によれば、複数のアクセス命令によってアクセスされるレコードを結果テーブルから抽出して当該複数のアクセス命令によってアクセス可能な構造に変換することができる。具体的には、この変換命令は、SQLのセレクトコマンドにより取得された結果テーブルを、EJBのbeanと呼ばれるオブジェクトに変換する命令である。

判断部３６０は、アクセスプログラム２０により利用可能な局所メモリの残量を判断する。局所メモリの残量は、アクセスプログラム２０に基づいて静的に判断されてもよいし、局所メモリの残量を計測する命令を、アクセスプログラム２０の実行中に実行させてもよい。ビュー制御部３７０は、判断部３６０により判断された残量が予め定められた基準よりも多いことを条件に、第１のテーブルおよび第２のテーブルを結合したテーブルを局所メモリに生成するビューコマンドを実行させる。具体的には、ビュー制御部３７０は、そのビューコマンドをアクセスプログラム２０中に生成することにより、アクセスプログラム２０の実行中に実行させる。また、ビューコマンドを実行させることを条件に、ビュー制御部３７０は、ＤＢ４５に代えてこのビューコマンドにより生成されるテーブルを、結合命令によってアクセスさせる。

実行部３８０は、以上に述べた各々の制御を含むアクセスプログラム２０を取得し、そのアクセスプログラム２０を実行する。実行部３８０は、アクセスプログラム２０を実行することによりＤＢ４５に対してアクセスする。このとき、結合命令および変換命令の制御によって、ＤＢ４５中のレコードはバッファメモリ３５に一時的に格納される。また、実行部３８０は、一時的に格納されたこのレコードを、ＤＢ４５に代えてバッファメモリ３５から読み出す。

図５は、アプリケーションサーバシステム３０がアクセスプログラム２０を取得したときに行う処理の流れを示す。取得部３００はアクセスプログラム２０を取得する（Ｓ５００）。検出部３１０は、アクセスプログラム２０中のコールグラフを生成する（Ｓ５１０）。例えば、検出部３１０は、メソッド呼び出しの対象を特定するために、型情報解析によるレシーバ・オブジェクト・タイプ（ｒｅｃｅｉｖｅｒ ｏｂｊｅｃｔ ｔｙｐｅ）のディスアンビギュエーション（ｄｉｓａｍｂｉｇｕａｔｉｏｎ）の技術や、クラス階層解析（ｃｌａｓｓ ｈｉｅｒａｒｃｈｙ ａｎａｌｙｓｉｓ）の技術を用いてもよい。これにより、アクセスプログラム２０中の各命令が実行される順序が判明する。

次に、検出部３１０は、アクセスプログラム２０に含まれる複数のアクセス命令について、それらの間の依存関係を示すＢｅａｎ依存グラフを生成する（Ｓ５２０）。具体的には、検出部３１０は、生成したコールグラフを走査することによって、複数のアクセス命令の依存関係を判断する。例えば、アクセスプログラム２０がJ2EEで記述されている場合において、finderメソッドで使われているアクセスキーの依存関係と、エンティティ・Ｂｅａｎのgetterメソッドやsetterメソッドによるフィールドのアクセス状況とに基づいて、アクセス命令間の依存関係を定めることができる。Ｂｅａｎ依存グラフは、例えば図３（ａ）および図３（ｂ−２）に例示される。

次に、検出部３１０は、ＤＢ４５のスキーマ情報を収集する（Ｓ５３０）。具体的には、検出部３１０は、ＤＢ４５に含まれる各テーブルのプライマリ・キー、外部キー、および、全カラムのデータタイプとサイズの情報を収集する。この処理は、JDBCのDatabaseMetaData APIsにより実現できる。

次に、アプリケーションサーバシステム３０は、複数のテーブルを検出すると共に、それらについて結合命令および計測命令を生成する処理を行う（Ｓ５４０）。次に、変換制御部３５０は、結果テーブルからレコードを抽出して複数のアクセス命令によりアクセス可能な構造に変換する変換命令を生成する（Ｓ５５０）。

図６は、Ｓ５４０における処理の詳細を示す。検出部３１０は、Ｂｅａｎ依存グラフをルートノードからリーフノードに向けて順次選択し、選択した各ノードについて以下の処理を繰り返す（Ｓ６００）。なお、ある２つのテーブルについて結合命令を生成する場合には、検出部３１０は、それら２つのテーブルを示す２つのノードを結合したノードを新たに検索の対象とする。即ち、３以上のテーブルの結合についても再帰的に判断される。以下、処理の詳細を述べる。

まず、検出部３１０は、選択した当該ノードと、当該ノードの子ノードの組を検出する（Ｓ６１０）。即ちこれにより、検出部３１０は、第１のアクセス命令によりアクセスされる第１のテーブルと、当該第１のテーブルから読み出したレコード中の要素をキーとして第２のアクセス命令によりアクセスされる第２のテーブルとを検出することができる。

また、検出部３１０は、選択した当該ノードと、当該ノードと兄弟の関係にある兄弟ノードの組を検出する。即ちこれにより、検出部３１０は、共に同一のキーを有する複数のアクセス命令によりアクセスされる複数のテーブルを検出できる。次に、解析部３２０は、検出された当該複数のテーブルについて、第１のアクセス命令が第１のテーブルをプライマリ・キーによりアクセスするか判断し、第２のアクセス命令が第２のテーブルをプライマリ・キーによりアクセスするかを判断する（Ｓ６２０）。共にプライマリ・キーによりアクセスされることを条件に（Ｓ６２０：ＹＥＳ）、解析部３２０は、命令生成の処理に移る（Ｓ６３０）。

第１のテーブルおよび第２のテーブルの少なくとも一方がプライマリ・キーによりアクセスされないことを条件に（Ｓ６２０：ＮＯ）、解析部３２０は、第１のアクセス命令により読み出されたレコードが、第２のアクセス命令により使用されるか否かを判断する（Ｓ６４０）。即ち例えば、図３（ａ）に示したテーブル「ｃｕｓｔｏｍｅｒ」およびテーブル「ｃｒｅｄｉｔＡｃｃｏｕｎｔ」のような関係であれば、解析部３２０は、第１のアクセス命令により読み出されたレコードが、第２のアクセス命令により使用されると判断する。一方で、図３（ｂ−１）に示したテーブルＡおよびテーブルＢの様な関係であれば、解析部３２０は、第１のアクセス命令により読み出されたレコードが、第２のアクセス命令により使用されないと判断する。

第１のアクセス命令により読み出されたレコードが、第２のアクセス命令により使用されないことを条件に（Ｓ６４０：ＮＯ）、解析部３２０は、Ｓ６５０に処理を移す。一方で、第１のアクセス命令により読み出されたレコードが、第２のアクセス命令により使用されることを条件に（Ｓ６４０：ＹＥＳ）、解析部３２０は、第１のアクセス命令により読み出されたレコードが、第２のアクセス命令のみによって使用され、他の何れの命令にも使用されていないかを判断する（Ｓ６６０）。他の何れの命令にも使用されていないことを条件に（Ｓ６６０：ＹＥＳ）、解析部３２０は、Ｓ６３０に処理を移す。一方で、他の何れかの命令に使用されていることを条件に（Ｓ６６０：ＮＯ）、解析部３２０は、Ｓ６５０に処理を移す。アプリケーションサーバシステム３０は、以上の処理を各Ｂｅａｎについて繰り返す（Ｓ６７０）。

図７は、Ｓ６３０における処理の詳細を示す。解析部３２０は、検出した複数のテーブルに対するアクセス命令の実行確率が１か否かを判断する（Ｓ７００）。即ち、解析部３２０は、アクセスプログラム２０が実行されれば必ずアクセス命令が実行されるか否かを判断する。実行確率が１ならば（Ｓ７００：ＹＥＳ）、結合制御部３４０は、これら複数のテーブルを結合した結果テーブルを取得する結合命令を生成させる（Ｓ７３０）。次に、判断部３６０は、アプリケーションサーバシステム３０により利用可能な局所メモリの残量を判断する（Ｓ７４０）。

そして、ビュー制御部３７０は、判断部３６０により判断された残量が予め定められた基準よりも多いことを条件に、第１のテーブルおよび第２のテーブルを結合したテーブルを局所メモリに生成するビューコマンドを実行させる（Ｓ７６０）。具体的には、ビュー制御部３７０は、そのビューコマンドをアクセスプログラム２０中に生成することにより、アクセスプログラム２０の実行中に実行させてもよい。また、この場合、結合制御部３４０は、このビューコマンドにより生成されたテーブルから結果テーブルを生成するセレクトコマンドを、結合命令として実行させる。これにより、ＤＢ４５に対するアクセス回数を一層低減することができる。

一方で、検出した複数のテーブルに対するアクセス命令の実行確率が１未満であることを条件に（Ｓ７００：ＮＯ）、計測制御部３３０は、そのアクセス命令が実行される確率を計測する計測命令を生成する（Ｓ７１０）。そして、結合制御部３４０は、その確率に応じて実行させる複数の命令列を生成する（Ｓ７２０）。これら複数の命令列の各々は、複数のテーブルを結合の対象とする結合命令を含み、結合の対象とするテーブルの組み合わせは命令列によって異なっている。

図８は、Ｓ６５０における処理の詳細を示す。計測制御部３３０は、冗長度を計測する計測命令を、アクセスプログラム２０の実行中に実行させる（Ｓ８００）。例えば、計測制御部３３０は、アクセスプログラム２０中に計測命令を生成してもよい。計測命令は、結合命令を生成した場合において結合命令によって読み出されるレコードのうち冗長なレコードの占める割合である冗長度を計測する命令である。冗長度は以下の式によって計算される。
冗長度＝AR(A) * (N-1) / ( (AR(A) + AR(B) ) * N)

ここで、Ｎは、結合命令によって結合される一方のテーブル（Ａとする）における１つのレコードに対応する、他方のテーブル（Ｂとする）のレコードの数を示す。Ｎは、cardinalityと呼ばれる。また、ＡＲ（Ａ）は、Ａのレコード長を示し、ＡＲ（Ｂ）は、Ｂのレコード長を示す。即ち、cardinalityが大きければ冗長度は大きく、また、cardinalityが大きくてもテーブルＡのレコード長が短ければ冗長度は低い。計測命令は、アクセスの対象となるレコードの組を動的に検出して、それらのレコードのレコード長をスキーマ情報に基づいて求め、アクセス対象テーブル間のcardinalityの実行時プロファイルから冗長度を算出する。

なお、計測制御部３３０は、オフラインプロファイルによって予め冗長度が計測されていることを条件に、冗長度の計測命令を生成しなくてもよい。この場合、結合制御部３４０は、予め計測された当該冗長度に基づいて命令列を生成してもよい。

解析部３２０は、検出した複数のテーブルに対するアクセス命令の実行確率が１か否かを判断する（Ｓ８１０）。即ち、解析部３２０は、アクセスプログラム２０が実行されれば必ずアクセス命令が実行されるか否かを判断する。実行確率が１であることを条件に（Ｓ８１０：ＹＥＳ）、結合制御部３４０は、結合命令を含む命令列と、結合命令を含まずに複数のアクセス命令が複数のテーブルをそれぞれアクセスする命令列との双方を生成する（Ｓ８２０）。これらの命令列は、計測命令により計測された冗長度に基づいて切り替えて実行される。

実行確率が１未満であることを条件に（Ｓ８１０：ＮＯ）、計測制御部３３０は、そのアクセス命令が実行される確率を計測する計測命令を生成する（Ｓ８３０）。そして、結合制御部３４０は、その確率に応じて実行させる複数の命令列を生成する（Ｓ８４０）。これら複数の命令列の各々は、複数のテーブルを結合の対象とする結合命令を含み、結合の対象とするテーブルの組み合わせは命令列によって異なっている。

図９は、結合命令、および、変換命令による処理の概念図を示す。本図の例において、結合命令は、Ｃｕｓｔｏｍｅｒテーブル、および、ｃｒｅｄｉｔＡｃｃｏｕｎｔテーブルを結合した結果テーブルをＤＢ４５から取得する命令である。具体的には、結合命令は、ＳＱＬのセレクトコマンド（ＳＥＬＥＣＴ）である。生成されるセレクトコマンドの一例を以下に示す。

select a.*, b.* from Customer_TABLE a, creditAccount_TABLE b where a.accessKey = ? and join_condition

ここで、join_conditionの部分には、a, bがアクセスキーを共有する関係のときは、アクセスキー同士の等値式を並べる。例えば、a.accessKey1a = b.accessKey1b and …のようになる。一方、a, bがアクセスキーに関して依存関係の場合は、join_conditionの部分は、カラムの一致を判断する条件となる。例えば、a.column1 = b.accessKey1 and a.column2 = b.accessKey2 and ….のようになる。この例では、テーブルaのcolumn1のデータをキーとしてテーブルbをアクセスする場合において、テーブルaおよびテーブルbから一度のクエリでレコードを取得できる。

この結合命令によれば、Ｃｕｓｔｏｍｅｒテーブルの各レコード、および、ｃｒｅｄｉｔＡｃｃｏｕｎｔテーブルの各レコードを結合したレコードを有する結果テーブルが生成される。ここで、Ｃｕｓｔｏｍｅｒテーブルは、プライマリ・キーとしてcustomerKeyを有する。しかし結合条件としたa.column1 = b.accessKey1で、accessKey1はｃｒｅｄｉｔＡｃｃｏｕｎｔテーブルのプライマリ・キーとは限らない。このため、Customerテーブルのレコードは結果テーブルに重複して出現する。

変換命令における重複を排除するべく、結合制御部３４０は、結果テーブルのうちプライマリ・キーが同一の複数のレコードを検出することを条件に、当該複数のレコードの何れか１つのレコードを抽出する。本図の例では、Ｃｕｓｔｏｍｅｒテーブルから取得された各レコードは同一のプライマリ・キーを有する。このため、結合制御部３４０は、これらのレコードから１つのレコードを抽出してＢｅａｎに変換する。一方で、ｃｒｅｄｉｔＡｃｃｏｕｎｔテーブルから取得された各レコードは互いに異なるプライマリ・キーを有する。このため、結合制御部３４０は、これらのレコードの各々をＢｅａｎに変換する。

図１０は、Ｓ７２０およびＳ８４０において生成される結合命令、および、それを実行する実行時処理の概要を示す。この処理段階において、結合制御部３４０は、Ｂｅａｎ依存グラフで親子関係または兄弟関係にある複数のテーブルについては、それらを結合する結合命令を実行した場合における冗長度に基づいて、その結合命令を実行させる。即ち例えば、冗長度が予め定められた基準以下であることを条件に、結合制御部３４０は、結合命令を実行させる。

更に、結合制御部３４０は、処理対象のノードに対応するアクセス命令がある特定の命令列中に検出されたことを条件に、複数の命令列を生成する。この場合、実行部３８０は、実行時の判断に基づいて何れかの命令列を実行する。以下、この処理の概要を述べる。特定の命令列の一例を図１０（ａ）に示す。図１０（ａ）は、アクセス命令を含むプログラムの制御フローを示す。即ちこのプログラムは、ｃｕｓｔｏｍｅｒテーブルに対するアクセス命令を実行後、ｃｒｅｄｉｔＡｃｃｏｕｎｔテーブルに対するアクセス命令、および、ｄｅｂｉｔＡｃｃｏｕｎｔテーブルに対するアクセス命令の何れかを実行する。

更に、アクセス命令がこのような特定の命令列中に検出されたことを条件に、結合制御部３４０は、３つのアクセス命令によってアクセスされる３つのテーブルを結合する結合命令を実行させてもよい。具体的には、まず、検出部３１０は、第１のアクセス命令によりアクセスされる第１のテーブルと、第１のテーブルから読み出したレコード中の要素をキーとして第２のアクセス命令によりアクセスされる第２のテーブルと、当該レコード中の要素をキーとして第３のアクセス命令によりアクセスされる第３のテーブルとを検出する。図１０（ａ）に具体例を示す。検出部３１０は、第１のテーブルであるテーブル「ｃｕｓｔｏｍｅｒ」と、第２のテーブルであるテーブル「ｃｒｅｄｉｔＡｃｃｏｕｎｔ」と、第３のテーブルであるテーブル「ｄｅｂｉｔＡｃｃｏｕｎｔ」とを検出する。

図１０（ｂ）に示すように、結合制御部３４０は、冗長度が予め定められた基準未満であることを条件に、結合命令を実行させる。更に詳細には、結合制御部３４０は、実行確率に基づいて、テーブル「ｃｕｓｔｏｍｅｒ」を、テーブル「ｃｒｅｄｉｔＡｃｃｏｕｎｔ」およびテーブル「ｄｅｂｉｔＡｃｃｏｕｎｔ」の一方と結合する第１結合命令、並びに、テーブル「ｃｕｓｔｏｍｅｒ」を、テーブル「ｃｒｅｄｉｔＡｃｃｏｕｎｔ」およびテーブル「ｄｅｂｉｔＡｃｃｏｕｎｔ」の双方と結合する第２結合命令の何れかを実行させる。

図１１は、Ｓ７２０およびＳ８４０において生成されるコマンドの処理例を示す（２図のうち１図目）。図１２は、Ｓ７２０およびＳ８４０において生成されるコマンドの処理例を示す（２図のうち２図目）。図１１（ａ）は、計測された冗長度が基準以上であることを条件に実行されるコマンドの処理内容を示す。結合制御部３４０は、内側ループの開始前に、テーブル「ｃｕｓｔｏｍｅｒ」から予めレコードを取得させる。しかしながら、結合制御部３４０は、テーブル「ｃｕｓｔｏｍｅｒ」を何れか他のテーブルと結合させる結合命令は実行させない。

図１１（ｂ）および図１２（ａ）は、計測された冗長度が基準未満であって、複数のアクセス命令の実行確率が偏っていることを条件に実行される結合命令の内容を示す。例えば、結合制御部３４０は、テーブルｃｒｅｄｉｔＡｃｃｏｕｎｔをアクセスするアクセス命令の実行確率（以下、実行確率Ｐ）、および、テーブルｄｅｂｉｔＡｃｃｏｕｎｔをアクセスするアクセス命令の実行確率（以下、実行確率（１−Ｐ））の差分値が、予め定められた基準値よりも大きいことを条件に、実行確率が偏っていると判断してもよい。

実行確率が偏っており、かつ、実行確率Ｐが実行確率（１−Ｐ）よりも大きいことを条件に、結合制御部３４０は、テーブル「ｃｕｓｔｏｍｅｒ」、および、テーブル「ｃｒｅｄｉｔＡｃｃｏｕｎｔ」を結合した結果テーブルを取得する結合命令を実行させる。また、実行確率が偏っており、かつ、実行確率（１−Ｐ）が実行確率Ｐよりも大きいことを条件に、結合制御部３４０は、テーブル「ｃｕｓｔｏｍｅｒ」、および、テーブル「ｄｅｂｉｔＡｃｃｏｕｎｔ」を結合した結果テーブルを取得する結合命令を実行させる。

図１２（ｂ）は、計測された冗長度が基準未満であって、複数のアクセス命令の実行確率が略等しいことを条件に実行される結合命令の内容を示す。例えば、結合制御部３４０は、実行確率Ｐおよび実行確率（１−Ｐ）の差分値が、予め定められた基準値以下であることを条件に、実行確率が略等しいと判断してもよい。実行確率が略等しいと判断したことを条件に、結合制御部３４０は、テーブル「ｃｕｓｔｏｍｅｒ」、テーブル「ｃｒｅｄｉｔＡｃｃｏｕｎｔ」、および、テーブル「ｄｅｂｉｔＡｃｃｏｕｎｔ」を結合した結果テーブルを取得する結合命令を実行させる。

図１３は、アプリケーションサーバシステム３０がアクセスプログラム２０に対してコマンドを生成した結果得られるプログラムの例を示す。ビュー制御部３７０はアクセスプログラム２０の第４行目にビューコマンドを生成し、判断部３６０により判断された局所メモリの残量が予め定められた基準よりも多いことを条件に、このコマンドを実行させる。即ち、この条件を満たす場合には、実行部３８０は、第６行目から開始するバッチ処理に先立って、複数のテーブルを結合したテーブルを局所メモリに生成する。

また、結合制御部３４０は、アクセスプログラム２０の９行目に結合命令を生成する。即ち、実行部３８０は、第１１行目から開始する内側ループに先立って、複数のテーブルを結合した結果テーブルをＤＢ４５から取得する。また、ビューコマンドが生成されたことを条件に、実行部３８０は、ＤＢ４５に代えて、ビューコマンドにより生成されたテーブルから結果テーブルを生成する。

また、変換制御部３５０は、同じ９行目に変換命令を生成する。即ち、実行部３８０は、結果テーブルの生成後に、その結果テーブルから、複数のアクセス命令によってアクセスされるレコードを抽出する。そして、実行部３８０は、抽出したそれらのレコードを複数のアクセス命令によってアクセス可能な構造に変換する。

また、計測制御部３３０は、アクセスプログラム２０の２２行目に計測命令を生成する。即ち、実行部３８０は、第２２行目が実行される毎に、予め設定されたカウンタの値を１つ増加させる。これによって、ｃｒｅｄｉｔＡｃｃｏｕｎｔテーブルに対するアクセス命令が実行される回数を計測し、計測されたその回数に基づいて実行確率を求めることができる。また、実行部３８０は、ｃｕｓｔｏｍｅｒテーブルに対してアクセスした結果と、ｃｒｅｄｉｔＡｃｃｏｕｎｔテーブルに対してアクセスした結果に基づいて、結合命令を生成した場合においてレコードが冗長に読み出される程度を示す冗長度を計測する。この冗長度によって、ｃｕｓｔｏｍｅｒテーブルおよびｃｒｅｄｉｔＡｃｃｏｕｎｔテーブルに対して生成された結合命令を実行させるべきか否かを、動的に判断することができる。

同様に、計測制御部３３０は、アクセスプログラム２０の２７行目に計測命令を生成する。即ち、実行部３８０は、第２７行目が実行される毎に、予め設定されたカウンタの値を１つ増加させる。これによって、ｄｅｂｉｔＡｃｃｏｕｎｔテーブルに対するアクセス命令が実行される回数を計測し、計測されたその回数に基づいて実行確率を求めることができる。また、実行部３８０は、ｃｕｓｔｏｍｅｒテーブルに対してアクセスした結果と、ｄｅｂｉｔＡｃｃｏｕｎｔテーブルに対してアクセスした結果に基づいて、結合命令を生成した場合においてレコードが冗長に読み出される程度を示す冗長度を計測する。この冗長度によって、ｃｕｓｔｏｍｅｒテーブルおよびｄｅｂｉｔＡｃｃｏｕｎｔテーブルに対して生成された結合命令を実行させるべきか否かを、動的に判断することができる。

図１４は、図１３に示すプログラムのバッチ処理の流れを示す。実行部３８０は、第１１行目の処理として、実行中のトランザクションがチェックポイントに到達したか否かを判断する。チェックポイントに到達していないことを条件に（Ｓ１４００：ＮＯ）、実行部３８０は、内側ループの繰り返しの１回分を実行する（Ｓ１４１０）。また、実行部３８０は、計測命令を実行する（Ｓ１４２０）。

一方、チェックポイントに到達したことを条件に（Ｓ１４００：ＹＥＳ）、実行部３８０は、内側ループを終了して第３５行目に処理を移し、トランザクションをコミットする（Ｓ１４３０）。そして、実行部３８０は、９行目に処理を戻し、計測命令により計測された実行確率および冗長度の計測結果を取得する（Ｓ１４４０）。冗長度が予め定められた基準以上であることを条件に（Ｓ１４５０：ＹＥＳ）、実行部３８０は、結合命令を実行しない（Ｓ１４６０）。

冗長度が予め定められた基準未満であることを条件に（Ｓ１４５０：ＮＯ）、実行部３８０は、実行確率に基づいて結合命令を実行する（Ｓ１４７０）。この結合命令は、ｃｒｅｄｉｔＡｃｃｏｕｎｔテーブルに対するアクセス命令およびｄｅｂｉｔＡｃｃｏｕｎｔテーブルに対するアクセス命令の実行比率によって異なる。即ち例えば、実行部３８０は、ｃｒｅｄｉｔＡｃｃｏｕｎｔテーブルおよびｄｅｂｉｔＡｃｃｏｕｎｔテーブルに対するアクセスの確率が略等しいことを条件に、ｃｕｓｔｏｍｅｒテーブル、ｃｒｅｄｉｔＡｃｃｏｕｎｔテーブル、および、ｄｅｂｉｔＡｃｃｏｕｎｔテーブルを結合する結合命令を実行する。

次に、実行部３８０は、アクセス命令によってアクセスされるレコードを結果テーブルから抽出してそのアクセス命令によってアクセス可能な構造に変換する（Ｓ１４７５）。続いて、実行部３８０は、次の内側ループの処理のために実行確率を再計測するべく、実行確率を計測するためのカウンタをリセットする（Ｓ１４８０）。

図１５は、本実施例における処理の全体概要を示す。実行部３８０は、バッチ処理の開始に先立ってビューコマンドを実行する（Ｓ１５００）。これによって、ｃｕｓｔｏｍｅｒテーブル、ｃｒｅｄｉｔＡｃｃｏｕｎｔテーブル、および、ｄｅｂｉｔＡｃｃｏｕｎｔテーブルがＤＢ管理サーバ４０から読み出されて、これらのテーブルを結合したテーブルが生成される。

次に、実行部３８０は、バッチ処理のトランザクションを開始する（Ｓ１５１０）。実行部３８０は、結合命令を実行することによって結果テーブルを生成する（Ｓ１５２０）。そして、実行部３８０は、生成したその結果テーブルを、アクセス命令によってアクセス可能な構造に変換してバッファメモリ３５に記録する。結果テーブルは、例えば、J2EEのＢｅａｎと呼ばれるオブジェクトに変換されてもよい。次に、実行部３８０は、内側ループを１回ずつ実行する（Ｓ１５３０）。そして、実行部３８０は、トランザクションをコミットする（Ｓ１５４０）。

続いて、本実施例のアプリケーションサーバシステム３０によってデータベースをアクセスする実験について、その実験環境および実験結果を述べる。
図１６は、実験に用いたプログラムにおいて参照されるテーブル間の依存関係を示す。即ちこの実験において、アプリケーションサーバシステム３０は、本図に示す構造のＤＢに対するアクセスを制御する。実験には、TPC-Cというベンチマークプログラムを用いた。TPC-Cは、オンライントランザクションの性能を評価するためのベンチマークプログラムである。本実施例の実験においては、TPC-Cにおける顧客のリクエストを無作為に生成してファイルに書き出し、そのファイルを入力としてトランザクションをバッチ処理させる。

本実験では、TPC-Cのシナリオのうち２つ（OrderStatusおよびNewOrder）を用いる。OrderStatusにおいて、アプリケーションサーバシステム３０は、３つのテーブル(Customer、Order、OrderLine)に対して読出専用のアクセスを行う。一方、NewOrderにおいて、アプリケーションサーバシステム３０は、３つのテーブル(Warehouse、Customer、Item)に対して読出専用のアセスを行う。更に、このシナリオにおいて、アプリケーションサーバシステム３０は、他の２つのテーブル(District, Stock)を読出し、かつ、更新する。また、アプリケーションサーバシステム３０は、更に他の３つのテーブルに対して挿入操作を行う。

本図において、各々の囲みはテーブルを示し、囲みの中の文字はテーブル名を示し、囲みの中の数値はレコードの数を示す。即ち、ＤＢ４５において、テーブルWarehouseは、１つのレコードを有する。テーブルDistrict、テーブルCustomer、テーブルOrder、テーブルOrderLine、テーブルStock、およびテーブルItemは、それぞれ、１０個、３０，０００個、３０，０００個、３００，０００個、１００，０００個、および、１００，０００個のレコードを有する。

また、囲みを連結するエッジは、各レコードのマッピングを示す。即ち例えば、テーブルWarehouseの中の１個のレコードは、テーブルDistrictの中の１０個のレコードに対応する。また、テーブルDistrictの中の１個のレコードは、テーブルCustomerの中の３，０００個のレコードに対応する。

図１７は、実験に用いたアクセスプログラムのＢｅａｎ依存グラフを示す。（ａ）は、シナリオOrderStatusにおいてアクセスされるＢｅａｎの間の依存関係を示す。テーブルCustomerは、入力データから得られるcustomerIDをキーとしてアクセスされる。その過程で、Customer beanが生成される。テーブルOrderは、入力データから得られるcustomerIDをキーとしてアクセスされる。その過程でOrder beanが生成される。また、テーブルOrderLineは、Order beanから得られるorderIDによってアクセスされる。その過程で、OrderLine beanが生成される。

（ｂ）は、シナリオNewOrderにおいてアクセスされるＢｅａｎの間の依存関係を示す。テーブルwarehouseは、入力データから得られるwarehouseIDをキーとしてアクセスされる。その過程で、Warehouse beanが生成される。テーブルDistrictは、入力データから得られるdistrictIDをキーとしてアクセスされる。その過程で、District beanが生成される。

テーブルCustomerは、入力データから得られるcustomerIDをキーとしてアクセスされる。その過程で、Customer beanが生成される。テーブルItemは、入力データから得られるitemIDをキーとしてアクセスされる。その過程でItem beanが生成される。また、テーブルStockは、入力データから得られるitemIDによってアクセスされる。その過程で、Stock beanが生成される。

図１８は、実験で使われた各テーブルの特徴を示す。ＤＢのスキーマ情報によって、各テーブルのプライマリ・キー、および、各テーブルのアクセスレコードの長さが求められる。即ち、テーブルWarehouseのプライマリ・キーはwarehouseIDであり、アクセスレコードの長さは６である。また、テーブルDistrictのプライマリ・キーはdistrictIDであり、アクセスレコードの長さは１０である。

以上の環境の下、アプリケーションサーバシステム３０は、シナリオOrderStatusおよびシナリオNewOrderを実行する。その結果の概要を述べる。
１）OrderStatusについて
テーブルCustomerおよびテーブルOrderは、共に、同一のプライマリ・キーcustomerIDによってアクセスされる。このため、図６のＳ６２０における判断はＹＥＳとなり、図７に示すＳ６３０が処理される。このアクセス命令の実行確率は１なので、結合命令が生成される（Ｓ７３０）。

また、Order beanは、テーブルOrderLineへのアクセスキー以外にもフィールドアクセスを有している。このため、図６のＳ６６０における判断はＮＯとなり、図８のＳ６５０が処理される。即ち、冗長度の計測命令が生成され（Ｓ８００）、また、結合をする場合としない場合とで複数の命令列が生成される（Ｓ８４０）。

結果として、アプリケーションサーバシステム３０は、テーブルCustomerおよびテーブルOrderの２つを結合する結合命令を含む命令列と、テーブルCustomer、テーブルOrder、および、テーブルOrderLineの３つを結合する結合命令を生成した命令列とを生成する。そして、計測される冗長度に基づいてこれら２つの何れかの命令列が動的に選択されて（Ｓ１４５０）、実行される。

２）NewOrderについて
全てのテーブルは、入力データをキーとしてアクセスされる。従って、これらのテーブルへのアクセスの間には依存関係が存在しない。また、Item beanおよびstock beanを除き、テーブル間のマッピングは不明である。従って、これらのテーブルの全ての組み合わせについて冗長度の計測命令が生成される。また、これらのテーブルの全ての組み合わせ（２つの組み合わせ、３つの組み合わせ、４つの組み合わせ全て）の各々について、その組み合わせのテーブルを結合する結合命令を含む複数の命令列が生成される。

冗長度が計測された結果として、結合命令の対象となるテーブル群がグループ化される。 具体的には、(warehouse, district)の２つのテーブルは、マッピングの比率が１：１０なので、これらに対して結合命令を生成すると、計測される冗長度は極めて大きくなる。また、一方、(warehouse, district)のテーブルはアクセスレコード長が小さいため、テーブルcustomerと結合した場合でも冗長度が低いことがわかる。従って、生成された複数の命令列のうち、実行されるのは (warehouse, district, customer)のテーブルを結合する結合命令と、(item, stock)のテーブルを結合する結合命令となる。
結合命令を生成した結果、シナリオOrderStatusでは24.5%の性能向上が、シナリオNewOrderでは6.1%の性能向上が確かめられた。

図１９は、アプリケーションサーバシステム３０として機能する情報処理装置５００のハードウェア構成の一例を示す。情報処理装置５００は、ホストコントローラ１０８２により相互に接続されるＣＰＵ１０００、ＲＡＭ１０２０、及びグラフィックコントローラ１０７５を有するＣＰＵ周辺部と、入出力コントローラ１０８４によりホストコントローラ１０８２に接続される通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を有する入出力部と、入出力コントローラ１０８４に接続されるＢＩＯＳ１０１０、フレキシブルディスクドライブ１０５０、及び入出力チップ１０７０を有するレガシー入出力部とを備える。

ホストコントローラ１０８２は、ＲＡＭ１０２０と、高い転送レートでＲＡＭ１０２０をアクセスするＣＰＵ１０００及びグラフィックコントローラ１０７５とを接続する。ＣＰＵ１０００は、ＢＩＯＳ１０１０及びＲＡＭ１０２０に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ１０７５は、ＣＰＵ１０００等がＲＡＭ１０２０内に設けたフレームバッファ上に生成する画像データを取得し、表示装置１０８０上に表示させる。これに代えて、グラフィックコントローラ１０７５は、ＣＰＵ１０００等が生成する画像データを格納するフレームバッファを、内部に含んでもよい。

入出力コントローラ１０８４は、ホストコントローラ１０８２と、比較的高速な入出力装置である通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を接続する。通信インターフェイス１０３０は、ネットワークを介して外部の装置と通信する。ハードディスクドライブ１０４０は、情報処理装置５００が使用するプログラム及びデータを格納する。ＣＤ−ＲＯＭドライブ１０６０は、ＣＤ−ＲＯＭ１０９５からプログラム又はデータを読み取り、ＲＡＭ１０２０又はハードディスクドライブ１０４０に提供する。

また、入出力コントローラ１０８４には、ＢＩＯＳ１０１０と、フレキシブルディスクドライブ１０５０や入出力チップ１０７０等の比較的低速な入出力装置とが接続される。ＢＩＯＳ１０１０は、情報処理装置５００の起動時にＣＰＵ１０００が実行するブートプログラムや、情報処理装置５００のハードウェアに依存するプログラム等を格納する。フレキシブルディスクドライブ１０５０は、フレキシブルディスク１０９０からプログラム又はデータを読み取り、入出力チップ１０７０を介してＲＡＭ１０２０またはハードディスクドライブ１０４０に提供する。入出力チップ１０７０は、フレキシブルディスク１０９０や、例えばパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各種の入出力装置を接続する。

情報処理装置５００に提供されるプログラムは、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５、又はＩＣカード等の記録媒体に格納されて利用者によって提供される。プログラムは、入出力チップ１０７０及び/又は入出力コントローラ１０８４を介して、記録媒体から読み出され情報処理装置５００にインストールされて実行される。プログラムが情報処理装置５００等に働きかけて行わせる動作は、図１から図１８において説明したアプリケーションサーバシステム３０における動作と同一であるから、説明を省略する。

以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５の他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムを情報処理装置５００に提供してもよい。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

図１は、情報処理システム１０の全体構成を示す。 図２は、アクセスプログラム２０の一例を示す。 図３は、相互に所定の関係を有する複数のテーブルの例を示す。 図４は、アプリケーションサーバシステム３０の機能構成を示す。 図５は、アプリケーションサーバシステム３０がアクセスプログラム２０を取得したときに行う処理の流れを示す。 図６は、Ｓ５４０における処理の詳細を示す。 図７は、Ｓ６３０における処理の詳細を示す。 図８は、Ｓ６５０における処理の詳細を示す。 図９は、結合命令、および、変換命令による処理の概念図を示す。 図１０は、Ｓ７２０およびＳ８４０において生成される結合命令、および、それを実行する実行時処理の概要を示す。 図１１は、Ｓ７２０およびＳ８４０において生成されるコマンドの処理例を示す（２図のうち１図目）。 図１２は、Ｓ７２０およびＳ８４０において生成されるコマンドの処理例を示す（２図のうち２図目）。 図１３は、アプリケーションサーバシステム３０がアクセスプログラム２０に対してコマンドを生成した結果得られるプログラムの例を示す。 図１４は、図１３に示すプログラムのバッチ処理の流れを示す。 図１５は、本実施例における処理の全体概要を示す。 図１６は、実験に用いたＤＢの構造を示す。 図１７は、実験に用いたアクセスプログラムのＢｅａｎ依存グラフを示す。 図１８は、実験で使われた各テーブルの特徴を示す。 図１９は、アプリケーションサーバシステム３０として機能する情報処理装置５００のハードウェア構成の一例を示す。

符号の説明

１０ 情報処理システム
２０ アクセスプログラム
３０ アプリケーションサーバシステム
３５ バッファメモリ
４０ ＤＢ管理サーバ
４５ ＤＢ
３００ 取得部
３１０ 検出部
３２０ 解析部
３３０ 計測制御部
３４０ 結合制御部
３５０ 変換制御部
３６０ 判断部
３７０ ビュー制御部
３８０ 実行部
５００ 情報処理装置

Claims (20)

1. データベースに対するアクセスを制御するシステムであって、
   データベースに対するアクセス命令を複数含むアクセスプログラムを取得する取得部と、
   前記データベースのうち、前記複数のアクセス命令によってアクセスされる互いに異なる複数のテーブルを検出する検出部と、
   検出された前記複数のテーブルを結合した結果テーブルを前記データベースから取得する結合命令を、当該複数のアクセス命令に先立って実行させる結合制御部と、
   前記複数のアクセス命令の各々に、前記結果テーブルをアクセスさせる制御を行うアクセス制御部と
   を備えるシステム。
2. 前記アクセス制御部は、前記複数のアクセス命令によってアクセスされるレコードを前記結果テーブルから抽出して前記複数のアクセス命令によってアクセス可能な構造に変換する変換命令を、前記複数のアクセス命令よりも先に実行させる
   請求項１に記載のシステム。
3. 前記検出部は、共に同一のキーを有する複数のアクセス命令によりアクセスされる複数のテーブルを検出し、
   前記結合制御部は、当該キーの値が同一のレコードを当該複数のテーブルの各々から読み出して単一のレコードに結合する命令を、前記結合命令として実行させる
   請求項１に記載のシステム。
4. 前記検出部は、第１のアクセス命令によりアクセスされる第１のテーブルと、前記第１のテーブルから読み出したレコード中の要素をキーとして第２のアクセス命令によりアクセスされる第２のテーブルとを検出し、
   前記結合制御部は、前記第１のテーブル中のレコードと、当該レコード中の要素をキーとして読み出される第２のテーブル中のレコードとを単一のレコードに結合する命令を、前記結合命令として実行させる
   請求項１に記載のシステム。
5. 前記結合制御部は、第１のテーブルおよび第２のテーブルの各々から、予め指定された関係にある複数のレコードを選択して結合することにより前記結果テーブルを生成するセレクトコマンドを、前記結合命令として実行させる
   請求項１に記載のシステム。
6. 前記アクセスプログラムにより利用可能なメモリの残量を判断する判断部と、
   前記判断部により判断された残量が予め定められた基準よりも多いことを条件に、前記第１のテーブルおよび前記第２のテーブルを結合したテーブルを前記メモリに生成するビューコマンドを実行させるビュー制御部と
   を更に備え、
   前記結合制御部は、前記ビューコマンドにより生成されたテーブルから前記結果テーブルを生成するセレクトコマンドを、前記結合命令として実行させる
   請求項５に記載のシステム。
7. 前記アクセス制御部は、前記結果テーブルのうちプライマリ・キーが同一の複数のレコードを検出することを条件に、当該複数のレコードの何れか１つのレコードを抽出する
   請求項１に記載のシステム。
8. 前記アクセスプログラムを解析することにより、アクセス命令毎に、アクセスプログラムが実行されれば必ず当該アクセス命令が実行されるか否かを判断する解析部と、
   必ずしも実行されないと判断されたアクセス命令について、当該アクセス命令が実行される確率を計測する計測命令を、前記アクセスプログラムの実行中に実行させる計測制御部と
   を更に備える請求項１に記載のシステム。
9. 前記検出部は、第１のアクセス命令によりアクセスされる第１のテーブルと、前記第１のテーブルから読み出したレコード中の要素をキーとして第２のアクセス命令によりアクセスされる第２のテーブルと、当該レコード中の要素をキーとして第３のアクセス命令によりアクセスされる第３のテーブルとを検出し、
   前記結合制御部は、前記アクセスプログラムの実行中に前記計測命令によって計測された確率に基づいて、前記第１のテーブルを、前記第２のテーブルおよび前記第３のテーブルの一方と結合する第１結合命令、並びに、前記第１のテーブルを、前記第２のテーブルおよび前記第３のテーブルの双方と結合する第２結合命令の何れかを実行させる
   請求項８に記載のシステム。
10. 前記検出部により検出された複数のテーブルについて、第１のアクセス命令が第１のテーブルを前記プライマリ・キーによりアクセスし、かつ、第２のアクセス命令が第２のテーブルをプライマリ・キーによりアクセスするか否かを判断する解析部を更に備え、
    前記結合制御部は、前記第１のアクセス命令および前記第２のアクセス命令が同一のプライマリ・キーによりアクセスすることを条件に、前記第１のテーブルおよび前記第２のテーブルを結合する結合命令を実行させる
    請求項１に記載のシステム。
11. 前記第１のテーブルおよび前記第２のテーブルの少なくとも一方がプライマリ・キーによりアクセスされないことを条件に、前記結合命令を生成した場合において前記結合命令によって読み出されるレコードのうち冗長なレコードの占める割合である冗長度を計測する計測命令を、前記アクセスプログラムの実行中に実行させる計測制御部を更に備え、
    前記結合制御部は、前記アクセスプログラムの実行中に前記計測命令によって計測された冗長度が、予め定められた基準よりも小さいことを条件に、前記第１のテーブルおよび前記第２のテーブルを結合する結合命令を実行させる
    請求項１０に記載のシステム。
12. 前記検出部は、第１のアクセス命令によりアクセスされる第１のテーブルと、前記第１のテーブルから読み出したレコード中の要素をキーとして第２のアクセス命令によりアクセスされる第２のテーブルとを検出し、
    前記アクセスプログラムを解析することにより、前記第１のアクセス命令に読み出されたレコードが、前記第２のアクセス命令に使用され、かつ、他の何れの命令にも使用されていないかを判断する解析部を更に備え、
    前記結合制御部は、前記第１のアクセス命令に読み出されたレコードが、前記第２のアクセス命令に使用され、かつ、他の何れの命令にも使用されていないことを条件に、前記第１のテーブルおよび前記第２のテーブルを結合する結合命令を実行させる
    請求項１に記載のシステム。
13. データベースに対するアクセスを制御する方法であって、
    データベースに対するアクセス命令を複数含むアクセスプログラムを取得する取得段階と、
    前記データベースのうち、前記複数のアクセス命令によってアクセスされる互いに異なる複数のテーブルを検出する検出段階と、
    検出された前記複数のテーブルを結合することにより結果テーブルを生成して前記データベースから取得する結合命令を、当該複数のアクセス命令に先立って実行させる結合制御段階と、
    前記複数のアクセス命令の各々に、前記結果テーブルをアクセスさせる制御を行うアクセス制御段階と
    を備える方法。
14. 前記アクセス制御段階において、前記複数のアクセス命令によってアクセスされるレコードを前記結果テーブルから抽出して前記複数のアクセス命令によってアクセス可能な構造に変換する変換命令を、前記複数のアクセス命令よりも先に実行させる
    請求項１３に記載の方法。
15. 前記検出段階において、共に同一のキーを有する複数のアクセス命令によりアクセスされる複数のテーブルを検出し、
    前記結合制御段階において、当該キーの値が同一のレコードを当該複数のテーブルの各々から読み出して単一のレコードに結合する命令を、前記結合命令として実行させる
    請求項１３に記載の方法。
16. 前記検出段階において、第１のアクセス命令によりアクセスされる第１のテーブルと、前記第１のテーブルから読み出したレコード中の要素をキーとして第２のアクセス命令によりアクセスされる第２のテーブルとを検出し、
    前記結合制御段階において、前記第１のテーブル中のレコードと、当該レコード中の要素をキーとして読み出される第２のテーブル中のレコードとを単一のレコードに結合する命令を、前記結合命令として実行させる
    請求項１３に記載の方法。
17. 前記検出段階において検出された複数のテーブルについて、第１のアクセス命令が第１のテーブルを前記プライマリ・キーによりアクセスし、かつ、第２のアクセス命令が第２のテーブルをプライマリ・キーによりアクセスするか否かを判断する解析段階を更に備え、
    前記結合制御段階において、前記第１のアクセス命令および前記第２のアクセス命令が同一のプライマリ・キーによりアクセスすることを条件に、前記第１のテーブルおよび前記第２のテーブルを結合する結合命令を実行させる
    請求項１３に記載の方法。
18. 前記第１のテーブルおよび前記第２のテーブルの少なくとも一方がプライマリ・キーによりアクセスされないことを条件に、前記結合命令を生成した場合において前記結合命令によって読み出されるレコードのうち冗長なレコードの占める割合である冗長度を計測する計測命令を、前記アクセスプログラムの実行中に実行させる計測制御段階を更に備え、
    前記結合制御段階において、前記アクセスプログラムの実行中に前記計測命令によって計測された冗長度が、予め定められた基準よりも小さいことを条件に、前記第１のテーブルおよび前記第２のテーブルを結合する結合命令を実行させる
    請求項１７に記載の方法。
19. 前記検出段階において、第１のアクセス命令によりアクセスされる第１のテーブルと、前記第１のテーブルから読み出したレコード中の要素をキーとして第２のアクセス命令によりアクセスされる第２のテーブルとを検出し、
    前記アクセスプログラムを解析することにより、前記第１のアクセス命令に読み出されたレコードが、前記第２のアクセス命令に使用され、かつ、他の何れの命令にも使用されていないかを判断する解析段階を更に備え、
    前記結合制御段階において、前記第１のアクセス命令に読み出されたレコードが、前記第２のアクセス命令に使用され、かつ、他の何れの命令にも使用されていないことを条件に、前記第１のテーブルおよび前記第２のテーブルを結合する結合命令を実行させる
    請求項１３に記載の方法。
20. データベースに対するアクセスを制御するシステムとして、情報処理装置を機能させるプログラムであって、
    前記情報処理装置を、
    データベースに対するアクセス命令を複数含むアクセスプログラムを取得する取得部と、
    前記データベースのうち、前記複数のアクセス命令によってアクセスされる互いに異なる複数のテーブルを検出する検出部と、
    検出された前記複数のテーブルを結合することにより結果テーブルを生成して前記データベースから取得する結合命令を、当該複数のアクセス命令に先立って実行させる結合制御部と、
    前記複数のアクセス命令の各々に、前記結果テーブルをアクセスさせる制御を行うアクセス制御部と
    して機能させるプログラム。

Images