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

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

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

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

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

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

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

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

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

小の月なのに11月31日だったり、閏年でない年の2月29日等の存在しない日付。

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

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

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

YYMMDD

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

和暦フォーマット

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

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

GYYMMDD

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

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

深夜を表す時刻表記

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

201502152730

このようなデータは、日付型の存在しないシステムでは日付データとして扱われますが、明確な日付型を持つRDBでは保持できません。
しかし、利用するアプリケーションとしては、例えば24時間営業のお店の「レジ締め時刻」のように、翌日のAM3:00ではなく当日の深夜3:00であることが重要だったりと理由があるわけですから、一律に翌日に変換すればよいわけではありません。
これは、このカラムを利用するアプリケーションとの相談で、実時刻とともに変換前時刻を保持する必要性を確認するべきでしょう。

未入力データ

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

すべて9

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

このように、様々な変換の可能性があるわけですが、よくあるのが「データはそのまま移行して欲しい」という依頼だけで作業が開始されてしまうことです。
日付型に留まらずさまざまな理由から、データ移行が「そのまま」で済むことはまずないと思っていただくとよいでしょう。
しかし、発注者も、受注見積者も、このようなデータが存在することを意識しておくことは困難でもあり、後になってから「そんな罠が仕掛けられているとは思わなかった。」のようになりがちです。

いずれにしろ、本契約前に検証作業だけの契約を締結するなどして、実証実験されることをお勧めします。