数据库范式

规范化可以使数据库更加适应数据结构的变化，使数据库抵御某些类型的错误。数据库规则从弱到强的次序：第一、二、三范式，Boyce_Codd范式，第四、五范式，域/键范式（DKNF）

第一范式：

   列名唯一；

   行列次序无关；（若有次序要求，则加列priority）

   每列数据类型唯一；

   两行不同；（相同则加列quantity）

   每列单值；（妻子列不能写多个名字）

   列不包含重复的组。（不要建家畜1，家畜2，……等重复的列）

第二范式：

符合第一范式；

所有的非键值字段均依赖所有的键值字段。

例子：歌手、演出时间、歌手等级、歌手类型

问题：歌手和演出时间构成主键，但等级和类型都不依赖演出时间（属于键值字段）。

异常：

   若更改了某一时段的歌手类型，其他时间段的该歌手类型冲突。

   在增加一个歌手时，必须同时增加演出时间。

   若取消了歌手的某一时间的表演，可能该歌手的全部信息就会丢失。

解决：将等级和类型移到新表中。

第三范式：

   符合第二范式；

   一个非键值字段不依赖于另一个非键值字段。（即不包含传递相关性）

   例子：读者、书名、作者、出版时间

   问题：书名依赖读者，而其他字段又依赖书名。

   异常：

       若修改了一本书的出版时间，而其他行的该书的时间则冲突。

必须在确定读者的情况下才能插入一本新书。

删除一读者可能会丢失一本书的信息。

   解决：将作者、出版时间移到新表中。

Boyce_Codd范式（BCNF）：

   符合第三范式；

   每个决定因子都是一个候选建。

   概念：

       超键：包含唯一值的一组字段。（既能够标识表中某个特定的行）

       候选键：最小的超键。（即从候选键中删除任一列，将不再是超键）

       决定因子：决定另一字段取值的字段

   例子：学号、姓、名字、职务（一名学生可有多个职务，一个职务也可有多个学生）

   问题：学号决定了姓和名字，但学号不是一个候选键。（学号+职务才是候选键）

   异常：

       若更改了一员工的姓，其他行该员工的姓则发生冲突。

       不给学生指派职务，则无法添加学生记录。

       删除一职务，可能会删除该学生的记录。

   解决：将姓，名字移到新表中。

第四范式：

   符合BCNF；

   不包含无关的多值依赖性。

概念：

无关的多值依赖性：技能依赖员工，工具依赖员工，但技能和工具是独立的。

   例子：员工，技能，工具（一个员工可有n种技能，m种工具）

   问题：技能、工具具有无关的多值依赖性

   异常：

       一名员工的技能修改了，其他工具对应的技能则冲突。

       一名员工丢失了一技能，需删除对应的n行。

       一名员工增加一技能，必须增加对应的n行。

   解决：将技能和工具放在两个表中，分别和员工关联。

第五范式：

   符合第四范式；

   不包含相关的多值依赖性。

   概念：

相关的多值依赖性：汽车品牌依赖修理工，发动机类型依赖修理工，但品牌和发动机类型是相关的。

   例子：修理工，汽车品牌，发动机类型

   问题：品牌和发动机类型具有相关的多值依赖性。

   解决：将品牌和发动机类型放在两个表中，与修理工关联；

         同时还要有个品牌和发动机的关联表。

域/键范式（DKNF）:

   除了域约束和键约束外，该表不包含其他约束。

   概念：

       域约束：字段的值满足属于其域内的值。

       键约束：构成一个键的字段中的值是唯一的。

   例子：名字，省份，城市，区，邮编

   问题：省份/城市/区与邮编存在约束，该约束不是域约束或键约束。

         若将邮编拿出来则是DKNF，但我国的邮编有上千个，且有时还会变化。这样表的规模就很庞大，维护也不方便。所以有时也需要必要的冗余。

   符合DKNF该范式的数据库，可以避免所有的数据异常；但有时满足该范式需要花费很大的代价，使维护很困难。一般较低级别的规范化就能得到足够好的结构，大多数情况不需要采用该范式。

注：本文参考《数据库设计解决方案入门经典》（美）Rod Stephens著 王海涛 宋丽华译 一书