数据库设计案例：E-R 建模、关系转换与宾馆案例¶

本篇整理“【软件设计】数据库设计”整章 4 篇课件，保存 10 张教学图片，完整保留宾馆案例的题干、三个问题和原参考答案。“课件原参考答案”保留来源表述；“补充推导与纠错”是本笔记的核对和说明。

课程内容提要包括数据库设计过程、理论基础、答题技巧、实战演练。本章的核心是把题干中的业务约束转成 E-R 联系、关系模式、键和函数依赖。基础概念也可结合数据库章节阅读。

一、数据库设计过程：区分各阶段的产物¶

阶段	主要工作	图中的产物或依据
需求分析	了解当前和未来应用的数据要求、数据处理要求	数据流图、数据字典、需求说明书
概念结构设计	提炼实体、属性、联系和业务约束	E-R 模型；不依赖具体 DBMS
逻辑结构设计	将概念模型转成选定数据模型中的逻辑结构，并检查规范化	关系模式、视图、完整性约束、应用处理说明；使用转换规则和规范化理论
物理设计	结合运行环境确定数据如何存储和访问	依据 DBMS、硬件、操作系统特性及数据处理要求

补充理解： 图中“E-R 模型与数据库无关”应理解为独立于具体 DBMS、存储和实现，并非与待建数据库的业务需求无关。关系模式解决表的结构及约束，物理设计进一步处理存储组织、索引、访问路径等问题。原图止于物理设计；完整生命周期还包括实施、运行和维护。

二、E-R 联系：先固定对象，再判断数量¶

两个不同实体集之间的联系¶

类型	课件示例	要检查的两个方向
一对一 `1:1`	班级—班长	一个班级对应至多一位班长，一位班长对应至多一个班级
一对多 `1:n`	班级—学员	一个班级可以有多名学员，一名学员至多属于一个班级
多对多 `m:n`	课程—学员	一门课可有多名学员，一名学员可选多门课

补充： 图中的 1、n 或 * 通常先表达最大基数；是否必须参加联系，还要看题干或最小参与约束。“每名员工只属于一个部门”给出了恰好一个部门，“一个部门可以有多名员工”不等于至少要有两名。不要只读其中一个方向。

三元联系：固定另外两端¶

课件的判断方法是：以一个实体集为中心，固定另外两个实体集各一个实例，看中心端最多能有几个实例与这个组合关联。至多一个记为 1，允许多个记为“多”。三个不同实体集参与的是三元联系，更多实体集参与的则是更高元联系。

原图左侧 P_D 的病房端为 1、病人端为 n、医生端为 m。按上述读法，病房端的 1 表示固定一位病人和一位医生后，至多对应一个病房，即 (病人, 医生) → 病房。它**不能单独推出** 医生 → 病房 或 病人 → 病房。

课件另给出业务解释：“一个病房有多个病人和多个医生，一个医生只负责一个病房，一个病人只属于一个病房。”后两项是更强的业务约束，需要作为额外条件保留；它们与图兼容，但并不是只看 1:m:n 就能推出来的。

右侧 SP_P 中，Supp 是供应商、Proj 是项目、Part 是零件。课件说明：供应商可为多个项目供应多种零件，每个项目可使用多个供应商供应的零件，每种零件可由不同供应商供应。三元事实是“哪个供应商，为哪个项目，供应哪种零件”；各端标“多”时，仍应固定另外两端检查。

补充： 三元联系不能随意拆成三条二元联系。只知道“某供应商供应某零件”“某项目使用某零件”“某供应商服务某项目”，不一定知道某一具体供应三元组实际存在。分解应验证业务语义及是否无损。

同一实体集内部的联系¶

自联系的两端来自同一实体集，需要标出角色。图中都是“球队”，但分别扮演主队和客队；关系转换后的引用字段也应区分为主队编号、客队编号。

补充： 若同一对球队可以多次比赛，仅用 (主队编号, 客队编号) 不能唯一标识每一场比赛，需要比赛编号或能区分场次的其他属性。这是把静态联系落到具体业务时必须检查的约束。

三、扩充 E-R 模型：弱实体、特殊化与聚集¶

弱实体¶

课件用职工—家属、邮件—附件说明存在依赖：家属记录依附职工，附件依附邮件。原图的家属是双矩形，联系是双菱形。

补充纠正： 在经典 E-R 模型中，弱实体不仅有存在依赖，还缺少独立完整的标识，需要通过属主实体的键与自身的部分键共同识别。例如：

1
2
3

邮件（邮件号，……）
附件（邮件号，附件序号，文件名，……）
附件的键 =（邮件号，附件序号）

附件序号只在同一封邮件内唯一。若附件已有全局唯一编号，就不能仅凭“删除邮件时删除附件”认定它在标识意义上是弱实体。级联删除、存在依赖、识别依赖不是同一个概念。

特殊化¶

一个实体集具有共性，也可按特征区分为不同子实体集。图中经理是员工的一种，继承员工标识及公共属性，并可有经理独有的属性或联系。

本章宾馆案例中的经理、业务员都是员工的子类型，不是两个与员工无关的实体集合。是否互斥、是否覆盖全部员工，应由具体业务规则决定。

聚集¶

课件定义：把一个联系作为另一个联系的一端。图中把房屋、租客及其“租赁”联系作为一个整体，再让这个整体与经理通过“签约”关联。经理对应的是某次具体租赁，而非孤立的房屋或租客。

答题技巧页另举：“采购完的商品交由配送员根据顾客订单组合装箱，然后交给托运公司运送。”课件把“订单”建模为先前形成的联系，将其聚集后与配送员、托运公司建立联系。

补充限定： 这里的“订单是联系名称”取决于课件采用的原始模型。实际建模也可以把具有订单号、日期、状态等属性的订单直接作为实体。不能见到“订单”二字就判定聚集；要看题给模型中它究竟是实体，还是被整体引用的联系。

四、完整性约束与 E-R 模型转关系模式¶

三类完整性约束¶

类型	课件要点	补充限定
实体完整性	主键唯一且非空	复合主键作为整体唯一，每个组成属性都不能为 NULL
参照完整性	外键引用其他关系的主键，或取空值	更一般地可引用符合 DBMS 要求的候选键／唯一键，也可自引用；是否允许 NULL 还由列约束和业务规则决定
用户自定义完整性	业务要求的数据约束	如天数大于 0、岗位限于规定集合、安排的客房类型与申请一致

补充： 外键通常不要求在引用表中唯一。部门号可以在员工表重复，因此能表示一对多；若要限制为一对一，还需要相应的唯一约束。复合外键的 NULL 匹配规则取决于数据库及匹配方式，不宜概括为任意一列为空就一律合法。

实体与二元联系的转换¶

按课件的基础转换规则，每个普通实体型转成一个关系模式，实体属性转成列，实体的标识转成候选键，再选主键。弱实体和特殊化还需要结合识别依赖及所选映射策略处理。

联系	独立成关系模式	归并到实体对应的关系模式
`1:1`	包含两端主键及联系自身属性；任一端的键可选作主键，另一端也要保持唯一	可归并到任一端，加入另一端的键及联系属性，原主键不变；新增外键要保持唯一
`1:n`	包含两端主键及联系自身属性；以“多”端的键作主键	归并到“多”端，加入“一”端的键及联系属性，原主键不变
`m:n`	独立成表，包含两端主键及联系自身属性；通常以两端键的组合作主键	基础转换规则不把多个对端值塞进一列

例如部门—员工为 1:n，将部门号加入员工表；不要反过来给部门表增加“员工1、员工2、员工3”这些列。若联系具有任职日期等属性，归并时还要把这些联系属性带上。

补充限定： 上述联系表的键以同一对实体只对应一个联系实例为前提。若业务保存多次任职、选课、比赛或入住，还要加入区分事件或时间的属性。外键和唯一约束也不能完整替代所有参与约束，例如“每个部门必须有经理”还需结合非空等要求实现。

三元联系通常独立转换为关系模式，加入各参与实体的键及联系属性，再按实际函数依赖求候选键。有一端为 1 时，其他两端键的组合能够确定这一端，但有更强业务依赖或重复事件时，必须继续核对，不能机械地把三个实体键拼起来作为最终主键。

五、规范化：先写依赖，再判断范式¶

图中以逐步消除依赖问题来记忆范式。实际判断应明确属性集合、函数依赖及**所有候选键**，不能只检查任选的一个主键。主属性是属于至少一个候选键的属性，其他属性是非主属性。

范式	判断要点
1NF	在所用关系模型与属性域的语义下，每个属性值是原子的，不在单元格中放一组重复值
2NF	满足 1NF，每个非主属性都完全依赖于每一个候选键，不存在对某候选键真子集的部分依赖
3NF	对每个非平凡函数依赖 `X → A`，`X` 是超键，或 `A` 是主属性
BCNF	对每个非平凡函数依赖 `X → A`，`X` 都是超键

“非平凡”指 A 不包含在 X 中；超键可以唯一确定整个元组，候选键是最小超键。课件用“消除非主属性对候选键的传递依赖”记忆 3NF，用“进一步处理主属性的依赖”记忆 BCNF；遇到多个候选键时，应使用上表的判定条件。

补充： 规范化主要处理函数依赖导致的冗余和异常，不能保证消除所有业务问题。分解后还要检查属性没有遗漏、连接无损，以及是否保持依赖；分解到 BCNF 不一定能保持全部依赖。

独立推导例：从库存业务得到三个关系¶

约定每个仓库有唯一库号和库名，每种商品有唯一商品号、商品名及计量单位；同一种商品可以放在多个仓库，每个仓库也可以存多种商品，只保存当前库存。数量描述的是“某仓库中的某商品”，不是仓库或商品单独的属性。

若先记成 R(库号, 库名, 商品号, 商品名, 单位, 数量)，从业务规则可写出：

1
2
3

库号 → 库名
商品号 → 商品名, 单位
(库号, 商品号) → 数量

仅有库号不能区分商品，仅有商品号不能区分仓库；两者组合能推出全部属性，又不能删除任何一项，所以候选键是 (库号, 商品号)。库名、商品名和单位依赖键的一部分，违反 2NF。按这些依赖分成：

关系模式	主键	外键
仓库(库号, 库名)	库号	无
商品(商品号, 商品名, 单位)	商品号	无
库存(库号, 商品号, 数量)	(库号, 商品号)	库号引用仓库；商品号引用商品

这不是凭“看起来冗余”拆表：拆仓库时公共属性是库号，能决定仓库关系的全部属性；拆商品同理，因而这两步连接无损。每条给定依赖也都能在一个分解后的关系内检查，保持了依赖。在没有额外依赖的前提下，这三个关系都达到 BCNF。

库存表的部分 SQL 约束可写为：

CREATE TABLE Warehouse (warehouse_id INTEGER PRIMARY KEY);
CREATE TABLE Product (product_id INTEGER PRIMARY KEY);
CREATE TABLE Stock (
    warehouse_id INTEGER NOT NULL,
    product_id INTEGER NOT NULL,
    quantity INTEGER NOT NULL CHECK (quantity >= 0),
    PRIMARY KEY (warehouse_id, product_id),
    FOREIGN KEY (warehouse_id) REFERENCES Warehouse(warehouse_id),
    FOREIGN KEY (product_id) REFERENCES Product(product_id)
);

此代码省略名称等非键字段，只展示约束：复合主键禁止同仓库同商品重复建当前库存行，两个外键检查引用对象，NOT NULL 和 CHECK 共同限制数量。单写 CHECK(quantity >= 0) 不一定拒绝 NULL，不能省略非空要求。

如果需求改成“保存每天的库存快照”，原来的键就不够了，应重新判断日期或快照标识如何参与唯一性；若允许一个商品多种计量单位，上面的 商品号 → 单位 也不再当然成立。键和依赖来自题干约束，不能从熟悉的表名直接套出。

六、答题步骤与关键词¶

课件要求熟练掌握 E-R 图、联系类型判断、E-R 图转关系模式、主键与外键判断、规范化理论，并详细分析说明。可按以下步骤作答：

先把实体及原有属性抄清，区分实体属性和联系属性。
标出“唯一标识”“每个”“只”“多个”“同类型”等限定词，将它们写成可检验的约束。
联系判断读两个方向；三元联系固定另外两端；继承与聚集先看原图结构。
将联系转换成关系模式，核对归并新增的属性，再填写空缺。
根据标识和函数依赖求主键，逐一写明外键引用哪个表的哪个键。
检查部分依赖、传递依赖；提出分解时同时写出新关系模式，并核对无损与依赖保持。

