Bill Inmon：數據倉庫是一個面向主題的、集成的、隨時間變化的、但信息本身相對穩定的數據集合，用于對管理決策過程的支持。

Ralph Kimball：數據倉庫是一個將源系統數據抽取、清洗、規格化、提交到維度數據存儲的系統，為決策的制定提供查詢和分析功能的支持與實現。

Inmon的表述側重于數據倉庫的性質和特點，Kimball的表述側重于數據倉庫建設的過程，綜合而言，數據倉庫是從源系統通過一系列操作匯集的、為管理決策提供支持的數據集合，具有面向主題、集成、隨時間變化、信息相對穩定的特點。

如其定義所言，數據倉庫的目的是為管理決策提供支持，因此數據倉庫的建設需要圍繞這個目的進行。

那么如何為管理決策提供支持呢？假設是一家銷售公司，那最基本的支持就是提供銷售業績數據。如果沒有數據倉庫，那么當管理者需要查詢這些數據并以此制定相應決策時，就需要從生產庫中直接拉取，那么顯然存在兩個問題：

1、影響生產業務

2、數據不可復用

因此需要有一個倉庫存儲數據實現聯機分析處理（OLAP，Online Analytical Processing）。

既然是一個倉庫，那么里面無論是貨物還是數據都不能雜亂無章地堆放，而如何有效組織數據就成了研究數據倉庫的重點，不同的組織方式形成了關于數據倉庫的不同建模理論。

1、ER模型（Entity-Relationship Modeling）

ER模型常用于OLTP數據庫建模，應用到構建數倉時更偏重數據整合， 站在企業整體考慮，將各個系統的數據按相似性一致性、合并處理，為數據分析、決策服務，但并不便于直接用來支持分析。缺陷：需要全面梳理企業所有的業務和數據流，周期長，人員要求高。

ER模型是站在企業的角度從上往下按主題進行相似性組合和合并，并進行一致性處理，最經典的實踐就是Teradata公司基于金融業務發布的FS-LDM（Finacial Services Logical Data Model），它將金融業務劃分為10大主題，企業可基于這個模型快速落地自己的數據倉庫。

2、維度模型（Dimensional Modeling）

維度建模是面向分析場景而生，針對分析場景構建數倉模型；重點關注快速、靈活的解決分析需求，同時能夠提供大規模數據的快速響應性能。針對性強，主要應用于數據倉庫構建和OLAP引擎低層數據模型。優點：不需要完整的梳理企業業務流程和數據，實施周期根據主題邊界而定，容易快速實現demo，而且相對來說便于理解、提高查詢性能、對稱并易擴展。

維度模型更側重于完成具體的分析決策需求，是一種從下往上的構建思路。同時，它關注大規模復雜查詢的響應性能，星型模型是其具體形式。

以事實表為中心，用代理鍵把維度表關聯起來

除了以上兩種外，還有Dan Linstedt提出的Data Valut模型和對其做進一步規范化處理的Anchor模型，但就目前實際使用情況而言，普遍采用的都是Kimball的維度模型及其變型，因此下面主要介紹維度模型框架下的相關概念。

開展維度建模首先需要理解兩個最重要的概念：維度和事實。

維度

維度建模的語境下，維度指的是環境，如你所處的城市、小區、公司、部門，商品所歸屬的一級大類、二級大類等。更通俗地理解是，維度指的是where和by后面跟著的字段，用來查詢約束、分類匯總和排序。

事實

維度建模中的事實比維度更難理解，其實這里的事實指的是度量，如商品數量、成交金額、利潤率等。度量業務過程的事實，一般為整型或浮點型的十進制數值，可分為可加、半可加和不可加三種類型。可加的事實指能夠以任意維度直接匯總；半可加事實只能以特定維度匯總，如房屋面積可以按小區匯總，但不能按時間匯總，因為今天的房屋面積加昨天的房屋面積是沒有意義的；不可加事實不具有可加性，如比率型事實，在任何維度下利潤率加利潤率都不具有實際含義。

維度表

維度表又稱維表，維表存儲的一般是對事實描述的信息。每一張維表對應現實世界中的一個對象或者概念。例如：用戶、商品、日期、地區等。

維度表的簡單示例

緩慢變化維

