一、Kimball維度建模
1.前生今世
維度建模出自Ralph Kimall的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling》（《數據倉庫工具箱》）一書，是十分流行的數倉建模理論。
維度建模從根本上來講是以結果爲導向的，由數據消費到底層數據的思路。維度建模是一種比較容易理解的業務數據化的方法和思維。個人認爲，維度建模可以很好地適應大規模數據響應項目交付的場景。
2.Kimball維度建模四大過程
1）選擇業務過程
業務過程是主體完成的活動，是維度建模的基礎。客觀來描述很抽象，舉例來說明。下單、付款、發貨和完成訂單都可以叫作業務過程，完成活動的主體有些差異。去理解和描述業務過程是後續過程的前置條件。
2）聲明粒度
聲明粒度是建模過程中非常精細的一環，因爲粒度是要清晰的表名事實表的每一行數據代表的意義。還是舉例來說明，訂單表每一條數據都是一個獨立的訂單（父子訂單等情況後續博客會再論述）。後續維度和事實必須要和此時聲明的粒度保持一致，所以此過程是十分精細的一環。同時要提一下，聲明粒度爲了保證模型的靈活，後續能滿足更豐富的業務需求，建議從原子粒度（不可再拆分的粒度）角度去聲明粒度。
3）確認維度
聲明粒度完成以後，標示事實表的最小單位，兩者的粒度是要統一的，那維度的確認也就水到渠成了，確認維度，主要是要描述事實表的出處和所處環境的維度信息。依舊舉例來說明，根據上述的訂單來說，一個訂單的維度有什麼，交易雙方人員、商品和時間等信息，這就確認了維度。
4）確認事實
確認事實就是來確認這個業務過程的度量是什麼，事實的度量要和聲明的粒度、確認的維度的粒度保持一致。有點拗口，最後一次的舉例說明，一個訂單的金額是就是一個度量。而度量可分爲三種類型：可加、半可加和不可加（後續博客會繼續論述）。
二、OneData體系
OneData體系實時過程如下：
1.數據調研
1）業務調研
數據倉庫的建設，業務十分重要，調研直接關乎數據倉庫是否是成功的。調研內容至少包含需求的業務流程、業務流程所屬業務模塊和業務模塊所屬業務線。
2）需求調研
需求調研簡單來說就是調研運營和分析等角色的需求。通常有兩個種方式去做需求調研，第一種，去和運營和分析去溝通他們的需求；第二種，分析現在已有的報表系統和數據消費需求。
2.架構設計
1）數據域劃分
數據域指的是面向業務分析，將業務過程或者維度進行抽象的集合。業務過程是指一個不可拆分的行爲事實。
舉例說明：*業務過程：下單、付款、收貨 *數據域：交易域。
2）構架總線矩陣
第一步、明確數據域下所有的業務過程。
第二步、明確業務過程和維度的關係，定義數據域下的業務過程和維度。
3）規範定義
定義指標體系內的原子指標、業務限定、時間週期和派生指標（命名規則可以後面在規劃）。
4）模型設計
主要是CDM層的設計（前面博客有介紹中臺分層），主要包括維表、事實明細表和彙總明細表的設計（後續博客會詳細介紹）。
實時流程圖：
