OLAP数据库是否需要非规范化才能读取性能？

我一直认为数据库应该是非规范化的读取性能，因为它是为OLAP数据库devise完成的，并没有夸大3NF太多的OLTPdevise。

PerformanceDBA在各种岗位上，例如，针对基于时间的数据的不同方式的performance，通过规范化为5NF和6NF（标准forms）来维护数据库应该总是精心devise的范例。

我的理解是否正确（以及我理解的正确）？

OLAP数据库（低于3NF）的传统非规范化方法/范式devise出现什么问题？3NF对OLTP数据库的大多数实际情况是否足够？

例如：

  • “简单的事实是，6NF，正确执行，是数据仓库”（PerformanceDBA）

我应该承认，我无法理解非规范化促进阅读performance的理论。 任何人都可以给我提供这个和相反的信念的合理解释吗？

在试图说服我的利益相关者说OLAP /数据仓库数据库应该正常化时，我可以参考哪些资源？

为了提高可见性，我从这里复制了评论：

“如果参与者在他们已经看到或参与的6NF中添加（披露）了多less实际（不包括科学项目）的数据仓库实施，这将是一件好事。 – Damir Sudarevic

维基百科的数据仓库文章告诉：

“Ralph Kimball的标准化方法（也称为Ralph Kimball的一维方法）也被称为3NF模型 （第三范式），其支持者被称为”Inmonites“，他们相信Bill Inmon的方法，其中声明数据仓库应该是使用ER模型/标准化模型进行build模“。

看起来规范化的数据仓库方法（Bill Inmon）被认为不超过3NF（？）

我只想了解什么是数据仓库/ OLAP是非规范化的同义词的神话（或无处不在的公理化信仰）的起源？

Damir Sudarevic回答说，他们的做法很好。 让我回到这个问题：为什么非规范化被认为有利于阅读？

神话

我一直认为数据库应该是非规范化的阅读，因为它是为OLAP数据库devise完成的，并没有为OLTPdevise进一步夸大3NF。

这是一个神话。 在关系数据库环境中，我重新实现了六个非常大的所谓“非标准化”数据库。 并执行八十多个任务，纠正他人的问题，只要简单化，运用标准和工程原则。 我从来没有看到任何神话的证据。 只有重复咒语的人才像是某种神奇的祈祷。

标准化与非标准化

（“非正常化”是我拒绝使用的欺诈性术语。）

这是一个科学工业（至less是那些提供不会中断的软件，把人送上月球，运行银行系统等等）。 它受物理定律的支配，而不是魔法。 计算机和软件都是有限的，有形的物理对象，受物理定律的约束。 根据我接受的中学和高等教育：

  • 一个更大，更胖，更less组织的对象不可能比一个更小，更薄，更有组织的对象更好地执行。

  • 规范化会产生更多的表格，是的，但是每个表格要小得多。 即使有更多的表，实际上（a）更less的连接和（b）连接更快，因为集合更小。 总体上需要更less的索引，因为每个较小的表需要较less的索引。 规格化的表格也可以产生更短的行数。

  • 对于任何给定的资源集合，规范化表格：

    • 将更多行放入相同的页面大小
    • 因此将更多行放入相同的caching空间，因此整体吞吐量增加）
    • 因此将更多行放入同一磁盘空间，因此I / O数量减less; 当需要I / O时，每个I / O更高效。
      。
  • 重复复制的对象不可能比存储为真实单一版本的对象更好地执行。 例如。 当我在表格和专栏层面删除了5个副本时，所有交易的规模都缩小了; locking减less; 更新exception消失。 这大大减less了争用，因此增加了并发使用。

总的结果是，性能要高得多。

根据我的经验，即从同一个数据库提供OLTP和OLAP，从来没有需要“规范化”我的规范化结构，以获得更高的只读（OLAP）查询速度。 这也是一个神话。

  • 不，其他人要求的“非正常化”速度降低了，被淘汰了。 对我来说并不奇怪，但请求者又一次感到惊讶。

许多书籍是由人们写的，出售神话。 需要认识到，这些是非技术性的人员; 因为他们卖魔术，他们卖的魔法没有科学依据，他们在销售方面很方便地避开了物理定律。

