1.

Project Files: in CRN

model.xml: The actual model data created by Framework Manager Users.
preferences.xml: The preferences for Framework Manager Projects.
customdata.xml: The stored diagram information, such as the diagram layout, Notation, font,
and color
Repository.xml: The logged version history for each project or segment.
That was added to a repository. This file exists only if you added projects to a Repository.
C8:
In Addition to the above files, C8 contains below files as well
IDLog.XML—Merging Info
Log.XML—all modifications made to the model
Session-Log.XML and Session-log-backup.XML—A list of unsaved transactions in the model
When Project is saved, this list is deleted. View contents of this file using View Transaction
History (Project Menu).When FW is started, the existing Session-log.XML file is renamed to
Session-log-backup.XML

2. Cardinality will be detected based on the selection of set of rules:

Use primary and foreign keys
1 Use matching query item names that represent uniquely indexed columns
2 Use matching query item names.
The general rule applied to cardinality is as follows:
1-to-n cardinality implies FACT
0-to-n or 1-to-n cardinality implies DIMENSION.
Query subjects defined with 1-to-many or 0-to-many cardinalities are identified as facts.
Query subjects defined with 1-to-1 or 0-to-1 cardinalities are identified as dimensions.
It is possible to have a query subject behave as a dimension in one query and as a fact in
another.
Cardinality in FW is
1.1,
1. N (Default),
0.1(Outer Join)
0. N (Outer Join)
0 Indicates Optional and 1 indicates mandatory.
Identifying Facts and Dimensions
Within the context of a query, a query subject that has only maximum (n) cardinality on all its
relationships to other query subjects can be regarded as a fact. The implication is that there are
more rows of data in the fact query subject than in the related query subject on the minimum (1)
side of the relationship. Any query subject having at least one relationship to another query
subject with minimum cardinality (1) will be treated as a dimension.
Analyze a Schema for Facts and Dimensions
Example 1: In this example, all four query subjects are included in a query. The diagram shows
that the query subjects having only maximum (n) cardinalities are treated as facts.
Example 2: In this example, only three query subjects are included in the query. The diagram
shows that the Order Header query subject is now treated as a fact.

New Objects in Cognos 8

In ReportNet 1.x, dimension information combined the concept of uniqueness with the concept
of dimensional hierarchies. In Cognos 8, the concept of dimension information is divided to
provide control over uniqueness and granularity. This control is required for relationally-based
query subjects and to more explicitly address dimensional concepts of hierarchies and levels for
dimensional objects, even on relational sources.
When reviewing dimension information, you must understand how the dimension information
is applied to the query subject and how the query subject will be used in the Cognos 8 model.
New objects have been introduced in Cognos 8:
• determinants for query subjects
• regular dimensions
• measure dimensions
• scope relationships
Determinants are not the same as levels and hierarchies but they can be closely related to a
single hierarchy. The query engine evaluates determinants from first to last. One or more
determinants may be specified.
If a model regular dimension is based on a query subject with determinants specified, we
recommend that
• one level correspond to each determinant that exists in the query subject
• the order of the levels in the hierarchy reflect the order of the determinants
This results in a consistent model, facilitating upgrading the model in future releases of Cognos
products.
WORKFLOW:
We recommend that you follow this workflow when you dimensionally model relational data
sources:
❑ Import the metadata.
❑ Check the imported metadata (p. 7).
❑ Customize the metadata.
❑ Simplify the model using dimensional concepts (p. 10).
❑ Resolve ambiguous relationships (p. 12).
❑ Define dimensions and determinants (p. 16).
❑ Organize the model by creating business views.
❑ Create star schema groups (p. 22).
❑ Apply security.
❑ Create packages and publish metadata.

Loop or Ambiguous relationship:

There are two types of Loops
1. Multivalid Relationship---Create Alias
2. Loop Joins
3. Recursive Relationship –Create Shortcut
Multiple Valid Relationships
CASE 1: typically occur between dimensions and facts. Create a model query subject for each
role with a single relationship specific to the role.
A table that has multiple valid relationships between itself and another table is known as a role-
playing dimension. This is most commonly seen in dimensions such as Date and Customer. A
good example is an Orders fact, which may have multiple relationships to the Customer
dimension on keys such as sold_to, ship_to and bill_to.

How do you resolve the join ambiguity for Customer?

Leave all the relationships in place in the Import View. Create a model query subject for each
role. Rename the model query subjects and query items appropriately for their use. Ensure that
a single appropriate relationship exists between each model query subject and the fact query
subject.
CASE2:
A table with multiple valid relationships between itself and another table is known as a
role-playing dimension. Multiple valid relationships often occur between regular dimensions
and measure dimensions. This is most commonly seen in dimensions such as Time and
Customer.
For example, the Sales fact has multiple relationships to the Time dimension on keys such as
Order Day, Ship Day, and Close Day.

Steps
1. Leave all the relationships in place in the Import View.
2. Create a measure dimension for the fact.
3. Create a regular dimension for each of the dimensions.
4. Create or copy the regular dimension for each role.
5. Rename the dimension, hierarchy, levels, and attributes appropriately for their use.
6. Ensure that a single appropriate relationship exists between each regular dimension and the
measure dimension, or between the underlying query subjects.
7. Ensure that there is a corresponding scope relationship specific to each role.
8. Decide how you want to use these roles with other facts that do not share the same concepts.
For example, Product Forecast has only one time key.
You can do one of the following:
• Designate a specific time dimension to be the conformed time dimension.
You can pick the most common role that you will use and name it clearly as a conformed
dimension. You can then ensure that this version of the dimension is joined to all facts
requiring a time dimension.
You can treat ship day, order day and close day as interchangeable time dimensions with
Product Forecast fact.
In this case, you must create joins between the role-playing dimensions and Product
Forecast fact. You can use only one time dimension at a time when querying the Product
Forecast fact or your report may contain no data. For example, Month_key=Ship Month
Key (200401) and Month key=Close Month Key (200312).
Loop Joins: Typically occurs when one schema is imported at a time like if we import one fact
table and 2 dimension tables by using Primary and Foreign Key relationship,here basically it
should use n-1 relationship between the tables,but in this case it creates N no of relationship
acroos the tables.
Recursive Relationships –
CASE1: typically imply two or more levels of granularity. As a minimum a shortcut or model
query subject each for the parent and the child roles.
Framework Manager imports recursive relationships but does not use them when executing
queries. Recursive relationships are shown in the model for the purpose of representation only.
To create a functioning recursive relationship, you must create a shortcut to the query subject or
a model query subject based on the query subject (an alias) and then creates a relationship
between the query subject and the alias. It is necessary to repeat this for each level you wish to
represent.

For a simple two-level structure, the model would look like this:

CASE 2: It’s like Self Join, let’s take EMP table which is having EMP ID,ENAME and
MGR_ID.If you want to get MGR(MGR is also Employee) for the particular employee, then we
will create another table based on the existing table which contains MGR_ID and MGR _NAME,
then join the new table with old table with MGR_ID
CASE 3:
Reflexive and recursive relationships imply two or more levels of granularity. Framework
Manager imports reflexive relationships but does not use them when executing queries.
Reflexive relationships, which are self-joins, are shown in the model for the purpose of
representation only.
To create a functioning reflexive relationship, you must create an alias using either a shortcut to
the query subject in the same folder, or a model query subject based on the query subject. You
then create a relationship between the query subject and the alias. Using a model query subject
tends to be a better option because you can specify which query items are included in the query
subject.
For example, the Staff query subject has a recursive relationship between Staff Key and
Manager
Key.
Steps
1. Create a model query subject to represent Manager.
2. Select which query items apply to Manager and rename them in a meaningful way.
3. Create a relationship with a 1:1 to 1:n between Staff and Manager.
For a simple two-level structure using a model query subject for Manager that is based on
Staff, the model looks like this:

4. For a recursive hierarchy, repeat these steps for each additional level in the hierarchy.
For a deep recursive hierarchy, we recommend that the hierarchy be flattened in the data
source and that you model the flattened hierarchy in a single regular dimensions.
5. Select the query subjects, right-click, and click Merge in New Regular Dimension.
Define Dimensional Information in CRN (Regular Dimension and Measure Dimension
and Determinants in C8)
Let’s discuss about the Dimensional Information in CRN
The basic goal of Dimensional Information is to prevent double counting in the sense
duplicating the records and to get the correct aggregations. It occurs where the fact data exists
at different levels of granularity.
Double counting occurs in 4 situations:
A. Single Fact Query
B. Multi Fact/Multi Grain Query
a. --on Confirmed Dimension and
b. --on Confirmed Dimension and Non Confirmed Dimension.
C. Aggregate Tables
D. Multiple Hierarchies
A. Single Fact Query: It contains one fact table and more than one Dimension table. It occurs in
relationally based query subjects and this is the basic Star schema structure. Here the cardinality
between Fact and Dimension tables would be 1 to many. Why we will use 1 to many, there are
multiple entries in fact table for each of the dimension key from Dimension table.
Let us consider the below example
RETAILER_SITE_KY is a primary key in Retailer table and the same key is present in
Retailer_Site table. Since the same Key is being used in different Dimension tables and joined
with Fact table with 1 to many relationship. So double counting may occur in this case.

Conclusion on Single Fact Query: I am not saying that double counting occurs when working
with one fact table with 1 to many relationships. It is better to Define the Dimensional
Information (one set of data) to avoid the Double Counting.

B. Multi Fact/Multi Grain Query

Multi-fact queries where de-normalized dimensions (Confirmed Dimension) are related to fact
tables on different keys (and therefore levels).
B.1.Multi Fact/Multi Grain Query on Confirmed Dimension:
A multi-fact/multi-grain query is typically the result of multiple star schemas sharing
conformed dimensions but using keys for different levels of the same hierarchy. There is
possibility for double counting the since an aggregation is required to bring the items from both
fact tables to the same level of granularity for reporting.
Multi Fact/Multi Grain Query occurs because of Confirmed Dimension shared between two
fact tables.

The data in the Sales Fact exists at a different level of granularity from the data in the Inventory
Levels Fact. Sales is at the day level, Inventory Level is at the month level.

Above figure shows two fact tables sharing a time dimension and a product dimension. The
Time dimension has four levels: Year, Quarter, Month, and Day. It has a relationship to
Inventory Levels Fact on the Month key and to Sales Fact on Day key. The Product dimension
has three levels: Product Line, Product Type, and Product. It has relationships to both fact tables
on the Product key.

A report on these four tables will, by default, be aggregated to retrieve records from each fact
table at the lowest common level of granularity, in this case at the month and product level.
Without specifying dimensional information on the time dimension, it is possible that incorrect
aggregation could occur – for example monthly fact values could be rolled up based on the
lower time level of days. By using dimensional information to specify that days roll up to
months, months to quarters, and quarters to years, any request to aggregate based on time will
ensure that days are rolled up to months.

