OLAP工具毁了商业智能

innovate511

我也提到过,在数据模型中,很多大公司根据行业的特点已经产品化了, 但是描述型很有限, 我们可以在其基础上扩展,发挥自己的力量. 对于时间维这种所有行业通用的维表, 完全可以产品化. 其内容主要体现在以下几点上:
1. 描述型丰富, 一般来说，我们可以丰富到上百个字段;
2. ETL产品化, 如果使用Java语言开发，那么这个ETL可以应用在任何平台, 也就意味着任何项目都可以使用, 不用再调试和测试;
3. 留足足够的扩展空间, 因为任何维随着时间的推移, 业务的发展, 其描述型都有过时的时候, 那么无论表还是ETL都留有扩展空间的话, 那么它的生命周期就会很长, 也能应用于各个项目, 无论你使用什么BI工具或者应用, 而Java除了跨平台外, 其面向对象的优点,也足以让它的可扩展性得到充分的发挥.

kinghq

innovate511，谢谢你在时间维度上给我的启发。

不过，我还是要把我的思路讲得更明白一些。所谓的统一数据视图是在广度上而言的；而所谓的统一维度视图则是在深度上而言的。

清楚了这一点，我就知道什么维度是现在已经有了的；即使有新的维度出现，我也先看一下能不能复用现有维度（借用和组合都算是复用）；如果真有什么满足不了的，再踅摸该怎么解决也来得及。

这样，对用户来说简洁明了——不需要去掌握所有的用不着的功能；对我们IT部门来说也知道到底应该干什么了。更重要的一点是：DW将不再是一个一成不变的，其有了生命力：一方面能够满足不断优化的功能性需求，另一方面通过自身数据架构的调整实现性能更高的数据组织形式。

innovate511

这个在数据模型中已经有很好的案例了, 如果是维的广度还是深度, 都可以在维度中实现, 并非要靠BI工具去帮助, 无论哪个BI工具, 也不过是在先有需求的基础上做了些扩展而已, 并没有什么高明之处.

比如Kimball在书中曾经有专门一小节讲解时间维, 在实例中他把公历日期、财务日期都放在一个表里面，这点我不是很赞同。首先这类不同种类的日期不仅仅只有财务日期， 还可能有报表日期、决策日期、预测日期等等不同的周期，那是否来一个新周期你就加在一个表里面呢？这样设计的弊病不言而喻。最好的设计方法就是重新建立新表，或者使用视图。道理很简单，由于描述型根据业务的飞速发展而更新很快，那么每种周期都有同样的描述型，在ETL实现中完全可以统一处理，既保证了扩展性，也保证了性能，灵活性也大大提高。

所以本质的东西还是在数据模型，不但可以成为优化ETL的一个力量，数据模型还反应了BI应用的变化和趋势，成为BI应用的一个重要接口，而不依赖任何BI工具。BI工具创出那么多名堂，无非是想推广自己的产品，同时“抢实施顾问的饭碗”。那么对不起，我现在要反抢BI工具的不该吃的那部分饭碗，因为你管的事太多了，限制了BI整体项目的灵活性、实现效率，可能导致增加成本（一般都会宣传降低企业的成本）。

jameszhuangmin

kinghq 和 innovate511你们二位说的都有道理，但不是同一件事情。

kinghq 是说要把BI设计尤其是维度设计上如何做得更合理些，哪些是不变的或者是很少变化的？哪些是经常会变化的？这些会经常变化的是否可以在一些相对固定的维度上产生？这是非常有道理的。我现在实施项目时就是这样的，设计了一组维度，其特点就是：相对固定，在各部门主题间复用性强，能够进行组合形成新维度的这些维度叫做公共维度。这些维度不管在任何企业里都用得到，而且基本固定，除了维表里的内容不同以外，其他的都不用做太多的修改。公共维度以外的一些维度就是项目实施时要定制的工作了，行业不同，部门不同，主题不同，就专门定制一些专用维度。但是，在定制这些专用维度时也要用定制公共维度的思想和方法去做，这样的话对以后的修改和调整都方便很多。而且这些维度的设计和工具无关。

