程序員筆記|3個問題帶你入門數據建模

做者介紹：韓鋒：宜信數據庫開發與管理主任工程師
ACMUG主席團成員，CCIA（中國計算機行業協會）常務理事，Oracle ACE，DBAplus聯合創始人，ODF 顧問團成員，ACOUG,ACMUG,DBGeek撰稿人，著有《SQL優化最佳實踐》一書。早年從事軟件開發工做，後因我的興趣轉入數據庫領域。有着多年的一線數據庫架構、設計、開發經驗，曾擔任多家公司首席DBA、數據庫架構師等職。

【技術沙龍002期】數據中臺：宜信敏捷數據中臺建設實踐|宜信技術沙龍 將於5月23日晚8點線上直播，點擊報名

1、何爲建模？

數據幾乎老是用於兩種目的：操做型記錄的保存和分析型決策的制定。簡單來講，操做型系統保存數據，分型型系統使用數據。

• 前者通常僅反映數據的最新狀態，按單條記錄事務性來處理；其優化的核心是更快地處理事務。
• 後者每每是反映數據一段時間的狀態變化，按大批量方式處理數據；其核心是高性能、多維度處理數據。

一般咱們將操做型系統簡稱爲OLTP（On-Line Transaction Processing）— 聯機事務處理，將分析型系統簡稱爲OLAP（On-Line Analytical Processing）— 聯機分析處理。

針對這兩種不一樣的數據用途，如何組織數據，更好地知足數據使用需求。這裏就涉及到數據建模問題。即設計一種數據組織方式（模型），來知足不一樣場景。在OLTP場景中，經常使用的是使用實體關係模型（ER）來存儲，從而在事務處理中解決數據的冗餘和一致性問題。在OLAP場景中，有多種建模方式有：ER模型、星型模型和多維模型。下面分別說明下：

ER模型

OLAP中的ER模型，與OLTP中的有所區別。其本質差別是站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體對象關係的抽象。

星型模型

星型模型，是維度模型在關係型數據庫上的一種實現。該模型表示每一個業務過程包含事實表，事實表存儲事件的數值化度量，圍繞事實表的多個維度表，維度表包含事件發生時實際存在的文本環境。這種相似於星狀的結構一般稱爲"星型鏈接"。其重點關注用戶如何更快速地完成需求分析，同時具備較好的大規模複雜查詢的響應性能。在星型模型基礎上，在複雜場景下還能夠進一步衍生出雪花模型。

多維模型

多維模型，是維度模型的另外一種實現。當數據被加載到OLAP多維數據庫時，對這些數據的存儲的索引，採用了爲維度數據涉及的格式和技術。性能彙集或預計算彙總表一般由多維數據庫引擎創建並管理。因爲採用預計算、索引策略和其餘優化方法，多維數據庫可實現高性能查詢。

在這三種方式中，星型模型使用較多，下面也着重對這種方式進行說明。

2、維度建模

一、基本概念

在建模過程當中，涉及到不少概念。下面經過一個場景來，來講明它們。例如：常見的電商下單環節，每一個用戶提交一筆訂單（僅限一個物品），就對應於一條訂單記錄。

【業務過程】：下訂單

【粒度】：每筆訂單（拆分爲單個物品）

【維度】：地域、年齡、渠道等（可供分析的角度）

【事實/度量】：訂單金額等（可用於分析的數據）

二、建模步驟

收集業務需求與數據實現

在開始維度建模工做以前，須要理解業務需求，以及做爲底層源數據的實際狀況。經過與業務方溝通交流、查看現有報表等來發現需求，用於理解他們的基於關鍵性能指標、競爭性商業問題、決策制定過程、支持分析需求的目標。同時，數據實際狀況可經過與數據庫系統專家交流，瞭解訪問數據可行性等。

選擇業務過程

業務過程是組織完成的操做型活動。業務過程時間創建或獲取性能度量，並轉換爲事實表中的事實。多數事實表關注某一業務過程的結果。過程的選擇很是重要的，由於過程定義了特定的設計目標以及對粒度、維度、事實的定義。

聲明粒度

聲明粒度是維度設計的重要步驟。粒度用於肯定某一事實表中的行表示什麼。在選擇維度或事實前必須聲明粒度，由於每一個候選維度或事實必須與定義的粒度保持一致。在從給定的業務過程獲取數據時，原子粒度是最低級別的粒度。強烈建議從關注原子級別粒度數據開始設計，由於原子粒度數據可以承受沒法預期的用戶查詢。

