數據倉庫-維度模型
描述
Dimensional Modeling,簡稱DM，是一套技術和概念的集合，用於數據倉庫設計
核心概念
事實
表示對業務數據的度量
通常是數字類型的，可以進行聚合和計算
維度
對觀察數據的角度
一組層次關系或描述信息，用來定義事實
舉例：銷售金額是一個事實，而銷售時間、銷售的產品、購買的顧客、商店等都是銷售事實的維度。
維度模型按照業務流程領域即主題域簡歷，例如進貨、銷售、庫存、配送等。不同的主題域可能共享某些維度，為了提高數據操作的性能和數據一致性，需要使用一致性維度，例如幾個主題域間共享維度的復制。
特點
易理解
相對於規范化的關系模型，維度模型容易理解且更直觀。在維度模型中，信息按業務種類或維度進行分組，這回提高信息的可讀性，也方便了對於數據含義的理解。
關系模型中，數據被分布到多個離散的實體中，對於一個簡單的業務流程，可能需要很多表聯合在一起才能表示。
高性能
維度模型更傾向於非規范化，因為這樣可以優化查詢的性能。
關系模型規范化的實質是減少數據冗余，以優化事務處理或數據更新的性能。
維度設計的整體觀點是要簡化和加速查詢。
可擴展
由於維度模型允許數據冗余，因此當向一個維度表或事實表中添加字段時，不會像關系模型那樣產生巨大的影響，帶來的結果就是更容易容納不可預料的新增數據。這種新增可以是單純地向表中增加新的數據行而不改變表結構，也可以時在現有表上增加新的樹形。
基於數據倉庫的查詢和應用不需要過多改變就能適應表結構的變化，老的查詢和應用會繼續工作而不會產生錯誤的結果。但是對於規范化的關系模型，由於表之間存在復雜的依賴關系，改變表結構前一定要仔細考慮
建模過程
選擇業務流程
確認哪些業務處理流程是數據倉庫應該覆蓋的，是維度方法的基礎
例如，需要了解和分析一個零售店的銷售情況，那么與該零售店銷售相關的所有業務流程都是需要關注的。
聲明粒度
用於確定事實中表示的是什么，在選擇維度和事實前必須聲明粒度，因為每個候選維度或事實必須與定義的粒度保持一致。
在一個事實所對應的所有維度設計中強制實行粒度一致性是保證數據倉庫應用性能和易用性的關鍵。
從給定的業務流程獲取數據時，原始粒度是最低級別的粒度。建議從原始粒度數據開始設計，因為原始記錄能夠滿足無法預期的用戶查詢。匯總后的數據粒度對優化查詢性能很重要，但這樣的粒度往往不能滿足對細節數據的查詢需求。
不同的事實可以有不同的粒度，但同一事實中不要混用多種不同的粒度。
確認維度
維度的粒度必須和第二步所聲明的粒度一致
維度表是事實表的基礎，也說明了事實表的數據是從哪里采集來的。典型的維度都是名詞，如日期、商店、庫存等。
維度表存儲了某一維度的所有相關數據，例如，日期維度應該包括年、季度、月、周、日等數據
確認事實
識別數字化的度量，構成事實表的記錄。
它是和系統的業務用戶密切相關的，因為用戶正是通過對事實表的訪問獲取數據倉庫存儲的數據。
大部分事實表的度量都是數字類型的，可累加，可計算，如成本、數量、金額等。
模型樣式
星型模式
星型模型是維度模型最簡單的形式，也是數據倉庫以及數據集市開發中使用最廣泛的形式。一個星型模式中可以有一個或多個事實表，每個事實表引用任意數量的維度表。星型模式的物理模型像一顆星星的形狀，中心是一個事實表，圍繞在事實表周圍的維度表表示星星的放射狀分支。
組成
事實表
事實表記錄了特定事件的數字化的考量，一般由數字值和指向維度表的外鍵組成。通常會把事實表的粒度級別設計得比較低，使得事實表可以記錄很原始的操作型事件，但這樣做的負面影響是累加大量記錄可能會更耗時
- 事務事實表
記錄特定事件的事實，如銷售
- 快照事實表
記錄給定時間點的事實，如月底賬戶余額
- 累積事實表
記錄給定時間點的聚合事實，如當月的總的銷售金額。一般需要給事實表設計一個代理鍵作為每行記錄的唯一標識。代理鍵是由系統生成的主鍵，它不是應用數據，沒有業務含義，對用戶來說是透明的。
維度表
維度表的記錄數通常比事實表少，但每條記錄包含有大量用於描述事實數據的屬性子u但
通常給維度表設計一個單列、整型數字類型的代理鍵，映射業務數據中的主鍵。
類型
- 時間維度表
描述記錄的事件所發生的時間，具有所需的最低級別的時間粒度。數據倉庫是隨時間變化的數據集合，需要記錄數據的歷史，因此每個數據倉庫都需要一個時間維度表
- 地理維度表
描述位置信息的數據，如國家、省份、城市、區縣、郵編等
- 產品維度表
描述產品及其屬性
- 人員維度表
描述人員相關的信息，如銷售人員、市場人員、開發人員等
- 范圍維度表
描述分段數據的信息，如高級、中級、低級等
優點
簡化查詢
查詢數據時，星型模式的連接邏輯比較簡單，而從高度規范化的事務模型查詢數據時，往往需要更多的表連接。
簡化業務報表邏輯
與高度規范化的模式相比，由於查詢更方便，因此星型模式簡化了普通的業務報表邏輯
獲得查詢性能
星型模式可以提升只讀報表類應用的性能
快速聚合
基於星型模型的簡單查詢能夠提高聚合操作的性能
便於向立方體提供數據
星型模式被廣泛用於高效地簡歷OLAP立方體，幾乎所有的OLAP系統都提供ROLAP模型(關系型OLAP)，它可以直接將星型模式中的數據當作數據源，而不用單獨建立立方體結構。
缺點
不能保證數據完整性
一次性的插入或更新操作可能會造成數據異常，而這種情況再規范化模型中是可以避免的。星型模式的數據裝載，一般都是以高度受控的方式，用批處理或准實時過程執行的，以此來抵消數據保護方面的不足
對於分析需求不夠靈活
星型模式更偏重於為特定目的建造數據視圖，因此實際上很難進行全面的數據分析。星型模式不能自然地支持業務實體的多對多關系，需要在維度表和事實表之間建立額外的橋接表
雪花模式
雪花模式是一種多維模型中表的邏輯布局，其實體關系圖有類似於雪花的形狀，因此得名。
與星型模式相同，雪花模式也是由事實表和維度表所組成。所謂的雪花就是將星型模式中的維度表進行規范化處理。當所有的維度表完成規范化后，就形成了以事實表為中心的雪花型結構，即雪花模式。
將維度表進行規范化的具體做法是，把低基數的屬性從維度表中移除並形成單獨的表。基數指的是一個字段中不同值的個數，如主鍵列具有唯一值，所有有最高的基數，而像性別這樣的列基礎就很低。
在雪花模式中，一個維度被規范化成多個關聯的表，而在星型模式中，每個維度由一個單一的維度表所表示。一個規范化的維度對應一組具有層次關系的維度表，而事實表作為雪花模式里的子表，存在具有層次關系的多個父表
數據規范化與存儲
規范化的過程就是將維度表中重復的組分離成一個新表，以減少數據冗余的過程。正因如此，規范化不可避免地增加了表的數量。在執行查詢的時候，不得不連接更多的表。但是規范化減少了存儲數據的空間需求，而且提高了數據更新的效率。
組成
事實表
維度表：在星型模式的基礎上對維度表做規范化
優點
規范化的維度屬性節省存儲空間
一些OLAP多維數據庫建模工具專為雪花模型進行了優化
星型模式是雪花模式的一個特例（維度沒有多個層級）
缺點
維度屬性規范化增加了查詢的連接操作和復雜度
向雪花模式的表中裝載數據時，一定要有嚴格的控制和管理，避免數據的異常插入或更新。
Data Vault
定義
Data Vault是面向細節的，可追蹤歷史的，一組有連接關系的規范化的表的集合。這些表可以支持一個或多個業務功能。
它是一種綜合了第三范式（3NF）和星型模型優點的建模方法。
設計理念是滿足企業對靈活性、可擴展性、一致性和對需求的適應性要求，是一種專為企業級數據倉庫量身定制的建模方式。
描述
是一種數據倉庫建模方法，用來存儲來自多個操作型系統的完整的歷史數據。Data Vault方法需要跟蹤所有數據的來源，因此其中滅個數據行都要包含數據來源和裝載時間屬性，用以審計和跟蹤數據值所對應的源系統。
Data Vault不區分數據在業務層面的正確與錯誤，它保留操作型系統的所有時間的所有數據，裝載數據時不做數據驗證、清洗等工作，這點明顯有別於其它數據倉庫建模方法。
Data Vault建模方法顯式地將結構信息和屬性信息分離，能夠還原業務環境的變化。Data Vault允許並行數據裝載，不需要重新設計就可以實現擴展。
例如：業務規則應該在數據的下游實現，就是說Data Vault只按照業務數據的原樣保存數據，不做任何解釋、過濾、清洗、轉換。即使從不同數據源來的數據是自相矛盾的，Data Vault模型不會遵照任何業務的規則，如“以系統A的地址為准”。Data Vault模型會保存兩個不同版本的數據，對數據的解釋將推遲到整個架構的后一個階段(數據集市)。
組成
中心表(Hub)
用來保存一個組織內的每個實體的業務主鍵，業務主鍵唯一標識某個業務實體。
中心表和源系統表是相互獨立的。當一個業務主鍵被用在多個系統時，它在Data Vault中也只保留一份，其他的組件都鏈接到這一個業務主鍵上。
屬性
- 主鍵：系統生成的代理鍵，供內部使用
- 業務主鍵：唯一標識的業務單元，用於已知業務的源系統
- 裝載時間：數據第一次裝載到數據倉庫時系統生成的時間戳
- 數據來源：定義了數據來源(例如源系統或表)
鏈接表(Link)
鏈接表是中心表之間的鏈接。一個鏈接表意味着兩個或多個中心表之間有關聯。
一個鏈接表通常是一個外鍵，它代表着一種業務關系。
屬性
- 主鍵：系統生成的代理鍵，供內部使用
- 外鍵{1...N}：引用中心表的代理鍵
- 裝載時間：數據第一次裝載到數據倉庫時系統生成的時間戳
- 數據來源：定義了數據來源(例如源系統或表)
附屬表(Satellite)
附屬表用來保存中心表和鏈接表的屬性，包括所有的歷史變化數據。一個附屬表總有一個且唯一一個外鍵引用到中心表或鏈接表。
屬性
- 主鍵：系統生成的代理鍵，供內部使用
- 外鍵：引用中心表或鏈接表的代理鍵
- 裝載時間：數據第一次裝載到數據倉庫時系統生成的時間戳
- 失效時間：數據失效時的時間戳
- 數據來源：定義了數據來源（例如源系統或表）
- 屬性{1...N}：屬性自身
特點
所有數據都基於時間來存儲，即使數據是低質量的，也不能在ETL過程中處理掉
依賴越少越好
和源系統越獨立越好
設計上適合變化
源系統中數據的變化
在不改變模型的情況下可擴展
ETL作業可以重復執行
數據完全可追蹤