（对于任何想要质疑上述物理科学的人，只要重复一下这个咒语就没有任何作用，请提供具体的证据来支持这个咒语。）

为什么神话是普遍的？

那么，首先，在科学types中并不普遍，谁也不想克服物理定律。

根据我的经验，我发现了三个主要原因：

  1. 对于那些不能规范化数据的人来说，这样做是不合理的。 他们可以参考魔法书，没有任何证据certificate魔法，他们可以恭敬地说：“看一位着名作家证实我所做的事”。 没有完成，最准确的。

  2. 许多SQL编码器只能编写简单的单级SQL。 规范化的结构需要一些SQLfunction。 如果他们没有的话; 如果他们不能在不使用临时表的情况下产生SELECT; 如果他们不能写子查询，他们会心理上粘到平面文件（这是“非规范化”结构），他们可以处理。

  3. 人们喜欢读书，讨论理论。 没有经验。 特别是重新魔术。 这是一种补品，是实际经验的替代品。 任何实际上对数据库进行了规范化的人都从来没有说过“非标准化比标准化快”。 对任何人说出口头禅，我只是说“给我看证据”，他们从来没有产生过任何证据。 所以现实就是，人们因为这些原因重复神话， 没有任何规范化的经验 。 我们是从众动物，而未知是我们最大的恐惧之一。

    这就是为什么我总是在任何项目中包含“高级”SQL和指导。

我的答案

如果我回答你的问题的每个部分，或者如果我回答其他答案中的不正确的元素，这个答案将是可笑的长。 例如。 以上只回答了一个项目。 因此，我将在不涉及具体组成部分的情况下回答您的问题，并采取不同的方法。 我只会处理与你的问题有关的科学，我有资格，而且很有经验。

让我在可pipe理的部分向你展示科学。 典型的第一代“数据库”
六大规模全面实施任务的典型模式。

  • 这些是在小公司中常见的封闭“数据库”，这些组织是大型银行
  • 第一代非常好，运行得心应手，但在性能，完整性和质量方面却完全失败
  • 他们分别为每个应用程序devise
  • 报告是不可能的，他们只能通过每个应用程序进行报告
  • 由于“非正常化”是一个神话，准确的技术定义是，它们是非标准化的
    • 为了“去规范化”，首先要规范化; 那么在人们向我展示他们的“非标准化”数据模型的每一个例子中，稍微改变这个过程，简单的事实是，他们根本没有标准化; 所以“非正常化”是不可能的。 这只是非正常化
  • 因为他们没有太多的关系技术，或者数据库的结构和控制，但是他们是作为“数据库”传递的，所以我把这些单词放在了引号中
  • 如果在科学上保证了非标准化的结构，那么他们就会遭受多重版本的事实（数据重复），因此在每个版本中都存在较高的争用和较低的并发性
  • 他们在“数据库”中还有一个额外的数据重复问题，
  • 该组织试图保持所有这些重复同步，所以他们实施了复制; 这当然意味着一个额外的服务器; ETL和同步脚本进行开发; 并保持; 等等
  • 不用说，同步是不够的，他们永远改变它
  • 所有这些争论和低吞吐量，为每个“数据库”提供一个单独的服务器是没有问题的。 这并没有太大帮助。

所以我们考虑物理定律，并且运用了一点科学。 5NF企业数据库
我们实现了数据属于公司（而不是部门）的标准概念，公司希望得到一个真实的版本。 该数据库是纯关系，规范化为5NF。 纯开放式架构，以便任何应用程序或报告工具都可以访问它。 存储过程中的所有事务（而不是整个networking中不受控制的SQLstring）。 在我们的“高级”教育之后，每个应用程序的相同开发人员编写新的应用程序。

显然，科学的工作。 那么，这不是我的私人的科学或魔法，这是普通的工程学和物理定律。 所有这些都运行在一个数据库服务器平台上; 两台服务器（生产和DR）退役并交给另一个部门。 总共720GB的5个“数据库”被标准化为总共450GB的一个数据库。 大约700个表格（许多重复的和重复的列）被标准化为500个不重复的表格。 它的执行速度要快得多，总体速度要快10倍，而在某些function上要快100倍以上。 这并没有让我感到意外，因为那是我的意图，科学预测了这一点，但却用咒语使人们感到惊讶。

