原文地址：https://blog.csdn.net/g_beginner/article/details/6789308

1． 定义

当下面性质成立时，一个数据库模式中的表T及函数依赖集F被称为符合Boyce-Codd范式（BCNF）：任何F可推导出的函数依赖X->A都在T中，这里A是不在X中的单一属性，X必须是T的一个超键。当一个数据库模式包含的所有表都符合BCNF时，这个数据库被称为符合BCNF.

2． 说明

BCNF是比第三范式更严格一个范式。它要求关系模型中所有的属性（包括主属性和非主属性）都不传递依赖于任何候选关键字。也就是说，当关系型表中功能上互相依赖的那些列的每一列都是一个候选关键字时候，该满足BCNF。

BCNF实际上是在第三范式的基础上，进一步消除了主属性的传递依赖。

3． 举例

有这样一个配件管理表WPE(WNO,PNO,ENO,QNT),其中WNO表示仓库号，PNO表示配件号，ENO表示职工号，QNT表示数量。

有以下约束要求：

（1）       一个仓库有多名职工；

（2）       一个职工仅在一个仓库工作；

（3）       每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件；

（4）       同一种型号的配件可以分放在几个仓库中。

分析表中的函数依赖关系，可以得到：

（1）       ENO->WNO;

（2）       （WNO，PNO）->QNT

（3）       （WNO，PNO）->ENO

（4）       （ENO，PNO）->QNT

可以看到，候选键有：（ENO,PNO）;(WNO,PNO)。所以，ENO,PNO,WNO均为主属性，QNT为非主属性。显然，非主属性是直接依赖于候选键的。所以此表满足第三范式。

而我们观察一下主属性：（WNO,PNO）->ENO;ENO->WNO。显然WNO对于候选键（WNO,PNO）存在传递依赖，所以不符合BCNF.

解决这个问题的办法是分拆为两个表：管理表EP（ENO，PNO，QNT）；工作表EW（ENO，WNO）。但这样做会导致函数依赖（WNO,PNO）->ENO丢失。

4． 应用

虽然，不满足BCNF，也会导致一些冗余和一致性的问题。但是，将表分解成满足BCNF的表又可能丢失一些函数依赖。所以，一般情况下不会强制要求关系表要满足BCNF。

5.第四范式（4NF）

1． 定义

第四范式需要满足以下要求：

（1）       必须满足第三范式

（2）       表中不能包含一个实体的两个或多个互相独立的多值因子。

2． 说明

     显然，第四范式也是一个比第三范式严格的范式。

     第四范式的意思是：当一个表中的非主属性互相独立时（3NF），这些非主属性不应该有多值。若有多值就违反了第四范式。定义比较抽象，可以参照下面的例子理解。

3． 举例

有这样一个用户联系方式表TELEPHONE(CUSTOMERID,PHONE,CELL)。 CUSTOMERID为用户ID,PHONE为用户的固定电话,CELL为用户的移动电话。

      本来，这是一个非常简单的第3范式表。主键为CUSTOMERID，不存在传递依赖。但在某些情况下，这样的表还是不合理的。比如说，用户有两个固定电话，两个移动电话。这时，表的具体表示如下：

      由于PHONE和CELL是互相独立的，而有些用户又有两个和多个值。这时此表就违反第四范式。

      在这种情况下，此表的设计就会带来很多维护上的麻烦。例如，如果用户放弃第一行的固定电话和第二行的移动电话，那么这两行会合并吗？等等

      解决问题的方法为，设计一个新表NEW_PHONE(CUSTOMERID,NUMBER,TYPE).这样就可以对每个用户处理不同类型的多个电话号码，而不会违反第四范式。

4． 应用

显然，第四范式的应用范围比较小，因为只有在某些特殊情况下，要考虑将表规范到第四范式。所以在实际应用中，一般不要求表满足第四范式。

六．第五范式（5NF）

1． 定义

第五范式有以下要求：

（1）       必须满足第四范式

（2）       表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。

2． 说明

第五范式是在第四范式的基础上做的进一步规范化。

第四范式处理的是相互独立的多值情况，而第五范式则处理相互依赖的多值情况。

3． 举例

