data-warehouse - 星型架构[事实 1:n 维度]...如何？

Question

我是数据仓库的新手，我希望有一个关于构建星型模式的简单问题：

如果我有一个事实表，其中事实记录自然与单个维度具有一对多关系，那么如何建模星型模式来支持这一点？例如：

• 事实表：销售点入口（计量单位为 DollarAmount）
• 维度表：促销（这些是在进行销售时有效的促销）

情况是我希望单个销售点条目与多个不同的促销相关联。这些促销活动不能是它们自己的维度，因为有很多很多促销活动。

我该怎么做呢？

Answer 1

对于真正具有“多值”维度的情况，桥接表通常是 Kimball 推荐的解决方案。

您的“促销”维度只是每个促销的记录及其属性（开始日期、结束日期、优惠券代码、POS 促销代码、广告名称等）。从促销到产品的关系在这里没有建模，因为它将反映在事实表中。

促销/折扣维度看起来像（每个独特的计划促销 1 行）

Promotion Dim ID
Promo Code
Coupon Code
Promo Start DTTM
Promo End DTTM
... etc ...

您的销售事实如下所示：

Tran Date
Tran Line #
Customer Dim ID
Product Dim ID
Promotion Group Dim ID
Net Sale Price
Average Cost
Discount Amount

您的“促销组”桥牌表将是一组组合：

Promotion Group Dim ID
Promotion Dim ID

如果发生了包含 3 个促销的销售，您只需创建与每个促销相关的组 ID，然后将组 ID 放在事实表中。这与医疗报告系统处理多种诊断的方式非常相似。

请注意，通过使用 Bridge 表，您可以轻松地重复计算销售额，因此我建议使用这种方法的报表由了解模型的人开发。

Answer 2

时间几乎总是星型模式中的一个维度。

“有效”表明促销活动有开始和结束日期。

因此，Promotion 本身可能是具有对 Time 维度的开始和结束日期引用的事实。

也许使用这样的模型，您可以拥有一个 JOIN 表，以在事实之间以多对多的方式将 Sale 与 Promotion 相关联。

“很多很多”促销活动 - 是的，但有多大？每天一个意味着每年 365 条记录。我假设促销与产品或类别有某种关联。销售将有一个时间戳和多个产品。

您必须将它们存储在某个地方，有时或者您的模型会崩溃。为什么不愿意以这种方式进行推广？

我的建议是不要担心数据的大小，并尽可能专注于对问题进行建模。首先正确地获取逻辑模型，然后再考虑物理模型和数据大小。

Answer 3

即使金额相同，您也应该为每次促销加载事实记录。如果事实上，您的示例中的每种促销类型确实由这个特定的美元金额表示，那么应该使用促销类型的键加载事实记录，还包含返回到其他相关维度（包括日期）的键。

这里的要点是不要担心数据重复。想想以销售为导向的数据仓库，比如一家快餐公司。可以假设不会只有一个 4.13 美元的事实记录，它用于代表“价值餐 #3”的一百万次不同销售。相反，“交易”维度中的每条记录都将与这个假设的销售事实表中的至少一个特定事实记录有关系。