<?xml version="1.0" encoding="UTF-8"?><!-- generator="WordPress/2.5.1" -->
<rss version="0.92">
<channel>
	<title>博计报表↓专注于提升.net报表项目的开发效率</title>
	<link>http://www.bonzerreport.com</link>
	<description>专注于提升.net报表项目的开发效率</description>
	<lastBuildDate>Sun, 04 Jan 2009 07:35:33 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	
	<item>
		<title>博计报表完整安装包</title>
		<description>博计报表完整安装包：含设计器、服务器

 博计报表完整安装包











 </description>
		<link>http://www.bonzerreport.com/download/download-install.html</link>
			</item>
	<item>
		<title>横向多源关联分片性能分析</title>
		<description>信息系统中，数据往往分散在一个库或者多个库中，利用统计报表对数据进行展现时，就经常需要从多个库中读取数据，在一张表里进行统计和展现。  &#160;  如果数据存在于多个库中，那么数据只能取到报表中进行数据关联和运算，如果数据存在于一个库的多张表里，有时候可以通过写sql或者存储过程进行关联，但是更多时候为了加快运算速度，也需要取到报表中进行数据关联。  &#160;  从多个库或者多张表中分别取数，然后在报表中进行关联的报表，称为多源关联报表。  &#160;  多源往往带来分片，正是由于分片，使得报表设计必须直接基于多源进行，而不能先将多源转成单源进行。有相当一部分分片报表无论如何也不可能换成单源处理，部分能转成单源的报表处理也非常繁琐。  &#160;  分片是指报表的纵向或横向或双向同时被分成了多个区域，每个区域扩展重复规则不同，而又可能相互运算。  &#160;  如下表就是一个较典型的固定列横向分片报表。    &#160;  这个报表中涉及到的人员基本信息、收入信息、考勤信息、费用情况一般来讲在数据库中会分别存在不同的数据表中。由于传统工具是单数据源的，为了组织出这个报表需要的数据，就必须在数据源设计阶段把这四个数据表叉乘起来（JOIN），且不论写个四表叉乘的SQL有多麻烦（无论图形化设计还是手写都不会简单，WHERE子句中会有太多的AND），我们只考虑这样一句复杂的SQL的运算效率会怎样。  &#160;  数据表叉乘的运算复杂度是各表记录数的乘积，即N1*N2*...*Nk。k是分片数，Ni是第i个数据表的记录数，简单地写，就是指数级的O(Nk)复杂度，分片数少时感觉不明显，若k较大时（比如分个七八片、十几片），这个运算量会急剧上升，到了不可容忍的地步，再优秀的数据库都会被这种运算拖垮。  &#160;  博计报表的处理方法则完全不同，由于可以直接支持多数据源，上面的报表就不需要写成一句四表叉乘的SQL，而是写四句独立的SQL，这种写法显然要比叉乘简单许多（是简单，不是短，写的SQL总字数可能更多，但很简单）。然后在报表中先把基准的数据表列出来（这个表中是最左边的一边，即人员姓名），其它片通过条件运算向基准片对齐，如第二片的表达式含义即是找出姓名等于第一列的人的当月收入填入格中，第三片的表达式含义是找出姓名等于第一列的人的当月考勤信息填入，...。这样相当于每一片都和基准片进行了一次叉乘运算，运算复杂度为N1*N2+N1*N3+...+N1*Nk，简单地写就是k-1倍的O(N2)，还是O(N2）。这是个平方级的运算，整体复杂度随着分片数增加呈线性增长而非指数增长！效率可以极大地提高。  &#160;  采用传统工具时，如果运气好了，在数据库中建了合适的索引，数据库有时也会自动把前述的O(Nk)变成上述这种O(N2），但这是没准的事情，而且也不可能在数据库中把所有表都建上索引。  &#160;  造成传统工具这种问题的设计根源在于其来自国外的数据处理模型。国外应用一般都要求业务系统中事先为查询分析建好模型，然后只需要基于这些模型提供简单的报表，这样很少会出现分片报表，即使有也就是两三片而已。然而国内应用中报表远比国外复杂，仅仅依靠事先建好的数据模型远远不够用，因此常常出现分片数很多的报表。  &#160;  我们在实际工作中确实碰到过这种现象，5个分片，对应的每个数据表约1万条记录，用brio在oracle数据库中运算了约20分钟，而用博计报表是6秒! </description>
		<link>http://www.bonzerreport.com/function-authorize/function/verhimultilinks.html</link>
			</item>
	<item>
		<title>多源关联分片介绍</title>
		<description>多源关联分片是比较常见的报表特征。  &#160;  多源是指一个报表的数据来源来自多个物理数据表（或类似数据体），甚至是多个物理数据库。这里的“多个”常常不是两个三个，而是七八个乃至十几个。  &#160;  严格意义上的多源报表，指的是单独从多个数据来源取数，然后在报表中进行关联。那种在sql或者存储过程中进行数据关联的做法，并不是真正意义上的多源。sql里对数据进行关联有很多局限，比如多个库中就没法关联，或者一部分数据来自txt文件，也无法进行关联。  &#160;  多源往往带来分片，正是由于分片，使得报表设计必须直接基于多源进行，而不能先将多源转成单源进行。有相当一部分分片报表无论如何也不可能换成单源处理，部分能转成单源的报表处理也非常繁琐。  &#160;  分片是指报表的纵向或横向或双向同时被分成了多个区域，每个区域扩展重复规则不同，而又可能相互运算。  &#160;  表1是个典型的纵向分片报表，数据区从上至下分成了几片，先是一片按客户汇总的两级分组区域，然后是两个固定计算行，接下来又是一片按年度汇总的一级分组区域，最后又是一个固定的合计行。各片分组层数不同，而且变动与固定固定结合，而且各片之间还有数据沟通（某些计算行的值是由其它行计算出来的）。这种上下格式不一致的报表，其数据源不可能组织成单源（各片列数不同）。    表1  &#160;  我们把表1横过来摆形成表2，成为一个横向分片表。类似的，也是有两片分组层数不同的变列区域和几个固定的计算列混合而成。    表2  &#160;  多源关联分片报表，其最核心的还在于数据的关联，即片与片之间的数据关联。这种数据的关联运算，处理得好，可以性能很高，运算速度很快，处理不好，很可能运算极其慢。 </description>
		<link>http://www.bonzerreport.com/function-authorize/function/multipieceslink.html</link>
			</item>
	<item>
		<title>强大的数据填报功能</title>
		<description>企业级软件应用随着信息技术的不断发展也得到了不断的提高，开始时候是单机数据操作，之后是联机文件处理，这时候开始出OA类的软件工具，在这以后是标准的财务软件，进销存软件大放异彩，随后便出现了MRPⅡ，ERP，EMP，BI等等标准企业流程再造概念，时至今日，已经是各类业务软件百花齐放，异彩纷呈。  &#160;  软件市场越来越热闹，但是对软件用户来说困惑却越来越多，一些需要灵活报送数据的行业由于数据格式变化大，需求多，标准的产品软件根本无法实现其需要，这一类的用户多集中在金融、咨询、化工、冶炼、通信等行业，我们在实际接触的大量用户中也了解到非常多这类的需求，使用旧式的工具多数时候很难保证项目的进度，随着此类应用越来越多，客户也迫切希望有一个随需而动的工具能够更快更好的满足企业自身的需要。  &#160;  博计报表的填报模型是一个快速开发各类数据采集系统的专业工具，它能够实现各类规范/复杂的填报应用，并且设计过程简单高效。  &#160;  博计报表的填报模型把数据采集的业务分作两个基本模式，行式填报和自由填报。首先，行式填报是针对简单快速填报业务的处理，行式填报可以方便的添加、插入、删除行，并对填写的单行数据即时进行保存。  &#160;        &#160;  自由填报可以用来做复杂的数据填报格式，相对与行式填报，自由填报的填报格式更为灵活。下面列出一个自由填报表的实例以供参考：  &#160;    &#160;  使用自由填报可以完成任何复杂格式数据采集需求，针对变动大，需求灵活的数据采集需要博计报表提供了完整数据填报方案，可以满足各种WEB数据采集的需求。  &#160;  博计报表的行式填报和自由填报能够广泛应用到各企事业单位，科研机构，各类集团组织，金融，咨询服务，冶炼等实际项目中，由于博计报表是一个纯java的报表工具，高效制表，部署迅速，能够与已有J2EE项目实现无缝衔接，博计报表也正不断进行产品优化和技术创新，力求为国内报表项目提供更加强大、完整的报表解决方案！ </description>
		<link>http://www.bonzerreport.com/products/data-report.html</link>
			</item>
	<item>
		<title>高效报表设计</title>
		<description>您见过比EXCEL的界面环境更适合设计静态报表的工具么？  &#160;  相信制作过报表或者浏览过诸多报表的读者都会有一致否定的回答，EXCEL的界面环境确实是设计报表的不二选择，其设计效率与便捷的操作设置在定义静态报表方面的优势无可比拟。  &#160;  同样的争议也曾经在专业级报表工具业内出现过，到底是控件式拖拽设计还是类似于EXCEL的设计模式？毕竟几个元老级别报表工具使用的都是控件拖拽的设计界面，但是，自从润乾报表推出类EXCEL报表设计工具以来，这一争议得到了更响亮的回应：即便是在专业的报表设计工具内，类似于EXCEL的设计报表的工作效率还是远超出控件拖拽式的设计，如同以前的结论：在习惯了EXCEL的设计环境以后，没有人愿意拿powerpoint的矩形框来拼表！  &#160;  EXCEL即便是对非专业人士而言，也是一个容易上手的制表工具，入门根本不需要多少时间，很快就可以从无到有制作出界面精美的表格。下面我们来看看博计类EXCEL的设计模型在多大程度上继承了EXCEL的特点。      博计报表类EXCEL的设计界面  &#160;  在左侧窗口的主设计界面，是最为常见的行列式二维表格，在这里设定格式时候会发现，在设定静态风格上，博计与EXCEL的功能完全一致：     设定单元格宽度和高度、背景色、前景色、显示格式、换行、格线等等；    字体类型、字体大小、字体粗细、斜体及下划线设置等；    数据水平对齐、垂直对齐；    格式刷；   &#160;  在定义格式方面，这些都与EXCEL毫无差别，而博计的设计环境在静态格式的基础上还对单元格的表达式进行了继承；还记得如何在EXCEL中定义表达式么？想要在E3单元格中汇总A3-D3的数据，那你要在E3单元格中写入：=SUM(A3:D3)。同样的例子不妨拿到博计里面试一下，你会发现，在博计里面表达式处理与EXCEL如出一辙。  &#160;  博计可以像EXCEL一样对位置变动的单元格中的表达式自动调整，如果在上面的表格里面，我在B3和C3之间插入一个新列，这时候EXCEL的F3单元格（原E3）的表达式会自动调整为:=SUM(A3:E3)，同样，在博计的设计表格里，当设计者插入一行或者一列时，相关的表达式也会进行自动调整；不仅如此，诸如：A2+B3-A4、（A1+E2*D4）/C3，同EXCEL一样，这类灵活的公式定义也能得到正确运算。  ...</description>
		<link>http://www.bonzerreport.com/products/efficiency-design.html</link>
			</item>
	<item>
		<title>复杂报表的制作</title>
		<description>什么是复杂报表？  &#160;  在企业信息化的过程中经常会碰到这样的问题：要不要二次开发？其中涉及到报表的情况较常见。稍稍了解一下实际的应用情况就会知晓，有报表的二次开发需要是由于标准业务类软件产品中查询报表功能不足导致的。经验显示：以前在引入标准业务类软件的同时，要考虑付出二次开发的成本。  &#160;  可往往二次开发的成本都是非常高的，软件提供商的资深顾问会告诉客户，标准产品的二次开发需要耗费额外的资源，由于公司的业务较多，开发的人力物力都比较紧张，所以作二次开发并不划得来，出于为客户的切身利益考虑，他们会给客户提供一些变通的方法，诸如：分表、拼表。如果客户原来的一张报表被分成两个，三个或者是更多的表；亦或是陷入与软件开发人员持久的需求确认，就应该知道，现在碰到复杂报表的难题了。  &#160;  复杂报表难道没有更好的解决办法么？  &#160;  实际上并非是软件提供商和实施顾问没有尽到本分，更不是开发人员故意磨洋工，问题在于软件开发人员仍然在使用传统的报表工具或者更加原始的手工编码实现，这直接导致了报表开发慢、周期长、成本高！  &#160;  &#8220;工欲善其事，必先利其器&#8221;，博计报表从既有功能卓越报表模型的基础上提取出更为先进的报表设计模型，能快速解决中国式复杂报表常见的对称双向扩展、任意分组汇总的难题，从而根除了软件提供商在报表上的后顾之忧。  &#160;    报表样例一    报表样例二       &#160;  如果您现在就有复杂报表的问题，请联系我们的在线客服，他们会针对具体问题提供专业详实的解决办法。 </description>
		<link>http://www.bonzerreport.com/products/make-report.html</link>
			</item>
	<item>
		<title>Web报表软件的集成方案</title>
		<description>报表开发只是应用程序中的一部分，而非全部，因此Web报表软件的集成性就显得非常重要了。     传统的Web报表软件无一例外地都提供了一个独立的报表服务器。采用独立服务器时的，应用结构如下图：  &#160;    &#160;  采用独立服务器的不便：      独立的报表服务器，与应用程序的沟通是通过网络协议，严重降低性能；     无法享受应用服务器的各项优势功能，包括集群能力、连接池的管理能力等；     报表服务器独立的用户权限户管理机制，无法适应各种行业、各种应用独特的用户角色管理需求，不够用却又迫使应用程序遵守它的规则；     编程接口太少，控制力度弱，难于整合。         博计软件没有独立的报表服务器，没有应用架构，也没有独立的用户角色管理机制，极大的方便了程序员的集成，其应用结构如下：  &#160;    &#160; ...</description>
		<link>http://www.bonzerreport.com/products/integrat-solution.html</link>
			</item>
	<item>
		<title>Web报表软件的采购成本</title>
		<description>一般地，Web报表在一个软件开发项目中占的比例大概是 10% 左右，这两年有上升的趋势，据总体统计项目中报表的开发量大的能占到20%。下面的计算还是以10%为标准，每人月的成本按2.5万计算。  &#160;  以一个100万的软件开发项目为例，Web报表的工作量占 10% ，即开发成本为 10 万元。以 2.5 万 / 人月来计算，这个项目需要用 4 个人月来完成报表工作。在实际的项目中，这 10 万元有几种方式分摊：  &#160;  （1）集成商以前的代码积累＋程序员按项目定制。说白了，就是纯手工编写代码。这里又分两种情况： A 、是在集成商以前的代码积累基础之上直接按项目定制； B 、找开源的报表软件，在此之上做修改。这样做能在一定程度上减少程序员的工作量和后期的维护成本，但是开发上要受限于开源软件。且不论产品资料、函数接口什么的是否齐全，单是开源软件的 bug 问题就够让人挠头的了。  &#160;  这两种方式不涉及到采用报表软件的成本问题，好处就是开发人员对程序能完全控制，开发成本直观。坏处就是如果项目报表的要求比较高的话，程序员的工作量会相当大，报表开发效率低，报表的后期维护成本也比较高，只要客户要修改报表，就必须找到开发商，除非事先商量好，否则就会出现钱方面的扯皮。实际应用中， A、B两种方式主要集中在中小型的项目。  &#160;  （2）Web报表软件＋程序员开发。用报表软件的好处有很多，象提高开发效率、节省时间、缩短工期、方便后期维护等到，就不多说了。但是市场上报表软件非常多，如何能选择出既符合项目需要、又能合理控制成本的工具呢？采购报表软件的成本遵循下面这个原则就行： 选择的Web报表软件至少能减少 50% 的报表开发工作量，报表的总开发成本降低 1/3 左右。  &#160;  再拿上面的例子来说：以前做报表需要4个人月，在使用Web报表工具后，应该2个人月就能完成；加上报表软件的采购成本，原来需要10万元才能做完的事情，应该要6、7万元就能做完。  &#160;  ...</description>
		<link>http://www.bonzerreport.com/products/procurement-cost.html</link>
			</item>
	<item>
		<title>Web报表工具的新起点</title>
		<description>国内的信息化将近 20 年了，但是信息化系统中的报表问题一直是个老大难，每到项目收尾阶段，开发商不做别的，就安排几个程序员，吭哧吭哧做报表，而现在市场上林林总总不下 20 家专业的Web报表工具，如果再加上各家公司自己开发 、 用于项目的报表控件 、 程序等等，用数以百计来形容报表工具的种类并不过分。显而易见，大家都没有找到好的解决方法（否则就不会出现报表工具百家争鸣的局面），而专业报表厂商的产品似乎连用户 50 ％的需求都满足不了，这是怎么回事？   &#160;  从报表工具的发展历史来看，在应用系统进入数据库、数据共享的时候，就有比较专业的web报表工具或控件出现，并且一直沿用到今天。这些工具的理论模型和需求都出自于国外的需求，这种模型和需求是否符合我们的报表习惯，我们在&#8220;拿来&#8221;这些工具的时候并没有认真考虑。事实上，我们的报表习惯与国外用户的可以说是天壤之别。  &#160;  这些工具之初，不能将国情与工具相结合是可以原谅的，毕竟这是成长应该付出的代价。但是，在拿来这些工具十几、二十年后，报表制作仍然面临着同样的问题，而前仆后继赶时髦的还大有产品在，那么什么时候复杂报表的问题才能被根本解决？这种代价，会不会太大？   &#160;  报表厂商无法静下来心来研究复杂报表的需求 ，耐不住长期研发的寂寞 ，也被短期的收入刺激着 ， 或许，还缺乏一些自信－真的能研发出来适合咱们的工具吗？拿来就成为最简便、快捷的方式：要么在开源产品上、要么在第三方控件上修改、包装，再包上解决复杂报表、报表工具等的外衣，一个新的报表工具就诞生了。专业厂商都是这样，对系统开发商来说，要求就更低了。   &#160;  这是造成报表工具普遍难用的一个根本原因。   &#160;  博计给了解决中国报表的一个新的起点，自主创新才是中国软件腾飞的正确之路。  </description>
		<link>http://www.bonzerreport.com/products/report-newstart.html</link>
			</item>
	<item>
		<title>博计报表教程及手册</title>
		<description>博计报表教程及手册：教程及使用手册

 

  博计报表教程及手册下载 </description>
		<link>http://www.bonzerreport.com/download/download-help.html</link>
			</item>
</channel>
</rss>
