主题
第二章 关系数据库基础与关系代数
1. 关系模型的数学基础
关系数据库理论是当今数据库技术的核心基石。自 1970 年 E.F. Codd 在论文 A Relational Model of Data for Large Shared Data Banks 中首次提出关系模型以来，建立在集合论和谓词逻辑上的关系理论体系，已经成为包括 Oracle、MySQL、PostgreSQL 和 SQL Server 在内的几乎所有主流 DBMS 的理论根基。对关系模型数学基础的深入理解，是掌握 SQL 查询优化和数据库设计的必要前提。
1.1 域与笛卡尔积
域 (Domain) 是一组具有相同数据类型的值的集合。例如，整数集合、长度不超过 20 个字符的字符串集合、以及枚举型集合如 {男 女} 都是域。域的作用在于规定某一类属性的合法取值范围。在数据库实现中，域的概念对应于列的数据类型定义，例如 INT、VARCHAR(20) 或 ENUM。
给定一组域
符号含义：
：参与笛卡尔积的第 1 个域。 ：参与笛卡尔积的第 2 个域。 ：参与笛卡尔积的第 个域。 ：来自第 个域 的一个取值。 ：第 个域。 ：下标序号，用来指代第 个对象或第 个分量。 ：题目中的数量、项数、次数或样本量，具体含义见公式前文字。
其中每一个有序组合
域这一概念看似抽象，实际上是在提醒我们：数据库中每一列都不只是“能装某种格式的值”，还承担着限定语义边界的作用。年龄列之所以不能随便写成任意字符串，成绩列之所以应落在合理范围内，本质上都是因为属性值必须来自恰当的域。只要把域理解成“某类属性允许出现的合法值空间”，后续关于类型、约束和完整性的很多要求就会更容易接受。
1.2 关系的形式化定义与基本术语
关系 (Relation) 在数学上是一组域的笛卡尔积的子集。在数据库的物理表现上，一个关系对应一张二维表。由于关系本质上是集合，因此满足集合的基本性质：元组不允许完全重复（由主键保证），元组之间的排列顺序不影响关系的语义，属性列的排列顺序也不影响语义。
与关系相关的基本术语包括：
元组 (Tuple)：关系中的一行，代表一个具体的实体实例。例如在学生表中，一名特定学生的所有信息构成一个元组。
属性 (Attribute)：关系中的一列。每个属性具有一个名称（在同一个关系内不能重名）和一个取值范围（即域）。在数据库实际操作中，属性通常被称为字段或列。
度数 (Degree)：关系中属性的个数。一个包含 5 个属性的关系的度数为 5。
基数 (Cardinality)：关系中元组的个数。基数是动态变化的，会随着数据的插入和删除而改变。
关系模式 (Relation Schema)：是对关系结构的形式化描述，通常记作
关系可以分为三类：基本关系（也称基本表，是实际存储在数据库中的表）、查询结果表（由查询操作产生的临时表）和视图表（由基本表导出的虚拟表，数据库中只存储其定义而不存储实际数据）。
基本关系需要满足以下性质：第一，每一列中的分量来自同一个域，是同一类型的数据。第二，不同列可以来自同一个域，但必须有不同的属性名以示区别。第三，行的顺序无关紧要。第四，列的顺序无关紧要。第五，不允许出现完全相同的两行（由关系的集合性质保证）。第六，每个分量必须是不可再分的原子值（这是第一范式的基本要求）。
这里最容易被忽视的一点，是“关系”虽然在界面上表现为二维表，但它在理论上并不是电子表格。电子表格强调单元格位置、填写顺序和视觉呈现，关系则强调集合语义。集合语义意味着行无序、列无序、同一元组不能重复。只要真正接受这一点，很多后续知识就会自然连起来。例如，为什么没有显式 ORDER BY 时不能依赖结果顺序；为什么投影操作在理论上要去重；为什么集合运算要求两个关系满足并相容条件。这些并不是数据库厂商的人为规定，而是关系模型数学基础的自然结果。
同时还要看到，理论中的关系与工程中的 SQL 结果并不完全重合。关系理论默认结果是集合，而现实 SQL 为了效率和表达便利，经常采用可保留重复行的多重集语义；理论上属性值来自明确域，而 SQL 中还允许 NULL 参与运算。学习关系模型不是为了忽略这些差异，而是为了在面对这些工程折中时，依然知道什么是底层原则，什么是产品层的扩展。
2. 键与完整性约束
关系数据库能够保证数据正确性和一致性的关键在于它定义了一套严密的完整性规则体系。这些规则通过键和约束来具体实施。
2.1 键的分类与层次
超键 (Superkey)：能够唯一标识关系中每个元组的属性集合。超键的定义比较宽泛，它可以包含多余属性。例如在学生表中，（学号）是超键，（学号 姓名）也是超键，因为加入姓名后仍然能唯一标识每个学生。
候选键 (Candidate Key)：不包含多余属性的超键。也就是说，候选键中的任何一个属性被去掉后，剩余的属性集合就不再具有唯一标识元组的能力。候选键是最小的超键。一个关系中可能存在多个候选键。例如在身份证信息表中，身份证号和护照号都可以唯一标识一个人，因此两者都是候选键。
主键 (Primary Key)：从候选键中选定的一个，用于在实际操作中唯一标识元组。每个关系只能指定一个主键。主键的选择通常考虑简洁性和稳定性，例如优先选择单一整数列而非组合列。
替代键 (Alternate Key)：候选键中除主键之外的其他候选键。
外键 (Foreign Key)：关系 R 中的某个属性或属性组合，它不是 R 的主键，但其取值要么为空值，要么等于另一个关系 S 中某个主键的值。外键是实现表与表之间关联的核心机制。外键所在的关系 R 称为参照关系，外键指向的关系 S 称为被参照关系。
主属性：包含在任何一个候选键中的属性称为主属性。非主属性：不包含在任何候选键中的属性称为非主属性。这一对概念在规范化理论中非常重要，是判定关系处于第几范式的关键依据。
2.2 三类完整性约束
实体完整性 (Entity Integrity)：要求主键的每个属性列都不能取空值 NULL。因为主键的作用是唯一标识每个元组，如果允许主键为空，就无法有效区分不同的实体实例。在联合主键的情况下，组成主键的每一个属性列都必须非空。
参照完整性 (Referential Integrity)：要求外键的值必须满足以下条件之一：取空值（前提是该外键列允许空值），或者等于被参照关系中某个实际存在的主键值。当对被参照关系中的主键进行删除或修改操作时，系统通常提供三种处理策略：RESTRICT 策略拒绝执行可能破坏参照完整性的操作；CASCADE 策略级联地删除或修改所有引用该主键的外键行；SET NULL 策略将引用方对应的外键值设置为空值。
用户定义完整性：由具体业务规则所决定的约束条件，反映特定应用领域中数据应满足的语义要求。例如，学生年龄必须大于 0 且小于 150 的 CHECK 约束，或者成绩必须在 0 到 100 之间的范围限制。用户定义完整性既可以通过 CHECK 约束在表定义时声明，也可以通过触发器 (Trigger) 在运行时进行更复杂的校验。
从更深一层看，键和约束并不是“为了写建表语句而设置的语法元素”，而是在回答两个根本问题：系统靠什么认出一个对象，系统靠什么阻止错误事实进入数据库。键负责前者，约束负责后者。若一个实体没有清晰稳定的键，数据库就很难可靠去重、建立引用和追踪责任；若约束缺位，错误虽然暂时能写入，代价却会在查询、统计、审计和人工纠错阶段成倍放大。因此，完整性约束越早下沉到数据库层，越能减少后续由应用层和人工流程兜底的成本。