好几个。如果一个主属性，它不能单独做为一个候选码，那么它也不能确定任何一个非主属性。给一个反例：我们考虑一个小学的教务管理系统，学生上课指定一个老师，一本教材，一个教室，一个时间，大家都上课去吧，没有问题。那么数据库怎么设计？（学生上课表）r
学生t课程t老师t老师职称t教材t教室t上课时间r
小明t一年级语文（上）t大宝t副教授t《小学语文1》t101t14：30r
r
一个学生上一门课，一定在特定某个教室。所以有（学生，课程）－教室r
一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）－老师r
一个学生上一门课，他老师的职称可以确定。所以有（学生，课程）－老师职称r
一个学生上一门课，一定是特定某个教材。所以有（学生，课程）－教材r
一个学生上一门课，一定在特定时间。所以有（学生，课程）－上课时间r
因此（学生，课程）是一个码。r
然而，一个课程，一定指定了某个教材，一年级语文肯定用的是《小学语文1》，那么就有课程－教材。（学生，课程）是个码，课程却决定了教材，这就叫做不完全依赖，或者说部分依赖。出现这样的情况，就不满足第二范式！r
有什么不好吗？你可以想想：r
1、校长要新增加一门课程叫“微积分”，教材是《大学数学》，怎么办？学生还没选课，而学生又是主属性，主属性不能空，课程怎么记录呢，教材记到哪呢……郁闷了吧插入异常r
2、下学期没学生学一年级语文（上）了，学一年级语文（下）去了，那么表中将不存在一年级语文（上），也就没了《小学语文1》。这时候，校长问：一年级语文（上）用的什么教材啊？……郁闷了吧删除异常r
3、校长说：一年级语文（上）换教材，换成《大学语文》。有10000个学生选了这么课，改动好大啊！改累死了……郁闷了吧？（修改异常）r
那应该怎么解决呢？投影分解，将一个表分解成两个或若干个表r
学生t课程t老师t老师职称t教室t上课时间r
小明t一年级语文（上）t大宝t副教授t101t14：30r
r
学生上课表新r
课程t教材r
一年级语文（上）t《小学语文1》r
r
课程的表第三范式（3NF）：符合2NF，并且，消除传递依赖r
上面的“学生上课表新”符合2NF，可以这样验证：两个主属性单独使用，不用确定其它四个非主属性的任何一个。但是它有传递依赖！r
在哪呢？问题就出在“老师”和“老师职称”这里。一个老师一定能确定一个老师职称。r
有什么问题吗？想想：r
1、老师升级了，变教授了，要改数据库，表中有N条，改了N次……（修改异常）r
2、没人选这个老师的课了，老师的职称也没了记录……（删r