データ変換方法、その装置およびそのプログラム
【課題】データベースを変換する際に、適切に変換されなかったＳＱＬ文を抽出することを可能にするデータ処理方法を提供する。
【解決手段】変換検証装置１１７では、Ａｃｃｅｓｓデータベースシステム１１１で処理するプログラムに、ＳＱＬ文を抽出するコードを挿入し、実行時にＳＱＬ文を自動的に抽出し、ＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３で処理されるＳＱＬ文に変換する。そして、Ａｃｃｅｓｓデータベースシステム１１１とＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３とでＳＱＬ文を実行させて、結果を比較し、結果が不一致のＳＱＬ文を特定する。
【解決手段】変換検証装置１１７では、Ａｃｃｅｓｓデータベースシステム１１１で処理するプログラムに、ＳＱＬ文を抽出するコードを挿入し、実行時にＳＱＬ文を自動的に抽出し、ＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３で処理されるＳＱＬ文に変換する。そして、Ａｃｃｅｓｓデータベースシステム１１１とＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３とでＳＱＬ文を実行させて、結果を比較し、結果が不一致のＳＱＬ文を特定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースシステムの移行に伴う処理を行うデータ変換方法、その装置およびそのプログラムに関する。
【背景技術】
【０００２】
事業規模の変化などに応じて、所定のデータベースシステムから他のデータベースシステムへ移行する場合がある。かかるデータベースシステムの移行に関する技術としては、例えば特許文献１に開示された技術がある。
【０００３】
特許文献１記載されているように、データベースシステムに使用可能なＳＱＬ文はシステム毎に異なっている。そこで、特許文献１のシステムにおいては、ＧＵＩ技術とＳＱＬ文自動変換処理とを連携させることによりデータベースシステムをスムーズに移行するようにしている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−３５１７１０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１において変換対象としているのはＳＱＬ文自体であるが、ＳＱＬ文のフォーマットは多様であり、その全ての構文を分析して、変換することができないという問題がある。
このような状況において、本出願人は、マイクロソフト社のＡｃｃｅｓｓ(商標)のデータベースを、ＳＱＬサーバのデータベースに変換（アップサイジング）するプログラムを提供している。
ところで、このようなプログラムの開発において、Ａｃｃｅｓｓのデータベースのなかで、適切に変換できなかったＳＱＬ文を抽出できれば、次の開発に役に立つ。
しかしながら、従来では、このように適切に変換できなかったＳＱＬ文を抽出することはできない。
【０００６】
そこで、本発明は、データベースを変換する際に、適切に変換されなかったＳＱＬ文を抽出することを可能にするデータ処理方法、その装置およびそのプログラム法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した従来技術の問題を解決し、上述した目的を達成するために、本発明の変換検証方法は、第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証する変換検証方法であって、前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する第１の工程と、前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する第２の工程と、前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行する第３の工程と、前記第３の工程における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する第４の工程とをコンピュータが実行する。
【０００８】
本発明の変換検証装置は、第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証する変換検証装置であって、前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する挿入手段程と、前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する変換結果取得手段程と、前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行するＳＱＬ実行手段と、前記ＳＱＬ実行手段における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する比較手段とを有する。
【０００９】
本発明のプログラムは、第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証するコンピュータが実行するプログラムであって、前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する第１の工程と、前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する第２の工程と、前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行する第３の工程と、前記第３の工程における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する第４の工程とを前記コンピュータに実行させる。
【図面の簡単な説明】
【００１０】
【図１】図１は、本発明の実施形態に係わるデータシステムの構成図である。
【図２】図２は、本発明の実施形態に係わる変換検証装置の構成図である。
【図３】図３は、図１および図２に示す変換検証装置の処理を説明するためのフローチャートである。
【図４】図４は、本発明の実施形態で用いられるＳＱＬ文取得テーブルの一例を説明するための図である。
【図５】図５は、ＳＱＬ文字列取得用関数呼び出し文を挿入する方法を説明するための図である。
【図６】図６は、実行結果テーブルを説明するための図である。
【図７】図７は、図１に示す変換装置の変換パターンを説明するための図である。
【図８】図８は、本発明の実施形態に係わる変換装置の機能ブロック図である。
【図９】図９は、図８に示す変換装置の処理フローを説明するための図である。
【図１０】図１０は、図８に示す変換装置の処理結果の一例である。
【図１１】図１１は、図９に示すタイプ判定ステップの詳細のフローチャートである。
【図１２】図１２は、図９に示すタイプ補正ステップの詳細のフローチャートである。
【図１３】図１３は、図８に示す変換装置の処理結果の一例である。
【図１４】図１４は、図８に示す変換装置の処理結果の一例である。
【図１５】図１５は、図８に示す変換装置の処理結果の一例である。
【図１６】図１６は、図９に示す呼び出し方法決定ステップの詳細のフローチャートである。
【図１７】図１７は、図９に示すＳＱＬ文生成ステップの詳細のフローチャートである。
【図１８】図１８は、図９に示すクエリ作成ステップの詳細のフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態に係わるデータシステムについて説明する。
図１は、本発明の実施形態に係わるデータシステム１０１の構成図である。
図１に示すように、データシステム１０１では、移行元のＡｃｃｅｓｓデータベースシステム１１１がマイロソフト社のＡｃｃｅｓｓであり、移行先のＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３が同じくマイクロソフト社のＳＱＬ Ｓｅｒｖｅｒである。
変換装置１１５は、Ａｃｃｅｓｓデータベースシステム１１１のＡｃｃｅｓｓプログラムを、ＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３で処理可能なＳＱＬ−ＳＥＲＶＥＲプログラムに変換する。
変換検証装置１１７は、変換装置１１５による上記変換が適切に行われたか否かを検証する。
なお、移行元及び移行先のデータベースシステムは、上述したものに限定されるものではない。
【００１２】
ところで、関係データベースシステムでは、クエリという、データベース管理システムに対する処理要求(問い合わせ)を文字列を用いて、データの検索や更新、削除などの命令をシステムに発行する。検索クエリでは、対象となるテーブルやデータの抽出条件、並べ方などを指定する。一度生成したクエリは保存しておいて何度も使うことができる。
関係データベースでシステムでは、クエリの記述にＳＱＬという言語を使う。
【００１３】
マイクロソフト社のＡｃｃｅｓｓ（商標）等のような汎用的な関係データべース（本発明の第１のデータベースシステムの一例）では、パフォーマンスやスケラビリティよりも、初心者でもプログラムできるように、クエリのタイプは定めていない。
一方、ＳＱＬ Ｓｅｒｖｅｒ等のより高度なデータベース（本発明の第２のデータベースシステムの一例）では、複数のクエリのタイプを用意し、それぞれのクエリについて記述方法等の制約を設けている。これは、データベースを基盤とするアプリケーションのパフォーマンスとスケーラビリティを向上させるためである。
本実施形態では、図１に示すように、マイクロソフト社のＡｃｃｅｓｓのプログラム（ＳＱＬ文）を、ＳＱＬ Ｓｅｒｖｅｒで処理可能なプログラムに変換するシステムイに用いられる変換検証装置について説明する。
【００１４】
以下、本発明の実施形態に係わる変換検証装置１１７の具体例を説明する。
図２は、本発明の実施形態に係わる変換検証装置１１７の構成図である。
図２に示すように、変換検証装置１１７は、例えば、インタフェース２１、ディスプレイ２２、操作部２３、メモリ２４および処理回路２５を有し、これらがバス２０を介して接続されている。
【００１５】
インタフェース２１は、例えば、他のコンピュータと通信を行うために用いられる。
ディスプレイ２２は、処理回路２５が実行するプログラムＰＲＧが提供する様々な画面を表示する。
【００１６】
操作部２３は、キーボードやマウス等の操作手段である。
メモリ２４は、処理回路２５が実行するプログラムＰＲＧ、処理回路２５の処理に用いられるデータを一時的に記憶する。
処理回路２５は、プログラムＰＲＧを実行して、変換検証装置１１７の処理を統括的に制御する。処理回路２５は、本実施形態のフローチャート等で記載した各処理において、処理過程でのデータを逐次メモリ２４に書き込み、それを読み出す。
本実施形態で示されるデータ変換装置１の処理は、プログラムＰＲＧに記述されている。
【００１７】
図３は、図１および図２に示す変換検証装置１１７の処理を説明するためのフローチャートである。
ステップＳＴ１１：
変換検証装置１１７の処理回路２５は、Ａｃｃｅｓｓデータベースシステム１１で処理されるＡｃｃｅｓｓのプログラムＰＲＧ−ＡのコピーのプログラムＣＰＲＧ−Ａを生成し、これをメモリ２４に書き込む。
【００１８】
ステップＳＴ１２：
処理回路２５は、メモリ２４に記憶されたプログラムＣＰＲＧ−Ａ内に、図４に示すＳＱＬ文取得テーブルデータＳＱＴを作成する。
【００１９】
ステップＳＴ１３：
処理回路２５は、プログラムＣＰＲＧ−Ａ内のオブジェクトデータを、テキストファイルデータＴＸＴに出力する。
ここで、オブジェクトデータとは、例えば、フォーム、レポート、モジュール等の機能を記述したデータである。
【００２０】
ステップＳＴ１４：
処理回路２５は、上記テキストファイルデータＴＸＴにＳＱＬ文取得関数を追加した新規テキストファイルＴＸＴＮを生成する。
具体的には、処理回路２５は、テキストファイルデータＴＸＴを開いて、当該テキストファイルデータＴＸＴＮに記載されたコードをコピーした新規テキストファイルＴＸＴＮを生成する。
そして、処理回路２５は、新規テキストファイルＴＸＴＮ内のコード（文字列）を先頭から順に読みだし、例えば、ＳＱＬ文の実行コマンドを示す図５（Ａ）に示す文字列と、その後にある図５（Ｂ）に示す文字列が存在するか否かを判断する。
そして、処理回路２５は、上記図５（Ａ），（Ｂ）に示す文字列が存在すると判断した場合に、新規テキストファイルＴＸＴの図５（Ａ）に示す文字列の行の一つ上の行に、ＳＱＬ文字列取得用関数呼び出し文を追加する。
当該ＳＱＬ文字列取得用関数呼び出し文は、実行時に、その直後にある図５（Ａ）に示す文字列に基づいて実行されたＳＱＬ文を呼び出して、ＳＱＬ文取得テーブルデータおよび実行結果テーブルに格納する。
【００２１】
ステップＳＴ１５：
処理回路２５は、プログラムＣＰＲＧ−Ａに対して新規テキストファイルＴＸＴＮを出力する。これにより、プログラムＣＰＲＧ−Ａ内に新規テキストファイルＴＸＴＮが格納される。具体的には、テキストファイルＴＸＴに対応するオブジェクトデータが、新規テキストファイルＴＸＴＮに記載されたオブジェクトデータに置き換えられる。
また、処理回路２５は、ＳＱＬ文字列取得用関数をプログラムＣＰＲＧ−Ａにエクスポート（登録）する。これにより、プログラムＣＰＲＧ−ＡでＳＱＬ文字列取得用関数が利用可能になる。
【００２２】
ステップＳＴ１６：
処理回路２５は、プログラムＣＰＲＧ−Ａの一連のオペレーション（操作）を実行する。これにより、プログラムＣＰＲＧ−Ａ内の新規テキストファイルＴＸＴＮのＳＱＬ文字列取得用関数呼び出し文が実行され、その直後にあるＳＱＬ文が抽出されてＳＱＬ文取得テーブルデータおよび実行結果テーブルデータに格納される。
【００２３】
ステップＳＴ１７：
処理回路２５は、ステップＳＴ１６で抽出されたＡｃｃｅｓｓのＳＱＬ文を、変換検証装置１１７に出力してＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３で処理可能なＳＱＬ文に変換する。そして、処理回路２５は、変換後のＳＱＬ文を、ＳＱＬ文取得テーブルデータおよび実行結果テーブルデータに格納する。
【００２４】
ステップＳＴ１８：
処理回路２５は、ステップＳＴ１６で抽出されたＡｃｃｅｓｓデータベースシステム１１のＳＱＬ文と、ステップＳＴ１７で変換したＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３で処理可能なＳＱＬ文内のＳＥＬＥＣＴ以外のＳＱＬ文をＳＥＬＥＣＴ文に変換する。当該変換については、図７〜図１８を参照して後に詳細に説明する。
【００２５】
ステップＳＴ１９：
処理回路２５は、ステップＳＴ１８で変換されたＡｃｃｅｓｓデータベースシステム１１のＳＱＬ文をＡｃｃｅｓｓデータベースシステム１１に出力して実行させる。処理回路２５は、当該実行結果をＡｃｃｅｓｓデータベースシステム１１から入力して図６に示す実行結果テーブル内の「ＭＤＢ ＳＱＬ文字列」の実行結果の各フィールドに格納する。
また、処理回路２５は、ステップＳＴ１８で変換されたＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３のＳＱＬ文をＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３に出力して実行させる。処理回路２５は、当該実行結果をＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３から入力して図６に示す実行結果テーブル内の「ＡＤＰ ＳＱＬ文字列」の実行結果の各フィールドに格納する。
【００２６】
ステップＳＴ２０：
処理回路２５は、図６に示す実行結果テーブル内で、「ＭＤＢ ＳＱＬ文字列」の実行結果と、「ＡＤＰ ＳＱＬ文字列」の実行結果とを、対応する実行結果の属性毎に比較する。
処理回路２５は、当該比較において、例えば、レコード数、フィールド数、最初のレコードのデータ値、中間のレコードのデータ値、最終のレコードのデータ値等の所定のチェック項目を比較する。
処理回路２５は、上記チェック項目のうち一つでも不一致の場合には、ＳＱＬ文取得テーブルデータＳＱＴ内の当該ＳＱＬ文に対応するレコードのフラグデータＦＬＡＧに「１」を設定する（フラグを立てる）。
また、処理回路２５は、当該不一致のＳＱＬ文について、そのＡｃｃｅｓｓのプログラムＰＲＧ−Ａの名前、モジュールライン位置、ＡｃｃｅｓｓのＳＱＬ文、ＳＱＬ ＳＥＲＶＥＲのＳＱＬ文、不具合内容を示すレポートデータを生成する。
不具合内容は、例えば、レコード数不一致、フィールド数不一致、最初のレコードのデータ値不一致、中間のレコードのデータ値不一致、最終のレコードのデータ値不一致、ＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３の実行不可能（エラー内容）等を示している。
【００２７】
ステップＳＴ２１：
処理回路２５は、図１に示すエラー修正装置１９にステップＳＴ２０で生成したレポートデータを送信する。
エラー修正装置１９は、レポートデータを基に、ＳＱＬ ＳＥＲＶＥＲのＳＱＬ文を修正する。
【００２８】
ステップＳＴ２２：
エラー修正装置１９は、ステップＳＴ２１で修正したＳＱＬ文を、例えば、ＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３に送信し、ＳＱＬ Ｓｅｒｖｅｒで処理可能なプログラムに反映させる。
【００２９】
以下、図３のステップＳＴ１８の処理の詳細について説明する。
［SELECT…INTOの場合］
変換前
SELECT
Table_1.Filed_1, Table_1.Filed_2, Table_1.Filed_3, Table_1.Filed_4, Table_1.Filed_5,
Table_1.Filed_6 INTO Table_3_Temp
FROM
Table_1;
【００３０】
変換後
SELECT
Table_1.Filed_1, Table_1.Filed_2, Table_1.Filed_3, Table_1.Filed_4,
Table_1.Filed_5, Table_1.Filed_6
FROM
Table_1;
【００３１】
［UPDATEの場合］
UPDATE
変換前
UPDATE
Table_1 INNER JOIN Table_2 ON Table_1.Filed_1 = Table_2.Filed_1 SET
Table_1.Filed_1 = "OK"
WHERE
(((Table_1.Filed_2)="ABC"));
変換後
SELECT
Table_1 INNER JOIN Table_2 ON Table_1.Filed_1 = Table_2.Filed_1
【００３２】
［DELETEの場合］
変換前
DELETE
Table_2.*
FROM
Table_2;
【００３３】
変換後
SELECT
Table_2.*
FROM
Table_2;
【００３４】
［INSERT INTOの場合］
変換前
INSERT
INTO Table_2 ( Filed_1, Filed_2, Filed_3, Filed_4, Filed_5, Filed_6 )
SELECT
Table_1.Filed_1 AS EEE, Table_1.Filed_2, Table_1.Filed_3, Table_1.Filed_4,
Table_1.Filed_5, Table_1.Filed_6
FROM
Table_1;
【００３５】
変換後
SELECT
Table_1.Filed_1 AS EEE, Table_1.Filed_2, Table_1.Filed_3, Table_1.Filed_4,
Table_1.Filed_5, Table_1.Filed_6
FROM
Table_1;
【００３６】
以上説明したように、変換検証装置１１７によれば、Ａｃｃｅｓｓデータベースシステム１１１で処理するＳＱＬ文のうち、変換装置１１５において適切に変換されなかったＳＱＬ文を自動的に抽出することができる。
そのため、適切に変換できなかったＳＱＬ文の情報を取得して、変換装置１１５の変換アルゴリズムの改良に役立てることができる。
また、データシステム１０１では、変換装置１１５で適切に変換できなかったＳＱＬ文をエラー修正装置１１９に出力することで、エラー修正処理を個別に行うことができる。
また、変換検証装置１１７では、図３のステップＳＴ１８に示すように、ＳＥＬＥＣＴ文以外をＳＥＬＥＣＴ文に変換することで、テーブルデータに対しての操作でデータ取得を行わない場合でも、当該操作に係るデータを取得して、比較処理を行うことができる。
【００３７】
以下、図１に示す変換検証装置１１７を詳細に説明する。
マイクロソフト社のＡｃｃｅｓｓ等のような汎用的な関係データべース（本発明の第１データベースシステムの一例）では、パフォーマンスやスケラビリティよりも、初心者でもプログラムできるように、クエリのタイプは定めていない。
一方、ＳＱＬ Ｓｅｒｖｅｒ等のより高度なデータベース（本発明の第２データベースシステムの一例）では、複数のクエリのタイプを用意し、それぞれのクエリについて記述方法等の制約を設けている。これは、データベースを基盤とするアプリケーションのパフォーマンスとスケーラビリティを向上させるためである。
例えば、項目の並べ替え文（ＯＲＤＥＲ ＢＹ）の有無、パラメータの有無、追加・削除・更新処理の有無、他のクエリからのネストの有無を制約条件として、下記表１に示すように組み合わせて、クエリのタイプを以下の３つに規定することである。
これらの複数のクエリは、「ビュー」、「テーブル関数」および「ストアドプロシージャ」の３タイプに分類される。
本実施形態によるデータベース移行システムは、Ａｃｃｅｓｓのクエリ（以下、元クエリとも記す）の各々に対して、その内容に基づいて適切なタイプのＳＱＬ Ｓｅｒｖｅｒのクエリ（以下、変換後クエリとも記す）に変換する。
【００３８】
【表１】
【００３９】
・「他のクエリからのネスト」→自分がだれかの子か
・「追加・削除・更新処理」→フォームからの呼び出し時に必要な機能
・「フォーム」とは画面上の入力ボックス等の起動するためのものであり、変更、削除、追加等の機能を必要とする
上述した表１において、「×」→禁止とした箇所の技術的理由を以下に示す。
【００４０】
［ビューがＯＲＤＥＲ ＢＹ句を含めない理由］
ＳＱＬ文法上は、ＯＲＤＥＲ
ＢＹ句を含めることは可能である。しかし、ビューを実行する際、データベースエンジンは最適化を行い、パフォーマンスを重視した実行プランにより実行し、並べ替えられた結果を返さない。これは、一般に並べ替え処理は、全データを走査し正しい順序で結果を返さなければいけないため、非常に高負荷な処理であるためである。様々な局面で多用されるビューに対してはパフォーマンスを優先するために、このように規定している。
これに対して、ストアドプロシージャは、最適化を行わないため、パフォーマンスは低下するが、並べ替えられた結果をそのまま返すことが可能である。
【００４１】
［ビューがパラメータを含めない理由］
ＯＲＤＥＲ ＢＹ句の理由と同様、全行走査が必要なパラメータ指定による絞り込みは、パフォーマンスの観点から禁止している。
【００４２】
［関数が追加・更新・削除できない理由］
ビューおよびストアドプロシージャから返される結果は、オリジナルのデータベース(メモリ)のテーブルの値に対して直接的に参照可能な状態で返される。つまり、返された結果を変更すると実際のデータの値が変更される。
これに対して、関数を実行する際には、データベースエンジンが内部的に一時テーブルを生成する。これは、元となるテーブルのレコードロックを回避し、他の操作に障害を与えないためである。一時テーブルに結果を挿入し、その一時テーブルを結果として返す。このため、返された結果は、テーブルの値に対して直接的な参照はできない。また、上述のように一時テーブルを介するため、常に実行時に、一時テーブルの生成と削除が繰り返されパフォーマンスは低い。
【００４３】
［ストアドプロシージャが他のクエリからのネストを禁止している理由］
ストアドプロシージャは、複数のＳＱＬ文を名前付きバッチ処理として再利用可能にするために用いられる。ストアドプロシージャの内容によっては、複数の結果を返すことも可能であり、値を返さないことも可能である。
返すデータ型がテーブルデータ型ではないため、文法上、ＳＱＬ内で結果を取得する目的で使用する(ＦＲＯＭ句の中でテーブルの様に使用する)ことは許可されていない。
すなわち、ＳＱＬ内で、ＦＲＯＭ句内でテーブルとして用いることができるのは、テーブル型の値を返すビューと関数の返り値である。
【００４４】
以下、ＳＱＬ ＳＥＲＶＥＲ（移行先データベースシステム）で規定されたクエリの３つのタイプについて説明する。
［ビュー］
ビューは、関数・ストアドプロシージャよりパフォーマンスが高い。
ビューとは，「ＦＲＯＭ」句で指定した元となるテーブルから、「ＳＥＬＥＣＴ」句で指定した項目を検索して取り出す。また、「ＷＨＥＲＥ」句で検索条件を指定できる。
【００４５】
［関数］
本実施形態において、関数とは、インラインテーブル値関数あるいは複数ステートメントテーブル値関数等のテーブル関数である。
関数は、上記表１の制約の他に、例えば、以下の特性がある。
・アクションクエリを含まない
・テーブル型の戻り値が必ずある
【００４６】
ここで、アクションクエリとは、テーブルレコードに対して削除、変更または追加の何らかのアクションを施すクエリをいう。具体的には、ＤＥＬＥＴＥ文、ＵＰＤＥＡＴＥ文、ＩＮＳＥＲＴ文、ＳＥＬＥＣＴ ＩＮＴＯ文を含むクエリをいう。
【００４７】
ＡＣＣＥＳＳ等のクエリは、常に単一のＳＱＬ文（機能記述）であるため、インラインテーブル値関数の必要十分の機能を備えている。
インラインテーブル値関数のＳＱＬ文を単一にするのは、単一のＳＱＬ文から、データの参照元(テーブルなど)、抽出条件および結果として返されるテーブル値の項目名とデータ型が決定可能だからである。
【００４８】
複数ステートメントテーブル値関数は、内部で変数を定義し、制御文（ＩＦ ＥＬＳＥ等）を行えるテーブル値関数である。インラインテーブル値関数とは異なり、複雑な制御を行える分、結果として返すテーブル値の項目名とデータ型を明示的に宣言しなければならない。
これらのテーブル値関数は、ビューに代わる強力なツールになる。テーブル値関数は、クエリ内のテーブル式またはビュー式を指定できる場所で使用できる。ビューに含めることができるのは、1 つの SELECT ステートメントだけだが、複数ステートメントテーブル値関数には、ビューで使用できるロジックより高度なロジックを使用できる追加のステートメントを含めることができる。
テーブル値関数を、単一の結果セットを返すストアドプロシージャの代わりに使用することもできる。テーブル値関数で返されるテーブルはＳＱＬステートメントのＦＲＯＭ句から参照できるが、ストアドプロシージャから返される値は、テーブル型ではないため、参照できない。
【００４９】
なお、関数は、クエリを作る可能性があり、そのクエリがフォームで参照される可能性がある。そのため、関数の子クエリを有する場合は、データ操作の可能性があると判断する。
【００５０】
［ストアドプロシージャ］
ストアドプロシージャは、上記表１の制約の他に、例えば、以下の特性を有している。
・パフォーマンス中程度
・アクションクエリを含むことが可能。アクションクエリは、ストアドしかもてない。
・戻り値の有無は任意だが、戻り値は値のみでありテーブル型ではない。
・キャッシュができる
【００５１】
ＳＱＬサーバ（データベース）は、個人データや機密データを含む。ユーザに随時許可を与えると、時として、この情報のセキュリティおよび機密性を脅かすことがある。
そのため、事実上、わずかな部分（パラメータなど）だけしか変更できない組み込みのクエリである「ストアドプロシージャ」を用いる。
ストアドプロシージャはＳＱＬ標準の基礎をなす機能であり、データベース管理者がデータベースに対して実行されるクエリを事前に決定することを可能にする、典型的なプログラミング言語における機能と類似している。このクエリ事前決定は、データベース挙動におけるより高いレベルのセキュリティおよび性能予測可能性（ｐｅｒｆｏｒｍａｎｃｅ
ｐｒｅｄｉｃｔａｂｉｌｉｔｙ）を提供することができる。リレーショナルデータベースの多くのユーザは、もっぱらストアドプロシージャに頼って、任意の（例えば随時の）クエリがデータベースによって消費され得ないようにしている。
【００５２】
ストアドプロシージャの場合は、例えば、「ＣＲＥＡＴＥ
ＰＲＯＣＥＤＵＲＥ ストアドプロシージャ名」とする。ＰＲＯＣＥＤＵＲＥというキーワードが、ストアドプロシージャ生成の指示である。ＡＳ句以降には、定義するＳＱＬ文を記述する。
ＣＲＥＡＴＥ文で生成したストアドプロシージャは、ビューと同様にデータベースサーバ上に格納される。一度定義したストアドプロシージャは、権限の設定を行えば、ほかのユーザから呼び出すことも可能である。
ＡＳ句に定義するＳＱＬ文は、ＳＥＬＥＣＴ文をはじめ、ほとんどすべてのＳＱＬ文が使用できる。また、1つのＳＱＬ文だけではなく、複数のＳＱＬ文の指定が可能である。ＳＱＬ文の実行は、基本的には定義した順番に行われるが、ほかの言語と同じように実行順を制御したり、繰り返させたりすることも可能である。
【００５３】
「データベース上に名前を付けて保存しておいたＳＥＬＥＣＴ文を呼び出す」という単純な機能においては、ストアドプロシージャはビューと同じである。ストアドプロシージャが実力を発揮するのは、ＳＱＬ
ＳＥＲＶＥＲでの実行時である。データベースにプログラムを保存しておく主な目的は、次のとおりである。
・繰り返して使用されるデータベースに対する処理を共通化して実装することによって、データの矛盾を防ぎたい
・単独のＳＥＬＥＣＴ文では処理できない複雑な条件による問い合わせを、クライアント・プログラムではなくデータベース上で実行することで、クライアントとデータベース間の通信量（トラフィック量）を抑えてレスポンスタイムを短縮化する。
一連の処理をストアドプロシージャでまとめて生成すれば、データベースへの問い合わせはストアドプロシージャを一度呼び出すだけで済む。多量の顧客からの注文を処理するシステムでは、クライアントとデータベース間での通信量を大幅に削減することが可能になる。
すなわち、ストアドプロシージャの処理は、ＳＱＬサーバ（データベースシステム）、コードを実行しながら、その間にオリジナルのデータベースのテーブルの値の追加・変更・削除をして処理を進められる。最終的な結果が出たときに、それをＳＱＬサーバからクライアントに戻す。
一方、関数で同様な処理を行おうとすると、実行中に、テーブルの追加・変更・削除はできない。
【００５４】
上述したように、ＡＣＣＥＳＳ等のような汎用的な関係データべースでは、パフォーマンスやスケラビリティよりも、初心者でもプログラムできるように、クエリのタイプは定めていない。
一方、ＳＱＬ ＳＥＲＶＥＲ等のより高度なデータベースでは、データベースを基盤とするアプリケーションのパフォーマンスとスケーラビリティを向上させるために、複数のクエリのタイプを用意し、それぞれのクエリについて記述方法等の制約を設けている。
そのため、ＡｃｃｅｓｓクエリをＳＱＬ
Ｓｅｒｖｅｒクエリへ移行する際、種々の条件を加味しながら適切なＳＱＬ Ｓｅｒｖｅｒクエリのタイプを決定していかなければならない。
【００５５】
本実施形態変換装置では、上述した表１の制約条件を基に、図７に示す変換パターンに基づいて、Ａｃｃｅｓｓで用いられていたＡｃｃｅｓｓ用ＳＱＬ文を、適切なＳＱＬ
ＳＥＲＶＥＲ用ＳＱＬに変換し、続いて、それによって生成したＳＱＬ文を用いて、ＳＱＬ ＳＥＲＶＥＲで使用可能なクエリを生成する。
図７に示す変換パターンは、上述したＳＱＬ
ＳＥＲＶＥＲクエリの表１に示す制約条件と、上述した特性に基づいて、より高いパフォーマンスと操作性を得られるように、発明者が考え出したものである。
すなわち、変換パターンは数多く考えられるが、そのなかで、図７に示す変換パターンが、パフォーマンスと操作性の面から、非常に優れている。
【００５６】
本実施形態では、移行元のデータベース内のクエリの内容を基に、移行先のデータベースのクエリのタイプを判定できるものについては、そのタイプを用いる。
また、移行元のデータベース内のクエリのうち、タイプが判定できないクエリについては「他タイプ」と判定し、いずれのタイプであっても機能が同じになるように、クエリを生成する。
【００５７】
本実施形態の変換装置では、タイプ決定ステップにおいて、移行元データベースシステム内の元クエリの子クエリが、関数タイプ、ストアドプロシージャタイプあるいは他タイプである場合に、その元クエリを他タイプと判定する。これは、その元クエリに要求される機能を必ず満たす変換後の一つのクエリを特定できないためである。
そして、当該変換装置は、他タイプあるいはストアドプロシージャタイプと判定された元クエリについては、その元クエリの機能記述と同等の機能記述を含むストアドタイプの変換後クエリを生成すると共に、その元クエリの機能記述と同等の機能記述を含む関数タイプの変換後クエリを生成する。
【００５８】
ここで、元クエリの機能記述と同等の機能記述を含むストアドタイプの変換後クエリを生成するのは、元クエリの子クエリに対しての操作性の観点の理由である。
また、元クエリの機能記述と同等の機能記述を含み関数タイプの変換後クエリを生成するのは、元クエリの親クエリが存在する可能性があるという観点の理由である。
「他タイプ」とは、処理過程において仮想的に規定されるタイプであり、移行元および移行後のデータベースシステムでは規定されていない。この他タイプは、変換後クエリを生成する生成方法を選択する条件判断に用いられる。
すなわち、他タイプと判定された元クエリ（子クエリが、テーブル関数タイプ、ストアドプロシージャタイプあるいは他タイプである場合）である対象クエリについては、子クエリに対してデータ操作（追加・削除・更新処理）の可能性があるため、これらを許可する（表1）ストアドプロシージャタイプの変換後クエリを生成する。
なお、関数は、クエリを作る可能性があり、そのクエリがフォームで参照される可能性がある。そのため、関数の子クエリを有する場合は、データ操作の可能性があると判断する。
【００５９】
また、ストアドプロシージャと判定された元クエリについては、ストアドプロシージャタイプの変換後クエリを生成する。
ここで、ストアドプロシージャタイプの変換後クエリは、他のクエリからのネスト（自分がだれかの子供になること）を禁止する(図７)。一方、この変換後クエリは、他のクエリの子となる“可能性”がある。
そのため、対象クエリの機能記述と同等の機能記述を含む関数タイプの変換後クエリを生成する。
このとき、関数タイプの変換後クエリの名称は、例えば、ストアドプロシージャタイプの変換後クエリの名称と異なるものを用いる。
これにより、他タイプと判定された元クエリである対象クエリについて、ストアドプロシージャタイプの変換後クエリと、関数タイプの変換後クエリとの２つの変換後クエリが生成されるが、下層のクエリに対してのデータ操作機能と、親クエリがある場合における関数タイプとしての機能発揮との双方を実現できる。
【００６０】
このように、ストアドプロシージャあるいは他タイプと判定されたクエリについては、親クエリが実際あるかどうかに係わらず、親クエリがある場合でも問題ないように、全ての場合において、同じ機能のストアドプロシージャタイプの変換後クエリの他に、関数タイプの変換後クエリを生成する。これにより、無駄なクエリは多くなるが、変換後のアプリケーションの拡張を想定した際、関数を手作業で生成するという非常にコストのかかる作業を大幅に軽減できる。
実際にツール開発の現場では、本実施形態の変換装置を用いたシステムにより、大幅な作業軽減が図れている。アップサイジングという総合的なアプリケーション変換(データの移行だけではなく機能性の移行)を行う際、どうしてもクエリの変換だけでは実現できない機能がある場合がある。その際には、既存のクエリを使用して新たなクエリを生成するが、ここでネスト可能な関数が生成済みかどうかで大きく作業コストが変わる。消すのは簡単だが、作るのは大変であるということに着目した技術である。
【００６１】
以下、本発明の実施形態に係わる変換装置の具体例を説明する。
図８は、本発明の実施形態に係わる変換装置１１５の機能ブロック図である。
図８に示すネスト関係特定部１１が図９に示すネスト関係特定ステップＳＱ２０１を実行し、タイプ決定部１２がタイプ決定ステップＳＱ２０２を実行し、呼び出し方法決定部１３が呼び出し方法決定ステップＳＱ２０５を実行し、ＳＱＬ文生成部１４がＳＱＬ生成ステップＳＱ２０６を実行し、クエリ生成部１５がクエリ生成ステップＳＱ２０７を実行する。
【００６２】
［ネスト関係特定ステップＳＱ２０１］
ネスト関係特定ステップＳＱ２０１は、Ａｃｃｅｓｓのクエリのネスト関係、即ち他のクエリから参照される関係にあるか否かを特定するものである。
図１０に例示される４つのクエリのネスト関係について説明すると、クエリＣはクエリＤを参照して生成され、クエリＢは当該生成されたクエリＣを参照して生成され、更にクエリＡはクエリＢを参照して生成される。
ここで、以下の説明においては、隣接する２つのクエリを例にすると、参照する方のクエリを親クエリと、その親クエリに参照される方のクエリを子クエリと表記する。
図１０の例では、クエリＣはクエリＤの親クエリであり、クエリＤはクエリＣの子クエリとなる。また、参照される側のクエリを参照する側のクエリに対して下階層にあると呼び、参照する側のクエリを参照される側のクエリに対して上階層にあると呼ぶ。
【００６３】
図１０の例では、クエリＤはクエリＣよりも下階層にあり、クエリＣはクエリＤよりも上階層にある。また、４つのクエリＡ〜クエリＤの中では、クエリＤは最下階層に位置しており、クエリＡは最上階層に位置している。本実施の形態におけるネスト関係特定ステップは、クエリ間の参照関係について、このような上階層又は下階層の位置関係も特定するものである。
【００６４】
［タイプ決定ステップＳＱ２０２］
タイプ決定ステップＳＱ２０２は、上述したネスト関係が特定されたクエリに対して、当該ネスト関係に基づいて最下階層のクエリから順に最上階層のクエリまで、各クエリに対してＳＱＬ Ｓｅｒｖｅｒで用いられるクエリの３タイプ（ビュー、関数、ストアドプロシージャ）に加え、「他タイプ」を含む計４タイプのいずれとするかを決定するものである。
上述したように、タイプ決定ステップＳＱ２０２は、タイプ判定ステップＳＱ２０３およびタイプ補正ステップＳＱ２０４を備えている。
各ステップの動作の概要としては、まず、タイプ判定ステップは各クエリを最下階層から順に上記４タイプのいずれとするかを判定し、全てのクエリの判定が終了すると、タイプ補正ステップにより当該判定された各クエリに対して必要に応じて各クエリのタイプが補正される。これにより、最終的に全てのクエリのタイプが決定する。以下、フローチャートを用いて具体的に説明する。
【００６５】
［タイプ判定ステップＳＱ２０３］
図１１は、図９に示すタイプ判定ステップＳＱ２０３の詳細のフローチャートである。
図１１に示されるように、タイプ判定ステップＳＱ２０３は、まず、対象となっているクエリが前述したアクションクエリであるか否かを判定する（ＳＱ４０１）。
対象となっているクエリがアクションクエリであると判定した場合には、当該クエリを「ストアドプロシージャ」として判定する（ＳＱ４０２）。
【００６６】
アクションクエリでない場合、ＯＲＤＥＲ ＢＹ句を含むものかどうかを判定する（ＳＱ４０３）。
ＯＲＥＤＥＲ ＢＹ句が含まれている場合は、当該クエリを「他タイプ」として判定する（ＳＱ４０４）。
ＯＲＤＥＲ ＢＹ句が含まれていない場合、当該クエリにパラメータが含まれているかどうかを判定する（ＳＱ４０５）。ここで、パラメータとは、具体的には、ＰＡＲＡＭＥＴＥＲ文を含むものや、Ａｃｃｅｓｓオブジェクトへの値参照を含むものや、直接入力パラメータを含むものを指す。
パラメータが含まれていない場合、当該クエリが子クエリを持たないか又は子クエリが「ビュー」のみかを判定し（ＳＱ４０６）、該当する場合は当該クエリを「ビュー」として判定し（ＳＱ４０７）、該当しない場合は、当該クエリを「他タイプ」として判定する（ＳＱ４０８）。
【００６７】
一方、パラメータが含まれている場合（ＳＱ４０５で「Ｙｅｓ」）、当該クエリがフォームで参照されているかどうかを判定する（ＳＱ４０９）。参照されている場合は、当該クエリを「他タイプ」として判定する（ＳＱ４０８）。参照されていない場合は、更に、当該クエリに子クエリを持たないか又は子クエリが「ビュー」のみかを判定し（ＳＱ４１０）、該当する場合は「関数」として判定する（ＳＱ４１１）。該当しない場合は当該クエリを「他タイプ」として判定する（ＳＱ４０８）。このようにして、最下階層のクエリから順に各クエリのタイプを判定し（ＳＱ４１１）する。そして、全てのクエリについての判定が完了した後（ＳＱ４１６）にタイプ補正ステップＳＱ２０４へと進む。
【００６８】
［タイプ補正ステップＳＱ２０４］
タイプ補正ステップＳＱ２０４は、上記タイプ判定ステップＳＱ２０３において判定された各クエリに対して、タイプの補正が必要なクエリに対しては適切なタイプに補正をするものである。
なお、タイプ補正ステップＳＱ２０４についても、タイプ判定ステップＳＱ２０３と同様に最下階層のクエリから順に行われるものである。
【００６９】
具体的には、図１２に示されるように、対象となるクエリのＷＨＥＲＥ句又はＨＡＶＩＮＧ句に暗黙パラメータがあるかどうかを判別する（ＳＱ５０１）。ここで、暗黙パラメータとは、入力ボックスを表示することによりユーザに対してパラメータの入力を促す処理が含まれているものを指す。
当該クエリに暗黙パラメータが含まれている場合、当該クエリのタイプを「他タイプ」に補正し（ＳＱ５０２）、当該クエリに暗黙パラメータが含まれていない場合、当該クエリのタイプは保持、即ち、上記のタイプ判定ステップで判定されたタイプを変更せずそのまま保持させる（ＳＱ５０３）。
このようにして、全てのクエリに対して処理を行ったことを確認すると（ＳＱ５０４）、再び最下階層のクエリから順番にパラメータを持つ子クエリがあるかどうかを判別する（ＳＱ５０５）。
パラメータを持つ子クエリがない場合、当該クエリのタイプはそのまま保持される（ＳＱ５０６）。一方、暗黙パラメータが発見されたことにより「他タイプ」に補正されたクエリがあった場合、それより上階層のクエリの全ては、パラメータを持つ子クエリを有することとなり、「他タイプ」に補正される（ＳＱ５０７）。
このようにして全てのクエリの補正が完了すると（ＳＱ５０８）タイプ補正ステップＳＱ２０４は終了する。
【００７０】
上記タイプ決定ステップＳＱ２０２の処理を、図１３、図１４および図１５に示されるような４つのクエリからなるＡｃｃｅｓｓのクエリを例にして説明する。
なお、図においては、クエリのタイプが既に記載されているが、実際にはタイプ決定ステップによって最下階層のクエリ（クエリＤ）からタイプが決定される。
図１３の例を説明すると、図１１に示される手順に従って、最下階層のクエリＤのタイプが判定される。
ここで、クエリＤは、アクションクエリ（ＳＱ４０１）を含まず、ＯＲＤＥＲ ＢＹ句（ＳＱ４０３）も含まず、パラメータ（ＳＱ４０５）も含まないものとする。更に、クエリＤは最下階層であるため子クエリ（ＳＱ４０６）はない。従って、この場合、クエリＤは「ビュー」と判定される（ＳＱ４０７）。
【００７１】
次に、タイプ判定ステップＳＱ２０３は、クエリＣについてタイプを判定する。クエリＣもクエリＤと同様に、アクションクエリ（ＳＱ４０１）を含まず、ＯＲＤＥＲ ＢＹ句（ＳＱ４０３）も含まず、パラメータ（ＳＱ４０５）も含まないものとする。また、クエリＣの子クエリであるクエリＤは「ビュー」（ＳＱ４０６）である。従って、クエリＣも「ビュー」と判定される（ＳＱ４０７）。
クエリＢ、クエリＡもクエリＣと同様にアクションクエリ（ＳＱ４０１）を含まず、ＯＲＤＥＲ ＢＹ句（ＳＱ４０３）も含まず、パラメータ（ＳＱ４０５）も含まないものとし、また、各クエリの子クエリは「ビュー」（ＳＱ４０６）と判定されているので、それぞれのタイプは「ビュー」と判定される。
このようにして、クエリＡ〜クエリＤまで順にタイプが判定される。
【００７２】
次に、タイプ補正ステップＳＱ２０４に進み、クエリＤからクエリＡまで順に図１２に示される手順に従って処理が実行される。
今回の場合、全てのクエリにも暗黙パラメータがないとすると（ＳＱ５０１）、全てのクエリのタイプは「ビュー」のまま保持される（ＳＱ５０３、５０４、５０５、５０７、５０８）。
次に、例えば、図１４に示されるように、クエリＤは「ビュー」と判定され、クエリＣの判定段階において、クエリＣが、アクションクエリを含まず（ＳＱ４０１）、ＯＲＤＥＲ ＢＹ句も含まないが、パラメータを有する（ＳＱ４０５）ものであって、フォームで参照（ＳＱ４０９）されていないとする。
【００７３】
また、クエリＣの子クエリであるクエリＤは「ビュー」である（ＳＱ４１０）ため、クエリＣは「関数」として判定されることとなる（ＳＱ４１１）。
続いて、クエリＢは、アクションクエリ（ＳＱ４０１）を含まず、ＯＲＤＥＲ ＢＹ句（ＳＱ４０３）も含まず、パラメータ（ＳＱ４０５）も含まないものであるが、子クエリであるクエリＣがパラメータを含んでいるものであるため（ＳＱ４０６）、「他タイプ」として判定される（ＳＱ４０８）。
同様に、クエリＡについても、アクションクエリ（ＳＱ４０１）を含まず、ＯＲＤＥＲ ＢＹ句（ＳＱ４０３）も含まず、パラメータ（ＳＱ４０５）も含まないものであるが、子クエリであるクエリＣがパラメータを含んでいるものであるため（ＳＱ４０６）、「他タイプ」として判定される（ＳＱ４０８）。
【００７４】
次に、タイプ補正ステップＳＱ２０４に進み、クエリＤからクエリＡへと順に図１２に示される手順に従って処理が実行される。
今回の場合、全てのクエリにも暗黙パラメータがないとすると（ＳＱ５０１）、クエリＣ及びクエリＤについては、クエリのタイプはそのまま保持され（ＳＱ５０３、５０４、５０５、５０７、５０８）、クエリＡ及びクエリＢについては、子クエリであるクエリＣがパラメータを持つので、処理上は「他タイプ」に補正される（ＳＱ５０６）。
なお、クエリＡ及びクエリＢは元々「他タイプ」と判定されているため、タイプには変更はない。
【００７５】
次に、暗黙パラメータが含まれ他クエリを有する一連のクエリのタイプ決定について説明する。
図１５に示されるように、タイプ判定ステップＳＱ２０３においては、全てのクエリについて「ビュー」と判定された後、タイプ補正ステップＳＱ２０４でクエリＣが対象となっている段階を例にする。この例では、図１２に示されるように、クエリＣは、暗黙パラメータを有するため（ＳＱ５０１）、タイプを「ビュー」から「他タイプ」に補正される（ＳＱ５０２）。
【００７６】
クエリＡ及びクエリＢについては暗黙パラメータはないとすると、これらのタイプは「ビュー」のまま保持される（ＳＱ５０３）。
しかし、クエリＣにパラメータが含まれていたため、クエリＡ及びクエリＢは、パラメータを持つ子クエリを有することとなったため（ＳＱ５０５）、「他タイプ」へと補正される（ＳＱ５０７）こととなる。なお、図１４の例から理解されるように、「関数」又は「ストアド」と判定されたクエリよりも上階層のクエリについては、アクションクエリを含むクエリ以外については、図１１において必然的に、ＳＱ４０３で「Ｙｅｓ」、ＳＱ４０６で「Ｎｏ」、ＳＱ４０９で「Ｙｅｓ」、又はＳＱ４１０で「Ｎｏ」のいずれかとなるため、すべては「他タイプ」として判定される。
従って、タイプ判定ステップＳＱ２０３によって、最初に「関数」又は「ストアド」と判定されたクエリよりも上階層であって、アクションクエリでないことが判定された段階で「他タイプ」として判定することとしてもよい。
【００７７】
［呼び出し方法決定ステップＳＱ２０５］
呼び出し方法決定ステップＳＱ２０５によって、４つクエリのタイプに変換されたＡｃｃｅｓｓのクエリのすべてについて、子クエリとして呼び出される場合の呼び出し方法が決定される。
図１６に示されるように、呼び出し方法決定ステップＳＱ２０５は、各クエリに対して、アクションクエリを含むかどうか判別し（ＳＱ９０１）、アクションクエリを含む場合はなにもしない（ＳＱ９０２）。アクションクエリを含まない場合、タイプが「ビュー」であるかどうか判別する（ＳＱ９０３）。
「ビュー」である場合、オリジナルクエリ名、即ちＡｃｃｅｓｓで用いられていたものと同一のクエリ名で当該クエリを呼び出すことする（ＳＱ９０４）。
タイプが「ビュー」でない場合であって、タイプが「関数」である場合は（ＳＱ９０５）、オリジナルクエリ名で及びパラメータの形式で呼び出す（ＳＱ９０６）。
更に、タイプが「関数」でない場合であって、パラメータがある場合（ＳＱ９０７）は、オリジナルクエリ名とは別のクエリ名及びパラメータの形式で呼び出す（ＳＱ９０８）。
また、パラメータがない場合は、オリジナルクエリ名とは別のクエリ名のみで呼び出すこととする（ＳＱ９０９）。このようにして、各クエリが子クエリとして呼び出される際の呼び出し方法（呼び出し名）が決定される。
【００７８】
［ＳＱＬ文生成ステップＳＱ２０６］
Ａｃｃｅｓｓで用いられていたＡｃｃｅｓｓ用ＳＱＬ文に基づいて、適切なＳＱＬ Ｓｅｒｖｅｒ用ＳＱＬを生成するＳＱＬ文生成ステップＳＱ２０６について説明する。
ＳＱＬ文生成ステップＳＱ２０６は、適切なＳＱＬ Ｓｅｒｖｅｒ用ＳＱＬを生成する際に、対象となるクエリの記述に子クエリを呼び出すための記述（呼び出し方法）が含まれていた場合、必要に応じて上述した呼び出し方法決定ステップＳＱ２０５によって決定された呼び出し方法で当該記述を置換する。
【００７９】
図１７に示されるように、ＳＱＬ文生成ステップＳＱ２０６は、対象クエリのＡｃｃｅｓｓＳＱＬをＳＱＬＳｅｒｖｅｒ用ＳＱＬに変換する（ＳＱ１００１）。
ここで、対象となるクエリが子クエリを有するか判断し（ＳＱ１００２）、子クエリを有する場合、各子クエリに対して、変換されたＳＱＬ文の置換処理を開始する（ＳＱ１００３）。
ここで、子クエリが「ビュー」であるか否かを判別し（ＳＱ１００４）、「ビュー」であった場合、置換処理は何も行わず次のクエリの判別に進む（ＳＱ１００５）。
一方、対象となっているクエリの子クエリが「ビュー」以外であった場合、生成したＳＱＬ文内の当該子クエリ名の記述を当該子クエリのタイプに応じて上述した呼び出し方法決定ステップＳＱ２０５で決定した呼び出し方法に従って置換する。（ＳＱ１００６）このようにして、全ての子クエリにいて適切な置換処理が完了すると、ＳＱＬ文生成ステップＳＱ２０６は終了する。
【００８０】
［クエリ生成ステップＳＱ２０７］
クエリ生成ステップＳＱ２０７は、上述したＳＱＬ分生成ステップＳＱ２０６よって生成したＳＱＬ文を用いて、ＳＱＬ Ｓｅｖｅｒで使用可能なクエリを生成する。図１７に示されるように、クエリ生成ステップＳＱ２０７は、対象とするクエリがアクションクエリを含むかどうか判別する（ＳＱ１１０１）。
アクションクエリを含む場合は、オリジナルクエリ名でストアドプロシージャ（アクションクエリ）を生成する（ＳＱ１１０２）。
アクションクエリを含まない場合、タイプが「ビュー」であるかどうかを判別し（ＳＱ１１０３）、タイプが「ビュー」である場合はオリジナルクエリ名でビューを生成する（ＳＱ１１０４）。
タイプが「ビュー」でない場合、タイプが「関数」であるかどうか判別し（ＳＱ１１０５）、「関数」である場合は、オリジナルクエリ名に関数を生成する。
一方、「関数」でない場合は、オリジナルクエリ名にてストアドプロシージャを生成すると共に（ＳＱ１１０７）、別名関数名にてインラインテーブル関数を生成する（ＳＱ１１０８）
【００８１】
以上説明したように、本実施形態によれば、移行先のデータベースシステムが機能することを確保しつつ移行時におけるクエリタイプの判断処理を簡略化して処理コストをできるだけ抑えることができる。
上述したように、ストアドプロシージャあるいは他タイプと判定されたクエリについては、親クエリが実際あるかどうかに係わらず、親クエリがある場合でも問題ないように、全ての場合において、同じ機能のストアドプロシージャタイプの変換後クエリの他に、関数タイプの変換後クエリを生成する。これにより、無駄なクエリは多くなるが、変換後のアプリケーションの拡張を想定した際、関数を手作業で生成するという非常にコストのかかる作業を大幅に軽減できる。
実際にツール開発の現場では、本実施形態の変換装置を用いたシステムにより、大幅な作業軽減が図れている。アップサイジングという総合的なアプリケーション変換(データの移行だけではなく機能性の移行)を行う際、どうしてもクエリの変換だけでは実現できない機能がある場合がある。その際には、既存のクエリを使用して新たなクエリを生成するが、ここでネスト可能な関数が生成済みかどうかで大きく作業コストを低減できる。
【００８２】
なお、図８に示す変換検証装置１１７の機能は、例えば、処理回路がプログラムを実行することで実現してもよい。また、この場合に、当該処理回路が実行するプログラム、当該処理回路の処理に用いられるデータを一時的に記憶するメモリが用いられる。変換検証装置１１７の処理は、当該プログラムに記述されている。
【００８３】
本発明は上述した実施形態には限定されない。
すなわち、当業者は、本発明の技術的範囲またはその均等の範囲内において、上述した実施形態の構成要素に関し、様々な変更、コンビネーション、サブコンビネーション、並びに代替を行ってもよい。
例えば上述した実施形態では、移行元の関係データベースシステム（第１のデータベースシステム）がマイロソフト社のＡｃｃｅｓｓであり、移行先のデータベースシステム（第２のデータベースシステム）が同じくマイクロソフト社のＳＱＬ Ｓｅｒｖｅｒである場合を例にして、本実施形態のデータ変換装置を説明した。
本発明の上述した請求項１等の記載した機能を持つものあれば移行先および移行元のデータベースシステムは特に限定されない。
【符号の説明】
【００８４】
１１…ネスト関係特定部
１２…タイプ決定部
１３…呼び出し方法決定部
１４…ＳＱＬ文生成部
１５…クエリ生成部
１０１…データシステム
１１１…Ａｃｃｅｓｓデータベースシステム
１１３…ＳＱＬ−ＳＥＲＶＥＲデータベースシステム
１１５…変換装置
１１７…変換検証装置
【技術分野】
【０００１】
本発明は、データベースシステムの移行に伴う処理を行うデータ変換方法、その装置およびそのプログラムに関する。
【背景技術】
【０００２】
事業規模の変化などに応じて、所定のデータベースシステムから他のデータベースシステムへ移行する場合がある。かかるデータベースシステムの移行に関する技術としては、例えば特許文献１に開示された技術がある。
【０００３】
特許文献１記載されているように、データベースシステムに使用可能なＳＱＬ文はシステム毎に異なっている。そこで、特許文献１のシステムにおいては、ＧＵＩ技術とＳＱＬ文自動変換処理とを連携させることによりデータベースシステムをスムーズに移行するようにしている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−３５１７１０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１において変換対象としているのはＳＱＬ文自体であるが、ＳＱＬ文のフォーマットは多様であり、その全ての構文を分析して、変換することができないという問題がある。
このような状況において、本出願人は、マイクロソフト社のＡｃｃｅｓｓ(商標)のデータベースを、ＳＱＬサーバのデータベースに変換（アップサイジング）するプログラムを提供している。
ところで、このようなプログラムの開発において、Ａｃｃｅｓｓのデータベースのなかで、適切に変換できなかったＳＱＬ文を抽出できれば、次の開発に役に立つ。
しかしながら、従来では、このように適切に変換できなかったＳＱＬ文を抽出することはできない。
【０００６】
そこで、本発明は、データベースを変換する際に、適切に変換されなかったＳＱＬ文を抽出することを可能にするデータ処理方法、その装置およびそのプログラム法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した従来技術の問題を解決し、上述した目的を達成するために、本発明の変換検証方法は、第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証する変換検証方法であって、前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する第１の工程と、前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する第２の工程と、前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行する第３の工程と、前記第３の工程における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する第４の工程とをコンピュータが実行する。
【０００８】
本発明の変換検証装置は、第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証する変換検証装置であって、前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する挿入手段程と、前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する変換結果取得手段程と、前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行するＳＱＬ実行手段と、前記ＳＱＬ実行手段における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する比較手段とを有する。
【０００９】
本発明のプログラムは、第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証するコンピュータが実行するプログラムであって、前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する第１の工程と、前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する第２の工程と、前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行する第３の工程と、前記第３の工程における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する第４の工程とを前記コンピュータに実行させる。
【図面の簡単な説明】
【００１０】
【図１】図１は、本発明の実施形態に係わるデータシステムの構成図である。
【図２】図２は、本発明の実施形態に係わる変換検証装置の構成図である。
【図３】図３は、図１および図２に示す変換検証装置の処理を説明するためのフローチャートである。
【図４】図４は、本発明の実施形態で用いられるＳＱＬ文取得テーブルの一例を説明するための図である。
【図５】図５は、ＳＱＬ文字列取得用関数呼び出し文を挿入する方法を説明するための図である。
【図６】図６は、実行結果テーブルを説明するための図である。
【図７】図７は、図１に示す変換装置の変換パターンを説明するための図である。
【図８】図８は、本発明の実施形態に係わる変換装置の機能ブロック図である。
【図９】図９は、図８に示す変換装置の処理フローを説明するための図である。
【図１０】図１０は、図８に示す変換装置の処理結果の一例である。
【図１１】図１１は、図９に示すタイプ判定ステップの詳細のフローチャートである。
【図１２】図１２は、図９に示すタイプ補正ステップの詳細のフローチャートである。
【図１３】図１３は、図８に示す変換装置の処理結果の一例である。
【図１４】図１４は、図８に示す変換装置の処理結果の一例である。
【図１５】図１５は、図８に示す変換装置の処理結果の一例である。
【図１６】図１６は、図９に示す呼び出し方法決定ステップの詳細のフローチャートである。
【図１７】図１７は、図９に示すＳＱＬ文生成ステップの詳細のフローチャートである。
【図１８】図１８は、図９に示すクエリ作成ステップの詳細のフローチャートである。
【発明を実施するための形態】
【００１１】
以下、本発明の実施形態に係わるデータシステムについて説明する。
図１は、本発明の実施形態に係わるデータシステム１０１の構成図である。
図１に示すように、データシステム１０１では、移行元のＡｃｃｅｓｓデータベースシステム１１１がマイロソフト社のＡｃｃｅｓｓであり、移行先のＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３が同じくマイクロソフト社のＳＱＬ Ｓｅｒｖｅｒである。
変換装置１１５は、Ａｃｃｅｓｓデータベースシステム１１１のＡｃｃｅｓｓプログラムを、ＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３で処理可能なＳＱＬ−ＳＥＲＶＥＲプログラムに変換する。
変換検証装置１１７は、変換装置１１５による上記変換が適切に行われたか否かを検証する。
なお、移行元及び移行先のデータベースシステムは、上述したものに限定されるものではない。
【００１２】
ところで、関係データベースシステムでは、クエリという、データベース管理システムに対する処理要求(問い合わせ)を文字列を用いて、データの検索や更新、削除などの命令をシステムに発行する。検索クエリでは、対象となるテーブルやデータの抽出条件、並べ方などを指定する。一度生成したクエリは保存しておいて何度も使うことができる。
関係データベースでシステムでは、クエリの記述にＳＱＬという言語を使う。
【００１３】
マイクロソフト社のＡｃｃｅｓｓ（商標）等のような汎用的な関係データべース（本発明の第１のデータベースシステムの一例）では、パフォーマンスやスケラビリティよりも、初心者でもプログラムできるように、クエリのタイプは定めていない。
一方、ＳＱＬ Ｓｅｒｖｅｒ等のより高度なデータベース（本発明の第２のデータベースシステムの一例）では、複数のクエリのタイプを用意し、それぞれのクエリについて記述方法等の制約を設けている。これは、データベースを基盤とするアプリケーションのパフォーマンスとスケーラビリティを向上させるためである。
本実施形態では、図１に示すように、マイクロソフト社のＡｃｃｅｓｓのプログラム（ＳＱＬ文）を、ＳＱＬ Ｓｅｒｖｅｒで処理可能なプログラムに変換するシステムイに用いられる変換検証装置について説明する。
【００１４】
以下、本発明の実施形態に係わる変換検証装置１１７の具体例を説明する。
図２は、本発明の実施形態に係わる変換検証装置１１７の構成図である。
図２に示すように、変換検証装置１１７は、例えば、インタフェース２１、ディスプレイ２２、操作部２３、メモリ２４および処理回路２５を有し、これらがバス２０を介して接続されている。
【００１５】
インタフェース２１は、例えば、他のコンピュータと通信を行うために用いられる。
ディスプレイ２２は、処理回路２５が実行するプログラムＰＲＧが提供する様々な画面を表示する。
【００１６】
操作部２３は、キーボードやマウス等の操作手段である。
メモリ２４は、処理回路２５が実行するプログラムＰＲＧ、処理回路２５の処理に用いられるデータを一時的に記憶する。
処理回路２５は、プログラムＰＲＧを実行して、変換検証装置１１７の処理を統括的に制御する。処理回路２５は、本実施形態のフローチャート等で記載した各処理において、処理過程でのデータを逐次メモリ２４に書き込み、それを読み出す。
本実施形態で示されるデータ変換装置１の処理は、プログラムＰＲＧに記述されている。
【００１７】
図３は、図１および図２に示す変換検証装置１１７の処理を説明するためのフローチャートである。
ステップＳＴ１１：
変換検証装置１１７の処理回路２５は、Ａｃｃｅｓｓデータベースシステム１１で処理されるＡｃｃｅｓｓのプログラムＰＲＧ−ＡのコピーのプログラムＣＰＲＧ−Ａを生成し、これをメモリ２４に書き込む。
【００１８】
ステップＳＴ１２：
処理回路２５は、メモリ２４に記憶されたプログラムＣＰＲＧ−Ａ内に、図４に示すＳＱＬ文取得テーブルデータＳＱＴを作成する。
【００１９】
ステップＳＴ１３：
処理回路２５は、プログラムＣＰＲＧ−Ａ内のオブジェクトデータを、テキストファイルデータＴＸＴに出力する。
ここで、オブジェクトデータとは、例えば、フォーム、レポート、モジュール等の機能を記述したデータである。
【００２０】
ステップＳＴ１４：
処理回路２５は、上記テキストファイルデータＴＸＴにＳＱＬ文取得関数を追加した新規テキストファイルＴＸＴＮを生成する。
具体的には、処理回路２５は、テキストファイルデータＴＸＴを開いて、当該テキストファイルデータＴＸＴＮに記載されたコードをコピーした新規テキストファイルＴＸＴＮを生成する。
そして、処理回路２５は、新規テキストファイルＴＸＴＮ内のコード（文字列）を先頭から順に読みだし、例えば、ＳＱＬ文の実行コマンドを示す図５（Ａ）に示す文字列と、その後にある図５（Ｂ）に示す文字列が存在するか否かを判断する。
そして、処理回路２５は、上記図５（Ａ），（Ｂ）に示す文字列が存在すると判断した場合に、新規テキストファイルＴＸＴの図５（Ａ）に示す文字列の行の一つ上の行に、ＳＱＬ文字列取得用関数呼び出し文を追加する。
当該ＳＱＬ文字列取得用関数呼び出し文は、実行時に、その直後にある図５（Ａ）に示す文字列に基づいて実行されたＳＱＬ文を呼び出して、ＳＱＬ文取得テーブルデータおよび実行結果テーブルに格納する。
【００２１】
ステップＳＴ１５：
処理回路２５は、プログラムＣＰＲＧ−Ａに対して新規テキストファイルＴＸＴＮを出力する。これにより、プログラムＣＰＲＧ−Ａ内に新規テキストファイルＴＸＴＮが格納される。具体的には、テキストファイルＴＸＴに対応するオブジェクトデータが、新規テキストファイルＴＸＴＮに記載されたオブジェクトデータに置き換えられる。
また、処理回路２５は、ＳＱＬ文字列取得用関数をプログラムＣＰＲＧ−Ａにエクスポート（登録）する。これにより、プログラムＣＰＲＧ−ＡでＳＱＬ文字列取得用関数が利用可能になる。
【００２２】
ステップＳＴ１６：
処理回路２５は、プログラムＣＰＲＧ−Ａの一連のオペレーション（操作）を実行する。これにより、プログラムＣＰＲＧ−Ａ内の新規テキストファイルＴＸＴＮのＳＱＬ文字列取得用関数呼び出し文が実行され、その直後にあるＳＱＬ文が抽出されてＳＱＬ文取得テーブルデータおよび実行結果テーブルデータに格納される。
【００２３】
ステップＳＴ１７：
処理回路２５は、ステップＳＴ１６で抽出されたＡｃｃｅｓｓのＳＱＬ文を、変換検証装置１１７に出力してＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３で処理可能なＳＱＬ文に変換する。そして、処理回路２５は、変換後のＳＱＬ文を、ＳＱＬ文取得テーブルデータおよび実行結果テーブルデータに格納する。
【００２４】
ステップＳＴ１８：
処理回路２５は、ステップＳＴ１６で抽出されたＡｃｃｅｓｓデータベースシステム１１のＳＱＬ文と、ステップＳＴ１７で変換したＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３で処理可能なＳＱＬ文内のＳＥＬＥＣＴ以外のＳＱＬ文をＳＥＬＥＣＴ文に変換する。当該変換については、図７〜図１８を参照して後に詳細に説明する。
【００２５】
ステップＳＴ１９：
処理回路２５は、ステップＳＴ１８で変換されたＡｃｃｅｓｓデータベースシステム１１のＳＱＬ文をＡｃｃｅｓｓデータベースシステム１１に出力して実行させる。処理回路２５は、当該実行結果をＡｃｃｅｓｓデータベースシステム１１から入力して図６に示す実行結果テーブル内の「ＭＤＢ ＳＱＬ文字列」の実行結果の各フィールドに格納する。
また、処理回路２５は、ステップＳＴ１８で変換されたＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３のＳＱＬ文をＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３に出力して実行させる。処理回路２５は、当該実行結果をＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３から入力して図６に示す実行結果テーブル内の「ＡＤＰ ＳＱＬ文字列」の実行結果の各フィールドに格納する。
【００２６】
ステップＳＴ２０：
処理回路２５は、図６に示す実行結果テーブル内で、「ＭＤＢ ＳＱＬ文字列」の実行結果と、「ＡＤＰ ＳＱＬ文字列」の実行結果とを、対応する実行結果の属性毎に比較する。
処理回路２５は、当該比較において、例えば、レコード数、フィールド数、最初のレコードのデータ値、中間のレコードのデータ値、最終のレコードのデータ値等の所定のチェック項目を比較する。
処理回路２５は、上記チェック項目のうち一つでも不一致の場合には、ＳＱＬ文取得テーブルデータＳＱＴ内の当該ＳＱＬ文に対応するレコードのフラグデータＦＬＡＧに「１」を設定する（フラグを立てる）。
また、処理回路２５は、当該不一致のＳＱＬ文について、そのＡｃｃｅｓｓのプログラムＰＲＧ−Ａの名前、モジュールライン位置、ＡｃｃｅｓｓのＳＱＬ文、ＳＱＬ ＳＥＲＶＥＲのＳＱＬ文、不具合内容を示すレポートデータを生成する。
不具合内容は、例えば、レコード数不一致、フィールド数不一致、最初のレコードのデータ値不一致、中間のレコードのデータ値不一致、最終のレコードのデータ値不一致、ＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３の実行不可能（エラー内容）等を示している。
【００２７】
ステップＳＴ２１：
処理回路２５は、図１に示すエラー修正装置１９にステップＳＴ２０で生成したレポートデータを送信する。
エラー修正装置１９は、レポートデータを基に、ＳＱＬ ＳＥＲＶＥＲのＳＱＬ文を修正する。
【００２８】
ステップＳＴ２２：
エラー修正装置１９は、ステップＳＴ２１で修正したＳＱＬ文を、例えば、ＳＱＬ−ＳＥＲＶＥＲデータベースシステム１１３に送信し、ＳＱＬ Ｓｅｒｖｅｒで処理可能なプログラムに反映させる。
【００２９】
以下、図３のステップＳＴ１８の処理の詳細について説明する。
［SELECT…INTOの場合］
変換前
SELECT
Table_1.Filed_1, Table_1.Filed_2, Table_1.Filed_3, Table_1.Filed_4, Table_1.Filed_5,
Table_1.Filed_6 INTO Table_3_Temp
FROM
Table_1;
【００３０】
変換後
SELECT
Table_1.Filed_1, Table_1.Filed_2, Table_1.Filed_3, Table_1.Filed_4,
Table_1.Filed_5, Table_1.Filed_6
FROM
Table_1;
【００３１】
［UPDATEの場合］
UPDATE
変換前
UPDATE
Table_1 INNER JOIN Table_2 ON Table_1.Filed_1 = Table_2.Filed_1 SET
Table_1.Filed_1 = "OK"
WHERE
(((Table_1.Filed_2)="ABC"));
変換後
SELECT
Table_1 INNER JOIN Table_2 ON Table_1.Filed_1 = Table_2.Filed_1
【００３２】
［DELETEの場合］
変換前
DELETE
Table_2.*
FROM
Table_2;
【００３３】
変換後
SELECT
Table_2.*
FROM
Table_2;
【００３４】
［INSERT INTOの場合］
変換前
INSERT
INTO Table_2 ( Filed_1, Filed_2, Filed_3, Filed_4, Filed_5, Filed_6 )
SELECT
Table_1.Filed_1 AS EEE, Table_1.Filed_2, Table_1.Filed_3, Table_1.Filed_4,
Table_1.Filed_5, Table_1.Filed_6
FROM
Table_1;
【００３５】
変換後
SELECT
Table_1.Filed_1 AS EEE, Table_1.Filed_2, Table_1.Filed_3, Table_1.Filed_4,
Table_1.Filed_5, Table_1.Filed_6
FROM
Table_1;
【００３６】
以上説明したように、変換検証装置１１７によれば、Ａｃｃｅｓｓデータベースシステム１１１で処理するＳＱＬ文のうち、変換装置１１５において適切に変換されなかったＳＱＬ文を自動的に抽出することができる。
そのため、適切に変換できなかったＳＱＬ文の情報を取得して、変換装置１１５の変換アルゴリズムの改良に役立てることができる。
また、データシステム１０１では、変換装置１１５で適切に変換できなかったＳＱＬ文をエラー修正装置１１９に出力することで、エラー修正処理を個別に行うことができる。
また、変換検証装置１１７では、図３のステップＳＴ１８に示すように、ＳＥＬＥＣＴ文以外をＳＥＬＥＣＴ文に変換することで、テーブルデータに対しての操作でデータ取得を行わない場合でも、当該操作に係るデータを取得して、比較処理を行うことができる。
【００３７】
以下、図１に示す変換検証装置１１７を詳細に説明する。
マイクロソフト社のＡｃｃｅｓｓ等のような汎用的な関係データべース（本発明の第１データベースシステムの一例）では、パフォーマンスやスケラビリティよりも、初心者でもプログラムできるように、クエリのタイプは定めていない。
一方、ＳＱＬ Ｓｅｒｖｅｒ等のより高度なデータベース（本発明の第２データベースシステムの一例）では、複数のクエリのタイプを用意し、それぞれのクエリについて記述方法等の制約を設けている。これは、データベースを基盤とするアプリケーションのパフォーマンスとスケーラビリティを向上させるためである。
例えば、項目の並べ替え文（ＯＲＤＥＲ ＢＹ）の有無、パラメータの有無、追加・削除・更新処理の有無、他のクエリからのネストの有無を制約条件として、下記表１に示すように組み合わせて、クエリのタイプを以下の３つに規定することである。
これらの複数のクエリは、「ビュー」、「テーブル関数」および「ストアドプロシージャ」の３タイプに分類される。
本実施形態によるデータベース移行システムは、Ａｃｃｅｓｓのクエリ（以下、元クエリとも記す）の各々に対して、その内容に基づいて適切なタイプのＳＱＬ Ｓｅｒｖｅｒのクエリ（以下、変換後クエリとも記す）に変換する。
【００３８】
【表１】
【００３９】
・「他のクエリからのネスト」→自分がだれかの子か
・「追加・削除・更新処理」→フォームからの呼び出し時に必要な機能
・「フォーム」とは画面上の入力ボックス等の起動するためのものであり、変更、削除、追加等の機能を必要とする
上述した表１において、「×」→禁止とした箇所の技術的理由を以下に示す。
【００４０】
［ビューがＯＲＤＥＲ ＢＹ句を含めない理由］
ＳＱＬ文法上は、ＯＲＤＥＲ
ＢＹ句を含めることは可能である。しかし、ビューを実行する際、データベースエンジンは最適化を行い、パフォーマンスを重視した実行プランにより実行し、並べ替えられた結果を返さない。これは、一般に並べ替え処理は、全データを走査し正しい順序で結果を返さなければいけないため、非常に高負荷な処理であるためである。様々な局面で多用されるビューに対してはパフォーマンスを優先するために、このように規定している。
これに対して、ストアドプロシージャは、最適化を行わないため、パフォーマンスは低下するが、並べ替えられた結果をそのまま返すことが可能である。
【００４１】
［ビューがパラメータを含めない理由］
ＯＲＤＥＲ ＢＹ句の理由と同様、全行走査が必要なパラメータ指定による絞り込みは、パフォーマンスの観点から禁止している。
【００４２】
［関数が追加・更新・削除できない理由］
ビューおよびストアドプロシージャから返される結果は、オリジナルのデータベース(メモリ)のテーブルの値に対して直接的に参照可能な状態で返される。つまり、返された結果を変更すると実際のデータの値が変更される。
これに対して、関数を実行する際には、データベースエンジンが内部的に一時テーブルを生成する。これは、元となるテーブルのレコードロックを回避し、他の操作に障害を与えないためである。一時テーブルに結果を挿入し、その一時テーブルを結果として返す。このため、返された結果は、テーブルの値に対して直接的な参照はできない。また、上述のように一時テーブルを介するため、常に実行時に、一時テーブルの生成と削除が繰り返されパフォーマンスは低い。
【００４３】
［ストアドプロシージャが他のクエリからのネストを禁止している理由］
ストアドプロシージャは、複数のＳＱＬ文を名前付きバッチ処理として再利用可能にするために用いられる。ストアドプロシージャの内容によっては、複数の結果を返すことも可能であり、値を返さないことも可能である。
返すデータ型がテーブルデータ型ではないため、文法上、ＳＱＬ内で結果を取得する目的で使用する(ＦＲＯＭ句の中でテーブルの様に使用する)ことは許可されていない。
すなわち、ＳＱＬ内で、ＦＲＯＭ句内でテーブルとして用いることができるのは、テーブル型の値を返すビューと関数の返り値である。
【００４４】
以下、ＳＱＬ ＳＥＲＶＥＲ（移行先データベースシステム）で規定されたクエリの３つのタイプについて説明する。
［ビュー］
ビューは、関数・ストアドプロシージャよりパフォーマンスが高い。
ビューとは，「ＦＲＯＭ」句で指定した元となるテーブルから、「ＳＥＬＥＣＴ」句で指定した項目を検索して取り出す。また、「ＷＨＥＲＥ」句で検索条件を指定できる。
【００４５】
［関数］
本実施形態において、関数とは、インラインテーブル値関数あるいは複数ステートメントテーブル値関数等のテーブル関数である。
関数は、上記表１の制約の他に、例えば、以下の特性がある。
・アクションクエリを含まない
・テーブル型の戻り値が必ずある
【００４６】
ここで、アクションクエリとは、テーブルレコードに対して削除、変更または追加の何らかのアクションを施すクエリをいう。具体的には、ＤＥＬＥＴＥ文、ＵＰＤＥＡＴＥ文、ＩＮＳＥＲＴ文、ＳＥＬＥＣＴ ＩＮＴＯ文を含むクエリをいう。
【００４７】
ＡＣＣＥＳＳ等のクエリは、常に単一のＳＱＬ文（機能記述）であるため、インラインテーブル値関数の必要十分の機能を備えている。
インラインテーブル値関数のＳＱＬ文を単一にするのは、単一のＳＱＬ文から、データの参照元(テーブルなど)、抽出条件および結果として返されるテーブル値の項目名とデータ型が決定可能だからである。
【００４８】
複数ステートメントテーブル値関数は、内部で変数を定義し、制御文（ＩＦ ＥＬＳＥ等）を行えるテーブル値関数である。インラインテーブル値関数とは異なり、複雑な制御を行える分、結果として返すテーブル値の項目名とデータ型を明示的に宣言しなければならない。
これらのテーブル値関数は、ビューに代わる強力なツールになる。テーブル値関数は、クエリ内のテーブル式またはビュー式を指定できる場所で使用できる。ビューに含めることができるのは、1 つの SELECT ステートメントだけだが、複数ステートメントテーブル値関数には、ビューで使用できるロジックより高度なロジックを使用できる追加のステートメントを含めることができる。
テーブル値関数を、単一の結果セットを返すストアドプロシージャの代わりに使用することもできる。テーブル値関数で返されるテーブルはＳＱＬステートメントのＦＲＯＭ句から参照できるが、ストアドプロシージャから返される値は、テーブル型ではないため、参照できない。
【００４９】
なお、関数は、クエリを作る可能性があり、そのクエリがフォームで参照される可能性がある。そのため、関数の子クエリを有する場合は、データ操作の可能性があると判断する。
【００５０】
［ストアドプロシージャ］
ストアドプロシージャは、上記表１の制約の他に、例えば、以下の特性を有している。
・パフォーマンス中程度
・アクションクエリを含むことが可能。アクションクエリは、ストアドしかもてない。
・戻り値の有無は任意だが、戻り値は値のみでありテーブル型ではない。
・キャッシュができる
【００５１】
ＳＱＬサーバ（データベース）は、個人データや機密データを含む。ユーザに随時許可を与えると、時として、この情報のセキュリティおよび機密性を脅かすことがある。
そのため、事実上、わずかな部分（パラメータなど）だけしか変更できない組み込みのクエリである「ストアドプロシージャ」を用いる。
ストアドプロシージャはＳＱＬ標準の基礎をなす機能であり、データベース管理者がデータベースに対して実行されるクエリを事前に決定することを可能にする、典型的なプログラミング言語における機能と類似している。このクエリ事前決定は、データベース挙動におけるより高いレベルのセキュリティおよび性能予測可能性（ｐｅｒｆｏｒｍａｎｃｅ
ｐｒｅｄｉｃｔａｂｉｌｉｔｙ）を提供することができる。リレーショナルデータベースの多くのユーザは、もっぱらストアドプロシージャに頼って、任意の（例えば随時の）クエリがデータベースによって消費され得ないようにしている。
【００５２】
ストアドプロシージャの場合は、例えば、「ＣＲＥＡＴＥ
ＰＲＯＣＥＤＵＲＥ ストアドプロシージャ名」とする。ＰＲＯＣＥＤＵＲＥというキーワードが、ストアドプロシージャ生成の指示である。ＡＳ句以降には、定義するＳＱＬ文を記述する。
ＣＲＥＡＴＥ文で生成したストアドプロシージャは、ビューと同様にデータベースサーバ上に格納される。一度定義したストアドプロシージャは、権限の設定を行えば、ほかのユーザから呼び出すことも可能である。
ＡＳ句に定義するＳＱＬ文は、ＳＥＬＥＣＴ文をはじめ、ほとんどすべてのＳＱＬ文が使用できる。また、1つのＳＱＬ文だけではなく、複数のＳＱＬ文の指定が可能である。ＳＱＬ文の実行は、基本的には定義した順番に行われるが、ほかの言語と同じように実行順を制御したり、繰り返させたりすることも可能である。
【００５３】
「データベース上に名前を付けて保存しておいたＳＥＬＥＣＴ文を呼び出す」という単純な機能においては、ストアドプロシージャはビューと同じである。ストアドプロシージャが実力を発揮するのは、ＳＱＬ
ＳＥＲＶＥＲでの実行時である。データベースにプログラムを保存しておく主な目的は、次のとおりである。
・繰り返して使用されるデータベースに対する処理を共通化して実装することによって、データの矛盾を防ぎたい
・単独のＳＥＬＥＣＴ文では処理できない複雑な条件による問い合わせを、クライアント・プログラムではなくデータベース上で実行することで、クライアントとデータベース間の通信量（トラフィック量）を抑えてレスポンスタイムを短縮化する。
一連の処理をストアドプロシージャでまとめて生成すれば、データベースへの問い合わせはストアドプロシージャを一度呼び出すだけで済む。多量の顧客からの注文を処理するシステムでは、クライアントとデータベース間での通信量を大幅に削減することが可能になる。
すなわち、ストアドプロシージャの処理は、ＳＱＬサーバ（データベースシステム）、コードを実行しながら、その間にオリジナルのデータベースのテーブルの値の追加・変更・削除をして処理を進められる。最終的な結果が出たときに、それをＳＱＬサーバからクライアントに戻す。
一方、関数で同様な処理を行おうとすると、実行中に、テーブルの追加・変更・削除はできない。
【００５４】
上述したように、ＡＣＣＥＳＳ等のような汎用的な関係データべースでは、パフォーマンスやスケラビリティよりも、初心者でもプログラムできるように、クエリのタイプは定めていない。
一方、ＳＱＬ ＳＥＲＶＥＲ等のより高度なデータベースでは、データベースを基盤とするアプリケーションのパフォーマンスとスケーラビリティを向上させるために、複数のクエリのタイプを用意し、それぞれのクエリについて記述方法等の制約を設けている。
そのため、ＡｃｃｅｓｓクエリをＳＱＬ
Ｓｅｒｖｅｒクエリへ移行する際、種々の条件を加味しながら適切なＳＱＬ Ｓｅｒｖｅｒクエリのタイプを決定していかなければならない。
【００５５】
本実施形態変換装置では、上述した表１の制約条件を基に、図７に示す変換パターンに基づいて、Ａｃｃｅｓｓで用いられていたＡｃｃｅｓｓ用ＳＱＬ文を、適切なＳＱＬ
ＳＥＲＶＥＲ用ＳＱＬに変換し、続いて、それによって生成したＳＱＬ文を用いて、ＳＱＬ ＳＥＲＶＥＲで使用可能なクエリを生成する。
図７に示す変換パターンは、上述したＳＱＬ
ＳＥＲＶＥＲクエリの表１に示す制約条件と、上述した特性に基づいて、より高いパフォーマンスと操作性を得られるように、発明者が考え出したものである。
すなわち、変換パターンは数多く考えられるが、そのなかで、図７に示す変換パターンが、パフォーマンスと操作性の面から、非常に優れている。
【００５６】
本実施形態では、移行元のデータベース内のクエリの内容を基に、移行先のデータベースのクエリのタイプを判定できるものについては、そのタイプを用いる。
また、移行元のデータベース内のクエリのうち、タイプが判定できないクエリについては「他タイプ」と判定し、いずれのタイプであっても機能が同じになるように、クエリを生成する。
【００５７】
本実施形態の変換装置では、タイプ決定ステップにおいて、移行元データベースシステム内の元クエリの子クエリが、関数タイプ、ストアドプロシージャタイプあるいは他タイプである場合に、その元クエリを他タイプと判定する。これは、その元クエリに要求される機能を必ず満たす変換後の一つのクエリを特定できないためである。
そして、当該変換装置は、他タイプあるいはストアドプロシージャタイプと判定された元クエリについては、その元クエリの機能記述と同等の機能記述を含むストアドタイプの変換後クエリを生成すると共に、その元クエリの機能記述と同等の機能記述を含む関数タイプの変換後クエリを生成する。
【００５８】
ここで、元クエリの機能記述と同等の機能記述を含むストアドタイプの変換後クエリを生成するのは、元クエリの子クエリに対しての操作性の観点の理由である。
また、元クエリの機能記述と同等の機能記述を含み関数タイプの変換後クエリを生成するのは、元クエリの親クエリが存在する可能性があるという観点の理由である。
「他タイプ」とは、処理過程において仮想的に規定されるタイプであり、移行元および移行後のデータベースシステムでは規定されていない。この他タイプは、変換後クエリを生成する生成方法を選択する条件判断に用いられる。
すなわち、他タイプと判定された元クエリ（子クエリが、テーブル関数タイプ、ストアドプロシージャタイプあるいは他タイプである場合）である対象クエリについては、子クエリに対してデータ操作（追加・削除・更新処理）の可能性があるため、これらを許可する（表1）ストアドプロシージャタイプの変換後クエリを生成する。
なお、関数は、クエリを作る可能性があり、そのクエリがフォームで参照される可能性がある。そのため、関数の子クエリを有する場合は、データ操作の可能性があると判断する。
【００５９】
また、ストアドプロシージャと判定された元クエリについては、ストアドプロシージャタイプの変換後クエリを生成する。
ここで、ストアドプロシージャタイプの変換後クエリは、他のクエリからのネスト（自分がだれかの子供になること）を禁止する(図７)。一方、この変換後クエリは、他のクエリの子となる“可能性”がある。
そのため、対象クエリの機能記述と同等の機能記述を含む関数タイプの変換後クエリを生成する。
このとき、関数タイプの変換後クエリの名称は、例えば、ストアドプロシージャタイプの変換後クエリの名称と異なるものを用いる。
これにより、他タイプと判定された元クエリである対象クエリについて、ストアドプロシージャタイプの変換後クエリと、関数タイプの変換後クエリとの２つの変換後クエリが生成されるが、下層のクエリに対してのデータ操作機能と、親クエリがある場合における関数タイプとしての機能発揮との双方を実現できる。
【００６０】
このように、ストアドプロシージャあるいは他タイプと判定されたクエリについては、親クエリが実際あるかどうかに係わらず、親クエリがある場合でも問題ないように、全ての場合において、同じ機能のストアドプロシージャタイプの変換後クエリの他に、関数タイプの変換後クエリを生成する。これにより、無駄なクエリは多くなるが、変換後のアプリケーションの拡張を想定した際、関数を手作業で生成するという非常にコストのかかる作業を大幅に軽減できる。
実際にツール開発の現場では、本実施形態の変換装置を用いたシステムにより、大幅な作業軽減が図れている。アップサイジングという総合的なアプリケーション変換(データの移行だけではなく機能性の移行)を行う際、どうしてもクエリの変換だけでは実現できない機能がある場合がある。その際には、既存のクエリを使用して新たなクエリを生成するが、ここでネスト可能な関数が生成済みかどうかで大きく作業コストが変わる。消すのは簡単だが、作るのは大変であるということに着目した技術である。
【００６１】
以下、本発明の実施形態に係わる変換装置の具体例を説明する。
図８は、本発明の実施形態に係わる変換装置１１５の機能ブロック図である。
図８に示すネスト関係特定部１１が図９に示すネスト関係特定ステップＳＱ２０１を実行し、タイプ決定部１２がタイプ決定ステップＳＱ２０２を実行し、呼び出し方法決定部１３が呼び出し方法決定ステップＳＱ２０５を実行し、ＳＱＬ文生成部１４がＳＱＬ生成ステップＳＱ２０６を実行し、クエリ生成部１５がクエリ生成ステップＳＱ２０７を実行する。
【００６２】
［ネスト関係特定ステップＳＱ２０１］
ネスト関係特定ステップＳＱ２０１は、Ａｃｃｅｓｓのクエリのネスト関係、即ち他のクエリから参照される関係にあるか否かを特定するものである。
図１０に例示される４つのクエリのネスト関係について説明すると、クエリＣはクエリＤを参照して生成され、クエリＢは当該生成されたクエリＣを参照して生成され、更にクエリＡはクエリＢを参照して生成される。
ここで、以下の説明においては、隣接する２つのクエリを例にすると、参照する方のクエリを親クエリと、その親クエリに参照される方のクエリを子クエリと表記する。
図１０の例では、クエリＣはクエリＤの親クエリであり、クエリＤはクエリＣの子クエリとなる。また、参照される側のクエリを参照する側のクエリに対して下階層にあると呼び、参照する側のクエリを参照される側のクエリに対して上階層にあると呼ぶ。
【００６３】
図１０の例では、クエリＤはクエリＣよりも下階層にあり、クエリＣはクエリＤよりも上階層にある。また、４つのクエリＡ〜クエリＤの中では、クエリＤは最下階層に位置しており、クエリＡは最上階層に位置している。本実施の形態におけるネスト関係特定ステップは、クエリ間の参照関係について、このような上階層又は下階層の位置関係も特定するものである。
【００６４】
［タイプ決定ステップＳＱ２０２］
タイプ決定ステップＳＱ２０２は、上述したネスト関係が特定されたクエリに対して、当該ネスト関係に基づいて最下階層のクエリから順に最上階層のクエリまで、各クエリに対してＳＱＬ Ｓｅｒｖｅｒで用いられるクエリの３タイプ（ビュー、関数、ストアドプロシージャ）に加え、「他タイプ」を含む計４タイプのいずれとするかを決定するものである。
上述したように、タイプ決定ステップＳＱ２０２は、タイプ判定ステップＳＱ２０３およびタイプ補正ステップＳＱ２０４を備えている。
各ステップの動作の概要としては、まず、タイプ判定ステップは各クエリを最下階層から順に上記４タイプのいずれとするかを判定し、全てのクエリの判定が終了すると、タイプ補正ステップにより当該判定された各クエリに対して必要に応じて各クエリのタイプが補正される。これにより、最終的に全てのクエリのタイプが決定する。以下、フローチャートを用いて具体的に説明する。
【００６５】
［タイプ判定ステップＳＱ２０３］
図１１は、図９に示すタイプ判定ステップＳＱ２０３の詳細のフローチャートである。
図１１に示されるように、タイプ判定ステップＳＱ２０３は、まず、対象となっているクエリが前述したアクションクエリであるか否かを判定する（ＳＱ４０１）。
対象となっているクエリがアクションクエリであると判定した場合には、当該クエリを「ストアドプロシージャ」として判定する（ＳＱ４０２）。
【００６６】
アクションクエリでない場合、ＯＲＤＥＲ ＢＹ句を含むものかどうかを判定する（ＳＱ４０３）。
ＯＲＥＤＥＲ ＢＹ句が含まれている場合は、当該クエリを「他タイプ」として判定する（ＳＱ４０４）。
ＯＲＤＥＲ ＢＹ句が含まれていない場合、当該クエリにパラメータが含まれているかどうかを判定する（ＳＱ４０５）。ここで、パラメータとは、具体的には、ＰＡＲＡＭＥＴＥＲ文を含むものや、Ａｃｃｅｓｓオブジェクトへの値参照を含むものや、直接入力パラメータを含むものを指す。
パラメータが含まれていない場合、当該クエリが子クエリを持たないか又は子クエリが「ビュー」のみかを判定し（ＳＱ４０６）、該当する場合は当該クエリを「ビュー」として判定し（ＳＱ４０７）、該当しない場合は、当該クエリを「他タイプ」として判定する（ＳＱ４０８）。
【００６７】
一方、パラメータが含まれている場合（ＳＱ４０５で「Ｙｅｓ」）、当該クエリがフォームで参照されているかどうかを判定する（ＳＱ４０９）。参照されている場合は、当該クエリを「他タイプ」として判定する（ＳＱ４０８）。参照されていない場合は、更に、当該クエリに子クエリを持たないか又は子クエリが「ビュー」のみかを判定し（ＳＱ４１０）、該当する場合は「関数」として判定する（ＳＱ４１１）。該当しない場合は当該クエリを「他タイプ」として判定する（ＳＱ４０８）。このようにして、最下階層のクエリから順に各クエリのタイプを判定し（ＳＱ４１１）する。そして、全てのクエリについての判定が完了した後（ＳＱ４１６）にタイプ補正ステップＳＱ２０４へと進む。
【００６８】
［タイプ補正ステップＳＱ２０４］
タイプ補正ステップＳＱ２０４は、上記タイプ判定ステップＳＱ２０３において判定された各クエリに対して、タイプの補正が必要なクエリに対しては適切なタイプに補正をするものである。
なお、タイプ補正ステップＳＱ２０４についても、タイプ判定ステップＳＱ２０３と同様に最下階層のクエリから順に行われるものである。
【００６９】
具体的には、図１２に示されるように、対象となるクエリのＷＨＥＲＥ句又はＨＡＶＩＮＧ句に暗黙パラメータがあるかどうかを判別する（ＳＱ５０１）。ここで、暗黙パラメータとは、入力ボックスを表示することによりユーザに対してパラメータの入力を促す処理が含まれているものを指す。
当該クエリに暗黙パラメータが含まれている場合、当該クエリのタイプを「他タイプ」に補正し（ＳＱ５０２）、当該クエリに暗黙パラメータが含まれていない場合、当該クエリのタイプは保持、即ち、上記のタイプ判定ステップで判定されたタイプを変更せずそのまま保持させる（ＳＱ５０３）。
このようにして、全てのクエリに対して処理を行ったことを確認すると（ＳＱ５０４）、再び最下階層のクエリから順番にパラメータを持つ子クエリがあるかどうかを判別する（ＳＱ５０５）。
パラメータを持つ子クエリがない場合、当該クエリのタイプはそのまま保持される（ＳＱ５０６）。一方、暗黙パラメータが発見されたことにより「他タイプ」に補正されたクエリがあった場合、それより上階層のクエリの全ては、パラメータを持つ子クエリを有することとなり、「他タイプ」に補正される（ＳＱ５０７）。
このようにして全てのクエリの補正が完了すると（ＳＱ５０８）タイプ補正ステップＳＱ２０４は終了する。
【００７０】
上記タイプ決定ステップＳＱ２０２の処理を、図１３、図１４および図１５に示されるような４つのクエリからなるＡｃｃｅｓｓのクエリを例にして説明する。
なお、図においては、クエリのタイプが既に記載されているが、実際にはタイプ決定ステップによって最下階層のクエリ（クエリＤ）からタイプが決定される。
図１３の例を説明すると、図１１に示される手順に従って、最下階層のクエリＤのタイプが判定される。
ここで、クエリＤは、アクションクエリ（ＳＱ４０１）を含まず、ＯＲＤＥＲ ＢＹ句（ＳＱ４０３）も含まず、パラメータ（ＳＱ４０５）も含まないものとする。更に、クエリＤは最下階層であるため子クエリ（ＳＱ４０６）はない。従って、この場合、クエリＤは「ビュー」と判定される（ＳＱ４０７）。
【００７１】
次に、タイプ判定ステップＳＱ２０３は、クエリＣについてタイプを判定する。クエリＣもクエリＤと同様に、アクションクエリ（ＳＱ４０１）を含まず、ＯＲＤＥＲ ＢＹ句（ＳＱ４０３）も含まず、パラメータ（ＳＱ４０５）も含まないものとする。また、クエリＣの子クエリであるクエリＤは「ビュー」（ＳＱ４０６）である。従って、クエリＣも「ビュー」と判定される（ＳＱ４０７）。
クエリＢ、クエリＡもクエリＣと同様にアクションクエリ（ＳＱ４０１）を含まず、ＯＲＤＥＲ ＢＹ句（ＳＱ４０３）も含まず、パラメータ（ＳＱ４０５）も含まないものとし、また、各クエリの子クエリは「ビュー」（ＳＱ４０６）と判定されているので、それぞれのタイプは「ビュー」と判定される。
このようにして、クエリＡ〜クエリＤまで順にタイプが判定される。
【００７２】
次に、タイプ補正ステップＳＱ２０４に進み、クエリＤからクエリＡまで順に図１２に示される手順に従って処理が実行される。
今回の場合、全てのクエリにも暗黙パラメータがないとすると（ＳＱ５０１）、全てのクエリのタイプは「ビュー」のまま保持される（ＳＱ５０３、５０４、５０５、５０７、５０８）。
次に、例えば、図１４に示されるように、クエリＤは「ビュー」と判定され、クエリＣの判定段階において、クエリＣが、アクションクエリを含まず（ＳＱ４０１）、ＯＲＤＥＲ ＢＹ句も含まないが、パラメータを有する（ＳＱ４０５）ものであって、フォームで参照（ＳＱ４０９）されていないとする。
【００７３】
また、クエリＣの子クエリであるクエリＤは「ビュー」である（ＳＱ４１０）ため、クエリＣは「関数」として判定されることとなる（ＳＱ４１１）。
続いて、クエリＢは、アクションクエリ（ＳＱ４０１）を含まず、ＯＲＤＥＲ ＢＹ句（ＳＱ４０３）も含まず、パラメータ（ＳＱ４０５）も含まないものであるが、子クエリであるクエリＣがパラメータを含んでいるものであるため（ＳＱ４０６）、「他タイプ」として判定される（ＳＱ４０８）。
同様に、クエリＡについても、アクションクエリ（ＳＱ４０１）を含まず、ＯＲＤＥＲ ＢＹ句（ＳＱ４０３）も含まず、パラメータ（ＳＱ４０５）も含まないものであるが、子クエリであるクエリＣがパラメータを含んでいるものであるため（ＳＱ４０６）、「他タイプ」として判定される（ＳＱ４０８）。
【００７４】
次に、タイプ補正ステップＳＱ２０４に進み、クエリＤからクエリＡへと順に図１２に示される手順に従って処理が実行される。
今回の場合、全てのクエリにも暗黙パラメータがないとすると（ＳＱ５０１）、クエリＣ及びクエリＤについては、クエリのタイプはそのまま保持され（ＳＱ５０３、５０４、５０５、５０７、５０８）、クエリＡ及びクエリＢについては、子クエリであるクエリＣがパラメータを持つので、処理上は「他タイプ」に補正される（ＳＱ５０６）。
なお、クエリＡ及びクエリＢは元々「他タイプ」と判定されているため、タイプには変更はない。
【００７５】
次に、暗黙パラメータが含まれ他クエリを有する一連のクエリのタイプ決定について説明する。
図１５に示されるように、タイプ判定ステップＳＱ２０３においては、全てのクエリについて「ビュー」と判定された後、タイプ補正ステップＳＱ２０４でクエリＣが対象となっている段階を例にする。この例では、図１２に示されるように、クエリＣは、暗黙パラメータを有するため（ＳＱ５０１）、タイプを「ビュー」から「他タイプ」に補正される（ＳＱ５０２）。
【００７６】
クエリＡ及びクエリＢについては暗黙パラメータはないとすると、これらのタイプは「ビュー」のまま保持される（ＳＱ５０３）。
しかし、クエリＣにパラメータが含まれていたため、クエリＡ及びクエリＢは、パラメータを持つ子クエリを有することとなったため（ＳＱ５０５）、「他タイプ」へと補正される（ＳＱ５０７）こととなる。なお、図１４の例から理解されるように、「関数」又は「ストアド」と判定されたクエリよりも上階層のクエリについては、アクションクエリを含むクエリ以外については、図１１において必然的に、ＳＱ４０３で「Ｙｅｓ」、ＳＱ４０６で「Ｎｏ」、ＳＱ４０９で「Ｙｅｓ」、又はＳＱ４１０で「Ｎｏ」のいずれかとなるため、すべては「他タイプ」として判定される。
従って、タイプ判定ステップＳＱ２０３によって、最初に「関数」又は「ストアド」と判定されたクエリよりも上階層であって、アクションクエリでないことが判定された段階で「他タイプ」として判定することとしてもよい。
【００７７】
［呼び出し方法決定ステップＳＱ２０５］
呼び出し方法決定ステップＳＱ２０５によって、４つクエリのタイプに変換されたＡｃｃｅｓｓのクエリのすべてについて、子クエリとして呼び出される場合の呼び出し方法が決定される。
図１６に示されるように、呼び出し方法決定ステップＳＱ２０５は、各クエリに対して、アクションクエリを含むかどうか判別し（ＳＱ９０１）、アクションクエリを含む場合はなにもしない（ＳＱ９０２）。アクションクエリを含まない場合、タイプが「ビュー」であるかどうか判別する（ＳＱ９０３）。
「ビュー」である場合、オリジナルクエリ名、即ちＡｃｃｅｓｓで用いられていたものと同一のクエリ名で当該クエリを呼び出すことする（ＳＱ９０４）。
タイプが「ビュー」でない場合であって、タイプが「関数」である場合は（ＳＱ９０５）、オリジナルクエリ名で及びパラメータの形式で呼び出す（ＳＱ９０６）。
更に、タイプが「関数」でない場合であって、パラメータがある場合（ＳＱ９０７）は、オリジナルクエリ名とは別のクエリ名及びパラメータの形式で呼び出す（ＳＱ９０８）。
また、パラメータがない場合は、オリジナルクエリ名とは別のクエリ名のみで呼び出すこととする（ＳＱ９０９）。このようにして、各クエリが子クエリとして呼び出される際の呼び出し方法（呼び出し名）が決定される。
【００７８】
［ＳＱＬ文生成ステップＳＱ２０６］
Ａｃｃｅｓｓで用いられていたＡｃｃｅｓｓ用ＳＱＬ文に基づいて、適切なＳＱＬ Ｓｅｒｖｅｒ用ＳＱＬを生成するＳＱＬ文生成ステップＳＱ２０６について説明する。
ＳＱＬ文生成ステップＳＱ２０６は、適切なＳＱＬ Ｓｅｒｖｅｒ用ＳＱＬを生成する際に、対象となるクエリの記述に子クエリを呼び出すための記述（呼び出し方法）が含まれていた場合、必要に応じて上述した呼び出し方法決定ステップＳＱ２０５によって決定された呼び出し方法で当該記述を置換する。
【００７９】
図１７に示されるように、ＳＱＬ文生成ステップＳＱ２０６は、対象クエリのＡｃｃｅｓｓＳＱＬをＳＱＬＳｅｒｖｅｒ用ＳＱＬに変換する（ＳＱ１００１）。
ここで、対象となるクエリが子クエリを有するか判断し（ＳＱ１００２）、子クエリを有する場合、各子クエリに対して、変換されたＳＱＬ文の置換処理を開始する（ＳＱ１００３）。
ここで、子クエリが「ビュー」であるか否かを判別し（ＳＱ１００４）、「ビュー」であった場合、置換処理は何も行わず次のクエリの判別に進む（ＳＱ１００５）。
一方、対象となっているクエリの子クエリが「ビュー」以外であった場合、生成したＳＱＬ文内の当該子クエリ名の記述を当該子クエリのタイプに応じて上述した呼び出し方法決定ステップＳＱ２０５で決定した呼び出し方法に従って置換する。（ＳＱ１００６）このようにして、全ての子クエリにいて適切な置換処理が完了すると、ＳＱＬ文生成ステップＳＱ２０６は終了する。
【００８０】
［クエリ生成ステップＳＱ２０７］
クエリ生成ステップＳＱ２０７は、上述したＳＱＬ分生成ステップＳＱ２０６よって生成したＳＱＬ文を用いて、ＳＱＬ Ｓｅｖｅｒで使用可能なクエリを生成する。図１７に示されるように、クエリ生成ステップＳＱ２０７は、対象とするクエリがアクションクエリを含むかどうか判別する（ＳＱ１１０１）。
アクションクエリを含む場合は、オリジナルクエリ名でストアドプロシージャ（アクションクエリ）を生成する（ＳＱ１１０２）。
アクションクエリを含まない場合、タイプが「ビュー」であるかどうかを判別し（ＳＱ１１０３）、タイプが「ビュー」である場合はオリジナルクエリ名でビューを生成する（ＳＱ１１０４）。
タイプが「ビュー」でない場合、タイプが「関数」であるかどうか判別し（ＳＱ１１０５）、「関数」である場合は、オリジナルクエリ名に関数を生成する。
一方、「関数」でない場合は、オリジナルクエリ名にてストアドプロシージャを生成すると共に（ＳＱ１１０７）、別名関数名にてインラインテーブル関数を生成する（ＳＱ１１０８）
【００８１】
以上説明したように、本実施形態によれば、移行先のデータベースシステムが機能することを確保しつつ移行時におけるクエリタイプの判断処理を簡略化して処理コストをできるだけ抑えることができる。
上述したように、ストアドプロシージャあるいは他タイプと判定されたクエリについては、親クエリが実際あるかどうかに係わらず、親クエリがある場合でも問題ないように、全ての場合において、同じ機能のストアドプロシージャタイプの変換後クエリの他に、関数タイプの変換後クエリを生成する。これにより、無駄なクエリは多くなるが、変換後のアプリケーションの拡張を想定した際、関数を手作業で生成するという非常にコストのかかる作業を大幅に軽減できる。
実際にツール開発の現場では、本実施形態の変換装置を用いたシステムにより、大幅な作業軽減が図れている。アップサイジングという総合的なアプリケーション変換(データの移行だけではなく機能性の移行)を行う際、どうしてもクエリの変換だけでは実現できない機能がある場合がある。その際には、既存のクエリを使用して新たなクエリを生成するが、ここでネスト可能な関数が生成済みかどうかで大きく作業コストを低減できる。
【００８２】
なお、図８に示す変換検証装置１１７の機能は、例えば、処理回路がプログラムを実行することで実現してもよい。また、この場合に、当該処理回路が実行するプログラム、当該処理回路の処理に用いられるデータを一時的に記憶するメモリが用いられる。変換検証装置１１７の処理は、当該プログラムに記述されている。
【００８３】
本発明は上述した実施形態には限定されない。
すなわち、当業者は、本発明の技術的範囲またはその均等の範囲内において、上述した実施形態の構成要素に関し、様々な変更、コンビネーション、サブコンビネーション、並びに代替を行ってもよい。
例えば上述した実施形態では、移行元の関係データベースシステム（第１のデータベースシステム）がマイロソフト社のＡｃｃｅｓｓであり、移行先のデータベースシステム（第２のデータベースシステム）が同じくマイクロソフト社のＳＱＬ Ｓｅｒｖｅｒである場合を例にして、本実施形態のデータ変換装置を説明した。
本発明の上述した請求項１等の記載した機能を持つものあれば移行先および移行元のデータベースシステムは特に限定されない。
【符号の説明】
【００８４】
１１…ネスト関係特定部
１２…タイプ決定部
１３…呼び出し方法決定部
１４…ＳＱＬ文生成部
１５…クエリ生成部
１０１…データシステム
１１１…Ａｃｃｅｓｓデータベースシステム
１１３…ＳＱＬ−ＳＥＲＶＥＲデータベースシステム
１１５…変換装置
１１７…変換検証装置
【特許請求の範囲】
【請求項１】
第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証する変換検証方法であって、
前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する第１の工程と、
前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する第２の工程と、
前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行する第３の工程と、
前記第３の工程における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する第４の工程と
をコンピュータが実行する変換検証方法。
【請求項２】
前記第３の工程は、前記第１のＳＱＬ文データおよび前記第２のＳＱＬ文データが前記テーブルデータに対する操作結果を取得するためのものではない場合に、前記第１のＳＱＬ文データおよび前記第２のＳＱＬ文データを前記操作結果あるいは操作過程のデータを取得するＳＱＬ文データに変換し、当該変換したＳＱＬ文データを実行する
請求項１に記載の変換検証方法。
【請求項３】
前記第３の工程は、前記第１のＳＱＬ文データの実行に応じて取得した第１のデータを予め決められた実行結果テーブルデータ内の所定の箇所に順次格納し、前記第２のＳＱＬ文データの実行に応じて取得した第２のデータを前記実行結果テーブルデータ内の所定の箇所に順次格納し、
前記第４の工程は、前記実行結果テーブルデータ内の前記第１のデータと前記第２のデータとを比較する
請求項２に記載の変換検証方法。
【請求項４】
前記第１の工程は、前記第１のＳＱＬ文データの実行命令文データと、その後にある前記第１のＳＱＬ文データの先頭文字列とを検出すると、前記実行命令文データの一つ上の行に前記取得操作コードを挿入する
請求項３に記載の変換検証方法。
【請求項５】
前記第４の工程の比較でデータの不一致を生じた前記第１のＳＱＬ文データおよび前記第２のＳＱＬ文データを所定のデータ処理装置に送信する第５の工程
を前記コンピュータがさらに実行する請求項４に記載の変換検証方法。
【請求項６】
前記第１のプログラムは複数の第１クエリを有し、前記第２のプログラムは複数の第２クエリを有し、
前記第１クエリは、パラメータ、データベースの値の追加・削除・更新処理、他のクエリの子クエリとなることの全てを許可しており、
第２クエリのタイプとして、
パラメータを禁止し、前記追加・削除・更新処理を許可し、他のクエリの子クエリとなることを許容するビュータイプと、
パラメータを許可し、前記追加・削除・更新処理を禁止し、他のクエリの子クエリとなることを許容する関数タイプと、
パラメータを許可し、前記追加・削除・更新処理を許可し、他のクエリの子クエリとなることを禁止するストアドプロシージャタイプが規定されている場合に、
前記第２の工程は、
変換装置のメモリから前記第１のデータベースシステムの複数の前記第１のクエリをメモリから読み出す読み出しステップと、
前記読み出した複数の第１クエリのネスト構造に基づいて、前記複数の第１のクエリの親子関係を特定するネスト関係特定ステップと、
前記親子関係に基づいて子クリエから親クエリに向けて、最下階層の前記第１クエリから最上階層の前記第１クエリまで順番に、前記第１クエリの夫々に対応する前記第２クエリのタイプを決定するタイプ決定ステップと、
前記親子関係に基づいて子クリエから親クエリに向けて、最下階層の前記第１クエリから最上階層の前記第１クエリまで順番に、前記決定されたタイプに従って前記第１クエリに対応する前記第２クエリを生成するクエリ生成ステップと
を前記変換装置の処理回路が実行し、
前記タイプ決定ステップは、
前記移行の処理過程でのみ使用される前記関数タイプ、ストアドプロシージャタイプ以外のタイプである予め規定された他タイプを用いて、
前記ネスト構造の親子関係を基に前記第１クエリの子クエリが、前記関数タイプ、ストアドプロシージャタイプあるいは前記他タイプである場合に、当該第１クエリに対応した前記第２のクリエを前記他タイプと判定する処理と、
前記第１クエリがアクションクエリではなく、パラメータを含まず、且つ、子クエリが無いまたは子クエリがビュータイプであると判定された場合に、当該第１クエリに対応する前記第２クエリはビュータイプであると判定する処理と
を前記処理回路が実行し、
前記クエリ生成ステップは、
前記タイプ決定ステップにおいて前記他タイプあるいは前記ストアドプロシージャタイプと判定された第２クエリである対象クエリについては、
当該対象クエリの機能記述と同等の機能記述を含むストアドプロシージャタイプの前記第２クエリを生成すると共に、
当該対象クエリの機能記述と同等の機能記述を含む関数タイプの前記第２クエリを生成する処理を前記処理回路が実行する
請求項１〜５のいずれかに記載の変換検証方法。
【請求項７】
第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証する変換検証装置であって、
前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する挿入手段程と、
前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する変換結果取得手段程と、
前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行するＳＱＬ実行手段と、
前記ＳＱＬ実行手段における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する比較手段と
を有する変換検証装置。
【請求項８】
第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証するコンピュータが実行するプログラムでって、
前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する第１の工程と、
前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する第２の工程と、
前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行する第３の工程と、
前記第３の工程における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する第４の工程と
を前記コンピュータに実行させるプログラム。
【請求項１】
第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証する変換検証方法であって、
前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する第１の工程と、
前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する第２の工程と、
前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行する第３の工程と、
前記第３の工程における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する第４の工程と
をコンピュータが実行する変換検証方法。
【請求項２】
前記第３の工程は、前記第１のＳＱＬ文データおよび前記第２のＳＱＬ文データが前記テーブルデータに対する操作結果を取得するためのものではない場合に、前記第１のＳＱＬ文データおよび前記第２のＳＱＬ文データを前記操作結果あるいは操作過程のデータを取得するＳＱＬ文データに変換し、当該変換したＳＱＬ文データを実行する
請求項１に記載の変換検証方法。
【請求項３】
前記第３の工程は、前記第１のＳＱＬ文データの実行に応じて取得した第１のデータを予め決められた実行結果テーブルデータ内の所定の箇所に順次格納し、前記第２のＳＱＬ文データの実行に応じて取得した第２のデータを前記実行結果テーブルデータ内の所定の箇所に順次格納し、
前記第４の工程は、前記実行結果テーブルデータ内の前記第１のデータと前記第２のデータとを比較する
請求項２に記載の変換検証方法。
【請求項４】
前記第１の工程は、前記第１のＳＱＬ文データの実行命令文データと、その後にある前記第１のＳＱＬ文データの先頭文字列とを検出すると、前記実行命令文データの一つ上の行に前記取得操作コードを挿入する
請求項３に記載の変換検証方法。
【請求項５】
前記第４の工程の比較でデータの不一致を生じた前記第１のＳＱＬ文データおよび前記第２のＳＱＬ文データを所定のデータ処理装置に送信する第５の工程
を前記コンピュータがさらに実行する請求項４に記載の変換検証方法。
【請求項６】
前記第１のプログラムは複数の第１クエリを有し、前記第２のプログラムは複数の第２クエリを有し、
前記第１クエリは、パラメータ、データベースの値の追加・削除・更新処理、他のクエリの子クエリとなることの全てを許可しており、
第２クエリのタイプとして、
パラメータを禁止し、前記追加・削除・更新処理を許可し、他のクエリの子クエリとなることを許容するビュータイプと、
パラメータを許可し、前記追加・削除・更新処理を禁止し、他のクエリの子クエリとなることを許容する関数タイプと、
パラメータを許可し、前記追加・削除・更新処理を許可し、他のクエリの子クエリとなることを禁止するストアドプロシージャタイプが規定されている場合に、
前記第２の工程は、
変換装置のメモリから前記第１のデータベースシステムの複数の前記第１のクエリをメモリから読み出す読み出しステップと、
前記読み出した複数の第１クエリのネスト構造に基づいて、前記複数の第１のクエリの親子関係を特定するネスト関係特定ステップと、
前記親子関係に基づいて子クリエから親クエリに向けて、最下階層の前記第１クエリから最上階層の前記第１クエリまで順番に、前記第１クエリの夫々に対応する前記第２クエリのタイプを決定するタイプ決定ステップと、
前記親子関係に基づいて子クリエから親クエリに向けて、最下階層の前記第１クエリから最上階層の前記第１クエリまで順番に、前記決定されたタイプに従って前記第１クエリに対応する前記第２クエリを生成するクエリ生成ステップと
を前記変換装置の処理回路が実行し、
前記タイプ決定ステップは、
前記移行の処理過程でのみ使用される前記関数タイプ、ストアドプロシージャタイプ以外のタイプである予め規定された他タイプを用いて、
前記ネスト構造の親子関係を基に前記第１クエリの子クエリが、前記関数タイプ、ストアドプロシージャタイプあるいは前記他タイプである場合に、当該第１クエリに対応した前記第２のクリエを前記他タイプと判定する処理と、
前記第１クエリがアクションクエリではなく、パラメータを含まず、且つ、子クエリが無いまたは子クエリがビュータイプであると判定された場合に、当該第１クエリに対応する前記第２クエリはビュータイプであると判定する処理と
を前記処理回路が実行し、
前記クエリ生成ステップは、
前記タイプ決定ステップにおいて前記他タイプあるいは前記ストアドプロシージャタイプと判定された第２クエリである対象クエリについては、
当該対象クエリの機能記述と同等の機能記述を含むストアドプロシージャタイプの前記第２クエリを生成すると共に、
当該対象クエリの機能記述と同等の機能記述を含む関数タイプの前記第２クエリを生成する処理を前記処理回路が実行する
請求項１〜５のいずれかに記載の変換検証方法。
【請求項７】
第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証する変換検証装置であって、
前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する挿入手段程と、
前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する変換結果取得手段程と、
前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行するＳＱＬ実行手段と、
前記ＳＱＬ実行手段における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する比較手段と
を有する変換検証装置。
【請求項８】
第１のデータベースシステムで処理される第１のプログラム内に記述された前記第１のデータベースシステムへの問い合わせ命令であるクエリを記述したＳＱＬ文データを、第２のデータベースで処理される第２のプログラム内の同じ機能のクエリを記述したＳＱＬ文データに変換した場合の前記変換を検証するコンピュータが実行するプログラムでって、
前記第１のプログラムに、当該第１のプログラム内のテーブルデータに対して操作を行う第１のＳＱＬ文データを取得する取得操作コードを挿入する第１の工程と、
前記第１のプログラムの実行過程で前記取得操作コードによって取得された前記第１のＳＱＬ文データを、前記第２のデータベースの第２のＳＱＬ文データに変換した結果を取得する第２の工程と、
前記第１のＳＱＬ文データを前記第１のデータシステムで実行し、前記第２のＳＱＬ文データを前記第２のデータベースシステムで実行する第３の工程と、
前記第３の工程における前記第１のＳＱＬ文データの処理に応じて取得したデータと、前記第２のＳＱＬ文データの処理に応じて取得したデータとを比較する第４の工程と
を前記コンピュータに実行させるプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１１−２５８００２（Ｐ２０１１−２５８００２Ａ）
【公開日】平成２３年１２月２２日（２０１１．１２．２２）
【国際特許分類】
【出願番号】特願２０１０−１３２１３９（Ｐ２０１０−１３２１３９）
【出願日】平成２２年６月９日（２０１０．６．９）
【出願人】（５０７３０２９２２）株式会社インフォース (4)
【Ｆターム（参考）】
【公開日】平成２３年１２月２２日（２０１１．１２．２２）
【国際特許分類】
【出願日】平成２２年６月９日（２０１０．６．９）
【出願人】（５０７３０２９２２）株式会社インフォース (4)
【Ｆターム（参考）】
[ Back to top ]