Guideline

General Guidelines – Size,

Structure, and Volume
Product(s): Framework Manager
Area of Interest: Modeling
General Guidelines – Size, Structure, and Volume 2

Copyright
Copyright © 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC
is an IBM Company. While every attempt has been made to ensure that the
information in this document is accurate and complete, some typographical
errors or technical inaccuracies may exist. Cognos does not accept
responsibility for any kind of loss resulting from the use of information
contained in this document. This document shows the publication date. The
information contained in this document is subject to change without notice.
Any improvements or changes to the information contained in this document
will be documented in subsequent editions. This document contains
proprietary information of Cognos. All rights are reserved. No part of this
document may be copied, photocopied, reproduced, stored in a retrieval
system, transmitted in any form or by any means, or translated into another
language without the prior written consent of Cognos. Cognos and the
Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated)
in the United States and/or other countries. IBM and the IBM logo are
trademarks of International Business Machines Corporation in the United
States, or other countries, or both. All other names are trademarks or
registered trademarks of their respective companies. Information about
Cognos products can be found at www.cognos.com
This document is maintained by the Best Practices, Product and Technology
team. You can send comments, suggestions, and additions to
cscogpp@ca.ibm.com .

IBM Cognos Proprietary Information

General Guidelines – Size, Structure, and Volume 3

Contents
1 INTRODUCTION ............................................................................................ 4
2 SIZE............................................................................................................... 5
3 STRUCTURE................................................................................................... 6
4 VOLUME ........................................................................................................ 6

IBM Cognos Proprietary Information

General Guidelines – Size, Structure, and Volume 4

1 INTRODUCTION

As a company’s reporting requirements grow, so too does the need for

efficient models to use in the reporting medium. Often the result is to create
one large model with all the possible reporting elements within it, leaving the
modeler with a single object to maintain. This can cause more problems than
are anticipated at first because, as the model grows so does dependency on
this model and in the process restricting the modeler from breaking it up into
smaller more manageable models later on. This document will discuss some
of the general guidelines for modeling with regards to size structure and
volume.

IBM Cognos Proprietary Information

General Guidelines – Size, Structure, and Volume 5

2 Size
While currently there are no documented limits to the size of a model, at
some point a model designer needs to evaluate the breadth of the
information being put into his model. They need to keep in mind that the
model they create will at some point be used to create a package and in turn
loaded into one of our studios. The end result is a model/package that needs
to be easily consumed by the users. A namespace structure which contains
hundreds of query subjects each one containing in excess of 10 columns
quickly becomes unmanageable when pushed to the studios. Ad-hoc users
typically do not have the patience to navigate the tree window in Query
Studio to search through hundreds of tables to find the data item they wish
to add into the report, and without the ability to search a package for a
particular data item they will eventually grow frustrated. When building your
model it’s best to design several small models which cover only the needed
object for the user base it is designed for. In every organization there is a
natural segregation of employees into groups when it comes to reporting.
For example Ajax Widgets has several departments, an HR, IS&T, Support,
and Sales departments. A model which contains database items which are
used by all these groups while much easier to maintain it is really unrealistic
that each a member of the HR group will need the information which is
contained in the tables that the Sales group requires. By putting all this
information into one model/package it becomes more difficult for the users to
navigate the UI in order to build their reports. A better method would be to
create smaller models, one for each group within the company, and link two
or models together for the rare users that require information from more than
one of the models. There will be users that transcend these groups, but they
are the exception to the rule and the number of people using these combined
models will be a small percentage of the overall user base. It also needs to
be clarified that there are differences between model size and package size,
and which one affects the user experience. These are two distinctly different
statements. Model size will affect the modeler or modelers and their ability to
load and modify the model in Framework Manager. A good rule of thumb is if
the model which is being used is too cluttered when trying to view it in the
diagram viewer in Framework Manager then you likely are on your way to a
complex model. Package size affects the users both in the UI as it takes time
to navigate the structure to find the desired data elements, as well as the
length of time it takes to load the package into the studio. Before the
package can be consumed by the studio it is retrieved from the content store
and then run through a SAX parser, and in turn an RTM file is created. The
initial creating and loading of this rtm file takes some time and for the first
user accessing this package there will be a hit against the time it takes to run
the report or load the package into the studio while this rtm file is created.
Once created it is reused for all users accessing the same package, however
this file is created on each of the dispatcher boxes in a multi server
configuration as the particular request is sent to each of the dispatchers.
Limiting the size of the package will limit the access time for the initial user
and in turn improve the user experience.

IBM Cognos Proprietary Information

General Guidelines – Size, Structure, and Volume 6

3 Structure
When creating a model the recommended structure is either a 2 or 3 layer
approach. Importing the required database objects into a database view and
then creating a business view which will be used by the report authors off of
the database view. This practice is the same in IBM Cognos 8 as it was in
IBM Cognos ReportNet, however with the addition of Analysis Studio we are
now able to add cubes to a model so that both a relational and cube
datasource can be accessed within the same package. This now can cause
an unforeseen issue with regards to opening and accessing a package. When
opening a package which has both a relational and cube datasource in it,
both data sources require an RTM file to be created, regardless of whether
the user is accessing both data sources in their report. There can be a delay
in the time it takes to open a package with multiple data sources (Ie
relational or cubes) involved, as it has to create the RTM files for each
datasource.

4 Volume
While there isn’t a hard coded limit to the number of objects that can exist in
a model, as stated before there does at some point the model designer needs
to evaluate the model and determine if the model design to too complex and
contains too many object to make working with the model in one of the
studios manageable. In modeling more doesn’t mean better and it’s better to
create smaller more manageable models rather than one large model with
everything in it. When dealing with a large data warehouse you may find
importing a small set of tables or columns into your FM model is rather
tedious work. Unfortunately we don’t provide a simple way of searching for
desired columns or tables from among those which are possible to be
imported from the data source. Further if you choose to import new tables
from the same data source in the future there is no way to identify the tables
or columns from that data source that you have already imported. Instead it
is recommended that you import the entire data warehouse into a single
model, and then use that as a metadata repository and import the desired
objects from the model rather than directly from the data warehouse. While
there will be a one time hit on the import time for the entire model, you will
now have the objects cached in a searchable format that can help you
minimize the impact of importing a large volume of metadata.

IBM Cognos Proprietary Information