データ移行B!データ移行チームが要件定義や設計タスクを進める上でネックになるのが、移行先データモデルが固まらないことです。移行対象がたくさんあるから早めに準備を始めたいのに移行先が決まらないから手がつけられない、もしくは手戻りが多数発生し結局水の泡になってしまう。移行元データは仕様もデータもずいぶん前から手元にあるのに進捗を上げることができない。移行チームのジレンマです。なると移行先となる新システムのデータモデルが計画上いつ固まるのかを確認しつつなるべく前もって情報をもらうようにするしかありません。次に入手したい情報データモデルとはデータの構造を図に示すものです。概念データモデル論理データモデル物理データモデルに分かれます。データ移行担当は、物理データモデルを手に入れないと移行ツールを完成させることができません。データモデルの構成要素と欲しい情報データモデルは、テーブル定義とテーブルの関係を表します。この中でデータ移行担当が欲しいのは、以下の情報です。他のテーブルのデータを参照するキー項目キー項目とは、その項目の値でシステム処理ができるものです。レコード特定する主キーであればその項目で必ず一行に決まる必要があります。他のテーブルを参照する場合も同じです。2,3行にだいたい絞れる、では足りません。次に入手したい情報キー項目の特定ができたら次は以下の情報に注意します。金額項目は間違えてはいけない度合いが強いです。移行元からある項目とある項目を掛け算して設定する場合、最大桁を超えないか注意が必要です。日本円といえど単価だと割り算して1円未満になるものもありえます。メモ項目はユーザーが自由に記入する内容なだけに注意が必要です。項目内に入る改行を再現することや、ユーザーが使った特殊な文字で文字化けしてないか気をつけます。似た項目名で多数存在する場合、例えば項目1から31まである場合、1ヶ月の日別データを別項目で持っていそうです。これを一つのレコードで横持ちするか、別テーブルで31行のレコードとして縦持ちするかはどちらが正解というのはありません。移行担当として気にすべきは、移行元データと持ち方が変わってないかです。変わっている場合はプログラムで変換が必要になるので注意しましょう。持ち方が変わっているというのは、以下のようなものです。31このような場合は、新システム向けレイアウトに移行元データを変換する必要が発生します。次記事では、移行元と移行先のマッピングタスクについて紹介します。移行元と移行先のマッピングは大枠から詳細に決めていくB!mhisaeda電子書籍「システム導入のためのデータ移行ガイドブック」著者。新卒から外資系コンサルティングファームに所属。15年に渡り販売物流、特にCRM領域のコンサルティングに従事。100名を超えるプロジェクトのPMOなど全体を推進していく役回りや、ユーザ企業への出向を通じた実務経験を持つ。このブログでは、自身がかき集めた知識や経験を共有する。クライアントへの提案やソリューション開発に直結しないガラクタのようなもの。将来再利用する自分のために。新卒から外資系コンサルティングファームに所属。15年に渡り販売物流、特にCRM領域のコンサルティングに従事。100名を超えるプロジェクトのPMOなど全体を推進していく役回りや、ユーザ企業への出向を通じた実務経験を持つ。本当に困った時にそっと手を差し伸べてくれる友人のような、あなたを傍で応援しいつも隣を走ってくれる相棒のような、そんなブログを目指しています。