JP7055064B2 - データベースマイグレーション支援システム及びプログラム - Google Patents

Description

本発明は、データベースを管理・運用するための支援技術に関し、特に、データベースのマイグレーション（移行・変換）を効率的に行えるようにするデータベースマイグレーション支援システム及びプログラムに関する。

データベースは、例えば、製品変更や、機能の拡張・縮減、ハードディスク資源の交換等の理由により、現行システムを新システムに移行・切り替え（マイグレーション）することが行われる。
これまで、このようなデータベースのマイグレーションに際して、移行先のシステムにおける現行システムと同様の処理・機能を保証しつつ、データベースの移行が効率的に行われるように、各種の支援システムが提案されている。

例えば、特許文献１には、ＧＵＩを介した操作者の操作に基づき、移行元のＳＱＬ（データベース言語：Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）に対応した移行先のＳＱＬを自動で生成することにより、操作者の習熟度に依存しない、汎用性・操作性に優れたデータベースの移行方法が提案されている。
また、特許文献２には、移行元のＳＱＬを移行先のＳＱＬに変換する場合に、両者における不一致のＳＱＬ文を特定することにより、適切に変換されなかったＳＱＬ文を自動抽出するデータ変換方法が提案されている。

特開２００２－３５１７１０号公報 特開２０１１－２５８００２号公報

しかしながら、特許文献１や特許文献２に開示されている技術は、移行先の新システムに対して、新たにＳＱＬを生成することを前提としており、移行元の現在稼働中のシステムのＳＱＬを移行先に適用・発行した場合の検証や動作保証の問題については想定されてない。
データベースを新システムに移行する場合、データを記録するハードウェア資源を含むデータベース管理システム（ＤＢＭＳ：ＤＡＴＡＢＡＳＥ ＭＡＮＡＧＥＭＥＮＴ ＳＹＳＴＥＭ）は、移行先で新たな製品等を導入するものの、データの出し入れに用いるデータベース言語（ＳＱＬ）については、移行元で使用されているＳＱＬをそのまま用いることが行われる。特に、大規模なデータベースでは、新システムに対応する新たなＳＱＬを改めて一から作成することは、非常に手間やコストがかかることとなり現実的でない。

その一方で、移行元のＳＱＬを移行先にそのまま適用した場合に、移行先の動作が正しく担保されないことがある。
データベースでは、ＤＢＭＳのオプティマイザと呼ばれる「頭脳」の部分が、ＳＱＬを解釈して、ハードディスク上に論理的に記録されたデータテーブルから最適なデータ習得を行う「実行計画（プラン）」を生成する。
ところが、このオプティマイザの成熟度レベルが、製品によってマチマチな場合があり、例えば移行元で使用されていた複雑なＳＱＬを移行先にそのまま適用すると、本来とは異なる「間違った結果」が返却されるといったことが起こり得る。つまり、同じＳＱＬであっても、ＤＢＭＳ（オプティマイザ）の製品によって、正しい結果を返却できるものと、そうでないものが存在することがある。

ＳＱＬは、複雑なものであれば例えば５０行を超えるＳＱＬ文で構成され、大規模システムでは、そのようなＳＱＬが例えば１０万本近く実装されるような場合もある。
このような膨大なＳＱＬを、効率よく確実に検証して動作担保を行うことは、非常に手間と時間がかかるもので、現実には全てのＳＱＬを試験・検証することは困難乃至不可能である。
このような、移行元と移行先で同一のＳＱＬを用いる場合の動作保証や検証などの問題について、上述した特許文献１，２を含めて、有効に対処し得る従来技術は提案されていない。

本発明は、以上の課題を解決するために、データベースのマイグレーションに際して、移行先で移行元と同一のＳＱＬを使用する場合に、効率的な動作確認を行うことができるデータベースマイグレーション支援システム及びプログラムを提供することを目的とする。

上記目的を達成するため、本発明は、移行元データベースから移行先データベースへのデータベースのマイグレーションを支援するシステムであって、前記移行元データベースのデータベース管理システムに実装される、所定のデータベース言語で作成されたデータベース言語文を入力するデータベース言語入力部と、前記データベース言語入力部で入力されたデータベース言語文の文字列を分解し、所定の画像に置換して、当該データベース言語の構造図を作成する構造図作成部とを備え、前記構造図作成部で作成された構造図に基づいて、前記移行先データベースにおける前記データベース言語文の動作確認テストを実行する構成としてある。

また、本発明は、上記のような本発明に係るデータベースマイグレーション支援システムで実行されるプログラムとして構成することができる。
さらに、本発明は、上記のような本発明に係るデータベースマイグレーション支援システム及びプログラムによって実施可能な方法として実施することもできる。

本発明によれば、データベースのマイグレーションに際して、ＳＱＬを構造図化，パターン化することにより、移行先で移行元と同一のＳＱＬを使用する場合に、効率的な動作確認を行うことが可能となる。

本発明の一実施形態に係るデータベースマイグレーション支援システム（以下「本システム」という）の全体構成を模式的に示す機能ブロック図である。 本システムにおけるＳＱＬのパターン化のアルゴリズムを模式的に示す説明図である。 パターン化におけるＳＱＬの収れん処理のアルゴリズムを模式的に示す説明図である。 収れんされたＳＱＬのテスト処理のアルゴリズムを模式的に示す説明図である。 パターン化されたＳＱＬの進化処理のアルゴリズムを模式的に示す説明図である。 進化されたＳＱＬのテスト結果を示すレポート出力の一例を示す説明図である。 同じく進化されたＳＱＬのテスト結果を示すレポート出力の一例を示す説明図である。 ＳＱＬのテスト結果の表示順序を変更したレポート出力の一例を示す説明図である。 パターン化されたＳＱＬの退化処理のアルゴリズムを模式的に示す説明図である。 退化されたＳＱＬのテスト結果を示すレポート出力の一例を示す説明図である。 ＳＱＬに含まれる「ＳＥＬＥＣＴ」文の構造を示す説明図である。 同じく、「ＳＥＬＥＣＴ」文の構造を示す説明図である。 同じく、「ＳＥＬＥＣＴ」文の構造を示す説明図である。 図１１に示す「ＳＥＬＥＣＴ」文の構造を所定の構造図に置換する手法を示す説明図である。 同じく、図１２に示す「ＳＥＬＥＣＴ」文を構造図に置換する場合の説明図である。 同じく、図１３に示す「ＳＥＬＥＣＴ」文を構造図に置換する場合の説明図である。 「ＩＮＳＥＲＴ」文を構造図に置換する場合の説明図である。 同じく、「ＩＮＳＥＲＴ」文を構造図に置換する場合の説明図である。 「ＵＰＤＡＴＥ」文を構造図に置換する場合の説明図である。 「ＤＥＬＥＴＥ」文を構造図に置換する場合の説明図である。 生成された構造図をマッピングする手法を示す説明図であり、構造図が「ＳＥＬＥＣＴ」文の場合である。 同じく、「ＩＮＳＥＲＴ」文の構造図をマッピングする場合の説明図である。 マッピングされた構造図の収れん処理の手法を示す説明図である。 同じく、構造図の収れん処理の手法を示す説明図である。 同じく、構造図の収れん処理の手法を示す説明図である。 マッピングされた構造図の進化処理の手法を示す説明図である。 同じく、構造図の進化処理の手法を示す説明図である。 進化処理された構造に対応するデータを自動生成する手法と出力結果を示す説明図である。 同じく、進化処理された構造に対応するデータの自動生成の手法と出力結果を示す説明図である。 出力データを入れ替えて出力・表示させる手法を示す説明図である。 マッピングされた構造図の退化処理の手法を示す説明図である。 同じく、構造図の退化処理の手法を示す説明図である。 退化処理された構造に対応するデータの出力結果を示す説明図である。 同じく、退化処理された構造に対応するデータの出力結果を示す説明図である。 特殊関数ファイルの一例を示す説明図である。 本システムにおける移行元と移行先のＳＱＬの動作確認処理の工程を示すフローチャートである。 動作確認処理における画面表示の一例を示す説明図である。 同じく、動作確認処理における画面表示の一例を示す説明図である。 図３６の「代表パターン：ＳＱＬファイルの作成／配置」処理のフローチャートである。 図３６の「代表パターン：テストデータの投入・正解データの作成／配置」処理のフローチャートである。 図３６の「代表パターン：代表ＳＱＬの決定」処理のフローチャートである。 同じく、「代表パターン：代表ＳＱＬの決定」処理のフローチャートである。 同じく、「代表パターン：代表ＳＱＬの決定」処理のフローチャートである。 図３６の「代表パターン：テスト実施（現行保証／進化／退化）」処理のフローチャートである。 同じく、「代表パターン：テスト実施（現行保証／進化／退化）」処理のフローチャートである。 同じく、「代表パターン：テスト実施（現行保証／進化／退化）」処理のフローチャートである。 同じく、「代表パターン：テスト実施（現行保証／進化／退化）」処理のフローチャートである。 図３６の「特殊関数：代表ＳＱＬ決定」処理のフローチャートである。 図３６の「特殊関数：テスト実施」処理のフローチャートである。 図３６の「代表パターン／特殊関数：結果レポート作成」処理のフローチャートである。

以下、本発明に係るデータベースマイグレーション支援システム及びプログラムの実施形態について、図面を参照しつつ説明する。
ここで、以下に示す本発明のデータベースマイグレーション支援システムは、プログラム（ソフトウェア）の命令によりコンピュータで実行される処理，手段，機能によって実現される。プログラムは、コンピュータの各構成要素に指令を送り、以下に示す本発明に係る所定の処理や機能等を行わせることができる。すなわち、本発明における各処理や手段，機能は、プログラムとコンピュータとが協働した具体的手段によって実現される。

なお、プログラムの全部又は一部は、例えば、磁気ディスク，光ディスク，半導体メモリ，その他任意のコンピュータで読取り可能な記録媒体により提供され、記録媒体から読み出されたプログラムがコンピュータにインストールされて実行される。また、プログラムは、記録媒体を介さず、通信回線を通じて直接にコンピュータにロードし実行することもできる。
また、本システムは、単一の情報処理装置（例えば一台のパーソナルコンピュータ等）で構成することもでき、複数の情報処理装置（例えば複数台のサーバコンピュータ群等）で構成することもできる。

