8000字，詳解資料建模的方法、模型、規範和工具！

作者：由九天發表于收藏時間：2022-03-26

由於在變化快速的商業世界裡，業務形態多種多樣，為了能夠更有針對性的進行資料建模，經過長時間的摸索，業界逐步形成了資料建模的四部曲：業務建模->領域建模->邏輯建模->物理建模。

簡單講，就是明確具體業務，抽象實體和關係，結合具體的建模方法，確定所有關鍵成分和屬性，最後建資料表進行資料的儲存和計算。

目前資料建模的方法論有兩大陣營，一個是基於關係型資料庫理論設計出來的，比如基於3NF的正規化建模。雖然目前也有不少非關係型資料庫以及不少半結構化和非結構化資料。但將半結構化/非結構化資料轉化為結構化資料，然後再利用關係型資料庫處理仍然是一種通用的主流資料處理方案。

另一個是基於資料倉庫之父Bill Inmon提出的維度建模理論，是從全企業的高度利用實體關係來對企業業務進行描述。

01 資料建模相關概念

資料幾乎總是用於兩種目的：操作型記錄的儲存和分析型決策的制定。簡單來說，

操作型系統儲存資料，分析型系統使用資料

。前者一般僅反映資料的最新狀態，按單條記錄事務性來處理；其最佳化的核心是更快地處理事務。後者往往是反映資料一段時間的狀態變化，按大批次方式處理資料；其核心是高效能、多維度處理資料。

通常我們將操作型系統簡稱為OLTP（On-Line Transaction Processing）— 聯機事務處理，將分析型系統簡稱為OLAP（On-Line Analytical Processing）— 聯機分析處理。

針對這兩種不同的資料用途，如何組織資料，更好地滿足資料使用需求。這裡就涉及到資料建模問題。即設計一種資料組織方式（模型），來滿足不同場景。在OLTP場景中，常用的是使用實體關係模型（ER）來儲存，從而在事務處理中解決資料的冗餘和一致性問題。

在OLAP場景中，有多種建模方式有：ER模型、星型模型和多維模型。下面分別說明下：

1、ER模型

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

2、星型模型

星型模型，是維度模型在關係型資料庫上的一種實現。該模型表示每個業務過程包含事實表，事實表儲存事件的數值化度量，圍繞事實表的多個維度表，維度表包含事件發生時實際存在的文字環境。

這種類似於星狀的結構通常稱為“星型連線”。其重點關注使用者如何更快速地完成需求分析，同時具有較好的大規模複雜查詢的響應效能。在星型模型基礎上，在複雜場景下還可以進一步衍生出雪花模型。

3、多維模型

多維模型，是維度模型的另一種實現。當資料被載入到OLAP多維資料庫時，對這些資料的儲存的索引，採用了為維度資料涉及的格式和技術。效能聚集或預計算彙總表通常由多維資料庫引擎建立並管理。由於採用預計算、索引策略和其他最佳化方法，多維資料庫可實現高效能查詢。

02 維度建模

維度建模，是資料倉庫大師Ralph Kimball提出的，是資料倉庫工程領域最流行的數倉建模經典。

維度建模以分析決策的需求出發構建模型，構建的資料模型為分析需求服務，因此它重點解決使用者如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應效能。

它是面向分析的，為了提高查詢效能可以增加資料冗餘，反規範化的設計技術。

1、事實表

事實表產生於業務過程，儲存了業務活動或事件提煉出來的效能度量。從最低的粒度級別來看，事實錶行對應一個度量事件。

事實表根據粒度的角色劃分不同，可分為事務事實表、週期快照事實表、累積快照事實表。

事務事實表

，用於承載事務資料，通常粒度比較低，它是面向事務的，其粒度是每一行對應一個事務，它是最細粒度的事實表，例如產品交易事務事實、ATM交易事務事實。

週期快照事實表

，按照一定的時間週期間隔（每天，每月）來捕捉業務活動的執行情況，一旦裝入事實表就不會再去更新，它是事務事實表的補充。用來記錄有規律的、固定時間間隔的業務累計資料，通常粒度比較高，例如賬戶月平均餘額事實表。

累積快照事實表

，用來記錄具有時間跨度的業務處理過程的整個過程的資訊，每個生命週期一行，通常這類事實表比較少見。

注意：

這裡需要值得注意的是，在事實表的設計時，一定要注意一個事實表只能有一個粒度，不能將不同粒度的事實建立在同一張事實表中。

2、維度表

維度表，一致性維度，業務過程的發生或分析角度，我們主要關注下退化維度和緩慢變化維。

退化維度

（DegenerateDimension）

