用自己主机做网站百度一下百度主页度

软件中级考试之软件设计师下午篇ER图做题方法总结

题目描述

1. 业务场景说明
2. 需求分析结果
3. 概念模型设计（给出不完整的实体联系图）
4. 关系模式设计（给出不完整的关系模式描述）

题型概括

1. 补充关系模式描述

补充数据库表格的列名

做题技巧:

一个空可能对应多个列名（额外考虑的列名一般是其他实体的主键，根据对应关系确定额外的列名）

总结：外键存储规则

关系类型	外键存储位置	是否允许双向外键？	示例场景
1:1	任选一方存储（查询频率高的一方）	是（需唯一约束）	员工 ↔ 社保卡
1:M	必须存储在“多”的一方	否	部门 ↔ 员工
M:N	必须通过关联表存储	否	学生 ↔ 课程

2. 补充E-R图

根据问题描述，补充 $n$ 个联系，实体联系图（需要画图）。联系名可用 联系 i = { 1 , , 2 , ⋯ , n } i=\{1,,2,\cdots,n\} i={1,,2,⋯,n} 表示 ，联系的类型为1:1，1:n 和 m:n（ 或 1:1，1:∗ 和 ∗:∗ )

以下是ER图（Entity-Relationship Diagram）中常见图形符号及其含义的表格总结，适用于数据库设计中的概念模型表示：

做题技巧:

联系有三元关系

三元关系描述及图：
”当客户入住时，业务员根据客户的预定申请负责安排入住客房事宜。...一名业务员可以安排多个预定申请，一个预定申请只由一名业务员安排，而且可安排多间同类型的客房。 “

“主管根据用户申请为已受理的用户申请制定策划任务。... 一名主管可以制定多个策划任务，一个用户申请只由一名主管策划，而且可策划多个任务。”

加深理解多元联系
多加练习

关系本身需要添加属性 2023上半年考察

设计原则总结

情况	是否需要关系属性	示例	实现方式
多对多（M:N）	是	学生选课的成绩、时间	关联表存储属性
一对多（1:M）的复杂场景	是（罕见）	订单商品的折扣	关联表模拟M:N
三元/多元关系	是	医生-患者-预约的状态	关联表存储多方外键+属性
弱实体的标识性关系	是	订单项的添加时间	弱实体表包含属性和外键
简单1:M或1:1	否	部门-员工、用户-个人资料	外键直接存储在子表中

习题描述：记录零件采购信息，某个车型的某种零件可以从多家供应商采购，某种零件也可以被多个车型采用某家供应商也可以供应多种零件，还包括采购数量和采购日期。据此补充E-R图

ER图常见图形符号及含义
E-R图理解
符号来源

图形符号	名称	含义	示例
矩形 ▭	实体（Entity）	表示现实中的独立对象或事物，对应数据库中的表。	学生、课程、员工
椭圆 ⬭	属性（Attribute）	描述实体的特征，对应表中的列。下划线标注为主键属性。	学号、姓名、价格
菱形 ◊	关系（Relationship）	表示实体间的关联，动词短语描述（如“属于”“选修”）。	选课、所属部门、订购
直线 ─	连接线	链接实体与属性，或实体与关系。	学生 ─ 学号

3. 分析关系模式的主键和外键（标注主键和外键完整性约束）

主键（PK）的确定方法

1. 定义：唯一标识表中每条记录的字段或字段组合，且不允许为空（NOT NULL）。
2. 分析步骤：
   • 步骤1：找出能唯一确定一条记录的字段（如学号、身份证号）。
   • 步骤2：若无单字段唯一标识，则用最小字段组合作为复合主键（如（订单ID, 商品ID））。
     主键为全码表示表中所有属性共同组成主键，常见于纯关联表或组合唯一性约束的场景。
     设计意义：确保数据唯一性，避免部分依赖，直接满足BCNF。
     软考考点：在分析关系模式时，若发现所有属性均需参与唯一标识，则主键为全码。

外键（FK）的确定方法

1. 定义：一个表中的字段引用另一个表的主键，用于维护参照完整性。
2. 分析步骤：
   • 步骤1：明确实体间的关系类型（1:1、1:M、M:N）。
   • 步骤2：根据关系类型决定外键位置：
     • 1:1：外键可放在任一方（通常选查询频率高的一方）。
     • 1:M：外键放在“多”的一方。
     • M:N：通过关联表存储双方主键作为外键。

弱实体的主键需包含所有者实体的主键

• 弱实体的主键需包含所有者实体的主键（如订单项的主键 = 订单ID + 项编号）。

4. 问答题-数据库的规范化

5. 问答题-数据库的相关概念

6. 问答题- 新增实体

例题