原文线索	可以定位什么	不能跳过的核对
“信息包括名称、电话和地址”	原始属性列表	最终表可能还因联系归并增加外键，不能只照抄属性句
“商品条码唯一标识每种商品”	商品标识／主键依据	是否有复合标识、是否要求最小性，不凭字段名猜键
“固定另两个对象只能对应一个……”	三元联系的 `1` 端	该约束针对组合，不必然代表任一单端能决定它

课件中的托运公司属性示例可写为 托运公司（托运公司名称，电话，地址）；名称能否作键仍需“名称唯一”的业务前提。关键词用于定位约束，不能代替对题干和图的共同核对。

七、完整案例：宾馆信息管理系统¶

（一）阅读下列说明，回答问题1至问题3，将解答填入对应栏内。

原题说明¶

某宾馆为了有效地管理客房资源，满足不同客户需求，拟构建一套宾馆信息管理系统，以方便宾馆管理及客房预订等业务活动。

该系统的部分功能及初步需求分析的结果如下：

（1）宾馆有多个部门，部门信息包括部门号、部门名称、电话、经理。每个部门可以有多名员工，每名员工只属于一个部门；每个部门只有一名经理，负责管理本部门。

（2）员工信息包括员工号、姓名、岗位、电话、工资，其中，员工号唯一标识员工关系中的一个元组，岗位有经理、业务员。

（3）客房信息包括客房号（如1301、1302等）、客房类型、收费标准、入住状态（已入住/未入住），其中客房号唯一标识客房关系中的一个元组，不同客房类型具有不同的收费标准。

（4）客户信息包括客户号、单位名称、联系人、联系电话、联系地址，其中客户号唯一标识客户关系中的一个元组。

（5）客户预订客房时，需要填写预订申请。预订申请信息包括申请号、客户号、入住时间、入住天数、客房类型、客房数量，其中，一个申请号唯一标识预订申请中的一个元组；一位客户可以有多个预订申请，但一个预订申请对应唯一的一位客户。

（6）当客户入住时，业务员根据客户的预订申请负责安排入住客房事宜。安排信息包括客房号、姓名、性别、身份证号、入住时间、天数、电话，其中客房号、身份证号和入住时间唯一标识一次安排。一名业务员可以安排多个预订申请，一个预订申请只由一名业务员安排，而且可安排多间同类型的客房。

根据需求阶段收集的信息，设计的实体联系图如图2-1所示。

原题关系模式¶

部门（部门号，部门名称，经理，电话）
员工（员工号，（a），姓名，岗位，电话，工资）
客户（（b），联系人，联系电话，联系地址）
客房（客房号，客房类型，收费标准，入住状态）
预订申请（（c），入住时间，天数，客房类型，客房数量）
安排（申请号，客房号，姓名，性别，（d），天数，电话，业务员）

问题 1（4 分）：补全四个联系¶

根据问题描述，补充四个联系，完善图2-1的实体联系图。联系名可用联系1、联系2、联系3和联系4代替，联系的类型为1∶1、1∶n和m∶n（或1∶1、1∶*和*∶*）。

问题 1：参考答案与补充解析

课件原参考答案：问题 1

1、经理与部门之间存在1∶1的联系。

2、部门与员工之间存在1∶n的联系。

3、客户与预订申请之间存在1∶n的联系。

4、业务员、客房、预订申请之间存在1∶m∶n的联系。

补充推导与纠错¶

先看原图：经理、业务员已经与员工建立了特殊化关系，这两条不是待补的四个业务联系。参考图的联系编号与原答案列表顺序不完全一致，但题目允许自由命名，按端点和基数对应即可。

原答案图编号	端点及类型	题干依据
联系1	经理—部门 `1:1`	每部门一名经理；经理属于员工，只归属一个部门，并管理本部门
联系2	部门—员工 `1:n`	一个部门可有多名员工，每名员工只属于一个部门
联系3	业务员—客房—预订申请：业务员端为 `1`，另外两端为多	业务员按申请安排多间客房，一份申请只由一名业务员安排
联系4	客户—预订申请 `1:n`	一位客户可有多个申请，一个申请唯一对应一位客户

经理与部门的一对一限定在**经理子类型**，不能把它误读成所有员工与部门一对一。用表实现时，部门的经理字段应引用员工号，还需核对该员工岗位是经理、归属该部门，且没有同时管理另一个部门。

三元图的业务员端为 1，按固定另外两端的读法，只能表示：

1	`（申请号，客房号）→ 业务员`

但题干实际给出更强的约束：

1	`申请号 → 业务员`

例如同一申请分别安排 1301 和 1302 两个房间，不能让两条安排记录写成不同业务员。仅有三元联系端点上的 1，并不足以禁止这一情况；实现或论述时需要保留 申请号 → 业务员。

原答案文字将业务员、客房、预订申请写为 1:m:n，图中客房端标 n、预订申请端标 m；字母只是“多”的占位，实际约束一致。客房—申请的“多”涉及多次预订或安排的记录，不能据此认为同一房间在重叠时段可以分配给互不兼容的预订。

补充解析：题干关键词

原文线索	可以定位什么	不能跳过的核对
“每个部门可以有多名员工，每名员工只属于一个部门”	部门—员工 `1:n`	部门号应归并到员工表；可选参与与必须参与另行检查
“一个申请只由一名业务员安排”	`申请号 → 业务员`	同一申请安排多间客房时，业务员仍必须一致

问题 2（8 分）：补属性并确定主外键¶

（1）根据题意，将关系模式中的空（a）～（d）补充完整，并填入对应的位置。

（2）给出“预订申请”和“安排”关系模式的主键和外键。

问题 2：参考答案与补充解析

课件原参考答案：问题 2

（a）部门号。

（b）客户号、单位名称。

（c）申请号、客户号。

（d）身份证号、入住时间。

“预订申请”关系模式中的主键是申请号，外键是：客户号。

“安排”关系模式中的主键是：（客房号、身份证号、入住时间），外键是：申请号、客房号、业务员。

补充推导¶

空缺	为什么是这些属性
（a）部门号	部门—员工是一对多，部门号归并到多端的员工表
（b）客户号、单位名称	从客户需求句中补齐两个尚未列出的属性；客户号还是该表标识
（c）申请号、客户号	申请号标识申请，客户号来自客户—申请的一对多联系
（d）身份证号、入住时间	题干明确规定安排的标识由客房号、身份证号、入住时间共同组成；客房号已在表中

填全后的模式是：

部门（部门号，部门名称，经理，电话）
员工（员工号，部门号，姓名，岗位，电话，工资）
客户（客户号，单位名称，联系人，联系电话，联系地址）
客房（客房号，客房类型，收费标准，入住状态）
预订申请（申请号，客户号，入住时间，天数，客房类型，客房数量）
安排（申请号，客房号，姓名，性别，身份证号，入住时间，天数，电话，业务员）

关系	主键	外键及引用对象
预订申请	`申请号`	`客户号 → 客户.客户号`
安排	`(客房号, 身份证号, 入住时间)`	`申请号 → 预订申请.申请号`；`客房号 → 客房.客房号`；`业务员 → 员工.员工号`，并限制其为业务员岗位

“业务员”是员工编号引用，不应存成无法唯一识别员工的姓名。如果实现中单独建了业务员子类型表，也可以引用该表继承的员工号。主键与外键身份可以重叠：本题安排表中的客房号既是复合主键的一部分，也单独构成外键。

安排主键包含入住时间，是为了区分同一个人在同一间客房的不同入住。它按题目给定标识使用，不能改成只用客房号或身份证号，也不能因三元图有三个实体就机械地改成 (申请号, 客房号, 业务员)。

进一步的设计说明： 原模式将业务员放在每条安排记录中，但 申请号 → 业务员 要求这些重复值一致。实现时可以把该对应关系集中到申请或单独的办理关系中，再由安排引用申请；还要验证客房类型、入住时段等业务约束。这是对原模式的补充讨论，不改动本题原填空答案。

问题 3（3 分）：客房关系是否规范¶

【关系模式设计】中的“客房”关系模式是否存在规范性问题，请用100字以内文字解释你的观点（若存在问题，应说明如何修改“客房”关系模式）。

问题 3：参考答案与补充解析

课件原参考答案：问题 3（含原文笔误）

根据试题中的描述，客房信息中客房号是唯一标识客房关系的一个元组，即可以作为唯一的主键。在客房关系模式中，不存在其他部分依赖关系，但客户号->类型->收费标准，存在传递函数依赖，所以冗余，添加异常，修改异常，删除异常均存在。

修改：客房1（客房类型，收费标准）客房2（客房号，客房类型，入住状态）。

补充推导与纠错¶

原答案的 客户号 → 类型 → 收费标准 是笔误。这里分析的是客房表，正确写法是：

1
2
3

客房号 → 客房类型，入住状态
客房类型 → 收费标准
因此：客房号 → 客房类型 → 收费标准

按题目的收费规则理解，同一客房类型对应同一收费标准。不要自行扩展成收费标准反向决定客房号；房间很多、类型较少，即使两个类型恰好收费不同，收费仍不能识别具体客房。

在这些依赖下，客房号的闭包包含全部四个属性，是候选键；客房类型的闭包只有类型和收费标准，不能决定客房号及入住状态，不是超键。收费标准是非主属性，所以 客房类型 → 收费标准 违反 3NF；若各属性满足 1NF，原表在这些依赖下属于 2NF，不属于 3NF。

异常可以落实到具体操作：同类型多间房重复保存价格，会有冗余；调价漏改某一行会产生不一致；还没有具体房间时难以单独登记新类型和价格；删除某类型的最后一间房时，可能连该类型的收费信息一起丢失。

分解为：

客房类型收费（客房类型，收费标准）
  主键：客房类型

客房（客房号，客房类型，入住状态）
  主键：客房号
  外键：客房类型 → 客房类型收费.客房类型

两个新表覆盖原表全部属性，交集是“客房类型”。由于 客房类型 → 客房类型收费表的全部属性，二元分解满足无损连接条件。客房号 → 客房类型, 入住状态 和 客房类型 → 收费标准 分别可在对应新表检查，因此保持了上述依赖；在所列依赖下，两表均满足 BCNF。

可用于答题的 100 字以内修正版：

存在。客房号→客房类型→收费标准，收费标准传递依赖于主键，不满足3NF。分解为客房类型（客房类型，收费标准）和客房（客房号，客房类型，入住状态）。

补充解析：题干关键词

原文线索	可以定位什么	不能跳过的核对
“同类型具有同一收费标准”	`客房类型 → 收费标准`	收费标准重复存放是否形成传递依赖

本章宾馆题按 客房号 → 客房类型 → 收费标准 检查传递依赖，详细推导见案例问题 3。

历年大题练习¶

本节按年份由近到远收录 18 道完整历年大题。先展开题干独立作答，再展开其中的答案与解析；平台答案与整理补充继续分别保留。

题目复用题库中的同一份正文，题图使用本地文件。普通 Markdown 阅读器可通过原题链接进入；完整性与剩余试卷见大题整理进度。

2024年下半年 · 第 4 题：铁路货运订单数据库的概念与逻辑设计¶

展开原题（先作答，再查看解析）

铁路货运订单数据库的概念与逻辑设计

（四）（15分）

【说明】

为响应国家一带一路战略，某贸易公司开通运行中欧班列铁路货运。为规范货物收发流程，便于查询客户订单情况，需要开发一个信息系统。请根据下述需求描述完成该系统的数据库设计。

【需求描述】

（1）记录货物的信息，包括货物编号和货物名称。

（2）记录班列信息，包括班列编号、起点和终点信息。

（3）记录托运信息，一个班列可以托运不同的货物，同一批货物也可以用不同的班列托运。

（4）记录客户信息，包括客户姓名和手机号码。

（5）记录订单信息，包括订单编号、客户手机号码、班列编号、货物编号、数量和日期。同一个订单的货物可能装载在不同的班列。

【概念模型设计】

根据需求阶段收集的信息，设计的实体联系图（不完整）如图1所示。

图1 实体联系图

【逻辑结构设计】

根据概念模型设计阶段完成的实体联系图，得出如下关系模式（不完整；下划线按原页保留）：

货物（货物编号，名称）

班列（班列编号，起点和终点）

托运（货物编号，（a），日期）

客户（姓名，手机号码）

订单（订单编号，客户手机号码，（b），货物编号，数量，日期）

01（6分）
根据问题描述，补充图1的实体联系图。
02（4分）
补充逻辑结构设计结果中的（a）、（b）两处空缺及完整性约束关系。
03（5分）
若公司还代办客户委托签证业务，签证信息包括签证编号、签证国别和日期。
（1）在图1中补充新增加的“签证”实体，以及客户实体和签证实体之间的“委托”联系。
（2）给出“签证”的关系模式。

