我要把我的第一步移到数据仓库。
我买了一本很好的书“数据仓库工具包-第三版”,由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
我的事实表只会有二维。
现在,在其他情况下,我会把传递看作是一个退化的维度,但是由于我必须将许多态度与它联系起来,所以我不知道该走哪条路:
也许在维度和事实之间选择并不是那么简单
发布于 2014-10-10 14:13:32
正如您所描述的那样,传递是与sale相关的一个单独事件。所以送货应该是一个单独的事实表。
当然,如果您不需要增加复杂性,您可以始终“项目”(可以这么说)维度中的一个事实。例如,假设您只需要了解一些关于交货的简单事实:例如承运人和交货日期。然后,您可以在SALES中使用DELIVERY_ID,并在传递维度中注册这些信息。
但是,如果您必须注册一个交付的全部复杂性(相对于一个销售可能有两个或两个以上的交付,以及相对于一个交付有两个或更多的销售),那么您需要两个事实表。
https://stackoverflow.com/questions/26300860
复制相似问题