如果您仍在直接提取數據：從日志中Select *，并希望您的分析能夠跟上，那么是時候重新考慮您的方法了。可擴展、可靠的數據工程——Airbnb、Netflix 和 Uber 等頂級科技公司所實踐的那種——依賴的不僅僅是基本的模式。它始于數據建模技術，這些技術可以優化管道、加快查詢速度，并使您的工程工作更順暢、更易于維護。

數據建模是將原始、混亂的數據轉換為可靠、可擴展系統的藍圖。它能讓您設計出易于維護、查詢速度快且值得信賴的數據管道！

在本文中，您將了解經驗豐富的數據工程師用來理順混亂流程的強大數據建模策略。這些模式對于構建強大的數據系統至關重要——無論是從零開始還是改進舊有工作流程。

1.主鍵

假設你經營著一家小型冰淇淋店，并保存了一份顧客名單。你可能有多個名叫Alex的顧客，但你不想在記錄銷售額時混淆他們。因此，你給每個顧客分配了一個唯一的 ID 號：

這里，Customer_Key是主鍵——它是唯一標識此表中每一行的列。即使兩個人的名字相同，他們的Customer_Key也總是不同的。

因此，在數據庫中，主鍵是表中的一列或多列的組合，用于唯一標識該表中的每一行。

關鍵規則：

唯一性——沒有兩行可以具有相同的主鍵值。

非空— 主鍵必須始終有一個值（不能為空）。

穩定性——它不應該頻繁改變。

2.外鍵

在我們的冰淇淋店中，我們已經在顧客名單中為每個顧客提供了一個唯一的 ID——他們的Customer_Key 。

現在，在我們記錄每筆購買的銷售記錄中，我們不必每次都寫“Alice Johnson”或“Bob Smith”。相反，我們只需寫上他們的Customer_Key。

銷售表

并將客戶詳細信息存儲在其他表中：

客戶表

這里Customer_Key是將銷售表鏈接到客戶表的外鍵。

外鍵是一個表中與另一個表中的主鍵相匹配的列，從而在兩者之間建立鏈接。

關鍵規則

匹配主鍵— 外鍵列中的每個值都必須存在于引用表的主鍵列中（除非允許 NULL）。

可以重復——與主鍵不同，相同的外鍵值可以出現在多行中（例如，同一個客戶多次購買）。

可以為 NULL — 如果關系是可選的，則外鍵可以為空。

現在我們了解了主鍵和外鍵，讓我們更深入地了解它們是如何組合在一起的。

3.事實表

在我們的冰淇淋店里，每當有人買冰淇淋時，你就把它寫在記錄本上：

日期：2025–08–13

口味: 巧克力

數量：2勺

價格：6美元

這個筆記本基本上是你的事實表——它是你記錄所有可測量事件（在本例中是銷售額）的地方。

在數據庫世界中，事實表存儲定量的、可測量的數據——可以計數、求和或計算平均值的數據。

因此，如果我們根據冰淇淋店筆記本中的銷售數據制作一個事實表，它可能看起來像這樣：

代表銷售額的事實表。

這里，Date_Key、Product_Key和Customer_Key是外鍵，分別鏈接到日期、產品和客戶表。Quantity和Sales_Amount是事實——我們想要測量和分析的實際數字。

到目前為止，我們先畫一個圖，稍后在介紹維度細節、SCD 和模式類型時，我們可以繼續擴展這個圖：

Date_Key ------ Product_Key ------ Customer_Key .........(外鍵)          \ |            /           \ | /              Sales_Fact Table

4.維度表

我們有銷售事實表，其中每一行使用外鍵記錄一次銷售：

|日期_Key |產品_Key |客戶_Key |數量|銷售_Amount | | --------- | ------------ | ------------- | -------- | ------------- | | 20250813 | 12           | 301          | 2        | 6.00           |

但這些關鍵數據只是數字而已。要真正理解銷售情況，我們需要知道：

代表什么日期20250813？

代表什么產品12？

誰是顧客301？

這就是維度表的作用所在——它們保存了所有的描述性細節。

維度表是數據倉庫中的表，用于存儲有關業務實體的描述性屬性（文本或分類信息）。

例如：客戶維度表：

|Customer_Key (PK)   |姓名          |城市     |忠誠度狀態  | | 301          |愛麗絲·約翰遜| 紐約    |金牌        | 

| 302            |鮑勃  史密斯|波士頓    |銀牌        |

Customer_Key是這里的主鍵。

