第二范式理解候选键答案

【问题标题】：2nd Normal Form understanding candidate key第二范式理解候选键
【发布时间】：2015-02-05 09:14:27
【问题描述】：

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

在文章here 在 customer 表中它说它不在 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。

有人可以帮助我更好地理解规范化背后的这个理论

【问题讨论】：

FD 确定 CK。您无法“选择” CK。 CK 是确定所有其他列的列集。您决定将行放入表中的标准。然后给定所有可能出现的情况，每个列子集（非平凡）确定 0 个或更多列，即从集合到列是否存在 FD。
那些文章无能。你用的是什么教材？

标签： database normalization database-normalization candidate-key

【解决方案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。

【讨论】：