何时删除重复数据：标准化之前/之后？答案

【问题标题】：When does repeating data get removed: before/after normalization?何时删除重复数据：标准化之前/之后？
【发布时间】：2017-08-29 09:31:10
【问题描述】：

鉴于这种逻辑设计：

R(a,b, c, d)
a is the only key. I can't underline it using this editor. 
a->b
a->c
a->d

它在 BCNF 中，因为没有复合键，没有传递依赖，也没有部分键依赖。

但是，我们仍然在属性 b、c 和 d 中的行间存在重复数据。

我们是否引入代理键并这样重写：

R(a, bID, cID, dID)
R1(bID, b)
R2(cID, c)
R3(dID, d)

如果是这样，那是在标准化之前还是之后发生的？

【问题讨论】：

代理键可能很紧凑，但它们并不能减少值的重复，并且它们增加了间接级别。为什么您将相同价值的多次出现视为一个问题？
由于您解释的原因，我认为它们是一个问题。我明白这些特定的重复在规范化过程中不是问题。
在规范化之前或之后引入代理键没有区别。
1.什么是“跨行重复数据”？ 2. 规范化不添加 id，它通过投影替换表格。 3.您的“因为”不清楚和困惑，请参阅一些 BCNF 和较低的 NF 定义。 4. 假设没有非 FD JD，这是在 5NF 中，尽可能归一化（在正常意义上）。你是什么意思，“规范化之前或之后”？ 6. 添加 id 会使 id 值具有与它们标识的值完全相同的外观模式，因此添加它们不会影响您拥有的“跨行重复数据”（无论您的意思是什么）。 PSstackoverflow.com/a/26952821/3404097
您的问题是关于“在属性中的行之间重复数据”，但您还没有解释这是什么，那么我们如何回答您的问题？您似乎认为这很明显，但相反，您似乎持有许多误解，不仅关于“重复数据”，而且关于规范化和代理/标识符。因此，如果您不想遭受误解，请编辑您的问题，以明确您的假设/期望以及困扰您的原因以及您认为这是一个问题的原因。

标签： sql normalization database-normalization

【解决方案1】：

标准化的重点不是消除重复。就是去掉不恰当的依赖。如果每个非键属性在功能上完全依赖主键（仅此而已），那么对于规范化的目的，从表中的一行到另一行，某些列数据可能是相同的。这种相同是偶然的。

这是您在查看重复并决定它是偶然的还是有意义的时必须考虑的事情。考虑更新非键列的情况。

在一种情况下，假设非键列是人名。当有人更改姓名时，您的系统会发生什么？如果旧值为“Doug”而新值为“Bob”，您是否希望将“Doug”的每个实例都替换为“Bob”？也许你会，但我猜你可能不会。如果您要创建代理键并将非键值规范化到另一个表，那么您将错误地更改您不想更改的值。

在另一种情况下，假设非键列是市政名称。当您更改自治市名称时，您的系统会发生什么情况？假设旧值为“New Berlin”，新值为“Kitchener”。你想让“新柏林”的每一个实例都变成“基奇纳”吗？可能是吧。（也许不是，这取决于您的业务规则）= 如果您确实想更改每个实例，那么您发现市政名称可能在功能上并不完全依赖于您的主键。在这种情况下，您应该将其规范化为一个新表。

您已询问何时这应该发生（在标准化之前或之后）。答案是它发生在作为规范化的一部分。将数据移到单独的关系中以避免部分或传递函数依赖的行为本身就是规范化数据库模式的行为。这是 2NF 还是 3NF 的一部分？这取决于。如果您的非键属性在功能上部分依赖于键，那么它在 2NF 期间。如果它是传递依赖的（即依赖于另一个或多个非关键属性），那么它是在 3NF 期间。

您应该尽可能将规范化作为逻辑建模过程的一部分。当您进入物理模型时，您更有可能出于某种实际原因引入非规范化。非规范化（在事务处理系统中）通常只有在您发现必须这样做时才应该做。 3NF 或更高版本是 OLTP 系统的重要基础。因此，在大多数情况下，您将在开始非规范化之前构建您的逻辑和物理模式。

【讨论】：

@nicomp & JoelBrown 将一个值的多个外观同时更改为另一个值的外观的愿望与规范化无关。（这是使模式复杂化以简化某些查询和更新并使其他复杂化的问题。）此外，对给定 NF 的规范化通常不涉及通过较低的 NF。（这样做会使良好的高 NF 设计不可用。）
@nicomp & JoelBrown 为了清楚起见，我指的是引入一个 id 以便您可以更改 id 映射到的内容，而不是更改各种单独的匹配项。这是一个设计问题，但不是规范化问题，因为规范化不引入 id，它通过投影替换表。
@nicomp 3NF 的定义意味着“2NF 的所有条件也都为真，再加上...”在 3NF 中没有任何操作。范式描述的是一种存在状态，而不是一个过程。
归一化确实可以自动化，但有许多不同的算法（伯恩斯坦和哈尔平仅举两个）。它们都以不同的方式工作，并且可以产生不同的结果。规范化是一组基于科学而非宗教的设计模式和原则。实现标准化数据库设计没有单一的通用惯例
@nicomp 这将定义的子句与算法中的步骤混淆了。 PS 在 CK 上没有非素数的传递 FD 意味着非素数对 CK 没有部分依赖性。 Codd 在他的 3NF 中使用“并且在 2NF”这个子句的唯一原因是因为他希望它需要他的1NF。可以只说“并且在 1NF 中”而他的 3NF 仍然意味着 2NF。用“in 1NF”来表示微不足道的“是一个关系”，我们得到所有归一化理论结果都是不关心属性类型的 NF。 3NF 的（现代）意义不必提及 2NF 或 1NF。