innovate511是说这些公共维度不应该由BI工具来实现，应该由设计者来实现。我也非常同意你的观点。
站在实施顾问的角度长远来看，这些设计应该与BI工具分离。这样可以不依赖BI工具，不依赖数据库等等，公司的发展会自由很多，项目的可维护性也强很多。但是，站在项目快速实施的角度来看，尤其是新手上路的情况下，功能强大的BI工具就很有帮助了。对于这件事情我的观点是这样的：当我们有能力自己来设计公共维度而且设计得也非常好的前提下，我们应该自己来设计；当我们还没有这个能力的时候，还是借助工具更合适。就拿前面讲的时间维度的93个设计来说，但是，当我们只能设计出30个时候，我们还不如先学学这93个怎么设计的？为什么要这样设计的？一旦我们学会了，我们就可以抛开工具了。

人总是先要扶着东西学走路，然后再独立行走，最后我们才能飞跑起来，关键是一开始我们就要有一颗准备飞跑的心。

kinghq

工具能够起到管理支持的作用或者说在特定的场合发挥其应有优势就足够了。OLAP工具在展现这层上做得还是很不错的；不过现在的OLAP工具厂商也许忘了，在实际应用过程中并不是他们自己想象的那样去应用这个工具的，有其他变通的办法去做。

刚跟一位交流完。我发现自己更倾向于架构。也许是我的思路逐渐清晰，所以对工具以及各部分应该做什么都慢慢明确的缘故。现在我的问题就真的是DW或者叫EDW该怎么构建，这个方法论上的问题了。那种走模型的方式和方法，我觉得不适合我们：因为需求以及相关的数据基础并不明确和确定。所以只能走其他的路。

另外，如果站在用户的角度来说，还有“方法”上的需求。这个经过今天的沟通，确信是能够做到的了。

kinghq

jameszhuangmin，对于我来说，如果能实现这种维度深度管理的话，那么我就可以更好地构建DW了。从这个意义上来说，这个OLAP工具其实就是服务于我们IT部门了。

现在我发现构建DW是相当地困难，尤其是对那些说一定要有明确业务需求才能做工作的公司。这让我想起了当年移动经分工作的初衷的无奈。呵呵，我们就需要另外一种思路来解决这种无奈，这样既能开创一条新路，也能解决我们目前的困境和实际问题。

interstage

93个时间模版是工具给你的,用户也可以创造多更多的时间模版型.

有一点,我们一定要清楚.数据库表中的时间类型和业务人员心中的时间模版类型完全是不一样的定位,用数据库中建时间维表的方法,是很难突破的.

至少是不是用工具还是技术人员自己的架构,关键在于如何从业务人员的角度去考虑如何更方便.
所以,我一直在讲工具的设计思想,因为思想能给我们的架构有很大的启发.

而BI项目选型的BI工具,对设计思想的考虑应该更加注重

interstage

管理视点的技术是依靠5W1H的分析理论设计出来,而时间在管理视点上占很重要因素.一个叫时间型,直接映射数据库中的时间类型的字段.一个叫时间模版型,有业务人员按照自己的理解定义.
工具本身对业务人员常见的93种时间模版型提供支撑,业务人员也可以在管理视点中自己定义不同时间模板,比如楼上提到的财务时间,决策时间,预测日期等等.时间模版型 管理视点定义后,本身不出现具体时间,当每一张分析报表查询中,时间模版型和时间型会自动映射后,具体时间才会统计出来.

interstage

93种时间描述,只是引子,业务人员自己可以定义不同于93种的时间模版

所以我一直认为工具的核心在于它的设计思想,而不在于工具本身.

innovate511

Kinghq提到了架构问题，我也凑合几句。我在ttnn群里已经发起过架构的讨论热， 目的就是解决数据整合与BI需求之间实现方法的一些矛盾。我的观点就是，如果是构建EDW级数据仓库的话，整体架构需要考虑Inmon老大的DW方法论，这个可以参考他以前的书以及最新的DW2.0。对于维度深度挖掘方面，就得找Kimball的实践总结了。

现在还流行一些谬论，那就是数据集市==OLAP，或者数据集市就是为OLAP服务的。我们知道OLAP本身是BI发展的一个标志性阶段，可以实现包括查询、报表、多维分析等多个功能。但别忘了OLAP作为BI的一种手段，其局限性也很明显。首先OLAP中的MOLAP里的数据信息有限，对于复杂的查询需求或者报表，不见得能满足需求，除非你无限地根据需求更新CUBE。再次，OLAP对于数据挖掘的功能非常弱，一般现在做数据挖掘的项目，都是用SAS之类的专业软件去实施。所以OLAP工具无论多么高明，只能作为局部解决方案的角色，代替不了数据集市，更代替不了数据仓库该有的功能。