sql-server-2012 - 次元モデリング

Question

複数のテーブルから顧客設定を調達するためのディメンションを構築しようとしています。

ソーステーブルの例は次のとおりです。

私はすでにDimCustomerを構築しましたが、今度はCustomerPreferenceDimensionを設計する必要があります。新しいディメンションはSCD1になります。常に顧客に最新の好みを持っています。ただし、特定の顧客は複数の組み合わせを持つことができます。

今私の質問：各プリファレンステーブルのディメンションを設計するのは良いことですか？以下のように、顧客のすべてのプリファレンス属性を1つの単一のディメンションテーブルにまとめる必要があります：

強調表示された列は、顧客の独自の好みになります。*お客様は複数の設定を行うことができます。

将来、ビジネスでさらにいくつかの設定が導入され、ディメンションに含めたい場合はどうでしょうか。次に、これらの属性と、一意にするキーを上記の表に含める必要があります。

上記のように、設定ごとに個別のディメンションを実行するか、すべてを1つの大きなディメンションにマージする方がよいでしょうか。

提案をお願いします。

編集：

私の読書に加えて、私は自分の顧客の薄暗い次元と他の顧客の好みの次元との間のブリッジテーブルを設計する必要があることを理解しています。

私が計画しているのは、すべての組み合わせで各プリファレンスタイプのCustomerPreferenceディメンションを作成することです。そして、これらを多対多の顧客選好関係を持つことができるブリッジテーブルにマッピングします。

以下の例

これは正しい方法ですか、それともベストプラクティスがありますか。

[または]これは正しい方法ですか？

編集：2013年3月27日

Pondlifeの提案によると、以下のようにSnowflakeアプローチを採用しています。

Answer 1

ファクトテーブルについては何も言っていません。これは、決定の重要な要素になる可能性があります。設定が顧客にのみ適用され、事実とはまったく関係がない場合は、スノーフレークモデルを使用して、顧客ディメンションのみにリンクされた顧客設定テーブルを追加できます。

しかし、あなたは「好みごとの個々の次元」について言及しました。これは、好みが事実に直接関連している可能性があることを示唆しています。その場合、ファクトごとに可能なプリファレンスの数が限られている場合（これは、提供した情報からは明確ではありません）、プリファレンスのすべての可能な組み合わせを含むミニディメンションがより適切なオプションである可能性があります。

これが役に立たない場合は、次の点を明確にすることをお勧めします。

1. ファクトテーブルが表すもの
2. 好みが事実または顧客にリンクされている場合
3. 1人の顧客（または事実？）が最大3つのプリファレンス（マーケティング、プラットフォーム、およびジャンル）、または未定義の数（たとえば、3つのマーケティングプリファレンス、10のプラットフォームプリファレンス、2つのジャンルプリファレンス）を持っている場合

Answer 2

開発者は、新しい設定が追加されたときにDBを変更する必要がないため、作業が「簡単」になると考えているため、顧客の設定には恐ろしい「エンティティ-属性-値」モデルがあります。もちろん、それはあなたの人生をはるかに難しくします。

私は現在同様の状況で働いており、顧客の好みをモデル化する最も簡単な方法は、特に多対多の場合に、自分で見つけた属性ブリッジテーブルを使用することです。

尋ねる必要がある本当の質問は、これらの設定に対してどのような分析が行われるのかということです。好みに基づいて顧客をフィルタリングするだけで、その顧客のセットで事実を確認する場合は、多くのブリッジがそのトリックを実行する必要があります。