概述
考点
- 了解数据库设计的方法；
- 掌握数据库设计的步骤；
- 掌握E-R图的画法；
- 掌握模式的规范化；
- 掌握E-R模型转化为关系模式的方法。
一、了解数据库设计的方法
数据库设计是将现实世界需求转化为数据库模型的过程，核心方法包括：
- 新奥尔良法：将设计划分为需求分析→概念结构设计→逻辑结构设计→物理结构设计→实施与维护六个阶段，是贯穿任务一至六的结构化设计方法。
- E-R方法：以实体-联系（E-R）模型为核心，通过抽象现实世界的实体、属性与联系构建概念模型（任务二核心内容）。
- 3NF规范化方法：以关系规范化理论为指导，通过模式分解将关系优化至第三范式（3NF），消除数据冗余与操作异常（任务六核心内容）。
- 迭代优化思路：各阶段并非线性流程，需根据需求反馈持续调整，如逻辑设计阶段需结合规范化优化，物理设计阶段需根据性能反馈调整方案。
二、掌握数据库设计的步骤
数据库设计遵循标准化流程，对应任务一至五的完整工作流：
| 阶段 | 对应任务 | 核心工作 | 关键产出 |
|---|---|---|---|
| 需求分析 | 任务一 | 收集并分析用户的业务、数据、功能、性能需求，梳理数据流向与约束 | 数据流图（DFD）、数据字典 |
| 概念结构设计 | 任务二 | 将需求抽象为独立于DBMS的E-R模型，设计局部→全局→优化后的E-R图 | 全局E-R图、概念数据模型 |
| 逻辑结构设计 | 任务三 | 将E-R模型转换为关系模式，优化关系结构（规范化），设计用户子模式 | 关系模式、视图（子模式） |
| 物理结构设计 | 任务四 | 为关系模式选择存取方法（索引、聚簇），设计存储结构与系统配置 | 存储方案、索引/聚簇设计 |
| 数据库实施 | 任务五 | 建立数据库结构、编制调试应用程序、组织数据入库、系统试运行 | 可运行的数据库系统、应用程序 |
| 运行与维护 | 任务五 | 监控性能、备份恢复、安全控制、重组与重构数据库 | 优化后的系统、维护记录 |
三、掌握E-R图的画法
E-R图通过实体、属性、联系三大要素抽象现实世界，设计步骤如下：
（1）核心要素表示
- 实体：现实中独立存在的事物（如“学生”“课程”），用矩形表示，主键（码）用下划线标注。
- 属性：实体的特征（如“学号”“课程名”），用椭圆表示，与实体用线连接。
- 联系：实体间的关联（如“选修”“授课”），用菱形表示，与实体用线连接，并标注联系类型（1:1、1:n、m:n）。
（2）设计流程
- 局部E-R图：针对每个用户视图，识别实体、属性及联系（如任务二中的学生、课程、选修联系）。
- 全局E-R图：合并局部E-R图，消除命名/属性/结构冲突，形成统一模型。
- 优化E-R图：删除冗余联系与属性，简化模型结构。
（3）联系类型标注
- 1:1联系（如“学生-学生证”）、1:n联系（如“班级-学生”）、m:n联系（如“学生-课程”），需在联系旁明确标注。
四、掌握模式的规范化
规范化的核心是消除数据冗余大、更新异常、插入异常、删除异常，通过模式分解提升范式级别：
（1）核心范式定义
| 范式 | 核心约束 | 解决问题 | 任务六示例 |
|---|---|---|---|
| 1NF | 所有属性为不可再分的原子项 | 保证数据原子性 | “学生课程成绩”表的属性均为原子项，满足1NF |
| 2NF | 满足1NF，且非主属性完全依赖于码 | 消除部分依赖 | 将“学生课程成绩”分解为“学生_班级”“课程”“成绩”，消除非主属性对（学号,课程号）的部分依赖 |
| 3NF | 满足2NF，且非主属性不传递依赖于码 | 消除传递依赖 | 将“学生_班级”分解为“学生”“班级”，消除“学号→班级名→班主任”的传递依赖 |
（2）规范化步骤
- 检查1NF：拆分复合属性至原子性。
- 分解至2NF：消除非主属性对码的部分依赖。
- 分解至3NF：消除非主属性对码的传递依赖。
（3）设计原则
一般数据库设计满足3NF即可，在消除冗余与性能之间取得平衡；更高范式（如BCNF）仅在特殊场景下需要。
五、掌握E-R模型转化为关系模式的方法
将E-R图转换为关系模式是逻辑设计的核心，规则如下（任务三核心内容）：
（1）实体的转换
一个实体型转换为一个关系模式，实体的属性即为关系的属性，实体的码即为关系的码。
示例：“学生”实体 → 学生(学号, 姓名, 性别, 年龄)。
（2）联系的转换
| 联系类型 | 转换规则 | 任务三示例 |
|---|---|---|
| 1:1联系 | 可转换为独立关系，或与任意一端合并 | “学生-学生证”可合并至“学生”关系 |
| 1:n联系 | 可转换为独立关系，或与n端（多方）合并（推荐） | “班级-学生”合并至“学生”关系，增加“班级号”属性 |
| m:n联系 | 必须转换为独立关系，包含双方码（联合主键）+ 联系属性 | “学生-课程”的“选修”联系 → 选修(学号, 课程号, 成绩) |
| 多元联系 | 转换为独立关系，包含所有参与实体的码+联系属性 | 如“学生-教师-课程”的“授课”联系，包含三方码 |
（3）合并规则
具有相同码的关系模式可合并，减少冗余（如任务三中“学生”与“班级”的合并优化）。