2NF和3NF都强调非主属性对主属性的依赖关系，2N针对完全依赖，3NF针对直接依赖，都是为了保持表的原子性。


学生选课表，包含的属性有学号、姓名、课程名称、分数、系别和系主任，可拆分成以下表：

1. 学生表：学号、姓名
2. 课程表：课程号、课程名称
3. 系别表：系别、系主任
4. 学生-课程表：学号、课程号、分数
5. 学生-系别表：学号、系别

拆分之前，“姓名”违反了2NF，“系主任”违反了3NF。

我所理解的第二范式和第三范式的不同：

1、首先第三范式是第二范式的更进一步（要求更严格），要想满足第三范式首先要满足第二范式。

2、而什么情况下能够满足第二范式呢？候选码能确定一条记录的所有信息。以老师文中的例子来对照：知道球员的编号是可以知道球员信息的，但是比赛编号、比赛时间是无法来通过球员信息来确定的。这张表需要两个候选码（球员编号、比赛编号）才能确定一条记录的信息。类似于这样的关系我们称为「部分依赖」,消除后才能算「第二范式」。

3、第三范式的核心 —— 消除传递依赖。老师文中的图已经画的很清晰了，A->B,B->C,A->C，类似于这样依靠中间人串起的关系我们称之为「传递依赖」

学生选课表我的修改：

学生信息表：学号、姓名、系别编号

课程信息表：课程编号、课程名称

课程成绩表：学号、课程编号、分数

系别信息表：系别编号、系别名称、系主任

作业：
3NF区别于2NF是在于：字段非主属性不直接依赖主属性，而是通过依赖于其他非主属性而传递到主属性，解决办法就是让依赖非主属性的字段与依赖字段独立成表

拆分1
学生选课表，包含的属性有学号、姓名、课程名称、分数、系别和系主任
- 姓名和系别都是依赖于学号
- 系主任依赖系别
- 系主任间接依赖学号
院系表：系别（主键） 系主任
学生表：学号 姓名 课程名称 分数 系别
拆分2
学生表，包含的属性有学号 姓名 课程名称 分数 系别
选课那就会有课程表
- 课程名称依赖于学号
- 分数依赖于课程名称和学号
学生表：学号（主键） 姓名 系别（外键）
课程表：课程名称 学号 分数     //主键（课程名称，学号）

啰哩巴嗦的扯一大堆。
姓名，年龄分开就是一范
加个id 就二范
加个foreign key 就三范
三降二 通过冗余字断提效率性能，取了个装x 的名字叫反范式。
其它的范式，没事别管，不论是开发效率，还是查询效率都很感人。
需要时google 下

有两个问题没懂 麻烦老师解答下 。
1. 文中 所谓完全依赖不同于部分依赖，也就是不能仅依赖候选键的一部分属性，而必须依赖全部属性。
候选键的属性 为什么还有 一部分或者全部 ？不就是一个属性吗？
2. 如果按1说的 全部依赖了 那么还会有出现3NF的间接依赖吗 间接依赖还算是全部依赖吗？

经过一番分析，得出以下的判断

1、学生的学号决定了系别（普遍情况），系别的又决定了系主任，所以不满足第三范式
解决方式：将系单独设为一个表，包括（系别，系主任）
 
2、学生还因为选课所以才和课程有了关系，所以选课其实是学生和课程共同产生的一个关系，也就是说，本来选课是不存在的！
 解决方式：所以选课又是一张表（学号，课程号，分数）主键是学号和课程号（复合主键）

最终的结果：
学生表(学号，姓名) 主键：学号

课程表(课程号,课程名) 主键：课程号

选课表（学号，课程号，分数） 主键：学号，课程号

系表（系编号，系别，系主任） 主键：系编号

表述可能略有不足，能力有限，还请多多包涵，多多指正！