更规范化

那么，在每一个项目中都已经取得了规范化的成功，而且对于科学的信心，自然而然的就是规范化，而不是更less。 在过去的3NF是足够好的，后来NFs还没有确定。 在过去的20年中，我只提供了零更新exception的数据库，所以从现在的NF定义来看，我一直都是5NF的。

同样的，5NF也很棒，但也有其局限性。 例如。 旋转大型表格（根据MS PIVOT扩展名而不是小型结果集）很慢。 所以我（和其他人）开发了一种提供标准化表格的方法，以便枢轴（a）容易和（b）非常快速。 事实certificate，现在已经定义了6NF，那些表是6NF。

由于我从同一个数据库提供OLAP和OLTP，我发现，与科学一致，结构更为标准化：

  • 他们执行的速度越快

  • 他们可以用更多的方式（例如枢轴）

所以是的，我有一贯的，不变的经验，不仅规范化很多，比非规范化或“非规范化”要快得多。 更规范化的速度比规范化的速度更快。

成功的一个标志是function的增长（失败的迹象是规模的增长，function没有增长）。 这意味着他们立即要求我们提供更多的报告function，这意味着我们的规范化程度更高 ，并提供了更多的专业表格（多年后成为6NF）。

在这个主题上取得进展。 我一直是数据库专家，而不是数据仓库专家，所以我最初的几个有仓库的项目并不是成熟的实现，而是大量的性能调优任务。 他们在我的专业范围内。 典型的数据仓库
让我们不要担心正常化的确切程度等，因为我们正在看典型的情况。 我们可以认为OLTP数据库是合理标准化的，但是不支持OLAP，并且该组织购买了一个完全独立的OLAP平台硬件; 投资开发和维护大量的ETL代码; 等等。然后，执行完后，他们花了一半时间pipe理他们创build的副本。 在这里，书籍作者和供应商需要被指责，硬件的巨大浪费和导致组织购买的单独的平台软件许可证。

  • 如果您还没有观察到它，我会要求您注意典型第一代数据库和典型数据仓库之间的相似之处

同时，回到农场（上面的5NF数据库 ），我们只是不断添加更多的OLAPfunction。 当然，应用程序的function增长了，但是很less，业务并没有改变。 他们会要求更多的6NF，而且很容易提供（5NF到6NF是一小步，0NF对任何事情，更不用说5NF，是一大步，有组织的架构很容易扩展）。

OLTP和OLAP之间的一个主要区别是， 单独的 OLAP平台软件的基本理由是OLTP是面向行的，它需要事务安全的行，并且速度很快; 而OLAP不关心事务性问题，它需要专栏，而且快速。 这就是所有高端BI或OLAP 平台都是以列为导向的原因，这就是为什么OLAP 模型 （Star Schema，Dimension-Fact）是以列为导向的。

但是与6NF表：

  • 没有行，只有列; 我们以相同的盲目速度提供行和列

  • 表格（即6NF结构的5NF视图） 已经被组织成了维度事实。 事实上，它们被组织成更多的维度，而不是任何OLAP模型所能识别的，因为它们都是维度。

  • （a）不费力，简单的代码和（b）速度非常快 典型的数据仓库

根据定义，我们已经提供多年的关系数据库至less有5NF用于OLTP使用，6NF用于OLAP需求。

  • 请注意，这是我们从一开始就使用的一门科学。 从典型的非标准化“数据库”转移到5NF公司数据库 。 我们只是应用更多的经过validation的科学，并获得更高的function和性能指令。

  • 注意5NF企业数据库和6NF企业数据库的相似之处

  • 单独的OLAP硬件，平台软件，ETL，pipe理，维护的全部成本都被消除了。

  • 只有一个版本的数据，没有更新exception或维护; 将相同的数据作为OLTP处理为行，将OLAP作为列处理

我们唯一没有做的就是从一个新项目开始，从一开始就宣布纯6NF。 那就是我接下来排队的东西。

什么是第六范式？

