Question

我在过去的关于关系数据库的论文中提出了以下问题。我完全陷入问题（iv）。我想我可能已经做了第（iii）部分错误，这导致了这个问题。

假设您有以下名为Songs的数据库表：
Songs(singerID, singerName, songID, songName, songLength, songGenre)
其中{singerID，songID}是主键，并且存在以下功能依赖项：
{singerID} -> {singerName}
{songID}   -> {songName, songLength, songGenre}
{songName} -> {songGenre}
i上面的表格是什么样的正常形式？

答案：它是在1NF。

ii说明为什么它不在2NF。

答案：SingerID无法确定songName，songGenre或songLength

iii重新设计Songs表并从中创建一个2NF的表。

答案：

Singer{singerID, SingerName}
Song{SongID, songName, songLength, songGenre}
Songs{singerID, SongID}

现在我认为所有非关键属性在功能上都依赖于主键。

iv说出你在第（iii）部分制作的表格为2NF而不是3NF的原因。陈述您需要的任何假设。

对我而言，这是3NF。

Answer 1

您有传递依赖：songID > songName > songGenre。这很棘手，因为我不会在现实世界中期待它。

对于3NF，您需要一个表{songName, songGenre}并从songGenre删除song。

Answer 2

您有什么参考？如果你没有遵循参考程序，你怎么能被卡住？什么定义＆amp;您使用的算法是2NF＆amp; 3NF？

i上面的表格是什么样的正常形式？


答案：它是在1NF。

问题（i）没有意义。据推测，他们的意思是，这张桌子的最高NF（正常形式）是多少。（在列表1NF，2NF，3NF，....）

你对（i）的回答没有意义; 2NF中的每个表也是1NF。你的意思是它在1NF而不是2NF，或者它的最高NF是1NF。

ii说明为什么它不在2NF。


答案：SingerID无法确定songName，songGenre或songLength

你对（ii）的回答没有意义;它对2NF或更高的定义或算法没有吸引力。

iii重新设计Songs表并从中创建一个2NF的表。


答案：
Singer{singerID, SingerName}
Song{SongID, songName, songLength, songGenre}
Songs{singerID, SongID}

问题（iii）没有意义;规范化替换其他表的表。也许他们的意思是＆＃34;分解它，直到你有一个2NF＆＃34;的组件。但下面我解释为什么他们可能意味着＆＃34;从2NF＆＃34;中做出设计。

也许您将问题解释为＆＃34;将其分解，直到您有一个2NF＆＃34;的组件，同意上面的第一个可能的意图。或者误解为＆＃34;从中制作一堆表2NF＆＃34;或者，给出相同的含义，误解＆＃34;表＆＃34; as＆＃34; design＆＃34;，同意上面的第二个可能的意图。如果是第一个，你不会说你的哪个部分是答案，或者说所有部分都是答案。你的是对所有2NF表的分解。

iv说出你在第（iii）部分制作的表格为2NF而不是3NF的原因。陈述您需要的任何假设。


对我而言，这是3NF。

现在我认为所有非关键属性在功能上都依赖于主键。

2NF的两个常见定义的措辞是没有任何特定类型的FD，据说是违反＆＃34;违反＆＃34;。人们可以总是以某种方式无损地分解，从而产生较小的组件，其中FD不再是可以合理地模糊地称为“将FD移动到其自己的组件，而留下另一个组件”的问题。如果你继续这样做，那么你最终将拥有所有2NF组件 - 一个2NF 设计。（这不是优秀设计的一部分，即使是2NF。）但如果你＆＃34;保持＆＃34;一路上不同的一个你做的＆＃34;制造＆＃34;一个不同的表是＆＃34; left＆＃34;。所以没有特定的表，除非你被告知一些不寻常的方式以某种有序的方式分解。此外，我们总是可以直接分解为3NF，但问题（iv）希望你不这样做。

也许问题（iv）期待＆＃34;＆＃34;＆＃34;表 - 假设某个定义，某种分解，以及某种分解顺序。更有可能的问题（iv）意味着＆＃34;从中做出设计，这是在2NF＆＃34; - 假设某个定义和某种类型分解。

据推测，您通过＆＃34;移动＆＃34;生成了所有2NF表。每个以上的FD。（Non-trivial FDs with a nonprime attribute dependent on a proper subset of a CK）。但你的回答并没有解释。而且，PK（主键）并不重要，CK（候选键）也可以。如果你的意思是每张桌子只有一个CK，你需要说出来并证明它是正确的。但它仍然没有意义，因为它没有提到分解为2NF或更高的定义或算法。

你对2NF对3NF的回答没有意义，你声称桌子在3NF并且你应该说出为什么但你没有。（Song不在3NF中的原因是它的FD {songID} -> {songGenre}是非主要属性通过songName对CK的传递依赖，或者它的FD {songName} -> {songGenre}是非的依赖性 - 非超级密钥上的非素数属性。

PS当我们被给予PK或CK时，某些FD（功能依赖性）必须保持，并且某些FD不能保持，并且FD的某些组合可以＆amp;不能坚持。当给出一组持有的FD时，那些必须持有的所有 FD的集合由阿姆斯特朗的公理给出，即给定集合的传递闭包。通常给出FD集的问题意味着唯一持有的FD就是那些，即该集合是表中FD的覆盖。有时我们会告诉它这是一个小小的封面。各种算法使用各种集合。不幸的是，许多问题都表明集合中的FD存在，但不清楚它是否是一个封面，即其他 FD不在传递闭包中是否可以成立。就像这个问题一样！

（请找出问题所针对的问题，找到定义和程序/算法的参考，然后按照它进行操作。然后再问一个新问题。）

考试重新规范歌曲（歌手ID，歌手姓名，歌曲ID，歌曲名称，歌曲长度，歌曲歌曲）

2 个答案: