database - 第二范式理解候选键

Question

为了理解什么是第二范式，我阅读了一些文章，有些东西我不明白。

在客户表中的文章 中，它说它不在 2NF 中，因为.这里的主键我认为它的意思是 {customerId,EmployeeId}there are several attributes which don’t completely rely on the entire Customer table primary key

如果我们选择 {customerId,employeeId} 作为候选键，那么 Customername,customerCity,PostalCode 确实仅部分取决于候选键，因此不依赖于 2NF。但是，如果我们将候选键单独视为 customerId，那么 Customer 表中的所有列都完全依赖于 customerId 对吗？（因为 employeeId 依赖于 customerId ）。
同样，由于CustomerId单独可以是候选键，我们可以将 {CustomerId,EmployeeId} 作为候选键，因为候选键不能包含另一个候选键作为其一部分。

因此，如果我们仅将 customerId 作为候选键，该表不是 2NF 形式吗？
但是在文章中它说 2NF 形式的表应该服务于一个目的，这里这个客户表有两个目的。
To indicate which customers are called upon by each employee To identify customers and their locations.
然后我感觉这张表不在2NF。
那么这个表中的候选键是什么？

我的第二个问题在这篇文章中

这些表在 3NF 中。在表 TABLE_BOOK 中，候选键是 bookId 对吗？我们不能选择 {bookId,genereId} 作为候选键，对吗？如果选择它就不会在 2NF 中，因为价格不依赖于genreId。

有人可以帮我更好地理解标准化背后的这个理论吗

Answer 1

您的两个问题都表明了此类练习的局限性。除非您事先知道或可以确定相关的业务规则，否则您无法进行有效的数据库设计或应用规范化原则。在现实生活中的数据库设计情况下，您可以通过采访主题专家并调查现有系统和流程来确定业务规则。在网站上的一个草图示例中，您所要做的只是几行示例数据以及一些可能不明确的属性和表名称。以这种方式得出的解决方案必然是假设性的，而且往往是不精确和主观的。

在第一种情况下，您是对的，如果CustomerID 是 Customer 表的唯一候选键，那么它将满足 2NF。但是，在这种情况下，每个 CustomerID 只能有一个 EmployeeID - 换句话说：CustomerID->EmployeeID。我希望该示例的重点是，可能有多个员工向同一个客户销售产品，因此如果 EmployeeID 包含在同一个表中，仅 CustomerID 不足以作为候选键。这不是示例数据中显示的内容，但它暗示 {CustomerID, EmployeeID} 被声明为该表的键而不是单独的 CustomerID。

第二个例子与第一个非常相似。选择BookID作为key意味着BookID标识的每一本书只能有一个GenreID和一个与之关联的价格：BookID->GenreID，BookID->Price。如果您将 {BookID, GenreID} 定义为键，则不再强制执行依赖关系 BookID->GenreID, BookID->Price，因为该表将允许每本书有多个流派和多个价格。这将违反关于依赖 BookID->Price 的 2NF。