我正在尝试构建一个数据仓库。
我有很多维度和几个度量 - 事实。每个度量都与所有业务相关的维度相连。标准方法是使用一个大的事实表，其中包含所有度量。
但我有一个想法：如果我为每个度量使用单独的事实表会怎样？这会对数据库性能、解决方案可扩展性等方面产生什么影响？
编辑：在非常复杂的企业环境中基于OLAP立方体创建一个庞大的解决方案。因此，首先需要易于扩展和维护，然后是性能。
一个事实表还是多个事实表？
7
- John
2
为每个度量值分离一个事实表？你能具体说明一下你的想法吗？ - Diego
为每个度量单独创建一个事实表意味着将有与度量数量相同的事实表 - 每个表只包含一个度量，否则可以有一个包含所有度量的大型事实表。 - John
2个回答
10
简述：如果仅有一个事实表/度量值，我会看到可扩展性问题无处不在。
如果你的目标是“可扩展性和维护性”，那么你可能考虑遵循业界标准方法，例如Kimball并通过一致的维度将事实首先按业务过程进行分组，然后按粒度进行分组。 我很高兴争论一下，这将通过标准化提供最大的灵活性和可扩展性，同时确保可扩展性和维护性。
此外，如果你为每个度量值设计一个单独的事实表，你的SAN管理员将讨厌你，因为你实际上正在增加空间要求的度量值数量...至少在当前所有度量值适合单个事实表的情况下。
查询DW的性能也将是一个问题...报告和/或自定义查询将不得不每次需要组合多个度量值时扫描（或查找...如果你的SAN管理员仍在与你交谈并慷慨地授予你必要的空间来正确索引你的一系列事实表）。
我们甚至还没有讨论OLAP立方体，但我已经对你将遇到的处理问题感到担忧。 全表扫描无处不在...或分区扫描...如果你在事实表中实施了分区...而你现在应该这样做，因为SQL 2012正在到来...我在看着你ColumnStore Index！！
如果你的目标是“可扩展性和维护性”，那么你可能考虑遵循业界标准方法，例如Kimball并通过一致的维度将事实首先按业务过程进行分组，然后按粒度进行分组。 我很高兴争论一下，这将通过标准化提供最大的灵活性和可扩展性，同时确保可扩展性和维护性。
此外，如果你为每个度量值设计一个单独的事实表，你的SAN管理员将讨厌你，因为你实际上正在增加空间要求的度量值数量...至少在当前所有度量值适合单个事实表的情况下。
查询DW的性能也将是一个问题...报告和/或自定义查询将不得不每次需要组合多个度量值时扫描（或查找...如果你的SAN管理员仍在与你交谈并慷慨地授予你必要的空间来正确索引你的一系列事实表）。
我们甚至还没有讨论OLAP立方体，但我已经对你将遇到的处理问题感到担忧。 全表扫描无处不在...或分区扫描...如果你在事实表中实施了分区...而你现在应该这样做，因为SQL 2012正在到来...我在看着你ColumnStore Index！！
- Bill Anton
4
如果所有度量的粒度相同，则将它们保留在同一张表中。只有在具有不同粒度级别的事实时才开始使用多个事实表。鉴于您说的所有事实都与所有维度相关联，因此在这个阶段看起来您只需要一个事实表。
- Mike McAllister
2
可能会有各种变更请求，例如使维度更加粒度化或减少粒度，添加事实、添加维度等等。除了这些变更请求之外，还需要编写新的ETL来执行操作，而且ETL可能会消耗大量的CPU资源，需要长时间运行 - 可能需要重新计算数百万行数据等等。因此，我更倾向于从以下角度考虑 - 尽可能使可扩展性和维护性更容易。 - John
更改维度粒度、添加事实、添加维度...所有这些都需要进行ETL开发工作，无论您是否将每个事实隔离在单独的事实表中。 - Bill Anton
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接