三范式建模和維度建模,到底該選哪一個?
編輯導(dǎo)語:當(dāng)你需要從頭開始設(shè)計數(shù)據(jù)倉庫時,你會選擇哪種建模方式?也許,你會從三范式建模和維度建模二者中選擇。但是這二者有其各自的適用范圍,具體選擇哪種方法,還需要回歸至業(yè)務(wù)層。本篇文章里,作者對Inmon 方法和Kimball 方法做了對比分析,一起來看一下。
一、兩種建模方式的背景
在如何構(gòu)建數(shù)據(jù)倉庫方面,這兩種截然不同的思想流派:Inmon 方法和 Kimball 方法。他們的關(guān)鍵區(qū)別在于數(shù)據(jù)結(jié)構(gòu)如何建模、加載和存儲在數(shù)據(jù)倉庫中。這種差異會影響數(shù)據(jù)倉庫的交付時間以及適應(yīng) ETL 設(shè)計未來變化的能力。
當(dāng)數(shù)據(jù)架構(gòu)師被要求從頭開始設(shè)計和實現(xiàn)數(shù)據(jù)倉庫時,他或她應(yīng)該選擇哪種架構(gòu)風(fēng)格來構(gòu)建數(shù)據(jù)倉庫?如何幫助架構(gòu)師在 Inmon 或 Kimball 架構(gòu)之間做出選擇?
Inmon的三范式建模經(jīng)常被和Kimball 是維度數(shù)據(jù)經(jīng)常會被拿來對比,兩位大神也一直在秉持著自己的數(shù)據(jù)建模觀點。兩位大神有過非常有趣的觀點是, Kimball 曾經(jīng)說過:?“數(shù)據(jù)倉庫只不過是所有數(shù)據(jù)集市的聯(lián)合體”,對此 Inmon 的回應(yīng)是:“你可以捕獲海洋中的所有小魚并將它們聚在在一起——但是它們?nèi)匀徊荒艹蔀轹L魚”。
在典型的數(shù)據(jù)倉庫中,我們從一組 OLTP 數(shù)據(jù)源開始(關(guān)于OLTP的說明可見《秒懂?dāng)?shù)倉的前世今生:DBMS、DW、OLTP、OLAP到底是啥?(上篇)》)。這些可以是Excel 表格、ERP 系統(tǒng)、文件或基本上任何其他數(shù)據(jù)源。數(shù)據(jù)存儲在目標(biāo)環(huán)境后,使用 ETL 工具對數(shù)據(jù)進行處理和轉(zhuǎn)換,然后將其饋入數(shù)據(jù)倉庫。
Inmon 認為數(shù)據(jù)應(yīng)該在 ETL 過程之后直接送入數(shù)據(jù)倉庫。Kimball 則堅持認為,在 ETL 過程之后,數(shù)據(jù)應(yīng)該被加載到數(shù)據(jù)集市中,所有這些數(shù)據(jù)集市的聯(lián)合創(chuàng)建一個概念性的數(shù)據(jù)倉庫。
二、兩種建模方式的定義
從定義上來說,Inmon 構(gòu)建數(shù)據(jù)倉庫的方法始于企業(yè)級別的數(shù)據(jù)模型。該模型確定了關(guān)鍵主題領(lǐng)域,最關(guān)鍵的是構(gòu)建業(yè)務(wù)運營和關(guān)心的關(guān)鍵實體,如客戶、產(chǎn)品、供應(yīng)商等。
首先,從這個模型中,為每個主要實體創(chuàng)建了一個詳細的邏輯模型。例如,將客戶構(gòu)建一個邏輯模型,其中包含與該實體相關(guān)的所有詳細信息。
其次,客戶下可能有十個不同的實體。實體之間的對應(yīng)關(guān)系是如何建立的,在這一步驟中有很多的體現(xiàn)。包括業(yè)務(wù)鍵、屬性、依賴關(guān)系、參與和關(guān)系在內(nèi)的所有細節(jié)都將在詳細的邏輯模型中捕獲。這里的關(guān)鍵點是實體結(jié)構(gòu)是以規(guī)范化形式構(gòu)建的。盡可能避免數(shù)據(jù)冗余。這導(dǎo)致業(yè)務(wù)概念的清晰識別并避免數(shù)據(jù)更新異常。
最后,是構(gòu)建物理模型。數(shù)據(jù)倉庫的物理實現(xiàn)也被規(guī)范化。這就是 Inmon 所說的“數(shù)據(jù)倉庫”,這里是管理企業(yè)真實數(shù)據(jù)的地方。這種規(guī)范化模型使得加載數(shù)據(jù)不那么復(fù)雜,但是使用這種結(jié)構(gòu)進行查詢很困難,因為它涉及許多表和連接。
因此,Inmon 構(gòu)建特定于部門的數(shù)據(jù)集市。數(shù)據(jù)集市將專門為財務(wù)、銷售等設(shè)計,數(shù)據(jù)集市可以包含非規(guī)范化數(shù)據(jù)以幫助報告。任何進入數(shù)據(jù)倉庫的數(shù)據(jù)都是集成的,數(shù)據(jù)倉庫是不同數(shù)據(jù)集市的唯一數(shù)據(jù)源。這可確保數(shù)據(jù)的完整性和一致性在整個組織中保持完整。(詳細內(nèi)容可參考《數(shù)倉界的大神之Inmon數(shù)據(jù)倉庫建設(shè)(3范式建模)》)
接著,咱們來看下Kimball。
從定義上來看,Kmiball是維度建模的擁護者,提供一種方法去建立數(shù)倉,“對于數(shù)據(jù)的查詢和分析提供一種更為明確的數(shù)據(jù)結(jié)構(gòu)”。再經(jīng)過數(shù)據(jù)處理ETL后,就開始進行核心建模,維度建模中最關(guān)注的有兩項。
事實表的建設(shè):經(jīng)常也被成為度量,事實是可以體現(xiàn)業(yè)務(wù)流程中真實表現(xiàn)的數(shù)據(jù)。例如:對于銷售業(yè)務(wù)流程,最核心的體現(xiàn)是季度銷售金額;對于招聘流程,最核心的體現(xiàn)是招聘人數(shù);對于技術(shù)團隊,最核心的體現(xiàn)是開發(fā)了多少功能。
維度表的建設(shè):維度是經(jīng)常被大家說道的一個詞,其實維度更多的是一個視角,是從不同的角度去觀察和分析事實的一個方法。誰在那干啥?例如:以銷售流程為例,需要分析的維度有:誰買了商品——客戶名稱,在哪買了商品——售賣地點,買了啥商品——商品名稱??(詳細內(nèi)容可參考《清晰易懂!用5W2H方法進行維度建模,一篇搞定!》)。
三、兩個模型的多視角對比
四、兩個模型的適用范圍
每種方法都有各自的特點,并且會適用于不同的環(huán)境中。具體選擇哪種數(shù)據(jù)倉庫設(shè)計方法取決于組織的業(yè)務(wù)目標(biāo)、業(yè)務(wù)特性、時間、成本、不同組織單元之間的相互依賴級別。
Inmon 三范式建模的方法適合長期穩(wěn)定的業(yè)務(wù),所謂“長期穩(wěn)定”是指:
“時間方面,業(yè)務(wù)整體的數(shù)據(jù)建設(shè)可以經(jīng)得起長時間的打磨;成本方面,由于inmon建模需要專家團隊的支持,所以需要能接受較多的支出。”
Kimball維度建模的方法更加適合快速激進的業(yè)務(wù),所謂“快速基金”是指:
“時間方面,業(yè)務(wù)處于快速擴張要快速看到效果;成本方面,沒有較多較為專業(yè)的團隊來支持相關(guān)建設(shè)。”
我們可以拿兩個例子來解釋說明一下。
- 營銷:這是一個專業(yè)領(lǐng)域,我們不需要為了分析的目的考慮營銷的每個方面。因此,我們不需要企業(yè)倉庫——幾個數(shù)據(jù)集市就足夠了——也就是 Kimball 方法。
- 保險:為了根據(jù)未來的預(yù)測管理風(fēng)險,我們需要對所有投保人形成一個廣泛的圖景,由一系列數(shù)據(jù)組成,如盈利能力、歷史、人口統(tǒng)計等。所有這些方面都是相互關(guān)聯(lián)的,因此 Inmon 方法從倉庫中的所有數(shù)據(jù)開始,并根據(jù)需要對其進行過濾是兩者中最合適的。
- 市場:這是一個小的分支,并且業(yè)務(wù)場景較為簡單,無需進行企業(yè)級數(shù)倉建設(shè),只需要數(shù)據(jù)集市就夠了。因此,Kimball的方法比較適合。
- 銀行:銀行類的業(yè)務(wù)對于銀行產(chǎn)品和客戶信息都是非常關(guān)注,尤其是兩者的交叉分析,哪些人買了啥銀行產(chǎn)品。這些數(shù)據(jù)會有相關(guān)的限制,例如:產(chǎn)品和客戶的信息不可給市場和財務(wù)部門公開,部門與部門之間的數(shù)據(jù)會有限制,這種情況下只能采用Kimball的方法;如果銀行中的整個流程和部門相互關(guān)聯(lián),這種情況下使用Inmon會更好一些
- 制造業(yè):會涉及到多個組織單元,且預(yù)算比較充裕。這種情況沒有系統(tǒng)依賴,因而需要企業(yè)模型,這時還是Inmon的方法比較理想。
在設(shè)計數(shù)據(jù)倉庫時,首先要先看看業(yè)務(wù)目標(biāo)——短期目標(biāo)和長期目標(biāo)??纯垂δ苤g哪里有聯(lián)系,什么是獨立的。分析數(shù)據(jù)源的數(shù)量和質(zhì)量。最后,評估你的資源級別、時間和經(jīng)費。這能幫助你判斷用Inmon方法還是用Kimball方法,或者是兩種方法的組合。
本文由 @業(yè)務(wù)數(shù)智化 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自 Unsplash,基于CC0協(xié)議
- 目前還沒評論,等你發(fā)揮!