基于BI应用的数据仓库建模归纳，
前言: 至于数据仓库架构该怎么建, 怎么优化, ETL怎么设计, 维度模型设计技巧等, 不在此讨论范围, 独立的讨论对于BI从业者来说如同天书, 不会有太多的感受和深入理解的, 因为太抽象, 很难与实际项目相结合. 另外关于数据仓库构建是"数据驱动", 还是"业务驱动", 通过本文会有一些见解.
开篇: 首先数据仓库有两大功能: 一是企业数据的整合与历史信息的存储; 二是支持BI的应用,所以数据仓库中有太多理论, 都是以围绕实际应用为最终目的.
企业数据的整合与历史信息的存储应用: 目的有两点, 一是为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针对不同用户的展现组合,解决实际业务问题, 使中层干部能做出漂亮清晰的报告和执行计划