答案与解析

平台参考答案（原意保留）

平台参考答案（以下保留其建模表述与键定义，问题见下方解析）：

为“订单”联系增加“数量”和“日期”属性。平台写道：“订单和班列之间是多，订单和货物之间是多，订单和客户之间是1，订单和托运之间是多。”
（a）班列编号。托运的主键为（货物编号，班列编号）；外键为货物编号、班列编号。（b）班列编号。订单的主键为（订单编号，客户手机号，班列编号，货物编号）；外键为客户手机号、班列编号、货物编号。
签证实体增加签证编号、签证国别、日期三个属性；“签证和委托之间是多，客户和委托之间是1”。关系模式：签证（签证编号，客户手机号码，签证国别，日期）。

平台解析补充：“同一个订单的货物可能装载在不同的班列”据以判断订单与班列为1对多，并将订单与货物也表述为1对多。

解析与纠错

解析与纠错：

（1）先区分图中已经出现的事实与需要补充的假设。

图片已核：货物、班列、客户使用实体矩形；托运、订单使用联系菱形。“托运”已连接货物和班列，两端均为 *，并有日期属性；“订单”目前只连接订单编号属性，尚未连接参与实体。货物编号、班列编号、手机号码、订单编号在图片中有下划线。原页已确认逻辑模式的下划线：托运仅货物编号带下划线；订单中的订单编号、客户手机号码、货物编号带下划线；（a）（b）和托运日期均不带下划线。下划线是来源记载，不代表认定其键设定合理。
（a）与（b）均应补“班列编号”，由需求和关系模式可以直接确定。订单还需数量、日期属性，这一部分无争议。
平台要求把订单与托运两个联系直接相连，但普通 E-R 模型中的联系连接实体；若要把一个联系整体作为另一个联系的参与对象，需要明确采用聚集抽象，或者把托运实体化。给定图没有聚集框或托运实体化说明，不能据平台的一句话擅自补出两菱形直连线。
若按当前图补订单这一多元联系，参与者可识别为客户、班列、货物。不过多元联系端的 1 不是“每张订单一位客户”的简单同义词：在通常三元联系的基数语义中，客户端为1意味着固定另外两端的组合后至多一位客户，会限制多位客户在同一班列托运同种货物。加之重复订单如何区分也未说明，不能把平台的“1／多”标记直接当作已证明正确的概念模型。
“一个订单可以包含多个班列”只说明订单这一端的可扩展性，不能推出“每个班列只对应一个订单”；题目并未禁止同一班列承运不同订单。同理，不能仅凭一句话就把订单与货物的整体关系确定为1:N。采用订单实体、订单明细还是带标识属性的多元联系，会影响补图和基数解释；题干未明确这种建模约定，现有条件不能确定唯一补图。

（2）键与函数依赖需要满足业务条件。

货物以货物编号标识，班列以班列编号标识，客户按图中的手机号码标识。托运中的货物编号应引用货物，班列编号应引用班列；订单中的客户手机号码引用客户，货物编号引用货物，班列编号引用班列。引用列须对应被引用关系的候选键／唯一键，外键值应满足参照完整性；作为主键的属性不得为空且键值唯一。数量的类型、是否允许零、日期范围等细则题干未给出，不冒充已有约束。
平台把托运主键定为（货物编号，班列编号），隐含“一对货物—班列只记录一次托运”，从而有 (货物编号, 班列编号) → 日期。题干提到“同一批货物”，却没有独立批次号，也没有明确同一组合能否在不同日期重复托运，因此该主键只能作为附带条件的简化设计。若允许重复，必须重新确定运次／批次标识或其他足够的唯一性约束；不能无依据断言加入日期就必然唯一。
按通常“一张订单属于一位客户”的业务语义，有 订单编号 → 客户手机号码。因此平台的四属性订单主键包含冗余的客户手机号码，不满足候选键的最小性。SQL 即使接受声明这个组合为 PRIMARY KEY，也不能证明它是关系理论上的候选键；这个声明本身还不能阻止同一订单编号对应多个客户。
因为同一订单的货物可分装到不同班列，订单编号不能单独标识这种展开后的明细行。如果另外约定“同一订单、班列、货物组合至多一条明细”，并且没有进一步减少键的函数依赖，才可以选择 (订单编号, 班列编号, 货物编号) 作为明细键；该唯一性条件并未完整写在题干中，不能把它宣布为无条件唯一答案。
若明细必须引用一条已经登记的托运，仅有两个分别指向货物、班列的外键还不能验证二者构成有效托运组合；在托运确实以二者为键的简化模型下，可另加 (货物编号, 班列编号) → 托运(货物编号, 班列编号) 的复合外键。这里是引用约束写法，不是新增函数依赖。

（3）签证与委托。

按平台隐含的“每份签证委托归属一位客户、一位客户可有多份签证”假设，客户与签证为1:N，可设计 签证(签证编号, 客户手机号码, 签证国别, 日期)，签证编号为主键，客户手机号码为引用客户手机号码的外键；非空规则由是否必须存在委托客户决定。若需求允许一份签证记录关联多位客户等其他情况，则须另建委托关系，题干没有这类条件，不能自行代入。

本题能确定字段空缺及基本引用方向，下划线已按原页确认。原页托运仅下划货物编号、订单未下划（b），又与平台答案后续列出的联合键不一致；结合多班列托运需求，不能把原版下划线直接等同于已证明合理的主键。订单／托运的建模方式及业务唯一性条件仍不足以支持一个完全确定的标准补图与全部候选键。下方给出带条件的建模示例，作为条件化示例，不代表唯一答案。

补充与完整修正示例

有条件的建模示例：

为避免把订单编号与展开后的行混为一谈，可将订单实体化，并拆分订单头和订单明细。采用以下显式假设：一单一客户；同一货物与班列只登记一条托运；同一订单、班列、货物组合至多一条明细。若这些假设不成立，需重新选择键。

货物(货物编号 PK, 名称)
班列(班列编号 PK, 起点和终点)
客户(手机号码 PK, 姓名)
托运(货物编号 PK/FK, 班列编号 PK/FK, 日期)
订单头(订单编号 PK, 客户手机号码 FK)
订单明细(订单编号 PK/FK, 班列编号 PK/FK, 货物编号 PK/FK, 数量, 日期)
签证(签证编号 PK, 客户手机号码 FK, 签证国别, 日期)

“PK”在同一行有多列时表示联合主键。日期在订单明细中保留题干的位置；只有确认日期属于订单整体且满足 订单编号 → 日期 后，才应移至订单头。

概念联系为：客户1:N订单头，订单头1:N订单明细，班列1:N订单明细，货物1:N订单明细；托运关联货物和班列，客户1:N签证。若要求订单明细必须基于已登记托运，可让其复合外键 (货物编号, 班列编号) 引用托运，而不是在基本 E-R 图中直接把两个联系菱形相连。这里的基数只表述最大数量，题目未给出的最小参与数不额外设定。

2024年上半年 · 第 4 题：球队、球员与球迷数据库设计¶

展开原题（先作答，再查看解析）

球队、球员与球迷数据库设计

阅读下列说明，回答问题。
【说明】
某数据库记录球队、球员和球迷的信息。球队包括名称、多个球员等信息。球员包括名字、出生年月、入队时间等信息。球迷包括名字、性别、喜欢的球员、关注的球队等信息。一个球队有一个教练指导，教练也是球队的球员。

01（6分）
请列出数据库设计过程的6个阶段。

02（5分）
将图1所示的E-R图补充完整。

03（4分）
现要求在数据库中存储球员在球队的比赛记录信息，得到如图2所示E-R图。比赛记录包括比赛场次编号、比赛球队名称、上场时间等信息。将图2补充完整。

答案与解析

平台参考答案（原意保留）

平台参考答案：

数据库设计的六个阶段：需求分析、概念设计、逻辑设计、物理设计、实施、运行和维护。
（1）入队时间；（2）1；（3）1；（4）m；（5）n。其中（4）（5）可交换。
平台称应补充“球队和比赛之间同一实体的二元联系，分为主队和客队，呈现多比多关系”，并给出下图；（6）场次编号；（7）上场时间，两者可交换。

解析与纠错

解析与纠错：

六个设计阶段的顺序正确：需求分析明确业务与数据要求；概念设计形成E-R等概念模型；逻辑设计映射到关系模式并检查依赖；物理设计确定存储与访问结构；实施建立数据库、装载数据并测试；运行维护持续管理和优化。
图1已经给定“球队—组成—球员”的1:m关系，按该模型每名球员属于一个球队。题干要求每队一个教练，且教练也是本队球员，因此“指导”联系两端的最大基数可为1。这里不意味着每名球员都必须指导球队；球队端要求恰好一位教练，普通球员可不担任教练。
“教练属于被指导的同一球队”是跨联系约束：指导联系应是组成联系中球队—球员配对的子集。单独在指导两端标1并不能表达这一点，需要附加约束。喜欢关系按平台采用的多对多语义填m、n；题干未明确最小参与数，不应额外要求每位球迷或球员必须参与喜欢关系。
图1的（1）连接在球员实体上，因此可填入队时间。若进一步支持球员转会、重复入队或历史效力记录，则入队时间应随球员与球队的效力记录保存；这些扩展没有写在当前题干中。
图2的（6）（7）都是“比赛记录”联系的属性，填场次编号和上场时间可互换。比赛球队名称可通过与球队实体的联系取得，但“比赛记录”还需要连接实际参赛的球员与相应比赛／球队。
平台答案图只有“球队”实体集到“比赛”联系的主队、客队两个角色，表达球队之间的自联系。这能描述哪些球队交手，却没有连接球员，也不能单独表示某位球员的上场时间。它并未完整覆盖“球员在球队的比赛记录”这一要求；题干也没有明确必须采用主客场制。
更完整的一种方案是增加以场次编号标识的比赛实体，由球员通过“出场”联系参与比赛，在该联系上记录上场时间和代表球队。若只使用原图中的球队、球员两个实体，则至少应把比赛记录与它们相连，并说明如何用场次编号区分同一球员和球队的多次比赛记录。具体采用联系实体化还是附带场次标识的联系，需要明确建模约定；现有题面不足以确定所有基数及唯一的补图。

2023年下半年 · 第 1 题：汽车维修子系统的关系与实体联系设计¶

展开原题（先作答，再查看解析）

汽车维修子系统的关系与实体联系设计

【考生回忆版】

某汽车生产企业要在信息管理平台中增加汽车维修管理子系统。请依据以下需求完成数据库设计。

车辆记录车牌号、客户号、车型、颜色；车牌号唯一标识一辆车，每位客户至少有一辆车。
客户记录客户号、客户名称、客户性质、折扣率、联系人、联系电话；客户号唯一，客户性质分单位和个人。
员工记录员工号、员工名、部门号、岗位、电话、家庭住址；员工号唯一。岗位分业务员、维修主管、维修工。业务员检查车辆、分析故障，与客户协商故障现象和维修范围后填写维修单。
维修单记录维修单号、车牌号、故障类型、结算方式、维修主管、业务员；维修单号唯一。结算方式分自付、三包、索赔。每张维修单只对应一名维修主管，一名主管可负责多张维修单，并可把多个维修单任务分配给多名维修工。

图1为尚未补全的实体联系图。

由概念模型得到以下未完整的关系模式：

车辆(车牌号，客户号，车型，颜色)
客户(客户号，客户名称，客户性质，(a)，联系人，联系电话)
员工(（b），员工号，员工名，部门号，电话，家庭住址)
维修单(维修单号，车牌号，故障类型，结算方式，业务员，(c))

【问题1】（4分）补全关系模式中的属性(a)～©。

【问题2】（4分）图1缺少两个联系，请补出联系及其类型。联系名称可用“联系1”“联系2”，也可自行命名。

【问题3】（3分）维修单的主键为(d)，外键为(e)。

【问题4】（4分）客户若购买了多份车辆保险单，须说明相关情况。结算维修单对应车辆的维修费用时，还要考虑保险单的理赔比率。为此增加“保险单”实体，请在图中补充所需联系及其类型。

答案与解析

平台参考答案（原文保留）

【问题1】

a、折扣率
b、岗位
c、维修主管、维修工

【问题2】

业务员与车辆之间有1-n的检查关系。
业务员与维修单之间有1-n的填写关系。

【问题3】
维修单主键：(d) 维修单号
维修单外键：(e) 车牌号、业务员、维修主管、维修工

【问题4】
车辆和保险单之间有1-n的投保关系。

解析与纠错

平台答案按原文保留；其中把多维修工直接塞入维修单的做法有建模问题。

