Namespace and Unique Names

OLE DB Programmer's Reference

The query expression examples given in previous sections use member names. However, MDX syntax allows expressions containing dimension, hierarchy, and level names as well.

If all data source objects require that all object names used within a cube be unique, you can use unqualified names (as in the examples). The domain within which an object name must be unique is called the namespace of that object. In other words, if the namespace of all objects were the cube, there would be no problems. However, this is not always the case.

Data source objects that allow for more granular namespaces require that hierarchy and level names be unique within a cube.

However, members can have very granular namespaces, 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 namespace 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 namespaces, 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.

This situation 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 might not always work. For example, if the name of an ancestor member changes, 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 about the contents of the unique name given by a provider. Specifically, it should not assume that the unique name is a qualified name. Providers can generate a unique name in any way. The provider guarantees only that the unique name unambiguously references an object.

Note   If you are dealing with namespaces of objects across all cubes in a schema or across all schemas in a catalog (queries involving multiple cubes), 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.

Like other aspects of the schema, unique names can usually be treated as persistent between sessions. However, the OLE DB for OLAP provider may allow administrative procedures that result in changes to the unique names of various objects, such as changing the name of a cube or dimension.

1998-2001 Microsoft Corporation. All rights reserved.