［システム構成］
図１に示すように、本システム１０は、移行元データベース１００から移行先データベース２００へのデータベースのマイグレーションを支援するシステムであり、所定の情報処理装置、例えば１又は２以上のサーバコンピュータ等によって構成することができる。
なお、特に図示していないが、本システム１０を構成する情報処理装置には、演算手段・記憶手段・入力手段・出力手段などのハードウェア資源、所定のアプリケーション／データなどのソフトウェア資源が備えられていることは言うまでもない。

移行元データベース１００は、現在稼動中の情報処理装置（現行稼動機）であって、対象データを記録したハードディスク等のハードウェア資源を含むデータベース管理システム（ＤＢＭＳ）と、データの出し入れに用いられる所定のデータベース言語で作成されたデータベース言語文あるＳＱＬなどによって構成されている。なお、この移行元データベース１００には、現在は稼動していないが過去に正常に稼働していたデータベース等も当然に含まれる。
移行先データベース２００は、新規に稼動を予定している情報処理装置であって、ハードウェア資源，ＤＢＭＳなどによって構成されている。この移行先データベース２００についても、過去に稼動していたデータベース等も含まれる。

ここで、移行元データベース１００と移行先データベース２００のＤＢＭＳやハードウェア構成が同一であれば、データを移行させるだけ、移行元のＳＱＬを使用することで、基本的には移行先での動作は保証されており、動作試験は確認的に行えば良いことになる。
したがって、本システム１０は、特に移行元データベース１００と移行先データベース２００において、ＤＢＭＳやハードウェア構成が異なる場合、例えば、移行元と移行先でデータベース製品が異なり、実装されているＤＢＭＳのオプティマイザの成熟度レベルに差異がある場合、ハードディスクの構成が移行先と移行元で共有ディスク型と分散ディスク型で異なっている場合、などにおけるデータベース移行支援に好適である。
但し、移行元／移行先のデータベース構成が同一の場合でも、本システム１０を適用して、移行先の動作確認や拡張・変更機能の確認などを行うことは勿論可能である。

本システム１０では、図１に示すように、現行稼動している移行元データベース１００から、実行済みのＳＱＬ情報とデータを取得して、移行先データベース２００に対してデータを入れて、同じＳＱＬが同じ結果を出力するかどうか、同じ性能で動作するか（例えばＣＰＵ・メモリ使用率・処理時間などが同じか）の稼動確認を行うようになっている。
なお、本システム１０は、移行元データベース１００と移行先データベース２００の双方と通信できる場合には、上記のような稼動確認処理を自動で実行することができる。
また、例えば移行元と移行先のデータベースが異なるシステムインテグレータ等によって提供される場合など、本システム１０が移行元データベース１００と通信できない環境にある場合には、動作確認を行うＳＱＬ／データをユーザ等が手動で用意することで、本システム１０での稼動確認処理を作動させることができる。

ここで、本システム１０が対象とする移行元データベース１００で稼動しているＳＱＬは、例えば４００行以上のＳＱＬ文、３０以上の利用テーブル数などのＳＱＬが１０万本近くになるなど、複雑で膨大なキャラクタデータ（ソースコード）によって構成されることがある。
このような規模のＳＱＬについて、稼動確認用データ及び正しい結果を用意することは、多大な労力と時間がかかり、ＳＱＬの全てについて検証を行うことは困難乃至不可能であり、実際には何本もチェックできないのが現実である。
このような課題に対して、本システム１０では、対象となるＳＱＬをパターン化し、効率的な動作確認を実施できるようにし、これによって、安心／安全なデータベース移行を実現し、プロジェクト工期の予期せぬ長期化や、品質低下等を防ぐことができるものである。

具体的には、本システム１０では、移行元データベース１００から稼動中のＳＱＬを入力することにより、大きく以下のような「ＳＱＬのパターン化」，「進化テスト」，「レポート出力」の３つの処理が実行されるようになっている。
［ＳＱＬのパターン化処理］
ＳＱＬをパターン化して最小本数化を行い、それによってテストの効率化を図るものである。
具体的には、パターン化処理は、大要以下の３つの処理が実行される。
(1)４分類（ＳＥＬＥＣＴ・ＵＰＤＡＴＥ・ＩＮＳＥＲＴ・ＤＥＬＥＴＥ）
ＳＱＬを４つの基本構文（ＳＥＬＥＣＴ・ＵＰＤＡＴＥ・ＩＮＳＥＲＴ・ＤＥＬＥＴＥ）に従って分類・抽出する処理である。
(2)構造図の作成
分類された各基本構文について、所定の構造図を示す画像を当てはめて置換し、キャラクタデータを画像データに変換する処理である。
(3)収れん処理
生成された構造図について、同一・重複構造を削除することにより、構造図全体を収れん・縮減させる処理である。

［進化テスト処理］
(1)テスト
収れん処理された構造図を元のＳＱＬのキャラクタデータに変換してテストを実行する処理である。
(2)進化ＳＱＬの自動生成
収れん処理された構造図を進化させることにより、進化されたＳＱＬを自動生成する処理である。この進化ＳＱＬをテストすることにより、将来的な今後の開発を予測した応用確認などの進化テストが可能となる。
(3)進化ＳＱＬに対応した自動データ増幅による応用テスト
進化ＳＱＬに対応した仮想データを自動生成する処理であり、進化テストを効率的に実行できるようになる。

［レポート出力処理］
上述し進化テストを含むテスト結果を出力処理である。
これによって、移行先データベース２００における動作確認を、表示画面等で視覚を通じて確認できるとともに、進化テストの結果なども容易に確認できるようになる。

［機能構成］
上記のような各処理を実行するために、本システム１０は、図１に示すように、データベース言語入力部１１，構造図作成部１２，収れん処理部１３，進化／退化処理部１４，代表パターン生成部１５，代表パターンテスト実行部１６，特殊関数テスト実行部１７，レポート出力部１８の各部として機能するように構成される。
データベース言語入力部１１は、移行元データベース１００のＤＢＭＳに実装されている所定のデータベース言語で作成されたデータベース言語文であるＳＱＬを入力する。
構造図作成部１２は、データベース言語入力部１１で入力されたＳＱＬの文字列を分解し、所定の画像に置換して、当該ＳＱＬの構造図を作成する。このようなＳＱＬを構造図に変換・作成することができる本システム１０では、以下に示すような代表ＳＱＬに基づく検証・テストを自動で行うことができる他、例えば、システムを管理するシステムエンジニア等の人間が、構造図を目視で確認・チェックすることで、テスト数を減らすようなことも可能となる。

収れん処理部１３は、構造図作成部１２で作成された構造図に、同一構造が含まれているか否かを検索し、同一構造が含まれる場合には一方を破棄することにより、構造図を収れんする。
進化／退化処理部１４は、収れん処理部１３で収れんされた構造図に、構造を追加して進化させ、又は構造を削除して退化させる。

代表パターン生成部１５は、収れん処理部１３で収れんされた構造図を元の文字列に置換して、最小数にパターン化された代表ＳＱＬ（代表データベース言語文）を生成する。
また、代表パターン生成部１５は、進化／退化処理部１４で進化又は退化された構造図を文字列に置換して、代表ＳＱＬを生成する。
代表パターンテスト実行部１６は、代表パターン生成部１５で生成された代表ＳＱＬについて、所定の正解データを用いたテストを実行する。
なお、本システム１０では、ＳＱＬを構造図に変換した後に、ＳＱＬの検証や進化／退化を行うために、構造図から逆変換してＳＱＬ文を生成しているが、最初にＳＱＬ文から構造図に変換しているため、元のＳＱＬ文を記録しておくことにより、構造図の逆変換を行うことなく、記録してある元のＳＱＬを読み出すことによっても、検証や進化／退化を行うことも可能である。

特殊関数テスト実行部１７は、データベース言語入力部１１で入力されたＳＱＬの文字列に、所定の特殊関数が含まれているか否かを検索し、所定の特殊関数が含まれる場合には、当該特殊関数について、所定の正解データを用いたテストを実行する。
レポート出力部１８は、代表パターンテスト実行部１６や特殊関数テスト実行部１７で実行されたテスト結果を出力する。
以上のような本システム１０の各部１１～１８によって実行されるデータベースのマイグレーション支援のための処理・動作の詳細について、図面を参照しつつ以下に詳述する。

［アルゴリズム］
まず、図２～図３５を参照して、本システム１０における処理・動作を実現するための具体的なアルゴリズム（手順）について説明する。
［ＳＱＬパターン化］
図２に、本システム１０におけるＳＱＬのパターン化のアルゴリズムを模式的に示す。
同図に示すように、本システム１０に移行元データベース１００のＳＱＬが入力されると（データベース言語入力部１１）、ＳＱＬを構成するソースコードから「１ファイル：１ＳＱＬ」単位でキャラクタデータが抽出され、１ファイルずつＳＱＬの構文タイプに応じて振り分けられる。

具体的には、図２に示すように、「ＳＥＬＥＣＴ系」，「ＵＰＤＡＴＥ系」，「ＩＮＳＥＲＴ系」,「ＤＥＬＥＴＥ系」に、１ファイルずつＳＱＬ文が振り分けられ、所定のＳＱＬ格納ディレクトリ（記憶手段）に格納されていく。なお、この処理は、それぞれのディレクトごとにパラレルで処理を行うことにより、処理の高速化を図ることができる。
次に、構文タイプごとに振り分けられたＳＱＬ文のキャラクタデータは、１ファイルずつ、所定の構造図への置換・変換処理が行われ（図１４～図２０参照）、構造図ファイルが生成される（構造図作成部１２）。
そして、生成された構造図データを、後述する包含関係（図３参照）を用いた収れん処理によって収れん・縮減されて（収れん処理部１３）、「代表パターン」が生成され、膨大なキャラクタデータからなる元のＳＱＬが。収れんされた構造図からなる代表パターンデータにパターン化されることなる（代表パターン生成部１５）。

