尴尬的第四范式 第五范式
作者：互联网
先准备几个概念防止后面对范式的理解不清晰。
候选码和主码：表中可以唯一确定一个元组的某个属性（或者属性组）叫候选码。
主码：我们从许多个候选码中挑一个就叫主码。（主键）
属性：教科书上解释为：“实体所具有的某一特性”，在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。
主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。
非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。
范式的概念
第一范式：即表中的每一个属性都是不可再分的。
第二范式：符合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
https://blog.csdn.net/zgcr654321/article/details/82350236
标签：非主,java,主码,第五,尴尬,依赖,范式,属性 来源： https://blog.csdn.net/xie__jin__cheng/article/details/88552967