(De)两个关系的归一化

Question

读过C.J.Date的《数据库系统简介》或类似水平书籍的人应该不会对规范化和非规范化的定义有问题。

但是，内存已经不像以前那样了，我发现自己经常看到一些设计并说它没有被规范化，即使我找不到它破坏了哪种正常形式。

说明它的实际例子是：

如果我们有关系

r1 (A, B, C) 和 r2 (A, D)

使用 FD：AB->C 和 A->D

和r1 表示详细数据，而r2 是该数据的摘要（换句话说，D 的每个实例都是 r1 中值的函数。在这个例子中，让它成为根据 A 的值 C 的小计r1)。

示例实例

r1 = 
A  B  C  
1  1  10
1  2  20
2  1  10
2  2  25

r2 =
A  D
1  30
2  35

所以，即使我不能说它破坏了例如 2NF 或 3NF，我似乎仍然认为设计仍然在以下意义上非规范化（来自 Codd，EF “数据库的进一步规范化Relational Model”，第 34 页，评论规范化超过 1NF 的原因）：

1. 要将关系集合从不需要的插入中解放出来， 更新和删除依赖项；
2. 减少重组集合的需要 关系作为新类型的数据 引入，从而增加寿命 应用程序的跨度；
3. 使关系模型为用户提供更多信息；
4. 使关系集合与查询无关 统计数据，这些统计数据在哪里 随着时间的推移可能会发生变化。

我可以说，如果我们将 D 定义为来自 r1 的所有 C 的总和，其中来自 r1 的 A 等于来自 r2 的 A，那么，如果我们更新 r1 中的 C 而我们不更新 r2 中的 D，我们最终可能会导致不良的更新依赖性，并且数据最终处于不一致的状态我发现这个原因将 r1 和 r2 称为非规范化并将它们视为非规范化。 （事实上​​，整个 r2 是 r1 的函数，并将零个新事实带入模型；r2 = f(r1)）

所以问题是

1. 我们可以将 r1 和 r2 称为非规范化吗？
2. 如果是，为什么？如果不是，为什么？ （根据哪个规则？还是根据哪个定义？）

注意：
对于那些发现问题足够有趣以提供答案的人，我恳请您提供一些可引用的内容或以特定假设和结论的形式（或者换句话说，如果您要您的意见，请遵循它的一些推理）。

编辑 我接受了 dportas 的回答。我将尝试在这里添加一些内容： C.J.Date 可以做出明确而严格的区分：

很多设计理论都与 减少冗余；正常化 减少relvars内的冗余， 正交性减少了它 关系。

引自Database in depth: relational theory for practitioners

在下一页

就像未能正常化所有 方式意味着冗余，并可能导致 某些异常，a 也可以 未能遵守正交性。

Answer 1

您对 r2 中 D 列的定义，“来自 r1 的所有 Cs 的总和，其中来自 r1 的 A 等于来自 r2 的 A”，是对 D 的约束。更正式地说，其中 Σ 是求和，π 是投影，σ是选择，

(a,d) ∈ r2 ⇔ (a, d) = (a, Σ c), a ∈ πA(r1), c ∈ πC(σA=a(r1))

由于此约束既不是域约束也不是键约束，r2 不在Domain/Key Normal Form (DKNF) 中。

DKNF 是我所知道的唯一正常形式，它不是根据单个关系定义的，主要是因为它是根据约束而不是依赖关系定义的。

Answer 2

我认为这对关系违反了第五范式。

---

R2 是 R1 的投影。有人认为 SUM 超出了关系模型的范围。在这种情况下，SUM 是 COUNT 的一个微不足道的扩展，它在关系模型的范围内。

Answer 3

所以 r2 是 r1 的函数，这意味着 r2 是 r1 的函数的物化视图

在该示例中，它将是select A, sum(C) from r1 group by A 的视图

codd 的规范化工作没有涵盖视图，但我认为他确实写过这些视图

物化视图通常是出于缓存原因而进行的，有些人可能认为这是一种非规范化形式，因此有论文关于自动决定要物化哪个视图，从而使其成为数据库可以对视图执行的操作，以使它们有时更快

但是由于视图的更新通常是不允许的，尽管我认为我读到 codd 说过所有可以更新的视图都应该是这样的，并且有论文让它在一些复杂的情况下工作

Answer 4

假设 AB 是 r1 中的键，A 是 r2 中的键，那么模式似乎在 6NF 中。关系数据库字典（日期）将非规范化定义为：

替换一组 relvars R1, R2, . . ., Rn 由他们加入 R，这样对于 所有 i R 在 Ri 的属性保证为 等于 Ri (i = 1, 2, . . ., n)。

从根本上说，规范化/非规范化是关于使用 projection 和 join 运算符的组合和无损分解。在此示例中，您有由不同运算符引起的冗余：求和。我预计原则上很有可能为除投影和连接之外的运算符形成“规范化”理论，甚至可能为求和之类的非关系函数。然而，这不是规范化的传统定义方式，并且在没有任何合理基础的情况下，我认为我们应该应用上述引用中由 Date 定义的技术含义的非规范化。