Discussion :

[idris]

Bonjour,
J'ai besoin de votre aide.
Il s'agit de modéliser la gestion des informations de retours clients dans le domaine automobile et mettre en place un système de capitalisation de ces informations de projets en projets (projets véhicule).
J'ai créé une entité Sujets (pour les informations saisis), une entité projets (pour l'ensmble des projets) et une entités METIER(pour les domaines concernés par le projet ex: qualité, planning, cout...).
Un sujet est affecté à un projet donné en fonction du METIER(qualité, cout ou planning...) pour qu'il le prend en considération pour son périmètre projet.
Les informations rajoutés sur chaque sujets dépende du métiet et du projet.
Je vous envoie en pièce jointe une image de ma modélisation.

J'aimerai savoir si c'est une bonne modélisation

,

[CinePhil]

Je pense que ton schéma n'est pas mal mais je ferais les remarques suivantes :
- 'nom métier' n'est pas une bonne clé primaire dans l'entité METIER. Il vaut mieux un identifiant de type entier non signé auto-incrémenté, comme cela semble être le cas dans les deux autres entités.
- selon ton schéma, chaque métier va pourvoir apporter sa solution au même sujet pour le même projet. Je mettrais plutôt la solution adoptée dans l'entité SUJET.
- Il me semble qu'un sujet est propre à un projet et ne peut pas concerner un autre projet. Exemple, un problème de fuite dans le circuit de refroidissement d'une Laguna ne sera pas forcément identique pour une Clio. Donc je ferais plutôt :
Sujet -1,1----Concerner----0,n- Projet
Sujet -1,n----Affecter----0,n- Métier

[idris]

Merci de m'avoir repondu.
-Je suis d'accord pour la première remarque
-Pour la 2ème, je dirai que le sujet représente un défaut constaté sur la qualité(METIER) d'une pièce sur un laguna en clientel.
Et est prévu de créer un projet P1 qui propose un nouveau véhicule qui va remplacer cette laguna. Il faut que le nouveau responsbale qualité(METIER) projet tient compte de ce défaut pour ne pas le repété sur le véhicule qu'il ca construire.
Donc ce sujet est affecté pour le projet en métier qualité.
Un autre projet métier aussi peut etre intérréssé par ce meme sujet (donc métier qualité).
Un sujet peut avoir 2 impacts(Qualité et coût)
Donc chaque sujet est traité pour un projet donnée en fonction du métier impacté.

La règle de gestion:un sujet est affecté à un ou plusieurs projets en fonction d’un métier, et un projet peut se voir affecté plusieurs sujets.
(on a plusieurs métiers pour un projet)
Shéma explicatif



Ex:un bruit de frein sur une laguna est affecté à 2 nouveaux projets qui vont qui vont se basé sur le véhicule pour construire des nouveaux modèles.

Sujet -O,n----Concerner----0,n- Projet (en fonction du métier concerné)

[Soutou]

En regardant le dernier dessin, il faut bien une 3-aire.

Maintenant, toute n-aire est sujette à contrainte (inclusion ou unicité). Ici il s'agit d'inclusion il me semble :
Chaque triplet (s,p,t) est inclus dans (s,p) ensemble de couples cohérents.

Sujet et Projet jouent un rôle prépondérant car chaque couple ayant un sens est rattaché à 1 ou +sieurs métiers.

