【データベース設計基礎講座お役立ちコラム】-ＩＴガバナンスとは

Home > useful information > useful column>

データ移行

データ移行の本質
　実は、データ移行と言うものほど、情報システムの本質を分かり易く表現しているものは他に無い。
　つまり、情報システムの本質はデータであると言うことだ。
　データとは、本質的にビジネスの記録であり、一旦記録すれば変更は無い。（ビジネスの実体自体の変化を反映する意味での変更は当然発生するが）
　しかし、画面・帳票などユーザインターフェースに表示を要求される導出項目や集計項目の都合上、中間値【注１】や集計値など、二次加工データや、人間とのインターフェースを良くするためのコード【注２】が設定された結果、様々な特性を持つデータが入り乱れることとなり、その本質が見失われている。
　そのため、データ移行を新システム側の二次加工データを含めた全データ項目をターゲットに、現行システムからデータを変換して持って行かなければならないと考えるので、データの変換ロジックが複雑となり、移行システムの開発の難易度が上がる。
　しかし、二次加工ロジックは、新システムも装備しているので、これをわざわざ移行システムに別建てで装備することは、全く無駄な二重投資だ。
　基本的には、現行システムから純粋な記録部分のデータ（これをファクトデータと呼ぶケースがある。　分かり易い様な気がする表現なので、本稿でも使いたい所だが、一般的な概念として通用するものかどうかわからない上、使用例にも微妙な違いがあるようなので、取りあえず我慢しておく。）を抽出すれば、それをそのまま、新システムでビジネスの事実を記録する部分に過不足無くロードする事が出来る（もちろん、新システムから新規に収集するデータ項目があれば、新システムからの収集になるが）ので、新システムで必要な二次加工は新システムで再度実行すれば良い。
　つまり、データ移行と見えるのは実は錯覚で、データ移行の本質はビジネスの記録であるデータを、アプリーエションを入れ替えて使い続けると言うことだ。
　ただ、データを格納しているデータベースが、アプリケーションの変更に伴って変わるので、その本質とは逆の「データ移行」と言う対応が必要になると言う訳だ。

【注１】：中間値
　非実装の集計データを利用する場合、利用する都度の膨大な再計算処理を回避する目的で最新の導出値を保持したデータ項目。
　例えば、売上合計金額の場合、当該データ項目の利用が発生する都度、その時点での最初の売上の売上金額から最新の売上の売上金額までを集計していたのでは、処理の負荷が大きくなって時間も掛りレスポンスに影響を与える可能性もある。
　そのような場合、最新の導出結果を最新売上金額合計などのデータ項目に保持しておき、次にデータ項目の利用が発生した時には、最新の導出値計算時以降に発生した計算対象だけを集計した上で、件の中間値に足し込み、最新の売上金額合計を導出する。

【注２】：人間とのインターフェースを良くするためのコード
　コードは二次記憶装置が高価であったり入力処理が面倒な時代には、大いに効果があったソリューションだ。
　しかし、現在では二次記憶装置はただ同然、入力もプルダウンメニューからの選択など、飛躍的に使い勝手が向上した結果、少々複雑な名称でも間違い無く同じ表記で入力する事が出来るので、以前ほどの効果は無くなった。
　ただ、複数の値からある状況をレベルに分けて人に分かり易く表現するような場合には依然として有効なソリューションである。
　例えば、月に１０件以上の買い物を三か月以上続けて頂いた方か、年１００万円以上お買い上げ頂いた方を、お得意様として特別扱いするためにお得意様フラグを、顧客に設定するような場合、中間値同様なデータ項目が設定されることになる。

