一、軟件生命週期中的數據庫設計步驟

軟件生命週期

數據庫設計需與軟件開發流程同步，通常分為 5 個關鍵階段，每個階段對應明確的輸出物。

1. 需求分析階段（對應軟件需求調研）

• 目標：明確業務需求與數據相關的核心訴求，避免後期返工。
• 核心動作：

1. 與產品、業務、開發溝通，梳理 “誰用數據、用什麼數據、怎麼用數據”。
2. 識別核心實體（如 “用户”“訂單”“商品”）和實體間的業務關係（如 “用户下單”“訂單包含商品”）。
3. 記錄數據的約束條件（如 “訂單金額不能為負”“用户手機號唯一”）。

• 輸出物：需求分析報告（含數據實體清單、業務關係描述、數據約束説明）。

2. 概念結構設計階段（抽象業務模型）

• 目標：將需求轉化為 “不依賴具體數據庫” 的抽象模型，聚焦業務邏輯而非技術實現。
• 核心動作：

1. 用 E-R 圖（實體 - 關係圖） 描述實體、屬性和關係（如 “用户” 實體含 “用户 ID、手機號、姓名” 屬性，與 “訂單” 實體是 “一對多” 關係）。
2. 合併重複實體，消除冗餘關係（如 “用户地址” 若僅用於訂單，可合併為 “訂單” 的屬性，無需單獨建表）。

• 輸出物：E-R 圖、概念模型説明書。

3. 邏輯結構設計階段（轉化為表結構）

• 目標：將概念模型轉化為 “對應數據庫類型” 的邏輯表結構（如 MySQL、Oracle 的表設計）。
• 核心動作：

1. 實體轉表：每個實體對應一張表，實體屬性對應表的字段（如 “用户” 實體→user表，“用户 ID”→user_id字段）。
2. 關係轉約束：

• 一對多關係：在 “多” 的表中加外鍵（如 “訂單” 表加user_id外鍵，關聯 “用户” 表的user_id）。
• 多對多關係：新增中間表（如 “學生” 和 “課程” 多對多，新增student_course表，含student_id和course_id雙外鍵）。

3. 字段設計：指定字段類型（如 “手機號” 用varchar(11)而非int）、長度、主鍵、非空、唯一約束等。

• 輸出物：邏輯表結構文檔（含表名、字段名、類型、約束、備註）。

4. 物理結構設計階段（優化存儲與性能）

• 目標：結合具體數據庫特性，設計 “可落地、高性能” 的物理存儲方案。
• 核心動作：

1. 選擇存儲引擎（如 MySQL 中，讀寫頻繁的表用InnoDB支持事務，只讀表用MyISAM）。
2. 設計索引（如 “訂單表” 的order_no加唯一索引，user_id加普通索引，提升查詢速度）。
3. 分庫分表規劃（若數據量超大，如 “訂單表” 按時間分表，按用户 ID 分庫）。
4. 指定字符集（如全表用utf8mb4支持 emoji 和特殊字符）。

• 輸出物：物理表結構腳本（可直接執行的CREATE TABLE語句）、索引設計文檔。

5. 實現與維護階段（落地與迭代）

• 目標：創建數據庫表，上線後持續優化。
• 核心動作：

1. 執行建表腳本，初始化基礎數據（如 “字典表” 的初始數據）。
2. 上線後監控性能：若查詢變慢，優化索引；若數據量超預期，調整分庫分表策略。
3. 需求變更時：同步修改表結構（如新增 “訂單備註” 字段，需執行ALTER TABLE語句），並更新設計文檔。

• 輸出物：數據庫建表腳本、運維監控報告、表結構變更記錄。

二、功能架構介紹（數據庫設計的 “上層依賴”）

功能架構是軟件的 “功能模塊劃分”，決定數據庫設計的 “範圍和粒度”，兩者需一一對應。

1. 功能架構與數據庫的關係

功能架構的每個模塊，對應數據庫中的一組表；模塊間的交互，對應表間的關聯。例如，電商系統的功能架構通常分 4 大模塊，對應的數據表如下：

能模塊	核心功能	對應數據表
用户模塊	註冊、登錄、個人信息管理	user（用户表）、user_address（地址表）
商品模塊	商品展示、分類、庫存管理	product（商品表）、category（分類表）、inventory（庫存表）
訂單模塊	下單、支付、訂單查詢	order（訂單表）、order_item（訂單項表）、payment（支付表）
營銷模塊	優惠券、積分	coupon（優惠券表）、user_points（積分表）