(a)为折扣率，(b)为岗位，均可由需求列出的属性与现有模式相减得到。维修单已含业务员、未含维修主管，所以©至少需要维修主管对应的员工号。平台还填入维修工，不能据此把同一维修单的多名维修工存成一个标量外键或一格列表。
图中已有“客户—拥有—车辆”“车辆—故障—维修单”及“维修单、维修主管、维修工—分配”三元联系。平台补的两条联系是业务员检查车辆、业务员填写维修单。填写联系按题中单个“业务员”字段可取业务员1对维修单多。检查联系的1对多是平台采用的简化口径；若保留同一车辆多次到店、由不同业务员检查的历史，需求没有保证每辆车只对应一名业务员，不能把该基数当成普遍事实。
(d)为维修单号。车牌号引用车辆；业务员和维修主管应保存相应员工标识并引用员工，而非直接把姓名或岗位当键。平台(e)还列维修工，是沿用其单表答案。按图中维修单与维修工两端的“多”，更稳妥的关系设计是把参与维修的对应关系单列，此时维修工外键放在分配关系中。
按一份车辆保险单归属一辆车的通常题设模型，车辆与保险单是1对多，符合平台答案；车辆在未投保时可对应0份，多份保单与理赔比率需要在结算时一并考虑。题文未给保单编号、险种、叠加赔付算法或具体比率，不补造这些数值或唯一结算公式。

补充说明

关系映射说明（独立改进方案，不替换平台答案）：

若一张维修单可分给多名维修工，可保留维修单(...，业务员，维修主管)，另建分配(维修单号，维修工号)；在“同一维修单与维修工只保留一条分配”的简化条件下，联合键可取两者。维修主管已由维修单号唯一决定，无须在每个分配记录中重复保存。若需区分工序、分派批次或历史记录，还需要题目未给出的标识，不能据现题断言两列一定是生产系统的完整主键。

原图的分配是三元联系，维修主管端为1、维修单和维修工端为多；“维修单只对应一名维修主管”的文字条件比一般三元联系中一个端的1更强。建表时须同时满足这条函数依赖，不能只机械照搬图上的三个数字。

2023年上半年 · 第 2 题：汽车零件采购与门店销售¶

展开原题（先作答，再查看解析）

汽车零件采购与门店销售

阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。

【说明】

某新能源汽车公司为了提升效率，需要开发一个汽车零件采购系统。请根据下述需求描述完成该系统的数据库设计。
【需求描述】
（1）记录供应商的信息，包括供应商的名称、地址和一个电话。
（2）记录零件的信息，包括零件的编码、名称和价格。
（3）记录车型信息，包括车型的编号、名称和规格。
（4）记录零件采购信息。某个车型的某种零件可以从多家供应商采购，某种零件也可以被多个车型采用，某家供应商也可以供应多种零件；还包括采购数量和采购日期。
【概念结构设计】

根据需求阶段收集的信息，设计的实体联系图（不完整）如图2-1所示。

图2-1 实体联系图

【逻辑结构设计】

根据概念结构设计阶段完成的实体联系图，得出如下关系模式（不完整）：

供应商（名称，地址，电话）

零件（编码，名称，价格）

车型（编号，名称，规格）

采购（车型编号，供应商名称，（a），（b），采购日期）

下划线按原页保留。

【问题1】（5分）

根据问题描述，补充图2-1的实体联系图（不增加新的实体）。
【问题2】（3分）

补充逻辑结构设计结果中的（a）、（b）两处空缺，并标注主键和外键完整性约束。
【问题3】（7分）

该汽车公司现新增如下需求：记录车型在全国门店的销售情况。门店信息包括门店的编号、地址和电话；销售包括销售数量和销售日期等。
对原有设计进行以下修改以实现该需求：
（1）在图2-1中体现门店信息及其车型销售情况，并标明新增的实体和联系，及其必要属性。
（2）给出新增加的关系模式，并标注主键和外键完整性约束。

注：

（1）本题为学员回忆版本，题干、问题、分值、答案、解析等内容都仅供参考。

（2）本题完整性约束，建议主键用实线下划线，外键用虚线下划线。因为编辑方式的影响，本题答案以文字形式进行说明。

答案与解析

平台参考答案（原意保留）

【问题1】（5分）

注：三元联系每条边以及多重度记1分，2个属性每个1分。
【问题2】（3分）
（1）

a：零件编码

b：采购数量
（2）

主键（车型编号，供应商名称，零件编号，采购日期）

外键（车型编号，供应商名称，零件编号）

注：关系模式补充每个1分，多写全扣；主键、外键每个0.5分，多写、少写、错写全扣。

【问题3】（7分）

（1）

注：二元联系及多重度1分，实体属性1.5分，联系属性1分，少写每个属性扣除0.5分，多写、错写全扣。
（2）
门店（编号，地址，电话）；主键：门店编号；外键：无。
销售（门店编号，车型编号，销售数量，销售日期）；主键（门店编号，车型编号，销售日期）；外键（门店编号，车型编号）。

注：门店关系模式1分，主键0.5分；销售关系模式1分，主键、外键各0.5分。多写、错写、少写全扣。

解析与纠错

三元联系。 “采购”把车型、供应商、零件同时联系起来，采购数量和采购日期是这次采购的属性。按平台采用的多对多对多模型补三条联系边即可；三个独立二元联系不能保存“哪家供应商向哪款车型供应哪种零件”的完整组合。题干没有给出固定两个参与者便唯一确定第三个的限制，采用一般的三元模型较稳妥，不应自行加入唯一供货商等条件。

属性与完整性。 原页已确认：所示下划线均为实线，采购日期有下划线，（a）（b）未划线。题目要求补全缺项及键约束；（a）是零件编码，（b）是采购数量，补全主键时仍需结合零件编码判断，不能把未填空处没有划线理解为最终键已完整。平台主键文字用了“零件编号”，应与模式统一为“零件编码”。采购中的车型编号、供应商名称、零件编码分别引用车型（编号）、供应商（名称）、零件（编码）：这是三个独立外键，不是引用某一个三列父表键的单个复合外键。销售中的门店编号与车型编号同理是两个外键。

日期与候选键。 平台参考答案把采购日期纳入采购主键、把销售日期纳入销售主键；平台解析却分别说仅组合三个实体的键、仅组合车型和门店的键，二者矛盾。若同一车型—供应商—零件组合在不同日期可重复采购，前三列不足以唯一标识记录；若同一门店可在不同日期反复销售同一车型，门店与车型两列也不足以唯一标识销售记录。

即使加上日期，仍需“相同组合每天至多一条记录（或已按日汇总）”的业务约束才能唯一确定数量。题干未规定同一天能否出现多笔采购或销售，因此不能无条件宣称这些日期组合键必然成立。若保存逐笔明细，应另设计交易标识或序号；这属于扩展设计，不作为原题缺失内容补入可见题干。

新增销售模型。 增加门店实体（编号、地址、电话），门店与车型之间设置多对多“销售”联系，属性为销售数量和销售日期。可得到门店（编号，地址，电话）及销售（门店编号，车型编号，销售数量，销售日期）；前者以编号为键，后者按上述日汇总假设取（门店编号，车型编号，销售日期）为键。采购也按同一假设取（车型编号，供应商名称，零件编码，采购日期）。这些假设应与关系模式一起说明。

2022年下半年 · 第 2 题：分公司与专卖店的数据库设计¶

展开原题（先作答，再查看解析）

分公司与专卖店的数据库设计

某营销公司拟建立业务管理系统，管理各地分公司和专卖店。根据以下需求完成数据库设计。

分公司记录分公司编号、分公司名、地址、电话；分公司编号唯一。一个分公司拥有多家专卖店，每家专卖店仅属于一个分公司。
专卖店记录专卖店号、专卖店名、店长、分公司编号、地址、电话；专卖店号唯一。每店只有一位负责各项业务的店长，每名店长只负责一家店。每店有多名职员，每名职员只属于一家店。
职员记录职员号、职员名、专卖店号、岗位、电话、薪资；职员号唯一。岗位包括店长、营业员等。

图2-1为未完成的实体联系图。

未完成的关系模式如下：

1
2
3

分公司（分公司编号，分公司名，地址，电话）
专卖店（专卖店号，专卖店名，___（a）__，地址，电话）
职员（职员号，职员名，____（b）___，岗位，电话，薪资）

【问题1】（6分）补出图2-1中缺少的三个联系及联系类型。联系名可用“联系1、联系2、联系3”，也可按题意命名。

【问题2】（6分）

（1）补全关系模式中（a）、（b）的属性。

（2）专卖店关系的主键为____（c），外键为（d）；职员关系的主键为（e），外键为（f）。

【问题3】（3分）为在紧急情况下及时联系职员家人，专卖店要求每位职员至少要填写位紧急联系人的姓名、与本人关系和联系电话。图2-1还需增加的实体为____（g），职员与该实体的联系类型为（h）__。

（3）给出新增实体的关系模式。

答案与解析

平台参考答案（原文保留）

【问题1】

【问题2】

（1）

（a）店长，分公司编号

（b）专卖店号

（2）

（c）专卖店号

（d）店长，分公司编号

（e）职员号

（f）专卖店号

【问题3】

（1）

（g）紧急联系人

（h） 1对多

（2）紧急联系人（联系人编号，职员号，紧急联系人姓名，关系，联系电话）

注：此处可以缺少紧急联系人编号。

解析与纠错

三个联系分别为：分公司—专卖店1:n、专卖店—店长1:1、专卖店—职员1:n。店长是职员中的一种岗位，不应另把店长姓名当成唯一标识。

（a）店长、分公司编号；（b）专卖店号；（c）专卖店号；（d）店长、分公司编号；（e）职员号；（f）专卖店号。其中“店长”字段应保存职员号，引用职员关系；分公司编号引用分公司，职员的专卖店号引用专卖店。1:1任职还需限制同一职员号不能担任多店店长，并保证其岗位及所属专卖店一致；单有外键并不能表达这些业务约束。

（g）紧急联系人；平台（h）为1:n，可把每条联系人记录视作属于某位职员的紧急联系记录。关系可设为紧急联系人（联系人编号，职员号，姓名，与本人关系，联系电话），联系人编号为主键，职员号为外键。若省略独立编号，就必须另确定能唯一标识联系记录的键；不能无条件假定姓名或电话唯一，也不能只以职员号为键而同时允许多个联系人。现实中同一自然人可以是多位职员的联系人，此时可进一步拆分联系人实体及关联关系，但这不是原题要求新增的事实。

原站可见页面已核实：原句为“专卖店要求每位职员至少要填写位紧急联系人的姓名、与本人关系和联系电话”，“填写”与“位”之间确实缺少数字。原题没有给出明确的最少人数，不能擅自补成“一位”或其他数量。平台1:n答案原样保留；它表达该建模方案可容纳多条联系人记录，不能据此确定题面未写明的最低人数。

2022年上半年 · 第 2 题：疫苗接种与检测记录¶

展开原题（先作答，再查看解析）

疫苗接种与检测记录

按照下列图表，填写答题纸的对应栏内。【说明】为了提高接种工作的效率，并为了抗击疫情提供疫苗接种数据支撑，需要开发一个信息系统，根据下述需求完成该系统的数据库设计。（1）记录疫苗供应商的信息，包括供应商名称，地址和一个电话。（2）记录接种医院的信息，包括医院名称、地址和一个电话。（3）记录接种者个人信息，包括姓名、身份证号和一个电话。（4）记录接种者疫苗接种信息，包括接种医院信息，被接种者信息，疫苗供应商名称和接种日期，为了提高免疫力，接种者可能需要进行多次疫苗接种，（每天最多接种一次，每次都可以在全市任意一家医院进行疫苗接种）。【概念模型设计】根据需求分析阶段收集的信息，设计的实体联系图（不完整）如图2-1所示。

图2-1 E-R图

【逻辑结构设计】根据概念模型设计阶段完成的实体联系图，得出如下关系模式（不完整）供应商（供应商名称、地址、电话）医院（医院名称、地址、电话）供货（供应商名称、（a）、供货内容）被接种者（姓名、身份证号、电话）接种（接种者身份证号、（b）、医院名称、供应商名称）

【问题1】（4分）根据问题描述，补充图2-1的实体联系图（不增加新的实体）。【问题2】（4分）补充逻辑结构设计结果中的（a）（b）两处空缺，并标注主键和外键完整性约束。【问题3】（7分）若医院还兼有核酸检测的业务，检测时可能需要进行多次核酸检测（每天最多检测一次），但每次都可以在全市任意一家医院进行检测。请在图2-1中增加“被检测者”实体及相应的属性，医院与被检测者之间的“检测”联系及必要的属性，并给出新增加的关系模式。 “被检测者”实体包括姓名、身份证号、地址和一个电话。“检测”联系需要包括检测日期和检测结果等。

