对业务的理解体现在BI工具的使用还是在后台建模?

innovate 20061106

上次提到的关于一个同事说以前他所在前公司和其他公司合作一个项目,
面对客户越来越复杂的报表需求, 后台模型支持不足,
只能仰仗BI工具的所有功能去实现,
然而很多情况下还是不能实现.

象这种后台和前端BI由两公司合作的情况越来越多,
客户提出的合理BI需求可能会导致做后台的公司把更多实现业务逻辑的技术责任全推到前端去.
于是我在想, 这样做后台, 他们到底对业务理解了多少,
到底对DW与BI的关系理解了多少?
如果我在当时那种情况,
可能我会跟客户豪不客气地指出那是后台问题,
不能都依赖于BI, 如果合作公司不知道如何建模,
我可以提些建议或者自己加一层模型作为展现使用.

如果说所谓的架构太空虚, 挖掘算法应用实在拿不准,
但我想比较成熟的模型设计还是有足够空间给各个公司和DWer去研究和探讨的吧.
不过还有一点, 很多公司其实有高手, 但在具体操作上,
在一些普通项目上, 可能会启用相对新的人去做,
而在公司技术积累上, 新人也没去继承,
我想这属于管理层次的问题了.

li-zhenguo 20061106

就像移动会找多个公司帮他架网铺线设基站一样，其他较大型公司也不会把自己的bi项目放在一个篮子里。在这种情况下，如果甲方能有较强的技术实力，能把两个乙方共同协作的项目管理起来，楼主说的这种问题应该就不会出现。如果甲方不能控制项目，那么这种问题就要由两个乙方来协商解决。

很多bi工具是有局限性的，像我们使用的cognos reportnet来说，能在工具里做表连接（对外连接支持有限），汇总分组也能做，但不支持在工具中嵌套子查询，也不支持在工具中画数据分析线（比如最小二乘法拟合）。所以这些工作必须后台去做。

我觉得一个项目要做得好，前端和后端要相互配合，互相推诿只能导致项目失败，或者造成日后维护的困难，最后只能影响公司的声誉。

innovate 20061106

我觉得DW&BI界应该制定出一套标准来,
比如后台模型设计到什么程度,
前端工具应该负责到什么程度. 现在都不清楚,
当然谁也没有标准去判断了.
我现在接触的客户，据说客户中高层领导就说Cognos
ReportNet这能做, 那也能做, 如果真是这样,
那倒真的可以把DW的建设费给省了,
问题是这个BI工具有那么厉害么?
不知道客户是被售前洗脑了, 还是他们自己搞过.
不过ReportNet不通过DW取数, 而直接取自业务系统的时候,
一个复杂点的报表需要运行半小时, 甚至1-多个小时,
真是有意思. 不过既然客户自己找咨询公司规划的,
以后才上DW, 所有条件都限制死了, 那也没办法,
能达到什么程度, 就只能达到什么程度了.
不过怀疑这家客户可能也会把未来的DW/BI项目分为两家或者多家公司去合作,
现在的咨询公司和BI厂商还真能忽悠.

li-zhenguo 20061107

我觉得单纯使用BI工具，而不在数据库中做必要的视图和汇总表，会显得比较困难和影响执行效率。拿reportnet来说吧，它提供一个界面模型让你拖拖拉拉生成元数据，但这个界面模型只支持明细层和汇总层，只允许在明细层做表连接，所以要实现复杂的嵌套子查询就只能在数据库中用视图实现了。然后它用你拖拖拉拉所得的元数据先生成cognos版的通用sql查询语句，然后根据连接数据库的类型再生成具体的sql语句，在这个过程中，无法设定hint（oracle的优化提示）去优化，也产生了一些比较笨的情况，具体见我的博客：
http://blog.tom.com/blog/read.php?bloggerid=828628&blogid=48562

从我的经验上来看，reportnet基于数据集市会比较好做些，如果用3nf的数据仓库做数据源，可能还需要另建视图或汇总表。

从什么都不能做到什么都能做，是一个对工具掌握的过程。从什么都能做到什么都不能做，是一个对工具进一步了解的过程。再从什么都不能做到知道什么能做什么不能做，是一个对工具精通的过程。客户可能处于第二个过程，体会到了reportnet的好处，但没有理解它的实现模型，不知道它的局限性。最好能结合工具的特点，引导客户的需求，若要说一个工具能实现所有的功能，那是不可能的。

smileagain 20061107

> 从什么都不能做到什么都能做，是一个对工具掌握的过程。从什么都能做到什么都不能做，是一个对工具进一步了解的过程。再从什么都不能做到知道什么能做什么不能做，是一个对工具精通的过程。客户可能处于第二个过程，体会到了reportnet的好处，但没有理解它的实现模型，不知道它的局限性。最好能结合工具的特点，引导客户的需求，若要说一个工具能实现所有的功能，那是不可能的。

这句话太牛了。工具的售前都忽悠客户，只要用工具，啥都能实现，啥都能做。有一次客户问工具的售前：资产负债表怎么做啊。人家就真拿个做好的资产负债表给客户看。仔细问了问后台结构，哈哈，原来后台就是设计了一个跟前端展现一模一样的数据库表。那当然是能做出来了。可是，这样的后台设计，完全不可用。

innovate511 20061107

这就是某些客户"牛"的地方了,
人家的规划是来自美国总部的,
而美国又没有那么多中国式报表,
所以客户高层(美国方)认为仅仅用ReportNet去ERP业务系统取数据就行了，暂时用不上数据仓库,
数据仓库是为将来全面上BI准备的.
当然报表的复杂性而导致少数报表不能做,
以及部分报表需要N分钟甚至小时计算, 他们是不管的.

你说给客户引导, 客户说你给美国总部的人说去,
你有人家权威? 你说建设数据仓库的好处,
人家说正在规划中, 但现在把报表做好先.
而且在这种国际公司中做项目，别说你建议别人做什么，就连建任何一个表的权限都没有，只能建视图

以前没用过ReportNet, 但从它架构一下就看出,
它最适合建立在成型的数据集市之上,
它的界面模型才能体现出优势,
否则模型可能在复杂报表面前反而成了累赘,
如果靠视图(不允许建中间表),
那么报表逻辑已经全面体现在视图中了, 视图搞定,
报表基本就算搞定了,
其实并没有体现出ReportNet多么高明, 反而更让人觉得,
任何高明的报表工具,
必须要数据集市才能满足客户更多复杂高效的报表需求.
而且建视图是不能替代数据集市的，因为数据集市里的事实表、维表、综合表和汇总表，是针对全部部门业务的，结构复杂多了，而视图仅仅局限在一个报表，字段和逻辑都定死了，基本没有什么可扩展性和重用性，所以我们跟客户多次强调，需求确定后就不能变了，因为要变需要很长的流程修改，是不太现实的，要想灵活地修改和增加需求，请等到上数据仓库吧。

上面有朋友提到3NF数据仓库,
我想从做报表等BI应用的话,
基本上公认的还是建立在数据集市上为好吧,
只能说支持3NF数据仓库建模的人建议客户可以用3NF成熟模型的数据仓库进行快速、更灵活的即席查询，
没听说建议客户把报表建在数据仓库上，毕竟报表基本都是有复杂业务逻辑运算过程的数据列或者汇总结果。