三大范式
第一范式（1NF）
如果我们在数据库中建立一张员工表emp(id, name, age, dept)，对于前三个属性都是基本类型，不可再分，而对于第四个属性dept，它在程序中其实对应于结构体，为复合属性，因此，按照第一范式正确的建表方式应该是将复合属性拆分为多个原子不可分的基本属性，即emp(id，name，age，dept_id，dept_name，dept_detail)。
第二范式（2NF）
第二范式是指在满足第一范式的情况下，关系表R中的所有非主属性都完全依赖于R的每一个候选关键属性。这句话怎么理解呢，这里还是举个栗子： 假如有一个学生课程表student_course(学号, 姓名, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为只有这两个属性一起才能决定一条记录，即(学号, 课程名称) → (姓名, 成绩, 学分) ，这个关系表便不符合第二范式，因为"姓名"仅依赖于"学号"，"学分"仅依赖于"课程名"，因此，不满足第二范式条件。那么，不满足第二范式会有什么问题呢？如下：
-
数据冗余 对于一门课程，如果有n名学生选修，则这门课程的全部信息将会重复存储n-1次，同理，一个学生选修了m门课程，则学生全部信息会重复存储m-1次，导致数据冗余存储。
-
更新问题 如果要更新某门课程的学分，那么所有关联这门课程的记录都将更新，否则会出现数据不一致问题。
-
插入问题 假如新增一门课程，但是尚未有学生选修，则该门课程的信息无法入库。
-
删除问题 假如某门课程对应的记录完全被删除，则将导致这门课程的信息完全丢失。
那我们可以按照第二范式来改造上述关系表，将表才分成student(学号，姓名)，cource(课程名称，学分)，student_cource(学号， 课程名称， 成绩)，这样便避免了上述问题。
第三范式（3NF）
第三范式是指，在满足第二范式的前提下，关系表R中的所有非主属性由主键直接决定，不存在间接依赖关系，简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。 如表emp(id，name，age，dept_id，dept_name，dept_detail)，这张表中的员工id能够决定所有非主属性，单我们发现dept_name，dept_detail这两个非主属性也可以由非主属性dept_id决定，而dept_id又依赖于id，因此存在间接传递依赖，不满足第三范式。同时，可以看出，不满足第三范式的问题是存在大量的冗余数据，解决该问题的方式很简单，只需将原关系表拆分为emp(id，name，age， dept_id)， dept(dept_id，dept_name, dept_detail)，这样不管是对于表emp还是表dept，各自的非主属性都直接依赖于主键，满足第三范式，同时也解决了数据冗余的问题
