OLAP工具毁了商业智能

interstage

最初由 innovate511 发布
[B]
前辈，你太让人失望了，自己的例子都搞不定啊？你说你举的例子属于CIF还是MD模式？老讲这些概念有意思吗？前辈和我争论个啥了，已经有好几个人感觉你在南辕北辙了，我明明说你举的例子有问题，你非要说我忠于某个方案，这种看法，除了你以外，还有第二个人么？前辈该不会忘了，BIDW是实践性的东西，不是谁能扯就受欢迎，而是谁能解决问题才受欢迎吧？

我为啥前面力挺你？因为你在某些方面能解决问题。而你现在谈DW，连一个基本的，你自己提出的案例都解释不清楚，如何给itpub那么多观众交代呢？

呵呵，这次我不用想你下一个帖子说啥，肯定你会继续说我只站在什么CIF模式，什么象Inmon一样，好象你只会说这个，实际的东西我已经向你这位前辈说过几次了，既然你提出了案例，也该给看贴的晚辈们一个交代，不能总东躲西藏的吧？难道继续话不答题让人看笑话？ [/B]

这样吧,我的实施文档中涉及到的需求和数据源结构,有最终用户的内部资料在里面,不方便给出.
如果哪位提供一个需求和数据源结构. 我做一份实施方案给人家.

如何.我就是MD方式的实施者.

innovate511

最初由 interstage 发布
[B]

这样吧,我的实施文档中涉及到的需求和数据源结构,有最终用户的内部资料在里面,不方便给出.
如果哪位提供一个需求和数据源结构. 我做一份实施方案给人家.

如何.我就是MD方式的实施者. [/B]

那就对了，我也是从MD方式的角度处理前辈刚才说的例子，真不知道为啥前辈会在前面的例子中提出DW里解决不了。

既然前辈是MD方式的实施者，应该看过Kimball的Data Warehouse Toolkit, Data Warehouse Toolkit second edition, Data Warehouse Life Cycle Toolkit, Data Warehouse ETL Toolkit以及Kimball官方网站的好几十个处理具体问题的Kimball Design Tips吧？ 我想前辈举的例子中，Kimball书中已经多次提到解决方案了，应该很轻松可以解决呀。如果前辈没有这些书籍的话，ITPUB就有部分电子书籍的下载，相信会有前辈想要的答案。

interstage

最初由 innovate511 发布
[B]
那就对了，我也是从MD方式的角度处理前辈刚才说的例子，真不知道为啥前辈会在前面的例子中提出DW里解决不了。

既然前辈是MD方式的实施者，应该看过Kimball的Data Warehouse Toolkit, Data Warehouse Toolkit second edition, Data Warehouse Life Cycle Toolkit, Data Warehouse ETL Toolkit以及Kimball官方网站的好几十个处理具体问题的Kimball Design Tips吧？ 我想前辈举的例子中，Kimball书中已经多次提到解决方案了，应该很轻松可以解决呀。如果前辈没有这些书籍的话，ITPUB就有部分电子书籍的下载，相信会有前辈想要的答案。 [/B]

呵呵,我知道你对我时间纬度的解释方式不满意,导致了你我在DW的争论.因为Kimball在书中提出可以在DW中可以建时间维表来解决,但我在后来的实践发现,通过这样的定义方式不合适,因为业务人员描述时间的方式从来不是这天是这个月第几天,这个财年的第几天.
都是本月,上月,今日,昨天,3天内,年初到现在的累计等等,以时间维表的方式是符合DW数据模型,可以在业务模型描述中做逻辑判断.

但我实践中发现NV在时间模版的管理视点设计和描述上更贴近用户,导致我目前放弃了Kimball对时间维表的方法.

这可能就是你我争论的起因.

innovate511

最初由 interstage 发布
[B]

呵呵,我知道你对我时间纬度的解释方式不满意,导致了你我在DW的争论.因为Kimball在书中提出可以在DW中可以建时间维表来解决,但我在后来的实践发现,通过这样的定义方式不合适,因为业务人员描述时间的方式从来不是这天是这个月第几天,这个财年的第几天.
都是本月,上月,今日,昨天,3天内,年初到现在的累计等等,以时间维表的方式是符合DW数据模型,可以在业务模型描述中做逻辑判断.

但我实践中发现NV在时间模版的管理视点设计和描述上更贴近用户,导致我目前放弃了Kimball对时间维表的方法.

