Discussion :

[jijimus]

Bonjour j'ai un soucis avec les MCD.
J'ai bien compris les cours mais j'ai du mal à les appliquer.

Si on prend l'exemple d'un réseau social ultra simpliste, on s'inscrit on note nos coordonnée on demande des amis, on créé des groupes types (famille, travail) et on décide quel type d'information montrer à quel groupe d'amis. Par défaut les amis ne sont dans aucun groupe et ne voient rien.

Donc est ce que mon mcd joint est bon? la difficulté c'est que les amis sont des membres? est ce que j'aurais du faire une association réflexive? si oui comment j'enregistre l'état de la demande d'amis (demandé, validée)? c'est un attribut de l'association demande d'amis??

Aussi j'ai l'impression que quelque chose cloche, dans la table des demandes d'amis je vais me retrouver avec une ligne par amitié et non pas par membre, comment optimiser tout ca?

je vous remercie pour toute aide

[fsmrel]

Bonsoir jijimus,

La difficulté c'est que les amis sont des membres? est ce que j'aurais du faire une association réflexive?

Puisque les amis sont des membres, votre entité-type AMI doit être absorbée par l’entité-type MEMBRE.

J’observe que l’attribut id_member est présent plusieurs fois dans le MCD : il ne peut l’être qu’une et une seule fois.

L’association réflexive s’impose, car elle permet d’associer un membre (source, celui qui fait la demande) à un autre membre (cible, celui qui reçoit la demande). Un attribut de type booléen, appelons-le Acceptation, permet de savoir si la demande a été acceptée (modélisation faite avec DB-MAIN, gratuit) :





D’où les structures relationnelles :

MEMBRE {id_membre, nom, prenom, ...}
    KEY {id_membre}
;

DEMANDE {id_membre_cible, id_membre_source, Acceptation}
    KEY {id_membre_cible, id_membre_source}
    FOREIGN KEY {id_membre_cible} REFERENCES MEMBRE {id_membre}
    FOREIGN KEY {id_membre_source} REFERENCES MEMBRE {id_membre}
;

Passons aux groupes. N’utilisez pas le point dans les noms des attributs car il joue un rôle très important en SQL, et vous auriez de grosses surprises en le conservant : remplacez id.groupe par id_groupe. L’attribut Pseudo caractérise-t-il bien l’entité-type GROUPE ? Sinon, il devrait normalement figurer dans l’entité-type MEMBRE. L’attribut id.membre (ou plutôt id_membre) n’a pas à figurer dans GROUPE puisque déjà présent dans MEMBRE.

Comme ils existent déjà dans le MCD, les attributs id_membre et id_groupe doivent être supprimés de l’association ATTRIBUER.

Cela dit, ATTRIBUER est une association entre GROUPE et DEMANDE, mais DEMANDE est aussi une association, or dans un MCD merisien on ne peut pas connecter deux associations : pour contourner la difficulté, on va donc déguiser DEMANDE en entité-type :






D’où les structures relationnelles :

MEMBRE {id_membre, nom, prenom, ...}
    KEY {id_membre}
;

DEMANDE {id_membre_cible, id_membre_source, Acceptation}
    KEY {id_membre_cible, id_membre_source}
    FOREIGN KEY {id_membre_cible} REFERENCES MEMBRE {id_membre}
    FOREIGN KEY {id_membre_source} REFERENCES MEMBRE {id_membre}
;

GROUPE {id_groupe, id_membre, nom_groupe, ...}
    KEY {id_groupe}
    KEY {id_groupe, id_membre}
    FOREIGN KEY {id_membre} REFERENCES MEMBRE {id_membre}
;

ATTRIBUER {id_groupe, id_membre_cible, id_membre_source}
    KEY {id_groupe, id_membre_cible, id_membre_source}
    FOREIGN KEY {id_membre_cible, id_membre_source} REFERENCES DEMANDE {id_membre_cible, id_membre_source}
    FOREIGN KEY {id_groupe, id_membre_cible} REFERENCES GROUPE {id_groupe, id_membre}
;

Vous êtes en droit d’être surpris par la présence de deux clés candidates pour la table GROUPE : la clé {id_groupe} est la clé primaire, tandis que la clé {id_groupe, id_membre} est une surclé, ce qui permet de s’assurer, non seulement que chaque paire {id_membre_cible, id_membre_source} de la table ATTRIBUER fait bien référence à son homologue {id_membre_cible, id_membre_source} de la table DEMANDE, mais aussi que le membre id_membre_cible de la table ATTRIBUER est bien le géniteur du groupe concerné.

Cette façon de procéder permet d’éviter de coder des triggers vérifiant qu’on n’associe pas des membres à des groupes où ils n’ont rien à faire.

Un point à régler : on ne doit pas pouvoir affecter à un groupe un membre qui est en attente d’acceptation de la part du créateur du groupe (cf. l’attribut Acceptation de la table DEMANDE) : un trigger paraît incontournable pour garantir cela.


L'exemple du réseau social est peut-être en apparence ultra simpliste, mais en garantir l’intégrité l’est un peu moins...


N.B. Le nom d’une entité-type doit être au singulier, car c’est en fait le nom d’un prédicat, les occurrences de l’entité-type en étant les propositions : ceci vaut pour MEMBRE, GROUPE et AMI.
J’utilise des lettres capitales dans ces noms seulement pout mieux les repérer.