cognos计划表篇一：coGnoS报表开发流程报表开发a）模块概述B）处理流程和处理逻辑1)处理流程图B)处理逻辑如图：基本的处理流程有三个部分，元数据准备、模型设计、报表设计。

针对本系统的情况，报表的制作分为三类，从cUBE出报表、直接从事实表出报表、从指标出报表。

从制作方式来讲其中直接从事实表出报表、从指标出报表的方法是完全相同的。

首先形成元数据模型描述。

将数据库结构描述成需要的结构，然后将元数据发布到cognos服务器上。

同时cognos的oLaP转换工具通过元数据描述可以将数据库中数据按照业务主题的维度、指标等因素，转换成文件型的多维立方体。

这些多维立方体也作为数据源，通过元数据模型进行描述，发布到cognos服务器上。

然后通过浏览器访问发布在门户上的元数据，并在其基础上制作报表。

详细过程：1.元数据准备本阶段主要准备cognos与数据库之间连接的语义层，封装数据库底层表和字段，建立表连接，为后续开发人员和最终用户提供一个贴合报表需求的数据库结构视图，设计要点是结构清晰、效率优化。

本部分工作主要是使用cognosFrameworkmanager。

对于三种报表均需要这一步骤。

其主要流程有：a.添加数据源，导入物理层数据结构。

b.定义表连接关系。

c.在物理层的基础上创建表示层QUERY，这些QUERY的设计基于如何更方便在后面的步骤中制作报表，并且要充分考虑性能的优化。

如果是为从cUBE出报表的QUERY，需要按照该多维模型的需要去设计QUERY。

d.发布元数据。

如果是为从cUBE出报表的QUERY，可以发布为iQd的格式，或直接使用。

2.模型设计本阶段的主要工作是根据需求分析来规划oLaP应用主题，然后根据oLaP应用主题建立数据模型，对于出报表使用的模型，基本的设计思路就是使报表的行列科目可以用模型的维度中的类别或者类别的计算来描述。

这部分工作主要是使用cognosTransfomer来完成，开发人员在cognosTransformer提供的图形化设计界面中设计a.导入iQd数据源。

进行必要的加工。

b.通过拖拽等方式设计维度、层次和指标。

c.定义模型中的计算，包括维度计算、指标计算等。

d.添加cUBE，定义cUBE的设置。

e.检查问题，并采用少量数据验证数据集市设计，当各方面满足需求后，该阶段即告完成。

在这一步中，实际上是通过图形化的界面将设计阶段涉及好的多维模型物理化。

例如下面的模型结构：3.报表开发前端的使用包括分析、查询、报表三类，元数据和cUBE发布后，分析和查询可以直接使用。

报表开发包含两类报表：直接从数据库中取得数据的报表，包括从指标库出的报表，以及从cognosPowercubes数据集市中取得数据的oLaP报表。

选择使用何种类型来制作报表时要综合考虑，对于明细查询型的报表，比如最大十家,以及客户信息统计，包括人行报表（实际上是对指标库的查询）等，采用直接从数据库中取得数据的报表比较合适，效率也不会有问题。

对于交叉统计型的报标，从cUBE出就更为合适，不仅制作过程方便，而且效率优于数据库处理。

cognos的报表开发过程不需要编写脚本和程序，仅需在报表设计界面中进行鼠标拖拽式设计，即可实现复杂的报表，如下图所示：通过报表开发，可以形成各种面向用户的丰富的展现内容。

如仪表盘报表，自动综合报告等。

基本的步骤有：a.选择元数据。

b.拖拽报表。

c.定义报表样式，表头、数据格式等。

d.添加提示用过滤条件。

e.对于复杂的报表，还需要进行添加计算、添加汇总、点定义、多查询设置、钻取等。

在这一步骤，对于直接从数据库中取得数据的报表，包括从指标库出的报表，和从cognosPowercubes数据集市中取得数据的oLaP报表的开发过程时没有太大区别的。

最大的不同是开发使用的源数据的结构不同，一种是表、字段的数据库结构，一种是oLaP的多维结构。

篇二：cognos+SdK+小结三(权限开发小例子)cognos应用小例子（权限控制）1.1.概述用户角色权限这部分主要可以实现1.第三方认证2.新建角色；新建组织；给角色添加用户、组织、角色；给组织添加用户、组织；读取当前角色(组织)已有的成员，给成员设置读写遍历等权限3.给Foler，package，rs，as，qs报表设置权限，比如山东小麦专家和山东大豆专家看到不同的文件夹报表等；这块和cognos在页面上设置权限的功能一样；不过是通过SdK自己包装了，为了给大家有个直观的产品集成的概念J2EE架构+cognos8.4环境下做了一个小功能demo，后面有效果图简单展示；1.2.demo效果为了给大家有个直观的产品集成的概念做了一个小小的功能demo，下面是几张截图效果：不同登录用户看到不用的目录内容，点击查看，如果是报表，弹出窗口，看到报表的运行结果页面，如果是文件夹就进入下级目录，另外有一个此用户可以看到的这个文件夹包含的报表数量的统计。