这可能就是你我争论的起因. [/B]

根本原因还是前辈对数据建模到底能提供到什么程度的信息没有把握，这也是我在紧问前辈在前面提出的例子，因为我感觉很奇怪，为啥会被认为数据模型不能提供解决方案，而在Kimball 的数据模型方案中，是有答案的。

至于你说的时间维度问题，你也说过NV提供93种维度型，还有扩展功能，那么数据模型的维就不能提供解决方案么？而且从实施的角度看，把这个问题解决在数据模型里，就连刚做BI 2年的新人懂得这样更合理，他们有时在BI业务需求来了后才用工具临时去处理，那是没有办法的，没人给他们整体规划的话，也只能这么将就处理了。

interstage

最初由 innovate511 发布
[B]
根本原因还是前辈对数据建模到底能提供到什么程度的信息没有把握，这也是为啥我紧问前辈在前面提出的例子，为啥会被认为数据模型不能支持，而在Kimball 的数据模型方案中，是有答案的。

至于你说的时间维度问题，你也说过NV提供93种维度型，还有扩展功能，那么数据模型的维就不能提供解决方案么？而且从实施的角度看，把这个问题解决在数据模型里，就连刚做BI 2年的新人懂得这样更合理，他们有时在BI业务需求来了后才用工具临时去处理，那是没有办法的，没人给他们整体规划的话，也只能这么将就处理了。 [/B]

hehe,看来又要争执了,算了,不讨论了.总而一点,就是我认为不管是谁做的数据模型(包括Kimball )肯定会滞后业务模型的变化,而变化出现的时候,让IT部门从数据模型上进行修改或者扩展,不是不可以.但出现业务部门需要与IT部门协做的问题.人与人之间的交流都有问题,何况工作上的,所以,业务模型如果能做到扩展,不求IT部门的数据模型的话,业务人员会喜欢. 至于你说可能会导致性能上下降,不是我们讨论的问题,实际上没下降,比直接做维表反而快.

呵呵

innovate511

最初由 interstage 发布
[B]

hehe,看来又要争执了,算了,不讨论了.总而一点,就是我认为不管是谁做的数据模型(包括Kimball )肯定会滞后业务模型的变化,而变化出现的时候,让IT部门从数据模型上进行修改或者扩展,不是不可以.但出现业务部门需要与IT部门协做的问题.人与人之间的交流都有问题,何况工作上的,所以,业务模型如果能做到扩展,不求IT部门的数据模型的话,业务人员会喜欢. 至于你说可能会导致性能上下降,不是我们讨论的问题,实际上没下降,比直接做维表反而快.

呵呵 [/B]

从项目顾问和实施者的角度看问题，必须从几个方面去考虑问题：
1. 客户满意
2. 在1的前提下降低成本使公司更多赢利

那么我不管你什么产品，在整体方案中只是一步棋而已，就和导演和演员的关系一样。如果你提供的功能很强大，但影响了客户满意度，比如实施难度（如功能无法实现，有bug等）、效率问题等，那么是不能被接受的。

前面bq_wang提到过，这个思想Fenet公司的产品有类似功能，但实际实施的时候效率不够理想，如果你说你的例子是建立在少数据量的基础上，那么这个案例没有实际意义，因为从产品的角度讲，只有经过压力测试的产品才能成为成熟产品。所以很多第三方实施厂商基本都认为厂商只会忽悠，演示的都是最基本的，数据量小的东西，真正用起来非常难受。

为啥在实施方法论里都认为需要在数据模型里去实现，原因就是数据模型是预处理好的，可信的，稳定的，那么业务分析时可以直接拿来用，可以不考虑转换带来的效率问题。如果前端去处理，就不同了，没有预处理，没有结果存储，既有效率隐患，也有信息重用性的不足。

至于人与人的交流问题，这个不是重点。因为从各个产业发展至今，都是分工越来越明确，靠的就是流程去整合。未来的趋势也是分工越来越明确，而不是一个产品可以上上下下的事情都做完了。

interstage

本文提出的原意,是我认为目前OLAP工具违背OLAP概念中的核心部分,过分把功能放在展现部门,抢了报表工具该有的功能,使业务部门和技术部门工作上出现脱节和重复的现象.不符合持续改善的企业BI项目,会毁掉BI的.

