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.
Tableau 13-1 Exemple : la dimension d'ancrage est Entité
Groupe de croisements valides | Dimension d'ancrage : Entité | Dimension de non-ancrage : Produit |
---|---|---|
1 | DESC(500 - Fabrication) - Les membres non sélectionnés sont valides. | DESC(P_TP1 - Equipement informatique) |
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.
Tableau 13-2 Exemple : la dimension d'ancrage est Produit
Groupe de croisements valides | Dimension d'ancrage : Produit | Dimension de non-ancrage : Entité |
---|---|---|
2 | DESC(P_TP1 - Equipement informatique) - Les membres non sélectionnés sont valides | DESC(500 - Fabrication) |
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.
Prudence :
Le choix de la dimension d'ancrage est important. Vous obtiendrez des résultats totalement différents si vous choisissez la mauvaise dimension d'ancrage.
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.
Tableau 13-3 Exemple : dimensions de non-ancrage obligatoires ou facultatives
Groupe de croisements valides | Dimension d'ancrage : Entité | Dimension de non-ancrage : Produit |
---|---|---|
1 | DESC(500 - Fabrication) - Les membres non sélectionnés sont valides. | DESC(P_TP1 - Equipement informatique) - Facultatif. |
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.
Tableau 13-4 Exemple : dimensions de non-ancrage obligatoires ou facultatives
Groupe de croisements valides | Dimension d'ancrage : Entité | Dimension de non-ancrage : Produit |
---|---|---|
2 | DESC(500 - Fabrication) - Les membres non sélectionnés ne sont pas valides. | DESC(P_TP1 - Equipement informatique) - Facultatif. |
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.
Prudence :
Examinez attentivement la nécessité d'une dimension de non-ancrage, en particulier s'il en résulte un groupe de croisements valides avec une seule dimension en vigueur. Par ailleurs, la sélection de l'option Les membres non sélectionnés sont valides pour les membres de la dimension d'ancrage joue un rôle important dans le comportement du système en ce qui concerne les croisements valides. Reportez-vous à Exemples de croisements valides.
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).
Tableau 13-5 Exemple : les membres non sélectionnés sont valides
Groupe de croisements valides | Dimension d'ancrage : Compte | Dimension de non-ancrage : Entité |
---|---|---|
1 | IDESC(BS - Bilan) - Les membres non sélectionnés ne sont pas valides. | 000 - Aucun service |
2 | IDESC(GP - Bénéfice brut) - Les membres non sélectionnés sont valides. | IDESC(403 - Ventes) |
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.
Tableau 13-6 Exemple : règles de croisement valide redondantes ou se chevauchant dans le même groupe de croisements valides
Règle de croisement valide | Dimension d'ancrage : Compte | Dimension de non-ancrage : Entité |
---|---|---|
1 | IDESC(GP - Bénéfice brut) - Les membres non sélectionnés sont valides. | IDESC(403 - Ventes) |
2 | IDESC(NI - Résultat net) - Les membres non sélectionnés sont valides | IDESC(TD - Total du service) |
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 :
Tableau 13-7 Exemple : règles de croisement valide redondantes ou se chevauchant dans différents groupes de croisements valides
Groupe de croisements valides | Dimension d'ancrage : Compte | Dimension de non-ancrage : Entité |
---|---|---|
1 | IDESC(GP - Bénéfice brut) - Les membres non sélectionnés sont valides. | IDESC(403 - Ventes) - Obligatoire |
2 | IDESC(NI - Résultat net) - Les membres non sélectionnés sont valides | IDESC(TD - Total du service) - Facultatif |
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.