关系模型与关系代数

一句话定义

关系模型（Relational Model）把数据组织为「关系」——即无序元组（行）的集合，每个关系有确定的属性（列）集合，并用关系代数（选择、投影、连接等集合运算）作为其查询理论。

为什么重要

它是 SQL 与几乎所有主流数据库的理论地基：理解了关系即集合，才能明白为什么 SELECT 结果无序、为什么重复行需要 DISTINCT。
关系代数是查询优化器的「中间语言」：SQL 先被改写为关系代数表达式树，再做等价变换与代价优化（kp-013）。
主键、外键、空值等设计时最常见的争论，根源都在关系模型的形式化定义里。

前置知识

kp-001（了解概念模式与表的关系即可）。集合的基本概念（并、交、差）会在下文随用随释。

核心概念

关系（Relation）：一个元组的集合，对应一张表；关系名即表名。
元组（Tuple）：关系中一行；属性（Attribute）：一列；域（Domain）：属性的取值范围。
候选键（Candidate Key）：能唯一标识元组的最小属性集；被选定的候选键称为主键（Primary Key）。
外键（Foreign Key）：引用另一关系候选键的属性，实现参照完整性。
空值（NULL）：「未知或不适用」，参与比较时结果为 UNKNOWN，是三值逻辑的来源。
关系代数五算子：选择 σ（按条件取行）、投影 π（取列）、并/差/笛卡尔积，由此导出交、连接 ⋈、除法。

原理与机制

关系是集合而非列表：其一，元组无序，ORDER BY 之前的查询结果顺序未定义；其二，集合不含重复元组，SQL 允许重复是工程妥协，因此去重要显式 DISTINCT。选择运算 σ_status='paid'(orders) 对应 WHERE；投影 π_order_id,amount(orders) 对应 SELECT 列清单；连接由笛卡尔积加选择导出：orders ⋈ users 等价于「积后按条件筛选」。空值使谓词从二值变为三值（TRUE/FALSE/UNKNOWN），WHERE 只保留 TRUE 行——这解释了 NOT IN 遇到 NULL 时结果为空的经典陷阱：x NOT IN (1, NULL) 中 x≠1 得 UNKNOWN，永远不会为 TRUE。

实例或案例

用关系代数表达「查询已支付订单的客户姓名」：π_name(σ_status='paid'(orders ⋈ customers))。翻译为 SQL：

SELECT DISTINCT c.name
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
WHERE o.status = 'paid';

注意 JOIN ... ON 是先积后选择，DISTINCT 是因为同名客户可能有多笔订单——每个 SQL 子句都能在关系代数里找到出处。

常见误区

认为表数据有「天然顺序」：没有 ORDER BY 的结果顺序随时可变，分页不排序是常见线上事故。
用 NULL 做等值判断：NULL = NULL 结果是 UNKNOWN 而非 TRUE，判空必须用 IS NULL。
把主键理解为「业务编号」：主键只需在库内唯一且不变，与业务编号是两回事。

自测题

为什么 SELECT * FROM t 的两次执行顺序可能不同？答：关系是集合，元组无序；物理返回顺序取决于扫描路径与并发状态，需要顺序必须显式 ORDER BY。
WHERE col NOT IN (SELECT v FROM s) 当 s 含 NULL 时会发生什么？答：对每个不匹配的 col，比较结果为 UNKNOWN，整体条件永不为 TRUE，查询返回空集，应改用 NOT EXISTS。

公式或模型

连接可由基础算子导出：R ⋈_θ S = σ_θ(R × S)；投影对连接的分配律 π_L(R ⋈ S) = π_L(π_L1(R) ⋈ π_L2(S))（当 L = L1 ∪ L2）是优化器下推投影、减少中间数据的理论依据。

图示

本节不适用：关系模型的「图」就是表格本身，示例中的表结构已足够直观，单独画图不增加信息量。

直观类比

关系像一张精确登记的库存清单：每行是一件物品、每列是一个属性，清单本身没有先后；你要「所有红色且价格低于 100 的物品」，是先按条件挑行（选择）再只抄名称与价格两栏（投影）。

与其他知识点的关系

kp-003、kp-004 把关系代数落到 SQL 语法；kp-006、kp-007 用函数依赖约束关系内容；kp-013 展示优化器如何等价变换关系代数树。

前置知识点

相关知识点