mysql数据库范式

范式

目的

减小数据的冗余性
提高效率

第一范式

属性的原子性,每列不可再分解;
如:出生年月日—>年、月、日 便于后续修改

第二范式

记录的惟一性,说明一个事物;
属性必须完全依赖于主键,不能存在部分依赖
如:说明了三个信息
说明了三个事物:学生信息、系信息、课程信息
存在的部分依赖:姓名对学号存在部分依赖、系名对学号存在部分依赖、系主任对学号存在部分依赖

可能会存在问题:
数据冗余
表中的第一行数据都存储了系名、系主任,数据的冗余太大
插入异常
如果有一个新的系还没有开始找到学生,那么不能讲该系的信息添加到数据表中去,从数据表中看不到该系的存在
删除异常
如果将某个系的学生信息全部删除,那么这个系在数据表里也就不存在了,但这个系还存在。
更新异常
如果某个人要转系,那么为了保证数据库中数据的一致性,需要修改三条记录中系与系主任的数据

总体来说个人感觉不完全依赖主键的话,描述多个事物,更新删除插入等等都会变得很繁琐,分成多个表类似编程中的模块化,便捷很多

修改:
在这里插入图片描述
表一: 分数完全依赖于 学号和课程的属性
表二: 姓名、系名、系主任完全依赖于学号的属性
第二范式消除了第一范式的部分依赖

第三范式

字段的冗余性
所有的非主属性不依赖于其他的非主属性,即不存在传递依赖;
如:
主属性:学号
非主属性:姓名、系名、系主任
系名可以推出系主任,所以非主属性系主任对主属性学号存在传递函数依赖,将该数据表改进如下:
在这里插入图片描述
第三范式消除了第二范式的传递函数依赖

BC 范式

主属性不能对候选码存在部分函数依赖或者传递函数依赖
如:
在这里插入图片描述
主属性:仓库名、管理员、物品名
非主属性:数量

存在的问题:

  1. 先新添加一个仓库,但尚未存放任何物品,不可以为该仓库指派管理员,因为物品名也是主属性,根据实体完整性的要求,主属性不能为空
  2. 某仓库被清空后,该仓库的信息也被清空
  3. 当需要更新仓库管理员,该仓库存放了多少物品,就要修改多少条信息。
    在这个问题中就是存在了主属性对于候选码的部分依赖,也就是仓库名对于管理员和物品名的部分依赖。
    修改为:
    仓库(仓库名,管理员)
    库存(仓库名、物品数、数量)

反范式化

一般说来,数据库只需满足第三范式(3NF)就行了。
但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据
具体做法:概念数据模型设计时遵守第三范式,物理数据模型设计时考虑降低范式标准。降低范式就是增加字段,允许冗余,达到以空间换时间的目的。
如:
〖例〗:有一张存放商品的基本表,“金额”这个字段的存在,表明该表的设计不满足第三范式,因为“金额”可以由“单价”乘以“数量”得到,说明“金额”是冗余字段。但是,增加“金额”这个冗余字段,可以提高查询统计的速度,这就是以空间换时间的作法。

范式、反范式性能比较

范式化

优点

  1. 可以尽量减少数据冗余,数据表更新快体积小
  2. 范式化更新操作快,范式化的表更小

缺点

  1. 查询需要多个表进行**关联,导致性能降低
  2. 更难进行索引优化

反范式化

优点

减少表的关联,更好的进行索引优化

缺点

存在数据冗余、数据异常,对数据的修改需要更多的成本

参考:
数据库逻辑设计之三大范式通俗理解,一看就懂,书上说的太晦涩

MySQL三大范式

展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 深蓝海洋 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读