biee报表开发总结

biee报表开发总结（一）当BI项目已经在essbase中搭建好框架之后，接着就要通过biee制作各种报表来展示BI的成果了。

BIEE报表开发能否成功的关键就在于初期的设计。

首先你必须明确你的需求，你开发的报表是给哪些人使用的，他们会如何使用，比如他们一般会有些什么输入，他们希望产生什么样的输出以及他们可能会做什么样的下钻动作。

一张报表往往只是给一类人使用的，你必须精心地为他们挑选合适的维度以及初始粒度。

所以同样的查询内容往往需要做好几张报表适合不同维度不同方式的数据查看（用下钻的方式可以通过汇总数据查询到详细数据，但是效率不高，如果已有足够的信息可以直接查到详细数据则直接显示详细数据）。

这样做可以减少每次查询使用到得维度，从而提高查询效率。

一般在一张仪表盘页中只放一张报表（汇总报表除外）。

一组报表一般由一张汇总报表（给领导查看）和几张明细查阅报表组成，汇总报表中包含各种图表，初始粒度大，同时支持很深的下钻，明细报表针对某个用途提供合适的查询方式，一般不放图表。

维度是由请求字段控制的，字段越多查询越慢，所以请求字段不能过多，尤其是大的维度（我遇到过成员好几千的维度，而且层次很少）不能太多，除非已经在筛选器中进行控制，最好不要直接添加时间字段，而使用全局筛选器来控制时间。

相反请求提示和相应的筛选器越多查询效率就越高，所以请求提示和筛选器可以多一些（这样还可以提供便捷的访问），请求提示使用什么输入方式也是需要考虑的问题。

关于使用表还是数据透视表，两者各有利弊。

表因为其结构就是请求字段的结构，所以可操作性强一些，可以实现很多数据透视表无法实现的功能（仪表盘排序，条件样式等），但是数据透视表在表现能力上优于表，尤其是维度较多的情况，可以通过一些高级的操作来改善数据透视表的功能（如修改saw脚本）。

总体来说BIEE报表的设计要控制好以下3点：1、汇总和明细分开；2、控制各种不同的查询路径；3、考虑查询效率。

biee报表开发总结（二）因为我做的报表的数据源是essbase多维数据库，所以在制作报表时不需要在administration tool当中添加维度和度量。

只要直接导入数据源，然后做两次拖曳就可以了。

但是很不幸的是BIEE其实并没有提供对essbase很好的支持，很多功能都无法实现，或需要调整之后才能实现。

在将文件夹从物理层拖到逻辑层之后，可以看到多维数据库的逻辑结构，但是展开的时候有些让人不知所云，因为biee并不使用essbase大纲中的名称，而是根据维度层次来命名的。

需要注意的是每个维度实际是从第2层(Gen2)开始的(因为essbase大纲中的实际维度也是从第2层开始算起，第0层是大纲的根，第1层是维度的根),之后的层次可以看到被标为蓝色，这类似于关系型的雪花模型。

所以在将文件夹从逻辑层拖到展现层之后就可以把第0层和第1层删了。

维度的每一层只有一个key，它到底是维度值还是它的别名呢？答案是别名，而且我到目前为止还没有发现显示维度值的方法(可能是BIEE不支持)。

接着修改一下维度和度量的标签就可以在answer里面使用了。

但是这样还是不够的，当使用到聚合的时候就会出现“发现外部聚合集”的错误，原因是BIEE在导入essbase的时候，默认将度量的聚合属性设置为外部聚合。

只要将外部聚合改为正确的度量即可，注意在物理层和逻辑层都要改，另外所有度量都要指定一种聚合方式，不能为none。

biee报表开发总结（三）在answers中的开发难点就在于设计，我在(一)中已经介绍了经验。

但是显然不可能一开始就设计得十分完美，有的时候会遇到功能实现不了或者效率太低，报表根本刷不出来，这时要么修改原先的设计，要么想办法解决问题。

关于如何提高效率，首先是优化查询。

在BIEE当中，有趣的一点是它首先根据你的设计生成一条SQL查询语句，然后如果判断出数据源是多维数据库，则再将SQL语句在后台转化为MDX语句去执行。

转化的逻辑大致是，select子句中放查询目标集(对应于MDX中的select 字句，但是没有行列之分)，from字句中放cube，where字句中定义如何进行切片。

所以在设计时尽量控制请求字段(对应select字句)中的维度字段，不需要的维度不要添加，尤其是大维度，而筛选器(对应where字句)则尽可能的多，这样切片可以切得小一些。

另外查询的逻辑不要太复杂，不要使用嵌套查询(筛选器不要使用“根据其他请求结果”)。

如果这样还不行，就只能优化数据源了，对于essbase，可以考虑将一些复杂的动态计算转为预先计算后存储(虽然这样做很可能会导致占用的空间增长好几倍...)，可以大大提高效率。

在BIEE中表的样式控制要比数据透视表灵活得多，基本的样式都是可控的，所以能用表的时候就尽量用表。

关于如何设置样式，由于比较繁杂而且在(一)中也介绍了一些经验，所以这里就不一一介绍了，比较重要的就是条件样式(只用表能用)，可以灵活地控制显示样式，另外就是列的隐藏，可以控制哪些列在表中不显示。

