試象一下，你是一家繁忙餐廳的分析工程師。每天，顧客都會預(yù)訂、下訂單并完成付款。所有這些數(shù)據(jù)都會流入餐廳的交易數(shù)據(jù)庫，記錄每次互動的詳細信息。

但是，事務(wù)型數(shù)據(jù)庫雖然非常適合日常運營，但并不適合分析數(shù)據(jù)以發(fā)現(xiàn)有助于業(yè)務(wù)增長的趨勢和見解。這就是數(shù)據(jù)倉庫的作用所在。數(shù)據(jù)倉庫是一個單獨的數(shù)據(jù)庫，經(jīng)過優(yōu)化，可用于存儲大量歷史數(shù)據(jù)以及快速查詢和分析。

挑戰(zhàn)在于如何構(gòu)建倉庫中的數(shù)據(jù)，以便進行高效分析，同時保持足夠的靈活性以應(yīng)對不斷變化的業(yè)務(wù)需求。數(shù)據(jù)倉庫中的數(shù)據(jù)建模有幾種常見和不太常見的方法。在本文中，我們將介紹七種關(guān)鍵的建模技術(shù)，權(quán)衡它們的優(yōu)缺點，并幫助您為數(shù)據(jù)倉庫選擇正確的方法。

一、事務(wù)數(shù)據(jù)庫示例

在深入研究數(shù)據(jù)倉庫建模之前，讓我們簡單看一下餐廳的典型事務(wù)數(shù)據(jù)庫可能包含哪些內(nèi)容：

• 包含姓名、電子郵件、電話號碼等詳細信息的客戶表
• 預(yù)訂表，包括預(yù)訂日期、時間、團體規(guī)模等
• 帶有描述的產(chǎn)品表，鏈接到產(chǎn)品價格和產(chǎn)品組表
• 訂單表將顧客與他們所選的菜單項聯(lián)系起來
• 訂單明細表，其中包含每個訂單的每個菜單項的數(shù)量
• 包含總額、付款方式等的付款表。

交易數(shù)據(jù)庫使用針對處理交易進行優(yōu)化的規(guī)范化結(jié)構(gòu)。但這種結(jié)構(gòu)使分析和報告更加困難。數(shù)據(jù)倉庫建模方法對數(shù)據(jù)進行非規(guī)范化和重組，以優(yōu)化整合層中的分析，同時仍便于快速寫入加工層。

二、數(shù)據(jù)倉庫建模方法

1.第三范式（3NF）

第三范式 (3NF) 是一種經(jīng)典的關(guān)系數(shù)據(jù)庫建模方法，可最大限度地減少數(shù)據(jù)冗余。在 3NF 中，每個非鍵列僅依賴于表的主鍵。

將 3NF 應(yīng)用于我們的餐廳數(shù)據(jù)倉庫，我們將進一步分離表格，這樣各個表格結(jié)構(gòu)中就不會有層次結(jié)構(gòu)，而是作為表格鏈接的層次結(jié)構(gòu)。訂單和付款等交易表將引用元數(shù)據(jù)表的主鍵，而元數(shù)據(jù)表又將引用更高級別的元數(shù)據(jù)表。

本質(zhì)上，我們要做的改變是確定客戶表包含地址詳細信息，這是自然層次結(jié)構(gòu)。然后，我們會將它們拆分為組件表。通常，您不會將此方法用于整合層，但它可能適用于加工層。如果您正在提取可能以不同粒度級別本機構(gòu)建的多個源，則尤其如此。

3NF 實體關(guān)系數(shù)據(jù)庫

優(yōu)點：

• 減少數(shù)據(jù)冗余，節(jié)省存儲空間
• 通過主鍵關(guān)系保證數(shù)據(jù)完整性
• 提供靈活性以適應(yīng)未來的變化

缺點：

• 可能需要進行許多表連接進行分析，從而影響查詢性能
• 對于業(yè)務(wù)用戶來說，理解和操作起來可能很復(fù)雜

2.Kimball 星型模式

Kimball 星型模式是數(shù)據(jù)倉庫中的一個關(guān)鍵概念，由數(shù)據(jù)倉庫和商業(yè)智能領(lǐng)域的杰出人物 Ralph Kimball 提出。它旨在簡化數(shù)據(jù)存儲并提高查詢性能，使復(fù)雜的數(shù)據(jù)結(jié)構(gòu)更易于管理并更易于進行業(yè)務(wù)分析。

關(guān)鍵部件