該表描述客戶但不包含銷售數字。

那么，我們再畫一下圖，里面有事實表，維度表，主鍵，外鍵。

冰淇淋店數據倉庫——事實表和鏈接維度。

現在我們已經介紹了所有基礎知識，讓我們想象一下這樣一種情況：我們想要跟蹤客戶及其最喜歡的口味。隨著時間的推移，一些客戶會改變他們喜歡的口味，我們需要決定如何在維度表中處理這些變化。所以，這就是 SCD 發揮作用的地方。

5.緩慢變化維度（SCD）

在數據倉庫中，維度表通常包含隨時間變化的屬性。正確管理這些變化對于準確的報告和分析至關重要。根據維度屬性變化的處理方式，SCD 可分為不同類型。最常見的類型是類型 1、類型 2 和類型 3。

假設Bob 把他最喜歡的口味從 草莓 改為 薄荷。讓我們看看每種 SCD 類型如何處理這個問題：

| 客戶 ID | 姓名 | 最喜歡的口味 | 

| 101    | 愛麗絲 | 香草 | | 102    | 鮑勃 | 草莓 | | 103    | 查理 | 巧克力 |

a. SCD 類型 1 — 覆蓋。

類型 1 只是用新值覆蓋舊值。

沒有保留任何歷史記錄，因此我們只能看到最新的信息。

當歷史數據不重要時使用它。

因此，Bob 更改后的表格（類型 1）：

SCD 類型 1：鮑勃以前最喜歡的口味“草莓”消失了。

b. SCD 類型 2 — 添加新行。

類型 2為每個更改添加一個新行。

這允許完整的歷史跟蹤。

通常包括StartDate、EndDate或CurrentFlag來識別活動記錄。

因此，Bob 更改后的表格（類型 2）：

SCD 類型 2：現在我們知道了鮑勃以前的口味以及他喜歡它的時間段。

c. SCD 類型 3 — 添加新列。

類型 3通過為先前的值添加新列來保留有限的歷史記錄。

僅可跟蹤一次先前的更改。

比類型 2 簡單，但不保留完整的歷史變化。

因此，Bob 更改后的表格（類型 3）：

SCD 類型 3：我們可以看到 Bob 當前和之前的風格，但除此之外的舊歷史則無法追蹤。

6.數據倉庫模式

我們已經介紹了如何管理不斷變化的數據。假設我們的冰淇淋店想要分析銷售情況、追蹤顧客偏好并高效管理庫存。為此，我們需要一種結構化的方法來組織數據，以便回答以下問題：

哪種口味最受歡迎？

哪些顧客購買巧克力最多？

本周我們的草莓冰淇淋庫存夠嗎？

這就是模式和數據建模發揮作用的地方。

在數據倉庫的背景下，模式就像定義數據組織方式的藍圖。它顯示了事實表（記錄交易或事件的位置）與維度表（描述實體，例如客戶、產品或位置）之間的關系。

把它想象成一張地圖：模式告訴你一切事物的位置和它們是如何連接的，這樣你就可以快速找到見解。

為什么是 Schemas ?????????????????????

現在我們有了基礎，我們可以探索不同的模式類型——星型、雪花型和星系型——并看看我們的冰淇淋店如何使用每一種模式類型來回答業務問題。

a. 星型模式。

想象一下，我們的冰淇淋店想要了解其銷售情況。諸如“哪種口味的冰淇淋賣得最好？”或“Alice 這周買了多少個冰淇淋？”之類的問題應該能夠快速回答。星型模式非常適合這類問題，因為它以一種簡單且查詢速度快的方式組織數據。

在星型模式中，銷售數據位于我們稱之為事實表的中心。該表記錄了所有交易——誰買了什么、買了多少錢以及何時買的。圍繞著這個事實表的是維度表，它們描述了每個實體的詳細信息，例如客戶或口味。我們可以把它想象成一顆星星：

事實表是中心，維度表是向外輻射的點。

在我們的冰淇淋店示例中，“銷售”事實表記錄交易，而“客戶”表和“口味”表則提供描述性上下文。例如，如果冰淇淋店想知道查理買了多少巧克力冰淇淋，只需將事實表與“客戶”表和“口味”表連接起來即可。同樣，為了了解哪種口味最受歡迎，冰淇淋店會從事實表中匯總數量，然后查找相應的口味名稱。

冰淇淋店的星型模式。

星型模式設計原則。

在設計星型模式時，應遵循一組準則，以保持其高效、整潔且易于使用：

