Star Schema 與 Snowflake Schema 都是資料市集中常見的資料模型，也都屬於 Dimensional Modeling 。在 Dimensional Modeling 中，表格分為維度表 (dimension)以及事實表（fact)。一般來說，資料市集是資料流水線的最終匯聚之地，也是 Dimensional Model 最適合拿來應用的地方，因為他的設計簡直可以說是為了 BI Query （Analytics Query) 而生。

另外，如果大家 Google Dimensional Modeling ，一定會看到 Ralph Kimball 的 Dimensional Data Warehouse，但他的書講的是資料倉儲的設計，而資料市集只是資料倉儲的一環，他也只倡議了資料市集應該用 Dimensional Modeling 呈現。而另外一位跟資料倉儲設計有關的大師，則是 Bill Inmon，他並沒有反對 Dimensional Modeling ，只是他跟 Kimball對於資料倉儲該如何設計有不同的理解。

概念釐清後，接下來就開始介紹 Star Schema 以及 Snowflake Schema 吧

Star Schema ＆ Snowflake Schema

資料模型如其名， Star Schema 是一個星狀結構的資料綱要，透過維度表環繞事實表來呈現星型。比方說：

假設有一間 B2B 會議室商品的公司，需要透過 BI 系統了解營收狀況，營收來自訂單這個商業流程，單一筆訂單的詳述：

McBurger 這間公司 (人） 在 2024年 9 月 25 日 （時）下了一筆訂單（事），購買了投影機、投影螢幕以及會議桌 （物）。

他的星狀結構，呈現如下圖：

在做單一維度的分析時，只需要 join 一次的 dim 跟 fct 就好。

而 Snowflake 的設計，就會將維度表做更多的拆解，減少資料的冗贅，像是下圖的 dim_product_category 以及 dim_product，product_category_name 內部值重複的次數就會比 star schema 少，但缺點就是對商業端來說較難理解：

其實以現在的儲存成本來說，在非必要的狀況下，我會覺得以星狀結構為主就好。 Snowflake 的使用主要是讓事實表的顆粒度能有更多的彈性，因為在實務中，資料市集的設計通常會需要多個事實表，但事實表所關聯的維度表的維度並不一定一致，像是訂單（事實表）的產品維度表可能是以品項為單位，一手啤酒跟一打啤酒是為不同品項。但產品廣告（事實表）卻是以產品種類為單位，一手啤酒跟一打啤酒就是同屬一個產品種類。

因此多數的資料市集模型設計會結合 Snowflake Schema 與 Star Schema。多事實表的資料模型，也可以稱為 Galaxy Schema。

Galaxy Schema

這間 B2B 會議室商品公司，其實也僱傭了不少業務，他們每個人都要負責各區的銷售成績，公司會替他們訂出每個月的銷售目標。針對銷售目標這個業務流程，可以設計出下面的星型架構：

如果他跟第一張星狀結構結合起來就變成：

藍色的是客戶採買會議室商品的商業流程。紅色的則是業績目標的商業流程。綠色則是 Snowflake 的部分。這裡採用 Snowflake 的原因是：業績目標不是以天為單位，也不是以公司為單位，因此需要相對粗顆粒度的維度表與之關聯。另外，在設計資料市集時，也應該盡量避免多對多的設計 （尤其是在 Power BI 的應用上）。（當然還是會有例外，但例外通常發生在事實表對事實表，也就是商務流程對商務流程的關聯。）

這樣結合多事實表的設計就是 Galaxy Schema。將資料市集建成 Dimensional Modeling 的好處也相當明顯，那就是只要有新的商業流程想進到資料市集中，不需要動太多的基礎架構，就可以整合到現有的資料模型中。簡單的 Dimensional Modeling 就介紹到這邊。

明後天的文章將會深入介紹常見的事實表以及維度表。