この記事は、前回書いたデータモデリングの9つのことの1つ目です。
crmprogrammer38.hatenablog.com
まず、物理的に1:Nで結合するという点について以下を示しています。
・ディメンションとファクトで結合する際に、ディメンション側の結合キーはユニーク制約があること
ポイントはユニーク制約なので、いわゆるPK(ユニーク+not null)である必要はありません。データベース側が結合条件の項目がユニークであると認識できることが必要です。(要するに、PKか、Unique Indexのどちらかが必要。TERADATAであればUPIも使えます)
当たり前のように感じますが、データが複雑になればなるほど見落としがちになります。
例えば、次のような店舗毎に営業日が異なるカレンダを考えます。
(年月日と店舗でユニークです)
結合するファクトに、年月日と店舗の要素があれば、上記のカレンダとファクトは、1:Nで結合できています。
[結合条件] これは1:Nでの結合条件
店舗別カレンダ.年月日 = ファクト.年月日
and 店舗別カレンダ.店舗 = ファクト.店舗
ですが、ファクトに店舗の要素がなく、店舗別カレンダの代表店舗を指定する場合の結合は、データとして考えれば1:Nですが、結合条件としては物理的に1:Nでありません。
[結合条件] データとしては1:Nだが、結合条件としては1:Nではない。
店舗別カレンダ.年月日 = ファクト.年月日
and 店舗別カレンダ.店舗 = '固定値の条件'
データベースのオプティマイザ次第ですが、結合が1:Nであることを明確にしたほうが性能も安定します。
そのため結合条件に代表店舗を指定して結合するのではなく、代表店舗のカレンダレコードで新規にカレンダを物理的に作成して、そちらを利用します。
テーブルが増えていくことだけが難点ですが、これで性能が安定するなら大したことではないです。