緩慢變化維指維度并不是靜態的，而是會隨著時間的推移發生緩慢變化。通用的處理方法是，在不考慮存儲成本的情況下可通過每天保留一份全量的快照數據來處理變化的維度，當有需要的時候取最近的維度表進行關聯。除此之外，還有全量重寫、增加行、增加列、開發拉鏈表等方法來處理這個問題。

事實表

事實表主要圍繞業務過程設計，表中的每行數據代表一個業務事件（下單、支付、退款、評價等）。每一個事實表的行包括：具有可加性的數值型的度量值、與維表相連接的外鍵。通常具有兩個和兩個以上的外鍵，外鍵之間表示維表之間多對多的關系。

事實表的簡單示例

就應用場景而言，事實表主要包括如下三種類型：

1、事務事實表

用于描述業務過程，按業務過程的單一性或多業務過程可進一步分為單事務事實表和多事務事實表。其中單事務事實表分別記錄每個業務過程，如下單業務記入下單事實表，支付業務記入支付事實表。多事務事實表在同一個表中包含了不同業務過程，如下單、支付、簽收等業務過程記錄在一張表中，通過新增字段來判斷屬于哪一個業務過程。

2、周期快照事實表

在一個確定的時間間隔內對業務狀態進行度量，如用戶每月使用信用卡的消費情況。

3、累計快照事實表

用于查看不同事件之間的時間間隔，例如分析用戶從購買到支付的市場、從下單到訂單完結的時長等，一般適用于有明確時間間隔的業務過程。

雪花模型

雪花模型是用以組織事實表和維度的模型之一。如上圖，雪花模型的維度表會分得較為細碎，往往一張維度表下會包含好幾個外鍵用以與下層的維度進行關聯。

星型模型

星型模型是雪花模型的退化形式。如上圖，星型模型的地域維度表收斂成一張，當需要地域維度時事實表只需與這一張地域維度表關聯即可。

退化和冗余

雪花模型和星座模型的組織形式很重要的目的就是節省存儲空間。如中國可以用CHN表示，當有需要的時候再與維度表關聯上展示全稱“中華人民共和國”，假設通過這個方法每條記錄可節省11個字節的話，那么一百萬條記錄就可節省約1MB，這在二十年前硬盤容量較少的情況下還是需要考慮的。

但是嚴格按照星型模型或雪花模型組織事實表和維度度帶來的問題就是查詢和應用事實表時需要多層關聯，影響分析效率，因此目前實際采用的做法普遍都是把一些通用和使用頻繁的維度表信息退化進事實表里形成一定程度的冗余，這樣做法的原因如下：

1、從過去20的技術發展來看，存儲成本的下降幅度要大于cpu和內存的下降幅度，同時存儲成本占企業開銷的占比也在不斷下降，因此節約存儲空間不是目前數倉建設最主要考慮的因素之一。

2、時間成本變得越來越重要。如果嚴格區分事實表和維度表，當需要事實表和維度表關聯時join的時間開銷是不得不考慮的。當業務急需某數據時，明明是一個select就能解決的事情，卻要join好幾張表花上好幾倍時間才能得到相同的結果，這其實是很劃不來的，更遑論需要維護的表的數量也是冗余后的好幾倍乃至幾十倍。

3、目前所采用的Hadoop框架下，擔心的不是存儲空間的大小，而是需要考慮如何減少MR啟動的次數和查詢時所用的到job的數量，這些會嚴重影響查詢和統計的效率。由于每次join都要增加一個job，而嚴格按照星型模型和雪花模型組織時是需要大量join的，這就與目前的技術路線相悖了。

數據域

指面向業務分析，將業務過程或維度進行抽象的集合。業務過程是一個個不可拆分的行為事件，維度指度量的環境。在劃分數據域時，既能涵蓋當前所有的業務需求，又能在新業務進入時無影響地被包含進已有的數據域中。常見的數據域劃分：商品域、日志域、交易域、互動域等。

業務過程

指企業的業務活動事件，如下單、支付、退款都是業務過程，通俗地講，業務過程就是企業活動中不可拆分的行為事件。

粒度

粒度指的就是每一行的含義，如日志表中的粒度就是用戶每一次的操作記錄，訂單表中的粒度就是用戶所下的訂單。

以上便是目前數據倉庫領域中最為重要的一些概念了，掌握這些概念有助于對數倉建設形成全面的認識。