数据库范式与模式分解

什么是一个好的数据库逻辑设计

不会发生插入异常、删除异常、更新异常，数据冗余尽可能的小，原因主要是不合适的数据依赖造成的。

数据依赖包含函数依赖和多值依赖：

        是一个关系内部属性与属性之间的一种约束关系

        通过属性间值的相等与否体现出来的数据间相互联系

        是现实世界属性间相互联系的抽象

        是数据内在的性质

        是语义的体现

关系模式的简化表示

R(U，F)  U上的值根据关系可以映射到F时，r成为关系模式R(U,F)的一个关系

完全函数依赖:多值函数依赖，多个值的真子级（不包含自己）无法在确定Y，则是完全函数依赖 

部分函数依赖：真子集可以确定Y，则为部分函数依赖。

传递函数依赖：sno -> sdept -> Mname（学生 只有一个系，系只有一个系主任）

主键的数学定义：

范式

 第一范式：一个关系模式R的所有属性都是不可分的基本数据项。即表中有表

无法解决部分函数依赖的问题，即非主属性部分依赖于码，必须成绩依赖于学号，宿舍楼管理员依赖于宿舍楼。

引入的问题：

S-L-C(Sno,Sdept,Sloc,Cno,Grade)， Sloc为学生的宿舍楼，并且每个系的学生住在同一个地方。S-L-C的码为(Sno,Cno)。

学生的学号（Sno）

所在系（Sdept）

学生选的宿舍楼（sloc）

课程号（Cno）

成绩（Grade）

​​​​​​​插入异常：因为码都不能为空，当学生没有选课（Cno为null）时，无法插入数据

删除异常：学生不选择某课程时，会删除学生所在的系等信息

冗余度大：选择多个课程时

修改困难：学生转系，则都得修改一遍

 第二范式：若关系模式R满足第一范式，并且每一个非主属性都完全依赖于R的码，则满足第二范式

将上面的问题投影分解之后，可以解决此问题。

无法解决Sloc是Sno和Sdept的直接依赖和传递依赖问题。

 第三范式：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）

性质1：每一个非主属性即不部分函数依赖于候选码，也不传递函数依赖于候选码

性质2：属于3范式，则一定属于二范式

一二三范式解决的是非主属性对于候选码的依赖，必须完全依赖，不能传递依赖，没有解决候选码之间的依赖关系

BC范式：在3NF基础上，任何主属性不能对主键子集依赖（在3NF基础上消除主属性对主码子集的依赖），即主属性之间不能有依赖关系

 关系模式规范化的基本步骤： 

模式分解待学习