部分依赖（数据库）

Question

部分依赖（数据库）

30

我提出了一个定义，即部分依赖是指字段间接依赖于主键或部分依赖于主键，但也依赖于其他依赖于主键的键。如果另一个字段所依赖的字段被删除，则由于其对主键的依赖，该字段仍将存在。我不确定这是否正确。我已经进行了研究，发现每个定义都很容易误导。我的定义是否正确，如果不正确，那么正确的定义是什么？

- rert588

9个回答

20

部分依赖是指非主属性在一个候选键的一部分上存在函数依赖关系。(非主属性指的是不属于任何一个候选键的属性)

例如，我们从R{ABCD}开始，并有以下函数依赖关系AB->CD和A->C。

R的唯一候选键是AB。 C和D是非主属性。C对A有函数依赖关系。A是一个候选键的一部分。这就是一个部分依赖性。

- Mike Sherrill 'Cat Recall'

每个FD都是完整的或部分的；键不参与其中。 - philipxy

2

C部分依赖于AB，即AB->C是一个部分函数依赖，因为C依赖于AB的一个适当子集A。C完全依赖于A，即A->C是一个完全函数依赖，因为C不依赖于A的任何适当子集。 - philipxy

你好。你对“部分函数依赖”的定义有什么参考资料吗？请看我的回答，我引用了不同的教科书。这里是Codd在《数据库关系模型的进一步规范化》中对“全函数依赖”的原始定义：“假设D、E是关系R属性的两个不同子集合，且R.D -> R.E。如果此外，E对于D的任何子集（除了D本身）都不具有函数依赖性，则称E在R中完全依赖于D。”（这并没有为X->X定义。还需要更多研究。） - philipxy

@philipxy：我没有参考资料。我没有接受过任何与计算机有关的正式培训。我完全是自学的。如果我能做到一切正确，我会感到惊讶的。 - Mike Sherrill 'Cat Recall'

很抱歉，这个答案是错误的，人们来到这篇文章并且会有错误的想法。实际上，我怀疑他们甚至没有进入页面去思考那些错误的想法，因为在谷歌搜索“部分函数依赖”时，在任何链接之上的页面顶部都是来自这篇文章的帖子中说错的话。刚才那段文字是你的帖子的开头，但其他时候它可能来自其他错误的帖子。（虽然我没有看到我的答案。好吧，我可能在那里学到了一些关于排名和语法的东西。）PS：你和dportas/sqlvogel/nvogel的数据库理论帖子（通常）具有非常高的质量。 - philipxy

你的回答中最后一段错误地说A -> C是部分函数依赖，但实际上它不是，而违反2NF的部分函数依赖是AB -> C。这一点我在第一次评论中没有表述清楚。 - philipxy

5

部分依赖是指一个非主属性（不是决定因素（主键/候选键）的一部分）函数依赖于主键/候选键的一部分/部分。

- Lehlohonolo

你对“部分函数依赖”的定义有什么参考依据？ - philipxy

3

部分依赖是一种函数依赖的类型，当主键必须是候选键，并且非主属性依赖于候选键的子集/部分（多个主键）时发生。

通过以下示例尝试理解部分依赖关系：

Seller(Id, Product, Price)

候选键：Id，Product
非主属性：Price

Price属性仅取决于Product属性，这是候选键的子集，而不是整个候选键（Id，Product）。这被称为部分依赖。

因此，我们可以说Product->Price是部分依赖。

- rashedcs

你对“部分函数依赖”的定义有何参考？ - philipxy

我根据自己的直觉写了这个。所以我无法提供参考。如果发现任何错误，请务必告知。 - rashedcs

技术术语有其含义和历史。"Partial FD" 的定义是指某个特定的事物，并且在研究和教科书中一直以这个意义使用。在教科书中很容易找到定义。它没有用CK或PK来定义。请看我的回答。但是你的帖子与它的实际意义不一致（而且你的英语表达不够清晰）。所以我很想知道你为什么认为它意味着你认为的任何东西 - 尽管你的帖子不够清晰，无法知道你认为它意味着什么。"直觉" 是无关紧要的，你提到它非常奇怪。 - philipxy

2

我希望这个解释比之前给出的答案更直观地说明了依赖关系。

功能依赖分析是在属性级别上进行的，即一个或多个属性由另一个属性确定，在键的概念之前。'关键字的作用基于决定的概念。'决定是一种状态，其中知道一个属性的值使得可以确定另一个属性的值。' 数据库系统 12ed 功能依赖是指一个或多个属性决定一个或多个属性。例如：

社会安全号码->名字，姓氏。

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

（SSN，名字）->姓

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

因此，作为功能依赖的子集，存在完整功能依赖的概念，其中考虑了最少的决定因素。我们将这些最少的决定因素统称为一个候选键（在我看来是奇怪的语言习惯，就像向量的概念）。

然而，有时候候选键中的一个属性足以确定关系中的另一个属性，但不是全部。那就是在关系中存在部分功能依赖。

- Vincent Lam

你对“部分函数依赖”的定义有何参考？ - philipxy

1

Partial dependence是解决到达二范式关系的一种方法，但是二范式只是解决任何传递依赖和到达三范式关系的“跳板”（C. Date）。然而，关于部分依赖最有趣的事情是它是自身传递依赖的一个特例。这是由P.A. Berstein在1976年证明的：如果{(x•y)→z但是y→z}，那么{(x•y)→y & y→z}。Berstein的3NF合成算法不需要区分这两种类型的关系缺陷。

- EnriqueVillar

1

部分函数依赖仅在复合键关系中发生。当一个或多个非键属性取决于主键的一部分时，就会发生部分函数依赖。

例如:

