当前位置：首页 > news >正文

软考数据库下午题 E-R 图实战：2020-2023年4类聚合与弱实体真题解析

news 2026/7/12 2:48:44

软考数据库下午题 E-R 图实战：2020-2023年4类聚合与弱实体真题解析

在软考数据库系统工程师的下午题中，E-R图设计一直是考生们最头疼的部分。特别是涉及到聚合与弱实体这类高级概念时，很多考生往往因为理解不透彻而丢分。本文将通过解析2020-2023年的4道典型真题，带你深入理解聚合与弱实体的核心要点，掌握实战解题技巧。

1. E-R图核心概念回顾与解题方法论

在开始真题解析前，我们需要先明确几个关键概念：

弱实体的特点：

存在依赖于其他实体（称为"属主实体"）
没有独立的主键，通过属主实体的主键+部分属性（称为"部分键"）来唯一标识
在E-R图中用双边矩形表示，与属主实体的联系用双边菱形表示

聚合的本质：

将两个实体间的联系本身作为实体，再与其他实体建立联系
常用于表达"通过...进行..."的业务场景
在E-R图中用方框将原联系框起来，再与新实体建立联系

解题四步法：

实体识别：标记题干中所有名词性描述
属性分配：确定每个实体的属性（注意主键、外键）
联系确认：分析实体间关系（1:1、1:n、m:n）
特殊构造：识别是否需要弱实体或聚合

提示：近年真题中，约65%的E-R图题目会涉及弱实体或聚合概念，这是区分高分考生的重要考点。

2. 2020年快递驿站系统真题解析

题目场景：某小区快递驿站系统需要记录：

快递公司（名称、地址、电话）和快递员（姓名、手机号，一个公司有多个快递员）
客户（姓名、手机号、等级）
包裹（编号、到达时间，与客户和快递员关联）

关键考点：

三方联系：包裹作为联系实体连接客户和快递员
弱实体识别：快递员是否弱依赖于快递公司？

E-R图设计：

erDiagram CUSTOMER ||--o{ PACKAGE : "收发" COURIER ||--o{ PACKAGE : "配送" EXPRESS_COMPANY ||--o{ COURIER : "雇佣" CUSTOMER { string phone PK string name string level } PACKAGE { string id PK datetime arrival_time string customer_phone FK string courier_phone FK } COURIER { string phone PK string name string company_name FK } EXPRESS_COMPANY { string name PK string address string tel }

对比分析：

设计方案	优点	缺点
三方联系	准确表达业务逻辑	可能遗漏快递员与公司的隶属关系
聚合设计	更符合现实场景	增加设计复杂度

解题要点：

包裹必须同时关联客户和快递员，典型的三方联系
快递员有独立主键（手机号），不属于弱实体
注意外键约束：包裹需引用客户和快递员的主键

3. 2021年社区人员分配系统真题解析

题目场景：居委会分配社区人员到各小区：

人员分配表（人员编号、姓名、小区编号、物业经理、职责）
同一人员在同小区只负责一项工作，不同小区可不同工作

关键考点：

弱实体识别：职责是否应作为弱实体？
聚合应用：人员与小区间的分配关系是否需要聚合？

E-R图设计：

erDiagram PERSON ||--o{ DUTY : "承担" COMMUNITY ||--o{ DUTY : "分配" PERSON { int id PK string name } COMMUNITY { int id PK string manager } DUTY { int person_id FK int community_id FK string responsibility }

关系模式转换：

CREATE TABLE Person ( id INT PRIMARY KEY, name VARCHAR(50) ); CREATE TABLE Community ( id INT PRIMARY KEY, manager VARCHAR(50) ); CREATE TABLE Duty ( person_id INT, community_id INT, responsibility VARCHAR(100), PRIMARY KEY (person_id, community_id), FOREIGN KEY (person_id) REFERENCES Person(id), FOREIGN KEY (community_id) REFERENCES Community(id) );

易错点分析：

误将职责作为属性：应识别为独立联系
忽略主键组合：Duty表需要联合主键
物业经理应属于小区属性，而非分配关系

4. 2022年电商订单系统真题解析

题目场景：电商平台订单系统包含：

顾客登录后下单
代购员根据订单采购商品
一个订单的商品可能由多个代购员从不同超市采购

关键考点：

聚合设计：订单作为顾客与商品的联系，再与代购员建立新联系
多元关系：代购员、订单、超市间的复杂关系

E-R图设计：

erDiagram CUSTOMER ||--o{ ORDER : "下单" ORDER ||--o{ PRODUCT : "包含" ORDER }|--|| PURCHASE : "触发" PURCHASE }|--|| SHOPPER : "执行" PURCHASE }|--|| SUPERMARKET : "来自" CUSTOMER { int id PK string name } ORDER { int id PK datetime time int customer_id FK } PRODUCT { int id PK string name } SHOPPER { int id PK string name } SUPERMARKET { int id PK string name } PURCHASE { int order_id FK int product_id FK int shopper_id FK int supermarket_id FK int quantity PRIMARY KEY (order_id, product_id, shopper_id) }

SQL实现关键：

-- 查询每个代购员负责的订单数 SELECT s.name, COUNT(DISTINCT p.order_id) AS order_count FROM PURCHASE p JOIN SHOPPER s ON p.shopper_id = s.id GROUP BY s.id; -- 查询各超市的商品采购量 SELECT m.name, SUM(p.quantity) AS total_quantity FROM PURCHASE p JOIN SUPERMARKET m ON p.supermarket_id = m.id GROUP BY m.id;

设计要点：

订单是顾客与商品间的联系，需要聚合处理
采购关系涉及四个实体，需要联合主键
注意基数约束：一个订单可对应多个采购记录

5. 2023年水电缴费系统真题解析

题目场景：在快递驿站系统基础上新增：

水电费缴费记录（编号、客户手机号、类型、金额、时间）
一个客户可有多个缴费记录

关键考点：

弱实体识别：缴费记录是否弱依赖于客户？
模式扩展：在已有E-R图中新增实体和联系

E-R图补充设计：

erDiagram CUSTOMER ||--o{ UTILITY_BILL : "缴纳" UTILITY_BILL { int id PK string customer_phone FK string type decimal amount datetime time }

关系模式对比：

方案	主键设计	外键设计
独立实体	自增ID	引用客户手机号
弱实体	(客户手机号+编号)	必须引用客户

解题建议：

缴费记录有独立编号，更适合作为常规实体
与客户的联系是1:n关系（一个客户对应多个记录）
注意与原有包裹实体保持逻辑独立

6. 综合对比与应试技巧

四类设计对比表：

类型	表示方法	适用场景	主键特点
弱实体	双边矩形	依赖性强、无独立标识	属主主键+部分键
聚合	方框包围	联系再关联其他实体	取决于聚合对象
三方联系	三个菱形	三方同时参与	通常为联合主键
子实体	双竖线矩形	实体分类	继承父实体主键