什么是BI建模，建模的本质是什么？
前几天和大项目团队一起和厂商聚餐，后来发了个厂商的小礼品，是一个便签本，本子面上是塑料的壳，上面是一个活动日历，中间如下面的数据，由一个框架在数字上面，可以活动左右移动，框架上面有周日到周六的英文简称，最左边是指针，指着上下2列数字，分别代表月份，上是12年，下是11年。例如11年6月，指针就会覆盖到第三列，那么我们看到框里的数字，就是从第四列到10列，大家看这些数字，刚好是6月的日历。如果是11年7月，则从第二列到七列，框架下面的代表月份的数字写得很清楚了。1 234567
234 5 678 9 1011121314
9 10 1112131415161718192021
16171819202122232425262728
232425262728293031
3031
话说这么多了，上面的例子是非计算机领域的日常用到的模型，来处理本来需要24页纸来描述的日历，只要在一页纸上就能基本描述清楚。当然只是基本，唯一的缺点就是每个月都会有31日，这个模型无法处理掉，但是不影响我们的使用。
首先这个模型的目标是将24月日历的变化能在一个图表里完成，这也是这个设计的需求。那么设计者发现，其实日历的变化，无非是每月从1号开始的星期不一样，从周日到周六，都有可能，于是我们的能左右滑动的框（框里有周日到周六的对应指针），就能解决这个问题。那么这个数字就需要7+6=13列数字。那么下一个模型问题，第一排数据，如何与第二排衔接。这个问题就是由日历的规律所决定，如果1号是周六，那么下一个星期的循环，应该从2号开始，于是第二排第一个数字肯定是2，而第一排必须有必要表达完整的星期，所以第一排数字定义为1到7.
那么第三、第四、第五、第六排的开头数字都以一个星期的周期7天累加。那么这个模型基本构架就完成了。刚才说到的唯一不足，就是31号无法解决，因为这个模型的致命缺点就是无法根据每月天数的多少，屏蔽其他只有30、29天的31、30日，这个在模具上是无法完成的，除非有更精巧的控制性设计，但要复杂很多。
现在回到我们的企业级BI模型当中，如何才能建好一个能反映业务本质的模型。首先要搞清楚BI建模的本质，BI建模与业务系统建模出发点是不同的，业务系统的模型，主要描述事务的流程，以及流程相关的控制和关系。而BI的模型则描述业务因果关系、因果过程原因等深层次信息的模型，它既可以描述事务的流程，也可以直接跳跃流程，直接奔流程头、尾的结果而去。
以前我就说过，如果按照业务系统的模型建BI的模型，那搞不出什么名堂，顶多还是ERP的附属物，甚至是无关紧要的系统。BI的模型，就得以事务的生命周期为线索，它不是ERP任何业务点或业务流程，它是由于智能化需要而抽象出来的模型。生命周期这类切合到战略战术，又能细到业务运营的业务概念，可以说是业务模型的法宝。生命周期之间可能有上下游，以及上下层关系，弄在一起，形成完整的业务模型框架。这种模型的本质，就是概述业务的来龙去脉，既然可以描述业务细节，又可以直接描述业务开头与结果的关系，而且环环相扣，相辅相成。只有在这样的模型下进行业务分析和BI应用，才能更大更高效产生BI的价值。
页:
[1]