Here我发现了这个:
定义:数据库表中的决定因素是可用于确定分配给其他值的任何属性 属性在同一行。
示例:考虑具有employee_id,first_name,last_name和date_of_birth属性的表。在这种情况下,该字段 employee_id确定剩余的三个字段。名称字段 不确定employee_id,因为公司可能有多个 具有相同名字和/或姓氏的员工。同样,DOB 字段不确定employee_id或名称字段,因为 不止一个员工可以分享同一个生日。
这个定义是否也适用于候选键?
答案 0 :(得分:16)
根据我的理解,如果表没有完全标准化,则行列式可能不是候选键。事实上,在描述将非正态数据转换为更有用的标准化形式的过程时,会使用决定因素这个词。
考虑这个(显然是非正常的)表:
CREATE TABLE US_Address (
AddressID int,
Streetline varchar(80),
City varchar(80),
State char(2),
ZIP char(5),
StateName varchar(80),
StateTax DECIMAL(5,2)
)
State是StateName和StateTax的决定因素,但它不是该行的候选键。 因此,正确的规范化会将StateName和StateTax移出US_Address表并移入States表。
有关详细信息,请参阅here。
答案 1 :(得分:7)
TL; DR 否," 决定因素"和" 候选键"是不一样的概念。决定因素是FD 的。 CK是表的。我们还可以合理地说,CK是其表的一个决定因素(FD),因为它决定了每一列和一个列。列中设置了它。
以下所有术语/概念是针对表值和变量并行定义的。表变量具有FD的实例(功能依赖),决定因素,超级密钥,CK(候选密钥)或PK(主键)(在可变意义上)当给定业务/应用程序中可能出现的每个表值具有该实例时(在表意义上)。
对于X和Y列,我们可以写 X - > ÿ。 我们说X是决定因素/确定集,Y是功能依赖中确定的 FD )X - >收率强>
我们说X 在功能上确定 Y和Y 在功能上由 X确定。我们说X是 X的决定因素 - > Y.在{C} - >我们说C 在功能上确定 Y.在X - >中{C}我们说X 在功能上确定 C.当X是Y的超集时,我们说X - > Y是琐碎的。
我们说X - >当X的每个子行值仅出现Y的一个特定子行值时,Y 保持在表T中。或者我们说X - > Y是/
表T的超级密钥是一组功能上确定每列的列。 候选键( CK )是一个超级密钥,不包含任何较小的超级密钥。我们可以选择一个CK作为主键(< em> PK )然后调用其他CK 备用密钥( AKs )。当某个列在某个CK中时,列是 prime 。
请注意,行列式可以是FD 的,也可以是(表中的FD)()。 每个CK都是其表格的决定因素。(但是,在表格中每个列都是一个决定因素:本身,非常简单。同样每个< / em>专栏。)
(这些定义不依赖于规范化。表的FD和CK用于归一化。当一个非平凡FD 的每个行列式中的表是在BCNF中时超级密钥。)
SQL表不是关系,SQL运算符不是它们的关系/数学对应物。除其他外,SQL有重复的行,空和&amp;一种3值逻辑。但是,虽然你可以借用术语并赋予它们SQL的含义,you can't just substitute those meanings into other RM definitions or theorems and get something sensible or true。所以我们必须convert an SQL design to a relational design, apply relational notions, then convert back to SQL。在某些特殊情况下,我们可以直接在SQL中执行某些操作,因为我们知道如果我们进行转换,应用和扩展会发生什么。转回来。
答案 2 :(得分:6)
以here为例,让我们有一个包含以下列的表:
客户#,名称,地址,信用,销售代表#,销售代表名称
并且让我们说Sales Rep #
可以唯一地确定Sales Rep Name
。因此,Sales Rep #
是Sales Rep Name
的决定因素,但不是此表的候选键。