数据库范式，我的理解就是一些定义数据库的规范。有1-5范式，但一般来说都是符合前三范式基本就可以了。

第一范式：百度百科原话是：所谓第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项。

我的理解是，每一个列的数据应该都有唯一的值，即对每一行数据来说，我们将他看成是一个实体，每一列即对应该实体的每一个属性，那么这个属性应该只有一个值，例如，性别，男，女，还有其他，但是对应每个实体来说，这个属性的值应该是唯一的，即只能是男，或者是女，或者是其他，不能既是男又是女。再举个例子，也是别人举过的例子，假如一个实例的一个属性是联系方式，但是联系方式有固话和手机，我们就必须把固话和手机分开，分成两个属性，否则就联系方式这个属性来说，是可以对应两个实例的。

第二范式：非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）（百度百科）

我的理解是：设置其他属性对于主键的完全依赖，什么是完全依赖，就是当主键确定了，那么其他属性也就唯一确定了，所以此范式必须依赖于第一范式。这个范式我认为就是对于主键的一个规定，他规定你每一张表必须有一个主键。

第三范式：

在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）

第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。（百度百科）。

我认为第三范式的规定极大的消除了数据的冗余。第三范式必须依赖于第二范式，为什么呢，首先第三范式说任何非主属性不依赖于其他非主属性，例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。这个其实就是百度百科的例子，我觉得他已经描述的很清楚了，但是并不是说你只想在员工表中添加部门名称，但是添加了部门编号（即用部门编号代替部门名称），虽然也符合第三范式，但是无疑增加了查询的时间。因为你还需要关联部门表才能查询到对应的部门名称。

bcnf范式：它构建在第三范式的基础上，如果关系模型R是第一范式，且每个属性都不传递依赖于R的候选键，那么称R为BCNF的模式。

我的理解是，假设你在满足第一范式的基础上，满足第二范式时，发现有不只唯一一个列满足第二范式，那么你就需要对表格进行拆分。也就是同一张表中，有不只一列可以当主键，则这种表格的形式就不符合bcnf的形式。也就是说主键是唯一确定的。

第四范式：我的理解是，表中只许有一个多值依赖。这篇博客讲的第四范式我认为很清楚，所以可以看一下。

https://blog.csdn.net/dove_knowledge/article/details/71434960

第五范式：从最终结构重新建立原始结构

我认为这所有的范式都是为了数据库在使用过程中，不会出现异常，并且降低数据冗余，提高查询速度，因此并非一定要按照这几条范式一条一条去对应，而是根据自己的实际需求，去定义一个好的数据表，所以需要大量练习和实践。

（以上仅是我本人的一些拙见，如果认为有不对的地方，请评论区指正，谢谢！！）