ITPub博客

下载了一份OLAP调查（the OLAP Survey 6），这是比较有名的关于BI（OLAP）工具的对比分析，从01年就开始。网站位于www.olapreport.com，这份报告页数不少，好几百页，要付费购买才能看完整版。样板倒是可以免费看，网上有下载的，我也放到这里，大家可以下载瞅瞅： http://groups.google.com/group/ttnn/web/20070215LU9UKRWL--1-OLAPSurve... 这份报告评估的产品包括MOLAP和ROLAP的种种，大致如下： MOLAP有Applix TM1， Congos Analysis，Congos Planning，Essbase，Hyperion Planning，MS Analysis Services，MIK OLAP，MIS，Oracle Ex

前段时间在ITPUB写了一篇"从非技术层面寻找BI成功的关键方法",被IT168刊登了, http://cio.it168.com/t/2007-06-06/2...1511796_3.shtml 发现被压缩了不少.把我的电子原稿放在ITPUB(实在不知道TTNN如何上传文件),愿意和大家进行讨论. 写这篇文章的原因,在于回应"业务模型和数据模型"的争论. 我认为:从技术上来讲,数据模型其实在定义上,功能描述上和性能上也不可能达到平衡,更不用说其对分析所必须的业务模型快速变化的支撑.kimball 的数据模型很多在定义上很美丽,但在实战的性能表现的很差,比如kimball经典的时间维表在

结论，要得是结论。 当看到一份洋洋数十页的ppt，堆砌大量的数字、图形，就有些头大。有没有结论性的东西？没有。即便有，也是淹没其中。按照流行的数据到信息，信息到知识，知识到决策这条路经，这种ppt就是展示信息，却没有发现知识，如果用于决策的话，还差一步，失败。 知识并不容易发现，特别是新的，大家不知道的而令人诧异的知识，经常能够提起听众的兴趣。做每次分析的时候，应该都有一些新知识被发现，哪怕这个知识是一种荒谬的，就怕没有结论。当然，如果抱着"没有功劳也有苦劳"的心态，恐怕就不会在乎是否有结论，抛

今天又看回了CRISP-DM的流程模型介绍文档。 发现非常之详细有用，模型除了大家耳熟能详的6阶段，还提出了分4层的模型，最上面是6阶段，下一层是通用任务（对6个阶段的每个进行任务分解），在下一层是具体任务（通用任务在具体的情况下应该采取什么行动）。比如通用任务是数据清洗，具体任务则有数值数据清洗，或是否判断问题类型是聚类或预测。最下一层是流程实例，即某次挖掘的行动、决定和结果记录。 CRISP-DM还提出了数据挖掘上下文的概念，对于将通用模型映射到具体模型很有用，其由下列某些或全部维度特征组成： 问题域、数据挖掘问题

天降大雨，机房进水，网络中断，好几天没有上网。 古代有个叫匡衡的人，小时候家里穷，没钱买点灯泡。但他喜欢看书，白天打工没时间，可晚上天一黑，就啥都看不见了。他挺郁闷，跟邻居商量，看能不能借个光去他家看书，邻居不愿意。没辙，于是有一天，他偷偷在墙上凿了个洞，从此，他每天晚上就可以看书了。 前几天我也向他学习一把。白天上不了网，着急啊。晚上回家，因为一直没钱办宽带，也上不了网。周末的晚上，还是打开了电脑，就算没有网络，那就听听音乐吧。咦，竟然发现弹出一个skype的自动更新对话框，这可只有连上网才会有的。一

无论是大家在讨论问题的时候, 还是所谓的争论的时候, 都在说IT人员. 但一说到IT人员, 我就想起了大公司的IT支持人员, 而一般也只叫这样的人员才叫IT人员. 一般来说, 大一点的甲方都会有自己的团队, 可能就是所谓的"IT人员". 这些人员中, 可能是专业知识一般的人, 也可能有很强的专业知识, 如果说他们只做数据库管理和开发, 我觉得说的不完整, 一般大公司里他们也会参与项目整体方面的东西, 包括业务分析, 帮助最终用户完成他们想要的分析、挖掘或者一般应用如报表查询. 所以每次说IT人员，不由得想起了支持公司内部IT的人员....

