了解数据库规范化 - 第二范式（2NF）答案

【问题标题】：Understanding Database Normalization - Second Normal Form(2NF)了解数据库规范化 - 第二范式（2NF）
【发布时间】：2016-10-31 12:27:14
【问题描述】：

我一直在学习“Elmasri 和 Navathe 的数据库系统基础（第 6 版）”中的规范化，但我无法理解以下关于 2NF 的部分。

下图是教科书2NF下给出的例子

候选键是{SSN,Pnumber} 依赖项是 SSN,Pnumber -> 小时, SSN -> ename, pnumber->pname, pnumber -> 位置

正式定义：

A relation schema R is in 2NF if every nonprime attribute A in R is
fully functionally dependent on the primary key of R.

例如上图：

如果假设，我定义一个额外的函数依赖 SSN -> 小时，然后取两个函数依赖，

{SSN,Pnumber} -> hours and SSN -> hours

关系不会是 2NF，因为现在 SSN ->hours 现在是部分函数依赖，因为 SSN 是给定候选键 {SSN,Pnumber} 的真子集。

查看2NF上的关系及其一般定义，我假设上述关系在2NF中

就我的理解以及我如何理解 2NF 是什么而言，

A relation is in 2NF if one cannot find a proper subset (prime attributes)
of the on the left hand side (candidate key) of a functional dependency 
which defines the NPA(non prime attribute).

我的第一个问题是，为什么上述关系不在 2NF 中？（教科书已将上述关系视为不在2NF中）

然而，本章开头定义了一种非正式的方法（根据教科书的步骤，一个不知道规范化的普通人可以采取哪些步骤来减少冗余）是：

■ Making sure that the semantics of the attributes is clear in the schema
■ Reducing the redundant information in tuples
■ Reducing the NULL values in tuples
■ Disallowing the possibility of generating spurious tuples

提到的指导方针如下：

我的第二个问题是，如果考虑到上述步骤，并考虑为什么以下关系不在 2NF 中，您是否假设以下函数依赖关系，即，

{SSN,Pnumber} -> Pname
{SSN,Pnumber} -> Plocation
{SSN,Pnumber} -> Ename

使关系的分解正确吗？如果假设的函数依赖不正确，那么导致该关系不满足 2NF 条件的因素是什么？

从一般的角度来看...因为该表包含多个主要属性并且存储的信息与员工和项目信息有关，因此可以指出这些需要分开，因为 Pnumber 是作为复合键的主要属性，可以直观地猜出冗余。这是因为我们知道属性的语义。

如果属性被替换为 A,B,C,D,E,F 会怎样

我的第三个问题是，功能依赖关系是否基于“数据库的功能和具有属性领域知识的数据库设计者”预先确定？

因为基于给定点的数据和关系状态，函数依赖关系可以改变，在一个状态下有效的函数在某个状态下可能会失效。一般来说，这可以说是任何非主属性决定非主属性。

正式定义：

A functional dependency, denoted by X → Y, between two sets of
attributes X and Y that are subsets of R specifies a constraint on the 
possible tuples that can form a relation state r of R. The constraint is     
that, for any two tuples t1 and t2 in r that have t1[X] = t2[X], they must 
also have t1[Y] = t2[Y].

那么预定义函数依赖会不会是错误的，因为在任何给定点上都不能泛化关系状态？

如果我对事物的基本理解一开始就有缺陷，请原谅我。

【问题讨论】：

