规范化：＆＃34;重复组＆＃34;意思？

Question

我已经阅读了不同的教程并看到了标准化的不同例子，特别是＆＃34;重复组的概念＆＃34;在第一个正常形式。从他们那里我已经聚集起来，重复的群体是＆＃34;善良的＆＃34;多值属性（例如here和here）。

但是我们已经通过在将ERM（实体关系模型）映射到RDM（关系数据模型）的过程中包含来自父表的外键来为每个多值属性创建单独的表？参考：this

其次，那些＆＃34;重复的群体＆＃34;基本上水平排列在同一行，或者同一个值可以一次又一次地出现在同一列中，即一次又一次的属性相同的值，也是一个重复的组，应该被删除？

在此示例中，英语值一次又一次地重复。这是一个重复的群体吗？ 如果我删除它以使用Subject Name和Module_ID（外键）创建另一个表SUBJECT，这就是我得到的。当然它摆脱了重复的价值，但我不确定这是否是正确的。这样对吗？

Answer 1

术语“重复组”最初是指基于CODASYL和COBOL的语言中的概念，其中单个字段可以包含重复值的数组。当E.F.Codd描述他的第一范式是他重复组的意思。任何现代关系或基于SQL的DBMS都不存在这个概念。

术语“重复组”也被非正式地用于数据库设计者并且不精确地表示重复的列，意味着包含类似的列的集合表中的各种值。这与其与1NF相关的原始含义不同。例如，在名为Families的表中，列名为Parent1，Parent2，Child1，Child2，Child3，...等，Child N 列的集合有时被称为重复组并假设违反1NF，即使它是不是 Codd意图的重复组。

如果每个属性仅为单值，则后一种所谓的重复组意义在技术上并不违反1NF。属性本身不包含重复值，因此没有违反1NF的原因。这种设计通常被认为是反模式，但是因为它将表限制为预定的固定数量的值（一个族中最多N个子节点），并且因为它强制对每个列重复查询和其他业务逻辑。换句话说，它违反了“DRY”设计原则。因为它通常被认为是糟糕的设计，它适合数据库设计师，有时甚至教师将这种重复的列称为“重复组”并违反第一范式的精神。

这种术语的非正式用法有点不幸，因为它可能有点随意和令人困惑（一组列实际上是什么时候构成重复？）而且因为它分散了一个更基本的问题，即Null问题。所有正规形式都关注不允许出现空值的关系。如果表允许任何列中的null，则它不满足满足1NF的关系模式的要求。对于Families表，如果Child列允许空值（表示少于N个子节点的族），则Families表不满足1NF。在规范化练习中经常会忘记或忽略空值的可能性，但避免使用不必要的可空列是避免重复列集的一个非常好的理由，无论你是否将它们称为“重复组”。

另见this article。

Answer 2

  

英语的价值一次又一次地重复。这是一个重复   组？

没有。 SUBJECT_MODULE中英语的多次出现不是重复组，也不是人们误认为重复组的两种情况中的任何一种。它们也不是冗余或缺乏正常化的证据。这样的多次出现可能与冗余或标准化有关，但是当没有冗余和各种标准化水平时它们会一直出现。

如果SUBJECT_MODULE是＆＃34; [SUBJECT_NAME]的[MODULE_NAME]由[MODULE_ID]＆＃34;并且一个主题可能有多个模块，然后你必须多次提到该主题（可能通过其名称）并提及不同的模块（可能是通过名称或ID）。这不会涉及冗余。

Student Age Subject

Adam    15  Biology
Adam    15  Maths
Alex    14  Maths
Stuart  17  Maths

此示例中的冗余来自您的问题的第二个＆＃34; this＆＃34;链接不是Adam出现在两行中，或者Adam出现在两行中有15行。如果表是＆＃34; [学生]是[年龄]岁并且需要[主题]＆＃34;然后学生（例如亚当）可以出现在多行中，但总是出现相同的年龄（例如15）。但如果桌子是行，那么[学生]有一个朋友[年龄]在[主题]中年龄大了＃34;然后表格已经完全正常化了。

  

当然它摆脱了重复的价值，但我不确定这是不是   是对的。

它适用于您的示例数据，但它可能不适用于其他示例数据。你还没有告诉我们。 （无论如何，正如我上面所述，多次出现甚至可能都不需要规范化。）

SUBJECT_MODULE中是否存在任何与归一化相关的冗余，或者是否存在任何有效分解（包括您给出的分解）取决于标准化到1NF以上所需的常用信息。即它的某些列是否是其他列的功能（功能依赖性）以及它的行是否也是＆＃34; ...＆＃34; AND＆＃34; ...＆＃34; （加入依赖关系）。

通过给出可能的分解，你已经说过它也是＆＃34; ... [Subject_Name] ... [Module_ID] ......＆＃34; AND＆＃34; ... [Module_Name] ... [Module_ID] ...＆＃34;并且您已经给出了一些示例分解数据。但是我们只知道它可以被分解，因为你添加了分解。分解加上数据仍然不足以让我们知道是否如此分解。

  

我已经阅读了不同的教程，并看到了不同的例子   规范化，特别是＆＃34;重复群体的概念＆＃34;在第一个   正常形式。

＆＃34;重复群组＆＃34;是来自关系前数据库的东西，不可能出现在关系表（关系）中。它们就像一组命名的值，就像一个记录的字段，但并不完整。关系表始终为1NF。行的每列都具有列类型的单个值。非关系型数据库是＆＃34;标准化的＆＃34;表格，即1NF（第一感觉＆＃34;标准化＆＃34;），它摆脱了重复的群体。那些表/关系是＆＃34;标准化＆＃34;更高的正常形式（第二感觉＆＃34;标准化＆＃34;）。

具有多个相似列或具有多个相似部分的列类型的关系表每个都只是让人想起在非关系数据库中具有重复组。并且多个列和部分应该在单独的表中变成多行，就像重复组的多个成员一样。但是这些问题与关系设计质量有关，而不是重复组或规范化（在任何意义上）或关系（即在1NF中）。

请注意，非关系数据库本身可能与多个相似字段和/或命名集或类似字段值的相似部分存在类似问题。当表格去掉重复的组时，对表的规范化并没有消除这些。

无论他们如何进入关系设计，删除它们都会带来更好的＆＃34;设计。这只是因为这些设计问题让人想起重复的群体让人们感到困惑，并想象某个表格可能包含一个重复的群体。因此，具有多个相似部分（或部分）的多个相似列和值被错误地调用＆＃34;重复组＆＃34;。

请参阅this answer re "atomicity"。