Database design 维度也是度量值有意义吗

我目前正在大致利用维度建模方法研究仓库模式

总体思路是在最低的粒度级别上创建一个事实表，其中包含感兴趣的事件度量。除此之外，当然还有一个维度表（a），其中记录的事件的维度将被保留。这些表由

维度\u id

绑定

我的问题是：某个东西既是一个维度又是一个度量，这有可能吗，或者更确切地说，这有意义吗

例如，产品在某些搜索结果中的位置。给定产品的位置可以被视为一个度量；用户可能希望对产品运行以下查询：

尺寸x=y的产品上周的平均展示位置是多少

同时，位置本身可以被视为一个维度：

显示上个月所有排名为2的产品的点击率

---

在数据仓库中，解决这种问题的正确方法是什么（如果有区别的话，我们正在寻找面向列的解决方案）。

在我看来，在这两种情况下，您实际上只是在对度量值运行查询

上月排名为2的产品

考虑一下生成这些产品的方法，可以通过动态地从事实表中生成正确的产品列表，然后将外部事实查询限制到这些产品来派生

如果您有一个有能力运行定制SQL的分析师，这很好，但是对于一个非技术分析师来说，在我使用过的任何报告工具中构建定制SQL要困难得多

或

你可以“强化”你作为一个属性的位置，使之成为一个缓慢变化的维度。但对于快速变化的数据，这通常不是一个选项。。。因为你的维度变化如此之快，这是不切实际的

如果您可以将所需的分析期缩短为一个月，那么将月度评级（以及许多其他属性，包括滚动期类型属性）实施到一个缓慢变化的维度中可能是可行的，这意味着您每年至少有12个产品维度成员，但是，您可以将每个可简化的实时KPI合并到维度中的一列中，这通常非常有用

---

但我猜这对您来说并不是什么新鲜事。

您的意思是“度量”吗？我想我的问题更多-您是否通过将事实表作为度量和维度表作为属性存储在事实表中来复制某些信息（位置），还是调整报告系统以允许对数字维度进行聚合查询。希望这更有意义。在我看来，批量装载的三维仓库为您提供了复制各种信息的便利和速度。