(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-04-07
(45)【発行日】2022-04-15
(54)【発明の名称】データベースマイグレーション支援システム及びプログラム
(51)【国際特許分類】
G06F 16/21 20190101AFI20220408BHJP
G06F 11/36 20060101ALI20220408BHJP
【FI】
G06F16/21
G06F11/36 168
(21)【出願番号】P 2018104207
(22)【出願日】2018-05-31
【審査請求日】2021-04-02
(73)【特許権者】
【識別番号】000155469
【氏名又は名称】株式会社野村総合研究所
(74)【代理人】
【識別番号】110002354
【氏名又は名称】弁理士法人平和国際特許事務所
(72)【発明者】
【氏名】大塚 紳一郎
【審査官】原 秀人
(56)【参考文献】
【文献】特開平05-204985(JP,A)
【文献】国際公開第2008/056438(WO,A1)
【文献】特開2006-227958(JP,A)
【文献】特開平8-190479(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/00-16/958
G06F 11/36
(57)【特許請求の範囲】
【請求項1】
移行元データベースから移行先データベースへのデータベースのマイグレーションを支援するシステムであって、
前記移行元データベースのデータベース管理システムに実装される、所定のデータベース言語で作成されたデータベース言語文を入力するデータベース言語入力部と、
前記データベース言語入力部で入力されたデータベース言語文の文字列を分解し、所定の画像に置換して、当該データベース言語の構造図を作成する構造図作成部とを備え
、
前記構造図作成部で作成された構造図に基づいて、前記移行先データベースにおける前記データベース言語文の動作確認テストを実行する
ことを特徴とするデータベースマイグレーション支援システム。
【請求項2】
前記構造図作成部で作成された構造図に、同一構造が含まれているか否かを検索し、同一構造が含まれる場合には一方を破棄することにより、前記構造図を収れんする収れん処理部と、
前記収れん処理部で収れんされた構造図を元の文字列に置換して、最小数にパターン化された代表データベース言語文を生成する代表パターン生成部とを備え
、
前記代表パターン生成部で生成された代表データベース言語文に基づいて、前記移行先データベースにおける前記データベース言語文の動作確認テストを実行する
ことを特徴とする請求項1に記載のデータベースマイグレーション支援システム。
【請求項3】
前記代表パターン生成部で生成された代表データベース言語
文について、所定の正解データを用いたテストを実行する代表パターンテスト実行部と、
前記代表パターンテスト実行部のテスト結果を出力するレポート出力部とを備える
ことを特徴とする請求項2に記載のデータベースマイグレーション支援システム。
【請求項4】
前記収れん処理部で収れんされた構造図に、構造を追加して進化させ、又は構造を削除して退化させる進化/退化処理部を備え、
前記代表パターン生成部が、
前記進化/退化処理部で進化又は退化された構造図を文字列に置換して、前記代表データベース言語
文を生成する
ことを特徴とする請求項2又は3に記載のデータベースマイグレーション支援システム。
【請求項5】
前記データベース言語入力部で入力されたデータベース言語の文字列に、所定の特殊関数が含まれているか否かを検索し、所定の特殊関数が含まれる場合には、当該特殊関数について、所定の正解データを用いたテストを実行する特殊関数テスト実行部を備える
ことを特徴とする請求項1乃至4のいずれか一項に記載のデータベースマイグレーション支援システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データベースを管理・運用するための支援技術に関し、特に、データベースのマイグレーション(移行・変換)を効率的に行えるようにするデータベースマイグレーション支援システム及びプログラムに関する。
【背景技術】
【0002】
データベースは、例えば、製品変更や、機能の拡張・縮減、ハードディスク資源の交換等の理由により、現行システムを新システムに移行・切り替え(マイグレーション)することが行われる。
これまで、このようなデータベースのマイグレーションに際して、移行先のシステムにおける現行システムと同様の処理・機能を保証しつつ、データベースの移行が効率的に行われるように、各種の支援システムが提案されている。
【0003】
例えば、特許文献1には、GUIを介した操作者の操作に基づき、移行元のSQL(データベース言語:Structured Query Language)に対応した移行先のSQLを自動で生成することにより、操作者の習熟度に依存しない、汎用性・操作性に優れたデータベースの移行方法が提案されている。
また、特許文献2には、移行元のSQLを移行先のSQLに変換する場合に、両者における不一致のSQL文を特定することにより、適切に変換されなかったSQL文を自動抽出するデータ変換方法が提案されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2002-351710号公報
【文献】特開2011-258002号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、特許文献1や特許文献2に開示されている技術は、移行先の新システムに対して、新たにSQLを生成することを前提としており、移行元の現在稼働中のシステムのSQLを移行先に適用・発行した場合の検証や動作保証の問題については想定されてない。
データベースを新システムに移行する場合、データを記録するハードウェア資源を含むデータベース管理システム(DBMS:DATABASE MANAGEMENT SYSTEM)は、移行先で新たな製品等を導入するものの、データの出し入れに用いるデータベース言語(SQL)については、移行元で使用されているSQLをそのまま用いることが行われる。特に、大規模なデータベースでは、新システムに対応する新たなSQLを改めて一から作成することは、非常に手間やコストがかかることとなり現実的でない。
【0006】
その一方で、移行元のSQLを移行先にそのまま適用した場合に、移行先の動作が正しく担保されないことがある。
データベースでは、DBMSのオプティマイザと呼ばれる「頭脳」の部分が、SQLを解釈して、ハードディスク上に論理的に記録されたデータテーブルから最適なデータ習得を行う「実行計画(プラン)」を生成する。
ところが、このオプティマイザの成熟度レベルが、製品によってマチマチな場合があり、例えば移行元で使用されていた複雑なSQLを移行先にそのまま適用すると、本来とは異なる「間違った結果」が返却されるといったことが起こり得る。つまり、同じSQLであっても、DBMS(オプティマイザ)の製品によって、正しい結果を返却できるものと、そうでないものが存在することがある。
【0007】
SQLは、複雑なものであれば例えば50行を超えるSQL文で構成され、大規模システムでは、そのようなSQLが例えば10万本近く実装されるような場合もある。
このような膨大なSQLを、効率よく確実に検証して動作担保を行うことは、非常に手間と時間がかかるもので、現実には全てのSQLを試験・検証することは困難乃至不可能である。
このような、移行元と移行先で同一のSQLを用いる場合の動作保証や検証などの問題について、上述した特許文献1,2を含めて、有効に対処し得る従来技術は提案されていない。
【0008】
本発明は、以上の課題を解決するために、データベースのマイグレーションに際して、移行先で移行元と同一のSQLを使用する場合に、効率的な動作確認を行うことができるデータベースマイグレーション支援システム及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【0009】
上記目的を達成するため、本発明は、移行元データベースから移行先データベースへのデータベースのマイグレーションを支援するシステムであって、前記移行元データベースのデータベース管理システムに実装される、所定のデータベース言語で作成されたデータベース言語文を入力するデータベース言語入力部と、前記データベース言語入力部で入力されたデータベース言語文の文字列を分解し、所定の画像に置換して、当該データベース言語の構造図を作成する構造図作成部とを備え、前記構造図作成部で作成された構造図に基づいて、前記移行先データベースにおける前記データベース言語文の動作確認テストを実行する構成としてある。
【0010】
また、本発明は、上記のような本発明に係るデータベースマイグレーション支援システムで実行されるプログラムとして構成することができる。
さらに、本発明は、上記のような本発明に係るデータベースマイグレーション支援システム及びプログラムによって実施可能な方法として実施することもできる。
【発明の効果】
【0011】
本発明によれば、データベースのマイグレーションに際して、SQLを構造図化,パターン化することにより、移行先で移行元と同一のSQLを使用する場合に、効率的な動作確認を行うことが可能となる。
【図面の簡単な説明】
【0012】
【
図1】本発明の一実施形態に係るデータベースマイグレーション支援システム(以下「本システム」という)の全体構成を模式的に示す機能ブロック図である。
【
図2】本システムにおけるSQLのパターン化のアルゴリズムを模式的に示す説明図である。
【
図3】パターン化におけるSQLの収れん処理のアルゴリズムを模式的に示す説明図である。
【
図4】収れんされたSQLのテスト処理のアルゴリズムを模式的に示す説明図である。
【
図5】パターン化されたSQLの進化処理のアルゴリズムを模式的に示す説明図である。
【
図6】進化されたSQLのテスト結果を示すレポート出力の一例を示す説明図である。
【
図7】同じく進化されたSQLのテスト結果を示すレポート出力の一例を示す説明図である。
【
図8】SQLのテスト結果の表示順序を変更したレポート出力の一例を示す説明図である。
【
図9】パターン化されたSQLの退化処理のアルゴリズムを模式的に示す説明図である。
【
図10】退化されたSQLのテスト結果を示すレポート出力の一例を示す説明図である。
【
図11】SQLに含まれる「SELECT」文の構造を示す説明図である。
【
図12】同じく、「SELECT」文の構造を示す説明図である。
【
図13】同じく、「SELECT」文の構造を示す説明図である。
【
図14】
図11に示す「SELECT」文の構造を所定の構造図に置換する手法を示す説明図である。
【
図15】同じく、
図12に示す「SELECT」文を構造図に置換する場合の説明図である。
【
図16】同じく、
図13に示す「SELECT」文を構造図に置換する場合の説明図である。
【
図17】「INSERT」文を構造図に置換する場合の説明図である。
【
図18】同じく、「INSERT」文を構造図に置換する場合の説明図である。
【
図19】「UPDATE」文を構造図に置換する場合の説明図である。
【
図20】「DELETE」文を構造図に置換する場合の説明図である。
【
図21】生成された構造図をマッピングする手法を示す説明図であり、構造図が「SELECT」文の場合である。
【
図22】同じく、「INSERT」文の構造図をマッピングする場合の説明図である。
【
図23】マッピングされた構造図の収れん処理の手法を示す説明図である。
【
図24】同じく、構造図の収れん処理の手法を示す説明図である。
【
図25】同じく、構造図の収れん処理の手法を示す説明図である。
【
図26】マッピングされた構造図の進化処理の手法を示す説明図である。
【
図27】同じく、構造図の進化処理の手法を示す説明図である。
【
図28】進化処理された構造に対応するデータを自動生成する手法と出力結果を示す説明図である。
【
図29】同じく、進化処理された構造に対応するデータの自動生成の手法と出力結果を示す説明図である。
【
図30】出力データを入れ替えて出力・表示させる手法を示す説明図である。
【
図31】マッピングされた構造図の退化処理の手法を示す説明図である。
【
図32】同じく、構造図の退化処理の手法を示す説明図である。
【
図33】退化処理された構造に対応するデータの出力結果を示す説明図である。
【
図34】同じく、退化処理された構造に対応するデータの出力結果を示す説明図である。
【
図35】特殊関数ファイルの一例を示す説明図である。
【
図36】本システムにおける移行元と移行先のSQLの動作確認処理の工程を示すフローチャートである。
【
図37】動作確認処理における画面表示の一例を示す説明図である。
【
図38】同じく、動作確認処理における画面表示の一例を示す説明図である。
【
図39】
図36の「代表パターン:SQLファイルの作成/配置」処理のフローチャートである。
【
図40】
図36の「代表パターン:テストデータの投入・正解データの作成/配置」処理のフローチャートである。
【
図41】
図36の「代表パターン:代表SQLの決定」処理のフローチャートである。
【
図42】同じく、「代表パターン:代表SQLの決定」処理のフローチャートである。
【
図43】同じく、「代表パターン:代表SQLの決定」処理のフローチャートである。
【
図44】
図36の「代表パターン:テスト実施(現行保証/進化/退化)」処理のフローチャートである。
【
図45】同じく、「代表パターン:テスト実施(現行保証/進化/退化)」処理のフローチャートである。
【
図46】同じく、「代表パターン:テスト実施(現行保証/進化/退化)」処理のフローチャートである。
【
図47】同じく、「代表パターン:テスト実施(現行保証/進化/退化)」処理のフローチャートである。
【
図48】
図36の「特殊関数:代表SQL決定」処理のフローチャートである。
【
図49】
図36の「特殊関数:テスト実施」処理のフローチャートである。
【
図50】
図36の「代表パターン/特殊関数:結果レポート作成」処理のフローチャートである。
【発明を実施するための形態】
【0013】
以下、本発明に係るデータベースマイグレーション支援システム及びプログラムの実施形態について、図面を参照しつつ説明する。
ここで、以下に示す本発明のデータベースマイグレーション支援システムは、プログラム(ソフトウェア)の命令によりコンピュータで実行される処理,手段,機能によって実現される。プログラムは、コンピュータの各構成要素に指令を送り、以下に示す本発明に係る所定の処理や機能等を行わせることができる。すなわち、本発明における各処理や手段,機能は、プログラムとコンピュータとが協働した具体的手段によって実現される。
【0014】
なお、プログラムの全部又は一部は、例えば、磁気ディスク,光ディスク,半導体メモリ,その他任意のコンピュータで読取り可能な記録媒体により提供され、記録媒体から読み出されたプログラムがコンピュータにインストールされて実行される。また、プログラムは、記録媒体を介さず、通信回線を通じて直接にコンピュータにロードし実行することもできる。
また、本システムは、単一の情報処理装置(例えば一台のパーソナルコンピュータ等)で構成することもでき、複数の情報処理装置(例えば複数台のサーバコンピュータ群等)で構成することもできる。
【0015】
[システム構成]
図1に示すように、本システム10は、移行元データベース100から移行先データベース200へのデータベースのマイグレーションを支援するシステムであり、所定の情報処理装置、例えば1又は2以上のサーバコンピュータ等によって構成することができる。
なお、特に図示していないが、本システム10を構成する情報処理装置には、演算手段・記憶手段・入力手段・出力手段などのハードウェア資源、所定のアプリケーション/データなどのソフトウェア資源が備えられていることは言うまでもない。
【0016】
移行元データベース100は、現在稼動中の情報処理装置(現行稼動機)であって、対象データを記録したハードディスク等のハードウェア資源を含むデータベース管理システム(DBMS)と、データの出し入れに用いられる所定のデータベース言語で作成されたデータベース言語文あるSQLなどによって構成されている。なお、この移行元データベース100には、現在は稼動していないが過去に正常に稼働していたデータベース等も当然に含まれる。
移行先データベース200は、新規に稼動を予定している情報処理装置であって、ハードウェア資源,DBMSなどによって構成されている。この移行先データベース200についても、過去に稼動していたデータベース等も含まれる。
【0017】
ここで、移行元データベース100と移行先データベース200のDBMSやハードウェア構成が同一であれば、データを移行させるだけ、移行元のSQLを使用することで、基本的には移行先での動作は保証されており、動作試験は確認的に行えば良いことになる。
したがって、本システム10は、特に移行元データベース100と移行先データベース200において、DBMSやハードウェア構成が異なる場合、例えば、移行元と移行先でデータベース製品が異なり、実装されているDBMSのオプティマイザの成熟度レベルに差異がある場合、ハードディスクの構成が移行先と移行元で共有ディスク型と分散ディスク型で異なっている場合、などにおけるデータベース移行支援に好適である。
但し、移行元/移行先のデータベース構成が同一の場合でも、本システム10を適用して、移行先の動作確認や拡張・変更機能の確認などを行うことは勿論可能である。
【0018】
本システム10では、
図1に示すように、現行稼動している移行元データベース100から、実行済みのSQL情報とデータを取得して、移行先データベース200に対してデータを入れて、同じSQLが同じ結果を出力するかどうか、同じ性能で動作するか(例えばCPU・メモリ使用率・処理時間などが同じか)の稼動確認を行うようになっている。
なお、本システム10は、移行元データベース100と移行先データベース200の双方と通信できる場合には、上記のような稼動確認処理を自動で実行することができる。
また、例えば移行元と移行先のデータベースが異なるシステムインテグレータ等によって提供される場合など、本システム10が移行元データベース100と通信できない環境にある場合には、動作確認を行うSQL/データをユーザ等が手動で用意することで、本システム10での稼動確認処理を作動させることができる。
【0019】
ここで、本システム10が対象とする移行元データベース100で稼動しているSQLは、例えば400行以上のSQL文、30以上の利用テーブル数などのSQLが10万本近くになるなど、複雑で膨大なキャラクタデータ(ソースコード)によって構成されることがある。
このような規模のSQLについて、稼動確認用データ及び正しい結果を用意することは、多大な労力と時間がかかり、SQLの全てについて検証を行うことは困難乃至不可能であり、実際には何本もチェックできないのが現実である。
このような課題に対して、本システム10では、対象となるSQLをパターン化し、効率的な動作確認を実施できるようにし、これによって、安心/安全なデータベース移行を実現し、プロジェクト工期の予期せぬ長期化や、品質低下等を防ぐことができるものである。
【0020】
具体的には、本システム10では、移行元データベース100から稼動中のSQLを入力することにより、大きく以下のような「SQLのパターン化」,「進化テスト」,「レポート出力」の3つの処理が実行されるようになっている。
[SQLのパターン化処理]
SQLをパターン化して最小本数化を行い、それによってテストの効率化を図るものである。
具体的には、パターン化処理は、大要以下の3つの処理が実行される。
(1)4分類(SELECT・UPDATE・INSERT・DELETE)
SQLを4つの基本構文(SELECT・UPDATE・INSERT・DELETE)に従って分類・抽出する処理である。
(2)構造図の作成
分類された各基本構文について、所定の構造図を示す画像を当てはめて置換し、キャラクタデータを画像データに変換する処理である。
(3)収れん処理
生成された構造図について、同一・重複構造を削除することにより、構造図全体を収れん・縮減させる処理である。
【0021】
[進化テスト処理]
(1)テスト
収れん処理された構造図を元のSQLのキャラクタデータに変換してテストを実行する処理である。
(2)進化SQLの自動生成
収れん処理された構造図を進化させることにより、進化されたSQLを自動生成する処理である。この進化SQLをテストすることにより、将来的な今後の開発を予測した応用確認などの進化テストが可能となる。
(3)進化SQLに対応した自動データ増幅による応用テスト
進化SQLに対応した仮想データを自動生成する処理であり、進化テストを効率的に実行できるようになる。
【0022】
[レポート出力処理]
上述し進化テストを含むテスト結果を出力処理である。
これによって、移行先データベース200における動作確認を、表示画面等で視覚を通じて確認できるとともに、進化テストの結果なども容易に確認できるようになる。
【0023】
[機能構成]
上記のような各処理を実行するために、本システム10は、
図1に示すように、データベース言語入力部11,構造図作成部12,収れん処理部13,進化/退化処理部14,代表パターン生成部15,代表パターンテスト実行部16,特殊関数テスト実行部17,レポート出力部18の各部として機能するように構成される。
データベース言語入力部11は、移行元データベース100のDBMSに実装されている所定のデータベース言語で作成されたデータベース言語文であるSQLを入力する。
構造図作成部12は、データベース言語入力部11で入力されたSQLの文字列を分解し、所定の画像に置換して、当該SQLの構造図を作成する。このようなSQLを構造図に変換・作成することができる本システム10では、以下に示すような代表SQLに基づく検証・テストを自動で行うことができる他、例えば、システムを管理するシステムエンジニア等の人間が、構造図を目視で確認・チェックすることで、テスト数を減らすようなことも可能となる。
【0024】
収れん処理部13は、構造図作成部12で作成された構造図に、同一構造が含まれているか否かを検索し、同一構造が含まれる場合には一方を破棄することにより、構造図を収れんする。
進化/退化処理部14は、収れん処理部13で収れんされた構造図に、構造を追加して進化させ、又は構造を削除して退化させる。
【0025】
代表パターン生成部15は、収れん処理部13で収れんされた構造図を元の文字列に置換して、最小数にパターン化された代表SQL(代表データベース言語文)を生成する。
また、代表パターン生成部15は、進化/退化処理部14で進化又は退化された構造図を文字列に置換して、代表SQLを生成する。
代表パターンテスト実行部16は、代表パターン生成部15で生成された代表SQLについて、所定の正解データを用いたテストを実行する。
なお、本システム10では、SQLを構造図に変換した後に、SQLの検証や進化/退化を行うために、構造図から逆変換してSQL文を生成しているが、最初にSQL文から構造図に変換しているため、元のSQL文を記録しておくことにより、構造図の逆変換を行うことなく、記録してある元のSQLを読み出すことによっても、検証や進化/退化を行うことも可能である。
【0026】
特殊関数テスト実行部17は、データベース言語入力部11で入力されたSQLの文字列に、所定の特殊関数が含まれているか否かを検索し、所定の特殊関数が含まれる場合には、当該特殊関数について、所定の正解データを用いたテストを実行する。
レポート出力部18は、代表パターンテスト実行部16や特殊関数テスト実行部17で実行されたテスト結果を出力する。
以上のような本システム10の各部11~18によって実行されるデータベースのマイグレーション支援のための処理・動作の詳細について、図面を参照しつつ以下に詳述する。
【0027】
[アルゴリズム]
まず、
図2~
図35を参照して、本システム10における処理・動作を実現するための具体的なアルゴリズム(手順)について説明する。
[SQLパターン化]
図2に、本システム10におけるSQLのパターン化のアルゴリズムを模式的に示す。
同図に示すように、本システム10に移行元データベース100のSQLが入力されると(データベース言語入力部11)、SQLを構成するソースコードから「1ファイル:1SQL」単位でキャラクタデータが抽出され、1ファイルずつSQLの構文タイプに応じて振り分けられる。
【0028】
具体的には、
図2に示すように、「SELECT系」,「UPDATE系」,「INSERT系」,「DELETE系」に、1ファイルずつSQL文が振り分けられ、所定のSQL格納ディレクトリ(記憶手段)に格納されていく。なお、この処理は、それぞれのディレクトごとにパラレルで処理を行うことにより、処理の高速化を図ることができる。
次に、構文タイプごとに振り分けられたSQL文のキャラクタデータは、1ファイルずつ、所定の構造図への置換・変換処理が行われ(
図14~
図20参照)、構造図ファイルが生成される(構造図作成部12)。
そして、生成された構造図データを、後述する包含関係(
図3参照)を用いた収れん処理によって収れん・縮減されて(収れん処理部13)、「代表パターン」が生成され、膨大なキャラクタデータからなる元のSQLが。収れんされた構造図からなる代表パターンデータにパターン化されることなる(代表パターン生成部15)。
【0029】
[SQLパターン収れん]
図3に、上記のような構造図の収れん処理のアルゴリズムを模式的に示す。
同図に示すように、収れん処理は、構造図の包含関係により収れんさせる。
具体的には、構造図に含まれる複数の構造について、構造が同じ場合には、重複する構造であるとして、一方を他方に包含(破棄)させることにより、構造図を収れんする。
例えば、
図3に示す例では、「UNION」構造が2つのケースは、「UNION」が3つのケースに包含することができる。
このように、構造図の同一構造に着目して、包含(破棄)が可能な対象構造の選定を行う。
【0030】
[テスト]
そして、以上のようにして収れんされた構造図に基づいて、動作確認のテストを行うことができる(代表パターンテスト実行部16)。
図4に示すように、動作確認テストは、構造図によって収れん・パターン化されたSQLについて行われる。これによって、元の膨大なSQLと比較して、収れん・縮減されたSQLについてテストを行えば良く、テストの正しい結果を示す正解データも、少ないデータで対応することができる。これに対して、元のそのままのSQLについてテストを行おうとすれば、全てのSQLに対応する正解データを準備する必要があり、そのような正解データを用意することは、現実に困難乃至不可能である。
なお、テストの正解データは、例えば、テーブルにデータを格納し、予め本システム10の記憶手段などに用意しておくことができる。
【0031】
[SQLパターン進化/退化]
そして、以上のようなテスト処理の結果に応じて、パターン化されたSQLの進化/退化を行うことができる(進化/退化処理部14)。
具体的には、まず、テストの結果、移行先データベース200でも、現行の移行元データベース100と同じ正しい結果が出た場合には、SQLを「進化」させることができる。これによって、移行先データベース200における今後の開発予測等を行うことができるようになる。
一方、テストの結果、移行先データベース200で誤った結果が出た場合には、現行のSQLを「退化」させる。これによって、移行先データベース200において正しい結果の出るSQLを予測・生成することが可能となる。
このようなSQLの進化/退化は、以下に示す自動生成処理によって行うことができ、特に、SQLを進化させた場合には、自動で進化データ及び正解データを生成し、自動データ増幅による応用テスト(進化テスト)を実行することができる。
【0032】
[進化]
図5に、自動進化処理のアルゴリズムを模式的に示す。
まず、SQLを進化させる場合には、
図5に示すように、パターン化されたSQLの構造図について、以下の3つのパターンによりSQLを変化(進化)させることができる。
【0033】
(1)UNIONにより横に伸びる
構造図において、同一構造を横に追加することで、当該構造と同一の機能を追加・拡張することができる。
これによって、例えば、現行システムが属性情報として「購入者」,「購入金額(円)」,「支払い期限日」の3つの項目のデータを管理している「業務システムA」,「業務システムB」,「業務システムC」の3つの機能を実装している場合に、さらに、例えば「業務システムD」などの新サービス・新業務システムの機能を追加・拡張させることができる。
図6に、SQL構造をUNIONにより横に進化させた場合の出力結果の一例を示す(レポート出力部18)。
【0034】
(2)JOINにより縦に伸びる
構造図において、格納データの構造を縦に追加することで、管理データの属性を付加・追加することができ、JOIN数を増加させることができる。
これによって、例えば、管理データの属性として「購入者」,「購入金額(円)」,「支払い期限日」の3つの項目のデータが管理されている「業務システムA」,「業務システムB」,「業務システムC」に対して、それぞれ、「性別:男or女」などの新属性を付与・追加させることができる。
図7に、SQL構造をJOINにより縦に進化させた場合の出力結果の一例を示す。
【0035】
(3)表示順序の調整により間に入る
構造図において、同一構造の横方向の位置を変更することで、表示の順序を変更・調整することができる。これによって、同一構造からなる複数の機能について、任意の機能の表示位置を移動させ、例えば先行表示されていた機能の間に入れることができるようになる。
図8に、表示順序を変更させた場合の出力結果の一例を示す。この例では、管理データとして「購入者」,「購入金額(円)」,「支払い期限日」の3つの項目データを管理している「業務システムA」,「業務システムB」,「業務システムC」の表示の順序を、「業務システムA」,「業務システムC」,「業務システムB」と入れ替えた場合である。
【0036】
[退化]
一方、SQLを退化させる場合には、
図9に示すように、パターン化されたSQLの構造図について、上述した進化と同様の以下の2つのパターンによりSQLを変化(退化)させることができる。
(1)UNIONを削り横に縮む
構造図において、横に並ぶ同一構造の一部を削除することで、当該構造の機能を縮減・退化させることができる。
これによって、例えば、現行システムが「業務システムA」,「業務システムB」,「業務システムC」の3つの機能を実装している場合に、「業務システムC」の機能を削除・縮減させることができる。
図10に、SQL構造についてUNIONを横に退化させた場合の出力結果の一例を示す。
【0037】
(2)JOINを削り縦に縮む
構造図において、縦に並ぶ格納データの構造の一部を削除(JOINテーブルを削除)することで、管理データの属性を縮減・退化させることができる。
なお、SQLを退化させる場合にも、上述した進化の場合と同様に、構造図において、同一構造の横方向の位置を変更することで、表示の順序を変更・調整することができることは言うまでもない。
【0038】
[SQLの構造分解/構造図の作成]
次に、上述したSQLを構成するソースコードをSQLの構文タイプに応じて振り分ける構造分解及び構造図の作成について説明する。
上述のとおり、SQLの構造分解は、SQL文の基本構文に従って、「SELECT系」,「UPDATE系」,「INSERT系」,「DELETE系」の4つの構文に着目して実行される。
基本的には、ソースコード中の「SELECT~;」,「UPDATE~;」,「INSERT~;」,「DELETE~;」を一つの構造の単位として抽出し、そこに含まれるコマンド単位で構文を抽出・分解して、分解された要素ごとに所定の構造図画像に置換・変換が行われる(
図14~
図20)。
【0039】
ここで、SELECT系構文は、他の構文(UPDATE系,INSERT系,DELETE系)にはない構造を記載できるため、まず、SELECT文に特有の構造ついて、
図11~
図13を参照して説明する。
図11~
図13に、SELECT文の構造を分解する場合の説明図を示す。
これらの図に示すように、SELECT文には、3つの構文パターンがある。
図11に示すのは、内部に入れ子構造を取ることができる構文である。
図11に示す例では、データベースの管理データとして、「社員テーブル」と「給与テーブル」の二つのデータテーブルが存在する場合に、例えば「月給30万円以上」の社員番号を選択し、その上で、社員番号を用いて社員名をリストにし、最後に社員番号順で並び替える、というSELECT文となっている。
このような場合には、SELECT文の「WHERE列名=(~)」の「(~)」中に記載されている「入れ子構造」の構文(
図11で太線で囲まれた部分)を含めて、一つのSELECT文の構造として抽出する。
【0040】
図12に示すのは、中間テーブルを一時的に作成して結果を出すことができる構文である。
図12に示す例では、データベースの管理データとして、「社員テーブル」と「退職明細」の二つのデータテーブルが存在する場合に、例えば「退職日」を指定して社員名を取得する、というSELECT文となっている。
このような場合には、「FROM~WHERE」の中に「LEFT OUTER JOIN」で記載されている構文(
図12で太線で囲まれた部分)を含めて、一つのSELECT文の構造として抽出する。
【0041】
図13に示すのは、結果の和集合を作成することができる構文である。
図13に示すSELECT文は、データベースの管理データとして、「拠点A勤務社員テーブル」と「拠点B勤務社員テーブル」の二つのデータテーブルが存在する場合に、例えば拠点別の所属社員表から和集合を出力する、という構文である。
このような場合には、「UNION ALL」で結ばれた2つの「SELECT~FROMテーブル名」の構文(
図13で太線で囲まれた3つの部分)を、一つのSELECT文の構造として抽出する。
【0042】
[構造図画像の作成]
そして、以上のようにしてSQLの基本構文(SELECT,UPDATE,INSERT,DELETE)に従って一構造として抽出されたSQL文について、そこに含まれるコマンド単位で構文を抽出・分解して、分解された要素ごとに所定の構造図画像に置換・変換して、SQLの構造を示す構造図が作成される。
なお、以下に示す所定の構造図を構成する画像は、本システム10の記憶手段などに予め画像データとして格納・記憶させておくものとする。
【0043】
[SELECT文]
図14は、
図11に示したSELECT文を所定の構造図に変換する場合である。
同図に示すように、この場合のSELECT文は、以下のような手順により、SELECT文の各要素がそれぞれ所定の画像に置換されて、一つの構造図として作成される。
(1)構文中の「一番内側にあるテーブル」という意味で「ドラム缶マーク」を一番右側に記載する。
(2)「条件に合致するレコードを抽出」という意味で「片カッコ」を「ドラム缶マーク」の左側に記載する。
(3)「その結果を用いて」という意味で「矢印」を「片カッコ」の左側に記載する。
(4)「別のテーブルのデータと連結して」という意味で「ドラム缶マーク」を「矢印」の左側に記載する。
(5)「該当するレコードもしくは列を抽出」という意味で「片カッコ」を「ドラム缶マーク」の左側に記載する。
以上の処理・手順により、
図14左側(
図11)に示すSELECT文が、
図14右側に示す構造図として置換・生成される。
【0044】
図15は、
図12に示したSELECT文を所定の構造図に変換する場合であり、以下のような手順により、SELECT文が構造図として置換・作成される。
(1)「JOINするテーブル」を示す2つの「ドラム缶マーク」をテーブル名順に一番右側に縦に配置する。
(2)「JOIN種別」及び「矢印」を対応する「ドラム缶マーク」の左側に記載する。
(3)「JOIN先テーブル」を示す「ドラム缶マーク」を「矢印」の左側に配置する。
(4)「その結果を用いて」という意味で「矢印」を「ドラム缶マーク」の左側に記載する。
(5)「別のテーブルのデータと連結して」という意味で「ドラム缶マーク」を「矢印」の左側に記載する。
(6)「該当するレコードもしくは列を抽出」という意味で「片カッコ」を「ドラム缶マーク」の左側に記載する。
以上の処理・手順により、
図15左側(
図12)に示すSELECT文が、
図15右側に示す構造図として置換・生成される。
【0045】
図16は、
図13に示したSELECT文を所定の構造図に変換する場合であり、以下のような手順により、SELECT文が構造図として置換・作成される。
(1)一つ目のSELECT文を示す「ドラム缶マーク」及び「片カッコ」を一番右側に配置し、それらを「UNION句の上(前)で出力される結果(集合)」を意味する「四角の枠」で括る。
(2)「和集合を作る」という意味で「横線」を「四角の枠」の左側に連結し、「UNION種別」を記載する。
(3) 二つ目のSELECT文を示す「ドラム缶マーク」及び「片カッコ」を一番左側に配置し、それらを「UNION句の下(後)で出力される結果(集合)」を意味する「四角の枠」で括り、「横線」の左側に連結する。
なお、「結果の和集合を作成する」ことが可能なコマンドとしては、「UNION」と「UNION ALL」とが存在するため、構造図を生成する場合には、両者を区別できる画像を割り当てるようにする。
以上の処理・手順により、
図16左側(
図13)に示すSELECT文が、
図16右側に示す構造図として置換・生成される。
【0046】
[INSERT文]
図17は、INSERT文を所定の構造図に変換する場合であり、以下のような手順により、INSERT文が構造図として置換・作成される。
(1)「データ挿入先のテーブル」という意味で「ドラム缶マーク」を一番右側に記載する。
(2)「データ挿入作業」を示す「左から右方向の矢印」を「ドラム缶マーク」の左側に配置する。
(3)「データ挿入の基点」という意味で「INSERT」を示す「黒丸「I」文字」を「矢印」の左側に配置する。
以上の処理・手順により、
図17左側に示すINSERT文が、
図17右側に示す構造図として置換・生成される。
【0047】
図18は、INSERT文として、他のテーブルから検索したデータを挿入することが可能なINSERT文を所定の構造図に変換する場合であり、以下のような手順により、INSERT文が構造図として置換・作成される。
(1)「データ挿入先のテーブル」という意味で「ドラム缶マーク」を一番右側に記載する。
(2)「データ挿入作業」を示す「左から右方向の矢印」を「ドラム缶マーク」の左側に配置する。
(3)「データ挿入の基点」という意味で「INSERT」を示す「黒丸「I」文字」を「矢印」の左側に配置する。
(4)「該当するレコードもしくは列を抽出」という意味で「片カッコ」(SELECT文とは逆向き)を「黒丸「I」文字」の左側に記載する。
(5)「データ挿入先に用いるオリジナルデータを格納したテーブル」という意味で「ドラム缶マーク」を「片カッコ」の左側に記載する。
以上の処理・手順により、
図18左側に示すINSERT文が、
図18右側に示す構造図として置換・生成される。
【0048】
[UPDATE文]
図19は、UPDATE文を所定の構造図に変換する場合であり、以下のような手順により、UPDATE文が構造図として置換・作成される。
(1)「データ更新先のテーブル」という意味で「ドラム缶マーク」を一番右側に記載する。
(2)「データ更新作業」を示す「左から右方向の矢印」を「ドラム缶マーク」の左側に配置する。
(3)「データ更新の基点」という意味で「UPDATE」を示す「黒丸「UP」文字」を「矢印」の左側に配置する。
以上の処理・手順により、
図19左側に示すUPDATE文が、
図19右側に示す構造図として置換・生成される。
【0049】
[DELETE文]
図20は、DELETE文を所定の構造図に変換する場合であり、以下のような手順により、DELETE文が構造図として置換・作成される。
(1)「データ削除先のテーブル」という意味で「ドラム缶マーク」を一番右側に記載する。
(2)「データ削除作業」を示す「左から右方向の矢印」を「ドラム缶マーク」の左側に配置する。
(3)「データ削除の基点」という意味で「DELETE」を示す「黒丸「D」文字」を「矢印」の左側に配置する。
以上の処理・手順により、
図20左側に示すDELETE文が、
図20右側に示す構造図として置換・生成される。
【0050】
[構造図のマッピング/収れん]
次に、以上のようにして作成された構造図のマッピング/収れん処理について説明する。
図21及び
図22は、生成する構造図をマッピングする手法を示す説明図であり、
図21は構造図がSELECT文の場合、
図22はINSERT文の場合である。
これらの図に示すように、マッピングは、例えば「1001マス×1001マス」を初期値とする「方眼マップ」を用意し、このマップ上に構造図を張り付けて実行される。
なお、方眼マップは、初期値として「縦横1001マス」からスタートさせるが、マスが足りない場合には拡張することができる。
また、このような方眼マップのデータについても、上述した構造図の画像データとともに、本システム10の記憶手段などに予め画像データとして格納・記憶させておくものとする。
【0051】
[マッピングルール]
マッピング処理は、以下のルールに基づいて実行される。
まず、SELECT文については、以下のルールとする(
図21参照)。
[SELECT文ルール]
・右端中心から書き始める
・記号:1マスに1つ
・「SELECT」は右から左に順に配置
・「JOIN」は上から下に順に配置
・結果セットを全ての記号が含まれる最小限の大きさの太い枠でくくる
・矢印:記号間を横1マスで接続(接続ポイントは真ん中とする)
「JOIN」種別を区別するために「JOIN」時は矢印の下に区分を記載する
-「JOIN」:「J」を記載
-「LEFT OUTER JOIN」:「LJ」
-「RIGHT OUTER JOIN」:「RJ」
-「FULL OUTER JOIN」:「FJ」
・和集合を作る「UNION」は横線で連結する
「UNION」種別を区別するために、横線の下に区分を記載する
-「UNION」:「U」を記載
-「UNION ALL」:「UA」
・色は白黒で表現
【0052】
同様に、INSERT文・UPDATE文・DELETE文については、以下のルールとする(
図22参照)。
[INSERT文・UPDATE文・DELETE文ルール]
・右端中心から書き始める
・記号:1マスに1つ
・右から左に順に配置
・結果セットを全ての記号が含まれる最小限の大きさの太い枠でくくる
・矢印:記号間を横1マスで接続(接続ポイントは真ん中とする)
左から右に向けて記載する
・テーブルから値を取り出す場合は片カッコを用いる(SELECTとは反対向きとする
・INSERT/UPDATE/DELETEを区別するため基点に区分を記載
-「INSERT」:「I」を記載
-「UPDATE」:「UP」
-「DELETE」:「D」
・色は白黒で表現
【0053】
以上のようなマッピングルールに従い、構造図の収れん処理が実行され、パターン化された代表SQLが決定される。
構造図の収れんは、画像処理による総当たりによって行われる。このような画像処理技術を用いることにより、構造図の収れんを高速かつ正確に実行できるようになる。
[前処理]
まず、収れんの「前処理」として、
図23に示すように、フィラーをマップから削除する処理が実行される。
具体的には、
図23に示す「太い線」以外の余白が削除される。
但し、「UNION」を示す「横線」及び「黒丸」は削除されないようにする。
【0054】
[メイン処理]
次に、収れんの「メイン処理」として、
図24及び
図25に示すように、画像処理による「総当たり」と、それに基づく「包含関係のチェック」が実行される。
まず、「メイン処理」は、以下のような手順により実行される(
図24参照)。
(1)SELECT系/UPDATE系/DELETE系/INSERT系のそれぞれのディレクトリごとに処理を実行する
(2)利用しているマス目順にソートする
(3)最も利用しているマス目の少ない構造図を抽出し、比較対象とする
(4)「(3)」で選択された構造図を、最もマス目の大きい構造図内に同一構造が無いかサーチする(
図25参照)
(5)同じ構造が発見された場合、「(3)」で選択された構造図は上位SQLに包含されているものとして破棄する
(6)「(3)」で選択された構造図の次にマス目の利用数が多い構造図を選択し、「(3)~(5)」と同様の処理を実行する
(7)もし「(3)~(5)」の処理によって「包含」される構造が発見されない場合は、比較対象を2番目に大きな構造図に変更し、同様の処理を実行する
以上の手順を繰り返すことにより、最も複雑なSQLを発見することができる。
【0055】
図25に、上記「(3)~(5)」の包含関係をチェックするサーチ処理の詳細を示す。
同図に示すように、包含関係のサーチは、以下の手順により実行される。
(1)包含チェックの対象となる構造図をマス目の左上に合わせて配置する
(2)対象構造図を右方向に1マスずつ移動させ、同じ構造が無いかをチェックする
(3)対象構造図がマス目の右端まで到達したら、下に1マスずつ移動させ
(4)再びマス目の左から右方向に、対象構造図を1マスずつ移動させて同様のチェックを行い、マス目の右下端まで到達したら終了とする
【0056】
以上の処理を繰り返すことにより、他の構造図に包含される構造図は破棄され、全ての構造図を包含する最も大きい(複雑な)構造図のみが抽出され、それが代表SQLとなる構造図として決定されることになる。
そして、そのように決定された代表SQLを示す構造図を、元のSQLのキャラクタデータ(ソースコード)に変換・復元して、移行先データベース200における動作確認のテストを実行することができるようになる。
これによって、移行先データベース200の動作確認テストを、上述のように構造図によって収れん・パターン化された代表SQLに基づいて実行することができ、元の膨大なSQLと比較して、高速かつ効率的なテストを実行することができ、テストの正解データも少ないデータで対応することができるようになる。
【0057】
[構造図の進化/退化]
以上のように、マッピング/収れん処理によって生成される代表SQLを示す構造図は、さらに、以下のような手順によって進化/退化(
図5,
図9)させることができる。
構造図の進化/退化処理は、上述した構造図の生成と同様に、マス目を用いた画像処理によって実行することができる。
【0058】
[進化処理]
図26~
図30に、構造図の進化処理の手法を示す。
図26は、進化処理の1つ目である「UNION」により「横に伸びる」進化(
図5参照)をさせる場合である。
具体的には、構造図中に「UNION」を示す「U」もしくは「UA」の記号が含まれる場合、
図26に示すように、その「UNION」」で連結された既存構造を、マス目上で半分のマス目分だけ左方向にシフトさせる。
その後、同一構造図をコピーにより生成し、シフトさせた既存構造の右側に張り付け、「UNION」で連結して、構造図を保存する。
これによって、横方向への構造拡張(進化)が行われる。
同様の処理を繰り返すことで、任意の数だけ、横方向への拡張を行うことできる。
【0059】
図27は、進化処理の2つ目である「JOIN」により「縦に伸びる」進化(
図5参照)をさせる場合である。
具体的には、構造図中に「JOIN」を示す「J」,「LJ」,「RJ」,「FJ」の記号が含まれる場合、
図27に示すように、その「JOIN」により縦方向に配置されている「データ」を示す「ドラム缶マーク」の下に、同様の「ドラム缶マーク」の画像を配置し、「JOIN」で連結して、構造図を保存する。
これによって、縦方向への構造拡張(進化)が行われる。
同様の処理を繰り返すことで、任意の数だけ、縦方向への拡張を行うことできる。
【0060】
図28及び
図29は、上記のように横方向・縦方向に構造図を進化させた場合の、格納すべきデータ及び正解データの自動生成の手法を示しており、
図28は横方向の拡張、
図29は縦方向の拡張の場合である。
図28に示すように、横方向の拡張を行った場合には、拡張された構造に格納すべきデータとして、コピー元の構造に対応するデータをコピーする。その際に、格納データの文字項目に関して、例えば最後の文字を他の文字、例えば「1」に置き換える。数字項目については変更しない。
このようにすることで、
図28の「想定結果」に示すように、拡張構造に格納すべきデータ及び正解データが自動生成されることになる。
なお、拡張構造を複数設ける場合には、上述した「1」を付与するだけではケタあふれの可能性があるため、さらに構造を拡張する場合には、次の拡張構造のデータには「2」を付与し、以降数字を順次上げることで対応することができる。
【0061】
図29に示すように、縦方向の拡張を行った場合には、拡張された構造に格納すべきデータとして、1つ前(上)の構造(テーブル)のデータをコピーする。その際に、横方向の場合と同様に、納データの文字項目に関して、例えば最後の文字を「1」に置き換える。数字項目については変更しない。
このようにすることで、
図29の「想定結果」に示すように、拡張構造に格納すべきデータ及び正解データが自動生成されることになる。
なお、この縦方向の拡張の場合も、横方向の場合と同様に、さらに構造を拡張する場合には、次の拡張構造のデータには「2」を付与し、以降数字を順次上げることができる。
【0062】
図30は、進化処理の3つ目である「表示順序の調整により間に入る」進化(
図5参照)をさせる場合のデータの出力結果を示している。
この場合には、
図30左側に示すように、構造図から元のキャラクタデータに変換したソースコード中の列名(例えば「列名1,列名2・・・」)を入れ替えることにより、表示順序を入れ替えることができる。
これによって、
図30右側に示すように、例えば「業務システムA」,「業務システムB」の順に表示されていた出力結果を入れ替えて、「業務システムB」を先頭に表示させることができるようになる。
なお、「間に入る」としているのは、並び替えの「列」が3つ以上であれば、結果のレコードセットが間に入る場合があるため、「間に入る」と表現している。
【0063】
[退化処理]
図31~
図34に、構造図の退化処理の手法を示す。
図31は、退化処理の1つ目である「UNION」を削ることにより「横に縮む」退化(
図9参照)をさせる場合である。
具体的には、構造図中に「UNION」を示す「U」もしくは「UA」の記号が含まれる場合、
図31に示すように、その「UNION」」で連結された既存構造の最も左に配置された構造と「UNION」を示す記号及び「横線」を削除する。
これによって、横方向への構造縮減(退化)が行われる。
同様の処理を繰り返すことで、任意の数だけ、横方向への縮減を行うことできる。
【0064】
図32は、退化処理の2つ目である「JOIN」を削ることにより「縦に縮む」退化(
図9参照)をさせる場合である。
具体的には、構造図中に「JOIN」を示す「J」,「LJ」,「RJ」,「FJ」の記号が含まれる場合、
図32に示すように、その「JOIN」により縦方向に配置されている「データ」を示す「ドラム缶マーク」のうち最も下の「ドラム缶マーク」を削除する。
これによって、縦方向への構造縮減(退化)が行われる。
同様の処理を繰り返すことで、任意の数だけ、縦方向への拡張を行うことできる。
【0065】
図33及び
図34は、上記のように横方向・縦方向に構造図を退化させた場合の、データの出力結果を示しており、
図33は横方向の縮減、
図34は縦方向の縮減の場合である。
横方向の縮減を行った場合には、
図33の「想定結果」に示すように、例えば退化前に「業務システムA」,「業務システムB」の出力結果が表示されていたものが、「業務システムA」のみが出力・表示されるようになる。
縦方向の縮減を行った場合には、
図34に示すように、例えば、属性情報として退化前に「購入者」,「購入金額(円)」,「支払い期限日」の3つの項目のデータが出力結果として表示されていたものが、1列の項目(「支払い期限日」)が消えて表示されないようになる。
なお、この場合には、「JOIN」数が減っても、検索結果レコードセットに変化が無いことが、SQLの実行性担保において重要となる。
【0066】
[特殊関数テスト]
次に、
図35を参照して、特殊関数テストについて説明する。
上述のとおり、本システム10においては、SQLの構造を示す構造図の作成及びその収れんによって代表SQLパターンを選定・決定し、その代表SQLパターンに基づく試験を行うことによって、移行先データベース200の動作保証を行うようになっている。
特許関数テストは、そのような代表パターンテストの仕上げ・補完として実行できるもので、SQLに含まれる特殊関数、例えば、
図35に示すような特殊制御及び関数(例えばSUM,AVG等)の動作確認を実行・保証するものである
特許関数テストは、本システム10に入力されたSQLの文字列に、所定の特殊関数が含まれているか否かを検索し、所定の特殊関数が含まれる場合には、当該特殊関数について、所定の正解データを用いたテストを実行する(特殊関数テスト実行部17)。
【0067】
具体的には、例えばマイクロソフト社の「Excel」などの表計算アプリケーションを用いて、SQLに含まれる特殊関数の解析表を作成し、SQLの全件について、例えば「Grep」により検索して、ヒットしたものを各1ケースずつ、移行元データベース100と移行先データベース200で結果が同じであるか否かを検査することにより行われえる。
対象とすべき特殊関数としては、例えば、
図35に示すような「特殊関数ファイル」を、本システム10の記憶手段において記憶しておくことができる。
【0068】
このような特殊関数のテストは、拾うべきレアケースではあるが、このような「仕上げ」を行うことで、ほぼ完全に、移行元データベース100と移行先データベース200の動作保証を行うことができることになる。
この特殊関数テストについても、SQL代表パターンテストと同様に、テスト結果を出力・表示させることができる(レポート出力部18)。
【0069】
[動作]
次に、以上のような本システム10における具体的な処理・動作(データベースマイグレーション支援方法の実施)について、
図36~
図50を参照して説明する。
[全体工程]
図36に、本システム10の動作確認処理の全体工程を示すフローチャートを示す。
同図に示すように、本システム10では、「代表パターンを探索しての動作確認」と「特殊関数を探索しての動作確認」の2系統で処理が行われる。
具体的には、以下の通りである。
[代表パターンの動作確認]
まず、「代表パターンを探索しての動作確認」は、「SQLファイルの作成/配置:手動」→「代表SQLの決定:自動」→「テストデータの投入・正解ファイルの作成/配置:手動」→「テスト実施(現行保証/進化/退化):自動」→「結果レポート作成:自動」の順に処理が実行される。
なお、処理中「手動」とあるのは、例えば本システム10のユーザや管理者,操作者等が、手動(手作業・操作)によってデータの選択・指定・入力等を行うものである。
一方、「自動」とあるのは、本システム10を構成する情報処理装置の動作によって、自動でデータの抽出・選択・決定・生成等が行われるものである。
【0070】
[特殊関数の動作確認]
次に、「特殊関数を探索しての動作確認」は、「SQLファイルの作成/配置:手動」→「代表SQLの決定:自動」→「テストデータの投入・正解ファイルの作成/配置:手動」→「テスト実施(現行保証):自動」→「結果レポート作成:自動」の順に処理が実行される。
なお、処理中「手動」,「自動」は上記「代表パターンを探索しての動作確認」と同様である。
また、「代表パターンを探索しての動作確認」において既に手動で「SQLファイルの作成/配置」,「テストデータの投入・正解ファイルの作成/配置」が行われた場合には、そのデータを再利用することができる。
【0071】
[システム画面構成]
図37及び
図38に、本システム10の動作確認処理における画面表示の一例を示す。
本システム10では、以下に示す動作確認処理が実行される場合に、操作者のユーザインタフェースとなる表示手段、例えば本システム10に接続された液晶ディスプレイ等において、
図37,
図38に示すような表示画面が生成・表示される。そして、操作者が表示画面に沿った入力操作を行うことによって、動作確認処理の各工程が実行されるようになる。
なお、以下に示す画面構成は一例であり、これ以外の画面構成を生成・出力させることができることは言うまでもない。
【0072】
[0.システム起動画面]
この画面は、本システム10の初期画面として最初に表示されるようになっている。
本画面では、
図37に示すように、画面表示に従った操作者の入力操作に応じて、「稼動確認実行」が選択されると、「1.システム実行形式選択画面」に遷移し、「実行記録閲覧」が選択されれば、「5.実行記録閲覧画面」に遷移する。
[1.システム実行形式選択画面]
この画面は、「0.システム起動画面」で「稼動確認実行」が選択された場合に遷移する画面であり、本システム10におけるシステムの実行形式を選択可能に表示するものである。
具体的には、本画面では、
図37に示すように、「自動実行選択ボタン」及び「手動実行選択ボタン」が選択可能に表示され、操作者の入力操作に応じて、いずれかの実行形式が選択・実行されるようなっている。
【0073】
[2.進捗表示画面]
この画面は、本システム10で実行される動作確認処理の進捗状況を表示するものであり、上述した
図36と同様の内容が表示されるようになっている。
本画面では、上述した「1.システム実行形式選択画面」で選択・指定された実行形式が「手動実行」の場合には、所定のアナウンス画面が表示される。
一方、「自動実行」が選択・実行されている場合には、自動実行処理の進捗に対応して、完了したステップが例えば灰色になり、実行中のステップが例えば赤色でハイライト表示されて、処理の進捗状況が表されるようになっている。
また、処理が全て完了すると「完了」ボタンが有効になり、操作者の入力操作により「完了」ボタンが押下されると、上述した「0.システム起動画面」に戻るようになる。
【0074】
[3.手動実行時のSQLファイル取得]
この画面は、上述した「1.システム実行形式選択画面」で選択・指定された実行形式が「手動実行」の場合に、SQLファイルの取得操作を促す画面が表示されるものである。
具体的には、
図37に示すように、例えば「SQLファイル格納場所を指定して下さい▼」というアナウンス表示が表示され、操作者の入力操作により「▼」ボタンが押下されると、任意のフォルダ選択が可能な画面が表示される(図示省略)。
ここで、有効なファイルが指定されない場合には、受け入れない。
また、ファイル格納場所が指定された後、「次に進む」ボタンが押下されることで、上述した進捗表示画面に戻り、次ステップに進むようになる。
【0075】
[4.データ投入指示画面]
この画面も、「1.システム実行形式選択画面」で選択・指定された実行形式が「手動実行」の場合に、移行先データベース200へのデータ投入と正解ファイルの取得操作を促す画面が表示されるものである。
具体的には、
図38に示すように、例えば「移行先データベースへデータをロードして下さい」,「正解ファイル格納場所を指定して下さい▼」というアナウンス表示が表示され、操作者の入力操作により「▼」ボタンが押下されると、任意のフォルダ選択が可能な画面が表示される(図示省略)。また、有効なファイルが指定されない場合には、受け入れないようになる。
そして、ファイル格納場所が指定された後、「次に進む」ボタンが押下されることで、上述した進捗表示画面に戻り、次ステップに進むことになる。
【0076】
[5.実行記録閲覧画面]
この画面は、「0.システム起動画面」で「稼動確認実行」が選択された場合に遷移しり画面であり、本システム10の動作確認処理について、閲覧を希望する実行記録を選択可能に表示するものである。
具体的には、本画面では、
図38に示すように、本システム10において過去に実行された動作確認の「日時」及び「実行回数」が複数表示され、例えばスライドバーで上下にスクロールできるようになっており、画面上には常に複数件(例えば5件程度)の実行履歴が表示さるようになっている。なお、実行履歴の記録としては、所定件数を保持しておくことができ、例えば最大1000件までの実行履歴の情報を保持させることができる。
そして、
図38に示すように、操作者の入力操作に応じて、任意の実行履歴に対応するボタンがクリックされて選択されると、ボタンの中心が黒色に反転して、選択された実行履歴が特定されるようになる。なお、
図38に示す場合には、選択可能な実行履歴は1行(1件)のみとなっているが、複数の実行履歴を選択できるように構成することも勿論可能である。
また、「戻る」ボタンが押下されれば、「0.システム起動画面」に戻るようになる。
【0077】
[6.希望閲覧処理選択画面]
この画面は、前画面(5.実行記録閲覧画面)で選択された実行履歴の日時/実行回数を表示させるとともに、当該実行履歴のうち、閲覧を希望する処理内容として、「代表パターン」と「特殊関数」のいずれかを選択可能に表示するものである。
具体的には、
図38に示すように、選択された実行履歴を示す情報として、例えば「2018年1月1日-12時 1回目の実行記録」と表示され、その実行履歴のうち、「代表パターンを探索しての動作確認」と「特殊関数を探索しての動作確認」のいずれかが選択可能に表示されるようになる。
そして、操作者の入力操作に応じて、「代表パターン」と「特殊関数」のいずれかに対応するボタンがクリックされると、ボタンの中心が黒色に反転して、選択された処理内容が特定されるようになる。
その後、「閲覧」ボタンが押下されれば、以下の「7.レポート表示画面」に遷移する。
また、「戻る」ボタンが押下されれば、「5.実行記録閲覧画面」に戻るようになる。
【0078】
[7.レポート表示画面]
この画面は、前画面(6.希望閲覧処理選択画面)で選択された実行記録・処理内容について、該当するレポートファイル(後述する
図50参照)を表示するものである。
具体的な画面の表示例は省略するが、このレポートファイルが表示されることで、ユーザは、過去に実行された動作確認処理の内容・結果を閲覧することができるようになる。
そして、「戻る」ボタンが押下されることで、初期画面である「0.システム起動画面」に戻る。
【0079】
[フローチャート]
次に、以上のような画面表示に従って実行される本システム10における動作確認処理の具体的な内容について、
図39~
図50に示すフローチャートに沿って説明する。
[代表パターン:SQLファイルの作成/配置]
図39に「代表パターン:SQLファイルの作成/配置」処理のフローチャートを示す。
このSQLファイルの作成/配置処理では、
図39に示すように、まず、本システム10の表示手段(ディスプレイ等)に表示されている進捗表示画面を初期化して(ステップ3901)、操作者の入力操作に応じて選択された動作確認処理の実行形式が自動実行であるか手動実行であるかが判定される(ステップ3902)。
【0080】
実行形式が「手動」であれば、表示画面を「3.手動実行時のSQLファイル取得」画面(
図37参照)に遷移させて(ステップ3903)、処理は終了となる。この場合は、SQLファイルは、上述のとおり、操作者の入力操作に応じて、任意のフォルダが選択されデータが取得される(
図37参照)。
一方、実行形式が「自動」の場合には、遷移画面(
図36,
図37参照)における「SQLファイルの作成/配置」ボックスが赤色などで着色された後(ステップ3904)、SQLファイルの自動作成処理が実行される(ステップ3905~3910)。
【0081】
SQLファイルの作成は、まず、ファイル名に使用する連続管理番号を「0」にセットし(ステップ3905)、その後、移行元データベース100のSQL実行記録からSQLを抽出する(ステップ3906)。この抽出処理は1SQLずつ、全てのSQLファイルを取り出して行われる。
抽出処理は、連続管理番号が「100,000」に到達するまで繰り返され(ステップ3907)、ファイル名に使用する連続管理番号をプラス「1」して(ステップ3908)、ファイル名を「mig_連続管理番号.txt」として、格納先の「INPUT-SQLファイル格納ディレクトリ」に出力し(ステップ3909)、連続管理番号が「100,000」に到達したら(ステップ3907)、進捗表示画面の進捗が進められて(ステップ3910)、処理は終了となる。
【0082】
[代表パターン:テストデータの投入・正解データの作成/配置]
図40に「代表パターン:テストデータの投入・正解データの作成/配置」処理のフローチャートを示す。
このデータ投入/配置処理では、
図40に示すように、まず、操作者の入力操作に応じて選択された動作確認処理の実行形式が自動実行であるか手動実行であるかが判定され(ステップ4001)、「手動」の場合には、表示画面を「4.データ投入指示画面」(
図38参照)に遷移させて(ステップ4002)、処理は終了となる。この場合は、データ投入/正解ファイルの配置は、上述のとおり、操作者の入力操作に応じて、任意のフォルダが選択されることで行われる(
図38参照)。
【0083】
一方、「自動」の場合には、遷移画面(
図36,
図37参照)における「テストデータの投入・正解ファイルの作成/配置」ボックスが赤色などで着色されて処理実行中であることが示された後(ステップ4003)、テストデータの投入処理(ステップ4004)及び正解ファイルの作成/配置処理(ステップ4005~4009)が実行される。
まず、テストデータの投入処理は、移行元データベース100のデータを逐次取り出して、移行先データベース200に入力・投入することにより行われる(ステップ4004)。
【0084】
次に、正解ファイルの作成/配置処理は、前の処理(
図39参照)で作成されたSQLファイルを逐次読み込み、全てのSQLファイルについて処理が実行される(ステップ4005)。
具体的には、まず、オープン中のファイル名を記録しておき(ステップ4006)、読み込まれたSQLを移行先データベース200に対して発行して、以下の項目についてデータを記憶させる(ステップ4007)。
・結果
・CPU使用率
・メモリ使用率
・応答時間
【0085】
正解ファイルが別名で保存される(ステップ4008)。ファイル名は、例えオープン中の結果ファイル名の直後に「_正解」等と付与することで生成できる。
そして、正解マッピングファイルをオープン中のファイル名で検索し、対応する正解ファイル名の横に正解ファイル名を記載して(ステップ4009)、正解ファイルの作成配置処理は終了となる。
その後は、進捗表示画面の進捗が進められて(ステップ4010)、次の代表SQLの決定処理に移行する。
【0086】
[代表パターン:代表SQLの決定]
図41~
図43に「代表パターン:代表SQLの決定」処理のフローチャートを示す。
この代表SQL決定処理は、
図41に示すように、まず、SQLを基本構文に従って「SELECT,UPDATE,INSERT,DELETE」の4分類にインプットを仕分ける処理が行われる(ステップ4101~4102)。
具体的には、SQLファイルが1ファイル毎に読み込まれ、この読み込み処理が最終ファイルまで繰り返し実行される(ステップ4101)。
そして、SQL分類仕分けサブルーチンが呼び出されて、SELECT/UPDATE/INSERT/DELETEの4つのディレクトリにコピーファイルが配置される(ステップ4102)。
【0087】
以降、
図42及び
図43に示すように、SELECT/UPDATE/INSERT/DELETEの構文系ごとの4系統で構成図の作成処理が実行される。このような4多重で構造図を作成することにより、処理の高速化を図ることができるようになる。
まず、SQLファイルが1ファイル毎に読み込まれ、最終ファイルまで繰り返し読み込み処理が実行される(ステップ4201)。
次いで、SQL構造図作成についてのサブルーチンが呼び出され、SQLファイルからSQL構造図が生成される(ステップ4202:
図14~
図20)。
なお、サブルーチンの具体的な内容については説明を割愛するが、サブルーチンは、公知のプログラミング技術を用いて、上述したSQL構造図の作成アルゴリズム(
図11~
図34参照)を実行可能なプログラムを作成することにより実現される。以下、サブルーチンについては同様である。
【0088】
続いて、
図43に示すように、SQL構造図ファイルが1ファイル毎に読み込まれ、最終ファイルまで繰り返し読み込み処理が実行される(ステップ4301)。
そして、SQL構造図収れんについてのサブルーチンが呼び出され、代表SQL構造図が決定される(ステップ4302:
図21~
図25)。
また、構造図化される前のSQLファイルが、SQLマッピングファイルが参照されて、代表SQLディレクトリに格納される(ステップ4302)。
その後は、進捗表示画面の進捗が進められて(ステップ4303)、次の代表SQLによるテスト処理に移行する。
【0089】
[代表パターン:テスト実施(現行保証/進化/退化)]
図44~
図47に「代表パターン:テスト実施(現行保証/進化/退化)」処理のフローチャートを示す。
このテスト処理では、
図44に示すように、まず、代表SQLディレクトリからSQLファイルが1ファイル毎に読み込まれ、最終ファイルまで繰り返し実行される(ステップ4401)。ここでは、まず移行先データベース200において移行元データベース100と同様の結果が得られるか否かについてのテストから開始される。
具体的には、現行保証テストのサブルーチンが呼び出されてテストが実行される(ステップ4402)。テストは、前の処理(
図41~
図43参照)で決定されたSQLを移行先データベース200に対して発行し、正解マッピングファイルを参照して正解と比較することにより行われる。
【0090】
そして、移行先データベース200についてのテストの結果が、移行元データベース100と一致するか否かが判定され(ステップ4403)、テスト結果が同じ場合には「進化」処理・テスト(図面左側のフロー)が実行され、テスト結果が異なる場合には「退化」処理・テスト(図面右側のフロー)が実行される。
まず、テスト結果が代表パターンポートファイルに出力され(ステップ4404)、その後、1行目の始めの空白出現までに「SELECT」が在るか否かが判定され(ステップ4405)、「SELECT」が在る場合には、進化/退化回数として「1」がセットされる(ステップ4406)。一方、「SELECT」がない場合には進化/退化処理は行われず、テスト処理は終了となる。
【0091】
続いて、進化/退化サブルーチンが呼び出され、進化/退化SQLが生成されて(ステップ4407:
図26,
図27,
図31,
図32参照)、進化/退化されたSQLが代表SQLディレクトリに格納される。
次に、自動データ増幅サブルーチンが呼び出され、進化/退化されたSQLについて、自動でデータ作成が行われ、正解マッピングファイルに自動で正解データが登録される(ステップ4408:
図28,
図29,
図33,
図34参照)。
その後、進化/退化テストのサブルーチンが呼び出されて、進化/退化されたSQLを移行先データベース200に対して発行し、正解マッピングファイルを参照して正解と比較することにより、1回目の進化/退化テストが実行される(ステップ4409)。
【0092】
そして、進化/退化テストの結果が、移行元データベース100と一致するか否かが判定され(ステップ4410)、テスト結果が一致する場合には「2回目」の進化/退化処理・テスト(図面各左側のフロー)が実行され、テスト結果が異なる場合には処理は終了となる(図面各右側のフロー)。
図45に示すように、まず、進化/退化テスト結果が移行元データベース100と異なる場合には、代表パターンポートファイルに出力された後(ステップ4501)、進捗表示画面の進捗が進められて(ステップ4502)処理は終了となる。
一方、進化/退化テスト結果が移行元データベース100と一致する場合には、代表パターンポートファイルに出力された後(ステップ4503)、進化/退化回数として「2」がセットされる(ステップ4504)。
そして、1回目と同様に、進化/退化サブルーチン(ステップ4505),自動データ増幅サブルーチン(ステップ4506),進化/退化テストサブルーチン(ステップ4507)の各サブルーチンが呼び出されて、進化/退化処理とテスト処理が実行される。
【0093】
その後、進化/退化テストの結果が、移行元データベース100と一致するか否かが判定され(ステップ4508)、テスト結果が一致する場合には「3回目」の進化/退化処理・テスト(図面各左側のフロー)が実行され、テスト結果が異なる場合には処理は終了となる(図面各右側のフロー)。
すなわち、
図46に示すように、2回目の進化/退化テスト結果が移行元データベース100と異なる場合は、代表パターンポートファイルに出力された後(ステップ4601)、進捗表示画面の進捗が進められて(ステップ4602)処理は終了する。
一方、2回目の進化/退化テスト結果が移行元データベース100と一致する場合には、代表パターンポートファイルに出力された後(ステップ4603)、進化/退化回数として「3」がセットされ(ステップ4604)、その後は、同様に進化/退化サブルーチン(ステップ4605),自動データ増幅サブルーチン(ステップ4606),進化/退化テストサブルーチン(ステップ4607)が呼び出されて、進化/退化処理とテスト処理が実行される。
【0094】
そして、3回目の進化/退化テストについては、テスト結果が移行元データベース100と一致するか否かが判定された後は(ステップ4608)、
図47に示すように、テスト結果の如何を問わず、テスト結果が代表パターンポートファイルに出力された後(ステップ4701)、進捗表示画面の進捗が進められて(ステップ4702)処理は終了となる。
これは、進化/退化処理については、3回程度行えば、進化によるシステム拡張等の予測や、退化によるシステムの改善検出などは十分可能であるからである。
但し、以上のような進化/退化処理・テストを、4回以上や2回以下とすることも勿論可能であり、システムの規模やコスト等を考慮して、適宜任意の回数を実行することができる。
【0095】
[特殊関数:代表SQLの決定]
図48に「特殊関数:代表SQLの決定」処理のフローチャートを示す。
この特殊関数の代表SQL決定処理では、
図48に示すように、まず、特殊関数ファイル(
図35参照)をオープンして、登録されている関数を記憶手段に記憶させる(ステップ4801)。
その後、登録されている関数1つずつに対して、各SQL中に該当する関数が存在するか否かが確認されて(ステップ4802)、特殊関数テストが実行される(ステップ4803~4805)。
【0096】
具体的には、SQLファイルが1ファイル毎に読み込まれ、最終ファイルまで繰り返し実行される(ステップ4803)。
そして、読み込まれたSQL中に、該当関数が存在するか否かが判定され(ステップ4804)、該当する関数が存在しない場合には、特殊関数テストは終了となる。
一方、SQL中に該当する関数が存在する場合には、SQLファイルが別名で保存される(ステップ4805)。ファイル名は、例えばオープン中の結果ファイル名の後に「_関数名」などを付与することで生成することができる。
その上で、SQLファイルが特殊関数用ディレクトリに格納され、特殊関数用正解マッピングファイルに追記される(ステップ4805)。これによって、特集関数を含む代表SQLが決定されることになる。
その後は、進捗表示画面の進捗が進められて(ステップ4806)、処理は終了となる。
【0097】
[特殊関数:テスト実施]
図49に「特殊関数:テスト実施及びレポート作成」処理のフローチャートを示す。
まず、特殊関数のテスト処理は、
図49に示すように、まず、上述した特殊関数ファイル格納用ディレクトリからSQLファイルが1ファイル毎に読み込まれ、最終ファイルまで繰り返し実行される(ステップ4901)。
そして、特殊関数用の現行保証テストのサブルーチンが呼び出されてテストが実行される(ステップ4902)。テストは、前の処理(
図48参照)で決定された代表SQLを移行先データベース200に対して発行し、特殊関数用の正解マッピングファイルを参照して正解と比較することにより行われる。
その後、移行先データベース200についてのテストの結果が、移行元データベース100と一致するか否かが判定され(ステップ4903)、テスト結果が同じ場合には、特殊関数レポートファイルに「OK」を出力し(ステップ4904)、テスト結果が異なる場合には、特殊関数レポートファイルに「NG」を出力して(ステップ4905)、処理は終了となる。
【0098】
[テスト結果レポート作成]
図50に「代表パターン/特殊関数:テスト実施及びレポート作成」処理のフローチャートを示す。
代表パターン/特殊関数のテスト結果のレポート作成処理は、
図53に示すような処理が実行される(ステップ5001~5003)。
【0099】
[代表パターン]
まず、代表パターンの結果レポートとしては、以下のような内容を生成・出力することができる(ステップ5001)。
(1)代表パターンレポートファイル(サマリ部分)
このサマリ部分には、以下のような結果を出力することができる。
・総試験SQL数をカウントアップし本数を出力。
・代表パターンレポートファイルの「現行保証テスト」列を「OK」で検索してヒットした本数を出力。
・代表パターンレポートファイルの「INPUT-SQLファイル名」列と「現行保証テスト」列の応答時間を引き算してマイナス値となった本数を出力。
(2)代表パターンレポートファイル(退化テスト部分)
この退化テスト部分には、以下のような結果を出力することができる。
・代表パターンレポートファイルの退化テスト3回目のSQL本数をカウントし退化数3と本数を出力。
・発見されなかったら2回目のSQL本数をカウントし退化数2と本数を出力。
・発見されなかったら1回目のSQL本数をカウントし退化数1と本数を出力。
・発見されなかったら退化数0,本数0を出力。
(3)代表パターンレポートファイル(退化テスト部分)
この進化テスト部分には、以下のような結果を出力することができる。
・代表パターンレポートファイルの進化テスト3回目のSQL本数をカウントし進化数3と本数を出力。
・発見されなかったら2回目のSQL本数をカウントし進化数2と本数を出力。
・発見されなかったら1回目のSQL本数をカウントし進化数1と本数を出力。
・発見されなかったら進化数0,本数0を出力。
【0100】
[特殊関数]
次に、特殊関数の結果レポートとしては、以下のような内容を生成・出力することができる(ステップ5002)。
特殊関数レポートファイル(サマリ部分)
・総試験SQL数をカウントアップし本数を出力。
・代表パターンレポートファイルの「現行保証テスト」列を「OK」で検索しヒットした本数を出力。
・代表パターンレポートファイルの「INPUT-SQLファイル名」列と「現行保証テスト」列の応答時間を引き算してマイナス値となった本数を出力。
【0101】
[その他の情報]
さらに、上記以外のその他の情報として、以下のような内容を生成・出力することができる(ステップ5002)。
具体的には、システムクロックを利用して日付日時を取得して、以下のような果を出力することができる。
・ディレクトリを作成
ネーミングルール:「年月日_時_回数」(例えば、6桁_2桁/24時間表記_4桁/最大1000)
・データコピー
データの中身:上記INPUT-SQLファイル格納ディレクトリ~結果レポート格納ディレクトリまで一式を、ディレクトリ構造を保ったまま格納
【0102】
そして、以上のようなレポート結果出職処理が行われると、その後、進捗表示画面の進捗が進められて(ステップ5004)、処理は終了となる。
【0103】
以上説明したように、本システム10によれば、移行元データベース100から移行先データベース200へのマイグレーションに際して、移行元で稼動されているSQLを所定の画像に置換してパターン化し、進化/退化させることにより、効率的な動作確認や、システムの拡張・変更等の試験を行うことが可能となる。
これによって、安心/安全なデータベース移行を実現でき、例えばプロジェクト工期の予期せぬ長期化や品質低下等の問題を有効に防止することができるようになる。
【0104】
以上、本発明について好ましい実施形態を示して説明したが、本発明は、上述した実施形態に限定されるものではなく、本発明の範囲で種々の変更実施が可能であることは言うまでもない。
例えば、上述した実施形態では、本システム10が対象とするデータベース言語としてSQLを例にとって説明したが、本発明は、SQL以外のデータベース言語を対象とすることも勿論可能である。
すなわち、本発明は、データベースシステムに適用・発行されて、データベースに格納されたデータの出し入れに用いられるデータベース言語であれば、どのような言語に対しても適用することが可能である。
【0105】
また、上述した実施形態で示したアルゴリズム(
図2~
図35)やフローチャート(
図36~
図50)は、本発明を実施するための一例であり、同図に示される形態に限定されず、本発明の技術思想を実現できる限り、他のアルゴリズム等を採用することは勿論可能である。
また、上述した実施形態では、大規模なデータシステム・SQLを想定して説明しているが、本発明は、SQLを含むデータベースの規模や構成などに限定されず、マイグレーションが行われる各種データベースに適用することができるものである。
【産業上の利用可能性】
【0106】
本発明は、例えば製品変更や機能の拡張・変更・縮減、ハードディスク資源の交換等の理由によってデータシステムの入れ替えや移行(マイグレーション)を支援するシステムとして好適に利用可能である。
【符号の説明】
【0107】
10 データベースマイグレーション支援システム
11 データベース言語入力部
12 構造図作成部
13 収れん処理部
14 進化/退化処理部
15 代表パターン生成部
16 代表パターンテスト実行部
17 特殊関数テスト実行部
18 レポート出力部
100 移行元データベース
200 移行先データベース