An Introduction to Cognos BI’s Framework Manager … Introduction to Cognos BI’s Framework...

Post on 31-Mar-2018

222 views 2 download

transcript

An Introduction to Cognos BI’s Framework Manager

Rocket City Cognos Users’ Group

March 14, 2013

Who am I? Application Analyst at Dynetics, Inc. since 2007

Over ten years of experience with Cognos Business Intelligence products

Cognos BI System Administrator

Author advanced reports

Maintain system security

Manage development and production environments

Jonathan.mcknight@dynetics.com

What is Framework Manager? “IBM® Cognos® Framework Manager is a metadata

modeling tool that drives query generation for IBM Cognos software. A model is a collection of metadata that includes physical information and business information for one or more data sources.” –from the FM User guide

Used to create packages which are used in report authoring Connects to numerous kinds of data sources

Relational data (SQL, Excel sheets, csv files, etc.) OLAP data sources (multidimensional data)

Organizes data into grouped, understandable areas for reporting

32-bit application

Framework Manager Terminology A project contains a model, namespaces, packages, data sources, and

related information for maintaining and sharing model information. A single project can span many data sources or tables.

A model is the set of related dimensions, query subjects, and other objects required for one or more related reporting applications.

A namespace uniquely identifies query items, dimensions, query subjects, and other objects. You import different databases into separate namespaces to avoid duplicate names.

A package is a subset of the dimensions, query subjects, and other objects defined in the project. A package is what is actually published to the IBM Cognos BI server, and it is used to create reports, analyses, and ad hoc queries.

A dimension is a broad grouping of data about a major aspect of a business, such as products, dates, or markets.

More Terminology A query subject is a set of query items that have an inherent

relationship. They typically behave like tables. Data source query subjects directly reference data in a single data

source. Model query subjects are not generated directly from a data source

but are based on query items in other query subjects or dimensions, including other model query subjects. By using model query subjects, you can create a more abstract, business-oriented view of a data source.

Stored procedure query subjects are generated when you import a procedure from a relational data source.

A query item is the smallest piece of the model that can be placed in a report. It represents a single characteristic of something, such as the date that a product was introduced. Query items are contained in query subjects or dimensions, and they are used to create reports.

What does all this mean? For metadata modelers (administrators), Framework

Manager is a powerful tool that allows you to build packages for report authors to use.

You can combine data from different data sources

You can use it to secure packages, tables, and even individual fields

You can add calculated fields

For authors, it means you shouldn’t have to worry about joining tables and making sure data comes into the report correctly. It simplifies your work!

Three best practices

Follow the 3 (or 4) layer model design approach

Think carefully about any security you assign

Document your model

The 3 Layer Model Design Database Layer

Contains the query subjects brought in from your data source(s)

Use the Run Metadata Wizard to simply the process

Do not place joins at this layer

The 3 Layer Model Design Logical (Transformation) Layer

Query subjects should reference back to the database layer

Create joins

Always try to create joins in a star schema

Examples of a star schema

The 3 Layer Model Design Logical (Transformation) Layer

Query subjects should reference back to the database layer

Create joins

Always try to create joins in a star schema

Apply model filters

Merge query subjects

Translate query subjects and items to business names

FY_CD becomes Fiscal Year

PD_NO become Period

The 3 Layer Model Design Presentation Layer

Contains shortcuts to the Logical (Transformation) layer

Organizes data into groupings for creating packages

Use namespaces to create your groupings

Only one shortcut is allowed per namespace

Dimensional Layer

Required only for models with dimensionally modeled data (data cubes)

Also built on the Logical (Transformation) Layer

The 3 Layer Model Design Database Layer

Query subjects based off of the data source

Logical (Transformation) Layer

Query subjects created from the Database Layer

Presentation Layer

Shortcuts from the Logical Layer

Consider Security Carefully Security can be added to almost any element in FM.

Security can be controlled through Active Directory.

If a person tries to run a report and the framework security will not allow a person to view one or more elements in the report, the user gets an unfriendly message.

Add security at the highest level first, then work down to lower levels.

Model, Packages, Namespace, Query Subject, Query Item

Document Your Model! Documentation is the key to understanding your

model.

It is also vital if you ever hand off responsibilities of Framework Manager to someone else.

It makes tracking down issues with your model much easier and faster.

It does take more time up front, but it will save you time in the long run.

It makes the 3 layer model design approach easier to understand.

Document Your Model! It is a good idea to use some kind of version control

system to keep a history of old models

If you add to a model you did not create (such as Deltek’s model), you will probably need to recreate those changes if you upgrade the third-party model. Documentation is invaluable in these situations.

Document additions to the model, joins, calculations, and especially security.

Lessons Learned the Hard Way Always run Framework Manager as administrator!

Bad joins = bad queries = bad reports

Document your changes, especially your security!

As a framework administrator, you should strive to make things as easy as possible for your report authors.

Reference Material IBM: Framework Manager User Guide 10.1.0

http://pic.dhe.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_fm.10.1.0.doc/ug_fm.html

Ben Harden: Blogging about Business Intelligence http://www.thehardens.net/2011/07/cognos-framework-manager-best-

practices.html

Ironside Group http://www.ironsidegroup.com/2010/07/08/best-practices-in-cognos-8-

framework-manager-model-design/ http://www.ironsidegroup.com/2010/08/01/best-practices-in-cognos-8-

framework-manager-model-design-part-2-%E2%80%93-advanced-modeling-issues/

http://www.ironsidegroup.com/2011/02/17/what%E2%80%99s-new-in-ibm-cognos-10-framework-manager/

CognosPractice.com http://www.cognospractice.com/Documents/Framework%20Modeling%20Gui

delines.pdf