概要
ディメンショナルデータモデルについて学習したら、スタースキーマ設計について詳細に理解したいと思った。
そこで、以下記事を読んで理解した内容をまとめる
↓参考
ディメンションモデリング
・データウェアハウスにデータを格納するために、最適化されたデータ構造
スタースキーマ
・ディメンションモデリングをRDBで実装したもの
・DWHで利用されるスキーマ
・ファクトとディメンションからなる
・オンライン系モデルのデータからBIツール側でデータ利用したい場合に使える
→ファクトとディメンションを掛け合わせることで分析ができる＝理解しやすい
ディメンションテーブル設計Tips
サロゲートキーとナチュラルキー
・サロゲートキー
ナチュラルキーとは異なる、ETLプロセスの一部で作成される本質的な意味を持たない値
・ナチュラルキー
業務システムのエンティティを一意に識別可能なキー
何がうれしいか
・業務システムのエンティティに変更があった場合に履歴を保てるようにするため
→ファクトテーブルのキーの外部キーとしてサロゲートキーを指定し、業務システムのエンティティをナチュラルキーとすることで
業務システム側のキーの変更を吸収しながら履歴を保つことができる
ディメンションは細かく切り出す
・ファクトの文脈としてディメンションがある
・この文脈の豊富さがファクトの解釈を多様なものにする
ファクトテーブル設計Tips
測定値はすべて列に含める(計算列を使用しない)
冗長性があっても測定値は列として保持する
クエリやツールから一貫性のある測定ができる
→計算列を計算するようにすると、計算式が変更されたときの過去の計算列の意味が変わってしまう
→計算列を計算するようにしてしまうと、計算式が変わることで過去の値まで変わるため、計算列を含むことで時点の結果を不変なもの(一貫性)にする？
★ここについてあまり腑に落ちていないので誰か説明してください。。
粒度を細かくする
「月の売り上げが50万円」と「月の売り上げが100万円」と単に聞くと後者と判断する
→実は。。。実働１時間で50万と実働１００時間で100万かもしれない(ファクトを理解する文脈が少ないので評価指標が月という次元のみになる)
上記は極端な例だが、粒度の説明にはなっていると思う
全てのファクトを同じ粒度で格納されていることを保証するためには
→ディメンションを多く持つ(＝粒度を細かくしておく)ことでファクトテーブルの行が表す意味について混乱が生じにくくなる
まとめ
スタースキーマの設計方法について具体的に書かれていたのでよかった。
サロゲートキーとナチュラルキーをディメンションテーブルにしようして、サロゲートキーを外部キーとすることでエンティティの変更に追従して
履歴を残す方法などは他のサイトで見ることはなかったので(ググり力がないだけ？)非常に参考になった。