設計資料倉儲結構描述

  • 7 分鐘

就像所有關聯式資料庫一樣，資料倉儲包含您想要分析的資料儲存所在的資料表。 最常見的情況是，這些資料表會組織於已針對多維度模型化最佳化的結構描述中，其中與稱為「事實」的事件相關聯的數值量值可依多個「維度」之間相關聯實體的屬性來彙總。 例如，與銷售訂單相關聯的量值 (例如，支付金額或訂購的項目數量) 可依銷售發生的日期、客戶、商店等屬性來彙總。

資料倉儲中的資料表

關聯式資料倉儲的常見模式是定義包含兩種資料表的結構描述：「維度」資料表和「事實」資料表。

維度資料表

維度資料表描述商務實體，例如，產品、人員、地點和日期。 維度資料表包含實體屬性的資料行。 例如，客戶實體可能具有名字、姓氏、電子郵件地址與郵遞區號 (其中可能包含街道地址、城市、郵遞區號，以及國家或地區)。 除了屬性資料行之外，維度資料表還包含唯一索引鍵資料行，可唯一識別資料表中的每個資料列。 事實上，維度資料表通常包含「兩個」索引鍵資料行：

  • 資料倉儲特有的「代理」索引鍵，可唯一識別資料倉儲內維度資料表中的每個資料列，通常是遞增整數。
  • 「替代」索引鍵 (通常是「自然」或「商務」索引鍵)，可用來識別實體記錄所源自之交易來源系統中實體的特定執行個體，例如產品名稱或客戶識別碼。

注意

為什麼要有兩個索引鍵？ 有幾個很好的理由：

  • 資料倉儲可能填入來自多個來源系統的資料，其可能導致商務索引鍵重複或不相容的風險。
  • 簡單的數值索引鍵在聯結許多資料表的查詢中通常執行得比較好，此為資料倉儲中的常見模式。
  • 實體的屬性可能隨著時間變更，例如，客戶可能變更其地址。 由於資料倉儲會用來支援歷史報表，因此，您可能想要在多個時間點為實體的每個執行個體保留一個記錄；例如，特定客戶的銷售訂單會計入其下單時所居住的城市。 在此案例中，有多個客戶記錄具有與該客戶相關聯的相同商務索引鍵，但客戶在不同時間居住的每個不同地址都有不同的代理索引鍵。

客戶的維度資料表範例可能包含下列資料：

CustomerKey CustomerAltKey 名稱 電子郵件 路/街 縣/市 PostalCode CountryRegion
123 I-543 Navin Jones navin1@contoso.com 1 Main St. 西雅圖 90000 美國
124 R-589 Mary Smith mary2@contoso.com 234 190th Ave Buffalo 50001 美國
125 I-321 Antoine Dubois antoine1@contoso.com 2 Rue Jolie Paris 20098 法國
126 I-543 Navin Jones navin1@contoso.com 24 125th Ave. 紐約 50000 美國
... ... ... ... ... ... ... ...

注意

觀察此資料表包含了兩個有關 Navin Jones 的記錄。 這兩個記錄都使用相同的替代索引鍵來識別此人 (I-543)，但每個記錄都有不同的代理索引鍵。 您可以由此推測出該客戶已從西雅圖搬到紐約。 當該客戶居住於西雅圖時，對其所做的銷售會與索引鍵 123 產生關聯，而當其搬到紐約之後所進行的購買，則會針對記錄 126 加以記錄。

除了代表商務實體的維度資料表之外，資料倉儲通常也包含代表「時間」的維度資料表。 此資料表可讓資料分析師透過時態性間隔彙總資料。 根據您需要分析的資料類型而定，時間維度的最低細微性 (稱為「精細度」) 可能代表時間 (到小時、秒、毫秒、奈秒，或甚至更低) 或日期。

日期層級上具有精細度的時間維度資料表範例可能包含下列資料：

DateKey DateAltKey DayOfWeek DayOfMonth Weekday 月 MonthName 季 Year
19990101 01-01-1999 6 1 星期五 1 一月 1 1999
... ... ... ... ... ... ... ... ...
20220101 01-01-2022 7 1 星期六 1 一月 1 2022
20220102 02-01-2022 1 2 星期日 1 一月 1 2022
... ... ... ... ... ... ... ... ...
20301231 31-12-2030 3 31 Tuesday 12 December 4 2030

資料表中記錄所涵蓋的時間範圍，必須包含相關事實資料表中所記錄之任何相關聯事件的最早和最新時間點。 通常，在中間的適當精細度上，每個間隔都有一個記錄。

事實資料表

事實資料表會儲存觀察或事件的詳細資料；例如，銷售訂單、存貨餘額、匯率或記錄的溫度。 事實資料表包含可依維度彙總之數值的資料行。 除了數值資料行之外，事實資料表還包含參考相關維度資料表中唯一索引鍵的索引鍵資料行。

例如，包含銷售訂單詳細資料的事實資料表可能包含下列資料：

OrderDateKey CustomerKey StoreKey ProductKey OrderNo LineItemNo 數量 UnitPrice 稅額 ItemTotal
20220101 123 5 701 1001 1 2 2.50 0.50 5.50
20220101 123 5 765 1001 2 1 2.00 0.20 2.20
20220102 125 2 723 1002 1 1 4.99 0.49 5.48
20220103 126 1 823 1003 1 1 7.99 0.80 8.79
... ... ... ... ... ... ... ... ... ...

事實資料表的維度索引鍵資料行會決定其精細度。 例如，銷售訂單事實資料表包含日期、客戶、商店與產品的索引鍵。 訂單可能包含多個產品，因此，精細度代表商店中，在特定日期銷售給客戶之個別產品的明細項目。

資料倉儲結構描述設計

在商務應用程式中所使用的大多數交易資料庫中，會將資料「正規化」以減少重複。 不過，在資料倉儲中，通常會將維度資料「取消正規化」，以減少查詢資料所需的聯結數目。

通常會將資料倉儲組織成「星型」結構描述，其中事實資料表會與維度資料表直接相關，如下列範例所示：

此圖顯示星型結構描述。

實體的屬性可用來將事實資料表中的量值彙總到多個階層層級，例如，依國家或地區、城市、郵遞區號或個別客戶來尋找總銷售額。 每個層級的屬性都可以儲存在相同的維度資料表中。 不過，當實體具有大量階層式屬性層級，或者當某些屬性可以由多個維度共用 (例如，客戶和商店都具有地理位址) 時，應該就要將某些正規化套用到維度資料表，並建立「雪花式」結構描述，如下列範例所示：

此圖顯示雪花式結構描述。

在此案例中，已將 DimProduct 資料表正規化來針對產品類別和供應商建立個別維度資料表，並新增 DimGeography 資料表來代表客戶和商店的地理屬性。 DimProduct 資料表中的每個資料列都包含 DimCategory 和 DimSupplier 資料表中對應資料列的索引鍵值；DimCustomer 和 DimStore 資料表中的每個資料列都包含 DimGeography 資料表中對應資料列的索引鍵值。