Framework Manager

Cognos 8 BI
Objectives

 In this module we will examine:

 Basic Data Model Issues
 Modeling Enhancements
 Determinants

 Dimensional Modeling enhancements

 New General Features

 OLAP Data Stores
 Update to Best Practices
New Features in Framework Manager
 Query Subject Enhancements
 Determinants
 Query Sets
 Tab Style Dialogs
 Dimensional modeling
enhancements
 Regular Dimensions
 Measure dimensions (facts)
 Scope relationships
 Dimension Map
 Metadata Import
 System Tables option
 Performance
 Quality of Service
 Navigation and maintenance
 Model Reporting
 Property Based Search
 Search object references
 UI Changes
 Menu reorganization
 In Context right click
Framework Manager – Publish Run time model
for end user consumption via the studios

Cognos Query Analysis Report Event Metric

Viewer Studio Studio Studio Studio Studio

Data Access

SQL XML MDX ODBC

Composite Metric
Files Database
Relational Cubes

More
Metadata for Business Intelligence

 The main goals of modeling in Framework Manager are:

 An intuitive end user experience
 Leverage existing metadata and add value
 Predictable queries and results
 To fully leverage advanced features you should model your
business view dimensionally.
 It is not required that you model dimensionally but it is important
to understand how your model impacts the predictability of your
queries and results.
Do you know the answers to these questions?

 What is the difference between dimensional and normalized models?

 What is the impact of reporting of each modeling method?
 What is a conformed dimension?
Review of Normalized vs. Dimensional

 Remember, operational and reporting databases have different goals

and different viewpoints
 Operational databases (typically normalized)
 Fast updates (writes)
 Reporting can be slow

 Reporting data structures (typically dimensional)

 Fast reporting (reads)
 Reporting is the goal

 Understand what issues you can and can’t address in FM

Basic Rules with Normalized Design

 Design technique to minimize redundancy

 Focus on writes/updates rather than reads
 The needed data may be in separate databases, which cannot be
joined
 Operational structures may be too complex for general reporting
(especially in ERP systems)
 Often result in monolithic designs with multiple joins
 A single table can have multiple cardinality relationships
 One to many
 Many to many
 Many to one
 Opens the door to ‘blind spots’ in join paths
 Double counting can easily take place
 There may be no long-term view of the data
 Reports can often take too long to run
Framework Manager Over Normalized Design

 Where Framework Manager can help:

 It can hide the complexity of the underlying design
 It can make some very complex reports simple (multi-grained,
multi-fact queries)
 How it typically WON’T help
 Performance hit on the Operational Application may still be great
 Query cost is unchanged (i.e. more joins = longer running time)
 If historical data is not captured in the operational application, it
still won’t be available for reporting
 If you want to address these issues, you should start thinking
about data warehousing
Basic Rules of Dimensional Design

 Dimension tables should relate to Fact tables

 Dimensions should not directly relate to other dimensions
 Facts should not directly relate to other facts
 Fact attributes should only hold one type of fact
 Don’t have a single Amount column that holds both Sales and
Budget figures
 Don’t mix different grains of fact in a single fact table
 Don’t hold monthly sales budgets in the same table with daily
sales
 You could hold monthly sales budgets with the aggregated sales
for the month (both facts are at the month grain)
 There are occasionally good reasons for breaking these rules but they
are rare.
Advantages of Dimensional Modeling

 Subject Area Marts (Star Schema Groupings)

 Data for a specific area of the business
 Simpler for the end-user to understand – fewer tables
 Collection of like fact tables connected to common dimensions
 Conformed dimensions prevent ‘Islands of Information’
 Adaptable and extensible
Examine Conformed Dimensions

 A conformed dimension has relationships to more than one

fact table.

Product
Dimension
1..1 1..1
1..n 1..n

Sales Inventory
Fact Levels Fact
1..n 1..n
1..1 1..1

Time
Dimension
Manage Star Schemas in Framework Manager

Sales Fact Namespace Inventory Levels Fact Namespace

Product Product
Dimension Dimension
1..1 1..1

Sales 1..n 1..n

