Cognos报表展示的参数传递

如何调用已发布到Enterprise server的ppx报表（参数传递）

Cognos的内容一般作为网页中某一特定的帧来展现。我们可以在外部统一的用户交互界面中收集用户递交的查询条件（一般用JSP实现），在检查完用户输入的有效性之后，把这些参数按照Cognos约定的标准，以POST的方式传到某一帧中的Cognos的网管。Cognos网管就会把用户查询的结果返回到该帧中。

下面是一个接口调用的实例：
假设服务器名称为：servername
ppx报表发布到enterprise server之后在enterprise server的根目录下，名称为：testreport
如果我们要对这个报表进行访问，可通过如下url对报表进行调用：http://test/cognos/ cgi-bin/ppdscgi.exe?DC=R&E=%2Ftestreport
如果用户要求访问的是一个可动态分析的cube，那么相应的url为
http://test/cognos/ cgi-bin/ppdscgi.exe?DC=Q&E=%2Fcubename

其中：%2F是一个URL使用的转意符，它的原型是符号“\”。

如果报表或Cube是发布于一个文件夹test中的，那么相应的url为：

http://test/cognos/ cgi-bin/ppdscgi.exe?DC=R&E=%2Ftest%2Ftestreport



通过以上的接口可以访问到任意发布到Powerplay Enterprise Server的报表或Cube。如果要向报表或Cube传递过滤条件，可采用下面的调用标准。

例如在Enterprise Server发布有报表ICBC，该报表开放了四个传参接口（Years，Products，Locations，Channles）。用户可以选择向其中的某几个接口传参。

如果选择“Products”为“Outdoor Products”则调用

http://test/cognos/cgi-bin/ppdscgi.exe?DC=R&E=%2Ficbc&DM=Products&FC=0%09Outdoor%20Products&ZZ=X

其中&DM=Products //表示要过滤维度Products

&FC=0%09Outdoor%20Products //表示维度Products的过滤值



如果是过滤两个维度，例如过滤“Products”和“Locations”则调用

http://info/cognos/cgi-bin/ppdscgi.exe?DC=R&E=%2Ficbc&DM=Products%09Locations&FC=0%09Outdoor%20Products%091%09Europe&ZZ=X

其中&DM=Products%09Locations //维度间用%09分开

&FC=0%09Outdoor%20Products%091%09Europe //维度值从0开始标号



如果是过滤三个维度，例如过滤“Products”和“Locations”及“Channels”则调用

http://info/cognos/cgi-bin/ppdscgi.exe?DC=R&E=%2Ficbc2&DM=Products%09Locations%09Channels&FC=0%09Environmental%20Line%091%09Europe%092%09Independent&ZZ=X

其中&DM=Products%09Locations%09Channels //维度间用%09分开

&FC=0%09Outdoor%20Products%091%09Europe%092%09Independent

//维度值从0开始标号



在每条Url后添加&ZZ=X,表示参数传递结束。



注意：维度过滤值必须用该维度节点的code

Cognos小技巧1

