Cognos-ReportNet 的聚合函数属性和函数应用

xiaoerp

Cognos-ReportNet 的聚合函数属性和函数应用
在使用Cognos的ReportNet的时候，一个很重要的功能是设置聚合函数属性。
聚合函数属性用得比较多的是“合计”和“已计算”属性。
这些属性最终是在报表展示的时候发挥作用的，这点可以通过比较运行查询和运行报表的情况来证明。
比如在开发过程中经常会遇到要将一个整体的数据集从纵向到横向进行展开。比如，一个数据集包括：




最后报表展示的时候你可能希望得到的样式是：




这种情况可以通过交叉表来自动完成，前提是成绩字段上要设置“合计”的聚合函数属性。它告诉ReportNet在展示报表的时候遇到行和列的值都一样的若干条记录的时候的处理方式。试试不使用交叉表，而使用列表的方式实现该需求会对这个属性了解得更加深刻。用列表的时候是利用CASE语句分离各个字段来实现的，通过比较查询的和报表的结果可能更容易想象这个属性的工作。

而一些自建的计算字段一般聚合属性都设置为“已计算”，这样才能得到计算的结果。实际开发中发现“已计算”的优先级是比较低的，Cognos认为你已经定义好了计算公式，可以放到最后进行计算。所以，如果这个计算字段来自于列表中其他字段的计算结果，而这些被用到的字段上有合计的话，这个计算的结果会是合计之后的值进行的计算。

当然也会有聚合属性的设置和记录的内容相冲突而导致失效的情况。这只能视实际情况进行调整。

--------------------

Cognos 对很多东西进行了封装，所以很多地方让你觉得是既强大又烦人的……这是方便和灵活这对矛盾不可调和的结果。。。

对数据集的内容进行加工形成报表展示需要的形式不可避免的要用到Cognos提供的函数。随着应用的不同，Cognos的函数还是很值得挖掘的，也应该去了解。因为Cognos不会认那个函数列表之外的函数。而且这些函数在使用上也是有限制的，特别是在过滤器里使用函数的时候会收到很多的限制。

除了普通的运算函数外，汇总函数的使用也是比较多的，比如你可能会经常需要计算百分比什么的，那你可能需要对某个字段进行求和，然后在一一计算百分比。

函数列表中的“汇总函数”和“成员函数”虽然大多关键字是一样的，但是语法和实用范围是有很大区别的。一般情况下，你可以使用两种汇总函数的语法和成员函数的语法达到相同的结果，虽然他们的实现机制可能是不同的。这两个部分从名字上可以有一个大致的区分，一个是用于整体数据集的，一个是用于数据集成员的。也可以从语法上试着去区分它们，比如total函数，在“汇总函数”中基本语法是total(<**> for <**> )，在“成员函数”中是total(<**> within set <**>)，也就是说在用后者的语法可以指定更详细的作用范围，一个set的范围。

当然，既然分开而存在就肯定有不交叉的作用地方。比如，你有一个聚合属性为“已计算”的字段A，这个字段可能是来自其他两个字段的比率，然后你可能想对这个A字段使用函数得到字段C，比如说汇总（total），如果你使用total（A for report）或其他的“汇总函数”中total的语法，你可能会发现结果为0，也就是说这个汇总没有使用你想要的A字段的值，而使用“成员函数”的语法你却可以获得正确的结果，比如total(A within set B)，报表会在聚合范围内，也就是B，对A进行一个total。产生这种结果和Cognos底层的机制和解析优先级有关系，笔者也没有机会能了解到……（使用工具就是这样。。。）。有些时候这种不对使用者开放的机制会导致你的方案功亏一篑！~~比如说上文中的字段C，这个字段可能是要通过CASE语句处理不同情况的，例如：case B = **** then C …… 这时候你运行查询会发现Cognos报错，这应该是语句中的判断条件和C字段指定了within set冲突导致的，就算判断条件中用到的和C字段中用到的字段不是同一个，也可能会产生一样的问题，所以我认为，这应该是由实现的逻辑带来的问题。

如果你的开发设计像上面提到的那样，一步步走向胡同深处，我劝你最好尽早停下来思考一下，因为有时候这并不是唯一的做法，像我就是想躲避麻烦，所以一步步变得复杂。。。最后懒得弄了，回来麻烦那么一下，多弄个查询就了事了

该贴已经同步到 xiaoerp的微博