答案与解析

平台参考答案（原意保留）

【问题1】（4分）

【问题2】（4分）

（a）医院名称

（b）接种时间

【问题3】

新增关系模式

被检测者（身份证号，姓名，地址，电话）

检测（被检测者身份证号，医院名称，检测日期，检测结果）

解析与纠错

概念模型。 供应商、医院、被接种者通过三元“接种”联系记录同一次接种，日期是联系属性。题图已有供应商与医院的多对多“供货”联系及供货内容，不要再把它误作待新增实体。接种涉及三个实体，不宜拆成互不约束的“人—医院”“人—供应商”两张关系后丢失同一次接种的组合。

填空与键。 已回看原页确认：五个关系模式均未标注主键实线或外键虚线，不能从原题排版推断已指定的键。（a）医院名称；（b）接种日期，平台称“接种时间”。供应商以供应商名称、医院以医院名称、被接种者以身份证号标识。供货以（供应商名称，医院名称）作为该供货关系的键，两个属性分别引用供应商和医院；这描述的是题给供货关系，不自动表示可区分多批历史供货。

本题明确规定：同一个人每天最多接种一次，而且可以在不同医院接种。因此有函数依赖“（接种者身份证号，接种日期）→医院名称、供应商名称”，日期不相同才允许该人出现下一条接种记录。接种的候选键是（接种者身份证号，接种日期）；医院名称、供应商名称不能为了照套三元联系模板而全部放进最小键。若仅使用（身份证号，医院名称，日期）作为唯一约束，还会错误地允许同一个人同一天在不同医院出现两条记录。

接种中的身份证号、医院名称、供应商名称分别引用被接种者、医院、供应商，是三个独立外键。平台答案图的二列接种主键是符合“每天最多一次”条件的；若“接种时间”保存到时分秒，还应落实按日的唯一性，不能让不同时间戳绕过同日限制。

新增检测模型。 增加被检测者（身份证号，姓名，地址，电话），主键为身份证号；医院与被检测者之间增加多对多“检测”联系，属性为检测日期、检测结果。关系模式为检测（被检测者身份证号，医院名称，检测日期，检测结果），主键为（被检测者身份证号，检测日期），分别以被检测者身份证号和医院名称引用两个实体。这里同样由题定“每天最多检测一次”排除医院名称进入最小键。不能把“每天最多一次”误解成每家医院各一次。

平台解析把接种时间称为需要补充的“实体属性”不准确，它是一次接种联系的属性；平台答案图中的位置已画在接种联系上。新增被检测者实体是题目明确要求，不因现实中可能与被接种者重合而自行合并掉该实体。

补充与完整参考实现

平台解析附图（原图保留）：

2021年下半年 · 第 2 题：汽车维修系统的数据库设计¶

展开原题（先作答，再查看解析）

汽车维修系统的数据库设计

某汽车维修公司拟建立汽车维修管理系统，需求如下。

客户记录包含客户号、客户名、客户性质、折扣率、联系人、联系电话。客户性质为个人或单位；客户号唯一标识每个客户元组。
车辆记录包含车牌号、车型、颜色、车辆类别。一个客户至少拥有一辆车，每辆车只属于一个客户。
员工记录包含员工号、员工名、岗位、电话、家庭住址。员工号唯一标识每个员工元组；岗位有业务员、维修工、主管。业务员依据车辆故障填写维修单。
部门记录包含部门号、名称、主管、电话。部门号唯一确定每个部门元组；每个部门只有一名主管，并有多名员工，每名员工只属于一个部门。
维修单记录包含维修单号、车牌号、维修内容、工时、维修员工号。维修单号唯一标识每个维修单元组；一个维修工可接多张维修单，一张维修单只对应一个维修工。

图2-1为尚未补全的实体联系图。

根据概念模型得到以下待补全的关系模式：

客户（客户号，客户名，(a)，折扣率，联系人，联系电话）
车辆（车牌号，(b)，车型，颜色，车辆类别）
员工（员工号，员工名，岗位，©，电话，家庭住址）
部门（部门号，名称，主管，电话）
维修单（维修单号，(d)，维修内容，工时）

【问题1】（6分）补充3个联系，完善图2-1。联系名可写为联系1、联系2、联系3；联系类型用1:1、1:n、m:n（或1:1、1:、.*）表示。

【问题2】（4分）填写关系模式空(a)～(d)中的属性。

【问题3】（2分）分别给出车辆关系与维修单关系的主键、外键。

【问题4】（3分）若一张维修单包含多项维修内容，需要多个维修工处理，哪个联系的类型会怎样变化？如何解决？

答案与解析

平台参考答案（原文保留）

【问题1】(6分) 联系1:客户和车辆：1:n 联系2:部门和员工：1:n 联系3:维修工和维修单：1:n 【问题2】(4分) a：客户性质 b：客户号 c：部门号 d：车牌号，维修员工号【问题3】(2分) 车辆关系的主键：车牌号外键：客户号维修单关系的主键：维修单号外键：车牌号，维修员工号【问题4】(3分) 维修工和维修单之间的联系类型会发生变化，从1:n变成m:n。对应的需要增加维修关系，m：n关系不能归并，需要将其单独加入一个联系中，将维修单的属性员工号（维修工）删掉，新建一个关系模式维修。维修（员工号（维修工），维修单号，维修地点，维修时间）

解析与纠错

三条待补联系分别是客户1—n车辆、部门1—n员工、维修工1—n维修单。图中已有车辆、维修单、业务员之间的“故障”联系，以及部门与主管的管理联系，不要重复补画。

空(a)为客户性质；空(b)为客户号；空©为部门号；空(d)为车牌号、维修员工号。把1:n联系转换为关系模式时，将1端主键放入n端作为外键，因此车辆引用客户号，员工引用部门号，维修单引用车牌号和维修员工号。平台长解析把(b)写成“车辆号”是笔误，平台答案中的“客户号”与题意一致。

车辆的主键为车牌号，外键为客户号；维修单的主键为维修单号，外键为车牌号、维修员工号，分别引用车辆及维修工对应的员工记录。

若一单可由多名维修工处理，维修工与维修单由1:n变为m:n。应从维修单移出单值维修员工号，建立关联关系“维修（维修员工号，维修单号）”；在每位维修工对每张维修单至多记一条关联的前提下，两属性组成主键并各作外键。平台答案额外加入“维修地点、维修时间”，原需求没有规定这两个属性，不能据此认定它们是必填条件。若还要按维修项目分派人员、登记工时，应依据新增业务规则设计维修明细，不能让一列存放多个员工号。

2021年上半年 · 第 2 题：社区蔬菜团购的数据库设计¶

展开原题（先作答，再查看解析）

社区蔬菜团购的数据库设计

某社区蔬菜团购网站需要信息系统，以规范商品收发并查询客户订单。数据库需求如下。

蔬菜供应商记录包括供应商编号、地址和一个电话。
社区团购点记录包括团购点编号、地址和一个电话。
客户记录包括客户姓名和一个电话。客户可以向不同社区团购点下订单，不直接与蔬菜供应商联系。
订单记录包括订单编号、团购点编号、客户电话、订单内容和日期。

图2-1给出未补全的实体联系图。

由概念模型得到以下尚未补全的关系模式：

蔬菜供货商（供货商编号，地址，电话）
社区团购点（团购点编号，地址，电话）
供货（供货商编号，(a)）
客户（姓名，客户电话）
订单（订单编号，团购点编号，订单内容，日期，(b)）

【问题1】（6分）按需求补充图2-1的实体联系图。

【问题2】（4分）填写关系模式的(a)、(b)，并补充完整性约束关系。

【问题3】（5分）若网站兼营代收快递，增加“快递”实体及其与客户之间的“收取”联系，补充图2-1。“快递”关系模式包含快递编号、客户电话、日期。

答案与解析

平台参考答案（原文保留）

【问题1】

【问题2】
（a）：团购点编号。主键为：（供货商编号，团购点编号），外键为：供货商编号，团购点编号。
（b）：客户电话。主键为：订单编号，外键为：团购点编号，客户电话。
【问题3】
若社区蔬菜团购网站还兼有代收快递的业务，请增加新的“快递”实体，并给出客户实体和快递实体之间的“收取”联系，对图2-1进行补充。“快递” 关系模式包括快递编号、客户电话和日期。

图2-1 实体联系图

解析与纠错

图中供应商与团购点的“供货”已是多对多联系，缺少的是团购点与客户之间的“订单”联系及订单内容、日期属性。客户可向多个团购点下单，每个团购点也可服务多个客户，因此两端均为多。订单编号、订单内容、日期属于每次订单，而非客户或团购点的固有属性。

(a)为团购点编号。供货表以（供货商编号，团购点编号）为联合主键，两列分别引用蔬菜供货商与社区团购点；(b)为客户电话。订单表以订单编号为主键，团购点编号引用社区团购点，客户电话引用客户。各主键应唯一且非空；非空外键必须匹配被引用记录。客户电话作为标识由原题图中的下划线给出，不能仅凭“一人一个电话”的文字自行推出全体客户电话号码唯一。

若同一客户可多次向同一团购点下单，不能将“客户电话+团购点编号”当作订单主键；应保留订单编号，把订单视作可重复发生的关联实体，这也与平台逻辑模式一致。

新增快递后，客户1—n快递，联系名为“收取”。快递（快递编号，客户电话，日期）以快递编号为主键、客户电话为外键；客户电话不能作快递表的唯一键，否则一名客户只能有一件快递。

2020年 · 第 2 题：分公司与职员信息的数据库设计¶

展开原题（先作答，再查看解析）

分公司与职员信息的数据库设计

M集团有多个分公司，拟建设信息平台管理各分公司的职员和业务。需求如下。

分公司记录分公司编号、名称、经理号、联系地址、电话；分公司编号唯一标识一个元组。每个分公司只有一名经理。各分公司下设仅为本分公司服务的多个业务部，例如研发部、财务部、采购部、销售部。
业务部记录业务部编号、名称、主管号、电话、分公司编号；业务部编号唯一标识一个元组。每个业务部只有一名主管，并有多名职员；每名职员只能隶属一个业务部。
职员记录职员号、姓名、所属业务部编号、岗位、电话、家庭成员姓名、成员关系；职员号唯一标识一个元组。岗位包括经理、主管、研发员、业务员等。

图2-1给出未补全的实体联系图。

待补全的关系模式按以下顺序列出：

分公司（分公司编号、名称、(a)、联系地址）
业务部（业务部编号、名称、(b)、电话）
职员（职员号、姓名、岗位、©、电话、家庭成员姓名、成员关系）

【问题1】（4分）补充4个联系，使图2-1完整；联系名可用联系1～联系4，类型从1:1、1:n、m:n（也可写1:1、1:、:*）中选择。

【问题2】（3分）填写关系模式中的(a)～©属性。

【问题3】（4分）（1）说明分公司关系模式的主键、外键；（2）说明业务部关系模式的主键、外键。

【问题4】（4分）若每名职员有多名家庭成员，现有职员关系模式存在什么问题？如何解决？

答案与解析

平台参考答案（原文保留）

【问题1】

【问题2】

（a）经理号，电话

（b）分公司编号，主管号

（c）所属业务部编号

【问题3】

【问题4】

在职员关系中，如果每个职员有多名家庭成员，会重复记录多条职员信息及对应家庭成员，为了区分各条记录，职员关系的主键需要设定为（职员号，家庭成员姓名），会产生数据冗余、插入异常、更新异常、删除异常等问题。

处理方式：

对职员关系模式进行拆分，职员1（职员号、姓名、岗位、所属业务部编号，电话）；职员2（职员号，家庭成员姓名，关系）。

解析与纠错

按平台图，联系1是分公司1:n业务部，联系2是分公司1:1经理，联系3是业务部1:n职员，联系4是业务部1:1主管。题意明确每个分公司一个经理、每个业务部一个主管；平台的1:1画法还采用了经理、主管各只负责一个对应组织的建模约定。若实际允许兼管多个组织，反向基数需要另行规定，不能把单向“只有一名”普遍当成双向一对一。

对照完整需求与所给模式：(a)补经理号、电话；(b)补分公司编号、主管号；©补所属业务部编号。分公司主键为分公司编号，经理号是引用职员号的外键；业务部主键为业务部编号，外键有分公司编号和主管号，分别引用分公司与职员。还应以业务约束保证经理号、主管号指向相应岗位；一般外键本身不能检查岗位值。

