database - 第二范式理解候选键

Question

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

文章中here在 customer 表中它说它不在 2NF 中，因为 有几个属性不完全依赖于整个 Customer 表主键。我认为这里是主键它意味着 {customerId,EmployeeId}

如果我们选择 {customerId,employeeId} 作为候选键，那么 Customername、customerCity、PostalCode 仅部分依赖于候选键，因此不在 2NF 中。但是，如果我们将候选键单独视为 customerId，那么 Customer 表中的所有列都完全依赖于 customerId，对吧？(因为 employeeId 依赖于 customerId )。
此外，由于单独的 CustomerId 可以作为候选键，我们能否将 {CustomerId,EmployeeId} 作为候选键，因为候选键不能包含另一个候选键作为它的一部分。

因此如果我们单独将customerId作为候选键，这个表不是2NF形式吗？
但是在文章中它说 2NF 形式的表应该服务于一个目的，这里这个客户表有两个目的。
表示每个员工拜访了哪些客户
识别客户及其位置。
然后感觉这张表不在2NF中。
那么这张表中的候选键是什么呢？

我的第二个问题在 this article

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

谁能帮我更好地理解归一化背后的理论

Answer 1

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

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

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