The Physical Data Model - Microsoft SQL Server 2008 Analysis Services - page 365

erty is set to Preserve ). When the partition data is stored on the disk, records in the map
store are not divided on key and data fields, and all fields are stored as data fields. This
enables Analysis Services to reduce the number of unused bits that would otherwise be
required to align the boundaries of the key and the data. However, when the map store is
loaded into memory, the keys ( DataID s of granularity attributes) are separated from the
data (measure values).

Because data in the partition is stored in the map store, it is divided into segments.
Segments are divided into blocks, and blocks into pages, as described earlier in this chapter.
When you design your model, we recommend that a single partition contain 5 to 20
million records, so the map store for the partition would have 100 to 400 data segments.

The following files support the map store, in which <version> represents the current
version of partition data:

. A map store header file, containing information about each segment (such as where

it starts within the map store file and how the segment is compressed), named
<version>.fact.data.hdr

. A map store file, containing the data for each segment in the map store, named

<version>.fact,data

. A string store file, containing string data for the map store, named

<version>.fact.string.data

Decoding Partition Attributes
To enable fast access to the data values stored in a partition by their coordinates—
attribute members—Analysis Services builds indexes. Indexes are built for the attributes
related to the data contained in this partition. An attribute is related to a measure group
when it belongs to the dimension that is included in a measure group and is located
above the granularity attribute of the measure group in the attribute tree. For more infor-
mation about related attributes, see Chapter 7.

So, before it can build indexes, Analysis Services has to first decode attributes for which it
needs to build the indexes from all the granularity attributes included in the measure
group. To do this, Analysis Services iterates through the dimensions related to the measure
group and finds the decoding table that enables the server to decode the maximum
number of attributes from the granularity attribute. If one decoding table doesn't cover all
the needed attributes, Analysis Services will use more than one decoding table.

After Analysis Services finds a decoding table it can use, it extracts the DataID of the gran-
ularity attribute from the partition record and uses this DataID to find the DataID s of
members from the attributes related to the granularity attribute. For example, when
Analysis Services builds indexes for the partition of the Sales measure group from our
Warehouse and Sales cube, it takes the DataID of the member from the Date attribute and
uses one of the decoding tables from the Time dimension to decode members on Month ,
Quarter , and Year attributes.