我一直认为数据库应该针对读取性能进行非规范化，就像针对 OLAP 数据库设计所做的那样，而不是针对 OLTP 设计进一步夸大 3NF。
各种职位的 PerformanceDBA，例如，基于时间的数据的不同方法的性能 https://stackoverflow.com/questions/4375192/performance-of-different-aproaches-to-time-based-data/4390401#4390401捍卫数据库应始终通过规范化为 5NF 和 6NF（范式）来精心设计的范式。
我是否正确理解了它（以及我正确理解了什么）？
OLAP 数据库的传统非规范化方法/范式设计（3NF 以下）以及 3NF 足以满足 OLTP 数据库的大多数实际情况的建议有什么问题？
例如：
我应该承认，我永远无法理解非规范化促进读取性能的理论。任何人都可以给我提供对这一点和相反信念有良好逻辑解释的参考资料吗？
当我试图说服我的利益相关者 OLAP/数据仓库数据库应该标准化时，我可以参考哪些来源？
为了提高可见性，我从评论中复制到这里：
“如果参与者能够 添加（披露）现实生活中有多少（没有） 包括科学项目） 6NF 中的数据仓库实现 他们见过或参与过。 有点像快速泳池。我 = 0。”——达米尔 苏达雷维奇
维基百科的数据仓库文章 http://en.wikipedia.org/wiki/Data_Warehouse告诉：
“标准化方法[与拉尔夫·金博尔（Ralph Kimball）的维度一]，也 叫做3NF模型（第三范式）其支持者是 被称为“Inmonites”，相信 Bill Inmon 的方法 据说数据仓库应该使用 E-R 进行建模 模型/归一化模型。”
看起来标准化数据仓库方法（由 Bill Inmon 提出）被认为不超过 3NF（？）
我只是想了解数据仓库/OLAP 是非规范化同义词的神话（或普遍存在的公理信念）的起源是什么？
Damir Sudarevic 回答说，他们已经做好了准备。让我回到这个问题：为什么非规范化被认为有利于阅读？
神话
我一直认为数据库应该非规范化以供读取，就像 OLAP 数据库设计所做的那样，而不是为 OLTP 设计进一步夸大 3NF。
有一个关于这个效果的神话。在关系数据库上下文中，我重新实现了六个非常大的所谓“非规范化”“数据库”；并执行了八十多项任务来纠正他人的问题，只需将其规范化、应用标准和工程原理即可。我从未见过任何证据证明这个神话。只有人们重复这个咒语，就好像这是某种神奇的祈祷一样。
标准化与非标准化
（“去规范化”是一个欺诈性术语，我拒绝使用它。）
这是一个科学产业（至少是提供不会损坏的软件、将人们送上月球、运行银行系统等）。它受物理定律而非魔法的支配。计算机和软件都是有限的、有形的、受物理定律约束的物理对象。根据我接受的中等和高等教育：
一个更大、更胖、组织性较差的物体不可能比一个更小、更薄、组织性更强的物体表现得更好。
标准化会产生更多的表，是的，但每个表要小得多。尽管有更多的表，但实际上 (a) 连接更少，并且 (b) 连接速度更快，因为集合更小。总体上需要更少的索引，因为每个较小的表需要更少的索引。标准化表还会产生更短的行大小。
对于任何给定的资源集，规范化表：
因此，总体结果是性能高得多。
根据我的经验，从同一个数据库提供 OLTP 和 OLAP，从来不需要“去规范化”我的规范化结构，以获得更高的只读 (OLAP) 查询速度。这也是一个神话。
人们写了很多书，兜售神话。需要认识到，这些人都是非技术人员；既然他们在推销魔法，那么他们推销的魔法就没有科学依据，而且他们在推销时很容易回避物理定律。
（对于任何想对上述物理科学提出质疑的人，仅仅重复咒语是没有任何作用的，请提供支持该咒语的具体证据。）
为什么这个神话盛行？
嗯，首先，它在科学类型中并不普遍，因为他们不寻求克服物理定律的方法。
根据我的经验，我发现这种流行的三个主要原因：
对于那些无法标准化数据的人来说，这是不这样做的一个方便的理由。他们可以参考魔法书，在没有任何魔法证据的情况下，他们可以虔诚地说“看到一位著名作家验证了我所做的事情”。最准确地说，还没有完成。
许多 SQL 编码人员只能编写简单的单级 SQL。规范化结构需要一定的 SQL 功能。如果他们没有那个；如果他们无法在不使用临时表的情况下生成 SELECT；如果他们不能编写子查询，他们就会在心理上坚持平面文件（这就是“非规范化”结构），他们can过程。
People love多看书，多讨论理论。没有经验。尤其是魔法。它是一种补品，是实际经验的替代品。任何真正正确规范化数据库的人都从未说过“非规范化比规范化更快”。对于任何说出咒语的人，我只是说“给我展示证据”，但他们从未拿出任何证据。所以现实是，人们因为这些原因重复这个神话，没有任何标准化经验。我们是群居动物，未知是我们最大的恐惧之一。
这就是为什么我总是在任何项目中包含“高级”SQL 和指导。
我的答案
如果我回答你问题的每一部分，或者如果我回答其他一些答案中的错误元素，那么这个答案将会非常长。例如。上面只回答了一项。因此，我将全面回答您的问题，而不涉及具体组成部分，并采取不同的方法。我只会涉及与你的问题相关的科学，我有资格并且非常有经验。
Let me present the science to you in manageable segments.
The typical model of the six large scale full implementation assignments.
So we contemplated the laws of physics, and we applied a little science.
We implemented the Standard concept that the data belongs to the corporation (not the departments) and the corporation wanted one version of the truth. The Database was pure Relational, Normalised to 5NF. Pure Open Architecture, so that any app or report tool could access it. All transactions in stored procs (as opposed to uncontrolled strings of SQL all over the network). The same developers for each app coded the new apps, after our "advanced" education.
显然，科学是有效的。嗯，这不是我的私人科学或魔法，而是普通的工程和物理定律。所有这些都运行在一个数据库服务器平台上；两对（生产和灾难恢复）服务器已退役并交给另一个部门。 5 个总计 720GB 的“数据库”被标准化为一个总计 450GB 的数据库。大约 700 个表（许多重复项和重复列）被规范化为 500 个不重复的表。它的执行速度要快得多，整体速度快了 10 倍，某些功能的速度快了 100 倍以上。这并不让我感到惊讶，因为那是我的意图，科学也预测到了这一点，但它让那些拥有咒语的人感到惊讶。
更多标准化
好吧，在每个项目中标准化都取得了成功，并且对所涉及的科学充满信心，标准化是一个自然的进展more， 不低于。以前3NF就足够了，后来NF还没有被识别出来。在过去 20 年里，我只交付了零更新异常的数据库，因此根据今天的 NF 定义，我一直交付 5NF。
同样，5NF 很棒，但也有其局限性。例如。旋转大型表（不是按照 MS PIVOT 扩展的小型结果集）的速度很慢。因此，我（和其他人）开发了一种提供标准化表格的方法，使得数据透视（a）简单并且（b）非常快。事实证明，既然 6NF 已经被定义，那么这些表就是 6NF。
由于我从同一个数据库提供 OLAP 和 OLTP，我发现，与科学一致，结构越规范化：
他们表现得越快
并且它们可以以更多方式使用（例如枢轴）
所以，是的，我有一致且不变的经验，规范化不仅比非规范化或“非规范化”快得多；而且more标准化甚至比less正常化。
成功的标志之一是功能的增长（失败的标志是规模的增长但功能的增长）。这意味着他们立即要求我们提供更多报告功能，这意味着我们更加规范化，并提供了更多这些专用表（几年后，结果是 6NF）。
Progressing on that theme. I was always a Database specialist, not a data warehouse specialist, so my first few projects with warehouses were not full-blown implementations, but rather, they were substantial performance tuning assignments. They were in my ambit, on products that I specialised in.
Let's not worry about the exact level of normalisation, etc, because we are looking at the typical case. We can take it as given that the OLTP database was reasonably normalised, but not capable of OLAP, and the organisation had purchased a completely separate OLAP platform, hardware; invested in developing and maintaining masses of ETL code; etc. And following implementation then spent half their life managing the duplicates they had created. Here the book writers and vendors need to be blamed, for the massive waste of hardware and separate platform software licences they cause organisations to purchase.
与此同时，回到农场（5NF 数据库上面）我们只是不断添加越来越多的 OLAP 功能。当然，应用程序的功能有所增长，但这很小，业务没有改变。他们会要求更多的 6NF，而且很容易提供（5NF 到 6NF 是一小步；0NF 到任何东西，更不用说 5NF，都是一大步；有组织的架构很容易扩展）。
OLTP 和 OLAP 之间的一大区别，其基本理由separateOLAP平台软件，是OLTP是面向行的，它需要事务性安全的行，并且速度快； OLAP 不关心事务问题，它需要列，而且速度快。这就是所有高端 BI 或 OLAP 的原因平台是面向列的，这就是 OLAP 的原因models（星型模式、维度事实）是面向列的。
但对于 6NF 表：
没有行，只有列；我们以相同的速度提供行和列
这些表（即 6NF 结构的 5NF 视图）是already组织成维度事实。事实上，它们被组织成比任何 OLAP 模型所能识别的更多维度，因为它们是all方面。
Pivoting entire tables with aggregation on the fly (as opposed to the PIVOT of a small number of derived columns) is (a) effortless, simple code and (b) very fast
根据定义，我们多年来一直提供的是关系数据库，对于 OLTP 使用至少具有 5NF，对于 OLAP 要求至少具有 6NF。
请注意，这与我们从一开始就使用的科学完全相同。移动自典型的非标准化“数据库” to 5NF企业数据库。我们只是简单地申请more经证实的科学，并获得更高的功能和性能。
注意之间的相似性5NF企业数据库 and 6NF企业数据库
单独的 OLAP 硬件、平台软件、ETL、管理、维护的全部成本都被消除。
数据只有一个版本，无更新异常或维护；相同的数据以行的形式提供给 OLTP，以列的形式提供给 OLAP
我们唯一没有做的事情就是开始一个新项目，并从一开始就声明纯 6NF。这就是我接下来要排队的。
什么是第六范式？
假设您掌握了规范化（我不会在这里定义它），与该线程相关的非学术定义如下。请注意，它适用于表级别，因此您可以在同一数据库中混合使用 5NF 和 6NF 表：
6NF 是什么样的？
数据模型属于客户，我们的知识产权不可免费发布。但我确实访问了这个网站，并提供了问题的具体答案。您确实需要一个真实的示例，因此我将发布我们内部实用程序之一的数据模型。
该数据用于收集任何时期任何客户的服务器监控数据（企业级数据库服务器和操作系统）。我们用它来远程分析性能问题，并验证我们所做的任何性能调整。该结构十多年来没有改变（添加，没有改变现有结构），这是典型的专业5NF，多年后被确定为6NF。允许完全旋转；在任何维度上绘制的任何图表或图表（提供 22 个枢轴，但这不是限制）；切片和切丁；连连看。注意他们是all方面。
监控数据或指标或向量可以更改（服务器版本更改；我们想要获取更多内容），而不会影响模型（您可能还记得在另一篇文章中我说过 EAV 是 6NF 的私生子；这就是完整的 6NF，未稀释的父亲，因此提供了 EAV 的所有功能，而不牺牲任何标准、完整性或关系力）；您只需添加行。
▶监控统计数据模型◀ http://www.softwaregems.com.au/Documents/Documentary%20Examples/sysmon%20Public.pdf。 （对于内联来说太大；某些浏览器无法加载内联；单击链接）
它使我能够生产这些▶这样的图表◀ http://www.softwaregems.com.au/Documents/Documentary%20Examples/sequoia%20091019%20Server%20Public.pdf，在收到客户的原始监控统计文件后按六次按键。注意混合搭配；操作系统和服务器在同一张图表上；各种枢轴。 （经许可使用。）
不熟悉关系数据库建模标准的读者可能会发现▶IDEF1X 表示法◀ http://www.softwaregems.com.au/Documents/Documentary%20Examples/IDEF1X%20Notation.pdf有帮助。
6NF 数据仓库
这一点最近得到了验证锚建模 http://www.anchormodeling.com/，因为他们现在将 6NF 作为数据仓库的“下一代”OLAP 模型。 （他们不提供来自单一版本数据的 OLTP 和 OLAP，那是我们自己的）。
数据仓库（仅限）经验
我仅在数据仓库（不是上述 6NF OLTP-OLAP 数据库）方面有过几项主要任务的经验，而不是完整的实施项目。结果并不令人意外：
与科学一致，标准化结构的执行速度要快得多；更容易维护；并且需要较少的数据同步。英蒙，不是金博尔。
与魔术一致，在我对一堆表格进行归一化，并通过应用物理定律大幅提高性能后，唯一令人惊讶的是魔术师的口头禅。
有科学头脑的人不会这样做；有科学头脑的人不会这样做。他们不相信也不依赖灵丹妙药和魔法；他们利用科学并努力工作来解决他们的问题。
有效的数据仓库理由
这就是为什么我在其他帖子中说过，唯一的valid单独的数据仓库平台、硬件、ETL、维护等的理由是存在许多数据库或“数据库”，所有这些都被合并到一个中央仓库中，用于报告和 OLAP。
Kimball
有必要谈谈 Kimball，因为他是数据仓库中“非规范化性能”的主要支持者。根据我上面的定义，他是那些拥有显然他们的生活从未正常化；他的起点是非标准化的（伪装为“非标准化”），他只是在维度事实模型中实现了这一点。
当然，为了获得任何表现，他必须更加“去规范化”，并创造更多的重复，并证明这一切是合理的。
因此，通过制作更专门的副本，以一种精神分裂的方式“去规范化”非规范化结构，“提高了读取性能”，这是事实。当考虑到整体时，情况就不是这样了。只有在那个小庇护所内才是如此，在外面则不然。
同样，以这种疯狂的方式，当所有“表”都是怪物时，“连接是昂贵的”也是应该避免的。他们从未有过连接较小桌子和集合的经验，因此他们无法相信“更多、更小的桌子速度更快”这一科学事实。
他们有经验creating重复的“表”更快，所以他们无法相信消除重复的速度甚至比这更快。
他的尺寸是added到非标准化数据。数据没有标准化，因此没有暴露任何维度。而在规范化模型中，维度已经公开，作为数据的组成部分，没有addition是必须的。
金博尔那条铺得很好的路通向悬崖，在那里更多的旅鼠会更快地坠落死亡。旅鼠是群居动物，只要它们一起走路，一起死，它们就死得很开心。旅鼠不会寻找其他路径。
所有这些都只是故事，是一个神话的一部分，相互关联、相互支持。
您的使命
你是否应该选择接受。我要求你独立思考，停止任何与科学和物理定律相矛盾的想法。无论它们多么常见、神秘或神话。在相信任何事情之前先寻找证据。保持科学性，为自己验证新的信念。重复“为了性能而去规范化”的口头禅不会让你的数据库变得更快，它只会让你感觉更好。就像坐在场边的胖孩子告诉自己，他可以比比赛中的所有孩子跑得更快。
问题 ？
