归一化后的函数依赖
Functional dependencies after normalization
我很难理解规范化过程的一个方面，我不太明白在将关系规范化为 2NF（或 3NF）后如何处理函数依赖。
让我用一个例子来描述它。
我的教科书中的练习要求规范化与 2NF 的关系，然后是 3NF 的关系。我们得到了一个关系
R=(ABCDEF) , F={AD->FE, BC->E, FEA->D, AC->DE, F->E, BD->A, F->C, ABC->AEF, B->F}
按照这本书，我将函数依赖性最小化为
F = {AD->F, AC->D, BD->A, F->E, F->C, B->F}
这应该是正确的，因为我检查了几次。现在我们可以找到钥匙了：
{AB} and {BD}
接下来，我可以看到
B->F
打破 2NF，因为非键属性依赖于键的一部分。所以我们需要 "divide" 我们的关系变成两个新的 tables :
R1 = (BFEC) and R2 = (ABD)
这是我迷路的地方。那些新的 table 需要 "inherit" 函数依赖，所以我的想法是这样做：
F1 = {F->E, F->C, B->F} and F2 = {BD->A}
我试图通过查看属性然后将它们配对在一起来确定哪个关系获得哪个依赖项。然而，这给我们留下了两个来自原始集合的函数依赖：
AD->F, AC->D
我不知道放在哪里。我试图查找它背后的一些理论，但到目前为止没有运气。
有人可以向我解释一下如何为我在规范化过程中创建的每个新 table 找出新的函数依赖关系吗？
谢谢。
假设我们想要无损分解，以便在原始关系中保持的 FD（函数依赖）也在其中一个组件中保持，因此在它们的连接中保持。我们可以使用一个组件的 FD 属性来执行此操作，同时通过从原始组件中删除确定的属性来获取另一个组件，只要这些组件共享其中一个组件的 CK（候选键）的属性即可。你会被告知是这样的。这里有问题的 FD B -> F 建议分解 {ABCDE} 和 {BF}，因为公共属性集 {B} 是后者的 CK。
So we need to "divide" our relation into two new tables :
R1 = (BFEC) and R2 = (ABD)
考虑到这些 FD，这不是无损分解，并且不清楚您为什么这么认为。 （共享列 {B} 不包含其中一个组件的 CK。）
（这个术语不是“划分”，而是“分解”。不清楚为什么你没有使用正确的术语，而是使用了一个并不意味着那个的不同术语，甚至使用吓人的引号来表明你知道这不是那个意思，虽然你甚至没有说出你的意思。）
您不能只将包含在组件中的封面中的 FD 的子集作为组件的封面。您需要查看保留的所有原始 FD 中的哪些具有组件的属性，因此保留在组件中。为什么？封面是一组 FD，表示所有持有的 FD，没有其他。组件中可能有一个 FD 控股，它不在封面中，但由封面中的 FD 集暗示。如果所有这些集合都包含其属性不在组件中的 FD，那么该 FD 将不会被具有组件属性的封面的 FD 子集所暗示。因此该子集不会成为组件的封面。
如上所述通过拆分某些 FD 进行分解可能意味着原始文件中包含的某些非平凡 FD 在任何一个组件中都没有其所有属性，因此不包含在其中。 （另请注意，成立的 FD 包括阿姆斯特朗公理给出的所有列出的 FD，而不仅仅是列出的 FD。）然后虽然我们会有无损分解，但我们无法检查后者 FD 是否成立通过检查它是否包含在组件中来连接组件。这称为不保留该 FD。但事实证明，我们始终可以在保留 FD 的同时归一化为 3NF。这就是为什么我们不通过较低的 NF 或随机选择 FD 来规范化为 NF（正常形式），而是使用专门设计的算法来在保留 FD 的同时获得该 NF。
查找并遵循信息建模和关系数据库教科书。 （许多在线免费，还有学术幻灯片和课程。）
这是 Ullman 的一些幻灯片中 Berstein 的保留 FD 的 3NF“合成”算法：
Given: a relation R and a cover F for the FDs that hold in R
- Find C, a canonical cover for F
- For each FD X -> Y in C, create a relation with schema XY
- Eliminate a relation if its schema is a subset of another
- If none of the schemas created so far contains a CK of R, add a relation schema containing a CK of R
由于这保留了 FD 并且 3NF 意味着 2NF，因此其输出也是保留了 FD 的 2NF 模式。 （它的输出实际上是 EKNF，比 3NF 稍微强一些。）
我很难理解规范化过程的一个方面，我不太明白在将关系规范化为 2NF（或 3NF）后如何处理函数依赖。 让我用一个例子来描述它。
我的教科书中的练习要求规范化与 2NF 的关系，然后是 3NF 的关系。我们得到了一个关系
R=(ABCDEF) , F={AD->FE, BC->E, FEA->D, AC->DE, F->E, BD->A, F->C, ABC->AEF, B->F}
按照这本书，我将函数依赖性最小化为
F = {AD->F, AC->D, BD->A, F->E, F->C, B->F}
这应该是正确的，因为我检查了几次。现在我们可以找到钥匙了：
{AB} and {BD}
接下来，我可以看到
B->F
打破 2NF，因为非键属性依赖于键的一部分。所以我们需要 "divide" 我们的关系变成两个新的 tables :
R1 = (BFEC) and R2 = (ABD)
这是我迷路的地方。那些新的 table 需要 "inherit" 函数依赖，所以我的想法是这样做：
F1 = {F->E, F->C, B->F} and F2 = {BD->A}
我试图通过查看属性然后将它们配对在一起来确定哪个关系获得哪个依赖项。然而，这给我们留下了两个来自原始集合的函数依赖：
AD->F, AC->D
我不知道放在哪里。我试图查找它背后的一些理论，但到目前为止没有运气。
有人可以向我解释一下如何为我在规范化过程中创建的每个新 table 找出新的函数依赖关系吗？
谢谢。
假设我们想要无损分解，以便在原始关系中保持的 FD（函数依赖）也在其中一个组件中保持，因此在它们的连接中保持。我们可以使用一个组件的 FD 属性来执行此操作，同时通过从原始组件中删除确定的属性来获取另一个组件，只要这些组件共享其中一个组件的 CK（候选键）的属性即可。你会被告知是这样的。这里有问题的 FD B -> F 建议分解 {ABCDE} 和 {BF}，因为公共属性集 {B} 是后者的 CK。
So we need to "divide" our relation into two new tables : R1 = (BFEC) and R2 = (ABD)
考虑到这些 FD，这不是无损分解，并且不清楚您为什么这么认为。 （共享列 {B} 不包含其中一个组件的 CK。）
（这个术语不是“划分”，而是“分解”。不清楚为什么你没有使用正确的术语，而是使用了一个并不意味着那个的不同术语，甚至使用吓人的引号来表明你知道这不是那个意思，虽然你甚至没有说出你的意思。）
您不能只将包含在组件中的封面中的 FD 的子集作为组件的封面。您需要查看保留的所有原始 FD 中的哪些具有组件的属性，因此保留在组件中。为什么？封面是一组 FD，表示所有持有的 FD，没有其他。组件中可能有一个 FD 控股，它不在封面中，但由封面中的 FD 集暗示。如果所有这些集合都包含其属性不在组件中的 FD，那么该 FD 将不会被具有组件属性的封面的 FD 子集所暗示。因此该子集不会成为组件的封面。
如上所述通过拆分某些 FD 进行分解可能意味着原始文件中包含的某些非平凡 FD 在任何一个组件中都没有其所有属性，因此不包含在其中。 （另请注意，成立的 FD 包括阿姆斯特朗公理给出的所有列出的 FD，而不仅仅是列出的 FD。）然后虽然我们会有无损分解，但我们无法检查后者 FD 是否成立通过检查它是否包含在组件中来连接组件。这称为不保留该 FD。但事实证明，我们始终可以在保留 FD 的同时归一化为 3NF。这就是为什么我们不通过较低的 NF 或随机选择 FD 来规范化为 NF（正常形式），而是使用专门设计的算法来在保留 FD 的同时获得该 NF。
查找并遵循信息建模和关系数据库教科书。 （许多在线免费，还有学术幻灯片和课程。）
这是 Ullman 的一些幻灯片中 Berstein 的保留 FD 的 3NF“合成”算法：
Given: a relation R and a cover F for the FDs that hold in R
- Find C, a canonical cover for F
- For each FD X -> Y in C, create a relation with schema XY
- Eliminate a relation if its schema is a subset of another
- If none of the schemas created so far contains a CK of R, add a relation schema containing a CK of R
由于这保留了 FD 并且 3NF 意味着 2NF，因此其输出也是保留了 FD 的 2NF 模式。 （它的输出实际上是 EKNF，比 3NF 稍微强一些。）