模块一：需求分析、E-R图与关系模式设计
这一部分对应开卷考核的模块一，满分30分，也是后续SQL能否正确编写的基础。教材第7章把数据库设计分为需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、运行和维护等阶段。本次考核重点集中在前三步。
1. 三项提交任务和得分点
Section titled “1. 三项提交任务和得分点”| 任务 | 分值 | 核心得分点 |
|---|---|---|
| 需求分析文档 | 10 | 说清核心业务、实体及属性，内容不超过2页 |
| 完整E-R图 | 10 | 不少于5个核心实体，标清属性、主键、联系和基数 |
| E-R模型转换为关系模式 | 10 | 正确生成表，并标出主键、外键、非空、唯一等约束 |
这三项是前后连贯的：
业务需求 → 找实体和联系 → 画E-R图 → 转换成关系模式 → 编写建表SQL如果实体和联系前后不一致，例如需求分析中有“支付记录”，E-R图与表结构中却完全没有支付相关信息，报告就会显得不完整。
2. 数据库设计的基本过程
Section titled “2. 数据库设计的基本过程”2.1 需求分析：回答“系统要管理什么”
Section titled “2.1 需求分析：回答“系统要管理什么””需求分析不是写空泛介绍，而是从业务中提炼数据库必须保存的信息与必须支持的操作。
需要回答的三个问题：
谁在使用系统？系统要保存哪些对象及其属性？这些对象之间发生什么业务动作？例如，如果当天题目是某类“订单管理”场景，需求分析可以提炼为：
用户可以创建订单；订单包含一种或多种商品；每个商品属于一个分类；订单可能产生支付记录；管理员维护商品与查询订单统计。这几句话自然导出实体：
用户、订单、商品、分类、订单明细、支付记录2.2 概念结构设计：回答“对象之间怎样联系”
Section titled “2.2 概念结构设计：回答“对象之间怎样联系””概念结构设计通常使用 E-R 模型，它不依赖 MySQL 或 openGauss 等具体数据库系统。
E-R图中的基本元素：
| 元素 | 含义 | 示例 |
|---|---|---|
| 实体 | 可以独立识别的业务对象 | 用户、课程、设备、订单 |
| 属性 | 描述实体的数据项 | 用户姓名、订单时间、商品价格 |
| 主键 | 唯一标识实体的属性 | 用户编号、订单编号 |
| 联系 | 实体之间的业务关系 | 用户创建订单、学生选修课程 |
| 基数 | 联系数量特征 | 1:1、1:N、M:N |
2.3 逻辑结构设计：回答“最终建哪些表”
Section titled “2.3 逻辑结构设计：回答“最终建哪些表””逻辑结构设计的核心任务，是把 E-R 图转换成关系表，并补上约束。
最终产物可以写成关系模式：
用户(UserID, UserName, Phone, ...)订单(OrderID, UserID, OrderTime, Status, ...)商品(ProductID, ProductName, UnitPrice, ...)订单明细(OrderID, ProductID, Quantity, UnitPrice)其中需要明确：
主键 PK：唯一识别一行数据外键 FK：保证联系引用有效NOT NULL：重要信息不能为空UNIQUE：业务上不能重复的属性CHECK：限定数值范围或状态取值3. 如何写需求分析文档
Section titled “3. 如何写需求分析文档”考试要求内容不超过2页，所以应该简明但信息完整。推荐按下面结构写。
3.1 业务背景与目标
Section titled “3.1 业务背景与目标”用一段话说明系统服务对象和目的。例如：
本系统面向某业务中的用户与管理人员，负责记录基础资料、业务交易过程以及查询统计信息。系统目标是保证业务数据结构化存储、关系一致，并支持日常录入、查询和统计管理。现场需要把“某业务”换成当天题目指定的真实业务，并补充它特有的动作。
3.2 核心业务流程
Section titled “3.2 核心业务流程”用编号列出3至5条最关键的业务流程。例如：
1. 管理员维护基础信息，如商品、分类或服务项目。2. 用户提交业务申请或订单。3. 一次申请可以关联多个明细对象。4. 系统记录处理状态或支付结果。5. 管理员按时间、用户或分类进行统计查询。3.3 实体与主要属性
Section titled “3.3 实体与主要属性”建议使用表格，让老师快速看到你的设计是否完整。
| 实体 | 主键 | 主要属性 | 设计理由 |
|---|---|---|---|
| 用户 | UserID | 姓名、电话、注册时间 | 发起业务操作的主体 |
| 商品/项目 | ProductID | 名称、单价、状态 | 被选择或被服务的对象 |
| 订单/申请 | OrderID | 创建时间、状态、用户编号 | 表示一次完整业务过程 |
| 订单明细 | OrderID + ProductID | 数量、成交单价 | 表示订单与商品的多对多联系 |
| 支付/处理记录 | PaymentID | 金额、时间、方式、订单编号 | 记录后续执行结果 |
这只是可迁移的示例结构，最终实体名称和属性必须服从当天业务题目。
3.4 数据约束与查询需求
Section titled “3.4 数据约束与查询需求”除了实体，还要说明关键规则，例如：
用户手机号不能重复。商品单价必须大于等于0。订单必须属于已存在的用户。明细数量必须大于0。支付金额不能为负数。系统需要查询某用户的业务记录、按类别统计数量、按时间统计金额等。这部分会直接帮助你写 UNIQUE、CHECK、FOREIGN KEY 和多表查询。
4. E-R图中的实体、属性和主键
Section titled “4. E-R图中的实体、属性和主键”4.1 什么是实体
Section titled “4.1 什么是实体”实体是业务中需要单独保存信息、并且能够区分个体的对象。
判断一个名词是否适合成为实体，可以问：
它是否拥有多个属性？它是否会被反复查询或引用？它是否需要一个编号来唯一标识？例如“用户”拥有姓名、手机号等属性，并且会关联很多订单，所以应当成为实体。而“订单总价”通常是由明细计算出来的属性，不一定需要独立成为实体。
4.2 什么是属性
Section titled “4.2 什么是属性”属性是实体需要保存的数据。例如：
用户：用户编号、姓名、手机号、注册时间订单：订单编号、用户编号、创建时间、订单状态属性选择应当服务于业务。无用字段堆得很多不会增加得分，反而让表结构更难维护。
4.3 什么是主键
Section titled “4.3 什么是主键”主键必须满足：
唯一：不同实体实例的主键值不能相同。非空：每条记录都必须能够被识别。稳定：尽量不要选择经常改变的业务属性。因此通常使用编号作为主键，例如 UserID、OrderID，而不是直接用姓名作为主键。
5. 联系和联系基数
Section titled “5. 联系和联系基数”5.1 一对一联系 1:1
Section titled “5.1 一对一联系 1:1”含义：
实体A的一个实例最多对应实体B的一个实例，反之亦然。示例：
用户 与 用户档案转换方式：
可以合并为一张表；也可以在任意一方加入另一方的外键，并设置 UNIQUE，保证一对一。5.2 一对多联系 1:N
Section titled “5.2 一对多联系 1:N”含义：
一名用户可以创建多个订单，但每个订单只属于一名用户。转换规则非常重要：
把“一”端的主键放到“多”端作为外键。例如：
用户(UserID, UserName, ...)订单(OrderID, UserID, OrderTime, ...)其中 订单.UserID 是指向 用户.UserID 的外键。
5.3 多对多联系 M:N
Section titled “5.3 多对多联系 M:N”含义：
一个订单包含多个商品，一个商品也可以出现在多个订单中。多对多不能简单只在某一方添加一个外键，否则无法正确存多个对应关系。正确做法是新建联系表：
订单明细(OrderID, ProductID, Quantity, UnitPrice)其中：
OrderID 是指向订单的外键ProductID 是指向商品的外键OrderID + ProductID 可组成联合主键Quantity、UnitPrice 是这次联系自身的属性6. 从E-R模型转换为关系模式
Section titled “6. 从E-R模型转换为关系模式”6.1 实体转换规则
Section titled “6.1 实体转换规则”每个普通实体通常转换为一张表：
用户实体 → User表商品实体 → Product表订单实体 → Orders表实体的主键成为表的主键，普通属性成为列。
6.2 联系转换规则汇总
Section titled “6.2 联系转换规则汇总”| E-R联系类型 | 转换到关系模式的方法 |
|---|---|
| 1:1 | 合并表，或在一方放置对方外键并加唯一约束 |
| 1:N | 在N端加入1端主键作为外键 |
| M:N | 建立独立联系表，含两端主键及联系属性 |
6.3 一个可迁移的转换示例
Section titled “6.3 一个可迁移的转换示例”假设抽象业务中包含用户、分类、商品、订单、订单明细和支付记录，可以转换为：
用户(UserID, UserName, Phone, RegisterTime)分类(CategoryID, CategoryName)商品(ProductID, CategoryID, ProductName, UnitPrice, ProductStatus)订单(OrderID, UserID, OrderTime, OrderStatus, TotalAmount)订单明细(OrderID, ProductID, Quantity, DealPrice)支付记录(PaymentID, OrderID, PayTime, PayAmount, PayMethod)关系与约束标注示例：
| 关系表 | 主键 | 外键 | 其他重要约束 |
|---|---|---|---|
| 用户 | UserID | 无 | Phone UNIQUE NOT NULL |
| 分类 | CategoryID | 无 | CategoryName UNIQUE NOT NULL |
| 商品 | ProductID | CategoryID | UnitPrice CHECK (UnitPrice >= 0) |
| 订单 | OrderID | UserID | OrderStatus NOT NULL |
| 订单明细 | OrderID, ProductID | 两列分别引用订单与商品 | Quantity CHECK (Quantity > 0) |
| 支付记录 | PaymentID | OrderID | PayAmount CHECK (PayAmount >= 0) |
7. 三类完整性约束如何体现在设计中
Section titled “7. 三类完整性约束如何体现在设计中”教材将数据库完整性强调为防止不正确数据进入数据库的重要机制。开卷SQL部分也明确要求涵盖以下三类约束，因此在模块一的表结构中就应该提前设计。
7.1 实体完整性
Section titled “7.1 实体完整性”实体完整性要求：
主键值唯一且不能为空。示例：
UserID INTEGER PRIMARY KEY7.2 参照完整性
Section titled “7.2 参照完整性”参照完整性要求：
外键值要么为空，要么必须对应被引用表中存在的主键值。示例：
FOREIGN KEY (UserID) REFERENCES Customer(UserID)它能够防止“订单引用一个根本不存在的用户”这种错误。
7.3 用户自定义完整性
Section titled “7.3 用户自定义完整性”用户自定义完整性来自具体业务规则，例如：
手机号不能重复。价格不能小于0。数量必须大于0。订单状态只能属于规定集合。可以使用：
NOT NULLUNIQUECHECKDEFAULT来实现。
8. 现场作答模板
Section titled “8. 现场作答模板”8.1 需求分析开头模板
Section titled “8.1 需求分析开头模板”本系统针对______业务场景进行设计，主要服务对象包括______和______。系统需要完成______、______、______等核心业务，并支持按______进行查询统计。根据业务流程，识别出不少于5个核心实体，分别为______。8.2 关系模式描述模板
Section titled “8.2 关系模式描述模板”实体______转换为关系模式______，以______作为主键。实体______与实体______之间为一对多联系，因此在多端关系______中加入______作为外键。实体______与实体______之间为多对多联系，因此建立联系关系______，其联合主键为______。此外，通过NOT NULL、UNIQUE和CHECK约束保证______等业务规则。9. 常见错误与改进方法
Section titled “9. 常见错误与改进方法”| 常见错误 | 为什么有问题 | 正确改法 |
|---|---|---|
| 把姓名当主键 | 可能重名且可能更改 | 使用编号作为主键 |
| 多对多关系只放一个外键 | 无法表示多个对应对象 | 建中间表并放两端外键 |
| E-R图有实体但表中遗漏 | 前后不一致 | 画图后逐实体检查转换结果 |
| 没有约束 | 不能体现数据正确性 | 标注PK、FK、NOT NULL、UNIQUE、CHECK |
| 需求写得空泛 | 看不出你理解业务 | 写核心业务动作和查询需求 |
10. 本模块背诵与操作要点
Section titled “10. 本模块背诵与操作要点”数据库设计的重点过程是需求分析、概念结构设计和逻辑结构设计。需求分析用于明确业务、实体、属性和数据处理需求。E-R图描述实体、属性和实体之间的联系，联系基数包括1:1、1:N、M:N。一对多联系应在多端加入外键，多对多联系应转换为独立联系表。关系模式设计必须体现实体完整性、参照完整性和用户自定义完整性。考试中E-R图至少包含5个核心实体，表结构应明确主键、外键、非空、唯一等约束。