若一行把多个家庭成员塞进同一字段，会出现非原子取值；若每个家庭成员各占一行，原来“职员号唯一”的约束便不再成立，并会反复保存职员姓名、岗位、部门、电话，产生冗余及插入、更新、删除异常。可以拆为职员（职员号、姓名、岗位、所属业务部编号、电话）和家庭成员（职员号、家庭成员姓名、成员关系），后表以职员号引用前表。

平台提出的（职员号，家庭成员姓名）作为后表主键，需要同一职员的家庭成员不同名这一额外前提；原题未保证这一点。若允许同名，应增加家庭成员编号，再用（职员号，家庭成员编号）或独立编号标识。该补充不改变平台原答案。

2019年下半年 · 第 2 题：新员工培训的数据库设计¶

展开原题（先作答，再查看解析）

新员工培训的数据库设计

公司计划开发新入职员工技能培训管理系统，使新员工快速胜任岗位。需求如下。

部门信息包括部门号、名称、部门负责人、电话等；部门号唯一标识部门元组。一个部门有多个员工，每名员工只属于一个部门；每个部门只有一名负责人，负责部门工作。
员工信息包括员工号、姓名、部门号、岗位、基本工资、电话、家庭住址等；员工号唯一标识员工元组。岗位有新入职员工、培训师、部门负责人等，不同岗位设置不同的基本工资。新入职员工选择多门课程培训，并通过考试取得课程成绩。一名培训师可讲授多门课程，一门课程可由多名培训师讲授。
课程信息包括课程号、课程名称、学时等；课程号唯一标识课程元组。

图2-1给出实体联系图。

关系模式按原顺序列出：

部门（部门号，部门名，部门负责人，电话）
员工（员工号，姓名，部门号，d，电话，家庭住址）
课程（e，课程名称，学时）
讲授（课程号，培训师，培训地点）
培训（课程号，（f））

【问题1】（5分）（1）补充图2-1中的空（a）～（c）；（2）判断是否缺少联系，若有，说明联系及其类型。

【问题2】（3分）填写关系模式的空（d）～（f）。

【问题3】（5分）员工关系模式的主键为（g），外键为（h）；讲授关系模式的主键为（i），外键为（j）。

【问题4】（2分）员工关系是否存在传递依赖？用100字以内说明理由。

答案与解析

平台参考答案（原文保留）

【问题1】

（1）（a）部门负责人；（b）培训师；（c）新入职员工

（2）存在缺失联系：员工与部门之间隶属关系，联系类型*:1。

（或，存在缺失联系：部门与员工之间隶属关系，联系类型1:*）。

【问题2】

（d）岗位，基本工资；（e）课程号；（f）新入职员工/新入职员工工号，课程成绩

【问题3】

【问题4】
存在传递函数依赖。
在员工关系中，员工的岗位有新入职员工，培训师，部门负责人，不同岗位设置不同的基本工资，即存在传递函数依赖，员工号→岗位，岗位→基本工资。

解析与纠错

图中的员工按岗位分化：与部门有“负责”联系的是(a)部门负责人，与课程“讲授”的是(b)培训师，与课程“培训”的是©新入职员工。还应补部门1:*员工的隶属联系，反向为员工*:1部门。

(d)补岗位、基本工资，(e)补课程号；培训是新员工与课程的多对多关系，(f)要补新入职员工工号和课程成绩。员工主键(g)为员工号，外键(h)为部门号，引用部门关系。讲授按原图的一般联系模型，用(培训师，课程号)作为主键(i)；(j)包含培训师、课程号两个外键，分别引用相应人员与课程。

平台另允许把培训地点加入讲授主键，这依赖“同一培训师可在不同地点讲同一课程、且三者足以区分记录”的业务约定，题目没有明确这些规则。若(培训师，课程号)已唯一，加入地点只是非最小超键；不能同时断言二者都是候选键。

问题4的100字以内作答可为：“存在。员工号决定岗位，岗位决定基本工资；岗位不是员工关系的候选键，因此基本工资对员工号存在经岗位的传递依赖。”分解时可另设岗位（岗位，基本工资），员工只保存岗位。原题问题3、问题4分值为5分、2分，平台长解析的预估4分、3分不替代题面分值。

2019年上半年 · 第 2 题：创业项目投资的数据库设计¶

展开原题（先作答，再查看解析）

创业项目投资的数据库设计

某创业孵化基地管理多家孵化公司和创业公司，拟建立信息系统规范创业项目投资业务。需求如下。

孵化公司保存公司代码、公司名称、法人代表名称、注册地址、一个电话；创业公司保存公司代码、公司名称、一个电话。两类公司的公司代码编码不同。
两类公司的员工统一管理，保存工号、身份证号、姓名、性别、所属公司代码、一个手机号；工号唯一标识员工。
投资方保存投资方编号、投资方名称、一个电话。
孵化公司为投资方与创业公司牵线建立创业项目合作关系，由孵化公司的一位员工具体协调投资方和创业公司的一个创业项目。一个项目只属于一个创业公司，但可接受多个投资方投资。项目信息含项目编号、创业公司代码、投资方编号、孵化公司员工工号。

图2-1是尚未完成的实体联系图。

由概念模型得到的关系模式如下，保留原有标记及顺序：

孵化公司（公司代码，公司名称，法人代表名称，注册地址，电话）创业公司（公司代码，公司名称，电话）员工（工号，身份证号，姓名，性别，（a），手机号）投资方（投资方编号、投资方名称，电话）项目（项目编号，创业公司代码#，（b），孵化公司员工工号#）

【问题1】（5分）根据需求补充图2-1实体联系图。

【问题2】（4分）补充关系模式中的（a）、（b），并补充完整性约束关系。

【问题3】（6分）若还要记录投资额和投资时间：（1）是否需要增加实体？（2）若需要，给出新实体关系模式并补图；若不需要，将这两个属性连到图2-1的合适对象，并修改发生变化的关系模式。

答案与解析

平台参考答案（原文保留）

【问题1】（5分）

【问题2】（4分）

（a）所属公司代码

（b）投资方编号

完整性约束关系

员工-外键：所属公司代码项目-主键：（项目编号、投资方编号）组合主键项目-外键：投资方编号，题干已给出外键创业公司编号、孵化公司员工工号

【问题3】（6分）（1）不需要（2）关系模式：项目（项目编号，创业公司代码，投资方编号，孵化公司员工工号，投资额，投资时间）

解析与纠错

补创业公司1:*员工的管理联系；平台还把项目画成员工、投资方、创业公司的三元联系，端点依次为1、*、1。(a)为所属公司代码，(b)为投资方编号。员工主键工号；项目按平台采用(项目编号，投资方编号)组合主键，创业公司代码、投资方编号、孵化公司员工工号作为引用字段。

原页AX与截图已核实五行关系模式均无下划线，项目行两处#保留；平台长解析称主键“题目已经用下划线标出”与当前可见题面不符，不能据此给题干补提示。

“所属公司代码”在业务上可指两类公司的任一家，不能在常规SQL中同时给它加两条分别引用两表的外键来表达“二选一”：两条外键会要求该值同时存在于两表。可引入统一的公司父表供员工引用，再记录公司类型及子类专有属性；也可分开建员工隶属关系并另约束唯一归属。项目协调工号还须确实属于孵化公司员工，仅引用普通员工工号不足以检查这一岗位归属。

平台1:*:1的三元图是按每个项目一个创业公司、一个协调员工的意图给出的，但三元联系的“1”通常是固定其他两端时的唯一性，不等同于“每个项目只有一个”。若同一投资方与同一创业公司有多个项目或不同协调员工，三元端点可能产生额外限制。以项目编号标识项目，并明确项目、投资方之间的投资关系，更容易表达这些规则。不能仅凭每个项目归属唯一，就宣称任意三元联系必为1:*:1。

问题3按题目当前粒度不必增加实体：投资额、投资时间可作为“项目”联系的属性，关系改为项目（项目编号，创业公司代码，投资方编号，孵化公司员工工号，投资额，投资时间）。这默认每对(项目编号，投资方编号)只记录一笔投资；若同一方对同一项目分多次投资，就需投资记录编号或足以区分记录的键，不能仍让这个二元键唯一而覆盖历史。

2018年下半年 · 第 2 题：分公司部门与任职历史的数据库设计¶

展开原题（先作答，再查看解析）

分公司部门与任职历史的数据库设计

某集团拥有多个分公司，拟开发业务管理信息系统。需求如下。

分公司记录分公司编号、名称、经理、联系地址、电话；编号唯一标识分公司元组。每个分公司仅有一名经理负责管理，并下设多个只为本分公司服务的业务部门，如研发部、财务部、采购部、销售部。
部门记录部门号、部门名称、主管号、电话、分公司编号；部门号唯一标识部门元组。每个部门仅有一名主管负责管理，并有多名员工；每名员工只能隶属一个部门。
员工记录员工号、姓名、隶属部门、岗位、电话、基本工资；员工号唯一标识员工元组。岗位包括经理、主管、研发员、业务员等。

图2-1给出尚未完成的实体联系图。

关系模式保持原有顺序与写法：

分公司（分公司编号，名称，（a），联系地址，电话）
部门（部门号，部门名称，（b），电话）
员工（员工号，姓名（c），电话，基本工资）

【问题1】（4分）补充4个联系完善图2-1。名称可写联系1～联系4；联系类型为1:1、1:n、m:n，也可用1:1、1:*、*:*表示。

【问题2】（5分）补全关系模式空(a)～©。

【问题3】（4分）写出“部门”“员工”关系模式的主键及外键。

【问题4】（2分）若要记录部门历任主管的任职时间和任职年限，数据库设计是否需增设实体？说明理由。

答案与解析

平台参考答案（原文保留）

【问题1】

联系1：分公司：经理，1:1

联系2：分公司：部门，1:*

联系3：部门：主管，1:1

联系4：部门：员工，1:*

【问题2】
（a）经理工号
（b）分公司编号，主管号
（c）隶属部门，岗位
【问题3】
部门
主键：部门号；外键：分公司编号，主管号
员工
主键：员工号；外键：隶属部门

【问题4】

不需要增加新的实体，对于任职情况，可以将任职时间和任职年限放入联系的属性即可，将部门与主管的联系单独形成关系模式，任职（部门号，主管工号，任职时间，任职年限）。

解析与纠错

四个联系依次可取分公司—经理1:1、分公司—部门1:*、部门—主管1:1、部门—员工1:*。其中经理、主管的双向一对一是平台采用的岗位建模约定；单凭“每个组织只有一名负责人”本身不能证明同一人一定不兼管多个组织。

问题4按平台无需另设独立业务实体，可给“部门—主管”的任职联系增加任职时间、任职年限，并单独映射为任职（部门号，主管工号，任职时间，任职年限）。不新增概念实体不等于无需新增关系表：当前部门行只存一个主管号，不能独自保存历任记录。

若同一主管可重复任职，不能仅以(部门号，主管工号)唯一标识全部任期，可增加任职起点或任职编号。历史上同一部门会对应多位主管，但“同一时刻只有一位”仍应约束任期不重叠；这区别于当前任职的一对一联系。

2018年上半年 · 第 2 题：海外代购与顾客地址的数据库设计¶

展开原题（先作答，再查看解析）

海外代购与顾客地址的数据库设计

某海外代购公司拟开发信息化管理系统，业务需求如下。

员工分代购员、配送员；记录工号、身份证号、姓名、性别和一个手机号，工号唯一标识员工。
商品记录名称、所在超市名称、采购价格、销售价格及介绍；内部用商品条码唯一标识商品，每种商品只在一家超市代购。
顾客记录真实姓名、用于清关缴税的身份证号、一个手机号及一个收货地址；系统生成唯一顾客编号。
托运公司记录名称、电话、地址；系统生成唯一托运公司编号。
顾客登录后下订单，支付成功后记录唯一支付凭证编号；订单指定空运或海运。
代购员按订单到超市采购；一份订单含多个商品，可能由多名代购员从不同超市采购。
配送员按顾客订单将已采购商品组合装箱，交托运公司。托运公司核对订单商品名称及数量，按顾客地址运送。

图2-1为尚未完成的实体联系图。

逻辑结构设计的关系模式如下，保留字段、空位和原有#标记：

员工（工号，身份证号，姓名，性别，手机号）

商品（条码，商品名称，所在超市名称，采购价格，销售价格，商品介绍）

顾客（编号，姓名，身份证号，手机号，收货地址）

托运公司（托运公司编号，托运公司名称，电话，地址）

订单（订单ID，（a），商品数量，运送方式，支付凭证编号）

代购（代购ID，代购员工号#，（b））

运送（运送ID，配送员工号#，托运公司编号#，订单ID#，发运时间）

【问题1】（3分）根据说明补充图2-1。

【问题2】（6分）补充关系模式中的（a）、（b）。