データ移行の手順
　データ移行の本質とは、概念的にはビジネスの記録としてのデータを中心に、アプリケーションを新旧入れ替えることだ。
　そのためには、ビジネスの記録としてのデータを詳細に把握する必要がある。
　つまり、集計情報や統計情報、変換結果であるコードやフラグなどを分離して、元々の記録部分を整理しなければならない。
　と言う事は、ここでもビジネスの構成要素ごとに、その固有の性質を属性として整理するデータ分析が威力を発揮することになる。
　考えて見れば、元々システムの中にビジネスの記録をするための構造を明らかにするための整理方法がデータ分析なので、そこに記録されたデータを取り出す場合の格納構造が同じデータ分析に結果として求められたデータモデルである事に何の不思議も無い。
　と言う訳でデータ移行は次の手順で行う事になる。
１．データ構造の確定（既に移行元システムや移行先システムが、きちんとデータ分析をした結果のデータ構造に従って設計されているのなら良いが、そうで無い場合は、データ分析を行う所から作業しなければならない事になる。　しかし、その場合は当然ながら、移行先システムのデータベース設計の品質に大いに疑問が生じると言う事なので、少々話がややこしくなるのは止むを得ないだろう。）
２．移行元システムからのデータ抽出
３．移行先システムへのデータロード
　挙げれば単純だが、移行対象データの量と移行に許容された時間によっては、単純な変換システムの作成だけでは済まない事があるので要注意だ。

移行方式のバリエーション
　データの移行と言うと、移行データを抽出した所で移行元システムを停止し、移行先システムに入れ替えた後、先ほど抽出しておいた、移行データを移行先システムにロードすると言う、単純な処理イメージを持つのが一般的だ。
　しかし、長期間に亘って蓄積されたビジネスの記録は膨大でデータベースから抽出するにもロードするにも想像以上に時間が掛る。
　漠然とした移行イメージしか持っていないにも関わらず、正月休みや５月の連休にシステムを止めたところで移行してなどと、数日時間があれば何とか成るだろうと安易に考えていると後悔する事になる。
　話は変わるが、システム運用で定期的にバックアップは取り続けて来たが、たまたまトラブルが無かったのでリカバリー処理を長期に亘って行っていなかった企業で、トラブルの発生を受けていざリカバリーを行って見たら、データ量の増加で想定時間の３倍掛り、結局業務に多大な影響が出てしまうなどと言うことが良くある。
　折角バックアップを取っていても、これではイザと言う時に役に立たないので、定期的なリカバリーの訓練は欠かせないと言う訳だ。。
　データ移行も何某かの基礎数値を把握した上で、移行方式は開発計画前に決定しておく必要がある。
　５月の連休にシステムを止めて移行する前提で、開発スケジュールを引いたが、いざ移行の内容が明らかになって見ると、時間が不足する事が分かり、完成したシステムを横目で眺めながら、移行システムの再設計などと言う事になると、目も当てられない。
　主な、移行方式は、システムを止めてセーノで移行する一括移行の他には、一括移行を多重処理して時間短縮を図る方式、完全な新旧システムの並行処理、移行処理を行っている間に発生したデータを後から反映する方式などが考えられるが、テーブル・ファイルなどの単位で決めることなので、通常は、幾つかの移行方式を並行利用する事になる。

その他のポイント
・移行とテストのタイミング
　データ移行を行うと言うことは、新システムのデータ一式が実装されると言うことだ。
　と言うことは、そのデータを使ってアプリケーションをテストすれば、精度の高いテストが出来ると言うことなので、これを活用しない手はない。
　また、業務システムと移行システムの仕様の摺り合わせにもなるので、なるべく早い段階のテストに移行データをテストデータとして提供可能な段取りを考える必要がある。
　
・移行仕様の検討
　移行設計を業務設計を行う作業グループとは別組織である移行グループで担当させようとする事が見られるが、移行設計は基本的にターゲットになっているテーブル・マスター・トランザクションなどの設計者本人が担当するのが最も効率が良いに決まっているので、調査作業の二度手間にならないように、移行ターゲットの設計と移行設計はセットで考えた方が良いだろう。
　データベースの設計や実装と移行に関する設計から開発までを、データ管理者の下に創ったデータ管理部隊で一括して担当するのが合理的だろう。