[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mondrian
Subject:    RE: [Mondrian] Re: NativizeSetFunDefTest
From:       "Julian Hyde" <jhyde () pentaho ! com>
Date:       2009-12-17 20:13:16
Message-ID: E4B9D875C021494EA0677EB3A23D8EF2 () mackerel
[Download RAW message or body]



> Pedro wrote:
>
> When I use [Foo].[Bar].[Zoo], how do I know if it's 
> [Dimension].[Hierarchy] or [Dimension].[Member] (or even 
> [Dimension].[Level]..) ?

The name resolution algorithm looks for direct descendants in the object
hierarchy first. So, in resolving [Foo].[Bar], if [Foo] is a dimension, it
will look for a hierarchy called [Bar] before it looks for a level called
[Bar]. And once it has found a match, it sticks with it; it doesn't
backtrack.

If there is not a direct descendant, it will look for indirect descendants.
So for example you can write [Time].[Month] because one of the hierarchies
in the Time dimension has a a level called Month.

That's the algorithm I inferred that Analysis Services uses, and it's an
algorithm that makes sense to me.

You don't even need to start with a dimension name. You can start names with
hierarchy, level or even member names. For example, [S] resolves to
[Customer].[Marital Status].[S].

(I don't recommend that you use unqualified member names in your queries,
even though Mondrian permits it. It is a lot more work for mondrian to look
up the members when it is parsing the query, since mondrian needs to read
data from potentially large dimension tables. Also, your application will be
more difficult to maintain because it's not obvious what the members mean.)

I don't remember offhand whether it requires descendants of the same type to
be unambiguous (e.g. requires that there is only one level in the Time
dimension called Month) or whether it just takes the first.

It has the unfortunate effect that if you've used multiple hierarchies in a
dimension in mondrian 3.1 (and apparently not many people have) you will
need to change references to these when the new naming convention rolls out.
But overall it's a much clearer naming scheme, and it allows you to group
all of your hierarchies -- including as many attribute hierarchies as you
want to create -- into a small number of dimensions. That's something your
business users will love.

Julian

_______________________________________________
Mondrian mailing list
Mondrian@pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian
[prev in list] [next in list] [prev in thread] [next in thread]