微结构优化数据库结构

使用带有微结构的星型模式其实没什么大不了的。只需要一点适应,它就可以用这种格式生成很好的查询。

从一位经验丰富的MSTR顾问那里,我听说MSTR真正喜欢的数据形状是一种经过修改的雪花。其中,数据维度建模为雪花,但每一层都包含其上层次结构中表的数据。

我想你可以在JumpStart项目中看到这个模式。位于此处: http://www.microstrategy.com/BI-application-jumpstart/

最后,我认为你应该继续使用最适合你的技术。逻辑数据模型的设置不应该太麻烦,并且MSTR有大量的性能优化技术(缓存、内存中的多维数据集等),您可以应用后遗症来增强功能。

我在土耳其的一家银行工作,我们已经在Microstrategy工作了3年多。我们确实有20多个不同的项目在不同的数据库和不同的模式类型上运行。当设计(和实现)正确时,MSTR非常能够处理星型模式,并且生成相当好的SQL语句。不过,我应该说,在设计架构时,习惯MSTR的父子关系和查找/事实表处理可能会很麻烦。但一旦你克服了它,它就很方便了。

在过去的八年里,我很高兴(或者其他方面)与微结构学合作。我认为公平地说,该产品设计用于第三种正常形式的模式。也就是说,使用以这种方式设计的模式在工具中建模对象是最简单的。

正如Ugur所说,MSTR非常能够使用星型模式,并且根据您的数据,使用星型模式(用于性能目的)可能更好,即使在微结构项目中建模有点(或很多)困难。

当我们在2007年开始研究微结构时,我们合作的微结构顾问告诉我们星型模式是可以的,但是他们的技术在雪花型模式下效果最好。不同的是,维度是标准化的,即,您有日、周、月、季度和年维度表,而不是时间维度表。由于我们在运输和物流行业运营,我们的数据仓库有许多复杂的关系,但数据量不大;表与兆字节的比率很高。在正统的形式中,星型和雪花型模式都只通过一致的维度连接事实表,有一段时间,我们认为这是一个“混合”模式,在事实表之间连接。最后,我们选择了一个规范化的数据仓库结构作为最适合公司的结构。

我们花了好几个月的时间,在仓库表的基础上开发和改进了微结构模式对象的标准,最终开发出了非常健壮的模式。这些模式没有得到很好的认可,据我所知,也没有被其他微结构客户广泛使用。它们生成了非常复杂的SQL,我们收到了非常好的响应时间,甚至对于特别的报告,因为我们使用Netezza作为数据仓库。缺点是,遵循该模式所需的应用程序对象的数量远远高于其他模式,开发新指标的专业知识水平也很高。我们成功地培训了所有的BI用户使用现有的度量标准(由专业的BI团队开发)。此BI/DW解决方案目前正在使用中。

因此,我认为微观结构并不是为标准化数据仓库模式构建的,尽管它们的技术非常可靠,并且足够强大,可以在这样的数据库上运行。他们的首选模式是雪花,有标准化的维度表和标准事实表。