部分依赖(数据库)

问题描述 投票:14回答:7

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

database functional-dependencies
7个回答
26
投票

当删除一个确定属性时,保持关系的FD(功能依赖性)是部分的,给出了保持在该关系中的FD。不是部分的FD已满。

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

如果从X中删除任何属性A意味着依赖性不再包含,则函数依赖性X→Y是完全函数依赖性;也就是说,对于任何属性A∈X,(X - {A})在功能上不确定Y.如果某个属性A∈X可以从X中移除并且依赖性仍然成立,则函数依赖X→Y是部分依赖性。也就是说,对于某些A∈X,(X - {A})→Y。

- 数据库系统的基础第六版Ramez Elmasri和Navathe

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

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


5
投票

部分依赖性意味着nonprime属性在功能上依赖于候选键的一部分。 (nonprime属性是不属于任何候选键的属性。)

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

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


2
投票

部分依赖性意味着非主要属性(不构成决定因素的一部分的属性(主键/候选键))在功能上依赖于主键/候选键的一部分/一部分。


2
投票

部分依赖性是当主键必须是候选键并且非主要属性取决于候选键的子集/部分(多于一个主键)时发生的一种功能依赖。

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

卖方(Id,产品,价格)

候选人密钥:Id,产品 非主要属性:价格

Price属性仅取决于Product属性,它是候选键的子集,而不是整个候选键(Id,Product)键。它被称为部分依赖。

所以我们可以说Product-> Price是部分依赖。


1
投票

部分功能依赖性仅与复合键相关。当一个或多个非键属性依赖于主键的一部分时,发生部分功能依赖性。

例:

表:Stud_id,Course_id,Stud_name,Course_Name

其中:主键= Stud_id + Course_id

然后:要确定学生的姓名,我们只使用Stud_id,这是主键的一部分。

{Stud_id} - > {Stud_Name}

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


0
投票

为了达到2NF中的关系,解决了部分依赖性,但是2NF是用于解决任何传递依赖性并且到达3NF(其是操作目标)中的关系的“踩踏石”(C. Date)。然而,对部分依赖最感兴趣的是它是自身传递依赖的特例。 1976年P. A. Berstein阐述了这一点:IF {(x•y)→z但y→z} THEN {(x•y)→y&y→z}。 Berstein的3NF合成器算法不需要区分这两种类型的关系缺陷。


-1
投票

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

功能依赖

对依赖性的分析对属性级别进行操作,即一个或多个属性由另一个属性确定,它位于密钥的概念之前。 '关键的作用是基于决心的概念。 “确定是一种状态,在这种状态下,知道一个属性的价值就可以确定另一个属性的价值。”数据库系统12ed

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

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

但是,根据功能依赖的定义:

(SSN,名字) - >姓氏

这也是一个有效的功能依赖。决定因素(确定另一个属性的属性)称为超级密钥。

完全功能依赖

因此,作为功能依赖性的子集,存在完全功能依赖性的概念,其中考虑了最小的最小行列式。我们将这些简单的最小决定因素统称为一个候选键(在我看来,奇怪的语言怪癖,如向量的概念)。

部分功能依赖

但是,有时候候键中的一个属性足以在关系(没有行的表)中确定另一个属性,但不是全部。那就是当你在一个关系中有一个部分功能依赖时。

© www.soinside.com 2019 - 2024. All rights reserved.