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

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

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

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

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

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

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

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

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

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

一般地，Web报表在一个软件开发项目中占的比例大概是 10% 左右，这两年有上升的趋势，据我现在项目中报表的开发量大的能占到20%。下面的计算还是以10%为标准，每人月的成本按2.5万计算。 以一个100万的软件开发项目为例，Web报表的工作量占 10% ，即开发成本为 10 万元。以 2.5 万 / 人月来计算，这个项目需要用 4 个人月来完成报表工作。在实际的项目中，这 10 万元有几种方式分摊：

利用计算机技术对电厂的信息进行管理出现在20世纪60年代末，到了80年代，一些软件公司开发出基于主机和字符终端的电厂管理信息系统，由于当时计算机设备昂贵，系统运行效率低，加上字符终端所显示的内容受到限制，因而没有形成规模。进入90年代，以图形为界面、网络和数据库为支撑的电厂管理信息系统逐步在电厂中推广应用，计算机技术也在电厂控制系统中得到广泛应用，过去电厂控制系统分散孤立的局面逐渐被全厂统一的计算机网络所取代，与MIS在计算机平台上实现了对接，形成了由底层实时信息和操作记录、管理层业务信息、决策层支持信息等组成的一套完整的电厂信息技术（IT）解决方案。

图表英文是CHART。 图表的差异，一方面在于是否能实现各种不同样式的图，另一方面在于展现的时候是什么样子。比较好的是在HTML里直接展现，而比较差的就还要通过一个控件。

目前，商业智能通常被理解为将企业中现有的数据转化为知识，帮助企业做出明智的业务经营决策的工具。这里所谈的数据包括来自企业业务系统的订单、库存、交易账目、客户和供给商资料来自企业所处行业和竞争对手的数据以及来自企业所处的其他外部环境中的各种数据。而商业智能能够辅助的业务经营决策，既可以是操作层的，也可以是战术层和战略层的决策。为了将数据转化为知识，需要利用数据仓库、联机分析处理（OLAP）工具和数据挖掘等技术。因此，从技术层面上讲，商业智能不是什么新技术，它只是数据仓库、OLAP和数据挖掘等技术的综合运用。

交叉表的特点是： 数据在横、纵两个方向扩展，即行、列均不固定 左边、上边都有一个表头，而中间是明细区。后面往往还有合计之类的。