Database Reference
In-Depth Information
so we will have to live with the confusion, drawing some comfort from knowing how
they behave in reality.
At first look, Attribute dimensions being Stored are fast to calculate and
can be aggregated, and because there is no net effect on the bitmap length, they
should be cheap to incorporate in your cube and have no special implications to
the query performance of your cube. unfortunately, that might not always be the
case. In the DBAg, we find the following, which is reprinted with permission from
oracle Corporation,
Oracle Essbase Administrators Guide Release 11.1.2.1
(oracle
Press, 1996, 2011) Chap. 62, p. 933
,
with my highlighting in italics on the most
important parts:
Design Considerations for attribute Queries
When selecting and building views based on attribute query data, some queries
on attribute data are always dynamically calculated at the time of retrieval, which
may affect query performance.
Every query involving attribute dimension members also must include at least
one member from the base dimension. If the query involves a single attribute
dimension and a sum-of-all dimension member, Essbase aggregates the query
data, potentially improving query performance.
In other cases, Essbase must cal-
culate the query at the time of retrieval.
(table 200 describes attribute query types
and how Essbase calculates the query.)
Table 200
Attribute Queries and Calculation Performance
Attribute Query Type
Query Calculation Type
Query involves a sum-of-all base dimension
member and members from one attribute
dimension.
Essbase can aggregate query data, potentially
improving query performance.
Query involves any member of the base dimension
and members from multiple attribute dimensions.
Essbase calculates the query at the time of
retrieval based on the level 0 input data.
Query involves any child member of the base
dimension member (or dimension member that
is tagged as label-only) and members from one
attribute dimension.
Essbase calculates the query at the time of
retrieval based on the level 0 input data, or
on data from aggregations on the base
dimension.
The first Query type can take advantage of aggregations on the Attribute dimen-
sion and is no problem (assuming that Attribute aggregation has been enabled using
“Consider Alternate hierarchies” and aggregations have been materialized). The third
type of query is also not a problem. While queries of the third type are not as easily
improved as the first type, they can take advantage of base dimension aggregations.
It is the highlighted second type of query that presents a problem. This is a very common
situation. Queries are often run on multiple Attributes of the same dimension and you
should carefully consider how your cube will be used.
It should be noted that queries of the second type are not totally out of the realm of improvement from aggregations:
It would simply have to be an aggregation in another dimension. Aggregations are not required for all cases (e.g.,
upper-level members of all dimensions) to be useful; if they were, then we essentially would have a BSO cube. Instead,
they are like stepping stones, different ones can be used to cross the river without getting your feet wet (i.e., querying
the input-level data). In this case, the query engine simply would be restricted to choosing an Aggregation with level-0
for the [Products] dimension.
