業務過程室友組織完成的微觀活動。例如獲得訂單，開具發票，接受付款、註冊學生、處理索賠等。業務過程包含以下公共特徵，理解他們有助於區分組織中不同的業務過程；
您需要仔細了解業務以區分組織的業務過程，因為商業使用者難以快速回答下列問題他們對哪些業務過程感興趣，使用者希望在dw/bi系統中分析來自業務過程的效能度量。
有時業務使用者談論的是業務戰略規劃，而不是業務過程。這些往往是由管理層為提高競爭優勢而制定的抽象企業規劃。為將這些規聯絡到dw/bi小組利用的表示專案工作單元的業務過程中，需要將業務規劃分解到基本業務過程中。這意味著需要深入挖掘，理解資料和操作型系統，以支援對規劃進行分析的需求。
我們也需要了解業務過程不是什麼。企業業務部門或企業功能職責並不等於業務過程。將注意力放在業務過程，而不是放在功能化的部門，可以更方便地獲得一致得企業資訊。如果以部門為邊界建立維度模型，則不可避免地會將不同標號的資料及資料值重複使用。確保一致性的最好方法是一次性發布資料。
宣告粒度意味著精確定義某個事實表的每一行表示什麼。粒度傳遞的是與事實表度量有關的細節級別。它回答『如何描述事實表中每行內容？』這一問題。粒度由獲取業務過程事件的操作型系統的物理實現確定。
經典的粒度宣告如下：
上述宣告粒度試一業務術語表示的。也許您一直期望粒度是指對事實表主鍵的傳統宣告。雖然最終的粒度與主鍵是等價的，但將維度集合列出，然後假定這一集合就是粒度宣告的方法是不正確的。無論何時，都應該以業務術語來表示粒度的。
維度建模者有時會忽略宣告粒度這一在四步設計過程中從表面上看起來可有可無的額步驟。請不要這樣做。宣告粒度是不容忽略的關鍵步驟。多年來，從對大量維度設計除錯的情況來看，最常見的錯誤就是在設計過程之初，沒有為事實表宣告粒度。如果不能清楚地定義粒度，整個設計就像建立在流沙上，對候選維度的討論處於兜圈子的狀態，不適當的事實將隱藏在設計中。不適當的維度始終籠罩著dw/bi實現。設計組的每個人都要對事實表的粒度達到共識，這一點非常重要。討論到此，您可能會發現第三步或第四步設計過程中對粒度的說明是錯誤的。您必須返回第二步。重新正確地定義粒度，然後考慮第三步或第四步的問題。
維度要解決的問題事 」業務人員如何描述來自業務過程度量事件的資料？「 應當使用健壯的維度集合來裝飾事實表，這些維度表示承擔每個度量環境中的所有可能的單值描述符。如果粒度清楚，維度通常易於區分，因為他們表示的是」誰、什麼、何處、合適、為何、如何」關聯的時間。常見的維度例項包括日期、產品、客戶、雇員、裝置等。在選擇每個維度時，應該列出所有具體的、文字型別的屬性以充實每個維度表。
可以通過回答「過程的度量是什麼？"這一問題來確定事實。商業使用者非常願意分析這些效能度量。設計中的所有候選事實必須符合二第二步的粒度定義。明顯屬於不同粒度的事實必須放在不同的事實表中。典型事實是可加性數值，例如訂貨數量是以美元計的成本總額等。
需要綜合考慮也二五使用者需求和資料**的實際情況，並與四個步驟聯絡起來，強烈建議堅決抵制僅僅考慮資料**來建模資料。將注意力放在資料上可莪能不會像與商業使用者交流那樣複雜，淡資料不能替代業務使用者的輸入。遺憾的是，許多組織仍然在採用這種看似最省力的資料驅動的方法，當然這樣做基本不能取得成功。
維度模型資料倉儲（二） 維度模型基礎
一 維度模型基礎 既然維度模型是資料倉儲建設中的一種資料建模方法，那不妨先看一下幾種主流的資料倉儲架構。1.kimball的dw bi架構 圖 一 1 2.inmon企業資訊工廠架構 圖 一 2 3.混合型架構 圖 一 3 從圖中可以看出，每種架構中都有資料集市。資料集市就是面向終端使用者的資料庫。...
千億級數倉》資料倉儲維度模型設計
2 維度建模三種模式 資料倉儲分層架構 維度模型是資料倉儲領域大師ralph kimall所倡導，他的 資料倉儲工具箱 是資料倉儲工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的資料模型為分析需求服務，因此它重點解決使用者如何更快速完成分析需求，同時還有較好的大規模複雜查詢...
資料倉儲的模型設計
a.資料建模方 資料倉儲模型設計遵循 自頂向下 逐步求精 的設計原則。模型設計分為三個階段 1，概念模型 對業務的範圍和使用，從高度上進行抽象概括，也就是劃分主題域。一般劃分為8個主題域 客戶 服務 服務使用 賬務 結算 資源 客服 營銷 為什麼要劃分主題域？劃分主題域，是根據業務的應用和需要來劃分...