有一个销售信息表SALES（SALEPERSON，VENDOR，PRODUCT）。SALEPERSON代表销售人员，VENDOR代表供和商，PRODUCT则代表产品。

在某些情况下，这个表中会产生一些冗余。可以将表分解为PERSON_VENDOR表（SALEPERSON，VENDOR）；PERSON_PRODUCT表（SALEPERSON，PRODUCT）；VENDOR­_PRODICT表（VENDOR，PRODUCT）。

4． 应用

第五范式的应用就更少了，很多时候，我认为分解为第五范式是完全没必要的。可能在某些情况下会有意义吧。不懂。。。

总结：

   总之，规范化的过程就是在数据库表设计时移除数据冗余的过程。随着规范化的进行，数据冗余越来越少，但数据库的效率也越来越低。

   这就要求你在数据库设计中，能结合实际应用的性能要求，规范到合适的范式。一般情况下，如何性能允许的话，都要求规范到第三范式的。

===================================================

例子：STC(Sid,Tid,Cid) 学生选课m:n，老师授课m:1， 
有以下函数依赖：(Sid,Cid)->Tid;(Sid,Tid)->Cid;Tid->Cid 

这个表不符合BCNF但符合第三范式。 
改为：ST(Sid,Tid);TC(Tid,Cid)。现在就符合BCNF了。 

3NF->BCNF 需要消除主属性对键的部分和传递函数依赖。

第三章 关系数据库设计理论

3.5 BC范式和第三范式

BC范式（BCNF）

• 定义：

  关系 R 满足 BCNF

  当且仅当：如果 R 中非平凡FD A1,A2,…,An→B 成立，则 {A1,A2,…,An} 是关系 R 的超键。

• 对定义的理解：

  • 每个非平凡FD的左边都必须是超键。

    （由于超键不一定要最小化，因此可以等价描述为，每个非平凡FD的左边都必须包含键。）

• 结论

  • 任意一个二元关系属于BCNF。

    多个键情况下只要包含任一个键都算满足 BCNF 的条件。

• 分解到 BCNF：左右圆法

  寻找违反BCNF的非平凡FD A→B ，找到 { A } + \{ A \}^+ {A}+，放到该FD的右端。

  然后将关系模式直接分解为两部分：

  1. 一部分为该FD的左端A和右端属性集
  2. 一部分为该FD的左端A和该FD未包括的所有属性

  如图：

  例题：

  P51 例3.19 $ {title, year, studioName, president, presAddr} $，

  其中，有FD:

  ​ $title,year\to studioname$

  ​ $studioname\to president$

  ​ $president\to presAddr$

  解：

  以 按照违反BCNF的 $studioname\to president$ 来分解 为例：

  计算闭包，得出唯一键是 { t i t l e , y e a r } \{ title, year \} {title,year}。

  则 R 1 = { t i t l e , y e a r ‾ , s t u d i o n a m e } {R_1 = \{\underline{title,year},studioname\}} R1​={title,year​,studioname}

  R 2 = { s t u d i o n a m e ‾ , p r e s i d e n t , p r e s A d d r } {R_2 = \{\underline{studioname}, president,presAddr\}} R2​={studioname​,president,presAddr}

  R2 不符合BC范式，故再分解（按照违反BCNF的基本集 $president\to presAddr$）。

  得到 R 3 = { p r e s i d e n t , p r e s A d d r } {R_3 = \{president, presAddr\}} R3​={president,presAddr}

  R 4 = { p r e s i d e n t , s t u d i o n a m e } {R_4 = \{president, studioname\}} R4​={president,studioname}

  最终结果即为 R1, R3, R4。

第三范式（3NF）

• 定义

  如果 R 中非平凡FD $A_1,A_2,..,A_n\to B_1,B_2,..,B_m$ 成立，

  那么或者 {A1,A2,…,An} 是关系R的超键，或者 每个属于 B 但不属于 A 的属性都是某个键的成员。

  “主属性” 表示 键包含的属性。

• 对定义的理解

  即对于任一非平凡FD，①左侧的属性是 R 的超键 或者 ②右侧的属性是键的属性。

3.6 多值依赖

定义