假设你有一个规范化的句柄（我不打算在这里定义它），与这个线程相关的非学术定义如下。 请注意，它适用于表级别，因此可以在同一个数据库中混合使用5NF和6NF表：

  • 第五范式 ：在数据库中解决的所有function依赖关系
    • 除了4NF / BCNF
    • 每个非PK列与PK都是1 :: 1
    • 并没有其他的PK
    • 没有更新exception
      。
  • 第六范式 ：是不可约的NF，数据不能被进一步减less或归一化的点（不会有7NF）
    • 除了5NF
    • 该行由一个主键组成，最多有一个非键列
    • 消除了空问题

6NF是什么样的？

数据模型属于客户，我们的知识产权不可用于免费发布。 但是我确实参加了这个网站，并提供了具体的问题答案。 你确实需要一个真实世界的例子，所以我将发布我们的一个内部工具的数据模型。

这是为任何时间的任何客户收集服务器监控数据（企业级数据库服务器和操作系统）。 我们使用它来远程分析性能问题，并validation我们所做的任何性能调优。 十多年来结构没有变化（增加了，现有结构没有变化），多年后被认定为6NF的是5NF的典型特征。 允许完全旋转; 在任何维度上绘制任何图表或图表（22个枢轴提供，但不是限制）; 切片和骰子; 连连看。 注意他们都是尺寸。

监控数据或度量或vector可以改变（服务器版本的变化，我们想要更多的东西），而不会影响模型（你可能会记得在另一篇文章中我说EAV是6NF的混蛋儿子，这是完整的6NF，未经稀释的父亲，因此在不牺牲任何标准，完整性或关系能力的情况下提供EAV的所有特征）; 你只需添加行。

▶监控统计数据模型◀ 。 （内联过大;有些浏览器无法加载内联;单击链接）

它允许我在收到客户的原始监控统计文件后，生成这些▶这样的图表 ，六个按键。 注意混搭; 操作系统和服务器在同一张图上; 各种枢轴。 （经许可使用）

不熟悉关系数据库build模标准的读者可能会发现▶IDEF1X符号有用。

6NF数据仓库

最近， Anchor Modelingvalidation了这一点，他们现在将6NF作为数据仓库的“下一代”OLAP模型。 （他们不提供从单一版本的数据，这是我们自己的OLTP和OLAP）。

数据仓库（唯一）的经验

我仅使用数据仓库（不是上述的6NF OLTP-OLAP数据库）的经验，与完全实施项目相比，有几项主要任务。 结果并不令人意外：

  • 与科学一致，标准化结构执行得更快; 更容易维护; 并且需要更less的数据同步。 Inmon，而不是Kimball。

  • 与魔术一致后，我规范了一堆桌子，并通过应用物理定律，提供大幅改善的performance，唯一令人惊讶的是魔术师与他们的咒语。

科学头脑的人不这样做; 他们不相信或依靠银弹和魔法; 他们运用科学的方法来解决他们的问题。

有效的数据仓库理由

这就是为什么我在其他文章中说过，单独的数据仓库平台，硬件，ETL，维护等的唯一有效的理由是存在许多数据库或“数据库”，这些数据库或“数据库”被合并到中央仓库中，用于报告和OLAP。

金博尔

关于Kimball的一句话是必要的，因为他是数据仓库中“非正常化”的主要支持者。 按照我上面的定义，他是那些在生活中显然没有正常化的人之一， 他的出发点是非归一化的（被伪装成“非归一化”），他只是在一个维度事实模型中实现。

  • 当然，为了获得任何表演，他必须更“去规范化”，创造更多的重复，并为此辩解。

    • 因此，以精神分裂的方式确实是这样，通过制作更专业化的副本来“去规范化”非规范化的结构，“提高阅读效果”。 整体考虑时是不正确的; 只是在那个小的收容所里面，不是外面的。

    • 同样，疯狂地说，所有的“桌子”都是怪物，“连接是昂贵的”，还有一些应该避免的地方。 他们从来没有join小桌子的经验，所以他们不敢相信科学的事实，更多的小桌子更快。

    • 他们有创build重复“表格”的经验，所以他们不能相信消除重复的速度比这更快。

  • 他的维度被添加到未标准化的数据。 那么数据没有规范化，所以没有维度暴露。 而在标准化模型中，尺寸已经公开，作为数据的组成部分，不需要添加 。

  • 那条铺好的金宝球的道路通向悬崖，在那里更多的旅鼠死亡，更快。 旅鼠是牲畜，只要一起走路，一起死去，就会快乐。 旅鼠不寻找其他path。

