個別のアドレスディメンションを使用する必要がありますか？
2つのディメンション（ユーザーとストア）を持つスタースキーマモデルがあり、それぞれにアドレスがあり、それを保存します。
各ユーザーとストアは1つのアドレスを持つことができます。ディメンションをアドレスディメンション（1：1の関係）に分割することをお勧めしますか？このように扱うための技術的な議論はありますか？それとも、住所をユーザー/ストアディメンションに保持する一般的な方法ですか？
住所はファクトレコードではなくディメンションメンバーのプロパティであるため、ユーザー/ストアディメンションに住所を追加する必要があります。
ディメンションに住所を追加すると、country -> city -> user間の属性関係を定義できます。これにより、これらの属性を使用して階層を作成する際のパフォーマンスが向上します。
通常、より簡単に計算されたメジャーも可能になります。
最後に、ディメンションの属性として住所を指定すると、ユーザー/ストアが新しい住所に移動した場合に、 ディメンションをゆっくりと変更する を簡単に処理できるようになります。
これは意見ですが、私はあなたが尋ねている質問の線に沿っている この答え に同意します。リンクが冷えた場合に備えて、ここのリンクから回答をコピーしています。
ある状況では、住所のタイプと住所のソースの列を住所ディメンション自体に含める必要があるように思われるため、スタンドアロンであり、ファクトを経由して種類を知る必要はありません。それは物事の。前述のように、キーを含む個別のテーブルは必要ありません。データはディメンション内で安全に非正規化できます。
余談として：
多くの人が別個の住所テーブルを持っていますが、キンボールグループからのアプローチは、独立した多目的ディメンションとして「住所」または場所ディメンションを持つことではありません-それは何か他のものを説明するものの一部を提供します（会社、または顧客、あるいは「配達場所」）。代わりに、ディメンション（Customerなど）があり、そのディメンション内に、適切な名前が付けられたいくつかのAddressフィールド（CustomerAddress1、CustomerAddress2、CustomerCity）があります。ビューまたは追加のETLによって形成された他のディメンションを使用して、バックグラウンドで便宜上アドレスを一元的に管理することを選択できますが、スタースキーマの表示では、アドレステーブルは個別に表示されません。アドレスは、同じものと呼ばれ、同じものを意味するという点で引き続き準拠しています。
しかし、あなたがやったように、多くの人が別のアドレステーブルを使います