http://blog.csdn.net/viving/报表zh-CNFri, 28 Dec 2007 14:19:02 GMT60vivinghttp://blog.csdn.net/viving/archive/2007/12/28/1999936.aspxFri, 28 Dec 2007 14:19:00 GMThttp://blog.csdn.net/viving/archive/2007/12/28/1999936.aspxhttp://blog.csdn.net/viving/comments/1999936.aspxhttp://blog.csdn.net/viving/archive/2007/12/28/1999936.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1999936.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1999936对于ETL而言，”是什么”是很容易理解的，也就是将分散的、不易利用的数据进行整理，变成规则清晰的、易于利用的、（可能同时还是）集中的数据。在ETL过程之外，就可以基于报表分析系统、多维分析系统和数据挖掘系统等，进行进一步的数据分析利用。 这一过程可以通过Hard Codding，即编写程序实现，也可以通过各种ETL工具实现。 对于ETL，实际常见的问题有两个： <img src ="http://blog.csdn.net/viving/aggbug/1999936.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/25/1965946.aspxTue, 25 Dec 2007 10:28:00 GMThttp://blog.csdn.net/viving/archive/2007/12/25/1965946.aspxhttp://blog.csdn.net/viving/comments/1965946.aspxhttp://blog.csdn.net/viving/archive/2007/12/25/1965946.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1965946.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1965946企业为了确定经营战略和市场战略所进行的经营活动，在BI项目的分析决策过程中，需要基于多种报告和报表进行分析。理想的市场活动展开，大多需要各个营业点的销售报表，每种商品按季节销售的业绩图表等，这就需要大量准确的并且易于判断的数据。<img src ="http://blog.csdn.net/viving/aggbug/1965946.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/25/1965945.aspxTue, 25 Dec 2007 10:27:00 GMThttp://blog.csdn.net/viving/archive/2007/12/25/1965945.aspxhttp://blog.csdn.net/viving/comments/1965945.aspxhttp://blog.csdn.net/viving/archive/2007/12/25/1965945.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1965945.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1965945报表绘制的方法，是非常影响工作效率的，特别是对于格线比较多的表。 　传统的报表绘制，大多数是用的拖拽式，拿部件拖来拽去。后来可能是发现了其中的不便，所以出现了类EXCEL的绘制方法。 　其实，这两者根本不具可比性，类EXCEL的方法明显优于拖拽式，或者说，画报表就应该是用象Excel那样的方法。 　道理非常简单，你见过有人用Powerpoint画表吗？会累死的。大概稍有点常识的人，都会拿Excel画表吧。 　所以，类Excel是必然的方向。 <img src ="http://blog.csdn.net/viving/aggbug/1965945.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/21/1957554.aspxFri, 21 Dec 2007 15:44:00 GMThttp://blog.csdn.net/viving/archive/2007/12/21/1957554.aspxhttp://blog.csdn.net/viving/comments/1957554.aspxhttp://blog.csdn.net/viving/archive/2007/12/21/1957554.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1957554.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1957554报表绘制的方法，是非常影响工作效率的，特别是对于格线比较多的表。 　传统的报表绘制，大多数是用的拖拽式，拿部件拖来拽去。后来可能是发现了其中的不便，所以出现了类EXCEL的绘制方法。 　其实，这两者根本不具可比性，类EXCEL的方法明显优于拖拽式，或者说，画报表就应该是用象Excel那样的方法。 　道理非常简单，你见过有人用Powerpoint画表吗？会累死的。大概稍有点常识的人，都会拿Excel画表吧。 　所以，类Excel是必然的方向。 <img src ="http://blog.csdn.net/viving/aggbug/1957554.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/21/1957504.aspxFri, 21 Dec 2007 15:18:00 GMThttp://blog.csdn.net/viving/archive/2007/12/21/1957504.aspxhttp://blog.csdn.net/viving/comments/1957504.aspxhttp://blog.csdn.net/viving/archive/2007/12/21/1957504.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1957504.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1957504当然，宏在带来方便的同时，也有其缺点，写进了宏的表达式在报表设计期间无法进行语法检查，只能在解析后才能查出错误，使用时必须很小心；另外，宏的解析很复杂，会影响表达式的处理速度（C编译器有相当多时间用于解析宏，PASCAL没这问题速度能快很多），对于表达式很多且性能要求很高的情况尽量不要采用宏。曾经有个相关的案例。用户有一张报表希望以某个字段排序输出，需要有正序和逆序两种形式。出于某些设计方面的原因，必须采用数据库的排序运算，即用SQL的ORDER BY子句控制，但该排序字段又不是数值型量，只能用ASC和DESC控制，但排序方向在水晶报表中不可作为参数传递，结果只能制作两张报表（如果是数值型量可通过乘1或-1控制，不必改变排序方向，即可用参数传递了），维护其一致性非常麻烦；而采用华天企业报表系统特有的宏，只要把排序方向作为宏传入就可以轻松解决。<img src ="http://blog.csdn.net/viving/aggbug/1957504.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/18/1946674.aspxTue, 18 Dec 2007 12:19:00 GMThttp://blog.csdn.net/viving/archive/2007/12/18/1946674.aspxhttp://blog.csdn.net/viving/comments/1946674.aspxhttp://blog.csdn.net/viving/archive/2007/12/18/1946674.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1946674.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1946674这张表在篮板的统计那里，分成了两层，因此，需要能够生成这种复杂的表头。（实际上这个表头还不算是复杂的，更复杂的情况是需要进行横向的数据展开，在后面的文章中将会提到） 同时，篮板球的总数，是进攻篮板和防守篮板的合计，这就需要能够在报表内自动进行合计。（这种横向的运算，是最简单的运算，复杂的运算，在后面的文章中也会提到） <img src ="http://blog.csdn.net/viving/aggbug/1946674.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/13/1932708.aspxThu, 13 Dec 2007 11:05:00 GMThttp://blog.csdn.net/viving/archive/2007/12/13/1932708.aspxhttp://blog.csdn.net/viving/comments/1932708.aspxhttp://blog.csdn.net/viving/archive/2007/12/13/1932708.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1932708.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1932708打印地址标签，是一个并不复杂的功能，但是非常实用。 简单讲，就是将一大堆地址，打印成发信用的地址标签（实际一般是打印在不干胶纸上，不过这事就和报表没关系了）。往往是一张纸上，要打印mxn个标签<img src ="http://blog.csdn.net/viving/aggbug/1932708.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/13/1932704.aspxThu, 13 Dec 2007 11:04:00 GMThttp://blog.csdn.net/viving/archive/2007/12/13/1932704.aspxhttp://blog.csdn.net/viving/comments/1932704.aspxhttp://blog.csdn.net/viving/archive/2007/12/13/1932704.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1932704.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1932704说来说去，还是说到经营分析系统来了，刚才只是借这么个引子说经营分析系统到底有啥用处，不过我也真心希望我们东方移动的经营分析系统上马之后，我们市场部门能够分析一下女同胞的消费特点，明年3.8节的时候推出女士专署套餐，给我们的女同胞送上实实在在的节日贺礼！<img src ="http://blog.csdn.net/viving/aggbug/1932704.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/10/1926519.aspxMon, 10 Dec 2007 10:01:00 GMThttp://blog.csdn.net/viving/archive/2007/12/10/1926519.aspxhttp://blog.csdn.net/viving/comments/1926519.aspxhttp://blog.csdn.net/viving/archive/2007/12/10/1926519.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1926519.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1926519类似的情况非常普遍，比如许多业务单据都是这样，如销售订单、采购单、出差报销单等。 主从报表还可能是包括多个从表（明细表），比如，再增加一个”教育经历”之类的。 <img src ="http://blog.csdn.net/viving/aggbug/1926519.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/10/1926512.aspxMon, 10 Dec 2007 09:59:00 GMThttp://blog.csdn.net/viving/archive/2007/12/10/1926512.aspxhttp://blog.csdn.net/viving/comments/1926512.aspxhttp://blog.csdn.net/viving/archive/2007/12/10/1926512.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1926512.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1926512以一个100万的软件开发项目为例，Web报表的工作量占 10% ，即开发成本为 10 万元。以 2.5 万 / 人月来计算，这个项目需要用 4 个人月来完成报表工作。在实际的项目中，这 10 万元有几种方式分摊：<img src ="http://blog.csdn.net/viving/aggbug/1926512.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/07/1922046.aspxFri, 07 Dec 2007 10:43:00 GMThttp://blog.csdn.net/viving/archive/2007/12/07/1922046.aspxhttp://blog.csdn.net/viving/comments/1922046.aspxhttp://blog.csdn.net/viving/archive/2007/12/07/1922046.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1922046.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1922046利用计算机技术对电厂的信息进行管理出现在20世纪60年代末，到了80年代，一些软件公司开发出基于主机和字符终端的电厂管理信息系统，由于当时计算机设备昂贵，系统运行效率低，加上字符终端所显示的内容受到限制，因而没有形成规模。进入90年代，以图形为界面、网络和数据库为支撑的电厂管理信息系统逐步在电厂中推广应用，计算机技术也在电厂控制系统中得到广泛应用，过去电厂控制系统分散孤立的局面逐渐被全厂统一的计算机网络所取代，与MIS在计算机平台上实现了对接，形成了由底层实时信息和操作记录、管理层业务信息、决策层支持信息等组成的一套完整的电厂信息技术（IT）解决方案。<img src ="http://blog.csdn.net/viving/aggbug/1922046.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/07/1922042.aspxFri, 07 Dec 2007 10:41:00 GMThttp://blog.csdn.net/viving/archive/2007/12/07/1922042.aspxhttp://blog.csdn.net/viving/comments/1922042.aspxhttp://blog.csdn.net/viving/archive/2007/12/07/1922042.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1922042.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1922042图表英文是CHART。 图表的差异，一方面在于是否能实现各种不同样式的图，另一方面在于展现的时候是什么样子。比较好的是在HTML里直接展现，而比较差的就还要通过一个控件。 <img src ="http://blog.csdn.net/viving/aggbug/1922042.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/04/1915189.aspxTue, 04 Dec 2007 10:05:00 GMThttp://blog.csdn.net/viving/archive/2007/12/04/1915189.aspxhttp://blog.csdn.net/viving/comments/1915189.aspxhttp://blog.csdn.net/viving/archive/2007/12/04/1915189.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1915189.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1915189商业智能系统维护与治理，包括商业智能整合性系统建立、数据库治理、安全治理与效率治理等步骤。这里涉及两个层面，第一是维持与治理商业智能系统与其支持结构（数据库治理、安全治理、效能治理）所需的基本功能。第二是从技术及商业的角度来探讨商业智能系统配置是否达到最佳。从技术的角度而言，包括检查逻辑与实体数据库设计，以及所需工作效率调整是否合适。从商业的角度而言，包括数据库稽核，亦即访问商业使用者，以考察他们的需求是否获得满足，以及获得的投资报酬。<img src ="http://blog.csdn.net/viving/aggbug/1915189.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/12/04/1915177.aspxTue, 04 Dec 2007 10:00:00 GMThttp://blog.csdn.net/viving/archive/2007/12/04/1915177.aspxhttp://blog.csdn.net/viving/comments/1915177.aspxhttp://blog.csdn.net/viving/archive/2007/12/04/1915177.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1915177.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1915177交叉表的特点是： 数据在横、纵两个方向扩展，即行、列均不固定 左边、上边都有一个表头，而中间是明细区。后面往往还有合计之类的。 有人会问，前面讲了纵向扩展的表，为什么没有讲只有横向扩展的表呢？实际上，大部分比较传统的报表工具，都不支持横向扩展，对于它们而言，纵与横是不对称的概念（和EXCEL完全不一样），而交叉表因为实际需求比较多，所以单独弄出一类。但比较新的发展是在报表工具中采用纵横对称的概念和类似于EXCEL的设计风格，从而很容易解决横向扩展的问题。 <img src ="http://blog.csdn.net/viving/aggbug/1915177.aspx" width = "1" height = "1" />vivinghttp://blog.csdn.net/viving/archive/2007/11/30/1908716.aspxFri, 30 Nov 2007 11:03:00 GMThttp://blog.csdn.net/viving/archive/2007/11/30/1908716.aspxhttp://blog.csdn.net/viving/comments/1908716.aspxhttp://blog.csdn.net/viving/archive/2007/11/30/1908716.aspx#Feedback0http://blog.csdn.net/viving/comments/commentRss/1908716.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1908716的来说，元数据治理还是一个不成熟的领域。具体原因有业务和技术两个方面。 从业务上看，很多人对于建立一个元数据治理、交换平台的目的并不明确，也没有人知道集中这些元数据究竟给企业带来多大价值。 从目前国内企业所处的阶段看，建立这样一个平台并不能产生多少价值。即便是在平台的建设初衷和谁来使用这个平台等问题上，也有多种说法。例如有人说这是企业数据标准的前提，也有人认为是企业数据集成的基础，可以使系统变得可扩展。这些听起来确实有道理，但也太过空洞。假如追问下去，这些说法都经不起推敲。比如建立企业数据标准又是为了什么目的？数据集成又是为了什么目的？ <img src ="http://blog.csdn.net/viving/aggbug/1908716.aspx" width = "1" height = "1" />