Guideline

Flexible Model Solutions

Product(s): Cognos ReportNet, Cognos 8

Area of Interest: Modeling
Flexible Model Solutions 2

Copyright
Your use of this document is subject to the Terms of Use governing the
Cognos software products and related services which you have licensed or
purchased from Cognos. The information contained in this document is
proprietary information of Cognos Incorporated and/or its licensors and is
protected under copyright and other applicable laws. You may use the
information and methodologies described in this document 'as is' or you may
modify them, however Cognos will not be responsible for any deficiencies or
errors that result from modifications which you make. Copyright 2006 (c)
Cognos Incorporated. All Rights Reserved.
You can print selected pages, a section, or the whole book. Cognos grants
you a non-exclusive, non-transferable license to use, copy, and reproduce the
copyright materials, in printed or electronic format, solely for the purpose of
providing internal training on, operating, and maintaining the Cognos
software.
This document is maintained by the Best Practices, Product and Technology
team. You can send comments, suggestions, and additions to Best Practices,
Product and Technologies.

Cognos Proprietary Information

Flexible Model Solutions 3

Contents

1. INTRODUCTION ..................................................................................................4
1.1 PURPOSE ................................................................................................................... 4
1.2 APPLICABILITY ............................................................................................................ 4
1.3 EXCLUSIONS AND EXCEPTIONS ......................................................................................... 4
2. WHAT IS A FLEXIBLE MODEL..............................................................................4
2.1 FLEXIBILITY FOR MODEL GROWTH .................................................................................... 4
2.2 FLEXIBILITY AND REPORTING .......................................................................................... 7
3. SUMMARY ...........................................................................................................9

Cognos Proprietary Information

Flexible Model Solutions 4

1. Introduction
1.1 Purpose
This document is aimed towards the Framework Manager model developer.
The purpose of this document is to outline design theory that will aid in
building maintainable models and allowing for easy extension of the model as
reporting requirements grow and mature.

1.2 Applicability
The current document applies to modeling within Cognos ReportNet and
Cognos 8 although the theory has broader scope and applicability.

1.3 Exclusions and Exceptions

The topics covered in this document are meant as general information and
recommendations rather than as hard rules for model design. Depending on
the reporting requirements, the material covered here may have more or less
bearing on the scope of any given reporting project. The information
presented here should be evaluated within the scope of the given project to
determine applicability.

2. What is a Flexible Model

Model flexibility can be defined from two different points of view. The first is
the ability of the model to expand and grow to support other reporting
applications. The second point of view is the ease of use for end users when
generating ad-hoc query requests.

2.1 Flexibility for Model Growth

Model development has many of the same challenges as any project will
have. The foremost of these is in setting the appropriate scope. With too
narrow a focus you limit user buy-in while if you choose a scope that is too
wide you may end up with a model that never transitions from development
to production.
The ideal scope for model development will exist somewhere between the
lowest level business process and the entire enterprise. Choosing this scope
will depend on many factors such as data quality, standardization, user
community, and the divisions between the business processes themselves.
Typically the enterprise reporting model is not built immediately and the
model starts from smaller building blocks. However, due to the immense
value of being able to report across business processes it is useful to have a
model that will grow after the initial production offering.

Cognos Proprietary Information

Flexible Model Solutions 5

The key to allowing a model to grow lies in the concept of dimensional

design. A dimension is a collection of similar attributes and properties.
Geography and Time are prime examples of dimensions. A geographical
dimension may contain details such as country, state, county, street address,
or zip code while a time dimension would contain items such a year, quarter,
month, and day. The information in each dimension is separate and distinct
and we can see that there is no logical overlap between the information
stored in the geographic and time dimensions.
Depending on the data source that is used for the model the ability to identify
these dimensions may be more or less difficult. For a data source that is
highly normalized there may be several tables that would define a single
dimension. To return to the Geography example, there may be a table for
each of country, state, and city with appropriate keys linking the 3 tables.
Another case is when working with a slightly denormalized data source that
defines the dimensions for you in a single table, merging country, state, and
city. The denormalized approach will result in some data redundancy as the
higher level data such as country will be replicated for each matching state
and city combination. One final scenario occurs when all the data is entirely
denormalized and exists within a single table where Geography, Time, and
fact data exist in the same table structure.

In the example above we can see two examples of table design within a data
warehouse. On the left there are multiple tables that combine to produce the
dimensional information for the Product dimension while a single table
populates the query subject on the right. By defining determinants in the
same order and with the same keys the rollups will be identical for both
approaches. The several tables that are used in the normalized approach can
be merged into a combined model query subject that will provide the same
look and feel as the denormalized dimension with its single point of entry for
the common product information.

Cognos Proprietary Information

Flexible Model Solutions 6

Modelling entirely denormalized data, as in the image below, can become a

very difficult process when trying to relate data across business processes as
it is difficult to relate different sets of data. Likewise, performance will likely
suffer due to the large pages of data that a relational database will need to
process to extract the subset required for a query. When working with these
totally denormalized data sets it is often best to review the design with the
data source before modelling within Cognos products. Creative modelling can
overcome some of the challenges in relating the data across processes but it
cannot overcome the performance considerations that will arise due to the
design of the data source itself.

When working with dimensionally modelled data (partially denormalized) or