讨论到现在,把我的本意没讨论清楚,反而对我的DW实践经验提出质疑,认为本人是一个大忽悠.
我承认我没做过象innovate511这样CIF的EDW,这是我的职场过程造成的.但我也感谢职场过程中对那些持续改善的企业,需要上BI生存的企业,让我实践了MD方式的DW.我在实践过程中,总结了我的经验,至少我认为是比较快速能够结题项目的,仅供参考,如果那些实施过CIF方式的BIER认为是小儿科,只能说明他的命比较好,但尺有所短，寸有所长,各有长处，也各有短处，彼此都有可取之处。不要因为实施过CIF的,就看不起MD方式.
至于对interstage NV的质疑,我可以明确表态,首先它是1991年的工具,目前全球有近7000个服务器中装着它的软件,我去年在中国的第一个CASE,就是进行数据测试赢的,同样是NV,BO,HyPERION在同样的SYBASE IQ上,测试大数据分析统计,一样的事实表,一样的纬度表,一样的关联模型,NV的速度一直是最快的(至于为什么最快,我在后来才明白),这样征服了用户的IT部门.
    NV中专利的管理视点技术快速解决数据模型滞后数据模型的变化问题,让业务部门非常满意,保护了他们不成熟分析验证的隐私和分析变化不过分求助IT部门的情况.

因此,用户选择了这个产品,并快速实施了MD模式下的BI系统.

使我对以前MD模式下的实施DW来快速实现BI分析,产生了质疑,我一直认为BI就是方法论,项目管理流程化,由预处理好的数据模型来控制业务模型的变化,是主要因素,而产品的选择不是关键.

但,突然发现,原来产品有另类的诠释, 如果在技术标准上产生的产品,的确可以不是BI项目选择的关键. 但如果,从管理和方法论角度出发,设计出来的产品,可以颠覆我们原来的实践经验.

这就是我对NV的不同之处的强调. 如果人家认为我有推销之嫌,我不反对,但请不要对我人身的攻击.
欢迎讨论.

kinghq

一般做项目一上来就会问：您的需求是什么。如果有需求，那就满足需求就行。如果没有需求，那么多半会让人傻眼。那您上项目干什么呢？对，绝大部分人都会问这个问题。这是一个好问题，但答案并不容易得到确认。在这种情况下，项目该怎么做呢？

一种就是interstage说的：让业务部门自己来把握整个项目，毕竟有工具来支持这样的思路。技术部门针对这个过程中产生的业务部门的任何技术需求去满足就行了。当然，怎么满足呢，主要是技术部门打算如何去处理技术需求。如果要对这些技术需求进行收集整理、等一等再响应业务部门的，那么技术部门完全有时间对其进行整体考虑。在这种情况下，如果涉及到DW，就可以借用大家说的CIF的方式来做整体规划和优化。如果需要即时响应的，那么技术部门就需要另选择逻辑上能用的方案了，比如DM。至于是不是优化过的等等问题，等有时间了再来解决。但起码已经知道了“接口”所在。

一种是我觉得是 innovate511 谈的：任何一个行业中的企业都有其通用的数据模型，先对这些在技术部门进行实现，以表明技术能做什么。技术部门再把这些能做的展现出来，让业务部门自己的挑。如果有什么是现在还不能做的，那么这就是日后丰富和完善数据模型的需求：大的要改变数据模型，小的可能也就是增加一个维度什么的。当然，对数据模型的这些需求也可以参考前一种做法的两种方式。

当然，这种项目的做法还会有很多。比如如果有能力，完全一上来就大谈特谈“业务模型”、“决策模型”、“方法论与最佳实践”。其实谈这些都没有关系，关键是能自圆其说、能让客户信服、最后做出来的东西能让大家（包括自己）认可。当然，也完全有可能说，我“双管齐下”：interstage和innovate511（是我觉得的） 两种都来做。

不管怎么样，项目最终是要交给客户自己的。虽然不指望说项目都是“交钥匙”工程，但绝不期望是那种“扯不清、理还乱”的遥遥无期型项目（终结这样的项目，往往不是因为技术原因）。起码从我个人角度来说，对于IT项目很忌讳谈什么二期、三期：因为一般项目的二期、三期都是一种设计成本几乎为零的复制。可放眼看过去，一种莫名的担忧油然而生。解决这个担忧，我在那个DWBI项目症结的帖子中做了一定的探讨；另外，对要来做这个事情的人也应该在项目思路上转变一下：应该以项目的对客户能用成果和对客户有益的价值为导向来做事情——这样双方在沟通上也是最容易的——因为双方有共同的沟通语言（绝不是说懂了业务名词或业务流程就叫有了共同的沟通语言）。所以我向来认为：商业沟通是最好的沟通方式——简洁明了、经济可靠。

