Discussion :

[Yohan24]

Bonjour,
Je cherche à afficher la quantités des produits utilisés pour un client avec la requête :

Code :

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

1
2
3
4
SELECT designation, SUM(quantite)
FROM ((((PRODUIT INNER JOIN UTILISER ON PRODUIT.ref = UTILISER.ref) INNER JOIN TRAITEMENT ON UTILISER.id = TRAITEMENT.id) INNER JOIN TRAITER ON TRAITEMENT.id = TRAITER.id_TRAITEMENT) INNER JOIN PARCELLE ON TRAITER.id = PARCELLE.id) INNER JOIN CLIENT ON PARCELLE.id_CLIENT = CLIENT.id
WHERE CLIENT.id = 1
GROUP BY UTILISER.ref

Mon MLD est :


Mais le résultat de cette requête ne me retourne pas la bonne somme.

Merci d'avance pour vos suggestions.

[SQLpro]

Votre modèle est fait à l'arrache avec des nommages stupide ! En effet normalement les colonnes PK et FK devrait porter le même nom lorsque ce sont les mêmes informations.
Or toutes vos PK sont nommées ID et par conséquent vos FK ont un nom différent.
Il ne faut donc pas faire une jointure ???.ID = !!!.ID mais ???.ID = !!!.ID_machin...

A +

[StringBuilder]

Rien d'étonnant à ça.

Votre modèle est bancal : au vue des cardinalités, à un moment où à un autre il n'y a plus de lien 1->n entre le client et les produits, mais une relation de type n-m dans les deux sens.

Par conséquent, votre table "traitement" ou "utiliser" provoque un produit cartésien.

[StringBuilder]

Votre modèle est fait à l'arrache avec des nommages stupide ! En effet normalement les colonnes PK et FK devrait porter le même nom lorsque ce sont les mêmes informations.
Or toutes vos PK sont nommées ID et par conséquent vos FK ont un nom différent.
Il ne faut donc pas faire une jointure ???.ID = !!!.ID mais ???.ID = !!!.ID_machin...

A +

Bof, personnellement, je ne suis pas fan d'avoir des ID à ralonge dans toutes les tables pour assurer un nom unique dans chaque table.

Ceci a un intérêt en TP de première année d'IUT, quand on apprends ce que c'est que le NATURAL JOIN.

Ensuite, on a les mêmes limitations : dans une table "produit_remplacant" on va avoir "id_produit_remplace, id_produit_remplacant", alors que dans la table produit on n'a aucune de ces deux colonnes, mais "id_produit" tout court.
Donc on doit à un moment où à un autre casser la logique de nommage.

L'avantage, je trouve, d'avoir "id" comme PK, c'est qu'à coup sûr c'est l'identifiant, on n'a pas à se poser de question si on a plusieurs colonnes avec des noms similaires (id_produit_erp, id_produit_ean, id_produt_code, etc.)

Et surtout, le gros avantage, c'est que le NATURAL JOIN ne fonctionne sur aucune requête et ça évite de planter l'application le jour où on crée une nouvelle colonne "date_modification" dans tous les tables par exemple.

[escartefigue]

Votre modèle est bancal : au vue des cardinalités, à un moment où à un autre il n'y a plus de lien 1->n entre le client et les produits, mais une relation de type n-m dans les deux sens.

C'est tout à fait normal : un produit peut être utilisé par plusieurs clients et un client peut utiliser plusieurs produits

Comme la requête de Yohan24 semble accepter ce Group By fantaisiste, je suppose que le SGBD est MySQL, du coup voici une solution sans passer par une CTE :

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
select pr.designation
     , sum(xx.qte) 
from (select ut.ref  
           , ut.quantite as qte
      from utiliser as UT
      inner join traitement as TM
         on tm.id = ut.id
      inner join traiter as TT
         on tt.id_traitement = tr.id
      inner join parcelle as PA
         on pa.id=tt.id
      where pa.id_client =1) as XX
inner join produit as PR
   on PR.ref = xx.ref
group by pr.designation

[Yohan24]

Merci de vos réponses, je suis novice dans le domaine ce qui explique mon modèle "bancal".

escartefigue : J'ai essayé votre requête mais celle-ci me renvoie aussi un résultat aberrant.

[escartefigue]

Si ce n'est pas trop volumineux
- communiquez la liste des lignes de la table PARCELLE dont le id_client vaut 1
- communiquez la liste des lignes de la table TRAITER pour les id issus de la liste qui précède
- et ainsi de suite, suivez le cheminement des identifiants jusqu'à la table produit

Communiquez ensuite le résultat attendu et le résultat obtenu

[Yohan24]

Voici le cheminement : *


Le résultat attendu serait :
Produit 1 | 5
Produit 2 | 5
Produit 3 | 24
Produit 5 | 15
Produit 6 | 15

Le résultat obtenu est :


Je trouverais logique d'obtenir :
Produit 1 | 15
Produit 2 | 15
Produit 3 | 57
Produit 5 | 30
Produit 6 | 30

Mais la je ne comprend pas d'où il me sort ces nombres.

[escartefigue]

