多值属性可以有主键吗？答案

【问题标题】：Can a multivalued attribute have a primary key?多值属性可以有主键吗？
【发布时间】：2015-08-22 06:04:14
【问题描述】：

函数依赖是其值由另一个属性以唯一方式确定的属性。鉴于此，多值属性可以依赖于主键吗？

【问题讨论】：

当然！您可以只创建一个代理键
代理键是没有商业意义的键。可以举个例子吗？
您关于业务意义的陈述需要一个星号。从数据库的角度来看，它们非常漂亮。这个想法只是为某些数据行提供唯一的 ID。如果您选择的主键是 eh... 这使您可以更轻松地跨表建立这些关系，因为它是数字而不是等等。除非您的问题没有完全定义，否则这将在您的情况下完美运行。
我正在尝试规范化我的数据库方案，并通过函数依赖公理从理论上证明我的数据库方案是正确的。所以我遇到了一个多值属性（在我的方案中——我想证明的那个——是一个不同的表），我试图弄清楚主键是否决定了多值属性。
您的问题错误而奇怪地使用了技术术语。尝试提出一个最小的设计及其理由来显示您的问题（根据您正在使用的流程和定义）。重新设计见the "educate yourself" section of this answer。

标签： database database-design primary-key functional-dependencies

【解决方案1】：

“FD 是其值由另一个属性以唯一方式确定的属性”难以理解。想办法正确地说出来，或者你怎么理解？
一个属性（或一组属性）在功能上由一组属性决定。
关系中不存在“多值属性”之类的东西。元组的每个属性名称都有一个属性值。（也许您的意思是，正在确定一组属性？也许您的意思是，一个多值依赖项？）如果您有一个您考虑包含多个部分的属性，即您想要通用查询在不使用带有类型参数的运算符的情况下，为这些部分创建一个单独的表通常是好的设计。但这并没有通过标准化来解决。任何值可以被认为具有多种方式的多个部分，它是您的应用程序/查询决定何时停止制作其属性是其他值的部分值并且仅具有一个属性的表价值。同样，如果您有一堆扮演相似角色的属性（通常具有相似的名称），那么通常良好的设计有一个单独的表，其中只有一个属性用于角色。但这并没有通过标准化来解决。
候选键对 FD、MVD、JD 和规范化很重要。 PK没有。您可以选择一个 CK 作为“PK”，但它的首要性与关系模型无关。它可能与某些信息建模方法或产品有关。
超级键是确定每一列的列集。由于每组属性总是确定其中的属性，因此超级键是确定其他列的列集。 CK 是不包含更小的超级密钥的超级密钥。（因此 CK 是唯一的列集，但不包含更小的唯一列集。）
在找到所有 FD 之前，您不会知道所有 CK。但是您可能知道一组特定的属性是唯一的，并且没有更小的唯一集，因此您知道它是一个 CK，您可以将其称为“PK”。（例如，关系变量中的 id 属性可以有多于一行。）

多值属性可以依赖于主键吗？

根据 CK 的定义，每个属性都依赖于每个 CK。因此，根据 PK 的定义，每个属性都依赖于每个 PK。（但您必须澄清“多值属性”和“依赖”的含义。）

【讨论】：