什么是将重复的行信息集组合成在进行数据库规范化时调用的新实体？
What is combining repeating sets of row information into new entities called when doing database normalization?
我对数据库规范化的某个部分有点困惑，我想问一下 Whosebug：
假设您有以下将产品与颜色相关联的关系。请注意，产品 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 table，具有合理程度的共享颜色组，我将从 space 的角度获得相当大的收益。
在数据库规范化的上下文中，此操作的技术名称是什么？我清楚地删除了冗余信息，即使我创建的实体实际上并不存在，它更像是随机的机会，有很多重叠。我这样做具体改变了什么？
此外，我似乎可以对大多数实体任意执行此操作。令我困惑的是 Product_Color 和 Color 在我们开始练习时已经处于第 6 范式（对吗？）。
您正在引入“surrogate key" (or identifier) to name/identify sets of colours that products come in. The alternative is usually considered to be a "natural key”（或标识符）。 （尽管不同的人在细节上使用这些术语的方式不同。例如，有些人可能只在 name/identifier 永久分配一个指称时才使用 "surrogate" and/or 是其唯一的指称 name/identifier and/or 它仅在数据库中可见，而不是在应用程序中可见。例如，有人会说外部可见的系统生成的任意 name/identifier 像驾驶员识别号一样是代理项和自然项。）
代理键通常称为 "meaningless (identifiers)"。这反映了思维混乱。 所有 不是由先验命名方案生成的名称都是"meaningless" & 任意的。 "Nicholas" 没有 "mean" you 直到它被选中；被选中了，就"means"你了。这适用于 any name/identifier。所以 "meaningless"/"meaningful" 不是一个有用的区分。 系统中的代理人 name/identifier 只是在系统启动后选择的代理人。 在系统中被称为 "meaningful" [原文如此] 的东西会被称为 "meaningless" [原文如此] 在之前存在的任何系统中分配时（因为分配是在 它 开始之后）。
有一个 "perspective"，您 "removing redundant information"，但这不是规范化解决的冗余问题。您正在用其他 table 替换 table，但这不是归一化分解。引入代理人不是正常化的一部分。规范化不会引入新的列名。它只是在替换它的 table 中重复使用原始 table 的名称。 （你能清楚准确地描述你在这里所说的 "redundant" 的意思吗？）
有时人们认为，如果相同的值子元组可以在列集中出现多次或 table，那么这些子行值需要用作为 FK 的 id 替换为新的 table 将 id 值映射到子行值。 （甚至对于单列子行，即当单个值在一列中出现多次或 table。）他们认为多个子行值出现是 "redundant" 或者只有 ids 可以重复而不是"redundant"。 （id设计被看作是对原始数据的一种压缩。）他们可能认为这是归一化的一部分。 None of this is so.
这不是冗余，您应该费心通过 table 设计来解决。 如果您知道 DBMS table 的实施选项并且您知道应用程序的使用模式and 你知道原始版本明显比某些恰好是 "less redundant" 的选项更糟糕（为什么 "more redundant" 选项不会更好？）然后 如果可以的话，您应该在不更改架构的情况下告诉 DBMS 您希望为您的设计选择什么选项。 （这通常是通过索引 and/or 视图完成的。）例如，在 ColorId 上索引您的原始 Product_Color 会导致实现中的结构与您在第二个设计中手动创建的结构基本相同，但自动生成和管理。 （您可能会出于 其他 原因引入代理项，例如，用更简洁但更模糊的值和约束的外键替换多列外键。）
Re 选项：您的新设计将在查询文本和（对于典型的 DBMS 实现）执行中使用 更多操作（例如，查询原始 table) 但在其他地方更少（例如，将一个产品的颜色集复制到另一个产品的颜色集）。所以这又是关于 权衡 的 多个 "perspectives".
事实上，您在另一种意义上 引入了代理人的冗余 。还有一些额外的列包含一堆 id 值，这些值不在原始记录中，但记录了相同的情况。您还给用户增加了更多命名和间接的设计负担。这个"perspective"中的surrogate design肯定比原来多了"redundant information"
甚至您的初始设计也可能引入了代理项，即颜色名称的颜色 ID。 （如果添加了颜色 ID "information"，即 "informed" 你超越了它们的关联名称，那么它们就不是代理人，而是必需的。）即如果颜色 ID 是任意选择的，那么你可以：
Product_Color
+-------------+-------------+
| Product* | ColorName* |
+-------------+-------------+
| 1 | Blue |
| 1 | Green |
| 2 | Blue |
| 2 | Green |
+-------------+-------------+
您应该有一个 理由 来引入颜色 ID，就此而言，产品 ID，而不是已经存在的自然键。你能证明你的多个tables、名称和间接与一个吗？
我对数据库规范化的某个部分有点困惑，我想问一下 Whosebug：
假设您有以下将产品与颜色相关联的关系。请注意，产品 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 table，具有合理程度的共享颜色组，我将从 space 的角度获得相当大的收益。
在数据库规范化的上下文中，此操作的技术名称是什么？我清楚地删除了冗余信息，即使我创建的实体实际上并不存在，它更像是随机的机会，有很多重叠。我这样做具体改变了什么？
此外，我似乎可以对大多数实体任意执行此操作。令我困惑的是 Product_Color 和 Color 在我们开始练习时已经处于第 6 范式（对吗？）。
您正在引入“surrogate key" (or identifier) to name/identify sets of colours that products come in. The alternative is usually considered to be a "natural key”（或标识符）。 （尽管不同的人在细节上使用这些术语的方式不同。例如，有些人可能只在 name/identifier 永久分配一个指称时才使用 "surrogate" and/or 是其唯一的指称 name/identifier and/or 它仅在数据库中可见，而不是在应用程序中可见。例如，有人会说外部可见的系统生成的任意 name/identifier 像驾驶员识别号一样是代理项和自然项。）
代理键通常称为 "meaningless (identifiers)"。这反映了思维混乱。 所有 不是由先验命名方案生成的名称都是"meaningless" & 任意的。 "Nicholas" 没有 "mean" you 直到它被选中；被选中了，就"means"你了。这适用于 any name/identifier。所以 "meaningless"/"meaningful" 不是一个有用的区分。 系统中的代理人 name/identifier 只是在系统启动后选择的代理人。 在系统中被称为 "meaningful" [原文如此] 的东西会被称为 "meaningless" [原文如此] 在之前存在的任何系统中分配时（因为分配是在 它 开始之后）。
有一个 "perspective"，您 "removing redundant information"，但这不是规范化解决的冗余问题。您正在用其他 table 替换 table，但这不是归一化分解。引入代理人不是正常化的一部分。规范化不会引入新的列名。它只是在替换它的 table 中重复使用原始 table 的名称。 （你能清楚准确地描述你在这里所说的 "redundant" 的意思吗？）
有时人们认为，如果相同的值子元组可以在列集中出现多次或 table，那么这些子行值需要用作为 FK 的 id 替换为新的 table 将 id 值映射到子行值。 （甚至对于单列子行，即当单个值在一列中出现多次或 table。）他们认为多个子行值出现是 "redundant" 或者只有 ids 可以重复而不是"redundant"。 （id设计被看作是对原始数据的一种压缩。）他们可能认为这是归一化的一部分。 None of this is so.
这不是冗余，您应该费心通过 table 设计来解决。 如果您知道 DBMS table 的实施选项并且您知道应用程序的使用模式and 你知道原始版本明显比某些恰好是 "less redundant" 的选项更糟糕（为什么 "more redundant" 选项不会更好？）然后 如果可以的话，您应该在不更改架构的情况下告诉 DBMS 您希望为您的设计选择什么选项。 （这通常是通过索引 and/or 视图完成的。）例如，在 ColorId 上索引您的原始 Product_Color 会导致实现中的结构与您在第二个设计中手动创建的结构基本相同，但自动生成和管理。 （您可能会出于 其他 原因引入代理项，例如，用更简洁但更模糊的值和约束的外键替换多列外键。）
Re 选项：您的新设计将在查询文本和（对于典型的 DBMS 实现）执行中使用 更多操作（例如，查询原始 table) 但在其他地方更少（例如，将一个产品的颜色集复制到另一个产品的颜色集）。所以这又是关于 权衡 的 多个 "perspectives".
事实上，您在另一种意义上 引入了代理人的冗余 。还有一些额外的列包含一堆 id 值，这些值不在原始记录中，但记录了相同的情况。您还给用户增加了更多命名和间接的设计负担。这个"perspective"中的surrogate design肯定比原来多了"redundant information"
甚至您的初始设计也可能引入了代理项，即颜色名称的颜色 ID。 （如果添加了颜色 ID "information"，即 "informed" 你超越了它们的关联名称，那么它们就不是代理人，而是必需的。）即如果颜色 ID 是任意选择的，那么你可以：
Product_Color
+-------------+-------------+
| Product* | ColorName* |
+-------------+-------------+
| 1 | Blue |
| 1 | Green |
| 2 | Blue |
| 2 | Green |
+-------------+-------------+
您应该有一个 理由 来引入颜色 ID，就此而言，产品 ID，而不是已经存在的自然键。你能证明你的多个tables、名称和间接与一个吗？