2015年3月24日火曜日

メインフレームからのデータ移行における日付型の扱い

こんにちは。大須賀です。




今回はデータ移行における日付型の話です。

RDBの場合、日付型という型があり、閏年や大の月、小の月等の整合性はデータ投入時にRDBが保証してくれます。
DB2等の最新のメインフレームRDBでは日付型がありますが、旧DB2やSAMファイルのままの設計のレガシーシステムなら、日付型は使用していない場合が多いです。
日付型という型がないと、そのようなデータはアプリケーションが保証しなければならないことになります。
そのため、日付であると指定されたカラムでも、単純に日付変換で済ませることはできません。

メインフレームから来る日付は以下の形態の場合が多いです。

  • 文字列型
  • アンパック数値型
  • パック数値型


文字列の場合、「/」や「:」などの区切り文字を含まず数値文字だけで構成され、
YYYYMMDDHHMMSSのように入ってきます。(もちろんEBCDICです)

文字列に日付フォーマット(YYYY-MM-DD HH:MM:SS等)で来る場合もありますが、希です。1バイトでも節約したいメインフレームの考え方では、区切り文字の空白やハイフンは無駄です。主要言語であるCOBOLが文字列操作を不得意としている理由もあると私は考えています。

このようなデータで起こりうるデータ異常について例を挙げてみましょう。

■アプリケーションバグによる異常日付

11月31日、閏年でない年の2月29日等の存在しない日付

データ整合性はアプリケーションの入力チェックにかかっていますので、このようなデータが大量のデータに紛れて入ってくることは結構な確率であります。たかが一件でも、RDBへロードする夜間バッチは中断してしまいます。
逆に、13月32日とか、61分のような単位自体が異常な数値はまず無いです。入力チェックで数値上限は確実にチェックされるためでしょう。

■日付フォーマットのバリエーション

日付フォーマットですがよくあるのが以下の形式。

YYMMDD

日付が2桁です。西暦の場合、何年以上が1900年代で、何年未満が2000年代という、データ上には無いシステム上の規約があります。
1900年代の、2000年を意識していなかったシステムや、年を和暦で設計してしまったシステムの名残だと思われます。

■和暦フォーマット

和暦と言えば、さすがにデータが昭和のままで2015年を昭和90年にしているシステムはもう無いようです。

日本でよくあるのが次の形式

GYYMMDD

Gは元号を表し、1:明治、2:大正、3:昭和、4:平成というような値になります。官公庁系のデータでよく見かけます。

このような和暦扱いのデータは、RDBの日付型に移行するのが常識でしょう。もとのデータには計算でいつでも戻せます。

■深夜を表す時刻表記

時刻フォーマットで深夜を示すデータです。

201502152730

このようなデータは、日付型の存在しないシステムでは日付データとして扱われますが、明確な日付型を持つRDBでは保持できません。
しかし、利用するアプリとしては、翌日のAM 3:00ではなく、当日の深夜3:00であることが重要なわけですから、一概に翌日の早朝に変換すればよいわけではありません。
これは、このカラムを利用するアプリケーションとの相談で、実時間とともに変換前時刻を保持する必要性を確認するべきでしょう。

■未入力データ

さて、これ以外にメインフレーム系で留意しなければならないのは以下のデータです

すべて空白
すべて9

メインフレームのデータにはNULLの概念がありませんので、未入力を表すためにこのようなデータをよく使用します。
メインフレームだけでなく、基本設計がメインフレームのSAP ERPも、未入力の場合オール9を返しますので、注意が必要です。


上記のように、様々な変換の可能性があるわけですが、よくあるのが「そのまま移行して欲しい」という依頼だけで作業が開始されてしまうことです。データ移行が「そのまま」で済むことは、まずありません。しかし、発注者も、受注見積者も、このようなデータが存在することを意識していません。

いずれにしろデータを見てから自体が発覚するのはトラブルの原因ですので、できれば作業量確定前にデータを見せていただくのが理想ですね。


0 件のコメント:

コメントを投稿