尴尬的第四范式第五范式-优快云博客

本文链接：https://blog.youkuaiyun.com/xie__jin__cheng/article/details/88552967

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

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

范式的概念

第一范式：即表中的每一个属性都是不可再分的。
第二范式：符合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表示项目号。

供应者	零件号	项目号
S1	P1	J2
S1	P2	J1
S2	P1	J1
S1	P1	J1

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

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

项目和零件的关系

项目号	零件号
J1	P1
J1	P2
J2	P1

零件和供应商的关系

零件号	供应者
P1	S1
P1	S2
P2	S1

吐槽四：

这确实存在传递依赖的关系。但是能符合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.不是主码的属性。是，但不一定完全依赖于主码，因为他只完全依赖于候选码；不是，那也不可能完全依赖于主码。有这里我们就可以看出来了，巴斯-科德范式-这完全是第二范式、第三范式的漏洞得出来的。如果把第二范式变成：非码属性必须完全依赖于主码，而不是候选码。把第二范式变成：任何非主属性不依赖于其它非主码属性，传递依赖的限制，变成了“非主码属”性而不是"非主属性"。这样就没有巴斯-科德范式范式纯在的必要了，单我却不明白为什么第二、第三范式都部分依赖和传递依赖的限制都没有定位为主码，而是候选码的意义是什么？

数据库范式