編輯導語：當你需要從頭開始設計數據倉庫時，你會選擇哪種建模方式？也許，你會從三範式建模和維度建模二者中選擇。但是這二者有其各自的适用範圍，具體選擇哪種方法，還需要回歸至業務層。本篇文章裡，作者對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協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部