第一范式 1NF：属性不能再被拆分。
- 人(身份证号, 姓名, 性别, 联系方式) 不满足 1NF
- 因为联系方式包含了电话号码、电子邮箱、微信、QQ 等
- 人(身份证号, 姓名, 性别, 电话号码) 满足 1NF
第二范式 2NF：不存在非主属性对主键的部分函数依赖关系。
- R(A, B, C, D, E) 的主键是 (A, B)，存在函数依赖关系 { A,B → C, B → D, C → E }
- R 不满足 2NF，因为存在部分函数依赖 B → D
- 使用手段把 B → D 干掉，变成 { A,B → C, C → E } 就满足了
你可能注意到 C → E，E 居然和主键没有关系，这是可以存在的吗？！答案是在 2NF 中是允许的，2NF 管不到那么宽，它只在乎与主键有关的函数依赖关系。
第三范式 3NF：不存在非主属性对主键的传递函数依赖关系。
- 在上述例子中，我们已经得到了 { A,B → C, C → E }
- 但 { A,B → C, C → E } 是不满足 3NF 的
- 因为存在 A,B → C → E，即 E 对主键有传递函数依赖
- 使用手段把 C → E 干掉，变成 { A,B → C } 就满足了
BCNF：非主属性依赖的对象一定是主键，且不能是部分函数依赖！
个人感觉 BCNF 不是一二三范式那样一路升级来的，按照定义来讲，其实 BCNF 只需要基于 第一范式。但是，你也可以在第三范式的基础上再满足 BCNF 以此来提高数据库的规范化。
- 2NF 不关心与主键无关的函数依赖关系
- 而 BCNF 关心所有的函数依赖关系
- 它要求所有函数依赖关系的箭头左侧一定是主键
- { A,B → C, C → E } 满足 2NF 但不满足 BCNF
- 除非改为 { A,B → C, A,B → E }
因此 BCNF 更像是 2NF 的升级版，它不仅禁止部分函数依赖，而且还要求所有函数依赖都满足这个关系。
如有错误，请指正！
纯纯是大学生为了准备考试罢了！