规范化可以使数据库更加适应数据结构的变化,使数据库抵御某些类型的错误。数据库规则从弱到强的次序:第一、二、三范式,Boyce_Codd范式,第四、五范式,域/键范式(DKNF)
第一范式:
列名唯一;
行列次序无关;(若有次序要求,则加列priority)
每列数据类型唯一;
两行不同;(相同则加列quantity)
每列单值;(妻子列不能写多个名字)
列不包含重复的组。(不要建家畜1,家畜2,……等重复的列)
第二范式:
符合第一范式;
所有的非键值字段均依赖所有的键值字段。
例子:歌手、演出时间、歌手等级、歌手类型
问题:歌手和演出时间构成主键,但等级和类型都不依赖演出时间(属于键值字段)。
异常:
若更改了某一时段的歌手类型,其他时间段的该歌手类型冲突。
在增加一个歌手时,必须同时增加演出时间。
若取消了歌手的某一时间的表演,可能该歌手的全部信息就会丢失。
解决:将等级和类型移到新表中。
第三范式:
符合第二范式;
一个非键值字段不依赖于另一个非键值字段。(即不包含传递相关性)
例子:读者、书名、作者、出版时间
问题:书名依赖读者,而其他字段又依赖书名。
异常:
若修改了一本书的出版时间,而其他行的该书的时间则冲突。
必须在确定读者的情况下才能插入一本新书。
删除一读者可能会丢失一本书的信息。
解决:将作者、出版时间移到新表中。
Boyce_Codd范式(BCNF):
符合第三范式;
每个决定因子都是一个候选建。
概念:
超键:包含唯一值的一组字段。(既能够标识表中某个特定的行)
候选键:最小的超键。(即从候选键中删除任一列,将不再是超键)
决定因子:决定另一字段取值的字段
例子:学号、姓、名字、职务(一名学生可有多个职务,一个职务也可有多个学生)
问题:学号决定了姓和名字,但学号不是一个候选键。(学号+职务才是候选键)
异常:
若更改了一员工的姓,其他行该员工的姓则发生冲突。
不给学生指派职务,则无法添加学生记录。
删除一职务,可能会删除该学生的记录。
解决:将姓,名字移到新表中。
第四范式:
符合BCNF;
不包含无关的多值依赖性。
概念:
无关的多值依赖性:技能依赖员工,工具依赖员工,但技能和工具是独立的。
例子:员工,技能,工具(一个员工可有n种技能,m种工具)
问题:技能、工具具有无关的多值依赖性
异常:
一名员工的技能修改了,其他工具对应的技能则冲突。
一名员工丢失了一技能,需删除对应的n行。
一名员工增加一技能,必须增加对应的n行。
解决:将技能和工具放在两个表中,分别和员工关联。
第五范式:
符合第四范式;
不包含相关的多值依赖性。
概念:
相关的多值依赖性:汽车品牌依赖修理工,发动机类型依赖修理工,但品牌和发动机类型是相关的。
例子:修理工,汽车品牌,发动机类型
问题:品牌和发动机类型具有相关的多值依赖性。
解决:将品牌和发动机类型放在两个表中,与修理工关联;
同时还要有个品牌和发动机的关联表。
域/键范式(DKNF):
除了域约束和键约束外,该表不包含其他约束。
概念:
域约束:字段的值满足属于其域内的值。
键约束:构成一个键的字段中的值是唯一的。
例子:名字,省份,城市,区,邮编
问题:省份/城市/区与邮编存在约束,该约束不是域约束或键约束。
若将邮编拿出来则是DKNF,但我国的邮编有上千个,且有时还会变化。这样表的规模就很庞大,维护也不方便。所以有时也需要必要的冗余。
符合DKNF该范式的数据库,可以避免所有的数据异常;但有时满足该范式需要花费很大的代价,使维护很困难。一般较低级别的规范化就能得到足够好的结构,大多数情况不需要采用该范式。
注:本文参考《数据库设计解决方案入门经典》(美)Rod Stephens著 王海涛 宋丽华译 一书
转载于:https://blog.51cto.com/lindianli/1378600