An attribute dimension in Oracle Essbase is a secondary, classification dimension that associates descriptive properties with members of a base dimension — allowing data to be queried by those properties without creating a full independent dimension. An attribute dimension is not a storage dimension; it does not create data blocks. Instead, it defines a set of attribute values — for example, a “Region” attribute with values North, South, East, West — and associates each member of the base dimension (individual cost centres, for example) with one of those attribute values. When a report queries “show me total costs by Region,” Essbase retrieves the cost centre members associated with each Region attribute value and aggregates their stored data — dynamically, at query time — without the Region values having their own data blocks in the database.
Attribute Dimension Architecture
| Dimension Type | Storage | Aggregation | Query Performance |
|---|---|---|---|
| Base dimension (e.g., Cost Centre) | Creates data blocks | Pre-calculated parent rollups in BSO; dynamic in ASO | Fast — data physically stored or dynamically aggregated from blocks |
| Attribute dimension (e.g., Region) | No data blocks created | Dynamic at query time — aggregates base dimension members by attribute value | Slower than base dimension query — attribute lookup adds computation |
The base dimension member-to-attribute assignment is stored in the Essbase outline as a property of each base member, not as a data relationship. When “Cost Centre 101” is tagged with the Region attribute value “North,” Essbase knows to include Cost Centre 101’s data when a query asks for the “North” attribute aggregate — without storing “North” data separately.
When Attribute Dimensions Are Appropriate
Attribute dimensions are appropriate for analytical classifications that do not change frequently, that are properties of base dimension members (not of individual data values), and where the attribute analysis is an occasional analytical use case rather than a primary reporting requirement. Product classification (SKU size, colour, category), geographic grouping (city-level data aggregated to region), and account classification (fixed vs variable, controllable vs non-controllable) are typical attribute dimension use cases. Attribute dimensions are inappropriate for high-frequency queries against large member sets — because attribute lookup computation adds latency to every query — and for classifications that change frequently, because reassigning attribute values requires an Essbase outline restructure or member property update for every affected base member.
Attribute Dimensions vs User-Defined Attributes (UDAs)
Attribute dimensions and UDAs (User-Defined Attributes) both associate properties with base dimension members, but they differ in their query capabilities. Attribute dimensions create queryable, reportable analytical axes — a report can include “Region” as an axis and retrieve aggregated data by Region value. UDAs are tags that can be used in Calc Script FIX statements to filter which members a calculation processes, but UDAs cannot be used as report axes or MDX set expressions. The choice between attribute dimension and UDA depends on whether the property needs to be a reporting axis (attribute dimension) or only a calculation filter (UDA).
What Goes Wrong in Practice
The specific attribute dimension failure that most commonly surprises EPM architects is an attribute dimension applied to a base dimension with very large member count — discovering that attribute-based queries against the large base dimension are significantly slower than expected because the dynamic aggregation at query time must process thousands of base members to compute the attribute aggregate. Attribute dimensions applied to dimensions with more than a few hundred members should be performance-tested under concurrent query load before production deployment.
How Loop Wise Solutions Designs Attribute Dimensions
We evaluate attribute dimension usage as part of every Essbase dimension design — determining whether the analytical use case justifies an attribute dimension or whether an alternative approach (a separate hierarchy in the base dimension, or a reporting cube with pre-aggregated values) would provide better query performance. Attribute dimensions are documented in the dimension design specification with their base dimension assignment and their expected query pattern.
