スタースキーマを設計する際、ディメンションテーブルの属性をどのようにグループ化するか決めること（一緒のテーブルに含めるか、含めないか）は、利便性と効率性に大きな影響を与えるので非常に重要である。
属性を適切にグルーピングすることで、以下のようなメリットが得られる。
- データモデルのシンプル化: 関連性の高い属性を 1 つのテーブルにまとめることで、テーブルの数が減り、データモデルを理解しやすくなる。
- クエリのパフォーマンス向上: よく一緒に使われる属性を同じテーブルに配置することで、結合の数が減り、クエリの実行速度が向上する。
- データの管理とメンテナンスの効率化: 属性のグループ化が適切だと、データの更新や保守作業がシンプルになり、データの整合性を保ちやすくなる。
したがって、効果的なデータウェアハウスを運用するには、ディメンションテーブルを設計する際に属性のグループ化について慎重に検討することが欠かせない。
本記事では、以下のような電話注文のソーステーブルを例にして、ディメンションテーブルのグループ化について解説する。設計時の留意点やサンプルを通じて、ディメンションテーブルのグループ化の理解を深めて欲しい。
設計方法
ポイント
スタースキーマでディメンションテーブルを設計する際、属性をグループ化するかどうかを判断するポイントは以下の 2 つである。
- 属性間に自然な親和性があるかどうか
- 属性間の関係性が他の文脈で成り立つかどうか
1. 属性間に自然な親和性があるかどうか
属性同士が、トランザクションや活動とは独立して関連性を持つ場合、それらは自然な親和性があると言える。
例えば、「製品とブランド、カテゴリ」、「オペレーターと役職」は、注文（トランザクション）が発生する前から関連性を持っている。このような親和性がある属性同士は同じディメンションテーブルに配置するのが適切である。
2. 属性間の関係性が他の文脈で成り立つかどうか
属性間の関係性がトランザクションや活動によってのみ定義される場合、それらは別のディメンションテーブルに配置すべきである。
例えば、「オペレーターと顧客」は、注文などのトランザクションが発生した時にのみ関連付けられる。このような属性は、「人間ディメンション」としてまとめるのではなく、別々のディメンションテーブルに配置し、それらの関係性はファクトテーブルで表現する。
完成形
本記事では、「ソーステーブルに元から存在していた属性をどのようにグループ化するか」だけに焦点を当てているため、その前提を踏まえたうえでのディメンションデザインの完成形は以下の通りである。日付ディメンション（dim_date）は、日付属性の特別なグループ化であるため別の記事で解説する。
まとめ
スタースキーマの利便性と効率性の観点から、ディメンションテーブルのグループ化は慎重に検討しなければならない。属性をグループ化するポイントは、以下の通り。
- 属性間に自然な親和性がある: 同じディメンションテーブルに配置する。
- 属性間の関係性がトランザクションを介して成立する: 同じディメンションテーブルに配置しない。
参考文献