設計資料庫並非僅僅是輸入程式碼，而更在於理解資料之間的關係。在撰寫任何程式碼之前，必須先建立視覺化的基礎。這個基礎就是實體-關係圖（ERD）。跳過這一步，等於在沒有設計圖的情況下建造摩天大樓。結構或許能撐一陣子，但隨著資料量增加，問題就會浮現。🧱
本指南將帶領您走過資料庫架構的初始階段。重點在於建立強健資料結構所需的概念模型與邏輯模型。無論您是在管理客戶資料、庫存，還是複雜的交易資料，這些原則都是一致的。我們將探討實體、屬性、關係與基數，且不依賴特定工具或專有軟體。目標是建立一個可擴展、高效且易於維護的系統。🚀
理解實體-關係圖 📐
ERD是系統內資料結構的視覺化呈現。它標示出需要儲存的「事物」（實體）及其相互之間的互動方式。可將其視為資料庫引擎的地圖。它並未定義資料在磁碟上的實際儲存方式，而是說明資料在應用程式中如何邏輯組織。
為什麼要從這裡開始？🤔
從穩固的圖表開始，可避免多項常見問題：
- 資料重複：將相同資訊儲存在多個地方，會導致資料不一致。
- 資料完整性錯誤：關係被明確定義，可避免出現孤立記錄。
- 可擴展性：邏輯模型可隨著業務成長而調整，無需全面重構。
- 溝通：利益相關者可在開發開始前審閱結構，確保需求獲得滿足。
若沒有ERD，開發人員經常只能猜測關係。這將導致後續出現複雜的連接操作，並造成效能瓶頸。一個明確定義的圖表，可作為整個專案團隊的唯一可信來源。🤝
第一步：識別實體 🏢
任何資料庫的基石都是實體。實體代表一個獨特的物件、概念或人物，資料即圍繞其收集。在圖表的脈絡中，這些就是您在需求中識別出的名詞。
現實世界實體 vs. 邏輯實體
分析業務流程時，必須區分實體物件與邏輯概念。例如，「產品」是一個邏輯實體，而倉庫中的一個特定「小零件」則是實體的具體範例。資料庫儲存的是邏輯實體，並透過唯一識別碼追蹤各個實例。
識別候選實體
要找出實體，請檢視業務規則與功能需求。請尋找：
- 名詞： 在需求文件中尋找大寫的名詞。
- 核心功能： 執行了哪些動作？誰參與其中？
- 法規需求： 哪些資料必須保留以符合法規？
常見範例包括：
- 客戶： 誰在購買或互動？
- 訂單： 交易記錄。
- 產品： 正在銷售的項目。
- 員工： 誰在管理系統？
- 地點： 貨物發送到哪裡？
實體命名慣例
一致性是可讀性的關鍵。在圖表中使用單數、複數或一致的命名標準。除非是業界標準，否則避免使用縮寫。例如，使用「客戶」而非「Cust」。
| 方面 | 建議 | 範例 |
|---|---|---|
| 案例 | PascalCase 或 snake_case | CustomerRecord 或 customer_record |
| 單複數 | 表格使用單數 | 使用客戶，而非客戶們 |
| 清晰度 | 避免使用通用名稱 | 使用發票，而非文件 |
步驟 2：定義屬性 📝
一旦識別出實體，您必須定義關於它們儲存哪些資訊。這些細節稱為屬性。屬性描述實體的特徵。
屬性的類型
屬性根據其角色和行為可分為幾個類別：
- 描述性屬性： 基本事實，例如姓名、地址或電話號碼。
- 關鍵屬性： 唯一識別碼。每個實體都至少需要一個關鍵屬性來區分於其他實體。
- 複合屬性： 可以細分為較小部分的資料（例如，地址可拆分為街道、城市、郵遞區號）。
- 衍生屬性： 從其他資料計算得出的值（例如，年齡由出生日期推導得出）。
- 多值屬性： 可以儲存多個值的欄位（例如，單一個人的多個電話號碼）。
主鍵：核心錨點 🔑
主鍵（PK）是最關鍵的屬性。它必須在表格中的每筆記錄中都是唯一的。這確保了沒有兩列是相同的。主鍵通常由系統自動產生，例如自動遞增的整數或 UUID。
選擇鍵時的考量：
- 穩定性： 該值不應隨時間改變。使用姓名有風險；使用 ID 更安全。
- 唯一性： 不允許重複。
- 非空性： 沒有鍵，記錄就無法存在。
步驟 3：建立關係 🔗
實體很少孤立存在。顧客下訂單。員工參與專案。這些連結就是關係。定義關係正是實體關係圖（ERD）真正強大的地方。
關係的類型
有三種標準的基數用來描述實體之間的互動方式：
- 一對一（1:1）： 實體 A 的一個實例僅與實體 B 的一個實例相關。
- 一對多（1:N）： 實體 A 的一個實例與實體 B 的多個實例相關。
- 多對多 (M:N)：實體 A 的多個實例與實體 B 的多個實例相關聯。
處理多對多關係
在關係模型中，直接的多對多關係在物理上不被支援。必須使用關聯實體（也稱為橋接表或聯結表）來解決。這個新的實體將 M:N 關係拆分為兩個一對多關係。
例如，一名學生可以選修多門課程，而一門課程也可以有許多學生。不應直接連結它們，而是建立一個註冊實體。此表格儲存學生 ID 和課程 ID，以及該註冊的任何特定資料（例如成績）。
步驟 4：基數與模態性 🔢
基數定義關係的數量。模態性定義可選性（關係是強制的還是可選的）。這些細節確保資料完整性。
基數符號
視覺符號有助於開發人員理解約束。常見符號包括：
- 一： 一條直線或短線（-）。
- 多： 乌鸦腳符號（∞）或三個分叉。
- 可選： 一個圓圈（○），表示允許零個。
- 強制： 一條實線，表示至少需要一個。
參與約束
理解參與關係對於應用程式邏輯至關重要。請考慮以下情境：
- 完全參與： 每一位客戶 必須擁有一筆訂單。（強制）
- 部分參與： 一筆訂單 可能擁有一個送貨地址。（可選）
錯誤的模態性會導致資料庫錯誤。如果系統要求強制關係，但資料庫允許空值，當資料遺失時，應用程式邏輯將會失效。
步驟 5：標準化上下文 🔄
雖然 ERD 是一個邏輯模型，但必須符合標準化原則。標準化能減少冗餘並提升資料完整性。這包括將屬性組織成表格，以最小化依賴關係。
第一範式 (1NF)
確保值為原子性。欄位不應包含項目清單。例如，不要在「興趣」欄位中儲存「閱讀、健行、程式設計」，而應建立一個獨立的「興趣」表格。
第二範式 (2NF)
消除部分依賴。所有非鍵屬性必須依賴整個主鍵，而非僅僅其中一部分。這通常適用於表格具有複合鍵的情況。
第三範式 (3NF)
消除傳遞依賴。非鍵屬性不應依賴其他非鍵屬性。例如，在「員工」表格中，若根據「辦公室編號」儲存「城市」，則應將「辦公室編號」與「城市」分離至「辦公室」表格中。
ERD 有助於視覺化這些依賴關係。如果你發現屬性以暗示重複的方式分組，則在撰寫 SQL 前必須調整 ERD。⚙️
常見陷阱須避免 ⚠️
即使經驗豐富的設計師在初期階段也會犯錯。及早識別這些陷阱可大幅節省開發時間。
| 陷阱 | 後果 | 解決方案 |
|---|---|---|
| 遺漏的關係 | 資料變成孤立的島嶼 | 審查所有連接的需求 |
| 過度標準化 | 查詢變得過於複雜 | 平衡資料完整性與讀取效能 |
| 忽略資料類型 | 儲存效率低下與錯誤 | 盡早定義類型（日期、數字、文字） |
| 硬編碼值 | 系統變得僵化 | 對靜態資料使用查閱表格 |
| 弱鍵 | 追蹤記錄困難 | 確保鍵具有唯一性與穩定性 |
文件編寫與審查 📄
ERD 不是一次性完成的繪圖。它是一個隨著專案不斷演進的動態文件。一旦初步設計完成，就必須進行審查。
利害關係人驗證
將圖表呈現給業務分析師和領域專家。他們可以發現開發人員可能忽略的遺漏業務規則。例如，「退款不得在30天後處理」這項規則可能不會出現在技術圖表中，但對邏輯至關重要。
技術可行性
與資料庫管理員一起審查設計。他們可以評估所提出的資料結構在預期資料量下是否能良好運作。他們可能會根據定義的關係，建議索引策略或分割計畫。
迭代過程 🔄
資料庫設計很少是線性的。新的需求會不斷出現，業務流程也會改變。ERD 必須更新以反映這些變動。
資料結構的版本控制
與程式碼一樣，資料庫結構也應該進行版本控制。這讓團隊能夠追蹤時間上的變更。如果某項變更導致系統故障，你可以回退到先前的 ERD 版本及對應的指令碼。
變更管理
修改 ERD 時，應考慮對現有資料的影響。在現有資料表中新增必要欄位，可能會導致報表失效。新增關係可能需要資料遷移。在更新設計時，務必同時規劃遷移策略。
工具與紙筆 🖊️
雖然有許多軟體工具可用於建立 ERD，但最初的思考過程最好不受限制。使用白板或紙筆可以快速迭代。你可以輕易擦除、重畫與重構，無需擔心格式或軟體限制。
一旦邏輯結構達成共識，便可轉換為正式的圖示工具。這能確保概念模型不會因軟體限制而扭曲。工具應服務於模型，而非主導模型。
設計的最後想法 🌟
建立資料庫是一項講求紀律的邏輯練習。第一步，建立穩固的 ERD，將為整個專案奠定方向。它迫使你在撰寫程式碼之前就思考資料關係。這種前瞻性能減少技術負債，並建立一個能抵禦變動的系統。
專注於清晰性。使用標準命名。嚴格定義鍵值。與利害關係人共同驗證。將圖表視為業務需求與技術實現之間的合約。遵循這些步驟，可確保基礎堅固，足以承載你的資料重量。 🏗️