I came across Cognos DMR recently as I reviewed some Framework Manager material. Cognos DMR (or Dimensionally Modelled Relational) is a hybrid of a relational model and an OLAP (or dimensional) model. It is covered as a theoretical concept in any Cognos Framework Manager course, but beyond a purely academic exercise I have never seen any call for it. Why is this? Because the way I see it, it delivers the worst of both worlds. It requires extra work creating a dimensional model on a relational database, and it delivers poor performance because it is not using an efficient pre-aggregated OLAP source. If you instead delivered a true OLAP solution with a Cognos Transformer model, you avoid both of these problems.
In my 12 years of Cognos consulting, I have never seen or recommended a DMR solution. That is not to say that there are no exceptional circumstances that could make DMR an ideal choice. But I would argue that these circumstances are rare, and may be the result of someone trying to do OLAP on the cheap. If you are considering a DMR solution, ask yourself why you are not using Cognos Transformer to deliver a true OLAP solution. If you have a valid reason (including cost), then DMR may be your ideal choice. But be aware of the cost of your choice (particularly in performance) and factor that into your decision too.
If anyone has any success stories with DMR I would be curious to hear about them!
#1 by Paul Mendelson on July 3, 2012 - 3:57 pm
There have been a few times where I’ve had to use DMR. A reporting platform for a website, they needed to show up to the minute information while comparing against another time period. Modeling the non-additive measures would have been an absolute nightmare. As long as the queries are built correctly, with plenty of testing to ensure no local processing, DMR doesn’t cause that much of a performance hit.
For the most part I urge my clients towards SSAS (or even Essbase on occasion), with PowerCubes as a last resort. Debugging DMR queries can be difficult, especially if DQM is enabled. I’ve had problems with DMR and indexes in the past.
#2 by Scott Andrews on July 3, 2012 - 4:13 pm
Thanks for your comments, Paul.
#3 by CognosBI on July 11, 2012 - 3:42 pm
Another reason to use DMR is to be able to report on attributes of a dimension level. For example, the level could be Customer, but in Transformer it’s very cumbersome (if not downright impractical) to also report on Customer attributes such as address, city, state, contact, phone, etc. Yes, you can drill-to-detail, but most users want the data in the main report.
#4 by Scott Andrews on July 11, 2012 - 4:55 pm
Usually city/state/region info offer a convenient way to group customers in Transformer, but I can certainly see your point about full address info or contact info. That can gum up a Transformer cube very quickly. Thanks for your comments.
#5 by Paul Mendelson on July 15, 2012 - 9:39 am
That argument works just as well for adopting a real more mature OLAP source, like SSAS or Essbase.
#6 by Paul Mendelson on July 15, 2012 - 9:40 am
The real was supposed to be in [s]strikeout[/s]…
#7 by Naresh Jasotani on October 3, 2012 - 9:47 am
I agree that the DMR should be included as a part of you solution, only when its an absoulte necessity. However, I have experienced a wonderful DMR performance on Teradata when the database is tuned wonderfully. It worked for the reporting solution. (Though we were heavily database dependent – in terms of aggregated table/indexes and caching.)
As someone already commented, DMR provide a solution to display multiple attributes at a level, I feel if the database is corretly tuned and the data is fetched from an aggregated table like MQT in DB2 and MVs in Oracle then it makes sense to use DMR.
- Thanks
Naresh Jasotani