第一个使用星型模式的项目，仍处于规划阶段。我们将不胜感激对以下问题的任何想法和建议。
我们有一个“使用的产品特性”的维度表，并且特性集会随着时间的推移而增长和变化。由于特征的动态集，我们认为特征不能是列，而必须是行。
我们有一个“用户事件”的事实表，我们需要知道每个事件中使用了哪些产品功能。
所以看起来我们需要在事实表上有一个主键，它被用作维度表中的外键（与传统的星型模式正好相反）。我们有几个不同的维度表，它们具有相似的动态，因此对事实表的外键也有类似的需求。
另一方面，我们的大多数维度表都比较常规，事实表可以只在这些常规维度表中存储一个外键。我们不喜欢这意味着某些连接（多对一）将使用维度表的主键，但其他连接（一对多）将使用事实表的主键。我们已经考虑在所有维度表中使用事实表键作为外键，只是为了保持一致性，尽管存储需求会增加。
有没有更好的方法来实现“动态”维度表的键？
这是一个不完全是我们正在做但类似的示例：
假设我们的应用搜索餐馆。
用户可以指定的可选功能包括价格范围、最低星级或美食。可选功能集随时间而变化（例如，我们可能会去掉指定美食的选项，并添加一个最受欢迎的选项）。对于记录在数据库中的每个搜索，使用的特征集是固定的。
- 每个搜索将是事实表中的一行。
我们目前在想，事实表中应该有一个主键，在“特征”维表中应该作为外键。所以我们有：
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)这些关键模式的缺陷是什么？有什么更好的方法来做到这一点？