【问题标题】:How would storing XML in a relational database violate Normalization Principles?将 XML 存储在关系数据库中会如何违反规范化原则?
【发布时间】:2017-01-23 19:02:15
【问题描述】:

在本书中:Regina Obe 和 Leo Hsu,PostgreSQL Up & Running,p。 101.它是作为PostgreSQL XML数据类型的介绍写的:

XML 数据类型,类似于 JSON,在关系中是“有争议的” 数据库,因为它违反了规范化原则。

无需进一步解释。有人可以详细说明什么是规范化原则以及为什么 XML 确实违反了其中的一些原则。

【问题讨论】:

  • 你知道什么是标准化吗?如果您知道什么是规范化,那么问问自己可以在 XML 中存储哪些类型的东西可能会违反规范化。
  • @KennethK.,从数据库的角度来看,我认为这意味着以不重复数据的方式设计表,而是解耦对象以在不重复的情况下引用它,然后在非规范化时加入该表需要。但是这里 XML 是一种数据类型,不是一种组织原始数据的方式,而是一种卫星数据,那么我想知道为什么作者要强调这种特殊性?
  • @KennethK.,此外,XML 允许引用避免重复,然后可以生成规范化的数据结构。那么,我错过了什么吗?
  • @kjhughes,感谢您让我的问题更清楚
  • 那么您将如何在 XML 列的两个不同行之间强制执行“没有数据重复”?

标签: xml relational-database normalization


【解决方案1】:

目前关于 1NF 的主流想法是,从形式上讲,它是不可定义的(原因是通常定义所依赖的“原子性”概念本身并不能在形式上定义——作为说明,我只需要指出Michael Kay 将“原子”和“不可分割”这两个词放在了吓人的引号中)。因此,评估某事是否构成违反 1NF 的行为并不是客观可判定的。

结果是,纯粹从形式上讲,“没有问题” - 正如 rb 所说。但这仅意味着很难用数学术语准确地确定该方法的实际缺点是什么,而不是没有这样的缺点。

编辑

很好的阅读:

https://www.simple-talk.com/sql/learn-sql-server/facts-and-fallacies-about-first-normal-form/

附带条件是 1NF 应该被理解为“最初的 1NF 打算解决的问题,至少在精神上”。

并特别注意,它的结论大部分也适用于您的场景:

违反 1NF 的影响有时被认为是无害的,尽管它们中的大多数会损害架构的结构健全性和完整性。如果您尝试通过使用解析和透视值的复杂例程或依赖外部应用程序来强制执行足够的完整性来“修补”问题,那么您只会对数据库的整体稳定性施加额外的负担。简而言之,任何认为您通过避开 1NF 来实现设计简单的看​​法都只是一种错觉。另一方面,只要将其作为数据管理中最基本的完整性格言来接受,就会有很多收获。

【讨论】:

    【解决方案2】:

    关系模型是一阶逻辑模型,这意味着我们的谓词中的变量只能包含值。值之间的任何结构/关联都应记录为关系,以便规范化和其他关系特征(如查询和约束)可以对其进行操作。

    将像 XML 或 JSON 这样的复杂值存储为不透明值不是问题,但是当我们将它们解释为数据结构时,我们有一个更高阶的模型(谓词随谓词而变化)。一般来说,这样的模型处理起来要复杂得多(尽管起初看起来更自然)。例如,它需要额外的运算符来遍历、连接、操作、比较和约束(部分)层次结构。

    【讨论】:

      【解决方案3】:

      书籍和网络上有很多关于关系数据库规范化的教程。例如见https://en.wikipedia.org/wiki/Database_normalization

      第一个范式表示列应该只包含“原子”或“不可分割”的值——如果你过于严格地解释它意味着你甚至不允许存储日期。将 XML 文档存储在列中肯定违背了这一原则。这并不意味着这样做一定是一件坏事,只是您需要了解后果(这通常意味着更新数据库并保持其一致性会更加困难)。

      【讨论】:

      • 好吧,我错过了列的原子性质。
      猜你喜欢
      • 2011-10-07
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-03-21
      • 1970-01-01
      • 2011-10-15
      • 1970-01-01
      相关资源
      最近更新 更多