一.建模理論
1.1 ER實體模型
在信息系統中，將事務抽象為“實體”（Entity）、“屬性”（Property）、“關系”（Relationship）來表示數據關聯和事物描述，這種對數據的抽象建模通常被稱為ER實體關系模型。
實體：
通常為參與到過程中的主體，客觀存在的，比如商品、倉庫、貨位、汽車，此實體非數據庫表的實體表。
屬性：
對主體的描述、修飾即為屬性，比如商品的屬性有商品名稱、顏色、尺寸、重量、產地等。
關系：
現實的物理事件是依附于實體的，比如商品入庫事件，依附實體商品、貨位，就會有“庫存”的屬性產生；用戶購買商品，依附實體用戶、商品，就會有“購買數量”、“金額”的屬性產品。
實體之間建立關系時，存在對照關系：
1:1：即1對1的關系
1:n：即1對多的關系
n:m：即多對多的關系
應用場景：
- ER模型是數據庫設計的理論基礎，當前幾乎所有的OLTP系統設計都采用ER模型建模的方式。
- Bill Inom提出的數倉理論，推薦采用ER關系模型進行建模。
- BI架構提出分層架構，數倉底層ods、dwd也多采用ER關系模型進行設計。
1.2 維度建模
維度建模源自數據集市，主要面向分析場景。Ralph Kimball推崇數據集市的集合為數據倉庫，同時也提出了對數據集市的維度建模，將數據倉庫中的表劃分為事實表、維度表兩種類型。
1.2.1 事實表
在ER模型中抽象出了有實體、關系、屬性三種類別，在現實世界中，每一個操作型事件，基本都是發生在實體之間的，伴隨著這種操作事件的發生，會產生可度量的值，而這個過程就產生了一個事實表，存儲了每一個可度量的事件。
1.2.2 維度表
維度，顧名思義，看待事物的角度。比如從顏色、尺寸的角度來比較手機的外觀，從cpu、內存等角度比較手機性能。
維度表一般為單一主鍵，在ER模型中，實體為客觀存在的事務，會帶有自己的描述性屬性，屬性一般為文本性、描述性的，這些描述被稱為維度。
比如商品，單一主鍵：商品ID，屬性包括產地、顏色、材質、尺寸、單價等，但并非屬性一定是文本，比如單價、尺寸，均為數值型描述性的，日常主要的維度抽象包括：時間維度表、地理區域維度表等。
維度建模通常又分為星型模型和雪花模型。
雪花、星型模型
雪花、星型模型的選擇：
對于傳統數據倉庫:
對于變化較少的維度，例如地區維度，省、市、區，可以采取星型模型，提高檢索的效率。
對于變化頻繁的維度，例如公司部門的組織架構，為了程序的可維護性，可以采取雪花模型。當組織架構發生變化，我們只需要維護維度表即可。對于大數據系統:
大數據和傳統關系型數據庫的計算框架不一樣，例如對比mapreduce和oracle，在mapreduce里面，每多一個表的關聯，就多一個job。mapreduce的每個任務進來，要申請資源，分配容器，各節點通信等。有可能YARN調度時長大于任務運行時間，例如調度需要5秒才能申請到資源，而表之間的join只需要2秒。hive優化里面，要盡可能減少job任務數，也就是減少表之間的關聯，可以用適當的冗余來避免低效的查詢方式，這是和oracle等其他關系型數據庫不同的地方。
所以針對大數據系統,盡可能的使用快照表及星型模型。
建模可以套用的模板:當事人模型
1.3 Data Vault模型
Data Vault是在ER模型的基礎上衍生而來，模型設計的初衷是有效的組織基礎數據層，使之易擴展，靈活應對業務變化，同時強調歷史性、可追溯性和原子性，不要求對數據進行過度的一致性處理，并非針對分析場景所設計。
Data Vault模型是一種中心輻射式模型，其設計重點圍繞著業務鍵的集成模式。這些業務鍵是存儲在多個系統中的、針對各種信息的鍵，用于定位和唯一標識記錄或數據。
Data Vault模型包含三種基本結構：
1）中心表-Hub：唯一業務鍵的列表，唯一標識企業實際業務，企業的業務主體集合。
2）鏈接表-Link：表示中心表之間的關系，通過鏈接表串聯整個企業的業務關聯關系。
3）衛星表-Satellite：歷史的描述性數據，數據倉庫中數據的真正載體。
Data Vault是對ER模型更進一步的規范化，由于對數據的拆解更偏向于基礎數據組織，在處理分析類場景時相對復雜，適合數倉底層構建，目前實際應用場景較少。
1.4 Anchor
Anchor是對Data Vault模型做了更進一步的規范化處理，初衷是為了設計高度可擴展的模型，核心思想是所有的擴張只添加而不修改，于是設計出的模型基本變成了K-V結構的模型，模型范式達到了6NF。
由于過度規范化，使用中牽涉到太多的join操作，目前沒有實際案例，僅作了解。
二. 四種基本建模方法對比
??Data Vault模型和Anchor模型對于審計類的系統比較適用，當前的數據倉庫模型大多采用ER模型和維度模型。
ER模型
ER模型俗稱范式模型，需要全方位的梳理業務流和數據流，項目周期長，對建模人員要求也高，傳統的大中型公司穩定的系統可以采用ER模型。維度模型
維度建模是面向分析場景而生，針對分析場景構建數倉模型，重點關注快速、靈活的解決分析需求，同時能夠提供大規模數據的快速響應性能。針對性強，主要應用于數據倉庫構建和OLAP引擎底層數據模型。
三. 維度建模技術基本概念
3.1 收集業務需求與數據實現
??開始維度建模工作前 ，項目組需要理解業務需求 ，以及作為基礎的源數據的實際情況 。 通過與業務代表交流來發現需求 ，用于理解他們的基于關鍵性能指標 、競爭性商業問題、 決策制定過程 、支持分析需求的目標。同時，數據實際情 況可以通過與源系統專家交流 ， 構建高層次數據分析訪問數據可行性來揭示 。
??脫離了實際業務的建模就是扯淡，建模前一定要與熟悉企業的業務流及數據流。
3.2 協作維度建模研討
??維度模型應該由主題專家與企業數據管理代表合作設計而成 。工作由數據建模者負責，但模型應該通過與 業務代表開展一系列高級別交互討論獲得 。這些討論組也為 豐富業務需求提供了一種機會 。維度模型不應該由那些不懂業務以及業務需求的人來設計 ，協作是成功的關鍵 。
??最了解業務的是一線的業務人員及業務領導，在實際建模過程中，一定要多與業務人員溝通，協助才是成功的關鍵，閉門造車是行不通的。
3.3 4 步驟維度設計過程
維度模型設計期間主要涉及 4 個主要的決策 ：
- 選擇業務過程
- 聲明粒度
- 確認維度
- 確認事實
要回答上述問題，需要考慮業務需求以及協作建模階段涉及的底層數據源 。按照業務過程 、粒度 、維度 事實聲明的流程 ，設計組確定表名和列名 、示例領域值以及業務規則 。而業務數據管理代表必須參與詳細的設計活動 ，以確保涵蓋正確的業務 。
3.4 業務過程
??業務過程是組織完成的操作型活動 ，例如 ，獲得訂單 、處理保險索賠 、學生課程注冊 或每個月每個賬單的快照等 。業務過程事件建立或獲取性能度量 ，并轉換為事實表中的事 實。多數事實表關注某一業務過程的結果 。過程的選擇是非常重要的 ，因為過程定義了特定的設計目標 以及對粒度 、維度、事實 的定義 。每個業務過程對應企業數據倉庫總線矩陣 的一行。
??以貸款業務為場景，一次貸款申請行為可以理解為一個業務過程，申請時間、申請產品可以理解為維度，申請金額這個可以理解為度量。
3.5 粒度
??聲明粒度是維度設計的重要步驟 。粒度用于確定某 一事實表中的行表示什么 。粒度聲明是設計必須履行的合同 。在選擇維度或事實前必須聲明粒度 ，因為每個候選維度或事實 必須與定義的粒度保持 一致 。在所有維度設計中強制 實行一致性是保證 BI 應用性能和易用 性的關鍵 。在從給定的業務過程 獲取數據時 ，原子粒度是最低級別的粒度 。我們強烈建議從關注原子級別粒度數據開始設計 ，因為原子粒度數據 能夠承受無法預期的用戶 查詢 。上 卷匯總粒度對性能調整 來說非常重要 ，但這樣的粒度往往要猜測業務公共問題 。針對不同 的事實表粒度 ，要建立不同的物理表 ，在同一事實表 中不要混用多種不同的粒度 。
??以貸款業務為場景，還款分多期，還款事實表的粒度可以是每一期還款為粒度，也可以是整個貸款單的還款為粒度。
3.6 描述環境的維度
??維度提供圍繞某 一業務過程事件所涉及的 “ 誰 、什么 、何處、何時、為什么 、如何” 等背景 。維度表包含 Bl 應用所需要的用于過濾及分 類事實 的描述性屬性 。牢牢掌握事實表 的粒度 ，就能夠將所有可能存在 的維度區分開 。當與給定事實表行關聯時 ，任何情況下都 應使維度保持單 一值。
??維度表有時被稱為數據倉庫的 “ 靈魂”，因為維度表包含確保 DW/BI 系統能夠被用作 業務分析的入口和描述性標識 。主要的工作都放在數據 管理與維度表的開發方面，因為它 們是用戶 BI 經驗的驅動者 。
??以貸款業務為場景，貸款申請的申請時間、申請產品、客戶的地域、客戶的年齡等都屬于維度，通過個維度的分析可以有助于我們找到目標客群，提升整個申請環節的效率，為企業創收。
3.7 用于度量的事實
??事實涉及來自業務過程事件的度 量 ，基本上都是以數 量值表示 。一個事實表行與按照 事實表粒度描述的度量事件之間存在一對一關系，因此事實表對應一個物理可觀察的事件 。 在事實表 內，所有事實只允許與聲明的粒度保持一致。例如 ，在零售事務中 ，銷售產品 的 數量與其總額是良好的事實 ，然而商店經理的工資不允許存在于零售事務中 。
??以貸款業務為場景，申請金額就是事實表的度量值。
3.8 星型模式與 OLAP 多維數據庫
??星型模式是部署在關系數據庫管理系統 (RDBMS）之上的多維結構 。典型地，主要包含 事實表 ，以及通過主鍵／外鍵關系與之關聯的維度表 。聯機分析處理（OLAP）多維數據庫是 實現在多維數據庫之上的多維結構 ，它與關系型星型模式內容等價 ，或者說來源于關系型 星型模式 。OLAP 多維數據庫包含維度屬性和事實表 ，但它能夠使用 比 SQL 語言具有更強 的分析能力的語言訪 問，例如 ，XMLA 和 MDX 等 。OLAP 多維數據庫包含在基本技術 的 列表中 ，因為 OLAP 多維數據庫通常是部署維度 DW/BI 系統的最后步驟 ，或者作為 一種 基于多個原子關系型星型模式的聚集結構 。
3.9 方便地擴展到維度模型
??維度模型對數據關系發生變化具有靈活的適應性 。當發生以下所列舉的變化時 ，不需 要改變現存的 BI 查詢或應用 ，就可以方便地適應 ，且查詢結果不會有任何改變 。
- 當事實與存在的事實表粒度 一致時 ，可以創建新列 。
- 通過建立新的外鍵列 ，可 以將維度關聯到己經存在的事實表上 ，前提是維度列與 事實表粒度保持一致。
- 可以在維度表上通過建立新列添加屬性 。
- 可以便事實表 的粒度更原子化 ，方法是在維度表上增 加屬性 ，然后以更細的粒度 重置事實表 ，小心保存事實表及維度表 的列名。
