The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience. (1) [Avatar] Offline
Thanks for an informative book. It's really helped me to get going on Mondrian 4.

I have been using Mondrian 3 for some time but wanted to convert to Mondrian 4 for a new project. Got everything working now apart from one thing: I have a dimension which is dependent on what in Mondrian 3 was called uniquemembers='false'. When I look at what I assume is the latest documentaion for the Level element at then I find no mention of the attribute. I have tried putting it in anyway but it seems to have no effect.

I have a strong feeling that I am missing something here, but what?

julian.hyde (7) [Avatar] Offline
Re: What happened to uniquemembers='false' ?
It's an astute question. The answer is quite subtle, and it gives an indication of Mondrian 4 does things differently.

Mondrian 3 didn't have attributes, so you would define levels, and of course every level other than the root level has a parent level. It was quite common for a level's key to be its parent's key plus another attribute. For example, the key of Year is the_year, the key of Month is (the_year, month_of_year).

So, 'uniquemembers=false' was code for 'include the key columns of my parent level in the key of this level'. Month would be defined like this:

<Level name="Year" column="the_year" type="Numeric" uniqueMembers="true"/>
<Level name="Month" column="month_of_year" type="Numeric" uniqueMembers="false"/>

In Mondrian 4, all of those complicated definitions of keys, names, captions, properties, are part of an attribute. Levels are very simple -- just a use of an existing attribute. An attribute belongs to a hierarchy, but unlike a level it does not have a "parent". Therefore each attribute's key needs to be self-contained. So you would define Month with its full composite key.

A nice side-effect is that, to make this work, we had to implement composite keys properly. An attribute's key can have as many columns as you like, not just one more than its parent, as in Mondrian 3. And of course you can have composite foreign keys too.

Composite keys are still usually not a good design choice in a data warehouse. I still usually recommend surrogate keys, especially as the primary key of a dimension table. We've given you the rope. Be careful not to hang yourself.