Database design 需要帮助建模事实表吗

我正在进入数据仓库的第一步

我买了Kimball&Ross的优秀著作《数据仓库工具包-第三版》，该书向我解释了如何掌握基本概念。
今天我开始设计我的第二个数据集市，但我已经遇到了一个（可能是愚蠢的）问题。假设我正在为一个简单的销售事件建模：一个微不足道的事实表将是：

DATE_ID | CUSTOMER_ID | PRODUCT_ID | QUANTITY

正如本书和网络上所解释的，每个维度都与其他维度有多对多的关系。
接下来，我想增加一些尺寸，如载体：

DATE_ID | CUSTOMER_ID | PRODUCT_ID | CARRIER_ID | QUANTITY

维度仍处于多对多关系中。
现在，我被要求添加很多（可能是十几个或更多）关于交付的细节，比如一堆日期、路线、箱子和托盘的数量、各种标志等等，所以我考虑了一个交付维度表。我的第一次尝试是：

DATE_ID | CUSTOMER_ID | PRODUCT_ID | CARRIER_ID | DELIVERY_ID | QUANTITY

但是。。。令人惊讶的是，事实表现在不再是多对多关系了。所以我想：“嗯，我可以重构它，因为现在其他维度实际上是交付的属性”，但它会变成

DELIVERY_ID | PRODUCT_ID | QUANTITY

我的事实表只有两个维度。
现在，在其他情况下，我会将交付视为一个退化维度，但由于我必须将许多态度与之关联，我不知道应该遵循哪条路线：

• 创建交付维度并重构事实表
• 把他们扔进事实调查表
• 创建一个DELIVERY维度并将DELIVERY_ID放在事实表中，假装它只是一个退化维度

---

也许在维度和事实之间进行选择并不像您描述的那样简单，交付是与销售相关的单独事件。因此，交付应该是一个单独的事实表

当然，如果不需要增加复杂性，您可以始终在维度中“投影”（可以这么说）一个事实。例如，假设你只需要知道一些关于交货的简单事实：例如承运人和交货日期。然后您可以在SALES中使用DELIVERY\u ID，并在DELIVERY维度中注册这些信息

---

但是，如果您必须注册一次交付的全部复杂性（一次销售可能有两次或两次以上的交付，一次交付可能有两次或两次以上的销售），那么您需要两个事实表。

IBM红皮书中有关数据仓库设计的更多免费资源已链接到。