資料庫設計是任何穩健軟體應用的骨幹。在建構處理複雜資料的系統時，可擴展架構與脆弱混亂之間的差異，往往取決於你如何組織資訊。在這結構的核心，存在三個基本支柱：實體、屬性與關係。理解這些概念對開發人員而言並非可有可無，而是創造可維護、高效且邏輯清晰的資料模型所不可或缺的。
實體關係圖（ERD）是這些結構的藍圖。它能直觀呈現資料如何連結、儲存，以及在系統中如何流動。若未能清楚掌握這些核心元件，即使最先進的應用邏輯也將難以順利運作。本指南精確剖析每一項元素，確保你能夠自信且清晰地設計資料模型。
理解實體：資料的基礎 🧱
在資料庫設計的脈絡中，實體代表一個需要儲存資訊的獨立物件或概念。它是資料模型中的名詞。可將其視為現實世界或你業務領域中存在的一類事物的分類或類別。每個實體在系統的脈絡中都必須是獨特且可識別的。
實體的類型
並非所有實體都是一樣的。辨識你所處理的實體類型，有助於定義資料儲存與取得的規則。
- 強實體： 這些實體獨立存在。它們擁有自己的主鍵，且不依賴其他實體而存在。例如，一個顧客 或一個產品 可以獨立存在。
- 弱實體： 這些實體的存在依賴於強實體。若無父實體，它們無法被唯一識別。一個經典範例是訂單中的訂單項目，若無訂單的上下文，此項目在此特定結構中將無意義。訂單。若無訂單的上下文，此項目在此特定結構中將無意義。
- 關聯實體： 也稱為連結表，用以解決多對多的關係。它們連結兩個其他實體，以允許它們之間存在多重連接。
辨識實體
在設計模型時，你必須問自己哪些現實世界的物件需要被追蹤。在你的業務需求中尋找名詞。若業務規則規定你需要追蹤某事物的狀態、歷史或屬性，那麼該事物很可能就是一個實體。
請考慮以下定義有效實體的特徵：
- 獨特性： 每個實例都必須能與其他所有實例區分開來。
- 一致性： 實體的定義應在整個系統中保持一致。
- 相關性： 實體應在業務邏輯中具有實際用途。避免為那些很少被查詢或使用的資料建立實體。
屬性：定義實體屬性 🔑
一旦你確認了實體，就需要描述它們。屬性是描述實體的特徵、屬性或細節。如果實體是一張表格，屬性就是一欄。它們共同構成了你所管理的資料的完整圖像。
主鍵與外鍵
並非所有屬性都具有同等重要性。有些屬性在資料的完整性與連結中扮演關鍵角色。
- 主鍵 (PK)： 實體內記錄的唯一識別符。確保沒有兩行資料完全相同。主鍵可以是單一欄位（例如識別碼），也可以是由多個欄位組成的複合鍵。
- 外鍵 (FK)： 連結到另一實體主鍵的屬性。這建立了表格之間的關係。它強制執行參考完整性，確保一張表格中的記錄無法引用另一張表格中不存在的記錄。
屬性分類
屬性根據其儲存與推導方式有所不同。理解這些差異有助於優化儲存空間與查詢效能。
| 類型 | 描述 | 範例 |
|---|---|---|
| 簡單 | 無法再進一步分割。具有原子性。 | 電話號碼 |
| 複合 | 可再細分為子部分。 | 地址（街道、城市、郵遞區號） |
| 多值 | 可為單一實體實例儲存多個值。 | 電子郵件地址 |
| 衍生 | 由其他屬性計算而得。 | 年齡（由出生日期推導） |
屬性的最佳實務
定義屬性時，請記住以下指導原則，以確保資料品質：
- 使用描述性名稱： 避免使用像這樣的通用名稱
col1或資料。使用能說明內容的名稱，例如客戶郵件或訂單日期. - 定義資料類型： 要精確。計數使用整數，時間相關資料使用日期，文字使用字串。這可避免資料輸入與取得時發生錯誤。
- 最小化空值： 在可能的情況下，強制執行約束，以確保屬性不會留空。空值可能使查詢變得複雜，並導致意外結果。
- 資料正規化： 確保屬性僅依賴於主鍵。避免儲存可推導或移至其他實體的資料。
關係：連結各個點 🔗
實體很少孤立存在。關係定義了實體之間如何互動。它決定了資料如何連結、查詢如何結合，以及資料庫中如何維持完整性。設計良好的關係結構可防止資料重複，並確保更新正確傳播。
基數
基數定義了實體之間的數值關係。它回答了這個問題：「實體 A 的多少個實例與實體 B 的多少個實例相關？」
- 一對一 (1:1)： 實體 A 的一個實例僅與實體 B 的一個實例相關。這較為罕見，但會出現在使用者擁有一個個人檔案等情境中。
- 一對多 (1:N)： 實體 A 的一個實例與實體 B 的多個實例相關。例如，一個 部門 擁有許多 員工.
- 多對多 (M:N)： 實體 A 的多個實例與實體 B 的多個實例相關。例如，一名 學生 可以註冊多門 課程，以及一個課程可以有許多學生.
參與約束
基數告訴你數量，但參與約束告訴你關係是否為強制性的。
- 完全參與：實體的每個實例都必須參與此關係。例如，每個訂單都必須有一個客戶.
- 部分參與：實例可能參與，也可能不參與此關係。例如，一個客戶可能有，也可能沒有訂單在某一時刻。
實作策略
不同的基數需要在資料模型中採用不同的實作策略。
| 關係類型 | 實作方法 | 範例情境 |
|---|---|---|
| 1:1 | 合併表格，或在其中一側新增外鍵。 | 使用者個人檔案連結至使用者帳戶。 |
| 1:N | 在「多」的一方表格中新增外鍵。 | 員工表格包含部門編號（Dept_ID）。 |
| M:N | 建立一個包含兩個外鍵的聯結表。 | 連結學生與課程的註冊表。 |
資料庫規範化：為穩定性而設計結構 📐
雖然實體、屬性和關係構成了結構，但規範化則對該結構進行組織，以減少冗餘並提升完整性。規範化是一系列步驟，旨在確保資料依賴關係具有邏輯性。
第一範式（1NF）
在 1NF 中，每一欄都必須包含原子值。不能在單一單元格中儲存一組值。每一列都必須是唯一的，通常由主鍵來強制執行。這可消除重複群組。
第二範式（2NF）
一旦達成 1NF，2NF 確保所有非鍵屬性都完全依賴於主鍵。如果你使用複合鍵，則每個屬性都必須依賴整個鍵，而非僅僅部分鍵。
第三範式（3NF）
3NF 消除傳遞依賴。非鍵屬性不應依賴於其他非鍵屬性。例如，如果城市依賴於郵遞區號，且郵遞區號依賴於客戶編號，那麼城市依賴於客戶編號傳遞依賴。為解決此問題，應將城市移至獨立的實體，或確保其直接與鍵連結。
設計中的常見陷阱 ⚠️
即使經驗豐富的開發人員在設計資料模型時也會犯錯。了解常見陷阱可以在開發階段節省大量時間。
- 過度規範化：將資料分割成過多小型實體會使查詢變得複雜且緩慢。有時，針對讀取密集型工作負載，允許一定程度的非規範化。
- 規範化不足： 將相同資料儲存在多個位置會導致不一致。如果客戶地址變更，您必須在每個記錄中更新它。這會增加出錯的風險。
- 忽略資料類型： 使用字串來表示數字或日期會導致排序問題和驗證錯誤。務必將屬性類型與實際資料相符。
- 硬編碼值： 如果狀態碼具有特定含義，請避免以字串形式儲存。對於「狀態」或「國家」等值，應使用參考表格以維持一致性。
- 遺漏索引： 外鍵和經常查詢的屬性應建立索引，以提升查詢速度。若無索引，連接操作可能成為瓶頸。
可擴展性方面的進階考量 🚀
隨著應用程式擴大，資料模型必須持續演進。早期的設計決策會影響系統擴展的難易程度。以下是一些確保長期穩定性的考量。
處理歷史資料
商業規則會隨時間改變。過去必須的屬性可能變成可選。關係也可能發生變化。比起不斷修改結構，可考慮新增歷史欄位或使用時間表來追蹤變更。這樣可以在不破壞現有功能的情況下，進行變更審計。
安全性與存取控制
實體通常包含敏感資訊。設計您的關係以支援存取控制。例如，將使用者資料與記錄資料分離，有助於管理權限。確保外鍵不會將敏感資料暴露給未授權的使用者。
查詢效能
您結構化關係的方式會直接影響查詢效能。過於深層的嵌套關係需要多次連接，可能導致資料檢索變慢。分析您最常見的查詢，並設計實體以減少所需的連接次數。有時，將特定屬性反規範化至讀取優化的儲存空間，才是正確的選擇。
結論 🏁
掌握實體、屬性和關係的核心概念是一段持續終身的旅程。這些元素不僅是理論構建，更是您用來打造持久系統的實用工具。透過專注於清晰性、完整性與效率，您將建立能長期支援應用程式的資料模型。
從基礎開始。明確定義您的實體。正確分配描述實體的屬性。建立反映現實世界互動的關係。隨著您不斷優化這些設計，您會發現應用程式的邏輯變得更清晰且更穩健。請記住，好的設計是容易理解且容易修改的。在未來的開發工作中，請始終秉持這些原則。
投入時間進行正確的ERD設計，將帶來減少錯誤、加快開發週期以及更易維護的程式碼庫等回報。無論您是建構小型工具還是大型企業系統，實體、屬性和關係的規則始終不變。堅持基本原則，您的資料架構將經得起時間的考驗。