Question

我需要关闭它。我制定了一个定义，部分依赖是指字段间接依赖于主键或部分依赖，但也依赖于依赖于主要的其他键，如果另一个字段依赖于id的字段被删除该字段仍将存在到期它依赖于主键。我不确定它是否正确。我已经研究过，每个定义听起来都很误导。我的定义是否正确，如果不是，请解释一下？

Answer 1

当删除一个确定属性时，保持关系的FD（功能依赖性）是部分的，给出了保持在该关系中的FD。非偏的FD已满。

例如，如果{A，B}→{C}而且{A}→{C}，那么{C}部分功能依赖于{A，B}。

功能依赖性X→Y是完全功能依赖性，如果   从X中删除任何属性A意味着依赖性不会   再坚持;也就是说，对于任何属性A∈X，（X - {A}）都没有   在功能上确定Y.功能依赖性X→Y是部分的   依赖性如果某个属性A∈X可以从X中删除   依赖仍然存在;也就是说，对于某些A∈X，（X - {A}）→Y。

- 数据库系统的基础第六版Ramez Elmasri＆amp; Navathe

请注意，FD是完全还是部分不依赖于CK（候选键），更不用说你可能正在调用PK（主键）的一个CK。

（2NF的定义涉及非CK属性对CK的完全功能依赖性，但任何持有的FD都是全部或部分。而PK对2NF也无关紧要。）

Answer 2

部分依赖表示非主要属性在功能上依赖于候选键的部分。（非主要属性是任何候选键的一部分属性。）

例如，让我们从R {ABCD}开始，功能依赖性AB-＆gt; CD和A-＆gt; C.

R的唯一候选键是AB。 C和D是非主要属性。 C在功能上依赖于A. A是候选键的部分。那是部分依赖。

Answer 3

部分依赖暗示非主要属性（不构成决定因素（主键/候选键）的一部分的属性）< strong> 功能相关 到主键/候选键的一部分/部分。

Answer 4

部分依赖是主键必须是候选键时发生的一种功能依赖，非主要属性取决于候选键的子集/部分（多个主键）。 / p>

尝试通过示例了解部分依赖关系：

卖家（同行，产品，价格）

候选键： ID，产品
非素数属性：价格

价格属性仅取决于产品属性，它是候选键的子集，不是整个候选键（Id，产品）键。它被称为部分依赖。

所以我们可以说产品 - >价格是部分依赖。

Answer 5

为了达到2NF中的关系而解决了部分依赖性，但是2NF是一个踩踏石头＆＃34; （C.日期）用于解决任何传递依赖并到达3NF中的关系（这是操作目标）。然而，对部分依赖最感兴趣的是它是自身传递依赖的特例。这是由A. A. Berstein在1976年演示的：IF {（x•y）→z但是y→z}那么{（x•y）→y＆amp; ÿ→Z}。 Berstein的3NF合成器算法不需要区分这两种类型的关系缺陷。

Answer 6

考虑表格= {cid，sid，位置}
候选键：cidsid（唯一标识行）
主要属性：cid和sid（用于制作候选密钥的属性）
非主要属性：地理位置（候选键以外的属性）

如果候选键确定非素属性：

i.e cidsid--->location (---->=determining) 
   then, it is fully functional dependent

如果候选键的正确子集确定了非素数属性

 i.e sid--->location (proper subset are sid and cid)
         then it is term as partial dependency

要删除部分依赖关系，我们相应地对表进行划分。

Answer 7

我希望这种解释比以前给出的答案能更直观地吸引依赖性。

功能依赖性

对依赖关系的分析在属性级别进行，即一个或多个属性由另一个属性确定，它在键的概念之前出现。 '钥匙的作用是基于确定的概念。 '决定就是状态了解一个属性的值可以确定该值另一个。数据库系统12ed

功能依赖性是指一个或多个属性确定一个或多个属性。例如：

社会保险号->名，姓

但是，根据功能依赖性的定义：

（SSN，名字）->姓氏

这也是有效的功能依赖关系。 决定因素（决定另一个属性的属性）称为超级键。

完全功能依赖

因此，作为功能依赖项的子集，有完全功能依赖项的概念，其中考虑了最小的行列式。我们将这些最起码的决定因素统称为一个候选键（我认为是奇怪的语言怪癖，就像向量的概念一样。）

部分功能依赖性

但是，有时候选关键字中的一个属性足以确定关系（没有行的表）中的另一个（不是全部）属性。那就是当您在关系中具有部分功能依赖性时。

Answer 8

如果存在关系R（ABC）

-----------
|A | B | C |
-----------
|a | 1 | x |
|b | 1 | x |
|c | 1 | x |
|d | 2 | y |
|e | 2 | y |
|f | 3 | z |
|g | 3 | z |
 ----------
Given,
F1: A --> B 
F2: B --> C

主键和候选键为：A

由于A + = {ABC}或R的闭包-因此，只有属性A才能找到关系R。

DEF-1：根据某些定义（来源不明）-部分依赖项是主要属性（即，作为候选关键字的一部分（或适当子集）的属性）确定时的依赖项非主要属性（即不是候选关键字的一部分（或子集）的属性）。

因此，A是质数（P）属性，而B，C是非质数（NP）属性。

因此，从上面的 DEF-1 ，

CONSIDERATION-1 ：： F1：A-> B（P决定NP）---必须是部分依赖。

CONSIDERATION-2 ：： F2：B-> C（NP确定NP）---传递依赖性。

我从@philipxy答案（https://stackoverflow.com/a/25827210/6009502）中了解到的是...

CONSIDERATION-1 :: F1：A-> B;应该是完全功能依赖的，因为B完全依赖于A，并且如果我们删除A，那么就没有可以确定B的适当子集（为明确起见，请考虑L.H.S.为X NOT BY SINGLE ATTRIBUTE）。

例如：如果我考虑F1：X-> Y其中X = {A}和Y = {B}，那么如果我们从X中删除A；即X-{A} = {};并且通常不（或根本不考虑）空集来定义功能依赖性。因此，没有X的适当子集可以保存依赖项F1：X-> Y;因此，它是完全功能依赖性。

F1：A-> B 如果删除A，则不存在可以保存功能依赖项F1的属性。因此，F1是完全功能依赖性，而不是部分依赖性。

If F1 were, F1: AC --> B;
and F2 were, F2: C --> B; 
then on the removal of A;
C --> B that means B is still dependent on C; 
we can say F1 is partial dependecy.

因此， @philipxy答案与DEF-1和CONSIDERATION-1确实是正确的 且清晰。

因此，F1：A-> B是完全功能依赖而不是部分依赖。

我考虑过X显示功能依赖项的左侧，因为单个属性不能具有适当的属性子集。在这里，我考虑将X作为一组属性，在当前情况下，X是{A}

-对于DEF-1的来源，请在Google上搜索，您也许可以找到类似的定义。（在上述示例中，请考虑DEF-1不正确或不起作用。

部分依赖（数据库）

8 个答案:

功能依赖性

完全功能依赖

部分功能依赖性