Applied dimensionality

New Supportlink‘s article on EP+BI led me to my 2cents on EP + BI integration topic:

Carefully select dimension for publish.

- Its elements will become columns in published table, so if you want database only processing, you’d be able to preform complex calculations (mean, percentile, variance) only on those columns. By adding local processing you gain flexibility but basically loose speed (cognos bi calculates worser that fine tuned sun-based oracle 10g )
- It won’t be updated automatically. Those cy_, it_  tables, containing dlist elements are repopulated with every publish (mind that in 8.2 incremental publish doesn’t do that, so you have to perform full publish after synchronize) and therefore you don’t have to update packages when those changes occur. And report’s items will be added automatically. But when dlist you selected as dimension for publish gets updated, you have to manually add new measures in FrameWork Manager and republish packages \ update reports. So select extremely careful.
Recently I’ve selected a dlist Measures with just two elements as dimension for publish in one of the projects. Reporting cube had 5  dimensions with lot’s of members each, but the first thing they changed — they added a new measure )

Build specially designed reporting applications

- Mind the time to load data in those applications and republish them. It maybe unacceptably long before numbers will appear
- Whereas you are creating such applications make sure they don’t get out of sync with applications they get data from. All synchronizations should be done at the same time for main and report applications. That leads to design principles once more, make sure all synchronizations go under the hood, packed in one synchronize macro. You’d save debugging time greatly.