细说数据库范式
作者 佚名技术
来源 数据库编程
浏览
发布时间 2012-03-22
| r→Course，这属于违反BCNF的情况。 可是，问题是这个表看起来还挺正常的啊？！它的毛病在于，我们无法阻止类似最后一行这样的数据插入，而这会导致与前提“一名教师只负责一门课程”违背。所以我们还是需要将它拆分： Student 学生 Teacher 教师 S1 T1 S1 T2 S2 T1 S2 T3 Teacher 教师 Course 课程 T1 C1 T2 C2 T3 C2 这样，在“Teacher-Course”表中，借助主键的帮助，最后可以避免违背“一名教师只负责一门课程”这个前提。 那么，如果没有这样一个前提，是初的设计是否符合BCNF？目前看来是的。 真实的情况可能更为复杂，下面这个更接近于我的一些经历： 1）学生需要学习多门课程 2）一门课程可能有多位教师负责 3）一位教师可能负责多门课程 4）某一班级的某一课程对应的教师是固定的（一位） 据此，为了描述学生、课程、教师三者的关系，从这一团乱麻中最早跳出来的大概是这样的表： Student 学生 Class 班级 Course 课程 Teacher 教师 候选键： {Student,Course} 我们可以明显地看到Student→Class违反了2NF，于是： Student 学生 Class 班级 Class 班级 Course 课程 Teacher 教师 从这两张表，仔细考虑，即便我们通过Class关联两张表，还是无法得出学生与课程的关系（只能得出可供该学生选择的课程），所以我们需要再添加一张表： Student 学生 Course 课程 最后大概是这么三张表，可能还有其它的方案，这里只是举例说明，就不纠缠了。 在BCNF之后，还有4NF，5NF，DKNF，6NF，等什么时候有空了再看看是什么东东。 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
你可能对下面的文章感兴趣
关于细说数据库范式的所有评论
