database - 了解数据库规范化 - 第二范式 (2NF)

Question

我一直在从 Elmasri 和 Navathe 的“数据库系统基础知识(第 6 版)”学习规范化，但我无法理解以下有关 2NF 的部分。

下图是教材中2NF下给出的例子

候选键为{SSN,Pnumber} 依赖项是 SSN,Pnumber -> hours, SSN -> ename, pnumber->pname, pnumber -> 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 -> hours，然后取两个函数依赖，

{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].

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

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

Answer 1

Why is the above relation not in 2NF?

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

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

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

If the above statement is taken into account, do you assume the following functional dependencies

so won't the same process of the decomposition shown based on the informal way alone be difficult each time such a case arrives?

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

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

还有从公理中遵循的速记规则。例如，如果一组属性在每个元组中具有不同的子行值，那么它的每个超集也是如此。例如，如果 FD 成立，则其行列式的每个超集决定其确定集的每个子集。例如， super key 的每个超集都是 super key ，并且 CK 的适当子集都不是 CK。还有算法。

Are functional dependencies pre-determined based on "functionalities of database and a database designer having domain knowledge of the attributes" ?

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

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

so would any general table be in 2NF based on a solo condition of a table having a composite primary key?

5NF 中有表格(因此也有所有较低的 NF)，其中包含各种复合和非复合 CK 的混合。 PK 无关紧要。

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