在星型模式中擁有時間維度的好處？
星型模式中的時間維度與事實表本身中的時間屬性相比有什麼好處？
例如：
我有一個交易數據，其中包含每筆交易的使用者資訊、交易發生的國家和交易發生的日期。
選項 1 如果我錯了，請糾正我，但這可能是許多人最常用和最推薦的方法：
- 包含
transaction_ID(PK)、user_id(FK) 和country_id(FK) 以及 date_id (FK)的事務事實表- 包含 (PK) 和其他使用者屬性的使用者維度
user_id，比如說name&phone_number。date_id由(PK)、date、day、month、year、組成的日期維度quarter。選項 2 我剛剛想到的東西，而不是選擇選項 1，但不確定：
- 包含
transaction_ID(PK),user_id(FK) 和country_id(FK),date,day,month,year, 的事務事實表quarter。- 包含 (PK) 和其他使用者屬性的使用者維度
user_id，比如說name&phone_number。與Option 2相比， Option 1有什麼好處？我不知道為什麼加入另一個 Date 維度會是一個更好的選擇，即使它是最廣泛使用的方法。非常感謝！
讓我用一個從簡單的事務表開始的場景來回答這個問題。當我們的業務開始時，管理層想知道當月的“名稱”，所以我將這些資訊包含在表格中。
DECLARE @Transactions TABLE ( TransactionId INT ,UserId VARCHAR(10) ,CountryId INT ,TransactionDate DATE ,[MonthName] VARCHAR(20) ,SalesAmount DECIMAL(18, 2) )業務一直很好，我們的 Transactions 表中已經有 100 萬行。事實上，生意如此之好，以至於管理層現在正在就我們的銷售提出更深入的問題。他們想知道銷售是在哪個“季度”進行的。
ALTER TABLE Transactions ADD [QuarterName] VARCHAR(10) UPDATE Transactions SET QuarterName = ...我們剛剛更新了 100 萬行。
隨著時間的推移，管理層開始對我們的銷售提出越來越多的問題。
- 那次銷售是在哪一天進行的？
- 那是假期嗎？
- 那天月圓嗎？
ALTER TABLE Transaction ADD ...
UPDATE TABLE SET ...希望你能看到這是怎麼回事。此外，每個事務行上的所有冗餘數據都會導致性能下降和資源使用率增加（記憶體、磁碟空間等）。我們的數據庫更大，備份時間更長。所有的冗餘數據都佔用了記憶體。
使用日期維度表，所有這些資訊都儲存在一個地方。日期從 2000-01-01 到 2100-01-01 的日期維度表僅包含 36525 行。任何時候我們想要跟踪日期的新屬性，我們只需要通過添加附加屬性來更改該表並更新 36525 行。
當我們想要關於銷售的“日期”屬性的特定資訊時，我們只需加入日期維度表
此外，日期維度中的數據是一致的。
January拼寫正確，Saturday拼寫正確等。將此類數據儲存在 Transaction 表中會導致各種拼寫錯誤等的差異。有關創建日期維度表的更多資訊，請查看 在 SQL Server 中創建日期維度或日曆表