【问题3】（6分）现允许顾客保存多组收货地址；增加“顾客地址”弱实体，补充图2-1，并修改“运送”关系模式。

答案与解析

平台参考答案（原文保留）

【问题1】

【问题2】

（a）商品条码#，顾客编号#

（b）订单ID#，商品条码#

【问题3】

新增一个弱实体顾客地址，新增一个联系客户收货地址，连接顾客实体和顾客地址类型为1:*；弱实体用双矩型表示。
运送关系模式增加属性：顾客地址
运送（运送ID，配送员工号#，托运公司编号#，订单ID#，顾客地址#，发运时间）

解析与纠错

问题1把“运送”连接到配送员、托运公司和顾客—商品的订单聚合，平台采用三元多对多联系；不要拆成三条彼此独立的二元联系后丢失“谁把哪张订单交给哪家公司”的组合信息。

(a)补商品条码#、顾客编号#，使订单关联所购商品及下单者；(b)补订单ID#、商品条码#，使代购记录能定位代购员负责的订单商品。#按原题表示引用字段，不能据此把所有这些字段都当作主键。

需区分“整张顾客订单”与“订单中的商品行”：说明允许同一订单有多个商品，若订单ID唯一标识整张订单，原关系中一个商品条码和商品数量不能容纳全部商品。规范实现可分订单头与明细，明细以(订单ID，商品条码)或订单行号标识，代购再引用相应明细；这是对原设计粒度的说明，不替换平台填空。原页截图已核实并保留工号、条码、编号、托运公司编号、订单ID、订单(a)、代购(b)、运送ID的下划线；代购ID没有下划线。(a)/(b)是空位本身带下划线，不能据此断言填入的全部字段都属于主键。

新增的顾客地址依赖顾客存在，图用双矩形弱实体和识别联系，顾客到地址为一对多。平台在运送中加顾客地址#；实现时必须说明这个引用如何唯一识别地址。例如以(顾客编号，地址序号)作弱实体键时，引用也须能确定这两个分量，并保证地址属于该订单顾客。仅在文字上写一个没有键定义的“顾客地址#”，不足以说明完整参照约束。答案图保留原画法，学习时留意弱实体的全参与也应表达。

2017年下半年 · 第 2 题：会议策划业务的数据库设计¶

展开原题（先作答，再查看解析）

会议策划业务的数据库设计

M公司拟构建基于网络的会议策划系统，便于开展、管理业务，并提高知名度与影响力。需求如下。

公司设业务部、策划部及其他部门。部门记录部门号、部门名、主管、联系电话、邮箱号；每部门只有一位只管理本部门的主管，主管引用员工号。部门有多名员工，每名员工仅属于一个部门。
员工记录员工号、姓名、职位、联系方式、薪资，职位包括主管、业务员、策划员等。业务员受理用户申请并设置受理标志；一人可受理多份申请，每份申请仅由一位业务员受理。
用户记录用户号、用户名、银行账号、电话、联系地址，用户号唯一标识元组。
用户申请记录申请号、用户号、会议日期、天数、参会人数、地点、预算、受理标志；申请号唯一。一名用户可提交多份申请，每份申请只对应一名用户。
策划部主管为已受理申请制定策划任务；任务记录申请号、任务明细、要求完成时间，申请号唯一标识任务。每个任务对应一个已受理申请；任务可由多名策划员执行，每名策划员也可执行多项任务。

图2-1为尚未完成的实体联系图。

关系模式保持字段、空位及顺序：

部门（部门号，部门名，部门主管，联系电话，邮箱号）

员工（员工号，姓名，（a），联系方式，薪资）

用户（用户名，（b），电话，联系地址）

用户申请（申请号，用户号，会议日期，天数，参会人数，地点，受理标志，（c））

策划任务（申请号，任务明细，（d））

执行（申请号，策划员，实际完成时间，用户评价）

【问题1】（5分）补充五个联系完善图2-1；可命名为联系1～联系5，类型为1:1、1:n、m:n，也可写作1:1、1:*、*:*。

【问题2】（4分）填写关系模式空（a）～（d）。

【问题3】（4分）写出“用户申请”和“策划任务”的主键、外键。

【问题4】（2分）“执行关系模式的主键为全码”的说法是否正确？说明理由。

答案与解析

平台参考答案（原文保留）

【问题1】 1.联系1：部门和员工，1:n 2.联系2：业务员和用户申请，1:n 3.联系3：用户和用户申请，1:n 4.联系4：策划员和策划任务，n:m 5.联系5：策划任务和用户申请，1:1 或（联系5：部门和主管，1:1）【问题2】 a.职位，部门号 b.用户号，银行账号 c.预算费用，业务员（员工号） d.要求完成时间，主管号【问题3】用户申请：主键：申请号外键：用户号，业务员策划任务：主键：申请号外键：申请号，主管号【问题4】不正确 All-key关系模型的所有属性组成该关系模式的候选码，称为全码。即所有属性当作一个码。若关系中只有一个候选码，且这个候选码中包含全部属性，则该候选码为全码。实际完成时间和用户评价为非主属性。

解析与纠错

一对多联系将引用字段放在多端：员工补职位、部门号；用户补用户号、银行账号；用户申请补预算费用和受理业务员；任务补要求完成时间与制定任务的主管号。业务员、主管最终引用的是员工的身份，仍需额外业务约束保证职位及所属部门合适。

五个联系按平台可取部门—员工、业务员—用户申请、用户—用户申请的1:n，策划员—任务的m:n，以及任务—申请的1:1。平台还允许第五个写部门—主管的1:1。原图已有主管、策划任务、用户申请的“制定”三元联系；补图时保留它，说明每个已建立任务对应其申请。题意并未要求未受理申请也必有任务，1:1是最大对应数量，不能据此增加强制参与条件。

用户申请以申请号为主键，用户号和业务员为外键；任务以申请号为主键，它同时引用用户申请，主管号引用员工。主键和外键可以是同一属性，不应因为是主键就排除它作为外键的作用。

按题中每位策划员对同一任务记录一次执行的粒度，执行的标识为(申请号，策划员)，实际完成时间和用户评价是该次执行的描述。因此全体属性不是最小候选码，不能称为全码。若另行扩展为同一人多次执行同一任务，应增加执行编号或轮次，不能把扩展条件冒充原题。原页截图已核实六行关系模式的字段和空位均没有下划线，按原样保留。

2017年上半年 · 第 2 题：公寓租赁的数据库设计¶

展开原题（先作答，再查看解析）

公寓租赁的数据库设计

房屋租赁公司拟用系统管理自有房屋、租客及员工，数据库需求如下。

公司拥有多幢公寓楼，每楼有唯一楼编号和地址。楼内有多套公寓，公寓号只在本楼内唯一，不同楼可重号；每套记录卧室数、卫生间数。
员工编号、租客编号分别唯一标识员工和租客。
租客记录姓名、多个联系电话、一个用于自动扣租的银行账号，以及一位紧急联系人的姓名、电话。
员工记录姓名、一个联系电话、月工资。类别可为经理、维修工，也可兼任。经理可管理多楼，每楼必须由一个经理管理；维修工需记录水暖维修、电工、木工等业务技能。
租赁须签合同，一份合同通常由一个或多个合租租客与该楼经理签订；一位租客也可租多套公寓。合同记录签订日期、开始时间、租期、押金和月租金。

未完成的实体联系图如图2-1。

逻辑结构设计给出以下关系模式，保留原字段与空位顺序：

联系电话（电话号码，租客编号）租客（租客编号，姓名，银行账号，联系人姓名，联系人电话）员工（员工编号，姓名，联系电话，类别，月工资，（a））公寓楼（（b），地址，经理编号）公寓（楼编号，公寓号，卧室数，卫生间数）合同（合同编号，租客编号，楼编号，公寓号，经理编号，签订日期，起始日期，租期，（c），押金）

【问题1】（4.5分）为图2-1的“签约”补充关联实体及联系类型。

【问题2】（4.5分）填写逻辑结构中的（a）、（b）、（c）。

【问题3】（6分）租期内公寓设施发生故障，租客在系统登记故障描述，系统为每项故障生成唯一故障编号；公司派维修工处理，系统记录每次维修日期、维修内容。补充图2-1，并把所补ER图内容转换为一个关系模式，写出该模式。

答案与解析

平台参考答案（原文保留）

问题1

问题2

（a）业务技能

（b）楼编号

（c）月租金

问题3

新增维修关系，维修工维修公寓，关系模式为维修情况。维修情况（故障编号，租客编号，楼编号，公寓号，员工编号，维修日期，维修内容）

或者：

解析与纠错

公寓由(楼编号，公寓号)共同识别，不能只用公寓号。经理—公寓楼为1:n，每楼必须恰有一名经理；经理和维修工可由同一员工兼任，不能将类别解释成互斥二选一。租客多个电话号码独立放在联系电话关系中。

平台图把租客—公寓的“租赁”聚集为整体，再由经理以1:n“签约”连接：一个经理可对应多项租赁，具体租赁归相应楼经理负责。题干还允许多人合租；若落地实现，应区分合同主体及合同租客明细，不能一面用合同编号单独作每一行的唯一键，一面要求同一合同的多个租客各占一行。这里保留给定关系模式及平台聚集图，未把额外设计要求塞进原空。

平台维修关系漏了题目明确要求的“故障描述”。同一故障也可能发生多次维修，故障编号本身不足以区分每次记录；题目没有保证一天只能修一次，不能无条件以(故障编号，维修日期)作键。若按一条维修记录对应一位维修工的粒度，可整理为：维修情况(维修记录编号，故障编号，故障描述，租客编号，楼编号，公寓号，员工编号，维修日期，维修内容)。新增维修记录编号是补全建模建议，用于区分维修事件，原平台答案仍按原文保留。当前关系模式未显示下划线，不自行补加。

2016年下半年 · 第 2 题：宾馆预订与入住的数据库设计¶

展开原题（先作答，再查看解析）

宾馆预订与入住的数据库设计

宾馆拟建设客房管理及预订系统，以利用客房资源、满足不同客户需求。需求如下。

有多个部门，部门记录部门号、部门名称、电话、经理。每部门可有多名员工，每员工仅属一个部门；每部门恰有一名经理，负责本部门。
员工记录员工号、姓名、岗位、电话、工资；员工号唯一标识元组，岗位包括经理、业务员。
客房记录客房号（如1301、1302）、客房类型、收费标准、入住状态（已入住／未入住）；客房号唯一，不同客房类型的收费标准不同。
客户记录客户号、单位名称、联系人、联系电话、联系地址；客户号唯一标识元组。
预订需提交申请，记录申请号、客户号、入住时间、入住天数、客房类型、客房数量；申请号唯一。一位客户可有多份申请，每份仅对应一位客户。
入住时业务员据申请安排客房。安排记录客房号、姓名、性别、身份证号、入住时间、天数、电话；客房号、身份证号、入住时间共同唯一标识一次安排。一位业务员可安排多份申请，每份申请只由一位业务员安排，并可安排多间同类型客房。

图2-1为初步实体联系图。

给定关系模式如下，字段、空位及顺序保留：

部门（部门号，部门名称，经理，电话）

员工（员工号，

（a）

，姓名，岗位，电话，工资）

客户（

（b）

，联系人，联系电话，联系地址）

客房（客房号，客房类型，收费标准，入住状态）

预订申请（

（c）

，入住时间，天数，客房类型，客房数量）

安排（申请号，客房号，姓名，性别，

（d）

，天数，电话，业务员）

【问题1】（4分）补充四个联系完善图2-1，可命名为联系1～联系4；联系类型采用1:1、1:n、m:n，也可用1:1、1:*、*:*。

【问题2】（8分）

补全关系模式中的（a）～（d）。
写出“预订申请”“安排”的主键和外键。

【问题3】（3分）“客房”关系是否存在规范性问题？用100字以内解释；若有问题，说明如何修改该关系。

答案与解析

平台参考答案（原文保留）

【问题1】

1、经理与部门之间存在1:1的联系。

2、部门与员工之间存在1:n的联系。

3、客户与预订申请之间存在 1:n的联系。

4、业务员、客房、预订申请之间存在1:m:n的联系。

【问题2】

（a）部门号。

（b）客户号、单位名称。

（c）申请号、客户号。

（d）身份证号、入住时间。

”预订申请“关系模式中的主键是申请号，外键是客户号。

”安排“关系模式中的主键是：（客房号、身份证号、入住时间），外键是：申请号、客房号、业务员。

【问题3】

根据试题中的描述，客房信息中客房号是唯一标识客房关系的一个元组，即可以作为唯一的主键。在客房关系模式中，不存在其他部分依赖关系，但客房号→类型→收费标准，存在传递函数依赖，所以冗余，添加异常，修改异常，删除异常均存在。

