建立穩健的資料庫，早在第一張資料表建立之前就已開始。它從理解商業問題開始，並將人類語言轉換為結構化的資料邏輯。這段旅程，被稱為資料模型設計，彌補了利害關係人需求與系統儲存方式之間的差距。一個精心構建的實體關係圖（ERD）可作為此基礎架構的藍圖。若缺乏明確的轉換流程，專案將面臨資料重複、完整性問題，以及後續高昂的重構成本。
本指南詳細說明了從原始需求轉換為最終ERD的實用步驟。我們將專注於邏輯、關係，以及確保資料模型能經得起時間考驗所需的批判性思維。
1. 理解輸入：收集與分析需求 📋
任何資料庫設計的基礎在於需求。這些需求在最初呈現時，往往模糊、衝突或不完整。目標是在著手處理「如何」之前，先釐清「什麼」與「為什麼」什麼以及為什麼在擔心「如何」之前如何.
識別商業流程
首先，繪製工作流程圖。請利害關係人描述他們的日常運作。留意那些涉及儲存資訊的動作。例如，物流經理可能會說，「我們需要追蹤每個包裹在任何時刻的位置。」這句話包含多個資料點：包裹、其位置以及時間軸。
- 訪談利害關係人：安排與終端使用者的會議，而不僅僅是經理。他們經常會揭示高階摘要所忽略的邊界案例。
- 記錄規則：明確地記錄商業規則。「一位客戶不能同時擁有超過一個有效的訂閱。」這是一個限制條件，而不僅僅是功能。
- 檢視現有系統：若從舊系統遷移，需分析遺留資料。實際使用的欄位有哪些？哪些已遭廢棄？
質性與量化需求
並非所有需求都同等重要。你必須區分資料的性質與資料的數量。
- 質性： 定義資料的意義與類型。日期是出生日期還是交易日期？姓名是單一字串，還是應拆分為名字與姓氏？
- 量化： 定義限制。每天最多多少筆記錄？保留期限是多少？
這裡的混淆會導致不良的資料結構設計。例如，將電話號碼視為文字字串可保留格式字元，但若視為整數，可能會移除必要的前綴。決策必須盡早記錄。
2. 識別核心實體 🏗️
一旦需求明確，下一步就是識別實體。實體代表必須儲存資料的現實世界物件或概念。在實體關係圖中，這些通常以矩形表示。
發現技巧
要找出實體，需在需求中尋找名詞。然而，並非每個名詞都是實體。您必須篩選出需要儲存且具有唯一識別性的名詞。
- 直接名詞： 客戶, 產品, 發票。這些都是明顯的候選項目。
- 隱含名詞： 有時實體隱藏在動詞中。「將專案指派給團隊。」 在這裡，專案 和團隊 都是實體。指派 如果它有自己的屬性（例如指派日期），則可能是關係或獨立的實體。
- 排除的名詞： 像系統, 使用者（廣義上來說），或資料通常過於抽象。請具體說明。是「註冊使用者」還是「訪客?
定義實體身分
每個實體都必須有一種方式來區分一個實例與另一個實例。這就是「主要鍵」。在概念階段，你不需要決定這個鍵是自動遞增的數字還是UUID，但你必須承認身分識別是必要的。
- 自然鍵：現實世界的屬性是否能提供唯一識別？（例如社會安全號碼或車輛識別號碼）。
- 替代鍵： 如果不存在自然鍵，或鍵經常變更，則需要系統產生的唯一識別碼。
考慮實體「員工」。員工編號是鍵嗎？還是姓名與部門的組合具有唯一性？通常，使用唯一識別碼更安全，以避免姓名變更或重複姓名所造成的問題。
3. 定義屬性和資料類型 🏷️
屬性是描述實體的性質。它們填補了細節。如果實體是一隻盒子，屬性就是盒子上的標籤。
屬性的分類
屬性應邏輯性地分組。有些是必要的，有些是可選的，有些是衍生的。
- 必要屬性：實體有效時必須存在的資料。（例如，訂單的「訂單日期」）
- 可選屬性：資料可能出現，也可能不出現。（例如，使用者的「次要電子郵件」）
- 衍生屬性： 根據其他屬性計算得出的資料。（例如，年齡 由 出生日期）。通常，這些資料不會以物理方式儲存，以避免更新異常，但它們對模型非常重要。
選擇資料類型
雖然ERD是概念性的，但考慮儲存類型可以避免未來的錯誤。類型不匹配會導致效能問題和資料遺失。
| 屬性概念 | 建議類型 | 理由 |
|---|---|---|
| 姓名、地址 | VARCHAR / 文字 | 長度可變，非數值字元。 |
| 數量、價格 | 整數 / 小數 | 數學運算、精確度需求。 |
| 日期、時間 | 日期 / 日期時間 | 允許排序、篩選和持續時間計算。 |
| 是/否旗標 | 布林值 | 明確的邏輯以表示真/假狀態。 |
| 大型文件 | BLOB / 檔案參考 | 用於儲存二進位資料或連結至外部儲存空間。 |
屬性的正規化
在繪製實體之間的連線之前，請確保屬性為原子性。屬性應僅包含一個值。避免將多個電話號碼儲存在單一欄位中，例如Phone_1、Phone_2、Phone_3。相反地，應為聯絡資訊 連結至 客戶.
- 為什麼選擇原子化？ 它簡化了查詢。如果電話號碼被串接在一起，就無法搜尋特定的電話號碼。
- 彈性： 如果客戶獲得第二個電話號碼，獨立的實體可以在不更改結構的情況下實現無限擴展。
4. 建立關係與基數 🔗
實體很少孤立存在。它們會相互作用。ERD 中連接實體的線條代表關係。正確定義這些關係是模型設計過程中最重要的部分。
關係類型
關係描述了一個實體的實例與另一個實體的實例之間的關聯方式。
- 一對一 (1:1)： 實體 A 的一個實例僅與實體 B 的一個實例相關聯。範例：員工 對應至 員工證.
- 一對多 (1:N)： 實體 A 的一個實例與實體 B 的多個實例相關聯，但實體 B 僅與實體 A 的一個實例相關聯。範例：作者 對應至 書籍.
- 多對多 (M:N)： A 的多個實例與 B 的多個實例相關聯。範例：學生 對應至 類別。注意：在實際實現中，這通常需要一個中介實體（關聯表）。
基數與模態
基數定義數量（一個、多個）。模態定義需求（必須、可選）。可視化這些內容對於資料完整性至關重要。
- 零個或一個： 這段關係是可選的，且僅允許一個。
- 一個且僅一個： 這段關係是強制性的，且僅允許一個。
- 零個或多個： 這段關係是可選的，且允許多個。
- 一個或多個： 這段關係是強制性的，且允許多個。
考慮 訂單 與 客戶 關係。客戶必須至少下一個訂單（強制）。訂單必須屬於一個客戶（強制）。這定義了資料庫中的外鍵約束。
5. 確保資料完整性與規範化 ⚖️
圖表繪製完成後，必須檢查其邏輯一致性。此階段涉及應用規範化規則，以消除重複並確保穩定性。
第一範式（1NF）
確保每一欄都包含原子值，且沒有重複的群組。每一列都必須是唯一的。
- 檢查： 单元格中是否有清單？單一欄位是否有多个值？
- 修正： 將清單拆分為獨立的列或獨立的表格。
第二範式（2NF）
確保所有屬性都完全依賴於主鍵。若使用複合鍵，則任何屬性都不應僅依賴於該鍵的一部分。
- 範例： 在儲存 學生編號, 課程編號，且學生姓名，其中學生姓名僅依賴於學生編號，而非組合。請將學生姓名移至一個學生資料表。
第三範式（3NF）
確保不存在傳遞依賴。非鍵屬性不應依賴於其他非鍵屬性。
- 範例：如果城市依賴於郵遞區號，且郵遞區號位於客戶資料表中，則應將郵遞區號與城市移至一個位置 表格。這可防止城市名稱的更新在數千個客戶記錄之間出現不一致。
6. 審查與驗證 🧐
在根據原始需求進行驗證之前，模型並未完成。這是一次合理性檢查，以確保沒有遺漏或誤解任何內容。
走查場景
執行特定使用案例，以確認模型是否支援。可提出以下問題：
- 「我們能否在沒有客戶的情況下建立訂單？」 如果模型允許此情況，但業務規則禁止，則關係的基數設定錯誤。
- 「我們能否刪除目前出現在訂單中的產品？」 如果答案是否定的，則需要參照完整性約束（級聯刪除）。
- 「如果客戶更改了姓名，會發生什麼情況？」 如果姓名同時儲存在訂單表格中，則存在資料一致性風險。它應僅儲存在客戶表格中。
利害關係人簽核
向業務使用者展示實體關係圖（ERD）。他們可能不理解技術術語，但能理解邏輯。請他們確認實體與關係是否符合他們對業務的思維模型。
- 視覺確認： 使用圖表向他們展示資料的存放位置。
- 缺口分析： 詢問是否有任何關鍵資料點遺漏於屬性清單中。
- 未來規劃： 討論可能的變更。如果業務計劃擴展至新區域，模型是否支援此發展？
翻譯中的常見挑戰 🛑
即使經驗豐富的建模人員在翻譯需求時也會遇到障礙。了解這些陷阱有助於避免它們。
- 過度建模： 試圖預測所有可能的未來需求，會導致結構複雜且僵化。應針對當前需求進行設計，但需為擴展留有空間（例如，若合適，可使用 JSON 欄位來儲存靈活的元資料）。
- 建模不足： 忽略約束條件會導致資料混亂。若欄位為必填，則模型中不可設為可選。
- 混淆實體與關係： 有時一個關係具有太多屬性，以致於它本身變成了一個實體。（例如，註冊 與 學生 和 課程可能有一個 成績 和 日期) 如果需要獨立的歷史記錄或屬性，請將其視為實體。
- 忽略大小寫： 在某些系統中，「紐約」 和 「紐約」 是不同的。請盡早決定標準化規則。
- 假設硬體效能： 不要為了速度而犧牲完整性。執行緩慢的查詢，總比資料錯誤來得好。
永續模型的最佳實務 ✅
為了多年後仍能維持資料庫的健康狀態，請在設計階段遵循這些指南。
- 一致的命名慣例： 為實體使用單數名詞（例如，顧客 而不是 顧客們)。欄位使用小寫並以底線分隔（例如，顧客編號)。這能減少歧義。
- 文件記錄： 為你的圖表加上註解。解釋 為什麼 一個關係存在，而不僅僅是說明 存在 它存在。這有助於未來的開發人員理解業務邏輯。
- 版本控制： 將你的ERD視為程式碼。隨著需求變更，保存不同版本。這樣若某項設計決策被證明不可行，你便能回退。
- 標準化： 在可能的情況下使用標準資料類型。除非絕對必要，否則避免使用自訂類型。
- 安全考量： 尽早識別敏感資料（個人身份資訊、財務資訊）。確保模型允許在欄位層級進行加密或遮蔽。
翻譯過程的最後想法 🎯
從需求轉換到ERD並非直線過程，而是迭代的。在定義關係時，你會發現新的實體；在規範化過程中，你會不斷優化屬性。目標不是第一稿就完美，而是建立一個可持續優化的穩固基礎。
強大的資料模型能減少技術負債。它可避免因資料結構無法支援新功能而必須重構系統。透過專注於業務邏輯並應用嚴謹的翻譯技術，你將建立一個可靠、可擴展且易於維護的系統。
分析時請放慢腳步。花在細化圖表上的幾個小時，能為開發階段節省數週的除錯與重構時間。將ERD視為業務與技術之間的合約。