阅读C.J.Date的数据库系统简介或相似级别的书籍的人不应该在定义规范化和非规范化方面遇到问题。
然而,记忆不像过去那样,我发现自己经常看一些设计并说它没有正常化,即使我找不到它正在破坏的正常形式。
说明它的实际例子是:
如果我们有关系
r1 (A, B, C)
和r2 (A, D)
与FD:AB-> C和A-> D
和r1
表示详细数据,而r2
是该数据的摘要(换言之,D的每个实例都是r1中的值的函数。在此示例中,将其作为值C的小计)根据来自r1的A。
示例实例
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“数据库的进一步规范化)关系模型“,第34页,评论超过1NF标准化的原因):
- 从不受欢迎的插入中释放关系集合, 更新和删除依赖项;
- 减少重组收集的需要 作为新型数据的关系 介绍,从而增加了生命 应用程序范围;
- 使关系模型对用户更具信息性;
- 使查询的关系集合中立 统计数据,这些统计数据 随着时间的推移可能会发生变化。
醇>
正如我可以说的那样,如果我们将D定义为来自r1的所有C的总和,其中来自r1的A等于来自r2的A,那么,如果我们在r1中更新C并且我们不在r2中更新D,我们最终可能会出现不希望的更新依赖性,并且数据最终处于不一致状态我发现这个原因是将r1和r2称为非规范化并将它们视为非规范化。 (事实上,整个r2是r1的函数,并将零个新事实带入模型; r2 = f(r1))
所以问题是
注意:
对于那些发现有趣的问题来回答问题的人,我请求提供一些可引用的东西,或者将其置于一种特定的假设和结论中(或换句话说,如果你要放入您的意见,请用一些推理来遵循它。)
修改 我接受了dportas的回答。我会尝试在这里添加一点: C.J.Date可以做出明确而严格的区分:
许多设计理论都与此有关 减少冗余;正常化 减少relvars内的冗余, 正交性减少了它 relvars。
引自Database in depth: relational theory for practitioners
并在下一页
正如未能使所有人正常化 方式意味着冗余,可以导致 某些异常现象也是如此 不遵守正交性。
答案 0 :(得分:4)
假设AB是r1中的键,A是r2中的键,那么模式似乎是6NF。关系数据库字典(Date)将非规范化定义为:
更换一组relvars R1,R2 ,. 。 。,Rn由他们加入R,这样就可以了 所有我对R的投射 Ri的属性保证是 等于Ri(i = 1,2,...,n)。
从根本上说,归一化/非规范化是指使用投影和 join 运算符进行合成和非损失分解。在此示例中,您具有由不同运算符引起的冗余:求和。我希望原则上很可能为投影和连接之外的运算符形成“规范化”理论,甚至可能对求和等非关系函数。然而,这并不是传统上如何定义规范化,并且在没有任何合理基础的情况下,我认为我们应该应用上述引文中由Date定义的技术含义非规范化。
答案 1 :(得分:2)
所以r2是r1的函数,这意味着r2是r1函数的物化视图
在该示例中,它将是select A, sum(C) from r1 group by A
实现视图的实现通常是出于缓存的原因,有些人可能会认为这是一种非规范化的形式,因此有些论文会自动决定实现哪个视图,从而使数据库可以通过视图进行操作以使其有时更快< / p>
但由于通常不允许对视图进行更新,但我认为我读过codd说所有可以更新的视图都应该是这样的,并且有一些文件可以让它在某些复杂的情况下工作
答案 2 :(得分:1)
我认为这对关系违反了第五种正常形式。
R2是R1的投影。有人认为SUM不在关系模型的范围之内。在这种情况下,SUM是COUNT的一个简单扩展,它在关系模型的范围内。