为什么维度取决于MDX中的属性

Question

对于我的生活，我无法弄清楚为什么 MDX 在维度而不是键上定义每个属性的维度。也许我在这里误解了一些东西，但如果我理解正确的话，这似乎是一种非常奇怪的方式。假设我有以下数据：

Person

• ID（密钥）
• 姓名
• 年龄

我有一些这样的数据：[('Tom123', 'Tom', 15), ('Brad456', 'Brad', 16)。

现在，为什么我可以通过以下两种方式选择两个用户：

{Person.Name.Tom, Person.Name.Brad}

或者：

{Person.ID.Tom123, Person.ID.Brad456}

但不是以下方式：

{Person.Name.Tom, Person.ID.Brad456}

然而，所有三种方式都使用相同的“维度”甚至“维度”，因为所有三种方式唯一地处理相同的两个Person 实体！

这对我来说似乎很奇怪，因为它们都使用相同的“维度”和“维度”，并且应该能够使用该维度的键，而不是认为每个属性都是唯一的。为什么会这样？或者，我是不是误会了什么。

如果我们使用这张图片：

如果我们通过执行{Product.TV, Geography.Asia, Time.Q1} 或执行{Product.TV, Geography.Asia, Time.Quarter One} 来处理单个多维数据集（元组），这有什么关系。它们只是做完全相同事情的两种方式，但 MDX 认为它们具有不同的维度 (?)。

Answer 1

这是一个非常好的问题。

然而，所有三个都使用相同的“维度”甚至“维度”，因为 所有三种方式都唯一地寻址相同的两个 Person 实体！

这对我来说似乎很奇怪，因为它们都使用相同的 'dimension' 和 'dimensionality' 并且应该能够使用 Key for 这个维度而不是认为每个属性都是唯一的。为什么是 这样吗？或者，我是不是误会了什么。

因此，对于任何语言，语法都会先于其他任何内容进行检查。您所指的案例是唯一可以忽略维度的实例。但是语言首先评估数据是不明智的（就 SSAS 和 MDX 而言，它称为 AttributeID）。其次，这将使用户更加困惑。以你的例子为基础

{Person.Name.Tom, Person.ID.Brad456}

让我们在纽约有 100 人，所以按照你的逻辑，下面是 该集合将是 {Person.City.Newyork}，然后 MDX 将替换所有 100 个 ID。这将阻止 MDX 使用聚合，这是 CUBE 的最大优势。大多数发送到多维数据集的查询都是针对汇总数据的。 MDX 中的大多数查询需要整个 NEWYORK 的数据，而不是 NEWYORK 中的一个人

总而言之，编译时间会增加，聚合将无法使用。