将定性的东西定量，这是现代管理的重要特性。因此，出现了很多"度"来衡量某种特质。比如信用度、忠诚度、满意度、健康度... "度"是数值，是可以比较的，数值越大就越好（或越差），这跟定性的东西相比看起来就客观一点。然而，很多"度"名不副实。比如前段时间谈的信用度问题，有朋友就质疑，你这个信用度真的就能衡量客户的信用好坏吗？仔细想想，不能。其实他只是体现信用的一方面——未来一段时间内欠费的可能性而已。因为没有谁能够给信用一个严谨客观的定义。同样，什么叫做忠诚？什么叫做满意？什么叫

最近工作比较忙，一直在TTNN潜水，看到大家在讨论业务建模和数据建模，我也一直做这个方向，很感兴趣。我把业务建模和数据建模的关系理一下，这样争论也有个基础。当然其中肯定也有不当之处，请多多指点。 先说业务建模，业务建模一般分两类。第一类是为了解决某个业务问题而建立一个业务模型或者数据模型。第二类是将企业的业务状况、业务流程及用户对业务的分析视角等信息用计算机的语言表示出来。这两类建模从方法到目的都是不同的。第一类，举例来说，对客户信用状况的评价，这需要从业务的角度来考虑反映客户信用状况的因素各占多少比

以我接触过的一点点市场营销的数据挖掘应用来说，把"模型"当黑盒子也许不算数据挖掘，但其实是有用的。做DM应用很重要的是ROI，如果真的是实干而 不是烧钱。如果一次分析的应用范围不大，仅仅是当前用一下就完事了，或者市场机会稍瞬即逝，也不必做什么深刻的挖掘。在数据集市维护一个特征库，每次建 模在重用原有数据基础上再补充一些新变量。通过数据集市的积累，快速构建分析数据集，随便建个足够有效的模型，快速部署应用，来做到减低成本。（这里 的"模型"仅指数据挖掘圈中所说的模型。）当然随着技术发展，成本

好久没有打架，想想，似乎还是03年的时候，在中关村的马兰面馆，打了一场。 手很痒，今天差点就有这样的机会，但被制止。为什么打架？竟然是因为工作，这个理由真是...搞笑。是跟同事之间的争执，因为我嫌他磨磨唧唧，因为我不是他领导，不用按下怒火。之前争执的声音已经很大，首先是从开骂开始。 我骂道，"你他妈多大了？怎么到现在还不会做人？" 他急了，"你怎么骂人，你多大了，你会做人吗？" 我继续，"骂你还不算，我还要打你呢。" 听此言，此生噌地站起身，怒眼圆睁，大力拍了一下桌子，"你来啊

周末愉快版选项当前，该论坛中首先显示的主题过多。要让该主题首先显示，请取消其他主题的这一选项。处理您的请求时出错。请重试。标准视图 树式浏览可变宽文字 固定文本 [点击信封图标接收电子邮件更新] 发邮件通知我更新信息取消电子邮件更新 [点击星标查看主题] [点击信封图标接收电子邮件更新] 标记 3 个帖子 - 全部隐藏 您要发布帖子的论坛是一个 Usenet 新闻组。在此论坛发帖会使您的电子邮件地址有机会给互联网上的所有人看到。您的回复帖子尚未发送。发帖成功 ding xining 查看个人资料 更多选项 6月30日, 上午9时28分发件人：&qu

每次回北京，除了跟哥几个喝酒，就是扯淡，有些就是纯属瞎扯，有些则是正儿八经地扯BI淡。 beter是隆博时代的老板，他们作政府行业的BI应用，主要搞MSTR产品，跟FirstBI很有关系。他喜欢喝咖啡，在他的办公室里面，就摆了个咖啡机。我跟他第一次见面的时候就是在当代商城的星巴克，去的多的是学院桥北边一个叫金码大厦下面的星巴克。上上周，离开北京之前，我们就在那里聊了一下午。 扯了一些正儿八经的淡。"有个现象，不是好事。"他说，"怎么搞BI的人都喜欢自由一点，或者就是喜欢搞自己那一块儿呢？这对BI的发展可不是什

我先在基本上是采用kimball的方法进行数据仓库的建模，其中有这么一个问题： 我的一个"人员维度"--记录了类似CRM系统的客户的各类信息--这个维度表的记录将达到近亿条，业务中，每一个人员都是有单位归属的，单位也有相应 的一些分析需要的属性，而且单位的数量也应该是百万级别的，从单位角度分析人员这个主体也是分析的要求之一，现在的问题是，是按照退化维度表的方式处理 成一个维度表呢，还是按照雪花型的方式处理好呢？ 另外，还有一个地域维度的处理问题，单位是有地域归属的，人员也是有地域归属的，每个人的服务机构也

