crmprogrammer38の日記

主にDWHやSalesforceのプログラムメモです。

【DWH】データモデリング (5.ディメンションを大きくし過ぎない。)

この記事は、前回書いたデータモデリングの9つのことの5つ目です。

 

crmprogrammer38.hatenablog.com

 

この辺りからは、ゆるくモデリングしようよという内容になっています。

ディメンションと結合するのはファクトだけで、ディメンションからさらにディメンションに結合はしないのがスタースキーマモデリングですが、ディメンションの項目が増えすぎて逆に性能が落ちてしまう場合があるので注意。

 

企業のデータで、ディメンションになることが多いのが、顧客軸、商品軸、組織軸だと思います。顧客軸でも、顧客の販売店、その上の支社、そして本社などの階層を持っていたり、商品、組織も5階層ぐらいのところが多いと思います。

仮に商品の属性が30項目あって、その項目を階層分に1つのディメンションに定義してしまうと、30項目×5階層で150項目のディメンションになってしまいます。ディメンションなので名称項目などを持つためサイズも大きくなります。

[大きなディメンション構造]

f:id:crmprogrammer38:20170222234125p:plain

 

そんなディメンションを用意するぐらいならば、商品の階層情報だけを持つ商品階層ディメンションと、その商品階層ディメンションと商品ディメンションを結合させて使った方がいいと思います。

商品階層も、全階層で見る頻度は低く、5階層あったうちの2つぐらいをチョイスするような使い方であればデータベースの処理コストも下がります。

f:id:crmprogrammer38:20170222234656p:plain

ディメンションが大きくなりすぎる前に考えたいものです。

ちなみに、階層だけでなく、例えば店舗などでも、店舗に様々な分析軸を持たせてデータを持たせたい場合もあると思います。主キー項目が店舗コードのディメンションだからといって無理に統合せず、店舗コードが主キーのディメンションが用途別に複数あっても大した問題ではないと思います。