第二范式理解候选键

Posted 2023-03-12

【中文标题】第二范式理解候选键

【英文标题】：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。

那些文章无能。你用的是什么教材？

【参考方案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。