資料庫設計裡有幾個詞常常讓人頭痛：Star Schema、Snowflake Schema、Fact Table、Dimension Table。
這篇文章用一間超市的銷售資料，帶你從頭理解這些概念，就算完全沒有資料庫背景也能看懂。
什麼是反正規化？從一張大表說起
想像你在一間超市工作，負責記錄每天的銷售資料。
一開始，你覺得最簡單的做法就是用一張 Excel 表，每次顧客結帳就新增一筆資料，把所有相關資訊全部塞進同一行。
一張典型的銷售記錄表長這樣：
這張表看起來很直覺：所有資訊都在同一個地方，要查哪筆訂單一目瞭然。
但仔細看，你會發現一個問題。
Peter Pandey 的姓名、Email、地址，在每一筆訂單裡都重複記錄了一遍。
Peter 這個月買了 20 次東西，他的地址就被存了 20 遍。
超市有 5,000 個常客，每個人平均每個月買 15 次，一個月就有 75,000 筆資料，而其中有很大一部分都是一遍又一遍地重複同樣的顧客資訊。
這種把所有資訊全塞進同一張表、同一行的做法，有個正式的名稱，叫做反正規化（Denormalized）。
資料重複帶來的兩個大問題
反正規化在資料量少的時候看不太出問題，但一旦資料量增加，麻煩就來了。
問題一：浪費儲存空間
Peter 的地址「台北市信義區」這九個字，在這個月的 20 筆訂單裡被重複存了 20 遍。
同樣的 Email、同樣的地址，一次又一次地佔用空間，這些都是完全多餘的重複。
在資料量很大的系統裡，這種浪費會非常可觀。
問題二：維護困難，容易造成資料不一致
現在假設 Peter 搬家了，從「台北市信義區」搬到「台北市大安區」。
你必須打開資料庫，把所有和 Peter 有關的記錄全部找出來，然後一筆一筆地把地址改掉。
這個月他買了 20 次，你就要改 20 筆。
如果這個月剛好業務很忙，你只改了 18 筆，漏掉了 2 筆，那這 2 筆資料裡的地址就還是舊的。
同一個人，在同一個資料庫裡，卻有兩個不同的地址——這個狀況叫做資料不一致（Data Inconsistency）。
資料不一致是一個非常嚴重的問題，因為你無法確定哪個版本才是正確的，做出來的分析報表也會跟著出錯。
解法：把重複的資訊獨立出來，用 ID 連結
既然問題的根源是「同樣的資訊被重複存了很多次」，解法也很直觀：重複出現的資訊，只存一次，其他地方改用一個代號（ID）來指向它。
這個概念叫做正規化（Normalization）。
第一步：把顧客資訊獨立出來
我們幫每一個顧客建立一個專屬的 ID，然後把顧客的詳細資料單獨存在「顧客表」裡：
每個顧客只出現一次，ID 是唯一的識別碼。
第二步：把商品資訊獨立出來
同樣的做法，商品的詳細資料也單獨存在「商品表」裡：
每個商品也只出現一次。
第三步：銷售表只存 ID，不存詳細資料
原本那張塞滿重複資訊的銷售表，現在只需要存 ID 和交易本身的數字：
401 代表 Peter Pandey，21 代表馬鈴薯，這樣就夠了。
需要查詢完整資料的時候，只要透過 SQL 的 JOIN 語法，把三張表的資料合併起來，一樣可以得到完整的訂單資訊。
現在回想一下剛才 Peter 搬家的問題。
他的地址只存在「顧客表」的那一筆記錄裡。
你只需要改那一個地方，全部的訂單記錄就自動反映了新地址。
不管他買過幾百次東西，你都只需要改一筆，不會有漏改、也不會有資料不一致的問題。
OLTP 不適合做分析：正規化資料庫的代價
正規化解決了「寫入資料」時的問題：不重複、好維護、一致性高。
這種以交易為核心的資料庫設計，有個專有名稱叫做 OLTP（Online Transaction Processing，線上交易處理）。
OLTP 非常擅長處理「一次寫入一筆、快速回應」的情境，例如：
- 顧客結帳，新增一筆訂單
- 更新某個商品的庫存數量
- 查詢某張訂單的狀態
但如果你的老闆今天問你：「去年每個季度，哪個商品類別的銷售額成長最快？」
這個問題要回答，你需要把銷售表、商品表、日期表全部 JOIN 在一起，再跑好幾層的計算。
資料一多，這種查詢就會變得非常慢，因為 OLTP 的設計目標本來就不是為了跑這種大範圍的分析。
所以在實務上，公司通常會另外建立一個專門用來做分析的資料庫，叫做資料倉儲（Data Warehouse）。
資料倉儲的設計概念叫做 OLAP（Online Analytical Processing，線上分析處理），它的目標和 OLTP 完全不同：
資料倉儲的設計不追求「避免重複」，而是追求「查詢速度快、方便切片分析」。
但問題來了：OLTP 的資料要怎麼進到資料倉儲？
ETL 是什麼？資料從 OLTP 進入資料倉儲的流程
OLTP 資料庫和資料倉儲是兩個完全獨立的系統，資料不會自動同步。
中間需要一個搬運和轉換的流程，這個流程叫做 ETL，代表三個步驟：
E — Extract（抽取）
定期從 OLTP 資料庫把資料撈出來。
例如每天凌晨，把昨天所有的訂單記錄、商品異動、新增顧客全部抽取出來。
T — Transform（轉換）
這是最關鍵的一步。
原始的 OLTP 資料通常不能直接使用，需要經過處理，例如：
- 清洗掉格式錯誤的資料（日期格式不一致、欄位填錯位置）
- 把來自不同系統的資料合併（線上訂單 + 實體店訂單）
- 把多張 OLTP 表重新組合，設計成適合分析的結構
L — Load（載入）
把轉換好的資料寫進資料倉儲，供分析師查詢使用。
這三個步驟合在一起，就是 ETL。
有一點很重要：資料倉儲裡的表，不一定和 OLTP 裡的表長得一樣。
ETL 的轉換過程會根據分析需求重新設計結構。
例如 OLTP 裡可能有「訂單表」和「訂單明細表」兩張表，ETL 之後可能會被合併成資料倉儲裡的一張事實表。
資料倉儲裡的表，分成「事實表」和「維度表」兩種
資料倉儲的設計有一套專屬的表格命名方式。
同樣是「記錄銷售資訊的表」，在 OLTP 裡我們叫它「銷售表」，但進入資料倉儲、經過 ETL 設計之後，它有了新的名字，反映的是它在分析架構中的角色。
這三張表在資料倉儲的設計裡，各自有一個專有名稱。
事實表（Fact Table）：記錄發生了什麼
為什麼叫「事實」？
因為它記錄的是「真實發生過的事件」——某個顧客，在某個時間點，買了某樣商品，買了幾個。
每一筆資料都是一件已經發生的事實，不可更改。
昨天 Peter 買了馬鈴薯這件事，永遠就是發生了，不會回頭修改。
這種「只增加、不修改」的特性，是事實表和其他表最大的不同。
事實表的特徵是：只存 ID 和可以計算的數字，不存文字描述。
回頭看我們的銷售表：
裡面只有日期、ID、和數量，沒有顧客的名字，沒有商品的名稱，沒有任何文字說明。
這裡的「數字」不是隨便的數字，而是可以拿來加總、計算、比較的度量值，例如：數量、金額、折扣比例。
這類可以計算的欄位，在資料倉儲裡有個專有名稱叫做量值（Measure），是事實表的核心內容。
維度表（Dimension Table）：描述參與者是誰
「維度」這個詞聽起來抽象，但概念很簡單：它就是用來描述事實表裡那些 ID 到底代表什麼的補充資料。
銷售表裡的 401 代表一個人，但那個人叫什麼名字、住在哪裡、是哪個年齡層？這些描述性的資訊，就存在顧客維度表裡。
銷售表裡的 21 代表一個商品，但那個商品叫什麼、屬於哪個類別、是哪個品牌？這些描述性的資訊，就存在商品維度表裡。
維度表存的不是「發生了什麼」，而是「參與這件事的人事物，長什麼樣子」。
有一個方法可以快速判斷一個欄位屬於事實表還是維度表：
- 問「多少？」能回答的（數量、金額、次數）→ 屬於事實表的量值
- 問「是什麼？屬於哪種？」能回答的（名稱、類別、地址）→ 屬於維度表的描述
事實表和維度表缺一不可
光有事實表，資料是看不懂的。
單看事實表，你只會看到一堆數字和 ID：
401 買了 21 兩個、22 一個——這兩行數字完全不知道在說什麼。
你不知道 401 是誰，不知道 21 是什麼商品，也不知道這些數量代表什麼業務意義。
事實表就像是一份只有代號、沒有說明的暗語清單。
光有維度表，也回答不了任何業務問題。
反過來，如果你只有顧客表和商品表，你知道 Peter Pandey 住在台北市信義區，你知道馬鈴薯屬於蔬菜類、單價 25 元。
但你完全不知道 Peter 買過什麼、買了幾次、消費了多少。
維度表就像是一份靜態的名冊，描述每個人、每樣東西的屬性，但沒有任何「行為」的紀錄。
它們必須透過 ID 連結在一起，才能發揮作用。
當你把事實表和維度表 JOIN 在一起，401 就變成了「Peter Pandey，台北市信義區的顧客」，21 就變成了「馬鈴薯，蔬菜類，單價 25 元」。
資料瞬間從一堆代號，變成了可以分析的完整資訊。
這時候你才能開始回答真正有業務價值的問題：
- 「哪個顧客這個月消費最多？」→ 事實表的「數量 × 金額」聚合，再對應到顧客維度表的「姓名」
- 「蔬菜類商品的週末銷量，比平日高多少？」→ 事實表的「數量」，用商品維度表的「類別」篩選，用日期維度表的「星期幾」分組
- 「北部地區的顧客，最常買哪個品牌？」→ 事實表的「銷售筆數」，用顧客維度表的「地區」篩選，再對應商品維度表的「品牌」
每一個問題，都是從事實表出發，透過維度表的描述屬性來「切入」、「篩選」、「分組」。
這就是事實表和維度表各自存在的意義：事實表負責記錄行為，維度表負責解釋背景，兩者缺一不可。
日期維度表：讓時間分析更靈活
銷售記錄裡有日期，但光一個日期能做的事很有限。
如果你想分析「平日和假日的銷售有什麼差異？」，你就需要知道每個日期是星期幾、是不是假日。
這時候可以建立一張「日期表」：
日期表也是一張維度表，它讓你可以對時間做更細緻的分析。
星型結構（Star Schema）：事實表在中間，維度表在四周
現在把前面建立的所有表的關係畫成圖。
規則很簡單：事實表放在正中間，每一張維度表放在旁邊，並用一條線連回事實表。
整個圖形看起來像一顆星，所以叫做星型結構（Star Schema）。
這個命名方式讓你一眼就能看出設計的意圖：中心是發生的事，四周是描述這件事的各種角度。
星型結構有幾個值得記住的特性：
事實表的資料量遠比維度表大。
超市每天可能有幾萬筆交易，一年下來事實表就有幾百萬筆資料。
但顧客表可能只有幾千人，商品表可能只有幾百種商品——維度表的資料量通常只有事實表的百分之一，甚至更少。
這個比例差距很重要。
資料倉儲在設計查詢效能的時候，優化的重點通常放在事實表上，因為它才是真正「大」的那張表。
維度表相對小，JOIN 起來的成本低，這也是星型結構查詢速度快的原因之一。
事實表頻繁更新，維度表相對穩定。
每次有新訂單，事實表就新增一筆，一天可能新增幾萬筆。
幾年下來，事實表會累積數億筆資料，而且只增不改——因為已經發生的交易事實不會被修改。
維度表則不一樣。
商品種類一個月可能只新增幾十項，顧客資料也不是每天都在改。
這種「更新頻率不對稱」的特性，讓資料倉儲可以針對兩種表做不同的處理策略：事實表專注在高效的大量寫入，維度表則可以花更多資源維護資料品質和描述的完整性。
分析時，從事實表出發，用維度表篩選和分組。
這是星型結構最核心的使用邏輯，值得用一個例子說清楚。
假設你想分析「2024 年第一季，蔬菜類商品在北部地區的銷售總額」。
這個問題涉及三個條件：時間（第一季）、商品類別（蔬菜）、顧客地區（北部）。
你的查詢流程會是這樣：
- 從事實表取出所有銷售記錄的「數量 × 單價」
- JOIN 日期維度表，篩選出「季度 = Q1」的記錄
- JOIN 商品維度表，篩選出「類別 = 蔬菜」的記錄
- JOIN 顧客維度表，篩選出「地址包含北部地區」的記錄
- 把符合條件的所有記錄加總起來
事實表是數字的來源，維度表是篩選和分組的依據。
每一個「你想從哪個角度分析」的需求，就對應到一張維度表——這就是為什麼它叫「維度」，因為它代表的是分析的一個維度（時間維度、地區維度、商品維度）。
維度表越完整、描述屬性越豐富，你能回答的分析問題就越多。
雪花結構（Snowflake Schema）：維度表繼續往下延伸
星型結構有一個常見的延伸情況：維度表本身也可以再拆分。
舉個例子。
超市的顧客可能來自不同國家和地區。
假設一開始你把所有資訊都塞進顧客表，它可能長這樣：
你有沒有發現一個問題？
「亞太區 / 東亞」這個資訊，在 Amy 和 David 兩筆記錄裡重複存了兩遍。
超市如果有幾千個台灣顧客，「亞太區 / 東亞」就會重複幾千次——這又回到了最一開始的資料重複問題。
而且「區域屬於哪個子區域」這件事，其實和「顧客叫什麼名字、Email 是什麼」是完全不同層次的資訊。一個是關於「人」，另一個是關於「地理層級」。
把它們混在同一張表，邏輯上就不太對。
所以我們可以繼續把這些資訊獨立出來。
第一步：把顧客表的地理資訊換成 ID
第二步：建立市場維度表，存放國家資訊，並連結到區域
第三步：建立區域維度表，存放區域層級資訊
現在「台灣屬於亞太區」這件事，只在區域表裡存了一次。
就算有幾千個台灣顧客，也不需要重複儲存同樣的區域資訊。
這樣拆分之後，顧客表連結市場表，市場表再連結區域表：
顧客表連結市場表，市場表再連結區域表——維度表往下再長出子維度表。
把整個結構的形狀想像一下，從中間的事實表往外延伸，維度表還連著更多表，整個圖形的輪廓看起來像雪花，這就是雪花結構（Snowflake Schema）名稱的由來。
雪花結構和星型結構的核心概念完全一樣，差別只在於：
- 星型結構：維度表是扁平的，所有描述資訊都在同一張表裡，查詢時 JOIN 的表比較少，速度較快
- 雪花結構：維度表被進一步正規化，層層拆分，資料重複性更低，但查詢時需要 JOIN 更多張表
兩者沒有絕對的優劣，視資料的複雜度和查詢效能的需求來選擇。
資料建模：設計事實表與維度表的思考過程
回顧一下我們這篇文章做的事情：
決定要建哪些表、每張表要存哪些欄位、哪些欄位應該拆出去成為獨立的維度表、表和表之間用哪個 ID 連結——這整個設計過程，有一個正式的名稱叫做資料建模（Data Modeling）。
資料建模不是一個技術操作，而是一個思考過程。
你需要回答的問題包括：
- 這個業務有哪些「事實」需要記錄？（→ 決定事實表的內容）
- 分析師最常需要從哪些角度切入資料？（→ 決定要建哪些維度表）
- 哪些資訊會一起被查詢、哪些可以拆開？（→ 決定星型還是雪花結構）
- 哪些欄位的更新頻率不同，需要分開管理？（→ 決定表的邊界）
同樣一份業務資料，不同的建模方式會產出完全不同的結構，也會直接影響之後查詢的速度和分析的靈活度。
資料建模是資料工程師和資料分析師日常工作的核心技能之一。
在實務上，建模的工作通常發生在兩個階段：
第一個階段是設計資料倉儲的整體架構，決定要建幾張事實表、幾張維度表、它們之間的關係是什麼。這個階段通常由資料工程師主導，會畫出像我們文章裡那樣的星型或雪花結構圖。
第二個階段是在 BI 工具裡設定表關係，告訴工具「這張表的顧客 ID 對應到那張表的顧客 ID」，讓報表能夠正確地跨表計算。Power BI、Tableau、Looker 等商業智慧工具都有內建的資料建模介面，讓你可以用視覺化的方式拖拉設定表與表之間的連結，不需要每次都手寫 SQL JOIN。
一個好的資料模型，能讓分析師用最少的步驟回答最多的業務問題。
一個設計不良的資料模型，則會讓每一個分析需求都變成一場 SQL 除錯大會。
這也是為什麼資料建模在資料工程領域被視為一項核心技能，而不只是「把表格排一排」這麼簡單的事。
為什麼資料倉儲的查詢比 OLTP 快？
前面介紹星型結構的時候，我們說過分析查詢的流程：從事實表取出銷售數字，JOIN 日期維度表篩選季度，JOIN 商品維度表篩選類別，JOIN 顧客維度表篩選地區。
這聽起來和 OLTP 的查詢沒什麼不同——兩者都需要把多張表 JOIN 在一起。
那前面說「OLTP 的大範圍分析查詢很慢，所以需要資料倉儲」，到底是快在哪裡？
要理解這個差距，需要先釐清一個很多人忽略的前提：OLAP 資料倉儲並不是用 MySQL、PostgreSQL 這類傳統關聯式資料庫來儲存資料的。
它用的是專門為分析設計的欄式資料庫（Columnar Database），例如 Google BigQuery、Amazon Redshift、Snowflake、ClickHouse 等。
這些系統在磁碟上儲存資料的物理方式，和 MySQL 從根本上就不同。
傳統的 MySQL 採用列式儲存：一筆資料的所有欄位在磁碟上連續存放在一起。
讀取「數量」這一欄時，磁碟必須先把整行讀進記憶體，再從中取出數量那格，其他欄位全部讀了又丟掉。
欄式資料庫採用欄式儲存：同一個欄位的所有值，在磁碟上連續存放在一起。
讀取「數量」這一欄時，磁碟讀寫頭直接跳到「數量欄」的儲存區塊，從頭讀到尾，其他欄位的儲存位置根本不會被碰到。
這不是軟體層面的優化，而是資料在磁碟上的實際排列方式不同，所以才能真正做到跳過其他欄位。
一百萬筆資料，讀取量可能只有列式儲存的十分之一，速度自然快得多。
除此之外，OLAP 通常還會預先計算好常用的聚合結果（例如每個商品的月銷售額），讓分析查詢可以直接取用，不需要每次都從頭計算。
OLAP 不是「不用 JOIN」，而是每次 JOIN 和掃描的成本，透過欄式儲存和預聚合設計，比 OLTP 低得多。
兩者都需要 JOIN，但 OLTP 的 JOIN 在幾百萬筆資料上會逐筆讀取整行，OLAP 的 JOIN 只讀需要的欄位、命中預計算的結果——這就是差距所在。
四個核心概念總整理
- 事實表（Fact Table）：記錄業務事件的主表，放在結構中間，更新頻繁
- 維度表（Dimension Table）：描述事件細節的輔助表，放在結構旁邊，更新較少
- 星型結構（Star Schema）：事實表在中間，維度表圍繞在四周，形狀像星星
- 雪花結構（Snowflake Schema）：在星型結構的基礎上，維度表再進一步拆分成子表，形狀像雪花
搞懂這四個概念，你就掌握了資料倉儲設計的基礎語言。