數據倉庫設計小知識之一個屬性的維度設計

我們通常在數據倉庫的設計中碰到這種問題：在維度設計中如果這個維度只有一個屬性，那我們面臨的選擇是為這個屬性單獨創建一個維度，還是將這個維度的屬性直接放在事實表中作為事實表的一部分？

假設這里有一個維度，通常在設計上至少會有兩列（DimKey 和 DimAttribute 屬性），事實表通過 DimKey 關聯到這個維度。首先，在查詢階段多表的 JOIN 關系比較單表的查詢在效率上肯定要低一些，我們來看下下面的這個例子：

CREATE DIM_TABLE
(
 DIM_KEY  INT PRIMARY KEY IDENTITY(1,1),
 DIM_ATTR NVARCHAR(20)
)

CREATE FACT_TABLE
(
 DIM_KEY INT FOREIGN KEY REFERENCES DIM_TABLE(DIM_KEY),
 MEASURE DECIMAL(18,2)
)

一個典型的星型結構的查詢如下：

SELECT D.DIM_ATTR,
       SUM(F.MEASURE) AS TOTAL
FROM FACT_TABLE AS F
INNER JOIN DIM_TABLE AS D
ON F.DIM_KEY = D.DIM_KEY
GROUP BY D.DIM_ATTR

如果把這個屬性直接放在 FACT 表中，結果和查詢如下：

CREATE TABLE FACT_TABLE_2
(
 DIM_ATTR INT FOREIGN KEY REFERENCES DIM_TABLE(DIM_KEY),
 MEASURE DECIMAL(18,2)
)

SELECT SUM(MEASURE) AS TOTAL
FROM FACT_TABLE_2
GROUP BY DIM_ATTR

我們的查詢和聚合更加簡單，從查詢效率上來說要更好一些。但是我們通常又為什么會選擇將這個單獨的屬性還是放在維度表中，這里有以下幾個原因是我們需要考慮的：

1. 如果事實表非常龐大的話，使用 DIM_KEY INT 類型 4 Bytes 相對於 DIM_ATTR 的 NVARCHAR(20) 類型可以明顯的減少事實表的體積。

2. 如果這個屬性值在源業務系統發生改變的話，就意味着我們要更新事實表中所有與該屬性相關的屬性值。

3. 有可能今天這個維度確實只有一個屬性，但是誰又能確保這個維度以后不會添加別的相關的屬性呢？

數據倉庫的設計是一個迭代的開發過程，開發一年，維護若干年，如果我們可以考慮到以上原因，就可以很清楚的考慮到在設計階段是否有必要將單一屬性挑選出來作為維度來設計了。

更多 BI 文章請參看 BI 系列隨筆列表 (SSIS, SSRS, SSAS, MDX, SQL Server) 如果覺得這篇文章看了對您有幫助，請幫助推薦，以方便他人在 BIWORK 博客推薦欄中快速看到這些文章。