上一篇我們透過使用者故事、使用案例、驗收標準，把痛點轉化為更嚴謹的規格，了解使用者想做什麼、系統該做什麼反應。但軟體系統不能只有動態行為，還必須有承載這些行為的靜態結構。如果直接開工寫程式，把所有資訊硬塞進單一陣列或物件，資料很快就會因為冗餘與關聯混亂而崩塌。今天要做的是領域概念建模，學習如何從規格中找出實體，並用實體關聯圖（ERD）與基數關係（Cardinality），為代購 App 畫出第一份資料架構藍圖。

一、實體關聯圖（ERD）

定義：一種用於資料庫設計的結構化圖表，透過視覺化方式呈現系統範圍內的核心實體（Entities）以及實體之間的關聯（Relationships）。

（一）實體 Entity

定義：實體代表系統中可被獨立定義、儲存資料的物件、概念或事件。在資料庫中，一個實體通常對應成一張資料表（Table）；在應用程式邏輯中，則常對應一個資料模型（Model）物件。

實體分類：

• 強實體 Strong Entity：具備主鍵，可獨立存在且不依賴其他實體，圖形符號為單矩形。
• 弱實體 Weak Entity：無法單靠自身屬性唯一識別，必須依賴識別實體（強實體）而存在，其參與關聯必定為完全參與，符號為雙矩形（對應的識別關聯為雙菱形）。
• 關聯實體 Associative Entity：用來承載多對多關聯，把關聯本身轉換成一個具備自身屬性的實體，例如訂單與商品之間的「訂單明細」，可以記錄數量、單價等只屬於這個組合的資訊。

（二）屬性類型與鍵值設計 Attributes and Keys

• 主鍵 / 鍵值屬性 Primary Key：可唯一識別實體集中每筆記錄的屬性，圖形符號為文字加底線的橢圓形。
• 外鍵 Foreign Key：在關聯式資料庫中參照另一張表主鍵的欄位，用以建立實體間的連結。
• 複合屬性 Composite Attribute：由多個子屬性組成，以大橢圓連接多個子橢圓表示。
• 多值屬性 Multivalued Attribute：單一實例可擁有複數個值，符號為雙橢圓。
• 衍生屬性 Derived Attribute：可由其他屬性計算得出，符號為虛線橢圓。

（三）關聯設計與基數關係

• 一元 / 遞迴關聯 Unary：同一個實體集與自身產生關聯。
• 二元關聯 Binary：兩個不同的實體集參與關聯。
• 多元關聯 Ternary / N-ary：三個或以上實體集同時參與同一個關聯。

基數關係 Cardinality 描述的是兩個實體之間，一筆記錄最多能對應到幾筆記錄：

• 一對一 1:1：一筆記錄只對應到另一邊的一筆記錄，例如一位買家只有一份帳號設定。
• 一對多 1:N：一筆記錄可以對應到另一邊的多筆記錄，例如一位買家可以下多筆訂單，但一筆訂單只屬於一位買家。
• 多對多 M:N：兩邊都可以對應到多筆記錄，例如一筆訂單可以包含多項商品，一項商品也可能出現在多筆訂單裡。多對多在資料庫裡無法直接建表，必須拆成兩個一對多，中間用關聯實體銜接。

二、代購 App 實例

先列出三個實體：

• 買家 User：買家 ID（主鍵）、姓名、Email
• 商品 Item：商品 ID（主鍵）、品名、原幣價格
• 訂單 Order：訂單 ID（主鍵）、買家 ID（外鍵）、建立時間

買家與訂單是一對多：一位買家可以有多筆訂單，每筆訂單只屬於一位買家，訂單表裡的買家 ID 就是外鍵。

但訂單跟商品是多對多：一筆訂單可能包含好幾項商品，同一項商品也會出現在很多筆訂單裡。這種關係沒辦法直接連兩張表，所以要加一個關聯實體「訂單明細 OrderItem」，欄位是訂單 ID（外鍵）、商品 ID（外鍵）、數量，這兩個外鍵合起來就是它的複合主鍵。多對多的關係就這樣被拆成兩個一對多：訂單對訂單明細、商品對訂單明細。

三、結論

這篇最核心的收穫是想通主鍵和外鍵怎麼搭配著用：外鍵不是憑空出現的欄位，它存在的唯一理由就是指向另一張表的主鍵，把兩個實體之間的關係用資料表達出來。而多對多沒辦法直接建表這件事，也解釋了為什麼幾乎每個訂單系統都會多一張「明細」表——那不是設計者想把系統做複雜，是關聯式資料庫的結構逼出來的必要安排。剛開始讀這些名詞完全沒有概念——強實體、弱實體、關聯實體、複合屬性、衍生屬性，一連串很長的串術語混在一起看，根本分不出誰是誰。我的解決方式是用實例去思考：把買家、商品、訂單這三個實體實際擺出來，一邊對著關係圖一邊問自己「這個屬性是不是可以由別的欄位算出來？」、「這兩個實體算不算獨立存在，還是誰依賴誰？」，名詞之間的關係才慢慢清楚起來，而不是靠死記活背。