［ＳＱＬパターン収れん］
図３に、上記のような構造図の収れん処理のアルゴリズムを模式的に示す。
同図に示すように、収れん処理は、構造図の包含関係により収れんさせる。
具体的には、構造図に含まれる複数の構造について、構造が同じ場合には、重複する構造であるとして、一方を他方に包含（破棄）させることにより、構造図を収れんする。
例えば、図３に示す例では、「ＵＮＩＯＮ」構造が２つのケースは、「ＵＮＩＯＮ」が３つのケースに包含することができる。
このように、構造図の同一構造に着目して、包含（破棄）が可能な対象構造の選定を行う。

［テスト］
そして、以上のようにして収れんされた構造図に基づいて、動作確認のテストを行うことができる（代表パターンテスト実行部１６）。
図４に示すように、動作確認テストは、構造図によって収れん・パターン化されたＳＱＬについて行われる。これによって、元の膨大なＳＱＬと比較して、収れん・縮減されたＳＱＬについてテストを行えば良く、テストの正しい結果を示す正解データも、少ないデータで対応することができる。これに対して、元のそのままのＳＱＬについてテストを行おうとすれば、全てのＳＱＬに対応する正解データを準備する必要があり、そのような正解データを用意することは、現実に困難乃至不可能である。
なお、テストの正解データは、例えば、テーブルにデータを格納し、予め本システム１０の記憶手段などに用意しておくことができる。

［ＳＱＬパターン進化／退化］
そして、以上のようなテスト処理の結果に応じて、パターン化されたＳＱＬの進化／退化を行うことができる（進化／退化処理部１４）。
具体的には、まず、テストの結果、移行先データベース２００でも、現行の移行元データベース１００と同じ正しい結果が出た場合には、ＳＱＬを「進化」させることができる。これによって、移行先データベース２００における今後の開発予測等を行うことができるようになる。
一方、テストの結果、移行先データベース２００で誤った結果が出た場合には、現行のＳＱＬを「退化」させる。これによって、移行先データベース２００において正しい結果の出るＳＱＬを予測・生成することが可能となる。
このようなＳＱＬの進化／退化は、以下に示す自動生成処理によって行うことができ、特に、ＳＱＬを進化させた場合には、自動で進化データ及び正解データを生成し、自動データ増幅による応用テスト（進化テスト）を実行することができる。

［進化］
図５に、自動進化処理のアルゴリズムを模式的に示す。
まず、ＳＱＬを進化させる場合には、図５に示すように、パターン化されたＳＱＬの構造図について、以下の３つのパターンによりＳＱＬを変化（進化）させることができる。

(1)ＵＮＩＯＮにより横に伸びる
構造図において、同一構造を横に追加することで、当該構造と同一の機能を追加・拡張することができる。
これによって、例えば、現行システムが属性情報として「購入者」，「購入金額（円）」，「支払い期限日」の３つの項目のデータを管理している「業務システムＡ」，「業務システムＢ」，「業務システムＣ」の３つの機能を実装している場合に、さらに、例えば「業務システムＤ」などの新サービス・新業務システムの機能を追加・拡張させることができる。
図６に、ＳＱＬ構造をＵＮＩＯＮにより横に進化させた場合の出力結果の一例を示す（レポート出力部１８）。

(2)ＪＯＩＮにより縦に伸びる
構造図において、格納データの構造を縦に追加することで、管理データの属性を付加・追加することができ、ＪＯＩＮ数を増加させることができる。
これによって、例えば、管理データの属性として「購入者」，「購入金額（円）」，「支払い期限日」の３つの項目のデータが管理されている「業務システムＡ」，「業務システムＢ」，「業務システムＣ」に対して、それぞれ、「性別：男ｏｒ女」などの新属性を付与・追加させることができる。
図７に、ＳＱＬ構造をＪＯＩＮにより縦に進化させた場合の出力結果の一例を示す。

(3)表示順序の調整により間に入る
構造図において、同一構造の横方向の位置を変更することで、表示の順序を変更・調整することができる。これによって、同一構造からなる複数の機能について、任意の機能の表示位置を移動させ、例えば先行表示されていた機能の間に入れることができるようになる。
図８に、表示順序を変更させた場合の出力結果の一例を示す。この例では、管理データとして「購入者」，「購入金額（円）」，「支払い期限日」の３つの項目データを管理している「業務システムＡ」，「業務システムＢ」，「業務システムＣ」の表示の順序を、「業務システムＡ」，「業務システムＣ」，「業務システムＢ」と入れ替えた場合である。

［退化］
一方、ＳＱＬを退化させる場合には、図９に示すように、パターン化されたＳＱＬの構造図について、上述した進化と同様の以下の２つのパターンによりＳＱＬを変化（退化）させることができる。
(1)ＵＮＩＯＮを削り横に縮む
構造図において、横に並ぶ同一構造の一部を削除することで、当該構造の機能を縮減・退化させることができる。
これによって、例えば、現行システムが「業務システムＡ」，「業務システムＢ」，「業務システムＣ」の３つの機能を実装している場合に、「業務システムＣ」の機能を削除・縮減させることができる。
図１０に、ＳＱＬ構造についてＵＮＩＯＮを横に退化させた場合の出力結果の一例を示す。

(2)ＪＯＩＮを削り縦に縮む
構造図において、縦に並ぶ格納データの構造の一部を削除（ＪＯＩＮテーブルを削除）することで、管理データの属性を縮減・退化させることができる。
なお、ＳＱＬを退化させる場合にも、上述した進化の場合と同様に、構造図において、同一構造の横方向の位置を変更することで、表示の順序を変更・調整することができることは言うまでもない。

［ＳＱＬの構造分解／構造図の作成］
次に、上述したＳＱＬを構成するソースコードをＳＱＬの構文タイプに応じて振り分ける構造分解及び構造図の作成について説明する。
上述のとおり、ＳＱＬの構造分解は、ＳＱＬ文の基本構文に従って、「ＳＥＬＥＣＴ系」，「ＵＰＤＡＴＥ系」，「ＩＮＳＥＲＴ系」，「ＤＥＬＥＴＥ系」の４つの構文に着目して実行される。
基本的には、ソースコード中の「ＳＥＬＥＣＴ～；」，「ＵＰＤＡＴＥ～；」，「ＩＮＳＥＲＴ～；」，「ＤＥＬＥＴＥ～；」を一つの構造の単位として抽出し、そこに含まれるコマンド単位で構文を抽出・分解して、分解された要素ごとに所定の構造図画像に置換・変換が行われる（図１４～図２０）。

ここで、ＳＥＬＥＣＴ系構文は、他の構文（ＵＰＤＡＴＥ系，ＩＮＳＥＲＴ系，ＤＥＬＥＴＥ系）にはない構造を記載できるため、まず、ＳＥＬＥＣＴ文に特有の構造ついて、図１１～図１３を参照して説明する。
図１１～図１３に、ＳＥＬＥＣＴ文の構造を分解する場合の説明図を示す。
これらの図に示すように、ＳＥＬＥＣＴ文には、３つの構文パターンがある。
図１１に示すのは、内部に入れ子構造を取ることができる構文である。
図１１に示す例では、データベースの管理データとして、「社員テーブル」と「給与テーブル」の二つのデータテーブルが存在する場合に、例えば「月給３０万円以上」の社員番号を選択し、その上で、社員番号を用いて社員名をリストにし、最後に社員番号順で並び替える、というＳＥＬＥＣＴ文となっている。
このような場合には、ＳＥＬＥＣＴ文の「ＷＨＥＲＥ列名＝（～）」の「（～）」中に記載されている「入れ子構造」の構文（図１１で太線で囲まれた部分）を含めて、一つのＳＥＬＥＣＴ文の構造として抽出する。

図１２に示すのは、中間テーブルを一時的に作成して結果を出すことができる構文である。
図１２に示す例では、データベースの管理データとして、「社員テーブル」と「退職明細」の二つのデータテーブルが存在する場合に、例えば「退職日」を指定して社員名を取得する、というＳＥＬＥＣＴ文となっている。
このような場合には、「ＦＲＯＭ～ＷＨＥＲＥ」の中に「ＬＥＦＴ ＯＵＴＥＲ ＪＯＩＮ」で記載されている構文（図１２で太線で囲まれた部分）を含めて、一つのＳＥＬＥＣＴ文の構造として抽出する。

図１３に示すのは、結果の和集合を作成することができる構文である。
図１３に示すＳＥＬＥＣＴ文は、データベースの管理データとして、「拠点Ａ勤務社員テーブル」と「拠点Ｂ勤務社員テーブル」の二つのデータテーブルが存在する場合に、例えば拠点別の所属社員表から和集合を出力する、という構文である。
このような場合には、「ＵＮＩＯＮ ＡＬＬ」で結ばれた２つの「ＳＥＬＥＣＴ～ＦＲＯＭテーブル名」の構文（図１３で太線で囲まれた３つの部分）を、一つのＳＥＬＥＣＴ文の構造として抽出する。

［構造図画像の作成］
そして、以上のようにしてＳＱＬの基本構文（ＳＥＬＥＣＴ，ＵＰＤＡＴＥ，ＩＮＳＥＲＴ，ＤＥＬＥＴＥ）に従って一構造として抽出されたＳＱＬ文について、そこに含まれるコマンド単位で構文を抽出・分解して、分解された要素ごとに所定の構造図画像に置換・変換して、ＳＱＬの構造を示す構造図が作成される。
なお、以下に示す所定の構造図を構成する画像は、本システム１０の記憶手段などに予め画像データとして格納・記憶させておくものとする。

