1. 多值依赖
1.1 多值依赖：多值依赖属4nf的定义范围，比函数依赖要复杂得多。在关系模式中，函数依赖不能表示属性值之间的一对多联系，这些属性之间有些虽然没有直接关系，但存在间接的关系，把没有直接联系、但有间接的联系称为多值依赖的数据依赖。
在函数依赖中，X与Y是否存在函数依赖关系，只需考察X,Y的两组属性，与别的属性无关。而在多值依赖中，X与Y是否存在多值依赖还需看属性Z。
1.2 数学定义：设R(U)是属性集U上的一个关系模式。X，Y，Z是U的子集,并且Z=U-X-Y。关系模式R(U)中多值依赖X→→Y成立，当且仅当对R(U)的任一关系r,给定的一对(x，z)值有一组Y的值，这组值仅仅决定于x值而与z值无关。
1.3 特点：1.允许X的一个值决定Y的一组值，这种决定关系与Z取值无关。
2.多值依赖是全模式的依赖关系。（多值依赖的缺点是:数据冗余太大）
1.4 举例：有这样一个关系 <仓库管理员，仓库号，库存产品号> ，假设一个产品只能放到一个仓库中，但是一个仓库可以有若干管理员，那么对应于一个 <仓库管理员，库存产品号>有一个仓库号，而实际上，这个仓库号只与库存产品号有关，与管理员无关，就说这是多值依赖。
2. 第四范式
2.1 数学定义：设关系R（X，Y，Z），其中X，Y，Z是成对的、不相交属性的集合。若存在非平凡多值依赖，则意味着对R中的每个属性Ai(i-1,2,…,n)存在有函数依赖X->Ai（X必包含键）。那么R∈4NF。
2.2 思想来源：1.第四范式是在关系数据库中，对关系的最基本要求的满足第一范式。这样的关系模式是合法的，允许的。但人们发现有些关系模式存在插入、删除、修改异常、数据冗余等弊病，人们寻求解决这些问题的方法，这就是规范化的目的。
2.规范化的基本思想是逐步消除数据依赖中不合适的部分，使关系数据库模式的各关系模式达到某种程度的“分离”，即“一事一地”的模式设计原则。
3.定义对解：定义和实例对比解析
3.1 多值依赖：设R(U)是属性集U上的一个关系模式。X，Y，Z是U的子集,并且Z=U-X-Y。关系模式R(U)中多值依赖X→→Y成立，当且仅当对R(U)的任一关系r,给定的一对(x，z)值有一组Y的值，这组值仅仅决定于x值而与z值无关
产品(X) | 代理商(Y) | 工厂(Z) |
|---|---|---|
Car | A1 | F1 |
Car | A1 | F2 |
Bus | A2 | F2 |
这里“产品(X)→→代理商(Y)”，产生的多值依赖关系如下
产品(X) | 工厂(Z) | 代理商(Y) |
|---|---|---|
Car | F1 | A1 |
Car | F2 | A1 |
这里一个car对应一组代理商，这就是代理商多值依赖于产品。为什么会产生这个多值依赖呢？ 因为工厂，只有代理商A1销售Car ,但是这里却又两个工厂生产Car ，说以导致了Car和A1的关系冗余。这就是数据表的设计问题的体现。消除多值依赖也很简单。做如下表设计。
产品-经销商关系表
产品 | 供应商 |
|---|---|
Car | A1 |
Bus | A1 |
Car | A2 |
产品生产关系表
产品 | 工厂 |
|---|---|
Car | F1 |
Car | F2 |
Bus | F2 |
3.2 从是否符合第四范式的角度分析以上表：设关系R（X，Y，Z），其中X，Y，Z是成对的、不相交属性的集合。若存在非平凡多值依赖，则意味着对R中的每个属性Ai(i-1,2,…,n)存在有函数依赖X->Ai（X必包含键）。那么R∈4NF。
产品(X) | 代理商(Y) | 工厂(Z) |
|---|---|---|
Car | A1 | F1 |
Car | A1 | F2 |
Bus | A2 | F2 |
“R中的每个属性Ai(i-1,2,…,n)存在有函数依赖X→Ai（X必包含键） ”，将这个要求，针对当前表展开。
X→Y：代理商依赖于产品
X→Z：工厂依赖于产品
从形式上看，这里明显Car → A1的关系有两个，不满足条件。这个是从数学上形式的分析，不符合第四范式。至于原因，就是上面多值依赖的存在。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/227648.html原文链接：https://javaforall.cn