Re "如果假设，{SSN,Pnumber} -> hours and SSN -> hours 这种关系不会在 2NF 中，因为现在 SSN ->hours 是部分函数依赖关系" 这种推理是不正确的，除非您添加它是候选键上的非主属性。但孤立的 FD 并不意味着 2NF。
@philipxy 如果您可以编辑该问题，如果它无法被其他人理解，我会很高兴......我会确保您所做的编辑是否传达了我手头的问题。因为我一直在努力寻找答案并澄清我的疑问。
但是由于 SSN 是候选键的真子集，假设 {SSN, Pnumber} 是上述关系的候选键，那么当 { SSN, Pnumber} 在功能上确定小时数？
您上一条评论的问题很困惑： 1. PK 无关紧要。忘记他们。 PK 是您称为 PK 的 CK。 2. CK 不是 FD。 3. 主属性 = 某些 CK 的属性。 4. 当您被告知某些 FD 持有时，某些其他 FD 也持有。 5. 所以：查找/接收一些持有和不持有的 FD。然后某些规则给出了当持有的 FD 时也必须持有的所有 FD。然后在确定每个 FD (set -> set) 是否持有之后，确定持有和不持有的 FD 的 CK。那么你有 2NF 当且仅当没有非主属性部分依赖于 CK。
我不知道你在括号里想表达什么。（也许“你需要假设”你的意思是“暗示”。）要显示 2NF 所有 FD，必须考虑到。教科书可以明确并说“在这些示例中，唯一持有的FD是给定的，由于给定的CK而持有的FD以及那些隐含的FD（即从那些得出的，即当那些做的时候也必须成立）。”但要证明 2NF 是违反，您只需要找到 1 个错误的 FD。所以在这里了解CK & FD2 或FD3 就足够了。别人持有什么并不重要。为什么会这样？

标签： database database-design relational-database database-normalization

【解决方案1】：

为什么上面的关系不在2NF中？

您对 2NF 的原始/第一个/非正式“定义”是乱码，没有帮助。甚至教科书中的引用也是错误的，因为 2NF 不是根据“PK（主键）”定义的，而是根据所有 CK（候选键）定义的。（如果只有一个 CK，他们的定义是有意义的。）

当非主属性对 CK 没有部分依赖时，表处于 2NF。即，当非主属性的行列式不是 CK 的适当/较小子集时。即，当每个非主属性在功能上完全依赖于每个 CK。

这里唯一的 CK 是 {Ssn, Pnumber}。但是 {Ssn} 和 {Pnumber} 中有 FD（功能依赖），它们都是 CK 的较小子集。所以原表在2NF中不是。

如果考虑到上面的说法，你是否假设以下函数依赖关系

所以每次这样的案例到来时，单独基于非正式方式显示的分解过程不会很困难吗？

一个表包含使某些谓词（由列名参数化的语句模板）成为真正的命题（语句）的行。给定业务规则，只能出现某些业务情况。然后给定表谓词，从业务情况中给出表值，只能出现某些数据库值。这导致某些表具有某些 FD。

但是，鉴于某些 FD 成立，我们可以正式使用 Armstrong 公理 来获得所有其他也必须成立的 FD。所以我们可以使用非正式和正式的方式来找出哪些 FD 持有和不持有。

公理也有一些速记规则。例如，如果一组属性在每个元组中具有不同的子行值，那么它的每个超集也是如此。例如，如果 FD 成立，则其行列式的每个超集确定其确定集的每个子集。例如，超级密钥的每个超集都是超级密钥，并且 CK 的任何真子集都不是 CK。还有算法。

是否基于“数据库的功能和具有属性领域知识的数据库设计者”预先确定了功能依赖关系？

在规范化时，我们关心无论业务情况如何，即数据库状态如何，FD 都保持不变。每个业务的每个表都可以根据表谓词和可能的业务情况有自己特定的 FD。

PS 当正式事物的定义是根据现实世界时，请根据现实世界来“理解”正式事物。例如，将谓词应用于所有可能的情况以获取所有可能的表值。但是一旦你有了必要的正式信息，就只能使用正式的定义和程序。例如，确定一个 FD 对一个表适用，因为它适用于所有可能的表值。

那么基于具有复合主键的表的单独条件，任何通用表都属于 2NF 吗？

在 5NF 中有一些表格（因此也有所有较低的 NF），其中包含各种复合和非复合 CK 的混合。 PK无所谓。

经常错误地说，没有复合 CK 可以保证 2NF。没有复合键且 {} 不确定任何属性的表在 2NF 中。但是，如果 {} 确定一个属性，那么它是任何/每个具有任何属性的 CK 的适当/较小子集。 {} 在每一行都必须具有该属性的相同值时确定该属性。

【讨论】：

