ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 转:基于BI应用的数据仓库建模归纳

转:基于BI应用的数据仓库建模归纳

原创 Linux操作系统 作者:ceo_lxy 时间:2011-09-01 09:17:48 0 删除 编辑

基于BI应用的数据仓库建模归纳

2010-7-20 21:21| 发布者: 管理员小杨| 查看: 2870| 评论: 0

至于数据仓库架构该怎么建、怎么优化、ETL怎么设计维度模型设计技巧等等,不在此讨论范围,以前已讨论过很多次了。但独立的讨论对于BI从业者来说,如同天书,不会有太多感受的和深入理解的,因为太抽象,很难与实际项目相结合。另外关于数据仓库构建的“数据驱动”,还是“业务驱动”,看了我这篇文章,也许会对你有帮助。

开篇:首先数据仓库有2大功能,一是企业数据的整合与历史信息的存储,二是支持BI应用,所以数据仓库中有太多理论,都以围绕实际应用为最终目的。

企业数据的整合与历史信息的存储应用:目的有2点,一是为BI应用打下数据整合的基础,理清数据之间的关联关系,对业务流程关系打下基础。二是历史信息的存储,历史信息包括固定信息和变化信息,通常来说历史信息的变化,主要应用在维度上,一是维度变化捕捉起来存储量不大,实现容易些,而事实的变化捕捉量很大,且必要性不强,往往多几个时间字段,对于变化就可以辨别出来。至于数据整合,就需要结合BI应用来讨论了。

BI建设性价比如何,是否得到企业认可,关键看用户是否使用,而且看使用频率和用法范围,只有弄清楚这个,我们高高在上的数据仓库和BI理论,才能落地产生价值,迎来BI下一轮发展。那么企业用户到底在做些什么呢?不妨我们多走访不同类型的用户,看看BI如何帮他们,我们后台模型的设计心理才有底。

高层决策者:每日/周/月/季/年都需要看关于企业的核心数据,以及各部门分析出来的报告,以便下一步决策;
中层干部:每日/周/月/季/年都需要根据部门的特点,进行专业分析,形成报告,上报高层,包括发现了商机、发现了运作问题,以及问题涉及到的业务流程和相关原因。
底层分析人员和基层干部:1. 根据上级领导的需求制作报表;2. 基于上级领导的任务,去找业务问题,做细节跟踪,发现有问题的产品或单据、订单、客户等;3. 根据自己负责的那一小块业务,对业务运作进行分析跟踪,发现数据异常后做报告,以便得到领导批示是否进行改进。

在你充分了解你的客户整天干什么的时候,你的BI可能产生价值,才能替代原有工作模式的同时,还能产生更丰富的价值,使BI不断深入企业各层人的心。

通过对BI需求的了解,于是数据仓库建模型,应该毫无争论地进行,只是各个理论倡导的,在不同时间点,做到什么地步,可能有值得商榷的地方。

首先得有ODS和EDW,在传统定义当中,ODS与EDW都是基于业务的数据,说直观点,应该是未汇总、丢失基础信息的基础数据。如果有人说EDW建设难度大,我们不妨先建设好ODS,对于业务数据抓取过来,进行通用的ETL技术处理,然后在ODS分2-3层,第一层作为与业务数据接口,一样的结构,二是桥接层或直接兼顾第三层,三是用户层(看情况可以设计为视图),可以将不同业务表之间进行关联,形成业务视图的作用,增加实用的指标。这样的设计轻松解决底层分析师和基层干部的需求。这也是不少项目ODS作用大,而有的ODS作用一般的原因,这要看EDW是否成熟。实践第一,能发挥作用,数据质量过关,就是好的应用,并非一定要技术十分成熟才能用,那时黄花菜都凉了。

对于EDW的设计,看起来和ODS一样都是基于基础数据的,但其抽象性远高于ODS。首先是整合程度。例如供应链这块,有的公司在某些仓库试点新的系统,与其他仓库不一样,所以得将完全不同的系统的数据,先抽象出来,形成统一的粒度,然后进行关联整合,而对于因业务不同的指标计算,更是要在ETL中进行处理,并做好元数据管理,以便维护。