在关系 R 中，当给定某个属性集合的值时，存在有一组与关系中所有其他属性值相独立的属性值。（以 $R(A,B,C)$ 为例）

• 独立：不能相互决定，相互之间的取值包含所有组合。

• 若给定 R 中属于 A 的各属性的值，
  则存在一个属性集 B，B 的值独立于 R 中既不属于A也不属于B的属性集合（也就是C）的值，
  则 R 中 $\text{MVD}{A}_1,A_2,..,A_n\to \to B_1,B_2,..,B_m$ 成立，称 $A_1,A_2,..,A_n$ 多值决定 $B_1,B_2,..,B_m$ 。

  ---

• 对于 R 中每个在 A 上取值相同的元组对 t 和 u，能找到满足下列条件的元组 v：
  在 A 属性上的取值与 t 和 u 相同；
  在 B 属性上的取值与 t 相同；
  在 AB 外的其他所有属性上取值与 u 相同。

  如图：

• 对定义的理解

  1. 设 U 是关系模式R的属性集合，X，Y，Z是 U 的子集，并且 Z = U - X - Y。
     R中存在多值依赖 X→→Y ，
     当且仅当 对于 R 中的任一关系 r ，给定一对（x，z）值，有一组 Y 值，这组 Y 值仅仅决定于 x 值而与 z 值无关。

  ---

  2. 在 R(U) 的任一关系 r 中，如果存在元组 t，s 使得 t[X] = s[X]，那么就必然存在元组 w，v ∈ r，(w，v可以与s，t相同)，使得 w[X] = v[X] = t[X]，而 w[Y] = t[Y]，w[Z] = s[Z]，v[Y] = s[Y]，v[Z] = t[Z]（即交换s，t元组的Y值所得的两个新元组必在 r 中），则 Y 多值依赖于 X，记为 X→→Y。 这里，X，Y是U的子集，Z = U - X - Y。

     如图：

平凡多值依赖

• X→→Y，若 Y 包含于 X 或者Z＝U - X - Y = Ø，则称 X→→Y 为平凡的多值依赖；
• 平凡多值依赖一定成立，之所以称为“平凡的”是因为它并不能定义R上任何重要的或有意义的约束。

多值依赖的推论

• 函数依赖（FD）是多值依赖（MVD）的特殊情况。

  这意味着，如果 $A_1{A}_2...A_n\to B_1{B}_2...B_m$，则 $A_1{A}_2...A_n\to \to B_1{B}_2...B_m$ 也成立。

  证明见 PPT

多值依赖的特性

• MVD 不遵循分解原则。

  例如，有 name →→ street city，但是 name →→ street 并不成立。（P63 例3.30）

• 互补规则（对称性）

  互换BC符号即可得， 即 Z = U - X - Y，R 中存在多值依赖 X →→Y，则 R 中也存在多值依赖 X →→Z。

第四范式（4NF）

• 定义：

  • 在 R 中，若任一 非平凡MVD 成立时，都有 左边是超键 的结论，则 R 属于第四范式。

  • 第四范式是 BCNF 的特例，满足 4NF 则满足 BCNF，违反 BCNF 则违反 4NF。

    (4NF 包含于 BCNF)

    证明见 PPT

• 分解到第四范式

  若多值依赖左边不是超键，则违反了4NF条件，运用投影分解方法将对应的关系 R 分解为两个关系：

  • 含有 A 和 B 的全部属性

  • 含有 A 的全部属性和不在 AB 中的全部属性

  （与BCNF中的左右圆分解方法非常相似）

• 范式之间的联系

  • 3NF：任何非平凡函数依赖的左侧是超键或右侧是主属性；
  • BCNF：任何非平凡函数依赖的左侧是超键；
  • 4NF：任何非平凡多值依赖的左侧是超键；

《秒懂数据库范式》

先准备几个概念防止后面对范式的理解不清晰。

元组：表中的一行就是一个元组。
候选码和主码：表中可以唯一确定一个元组的某个属性（或者属性组）叫候选码。
主码：我们从许多个候选码中挑一个就叫主码。（主键）
属性：教科书上解释为：“实体所具有的某一特性”，在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。
主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。
非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。

范式的概念