Inventory
Fact 1..n
1..n Levels Fact
1..1
1..1

Time Time
Dimension Dimension
Examine Multi-Fact Queries

Product
Dimension
1..1 1..1
1..n 1..n

Sales Inventory
Fact Levels Fact
1..n 1..n
1..1 1..1

Time
Dimension
Examine Stitch Queries

 Stitch queries send two separate queries to the data source and then
merge them locally.
 The SQL generated contains syntax such as:
 coalesce
 full outer join

Report Output
Database Cognos 8
D1 D2 F1 F2

Query 1 A Y1 300 $18

Stitch Queries
Together B Y2 $22
Query 2
C Y3 456 $45
Degenerate Dimension

 Kimball:
 A degenerate dimension (DD) acts as a dimension key in the fact table,
however does not join to a corresponding dimension table because all its
interesting attributes have already been placed in other analytic dimensions

Facts

Degenerate Dimension

 Dimension key that has no attributes

 In the warehouse having it’s own table
would mean having as many rows as
the fact
Create a Dimension Between Two Joined Facts

 Implement a degenerate dimension solution.

Facts
Joins

 Inner Join (also known as equi-

join)
Consider a business that employs both
managers and engineers - and some employees
that are both. An inner join is like a union of this
set; it selects the set of people that are both
managers and engineers and provides
information about them in both roles.

 Left Outer Join

Consider again the business that employs both
managers and engineers. A left outer join
selects all of the managers, providing the
information about them, but in the case of
managers who are also engineers, it provides
additional information about them.
Joins

 Right Outer Join

Consider again the business that employs
both managers and engineers. A right outer
join selects the set of all engineers,
providing information about them, but in the
case of engineers and also managers, it
provides additional information about them.

Non-matching Non-matching
records records

 Full Outer Join

Set 2 Set 3 A FULL OUTER join would return a record set that
Set 1 contains all the records from these three different
sets 1, 2 and 3.
Customers Orders
For each record returned that does not have
matching records in the corresponding table, a
NULL value will be returned for each column
Records with matching values selected from the corresponding table.
Modeling Enhancements in C8

 Determinants
 Dimensional Modeling enhancements
 Regular Dimensions
 Measure dimensions (facts)
 Scope relationships
What is a determinant?

 A determinant can define either:

 the set of database columns (query items) that uniquely identify
a set of data
 a set of columns that identify a non-unique set within the data
 Dimension Information in CRN 1.x was a means of controlling
granularity but wasn’t completely part of the OLAP world
 In Cognos 8, determinants are most closely related to the concept
of keys and indexes in the database
 There is no concept of hierarchy in determinants, although the
order in which they are specified does govern the order in which
they are evaluated
What is a determinant? Example 1

Example 1 – Database columns that uniquely identify a set of data:

Year Key Month Key Month Name Day Key Day Name
2005 200501 Jan 05 20050101 Sunday, Jan 1, 2005
2005 200502 Jan 05 20050102 Monday, Jan 2, 2005

Non-Unique Determinants Unique Determinant

Month Key is all that is required to identify month Day Key is the unique key of the table and can be
but to query with month needs a select distinct associated to all columns in the table
and Month Key in the Group By

Determinants
Name Key Attributes Uniquely Identified Group By
Year Year Key None No Yes
Month Month Key Month Name No Yes
Day Day Key Day Name Yes No
Month Key
Month Name
Year Key
What is a determinant? Example 2

Example 2 – Identifies a set of columns that identify a non-unique set within the data:

Year Key Month Key Month Name Day Key Day Name
2005 01 January 20050101 Sunday, Jan 1, 2005
2005 02 January 20050102 Monday, Jan 2, 2005

Non-Unique Determinants Unique Determinant

Month Key is not enough to identify month. Day Key is the unique key of the table and can be
Resulting query needs a select distinct and the associated to all columns in the table
Group By containing Year Key and Month Key

Determinants
Name Key Attributes Uniquely Identified Group By
Year Year Key None No Yes

Month Year Key, Month Key Month Name No Yes

Day Day Key Day Name Yes No

Month Key
Month Name
Year Key
When are determinants required?

 Determinants are absolutely required within your model when

