公司的資料都有一定的複雜性,處理時很容易被其影響,只有總結並掌握乙個好的設計原則,才能應對紛繁複雜的業務細節。
先總結一下資料倉儲工具箱中的提到的維度建模的4步過程
第一步:選擇業務過程
業務過程的公共特徵:
1)業務過程通常表示業務執行的活動,用行為動詞表示
2)業務過程通常由某一操作型系統來支撐,如訂單管理系統
3)業務過程的結果通常是建立並獲得某些關鍵度量資料
4)業務過程包含輸入及輸出,由輸入啟用
一系列的業務過程產生一系列的事實表,通過對產生的資料進行分析,能夠得出一些利於管理者為提公升競爭優勢而制定決策的結論。所以,想要得到乙個好的設計模型,需要深入挖掘和理解資料及對應操作型系統,一方面不能被資料複雜性蒙蔽,另一方面也不能不加思索,草草了事。
第二步:確定粒度
確定粒度即精確定義事實表中的每一行表示什麼,它表示的是與事實表度量有關的細節級別。在理解上可以認為粒度與主鍵等價。但是在進行維度模型設計時,應該使用業務術語來表示粒度。
第三步:確定維度
維度用於描述業務過程事件的度量資料。比如說,從某個維度(日期)上來看,這條事件記錄(日期資料)反常,應該重點關注。常見的維度例項包括日期、產品、市場、客戶、雇員、裝置等。通常用於表示"who what where when why how"關聯的事件。
在確定維度的過程中,還是應該以滿足指導業務規劃決策的需求為原則,必須保證維度資料能夠說明問題。
第四步:確定事實
事實即過程事件的度量。典型的事實是可加性數值。企業通過分析這些度量資料來制定決策,以便提公升競爭力,這便是資料的價值。
緊緊通過資料來源確定事實來建模資料是不應該的,這樣很難發現資料與某些潛在條件之間可能的價值關係,所以,確定事實時需要考慮業務使用者的需求和資料**的實際情況。
下面結合零售業並根據以上四步來設計維度模型
1、選擇業務過程:
對乙個企業來說,在進行dw/bi專案時,首先應該選擇最關鍵並且最易實現的業務過程。也要考慮到資料可用性與質量及獲取的難易度。
就零售業務來講,管理者更希望通過交易系統來了解顧客的購買情況。於是,這裡業務過程選擇pos零售交易。
2、確定粒度
通常來講都應該確定為原子粒度,也就是最細級別的粒度。一般情況下,查詢需要以精確的方式對某些細節進行切分。如果是彙總粒度,可能面臨分析障礙,想想如果某個需求需要下鑽怎麼辦?
在零售業務中,最細粒度的資料,就是pos交易的單個產品。使用者可能想要知道一些情況,例如,需要知道某一商品工作日與休息日的銷售差別,某日打折商品的銷售情況,某種品牌的商品是否備存不足等等,這些需要對單個商品銷售情況進行上捲彙總,所以這裡以單個產品為粒度是很合理的。
3、確定維度
詳細的粒度就已經確定了事實表的主要維度,在零售案例中指產品維度。在交易事件發生時,產品隨事件直接呈現,比如說這是一瓶牙膏,**是多少,數量。可以考慮增加其他的維度,當然增加的維度,必須能夠按該維度值進行主維度聚合,並且該維度不會產生與既定粒度不符的其他事實行。
在零售業務中,除產品外、還可將日期、門店、收銀員、是否**、支付方式等緯度新增進來。
4、確定事實
事實必須要與粒度吻合,pos銷售系統收集的事實包括銷售數量、單價、折扣、應付額、實付額。
如乙個零售事實表:
日期(日期維度)、產品(產品維度)、商店(商店維度)、**(**維度)、收銀員(收銀員維度)、支付方式(支付維度)、pos交易號、銷售數量、單價、折扣價
在考慮事實的組成時,對可計算獲得的事實也應考慮在內,通常將其一並儲存在資料庫,等於使用一點儲存成本換使用者計算錯誤的成本。
我對維度建模和正規化建模的一點理解
概念模型 將業務劃分成幾個主題 邏輯模型 定義各種實體 屬性 關係 物理模型 設計資料物件的物理實現,比如表的命名規範 欄位的命名規範 字段型別等 我先來介紹一下正規化。域都應該是原子性。即資料不可分割 特殊 json 在1nf 的基礎上,實體的屬性完全依賴主關鍵字,不能存在僅依賴主關鍵字一部分的屬...
關於MongoDB的一點總結
今天推送引擎註冊在dubbo上的服務總是自動會關閉掉,查了一下發現是system.in.read 的原因,導致自動關閉。但是還是不太明白,別人執行spring的時候,只要啟動以後就不會自動關閉,而我的spring剛啟動就關閉了,找了半天都沒有解決,沒辦法,只好用了最笨的方法 while true 而...
關於演算法的一點總結
分解問題的角度 fix 某一維度,嘗試另一維度上的所有可能 a.可能是array的 i,j pointers,b.可能是矩形的長與寬,c.可能是tree的每乙個subtree,d.可能是情景題的每一對pair 求所有解的,暴力上backtracking吧 如果問最短 最少的,先想bfs dp這對好 ...