Database Reference
In-Depth Information
Figure 7.20 ASOsamp with two new noncompound attributes (left) and compound attributes (right). (From Oracle
Essbase Administration Services. With permission.)
7.6.2.5 Compound Attributes Previously (near the end of Section 7.4.3.2), the issue of
query performance degradation due to queries against multiple attribute dimensions
was introduced. one possible solution is to convert one of the Attribute dimensions to
a Stored dimension. This, of course, means that your users will always have to include
that dimension on their spreadsheets, and the former Attribute association will have to
be made on every data record at load time instead of through metadata when the outline
is built.
The alternative, that of manually compounding the attributes into a single attribute
dimension, should be considered. to demonstrate this approach, ASosamp has been
modified on the left side of Figure 7.20 with two newly added attributes of the [Stores]
dimension: [how Big] and [Location type]. Querying against these two attributes pres-
ents the performance problems I have discussed. The right side of Figure  7.20 shows
these two attributes combined into a compound attribute.
obviously, this could be a maintenance nightmare with larger, frequently
changing Attributes. however, there is the advantage that “illegal” combinations
are not offered to the user when they create queries. only those combinations that
you have explicitly set up can be queried by the user. This would be a definite advan-
tage in the case of larger, more generic attributes. For instance, an auto manufacturer
could have [make] and [Color] as attributes, but ensure that while the user could
query for ([Pink], [Cadillac]), nobody would waste their time with a query for
([Pink], [Corvette]). okay, maybe there are some pink Corvettes out there, but you
get the idea.
Search WWH ::




Custom Search