Resolving Uniqueness Problems In Your Data Source - IBM Cognos User Manual

v The category or member may no longer exist in the data source.
To avoid these problems, use the following best practices:
v Use unique codes and keys within a dimension for the category or member
keys.
Ensure that your Cognos Transformer model source values have unique values
throughout the levels of each dimension. This ensures that the model category
codes, and therefore the MUNs, are more stable.
v Use unique conformed source values for similar dimensions between the target
and source environments when enabling drill through.
v Ensure that the business keys and dimension metadata structure are the same
between the production and test environments.
v If the data source is a package or report, do not change the business keys after
going into production.
v Resolve the non-unique keys within a dimension in the data source.
Do not use the tilde character (~) in the category codes because this might
produce unstable MUN values.
v If you have tildes within your category codes, do not use the Clean House
feature.
Using the Clean House feature will most likely change the category codes.
v Keep a backup of your .mdl file and revert to the backup .mdl model file if the
current model file becomes corrupt and requires a Clean House action.

Resolving Uniqueness Problems in Your Data Source

To avoid ambiguity problems in your reports, design your models so that no two
categories in a level represent identically-named distinct categories, such as cities
with the same name in two or more regions.
When you create models in Cognos Transformer, multiple non-unique categories
imported into the same level are made unique by appending ~### to the duplicate
codes, where ### represents an ascending numeric sequence.
The mappings between these assigned codes and their associated source values are
stored in the Cognos Transformer model for use in subsequent cube build
operations. However, errors may arise if the model is not saved after a cube
refresh, or if the processing order changes for any reason.
For example, IBM Cognos report specifications reference categories or members of
an OLAP package, including PowerCubes, using a unique identifier referred to as
Member Unique Name (MUN). This MUN is generated for each category in a
PowerCube and is based on the fully-qualified path of category codes in the
dimension, according to where the category exists within the dimension. If the
category codes change for any reason, the report specification can no longer locate
the original MUN. The report author must modify the report to point to the
updated category or member.
If your source data contains columns that populate levels that are not unique, an
error message warns you of the potential problem when you attempt to generate
categories. However, this prompting occurs only if the data source contains all the
columns required for the levels in question. If categories for some levels have
values derived from other transactional data sources, uniqueness conflicts may
arise but remain undetected. Also, if you select an optimization setting that
Chapter 3. Data Sources for Your Model
23