权限设置后，admin用户能看到的分配权限以后，以user1用户登录，看到：以user2用户登录，看到：和cognos页面分配的效果一致；设置过程（和cognos设置过程基本一样）：在此页面点击设置：点击“添加”：选择要添加角色或者组织的命名空间，在下面页面中点选“新增”就把此角色或组织添加到这个资源上，默认有读、遍历、执行权限；添加用户也一样，点击“jn”命名空间可以看到组织机构成员等类型，添加第三方用户如下图：篇三：iBmcognosBi最佳实践_报表设计高级提示和提示性能调优iBmcognosBi最佳实践:报表设计高级提示和提示性能调优1简介1.1目的本文档旨在向报表创建者展示如何处理第一个提示页面性能低下的问题。

1.2适用范围这里的信息只适用于iBmcognos8.2Bi。

2第一个提示页面的性能当用户运行包含多个复杂查询的报表时，常常需要等待很长时间才会看到第一个提示页面出现。

例如，在一个客户场景中，报表用了40秒才显示出第一个提示页面。

可以通过两方面的努力改进第一个提示页面的性能：1)减少提示调节（promptreconciliation）的时间2)减少为提示控件获取数据的时间3提示调节3.1什么是提示调节？提示调节确保参数定义与参数的用法匹配。

在筛选和计算中定义参数。

在提示中使用定义好的参数。

参数定义包含几个关键项：?基数–可以提供给参数的输入值的数量。

?离散性–决定输入值是定义单一值，还是定义一个值范围。

?可选性–决定参数在筛选或计算的上下文中是必需的，还是可选的。

?数据类型–为了与引用的其他数据项或常量匹配，在筛选或计算的上下文中期望的数据类型。

数据类型可以是numeric、date、Time、dateTime、interval、String或memberUniquename(mUn)。

3.1.1筛选表达式请考虑可选的筛选：[ordernumber]=?pordernumber?通过分析这个筛选，可以判断出参数pordernumber的一些性质：基数：单一值?等号表明只能使用单一值。

?使用多个值需要适当的操作符，比如“in”：[ordernumber]in?pordernumber?离散性：简单值?等号表明了这一点。

?值的范围需要适当的操作符，比如“in_range”：[ordernumber]in_range?pordernumber?o如果一个参数在多个上下文中使用，那么对于是范围值的参数，所有引用都必须是范围值。

可选性：可选的?这个筛选定义为可选的，所以参数也是可选的。

?参数也可以是必需的。

如果一个参数在多个上下文中使用，那么对于可选的参数，所有引用都必须是可选的。

数据类型：numeric?这个参数是数字，因为ordernumber数据项是数字。

现在，把参数的特性应用于引用它的提示。

这意味着，提示控件会体现参数的一部分特性，从而让提示控件与参数定义保持兼容。

如果在创建的提示页面中引用参数，会在运行时修改提示定义，以便与参数的基数、可选性和离散性匹配。

数据类型不匹配可能会导致运行时错误。

如果没有创建的提示页面，那么这些特性应用于生成的提示页面上的提示。

3.1.2数据项表达式与通过宏表达式定义的参数不同，在数据项表达式中使用的参数是必需的。

3.1.3宏表达式在宏表达式中定义的参数1可以是可选的或必需的，可以是单一值或多值。

请考虑宏表达式：#prompt(‘pordernumber’,‘integer’)#基数：单一值?prompt()宏函数只接受单一输入值。

?可以用prompt()定义多个值：#promptmany(‘pordernumber’,‘integer’)#离散性：简单值?提示宏总是简单值，而不是范围。

可选性：必需的?没有默认值（这个宏函数的第三个可选参数）表明了这一点。

?包含可选参数的示例如下：#prompt(‘pordernumber’,‘integer’,‘5’)#3.2提示调节如何影响性能？为了执行提示调节，iBmcognos8要检查查询，判断有哪些参数及其特性。

查询越大、越复杂，这个过程花费的时间越长。

在iBmcognos8.1中，一个包含200多个查询的客户报表需要超过40秒才能显示出第一个提示页面。

大多数时间花费在提示调节方面。

3.3在cognos8.2中如何改进提示调节？在iBmcognos8.2中通过三种方式改进提示调节：?更快的提示调节?用于提示调节调优的报表服务器属性?用于提示调节调优的查询属性3.4iBmcognos8.2中更快的提示调节首先，在iBmcognos8.2中提示调节过程已经得到优化，大大提高了速度。

与iBmcognos8.1相比，这个过程花费的时间减少了75%到90%。

例如，在iBmcognos8.2中客户示例报表的提示调节只花费了5秒，与iBmcognos8.1中的40多秒相比降低了80%。

只需迁移到iBmcognos8.2，就实现了80%的性能改进。

不需要采取其他措施。

3.5用于提示调节调优的报表服务器属性iBmcognos8.2为整个系统和具体报表的提示调节调优提供了三个相互关联的选项。

第一个选项是一个针对整个报表服务器启用的报表服务器高级属性：RSVP.PRomPT.REconciLiaTion。

这个属性有几个值：comPLETE-在显示第一个提示页面之前，调节所有查询。

这是默认设置，用来确保与以前版本的兼容性。

cHUnKEd–分批调节所有查询，直到调节了第一个提示页面所需的参数为止。

以不固定的次序处理查询。

可以用高级服务器属性RSVP.PRomPT.REconciLiaTion.cHUnKSizE修改cHUnK大小。

默认的cHUnK大小是5个查询。

GRoUPEd–按组调节查询，直到调节了第一个提示页面所需的参数为止。