1,机构中数据分级控制,
case
left (#"'"+$account.personalInfo.businessPhone+"'"# ,1)
when '0' then [ocrm_person].[RPTORGDIMEN].[CENTRE]
when '1' then [ocrm_person].[RPTORGDIMEN].[PROVINCE]
when '2' then [ocrm_person].[RPTORGDIMEN].[CITY]
when '3' then [ocrm_person].[RPTORGDIMEN].[BRANCHCODE]
when '4' then [ocrm_person].[RPTORGDIMEN].[NODE]
else #"'"+$account.personalInfo.email+"'"#
end = #"'"+$account.personalInfo.email+"'"#

2,Cognos外部链接登录格式
http://192.168.5.83:9300/p2pd/servlet/dispatch?CAMNamespace=default&CAMUsername=administrator&CAMPassword=123456

Cognos权限管理注意的地方

Cognos权限管理注意的地方

Everyone
This group represents all authenticated users and the Anonymous user account. The membership of this group is maintained by the product and cannot be viewed or altered.

You can use the Everyone group to set default security quickly. For example, to secure a report, you grant read, write, or execute permissions to the report for the Everyone group. After this security is in place, you can grant access to the report to other users, groups, or roles, and remove the group Everyone from the security policy for this report. Then, only users, groups, and roles that you specified have access granted to the report.

You can use the Everyone group to apply security during deployment , but you cannot deploy the group itself .

System Administrators
This is a special role. Members of this role are considered root users or super users. They may access and modify any object in the content store, regardless of any security policies set for the object. Only members of the System Administrators role can modify the membership of this role.

The System Administrators role cannot be empty. If you do not want to use System Administrators, you can create an empty group in the Cognos namespace or in your authentication provider, and add this group to the membership of the System Administrators role.

When this role is created during the content store initialization, the group Everyone is included in its membership. This means that all users have unrestricted access to the content store. Immediately after installing and configuring Cognos 8, you must modify the initial security settings for this role and remove the group Everyone from its membership .

You can deploy this role .

将everyone 从System administrator 删除,然后将everyone禁用!!!!

探讨数据仓库与商业智能需求与需求分析(转载)

探讨数据仓库与商业智能需求与需求分析

　　各位朋友，我是一名来自从事商业智能项目开发的一名一线技术工作者，我曾在这个领域从事过从程序员，系统分析员到项目经理多种岗位，从2002年开始，我亲身经历了多个不同规模的数据仓库与商业智能项目，经历了甲方和乙方的角色变换，我试图以一个一线bi从业者的体会，为众多朋友描绘出这个充满了激情与失落的bi需求的最直白的面目，以及结合自己的经验，试图从bi的本质观点(如何创造价值)出发，探讨"什么bi需求是有效的，怎么做有效的bi需求"这两个做bi需求不可回避，却又容易被淡忘的问题。并提出和阐述我认为做bi需求应该与发展企业价值链相结合思考的观点。

　　bi界内，有一句几乎每个bi实施人员都备感到无奈，却又不得不承认的话，客户真正的需求往往是从项目投产那一刻才真正开始，仿佛bi项目天生就注定是一场的吃力不讨好的恶梦，。

　　在决定bi实施成败与效果中，需求无疑是雷区最多的地方。对于bi项目而言，需求是个让人又爱又恨的怪圈。几乎所有bi项目都诞生自bi销售人员所描绘出的华丽前景，以及由此所激发出来的充满理想色彩和浪漫情怀的客户需求，是一个美妙的梦中情人；而在bi界众多周知的是，bi的需求又是一个最折磨人，最让人心力交瘁的顽皮孩子。

　　那么，究竟商业智能是一样什么样的东西呢，商业智能的需求为什么同时具备了可爱和可恨两种自相矛盾的特质呢，让我们先从认识商业智能开始。

　　第一章回 商业智能的来龙去脉

　　传统以来，计算机一直被俗称之为电脑，把计算机和智能划上了等号，然而，我相信在坐有计算机常识的人都明白，除了科学幻想外，我们日常实际工作和生活中使用的计算机其实是个傻瓜，他只会毫不变通地执行的预定的程序，所以如果说计算机有智能，程序是智能的核心，再进一步说，所谓的智能的核心就是用程序来演义的逻辑， 在这种以程序为核心的体系下，数据充其量只是程序的一个附属，如果用游客进公园的大门比喻成一套非常简单的程序系统，公园的大门和配套的验票人员是程序，数据是门票，用过一次就扔了，最多拿个废纸箩装起来，一般也不会再有什么作用了，这就是过往在林林总总的政府和企业的计算机系统中数据所遭受的普遍下场了。

　　附图描述信息化发展规律，从60年代计算机逐渐普及以来，计算机的应用领域无论在深度和广度都有了质的拓展，而从总体的应用水平来说，可以划分为以下三个阶段（如图1－1）：这三个阶段与不是用单纯的技术高低来划分的，而是从应用的影响层面来划分。

　　第一个阶段是基础信息化阶段，这个阶段从应用面来说，主要是解决数据处理电子化的问题，在这一阶段，机构内往往是一些数据处理工作量最大的部门首先采用了信息技术把手工数据工作电子化，如财务系统，计算机辅助设计系统，电子数据交换系统等等，实现了信息处理的电子自动化无论在人力投入和纸张损耗等方面无疑节约产生了具大的效益，可惜这些信息的关联面是非常有限的，甚至可以说离开了这些系统的主要用户，别人是看不懂这些数据的，而这些用户在企业中往往是少数的专业人士。

　　第二阶段是企业级信息化阶段，这一阶段政府机构与企业往往已经拥有了几个分别建设的业务处理系统，机构期望从总体角度建设高度集中的、或互相联接的综合业务管理系统，如mis，erp，oa等等，这个阶段的应用核心是通过实施一个企业级的应用系统实现企业的业务流程或者管理流程的信息流畅，以此来提高企业的运作效率，以实现流程的自动化。

　　第三阶段是目前的近几年刚起步的发展趋势，应该说也是现在很多企业完成了第二阶段的信息化建设后，所面临的下一步信息化该怎么走的问题，由于还没成为历史，所以我这里大胆提出我的定义，我认为，这个阶段应该是企业的战略价值信息化阶段，因为这个阶段的根本目标，是实现整个企业的系统思考(systems thinkings)能力，这个阶段的应用层面，应该说已经渗透到从企业管理到企业文化的方方面面，当然，这个阶段的形成与产生绝对是离不开前两个阶段所打下的信息化坚实的基础，本身这三个阶段也是承前启后,不可分割的，而我认为第三阶段对于企业发展更有深远的发展意义，我把企业形象地比喻一个人的话，第一阶段是针对手指的自动化，第二阶段是针对耳朵的自动化，第三阶段是针对大脑的自动化。

　　第三阶段正是商业智能走上历史舞台并且成为主角的时代，也是企业求生存求发展不得不走向商业智能的历史选择，这个选择的根源，我认为，不是技术的进步，当然不可否认，技术的进步创造了物质上的条件，然而从因果关系的动因角度来做说，企业选择商业智能的根本原因，是市场竞争的必然。

　　这样，我们不得不偏离一下主题，稍微看看现在市场的竞争给企业带来的压力，随着市场竞争的日益激烈，目前营销竞争方式已经从一个大众化营销阶段进入了一个差异化营销阶段，进而上升到一个价值链整合营销阶段，竞争从拼生产能力到拼服务能力，最终必然上升到拼决策能力，现在的企业一把手可能比历史上任何一个时期的皇帝还要难当，一则是现在企业内部组织机构的复杂性肯定超过100年前的封建帝国，生产环节，销售环节，财务环节，人力环节方方面面，缺一不可，协调一个企业的正常运作已经越来越需要精确化的管理，压缩管理成本已经是任何一位企业领导人都需要认真对待的问题，二则企业的外部环境瞬息万变，拜高度商业化所赐，市场的潮流和态势可能已经达到了一月或者数月一变的程度，一个判断的失误可能就会把企业带入覆灭的境地，在这种内外压力的夹攻中，一个领导的个人决策能力是不可能不达到人的极限，这个时候，企业的信息系统能做什么，当一个领导要了解能反映企业运行状态的一些重要的信息的时候，我们目前的企业的信息系统能迅速给出一个答案吗?

　　很遗憾，不能，也很幸运，就是因为不能，才有我今天这个报告的主题。

第二章回 什么是商业智能

　　越来越多企业已经认识到，数据是资产的重要组成部分，以前，企业可能把过期的数据看成是过期门票，随意抛弃，而当企业的领导要做出一个准确有力的决策的时候，终于发现，没有数据啊! 很多人说，不对啊，企业不是已经在计算机设备和软件上投入了大量的资金，做了很多业务系统了吗，不是有很多数据吗？ 为什么不能用呢，这个问题问得实在是太好了，我相信每个人都在问这个简单而其实是最深刻的问题，为什么我们的数据不能用!

　　过去数年里，几乎每一个企业都建立了自己的信息中心，收集和整理了大量的数据，但是这些数据又带来了始料不及的新问题，就是数量之大种类之浩瀚繁杂远远超过了可以控制和理解的范围，数据库变成了“数据监狱”，数据一进去就十有八九成了“囚犯”，而数据一旦过时，要么就被束之高阁，无情地被判了无期徒刑，要么就象碎成纸片的机要文件一样被销毁了。怎么让这些“数据囚犯”变成有价值的决策依据，进而成为有价值的生产要素，这就是商业智能的目的所在。

　　实际上，给商业智能一个完整的定义是很难的，但是，从商业智能的产生根源的角度而言，可以概括为：商业智能是用来实现数据向信息转变，信息向知识转变，知识向价值转变的这么一个过程，以及这个过程中所使用到的种种技术和工具。

　　由于商业智能是围绕着数据来做文章的，数据仓库也可以说是商业智能的核心环节，很多情况下，习惯性地，由于两者有如此密切的关系，所以在很多项目命名时，往往是把数据仓库和商业智能相提并论，有时这会给人一种很混淆的感觉。一般来说，上面所描述的是一个广义上的商业智能概念，在这个概念层面上，数据仓库是其中非常重要的组成部分，数据仓库从概念上更多地侧重在对各项企业各类信息的整合工作，包括了数据的迁移，数据的组织和存储，数据的管理与维护这些我们平常称之为后台的基础性的数据准备工作，与之对应，侠义的商业智能概念则侧重在对数据的查询，报表、多维/联机数据分析、数据挖掘和数据可视化工具这些平常称之为所谓前台的数据应用方面。

　　第三章回 商业智能的需求

　　前面我很罗嗦地交代了商业智能的来龙去脉，我希望让各位知道的是，商业智能需求天生就注定了是不好弄的，为什么，一句话可以概括，因为这是脑子工程，是一把手的工程！决策，其本身就是一个很个性化的事情，每个人的思维方式和思维习惯千差万别，加上性格偏向和个人喜好等因素，好与不好本身就是个价值判断，不是一个是非分明的逻辑判断。说穿了，商业智能的需求就不可能有什么标准的模式，因为即使从人工智能的理论角度，现在也还没有一个方法可以完全地模拟人脑的运做，所以对商业智能需求的定义和控制过程事实上就变成了对人脑的控制过程，如果需求是做到一把手的头上的，想控制一把手的想法可不是闹着玩的。

　　关于商业智能的需求，业界和用户就存在两种观点之争，为了说明两种观点，我把商业智能四个字拆开成“商业”和“智能”两对，前者是商业观点，后者是智能观点。这也反映了商业智能需求驱动力的一个发展和变迁，从商业智能形成产业到目前，商业智能需求的主要驱动出现了三次变迁。

　　首先是技术驱动，最开始只是觉得它是先进的技术，很多企业开始购买了很多这些产品，积极的通过技术的方法驱动这个技术在企业里面的应用。譬如引入查询与报表工具，多维分析工具来改些原来业务系统的报表以及开发一些分析型的应用。

　　到后来我们称之为业务驱动，现在特别是金融行业，还有政府行业，他们的数据量非常大，基于数据的分析和研判实际上在日常业务流程的战术层次也有很大的一个应用的价值。前在很多行业里面，它的基本从业人员的素质已经非常专业化，比如说特别在金融行业里面，从业人员的素质非常高，因此他很多时候他的决策是在战术层面决定的，比如银行的客户经理负责信贷业务的话，很多时候是他客户经理就要决策，给这个客户相应的信贷的政策是什么样的，基本定制适合这个客户服务的套餐。面对这样一个情况，实际上我们看到很多时候是业务的一种驱动，满足一线业务人员每天做很多战术上决策的需要。

　　再到后来是管理驱动，由于管理信息面的广度要求，就要开始建数据仓库整合数据了，大家可能觉得他是为管理服务的，但是我们认为在中国早期的bi建设当中，它没有真正起到这个作用，仅仅是给管理者提供了一些基本的报表而已。为什么会提到管理驱动呢，我刚才已经提到了现在的企业老总所面对的内外夹攻的双重压力，在这个情况之下，我们看到的是企业真正的意识到了这种管理的重要性，特别是现在金融企业，它面临很多管理上的改革，比如说中国的金融行业在这两年改革最多的地方，就是我们的信贷风险的管理，还有我们的相应的一些引进一些先进的成本核算的机制，还有绩效考核的机制，这些都是真正对管理从内在的改变。进而它反过来就会驱动数据仓库技术的应用。我们看到在以前，比如说我们做数据仓库的时候，我们会在中国的很多企业里面，认为它是一个可有可无的系统，只是说这个报表我早一点拿到，晚一点拿到而已，但是今天我们看到在银行里面所有的员工，他每个季度的奖金怎么发，都是数据仓库来支撑的绩效考核系统来实现的。

第四章回 商业智能的需求分析

　　从这个变迁，回应刚才的我对商业智能的分拆，我们看到了一个很明显的趋势，就是目前商业智能需求的重点逐渐从“智能”转向“商业”，同时也因为这种我们和我们的客户对商业智能的理解的变迁，直接地影响了商业智能的需求形态，也必然对商业智能需求分析工作者提出了与时俱进，不断调整和修改需求分析方法的要求。

　　在技术驱动的时代，商业智能的需求分析更多地是侧重在bi工具的应用，例如用报表工具来实现一些管理性的报表，用olap来实现一些经常性的数据统计与分析，用etl工具来替代手工编写代码方式的数据迁移。这个阶段的需求分析过程有非常明显的技术倾向性，这种项目往往有个前提，就是目标技术平台往往在项目启动之初已经敲定，需求分析师首先要非常了解目标技术平台的各项技术指标，并且非常小心地把目标用户的需求引导并且框定在这个目标技术平台的能力范围之内，这个逻辑是很自然的，也是无可厚非的。

　　在业务驱动的时代，需求分析师首先需要非常熟悉目标用户的日常业务，商业智能系统比传统业务系统相比，需求的把握与定义是非常困难的，传统业务系统的流程是非常清晰的，类似银行业务的核心业务系统，诸如储蓄业务，对公业务，国际业务即使种类很多，而对于落实到具体业务的需求的时候，起码同一家银行是有一个标准的业务操作的流程的，不论流程多么复杂，所对应的需求总是明确的，可见的，用程序化的方式来表达也是简单的，而且作为生产系统，早日投产比完善往往是更具价值，在这个大前提是，花繁为简，稳定压倒一切是甲乙双方都认同的。而作为以辅助业务中战术决策的商业智能系统，首先要迈过的一个关口就是，在战术智慧上，系统的决策水平要起码高明于一个中等层次的业务人员的商业智慧，这样他才会觉得系统对他是有帮助的，回应刚才我所提出的，对商业智能需求的定义和控制过程事实上就变成了对人脑的控制过程，需求分析师如果不是一位该业务领域的专家，所能形成的需求分析结果能一次性地获得业务人员的真心拥护和认可无疑是天方夜谭，而在目前的bi界中，完全是从业务成长起来的bi需求分析工作人员凤毛麟角，实际情况往往是，一群技术功底还不错，脑子又转得比较快，能给客户一个良好形象的技术人员出身的人充当了bi需求分析师的角色，我就是一个非常典型的例子，这些人如果心态正确的话，会抱着一种对业务无知的谦卑感虚心地向自己的客户请教，并且仗着客户对技术莫测高深的敬畏，迅速地把需求结果框定为一个个本来就是客户手工在做的报表，当然也不排除通过向客户的需求学习，初步掌握了一些业务上的规律，把客户的需求提炼成灵活查询或者多维分析的模型。不幸地，就是这种需求分析方式也造成了我的报告开头所形成的需求怪圈，可以说，这种不幸的局面是先天性的，在东西没有实际做出来以前，无论是客户还是我们的需求分析师，双方所沟通的都是对方头脑里的想象，然后把这种想象用稍微直观一点的方式描述出来，这种表达的效果不管花了多少的细致周到的努力，实质上还只是一种纸上谈兵，或者俗称画饼，饼的模样是画出来了，饼的味道是无论如何也画不出来的，然而时间是不会等人的，工程师们迅速地照饼样动手施工，力求早日让客户吃上称心可口的美味，然而，交付的时刻往往是令人悲哀的，当用户第一口咬下去以后，能一口咬定就收货的用户几乎是不可能的，因为本来就是“学生”做出来的东西，有这样的结局是不足为怪的，于是就有接下来的不断的用户抱怨，不断的需求“变更”，不断的“优化”，不断的“补丁”，不断的忧虑和烦恼……

　　目前，针对这种情况，一些大公司仗着自己的影响力，组织了一群技术专家经过多年的类似项目经验沉淀后，形成了一套所谓的模板，一则让bi需求分析师对于业务思考模式的学习和理解可以从客户现场退回到自己的公司内部，避免了露短的尴尬，二则，也试图用既成事实的行业标准的做法迅速而直接的影响用户的思维，业界内俗称，给客户“洗脑”，然而，针对个别企业的业务所分析出来的模板能推广，有一个预设前提，就是这种业务在全世界有一个可以普遍使用，而且有同质度非常高的标准成功模式，事实上，每个企业和人一样，是个性发展的产物，不是标准形成的产物，标准的推行本身就意味着企业的持续变革，这里也形成了一个悖论，持续的变革是否需要模板也需要持续的调整，然后模板的调整是否又需要持续的变革来配合，…… 本人对模板是认可的，而对模板的可推广能力是持非常怀疑的态度的。

　　在bi领域，这个以优化为名的迭代几乎形成了一个没完没了的怪圈。这个怪圈的形成，给每一位曾为商业智能抱有共产主义理想的人冷冷地提了个醒，商业智能不是一个目标，而是一个过程，正如伟大的孙中山先生所嘱咐的，革命尚未成功，同志仍需要努力。

　　第五章回 商业智能需求的出路

　　一直到现在，可能各位觉得我对商业智能所持的是一种悲观的态度，这几年，我对商业智能的认识也确实出现了几次反复，从崇拜到失望，从激情蓬勃到理性回归，最后，我相信，商业智能需求必然走向的是价值驱动， 我相信，商业智能的需求经过多次否定之否定的螺旋式上升发展的过程后，商业智能的应用与企业价值链的优化组合是必然的趋势，只有把商业智能的需求和企业价值链的形成与提升结合起来，商业智能的实际价值才能得到真正的体现。

　　正如前面的分析，各种内外因素的组合作用，使企业必然信息驱动为核心的生产和管理方式，在企业利润形成的整个价值链条中，信息使这条价值链从模糊逐渐走向清晰，将数据作为企业战略资产并且在数据质量方面继续投资，是使企业成为行业先锋的重要保证，运用商业智能的环境来回答诸如客户价值贡献度，地区市场差异，资本充足率，商品生命周期，成本与财务预算，定价策略，资金周转率等与企业利润的形成密切相关，商业智能把历史数据从“数据监狱”里释放出来，成为企业的一笔有形的资产。

　　说到这里，已经到了我这次报告的尾声了，由于时间的限制，很多具体的点我都没有办法再深入展开了，我相信，商业智能从“智能”走向“商业”是一条商业智能需求走出困境的必由之路，我作为一个从事技术工作十二年，从一个很单纯的技术人员成长起来的技术人员，凭我自己的良心指出，技术至上的观点，不但会成为商业智能发展的桎梏，甚至会成为扼杀商业智能应用推广的无形黑手，所以，作为商业智能项目主导的这些需求分析负责人，首先，就要明确地树立的是做商业智能是为客户赚钱的商业观念，在和客户需求形成的过程中，把客户的需求引导向对客户有利而同时也对降低自身实施成本，加快投产速度也有利的角度，我从来不认为做报表和查询是一种身价的贬低，如果一份“简单”的报表或一笔“简单”的查询能为客户一年节省过千万的成本，避免一笔过千万的风险损失，一份报表就把客户对项目的全部投资都收回来了，这笔帐，我们这些技术人员应该学会帮客户算! 这样的商业智能项目，难道还会受到客户的冷遇和拒绝吗?

　　最后，我们每位从事商业智能的业界朋友，有个很简单的问题我们问过了吗? 我想以这个问题作为我这篇报告的总结，请问到底什么是商业? 我想我的答案很简单，不过说了也等于什么都没有说，我想用这句香港人常说的口头语来作为我报告的结语:

　　business is business!

COGNOS经验摘抄一

用了将近半年的cognos，仍属入门级菜鸟，但是在使用过程中也颇有一些心得，将其整理并记录下来，希望对大家有所帮助

1. 在iqd中编写sql语句时，建议不要使用cognos的标准sql语法，因为这不仅会影响sql查询的速度，同时对sql查询的功能也有所限制，具体的实现的方法是直接将所有sql{}括起，这样cognos将不对花括号中的sql语句进行解释而是直接仍给所连接的数据库，用数据库自己生成最优化的查询计划。

2.关于iqd的写法，以下提供一个具体的模板，只需要依葫芦画瓢即可

COGNOS QUERY
STRUCTURE,1,1
DATABASE,DB
TITLE,IMR1.imr
BEGIN SQL
{select T1.C1 as c1,
T1.C2 AS C2,
T1.C3 AS C3,
T1.C4 AS C4
FROM SCM. T1

}

END SQL
COLUMN,0,C1

COLUMN,1,C2

COLUMN,2,C3

COLUMN,3,C4

3.对于相对固定不变的维表，最好是使用本地文本的格式如csv格式加以保存和维护，这样可以提高cube生成的速度

4.对于以时间为变化轴的数据，可以通过建cube group来按照指定的时间粒度进行增量维护

5.下钻路径应该根据维表层次的关系以及分析的需要进行选取，如果在同一维表中两个层次之间没有明确的继承关系，则应考虑将两个层次建在两个不同的下钻路径上

6.开发cube的时候，事实表中的数据应在保证不丢失信息的前提下尽可能的将粒度变大，这需要建立一个中间表，从源数据表中将聚合后的数据导入到中间表中，总之直接从源数据中提取数据建cube是不合适，应尽量避免


1. 对于多维报表模型，在开发环境下应存储为MDL格式而不是PYI格式，两种格式的区别在于MDL是以XML文本存储，保证了模型的移植性和可扩展性，但是在性能方面会相对差一些，因为每次生成Cube都要先将MDL编译成二进制的文件，而PYI则是已经编译好的，因此性能较MDL优，但是如果模型不是很复杂，两者的差别并不大

2.除时间维度外，其余维度中的category应设成always include，这样可以保证报表中有完整的分析方向，举个例子：

要分析所有客户中的男女分布，如果客户中全是男性，而将相应的category按默认生成include in need，则用pp打开cube后，只能看到性别维度中只有男性，没有女性。

这段时间又有一点体会，希望能为大家省去一些麻烦

1.Powerplay server 7 version 4的字体支持问题
从3.0 升级到4.0后，发现对粗体的支持有问题，发布的报表中如果使用了粗体，在upfront上浏览的报表出现了显示不正常的情况，主要包括：标签不能正常显示，报表中的数据不能正常显示，因此在4的版本下开发报表，应注意使用正常字体（这个问题，折腾了俺一个星期的时间才找到原因，5555）
2.报表格式的要求
为了保证报表有效、快速的显示，应在整张报表上使用相同的字体，并尽量避免使用图片等多媒体格式的文件
3.Transform中的多维模型设计
在维视图上，时间维在系统内部生成，并讲时间维放在维视图的第1列
在数据源视图上，将事实表放在最后
中间表的设计方面，在保证信息不丢失的前提下，尽可能通过聚合等方式，去除中间表中的明细数据
4.如果希望以时间为轴实现数据的增量更新，应使用cube group
5.如果要全部重新生成cube，应该将原有的cube删除后，再进行重建，否则会报错
6.如果维度比较稳定， 则尽可能的使用csv格式保存，对于渐变维或经常需要维护的维度使用iqd来获取
7.在pp中设计报表时，对于出现报表的列或行的维度，如果经常需要维护，则尽量使用subset，这样可以保证报表动态的更新
8.如果使用了宏来自动生成cube，产生报表，则在重新生成cube后，应该手工的保存mdl，否则下一次重新运行宏的时候，cube会生成失败(这个问题应值得注意)
9. 如果将其他环境下的cube放到当前环境中打开，如果cube中含有访问控制信息，则只有在当前环境下的Acess Manager中的用户类目录结构于先前环境下的完全一致，才能保证cube的正确打开， 可以先将前一环境下的安全控制配置文件导出为.lae，然后再导入到当前环境来完成这个工作


Cognos 企业级系列产品其实包括了两部分，一部分是ReporNet，一部分是Powerplay也就是人们常常提到的PPES,这两部分分别解决的是二维报表和多维报表的问题，同时在数据采集的机制上也是完全不同的，ReportNet采取的是对数据库做online查询，而PP则是在实现准备好的Cube基础上，创建多维报表，并支持钻取，切片，上卷，旋转等灵活的报表展示功能，前者的工作负荷集中在数据库上，而后者的工作负荷则集中在PPES服务器上。而两者的安装完全可相互隔离，他们在功能上是一种互补的关系，但是在物理上却毫无关系，对于Cognos产品的理解，我个人建议最好是先看看cognos自带的关于产品体系架构方面的文档，同时最好能自己亲手安装和配置一下，这样才能对其产品的结构有一个深入和全面的认识


数据库的导入
ReportNet自带sample数据库以及相关的工程文件
在导入模型之前，要将sample数据库中的表恢复至当前的数据库中，对于DB2，在..program filescognoscrnwebcontentsampledbdb2目录下有多个.tar文件，解压后可以看到有多个tabl?. ixf以及一个db2move.lst文件组成，其中db2move.lst是供db2move工具使用的列表， 而ixf文件中包含了相应的表的表结构定义和数据，使用db2move将表及其数据导入现有的数据库，命令如下：
db2move import -io replace_insert -u user -p password
如果提示单字节代码页集不相配的错误，可以自己建立一个批处理文件来使用import或load语句的forcein文件类型修饰符来强制对单字节代码页进行转换，如：
db2 connect to cogdb user cfep using cfep2004
import from tabl.ixf of ixf modified by forcein create into GOHR.BRANCH
import from tab2.ixf of ixf modified by forcein create into GOHR.EMPLOYEE
db2 import from tab3.ixf of ixf modified by forcein create into GOHR.COUNTRY_MULTILINGUAL
db2 import from tab4.ixf of ixf modified by forcein create into GOHR.COUNTRY
db2 import from tab5.ixf of ixf modified by forcein create into GOHR.GENDER_LOOKUP

将数据导入至数据库中之后，应对模型进行相应的修改，首先在crn中建立同名的datasource，并且在properties页中设置同名 datasource,schema设置为所使用的db2模式（大小写敏感），将type->interface设置为DB2,
即完成了对sample的导入工作

OLAP12条准则

Codd提出OLAP的 12条准则来描述OLAP系统：
准则1 OLAP模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力推测
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成
准则12 不受限的维与聚集层次