數據倉庫中的七種建模方法及示例
試象一下，你是一家繁忙餐廳的分析工程師。每天，顧客都會預訂、下訂單并完成付款。所有這些數據都會流入餐廳的交易數據庫，記錄每次互動的詳細信息。
但是，事務型數據庫雖然非常適合日常運營，但并不適合分析數據以發現有助于業務增長的趨勢和見解。這就是數據倉庫的作用所在。數據倉庫是一個單獨的數據庫，經過優化，可用于存儲大量歷史數據以及快速查詢和分析。
挑戰在于如何構建倉庫中的數據，以便進行高效分析，同時保持足夠的靈活性以應對不斷變化的業務需求。數據倉庫中的數據建模有幾種常見和不太常見的方法。在本文中，我們將介紹七種關鍵的建模技術，權衡它們的優缺點，并幫助您為數據倉庫選擇正確的方法。
一、事務數據庫示例
在深入研究數據倉庫建模之前，讓我們簡單看一下餐廳的典型事務數據庫可能包含哪些內容：
- 包含姓名、電子郵件、電話號碼等詳細信息的客戶表
- 預訂表，包括預訂日期、時間、團體規模等
- 帶有描述的產品表，鏈接到產品價格和產品組表
- 訂單表將顧客與他們所選的菜單項聯系起來
- 訂單明細表，其中包含每個訂單的每個菜單項的數量
- 包含總額、付款方式等的付款表。
交易數據庫使用針對處理交易進行優化的規范化結構。但這種結構使分析和報告更加困難。數據倉庫建模方法對數據進行非規范化和重組，以優化整合層中的分析，同時仍便于快速寫入加工層。
二、數據倉庫建模方法
1.第三范式（3NF）
第三范式 (3NF) 是一種經典的關系數據庫建模方法，可最大限度地減少數據冗余。在 3NF 中，每個非鍵列僅依賴于表的主鍵。
將 3NF 應用于我們的餐廳數據倉庫，我們將進一步分離表格，這樣各個表格結構中就不會有層次結構，而是作為表格鏈接的層次結構。訂單和付款等交易表將引用元數據表的主鍵，而元數據表又將引用更高級別的元數據表。
本質上，我們要做的改變是確定客戶表包含地址詳細信息，這是自然層次結構。然后，我們會將它們拆分為組件表。通常，您不會將此方法用于整合層，但它可能適用于加工層。如果您正在提取可能以不同粒度級別本機構建的多個源，則尤其如此。
3NF 實體關系數據庫
優點：
- 減少數據冗余，節省存儲空間
- 通過主鍵關系保證數據完整性
- 提供靈活性以適應未來的變化
缺點：
- 可能需要進行許多表連接進行分析，從而影響查詢性能
- 對于業務用戶來說，理解和操作起來可能很復雜
2.Kimball 星型模式
Kimball 星型模式是數據倉庫中的一個關鍵概念，由數據倉庫和商業智能領域的杰出人物 Ralph Kimball 提出。它旨在簡化數據存儲并提高查詢性能，使復雜的數據結構更易于管理并更易于進行業務分析。
關鍵部件
- 事實表：事實表是星型模式的核心，包含定量數據，例如銷售額、交易次數和其他可衡量指標。事實表中的每條記錄都對應一個特定事件或交易，并包含鏈接到維度表的外鍵。由于它保存的交易數據量很大，因此該表通常很大。通常，它包括銷售額、銷售量和成本等數值度量，以及引用維度表的鍵。
- 維度表：維度表是為事實表中的數據提供上下文的外圍表。它們包含與業務維度相關的描述性屬性，例如時間段、地理位置、產品、客戶和員工。與事實表相比，維度表通常更小且更靜態。它們以非規范化形式存儲數據以簡化查詢，使其更易于理解和導航。
結構和設計
星型模式因其布局類似星星而得名。事實表位于中心，周圍是維度表，每個維度表都通過外鍵連接到事實表。這種設計非常直觀，允許用戶在事實表和維度表之間執行直接連接。
在我們的餐廳示例中，我們將有一個中央訂單事實表，其中包含客戶、日期、產品等維度表的外鍵。維度表包含冗余、非規范化的數據，以避免進一步連接。這是倉庫中整合層或表示層的一種相當標準的方法。
訂單數據的星型模式 ERD
優點：
- 通過最小化連接來優化快速查詢
- 對于熟悉業務流程的業務用戶來說很直觀
- 聚合計算簡單
缺點：
- 非規范化增加了數據冗余
- 處理緩慢變化的維度可能很棘手
- 適應未來變化的靈活性較差
3.雪花模式
雪花模式是數據倉庫中星型模式的一種變體，旨在處理復雜且高度規范化的數據結構。該模式因其復雜的雪花狀形狀而得名，它將數據組織到多個相關表中，從而增強了數據完整性并減少了冗余。然而，這會增加查詢編寫的復雜性并可能影響性能。它幾乎可以看作是星型模式和 3NF 的混合體。
關鍵部件
- 事實表：事實表仍然是雪花模式中的中心表，包含定量數據，例如銷售額、收入或其他業務指標。它包含維度表的外鍵，為事實提供背景信息。事實表中的每條記錄代表一個可測量的事件，并包括數值度量和鏈接到相關維度的外鍵。
- 維度表：與星型模式不同，雪花模式進一步規范化了維度表。每個維度表都可以分解為多個相關表，從而創建更規范的結構。例如，我們的客戶維度將地址拆分為郵政編碼、城市和州表，每個表都通過外鍵鏈接。這種規范化減少了數據冗余，但增加了查詢所需的連接數。
結構和設計
雪花模式由于其多級結構而類似于雪花。維度表被規范化為多個相關表，分散成復雜的網狀結構。這種設計旨在通過消除冗余來節省存儲空間并提高數據完整性。
訂單數據的雪花模式
優點：
- 與星型模式相比，減少了數據冗余
- 通過規范化確保數據完整性
- 使維度表更易于維護
缺點：
- 與星型模式相比，可能需要更多連接，從而影響查詢性能
- 商業用戶更難理解和駕馭
4.寬表 (OBT)
One-Big-Table (OBT) 設計，也稱為平面表或寬表，是一種數據倉庫方法，其中所有數據都合并到單個非規范化表中。這種方法與星型和雪花型等規范化模式形成鮮明對比，它提供了更簡單的結構，但代價是冗余度增加，并且在處理非常大的數據集時可能會出現性能問題。
關鍵部件
- 單表：OBT 設計的核心特征是所有相關數據都存儲在一個綜合表中。該表包含大量列，可捕獲分析所需的所有屬性和度量。該表可能包含數千列，每行代表一條包含多個維度和指標的唯一記錄。
- 屬性和指標：在 OBT 設計中，屬性（通常在其他模式的維度表中找到）和指標（通常在事實表中找到）被組合到單個表中。例如，客戶詳細信息、產品信息和銷售數據都將存儲在同一張表中，每條記錄都提供交易或事件的完整快照。
結構和設計
OBT 設計的結構非常簡單，只包含一個表，其中每行包含所有必要的數據點。這種扁平結構無需連接，用戶無需了解復雜的表關系即可輕松查詢和檢索數據。
對于我們的餐廳，我們將為三個關鍵事件（預訂、訂單和付款）分別設置一個大表。我看到過一些關于 OBT 還是星型模式是更好的方法的相當激烈的爭論。答案是“視情況而定”。如果您將數據拉入 Power BI，它將需要星型模式樣式的數據集。但是，如果您將數據拉入 Tableau，您可能更喜歡 OBT 方法。但應該注意的是，如果您確實選擇 OBT，則應將任何可重復使用的邏輯保留在可以反復引用的支持表中。
OBT 示例
優點：
- 極快的查詢性能，無需連接
- 所有數據都集中在一處，簡單易懂
- 適合數據科學消費
缺點：
- 數據冗余度高，需要大量存儲空間
- 如果不改變整個表結構，就很難做出改變
- 包含許多列的查詢可能難以編寫和維護
5.數據倉庫 2.0
Data Vault 2.0 是一種現代數據倉庫方法，旨在提供可擴展、靈活且可審計的數據模型。它由 Dan Linstedt 開發，以原始 Data Vault 方法為基礎，對其進行了增強，以更好地支持當今復雜的數據環境。Data Vault 2.0 滿足了處理大數據、非結構化數據和各種數據源的需求，同時保持了數據完整性和歷史準確性。與 3NF 一樣，這將位于您的銀層。這不是您指向 BI 工具的東西。
關鍵部件
- 樞紐：樞紐存儲具有唯一代理鍵和元數據（如加載日期和源信息）的唯一業務鍵。每個樞紐代表一個核心業務概念，例如客戶、產品或訂單。樞紐高度穩定且很少發生變化，為數據倉庫提供一致的參考點。
- 鏈接：鏈接捕獲存儲在中心中的業務鍵之間的關系。每個鏈接表包含相關中心的外鍵以及元數據。鏈接表示實體之間的事務、關聯或層次結構。它們用于對多對多關系以及關系隨時間的變化進行建模。
- 衛星：衛星存儲中心中業務鍵或鏈接中關系的描述性屬性和上下文。它們包括用于跟蹤隨時間變化的元數據，例如加載日期和來源。衛星可以在不影響核心業務鍵和關系的情況下發展，從而可以靈活地適應新的業務需求。
結構和設計
Data Vault 2.0 采用模塊化架構設計，將數據存儲分為這三種類型的表，從而提高可擴展性和靈活性。集線器、鏈路和衛星被設計為增量和并行加載，從而可以高效處理大量數據和隨時間變化的數據。
數據倉庫 ERD 示例
優點：
- 旨在應對業務需求隨時間的變化
- 將結構變化與信息變化分開
- 提供可追溯性并保存歷史記錄
缺點：
- 設計和實施起來可能很復雜
- 需要許多表格和連接來匯總數據進行分析
- 查詢可能難以編寫和理解
6.活動模式
活動模式是 Ahmed Elsamadisi 設計的一種數據倉庫方法，用于以結構化和高效的方式捕獲業務活動或事件的詳細記錄。此模式側重于記錄企業內部執行的操作或交易，因此對于事件驅動數據和詳細交易日志記錄特別有用。它已用于需要跟蹤大量細粒度事件的系統，例如電子商務網站、金融系統或物聯網應用程序。
關鍵部件
- 活動表：活動模式中的中心表是活動表，它記錄每個業務活動或事件。活動表中的每一行代表單個事件或交易，捕獲有關發生了什么、何時發生以及其他相關背景的詳細信息。此表屬性已定義為標準的一部分，因此易于實現。
- 維度表：活動表附帶一個可選維度表，該維度表為活動表中記錄的事件提供額外的背景信息。維度可能包括有關客戶、產品、位置、時間和其他相關實體的詳細信息，具體取決于它所涉及的活動流。
在我們的餐廳示例中，我們可能有一個帶有相關客戶維度的客戶活動表。活動表將跟蹤客戶的活動，例如他們的預訂、訂單和付款。這些活動的詳細信息保存在列中feature_json，并有一個可選列用于存儲相關的收入影響。
活動架構示例
優點：
- 設計簡單直觀，表格數量極少
- 無需更改架構即可捕獲實體的其他活動
- 僅當需要跟蹤新實體時才需要新表
缺點：
- 相對較新的方法，尚未被廣泛采用
- 可能不適合所有業務領域和分析需求
7.以實體為中心的建模
以實體為中心的建模是一種靈活的方法，由 Maxime Beauchemin 提出，專注于圍繞客戶和產品等實體進行建模。每個實體都有自己的表，使用 JSON 來跟蹤包括聚合在內的各種指標。這種方法不需要額外的維度表，因為實體表位于實體的最低粒度，并且可以直接在表中包含其屬性。
在餐廳環境中，我們會有一個客戶表，其中包含客戶屬性列，加上一個 json 列來保存時間綁定指標，例如visit.7d，，visit.14d。sale.30d
以實體為中心的建模
優點：
- 靈活適應不斷變化的業務需求
- 只需少量表格即可輕松理解
- 在指標欄內有效捕捉歷史記錄
缺點：
- 查詢可能很復雜，通常需要解除半結構化數據的嵌套
- 實體具有重疊屬性或行為類型時的挑戰
- 與星型模式相比，更難實施完整性約束
三、選擇正確的建模方法
考慮到這七種常見的數據倉庫建模方法，如何為您的數據倉庫選擇正確的方法？請考慮以下因素：
- 分析要求：您需要回答哪些類型的問題？選擇針對這些查詢模式進行優化的模型。
- 數據量和可擴展性：考慮您現在擁有的數據量以及未來預期的數據量。有些方法的可擴展性優于其他方法。
- 易用性：考慮誰將查詢數據倉庫。有些模型對于非技術用戶來說更直觀。
- 靈活性：您的業務可能會不斷發展。選擇能夠適應不斷變化的需求的模型。
- 性能：考慮查詢速度和數據冗余之間的權衡。非規范化模型通常速度更快，但需要更多存儲空間。
最后，“正確”的數據倉庫建模方法取決于您獨特的業務需求和優先事項。通過了解每種建模技術的優勢和劣勢，您可以設計一個數據倉庫，提供快速、靈活且富有洞察力的分析，以推動公司發展。
