kimball維度建模步驟

業務需求

維度模型

1.業務處理

2.粒度

3.維度

4.事實（資料實際）

首先對業務進行描述，以使建立的維度與事實表更容易理解。

在對業務例項研究進行描述之後，現在就可以開始維度建模的設計工作了。

設計工作的第一步使，通過將對業務需求的理解與對可用資料的理解組合起來而確定

建模的業務處理內容。

建立的第乙個維度模型應該是乙個最有影響的模型--它應該對最緊迫的業務問題做出回答，並且對資料的抽取來說使容易訪問的。

一旦將業務處理確定下來，資料倉儲團隊下乙個就面臨關於粒度確定的顏色課題。

應優先考慮為業務處理獲取最有原子性的資訊而開發維度模型。原子型資料是所收集的最詳細的資訊，這樣的資料不能再做更進一步的細分。

原子型資料是高度維結構化。事實度量值越細微並具有原子性，就越能夠確切地知道更多的事情，所有那些確切知道的事情都轉換為維度。在這點上，原子型資料可以說是維度方法的乙個極佳匹配。

原子型資料可為分析方面提供最大限度的靈活性，因為它可以接受任何可能形式的約束，並可以以任何可能的形式出現。

維度模型的細節性資料是安如泰山的，並隨時準備接受業務使用者的特殊攻擊。

可以總是結合業務處理定義較高層面的粒度，這種粒度表示最具有原子性的資料的聚集。

不過，只要選取較高層面的粒度就意味著將自己限制到更少或者細節性可能更小的維度上了。具有較少粒度性的模型容易直接遭到深入到細節內容的不可預見的使用者請求的攻擊。如果不讓使用者訪問原子型資料，則他將不可避免地在分析方面撞上南牆。

聚集概要性資料作為調整效能的一種手段起著非常重要的作用，但它絕對不能作為使用者訪問最底層面的細節內容的替代品。

資料倉儲幾乎總是要求在每個維度可能得到的最低粒度上對資料進行表示的原因，並不是因為查詢想看到每個底層面的行，而是因為查詢希望以很精確的方式對細節知識進行抽取。

一旦事實表的粒度被選定，則時期、產品與商店方面的維度就應該隨之被確定下來。

在基本維度框架範圍內，可能需要知道其他諸如針對某種產品的**這樣的維度是否可以分配資料。這個內容可表示為另外乙個設計原則。

乙個經過仔細考慮的粒度定義確定了事實表的基本維度特徵。同時，經常也可能向事實表的基本粒度加入更多的維度，而這些附加的維度會在基本維度的每個組合值方面自然地取得惟一的值。

如果附加的維度因為導致生產另外的事實行而違背了這個基本的粒度定義，那麼必須對粒度定義進行修改以適應這個維度的情形。

設計過程的第四步同時也是最後一步，在於仔細確定哪些事實要在事實表中出現。粒度定義在這裡再次成為考慮問題的支點。只是需要支出，事實對於粒度必須是真實的。

當考慮潛在的事實時，可能會再次發現，對早先的粒度設想或者維度選取做出調整是非常必要的。

單價也是非加型事實。試圖在任何維度範圍內對單價進行求和，都會導致出現一些毫無意義的甚至顯得荒謬的數值結果。

要針對一系列商店或者乙個時間跨度分析某種產品的平均售價，就必須在用銷售總量取除銷售總額之前，將相關銷售額與銷售量加起來。雖然資料倉儲市場方面的報表生成器或者查詢工具都應該自動地正確完成這個功能，但是很遺憾，其中一部分工具仍舊布恩那個很圓滿地做到這一點。

在設計的早期階段，經常對可能需要的最大錶即最大事實表的行數做出估計是很有益處的