數據倉庫常見建模方法與建模實例演示

1.數據倉庫建模的目的？

  爲什麼要進行數據倉庫建模？大數據的數倉建模是通過建模的方法更好的組織、存儲數據，以便在 性能、成本、效率和數據質量之間找到最佳平衡點。一般主要從下面四點考慮

1. 訪問性能：能夠快速查詢所需的數據，減少數據I/O
2. 數據成本：減少不必要的數據冗餘，實現計算結果數據複用，降低大數 據系統中的存儲成本和計算成本 
3. 使用效率：改善用戶應用體驗，提高使用數據的效率
4. 數據質量：改善數據統計口徑的不一致性，減少數據計算錯誤 的可能性，提供高質量的、一致的數據訪問平臺

2.常見的數據建模方法

數據倉庫本質是從數據庫衍生出來的，所以數據倉庫的建模也是不斷衍生髮展的。從最早的借鑑數據庫的範式建模，到逐漸提出維度建模，Data Vault模型，Anchor模型等等，越往後建模的要求越高，越需滿足3NF,4NF等。但是對於數據倉庫來說，目前主流還是維度建模,會夾雜着範式建模。

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

3.常見四種建模方法的建模步驟與演示

3.1.範式建模（E-R模型）

        將事物抽象爲“實體”、“屬性”、“關係”來表示數 據關聯和事物描述；實體：Entity，關係：Relationship，這種對數據的抽象 建模通常被稱爲ER實體關係模型  

       ER模型是數據庫設計的理論基礎，當前幾乎所有的OLTP系統設計都採用ER模型建模的方式，且該建模方法需要滿足3NF。Bill Inom提出的數倉理論，推薦採用ER關係模型進行建模，BI架構提出分層架構，數倉底層ods、dwd也多采用ER關係模型就行設計。

     但是逐漸隨着企業數據的高增長，複雜化，數倉全部使用ER模型建模顯得越來越不合時宜。爲什麼呢，因爲其按部就班的步驟，三範式等，不適合現代化複雜，多變的業務組織。

E-R模型建模的步驟（滿足3NF）如下：

1.  抽象出主體         (教師，課程)
2. 梳理主體之間的關係   （一個老師可以教多門課，一門課可以被多個老師教）
3. 梳理主體的屬性    （教師：教師名稱，性別，學歷等）
4. 畫出E-R關係圖

3.2.維度建模

       維度建模，是數據倉庫大師Ralph Kimball提出的，是數據倉庫工程領域最流行的數倉建模經典。
      維度建模以分析決策的需求出發構建模型，構建的數據模型爲分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。維度建模是面向分析的，爲了提高查詢性能可以增加數據冗餘，反規範化的設計技術。

      Ralph Kimball提出對數據倉庫維度建模，並且將數據倉庫中的表劃分爲事實表、維度表兩種類型。

3.2.1.事實表

      在ER模型中抽象出了有實體、關係、屬性三種類別，在現實世界中，每一個操作型事件，基本都是發生在實體之間的，伴隨着這種操作事件的發生，會產生可度量的值，而這個過程就產生了一個事實表，存儲了每一個可度量的事件。

以電商行業爲例：電商場景：一次購買事件，涉及主體包括客戶、商品、商家，產生的可度量值 包括商品數量、金額、件數等

         

    事實表根據粒度的角色劃分不同，可分爲事務事實表、週期快照事實表、累積快照事實表。注意：這裏需要值得注意的是，在事實表的設計時，一定要注意一個事實表只能有一個粒度，不能將不同粒度的事實建立在同一張事實表中。

1. 事務事實表，用於承載事務數據，通常粒度比較低，它是面向事務的，其粒度是每一行對應一個事務，它是最細粒度的事實表，例如產品交易事務事實、ATM交易事務事實。
2. 週期快照事實表，按照一定的時間週期間隔(每天，每月)來捕捉業務活動的執行情況，一旦裝入事實表就不會再去更新，它是事務事實表的補充。用來記錄有規律的、固定時間間隔的業務累計數據，通常粒度比較高，例如賬戶月平均餘額事實表。
3. 累積快照事實表，用來記錄具有時間跨度的業務處理過程的整個過程的信息，每個生命週期一行，通常這類事實表比較少見。

3.2.2.維度表

        維度，顧名思義，業務過程的發生或分析角度。比如從顏色、尺寸的角度來比較手機的外觀，從cpu、內存等較比比較手機性能維。維度表一般爲單一主鍵，在ER模型中，實體爲客觀存在的事物，會帶有自己的 描述性屬性，屬性一般爲文本性、描述性的，這些描述被稱爲維度。

       比如商品，單一主鍵：商品ID，屬性包括產地、顏色、材質、尺寸、單價等， 但並非屬性一定是文本，比如單價、尺寸，均爲數值型描述性的，日常主要的維度抽象包括：時間維度表、地理區域維度表等

 