什么時候不使用星型模式？？？？

規范化數據：扁平化會造成冗余和混亂的 ETL。

頻繁更新：對于經常變化的數據來說并不理想。

多對多關系：難以清晰地表示。

大尺寸或寬尺寸：會減慢查詢速度并浪費存儲空間。

深層層次結構：扁平化會導致重復和復雜的計算。

復雜的臨時查詢：缺乏多表連接的靈活性。

我的看法是：當您的數據相對穩定、關系簡單并且您希望快速查詢時，請使用星型模式進行分析。

b.雪花模式。

請記住，我們的星型模式可以很好地組織銷售，但仍然存在一個問題。

IceTypeID    IceTypeName    CategoryName   1         簡單蛋筒         2簡單杯3精美圣代看到了嗎？ “簡單”這個詞在錐體和杯體上都重復出現。

如果我們想將“簡單”重命名為“經典”，我們必須在所有地方進行更改。

隨著我們商店的擴大和更多冰類型或類別的添加，這會變得混亂且容易出錯。

Snowflake 模式通過進一步分割維度解決了這個問題。

我們創建一個類別表，而不是重復類別名稱。

斌記錄類型現在只需使用 ID 即可指向正確的類別。

                    雪花模式                    ---------------- *冰激凌類型表IceTypeID | IceTypeName | CategoryID -----------------------------------------  1 | 蛋筒 | 1   2 |    杯 | 1   3 |  圣代 | 2 *類別表CategoryID | CategoryName --------------------------------   1 | 簡單   2 | 花式

雪花模式是一種組織數據的方法，以便將維度表分成更小的相關表以減少重復。

何時不使用雪花模式？

1.性能比存儲更重要。

如果速度至關重要（例如實時儀表板），則這種額外的連接可能會降低速度。

2.維度小巧、簡潔

拆分表只會增加復雜性，而沒有太多好處。

3. 你需要非常簡單的報告

對于簡單查詢來說，星型模式通常更快、更容易理解。

c. 星座圖式。

星座模式，也稱為事實星座模式，就像是星型模式的放大版本。

它有多個共享一些維度表的事實表。

可以將其想象為幾顆恒星共享同一顆行星——這就是為什么它被稱為“星座”。星座”

想象一下你的冰店現在同時跟蹤銷售和庫存：

銷售情況表→ 冰塊銷量、數量、價格

庫存事實表→ 冰庫存，供應商，數量

兩個事實表都需要共享維度：

顧客

冰型

日期

星座模式允許多個事實表共享維度，而不是重復維度。

何時使用星座模式？？？

對于同一業務，您有多個事實表。

事實表共享維度，因此可以避免重復。

您需要將多個業務流程一起進行分析。

下面，我們將深入探討 7 種高級數據建模技術——Airbnb、Netflix 和 Shopify 等公司也使用這些技術——展示它們如何輕松實現日常指標、簡化復雜關系并幫助團隊理清混亂的流程。這些技術是每位數據工程師在從頭構建新系統或重構遺留 ETL 系統時都應該掌握的。下文將涵蓋以下內容：

這些先進的建模技術不僅僅是理論概念，它們構成了可擴展、高性能數據系統的基礎。利用它們可以幫助您加快查詢速度、優化存儲、簡化復雜關系，并構建能夠應對未來挑戰的管道。那就讓我們開始吧！

1、累積表設計

假設你所在的公司每天追蹤數百萬個用戶事件——登錄、頁面瀏覽、點擊、購買等等。現在，產品團隊的某個人想要一個顯示每日活躍用戶 (DAU) 的儀表盤。

如果直接在原始事件表上運行查詢，它可能看起來像這樣：

從事件中選擇COUNT（DISTINCT user_id），其中event_date = '2025-08-01'；聽起來很簡單，對吧？但問題在于：你的events表每天都有數百萬行數據。在儀表板、報告或 API 上重復運行此查詢會變得緩慢、昂貴，有時甚至在高峰時段無法執行。

這就是累積表發揮作用的地方。

累積表設計。

什么是累積表？

累積表是一種預先聚合的表。您無需每次都重新計算每日活躍用戶 (DAU) 等指標，只需計算一次并存儲結果即可。這樣，當您或您的信息中心需要數據時，即可立即使用。

想象一下提前準備一批餅干——你不用每次有人想吃的時候都從頭開始烤。你只需從罐子里拿出一塊現成的餅干即可。

示例：每日活躍用戶

