Slowly Changing Dimensions (SCD)について

Slowly Changing Dimensions (SCD)って何でしょうか。
実はこれデータウェアハウスで使用するディメンションデータの更新の対応方法のことなのです。
ディメンションとは、年や月、製品、住所などのデータを分析する上で必要になる切り口のことですが、
これは更新されることがあります。例えば、Aさんが引っ越して、住所が長野県から東京都にかわるなどです。
それをそのまま何も考えずに上書きすると大変なことになります。なぜなら、今まで長野県に住んでいるときに
行った過去の行動が東京でおこったことになるからです。
そのため、データウェアハウスの設計ではこの更新する方法論が確立されています。
基本はType0~Type4まであり、あとそのハイブリット型があります。

Type 0 SCD:
何もしない。値がかわっても無視です。

Type 1 SCD:
値が変化したときに、テーブルの値をそのまま上書き変更します。
これは、変更がビジネス上さほど重要でない場合に採用します。たとえば、顧客の名前など。。。
問題点としては、顧客の住所などを上書きすると、過去のデータを地域別でみた場合、
データが正しく分析できないことです。
また、注意としてサマリーデータなどを持っている場合は、データを再構築する必要があります。

Type 2 SCD:
値が変化したときに、新しいレコードを追加します。
また、各レコードにStart dateとEnd dateを入れておきます。
最新のデータはEnd dateに9999131などを入れておきます。
問題点としては変更が多いとたくさんのレコードが増えます。
また、この場合過去のサマリーテーブルは再構築する必要はありません。

Type 3 SCD:
あらかじめデータに現在の値とその前の値のフィールドを用意しておき、
変更があった場合に古いデータを以前のデータフィールドへ入れて、最新の現在のデータフィールドへ
格納します。
問題点は複数の変更に対応できません。保持できるのは一つ前のデータだけ。
でもこれは営業のテリトリー変更などで一つまえのテリトリーで現在の値をみたい場合などに威力を発揮します。

Type 4 SCD:
これはテーブルには最新の情報を保持し、古いデータは別途用意した履歴テーブルへ格納します。
問題点としてはシステムが複雑になります。

Hybrid SCDs
これ以外にそのハイブリット版として２つの方法があります。

Predictable changes with Multiple Version overlays
これは例えば、毎年営業のテリトリーが変更になり、分析要件として
情報すべてを指定した年のテリトリーで数値をみたい場合などに利用します。
方法としては、レコードの列にそれぞれの年のフィールドを用意しておきます。
例：District 2010, District 2009, District 2008.....
でもシステムがとっても複雑になるので、諸刃の剣です。

Unpredictable Changes with Singel version overlay
これは予測できない変更に対して、分析の切り口として現在の状態での切り口とそのデータが発生したときに
切り口でみたい場合にしようします。
これはレコードにCurrentとPreのフィールドを用意しておき、変更があった場合に
レコードを追加し、関連するCurrentの変更を行う方法です。
例をみるとこんな感じ。
key,name, current, pre
1,AAA,TOKYO,NAGANO
2,AAA,TOKYO,KANAGAWA
3,AAA,TOKYO,TOKYO
これは、Type 2 と Type 3と Type 1を合わせた感じなので、Type 6(2+3+1)と呼ばれています。。。

このタイプは各レコードの列ごとに適用ですので、設計時にどれにするか入念な検討が必要となります。
設計する上で非常に重要な概念です。