Mondrian是一个开放源代码的Rolap服务器，使用java开发的。它实现了xmla和jolap规范，而且自定义了一种使用mdx语言的客户端接口。Mondrian是olap服务器，而不是数据仓库服务器，因此Mondrian的元数据主要包括olap建模的元数据，不包括从外部数据源到数据库转换的元数据。也就是说Mondria的元数据仅仅包括了多维逻辑模型，从关系型数据库到多维逻辑模型的映射，存取权限等信息。在功能上，Mondrian支持共享维和成员计算，支持星型模型和雪花模型的功能。
Mondrian中使用物理的xml文件存储元数据，它的设计者规定了xml文件的格式。下面简单介绍一下它是如何存储元数据的。

Element Description
根元素
<Schema> Collection of Cubes, Virtual cubes, Shared dimensions, and Roles.
逻辑元素
<Cube> A collection of dimensions and measures, all centered on a fact table.
<VirtualCube> A cube defined by combining the dimensions and measures of one or more cubes.
<Dimension>
<DimensionUsage> Usage of a shared dimension by a cube.
<Hierarchy>
<Level>
<Property>
<Measure>
物理元素
<Table> Fact- or dimension table.
<View> Defines a 'table' using a SQL query, which can have different variants for different underlying databases.
<Join> Defines a 'table' by joining a set of queries.
存取控制
<Role> An access-control profile.
<SchemaGrant> A set of rights to a schema.
<CubeGrant> A set of rights to a cube.
<HierarchyGrant> A set of rights to a hierarchy and levels within that hierarchy.
<MemberGrant> A set of rights to a member and its children.
其他
<Parameter>
<Table>
<Table>



一个模式定义一个多维数据库，它包括一个逻辑模型，由立方体，层次，成员和逻辑模型到物理模型的映射构成。一个逻辑模型由可以用MDX语言来查询。Mondrain的模型由xml文件来描述。现在创建模式的唯一途径是用文本编辑a器编辑xml文件。Xml的语法不是太复杂，因此没有想象中的那么难。目前正在开发一个图形界面的程序来创建和修改模式。
一个模式最重要的组成部分是立方体，度量和维：在一个主题域中立方体是维和度量的集合。一个度量是一个可测量的数值，比如产品销售的数量或者详细清单的价格
一个维是一个属性或者是属性的集合， 通过维你可以将度量划分到字类中。比如：你希望将销售产品按颜色，顾客性别，售出的商店分为八个部分，那么颜色，性别，商店都是维。

下面是一个简单的模型定义的例子：
<Schema>
<Cube name="Sales">
<Table name="sales_fact_1997"/>
<Dimension name="Gender" foreignKey="customer_id">
<Hierarchy hasAll="true" allMemberName="All Genders" primaryKey="customer_id">
<Table name="customer"/>
<Level name="Gender" column="gender" uniqueMembers="true"/>
</Hierarchy>
</Dimension>
<Dimension name="Time" foreignKey="time_id">
<Hierarchy hasAll="false" primaryKey="time_id">
<Table name="time_by_day"/>
<Level name="Year" column="the_year" type="Numeric"
uniqueMembers="true"/>
<Level name="Quarter" column="quarter"
uniqueMembers="false"/>
<Level name="Month" column="month_of_year" type="Numeric"
uniqueMembers="false"/>
</Hierarchy>
</Dimension>
<Measure name="Unit Sales" column="unit_sales"
aggregator="sum" formatString="#,###"/>
<Measure name="Store Sales" column="store_sales"
aggregator="sum" formatString="#,###.##"/>
</Cube>
</Schema>

这个模型包含了一个销售cube，这个cube有两个维，时间和性别维；两个度量，销售数量和销售总额。
我们可以在这个模型上写一个 MDX 查询:
select {[Measures].[Unit Sales], [Measures].[Store Sales]} on columns,
{[Time].[1997].[Q1].descendants} on rows
from [Sales]
where [Gender].[F]
这 个查询涉及到了销售立方体, 每一个维 [Measures], [Time], [Gender], 这些维的多个成员. 结果如下:
[Time] [Measures].[Unit Sales] [Measures].[Store Sales]
[1997].[Q1] 0 0
[1997].[Q1].[Jan] 0 0
[1997].[Q1].[Feb] 0 0
[1997].[Q1].[Mar] 0 0

