数据库设计范式

这是转载的。

对第二范式的理解：

第二范式主要规范联合主键情况：要求非主键字段不能由符合主键的一个完全决定，而必须由符合主键共同决定！只要没有使用联合主键，肯定不会出现违反第二范式的情况！

例：学生选课表的设计应该如何实现？
假设选课关系表为学号、姓名、年龄、课程名称、成绩、学分。
那么这个表里面的主键应该为学号和课程名称联合作为主键，这是毫无疑问的，但是不符合第二范式：因为姓名
可以由学号完全决定，和课程名称没有任何关系，也就是说姓名这个非主键字段对这个联合主键有部分依赖关系存在。
同理，学分完全由课程名称来决定，也是部分依赖的。
成绩是不存在部分依赖的，是由学号和课程名称共同决定的
所以这个表是不满足第二范式的，危害如下：
1 数据冗余
2 更新异常，若调整了课程的学分，那么每条记录都要调整
3 删除异常，假如要删一个学生，那么他选的课也跟着丢了，要是这门课没有别人选的话，该课程的信息就永远的丢失了
4 插入异常，假如新来了一门课程，但是没有人选，试问这怎么插入呢？没办法弄……
  
解决不满足第二范式情况的办法是分解主键
建立学生表（学号，姓名，年龄）课程表（课程名称、学分）和选课关系（学号，课程名称，成绩）
一般认为，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字
满足第二范式的设计肯定满足第一范式的要求！

问题：那么使用了组合主键是否就一定是违反了第二范式？

第三范式：

要求不存在非关键字段对任一候选关键字段的传递函数依赖关系，其实，就是不能出现非主键字段决定其他非主键字段！
关键字段决定了非关键字段x，而x又决定了另外一个非关键字段y，这就不满足第三范式！
假设须生关系表（学号，姓名，年龄，所在班级，教室编号，班级人数）
主键是学号
学号确定了其余的字段，但是呢，所在班级直接决定了教室编号和班级人数，这就是典型的传递依赖，不满足第三范式
解决方法：
分解实体：学生（学号，姓名，年龄，所在班级）
学院（班级，地点，人数）
两者之间用主外键关系联系起来，二者是一对多的关系。