4.3.2 E-R 图与关系模式补充
从题干抽丝剥茧
这一节的核心不是背一张答案，而是掌握“题干语句 -> 模型元素”的翻译能力。字幕里讲到，做题时要从需求说明中一次次抽丝剥茧，把描述语句对应到 E-R 图和关系模式上。
题干里的句子大致有四种功能：描述联系、描述属性、指出主键、暗示外键或归并。你要先判断这句话在说什么，再决定写到图里还是写到关系模式里。
| 题干线索 | 模型含义 | 作答位置 |
|---|---|---|
| “一个部门可以有多个员工，一个员工只属于一个部门” | 部门与员工的一对多联系 | E-R 图联系与多重度 |
| “托运公司信息包括编号、名称、电话” | 托运公司的属性 | 关系模式属性 |
| “申请号唯一标识预定申请” | 申请号是主键 | 主键作答 |
| “员工属于部门”且员工关系缺空 | 部门号归并到员工关系 | 关系模式补空 |
| “订单作为一组联系继续参与运送” | 聚集 | E-R 图特殊建模 |
联系：先看实体之间的对应关系
联系不是“名词好像重要”，而是题干明确描述了两个或多个实体之间的业务关系。判断联系时，优先找数量词和约束词。
| 语义句式 | 联系类型 | 判断方式 |
|---|---|---|
| 一个 A 对应一个 B，一个 B 对应一个 A | 1:1 | 两端都唯一 |
| 一个 A 对应多个 B，一个 B 只对应一个 A | 1:n | A 端为 1，B 端为 n |
| 一个 A 对应多个 B，一个 B 也对应多个 A | m:n | 两端都可多 |
| A、B、C 三个实体共同完成一个动作 | 三元联系 | 不能简单拆成三个二元联系时，保留三元联系 |
关系模式补空：两个来源
字幕里特别提醒：关系模式的属性补充，一般可以从题干直接找到；如果题干没有多余属性，就要考虑是不是来自 E-R 图转关系模式时的归并。
题干直接给属性
如果题干写“托运公司信息包括公司编号、公司名称、联系方式”，那这些词就是关系模式里的属性名称。考试要求通常希望你与题干保持一致，不要把“联系方式”随意改成“电话字段”。
联系转换带来属性
如果部门和员工是一对多，员工在多端，那么部门主键会并入员工关系。例如：
部门(部门号, 部门名)
员工(员工号, 姓名, 岗位, 电话, 工资, 部门号)这里 部门号 不是题干在“员工信息包括...”里直接列出的员工自然属性，而是由“员工属于部门”的联系归并得到的外键。
主键与外键：考试里的简化判断
主键一般看“唯一标识”。外键一般看“参照其他关系的主键”。严格数据库理论中，外键还有参照完整性等条件，但软件设计师考试里，字幕给出的实用原则是：只要当前关系中的属性参照了其他关系的主键，通常就按外键处理。
| 判断对象 | 题干信号 | 答题写法 |
|---|---|---|
| 主键 | 唯一标识、编号、代码、证号 | 写能唯一标识元组的属性 |
| 组合主键 | 单个属性不能唯一，一组属性共同唯一 | 用括号把组合键括起来 |
| 外键 | 当前关系中出现其他关系的主键 | 写当前关系里的属性名 |
| 多个外键 | 分别参照不同关系 | 逐个列出，不要误写成一个组合外键 |
三元联系与聚集
二元联系比较直接，三元联系更容易丢分。课堂里给出的方法是：可以按中心实体分析，也可以按题干语义分析。比如“业务员根据预定申请安排客房”，这句话同时涉及业务员、预定申请、客房，且“安排”这个动作需要三者共同参与，就适合作为三元联系。
聚集则更特殊：当一个联系本身具有业务实体的性质，并继续参与新的联系时，可以把联系作为更高层次的实体来看。字幕中的例子是“订单”可能本来是顾客与商品之间的一组联系，但订单又参与托运、配送等业务，这时可以把订单聚集起来继续建模。
顾客 -- 下单 -- 商品
|
聚集为
|
订单 -- 托运/配送 -- 托运公司、配送员作答细节：小地方也会丢分
| 细节 | 建议 |
|---|---|
| 联系名称 | 题目允许写“联系1、联系2”时就按编号写，避免起名不准 |
| 菱形标志 | E-R 图中联系要写在菱形内部 |
| 多重度 | 常用 1、m、n 或 *；两端不要都随手写成同一个符号 |
| 人名字段 | 关系模式中常对应工号、员工号，而不是直接写“配送员” |
| 部门字段 | 通常对应部门编号、部门号 |
| 题干属性名 | 尽量与题干原词一致 |
例题
自查要点
- 一句话里出现两个实体时，如何判断它是在描述联系还是属性？
- 为什么一对多联系常把“一”端主键并入“多”端？
- 三元联系的多重度可以怎样分析？
- 写外键时，为什么要使用当前关系模式中的属性名？
- 什么情况下联系会被当作聚集继续参与建模？