函数依赖
定义
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/