interstage

最初由 kinghq 发布
[B]一般做项目一上来就会问：您的需求是什么。如果有需求，那就满足需求就行。如果没有需求，那么多半会让人傻眼。那您上项目干什么呢？对，绝大部分人都会问这个问题。这是一个好问题，但答案并不容易得到确认。在这种情况下，项目该怎么做呢？

一种就是interstage说的：让业务部门自己来把握整个项目，毕竟有工具来支持这样的思路。技术部门针对这个过程中产生的业务部门的任何技术需求去满足就行了。当然，怎么满足呢，主要是技术部门打算如何去处理技术需求。如果要对这些技术需求进行收集整理、等一等再响应业务部门的，那么技术部门完全有时间对其进行整体考虑。在这种情况下，如果涉及到DW，就可以借用大家说的CIF的方式来做整体规划和优化。如果需要即时响应的，那么技术部门就需要另选择逻辑上能用的方案了，比如DM。至于是不是优化过的等等问题，等有时间了再来解决。但起码已经知道了“接口”所在。

一种是我觉得是 innovate511 谈的：任何一个行业中的企业都有其通用的数据模型，先对这些在技术部门进行实现，以表明技术能做什么。技术部门再把这些能做的展现出来，让业务部门自己的挑。如果有什么是现在还不能做的，那么这就是日后丰富和完善数据模型的需求：大的要改变数据模型，小的可能也就是增加一个维度什么的。当然，对数据模型的这些需求也可以参考前一种做法的两种方式。

当然，这种项目的做法还会有很多。比如如果有能力，完全一上来就大谈特谈“业务模型”、“决策模型”、“方法论与最佳实践”。其实谈这些都没有关系，关键是能自圆其说、能让客户信服、最后做出来的东西能让大家（包括自己）认可。当然，也完全有可能说，我“双管齐下”：interstage和innovate511（是我觉得的） 两种都来做。

不管怎么样，项目最终是要交给客户自己的。虽然不指望说项目都是“交钥匙”工程，但绝不期望是那种“扯不清、理还乱”的遥遥无期型项目（终结这样的项目，往往不是因为技术原因）。起码从我个人角度来说，对于IT项目很忌讳谈什么二期、三期：因为一般项目的二期、三期都是一种设计成本几乎为零的复制。可放眼看过去，一种莫名的担忧油然而生。解决这个担忧，我在那个DWBI项目症结的帖子中做了一定的探讨；另外，对要来做这个事情的人也应该在项目思路上转变一下：应该以项目的对客户能用成果和对客户有益的价值为导向来做事情——这样双方在沟通上也是最容易的——因为双方有共同的沟通语言（绝不是说懂了业务名词或业务流程就叫有了共同的沟通语言）。所以我向来认为：商业沟通是最好的沟通方式——简洁明了、经济可靠。 [/B]

你的说法,我基本上赞同.但我觉得少个1个,就是技术人员先提需求(不管需求是否完全合理,总可以提出一部分),技术部门把需求转为业务模型,然后设计成数据模型,最后展现出来.业务人员上系统后,提出新的需求了,如果改动或者扩展的工作不大,技术部门就修改(原则上10%以下属于维护费范围,10%-40%属于技术支持的人工费),;如果改动量大(40%工作量,立项为第2期),就是这样的循环着.

象innovate511这样技术部门先引入通过模型,只有大企业上整体的EDW有用,但实际上,很少有这样的公司一开始就上EDW,也是从MD方式做起,就以HP的例子,本身是大企业,又是IT公司,应该更知道DW的重要性,但HP很早就建了MD了,但现在还在建EDW.

interstage

所以在DW领域上,我们感谢Inmon,他的确定义了DW;但我们更感谢kimball,他给出的DW架构,让DW变成不再是只能大企业和高费用的项目了. 所以kimball不仅是实践大师,更是理论大师.
尽管,我对他提出的数据仓库是虚拟概念,只是无数数据集市的整合这个说法.一直很质疑.但他的纬度设计的验证性方法一直闪烁着他的方法和技巧.
但,如果连他这种技术和方法都不能解决了,我们是不是还需要改变.