所有只是故事，一个神话的一部分挂在一起，相互支持。

你的使命

如果你select接受它。 我要求你自己思考，停止接受任何违背科学和物理定律的思想。 无论他们是多么普遍，神秘或神话。 在相信任何东西之前寻找证据。 要科学，为自己validation新的信念。 重复“性能不规范”的口头禅不会让你的数据库更快，它只会让你感觉更好。 就像坐在场边的肥胖孩子告诉自己，比起比赛中的所有孩子，他跑得快。

  • 在这个基础上，即使是“OLTP正常化”这个概念，反之，“OLAP反正常化”也是一个矛盾。 物理定律如何在一台计算机上运行，​​而在另一台计算机上运行呢？ 头脑发呆。 这是不可能的，每台电脑上的工作方式都是一样的。

问题？

非规范化和聚合是用于在数据仓库中实现性能的两个主要策略。 这只是愚蠢的build议，它不会提高阅读性能！ 当然，我一定是在这里误解了一些东西？

聚合：考虑一个持有10亿次购买的表格。 将它与一个包含购买总和的一行对比。 现在，哪个更快？ 从十亿行表中select总和（金额）还是从单行表中select一个金额？ 这当然是一个愚蠢的例子，但它很清楚地说明了聚合的原理。 为什么它更快？ 因为不pipe我们使用什么神奇的模型/硬件/软件/宗教，读取100字节比读取100千兆字节更快。 就那么简单。

非规范化：零售数据仓库中的典型产品维度包含大量列。 有些列很容易就像“名字”或“颜色”，但也有一些复杂的东西，比如层次结构。 多个层次（产品范围（5个层次），预期买方（3个层面），原材料（8个层面），生产方式（8个层面）以及多个计算数字，如平均提前期（自年初以来） ，重量/包装等等我维护了一个产品维度表，其中包含来自5个不同来源系统的约70个表格的200多个列，关于归一化模型的查询（下文） 

select product_id from table1 join table2 on(keys) join (select average(..) from one_billion_row_table where lastyear = ...) on(keys) join ...table70 where function_with_fuzzy_matching(table1.cola, table37.colb) > 0.7 and exists(select ... from ) and not exists(select ...) and table20.version_id = (select max(v_id from product_ver where ...) and average_price between 10 and 20 and product_range = 'High-Profile'

…比非规范化模型上的等价查询更快： 

 select product_id from product_denormalized where average_price between 10 and 20 and product_range = 'High-Profile';

为什么？ 部分原因与汇总情况相同。 但也因为查询只是“复杂”。 他们是如此令人厌恶的复杂，以至于优化器（现在我正在讨论Oracle的细节）变得混乱，并且搞砸了执行计划。 如果查询处理less量的数据，那么次最佳的执行计划可能不是那么重要。 但是，只要我们开始join大表格，数据库就能正确执行执行计划是至关重要的。 使用一个同步键对一个表格中的数据进行非规范化处理（嘿嘿，为什么我不会在这个持续的火灾中增加更多的燃料），这些filter就变成了简单的范围/相等的filter。 将数据复制到新列中后，我们可以收集列上的统计数据，帮助优化程序评估select性，从而为我们提供适当的执行计划（以及…）。

很明显，使用非规范化和聚合使得适应模式更改变得更加困难，这是一件坏事。 另一方面他们提供阅读performance，这是一件好事。

那么，为了实现读取性能，是否应该对数据库进行非规范化处理？ 一定不行！ 它给你的系统增加了太多的复杂性，所以在你交付之前，有多less种方法会使你无法完成。 这值得么？ 是的，有时你需要做到这一点，以满足特定的性能要求。

更新1

PerformanceDBA：1行会每天更新10亿次

这意味着（接近）实时需求（反过来会产生一组完全不同的技术要求）。 许多（如果不是大多数）数据仓库没有这个要求。 我select了一个不切实际的聚合示例，以清楚说明为什么聚合起作用。 我不想解释汇总策略也:)