在維度型別中，有一種重要的維度稱作為退化維度，亦維度退化一說。這種維度指的是直接把一些簡單的維度放在事實表中。退化維度是維度建模領域中的一個非常重要的概念，它對理解維度建模有著非常重要的作用，退化維度一般在分析中可以用來做分組使用。

緩慢變化維

（Slowly Changing Dimensions）

維度的屬性並不是始終不變的，它會隨著時間的流逝發生緩慢的變化，這種隨時間發生變化的維度我們一般稱之為緩慢變化維（SCD）。

SCD常用的三種處理方式：

①

TYPE1

直接覆蓋原值

②

TYPE2

增加維度行

在為維度成員增加新行時，需為其分配新的主代理鍵。並且，至少需要在維度行再增加三列：有效日期、截止日期、行標識。這個地方可聯想拉鍊表設計。

③

TYPE3

增加屬性列

④ 混合方式

可根據實際業務場景，混合或選擇使用以上三種方式，以快速方便而又準確的分析歷史變化情況。

3、粒度

用於確定某一事實表中的行表示什麼，是業務最小活動單元或不同維度組合，即業務細節程度。

4、維度建模流程

維度建模步驟：選擇業務過程->宣告粒度->確定維度->確定事實。旨在重點解決資料粒度、維度設計和事實表設計問題。

宣告粒度，為業務最小活動單元或不同維度組合。以共同粒度從多個組織業務過程合併度量的事實表稱為合併事實表，需要注意的是，來自多個業務過程的事實合併到合併事實表時，它們必須具有同樣等級的粒度。

由於在維度建模過程中，涉及到很多概念。下面透過一個場景來，來一一說明。例如：常見的電商下單環節，每個使用者提交一筆訂單（僅限一個物品），就對應於一條訂單記錄。

【業務過程】：下訂單

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

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

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

維度建模的步驟如下：

（1）收集業務需求與資料實現

在開始維度建模工作之前，需要理解業務需求，以及作為底層源資料的實際情況。透過與業務方溝通交流、檢視現有報表等來發現需求，用於理解他們的基於關鍵效能指標、競爭性商業問題、決策制定過程、支援分析需求的目標。同時，資料實際情況可透過與資料庫系統專家交流，瞭解訪問資料可行性等。

（2）選擇業務過程

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

（4）宣告粒度

宣告粒度是維度設計的重要步驟。粒度用於確定某一事實表中的行表示什麼。在選擇維度或事實前必須宣告粒度，因為每個候選維度或事實必須與定義的粒度保持一致。在從給定的業務過程獲取資料時，原子粒度是最低級別的粒度。強烈建議從關注原子級別粒度資料開始設計，因為原子粒度資料能夠承受無法預期的使用者查詢。

（5）確認維度（描述環境）

維度提供圍繞某一業務過程事件所涉及的“誰、什麼、何處、何時、為什麼、如何”等背景。維度表包含分析應用所需要的用於過濾及分類事實的描述性屬性。牢牢掌握事實表的粒度，就能夠將所有可能存在的維度區分開來。

（6）確認事實（用於度量）

事實，涉及來自業務過程事件的度量，基本上都是以資料值表示。一個事實錶行與按照事實表粒度描述的度量事件之間存在一對一關係，因此事實表對應一個物理可觀察的事件。在事實表內，所有事實只允許與宣告的粒度保持一致。

（7）部署方式 - 星型模型或多維模型

選擇一種維度模型的落地方式。既可以選擇星型模型，部署在關係資料庫上，透過事實表及透過主外來鍵關聯的維度表；也可以選擇多維模型，落地於多維資料庫中。

03 維度建模方法論

資料倉庫建模方法論可分為：維度建模、正規化建模、Data Vault模型、Anchor模型。

1、維度模型

企業中最流行、也是最經典的數倉建模經典，資料倉庫大師Ralph Kimball的經典著作《資料倉庫工具箱維度建模權威指南第三版》一本書進行了論述。從事資料倉庫/ETL/BI的同學，強烈建議買一本至少讀一遍。

按資料組織型別劃分可分為星型模型、雪花模型、星座模型。

（1）

星型模型

星型模型主要是維表和事實表，以事實表為中心，所有維度直接關聯在事實表上，呈星型分佈。

圖來源於Kimball《The Data Warehouse Toolkits -3rd Edition》

（2）

雪花模型

雪花模型，在星型模型的基礎上，維度表上又關聯了其他維度表。這種模型維護成本高，效能方面也較差，所以一般不建議使用。尤其是基於hadoop體系構建數倉，減少join就是減少shuffle，效能差距會很大。

（3）

星座模型