我已经用正式定义编辑了这个问题，并展示了一个关于部分依赖的例子
@WSimpson 指出了与您的论点类似的东西，所以您能否澄清我为他发布的问题，那么我是否正确假设表是否具有复合主键，而不管功能依赖关系如何不在 2NF 中？
因为规范化的重点是减少基于函数依赖的冗余，所以任何通用表都可以基于具有复合主键的表的单独条件处于 2NF 中吗？
我被教过 BCNF，在阅读教科书时，我发现了这个例子，我一直在思考这个例子......这导致了这些问题：D......我将研究 4NF 和 5NF ..谢谢你:)
有时要学习摘要，您需要多个实际应用示例。重点是学习如何准确定义可应用于多个现实世界场景的模型。如果试图理解模型的人没有完全理解或对所使用的术语有误解。然后需要一个真实世界或非正式的解释，以确保他们能够理解正式术语的正确含义。

【解决方案2】：

为什么上面的关系在 2NF 中？

EP1、EP2 和 EP3 属于 2NF，因为对于每一个，密钥标识非密钥。任何键的任何部分都不能标识任何非键的任何部分。这就是 对于 r 中具有 t1[X] = t2[X] 的任何两个元组 t1 和 t2 的含义，它们也必须具有 t1[Y] = t2[Y]。 p>

相比之下，您可能会说 EMP_PROJ 是过度指定的。如果ssn 标识为ename（如文中所说），则 {ssn, pnumber} 的组合太多了。存在标识非密钥 {ename} 的一部分的密钥 {ssn,pnumber} 的子集。这种情况不会出现在符合 2NF 的表中，如 EP1、EP2 和 EP3 所示。

功能依赖...是否基于...属性的领域知识？

强调，是的！这就是他们的全部基础。 DBMS 只是一个逻辑机器。 “员工”和“小时”的概念并不存在。数据库设计者选择定义模拟现实世界话语世界的表，并为列赋予意义。他为 X 和 Y 中的属性（上图）命名。他根据正在建模的宇宙的真实情况来决定哪些列用于标识行。

如果一个表有复合主键，不管函数依赖是不是在2NF？

没有。请记住，2NF 是根据 FD 定义的。说“不管”他们是否符合 2NF 意味着什么？

键中的列数无关紧要。它是一些集合，X，标识补码，Y。

【讨论】：

对不起，我在打字时错过了第一个问题中的“不是”，如果他们说任何具有复合主键的表不在 2NF 中，我试图挑战他们：D .. 对此感到抱歉.. .. 如果有助于澄清我的问题，我已经添加了一个正式的定义并在我的示例中说明了部分功能依赖。
我希望您理解该主题，但您写的内容有些问题。例如，“EP1、EP2 和 EP3 在 2NF 中，因为对于每一个，密钥标识非密钥。”不，因为 CK 总是标识非 CK（和 CK）属性。例如“任何键的任何部分都不能标识任何非键的任何部分。这就是 r 中具有 t1[X] = t2[X] 的任何两个元组 t1 和 t2 的含义，它们也必须具有 t1[Y ] = t2[Y]。"不，第 1 句是关于 2NF，但第 2 句是关于 FD。

【解决方案3】：

我不确定我是否完全理解你的问题，但我会尝试解释一下。

你关于 2NF 的第一个陈述：

如果在定义 NPA 的函数依赖的左侧找不到适当的子集，则关系处于 2NF 中

是正确的，以及你的假设

如果 {SSN,Pnumber} -> hours 和 SSN -> hours 那么这个关系不会在 2NF 中

因为这意味着您可以单独从“SSN”确定“小时”，因此使用复合键 {SSN,Pnumber} 来确定“小时”将是多余的，因此违反了 2NF 要求。

FD 的左侧通常称为键。您使用密钥查找相关数据。为了节省空间（并降低复杂性），您应该始终尝试找到一个最小键，并尽可能将较大的表分解为较小的表，这样您就不必将信息保存在不必要的位置。这就是范式归一化的意义所在，经过近半个世纪的研究，已经形成了关于这个问题的大量理论，并从中结晶了一些规则，如 1NF、2NF、3NF 等。

你的第二个问题让我很困惑，因为从你所说的来看，你似乎已经明白了这一点。会不会对 FD 有一些混淆？从图中，在我看来，它们是这样定义的：

{SSN,Pnumber} -> 小时
{SSN} -> 姓名
{Pnumber} -> Pname，位置

就像下面的三个表被建模一样，它们加起来就是上面建模的关系（表）。因此，在第一个表中，您需要组合键 {SSN,Pnumber} 来访问关系中的任何数据（在表中搜索），而对于大多数字段来说显然不是必需的。