下面详细地介绍一下模式定义：
一个立方体是一个或者多个维和度量的集合，通常是一个事实表，这里是 ‘sales_fact_1997". 事实表保存了需要计算的列和包含维的参考表.
<Cube name="Sales">
<Table name="sales_fact_1997"/>
...
</Cube>
这里用 <Table> 元素定义事实表. 如果事实表 不在默认的模式中, 你可以用"schema"属性指定一个明确地模式,例如：
<Table schema="foodmart" name="sales_fact_1997"/>
你也可以利用 <View> 和 <Join> 结构来创建更复杂的sql .
度量
销售立方体定义了两个维 "Unit Sales" 和 "Store Sales".
<Measure name="Unit Sales" column="unit_sales"
aggregator="sum" formatString="#,###"/>
<Measure name="Store Sales" column="store_sales"
aggregator="sum" formatString="#,###.00"/>
每个度量有一个名字,对应事实表中的一列, 采用一个聚集函数 (usually "sum").
一个可选的格式字符串指定了值如何被打印. 这里我们选择销售数量不带小数的输出（因为销售数量是整数） ，销售总额带2位小数 . 符号',' 和 '.' 是对地区敏感的, 因此如果是在意大利运行, 销售总额可能会出现 "48.123,45". 你可以用 advanced format strings来实现更严格的效果.度量值不是从列中来的，而是从立方体的单元中来的
维
性别维由单一的层次组成，仅有一层。
<Dimension name="Gender" foreignKey="customer_id">
<Hierarchy hasAll="true" primaryKey="customer_id">
<Table name="customer"/>
<Level name="Gender" column="gender" uniqueMembers="true"/>
</Hierarchy>
</Dimension>
对于任意给定的销售, 性别维是指购买改产品的客户的性别. 它通过连接事实表"sales_fact_1997.customer_id"和维表"customer.customer_id"
来表示 。"gender" 包括两个值, 'F' 和 'M', 因此性别维包含的成员： [Gender].[F] and [Gender].[M]. 因为 hasAll="true", 系统产生一个特别的 'all' 层, 仅包括一个成员 [All Genders].
一个维可以包含多个层次:
<Dimension name="Time" foreignKey="time_id">
<Hierarchy hasAll="false" primaryKey="time_id">
<Table name="time_by_day"/>
<Level name="Year" column="the_year" type="Numeric"
uniqueMembers="true"/>
<Level name="Quarter" column="quarter"
uniqueMembers="false"/>
<Level name="Month" column="month_of_year" type="Numeric"
uniqueMembers="false"/>
</Hierarchy>
<Hierarchy name="Time Weekly" hasAll="false" primaryKey="time_id">
<Table name="time_by_week"/>
<Level name="Year" column="the_year" type="Numeric"
uniqueMembers="true"/>
<Level name="Week" column="week"
uniqueMembers="false"/>
<Level name="Day" column="day_of_week" type="String"
uniqueMembers="false"/>
</Hierarchy>
</Dimension>
第一个层次没有指定名称.缺省的情况下,一个层次拥有和它的维相同的名称。，因此第一个层次成为"Time".这些层次没有太多的共同之处，他们甚至没有相同的表，除非它们连接了实施表中的同一列"time_id"。在一个维上存在两个层次的原因是这样对最终用户是有用的. 如果一个维上存在两个层次, MDX会强制不允许在一个查询中同时用到他们.
A dimension can live in the fact table:
<Cube name="Sales">
<Table name="sales_fact_1997"/>
...
<Dimension name="Payment method">
<Hierarchy hasAll="true">
<Level name="Payment method" column="payment_method" uniqueMembers="true"/>
</Hierarchy>
</Dimension>
</Cube>
每个维包含有多层组成的一个层次,

大多数维都是仅有一个层次，但有时候一个维有多个层次。比如：你可能希望在时间维上从天聚集到月，季度和年；或者从天聚集到周和年。这两种层次都是从天到年，但是聚集的路径不同。大多数层次有全成员，全成员包括层次的所有成员，因此能够代表他们的总合。它通常命名为'All something',比如：'All stores'.




