函数依赖
函数依赖
设R(U)是一个属性集U上的关系模式，X和Y是U的子集。若对于R(U)的任意一个可能的关系r，r 中不可能存在两个元组在X上的属性值相等， 而在Y上的属性值不等， 则称“X函数确定Y”或“Y函数依赖于X”，记作X→Y。
特别的：
若X→Y，并且Y→X, 则记为X←→Y。
若Y 不函数依赖 于X, 则记为X→Y。
自我理解
对于给定的一个全集U，当其子集X取任意的值时，子集Y都有唯一一条记录与之对应，称 X 函数确定 Y ，或 Y 函数依赖于 X 。
平凡函数依赖与非平凡函数依赖
自我理解
平凡的函数依赖是确定自己本身，或者本身的子集，这当然是显然的，我们一般讨论的都是非平凡的函数依赖。
完全函数依赖与部分函数依赖
自我理解
完全函数依赖：X的任意一个子集都不能函数确定Y，只有X为全集时，才能函数确定Y（即Y函数依赖于X）。
部分函数依赖：X存在某个子集a,子集a能够函数确定Y（即Y函数依赖子集a）
传递函数依赖
自我理解
以下均为非平凡函数依赖：
X函数确定Y，Y函数确定Z就是传递函数依赖
码
候选码
设K为R<U,F>中的属性或属性组合。若
自我理解
若子集K完全函数确定全集U，则子集K中的所有属性为一个候选码
超码
如果U部分函数依赖于K，即
自我理解
任意一个候选码，加上任意个非主属性，都会构成超码。
主码
自我理解
一个关系模式中，若有多个候选码，只能选择其中一个作为主码，即主码有且只有一个。
全码
整个属性组是码，称为全码（All-key）
自我理解
全部属性都确定下来之后，才能唯一确定一条记录，就是全码。
外码
关系模式 R中属性或属性组X 并非 R的码，但 X是另一个关系模式的码，则称 X 是R 的外部码（Foreign key）也称外码。
自我理解
关系模式A的某个子集X为其候选码，其子集X同时也在关系模式B中，且子集X不是关系模式B的候选码，则子集B就是候选码。
主属性与非主属性
自我理解
只要这个属性包含在某个候选码中，它就是主属性，否则就是非主属性。
范式
1NF
即表中的每一个属性都是不可再分的。
自我理解
2NF
若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于任何一个候选码，则R∈2NF
自我理解
候选码（主属性A，主属性B），对任意一个非主属性，主属性A不能函数确定它，主属性B也不能函数确定它，那么这个关系模式就是第二范式。
3NF
设关系模式R<U,F>∈1NF,若R中不存在这样的码X、属性组Y及非主属性Z （
自我理解
没有传递函数依赖的第一范式，就是第三范式。
BCNF
设关系模式R<U,F>∈1NF，若X →Y且Y ⊆ X时X必含有码，则R<U,F>∈BCNF。
自我理解
非主属性之间不能有函数确定
多值依赖
自我理解
X确定后，不论Y取什么值，总是对应同一组Z的值
4NF
自我理解
消除多值依赖
规范化小结
关系模式规范化的基本步骤
1NF
↓ 消除非主属性对码的部分函数依赖
消除决定因素 2NF
非码的非平凡 ↓ 消除非主属性对码的传递函数依赖
函数依赖 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表示项目号。
供应者 零件号 项目号
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，并且主属性内部不能有部分或传递依赖。
这第五范式的存在我觉得有点尴尬。
如下引用：
补充说明
关于第二范式和巴斯-科德范式
第一范式（1NF）：所谓第一范式（1NF）是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。
第二范式（2NF）：在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）
第三范式（3NF）：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
巴斯-科德范式（BCNF）：在3NF基础上，任何非主属性不能对主键子集依赖（在3NF基础上消除对主码子集的依赖）
任何非主属性不能对主键子集依赖，这一定是一个组合主键，非主属性不能依赖于主键的一部分，这是在消除部分依赖。那么和第二范式有什么确保呢。非码属性必须完全依赖于候选码，完全依赖于候选吗，索性可以不完全依赖于主码，而完全依赖于候选码。再看第三范式，任何非主属性不依赖于其它非主属性，不依赖于其他非主属性，就是可以依赖于候选码的属性。这要到第三范式就纯在一个依赖候选码的属性，而这个候选码，有两种可能，1.是主码的属性；2.不是主码的属性。是，但不一定完全依赖于主码，因为他只完全依赖于候选码；不是，那也不可能完全依赖于主码。有这里我们就可以看出来了，巴斯-科德范式-这完全是第二范式、第三范式的漏洞得出来的。如果把第二范式变成：非码属性必须完全依赖于主码，而不是候选码。把第二范式变成：任何非主属性不依赖于其它非主码属性，传递依赖的限制，变成了“非主码属”性而不是”非主属性”。这样就没有巴斯-科德范式范式纯在的必要了，单我却不明白为什么第二、第三范式都部分依赖和传递依赖的限制都没有定位为主码，而是候选码的意义是什么？
