NW Business Intelligence Consulting

I'll admit it's a slow day and I'm in need of something new to put up on the front page and this is what I came up with. I've been messing about with Cognos 8.4 installs lately and in the process I usually try a few sample reports. I picked one at random as I usually do and I liked the look of it enough to check it out.

It had some nice spark-line charts so I thought I'd have a look at it in Report Studio and see what's going on behind the scenes. This particular report was based on a dimensionally modeled data source. This means the data source dimensions have built in hierarchies and when you work with them in Report Studio it means certain things are done differently. If you're not a Cognos developer this probably means nothing to you. In fact, if you're not a Cognos developer you're probably long gone by now! The nit I found to pick was lurking on the inside of this report.

First of all, here we have what I presume is supposed to be an example of Cognos Report Studio development provided for new and experience users alike. Something to learn from. One would expect it to follow basic best practices. At a minimum to follow recommendations found in the documentation provided by Cognos. Well, unless I've totally failed to understand the documentation, (yes, that's correct I did actually read the documentation) it appears this nice example shows just the opposite of what's recommended.

I opened one of the queries in the report and noticed a filter for Time. It was limiting the report to the year 2005. However, instead of what one might see in a typical non-DMR based report (i.e. [Year] = 2005) you see this:

[Sales].[Time dimension].[Time dimension].[Year]=[Sales].[Time dimension].[Time dimension].[Year]->[all].[2005]

This bit in bold is what Cognos calls a Member Unique Name or MUN (actually the entire bit right of the equal sign). It's unique to dimensionally modeled query subjects. Now if you look up MUN in the documentation you will see that Cognos specifically tells you to always use the alias and not the MUN. The alias for the bit in bold above is simply "[2005]". Report Studio actually displays the alias in its user interface and the MUN is only available when you look at the properties of an item. Either works in this case but clearly the alias is easier to read and if it is equivalent why use the more verbose MUN.

The screen shot below shows what it should look like if you use the alias as the documentation recommends. So, if you've looked at the sample reports and wondered what the funky syntax was, and didn't look it up, now you know. Hopefully you didn't follow the example. Like I said, slow day.

 

 

 

< Prev		Next >