第一范式：即表中的每一个属性都是不可再分的。
第二范式：符合1NF，且所有的非主属性都完全依赖于主属性。
第三范式：符合2NF，并要求任何非主属性不依赖于其他非主属性。
BC范式（BCNF）：符合3NF，并且主属性内部不能有部分或传递依赖。
第四范式：消除多值依赖
第五范式：消除传递依赖

第一范式解
即表中的每一个属性都是不可再分的。
注意：这句话定义的太他妈的糟糕了，从学数据库我就没弄明白，设计了好些年数据库了，还是不太明白。
这里我这样理解，这里的不可分割是对应的从数据库的角度讲，这个数据不用在分了，想对于数据库而言的原子性。
说得具体点，这就是我定义的数据库的最小单位，无论他里面装的多丰富的内容，但是做为数据的控制而言，我就定义这么个单位。
就拿电话这个概念吧，我就定义“电话”这个属性 那么有两个电话这么办呢。
如下这样的录入数据是没有问题的
姓名 电话
张三 131457811,0431-2574214
李四 0431-1234567
但如下这样录入，就有问题
姓名 电话
张三 131457811
张三 0431-2574214
李四 0431-1234567

那么如果解决这个问题呢，很明显，用录入的方式就可以解决问题（我们可以把两个电话放在一起用,隔开的方式也可是说是不可再分，不可分这个定义非常的不友好，就这里来说，区号用不用分呢，所以说但从数据本身是否可分，根本是一个说不清的话题）。
所以啊，这第一范式的要求，定义的不好，还不如说属性要有相对的原子行呢？

注：这我这样理解，属性不可分割指的是纵向不可分割，并不是横向不可分割。横向不可分割说不清楚，比如电话，可以在分成区号和电话，甚至在可以分成是否是国际电话，如果是这样的话，一定要把电话设计层区号+电话两个字段，显然不是这样的，所以我认为这里发不可分割是纵向的。

当然这里通常的解决方案应该是这样的

姓名   固定电话           移动电话
张三  0431-2574214   131457811 
李四   0431-1234567

那么这个方案有什么问题呢，明显数据有空位（李四  移动电话）

相对合理的解决方案应这样（明显没有数冗余，有id的容易，但是id的容易就行指摘一样，对空间和性能的消耗都不大）

用户表

id 姓名          
1   张三  
2   李四  

电话表

id   电话         
1   0431-2574214 
1   131457811 
2   0431-1234567
 

吐槽一

其实范式这个东西，说白了，理解好他和设计好数据库没有多大关系，理解起来太费劲了。
要我说，设计数据库就一个原则：源数据不能重复（冗余），但关系可以重复，就行c++的设计对待数据和指针一样，个人觉得如果遵守了这个原则去设计数据库，觉得不会有任何一个范式不符合的问题。
对范式我分如下两种情况解释

对于主码不是复合属性且没有外码的情况

第一范式：即表中的每一个属性都是不可再分的。
第三范式：符合2NF，并要求任何非主属性不依赖于其他非主属性。
满足上面两个范式，数据库的设计就完美呢（不需要第二范式）

如果有了组合属性的主码呢
那问题就多喽
一
我这里定义一个词：
非主候选码属性：不属于主码，但属于候选码的属性
假设主码内部没有非完全依赖和部分依赖的情况，且没有非主码属性。那么到第3NF，数据库完美
符合1NF，且所有的非主属性都完全依赖于主属性。
符合2NF，并要求任何非主属性不依赖于其他非主属性。
符合3NF，并且主属性内部不能有部分或传递依赖。
二
假设主码内部没有非完全依赖和部分依赖的情况，且没有非主码属性。
符合1NF，且所有的非主属性都完全依赖于码。
符合2NF，并要求任何非主属性不依赖于其他非主属性。
在第3NF的基础上在加一条：
1.非主码属性完全依赖于主码，
2.非主码属性不依赖于其他非主属性
三
假设主码内部有非完全依赖和部分依赖的情况，且没有非主码属性。那么到BC范式（BCNF），数据库完美
第一范式：即表中的每一个属性都是不可再分的。
第二范式：符合1NF，且所有的非主属性都完全依赖于主属性。
第三范式：符合2NF，并要求任何非主属性不依赖于其他非主属性。
BC范式（BCNF）：符合3NF，并且主属性内部不能有部分或传递依赖。