［ＳＥＬＥＣＴ文］
図１４は、図１１に示したＳＥＬＥＣＴ文を所定の構造図に変換する場合である。
同図に示すように、この場合のＳＥＬＥＣＴ文は、以下のような手順により、ＳＥＬＥＣＴ文の各要素がそれぞれ所定の画像に置換されて、一つの構造図として作成される。
(1)構文中の「一番内側にあるテーブル」という意味で「ドラム缶マーク」を一番右側に記載する。
(2)「条件に合致するレコードを抽出」という意味で「片カッコ」を「ドラム缶マーク」の左側に記載する。
(3)「その結果を用いて」という意味で「矢印」を「片カッコ」の左側に記載する。
(4)「別のテーブルのデータと連結して」という意味で「ドラム缶マーク」を「矢印」の左側に記載する。
(5)「該当するレコードもしくは列を抽出」という意味で「片カッコ」を「ドラム缶マーク」の左側に記載する。
以上の処理・手順により、図１４左側（図１１）に示すＳＥＬＥＣＴ文が、図１４右側に示す構造図として置換・生成される。

図１５は、図１２に示したＳＥＬＥＣＴ文を所定の構造図に変換する場合であり、以下のような手順により、ＳＥＬＥＣＴ文が構造図として置換・作成される。
(1)「ＪＯＩＮするテーブル」を示す２つの「ドラム缶マーク」をテーブル名順に一番右側に縦に配置する。
(2)「ＪＯＩＮ種別」及び「矢印」を対応する「ドラム缶マーク」の左側に記載する。
(3)「ＪＯＩＮ先テーブル」を示す「ドラム缶マーク」を「矢印」の左側に配置する。
(4)「その結果を用いて」という意味で「矢印」を「ドラム缶マーク」の左側に記載する。
(5)「別のテーブルのデータと連結して」という意味で「ドラム缶マーク」を「矢印」の左側に記載する。
(6)「該当するレコードもしくは列を抽出」という意味で「片カッコ」を「ドラム缶マーク」の左側に記載する。
以上の処理・手順により、図１５左側（図１２）に示すＳＥＬＥＣＴ文が、図１５右側に示す構造図として置換・生成される。

図１６は、図１３に示したＳＥＬＥＣＴ文を所定の構造図に変換する場合であり、以下のような手順により、ＳＥＬＥＣＴ文が構造図として置換・作成される。
(1)一つ目のＳＥＬＥＣＴ文を示す「ドラム缶マーク」及び「片カッコ」を一番右側に配置し、それらを「ＵＮＩＯＮ句の上（前）で出力される結果（集合）」を意味する「四角の枠」で括る。
(2)「和集合を作る」という意味で「横線」を「四角の枠」の左側に連結し、「ＵＮＩＯＮ種別」を記載する。
(3) 二つ目のＳＥＬＥＣＴ文を示す「ドラム缶マーク」及び「片カッコ」を一番左側に配置し、それらを「ＵＮＩＯＮ句の下（後）で出力される結果（集合）」を意味する「四角の枠」で括り、「横線」の左側に連結する。
なお、「結果の和集合を作成する」ことが可能なコマンドとしては、「ＵＮＩＯＮ」と「ＵＮＩＯＮ ＡＬＬ」とが存在するため、構造図を生成する場合には、両者を区別できる画像を割り当てるようにする。
以上の処理・手順により、図１６左側（図１３）に示すＳＥＬＥＣＴ文が、図１６右側に示す構造図として置換・生成される。

［ＩＮＳＥＲＴ文］
図１７は、ＩＮＳＥＲＴ文を所定の構造図に変換する場合であり、以下のような手順により、ＩＮＳＥＲＴ文が構造図として置換・作成される。
(1)「データ挿入先のテーブル」という意味で「ドラム缶マーク」を一番右側に記載する。
(2)「データ挿入作業」を示す「左から右方向の矢印」を「ドラム缶マーク」の左側に配置する。
(3)「データ挿入の基点」という意味で「ＩＮＳＥＲＴ」を示す「黒丸「Ｉ」文字」を「矢印」の左側に配置する。
以上の処理・手順により、図１７左側に示すＩＮＳＥＲＴ文が、図１７右側に示す構造図として置換・生成される。

図１８は、ＩＮＳＥＲＴ文として、他のテーブルから検索したデータを挿入することが可能なＩＮＳＥＲＴ文を所定の構造図に変換する場合であり、以下のような手順により、ＩＮＳＥＲＴ文が構造図として置換・作成される。
(1)「データ挿入先のテーブル」という意味で「ドラム缶マーク」を一番右側に記載する。
(2)「データ挿入作業」を示す「左から右方向の矢印」を「ドラム缶マーク」の左側に配置する。
(3)「データ挿入の基点」という意味で「ＩＮＳＥＲＴ」を示す「黒丸「Ｉ」文字」を「矢印」の左側に配置する。
(4)「該当するレコードもしくは列を抽出」という意味で「片カッコ」（ＳＥＬＥＣＴ文とは逆向き）を「黒丸「Ｉ」文字」の左側に記載する。
(5)「データ挿入先に用いるオリジナルデータを格納したテーブル」という意味で「ドラム缶マーク」を「片カッコ」の左側に記載する。
以上の処理・手順により、図１８左側に示すＩＮＳＥＲＴ文が、図１８右側に示す構造図として置換・生成される。

［ＵＰＤＡＴＥ文］
図１９は、ＵＰＤＡＴＥ文を所定の構造図に変換する場合であり、以下のような手順により、ＵＰＤＡＴＥ文が構造図として置換・作成される。
(1)「データ更新先のテーブル」という意味で「ドラム缶マーク」を一番右側に記載する。
(2)「データ更新作業」を示す「左から右方向の矢印」を「ドラム缶マーク」の左側に配置する。
(3)「データ更新の基点」という意味で「ＵＰＤＡＴＥ」を示す「黒丸「ＵＰ」文字」を「矢印」の左側に配置する。
以上の処理・手順により、図１９左側に示すＵＰＤＡＴＥ文が、図１９右側に示す構造図として置換・生成される。

［ＤＥＬＥＴＥ文］
図２０は、ＤＥＬＥＴＥ文を所定の構造図に変換する場合であり、以下のような手順により、ＤＥＬＥＴＥ文が構造図として置換・作成される。
(1)「データ削除先のテーブル」という意味で「ドラム缶マーク」を一番右側に記載する。
(2)「データ削除作業」を示す「左から右方向の矢印」を「ドラム缶マーク」の左側に配置する。
(3)「データ削除の基点」という意味で「ＤＥＬＥＴＥ」を示す「黒丸「Ｄ」文字」を「矢印」の左側に配置する。
以上の処理・手順により、図２０左側に示すＤＥＬＥＴＥ文が、図２０右側に示す構造図として置換・生成される。

［構造図のマッピング／収れん］
次に、以上のようにして作成された構造図のマッピング／収れん処理について説明する。
図２１及び図２２は、生成する構造図をマッピングする手法を示す説明図であり、図２１は構造図がＳＥＬＥＣＴ文の場合、図２２はＩＮＳＥＲＴ文の場合である。
これらの図に示すように、マッピングは、例えば「１００１マス×１００１マス」を初期値とする「方眼マップ」を用意し、このマップ上に構造図を張り付けて実行される。
なお、方眼マップは、初期値として「縦横１００１マス」からスタートさせるが、マスが足りない場合には拡張することができる。
また、このような方眼マップのデータについても、上述した構造図の画像データとともに、本システム１０の記憶手段などに予め画像データとして格納・記憶させておくものとする。

［マッピングルール］
マッピング処理は、以下のルールに基づいて実行される。
まず、ＳＥＬＥＣＴ文については、以下のルールとする（図２１参照）。
［ＳＥＬＥＣＴ文ルール］
・右端中心から書き始める
・記号：１マスに１つ
・「ＳＥＬＥＣＴ」は右から左に順に配置
・「ＪＯＩＮ」は上から下に順に配置
・結果セットを全ての記号が含まれる最小限の大きさの太い枠でくくる
・矢印：記号間を横１マスで接続（接続ポイントは真ん中とする）
「ＪＯＩＮ」種別を区別するために「ＪＯＩＮ」時は矢印の下に区分を記載する
－「ＪＯＩＮ」：「Ｊ」を記載
－「ＬＥＦＴ ＯＵＴＥＲ ＪＯＩＮ」：「ＬＪ」
－「ＲＩＧＨＴ ＯＵＴＥＲ ＪＯＩＮ」：「ＲＪ」
－「ＦＵＬＬ ＯＵＴＥＲ ＪＯＩＮ」：「ＦＪ」
・和集合を作る「ＵＮＩＯＮ」は横線で連結する
「ＵＮＩＯＮ」種別を区別するために、横線の下に区分を記載する
－「ＵＮＩＯＮ」：「Ｕ」を記載
－「ＵＮＩＯＮ ＡＬＬ」：「ＵＡ」
・色は白黒で表現

同様に、ＩＮＳＥＲＴ文・ＵＰＤＡＴＥ文・ＤＥＬＥＴＥ文については、以下のルールとする（図２２参照）。
［ＩＮＳＥＲＴ文・ＵＰＤＡＴＥ文・ＤＥＬＥＴＥ文ルール］
・右端中心から書き始める
・記号：１マスに１つ
・右から左に順に配置
・結果セットを全ての記号が含まれる最小限の大きさの太い枠でくくる
・矢印：記号間を横１マスで接続（接続ポイントは真ん中とする）
左から右に向けて記載する
・テーブルから値を取り出す場合は片カッコを用いる（ＳＥＬＥＣＴとは反対向きとする
・ＩＮＳＥＲＴ／ＵＰＤＡＴＥ／ＤＥＬＥＴＥを区別するため基点に区分を記載
－「ＩＮＳＥＲＴ」：「Ｉ」を記載
－「ＵＰＤＡＴＥ」：「ＵＰ」
－「ＤＥＬＥＴＥ」：「Ｄ」
・色は白黒で表現

以上のようなマッピングルールに従い、構造図の収れん処理が実行され、パターン化された代表ＳＱＬが決定される。
構造図の収れんは、画像処理による総当たりによって行われる。このような画像処理技術を用いることにより、構造図の収れんを高速かつ正確に実行できるようになる。
［前処理］
まず、収れんの「前処理」として、図２３に示すように、フィラーをマップから削除する処理が実行される。
具体的には、図２３に示す「太い線」以外の余白が削除される。
但し、「ＵＮＩＯＮ」を示す「横線」及び「黒丸」は削除されないようにする。

