星型模式：如何处理不断变化的一组列的维度表？

Question

使用星型模式的第一个项目，仍在规划阶段。对于以下问题，我们将不胜感激。

我们有一个“使用的产品功能”的维度表，随着时间的推移，功能集会不断增长和变化。由于功能的动态集合，我们认为这些功能不能是列，而必须是行。

我们有一个“用户事件”的事实表，我们需要知道每个事件中使用了哪些产品功能。

因此，我们似乎需要在事实表上有一个主键，它用作维表中的外键（与传统星型模式完全相反）。我们有几个不同的维度表，它们具有相似的动态特性，因此对事实表中的外键也有类似的需求。

另一方面，我们的大多数维度表更传统，事实表可以将外键存储到这些常规维度表中。我们不喜欢这意味着某些连接（多对一）将使用维度表的主键，但其他连接（一对多）将使用事实表的主键。尽管存储需求增加，但我们考虑将事实表键用作所有维度表中的外键，以保持一致性。

有没有更好的方法来实现“动态”维度表的键？

下面是不是正是我们正在做的事情，但类似的例子：

• 假设我们的应用程序搜索餐馆。

• 用户可以指定的可选功能包括价格范围，最低星级评分或美食。随着时间的推移，这组可选功能会发生变化（例如，我们可能会摆脱指定美食的选项，并为最受欢迎的菜单添加选项）。对于数据库中记录的每个搜索，所使用的一组功能是固定的。

• 每个搜索都将成为事实表中的一行。

• 我们现在认为我们应该在事实表中有一个主键，并且它应该在“features”维表中用作外键。因此，我们必须：

  fact_table（SEARCH_ID，USER_ID，metric1，metric2）
  feature_dimension_table（FEATURE_ID，SEARCH_ID，feature_attribute1，feature_attribute2）
  user_dimension_table（USER_ID，user_attribute1，user_attribute2）

• 或者，为了保持一致的连接并忽略存储要求，我们可以将事实表的主键用作所有维度表中的外键：

  fact_table（SEARCH_ID，metric1，metric2）/ *没有更多的user_id */
  feature_dimension_table（FEATURE_ID，SEARCH_ID，feature_attribute1，feature_attribute2）
  user_dimension_table（USER_ID，SEARCH_ID，user_attribute1，user_attribute2）

• 这些关键模式有哪些缺陷？什么是更好的方法来做到这一点？

Answer 1

您需要一个Bridge表，它是事实和维度之间多对多关系的推荐解决方案。例如加入到问题后

http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/multivalued-dimension-bridge-table/

编辑：

好吧，也许它不是一个桥，例如改变了我的看法。

尺寸建模的基本要求是正确识别事实表的颗粒。一个常见的例子是发票和行项目，其中谷物通常是行项目。

假设的例子往往很困难，因为你永远无法确定该例子是否反映了真实的用例，但我认为你的场景可能是搜索和条件，并且你的谷物应该处于标准级别。

例如，事实表可能是这样的：

fact_search（DATE_ID，TIME_ID，SEARCH_ID，criteria_id，criteria_value）

思考我可能想这样做对搜索数据的查询类型，这个设计是我最好的选择。我看到的唯一问题是criteria_value的数据类型，它必须是选择/文本值，并且肯定是非加法的。