在进行数据库规范化时，什么是将重复的行信息集组合成新的实体？

我对数据库规范化的某个部分有点困惑，我想我应该问 StackOverflow：

想象一下，您有以下将产品与颜色联系起来的关系。请注意，产品 1 和产品 2 都使用同一组颜色（蓝色和绿色）。

Product_Color                         Color
+-------------+-------------+     +-------------+-------------+
| Product*    | Color*      |     | ColorId*    | Name        |
+-------------+-------------+     +-------------+-------------+
| 1           | 1           |     | 1           | Blue        |
| 1           | 2           |     | 2           | Green       |
| 2           | 1           |     +-------------+-------------+
| 2           | 2           |
+-------------+-------------+

如果我创建两个新关系 ColorSet 和 ColorSet_Color，我可以通过将 4 个关系连接在一起来显示相同​​的信息。

Product_ColorSet:                 ColorSet_Color:             
+-------------+-------------+     +-------------+-------------+
| Product*    | ColorSetId* |     | ColorSetId* | ColorId*    |
+---------------------------+     +-------------+-------------+
| 1           | 1           |     | 1           | 1           |
| 2           | 1           |     | 1           | 2           |
+-------------+-------------+     +---------- --+-------------+

ColorSet:                         Color:
+-------------+                   +-------------+-------------+
| ColorSetId* |                   | ColorId*    | Name        |
+-------------+                   +-------------+-------------+
| 1           |                   | 1           | Blue        |
| 2           |                   | 2           | Green       |
+-------------+                   +----------[--+-------------+

此时，如果我有一个大型 Product_Color 表，并且具有合理程度的共享颜色组，那么从空间角度来看，我将获得相当大的收益。

在数据库规范化的背景下，此操作的技术名称是什么？我显然正在删除冗余信息，即使我创建的实体实际上并不存在，这更像是存在大量重叠的随机机会。我这样做具体要改变什么？

此外，似乎我可以对大多数实体任意执行此操作。让我困惑的是，当我们开始练习时，Product_Color 和 Color 已经处于第六范式（对吗？）。

您正在介绍一个“代理键 https://en.wikipedia.org/wiki/Surrogate_key“（或标识符）到name/identify产品所采用的颜色集。替代方案通常被认为是“自然键 https://en.wikipedia.org/wiki/Natural_key“（或标识符）。（尽管不同的人在细节上使用这些术语的方式不同。例如，当名称/标识符被永久分配给所指对象和/或其所指对象的唯一名称/标识符和/或其是时，有些人可能仅使用“代理”仅在数据库中可见，而在应用程序中不可见。例如，有些人会说外部可见的系统生成的任意名称/标识符（如驾驶员识别号）既是替代项又是自然项。）

代理键通常被称为“无意义（标识符）”。这反映了思想的混乱。All不是由先验命名方案生成的名称是“无意义的”且任意的。 “尼古拉斯”并不是“意思”you直到被选中；一旦被选中，它就“意味着”你。这适用于any名称/标识符。因此，“无意义”/“有意义”并不是一个有用的区别。系统中的代理名称/标识符只是系统启动后选择的名称/标识符。当在之前存在的任何系统中分配时，系统中被称为“有意义”[原文如此]的东西将被称为“无意义”[原文如此]（因为分配是在之后）it开始）。

有一种“视角”是“删除冗余信息”，但这不是规范化所解决的那种冗余。您正在用其他表替换一个表，但这不是规范化分解。引入代理人并不是正常化的一部分。规范化不会引入新的列名称。它只是在替换它的表中重用原始表的名称。 （你能清楚准确地描述一下这里的“冗余”是什么意思吗？）

有时人们认为，如果相同的值子元组可以在列集或表中出现多次，那么这些子行值需要替换为 id，这些 id 是新表的 FK，将 id 值映射到子行值。 （甚至可能对于单列子行，即当单个值在列或表中出现多次时。）他们认为多个子行值出现是“冗余的”，或者只有 id 可以重复而不是“冗余”。 （id设计被视为原始数据的一种压缩。）他们可能认为这是规范化的一部分。但事实并非如此。 https://stackoverflow.com/a/32036030/3404097

这不是您应该通过表格设计来解决的冗余问题。If您知道 DBMS 对表的实施选项and您了解应用程序的使用模式and你知道原来的选项显然比某些恰好“冗余度较低”的选项更糟糕（为什么“冗余度更高”的选项不会更好？）then如果可以的话，您应该告诉 DBMS 您的设计需要什么选项，而不需要更改架构。 （这通常是通过索引和/或视图完成的。）例如，在 ColorId 上索引原始 Product_Color 会导致实现中的结构与您在第二个设计中手动创建的结构基本相同，但会自动生成和管理。 （您可能会引入代理other原因，例如用更简洁但更模糊的值和约束的外键替换多列外键。）

重新选项：您的新设计将使用更多操作（例如连接和投影）在查询文本中并且（对于典型的 DBMS 实现）执行比原始（例如查询原始表）但是fewer其他地方（例如，将一个产品的颜色设置复制到另一个产品的颜色设置）。所以这又是关于权衡 of multiple“观点”。

事实上你在另一种意义上引入冗余与代理人。还有一些附加列保存了原始中没有的一堆 id 值，但记录了相同的情况。您还给用户带来了更多命名和间接设计的负担。与原始设计相比，替代设计在这个“视角”中肯定有很多“冗余信息”。

甚至您的初始设计也可能引入了代理，即颜色名称的颜色 ID。 （如果颜色 ID 添加了“信息”，即“通知”您的不仅仅是它们的相关名称，那么它们就不是替代品，而且是必要的。）即，如果颜色 ID 是任意选择的，那么您可以：

Product_Color
+-------------+-------------+
| Product*    | ColorName*  |
+-------------+-------------+
| 1           | Blue        |
| 1           | Green       |
| 2           | Blue        |
| 2           | Green       |
+-------------+-------------+

你应该有一个reason引入颜色 ID，以及就此而言的产品 ID，而不是已经存在的自然键。你可以吗justify您的多个表、名称和间接寻址与只有一个？