［メイン処理］
次に、収れんの「メイン処理」として、図２４及び図２５に示すように、画像処理による「総当たり」と、それに基づく「包含関係のチェック」が実行される。
まず、「メイン処理」は、以下のような手順により実行される（図２４参照）。
(1)ＳＥＬＥＣＴ系／ＵＰＤＡＴＥ系／ＤＥＬＥＴＥ系／ＩＮＳＥＲＴ系のそれぞれのディレクトリごとに処理を実行する
(2)利用しているマス目順にソートする
(3)最も利用しているマス目の少ない構造図を抽出し、比較対象とする
(4)「(3)」で選択された構造図を、最もマス目の大きい構造図内に同一構造が無いかサーチする（図２５参照）
(5)同じ構造が発見された場合、「(3)」で選択された構造図は上位ＳＱＬに包含されているものとして破棄する
(6)「(3)」で選択された構造図の次にマス目の利用数が多い構造図を選択し、「(3)～(5)」と同様の処理を実行する
(7)もし「(3)～(5)」の処理によって「包含」される構造が発見されない場合は、比較対象を２番目に大きな構造図に変更し、同様の処理を実行する
以上の手順を繰り返すことにより、最も複雑なＳＱＬを発見することができる。

図２５に、上記「(3)～(5)」の包含関係をチェックするサーチ処理の詳細を示す。
同図に示すように、包含関係のサーチは、以下の手順により実行される。
（１）包含チェックの対象となる構造図をマス目の左上に合わせて配置する
（２）対象構造図を右方向に１マスずつ移動させ、同じ構造が無いかをチェックする
（３）対象構造図がマス目の右端まで到達したら、下に１マスずつ移動させ
（４）再びマス目の左から右方向に、対象構造図を１マスずつ移動させて同様のチェックを行い、マス目の右下端まで到達したら終了とする

以上の処理を繰り返すことにより、他の構造図に包含される構造図は破棄され、全ての構造図を包含する最も大きい（複雑な）構造図のみが抽出され、それが代表ＳＱＬとなる構造図として決定されることになる。
そして、そのように決定された代表ＳＱＬを示す構造図を、元のＳＱＬのキャラクタデータ（ソースコード）に変換・復元して、移行先データベース２００における動作確認のテストを実行することができるようになる。
これによって、移行先データベース２００の動作確認テストを、上述のように構造図によって収れん・パターン化された代表ＳＱＬに基づいて実行することができ、元の膨大なＳＱＬと比較して、高速かつ効率的なテストを実行することができ、テストの正解データも少ないデータで対応することができるようになる。

［構造図の進化／退化］
以上のように、マッピング／収れん処理によって生成される代表ＳＱＬを示す構造図は、さらに、以下のような手順によって進化／退化（図５，図９）させることができる。
構造図の進化／退化処理は、上述した構造図の生成と同様に、マス目を用いた画像処理によって実行することができる。

［進化処理］
図２６～図３０に、構造図の進化処理の手法を示す。
図２６は、進化処理の１つ目である「ＵＮＩＯＮ」により「横に伸びる」進化（図５参照）をさせる場合である。
具体的には、構造図中に「ＵＮＩＯＮ」を示す「Ｕ」もしくは「ＵＡ」の記号が含まれる場合、図２６に示すように、その「ＵＮＩＯＮ」」で連結された既存構造を、マス目上で半分のマス目分だけ左方向にシフトさせる。
その後、同一構造図をコピーにより生成し、シフトさせた既存構造の右側に張り付け、「ＵＮＩＯＮ」で連結して、構造図を保存する。
これによって、横方向への構造拡張（進化）が行われる。
同様の処理を繰り返すことで、任意の数だけ、横方向への拡張を行うことできる。

図２７は、進化処理の２つ目である「ＪＯＩＮ」により「縦に伸びる」進化（図５参照）をさせる場合である。
具体的には、構造図中に「ＪＯＩＮ」を示す「Ｊ」，「ＬＪ」，「ＲＪ」，「ＦＪ」の記号が含まれる場合、図２７に示すように、その「ＪＯＩＮ」により縦方向に配置されている「データ」を示す「ドラム缶マーク」の下に、同様の「ドラム缶マーク」の画像を配置し、「ＪＯＩＮ」で連結して、構造図を保存する。
これによって、縦方向への構造拡張（進化）が行われる。
同様の処理を繰り返すことで、任意の数だけ、縦方向への拡張を行うことできる。

図２８及び図２９は、上記のように横方向・縦方向に構造図を進化させた場合の、格納すべきデータ及び正解データの自動生成の手法を示しており、図２８は横方向の拡張、図２９は縦方向の拡張の場合である。
図２８に示すように、横方向の拡張を行った場合には、拡張された構造に格納すべきデータとして、コピー元の構造に対応するデータをコピーする。その際に、格納データの文字項目に関して、例えば最後の文字を他の文字、例えば「１」に置き換える。数字項目については変更しない。
このようにすることで、図２８の「想定結果」に示すように、拡張構造に格納すべきデータ及び正解データが自動生成されることになる。
なお、拡張構造を複数設ける場合には、上述した「１」を付与するだけではケタあふれの可能性があるため、さらに構造を拡張する場合には、次の拡張構造のデータには「２」を付与し、以降数字を順次上げることで対応することができる。

図２９に示すように、縦方向の拡張を行った場合には、拡張された構造に格納すべきデータとして、１つ前（上）の構造（テーブル）のデータをコピーする。その際に、横方向の場合と同様に、納データの文字項目に関して、例えば最後の文字を「１」に置き換える。数字項目については変更しない。
このようにすることで、図２９の「想定結果」に示すように、拡張構造に格納すべきデータ及び正解データが自動生成されることになる。
なお、この縦方向の拡張の場合も、横方向の場合と同様に、さらに構造を拡張する場合には、次の拡張構造のデータには「２」を付与し、以降数字を順次上げることができる。

図３０は、進化処理の３つ目である「表示順序の調整により間に入る」進化（図５参照）をさせる場合のデータの出力結果を示している。
この場合には、図３０左側に示すように、構造図から元のキャラクタデータに変換したソースコード中の列名（例えば「列名１，列名２・・・」）を入れ替えることにより、表示順序を入れ替えることができる。
これによって、図３０右側に示すように、例えば「業務システムＡ」，「業務システムＢ」の順に表示されていた出力結果を入れ替えて、「業務システムＢ」を先頭に表示させることができるようになる。
なお、「間に入る」としているのは、並び替えの「列」が３つ以上であれば、結果のレコードセットが間に入る場合があるため、「間に入る」と表現している。

［退化処理］
図３１～図３４に、構造図の退化処理の手法を示す。
図３１は、退化処理の１つ目である「ＵＮＩＯＮ」を削ることにより「横に縮む」退化（図９参照）をさせる場合である。
具体的には、構造図中に「ＵＮＩＯＮ」を示す「Ｕ」もしくは「ＵＡ」の記号が含まれる場合、図３１に示すように、その「ＵＮＩＯＮ」」で連結された既存構造の最も左に配置された構造と「ＵＮＩＯＮ」を示す記号及び「横線」を削除する。
これによって、横方向への構造縮減（退化）が行われる。
同様の処理を繰り返すことで、任意の数だけ、横方向への縮減を行うことできる。

図３２は、退化処理の２つ目である「ＪＯＩＮ」を削ることにより「縦に縮む」退化（図９参照）をさせる場合である。
具体的には、構造図中に「ＪＯＩＮ」を示す「Ｊ」，「ＬＪ」，「ＲＪ」，「ＦＪ」の記号が含まれる場合、図３２に示すように、その「ＪＯＩＮ」により縦方向に配置されている「データ」を示す「ドラム缶マーク」のうち最も下の「ドラム缶マーク」を削除する。
これによって、縦方向への構造縮減（退化）が行われる。
同様の処理を繰り返すことで、任意の数だけ、縦方向への拡張を行うことできる。

図３３及び図３４は、上記のように横方向・縦方向に構造図を退化させた場合の、データの出力結果を示しており、図３３は横方向の縮減、図３４は縦方向の縮減の場合である。
横方向の縮減を行った場合には、図３３の「想定結果」に示すように、例えば退化前に「業務システムＡ」，「業務システムＢ」の出力結果が表示されていたものが、「業務システムＡ」のみが出力・表示されるようになる。
縦方向の縮減を行った場合には、図３４に示すように、例えば、属性情報として退化前に「購入者」，「購入金額（円）」，「支払い期限日」の３つの項目のデータが出力結果として表示されていたものが、１列の項目（「支払い期限日」）が消えて表示されないようになる。
なお、この場合には、「ＪＯＩＮ」数が減っても、検索結果レコードセットに変化が無いことが、ＳＱＬの実行性担保において重要となる。

［特殊関数テスト］
次に、図３５を参照して、特殊関数テストについて説明する。
上述のとおり、本システム１０においては、ＳＱＬの構造を示す構造図の作成及びその収れんによって代表ＳＱＬパターンを選定・決定し、その代表ＳＱＬパターンに基づく試験を行うことによって、移行先データベース２００の動作保証を行うようになっている。
特許関数テストは、そのような代表パターンテストの仕上げ・補完として実行できるもので、ＳＱＬに含まれる特殊関数、例えば、図３５に示すような特殊制御及び関数（例えばＳＵＭ，ＡＶＧ等）の動作確認を実行・保証するものである
特許関数テストは、本システム１０に入力されたＳＱＬの文字列に、所定の特殊関数が含まれているか否かを検索し、所定の特殊関数が含まれる場合には、当該特殊関数について、所定の正解データを用いたテストを実行する（特殊関数テスト実行部１７）。

具体的には、例えばマイクロソフト社の「Ｅｘｃｅｌ」などの表計算アプリケーションを用いて、ＳＱＬに含まれる特殊関数の解析表を作成し、ＳＱＬの全件について、例えば「Ｇｒｅｐ」により検索して、ヒットしたものを各１ケースずつ、移行元データベース１００と移行先データベース２００で結果が同じであるか否かを検査することにより行われえる。
対象とすべき特殊関数としては、例えば、図３５に示すような「特殊関数ファイル」を、本システム１０の記憶手段において記憶しておくことができる。