吐槽二

这里我又要吐槽了。
这样我定义一个概念
非主吗属性：没有在主码中出现过，这个属性就是非主属性。
第一范式：即表中的每一个属性都是不可再分的。
第二范式：符合1NF，且所有的非主吗属性都完全依赖于码。
第三范式：符合2NF，并要求任何非主吗属性不依赖于其他非主吗属性。
那么BC范式还有存在的必要吗？
难道非主吗属性可以依赖于其他非主吗属性？这个我要考虑。

那么说说非常高深的第四第五范式吧。
一个表中存在三个数据：“课程、学生、先修课”。
假设2017级的计算机专业学生想要学习JAVA课程，那么他们需要先学习VB、C#、BS三门课，才可以选择进行JAVA课程。
存在关系：
课程  学生 先修课
java 张三 VB
java 张三 C#
java 张三 BS
java 李四 VB
java 李四 C#
java 李四 BS
这我的问题就来了，这是别人举的例子，我解决过来的。
多值依赖吗，确实纯在。
确是可以用下面的设计，解决这个问题，消除多值依赖
课程  学生
java 张三
java 李四

课程 先修课
java VB
java C#
java BS

吐槽三

但我的问题是，这里的多值依赖能过第一范式吗？

第一范式：即表中的每一个属性都是不可再分的。

如果我这样录数据

课程  学生  先修课
java   张三  VB，C#，BS
java   李四  VB，C#，BS

那么可以是用不符合第一范式的理由来解决问题。

在说说第无范式
设关系模式SPJ（SNO,PNO,JNO），其中SNO表示供应者号，PNO表示零件号，JNO表示项目号。

这就像排列组合的关系（SNO,PNO,JNO）间存在传递依赖的关系。如下消除这种传递关系。

即：只存在两个属性将的关系。

项目和零件的关系

零件和供应商的关系

吐槽四：

这确实存在传递依赖的关系。但是能符合BC范式范式吗？

BC范式（BCNF）：符合3NF，并且主属性内部不能有部分或传递依赖。

这第五范式的存在我觉得有点尴尬。

如下引用：

https://baike.baidu.com/item/%E7%AC%AC%E4%BA%94%E8%8C%83%E5%BC%8F/5025271?fr=aladdin

补充说明

关于第二范式和巴斯-科德范式

第一范式（1NF）：所谓第一范式（1NF）是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。

第二范式（2NF）：在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）

第三范式（3NF）：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖） 

巴斯-科德范式（BCNF）：在3NF基础上，任何非主属性不能对主键子集依赖（在3NF基础上消除对主码子集的依赖）

任何非主属性不能对主键子集依赖，这一定是一个组合主键，非主属性不能依赖于主键的一部分，这是在消除部分依赖。那么和第二范式有什么确保呢。非码属性必须完全依赖于候选码，完全依赖于候选吗，索性可以不完全依赖于主码，而完全依赖于候选码。再看第三范式，任何非主属性不依赖于其它非主属性，不依赖于其他非主属性，就是可以依赖于候选码的属性。这要到第三范式就纯在一个依赖候选码的属性，而这个候选码，有两种可能，1.是主码的属性；2.不是主码的属性。是，但不一定完全依赖于主码，因为他只完全依赖于候选码；不是，那也不可能完全依赖于主码。有这里我们就可以看出来了，巴斯-科德范式-这完全是第二范式、第三范式的漏洞得出来的。如果把第二范式变成：非码属性必须完全依赖于主码，而不是候选码。把第二范式变成：任何非主属性不依赖于其它非主码属性，传递依赖的限制，变成了“非主码属”性而不是"非主属性"。这样就没有巴斯-科德范式范式纯在的必要了，单我却不明白为什么第二、第三范式都部分依赖和传递依赖的限制都没有定位为主码，而是候选码的意义是什么？

https://baike.baidu.com/item/%E6%95%B0%E6%8D%AE%E5%BA%93%E8%8C%83%E5%BC%8F/7309898?fr=aladdin

https://www.cnblogs.com/dirichlet/archive/2010/11/27/1889772.html