数据库设计范式
1.第一范式(1NF)
定义:如果关系模式R的所有属性的域都是原子的,那么称关系模式R属于第一范式。
通俗的讲,第一范式就是属性不可再分。比如地址属性,可以再分为省、市、县等属性,所以在这种情况下,地址属性所在的关系模式就不符合第一范式。
2.第二范式(2NF)
定义:若R满足第一范式,且每一个非主属性完全函数依赖于主码,则R满足第二范式。
这里首先补充函数依赖的知识
平凡依赖和非平凡依赖
如果A->B,A是B的超集,则称此函数依赖为平凡的。
举个例子:A->A AB->A ABC->AB都是平凡依赖(此处的A、B、C为原子属性)
非平凡依赖就是不包含自己或包含自己的集决定自己的函数依赖。
完全依赖和部分依赖
函数依赖A->B称为部分依赖的条件是存在A的真子集C使得C->B。即A中的一部分就可以决定B,不需要所有的属性来决定B。
反之,需要A中所有的属性才能来决定B,缺一不可,那么A->B就是一个完全依赖。
传递依赖
如果A、B是两个属性集,存在A->B,如果c是一个属性,并且c不属于A或B,并且存在B->c,那么c就传递依赖于A。
根据2NF的定义,我们可以知道,单属性主键的关系模式一定符合第二范式。
3.第三范式(3NF)
定义:对于F*(F的闭包)中所有形如A->B的函数依赖(其中A、B都包含于R),以下至少一项成立:
· A->B是一个平凡的函数依赖
· A是R的一个超码
· B-A中的每个属性c都包含于R的一个候选码中
简单的说,若R满足第二范式,且每一个非主属性都不传递函数依赖于主码,则R满足第三范式。
即不存在如下依赖关系:
关键字段 → 非关键字段x → 非关键字段y
举个例子:
假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话),关键字为单一关键字"学号",因为存在如下决定关系:
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系:
(学号) → (所在学院) → (学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
4.BC范式(BCNF)
定义:若R满足第三范式,且每一个主属性都不部分函数依赖或传递函数依赖于主码,则R满足第三范式。
· 每一个决定属性集(因素)都包含(候选)码
· R中的所有属性(主,非主属性)都完全函数依赖于码
举个例子:
假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID) 即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。
BCNF分解算法
while(有违反BCNF的函数依赖)
{
找出违反BCNF的函数依赖A->B;
先计算A的闭包,且用A的闭包(除去A)替换B,并将其分解为{A+}和{AU(R-(A+)}; //比如A->B ,而{A}+={A,B,C},则用A->BC替换A->B;
求出分解后的关系满足的投影FD集合;
再看分解后的关系的FD集合是否满足BCNF,如果不满足,则继续分解
}
举个例子:
3NF分解算法
分解算法参考博客:https://blog.csdn.net/xiazdong/article/details/7517438