このような特殊関数のテストは、拾うべきレアケースではあるが、このような「仕上げ」を行うことで、ほぼ完全に、移行元データベース１００と移行先データベース２００の動作保証を行うことができることになる。
この特殊関数テストについても、ＳＱＬ代表パターンテストと同様に、テスト結果を出力・表示させることができる（レポート出力部１８）。

［動作］
次に、以上のような本システム１０における具体的な処理・動作（データベースマイグレーション支援方法の実施）について、図３６～図５０を参照して説明する。
［全体工程］
図３６に、本システム１０の動作確認処理の全体工程を示すフローチャートを示す。
同図に示すように、本システム１０では、「代表パターンを探索しての動作確認」と「特殊関数を探索しての動作確認」の２系統で処理が行われる。
具体的には、以下の通りである。
［代表パターンの動作確認］
まず、「代表パターンを探索しての動作確認」は、「ＳＱＬファイルの作成／配置：手動」→「代表ＳＱＬの決定：自動」→「テストデータの投入・正解ファイルの作成／配置：手動」→「テスト実施（現行保証／進化／退化）：自動」→「結果レポート作成：自動」の順に処理が実行される。
なお、処理中「手動」とあるのは、例えば本システム１０のユーザや管理者，操作者等が、手動（手作業・操作）によってデータの選択・指定・入力等を行うものである。
一方、「自動」とあるのは、本システム１０を構成する情報処理装置の動作によって、自動でデータの抽出・選択・決定・生成等が行われるものである。

［特殊関数の動作確認］
次に、「特殊関数を探索しての動作確認」は、「ＳＱＬファイルの作成／配置：手動」→「代表ＳＱＬの決定：自動」→「テストデータの投入・正解ファイルの作成／配置：手動」→「テスト実施（現行保証）：自動」→「結果レポート作成：自動」の順に処理が実行される。
なお、処理中「手動」，「自動」は上記「代表パターンを探索しての動作確認」と同様である。
また、「代表パターンを探索しての動作確認」において既に手動で「ＳＱＬファイルの作成／配置」，「テストデータの投入・正解ファイルの作成／配置」が行われた場合には、そのデータを再利用することができる。

［システム画面構成］
図３７及び図３８に、本システム１０の動作確認処理における画面表示の一例を示す。
本システム１０では、以下に示す動作確認処理が実行される場合に、操作者のユーザインタフェースとなる表示手段、例えば本システム１０に接続された液晶ディスプレイ等において、図３７，図３８に示すような表示画面が生成・表示される。そして、操作者が表示画面に沿った入力操作を行うことによって、動作確認処理の各工程が実行されるようになる。
なお、以下に示す画面構成は一例であり、これ以外の画面構成を生成・出力させることができることは言うまでもない。

［０．システム起動画面］
この画面は、本システム１０の初期画面として最初に表示されるようになっている。
本画面では、図３７に示すように、画面表示に従った操作者の入力操作に応じて、「稼動確認実行」が選択されると、「１．システム実行形式選択画面」に遷移し、「実行記録閲覧」が選択されれば、「５．実行記録閲覧画面」に遷移する。
［１．システム実行形式選択画面］
この画面は、「０．システム起動画面」で「稼動確認実行」が選択された場合に遷移する画面であり、本システム１０におけるシステムの実行形式を選択可能に表示するものである。
具体的には、本画面では、図３７に示すように、「自動実行選択ボタン」及び「手動実行選択ボタン」が選択可能に表示され、操作者の入力操作に応じて、いずれかの実行形式が選択・実行されるようなっている。

［２．進捗表示画面］
この画面は、本システム１０で実行される動作確認処理の進捗状況を表示するものであり、上述した図３６と同様の内容が表示されるようになっている。
本画面では、上述した「１．システム実行形式選択画面」で選択・指定された実行形式が「手動実行」の場合には、所定のアナウンス画面が表示される。
一方、「自動実行」が選択・実行されている場合には、自動実行処理の進捗に対応して、完了したステップが例えば灰色になり、実行中のステップが例えば赤色でハイライト表示されて、処理の進捗状況が表されるようになっている。
また、処理が全て完了すると「完了」ボタンが有効になり、操作者の入力操作により「完了」ボタンが押下されると、上述した「０．システム起動画面」に戻るようになる。

［３．手動実行時のＳＱＬファイル取得］
この画面は、上述した「１．システム実行形式選択画面」で選択・指定された実行形式が「手動実行」の場合に、ＳＱＬファイルの取得操作を促す画面が表示されるものである。
具体的には、図３７に示すように、例えば「ＳＱＬファイル格納場所を指定して下さい▼」というアナウンス表示が表示され、操作者の入力操作により「▼」ボタンが押下されると、任意のフォルダ選択が可能な画面が表示される（図示省略）。
ここで、有効なファイルが指定されない場合には、受け入れない。
また、ファイル格納場所が指定された後、「次に進む」ボタンが押下されることで、上述した進捗表示画面に戻り、次ステップに進むようになる。

［４．データ投入指示画面］
この画面も、「１．システム実行形式選択画面」で選択・指定された実行形式が「手動実行」の場合に、移行先データベース２００へのデータ投入と正解ファイルの取得操作を促す画面が表示されるものである。
具体的には、図３８に示すように、例えば「移行先データベースへデータをロードして下さい」，「正解ファイル格納場所を指定して下さい▼」というアナウンス表示が表示され、操作者の入力操作により「▼」ボタンが押下されると、任意のフォルダ選択が可能な画面が表示される（図示省略）。また、有効なファイルが指定されない場合には、受け入れないようになる。
そして、ファイル格納場所が指定された後、「次に進む」ボタンが押下されることで、上述した進捗表示画面に戻り、次ステップに進むことになる。

［５．実行記録閲覧画面］
この画面は、「０．システム起動画面」で「稼動確認実行」が選択された場合に遷移しり画面であり、本システム１０の動作確認処理について、閲覧を希望する実行記録を選択可能に表示するものである。
具体的には、本画面では、図３８に示すように、本システム１０において過去に実行された動作確認の「日時」及び「実行回数」が複数表示され、例えばスライドバーで上下にスクロールできるようになっており、画面上には常に複数件（例えば５件程度）の実行履歴が表示さるようになっている。なお、実行履歴の記録としては、所定件数を保持しておくことができ、例えば最大１０００件までの実行履歴の情報を保持させることができる。
そして、図３８に示すように、操作者の入力操作に応じて、任意の実行履歴に対応するボタンがクリックされて選択されると、ボタンの中心が黒色に反転して、選択された実行履歴が特定されるようになる。なお、図３８に示す場合には、選択可能な実行履歴は１行（１件）のみとなっているが、複数の実行履歴を選択できるように構成することも勿論可能である。
また、「戻る」ボタンが押下されれば、「０．システム起動画面」に戻るようになる。

［６．希望閲覧処理選択画面］
この画面は、前画面（５．実行記録閲覧画面）で選択された実行履歴の日時／実行回数を表示させるとともに、当該実行履歴のうち、閲覧を希望する処理内容として、「代表パターン」と「特殊関数」のいずれかを選択可能に表示するものである。
具体的には、図３８に示すように、選択された実行履歴を示す情報として、例えば「２０１８年１月１日－１２時 １回目の実行記録」と表示され、その実行履歴のうち、「代表パターンを探索しての動作確認」と「特殊関数を探索しての動作確認」のいずれかが選択可能に表示されるようになる。
そして、操作者の入力操作に応じて、「代表パターン」と「特殊関数」のいずれかに対応するボタンがクリックされると、ボタンの中心が黒色に反転して、選択された処理内容が特定されるようになる。
その後、「閲覧」ボタンが押下されれば、以下の「７．レポート表示画面」に遷移する。
また、「戻る」ボタンが押下されれば、「５．実行記録閲覧画面」に戻るようになる。

［７．レポート表示画面］
この画面は、前画面（６．希望閲覧処理選択画面）で選択された実行記録・処理内容について、該当するレポートファイル（後述する図５０参照）を表示するものである。
具体的な画面の表示例は省略するが、このレポートファイルが表示されることで、ユーザは、過去に実行された動作確認処理の内容・結果を閲覧することができるようになる。
そして、「戻る」ボタンが押下されることで、初期画面である「０．システム起動画面」に戻る。

［フローチャート］
次に、以上のような画面表示に従って実行される本システム１０における動作確認処理の具体的な内容について、図３９～図５０に示すフローチャートに沿って説明する。
［代表パターン：ＳＱＬファイルの作成／配置］
図３９に「代表パターン：ＳＱＬファイルの作成／配置」処理のフローチャートを示す。
このＳＱＬファイルの作成／配置処理では、図３９に示すように、まず、本システム１０の表示手段（ディスプレイ等）に表示されている進捗表示画面を初期化して（ステップ３９０１）、操作者の入力操作に応じて選択された動作確認処理の実行形式が自動実行であるか手動実行であるかが判定される（ステップ３９０２）。

実行形式が「手動」であれば、表示画面を「３．手動実行時のＳＱＬファイル取得」画面（図３７参照）に遷移させて（ステップ３９０３）、処理は終了となる。この場合は、ＳＱＬファイルは、上述のとおり、操作者の入力操作に応じて、任意のフォルダが選択されデータが取得される（図３７参照）。
一方、実行形式が「自動」の場合には、遷移画面（図３６，図３７参照）における「ＳＱＬファイルの作成／配置」ボックスが赤色などで着色された後（ステップ３９０４）、ＳＱＬファイルの自動作成処理が実行される（ステップ３９０５～３９１０）。

ＳＱＬファイルの作成は、まず、ファイル名に使用する連続管理番号を「０」にセットし（ステップ３９０５）、その後、移行元データベース１００のＳＱＬ実行記録からＳＱＬを抽出する（ステップ３９０６）。この抽出処理は１ＳＱＬずつ、全てのＳＱＬファイルを取り出して行われる。
抽出処理は、連続管理番号が「１００，０００」に到達するまで繰り返され（ステップ３９０７）、ファイル名に使用する連続管理番号をプラス「１」して（ステップ３９０８）、ファイル名を「ｍｉｇ＿連続管理番号．ｔｘｔ」として、格納先の「ＩＮＰＵＴ－ＳＱＬファイル格納ディレクトリ」に出力し（ステップ３９０９）、連続管理番号が「１００，０００」に到達したら（ステップ３９０７）、進捗表示画面の進捗が進められて（ステップ３９１０）、処理は終了となる。