創建 DAU 累積表的方法如下：

創建 表daily_active_users AS SELECT      event_date，    COUNT（DISTINCT user_id）AS daily_active_users，    CURRENT_TIMESTAMP（）AS last_updated FROM events WHERE event_type =  'login' GROUP  BY event_date；

現在，每一行代表一天的數據以及當天的活躍用戶總數。您還可以跟蹤數據的最后更新時間。這樣，除非發生任何變化，否則您無需修改歷史數據。

為什么累積表很重要？

不妨將累積表視為您的性能提升器。您無需在每次有人請求報告時重新計算相同的數字，而是可以提前存儲結果。這意味著：

累積表模式通常在現代數據倉庫（如 Snowflake、BigQuery 和 Redshift）中實現，其中效率、可擴展性和成本優化發揮著至關重要的作用。

2、事實數據建模

事實表記錄著您業務的真實情況。它們記錄著發生的每件事：每筆訂單、每筆付款、每次點擊、每次配送。如果您想衡量增長、追蹤客戶行為或計算收入，您總會用到事實表。

但問題在于：這些表格不僅會增長，還會呈爆炸式增長。數十億行的數據很常見，如果您不仔細設計它們，您的數據倉庫就會變慢，查詢成本會變得昂貴，您的數據團隊也會被各種修復工作淹沒。事實數據建模就是防止這種情況發生的辦法。與其將其視為“存儲數據”，不如將其視為“為清晰度和規模而設計”。

事實數據建模。

核心基本原理。

1. 清晰度——定義你的粒度。

粒度可以準確地告訴您事實表中的一行代表什么。如果它不清楚，那么您的所有計算都可能是錯誤的。

例子：

Grain = “一份訂單”：每行 = 一份訂單。您可以輕松計算總收入或訂單數量。

Grain = “一個訂單商品”：每行代表訂單中的一個商品。您可以分析哪些商品銷量最高，但需要對每個商品進行加總才能得出每個訂單的總收入。

關鍵規則：首先確定粒度。它為所有指標設置規則，并保持數據的一致性。

2. 穩定性——如何識別行

事實表中的每一行都需要一種可靠的方法來標識。如果您依賴于混亂的字段組合（例如user_id + timestamp），最終會遇到問題：重復、連接緩慢以及結果不一致。

更好的方法是使用單個穩定的鍵（通常稱為代理鍵），例如order_id或session_id。這使得連接更快，查詢更簡單，并確保每個事件只被計數一次。

例子：

缺點：user_id = 101+ 2025-08-18 10:32:45→難以管理，容易復制。

好：order_id = 500123→ 該訂單的單一、唯一標識符。

關鍵規則：干凈的鍵可以使您的數據模型在擴展時保持穩定。

3.可擴展性——它將如何增長

事實表不僅會變大，還會變得非常龐大。對于擁有數百萬用戶或交易的企業來說，這些表的數據很快就會達到數十億行。如果在設計時沒有考慮到規模，查詢速度就會變得非常慢，成本也會急劇上升。

關鍵在于確保查詢僅掃描實際需要的數據。這時分區和聚類等技術就派上用場了：

分區通常會按時間將表拆分成更小的部分。例如，如果您按銷售額進行分區order_date，查詢“上個月的銷售額”時只會掃描該月的銷售額，而不是整個歷史記錄。

聚類將具有相似值的行分組在一起，因此類似的過濾器WHERE order_type = 'electronics'可以更快地找到正確的數據。

通過這些策略，表可以從數百萬行增長到數十億行，而不會導致系統崩潰。

關鍵規則：可擴展的事實表會隨著數據的增長而增長，同時保持查詢的快速和經濟實惠。

4. 背景——您需要哪些額外的細節

事實表本身只是原始數字。為了使這些數字有意義，您需要將它們與提供上下文的維度聯系起來。

例如：事實表可能顯示：order_id = 123, product_id = 45, amount = $200。就其本身而言，這只是一個數字。但通過與維度連接，你會發現它是：

一臺200 美元的筆記本電腦（來自dim_product）

由倫敦的新客戶購買（來自dim_customer）

現在數據可以回答更豐富的問題，例如“倫敦新客戶購買電子產品帶來了多少收入？”

關鍵規則：事實告訴你發生了什么；維度告訴你這意味著什么。

精心設計的事實表可以將原始事件轉化為您的企業可以信賴的可靠、快速且富有洞察力的數據。

3、日期列表數據類型

