使用星型模式的第一个项目，仍在规划阶段。我们对以下问题的任何想法和建议表示感谢。
我们有一个维度表，用于＆＃34;使用的产品功能＆＃34;，这些功能随着时间的推移而增长和变化。由于动态的一组功能，我们认为功能不能是列，而是必须是行。
我们有一个用于＆＃34;用户事件＆＃34;的事实表，我们需要知道每个事件中使用了哪些产品功能。
所以我们需要在事实表上有一个主键，它在维度表中用作外键（与传统的星型模式完全相反）。我们有几个具有相似动态的不同维度表，因此对事实表中的外键也有类似需求。
另一方面，我们的大多数维度表都更加传统，事实表只能将外键存储到这些传统维度表中。我们不喜欢这意味着一些连接（多对一）将使用维度表的主键，但其他连接（一对多）将使用事实表＆＃39;主键。我们已经考虑在所有维度表中使用事实表键作为外键，只是为了保持一致性，尽管存储需求增加。
是否有更好的方法来实现＆＃34;动态＆＃34;维度表？
这里有一个例子，它不完全是我们正在做的但是相似的事情：
假设我们的应用搜索了餐馆。
用户可指定的可选功能包括价格范围，最低星级或美食。可选功能集随着时间的推移而变化（例如，我们可能会删除指定菜肴的选项，并添加最受欢迎的选项）。对于数据库中记录的每个搜索，使用的功能集是固定的。
我们目前认为我们应该在事实表中有一个主键，它应该被用作＆＃34;功能中的外键。维度表。所以我们有：
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）
这些关键模式存在哪些缺陷？有什么比这更好的方法呢？
答案 0 :(得分：1)
您需要一个Bridge表，它是事实和维度之间多对多关系的推荐解决方案。
编辑后添加到问题的示例：
好吧，也许它不是桥梁，这个例子改变了我的观点。
维度建模的基本要求是正确识别事实表的粒度。一个常见的例子是invoice和line-item，其中grain通常是line-item。
假设示例通常很难，因为您永远无法确定示例是否反映了实际用例，但我认为您的方案可能是搜索和标准，并且您的粒度应该处于标准级别。
例如，您的事实表可能如下所示：
fact_search（date_id，time_id，search_id，criteria_id，criteria_value）
考虑到我可能想对搜索数据做的查询类型，这个设计是我的最佳选择。我看到的唯一问题是使用criteria_value的数据类型，它必须是一个选项/文本值，并且肯定是非加法的。