I'm not sure if following points are correct:
1. If you want to take advantage of dimensional function such as MDX, dimensional functions (PreMemver, LosingPeriod...) , then your only choice is the model based on true OLAP, not the DMR. OLAP is much easy for reports with YTD, LAST YEAR requirements
2. If you want to use SQL and corresponding functions, you may choose DMR. In this case, Cognos provides a little bit of multidimesional functionalities, such as drill up/down. But for those reports that need YTD, Last Year..., you have to construct them in DMR through SQL. MDX and dimensional functions are with lots of restrictions in DMR for now.
Am I right?
Thanks
From 8.4 presentations I'd say that using DMR is not something to go for in 8.3 and earlier versions. The ordering issue is the real showstopper and this appears to be solved in 8.4.
So we are able to enjoy full MDX and DMR facilities in 8.4 ;D. If you have DMR and MDX experiences in 8.4, please throw lights on it.
Some dimensional functions do not work with DMR, like ParallelPeriod(), Cousin() ... for example. Cognos has an FAQ that shares all of those functions that will not work with DMR.
http://support.cognos.com/supported/docs/en/html/cognos8_bi/8.2/rdm_cr_id3217CannotSpecifytheOrderofMembers.html
This was an 8.2 document, that I think still applies, but you may want to check with Cognos
Other than that and the fact that you can;t order levels in 8.3 back, DMR works very similarly to OLAP, EXCEPT it is never going to be as fast as a PowerCube.
Quote from: will.sl on 19 Dec 2008 09:53:40 AM
So we are able to enjoy full MDX and DMR facilities in 8.4 ;D. If you have DMR and MDX experiences in 8.4, please throw lights on it.
Today we reviewed the first set of packages build with DMR in 8.4.
We have quite small datasets (up to a couple of 100K fact rows) and performance is pretty acceptable.
What really makes us happy is that we can now show dimensional attributes directly under the dimension keys in an AS report. This is a truly great asset for management reporting from a dimensional source.
We have not been able to come up with a solution for a ragged hierarchy (i.e. some levels may be missing for a node) So, if you have a max of 5 levels and for a certain value 2 levels are empty, then you still have to drill down through N/A , N/A to the lower levels. In a transformer model this is handled better as the empty levels can be surpressed.
Zero suppression for nested values seems to work properly in 8.4, but that is not specific for DMR I guess