在傳統的數據模型中，跟蹤多個日期的數據通常會創建多行記錄，每行記錄一天。這很快就會導致表格體積過大、查詢速度變慢以及存儲空間浪費。日期列表數據類型通過將實體的所有相關日期存儲在一行內的單個數組或列表中來解決這個問題。

日期列表是區分普通數據模型和高性能數據模型的隱藏技巧之一。它不需要為每個日期創建單獨的行，而是將多個日期存儲在一行中的單個數組或列表中。這個概念很簡單，但對性能和存儲的影響卻非常巨大。

工作原理：

您可以將用戶活躍日期、預訂持續時間或事件發生日期存儲在單個數組字段中，而無需為每一天創建多行數據。例如，在酒店預訂系統中：

{   “booking_id” ： “H1001” ，  “guest_id” ： “G45” ，  “booked_dates” ： [ “2025-08-01” ， “2025-08-02” ， “2025-08-03” ] }

這里，一行代表整個預訂，但每個日期仍然可以查詢。

           ┌──────────────────┐            │ Dim_Date │            │ （日期列表表）│            └────────┬──────────┘                    │ date_key         ┌──────────┼────────────┐         │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ Fact_Sales │ │ Fact_Orders│ └────────────┘ └────────────┘

BigQuery 或 Snowflake 等現代倉庫可以有效地查詢這些數組。

理想用例：

跟蹤不規則活動：無需為用戶登錄的每一天創建一行，而是將所有活動日期存儲在一條記錄中。

多日預訂：每次預訂可將酒店、航班或汽車租賃顯示為一行。

靈活的事件安排：處理非連續或重復的事件，而無需重復每個日期的事件詳細信息。

如何讓它發揮作用

始終包含start_dateand end_date——這可以使篩選和分區更快。按重要字段（例如user_id或 ）進行聚類或索引booking_id，以避免掃描大量數組。請記住，數組功能強大但并非萬能：如果下游需要完全扁平的表，請仔細規劃扁平化操作。

關鍵規則：

日期列表模式簡化了多日期數據，減少了冗余，并使倉庫保持快速且易于管理。

它在支持半結構化數據類型的現代云倉庫（如 Snowflake、BigQuery 或 Redshift）中特別有用。

4、圖形數據建模

假設你正在為一款流媒體應用設計一個推薦引擎。首先，你用一個關系模型構建它：用戶、電影、類型、評分和好友關系等表。它運行良好，直到有人問起：

“給我看我朋友喜歡的電影，但僅限于動作類。”

突然之間，你需要將四五個連接操作串聯起來——用戶 → 好友 → 評分 → 電影 → 類型。查詢變得繁重、緩慢且難以維護。隨著數據集增長到數百萬用戶和電影，性能會急劇下降。

這就是圖形數據建模改變游戲規則的地方。

你不用考慮行和連接，而是用節點和邊來思考。用戶是一個節點，電影是一個節點，類型也是節點。它們之間的關系——“FRIEND_OF”、“LIKES”、“BELONGS_TO”——就是邊。有了這種結構，同樣的推薦查詢就變得簡單了：從用戶開始，沿著他們的FRIEND_OF邊走，跳到他們朋友的電影LIKED，然后按BELONGS_TO動作過濾。

以前感覺像是在與 SQL 連接搏斗，現在感覺就像在跟隨一連串的連接。

圖形建模。

為什么這很重要？

圖建模的優勢在于它反映了數據在現實世界中的實際行為方式：互聯且動態。每次出現新的關系類型時，您無需重新設計架構——只需添加一條新邊即可。

關系數據庫在關系簡單的情況下運行良好——例如將客戶與其訂單關聯，或將員工與其部門關聯。但是，一旦要查看跨越多層級的連接，事情就會變得復雜且緩慢。

現在想象一下金融科技的場景。你需要抓住那些以微妙方式聯系在一起的不法分子：

兩個賬戶綁定同一張銀行卡，

一組從同一 IP 登錄的用戶，

同一小組之間的推薦循環反復出現，

或使用同一設備擁有多個身份。

如果您嘗試將其與標準連接結合在一起，您的查詢將變成迷宮，并且性能會下降。

使用圖模型，情況會更加清晰。每個用戶、卡、IP 和設備都是一個節點。每個連接—— “登錄”、 “付款方式”、 “推薦” ——都是一條邊。您無需強迫數據庫處理嵌套連接，只需遵循路徑即可。需要查看可疑賬戶三步之內的所有用戶？只需一次遍歷，無需執行一堆混亂的 SQL 連接。

