テキストデータにおける変換処理の例
- 日付処理：西暦/和暦変換、JST/UTCなどのタイムゾーン変換
- 不正な値処理変換：Null値や空文字の取扱い
- 文字列や値の統一：大文字小文字の統一(半角/全角もか)、整数/小数の統一、表記揺れの統一
- テーブルの結合処理：取引ログテーブルと取引先テーブルを取引先IDで結合
- ファイルサイズの変換：大量の細かい数KB程度のファイルを数百MBのファイルに集約
- ファイルフォーマットの変換：Parques/ORCへの変換
[自己メモ]
他にもデータ変換を行う際には、格納先がRDBのテーブルに格納する際には以下の様な事が配慮必要である
- コード値変換：男性/女性といった値や、ON/OFFなどのフラグ値の変換、そもそもマッピング関係があるかどうか
- 桁合わせ：ゼロパディング(0埋め)、ゼロサプレス(0削り)、コメントなどの文字の桁不一致時の処理
- 時刻処理：秒/ミリ秒格納、年・日付含みかどうか
また、値の中身に関して以下の様な配慮が必要である(※1)
- 文字コード：UTF-8かSJISか、漢字は第三水準以上も含まれるかどうか、昔のデータだとある項目値だけEBCIDICとかいう落とし穴もあるので注意
- 改行コード：CRLFかLFか、別の置換文字として送られてくるかどうか
- 記号：シングルクオーテーション/ダブルクオーテーション、カンマ、括弧【(), {}, []】、アスタリスク、クエスチョンマーク、アンパーサントなどが含まれているかどうか
- アスキー/バイナリ：対象の値がアスキー文字で想定していたら実はバイナリデータだったとか、その逆もしかり(項目値名だけで判断しない)
- 文字数/バイト数：Nバイトの文字送ると記載されているのに実際の値見るとN文字のこと指していているなど
- 項目の前後関係：ある項目の値がある時だけこの項目が存在、ある項目の値によって別の項目の値の意味が変わる、ある項目とある項目の値をつなぎ合わせて一つの値など
- 項目による値の意味合い：項目毎にデリミタが異なる、ある項目では更にcsvの値が格納されている、ある項目では文字コードの値やパーセントエンコーディングの値が入っているなど
- 暗号化されている範囲：項目によっては最近は暗号化されている値が存在するが、それの適応範囲など
- 値だけで意味があるかどうか：値を解読するためのアルゴリズムが必要、またはハッシュ値が入っていてそれを連動してもらってもそもそも意味が無いなど
- 必要なNull値、空文字：値受信時には送られてこないのに、値送信時には値をNull文字や空文字で送ってこいみたいな場合の受信側の管理方法など
- 繰り返し項目の取り扱い：レコードみたいな場合にどの様なルールに基づいて構造化されているかどうか、繰り返し項目中に繰り返し項目が存在する場合とかも
※1
こんな複雑な闇が沢山あるから、日本ではETLツールが流行らずスクラッチで無いとと言われるゆえんかと考える。。。