另外，还需要对比数据仓库的典型用户和底层OLTP系统的典型用户的需求。 一位用户希望了解哪些因素可以推动运输成本，如果缺less50％的今天的数据，或者10辆卡车爆炸并杀死驾驶员，他们也不会轻视。 对两年的数据进行分析仍然会得出同样的结论，即使他掌握了第二次最新的信息。

对比这个卡车司机的需求（幸存者）。 他们不能在某个中转站等5个小时，只是因为一些愚蠢的聚合过程需要芬兰人。 有两个单独的数据副本解决了这两个需求。

在操作系统和报告系统中共享同一组数据的另一个主要障碍是发布周期，问答，部署，SLA和你有什么不同。 再次，有两个单独的副本，这使得更容易处理。

通过“OLAP”，我了解到您指的是用于决策支持的面向主题的关系/ SQL数据库 – 也称为数据仓库。

正常forms（通常是第五/第六正常forms）通常是数据仓库的最佳模式。 数据仓库规范化的原因与其他数据库完全相同：它减less了冗余，避免了潜在的更新exception; 它避免了内置偏见，因此是支持模式更改和新需求的最简单方法。 在数据仓库中使用正常表单还有助于保持数据加载过程的简单性和一致性。

没有“传统的”非规范化方法。 良好的数据仓库一直是正常化的。

不应该为了读取性能而使数据库非规范化？

好吧，这里总共有“你的里程可能有所不同”，“取决于”，“为每个工作使用适当的工具”，“一个尺寸不适合所有”的答案，有一点“不要修复它，如果它不坏“抛出：

非规范化是在某些情况下提高查询性能的一种方法。 在其他情况下，实际上可能会降低性能（因为增加了磁盘使用）。 这当然会使更新更加困难。

只有当你遇到性能问题时才应该考虑这个问题（因为你正在给规范化带来好处，并引入复杂性）。

反规范化的缺点是不会更新数据，或者只在批处理作业中更新，即不是OLTP数据。

如果非规范化解决了您需要解决的性能问题，而较less侵入性的技术（如索引或caching或购买更大的服务器）无法解决，那么是的，您应该这样做。

首先我的意见，然后一些分析

意见
非规范化被认为有助于阅读数据，因为常规使用非规范化单词通常不仅包括打破常规forms，而且还将任何插入，更新和删除依赖项引入到系统中。

严格来说，这是错误的 ，看到这个问题/答案 ，严格意义上的非规范化意味着打破任何1NF-6NF的正常forms，而其他插入，更新和删除依赖关系则用正交devise原则来解决。

那么会发生什么呢是人们采取空间与时间的权衡原则，并记住冗余（与去标准化相关，仍然不等于它）这一术语，并得出结论认为你应该有好处。 这是错误的暗示，但是错误的暗示不允许你做出相反的结论。

打破常规forms可能确实会加快一些数据检索的速度（下面的分析细节），但通常也会在同一时间：

  • 只支持特定types的查询并减慢所有其他访问path
  • 增加系统的复杂性（这不仅影响数据库本身的维护，而且增加了消耗数据的应用程序的复杂性）
  • 混淆和削弱数据库的语义清晰度
  • 作为代表问题空间的中心数据，在logging事实时要毫无偏见，这样当需求发生变化时，不必重新devise实际上独立的系统部分（数据和应用程序）。 为了能够做到这一点，应该尽量减less人为的依赖关系 – 现在“加速查询”的“关键”要求往往变得非常重要。

分析

所以，我声称有时打破正常的forms可以帮助检索。 有时间给一些论据

1）打破1NF

假设你在6NF有财务logging。 从这样的数据库，你肯定可以得到每个月份每个账户余额的报告。

假设一个需要计算这样的报告的查询需要经过n条logging，你可以创build一个表 

 account_balances(month, report)

这将为每个帐户保存XML结构余额。 这打破了1NF（见后面的注释），但允许一个特定的查询以最小的I / O执行。

