决定因素和候选键是相同还是不同的东西？

Question

在这里我发现了这个:

定义:数据库表中的决定因素是可用于确定分配给同一行中其他属性的值的任何属性.

示例:考虑具有employee_id,first_name,last_name和date_of_birth属性的表.在这种情况下,字段employee_id确定剩余的三个字段.名称字段不确定employee_id,因为公司可能有多个具有相同名字和/或姓氏的员工.同样,DOB字段不确定employee_id或名称字段,因为多个员工可能共享同一个生日.

候选键的定义是否也适用？

Answer 1

根据我的理解,如果表没有完全标准化,则行列式可能不是候选键.实际上,在描述将非正态数据转换为更有用的标准化形式的过程时,使用单词determinant.

考虑这个(显然是非正常的)表:

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表.

有关更多信息,请参见此处

Answer 2

TL; DR否," 行列式 "和" 候选键 "不是相同的概念.决定因素是FD.CK是一张桌子.我们还可以合理地说,CK是其表的一个决定因素(FD),因为它确定了其中的每个列和列集.

对于表值和变量,并行定义了以下所有术语/概念.当给定业务/应用程序中可能出现的每个表值时,表变量具有FD(函数依赖性),行列式,超级密钥,CK(候选键)或PK(主键)(在可变义上)的实例有那个实例(在表格意义上).

对于列组X和Y,我们可以写X - >ÿ.我们说X是行列式/决定集,Y是确定的函数依赖性(FD)X - > Y的集合.

我们说X在功能上决定 Y和Y 在功能上由 X 确定.我们说X是X - > Y 的行列式.在{C} - > Y中我们说C在功能上决定 Y.在X - > {C}我们说X 在函数上确定 C.当X是Y的超集时,我们说X - > Y是微不足道的.

我们说当X的每个子行值仅出现Y的一个特定子行值时,X - > Y 保持在表T中.或者我们说X - > Y是/ T中的FD .当X是某个FD的行列式时在表T中,我们说X 是/在 T中的决定因素.表中的每个平凡FD都包含在其中.

甲超密钥一个表T的是一组列在功能上确定每一列.一个候选键(CK)是不包含更小的超密钥一个超密钥.我们可以选择一个CK作为主键(PK),然后调用其他CK 备用键(AK).在某个CK中,列是素数.

注意,行列式可以是FD,或者是(表中保存的FD).每个CK都是其表格的决定因素.(但是,在一个表格中,每一列都是一个决定因素:本身,平凡.同样每一列.)

(这些定义不依赖于规范化.表的FD和CK用于规范化.当一个非平凡FD的每个行列式都是超级密钥时,表在BCNF中.)

SQL表不是关系,SQL运算符不是它们的关系/数学对应物.除此之外,SQL还有重复的行,空值和一种3值逻辑.但是,虽然你可以借用术语并赋予它们SQL的含义,但你不能仅仅将这些含义替换为其他RM定义或定理,并获得合理或真实的东西.因此,我们必须将SQL设计转换为关系设计,应用关系概念,然后转换回SQL.在特殊情况下我们可以直接在SQL中执行某些操作,因为我们知道如果我们进行转换,应用和转换会发生什么.

Answer 3

• 主键或任何候选键也是决定因素,而相反的情况则不然.
• 行列式可以唯一地确定行中的一个或多个属性.
• 候选键可以唯一地确定整行.

从这里举一个例子,让我们有一个包含以下列的表:

客户#,姓名,地址,信用,销售代表#,销售代表名称

并且让我们说Sales Rep #可以唯一地确定Sales Rep Name.因此,Sales Rep #是Sales Rep Name该表的决定因素但不是该表的候选键.