Database design （d）两种关系正常化

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

然而，记忆已经不是过去的样子了，我发现自己经常看着一些设计，说它没有标准化，即使我找不到它打破的是哪种正常形式

说明这一点的实际例子是：

如果我们有关系

r1（A，B，C）

和

r2（A，D）

使用FDs:AB->C和A->D

和

r1

表示详细数据，而

r2

是该数据的汇总（换句话说，D的每个实例是r1中值的函数。在本例中，让它是根据r1中的a值C的小计）

实例

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，E.F.“数据库关系模型的进一步规范化”，第34页，评论了规范化超过1NF的原因）：

将关系集合从不希望的插入中释放出来， 更新和删除依赖项

减少对收集数据进行重组的必要性 关系作为新的数据类型是 引入，从而增加寿命 应用程序的跨度

使关系模型向用户提供更多信息

使关系集合与查询无关 统计数据，这些统计数据在哪里 随着时间的推移容易改变

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

所以问题是

我们能称r1和r2为非规范化的吗

若有，原因为何？若否，原因为何？（根据哪个规则？或根据哪个定义？）

注意：
对于那些觉得这个问题很有趣，可以给出答案的人，我恳请他们提供一些可以引用的东西，或者以一种特定的假设和结论的形式（或者换言之，如果你想提出你的观点，请遵循它并进行一些推理）

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

许多设计理论都与设计有关 减少冗余；规范化 减少relvars中的冗余， 正交性减少了它的交叉性 雷瓦尔

引自

在下一页

就像所有的错误都无法正常化一样 这种方式意味着冗余，并可能导致 某些异常情况也会出现 未能坚持正交性

---

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

在该示例中，它将是一个视图，

通过a从r1组中选择a和（C）

codd关于规范化的工作中没有涉及这些观点，但我认为他确实写过这些观点

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

---

但是，由于视图的更新通常是不允许的，尽管我认为我读到codd说，像所有可以更新的视图一样，在一些复杂的情况下，应该是可以更新的，并且有一些关于如何使其工作的论文假设AB是r1中的一个键，a是r2中的一个键，那么模式似乎是6NF中的。关系数据库字典（日期）将非规范化定义为：

替换一组相关变量R1、R2。 ，Rn由它们的联接R表示，因此 所有i都是R在平面上的投影 Ri的属性保证是 等于Ri（i=1，2，…，n）

---

从根本上讲，规范化/非规范化是关于使用投影和连接运算符进行合成和非损失分解。在本例中，冗余是由不同的运算符引起的：求和。我认为，对于投影和连接以外的运算符，甚至对于像求和这样的非关系函数，在原则上形成“规范化”理论是完全可能的。然而，这不是规范化的常规定义，在没有任何可靠基础的情况下，我认为我们应该应用上述引用中日期定义的技术意义非规范化。

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

---

---

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

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

（a、d）∈ r2⇔ （a，d）=（a，∑c），a∈ πA（r1），c∈ πC（σA=A（r1））

由于此约束既不是域约束也不是键约束，

r2

不在（DKNF）中

DKNF是我所知道的唯一一种没有用单一关系定义的规范形式，主要是因为它是用约束而不是依赖关系定义的。

它可能是一种视图，但规范化是关于语义，而不是实现的。在这种情况下，似乎相关的事实是A确定D，而不管r1和r2是基关系还是deri