1. 事實表：事實表是星型模式的核心，包含定量數(shù)據(jù)，例如銷售額、交易次數(shù)和其他可衡量指標(biāo)。事實表中的每條記錄都對應(yīng)一個特定事件或交易，并包含鏈接到維度表的外鍵。由于它保存的交易數(shù)據(jù)量很大，因此該表通常很大。通常，它包括銷售額、銷售量和成本等數(shù)值度量，以及引用維度表的鍵。
2. 維度表：維度表是為事實表中的數(shù)據(jù)提供上下文的外圍表。它們包含與業(yè)務(wù)維度相關(guān)的描述性屬性，例如時間段、地理位置、產(chǎn)品、客戶和員工。與事實表相比，維度表通常更小且更靜態(tài)。它們以非規(guī)范化形式存儲數(shù)據(jù)以簡化查詢，使其更易于理解和導(dǎo)航。

結(jié)構(gòu)和設(shè)計

星型模式因其布局類似星星而得名。事實表位于中心，周圍是維度表，每個維度表都通過外鍵連接到事實表。這種設(shè)計非常直觀，允許用戶在事實表和維度表之間執(zhí)行直接連接。

在我們的餐廳示例中，我們將有一個中央訂單事實表，其中包含客戶、日期、產(chǎn)品等維度表的外鍵。維度表包含冗余、非規(guī)范化的數(shù)據(jù)，以避免進一步連接。這是倉庫中整合層或表示層的一種相當(dāng)標(biāo)準(zhǔn)的方法。

訂單數(shù)據(jù)的星型模式 ERD

優(yōu)點：

• 通過最小化連接來優(yōu)化快速查詢
• 對于熟悉業(yè)務(wù)流程的業(yè)務(wù)用戶來說很直觀
• 聚合計算簡單

缺點：

• 非規(guī)范化增加了數(shù)據(jù)冗余
• 處理緩慢變化的維度可能很棘手
• 適應(yīng)未來變化的靈活性較差

3.雪花模式

雪花模式是數(shù)據(jù)倉庫中星型模式的一種變體，旨在處理復(fù)雜且高度規(guī)范化的數(shù)據(jù)結(jié)構(gòu)。該模式因其復(fù)雜的雪花狀形狀而得名，它將數(shù)據(jù)組織到多個相關(guān)表中，從而增強了數(shù)據(jù)完整性并減少了冗余。然而，這會增加查詢編寫的復(fù)雜性并可能影響性能。它幾乎可以看作是星型模式和 3NF 的混合體。

關(guān)鍵部件

1. 事實表：事實表仍然是雪花模式中的中心表，包含定量數(shù)據(jù)，例如銷售額、收入或其他業(yè)務(wù)指標(biāo)。它包含維度表的外鍵，為事實提供背景信息。事實表中的每條記錄代表一個可測量的事件，并包括數(shù)值度量和鏈接到相關(guān)維度的外鍵。
2. 維度表：與星型模式不同，雪花模式進一步規(guī)范化了維度表。每個維度表都可以分解為多個相關(guān)表，從而創(chuàng)建更規(guī)范的結(jié)構(gòu)。例如，我們的客戶維度將地址拆分為郵政編碼、城市和州表，每個表都通過外鍵鏈接。這種規(guī)范化減少了數(shù)據(jù)冗余，但增加了查詢所需的連接數(shù)。

結(jié)構(gòu)和設(shè)計

雪花模式由于其多級結(jié)構(gòu)而類似于雪花。維度表被規(guī)范化為多個相關(guān)表，分散成復(fù)雜的網(wǎng)狀結(jié)構(gòu)。這種設(shè)計旨在通過消除冗余來節(jié)省存儲空間并提高數(shù)據(jù)完整性。

訂單數(shù)據(jù)的雪花模式

優(yōu)點：

• 與星型模式相比，減少了數(shù)據(jù)冗余
• 通過規(guī)范化確保數(shù)據(jù)完整性
• 使維度表更易于維護

缺點：

• 與星型模式相比，可能需要更多連接，從而影響查詢性能
• 商業(yè)用戶更難理解和駕馭

4.寬表 (OBT)

One-Big-Table (OBT) 設(shè)計，也稱為平面表或?qū)挶恚且环N數(shù)據(jù)倉庫方法，其中所有數(shù)據(jù)都合并到單個非規(guī)范化表中。這種方法與星型和雪花型等規(guī)范化模式形成鮮明對比，它提供了更簡單的結(jié)構(gòu)，但代價是冗余度增加，并且在處理非常大的數(shù)據(jù)集時可能會出現(xiàn)性能問題。

關(guān)鍵部件

