database-design - 维度同时作为度量是否有意义

Question

我目前正在研究一个大致使用维度建模方法的仓库模式。

一般的想法是有一个单一的事实表，在最低粒度级别上充满感兴趣的事件度量。除此之外，当然还有一个维度表(a)，其中将保存正在记录的事件的维度。这些表由 dimension_id 绑定(bind)。 .

我的问题是:是否有可能，或者更确切地说，它是否有意义，既是维度又是度量。

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

上周展示尺寸为 x = y 的产品的平均排名是多少？

同时，位置本身也可以被认为是一个维度:

显示上个月所有 position = 2 的产品的点击率

在数据仓库中解决此类问题的正确方法是什么(如果有影响，我们正在研究面向列的解决方案)。

Answer 1

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

products with position = 2 for the last month

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

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

或者

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

如果您可以将所需的分析期限制为一个月，则将每月评级(以及许多其他属性，包括滚动期类型属性)实现到一个缓慢变化的维度中可能是切实可行的，这意味着您将至少有 12 个产品维度每年的成员，但是您将每个可能的实际 KPI 都归结为维度中的一列，这通常很有帮助。

但我猜这对你来说并不新鲜。