Database design 如何在数据仓库设计中处理同样增长的事实/维度表？

我有一个源数据集：
1.客户
2.客户\产品\购买
3.客户支持计划采购
4.客户支持请求

他们都有这样一种关系，即针对计划和产品购买提出支持请求。客户购买产品支持计划（客户也购买）

为了为此设计数据仓库模式，我考虑创建一个事实表，我考虑了以下方法：

A.将客户、产品、计划和请求合并为一个事实表，因为它们有一些共同的属性（以及一些不常见的属性，可以为其他人保留空白）。因为我相信它们的粒度相同（购买产品/支持计划，根据支持计划提出请求）。这将意味着丢失一些特定信息，使其成为通用信息，例如相同名称下的产品保修和支持计划有效性有效性

B.从客户、产品、采购和客户支持、计划和采购创建事实表，这两种采购本质上都是采购，可以与一些常见和不常见属性一起保存。客户支持请求可以单独处理

C.围绕客户支持请求创建事实表，因为它与其他两个表（可以是维度）关联。然而，这将意味着尺寸也将以与事实相同的速度增长（，我已经读到，这是一个糟糕设计的指标）

---

那么，我如何处理这样一种情况，即支持计划、服务请求和产品购买可以单独增长，最好将它们分开？但是由于它们（全部或两个）具有相似的粒度，它们不应该合并吗？

我的评论中的一些观点

---

• 星型模式中的事实表应该为业务流程建模

• 我建议不要太努力地把事实结合起来，除非这样做有明确的意义。不同细节层次的事实是不可合并的有力指标

这里有一些关于事实细节层次的观察

• 一次购买可以有0个或多个支持计划。这是一个不同层次的细节，可能是一个不同的事实

• 您可以针对单个支持计划提出零个或多个支持请求。这是一个不同层次的细节，可能是一个不同的事实

• 如果您将支持计划和销售放在同一事实中，并且您为同一客户进行了两次产品销售，一次为零支持计划，一次为三支持计划，那么您的事实中会有五（2+3）条记录，并且很难将支持计划与销售相关联，因为它们位于不同的行中。例如，对于给定的产品组，如果您想要一个支持计划与购买金额的价值比率，虽然并非不可能，但将所有这些分散在同一事实中并不“有味道”

• 如果您的回头客非常少，那么您的客户dim将以与事实相同的速度增长，但这是不可避免的，也是正常的

---

请记住，没有任何“最佳”解决方案，所以不要陷入分析瘫痪。在Power BI中快速建模并向其提出一些商业问题是值得的。请记住，您的星型模式是为了让业务问题更容易回答。

我希望您可以针对单个支持计划提出零或多个支持请求，因此我觉得

支持请求

是事实。每次购买是否只有零或一个支持计划？第一个支持计划到期后是否会有后续支持计划？如果是这样，这些也应该是独立的事实。如果确定的重复客户非常少，那么您的客户dim将以与事实相同的速度增长，但这是不可避免的。星型模式中的事实表应该为业务流程建模。我建议不要太努力地把事实结合起来，除非这样做有明确的意义。不同细节级别的事实是不合并的危险信号。@Nick.McDermaid是的，你是对的，支持计划可以针对一个产品多次购买。另外，从您的第二条评论中，我想知道

产品销售

和

支持计划销售

是否被视为是同一种情况？它们仍然是单独的事务（但是每个支持计划都引用了产品购买）。因此，我考虑将它们合并为一个，使用一些稀疏列（这两个表之间不相交），使用指定“支持计划”或“产品”作为购买类型的类型列。你认为这是一个好的做法吗？他们的观点不一致，因为产品销售只会发生一次。对于给定的产品销售，支持计划销售发生0次或多次。如果您将这些记录放在同一事实中，并且您为同一客户进行了两次产品销售，一次是零支持计划，一次是三支持计划，那么您的事实中最终会有五（2+3）条记录，并且很难将支持计划与销售相关联，因为它们位于不同的行中。是的，你可以用相同的发票号给它们贴标签，但它只是“感觉不对劲”（这里的关键设计决策过程！）@Nick.McDermaid很棒。非常感谢你。如果你能把你的评论复制成一个答案，我会把它标记为接受