奥威软件交流社区

[讨论] 如何建好BI模型,建模的本质是什么?

2011-6-18 22:42
713217
       前几天和大项目团队一起和厂商聚餐,后来发了个厂商的小礼品,是一个便签本,本子面上是塑料的壳,上面是一个活动日历,中间如下面的数据,由一个框架在数字上面,可以活动左右移动,框架上面有周日到周六的英文简称,最左边是指针,指着上下2列数字,分别代表月份,上是12年,下是11年。例如11年6月,指针就会覆盖到第三列,那么我们看到框里的数字,就是从第四列到10列,大家看这些数字,刚好是6月的日历。如果是11年7月,则从第二列到七列,框架下面的代表月份的数字写得很清楚了。
                     1 2  3  4  5  6  7
       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的价值。
分享到 :
2 人收藏

17 个回复

倒序浏览
xtm502  会员 | 2011-6-20 10:00:01
帮顶一下
innovate511  会员 | 2011-6-20 11:06:25
补充说明一下,这里的BI建模,主要是业务模型,例子中,主要说明如何由业务模型思路,落地到具体的建模中去。 而实际BI项目中,最难的并非如何数据建模,而是设计合适的业务模型,既要了解行业业务,也要对企业的业务情况足够了解。业务模型的精髓是通过业务模型的构建,对业务流程的剖析,达到从宏观到微观的概论理解,使数据建模能有足够扩展性和实用性,同时对数据分析有思路引导作用。
xyly18  会员 | 2011-6-21 16:12:45
数据建模从技术角度进行概念、逻辑、物理建模,进行主题域、实体和属性填充

业务建模是业务指标+业务应用场景,形成业务模型

那么业务建模与数据建模结合的关键点是什么?

我认为建模的出发点还是业务驱动。
innovate511  会员 | 2011-6-21 16:22:12
业务模型的重点是讲述清楚你是怎样剖析要分析的业务对象,这就牵涉到从宏观概括,到微观业务流程和操作的全面理解,否则你没法剖析。 而数据建模的重点是将业务模型映射到数据结构里,就像我们机器编码10的组成,来描述清楚了我们无数的构想。

所以如果有了清晰的业务模型,剩下的就是拆分成不同的维度、事实,然后演变成不同粒度的事实表、桥梁表、维度层级等逻辑结构中去,最终落实到物理模型,建立在数据库。
stig  会员 | 2011-6-22 22:13:48
我来梳理一下:通常说数据模型,实际上有2个大的类型:业务系统的数据模型;BI系统的数据模型。
1,前者强调:正确的做事情;数据模型基本都是关系型模型。这种模型我们过去经常在做和使用。
2,后者强调:做正确的事情。数据模型基本上是关系型和多维行模型结合

BI系统的数据模型通常的方法或者步骤:
1,先划框框,做出一个subject area model,也有人说是概念建模。只是名字不一样而已。做的事情就是先划一个大饼出来;
2,继续细化,做逻辑模型,作出一个ldm。大部分都是按照ER来做的。这个地方的难点主要R比较难搞定,E相对比较容易,但是R怎么处理,相对模糊一些。
3,结合数据库的特点,依据逻辑模型,做物理模型。

在上面3个步骤中,有一个争论点在于最后到底是选择范式建模,还是多维建模。
1,有一个大佬的观点是基本上采用范式建模,在数据集市的时候选择多维建模;
2,有一个大佬的观点是倾向于选择多维建模。
在这些选择里面,潜藏着实施方法论在里面,有的人想做好基础,踏踏实实干,一步一步做;有的人认为不可能一开始就大而全,先搞一个快的用起来先,慢慢做完全。

项目具体做的时候,现成的模型很多,无论是IBM,还是TERADATA,还是第三方都有很多现成的模型供参考。包括通用模型,金融行业模型,电信行业模型,零售模型。先好好理解这些模型,不失为一个入门的捷径。

通用模型,有2本书,是2卷,国内已经出版了中文的。可以找来看看。先把这个看明白了,就好理解了。

数据模型是整个BI的核心,把这个理解了。其他的都是壳子。

友情提示,从这个很旧的帖子里面,可以找到很多不错的资料:

http://www.itpub.net/viewthread. ... p;extra=page=1

如果需要一些新的资料,不妨去亚马逊网站购买,或者去google book看一些新书的电子档。

随便说几句,我亦是外行说热闹话。

荒诞之处,博取一笑。
innovate511  会员 | 2011-6-22 23:18:49
呵呵,LS说的是数据模型,我说的是业务模型。

IBM等大公司的产品确实是数据模型,但我想问一下,有多少公司是自己在数据模型产品上继续不断扩展深入做BI的呢?没有几个,因为你连基于数据模型之上的业务模型框架都不理解,是无法扩展这个数据模型产品的,顶多是加些字段,做些增加的小需求。

一个在某厂商做数据模型产品的哥们说,他们从没接触过业务模型,都是美国那边扔过来一个基础数据模型,然后他们在上面扩展,形成不同需求的产品。我说老美很狡猾,说是中国团队开发,其实最核心的业务模型框架都留在总部的,中国团队只做针对不同细分应用的扩展,这就是老美的高明之处。
stig  会员 | 2011-6-23 08:13:44
可能是我打字的某些字眼,不对路吧。

我看到的现成的东西,都是一整套东西。

既从大到小,都有。有概念模型,逻辑模型,物理模型。所以不存在只有一个最后物理模型,而没有大的概念模型,逻辑模型的情况。

你说的业务模型大概是以概念模型和逻辑模型方式承载吧?
sinshan  会员 | 2011-7-4 18:06:25
呵呵,说到本质问题了,不才认为业务模型单纯靠实施厂商肯定建不来,实施方只是灵媒,达不到比整天在行业中摸爬滚打的企业决策层更懂业务的程度,能做到的就是把各家客户好的经验加以引用和推广。目前比较好的模式是咨询公司跟实施厂商一起做业务模型设计,咨询公司负责用行话与客户的业务精英们沟通,并让实施厂商参与抽象成逻辑模型和流程图,再由实施厂商转化成物理层落到实处。
innovate511  会员 | 2011-7-4 18:56:38
既然实施厂商没能力设计,那应该是咨询方与客户方一起设计业务模型吧? 另外现在越来越多甲方公司是自己作为咨询方也是设计方,这样更贴近业务的本质,而实施方来实施就好了。而也有甲方公司连数据模型也是自己设计的了,掌握全套核心东西。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

奥威软件|联系奥威|新手须知| ( 粤ICP备09215901号-2    联系客服

Powered by Discuz! X3.2 © 2001-2016 Comsenz Inc.

返回顶部