关系型数据库理论——范式的分类与判断
一、数据库设计的目标（从合理组织数据加以存储的角度）：
1）.数据的冗余度小；
SRE实战 互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。2）.共享性高；
解决方法：
对模式进行分解，分解成一组关系模式，每一关系模式对应一个基本表；使用时，将多个关系模式进行自然连接，构成完整的关系模式。
二、关系模式存在哪些问题呢？
以描述学校的数据库为例，属性如下：
学生的学号（sno）、所在系（sdept）、系主任名字（dname）、课程名（cname）、成绩（grade）；
关系模式 Student （sno, sdept, dname, cname, grade）;
语义：一个系有若干学生，一个学生只属于一个系；
一个系只有一个主任；
一个学生可以选修多门课程，一门课程有若干学生选修；
每个学生选修的每门课程都有一个成绩；
1）数据冗余度大；
例中：每一个系主任的名字重复出现；
2）插入异常（即：该插的数据无法插入到表中）；
例中：如果一个系刚成立，尚无学生，我们就无法将该系及系主任信息存如数据库；
3）删除异常（即：不该删除的对象，不得不删）；
例中：如果某个系的学生都毕业了，在删除该系学生信息时，把这个系及系主任信息也删除了；
4）更新/修改异常；
例中：某系更换系主任后，需要修改与该系学生有关的每一个元组；
总结：student关系模式不是一个“好”的模式，由于模式中某些属性之间存在依赖关系，需要通过分解关系模式来消除其中不合适的依赖；
三、那么分解关系模式遵循什么样的要求呢？
——规范化：定义一组关系模式应该符合的要求（范式）；这样的关系模式就不存在某些操作异常，且减少了数据冗余；
范式的分类：（要求越来越严格）1NF——> 2NF ——> 3NF——> BCNF ——> 4NF
1NF ： 如果一个关系模式 R 的每个属性都是不可再分的基本数据项，那么称 R 为一范式；
2NF： 在 R 属于一范式的基础上，满足每一个非主属性都完全依赖于 R 的候选码，那么称 R 为二范式；
3NF： 在 R 属于二范式的基础上，满足不含非主属性对候选码的传递依赖，那么称 R 为三范式；【即，消除了非主属性的传递依赖】
BCNF： 在 R 属于三范式的基础上，满足每一函数依赖的决定因素都包含候选码，那么称 R 为 BC范式；【即，消除了主属性的传递依赖和部分依赖】
总结：即使关系模式达到BCNF，消除了主属性对码的部分依赖和传递依赖，在函数依赖的范畴类解决了数据插入异常和删除异常，但仍可能存在数据冗余和更新异常；
4NF： 在 R 属于BCNF的基础上，对每一个出现的非平凡的多值依赖K→→A，K→→B，分表。【即，消除多值依赖，只允许函数依赖】
四、补充：多值依赖
多值依赖是属性之间的一对多关系，记为K→→A；
平凡的多值依赖：全集U=K+A，一个K可以对应于多个A，即K→→A。此时整个表就是一组一对多关系。
非平凡的多值依赖：全集U=K+A+B，一个K可以对应于多个A，也可以对应于多个B，A与B互相独立，即K→→A，K→→B。整个表有多组一对多关系。
例：关系模式WSC(W,S,C)，W表示仓库，S表示保管员，C表示商品
假设每个仓库有若干个保管员，有若干个商品；每个保管员保管所在的仓库的多个商品；每个商品会被多个保管员保管。这张表满足W→→S且W→→C。这就是非平凡的多值依赖。
欢迎交流与指正！*~* *~*
