[BO6.5] - Requêtes et Cube

[samovich]

J'ai fait une requête qui s'appelle distribution.

J'ai voulu ajouté un élément d'une autre classe à ma requête et en l'exécutant j'ai trouvé deux requêtes dans le cube : distribution.Cube1 et distribution.Cube2 , je n'ai jamais vu ça car j'ai d'autres requêtes avec des objets et indicateurs de différents classes sans que ce problème se pose.

Quelqu'un a une explication?

[samovich]

Personne ne reconnaît ce problème!!!!!!

Faut il pas croiser des objets de différents classes???????????

[jj bzh]

les objets que tu as sélectionné dans différentes classes sont incompatibles.
soit c'est volontaire et le designor a marqué ces objets explicitement comme incompatibles soit il s'agit d'une erreur de conception de l'univers.

dans tous les cas, quand des objets sont incompatibles il y a création de 2 requetes .

par exemple on peut avoir des contrats avec 0 ou n livraison
et des livraisons avec 0 ou n contrat.
et dans une requete on demande le nombre de contrat et le nombre de livraison.
si on lance une requete et que le nombre de contrats et le nombre de livraison sont compatibles , on n'obtient que les contrats qui ont des livraisons.
s'ils sont mis incompatibles , BO lance 2 requetes parallèles et on obtient le nombre de contrat (avec ou sans livraison) et le nombre de livraison (avec ou sans contrat)

[samovich]

Je te remercie beaucoup pour ce retour.

Mais comment pourrais je savoir que des éléments dans mon univers sont incompatibles?
J'ai fait un test d'integrité qui a réussi. Dans Oracle, je fait la requête sans problème.
Est ce que exemple je peux utiliser directment cette requête SQL dans BO? et comment?

[dsoexo7]

Dans ta 1ère requête, tu devais avoir un objet de type indicateur (nombre, montant, un numérique quoi.....). L'objet que tu as ajouté dans ta requète doit-être également du type indicateur. Si au niveau de designer, les tables sont jointes, BO créé automatiquement 2 requêtes.
Les résultats sont souvent faux. Pour solutionner cela, garde ta 1ère requète telle qu'elle était (avant l'ajout du ton objet), créé une nouvelle requète à partir de ctte dernière, enlève l'objet de type indicateur déjà existant et ajoute le nouveau. Normalement ça doit marcher

[samovich]

Non je n'ai pas d'indicateur, je n'ai que des objets de type dimension.
Je suis en train d'essayer la navigation aggrégée mais je ne sais pas comment ça marche. Il faut créer des tables aggrégées en utilisant la fonct @aggregate_aware.
Est ce qu'elle peut être une piste l'aggrégation????

[BzhCH]

Je ne suis pas certain que ce soir la bonne explication car dans le cas que tu expliques, jjbzh, BO génère un seul cube à partir des 2 requêtes (synchronisation).
Ici il s'agit plutôt de l'utilisation de 2 contextes sans qu'il y ait d'indicateur (ce qui semble être le cas). Les résultats sont bien sûr faux à 90%.
Il faut voir si les contextes sont correctement définis ou si certaines tables n'ont pas été ajoutées sans être incorporées dans les contextes existants.

[Bruno2r]

Envoyé par samovich

Je te remercie beaucoup pour ce retour.

Mais comment pourrais je savoir que des éléments dans mon univers sont incompatibles?
J'ai fait un test d'integrité qui a réussi. Dans Oracle, je fait la requête sans problème.
Est ce que exemple je peux utiliser directment cette requête SQL dans BO? et comment?

Réponse bien sûr ! en SQL à la carte ... à condition :
que le supervisor t'ait accordé ce droit
que tu ais une connexion de définie vers cette base

Pour ce qui est de l'incompatibilité des objets :
C'est avant tout une méthode de gestion des contexte qui sont créés pour résoudre les boucles
Egalement ce qui permet le recours à la fonction @aggregate_aware
Cette dernière présente dans le sql de l'objet les différents champs de différentes tables qui peuvent ramener l'info désirée à des niveaux d'agrégation décroissants. L'utilisation n'a que peu d'intêret si il n'y a pas d'objet indicateur dans ta requête.
Une dernière précision les requêtes qui se traduisent par deux sql ... ne sont pas obligatoirelent fausses mais c'est vrai qu'elles peuvent l'être.
Ce qui est certain c'est que trop de designer construisent les universs de type une table = une classe d'objet et que bien souvent ça ne correspond pas aux besoins de l'utilisateur qui veut croiser des données pour analyse.