我对使用Microstrategy对由多个事务规范化(3NF)表组成的复杂雪花SQL Server数据库进行报告的评论和见解很感兴趣。
具体来说，在这样的环境下，什么是最好的方法或挑战?目前，有一些复杂的视图使用多个事务表之间的复杂SQL连接作为分析事实表。
事务表也有自己的维度，等等。这些视图似乎在SSRS中工作得很好。然而，我读到Microstrategy并不适合针对如此复杂的数据库进行报告(不是因为工具的性能，而是因为在Microstrategy中构建这些指标的SQL的复杂性)。
在这样的环境下，什么是最好的报告方法?在当前数据仓库上构建SSAS多维数据集是个好主意吗?是应该在数据库上进行报告，还是应该创建一个新的数据库或集市，专门供Microstrategy使用，只提供基本报告的相关视图?我不知道这是否仍然是一个活跃的线程，但这里有一些想法。
事务数据库，在我看来，不是最好的报告BI。关系模型适用于日常报告和运营报告。
然而，一旦您决定生成BI报告，您就需要为您的数据仓库使用维度模型。我从艰难的经历中学到了这一点。这条规则不仅适用于MicroStrategy，也适用于任何希望实现BI报告的软件产品。
这句话有很多原因。我就不一一列举了。你最好的办法是找一本由Kimbal写的关于维度建模的好书。
我试过使用几个不同的报告包，包括MicroStrategy，你的项目是否工作的最大决定因素是你的BI仓库是否有一个良好的维度数据库设计。这当然意味着使用某种ETL过程将关系数据转换为维度数据。
无论您使用什么报告工具，如果您在后台有复杂的雪花连接，您都会遇到性能问题。这是因为每个运行报告的用户都会导致运行相同的SQL—一些工具有聪明的缓存，但是当您有用户选择提示时，这就失效了。
SSAS多维数据集是一个很好的选择，只要您的用户对此感到满意，但理想的方法是为您的报表设计数据聚合表(您可以称之为迷你数据集市)。
只有当您有足够的时间刷新聚合表时，这才有效——如果您的用户需要实时数据，这不是一个容易的选择，但是您可以安排一个聚合过程以设置的间隔运行。
真正的美妙之处在于，您的聚合可以根据您的报告进行定制，并且您可以获得惊人的性能。
很多年前我就使用过Microstrategy工具。我的评论可能不是最新的。在那个时候，它是一个针对星型模式的完美折叠工具。它可以生成许多优化的SQL语句来提供结果集。然而，它不是在第三正常形式db工作。
对于第三种正常形式的数据库，我建议使用一种替代工具，比如可以处理任何类型的数据库结构的业务对象。我曾经在一个再保险OLTP系统上看到过一个业务对象宇宙，它有5000多个第三种格式的表/视图，运行得很好。但是当你开始使用第三范式时，很难为所有可能的查询提供正确的结果，而且与非规范化的星型模式相比，它会慢得多。
如果您知道在SQL端做什么，并且知道MSTR生成的SQL需要如何更改以避免隐藏连接，那么您可以使用添加到相关属性表单的逻辑表来直接影响生成的SQL。查看逻辑视图