神马文学网我们需要什么怎样的OLAP（转摘并修改）
来源：百度文库 编辑：神马文学网 时间：2024/04/29 02:03:41
商业智能一般分成为报表、分析、挖掘三个阶段，而OLAP方法是当前在线分析的主要手段。
其实OLAP这个词本身就是在线分析的意思，但现在已经被狭义化了，说到OLAP，只是指钻取、聚合、旋转等操作。
然而，这种OLAP并不能提供我们需要的在线分析功能。它只能针对某个单一主题作分析，无法对全业务数据进行多主题混合分析。国内行业业务变化迅速，基本上没可能事先把所有的分析需求整理清楚，而由业务人员（最需要做分析的人）通过设计工具、编写SQL来定义、设计报表分析模板，是非常不现实的。所以这样的OLAP即使建立起来，实际上跟没有差不多。笔者认为，这是国内大多数OLAP项目失败的主因之一。
那么我们现在需要的OLAP应当是什么样的？
我们来分析一下在线分析的应用过程。任何一个经营性行业中有多年工作经验的从业人员一般都会对自己从事的业务产生一些猜测，如股票分析师会猜测满足某种条件的股票容易上涨，航空公司的业务人员会猜测何种人群习惯于购买哪类航班，超市经营者也会猜测何种价位的商品更适应周边的人群，…。这些猜测正是预测的基础。而一个机构建设好的业务系统运行一段时间后也都会积累大批的数据，业务人员的猜测很可能已可由这些积累的数据去验证，证实了则可以用于预测，证伪则再重新猜测。
需要注意的是，这些猜测都是由有经验的业务人员做出的，而不是计算机系统做出的！需要计算机系统做的就是辅助业务人员针对已有数据去证实或证伪猜测，也就是查询数据（包括一定的汇总运算），这就是在线分析的应用过程。之所以需要在线，是由于许多猜测都是业务人员看到了某个中间结果后临时想出来的。整个过程中不可能也不需要事先建模，而由于其临时性，业务人员在验证猜测时也无法依赖技术人员的配合。
再据个政府机关的例子。机关信息部门经常要面对领导的突发性报表要求，比如一个税务领导要出席政府召开的有关福利企业工作会议，很可能突然要相关部门立即准备好本地区福利企业最近5年的税收入库情况表。如果这样的表要临时定义、测试、输出，可能需要业务部门和信息部门反复沟通多次，然后信息部门生成报表，业务部门最终审核才可送交领导。要是软件能提供简易的操作界面，让业务人员也能自己查询分析生成所需的报表该多好呢？
从技术上讲，我们需要的在线分析其实是一个针对业务数据库的多表即时查询系统，绝大多数有意义的业务查询都不是单表能够解决的（如查出曾在某机构工作过三年以上的员工、超市下午五点时断档的商品、一段时期内有连续N天涨停记录的股票等），而当前的OLAP方法是个单表工具，解决不了我们的问题。
对于技术人员而言，多表查询本身并不太困难，使用SQL或编写程序都可以完成，虽不很轻松但也可以应付。然而，对于更需要这个功能的业务人员就不那么简单了，一个两层嵌套的三表叉乘SQL或一段10行以上带有条件跳转的代码都是他们不可能完成的事情。
这才是我们需要的在线分析：让不懂技术的业务人员能够用某种手段自由地完成自己临时想做的各种查询，特别是多表查询。
能达到这样的应用目标的软件并不多见，我个人认为这里面有2个关键点：
1）根据业务需求合理规划OLAP主题模型。一般数据模型采用星形或雪花，其实更重要的是业务模型，也就是一个主题表中放哪些指标，多个主题表间如何自动关联。
2）友好、灵活的前端展示工具。展示工具应有非常友好的操作界面，方便业务人员使用。一般最好采用向导式界面，允许用户拖拉或拾取指标（多表操作同样要简单），系统能根据用户的界面操作，自动生成复杂的SQL语句，完成查询和报表。
其实OLAP这个词本身就是在线分析的意思，但现在已经被狭义化了，说到OLAP，只是指钻取、聚合、旋转等操作。
然而，这种OLAP并不能提供我们需要的在线分析功能。它只能针对某个单一主题作分析，无法对全业务数据进行多主题混合分析。国内行业业务变化迅速，基本上没可能事先把所有的分析需求整理清楚，而由业务人员（最需要做分析的人）通过设计工具、编写SQL来定义、设计报表分析模板，是非常不现实的。所以这样的OLAP即使建立起来，实际上跟没有差不多。笔者认为，这是国内大多数OLAP项目失败的主因之一。
那么我们现在需要的OLAP应当是什么样的？
我们来分析一下在线分析的应用过程。任何一个经营性行业中有多年工作经验的从业人员一般都会对自己从事的业务产生一些猜测，如股票分析师会猜测满足某种条件的股票容易上涨，航空公司的业务人员会猜测何种人群习惯于购买哪类航班，超市经营者也会猜测何种价位的商品更适应周边的人群，…。这些猜测正是预测的基础。而一个机构建设好的业务系统运行一段时间后也都会积累大批的数据，业务人员的猜测很可能已可由这些积累的数据去验证，证实了则可以用于预测，证伪则再重新猜测。
需要注意的是，这些猜测都是由有经验的业务人员做出的，而不是计算机系统做出的！需要计算机系统做的就是辅助业务人员针对已有数据去证实或证伪猜测，也就是查询数据（包括一定的汇总运算），这就是在线分析的应用过程。之所以需要在线，是由于许多猜测都是业务人员看到了某个中间结果后临时想出来的。整个过程中不可能也不需要事先建模，而由于其临时性，业务人员在验证猜测时也无法依赖技术人员的配合。
再据个政府机关的例子。机关信息部门经常要面对领导的突发性报表要求，比如一个税务领导要出席政府召开的有关福利企业工作会议，很可能突然要相关部门立即准备好本地区福利企业最近5年的税收入库情况表。如果这样的表要临时定义、测试、输出，可能需要业务部门和信息部门反复沟通多次，然后信息部门生成报表，业务部门最终审核才可送交领导。要是软件能提供简易的操作界面，让业务人员也能自己查询分析生成所需的报表该多好呢？
从技术上讲，我们需要的在线分析其实是一个针对业务数据库的多表即时查询系统，绝大多数有意义的业务查询都不是单表能够解决的（如查出曾在某机构工作过三年以上的员工、超市下午五点时断档的商品、一段时期内有连续N天涨停记录的股票等），而当前的OLAP方法是个单表工具，解决不了我们的问题。
对于技术人员而言，多表查询本身并不太困难，使用SQL或编写程序都可以完成，虽不很轻松但也可以应付。然而，对于更需要这个功能的业务人员就不那么简单了，一个两层嵌套的三表叉乘SQL或一段10行以上带有条件跳转的代码都是他们不可能完成的事情。
这才是我们需要的在线分析：让不懂技术的业务人员能够用某种手段自由地完成自己临时想做的各种查询，特别是多表查询。
能达到这样的应用目标的软件并不多见，我个人认为这里面有2个关键点：
1）根据业务需求合理规划OLAP主题模型。一般数据模型采用星形或雪花，其实更重要的是业务模型，也就是一个主题表中放哪些指标，多个主题表间如何自动关联。
2）友好、灵活的前端展示工具。展示工具应有非常友好的操作界面，方便业务人员使用。一般最好采用向导式界面，允许用户拖拉或拾取指标（多表操作同样要简单），系统能根据用户的界面操作，自动生成复杂的SQL语句，完成查询和报表。
我们需要什么怎样的OLAP（转摘并修改） - 风雨BI的专栏 - CSDNBlog
我们需要什么怎样的OLAP（转摘并修改）
我们需要怎样的“强国”
我们需要怎样的教育
我们需要怎样的教育 [
我们需要怎样的教育
我们需要怎样的国学
我们需要怎样的云？
肖雪慧：我们需要怎样的精英
肖雪慧：我们需要怎样的精英
我们需要怎样的国家话语？
我们需要怎样的国家话语？11
高全喜：我们需要怎样的政治经济学？
我们到底需要怎样的班规
我们到底需要一个怎样的楼市
[转载]我们需要怎样的学校
我们需要怎样的财富境界？
今天，我们需要怎样的启蒙?
今天，我们需要怎样的启蒙?
OLAP
我们究竟需要什么样子的精英
我们需要牛奶里的什么营养
评恒（抱朴子）的《忆秦娥.夜祭母坟》并修改
我们需要独尊什么