征求意见：非规范化 Fact 和 Dim 表以提高 SSRS 报告的性能答案

【问题标题】：Seeking Opinion:Denormalising Fact and Dim tables to improve performance of SSRS Reports征求意见：非规范化 Fact 和 Dim 表以提高 SSRS 报告的性能
【发布时间】：2017-08-22 17:18:16
【问题描述】：

我们似乎对团队中的某个讨论点进行了一些辩论。我们正在开发 Microsoft SQL Server 2012 平台中的数据仓库。我们遵循 Kimball 架构来构建这个数据仓库。

问题：

从该仓库获取数据的报告解决方案（基于 SSRS 构建）在从事实表和暗表获取数据时存在严重的性能问题。我们的一些团队成员建议我们使用 SSIS 包从事实和暗淡中提取数据到一组新的表中。这意味着我们将这些表非规范化为“快照”表。这样，我们就不需要连接这些表来在报告中创建数据集。可以直接从这些表中读取数据。

我确实对此有自己的担忧；不一致、不同数据结构的维护、数据重复等。

问题：

您是否认为为报告表创建快照表（通过非规范化事实和暗表）是一种正确的方法？

想听听您对此的看法。

干杯尼丁

【问题讨论】：

我想对此有一个深思熟虑的答案，并在我能想到的情况下提出替代方案。但首先，您能否更多地解释所讨论的事实和问题，或许可以举一个例子（即使只是说明性的）来说明差异。特别是，我想通过非规范化事实和暗表来了解您的意思。无论如何，维度通常是非规范化的，事实要么是事务性的，要么是快照，要么是累积快照。您是在谈论在交易事实之外制作快照吗？另外，您可以访问 SSAS 吗？
您是否在为下拉列表等提供动力时遇到了麻烦（它更喜欢源列上的不同值列表），还是比这更大？

标签： reporting data-warehouse

【解决方案1】：

我不认为快照表有什么问题。数据仓库最重要的两个方面是：

数据正确。
数据很有用。

如果您的用户无法在合理的时间范围内提取所需的总数，他们将不会使用仓库。

我自己的解决方案包括 3 个快照表。像你一样，我担心不一致。为了解决这个问题，我们建立了一个自动检查流程。该子系统每小时执行一次存储在网络驱动器上的一系列查询。查询返回的任何记录都被视为失败。我的 ETL 团队会报告失败并立即进行调查。该子系统确保快照和基础事实始终相互对齐和一致。防止漂移。

也就是说，额外的表格等于额外的复杂性。这需要更多的时间/精力来管理。在将另一层引入您的仓库之前，您应该调查为什么这些查询表现不佳。如果连接是罪魁祸首：

您的 P/F 键是否使用了不合适的数据类型？
FKeys 是否被索引（某些 RDBMS 默认会这样做，而其他人不会）？
对于有问题的查询，您是否查看过执行计划？
真的应该归咎于连接，还是应用到暗表的过滤器？

【讨论】：

谢谢...我相信团队仍然需要回答我们提出的一些问题，并且您提出的观点与我们提出的问题非常吻合...您的想法再次证实了这一点我们走在正确的轨道上..干杯 Nithin

【解决方案2】：

对于原始多维数据集性能，我的建议是始终尝试对表进行非规范化，并为每个维度（星型模式）设置一个事实表和一个表。如果您不确定它是否真的有帮助，您可以开始创建物化视图。这些是两全其美的，从长远来看，你应该改变你的 etl。在我以前的工作中，我们只有工作得很好的扁平表。目前我们有一个规范化的模式，但在最后一步将其展平。

【讨论】：

提问者说他们已经使用 Kimball 构建了数据仓库，这就是你描述的情况，所以我假设他们的意思是别的！
重读帖子后我仍然不确定。也许op会按照你的建议澄清他的问题。
嗨 Rich/Kaylon 这只是一个示例：有一个 Fact_Sales，具有昏暗的 Dim_Location 和 Dim_Product 以及 Dim_Date。理想情况下，如果我要报告销售指标，我会在 Fact 表的顶部编写一个查询，然后根据键加入 Dim_Location 和 Dim_Product 和 Dim_Date。查询的结果将通过报告报告。一些团队成员希望在查询中加入表，然后应该通过 ETL 包将其馈送到聚合表中。在此表之上运行的报告将提供更好的性能。这是一个好习惯吗？？干杯尼廷