在高度规范化的SQL Server数据库上使用Microstrategy

Question

我感兴趣的是有关使用Microstrategy报告复杂雪花SQL Server数据库的评论和见解，该数据库包含多个事务规范化（3NF）表。

具体而言，在这样的环境中报告的最佳方法或挑战是什么？目前，有一些复杂的视图用作使用多个事务表之间的复杂SQL连接的分析事实表。

事务表也有自己的维度，依此类推。这些观点似乎在SSRS中运作良好。但是，我已经读过，Microstrategy不适合报告这样一个复杂的数据库（不是因为该工具的性能，而是因为在Microstrategy中构建这些指标时SQL的复杂性）。

在这样的环境中报告的最佳方法是什么？在当前数据仓库上构建SSAS多维数据集是一个好主意吗？是应该在数据库上进行报告，还是应该创建一个新的数据库或市场，专门用于Microstrategy，只有基本报告的相关视图？

感谢任何建议或意见。

Answer 1

我不知道这是否仍然是一个活跃的主题，但这里有一些想法。

在我看来，交易数据库并不是报告BI的最佳选择。关系模型适用于日常报告和运营报告。

但是，一旦决定生成BI报告，就需要为数据仓库使用维度模型。我通过艰苦的经历学到了这一点。这不仅适用于MicroStrategy，也适用于任何希望进行BI报告的软件产品。

这种说法有很多原因。我不会介绍所有的原因。你最好的选择是获得Kimbal关于尺寸建模的任何优秀书籍。

我尝试使用几种不同的报告包，包括MicroStrategy，以及您的项目是否有效的最大决定因素是您的BI仓库是否具有良好的维度数据库设计。这当然意味着使用某种ETL过程将关系数据转换为维度数据。

希望这有帮助。

Answer 2

无论您使用哪种报告工具，如果您在后台使用复杂的雪花连接，都会遇到性能问题。这是因为每个运行报告的用户都会导致运行相同的SQL - 某些工具具有智能缓存，但是当您有用户选择的提示时，这会降低。

只要您的用户对此感到满意，SSAS多维数据集就是一个不错的选择，但理想的方法是为您的数据设置聚合表（您可以将其称为迷你数据集市），这些表专为您的报告而设计。

只有当您能够花时间刷新聚合表时，这才有效 - 如果您的用户需要实时数据，这不是一个简单的选择，但是您可以安排聚合过程在设定间隔。

真正的美妙之处在于，您的聚合可以根据您的报告量身定制，并且您可以获得惊人的表现。

Answer 3

多年前我使用过Microstrategy工具。我的评论可能不是最新的。那时它是一个完美的反对星型模式的折叠工具。它可以生成许多优化的SQL语句来提供结果集。但是它在第3个普通表格db上运行不正常。

在第三个普通形式的数据库中，我建议使用另一种工具，比如可以处理任何类型的数据库结构的业务对象。我已经看到一个业务在一个重新保险的OLTP系统之上，拥有5000+第三范式表/视图，并且工作正常。但是当你开始使用第三范式时，很难为所有可能的查询提供正确的结果，而且与非规范化的星型模式相比，它会慢得多。

Answer 4

如果你知道你在SQL端做了什么，并且知道MSTR生成的SQL需要如何更改以避免隐藏的连接，那么你可以使用添加到相关属性表单的逻辑表来影响直接生成的SQL。查看逻辑视图。