《資料倉儲工具箱：維度建模的完全指南》筆記總結

此篇是關於本書的讀書筆記總結，因為在這方面的理解還是比較初級的狀態，有誤之處還望指教。

 

個人認為這本書對於資料倉儲的建模思路有一個很明確的描述：圍繞事實表建立維度表。對資料倉儲的建設有關鍵步驟上的指點：

     四步流程：

     1. 確定業務流程

     2. 確定粒度

     3. 確定維度

     4. 確定事實表

另外一方面，由於這本書的出版時間大約在2005年前，因此對於Hadoop之類的分散式概念沒有涉及，姑且可以認為是傳統資料倉儲建模的建模流程（這裡的表述未必準確，因為本書主要是概念性的指導而非物理實現的說明，因此對於資料建模還是有很大的參考價值的）。而且不知道是不是翻譯的差異，感覺行文比較囉嗦，經常看了半天也抓不住重點。

 

這裡列舉一些感觸較深的概念：

1.      因果維度：如果某個維度的變化會導致事實表變化，則稱其為因果維度。事實上，每個維度（比如時間維度）的變化都會造成事實表（比如銷售量）的變化，因果維度的特殊性在於這種變化是主動的，用來描述決策者行為對事實表的變化，而時間等維度更多的是自然性的變化。

因果維度的對立面是偶然維度，這個概念我也沒有足夠了解，可能指的是相關而非因果的資訊。

促銷維度是一種典型的因果維度，其中包括降價，活動等等，見第二章

2.      匯流排結構：這是對於公司不同部分在資料倉儲建設方面的關聯方法，增量的構建資料倉儲。既然不同業務部門都要建立資料倉儲，作者提出按業務而不是按部門建立資料倉儲，因此匯流排流水式符合業務的執行流程，可以更好的與業務結合，畢竟資料倉儲的目標是服務業務的

3.      值鏈：描述機構主體活動的自然邏輯流程。主要目標是將業務中先分解為幾個部分，不同部分可能分別由操作型源系統構成。

操作型源系統即OLTP，和資料倉儲的區別是normalized. 我個人認為normalized和denormalized問題如同CPU密集和IO密集型應用一樣，是資料倉儲和資料庫最最根本的分別。（雪花型和星型反映的也是資料倉儲的規範化程式，即應用中的半規範化概念）。

4.      半加性事實：在某些維度下可加，在另外一些維度下不可加的事實。比如銀行存款，在日期維度上，一週後的存款不等於每天結算時的存款總額，而在銀行網點維度上，一個城市的總存款等於各個分行的存款總額。

5.      混合事實表：某些應用中，事實表的事實可能存在內在關聯，那麼是把它們分裂作為不同的事實表，還是混合作為一個整體的事實表需要考量。

6.      漸變維度：在業務發生調整時基本保持不變的維度，與之相對應的是快變維度，比如某個維度表的屬性經常性的發生取值變化。

7.      一致性維度：避免不同業務部門對於維度定義的不統一，這也是資料倉儲團隊的主要工作之一，避免同一個概念的不同表述。

8.      三種基本的事實表：

     (1)事務：記錄基本的事務活動

     (2)週期性快照 : 規律性的時間插入

     (3)累計快照：存在重新存取

9.  維度支架：一種雪花狀模型使用的條件，其特點是最外延的維度表很多屬性，它又作為關鍵字給內延維度表查詢使用，合併在一起由於粒度差距較大而會引起極大的冗餘

10. 屬性變化策略

     (1) 改變屬性值：對於非關鍵字，可以直接做替換，問題在於無法記錄舊的取值

     (2) 新增維度行：如果某個維度的屬性發生變化，那麼不是直接替換原來值，而是生成新值

     (3) 新增維度列：比如現部門，前部門。增加一個新的維度列把維度與之間資訊相關聯

 

另外有一本書<<點選流資料倉儲>>，作者也是Kimball的擁護者，也存在時間較早的遺憾，雖然談了很多具體實現，但和現在的應用環境有較大的區別。網上有很多不錯的建模文章（比如寬表建模，Hive）但還是很希望能有一些接地氣的DW/BI設計書籍可以系統閱讀，如果有可以推薦給我非常歡迎。