プログラマ38の日記

主にプログラムメモです。

DWH: データモデリング (1.ディメンションとファクトは、物理的に1:Nで結合する。)

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

 

crmprogrammer38.hatenablog.com

 

まず、物理的に1:Nで結合するという点について以下を示しています。

・ディメンションとファクトで結合する際に、ディメンション側の結合キーはユニーク制約があること

 

ポイントはユニーク制約なので、いわゆるPK(ユニーク+not null)である必要はありません。データベース側が結合条件の項目がユニークであると認識できることが必要です。(要するに、PKか、Unique Indexのどちらかが必要。TERADATAであればUPIも使えます)

 

当たり前のように感じますが、データが複雑になればなるほど見落としがちになります。

 

例えば、次のような店舗毎に営業日が異なるカレンダを考えます。 

(年月日と店舗でユニークです)

f:id:crmprogrammer38:20170222111655p:plain

 

結合するファクトに、年月日と店舗の要素があれば、上記のカレンダとファクトは、1:Nで結合できています。

f:id:crmprogrammer38:20170222111706p:plain

[結合条件] これは1:Nでの結合条件

       店舗別カレンダ.年月日 = ファクト.年月日

and 店舗別カレンダ.店舗    = ファクト.店舗

 

ですが、ファクトに店舗の要素がなく、店舗別カレンダの代表店舗を指定する場合の結合は、データとして考えれば1:Nですが、結合条件としては物理的に1:Nでありません。

f:id:crmprogrammer38:20170222111725p:plain

[結合条件] データとしては1:Nだが、結合条件としては1:Nではない。

       店舗別カレンダ.年月日 = ファクト.年月日

and 店舗別カレンダ.店舗    = '固定値の条件'

 

データベースのオプティマイザ次第ですが、結合が1:Nであることを明確にしたほうが性能も安定します。

 そのため結合条件に代表店舗を指定して結合するのではなく、代表店舗のカレンダレコードで新規にカレンダを物理的に作成して、そちらを利用します。

f:id:crmprogrammer38:20170222111743p:plain

テーブルが増えていくことだけが難点ですが、これで性能が安定するなら大したことではないです。