MySQL三大范式

第一范式(1NF)

数据表的每一列都要保持它的原子特性，也就是列不能再被分割。
数据库

这张表就不符合第一范式规定的原子性，不符合关系型数据库的基本要求，在关系型数据库中建立这个表的操做就不能成功。不得不将数据表设计为以下形式。
函数

第二范式(2NF)

几率：属性必须彻底依赖于主键。
下满这张表不符合第二范式的要求。
性能

缺点设计

• 表中的第一行数据都存储了系名、系主任,数据的冗余太大
• 若是有一个新的系尚未开始找到学生，那么不能讲该系的信息添加到数据表中去，从数据表中看不到该系的存在
• 若是将某个系的学生信息所有删除，那么这个系在数据表里也就不存在了，但这个系还存在。

• 若是某我的要转系，那么为了保证数据库中数据的一致性，须要修改三条记录中系与系主任的数据3d

  依赖

  在数据表中，属性（属性组）X肯定的状况下，能彻底退出来属性Y彻底依赖于X。
  彻底依赖
  彻底依赖是针对于属性组来讲，当一组属性X能推出来Y的时候就说Y彻底依赖于X。
  部分依赖
  一组属性X中的其中一个或几个属性能推出Y就说Y部分依赖于X。
  结论:当一个第一范式的候选码只有一个属性的时候，那它就是第二范式(2NF)blog

  候选码

  当一个属性或者属性组肯定的状况下，这张表的其他全部属性就能肯定下来，这个属性或者属性组就叫作或候选码。
  一张表能够有多个候选码
  通常只选一个候选码做为主键
  从表中找到两个属性：学号和课程
  学号能够推出姓名、系名、系主任。
  课程能够推出成绩。
  将它们两个设置为联合主键
  效率

存在的部分依赖

• 姓名对学号存在部分依赖
• 系名对学号存在部分依赖
• 系主任对学号存在部分依赖
• 这显然不符合第二范式的要求，作出修改：
  

表一中分数彻底依赖于学号和课程的属性
表二中姓名、系名、系主任彻底依赖于学号的属性
第二范式消除了第一范式的部分依赖im

第三范式(3NF)

概念:全部的非主属性不依赖于其余的非主属性
传递函数依赖
设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
在改进后的学生表中：
主属性：学号
非主属性：姓名、系名、系主任
知道系名能够推出系主任，因此非主属性系主任对主属性学号存在传递函数依赖，这不符合非主属性不依赖于其它的非主属性的设计要求。将该数据表改进以下：
数据

第三范式消除了第二范式的传递函数依赖
BC 范式
主属性不能对候选码存在部分函数依赖或者传递函数依赖
关系型数据库

这张表不存在部分函数依赖于传递函数依赖，属于第三范式
表中的依赖关系

• 仓库名—————>管理员
• 管理员—————>仓库名
• 物品名—————>数量

主属性：仓库名、管理员、物品名
非主属性：数量
存在的问题

• 先新添加一个仓库，但还没有存听任何物品，不能够为该仓库指派管理员，由于物品名也是主属性，根据实体完整性的要求，主属性不能为空
• 某仓库被清空后，该仓库的信息也被清空
• 当须要更新仓库管理员，该仓库存放了多少物品，就要修改多少条信息。
  在这个问题中就是存在了主属性对于候选码的部分依赖，也就是仓库名对于管理员和物品名的部分依赖。
  修改成
  仓库（仓库名，管理员）
  库存（仓库名、物品数、数量）

范式的目的

• 减少数据的冗余性
• 提升效率