
2008年05月21日 09:23:45
数据分析讲堂
|
数据分析讲堂
Thor立刻注意到要做一些转换才能把数据放入到立方体。你能看出问题之所在吗?Thor解释说,存在此问题是由于价格表中的包类型信息是项描述的一部分,这与把包类型定义为foodcake维的叶子成员是等价的。遗憾的是,关系和OLAP工具都不能很好地执行这类转换。 Thor指出他需要转置具有总销售(W)和列表(L)价格列的现存部分foodcake名字的包后缀,把以前的一列创建为两列。就这么简单吗?Lulu不这么认为。她告诉Thor他能否进行此转置取决于FCI是否会同时改变两种包类型的价格,为说明她的观点,她展示了如果按照Thor的设计进行转置FCI的价格表会是什么样子。 Lulu对Thor所提建议的说明如图7.3.2。 按照此种类型表的设计必然会产生大量稀疏,她说。一行数据要么在4组的列上,要么在8组的列上,而不会同时都有。Thor同意,但如果FCI在同一天内改变其两种包类型的价格,那么此表将变得稠密,因此也将是适当的。非常正确,Lulu说,但目前FCI的业务过程是独立地改变每个包类型的定价,并且FCI也不会仅仅为了使他们的工作更容易而改变其业务过程。
因此,给定Foodcake维在他们销售模型内的定义方法之后,分析师有两种基本的选择。一方面,他们可以复制定价数据并把它们保存在一张表内,像前面那张表一样,这种方法的优势是只有一张表需要维护和连接。另一方面,他们可以给每个包类型创建一张独立的表,此种方法的好处是两张表中的每一行都表示了一个真正的价格变化,并且表符合第四范式,更不容易产生更新异常,不利的地方是需要连接更多的表。既然FCI现在只有两种不同的包类型,没人会觉得有两张价格表是个难事,因此他们选择为每个包类型建立不同的价格表,如图7.3.3和图7.3.4所示。
创建完两张表之后,Lulu看着它们,很惊讶地讲道,你知道,Thor,我不是很确信把包的变化分解是正确的方法。如果FCI建立更多的包类型怎么办?那将变得很难维护,难道不存在两个方面都是最好的方法吗?我们不能利用我们创建的包类型维吗?你怎么想? 我知道了,Thor说。为什么不把包类型也作为列标题,这样不就隐含地将其作为一个维了吗?就是这样,Lulu说。我不明白我们前面怎么没想到。这在图7.3.5内显示。
为了把价格信息输入销售立方体,Thor设计了如下输入公式: “List_price”{$/pkg}, Foodcake.leaf., Time.day., Geog.all., Package., Scenario.actual << [ Price chang table ]: L price 这应该有效,他说。此公式要做的所有事情是在价格变化表中抽取正确的值。你同意吗?Lulu不同意。等一下,她说。它将会怎么工作?可能有两种不同的情况: l 当时间维的叶子成员与价格变化表中的日期匹配时 l 当时间维的叶子成员不与价格变化表中的任何日期匹配时 第一种情况很简单,这时你能输入恰当的行。但第二种情况时,依据定义,立方体会给没有新价格信息的日期赋一个空值,但你想要的是保持最近的值直到有变化发生。Lulu建议如下方法,它对两种包类型都适用: “List_price”{$/pkg}, Foodcake.leaf., Time.day., Package., Geog.all., Scenario.actual << [ Price chang table ]: L price Else If missing List_Price{$/pkg}, Time.day.this = List_Price{$/pkg},Time.day.- 1 换句话说,对任何特定的一天,如果在价格变化表中有值,那么就把它插入立方体。但如果没有这样一个值(即当天没有价格变化),那么立方体中的价格值就与前一天的值相等。 2) 美元零售额{$} 美元零售额也是一个输入变量,定义如下: “Retail dollar sales”{$}, Time.leaf., Foodcake.leaf., Geog.leaf., Scenario.actual << Input [ Sales Fact table ]: Retail dollar sales 此变量在除了方案维外的所有维上汇总,定义如下: “Retail dollar sales”{$}, Time.leaf.above., Foodcake.leaf.above., Geog.leaf.above. = Sum(“Retail dollar sales”,Time.leaf.,Foodcake.leaf., Geog.leaf.,Scenario.actual ) |
一共有 58 条评论