七嘴八舌谈业务建模和数据建模

最近工作比较忙，一直在TTNN潜水，看到大家在讨论业务建模和数据建模，我也一直做这个方向，很感兴趣。我把业务建模和数据建模的关系理一下，这样争论也有个基础。当然其中肯定也有不当之处，请多多指点。

　　先说业务建模，业务建模一般分两类。第一类是为了解决某个业务问题而建立一个业务模型或者数据模型。第二类是将企业的业务状况、业务流程及用户对业务的分析视角等信息用计算机的语言表示出来。这两类建模从方法到目的都是不同的。

　　第一类，举例来说，对客户信用状况的评价，这需要从业务的角度来考虑反映客户信用状况的因素各占多少比重等等内容，这些是业务人员需要完成的工作，有大量的领域知识在里面。这部分建模的结果有些会反映到信息系统中，有些就只是咨询，反映到用户的日常工作中。

　　第二类，是对企业业务状况的描述，如贷款和抵押品之间是什么关系，与抵押品相关的信息都有那些、产品内部的层级关系，用户分析问题的业务视角等等，这些内容需要业务人员和信息人员共同参与完成，最终体现在信息系统之中也就是开发人员使用的数据表。

　　对于KPI的建模是属于第一类业务建模，它的重点在于哪些因素会影响KPI，影响的比重有多大。但是计算KPI需要的因素以及对这些因素的数据需求都属于第二类业务建模。

　　再说数据建模，数据建模也分为两个步骤，第一类是逻辑模型，第二类是物理模型。这两类模型的差别并不是很大。

　　第一类，逻辑模型，也称为实体关系模型(维度建模可以认为是实体关系建模中的一种)，是用计算机术语表示出来的业务状况以及业务分析视角。事实上，逻辑模型就是前面提到的第二类业务模型。我们是做信息系统的，所作的东西最终都是要体现在计算机里，所以，第二类业务模型和数据模型之间的距离并不大。

　　第二类，物理模型，是将逻辑模型转化成的物理表，这里会出于性能、效率和易用性等考虑对逻辑模型做一些处理。这些处理在逻辑模型中也存在。将逻辑模型转化为物理模型需要DBA的参与。

　　而我们在日常工作中提到的业务建模一般是指第一类业务建模，即从业务的角度来设计KPI等内容。我们在日常工作中提到的数据建模一般是指第二类业务建模，也是第一类数据建模。这两类原本就是同一份工作。也许有很牛的公司会将这两部分分开，请完全不懂技术的业务专家来设计这部分。但大部分情况下这部分是需要业务和技术都懂的人来完成。我理解innovate511提到的数据建模应该是这类和业务也直接相关的建模，而不是纯数据的建模。我们再看DW和BI，一般DW里不会有第一类业务模型，但是一定会有第一类业务模型需要的数据，也可能有第一类业务模型分析的结果。而BI里可能有第一类业务模型，也可能没有第一类业务模型，例如对数据进行OLAP分析就不一定有第一类业务模型。但是勿庸置疑的是，无论是DW还是BI，它的目的都是为业务服务的。所以说业务驱动BI、DW或者说需求驱动BI、DW都是一定的。但是归根到底，DW和BI都是用来辅助分析的，真正提高企业效益的是使用DW和BI的分析人员。从非技术层面来促进BI成功我的感觉更像是借助BI来提出的管理咨询，而不是信息技术咨询。

　　随便谈几句，欢迎指导。

　　和你的看法差不多，所以我把511的数据建模看作业务建模，落实到数据库就是物理建模。

　　全民BI那等于大家都不要做了，告诉客户老总说，你们的企业管理方式错了，要这样这样搞，其实这不是搞BI，而是搞管理咨询了。事实上这种做法在甲方自身没有什么执行力，混日子的员工懒得理你，分析人员自有自己的分析方法不干BI的事情，剩下的想要看数据的业务人员肯定是要求助于IT来整理数据，但按道理乙方又不做实施，于是成了空对空。所以这样的consultant还是去麦肯锡吧，不要来趟BI这个浑水了。

　　如果你这样理解业务模型和数据模型，我觉得也可以。 只不过这样第2类业务模型和第1类的数据模型就难界定了。 难界定的东西会使业务部门和技术部门相互指责，如果技术部门要强势，就会出现一个"牛比无极限"第1类的数据模型包含了第2类业务模型，然后当BI项目失败的时候，就会出现牛比的专家说：我们的数据模型是先进的，但这个企业业务人员能力还不到等等这类的话，这样的话难道还少吗，这样的故事难道还少吗。

