一、何爲建模
數據幾乎總是用於兩種目的：操作型記錄的保存和分析型決策的制定。簡單來說，操作型系統保存數據，分型型系統使用數據。
-
前者一般僅反映數據的最新狀態，按單條記錄事務性來處理；其優化的核心是更快地處理事務。
-
後者往往是反映數據一段時間的狀態變化，按大批量方式處理數據；其核心是高性能、多維度處理數據。
通常我們將操作型系統簡稱爲OLTP（On-Line Transaction Processing）— 聯機事務處理，將分析型系統簡稱爲OLAP（On-Line Analytical Processing）— 聯機分析處理。
針對這兩種不同的數據用途，如何組織數據，更好地滿足數據使用需求。這裏就涉及到數據建模問題。即設計一種數據組織方式（模型），來滿足不同場景。在OLTP場景中，常用的是使用實體關係模型（ER）來存儲，從而在事務處理中解決數據的冗餘和一致性問題。在OLAP場景中，有多種建模方式有：ER模型、星型模型和多維模型。下面分別說明下：
ER模型
OLAP中的ER模型，與OLTP中的有所區別。其本質差異是站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體對象關係的抽象。
星型模型
星型模型，是維度模型在關係型數據庫上的一種實現。該模型表示每個業務過程包含事實表，事實表存儲事件的數值化度量，圍繞事實表的多個維度表，維度表包含事件發生時實際存在的文本環境。這種類似於星狀的結構通常稱爲"星型連接"。其重點關注用戶如何更快速地完成需求分析，同時具有較好的大規模複雜查詢的響應性能。在星型模型基礎上，在複雜場景下還可以進一步衍生出雪花模型。
多維模型
多維模型，是維度模型的另一種實現。當數據被加載到OLAP多維數據庫時，對這些數據的存儲的索引，採用了爲維度數據涉及的格式和技術。性能聚集或預計算彙總表通常由多維數據庫引擎建立並管理。由於採用預計算、索引策略和其他優化方法，多維數據庫可實現高性能查詢。
在這三種方式中，星型模型使用較多，下面也着重對這種方式進行說明。
二、維度建模
1、基本概念
在建模過程中，涉及到很多概念。下面通過一個場景來，來說明它們。例如：常見的電商下單環節，每個用戶提交一筆訂單（僅限一個物品），就對應於一條訂單記錄。
【業務過程】：下訂單
【粒度】：每筆訂單（拆分爲單個物品）
【維度】：地域、年齡、渠道等（可供分析的角度）
【事實/度量】：訂單金額等（可用於分析的數據）
2、建模步驟
收集業務需求與數據實現
在開始維度建模工作之前，需要理解業務需求，以及作爲底層源數據的實際情況。通過與業務方溝通交流、查看現有報表等來發現需求，用於理解他們的基於關鍵性能指標、競爭性商業問題、決策制定過程、支持分析需求的目標。同時，數據實際情況可通過與數據庫系統專家交流，瞭解訪問數據可行性等。
選擇業務過程
業務過程是組織完成的操作型活動。業務過程時間建立或獲取性能度量，並轉換爲事實表中的事實。多數事實表關注某一業務過程的結果。過程的選擇非常重要的，因爲過程定義了特定的設計目標以及對粒度、維度、事實的定義。
聲明粒度
聲明粒度是維度設計的重要步驟。粒度用於確定某一事實表中的行表示什麼。在選擇維度或事實前必須聲明粒度，因爲每個候選維度或事實必須與定義的粒度保持一致。在從給定的業務過程獲取數據時，原子粒度是最低級別的粒度。強烈建議從關注原子級別粒度數據開始設計，因爲原子粒度數據能夠承受無法預期的用戶查詢。
確認維度（描述環境)
維度提供圍繞某一業務過程事件所涉及的"誰、什麼、何處、何時、爲什麼、如何"等背景。維度表包含分析應用所需要的用於過濾及分類事實的描述性屬性。牢牢掌握事實表的粒度，就能夠將所有可能存在的維度區分開來。
確認事實（用於度量）
事實，涉及來自業務過程事件的度量，基本上都是以數據值表示。一個事實錶行與按照事實表粒度描述的度量事件之間存在一對一關係，因此事實表對應一個物理可觀察的事件。在事實表內，所有事實只允許與聲明的粒度保持一致。
部署方式 - 星型模型或多維模型
選擇一種維度模型的落地方式。既可以選擇星型模型，部署在關係數據庫上，通過事實表及通過主外鍵關聯的維度表；也可以選擇多維模型，落地於多維數據庫中。
3、建模規範
以維度建模爲理論基礎，定義一系列術語來描述建模對象。下圖摘自於《阿里巴巴大數據實踐之路》。
數據域
指面向業務分析，將業務過程或者維度進行抽象的集合。在劃分數據域時，既能涵蓋當前所有的業務需求，又能在新業務進入時無影響地被包含進已有的數據域中和擴展新的數據域。
業務過程
指企業的業務活動事件，如下單、支付、退款都是業務過程。請注意，業務過程是一個不可拆分的行爲事件，通俗地講，業務過程就是企業活動中的事件。
時間週期
用來明確數據統計的時間範圍或者時間點，如最近30天、自然周、截至當日等。
修飾類型
是對修飾詞的一種抽象劃分，是從屬於某個業務域的。
修飾詞
指除了統計維度以外指標的業務場景限定抽象。修飾詞隸屬於一種修飾類型。
度量/原子指標
原子指標和度量含義相同，基於某一業務事件行爲下的度量，是業務定義中不可再拆分的指標，具有明確業務含義的名詞，如支付金額。
維度
維度是度量的環境，用來反映業務的一類屬性，這類屬性的集合構成一個維度，也可以稱爲實體對象。維度屬於一個數據域，如地理維度（其中包擠國家、地區、省以及城市等級別的內容）、時間維度（其中包括年、季、月、周、日等級別的內容）。
維度屬性
維度屬性隸屬於一個維度，如地理維度裏面的國家名稱、國家ID、省份名稱等都屬於維度屬性。
派生指標
派生指標＝一個原子指標＋多個修飾詞（可選）＋時間週期。可以理解爲對原子指標業務統計範圍的圈定。
三、設計要點
1、維度表設計
維度是維度建模的基礎和靈魂。在維度建模中，將度量稱爲"事實"，將環境描述爲"維度"，維度是用於分析事實所需要的多樣環境。維度所包含的表示維度的列，稱爲維度屬性。維度屬性是查詢約束條件、分組和報表標籤生成的基本來源，是數據易用性的關鍵。維度的作用一般是查詢約束、分類彙總以及排序等。維度的設計過程就是確定維度屬性的過程，如何生成維度屬性，以及所生成的維度屬性的優劣，決定了維度使用的方便性，成爲數據倉庫易用性的關鍵。正如Kimball所說的，數據倉庫的能力直接與維度屬性的質量和深度成正比。
在整個設計過程中，應當遵循下面一些原則：
-
維度屬性儘量豐富，爲數據使用打下基礎。
-
給出詳實的、富有意義的文字描述。
-
沉澱通用維度屬性，爲建立一致性維度做好鋪墊。
-
嚴格區分事實與維度，通過使用場景進行區分。
2、事實表設計
事實表作爲數據倉庫維度建模的核心，緊緊圍繞着業務過程來設計，通過獲取描述業務過程的度量來表達業務過程，包含了引用的維度和與業務過程有關的度量。在設計過程中，可以選擇不同類型的事實表，它們有各自的適用場景。
在整個設計過程中，應當遵循下面一些原則：
-
選擇一種適合的事實表類型。
-
事實儘可能完整，包含整個業務過程的全部事實。
-
確保每一個事實度量都是一致性，反覆計算都會得到相同的結果。儘量記錄一些“原子”事實，而不是加工後的結果。
-
可適當做些”維度退化屬性”，提高事實表的查詢性能。
-
爲提高聚合性能，可適度做些上卷匯聚事實表。
