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

Question

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

以下图片是教科书中2NF下给出的一个例子

候选键是{SSN，Pnumber} 依赖是 SSN，Pnumber - ＆gt;小时，SSN - ＆gt; ename，pnumber-＆gt; pname，pnumber - ＆gt; plocation

正式定义：

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 - ＆gt;小时，然后采取两个功能依赖，

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

关系不会在2NF，因为现在SSN - >小时现在是部分功能依赖，因为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].

所以不会预定义函数依赖是错误的，因为on不能在任何给定点概括关系状态吗？

请原谅我，如果我对事物的基本理解是有缺陷的。

Answer 1

  

为什么上述关系不在2NF？

您的原创/第一/非正式＆＃34;定义＆＃34; 2NF是乱码，没有帮助。甚至教科书中的引用都是错误的，因为2NF没有用＆＃34; PK（主键）＆＃34;来定义。而是在所有CK（候选键）方面。 （如果只有一个CK，他们的定义是有意义的。）

当CK上没有非素数属性的部分依赖性时，表在2NF中。即，当非主要属性的决定因素不在CK的某个适当/较小的子集上时。即每个非素数属性在功能上完全依赖于每个CK。

唯一的CK是{Ssn，Pnumber}。但是在{Ssn}和{Pnumber}中存在FD（功能依赖性），这两者都是CK的较小子集。所以原始表在2NF中不是。

  

如果考虑上述陈述，您是否假设以下功能依赖

  

所以，每次这样的情况到来时，单独以非正式方式显示的分解过程是否很困难？

一个表保存将一些谓词（由列名参数化的语句模板）转换为真正的命题（语句）的行。根据业务规则，只会出现某些业务情况。然后给定表谓词，它从业务情境中提供表值，只会出现某些数据库值。这导致某些表具有某些FD。

然而，考虑到一些持有的FD，我们可以正式使用 Armstrong的公理来获得必须持有的所有其他FD。因此，我们可以使用非正式和正式的方式来查找哪些FD持有并且不会持有。

公理也有简写规则。例如，如果一组属性在每个元组中具有不同的子行值，那么它的每个超集也是如此。例如，如果FD保持，则其行列式的每个超集确定其确定的集合的每个子集。例如，超级钥匙的每个超集都是一个超级钥匙＆amp;没有适当的CK子集是CK。有算法。

  

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

当规范化时，无论业务情况如何，我们都关注持有的FD，即数据库状态是什么。每个企业的每个表可以根据表谓词和放大器具有其自己的特定FD。可能的商业情况。

PS Do＆＃34;有意义＆＃34;当他们的定义是关于现实世界的时候，就现实世界来说是正式的事物。例如，将谓词应用于所有可能的情况以获取所有可能的表值。但是，一旦获得必要的正式信息，只能使用正式的定义和程序。例如，确定FD为表保持，因为它保存在每个可能的表值中。

  

基于具有复合主键的表的独奏条件，任何通用表都在2NF中吗？

5NF中存在表格（因此也是所有其他NF），其中包含各种复合材料和混合物。非复合CKs。 PK并不重要。

没有复合键且没有{}作为决定因素的表必须在2NF中。通常说没有复合键可以保证2NF，但是忘记{}可能是一个决定因素。它是任何/每个单属性CK的适当/较小子集。 {}是每个行必须为其确定的属性具有相同值的决定因素。

Answer 2

  

为什么上述关系在2NF？

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

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

  

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

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

  

如果表具有复合主键，则无论函数依赖性是否在2NF中都不存在？

没有。请记住，2NF是根据FD定义的。说到2NF符合“无论”它们的含义是什么意思？

密钥中的列数并不重要。它是一些设置， X ，标识补充， Y 。

Answer 3

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

关于2NF的第一个陈述：

  

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

是正确的，也是你的假设

  

if {SSN，Pnumber} - ＆gt;小时和SSN - ＆gt;几个小时，这种关系不会在2NF

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

您所谓的FD左侧通常称为键。您可以使用该键来查找相关数据。为了节省空间（并降低复杂性），您应该始终尝试找到最小的密钥，并尽可能将较大的表拆分为较小的表，这样您就不必在必要的地方保存信息。这就是对正常形式的归一化，并且正在研究大约半个世纪的时间，已经开发了关于这个问题的实质性理论，并且一些规则从中得到了结晶，如1NF，2NF，3NF等。

你的第二个问题让我感到很困惑，因为从你所说的话来看，你似乎已经理解了这一点。 关于FD的问题会有些混乱吗？从图中可以看出，因为它们的定义如下：

{SSN，Pnumber} - ＆gt;小时
{SSN} - ＆gt;为ename
{Pnumber} - ＆gt; PNAME，Plocation

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

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

所以，让我们知道在某个组织中每个项目的每个人员的工作时间。 SSN识别员工（其名称也存储为ename，因为它更容易记住，但可能重复），Pnumber识别项目，出于同样的原因，名称和位置也存储得很多。

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

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

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

我的第三个问题根本不明白，我很害怕。在某种程度上，一旦确定了将在数据库中保存哪些数据，就可以说预定FD是预定义的。 FD不会被迫改变。在DB中建模时，它们不会更改。如果你以后发现你会改变设计，那么这将是与新FD的新关系。

你似乎从某个地方引用的文字只是说如果你有FD X - ＆gt; Y（X给出或确定Y）然后如果你在该关系（表）中有任何两个具有相同X值的元组（记录），它们也必须具有相同的Y值。或者在我们的例子中，如果Pnumber在某处给出888的值，Pname是'Battleship'，Plocation是'Kitchen Sink'，然后如果在其他地方（其他一些记录）使用Pnumber 888那么Pname也必须是'Battleship'并且Plocation必须是'Kitchen Sink '因为Pname和Plocation在功能上依赖于Pnumber。

现在这几乎是你教科书的另一章，或者是什么？希望它有所帮助，因为我花了一些时间来写： - ）

Answer 4

如果主键由多列组成，则表可以说是2NF，如果每行将这些列连接在一起形成一个字符串，则生成的列将符合主键的条件。或者，单列主键也可以作为2NF。

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