跳至主要内容

Entity Relationship Diagram (ERD) 範本

用途：資料模型、DB schema、Entity 關係

適用場景：

  • 「這個系統的資料表長怎樣」
  • 「實體之間的關聯」
  • 「主鍵 / 外鍵關係」

範本 1：基本 ERD​

關鍵符號：

  • || 一個（one）
  • o{ 零到多個（zero or many）
  • |{ 一到多個（one or many）
  • PK primary key
  • FK foreign key
  • UK unique key

關聯符號完整對照​

符號意義讀法
`--
`--o
`--o{`
`--
`}--{`

註：表中 { 和 } 在 Mermaid 原始碼中分別是左右大括號。這裡用 HTML entity 顯示是因為 MDX / Docusaurus 會把裸的左大括號當成 JSX 表達式起始，需要跳脫。

範本 2：Micro SaaS 典型 schema​

使用時機：新 SaaS 產品 DB 設計起點。

範本 3：工業設備 Entity 模型​

使用時機：SECS/GEM 相關系統、工業設備整合。

客製化指南​

屬性格式​

ENTITY {
    type name constraint "comment"
}

範例：

USER {
    uuid id PK "主鍵"
    string email UK "必須唯一"
    string name
    timestamp created_at
}

常用資料型別​

在 Mermaid 寫實際 DB 型別
uuidUUID / GUID
stringVARCHAR / TEXT
intINTEGER
bigintBIGINT
decimalDECIMAL / NUMERIC
booleanBOOLEAN
timestampTIMESTAMP
jsonbJSONB（Postgres）
textTEXT

何時用 ERD vs 其他​

情境用 ERD用其他
DB schema 設計✅—
類別繼承❌classDiagram
服務架構❌flowchart
Entity 關聯（業務模型）✅—

Real-world 建議​

Micro SaaS 必備 Entity​

每個 Micro SaaS 都該有：

  • USER（使用者）
  • SUBSCRIPTION（訂閱狀態）
  • PLAN（方案定義）
  • USAGE_RECORD（使用量追蹤）
  • SESSION 或 AUTH_TOKEN（登入）

複製範本 2 即可。

Anti-patterns​

❌ 沒標 PK / FK​

USER {
    uuid id
    string email
}

應該是：

USER {
    uuid id PK
    string email UK
}

❌ 關係符號不對​

USER ||--|| ORDER

一個使用者只能有一個訂單？通常不對。應該是：

USER ||--o{ ORDER

（一個使用者可以有多個訂單，包括 0 個）

❌ Entity 名稱用小寫 / 複數​

users ||--o{ orders

慣例用大寫單數（UML 慣例）：

USER ||--o{ ORDER