数据库的各个范式

备注：此文偏专业术语，不易理解，佶屈聱牙，晦涩难懂，新总结了一篇，链接如下 数据库范式2

数据库范式是为了设计出高效、规范的数据库而总结出的一些规则和标准，主要用于消除数据冗余、提高数据的一致性和完整性。

第一范式（1NF）

• 定义：数据库表中的每一列（属性）都是不可再分的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
• 示例：在一个学生信息表中，“联系方式”列不能同时包含多个电话号码，而应该将电话号码拆分成“手机号码”和“家庭电话”等不同的列。

第二范式（2NF）

• 定义：在满足第一范式的基础上，要求表中的每一个非主属性完全依赖于主键，而不能只依赖于主键的一部分。如果一个关系模式R是1NF，并且每一个非主属性都完全函数依赖于R的码，则R属于2NF。
• 示例：在一个订单明细表中，主键是（订单编号，商品编号），如果存在“商品名称”这个非主属性，它只依赖于“商品编号”，而不是整个主键，就不满足第二范式。应该将商品相关信息单独提取到一个商品表中，通过商品编号与订单明细表关联。

第三范式（3NF）

• 定义：在满足第二范式的基础上，要求表中的每一个非主属性都不传递依赖于主键。也就是说，非主属性之间不能存在函数依赖关系。如果关系模式R是2NF，且每个非主属性都不传递函数依赖于R的候选码，则R属于3NF。
• 示例：在一个员工信息表中，有员工编号、部门编号、部门名称等字段。员工编号是主键，部门名称依赖于部门编号，而部门编号又依赖于员工编号，这就存在传递依赖。应该将部门信息单独提取到一个部门表中，通过部门编号与员工信息表关联。

BC范式（BCNF）

• 定义：在满足第三范式的基础上，对于关系模式R中的每一个函数依赖X→Y（Y不属于X），X都必须包含候选码。也就是说，每一个决定因素都包含码。
• 示例：在一个仓库管理系统中，有仓库编号、管理员编号、货物编号等字段。假设一个仓库只有一个管理员，一个管理员可以管理多个仓库，一个仓库可以存放多种货物。存在函数依赖（仓库编号→管理员编号）和（管理员编号，货物编号→仓库编号），这里（管理员编号，货物编号）是候选码，但决定因素“仓库编号”不包含码，不满足BCNF。可以将仓库和管理员的关系单独提取到一个表中，以满足BCNF。

第四范式（4NF）

• 定义：关系模式R满足BCNF，且对于R的每个非平凡多值依赖X→→Y（Y不属于X），X都含有码，则R属于4NF。它主要用于处理多值依赖问题，消除表中的多值依赖关系，使数据更加规范化。
• 示例：在一个学校课程管理系统中，有学生、课程和教师三个实体。一个学生可以选多门课程，一门课程可以有多个教师授课，一个教师可以教多门课程。如果将这些信息放在一个表中，就会存在多值依赖。例如，学生A选了课程C1，课程C1有教师T1和T2授课，那么就会出现（学生A，课程C1）→→教师T1和（学生A，课程C1）→→教师T2这样的多值依赖。可以将其拆分成两个表，一个是学生选课表（学生，课程），另一个是课程教师表（课程，教师），以满足第四范式。

第五范式（5NF）

• 定义：也称为投影连接范式（PJNF），是在第四范式的基础上，要求关系模式R中的每一个连接依赖都由R的候选码所蕴含。它是一种更高级的范式，用于处理非常复杂的关系模式中的数据依赖问题。
• 示例：假设存在一个关系模式R（A，B，C，D），其中存在连接依赖JD（AB，BC，CD），即关系R可以通过投影到AB、BC和CD三个子模式上，然后再通过自然连接恢复到原关系R。如果关系模式R满足5NF，那么这个连接依赖必须是由R的候选码所蕴含的。如果不满足，就需要进一步分解关系模式，以消除连接依赖对数据操作的不良影响。

一般在实际的数据库设计中，通常会满足第三范式或BC范式就可以了，能够保证数据库的高效性和数据的完整性。更高的范式虽然可以进一步消除数据冗余，但可能会导致数据库设计过于复杂，增加查询和维护的成本。