If you are unable to create a new account, please email support@bspsoftware.com

 

News:

MetaManager - Administrative Tools for IBM Cognos
Pricing starting at $2,100
Download Now    Learn More

Main Menu

Framework Manager Best Practice

Started by wyconian, 23 Sep 2008 12:48:58 AM

Previous topic - Next topic

wyconian

Firstly apologies if I've posted this in the wrong place.

I've been asked to put together a brief document on best practice for framework manager.  The kind of thing we've been 'discussing' is should there be an import layer (direct from source) + intermedite layer (where aany calculations, aliases etc are developed) + presentation layer (where the reports are run against).  Also where should the relationships be and should we use shortcuts or fresh data subjects?

It's been a bit of a heated discussion so I'm looking for some ind of definitive bes practice documentation.  Does anyone have any ideas where I can find some?  I've already searched the knowledge base.

Thanks for your help.

blom0344

import layer

I'd say ALWAYS have this one and do not change the imported objects. AFAIK it is not a big deal to add SQL objects to the layer as the net result would be the same as importing a database view.
Adding aliases here is also not a big deal, but Cognos best practice would indicate using shortcuts.

transformation layer

Definitely needed when trying to remodel towards a set of starschema's , factdetection, determinants and the lot. Any calculations or derived fields should be created HERE

Presentation layer

Consists solely out of shortcuts to the transformation layer , but can for example consist of a pure folder structure for better reference.

Relationships is a mixed bag. If you are reducing snowflake to a star (merging dimensions) than the new model query subject will use a join from the datalayer. The join between fact and the resulting dimension is defined in the transformation layer.
You can witness this if you allow Cognos to work with the 'WITH' clause. What it in fact does is create a sort of global temp table (subquery factoring) that stores the resultset from the objects and join from the datalayer and uses this temp set as the basis for the model query subject

The shortest way to the scrapeyard is allowing SQL based objects outside the datalayer. In fact we have a load of these thanks to ignorance in the past and we are suffering as a result  :-\

wyconian

Thanks a lot for the reply big help