数据库设计 · ER图 · 弱实体

ER 图弱实体怎么画？

弱实体是 ER 图里相对容易被忽略的点。它不像学生、课程、订单这些实体那么直观，因为弱实体自己通常不能靠自身属性完整标识，必须依赖另一个强实体才说得清。老师讲这类题时，会先问一个很朴素的问题：这个对象离开它依赖的对象，还能不能独立识别？

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

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

弱实体的关键：自己不够独立，需要依赖强实体

弱实体通常不能只靠自己的属性唯一标识，需要借助所属强实体的主键。比如订单明细可以有行号，但同一个行号会出现在不同订单里。单看行号 1，你不知道是哪张订单的第一行；要加上订单号，才能唯一确定一条订单明细。

这就是弱实体的核心感觉：它不是没有属性，而是自身的标识不完整。它的存在和识别都依赖另一个实体。考试里如果题干说“必须依附于”“离开某对象没有意义”“编号只在所属范围内唯一”，就要警惕弱实体。

弱实体转换成关系模式时，通常要把依赖的强实体主键放进弱实体表中，作为外键；弱实体自己的部分键再和这个外键一起组成主键。比如订单明细表可以是：订单明细(订单号, 行号, 商品编号, 数量, 单价)。

这里订单号来自订单表，是外键；行号只在同一张订单内唯一，是部分键；订单号加行号，才能唯一确定一条订单明细。这个结构比单独用行号做主键更符合业务。

订单(订单号, 客户编号, 下单时间)。

订单明细(订单号, 行号, 商品编号, 数量, 单价)。

订单明细依赖订单存在，订单号 + 行号才能唯一标识一条明细。

如果只用行号，很多订单都会有第 1 行，无法唯一定位。

弱实体常常表现成一对多，但不是所有一对多的多端都是弱实体。部门和员工是一对多，但员工通常有自己的员工号，可以独立标识，所以员工不是弱实体。订单和订单明细也是一对多，但明细行通常依赖订单号和行号才能识别，因此更像弱实体。

判断弱实体，别只看数量关系，要看标识是否依赖。这个点很重要：一对多回答的是基数，弱实体回答的是识别和存在依赖。考试选项如果把这两件事混在一起，就要小心。

场景	是否一对多	多端是否弱实体	原因
部门-员工	是	通常不是	员工有独立员工号
订单-订单明细	是	通常是	明细行依赖订单号识别
班级-学生	是	通常不是	学生有学号
楼栋-房间	是	可能是	房间号可能只在楼栋内唯一

不同教材和工具对弱实体画法细节可能不同，有的用双矩形表示弱实体，有的强调识别联系和部分键。考试中更重要的是你能说清关系模式怎么落地：弱实体表要带上强实体主键，并和部分键一起形成标识。

如果题目没有明确要求画弱实体符号，关系模式里也要体现依赖关系。比如订单明细表漏掉订单号，就会导致明细无法归属；只写一个行号做主键，也无法全局唯一。