Let us consider the below SQL example generated using the above schema
Select
Coalesce (D2.MONTH_KEY, D3.MONTH_KEY) as MONTH_KEY,
Coalesce (D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME,
D3.CLOSING_BALANCE as CLOSING_BALANCE,
D2.QUANTITY as QUANTITY,
RMIN (D2.QUANTITY1 order by coalesce (D2.PRODUCT_NAME,D3.PRODUCT_NAME) asc
local) as QUANTITY1
From
(Select distinct
TIME_DIMENSION.MONTH_KEY as MONTH_KEY,
PRODUCT.PRODUCT_NAME as PRODUCT_NAME,
INVENTORY_LEVELS_FACT.CLOSING_BALANCE as CLOSING_BALANCE
From
TIME_DIMENSION,
PRODUCT,
INVENTORY_LEVELS_FACT
Where
(INVENTORY_LEVELS_FACT.MONTH_KEY = TIME_DIMENSION.MONTH_KEY) and
(Product.PRODUCT_KEY = INVENTORY_LEVELS_FACT.PRODUCT_KEY)
) D3
Full outer join
(Select
TIME_DIMENSION.MONTH_KEY as MONTH_KEY,
Product.PRODUCT_NAME as PRODUCT_NAME,
XSUM (SALES_FACT.QUANTITY for TIME_DIMENSION.MONTH_KEY,
Product.PRODUCT_NAME) as QUANTITY
From
TIME_DIMENSION,
PRODUCT,
SALES_FACT
Where
(TIME_DIMENSION.DAY_KEY = SALES_FACT.DAY_KEY) and
(Product.PRODUCT_KEY = SALES_FACT.PRODUCT_KEY)
Group by
TIME_DIMENSION.MONTH_KEY,
Product.PRODUCT_NAME
) D2
On ((D3.MONTH_KEY = D2.MONTH_KEY) and (D3.PRODUCT_NAME =
D2.PRODUCT_NAME))
What is coalesce?
Coalesce is simply an efficient means of dealing with query items from conformed dimensions.
A coalesce is used to accept the first non-null value returned from either query subject. This
allows a full list of keys with no repetitions when doing a full outer join.
Why is there a full outer join?
A full outer join is necessary to ensure that all the data from each fact table is retrieved.
The potential for double-counting exists because the Inventory Levels Fact and the Sales Fact
join to the Time Dimension on different keys (Month Key and Day Key respectively).

The SQL generated in above schema is often mistaken by the modeler as incorrect or inefficient
because of a full outer join shown in the Cognos SQL. Many modelers may be tempted to
remove the full outer join by changing the SQL type of the query subjects to native SQL or by
changing the relationships between the fact query subjects and the dimension query subjects to
one-to-one. Once these changes have been made, they will find that the results are incorrect as
shown below.

If the cardinality were modified to use only mandatory (1) and/or optional (0) cardinality for all
relationships between query subjects the result of a query on Inventory Levels Fact and Sales
Fact with Time and/or Product will have incorrect totals. The Closing Balance is double-
counted, once for each day in the month and the quantity is incorrect.
Example: Incorrect Result without Dimensional Information (with above loop)
By not specifying dimensional information on the dimension query subject, Time for example,
you will find that the closing balance totals are multiplied by the number of days in the month
(or rows in the time dimension per month). This is an incorrect result.

Please note that if the underlying Time Dimension table has a primary key index on the Day
level id, then Cognos ReportNet will detect this and render the correct results because it will
understand that the month level join will not be unique.

Is the relationship between the Time dimension and Inventory Levels fact a many-to-many
relationship?
The join between the Time dimension and Inventory Levels fact is actually a many-to-many
relationship because there are duplicate months in the time dimension (one per day). By
specifying the dimensional information, we are giving Cognos ReportNet information about the
internal cardinality of the Time dimension that allows us to specify the relationship as one-to-
many. At runtime this will force the months to be distinctly joined and will avoid any double-
counting issues.
B.2. Multi-fact/Multi-grain Query on Conformed and Non-Conformed Dimensions
The scenario where a non-conformed dimension is added to the query changes the nature of the
result returned by the stitched query. It is no longer possible to aggregate records to a
lowest common level of granularity as one side of the query has dimensionality that is
 not common to the other side of the query. The result returned is really two correlated
lists.

The Result
The results of individual queries on the respective star schemas would look like this.
Querying the

Querying the same items from both star schemas yields the following result:
The SQL
The stitched SQL generated for this example is very similar to that generated in Example 2. The
main difference is the addition of Retailer Type. Retailer Type is not a conformed dimension
and affects only the query against the Sales Fact table.
select
coalesce(D2.MONTH_KEY,D3.MONTH_KEY) as MONTH_KEY,
coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME,
D2.CLOSING_BALANCE as CLOSING_BALANCE,
D3.RETAILER_TYPE as RETAILER_TYPE,
D3.QUANTITY as QUANTITY --- No coalesce because this is not a conformed dimension.
from
(select TIME_DIMENSION.MONTH_KEY as MONTH_KEY,
Product.PRODUCT_NAME as PRODUCT_NAME,
Retailer.RETAILER_TYPE1 as RETAILER_TYPE,
XSUM(SALES_FACT.QUANTITY for TIME_DIMENSION.MONTH_KEY,
Product.PRODUCT_NAME,Retailer.RETAILER_TYPE1 ) as QUANTITY,
RSUM(1 at TIME_DIMENSION.MONTH_KEY ,Product.PRODUCT_NAME,
Retailer.RETAILER_TYPE1 for TIME_DIMENSION.MONTH_KEY, Product.PRODUCT_NAME
order by TIME_DIMENSION.MONTH_KEY asc,Product.PRODUCT_NAME asc,
Retailer.RETAILER_TYPE1 asc local) as sc
from TIME_DIMENSION,Product,Retailer,SALES_FACT
where
(TIME_DIMENSION.DAY_KEY = SALES_FACT.DAY_KEY) and
(Product.PRODUCT_KEY = SALES_FACT.PRODUCT_KEY) and
(Retailer.RETAILER_KEY1 = SALES_FACT.RETAILER_KEY)
group by
TIME_DIMENSION.MONTH_KEY,
Product.PRODUCT_NAME,
Retailer.RETAILER_TYPE1 ---- Grouping includes retailer type as well as month and
product.
) D3
full outer join
(select TIME_DIMENSION.MONTH_KEY as MONTH_KEY,
Product.PRODUCT_NAME as PRODUCT_NAME,
INVENTORY_LEVELS_FACT.CLOSING_BALANCE as CLOSING_BALANCE,
RSUM(1 at TIME_DIMENSION.MONTH_KEY,
Product.PRODUCT_NAME,INVENTORY_LEVELS_FACT.CLOSING_BALANCE for
TIME_DIMENSION.MONTH_KEY, Product.PRODUCT_NAME order by
TIME_DIMENSION.MONTH_KEY asc, Product.PRODUCT_NAME asc,
INVENTORY_LEVELS_FACT.CLOSING_BALANCE asc local) as sc
from TIME_DIMENSION, Product, INVENTORY_LEVELS_FACT
where (INVENTORY_LEVELS_FACT.MONTH_KEY = TIME_DIMENSION.MONTH_KEY)
and
(Product.PRODUCT_KEY = INVENTORY_LEVELS_FACT.PRODUCT_KEY)
group by
TIME_DIMENSION.MONTH_KEY,
Product.PRODUCT_NAME,
INVENTORY_LEVELS_FACT.CLOSING_BALANCE
) D2
on (((D3.MONTH_KEY = D2.MONTH_KEY) and (D3.PRODUCT_NAME =
D2.PRODUCT_NAME)) and (D3.sc = D2.sc))

Why does Framework Manager decide to use a full outer join for query subjects when you
specify a one-to-many join?
Root Causes: Could be either one of those two: 1. Key of the dimension table is not part of the
join. 2. No determinants have been defined for the dimension table, or the determinants of the
join keys have not been defined as Uniquely Identified. Solution for cause 1: The full outer join
is generated to avoid double counting, for example - The key of the Retailer_type table is
retailer_type_code. When Retailer_type acts as a fact table (i.e when its cardinality is 1:n), and
Retailer is the dimension table (1:1), then because the key of the dimension table is not part of
the join, a stitched query is generated to avoid double counting. So, this is as design intent in the
sense that the correct SQL gets generated based on the join and key information in the model.
Change the relationship expression: D_EMPLOYEE.EMP_POSTN_BK = F_CR_EMP.EMP_BK
Instead of Call Report Attendee Employee.EMP_BK = F_CR_EMP.EMP_BK Solution for cause

Create determinants for the dimension table, make sure the join keys are defined as Uniquely
Identified.

STITCHED QUERY:
CASE 1: A stiched query uses multiple subqueries, on for each star, brought together by a full outer join
on the common keys
CASE 2: When a conformed dimension is present and you see a stitch key, keep in mind that the
stitch key is not exclusively used to merge the queries together. Any other indexes or
determinants will also be used in conjunction with the Cognos 8 generated stitch column to
merge the record sets."

For example, if we have two fact tables - sales and shipments with a conformed dimension
representative which joins to each fact table by repress entativedimid. I want to see sales vs.
shipments in a query so I drag over representative name, sales amount, and shipment amount.
Cognos constructs two sub-queries against each fact table, then does a full outer join on the
representative name rather than using represetnativedimid (the indexed surrogate key).
I have come up with a couple of solutions, both of which have issues:
1.Construct a specific fact table to handle these types of questions.
The issue here is that I have many potential and fact table combinations. This would increase
maintenance and even worse force the user to pick between a large number of datamarts.
2. If I create a many to many relationship between the two fact tables, Cognos generates the
query I want.
This leads to potential loop issues if I don't isolate the combinations in separate packages, and
again forces the user to know more about the structure than I want them to have to learn.

What I would like is for Cognos to construct two or more subqueries and join those on the
common surrogate keys. At that point it could perform any necessary aggregation. The query is
trivial to write by hand, but I can't seem to make Query Studio do the right thing

CASE 3: When queries are performed in IBM Cognos 8 that request facts from multiple
underlying database tables, the query engine performs a stitch query. Stitch queries consist of
sub queries, one for each disparate fact, which are then merged together on their common
attributes.Examine the report below:

Notice the Return quantity column has a null value in the last row. There are no nulls
in the Returned items table in the database. Why is there a null in the report?
Quantity and Return quantity are each facts taken from a separate query subject and
have Year from Time dimension and Product name from Products in common.

IBM Cognos 8 generates two subqueries which are then merged together to fulfil the
parent query which populates the report.
Pseudo SQL:

Select
coalesce(D2.Year1,D3.Year1) as Year1,
coalesce(D2.Product_Name,D3.Product_name) as Product_name,
D2.Quantity as Quantity,
D3.Return_quantity as Return_quantity
from
(Sub query 1) D2
full outer join
(Sub query 2) D3
on
((D2.Year = D3.Year) and (D2.Product_name = D3.Product_name))
In the pseudo SQL example above, the coalesce function is used to return the first non-null
record set from the sub queries. If both are null, then no record is returned. If one is null and the
other is not, then a record will be returned, but the sub query that had no match will display a
null value.Examine the results of each sub query. First, look at the sub query results that
retrieve data for the Quantity fact.

There are four records. Now examine the sub query results for the Return quantity fact.

Notice that there are only three records. There were no returns for 2007.
In a stitch query however, when there are more records in one sub query than the other, nulls
will be returned for the rows where there is no match as seen below:

IBM Cognos 8 uses cardinality defined in Framework Manager to identify which query subjects
are facts (fact detection). Query subjects that have only a 1..n or 0..n cardinality attached to them
in the context of a query will be considered facts. If two or more facts are found in the context of
a query, a stitch query will be performed provided a shared/conformed dimension is also a part
of the query. In the majority of cases, these stitch queries are required to bring back all required
data and aggregate the results correctly. However, there may be instances when fact detection
and stitch queries are not desired.

Examine the following HR model:

Staff members belong to a division. Each staff member speaks the company's primary language,
English, and may also speak a secondary language, which is tracked in the StaffLanguageFact
table. Each staff member also has one or more skills, such as being able to work on the sales
floor or at customer service. These skills are tracked in the StaffSkillsFact table.

In this model scenario, Staff and Division are both shared/conformed dimensions between the
two fact tables, which would enable a stitch query should both facts be requested in a single
query. The Language and Skills tables are nonshared/ conformed dimensions as they are only
related to their respective fact tables and not other fact tables.

The following is a report output when reporting which divisions have which skills and
which secondary spoken languages.
In this report output, it appears that the Furniture division has one person who speaks Spanish
as a secondary language and one or two people who can act as a cashier or customer service
representative. The Home Electronics division has one or two people that can speak French and
Spanish and also have customer service skills and sales skills. It is possible that the same person
can have more than one language or skill as seen below when StaffName is added to the report.

Here you can see that indeed, the same person can speak more than one secondary language
and have more than one skill. So over all, the report, through a stitch query, represents accurate
summary totals where both divisions have a total of three secondary languages spoken and a
total of four skill sets.
Examine the SQL snippet below to see the stitch query (…… represents removed SQL
in order to shorten the example):
select
coalesce(D2.DivisionName,D3.DivisionName) as DivisionName,
coalesce(D2.LastName,D3.LastName) as LastName,
coalesce(D2.FirstName,D3.FirstName) as FirstName,
D2.LanguageName as LanguageName,
D2.LanguageCount as LanguageCount,
D3.SkillName as SkillName,
D3.SkillCount as SkillCount,
XMIN(D2.Total_LanguageCount_ ) as Total_LanguageCount_,
XMIN(D3.Total_SkillCount_ ) as Total_SkillCount_
from
(select
……
) D2
full outer join
(select
……
) D3
on
((((D2.DivisionName = D3.DivisionName) and
(D2.LastName = D3.LastName)) and (D2.FirstName = D3.FirstName))
and (D2.sc = D3.sc)) order by DivisionName asc
This SQL indicates, through the use of the coalesce function in combination with the full outer
join, that two sub queries (D2 and D3) are sent to the database and then merged on the common
items from the shared/conformed dimensions, in this case DivisionName from Division and
FirstName and LastName from Staff.
In this scenario however, each of the facts are not correlated to one another. For example, the
report tells us that Maria Valenzuela speaks Spanish and has two skills, Cashier and Customer
Service, but it does not indicate that there is a Cashier as well as Customer Service
representative that can speak Spanish in the Furniture division.In other words, the report is not
showing language and skill combinations.
Fact Combination Analysis Solution
Looking at the diagram again, it is clear that the IBM Cognos 8 query engine is using fact
detection through the cardinality settings on StaffLanguageFact and StaffSkillsFact.

Both have only n cardinalities attached. In order to achieve combinations of facts based on the
dimension attributes included in the query, fact detection must be removed. This is done by
changing the n cardinalities to 1 on the fact side. Before this is done however, it is important to
examine the nature of the data. In this example, Division and Staff are separate
shared/conformed dimensions. Yet each staff member must belong to a Division. In this case, a
hierarchy of data can be established rather than two separate shared/conformed dimensions.
This can be accomplished in two ways. The tables can be merged and flattened in the data
source to include the division and staff hierarchy in one table, or a relationship can be
established from Division to Staff (snowflake dimension), as shown below, instead of Division
to each of the facts:
The next step is to change the cardinality from Staff to the facts to one-to-one as
shown below:
Now the fact tables will not be perceived as facts by the IBM Cognos 8 query engine and a stitch
query will not be performed. Instead all record combinations will be returned allowing for
combination analysis as seen in the report output below:

The report now shows two entries for Spanish for Maria Valenzuela; one combination for each
skill she possesses. The same applies for John Smith. There are now four records; one for each
language and skill combination.
It is important to note the summary totals for this report. This number now represents the total
number of combinations and not the total number of languages spoken or skills for the
divisions as in the previous report. Authors and consumers must be aware of this.
The SQL generated for this type of report appears below:
select
Division.DivisionName as DivisionName,
Staff.LastName as LastName,
Staff.FirstName as FirstName,
Language_.LanguageName as LanguageName,
XSUM(StaffLanguageFact.LanguageCount for
Division.DivisionName,Skills.SkillName,Language_.LanguageName,Staff.
LastName,Staff.FirstName ) as LanguageCount,
Skills.SkillName as SkillName,
XSUM(StaffSkillsFact.SkillCount for
Division.DivisionName,Skills.SkillName,Language_.LanguageName,Staff.
LastName,Staff.FirstName ) as SkillCount,
XSUM(XSUM(StaffLanguageFact.LanguageCount for
Division.DivisionName,Skills.SkillName,Language_.LanguageName,Staff.
LastName,Staff.FirstName ) at
Division.DivisionName,Skills.SkillName,Language_.LanguageName,Staff.
LastName,Staff.FirstName ) as Total_LanguageCount_,
XSUM(XSUM(StaffSkillsFact.SkillCount for
Division.DivisionName,Skills.SkillName,Language_.LanguageName,Staff.
LastName,Staff.FirstName ) at
Division.DivisionName,Skills.SkillName,Language_.LanguageName,Staff.
LastName,Staff.FirstName ) as Total_SkillCount_
from
( HRSample.HRSample.Conformed.Skills Skills join
HRSample.HRSample.Person.StaffSkillsFact StaffSkillsFact on
(Skills.SkillID = StaffSkillsFact.SkillsID) join
HRSample.HRSample.Conformed.Staff Staff on (Staff.StaffID =
StaffSkillsFact.StaffID) join HRSample.HRSample.Conformed.Division
Division on (Division.DivisionID = Staff.DivisionID) ) left outer
join ( HRSample.HRSample.Conformed."Language" Language_ join
HRSample.HRSample.Person.StaffLanguageFact StaffLanguageFact on
(Language_.LanguageID = StaffLanguageFact.LanguageID) ) on
(Staff.StaffID = StaffLanguageFact.StaffID)
group by
Division.DivisionName,
Staff.LastName,
Staff.FirstName,
Language_.LanguageName,
Skills.SkillName
order by
DivisionName asc
In this SQL, in the "from" clause, one can see all the tables are joined together, thereby bringing
back every record combination. This is quite different than the stitch query where two sub
queries were merged through a full outer join.
MULTI FACT QUERY IS ALSO CALLED AS STITCHED QUERY
C. Aggregate Tables
Aggregate tables contain primarily quantitative data aggregated to a single level or multiple
levels.
Example: Aggregate Tables With Dimensional Information
A query subject has internal cardinality and there are quantitative items that are associated to
levels above the lowest level. In this example, the GEO_POP query subject has populations for
each level of the geographic hierarchy.

Once dimensional information is specified, the query is written to prevent aggregating repeated
values for a given key.
select
GEO_POP.COUNTRY as COUNTRY,
XSUM(GEO_POP.COUNTRY_POP for GEO_POP.COUNTRY ) as COUNTRY_POP
from
(select
GEO_POP.COUNTRY as COUNTRY,
XMIN(GEO_POP.COUNTRY_POP for GEO_POP.COUNTRY ) as COUNTRY_POP
from
GEO_POP
group by
GEO_POP.COUNTRY
) GEO_POP
group by
GEO_POP.COUNTRY

Example: Incorrect Result Without Dimensional Information

Without specifying dimensional information, a query against any of the higher levels with its
population will result in double counting. In this example, populations for Cities get added to
the already summarized values for State, which in turn get added to the summary value for the
Country.
Note: If you do not associate an item to a level, Framework Manager will assume that it is
associated to the lowest level (that is, that it can be safely aggregated using all rows).
select
GEO_POP.COUNTRY as COUNTRY,
XSUM(GEO_POP.COUNTRY_POP for GEO_POP.COUNTRY ) as COUNTRY_POP
from
GEO_POP GEO_POP
group by
GEO_POP.COUNTRY

D. Multiple Hierarchies
You can specify multiple hierarchies implicitly or explicitly in Framework Manager. With
multiple hierarchies specified implicitly, the query engine will select a hierarchy at runtime
based on the query items selected by the user.
If the user selects more query items from one hierarchy than the other, that is the hierarchy to be
applied to any aggregations performed on the data automatically.

If you wish to allow your users to be aware of and to select the hierarchy that they wish to use,
we recommend that you create separate model query subjects for each hierarchy. The
advantage is that you can customize query item names and include only those items that are
relevant to the particular hierarchy.
Define Determinants in Cognos 8(Dimensional Information in CRN)
CASE 1: A Determinant is the set of database columns (query items) that can be used to
uniquely identify a set of data. Determinants are imported based on key and
Index Information
Determinants will be used to do one of the following:
 Add the information about functional dependencies between columns to avoid double
counting
 Specify the granularity of a denormalized query subject to control grouping and double-
counting when using model dimension
For example,some facts joins to time on Month and some facts joins on day.Specify
Determinants for time to clearly capture the functional dependency month and day as a
minimum to prevent double-counting for those facts that join at month key
 Uniquely identify the row of data when retrieving text BLOB data from data source
 Override the Determinants imported from the data source that conflict the relationships
created for reporting.
For Example, there are determinants on two query subjects for multiple columns but the
relationship between the query subjects uses only a subset of these columns. Modify the
Determinant information of the Query Subject if it is not appropriate to use the
additional columns in the relationships.
Defining Dimensions and Determinants
Use dimensions and determinants to ensure that the aggregation in reports is correct and that
queries generate correctly.
Use regular dimensions to organize and present descriptive information to guide the end user
experience in the report authoring tools. Hierarchies are presented in a top-down format, from
the coarsest level of granularity to the finest.
Data source regular dimensions treat hierarchy and level information as if they are
determinants.
Model regular dimensions require determinants to be specified for the underlying query
subjects.
Use determinants to specify which data is unique.
If a determinant defines attributes, all query items in the query subject must be defined as either
a key or an attribute. You can have a determinant with no attributes defined for it. Framework
Manager uses this type of determinant to indicate which query items are indexed.
Joins and granularity are the key factors in SQL generation. Specify granularity for the objects
that have relationships by using either a hierarchy or determinants on the object to which the
join is created.
You must use regular and measure dimensions to enable analysis on your relational data
source. In most data sources, regular dimensions, which contain descriptive information, are
likely to be shared by more than one measure dimension. Regular dimensions are often called
shared dimensions. Regular and measure dimensions organized into a cluster is often referred
to as a star schema group but can also be referred to as a functional or subject area group.

Measure dimensions are related to each other through the regular dimensions. To create reports
that fully compare and contrast functional areas, you may need to use more than one measure
dimension in a report.
When querying across star schemas or functional areas, you must consider the role the
hierarchy plays in query generation:
• Multiple-fact, multiple-grain queries (p. 17)
• Multiple hierarchies (p. 21)
Multiple-fact, Multiple-grain Queries
Multiple-fact, multiple grain queries occur when dimensions are related to multiple fact tables
at different levels. A dimension typically has distinct levels of attribute data with business keys
that have a hierarchical relationship to each other. The report authoring tools automatically
aggregate to the lowest common level present in the report. The hierarchical relationship
between level keys is used to aggregate data to the lowest level included in the report. The
potential for double-counting arises when creating totals on columns that may contain repeated
data. When the level of granularity of the data is modeled correctly, double-counting can be
avoided.
Note: You can report data at a level of a hierarchy below which it exists. This causes the data to
repeat across members at that level, but the totals are not affected.
This example shows two data source measure dimensions, Sales and Product forecast, that
share two regular dimensions, Time and Product.
The Time dimension is the focal point of the granularity issue in this example. In the underlying
data source, Sales is joined to Time on the Day key, and Product forecast is joined to Time on
the Month key. Because of the different join keys, a minimum of two levels must be clearly
identified with keys for the Time Dimension.
Data Source Dimensions
When using data source dimensions, we recommend that you create all levels that may be
necessary for reporting instead of only those levels that are immediately necessary.
For example, the levels for Month and Day have their keys identified. Day is the lowest level of
the hierarchy, and the Unique Level box is selected because this data is unique in the
underlying data source.
For example, the level definitions for Month are as follows.
For example, the level definitions for Day are as follows.
The Product dimension has three levels: Product line, Product type, and Product. It has
relationships to both fact tables on the Product key. All joins in the underlying tables occur on
the Product key so there are no granularity issues for this dimension. Any hierarchy that you
create is purely for the purpose of drilling and rollup.

By default, a report is aggregated to retrieve records from each fact table at the lowest common
level of granularity. If you create a report that uses Quantity from Sales, Expected volume from
Product forecast, Month_name from the Time dimension, and Product_name from the Product
dimension, the report retrieves records from each fact table at the lowest common level of
granularity. In this example, it is at the month and product level.

If you do not specify the levels of the hierarchy properly in the Time dimension, incorrect
aggregation may occur. For example, Expected volume values that exist at the Month level in
Product forecast is rolled up based on the lower time level, days, in the Time dimension. The
values for Expected volume are multiplied by the number of days in the month.
To prevent double-counting when data exists at multiple levels of granularity, create a
hierarchy for the Time dimension and correctly specify the levels with keys.
Note the different numbers in the Expected Volume column. Double-counting was prevented.

Model Regular Dimensions and Query Subjects with Determinants

Determinants are not the same as levels and hierarchies but they can be closely related to a
single hierarchy. The query engine evaluates determinants from first to last. One or more
determinants may be specified.
If a model regular dimension is based on a query subject with determinants specified, we
recommend that
• one level correspond to each determinant that exists in the query subject
• the order of the levels in the hierarchy reflect the order of the determinants
This results in a consistent model, facilitating upgrading the model in future releases of Cognos
products.
When using model dimensions, you begin with the query subjects that are the basis for the
Dimension. We recommend that you create a determinant for each level that may be necessary
for reporting instead of only those levels that are immediately necessary.
For example, here is a solution for the Time dimension that is an alternative to using
dimensions as previously described. Determinants are defined for Month and Day. Note that
Day is the lowest level of the hierarchy.
For example, the determinants for Month are as follows.
For example, the determinants for Day are as follows.

The Uniquely Identified check box is selected for only the lowest level of the hierarchy because
the data in this column is unique for every row in the underlying data source.
The Group By check box is selected for all levels whose data is not unique. If aggregation on an
associated attribute is required, the key defined for the determinant should be used in a Group
By clause in the query. Also, if an attribute of a Group By level is included in a query, a
Minimum aggregate function may be used to ensure that the value is unique in the query.

The hierarchy for the model regular dimension would be the same as the one shown for the
data source dimension.

Multiple Hierarchies
Multiple hierarchies occur when different structural views can be applied to the same data.
Depending on the nature of the hierarchies and the required reports, you may need to evaluate
the modeling technique applied to a particular case.

You can specify multiple hierarchies on regular dimensions in Framework Manager. Multiple
hierarchies for a regular dimension behave as views of the same query. You cannot use the
different hierarchies of the same dimension in a single report query.

For example, sales staff can be viewed by manager or geography. In the report authoring tools,
these hierarchies are separate but interchangeable logical structures, which are bound to the
same underlying query.
Here is sales staff as a single dimension with two hierarchies:

The hierarchies are defined in Framework Manager as follows.

If you need more than one hierarchy from a dimension in a report, such as on opposing axes,
you must create a regular dimension for each hierarchy. Each regular dimension must be a
single distinct hierarchy. In this way, you can issue the same, or slightly different, block of SQL
multiple times.
Here are separate dimensions for each hierarchy.
Use this approach if dramatically different sets of columns are relevant for each hierarchy and it
is more intuitive for end users to model the hierarchies as separate dimensions with separate
and simpler queries.

CASE 2: The key of performing multi fact multi grain queries is by using a conformed
dimension shared between both fact tables. When retrieving 2 measures from two different fact
tables using a different granularity, Cognos can determine the correct aggregation when
determinants are specified. A determinant will specify what set of columns will uniquely define
a dataset. This will enable the report developer to create a report showing revenue at week level
versus Full Time Equivalents at month level without double counting the lowest grain fact !
Cognos uses the mechanism of stitch queries to perform this type of requests. A stitch query
will perform a full outer join to break queries into multiple selects, one for each fact table and
then stitch the data back together.

CASE 3: By modifying determinants, you can override the index and key information in your
data source,
An example of a unique determinant is Day in the Time example below. An example of a non
unique determinant is Month; the key in Month is repeated for the number of days in a
particular month. When you define a non-unique determinant, you should specify group by.
This indicates to IBM Cognos 8 that when the keys or attributes associated with that
determinant are repeated in the data, it should apply aggregate functions and grouping to
avoid double-counting. It is not recommended that you specify determinants that have both
uniquely identified and group by selected or have neither selected.

You can define three determinants for this data set as follows -- two group by determinants
(Year and Month) and one unique determinant (Day). The concept is similar but not identical to
the concept of levels and hierarchies.
In this case, we use only one key for each determinant because each key contains enough
information to identify a group within the data. Often Month is a challenge if the key does not
contain enough information to clarify which year the month belongs to. In this case, however,
the Month key includes the Year key and so, by itself, is enough to identify months as a sub-
grouping of years.
Note: While you can create a determinant that groups months without the context of years, this
is a less common choice for reporting because all data for February of all years would be
grouped together instead of all data for February 2006 being grouped together.
When to Use Determinants
While determinants can be used to solve a variety of problems related to data granularity, you
should always use them in the following primary cases:
● A query subject that behaves as a dimension has multiple levels of granularity and will be
joined on different sets of keys to fact data.
For example, Time has multiple levels, and it is joined to Inventory on the Month Key and to
Sales on the Day Key. For more information, see "Multiple-fact, Multiple-grain Queries" (p. 324).
● There is a need to count or perform other aggregate functions on a key or attribute that is
repeated.
For example, Time has a Month Key and an attribute, Days in the month, that is repeated for
each day. If you want to use Days in the month in a report, you do not want the sum of Days
in the month for each day in the month. Instead, you want the unique value of Days in the
month for the chosen Month Key. In SQL, that is XMIN(Days in the month for Month_Key).
There is also a Group by clause in the Cognos SQL.
There are less common cases when you need to use determinants:
● You want to uniquely identify the row of data when retrieving text BLOB data from the data
source.
Querying blobs requires additional key or index type information. If this information is not
Present in the data source, you can add it using determinants. Override the determinants
Imported from the data source that conflict with relationships created for reporting.
You cannot use multiple-segment keys when the query subject accesses blob data. With
summary queries, blob data must be retrieved separately from the summary portion of the
query. To do this, you need a key that uniquely identifies the row and the key must not have
multiple segments.
● A join is specified that uses fewer keys than a unique determinant that is specified for a query
subject.
If your join is built on a subset of the columns that are referenced by the keys of a unique
determinant on the 0..1 or 1..1 side of the relationships, there will be a conflict. Resolve this
conflict by modifying the relationship to fully agree with the determinant or by modifying the
determinant to support the relationship.
● You want to override the determinants imported from the data source that conflict with
relationships created for reporting.
For example, there are determinants on two query subjects for multiple columns but the
relationship between the query subjects uses only a subset of these columns. Modify the
determinant information of the query subject if it is not appropriate to use the additional
columns in the relationship.
Specify a Determinant
Determinants provide control over granularity for query subjects.
If a query subject has determinants, each query item of the query subject must be included in
one of the determinants.
Determinants are processed in the order in which they are specified in the model. You can
change the order of the determinants. If a query subject has more than one determinant, the first
one that covers all the requested items is used. Determinants are evaluated in the context of
each required join as well as the context of requested items.
Data source query subjects are imported with determinants defined for them. These default
determinants are generated based on keys and indexes in the data source.
Constraints
Model query subjects do not have determinants defined for them automatically. If determinants
are needed, you must define them manually.
Stored procedure query subjects do not have determinants.
You cannot use determinants with user-entered SQL that was specified in a query defined in
Report Studio.
Steps
1. Click the query subject you want and, from the Actions menu, click Edit Definition.
2. Click the Determinants tab.
3. To add a query item to a determinant, select the query item from the Available items box and
Click Add.
4. To specify that the selected query item is the lowest level of the hierarchy and should be used
as the unique identifier, select the Uniquely Identified check box.
Do this only if the data in this item is unique for every row in the underlying data source.
If you define a determinant as unique and you select the Group By check box, grouping is
Applied after the determinants are processed. The Group By clause is used in the generated
SQL, which enables aggregate functions in the data source to be used in IBM Cognos 8.
If you have multiple determinants with Uniquely Identified check box selected, only the
Group
By setting of the first determinant is used. This is because the processing of determinants stops
at the first determinant with Uniquely Identified check box selected.
5. To indicate that, when the keys or attributes associated with the determinant are repeated in
the data, IBM Cognos 8 should apply aggregate functions and grouping to avoid double
counting,
select the Group By check box.
It is not recommended that you specify determinants that have both uniquely identified and
group by selected or have neither selected.
6. To define a key, right-click one or more query items in the Available items box and click Add
as Key.
You can also drag query items to the Key box.
7. To identify which query items users must report on, right-click query items in the Available
items box and click Add as Attributes.
You can also drag query items to the Attributes box.
If a determinant defines attributes, all query items in the query subject must be associated with
the determinant and defined as either a key or an attribute. You can have a determinant with
no attributes defined for it. Framework Manager uses this type of determinant to indicate which
query items are indexed.
8. If you want to change the order of the determinants, use the arrow buttons.
Determinants are processed in the order in which they are specified in the model.
The Effect of Determinants on SQL
It is important to understand the effect that determinants have on the SQL that is generated.
Determinants affect the grouping and aggregation of data, including other query subjects that
have
relationships with the query subject as well as the query subject itself.

For example, consider the following information. Each Product Line contains many occurrences
of
Product Type. Each Product Type contains many occurrences of Product. For Product, Product
Key is a surrogate key and Product Number is a business key that is used as an attribute. Data
joined on Product Key is aggregated correctly when reported by Product Line or Product Type
or
both.

CASE 4:
Determinants are designed to provide control over granularity in a similar, but not identical,
way as dimension information in Cognos ReportNet. A determinant can define the set of
database columns (query items) that uniquely identify a set of data, or it can identify a set of
columns that identify a non-unique set within the data.
Determinants are most closely related to the concept of keys and indexes in the data source and
are imported based on key and index information in the data source. We recommend that you
always review the determinants that are imported. There is no concept of hierarchy in
determinants. The order in which they are specified governs
the order in which they are evaluated.

Use determinants in the following cases:

• Joins exist at multiple levels of granularity for a single query subject. An example is the Time
dimension in the Go Data Warehouse sample model. There are joins
to the Time dimension on the day key and on the month key. Determinants are used for the
Time dimension when you want to prevent double-counting for multiple-fact queries. For
example, some facts join to time on month and some facts join to time on day. Specify
determinants for time to clearly capture the functional dependency between month and day as
a minimum to prevent double-counting for those facts that join at the month key.
• BLOB data types exist in the query subject. Querying blobs requires additional key or index
type information. If this information is not present in the data source, you can add it using
determinants. Override the determinants imported from the data source that conflict with
relationships created for reporting. For example, there are determinants on two query subjects
for multiple columns but the
relationship between the query subjects uses only a subset of these columns. Modify the
determinant information of the query subject if it is not appropriate to use the additional
columns in the relationship.
• A join is specified that uses fewer keys than a unique determinant that is specified for a query
subject. If your join is built on fewer columns than what is stored in Framework Manager within
the determinants, there will be a conflict. Resolve this conflict by modifying the relationship to
fully agree with the determinant or by modifying the determinant to support the relationship.
Dimension, Hierarchy, Level etc., Examples across Relational and Dimensional Modeling.
Relational Dimensional
Related subjects from tables/folders Hierarchy
Identifier query item/dimension item Level
Fact query item/value Measure
Attribute query item/descriptor Attribute item
Nested grouping of dimension items Nested children or descendants
Detail filter on dimension items Member sets, on edge or in slicer
Detail filter on attribute Filter function using attribute on edge or slicer
List report Cross-tab report
Summary FOR Summary WITHIN SET
Drill-through by value(s) Drill-through by member
Use Relational reports for most detail and Use Dimensional Reports for most Cross-tab,
list style reports. Relational reports are also Summary reports. Dimensional reports are
the standard when reporting against data standard when reporting against OLAP data
marts, even dimensionally modeled Star sources and DMR models in Framework
Schema designs. Avoid complex Cross-tabs Packages. Do not try to do detail lists in
in Relational Model. Dimensional Reports.
How to Resolve Double Counting issue by defining Dimensional Information in CRN
CASE1: The primary purpose of dimensional information in Framework Manager is to prevent
double-counting.
 Identify the levels that are relevant for reporting purposes
 Identify the key(s) for those levels and if those keys uniquely identify the members of
their respective levels.
 Identify any attributes associated to levels
 Identify the hierarchy of the levels – the relationship between levels.
  Multiple hierarchies may exist, it is recommended that these be explicitly modeled with
additional query subjects.
 Star style dimension tables are perfect candidates for dimensional information because
they typically have more than one level and they include attributes that are associated to
more than one level.
Use dimensional information to specify the relationship between levels in a multi-level
dimension.
For example, there is a time dimension table that contains keys for days, months,
quarters, and years. Day key is the primary key of the table, however, there are also keys
for month, quarter and current_year, each of which can uniquely identify the data at
their respective levels and could relate directly to facts in the database.
In order to define the behavior expected when querying at a one or more levels of time,
dimensional information is used. Levels are defined for years, quarters, months, and
days. A key is defined for each level and in this example, that key is sufficient to
uniquely identify the level. A hierarchy is defined to specify the relationships between
the levels: days roll up to months, months to quarters, and quarters to years. Attributes
and facts can also be defined for each level. Any attribute or fact that is not explicitly
associated to a level will be treated by default as if it were associated to the lowest level
(day).

When performing multi-fact queries between facts at different levels of granularity, dimension
information on conformed dimensions ensures correct behavior when a multi-fact query is
submitted and each fact is recorded for a different time period (daily versus monthly, for
example). The query engine will use its understanding of the relationship between days and
months from the defined dimensional information to ensure that data is rolled up correctly.

CASE2:
1. Associate measures with levels to ensure proper aggregation
a. For example, to avoid double counting in queries
2. Define keys for groups for query efficiency
3. Model aggregate tables
4. Model multi-grain aggregate tables
Note that dimensions do not appear in the Report Studio and Query Studio user
interfaces as they are intended for query planning and not for user exposure.
Dimensions are optionally defined on each query subject and use only the query
items defined therein.
What are the levels in your dimension?
• What is the order and combination of levels that form hierarchies.
• How do you uniquely identify the members of a level, is it unique (one
query item) or does it require multiple query items?
• Association of levels with attributes and measures.
• At what level of granularity is your fact data, do you have more than one
level of granularity? Ie. Is some of your data recorded monthly and some
daily, this would mean that you would have a fact tables relating to your
time dimension table at the month and day levels.
• Are there surrogate keys defined in your data source?
Identify the levels, level keys, level attributes and hierarchy(ies)
of your dimension.
A star schema might have a table that looks like:

It can be observed from this data that product lines have multiple product types and product
types have one or more products. The cardinality of the product line-product type relationship
and the product type-product relationship should be verified. A hierarchy that might be useful
for reporting would have the levels Product Line, Product Type and Products and would be
structured so that Products relate to and are children of Product Types, and Product Types
relate to and are children of Product Lines. Once it is clear what the levels are and what
the relationships are between the levels it is important to determine what uniquely identifies a
level (the key) and which data elements are associated to each level. In this case Product_Line is
a unique identifier for the Product Line level, Product_Type is a unique identifier for the
Product Type level and Product_Key is a unique identifier for the Product level with
Product_Number and Product_Image as attributes. You may wonder why Product Key was
chosen as the identifier for the Product level instead of Product Number. The answer is
that the datasource is a warehouse that uses surrogate keys and Product Key is the surrogate
key for the Product dimension table. Product Number is also an identifier but it is regarded as a
business key and will be treated as an attribute when specifying the dimensional information in
Framework Manager. The dimensional information is summarized in the following table:
Dimensional Information and SQL Generation
It is important when specifying your dimensional information to understand the affect this will
have on the SQL that is generated. Dimensional information affects grouping and aggregation
of data, not only from the dimension data source but also from other data sources that have
relationships with that dimension. Specifying hierarchies for a query subject using query items
as levels, either individual or combinations of query items as keys, and associating query items
to the appropriate levels as attributes provides FM with enough information to automatically
group and aggregate data according to the hierarchies you have specified. Hierarchies in this
case can be thought of as ways of specifying the order in which data segmented into levels can
be grouped.
With the dimensional information specified in the model it will no longer be necessary for a
report writer to understand the relationships between the data elements and do explicit
grouping in a report in order to get correctly aggregated data. The model will have sufficient
information to write the correct SQL so that data joined on Product_Key can be aggregated
properly when reported by Product Line or Product Type or both.
Overview of Dimensional Information Components and their impact on ReportNet
The key is optional and used to identify a query item(s) that guarantee uniqueness. By default
the query item that is the level is set as the key. A single query item key is used when one item
uniquely identifies the level - for example, product number uniquely identifies each product. . If
a single query item determines uniqueness, then use the Unique Key option to inform
ReportNet.

Multiple part keys are used when two or more query items are required to uniquely identify the
level - for example, the combination of country and city are required to uniquely identify each
city. Note that each level must be uniquely identified on its own, not by other levels within a
hierarchy.

Facts are associated with levels to tell ReportNet which quantitative query items can be
aggregated against that level. For example, if a query subject had the country and city query
items and a population column, ReportNet would need to know whether the population was
for the country or the city. Where facts are stored at different grains (for different levels) in the
same table, ReportNet needs to know which facts are associated with each level. For example, a
query subject with country and city might have two population query items one for
country and one for city. By properly associating the fact with the appropriate level in
Framework Manager, you ensure that ReportNet will correctly aggregate the facts avoiding
such issues as double counting.

Attributes are qualitative columns which share a 1 to 1 relationship with the level. For example,
a product description exists for each product. Attributes are columns which are generally not
aggregated.
Once levels have been defined they can optionally be used in hierarchies.
ReportNet will attempt to derive hierarchies if they are not set. The hierarchies establish the
relationship between the levels - for example, a hierarchy of country - city tells ReportNet that
country is a higher level grouping to city.

Before Specifying Dimensional Information in FM ensure that you have verified

your relationships, query item usages and aggregation properties.

Create Star Schema Grouping:

CASE1: Star Schema Grouping will be created to identify the Confirmed Dimension.Star
Schema also enables Multi-Fact Querying.
Multiple Confirmed Star Schemas:
In dimensionally modeled data, it is likely that you will see fact query subjects that share
dimension query subjects, resulting in what looks like a web in your diagram. Join ambiguity is
an issue in this situation, when you use multiple dimensions without any items from the fact
table.
For example, with the relationships above, how do you write a report that lists Products and
Year? The business question may be which products were in inventory in 2002 or it may be
which products were sold in 2002. Although this query involves only the time and product
dimensions, these dimensions are related via multiple fact tables. Given the option to relate
these dimensions on the Orders fact table or the Returns fact table how do you let the user
choose which context they are interested in?
Set the Context of a Query
The way to resolve this join ambiguity is to create star schema groupings:

• select a fact table

• choose Create Star Schema Grouping from the menu
• choose the dimensions you want from a list in the wizard
• choose the options to create shortcuts for all query subjects and move to a new namespace

By doing this for all star schemas, you resolve join ambiguity by placing shortcuts to the fact
and all dimensions in a single namespace along with shortcuts to the relationships between
them. The shortcuts for conformed dimensions in each namespace will be identical and will be
references to the original object, thus it will be truly conformed.
With a namespace created for each star schema, it will now be clear to a business user that to
write a report on Products Sold in 2002, they will choose Product and Year from the Sales Fact
Namespace. Because a relationship between Product, Time and Sales Fact is the only
relationship available in this context, it will be used to return the data.

CASE2:
Star schema groups can make the model more intuitive for end users by indicating which
regular dimensions and measure dimensions are related. Star schema groups can also facilitate
multiple-fact reporting by indicating how to use regular dimensions that are common to many
measure dimensions. Multiple-fact reporting is also known as cross-functional reporting.

Star schema groups also provide context for queries with ambiguous joins. By creating star
schema groups in the business view of the model, you can clarify which join path to select when
multiple join paths are available. This is particularly useful for fact-less queries.
Multiple Conformed Star Schemas or Fact-less Queries
You will likely see conformed regular dimensions between measure dimensions. Join ambiguity
is an issue when you report using items from multiple dimensions without including any items
from the measure dimension. This is called a fact-less query.

For example, Product and Time are regular dimensions related to the Product forecast and Sales
measure dimensions.

Using these relationships, how do you write a report that uses only the Product and Year items?
The business question could be which products were forecasted for sale in 2005 or which
products were actually sold in 2005. Although this query involves only the Product and Time
dimensions, these dimensions are related through multiple measure dimensions. There is no
way to guess which business question is being asked. You must set the context for the fact-less
query.
In this example, we recommend that you create two namespaces, one containing Product, Time,
and Product forecast, and another containing Product, Time, and Sales.
When you create these namespaces, use the Create Star Schema Grouping wizard to select the
correct dimensions for each measure, create shortcuts for all objects, and move the shortcuts to a
new namespace.
When you do this for all star schemas, you resolve join ambiguity by placing shortcuts to the
measure dimension and all regular dimensions in a single namespace. The shortcuts for
conformed dimensions in each namespace are identical and are references to the original object.

With a namespace for each star schema, it is now clear to the end users which items to use. To
create a report on Products Sold in 2005, they use Product and Year from the Sales Namespace.
The only relationship that is relevant in this context is the relationship between Product, Time,
and Sales Fact, and it is used to return the data.

CASE3:
Use the Star Schema Grouping wizard to quickly create groups of shortcuts that will provide
context for your users regarding which objects belong together. This makes the model more
intuitive for your users. Star schema groups can also facilitate multiple-fact reporting by
allowing the repetition of shared dimensions in different groups. This helps your users to see
what different groups have in common and how they can do cross-functional, or multiple-fact,
reporting. For more information, see "Multiple-fact, Multiple-grain Queries" (p. 324).

Star schema groups also provide context for queries with multiple join paths. By creating star
schema groups in the business view of the model, you can clarify which join path to select when
many are available. This is particularly useful for fact-less queries.

In a star schema design, numeric, transactional data is contained in a central fact table with
related dimension tables radiating out from the fact table.
Star schema groups can contain the selected dimensions, query subjects, or shortcuts. The
objects in a star schema group cannot reference, or be referenced by, any object outside the
group. Therefore, Framework Manager automatically creates a shortcut for any object that is
referenced by an object outside the group.
For example, in a project for sales analysis, you include these dimensions:
● dates of sales (Time)
● locations of sales (Region)
● product details (Product)
● customer information (Customer)
You include quantity in the fact table.
Steps
1. Select one or more dimensions or query subjects.
2. From the Tools menu, click Create Star Schema Grouping.
3. If you want to exclude an object from the group, in the Available objects box, clear the check
box next to the object.
4. Do one of the following:
● To add shortcuts to the group, click Create a shortcut for all selected objects.
● To move the objects to the group, click Create shortcuts only for objects that are used
outside the star schema.
5. To move the selected objects to a separate namespace, ensure that the Create a new
namespace
for this grouping check box is selected and type the name in the Namespace name box.
6. Click OK.
7. If there are multiple relationships, also known as role-playing dimensions, create relationship
shortcuts for them (p. 73), or create individual dimensions or query subjects if you must rename
them.
A Star Schema Group Based on One Dimension or Query Subject
Generally, you select a single object when it is a fact that has a relationship to every dimension
or query subject that you want in the star schema group. When you create a star schema group
that is based on one object, the following occurs:
● Framework Manager shows a list of objects with which it has relationships so that you can
quickly select the objects that you want in the group.
● The name of the group is based on the name of the fact table.
● The new group is created under the same parent as the selected object.
A Star Schema Group Based on Multiple Dimensions or Query Subjects
Selecting multiple dimensions or query subjects is useful if you want to group dimensions or
query subjects that do not already have relationships defined. The new group is placed under
the nearest common parent of the dimensions or query subjects.
Resolve Multiple Conformed Star Schemas
You will likely see dimensional query subjects that are joined to more than one fact query
subject.Join ambiguity is an issue when you report using items from multiple dimensions or
dimensional query subjects without including any items from the measure dimension or fact
query subject. This is called a fact-less query.
For example, Product and Time are related to the Product forecast and Sales facts.

Using these relationships, how do you write a report that uses only items from Product and
Time?The business question could be which products were forecasted for sale in 2005 or which
products were actually sold in 2005. Although this query involves only Product and Time, these
dimensions are related through multiple facts. There is no way to guess which business
question is being asked.You must set the context for the fact-less query.
In this example, we recommend that you create two namespaces, one containing shortcuts to
Product, Time, and Product forecast, and another containing Product, Time, and Sales.

When you do this for all star schemas, you resolve join ambiguity by placing shortcuts to the
fact and all dimensions in a single namespace. The shortcuts for conformed dimensions in each
namespace are identical and are references to the original object. Note: The exact same rule is
applied to regular dimensions and measure dimensions.

With a namespace for each star schema, it is now clear to your users which items to use. To
create a report on which products were actually sold in 2005, they use Product and Year from
the Sales Namespace. The only relationship that is relevant in this context is the relationship
between Product, Time, and Sales, and it is used to return the data.

Steps
1. Select one of the measure dimensions.
2. From the Tools menu, click Create Star Schema Grouping.
3. If you want to exclude an object from the group, in the Available objects box, clear the check
box next to the object.
4. Click Create a shortcut for all selected objects.
5. To move the selected objects to a separate namespace, ensure that the Create a new
namespace for this grouping check box is selected and type the name in the Namespace name
box.
6. Click OK.
7. Repeat these steps for the other measure dimension.

Model a Snowflaked Dimension as a Star Dimension

A snowflaked dimension removes low-level cardinality attributes from the dimension tables
and places them in secondary dimensions that are linked back to the original dimensions by
artificial keys.
To model a snowflaked dimension as a star dimension, do the following:
 Select the query subjects that are required to access the data, and put them in a new
namespace(p. 175).
 Ensure that all relationships are correct (p. 67).
 Handle multilingual metadata (p. 120).
 Create a model dimension for each snowflaked dimension:
 Select the query subjects you need.
 From the Actions menu, click Merge in New Regular Dimension.
 Rename the new model dimension. By default, its name is composed of the concatenated
names of the original objects.
 If you require multiple levels, do one of the following:
 Use the dimension map to define hierarchies and levels for the dimension (p. 105).
 Specify determinants if the levels are stored in a single query subject (p. 82).
 Regular Dimension
A regular dimension contains descriptive and business key information and organizes the
information in a hierarchy, from the highest level of granularity to the lowest. It usually has
multiple levels and may have multiple key segments to define a level. It may also have multiple
hierarchies.
Only a single hierarchy can be defined on a data source regular dimension.
Multiple-fact querying is enabled with conformed dimensions.
Model regular dimensions are based on data source or model query subjects that are already
defined in the model. You must define a business key and a string type caption for each level.
When you verify the model, the absence of business keys and caption information is detected.
Instead of joining model regular dimensions to measure dimensions, create joins on the
underlying query subjects and create a scope relationship between the regular dimension and
the measure dimension.
When creating regular dimensions, you must understand the dimensionality of the data. You
must
be able to answer the following questions:
● What are the levels in your dimension?
● What is the order and combination of levels that form hierarchies?
● What are the relationships between the levels?
● What uniquely identifies a level?
● Which data elements are associated at each level?
● Do you have more than one level of granularity, such as some data is recorded monthly and
some is recorded daily?
● Are foreign keys defined in the data source?
You can specify multiple hierarchies on regular dimensions in Framework Manager. Multiple
hierarchies for a regular dimension behave as views of the same query. However, you can use
only one hierarchy at a time in a query. For example, you cannot use one hierarchy in the rows
of a crosstab report and another hierarchy from the same dimension in the columns. If you need
both hierarchies in the same report, you must create two dimensions, one for each hierarchy.
In addition to creating regular dimensions, you can also merge dimensions into a single
dimension or convert query subjects to dimensions.
Multiple-fact querying is enabled with conformed dimensions.
While you can use data source dimensions, they have limited functionality in comparison to
query subjects or model dimensions. It is recommended that you discontinue using data source
dimensions (both regular and measure). Create new models following the recommendations in
"Guidelines for Modeling Metadata" (p. 317) to use query subjects as the relational foundation
of the model. Define regular and measure dimensions as model objects based on data source
query subjects or model query subjects or both. Guidance on migration for existing users of data
source dimensions will be provided in a future release.
Steps
1. Select a namespace or folder where you want to place the dimension.
2. From the Actions menu, click Create, Regular Dimension, and then click the Dimension tab.
3. Click the Dimension tab.
4. Click Add Hierarchy and then drag one or more objects from the Available items box to the
Hierarchies box.
You can define multiple hierarchies for a dimension. The first hierarchy is used as the default,
or primary, hierarchy.
You can also create an alternate hierarchy by copying a level. Click a level and drag it to the
right border of the dimension. You can only copy a level within the same dimension.
5. Click Add Level and then drag one or more objects from the Available items box into the
new level.
You can also create copies of levels in the Dimension Definition dialog box or in the
Dimension Map tab. Click the level and drag it to another position in the hierarchy. All
attributes of the level are also copied. You can only copy a level within the same dimension.
6. If you want to use a different item in a level, drag it from the Available items box to the
Select a level in the hierarchy control to see the query items box.
You are prompted to specify its role.
By default, Framework Manager adds the name of the namespace.
Tip: To have a multiple-part key such as first name plus last name, create a new attribute that
combines the items, and then specify that the new attribute is the business key.
7. If you want to indicate that the keys of the levels above the current level are not necessary to
identify the members in this level, select the item and select the Unique Level check box.
Do this only if the key values are unique regardless of their context, such as postal code values.
8. Choose the additional tasks that you want to perform:
● Specify roles (p. 112).
● Embed calculations by clicking Add and then defining the expression (p. 144).
To change a calculation that has been embedded in the dimension, in the Dimension Map
tab, click Attributes, right-click the query item, and click Edit Expression.
● Embed filters (p. 146).
● Specify the sort characteristics of levels (p. 111) .
● Test the dimension (p. 117).
● Edit the SQL and change various options (p. 99).
9. Click OK.
10. To change the default hierarchy for a dimension with multiple hierarchies, do the following:
● In the Properties pane, click the ellipsis (...) button in the Default Hierarchy box.
● Select a different hierarchy, and click OK.
You can also use the Dimension Map tab to create a regular dimension. Click the regular
dimension Button.

Hierarchies for a Regular Dimension

Information about hierarchies for SAP BW metadata appears in different topics (p. 191) and (p.
185).
A hierarchy is an ordered list of levels or a collection of items. Each query item in a hierarchy
must have a unique name.
You can specify multiple hierarchies on regular dimensions in Framework Manager. Multiple
hierarchies for a regular dimension behave as views of the same query. The first hierarchy is the
primary or default hierarchy.
You can use only one hierarchy at a time in a query. For example, you cannot use one hierarchy
in the rows of a crosstab report and another hierarchy from the same dimension in the columns.
If you need both hierarchies in the same report, you must create two dimensions, one for each
hierarchy.
For example, sales staff can be viewed by manager or by sales branch and can be modeled as a
single dimension with two hierarchies.

If you need both hierarchies in the same report query, such as on opposing axes, you must
create a regular dimension for each hierarchy. For example, here is sales staff as two
dimensions.

Tip: To change the default hierarchy for a dimension with multiple hierarchies, in the
Properties pane, click the ellipsis (...) button in the Default Hierarchy box, and select a different
hierarchy.
If a hierarchy in a dimension contains a large number of members, running a query in one of the
IBM Cognos 8 studios may be slow because the IBM Cognos 8 engine is generating one large
query for a locally-built cube. To resolve this issue, set the Wide Member Tree property in the
Properties pane to true. The engine will then generate multiple smaller queries for the locally-
built cube.
Balanced Hierarchy
Each path in a balanced hierarchy descends to the same depth.
For example, in the following diagram, the highest level is Product Line. Level 2 is Product
Type.Level 3 is Products.

Unbalanced Hierarchy
The branches in an unbalanced hierarchy descend to different levels.
For example, in the following diagram, the highest level in an organization is the CEO. Level 2
is the vice-presidents and the CEO’s executive assistant. The executive assistant does not have
subordinates although the vice-presidents do.

An unbalanced hierarchy can also be ragged. In a ragged-unbalanced hierarchy, there are gaps
in the levels and the levels descend to different depths.
Ragged and Network Hierarchies
For relational metadata, we recommend that ragged hierarchies and network hierarchies be
flattened in the data source.
Levels for a Regular Dimension
The simplest definition of a level consists of a business key and a caption, each of these referring
to one query item. An instance (or row) of a level is defined as a member of that level. It is
identified by a member unique name, which contains the values of the business keys of the
current and higher levels. For example, [gosales].[Products].[ProductsOrg].[Product]->[All
Products]. [1].[1].[2] identifies a member that is on the fourth level, Product, of the hierarchy
ProductsOrg of the dimension [Products] that is in the namespace [gosales]. The caption for this
product is TrailChef Canteen, which is the name shown in the metadata tree and on the report.

The first level of the hierarchy is automatically defined as the All level. It contains a single root
member, which represents the top level of the hierarchy. For example, the All level for the Time
dimension is named Time (All). You cannot delete or move the All level. You can change its
name, description, and screen tip.
If you do not specify the levels of the hierarchy correctly, incorrect aggregation could occur.
Member Unique Names
The member unique name (MUN) is how the member is found in the data source, much like
using business keys to find records in a table.
The member unique name is used in the expression for a member data item that is used in a
report, a reference to members in filters and expressions, and used in drill-through between
OLAP data sources. The member keys in the MUN for the different OLAP data sources must
match.
If a member unique name changes, members that are directly referenced in expressions, filters,
or
reports are no longer found because the MUN is contained in the report specification. Member
unique names can change for a variety of reasons:
● Changes to the hierarchy and level structures may change the level unique name.
● The business key values have changed and this changed the member key path.
● The application changed during design or over time.
● The cube has category codes that are unpredictably unique.
● The production environment has more members than the test environment.
● The member no longer exists in the data source.
To avoid these problems, we recommend the following practices:
● Use unique codes and keys within a dimension for the member keys.
● Use unique conformed values for similar dimensions between the target and source
environments when enabling drill through.
● When using a dimensionally model relational model for drill-through, ensure the root
business key conforms with the root members of the other data sources.
● Ensure that the business keys and dimension metadata structure are the same between the
production and test environments.
● Do not change the business keys in Framework Manager after going into production.
● Resolve the non-unique keys within a dimension in the data source. Tildes are not
recommended in the category codes.
● If you have a Transformer cube that is built with non-unique source values, do not use the
Clean House feature in Transformer because it will most likely change the category codes. We
recommend that you keep a backup copy of your MDL file.
Keys for Levels
A key is a query item that uniquely identifies members in a level. For example, Product
Number uniquely identifies a product while City, State, and Country are all needed to uniquely
identify a city. The key may or may not be contained in a level. Foreign keys are used to relate
the measure dimension to its regular dimensions.
Each level needs an item that is defined as a key.
If a model dimension contains a query item whose data type is BLOB, create a query subject that
has determinants and then create a model dimension that is based on the model query subject.
Sort Members of a Level
For dimensionally modeled relational metadata, you can specify sort characteristics on a
dimension.
You can also specify sorting on individual levels within the dimension. When you sort
individual levels within a dimension, you can ensure that the order in which the data is
delivered to the model is appropriate. The order in which the data is delivered to the model can
be particularly important when reporting data over relative time periods.
The default sort order is alphabetical, in ascending order, depending on the level caption. When
you specify a sort order, the data is sorted on another column such as the business key.
Steps
1. In the Project Viewer pane, select a dimension or level.
2. From the Actions menu, click Edit Definition.
3. Click the Member Sort tab.
4. Select the sorting option to apply to the dimension.

Tips
● To apply the default sort order to all child levels within the levels in the dimension that do
not have a sort option defined, click Detect.
● To remove sort options from all child levels within the levels in the dimension, click Clear
All.
5. In the Select a Level to Assign Sort Properties box, click a level.
6. In the Available Data Items box, click an item to sort and click the right arrow to add it to the
Level Sort Properties box. Use the up and down arrows to change the order of items.
Tip: To change the sort order to ascending or descending, click Sort Order.
7. To specify how null values are sorted in reports, click the Nulls box beside the item and then
click First, Last, or Unspecified.
First places the null values at the beginning, and Last places the null values at the bottom.
Unspecified uses the setting defined in the data source.
8. Click OK.
Roles
Information about roles for SAP BW metadata appears in a different topic (p. 194).

Roles define what appears in the member tree in the IBM Cognos 8 studios. Use roles to
organize and manage metadata and to determine how to present data to your users.

You can also create expressions that refer to roles instead of query items. You must use the
roleValue function to refer to a particular role. For example, you want to query against a specific
role in a hierarchy but the query item playing that role is different at each level of the hierarchy.
A single query can span the different query items at each level. You can also use the roleValue
function when you know the role but not the underlying query item.

You can assign multiple roles to one query item, but the same role cannot be assigned to
different query items in the same level.

Default roles are pre-defined for all parent-child hierarchies and for all levels in level-based
hierarchies.Most of these roles are not visible in the IBM Cognos 8 studios.

The roles that are reserved by IBM Cognos 8 start with an underscore. The name for a custom
role cannot start with an underscore.
Default Roles
The default roles include the following:
● _businessKey
Represents the key for the level. The level can be defined as unique if the business key of the
level is sufficient to identify each set of data for a level.
The _businessKey role can be assigned to only one attribute in a level.
The Root Business Key property shows the value of the business key for the root member. The
root member is an artificial level created for dimensionally modeled relational models. To
enable drill-through on conforming dimensions, you must set the Root Business Key property.
● _memberCaption
Presents the caption for a member that will be shown in the IBM Cognos 8 studios.
The _memberCaption role is necessary to leverage member functions and to enable dragging
and dropping levels in the IBM Cognos 8 studios.
Ensure that the data type is set to string for the item that will be assigned the _memberCaption
role.
● _memberDescription
Returns the description for a member within a dimension.

Custom Roles
By default, attributes are included with no role. You can assign attributes to existing roles or
you can create custom roles. Each role that you create must have a unique name.
You can translate the custom roles in the model.
 Measure Dimension
A measure dimension is a collection of facts.
You can create a measure dimension for one or more query subjects that have a valid
relationship between them.
Information about modifying a key figures dimension for SAP BW metadata appears in a
different topic (p. 196).

A measure dimension is a collection of facts. You can create a measure dimension for one or
more query subjects that have a valid relationship between them.
Model measure dimensions should be composed of only quantitative items. Because, by design,

Model measure dimensions do not contain keys on which to join, it is not possible to create joins
to model measure dimensions. Instead of joining model measure dimensions to regular
dimensions,create joins on the underlying query subjects. Then either manually create a scope
relationship between them or detect scope if both dimensions are in the same namespace.

Only measures are visible in the model measure dimension. Query items, such as keys, are
hidden.

While you can use data source dimensions, they have limited functionality in comparison to
query subjects or model dimensions. It is recommended that you discontinue using data source
dimensions (both regular and measure). Create new models following the recommendations in
"Guidelines for Modeling Metadata" (p. 317) to use query subjects as the relational foundation
of the model. Define regular and measure dimensions as model objects based on data source
query subjects or model query subjects or both. Guidance on migration for existing users of data
source dimensions will be provided in a future release.

You can add value by embedding calculations based on existing business rules, such as Profit
Margin.

You can change the order of measures, query items, and calculations.
Constraints
If the measure dimension contains a folder, you can change the order only in the Project
Viewer.
You cannot define hierarchies or levels for a measure dimension.
Steps
1. Click a namespace where you want to place the measure dimension.
2. From the Actions menu, click Create, Measure Dimension.
3. Click the Measure Dimension tab.
4. Drag measures from the Model Objects box to the Measures box.
5. Perform the actions that you want.
Note: If you test the measure dimension by using the Query Information tab, IBM Cognos 8
validates the measure dimension. If you test the measure dimension by using the Test tab, IBM
Cognos 8 executes the measure dimension. The SQL for validate is slightly different than the
SQL for execute. To generate definitive SQL for the measure dimension, use the Test tab.
6. Click OK.
You can also use the Dimension Map tab to create a measure dimension. Click the measure
dimension button .
You may be interested in the following related topics:
● multiple measure dimensions that are related to dimensions at different levels (p. 324)
● embedded calculations (p. 144)
● embedded filters (p. 146)
● testing the measure dimension (p. 117)
Convert a Measure into a Query Item
If you have created a measure dimension and want to join it to regular dimensions, you need to
create joins. Joins need keys and keys are query items, not measures. The measure that you
want to use as a key must be converted into a query item.
You can also convert a query item into a measure (p. 143).
Steps
1. Double-click the measure dimension that contains the measure.
2. Click the Measure Dimension tab.
3. Right-click the measure and click Convert to Query Item.
4. Click OK
Scope Relationship
CASE 1:Scope relationships exist between measure dimensions and regular dimensions to
define the level at which the measures are available for reporting. Scope relationships govern
the reporting
granularity of the regular dimension for a particular measure dimension.

Scope relationships are mandatory between measures and dimensions when reporting. The
absence of a scope relationship results in an error at runtime. Scope relationships are for
reporting purposes. They are not the same as joins and do not impact the Where clause.
You can use scope relationships to include or exclude the regular dimension from the star
schema group.

Shortcuts cannot be created for scope relationships. Scope relationships can exist only between
regular and measure dimensions. Scope relationships can also be created for shortcuts to
dimension objects. When shortcuts to dimensions are used, the scope is derived from the scope
of the target objects unless scope has been explicitly defined on the shortcuts.

CASE2:
Scope relationships are necessary to define which dimensions and measures are used together
for dimensionally modeled relational models.

Scope relationships exist only between measure dimensions and regular dimensions to define
the level at which the measures are available for reporting. They are not the same as joins and
do not impact the Where clause. There are no conditions or criteria set in a scope relationship to
govern how a query is formed, it specifies only if a dimension can be queried with a specified
fact. The absence of a scope relationship results in an error at runtime.

If you set the scope relationship for the measure dimension, the same settings apply to all
measures in the measure dimension. If data is reported at a different level for the measures in
the measure dimension, you can set scope on a measure. You can specify the lowest level that
the data can be reported on.

When you create a measure dimension, Framework Manager creates a scope relationship
between the measure dimension and each existing regular dimension. Framework Manager
looks for a join path between the measure dimension and the regular dimensions, starting with
the lowest level of detail. If there are many join paths available, the scope relationship that
Framework Manager createsmay not be the one that you intended. In this case, you must edit
the scope relationship.

A scope relationship is automatically generated when you drag a dimension into the dimension
map or when you move a query subject into the dimension namespace and convert it to a
regular dimension.

Note: Shortcuts to scope relationships are not supported.

Define Scope Relationships

Scope relationships exist only between measure dimensions and regular dimensions to define
the level at which the measures are available for reporting.
Steps
1. Click the Dimension Map tab.
Tip: To view scope relationships highlighted with a background color, click the show scope
button .
2. Click one or more measure dimensions.
3. Click the level of the dimension that you want to set the scope to.
Tip: If you want Framework Manager to define the scope relationship, select the measure
dimension and the regular dimension, and click the determine scope button .
4. Click the set scope button .
If you want to remove the scope, select the hierarchy or dimension and click the remove scope
button .
If you select a hierarchy, you can remove the scope from a specific hierarchy without affecting
the
scope set in other hierarchies of the dimension.
If you select the dimension, all scope from all hierarchies is removed. The scope relationship
between
the measure dimension and the regular dimension is also removed.
Create a Regular Dimension Based on Existing Objects
You can create a new regular dimension by merging existing objects. These objects can be
dimensions,
query subjects, or query items.
Steps
1. Select the objects that you want in a dimension.
2. From the Actions menu, click Merge in New Regular Dimension.
View Related Objects
Information about viewing related objects for SAP BW dimensions appears in a different topic
(p. 199).
116 Framework Manager
Chapter 4: Modeling Relational Metadata
You can explore a visual representation of the objects that are connected to the query subject or
dimension that you select in the Project Viewer. The Context Explorer shows the objects that
the selected object is connected to. You can also select a connected object and see its references.
You can hide an object in the Context Explorer. You can also change the layout, fit all objects in
the Context Explorer, zoom in and out, print, preview diagrams before printing, and change the
page setup.
You can also use the Dimension Map tab to explore dimensions.
Steps
1. Select one or more objects that you want to explore.
2. From the Tools menu, click Launch Context Explorer.
3. To see the connected objects, click one or more objects and click the appropriate button.

4. If you want to see details about an object, such as its relationships and query items, right-click
the object, click Navigate Diagram, Diagram Settings, and then select the details you want.

Test a Dimension
Testing a regular dimension returns the attributes associated with the hierarchy defined as the
default.
You can see the results that an object returns by testing it. You can test when creating an object
or later on. The objects you can test are dimensions, query subjects, query sets, hierarchies,
levels, calculations, and query items.

You can view the data that will appear in a specific report before publishing a package by
selecting and testing the objects that will appear in the report. This makes it easier to debug a
model and to verify that the model meets the reporting requirements because you do not need
to create and publish packages first.

When you test an object, Framework Manager returns sample data. Formatting is not applied to
the sample data. If you must test formatting, you must publish the package and view the objects
in the IBM Cognos 8 studios.

You may see different results depending on what you test. For example, if you use the
expression editor to test a calculation that is embedded in a query subject, Framework Manager
tests only the expression, not the item, so the aggregation setting for the query item is not
applied to the test.

Testing the entire query subject, which includes the calculation, gives a different result because
the aggregation setting is applied. For example, if the aggregation setting is summarize, you can
see a smaller number of rows in the test.

If you test a child segment of a segmented model, you may see an error if an object you are
testing refers to an object in another child segment and the referenced object is not available to
the project you are in. We recommend that you check that the parent model contains all the
objects and that this error message does not appear when you test the parent model.

Governor settings may affect the testing results. For more information, see "Set Governors" (p.
303).
You can change existing test settings to customize the results that the test shows. For example,
in addition to other settings, you can control the number of rows returned.
Steps When Creating or Modifying the Object
1. Select the object you want to test.
2. From the Actions menu, click Edit Definition, and click the Test or Query Information tab.
The Test Results box is initially empty until you run the query.
Any result sets that contain binary large objects are shown as [blob].
3. To run the query and bring back all the test results, click Test Sample.
4. If you want to add a count of the rows, click Total Rows.
5. If you want to apply the Regular Aggregate property of the query item or the Aggregate
Rules property of a semi-additive measure that is referenced in the expression, select the Auto
Sum check box.
If you clear this check box, a row is returned for each row in the result set of the query.
6. If you want to obtain more information about the query results, click the Query Information
tab.
7. Click OK.
Steps to View the Data That Will Appear in a Specific Report
1. Select the objects that will appear in the report.
2. From the Tools menu, click Test.
A message appears, telling you if the test was successful or if problems were found.
3. To view details about any problem that is found, click the Query Information tab.
If you do not see the results of the query in the test window, the data from your data source
may exceed the value of the Runtime Limits governor. The query stops at the specified limit,
but the test result window does not contain any data. Tip: Set the Runtime Limits governor to
zero.
When you test a measure dimension, the SQL uses aggregates not the measures.
Change the Test Settings
You can customize the tests by changing the test settings.
Steps
1. Select the object that you want.
2. From the Actions menu, click Edit Definition and then click the Test tab or the Query
Information tab.
3. Click Options and then click the Test Settings tab.
4. Choose the options that you want.
5. Click OK two times.
You may be interested in the following related topics:
● working with dimensions (p. 103)
● working with query subjects (p. 75)
Convert a Regular Dimension into a Query Subject
You can convert a regular dimension into a model query subject or a data source query subject.
You can also convert a query subject into a dimension (p. 95).
Constraint
If a dimension has multiple hierarchies, only the default hierarchy is included when you
convert the dimension to a query subject.
Steps
1. Click the regular dimension.
2. From the Actions menu, click Convert to Query Subject.

UPGRADING ISSUES IN MODEL FORM CRN TO C8

Changes to Data Types
Cognos 8 added support for new data types. This may change how data types are mapped
between Cognos and the source data on metadata import. The primary areas of change are as
follows:
• nChar
In some cases, data types that were char become nChar.
• nVarChar
In some cases, data types that were varChar become nVarChar.
• numeric
In some cases, data types that were decimal become numeric.
• timestampTZ
In some cases, data types that were varChar become timestampTZ.
• IntervalTZ
In some cases, data types that were varChar become IntervalTZ.
Mapping of these data types varies by data source vendor and can be confirmed from the data
type support section of the Cognos support Web site (http://support.cognos.com).
The Allow enhanced model portability at runtime governor is selected upon initial upgrade.
This governor prevents rigid enforcement of data types so that the Cognos 8 model can function
as a ReportNet 1.x model until you update the data types in the metadata.

It is not possible to automatically determine the new data type based on the existing data types
saved in the model. For this reason, use the Verify Model, Verify Selected Objects, or Update
Object commands to update the mapping of the data types.

Dimensions and Determinants

In ReportNet 1.x, dimension information combined the concept of uniqueness with the concept
of dimensional hierarchies. In Cognos 8, the concept of dimension information is divided to
provide control over uniqueness and granularity. This control is required for relationally-based
query subjects and to more explicitly address dimensional concepts of hierarchies and levels for
dimensional objects, even on relational sources.

When reviewing dimension information, you must understand how the dimension information
is applied to the query subject and how the query subject will be used in the Cognos 8 model.
The metadata previously specified by dimension information is implicitly preserved in the
model and continues to exist for query subjects until those query subjects are repaired. You
cannot change this dimension information. You can upgrade the dimension information to
regular dimensions or determinants. Until you upgrade the query subject, Cognos 8 query
generation uses the dimension information previously specified in ReportNet 1.x.

The Allow dynamic generation of dimension information governor is selected upon initial
upgrade. This governor ensures consistent behavior with ReportNet 1.x by deriving a form of
dimension information from the relationships, key information, and index information in the
data source.
Checking and Repairing the Model
After automatically updating the metadata, Framework Manager prompts you to check the
model. We highly recommend that you complete this step before making any changes to the
model.
Understanding Warnings
The following warnings commonly appear when you check a ReportNet 1.x model:
• Needs reevaluation
This message is most likely related to data type changes.
The majority of items with this warning can be selected for repair. The repair option steps you
through your options for evaluating and upgrading specific elements of metadata.
Tip: You can also evaluate a query subject by using the Evaluate Object command from the
Tools menu.
• Join expression conflicts with the determinant information defined in the query subject
Sometimes the index and key information specified for a query subject implies a level of
granularity that does not match the relationships specified on a query subject. For more
information, see "Defining Dimensions and Determinants" (p. 16).
• None of the query items in this level have a role Caption specified
When defining levels, you must ensure that a business key and caption roles are specified.
These roles are relevant for member functions in the report authoring tools and to assist in the
member-oriented tree in Analysis Studio.
• One or more determinants that describe the keys and attributes of the query subject should be
Specified When importing from a relational data source, determinants are specified for any
indexes and keys that exist in the data source. It is possible that no determinants exist on a
query subject upgraded from ReportNet 1.x, especially for model query subjects. We
recommend that you use determinants to explicitly specify the granularity of the data in the
query subject and the functional dependencies between query items. However, it is not
mandatory to specify determinants for query subjects representing a single level or fact data.
Determinants are required only if the item is a BLOB data type.
Selecting and Repairing Objects
You can select all items with check boxes and repair them. The repair process first evaluates all
selected items. This evaluation automatically resolves issues around new data types and
prompts you to deal with dimension information in the model. We recommend that you
upgrade most query subjects that used dimension information in ReportNet 1.x to dimensions.
Converting Query Subjects to Dimensions
You can convert a query subject to a dimension by using the dimension information in the
query subject. You can also convert a dimension to a query subject with determinants at any
time after completing the upgrade.sional objects, even on relational sources.
Dimension information is mapped to regular dimensions as follows.
For example, the Product query subject in ReportNet 1.x has the following dimension
information.

When you convert this query subject to a regular dimension, the dimension information is used
to create these hierarchies and levels in Cognos 8.
Things to Review
After conversion, you must review the following:
• Unique Level
A unique level indicates that the keys of the levels above are not necessary to identify the
members in this level.
• memberCaption role
To leverage member functions and enable dragging and dropping levels in the report
authoring tools, you must assign a memberCaption to each level in a dimension. Because this
role does not exist in ReportNet 1.x, it is mapped where possible. If there are no attributes for
the level, the absence of a caption is highlighted when you check the model.
• Attributes
In general, all other attributes should be included in the dimension and associated to the
correct level. By default, they are included with no role. You have the option to create custom
roles or assign attributes to existing roles.
• Multiple Hierarchies
Only the first hierarchy from a ReportNet 1.x query subject is upgraded to a dimension. You
must re-create all other hierarchies.
For example, after upgrading the Product query subject to a regular dimension, you can further
refine it. In this example, Product name is now defined as the memberCaption role.
Converting Dimension Information to Determinants
When maintaining models that do not fully conform to ReportNet 1.x recommendations, you
may need to preserve query subjects. Dimension information is then mapped to determinants as
follows.

For example, the Product query subject with dimension information looks like this in ReportNet
1.x.
When you convert it to a query subject with determinants, it looks like this.

Things to Review
After conversion, you must review the following:
• Uniquely Identified
The Uniquely Identified check box indicates that a determinant uniquely identifies a row in
the data set.
• Group By
The Group By check box implies a mandatory grouping will be done on any query using this
determinant or any item determined by it. This helps to resolve double-counting in the case of
dimensions being joined on different keys at different levels of granularity. If attribute items
are determined by a determinant that has the Group By check box selected, the Minimum
aggregate function is applied to them in the query.
• Multiple Hierarchies
Determinants do not explicitly support the concept of hierarchies and provide no mechanism
to represent multiple hierarchies. If two hierarchies existed on a query subject in ReportNet
1.x, only the first hierarchy is upgraded to a determinant. You must create a second query
subject and manually specify the determinants for the other hierarchy.
For example, after upgrading the Product query subject to use determinants, you can further
refine it. In this example, Product key is now the unique identifier, and Product line code and
Product type code are used to group query items.

Synchronization
Macro in database selection
Stored Procedure in Report

Context filters are different from other filters. When you filter data, members that do not
meet the filter criteria are removed from the report. A context filter does not remove
members from a report. Instead, their values are filtered or and you see blank cells.

You can also use context filters as prompts when the report is run .

When creating context filters,

 use only members from hierarchies that are not already projected on an edge of the
crosstab

 use only one member per hierarchy

Design and Active Lanaguage:
Find from Project MenuLangugaes
Design:Default Langugae,it shows in the language that model was created originally.
It cannot be changed.We can have only one default Language.
Active:In which language the currently opened model should be shown.We can more than
one.Example:IF you change the Lanaguage as Active,all the objects will be converted to
Active Language.

Multilingual Project and Reports

For relational data sources, you can support multiple languages by using one or more of the
following:
 Language-specific database tables
The data source should contain the same tables for each supported language. For
example, if the Product table supports English, French, and German, the data source
has tables named Product_en, Product_fr, and Product_de.
 Language-specific columns
A database table should contain the same columns for each supported language. For
example, if the Product table supports English, French, and German, the table has
columns for ProductName_en, ProductName_fr, and ProductName_de.
 Language-specific rows
A database table should contain an additional column to identify the language of each
row of data, such as a column named LANG.
You can model multilingual data that is stored in multiple tables, columns, or rows for each
supported language. You can use macros with parameter maps and session parameters to
create dimensions or query subjects that retrieve data in the preferred language of the
person viewing the report
Example - Create a Multilingual Project for Relational Metadata
 Translate the metadata.

 Use macros to create a multilingual project.

Cognos 8 License Series 7 User Class Cognos 8 Namespace Studio Access Characteristics
Role
BI Administrator Root User Class Directory Administrator All Studios, All Includes Framework Manager
capabilities and OLAP builder
BI Professional Report Authors Class, Authors, Metrics Authors, All Studios
Metrics Author, Event Event Author
Author
Professional Author Report Authors Class Authors Portal, Query,
Report
Business Manager Metrics Author Metrics Authors Portal, Metrics
Business Author Query User Class Query Users Portal, Query
Business Analyst Analysis User Analysis Users Portal, Analysis
BI Consumer Consumer Users Consumers,read and Portal No Metrics Watch List.
execute Event Newsitems OK.
Metrics Package Content
BI Recipient Recipient Users Read,deny write, execute Portal No Metric Watch List
and set policy for public No Event Newsitems
folders for Recipient Users Metrics Package Content
 View pre-run reports

Predefined Roles

Datalevel Security:
Method 1:
Parameter Maps and Session parameter maps using Macro syntax on Fact Table itself

Method 2:
Paramter Maps with CSVIdentityName on Fact Table itself as a filter

Method 3:
Paramter Maps with CSVIdentityNameList on Fact Table itself as a filter
Use CSVIdentityNameList to define the securities at report level directly if you do not
have the

Method 4:
Use security wizard to assign the Groups and Roles to the already exist filters.

Method 5:
Assume that you have 2 groups, out of that you have the list of accounts related to one
account, don’t have the account list for second group. In this case, define second group
as default group in Parameter Maps window. (All the accounts which are not falling
under Group 1 go to group 2)
Then use Default name(defined above) in filter condition.