为什么要先"设计"数据库？
想象你要开一家网上书店。你一上来就打开 MySQL，噼里啪啦建了一堆表：
user、book、order⋯⋯两周后老板说"我还想支持会员等级、优惠券、拼团"。
你打开数据库一看——坏了，整个结构得重做。
数据库设计，就是在写第一行 SQL 之前，先把业务需求想清楚、把数据结构画明白的 工程化过程。这一章我们从"宏观地图"开始，理清整个设计之路的 6 个阶段， 然后深入第一站：需求分析——整个设计的地基。
本章路线图
本章共 5 节，建议学习节奏如下：
第 一 部 分
11.1数据库设计的任务和内容
一句话理解：数据库设计要干什么？
📖 官方定义
对于给定的业务描述和应用环境，通过合理的数据分析、设计和组织方法，综合
DBMS 特性以及系统支撑环境特性，构造最为适合的数据库模式，建立数据库及其
应用系统，使之能可靠、有效地满足用户的信息处理要求。
💬 人话翻译
给你一份"客户要什么"的说明 + 一个"技术环境长什么样"的清单，
你要把它变成一个能跑、跑得稳、改起来不崩的数据库 + 应用系统。
关键词有三个：业务对、性能够、结构稳。
数据库设计的输入与输出
📝 业务描述
🖥️ 应用环境
➜
数 据 库 设 计DATABASE DESIGN
⬆ DBMS 选型
⬆ 支撑环境
➜
🗄️ 关系模式
💼 业务系统
数据库设计的两大内容
数据库设计不是只设计表，而是"结构 + 行为"两条线并行推进：
静态模型设计
结构设计
根据给定的应用环境，进行数据库的子模式或模式的设计。
—— 也就是"表怎么建、字段怎么设、主外键怎么连"
—— 也就是"表怎么建、字段怎么设、主外键怎么连"
动态模型设计
行为设计
数据库用户的行为和动作设计，需要通过应用程序实现，
可看作应用程序或业务逻辑的设计。
—— 也就是"用户点一下按钮，数据是怎么流动的"
—— 也就是"用户点一下按钮，数据是怎么流动的"
💡 记住这把尺
结构像"房子的地基和承重墙"——一旦定下来，改动代价非常大；
行为像"房间里的家具摆放"——可以边住边调。
所以数据库设计里，结构设计是核心中的核心。
数据库设计的三类方法
1直观设计法
2规范设计法
3计算机辅助设计法
规范设计法 — 本课程重点
重点E-R 模型方法
重点范式理论方法
视图方法
💬 三种方法的区别
直观：凭经验一拍脑门就上手——适合极小系统。规范：有章可循、有理论依据——这一章到 13 章讲的全都是这个流派。
计算机辅助：用 PowerDesigner、Navicat、MySQL Workbench 等工具辅助建模和校验。
Q1. 在数据库设计中，设计"用户下单后，订单数据如何流转、如何扣库存、如何生成支付记录"——属于下面哪一类？
✅ 答案：B 行为设计
"下单→扣库存→生成支付"描述的是数据怎么流动、业务怎么发生，属于动态模型， 由应用程序实现。如果题目改成"订单表应该有哪些字段、和商品表怎么关联"，那才是结构设计。
"下单→扣库存→生成支付"描述的是数据怎么流动、业务怎么发生，属于动态模型， 由应用程序实现。如果题目改成"订单表应该有哪些字段、和商品表怎么关联"，那才是结构设计。
第 二 部 分
11.2数据库设计的 6 个阶段
数据库设计不是"想到哪建到哪"，而是一条清晰的流水线。 每一个阶段都有明确的输入、输出和任务：
全景流程图
◀ 结构设计线
主流程
行为设计线 ▶
📥 业 务 需 求
▼
① 数据库系统规划
▼
数据模型分析
② 需求分析
功能模型分析
▲▼▼▲▼
概念结构设计
③ 设 计
系统架构设计
逻辑结构设计
（含三子项）
系统模块设计
物理结构设计
系统程序设计
▼▼▼
数据库实现
④ 实 现
程序编码和调试
▼▼▼
测试数据加载
⑤ 加 载 和 测 试
系统测试
▼
⑥ 运 行 维 护
💡 看图记住三条线
中间蓝色是主流程 6 阶段；左绿色是每个阶段对应的
"结构设计"任务；右橙色是对应的"行为设计"任务。
两条副线不是独立的，而是围绕主流程并行推进、双向交换信息。
6 个阶段各做什么？（点击展开详情）
1 数据库系统规划阶段 — 要不要做？
结合业务需求，对数据库系统进行可行性分析和规划，
判断是否有必要分析、设计和开发该数据库系统。
项目经理/架构师要先回答：值不值得做？能不能做？预算够不够？
2 需求分析阶段 — 要做什么？
综合运用面向过程或面向对象分析方法，收集与业务相关的数据资源和业务描述，
使用数据流图、用例图等工具，抽象满足业务需求的
数据模型（数据项）和功能模型。
这是本章第 11.4、11.5 节重点讲的内容，也是整个设计的地基。
3 设计阶段 — 怎么做？
根据需求分析阶段的数据模型和功能模型，获取满足业务需求的
数据库结构和程序结构。包括三个子阶段：
概念结构设计（E-R 图）→ 逻辑结构设计（关系模式）→ 物理结构设计（索引、存储）。
第 12 章、第 13 章会分别展开讲这三个子阶段。
4 实现阶段 — 代码落地
根据设计结果，完成数据库和程序的实现工作。
写 CREATE TABLE、写存储过程、写后端代码——这就是动手敲键盘的阶段。
5 加载和测试阶段 — 是不是对？
实现数据库和程序后，通过数据加载、软件测试等手段，
测试实现内容是否满足需求分析要求。
回头对账：当初说好的功能现在都实现了吗？性能扛得住吗？
6 运行和维护阶段 — 长期服役
系统正式上线后，持续进行性能监控、故障排查、数据备份、需求变更响应等日常工作。
上线不是结束，而是"长期服役"的开始——往往占项目总成本的 60% 以上。
Q2. 以下哪些任务属于"设计阶段"的工作？（多选，选对不漏、错选或漏选不得分）
✅ 答案：A、B、D
"设计阶段"包含概念→逻辑→物理三个子阶段（A、B、D）。
C 中"数据流图"属于需求分析阶段的工具（11.5 节重点）； E 属于加载和测试阶段。
"设计阶段"包含概念→逻辑→物理三个子阶段（A、B、D）。
C 中"数据流图"属于需求分析阶段的工具（11.5 节重点）； E 属于加载和测试阶段。
☕ 课间停一停（约 5 分钟）
前两节我们完成了"宏观地图"——数据库设计是什么、有几个阶段。
下半节我们要进入第一站：走到真实案例里，学习需求分析怎么做。
👀 休息一下眼睛，回来后请试着用自己的话复述 6 个阶段的名字。
下半节我们要进入第一站：走到真实案例里，学习需求分析怎么做。
👀 休息一下眼睛，回来后请试着用自己的话复述 6 个阶段的名字。
第 三 部 分
11.3设计案例描述：电子商务系统
接下来 11.3 ~ 11.5 三节都围绕同一个案例展开——一个小型电子商务系统。 为什么选它？因为电商是目前使用最为广泛的一类数据库系统，其关键业务所涉及的数据库 设计方案涵盖了常规数据库系统的所有设计结构——从商品、用户、订单到库存，麻雀虽小五脏俱全。
案例中的两个核心业务部门
📖 业务描述
商品采购部门由专人记录从供应商采购各类商品的信息，并将采购信息记录在采购台账中。
商品编号1100****112
商品名称数据库原理及应用教程（第 4 版）
商品类别图书/教材
商品单价4*.5 元
生产厂家人民邮电出版社
入库时间2020-2-11 11:15:25
商品概述全面系统讲解了数据库技术的基本原理和应用，全书共 7 章。
供 应 商****供货公司 186****8965 186****8965@com
供货数量100 册
⚠️ 请观察
这份"台账"里什么都混在一起——商品信息、供应商信息、入库记录……
如果你直接把它变成一张表，会有什么问题？（提示：供应商的电话一改，100 条商品记录全要改）
这就是我们为什么需要"分解"——之后 11.5 节会详细讲。
📖 业务描述
商品销售部由专人记录每次商品销售的订单情况，并将订单信息记录在销售台账中。
订单号20200410140000001
提交时间2020-4-10 17:03:28
联系人李** 性别：女
快递地址北京市海淀区成府路***号，100083
手机138****2876
电子邮箱li******@163.com
物流信息565******** 中国邮政快递
订单明细
| 编号 | 名称 | 数量 | 单价 |
|---|---|---|---|
| 1100****112 | 数据库原理及应用教程（第四版） | 5 | 4*.5 |
| 2120****109 | 联想笔记本电脑 E14 | 2 | 55**.6 |
订单总计112***.3 元 状态：已完成
⚠️ 同样的问题
联系人的手机号、快递地址、物流公司……通通塞在一张"台账"里。
如果同一个联系人又下了 10 个订单，地址就要重复存 10 次！
这就是数据冗余——我们设计数据库的重要敌人之一。
💡 案例给我们的启发
现实中的"台账"本质上就是一张大宽表——简单、直观，但冗余严重、维护困难。
数据库设计要做的，就是把这张大宽表合理地拆分成多张小表，
用主外键关联起来。而拆的第一步，就是从需求分析开始。
第 四 部 分
11.4需求分析：任务与方法论
需求分析到底要做什么？三件事
STEP 1 · 调查
调查分析用户活动
对相关用户的业务或旧系统进行分析，收集业务相关原始资料，
明确未来系统开发的需求目标，确定这个目标的功能域和数据域。
STEP 2 · 转换
转换业务需求，
确定系统边界
确定系统边界
在熟悉业务活动的基础上，使用规范化分析方法，与用户共同明确对新系统的
功能性需求、信息需求、非功能性需求等。
STEP 3 · 编写
编写需求分析
规格说明书
规格说明书
系统需求分析阶段的最后产出物，是《系统需求分析规格说明书》。
编写过程是不断反复、逐步深入、逐步完善的。
💬 想象一个画面
三个步骤就像一个记者在做调查报道：
先去现场采访（调查），再把采访内容理清楚（转换），
最后写成一篇报道（规格说明书）——并且要反复修改到发稿。
两种思维路径：自顶向下 vs 自底向上
自顶向下（Top-Down）
采用逐层分解的方式，将已知的宏观业务需求按执行部门、涉及岗位
或角色等原则，划分为相对具体的子业务需求；如果子需求还可细分，则再次分解，
直到分解到基本功能点为止。
自底向上（Bottom-Up）
采用逐层组合的方式，将已知业务需求按协同原则构成更复杂、
更宏观的业务需求；如果构成的新需求不满足目标，就继续组合，
直到组合后的需求满足目标为止。
💡 记忆小口诀
自顶向下 = 切蛋糕（从大往小切，分到每一口能吃下为止）；自底向上 = 拼积木（从小往大拼，直到拼成设想的城堡）。
真实项目中两者经常配合使用——先自顶向下搭骨架，再自底向上补细节。
Q3. 某公司要做"企业 ERP 系统"，项目经理先把系统分为"采购"、"销售"、"财务"、"人事"
四大模块，再把"采购"分为"询价、下单、入库、付款"四个子功能——这体现的是哪种需求分析方法？
✅ 答案：A 自顶向下
题目描述的是"先定大模块，再细分小功能"——典型的从宏观往微观切。 下一节我们画数据流图时，用的也正是这种方法（顶层 → 0 层 → 1 层）。
题目描述的是"先定大模块，再细分小功能"——典型的从宏观往微观切。 下一节我们画数据流图时，用的也正是这种方法（顶层 → 0 层 → 1 层）。
第 五 部 分
11.5案例需求分析：数据流图 & 数据字典
这一节是本章最重要的一节。我们要学两个工具： 一个用来"画"（数据流图 DFD），一个用来"写"（数据字典 DD）。 并用它们，完成电商案例的需求分析。
工具 ①：数据流图（Data Flow Diagram, DFD）
📖 定义
数据流图是一种常用的自顶向下需求分析工具。
用于描述：数据从哪里来、经过什么处理、最终存到哪里。
DFD 的 4 个基本符号
外部实体
数据来源或去向（人、组织、外部系统）
处理（加工）
对数据的变换、计算、处理过程
数据存储
数据库、文件或中间存储区
数据流
数据在系统内的传输路径（带名字的箭头）
💬 一个小例子：财务报销流程
报销人（外部实体）→ 交上 报销单（数据流）→
经过 审核（处理）→ 把 报销登记 存入 数据存储 →
同时输出 付款信息（数据流）到 付款凭证。
工具 ②：数据字典（Data Dictionary, DD）
📖 定义
数据字典是对系统中数据资源结构和处理过程的详细描述，
是各类数据结构和属性的清单。
数据字典包含 5 大类条目：
数据项
最小的数据单位。内容：
数据项名、含义说明、别名、类型、长度、取值范围、与其他数据项的关系。
数据结构
有意义的数据项集合。内容：数据结构名、组成的数据项。
数据流
数据在系统内传输的路径。内容：数据流名、说明、
流出过程、流入过程。
数据存储
处理过程中数据的存放场所——通常是数据库、文件或其他业务处理过程。
处理过程
描述数据处理逻辑。内容：处理过程名、说明、
输入、输出、处理（简要说明）。
💡 DFD 和 DD 的关系
DFD 是画出来的图，DD 是配套的解释文档。
就像地图和图例——图上每一条"数据流"是什么意思、每一个"处理"具体做什么，都要在数据字典里写明。
案例实战：自顶向下画 3 层 DFD（点击切换）
围绕电子商务案例，我们用自顶向下的方法，逐层分解出 3 层数据流图。 请依次点击下面三个按钮观察变化：
第 1 步：顶层 DFD（最粗颗粒）
系统被抽象成一个大处理——"商品采购销售"，外接操作人员，内接两个台账。 这一层给出的台账结构，和现实业务的原始台账差不多——数据还是杂糅在一起的。 所以我们要继续分解。
系统被抽象成一个大处理——"商品采购销售"，外接操作人员，内接两个台账。 这一层给出的台账结构，和现实业务的原始台账差不多——数据还是杂糅在一起的。 所以我们要继续分解。
第 2 步：0 层 DFD（把大处理拆成两个）
将原本的"商品采购销售"拆成两个独立处理：商品采购业务 和 商品销售业务， 销售时还需要从库存表查询商品信息。 但台账结构仍然没有变——冗余问题还在，所以还要继续分解。
将原本的"商品采购销售"拆成两个独立处理：商品采购业务 和 商品销售业务， 销售时还需要从库存表查询商品信息。 但台账结构仍然没有变——冗余问题还在，所以还要继续分解。
第 3 步：1 层 DFD（充分分解）
现在可以看到：用户登录、商品采购入库、查询销售商品、订单生成、物流状态查询 成了独立的处理；台账也被拆成了 5 个专门的数据存储： 用户信息表、登录成功凭证、商品库存表、系统订单表、收货地址表。
现在，每个存储结构都是"高内聚、低冗余"的—— 这就是我们需求分析阶段想达到的状态！
现在可以看到：用户登录、商品采购入库、查询销售商品、订单生成、物流状态查询 成了独立的处理；台账也被拆成了 5 个专门的数据存储： 用户信息表、登录成功凭证、商品库存表、系统订单表、收货地址表。
现在，每个存储结构都是"高内聚、低冗余"的—— 这就是我们需求分析阶段想达到的状态！
案例的数据字典（最终产出）
根据 1 层 DFD，我们抽象出 5 个核心数据结构，构成本案例的数据字典：
| 数据结构名称 | 数据项内容 |
|---|---|
| 用户信息 | 登录用户名、登录用户密码、忘记密码邮箱 等 |
| 登录凭证 | 用户名、登录时间 等 |
| 商品库存 | 商品编号、名称、类别、生产厂家、入库时间、概述、库存量、供应商信息 等 |
| 系统订单 | 订单编号、提交时间、订单总计、订单状态、销售商品、物流信息 等 |
| 收货地址 | 联系人、性别、快递地址、手机、电子邮箱 等 |
💡 承上启下
有了5 个数据结构，下一章（第 12 章）我们就要基于它们，
画出概念模型 E-R 图——把数据结构变成实体和联系。
然后再转换成关系模式（第 13 章）。你会看到整个 6 阶段流水线真正"流动"起来。
Q4. 关于数据流图 DFD 和数据字典 DD，下列说法正确的是？
✅ 答案：A、B、D
C 错：分解要适可而止，分到能抽象出清晰数据结构即可， 过度分解反而让设计变重。
E 错：处理过程必须包含输入（数据流）、输出（数据流）、处理简要说明， 少一项都不完整。
C 错：分解要适可而止，分到能抽象出清晰数据结构即可， 过度分解反而让设计变重。
E 错：处理过程必须包含输入（数据流）、输出（数据流）、处理简要说明， 少一项都不完整。
动 手 练 习
课堂练习：图书管理系统需求分析
场景设定：某高校图书馆准备开发新版图书管理系统。核心业务包括——
读者注册、图书借阅、图书归还、逾期罚款、图书采购入库。
请你作为系统分析师，独立完成以下任务。
20:00
- 列出系统中的外部实体（至少 3 个），说明它们与系统的交互内容。
- 画出本系统的顶层数据流图（最宏观的那一张，只有一个大处理）。
- 把顶层 DFD 分解成 0 层 DFD——至少包含"借阅处理"、"归还处理"、"图书入库"3 个处理。
- 从 0 层 DFD 中抽象出 3~5 个数据结构，仿照 23 页表格写出数据字典。
- （进阶）指出你设计中哪些数据还存在冗余，如果要继续分解到 1 层 DFD，你会拆什么？
参考思路（不是唯一答案）：
- 外部实体：读者、图书采购员、图书管理员、供应商（供书方）。
- 顶层：读者/采购员/管理员 → 【图书流通管理】大处理 → 输出到【图书台账】【借阅台账】两个存储。
- 0 层：可拆为「读者登录/验证」「借阅处理」「归还处理」「图书采购入库」「逾期罚款」5 个处理；存储拆为读者信息表、图书信息表、借阅记录表、罚款记录表。
- 数据字典建议：
- 读者信息：读者编号、姓名、院系、联系方式、注册时间等
- 图书信息：图书编号、书名、作者、出版社、ISBN、库存量、分类号等
- 借阅记录：借阅流水号、读者编号、图书编号、借出时间、应还时间、实还时间、状态
- 罚款记录：罚款编号、借阅流水号、逾期天数、罚款金额、缴费状态
- 进一步分解提示："借阅处理"里其实包含读者资格验证、可借数量校验、更新库存、生成借阅记录 4 个子过程，可以在 1 层 DFD 里拆开。
💡 判分要点：不要求和参考答案一字不差，看三件事——
（1）符号用得对不对；（2）分解有没有"减少冗余"；
（3）数据字典是否涵盖了图中出现的所有存储。
本 章 小 结
📋 回顾一下，我们走过的路
本章我们从宏观到微观，建立了数据库设计的认知框架：
先理解数据库设计干什么、含哪些内容、有哪些方法；
然后理顺 6 大阶段的流水线；再聚焦到"需求分析"，学会用
数据流图 + 数据字典这两件工具，通过电商案例完成了一次从 0 到 1 的分解。
🎯 核心观念
数据库设计 = 结构设计（建表）+ 行为设计（业务逻辑），两者并行。
📐 6 阶段顺序
规划 → 需求分析 → 设计 → 实现 → 加载测试 → 运行维护
🔍 需求分析三件事
调查用户活动 → 转换业务需求 → 编写规格说明书
⬇⬆ 两种分析路径
自顶向下（切蛋糕）+ 自底向上（拼积木），实战中常配合使用
🧰 DFD 4 符号
外部实体（矩形）· 处理（圆形）· 数据存储（两线）· 数据流（箭头）
📚 DD 5 条目
数据项 · 数据结构 · 数据流 · 数据存储 · 处理过程
⚠️ 容易踩的坑
（1）把"结构设计"和"行为设计"搞混——问字段怎么定是结构，问业务如何流转是行为。（2）需求分析草草跳过——地基没打好，后面盖楼迟早要返工。
（3）DFD 画到"大而全"就停——没有检查每个数据存储是否已经内聚化、低冗余。
🚀 下一章预告
第 12 章：数据库概念结构设计——我们将把本章得到的 5 个数据结构，
翻译成可视化的 E-R 图（实体-联系模型），
这是数据库设计中最有"工程美感"的一步。