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

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

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

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

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

包含姓名、電子郵件、電話號碼等詳細信息的客戶表

預訂表，包括預訂日期、時間、團體規(guī)模等

帶有描述的產(chǎn)品表，鏈接到產(chǎn)品價格和產(chǎn)品組表

訂單表將顧客與他們所選的菜單項聯(lián)系起來

訂單明細表，其中包含每個訂單的每個菜單項的數(shù)量

包含總額、付款方式等的付款表。

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

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

1.第三范式(3NF)

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

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

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

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

優(yōu)點：

減少數(shù)據(jù)冗余，節(jié)省存儲空間

通過主鍵關系保證數(shù)據(jù)完整性

提供靈活性以適應未來的變化

缺點：

可能需要進行許多表連接進行分析，從而影響查詢性能

對于業(yè)務用戶來說，理解和操作起來可能很復雜

2.Kimball星型模式

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

關鍵部件

事實表：事實表是星型模式的核心，包含定量數(shù)據(jù)，例如銷售額、交易次數(shù)和其他可衡量指標。事實表中的每條記錄都對應一個特定事件或交易，并包含鏈接到維度表的外鍵。由于它保存的交易數(shù)據(jù)量很大，因此該表通常很大。通常，它包括銷售額、銷售量和成本等數(shù)值度量，以及引用維度表的鍵。

維度表：維度表是為事實表中的數(shù)據(jù)提供上下文的外圍表。它們包含與業(yè)務維度相關的描述性屬性，例如時間段、地理位置、產(chǎn)品、客戶和員工。與事實表相比，維度表通常更小且更靜態(tài)。它們以非規(guī)范化形式存儲數(shù)據(jù)以簡化查詢，使其更易于理解和導航。

結構和設計

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

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

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

優(yōu)點：

通過最小化連接來優(yōu)化快速查詢

對于熟悉業(yè)務流程的業(yè)務用戶來說很直觀

聚合計算簡單

缺點：

非規(guī)范化增加了數(shù)據(jù)冗余

處理緩慢變化的維度可能很棘手

適應未來變化的靈活性較差

3.雪花模式

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

關鍵部件

事實表：事實表仍然是雪花模式中的中心表，包含定量數(shù)據(jù)，例如銷售額、收入或其他業(yè)務指標。它包含維度表的外鍵，為事實提供背景信息。事實表中的每條記錄代表一個可測量的事件，并包括數(shù)值度量和鏈接到相關維度的外鍵。

維度表：與星型模式不同，雪花模式進一步規(guī)范化了維度表。每個維度表都可以分解為多個相關表，從而創(chuàng)建更規(guī)范的結構。例如，我們的客戶維度將地址拆分為郵政編碼、城市和州表，每個表都通過外鍵鏈接。這種規(guī)范化減少了數(shù)據(jù)冗余，但增加了查詢所需的連接數(shù)。

結構和設計

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

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

優(yōu)點：

與星型模式相比，減少了數(shù)據(jù)冗余

通過規(guī)范化確保數(shù)據(jù)完整性

使維度表更易于維護

缺點：

與星型模式相比，可能需要更多連接，從而影響查詢性能

商業(yè)用戶更難理解和駕馭

4.寬表 (OBT)

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

關鍵部件

單表：OBT 設計的核心特征是所有相關數(shù)據(jù)都存儲在一個綜合表中。該表包含大量列，可捕獲分析所需的所有屬性和度量。該表可能包含數(shù)千列，每行代表一條包含多個維度和指標的唯一記錄。

屬性和指標：在 OBT 設計中，屬性(通常在其他模式的維度表中找到)和指標(通常在事實表中找到)被組合到單個表中。例如，客戶詳細信息、產(chǎn)品信息和銷售數(shù)據(jù)都將存儲在同一張表中，每條記錄都提供交易或事件的完整快照。

結構和設計

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

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

OBT 示例

優(yōu)點：

極快的查詢性能，無需連接

所有數(shù)據(jù)都集中在一處，簡單易懂

適合數(shù)據(jù)科學消費

