スタースキーマとキューブ(8)

ディメンションテーブルに保持すべきデータがデータソースシステム（業務システム）において変化した場合に、多次元データモデルでどのように扱うのかというのが「緩やかに変化するディメンション(Slowly Changing Dimensions)」の論点です。

Type1変更

データソースの業務システムでディメンションテーブルの値が変更された時、スタースキーマにおいて変更の履歴を保持する必要がない場合にType1が選択されます。ディメンションは単純に新しい値に上書きされます。この方法はソースデータにおいて「間違いがあるた場合に修正する」際に主に使用されます。

ディメンションデータを上書きするためType1変更はデータ変更の履歴は持たないため、該当列のデータが以前異なるものであったかどうかは判別することができません。ディメンションの変更前のデータがファクトと関連性を持っていた場合、全て遡及して変更が発生するためしばし混乱が発生することになります。

ディメンションの上書き変更

先ほどのSue Johnsonの誕生日の変更を例に考えます。最初にSue Johonsonは誕生日を1961年と記録されていますが、後に誕生日は1971年に変更されています。人間の誕生日はそもそも変更はあり得ないことから、データソースシステムで変更されることはエラー訂正ということになります。

受注処理を分析するためのスタースキーマの「顧客」ディメンションテーブルを例に考えてみます。このテーブルのナチュラルキーは顧客ID(customer_id)となり、顧客名(cusomer_id)、誕生日(birth_of_date)、住所(state)などを保持しています。

顧客ディメンションテーブルにおいて、Sueに関する行が存在しています。Sueのcustomer_idは990001でこれはナチュラルキーで、データソースシステムにおける主キーになります。図ではサロゲートキーcustomer_keyが存在していて1499の値になっています。

ここで、Sueの誕生日の変更が発生して、Type1変更が行われた場合についてみていきます。customer_id=990001の行にSueの誕生日が1971年2月3日にupdateされますがこの行のサロゲートキーは1499のままです。

既に存在するファクト分析とは別の意味になる

Type1変更はファクトテーブルの分析に影響を与えますが、この点はしばし見落とされるケースが多いです。ディメンションテーブルの値がupdateされた時、既存のファクト分析と意味は異なる場合が出てきますが、このことが混乱を発生させます。

先ほどのSueの誕生日の変更を例に考えてみます。ファクトテーブルに日付に関するサロゲートキー(day_key)2322が存在しています。もし「顧客の誕生日」における注文を集計するとき、Sueの注文は誕生日が1961年2月3日の顧客としてリストアップされますが、これを誰かがレポートとして印刷したと仮定します。

この後、Sueの誕生日についてType1変更が行なった場合、Sueのデータは1971年2月3日にリストアップされることになります。同じ日付(day_key)に関するレポートを作成しているのですが、前回とは異なる出力結果になってしまいます。

Type1変更に関するこの種の混乱はきちんとした段階を取って行えば最小化することができます。ユーザーにこの種の変更があることを気付かせるようにするという方法です。レポート作成時（クエリー発行時）の年月日をヘッダー、フッターに記載するなどしてどのレポートが最新化というのを認識させるようにしたり、利用者への告知（教育）で対応することになります。つまり、データは常に変化する可能性があるということをユーザーにも理解してもらう事です。

実際問題としては、多くの現場ではそもそもType1変更は避ける例が多いです。

Type1変更とスタースキーマ

ここまで見てきたように、ファクトを分析する際に、Type1変更はディメンションの履歴を追跡することができないという問題があります。スタースキーマ内のデータの変更が一切追跡することができないことになります。一方、コーポレートインフォメーションファクトリアーキテクチャにおけるエンタープライズデータウェアハウスにおいてはETLの中で履歴を保持するように処理することが可能です。

（次回はType2変更について説明します）