[Mondrian] PAGES axis, and attribute hierarchies

Julian Hyde jhyde at pentaho.com
Wed Aug 3 02:31:43 EDT 2011


Benny,
 
I have opened this up the mondrian-dev list, as I think it gets to the core
of the "attribute-oriented analysis" issue. Hope you don't mind.
 
See reponses inline.



 [If analyzer supported a 3rd 'PAGES' axis, users would] want to split
levels from the same hierarchy across axis. For example, in the Product
Hierarchy, I want Product Family on the Page axis and Product Dept on the
Rows axis.  I don't think we can do this with Mondrian 3.3. 

It's not just the PAGES axis. If you have 3 years' data to display,
sometimes it's nice to put years on columns and months on rows. It's more
compact, and data for the same month in different years appears
side-by-side.
 
You can do a lot of this stuff manually in mondrian 3.3. You can create a
{Product] dimension with a [Product] hierarchy consisting of levels
[Manufacturer], [Dept], [Family], [SKU], and single-level "attribute
hierarchies" [Manufacturer], [Dept] etc.
 
There is currently no mapping between the Dept level of the product
hierarchy and the Dept attribute hierarchy. But let's suppose there was: a
method "Hierarchy Level.getAttributeHierarchy()". Would that be sufficient
to allow analyzer to decompose hierarchies?
 
Note that the schema designer would have had to create those attribute
hierarchies, and mondrian would have to deduce the mapping somehow.

Will this be possible with Mondrian 4.0? 

Yes, Mondrian 4.0 will allow you to define 'attributes' in your schema. It
will be easy to create a hierarchy for an attribute. In fact, it will have
its own hierarchy unless you set "hasHierarchy=false" in the attribute
definition.
 
And, when you define a hierarchy, you will just say "I want level X based on
attribute A, level Y based on attribute B". You've already done the work
defining keys, sort keys, properties when you define attributes.
 
I don't know yet how to expose the mapping. But I note that XMLA's
MDSCHEMA_LEVELS rowset has a LEVEL_ATTRIBUTE_HIERARCHY_NAME column. That
maps nicely to the getAttributeHierarchy method above.

The SQL generation will also need to be smart enough to know that both these
levels come from the same dimension so there should be only one join to the
underlying dimension table. 

It should already be smart enough. (Even if you define the single-level
hierarchies manually.) Please log a bug if it isn't.
 
Julian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110803/5a9f6eef/attachment.html 


More information about the Mondrian mailing list