㈠ 什么是多值依赖
多值依赖属4nf的定义范围，比函数依赖要复杂得多。
在关系模式中，函数依赖不能表示属性值之间的一对多联系，这些属性之间有些虽然没有直接关系，但存在间接的关系，把没有直接联系、但有间接的联系称为多值依赖的数据依赖。
在函数依赖中，X与Y是否存在函数依赖关系，只需考察X，Y的两组属性，与别的属性无关。而在多值依赖中，X与Y是否存在多值依赖还需看属性Z。
多值依赖的举例：
有这样一个关系 <仓库管理员，仓库号，库存产品号> ，假设一个产品只能放到一个仓库中，但是一个仓库可以有若干管理员，那么对应于一个 <仓库管理员，库存产品号>有一个仓库号，而实际上，这个仓库号只与库存产品号有关，与管理员无关，就说这是多值依赖。
为降低数据冗余，作模式分解，使子模式的Z=Ø，仅有平凡多值依赖。对前例，子模式为R1(仓库，雇员)，R2(仓库，物资)。
以上内容参考：网络—多值依赖
㈡ 关系数据库多值依赖的性质：若X→Y,则X→→Y.怎么理解
多值依赖里面的Z是一组，这里一组可以是任意值，可为0，1，2，，，，
函数依赖虽然没有规定Z的依赖问题，但它相当于默认Z为某值的情况
所以 “若X→Y,则X→→Y，反之则不正确”
（个人看法）
㈢ 数据库设计过程包括几个主要阶段哪些阶段独立于数据库管理系统哪些阶段依赖于数据库管理系统
数据库设计阶段包括五个阶段，分别是：需求分析阶段、概念结构设计阶段、逻辑结构设计阶段、物理设计阶段、数据库实施阶段、数据库运行和维护阶段。
独立于数据库管理系统的是：需求分析阶段，概念设计阶段，逻辑设计阶段，物理设计阶段。
依赖于数据库管理系统的是：实施阶段，运行和维护阶段。
数据库设计是建立数据库及其应用系统的技术，是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性，为了支持相关程序运行，数据库设计就变得异常复杂。
因此最佳设计不可能一蹴而就，而只能是一种“反复探寻，逐步求精”的过程，也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。
(3)数据库多值依赖扩展阅读：
形成过程
1、需求分析阶段：综合各个用户的应用需求(数据流程图(DFD)。
2、概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式(E-R图)。
3、逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式。
4、物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。
㈣ 关于数据库中的多值依赖~4NF为什么允许平凡的多只依赖呢
呵呵，数据库关系分析，一般不好学啊！
R属于第一范式，这一句一定对，呵呵，下次问的话是最高范式知道了吗？
一张二维表就是一个第一范式，也就是表中不可分表！
R一定属于第二范式，这个也很容易证明的，第二范式就是不允许有对主属性的依赖，显然，B与C都是依赖于A的都是对主属性的依赖，当然，前提是主属性是A。不允许有对非主属性的依赖是判断是否为第二范式的标准。
R也一定属于第三范式，因为第二范式就是去掉了对主属性的传递依赖，也就是说不允许有对主属性的传递依赖。
而BCNF与4NF是对多值依赖与平凡依赖的定义，在非平凡依赖中，最高就是3NF了，事实上数据真正的还有5NF叫呢！
所以此处R最高为3NF！
㈤ 数据库函数依赖与多值依赖区别帮帮忙…！
1、符合的范式不同：
多值依赖属4nf(第四范式)的定义范围，比函数依赖要复杂得多。在关系模式中，函数依赖不能表示属性值之间的一对多联系，这些属性之间有些虽然没有直接关系，但存在间接的关系，把没有直接联系、但有间接的联系称为多值依赖的数据依赖。
2、对属性的依赖不同：
在函数依赖中，X与Y是否存在函数依赖关系，只需考察X,Y的两组属性，与别的属性无关。而在多值依赖中，X与Y是否存在多值依赖还需看属性Z。
(5)数据库多值依赖扩展阅读：
多值依赖的性质：
对称性：使用上述定义的符号，若X→→Y，则X→→Z 。实例r的X或Z每增删一个值，r就须同步增删多条记录。若X→Y,则X→→Y。故可把函数依赖看成多值依赖的特款。
多值依赖的特点：
允许X的一个值决定Y的一组值，这种决定关系与Z取值无关。多值依赖是全模式的依赖关系。多值依赖的缺点是数据冗余太大。
函数依赖的特点：
不是指关系模式R的某个或某些关系实例满足的约束条件，而是指R的所有关系实例均要满足的约束条件。函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖。数据库设计者可以对现实世界作强制的规定。
㈥ 数据库关系中含有多值依赖的时候，关系的码怎么求
（1）如果有属性不在函数依赖集中出现，那么它必须包含在候选码中；
（2）如果有属性不在函数依赖集中任何函数依赖的右边出现，那么它必须包含在候选码中；
（3）如果有属性只在函数依赖集的左边出现，则该属性一定包含在候选码中。
（4）如果有属性或属性组能唯一标识元组，则它就是候选码；
㈦ 数据库多值依赖第四范式
第四范式搞定多值属性问题！数据库范式和EER紧密相关，单纯范式意义不大。例如：课程代码 老师 教科书001 Tom A001 Tom B001 Jim A001 Jim B教科书和老师都是多值属性，所以分出来课程－老师（课程代码，老师）课程－教科书（课程代码，教科书）
㈧ 数据库中的多值依赖是怎么回事
一条记录在整个表的唯一性由多个值组合决定！
㈨ 数据库理论的疑问
一、函数依赖概念
函数依赖是从数学角度来定义的，在关系中用来刻画关系各属性之间相互制约而又相互依赖的情况。函数依赖普遍存在于现实生活中，比如，描述一个学生的关系，可以有学号、姓名、所在系等多个属性，由于一个学号对应一个且仅一个学生，一个学生就读于一个确定的系，因而当“学号”属性的值确定之后，“姓名”及“所在系”的值也就唯一地确定了， 此时， 就可以称“姓名”和“所在系”函数依赖于“学号”，或者说“学号”函数决定“姓名”和“所在系”，记作：学号→姓名、学号→所在系。下面对函数依赖给出确切的定义。
定义：设U{A1，A2，…，An}是属性集合，R（U）是U上的一个关系，x、y是U的子集。若对于R（U）下的任何一个可能的关系， 均有x的一个值对应于y的唯一具体值，称y函数依赖于x，记作x→y。 其中x称为决定因素。进而若再有y→x，则称x与y相互依赖，记作x←→y。例如表1．2所示“系”关系中：如果系名值是唯一的，即各系名均不相同，那么有函数依赖集：
系代码→系名，系代码→系地址，系代码→系电话，系代码→系专业设置。
系名→系代码，系名→系地址，系名→系电话，系名→系专业设置。
可见，系名与系代码相互依赖，记作系名←→系代码。
函数依赖中还可细分为多种函数依赖，分别介绍如下：
二、部分函数依赖
设R（U）是属性集U上的关系，x、y是U的子集，x’是x的真子集，若x→y且x’→y，则称y部分依赖x，记作X→PY。显然，当且仅当x为复合属性组时，才有可能出现部分函数依赖。
例如表1.6中， 显然有课程号→课程名，课程号→开课教研室代码。从另一角度看，只要课程号一定，同时课程名确定，开课教研室也就唯一确定，因此课程号+课程名→开课教研室代码。 但它与前述课程号→开课教研室代码是不同的，因为｛课程号，课程名｝存在真子集：“课程号”，课程号→开课教研室代码，我们把课程号十课程名→开课教研室代码称为“开课教研室代码”部分函数依赖于课程号+课程名。
三、完全函数依赖
设R（U）是属性集U上的关系，x、y是U的子集，x’是x的真子集。若对于R（U）的任何一个可能的关系，有x→y但x’→y，则称y完全函数依赖于x，记作X→FY。
所谓完全依赖是说明在依赖关系的决定项（即依赖关系的左项）中没有多余属性，有多余属性就是部分依赖。
例如设关系模式R，R＝R（学号，姓名，班号，课程号，成绩），易知：
“（学号，班号，课程号）→成绩”是R的一个部分依赖关系。 因此有决定项的真子集（学号，课程号），使得“（学号，课程号）→成绩”成立，且“学号→成绩”或“课程号→成绩”成立，“（学号，课程号）→ 成绩”是R的一个完全依赖关系。
四、传递函数依赖
设R（U）是属性集U上的关系，x、y、z是U的子集，在R（U）中，若x→y，但y→x，若y→z，则x→z，称z传递函数依赖于x，记作X→TZ。
例如在一个学校中，每门课均是某一位老师教，但有些老师可教多门课，则有关系“教学”如表3．1所示。
由以上关系不难分析，课程名→职工号、职工号→课程名，但职工号和其他属性的函数关系中都是决定因素，即职工号→老师名、职工号→职称，在这种情况下，老师名、职称传递函数依赖于课程名。
表3．1 教学表
课程名
职工号
老师名
性别
出生日期
职称
英语
T1
张平
男
55．6．3
教授
数学
T2
王文
女
62．10．5
副教授
C语言
T3
李迎
女
62．10．5
副教授
数据库
T2
王文
女
62．10．5
副教授
下面进一步举例说明。
例如设车间考核职工完成生产定额关系为W：
W（日期，工号，姓名，工种，定额，超额，车间，车间主任）
请画出该关系中存在的所有类型的函数依赖。
解答：因每个职工每个月超额情况不同，而定额一般很少变动，因此为了识别不同职工以及同一职工不同月份超额情况，选定“日期”与“工号”两者组合作为主关键字。为了直观醒目，可以在关系框架中的主关键字下方划一横线。
用箭头标出各属性的依赖情况，如图3.3所示：
图3.3 关系中各属性的依赖情况
图中表明:“超额”完全函数依赖于主关键字;“姓名”、“工种”和“车间”仅依赖于关键字中的“工号”；因“定额”依赖于“工种”，故“定额”传递函数依赖于“工号”；因“车间主任”函数依赖于“车间”，因而“车间主任”传递函数依赖于“工号”。
㈩ 在学习SQL范式时，在多值依赖的性质中遇到这几种符号问题，不知怎么解决，希望帮忙。
理论书本上都有，我举个简单例子吧
比方说
（1）X是身份证的集合，那么就需要知道名字、生日、籍贯等，
Y是驾驶证的集合，需要身份证X来得到Y,X-->-->Y,
Z是你的车型集合，不同的Y所驾驶的车型Z就不同，Y-->-->Z，
那么，你的身份证集合X可以决定你的Z通过Y
（2）X,Y同上，Z变成你的银行账号集合，X-->-->Y, X-->-->Z, 则X可以同时决定Y,Z