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