星型模式和雪花模式
mondrian支持星型模式和雪花模式。下面介绍一下雪花模式的建模，它需要用到操作符 <Join>.比如:
<Cube name="Sales">
...
<Dimension name="Product" foreignKey="product_id">
<Hierarchy hasAll="true" primaryKey="product_id" primaryKeyTable="product">
<Join leftKey="product_class_id" rightAlias="product_class" rightKey="product_class_id">
<Table name="product"/>
<Join leftKey="product_type_id" rightKey="product_type_id">
<Table name="product_class"/>
<Table name="product_type"/>
</Join>
</Join>
...
</Hierarchy>
</Dimension>
</Cube>
这里定义一个 "Product" 维 由三个表构成. 事实表连接 表"product" (通过外键 "product_id"),表"product"连接表"product_class" (通过外键 "product_class_id"),表"product_class"连接表 "product_type" (通过外键 "product_type_id"). 我们利用 <Join> 元素的循环嵌套， <Join>带有两个操作对象; 操作对象可能是表，连接或者查询 。
按照操作对象行的数目来安排次序，表 "product" 的行数最大, 因此它首先出现连接事实表;然后是表 "product_class"和 "product_type",在雪花的末端拥有的行数最小.
注意外部元素 <Join>有一个属性 rightAlias. 这是必要的，因为join 的右边(是内部元素 <Join> ) 有可能是许多表组成的.这种情况下不需要属性leftAlias,因为列 leftKey 很明确的来自表 "product".

共享维
当为一个连接生成SQL的时候, mondrian 需要知道连接哪一个列. 如果一正在连接一个多表连接, 你需要告诉它连接这些表里的哪一个表，哪一个列.
因为共享维不属于一个cube,你必须给它们一个明确的表 (或者数据源). 当你在一个特别的cube里用他们的时候, 你要指定外键 foreign key. 下面的例子显示了 Store Type 维被 连接到 Sales cube ，用了外键 sales_fact_1997.store_id, 并且被连接到Warehouse cube ，用了外键 warehouse.warehouse_store_id :
<Dimension name="Store Type">
<Hierarchy hasAll="true" primaryKey="store_id">
<Table name="store"/>
<Level name="Store Type" column="store_type" uniqueMembers="true"/>
</Hierarchy>
</Dimension>

<Cube name="Sales">
<Table name="sales_fact_1997"/>
...
<DimensionUsage name="Store Type" source="Store Type" foreignKey="store_id"/>
</Cube>

<Cube name="Warehouse">
<Table name="warehouse"/>
...
<DimensionUsage name="Store Type" source="Store Type" foreignKey="warehouse_store_id"/>
</Cube>




虚拟 cubes
父子层次
一个使用方便的层次 有一个严格的层的集合, 成员与层紧密的联系.比如,在 Product 层次中, 任何产品名称层的成员在商标层上都有一个父亲 ，商标层上的成员在产品子目录层也都有一个父亲. 这种结构对于现实世界中的数据有时候太严格了.
一个父子层次只有一层 (不计算 'all' 层), 但是任何成员可以在同一层上有父亲成员. 一个典型的例子是Employees 层次:
<Dimension name="Employees" foreignKey="employee_id">
<Hierarchy hasAll="true" allMemberName="All Employees" primaryKey="employee_id">
<Table name="employee"/>
<Level name="Employee Id" uniqueMembers="true" type="Numeric"
column="employee_id" nameColumn="full_name"
parentColumn="supervisor_id" nullParentValue="0">
<Property name="Marital Status" column="marital_status"/>
<Property name="Position Title" column="position_title"/>
<Property name="Gender" column="gender"/>
<Property name="Salary" column="salary"/>
<Property name="Education Level" column="education_level"/>
<Property name="Management Role" column="management_role"/>
</Level>
</Hierarchy>
</Dimension>
这里parentColumn 和nullParentValue是重要的属性:
属性parentColumn 是一个成员连接到它父亲成员的列名。在这种情况下, 它是指向雇员经理的外键。元素<Level>的子元素 <ParentExpression> 是与属性 parentColumn 有相同作用的，但是元素允许定义任意的SQL表达式, 就像元素 <Expression>. 属性 parentColumn (或者 元素<ParentExpression>) 是维一向Mondrian指出 层次有父子结构的。
属性 nullParentValue 是指明成员没有父成员的值 。 缺省情况下 nullParentValue="null", 但是因为许多数据库不支持null, 建模时 用其他值来代替空值，0和-1.