normalized tables one of the best approaches in regards to model growth is
to evaluate these tables for common elements that can be reused for future
projects. With proper planning and foresight the growth process will proceed
much more smoothly when integrating other business units and processes
into your model. An effective tool for this analysis is the Data Warehouse Bus
Matrix1. The original purpose of this technique is to assist in data warehouse
design but it is equally applicable to the dimensional design of a Framework
Manager model as well.
The Bus Matrix allows quick and easy comparison of business processes and
their associated dimensions. Reviewing this information can identify common
areas and areas where data cleansing and realignment would benefit the
organizational processes.

Common Dimensions
Business
Process Date Branch Department Product Customer Employee Geography

Human X X X
Resources

Accounting X X X X

Sales X X X X X X X

1
R. Kimball and M. Ross, The Data Warehouse Toolkit, 2nd ed., (New York, Wiley Computer
Publishing, 2002)

Cognos Proprietary Information

Flexible Model Solutions 7

The table above allows a quick scan of the relevant data for each business
process. The format allows common areas to be quickly identified such as the
Branch dimension. Depending on how the business processes operate the
Branch information could be modelled in several ways.
For example, a Branch may be closely tied to its Geographic location or to a
Department. If the Brach information only relates to one of these dimensions
then it would be a logical choice to generate a query subject that merges the
Branch with the single associated parent dimension. On the other hand, the
Branch may have no relationship at all to Department or Geography and
would stand as its own dimension without any ties to the other dimensions in
the mode. Finally, a Branch may be tied to both a Department and
Geographical location and it would make sense to have a specific Branch
dimension with multiple hierarchies based on Department and Geography
respectively.
The choice for the modelling approach in such a scenario depends largely on
the logical relationships between the types of data that are being tracked by
the business process. If there is no relationship between the data then the
choice should be for separate dimensions. If there is a relationship then
combining the dimensions for logical reporting should be considered.
The true strength of the Bus Matrix is that it allows for a forward-looking view
of the modelling process. The current project may only be addressing the
Human Resources reporting requirements but the Bus Matrix shows that
there are other business processes that could make use of the Date,
Employee, and Geography dimensions at a later date. By reviewing the
common requirements it is possible to build in appropriate join keys to relate
the other business processes and ensure that the dimensions are modelled to
reflect the appropriate dimension granularity across the multiple processes.
For example, Accounting may be interested in the Monthly grain total
expenses while Human Resources is tracking the daily movement of
employees within the organization. In such a case it would be valuable to
build in the relevant key field for the month join to the accounting fact tables
and build a determinant in the date dimension at the month level with the
group by clause. With these items added during initial model development it
is a simple process to link the Accounting fact tables into the model at a later
date. Likewise, if the model were starting with the Accounting processes then
it would be useful to include the Day level granularity into the Date dimension
to make it easier to integrate Human Resources fact data.

2.2 Flexibility and Reporting

Reporting can be categorized in many ways. In regards to model flexibility
the two main categories are ad-hoc reporting and canned reporting. Typically
the development community for canned reports is small and the consumer
base is large while with ad-hoc reporting this ratio is reversed.

Cognos Proprietary Information

Flexible Model Solutions 8

When modelling for these two types of reporting there is a tendency to use
considerably different approaches. Ad-hoc models will tend towards general
query subjects that allow a wide range of business questions to be answered
by a single model. Canned models often tend towards individual query
subjects that serve to address the specific requirements of the canned
reports. With regards to a scale of flexibility ad-hoc models are most flexible
while canned models are at the least flexible end of the scale. Consider the
following as an illustration of the narrowing of scope for the two applications.

At the ultimate end of the scale it is even possible to design a complete

report query as a query subject within the model. The result of such a query
limits the use of the query subject so that it can only ever satisfy a single
report query with any efficiency.
The development time required with these various approaches will vary based
on the number of reports to be created. When there are very few reports
each modelling approach will take relatively the same amount of time to
complete. As the number of reports increase the models with narrower vision
will suffer increased development time because there will be little within the
model that can be reused for subsequent reports. In the extreme, if query
subjects are used to satisfy individual report requirements then every new
report will require a start-from-scratch modelling commitment.

Cognos Proprietary Information

Flexible Model Solutions 9

At the beginning of a project the effect of a particular design approach may

not be immediately visible. However, project scope and requirements most
often grow over time. By limiting the vision of a model at the start of a
project the future costs associated with creating reports or updating the
model can be large. By modelling dimensionally it is possible to reuse query
subjects in many different ways and for many different reports. This reuse
will make updates and maintenance a simple process as global changes can
be propagated to all associated reports at once while individual report
changes can be made in the specific report without impacting any other
applications.
Developm ent Developm ent and Maintenance

Development Time
Development Time

Num ber of Reports Num ber of Reports

Ad-Hoc Canned Single Report Ad-Hoc Canned Single Report

3. Summary
A metadata model is a foundation for both future modelling and report
development. There are two key areas that need to be addressed to ensure a
successful model.
The first area is understanding the scope of the current data set in terms of
all the other data in the organization. By looking ahead it is possible to
esablish common data structures that will easily integrate the data from other
business processes. Likewise, by understanding different data formats you
can proactively model for this integration or identify areas where data
warehousing or tuning will benefit the organization.
The second area is understanding your user population and how they will
access the data that is being made accessible through the model. By focusing
on a nearsighted goal it may be possible that the long-term needs of the user
community are being lost. It is difficult to modify a model that has been
designed with too narrow a focus to meet wider user needs. By identifying
who the current users are and what your user base may be in the future it is
possible to select the approprate range of vision for a model.
With only a little forsight and planning at the beginning of a modelling project
it is possible to reap large gains when the model is called upon to grow with
your users. Further, proper planning will save considerable effort for
everyone involved in the maintenance of your model metadata.

Cognos Proprietary Information