2

我对使用 Microstrategy 报告复杂的雪花 SQL Server 数据库相关的评论和见解感兴趣，该数据库由几个事务性规范化 (3NF) 表组成。

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

事务表也有自己的维度，等等。这些视图似乎在 SSRS 中运行良好。但是，我读到 Microstrategy 并不适合针对如此复杂的数据库进行报告（不是因为工具的性能，而是因为在 Microstrategy 中构建这些指标时 SQL 的复杂性）。

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

任何建议或意见表示赞赏。

4

4 回答 4

3

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

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

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

这种说法有很多原因。我不会详述所有的原因。您最好的选择是获得 Kimbal 关于维度建模的任何优秀书籍。

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

希望这可以帮助。

于 2013-09-24T15:24:10.003 回答
1

如果你知道你在 SQL 端做什么，并且知道 MSTR 生成的 SQL 需要如何改变以避免隐藏连接，那么你可以使用一个逻辑表，添加到相关的属性形式中，以影响生成的 SQL直接地。查找逻辑视图。

于 2013-09-12T23:19:55.717 回答
1

多年前我使用过微观策略工具。我的评论可能不是最新的。在当时，它是对抗星型模式的完美 rolap 工具。它可以生成许多优化的 SQL 语句来提供结果集。但是它在第 3 范式 db 上运行不正常。

在第三种范式数据库中，我建议使用替代工具，例如可以处理任何类型数据库结构的业务对象。我已经在一个再保险 OLTP 系统之上看到了一个业务对象宇宙，该系统具有 5000 多个第 3 范式表/视图，并且运行良好。但是，当您开始使用第 3 范式时，很难为所有可能的查询提供正确的结果，而且与非规范化星型模式相比，它会慢很多。

于 2013-04-04T11:58:54.100 回答
1

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

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

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

这样做的真正美妙之处在于，您的聚合可以根据您的报告进行定制，并且您可以获得惊人的性能。

于 2013-03-25T13:03:49.367 回答