何時使用圖形建模？

圖表并非適用于所有數據集。如果您的數據主要是一對一或一對多關系（例如客戶及其訂單，或員工及其部門），那么關系模型通常更簡單、更高效。

但當關系成為問題的核心時，圖表才真正發揮作用。一些常見的用例包括：

欺詐檢測——查找實體之間的隱藏聯系。

社交網絡——誰關注誰，朋友的朋友。

推薦系統——“購買 X 的人也購買了 Y。”

供應鏈——追蹤跨多個供應商和零件的依賴關系。

IT 網絡——跟蹤系統和服務的連接方式。

5、橋接表

大多數情況下，事實表和維度表都能清晰地處理關系。但有時它們之間的關系并非一對多，而是多對多。這時，橋接表就派上用場了。

想一想：

一個學生可以選修多門課程，每門課程有多名學生。

一部電影可以屬于多個類型，每個類型又有多部電影。

一名醫生可以治療多名患者，一名患者也可以看多名醫生。

如果嘗試直接在事實表中建模，要么會無休止地重復數據，要么會失去豐富的關系。橋接表位于中間，映射所有有效組合，從而解決了這個問題。

橋接表的亮點：

教育系統——連接學生?課程?教師。

媒體目錄——映射電影?流派或歌曲?播放列表。

醫療保健——管理醫生?患者?治療關系。

銷售和營銷——連接活動?客戶?產品。

例子 ：

上圖顯示了當學生可以選修多門課程并且課程可以有多名學生時橋接表如何提供幫助。

左邊是學生。

右邊是課程。

在中間，橋接表映射了哪個學生與哪門課程相關聯。

例如：

學生 A選修了數學和歷史課。

學生 B就讀于歷史專業。

如果沒有橋接，您要么會得到重復的行（混亂），要么會得到過于復雜的事實表（效率低下）。通過引入橋接，您可以將多對多關系分解為兩個簡潔的一對多關系：

學生 → 橋梁 → 課程

這使得模式保持清晰，使查詢更可預測，并確保在聚合數據時不會重復計算。

關鍵規則：

當維度之間存在多對多關系時，請使用橋接表。它可以保持數據倉庫的整潔，并確保分析結果的可靠性。

6、Data Vault建模

如果星型模式是為了快速分析，那么Data Vault 建模就是為了讓數據倉庫更加靈活且面向未來。它專為數據來自多個系統、隨時間變化且需要可審計的環境而設計。

核心思想

Data Vault 不會將數據分成一個大表，而是將其分為三個構建塊

1.中心→業務關鍵（不經常改變的事物）。

例如：客戶 ID、產品代碼、訂單 ID

2. 鏈接→樞紐之間的關系。

例如：客戶下訂單，訂單包含產品

3. 衛星→描述性細節（發生變化的屬性）。

例如：客戶的電子郵件地址、訂單狀態、產品價格

因此，數據倉庫就像樂高積木一樣——集線器是錨點，鏈接是連接器，衛星添加細節。

示例：電子商務訂單

假設您正在為一家網上商店建造一個倉庫。

Hub_Customer：客戶 ID（C123、C456……）

Hub_Order：訂單 ID（O001、O002……）

Hub_Product：產品代碼（P10、P20……）

Link_Order_Customer：將每個訂單與下達該訂單的客戶聯系起來。

Link_Order_Product：將每個訂單與其包含的產品連接起來。

Sat_Customer：保存客戶詳細信息（姓名、電子郵件、注冊日期）和歷史記錄。

Sat_Order：保存訂單詳細信息（狀態、付款類型、發貨日期）。

Sat_Product：保存產品詳細信息（價格、類別、描述）。

以下是使用電子商務示例的數據庫建模的流程圖：

藍色 = 中心（業務關鍵）

綠色 = 鏈接（關系）

紅色 = 衛星（帶有歷史的描述性細節）

這樣，您的讀者就可以“看到”中心如何錨定模型、鏈接如何連接它們以及衛星如何用細節豐富它們。

為什么重要

可擴展：即使您每天攝取數十億行數據也能正常工作。

靈活：無需重新設計模型即可輕松添加新來源或屬性。

可審計：您始終知道發生了什么變化、何時發生、從何地發生。

它并非面向最終用戶模型（星型/雪花型模型正是為此而設計的）。相反，Data Vault 是為這些模型提供數據的原始但結構化的基礎。