you are:
 Using model query subjects where there are joins at
multiple levels of granularity (like time), especially facts at
multiple levels
 Eliminates double-counting / double-summing of data

 Using blobs in your data

 The application of determinants is similar the application of
Dimension Information (hierarchies) in CRN 1.x with a few
changes
Demo 1

 Refine Determinants for Query Subject

Determinant Concepts

 You help CRN by providing extra information in FM that tells what

columns (attributes) are associated with what level of detail
(granularity).
There is no hierarchy but
determinants are evaluated
in order of highest to lowest
until it finds the first level the
attribute exists at
Group By – Includes a select
distinct in the query and the
group by will contain the key
for this determinant

Uniquely Identified – The

unique key of the table. All
the columns in the table are
associated to this key.
Determinants with Multi-Grain Queries

 Usage: Determinants allow us

to specify the correct level of
rollup on a query subject
when reporting with facts
stored at different grains

Example:
 Quantity fact = reported (and joined) at the day level
 Expected Volume fact = reported (and joined) at the month level
(month is repeated so you would see a select distinct in the query
and month key in the group by)
 Determinants on the Time Dimension allow data reported from both
facts to be rolled up to their correct levels
Determinants Additional Information

 On Import, FM looks for Primary Keys and Indexes

 CRN 1.1 – keys and indexes only accessible in the model.xml file
 Cognos 8 – keys and indexes manageable via determinants tab

 On import, Primary
Key and Unique Index
are flagged as
“Uniquely Identified”
 Multi-part keys are
recognized and
treated as such on
import
Workshop 1

 Working with Determinants

Dimensional vs. Relational Modeling

 When to dimensionally model a relational source

 To enable relational reporting within analysis studio
 To enable drill up/down functionality in reports and ad hoc
queries
 To access member functions in the report authoring tools
Refer to Modeling recommendations in the Framework Manager User Guide

 When to use only relational modeling on a relational source:

 To enable basic ad hoc querying and relational reporting
 A purely relational model built using the best practices from CRN
1.1 will be suitable to extend using dimensional features, this can
be done at any time.
Refer to Modeling Best Practices from CRN 1.1
Introducing Regular Dimension Objects

 Regular dimension object:

 Contains one or more hierarchies each with
several levels
 Additional attributes can be specified at the
appropriate levels
 Rolls up the data between the levels
 Allows drill up / down functionality in the
studios
 No ambiguity with multiple hierarchies
however there is a restriction of using
items from both hierarchies within the
same query
 Requirements:
 Each level must contain a caption and a key
 Captions must be a character field
 Key is the query item that uniquely
identifies the members in that level
Demo 2

 Create a Regular Dimension

Introducing Measure Dimension Objects

 A measure dimension is a logical collection of facts

 Can be created from:
 A single table in the database
 Multiple db queries combined in a model query subject
 Measure dimensions link relevant regular dimensions and are
required to:
 Enable OLAP style analytical
querying of Relational Data
Sources
 Enable drill up/down functionality
in reports
 Access to member functions in the
studios
Cognos 8 Facts
 Query Subject
 A query subject can be a
dimension or a fact
depending on its cardinality
relative to other query
subjects involved in the
query.
 There is no way for an end
user to distinguish between
a fact and a dimension.
 Best Practice recommends
hiding the foreign keys from
users
 Measure Dimension
 Measure Dimensions are
always treated as Facts
 Only measures are visible
 Measure Dimensions are
joined to Regular
Dimensions through scope
relationships
 Both Measure and Regular
Dimensions have very clear
roles in the model. Less
chance for confusion
 Allows for OLAP style
querying
Demo 3

 Create a Measure Dimension

Cognos 8 Relationships
 Query Subject Relationships
 Defines the physical relationship
or how the underlying data is
related. A relationship is a SQL
concept that defines the physical
JOIN between query subjects.
Equivalent to the WHERE clause
generated when multiple query
subjects are combined in a
report.
 Physical relationship between
query subject will always be
required
 Cardinality is still used to
determine if a query subject is a
fact or a dimension in context to
the query
 Cognos 8 Scope Relationships
 Defines the reporting relationship