D'après ce que je vois, le traitement n°1 est utilisé sur les parcelles n° 1, 2 et 3
Comme le traitement 1 utilise 5 unités du produit 1, le résultat 15 est logique.

D'ailleurs je me rends compte que ça ne va pas, car il faut pondérer la quantité consommée pour un traitement, en fonction de la surface de chaque parcelle
La règle de calcul est donc somme(surface) de toutes les parcelles x dose/ha du produit

A ce sujet, pourquoi avoir utilisé un type FLOAT pour les surfaces , du decimal serait plus adapté

[StringBuilder]

Après avoir passé un bon moment à me recréer les tables et y insérer le jeu de données, je suis arrivé à la même conclusion qu'escartefigue : les calculs semblent tout à fait corrects au vue des données.

Et même remarque à propos de la surface : si vous n'avez que des entiers, utilisez un INT, et si vous avez des décimales, utilisez DECIMAL(5,2) par exemple.

Et enfin, il me semble aussi opportun de pondérer les quantités utilisées dans les traitements par la superficie, ça me semble plus logique.

[Yohan24]

En effet le calcul correspond pour le produit n°1 mais pas pour le n°3.
Merci, c'est une erreur de ma part, je vais utiliser un Decimal pour la surface.
En faite je mis prend peut être mal mais je souhaite afficher pour tout les traitements d'un client, les nom des produit et la quantité total utilisé des produits. Ceci dans le but de de calculé la dose utilisé divisé par la surface total de l'exploitant et non la surface traité (je sais que cela n'est pas logique mais c'est pour arrondir dans le bon sens les résultats).
Je suis encore entrain de modifié mon schéma de base de donnée qui comme vous l'avez dit est bancal malheureusement je ne fais que mettre en exergue ce que l'on m'a appris.
Merci de vos conseils.

[escartefigue]

Sauf que si vous ne tenez pas compte de la surface totale, vous aurez ce genre de résultat

1er exploitant qui exploite 20 parcelles de 0,5 ha en moyenne chacune (cas d'un cultivateur dans un paysage de bocage), sur laquelle il utilise un produit P1 à raison de 1kg par hectare
2ème exploitant qui possède 3 parcelles de respectivement 50, 42 et 53 ha sur laquelle il utilise également le produit P1 à raison de 1kg par hectare

Votre résultat sera 20x1kg pour le 1er exploitant et 3x1kg pour le deuxième, dans cet exemple vous comprendrez que les deux résultats sont complètement faux et le rang est inversé

D'ailleurs, pour avoir travaillé dans le milieu agricole plusieurs années, je me souviens aussi que les doses préconisées par le producteur de produits phytosanitaires et les doses effectivement utilisées par l'exploitant sont parfois très différentes.

Il faudrait donc, pour un résultat fiable, tenir compte :
- de la surface réellement traitée et non la surface totale de la parcelle (il est possible qu'une partie de la parcelle ne soit pas cultivée, ou pas traitée par exemple pour comparer le résultat avec et sans traitement)
- de la dose réellement utilisée par unité de surface pour le traitement et non de la dose préconisée par le chimiste

Le problème est donc un peu plus complexe qu'il n'y parait en première approche, et votre modèle de données devrait en tenir compte :
- il faut quelque part enregistrer le dosage du produit à telle date sur telle parcelle...
- il faut également connaitre la surface effectivement traitée

[Yohan24]

Merci pour votre réponse.
Excusez moi, j'aurais dû m'expliquer correctement dès le début, j'aimerais à terme pouvoir calculer l'Indice de Fréquence de Traitement qui correspond à la somme des IFT de chaque produits utilisée :

• Par exemple pour calculer l'IFT d'un client qui utiliserait 10Kg de produit P1 et 20kg de produit P2, le tout sur 3 parcelles (respectivement de 10, 8 et 2 Ha) pour une surface total de 20Ha.
• L'IFT d'un produit correspond à la quantité utilisé soit pour P1 10Kg divisé par la surface traité soit 20Ha divisé par la dose/Ha homologué du produit qui sera pour P1 et P2 de 1Kg/Ha.
• Ce qui nous donne 10/20/1=0,5 pour P1 et 20/20/1=1; On obtient 0,5+1 un IFT de 1,5 pour ce client.
• Tout cela pour pouvoir en fin de saison calculer l'IFT de chaque client avec une requête qui récupérerait pour chaque produits : la somme de la quantité de ce produits dans les traitements et la surface total de toutes les parcelles d'un client.

Le champ "quantite" de ma table UTILISE correspond en réalité à la dose en kg ou en litre total réellement utilisé pour un traitement (la dose préconisée par le chimiste correspond a mon champs doseHa de la table PRODUIT), par exemple :

• Pour un traitement à 1kg/ha sur 10ha le champ quantité sera égal à 10.

Je suis d'accord avec vous concernant la fiabilité du calcul, de même on pourrait amélioré la précision du calcul de l'IFT en prenant compte des parcelles traités mais l'on m'a explicitement demandé de ne pas le faire.
Je me rend compte que je pourrait presque me passé de la table PARCELLE mais dans l'optique où je devrais faire évolué plus tard mon application pour prendre en compte les parcelles je pense qu'il est plus sage de l'implémenté maintenant.