通过常识确定候选键？答案

【问题标题】：Determining candidate keys by common-sense?通过常识确定候选键？
【发布时间】：2019-05-02 06:20:38
【问题描述】：

我有下表：

Book_Name       Author  Edition Year
DB_fundamentals Navathe 4       2004
DB_fundamentals Elmasri 4       2004
DB_fundamentals Elmasri 5       2007
DB_fundamentals Navathe 5       2007

在没有任何知识的情况下，我必须确定可能的候选键。显然它将是 {Book_Name, Author, Edition}。从我教授的解决方案来看，这是正确的。但我会更进一步说 {Book_Name, Author, Year} 也是正确的。但在这方面，他说“我们应该考虑到某些书籍可能有一个发行周期，这会导致在给定年份出现多个版本。”但是为什么有人（像他所说的那样来自“常识”）在同一年（或根本）发行两本或更多同名和版本的书籍？

你们怎么看这件事？没看懂。

【问题讨论】：

“但为什么会有人……” - 因为它在同一年内售罄并再次重印？
但那不就是一个新版本吗？比如“4.5 版”或“4 v2 版”之类的？
我不知道。对我来说，“新”版本意味着发生了一些变化（例如，添加了新章节，旧章节被改写（因为它不再有效）。如果没有任何变化，那仍然是相同的版本。但是，我对此一无所知，所以我们只是聊天。
我的意思是，那是主观的。这个问题只是愚蠢地问，imo，你同意吗？
如果教授的意图是让你考虑一下，我猜他们成功了。可能没有明确的答案。也许他们是对的，也许你是对的，也许两者都是。也许这并不重要，只要你理解一般的候选键的想法。

标签： database relational-database data-modeling functional-dependencies candidate-key

【解决方案1】：

图书版本可能会唯一标识正在发行的图书。 year 大概是发布年份。

如果数据代表“我们的仓库正在运送哪些书籍”，那么您的解释是正确的。在这种情况下，一个版本可能会在多年后发布。

教授显然在想“什么书已经出版了”。

换句话说，在不知道表格的用途的情况下，您无法真正指定。有时目的从数据中“显而易见”，但不一定。

【讨论】：