星座模型，是對星型模型的擴充套件延伸，多張事實表共享維度表。數倉模型建設後期，大部分維度建模都是星座模型。

2、正規化模型

即實體關係（ER）模型，資料倉庫之父Immon提出的，從全企業的高度設計一個3NF模型，用實體加關係描述的資料模型描述企業業務架構，在正規化理論上符合3NF。此建模方法，對建模人員的能力要求非常高。

3、Data Vault模型

DataVault由Hub（關鍵核心業務實體）、Link（關係）、Satellite（實體屬性）三部分組成，是Dan Linstedt發起建立的一種模型方法論，它是在ER關係模型上的衍生，同時設計的出發點也是為了實現資料的整合，並非為資料決策分析直接使用。

4、Anchor模型

高度可擴充套件的模型，所有的擴充套件只是新增而不是修改，因此它將模型規範到6NF，基本變成了K-V結構模型。一般很少使用，本文不多做介紹。

04 建模規範

以維度建模為理論基礎，定義一系列術語來描述建模物件。下圖摘自於《阿里巴巴大資料實踐之路》。

資料域

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

業務過程

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

時間週期

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

修飾型別

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

修飾詞

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

度量/原子指標

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

維度

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

維度屬性

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

派生指標

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

資料層次的劃分：

ODS：Operational Data Store，操作資料層，在結構上其與源系統的增量或者全量資料基本保持一致。

它相當於一個數據準備區，同時又承擔著基礎資料的記錄以及歷史變化。其主要作用是把基礎資料引入到MaxCompute。

CDM：Common Data Model，公共維度模型層，又細分為DWD和DWS。它的主要作用是完成資料加工與整合、建立一致性的維度、構建可複用的面向分析和統計的明細事實表以及彙總公共粒度的指標。

DWD：Data Warehouse Detail，明細資料層。

DWS：Data Warehouse Summary，彙總資料層。

ADS：Application Data Service，應用資料層。

具體倉庫的分層情況需要結合業務場景、資料場景、系統場景進行綜合考慮。

資料分類架構

該資料分類架構在ODS層分為三部分：資料準備區、離線資料和準實時資料區。在進入到CDM層後，由以下幾部分組成：

公共維度層：

基於維度建模理念思想，建立整個企業的一致性維度。

明細粒度事實層：

以業務過程為建模驅動，基於每個具體業務過程的特點，構建最細粒度的明細層事實表。

可以結合企業的資料使用特點，將明細事實表的某些重要維度屬性欄位做適當的冗餘，即寬表化處理。

公共彙總粒度事實層：

以分析的主題物件為建模驅動，基於上層的應用和產品的指標需求，構建公共粒度的彙總指標事實表，以寬表化手段來物理化模型。

資料處理流程架構

資料劃分及名稱空間約定

請根據業務劃分資料並約定命名，建議針對業務名稱結合資料層次約定相關命名的英文縮寫，這樣可以給後續資料開發過程中，對專案空間、表、欄位等命名做為重要參照。

按業務劃分：

命名時按主要的業務劃分，以指導物理模型的劃分原則、命名原則及使用的ODS project。

例如，按業務定義英文縮寫，阿里的“淘寶”英文縮寫可以定義為“tb”。

按資料域劃分：

命名時按照CDM層的資料進行資料域劃分，以便有效地對資料進行管理，以及指導資料表的命名。

例如，“交易”資料的英文縮寫可定義為“trd”。

按業務過程劃分：

當一個數據域由多個業務過程組成時，命名時可以按業務流程劃分。

業務過程是從資料分析角度看客觀存在的或者抽象的業務行為動作。

例如，交易資料域中的“退款”這個業務過程的英文縮寫可約定命名為“rfd_ent”。

資料模型

模型是對現實事物的反映和抽象，能幫助我們更好地瞭解客觀世界。資料模型定義了資料之間關係和結構，使得我們可以有規律地獲取想要的資料。例如，在一個超市裡，商品的佈局都有特定的規範，商品擺放的位置是按照消費者的購買習慣以及人流走向進行擺放的。

資料模型的作用

資料模型是在業務需求分析之後，資料倉庫工作開始時的第一步。良好的資料模型可以幫助我們更好地儲存資料，更有效率地獲取資料，保證資料間的一致性。

模型設計的基本原則

（1）高內聚和低耦合

一個邏輯和物理模型由哪些記錄和欄位組成，應該遵循最基本的軟體設計方法論中的高內聚和低耦合原則。主要從資料業務特性和訪問特性兩個角度來考慮：將業務相近或者相關的資料、粒度相同資料設計為一個邏輯或者物理模型；將高概率同時訪問的資料放一起，將低概率同時訪問的資料分開儲存。

