我有一个源数据集，有 1.customer 2.customer_product_purchase 3.customer_support_plan_purchase 4.customer_support_request。
所有这些都有一个关系，即支持请求是针对一个计划和产品购买提出的。而客户购买了一个产品的支持计划（客户也购买了这个计划）。
为了对此设计一个数据仓库模式，我是想建立一个单一的事实表，我想到了以下几种方法。
A. 有一个合并的事实表，表的内容是 客户_产品购买, 客户支持计划_购买 和 客户支持请求 因为它们有一些共同的属性（和一些不常见的属性，可以保留空白）。因为我相信它们的粒度是一样的（购买产品支持计划，对支持计划提出请求）。这将意味着失去一些特定的信息，使其通用，如产品保修和支持计划的有效期在同一名称下。有效性
B. 从以下方面创建事实表 客户_产品购买 和 客户支持计划_购买 其本质上是购买，可以用一些常见的和一些不常见的属性保持在一起。的 客户支持请求 可以分别对待。
C. 围绕创建事实表 客户支持请求 因为它与其他两个表都有联系，可以是维度。然而，这将意味着维度也将以与事实相同的速度增长(我读到，这是一个设计不良的指标。).
那么如何处理这样的情况呢，支持计划、服务请求和产品购买可以自己单独成长，是不是最好把它们全部分开呢？但因为它们(全部或两个)的粒度相近，是不是应该合并？
我的评论中的一些观点
星型模式中的事实表应该对业务流程进行建模。
我建议不要过于努力地组合事实，除非这样做有明确的意义。不同细节层次的事实是一个强有力的指标，不要将其组合起来
这里有一些关于事实细节层面的观察。
你可以针对一次购买有0个或多个支持计划。这是一个不同的细节层次，可能是一个不同的事实。
您可以针对一个支持计划提出零个或多个支持请求。这是一个不同层次的细节，可能是一个不同的事实。
如果你把支持计划和销售放在同一个事实中，而你对同一个客户有两个产品销售，一个支持计划为零，一个支持计划为三，那么你的事实中就会有五个（2+3）记录，而且很难把支持计划和销售联系起来，因为它们在不同的行中。例如，如果你想要一个给定产品组的支持计划和购买金额的价值比，虽然不是不可能，但把所有这些分散在同一事实中的支持计划和购买金额放在一起就不 "对味 "了。
如果你有很少的确定的回头客，那么是的，你的客户数量会以同样的速度增长，但这是不可避免的，也是正常的。
请记住，从来没有任何 "最好 "的解决方案，所以不要陷入分析瘫痪。值得在类似Power BI这样的东西中快速建模，并向它抛出一些业务问题。请记住，你的星级模式是为了让业务问题更容易回答。