什麼是事實表
事實表的結構
事實數據表是包含描述業務內特定事件的數據。是發生在現實世界中的操作型事件所產生的可度量數據，通常包含大量的行。日常查詢請求的主要目標就是基於事實表展開計算和聚合操作。
從最低粒度級別來看，事實錶行對應一個度量事件，也可以說，一個度量事件必然對應一個最低粒度的事實行爲。因此，事實表的設計完全依賴物理活動，不受可能產生的最終報表的影響。
事實表一般會包含數字度量，也總會包含外鍵，用來與相關的維表做關聯。
常用的事實表經常會包含日期/時間戳，退化維度鍵（退化維度鍵的解釋不再展開，想了解具體定義可Baidu或者看我下期博客）。
數據度量分類
數據度量可分爲：可加，半可加，不可加三類。
可加類：最靈活，最有用的事實。可加類度量可以按照與事實表關聯的任意維度彙總。
半可加類：可以對某些維度彙總，但不能對所有維度彙總。例如，訂單差額的計算，除了時間維度外，它們可以跨所有維度進行加法操作。
不可加類：完全不可加類。例如 ，比率。對非可加事實，一種好的方法時，儘可能存儲非可加度量的完全可加的分量，並在計算出最終的非可加事實前，將這些分量彙總到最終的結果集合中。
事實表中的空值
事實表中可以存在空值。所有的聚合函數（sum,count,min,max ，avg等）均可針對空值計算。但是外鍵和用來關聯維度表的id不能存放空值，否則會導致違反參照完整性的情況發生，可以採用使用默認行（代理鍵）的形式來表示未知的或者無法應用的條件。
一致性原則
1.如果某些度量出現在不同的事實表中，應該保證針對事實的技術定義是相同的。
2.如果不同的事實表定義是一致的，則這些一致性事實應該具有相同的命名。
3.如果不同的事實表定義不一致，則應該有不同的命名用來告誡業務用戶和BI應用。
簡單舉例
1.銀行對存款記賬，A表中存放實際數據，包括賬號、所屬機構號、存款金額等，B表存放機構號和機構名稱的對應關係。則A是事實表，B是維表。
2.用戶註冊網站。A表中存放實際數據，包括用戶的姓名，年齡，郵箱，國家id，省份id等，B表存放國家id與國家名字的對應關係。則A是事實表，B是維表。
事實表分類
-
可加，半可加，不可加事實
-
一致性事實表：
-
事務事實表：一行對應空間或時間上某點的度量事件。
優劣：事務事實表可以是稠密的，也可以是稀疏的，因爲僅當存在度量時纔會建立行
應用場景：
業務場景舉例： -
週期快照事實表：每行彙總了發生在某一標準週期，如某一天，某周，某月的多個度量事件。
優劣：
應用場景：
業務場景舉例： -
積累快照事實表：彙總了發生在過程開始和結束之間可預測步驟內的度量事件。管道或工作流過程具有定義的開始點，標準中間過程，定義的結束點，它們在此類事實表中都可以被建模。
優劣：
應用場景：緩慢變化維事實表的設計
業務場景舉例：以履行訂單表舉例。累計快照事實表中的一行，對應某一具體的訂單，當訂單產生時會插入一行，修改訂單行爲發生時，表內訂單數據被訪問並修改。 -
無事實的事實表：存在某些事件僅僅記錄一系列某一時刻發生的多維實體。
優劣：
應用場景：
業務場景舉例：在給定的某一天中發生的學生參加課程的事件。用戶註冊網站事件 -
聚集事實表或OLAP多維數據庫：聚合事實表是對原子粒度事實表數據進行簡單的數字化上卷操作，目的是爲了提高查詢性能。聚合事實表包含外鍵以縮小一致性維度，聚集事實的構建是通過對來自多個原子事實表的度量的彙總而獲得的。
優劣：適當設計的聚集集合類似數據庫索引，能夠提高查詢性能，但不需要直接面對BI應用和商業用戶
應用場景：數據倉庫中集市層的建設（IDL）
業務場景舉例： 未想到 -
合併事實表：通常將來自多個過程的，以相同粒度表示的事實合併爲一個單一的合併事實表，這樣做能夠帶來方便。
優劣：合併事實表會增加ETL處理過程的負擔，但降低了BI應用的分析代價。
應用場景：特別適合那些經常需要共同分析的多過程度量。
業務場景舉例：現貨銷售可以與銷售預測合併爲一張事實表，與針對多個不同的事實表採用下鑽應用比較，這樣做可使對現貨及預測任務的分析工作變得簡單快捷。