［代表パターン：テストデータの投入・正解データの作成／配置］
図４０に「代表パターン：テストデータの投入・正解データの作成／配置」処理のフローチャートを示す。
このデータ投入／配置処理では、図４０に示すように、まず、操作者の入力操作に応じて選択された動作確認処理の実行形式が自動実行であるか手動実行であるかが判定され（ステップ４００１）、「手動」の場合には、表示画面を「４．データ投入指示画面」（図３８参照）に遷移させて（ステップ４００２）、処理は終了となる。この場合は、データ投入／正解ファイルの配置は、上述のとおり、操作者の入力操作に応じて、任意のフォルダが選択されることで行われる（図３８参照）。

一方、「自動」の場合には、遷移画面（図３６，図３７参照）における「テストデータの投入・正解ファイルの作成／配置」ボックスが赤色などで着色されて処理実行中であることが示された後（ステップ４００３）、テストデータの投入処理（ステップ４００４）及び正解ファイルの作成／配置処理（ステップ４００５～４００９）が実行される。
まず、テストデータの投入処理は、移行元データベース１００のデータを逐次取り出して、移行先データベース２００に入力・投入することにより行われる（ステップ４００４）。

次に、正解ファイルの作成／配置処理は、前の処理（図３９参照）で作成されたＳＱＬファイルを逐次読み込み、全てのＳＱＬファイルについて処理が実行される（ステップ４００５）。
具体的には、まず、オープン中のファイル名を記録しておき（ステップ４００６）、読み込まれたＳＱＬを移行先データベース２００に対して発行して、以下の項目についてデータを記憶させる（ステップ４００７）。
・結果
・ＣＰＵ使用率
・メモリ使用率
・応答時間

正解ファイルが別名で保存される（ステップ４００８）。ファイル名は、例えオープン中の結果ファイル名の直後に「＿正解」等と付与することで生成できる。
そして、正解マッピングファイルをオープン中のファイル名で検索し、対応する正解ファイル名の横に正解ファイル名を記載して（ステップ４００９）、正解ファイルの作成配置処理は終了となる。
その後は、進捗表示画面の進捗が進められて（ステップ４０１０）、次の代表ＳＱＬの決定処理に移行する。

［代表パターン：代表ＳＱＬの決定］
図４１～図４３に「代表パターン：代表ＳＱＬの決定」処理のフローチャートを示す。
この代表ＳＱＬ決定処理は、図４１に示すように、まず、ＳＱＬを基本構文に従って「ＳＥＬＥＣＴ，ＵＰＤＡＴＥ，ＩＮＳＥＲＴ，ＤＥＬＥＴＥ」の４分類にインプットを仕分ける処理が行われる（ステップ４１０１～４１０２）。
具体的には、ＳＱＬファイルが１ファイル毎に読み込まれ、この読み込み処理が最終ファイルまで繰り返し実行される（ステップ４１０１）。
そして、ＳＱＬ分類仕分けサブルーチンが呼び出されて、ＳＥＬＥＣＴ／ＵＰＤＡＴＥ／ＩＮＳＥＲＴ／ＤＥＬＥＴＥの４つのディレクトリにコピーファイルが配置される（ステップ４１０２）。

以降、図４２及び図４３に示すように、ＳＥＬＥＣＴ／ＵＰＤＡＴＥ／ＩＮＳＥＲＴ／ＤＥＬＥＴＥの構文系ごとの４系統で構成図の作成処理が実行される。このような４多重で構造図を作成することにより、処理の高速化を図ることができるようになる。
まず、ＳＱＬファイルが１ファイル毎に読み込まれ、最終ファイルまで繰り返し読み込み処理が実行される（ステップ４２０１）。
次いで、ＳＱＬ構造図作成についてのサブルーチンが呼び出され、ＳＱＬファイルからＳＱＬ構造図が生成される（ステップ４２０２：図１４～図２０）。
なお、サブルーチンの具体的な内容については説明を割愛するが、サブルーチンは、公知のプログラミング技術を用いて、上述したＳＱＬ構造図の作成アルゴリズム（図１１～図３４参照）を実行可能なプログラムを作成することにより実現される。以下、サブルーチンについては同様である。

続いて、図４３に示すように、ＳＱＬ構造図ファイルが１ファイル毎に読み込まれ、最終ファイルまで繰り返し読み込み処理が実行される（ステップ４３０１）。
そして、ＳＱＬ構造図収れんについてのサブルーチンが呼び出され、代表ＳＱＬ構造図が決定される（ステップ４３０２：図２１～図２５）。
また、構造図化される前のＳＱＬファイルが、ＳＱＬマッピングファイルが参照されて、代表ＳＱＬディレクトリに格納される（ステップ４３０２）。
その後は、進捗表示画面の進捗が進められて（ステップ４３０３）、次の代表ＳＱＬによるテスト処理に移行する。

［代表パターン：テスト実施（現行保証／進化／退化）］
図４４～図４７に「代表パターン：テスト実施（現行保証／進化／退化）」処理のフローチャートを示す。
このテスト処理では、図４４に示すように、まず、代表ＳＱＬディレクトリからＳＱＬファイルが１ファイル毎に読み込まれ、最終ファイルまで繰り返し実行される（ステップ４４０１）。ここでは、まず移行先データベース２００において移行元データベース１００と同様の結果が得られるか否かについてのテストから開始される。
具体的には、現行保証テストのサブルーチンが呼び出されてテストが実行される（ステップ４４０２）。テストは、前の処理（図４１～図４３参照）で決定されたＳＱＬを移行先データベース２００に対して発行し、正解マッピングファイルを参照して正解と比較することにより行われる。

そして、移行先データベース２００についてのテストの結果が、移行元データベース１００と一致するか否かが判定され（ステップ４４０３）、テスト結果が同じ場合には「進化」処理・テスト（図面左側のフロー）が実行され、テスト結果が異なる場合には「退化」処理・テスト（図面右側のフロー）が実行される。
まず、テスト結果が代表パターンポートファイルに出力され（ステップ４４０４）、その後、１行目の始めの空白出現までに「ＳＥＬＥＣＴ」が在るか否かが判定され（ステップ４４０５）、「ＳＥＬＥＣＴ」が在る場合には、進化／退化回数として「１」がセットされる（ステップ４４０６）。一方、「ＳＥＬＥＣＴ」がない場合には進化／退化処理は行われず、テスト処理は終了となる。

続いて、進化／退化サブルーチンが呼び出され、進化／退化ＳＱＬが生成されて（ステップ４４０７：図２６，図２７，図３１，図３２参照）、進化／退化されたＳＱＬが代表ＳＱＬディレクトリに格納される。
次に、自動データ増幅サブルーチンが呼び出され、進化／退化されたＳＱＬについて、自動でデータ作成が行われ、正解マッピングファイルに自動で正解データが登録される（ステップ４４０８：図２８，図２９，図３３，図３４参照）。
その後、進化／退化テストのサブルーチンが呼び出されて、進化／退化されたＳＱＬを移行先データベース２００に対して発行し、正解マッピングファイルを参照して正解と比較することにより、１回目の進化／退化テストが実行される（ステップ４４０９）。

そして、進化／退化テストの結果が、移行元データベース１００と一致するか否かが判定され（ステップ４４１０）、テスト結果が一致する場合には「２回目」の進化／退化処理・テスト（図面各左側のフロー）が実行され、テスト結果が異なる場合には処理は終了となる（図面各右側のフロー）。
図４５に示すように、まず、進化／退化テスト結果が移行元データベース１００と異なる場合には、代表パターンポートファイルに出力された後（ステップ４５０１）、進捗表示画面の進捗が進められて（ステップ４５０２）処理は終了となる。
一方、進化／退化テスト結果が移行元データベース１００と一致する場合には、代表パターンポートファイルに出力された後（ステップ４５０３）、進化／退化回数として「２」がセットされる（ステップ４５０４）。
そして、１回目と同様に、進化／退化サブルーチン（ステップ４５０５），自動データ増幅サブルーチン（ステップ４５０６），進化／退化テストサブルーチン（ステップ４５０７）の各サブルーチンが呼び出されて、進化／退化処理とテスト処理が実行される。

その後、進化／退化テストの結果が、移行元データベース１００と一致するか否かが判定され（ステップ４５０８）、テスト結果が一致する場合には「３回目」の進化／退化処理・テスト（図面各左側のフロー）が実行され、テスト結果が異なる場合には処理は終了となる（図面各右側のフロー）。
すなわち、図４６に示すように、２回目の進化／退化テスト結果が移行元データベース１００と異なる場合は、代表パターンポートファイルに出力された後（ステップ４６０１）、進捗表示画面の進捗が進められて（ステップ４６０２）処理は終了する。
一方、２回目の進化／退化テスト結果が移行元データベース１００と一致する場合には、代表パターンポートファイルに出力された後（ステップ４６０３）、進化／退化回数として「３」がセットされ（ステップ４６０４）、その後は、同様に進化／退化サブルーチン（ステップ４６０５），自動データ増幅サブルーチン（ステップ４６０６），進化／退化テストサブルーチン（ステップ４６０７）が呼び出されて、進化／退化処理とテスト処理が実行される。

そして、３回目の進化／退化テストについては、テスト結果が移行元データベース１００と一致するか否かが判定された後は（ステップ４６０８）、図４７に示すように、テスト結果の如何を問わず、テスト結果が代表パターンポートファイルに出力された後（ステップ４７０１）、進捗表示画面の進捗が進められて（ステップ４７０２）処理は終了となる。
これは、進化／退化処理については、３回程度行えば、進化によるシステム拡張等の予測や、退化によるシステムの改善検出などは十分可能であるからである。
但し、以上のような進化／退化処理・テストを、４回以上や２回以下とすることも勿論可能であり、システムの規模やコスト等を考慮して、適宜任意の回数を実行することができる。