物理结构
member reade
member reader 是访问成员的方法. 层次通常以维表为基础建立的 ， 因此要用sql来构造.但是甚至你的数据没有存在于 RDBMS, 你可以通过一个 Java 类来访问层次。（自定义 member reader）
Here are a couple of examples:
DateSource (to be written)生成一个时间层次. 按常规,数据仓库工具生成一个表 ，每天包含一行。但是问题是这个表需要装载，并且随着时间的变化能够添加更多的行。 DateSource 在内存中按照要求生成日期成员.
FileSystemSource (to be written) 按照目录和文件的层次描述文件系统。 Like the time hierarchy created by DateSource, this is a virtual hierarchy: the member for a particular file is only created when, and if, that file's parent directory is expanded.
ExpressionMemberReader (to be written) 创建了一个基于表达式的层次。
自定义member reader 必须实现接口 mondrian.rolap.MemberSource. 如果你需要实现一个更大的成员操作集合, 需要实现接口 interface mondrian.rolap.MemberReader; 否则, Mondrian在 mondrian.rolap.CacheMemberReader中封装 你的 reader类.你的 member reader 必须有一个公共的构造函数，这个构造函数拥有参数(Hierarchy,Properties),抛出未检查的错误.
Member readers 用 元素<Hierarchy> 的属性memberReaderClass来声明; 任何 <Parameter> 子元素通过属性构造函数来传递.
这是一个例子:
<Dimension name="Has bought dairy">
<Hierarchy hasAll="true" memberReaderClass="mondrian.rolap.HasBoughtDairySource">
<Level name="Has bought dairy" uniqueMembers="true"/>
<Parameter name="expression" value="not used"/>
</Hierarchy>
</Dimension>
Cell readers
<Measure name="name" cellReaderClass="com.foo.MyCellReader">
类 "com.foo.MyCellReader" 实现了接口interface mondrian.olap.CellReader.


存取控制
可以定义存取控制的属性（角色）, 作为模式的一部分, 并且可以在建立连接的时候设置角色。
定义角色
角色可以通过 元素<Role>来设置 , 它是元素<Schema> 的直接的子元素.
下面是一个关于角色的例子:
<Role name="California manager">
<SchemaGrant access="none">
<CubeGrant cube="Sales" access="all">
<HierarchyGrant hierarchy="[Store]" access="custom" topLevel="[Store].[Store Country]">
<MemberGrant member="[Store].[USA].[CA]" access="all"/>
<MemberGrant member="[Store].[USA].[CA].[Los Angeles]" access="none"/>
</HierarchyGrant>
<HierarchyGrant hierarchy="[Customers]" access="custom" topLevel="[Customers].[State Province]" bottomLevel="[Customers].[City]">
<MemberGrant member="[Customers].[USA].[CA]" access="all"/>
<MemberGrant member="[Customers].[USA].[CA].[Los Angeles]" access="none"/>
</HierarchyGrant>
<HierarchyGrant hierarchy="[Gender]" access="none"/>
</CubeGrant>
</SchemaGrant>
</Role>
元素 <SchemaGrant> 定义了模式中缺省的对象方问权限. 访问属性可以是 "all" 或者 "none"; 这个属性可以被具体的权限对象继承. 在这个例子中, 因为 access="none", 用户只能浏览"Sales" 立方体, 这里明确的赋予了这个权限.
元素 <CubeGrant> 定义了立方体的访问权限. 就像 <SchemaGrant>, 属性access 可以是"all" 或者 "none", 并且能够被cube中具体的子对象继承.
元素 <HierarchyGrant>定义了层次的访问权限. 属性access 可以是"all", 意思是所有的members都是可见的; "none",意思是 hierarchy的存在对用户是隐藏的; "custom"， 你可以利用属性 topLevel 定义可见的最高层 (阻止用户 进行上卷操作， 比如浏览税收 上卷到 Store Country 层); 或者用属性 bottomLevel 定义可见的最底层 (这里阻止用户查看顾客个人的细节数据);或者控制用户查看哪一个成员集合,通过嵌套定义元素 <MemberGrant>.
你也可以只定义元素 <MemberGrant> ，如果模式的<HierarchyGrant> 有属性access="custom". Member grants 赋予 (或者取消) 访问给定的成员, 以及它的所有子成员.

改了不少JPivot/mondrian代码，还修正了jpivot一个bug。

