假设我有一个表格，为了简化所有的行都是关于Persons，并假设我们存储了这个人的颜色。现在让我们简化一下，我们有 100 万条记录，所有人的颜色都是白色。
现在在这种情况下，white 重复了超过 100 万次。
现在，如果我们不能将表格更改为例如white_person 表是这样的，是不是意味着color 和person 属性有特定的关系：
1-N 关系？但在形式上如何定义这种类型的关系？【问题讨论】：
标签： mysql sql database-design relational-database normalization
现在，如果我们不能将表格更改为例如white_person 表 就是这样，是否意味着属性 color 和 person 有 一种特定的关系，
1) 证明表中的重复属性是正确的？
重复属性在数据库技术中有特定的含义。它确实 not 意味着您可以找到具有相同值的多行。 （这就是 for 的行。）您没有重复属性。
2) 证明创建新表的合理性并将其视为 1-N 关系？但从形式上讲，这种关系将如何 定义？
1-N 关系可以通过函数依赖来识别——你会找到一个人，他的颜色是白色的，他的颜色也是紫红色的。一个人可以在您的数据库中有多少种颜色？
【讨论】：
It does not mean you can find multiple rows that have the same value. (That's what rows are for.) 我问的是列的值在所有行中是否相同。并非所有行在所有列中都具有相同的值。 2) A 1-N relationship would be identified by a functional dependency 是的，但是您可以为 1-1 关系创建一个单独的表。这就是我的意思，但也许我不清楚
如果在每一行上重复相同的值，因为您实际想要建模的依赖项是 ∅->{color}，那么您的 Persons 表违反了 2NF：行列式 ∅（空集）是关键。满足 2NF 所需的更改是将颜色属性删除到以 ∅ 为键的新表（即单行表）中。或者完全从模型中删除该属性。
请注意，不会因为表中某些值的巧合而自动暗示依赖关系。问题在于您需要 DBMS 执行哪些业务规则，以及数据模型是否正确支持这些规则。
我讨论了一个类似的例子here。
【讨论】：
∅->{color}？我不确定你的意思？
如果一个事实可以假设，则不需要存储它。因此，如果有一个个人属性的值是预先知道的，你知道肯定对于数据库中的所有人都是相同的，并且将来始终保持不变，那么你不需要'根本不需要将其物理存储在数据库中。
但我怀疑你能否做出这样的假设。为了降低存储许多重复字符串的成本，请使用细长的surrogate key（例如，一个字节或一个 16 位 int）将颜色分隔到自己的表中，然后从“大”引用它（通过 FOREIGN KEY）桌子。这样，您不是在重复字符串，而是在重复（更细的）整数。这并不是真正的规范化问题（两种变体都是“规范化的”），而是优化物理设计。
但是，如果有 另一个 属性在功能上依赖于颜色，那么您绝对应该拥有单独的表格。否则会出现transitive functional dependencyPK -> 颜色 -> 另一个，违反了 3NF。
例如：
【讨论】：