loading
Cognos报表开发设计规范
版本历史：
版本
作者 日期 修改记录和备注 1.模型的规范
物理层：从数据库直接引入的数据库对象。
逻辑层：最终发布到Cognos服务器上提供给用户使用的对象集合。 模型分层的原则：降低模型的复杂性，便于管理和维护。 模型开发命名规范 安全设计 功能安全性
1.1 物理层的创建
A. 在工程的主namespace（最上层的namespace，工程自动生成）下创建物理层文件 夹（以下简称“物理层”）
B. 将开发用到的数据对象（表、视图或者存储过程）全部纳入 C. 不对导入对象作任何改动
D. 不导入数据库对象间的约束关系，不在该层建立查询对象的关联关系 E. 物理层对象统一放在名称为“物理层”的文件夹对象下
F. 物理层对象根据数据源的不同使用名字空间进行归类组织，命名规则如下：数 据来源描述+’_DS’
目录结构图如下：
1.2逻辑层的创建
A. 创建和物理层并列的逻辑层文件夹（以下简称“逻辑层”）
B. 根据物理层的数据对象在逻辑层创建查询主体（Query Subject）。 C. 在逻辑层内建立查询主体之间关系
D. 在逻辑层的第一层使用namespace对业务主题进行分类，如基金余额汇总表，证券 客户信息表等。根据实际情况可以在往下一层使用目录或者namespace再进行主题 分类。最后，放置具体的查询对象
E. 逻辑层的分层根据实际情况按照具体应用进行，一般至少分成两层 F. Cognos模型开发规范 G. 目录结构图如下：
1.3模型开发命名规范
A. 以下使用的项目简称一律使用英文大写，如ERPF、ECIF等，其余英文部分，如未
加说明一律使用小写
B. Cognos工程（Project）：直接使用项目或应用专题名称
C. 顶级namespace：项目组或者应用专题的简称+’_’+ COGNOS模型，一个项目组原 则上只建立一个Cognos工程。如：SMIS_COGNOS模型
D. 逻辑数据源：项目组组或者应用专题的简称+’_’+’rdb/mdb/txt/oth’，其中，rdb代表 关系数据库，mdb代表多维数据库，txt代表文本数据,不属于上述任何一种数据源 的使用oth，原则上，一个工程只允许新建一个数据源，如果确实有必要建立多个 逻辑数据源的，需要在上述命名规则后添加三位数字序号，如ERPF_mdb_001 E. 名称空间和目录、查询主题、查询对象，根据具体的业务含义进行设置，除专有名 称外，原则上只使用中文，并避免直接使用技术术语，在名称的选取上要力求规整 F. 过滤：根据过滤条件的实际意义用中文进行描述
1.4安全设计
A. 安全控制原则：机构层级+角色访问控制（RBAC）
通过会话函数（session）取得用户所在机构对用户所访问数据进行权限控制，再通
过给用户分配不同的角色对用户所访问的报表进行权限控制。一般的，上级机构用户具备所有下级机构用户在数据和报表的访问权限。
B. 对象安全性的实现
通过设置对象可视性给对象提供可视权限，设置哪些用户、组和角色具有对象的可
视权力，拒绝所有其它的用户、组和角色的访问。
C. 数据安全性的实现
通过设定包访问权限来实现元数据的安全性；通过定义数据安全性过滤，限制查
询主题返回的数据。
1.5功能安全性
对于Congos几种默认角色要求：
A. 系统管理员：对于系统管理员角色用户，可视为根用户或超级用户，所以可以任意
访问和更改资料库的对象，并且能够更改其他角色的关系，因此系统管理员的成员中不允许包含所有人用户。
B. 匿名用户：匿名用户可以访问未设置权限的，或已经授权给匿名用户角色或所有人
角色的资源。
C. 授权用户：授权用户是经过权限设置者授权的用户，是由Cognos产品自身维护的，
其他人不能对该角色进行配置。
D. 所有人：所有人用户是由Cognos产品自身维护的。对于所有人角色用户，相当于
匿名用户及所有授权用户。可以使用所有人用户来对资源进行快速默认授权设置。
1.6包设计规范
A. 一个项目组原则上只发布一个包，由于应用的需要必须设置多个包的时候，可以使
用包的应用进行区分，命名如下：
项目简称+’_’XXXX，XXXX代表应用名称，一般使用中文，如ERPF_总帐报表， ERPF_资产查询
B. 命名的原则：中文部分按照业务的原则组织，避免使用技术的术语，如“ERPF_资
产模型”是不符合规范的命名
C. 包发布规范：只发布展示层文件夹的内容。 发布后内容如下图：