この記事は、前回書いたデータモデリングの９つのことの５つ目です。
crmprogrammer38.hatenablog.com
この辺りからは、ゆるくモデリングしようよという内容になっています。
ディメンションと結合するのはファクトだけで、ディメンションからさらにディメンションに結合はしないのがスタースキーマのモデリングですが、ディメンションの項目が増えすぎて逆に性能が落ちてしまう場合があるので注意。
企業のデータで、ディメンションになることが多いのが、顧客軸、商品軸、組織軸だと思います。顧客軸でも、顧客の販売店、その上の支社、そして本社などの階層を持っていたり、商品、組織も5階層ぐらいのところが多いと思います。
仮に商品の属性が30項目あって、その項目を階層分に１つのディメンションに定義してしまうと、30項目×5階層で150項目のディメンションになってしまいます。ディメンションなので名称項目などを持つためサイズも大きくなります。
[大きなディメンション構造]
そんなディメンションを用意するぐらいならば、商品の階層情報だけを持つ商品階層ディメンションと、その商品階層ディメンションと商品ディメンションを結合させて使った方がいいと思います。
商品階層も、全階層で見る頻度は低く、5階層あったうちの２つぐらいをチョイスするような使い方であればデータベースの処理コストも下がります。
ディメンションが大きくなりすぎる前に考えたいものです。
ちなみに、階層だけでなく、例えば店舗などでも、店舗に様々な分析軸を持たせてデータを持たせたい場合もあると思います。主キー項目が店舗コードのディメンションだからといって無理に統合せず、店舗コードが主キーのディメンションが用途別に複数あっても大した問題ではないと思います。
