輪輻式模型實體（Entity）

為了在設計上實現資料模型上的重用性與模塊化，DV模型設計主要是以業務鍵（Business Key）為中心的輪輻式（Hub-and-Spoke Model）模型。模型中有三種基本的實體（Entity）組件：

• 中心（Hubs)表:唯一業務鍵（Unique Business Key）的列表，也包含了一些常用的業務實體建值（Mapping Dimensions）。
• 鏈接（Links)表：鍵與鍵之間關係的列表，可以實現一對一(1-to-1)、多對多(n-to-n）的各種實體業務關係。
• 衛星（Satellite）表：實際儲存各種業務事實（Business Facts）的組件，通過唯一業務鍵來與中心表鏈接並且擴充主要實體的業務描述。

簡單實用案例

在以上的參考設計里，可以看到幾個不同的實體：

• 中心表：
  • hub_customer
  • hub_order
  • hub_payment
• 鏈接表：
  • link_order_customer
  • link_order_payment
• 衛星表：
  • sat_payment
  • sat_customer
  • sat_order

在設計上可以看出來，中心表是可以比對業務上的主要實體：客戶、訂單、付款紀錄。業務實體的各種資料則是存在對應的衛星表上。中心實體之間的關係則可以通過連結表：訂單<>客戶、訂單<>付款紀錄。

乍看之下，看習慣一般Kimball資料倉儲模型的人可能會覺得這個設計有點冗長與過於複雜，甚至有點過度設計（over-engineered）。特別是各種衛星表，感覺特別沒必要。如果本身就是一比一對應業務實體，為什麼不直接放在代表業務主要實體的中心表上呢？

其實，如果資料倉儲項目上不需要用到這一類設計，我還是會建議先從簡單資料倉儲模型開始建起。DV的主要用途是為了可以用同樣的資料模組與抽象數據模型（abstract data model）來實現所有多對多（衛星<>中心，中心<>中心）的業務關係，還有資料源與載入時間上的業務複雜性。

（小）收尾與參考

基本理論部分結束！接下來會從以上例子開始討論各種實踐上的問題與比對其他常見數據模型的考量。

Entity定義：為了拼中文字數，我這裡是把entity硬翻成了“實體”，但好像沒有制式的對照。好奇的朋友可以參考一下前幾屆鐵人賽前輩的解釋 (人>U<)