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

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

交通大數據平臺概述（滿分PPT）

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

12張架構圖讀懂企業數據中臺

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

數據幾乎總是用于兩種目的：操作型記錄的保存和分析型決策的制定。簡單來說，操作型系統保存數據，分析型系統使用數據。前者一般僅反映數據的最新狀態，按單條記錄事務性來處理；其優化的核心是更快地處理事務。后者往往是反映數據一段時間的狀態變化，按大批量方式處理數據；其核心是高性能、多維度處理數據。

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

華為數據治理之旅（100分PPT）

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

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

1、ER模型

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

2、星型模型星型模型，是維度模型在關系型數據庫上的一種實現。該模型表示每個業務過程包含事實表，事實表存儲事件的數值化度量，圍繞事實表的多個維度表，維度表包含事件發生時實際存在的文本環境。這種類似于星狀的結構通常稱為"星型連接"。其重點關注用戶如何更快速地完成需求分析，同時具有較好的大規模復雜查詢的響應性能。在星型模型基礎上，在復雜場景下還可以進一步衍生出雪花模型。3、多維模型多維模型，是維度模型的另一種實現。當數據被加載到OLAP多維數據庫時，對這些數據的存儲的索引，采用了為維度數據涉及的格式和技術。性能聚集或預計算匯總表通常由多維數據庫引擎建立并管理。由于采用預計算、索引策略和其他優化方法，多維數據庫可實現高性能查詢。

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

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

它是面向分析的，為了提高查詢性能可以增加數據冗余，反規范化的設計技術。

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

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

事務事實表，用于承載事務數據，通常粒度比較低，它是面向事務的，其粒度是每一行對應一個事務，它是最細粒度的事實表，例如產品交易事務事實、ATM交易事務事實。 周期快照事實表，按照一定的時間周期間隔(每天，每月)來捕捉業務活動的執行情況，一旦裝入事實表就不會再去更新，它是事務事實表的補充。用來記錄有規律的、固定時間間隔的業務累計數據，通常粒度比較高，例如賬戶月平均余額事實表。

累積快照事實表，用來記錄具有時間跨度的業務處理過程的整個過程的信息，每個生命周期一行，通常這類事實表比較少見。

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

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

退化維度（DegenerateDimension） 在維度類型中，有一種重要的維度稱作為退化維度，亦維度退化一說。這種維度指的是直接把一些簡單的維度放在事實表中。退化維度是維度建模領域中的一個非常重要的概念，它對理解維度建模有著非常重要的作用，退化維度一般在分析中可以用來做分組使用。 緩慢變化維（Slowly Changing Dimensions） 維度的屬性并不是始終不變的，它會隨著時間的流逝發生緩慢的變化，這種隨時間發生變化的維度我們一般稱之為緩慢變化維（SCD）。 SCD常用的三種處理方式：

TYPE1 直接覆蓋原值

TYPE2 增加維度行

TYPE3 增加屬性列

混合方式

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

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

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

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

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

【業務過程】：下訂單【粒度】：每筆訂單（拆分為單個物品）【維度】：地域、年齡、渠道等（可供分析的角度）【事實/度量】：訂單金額等（可用于分析的數據）

維度建模的步驟如下：

（1）收集業務需求與數據實現

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

（2）選擇業務過程

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

（3）聲明粒度

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

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

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

（5）確認事實（用于度量）

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

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

選擇一種維度模型的落地方式。既可以選擇星型模型，部署在關系數據庫上，通過事實表及通過主外鍵關聯的維度表；也可以選擇多維模型，落地于多維數據庫中。

數據倉庫建模方法論可分為：維度建模、范式建模、Data Vault模型、Anchor模型。

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

按數據組織類型劃分可分為星型模型、雪花模型、星座模型。

（1）星型模型

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

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

（2）雪花模型

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

（3）星座模型

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

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

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

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

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

數據域

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

業務過程

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

時間周期

用來明確數據統計的時間范圍或者時間點，如最近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”。

數據模型

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

數據模型的作用

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

模型設計的基本原則

