{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.
\\
{anchor:_Toc94582633}{*}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 
\\
{anchor:_Toc94582634}{*}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.
 \\
{anchor:_Toc94582635}{*}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. 
\\
{anchor:_Toc94582636}{*}Redundancy Methods* 
In order to simplify the redundancy definition process, O3 offers a set of predefined redundancy methods. Each redundancy method defines a redundancy policy for the cube. Some methods are completely automatic, and other give more control to the designer. Apart from the predefined methods there is a manual method in which the designer can define the levels one by one.
The redundancy method is the first thing to select to define a redundancy in a cube. Depending on the method selected, in some cases it will be necessary to define some additional parameters.
The redundancy methods available are:
# (none) 
# Top Most
# Fixed Level 1
# Fixed Level 2
# Automatic
# Manual

{anchor:_Toc94582637}{*}a) (none)*
In this case no redundancy level is included in the cube. All the queries will be solved on the dimensions base level.
{anchor:_Toc94582638}{*}b) Top Most*
The Top Most method includes an only redundancy level in the superior level of all the dimension hierarchies. The format of the included level is the following:
(S1, S2, ..., SN)
where Si is the superior level of no. i dimension, and N is the number of dimensions in the cube.
This method is oriented to efficiently solve the queries on higher level in the cube. It may be useful to accelerate the opening of the initial view in a cube with many records.
{anchor:_Toc94582639}{*}c) Fixed Level 1*
The Fixed Level 1 method includes the Top Most level and an additional redundancy level with the following format:
(1, 1, ...., 1)
that is, a redundancy level for the level 1 in each one of the cube dimensions. If any of the dimensions doesn't have level 1 (it has only one level), the redundancy level will be ignored. If the dimensions have 2 levels, the Fixed Level 1 matches the Top Most.
{anchor:_Toc94582640}{*}d) Fixed Level 2*
The Fixed Level 2 method includes the Top Most level, the Fixed Level 1 and an additional redundancy level with the following format:
 (2,2, ... , 2)
that is a redundancy level for the level 2 in each one of the cube dimensions. If any dimension doesn't have level 2 (it has less than 3 levels), the redundancy level will be ignored. If all the dimensions have 3 levels, the Fixed Level 2 matches the Top Most.
{anchor:_Toc94582641}{*}e) Automatic*
The automatic method makes and analysis of the cube content and automatically decides the location of the redundancy levels through algorithms included in O3.
To make this decision the algorithms use an entry parameter that the designer has to give in section "Automatic Redundancy Configuration". The parameter is the maximum number of records that are to be scanned (and added) in the worst of cases to answer a query. This restriction in practice gives a time limit to answer any query. Based on this data and any additional data from the cube (number of levels in the hierarchies, number of elements in the levels and total number of records in the cube) the automatic algorithms will generate the redundancy levels necessary to comply with this rule.
Depending on the moment the automatic redundancy levels are generated, (See Phases) the algorithms can not know the total number of records the cube will have. If this is the case, the algorithm will be based on the information obtained in the stage of metadata generation (building of dimensions and their hierarchies) regarding the number of records in the cube and will base its decisions on this information.
On the other hand, the designer can indicate for this case through the "Estimate total nr. of tuples"  option, a total estimate of tuples in the cube, to be used instead of the estimate.
*Notes*
* The user has to consider that if the value of the maximum number of records to scan in a query is too low, this can cause the generation of too many redundancy levels and increase the size of the cube. Therefore, this redundancy method should be carefully used, controlling the parameter in particular. 

{anchor:_Toc94582642}{*}f) Manual*
In the manual method the designer has total control over the redundancy levels that will be included in the cube. The designer will have to define the levels one by one, indicating how each one of them is formed (the level for each dimension).
Once the Manual method is selected, the levels should be entered in the "Manual Redundancy Configuration" section through the Add Level button. Once a new level is added, the level number for each dimension should be specified.
 The manual method is more flexible that the others, as it permits to adjust the redundancy included in the cube to the reality of the data managed in the best way. On the other hand, it is the one that requires more knowledge from the designer about the redundancy mechanism and the data included in the cube.
{anchor:_Toc94582643}{*}Phases*
Given a set of redundancy levels generated by any of the previous methods, O3 organizes these levels in phases according to the dependencies among them. The objective of this organization is to make each level use as base level for its calculation the lowest level possible, and prevent all levels to be calculated on the base level.
Given a set of levels, O3 will make a plan composed by a set of phases each one of which will have the levels calculated on the same base level and will make the calculation for these phases.
\\
----
{scrollbar}
{children}