一.建模理論
1.1 ER實體模型
在信息系統(tǒng)中常侣，將事務抽象為“實體”（Entity）荡澎、“屬性”（Property）蹋笼、“關系”（Relationship）來表示數(shù)據(jù)關聯(lián)和事物描述堪置，這種對數(shù)據(jù)的抽象建模通常被稱為ER實體關系模型殃饿。
實體：
通常為參與到過程中的主體饮寞，客觀存在的孝扛，比如商品、倉庫骂际、貨位疗琉、汽車，此實體非數(shù)據(jù)庫表的實體表歉铝。
屬性：
對主體的描述盈简、修飾即為屬性，比如商品的屬性有商品名稱太示、顏色柠贤、尺寸、重量类缤、產地等臼勉。
關系：
現(xiàn)實的物理事件是依附于實體的，比如商品入庫事件餐弱，依附實體商品宴霸、貨位囱晴，就會有“庫存”的屬性產生；用戶購買商品瓢谢，依附實體用戶畸写、商品，就會有“購買數(shù)量”氓扛、“金額”的屬性產品枯芬。
實體之間建立關系時，存在對照關系：
1:1：即1對1的關系
1:n：即1對多的關系
n:m：即多對多的關系
應用場景：
- ER模型是數(shù)據(jù)庫設計的理論基礎采郎，當前幾乎所有的OLTP系統(tǒng)設計都采用ER模型建模的方式千所。
- Bill Inom提出的數(shù)倉理論，推薦采用ER關系模型進行建模蒜埋。
- BI架構提出分層架構淫痰，數(shù)倉底層ods、dwd也多采用ER關系模型進行設計理茎。
1.2 維度建模
維度建模源自數(shù)據(jù)集市黑界，主要面向分析場景管嬉。Ralph Kimball推崇數(shù)據(jù)集市的集合為數(shù)據(jù)倉庫皂林，同時也提出了對數(shù)據(jù)集市的維度建模，將數(shù)據(jù)倉庫中的表劃分為事實表蚯撩、維度表兩種類型础倍。
1.2.1 事實表
在ER模型中抽象出了有實體、關系胎挎、屬性三種類別沟启，在現(xiàn)實世界中，每一個操作型事件犹菇，基本都是發(fā)生在實體之間的德迹，伴隨著這種操作事件的發(fā)生，會產生可度量的值揭芍，而這個過程就產生了一個事實表胳搞，存儲了每一個可度量的事件。
1.2.2 維度表
維度称杨，顧名思義肌毅，看待事物的角度。比如從顏色姑原、尺寸的角度來比較手機的外觀悬而，從cpu、內存等角度比較手機性能锭汛。
維度表一般為單一主鍵笨奠，在ER模型中袭蝗，實體為客觀存在的事務，會帶有自己的描述性屬性般婆，屬性一般為文本性呻袭、描述性的，這些描述被稱為維度腺兴。
比如商品左电，單一主鍵：商品ID，屬性包括產地页响、顏色篓足、材質、尺寸闰蚕、單價等栈拖，但并非屬性一定是文本，比如單價没陡、尺寸涩哟，均為數(shù)值型描述性的，日常主要的維度抽象包括：時間維度表盼玄、地理區(qū)域維度表等贴彼。
維度建模通常又分為星型模型和雪花模型。
雪花埃儿、星型模型
雪花器仗、星型模型的選擇：
對于傳統(tǒng)數(shù)據(jù)倉庫:
對于變化較少的維度，例如地區(qū)維度童番，省精钮、市、區(qū)剃斧，可以采取星型模型轨香，提高檢索的效率。
對于變化頻繁的維度幼东，例如公司部門的組織架構臂容，為了程序的可維護性，可以采取雪花模型筋粗。當組織架構發(fā)生變化策橘，我們只需要維護維度表即可。對于大數(shù)據(jù)系統(tǒng):
大數(shù)據(jù)和傳統(tǒng)關系型數(shù)據(jù)庫的計算框架不一樣娜亿，例如對比mapreduce和oracle丽已，在mapreduce里面，每多一個表的關聯(lián)买决，就多一個job沛婴。mapreduce的每個任務進來吼畏，要申請資源，分配容器嘁灯，各節(jié)點通信等泻蚊。有可能YARN調度時長大于任務運行時間，例如調度需要5秒才能申請到資源丑婿，而表之間的join只需要2秒性雄。hive優(yōu)化里面，要盡可能減少job任務數(shù)羹奉，也就是減少表之間的關聯(lián)秒旋，可以用適當?shù)娜哂鄟肀苊獾托У牟樵兎绞剑@是和oracle等其他關系型數(shù)據(jù)庫不同的地方诀拭。
所以針對大數(shù)據(jù)系統(tǒng),盡可能的使用快照表及星型模型迁筛。
建模可以套用的模板:當事人模型
1.3 Data Vault模型
Data Vault是在ER模型的基礎上衍生而來耕挨，模型設計的初衷是有效的組織基礎數(shù)據(jù)層细卧，使之易擴展，靈活應對業(yè)務變化筒占，同時強調歷史性贪庙、可追溯性和原子性，不要求對數(shù)據(jù)進行過度的一致性處理赋铝，并非針對分析場景所設計插勤。
Data Vault模型是一種中心輻射式模型，其設計重點圍繞著業(yè)務鍵的集成模式革骨。這些業(yè)務鍵是存儲在多個系統(tǒng)中的、針對各種信息的鍵析恋，用于定位和唯一標識記錄或數(shù)據(jù)良哲。
Data Vault模型包含三種基本結構：
1）中心表-Hub：唯一業(yè)務鍵的列表，唯一標識企業(yè)實際業(yè)務助隧，企業(yè)的業(yè)務主體集合筑凫。
2）鏈接表-Link：表示中心表之間的關系，通過鏈接表串聯(lián)整個企業(yè)的業(yè)務關聯(lián)關系并村。
3）衛(wèi)星表-Satellite：歷史的描述性數(shù)據(jù)巍实，數(shù)據(jù)倉庫中數(shù)據(jù)的真正載體。
Data Vault是對ER模型更進一步的規(guī)范化哩牍，由于對數(shù)據(jù)的拆解更偏向于基礎數(shù)據(jù)組織棚潦，在處理分析類場景時相對復雜，適合數(shù)倉底層構建膝昆，目前實際應用場景較少丸边。
1.4 Anchor
Anchor是對Data Vault模型做了更進一步的規(guī)范化處理叠必，初衷是為了設計高度可擴展的模型，核心思想是所有的擴張只添加而不修改妹窖，于是設計出的模型基本變成了K-V結構的模型纬朝，模型范式達到了6NF。
由于過度規(guī)范化骄呼，使用中牽涉到太多的join操作共苛，目前沒有實際案例，僅作了解蜓萄。
二. 四種基本建模方法對比
??Data Vault模型和Anchor模型對于審計類的系統(tǒng)比較適用俄讹，當前的數(shù)據(jù)倉庫模型大多采用ER模型和維度模型。
ER模型
ER模型俗稱范式模型绕德，需要全方位的梳理業(yè)務流和數(shù)據(jù)流患膛，項目周期長，對建模人員要求也高耻蛇，傳統(tǒng)的大中型公司穩(wěn)定的系統(tǒng)可以采用ER模型踪蹬。維度模型
維度建模是面向分析場景而生，針對分析場景構建數(shù)倉模型臣咖，重點關注快速跃捣、靈活的解決分析需求，同時能夠提供大規(guī)模數(shù)據(jù)的快速響應性能夺蛇。針對性強疚漆，主要應用于數(shù)據(jù)倉庫構建和OLAP引擎底層數(shù)據(jù)模型。
三. 維度建模技術基本概念
3.1 收集業(yè)務需求與數(shù)據(jù)實現(xiàn)
??開始維度建模工作前 刁赦，項目組需要理解業(yè)務需求 娶聘，以及作為基礎的源數(shù)據(jù)的實際情況 。 通過與業(yè)務代表交流來發(fā)現(xiàn)需求 甚脉，用于理解他們的基于關鍵性能指標 丸升、競爭性商業(yè)問題、 決策制定過程 牺氨、支持分析需求的目標狡耻。同時，數(shù)據(jù)實際情 況可以通過與源系統(tǒng)專家交流 猴凹， 構建高層次數(shù)據(jù)分析訪問數(shù)據(jù)可行性來揭示 夷狰。
??脫離了實際業(yè)務的建模就是扯淡，建模前一定要與熟悉企業(yè)的業(yè)務流及數(shù)據(jù)流郊霎。
3.2 協(xié)作維度建模研討
??維度模型應該由主題專家與企業(yè)數(shù)據(jù)管理代表合作設計而成 沼头。工作由數(shù)據(jù)建模者負責，但模型應該通過與 業(yè)務代表開展一系列高級別交互討論獲得 歹篓。這些討論組也為 豐富業(yè)務需求提供了一種機會 瘫证。維度模型不應該由那些不懂業(yè)務以及業(yè)務需求的人來設計 揉阎，協(xié)作是成功的關鍵 。
??最了解業(yè)務的是一線的業(yè)務人員及業(yè)務領導背捌，在實際建模過程中毙籽，一定要多與業(yè)務人員溝通，協(xié)助才是成功的關鍵毡庆，閉門造車是行不通的坑赡。
3.3 4 步驟維度設計過程
維度模型設計期間主要涉及 4 個主要的決策 ：
- 選擇業(yè)務過程
- 聲明粒度
- 確認維度
- 確認事實
要回答上述問題，需要考慮業(yè)務需求以及協(xié)作建模階段涉及的底層數(shù)據(jù)源 么抗。按照業(yè)務過程 毅否、粒度 、維度 事實聲明的流程 蝇刀，設計組確定表名和列名 螟加、示例領域值以及業(yè)務規(guī)則 。而業(yè)務數(shù)據(jù)管理代表必須參與詳細的設計活動 吞琐，以確保涵蓋正確的業(yè)務 捆探。
3.4 業(yè)務過程
??業(yè)務過程是組織完成的操作型活動 ，例如 站粟，獲得訂單 黍图、處理保險索賠 、學生課程注冊 或每個月每個賬單的快照等 奴烙。業(yè)務過程事件建立或獲取性能度量 助被，并轉換為事實表中的事 實。多數(shù)事實表關注某一業(yè)務過程的結果 切诀。過程的選擇是非常重要的 揩环，因為過程定義了特定的設計目標 以及對粒度 、維度趾牧、事實 的定義 检盼。每個業(yè)務過程對應企業(yè)數(shù)據(jù)倉庫總線矩陣 的一行。
??以貸款業(yè)務為場景翘单，一次貸款申請行為可以理解為一個業(yè)務過程，申請時間蹦渣、申請產品可以理解為維度哄芜，申請金額這個可以理解為度量。
3.5 粒度
??聲明粒度是維度設計的重要步驟 柬唯。粒度用于確定某 一事實表中的行表示什么 认臊。粒度聲明是設計必須履行的合同 。在選擇維度或事實前必須聲明粒度 锄奢，因為每個候選維度或事實 必須與定義的粒度保持 一致 失晴。在所有維度設計中強制 實行一致性是保證 BI 應用性能和易用 性的關鍵 剧腻。在從給定的業(yè)務過程 獲取數(shù)據(jù)時 ，原子粒度是最低級別的粒度 涂屁。我們強烈建議從關注原子級別粒度數(shù)據(jù)開始設計 书在，因為原子粒度數(shù)據(jù) 能夠承受無法預期的用戶 查詢 。上 卷匯總粒度對性能調整 來說非常重要 拆又，但這樣的粒度往往要猜測業(yè)務公共問題 儒旬。針對不同 的事實表粒度 ，要建立不同的物理表 帖族，在同一事實表 中不要混用多種不同的粒度 栈源。
??以貸款業(yè)務為場景，還款分多期竖般，還款事實表的粒度可以是每一期還款為粒度甚垦，也可以是整個貸款單的還款為粒度。
3.6 描述環(huán)境的維度
??維度提供圍繞某 一業(yè)務過程事件所涉及的 “ 誰 涣雕、什么 艰亮、何處、何時胞谭、為什么 垃杖、如何” 等背景 。維度表包含 Bl 應用所需要的用于過濾及分 類事實 的描述性屬性 丈屹。牢牢掌握事實表 的粒度 调俘，就能夠將所有可能存在 的維度區(qū)分開 。當與給定事實表行關聯(lián)時 旺垒，任何情況下都 應使維度保持單 一值彩库。
??維度表有時被稱為數(shù)據(jù)倉庫的 “ 靈魂”，因為維度表包含確保 DW/BI 系統(tǒng)能夠被用作 業(yè)務分析的入口和描述性標識 先蒋。主要的工作都放在數(shù)據(jù) 管理與維度表的開發(fā)方面骇钦，因為它 們是用戶 BI 經驗的驅動者 。
??以貸款業(yè)務為場景竞漾，貸款申請的申請時間眯搭、申請產品、客戶的地域业岁、客戶的年齡等都屬于維度鳞仙，通過個維度的分析可以有助于我們找到目標客群，提升整個申請環(huán)節(jié)的效率笔时，為企業(yè)創(chuàng)收棍好。
3.7 用于度量的事實
??事實涉及來自業(yè)務過程事件的度 量 ，基本上都是以數(shù) 量值表示 。一個事實表行與按照 事實表粒度描述的度量事件之間存在一對一關系借笙，因此事實表對應一個物理可觀察的事件 扒怖。 在事實表 內，所有事實只允許與聲明的粒度保持一致业稼。例如 盗痒，在零售事務中 ，銷售產品 的 數(shù)量與其總額是良好的事實 盼忌，然而商店經理的工資不允許存在于零售事務中 积糯。
??以貸款業(yè)務為場景，申請金額就是事實表的度量值谦纱。
3.8 星型模式與 OLAP 多維數(shù)據(jù)庫
??星型模式是部署在關系數(shù)據(jù)庫管理系統(tǒng) (RDBMS）之上的多維結構 看成。典型地，主要包含 事實表 跨嘉，以及通過主鍵／外鍵關系與之關聯(lián)的維度表 川慌。聯(lián)機分析處理（OLAP）多維數(shù)據(jù)庫是 實現(xiàn)在多維數(shù)據(jù)庫之上的多維結構 ，它與關系型星型模式內容等價 祠乃，或者說來源于關系型 星型模式 梦重。OLAP 多維數(shù)據(jù)庫包含維度屬性和事實表 ，但它能夠使用 比 SQL 語言具有更強 的分析能力的語言訪 問亮瓷，例如 琴拧，XMLA 和 MDX 等 。OLAP 多維數(shù)據(jù)庫包含在基本技術 的 列表中 嘱支，因為 OLAP 多維數(shù)據(jù)庫通常是部署維度 DW/BI 系統(tǒng)的最后步驟 蚓胸，或者作為 一種 基于多個原子關系型星型模式的聚集結構 。
3.9 方便地擴展到維度模型
??維度模型對數(shù)據(jù)關系發(fā)生變化具有靈活的適應性 除师。當發(fā)生以下所列舉的變化時 沛膳，不需 要改變現(xiàn)存的 BI 查詢或應用 ，就可以方便地適應 汛聚，且查詢結果不會有任何改變 锹安。
- 當事實與存在的事實表粒度 一致時 ，可以創(chuàng)建新列 倚舀。
- 通過建立新的外鍵列 叹哭，可 以將維度關聯(lián)到己經存在的事實表上 ，前提是維度列與 事實表粒度保持一致痕貌。
- 可以在維度表上通過建立新列添加屬性 话速。
- 可以便事實表 的粒度更原子化 ，方法是在維度表上增 加屬性 芯侥，然后以更細的粒度 重置事實表 ，小心保存事實表及維度表 的列名。