between regular and measure
dimensions
 Scope relationships exist ONLY
between regular and measure
dimensions.
 Governs the reporting granularity
of the regular dimension for a
particular measure (each
measure in a dimension can
have different scope assigned)
 does not impact the WHERE
clause.
 Similar to setting scope in
Transformer
Scope Relationships

 A scope relationship defines:

 Defines the reporting relationship between regular and measure
dimensions
 The inclusion/exclusion of a dimension in a star schema
 A scope relationship will be automatically created between a
dimension and a measure dimension whose underlying query
subjects have a valid JOIN relationship defined
 Scope can be modified or deleted and is similar to setting scope in
Transformer
Dimension Map View

 View, create, or modify hierarchies or levels;

 View, create or modify regular or measure dimensions;
 View, create or modify scope relationships for measure dimensions
or individual measures
Demo 4

 Dimension Map UI
Merging or Converting into Dimensions

 Merge Query Subject with Determinants results in:

 Original Query Subject is maintained
 New Regular Dimension is created using the levels
 Convert Query Subjects into a Regular Dimension results in:
 Only a Regular Dimension Object
Demo 5

 Merging and Converting

Workshop 2

 Dimensional Modeling
Why Both Determinants and Regular
Dimensions?

 Determinants  Regular Dimensions

 For traditional query subjects  Allows you to perform OLAP
analysis against Relational data
 Required to manage granularity for
(dimensionally modeled relational)
multi-fact/multi-grain reporting
 Provides OLAP functionality such
 Required for blobs
as drill up / down
 Represents levels of grouping data
 Is required for Analysis Studio
 Does not provide OLAP
functionality
 Cannot be used in Analysis Studio
Dimensional Modeling Considerations

 To better understand the impact of dimensional modeling we recommend you

consider the following:
 Relational query generation continues to be defined by query subjects and
joins as it was in CRN 1.1
 Dimensional objects are an additional layer of metadata that enable OLAP
behaviors. There is a cost to the additional capability enabled by OLAP
behavior on a relational source
 It will most likely be necessary to employ a form of RDBMS vendor
materialization to improve performance, particularly for drill through.
 It is highly recommended that you build mandatory filters into your model to
ensure that end users do not accidentally retrieve excessively large data
sets.
 Similar rules regarding data volumes apply to a dimensionally modeled
relational source as apply to building cube. The key difference is that with
filtering strategies it is possible to perform analysis against larger volumes in
a relational source than is practical to do with most OLAP sources.
OLAP Data Store Support

 Setup OLAP data store in Framework Manager

 Setup Data source connection
 Import OLAP data store (essentially a link)
 Publish OLAP Package to Cognos Connection
 Administration in OLAP Administration Tool
 Changes to OLAP data stores are automatically consumed by
Studios
 Supported OLAP data stores
 Cognos PowerCube, Microsoft Analysis Services, Hyperion
Essbase or IBM DB2/OLAP
 SAP BW is an OLAP store
 An RDBMS is not an OLAP data store, even when dimensionally
modeled.
What about PowerPlay 7 Components?

 PowerPlay Transformer Series 7 Version 2 and higher continues to

be used as the modeling tool for PowerPlay Cubes
 OLAP data stores cannot be edited within Framework Manager
 PowerPlay Client Series 7 is used for disconnected users who
cannot access Analysis Studio
 PowerPlay Enterprise Server is not used with Cognos 8 as it is not
necessary.
 Instead of connecting to cubes through PowerPlay Enterprise
Server you now connect to cubes through FM published
packages using MDX.
PowerPlay and Cognos 8

 Transformer Series 7 Version 3, MR2 has been re-branded and will

be shipped with Cognos 8
 New Name when shipped with C8:
 Cognos 8 Business Intelligence OLAP Modeling

 PowerPlay for Windows Series 7, Version 3 has been re-branded

and will be shipped with Cognos 8
 New Name when shipped with C8:
 Cognos 8 Business Intelligence Mobile Analysis
Workshop 3

 Modeling with OLAP Data Sources