与此同时，假设可以通过插入，更新或删除财务logging来更新任何月份，系统上更新查询的执行速度可能会随着每次更新的某个函数n而变慢。 （上面的例子说明了一个原则，实际上你会有更好的select，获得最小I / O带来的好处带来了这样的惩罚：对于实际更新数据的现实系统，即使对于有针对性的查询，types的实际工作量;如果你愿意，可以更详细地解释这一点）

注：这实际上是一个微不足道的例子，它有一个问题 – 1NF的定义。 假设上述模型打破1NF是根据一个属性的值“ 恰好包含来自适用域的一个值 ”的要求。

这允许你说，属性报告的域是一组所有可能的报告，并且从它们中都有一个值，并声称1NF没有被破坏（类似于存储单词不会中断1NF的论点你可能在你的模型中有letters关系）。

另一方面，还有更好的方法来模拟这个表格，这对更广泛的查询（比如一年中所有月份的单个账户的检索余额）更有用。 在这种情况下，你可以通过说这个字段不在1NF中来certificate这个改进。

无论如何，这解释了为什么人们声称打破NFs可能会提高性能。

2）打破3NF

假设3NF表 

 CREATE TABLE `t` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `member_id` int(10) unsigned NOT NULL, `status` tinyint(3) unsigned NOT NULL, `amount` decimal(10,2) NOT NULL, `opening` decimal(10,2) DEFAULT NULL, PRIMARY KEY (`id`), KEY `member_id` (`member_id`), CONSTRAINT `t_ibfk_1` FOREIGN KEY (`member_id`) REFERENCES `m` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB CREATE TABLE `m` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB

带有样本数据（t中的1M行，m中的100k）

假设您想要改进的通用查询 

 mysql> select sql_no_cache m.name, count(*) from t join m on t.member_id = m.id where t.id between 100000 and 500000 group by m.name; +-------+----------+ | name | count(*) | +-------+----------+ | omega | 11 | | test | 8 | | test3 | 399982 | +-------+----------+ 3 rows in set (1.08 sec)

你可以findbuild议将属性name移动到表格m中，该表格打破了3NF（它有一个FD：member_id – > name，member_id不是t的关键字）

后 

 alter table t add column varchar(255); update t inner join m on t.member_id = t.id set t.name = m.name;

赛跑 

 mysql> select sql_no_cache name, count(*) from t where id between 100000 and 500000 group by name; +-------+----------+ | name | count(*) | +-------+----------+ | omega | 11 | | test | 8 | | test3 | 399982 | +-------+----------+ 3 rows in set (0.41 sec)

注意：上面的查询执行时间被削减了一半 ，但是

  • 这张桌子并没有在5NF / 6NF开始
  • 该testing是使用no_sql_cache完成的，所以大多数caching机制都被避免了（在实际情况下，它们在系统性能中扮演着angular色）
  • 空间消耗增加了大约9倍大小的列名x 100k行
  • 应该有触发器来保持数据的完整性，这将显着减缓所有更新的名称，并添加额外的检查，插入在T将需要通过
  • 可能更好的结果可以通过放弃代理键和切换到自然键和/或索引或重新devise到更高的NF

规范化是长远的正确方法。 但是，您并不总是可以select重新devise公司的ERP（例如，已经只有大部分3NF） – 有时您必须在给定的资源范围内完成某些任务。 当然，这只是短期的“解决scheme”。

底线

我认为，对你的问题最恰当的答案是，你会发现工业和教育使用“去标准化”

  • 严格意义上说，是为了打破NFs
  • 松散地介绍任何插入，更新和删除依赖关系 （原始的Codd关于规范化的评论说：' 不受欢迎的 （！）插入，更新和删除依赖关系'， 在这里看到一些细节）

因此，在严格的定义下，汇总（汇总表）不被视为非规范化，它们可以在性能方面提供很大的帮助（任何caching都不会被视为非规范化）。

如前所述，宽松的用法包括打破常规forms和 正交devise的原则 。

还有一点可以说是逻辑模型和物理模型之间有一个非常重要的区别。

例如，索引存储冗余数据，但没有人认为它们是非规范化的，即使是松散地使用该术语的人也没有，并且有两个（连接的）原因

  • 他们不是逻辑模型的一部分
  • 它们是透明的，保证不会破坏模型的完整性

