大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全家桶1年46,售后保障稳定
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的关系有两个,不满足条件。这个是从数学上形式的分析,不符合第四范式。至于原因,就是上面多值依赖的存在。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/227648.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...