数据库理论之范式与反范式

函数依赖

定义

A 和 B 是两个属性集,来自同一关系模式,对于同样的 A 属性值,B 属性值也相同。这种关系称为函数依赖。

记作A->B ,称为B函数依赖于A。

部分函数依赖

如果对于A的一个真子集A'存在A'->B,称为B部分依赖于A。

完全函数依赖

如果对于A的任意一个真子集A'都不存在A'->B,称为B完全依赖于A。

平凡函数依赖

当B的属性集是A的子集时,且存在A->B,称这种关系为平凡函数依赖

非平凡函数依赖

当B的属性集不是A的子集时,且存在A->B,称这种关系为非平凡的函数依赖

传递函数依赖

在某关系中,若存在 如果 X->Y(非平凡函数依赖, 完全函数依赖) ,Y->Z,则称 Z 对 X 有传递函数依赖。

注: X不包含Y,Y不确定X

超键、主键、候选键

  • 超键(super key): 在关系中能唯一标识元组的属性集称为关系模式的超键
  • 候选键(candidate key): 不含有多余属性的超键称为候选键。也就是在候选键中,若再删除属性,就不是键了!

  • 主键(primary key): 用户在候选键中任选一个作为关系的主键。

  • 复合主键(compound primary key):主键包含多个属性。

候选键中 X 决定所有属性的函数依赖是完全函数依赖

包含在任何一个候选键中的属性,称为主属性,不包含在候选键中的属性称为非主属性

范式

1NF

第一范式:不包含非原子项,即任一属性不可再分。

2NF

第二范式:在第一范式的基础上。每个非主属性完全依赖于主键,不存在复合主键。

3NF

第三范式:在第二范式的基础上。非主属性不能传递依赖于主键。

BCNF

所有非主属性对每一个候选键都是完全函数依赖; 所有的主属性对每一个不包含它的候选键,也是完全函数依赖;没有任何属性完全函数依赖于非候选键的任何一组属性。

实例可以参考关系数据库的三大范式以及BCNF范式_数据库_jsj13263690918的博客-CSDN博客

反范式

范式的出现是为了避免数据冗余,减少数据库的空间,减轻维护数据完整性的麻烦。

然而它也存在一些缺点:

按照范式的规范设计出来的表,等级越高的范式设计出来的表越多。而表越多,查询时越会涉及到一些连接操作,影响查询的效率。

当我们的业务所涉及的表非常多,并且我们对表的操作要时间上要尽量的快,这时可以考虑使用“反范式”。例如合并表、复制属性等操作。

反范式就是不遵从范式规则,允许数据库维护一些冗余数据,从而提高查询效率。

OLAP和OLTP中如何设计范式

OLAP 一般冗余比较多,以查询分析为主,这种一般都是采用反范式设计,以提高查询效率。更新一般是定时大批量数据插入。

OLTP 则是尽可能消除冗余,以提高变更的效率。因为这种应用无时无刻不在频繁变化。

原创文章,作者:彭晨涛,如若转载,请注明出处:https://www.codetool.top/article/%e6%95%b0%e6%8d%ae%e5%ba%93%e7%90%86%e8%ae%ba%e4%b9%8b%e8%8c%83%e5%bc%8f%e4%b8%8e%e5%8f%8d%e8%8c%83%e5%bc%8f/