系統闡述資料庫設計六大階段流程、IDEF1X 概念模型建模步驟、邏輯/物理設計原則、正規化標準、建模工具選型，並提煉 20+ 實戰技巧 (命名規範、欄位設計、鍵與索引策略、變化預留、審計欄位等)，為資料庫架構師與開發人員提供完整參考依據。
一、資料庫設計六大階段流程
- 需求分析： 收集調查 → 數據字典 (數據項/結構/流/存儲/處理) + 數據流圖 (DFD) → 結構化分析 (SA 法) 自頂向下分解
- 概念結構設計： 獨立於 DBMS 的概念模型 → E-R 圖 → IDEF1X 方法 (實體定義 → 聯繫定義 → 識別碼定義 → 屬性定義 → 其他物件/規則)
- 邏輯結構設計： E-R 轉關係模型 (實體→表、m:n→關聯表、1:n→外鍵合併或獨立、1:1→合併) → 正規化優化至 3NF (單一事實單一位置、唯一鍵識別、無非鍵傳遞依賴)
- 物理設計： 依 DBMS 特點選擇儲存結構、存取方法、索引策略、分區、叢集
- 實施： DDL 建構 → 數據載入 → 應用開發除錯 → 試運行
- 運行維護： 備份恢復、安全完整性、效能監控分析優化、重組重構
二、IDEF1X 概念模型建模五步驟
- 第零步 初始化： 確定目標、計劃、隊伍、收集源材料 (業務流程、報表、舊系統 I/O) → 基礎數據資料表
- 第一步 定義實體： 從源材料名詞、帶「代碼」後綴術語識別潛在實體 → 初步實體表
- 第二步 定義聯繫： 僅二元聯繫 (n元拆解) → 實體聯繫矩陣識別關係 → 判斷識別/非識別 (強制/可選)、分類聯繫
- 第三步 定義碼： 引入交叉實體消除非確定聯繫 → 候選碼 → 主碼 → 非空/非多值規則驗證 → KB 圖 (鍵基視圖)
- 第四步 定義屬性： 從源數據抽取說明性名詞 → 完整屬性視圖 (滿足 3NF：完全依賴、無傳遞依賴)
- 第五步 定義其他物件： 資料類型/長度/精度/非空/預設值/約束、觸發器/預存程序/視圖/角色/同義詞/序列
三、E-R 轉關係模型七大轉換原則
| 來源 | 目標關係模式 | 鍵 |
|---|
| 實體型 | 一個關係模式 | 實體碼 = 關係碼 |
| m:n 聯繫 | 一個關係模式 | 各實體碼組合 = 關係碼 |
| 1:n 聯繫 | 獨立模式 或 與 n 端合併 | 獨立時 n 端碼 = 關係碼 |
| 1:1 聯繫 | 獨立模式 或 與任一端合併 | 視合併方向而定 |
| 多元聯繫 (≥3 實體) | 一個關係模式 | 各實體碼組合 |
| 自聯繫 | 依 1:1/1:n/m:n 處理 | 同上 |
| 相同碼關係模式 | 合併 | 共用碼 |
四、建模工具選型指南
| 工具 | 廠商 | 特色 | 適用場景 |
|---|
| Rational Rose | IBM/Rational | UML 全棧、模型驅動開發 | 大型企業級、模型驅動團隊 |
| ERwin (ER Studio) | CA/erwin Inc. | IDEF1X 專精、邏輯/物理雙模型、自動轉型、支援多種 DBMS | **資料庫設計首選**、需求分析後畫 ER 圖生成 DDL |
| BPwin | CA | 業務流程建模 (IDEF0/IDEF3) | 流程梳理階段 |
| PowerDesigner | Sybase/SAP | CDM/PDM/LDM 三層模型、強大逆向工程、版本管理 | 資料架構治理、多平台部署 |
| Oracle Designer | Oracle | 與 Oracle 產品棧深度整合 | 純 Oracle 技術棧專案 |
五、實戰技巧精華 20+ 條
階段 0：需求分析前
- 深度理解客戶需求，持續確認變化
- 熟悉企業業務，開發期節省大量溝通成本
- 重視輸出導向設計：先看報表/查詢/視圖，反推必要表與欄位 (例：郵遞區號需獨立欄位支援排序分組)
- 建立數據字典 + ER 圖：任何人可快速理解數據獲取方式
- 制定標準化物件命名規範 (表/欄/索引/約束/視圖/序列)
階段 1：表與欄位設計 (邏輯設計)
表設計三原則
- 正規化與標準化： 3NF 平衡效能/擴展性/完整性。核心：「One Fact in One Place」—— 表僅含本質屬性，關聯靠外鍵。例：`Customer` + `Order` (含 `customer_id` FK)。效能需求下可適度反正規化。
- 數據驅動而非硬編碼： 連接資訊、工作流參數、角色權限存入資料表，賦能用戶自維護，增強彈性擴展性。
- 預留變化維度： 如姓名變更 (婚姻/改名) → 獨立 `name_history` 表含生效/失效日期，保留完整軌跡。
欄位設計七原則
- 三大通用審計欄位： `dRecordCreationDate` (預設 `GETDATE()`)、`sRecordCreator` (預設 `USER`)、`nRecordVersion` (樂觀鎖/變更追蹤)
- 地址/電話拆分多欄： `Address_Line1/2/3`、電話/郵件獨立表含類型標籤
- 角色實體模式化分類： `Person` + `Person_Type` (Associate/Engineer/Director/CIO) + 關係表含日期，實現自我文檔化與時間旅行
- 數值/字串長度留裕度： `SMALLINT` 上限 32767 易溢位 → 用 `INT`/`BIGINT`；ID 類字串預留 2-3 位額外長度 (10 位 → 定 12-13)，避免重構
- 軟刪除標記欄位： `is_deleted`/`deleted_at` 替代物理刪除，維護索引完整性，支援恢復/稽核
- 避免索引大型文本/BLOB： 佔用空間大、維護成本高
- 小表不建索引： 掃描成本低於索引維護成本，尤其頻繁增刪時
階段 2：鍵與索引策略
鍵設計四原則
- 關聯欄位建外鍵
- 所有鍵必須唯一
- 避免複合鍵 (單欄代理鍵優先)
- 外鍵必須關聯唯一鍵
代理鍵 (Surrogate Key) 最佳實務
- 系統生成 (Identity/Sequence) 作為主鍵，控制索引完整性、統一鍵結構、易發現邏輯缺陷
- **禁止使用用戶可編輯欄位作主鍵** (業務鍵加 `UNIQUE` 約束即可)
- 候選鍵 (Alternate Key) 可輔助建立強力索引
索引使用四原則
- 邏輯主鍵 → 唯一叢集索引；系統鍵 → 唯一非叢集索引；外鍵欄 → 非叢集索引
- **別忘記索引外鍵** — 連接查詢高頻使用
- 不索引 `MEMO`/`NOTE`/大字串欄位
- 小表、高頻增刪表不建索引
六、總結
資料庫設計是系統架構基石。遵循標準化流程 (SA → IDEF1X → 3NF)、選用專業工具 (ERwin/PowerDesigner)、貫徹命名與審計規範、預留業務變化維度、採用代理鍵與索引策略，方能構建高效能、可擴展、易維護的資料資產。設計即文檔，文檔即資產。
