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

咱們一般在數據倉庫的設計中碰到這種問題：在維度設計中若是這個維度只有一個屬性，那咱們面臨的選擇是爲這個屬性單首創建一個維度，仍是將這個維度的屬性直接放在事實表中做爲事實表的一部分？

假設這裏有一個維度，一般在設計上至少會有兩列（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 博客推薦欄中快速看到這些文章。