（2）核心模型與擴充套件模型分離

建立核心模型與擴充套件模型體系，核心模型包括的欄位支援常用核心的業務，擴充套件模型包括的欄位支援個性化或是少量應用的需要。在必須讓核心模型與擴充套件模型做關聯時，不能讓擴充套件欄位過度侵入核心模型，以免破壞了核心模型的架構簡潔性與可維護性。

（3）公共處理邏輯下沉及單一

底層公用的處理邏輯應該在資料排程依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用層實現，不要讓公共邏輯在多處同時存在。

（4）成本與效能平衡

適當的資料冗餘可換取查詢和重新整理效能，不宜過度冗餘與資料複製。

（5）資料可回滾

處理邏輯不變，在不同時間多次執行資料的結果需確定不變。

（6）一致性

相同的欄位在不同表中的欄位名必須相同。

（7）命名清晰可理解

表命名規範需清晰、一致，表命名需易於下游的理解和使用。

（8）補充說明

一個模型無法滿足所有的需求。

需合理選擇資料模型的建模方式。

通常，設計順序依次為：概念模型->邏輯模型->物理模型。

維度表設計要點：

維度是維度建模的基礎和靈魂。在維度建模中，將度量稱為“事實”，將環境描述為“維度”，維度是用於分析事實所需要的多樣環境。維度所包含的表示維度的列，稱為維度屬性。維度屬性是查詢約束條件、分組和報表標籤生成的基本來源，是資料易用性的關鍵。

維度的作用一般是查詢約束、分類彙總以及排序等。維度的設計過程就是確定維度屬性的過程，如何生成維度屬性，以及所生成的維度屬性的優劣，決定了維度使用的方便性，成為資料倉庫易用性的關鍵。正如Kimball所說的，資料倉庫的能力直接與維度屬性的質量和深度成正比。

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

維度屬性儘量豐富，為資料使用打下基礎。

給出詳實的、富有意義的文字描述。

沉澱通用維度屬性，為建立一致性維度做好鋪墊。

嚴格區分事實與維度，透過使用場景進行區分。

事實表設計要點：

事實表作為資料倉庫維度建模的核心，緊緊圍繞著業務過程來設計，透過獲取描述業務過程的度量來表達業務過程，包含了引用的維度和與業務過程有關的度量。在設計過程中，可以選擇不同型別的事實表，它們有各自的適用場景。

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

選擇一種適合的事實表型別。

事實儘可能完整，包含整個業務過程的全部事實。

確保每一個事實度量都是一致性，反覆計算都會得到相同的結果。儘量記錄一些“原子”事實，而不是加工後的結果。

可適當做些”維度退化屬性”，提高事實表的查詢效能。

為提高聚合效能，可適度做些上卷匯聚事實表。

05 建模工具

1、PowerDesigner

PowerDesigner是目前資料建模業界的領頭羊。功能包括：完整的整合模型，和麵向包含IT為中心的、非IT為中心的差異化建模訴求。

支援非常強大的元資料資訊庫和各種不同格式的輸出。PowerDesigner擁有一個優雅且人性化的介面，非常易懂的幫助文件，快速幫助使用者解決專業問題。

2、ER/Studio

ER/Studio 是一個支援多平臺環境的直觀資料建模工具，並且本地集成了用於處理大資料平臺，例如-MongoDB和Hadoop Hive。

它能夠進行正向和逆向工程，並且擁有“比較合併”功能，能夠輸出例如XML、PNG、JPEG等格式文件。內建自動執行任務功能支援當前流行資料庫平臺。ER/Studio功能非常強大，擁有直觀的介面和很好的使用者支援特別易於馬上開始工作。

3、Sparx Enterprise Architect

Enterprise Architect是一個擁有豐富功能的資料建模工具。自詡是高性價比的明智之選。Enterprise Architect幫助企業使用者快速建立強大的可維護的系統，而且很容易在共享專案中擴充套件到大型的協作團隊中去。

Enterprise Architect 同樣有動態執行模擬模型的能力，用以驗證模型和更加正確和深入的理解原來商業系統運作的方式。

4、CA ERwin

ERwin 也是業界領先的資料建模解決方案，能夠為使用者提供一個簡單而優雅的介面同時處理複雜的資料環境問題。Erwin的解決方案提提供敏捷模型，同時元資料可以放在普通的資料庫中進行處理，這樣就能夠保證資料的一致性和安全性。Erwin支援高度自定義的資料型別、APIs，允許自動執行宏語言等等。Erwin還建有一個很活躍的使用者討論社群，使得使用者之間可以分享知識和各種經驗。