Discussion :

[alextoucour]

Bonjour,

Voilà mon problème:

Sur un même tableau, je dois mettre des informations provenant de pas mal de requêtes différentes (une dizaine).

Je fais requête1, ok.

Ensuite, je fais requête2 qui reprends des objects de la requête1 plus d'autres. BO reconnait qu'il y a certains objets communs dans ces deux requêtes et me les lie (me les synchronise) automatiquement. Sauf que je ne veux pas qu'ils soient liés donc je les délie.

Ensuite, quand je fais requete3 ou bien que je modifie l'une des requetes existantes, qu'est ce que me fait BO??? Et bien il me relie à nouveau tous les objets que j'avais déliés.

Avec une ou deux requêtes, ok ca va. Mais imaginez au bout de la dixième, ... et que vous devez tout refaire ...

Voilà quelqu'un a-t-il une idée? Y-a-il un paramétrage pour désactiver cette option en automatique?

Merci

[Bruno2r]

Bonjour,
Je ne connais pas de paramètre pour éviter la synchronisation automatique.
Je comprends que cela soit fastidieux si tu as 10 requêtes mais :

• pourquoi 10 requêtes ?

• pourquoi pas synchronisées (alors qu'elles utilisent bien les mêmes objets)

Enfin si vraiment tes requêtes sont bien conçues et nécessaires non synchronisées il ne te reste qu'à mettre au point les 10 et à délier les objets seulement après en une seule fois.

[alextoucour]

pourquoi 10 requêtes ?

Parce que mon client (exigeant) veut toutes ses données sur le même morceau de papier! Sinon

pourquoi pas synchronisées (alors qu'elles utilisent bien les mêmes objets)

Plusieurs raisons:
- la base de données (que j'ai réalisée) est de type transactionnel et donc certainement pas adapté à ce reporting. J'ai quelques connaissances théoriques sur le datawarehouse mais aucune pratique. Et seul et dans le délai, je ne pouvais pas faire plus.

- certaines requêtes me l'impose un peu. Exemple:

En vrai, disons qu'on a:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Ville          Nb magasins total      Nb de magasins visités
Paris         25                          14
Créteil       3                            2

Une premiere requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT ville, nom_magasin FROM magasin

La fonction "Nombre(<nom_magasin>)" dans le rapport me permet d'avoir la deuxième colonne

La deuxième requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT ville, nom_magasin, num_visite FROM visite 1, magasin 2
WHERE 1.num_magasin = 2.num_magasin

Ce qui me donne la troisième colonne.

Par contre si je mets tout dans un même tableau et que je laisse synchroniser ça me donne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Ville          Nb magasins total      Nb de magasins visités
Paris         14                          14
Créteil       2                            2

Enfin si vraiment tes requêtes sont bien conçues et nécessaires non synchronisées il ne te reste qu'à mettre au point les 10 et à délier les objets seulement après en une seule fois.

Je te déteste!!
C'est ce que je suis bien obligé de faire, mais parfois, soit j'ai oublié un truc, soit on m'en demande un nouveau, et là le fait de relancer n'importe quelle requête m'oblige à tout délier à nouveau.

Mais merci quand même!!

[Sergio63]

Bonjour,

Si tes requêtes ne sont pas trop complexes, tu peux les rédiger avec le SQL à la carte, il n'y aura pas de lien automatique.

Personnellement, je fonctionne comme ça pour tous les rapports un peu tordus.

L'univers c'est très bien pour les utilisateurs sans connaissances techniques ni de la base qui peuvent ainsi effectuer des rapports standards en toute autonomie.

Par contre dès que tu sors de ce contexte il apporte pas mal de contraintes qui limitent les possibilités.

Cordialement

Sergio

P.S. : je suis en v 5.1.8

[nevada_smith]

La seule possibilité à mon avis c'est de faire 10 copies de ton univers.

En effet, la synchro des objets est automatique s'ils sont issus du même univers mais en dehors de ça, il faut la faire manuellement.

Pour moi, c'est la seule solution à ton problème.

[Bruno2r]

Parce que mon client (exigeant) veut toutes ses données sur le même morceau de papier! Sinon

ça répond à pourquoi plusieurs tableaux pas à pourquoi plusieurs requêtes

Plusieurs raisons:
- la base de données (que j'ai réalisée) est de type transactionnel et donc certainement pas adapté à ce reporting. J'ai quelques connaissances théoriques sur le datawarehouse mais aucune pratique. Et seul et dans le délai, je ne pouvais pas faire plus.

- certaines requêtes me l'impose un peu. Exemple:

En vrai, disons qu'on a:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Ville          Nb magasins total      Nb de magasins visités
Paris         25                          14
Créteil       3                            2

Une premiere requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT ville, nom_magasin FROM magasin

La fonction "Nombre(<nom_magasin>)" dans le rapport me permet d'avoir la deuxième colonne

La deuxième requête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT ville, nom_magasin, num_visite FROM visite 1, magasin 2
WHERE 1.num_magasin = 2.num_magasin

Ce qui me donne la troisième colonne.

Par contre si je mets tout dans un même tableau et que je laisse synchroniser ça me donne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Ville          Nb magasins total      Nb de magasins visités
Paris         14                          14
Créteil       2                            2

Ton problème viens du fait que tu comptes dans BO
C'est dans l'univers que tu dois créer tes indicateurs :
Nb de magasins total

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select count(distinct magasin.nom_magasin)

Nb de magasins visités

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

count(distinct visite .num_visite)

Nb de magasins cambriolés ...

C'est ce que je suis bien obligé de faire, mais parfois, soit j'ai oublié un truc, soit on m'en demande un nouveau, et là le fait de relancer n'importe quelle requête m'oblige à tout délier à nouveau.

Enfin, pourquoi ne pas faire une table dérivée avec tous tes indicateurs ?
tu n'aurais que le SQL à corriger pour ajouter un indicateur.

En admettant que ta base soit Oracle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SELECT 'Nb de magasin total' as ITEM,
ville as VILLE,
null as MAGASIN,
count(distinct nom_magasin) as NB 
FROM magasin
GROUP BY ville
UNION 
SELECT 
'Nb de magasins visités', 
2.ville, 
2.nom_magasin, 
sum(decode(1.num_visite, null, 0, 1)) 
FROM visite 1, magasin 2
WHERE 2.num_magasin = 1.num_magasin(+)
GROUP BY 2.ville, 2.nom_magasin
UNION
SELECT
'autre item',
etc....

La jointure externe p et le choix de 2.num_magasin dans le select, associé au decode permet d'avoir le magasin avec nb de visite = 0 quand il n'y en a pas eu

[alextoucour]

ça répond à pourquoi plusieurs tableaux pas à pourquoi plusieurs requêtes

En fait, j'ai pris un exemple un peu comme ca de tête pour simplifier (magasin, ville, visite).
Ci-joint un exemple de tableau que je dois réaliser ... Et tout doit s'afficher sur un A4!!!!
Et les informations peuvent venir de tables très différentes sans aucun lien avec les autres (Je sais c'est mon modèle relationnel ... )

Ton problème viens du fait que tu comptes dans BO
C'est dans l'univers que tu dois créer tes indicateurs :
Nb de magasins total

Tu as tout à fait raison, je crois que c'est une grosse erreur de ma part. En comptant dans l'univers, je n'aurais pas à synchroniser sur des objets inutilement, juste sur les objets à afficher dans le tableau (dans mon exemple, la première colonne).

Enfin, pourquoi ne pas faire une table dérivée avec tous tes indicateurs ?
tu n'aurais que le SQL à corriger pour ajouter un indicateur.

Dans ce cas précis, je ne pense pas que je vais utiliser la table dérivée, car vu le nombre d'indicateurs, ça fait quand même une sacré table dérivée!! Et à maintenir ...
Donc je pense plutôt me tourner vers ta solution (au dessus) de retravailler mes requêtes et l'univers et en ne gardant que les objets vraiment utiles à synchroniser.

Merci!

[Bruno2r]

Alex,
J'ai regardé ton xls.
Je reste convaincu que (à défaut d'une procédure stockée dans la base) la table dérivée est idéale : 5 colonnes
Région
Délégué
Période
Item
et
union de 20 sql

que tu pourras enrichir si nécessaire

sinon
une requête 1 avec seulement
Région Délégué
sur laquelle tu synchronises les autres réduites au strict nécessaire (mieux en SQL)
Mais là tu vas y passer quelques nuits avant que ça marche surtout avec les mois mobile

[alextoucour]

Je reste convaincu que (à défaut d'une procédure stockée dans la base) la table dérivée est idéale : 5 colonnes

Ce qui m'embête avec la table dérivée c'est qu'elle ne servira qu'à ce rapport. Or il y en a une dizaine comme ça!
Et certains éléments doivent être repris mais avec d'autres objets en plus. Donc forcément refaire des tables dérivées différentes. Il y aura donc a priori une dizaine de tables dérivées et à priori assez complexes.
Tu me diras: "Et alors?" ... et c'est vrai que je n'ai pas d'autres arguments ...
En fait, je préfère peut-être voir les rapports se contruire petit à petit avec mes requêtes que devoir faire la table dérivée en premier ...
Je sais c'est assez abstrait ce que je dis

A méditer encore un peu pour moi!

une requête 1 avec seulement
Région Délégué
sur laquelle tu synchronises les autres réduites au strict nécessaire (mieux en SQL)
Mais là tu vas y passer quelques nuits avant que ça marche surtout avec les mois mobile

Oui plutôt cela, surtout que ca existe déjà. Mais comme tu dis, il faut que je retravaille les requêtes en gardant le minimum pour ne plus avoir ce problème de synchronisation.

[Bruno2r]

Alex tu es sur la bonne voie avec des réticences mais tu y viendras ...

Tes dizaines de tableaux dont certains reprennent certains de ces indicateurs ... justement et raison de plus pour te créer une table ou une vue (table dérivée) avec tout dedans
les tableaux seront simplissimes à faire si tu trouves une structure unique
du genre de celle que j'ébauchais

Tu peux commencer par mettre au point dans BO la requête d'un premier indicateur
Tu copies le SQL dans ta table dérivée en ajoutant Item et le résultat dans un champ NB
Tu fais la requête du second encore dans BO
Dans la table dérivée UNION 2ème SQL
et ainsi de suite

Bien sûr le critère doit être le temps d'exécution (à surveiller)

[alextoucour]

Merci encore tes conseils!

Et oui, je vais faire attention à la durée d'exécution! Les 5 à 10 minutes de silence lors de l'exécution et de la présentation au client des premières statistiques étaient ... plutôt gênantes!!

Question supplémentaire: est-ce que si je prends le SQL de cette table dérivée et que je fais un export des données puis un import dans une nouvelle table, cela peut s'apparenter à un datamart?
Le temps d'exécution sera certainement meilleur. Mais je ne sais pas comment gérer les problèmes liés à des changements de données dans cette éventuelle nouvelle table. Par exemple, si un délégué change que dois je faire? Si les données d'une dimension dans la base transactionnelle sont mises à jour ou supprimées?

Je sais que c'est ce genre de problèmatiques qui ont poussés à penser et à créer les datawarehouses, datamarts, infocentres, ... Mais je ne m'y connais pas assez.

Merci pour toute aide.

[Bruno2r]

Merci encore tes conseils!

Et oui, je vais faire attention à la durée d'exécution! Les 5 à 10 minutes de silence lors de l'exécution et de la présentation au client des premières statistiques étaient ... plutôt gênantes!!

ça va être difficile de faire plus lent

Question supplémentaire: est-ce que si je prends le SQL de cette table dérivée et que je fais un export des données puis un import dans une nouvelle table, cela peut s'apparenter à un datamart?

non ça s'apparente à une table d'indicateurs statistiques mais ce serait très intéressant pour garder un historique lorsque la structure de la base change

Le temps d'exécution sera certainement meilleur. Mais je ne sais pas comment gérer les problèmes liés à des changements de données dans cette éventuelle nouvelle table. Par exemple, si un délégué change que dois je faire? Si les données d'une dimension dans la base transactionnelle sont mises à jour ou supprimées?

le problème est le même dans le cas de l'univers sans table dérivée

Je sais que c'est ce genre de problèmatiques qui ont poussés à penser et à créer les datawarehouses, datamarts, infocentres, ...

Pardi ! Bien sûr
L'idéal serait un infocentre sur une base indépendante
Tu l'alimentes quand tu veux
De préférence la nuit
Tu ne pénalises pas la base de prod
Tu ne charges que les données stabilisées par exemple N
En cas de changement dans la base tu ne corriges que l'alimentation

[alextoucour]

non ça s'apparente à une table d'indicateurs statistiques mais ce serait très intéressant pour garder un historique lorsque la structure de la base change

Très intéressant comme concept! Je vais étudier cela de plus près!

le problème est le même dans le cas de l'univers sans table dérivée

Pas exactement, je prends l'exemple de la modification d'un nom de délégué.
Si je modifie le nom du délégué (toto en titi) dans la table délégué, TOUS les résultats de toto seront affectés à titi dans le cas de la table dérivée.

Par contre, à priori, je ne change pas les données existants dans la table d'indicateurs statistiques: les anciennes données seront toujours associées à toto et seuls les nouvelles données seront associés à titi.

C'est un peu tout ca que je n'arrive pas à cerner dans l'idée d'infocentre. Comme est gérée l'historisation des données? Que faire lors de la suppression ou la modification de données dans les bases de données transactionnelles? Comment l'infocentre résout-il ces problèmatiques?

[Bruno2r]

Tu vois bien que t'es mûr pour pondre ces questions en ETL
Alors vas y

[Antoun]

La seule possibilité à mon avis c'est de faire 10 copies de ton univers.

En effet, la synchro des objets est automatique s'ils sont issus du même univers mais en dehors de ça, il faut la faire manuellement.

Pour moi, c'est la seule solution à ton problème.

en fait la synchro automatique se fait parce que les objets portent le même nom. Faire 10 copies de l'univers ne changerait donc rien.

Par contre, faire plusieurs objets identiques pour tes dimensions communes empêcherait la synchro auto.

par exemple, ta requête 1 utilise Client et Produit. Pour ta requête 2, tu crées deux objets Client2 et Produit2, dans une classe technique que tu masqueras à la fin. La formule de Client2 est = @SELECT(client), idem pour Produit2, afin d'éviter la double maintenance.

Comme les objets ont des noms différents, il ne se lieront pas automatiquement. C'est de la bidouille pas très clean, mais si tu as des délais à tenir, ça sera plus rapide que de te lancer dans un projet de DM.

[alextoucour]

C'est super intéressant de voir qu'un même problème peut être aborder à plusieurs niveaux (DM, table dérivée, copie d'univers, rapports)!

par exemple, ta requête 1 utilise Client et Produit. Pour ta requête 2, tu crées deux objets Client2 et Produit2, dans une classe technique que tu masqueras à la fin. La formule de Client2 est = @SELECT(client), idem pour Produit2, afin d'éviter la double maintenance.

Je ne connais pas trop cette syntaxe "@SELECT..." à quoi cela correspond?
Qu'est ce que cela apporte de plus par rapport à la définition "classique" des objets??
J'aurais créé client1 (=client) et client2 (=client).

[Antoun]

@SELECT est une fonction du Designer. Elle permet à un objet d'avoir dynamiquement le même code SQL qu'un autre objet.

(pour faciliter l'explication, j'ai mis en italiques ce qui relève de Designer et en gras ce qui est du SQL)

Supposons par exemple que ton objet Client soit placé dans la classe Marketing et corresponde à la colonne Clients.Nom de ta base. Quand tu fais ton objet Client2, tu lui donnes comme code @SELECT("Marketing\Client")... je ne garantis pas la syntaxe, mais ça ne doit pas être très différent de ça. Tu crées Client3, Client4... au besoin jusqu'à Client10.

Maintenant, tu t'aperçois que certains clients portent le même nom, et que tu dois ajouter le prénom. Tu changes donc la formule de Client en Clients.Nom || ', ' || Clients.Prenom (en syntaxe normalisée). Comme Client2 et ses frères reprennent dynamiquement le code de Client, tu n'as pas besoin de répercuter 10 fois ta modification.

[Bruno2r]

Antoun a une bonne mémoire tout de même.
@SELECT("Marketing\Client")
La syntaxe est bonne mais comme c'est un nom d'objet on ne l'encadre pas comme on le ferait avec du texte Faux J'ai vérifié
Ici on écrirait donc : @Select('Marketing\Client')

En résumé

• @Select
  Permet de réutiliser la clause Select d’un objet existant.
  La syntaxe est :
  @Select(Nomdelaclasse\nomdel’objet)

• @Where
  Permet de réutiliser la clause Where d’un objet existant.
  La syntaxe est :
  @Where(Nomdelaclasse\nom_objet)

il y a d'autres fonctions @ :

• @Prompt qui affiche une invite à l'utilisateur

• @Variable qui récupère la valeur réponse de cette invite ou la valeur d'une variable système (BOUSER ou BIPASS)

• @Script qui récupère la valeur retournée par une fonction écrite en VBA

• @AggregateAware qui permet de préciser le classement d'un champ commun à plusieurs tables en partant de la plus agrégée vers la plus détaillée.

Je vais détailler tout ça dans une Q/R pour la FAQ BO ce serait trop long ici.

[nevada_smith]

en fait la synchro automatique se fait parce que les objets portent le même nom. Faire 10 copies de l'univers ne changerait donc rien.

En fait si, je maintients ce que j'avance. La synchro automatique se fait lorsque deux objets ont le même nom et la même source de données (univers). Le fait de ne pas avoir le même nom d'univers, même si les objets ont le même nom invalide cet automatisme (test fait en version 6.5.1).

Et c'est bien ça qu'on cherche à faire, non?

[alextoucour]

En fait si, je maintients ce que j'avance. La synchro automatique se fait lorsque deux objets ont le même nom et la même source de données (univers). Le fait de ne pas avoir le même nom d'univers, même si les objets ont le même nom invalide cet automatisme (test fait en version 6.5.1).

Je n'ai pas pu tester la copie de plusieurs univers mais par rapport à un autre test je vais dans le sens de Nevada, à savoir que la copie d'univers ne semble pas synchroniser les objets portant le même nom.

Mon test:

Dans mon univers je créé 2 classes contenant chacune exactement le même objet (même nom, même définition).
Je fais une requête avec l'objet 1 puis une seconde avec l'objet 2 et BO ne synchronise pas ces deux objets.
En fait (de mémoire), lorsque l'on créé un objet sous BO, BO lui affecte un identifiant uniquement et je pense que c'est sur celui-ci que la synchronisation se fait.

Par contre je ne retiendrai pas la solution de Nevada car dans mon cas (plusieurs reports multi-requêtes), je trouve la maintenance de dix univers extrémement fastidieuse. Deux univers c'est jouable mais dix ... ca fait beaucoup. Si on a besoin de rajouter ne serait-ce qu'une seule dimension, ca fait dix fois plus de boulot!


Pour information, ces rapports existent déjà et avec ma méthode (mettre plein d'objets pas forcément utiles et délier) cela fonctionne. Mais en revanche, c'est très très compliqué à maintenir. Quand je reviens dessus 6 mois après et que je modifie une requête je dois me souvenir ou retrouver (car j'ai oublié de noter ) tout ce qui doit être délier.