对JPivot的jfreechart和drillthrough显示做了增强，终于可以拿出去给人用了。

先说说性能问题： 先是找了一台闲置的IBM X445 PC Server，4×2GHZ CPU，8G内存，2×146G硬盘，操作系统 windows 2000 ， 开启AWE 3G参数。然后装Oracle 10g，数据仓库模式，使用了4G AWE内存共约4.5GB内存。再建成一张1600万用户数据宽表，宽表一律使用bitmap索引，还有其他20个左右维表。 然后就简单了，写mondrian Cube，配JPivot。 最后搞下来的结果是：基本上mondrian 每次做group by 操作最长不超过30秒，一般在20秒左右。用户基本可以接受。问了使用NCR的朋友，说NCR使用自己的数据库，也基本是这样的一个性能。 PS：偷偷问一声，在这基础上，性能还能改进否?

 

再说说方向问题： 我们现在使用2个OLAP，一个是jpivot + mondrian ，属于ROLAP；另一个是BO intelligence + essbase，属于MOLAP。目前的感觉是，由于DB性能强悍，导致ROLAP和MOLAP在性能上相差不大。同时ROLAP可以直接和报表系统共用同一张表。而MOLAP则需要使用工具来打CUBE做数据转换，这样在开发和维护工作量上，MOLAP比ROLAP大。 另外往往业务部门分析到最后，就是要看明细数据了，这个时候MOLAP的前端工具往往不能做好支持。而jpivot则无此问题。 综上所述，我目前好像还没看到必须用MOLAP的理由，听说华为原来用M$ 的OLAP，后来好像支持不住了，就直接用回了BO 报表，呵呵。

 

JPivot的问题： 操作太复杂，必须对OLAP的概念有清晰的了解，普通用户无法使用。与mondrian 集成不够紧密。mondrian不提供数据钻取功能，该功能是jpivot自己做的，所以会导致数据类型格式丢失。钻取详细数据量无限制，导致内存溢出。界面比较难看，操作方式非主流使用jpivot自己的mvc框架，不易其他框架集成 总体来说，jpivot目前已经不是一个玩具了，完全可以用于企业级的操作，而且定位在高端业务分析人员。


拿出来开源比较困难，一方面jpivot在不停升级，另一方面我在修改的时候不顾一切，在jpivot中乱引用了mondrian代码，还把mondrian部分无用代码全删了。这样，我就在这个帖里把能共享部分都在这里帖出来。 首先是我优化后的界面。 1.图标用了pentaho里面的图标。 2.jpivot里面其实支持3D饼图，只是选项未开，我先将jfreechart升级成1.0.2，又对饼图、线图等做了美观。 3.drillthrough是jpivot相对其他olap产品的杀手级功能，但是有不少细节未完善。我基本都一一补上。 在界面上可以看出，我添加了一个CSV导出功能(改了WCF库)，同时限制最大导出20万行记录(改了jpivot)。界面上显示的“访问次数”是measure的名字，实际上应该显示“访问时间”，该问题暂时无解。另外修正了一下numberformat、dateformat不正确的一些问题。 4.excel导出时，格式很难看，但是由于excel本身只支持256色，无法显示web上的底色，所以我修改了只显示蓝色的border，底色一律为白。 附件中rar里面是web的CSS文件、Excel的生成文件和jpivot的图表生成部分代码，感兴趣的朋友各取所需吧

我在用Jpivot的时候,发现用mondrian是影响取数性能其中的一个瓶颈........ 经研究.....我们自己修改了jpivot和wcf的一些代码来适应我们自己的项目.........以下是我做的一些修改.....想听听大家的意见 1.脱离mondrian.直接写dll的方式取数,然后生成XML数据 .我发现脱离mondrian自己写了一个DLL去调用MSSQL 2000 的OLAP,数度很快........... 2 .修改界面的显示方式 上面也说道.Jpivot的界面一个不好看,二是用起来很不方便.比如取维度等的时候....一层一层的进去实在很麻烦.... a.修改取维度的方式 我们参照ms的做法 做成一个了一个树的取数,研究jpivot里面的代码.如果直接用jpivot的代码取数据十分慢.这样我自己通过AJAX和Jpivot结合,动态生成树的结构,然后在树上取维度的时候,直接通过鼠标托到选择维度textbox上.........依照条件生成相应MDX....显示数据..... b.修改数据显示的样式.和取维度,生成MDX分开了. 显示数据我用了另外一种方式显示.就是用Frame分为上下两层.....上下两层可以通过按钮扩大整个页面........ 3. 集成在自己的框架中 集成在自己的框架中,我个人觉得是比较麻烦的一件事情.一点小事没有搞好就很麻烦...因为我们是用JSF开发的.所以依照Jpivot....自己写了一些组件来辅助开发,我自己开发主要改成比较像ms 2000 的olap分析方法... 还未完成的需求 JFreeChar的功能还需要加强. 个人感觉:jpivot是很不错.可是不能一拿来就用..我发现好多人用jpivot都要修改好多东西....但是修改起来又比较麻烦....java,j2ee,xml ,xslt,javascript,taglib.....好多东西都要懂.....

