142 lines
5.1 KiB
Markdown
142 lines
5.1 KiB
Markdown
# 第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章 包图](第08章-包图.md) | 下一篇：[第11章 RUP统一过程](第11章-RUP统一过程.md)
|