2. 功能架構對數據庫設計的影響

• 模塊邊界決定表邊界：避免跨模塊設計表（如 “訂單備註” 不應放在 “商品表” 中，需歸到 “訂單模塊” 的order表）。
• 模塊交互決定表關聯：若 “訂單模塊” 需調用 “用户模塊” 的地址信息，可通過order表的user_id關聯user_address表，而非在order表冗餘地址字段。

三、需求文檔介紹（數據庫設計的 “依據來源”）

需求文檔是描述 “軟件要做什麼” 的核心文檔，數據庫設計需 100% 基於需求文檔，避免主觀臆斷。

1. 需求文檔的核心組成部分

• 業務背景：説明軟件的應用場景（如 “電商平台，服務 C 端用户購物”），明確數據庫設計的業務邊界。
• 功能需求：分模塊描述具體功能（如 “用户模塊需支持手機號註冊，訂單模塊需記錄下單時間、支付狀態”），是表字段和表關係的直接來源。
• 非功能需求：

• 性能需求（如 “訂單查詢響應時間≤1 秒”，決定是否需設計索引）。
• 數據量需求（如 “預計 3 年訂單數據達 1 億條”，決定是否需分表）。
• 安全需求（如 “用户密碼需加密存儲”，決定user表的password字段需存加密後的值）。

• 數據字典：定義核心數據的格式、取值範圍（如 “支付狀態：0 - 未支付，1 - 已支付，2 - 退款中”），對應表字段的enum類型或字典表。

2. 需求文檔的作用

• 明確 “設計邊界”：避免設計冗餘表（如需求中未提 “用户積分”，則暫不設計user_points表）。
• 減少 “變更成本”：若需求文檔明確 “訂單僅關聯一個地址”，則無需設計 “訂單 - 地址” 多對多的中間表，後期無需修改表結構。

四、如何閲讀需求文檔（提取數據庫設計關鍵信息）

閲讀需求文檔的核心目標是 “精準提取數據相關信息”，避免遺漏或誤解，可按以下 4 步操作：

1. 先看 “業務背景”，明確整體方向

• 重點關注：軟件的用户是誰、核心業務流程是什麼（如電商的 “瀏覽商品→加購→下單→支付” 流程）。
• 目的：建立 “業務腦圖”，預判核心實體（如電商流程中，必然有 “用户、商品、訂單” 等實體）。

2. 再看 “功能需求”，提取 “實體、屬性、關係”

• 提取實體：從功能描述中找 “名詞”（如 “用户註冊” 中的 “用户”，“創建訂單” 中的 “訂單”）。
• 提取屬性：從功能描述中找 “形容詞 / 數值”（如 “用户需填寫手機號、姓名”→“手機號、姓名” 是user表的屬性；“訂單需記錄金額、下單時間”→“金額、下單時間” 是order表的屬性）。
• 提取關係：從功能描述中找 “動詞”（如 “用户下單”→“用户” 與 “訂單” 是 “一對多” 關係；“訂單包含多個商品”→“訂單” 與 “商品” 是 “多對多” 關係，需中間表order_item）。

3. 關注 “非功能需求”，確定設計約束

• 性能需求：若 “商品列表頁需支持百萬級數據分頁查詢”，則product表需設計 “分類 ID” 索引、“上架時間” 索引。
• 數據量需求：若 “用户表預計 5 年達 5000 萬條”，則需考慮分庫（按user_id哈希分 3 個庫）。
• 安全需求：若 “用户手機號需脱敏展示”，則user表的phone字段需存原始值，查詢時通過函數脱敏（而非存脱敏後的值，避免無法用於登錄）。

4. 核對 “數據字典”，統一字段設計

• 重點關注：核心數據的取值範圍、格式要求（如 “支付狀態” 的取值為 0/1/2，對應 “未支付 / 已支付 / 退款中”）。
• 操作：將數據字典的定義轉化為表字段的約束（如 “支付狀態” 字段用tinyint類型，且通過CHECK約束或枚舉類型限制取值）。

總結

數據庫設計是 “從業務需求到技術落地” 的轉化過程：需先通過需求文檔明確業務邊界，結合功能架構劃分模塊，再按 “需求分析→概念設計→邏輯設計→物理設計→維護” 的步驟落地，最終實現 “滿足業務、性能最優、易於維護” 的數據庫方案。