三范式建表

第一范式

每个字段是可确立含义的，对于数据库表设计时候，当一个字段有着多重含义，说明拆分是不准确的，
如下图实例：

这种是设计人员最常见接收到的数据调研的数据格式，这里我们需要将其拆分符合数据库的第一范式，在设计数据库表时最少是符合第一范式的。但这并不是设计数据库表结构的最优解。符合数据库的第一范式：
如下：

第二范式

在设计数据表时候，往往数据不会单单一个表格就能搞定的，我们将举例更加的复杂化一下。
如下图：

按照第一范式的处理方式，我们用一张表格来存储，就会大量的冗余数据，且扩展性不高。但是这种设计后端的处理难度是最简单的，甚至可以用代码生成器。
扩展性不高：
如果现在需要优化，课时增加一个属性，选修课和必修课。必修课有额外的老师日常分，选修
课没有分数，只有成绩评级（优，良，及格，不及格）
如果学生是飞行器的学校增加实践分数等等。

函数依赖

要以第二范式进行拆分，需要理解一个概念，函数依赖。具体的定义就不讲了，简单可以理解为业务主键。即当我需要查询一条业务数据时候，业务主键的能帮助找到其对应的一条数据。

学号能确定一条学生数据，我们将这个关系记为：x->y
学号加课程能确定一条成绩数据，这类记为（x1,x2）->y
以此类推

按照上诉的案例我们可以知道，该数据的业务主键是学生姓名（假设名称唯一）加课程信息才能得到对应的成绩。我们将这个业务主键拆分。
结果如下

这时候就完美了嘛？

坑：
按照上面的建表，就默认了一点，一个老师只能一门课。万一我一个老师教20门课。

第三范式

第三范式是第二范式基础上的升级。回到上面一个问题，将表拆分后，老师和课程这方面的拓展依旧显得非常的局限。
举例：现在需要做一个老师选课的功能，老师的数据要从上面表格提取，如果老师改名等等，上面的表格就成了脏数据。

很显然在老师可以教学多门课程这个条件下，又出现了(x1,x2)->y的函数依赖。第三范式要求每个主体都独立的维护，不影响其他数据。按照上面的，当我们老师需要删除一个，将其记录删除，对应的课程就减少了。

中间属性

当我们将老师和课程分开后，有一个属性就变的很尴尬，成绩。将成绩放在老师表还是课程表都不合适。这是一个需要一系列操作产生的数据，老师开课，学生选课，最后产生成绩。
这时候就需要将该属性放在中间中。最终的表设计。

课程表：

学生表：

老师表：

开课表：

选课表：

更加专业知识，定义参考：
https://blog.csdn.net/WHEgqing/article/details/108997240