星型架构[事实 1:n 维度]...怎么样？答案

【问题标题】：Star schema [fact 1:n dimension]...how?星型架构[事实 1:n 维度]...怎么样？
【发布时间】：2010-05-06 23:19:14
【问题描述】：

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

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

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

我该怎么做？

【问题讨论】：

【解决方案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 表，您可以轻松地重复计算销售额，因此我建议使用这种方法的报表由了解模型的人开发。

【讨论】：

【解决方案2】：

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

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

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

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

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

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

我的建议是不要担心数据的大小，并尽可能专注于对问题进行建模。先搞好逻辑模型，再考虑物理模型和数据大小。

【讨论】：

这是一个虚构的例子，但我不能使用时间作为连接的原因是特定产品在促销期间并非所有产品都在同一促销下。想想优惠券，这些是可以应用于特定产品的促销活动，但它们也可以一次应用于多个产品。我知道我必须在某个地方存储促销信息，但是为每个促销设置一个维度是行不通的。在这一点上，我知道我不想要一个包含 3000 列的事实表，其中大多数都指向“不在此促销下”记录。
我读到的关于星型模式的所有内容都表明时间是您包含的第一个维度。而且我认为这不会是 3000 列指向提升，这显然会打破任何关系模型的第一范式。这将是此次促销活动的唯一关键。有多少适用于单次销售？
我希望它不会走到这一步。这是一个虚构的例子，所以当然会出现逻辑漏洞。怎么样...每个 POS 条目可以是 1 个或多个命名组的成员。这些组可以有任意数量，并由正常关系世界中的分组表分配。我希望能够查询多维数据集（从星型模式构建）以找出哪些 POS 条目属于组：“组 1”、“组 2”和“组 3”。同样，可以有任意数量的组，因为它们是由经理或类似人员自定义创建的。
或者，继续前面的示例，假设单次销售可以应用 0、1 或更多促销。

【解决方案3】：

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

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

【讨论】：

在我的用例中，我有一个orders 事实表和一个salesman 维度。有时（不是很常见）一个订单会与超过 1 个业务员相关，您会如何建议这种模式？就像在您看来，事实表将有两个相同的行，除了 FK salesman_id？但这在求和聚合时会出现问题。