我对与使用Microstrategy报告包含多个事务性规范化（3NF）表的复杂雪花SQL Server数据库相关的评论和见解很感兴趣。在高度规范化的SQL Server数据库上使用Microstrategy
具体来说，在这样的环境中报告的最佳方法或挑战是什么？目前，有一些复杂的视图用作使用多个事务表之间的复杂SQL连接的分析事实表。
交易表也有它们自己的尺寸，等等。这些观点似乎在SSRS中运行良好。但是，我已经看到，Microstrategy不适合用于报告这样一个复杂的数据库（不是因为该工具的性能，但更多的是因为在Microstrategy中构建这些度量标准时SQL的复杂性）。
在这样的环境中报告最好的方法是什么？在当前数据仓库中构建SSAS多维数据集是否是一个好主意？是否应该在数据库上进行报告，或者是否应该创建一个专门供Microstrategy使用的新数据库或集市，只有基本报告的相关视图？
任何意见或建议表示赞赏。
无论您使用哪种报告工具，如果您在后台有复杂的雪花连接，您都会遇到性能问题。这是因为每个运行报表的用户都会导致运行相同的SQL - 一些工具具有巧妙的缓存，但是当用户选择提示时会下降。
只要您的用户对此感到满意，SSAS立方体就是一个不错的选择，但理想的方法是为您的报告设计用于数据的聚合表格（您可以将其称为小型数据集市）。
只有当您可以承担刷新聚合表的时间时才有效 - 如果您的用户需要实时数据，这不是一个简单的选项，但是除此之外，您可以安排聚合过程以设置间隔。
真正的美妙之处在于您的聚合可以根据您的报告进行量身定制，并且您可以获得惊人的性能。
很多年前我使用了Microstrategy工具。我的评论可能不是最新的。那时它是一个完美的反对星型模式的漫画工具。它可以生成许多优化的SQL语句来提供结果集。然而，它不能正常工作在第三范式数据库。
在第三个常规表单db中，我会建议一个替代工具，比如可以处理任何类型的db结构的业务对象。我已经看到了一个业务处理系统，在一个具有5000多个第三常规表格/视图的再保险OLTP系统之上，并且工作正常。但是当你开始使用第三范式时，很难为所有可能的查询提供正确的结果，并且与非规范化的星型模式相比，它会慢很多。
如果你知道你在SQL方面做了什么，并且知道MSTR生成的SQL如何改变以避免隐藏的连接，那么你可以使用逻辑表，添加到相关的属性表单中直接影响生成的SQL。查找逻辑视图。
我不知道这是否仍然是一个活跃的线程，但这里有一些想法。
在我看来，交易数据库并非最适合报告BI。关系模型适用于日常报告和运营报告。
但是，一旦您决定生成BI报告，您需要为您的数据仓库使用维度模型。我通过艰苦的经历了解到了这一点。这不仅适用于MicroStrategy，也适用于希望进行BI报告的任何软件产品。
这种说法有很多原因。我不会去解释所有的原因。您最好的选择是获得Kimbal在Dimensional Modeling上出色的书籍。
我试图使用几种不同的报告包，包括MicroStrategy，以及项目是否能够正常工作的最大决定因素是您的BI仓库是否具有良好的维度数据库设计。这当然意味着使用某种ETL过程将关系数据转换为维数据。
希望这会有所帮助。
感谢用于分析的急性软件。完全同意缓存的方法。将所有复杂的SQL委托给非高峰刷新工作将基本上消除性能问题。不幸的是，在我的情况下，实时数据看起来是一项关键业务需求。虽然有选择性或“聪明”的缓存听起来很刺耳。急于开始使用该工具来查看它可以做什么。另外，据我所知，Microstrategy报告对象是针对Metadata Repository表作为其“数据集”运行的，并填充了来自SQL Server的转换结果。会很有趣.. – dmedz 2013-03-28 16:55:56