数据库范式
范化是在识别数据库中的数据元素，关系，以及定义所需的表和各个表中的项目这些初始工作之后的一个细化的过程。常见的范式有1NF,2NF,3NF,BCNF,4NF。
-
1NF，即第一范式，是指数据库表的每一列都是不可分割的基本数据项，同一列不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多的关系。第一范式模式要求属性值不可分裂成更小部分，即属性想不能是属性组合或由组属性构成。简而言之，第一范式就是无重复的列。例如，由“职工号”“姓名”“电话号码”组成的表（一个人可能有一个办公电话和一个移动电话），这时将其规范化为1NF可以将电话号码分为“办公电话”和“移动电话”两个属性，即职工（职工号，姓名，办公电话，移动电话）。
- 2NF，即第二范式，实在第一范式的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常为表加上一个列，以存储各个实例的唯一标识。如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R的某个候选键，则称R为第二范式模式。（如果A是关系模式R的候选键的一个属性，则称A是R的主属性，否则称A是R的非主属性。）例如，在选课关系表（学号，课程号，成绩，学分），关键字为组合关键字（学号，课程号），但由于非主属性学分仅依赖于课程号，对关键字（学号，课程号）只是部分依赖，而不是完全依赖，所以，此种方式会导致数据冗余以及更新异常等问题，解决办法是将其分为两个关系模式：学生表（学号，课程号，分数）和课程表（课程号，学分），新关系通过学生表中的外键字课程号联系，在需要时通过两个表的连接来取出数据。
- 3NF，即第三范式，如果关系模式R是第二范式，且每个非主属性都不传递依赖于R的候选键，则称R是第三范式的模式。例如学生表（学号，姓名，课程号，成绩），其中学生姓名无重名，所以，该表有两个候选码（学号，课程号）和（姓名，课程号），则存在函数依赖：学号->姓名，（学号，课程号）->成绩，（姓名，课程号）->成绩，唯一的非主属性成绩对码不存在部分依赖，也不存在传递依赖，所以，属于第三范式。
- BCNF，构建在第三范式的基础之上，如果关系模式R是第一范式，且每个属性都不传递依赖于R的候选键，那么称R为BCNF的模式。假设仓库管理关系表（仓库号，存储物品号，管理员号，数量），满足一个管理员只在一个仓库工作；一个仓库可以存储多个物品。则存在如下关系：
（仓库号，存储物品号）->（管理员号，数量）；
（管理员号，存储物品号）->（仓库号，数量）
所以，（仓库号，存储物品号）和（管理员号，存储物品号）都是仓库管理关系表的候选码，表中的唯一非关键字段为数量，它是符合第三范式的。但是由于存在如下决定关系：
（仓库号）-> （管理员号）
（管理员号）-> （仓库号）
即存在关键字段决定关键字段的情况，所以不符合BCNF范式。把仓库管理关系表分解为二个关系表：仓库管理表（仓库号，管理员号）和仓库表（仓库号，存储物品号，数量），这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。
5. 4NF，即第四范式，设R是一个关系模式，D是R上的多值依赖的集合。如果D中成立非平凡多值依赖X->Y时，X必须是R的超键，那么称R是第四范式的模式。例如，职工表（职工编号，职工孩子姓名，职工选修课程），在这个表中同一职工也可能会有多个职工孩子姓名，同样，同一个职工也可能会有多个职工选修课程，即这里存在着多值事实，不符合第四范式。如果要符合第四范式，只需要将上表分为两个表，使他们有一个多值事实，例如职工表一（职工编号，职工孩子姓名），职工表二（职工编号，职工选修课程），两个表都只有一个多值事实，所以，符合第四范式。
附上一些基本的概念（参考：https://blog.csdn.net/legendaryhaha/article/details/79948061）：