第四章 采购

1.         采购案例研究

       采购涉及到从合同谈判到发布购买通知单与购买订单(Pos Purchase Orders)、到跟踪支出付款批准等一系列覆盖面很广的活动。

       哪些材料或者产品的购买最频繁?有多少厂家提供这些产品?价格如何?测评的度量单位是什么(例如散装或者桶装)?

       通过查看地企业范围内的需求(而不是从单一的具体方面)。发现可以通过合并供应商、从单一货源进货或者通过购买量这样的谈判来取得一个更可接受的价格?

       员工是从首选厂家寻里购买的货或者变通执行谈判达成的厂家协议

       厂家行事如何?厂家的注入率是多少?按期交货情况如何?是否支付了最近的货款?订货不是占订单的百分比是多少?到货检验打出废品率是多少?

2.         采购事务

       将事务日期、产品、厂家、合同期限与采购事务类型指定为关键性维度,同时将采购计量单位与事务总量看做事实。

合同编号是一个退化维度,可用来确定每份谈判合同给出的业务容量。

3.         多事务事实表与单事务事实表

业务用户针对不同的采购事务所进行的描述是不一样的,购买订单、发货通知、仓库接货与厂家付款等业务都被看做分开的独特处理。而事实上对所有事务源都提供支持的单个采购系统是不存在的。与此相反,需要用一个购买处理系统提供购买通知单与购买订单,由仓库处理系统提供发货通吿和仓库收据,以及用账户支付系统处理厂家付款方面的事务等

是建立一个带有事务类型维度的混合事务事实表而一起查看所有采购事务呢,还是为每个事务类型单独建立一个事实表?需如下说明:

a.                  首先,用户的分析需求是什么?作为设计人员,要达到的目标就是降低复杂度,从而用最有效的形式将数据展示给业务用户。

b.                  确实存在多个独特的业务处理吗?

c.                  涉及到多个源系统吗?

d.                  事实的维度是什么?在采购业务例子中,找到的几个维度适合于一些事务类型,却不能用于其他事务类型。这又将导致使用独立的事实表。

由于操作型数据存在于独立的源系统中,所以当然需要在一些场合使用多个转储。将数据加载到分开的事实表比试图将来自多个源系统的数据集成为单事实表,具有较少的复杂性。

              对产品的流动情况很感兴趣,那么跨处理的累积快照会是特别有用的

4.         渐变维度

1.  对大部分维度随时间基本保持不变

2.  仅仅进行相对较少的调整,就能做到在对变化做出反应的情况下,保持相互独立的维度形式。

综上两点叫渐变维度(Slowly Changing DimensionsSCDs

       必须为维度表的每个属性指定处理变化的策略

       类型1 改写属性值

用户仅仅用当前值取代维度行的旧属性值可以完成对它的改写,这样处理属性所反映的总是最新的值

但类型1响应方式容易实现,但不能对旧属性值的任何历史数据进行维护

       类型2 添加维度行

每个独立的代理关键字标出在一个时间跨度内成立的惟一产品属性概况。在修改中为维度行包括一个生效日期标记

类型2响应方法是准确跟渐变维度属性的主要方法。这种方法由于渐变行能自动区分事实表的历史而显得特别有效

       类型3 添加维度列

假定存在针对变化出现的前后一段时间同时跟踪新旧部门属性值的合理业务需要。增加一个新列来获取属性的变化。

类型3对维度处理方法可用于任意通过新的或者以前的属性值、了解新的以及历史实际数据

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值