數據倉庫 Kimball 客戶和客戶地址維度
我有一個客戶表和多個客戶地址。一個客戶可以有多個地址：家庭、工作、假期等。
在 Kimball 數據倉庫中，我是否會使用橋接表來連接客戶和客戶地址資訊？
（一）所以
$$ DimCustomer $$到$$ DimCustomerAddressBridge $$到$$ DimAddress $$桌子？這會是正確的技術嗎？ (b) 或者我只是有一個事實表，比如 CustomerTransactionPayment 表，它連接兩個維度
$$ DimCustomer $$和$$ DimAddress $$? 那麼一種策略是使用橋接連接的 Dims，而另一種策略是通過 Fact 事務表連接的斷開連接的 Dims？
正確的架構取決於您打算如何使用這些數據。讓我們談談您的選擇：
a) 橋接表。
我不會使用這種方法，因為橋表用於表達
N:N關係。如果你這樣做，那將無法準確地說出你的交易的正確地址是什麼；所以這將是無用的。跟隨 Kimball 組 - >“使用橋接表……在事實表本身中無法解決多對多關係……” https://www.kimballgroup.com/2008/09/design -tip-105-snowflakes-outriggers-and-bridges/
b) 創建另一個維度 DimAddress (DimGeography?)
這看起來是一個不錯的方法，特別是如果此地址資訊可能與其他事實表相關。也許您可以將其擴展為 DimGeography 或類似的東西。在這種情況下，DimGeography 和 DimCustomer 不會直接相關。
其他選項
c) 您還可以將客戶維度的粒度更改為地址級別；因此，每個地址會有一行，並且“主客戶數據”對於該維度中的同一客戶來說是相同的。-> 如果您的大部分數據與地址級別相關，請執行此操作。
d）另一種方法是雪花你的模式。然後創建一個可以用於這個事實的 DimCustomerAddress；您的事實表指向 DimCustomerAddress 和 DimCustomerAddress 指向 DimCustomer。這樣，您既不會更改您的客戶表，也不會更改其他事實表，並且可以創建客戶 -> 地址層次結構。
e) 如果您必須跟踪歷史地址更改（基於評論）
此解決方案類似於 d)，但 DimCustomerAddress 將是 SCD 類型 2。這將使您的新 DimCustomerAddress 的粒度成為“地址歷史記錄”。IE：我假設你這個維度的業務鍵是Customer ID、AddressID和Address type，所以每次地址更改時都應該添加一個新行；跟踪地址有效的開始和結束日期。您的事實表應通過代理鍵“CustomerAddressKey”與 DimCustomerAddress 相關，並且 DimCustomerAddress 應使用“CustomerKey”與 DimCustomer 相關。在 ETL 時間內可以使用開始和結束日期來填充事實表以確定正確的“CustomerAddressKey”。