1. 單表：OBT 設(shè)計的核心特征是所有相關(guān)數(shù)據(jù)都存儲在一個綜合表中。該表包含大量列，可捕獲分析所需的所有屬性和度量。該表可能包含數(shù)千列，每行代表一條包含多個維度和指標(biāo)的唯一記錄。
2. 屬性和指標(biāo)：在 OBT 設(shè)計中，屬性（通常在其他模式的維度表中找到）和指標(biāo)（通常在事實表中找到）被組合到單個表中。例如，客戶詳細信息、產(chǎn)品信息和銷售數(shù)據(jù)都將存儲在同一張表中，每條記錄都提供交易或事件的完整快照。

結(jié)構(gòu)和設(shè)計

OBT 設(shè)計的結(jié)構(gòu)非常簡單，只包含一個表，其中每行包含所有必要的數(shù)據(jù)點。這種扁平結(jié)構(gòu)無需連接，用戶無需了解復(fù)雜的表關(guān)系即可輕松查詢和檢索數(shù)據(jù)。

對于我們的餐廳，我們將為三個關(guān)鍵事件（預(yù)訂、訂單和付款）分別設(shè)置一個大表。我看到過一些關(guān)于 OBT 還是星型模式是更好的方法的相當(dāng)激烈的爭論。答案是“視情況而定”。如果您將數(shù)據(jù)拉入 Power BI，它將需要星型模式樣式的數(shù)據(jù)集。但是，如果您將數(shù)據(jù)拉入 Tableau，您可能更喜歡 OBT 方法。但應(yīng)該注意的是，如果您確實選擇 OBT，則應(yīng)將任何可重復(fù)使用的邏輯保留在可以反復(fù)引用的支持表中。

OBT 示例

優(yōu)點：

• 極快的查詢性能，無需連接
• 所有數(shù)據(jù)都集中在一處，簡單易懂
• 適合數(shù)據(jù)科學(xué)消費

缺點：

• 數(shù)據(jù)冗余度高，需要大量存儲空間
• 如果不改變整個表結(jié)構(gòu)，就很難做出改變
• 包含許多列的查詢可能難以編寫和維護

5.數(shù)據(jù)倉庫 2.0

Data Vault 2.0 是一種現(xiàn)代數(shù)據(jù)倉庫方法，旨在提供可擴展、靈活且可審計的數(shù)據(jù)模型。它由 Dan Linstedt 開發(fā)，以原始 Data Vault 方法為基礎(chǔ)，對其進行了增強，以更好地支持當(dāng)今復(fù)雜的數(shù)據(jù)環(huán)境。Data Vault 2.0 滿足了處理大數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)和各種數(shù)據(jù)源的需求，同時保持了數(shù)據(jù)完整性和歷史準(zhǔn)確性。與 3NF 一樣，這將位于您的銀層。這不是您指向 BI 工具的東西。

關(guān)鍵部件

1. 樞紐：樞紐存儲具有唯一代理鍵和元數(shù)據(jù)（如加載日期和源信息）的唯一業(yè)務(wù)鍵。每個樞紐代表一個核心業(yè)務(wù)概念，例如客戶、產(chǎn)品或訂單。樞紐高度穩(wěn)定且很少發(fā)生變化，為數(shù)據(jù)倉庫提供一致的參考點。
2. 鏈接：鏈接捕獲存儲在中心中的業(yè)務(wù)鍵之間的關(guān)系。每個鏈接表包含相關(guān)中心的外鍵以及元數(shù)據(jù)。鏈接表示實體之間的事務(wù)、關(guān)聯(lián)或?qū)哟谓Y(jié)構(gòu)。它們用于對多對多關(guān)系以及關(guān)系隨時間的變化進行建模。
3. 衛(wèi)星：衛(wèi)星存儲中心中業(yè)務(wù)鍵或鏈接中關(guān)系的描述性屬性和上下文。它們包括用于跟蹤隨時間變化的元數(shù)據(jù)，例如加載日期和來源。衛(wèi)星可以在不影響核心業(yè)務(wù)鍵和關(guān)系的情況下發(fā)展，從而可以靈活地適應(yīng)新的業(yè)務(wù)需求。

結(jié)構(gòu)和設(shè)計

Data Vault 2.0 采用模塊化架構(gòu)設(shè)計，將數(shù)據(jù)存儲分為這三種類型的表，從而提高可擴展性和靈活性。集線器、鏈路和衛(wèi)星被設(shè)計為增量和并行加載，從而可以高效處理大量數(shù)據(jù)和隨時間變化的數(shù)據(jù)。

數(shù)據(jù)倉庫 ERD 示例

優(yōu)點：

• 旨在應(yīng)對業(yè)務(wù)需求隨時間的變化
• 將結(jié)構(gòu)變化與信息變化分開
• 提供可追溯性并保存歷史記錄

缺點：

• 設(shè)計和實施起來可能很復(fù)雜
• 需要許多表格和連接來匯總數(shù)據(jù)進行分析
• 查詢可能難以編寫和理解

