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

Question

我在事实表上做了一些R & D，无论它们是标准化的还是非标准化的。 我遇到了一些让我困惑的发现。

根据Kimball：

三维模型结合规范化和非规范化表结构。描述性信息的维度表在相同表中具有高度非规范化的细节和分层累积属性。同时，具有性能指标的事实表通常被标准化。尽管我们建议不要在单独的表中为完全标准化的雪花尺寸属性（为商业用户创建类似于暴风雪的条件），但同一个表中包含度量和描述的单个非规范化大宽表也是不明智的。

其他发现，这也是我，我认为是好的，by fazalhp at GeekInterview：

DW的主要丰达被解归一化数据，以供报表工具更快速的访问...因此，如果乌尔建立一个DW.90％它必须被去标准化，并且当然事实表必须被标准化...

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

Answer 1

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

然而，三维建模是methodology你们自己，量身定制：

• 一个用例，即报告查询

• 主要是一个基本类型（模式）

• 一个主要用户类别 - 业务分析师或类似

• 像Oracle，SQl服务器，Postgres一样的行存储RDBMS ...

• 一个独立控制的加载/更新过程（ETL）;所有其他客户端都只读

还有其他DW设计方法在那里，像

• Inmon的 - 数据结构驱动

• 数据存储库 - 数据结构驱动

• 锚点建模 - 架构演变驱动

最重要的不是混淆数据库设计理论与特定的设计方法。您可以通过数据库设计理论的角度来看待某种方法，但必须分别研究每种方法。

Answer 2

大多数使用数据仓库的人都熟悉事务性RDBMS并应用各种标准化级别，因此这些概念用于描述工作星型模式。他们正在做的是试图让你忽略所有这些规范化习惯。这可能会让人困惑，因为有一种倾向于专注于“不”做的事情。

事实表可能是最规范化的，因为它们通常只包含数值以及用于链接到维度的各种ID。他们使用事实表的关键在于您需要如何获取数据。 “采购”示例可以是订单中产品的特定订单项，也可以是每日，每周，每月的汇总数。

我的建议是继续搜索和研究如何根据您的需求设计仓库。不要期望达到高水平的规范化形式。仔细考虑要生成的报告和分析功能，以便为用户提供帮助。