java开发者 网友 溪涧
多谢了！
最近工作中用到报表，而我在学习JasperReport的过程中遇到了很多问题（主要是国内的资料太少了），网上很少找得到，在此我就把我找到的一些资料和大家共享，希望能对大家有所帮助。
1、JasperReport和iReport的资源，最新版本可以到下面官方网站得到
iReport官方网站：
http://ireport.sourceforge.net
JasperReport官方网站：
http://jasperreports.sourceforge.net
2、安装
1）、JDK的安装，并配置JAVA_HOME
比如我的JAVA_HOME路径如下：
JAVA_HOME D:\Program Files\j2sdk1.4.2_03
2）、由于中文的问题，所以还需要下载：itext-1.02b.jar和iTextAsian.jar包
下载地址：http://itext.sourceforge.net/downloads/iTextAsian.jar
并在CLASSPATH中设置
例如我的CLASSPATH如下：
CLASSPATH
E:\Program Files\Apache Group\Tomcat4.1\webapps\testreport\WEB-INF\lib\itext-1.02b.jar;E:\Program
Files\Apache Group\Tomcat 4.1\webapps\testreport\WEB-INF\lib\iTextAsian.jar;E:\Program Files\Apache
Group\Tomcat 4.1\webapps\testreport\WEB-INF\lib;D:\tools\iReport0.2.3\lib
3）、iReport的安装iReport只要解压就OK，如果没有安装Ant，可以直接在iReport下的noAnt目录下，
运行startup.bat就可以了，这样iReport就可以启动了
4）、JasperReport
Jasperreport不需要任何配置，你只需将下载以后的jar包放到classpath下即可
5）、数据库的JDBC驱动包
加入到CLASSPATH中
3、详细资源
iReport官方提供了一些关于iReport视频，对于初学者很有帮助：
地址：http://ireport.sourceforge.net/docs.html
JasperReport官方提供的使用指南
地址：http://jasperreports.sourceforge.net/tutorial/index.html
JasperReport提供的一些例子：
地址：http://jasperreports.sourceforge.net/samples/index.html
4、常见问题
1）、iReport中提示框输入中文是不能正常显示，请将iReport下lib中的这个包删除tinylaf.jar
2）、在iReport中运行报表时如果出现乱码问题，请检查itext-1.02b.jar和iTextAsian.jar这两个包是否加到CLASSPATH
3）、在jsp或servlet高度报表时出现乱码或不显示，请检查你在报表设计过程中所设置的字体及其编码
比如：pdfname、pdfencoding
5、下面是两个调试例子
Servlet:
import javax.servlet.*;
import javax.servlet.http.*;
import dori.jasper.engine.*;
import java.io.*;
import java.util.*;
import java.sql.*;
/**
* @author Administrator
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>Code Generation>Code and Comments
*/
public class TestReport extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
Connection conn = null;
try {
Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver");
conn =
DriverManager.getConnection(
"jdbc:microsoft:sqlserver://192.168.0.10:1433;DatabaseName=am;user=sa;password=sa");
ServletContext servletContext =this.getServletContext();
File reportFile = new File(servletContext.getRealPath("test/iteminfo.jasper"));
Map parameters = new HashMap();
Integer i=new Integer(8);
parameters.put("pjId", i);
byte[] bytes =
JasperRunManager.runReportToPdf(
reportFile.getPath(),
parameters,
conn);
response.setContentType("application/pdf");
response.setContentLength(bytes.length);
ServletOutputStream ouputStream = response.getOutputStream();
ouputStream.write(bytes, 0, bytes.length);
ouputStream.flush();
ouputStream.close();
} catch (JRException jre) {
System.out.println("JRException:" + jre.getMessage());
} catch (Exception e) {
System.out.println("Exception:" + e.getMessage());
}
}
public void doPost(
HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
doGet(request, response);
}
}
数据仓库模型的特点
对于传统的OLTP系统，我们总是按照应用来建立它的模型，换言之，OLTP系统是面向应用的。而数据仓库则一般按照主题 (Subjec
t)来建模，它是面向主题的。何谓应用?何谓主题?让我们来看一个简单的例子。在银行中，一般都有对私 (个人储蓄)、对公 (企业储蓄)、信用卡等多种业务系统，它们都是面向应用的，所支持的交易类型简单而且固定。由于实施的先后等原因，这些系统可能运行在不同的平台上，相互之间没有什么关系，各系统之间的数据存在冗余。比如每个系统中都会有客户的数据，当针对银行建立其数据仓库应用时，要把上述生产系统中的数据转换到数据仓库中来。从整个银行的角度来看，其数据模型不再面向个别应用，而是面向整个银行的主题，比如客户、产品、渠道等。因此，各个生产系统中与客户、产品、渠道等相关的信息将分别转换到数据仓库中相应的主题中，从而在整个银行的业务界面上提供一个一致的信息视图。
数据仓库的建模方法
逻辑建模是数据仓库实施中的重要一环，因为它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF，即 Third Normal Form)和星型模式 (Star-Schema)，我们将重点讨论两种方法的特点和它们在数据仓库系统中的适用场合。
什么是第三范式
范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也称为规范化 (Normalize)。在数据仓库的模型设计中目前一般采用第三范式，它有非常严格的数学定义。如果从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件:
1. 每个属性的值唯一，不具有多义性;
2. 每个非主属性必须完全依赖于整个主键，而非主键的一部分;
3. 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
我们可以看到，第三范式的定义基本上是围绕主键与非主属性之间的关系而作出的。如果只满足第一个条件，则称为第一范式;如果满足前面两个条件，则称为第二范式，依此类推。因此，各级范式是向下兼容的。
什么是星型模式
星型模式是一种多维的数据关系，它由一个事实表(Fact Table)和一组维表(Dimens ion Table)组成。每个维表都有一个维作为主键，所有这些维则组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实 (Fact)，它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。
第三范式和星型模式在数据仓库中的应用
一个数据仓库的基本结构可以分成四层:
也有一些企业由于这样那样的原因，没有建立全企业范围的数据仓库，而是建立基于部门应用的独立数据集市(有关数据集市与数据仓库的比较，请参阅本报今年第 27期上笔者编译自 Bill Inmon的文章)。
大多数人在设计中央数据仓库的逻辑模型时，都按照第三范式来设计;而在进行物理实施时，则由于数据库引擎的限制，不得不对逻辑模型进行不规范处理 (De-Normalize)， 以提高系统的响应速度，这当然是以增加系统的复杂度、维护工作量、磁盘使用比率 (指原始数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。
根据数据仓库的测试标准 TPC-D规范，在数据仓库系统中，对数据库引擎最大的挑战主要是这样几种操作:多表连接、表的累计、数据排序、大量数据的扫描。下面列出了一些 DBMS在实际系统中针对这些困难所采用的折衷处理办法:
S如何避免多表连接:在设计模型时对表进行合并，即所谓的预连接 (Pre-Join)。当数据规模小时，也可以采用星型模式， 这样能提高系统速度，但增加了数据冗余量。
S如何避免表的累计:在模型中增加有关小计数据 (Summarized Data)的项。这样也增加了数据冗余，而且如果某项问题不在预建的累计项内，需临时调整。
S如何避免数据排序:对数据事先排序。但随着数据仓库系统的运行，不断有新的数据加入，数据库管理员的工作将大大增加。大量的时间将用于对系统的整理，系统的可用性随之降低。
S如何避免大表扫描:通过使用大量的索引，可以避免对大量数据进行扫描。但这也将增加系统的复杂程度，降低系统进行动态查询的能力。
这些措施大都属于不规范处理。根据上面的讨论，当把规范的系统逻辑模型进行物理实施时，由于数据库引擎的限制，常常需要进行不规范处理。举例来说，当系统数据量很小 ，比如只有几个 GB时，进行多表连接之类复杂查询的响应时间是可以忍受的。但是设想一下，如果数据量扩展到很大，到几百 GB，甚至上 TB，一个表中的记录往往有几百万、几千万，甚至更多，这时进行多表连接这样的复杂查询，响应时间长得不可忍受。这时就有必要把几个表合并，尽量减少表的连接操作。当然，不规范处理的程度取决于数据库引擎的并行处理能力。用户在选择数据库引擎时，除了参考一些相关的基准测试结果外，最好是能根据自己的实际情况设计测试方案，从几个数据库系统中选择最适合自己企业决策要求的一种。
不规范处理的阶段
现在来讨论一下，当不得不选择不规范处理时，应在哪个阶段进行。
由于中央数据仓库的数据模型反映了整个企业的业务运行规律，在这里进行不规范处理容易影响整个系统，不利于今后的扩展。 而且不规范处理产生的数据冗余将使整个系统的数据量迅速增加，这将增加 DBA的工作量和系统投资。因此，当系统性能下降而进行不规范处理时，比较好的办法是选择问题较集中的部门数据集市实施这种措施。这样既能有效地改善系统性能，又不至于影响整个系统。在国外一些成功的大型企业级数据仓库案例中，基本上都是采用这种方法。
那么，在中央数据仓库中是否可以采用星型模式来进行模型设计呢?我们知道，星型模式中有一个事实表和一组维表，我们可以把事实看成是各个维交叉点上的值。例如，一个汽车厂在研究其销售情况时可以考察汽车的型号、颜色、代理商等多种因素，这些因素就是维，而销售量就是事实。这种多维模型能迅速给出基于各个维的报表，这些维必须事先确定。
星型模式之所以速度快，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。在上面的例子中，就是按照汽车的型号、颜色、代理商进行预先的销售量统计。因此，在星型模式设计的数据仓库中，作报表的速度虽然很快，但由于存在大量的预处理，其建模过程相对来说就比较慢。当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。由于事实表的主键由所有维表的主键组成，这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。综合这些讨论，不难得出结论，星型模式比较适合于预先定义好的问题，如需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此，星型模式在一些要求大量报表的部门数据集市中有较多的应用。
小结
上面讨论了数据仓库模型设计中常用的两种方法。在数据仓库的应用环境中，主要有两种负载:一种是回答重复性的问题;另一种是回答交互性的问题。动态查询具有较明显的交互性特征，即在一个问题答案的基础上进行进一步的探索，这种交互过程常称为数据挖掘 (Data Mining)或者知识探索 (Knowledge Discovery)。对于以第一种负载为主的部门数据集市，当数据量不大、报表较固定时可以采用星型模式;对于中央数据仓库，考虑到系统的可扩展能力、投资成本和易于管理等多种因素，最好采用第三范式。
1：数据仓库必须由业务用户的需求来驱动，并因此从一个简单的维度视角来建立于展示数据仓库这样的概念；
2：对数据仓库，业务才是第一位的；
3：操作性系统：存入数据；数据仓库：取出数据；
4：数据仓库在需求、客户、体系结构和运行机制与操作性系统有很大不同；
5：客户的烦恼：不能访问数据；切割数据；快速访问；不同系统间不同编码；
6：数据仓库：易阅读的、并且精心组织，可信而安全；
7：EAI：企业应用一体化，所有系统按一定的视角来统一设计；
8：数据仓库的4个环节：操作源系统、数据聚集、数据展示和数据的存取；
9：ETL：数据析取转换和加载；转换如拼写错误、丢失补充、标准化格式、多数据源组合、重复数据消除、仓库
关键字的分配；
10：维度模型是为数据仓库用户提交数据最可行的技术手段；
11：维度建模和3NF范式建模的不同；
12：数据仓库维度建模要求：必须包含原子数据、一致性维度和事实；符合数据仓库总线结构；
13：总线结构是构造分布式数据仓库系统的秘诀；
14：元数据；
15：ODS：操作数据的存储，一般没有必要；
16：可加性、半加性和非加性事实；
17：事实表倾向于更多的行和更少的列，维表则相反；
18：事实表分类：周期、事务和累积快照；
19：数据仓库：以数据库为基础，在需求、客户、体系结构和运作方式等方面都与数据库应用有很大的不同；
20：数据仓库的两种增值操作：OLAP和DM；
1 什么是数据仓库?
目前，数据仓库一词尚没有一个统一的定义，著名的数据仓库专家W.H.Inmon在其著作
《Building the Data Warehouse》一书中给予如下描述：数据仓库（Data Warehouse）
是一个面向主题的（SubjectOriented）、集成的（Integrate）、相对稳定的（Non-Vola
tile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。对于数据仓库
的概念我们可以从两个层次予以理解，首先，数据仓库用于支持决策，面向分析型数据处
理，它不同于企业现有的操作型数据库；其次，数据仓库是对多个异构的数据源有效集成
，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再
修改。
数据仓库建模分为物理建模以及逻辑建模:
物理建模:侧重于对物理存储介质的访问.
逻辑建模:侧重于反应业务部门的需求,逻辑建模通常可以分为3NF(第三范式)及星状模型
第三范式:范式是数据库逻辑模型设计的基本理论,可以通过范式来规范化一个关系型数据
库,在数据仓库的模型设计中多采用第三范式是因为它有非常严格的数学定义
(1) 每个属性的值唯一，不具有多义性；
(2) 每个非主属性必须完全依赖于整个主键，而非主键的一部分；
(3) 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他
关系中去。
星状模型: 星型模式是三个或三个以上数据表的集合.星型模式是一种多维的数据关系，
它由一个事实表（FactTable）和一组维表（DimensionTable）组成。每个维表都有一个
维作为主键，所有这些维组合成事实表的主键，换言之，事实表主键的每个元素都是维表
的外键。事实表的非主属性称为事实（Fact），它们一般都是数值或其他可以进行计算的
数据，而维大都是时间、地域等类型的数据。