数据库设计范式的理解

第一范式

描述单个属性自己要达到什么样的规范
单个属性自己应该具有原子性，不可再拆分。

第二范式

描述非主属性与主属性之间的关系
非主属性必须完全依赖与主键

违反第二范式的例子

在表 成绩表（课程ID，课程名称，学生ID，学生姓名，成绩） 中，
主键为（课程ID，学生ID），但是学生姓名这一非主属性只依赖于部分主键即学生ID，所以违反第二范式。课程名称同理，只依赖于部分主键即课程ID。
为满足第二范式，将课程表拆成成绩表（课程ID，学生ID，成绩）；课程（课程ID，课程名称）；学生（学生ID，学生姓名）

第三范式

描述非主属性之间的关系
非主属性之间不可以有依赖关系

违反第三范式的例子

在表课程（课程ID，课程名称，任课老师ID，任课老师姓名）中，主键为（课程ID），非主属性任课老师姓名依赖于非主属性任课老师ID，违反第三范式。
为满足第三范式，可将表拆成课程（课程ID，课程名称，任课老师ID）；教师（教师ID，教师姓名）

巴斯·科德范式

描述主属性之间的关系
主属性之间不可以有依赖关系

违反巴斯·科德范式的例子

在表借阅表（读者ID，读者身份证，书本ID，借阅起始日期）中主属性读者身份证与读者ID存在依赖关系，违反巴斯·科德范式。
为满足巴斯·科德范式，将借阅表拆成借阅表（读者ID，书本ID，借阅起始日期）；读者信息（读者ID，读者身份证）
ps: 这个例子不太完美，因为一般图书馆不会记录个人的身份证信息

第四范式

不可以存在非平凡的多值依赖
非平凡的多值依赖：
表R0(K,VA,VB)中一个K对应多个VA，一个K对应多个VB，且VA与VB相互独立
这时候可以将表R0拆分为R1(K, VA)和表R2(K, VB)

违反第四范式的例子

在表课程（课程ID，任课教师ID，学生ID）中存在多值依赖，一个课程可能有多个教师，很可能有多个学生。
为满足第四范式，将课程表拆成课程-任课教师表（课程ID，教师ID）；课程-学生表（课程ID，学生ID）