{scrollbar}

----
One of the most important characteristics of the O3 cubes is the possibility to handle hierarchies for the dimensions. The hierarchies allow the user to analyze the information not only from different perspectives (dimensions) but also for different levels of detail.

In the definition of a cube's model the hierarchies related to each one of its dimensions are defined, specifying the possible levels of the detail that the user will be able to query.
For a Date dimension, for example, Year, Quarter, Month and Week levels can be defined, so the user will be able to analyze the information on any of this cube levels.

It is important to consider that the information obtained from the sources to build a cube is always given for a particular level (base or entry level) in each one of the dimensions and it is stored in this way. Therefore, each information record that is stored in the cube is stored for the base level of each one of the dimensions that form the cube. In the example of the Date dimension this level could be Week.

Each time a user queries a level above the entry level for one or more dimensions (Year, Quarter or Month in the example), O3 makes the aggregation to solve the query (through the aggregation operation defined for the queried measure) from the entry level or database in each one of the dimensions (Week for the example). Depending on the number of records managed by the cube, the aggregation operations can involve great numbers of records, and can also slow down the answering times for certain queries.

The redundancy is the mechanism that makes it possible to include information previously calculated at the time the query is made (when the cube is built, for example) for aggregation levels above the base or entry levels.

This way, if the user queries a level for with a redundancy has been included (redundancy level) it will not be necessary to make any aggregation as the calculation will be done and stored in the cube, making the answering times more agile.

On the other hand, if queries are made above a precalculated level, O3 will use these levels for the aggregation instead of the base level records.

This way, all the redundancy levels included not only benefit from the specific level, but also from the superior ones.

As the redundancy consists of information precalculated that is stored as part of the cube, the user should note that its inclusion will affect the final size of the cube. Therefore, the amount of redundancy included in a cube should be carefully controlled so as to prevent it from taking up too much space.

The task of defining the redundancy appropriately consists of reaching a balance between the extra space occupied by the cube as a consequence of the redundancy and the benefit that it brings to the queries' answering times. In most cases, a few redundancy levels carefully selected is enough for a great improvement in the answering time and with little additional storing space.

h1. Definition of Redundancy

A cube's redundancy is the selection of the levels for the dimensions in which the values will be precalculated. The redundancy in a cube will be defined by a set of
\\

h1. Redundancy Levels

A redundancy level should specify a level for each one of the cube's dimensions. The data corresponding to the combination of levels specified will be precalculated in the cube.
If when querying the cube the user is in the redundancy level for each dimension, the data will be precalculated and it will not be necessary to make any calculations to answer the query.
Besides, if in one of more dimensions the user is above the redundancy level, it can be used for the calculation by reducing the number of records and therefore the answering time.

h3. Example

Let's take a cube like the following:
\\
| Dimension | Number of Levels |
| Dimension1 | 4 |
| Dimension2 | 3 |
| Dimension3 | 2 |
| Dimension4 | 3 |
\\
These are examples of redundancy levels:
(3, 2, 1, 2)
(3, 1, 1, 1)
(2, 2, 1, 2)
\\
*Notes*
* For the definition of a redundancy the levels of each dimension are numbered in ascending order, being 0 the lowest level in the hierarchy.

In order to evaluate the impact a redundancy level can have in a cube, the user has to consider that each redundancy level will generate new records in the cube.
As a rule, the higher the levels forming the redundancy level, the lower will be the number of generated new records.
See The Redundancy Tab in the Cube Property Pane.
\\

----
{scrollbar}
{children}