4.4 数据库设计
本篇定位：数据库设计回答"数据库怎么从无到有建出来"——生命周期、各阶段任务、E-R 模型到关系模式的转换。9 年真题直接命中 4 题（2020 单45/46、2021 单54、2023 单48、2025 单54），且与 4.1（E-R/关系模型）、4.3（范式规范化）、第 6 篇软件工程（生命周期/需求分析）交叉。2027 预测 0–1 题：大概率是"某设计任务属于哪个阶段"或"数据字典/再组织"概念题。 数据依据：
01-真题/真题文本/+01-真题/考点汇总/；答案以专业判断为准。 阅读提示：本章与 6.4 需求分析、6.6 软件设计（软工视角）互补：数据库设计是软工"数据流"的落地；E-R→关系转换与 4.3 范式衔接。
一、考点定位（本章真题统计）
| 考点 | 真题锚点 | 频次 | 考法 |
|---|---|---|---|
| 设计阶段任务 | 2025 单54 | 1 年 | 设计关系模式=逻辑结构设计 |
| 数据字典 | 2023 单48 | 1 年 | 数据字典=元数据（同一概念） |
| 数据库再组织/重构 | 2021 单54 | 1 年 | 性能下降→再组织重构（DBA 职责） |
| 数据审阅签字 | 2020 单46 | 1 年 | 上线前数据准确性审阅=IS 审计师 |
| 敏感数据保护 | 2020 单45 | 1 年 | 列级/行级授权访问控制 |
| E-R→关系转换 | 2022 单50 | 1 年 | 实体集/联系转关系模式计数（拉分题） |
命题规律：本章题量少但年年出现（几乎每年 1 题），全部是"概念+角色判断"：设计阶段归属、谁负责什么、数据字典是什么。2027 预测 1 题：设计阶段任务或 E-R 转换计数。核心能力：四阶段（需求→概念→逻辑→物理）各自产物分清；E-R 转关系计数规则背熟。
二、知识框架（先搭骨架）
数据库设计生命周期（六阶段，与软工生命周期呼应）
├── 需求分析：收集用户需求 → 数据字典、数据流图（DFD）
├── 概念结构设计：画 E-R 图（实体/属性/联系，与 DBMS 无关）——两步走：局部视图设计（分 E-R 图）→ 视图集成（全局 E-R 图），策略＝自底向上
├── 逻辑结构设计：E-R 图 → 关系模式（二维表）；规范化（4.3 章）
├── 物理结构设计：存储结构、索引、文件组织（4.6 章）
├── 数据库实施：建库建表、数据装载、试运行
└── 运行维护：运行监控、再组织/重构（2021 单54）
核心对应（2025 单54）：
├── 设计关系模式（表结构） = 逻辑结构设计阶段
├── 画 E-R 图 = 概念结构设计阶段
└── 定存储/索引 = 物理结构设计阶段
E-R 图 → 关系模式转换规则（2022 单50，拉分计算）
├── 每个实体集 → 一张表，实体属性=表的列，实体主键=表的主键
├── 1:1 联系：不建表 → 把"另一端主键"加到任一端表里当外键（选一端即可）
├── 1:n 联系：不建表 → 把"1 端主键"加到"n 端"表里当外键（只能加 n 端）
├── m:n 联系：必须单独建表 → 新表主键=两端主键的组合，两列同时是外键
└── 计数规则：关系数 = 实体数 + m:n 联系数；主键数 = 关系数；外键数 = 联系总数 + m:n 联系数
★ 口诀：表数看实体，外键只看联系（实体再多也不产生外键）
（2022 单50 验证：10 实体 + 12 联系（5 个 m:n）→ 关系 15、外键 17）
数据字典（2023 单48）
├── 定义：关于数据库的元数据（描述数据的数据）
└── 内容：表结构、视图定义、索引、完整性约束、用户权限等
一句话记忆：四阶段（需求→概念 E-R→逻辑关系模式→物理存储）→ 产物各不同（DFD/E-R/表/索引）→ E-R 转关系（实体建表、1:n 并入 n 端、m:n 单独建表）→ 数据字典=元数据 → 运维期再组织重构。
三、考点详解
3.1 数据库设计六阶段（2025 单54）
精确定义：数据库设计 = 根据用户需求，设计数据库的结构（模式）与行为（应用）的过程。经典六阶段：
| 阶段 | 主要任务 | 产物 |
|---|---|---|
| 1 需求分析 | 收集数据需求、处理需求 | 数据字典、数据流图 |
| 2 概念结构设计 | 建立概念模型（与 DBMS 无关） | E-R 图 |
| 3 逻辑结构设计 | 概念模型→数据模型（关系模式） | 关系模式（表） |
为什么说"E-R 图与 DBMS 无关"（三个层次的耦合度，一句话判死）：
| 层次 | 产物 | 与 DBMS 的关系 | 原因 |
|---|---|---|---|
| 概念模型 | E-R 图 | 无关 | 描述现实世界的信息结构（实体/属性/联系），既不依赖数据模型类型，也不依赖具体产品 |
| 逻辑模型 | 关系模式（表） | 只与"数据模型类型"有关 | 先选定关系模型才有表；但不绑定具体产品（MySQL/Oracle 都能实现） |
| 物理模型 | 存储结构、索引、分区 | 强相关 | 页大小、索引类型、分区策略都是厂商相关的 |
判死句：E-R 图是概念模型，面向"用户与现实世界"，不面向机器 —— 同一条 E-R 图可以落成关系库、也可以落成对象库/网状库，所以"与 DBMS 无关"是对的。 ⚠️ 常见错项："概念结构设计要考虑 DBMS 的性能与存储"（那是物理设计）、"E-R 图要遵守所选数据库产品的语法"（那是逻辑/物理）—— 两句都错。 | 4 物理结构设计 | 存储结构、索引、存取路径 | 物理存储方案 | | 5 数据库实施 | 建库、装载数据、试运行 | 可运行数据库 | | 6 运行维护 | 监控、调整、再组织重构 | 持续优化 |
2025 单54 直接考：设计关系模式是逻辑结构设计阶段的任务（选 B）。干扰：需求分析（收集需求）、概念结构设计（画 E-R）、物理结构设计（存储/索引）。口诀：关系模式=逻辑设计、E-R 图=概念设计、存储索引=物理设计。
3.1.1 概念结构设计是"两步"，不是"一步"（防"自底向上/自顶向下"概念题）
很多资料只写"概念设计=画 E-R 图"，漏掉最关键的一层：E-R 图要分两次画。 完整做法（教材口径）：
| 步骤 | 干什么 | 产物 |
|---|---|---|
| ① 局部视图设计 | 对每个部门/业务子系统分别画 E-R 图，只看本部门数据 | 分 E-R 图（局部概念视图） |
| ② 视图集成 | 把各分 E-R 图合并成一张全局图：同名异义/异名同义对齐、消除冗余联系与冗余属性 | 总 E-R 图（全局概念模型） |
策略四种：自底向上（局部→全局）、自顶向下（全局→局部细化）、逐步扩张（核心→扩展）、混合策略。 → "自底向上"就是教材最常用的那种，指的就是上表这两步；判断依据一句话：先有分 E-R 图、后有总 E-R 图＝自底向上。
⚠️ 三个坑：
- 这里的"视图"不是 SQL 的 View——指"用户视图/局部概念视图"（分 E-R 图）。看到"视图设计"先看语境。
- 别和软件工程的"自顶向下"混：软工核心原则是自顶向下、逐层细化（2021 多88，见 6.1）；数据库概念结构设计主流是自底向上。两者都对，问的是不同的事，考场上先认题干的"领域"。
- "数据库设计＝数据存储文件的设计"是错的（机构资料常见错法）：存储文件/存取方法只是物理结构设计里的一小块；数据库设计的定义是"构造最优数据库模式、建立数据库及其应用系统"，覆盖需求→概念→逻辑→物理→实施→运维全程。
第①步的起手式：不是直接画图，而是先选择局部应用（挑哪些部门/业务先做），再逐一设计分 E-R 图——所以完整链条是 选局部应用 → 逐一设计分 E-R 图 → 合并 → 修改重构消除冲突与冗余（四步，别背成两步）。
3.2 E-R 图 → 关系模式转换（2022 单50，拉分计算）
先理解在干什么：E-R 图是"画着看"的概念图（矩形=实体、椭圆=属性、菱形=联系），关系模式是能存进数据库的二维表。转换就是把图和联系都落成表——实体好落（一个实体一张表），难点全在"联系怎么落地"。
四条规则（讲人话版，必背）：
-
每个实体集 → 一张表（10 个实体就至少 10 张表）。实体的属性 = 表的列；实体的主键 = 表的主键。
- 例：「学生」→
学生(学号, 姓名)；「班级」→班级(班号, 班名)。
- 例：「学生」→
-
1:1 联系 → 不单独建表，把任一端的主键加到另一端的表里当外键（一对一，两边各添一列都表达得出来，选一端即可，不必两端都加）。
- 例：「住宿」＝ 学生 ↔ 宿舍 的 1:1 联系（一个学生住一间宿舍，一间宿舍住一个学生）：
- 方案一：在学生表加「宿舍号」→
学生(学号, 姓名, 宿舍号)； - 方案二：在宿舍表加「学号」→
宿舍(宿舍号, 楼号, 学号)。 - 两个方案都只占一列、都能表达"一对一" → 二选一，不必建"住宿表"。
- 方案一：在学生表加「宿舍号」→
- 实做时怎么选：挑加进去不与已有列重复、更自然的那一端。例：若"学生属于某班级"（1:n）已经在学生表存了「班号」，则"班长"（1:1）就应加到班级表 →
班级(班号, 班名, 班长学号)；若反过来加到学生表，会与已有的「班号」重复，还得靠 NULL 才能区分"谁是班长"。 - ⚠️ "并入任一端"＝选一端，不是两端都加。
- 例：「住宿」＝ 学生 ↔ 宿舍 的 1:1 联系（一个学生住一间宿舍，一间宿舍住一个学生）：
-
1:n 联系 → 不单独建表，把**"1"端的主键塞进"n"端**的表里当外键（只能塞 n 端）。
- 例：「属于」＝ 学生(n) ↔ 班级(1)（一个班有多个学生）→ 在学生表加"班号"外键。
- 为什么必须放 n 端（两难论证）：班级表里一个班只占一行（班号是主键，一个班不许出现两行）。要把"B01 有 3 个学生"记进班级表，只有两种写法，各撞一条铁律：
- 一行多值：B01 只占一行，"学号"格子里挤 3 个学号（
2025001,2025002,2025003）→ 属性不再原子 → 破坏 1NF； - 一行一值：每行只记一个学号，B01 就得重复 3 行 → 班号主键重复 3 次 → 主键冗余（一个班被记成 3 行、班名抄 3 遍，数班数=3 实际只有 1 个班）。
- 两种写法都死 → "多"塞不进"1"端的表。而学生表一个学生一行，3 个学生天然 3 行，每行各填一个班号 → 既是一行一值（不破坏 1NF），主键又是学号、各行不同（不冗余），刚好。
- 一行多值：B01 只占一行，"学号"格子里挤 3 个学号（
- 本质："多"永远只能落在行数上；n 端一行一个体、行数天然多，所以外键放 n 端。
- 找 n 端技巧：找"多"的那一方——"一个班有多个学生"→ 学生是 n 端。
-
m:n 联系 → 必须单独建一张表（塞哪端都撞同一个两难：一行多值破坏 1NF、一行一值主键冗余——两端都装不下"多"）。新表主键 = 两端主键的组合（联合主键），这两列同时是各自指向实体表的外键；联系自身的属性（如"选课"的成绩）也放这张表。新表一行 = 一次联系实例（一次选课），"多"落在它的行数上——与 1:n 是同一条原理。
- 例：「选课」＝ 学生(m) ↔ 课程(n) → 建
选课(学号, 课程号, 成绩)，主键=(学号, 课程号)，学号、课程号分别是外键。
- 例：「选课」＝ 学生(m) ↔ 课程(n) → 建
🔑 一句话抓住外键数：外键只看"联系"，与"实体"无关。
- 实体不产生外键——实体表里只有它自己的主键（别的表来引用它，那是别人的外键，不是它的）。所以算外键时把实体数整条划掉。
- 每一条联系都要落地外键，条数由类型定死：
| 联系类型 | 落地几个外键 | 落在哪 |
|---|---|---|
| 1:1 | 1 | 被并入的那一端表 |
| 1:n | 1 | n 端表 |
| m:n | 2 | 新建的联系表（两端主键各一个） |
- 于是：外键数 = 1:1 数 + 1:n 数 + 2×m:n 数 = 联系总数 + m:n 数。
两个数分开算，互不影响：表数看"实体 + m:n"，外键数看"联系"。所以出现"表 15 张、外键 17 个"（外键比表多）完全正常——两个实体之间一条 m:n 联系，就是"3 张表、2 个外键"。 考场自检：算完外键数，回头问一句"我有没有用到实体数？"——一旦用到了，就是算错了。
计数公式（2022 单50 口径，必背）：
- 关系模式数（＝需要创建的基本表的张数）= 实体数 + m:n 联系数（1:1、1:n 联系不单独建表 → 不增加表）；
⚠️ 为什么能读成"表的张数"：关系模式就是一张二维表的结构，一个模式对应一张表。但只有 m:n 联系（和多值属性，如"家庭成员""多个电话号码"）才会额外成表——1:1 与 1:n 都是"并一列"解决，不建新表。所以千万别算成"实体数 + 联系总数"（那正是 2022 单50 的陷阱：会算成 10+12=22）。
- 主键数 = 关系模式数（每张表 1 个主键；m:n 表的联合主键也只算 1 个）；
- 外键数 = 2 × m:n 联系数 + 1 × (1:n 联系数) + 1 × (1:1 联系数)
- 等价速记：外键数 = 联系总数 + m:n 联系数（m:n 贡献 2 个外键，1:1 与 1:n 各贡献 1 个）；
- ⚠️ 别记成"关系数 + m:n 数"——那是错的（本题会算成 15+5=20，正确答案是 17）。
⚠️ 前提澄清：并不是"每张表各有一个外键"——公式数的是"联系产生的外键"，与表的张数是两笔账。 · 实体表可以 0 个外键：只有 A、B 两个实体＋一个 m:n 联系时 → 3 张表、2 个外键（全在联系表），A 表与 B 表都是 0。 · 外键会集中：m:n 联系表 2 个；n 端表被 N 个 1:n 指着就有 N 个；1:1 被并入的那端 1 个。所以外键数可能大于表数（2022 单50 就是 15 张表 / 17 个外键）。 · 公式的三条前提：①只数二元联系（三元 m:n 联系表有 3 个外键）；②1:1 只在一端加外键（两端都加会变成
2×m:n＋1:n＋2×1:1）；③只数联系产生的，不含为约束额外建的。
2022 单50 代入验证：10 个实体集、12 个二元联系（3 个 1:1、4 个 1:n、5 个 m:n）：
- 关系模式数 = 10 + 5 = 15；
- 主键数 = 15；
- 外键数 = 2×5 + 4 + 3 = 17（也可直接 12 + 5 = 17）→ 答案 C（15、17） ✓
3.3 数据字典（2023 单48）
精确定义：数据字典 = 系统中各类数据描述的集合，即元数据（描述数据的数据）——是数据库设计的核心文档，由 DBMS 自动维护。
2023 单48 考"错误的是"："数据字典与元数据是不同的概念"是错误说法（选 B）——两者是同一概念（数据字典就是元数据的集合）。其他正确项：数据字典保存关于数据库的描述信息；程序访问数据时由 DBMS 查询数据字典确定被访问的数据；用户可通过数据字典查看数据库结构。
记忆：数据字典 = 元数据 = 关于数据的数据（表结构、视图定义、索引、约束、权限的描述）。4.1 章提到"建立视图后数据字典存放的是视图的定义"（2018 单53）——同一概念，前后呼应。
3.4 数据库实施与运行维护（2021 单54）
2021 单54：数据库运行久了物理存储变差、性能下降 → DBA 进行再组织和重构：
- 数据库再组织：重新安排物理存储（回收碎片、重排物理记录）——不改逻辑结构；
- 数据库重构：调整逻辑结构（增删表、改属性）——应用程序要相应修改。
辨析：再组织=动物理（性能优化）、重构=动逻辑（需求变化）。口诀：再组织理存储、重构改结构。
3.5 角色与职责（2020 单46、2020 单45）
2020 单46：新系统上线前，对数据准确性和完整性进行审阅并签字 → IS 审计师（IS auditor）（选 A）。
- 辨析：DBA 管数据库本身（结构/权限/监控）、项目经理管项目进度资源、数据所有人管业务数据——"上线前数据质量审阅签字"是审计师的职责（独立第三方视角）。
2020 单45：保护数据仓库的特殊敏感信息 → 实施列级/行级授权访问控制（选 A）——只给需要的人看需要的行/列，最小权限原则在数据库的落地（与 7.3 访问控制呼应）。
四、易错坑汇总（命题人惯用陷阱）
🔴 外键数只看联系，不看实体——若算外键时用到了"实体数"，必错。表数＝实体＋m:n；外键数＝联系总数＋m:n（即 1:1 算 1、1:n 算 1、m:n 算 2）。
- 关系模式=逻辑结构设计（2025 单54）——"关系模式是概念设计产物"错误（概念设计产物是 E-R 图）；"是物理设计产物"错误（物理设计产物是存储/索引）。
- 数据字典=元数据（2023 单48）——"数据字典与元数据是不同概念"是错误说法；数据字典保存的是描述信息不是数据本身。
- 1:n 联系并入 n 端——"1:n 联系单独建表"错误；只有 m:n 单独建表。
- 再组织 vs 重构（2021 单54）——再组织动物理、重构动逻辑；"重构不改逻辑结构"错误。
- 上线前数据审阅签字=IS 审计师（2020 单46）——"DBA 负责签字"错误（DBA 是执行者，审计是独立监督角色）。
- E-R 图与 DBMS 无关——概念设计阶段不依赖具体数据库产品；"概念设计要考虑用 Oracle 还是 MySQL"错误。
- 数据流图（DFD）属于需求分析——"DFD 是概念设计产物"错误（DFD 是需求分析产物，E-R 才是概念设计）。
- 敏感数据保护=最小权限（2020 单45）——"用强密码就能保护数据仓库敏感信息"不充分（访问控制才是数据级保护）。
- 概念设计=自底向上（先局部后集成）——"概念设计是自顶向下逐层细化"错误（那是软工原则）；"画完实体图就结束"也错，缺了视图集成这一步。
- "数据库设计＝存储文件设计"是错的——存储文件/存取方法属物理结构设计；数据库设计是覆盖六阶段的全过程，别被窄定义带偏。
五、横向扩展（防漏网：本章边界内、真题尚未考但可能补考的点）
说明：横向扩展覆盖"大纲范围内但 9 年真题未考过"的知识，标注【新增概率】供取舍。
- E-R 转换计数变体【高】：给实体数/联系数求关系数/主键数/外键数（2022 单50 同族）——拉分计算题，掌握"关系数=实体数+m:n 数"。
- 概念设计 vs 逻辑设计的区别【中】：概念=E-R（与平台无关）、逻辑=关系模式（与 DBMS 有关）——判断题。同族补考点：概念设计的策略（自底向上）与"视图集成"步骤【中】——真题未考，但概念题口径固定（见 3.1.1）。
- 需求分析的方法【低】：自顶向下、结构化分析（DFD+数据字典）——与 6.4 软工需求分析衔接。
- 物理设计的索引选择【中】：根据查询频率/更新频率决定建哪些索引——与 4.6 索引衔接。
- 数据库实施的数据装载【低】：数据转换、清洗（与 4.7 ETL 衔接）——"装载前要清洗"概念题。
- 数据库性能监控指标【中】：响应时间、吞吐量、锁等待——与 2022 单28（DBMS 性能指标=最大连接数等）呼应。
- 数据流图（DFD）与数据字典的关系【低】：DFD 表示数据的流动加工、数据字典定义数据元素——软工交叉点。
- 数据库设计规范（命名/文档）【低】：设计文档完整性——软工视角的低概率题。
六、真题演练（代表性真题 + 解析）
例 1（2025 单54） 在关系数据库设计中，设计关系模式是（口径已核）阶段的任务。 A. 需求分析 B. 逻辑结构设计 C. 概念结构设计 D. 物理结构设计
答案：B。设计关系模式（表结构）= 逻辑结构设计。需求分析出 DFD/数据字典；概念设计出 E-R 图；物理设计出存储/索引方案。口诀：关系模式=逻辑设计。
例 2（2023 单48） 关于数据库数据字典，下列说法错误的是（口径已核）。 A. 数据字典中保存关于数据库的描述信息 B. 数据字典与元数据是不同的概念 C. 程序访问数据库数据时，由 DBMS 查询数据字典确定被访问的数据 D. 用户可以通过数据字典查看数据库的结构
答案：B。数据字典 = 元数据（同一概念）——B 说"是不同的概念"是错误说法。口诀：数据字典就是元数据，描述数据的数据。
例 3（2021 单54） 数据库运行一段时间后性能下降、物理存储变差，DBA 应采取的措施是（口径已核）。 A. 数据库再组织和重构 B. 删除数据库重建 C. 更换数据库管理系统 D. 限制用户访问
答案：A。运行维护期性能下降 → 数据库再组织（整理物理存储）和重构（调整逻辑结构）。口诀：性能下降→再组织重构。
例 4（2020 单46） 某银行老的工资系统将被迁移到新应用系统，（口径已核）应主要负责在新系统正式使用前对数据准确性和完整性进行审阅并签字。 A. IS 审计师 B. 数据库管理员 C. 项目经理 D. 数据所有人
答案：A。上线前数据准确性与完整性审阅签字 = IS 审计师（独立监督）；DBA 负责数据库运维、项目经理管项目、数据所有人管业务。口诀：数据质量把关找 IS 审计师。
例 5（2022 单50·拉分题） 10 个实体集、12 个二元联系（3 个 1:1、4 个 1:n、5 个 m:n），转换的关系模式集中，主键和外键的总数分别为（口径已核）。 A. 14、12 B. 15、15 C. 15、17 D. 19、19
答案：C。关系数 = 实体数 + m:n 联系数 = 10 + 5 = 15（1:1、1:n 并入实体表，不建表）；主键数 = 关系数 = 15；外键数 = 联系总数 + m:n 联系数 = 12 + 5 = 17（5 个 m:n 各贡献 2 个外键 = 10，4 个 1:n 各贡献 1 个 = 4，3 个 1:1 各贡献 1 个 = 3，合计 17）。主线：只有 m:n 联系单独建表；外键 m:n 数×2 + 其余联系数×1。
七、本章小结
- 一条主线：六阶段（需求→概念→逻辑→物理→实施→运维）→ 各阶段产物（DFD/E-R/关系模式/存储）→ E-R 转关系（m:n 单独建表）→ 数据字典=元数据 → 运维再组织/重构。
- 必背对应：关系模式=逻辑设计（2025 单54）；E-R 图=概念设计；存储/索引=物理设计。
- 必背一层：概念设计＝自底向上（选局部应用→分 E-R 图→合并→消冲突冗余）；数据库设计≠存储文件设计（那只是物理设计的一小块）。
- 必背概念：数据字典=元数据（2023 单48）；再组织=动物理、重构=动逻辑（2021 单54）；审阅签字=IS 审计师（2020 单46）。
- 衔接预告：E-R 转关系的"质量检验"=4.3 范式规范化；物理设计的索引=4.6；需求分析/生命周期与 6.4/6.1 软工呼应。