BIEE的访问控制是比较灵活的，可以使用单独的链接，也可以对标题设链接，还可以对值设链接，并可以控制是否用于下钻(在列的交互控制当中设置搜索或链接)。

BIEE最神奇的就是筛选器中的提示选项，选了这个选项不仅可以使用提示中的选择还可以用于链接的值传递。

如果一个请求的字段的筛选器使用提示，则通过值链接被连接过来的时候，该字段就会被筛选为进行链接的那个值。

另外使用提示默认是所有值，所以可以灵活的控制提示字段，比如同一个请求在不同地方使用时，需要的查询条件可能不同，这时可以通过请求提示来控制查询条件，此时就必须将所有使用到的查询条件字段加一个使用请求的筛选器。

不过在awnser中提示筛选器是不会被使用的，如果不使用筛选器就会导致查询过慢的话，建议在设计报表时先指定一个筛选值，设计完成后再将筛选器的筛选方式改为请求。

对于实在无法实现的功能，最后一条路就是修改saw脚本了，但是有关BIEE的saw脚本的文档实在太少...不过通过查看saw脚本倒是可以分析出别人的报表的某些功能是怎么实现的。

实施上saw脚本包含了一个请求的一切，包括显示样式和SQL查询，所以如果要备份或者拷贝一个请求，最简单的方法就是把saw脚本拷贝下来。

如果你想直接修改SQL查询语句，应该先看一下SQL查询语句的各个字句存储在saw脚本中的什么位置，然后对saw 脚本修改，如果直接改下面的SQL框，点了设置SQL的结果是，它产生一个最简单的SQL 语句(没有任何附加内容)，而且把原来你的一切设置都重新初始化(要是你之前没备份的化，赶紧退出重来吧，千万不要保存了...)另外介绍一些经验。

为了防止字段过多导致一格内无法一行显示，可以在格式化视图的附加格式中指定一个很大的宽度，然后选择单元格向左对齐。

如果只想修改请求条件的化，最好不要直接双击进入，而是先打开所在的文件夹，然后在面板中选择修改条件，这样可以避免一次不必要的查询。

查询如果异常中断，即使你在后台取消了请求，甚至删除会话，essbase 仍然会继续执行，如果你想进入同一个请求就会报错，这时你能做的就是等待，等essbase 执行完毕才能继续使用(这也是BIEE与essbase不兼容的一个表现，它导致了BIEE的不稳定，所以要尽量避免没有筛选控制的查询)。

biee报表开发总结（四）本文主要讲biee中answers和dashboard的开发步骤。

在administrator tool搭建好框架之后，接着通过在浏览器中操作的answers和dashboard开发最后的报表显示。

首先要做的是添加全局筛选器。

对每一个维度都设定一个全局筛选器，每个层次都设定为请求。

接着开发请求。

按请求在报表中的使用顺序一个一个开发请求。

先选择合适的请求字段，再添加全局筛选器，接着添加测试筛选条件（因为全局筛选器中的筛选条件都是请求，所以不会在answers中发挥作用，所以不会和测试筛选条件冲突），然后在表中查看结果，如果要用表显示则调整字段的顺序。

如果不报错且数据无误，则返回请求条件面板，添加一些需要计算的字段(这些字段可以通过加入一个原始字段然后用编辑公式输入计算表达式产生)，设置标题和值的样式，并添加筛选器。

然后在结果面板中开发需要用到的数据透视表或图表，同样需要设置字段顺序和显示样式和一些其他小功能（比如计算和排序）。

然后在组合布局中调整布局，并调整格式化视图中的值。

最后回到条件面板，在列格式中设置交互即链接（建议不要现在做，因为链接最好链接到仪表盘，不过如果链接的内容很简单也可以这里做）。

然后开发提示。

提示要考虑到所有可能的筛选，提示可以尽量多（就像筛选要尽量多），但是必须要关联到筛选器。

提示的输入方式很重要，必须要根据实际需求精心设计。

提示之间有关联的要勾选约束，这样可以限制提示的内容。

但是biee的约束很恶心，你不能限定某几个提示有约束，一旦勾选了约束，就会和所有约束关联，也就是说如果其他任何一个提示被输入错误的值，它就会报错。

对提示进行分组以防止一行中提示太多。

提示设计完成后一定要预览一下，看看效果如何，尤其是约束关系。

这时可以将所有的测试筛选器删除了。

然后就可以再dashboard上开发了。

首先建一个仪表盘，然后添加提示和请求，不同的请求放在不同的部分，但是因为部分只能垂直排列，所以如果要水平排列则必须放在同一个部分，并设置排列方式为水平排列，排版的时候要注意，各部分的附加格式的宽度必须一致，否则会出现排版错误。

最后就是甚至权限了，这个很简单，这里不介绍了。

整个开发过程当然不可能按上面的步骤一帆风顺地做下来，在开发过程中经常会遇到需求变更和一些意外的结果，所以整个开发过程应该是一个循环迭代的过程，不断地完善，最后使得开发出来的报表十分好用而且能够从各方面反映这个报表应该反映的内容。