事实表是规范化的还是非规范化的？

Question

我对事实表做了一些研究和开发，不管它们是标准化还是非规范化。我偶然发现了一些让我困惑的发现。

根据金波

量纲模型结合了规范化和非正规化的表格结构。描述性信息的维度表高度非规范化，在同一表中具有详细和分层的卷起属性。同时，具有性能指标的事实表通常是规范化的。虽然我们建议不要在单独的表中使用完全规范化的雪花维属性(为业务用户创建类似暴风雪的条件)，但对于包含同一表中的度量和描述的单个非规范化大宽表也是不明智的。

另一个发现，我也认为是可以的，由fazalhp在GeekInterview

DW的主要功能是对数据进行非规范化，以使reporting tool...so更快地访问数据，如果您构建了一个DW ..90%，那么它必须是非规范化的，而事实表必须是非规范化的。

所以我的问题是，事实表是规范化的还是非规范化的？如果其中任何一个，那么怎么&为什么？

Answer 1

从关系数据库设计理论的角度来看，维度表通常在2NF中，事实表在2NF和6NF之间。

然而，维度建模本身就是一种方法论，专门为以下目的量身定做：

• 一个用例，即报告
• 主要是查询的一种基本类型(模式)
• 一个主要的用户类别--业务分析师，或类似的
• 行存储关系数据库，如甲骨文，SQl服务器，邮政.
• 一个独立控制的加载/更新过程(ETL)；所有其他客户端都是只读的。

还有其他的数据仓库设计方法，比如

• Inmon's --数据结构驱动
• 数据仓库.数据结构驱动
• 锚模型.模式演化驱动

主要是不要将数据库设计理论与具体的设计方法相混淆.您可以从数据库设计理论的角度来看待某种方法，但必须分别研究每一种方法。

Answer 2

大多数使用数据仓库的人都熟悉事务RDBMS，并应用不同级别的规范化，因此这些概念用于描述工作星型模式。他们所做的是试图让你忘记所有那些正常化的习惯。这可能会让人感到困惑，因为人们倾向于专注于“不”去做什么。

事实表可能是最标准化的，因为它们通常只包含数字值和各种id，用于链接到维度。事实表的关键是您需要如何获取数据的粒度。采购的一个例子可以是按产品在订单中按产品分列的特定项目，或者在每日、每周、每月的水平上进行汇总。

我的建议是继续寻找和研究如何根据您的需要设计一个仓库。不要寻找到高水平的规范化形式。更多地考虑您想要生成的报告和为用户提供的分析功能。