The query expression examples given in previous sections use member names. MDX syntax allows expressions containing dimension, hierarchy, and level names as well.
If all data sources require that all object names used within a cube be unique, then you can use unqualified names (as in the examples). The domain within which an object name must be unique is called the name space of that object. In other words, if the name space of all objects were the cube, there would be no problems. However, this is not always the case.
Data sources that allow for more granular name spaces require that hierarchy and level names be unique within a cube.
However, there can be very granular name spaces for members, such as just the set of all siblings. That is, for any given member, each of its children must have unique names. Slightly less granular is the case where the name space of members is the set of members at the same level; that is, all members belonging to a level (such as States) must be uniquely named.
Because of such granular name spaces, names used within a query expression can sometimes be ambiguous. One way to make the names unambiguous is by qualifying a name to the extent necessary to make it unique. For example, in the Geography dimension, the name Portland is ambiguous because there is a Portland in Maine and another in Oregon. So, to make it unambiguous, it needs to be qualified by the state name: Oregon.Portland or Maine.Portland.
Note that this is further complicated by the fact that when the same member is part of multiple hierarchies, it behaves like two different members. Therefore, the unique name for a member must take this into account and generate two unique names for a member that is present in two different hierarchies.
Qualifying the name is just one way to ensure uniqueness. However, it may not always work. For example, if the name of an ancestor member changes, then the unique name is no longer valid. Therefore, any queries stored by the application become invalid.
A better way is for the provider to give the application a unique name. How the provider constructs a unique name is up to the provider, and is of no concern to the application.
OLE DB for OLAP has a mechanism that an application can use to get the unique name of any object in the multidimensional schema. This information is available in the schema rowsets. The UNIQUE_NAME column in a schema rowset always contains the name of an object that is unambiguous within the context of the cube.
When using the name of an object in an expression, the application must use the string obtained in the UNIQUE_NAME column of the schema rowset. It is up to the provider to make sure that this name is unambiguous. (This theme of using schema rowsets to help formulate a query is not unique to OLE DB for OLAP. It applies to OLE DB in general.)
An application should not make any assumptions of what the unique name given by a provider contains. Specifically, it should not assume that the unique name is a qualified name. Providers may generate a unique name in any way. The provider only guarantees that the unique name unambiguously references an object.
Note If you are dealing with name spaces of objects across all cubes in a schema or across all schemas in a catalog (queries involving multiple cubes), then all object names used must be qualified by cube name and, if necessary, by catalog name and schema name. This applies even to object names obtained from the UNIQUE_NAME column of a schema rowset.
In general, there are two ways for a provider to generate a unique name:
Using a qualified name as a unique name can have performance advantages. Because the name encodes the “path” to a member, it decreases the search required to locate that member. The disadvantage is that if the name of an ancestor changes, then the path becomes invalid. If the path becomes invalid, the queries stored in the application no longer work.
Using a unique string with no internal structure gets around this problem. However, because it no longer contains the path, the search time required to locate the member increases.
Note that it is possible to create a method that has the advantages of both these approaches. For example, the provider can return a string that encodes the “location” information without tying that to the uniqueness of the name itself.
Providers should keep these considerations in mind when deciding on what to expose as a unique name.