確認維度（描述環境)

維度提供圍繞某一業務過程事件所涉及的"誰、什麼、何處、什麼時候、爲何、如何"等背景。維度表包含分析應用所須要的用於過濾及分類事實的描述性屬性。緊緊掌握事實表的粒度，就可以將全部可能存在的維度區分開來。

確認事實（用於度量）

事實，涉及來自業務過程事件的度量，基本上都是以數據值表示。一個事實錶行與按照事實表粒度描述的度量事件之間存在一對一關係，所以事實表對應一個物理可觀察的事件。在事實表內，全部事實只容許與聲明的粒度保持一致。

部署方式 - 星型模型或多維模型

選擇一種維度模型的落地方式。既能夠選擇星型模型，部署在關係數據庫上，經過事實表及經過主外鍵關聯的維度表；也能夠選擇多維模型，落地於多維數據庫中。

三、建模規範

以維度建模爲理論基礎，定義一系列術語來描述建模對象。下圖摘自於《阿里巴巴大數據實踐之路》。

數據域

指面向業務分析，將業務過程或者維度進行抽象的集合。在劃分數據域時，既能涵蓋當前全部的業務需求，又能在新業務進入時無影響地被包含進已有的數據域中和擴展新的數據域。

業務過程

指企業的業務活動事件，以下單、支付、退款都是業務過程。請注意，業務過程是一個不可拆分的行爲事件，通俗地講，業務過程就是企業活動中的事件。

時間週期

用來明確數據統計的時間範圍或者時間點，如最近30天、天然周、截至當日等。

修飾類型

是對修飾詞的一種抽象劃分，是從屬於某個業務域的。

修飾詞

指除了統計維度之外指標的業務場景限定抽象。修飾詞隸屬於一種修飾類型。

度量/原子指標

原子指標和度量含義相同，基於某一業務事件行爲下的度量，是業務定義中不可再拆分的指標，具備明確業務含義的名詞，如支付金額。

維度

維度是度量的環境，用來反映業務的一類屬性，這類屬性的集合構成一個維度，也能夠稱爲實體對象。維度屬於一個數據域，如地理維度（其中包擠國家、地區、省以及城市等級別的內容）、時間維度（其中包括年、季、月、周、日等級別的內容）。

維度屬性

維度屬性隸屬於一個維度，如地理維度裏面的國家名稱、國家ID、省份名稱等都屬於維度屬性。

派生指標

派生指標＝一個原子指標＋多個修飾詞（可選）＋時間週期。能夠理解爲對原子指標業務統計範圍的圈定。

3、設計要點

一、維度表設計

維度是維度建模的基礎和靈魂。在維度建模中，將度量稱爲"事實"，將環境描述爲"維度"，維度是用於分析事實所須要的多樣環境。維度所包含的表示維度的列，稱爲維度屬性。維度屬性是查詢約束條件、分組和報表標籤生成的基原本源，是數據易用性的關鍵。維度的做用通常是查詢約束、分類彙總以及排序等。維度的設計過程就是肯定維度屬性的過程，如何生成維度屬性，以及所生成的維度屬性的優劣，決定了維度使用的方便性，成爲數據倉庫易用性的關鍵。正如Kimball所說的，數據倉庫的能力直接與維度屬性的質量和深度成正比。

在整個設計過程當中，應當遵循下面一些原則：

• 維度屬性儘可能豐富，爲數據使用打下基礎。
• 給出詳實的、富有意義的文字描述。
• 沉澱通用維度屬性，爲創建一致性維度作好鋪墊。
• 嚴格區分事實與維度，經過使用場景進行區分。

二、事實表設計

事實表做爲數據倉庫維度建模的核心，牢牢圍繞着業務過程來設計，經過獲取描述業務過程的度量來表達業務過程，包含了引用的維度和與業務過程有關的度量。在設計過程當中，能夠選擇不一樣類型的事實表，它們有各自的適用場景。

在整個設計過程當中，應當遵循下面一些原則：

• 選擇一種適合的事實表類型。
• 事實儘量完整，包含整個業務過程的所有事實。
• 確保每個事實度量都是一致性，反覆計算都會獲得相同的結果。儘可能記錄一些「原子」事實，而不是加工後的結果。
• 可適當作些」維度退化屬性」，提升事實表的查詢性能。
• 爲提升聚合性能，可適度作些上卷匯聚事實表。

來源：公衆號-韓鋒頻道，歡迎關注。

宜信技術學院