原文連接：https://blog.csdn.net/mark_wu2000/article/details/82668787web
「無心中發現的一篇很是的好的文章，分享給你們，建議收藏。」微信
概述
維度建模是一種將數據結構化的邏輯設計方法，它將客觀世界劃分爲度量（事實）和上下文（維度）。度量是經常是以數值形式出現，事實周圍有上下文包圍着，這種上下文被直觀地分紅獨立的邏輯塊，稱之爲維度。它與實體-關係建模有很大的區別，實體-關係建模是面向應用，遵循第三範式，以消除數據冗餘爲目標的設計技術。維度建模是面向分析，爲了提升查詢性能能夠增長數據冗餘，反規範化的設計技術。數據結構
維度建模優勢
-
便於管理 -
提升查詢性能 -
對稱性 -
可擴展性
事實表
事實表存儲了從業務活動或事件提煉出來的性能度量，它主要包含維度表的外鍵和連續變化的可加性數值或半可加事實。事實表產生於業務過程當中而不是業務過程的描述性信息。它通常是行多列少，佔了數據倉庫的90%的空間。在維度模型中也有表示多對多關係的事實，其餘都是維度表。架構
事實表粒度
事實表的粒度是產生事實行的度量事件的業務定義。粒度肯定了事實表的業務主鍵，事實表的全部度量值必須具備相同的粒度。app
事實表類型
1.事務事實表
它是面向事務的，其粒度是每一行對應一個事務，它是最細粒度的事實表。異步
2.週期快照事實表
它是按照良好的時間週期間隔(天天，每個月)來捕捉業務活動的執行狀況，一旦裝入事實表就不會再去更新，它是事務事實表的補充，而非替代品。編輯器
3.累積快照事實表
它用於描述業務過程當中某個不肯定時間跨度裏的活動，它隨着業務活動的發生會不斷的更新。性能
事實表區別
維度表
維度表是對業務過程的上下文描述，主要包含代理鍵、文本信息和離散的數字。它是進入事實表的入口，豐富的維度屬性給出了對事實表的分析切割能力，它通常是行少列多。若是屬性值是離散的，用於過濾和標記的，就放到維度表裏，若是是屬性值是連續取值，用於計算的，就放到事實表中。flex
維度表類型
緩慢變化維
1.類型1spa
字段值發生變化時覆蓋原來的值。
2.類型2
字段值發生變化時會新增一行，從新分配代理鍵，每一行添加開始日期，結束日期，版本號，是否當前值。
3.類型3
每條記錄會新增一列來標識變化前的值，發生變化時，把舊值放到新增的列中，把新值覆蓋舊值。
4.混合類型
把上面的三種類型混合來使用。
日期維
它是數據倉庫必須有的維度，包含日期，日期所屬的周，月，季度，年等信息。
角色維
相同的維度表在維度模型中扮演不一樣的邏輯角色，通常經過建立視圖來表示。
雜項維
若是每一個屬性值都不多，能夠把這些維度的組合起來生成一個維度表。
支架維
若是維度之間是一對多的關係或區別於原維度的多個描述性維度屬性，能夠建雪花型支架維度。
多值維度橋接維
若是二個維度表是多對多的關係，可使用多值維度設計。
微型維
一個大型維有些屬性變化比較頻繁，把這些屬性單獨生成一個微型維度表。
縮小維
它是維度表的一個子集或部分屬性。
查找維
系統裏代碼表裏維度信息。
層次維
有些維度表是有層次結構的，能夠經過視圖生成樹形結構的維度表。
手工維護的維表
有些數據不在業務系統裏，須要業務用戶手工維護的維度表。
企業數據倉庫總線架構
企業價值鏈
每家機構都有一個關鍵業務過程組成的潛在價值鏈，這個價值鏈肯定機構主體活動的天然邏輯流程。數據倉庫建設就是圍繞着價值鏈創建一致化的維度和事實。
數據總線
這些業務過程都會共用一些維度，造成了企業數據倉庫的總線，一致化維度和事實看做一組標準的應用程序鏈接口，能夠看做一個數據倉庫的總線架構。它能夠將新的業務過程引入數據倉庫中，該業務過程從總線得到動力，而且和其餘已經存在的業務過程和諧共存。
數據總線矩陣
矩陣的每一行對應都對應機構中的一個業務過程，每一列都和一個業務維度相對應，用叉號填充顯示的是和每一行相關的列。業務過程應該先從單個數據源系統開始，而後再進行多數據源的合併。
企業數據倉庫總線矩陣是DW/BI系統的一個整體數據架構，提供了一種可用於分解企業數據倉庫規劃任務的合理方法，開發團隊能夠獨立的，異步的完成矩陣的各個業務過程，迭代地去創建一個集成的企業數據倉庫。
一致性維度和事實
企業數據倉庫應該創建一個一致性維度和事實，而不是爲每一個部門創建維度和事實。
一致性維度
具備一致的維度關鍵字，一致的屬性列名稱，一致的屬性定義和一致的屬性值。一致性維度要麼是統一的，要麼是維度表的一個子集。
一致性事實
指每一個度量在整個數據倉庫中都是惟一的統計口徑，爲了不歧義，一個度量只有惟一的業務術語。
維度模型設計方法
維度模型設計流程圖
維度模型設計步驟
1.需求調研
2.數據探查
根據總線矩陣，肯定業務過程的優先級，就要對候選數據源進行可行性評估，產出文檔有源系統跟蹤報告，數據評估報告。主要內容有：
3.高層模型設計
4.識別維度和度量
有了高層模型，就要設計維度和度量，維度和度量清單不只僅是業務用戶所關心，還要從業務過程出發，自上而下的設計所涉及的維度和度量。防止業務用戶的需求變化帶來的衝擊。
5.肯定命名規範
在詳細設計以前，爲DW/BI系統制定規範，主要包含源系統、主題、業務術語、報表，物理設計命名、調度任務、文檔方面的規範。
6.編寫詳細設計映射文檔
詳細設計文檔包括從源系統到維度模型的每一個數據層的物理映射文檔。
7.審查和驗證模型
詳細設計文檔出來後，要和業務用戶和團隊成員進行評審，記錄下來評審過程當中的問題，造成問題清單。
8.完成設計文檔
最後肯定設計文檔，進行下一步的ETL開發。
有熱門推薦👇
本文分享自微信公衆號 - 一萬小時極客（coding-Hub）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。