In Decision Support Objects (DSO), dimensions are represented by objects that contain collections of other objects that, in turn, represent levels in the dimensions. For example, a Time dimension often contains the levels Year, Quarter, Month, and Day. The levels of a cube are defined by columns in a dimension table that is stored in the data warehouse database. When a dimension object is processed, the Analysis server constructs the dimension and its levels and then populates them with members from the dimension table. For more information about DSO, see Introducing Decision Support Objects.
All DSO dimension objects implement the Dimension interface, and you manipulate these objects through this interface. The ClassType property of the dimension object specifies the dimension's type. The ClassType value of a database dimension is clsDatabaseDimension. The ClassType values of cube, partition, and aggregation dimensions (supported by the CubeDimension, PartitionDimension, DbDimension, and AggregationDimension objects) are clsCubeDimension, clsPartitionDimension, and clsAggregationDimension, respectively. The Dimension interface provides collections, methods, and properties to manipulate these objects. Dimensions reside in the Dimensions collection of the MDStore object that represents a database, cube, partition, or aggregation.
To use dimensions, create them in the Dimensions collection of a database object. Then assign some or all of the dimensions to a cube. The dimensions assigned to a cube automatically apply to its partitions and aggregations, and you can explicitly associate them with virtual cubes that use the cube.
This topic discusses different types, varieties, and uses of dimensions and provides information about how to work with them in DSO. For more information about dimensions, see Dimensions.
The following table describes each type of dimension and the context in which it is used.
Dimension type | Description |
---|---|
Database dimension | The dimensions are contained in a database |
Cube dimension | The dimensions are contained in a cube |
Partition dimension | The dimensions are used in a partition |
Aggregation dimension | The dimensions are contained in an aggregation |
Database dimensions define the structure of the dimension and the data source where the dimension tables exist.
Any of the database dimensions can be used in a cube, if a join can be made between the dimension table and the fact table of the cube. Cube dimensions have the same name as their corresponding database dimensions. When an existing database dimension is added to the Dimensions collection of a cube, DSO automatically defines and creates all of the cube level objects for the cube dimension. A cube dimension inherits its properties from the corresponding database dimension; some of those properties can be customized in the cube. For example, you can specify how a cube dimension is used in the design of aggregations by setting the AggregationUsage property of the dimension.
The dimensions of a partition relate to the dimensions of its parent cube in the same way that cube dimensions relate to database dimensions. Each partition dimension has a corresponding cube dimension and has the same number of levels as the cube dimension.
Aggregation dimensions are the dimensions used within an
For example, the following illustration represents two aggregations. The first summarizes sales by year for store cities and product brand. The Time aggregation dimension in this case has only one level: Year. The Store and Product dimensions have all of their respective levels. The second aggregation summarizes sales by Quarter and Region for products by category. The Time aggregation dimension has two levels: Year and Quarter. The Store and Products dimensions, on the other hand, contain only the first levels of each dimension: Region and Category.
DSO dimensions can be either shared or private. A shared dimension is one that can be used in multiple cubes, but a private dimension can only be used in a single cube. For more information about shared and private dimensions, see Shared and Private Dimensions.
Private dimensions use a special naming convention to identify the cubes to which they belong. In all other aspects, private dimensions are identical to shared dimensions. The name of a private dimension is constructed by using the cube name, followed by the caret character (^), followed by the dimension name. To create a private dimension in DSO, name the dimension according to this convention. This naming convention allows private dimensions in different cubes to have the same name, and the cube name prefix ensures uniqueness within the dimension collection of the database. For example, NorthWestSales^Stores represents a private dimension of stores created for use in the NorthWestSales cube.
You can programmatically determine whether a dimension is shared or private by reading its IsShared property. DSO determines the value of this property by examining the name of the dimension. All cubes, partitions, and aggregations that use the dimension inherit its IsShared property.
Parent-child dimensions contain self-joining hierarchies. Because the level hierarchy is variable, rather than rigidly set, parent-child dimensions are more flexible than regular dimensions. For more information about parent-child dimensions, see Parent-Child Dimensions.
In DSO, a parent-child dimension has a maximum of two levels: the (All) level, which is optional, and a second level that acts as a template for building other levels.
You can create a parent-child dimension by setting the SubClassType property to sbclsParentChild. When you define a parent-child dimension, the system uses source table data to build a dimension that has a level hierarchy of variable depth.
Virtual dimensions are based on the columns or member properties of existing regular dimensions, and they can provide additional information in cubes that use these regular dimensions. For more information about virtual dimensions, see Virtual Dimensions.
To build a virtual dimension using DSO, create a regular dimension and set its IsVirtual property to True. Next, set the DependsOnDimension property to refer to the underlying source dimension. Finally, create levels for the virtual dimension and configure the MemberKeyColumn property of each virtual level to point to a source level or member property in the source dimension.
Although it is possible to create a shared virtual dimension that is based on a private dimension, this virtual dimension will work only in the cube that contains the private dimension.
Note In earlier versions of Microsoft® SQL Server™ 2000 Analysis Services, virtual dimensions were limited to having an (All) level and a second level whose SubClassType was set to sbclsVirtual. The dimension itself had a SubClassType of sbclsRegular. This convention is still supported for compatibility, but the new method of setting the dimension's IsVirtual property to True should be used, because it is more flexible and efficient.
Collections, Dimension Interface