我對數據庫設計感興趣，現在閱讀相應的文獻。 通過這本書，我遇到了一個讓我感到不確定的奇怪例子。 有一個關係如何設計具有主鍵和多值屬性的表格？
在此表中，我們有一個複合主鍵（StudentID，活動）。但是ActivityFee是部分依賴於表的鍵（活動 - > ActivityFee），所以筆者建議這種關係劃分爲另外兩個關係：
現在，如果我們來看看STUDENT_ACTIVITY，活動成爲外鍵，關係仍然有一個複合主鍵。
我們已經有了整個列定義複合主鍵的表，它可以嗎？
如果不是，我們該怎麼辦？ （可能定義代理鍵？）
什麼是處理多值屬性（我們的情況下的活動）的一種好方法，以消除可能的數據異常？
複合候選鍵沒有問題。 （如果您的參考不以候選鍵的方式進行交談，即，如果在任何其他情況下談論主鍵，而不是恰好只有一個候選鍵時，請獲取新的參考。）
您的文本將會告訴你是好是壞設計。沒有必要擔心你注意到關於它可能是「壞」的關係的每一個屬性。目前正在解決的那種「好」是由「正常化」給出的。
「活動」不是「多值屬性」。一個「多值」屬性是一個非關係的概念。該術語經常被錯誤地用來表示非關係型「表」中的「屬性」，它以某種方式（從未解釋過）每個「行」有多個條目，或者關係表中的列有具有多個類似部分（集合，列表，包，表等）的值不適用於說，字符串&數字或關係表中具有多個值的列不同的部分（記錄，元組等）以某種方式（從未解釋過）不適用於日期。 （有時甚至誤用了一些具有相似名稱和值的屬性，這些屬性應該被一個屬性替換爲每個原始名稱的行。）（這些只是不想要的設計的例子。）「多值」獲取用作類似濫用/濫用術語"atomic"的反義詞。
在列或表中出現多次相同的值（值或）的值不止一次，本身也不是好的或壞的。再次，您的參考將告訴您什麼是優秀的設計。
如果您的業務需求與您的業務需求相匹配，那麼僅包含複合關鍵字的表格完全可以。
活動不是一個多值屬性。每個元組的活動都有一個值。