我的大部分职业生涯都将数据仓库\市场开发为星型模式，因为它们通常与 Microsoft 的分析服务一起使用。但是，我们开始利用 MicroStrategy 9.0.1，并且有人告诉我，星型模式对于这个平台来说并不是最优的。MicroStrategy 在这个话题上没有官方立场，所以我想我会问这个社区。我应该继续使用非规范化结构，还是应该考虑针对这个平台采用更规范化的方法？
我的意图不是发起 Kimball vs. Inmon vs etc 战争，任何现实世界的经验都会受到赞赏
问问题
6350 次
4 回答
1
我在土耳其的一家银行工作，我们与 MicroStrategy 合作已超过 3 年。我们确实有超过 20 个不同的项目在不同的数据库和不同的模式类型上运行。当设计（和实现）正确时，MSTR 非常有能力处理星型模式，并且生成适度好的 sql 语句。在设计架构时习惯于 MSTR 的父子和查找/事实表处理可能会很麻烦，但我应该说。但是一旦你克服了它，它就很方便了。
于 2010-09-25T15:50:37.600 回答
1
在过去的八年里，我很高兴（或以其他方式）与 MicroStrategy 一起工作。我认为可以公平地说，该产品旨在与第三范式中的模式一起使用。也就是说，使用以这种方式设计的模式在工具中建模您的对象将是最容易的。
正如 Ugur 所说，MSTR 非常有能力使用星型模式，并且根据您的数据，使用星型模式（出于性能目的）可能会更好，即使在模型中建模有点（或很多）困难微策略项目。
于 2010-10-22T18:08:10.497 回答
1
在 MicroStrategy 中使用星型模式实际上并没有什么大不了的。它只需要一点时间来适应，它会生成具有该格式的精细查询。
从一位经验丰富的 MSTR 顾问那里，我听说 MSTR 真正喜欢的数据形状是一种经过修改的雪花。其中数据维度被建模为雪花，但每一层都包含其上方层次结构中表的数据。
我想你可以在 jumpstart 项目中看到这种模式。位于此处： http: //www.microstrategy.com/BI-application-jumpstart/
最终，我认为您应该继续使用最适合您的技术。逻辑数据模型的设置应该不会太麻烦，而且 MSTR 有大量的性能优化技术（缓存、内存中的多维数据集，...），您可以在后面应用这些技术来解决问题。
于 2010-10-22T18:15:47.147 回答
1
当我们在 2007 年开始走 MicroStrategy 之路时，与我们合作的 MicroStrategy 顾问告诉我们，星型模式还可以，但他们的技术最适合雪花模式。不同之处在于维度是标准化的，也就是说，您有 Day、Week、Month、Quarter 和 Year 维度表，而不是 Time 维度表。因为我们在运输和物流行业运营，我们的数据仓库有很多复杂的关系，但数据量不是很大；高“表与 TB 的比率”。在正统的形式中，星型和雪花模式都仅通过一致的维度连接事实表，并且有一段时间我们考虑了在事实表之间连接的“混合”模式。最后，我们选择了标准化的数据仓库结构，作为最适合公司的结构。
我们花了几个月的时间在我们的仓库表上开发和完善我们的 MicroStrategy 模式对象标准，并最终开发出非常健壮的模式。这些模式没有得到很好的认可，据我所知，其他 MicroStrategy 客户并未广泛使用这些模式。它们生成了非常复杂的 sql，我们收到了极好的响应时间，即使是临时报告，因为我们使用 Netezza 作为我们的数据仓库。不利的一面是遵循该模式所需的应用程序对象数量远高于其他模式，并且开发新指标的专业知识水平很高。我们成功地培训了所有 BI 用户使用现有指标（由专业 BI 团队开发）。这种 BI/DW 解决方案目前正在积极使用。
因此，我认为 MicroStrategy 不是为规范化的数据仓库模式而构建的，尽管他们的技术非常可靠，并且足够强大，可以在这样的数据库上运行。他们首选的模式是雪花模式，带有标准化维度表和标准事实表。
于 2011-02-11T00:34:21.663 回答