Cognos Best Practices Done Sep 13
Cognos Best Practices Done Sep 13
Cognos Best Practices Done Sep 13
Only the required tables and DB objects should be imported into the model.
Avoid having Orphan Tables in the data base layer
Complicated calculations should be done at the data base side
Many to Many relationships should be avoided as they generate stitched queries. Instead Star Schema
grouping should be used.
All Parallel relationships should be examined and the unnecessary ones should be resolved.
Recursive relationship should be converted to fixed hierarchy using shortcuts.
In a fact table query subject, exposing any query items that are not facts (measures with an aggregation
rule) should be avoided. If necessary, they should be exposed as a separate model query subject that looks
like a dimension.
Whenever possible reduce the number of query subjects. Represent each discrete business concept with a
single model query subject.
If two fact tables have conformed dimensions, but different levels of granularity for that dimension, then for
each fact table only the relevant levels should be included.
Only the objects that will be reported on by users should be published in a package.
Surrogate keys should be hidden while publishing a package.
Define Data level security in the ‘Data base layer’ in the cognos model
Fetch the parameter values for the security filters from a DB table instead of hard coding in the model. This
provides more flexibility in change management
Maintain identical user group names in Cognos Namespace & External Authentication source
Use Parameter Maps for dynamic data source querying instead of creating individual packages for each
data source
Restrict access to the administrative functions in Cognos connection. By default, the ‘Everyone’ group is a
member of the ‘System Administrators’ role.
Groups and / or roles be created within the Cognos namespace, and these groups and roles be used to
secure the content objects.
All Development activities to be done in Dev environment, UAT be done in BETA environment & Users
access the production environment.
It should be ensured that copies of reports in BETA & Production environment are same for ease of
maintenance & back up
Production & BETA should have same hardware and configuration settings
Deployment of Report objects into BETA & Production should be done by cognos administrator
For bulk deployment of objects , Cognos deployment service may be used, manual depoyment may be
used when the number of objects to be deployed is less.
• Configure the required audit settings and have audit reports in pace to measure usage of cognos
environment
• Set the default font to Arial or some light weight font, ‘Andale’ which is the default font consumes 216MB of
memory which may potentially cause performance issues in reports
• Maintain copies of Configuration settings using the ‘Save configuration’ option available in cognos
configuration
• Maintain the same configuration for the Dev,BETA & Production environments for consistency
• Provide description & screen tips for each export & Import deployment archives for easy maintenance &
future reference
• Have Load balancing & fail over mechanism in BETA & Production environments
• Set up server CPU usage, memory usage & exception alerting mechanism in production environment
• During Cognos version upgrade, upgrade the dev environment first ,make an impact analysis on reporting
objects due to upgrade to ensure smooth flow to production environment
Configure the Framework manager with version control software to enable maintaining versions of models
in development environment
Enable ‘Versioning’ while publishing packages and do not overwrite packages in development environment
Developers to ‘Check-in’/’Check-out’ & provide change comments for every change made in the model
BETA & Production environment to have only a single copy of packages & reports
Local processing should be avoided under normal circumstances and should be enabled only while
processing queries with outer joins.
Tabular SQL should be avoided unless absolutely needed.
A report template should be created with the standard layout and should be used for creating all the reports.
Templates can be set in such a way that they are prompted at the start of a new report creation.
The Page header and Page footer section should be used to put common items like titles and links to other
reports.
A combination of tables and blocks should be used to create reports .
© 2013,
2007, Cognizant Technology Solutions. Confidential
10