第五范式（5NF）是关系数据库规范化理论中的高级范式，也被称为投影连接范式（PJ/NF），它的核心目标是消除关系中存在的连接依赖，进一步减少数据冗余，保证数据的一致性。第五范式建立在第四范式（4NF）的基础之上，只有满足第四范式的关系才有可能满足第五范式。
第五范式的定义
如果一个关系模式R满足第四范式，并且R中的每个连接依赖都是R的候选键蕴含的，那么R就属于第五范式。简单来说，就是关系中的所有数据都可以通过候选键的投影连接得到，不存在需要通过非候选键的连接才能推导出的数据依赖。
这里需要先明确连接依赖的概念：如果关系R可以分解为多个子关系R1、R2...Rn，且将这几个子关系自然连接后能够完全还原为原来的关系R，那么就称R存在连接依赖。第五范式要求这种连接依赖必须由候选键来蕴含，也就是连接拆分后的子关系的公共属性必须是原关系的候选键的一部分。
第五范式的判断标准
判断一个关系是否符合第五范式，可以按照以下步骤进行：
- 首先确认该关系已经满足第四范式，不存在非平凡的多值依赖
- 检查关系是否存在非候选键蕴含的连接依赖
- 如果存在非候选键蕴含的连接依赖，说明该关系不符合第五范式，需要进行拆分
- 拆分后的所有子关系，自然连接后必须能够完全还原原关系的所有数据，且每个子关系都满足第五范式
第五范式的应用示例
我们来看一个供应商、零件、项目的业务场景，假设我们有一个关系供应商_零件_项目，存储供应商可以提供哪些零件，以及这些零件可以用于哪些项目，表结构如下：
| 供应商ID | 零件ID | 项目ID |
|---|---|---|
| S001 | P001 | J001 |
| S001 | P001 | J002 |
| S001 | P002 | J001 |
这个关系如果直接存储，会存在连接依赖：我们可以把它拆分为供应商_零件和零件_项目两个子关系，自然连接后可以得到原关系，但这两个子关系的公共属性是零件ID，而零件ID不是原关系的候选键（原关系的候选键是供应商ID、零件ID、项目ID的组合），因此这个关系不符合第五范式。
我们可以将它拆分为三个符合第五范式的关系：
-- 供应商零件关系，候选键为(供应商ID, 零件ID)
CREATE TABLE supplier_part (
supplier_id VARCHAR(20),
part_id VARCHAR(20),
PRIMARY KEY (supplier_id, part_id)
);
-- 供应商项目关系，候选键为(供应商ID, 项目ID)
CREATE TABLE supplier_project (
supplier_id VARCHAR(20),
project_id VARCHAR(20),
PRIMARY KEY (supplier_id, project_id)
);
-- 零件项目关系，候选键为(零件ID, 项目ID)
CREATE TABLE part_project (
part_id VARCHAR(20),
project_id VARCHAR(20),
PRIMARY KEY (part_id, project_id)
);
拆分后的三个关系，每个关系的连接依赖都由自身的候选键蕴含，符合第五范式的要求，同时自然连接这三个关系也可以得到原来的所有数据，没有信息丢失。
第五范式的适用场景
第五范式属于高级范式，在实际的数据库设计中并不需要所有表都达到第五范式，通常适用于以下场景：
- 业务中存在多个实体之间的多对多对多关联关系，且这种关联关系存在复杂的连接依赖
- 对数据一致性要求极高，需要最大程度减少数据冗余的场景
- 数据更新频率较低，但查询时需要频繁进行多表连接的场景，第五范式拆分后可以减少连接时的冗余数据处理
需要注意的是，过度追求第五范式可能会导致表的数量过多，增加查询时的连接成本，因此实际设计中需要结合业务场景平衡规范化和查询性能的关系。
第五范式与前几类范式的区别
第五范式和前几类范式的核心差异在于处理的依赖类型不同：
- 第一范式（1NF）处理的是属性的原子性，要求属性不可再分
- 第二范式（2NF）处理的是部分依赖，要求非主属性完全依赖于候选键
- 第三范式（3NF）处理的是传递依赖，要求非主属性不依赖于其他非主属性
- 第四范式（4NF）处理的是多值依赖，要求消除非平凡的多值依赖
- 第五范式（5NF）处理的是连接依赖，要求所有连接依赖都由候选键蕴含
可以看出，范式等级越高，对数据结构的约束越严格，数据冗余越少，但设计复杂度也会相应提升。