May 09, 2015 TRUONG PHAN NGUYEN MINH

Senior software Engineer

COGNOS FRAMEWORK VERVIEW

An introduction about Modeling Metadata
Course Agenda

 IBM Cognos Framework Manager overview

 Build a model with IBM Cognos Framework Manager
 Add business logic to the model
 Create dimensional objects for OLAP-style reporting
 Create and configure a package
Course Objective

 Modelmetadata so that end users can easily and

accurately author reports and analyze data.
 Manage projects and package.
 Createanalysis objects by providing dimensional
information in model.
IBM Cognos Framework
Manager overview
What is Framework Manager?

 Providesthe metadata model development environment

for IBM Cognos
 Used
to create simplified business presentations of
Metadata derived from one or more data sources

Complex Data Source Simple Business Presentation

 What is Framework Manager? (cont'd)

 Can create two model types:

 relational for reporting

 dimensionally modeled relational (DMR) for OLAP-style analysis and reporting

Relational Dimensional
Model Model
Define a Framework Manager Project

 Atthe highest level, objects

in a project include:
 a model organized
into namespaces
and folders

 data sources

 parameter maps

 packages
Define Framework Manager Metadata Elements

 Metadata is defined and organized by the following elements:

Model Measure
Query Subject Dimension

Data Source
Query Subject
Regular
Dimension

Query Item

Relationship
(scope Shortcut
relationship
for dimensional
objects)
Examine the Model from the Author's Point of View
Framework Manager Workflow

Framework Manager

Create Model
Import Prepare
Project Metadata for
Metadata Metadata
Reporting

Set Create and

Publish Manage
Security Packages

Report Studio
Query Studio
Data Content
Analysis Studio
Sources Store
….
Import Required Metadata Recommendation #2

Select Object
for Import

Select Select Select Criteria

Select Data Objects to to Generate
Import Source Import Relationships
Source

Import
Create Data
Source
Connection
Generate Relationship Criteria
Examine the Role of an IBM Cognos
Metadata Model

 An IBM Cognos metadata model provides a business

presentation view of an organization’s data sources.
 BIusers use the model to analyze and report on their data
sources.
Reporting Layer

IBM Cognos Metadata Model

Relational Files Other

Cubes
Distinguish Between Operational and
Reporting Databases

 Relational databases are typically either:

Operational Reporting
Customer Sales Product
Type Area Line Sales
1..1 1..1 1..1 Rep
1..n 1..n 1..1
1..n
0..n

Customer Sales Product 1..1 Order 1..1

Rep Type Customer 0..n Fact 0..n Product
1..1 1..1 1..1
0..n
1..n 1..n 1..1

Order Product
1..n Header Date
1..1 1..1
1..n

Order
Detail 1..n
Identify Features of an Operational Database

 Operational databases:
 are designed to maximize accuracy and minimize redundancy

 are optimized for writing and updating data rather than reading data

 often result in monolithic designs with multiple joins

 Large queries can perform slowly.

Identify Issues with Operational Databases

 "Showall customer types that bought Customer Sales Product

Type Area Line
from a product line." 1..1 1..1 1..1
1..n 1..n 1..n

 Thequery must check data in seven Customer Sales

Rep
Product
Type
tables before returning a result set. 1..1
0..n
1..1
1..n
1..1

0..n
Order Product
Header
1..1 1..1
1..n

Order
Detail 0..n

Query requires 7 tables

Examine Reporting Databases
(Star Schema Design)

 Transactional data is stored in a fact table

 Reference data is stored in separate dimension tables

Sales
Rep
1..1
0..n

Customer 1..1 Order 1..1

0..n Fact 0..n Product
0..n
1..1

Date

Query only requires 3 tables

Create a Star Schema

 Collapsethe relationships to form dimensions

(perspectives).
Customer Sales Product
Type Area Line
1..1 1..1 1..1
1..n 1..n 1..n
Sales Product
Customer Rep Type
1..1 1..1 1..1
Sales
Rep 0..n 1..n

0..n
1..1 0..n Order Product
Header
Customer
1..1 Order 1..1 1..1 1..1
0..n Fact 0..n Product 1..n
0..n Order
1..1 0..n
Detail
Date
Examine Operational Data

 Data is normalized

Product Line Table Product Type Table Product Table

PL# PL_Desc PL# PT# PT_Desc PT# Prod# Prod_Desc
a Classic Tents a 1 Pup Tents 1 101 1 Sleeper
b Moose Boots a 2 Family Tents 1 102 2 Sleeper

2 rows b 11 Child Boots 2 201 4 Sleeper

b 12 Adult Boots 2 203 6 Sleeper
11 1101 Wet Proof
4 rows
12 1102 Hikers+

6 rows
Before collapsing into a star schema dimension
Examine Reporting Data

 Data is de-normalized

Product Dimension Table

PL# PL_Desc PT# PT_Desc Prod# Prod_Desc
A Classic Tents 1 Pup Tents 101 1 Sleeper
A Classic Tents 1 Pup Tents 102 2 Sleeper
A Classic Tents 2 Family Tents 201 4 Sleeper
A Classic Tents 2 Family Tents 203 6 Sleeper
B Moose Boots 11 Child Boots 1101 Wet Proof
B Moose Boots 12 Adult Boots 1102 Hikers

6 rows
After collapsing into a star schema dimension
Examine Fact Tables

 Fact
tables contain the (usually additive) values by which
a company measures itself:
Standard Selling Price - not additive
Sale Amount - additive

Dimension Tables
Fact Table Product

Sales Revenue
Measures Quantity
………………………. Customer
Product Key
Foreign Keys Customer Key
Time Key Time
Examine Dimension Tables

 Dimension tables provide descriptive information.

 Dimensiontables may be "conformed" so that they are
applicable to multiple fact tables across the business.

Dimension Dimension
Product Warehouse
Fact Fact
Sales Inventory

Dimension Dimension
Customer Time

Conformed Dimensions
Identify Issues with a Star Schema

 Data is only as current as the last data load.

 Structural issues:
 the distinct count problem
 very large dimension tables
 snowflakes

 Fact issues:
 different levels of granularity (detail) in fact tables
Define Relationships

 Specify how data in one table is linked to data in another

table.
 Relationships are implied in the physical data (modeler
explicitly declares these relationships)
 Modeler formulates the reality of the business by
configuring the relationships
Examine Relationships: Cardinality

Employe 1..1 Security  One-to-One: One employee holds

e 1..1 Number exactly one security number.

 One-to-Many: Each order header

must have one or more order
Order 1..1 Order
details.
Header 1..n Details

 Many-to-Many: Each part may be

provided by many suppliers, and
1..n each supplier may provide many
Part Supplier
1..n parts.
Examine Relationships:
Optional vs. Mandatory

 Relationships may be mandatory or optional.

 For example, a product may exist even if it has not been ordered,
but an order must refer to at least one existing product.

 It
is important to determine if certain relationships are
optional.
 For example, is there a reporting requirement to list sales
representatives who have sold nothing?
Examine Relationships: Data Traps

 There are four basic data traps:

 chasm trap (many-to-many relationship)

 transitive relationship trap (more than one path between two

tables)

 connection trap (an optional path through different entities)

 fan trap (multiple one-to-many relationships that fan out from a

single table)
Examine Chasm Traps

 Many-to-many relationship
 Structure
cannot record and maintain data (it lets the
information fall into a chasm)
 Notincorrect when designing at a high level (it just does
not show all the necessary details)

Which
suppliers
1..n provide
Supplier 1..n Part
which
specific
parts?
Examine Transitive Relationships

 Exists if there is more than one path between two tables

Customer 1..1 Order

0..n

1..1 1..1
Can an order exist
Can a customer without an order
1..n
exist without an detail?
order detail? 0..n Order
Detail

Which relationship is redundant: the one

between Customer and Order Detail, or the
one between Order and Order Detail?
Examine Fan Traps

 Identified
by multiple one-to-many relationships that fan
out from a single table
 Exists if there is more than one path between
two tables

1..1
Customer 0..n Order

1..1 1..1 Can an order exist

Can a customer 1..n
without an order
exist without an detail?
order detail? 0..n Order
Detail

Which relationship is redundant: the one

between Customer and Order Detail, or the
one between Order and Order Detail?
Examine Connection Traps

 Is there an optional path through different entities?

 There must be a reliable path through all truly related
entities

What is the relationship between Branch and Employee?

If an employee does not work for a branch, do they work for a

division?

1..1 1..1
Division 1..n Branch 1..n Employee
1..1 1..n
Examine OLAP Data Structures

Products
Order Camping Equipment

Methods Golf Equipment

Fax Cell
Dimension
Outdoor Protection
Telephone
Mountaineering
Members Mail Equipment

E-Mail Personal Accessories

Jan Feb ... Web

Q1 Q2 ...
2005 2006 ... Start End
April 1 June 30
Time Attributes
Hierarchy/Levels 2005
Q1 Q2 Q3 Q4
Identify Data Access Strategies

 Consider using a cube to analyze data sets that are not

prohibitively large.
 Consider creating a star schema to improve performance
over an operational system.
 If
you need to access live data, you may have no choice
but to go with an operational system.
Questions & Discussion