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

Posted 2023-03-29

【中文标题】如何处理数据仓库设计中同样增长的事实/维度表？

【英文标题】：How to deal with equally growing fact/dimension tables in datawarehouse design?

【发布时间】：2020-06-19 02:41:44

【问题描述】：

我有一个源数据集： 1. 客户 2. customer_product_purchase 3. customer_support_plan_purchase 4. customer_support_request

他们都有这样的关系，以便针对计划和产品购买提出支持请求。并且客户购买产品的支持计划（客户也购买）。

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

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

下的产品保修和支持计划有效性

B.从 customer_product_purchase 和 customer_support_plan_purchase 创建一个事实表，它们本质上是购买，并且可以与一些常见和一些不常见的属性保持在一起。 customer_support_request 可以单独对待。

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

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

【问题讨论】：

我希望您可以针对单个支持计划提出零个或多个支持请求，所以我觉得support_request 是它自己的事实。每次购买是否只有零个或一个支持计划？第一个支持计划到期后是否还有后续支持计划？如果是这样，这些也应该是单独的事实。如果您确定的回头客很少，那么是的，您的客户数量会以与事实相同的速度增长，但这是不可避免的

星型模式中的事实表应该为业务流程建模。我建议不要太努力地结合事实，除非这样做很有意义。不同细节级别的事实是不合并的危险信号。

@Nick.McDermaid 是的，您是对的，支持计划可以随后购买，并且可以针对一个产品多次购买。另外，从您的第二条评论中，我想知道product sale 和support plan sale 是否被视为相同？它们仍然是单独的交易（但是每个支持计划都引用了产品购买）。因此，我正在考虑将它们合并为一个，其中包含一些稀疏列（两个表之间不相交），以及指定“支持计划”或“产品”作为购买类型的类型列。认为这是一个好习惯？

它们不一样，因为产品销售只发生一次。对于给定的产品销售，支持计划销售发生 0 次或多次。如果你把这些放在同一个事实中，并且你有两个产品销售给同一个客户，一个是零支持计划，一个是三个，你最终会在你的事实中得到五 (2+3) 条记录，并且很难将销售支持计划，因为它们位于不同的行中。是的，您可以用相同的发票号标记它们，但它只是“感觉不对”（此处工作的关键设计决策过程！）

@Nick.McDermaid 太好了。非常感谢。如果您可以将您的 cmets 复制为单个答案，我会将其标记为已接受

【参考方案1】：

我的cmets的一些观点

星型模式中的事实表应该对业务流程进行建模。

我建议不要太努力地结合事实，除非这样做很有意义。不同细节级别的事实是一个强有力的指标，不能合并

这里有一些关于事实细节级别的观察；

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

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

如果您将支持计划和销售放在同一个事实中，并且您有两个针对同一客户的产品销售，一个具有零支持计划，一个具有三个支持计划，您最终会在您的事实，并且很难将支持计划与销售联系起来，因为它们位于不同的行中。例如，如果您想要一个给定产品组的支持计划与购买金额的价值比率，虽然并非不可能，但将所有这些分散在同一个事实中并不是“闻起来”正确

李>

如果您确定的回头客很少，那么您的客户数量会以与事实相同的速度增长，但这是不可避免且正常的

请记住，从来没有任何“最佳”解决方案，因此不要陷入分析瘫痪状态。值得在 Power BI 之类的东西中快速建模并提出一些业务问题。请记住，您的星型模式是为了让业务问题更容易回答。