案例：某電商平臺，經常需要對訂單進行分析，以某寶的購物訂單爲例，以維度建 模的方式設計該模型
      涉及到事實表爲訂單表、訂單明細表，維度包括商品維度、用戶維度、商家維度、區域維 度、時間維度 
         商品維度：商品ID、商品名稱、商品種類、單價、產地等 
         用戶維度：用戶ID、姓名、性別、年齡、常住地、職業、學歷等 
         時間維度：日期ID、日期、周幾、上/中/下旬、是否週末、是否假期等 

維度分爲：

（1）退化維度（DegenerateDimension）

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

（2）緩慢變化維（Slowly Changing Dimensions）

維度的屬性並不是始終不變的，它會隨着時間的流逝發生緩慢的變化，這種隨時間發生變化的維度我們一般稱之爲緩慢變化維（SCD）。比如員工表中的部門維度，員工的所在部門有可能兩年後調整一次。

3.2.3.維度建模模型的分類

 維度建模按數據組織類型劃分可分爲星型模型、雪花模型、星座模型。

（1）星型模型

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

（2）雪花模型

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

尖叫提示：所以由上可以看出

1.  星型模型和雪花模型主要區別就是對維度表的拆分
2. 對於雪花模型，維度表的涉及更加規範，一般符合3NF，有效降低數據冗餘，維度表之間不會相互關聯，但是
3. 而星型模型，一般採用降維的操作，反規範化，不符合3NF,利用冗餘來避免模型過於複雜，提高易用性和分析效率，效率相對較高。

（3）星座模型

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

3.2.4. 維度建模步驟

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

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

3.3 DataVault模型

          Data Vault是Dan Linstedt發起創建的一種模型方法論，Data Vault是在ER模型的基礎上衍生而來，模型設計的初衷是有效的組織基礎數據層，使之易擴展、靈活的應對業務的變化，同時強調歷史性、可追溯性和原子性，不要求對數據進行過度的一致性處理。同時設計的出發點也是爲了實現數據的整合，並非爲數據決策分析直接使用。
          Data Vault模型是一種中心輻射式模型，其設計重點圍繞着業務鍵的集成模式。這些業務鍵是存儲在多個系統中的、針對各種信息的鍵，用 於定位和唯一標識記錄或數據

Data Vault模型包含三種基本結構 ：

1. 中心表-Hub ：唯一業務鍵的列表，唯一標識企業實際業務，企業的業務主體集合 
2. 鏈接表-Link： 表示中心表之間的關係，通過鏈接表串聯整個企業的業務關聯關係 
3. 衛星表- Satellite： 歷史的描述性數據，數據倉庫中數據的真正載體

3.3.1 中心表-Hub

3.3.2 鏈接表-Link

3.3.3 衛星表- Satellite

3.3.4 Data Vault模型​​​​​​建模流程

1. 梳理所有主要實體 
2. 將有入邊的實體定義爲中心表 
3. 將沒有入邊切僅有一個出邊的表定義爲中心表 
4. 源苦衷沒有入邊且有兩條或以上出邊的表定義爲連接表 
5. 將外鍵關係定義爲鏈接表

尖叫提示：Hub想像成人體的骨架，那麼Link就是連接骨架的韌帶組織， 而satelite就是骨架上的血肉。 Data Vault是對ER模型更近一步的規範化，由於對數據的拆解和更偏向於基礎數據組織，在處理分析類場景時相對複雜， 適合數倉低層構建，目前實際應用場景較少

 

3.4Anchor模型

1.  Anchor是對Data Vault模型做了更近一步的規範會處理，初衷是爲了 設計高度可擴展的模型，核心思想是所有的擴張只添加而不修改，於 是設計出的模型基本變成了k-v結構的模型，模型範式達到了6NF
2. 由於過度規範化，使用中牽涉到太多的join操作，目前木有實際案例，僅作了解

4.四種模型總結

以上爲四種基本的建模方法，當前主流建模方法爲：ER模型、維度模型

1. ER模型常用於OLTP數據庫建模，應用到構建數倉時更偏重數據整合， 站在企業整體考慮，將各個系統的數據按相似性一致性、合併處理，爲 數據分析、決策服務，但並不便於直接用來支持分析。缺陷：需要全面梳理企業所有的業務和數據流，週期長，人員要求高。
2. 維度建模是面向分析場景而生，針對分析場景構建數倉模型；重點關注快 速、靈活的解決分析需求，同時能夠提供大規模數據的快速響應性能。針對性 強，主要應用於數據倉庫構建和OLAP引擎低層數據模型。優點：不需要完整的梳理企業業務流程和數據，實施週期根據主題邊界而定，容易快速實現demo
3.  數倉模型的選擇是靈活的，不侷限於某一種模型方法
4. 數倉模型的設計也是靈活的，以實際需求場景爲導向
5. 模型設計要兼顧靈活性、可擴展，而對終端用戶透明性
6. 模型設計要考慮技術可靠性和實現成本

5.常用建模工具

建模工具，一般企業以Erwin、powerdesigner、visio，甚至Excel等爲主。也有些企業自行研發工具，或使用阿里等成熟套裝組件產品。