Discussion :

[reitsab]

Bonjour,

Voici mon analyse :



Mon interface graphique me permet de choisir plusieurs moteurs pour un projet grâce à une liste.
Mettons que je choisisse un seul moteur pour un projet, l'ajout de l'enregistrement dans la table Projet ce passe sans aucun problèmes.
Mais comment dois-je faire si je souhaite ajouter 2 moteur à un Projet ?
Ce qui veut dire qu'un projet sera lié à 2 moteurs.

Merci

[CinePhil]

Mais comment dois-je faire si je souhaite ajouter 2 moteur à un Projet ?
Ce qui veut dire qu'un projet sera lié à 2 moteurs.

Ben il faut changer ton modèle de données.
Aujourd'hui, un projet ne peut être lié qu'à un seul moteur.

Il faut donc faire la relation
Moteur <-1,n----1,n- Projet

Ce qui entraîne la création d'une table associative :
Moteur_Projet (IDMoteur, IDProjet)

Et la suppression de IDMoteur dans la table Projet.

[reitsab]

Je pensais que ma relation était correcte !

Pour moi (et d'apres WinDev) elle veut dire :

Moteur<1,1-- :

• Chaque "moteur" a au moins un "projet"
• Un "moteur" n'as qu'un seul "projet"

--1,n-Projet :

• Chaque "projet" a au moins un "moteur"
• Chaque "projet" peut avoir plusieurs "moteurs"

[reitsab]

Je ne voie pas quelle requette faire pour ajouter plusieurs moteurs à un projet, qui peut m'aider svp ?

[CinePhil]

Je pensais que ma relation était correcte !

Pour moi (et d'apres WinDev) elle veut dire :

Moteur<1,1-- :

• Chaque "moteur" a au moins un "projet"
• Un "moteur" n'as qu'un seul "projet"

--1,n-Projet :

• Chaque "projet" a au moins un "moteur"
• Chaque "projet" peut avoir plusieurs "moteurs"

D'après vos tables, il y a une clé étrangère NumeroMoteur dans la table Projet. J'ai donc interprété les cardinalités du schéma dans le même sens que sur un diagramme de classes UML :
Moteur -1..1----1..*- Projet

En MCD Merise, ça donnerait plutôt ce qui suit, les cardinalités étant inversées :
Moteur -1,n----Avoir----1,1- Projet

Ne connaissant pas cette notation bizarre de WinDev qui n'est ni du MCD, ni du MLD, ni du DC UML mais apparemment un mélange des trois avec une signification bizarre des cardinalités, je ne pouvais qu'interpréter selon mes connaissances.

Il y a une contradiction dans votre première règle de gestion :

• Chaque "moteur" a au moins un "projet"
• Un "moteur" n'as qu'un seul "projet"

"au moins un" signifie "un et potentiellement plusieurs" et est donc en contradiction avec la deuxième partie qui stipule qu'il n'y a qu'un seul projet pour un moteur.
Je dirais plus simplement :
"Un moteur a un et un seul projet".

Si un moteur n'a qu'un seul projet, en MCD on a ceci :
Moteur -1,1----Avoir----min,max- Projet
Et dans ce cas, c'est l'identifiant du projet qui doit se retrouver en clé étrangère dans la table Moteur et pas l'inverse.

Par contre, la deuxième règle de gestion est claire. C'est même selon moi un pléonasme :

• Chaque "projet" a au moins un "moteur"
• Chaque "projet" peut avoir plusieurs "moteurs"

Je dirais plus simplement :
"Un projet a de un à plusieurs moteurs".
La cardinalité est bien de 1,n et le MCD complet est le suivant :
Moteur -1,1----Avoir----1,n- Projet

Les tables qui en découlent doivent avoir la forme suivante :
Projet (IDProjet, Code_projet, Commentaires_projet)
Moteur (IDMoteur, IDProjet, Commentaire_moteur, Cylindree_moteur, Type_moteur, Refroidissement_moteur, Alimentation_moteur, Cycle_moteur)

Ce dernier morceau de message m'a permis de me rendre compte que vous avez inséré des attributs du moteur dans le projet, ce qui n'est évidemment pas leur place !
De plus, la clé étrangère fait référence à la clé primaire de l'autre table (IDMoteur), pas à un autre attribut (Numero_Moteur dans votre schéma).

Il vous faut donc commencer par modifier votre modèle de données sinon vous allez dans le mur avec vos moteurs !

A noter que d'après ce que vous dites dans votre premier message :

Mon interface graphique me permet de choisir plusieurs moteurs pour un projet grâce à une liste.

Le moteur existe avant le projet. La cardinalité côté moteur devrait donc être 0,1 et non pas 1,1.
Ce qui, en toute rigueur, devrait là aussi entraîner la création d'une table associative pour éviter d'avoir une clé étrangère nulle pour les moteurs non encore affectés à un projet.

Bref, révisez bien vos règles de gestion, refaite le bon MCD selon le formalisme Merise puis créez vos tables dans WinDev et regardez ensuite comment WinDev a fait le schéma et placé les cardinalités.

Ca fait plusieurs fois que je vois des messages traitant de WinDev ou de son SGDB HyperFile qui ont des notations pas standard.

[reitsab]

Merci d'avoir pris le temps de m'expliquer votre point de vue. Je n'ai pas été formé pour réaliser des applications de gestion et étant donné que c'est ma première application en entreprise, c'est un peut difficile pour moi !

J'ai bien pris note de vos remarques et j'ai modifié mon analyse pour avoir :

Moteur -0,1----Avoir----1,n- Projet

Cela n'as pas pour autant créé une table associative. Mais l'important c'est que j'ai réussi à faire ce que je souhaitait, même si je ne pense pas que mon traitement soit optimisé !!!

Je procède donc de la façon suivante :

Je créé un projet avec tout ces paramètres (Commentaire_moteur, Cylindree_moteur, Type_moteur, Refroidissement_moteur, Alimentation_moteur, Cycle_moteur). Comme vous le remarquez, ces champs appartiennent bien à la table Projet.
Et ensuite, je modifie (UPDATE) les moteurs que je souhaite ajouter au projet en faisant : Moteur.IDProjet = Projet.IDProjet.

[CinePhil]

Je créé un projet avec tout ces paramètres (Commentaire_moteur, Cylindree_moteur, Type_moteur, Refroidissement_moteur, Alimentation_moteur, Cycle_moteur). Comme vous le remarquez, ces champs appartiennent bien à la table Projet.

Bizarre ! Sans plus d'explication sur la raison, admettons !

Et ensuite, je modifie (UPDATE) les moteurs que je souhaite ajouter au projet en faisant : Moteur.IDProjet = Projet.IDProjet.

OK

[reitsab]

Les raison sont propore à l'utilisation du logiciel.

Merci pour votre aide