Cubes are informational objects that identify measures with the exact same dimensions, and are candidates for being processed together at all stages: data loading, aggregation, storage, and querying. The Implementation Details tab determines how the data is stored physically.
Important: Run the Sparsity Advisor after mapping the cube to get recommendations for these choices.
Dimension Order and Sparsity
Select the sparse dimensions.
The dimension order is important for composites, but it has no effect on compressed composites. To order the dimensions, use the arrow keys to move the sparse dimensions down the list, after the dense dimensions. All dimensions that you have identified as sparse (by selecting the Sparse box) must be grouped together.
If you are not using the Sparsity Advisor, then use these basic guidelines:
List Time first to expedite data loading and time-based analysis. Time is often a dense dimension, although it may be sparse if the base level is Day or the cube has many dimensions.
For a regular composite, list the sparse dimensions in order from the one with the most members to the one with the least. For a compressed composite, list the sparse dimensions in order from the one with the least members to the one with the most.
If you are using the Sparsity Advisor, note that it does not optimize for data loading or time-based analysis. If you want to optimize for these tasks, then you may deviate from the recommendations and list Time first.
Use Global Composites
A choice between single (global) and multiple composites is available for uncompressed, partitioned cubes. This option defines a single composite for the cube instead of a composite for each partition. By using a global composite, you may be able to:
Eliminate redundancy among multiple composites and thereby lower the storage requirements.
Load the entire composite in memory for improved all-around performance.
A global composite may be a better choice under these circumstances:
The partitioned dimension is dense, and the sparsity patterns for the other dimensions are consistent across partitions.
The aggregated composite will not exceed the available memory (50 million or more values).
Regular composites are being used. Compressed cubes cannot use global composites.
The analytic workspace does not support multiwriter applications.
Note: A global composite does not allow parallel aggregation across partitions. If the analytic workspace has fewer cubes than available processes, then aggregating the partitions in parallel may improve build performance more than a global composite.
When in doubt, do not choose this option. The cube will have one composite for each partition.
An unpartitioned cube always has one composite for the cube, whether it is compressed or uncompressed. A partitioned, compressed cube always has a composite for each partition.
Use Compression
Select this option if the data in this cube is extremely sparse. Note that extreme sparsity is quite common.
Extreme sparsity often results from one or more of these factors:
A cube has a large number of dimensions (seven or more).
One dimension has more than 300,000 members.
Two dimensions have more than 100,000 members each.
Dimension hierarchies have numerous levels, with little change to the number of dimension members from one level to the next, so that many parents have only one descendant for several contiguous levels.
Compressed storage uses less space and results in faster aggregation than normal sparse storage for extremely sparse cubes.
Some aggregation operators are not compressible because their values can change for every level: all weighted operators, all scaled operators, and the Hierarchical Weighted Average operator. When these operators are used in a cube, the aggregation engine compresses the dimensions that it can, but it cannot compress the entire cube.
Data Type of Cube
For compressed storage, all measures in the cube must have the same data type. For regular storage, a data type is associated with each measure. Depending on your selection of a data type, you may set the following additional parameters:
Precision: The maximum number of significant decimal digits.
Scale: The number of digits from the decimal point to the least significant digit.
Size: The maximum length in bytes for text data types.
Partition Cube
Select this option to partition the cube. Partitioning improves the performance of large measures. A measure with 50 million composite tuples or more should be partitioned.
Dimension
Select the dimension for partitioning the cube. The dimension must have at least one level-based hierarchy and its members should be distributed evenly, such that every parent at a particular level has roughly the same number of children.
Time is usually the best choice because it meets these criterion. In addition, data is loaded and rolled off by time period, so that new partitions can be created and old partitions dropped as part of the data refresh process.
Hierarchy
Select the hierarchy to be used for partitioning. If the dimension has multiple hierarchies, choose the one that has the most members; it should be defined as the default hierarchy.
Level
Select the level to be used for partitioning. Each dimension member at that level is stored in a separate partition, along with its descendants. Any dimension members that are at higher levels or are not in the hierarchy are stored together in the default partition. The size of the default partition should not exceed the size of the level-based partitions.
Choose the level with care so that you do not create a surfeit of partitions. For example, if the Time dimension has 10 years of data at the year, quarter, month, and day levels, then you might partition at the quarter level. This choice creates 40 partitions, one for each quarter and its descendants (months and days). The 10 members at the year level are stored together in the default partition, and can be retrieved quickly for a top-level view of the data. However, if the data is very sparse, then you might partition at the year level.
The goal of partitioning is to create composites that fit in memory, which optimizes performance. The more memory you computer has, the larger the partitions can be and still achieve this goal.
Copyright © 2003, 2007, Oracle. All rights reserved.