可以对客房关系进行分解，具体如下：

客房1（客房号，客房类型，入住状态）；

客房2（客房类型，收费标准）。

解析与纠错

部门—员工为1:n，经理—部门为1:1，客户—预订申请为1:n。安排连接业务员、客房、预订申请，平台以1:m:n三元联系表达；还要按文字保证同一份申请由同一业务员负责，三元图上的多重性不能代替全部业务约束。

(a)放部门号，作为多端员工对部门的引用；(b)补客户号、单位名称；©补申请号、客户号；(d)补身份证号、入住时间。预订申请主键是申请号，客户号为外键。安排按题中明确粒度以(客房号，身份证号，入住时间)为主键，申请号、客房号、业务员为外键；业务员引用员工号，岗位资格需另行约束。姓名和电话只是描述信息，不加入题已给定的组合键。

按题意收费标准由客房类型决定，客房号→客房类型→收费标准，形成非主属性对键的传递依赖。单属性键不存在部分依赖，但这不能保证达到3NF。分为客房1(客房号，客房类型，入住状态)和客房2(客房类型，收费标准)，公共属性客房类型是客房2的键，分解无损且保留相关依赖。

问题3的100字内答法：存在传递依赖“客房号→客房类型→收费标准”，可能造成重复及更新异常。分为客房1(客房号，客房类型，入住状态)与客房2(客房类型，收费标准)。

关系模式中的四处下划线只标示待填空位，不将推导键值补标进原题。

补充说明

平台解析另附的同一联系补全图，原样保留：

2016年上半年 · 第 2 题：网购与实体店配送的数据库设计¶

展开原题（先作答，再查看解析）

网购与实体店配送的数据库设计

一家销售公司现以商城实体店销售为主，拟增加网络销售并建设信息化管理系统。数据库需求如下（共15分）。

记录所有员工的工号、身份证号、姓名、性别、出生日期、电话；每人只登记一部电话。
记录所有商品的商品名称、生产厂家、销售价格、商品介绍；系统用商品条码唯一区别每种商品。
记录所有顾客的姓名、身份证号、登录名、登录密码、电话号码；每位顾客只提供一个电话号码，系统生成唯一顾客编号。
顾客登录后可在网上商城选购，将商品放入虚拟购物车长期保存；在购物车选择商品、修改数量后生成网购订单。顾客从系统备选第三方支付平台中选择电子支付，成功后记录唯一支付凭证编号，再按订单线下配送。
配送商品统一从仓库出库。每位顾客可登记多组收货地址、收货人和联系电话。一份订单可含多个商品，由多名分拣员依商品所在仓库信息分拣，再交配送员按配送单地址配送。
同时记录实体店每笔销售的营业员、顾客、所售商品及数量。

概念模型如下，图尚未补全。

给定逻辑关系模式如下，字段、空位及顺序保留：

根据概念模型设计阶段完成的实体联系图，得出如下关系模式（不完整）：员工（工号，身份证号，姓名，性别，出生日期，电话）商品（商品条码，商品名称，生产厂家，销售价格，商品介绍，（a））顾客（顾客编号，姓名，身份证号，登录名，登录密码，电话）收货地点（收货ID，顾客编号，收货地址，收货人，联系电话）购物车（顾客编号，商品条码，商品数量）订单（订单ID，顾客编号，商品条码，商品数量，（b））分拣（分拣ID，分拣员工号，（c），分拣时间）配送（配送ID，分拣ID，配送员工号，收货ID，配送时间，签收时间，签收快照）销售（销售ID，营业员工号，顾客编号，商品条码，商品数量）

【问题1】（4分）补充图中“配送”联系关联的对象及联系类型。

【问题2】（6分）补全关系模式（a）、（b）、（c）。

【问题3】（5分）若实体店增加送货上门，由营业员按销售结果在系统下订单，并与网购订单统一管理后续业务，应怎样补图并修改订单关系模式？

答案与解析

平台参考答案（原文保留）

【问题1】

补充内容如图中虚线所示：

【问题2】

（a）所在仓库

（b）支付凭证

（c）订单ID，商品条码

【问题3】

补充内容如图中虚线所示：

关系模式：订单（订单ID，顾客编号（FK），商品条码（FK），商品数量，销售ID（FK），支付凭证）。

注：用FK标注外键。

解析与纠错

“配送”联系的对象包括配送员、收货地点以及一次分拣活动；平台将分拣员—分拣—订单聚合为一个可参与新联系的整体，再与配送员、地点连接。答案图三端都标为多，保留该图的表达，不把分拣活动误作商品实体，也不把配送限定为只连接订单和配送员。

平台解析把“一个商品只存放一个仓库”当作推导依据，但需求文字并未明确规定；题给商品表只留一个所在仓库属性，答案实际采用了这一简化。若业务允许同一商品分布多个仓库，则需另建商品—仓库存储关系，不能把该限制说成已明确给定。

问题3将营业员—销售—商品—顾客的销售活动聚合，按平台图与订单建立1:1联系，并在订单关系加入销售ID外键。原网购关联及配送补全仍保留。新增销售关联的1:1是一次销售与其配送订单的业务对应，不等于每个网购订单都必须关联实体店销售；网购场景的该外键如何允许空值需另作实现约定。

题目已说明一份订单可含多个商品，给定关系又把商品条码、数量放在订单中，因而不能无条件宣称每行都由订单ID单独唯一标识。实际规范化设计通常分订单头和明细；这里按原模式填空，不暗改原关系结构或擅自补主键下划线。

原站可见页面已核实：九行关系模式的字段和（a）（b）（c）空位均无下划线，按原样保留；不将推导出的主键标注补入题面。

2015年上半年 · 第 2 题：足球联赛的信息模型¶

展开原题（先作答，再查看解析）

足球联赛的信息模型

某省拟为每年的足球联赛建设信息管理系统，管理球队、球员、主教练、主裁判与比赛。

球队信息：球队编号、名称、成立时间、人数、主场地址、球队主教练。
球员信息：姓名、身份证号、出生日期、身高、家庭住址。
主教练信息：姓名、身份证号、出生日期、资格证书号、级别。
主裁判信息：姓名、身份证号、出生日期、资格证书号、获取证书时间、级别。

每队有一名主教练和若干球员；每名主教练只能受聘于一队，每名球员只能效力于一队。各队有唯一的主场场地，场地不能共用。联赛采取主客场循环制，每周一轮，同轮全部比赛同时进行。

每场比赛恰有两队，分别作为主队、客队，且只能有一名主裁判；每场有唯一比赛编码，记录比分和日期。图2-1为尚未完成的实体联系图。

由概念设计得到的关系模式尚有空缺：

球队（球队编号，名称，成立时间，人数，主场地址）
球员（姓名，身份证号，出生日期，身高，家庭住址，（1））
主教练（姓名，身份证号，出生日期，资格证书号，级别，（2））
主裁判（姓名，身份证号，出生日期，资格证书号，获取证书时间，级别）
比赛（比赛编码，主队编号#，客队编号#，主裁判身份证号#，比分，日期）

【问题1】（6分）补出图2-1的联系和联系类型；列出“比赛”联系应有的属性。

【问题2】（4分）补全关系模式中的（1）～（2）。

【问题3】（5分）新增赞助商，记录名称和编号。赞助商可赞助球队：一队只能有一个赞助商，一个赞助商可赞助多队；也可单独赞助球员，一名球员可为多个赞助商代言。画出新增或修改的实体联系及联系类型。

答案与解析

平台参考答案（原文保留）

【问题1】

比赛联系应具有的属性包括：比赛编码，比分，日期。

【问题2】

（1）球队编号# （2）球队编号#

【问题3】

解析与纠错

球队与球员的“效力”为1对多：球员端为多，球队端为1。球队与主教练的“聘任”为1对1。“比赛”同时连接两个不同角色的球队以及主裁判：一场由一支主队、一支客队和一名主裁判参加，各队和裁判可以参与多场比赛。比赛自身记录比赛编码、比分、日期。

两处填空均为球队编号#。球员表的外键表达所属球队；主教练表的球队编号除了引用球队，还应有唯一性约束，才能体现一队最多聘用一名主教练。若要求每队必须有一名主教练，还需检查反向存在约束。

新增赞助商后，赞助商→球队为1对多；赞助商与球员为多对多。后者可另建包含赞助商编号、球员身份证号的关联表，不能让球队的单一赞助商约束覆盖球员的个人代言关系。

补充说明

订正与约束：原解析末句把球员个人代言的多对多关系写成“球队和赞助商”，应为“球员和赞助商”。球队与赞助商仍是多对一。图中多重联系描述整个联赛期间可发生多次关联，不应理解为一场比赛可以有多名主裁判。

比赛编码区分具体场次；不能只用主队、客队、裁判三者作为场次标识。同轮比赛同时举行意味着同一裁判或球队不能同时参与多场，主客队也不能相同；主场唯一且不共用需结合球队与地址约束落实，这些规则不单靠外键就能全部表达。

原题关系模式中，球队编号、三类人员各自的身份证号、比赛编码均带下划线；两处待填空也带下划线。填空下划线用于标示位置，不能据此把补入的球队编号与身份证号直接当作联合主键；球队归属与主教练唯一性仍须分别约束。

来源与整理说明¶

本篇依据希赛《2026 版本软件设计师考试精讲班视频教程讲义电子版》中“【软件设计】数据库设计”的四篇课件整理。

课件	提取与对应内容
课程内容提要	Web Clipper 遗漏了短列表；四项提要已根据原课件页面的可访问性文本核对补全
数据库设计过程	Web Clipper 正文；设计阶段、E-R 建模、约束、转换、范式，8 张原图
答题技巧	Web Clipper 正文；联系、属性、主外键与答题步骤
实战演练	Web Clipper 正文；完整宾馆案例、三个问题与原参考答案，2 张原图

网页导航和账号杂项已移除，表述、层级与排版已整理。10 张图片已下载到本地并逐图核对，原图保留；来源 URL、所属课件、尺寸和 SHA-256 记录在 image-sources.json。正文中的推导、范式精确定义及实现注意事项均为补充，原参考答案中的笔误明确保留并更正。

数据库设计案例：E-R 建模、关系转换与宾馆案例¶

一、数据库设计过程：区分各阶段的产物¶

二、E-R 联系：先固定对象，再判断数量¶

两个不同实体集之间的联系¶

三元联系：固定另外两端¶

同一实体集内部的联系¶

三、扩充 E-R 模型：弱实体、特殊化与聚集¶

弱实体¶

特殊化¶

聚集¶

四、完整性约束与 E-R 模型转关系模式¶

三类完整性约束¶

实体与二元联系的转换¶

五、规范化：先写依赖，再判断范式¶

独立推导例：从库存业务得到三个关系¶

六、答题步骤与关键词¶

七、完整案例：宾馆信息管理系统¶

原题说明¶

原题关系模式¶

问题 1（4 分）：补全四个联系¶

补充推导与纠错¶

问题 2（8 分）：补属性并确定主外键¶

补充推导¶

问题 3（3 分）：客房关系是否规范¶

补充推导与纠错¶

历年大题练习¶

2024年下半年 · 第 4 题：铁路货运订单数据库的概念与逻辑设计¶

2024年上半年 · 第 4 题：球队、球员与球迷数据库设计¶

2023年下半年 · 第 1 题：汽车维修子系统的关系与实体联系设计¶

2023年上半年 · 第 2 题：汽车零件采购与门店销售¶

2022年下半年 · 第 2 题：分公司与专卖店的数据库设计¶

2022年上半年 · 第 2 题：疫苗接种与检测记录¶

2021年下半年 · 第 2 题：汽车维修系统的数据库设计¶

2021年上半年 · 第 2 题：社区蔬菜团购的数据库设计¶

2020年 · 第 2 题：分公司与职员信息的数据库设计¶

2019年下半年 · 第 2 题：新员工培训的数据库设计¶

2019年上半年 · 第 2 题：创业项目投资的数据库设计¶

2018年下半年 · 第 2 题：分公司部门与任职历史的数据库设计¶

2018年上半年 · 第 2 题：海外代购与顾客地址的数据库设计¶

2017年下半年 · 第 2 题：会议策划业务的数据库设计¶

2017年上半年 · 第 2 题：公寓租赁的数据库设计¶

2016年下半年 · 第 2 题：宾馆预订与入住的数据库设计¶

2016年上半年 · 第 2 题：网购与实体店配送的数据库设计¶

2015年上半年 · 第 2 题：足球联赛的信息模型¶

来源与整理说明¶

评论