維度建模示例

2021-10-22 10:59:24 字數 2272 閱讀 3639

以庫存模組和零售模組這兩個模組來談一談維度建模的相關事項

梳理庫存業務中的表的構造與設計思想

梳理一下緩慢變化維的處理方法與優缺

這篇部落格計畫用週末來完成,只能簡單的討論一下建模概況,從維度建模這本書中摘錄出一些重要的知識點,對於維度建模這本書的報告計畫在5.1之前完成,希望結合具體的業務來分享一下

對庫存業務過程的梳理,我們發現有如下過程,向製造商發出購買訂單,倉庫庫存產品,商店庫存業務,零售業務

我們發現有如下重要的維度:商店,日期,產品 以及我們要建一張事實表來描述變化以及這張表應該有哪些屬性才能描述特徵和變化,(在此之前我們要考慮一張事實表是否能夠描述真正的業務過程與包含的資料域,以及如果採用一張表面臨的可迭代問題,維護性,缺陷)

我們建一張週期性快照表來描述我們的庫存(每天的交易資料是離散的),這張週期性快照表有如下的屬性:庫存數量 交易總量,價值(我們借助這張表能夠對企業庫存業務高效率運營,例如我們可以分析出那個地區某類書籍買的書最多,對商店的庫存進行區域優化),同時我們發現這張表每期更新只有80m的更新/新增(假設有100商店,60000的商品型別)

同時我們還要對倉庫的明細事務進行分析,我們考慮建立一張事實表,倉庫的事務可能包含如下步驟:

接收產品

將產品放入檢驗區

將產品從檢驗區提出

若檢驗存在問題則將產品返回**商

產品入庫

從庫中選擇產品

包裝產品

將產品運送給客戶

從客戶處接收產品

將客戶返回的產品

重新入庫

從庫存中刪除產品

我們可以考慮使用事務事實表來描述明細過程,但是對於庫存明細這種業務是多時間性質的,我們也可以採用累積快照表來描述明細的業務過程,如下:

倉庫庫存累積快照

累積快照表中的行的演進

事務事實表 週期性快照表 累積性快照表

不同事實表之間的比較

業務過程間共享維度

匯流排架構

零售商總體矩陣

支架表支架表是對雪花模型的改進,雖然沒有雪花模型的清晰性,但是避免了星型模型的複雜性,在維度表上連線一張支架表,節省了空間,支架表和微型維度其實差不多

支架表的示例

橋接表(難點)

橋接表示例

橋接表示例二

多對多和多值設定因子的處理方法

保留原始值

恆久值 常量

重寫無法捕獲歷史變化,適用於一些常量,過去的量時沒有統計的意義的,例如:生日等

增加新行

增加新行

設定行的失效和有效日期

增加新屬性

增加新屬性

不適應與多維資料庫

增加微型維度

微型維度示例

微型維度與重寫型別支架表

微型維度與重寫型別支架表

雙重型別一和型別二維度

雙重型別一和型別二維度

維度示例

現在在看一遍,還是不明白這種復合緩慢變化維有什麼特殊的作用

學習資料

識別下方二

維度建模步驟

資料模型是指用實體 屬性 實體之間的關係對業務概念和邏輯規則進行統一的定義,命名和編碼,主要描述企業的資訊需求和業務規則,是業務人員和開發人員溝通的語言,是資料倉儲架構設計工作開始的第一步。正確的資料模型是使用者需求的集中體現,是商業智慧型專案成功與否最重要的因素之一。資料模型可以分為概念模型 邏輯...

維度建模工具

幵始維度建模工作前,專案組需要理解業務需求,以及作為基礎的源資料的實際情況。通過與 ik務代表交流來發現需求,用於理解他們的基於關鍵效能指標 競爭性商業問題 決策制定過程 支援分析需求的目標。同時,資料實際情況可以通過與源系統專家交流,構建高層次資料分析訪問資料可行性來揭示。維度模型設計期間主要涉及...

維度建模步驟

原 2015年05月15日 10 50 00 資料模型是指用實體 屬性 實體之間的關係對業務概念和邏輯規則進行統一的定義,命名和編碼,主要描述企業的資訊需求和業務規則,是業務人員和開發人員溝通的語言,是資料倉儲架構設計工作開始的第一步。正確的資料模型是使用者需求的集中體現,是商業智慧型專案成功與否最...