概要
スタースキーマを学習した後で
モデルとしてスタースキーマが存在するが、実際の業務システムを単一スタースキーマで表現することは難しい
とのことだったので複数スタースキーマを勉強した。それのまとめ
以下参考
複数スタースキーマについて
複数のプロセスを横断的に分析できるのが真に価値ある分析となる
ファクトの発生イベントが異なるものは分ける
記事では
・製品別注文数量
・製品別出荷量
というファクトに対して
・時間
・顧客
というディメンションがある場合の単一スキーマにした時の失敗が記載されている。
要約すると
ファクトテーブルのカラムに複数イベントを格納するとたいてい後で苦しくなる
理由
・対象イベント外のファクトデータに無意味なデータが格納される
ファクトテーブルはそれぞれのイベント発生時のデータを格納するが、それ以外のイベントが発生しなければ格納する値がない
→デフォルトキー(Nullか0等。Nullはあまり使いたくないので0を格納する)を設定する
→時間軸などで分析した時に、デフォルトキーで格納されているデータも引っ張られるので、意味のないレコードが分析データ内に残る
・クエリで解決しようとしても複雑性が増す
上記の内容をクエリでフィルタリングして解決することにする
→サブクエリや集計処理などでフィルタリングのことを考慮する必要があり、この制約が効いてくる(悪いほうに)
解決策
素直にファクトテーブルをイベント(プロセスと呼んでいる)毎に分けること
→それぞれでディメンションテーブルとリレーションをはってモデリングする
複数のファクトテーブルの横断的な分析がしたい
上記のようなモチベーションがあるとする(業務間の比較(e.g. 生産と受注の比較など))
落とし穴
この時、素直にJOINしてしまうとファントラップという現象が起きる可能性が高い
どうするか
１．それぞれのファクトテーブルをいったん分析軸となるディメンションテーブルと結合する
→WITH句などで切り出すのが効率的
→Group By句でディメンションの外部キーを指定してグループ化する
２．１で結合したファクトテーブル同士をFULL JOINする
→ディメンションのキーは一意のものとなっているので、重複する値がなくなりファントラップは起こらない
上記の方法をドリルアクロスと呼ぶらしい
詳しくは記事のソースを確認したら理解しやすい
まとめ
・単一スタースキーマでは業務プロセスを分析するのは難しい(できてたら状態がないことになる)
・イベント(＝プロセス)毎にファクトを分ける
・複数のファクトを横断的に分析するときはドリルアクロスでファントラップしないようにする
理論としては理解したので実践してみたい。
結局単一スタースキーマで表現されるのは、業務プロセス内の単一イベント。
業務プロセスごとのファクトは異なるので、まずは業務プロセスを理解し、それぞれのプロセスのファクトとディメンションを分けることを考えれるようにする。