This documentation is related to the displaytag 1.1.x releases.

The latest available release is 1.1.1

Displaytag 1.1 offers several enhancements over 1.0: the most notable news are support for partial lists and enhanced decorator APIs, but there is also a lot more. Be sure to read the migration guide for upgrading an existing application from displaytag 1.0. A full changelog is also available.

近在论证java领域的开源BI前端框架,把随手记得东西和大家分享下.
因为只看了几天，有没时间整理所以看起来比较乱，也不是很深入。

目前在java领域较常见的BI前端框架（商业智能项目）主要有以下几个Pentaho，spagoBi, OpenI, JASPER intelligence等开源框架。

 他们都有自己的强项和不足，下面简要介绍下：

轻量级的:

OpenI使用Mondrian和Jpivot框架，报表引擎是jasper report，数据挖掘接口是R-Project，

相对来说开发和学习比较简单，而且OpenI支持使用MS的数据仓库(xmla)，但是其国际化比较失败(中文乱码)，要深入改造。

 JASPER intelligence也是个轻型项目，对jasper report的支持最好，所以报表部分比较好。

 重量级的:

Pentaho，spagoBi是两个比较大的框架了，集成了相当多的开源项目，JfreeReport、Mondrian、Kettle、Weka基本都使用了。特别适合大型复杂项目的开发。

      Pentaho在中国使用的比较多，文档什么的也多一点。尤其值得一提的是网络上对他的中文支持做的相当好，很多志愿者翻译了它的文档。这给我们开发带来很大便利。

 

      Pentaho的模块工作流引擎、中心资源库、审计组件、报表设计工具、ETL工具、OLAP Server、多维展示、数据挖掘组件各种组建都有。

而且Pentaho得到了很大的投资，开发后劲很大，而且会有付费的官方发售版本。 

http://blog.csdn.net/dust_bug/archive/2006/09/18/1240753.aspx

这个是《Pentaho源代码阅读报告》，介绍Pentaho构架相当的全面。 

Pentaho的中文论坛在http://www.bipub.org/ 

Pentaho相对spagoBi来说功能较强，尤其是工作流一块做的相当不错。

官方站的demos在http://www.pentaho.com/products/demos/

 spagoBi功能也很强，尤其是最近发布的1。9版本，在http://spagobi.eng.it:8080/sbiportal/faces/public/exo（或http://spagobi.eng.it:8080/sbiportal）

的demos里展现了spagoBi很多功能。

 后记
这几款BI框架因为都是开源的前端框架，所以核心部分使用的还是一些开源项目，

Mondrian，Jpivot，JfreeReport，所以在使用的时候搭建合适的框架会占用项目很大一部分时间，但是一旦框架搭建好了，基本就可以象流水线一样出报表了。

但是期望在原始功能上添加性能功能是比较麻烦的，为了一个新加的功能可能需要相当长的时间来实现。

另外这些开源框架的权限管理都不怎么强，可能需要改造。

另外，全球话的问题也是问题。象OpenI完全不支持中文，必须改造。

我们都知道“瞎子摸象”的故事。不同的瞎子对大象的认识不同，因为他们只认识了自己摸到的地方。而企业如果要避免重犯这样的错误，那就离不开商务智能（BI）。专家认为，BI对于企业的重要性就像聪明才智对于个人的重要性。欧美企业的经验也证明，企业避免无知和一知半解危险的有效手段就是商务智能。商务智能旨在充分利用企业在日常经营过程中收集的大量数据和资料，并将它们转化为信息和知识来免除各种无知状态和瞎猜行为。   

