数据库范式

目前可知的有 8 种范式，分别是 1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常数据库设计只要满足第一范式( 1NF )、第二范式( 2NF )、第三范式( 3NF )即可，通常设计关系数据库最多考虑到 BCFN 就可以。

1. 第一范式(1NF)：确保每列保持原子性

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。 强调的是列的含义的不可分割性，每一列都是不可分割的基本数据项。 定义：符合 1NF 的关系中的每个属性都不可再分。（可以把”关系”理解为一张带数据的表，“关系模式”是这张数据表的表结构）。

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。 但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作或分类的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示：

userID	姓名	省份	城市	详细地址
001	小明	广东	深圳	南山区xx路xx号
002	小红	广东	广州	天河区xx路xx号

2. 第二范式(2NF)：确保表中的每列都和主键相关

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关(主要针对联合主键而言)，通过和主键完全相关，确保所有的数据都是同一类相关的数据。 也就是在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。 2NF 在 1NF 的基础之上，消除了非主属性对于码的部分函数依赖。

函数依赖：在一张表中，在属性(或属性组) X 的值确定的情况下，必定能确定属性 Y 的值，那么就可以说Y函数依赖于 X，写作 X → Y。

• 完全函数依赖
• 部分函数依赖
• 传递函数依赖

3. 第三范式(3NF)：确保每列都和主键列直接相关,而不是间接相关

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

第三范式对应表的主外键关系，将间接相关的列数据作为一个新表，外键关联到主表。

符合 3NF 要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。在实际中，出于性能上或者对扩展的需要，经常做到2NF或者1NF。

三范式对应的要求就是：

• 第一范式不可拆分。表的列不可拆分(列的原子性)。
• 第二范式完全函数依赖。非主键列完全依赖于主键。
• 第三范式消除非主属性的传递依赖。传递依赖的属性创建新表，通过外键关联。