数据库设计 · ER图转换 · 联系属性

ER 图联系有属性怎么转换？

ER 图里最容易漏的，不是实体，而是联系属性。学生有姓名，课程有课程名，这些好判断；但“成绩”放哪？“选课时间”放哪？它既不像学生本身的固定属性，也不像课程本身的固定属性，而是属于“某个学生选了某门课”这件事。老师讲数据库设计时，会反复提醒：联系有属性，先别急着往实体表里塞。

数据库与软件设计专题软考题库编辑部持续更新

内容整理：软考题库编辑部最近更新：2026-06-18

联系属性属于一段关系，不属于单独一端

以学生选课为例，成绩不是学生的固定属性。一个学生选不同课程，成绩不同；成绩也不是课程的固定属性，因为同一门课对不同学生成绩也不同。它真正属于“学生选某门课程”这个联系。

所以在多对多关系转换时，通常会建立选课表，里面保存学生编号、课程编号，以及成绩、选课时间等联系属性。这样每一行都能清楚表达：哪个学生、哪门课程、这次选课产生了什么数据。

多对多本来就需要联系表；如果联系还有属性，联系表就更不能省。比如学生和课程之间的选课表，不只是用来解决多对多，还负责记录成绩、选课时间、重修标记等信息。

这类题的标准答案通常会长这样：选课(学号, 课程号, 成绩, 选课时间)。其中学号和课程号分别是外键，也常常共同组成主键或候选键。成绩这类联系属性，放在选课表里才有业务含义。

学生(学号, 姓名, 班级)。

课程(课程号, 课程名, 学分)。

选课(学号, 课程号, 成绩, 选课时间)。

成绩跟某个学生和某门课同时有关，所以放在选课表。

如果是一对多联系，联系属性有时可以放到多端表里。比如客户和订单是一对多，订单日期、订单金额通常更像订单本身的属性，放在订单表里就很自然。因为每条订单记录已经对应一个客户，联系信息可以随订单一起保存。

但如果联系本身有独立含义，或者同一对实体之间会发生多次联系，就要考虑单独建联系表。比如员工参与项目，一名员工在同一项目中可能有多个阶段角色或多段投入记录，简单放在员工表或项目表都不合适。

读题时可以把属性逐个问一遍：它只描述学生吗？只描述课程吗？还是必须同时知道学生和课程才有意义？如果必须同时知道两端实体，它大概率是联系属性。

做关系模式转换时，别只写表名。至少要把主键、外键和联系属性写清楚。很多下午题丢分不是因为实体找错，而是关系表里少了成绩、数量、时间这类关键字段。