数据库三范式
：数据库三范式是指关系型数据库设计中的三种规范化设计原则，旨在减少数据冗余、提高数据一致性和可维护性。
第一范式：规定表中的每一列都应该是不可分割的最小单元。
为什么要这样实现呢？
：举个栗子，大家可能都用过淘宝，京东，在填写收件地址的时候，是不是都要逐一填写 ：省、市、区、详细地址。以上其实就是数据库中的某个字段。这就是第一范式的具体应用，如果某一天，政府下了批文，修改了某个区的名字，这样就可以直接在该字段上修改即可。如果全部都写到一起的话，修改就比较麻烦，可能会涉及正则表达式。
第二范式：是在满足第一范式的基础上，规定表中的非主键列不存在对主键的部分依赖。
在满足第一范式的基础上，表中不存在部分依赖，非主键列要完全依赖于主键。(主要是说在联合主键的情况下，非主键列不能只依赖于主键的一部分)
如下学生成绩表(score)：
stu_id(学生id)、course_id(课程id)、score(分数)、course_name(课程名)
primary key(stu_id, course_id)
| stu_id | course_id | score | course_name |
|---|---|---|---|
| 001 | 1011 | 88 | 高数3-1 |
| 001 | 1022 | 69 | 计算机组成原理 |
| 002 | 1011 | 92 | 高数3-1 |
表中主键为stu_id和course_id组成的联合主键。满足1NF；非主键列score完全依赖于主键，stu_id和course_id两个值才能决定score的值；而course_name只依赖于course_id，与stu_id没有依赖关系，它不完全依赖于主键，只依赖于主键的一部分，不符合2NF。
修改使表满足2NF后：
成绩表(score) primary key(stu_id)
| stu_id | course_id | score |
|---|---|---|
| 001 | 1011 | 88 |
| 001 | 1022 | 69 |
| 002 | 1011 | 92 |
课程表(kc) primary key(course_id)
| course_id | course_name |
|---|---|
| 1011 | 高数3-1 |
| 1022 | 计算机组成原理 |
将原来的成绩表(score)拆分为成绩表(score)和课程表(kc)，而且两个表都符合2NF。
第三范式是在满足第一范式和第二范式的基础上，规定表中的列不存在对非主键列的传递依赖。
传递依赖关系指的是：指的是在一个关系（表）中，一个非主键列依赖于另一个非主键列，而那个被依赖的列本身依赖于主键。
该表中，订单编号为主键，顾客名称依赖于顾客编号，这就是对非主键列的传递依赖。
修改之后应该如下：