Dimension and Partition Processing - Microsoft SQL Server 2008 Analysis Services - page 385

ROLAP dimensions are designed for scenarios in which Analysis Services had to deal with
large dimension sizes. In most cases with the scalable MOLAP dimension architecture, it's
not so crucial to use ROLAP dimensions. You need to build a ROLAP dimension only if
your dimension is extremely large (containing hundreds of millions of members).
Processing Parent-Child Dimensions
Having a parent-child relationship between attributes in a dimension changes the way that
dimension is processed, compared with the way in which a regular dimension is processed.
When Analysis Services processes the key attribute of a parent-child dimension, it scans
the data retrieved from the relational database twice. During the first scan, Analysis
Services processes the key attribute as it would process any other attribute. It builds all
regular data structures, such as the key store, the properties store, the BLOB store, and so
on, but it doesn't create the related attribute map store. By building the key store, Analysis
Services defines the DataID for each member of the key attribute.
During the second scan of the retrieved data, Analysis Services resolves the DataID for
related attributes, including the parent attribute. The members of the parent attribute are
actually members of the key attribute. For example, in the Employee dimension, the
manager is also an employee in the same dimension; therefore, the member associated
with the manager has the same DataID in the parent attribute as in the key attribute.
There is an interesting aspect to how Analysis Services treats data errors during processing
of the parent-child dimension. If, during dimension processing, Analysis Services can't
resolve a member of the related attribute because it doesn't exist in the key attribute, it
handles this error according to the error configuration properties. If the error configura-
tion is set to DiscardRecord , Analysis Services cannot delete this record, so it stops
processing the parent-child dimension.
Analysis Services builds the parent-child hierarchy in a different way from how it builds a
regular hierarchy. You define a parent-child hierarchy in the conceptual model by specify-
ing two attributes: parent and key. However, Analysis Services builds the levels of the
parent-child hierarchy automatically. For each member of the key attribute, Analysis
Services iterates over all parent members directly or indirectly related to it, and calculates
the number of levels between the current member and the root (the member that doesn't
have a parent). Then Analysis Services finds the maximum number of levels and builds an
artificial attribute for each level in the parent-child hierarchy.
Because you can add new members to the parent-child dimension during incremental
processing ( ProcessAdd ) and updating ( ProcessUpdate ), the number of levels in a parent-
child hierarchy might change. This also means that the number of artificial attributes for
the dimension will change, too. Because this causes a structural change to the dimension,
Analysis Services invalidates the indexes for the current dimension, and the indexes of all
partitions built on this dimension. Analysis Services also has to clean all the caches
because the data in the caches is now stale. We recommend keeping changes to the
parent-child dimension to a minimum, especially any changes that might change the
number of levels within the parent-child hierarchy.