tag:blogger.com,1999:blog-15319370.post7539188506697320178..comments2024-03-05T11:16:00.846+01:00Comments on Roland Bouman's blog: MDX: retrieving the entire hierarchy path with Ancestors()rpboumanhttp://www.blogger.com/profile/13365137747952711328noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-15319370.post-40382728372902903462015-08-30T23:07:55.623+02:002015-08-30T23:07:55.623+02:00Fabian,
of course it's good advice to make d...Fabian, <br /><br />of course it's good advice to make descriptive labels. <br /><br />But IMO, from a query tool's perspective, the problem does not go away. There will always be schemas with labels that need context of ancestors and the query tool better be able to deal with it. <br /><br />Because of this particular use case, I'm not really that worried about maintenance. The query tool should simply have a powerful generator that can figure out how to translate the user's requests into a query that can be executed and retrieve all required information. <br /><br />If the query tool decides it needs to generate extra elements that are not explicitly present in the user's model, then so be it.<br /><br />Final consideration - looking at the kind of labels you propose, I'm wondering whether this is really that good. It seems to me there is a risk of cluttering the view, because you're going to need a lot of text in some cases. In addition, creating these full context labels will have impact on the DWH loading process and add a maintenance cost on that end. I'm not saying that's bad, but I'm just pointing out that your solution requires maintenance too, just in another place.<br /><br />It seems to me the ideal situation would be if the query tool would be able to access all properties associated with a member and allow the user to define precisely how to generate the labels, using whatever member name, caption, property or even properties from related members (at ancestor or maybe even child level). Maybe this is a bit much for a ad-hoc analysis tool but for a report writer this seems like a hard requirement.rpboumanhttps://www.blogger.com/profile/13365137747952711328noreply@blogger.comtag:blogger.com,1999:blog-15319370.post-5706217835676992532015-08-30T17:53:05.903+02:002015-08-30T17:53:05.903+02:00I usually solve context problems by simply using b...I usually solve context problems by simply using better labels. In this case QTR1 could be Q1/2003, Q1/2004, Q1/2005.<br /><br />Time Time Ancestors<br />Q1/2003 All Years,2003<br />Q2/2003 All Years,2003<br />Q3/2003 All Years,2003<br />Q4/2003 All Years,2003<br />Q1/2004 All Years,2004<br />Q2/2004 All Years,2004<br />Q3/2004 All Years,2004<br />Q4/2004 All Years,2004<br />Q1/2005 All Years,2005<br />Q2/2005 All Years,2005<br /><br />Now the context is implicit, labels are still short, now you don't need ancestors to understand the MDX results. <br /><br />But end users always to ask for ancestors, so my response is just press show ancestors button. This kind of options are efficient and allow me to keep the MDX simple, also important for maintenance reasons, maintenance, maintenance, maintenance.<br /><br />Fortunately with Mondrian you can define alternate hierarchies, for example Quarter / Year / Month / Date to simplify user navigation when they try to compare quarters. In this example QTR1 label has sense.Fabianhttps://www.blogger.com/profile/08454895424366890589noreply@blogger.com