用编程思想的发展来比喻DWBI的发展

innovate511

DWBI和其他企业级管理软件系统一样，是基于管理思想的软件系统，往往不是一个软件产品能搞定，需要系统架构和软件整合。从纯技术角度来看，使用软件产品建立基本的架构并不难，正如一些人说的，没太多技术含量。但实际上是有“技术含量”的，而且还是很有含量，那就是分析型管理思想（与ＥＲＰ等ＯＬＴＰ系统管理思想略有不同）＋技术＋业务理解。

编程语言发展至今，特别是面向业务应用的编程语言，有着很多明显的趋势，那就是更快更稳产出应用，用更多可复用组件降低开发和维护量，更方便的程序管理、版本管理工具，方便软件在企业里的更多技术和知识沉淀。

DWBI亦是如此，众多人嚷着业务驱动，就是为了更快产出BI应用，而众多人要数据驱动，就是为了开发“可复用组件”这样的稳健数据基础架构EDW。大量企业改用工具开发ETL，就是为了更方便的元数据/版本管理，以便未来以最小代价去维护以及系统升级。从此处可以看出，业务驱动和数据驱动并不矛盾，只是两者出发点不同。

以EDW和多维模型的数据集市为比喻代表，我可以认为EDW就是我们编程里的语言代码，我们从EDW里看出数据的本质以及基础的业务思想来，而DM更像编译后的软件，最终用户可以直接使用DM的数据（或者叫信息）来从他们的角度和分析指标定义来做分析、查询等，当然普通用户是不能看原始数据的，因为“编译”过的，除非让高级用户看到“原代码”---EDW甚至ODS里的原始数据。为什么可以这样比喻呢？做过DW的人都知道，多维模型汇总后的数据，几乎不能再反转推出原始数据的，所以这和被“编译”过类似，当然程序开发还可以反编译，这个几乎不能。这也容易解释一味地建设ＤＭ，而忽略ＥＤＷ的建设，容易出现的后期开发维护量大，不方便整体性的管理这样的问题了。

多维模型里的维、度量如果是企业级的，那么可以当成另外一种ＤＷ，承担着各个ＤＭ的信息复用，如果ＤＭ有好些个，这样的架构还是很经济实惠的，但需要有高度的模型管理和业务概括能力，于是“企业级”的家伙就成为整个系统可重复使用的组件，他们面向的对象，正是需要快速产出ＢＩ的ＤＭ。

所以业务驱动也好，数据驱动也好，只要你能看出他们的本质，这些概念和理论都不是问题，就看怎么把这些管理思想和实际项目结合起来，做成更适合你的解决方案。

蓝色虫

什么时候才有第四代软件开发工具？简单的智能软件方案

hero--008

原帖由 innovate511 于 2008-10-10 23:59 发表
DWBI亦是如此，众多人嚷着业务驱动，就是为了更快产出BI应用，而众多人要数据驱动，就是为了开发“可复用组件”这样的稳健数据基础架构EDW。大量企业改用工具开发ETL，就是为了更方便的元数据/版本管理，以便未来以最小代价去维护以及系统升级。从此处可以看出，业务驱动和数据驱动并不矛盾，只是两者出发点不同。:wink:  ...

学习！

hero--008

原帖由 蓝色虫 于 2008-10-12 09:36 发表
什么时候才有第四代软件开发工具？简单的智能软件方案

老大！您也是邯郸的？
貌似 MS拟2010年推新版SQL 强化商业智能功能
http://news.csdn.net/n/20081007/119683.html