General Guidelines - Size Structure and Volume

8/6/2019 General Guidelines - Size Structure and Volume

1/6


2/6

General Guidelines Size, Structure, and Volume 2

IBM Cognos Proprietary Information

Copyright

Copyright 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULCis an IBM Company. While every attempt has been made to ensure that theinformation in this document is accurate and complete, some typographicalerrors or technical inaccuracies may exist. Cognos does not accept

responsibility for any kind of loss resulting from the use of informationcontained in this document. This document shows the publication date. Theinformation contained in this document is subject to change without notice.Any improvements or changes to the information contained in this documentwill be documented in subsequent editions. This document containsproprietary information of Cognos. All rights are reserved. No part of thisdocument may be copied, photocopied, reproduced, stored in a retrievalsystem, transmitted in any form or by any means, or translated into anotherlanguage without the prior written consent of Cognos. Cognos and theCognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated)in the United States and/or other countries. IBM and the IBM logo aretrademarks of International Business Machines Corporation in the UnitedStates, or other countries, or both. All other names are trademarks or

registered trademarks of their respective companies. Information aboutCognos products can be found at www.cognos.com

This document is maintained by the Best Practices, Product and Technologyteam. You can send comments, suggestions, and additions [email protected] .


3/6



Contents

1 INTRODUCTION ............................................................................................ 42 SIZE............................................................................................................... 53 STRUCTURE................................................................................................... 64 VOLUME ........................................................................................................ 6


4/6



1 INTRODUCTION

As a companys reporting requirements grow, so too does the need forefficient 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 themodeler with a single object to maintain. This can cause more problems thanare anticipated at first because, as the model grows so does dependency onthis model and in the process restricting the modeler from breaking it up intosmaller more manageable models later on. This document will discuss someof the general guidelines for modeling with regards to size structure andvolume.


5/6



2 Size

While currently there are no documented limits to the size of a model, atsome point a model designer needs to evaluate the breadth of theinformation being put into his model. They need to keep in mind that themodel 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 needsto be easily consumed by the users. A namespace structure which containshundreds of query subjects each one containing in excess of 10 columnsquickly becomes unmanageable when pushed to the studios. Ad-hoc userstypically do not have the patience to navigate the tree window in QueryStudio to search through hundreds of tables to find the data item they wishto add into the report, and without the ability to search a package for aparticular data item they will eventually grow frustrated. When building yourmodel its best to design several small models which cover only the neededobject for the user base it is designed for. In every organization there is anatural 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 areused by all these groups while much easier to maintain it is really unrealisticthat each a member of the HR group will need the information which iscontained in the tables that the Sales group requires. By putting all thisinformation into one model/package it becomes more difficult for the users tonavigate the UI in order to build their reports. A better method would be tocreate smaller models, one for each group within the company, and link twoor models together for the rare users that require information from more thanone of the models. There will be users that transcend these groups, but theyare the exception to the rule and the number of people using these combinedmodels will be a small percentage of the overall user base. It also needs tobe clarified that there are differences between model size and package size,and which one affects the user experience. These are two distinctly differentstatements. Model size will affect the modeler or modelers and their ability toload and modify the model in Framework Manager. A good rule of thumb is ifthe model which is being used is too cluttered when trying to view it in thediagram viewer in Framework Manager then you likely are on your way to acomplex model. Package size affects the users both in the UI as it takes timeto navigate the structure to find the desired data elements, as well as thelength of time it takes to load the package into the studio. Before thepackage can be consumed by the studio it is retrieved from the content storeand then run through a SAX parser, and in turn an RTM file is created. Theinitial creating and loading of this rtm file takes some time and for the firstuser accessing this package there will be a hit against the time it takes to runthe 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, howeverthis file is created on each of the dispatcher boxes in a multi serverconfiguration 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 userand in turn improve the user experience.


6/6



3 Structure

When creating a model the recommended structure is either a 2 or 3 layerapproach. Importing the required database objects into a database view andthen creating a business view which will be used by the report authors off ofthe 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 arenow able to add cubes to a model so that both a relational and cubedatasource can be accessed within the same package. This now can causean unforeseen issue with regards to opening and accessing a package. Whenopening a package which has both a relational and cube datasource in it,both data sources require an RTM file to be created, regardless of whetherthe user is accessing both data sources in their report. There can be a delayin the time it takes to open a package with multiple data sources (Ierelational or cubes) involved, as it has to create the RTM files for eachdatasource.

4 Volume

While there isnt a hard coded limit to the number of objects that can exist ina model, as stated before there does at some point the model designer needsto evaluate the model and determine if the model design to too complex andcontains too many object to make working with the model in one of thestudios manageable. In modeling more doesnt mean better and its better tocreate smaller more manageable models rather than one large model witheverything in it. When dealing with a large data warehouse you may findimporting a small set of tables or columns into your FM model is rathertedious work. Unfortunately we dont provide a simple way of searching fordesired columns or tables from among those which are possible to be

imported from the data source. Further if you choose to import new tablesfrom the same data source in the future there is no way to identify the tablesor columns from that data source that you have already imported. Instead itis recommended that you import the entire data warehouse into a singlemodel, and then use that as a metadata repository and import the desiredobjects from the model rather than directly from the data warehouse. Whilethere will be a one time hit on the import time for the entire model, you willnow have the objects cached in a searchable format that can help youminimize the impact of importing a large volume of metadata.

General Guidelines - Size Structure and Volume

Documents

Transcript of General Guidelines - Size Structure and Volume