4.3.3 综合案例分析
这节课的重点：把规则落到案例里
前两节讲的是数据库设计题的总体套路，这一节开始进入综合案例：从题干中找联系、补 E-R 图、补关系模式、写主键外键，并判断规范化问题。
课堂里的案例涉及部门、员工、经理、客户、预定申请、业务员、客房等对象。它看起来像酒店预定系统，也穿插了企业人事关系；真正要训练的是同一套能力：看懂题干语义，而不是背某个系统的固定答案。
联系怎么找：从数量词入手
题干里的“每个”“多个”“唯一”“只属于”是判断联系类型的关键。
| 题干描述 | 实体 | 联系类型 | 解释 |
|---|---|---|---|
| 每个部门可以有多名员工，一个员工只能属于一个部门 | 部门、员工 | 1:n | 部门端为 1，员工端为 n |
| 每个部门只有一名经理负责管理本部门 | 部门、经理 | 1:1 | 一个部门对应一个经理，经理管理本部门 |
| 一名客户可以有多个预定申请，一个预定申请只对应唯一客户 | 客户、预定申请 | 1:n | 客户端为 1，预定申请端为 n |
| 业务员根据预定申请安排入住客房 | 业务员、预定申请、客房 | 三元联系 | “安排”动作需要三者同时参与 |
三元联系“安排”为什么不能随便拆
“业务员安排客房”和“预定申请包含客房”分开看，好像也能画成两个二元联系。但题干强调的是：业务员根据某个预定申请来安排入住客房。一次安排同时绑定了业务员、申请和客房；拆开后容易丢失“哪名业务员针对哪份申请安排了哪间客房”这个整体事实。
所以考试中遇到三方共同构成一个业务动作时，应优先考虑三元联系。多重度如果分值很低，不必耗费过多时间；但要知道基本分析方法：
| 分析角度 | 问题 | 可能结论 |
|---|---|---|
| 以业务员为中心 | 一名业务员能处理几个申请、几间客房？ | 可为多个 |
| 以预定申请为中心 | 一个申请能安排几间客房？由几名业务员处理？ | 客房可多，业务员通常唯一 |
| 以客房为中心 | 一间客房在一次安排中对应几份申请？ | 语义上通常唯一 |
关系模式怎么补：先题干，再归并
员工关系中的部门号
题干可能说：员工信息包含员工号、姓名、岗位、电话、工资。乍看员工关系已经完整，但如果题目留空，还要检查联系归并。因为“部门与员工是一对多”，一端部门的主键会并入多端员工，因此员工关系中常补 部门号。
部门(部门号, 部门名, ...)
员工(员工号, 姓名, 岗位, 电话, 工资, 部门号)这里 部门号 同时体现两个含义：它记录员工属于哪个部门；它也是员工关系参照部门关系的外键。
安排关系中的三端主键
三元联系独立转换为关系模式时，通常会并入三端实体的主键。若题干说明安排还具有入住时间、离店时间等属性，这些属性也进入安排关系。
安排(业务员号, 申请号, 客房号, 入住时间, 离店时间, ...)主键要以题干为准。如果题干说 客房号、身份证号、入住时间 能唯一标识一次安排，就按这组属性写组合主键；不要机械地把所有外键都当成组合主键。
主键、外键写法
| 关系 | 主键判断 | 外键判断 |
|---|---|---|
| 部门 | 部门号 通常唯一标识部门 | 视题干而定 |
| 员工 | 员工号 唯一标识员工 | 部门号 参照部门 |
| 预定申请 | 申请号 唯一标识申请 | 客户号 参照客户 |
| 安排 | 由题干指定的一组属性唯一标识 | 业务员号、申请号、客房号 等分别参照对应关系 |
外键写法的一个细节是：外键必须写当前关系中的属性名。比如安排关系里写 业务员号，而不是笼统写“业务员表主键”。
规范化问题：客房类型与收费标准
字幕里的规范化示例是客房关系。假设有：
客房(客房号, 客房类型, 收费标准, 入住状态)题干说 客房号 唯一标识客房，又说“不同房型具有不同的收费标准”。于是依赖关系是：
客房号 -> 客房类型
客房类型 -> 收费标准合起来就是：
客房号 -> 客房类型 -> 收费标准这表示非主属性 收费标准 通过非主属性 客房类型 传递依赖于主键 客房号。问题后果包括收费标准冗余、更新异常、插入异常和删除异常。
| 异常 | 会发生什么 |
|---|---|
| 数据冗余 | 同一房型的收费标准在许多客房记录中重复出现 |
| 更新异常 | 调整某房型价格时必须改多行，漏改就不一致 |
| 插入异常 | 新增一种房型但还没有客房时，可能无法记录收费标准 |
| 删除异常 | 删除某房型最后一间客房时，收费标准也丢失 |
合理拆分方式：
客房类型(客房类型, 收费标准)
客房(客房号, 客房类型, 入住状态)注意第二个关系中仍要保留 客房类型。否则客房表和客房类型表就无法连接，拆分虽然消除了冗余，却破坏了信息可还原性。
答题时写多长
规范化解释题常写“100 字以内”。这不是要求你必须写满 100 字，而是限制你别写太长。评分通常按关键点给分，例如：
存在。客房号决定客房类型，客房类型决定收费标准，收费标准对主键存在传递依赖，导致冗余和更新异常。可拆为客房(客房号, 客房类型, 入住状态)和客房类型(客房类型, 收费标准)。这类答案不长，但包含了判断、依赖原因、异常结果和修改方案。
例题
自查要点
- 为什么“安排”可以作为业务员、预定申请、客房之间的三元联系？
- 员工关系中补
部门号时，它来自题干直接属性还是联系归并？ - 安排关系的组合主键和外键写法有什么区别？
- 客房关系拆分时为什么不能漏掉
客房类型？ - 规范化解释题如何用短答案命中“判断、原因、修改”三个得分点？