表： Stud_id，Course_id，Stud_name，Course_Name

其中：主键= Stud_id + Course_id

然后：为确定学生的姓名，我们仅使用Stud_id，这是主键的一部分。

{Stud_id} -> {Stud_Name}

因此，Stud_name部分依赖于Stud_id。这被称为部分依赖。

- Juhi Shelar

第一句话是错误的，请看我的回答和评论。第二句话是错误和不清楚的，请看我的回答。其余部分不清楚。 - philipxy

1

你的“部分函数依赖”的定义的参考是什么？ - philipxy

0

考虑一个表={cid，sid，location}
候选键：cidsid（唯一标识行）
主属性：cid和sid（用于制作候选键的属性）
非主属性：location（除了候选键之外的属性）

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

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

为了消除部分依赖，我们相应地划分表格。

- Yash Zade

0

如果有一个关系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 determines NP) --- 这必须是部分依赖。

CONSIDERATION-2:: F2: B --> C (NP determines NP) --- 这是传递依赖。

我从 @philipxy 的回答中理解到的是（https://dev59.com/VF8e5IYBdhLWcg3wcKAq#25827210）...

考虑因素-1：F1: A --> B；应该是完全功能依赖，因为B完全依赖于A。如果我们去除A，则没有任何一个子集（为了完全澄清，请将L.H.S.视为X，而不是单个属性）能够确定B。

例如：如果我考虑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在上述示例中不正确或不起作用）。

- sagar

这不够清晰。请使用足够的词语、句子和示例引用来明确和完整地表达您的意思。不要试图把所有东西都塞到一个短语或句子中。此外，这个陈述是错误的。那些函数依赖必须形成覆盖，否则无法确定 CK。PK 是无关紧要的。“足以找到”只是日常用语。“我们可以说 B 部分依赖于 A 和 C”——不，B 部分依赖于 AC。定义 1 将“部分函数依赖”与“第二范式”混淆了。你引用的来源怎么会是未知的呢？而且给出它有什么意义？你对它做了什么？... - philipxy

请查看我的答案评论和编辑过的答案，了解如何将仅有一个属性的函数依赖定义为部分依赖，因为空集可以是一个决定因子。"因为B完全依赖于A"是错误的，因为B并不依赖于A的所有内容——很明显，在X->Y中，Y始终与X的所有内容相关联。您提供示例数据的目的是什么？-您并没有用到其内容。等等。 - philipxy

@philipxy更新了我的答案，以便更加明确地帮助您理解我的观点。然而，在实际的情况中，我从未见过空属性或空集合 - {}任何确定性。这在理论上可能是可能的。但没有实际用途。 - sagar

这仍然存在大部分问题-我猜我们不同意。我的上一个评论已经与您关于{}的最新评论相矛盾了。（只需应用FD的定义即可。）当且仅当X必须至多具有一个值时，PS {}-> {X}。我们看不到很多，因为它通常是一个明显的糟糕设计。但是来自实践的两个例子是参数值的1行表（{}是一个CK）和用于在声明限制中将子类型表的具有唯一自身类型标记的列作为FK约束到超类型表的子类型标记列的某种SQL语言习惯用法。 - philipxy

关于“给定”函数依赖关系： “我有这些FDs”的意思是什么？“这些都是保持的FDs”？-不可能。“这些都是不平凡的FDs”？-不可能。“这些是一些保持的FDs”？-问题无法回答。了解覆盖是什么，以及适用特定定义/规则/算法的确切条件。要确定CK和NF，我们必须获得形成覆盖的FD。有时是最小/不可约覆盖。[请参见此答案。] (https://stackoverflow.com/a/53386492/3404097) - philipxy

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- philipxy · Accepted Answer

当从一个决定属性中删除一个属性后，关系中仍存在一个FD（函数依赖）时，该FD在该关系中是部分的。如果一个FD不是部分的，则为完全的。

例如：假设 {A，B} → {C} 但也有 {A} → {C}。那么 {A，B} → {C} 是部分的；{C} 对 {A，B} 部分地函数依赖；{C} 在 {A，B} 的一部分上有函数依赖，而不是全部。因此，产生的部分 FD 不是 {A} → {C}。是否是部分的取决于（根据部分FD的定义）是否有一个子集 {A} 确定 {C}，即 {} → {C}。

例如：这里有一个关系 value，其中满足该示例条件。（当一个FD在每个可能出现的值中都成立时，它才在关系 variable 中成立。）

非平凡的函数依赖包括：{A,B}决定{C}，{B,C}，{A,C}和{A,B,C}；{A}，{B}和{}也决定{C}。其中：{A,B}→{C}是关于{A}→{C}，{B}→{C}和{}→{C}的部分依赖；{A}→{C}和{B}→{C}是关于{}→{C}的部分依赖；其余的是全依赖。

X → Y是完全依赖，如果从X中移除任何属性A意味着该依赖不再存在；也就是说，对于任何属性A ε X，（X - {A}）不能功能上确定Y。如果在X中某些属性AεX被移除并且依赖仍然存在，则函数依赖X→Y是部分依赖；也就是说，对于某些AεX，（X-{A}）→Y。

--数据库系统基础第6版，Ramez Elmasri & Navathe

注意，FD是完全还是部分取决于CK（候选键），更不用说您可能称为PK（主键）的一个CK。

2NF的定义是每个非CK属性都由每个CK完全确定。请注意，唯一的CK是{A,B}，唯一的非CK属性C部分依赖于它，因此此值不符合2NF，并且它是组件/投影的无损连接到{A,B}和{A,C}，{A,B}和{B,C}和{A,B}和{C}上。）

（请注意，该教科书对“传递FD”的定义并没有定义与“传递FD”的标准定义相同的内容。）