支持BI的开源工具数量众多，但是大多数的工具都是偏重某方面的。例如，CloverETL偏重ETL，JPivot偏重多维分析展现，Mondrian是OLAP服务器。而Bee、Pentaho和SpagoBI等项目则针对商务智能问题提供了完整的解决方案。

ETL 工具

ETL开源工具主要包括CloverETL和Octupus等。

（1）CloverETL是一个Java的ETL框架，用来转换结构化的数据，支持多种字符集之间的转换（如ASCII、UTF-8和ISO-8859-1等）；支持JDBC，同时支持dBase和FoxPro数据文件；支持基于XML的转换描述。

(2)Octupus是一个基于Java的ETL工具，它也支持JDBC数据源和基于XML的转换定义。Octupus提供通用的方法进行数据转换，用户可以通过实现转换接口或者使用Jscript代码来定义转换流程。

OLAP服务器

(1)Lemur主要面向HOLAP，虽然采用C++编写，但是可以被其他语言的程序所调用。Lemur支持基本的操作，如切片、切块和旋转等基本操作。

(2)Mondrian面向ROLAP包含4层：表示层、计算层、聚集层、存储层。

● 表示层：指最终呈现在用户显示器上的以及与用户之间的交互，有许多方法来展现多维数据，包括数据透视表、饼、柱、线状图。

● 计算层：分析、验证、执行MDX查询。

● 聚集层：一个聚集指内存中一组计算值(cell)，这些值通过维列来限制。计算层发送单元请求，如果请求不在缓存中，或者不能通过旋转聚集导出的话，那么聚集层向存储层发送请求。聚合层是一个数据缓冲层，从数据库来的单元数据，聚合后提供给计算层。聚合层的主要作用是提高系统的性能。

● 存储层：提供聚集单元数据和维表的成员。包括三种需要存储的数据，分别是事实数据、聚集和维。

OLAP客户端

JPivot是JSP风格的标签库，用来支持OLAP表，使用户可以执行典型的OLAP操作，如切片、切块、上钻、下钻等。JPivot使用Mondrian服务器，分析结果可以导出为Excel或PDF文件格式。

数据库管理系统

主要的开源工具包括MonetDB、MySQL、MaxDB和PostgreSQL等。这些数据库都被设计用来支持BI环境。MySQL、MaxDB和PostgreSQL均支持单向的数据复制。BizGres项目的目的在于使PostgreSQL成为数据仓库和 BI的开源标准。BizGres为BI环境构建专用的完整数据库平台。

完整的BI开源解决方案

1.Pentaho 公司的Pentaho BI 平台

它是一个以流程为中心的、面向解决方案的框架，具有商务智能组件。BI 平台是以流程为中心的，其中枢控制器是一个工作流引擎。工作流引擎使用流程定义来定义在 BI 平台上执行的商务智能流程。流程可以很容易被定制，也可以添加新的流程。BI 平台包含组件和报表，用以分析这些流程的性能。BI 平台是面向解决方案的，平台的操作是定义在流程定义和指定每个活动的 action 文档里。这些流程和操作共同定义了一个商务智能问题的解决方案。这个 BI 解决方案可以很容易地集成到平台外部的商业流程。一个解决方案的定义可以包含任意数量的流程和操作。

BI平台包括一个 BI 框架、BI 组件、一个 BI 工作台和桌面收件箱。BI 工作台是一套设计和管理工具，集成到Eclipse环境。这些工具允许商业分析人员或开发人员创建报表、仪表盘、分析模型、商业规则和 BI 流程。Pentaho BI 平台构建于服务器、引擎和组件的基础之上，包括J2EE 服务器、安全与权限控制、portal、工作流、规则引擎、图表、协作、内容管理、数据集成、多维分析和系统建模等功能。这些组件的大部分是基于标准的，可使用其他产品替换之。

2.ObjectWeb

该项目近日发布了SpagoBi 1.8版本。SpagoBi 是一款基于Mondrain+JProvit的BI方案，能够通过OpenLaszlo产生实时报表，为商务智能项目提供了一个完整开源的解决方案，它涵盖了一个BI系统所有方面的功能，包括：数据挖掘、查询、分析、报告、Dashboard仪表板等等。SpagoBI使用核心系统与功能模块集成的架构，这样在确保平台稳定性与协调性的基础上又保证了系统具有很强的扩展能力。用户无需使用SpagoBI的所有模块，而是可以只利用其中的一些模块。

