Database Reference
In-Depth Information
Considering that the surrogate key of the fact table will not have any meaning
to our users, we will not display it directly to them, but we will use it in the
KeyColumns
property of the
key
attribute. In the following screenshot, we can see
the resulting
Invoice Details
dimension. The
Line Number
attribute has the
KeyColumns
property set to
ID_FactSales
and the
NameColumn
property set to
SalesOrderLineNumber
. The
Order Number
attribute has the
KeyColumns
property
set to
SalesOrderNumber
.
We might wonder why we didn't want to waste an attribute on the
Surrogate key
column on the fact table. The reason is that this dimension will be a very large one.
Its number of members will be the same as the number of rows in the fact table.
Using MOLAP storage for the dimension (which is the default of the dimension's
StorageMode
property) a
SELECT
DISTINCT
query is sent to the relational source for
each attribute of the dimension.
Setting the dimension
ProcessingGroup
property to
ByTable
may not be a good idea here. This setting reduces the number of SQL
queries generated during dimension processing to just one, with
Analysis Services finding the distinct dimension members itself.
However, for a very large dimension such as this it would mean
Analysis Services doing a lot of work that could exhaust its memory
resources and cause dimension processing to fail.
Search WWH ::
Custom Search