如果你没有对逻辑模型进行正确的build模，那么最终会出现数据库不一致的情况 – 实体之间的关系错误（无法表示问题空间），冲突的事实（信息松散的能力），你应该使用任何方法来获得一个正确的逻辑模型，它是build立在它之上的所有应用程序的基础。

谓词的规范化，正交和清晰的语义，明确定义的属性，正确识别的函数依赖性都是避免陷阱的一个因素。

在物理实现方面，事情变得更为宽松，因为依赖于非关键字的物化计算列可能会破坏3NF，但是如果存在保证一致性的机制，则它与物理模型中的索引相同是可以的，但是你必须非常仔细地certificate它是正确的，因为通常正常化将会产生相同或更好的改进，并且不会有或者更less的负面影响，并且将保持devise清晰（这降低了应用开发和维护成本）您可以轻松地花在升级硬件上以提高速度，甚至可以通过打破NF来实现。

构build数据仓库的两种最stream行的方法似乎是Bill Inmon和Ralph Kimball。

Inmon的方法使用标准化的方法，而Kimball使用的是尺寸build模 – 非标准化的星型模式。

这两个都有很好的文件logging到小细节，都有许多成功的实现。 双方都提出了一个“宽广的，铺好的道路”的DW目的地。

我不能评论6NF方法，也不能评论锚定build模，因为我从来没有见过也没有参与使用这种方法的DW项目。 当谈到实现时，我喜欢沿着经过良好testing的path旅行 – 但是，那只是我自己。

那么，总结一下，DW应该正常化还是非正常化？ 取决于你select的方法 – 只要select一个，坚持下去，至less直到项目结束。

编辑 – 一个例子

在我现在工作的地方，我们有一个传统的报告，从生产服务器上就一直运行。 这不是一份简单的报告，而是每天发送给每个人和他的ant的30个分报告。

最近，我们实施了一个DW。 有了两台报表服务器和大量的报表，我希望我们可以忘记遗留问题。 但是，遗产是遗产，我们一直拥有它，所以我们需要它，需要它，不能没有它，等等。

事情是python脚本和SQL的混乱每8个小时（是，八个小时）运行每一天。 毋庸置疑，数据库和应用程序是由几批开发人员构build的，所以不完全是您的5NF。

是时候重新创buildDW的遗留问题了。 好的，保持它的简短，完成后需要3分钟（三分钟），每个子报告需要6秒。 而且我急于交付，所以甚至没有优化所有的查询。 这是因为8 * 60/3 = 160倍的速度 – 更不用说从生产服务器上移除八小时作业的好处。 我想我还可以剃一分钟左右，但现在没人在乎。

作为一个兴趣点，我已经使用了Kimball的DW（维度build模）方法，这个故事中使用的所有东西都是开源的。

这就是所有这些（数据仓库）应该是关于，我想。 使用哪种方法（标准化或非标准化）甚至无关紧要？

编辑2

作为一个兴趣点，Bill Inmon在他的网站上发表了一篇很好的论文 – “两个架构的故事” 。

“非规范化”这个词的问题在于它没有明确指出进入的方向。这就像是试图从芝加哥赶到纽约去旧金山。

星型模式或雪花模式当然不是标准化的。 在某些使用模式中，它肯定比正规模式执行得更好。 但是也有一些非规范化的例子，devise师根本没有遵循任何纪律，只是用直觉来组织表格。 有时候这些努力不会出来。

总之，不要只是规范化。 如果你对自己的好处有信心，即使它不符合标准化的devise，也要遵循不同的devise原则。 但是不要使用非规范化作为偶然devise的借口。

简短的答案是不解决你没有得到的性能问题 ！

至于基于时间的表，普遍接受的方法是在每一行都有valid_from和valid_todate。 这基本上仍然是3NF，因为它只是把语义从“这是这个实体的唯一的版本”改为“这是这个实体的唯一版本”

简化：

一个OLTP数据库应该被标准化（只要有意义）。

应将OLAP数据仓库非规范化为事实和维度表（以最小化连接）。

    Interesting Posts

    星型模式devise

    数据仓库与OLAP多维数据集？

    数据库和数据仓库有什么区别？

    大数据量的数据库select？

    数据仓库注意事项：何时和为什么？