我目前正在研究一个大致使用维度建模方法的仓库模式。
一般的想法是有一个单一的事实表，在最低粒度级别上充满感兴趣的事件度量。除此之外，当然还有一个维度表（a），其中将保存正在记录的事件的维度。这些表由dimension_id.
我的问题是：是否有可能，或者更确切地说，它是否有意义，既是维度又是度量。
一个例子可能是产品在某些搜索结果中的位置。给定产品的位置可以被认为是一个度量；用户可能希望对产品运行以下查询：
上周展示尺寸为 x = y 的产品的平均排名是多少？
同时，位置本身也可以被认为是一个维度：
显示上个月所有 position = 2 的产品的点击率
在数据仓库中解决此类问题的正确方法是什么（我们正在研究面向列的解决方案，如果这有所作为）。
在我看来，在这两种情况下，您实际上只是在对度量进行查询
上个月位置 = 2 的产品
考虑生成它的方法，可以通过动态地从事实表中生成正确的产品列表，然后将外部事实查询限制在这些产品中来派生。
如果您有一个有能力的分析师运行自定义 SQL，这很好，但对于非技术分析师来说，在我曾经使用过的任何报告工具中构建它要困难得多。
或者
您可以将您的位置作为一个属性“强化”为一个缓慢变化的维度。但是对于快速变化的数据，这通常不是一个选择......因为您的尺寸变化如此之快，这是不切实际的。
如果您可以将所需的分析期限制为一个月，则将每月评级（以及许多其他属性，包括滚动期类型属性）实施到一个缓慢变化的维度中可能是切实可行的，这意味着您将至少有 12 个产品维度每年的成员，但是您将每个可能的实际 KPI 都归结为维度中的一列，这通常很有帮助。
但我猜这对你来说并不新鲜。