Discussion :

[EmmanuelleC]

Bonjour,

En essayant de remettre au propre des notes consécutive a une formation en designer je réalise que j'ai mal noté (ou pas pensé a demander plus d'explication sur le coup :p) quelque chose concernant l'onglet SQL dans les parametre d'univers



J'ai retenu qu'il vaut mieux ne pas cocher "plusieurs instructions SQL pour chaque indicateurs" parce que ca plombe les performances et qu'il y a des meilleurs solutions pour éviter les chasm traps

J'ai retenu qu'il vaut en général mieux ne pas authoriser de sélectionner plusieurs contextes en meme temps parce que les utilisateurs vont avoir du mal a utiliser l'otpion avec discernement et que ca a de fortes chances de produires des rapports pleins de données incorectes

J'ai noté qu'il vallait mieux cocher "plusieurs instructions SQL pour chaque contexte" mais j'ai omi de noter pourquoi
Et quand je cherche dans la documentation BO, je n'arrive pas a remettre la main sur l'explication

Est-ce que quelqu'un ici sait ce que ca change?
Dans quel cas ca génère plusieurs instructions SQL?
Dans quel cas ca pose probleme si on ne l'a pas coché?

Merci beaucoup

[TomDuBouchon]

Bonjour Emmanuelle,

En fait cette option fonctionne de la même façon que "Plusieurs instructions SQL pour chaque indicateur".

En effet, si cette dernière est cochée, il y aura autant d'instructions SQL présentes qu'il y a d'indicateurs provenant de tables différentes. La jointure s'effectuant ensuite directement dans le cube dans BO.
Ex :

Table1
Dimension1
Dimension2
Indicateur1

Table2
Dimension1
Dimension3
Indicateur2

Résultat :
SQL 1:
Dimension 1, Dimension2, Dimension3, Indicateur 1
SQL 2:
Dimension 1, Dimension2, Dimension3, Indicateur 2
Le lien se fera ensuite dans le cube avec les correspondances entre les Dimension 1, Dimension2 et Dimension3 des deux "vues" obtenues.

Donc, idem pour les contextes. Il y aura autant d'instructions SQL qu'il y a d'éléments de tables de contextes différents.
Le but de la laisser cocher est justement de respecter "l'idée" du contexte. Normalement on crée des contextes car autrement certaines données obtenues seraient incohérentes ou inapplicables (boucles). Donc pour éviter de ne créer qu'une seule jointure qui pourrait changer complètement le sens de la requête, une instruction SQL est crée pour chaque contexte utilisé et les correspondances déterminées ensuite.

[EmmanuelleC]

Ok, merci

Meme si du coup, je me demande bien pourquoi ils ont mit l'option. Si sans ca les contextes ne fonctionnent pas, alors ca m'aurait semblé logique que l'option s'active automatiquement et sans qu'on puisse la désactiver

[TomDuBouchon]

En soi ça peut fonctionner mais être générateur d'erreurs.

Dans le cas d'une boucle, évidemment, la question ne se pose même pas ce n'est pas possible.

Par contre si on imagine le cas où deux contextes servent simplement à obtenir des données agrégées d'un côté et élémentaires de l'autre, ça peut fonctionner.
Mais un cas posant problème serait par exemple celui où une des jointures d'un contexte possède un filtre et l'autre non. Dans cas le fait de ne générer qu'une seule requête peut ne pas correspondre au résultat attendu.