主要考点
- 相关名词
- 关系数据库模式
- 关系的三种类型
- 关系的完整性约束
拿上面举例子
数据库核心概念：学生-课程详解
一、先明确图一的核心逻辑
图一是学生 - 选课 - 课程的 ER 实体联系模型：
- 矩形代表实体：「学生」和「课程」是两个核心实体
- 菱形代表实体间的联系：「选课」是学生和课程之间的联系
- 连线两端的
*代表多对多关系：一个学生可以选多门课程，一门课程可以被多个学生选择
下面结合这个场景，逐个拆解图二的 10 个数据库核心概念，做到定义 + 场景实例一一对应，清晰易懂。
二、逐个概念结合场景讲解
1. 关系
定义：在关系数据库中，实体以及实体间的联系都是用关系来表示的，类似于程序设计语言中变量的概念。 场景讲解： 关系数据库里，你看到的每一张二维数据表，就是一个「关系」。 对应这个场景，我们需要 3 个关系（3 张表）：
- 学生实体 → 对应「学生表」这个关系，用来存所有学生的信息
- 课程实体 → 对应「课程表」这个关系，用来存所有课程的信息
- 选课联系 → 对应「选课表」这个关系，用来存学生选课程的关联数据
2. 关系模式
定义：是对关系的描述，类似于程序设计语言中类型定义的概念。 场景讲解： 关系是装数据的表，关系模式就是这张表的表结构定义，固定不变，描述了 “这张表叫什么、有哪些列”。 对应场景的 3 个关系模式：
- 学生关系模式：
学生(学号, 姓名, 性别, 年龄, 班级) - 课程关系模式：
课程(课程号, 课程名, 学分, 任课老师) - 选课关系模式：
选课(学号, 课程号, 成绩)
3. 关系模型
定义：是由若干个关系模式组成的集合。 场景讲解： 把上面 3 个描述学生选课业务的关系模式，整合在一起，就是一个完整的学生选课关系模型。 简单说，关系模型就是一整套业务里，所有表的结构定义的合集，完整描述了业务里所有实体、实体间联系的结构。
4. 属性
定义：用来描述某一个事物的特征。 场景讲解： 对应到表里，就是表的列（字段） ，用来描述实体 / 联系的特征。
- 学生实体的属性：学号、姓名、性别、年龄、班级
- 课程实体的属性：课程号、课程名、学分、任课老师
- 选课联系的属性：成绩
5. 域
定义：每个属性的取值范围所对应一个值的集合。 场景讲解： 就是每个属性（列）的合法取值范围，超出这个范围的数据不能存入。
- 「性别」属性的域：
{男,女}，只能在这两个值里选 - 「年龄」属性的域：
10~40的整数（符合大学生的合理范围） - 「成绩」属性的域：
0~100的整数 - 「学号」属性的域：
10位数字组成的字符串（符合学校学号规则）
6. 候选码
定义：若关系中的某一属性或属性组的值能唯一标识一个元组（表中的一行记录），则称该属性或属性组为候选码。 场景讲解： 能唯一确定表里一行数据的字段 / 字段组合，一个关系可以有多个候选码。
- 学生表：学号是候选码，每个学生的学号唯一，知道学号就能唯一确定一个学生；如果没有重名，「姓名」也可以是候选码。
- 课程表：课程号是候选码，能唯一确定一门课程。
- 选课表：单独的学号 / 课程号都无法唯一标识一行（一个学生选多门课、一门课被多个学生选，都会重复），因此学号 + 课程号这个属性组合，是候选码，能唯一确定一条选课记录。
7. 主码（主键）
定义：又称为主键，若一个关系有多个候选码，则选定其中一个为主码。 场景讲解： 从候选码里选一个，作为表的唯一标识，每张表必须有且只有一个主码，用来保证表里的每一行记录不重复。
- 学生表：选学号作为主码
- 课程表：选课程号作为主码
- 选课表：候选码只有「学号 + 课程号」，因此这个属性组就是主码
8. 主属性
定义：包含在任何一个候选码中的各个属性称为主属性。 场景讲解： 只要这个字段出现在了任意一个候选码里，它就是主属性。
- 学生表：学号在候选码里，学号是主属性
- 课程表：课程号在候选码里，课程号是主属性
- 选课表：学号、课程号都在候选码里，学号、课程号都是主属性
9. 非主属性
定义：不包含在任何候选码中的属性称为非主属性。 场景讲解： 除了主属性，剩下的所有字段都是非主属性。
- 学生表：姓名、性别、年龄、班级，都不在候选码里，都是非主属性
- 课程表：课程名、学分、任课老师，都不在候选码里，都是非主属性
- 选课表：成绩，不在候选码里，是非主属性
10. 外码（外键）
定义：如果关系模式 R 中的属性或属性组非该关系的码，但它是其他关系的码，那么该属性集对关系模式 R 而言是外码。 场景讲解： 外码是用来关联多张表的核心，对应这个场景，最典型的就是选课表：
- 选课表里的学号：不是选课表的主码，但它是学生表的主码，因此「学号」对选课表来说，就是外码
- 选课表里的课程号：不是选课表的主码，但它是课程表的主码，因此「课程号」对选课表来说，也是外码
通过这两个外码，就把学生表、选课表、课程表关联起来，完美实现了图一中「学生 - 选课 - 课程」的多对多业务逻辑。
相关名称
学生数据库核心术语解析与衔接
我们继续沿用之前的学生选课业务场景，结合图中的Student学生表实例，逐个拆解这 6 个数据库核心名词，做到定义 + 实例一一对应，和之前的知识点连贯衔接。
11. 全码
定义：关系模型的所有属性组是这个关系模式的候选码，称为全码。 通俗讲解 + 实例： 全码是候选码的特殊情况 —— 当一张内外，单独任何一个属性、甚至任意几个属性组合，都不能唯一标识一行数据，必须把表里所有属性合在一起，才能唯一确定一条记录时，这个由全部属性组成的候选码，就叫全码。
举个贴合场景的例子： 比如我们新增一张「学生 - 竞赛 - 获奖」表，关系模式为：竞赛获奖(学号, 竞赛名称, 获奖等级)。
- 一个学生可以参加多个竞赛，单独「学号」不能唯一确定一行；
- 一个竞赛有多个学生获奖，单独「竞赛名称」不能唯一确定一行；
- 同一个竞赛同一个获奖等级有多个学生，单独「获奖等级」也不能唯一确定一行；
- 甚至「学号 + 竞赛名称」也不行（一个学生可以在同一个竞赛里拿多个奖项）；
- 只有学号 + 竞赛名称 + 获奖等级三个属性全部合在一起，才能唯一确定一条获奖记录。 此时这个关系的候选码包含了全部属性，它就是全码。
补充：图中的学生表不是全码，因为单独「学号」就能作为候选码，不需要所有属性组合。
12. 元组 / 记录：行
定义：关系（二维表）中的每一行完整数据，就是一个元组，也叫一条记录，对应现实世界里一个具体的实体实例、一条具体的业务数据。 结合图中实例讲解：
- 图里第一行
100101 张军生 通信 男，就是 1 个元组（1 条记录），对应「学号 100101 的张军生」这个具体的学生实体； - 图里标注的元组 1~ 元组 6，就是这张学生表里的 6 条完整记录，也就是 6 个元组。
和之前知识点的衔接：我们之前说「候选码能唯一标识一个元组」，意思就是通过主码（比如学号 100101），就能精准定位到表里对应的这一行元组。
13. 字段、数据项
定义：就是关系（二维表）中的每一列，和我们之前讲的「属性」是完全等价的概念 —— 只是数据库理论里叫「属性」，实际开发、数据库操作中，更常用「字段 / 数据项」这个叫法。 结合图中实例讲解：
- 图里的
Sno(学号)、Sname(姓名)、SD(院系)、Sex(性别)，这 4 列，每一列都是一个字段 / 数据项，对应一个属性； - 每个单元格里的具体值（比如 Sno 列的 100101），就是这个字段的一个数据项值。
14. 元数：属性的个数（列数）
定义：一个关系（二维表）里，包含的属性（列 / 字段）的总数量，就叫这个关系的元数，也叫 “度”。 结合图中实例讲解：
- 这张学生表有 Sno、Sname、SD、Sex 一共 4 个属性（4 列），所以这个关系的元数是 4；
- 再举之前的例子：选课表 (学号，课程号，成绩) 有 3 个属性，它的元数就是 3。
补充：元数是由表结构决定的，表结构不修改（不加列 / 减列），元数就不会变化。
15. 基数：记录的个数（行数）
定义：一个关系（二维表）里，包含的元组（行 / 记录）的总数量，就叫这个关系的基数，用来描述表里一共有多少条业务数据。 结合图中实例讲解：
- 这张学生表里一共有 6 行数据（元组 1~ 元组 6），所以这个关系的基数是 6；
- 基数会随着数据操作动态变化：比如新增 1 个学生，基数就变成 7；删除 1 个学生，基数就变成 5。
16. n 元关系：元数为几，就是几元关系
定义：这个概念和元数直接绑定，一个关系的元数是 n，我们就称它为n 元关系。 结合实例讲解：
- 图里的学生表元数是 4，所以它是一个4 元关系；
- 之前的选课表 (学号，课程号，成绩) 元数是 3，就是 3 元关系；
- 哪怕是只有 1 列学号的表，元数是 1，也叫 1 元关系。
图中内容对应关系总结（一眼看懂）
| 图中表的组成 | 对应关系模式术语 | 对应通用开发术语 |
|---|---|---|
| 每一列（Sno/Sname 等） | 属性 | 字段、数据项 |
整个表的结构Student(Sno,Sname,SD,Sex) | 关系模式 | 记录类型、表结构 |
| 每一行数据 | 元组 | 记录 |
| 列的总数量（4 列） | 元数 | 字段数 |
| 行的总数量（6 行） | 基数 | 记录数 |
| 元数为 4 | 4 元关系 | 4 列表 |
