多维设计中略有相关的维度

Question

我使用以下（简化）星型方案作为SSAS OLAP多维数据集的数据源：

在我的立方体中，我有测量[天]，它只包含＆＃34; 1＆＃34;对于每个日期 - 这只是获得某段时间内天数的简洁方法，对于计算每日平均值等非常有用。显然，此度量与商店和员工维度无关。

现在，比方说，我使用以下MDX查询：

SELECT { [SalesAmount], [Days] } on 0,
    { [Shop].[Shop].[Shop].members } on 1
FROM
    [MyCube]
WHERE
    ( [Shop].[Country].[USA], [Calendar].[Month].&[201406] )

这将返回美国所有商店的列表，其中包含2014年6月的销售额以及6月份的天数。它按预期工作，性能很好。

现在说，我想要相同的列表，但除了商店，我想按员工分割销售额。当然，我将Employee-dimension与Shop-dimension交叉：

SELECT { [SalesAmount], [Days] } on 0,
    { [Shop].[Shop].[Shop].members * 
      [Employee].[Employee].[Employee].members } on 1
FROM
    [MyCube]
WHERE
    ( [Shop].[Country].[USA], [Calendar].[Month].&[201406] )

这有两个问题：首先，当跨越这两个（可能）大尺寸时，性能会受到很大影响。其次，对于那些与美国商店无关的员工，我获得了许多销售金额= NULL的记录。如果我删除[Days]度量，我会得到预期的结果，但我需要每日平均值等度量。

我正在寻找替代方法来建模我的立方体，以避免这个问题。也就是说，当我通过Shop维度过滤我的事实表时，我只需要显示来自Employee维度的相关记录（因此该帖子的标题，因为Employee和Shop维度通过事实表相关）。

我考虑将Shop和Employee维度合并为一个单一的组织＆＃34;维度，但这会产生多个问题：首先，员工可能在多个商店工作，并且随着时间的推移，关联可能会发生变化。

注意：我不是在寻找替代的MDX解决方案，因为我的最终用户使用各种前端工具，他们无法控制生成的MDX。我认为问题应该在多维建模中解决，而不是在前端解决。建模技术和文献参考将非常感激。

Answer 1

如果您可以在商店下面雇员，可以避免跨越2个独立的维度。这将改善我相信的表现。

Answer 2

我不确定您的解决方案是否属于这种情况，但在我使用类似Days措施的措施的情况下，有必要计算几个计算的度量，但没有必要最终用户可以查看Days度量本身。因此，只是让措施不可见可以解决您的问题：

由于用户无法在普通客户端工具中选择度量，因此查询将不包含员工和商店组合的记录，这些记录在factSales表中没有共同记录。如果客户端工具在行上使用NON EMPTY，则至少会出现这种情况，大多数工具默认情况下这样做。而且由于结果集要小得多，它也应该更快地到达客户端工具，大概解决了性能问题。

您应该注意计算度量的表达式，在没有数据时将结果保持为NULL。如何执行此操作取决于您定义的措施。

您应该知道，只要用户能够手动输入MDX表达式，即使它不可见，他们也可以使用该度量。多维数据集中提供了一个不可见的度量，可以在MDX查询中使用。它没有列在许多客户端工具显示的度量列表中。但是，如果用户故意使用Days度量，因为他们知道它在那里，并且他们知道度量的名称，因此可以在MDX表达式中输入它们，他们应该意识到他们需要在一个MDX中设计他们的MDX。避免你遇到的问题的方法。无论如何，这些用户将是“超级用户”。