Database design 在高度规范化的SQL Server数据库上使用微策略

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

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

事务表也有自己的维度，以此类推。这些观点在SSR中似乎很有效。然而，我已经读到Microstrategy不适合针对如此复杂的数据库进行报告（这不是因为工具的性能，而是因为在Microstrategy中构建这些度量的SQL的复杂性）

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

---

任何建议或意见都将不胜感激。

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

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

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

---

这一点的真正好处在于，您的聚合可以根据您的报告进行定制，您可以获得惊人的性能。

我多年前就使用了Microstrategy工具。我的评论可能不是最新的。当时，它是一个针对星型模式的完美rolap工具。它可以生成许多优化的SQL语句来提供结果集。然而，它在第三标准格式数据库上工作不正常

---

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

如果您知道自己在SQL端执行的操作，并且知道MSTR生成的SQL需要如何更改以避免隐藏联接，那么您可以使用添加到相关属性表单的逻辑表直接影响生成的SQL。查找逻辑视图。

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

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

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

这种说法有很多原因。我不会详细说明所有的原因。你最好的选择是获得金巴尔关于尺寸建模的任何优秀书籍

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

---

希望这能有所帮助。

感谢acutesoftware的分析。完全同意缓存的方法。将所有这些复杂的SQL委托给非高峰刷新作业将从根本上消除性能问题。不幸的是，在我的情况下，实时数据似乎是一项关键的业务需求。尽管选择性或“聪明”的缓存听起来很有趣。渴望开始使用该工具，看看它能做什么。此外，据我所知，Microstrategy报表对象将元数据存储库表作为“数据集”运行，并使用SQL Server转换的结果填充。会很有趣的。。