トランザクションを集約して処理する方法、システム、およびプログラム
【課題】 トランザクションを集約して処理する方法、システム、およびプログラムを提供することである。
【解決手段】上記課題を解決するために第１の態様として、コンピュータの処理により、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約する方法であって、前記コンピュータが前記データベースと接続され、複数クライアントから複数トランザクションを受信するステップと、前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信するステップを有する。
【解決手段】上記課題を解決するために第１の態様として、コンピュータの処理により、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約する方法であって、前記コンピュータが前記データベースと接続され、複数クライアントから複数トランザクションを受信するステップと、前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信するステップを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はトランザクションの処理方法に関し、特に複数の照会クエリを含む集約トランザクションの処理方法、システムに関する。
【背景技術】
【０００２】
通常、データベースにおけるトランザクション処理は、一貫した状態のデータベースを維持するよう設計されている。相互依存のある複数の操作が全て完了するか、全てキャンセルされることを保証している。そのために、ロック、ロールバック、デッドロックの回避の仕組みがある。
【０００３】
ロックとは、特定のデータに対するアクセスや更新を制御することである。特にデータベースへの書き込み処理を行なう際に、データの整合性を保つためにアクセスやデータの読み書きを一時的に制限することである。より具体的には１つの処理がデータＸにアクセス中は他の処理がＸへアクセスできないように排他制御を行う。１つの処理が２つ以上のＳＱＬ文で表される場合にトランザクションを利用する。
【０００４】
トランザクションは一連の処理（複数のＳＱＬからなる照会クエリ）をまとめてコミット（確定）またはロールバック（取り消し）を行うことができる機能で、これを利用すれば１つのＳＱＬ文が失敗した場合、同じ処理の別のＳＱＬ文をすべて取り消すことができる。ロールバックはつまりトランザクションがコミット前に失敗した場合、データベースをトランザクション開始前の状態に戻す処理である。またデッドロックとは、２つのトランザクションの処理中にデータベース内の同じ部分に同時にアクセスすることで、互いの処理の進行を妨げる現象である。例えば、トランザクションＡがデータＸにアクセスし、トランザクションＢがデータＹにアクセスする場合、ＡがＹにアクセスしようとし、ＢがＸにアクセスしようとしたときデッドロックが発生する。この場合どちらのトランザクションも先に進めなくなる。このようなデッドロックを回避するには、両方のトランザクションをキャンセルし、ロールバックする。そして順序を変えて再実行し、デッドロックが再度発生しないようにする。
【０００５】
クライアント数の増加と処理するデータ量の増大に伴い、データベースへのアクセスをより効率化する技術が知られている。特許文献１には、複数のロック制御によって複数のトランザクションの並行的な実行を制御する場合に、連続してなされるロック要求を蓄積し、ロック要求でない要求が出されたとき、この要求を処理する前に、前述の蓄積されたロック要求を一括してデ−タベ−スサ−バヘ送信し、ロック処理することによって送信回数を減少させる技術が開示されている。すなわち複数のトランザクション内でのロック要求をまとめる技術である。
【０００６】
特許文献２には、入力された複数のトランザクションを別々に処理するのではなく、入力された複数のトランザクションが処理を行うデータ項目に対して、そのデータ項目を一度だけ検索し、検索したデータ項目に対して、複数のトランザクションの更新処理を順次メインメモリ内で行い、最後に更新した結果だけをデータベースに一度だけ書き込む手法を開示している。すなわち複数のトランザクションの更新をまとめる技術である。
【０００７】
上記従来の方法は複数のトランザクションを１つにまとめて集約してデータベースに問い合わせる方法を採っていない。その理由は、複数のトランザクション（照会クエリ）に存在するＳＱＬ文を集約する方法が難しいことと、またＳＱＬの集約が可能になったとしても、データベースに集約照会をした時に、照会したデータを更新するトランザクションが１つでも発生した場合、必然的にデッドロックが発生するからである。なお本発明ではトランザクションの分離レベルを「再読み込み可能読み取り」（ＲＥＰＥＡＴＡＢＬＥＲＥＡＤ）とする。この分離レベルではトランザクションにおいて対象となるすべてのテーブルの対象データがトランザクション実行中に変更されないことが保証される。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開１９９３−０１０８４５２
【特許文献２】特開２００９−０２７１６６５
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明が解決しようとする課題は、データベース・クライアントがトランザクション処理をデータベースに要求する際に、一部の照会クエリを、その他のトランザクションの照会クエリと共に、別トランザクション（集約トランザクション）としてデータベースに要求する、集約トランザクションの処理方法、システムを提供することである。
【００１０】
さらに別の課題は、集約トランザクションの処理において、照会クエリを要求した全データベース・クライアントからのコミット要求を受信した時に前記集約トランザクションをコミットする方法、システムを提供することである。
【００１１】
さらに別の課題は、集約トランザクションを処理するにあたり、デッドロックの生じないデータ更新方法、システムを提供することである。
【課題を解決するための手段】
【００１２】
本発明は上記課題を解決するために、コンピュータの処理により、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約する方法であって、前記コンピュータが前記データベースと接続され、複数クライアントから複数トランザクションを受信するステップと、前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信するステップと、を有する。
【００１３】
また、前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信するステップが、前記コンピュータが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信するステップと、である。
【００１４】
また、前記送信するステップが、集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付けるステップと、前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成するステップと、複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成するステップと、前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換するステップと、前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶するステップと、全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信するステップである
【００１５】
さらに、前記方法が、前記データベースから前記集約トランザクションに対する結果を受信するステップとを有する。
【００１６】
さらに、前記方法が、前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信するステップを有する。
【００１７】
また、前記分割して送信するステップが、データベースから送信された結果からクライアントＩＤを判断するステップと、前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換するステップと、前記クライアントＩＤを有するクライアントに照会結果を送信するステップである。
【００１８】
そして、前記方法が、前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新するステップであって、更新するデータが、集約トランザクションとして照会したかを前記コンピュータに問い合わせるステップと、集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求するステップと、前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求するステップを有する。
【００１９】
別の態様として、本発明は、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約するシステムであって、複数クライアントから複数トランザクションを受信する手段と、前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信する手段を有する。
【００２０】
また、前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信する手段が、前記システムが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信する手段である。
【００２１】
また、前記送信する手段が、集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付ける手段と、前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成する手段と、複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成する手段と、前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換する手段と、前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶する手段と、全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信する手段である。
【００２２】
さらに、前記システムが、前記データベースから前記集約トランザクションに対する結果を受信する手段を有する。
【００２３】
さらに、前記システムが、前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信する手段を有する。
【００２４】
また、前記分割して送信する手段が、データベースから送信された結果からクライアントＩＤを判断する手段と、前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換する手段と、前記クライアントＩＤを有するクライアントに照会結果を送信する手段である。
【００２５】
そして、前記システムが、前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新する手段であって、更新するデータが、集約トランザクションとして照会したかを判断する手段と、集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求する手段と、前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求する手段を有する。
【００２６】
また別の態様として、上記何れか１つに記載の方法の各ステップを、コンピュータに実行させるためのプログラムを提供する。
【発明の効果】
【００２７】
本発明により、複数のトランザクションを１つにまとめて集約してデータベースに問い合わせることが可能となる。またデータベースに集約トランザクションを問い合わせた場合に、データを更新するトランザクションが発生てもデッドロックすることなく、パフォーマンスに優れたデータベースアクセスが可能となる。
【図面の簡単な説明】
【００２８】
【図１】本発明の全体のシステム構成を示す。
【図２】トランザクションをまとめてデータベース１３０へ送信する場合の図である。
【図３】集約トランザクションの問題点を示す図である。
【図４】本発明における集約トランザクションの処理例である。
【図５】クライアントとＤＢ Ｐｒｏｘｙ１２０の記憶構成ブロックを示す。
【図６】トランザクション開始時のクライアントの挙動を示す。
【図７】照会ＳＱＬを要求時のクライアントの挙動のフローチャートである。
【図８】更新ＳＱＬを要求時のクライアントの挙動のフローチャートである。
【図９】コミット要求時のクライアントの挙動のフローチャートである。
【図１０】ロールバック要求時のクライアントの挙動のフローチャートである。
【図１１】照会ＳＱＬ要求受信時のＤＢ Ｐｒｏｘｙの挙動のフローチャートである。
【図１２】照会ＳＱＬのバッチ要求時の、ＤＢ Ｐｒｏｘｙの挙動のフローチャートである。
【図１３】トランザクションのコミット要求時のＤＢ Ｐｒｏｘｙの挙動のフローチャートである。
【図１４】本発明における、クライアント、ＤＢ Ｐｒｏｘｙ、データベースの例示的なハードウェア構成である。
【図１５】ＳＱＬ文例である。
【図１６】別の ＳＱＬ文例である。
【図１７】ＳＱＬであるＳＥＬＥＣＴ文の集約のフローチャートを示す。
【図１８】データベース１３０から受信した結果を各クライアント用に分割するフローチャートを示す。
【図１９】データベース１３０から受信した結果の例である。
【図２０】データベース１３０から受信した結果を各クライアント用に分割する例１である。
【図２１】データベース１３０から受信した結果を各クライアント用に分割する例２である。
【図２２】データベース１３０から受信した結果を各クライアント用に分割する例３である。
【発明を実施するための形態】
【００２９】
図１に本発明の全体のシステム構成を示す。ＤＢ Ｐｒｏｘｙ１２０は複数のクライアント１１０からトランザクションを集約してデータベース１３０に送信する。ＤＢ Ｐｒｏｘｙ１２０は複数のクライアントに対して１つ存在する。
【００３０】
データベース１３０は、クライアント１１０、もしくは、ＤＢ Ｐｒｏｘｙ１２０から受信する、複数のＳＱＬを１つのトランザクションとして処理する。
【００３１】
ＤＢ Ｐｒｏｘｙ１２０は、トランザクションの開始をデータベース１３０に通知し、要求するＳＱＬを送信し、その結果を受信し、コミット要求をデータベースに送信することで行う。なお一般的には、ＳＱＬの送信、結果の受信は、複数回行われる。
【００３２】
なお本明細書の実施例において、クライアント１１０がトランザクションを開始する際の処理、照会ＳＱＬを要求する際の処理、更新ＳＱＬを要求する際の処理、コミット・ロールバックを要求する際の処理を詳細に説明する。また、ＤＢＰｒｏｘｙ１２０が、上記のクライアント１１０の処理内で、クライアントから照会ＳＱＬを受信した際の処理、クライアントからコミット要求を受信した際の処理を詳細に説明する。
【００３３】
なお説明の簡素化のため、ＤＢ Ｐｒｏｘｙ１２０、クライアント１１０は、同時に１つのトランザクションしか要求しないものと仮定する。また、クライアント１１０とＤＢＰｒｏｘｙ１２０は、Ｎ対１の関係がついているものとする。
【００３４】
図２に、トランザクションをまとめてデータベース１３０へ送信する場合を図示する。図２ではＤＢＰｒｏｘｙ１２０がクライアント１とクライアント２のトランザクション中の照会クエリをまとめてデータベースに要求することにより、データベースのスループットを向上させる。なお図中においてｒ は読み取り（Ｒｅａｄ）、ｗは書き込み（Ｗｒｉｔｅ）を表し、その添え字の最初はクライアント番号、次の添え字は時系列順序を表している。
【００３５】
図２において、クライアント１およびクライアント２は、トランザクション中の照会クエリを、ＤＢＰｒｏｘｙ１２０に転送する。ＤＢ Ｐｒｏｘｙ１２０は、複数のクライアントから受信した照会クエリを１つのクエリにまとめ、照会トランザクションとしてデータベース１３０に処理要求する。照会クエリは通常ＳＱＬ文であるので、同時系列順序で出されたクライアント１のレコードＡを参照するＳＱＬと、クライアント２のレコードＢを照会するＳＱＬ２つのＳＱＬは、ＤＢＰｒｏｘｙ１２０で１つのＳＱＬに集約されてデータベース１３０に送信されることになる。
【実施例】
【００３６】
図１７に、ＳＱＬであるＳＥＬＥＣＴ文の集約のフローチャートを示す。本発明ではＳＥＬＥＣＴ文の集約に集合演算子であるＵＮＩＯＮＡＬＬを使用する。ＵＮＩＯＮ 集合演算子とは複数の ＳＥＬＥＣＴ 文を１つに組み合わせる演算子である。しかし、複数の問い合わせを１つに結合することから、それぞれの問い合わせの抽出項目のリストは同数、かつ、同じグループのデータ型でなければ結合することができない。この方法により任意のＳＱＬをまとめることが可能になる。
【００３７】
まず１７１０で連結対象となるＳＥＬＥＣＴ文と、クライアントＩＤ （ＩＮＴ型） を対応付ける。例として以下の２つのＳＥＬＣＥＣＴ文を結合対象として説明する。
S1: SELECT C11, C12, C13 FROM T1 WHEREK1=? →クライアントIDを1とする
> C11: INT, C12: DOUBLE, C13: STRING
S2: SELECT C21, C22, C23 FROM T0 WHERE K2=? →クライアントIDを2とする
> C21: DOUBLE, C22:INT, C23: DATE
【００３８】
ステップ１７２０で、全てのＳＥＬＥＣＴ文が返すデータ（カラム）の型を含む、データの型の集合を生成する。この時、同一グループのデータ型について型を増加させす１つにして異なるグループのデータ型は新しく付加する。すなわち型の集合を作成する時は異なる型のみを追加する。
例では、{INT, DOUBLE,STRING, DATE}となる。
【００３９】
ステップ１７３０で、ステップ１７２０で生成した型の集合に順序をつけ、先頭にＩＮＴ型を追加する。
例では、INT, INT, DOUBLE,STRING, DATEの順となる。
【００４０】
ステップ１７４０で、各ＳＥＬＥＣＴ文に対し、ステップ１７３０でつけた順序で結果を返すように書き換える。もし、返す型が存在しない場合は、固定値を返すようにする。また、最初のＩＮＴ型には、クライアントＩＤを固定値として返すようにする。
S1': SELECT 1, C11, C12, C13, NULL FROM T1 WHERE K1=?
S2': SELECT 2, C22, C21, ‘CONST', C23 FROM T2 WHERE K2=?
【００４１】
ステップ１７５０で、元のＳＥＬＥＣＴ文のデータ型（カラム）順序と、書き換えたＳＥＬＥＣＴ文のデータ型（カラム）順序の対応を記憶する。記憶した内容は後ほど結果を分割するために使用する。
【００４２】
S1とS1'の対応:{1→2, 2→3, 3→4} (1→2は、S1の1番目の項目がS1'の2番目の項目に対応することを意味する)
S2とS2'の対応:{1→3, 2→2, 3→5} (1→3は、S2の1番目の項目がS2'の3番目の項目に対応することを意味する)
【００４３】
ステップ１７６０で、書き換えたＳＥＬＥＣＴ文をＵＮＩＯＮ ＡＬＬで連結する。そしてデータベース１３０に照会する。
SELECT 1, C11, C12, C13, NULL FROM T1 WHERE K1=? UNION ALL SELECT 2,C22, C21, ‘CONST', C23 FROM T2 WHERE K2=?
【００４４】
図１８に、データベース１３０から受信した結果を各クライアント用に分割するフローチャートを示す。
【００４５】
図１９に、データベース１３０から受信した結果の例を示す。表は左から、INT, INT, DOUBLE, STRING, DATEの順で構成されたデータが５行存在している。左端のＩＮＴ型データはクライアントＩＤを示している。
【００４６】
図１８のフローチャートに従い、ステップ１８１０で、データベース１３０から受信した結果から一行読み込む。すなわち１行目である、1, 1, 0.001, "AAAA"が読み込まれる。ステップ１８２０で、ステップ１８１０で読み込んだ行の、始めのＩＮＴ型のデータからクライアントＩＤを取得する。この場合は１であるのでクライアント１であることがわかる。
【００４７】
ステップ１８３０で、ステップ１８２０で読み込んだ行を、ステップ１７５０で記憶したデータ型順序の対応から、各クライアントが要求したデータ型の値のみを、要求順に並び替え、そのクライアントＩＤのＳＥＬＥＣＴ文に対する結果とする。
【００４８】
ここでクライアント１において、S1とS1'の対応関係は{1→2, 2→3, 3→4} であるので、１行目のデータは図２０に示すように変換される。この処理を繰り返すことで、クライアント１のデータは図２１に示すように、元の結果から分離され、変換されることになる。
【００４９】
３行目からはクライアント２の結果であるので、S2とS2'の対応関係{1→3, 2→2, 3→5} を参照しながら、図２２に示すように、元の結果から分離され、変換される。
【００５０】
図１８のフローチャートに従い、ステップ１８４０で、受信した結果が存在しない場合は処理を終了する。それ以外は、ステップ１８１０に戻る。
【００５１】
本発明の集約と分割の特徴はまとめると次のようになる。
・ＳＥＬＥＣＴ対象となるデータの型情報のみを利用して、ＵＮＩＯＮ ＡＬＬのデータ型を決定すること
・ＵＮＩＯＮ ＡＬＬのデータ（カラム）名とクライアントの要求したＳＥＬＥＣＴ文のデータ（カラム）名の対応関係から、各クライアント用の結果を分割して生成すること。
・ＳＥＬＥＣＴ文のＩＤが結果に含まれない場合は、空の結果（ＲｅｓｕｌｔＳｅｔ）を生成すること
これにより本発明は、ＤＢ Ｐｒｏｘｙ１２０で、複数の照会ＳＱＬを集約してデータベースに処理要求し、その結果をそれぞれのクライアントに分割して返すことができる。
【００５２】
図２の集約クエリ送信後の問題点を図３で説明する。
１．クライアント１は、トランザクション中の照会クエリ（レコードＡを照会ｒ１１）を、ＤＢ Ｐｒｏｘｙ１２０に転送する。
２．クライアント２は、トランザクション中の照会クエリ（レコードＢを照会ｒ２１）を、ＤＢ Ｐｒｏｘｙ１２０に転送する。
３．ＤＢ Ｐｒｏｘｙ１２０は、クライアント１とクライアント２から受信した照会クエリを１つのクエリにまとめ、集約トランザクション（レコードＡとレコードＢを同時照会ｒ１１＋２１）としてデータベース１３０に処理要求する。
４．ここでクライアント１が、同じトランザクション中の更新クエリを更新トランザクション（レコードＡを更新ｗ１２）として、ＤＢ Ｐｒｏｘｙ１２０経由で照会中の集約トランザクション（照会クエリ）とは別に、データベース１３０に要求する。
【００５３】
しかし、この更新トランザクションは集約トランザクションによりレコードＡがロックされているため、レコードＡのロックが開放されるまで待たねばならないが開放されることがない。
【００５４】
なぜなら、クライアント１の更新トランザクションは、ＤＢ Ｐｒｏｘｙ１２０の照会トランザクションがコミットされないと、コミットできないからである。逆に、クライアント１の更新トランザクションよりコミットの通知を受けなくては、ＤＢＰｒｏｘｙ１２０の照会トランザクションがコミットすることはないからである。すなわち、ＤＢ Ｐｒｏｘｙ１２０に要求した照会クエリで照会したレコードＡを、同じトランザクションで更新する場合、必ずデッドロックが発生することになる。
【００５５】
そこで本発明では図４の方法を採る。以下の手順により、集約トランザクションで照会したレコードを更新する場合でも、デッドロックが発生しない。クライアント１が集約トランザクション経由で照会したデータを更新する際に、
４．まずクライアント１は、更新するレコードＡが、集約トランザクションとして照会したかをＤＢＰｒｏｘｙ１２０に問い合わせる。集約トランザクションとして照会している場合、クライアント１は、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベース１３０に処理要求する。
５．クライアント１は、ＤＢＰｒｏｘｙ１２０にコミット要求を出す。
６．クライアント１はレコードＡの更新クエリを直接トランザクションとして、データベース１３０に処理要求する
【００５６】
図５に、クライアントとＤＢ Ｐｒｏｘｙ１２０の記憶構成ブロックを示す。ここでＤＢ Ｐｒｏｘｙ１２０は説明のため１つのトランザクションのみを実行することを仮定する。
【００５７】
クライアントは、照会済ＳＱＬ記憶部、更新済ＳＱＬ記憶部、モード、トランザクション状態を管理する。照会済ＳＱＬ記憶部は、現在実行中のトランザクション内で照会したＳＱＬの履歴を保持する。更新済ＳＱＬ記憶部は、現在実行中のトランザクション内で更新したＳＱＬの履歴を保持する。
【００５８】
モードは、照会ＳＱＬの送信モードを意味し、Ｐｒｏｘｙ時はＤＢ Ｐｒｏｘｙを優先的に利用する、Ｄｉｒｅｃｔ時は直接利用することを意味する。なお、Ｎｕｌｌ時はモードが決定されていないことを意味する。トランザクション状態は、クライアントが直接要求するトランザクションの状態を意味し、Ａｃｔｉｖｅ時はトランザクションを要求中、Ｉｎａｃｔｉｖｅはトランザクションを要求していないことを意味する。
【００５９】
ＤＢ Ｐｒｏｘｙは、開始待ちクライアント記憶部、開始済クライアント記憶部、コミット済クライアント記憶部、バッチ待ち照会ＳＱＬ記憶部を管理する。
【００６０】
開始待ちクライアント記憶部は、ＤＢ Ｐｒｏｘｙが次のトランザクションでバッチ対象とするＳＱＬを要求したクライアントの識別子のリストを保持する。開始済みクライアント記憶部は、ＤＢＰｒｏｘｙが現在バッチ対象とするＳＱＬを要求したクライアントの識別子のリストを保持する。
【００６１】
コミット済みクライアント記憶部は、開始済みクライアント記憶部のうち、コミット要求を受信したクライアントの識別子のリストを保持する。バッチ待ち照会ＳＱＬ記憶部は、開始済みクライアント記憶部のクライアントがＤＢＰｒｏｘｙに要求し、ＤＢ Ｐｒｏｘｙがまだデータベースに要求していないＳＱＬを保持する。
【００６２】
図６に、トランザクション開始時のクライアントの挙動を示す。
【００６３】
ステップ６０２で、照会ＳＱＬを要求する。ステップ６０４でモードをＮｕｌｌに遷移する。次にステップ６０６で照会済ＳＱＬ記憶部をクリアする。そしてステップ６０８で更新済ＳＱＬ記憶部をクリアし、最後にステップ６１０でトランザクション状態をＩｎａｃｔｉｖｅにする。
【００６４】
図７に、照会ＳＱＬを要求時のクライアントの挙動のフローチャートを示す。
【００６５】
クライアントが照会ＳＱＬを要求する際は、ステップ７０４で、モードがＤｉｒｅｃｔモードか否かを判断する。Ｎｕｌｌモード、もしくは、Ｐｒｏｘｙモードの場合は、Ｐｒｏｘｙ経由でＳＱＬが処理可能かを判断するためにステップ７０６へ移る。
【００６６】
Ｐｒｏｘｙ経由でＳＱＬが処理可能かチェックするには、ステップ７０６でこれまでクライアントが同じトランザクション内で要求した更新データを、照会ＳＱＬが照会する可能性があるかを判断することで行う。
【００６７】
例えば、図１５のＳＱＬ Ａ（ＵＰＤＡＴＥ）をすでに実行済みで、ＳＱＬ Ｂ（ＳＥＬＥＣＴ）という照会ＳＱＬを要求する場合は、更新したデータを照会することはないので、Ｐｒｏｘｙ経由で照会可能となる。
【００６８】
一方、ＳＱＬ Ｃ（ＳＥＬＥＣＴ）という照会ＳＱＬを要求する場合は、更新データを照会する可能性があるため、Ｐｒｏｘｙ経由で照会できない。また、ＳＱＬＤ（ＳＥＬＥＣＴ）のように、クエリからでは更新したデータを判定できない場合も、同様にＰｒｏｘｙ、経由で照会できないと判断する。
【００６９】
ステップ７０８で、Ｐｒｏｘｙ経由で照会する場合は、ＤＢ Ｐｒｏｘｙに照会ＳＱＬを送信し、ステップ７１０で、ＤＢ Ｐｒｏｘｙから照会ＳＱＬ結果を受信するまで待機する。ステップ７１２で、照会ＳＱＬ結果を受信後は、照会ＳＱＬを照会済ＳＱＬ記憶部に追加し、ステップ７１４でモードをＰｒｏｘｙモードに遷移させる。
【００７０】
一方、Ｐｒｏｘｙ経由で照会しない場合は、直接データベースに照会ＳＱＬを要求し、照会ＳＱＬ結果を受信する。ステップ７１６で、もしトランザクションが開始されていない場合（トランザクション状態がＩｎａｃｔｉｖｅの場合）は、ステップ７１８でトランザクション開始をデータベースに要求し、ステップ７２２でトランザクション状態をＡｃｔｉｖｅにしてから、ステップ７２４で照会ＳＱＬを要求する。そしてステップ７２６でデータベース１３０から照会ＳＱＬの結果を受信する。
【００７１】
図８に、更新ＳＱＬを要求時のクライアントの挙動のフローチャートを示す。
【００７２】
ステップ８０２でクライアントが照会ＳＱＬを要求する際は、まず、ステップ８０４でモードがＰｒｏｘｙモードか否かを判断する。
Ｐｒｏｘｙモードの場合は、ステップ７０６で照会ＳＱＬで照会したデータを、更新ＳＱＬが更新する可能性があるかを判断する。
【００７３】
更新ＳＱＬが更新する可能性があるかのチェックは、照会済ＳＱＬ記憶部内の照会ＳＱＬと、その照会結果をチェックすることで判定する。
例えば、照会済ＳＱＬ記憶部内に、図１６のＳＱＬ Ｄ（ＳＥＬＥＣＴ）という照会ＳＱＬを要求する場合、ＳＱＬ Ｅ（ＵＰＤＡＴＥ）という更新の際は更新する可能性がなく、ＳＱＬＦ（ＵＰＤＡＴＥ）の際は更新する可能性があると判断する。
【００７４】
ステップ８０６で、もし更新があると判断した場合は、これまでにＰｒｏｘｙ経由で照会したＳＱＬを、再度直接データベースに要求し、照会結果を受信する。
【００７５】
ステップ８０８で、クライアントがトランザクションを直接要求していない場合（トランザクション状態がＩｎａｃｔｉｖｅの場合）は、ステップ８１０でデータベースにトランザクションの開始要求を行ってから、ステップ８１２で照会ＳＱＬを送信する。
【００７６】
ステップ８１４で照会結果を受信後は、ステップ８１６でＤｉｒｅｃｔモードに遷移し、ステップ８１８でＤＢＰｒｏｘｙにコミット要求を送信する。そして処理はステップ８２０へ移る。
【００７７】
Ｐｒｏｘｙモードではない場合、もしくは、照会結果を受信した後は、データベースに更新ＳＱＬを要求し、更新結果を受信する。
【００７８】
ステップ８２０で、クライアントがトランザクションを直接要求していない場合（トランザクション状態がＩｎａｃｔｉｖｅの場合）は、ステップ８２２でデータベースにトランザクションの開始要求を行い、ステップ８２４でトランザクション状態をＡｃｔｉｖｅにしてから、ステップ８２６で更新ＳＱＬを送信する。ステップ８２８で更新結果を受信した後は、ステップ８３０で更新ＳＱＬを更新済みＳＱＬ記憶部に追加する。
【００７９】
図９に、コミット要求時のクライアントの挙動のフローチャートを示す。
【００８０】
ステップ９０２でコミット要求を出す際に、ステップ９０４でトランザクション状態がＩｎａｃｔｉｖｅか判断する。Ｉｎａｃｔｉｖｅの場合はステップ９０６でデータベース１３０にコミット要求を出しステップ９０８へ移る。
【００８１】
ステップ９０４でトランザクション状態がＡｃｉｖｅの場合はステップ９０８でＤＢＰｒｏｘｙモードか判断する。ＤＢ Ｐｒｏｘｙモードの場合はステップ９１０でＤＢ Ｐｒｏｘｙ１２０にコミット要求を出しステップ９１２に進む。ステップ９０８でＤＢ Ｐｒｏｘｙモードでない場合にはステップ９１２でトランザクション処理終了となる。
【００８２】
図１０に、ロールバック要求時のクライアントの挙動のフローチャートを示す。
【００８３】
ステップ１００２で、ロールバックを要求する際、ステップ１００４でトランザクション状態がＩｎａｃｔｉｖｅかどうか判断する。Ｉｎａｃｔｉｖｅの場合はステップ１００６でデータベースにロールバック要求し、ステップ１００８に進む。Ａｃｔｉｖｅの場合は、ステップ１００８でＤＢＰｒｏｘｙモードかどうかを判断する。ＤＢ Ｐｒｏｘｙモードの場合は、ステップ１０１０でＤＢＰｒｏｘｙにコミット要求し、ステップ１０１２に進む、ＤＢ Ｐｒｏｘｙモードでない場合にはステップ１０１２でトランザクション処理を終了する。
【００８４】
図１１に、照会ＳＱＬ要求受信時のＤＢ Ｐｒｏｘｙの挙動のフローチャートを示す。
【００８５】
ステップ１１０２で、クライアントから照会ＳＱＬを受信する際、ステップ１１０４で、開始済クライアント記憶部にクライアントが含まれるか判断する。含まれる場合には処理はステップ１１１０に進む。含まれない場合にはステップ１１０６で、クライアントを開始待ちクライアント記憶部に追加する。そしてステップ１１０８で、クライアントが開始済みクライアント記憶部に追加されるまで待機する。そしてステップ１１１０で、バッチ待ち照会ＳＱＬ記憶部に照会ＳＱＬを追加する。
【００８６】
図１２に、照会ＳＱＬのバッチ要求時の、ＤＢ Ｐｒｏｘｙの挙動のフローチャートを示す。
【００８７】
ステップ１２０２で、バッチ待ち照会ＳＱＬ記憶部内に照会ＳＱＬが存在するようになる待機する。ステップ１２０４で、バッチ待ち照会ＳＱＬ記憶部内の照会ＳＱＬの１つを選択する。
【００８８】
ステップ１２０６で、開始済クライアント記憶部内の他クライアントが、選択した照会ＳＱＬとバッチ可能なＳＱＬを要求する可能性がないか判断する。可能性がある場合には処理はステップ１２０２に戻る。可能性がない場合にはステップ１２０８でバッチ待ち照会ＳＱＬ記憶部から、照会ＳＱＬとバッチ可能な他クライアントの照会ＳＱＬを消去し、バッチ照会ＳＱＬとしてデータベースに要求する。次にステップ１２１０でデータベースから照会結果を受信し、バッチ照会ＳＱＬに含まれる照会ＳＱＬごとに、照会結果を分割し、要求したクライアントに送信する。
【００８９】
図１３に、トランザクションのコミット要求時のＤＢ Ｐｒｏｘｙの挙動のフローチャートを示す。
【００９０】
ステップ１３０２でクライアントからのコミット要求を待機する。ステップ１３０４で、コミット済クライアント記憶部にクライアントを追加する。
【００９１】
ステップ１３０６でコミット済クライアント記憶部と開始済クライアント記憶部が同じかどうか判断する、同じでない場合、処理はステップ１３１６へ進む。同じ場合はステップ１３０８でデータベースにコミット要求し、ステップ１３１０で、開始済クライアント記憶部の全クライアントに、コミット完了を通知する。
【００９２】
次にステップ１３１２で開始済みクライアント記憶部を消去する。そしてステップ１３１４で開始待ちクライアント記憶部にクライアントが存在するか判断する。存在しない場合には処理は１３０２に戻る。存在する場合にはステップ１３１６で、開始待ちクライアント記憶部の全クライアントを開始済クライアント記憶部に追加する。
【００９３】
以下、図面を参照して、本発明の実施例のシステム構成例を説明する。ここで説明する構成要素は必須の構成要件ではなく、一実施例として説明するものであり、本発明の技術的範囲をこの一実施例に限定して解釈されるものではないことに留意されたい。
【００９４】
図１４を参照すると、本発明の一実施例に係る、クライアント、ＤＢＰｒｏｘｙ、もしくはデータベースのシステム構成を実現するためのコンピュータ・ハードウェアのブロック図が示されている。
【００９５】
図１４において、システム・バス１４０９には、ＣＰＵ１４１０と、主記憶（ＲＡＭ）１４２０と、ハードディスク・ドライブ（ＨＤＤ）１４３０と、ネットワークコントローラ１４４０と、キーボード１４５０と、マウス１４６０と、ディスプレイ１４７０と、オーディオコントローラ１４８０が接続されている。
【００９６】
ＣＰＵ１４１０は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＰｅｎｔｉｕｍ（商標）４、インテル社のＣｏｒｅ（商標）２ ＤＵＯ、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。主記憶１４２０は、好適には、１ＧＢ以上の容量、より好ましくは、２ＧＢ以上の容量をもつものである。
【００９７】
ハードディスク・ドライブ１４３０には、オペレーティング・システムが、格納されている。オペレーティング・システムは、Ｌｉｎｕｘ（商標）、マイクロソフト社のＷｉｎｄｏｗｓ７、Ｗｉｎｄｏｗｓ ＸＰ（商標）、Ｗｉｎｄｏｗｓ（商標）２０００、アップルコンピュータのＭａｃＯＳ（商標）などの、ＣＰＵ１４１０に適合するオペレーティング・システムとして任意のものでよい。
【００９８】
ハードディスク・ドライブ１４３０には、好適にはＯＲＡＣＬＥ（商標）、ＤＢ２（商標）、ＳＱＬＳＥＲＶＥＲ（商標）、ＡＣＣＥＳＳ（商標）などのリレーショナルデータベース・アプリケーションが格納される。これらのアプリケーション、ソフトウェアに限らずＳＱＬを解釈できるものであれば任意に選択できる。そしてこれらのプログラムはオペレータのキーボードやマウス操作に応答して、メイン・メモリ１４２０にロードされて実行される。
【００９９】
キーボード１４５０及びマウス１４６０は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、データベースアプリケーションを開始したり、照会クエリの入力、パラメータの指定を提供するために使用される。
【０１００】
ディスプレイ１４７０は、照会クエリの表示、照会結果の表示等、適宜表示するために使用される。また音声認識ソフトウェアを用いてオーディオコントローラ１４８０通じ、音声により照会クエリを入力するようにしてもよい。
【０１０１】
ネットワークコントローラ１４４０はネットワークを通じて、クライアント、ＤＢＰｒｏｘｙ、データベース間で通信を行う。本発明はクライアント、ＤＢ Ｐｒｏｘｙ、が夫々別のハードウェアに存在する必要はない。例えば、ＤＢＰｒｏｘｙ とデータベースを１つのコンピュータ・ハードウェア内に構成しても良い。さらにクライアント、ＤＢＰｒｏｘｙ、データベースを１つのデータベースサーバ内に置く態様も可能である。
【符号の説明】
【０１０２】
１１０ クライアント
１２０ ＤＢＰｒｏｘｙ
１３０ データベース
１４０９ システム・バス
１４１０ ＣＰＵ
１４２０ メイン・メモリ
１４２０ 主記憶
１４３０ ハードディスク・ドライブ
１４４０ ネットワークコントローラ
１４５０ キーボード
１４６０ マウス
１４７０ ディスプレイ
１４８０ オーディオコントローラ
【技術分野】
【０００１】
本発明はトランザクションの処理方法に関し、特に複数の照会クエリを含む集約トランザクションの処理方法、システムに関する。
【背景技術】
【０００２】
通常、データベースにおけるトランザクション処理は、一貫した状態のデータベースを維持するよう設計されている。相互依存のある複数の操作が全て完了するか、全てキャンセルされることを保証している。そのために、ロック、ロールバック、デッドロックの回避の仕組みがある。
【０００３】
ロックとは、特定のデータに対するアクセスや更新を制御することである。特にデータベースへの書き込み処理を行なう際に、データの整合性を保つためにアクセスやデータの読み書きを一時的に制限することである。より具体的には１つの処理がデータＸにアクセス中は他の処理がＸへアクセスできないように排他制御を行う。１つの処理が２つ以上のＳＱＬ文で表される場合にトランザクションを利用する。
【０００４】
トランザクションは一連の処理（複数のＳＱＬからなる照会クエリ）をまとめてコミット（確定）またはロールバック（取り消し）を行うことができる機能で、これを利用すれば１つのＳＱＬ文が失敗した場合、同じ処理の別のＳＱＬ文をすべて取り消すことができる。ロールバックはつまりトランザクションがコミット前に失敗した場合、データベースをトランザクション開始前の状態に戻す処理である。またデッドロックとは、２つのトランザクションの処理中にデータベース内の同じ部分に同時にアクセスすることで、互いの処理の進行を妨げる現象である。例えば、トランザクションＡがデータＸにアクセスし、トランザクションＢがデータＹにアクセスする場合、ＡがＹにアクセスしようとし、ＢがＸにアクセスしようとしたときデッドロックが発生する。この場合どちらのトランザクションも先に進めなくなる。このようなデッドロックを回避するには、両方のトランザクションをキャンセルし、ロールバックする。そして順序を変えて再実行し、デッドロックが再度発生しないようにする。
【０００５】
クライアント数の増加と処理するデータ量の増大に伴い、データベースへのアクセスをより効率化する技術が知られている。特許文献１には、複数のロック制御によって複数のトランザクションの並行的な実行を制御する場合に、連続してなされるロック要求を蓄積し、ロック要求でない要求が出されたとき、この要求を処理する前に、前述の蓄積されたロック要求を一括してデ−タベ−スサ−バヘ送信し、ロック処理することによって送信回数を減少させる技術が開示されている。すなわち複数のトランザクション内でのロック要求をまとめる技術である。
【０００６】
特許文献２には、入力された複数のトランザクションを別々に処理するのではなく、入力された複数のトランザクションが処理を行うデータ項目に対して、そのデータ項目を一度だけ検索し、検索したデータ項目に対して、複数のトランザクションの更新処理を順次メインメモリ内で行い、最後に更新した結果だけをデータベースに一度だけ書き込む手法を開示している。すなわち複数のトランザクションの更新をまとめる技術である。
【０００７】
上記従来の方法は複数のトランザクションを１つにまとめて集約してデータベースに問い合わせる方法を採っていない。その理由は、複数のトランザクション（照会クエリ）に存在するＳＱＬ文を集約する方法が難しいことと、またＳＱＬの集約が可能になったとしても、データベースに集約照会をした時に、照会したデータを更新するトランザクションが１つでも発生した場合、必然的にデッドロックが発生するからである。なお本発明ではトランザクションの分離レベルを「再読み込み可能読み取り」（ＲＥＰＥＡＴＡＢＬＥＲＥＡＤ）とする。この分離レベルではトランザクションにおいて対象となるすべてのテーブルの対象データがトランザクション実行中に変更されないことが保証される。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開１９９３−０１０８４５２
【特許文献２】特開２００９−０２７１６６５
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明が解決しようとする課題は、データベース・クライアントがトランザクション処理をデータベースに要求する際に、一部の照会クエリを、その他のトランザクションの照会クエリと共に、別トランザクション（集約トランザクション）としてデータベースに要求する、集約トランザクションの処理方法、システムを提供することである。
【００１０】
さらに別の課題は、集約トランザクションの処理において、照会クエリを要求した全データベース・クライアントからのコミット要求を受信した時に前記集約トランザクションをコミットする方法、システムを提供することである。
【００１１】
さらに別の課題は、集約トランザクションを処理するにあたり、デッドロックの生じないデータ更新方法、システムを提供することである。
【課題を解決するための手段】
【００１２】
本発明は上記課題を解決するために、コンピュータの処理により、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約する方法であって、前記コンピュータが前記データベースと接続され、複数クライアントから複数トランザクションを受信するステップと、前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信するステップと、を有する。
【００１３】
また、前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信するステップが、前記コンピュータが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信するステップと、である。
【００１４】
また、前記送信するステップが、集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付けるステップと、前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成するステップと、複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成するステップと、前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換するステップと、前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶するステップと、全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信するステップである
【００１５】
さらに、前記方法が、前記データベースから前記集約トランザクションに対する結果を受信するステップとを有する。
【００１６】
さらに、前記方法が、前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信するステップを有する。
【００１７】
また、前記分割して送信するステップが、データベースから送信された結果からクライアントＩＤを判断するステップと、前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換するステップと、前記クライアントＩＤを有するクライアントに照会結果を送信するステップである。
【００１８】
そして、前記方法が、前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新するステップであって、更新するデータが、集約トランザクションとして照会したかを前記コンピュータに問い合わせるステップと、集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求するステップと、前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求するステップを有する。
【００１９】
別の態様として、本発明は、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約するシステムであって、複数クライアントから複数トランザクションを受信する手段と、前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信する手段を有する。
【００２０】
また、前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信する手段が、前記システムが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信する手段である。
【００２１】
また、前記送信する手段が、集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付ける手段と、前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成する手段と、複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成する手段と、前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換する手段と、前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶する手段と、全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信する手段である。
【００２２】
さらに、前記システムが、前記データベースから前記集約トランザクションに対する結果を受信する手段を有する。
【００２３】
さらに、前記システムが、前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信する手段を有する。
【００２４】
また、前記分割して送信する手段が、データベースから送信された結果からクライアントＩＤを判断する手段と、前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換する手段と、前記クライアントＩＤを有するクライアントに照会結果を送信する手段である。
【００２５】
そして、前記システムが、前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新する手段であって、更新するデータが、集約トランザクションとして照会したかを判断する手段と、集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求する手段と、前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求する手段を有する。
【００２６】
また別の態様として、上記何れか１つに記載の方法の各ステップを、コンピュータに実行させるためのプログラムを提供する。
【発明の効果】
【００２７】
本発明により、複数のトランザクションを１つにまとめて集約してデータベースに問い合わせることが可能となる。またデータベースに集約トランザクションを問い合わせた場合に、データを更新するトランザクションが発生てもデッドロックすることなく、パフォーマンスに優れたデータベースアクセスが可能となる。
【図面の簡単な説明】
【００２８】
【図１】本発明の全体のシステム構成を示す。
【図２】トランザクションをまとめてデータベース１３０へ送信する場合の図である。
【図３】集約トランザクションの問題点を示す図である。
【図４】本発明における集約トランザクションの処理例である。
【図５】クライアントとＤＢ Ｐｒｏｘｙ１２０の記憶構成ブロックを示す。
【図６】トランザクション開始時のクライアントの挙動を示す。
【図７】照会ＳＱＬを要求時のクライアントの挙動のフローチャートである。
【図８】更新ＳＱＬを要求時のクライアントの挙動のフローチャートである。
【図９】コミット要求時のクライアントの挙動のフローチャートである。
【図１０】ロールバック要求時のクライアントの挙動のフローチャートである。
【図１１】照会ＳＱＬ要求受信時のＤＢ Ｐｒｏｘｙの挙動のフローチャートである。
【図１２】照会ＳＱＬのバッチ要求時の、ＤＢ Ｐｒｏｘｙの挙動のフローチャートである。
【図１３】トランザクションのコミット要求時のＤＢ Ｐｒｏｘｙの挙動のフローチャートである。
【図１４】本発明における、クライアント、ＤＢ Ｐｒｏｘｙ、データベースの例示的なハードウェア構成である。
【図１５】ＳＱＬ文例である。
【図１６】別の ＳＱＬ文例である。
【図１７】ＳＱＬであるＳＥＬＥＣＴ文の集約のフローチャートを示す。
【図１８】データベース１３０から受信した結果を各クライアント用に分割するフローチャートを示す。
【図１９】データベース１３０から受信した結果の例である。
【図２０】データベース１３０から受信した結果を各クライアント用に分割する例１である。
【図２１】データベース１３０から受信した結果を各クライアント用に分割する例２である。
【図２２】データベース１３０から受信した結果を各クライアント用に分割する例３である。
【発明を実施するための形態】
【００２９】
図１に本発明の全体のシステム構成を示す。ＤＢ Ｐｒｏｘｙ１２０は複数のクライアント１１０からトランザクションを集約してデータベース１３０に送信する。ＤＢ Ｐｒｏｘｙ１２０は複数のクライアントに対して１つ存在する。
【００３０】
データベース１３０は、クライアント１１０、もしくは、ＤＢ Ｐｒｏｘｙ１２０から受信する、複数のＳＱＬを１つのトランザクションとして処理する。
【００３１】
ＤＢ Ｐｒｏｘｙ１２０は、トランザクションの開始をデータベース１３０に通知し、要求するＳＱＬを送信し、その結果を受信し、コミット要求をデータベースに送信することで行う。なお一般的には、ＳＱＬの送信、結果の受信は、複数回行われる。
【００３２】
なお本明細書の実施例において、クライアント１１０がトランザクションを開始する際の処理、照会ＳＱＬを要求する際の処理、更新ＳＱＬを要求する際の処理、コミット・ロールバックを要求する際の処理を詳細に説明する。また、ＤＢＰｒｏｘｙ１２０が、上記のクライアント１１０の処理内で、クライアントから照会ＳＱＬを受信した際の処理、クライアントからコミット要求を受信した際の処理を詳細に説明する。
【００３３】
なお説明の簡素化のため、ＤＢ Ｐｒｏｘｙ１２０、クライアント１１０は、同時に１つのトランザクションしか要求しないものと仮定する。また、クライアント１１０とＤＢＰｒｏｘｙ１２０は、Ｎ対１の関係がついているものとする。
【００３４】
図２に、トランザクションをまとめてデータベース１３０へ送信する場合を図示する。図２ではＤＢＰｒｏｘｙ１２０がクライアント１とクライアント２のトランザクション中の照会クエリをまとめてデータベースに要求することにより、データベースのスループットを向上させる。なお図中においてｒ は読み取り（Ｒｅａｄ）、ｗは書き込み（Ｗｒｉｔｅ）を表し、その添え字の最初はクライアント番号、次の添え字は時系列順序を表している。
【００３５】
図２において、クライアント１およびクライアント２は、トランザクション中の照会クエリを、ＤＢＰｒｏｘｙ１２０に転送する。ＤＢ Ｐｒｏｘｙ１２０は、複数のクライアントから受信した照会クエリを１つのクエリにまとめ、照会トランザクションとしてデータベース１３０に処理要求する。照会クエリは通常ＳＱＬ文であるので、同時系列順序で出されたクライアント１のレコードＡを参照するＳＱＬと、クライアント２のレコードＢを照会するＳＱＬ２つのＳＱＬは、ＤＢＰｒｏｘｙ１２０で１つのＳＱＬに集約されてデータベース１３０に送信されることになる。
【実施例】
【００３６】
図１７に、ＳＱＬであるＳＥＬＥＣＴ文の集約のフローチャートを示す。本発明ではＳＥＬＥＣＴ文の集約に集合演算子であるＵＮＩＯＮＡＬＬを使用する。ＵＮＩＯＮ 集合演算子とは複数の ＳＥＬＥＣＴ 文を１つに組み合わせる演算子である。しかし、複数の問い合わせを１つに結合することから、それぞれの問い合わせの抽出項目のリストは同数、かつ、同じグループのデータ型でなければ結合することができない。この方法により任意のＳＱＬをまとめることが可能になる。
【００３７】
まず１７１０で連結対象となるＳＥＬＥＣＴ文と、クライアントＩＤ （ＩＮＴ型） を対応付ける。例として以下の２つのＳＥＬＣＥＣＴ文を結合対象として説明する。
S1: SELECT C11, C12, C13 FROM T1 WHEREK1=? →クライアントIDを1とする
> C11: INT, C12: DOUBLE, C13: STRING
S2: SELECT C21, C22, C23 FROM T0 WHERE K2=? →クライアントIDを2とする
> C21: DOUBLE, C22:INT, C23: DATE
【００３８】
ステップ１７２０で、全てのＳＥＬＥＣＴ文が返すデータ（カラム）の型を含む、データの型の集合を生成する。この時、同一グループのデータ型について型を増加させす１つにして異なるグループのデータ型は新しく付加する。すなわち型の集合を作成する時は異なる型のみを追加する。
例では、{INT, DOUBLE,STRING, DATE}となる。
【００３９】
ステップ１７３０で、ステップ１７２０で生成した型の集合に順序をつけ、先頭にＩＮＴ型を追加する。
例では、INT, INT, DOUBLE,STRING, DATEの順となる。
【００４０】
ステップ１７４０で、各ＳＥＬＥＣＴ文に対し、ステップ１７３０でつけた順序で結果を返すように書き換える。もし、返す型が存在しない場合は、固定値を返すようにする。また、最初のＩＮＴ型には、クライアントＩＤを固定値として返すようにする。
S1': SELECT 1, C11, C12, C13, NULL FROM T1 WHERE K1=?
S2': SELECT 2, C22, C21, ‘CONST', C23 FROM T2 WHERE K2=?
【００４１】
ステップ１７５０で、元のＳＥＬＥＣＴ文のデータ型（カラム）順序と、書き換えたＳＥＬＥＣＴ文のデータ型（カラム）順序の対応を記憶する。記憶した内容は後ほど結果を分割するために使用する。
【００４２】
S1とS1'の対応:{1→2, 2→3, 3→4} (1→2は、S1の1番目の項目がS1'の2番目の項目に対応することを意味する)
S2とS2'の対応:{1→3, 2→2, 3→5} (1→3は、S2の1番目の項目がS2'の3番目の項目に対応することを意味する)
【００４３】
ステップ１７６０で、書き換えたＳＥＬＥＣＴ文をＵＮＩＯＮ ＡＬＬで連結する。そしてデータベース１３０に照会する。
SELECT 1, C11, C12, C13, NULL FROM T1 WHERE K1=? UNION ALL SELECT 2,C22, C21, ‘CONST', C23 FROM T2 WHERE K2=?
【００４４】
図１８に、データベース１３０から受信した結果を各クライアント用に分割するフローチャートを示す。
【００４５】
図１９に、データベース１３０から受信した結果の例を示す。表は左から、INT, INT, DOUBLE, STRING, DATEの順で構成されたデータが５行存在している。左端のＩＮＴ型データはクライアントＩＤを示している。
【００４６】
図１８のフローチャートに従い、ステップ１８１０で、データベース１３０から受信した結果から一行読み込む。すなわち１行目である、1, 1, 0.001, "AAAA"が読み込まれる。ステップ１８２０で、ステップ１８１０で読み込んだ行の、始めのＩＮＴ型のデータからクライアントＩＤを取得する。この場合は１であるのでクライアント１であることがわかる。
【００４７】
ステップ１８３０で、ステップ１８２０で読み込んだ行を、ステップ１７５０で記憶したデータ型順序の対応から、各クライアントが要求したデータ型の値のみを、要求順に並び替え、そのクライアントＩＤのＳＥＬＥＣＴ文に対する結果とする。
【００４８】
ここでクライアント１において、S1とS1'の対応関係は{1→2, 2→3, 3→4} であるので、１行目のデータは図２０に示すように変換される。この処理を繰り返すことで、クライアント１のデータは図２１に示すように、元の結果から分離され、変換されることになる。
【００４９】
３行目からはクライアント２の結果であるので、S2とS2'の対応関係{1→3, 2→2, 3→5} を参照しながら、図２２に示すように、元の結果から分離され、変換される。
【００５０】
図１８のフローチャートに従い、ステップ１８４０で、受信した結果が存在しない場合は処理を終了する。それ以外は、ステップ１８１０に戻る。
【００５１】
本発明の集約と分割の特徴はまとめると次のようになる。
・ＳＥＬＥＣＴ対象となるデータの型情報のみを利用して、ＵＮＩＯＮ ＡＬＬのデータ型を決定すること
・ＵＮＩＯＮ ＡＬＬのデータ（カラム）名とクライアントの要求したＳＥＬＥＣＴ文のデータ（カラム）名の対応関係から、各クライアント用の結果を分割して生成すること。
・ＳＥＬＥＣＴ文のＩＤが結果に含まれない場合は、空の結果（ＲｅｓｕｌｔＳｅｔ）を生成すること
これにより本発明は、ＤＢ Ｐｒｏｘｙ１２０で、複数の照会ＳＱＬを集約してデータベースに処理要求し、その結果をそれぞれのクライアントに分割して返すことができる。
【００５２】
図２の集約クエリ送信後の問題点を図３で説明する。
１．クライアント１は、トランザクション中の照会クエリ（レコードＡを照会ｒ１１）を、ＤＢ Ｐｒｏｘｙ１２０に転送する。
２．クライアント２は、トランザクション中の照会クエリ（レコードＢを照会ｒ２１）を、ＤＢ Ｐｒｏｘｙ１２０に転送する。
３．ＤＢ Ｐｒｏｘｙ１２０は、クライアント１とクライアント２から受信した照会クエリを１つのクエリにまとめ、集約トランザクション（レコードＡとレコードＢを同時照会ｒ１１＋２１）としてデータベース１３０に処理要求する。
４．ここでクライアント１が、同じトランザクション中の更新クエリを更新トランザクション（レコードＡを更新ｗ１２）として、ＤＢ Ｐｒｏｘｙ１２０経由で照会中の集約トランザクション（照会クエリ）とは別に、データベース１３０に要求する。
【００５３】
しかし、この更新トランザクションは集約トランザクションによりレコードＡがロックされているため、レコードＡのロックが開放されるまで待たねばならないが開放されることがない。
【００５４】
なぜなら、クライアント１の更新トランザクションは、ＤＢ Ｐｒｏｘｙ１２０の照会トランザクションがコミットされないと、コミットできないからである。逆に、クライアント１の更新トランザクションよりコミットの通知を受けなくては、ＤＢＰｒｏｘｙ１２０の照会トランザクションがコミットすることはないからである。すなわち、ＤＢ Ｐｒｏｘｙ１２０に要求した照会クエリで照会したレコードＡを、同じトランザクションで更新する場合、必ずデッドロックが発生することになる。
【００５５】
そこで本発明では図４の方法を採る。以下の手順により、集約トランザクションで照会したレコードを更新する場合でも、デッドロックが発生しない。クライアント１が集約トランザクション経由で照会したデータを更新する際に、
４．まずクライアント１は、更新するレコードＡが、集約トランザクションとして照会したかをＤＢＰｒｏｘｙ１２０に問い合わせる。集約トランザクションとして照会している場合、クライアント１は、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベース１３０に処理要求する。
５．クライアント１は、ＤＢＰｒｏｘｙ１２０にコミット要求を出す。
６．クライアント１はレコードＡの更新クエリを直接トランザクションとして、データベース１３０に処理要求する
【００５６】
図５に、クライアントとＤＢ Ｐｒｏｘｙ１２０の記憶構成ブロックを示す。ここでＤＢ Ｐｒｏｘｙ１２０は説明のため１つのトランザクションのみを実行することを仮定する。
【００５７】
クライアントは、照会済ＳＱＬ記憶部、更新済ＳＱＬ記憶部、モード、トランザクション状態を管理する。照会済ＳＱＬ記憶部は、現在実行中のトランザクション内で照会したＳＱＬの履歴を保持する。更新済ＳＱＬ記憶部は、現在実行中のトランザクション内で更新したＳＱＬの履歴を保持する。
【００５８】
モードは、照会ＳＱＬの送信モードを意味し、Ｐｒｏｘｙ時はＤＢ Ｐｒｏｘｙを優先的に利用する、Ｄｉｒｅｃｔ時は直接利用することを意味する。なお、Ｎｕｌｌ時はモードが決定されていないことを意味する。トランザクション状態は、クライアントが直接要求するトランザクションの状態を意味し、Ａｃｔｉｖｅ時はトランザクションを要求中、Ｉｎａｃｔｉｖｅはトランザクションを要求していないことを意味する。
【００５９】
ＤＢ Ｐｒｏｘｙは、開始待ちクライアント記憶部、開始済クライアント記憶部、コミット済クライアント記憶部、バッチ待ち照会ＳＱＬ記憶部を管理する。
【００６０】
開始待ちクライアント記憶部は、ＤＢ Ｐｒｏｘｙが次のトランザクションでバッチ対象とするＳＱＬを要求したクライアントの識別子のリストを保持する。開始済みクライアント記憶部は、ＤＢＰｒｏｘｙが現在バッチ対象とするＳＱＬを要求したクライアントの識別子のリストを保持する。
【００６１】
コミット済みクライアント記憶部は、開始済みクライアント記憶部のうち、コミット要求を受信したクライアントの識別子のリストを保持する。バッチ待ち照会ＳＱＬ記憶部は、開始済みクライアント記憶部のクライアントがＤＢＰｒｏｘｙに要求し、ＤＢ Ｐｒｏｘｙがまだデータベースに要求していないＳＱＬを保持する。
【００６２】
図６に、トランザクション開始時のクライアントの挙動を示す。
【００６３】
ステップ６０２で、照会ＳＱＬを要求する。ステップ６０４でモードをＮｕｌｌに遷移する。次にステップ６０６で照会済ＳＱＬ記憶部をクリアする。そしてステップ６０８で更新済ＳＱＬ記憶部をクリアし、最後にステップ６１０でトランザクション状態をＩｎａｃｔｉｖｅにする。
【００６４】
図７に、照会ＳＱＬを要求時のクライアントの挙動のフローチャートを示す。
【００６５】
クライアントが照会ＳＱＬを要求する際は、ステップ７０４で、モードがＤｉｒｅｃｔモードか否かを判断する。Ｎｕｌｌモード、もしくは、Ｐｒｏｘｙモードの場合は、Ｐｒｏｘｙ経由でＳＱＬが処理可能かを判断するためにステップ７０６へ移る。
【００６６】
Ｐｒｏｘｙ経由でＳＱＬが処理可能かチェックするには、ステップ７０６でこれまでクライアントが同じトランザクション内で要求した更新データを、照会ＳＱＬが照会する可能性があるかを判断することで行う。
【００６７】
例えば、図１５のＳＱＬ Ａ（ＵＰＤＡＴＥ）をすでに実行済みで、ＳＱＬ Ｂ（ＳＥＬＥＣＴ）という照会ＳＱＬを要求する場合は、更新したデータを照会することはないので、Ｐｒｏｘｙ経由で照会可能となる。
【００６８】
一方、ＳＱＬ Ｃ（ＳＥＬＥＣＴ）という照会ＳＱＬを要求する場合は、更新データを照会する可能性があるため、Ｐｒｏｘｙ経由で照会できない。また、ＳＱＬＤ（ＳＥＬＥＣＴ）のように、クエリからでは更新したデータを判定できない場合も、同様にＰｒｏｘｙ、経由で照会できないと判断する。
【００６９】
ステップ７０８で、Ｐｒｏｘｙ経由で照会する場合は、ＤＢ Ｐｒｏｘｙに照会ＳＱＬを送信し、ステップ７１０で、ＤＢ Ｐｒｏｘｙから照会ＳＱＬ結果を受信するまで待機する。ステップ７１２で、照会ＳＱＬ結果を受信後は、照会ＳＱＬを照会済ＳＱＬ記憶部に追加し、ステップ７１４でモードをＰｒｏｘｙモードに遷移させる。
【００７０】
一方、Ｐｒｏｘｙ経由で照会しない場合は、直接データベースに照会ＳＱＬを要求し、照会ＳＱＬ結果を受信する。ステップ７１６で、もしトランザクションが開始されていない場合（トランザクション状態がＩｎａｃｔｉｖｅの場合）は、ステップ７１８でトランザクション開始をデータベースに要求し、ステップ７２２でトランザクション状態をＡｃｔｉｖｅにしてから、ステップ７２４で照会ＳＱＬを要求する。そしてステップ７２６でデータベース１３０から照会ＳＱＬの結果を受信する。
【００７１】
図８に、更新ＳＱＬを要求時のクライアントの挙動のフローチャートを示す。
【００７２】
ステップ８０２でクライアントが照会ＳＱＬを要求する際は、まず、ステップ８０４でモードがＰｒｏｘｙモードか否かを判断する。
Ｐｒｏｘｙモードの場合は、ステップ７０６で照会ＳＱＬで照会したデータを、更新ＳＱＬが更新する可能性があるかを判断する。
【００７３】
更新ＳＱＬが更新する可能性があるかのチェックは、照会済ＳＱＬ記憶部内の照会ＳＱＬと、その照会結果をチェックすることで判定する。
例えば、照会済ＳＱＬ記憶部内に、図１６のＳＱＬ Ｄ（ＳＥＬＥＣＴ）という照会ＳＱＬを要求する場合、ＳＱＬ Ｅ（ＵＰＤＡＴＥ）という更新の際は更新する可能性がなく、ＳＱＬＦ（ＵＰＤＡＴＥ）の際は更新する可能性があると判断する。
【００７４】
ステップ８０６で、もし更新があると判断した場合は、これまでにＰｒｏｘｙ経由で照会したＳＱＬを、再度直接データベースに要求し、照会結果を受信する。
【００７５】
ステップ８０８で、クライアントがトランザクションを直接要求していない場合（トランザクション状態がＩｎａｃｔｉｖｅの場合）は、ステップ８１０でデータベースにトランザクションの開始要求を行ってから、ステップ８１２で照会ＳＱＬを送信する。
【００７６】
ステップ８１４で照会結果を受信後は、ステップ８１６でＤｉｒｅｃｔモードに遷移し、ステップ８１８でＤＢＰｒｏｘｙにコミット要求を送信する。そして処理はステップ８２０へ移る。
【００７７】
Ｐｒｏｘｙモードではない場合、もしくは、照会結果を受信した後は、データベースに更新ＳＱＬを要求し、更新結果を受信する。
【００７８】
ステップ８２０で、クライアントがトランザクションを直接要求していない場合（トランザクション状態がＩｎａｃｔｉｖｅの場合）は、ステップ８２２でデータベースにトランザクションの開始要求を行い、ステップ８２４でトランザクション状態をＡｃｔｉｖｅにしてから、ステップ８２６で更新ＳＱＬを送信する。ステップ８２８で更新結果を受信した後は、ステップ８３０で更新ＳＱＬを更新済みＳＱＬ記憶部に追加する。
【００７９】
図９に、コミット要求時のクライアントの挙動のフローチャートを示す。
【００８０】
ステップ９０２でコミット要求を出す際に、ステップ９０４でトランザクション状態がＩｎａｃｔｉｖｅか判断する。Ｉｎａｃｔｉｖｅの場合はステップ９０６でデータベース１３０にコミット要求を出しステップ９０８へ移る。
【００８１】
ステップ９０４でトランザクション状態がＡｃｉｖｅの場合はステップ９０８でＤＢＰｒｏｘｙモードか判断する。ＤＢ Ｐｒｏｘｙモードの場合はステップ９１０でＤＢ Ｐｒｏｘｙ１２０にコミット要求を出しステップ９１２に進む。ステップ９０８でＤＢ Ｐｒｏｘｙモードでない場合にはステップ９１２でトランザクション処理終了となる。
【００８２】
図１０に、ロールバック要求時のクライアントの挙動のフローチャートを示す。
【００８３】
ステップ１００２で、ロールバックを要求する際、ステップ１００４でトランザクション状態がＩｎａｃｔｉｖｅかどうか判断する。Ｉｎａｃｔｉｖｅの場合はステップ１００６でデータベースにロールバック要求し、ステップ１００８に進む。Ａｃｔｉｖｅの場合は、ステップ１００８でＤＢＰｒｏｘｙモードかどうかを判断する。ＤＢ Ｐｒｏｘｙモードの場合は、ステップ１０１０でＤＢＰｒｏｘｙにコミット要求し、ステップ１０１２に進む、ＤＢ Ｐｒｏｘｙモードでない場合にはステップ１０１２でトランザクション処理を終了する。
【００８４】
図１１に、照会ＳＱＬ要求受信時のＤＢ Ｐｒｏｘｙの挙動のフローチャートを示す。
【００８５】
ステップ１１０２で、クライアントから照会ＳＱＬを受信する際、ステップ１１０４で、開始済クライアント記憶部にクライアントが含まれるか判断する。含まれる場合には処理はステップ１１１０に進む。含まれない場合にはステップ１１０６で、クライアントを開始待ちクライアント記憶部に追加する。そしてステップ１１０８で、クライアントが開始済みクライアント記憶部に追加されるまで待機する。そしてステップ１１１０で、バッチ待ち照会ＳＱＬ記憶部に照会ＳＱＬを追加する。
【００８６】
図１２に、照会ＳＱＬのバッチ要求時の、ＤＢ Ｐｒｏｘｙの挙動のフローチャートを示す。
【００８７】
ステップ１２０２で、バッチ待ち照会ＳＱＬ記憶部内に照会ＳＱＬが存在するようになる待機する。ステップ１２０４で、バッチ待ち照会ＳＱＬ記憶部内の照会ＳＱＬの１つを選択する。
【００８８】
ステップ１２０６で、開始済クライアント記憶部内の他クライアントが、選択した照会ＳＱＬとバッチ可能なＳＱＬを要求する可能性がないか判断する。可能性がある場合には処理はステップ１２０２に戻る。可能性がない場合にはステップ１２０８でバッチ待ち照会ＳＱＬ記憶部から、照会ＳＱＬとバッチ可能な他クライアントの照会ＳＱＬを消去し、バッチ照会ＳＱＬとしてデータベースに要求する。次にステップ１２１０でデータベースから照会結果を受信し、バッチ照会ＳＱＬに含まれる照会ＳＱＬごとに、照会結果を分割し、要求したクライアントに送信する。
【００８９】
図１３に、トランザクションのコミット要求時のＤＢ Ｐｒｏｘｙの挙動のフローチャートを示す。
【００９０】
ステップ１３０２でクライアントからのコミット要求を待機する。ステップ１３０４で、コミット済クライアント記憶部にクライアントを追加する。
【００９１】
ステップ１３０６でコミット済クライアント記憶部と開始済クライアント記憶部が同じかどうか判断する、同じでない場合、処理はステップ１３１６へ進む。同じ場合はステップ１３０８でデータベースにコミット要求し、ステップ１３１０で、開始済クライアント記憶部の全クライアントに、コミット完了を通知する。
【００９２】
次にステップ１３１２で開始済みクライアント記憶部を消去する。そしてステップ１３１４で開始待ちクライアント記憶部にクライアントが存在するか判断する。存在しない場合には処理は１３０２に戻る。存在する場合にはステップ１３１６で、開始待ちクライアント記憶部の全クライアントを開始済クライアント記憶部に追加する。
【００９３】
以下、図面を参照して、本発明の実施例のシステム構成例を説明する。ここで説明する構成要素は必須の構成要件ではなく、一実施例として説明するものであり、本発明の技術的範囲をこの一実施例に限定して解釈されるものではないことに留意されたい。
【００９４】
図１４を参照すると、本発明の一実施例に係る、クライアント、ＤＢＰｒｏｘｙ、もしくはデータベースのシステム構成を実現するためのコンピュータ・ハードウェアのブロック図が示されている。
【００９５】
図１４において、システム・バス１４０９には、ＣＰＵ１４１０と、主記憶（ＲＡＭ）１４２０と、ハードディスク・ドライブ（ＨＤＤ）１４３０と、ネットワークコントローラ１４４０と、キーボード１４５０と、マウス１４６０と、ディスプレイ１４７０と、オーディオコントローラ１４８０が接続されている。
【００９６】
ＣＰＵ１４１０は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＰｅｎｔｉｕｍ（商標）４、インテル社のＣｏｒｅ（商標）２ ＤＵＯ、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。主記憶１４２０は、好適には、１ＧＢ以上の容量、より好ましくは、２ＧＢ以上の容量をもつものである。
【００９７】
ハードディスク・ドライブ１４３０には、オペレーティング・システムが、格納されている。オペレーティング・システムは、Ｌｉｎｕｘ（商標）、マイクロソフト社のＷｉｎｄｏｗｓ７、Ｗｉｎｄｏｗｓ ＸＰ（商標）、Ｗｉｎｄｏｗｓ（商標）２０００、アップルコンピュータのＭａｃＯＳ（商標）などの、ＣＰＵ１４１０に適合するオペレーティング・システムとして任意のものでよい。
【００９８】
ハードディスク・ドライブ１４３０には、好適にはＯＲＡＣＬＥ（商標）、ＤＢ２（商標）、ＳＱＬＳＥＲＶＥＲ（商標）、ＡＣＣＥＳＳ（商標）などのリレーショナルデータベース・アプリケーションが格納される。これらのアプリケーション、ソフトウェアに限らずＳＱＬを解釈できるものであれば任意に選択できる。そしてこれらのプログラムはオペレータのキーボードやマウス操作に応答して、メイン・メモリ１４２０にロードされて実行される。
【００９９】
キーボード１４５０及びマウス１４６０は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、データベースアプリケーションを開始したり、照会クエリの入力、パラメータの指定を提供するために使用される。
【０１００】
ディスプレイ１４７０は、照会クエリの表示、照会結果の表示等、適宜表示するために使用される。また音声認識ソフトウェアを用いてオーディオコントローラ１４８０通じ、音声により照会クエリを入力するようにしてもよい。
【０１０１】
ネットワークコントローラ１４４０はネットワークを通じて、クライアント、ＤＢＰｒｏｘｙ、データベース間で通信を行う。本発明はクライアント、ＤＢ Ｐｒｏｘｙ、が夫々別のハードウェアに存在する必要はない。例えば、ＤＢＰｒｏｘｙ とデータベースを１つのコンピュータ・ハードウェア内に構成しても良い。さらにクライアント、ＤＢＰｒｏｘｙ、データベースを１つのデータベースサーバ内に置く態様も可能である。
【符号の説明】
【０１０２】
１１０ クライアント
１２０ ＤＢＰｒｏｘｙ
１３０ データベース
１４０９ システム・バス
１４１０ ＣＰＵ
１４２０ メイン・メモリ
１４２０ 主記憶
１４３０ ハードディスク・ドライブ
１４４０ ネットワークコントローラ
１４５０ キーボード
１４６０ マウス
１４７０ ディスプレイ
１４８０ オーディオコントローラ
【特許請求の範囲】
【請求項１】
コンピュータの処理により、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約する方法であって、前記コンピュータが前記データベースと接続され、
複数クライアントから複数トランザクションを受信するステップと、
前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信するステップ、
を有する、方法。
【請求項２】
前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信するステップが、
前記コンピュータが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信するステップ、
である、請求項１記載の方法。
【請求項３】
前記送信するステップが、
集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付けるステップと、
前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成するステップと、
複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成するステップと、
前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換するステップと、
前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶するステップと、
全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信するステップ、
である、請求項２の方法。
【請求項４】
前記方法が、さらに
前記データベースから前記集約トランザクションに対する結果を受信するステップと、
を有する、請求項３記載の方法。
【請求項５】
前記方法が、さらに
前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信するステップと、
を有する、請求項４記載の方法。
【請求項６】
前記分割して送信するステップが、
データベースから送信された結果からクライアントＩＤを判断するステップと、
前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換するステップと、
前記クライアントＩＤを有するクライアントに照会結果を送信するステップ、
である、請求項５記載の方法。
【請求項７】
前記方法が、
前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新するステップであって、
更新するデータが、集約トランザクションとして照会したかを前記コンピュータに問い合わせるステップと、
集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求するステップと、
前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求するステップ、
を有する、請求項１記載の方法。
【請求項８】
データベースにアクセスして、複数の照会クエリを含むトランザクションを集約するシステムであって、
複数クライアントから複数トランザクションを受信する手段と、
前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信する手段、
を有する、システム。
【請求項９】
前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信する手段が、
前記システムが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信する手段、
である、請求項８記載のシステム。
【請求項１０】
前記送信する手段が、
集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付ける手段と、
前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成する手段と、
複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成する手段と、
前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換する手段と、
前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶する手段と、
全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信する手段、
である、請求項９のシステム。
【請求項１１】
前記システムが、さらに
前記データベースから前記集約トランザクションに対する結果を受信する手段、
を有する、請求項１０記載のシステム。
【請求項１２】
前記システムが、さらに
前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信する手段、
を有する、請求項１１記載のシステム。
【請求項１３】
前記分割して送信する手段が、
データベースから送信された結果からクライアントＩＤを判断する手段と、
前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換する手段と、
前記クライアントＩＤを有するクライアントに照会結果を送信する手段、
である、請求項１２記載のシステム。
【請求項１４】
前記システムが、さらに、
前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新する手段であって、
更新するデータが、集約トランザクションとして照会したかを判断する手段と、
集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求する手段と、
前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求する手段、
を有する、請求項８記載のシステム。
【請求項１５】
請求項１〜７記載の何れか１つに記載の方法の各ステップを、コンピュータに実行させるためのプログラム。
【請求項１】
コンピュータの処理により、データベースにアクセスして、複数の照会クエリを含むトランザクションを集約する方法であって、前記コンピュータが前記データベースと接続され、
複数クライアントから複数トランザクションを受信するステップと、
前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信するステップ、
を有する、方法。
【請求項２】
前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信するステップが、
前記コンピュータが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信するステップ、
である、請求項１記載の方法。
【請求項３】
前記送信するステップが、
集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付けるステップと、
前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成するステップと、
複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成するステップと、
前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換するステップと、
前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶するステップと、
全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信するステップ、
である、請求項２の方法。
【請求項４】
前記方法が、さらに
前記データベースから前記集約トランザクションに対する結果を受信するステップと、
を有する、請求項３記載の方法。
【請求項５】
前記方法が、さらに
前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信するステップと、
を有する、請求項４記載の方法。
【請求項６】
前記分割して送信するステップが、
データベースから送信された結果からクライアントＩＤを判断するステップと、
前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換するステップと、
前記クライアントＩＤを有するクライアントに照会結果を送信するステップ、
である、請求項５記載の方法。
【請求項７】
前記方法が、
前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新するステップであって、
更新するデータが、集約トランザクションとして照会したかを前記コンピュータに問い合わせるステップと、
集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求するステップと、
前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求するステップ、
を有する、請求項１記載の方法。
【請求項８】
データベースにアクセスして、複数の照会クエリを含むトランザクションを集約するシステムであって、
複数クライアントから複数トランザクションを受信する手段と、
前記複数トランザクション中の照会クエリを集約し、集約トランザクションとしてデータベースに送信する手段、
を有する、システム。
【請求項９】
前記照会クエリは複数のＳＱＬ文からなり、前記データベースに送信する手段が、
前記システムが前記トランザクション中の照会クエリを、集合演算子を用いて集約し、集約トランザクションとしてデータベースに送信する手段、
である、請求項８記載のシステム。
【請求項１０】
前記送信する手段が、
集約対象となる照会クエリのＳＱＬ文について前記照会クエリを発したクライアントのクライアントＩＤを対応付ける手段と、
前記クライアントＩＤの型を含む、前記ＳＱＬ文のデータ型を生成する手段と、
複数クライアントからの全てのＳＱＬ文について異なるデータの型のみを追加して、集合したデータの型を生成する手段と、
前記集合したデータの型の順番となるように各クライアントのＳＱＬ文を変換する手段と、
前記変換後のＳＱＬ文のデータ型と変換前のＳＱＬ文のデータ型の対応関係を前記クライアントのクライアントＩＤ毎に記憶する手段と、
全ての変換後のＳＱＬ文を集合演算子を用いて集約してデータベースに送信する手段、
である、請求項９のシステム。
【請求項１１】
前記システムが、さらに
前記データベースから前記集約トランザクションに対する結果を受信する手段、
を有する、請求項１０記載のシステム。
【請求項１２】
前記システムが、さらに
前記結果を前記複数クライアントの各々トランザクションに対する照会結果に分割して送信する手段、
を有する、請求項１１記載のシステム。
【請求項１３】
前記分割して送信する手段が、
データベースから送信された結果からクライアントＩＤを判断する手段と、
前記記憶した前記変換後のＳＱＬのデータ型と変換前のデータ型の対応関係に基づき、前記クライアントＩＤ毎に、変換前のＳＱＬ文に対する照会結果に変換する手段と、
前記クライアントＩＤを有するクライアントに照会結果を送信する手段、
である、請求項１２記載のシステム。
【請求項１４】
前記システムが、さらに、
前記集約トランザクションで、クライアントが集約トランザクション経由で照会したデータを更新する手段であって、
更新するデータが、集約トランザクションとして照会したかを判断する手段と、
集約トランザクションとして照会している場合、集約トランザクション経由で処理した照会クエリを、直接トランザクションとして、データベースに処理要求する手段と、
前記クライアントからのコミット要求に応じて、更新するデータの更新クエリを直接トランザクションとして、データベースに処理要求する手段、
を有する、請求項８記載のシステム。
【請求項１５】
請求項１〜７記載の何れか１つに記載の方法の各ステップを、コンピュータに実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【公開番号】特開２０１２−１４５０２（Ｐ２０１２−１４５０２Ａ）
【公開日】平成２４年１月１９日（２０１２．１．１９）
【国際特許分類】
【出願番号】特願２０１０−１５０９８９（Ｐ２０１０−１５０９８９）
【出願日】平成２２年７月１日（２０１０．７．１）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公開日】平成２４年１月１９日（２０１２．１．１９）
【国際特許分類】
【出願日】平成２２年７月１日（２０１０．７．１）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]