三正規化建模和維度建模,到底該選哪一個?

編輯導語:當你需要從頭開始設計資料倉庫時,你會選擇哪種建模方式?也許,你會從三正規化建模和維度建模二者中選擇。但是這二者有其各自的適用範圍,具體選擇哪種方法,還需要回歸至業務層。本篇文章裡,作者對Inmon 方法和Kimball 方法做了對比分析,一起來看一下。

三正規化建模和維度建模,到底該選哪一個?

一、兩種建模方式的背景

在如何構建資料倉庫方面,這兩種截然不同的思想流派:Inmon 方法和 Kimball 方法。他們的關鍵區別在於資料結構如何建模、載入和儲存在資料倉庫中。這種差異會影響資料倉庫的交付時間以及適應 ETL 設計未來變化的能力。

當資料架構師被要求從頭開始設計和實現資料倉庫時,他或她應該選擇哪種架構風格來構建資料倉庫?如何幫助架構師在 Inmon 或 Kimball 架構之間做出選擇?

Inmon的三正規化建模經常被和Kimball 是維度資料經常會被拿來對比,兩位大神也一直在秉持著自己的資料建模觀點。兩位大神有過非常有趣的觀點是, Kimball 曾經說過: “資料倉庫只不過是所有資料集市的聯合體”,對此 Inmon 的迴應是:“你可以捕獲海洋中的所有小魚並將它們聚在在一起——但是它們仍然不能成為鯨魚”。

在典型的資料倉庫中,我們從一組 OLTP 資料來源開始(關於OLTP的說明可見《秒懂數倉的前世今生:DBMS、DW、OLTP、OLAP到底是啥?(上篇)》)。這些可以是Excel 表格、ERP 系統、檔案或基本上任何其他資料來源。資料儲存在目標環境後,使用 ETL 工具對資料進行處理和轉換,然後將其饋入資料倉庫。

Inmon 認為資料應該在 ETL 過程之後直接送入資料倉庫。Kimball 則堅持認為,在 ETL 過程之後,資料應該被載入到資料集市中,所有這些資料集市的聯合建立一個概念性的資料倉庫。

三正規化建模和維度建模,到底該選哪一個?

二、兩種建模方式的定義

從定義上來說,Inmon 構建資料倉庫的方法始於企業級別的資料模型。該模型確定了關鍵主題領域,最關鍵的是構建業務運營和關心的關鍵實體,如客戶、產品、供應商等。

首先,從這個模型中,為每個主要實體建立了一個詳細的邏輯模型。例如,將客戶構建一個邏輯模型,其中包含與該實體相關的所有詳細資訊。

其次,客戶下可能有十個不同的實體。實體之間的對應關係是如何建立的,在這一步驟中有很多的體現。包括業務鍵、屬性、依賴關係、參與和關係在內的所有細節都將在詳細的邏輯模型中捕獲。這裡的關鍵點是實體結構是以規範化形式構建的。儘可能避免資料冗餘。這導致業務概念的清晰識別並避免資料更新異常。

最後,是構建物理模型。資料倉庫的物理實現也被規範化。這就是 Inmon 所說的“資料倉庫”,這裡是管理企業真實資料的地方。這種規範化模型使得載入資料不那麼複雜,但是使用這種結構進行查詢很困難,因為它涉及許多表和連線。

因此,Inmon 構建特定於部門的資料集市。資料集市將專門為財務、銷售等設計,資料集市可以包含非規範化資料以幫助報告。任何進入資料倉庫的資料都是整合的,資料倉庫是不同資料集市的唯一資料來源。這可確保資料的完整性和一致性在整個組織中保持完整。(詳細內容可參考《數倉界的大神之Inmon資料倉庫建設(3正規化建模)》)

接著,咱們來看下Kimball。

從定義上來看,Kmiball是維度建模的擁護者,提供一種方法去建立數倉,“對於資料的查詢和分析提供一種更為明確的資料結構”。再經過資料處理ETL後,就開始進行核心建模,維度建模中最關注的有兩項。

事實表的建設:經常也被成為度量,事實是可以體現業務流程中真實表現的資料。例如:對於銷售業務流程,最核心的體現是季度銷售金額;對於招聘流程,最核心的體現是招聘人數;對於技術團隊,最核心的體現是開發了多少功能。

維度表的建設:維度是經常被大家說道的一個詞,其實維度更多的是一個視角,是從不同的角度去觀察和分析事實的一個方法。誰在那幹啥?例如:以銷售流程為例,需要分析的維度有:誰買了商品——客戶名稱,在哪買了商品——售賣地點,買了啥商品——商品名稱 。

三、兩個模型的多視角對比

三正規化建模和維度建模,到底該選哪一個?

四、兩個模型的適用範圍

每種方法都有各自的特點,並且會適用於不同的環境中。具體選擇哪種資料倉庫設計方法取決於組織的業務目標、業務特性、時間、成本、不同組織單元之間的相互依賴級別。

Inmon 三正規化建模的方法適合長期穩定的業務,所謂“長期穩定”是指:

“時間方面,業務整體的資料建設可以經得起長時間的打磨;成本方面,由於inmon建模需要專家團隊的支援,所以需要能接受較多的支出。”

Kimball維度建模的方法更加適合快速激進的業務,所謂“快速基金”是指:

“時間方面,業務處於快速擴張要快速看到效果;成本方面,沒有較多較為專業的團隊來支援相關建設。”

我們可以拿兩個例子來解釋說明一下。

營銷:這是一個專業領域,我們不需要為了分析的目的考慮營銷的每個方面。因此,我們不需要企業倉庫——幾個資料集市就足夠了——也就是 Kimball 方法。

保險:為了根據未來的預測管理風險,我們需要對所有投保人形成一個廣泛的圖景,由一系列資料組成,如盈利能力、歷史、人口統計等。所有這些方面都是相互關聯的,因此 Inmon 方法從倉庫中的所有資料開始,並根據需要對其進行過濾是兩者中最合適的。

市場:這是一個小的分支,並且業務場景較為簡單,無需進行企業級數倉建設,只需要資料集市就夠了。因此,Kimball的方法比較適合。

銀行:銀行類的業務對於銀行產品和客戶資訊都是非常關注,尤其是兩者的交叉分析,哪些人買了啥銀行產品。這些資料會有相關的限制,例如:產品和客戶的資訊不可給市場和財務部門公開,部門與部門之間的資料會有限制,這種情況下只能採用Kimball的方法;如果銀行中的整個流程和部門相互關聯,這種情況下使用Inmon會更好一些

製造業:會涉及到多個組織單元,且預算比較充裕。這種情況沒有系統依賴,因而需要企業模型,這時還是Inmon的方法比較理想。

在設計資料倉庫時,首先要先看看業務目標——短期目標和長期目標。看看功能之間哪裡有聯絡,什麼是獨立的。分析資料來源的數量和質量。最後,評估你的資源級別、時間和經費。這能幫助你判斷用Inmon方法還是用Kimball方法,或者是兩種方法的組合。

本文由 @資料產品高遠 原創釋出於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於CC0協議

頂部