Expert Cube Development with Microsoft SQL Server 2008

This is the rule for relational tables. However, you also need to remember
that the equivalent measure data type in Analysis Services must be large
enough to hold the largest aggregated value of a given measure, not just
the largest value present in a single fact table row.
[ 29 ]
Chapter 1
Always remember that there are situations in which the rules must be overridden.
If we have a fact table containing 20 billion rows, each composed of 20 bytes and a
column that references a date, then it might be better to use a SMALLINT column for
the date, if we find a suitable representation that holds all necessary values. We will
gain 2 bytes for each row, and that means a 10% in the size of the whole table.
SQL queries generated during cube
processing
When Analysis Services needs to process a cube or a dimension, it sends queries
to the relational database in order to retrieve the information it needs. Not all the
queries are simple SELECTs; there are many situations in which Analysis Services
generates complex queries. Even if we do not have space enough to cover all
scenarios, we're going to provide some examples relating to SQL Server, and we
advise the reader to have a look at the SQL queries generated for their own cube
to check whether they can be optimized in some way.
Dimension processing
During dimension processing Analysis Services sends several queries, one for
each attribute of the dimension, in the form of SELECT DISTINCT ColName, where
ColName is the name of the column holding the attribute.
Many of these queries are run in parallel (exactly which ones can be run in parallel
depends on the attribute relationships defined on the Analysis Services dimension),
so SQL Server will take advantage of its cache system and perform only one physical
read of the table, so all successive scans are performed from memory. Nevertheless,
keep in mind that the task of detecting the DISTINCT values of the attributes is done
by SQL Server, not Analysis Services.
We also need to be aware that if our dimensions are built from complex views, they
might confuse the SQL Server engine and lead to poor SQL query performance. If,
for example, we add a very complex WHERE condition to our view, then the condition
will be evaluated more than once. We have personally seen a situation where the
processing of a simple time dimension with only a few hundred rows, which had a
very complex WHERE condition, took tens of minutes to complete.
Download at Boykma.Com