如何设置具有主键和多值属性的表？

Question

我对数据库设计很感兴趣，现在正在阅读相应的文献。 通过这本书，我遇到了一个让我感到不确定的奇怪例子。 有一种关系

在此表中，我们有一个复合主键（StudentID，Activity）。但是ActivityFee部分依赖于表的键（Activity - ＆gt; ActivityFee），因此作者建议将此关系划分为另外两个关系：

现在，如果我们看一下STUDENT_ACTIVITY，Activity就变成了一个外键，关系仍然有一个复合主键。

我们已经得到了整个列定义复合主键的表，可以吗？

如果不是，在这种情况下我们该怎么做？ （可能定义代理键？）

为了消除可能的数据异常，有什么方法可以处理多值属性（在我们的例子中为Activity）？

Answer 1

如果符合您的业务需求，则只包含复合键的表格完全正常。

活动不是多值属性。每个元组的活动都有一个值。

Answer 2

复合候选键没有错。 （如果您的参考文献没有根据候选键进行讨论，即如果它在任何其他情况下谈论主键而不是恰好只有一个候选键，则获取新的参考。）

您的文字将告诉您的设计是好是坏。没有必要担心你注意到某种关系可能是什么＆＃34;坏＆＃34;。那种好的＆＃34;目前正在解决的是＃34;标准化＆＃34;。

＆＃34;活动＆＃34;不是＆＃34;多值属性＆＃34;。 A＆＃34;多值＆＃34;属性是一种非关系概念。该术语经常被错误地用于表示＆＃34;属性＆＃34;在一个非关系的表格中＃34;以某种方式（从未解释过）每个＆＃34; row＆＃34;有一个以上的条目，或者对于具有多个相似部分（set，list，bag，table等）的值的关系表中的列以某种方式（从未解释过）并不适用于说，字符串＆amp;数字，或者对于具有多个不同部分（记录，元组等）的值的关系表中的列，以某种方式（从未解释过）不适用于日期。 （有时甚至误用了一堆具有相似名称和值的属性，应该用一个属性替换，每个原始名称都有一行。）（这些只是不需要的设计的情况。）＆＃34;多值＆＃34;被用作类似误用/滥用的术语"atomic"的反义词。

具有相同（值或）子行的值在列或表中出现不止一次，本身既不好也不坏。再次，您的参考将告诉您什么是好的设计。