Avec UML (il faut s'y mettre selon moi), 3 classes S, P et M et 2 classes-asso C1 et C2. C1 relie S à P en multiplicité *-*, C2 relie C1 à M en *-*.

--> 5 tables générées (en théorie).

[idris]

Merci pour ta réponse;
J'ai éclaté ma relation en trois relations:
SUJET-----0,n----retenu-----0,n---------PROJET
PROJET------1,n----concerne-------1,n-------METIER
SUJET---------0,n------affecter----0,n------------METIER

et en plus je dois gérer une règle de gestion qui dit aussi qu'un projet peut proposer un sujet pour un autre projet.

Donner moi votre avis
aidez-moi

Merci

[fsmrel]

Bonsoir,

J'ai éclaté ma relation en trois relations:
SUJET-----0,n----retenu-----0,n---------PROJET
PROJET------1,n----concerne-------1,n-------METIER
SUJET---------0,n------affecter----0,n------------METIER

Cela signifie que :

— Un sujet est retenu pour un projet (ou l’inverse, mais peu importe) indépendamment des métiers.
— Un projet concerne un métier indépendamment des sujets.
— Un sujet est affecté à un métier, indépendamment des projets.

A titre d'exemple, au niveau tabulaire, on pourrait donc avoir les valeurs suivantes :

Code :

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

1
2
3
4
5
6
7
 
Sujet  Projet         Projet   Metier         Sujet  Metier
 s1      p1             p1       m1            s1      m1
 s1      p2             p1       m2            s1      m2
 s1      p3             p1       m4            s1      m3
 s2      p2             p2       m1            s2      m3
                        p2       m3

Traduisant le fait que les relations se font en toute indépendance.

Si au contraire il y a des dépendances, il faut mettre en oeuvre la relation ternaire initiale (Affecter) ou la proposition de Soutou, selon laquelle les relations Sujet - Projet préexistent, tandis que les relations avec Metier sont contraintes par les précédentes (la classe-association C2 permettant de retrouver la ternaire Affecter).

Toutefois, s’il n’y a pas indépendance, mais s’il existe par exemple une règle selon laquelle si un sujet affecte implicitement tous les métiers concernant les projets pour lesquels ce sujet est retenu, alors l’éclatement en trois relations binaires est correct, dans la mesure où l'on est à même de vérifier que leur jointure naturelle est égale à la ternaire. (Pour la petite histoire, au niveau relationnel, on dit qu’il existe une dépendance de jointure et que la projection de la ternaire en trois binaires revient à normaliser en cinquième forme normale.)

N.B. Dans ce qui précède, je n’ai pas tenu compte des éventuelles propriétés portées par les relations.

je dois gérer une règle de gestion qui dit aussi qu'un projet peut proposer un sujet pour un autre projet.

Abstraction faite de tout ce qui précède, il y a de la réflexivité dans cette histoire. Si pour un sujet, un projet joue le rôle de déterminant vis-à-vis d’un autre projet jouant le rôle de dépendant, la représentation graphique (Power AMC) ci-dessous pourrait convenir. Si c’est pour plusieurs sujets, la cardinalité 1,1 (côté R3) est à remplacer par 1,N.


J’ai supposé qu’un projet pouvait jouer plus d’une fois le rôle de déterminant et qu’un projet pouvait jouer plus d’une fois le rôle de dépendant.
MLD correspondant :

[idris]

Merci pout ton éclairsissement
Comme il ya une dépendance entre les entités j'ai reconsidéré la relation 3-naires;la propriété commentaite est est fonction du sujet, du projet et d'un métier donné donc id_sujet+id_projet+id_metier-------->commentaire.

et pour gérer la règle de gestion qui dit qu'un projet peut proposer un sujet pour un autre projet, j'ai créer une deuxième relation comme tu me l'avai proposé. j'ai le shéma suivant.



Un autre souci est que le sujet proposé par un projet pour un autre projet est aussi fonction d'un métier donné.
ex: S1 métier m1 est proposé par P1 métier m1 pour P2 métier m1

je suis perdu!

[idris]

Est ce que je dois lier l'entité Metier à la relation Proposer pour créer une relation 4-aire.
Mais je sais pas si c'est une bonne modélisation.

Guider moi

Merci

[idris]

Bonjour,
Je propose une nouvelle modélisation. J'ai créé une entité regroupant des informations de METIER et PROJET poaur aléger le schéma. Et aussi en considérant l'entité utilisateur pour garder trace des personnes qui créer les sujets.


Donnez moi vos avis

Merci