Question

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

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

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

我该怎么做？

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

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

“实际上”表示促销活动的开始和结束日期。

因此，促销本身可能是具有时间维度的开始和结束日期引用的事实。

也许使用这样的模型你可以有一个JOIN表，以便在事实之间以多对多的方式将销售与促销联系起来。

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

你必须将它们存储在某个地方，或者你的模型分崩离析。为什么不愿意以这种方式模拟促销？

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

Answer 3

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

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