文章 - 24 评论 - 2 收藏 - 0 粉丝 - 0 访问量 - 38453
所有

对于ETL而言,”是什么”是很容易理解的,也就是将分散的、不易利用的数据进行整理,变成规则清晰的、易于利用的、(可能同时还是)集中的数据。在ETL过程之外,就可以基于报表分析系统、多维分析系统和数据挖掘系统等,进行进一步的数据分析利用。 这一过程可以通过Hard Codding,即编写程序实现,也可以通过各种ETL工具实现。 对于ETL,实际常见的问题有两个: 1、为什么要做ETL,而不是直接利用数据?

posted @ 2007-12-28 14:32 Wishing | 阅读(1414) | 收藏(0) | 评论 (0) ||收藏

OLAP报表产品最大的难点在哪里? 目前报表工具最大的难点不在于报表的样式(如斜线等),样式虽较繁琐但并非本质困难。最根本的难点在于业务部门知道报表代表的真正含义,却不知道报表的数据统计模型模型;而IT部门通过理解业务部门的描述,在数据库端进行设置数据统计模型,却对报表本身所代表的价值很难理解。 这样的现状,导致报表工具无法两者兼顾,OLAP报表工具产品一直在数据模型设计层面(OLAP层面)和报表本身功能层面做出平衡。

posted @ 2007-12-25 10:39 Wishing | 阅读(2108) | 收藏(0) | 评论 (0) ||收藏

报表绘制的方法,是非常影响工作效率的,特别是对于格线比较多的表。  传统的报表绘制,大多数是用的拖拽式,拿部件拖来拽去。后来可能是发现了其中的不便,所以出现了类EXCEL的绘制方法。  其实,这两者根本不具可比性,类EXCEL的方法明显优于拖拽式,或者说,画报表就应该是用象Excel那样的方法。  道理非常简单,你见过有人用Powerpoint画表吗?会累死的。大概稍有点常识的人,都会拿Excel画表吧。  所以,类Excel是必然的方向。

posted @ 2007-12-25 10:38 Wishing | 阅读(1302) | 收藏(0) | 评论 (0) ||收藏

报表绘制的方法,是非常影响工作效率的,特别是对于格线比较多的表。  传统的报表绘制,大多数是用的拖拽式,拿部件拖来拽去。后来可能是发现了其中的不便,所以出现了类EXCEL的绘制方法。  其实,这两者根本不具可比性,类EXCEL的方法明显优于拖拽式,或者说,画报表就应该是用象Excel那样的方法。  道理非常简单,你见过有人用Powerpoint画表吗?会累死的。大概稍有点常识的人,都会拿Excel画表吧。  所以,类Excel是必然的方向。

posted @ 2007-12-21 15:51 Wishing | 阅读(1142) | 收藏(0) | 评论 (0) ||收藏

当然,宏在带来方便的同时,也有其缺点,写进了宏的表达式在报表设计期间无法进行语法检查,只能在解析后才能查出错误,使用时必须很小心;另外,宏的解析很复杂,会影响表达式的处理速度(C编译器有相当多时间用于解析宏,PASCAL没这问题速度能快很多),对于表达式很多且性能要求很高的情况尽量不要采用宏。曾经有个相关的案例。用户有一张报表希望以某个字段排序输出,需要有正序和逆序两种形式。出于某些设计方面的原因,必须采用数据库的排序运算,即用SQL的ORDER BY子句控制,但该排序字段又不是数值型量,只能用ASC和DESC控制,但排序方向在水晶报表中不可作为参数传递,结果只能制作两张报表(如果是数值型量可通过乘1或-1控制,不必改变排序方向,即可用参数传递了),维护其一致性非常麻烦;而采用华天企业报表系统特有的宏,只要把排序方向作为宏传入就可以轻松解决。

posted @ 2007-12-21 15:27 Wishing | 阅读(1057) | 收藏(0) | 评论 (0) ||收藏

这张表在篮板的统计那里,分成了两层,因此,需要能够生成这种复杂的表头。(实际上这个表头还不算是复杂的,更复杂的情况是需要进行横向的数据展开,在后面的文章中将会提到) 同时,篮板球的总数,是进攻篮板和防守篮板的合计,这就需要能够在报表内自动进行合计。(这种横向的运算,是最简单的运算,复杂的运算,在后面的文章中也会提到)

posted @ 2007-12-18 12:36 Wishing | 阅读(1301) | 收藏(0) | 评论 (0) ||收藏

 技术的先进性,比如: 强有力的权限控制机制 先进的报表设计模型 可靠地处理大附件的能力   进一步的,有一些专业的知识管理系统还提供了对知识的利用率、贡献率、生命周期等的管理,使得知识管理到了更深的层次。

posted @ 2007-12-18 12:34 Wishing | 阅读(1901) | 收藏(0) | 评论 (0) ||收藏

打印地址标签,是一个并不复杂的功能,但是非常实用。 简单讲,就是将一大堆地址,打印成发信用的地址标签(实际一般是打印在不干胶纸上,不过这事就和报表没关系了)。往往是一张纸上,要打印mxn个标签:

posted @ 2007-12-13 11:21 Wishing | 阅读(1157) | 收藏(0) | 评论 (0) ||收藏

不好意思,刚才跑题了,还说女同胞的通话行为特点分析,为什么我们不能分析出女同胞的通话特点呢?如果放到营帐系统里去,要看看男同胞和女同胞通话行为差异,就比如联系人个数、电话频率、平均单次时长,还有短信/通话次数比例吧,就要把用户资料和详单、帐单关联起来进行查询,顺便做一些汇总计算,这个查询说起来容易,可实际做起来,可要些上一大段SQL,扔到营帐库里面去跑上一天半日,没准还要十天半月,如果运气不好还能把营帐搞趴下。看来一个简单的市场分析需求都这么困难,所以说来说去,我们还是需要建立经营分析系统,有了经营分析系统,这些复杂的关联计算在后台就已经做完了,也不用写SQL了,直接拿工具拖拖拉拉就搞出来,也不用等那么久了,一个查询分析分秒之间就搞定了,还能够自由自在地改变条件,舒舒服服地研究数据,真是我们IT部门和市场部门的好帮手啊。

posted @ 2007-12-13 11:19 Wishing | 阅读(1232) | 收藏(0) | 评论 (0) ||收藏

类似的情况非常普遍,比如许多业务单据都是这样,如销售订单、采购单、出差报销单等。 主从报表还可能是包括多个从表(明细表),比如,再增加一个”教育经历”之类的。

posted @ 2007-12-10 10:17 Wishing | 阅读(1295) | 收藏(0) | 评论 (0) ||收藏

Full 所有 Archive