数据表所遵循的范式是数据库设计所需要满足的规范，数据库的规范化是优化表的结构，把字段表现的数据清晰、明确、简洁，通常把一个数据表分成两个或多个表之间的关系叫做
，表结构遵循第三范式可以帮助我们减少数据的冗余以及减轻更新数据信息的工作量。
目前，总共有有六种范式（第一范式（1NF），第二范式（2NF），第三范式（3NF），BC范式（BCNF），第四范式（4NF），第五范式（5NF））在这些范式中，
事务往往是多面性的，在数据库设计时，遵循三范式也有不方便的地方，比如遵循范式之后，。范式越高，性能越差，一般满足第三范式就能解决我们大部分需求的数据库设计。
下面我们来举例子说第一范式，第二范式，第三范式表设计的合理化
第一范式
定义：第一范式每一个字段都是单一属性，不可再分。
简单的来说：就是每个字段便是一个属性。1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库，只要是关系型数据库，就一定满足第一范式。
下面我来举例子说明是第一范式
| id | 姓名 | 年龄 | 班级 | 性别 |
|---|---|---|---|---|
| 1 | 小红 | 18 | 九年级1班 | 女 |
| 2 | 小明 | 19 | 九年级2班 | 男 |
在上表中，班级字段就不是单一属性，可以分为：年级（九年级），班级（1班）
| id | 姓名 | 年龄 | 年级 | 班级 | 性别 |
|---|---|---|---|---|---|
| 1 | 小红 | 18 | 九年级 | 1班 | 女 |
| 2 | 小明 | 19 | 九年级 | 2班 | 男 |
第二范式
定义：第二范式每一个字段不存在其他字段的函数依赖 [消除部分子函数依赖]。
简单来说：就是一个字段由另外一个字段推导出来的。
下面我们用例子来说明
| id | 姓名 | student_id | 得分 | 水平 |
|---|---|---|---|---|
| 1 | 小红 | 1 | 91 | 优秀 |
| 2 | 小明 | 2 | 79 | 良 |
在这张表中，student_id与姓名中的id是对应关系，所以可以用student_id来推导出姓名，所以就不需要student_id与名字字段有函数依赖关系。在表中字段水平可以由得分的区间来推出是否优秀、良。所以这个得分与水平字段是有函数依赖关系
score表
| id | student_id | 得分 |
|---|---|---|
| 1 | 1 | 91 |
| 2 | 2 | 79 |
student表
| student_id | 姓名 |
|---|---|
| 1 | 小红 |
| 2 | 小明 |
然后用student表与score表连表查询即可获得相同的数据
第三范式
定义：第三范式属于不依赖与其他非主属性 [消除部分传递函数依赖]。
简单的说：就是消除数据量大的时候部分冗余
下面通过例子来解释第三范式
student表
| id | 姓名 | 年龄 | 职务 | 职务编号 |
|---|---|---|---|---|
| 1 | 小红 | 18 | 班长 | 1 |
| 2 | 小明 | 19 | 劳动委员 | 2 |
| 3 | 小丽 | 19 | 课代表 | 3 |
student表
| id | 姓名 | 年龄 | 职务编号 |
|---|---|---|---|
| 1 | 小红 | 18 | 1 |
| 2 | 小明 | 19 | 2 |
| 3 | 小丽 | 19 | 3 |
job表
| id | 职务名称 |
|---|---|
| 1 | 班长 |
| 2 | 劳动委员 |
| 3 | 课代表 |
两表相互关联即可查询到你所要的数据，而且可以避免数据的冗余问题
总结
数据库的范式可以让我们更好的适应项目的不同变化，选择最优的数据库的设计模式，一般遵循第三范式就可以满足更多的数据表设计的优化。不需要在项目后期，重新构建项目的数据库设计了。