缺點：

數(shù)據(jù)冗余度高，需要大量存儲空間

如果不改變整個表結構，就很難做出改變

包含許多列的查詢可能難以編寫和維護

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

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

關鍵部件

樞紐：樞紐存儲具有唯一代理鍵和元數(shù)據(jù)(如加載日期和源信息)的唯一業(yè)務鍵。每個樞紐代表一個核心業(yè)務概念，例如客戶、產(chǎn)品或訂單。樞紐高度穩(wěn)定且很少發(fā)生變化，為數(shù)據(jù)倉庫提供一致的參考點。

鏈接：鏈接捕獲存儲在中心中的業(yè)務鍵之間的關系。每個鏈接表包含相關中心的外鍵以及元數(shù)據(jù)。鏈接表示實體之間的事務、關聯(lián)或?qū)哟谓Y構。它們用于對多對多關系以及關系隨時間的變化進行建模。

衛(wèi)星：衛(wèi)星存儲中心中業(yè)務鍵或鏈接中關系的描述性屬性和上下文。它們包括用于跟蹤隨時間變化的元數(shù)據(jù)，例如加載日期和來源。衛(wèi)星可以在不影響核心業(yè)務鍵和關系的情況下發(fā)展，從而可以靈活地適應新的業(yè)務需求。

結構和設計

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

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

優(yōu)點：

旨在應對業(yè)務需求隨時間的變化

將結構變化與信息變化分開

提供可追溯性并保存歷史記錄

缺點：

設計和實施起來可能很復雜

需要許多表格和連接來匯總數(shù)據(jù)進行分析

查詢可能難以編寫和理解

6.活動模式

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

關鍵部件

活動表：活動模式中的中心表是活動表，它記錄每個業(yè)務活動或事件。活動表中的每一行代表單個事件或交易，捕獲有關發(fā)生了什么、何時發(fā)生以及其他相關背景的詳細信息。此表屬性已定義為標準的一部分，因此易于實現(xiàn)。

維度表：活動表附帶一個可選維度表，該維度表為活動表中記錄的事件提供額外的背景信息。維度可能包括有關客戶、產(chǎn)品、位置、時間和其他相關實體的詳細信息，具體取決于它所涉及的活動流。

在我們的餐廳示例中，我們可能有一個帶有相關客戶維度的客戶活動表?；顒颖韺⒏櫩蛻舻幕顒樱缢麄兊念A訂、訂單和付款。這些活動的詳細信息保存在列中feature_json，并有一個可選列用于存儲相關的收入影響。

活動架構示例

優(yōu)點：

設計簡單直觀，表格數(shù)量極少

無需更改架構即可捕獲實體的其他活動

僅當需要跟蹤新實體時才需要新表

缺點：

相對較新的方法，尚未被廣泛采用

可能不適合所有業(yè)務領域和分析需求

7.以實體為中心的建模

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

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

以實體為中心的建模

優(yōu)點：

靈活適應不斷變化的業(yè)務需求

只需少量表格即可輕松理解

在指標欄內(nèi)有效捕捉歷史記錄

缺點：

查詢可能很復雜，通常需要解除半結構化數(shù)據(jù)的嵌套

實體具有重疊屬性或行為類型時的挑戰(zhàn)

與星型模式相比，更難實施完整性約束

三、選擇正確的建模方法

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

分析要求：您需要回答哪些類型的問題?選擇針對這些查詢模式進行優(yōu)化的模型。

數(shù)據(jù)量和可擴展性：考慮您現(xiàn)在擁有的數(shù)據(jù)量以及未來預期的數(shù)據(jù)量。有些方法的可擴展性優(yōu)于其他方法。

易用性：考慮誰將查詢數(shù)據(jù)倉庫。有些模型對于非技術用戶來說更直觀。

靈活性：您的業(yè)務可能會不斷發(fā)展。選擇能夠適應不斷變化的需求的模型。

性能：考慮查詢速度和數(shù)據(jù)冗余之間的權衡。非規(guī)范化模型通常速度更快，但需要更多存儲空間。

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