前言

数据库三大范式，是后端人员设计表要遵守的最基本准则。（现实中，时间换空间，可能会做数据冗余，没有遵守部分准则，但是只有在理解这个三大范式基础上，才能艺高人胆大的去做这类处理，否则会把数据库弄的一团糟）
很多书和博客上的专业术语让人不知所云。这里用通俗的语言介绍下，可能不太准确，权当辅助理解那些专业术语。

第一范式

1.确保每列的原子性
2.如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF。

简单的说，第一范式就是每一个属性（每一列）都不可再分的。

第二范式

1.在第一范式的基础上，确保每列和主键相关
2.若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于R的码，则R∈2NF

首先，要符合第一范式。
有的表，可能是联合主键（多个列构成一个主键），这时其他的非主键列，必须完全依赖于全部主键，不是依赖部分主键。
比如：一个表（学生id,课程id,课程姓名），这里联合主键（学生id，课程id），这里的‘课程姓名’就是不遵守第二范式的，因为他只是依赖部分主键（课程id）。换个角度想，一个课程有多个学生选择，就是在这个表，某一个课程的名字会出现多次，应该只用课程id,新建一个课程表，记录（课程id，课程名）

如果表的主键只有一列属性，则非主键列依赖主键列即可

第三范式

1. 在第二范式的基础上，确保每列都和主键直接相关，而不是间接相关
   2.关系模式R 中若不存在这样的码X、属性组Y及非主属性Z, 使得Z→Y，Y→X，成立，则称R ∈ 3NF。

首先，满足第一范式，第二范式
第三范式是为了消除数据库中关键字之间的依赖关系
比如表（用户id[主键]、角色id、角色职责），这里角色id依赖用户id,角色职责依赖角色id,造成了传递依赖，所以不符合第三范式