为啥维度取决于MDX中的属性

Posted 2023-03-29

【中文标题】为啥维度取决于MDX中的属性

【英文标题】：Why does dimensionality depend on the attribute in MDX为什么维度取决于MDX中的属性

【发布时间】：2020-11-30 06:14:46

【问题描述】：

对于我的生活，我无法弄清楚为什么 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 认为它们具有不同的维度 (?)。

【参考方案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 中的一个人

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