第一范式
规则：数据库中的每一列都是不可再分割的基础数据
举例： 地址这个字段 如果我们业务中只是当一个备注字段 那么做为一个字段也没有什么问题，但如果我们要对地址进行省、市、区做分布分析，那么显然把地址做成一列就违反了第一范式。
第二范式
规则：数据据库中的非主键字段 对任一候选键的所有列 都是完全依赖，不存在部份依赖。
当一个表有多种组合或单个列可以唯一区分行时，则这个组合列或单列就可以称为候选键，主键即是从候选键中选中一种可以唯一区分行的组合。大多数情况下，你可以理解为候选键就是我们表中定义的主键
第二范式主要针对联合主键情况
举例：（学号 课程编号 课程名称 成绩） 这样一个成绩表 显然 主键是(学号，课程编号)组合列， 成绩列是对 (学号，课程编号) 完全依赖 没有问题。但显然课程名称列只依赖来课程编号列就存在了部份依赖，所以这个设计不符合2nf 需要把课程名称列移除
第三范式
规则：表中不存在非主键字段对主键字段的传递依赖
举例：学号 姓名 系名 系主任
系主任与学号是没有直接依赖关系的，是通过系名传递依赖的 所以这个设计符合2nf但不符合3nf
为什么要遵守3nf 是因为 遵守3nf能消除插入异常、修改异常和删除异常。
我们具体来说说这三种异常
1、插入异常： 3nf的例子来说 如果学校决定新增加一个 计算机系 但还没有招生 那这个计算机系就不能录入系统了。
2、修改异常： 3nf的例子来说 如果计算机系 换了一个系主任 则需要修改的行特别多，需要将这个系所有学生的行都需要修改
3、删除异常： 2nf例子来说 假如这门课所有学生都毕业了且新生也没有学生选修。那删除成绩表的时候 就会把这门课也删除了
BCNF
规则： 消除候选键中的列对其它任一候选键的传递依赖或部份依赖
假定 一个教师只会教一门课程，一门课可以有很多老师教且当学生选定某门课，就对应一个固定的教师
举例：学生id 课程id 教师id
那我们可以 确定两个候选键（学生id,课程id）,(学生id，教师id)
但我们发现 一个教师只会教一门课程，那么 教师id就决定了课程id 可以认为课程id依赖于教师id 那么这个表就不符合 bcnf
最近我在面试中会问到面试者对范式的理解，但给我的答案出奇的统一，会用但理论讲不上来。
但我认为 虽然我们在业务设计中 常常会违反范式(最常见的增加冗余字段) 但当我们了解范式。并在此基础上根据业务的需要、BTREE的特性(二级索引 叶子结点存储的是主键数据以及防止页分裂)，冷热分区等理论 才能设计出较好的数据字典