OLAP and Relational

 What you can and can’t do:

 You can combine OLAP data stores and relational data stores in
the same model and package
 You can create a report using both based on the following rules:

Joins Set Ops Master- Drill-Through

(unions, etc) Detail
OLAP to OLAP No Yes Yes Yes

OLAP to RDBMS No Yes Yes Yes

RDBMS to RDBMS Yes Yes Yes Yes

 Report bursting is limited:

 The burst report must be a grouped report and the burst is
restricted to the outer most grouping in the report.
 i.e. report grouped on Country and State but can only be burst
on Country
Workshop 4

 Modeling with OLAP and Relational

Data Sources
Changes Overview

 Performance: Quality of Service

 Query Sets
 Test Capabilities
 Model Reporting
 Diagram enhancements
 Property Based Search
 Search object references
 Query item properties
 True/False – Boolean
Navigate to Quality of Service

 Highlight a Data Source

 From the properties menu expand ‘Type’
 <Click to edit> the Function Set ID property
 In Project Function List pane, click Define Quality of Service
Performance - Quality of Service
Define Query Set

 Similar to tabular sets in CRN 1.x Report Studio

 Requires two identical query subjects
 Supports union, except, intersect
Query Set – Union, Except, and Intersect

 Union
Product 1

Product 2

 Except
Product 1

Product 2

 Intersect
Product 1

Product 2
Test – Cognos 8 update

 Enhancements allow the modeler to test query scenarios without

going to the studios.
 Batch – runs the entire query - similar to running in pdf mode
from studio. Test for performance and to ensure entire query
runs properly from FM (as opposed to running html in studio)
 Auto Sum – test the SQL and results with automatic aggregation
on determinants
 Multiple Query Subject Testing – select one for more query
subject or query items from one or more query subject and Test
is now available. Replaces the need to create model query
subjects or to go into a studio to verify SQL generation.
Demo 6

 UI Overview
Workshop - Query Sets and Test Enhancements

 Query Sets
 Import Views from go sales data warehouse
 Select the AR_AMX and AR_CEU Views to import
 Compare data columns between the imported views
 Highlight the two views
 From the Actions menu – Define Query Set
 What would have happened if we selected “Merge into a New
Query Subject” ?
 Test enhancements
 TEST: Select one or more linked Query Subjects
 TEST: Select query items from one or more query subjects
 Observe the data and the SQL
 Compare the Batch and AutoSum Check boxes results
Best Practices Review

1. Take a multiple layer approach to modeling

2. Customize Metadata at run-time
3. Setup Query Item properties for Business Intelligence use
4. Make sure all the relationships you need exist in the database
view. Ensure there are no discrepancies in cardinality between
database and modeled environment
5. Begin creating simplified, abstracted model query subjects for
your business view
6. Resolve valid multiple relationships (‘ambiguous join paths’) by
generating Role Playing Dimensions
7. Use dimension information to enable automatic aggregation
capabilities
8. Handle multiple hierarchies
9. Create a Business View with the Star Schema Grouping Wizard
10.Secure the Model for deployment
Updates to Best Practices

1. Take a multiple layer approach to modeling

2. Customize Metadata at run-time
3. Setup Query Item properties for Business Intelligence use
4. Make sure all the relationships you need exist in the database view.
Ensure that any discrepancies in cardinality or relationships between
database and modeled environment are correctly reflected by
determinants.
5. Begin creating simplified, abstracted model query subjects/dimensions
and measures for your business view
6. Resolve valid multiple relationships (‘ambiguous join paths’) by generating
creating multiple query subjects for Role Playing Dimensions.
7. Create dimensions with levels, hierarchies and keys to enable automatic
aggregation capabilities and OLAP query functionality on relational
sources. Create multiple hierarchies within the dimension if desired.
8. Create measure dimensions and adjust/set scope relationships.
9. Create a Business View with the Star Schema Grouping Wizard
10. Secure the Model for deployment
Summary

 In this module we examined:

 Basic Data Model Issues
 Modeling Enhancements
 Determinants

 Dimensional Modeling enhancements

 New General Features

 OLAP Data Stores
 Update to Best Practices