数据库笔记（7.1）数据库反规范化

对冗余的控制（反范式模式）

数据库三范式：

• 一范式：一个字段只有一个值
• 二范式：一条记录可以被唯一的字段的组合所区分（一个实体有唯一的标识），是对于实体完整性的要求
• 三范式：字段和字段之间不存在函数依赖。两个字段之间不能够进行函数推导。比如有两个字段，一个字段是身份证号，一个字段是出生日期；前者可以推导出后者，所以最好不应该同时存在。

反规范化的坏处

1. 会使得实现变得更加复杂，因为需要手动保持数据完整性
2. 会降低数据的灵活性
3. 会加速元组检索的速度，但是一定会减慢更新的速度。

• 如果系统具有低修改率和高查询率，那么规范弱化是一种可行的选择。
• 如果根据某种规则打破范式，那么需要根据相应的解决方案来手动保证打破范式之后的数据完整性。
• 反规范化需要先根据三范式设计出数据表，然后在设计出的表上进行反规范化
  • 可以通过ER实体关系模型先设计出表，然后构建出满足三范式的表

考虑冗余

• 放弃完全规范化，得到某些性能上的好处。最好只在系统不满足其性能要求的时候才考虑打破范式。

打破范式的7种常见方式

1. Combine 1:1 relationships 合并1-1关系

2. Duplicating(重复) nonkey columns in 1:* relationships to reduce joins 为了减少连接操作，在1-多关系中间复制非关键字属性

• 对于“钱”这个属性，一般都需要打破范式进行存储
  

3. Duplicating FK columns in 1:* relationships to reduce joins 为了减少连接操作，在1-多关系中间复制外部关键字

• 模式本质：出现A<–B<–C这种连接模式的时候，可以改成A<–B，A<–C，B<–C，以此减少连接。
  

4. Duplicating columns in * relationships to reduce joins 为了减少连接操作，在多-多关系中间复制属性

• 适用类型：A–>B<–C，且对于B，两边的表都是*-1或者1-*，这样A于C就是一个多对多的关系。这就可以打破范式。其实也是1对多情况下打破范式的一种延伸
  

5. Introducing repeating groups 引入重复数据

• 比如电话、地址这样的，那么一个用户会拥有多个地址和电话号码，一组地址和一组电话号码就是重复组。如果需要满足三范式，那就需要单独建立一张地址或者电话号码的表，然后再做连接查询。
• 大概的方式有两种：
  • 把重复组全部打包放在主表中间（一个用户可能有5个电话号码或者地址的字段）。但是需要满足：重复组的绝对数量是一致的切无法改变；该数量不能很大，一般不能大于10个
  • 主表中存储缺省的1个电话号码/1个地址；当你真的需要所有的地址和电话号码的时候，再从那些电话号码表/地址表里面去拿。（大部分查询只需要取缺省值而不需要做连接查询）

6. Creating extract tables 合并基本表和查找表，创建提取表

• 什么查询慢，就把这些查询所需要用的表全部连接成一个大表并存储下来。
  • 但是需要这些数据不经常改变，也不需要查询非常实时的数据，允许数据有一点点延迟。
  • 如果需要实时计算，会拖垮更新的操作
  • 不到万不得已不要使用
  • “在一张数据表中构建数据仓库”

7. Partitioning tables 分区，分割物理表（第五章讲过了）