Exemples de croisements valides

Cette section fournit des exemples de règle de croisement valide et de groupe de croisements valides pour illustrer quelques scénarios simples, complexes et extrêmes.

Exemple : dimensions d'ancrage et de non-ancrage

Le choix de la dimension d'ancrage est essentiel. Examinez l'exemple suivant, qui donne un résultat différent en fonction de la définition de la dimension d'ancrage :

• Le groupe de croisements valides 1 définit Entité comme dimension d'ancrage et Produit comme dimension de non-ancrage.

• Le groupe de croisements valides 2, à l'inverse, définit Produit comme dimension d'ancrage et Entité comme dimension de non-ancrage.

Dans le groupe 1, les entités étant des descendants de Fabrication ne sont valides que si leurs produits sont des descendants d'Equipement informatique. Aucun autre produit n'est valide avec des descendants de Fabrication. Toutes les entités autres que les descendants de Fabrication sont valides avec tous les produits, y compris les descendants d'Equipement informatique.

Dans le groupe 2, les produits étant des descendants d'Equipement informatique ne sont valides que si leurs entités sont des descendants de Fabrication. Aucune autre entité n'est valide avec des descendants d'Equipement informatique. Tous les produits autres que les descendants d'Equipement informatique sont valides avec toutes les entités, y compris les descendants de Fabrication.

Exemple : dimension obligatoire

Dans l'exemple suivant, si aucune dimension de non-ancrage n'est requise, l'application évalue tous les croisements de dimensions restants du groupe de croisements valides pour un cube qui ne contient pas la dimension facultative. Ce comportement peut entraîner l'évaluation d'un groupe de croisements valides doté d'une seule dimension en vigueur.

Dans le groupe 1, la dimension Produit n'est pas requise, et les entités non sélectionnées sont valides. Par conséquent, à l'exécution, si le cube du formulaire ou de la règle métier n'inclut pas la dimension Produit, l'application évalue les sélections de la dimension Entité et marque toutes les entités comme valides pour un cube ne contenant pas la dimension Produit.

Dans le groupe 2, la dimension Produit n'est pas requise, et les entités non sélectionnées ne sont pas valides. Par conséquent, à l'exécution, si un cube n'inclut pas la dimension Produit, l'application évalue les sélections de la dimension Entité et marque toutes les entités comme non valides, sauf les descendants de Fabrication. Ensuite, tout cube qui n'utilise pas la dimension Produit autorise uniquement la saisie de données dans les descendants des entités Fabrication.

Exemple : les membres non sélectionnés sont valides

Dans l'exemple suivant, deux groupes de croisements sont valides. Dans un groupe, les membres non sélectionnés de la dimension d'ancrage ne sont pas valides (cette option est désactivée). Dans l'autre groupe, les membres non sélectionnés de la dimension d'ancrage sont valides (cette option est activée).

Etant donné que le groupe 1 définit tous les membres non sélectionnés comme étant non valides, l'application marque les descendants non inclusifs de Bilan comme non valides. Bénéfice brut n'est pas un descendant inclusif de Bilan. Ainsi, même si le groupe 2 spécifie explicitement que les descendants non inclusifs de Bénéfice brut sont valides avec les descendants inclusifs des entités Ventes, le caractère non valide défini dans le groupe 1 prévaut sur les autres croisements valides du même ensemble de membres de la dimension d'ancrage.

Exemple : règles de croisement valide redondantes ou se chevauchant dans le même groupe de croisements valides

Lorsque des règles de croisement valide sont incluses dans le même groupe de croisements valides, et qu'elles sont redondantes ou se chevauchent, le système marque un croisement comme étant valide s'il respecte au moins une condition de règle de croisement valide.

Comme Bénéfice brut est un descendant de Résultat net et que Ventes est un descendant de Total du service, les descendants inclusifs de Bénéfice brut sont valides avec tout descendant inclusif de Total du service. La règle 1 est un sous-ensemble de la règle 2. La règle 1 est donc effectivement une règle de type "Aucune opération" et ne sert à rien. Il n'existe pas de restriction selon laquelle les descendants inclusifs des comptes de Bénéfice brut ne sont valides que pour les descendants inclusifs des entités Ventes.

Exemple : règles de croisement valide redondantes ou se chevauchant dans différents groupes de croisements valides

Lorsque des règles de croisement valide sont incluses dans différents groupes de croisements valides, et qu'elles sont redondantes ou se chevauchent, le système marque un croisement comme étant valide s'il respecte les critères de tous les groupes de croisements valides.

Dans l'exemple suivant, il existe des règles redondantes ou qui se chevauchent dans différents groupes :

Dans la mesure où le groupe 1 est encore plus restrictif pour les descendants inclusifs des comptes Bénéfice brut valides avec les descendants inclusifs des entités Ventes, l'application impose ce groupe à ces croisements. Les autres comptes (ceux qui ne sont pas des descendants de Bénéfice brut) peuvent quand même utiliser tous les descendants des entités Total du service, mais les descendants inclusifs des comptes Bénéfice brut doivent utiliser des descendants inclusifs des entités Ventes.