几句话说清楚数据库的基本范式

第一范式 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 的升级版，它不仅禁止部分函数依赖，而且还要求所有函数依赖都满足这个关系。

---

如有错误，请指正！

纯纯是大学生为了准备考试罢了！