データ移行チームが要件定義や設計タスクを進める上でネックになるのが、移行先データモデルが固まらないことです。
移行対象がたくさんあるから早めに準備を始めたいのに移行先が決まらないから手がつけられない、もしくは手戻りが多数発生し結局水の泡になってしまう。移行元データは仕様もデータもずいぶん前から手元にあるのに進捗を上げることができない。
移行チームのジレンマです。
そうなると移行先となる新システムのデータモデルが計画上いつ固まるのかを確認しつつなるべく前もって情報をもらうようにするしかありません。
データモデルとは
データの構造を図に示すものです。粒度があって、
- 概念データモデル
- 論理データモデル
- 物理データモデル
に分かれます。データ移行担当は、物理データモデルを手に入れないと移行ツールを完成させることができません。
データモデルの構成要素と欲しい情報
データモデルは、テーブル定義とテーブルの関係を表します。この中でデータ移行担当が欲しいのは、以下の情報です。
- テーブルのレコードを特定するキー項目
- 他のテーブルのデータを参照するキー項目
キー項目とは、その項目の値でシステム処理ができるものです。レコード特定する主キーであればその項目で必ず一行に決まる必要があります。他のテーブルを参照する場合も同じです。2,3行にだいたい絞れる、では足りません。
次に入手したい情報
キー項目の特定ができたら次は以下の情報に注意します。
- 金額項目
- メモ項目
- 似た項目名で多数ある項目
金額項目は間違えてはいけない度合いが強いです。もちろん他の項目も間違えてはいけないことに変わりはないのですが、特に慎重に扱う必要があります。最大桁数、小数点以下など丁寧に確認します。
移行元からある項目とある項目を掛け算して設定する場合、最大桁を超えないか注意が必要です。また、日本円といえど単価だと割り算して1円未満になるものもありえます。
メモ項目はユーザーが自由に記入する内容なだけに注意が必要です。項目内に入る改行を再現することや、ユーザーが使った特殊な文字で文字化けしてないか気をつけます。
似た項目名で多数存在する場合、例えば項目1から31まである場合、1ヶ月の日別データを別項目で持っていそうです。これを一つのレコードで横持ちするか、別テーブルで31行のレコードとして縦持ちするかはどちらが正解というのはありません。
移行担当として気にすべきは、移行元データと持ち方が変わってないかです。変わっている場合はプログラムで変換が必要になるので注意しましょう。
持ち方が変わっているというのは、以下のようなものです。
（現行：横持ち）
顧客 売上1 売上2 ・・・売上31
A 100 200 ・・・
（新：縦持ち）
顧客 日付 売上
A 1 100
A 2 200
・・・
A 31
このような場合は、新システム向けレイアウトに移行元データを変換する必要が発生します。
次記事では、移行元と移行先のマッピングタスクについて紹介します。
