Business Objects 以及reporting service报表点滴v20100519--学习笔记

看来图片显示不出来，可从此处下载旧版word文档。因为最近还上传不上。

http://download.csdn.net/source/1902006 

 

 

也可试试附件图片。

 

Ver20100519

 

BO

BO入门及笔记

主要包括用designer构建universe，在webi ( Web Intelligence Rich Client )中使用universe构建报表。

目前使用的版本是BusinessObjects XI 3.1 -- BusinessObjects Edge Series 。

 

主要与Universe相关

关于measure

在object的属性定义中有个qualification属性的设置，可以设置为 dimension , measure , detail 中的某一项。这里需要对measure提一点的是，紧跟着会有一个”choose how this measure will be projected when aggregated”的设置，这个设置的用途目前发现是在webi的报表中，如果对query取出来的数据再进行聚集计算，这个设置是默认的聚集计算方式。

对于measure的再认识，是可以用来且一般是用来作计算的，而不必非要去做聚集计算……

对于measure的再再认识，主要是BO中比如webi的图表中的一些字段指定要用measure类型，其它诸如dimension的还不能拖到指定measure的位置使用。其实这个分类的设计挺蹩脚的，因为有时一个列可以具有多个BO中的类别，比如像日期类型即可做维度又可作计量。…….

 

Measure的建议用法，（A）一般是数值类型的列或普通计算列应该设置为measure类型并且不要默认聚集函数，（B）而那种已经调用聚集计算函数得到的列默认就是measure类型但不要默认聚集函数。（C）要进一步做聚集计算可以在webi中调相应函数来做。（A）是由于webi中的图表等处必须要measure类型，（B）是防止使用隐藏列（由于BO在显示的维度少于取出的维度时会找默认聚集函数做计算），目前BO的隐藏列的做法很不正规。

这里会费点事的地方是会改Universe对object的默认设置。省事的是不必设置隐藏列，而且如果有无默认聚集计算函数的measure类型的object和有默认聚集计算函数的的object在同一个表格里时，BO也就不会做聚集计算了，从而有一定的容错性，可以防止部分列的默认聚集计算函数被误改之后还能保持报表显示正确。

原则是，尽量显式去实现计算，防止对BO工具不熟看不到一些隐式信息而看不懂报表是如何实现的或做了什么样的默认计算。

(另外，想利用measure的默认计算函数省点事的，还不太可能，比如在图表中需要显示measure列的标题时，基本还得定义一个variable以利用其名称作为标题，此时再给此variable显式定义计算方式并不多费时间。)

 

由于BO中一些特殊性。从本义上看，Measure是表示维度的度量特性，而一般是数值类型的列都是用于度量的，这些列从理论上来说应该设置为measure类型。在实际使用中，在Universe中把数值列拖为对象时，默认是dimension类型，虽然用于表格不出什么问题，但图表上及其它某些地方一定要求是measure类型，从而必须改默认类型。另一方面，为了避免BO在显示的维度少于取出的维度时默认做聚集计算，而不能直接显示明细行，虽然可以加隐藏列避免，但是还是把默认的聚集函数设置为无比较好，要想进一步做任何聚集计算可以在webi上调用聚集计算函数实现。

 

 

 

 

 

 

 

关于lov ( list of values )

看来每个（dimension和detail类型的）object都有自己默认的lov，在object的位于properties选项卡的属性页上，点击 associate a list of values 框中的edit按钮，可以从弹出的query panel右上的result objects框中的内容可以看到。也可以在这里编辑。

使用object的lov目前知道是在@prompt （不管是在Universe中定义还是在webi中定义）函数中使用，使用写代码的方式可以参考@prompt函数的定义，在webi中可以有界面编辑的方式。在webi中run query时可以在弹出的prompts界面上看到最终使用界面。

 

一个应用是从id与name的列表清单中根据name选择，再使用相应的id的值。这时需要：先在Universe设计中对这个id object的lov进行设置，找到lov的编辑界面，默认只在右上的result objects框中有本id object，然后拖一个name object过去（必要时还可设置下面的条件过滤），注意需要拖到id object的右边，保存并export这个Universe。然后在webi报表中对这个id object作prompt过滤即可看到。下面有两个截图可以参考。

 

 

 

Lov提供的list还可以事先根据condition过滤，但是condition支持的表达式很有限，基本只支持只带一个操作符的表达式，虽然能支持Prompt的变量，也一般稍微复杂一点就用不上了。而得使用Derived Table之类的了。

 

 

关于cascade lov

创建与使用：在（designer编辑）Universe中，从ToolsàList of Values…àcreate cascading lists of values菜单项进去。然后把左边的一些有层次结构的object弄到右边来，最后点Generate LOVs的按钮生成。而点击完按钮也就生成好了，点击菜单项“Edit a list of values…”进入编辑界面其实很难看到已经生成的有层次结构的cascade lov，很不直观，选中编辑界面中某个曾设置过cascade lov的object，点Edit按钮，可以在弹出的query panel界面的右下部看到多了一个条件。这个编辑界面也可以从object属性的编辑lov的界面进入。使用时像普通lov那样在webi报表中对层次结构中的某object作prompt过滤，在run query时即可看到有层次结构的数据供选择。

几点说明：如果选择的有层次结构的objects中有已定义的lov的话，则这些lov会被cascade lov覆盖。然后可以在普通编辑lov的界面上再补上定义。

还要注意一点，生成cascade lov后在下层object的lov的编辑界面上能够看到在conditions中有一个条件，但是如果不做生成cascade lov而直接添加条件，是不能被当作cascade lov处理的。

如果选择的有层次结构的objects都只是id的话，没作特殊处理只能看到一些id，要显示name需要在普通编辑lov的界面上把name object拖上去。这样可以避免name的objects来作层次结构而导致可能的重名问题。

一些相关截图如下：

 

 

 

Lov与Prompt

在prompt小节介绍。

 

Lov的相关问题

如果一个object，删掉了select中的东西，默认的lov也有问题，需要重新拖拉一下。

Derived Tables

Derived Tables是自写select sql的方式，应该是最灵活的了。不过还有一些问题，比如里面不能有order by语句，不能预排序。从而对多列先排序，再取top行的效果目前没法支持。

另外，一个Derived Table还可以被另一个Derived Table使用。

 

在Universe中复制粘贴要注意的

注意有些不能完全复制，比如object的lov的定义就不能被复制。

 

对于Universe文件的复制的注意事项

由于在文件系统的Universe文件与在cms系统里的Universe数据有某种对应关系，单纯复制文件系统的Universe文件，还是对应同一个cms系统里的Universe数据。要想复制得到完全独立的另一份Universe文件，还需要用designer打开Universe并在FileàParameters界面上改Name属性，而且最好与文件名同名。不过，又发现另外一种可能更保险的方式。

（先注意做必要的备份）Designer打开一个Universe中，在File