问星型[事实1:n维]...how？

EN

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

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

促销/折扣维度看起来像(每一次唯一的计划促销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表，您可以轻松地进行双计数销售，因此我建议使用此方法的报告应由了解该模型的人员开发。

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

“有效”表示促销有一个开始和结束的日期。

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

也许有了这样一个模型，你可以有一个连接表，将销售和促销联系起来，在事实之间以多到多的方式。

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

你必须把它们存放在某个地方，否则你的模型就会崩溃。为什么不愿意以这种方式进行推广？

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

你应该为每一次晋升载入一个事实记录，即使美元金额是相同的。实际上，如果您的示例中的每一种晋升类型都真正地由这个特定的美元金额表示，那么一个事实记录应该加载升级类型的键，还包含返回到其他相关维度的键(包括日期)。

这里的要点是不要担心数据复制。想想一个面向销售的数据仓库，比如说，一家快餐公司。人们可以假设，4.13美元的事实记录并不仅仅是一个事实，它代表着“价值餐#3”的一百万种不同的销售额。相反，"Transaction“维度中的每个记录都与这个假设的Sales事实表中的至少一个特定事实记录有关系。