星型模式中的“維度”表和關係數據庫中的“查找”表有什麼區別？
我正在嘗試設計一個星型事實表以及一些圍繞它的維度表。
customer_key如果我重用在兩者中呼叫的自然鍵fact_table，dim_customer那麼我看不出呼叫一些暗淡的東西和查找表之間有什麼區別。此外，如果我每次都需要更新，customer_name我將失去在記錄時代表這一事實的歷史數據。嘗試對昏暗表和事實表進行建模時，我缺少什麼？我想了解關係“查找”表技術和數據倉庫“維度”表之間的區別？
fact_table dim_customer dim_product ------------- ------------ ----------- customer_key customer_key product_key product_key name name units_sold email description unit_price請原諒我在這個問題中可能表現出的任何無知。我是數據倉庫新手。
如果您只有這些表，那麼您的數據倉庫星型模式和您的實際模式之間將幾乎沒有區別。
不過，您可能有一個更複雜的關係架構，其中您還有客戶組或項目類型，並且您的架構看起來更像
事實表->客戶表->客戶組表
事實表->項目表->項目類型表
當您使用星型模式時，您將對模式進行非規範化，以便將客戶組描述包含在您的客戶維度表中，並將您的項目類型描述包含在您的項目維度表中。
星型模式的基礎是你有一個事實表，每個維度都是一個表，離事實表只有一步之遙。
金博爾描述它的方式：
星型模式通常由事實表組成，這些事實表通過主/外鍵關係連結到關聯的維度表。
如果您不將維度非規範化為單維度表，您最終會得到雪花模式。雪花似乎是個好主意，但它們通常會導致查詢性能下降，並且以後會給您帶來各種麻煩，特別是如果您計劃在數據倉庫之上建構多維數據集時。
Kimball再次發表了一篇文章：
我們通常鼓勵您在單個維度表中處理多對一的層次關係，而不是雪花。對於有經驗的 OLTP 數據建模者來說，雪花可能看起來是最佳的，但對於 DW/BI 查詢性能來說，它們並不是最佳的。連結的雪花表給直接暴露於表結構的使用者帶來了複雜性和混亂；即使使用者從表中緩衝，雪花也會增加優化器的複雜性，優化器必須將數百個錶鍊接在一起以解決查詢。Snowflakes 還給 ETL 系統帶來了管理連結規範化表的鍵的負擔，當連結的層次關係發生變化時，這些鍵會變得非常複雜。雖然雪花可以通過用程式碼替換重複的文本字元串來節省一些空間，但節省的空間可以忽略不計，
關於您關於更改客戶數據和失去歷史記錄的問題，在通過使用“緩慢變化的維度”解決的數據倉庫中。
您基本上有幾種緩慢變化的維度，但您可能正在尋找“類型 2”，這主要歸結為在維度行上儲存 valid_from 和 valid_to 日期，以便您可以選擇在交易時有效的行.
除了主代理鍵之外，我建議向正在進行類型 2 處理的維度添加五個附加欄位。這些欄位如圖 1 所示。日期時間是完整的時間戳，表示從更改生效到下一次更改生效之間的時間跨度。類型 2 維度記錄的結束生效日期時間必須完全等於該維度成員下一次更改的開始生效日期時間。
這是一個廣泛的主題，但我希望這能讓您走上正確的基礎，並且您將來可以使用正確的術語。