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

Using the e.list as a dimension advantages and best practice

Started by MC, 18 Jan 2011 03:51:53 PM

Previous topic - Next topic

MC


So I have been trained to add the elist as a separate dimension in Analyst but I'm struggling to understand why?

For example if you have a cube that consists of:

Cost Centres, Segments, Currencies and Quarters

Training says that you should have another dimension which just has elist in it as a placeholder for the elist in Contributor so the cube in analyst would look like this:

Cost Centers, Segments, Currencies, Quarters, elist


If the elist is the same as the cost centers why not use them instead of adding the elist item? It seems adding the elist you are opening yourself up to data duplication? i.e. if the elist is Cost centers and you have the elist placeholder in the cube you are duplicating the data?

Please advise or explain, or if you have any articles on this please post them

Thanks

ericlfg

Hey MC,

I'll try to explain this to the best of my abilities:

You can use your cost centers dimension as the elist, especially if that makes sense in regards to the cube structure and business hierarchy...  If you included "elist" as an additional 5th dimension and intended to use it as the elist in a contributor application, then Cost Centers wouldn't make sense to have -- as the hierarchy is built in the Contributor Admin Console (CAC) to be published to the web.

The recommendation and best practice (and even looking at the cognos samples) is to insert (elist) or some identifier to the dimension name so you know that it's the elist in contributor.  Duplication of data wouldn't necessarily be a concern, but rather the complexity of the model and the flow.  Using your lowest example with 5 dimensions, you would build an application and use "elist" as the elist in contributor.  It wouldn't make sense to then populate your Cost Centers dimension with the identical hierarchy used in the CAC.  You would have the workflow hierarchy in the contributor application, and then in this particular cube you would have a slice with all of the hierarchy present again.

Hope this helps..

Cheers,
Eric

PS, Alexis (or anyone) correct me if I'm wrong in any point -- I'm just going by what I've seen and my experiences.  I've never really put much thought into it.

Rutulian

Hi MC,

Eric's covered this to the best of my understanding - the goal is to keep your Analyst library more manageable by substituting a 1-item dummy elist for the dimension which it represents, so in your case Cost Centers.  I'm fairly new to modelling but I don't see any problem with just tagging your initial dimension name with elist, so if you have apps with different e.lists it's easy to figure out which is going on.  So your cube would have:

Cost Centres -elist, Segments, Currencies, Quarters

If you have the full elist in your Analyst cubes you can end up hitting the Analyst 25-30 million cell limit - for instance an app with 500,000 cells per slice in one cube and an elist of 1000 will give you 500m cells in Analyst and you won't be able to work with it.  Keeping the elist as a single-item dummy in Analyst means your Analyst model represents a slice, rather than the whole application.

It's not uncommon to see parallel libraries, one with the full e.list (or an important subset of it) for analysis purposes after Contributor's done all the data collection, and one with the dummy which is a skeleton for the Contributor model.

Cheers,
Alexis