现在，我不确定这张桌子在现实生活中的用途。虽然这在形式上不是必需的，但只要给出 FD，就可能更容易想象为什么设计会从规范化中受益。

让我们开始吧，记录某个组织中每个项目的每个员工的工作时间。 SSN 标识员工，（其姓名也被存储为 ename，因为它更容易记住，但可能重复），Pnumber 标识项目，其名称和位置也出于相同的原因存储很多。

然后，如果您作为经理需要注册某个员工在某个项目上又工作了几个小时，您将在您的设备上使用您的经理应用程序，这反过来会无缝更新表格（您不能指望经理了解逻辑归一化）

然而，在幕后，它相当于一些查询，在 SQL 中，这将是一个“INSERT”语句，它将另一行添加到相关表中。

现在您可以看到，在上表中，您必须插入所有六个属性，而对于下面的规范化表，您只需向表 EP1 添加一行，由三个属性组成。在每周都有数千名员工交付工作表的大型组织中，这将很快成为存储需求的巨大差异。这有很多好处，也许是最重要的蜜蜂搜索速度。

恐怕你的第三个问题我根本不明白。从某种意义上说，一旦您决定将哪些数据保存在数据库中，您就可以说 FD 是预先确定的。 FD 不会改变。在数据库中建模时，它们不会改变。如果你后来发现你会改变设计，那将是与新 FD 的新关系。

您似乎从某处引用的文本只是说，如果您有 FD X -> Y（X 给出或确定 Y），那么如果您在该关系（表）中有任何两个元组（记录）具有X 的值相同，它们也必须具有相同的 Y 值。或者在我们的示例中，如果某处的 Pnumber 的值是 888，则 Pname 是“Battleship”，而 Plocation 是“Kitchen Sink”，那么如果其他地方（其他一些记录）使用 Pnumber 888，那么 Pname 必须是“Battleship”，Plocation 必须是“Kitchen Sink”，因为 Pname 和 Plocation 在功能上取决于 Pnumber。

现在这几乎是您教科书中的另一章，还是什么？希望它有所帮助，因为我花了一些时间来写:-)

【讨论】：

FD 的 LHS 是“行列式”。只有一些 FD 的行列式是 CK。
感谢您不厌其烦地理解问题..我已经进行了编辑..您能再检查一下问题吗？
嗨，看来您已经在这里获得了很多合格的帮助。如果您希望我回答特定问题，请在另一条评论中输入。祝你的课程好运！

【解决方案4】：

一个表可以说是 2NF，如果主键由多个列组成，并且如果对于每一行，这些列连接在一起成为一个字符串，那么结果列将有资格作为主键。或者，单列主键也符合 2NF。

在这种情况下，同一员工可能有多个电话号码 (PNUMBER)，因此您不能拥有包含电话号码的复合主键。

【讨论】：

那么我是否正确假设一个表是否有一个复合主键，而不管功能依赖关系是否不在 2NF 中？
请注意，我不会像他们那样划分表格。根据您上面的内容； ssn、pnumber 和 hours 合并到一个表中，而 ssn 和 ename 在另一个表中。可能应该发生的是应该有一个班次表，其中包含小时的可用值。然后应将 SSN 映射到一张表中的 ename 和 hours。另一个和最后一个表中的 ssn 和 pnumber 可以是 pnumber、pname 和 plocation。虽然没有更多上下文，但我不确定最后一张表的目的。
@WSimpson & @PagadalaVikramaditya `。规范化不添加列。 2. Ssn 应该不“映射到一个表中的 ename 和 hours”。由于 {Ssn} 是 CK {Ssn, Pnumber} 的一个真子集，决定了 ename，因此该表不会在 2NF 中。自己应用正式定义以查看此内容。
其实我读这个的方式，小时是定义班次，这意味着它实际上是班次的开始和结束值，这意味着小时列实际上是一个两列的表.因此 ssn, pnumber, hours 表不是 1NF。
@WSimpson (& @PagadalaVikramaditya) 您已获得属性和 FD。那时，流程是正式的，表格的含义并不重要。你的提议与你得到的相矛盾。那个设计不错例如，您的“这意味着……”重新工作时间是错误的。它可以是总小时数、开始时间或结束时间，并且在功能上取决于该 CK。你似乎不明白什么是标准化。关于“1NF”和“原子”（关于这很多废话）见this。