然后是EDW的面向主题,例如物流供应链分析中,出、入库两类单据应整合在一起,其意义为面向仓库的商品运作。而在DW定义的历史的上面,主要体现在事实数据的历史数据,一般保留3-5年或更久数据,而维度数据根据情况,可能需要记录历史变化。在DW的稳定性上,一般不对事实数据进行变更,我们一般取状态已经确定好的数据,所以不用再变更。至于有的因为外因而导致的数据源进行了修改和删除,首先我们要跟用户提出,这样做不是最好的办法,他们可以用冲单等逆向数据流的办法,来处理数据问题,而非粗暴处理,我们BI有责任和义务建议他们。但如果真做了,那就个别处理,问题也不大,但要在DW中作记号,不建议DW中也直接删除等操作。

另外EDW里也可以分2-3层逻辑,一层是基础过程数据,针对业务过程的数据模型,二类是结果的,针对不同部门的需求,例如零售里商品管理的人员,不会问你这个商品经过多少物流操作销售出去的,而物流/供应链部门需要了解所有过程细节。

那么有了ODS和EDW,能满足中高层用户的需求么?答案是否定的,中高层需要的是面向业务分析的模型,这里就要看多维模型的设计了。至于到底该怎么做,请看下面de分解。
中高层用户到底要看什么东西?基层分析师到底要做怎样的报表,才能满足中层的需求, 而中层需要做什么样的报告,才能满足高层的决策性需求?

面向这个需求时,我们不得不改变上贴的特点,由业务需求来引导驱动!

老板和高层需要看到的是一个结果: 是否达成目标? 如果理想中什么事情都没有, 看看报告没啥突出嘛, 然后就可以不过问了. 当然显示中是问题多多, 领导需要的是一眼就能发现问题, 而且中层提交的报告中已经找到问题根本了,而且还有解决方案, 领导一看, 不错,那就这样, 希望下次的报告, 业绩有明显改善哦!

所以维度模型的设计核心,应从中层需求上找答案.  中层需求中,我们不难发现, KPI是重中之重. 例如我要达到领导说的将净利提高30%,你需要用哪些指标来分解\跟踪? 而领导们只能将指标分解到销售额\毛利\各种成本,之后呢?

作为BI建模, 我最近最为得意之作就是在分各个专题分析之后, 然后对业务过程进行抽象建模, 这个过程模型没有任何单独的业务意义, 却是所有分析的深入分析的支柱. 例如网络营销中, 当商品销售专题的时候, 发现某些商品点击不高,却销售量增加了不少,而销售额很少?  于是你返回过程分析中看,原来该类用户都是看过促销广告, 再该商品拉入购物篮, 原来作为捆绑销售, 既增加了这个商品的库存消化, 也带动其他商品的销售.

所以多维模型首先是专题的划分, 基本上普通一个专题2-3个事实表, 有的因为业务原因, 粒度有所不同, 所以事实表不止一个, 而抽象后的业务过程分析, 则要看具体业务需求, BI人充分消化后进行抽象而来的模型. 多维模型的参考辅助模型建设\以及其他技术技巧,这里不作讲解.
这里说的是数据模型, 其实最为关键的是BI的应用, 因为那算临门一脚吧, 成败在此一举, 如果BI应用一塌糊涂, 人家不知道怎么用, 整个数据仓库价值也大打折扣, BI也变得无人问津了.

BI针对不同用户的展现组合,解决实际业务问题, 使中层干部能做出漂亮清晰的报告和执行计划 , 我最近在其他帖子中有描述, 这里就不做详细讲解了.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12122734/viewspace-706394/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 想点点
下一篇: 9.1开学了
请登录后发表评论 登录
全部评论

注册时间:2008-06-02

  • 博文量
    519
  • 访问量
    490392