Database Reference
In-Depth Information
• my data is all or largely balance-sheet related or point-in-time measurements
and not transactional in nature and, therefore, heavy use is made of the time
Balance tags.
The accounts dimension is often large, with many levels of consolidation. making it
dynamic will have a major negative impact. There are alternative design options for the
two objections raised above that should be given serious consideration. For the first point,
I refer the reader to Section 7.6.2.1 (time Spans (ytD, QtD) using Stored hierarchies).
For the second, please consider Section 7.6.2.4 (Loading “Balance Data” or “Flow Data”).
The typical large size of the Accounts dimension and its many levels make it a good
candidate for leveraging the power of stored consolidation and aggregations. of course,
this requires that the dimension be stored. you may find that the cube performance is
so much improved by converting the dimension to Stored that the process of designing
and materializing aggregations, though now possible, is not really needed.
The discussion of the Accounts dimension is summarized with our next rule:
r10: The use of the Accounts dimension tag has substantial costs; alternatives
should be considered strongly.
The extra emphasis in r10 “alternatives should be considered
strongly
” regarding
the Accounts tag versus in rule r9 regarding the Compression tag is intentional. There
are really good alternatives and no performance-related benefits to using the Accounts
dimension tag that I know of.
7.4.3.5 Implied Sharing and “Never-Share”
As introduced earlier (in Section 7.4.2.1),
the concepts of Implied Sharing and the “never-Share” tag are still in use in ASo
cubes as they were in BSo. As in the example just referenced, Implied-Share members
do not affect the size of the bitmap. however, tagging them as “never-Share” also does
not appear to affect the size of the bitmap. The only impact of setting the “never-
Share” tag appears to be that noted in the DBAg, which is reprinted with permission
from oracle Corporation,
Oracle Essbase Administrators Guide Release 11.1.2.1
(oracle
Press, 1996, 2011) Chap. 62, p. 932:
Note:
In an aggregate storage database, a shared member automatically shares
any attributes that are associated with its nonshared member. This also applies to
an implied shared member (for example, a member that has only one child). See
“understanding Implied Sharing”. you can prevent implied sharing by setting
the never Share property; see “Determining how members Store Data values”.
This behavior of shared members and attributes in aggregate storage databases is
different from the behavior in block storage databases.
7.4.3.6 Most Efficient Hierarchies
you may have noticed the use of the phrase “almost
always cheap” back in rule r5:
r5: Alternate hierarchies, whether Dynamic or Stored or Attribute, are almost
always cheap … give the user what they want.
