数据库设计范式

所谓设计范式,可理解为设计一张表的各个列的规则

定义

键和函数依赖

所有的键(key) 都是 a set of one or more attributes

主属性(prime attribute) 至少出现在一个候选键中的属性

超键(super key) 一个超键能唯一标识一个元组,其属性集闭包是所有属性的集合

候选键(candidate key) 最小的超键,即任何一个子集都不能是超键; 超键就是候选键加上其他属性

主键存在多个候选键组,选一组成为主键

α->β表示α能决定β, β函数依赖于α

对键的部分函数依赖: (a,b)->(c,d,e) 且 a->c , 则c部分函数依赖于候选键(a,b)

传递依赖: a->b, b->c, 则称c传递依赖于a;

所有的部分函数依赖都是传递依赖: (a,b)->(c,d,e) 且 a->c , 则c传递依赖于候选键(a,b)

1NF
- 给定行与列, 能得到唯一的值
- 每一列都不可分割成多个子属性
2NF
- It is of historical significance only and is not used in practice.
- 非主属性不会部分函数依赖于候选键,即不存在某个主属性能决定非主属性,除非这个主属性是候选键
- 简单来看: 非主属性不能函数依赖于主属性
  - 否则两个属性应该独立成表
3NF
- 学术角度: 对于一个非平凡函数依赖α->β,要么α是超键,要么β-α的元素在某个候选键中(可以是不同的元素在不同的候选键中)
- 简单来讲: 非主属性不能函数依赖非主属性,即禁止传递依赖 (候选键->非主属性->非主属性)
  - 否则两个非主属性应该独立成表
BCNF:
- 非平凡函数依赖的左端必是超键(而不能是一个候选键的某个属性)
- 主属性不能函数依赖于主属性

在表述中,一会是超键,一会是候选键,这其实是自然的,候选键本身就会依赖于超键