Ordre de calcul des cellules
L'ordre dans lequel Essbase calcule les cellules de chaque bloc de données dépend de la façon dont vous avez configuré la base de données.
Chaque bloc de données contient toutes les valeurs de membre de dimension dense pour sa combinaison unique de membres de dimension dispersée. Chaque valeur de données est contenue dans une cellule du bloc.
La configuration de la base de données détermine l'ordre de calcul des membres de dimension dense au sein de chaque bloc, ainsi que l'ordre de calcul des blocs qui représentent les membres de dimension dispersée.
Reportez-vous aux exemples suivants :
Ordre de calcul des cellules : Exemple 1
Dans cet exemple, qui est le cas le plus simple, ces conditions sont vraies :
-
Aucune dimension n'a de balises de temps ou de compte.
-
Le paramètre de consolidation des valeurs #MISSING est activé.
-
Les dimensions Market et Year sont denses.
Essbase calcule les dimensions denses dans l'ordre dans lequel elles sont définies dans l'outline de base de données. Supposons que la dimension Year soit positionnée dans l'outline de la base de données avant la dimension Market et qu'elle soit calculée en premier.
La grille suivante présente une tranche (sous-ensemble des cellules d'un bloc de données). Dans la grille, l'ordre de calcul des cellules de la tranche est représenté par les nombres 1 à 6.
Tableau 19-3 Ordre de calcul Exemple 1 : Cellules d'entrée et cellules calculées
| Année-marché | New York | Massachusetts | East |
|---|---|---|---|
| Jan | 112 345 | 68 754 | 3 |
| Feb | 135 788 | 75 643 | 4 |
| Mar | 112 234 | 93 456 | 5 |
| Qtr1 | 1 | 2 | 6 |
Les valeurs de données ont été chargées dans les cellules d'entrée suivantes :
-
Jan -> New York
-
fév -> New York
-
Mar -> New York
-
Jan -> Massachusetts
-
fév -> Massachusetts
-
Mar -> Massachusetts
Essbase calcule les cellules dans l'ordre suivant.
-
Qtr1 -> New York
-
Qtr1 -> Massachusetts
-
Jan -> Est
-
Fév -> Est
-
Mar -> Est
-
Trim1 -> Est
Qtr1 -> Est a plusieurs chemins de consolidation ; il peut être consolidé sur le marché ou sur l'année. Lorsqu'il est consolidé sur Market, il s'agit d'une consolidation de Qtr1 -> New York et Qtr1 -> Massachusetts. Une fois consolidé sur l'année, il s'agit d'une consolidation de Jan -> Est, Fév -> Est et Mar -> Est.
Essbase sait que Qtr1 -> East possède plusieurs chemins de consolidation. Par conséquent, il ne calcule Qtr1 -> East qu'une seule fois en consolidant les valeurs de Qtr1 et utilise le chemin de consolidation de la dimension calculée en dernier (dans cet exemple, la dimension Market), comme indiqué ci-dessous.
Tableau 19-4 Ordre de calcul Exemple 1 : Résultats
| Année-marché | New York | Massachusetts | East |
|---|---|---|---|
| Jan | 112 345 | 68 754 | 181 099 |
| Feb | 135 788 | 75 643 | 211 431 |
| Mar | 112 234 | 93 456 | 205 690 |
| Qtr1 | 360 367 | 237 853 | 598 220 |
En fonction de l'ordre de calcul, si vous placez une formule de membre sur Qtr1, Essbase l'ignore lors du calcul de Qtr1 -> East. Si vous placez une formule de membre sur East, celle-ci est calculée lorsque Essbase consolide Qtr1 -> East sur Market.
Si nécessaire, vous pouvez utiliser un script de calcul pour calculer les dimensions dans l'ordre de votre choix.
Ordre de calcul des cellules : Exemple 2
Dans cet exemple, les conditions suivantes sont vraies :
-
Aucune dimension n'a de balises de temps ou de compte.
-
Le paramètre de consolidation des valeurs #MISSING est désactivé (valeur par défaut).
-
Les dimensions Market et Year sont denses.
Essbase calcule les dimensions denses dans l'ordre dans lequel elles sont définies dans l'outline de base de données. Supposons que la dimension Year soit positionnée dans l'outline de la base de données avant la dimension Market et qu'elle soit calculée en premier.
La grille suivante présente une tranche (sous-ensemble des cellules d'un bloc de données). Dans la grille, l'ordre de calcul des cellules de la tranche est représenté par les nombres 1 à 7.
Tableau 19-5 Exemple d'ordre de calcul 2 : Cellules d'entrée et cellules calculées
| Année-marché | New York | Massachusetts | East |
|---|---|---|---|
| Jan | 112 345 | 68 754 | 4 |
| Feb | 135 788 | 75 643 | 5 |
| Mar | 112 234 | 93 456 | 6 |
| Qtr1 | 1 | 2 | 3/7 |
Les valeurs de données ont été chargées dans les cellules d'entrée suivantes :
-
Jan -> New York
-
fév -> New York
-
Mar -> New York
-
Jan -> Massachusetts
-
fév -> Massachusetts
-
Mar -> Massachusetts
Essbase calcule les cellules Qtr1 pour les cellules New York, Massachusetts et East et les cellules East pour Jan, Feb et March.
-
Qtr1 -> New York
-
Qtr1 -> Massachusetts
-
Trim1 -> Est
-
Jan -> Est
-
Fév -> Est
-
Mar -> Est
-
Trim1 -> Est
Qtr1 -> Est est calculé sur les chemins de consolidation Année et Marché. Tout d'abord, Qtr1 -> East est calculé comme une consolidation de Qtr1 -> New York et Qtr1 -> Massachusetts. Deuxièmement, Qtr1 -> East est calculé comme une consolidation de Jan -> East, Feb -> East et Mar -> East.
Les résultats sont identiques aux résultats par example 1. Cependant, Qtr1 -> Est a été calculé deux fois. Ce fait est important lorsque vous devez charger des données au niveau parent.
En fonction de l'ordre de calcul, si vous placez une formule de membre sur Qtr1, son résultat est écrasé lorsque Essbase consolide Qtr1 -> East sur Market. Si vous placez une formule de membre sur East, le résultat est conservé car Market est calculé en dernier.
Tableau 19-6 Ordre de calcul Exemple 2 : Résultats
| Année-marché | New York | Massachusetts | East |
|---|---|---|---|
| Jan | 112 345 | 68 754 | 181 099 |
| Feb | 135 788 | 75 643 | 211 431 |
| Mar | 112 234 | 93 456 | 205 690 |
| Qtr1 | 360 367 | 237 853 | 598 220 |
Ordre de calcul des cellules : Exemple 3
Dans cet exemple, prenons une tranche de données d'une dimension dense stockée. La configuration de la base de données détermine que l'ordre des dimensions définit l'ordre de calcul. Il existe deux chemins de consolidation par lesquels les blocs seront calculés.
Dans cet exemple, les conditions suivantes sont vraies :
-
Aucune dimension n'a de balises de temps ou de compte.
-
Le paramètre de consolidation des valeurs #MISSING est désactivé (valeur par défaut).
-
Les valeurs de données ont été chargées aux niveaux parent.
-
Les dimensions Market et Year sont denses.
Essbase calcule les dimensions denses dans l'ordre dans lequel elles sont définies dans l'outline de base de données. Supposons que la dimension Year soit positionnée dans l'outline de la base de données avant la dimension Market et qu'elle soit calculée en premier.
La grille suivante présente une tranche (sous-ensemble des cellules d'un bloc de données) à calculer.
Tableau 19-7 Exemple d'ordre de calcul 3 : Cellules d'entrée et valeurs #MISSING
| Année-marché | New York | Massachusetts | East |
|---|---|---|---|
| Jan | #MANQUANT | #MANQUANT | 181 099 |
| Feb | #MANQUANT | #MANQUANT | 211 431 |
| Mar | #MANQUANT | #MANQUANT | 205 690 |
| Qtr1 | #MANQUANT | #MANQUANT |
Les cellules sont calculées dans le même ordre que dans Ordre de calcul des cellules : Exemple 2. Qtr1 -> Est est calculé sur les chemins de consolidation Année et Marché.
Comme le paramètre de consolidation des valeurs #MISSING est désactivé, Essbase ne consolide pas les valeurs #MISSING. Ainsi, les données chargées aux niveaux parent ne sont pas écrasées par les valeurs #MISSING en dessous.
Toutefois, si l'une des valeurs de données enfant n'est pas #MISSING, ces valeurs sont consolidées et remplacent les valeurs parent. Par exemple, si Jan -> New York contient 50000.00, cette valeur remplace les valeurs chargées aux niveaux parent.
Essbase doit calculer la cellule Qtr1 -> East deux fois pour s'assurer qu'une valeur est calculée pour la cellule. Si Qtr1 -> East est calculé en fonction du dernier chemin de consolidation, le résultat est #MISSING, ce qui n'est pas le résultat requis.
Les résultats montrent qu'Essbase calcule d'abord correctement la cellule Qtr1 -> East en consolidant Jan -> East, Feb -> East et Mar -> East, puis en effectuant le calcul sur le chemin de consolidation Market. Cependant, il ne consolide pas les valeurs #MISSING dans Qtr1 -> New York et Qtr1 -> Massachusetts ; par conséquent, la valeur dans Qtr1 -> East n'est pas écrasée.
Tableau 19-8 Ordre de calcul Exemple 3 : Résultats
| Année-marché | New York | Massachusetts | East |
|---|---|---|---|
| Jan | #MANQUANT | #MANQUANT | 181 099 |
| Feb | #MANQUANT | #MANQUANT | 211 431 |
| Mar | #MANQUANT | #MANQUANT | 205 690 |
| Qtr1 | #MANQUANT | #MANQUANT | 598 220 |
Ordre de calcul des cellules : Exemple 4
Dans cet exemple, prenons une tranche de données dans une dimension stockée. La configuration de la base de données détermine l'ordre dans lequel les blocs seront calculés.
Dans cet exemple, les conditions suivantes sont vraies :
-
La dimension Year est marquée Time.
-
La dimension Measures est marquée Accounts.
Essbase calcule d'abord une dimension marquée comme Comptes, puis une dimension marquée comme Temps. Par conséquent, dans cet exemple, Measures est calculé avant Year.
-
Le paramètre de consolidation des valeurs #MISSING est désactivé (valeur par défaut).
-
Les valeurs Marketing, Payroll et Misc Expenses ont été chargées au niveau des trimestres (niveau 1).
L'image ci-dessous illustre la branche Profit de la dimension Measures dans la base de données Sample Basic. Cet exemple suppose que Total Expenses est stocké (et non un membre de calcul dynamique).
Figure 19-9 Direction générale des bénéfices de la dimension Mesures

Etant donné qu'il n'existe aucune formule et que #MISSING ne se consolide pas, les valeurs de niveau supérieur ne sont pas écrasées. Les valeurs de données avec deux chemins de consolidation (mesures autres que de niveau 0) sont calculées deux fois.
La grille suivante présente une tranche (sous-ensemble des cellules d'un bloc de données). Dans la grille, l'ordre de calcul des cellules de la tranche est représenté par les nombres 1 à 17.
Tableau 19-9 Exemple d'ordre de calcul 4 : Cellules d'entrée, valeurs #MISSING et cellules calculées
| Mesures/Année | Jan | Feb | Mar | Qtr1 |
|---|---|---|---|---|
| Sales | 31 538 | 32 069 | 32 213 | 13 |
| COGS | 14 160 | 14307 | 14 410 | 14 |
| Marge | 1 | 4 | 7 | 10/15 |
| Marketing | #MANQUANT | #MANQUANT | #MANQUANT | 15 839 |
| Payroll | #MANQUANT | #MANQUANT | #MANQUANT | 12 168 |
| Divers | #MANQUANT | #MANQUANT | #MANQUANT | 233 |
| Total des dépenses | 2 | 5 | 8 | 11/16 |
| Profit | 3 | 6 | 9 | 12/17 |
Les cellules suivantes ont plusieurs chemins de consolidation :
-
Marge -> Trim1
-
Total des dépenses -> Trimestre1
-
Bénéfice -> Trim1
Comme le paramètre de consolidation des valeurs #MISSING est désactivé, Essbase ne consolide pas les valeurs #MISSING. Les données chargées aux niveaux parent ne sont pas écrasées par les valeurs #MISSING, et Essbase calcule les cellules avec plusieurs chemins de consolidation deux fois.
En fonction de l'ordre de calcul, si vous placez une formule sur Margin, son résultat sera écrasé par la consolidation sur Qtr1.
Les résultats sont présentés ci-dessous :
Tableau 19-10 Exemple d'ordre de calcul 4 : Résultats
| Mesures/Année | Jan | Feb | Mar | Qtr1 |
|---|---|---|---|---|
| Sales | 31 538 | 32 069 | 32 213 | 95 820 |
| COGS | 14 160 | 14307 | 14 410 | 42 877 |
| Marge | 17 378 | 17 762 | 17 803 | 52 943 |
| Marketing | #MANQUANT | #MANQUANT | #MANQUANT | 15 839 |
| Payroll | #MANQUANT | #MANQUANT | #MANQUANT | 12 168 |
| Divers | #MANQUANT | #MANQUANT | #MANQUANT | 233 |
| Total des dépenses | 28 240 | |||
| Profit | 17 378 | 17 762 | 17 803 | 12/17 |
Ordre de calcul des cellules pour les formules d'une dimension dense
Lorsque vous placez une formule sur un membre de dimension dense, tenez compte de l'ordre de calcul des cellules. Comme illustré dans les exemples précédents, la dimension calculée en dernier remplace les calculs de cellule précédents pour les cellules ayant plusieurs chemins de consolidation.
L'ordre de calcul des cellules dans un bloc de données n'est pas affecté par les formules des membres. Lorsque Essbase rencontre une formule dans un bloc de données, il verrouille tous les autres blocs de données requis, calcule la formule et procède au calcul du bloc de données.
Si nécessaire, vous pouvez utiliser un script de calcul pour modifier l'ordre dans lequel les dimensions sont calculées. Reportez-vous à Développement de scripts de calcul pour les cubes en mode "block storage" et à Développement de formules pour les cubes en mode "block storage".