高內聚和低耦合 一個邏輯和物理模型由哪些記錄和字段組成，應該遵循最基本的軟件設計方法論中的高內聚和低耦合原則。主要從數據業務特性和訪問特性兩個角度來考慮：將業務相近或者相關的數據、粒度相同數據設計為一個邏輯或者物理模型；將高概率同時訪問的數據放一起，將低概率同時訪問的數據分開存儲。 核心模型與擴展模型分離 建立核心模型與擴展模型體系，核心模型包括的字段支持常用核心的業務，擴展模型包括的字段支持個性化或是少量應用的需要。在必須讓核心模型與擴展模型做關聯時，不能讓擴展字段過度侵入核心模型，以免破壞了核心模型的架構簡潔性與可維護性。 公共處理邏輯下沉及單一 底層公用的處理邏輯應該在數據調度依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用層實現，不要讓公共邏輯在多處同時存在。 成本與性能平衡 適當的數據冗余可換取查詢和刷新性能，不宜過度冗余與數據復制。 數據可回滾 處理邏輯不變，在不同時間多次運行數據的結果需確定不變。 一致性 相同的字段在不同表中的字段名必須相同。 命名清晰可理解 表命名規范需清晰、一致，表命名需易于下游的理解和使用。 補充說明

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

需合理選擇數據模型的建模方式。

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

維度表設計要點：

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

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

在整個設計過程中，應當遵循下面一些原則： 維度屬性盡量豐富，為數據使用打下基礎。 給出詳實的、富有意義的文字描述。 沉淀通用維度屬性，為建立一致性維度做好鋪墊。

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

事實表設計要點：

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

在整個設計過程中，應當遵循下面一些原則： 選擇一種適合的事實表類型。 事實盡可能完整，包含整個業務過程的全部事實。 確保每一個事實度量都是一致性，反復計算都會得到相同的結果。盡量記錄一些“原子”事實，而不是加工后的結果。 可適當做些”維度退化屬性”，提高事實表的查詢性能。

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

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

支持非常強大的元數據信息庫和各種不同格式的輸出。PowerDesigner擁有一個優雅且人性化的界面，非常易懂的幫助文檔，快速幫助用戶解決專業問題。

ER/Studio 是一個支持多平臺環境的直觀數據建模工具，并且本地集成了用于處理大數據平臺，例如-MongoDB和Hadoop Hive。

它能夠進行正向和逆向工程，并且擁有“比較合并”功能，能夠輸出例如XML、PNG、JPEG等格式文檔。內建自動執行任務功能支持當前流行數據庫平臺。ER/Studio功能非常強大，擁有直觀的界面和很好的用戶支持特別易于馬上開始工作。

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

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

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

InfoSphere 是一個很創新的、運行在開源平臺-Eclipse上的數據建模工具。Infopshere主要聚焦于一下三個主要的特性：高效、簡潔、高度集成。

InfoSphere能夠幫助商業用戶建立邏輯、物理模型圖，并且之后能非常方便的在各種不同的應用和系統中進行使用。InfoSphere是一個端到端的解決方案，可以快速高效地用在建立、部署、更新數據模型。同時為非常簡易的集成了IBM的其他相關產品。

Visio 是Office 軟件系列中的負責繪制流程圖和示意圖的軟件，是一款便于IT和商務人員就復雜信息、系統和流程進行可視化處理、分析和交流的軟件。同時它也可以用來數據庫建模。

打開visio 2010,文件—>新建—>數據庫—>數據庫模型圖。建立數據庫模型圖之后，菜單欄多出一個菜單項"數據庫"。

通過我們最熟悉的Excel進行維護數據模型、血緣關系和元數據管理，話不多說，直接上圖：

上述的這些方法都有自己的優點和局限性，實際在創建數據倉庫模型的時候，可以參考使用上述數據倉庫不同的建模方法，在各個不同階段采用不同的方法，從而能夠保證整個數據倉庫建模的質量。

方法論僅僅停留在理論層面上，落地實現的才真正決定了數倉設計的好壞，當然再好的方法，只有在合適的階段使用，才有意義，才能發揮它最大的價值。