第2范式理解候选键

Question

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

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

如果我们选择{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 作为键意味着由 BookID 标识的每一本书只能有一个 GenreID 和一个与其关联的价格：BookID->GenreID、BookID->Price。如果您将 {BookID, GenreID} 定义为键，则将不再强制执行依赖关系 BookID->GenreID、BookID->Price，因为该表允许每本书有多个流派和多个价格。这将违反关于 BookID->Price 依赖关系的 2NF。