我在过去几天一直在研究数据仓库,特别是,我一直在阅读Kimball和Ross的 The Data Wharehouse Toolkit - Dimensional Modeling的权威指南。
从阅读开始,我来到第一个有销售事实的例子,它与产品维度有关,正如你在下面的图片中看到的那样:
我想我可以理解这种关系如何允许我们旋转“立方体”切片和切割数据的要点,但这是我迷路的地方:
在这个例子中,网络产品上的许多其他产品与销售是一对一的关系,这对大多数情况来说都很好。但是,这至少会产生一次销售中的每种产品的销售登记。
假设我买了1个香蕉,2个苹果和1个橙子,这将至少产生3个销售登记。再次,这是好的,我猜,因为它将销售的门票ID存储在销售事实中,我们仍然可以将特定销售中的所有itens关联起来。
然而,如果这是一个用例:关联销售产品说我希望得到每一个有香蕉的销售并得到这样的东西:这些销售中有多少项,它们的价格成本,它们的利润,这样的东西... 如果事实 - 产品关系是Fact-one_to_many - 产品关系,那会不会更好?哪些事实会保留销售的机票ID,而产品的外键引用它们来自哪里?
我认为这些指标应该在事实表中,而不是在我认为我想要的产品表中。那么,这是不是我的冲动标准化它或者它是否有意义我想要做那种过滤 - > [根据X产品的所有销售情况,从同一销售中的其他产品获取数据]。
如果我遵循这些指导原则,产品维度将为商店所具有的每种独家产品提供一个注册表吗?我想要的所有测量结果都会将其存储在事实本身上,如价格成本,销售价格,利润等......
另一方面,如果我对一对多的产品维度会有每个产品的许多副本。我认为这很糟糕。但是,我认为在这方面会给我更好的询问。
正如你所看到的那样,我是一个初学者,并且真的处于这条道路的早期阶段,所以如果你能在一个解释中表达我的回答,我会很感激。
编辑:
抱歉@ Nick.McDermaid,你是对的。我的意思是从销售事实的角度来看,对于每个销售事实,我只有一个产品,但对于一个产品,它可以有N个销售相关。因此,我们在商店中的每个不同产品的数据库中都有一条产品记录。这是正确的方法,如何正确地建模。此外,许多指标是我猜的“销售数量”。
无论如何,虽然如果我们以销售作为观点,这允许切片和切块,但如果我想要举例如下: 获取其中包含香蕉的所有销售,以及这些销售中的所有其他项目。我们仍然可以使用这种结构,但比产品重复更难,我们在产品表中将销售ID作为外键。 Cuz ultimetly我想获得有香蕉的所有销售(以及销售中的产品)。然后从中获取指标。
答案 0 :(得分:0)
您有点暗示的是退化维度,包括发生的交易的销售ID /发票#/采购订单#。简并维度的整个目的是将与无意义数据相关的项目分组。例如,A1234的PO#本身毫无意义,它没有告诉您有关购买的任何信息。但是,它可用于识别其他有意义的数据,例如为客户购买产品的日期。在这种情况下,PO#由它汇集在一起描述事件的实体集合定义。
数据仓库中的另一个关键概念是从多维数据集中的模型中抽象出数据库中的模式。您不会在多维数据集模型中加入和分组数据。你切片和过滤。多维数据集模型中没有外键。这些在底层数据模式中使用,但所有这些工作都在多维数据集模型的幕后处理。