6.活動模式

活動模式是 Ahmed Elsamadisi 設(shè)計的一種數(shù)據(jù)倉庫方法，用于以結(jié)構(gòu)化和高效的方式捕獲業(yè)務(wù)活動或事件的詳細記錄。此模式側(cè)重于記錄企業(yè)內(nèi)部執(zhí)行的操作或交易，因此對于事件驅(qū)動數(shù)據(jù)和詳細交易日志記錄特別有用。它已用于需要跟蹤大量細粒度事件的系統(tǒng)，例如電子商務(wù)網(wǎng)站、金融系統(tǒng)或物聯(lián)網(wǎng)應(yīng)用程序。

關(guān)鍵部件

1. 活動表：活動模式中的中心表是活動表，它記錄每個業(yè)務(wù)活動或事件?；顒颖碇械拿恳恍写韱蝹€事件或交易，捕獲有關(guān)發(fā)生了什么、何時發(fā)生以及其他相關(guān)背景的詳細信息。此表屬性已定義為標(biāo)準(zhǔn)的一部分，因此易于實現(xiàn)。
2. 維度表：活動表附帶一個可選維度表，該維度表為活動表中記錄的事件提供額外的背景信息。維度可能包括有關(guān)客戶、產(chǎn)品、位置、時間和其他相關(guān)實體的詳細信息，具體取決于它所涉及的活動流。

在我們的餐廳示例中，我們可能有一個帶有相關(guān)客戶維度的客戶活動表?；顒颖韺⒏櫩蛻舻幕顒?，例如他們的預(yù)訂、訂單和付款。這些活動的詳細信息保存在列中feature_json，并有一個可選列用于存儲相關(guān)的收入影響。

活動架構(gòu)示例

優(yōu)點：

• 設(shè)計簡單直觀，表格數(shù)量極少
• 無需更改架構(gòu)即可捕獲實體的其他活動
• 僅當(dāng)需要跟蹤新實體時才需要新表

缺點：

• 相對較新的方法，尚未被廣泛采用
• 可能不適合所有業(yè)務(wù)領(lǐng)域和分析需求

7.以實體為中心的建模

以實體為中心的建模是一種靈活的方法，由 Maxime Beauchemin 提出，專注于圍繞客戶和產(chǎn)品等實體進行建模。每個實體都有自己的表，使用 JSON 來跟蹤包括聚合在內(nèi)的各種指標(biāo)。這種方法不需要額外的維度表，因為實體表位于實體的最低粒度，并且可以直接在表中包含其屬性。

在餐廳環(huán)境中，我們會有一個客戶表，其中包含客戶屬性列，加上一個 json 列來保存時間綁定指標(biāo)，例如visit.7d，，visit.14d。sale.30d

以實體為中心的建模

優(yōu)點：

• 靈活適應(yīng)不斷變化的業(yè)務(wù)需求
• 只需少量表格即可輕松理解
• 在指標(biāo)欄內(nèi)有效捕捉歷史記錄

缺點：

• 查詢可能很復(fù)雜，通常需要解除半結(jié)構(gòu)化數(shù)據(jù)的嵌套
• 實體具有重疊屬性或行為類型時的挑戰(zhàn)
• 與星型模式相比，更難實施完整性約束

三、選擇正確的建模方法

考慮到這七種常見的數(shù)據(jù)倉庫建模方法，如何為您的數(shù)據(jù)倉庫選擇正確的方法？請考慮以下因素：

• 分析要求：您需要回答哪些類型的問題？選擇針對這些查詢模式進行優(yōu)化的模型。
• 數(shù)據(jù)量和可擴展性：考慮您現(xiàn)在擁有的數(shù)據(jù)量以及未來預(yù)期的數(shù)據(jù)量。有些方法的可擴展性優(yōu)于其他方法。
• 易用性：考慮誰將查詢數(shù)據(jù)倉庫。有些模型對于非技術(shù)用戶來說更直觀。
• 靈活性：您的業(yè)務(wù)可能會不斷發(fā)展。選擇能夠適應(yīng)不斷變化的需求的模型。
• 性能：考慮查詢速度和數(shù)據(jù)冗余之間的權(quán)衡。非規(guī)范化模型通常速度更快，但需要更多存儲空間。

最后，“正確”的數(shù)據(jù)倉庫建模方法取決于您獨特的業(yè)務(wù)需求和優(yōu)先事項。通過了解每種建模技術(shù)的優(yōu)勢和劣勢，您可以設(shè)計一個數(shù)據(jù)倉庫，提供快速、靈活且富有洞察力的分析，以推動公司發(fā)展。