我阅读了不同的教程并看到了不同的规范化示例，特别是第一范式中“重复组”的概念。我从他们那里收集到重复组是“一种”多值属性（例如here 和here）。
但是，在将 ERM（实体关系模型）映射到 RDM（关系数据模型）的过程中，我们已经通过包含来自父表的外键，为每个多值属性创建了单独的表？参考：this
其次，那些“重复的组”本质上是水平排列在同一行中，还是可以在同一列中一次又一次出现相同的值，即一个属性的相同值一次又一次，也是一个重复组，应该被淘汰吗？
在此示例中，值 English 一次又一次地重复。这是重复组吗？ 如果我消除它以使用主题名称和 Module_ID（外键）创建另一个表 SUBJECT，这就是我得到的。当然它摆脱了重复值，但我不确定这是否是正确的。这样对吗？
【问题讨论】：
标签： database database-design database-normalization
术语“重复组”最初是指基于 CODASYL 和 COBOL 的语言中的概念，其中单个字段可以包含重复值的数组。当 E.F.Codd 描述他的第一个范式时，这就是他所说的重复组。这个概念在任何现代关系型或基于 SQL 的 DBMS 中都不存在。
术语“重复组”也已非正式地被数据库设计人员不准确地用来表示重复的列集，表示包含类似的列的集合表中的各种值。这与它与 1NF 相关的原始含义不同。例如，在名为 Families 的表的情况下，列名为 Parent1、Parent2、Child1、Child2、Child3 等，Child N 列的集合有时被称为重复组并假定违反 1NF，即使它 不是 Codd 想要的意义上的重复组。
如果每个属性都只有单值，则所谓的重复组的后一种含义在技术上并不违反 1NF。属性本身不包含重复值，因此不违反 1NF。然而，这样的设计通常被认为是一种反模式，因为它将表限制为预先确定的固定数量的值（一个家庭中最多 N 个子项），并且因为它强制为每一列重复查询和其他业务逻辑。换句话说，它违反了“DRY”的设计原则。因为它通常被认为是糟糕的设计，所以适合数据库设计人员甚至教师将这种重复列称为“重复组”，违反了第一范式的精神。
这种非正式的术语用法有点令人遗憾，因为它可能有点武断和混乱（一组列实际上何时构成重复？），还因为它分散了对更基本问题的注意力，即 Null 问题.所有范式都关注不允许有空值的关系。如果表允许在任何列中为空，则它不满足满足 1NF 的关系模式的要求。对于我们的 Families 表，如果 Child 列允许空值（表示具有少于 N 个孩子的家庭），则 Families 表不满足 1NF。在规范化练习中经常忘记或忽略空值的可能性，但避免不必要的可空列是避免重复列集的一个很好的理由，无论您是否称它们为“重复组”。
另见this article。
【讨论】：
英语的价值一次又一次地重复。这是重复的吗 组？
没有。 SUBJECT_MODULE 中多次出现的英语不是重复组，甚至不是人们错误地认为重复组的两件事中的任何一个。它们也不是冗余或缺乏标准化的证据。这种多次出现可能与冗余或规范化有关，但它们总是在没有冗余和各种规范化级别时出现。
如果 SUBJECT_MODULE 是“[SUBJECT_NAME] 具有 [MODULE_NAME] 由 [MODULE_ID] 标识”的行，并且一个主题可能有多个模块，那么您必须在某处多次提及该主题（也许通过它的名字）提到不同的模块（可能是名字或id）。这不会涉及冗余。
Student Age Subject
Adam 15 Biology
Adam 15 Maths
Alex 14 Maths
Stuart 17 Maths
此示例中问题的第二个“this”链接的冗余不是 Adam 出现在两行中，也不是 Adam 出现在两行中的 15。如果表格是“[Student] 是 [Age] 岁并采用 [Subject]”的行，那么 Student（例如 Adam）可以出现在多行中但总是以相同的年龄出现 （例如 15）。但是，如果表格是“[Student] 在 [Subject] 中有一个 [Age] 岁的朋友”的行，那么表格可能已经完全规范化了。
当然它消除了重复值，但我不确定这是否是 正确的事情。
它适用于您的示例数据，但它可能不适用于其他示例数据。你告诉我们的还不够多。 （无论如何，正如我上面所说，多次出现可能甚至不需要标准化。）
在 SUBJECT_MODULE 中是否存在任何与规范化相关的冗余，甚至是否存在任何有效的分解，包括您给出的分解，取决于规范化到 1NF 以上所需的通常信息。即它的某些列是否是其他列的函数（函数依赖）以及它的行是否也是“...”和“...”（连接依赖）的那些。
通过给出可能的分解，您已经说过“...[Subject_Name]...[Module_ID]...” AND “...[Module_Name]...[Module_ID].. 。”你已经给出了一些分解数据的例子。但我们只知道它可以如此分解，因为您添加了分解。而且分解加上数据仍然不足以让我们知道它是否应该应该如此分解。
我阅读了不同的教程并看到了不同的示例 规范化，特别是第一个中的“重复组”的概念 正常形式。
“重复组”是来自前关系数据库的东西，不可能出现在关系表（关系）中。它们就像一组命名的值，就像记录的一个字段，但不完全是。关系表总是在 1NF 中。行的每一列都有一个列类型的值。非关系数据库被“规范化”为表，即 1NF（“规范化”的第一意义上），它摆脱了重复组。然后这些表/关系被“规范化”为更高的规范形式（“规范化”的第二种意义）。
具有多个相似列或具有具有多个相似部分的列类型的关系表每个都只是让人想起在非关系数据库中具有重复组。并且多个列和部分应该成为单独表中的多行，就像重复组的多个成员一样。但这些问题与关系设计质量有关，而不是重复组或规范化（在任何一种意义上）或关系（即处于 1NF 中）。
请注意，非关系数据库本身可能在多个相似字段和/或命名集或字段值的多个相似部分存在类似问题。消除重复组时，对表格的规范化并没有消除这些。
无论它们是如何进入关系设计的，删除它们都会提供“更好”的设计。正是因为这些设计问题让人想起重复组，人们才会感到困惑，并想象一个表格可能包含一个重复组。因此，具有多个相似部分（或部分）的多个相似列和值被错误地称为“重复组”。
【讨论】：