笔记 数据库规范化(关系数据库)
规范化
数据库设计过程中的一系列原理和技术，
使用范式来定义和衡量，
主要用于减少表中数据的冗余，消除异常，提高数据完整性和一致性。
第一范式 First Normal Form
- 表中的字段都是不可再分的单一属性;
- 表需要定义主键（PRIMARY KEY）。
需要考虑字段不可分割到底是针对什么而言
第二范式 Second Normal Form
- 满足第一范式；
- 非主键字段必须完全依赖于主键或者候选键，不能只依赖于主键或者候选键的一部分。
部分函数依赖（partial functional dependency）
“部门地址”取决于“部门名称”，也就是主键的一部分；(注：部门名称 + 姓名 为主键)
第三范式
- 满足第二范式；
- 属性不依赖于其它的非主属性，也就是非关键字段不依赖于其他非关键字段。
传递函数依赖（transitive functional dependency）
当主键决定字段 A，字段 A 又决定字段 B 时，称
对于前三个范式而言，
只需要将不同的实体/对象单独存储到一张表中，
并且通过外键建立它们之间的联系即可满足。
反规范化（denormalization）
规范化可能导致连接查询（JOIN）过多
如果表中的数据量很大，过多的表连接查询会增加数据库的 IO 操作，从而降低数据库的性能。有时候为了提高某些查询或者应用的性能而
故意降低规范反的程度
数据仓库（Data Warehouse） 和 在线分析系统（OLAP）
会使用到反规范化的技术，
因为它们以复杂查询和报表分析为主
方法
- 增加冗余字段、
- 增加计算列、
- 将小表合成大表
缺点
- 反规范化会
增加更新和修改数据的开销， - 导致
数据存在冗余， - 可能带来
数据完整性和一致性的问题
外键
数据库用于实现参照完整型的约束，
利用数据库的外键可以保证数据的完整性和一致性；
外键的级联操作可以方便数据的自动处理，
减少了程序出错的可能性。
不采用的原因
数据库为了维护外键需要牺牲一定的性能，
尤其是在大数据量高并发的情况下。
将完整性检查放到应用层去实现，
而应用程序相对比较容易扩展。
在系统的设计之初应该尽量使用外键确保完整性。
如果随着业务增长出现性能问题，可以考虑在应用中实现约束。
缺失外键可能导致数据库的结构不明确，需要依赖相应的文档进行说明。
其他
更高级别的范式包括
- BC 范式（BCNF）、
- 第四范式（4NF）、
- 基本元组范式（ETNF）、
- 第五范式（5NF）、
- DK 范式（DKNF）
- 第六范式（6NF）；
