我在事实表上做了一点R＆amp; D，无论它们是标准化还是非标准化。 我遇到了一些令我困惑的发现。
根据Kimball：
维度模型结合了规范化和非规范化表格结构。描述性信息的维度表在同一个表中具有高度非规范化，具有详细和分层的汇总属性。同时，具有性能指标的事实表通常是标准化的。虽然我们建议不要在单独的表中使用snowflaked维度属性进行完全规范化（为业务用户创建类似暴雪的条件），但是在同一个表中包含度量和描述的单个非规范化大型宽表也是不明智的。
另一个发现，我认为我也没关系，by fazalhp at GeekInterview：
DW的主要基础是对数据进行反规范化，以便报告工具更快地访问...所以如果你构建一个DW ..90％它必须被去规范化，当然事实表必须是de normalized ...
所以我的问题是，事实表是规范化还是非规范化的？如果其中任何一个如何＆amp;为什么呢？
答案 0 :(得分：4)
从关系数据库设计理论的角度来看，维度表通常在2NF和2NF到6NF之间的事实表中。
然而，维度建模本身就是一个 methodology ，专为：
一个用例，即报告
主要是查询的一种基本类型（模式）
一个主要用户类别 - 业务分析师或类似的
行存储RDBMS，如Oracle，SQl Server，Postgres ......
一个独立控制的加载/更新过程（ETL）;所有其他客户端都是只读的
还有其他DW设计方法，比如
Inmon＆＃39; - 数据结构驱动
Data Vault - 数据结构驱动
主播建模 - 模式演变驱动
主要的是不要将数据库设计理论与特定的设计方法混为一谈。您可以通过数据库设计理论的角度来看待某种方法，但必须分别研究每种方法。
答案 1 :(得分：1)
大多数使用数据仓库的人都熟悉事务性RDBMS并应用各种级别的规范化，因此这些概念用于描述星型模式的工作。他们正在做的是试图让你忘掉所有那些正常化的习惯。这可能会让人感到困惑，因为人们倾向于关注什么＆＃34; not＆＃34;要做。
事实表可能是最正常化的，因为它们通常只包含数值以及用于链接到维度的各种id。它们与事实表的关键在于您需要多少粒度来获取数据。 “购买”的示例可以是按订单中的产品划分的特定订单项，也可以是每日，每周，每月级别的汇总。
我的建议是继续搜索和研究如何根据您的需求设计仓库。不要寻求高水平的标准化形式。请仔细考虑您要生成的报告以及为用户提供的分析功能。