1、維度建模相關概念
1.1、度量和環境
維度建模支持對因為過程的支持，這是通過對業務過程度量進行建模來實現的。
那么，什么是度量呢？實際上，通過和業務方、需求方交談、或者閱讀報表、圖表等，可以很容易地識別度量。
考慮如下因為需求：
a、店鋪上個月的銷售額如何？
b、店鋪庫存趨勢如何？
c、店鋪的訪問情況如何（pv page view 訪問量, 即頁面瀏覽量或點擊量，衡量網站用戶訪問的網頁數量；在一定統計周期內用戶每打開或刷新一個頁面就記錄1次，
多次打開或刷新同一頁面則瀏覽量累計。uv: Unique Visitor）獨立訪客，統計1天內訪問某站點的用戶數(以cookie為依據);訪問網站的一台電腦客戶端為一個訪客。
可以理解成訪問某網站的電腦的數量）。
d、店鋪訪問的熟客占比多少？
這里的銷售額、庫存、訪問量、熟客量就是度量。缺乏上下文和環境來談論度量是沒有意義的。
度量和環境這兩個概念構成了維度建模的基礎。而所有維度建模都是通過對度量和其上下文和環境的詳細設計來實現的。
1.2、事實和維度
通常來說，事實通常數值形式出現，而且一般都被大量的文本形式的上下文包圍。這些文本形式的上下文描述了事實的5個W（when、where，what、who、why）信息，
通常可被直觀地分隔為獨立的邏輯塊，每一個獨立的邏輯塊即為一個維度，比如一個訂單可以非常直觀地分為商品、買家、賣家等多個維度。
在維度建模和設計過程中，可以根據需求描述或基於現有報表，很容易將信息和分析需求分類到事實和度量中。比如業務人員需求為“按照一級類目，統計本店鋪上月的銷售額情況”，
“按照一級類目”這個描述，很清楚說需求方希望對一級類目的銷售額進行統計分析，這里的一級類目即為一個維度。類似的是，“上月”為另一個維度，而銷售額明顯是一個事實。
2、事實表
事實表是維度模型中的基本表，或者說核心表。事實上，業務過程的所有度量在維度建模中都是存儲在事實表中的，除此之外，事實表還存儲了引用的維度。
事實表通常和一個企業的業務過程緊密相關，由於一個企業的業務過程數據構成了其數據的絕大部分，因此事實表也通常占用了數據倉庫存儲的絕大部分。比如對於某個超市來說，
其銷售的明細數據通常占其擁有數據絕大部分且每天還在不斷的累計和增長，而商品，門店、員工、設備等其他數據相對來說固定且變化不大。
事實表的一行對應一個度量事件，事實上，每行對應的度量事件可粗可細。維度建模認為事實表應該包含最底層的、最原子性的細節，因為這樣會帶來最大靈活性。維度建模中，
細節的級別稱為事實表的粒度。
事實表中最常用的度量一般是數值型和可加類型的。除了存儲事實外，事實表都會包含多個相關的外鍵，用於關聯和連接對應的維度表。正是通過這些外鍵，才能進行各個角度、
各個維度的分析。
在進行事實表的設計時，一定要注意一個事實表只能有一個粒度，不能將不同粒度的事實建立在同一張事實表中。
3、維度表
維度表是維度建模的靈魂，通常來說，維度表設計的好壞直接決定了維度建模的好壞。
維度表包含了事實表所記錄的業務過程度量的上下文和環境，它們除了記錄“5個W”等信息外，通常還包含了很多描述字段和標簽字段等。
維度表通常由多列或說多個屬性。實際應用中，包含幾十甚至上百屬性的維度並不少見。維度表應該盡可能地包括一些有意義的文字性描述，以方便下游用戶使用。
維度屬性是查詢約束條件（SQL where條件）,分組（SQL group語句）與報表標簽生成的基本來源。
維度屬性在數據倉庫中承擔這一個重要的角色。由於它們實際上所有令人感興趣的約束條件和報表標簽的來源，因此是數據倉庫易學易用的關鍵。在許多方面，
數據倉庫不過是維度屬性的體現而已。數據倉庫的能力直接與維度屬性的質量和深度成正比。在提供詳細的業務用語屬性方面所花的時間越多，數據倉庫就越好；在屬性列值給定方面所花的時間越多，
數據倉庫就越好；在保證屬性列值的質量方面花的時間越多，數據倉庫就越好。
維度表是進入事實表的入口。豐富的維度屬性給出了豐富的分析切割能力。維度給用戶提供了使用數據倉庫的接口。最好的屬性是文本的和離散的。屬性應該是真正的文字而不應是
一些編碼簡寫符號。應該通過更為詳細的文本屬性取代編碼，力求最大限度的減少編碼在維度表中的使用。
有時候在設計數據庫時，並不能確定從數據源分析取出的一個數字型數據字段到底應該作為事實還是維度屬性看待。通常可以這樣做出決定，
即看字段是一個含有許多取值並參與運算的度量值（當事實看待），還是一個變化不多並做為約束條件的 離散取值的描述（當作維度屬性看待）。
參考資料：《離線和實時大數據開發實戰》