Dependent Dimensions
A dependent dimension is a dimension that has members that are determined by the members of another dimension. Regular, virtual, and parent-child dimensions can support this dimension characteristic.
Making one dimension dependent on another is advantageous when the cross product of the members of the two dimensions results in a significant percentage of combinations that cannot coexist. For example, a Customer Gender dimension is dependent on a Customers dimension. Fifty percent of the combinations that result from the cross product of the dimensions' lowest-level members cannot coexist because a customer can have only one gender.
To make a dimension dependent on a second dimension, edit the first dimension in Dimension Editor (if the first dimension is shared) or Cube Editor (if the first dimension is private) and select the second dimension in the Depends on Dimension property in the properties pane. It is not necessary to specify dependency in both dimensions. For example, if in Dimension A you specify that Depends on Dimension is Dimension B, it is not necessary to also specify in Dimension B that Depends on Dimension is Dimension A.
All virtual dimensions are dependent dimensions. However, because aggregations do not apply to virtual dimensions, the Depends on Dimension property has a different use in virtual dimensions than it does in regular and parent-child dimensions. A virtual dimension's Depends on Dimension property identifies the dimension that contains the member properties or columns on which the virtual dimension is based.
In a Microsoft® SQL Server™ 2000 Analysis Services database, multiple dimensions can have the same value for their Depends on Dimension property.
Dependent Dimensions and Aggregation Design
For certain dimension varieties, if a dimension is set as a dependent dimension, its aggregation design characteristics may be affected. If a regular or parent-child dimension is a dependent dimension, the design of aggregations for partitions that include the dimension is optimized according to the dimension on which the regular or parent-child dimension is dependent.
When aggregations are designed for partitions that include dependent dimensions, aggregations for the nonexistent member combinations are excluded from the estimated storage size. For example, if Pat Coleman is a male, the estimated storage size excludes aggregations for the intersections of the Pat Coleman member and the Female member. Because aggregations for these intersections are not created when the partition is processed (regardless of whether the dimensions are dependent), the actual storage size is closer to the estimated storage size if the dimensions are dependent.
Note If you stop the aggregation design process before the aggregations for the nonexistent member combinations are reached, the reduction in the estimated storage size does not occur.
In Analysis Manager, aggregation design is performed in the Set aggregation options step in the Storage Design Wizard and the Usage-Based Optimization Wizard.