什么是模型？什么是分析模型？现在问这个问题似乎有点不合时宜，但总觉得这个词在平日里出现的频次太多，而其实大家并没什么共识在上面，只是当作一个名词而已。动辄建一个模型搞定，似乎它是万能的。下面，没有特别说明，模型都是指分析模型。 昨天，要写一份报告，相当于项目的总结，照例是要描述一番"模型"的，这个工作越来越让人头疼，因为不知道究竟什么是"模型"。逐渐地，我想着不应该总是用什么挖掘模型来解决问题，很多场合，只需要我们看看数据统计，稍微动动脑子就可以作决策了。但这样便体现不出工作量，数

一些事没人做一些人没事做没事的人盯著做事的人,议论做事的人做的事使做事的人做不成事做不好事于是,老板夸奖没事的人因为他看到事做不成于是,老板训诫做事的人因为他做不成事一些没事的人总是没事做一些做事的人总有做不完的事一些没事的人滋事闹事使做事的人不得不做更多的事结果好事变坏事,小事变大事,简单的事变复杂的事[@more@]

有一天，阿Q带着老婆逛街，老婆快生了，肚子不小。走到一个小胡同，胡同口摆了个摊子，里面端坐一位先生。满头银发，长须飘飘，仙风道骨。可惜，是个瞎子，带着墨镜。但面前摆着台笔记本，着实让人好奇。 阿Q再细细一打量，摊子两侧各有一联，上书：麻衣神相，通晓天文地理必爱模型，预测过去未来 哦，原来是同道中人，是个搞BI的。便坐下来，问道 "先生，给我预一测。" "你预什么？" "预测一下老婆生男生女。" "OK，让我算算。" 然后，老先生在电脑上捣鼓一通，阿Q很好奇，探头看看，原来老先生

一条直线，你能看出什么？从简单的表象，能够看到背后的本质，这是功夫。BI，花了很大精力在于如何将事物忠实地表现出来。做数据整合，做报表，做OLAP，做挖掘。首先保证原材料的真实，然后再从各个角度来观察表象。至于你能从这些表象分析出来什么东西，恐怕很难让BI告诉你，这是读者的功夫。 往往，换个角度就够了。不是所有的人都能如李寻欢那样，从郭嵩阳的尸体看出荆无命的剑招。也不像黑客帝国里面那些端坐在屏幕面前，看着绿色字符直往下落，就知道发生什么事情。 所以我想BI真正要用好是否应当将它当作是一种启发式工具呢？而并非

站在别人的立场看问题，说起来简单，但做起来，确实需要修炼。我基本上是个喜欢内省的人，本来不擅长这种技巧，但如今被逼得不得不如此。比如写文章，当写一篇blog的时候，很轻松，想到哪儿写到哪儿。但如果是要写一份报告，是要给别人看的，甚至是要说服一类人的，总是痛苦的很。不光是写文章，其他很多事情都是如此。BI人所在的应当也算是一种服务行业，得有服务意识，得站在客户角度，看你给我的东西是不是帮到我。一张报表，一目了然看到全部经营状况。一个前端界面，就像熟知使用者的习惯一样，操作简洁明了。反之，如果你就站在自己

从分析结论说到决策，是一种进步。拿编写分析报告来说，早先时候，ppt里面充斥着图表，似乎是多多益善，但对于每张图包含什么结论，或者最终有个什么结论，没有描述。因此，有段时间，我特别注意要"分析结论"。但在这点已经做到之后，发现有新的问题，这些图表显示的结论究竟如何辅助决策呢？确实给出了结论，但就这样抛给决策者，似乎有点信不信由你的味道。于是，我想，在分析结论之后，得讲如何决策了。 BI的最终目的就是辅助决策，但能不能有科学的决策并非是BI所决定的，他终究是一种辅助手段。 有个传统的例子，阿P和阿Q到

推荐一篇文章，关于电信行业经营分析系统应用的一些现状，作者不知姓甚名谁，很想结识一下。 该文有些段落较长，概括一下，主要论述了经分系统的三种病症： 1、没有重点，太多信息扑面而来； 2、缺乏集成，是个半成品； 3、只是暴露问题，没有给予解决解决问题建议。 稍后评论，先看全文。 __________________________________________________________ 当前国内电信企业经营分析中的困惑 虽然国内运营商已初步建立了企业经营分析系统和分析体系，取得了一定的管理和决策改善的效果。但从目前的实践情况看，经营分析中仍存在一些突出问题，