定义过多的冗余？答案

【问题标题】：Define too much redundancy?定义过多的冗余？
【发布时间】：2015-12-03 00:59:13
【问题描述】：

我正在做一个在线课程，它给出了以下 relvar 示例，然后说：

嗯。尽管每个元组中的 answer 和 answercode 都不同——使得每个元组在技术上是唯一的——属性 id 的值， questionID 和 answertype 完全相同。规范化是有序的。

问题是，什么被认为是过多的冗余？在我们开始进行标准化步骤之前，这条线在哪里绘制？

【问题讨论】：

en.wikipedia.org/wiki/Database_normalization

标签： sql relational-database normalization redundancy

【解决方案1】：

规范化不是用来减少冗余值的东西。它用于减少值之间的冗余关联。换句话说，它旨在确保每个事实只记录一次。

为了确定是否需要规范化，写出函数依赖关系并寻找异常的原因，如传递依赖关系、对部分键的依赖等。这些类型的冗余中的每一种都在范式的描述中明确定义在线和教科书中。

在您的示例中，如果我假设 questionID -> answertype、(questionID, answercode) -> answer 和 id 等效于 questionID 并且可以忽略，那么该关系仅在 1NF 中，因为 answertype 是非主要属性取决于键 (questionID, answercode) 的一部分。如果更新要更改某些显示的答案类型（但不是全部）的值，则您的数据将在逻辑上损坏。规范化可以防止这种情况发生。

您的客户关心准确性和一致性。你呢？

【讨论】：

那么我们什么时候开始规范化呢？ “在别处清楚地描述”没有什么帮助。我们几乎在每个 relvar 中都会有重复的值。所以当我们看到一个包含相同值的冗余依赖时，这就是我们应该规范化的时候吗？
忘记重复值。查看函数和多值依赖项。将其与正常形式进行比较。是否存在更新异常的风险？您是想通过设计确保完整性，还是在客户端代码和手动更新时自己承担责任？要么正常化，要么接受后果，这是你的选择。