Databases Reference
In-Depth Information
Partition Slice
Analysis Services uses the partition slice to decide quickly whether the partition holds the
data requested by the user. Typically, the user defines the partition slice. A partition slice is
defined by specifying a MDX expression that resolves to a single tuple. (For more informa-
tion about tuples, refer to Chapter 10, “MDX Concepts.”) For example, if the partition
contains only data about sales in December 1998, you can use the following MDX expres-
sion to define the partition slice: [Time].[Time].[Month].&[12]&[1998] . Note that you
can specify the slice that has only one member per attribute; so, for example, you cannot
define a slice that will have both December and November members. However, you can slice
by members of multiple attributes; for example, you can slice the data by December and
Seattle .
To exclude partitions that don't contain data requested by the user during the query,
Analysis Services builds a special data structure called a subcube, which represents the
multidimensional space occupied by the data of the partition. To check whether requested
data exists in the partition, Analysis Services then determines whether the subcube repre-
sented by the partition intersects with the subcube represented by the query request.
When Analysis Services builds indexes for the partition, it analyzes the slice defined by a
user and then redefines the slice for each attribute by detecting sequential range of
DataID s of members that have data in the partition. For example, if a partition contains
data from January to March, Analysis Services detects the range of members from the
Month attribute as [1:3] .
If the starting and ending point of the detected range correspond to the same member,
Analysis Services uses this member to define the partition slice. If there is more than one
member in the detected range, the range cannot be used as a slice (because a partition
slice must always resolve to a single tuple), but the range can still be used when creating
a query plan for partition scanning. For more information about query plans, see
Chapter 30, “Architecture of Query Execution—Retrieving Data from Storage.”
Partition Data
Data for the partition is loaded from the underlying data source. We discuss how Analysis
Services processes the data in Chapter 21, “Dimension and Partition Processing,” but in
this chapter, we describe the data structures that Analysis Services uses to contain the data
after processing. Partitions are stored in the map store, described earlier in this chapter.
Analysis Services uses the map store data structure to store both the attribute relationships
for a dimension and the data for a partition. The main difference between a map store
containing attribute relationships and a map store containing partition data is that the
record structure of a map store containing partition data contains both the key (the
DataID of the members corresponding to the granularity attribute) and the data values of
the measures contained in the partition. Actually, we called the DataID property DataID
because it associates data stored in the measure group with members of the dimension
corresponding to this data.
Values for the measures in the partition are stored in the format appropriate to their data
type. Because it is possible for a measure to contain NULL values, Analysis Services has to
store a null bit if the corresponding measure is marked as nullable ( NullProcessing prop-
Search WWH ::




Custom Search