第2范式理解候选键

Question

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

文章here 在客户表中，它表​​示它不在2NF中，因为there are several attributes which don’t completely rely on the entire Customer table primary key。这里的主键我认为它意味着{customerId，EmployeeId}

如果我们选择{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 那么这张表中的候选键是什么？

我的第二个问题是this article

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

有人可以帮助我更好地理解正常化背后的理论

Answer 1

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

在第一种情况下，你是对的如果 CustomerID是Customer表的唯一候选键，那么它将满足2NF。但是，在这种情况下，每个CustomerID只能有一个EmployeeID - 换句话说：CustomerID-＆gt; EmployeeID。我希望这个例子的重点是不止一个员工可以向同一个客户销售，因此如果EmployeeID包含在同一个表中，单独的CustomerID就不足以作为候选密钥。这不是示例数据中显示的内容，但事实上暗示{CustomerID，EmployeeID}被声明为此表的关键而不是CustomerID。

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