累計快照事實表的概念
累積快照事實表用來表述過程開始和結束之間的關鍵步驟事件，覆蓋過程的整個生命周期，通常具有多個日期字段來記錄關鍵時間點， 當過程隨着生命周期不斷變化時，記錄也會隨着過程的變化而被修改。
設計過程
對於累積快照事實表，其建模過程和事務事實表相同，適用於維度建模的步驟。
下面詳述淘寶交易累積快照事實表的設計過程，並討論和事務事實表的設計差異。
選擇業務過程
對於以下四個業務過程，在事務統計中只關注下單、支付和確認收貨三個業務過程；而在統計事件時間間隔的需求中，賣家發貨也是關鍵環節。所以針對淘寶交易累積快照事實表，我們選擇這四個業務過程。
確定粒度
在“事務事實表”中提到，對於淘寶交易，業務需求一般是從子訂單粒度進行統計分析，所以選擇子訂單粒度。淘寶交易事務事實表的粒度也是子訂單，但通常對於子訂單的每個事件都會記錄一行，對於多事件事實表，如果子訂單同一周期發生多次事件則記錄一行；而對於累積快照事實表，用於考察實體的唯一實例，所以子訂單在此表中只有一行記錄，事件發生時，對此實例進行更新。
確定維度
與事務事實表相同，維度主要有買家、賣家、店鋪、商品、類目、發貨地區、收貨地區等。四個業務過程對應的時間字段，格式為日期＋時間，分別為下單時間、支付時間、發貨時間、確認收貨時間，對應於日期維表，圖l 1.24 中未標識。在實際使用時會使用視圖或SQL 別名的方式表示四個日期角色維度，類似於發貨地區維度和收貨地區維度。
在交易訂單表中，存在很多與訂單相關的屬性，如訂單類型、子類型、支付狀態、物流狀態、attributes 、options 等。對於類似的屬性字段，無法歸屬到已有的商品等維度中，所以新建雜項維度存放。
在數據倉庫建模理論中，雜項維度無自然鍵，一般是枚舉值的組合，對於每個組合生成一個代理鍵。但在實際建模中，存在很多非枚舉值，且對於每個訂單都不相同，如訂單的attributes 和options 屬性。所以實際中雜項維度設計時，也可以直接使用自然鍵標識具體的維度值，如下：
確認事實
對於累積快照事實表，需要將各業務過程對應的事實均放人事實表中。
比如淘寶交易累積快照事實表，包含了各業務過程對應的事實，如下單對應的下單金額，支付對應的折扣、郵費和支付金額，確認收貨對應的金額等。累積快照事實表解決的最重要的問題是統計不同業務過程之間的時間間隔，建議將每個過程的時間間隔作為事實放在事實表中。在淘寶交易累積快照事實表建模中，由於每個過程的時間間隔計算邏輯簡單，因此並未加人事實表中，如下：
退化維度
在大數據的事實表模型設計中，更多的是考慮提高下游用戶的使用效率，降低數據獲取的復雜性，減少關聯的表數量。一方面，存儲成本降低了，而相比之下CPU 成本仍然較高；另一方面，在大數據時代，很多維表比事實表還大，如淘寶幾十億的商品、幾億的買家等，在分布式數據倉庫系統中，事實表和維表關聯的成本很高。
所以在傳統的維度模型設計完成之后，在物理實現中將各維度的常用屬性退化到事實表中，以大大提高對事實表的過濾查詢、統計聚合等操作的效率。
累計快照事實表特點
數據不斷更新
事務事實表記錄事務發生時的狀態，對於實體的某一實例不再更新；而累積快照事實表則對實體的某一實例定期更新。
多業務過程日期
累積快照事實表適用於具有較明確起止時間的短生命周期的實體，比如交易訂單、物流訂單等，對於實體的每一個實例，都會經歷從誕生到消亡等一系列步驟。
對於商品、用戶等具有長生命周期的實體， 一般采用周期快照事實表更合適。
累積快照事實表的典型特征是多業務過程日期，用於計算業務過程之間的時間間隔。對於累積快照事實表，還有一個重要作用是保存全量數據。
對於淘寶交易，需要保留歷史截至當前的所有交易數據，其中一種方式是在ODS 層保留和源系統結構完全相同的數據z 但由於使用時需要關聯維度，較為麻煩，所以在公共明細層需要保留一份全量數據，淘寶交易累積快照事實表就承擔了這樣的作用一一存放加工后的事實，並將各維度常用屬性和訂單雜項維度退化到此表中。通常用於數據探查、統計分析、數據挖掘等。