对数据库中的123范式的理解

关系数据库中的函数依赖。
定义如下：一个属性集的全集U，设R(U)是属性集U上的关系模式。X,Y是U的子集。若对于R(U)的所有具体关系r都满足如下约束：对于X的每一个具体值，Y有唯一的具体值与之对应，则称Y函数依赖于X，或X函数决定Y，记作X->Y，X称作决定因素。
其实这个看起来就很像数学上的映射，如果一个输入X在一个函数F的作用下的输出在值域中有唯一的值，则它们可以用一个函数来建立关系，要注意函数和方程是不同的概念。
但还是有些相似这样的话
（1）在关系模式中，如果属性X与Y有1：1联系时，则存在函数依赖X->Y,Y->X，即X<->Y。
（2）如果属性Y与X有1：n的联系时，则只存在函数依赖X–>Y。
（3）如果属性X与Y有m:n的联系时，则X与Y之间不存在任何函数依赖关系。

传递函数依赖：
如果存在非平凡函数依赖X->Y,Y->Z，而Y !->X，则成Z传递依赖于X，比如：读者号->姓名，姓名->单位
那么读者号->单位属于传递函数依赖。

PS：数据库说的某某依赖于某某，“依赖”的具体含义是是否相关，比如A依赖于B（A->B），具体含义即A是否和B存在相关的关系，使得A可以通过B的引导来获得，如果B不存在的话，A也是不存在的。在具体一点就是非主属性依赖于主属性，如果主属性不存在的话，那么对应的非主属性也不存在。
如下表：
主码为(book_no,book_name,book_author)
其他非主属性都依赖于主码，如果在查询的过程中，下表中的元组中的主码的值不存在，那么对应的非主属性的值也是不存在的，因为非主属性依赖于主码而存在，主码不存在，非主属性自然也不存在。

第一范式：在关系模式R（U）中的每一个具体关系中，如果每个属性值都是不可再分的最小数据单位，则称R(U)时第一范式的关系，记为R(U)∈1NF。

第一范式简明意义：表中的列（属性字段）是原子的，不可在细分成一个以上的列。
比如，举例一个例子，一个表学生：(姓名，年级，专业)
在实际场景中一个学生可能会出现双专业的情况，主修专业和辅修专业。因此
，在例子中的场景的表的属性专业不具有原子性，需要继续把专业这个属性细化拆分
如：学生（姓名，年级，主修专业，辅修专业）。这样就符合1NF的要求了。当我们明确了设计的场景时，判断是否满足1NF很直观。

第二范式：如果关系模式R(U)中的所有非主属性都完全函数依赖于主码，则称R(U)时第二范式的关系，即为R∈2NF。

PS：主码是一组属性的集合，主码能唯一的标识一个元组，候选码也是一组属性的集合，主码是候选码的子集。
第二范式简明意义：关系需要满足1NF，一个表必须要有一个主码（主键），没有包含在主码里面的属性必须依赖于完全依赖于主码，而不能只依赖于主码的一部分或者不依赖。

比如一个学生成绩表：学生成绩（学号，课程号，成绩，学生名字），主码为（学号，课程号）。因为只通过学号就能唯一的确定一个学生的姓名，所以非主属性学生名字不完全依赖于主码。同时一个学生对应多个课程，比如n个课程，那么学生名字就会存储n次这种重复的存储造成数据冗余，没有意义。

我们可以把学生名字拆出来
学生成绩(学号，课程号，成绩)
学生（学号，学生名字）

第三范式：关系模式R(U)中的所有非主属性对主码不存在传递函数依赖，则称R(U)是第三范式的关系，即为R∈3NF。
简明意义：先要满足2NF，参考上面的传递函数依赖解释，就是一个非主属性对主码的依赖，不能是间接的依赖而是要直接依赖。

比如:学生表(学号，姓名，学院编号，学院名称)，学号是主码，姓名，学员编号，学院，学院名称都完全依赖于学号，满足2NF要求，但是存在非主属性，学院名称->学院编号->学号的关系，学院名称不是直接依赖于学号的，而学院编号又不是主码的属性。

我们需要把学院名称取出来单独成表
学生（学号，姓名，学院编号）
学院（学号，学院名称）

从上面看，一二三范式是层层递进的,并非是独立的关系，满足第三范式的前提要满足第二范式，范式有助于减少数据冗余，数据异常等问题，还有更高级的范式这里就不说了。2NF和3NF很容易搅浑，但是只要注意特点就可以区分，2NF关注的是非主属性是不是完全依赖于主码，3NF关注的是是否非主属性直接依赖于主码，而不是经过非主属性传递的方式依赖于主码。