对数据库三范式的理解

     最近面试老有人问到数据库设计范式的问题。虽然在学校里也学过，但具体是什么东东早忘得一干二净了，只是在设计数据库的时候不自觉便向三范式靠拢罢了。

     1n：数据库表中的字段都是单一属性的，不能再分。

            就是说属性是不能再分的，或者说一个字段已经不能再分为更多的属性了。有人说当前DBMS中，傻瓜也不能做出不符合第一范式的设计，因为关系数据库中不能把一列分成两列或多列。

     2n：在1n的基础上，数据库表中不存在非关键字段对候选关键字段（组合关键字中的某一个关键字）的部分函数依赖。只能全部依赖于一组关键字的情况，符合第二范式。

            如果是单关键字的话，肯定符合第二范式，第二范式主要说的是符合关键字的情况。

            比如学生学分表：学号，课程名称，课程总学分，实得学分 

            其中存在符合关键字（学号，课程名称），存在的情况是    课程名称--->课程总学分，意思是课程总学分只依赖课程名称，跟学号没关系，就是说部分依赖。会出现的问题是数据冗余，添加异常，更新异常和删除异常。

            要消除部分依赖，就需要把 课程名称和课程总学分单独分出来变为一个表：

             1.课程表：课程编号，课程名称，课程总学分

             2.学生学分表：学号，课程编号，实得学分 

            这样便消除了部分依赖。

     3n: 在2n的基础上，数据库表中不存在非关键字对任一候选关键字的传递依赖，就说明符合第三范式。

            说的比较绕，主要就是说如果有传递依赖了就不行。

            A-->B-->C,如果A是非关键字段，C是候选关键字。那么就说明不符合3n。

            比如员工表：员工，部门，部门人数 ， 其中员工是主键

            因为 部门人数 不是直接依赖于某个员工，但是部门人数是依赖于 部门 字段的，那么就存在了依赖关系，员工-->部门-->部门人数，就不符合3n了。

            会出现的问题也是数据冗余，添加更新删除异常。

            解决的办法是把部门和部门人数单独作为一个表，然后员工表中只出现员工和部门编号。