レガシーシステムあるあるの話
はじめに
本ブログは、30年以上BI・アナリティクス業界に携わってきた一技術者の筆者が、ふと思い立って筆を執ったものです。内容は筆者の思い込みも含まれています。間違いはご指摘いただき、ご容赦願えれば幸いです。
◎製品資料をCheck！Yellowfinについて理解を深めよう↓
最近の話
うちの若い（と言ってもちゃんとおっさんの）メンバーから、
「お客様データを見て驚いたのが日付型のデータの持ち方で、数値型４桁yyMMでデータを保持していました。具体的には、2003年10月は「310」、2023年10月は「2310」のような感じです。数値型なので1-9月に関しては、yyの部分が1桁になるようなデータの持ち方でした（頭文字0で桁合わせしない）。これって普通なのでしょうか・・・」
という話がありました。
DWH/BIシステムを扱うようになって、日付はDATE/TIMESTAMP型、コードは文字型にするのが常識だと思っていますが、私のような、COBOL世代の“オヤジ”にとっては、「あるあるだよねー」と思い、当時を振り返ってみました。
日付型なんかなかった（今はあるようです）
そもそも私がCOBOLでコードを書いていた、1985年から1995年ごろに日付型という考え方はありませんでした。文字列、または数値型で、6桁数字の羅列で表現していました。
翌月や翌年の算出はどうするかって？
例えば 1987年6月15日 だと、 870615 という数値または文字列になります。これを年の2桁、月の2桁、日の2桁に分けて数値として扱います。SUBSTAR関数のようなもので切り出すのではなく、項目の再定義（REDEFINES）で6桁の文字列を2桁3つの数字として分割します。翌月は月に1を足し、13になったら年に1を足し、月を1にし、月の大小を判断して日を調整するというロジックを書いていました（嘘のようなホントの話）。6桁日付のまま2000年に突入すると、日付の大小関係が崩れてしまうので、私のCOBOL時代後半は8桁日付を使うようになりました。
なぜ最初から8桁にしなかったのかって？
私が入社したときには既存システムがそうだったと言えばそれまでですが、その昔、メモリやDISKは高価だったので、できるだけ使うバイト数を少なくするため、必要最低限の情報にしていたのだと思います。
このように、できるだけ記憶容量を少なくするためにいろいろな方法が使われていました。
Packed-Decimal型
日付が数値型であるのと同様に、商品コードや顧客コードのようなものも、数値型で定義されていることがあります。COBOLの通常の数値型（ゾーン10進数）は、1バイトで1桁の数値を表現しますので、文字列でも数値でも記憶容量はかわりません。しかし、COBOLには、Packed-Decimal型という記憶容量を節約する方法があります。Packed-Decimal型（COMP-3型といった方が通じるかも）は、数値の1桁を4ビットで表す方法です。これで必要なバイト数が半分程度（実際は符号４バイトが入るので半分より1バイト多い）になります。
例えば、数値「841」の、
ゾーン10進数での記憶の仕方 ※上から 16進数表記、2進数表記
Packed-Decimal型（COMP-3型）での記憶の仕方 ※上から16進数表記、2進数表記
黄色部分は符号（＋－）を表します。ただし、コンピュータの機種によって違うかもです。
と、こんな具合です。
数量や金額など、計算をするような数値はもちろん、上記のようなコードもこの形式で容量を節約することがありました。ただこの方法は、データをダンプした場合に16進数表示でないと数値が読み取れない、という不便さが付きまといました。というのは・・・
昔はレコードレイアウトでデータ設計
データの設計時にRDBの時代では、項目の集合で考えるようになりましたが、COBOL時代は入出力の単位としてのレコードで考えていました。
一度の読み込みではレコードすべてが転送されるので、性能面からも、桁（バイト数）の節約は必須でした。
このレコード形式からDBに置き換える際も、記憶容量の節約を行う考え方や、旧システムのデータ型を一番近いDBの型に置き換えた結果が、数値羅列の日付や数値型のコードということになります。
ちなみに上記の数量だと、符号付７桁の数値（-9,999,999～9,999,999）が範囲になりますので、OracleでいうとINTEGER型（-2,147,483,648～2,147,483,647）で充分ということになります。同じ4バイトです。これ以上の桁数になるとDBが勝りますね。
最後に
話の発端になったyyMM形式の年月は、表示や並び替えを行う分には困りませんが、経過時間（年月）を分析に持ち込んだり、時系列のグラフを作成したりする際には使いやすいとは言えません。
同じDB内に、このyyMM形式の年月のDATE型の日付と、その日付の属性が管理できるカレンダーマスタを用意し、そちらを参照するのがベストでは、と内部では話しています。
Yellowfinでは、数値、テキスト、日付/タイムスタンプ間の型変換機能を備えています。これらをうまく活用することにより簡単にレポーティングが可能ですが、データはデータベースに適切な型で保存されている方が、いろいろな意味で使いやすいです。データの活用は正しくデータを保存するところから、といったところでしょうか。
以上、本記事に関する詳しい説明を聞きたい方はお気軽にお問い合わせください。
◎製品資料をCheck！Yellowfinについて理解を深めよう↓
