我对数据库设计很感兴趣，现在正在阅读相应的文献。 通过这本书，我遇到了一个奇怪的例子，让我感到不确定。 有关系
在此表中，我们有一个复合主键（StudentID、Activity）。但是ActivityFee部分依赖于表的key（Activity -> ActivityFee），所以作者建议把这个关系分成另外两个关系：
现在如果我们看一下 STUDENT_ACTIVITY，Activity 变成了一个外键，而关系仍然有一个复合主键。
我们有一个表，其中所有列都定义了一个复合主键，可以吗？
如果不是，在这种情况下我们应该怎么做？ （可能定义一个代理键？）
为了消除可能的数据异常，处理多值属性（在我们的例子中是 Activity）的好方法是什么？
【问题讨论】：
标签： database database-design relational-database relational-model
如果符合您的业务需求，只包含复合键的表是完全可以的。
Activity 不是多值属性。每个元组都有一个活动值。
【讨论】：
复合候选键没有任何问题。 （如果您的参考资料没有提及候选键，即如果它在任何其他情况下谈论主键，而不是碰巧只有一个候选键，请获取新参考。）
你的文字会告诉你什么是好的和坏的设计。不必担心您注意到的每个属性都可能是“坏的”关系。它目前正在处理的那种“好”是由“规范化”给出的。
“活动”不是“多值属性”。 “多值”属性是一个非关系概念。该术语经常但错误地用于表示非关系“表”中的“属性”，以某种方式（从未解释过）每个“行”具有多个条目，或者关系表中的列具有具有多个相似部分（集合、列表、袋子、表格等）的值，不知何故（从未解释过）不适用于字符串和数字，或关系表中具有多个值的列以某种方式（从未解释过）不适用于日期的不同部分（记录、元组等）。 （有时它甚至被误用为具有相似名称和值的一组属性，应该将其替换为每个原始名称对应一行的单个属性。）（这些只是不需要的设计的情况。）“多值”得到用作类似滥用/滥用术语"atomic" 的反义词。
在列或表中多次出现相同（值或）值的子行本身既不好也不坏。同样，您的参考资料会告诉您什么是好的设计。
【讨论】：