mysql - 我们如何处理在表的所有记录中具有相同值的列？

Question

假设我有一张表，为了简化所有行的内容Persons，并假设我们存储了这个人的颜色。现在让我们简化一下，我们有 100 万条记录，所有人的颜色都是白色。

现在在这种情况下white重复了超过一百万次。
现在，如果我们不能将表更改为 eg white_person 表，是否意味着该属性color和person具有特定关系：

1. 证明表中的重复属性是正确的？
2. 证明创建新表并将其视为1-N关系的合理性？但正式地如何定义这种类型的关系？

Answer 1

如果在每一行上重复相同的值，因为您实际想要建模的依赖项是 ∅->{color}，那么您的 Persons 表违反了 2NF：行列式 ∅（空集）是键的适当子集。满足 2NF 所需的更改是将颜色属性删除到以 ∅ 为键的新表（即单行表）中。或者完全从模型中删除该属性。

请注意，不会因为表中某些值的巧合而自动暗示依赖关系。问题在于您需要 DBMS 执行哪些业务规则，以及数据模型是否正确支持这些规则。

我在这里讨论了一个类似的例子。

Answer 2

如果可以假设一个事实，则不需要存储它。所以如果有一个个人属性的值是预先知道的，你确定对数据库中的所有人来说都是一样的，并且将来会一直保持不变，那么你就不需要将它物理存储在数据库。

但我怀疑你可以做出这样的假设。为了降低存储许多重复字符串的成本，请使用细长的代理键（例如，字节或 16 位 int）将颜色分隔到自己的表中，然后从“大”表中引用它（通过 FOREIGN KEY） . 这样，您不是在重复字符串，而是在重复（更细的）整数。这不是真正的规范化问题（两种变体都是“规范化的”），而是优化物理设计。

但是，如果有另一个属性在功能上依赖于颜色，那么您绝对应该拥有单独的表格。否则，将存在传递函数依赖 PK -> color -> another，违反 3NF。

例如：

Answer 3

现在，如果我们不能将表更改为例如 white_person 表，这是否意味着属性 color 和 person 具有特定关系

1）证明表中的重复属性是正确的？

重复属性在数据库技术中具有特定的含义。这并不意味着您可以找到具有相同值的多行。（这就是 rows 的用途。）您没有重复属性。

2) 证明创建新表的合理性并将其视为 1-N 关系？但正式地如何定义这种类型的关系？

1-N 关系将通过函数依赖来识别——你会发现一个人的颜色是白色的，他的颜色也是紫红色的。一个人可以在你的数据库中有多少种颜色？