　　关于我的"非技术层面"，不是管理咨询的书，我没这么牛比，提到的概念，在很多管理人员中都知道的，我只是把这些概念做到BI实施中而已，来改变由于"牛比无极限"第1类的数据模型导致业务部门和技术部门相互指责是现象， 是BI实施的咨询。

　　关于BI和DW，还是没有达到共识，我在"非技术层面"已经提到了BI，就是一系列的方法和概念，在技术上是DW技术，OLAP技术和数据挖掘技术的综合运用而已。

　　既然你认为全民BI是大家都不做，你以为每个人做同一件事情呀，以为是大锅饭。 那你对BI的理解，就是分析一个事情，每个人都是一样的思路，才是正确的。你这样才是BI的空对空。 BI需要一系列的方法和概念来支撑决策，当然也包含业务模型和数据模型。但唯一不变的就是决策需要分析，分析需要思考，BI只是给出了思考的一些素材而已，别以为一个牛比的模型就代替支撑决策的一切。 BI这个浑水有多深，我搞了10年都不敢说有多了解，你一个模型就知道这水多深了。太牛比无极限了吧。

　　关于BI和DW，还是没有达到共识，我在"非技术层面"已经提到了BI，就是一系列的方法和概念，在技术上是DW技术，OLAP技术和数据挖掘技术的综合运用而已。

　　DW和BI的范围如何划分确实没有定论。您的这种理解方式肯定是正确的。另一种理解方式是DW主要负责收集和保存数据，BI主要负责分析，这样理解也没有错误。我个人对这两种理解方式没有偏向，大家都能理解表达的意思就好。

　　OK，你这个描述，我也是赞同的，我把你这个定义的BI，称为狭义的BI，主要是解决前端层面的技术，工具等等的系统都包含在里面。 如果这个定义达到共识，那就不用讨论了。 只要讨论模型即可，按照raullew的说法"我把511的数据建模看作业务建模，落实到数据库就是物理建模。" 也就是BI无模型，DW上即是业务模型又是数据模型，真正的"大牛比模型"，解决所有BI的问题，是不是这个意思?

　　从你的逻辑，我只能认为是大家都不做了BI可以不要DW，于是乙方的数据集成可以不做了BI是甲方业务人员的全民BI，于是乙方或者IT部门的报表也可以不做了那么大家都不用做了，只要按照你的思路，心怀一颗"人人分析，丰衣足食"的心，并随时拿起EXCEL，这个企业或部门的BI，就自然而然的水到渠成了。

　　我是把business model等同于data model的，但这是IT领域建模的business model，不是商业领域的business model， 这样区分也许不会再有文字上的歧异了。

　　呵呵，你太幽默了，既然你把business model和data model搞成一样了，而且不是商业领域的business model(那这个又叫什么)。 OK，我也认可了你这样把business model和data model是一回事，都归于IT了，也就是说BI的成功基础是IT，IT驱动BI，对吗?

　　谢谢jerome给业务模型和数据模型一个区分，看完之后我的理解是有三种：

　　一、是业务人员主导的：第一类业务模型

　　二、是业务和技术专家主导的：第二类业务模型(也即第一类数据模型)

　　三、是技术专家主导的：第二类数据模型

　　是不是这样的?这种划分可以接受，关于业务模型vs。数据模型，BI vs。 DW，这种争论没有尽头。而业务驱动BI的说法，显然大家都已经接受。本帖的主题是细化了模型概念的定义，不过后来又扯到持续改善上面了，有趣。

　　呵呵，jerome说法我同意，Qing你的总结我也赞同，后来的讨论就是集中在第2点上，业务和技术专家主导业务模型(或者第1类数据模型)，是如何界定的问题上展开了。 Raullew认为这就是"511的数据建模看作业务建模，落实到数据库就是物理建模"，把它归于技术了，所以就展开了。

　　其实，这是"持续改善"的继续讨论，业务和技术专家主导业务模型(或者第1类数据模型)如何界定? 就是我提出的对于分析角度业务部门和技术部门各自表述的"管理视点"。

　　其实解决第2点，也就解决了我们所有以前的讨论，我为什么一开始提"OLAP工具毁了BI"，就是因为目前OLAP工具太关注图形形式和报表功能了，所以我提出OLAP工具应该在第2点上细化实现界定，不然会毁了BI的，我和511的业务模型和数据模型之争论其实也是在争论这个界定，应该是技术还是业务来主导的问题。jerome把业务模型和数据模型做这个区分，也是在谈这个问题，只是他提出了区分，没说第2点如何界定。

　　对于界定问题的讨论，有很多，比如，这段时间大家关注比较多的"股指期货"的历史，产生的时候也是有争论，是股票交易所来管理，还是期货交易所来管理?争论了7年，才出来结果。 所以我觉得在BI这点上的讨论是正常的。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友