学的时候就知道是一堆公式。
实际中在设计表的时候可能会用到。
前提是关系型数据库，比如mysql。
（实际中oracle比mysql更好用。但是他收费啊。）

第一范式：每个属性都是原子的（需要做到每个属性都是不可分割的。）

如上。建表的话，还需要把联系方式分成三列去保存，保证每个属性都是原子的。

不满足第一范式，mysql都无法建表。所以第一范式不需要太多关注。

第二范式：满足第一范式基础上，非主属性必须完全依赖于主属性。即主键的整体才能确定一个非主属性。

非主属性是指不构成主键的那些列。

跟着我的思路来，

假设我设计的 管理学生信息表结构如下，
(学号，课程号，成绩，姓名， 老师，老师职称)。主键加粗。
分析一下

1. 成绩是完全依赖于主属性（即学号+课程号，可以确定一个人一门课的成绩）

2. 姓名可以直接通过学号来确定，不用课程号就行了。不满足非主属性必须完全依赖于主属性。

不满足第二范式了有啥坏处呢？

新生入学了。你会发现无法新增内容。因为学生还没有选课，自然没有课程号。

我们按照第二范式，消除非主属性部分依赖主属性的情况。就把姓名提出来，新建一张表。两张表如下

1.选课表(学号，课程号，成绩， 老师，老师职称)
2.学生表（学号，姓名）。

学生表就一个主属性，天然满足第二范式。

第三范式：满足第二范式基础上，且消除对主属性的传递依赖。

选课表中，能决定教师职称并不是通过学号+课程号来确定的，而是先确定了老师才知道教师职称。

我们称教师职称是传递依赖于（学号，课程号）。

有什么坏处呢？

1.老师职称改变了，要修改很多条数据
2.新来老师还没有定教哪门课，教师职称不知该保存到什么地方。（插入异常）

按照第三范式，消除传递依赖的非主属性。最终得到表结构如下

选课表（学号，课程号，成绩，教师）
教师表（教师，教师职称）
学生表（学号，姓名）

BCNF:第三范式基础上，

BCNF与第三范式的不同之处在于：第三范式中不允许非主属性被另一个非主属性决定，但第三范式允许主属性被非主属性决定；而在BCNF中，任何属性（包括非主属性和主属性）都不能被非主属性所决定。
实际上，我们存表，一般都是用id做主键。假如这样设计表：
选课表（学号，课程号，成绩，教师,id）满足第三范式，却不满足BCNF。
因为id可以决定非主属性和主属性了。
所以直接把id作为主属性就满足BCNF了。