1.資料倉儲建模目標
資料倉儲建模的目標是通過建模的方法更好的組織、儲存資料，以便在效能、成本、 效率和資料質量之間找到最佳平衡點。
訪問效能：能夠快速查詢所需的資料，減少資料 i/o;
資料成本：減少不必要的資料冗餘，實現計算結果資料復用，降低大資料系統中的資料 成本和計算成本;
使用效率：改善使用者應用體驗，提高使用資料的效率。
資料質量：整合所有資料來源的資料，改善資料統計口徑的不一致性，減少資料計算錯誤
上述的四點之間是存在衝突的，為了提高訪問效能，可能會提高資料冗餘(減少 join操作)， 這樣會降低計算成本，但是會導致資料儲存成本很高，並且由於資料的冗餘，會提高資料統 計口徑不一致的風險，我們的目的是通過合理的設計在效能、成本、效率和資料質量之間找 到平衡點。
2.維度模型基本概念
維度建模的理論由 ralph kimball 提出，他提出將資料倉儲中的表劃分為
事實表和
維度表兩種型別，專門用於分析型資料庫、資料倉儲、資料集市建模的方法。資料集市可以理解為是一種"小型資料倉儲"。
2.1 維度表（用來儲存該維的元資料，即維的描述資訊，包括維的層次及成員類別等）
維度表示你要對資料進行分析時所用的乙個量,比如你要分析產品銷售情況, 你可以選擇按類別來進行分析,或按區域來分析。這樣的按..分析就構成乙個維度。再比如"昨天下午我在星巴克花費200元喝了一杯卡布奇諾"。那麼以消費為主題進行分析，可從這段資訊中提取三個維度：時間維度(昨天下午)，地點維度(星巴克), 商品維度(卡布奇諾)。通常來說維度表資訊比較固定，且資料量小。
2.2 事實表（用來儲存事實的度量(measure)及指向各個維的外鍵值）：
表示對分析主題的度量。事實表包含了與各維度表相關聯的外來鍵，並通過join方式與維度表關聯。事實表的度量通常是數值型別，且記錄數會不斷增加，表規模迅速增長。比如上面的消費例子，它的消費事實表結構示例如下：
消費事實表：prod_id(引用商品維度表), timekey(引用時間維度表), place_id(引用地點維度表), unit(銷售量)。
總的說來，在資料倉儲中不需要嚴格遵守規範化設計原則。因為資料倉儲的主導功能就是面向分析，以查詢為主，不涉及資料更新操作。事實表的設計是以能夠正確記錄歷史資訊為準則，維度表的設計是以能夠以合適的角度來聚合主題內容為準則。
3.維度建模流程步驟
3.1 確認業務過程
選擇建模的業務過程，比如園區中庫存單元被租賃出去。
3.2 確認粒度
保證粒度為最小粒度，保證以後的可擴充套件性，以及向下鑽去的靈活性。特殊說明，除週期性快照表，其他型別的事實表的時間粒度都保持操作性系統中的時間，即明細到時分秒。
3.3 確認維度
也就是確認業務過程設計到的維度，維度主要用途是回答「what, when, where, how」等這樣的問題。bi應用上，維度主要用來做篩選、分組、鑽取。
由於維度相對資料量較少，在hive中建立的維度表，建議不考慮使用分割槽。
3.3.1 緩慢漸變維
資料倉儲需要追蹤歷史，因此部分維度需要採用緩慢漸變的方式，計畫採用如下方式：
在維度表上增加起始日期(begin_date)與結束日期(end_date)，以及當前狀態（current_status）
3.3.2 維度一致性
在確認最小粒度之後，維度表盡量一次建成以後，後續可重複使用，如此可以保證維度的一致性。
3.4 確認事實
確認需要衡量的事實，例如進出園區人數，次數；園區租賃金額等。
• 事務型事實表：主要用來捕捉特定維度範圍內，會經常發生的一系列基本無序的事件。
• 週期型快照事實表：按照一定時間粒度（day/month），儲存特定維度範圍內的效能度量。例如，每日進出園區的人數。
• 累積快照事實表：用來捕捉一系列有序的事件，在不同時間範階段內效能度量。例如，crm系統中有lead(潛在意向客戶)->deal(簽約中的客戶) -> lease(發生租賃的客戶)，這樣一系列的流程可以考慮使用累積快照事實表。
4.維度建模三種模式
4.1 星型模式
星形模式(star schema)是最常用的維度建模方式。星型模式是以事實表為中心，所有的維度表直接連線在事實表上，像星星一樣。
星形模式的維度建模由乙個事實表和一組維表成，且具有以下特點：
a. 維表只和事實表關聯，維表之間沒有關聯；
b. 每個維表主鍵為單列，且該主鍵放置在事實表中，作為兩邊連線的外來鍵；
c. 以事實表為核心，維表圍繞核心呈星形分布；
4.2 雪花模式
雪花模式(snowflake schema)是對星形模式的擴充套件。雪花模式的維度表可以擁有其他維度表的，雖然這種模型相比星型更規範一些，但是由於這種模型不太容易理解，維護成本比較高，而且效能方面需要關聯多層維表，效能也比星型模型要低。所以一般不是很常用。
4.3 星座模式
星座模式是星型模式延伸而來，星型模式是基於一張事實表的，而星座模式是基於多張事實表的，而且共享維度資訊。
前面介紹的兩種維度建模方法都是多維表對應單事實表，但在很多時候維度空間內的事實表不止乙個，而乙個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。
5.維度建模例項
5.1 背景
某電商平台，經常需要對訂單進行分析，以某寶的購物訂單為例，以維度建模的方式設計該模型。
5.2 事實表與維度表的劃分
事實表為訂單表、子訂單表，維度包括商品維度、使用者維度、商家維度、區域維度、時間維度。
5.3 事實表分析
訂單中包含的度量:商品件數、總金額、總減免金額;
描述性屬性:下單時間、付款時間、訂單狀態等;
子訂單包含度量:商品 id、單價、減免金額;
描述性屬性:加入購物車時間、下單時間、付款時間、狀態;
5.4 維度表分析
商品維度:商品 id、商品名稱、商品品類、單價、顏色、尺寸、生產商等;
使用者維度:使用者 id、姓名、性別、生日、職業、信用值、收貨位址等;
時間維度:日期 id、日期、週幾、是否週末、是否假期等;
區域維度:區域 id，縣/區、縣/區 id、市、市 id、省、省 id;
訂單表和子訂單表是兩張事實表，我們往往會避免事實表之間產生關係，因此會考慮讓子訂單表中有一定的資料冗餘，比如訂單表和訂單明細表都各自記錄著使用者 id，區域 id，時間 id 等，這樣在查詢子訂單資訊時，就不用通過關聯訂單表來獲取上述資料了，但是子訂單表中仍會儲存訂單 id 字段。
資料倉儲維度建模
雪花模型 星型模型 星座 多個事實表 問題 1 資料倉儲，不針對某乙個分析主題，而是有多個分析主題，即多個事實表，維度表怎麼設計？2 即使是同乙個分析主題，也可能存在多個事實表，維度表如何設計？多個時間維度？無論星型模型 雪花模型還是星座模型，都是針對維度上的區別而來，星座模型實質上還是星型模型，只...
資料倉儲之維度建模流程
資料倉儲之維度建模流程 1.確認業務過程 選擇建模的業務過程，比如園區中庫存單元被租賃出去 2.確認粒度 保證維度粒度為最小粒度，保證以後的可擴充套件性，以及向下鑽去的靈活性。特殊說明，除週期性快照表，其他型別的事實表的時間粒度都保持操作性系統中的時間，即明細到時分秒。3.確認維度 也就是確認業務過...
資料倉儲維度建模概述
面向主題的。操作型資料庫的資料組織面向事物處理任務，各個業務系統之間各自分離，而資料倉儲中的資料是按照一定的主題域進行組織的。例如 當事人 協議 機構 財務 事件 產品等主題。整合的。資料倉儲中的資料是從多個不同的資料來源傳送來的。多個應用之間在編碼，命名習慣，物理屬性 不同的資料庫 欄位的資料型別...