［特殊関数：代表ＳＱＬの決定］
図４８に「特殊関数：代表ＳＱＬの決定」処理のフローチャートを示す。
この特殊関数の代表ＳＱＬ決定処理では、図４８に示すように、まず、特殊関数ファイル（図３５参照）をオープンして、登録されている関数を記憶手段に記憶させる（ステップ４８０１）。
その後、登録されている関数１つずつに対して、各ＳＱＬ中に該当する関数が存在するか否かが確認されて（ステップ４８０２）、特殊関数テストが実行される（ステップ４８０３～４８０５）。

具体的には、ＳＱＬファイルが１ファイル毎に読み込まれ、最終ファイルまで繰り返し実行される（ステップ４８０３）。
そして、読み込まれたＳＱＬ中に、該当関数が存在するか否かが判定され（ステップ４８０４）、該当する関数が存在しない場合には、特殊関数テストは終了となる。
一方、ＳＱＬ中に該当する関数が存在する場合には、ＳＱＬファイルが別名で保存される（ステップ４８０５）。ファイル名は、例えばオープン中の結果ファイル名の後に「＿関数名」などを付与することで生成することができる。
その上で、ＳＱＬファイルが特殊関数用ディレクトリに格納され、特殊関数用正解マッピングファイルに追記される（ステップ４８０５）。これによって、特集関数を含む代表ＳＱＬが決定されることになる。
その後は、進捗表示画面の進捗が進められて（ステップ４８０６）、処理は終了となる。

［特殊関数：テスト実施］
図４９に「特殊関数：テスト実施及びレポート作成」処理のフローチャートを示す。
まず、特殊関数のテスト処理は、図４９に示すように、まず、上述した特殊関数ファイル格納用ディレクトリからＳＱＬファイルが１ファイル毎に読み込まれ、最終ファイルまで繰り返し実行される（ステップ４９０１）。
そして、特殊関数用の現行保証テストのサブルーチンが呼び出されてテストが実行される（ステップ４９０２）。テストは、前の処理（図４８参照）で決定された代表ＳＱＬを移行先データベース２００に対して発行し、特殊関数用の正解マッピングファイルを参照して正解と比較することにより行われる。
その後、移行先データベース２００についてのテストの結果が、移行元データベース１００と一致するか否かが判定され（ステップ４９０３）、テスト結果が同じ場合には、特殊関数レポートファイルに「ＯＫ」を出力し（ステップ４９０４）、テスト結果が異なる場合には、特殊関数レポートファイルに「ＮＧ」を出力して（ステップ４９０５）、処理は終了となる。

［テスト結果レポート作成］
図５０に「代表パターン／特殊関数：テスト実施及びレポート作成」処理のフローチャートを示す。
代表パターン／特殊関数のテスト結果のレポート作成処理は、図５３に示すような処理が実行される（ステップ５００１～５００３）。

［代表パターン］
まず、代表パターンの結果レポートとしては、以下のような内容を生成・出力することができる（ステップ５００１）。
(1)代表パターンレポートファイル（サマリ部分）
このサマリ部分には、以下のような結果を出力することができる。
・総試験ＳＱＬ数をカウントアップし本数を出力。
・代表パターンレポートファイルの「現行保証テスト」列を「ＯＫ」で検索してヒットした本数を出力。
・代表パターンレポートファイルの「ＩＮＰＵＴ－ＳＱＬファイル名」列と「現行保証テスト」列の応答時間を引き算してマイナス値となった本数を出力。
(2)代表パターンレポートファイル（退化テスト部分）
この退化テスト部分には、以下のような結果を出力することができる。
・代表パターンレポートファイルの退化テスト３回目のＳＱＬ本数をカウントし退化数３と本数を出力。
・発見されなかったら２回目のＳＱＬ本数をカウントし退化数２と本数を出力。
・発見されなかったら１回目のＳＱＬ本数をカウントし退化数１と本数を出力。
・発見されなかったら退化数０，本数０を出力。
(3)代表パターンレポートファイル（退化テスト部分）
この進化テスト部分には、以下のような結果を出力することができる。
・代表パターンレポートファイルの進化テスト３回目のＳＱＬ本数をカウントし進化数３と本数を出力。
・発見されなかったら２回目のＳＱＬ本数をカウントし進化数２と本数を出力。
・発見されなかったら１回目のＳＱＬ本数をカウントし進化数１と本数を出力。
・発見されなかったら進化数０，本数０を出力。

［特殊関数］
次に、特殊関数の結果レポートとしては、以下のような内容を生成・出力することができる（ステップ５００２）。
特殊関数レポートファイル（サマリ部分）
・総試験ＳＱＬ数をカウントアップし本数を出力。
・代表パターンレポートファイルの「現行保証テスト」列を「ＯＫ」で検索しヒットした本数を出力。
・代表パターンレポートファイルの「ＩＮＰＵＴ－ＳＱＬファイル名」列と「現行保証テスト」列の応答時間を引き算してマイナス値となった本数を出力。

［その他の情報］
さらに、上記以外のその他の情報として、以下のような内容を生成・出力することができる（ステップ５００２）。
具体的には、システムクロックを利用して日付日時を取得して、以下のような果を出力することができる。
・ディレクトリを作成
ネーミングルール：「年月日＿時＿回数」（例えば、６桁＿２桁／２４時間表記＿４桁／最大１０００）
・データコピー
データの中身：上記ＩＮＰＵＴ－ＳＱＬファイル格納ディレクトリ～結果レポート格納ディレクトリまで一式を、ディレクトリ構造を保ったまま格納

そして、以上のようなレポート結果出職処理が行われると、その後、進捗表示画面の進捗が進められて（ステップ５００４）、処理は終了となる。

以上説明したように、本システム１０によれば、移行元データベース１００から移行先データベース２００へのマイグレーションに際して、移行元で稼動されているＳＱＬを所定の画像に置換してパターン化し、進化／退化させることにより、効率的な動作確認や、システムの拡張・変更等の試験を行うことが可能となる。
これによって、安心／安全なデータベース移行を実現でき、例えばプロジェクト工期の予期せぬ長期化や品質低下等の問題を有効に防止することができるようになる。

以上、本発明について好ましい実施形態を示して説明したが、本発明は、上述した実施形態に限定されるものではなく、本発明の範囲で種々の変更実施が可能であることは言うまでもない。
例えば、上述した実施形態では、本システム１０が対象とするデータベース言語としてＳＱＬを例にとって説明したが、本発明は、ＳＱＬ以外のデータベース言語を対象とすることも勿論可能である。
すなわち、本発明は、データベースシステムに適用・発行されて、データベースに格納されたデータの出し入れに用いられるデータベース言語であれば、どのような言語に対しても適用することが可能である。

また、上述した実施形態で示したアルゴリズム（図２～図３５）やフローチャート（図３６～図５０）は、本発明を実施するための一例であり、同図に示される形態に限定されず、本発明の技術思想を実現できる限り、他のアルゴリズム等を採用することは勿論可能である。
また、上述した実施形態では、大規模なデータシステム・ＳＱＬを想定して説明しているが、本発明は、ＳＱＬを含むデータベースの規模や構成などに限定されず、マイグレーションが行われる各種データベースに適用することができるものである。

本発明は、例えば製品変更や機能の拡張・変更・縮減、ハードディスク資源の交換等の理由によってデータシステムの入れ替えや移行（マイグレーション）を支援するシステムとして好適に利用可能である。

１０ データベースマイグレーション支援システム
１１ データベース言語入力部
１２ 構造図作成部
１３ 収れん処理部
１４ 進化／退化処理部
１５ 代表パターン生成部
１６ 代表パターンテスト実行部
１７ 特殊関数テスト実行部
１８ レポート出力部
１００ 移行元データベース
２００ 移行先データベース

Claims (5)

1. 移行元データベースから移行先データベースへのデータベースのマイグレーションを支援するシステムであって、
   前記移行元データベースのデータベース管理システムに実装される、所定のデータベース言語で作成されたデータベース言語文を入力するデータベース言語入力部と、
   前記データベース言語入力部で入力されたデータベース言語文の文字列を分解し、所定の画像に置換して、当該データベース言語の構造図を作成する構造図作成部とを備え、
   前記構造図作成部で作成された構造図に基づいて、前記移行先データベースにおける前記データベース言語文の動作確認テストを実行する
   ことを特徴とするデータベースマイグレーション支援システム。
2. 前記構造図作成部で作成された構造図に、同一構造が含まれているか否かを検索し、同一構造が含まれる場合には一方を破棄することにより、前記構造図を収れんする収れん処理部と、
   前記収れん処理部で収れんされた構造図を元の文字列に置換して、最小数にパターン化された代表データベース言語文を生成する代表パターン生成部とを備え、
   前記代表パターン生成部で生成された代表データベース言語文に基づいて、前記移行先データベースにおける前記データベース言語文の動作確認テストを実行する
   ことを特徴とする請求項１に記載のデータベースマイグレーション支援システム。
3. 前記代表パターン生成部で生成された代表データベース言語文について、所定の正解データを用いたテストを実行する代表パターンテスト実行部と、
   前記代表パターンテスト実行部のテスト結果を出力するレポート出力部とを備える
   ことを特徴とする請求項２に記載のデータベースマイグレーション支援システム。
4. 前記収れん処理部で収れんされた構造図に、構造を追加して進化させ、又は構造を削除して退化させる進化／退化処理部を備え、
   前記代表パターン生成部が、
   前記進化／退化処理部で進化又は退化された構造図を文字列に置換して、前記代表データベース言語文を生成する
   ことを特徴とする請求項２又は３に記載のデータベースマイグレーション支援システム。
5. 前記データベース言語入力部で入力されたデータベース言語の文字列に、所定の特殊関数が含まれているか否かを検索し、所定の特殊関数が含まれる場合には、当該特殊関数について、所定の正解データを用いたテストを実行する特殊関数テスト実行部を備える
   ことを特徴とする請求項１乃至４のいずれか一項に記載のデータベースマイグレーション支援システム。

Images