3.3.2 概念设计过程

本课核心知识点整理

从需求文本到 E-R 图

概念设计过程不是把题干中的名词机械圈出来，而是把业务叙述拆成“对象、特征、事实约束”。软件设计师下午题常给一段业务材料，要求补 E-R 图或由 E-R 图转关系模式。前半步若抽取错，后面的主键、外键、联系表都会错。

可以按四层推进：

步骤	要问的问题	常见输出	易错点
找候选实体	哪些对象需要独立管理和区分	学生、课程、教师、订单	把普通属性误当实体
找属性	每类对象需要记录哪些特征	学号、姓名、课程名	忘记联系也可以有属性
找联系	对象之间发生什么业务事实	选修、讲授、供应	只找名词不找动词关系
判约束	一个实例能关联多少另一方实例	1:1、1:n、m:n	忽略题干给出的方向和数量

实体与属性的取舍

字幕里讲实体时强调“能够区别于其他事物”，但做题时还要补一个工程判断：它是否需要被单独维护。因为同一个词在不同系统里可能身份不同。

候选对象	作为属性更合理的场景	作为实体更合理的场景
地址	只记录学生家庭地址字符串	物流系统维护地址、区域、经纬度、配送规则
部门	仅记录员工所属部门名称	需要维护部门编号、负责人、预算、层级
供应商电话	只作为供应商联系方式	一个供应商有多个电话且电话有类型、状态、归属人
成绩	学生总评成绩	某学生选某课程得到的成绩，依赖选课联系

判断口诀不是“名词就是实体”，而是：能否独立标识、是否有自己的属性、是否被多个业务过程引用、是否需要单独增删改查。

属性类型会影响模型质量

课程字幕补充了几类属性，它们在考试中不一定都要求画出完整符号，但理解后可以避免误判。

属性类型	含义	例子	设计含义
简单属性	原子的、不能再拆	性别、年龄	可直接作为一个属性
复合属性	可继续拆成更小属性	地址可拆省、市、区；姓名可拆姓、名	是否拆分由题干需求决定
派生属性	可由其他数据计算得到	销售总额、年龄	通常不必作为基础事实重复存储
联系属性	依附于某个联系	选课成绩、供应数量	后续多转多关系表中要保留

这里最值得注意的是“可不可再分由题干定义”。例如中文姓名通常可当作简单属性；如果题干明确要求分别记录姓和名，就应按复合属性处理。

联系的抽取要看业务事实

联系通常来自动词或业务动作，例如“选修”“讲授”“供应”“管理”“属于”。但也不能只看词面，要看它表达的是不是数据库需要保存的事实。

例如“学生选修课程并记录成绩”中：

元素	建模结果	原因
学生	实体	需要独立记录学号、姓名等
课程	实体	需要独立记录课程号、课程名等
选修	联系	表达学生与课程之间的业务事实
成绩	联系属性	没有“某学生选某课程”就没有该成绩

如果题干说“每门课程由一名教师讲授，一名教师可讲授多门课程”，则“教师-课程”是 1:n 联系；如果说“一门课程可由多名教师共同讲授，一名教师也可讲授多门课程”，则变为 m:n 联系。联系类型不是固定背诵出来的，而是由题干业务约束决定。

概念设计的产物要服务后续转换

概念模型不是终点，后续要转成关系模式。因此抽取时要提前保持语义清楚：

概念设计中的判断	后续转换时的影响
1:1 联系	可把一方主键放入另一方，或独立成关系
1:n 联系	通常把“一”方主键放入“多”方作为外键
m:n 联系	通常必须转换为独立关系模式
联系有属性	联系转成关系时，属性一起放入该关系
弱实体	需要依赖强实体主键共同标识

所以概念设计阶段的“粗心”会在逻辑设计阶段放大：多对多如果误判成一对多，就会导致一张表只能保存一个对应对象，无法表达真实业务。

做题路线

1. 先把题干中的业务对象和业务动作分别标出来，名词只是候选，不是最终答案。
2. 对每个候选对象问：是否能独立标识、是否有自己的属性、是否需要单独维护。
3. 对每个业务动作问：它连接了哪些实体，是否有自己的属性。
4. 对每个联系分别从两端判断数量约束，不要凭常识覆盖题干。
5. 最后检查模型能否无歧义转换为关系模式，尤其检查 m:n 联系和联系属性。

例题

单选

在“学生选修课程”场景中，“学生”通常建模为：

A属性B实体C外模式D索引

单选

一个学生可选多门课程，一门课程可被多名学生选修，这种联系通常是：

A1:1B只属于属性C无联系Dm:n

自查要点

1. 如何区分实体和属性？
2. 联系类型为什么要结合业务语义判断？
3. 从需求文本抽取 E-R 要素的顺序是什么？