mysql数据库范式
范式
目的
减小数据的冗余性
提高效率
第一范式
属性的原子性，每列不可再分解；
如：出生年月日—>年、月、日 便于后续修改
第二范式
记录的惟一性，说明一个事物；
属性必须完全依赖于主键，不能存在部分依赖
如：
说明了三个事物：学生信息、系信息、课程信息
存在的部分依赖：姓名对学号存在部分依赖、系名对学号存在部分依赖、系主任对学号存在部分依赖
可能会存在问题：
数据冗余：
表中的第一行数据都存储了系名、系主任,数据的冗余太大
插入异常：
如果有一个新的系还没有开始找到学生，那么不能讲该系的信息添加到数据表中去，从数据表中看不到该系的存在
删除异常：
如果将某个系的学生信息全部删除，那么这个系在数据表里也就不存在了，但这个系还存在。
更新异常：
如果某个人要转系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据
总体来说个人感觉不完全依赖主键的话，描述多个事物，更新删除插入等等都会变得很繁琐，分成多个表类似编程中的模块化，便捷很多
修改：
表一: 分数完全依赖于 学号和课程的属性
表二: 姓名、系名、系主任完全依赖于学号的属性
第二范式消除了第一范式的部分依赖
第三范式
字段的冗余性
所有的非主属性不依赖于其他的非主属性，即不存在传递依赖；
如：
主属性：学号
非主属性：姓名、系名、系主任
系名可以推出系主任，所以非主属性系主任对主属性学号存在传递函数依赖，将该数据表改进如下：
第三范式消除了第二范式的传递函数依赖
BC 范式
主属性不能对候选码存在部分函数依赖或者传递函数依赖
如：
主属性：仓库名、管理员、物品名
非主属性：数量
存在的问题：
- 先新添加一个仓库，但尚未存放任何物品，不可以为该仓库指派管理员，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空
- 某仓库被清空后，该仓库的信息也被清空
- 当需要更新仓库管理员，该仓库存放了多少物品，就要修改多少条信息。
在这个问题中就是存在了主属性对于候选码的部分依赖，也就是仓库名对于管理员和物品名的部分依赖。
修改为：
仓库（仓库名，管理员）
库存（仓库名、物品数、数量）
反范式化
一般说来，数据库只需满足第三范式（3NF）就行了。
但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。
具体做法：概念数据模型设计时遵守第三范式，物理数据模型设计时考虑降低范式标准。降低范式就是增加字段，允许冗余，达到以空间换时间的目的。
如：
〖例〗：有一张存放商品的基本表，“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
范式、反范式性能比较
范式化
优点
- 可以尽量减少数据冗余，数据表更新快体积小
- 范式化更新操作快，范式化的表更小
缺点
- 查询需要多个表进行**关联，导致性能降低
- 更难进行索引优化
反范式化
优点
减少表的关联，更好的进行索引优化
缺点
存在数据冗余、数据异常，对数据的修改需要更多的成本