这是转载的。
对第二范式的理解:
第二范式主要规范联合主键情况:要求非主键字段不能由符合主键的一个完全决定,而必须由符合主键共同决定!只要没有使用联合主键,肯定不会出现违反第二范式的情况!
例:学生选课表的设计应该如何实现?
假设选课关系表为学号、姓名、年龄、课程名称、成绩、学分。
那么这个表里面的主键应该为学号和课程名称联合作为主键,这是毫无疑问的,但是不符合第二范式:因为姓名
可以由学号完全决定,和课程名称没有任何关系,也就是说姓名这个非主键字段对这个联合主键有部分依赖关系存在。
同理,学分完全由课程名称来决定,也是部分依赖的。
成绩是不存在部分依赖的,是由学号和课程名称共同决定的
所以这个表是不满足第二范式的,危害如下:
1 数据冗余
2 更新异常,若调整了课程的学分,那么每条记录都要调整
3 删除异常,假如要删一个学生,那么他选的课也跟着丢了,要是这门课没有别人选的话,该课程的信息就永远的丢失了
4 插入异常,假如新来了一门课程,但是没有人选,试问这怎么插入呢?没办法弄……
解决不满足第二范式情况的办法是分解主键
建立学生表(学号,姓名,年龄)课程表(课程名称、学分)和选课关系(学号,课程名称,成绩)
一般认为,所有单关键字的数据库表都符合第二范式,因为不可能存在组合关键字
满足第二范式的设计肯定满足第一范式的要求!
问题:那么使用了组合主键是否就一定是违反了第二范式?
第三范式:
要求不存在非关键字段对任一候选关键字段的传递函数依赖关系,其实,就是不能出现非主键字段决定其他非主键字段!
关键字段决定了非关键字段x,而x又决定了另外一个非关键字段y,这就不满足第三范式!
假设须生关系表(学号,姓名,年龄,所在班级,教室编号,班级人数)
主键是学号
学号确定了其余的字段,但是呢,所在班级直接决定了教室编号和班级人数,这就是典型的传递依赖,不满足第三范式
解决方法:
分解实体:学生(学号,姓名,年龄,所在班级)
学院(班级,地点,人数)
两者之间用主外键关系联系起来,二者是一对多的关系。