データウェアハウスは基本的にデータの蓄積をしていくものである。
しかし、現実には蓄積したデータに対して更新が発生する場合が多い。
スタースキーマのようなディメンショナルモデリングを採用した場合、ディメンションの更新手法について検討することが必要になる。
調べた結果を備忘のため残しておく。
※更新手法については下記の論文が最も参考になったので、主なインプットとしてる。
http://www.unisys.co.jp/tec_info/tr68/6815.pdf
はじめに
スタースキーマにおいては、基本的にファクトテーブルへの更新は避け、ディメンションの更新によって、属性の変化を保持・表現する。
ディメンションの例としては下記のようなものの変化があげられる。
・顧客の住所
・商品のカテゴリ
・会社組織
キンボールの示した解決方法は３つある
1. レコードオーバーライト
要は、そのまま次元テーブルに対してアップデートしちゃう手法。
特徴としては、履歴が失われる点。
例えば顧客の住所を直接更新した場合、地域ごとの年別売上の分析は難しくなる。
しかし電話番号のような変化した属性が分析に意味を為さない項目であれば、直接更新が手っ取り早い。
2. 新規レコードの生成
変更されたデータで、新しい次元レコードを作成する手法。
この手法では履歴を保持することが可能。
例えば事業所が移転した場合、下記のようにレコードを作成する。
・旧レコードは「事業所Ａ、神奈川」
・新レコードは「事業所Ａ、東京」
事業所コードのようなキーがあれば、グルーピングすることで継続的に事業所Ａの売上分析が可能だし、年毎の地域別売上のような分析も、履歴レコードがあることで実現可能になる。
3. 新旧属性値の保持
1レコードに、オリジナル値と最新値を持たせる手法。
例えば組織名が変わったが、以前のデータを最新の組織の情報として扱いたいい場合などに使える。
・変更前「システム部」
・変更後「ITソリューション部」
のような場合、1レコードで「オリジナル組織、最新組織」を持つ。
これにより、最新組織の分析情報として古いデータも分析情報に集約できる。
注意点と対策
上記３つの手法のいずれであっても、次元の統合には対応できない。
あくまで属性の変化にしか対応できない。
例えば、事業所Ａと事業所Ｂが統合された場合などは対応不可能である。
詳しく調べていないが、データボルトモデルモデリングを使えば統合も実現可能なのではなかろうか。
リンクやサテライトによって履歴も失わないし、統合も可能？
しかしこの手法は理論的には納得できるものの、リンクテーブルがカオス化していきそうな雰囲気がすごい。
データクレンジングというかETLをしっかりして、DWHのモデルは可読性を保持したほうがいいと思うんだがなぁ。
