obsidian/软件需求分析/各章笔记/第09章-数据建模.md

第9章 数据建模

考试重要度：★★★★
核心内容：对象模型→数据模型的转换规则、多重性映射、泛化关系映射、三大范式

---

📢 从类图到数据库表

💬 前面用类图设计好了系统结构，但数据最终要存到数据库里。数据建模就是回答：怎么把"类"变成"数据库表"？

---

💡 一、数据库设计的三个阶段

阶段	任务	产物
概念设计	把用户需求统一到一个逻辑结构中	E-R图（或UML类图）
逻辑设计	转换为具体DBMS支持的数据模型	关系模式（表结构）
物理设计	选择存储方式、索引策略等	在特定数据库上实现

💬 UML类图可以替代E-R图——类图不仅能描述数据，还能描述行为（触发器和存储过程）。

关键概念速查

概念	说明
主键	唯一标识一条记录的字段
外键	引用另一个表主键的字段
模式	所有表及表间关系的集合
索引	提高查询速度的数据结构
触发器	满足条件时自动执行的操作
存储过程	预编译的SQL语句集合

---

💡 二、对象模型 → 数据模型转换规则

基本转换规则

类       →  表
属性     →  字段（列）
操作     →  触发器/存储过程
类间关系 →  表间关系（或单独的表）

多重性在数据模型中的映射（重点！）

多重性	映射方法
1 对 0..*	在多的一端加外键（指向一的一端的主键）
0..1 对 1	在0..1一端加外键（指向1的一端的主键）
0..* 对 0..*	新建一个关联表，两端主键作为外键

例：客户(Customer) 1 —— 0..* 订单(Order)

→ Order表加外键 customer_id 指向 Customer表的主键。

例：学生(Student) * —— * 课程(Course)

→ 新建选课表(Enrollment)，包含 student_id 和 course_id 两个外键。

泛化关系在数据模型中的映射（三种方案）

方案	做法	优点	缺点
方案一	父类和每个子类各建一个表	结构清晰	表多，查询要JOIN
方案二	不建父类表，父类属性放在每个子类表中	查询快	数据冗余
方案三	不建子类表，所有子类属性放在父类表中	表少	字段很多，有空值

💬 方案一像"分家"——各过各的，但联系起来需要花时间。
💬 方案二像"合住但分灶"——各自独立但有些东西重复了。
💬 方案三像"大家庭"——都在一个屋檐下，但人多事杂。

---

💡 三、三大数据库范式

范式	要求	解决的问题
1NF	每个字段值都是不可再分的原子值	消除重复列
2NF	满足1NF + 非主键字段完全依赖主键	消除部分依赖
3NF	满足2NF + 非主键字段不传递依赖主键	消除传递依赖

💬 1NF：别在一个格子里塞多个值。
💬 2NF：每个字段只跟主键有关，别跟主键的一部分有关。
💬 3NF：非主键字段之间不要相互依赖。

---

✍️ 边学边练

题目：以下表是否符合3NF？如果不符合，说明原因并修正。

订单表(Order)
  订单ID (主键)
  客户ID
  客户姓名
  客户电话
  商品ID
  商品名称
  数量
  下单日期

答案： 不符合3NF。存在传递依赖：

• 客户姓名、客户电话 → 依赖客户ID（不是直接依赖订单ID）
• 商品名称 → 依赖商品ID（不是直接依赖订单ID）

修正方案（拆分成三个表）：

• 订单表：订单ID、客户ID、商品ID、数量、下单日期
• 客户表：客户ID、客户姓名、客户电话
• 商品表：商品ID、商品名称

这样每个非主键字段都直接依赖于所在表的主键，满足3NF。

---

📝 章末自测

1. 填空题

• 1对多关联的映射方法是：在（ ___ ）（ ___ ）的一端加外键指向（ ___ ）（ ___ ）的一端
• 多对多关联的映射方法是：新建一个（ ___ ）（ ___ ），两边的主键作为外键
• 3NF要求非主键字段之间没有（ ___ ）（ ___ ）依赖

2. 简答题

• 简述泛化关系映射的三种方案及其适用场景。
• 类图中的操作在数据模型中对应什么？

答案： 填空题：多、一；关联表；传递

简答题：

• 方案一（每个类一个表）：适合查询灵活、结构变化少的系统。方案二（父子属性合并到子表）：适合子类差异大、按子类查询多的场景。方案三（所有属性合并到父表）：适合子类差异小、字段不多的场景。
• 类图中的操作对应数据库中的触发器和存储过程。触发器是满足条件自动执行的代码，存储过程是预编译的SQL程序。

---

🔗 上一篇：第8章 包图 | 下一篇：第11章 RUP统一过程