データウェアハウスキンボールの顧客と顧客の住所のディメンション
顧客テーブルと複数の顧客アドレスがあります。顧客は、自宅、職場、休暇など、複数の住所を持つことができます。
キンボールデータウェアハウスでは、ブリッジテーブルを利用して、顧客と顧客の住所情報の間を行き来できますか？
（a）それでは、[DimCustomer]から[DimCustomerAddressBridge]から[DimAddress]テーブルへ？これは適切なテクニックでしょうか？
（b）または、2つのディメンション[DimCustomer]と[DimAddress]を接続するCustomerTransactionPaymentテーブルのようなファクトテーブルを用意しますか？
したがって、1つの戦略はブリッジを使用して接続されたDimsであり、別の戦略はファクトトランザクションテーブルによって接続された切断されたDimsですか？
正しいスキーマは、このデータの使用方法によって異なります。あなたのオプションについて話しましょう：
a）ブリッジテーブル
ブリッジテーブルはN:Nの関係を表すために使用されるため、私はこのアプローチを使用します。あなたがそれのために行くなら、それはあなたの取引のための正しいアドレスが何であるかを正確に言うことは不可能でしょう。それは役に立たないでしょう。
キンボールグループ->「多対多の関係がファクトテーブル自体で解決できない場合、ブリッジテーブルが使用されます...」 https://www.kimballgroup.com/2008/09/design-tip-105-snowflakes-outriggersand-bridges /
b）別の次元を作成しますDimAddress（DimGeography？）
このアドレス情報が他のファクトテーブルに関連している可能性がある場合は特に、これは良いアプローチに見えます。たぶん、それをDimGeographyなどに拡張できます。この場合、DimGeographyとDimCustomerは直接関連付けられません。
その他のオプション
c）Customerディメンションの細分性をAddressレベルに変更することもできます。したがって、住所ごとに1つの行があり、「マスター顧客データ」は、このディメンションの同じ顧客に対して同じになります。 ->ほとんどのデータが住所レベルに関連している場合は、それを行ってください。
d）別のアプローチは、スキーマをスノーフレークすることです。次に、このファクトで使用できるDimCustomerAddressを作成します。ここで、ファクトテーブルはDimCustomerAddressを指し、DimCustomerAddressはDimCustomerを指します。この方法では、Customerテーブルを変更せず、他のファクトテーブルも変更せず、Customer-> Address階層を作成できます。
e）住所の変更履歴を追跡する必要がある場合（コメントに基づく）
このソリューションはd）に似ていますが、DimCustomerAddressはSCDタイプ2になります。これにより、新しいDimCustomerAddressの粒度が「アドレス履歴」になります。つまり、このディメンションのビジネスキーは顧客ID、住所ID、住所タイプであると想定するため、住所を変更するたびに新しい行を追加する必要があります。住所が有効な開始日と終了日を追跡し続ける。ファクトテーブルは代理キー「CustomerAddressKey」によってDimCustomerAddressと関連付けられている必要があり、DimCustomerAddressは「CustomerKey」を使用してDimCustomerと関連付けられている必要があります。開始日と終了日をETL時間中に使用して、ファクトテーブルにデータを入力し、正しい「CustomerAddressKey」を決定できます。 