SpagoBI使用了许多已有的开源软件，如Spago和Spagosi等。因此，SpagoBI集成了 Spago的特征和技术特点，使用它们管理商务智能对象，如报表、OLAP分析、仪表盘、记分卡以及数据挖掘模型等。SpagoBI支持BI系统的监控管理，包括商务智能对象的控制、校验、认证和分配流程。SpagoBI采用Portalet技术将所有的BI对象发布到终端用户，因此BI对象就可以集成到为特定的企业需求而已经选择好的Portal系统中去。

3.Bee项目

该项目是一套支持商务智能项目实施的工具套件，包括ETL工具和OLAP 服务器。Bee的ETL工具使用基于Perl的BEI，通过界面描述流程，以XML形式进行存储。用户必须对转换过程进行编码。Bee的ROLAP 服务器保证多通SQL 生成和强有力的高速缓存管理(使用MySQL数据库管理系统)。ROLAP服务器通过SOAP应用接口提供丰富的客户应用。Web Portal作为主要的用户接口，通过Web浏览器进行报表设计、展示和管理控制，分析结果可以以Excel、PDF、PNG、PowerPoint、 text和XML等多种形式导出。

Bee项目的特点在于：

● 简单快捷的数据访问；

● 支持预先定义报表和实时查询；

● 通过拖拽方式轻松实现报表定制；

● 完整报表的轻松控制；

● 以表和图进行高质量的数据展示。

java /zongfeng 发表于2005-01-21, 23:05

在xml应用中，经常将一些URL信息作为xml数据存储，其中URL参数有可能包含有中文字符。
当使用dom对xml数据进行解析时，可以对中文字符进行编码。
但如果只使用xslt来显示xml数据时(data.xml+data.xsl)，发现此时的URL会出现编码错误.
即使指定编码类型(encoding="gb2312"),依然会出现同样的问题.
测试发现：是IE的缓存机制问题，IE仍会把新的页面(所链接的URL)的MIME内容类型默认为text/xml

解决方法：
1.指定输出文档类型为xml文档  (example:data.xsl)
 <xsl:output method="xml"  encoding="gb2312" media-type="text/xml" />
2.在新的窗口打开，给联接增加属性,指明目标窗口为其他窗口  (example:data2.xsl)
 <xsl:attribute name="target">_blank</xsl:attribute>

examples:

/*** data.xml ***/

<?xml version="1.0" encoding="gb2312"?>
<?xml-stylesheet type="text/xsl" href="data.xsl"?>
<root>
 <search>
  <url>http://www.google.com/search?q=</url>
  <word>xml数据</word>
 </search>
 <search>
  <url>http://www1.baidu.com/baidu?word=</url>
  <word>xml数据</word>
 </search>
 <search>
  <url>http://www.google.com/search?q=</url>
  <word>极限编程(xp)</word>
 </search>
 <search>
  <url>http://www1.baidu.com/baidu?word=</url>
  <word>极限编程(xp)</word>
 </search>
</root>

/*** data.xsl ***/

<?xml version="1.0" encoding="gb2312"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!-- 去掉下面一句,将出现错误 -->
<xsl:output method="xml"  encoding="gb2312" media-type="text/xml" />

<xsl:template match="/">
 <xsl:apply-templates /> 
</xsl:template>

<xsl:template match="search">
 <xsl:element name="a">
  <xsl:attribute name="href"><xsl:value-of select="url" /><xsl:value-of select="word" /></xsl:attribute>
  <xsl:value-of select="word" />
 </xsl:element>
 <br />
</xsl:template>

</xsl:stylesheet>

/*** data2.xsl ***/

<?xml version="1.0" encoding="gb2312"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">
 <xsl:apply-templates /> 
</xsl:template>

<xsl:template match="search">
 <xsl:element name="a">
  <xsl:attribute name="href"><xsl:value-of select="url" /><xsl:value-of select="word" /></xsl:attribute>
  <!-- 去掉下面一句,将出现错误 -->
  <xsl:attribute name="target">_blank</xsl:attribute>
  <xsl:value-of select="word" />
 </xsl:element>
 <br />
</xsl:template>

</xsl:stylesheet>