uniqueness of levels and members over multiple hierarchies
Open Java API for OLAP
Brought to you by:
jhyde,
lucboudreau
Menu
▾
▴
On a conceptual level a level and its members can belong to different hierarchies within a dimension, but the org.olap4j.metadata.Level and org.olap4j.metadata.Member interfaces have several methods that bind them to a single org.olap4j.metadata.Hierarchy.
The most obvious example is the getHierarchy() method.
Can you explain the reasoning behind this choice?
As a rule of thumb, if they belong to a different parent, they are different members. Since everything in an OLAP tree has parents, it is ok to assume that two members from two different hierarchies are not the same member, even though the backing OLAP server might use the same column in the RDBMS.
Also, when you call member.getHierarchy, you want the one directly above in a context that is implicit. If we were to return all the hierarchies, you wouldn't be able to figure out in what hierarchal context is the member living.
When you say that they are the same 'on the contextual level', this is OLAP-server specific. As far as olap4j is concerned, they are not since they belong to a different hierarchy.
If you can come up with a use case that would require the API to return all the levels where a member can be found, we might consider it.
It sounds like what you want is what Mondrian (version 4) calls an "attribute". An example of an attribute is Day, which lives in the Date dimension. It can be included in multiple hierarchies. Each inclusion of an attribute in a hierarchy is called a level.
Suppose that you use the Day attribute in the hierarchies Monthly (which is based on attributes Year, Month, Day) and weekly (which is based on attributes Year, Week, Day). Each of those hierarchies have a member representing today, 2013-10-15. They would be different members, because the parent of [Date].[Monthly].[Day].&[20131015] needs to be the month [Date].[Monthly].[Month]&[201310], and the parent of [Date].[Weekly].[Day].&[20131015] needs to be the week [Date].[Weekly].[Week].&[41]&[2013].
But the members have the same key, so it is possible to convert one to the other.
MDX and XMLA do not include attributes natively. All you can see are the levels, not the attributes that were used to build them. But in olap4j version 2.0, Level will have a method called getAttributeHierarchyName().
http://www.olap4j.org/2.0/api/org/olap4j/metadata/Level.html
Julian
I said "conceptual" not "contextual" which by its definition excludes implementation specificness.
If you think about a Time dimension, do you see Year in the Monthly hierarchy as a different concept than Year in Weekly?
I sure do not. I see it as the same level in a dimension arranged in different hierarchies.
Of course, from an implementation and query (MDX) perspective, it's easier to see them as being different levels.
Indeed, once the cube is build, this conceptual information is/could be lost and therefore olap4j can't show what isn't there anymore.
A Mondrian "attribute" indeed seems to be the implementation of my "conceptual level".
Unfortunately this is OLAP-Server specific and my OLAP Server (SAS) doesn't support it.
Thanks for the feedback.
I don't think it's productive to divide things into conceptual, logical, physical. They are relative to the other elements of the architecture. Ask someone who designs storage devices what they mean by "logical". The only absolute is what appears on the screen, the behavior as experienced by the end user. (Mathematics and physics have yet to give us an absolute at the other end of the continuum.)
In Mondrian and SSAS you can create two hierarchies, each with levels based on the Month attribute, and make sure that members of those levels look the same when they appear on the screen. They have the same key, name, sort order, and properties. At the MDX level, they have different parents, but of course we need that.
I don't know what SAS OLAP supports. You could try creating hierarchies with a single level. Those are what SSAS and Mondrian call "attribute hierarchies". Then it's really up to your users whether to include "Month" their reports alongside "Year", "Quarter" or "Cat breed".
If MDX were defined today, I think it would include support for attributes as first-class objects. Attribute hierarchies are an acceptable workaround for servers that support attributes, and it's good that you can speak MDX, XMLA and olap4j to servers such as SAS OLAP that do not.
Julian