[MPD] Table d'identifiants, hérésie ? [Résolu]

[BaBeuH]

Bonjour,

Je suis face à un problème de conception où mon coté obscur (le coté développeur, et donc fainéant au possible) et mon coté clair (le coté modélisateur/concepteur qui essaie de respecter les grands principes relationnels) s'opposent, je m'explique :

J'ai une entité CLIENT qui comme son nom l'indique référence les clients, j'ai une autre entité EVENEMENT qui référence des évènements (j'aime bien enfoncer les portes ouvertes).

Les règles de gestion sont les suivantes :
- Un client ou un groupe de client peuvent participer à un ou plusieurs évènements
- Chaque client / groupe de client participant à un évènement peut avoir d'autres relations avec différentes entités (le modèle de celles-ci importent peu si ce n'est qu'elles peuvent être nombreuses).

Ainsi, j'ai défini le modèle suivant :

CLIENT(idclient,nom,prenom)
EVENEMENT(idevenement,libelle,date)
PARTICIPANT(idclient,idevenement)

Voici la théorie, maintenant, j'ai besoin d'utiliser le tuple {idclient,idevenement} dans d'autres entités, et c'est là que mon coté fainéant du développeur intervient, gérer deux attributs pour référencer un participant, que c'est ennuyeux !... Je me dis donc que je vais générer un idparticipant qui me facilitera la vie pour associer mes participants à d'autres entités. Mise à part probablement une entorse aux principes de modélisation, jusque là tout va bien, maintenant passons à la mise en oeuvre :

La table PARTICIPANT va donc posséder un attribut idparticipant qui sera auto-incrémental (comme tout bon identifiant généré qui se respecte), mais là où le problème se pose, c'est lorsqu'il y a un groupe de client !

En effet, l'idparticipant sera répété pour un groupe de client :

Code :

1
2
3
4
idclient     idevenement     idparticipant
1             1                    1
2             1                    1
3             1                    1

Mince alors, ma colonne idparticipant auto-incrémentale ne correspond pas à la situation ! ou alors il faut forcer l'ajout lors de l'insert ! (beurk !)

Je me dis donc que je vais "externaliser l'auto-incrémentalité" (vive les barbarismes !) dans une table dont le role ne sera que de "fournir" des identifiants, je n'ai pas d'autres attributs propres à chaque participant qui serait stocké dans cette table... Si ce n'est un nom/libellé mais qui ne concernerait que les groupes de clients car le nom d'un unique client participant serait... son nom ! Et donc pour éviter des bonhommes NULL j'utiliserai une autre table pour y stocker l'information.

En résumé, voilà ce que j'obtiens :

CLIENT(idclient,nom,prenom)
EVENEMENT(idevenement,libelle,date)
PARTICIPANT(idclient,idevenement,idparticipant)
GEN_PARTICIPANT(idparticipant) <-- la table qui génère les idparticipants
NOM_PARTICIPANT(idparticipant,nom) <-- la table des noms de groupe de clients

Voilà, qu'en pensez-vous, serai-je brulé vif sur l'autel de la modélisation pour avoir généré tout ça ?

Merci d'avance,

A+

[punkoff]

Bonjour,

Dans votre 1ere modélisation la notion de groupe n'apparait pas.

elle décrit simplement :
- un ou plusieurs client peuvent participer à un ou plusieurs évenements.



Bon pour ce qui suit, attendez d'autre réponse :


De ce que je comprend du problème :

On reprend donc la RG de base :
Client-0,N------Participe------0,N-Evement

Ensuite, on rajoute ces deux notions :
- Un client peut appartenir à un ou plusieurs groupe de client
- Un groupe de client contient un à plusieurs clients

- Un groupe de client peut participer à un ou plusieurs evenement
- un evenement peut être composé d'un ou plusieurs groupes de client.


Niveau modélisation :

Code :

1
2
3
4
5
6
7
8
Client-0,N------appartient------1,N-Groupe
Groupe-0,N-----Participe------0,N-Evenement

On reboucle le tout :
Client-0,N---------------Participe1-------------0,N-Evement
      |                                                |
     0,N---Appartient---1,N-Groupe-0,N---Participe2---0,N

Bien du coup ca change des choses !

Car au nivaeu du MPD ca donnera 2 tables d'association, une pour les clients et une pour les groupes de clients, avec surement des contraintes à gérer entre un client qui partiticpe à un evenement et ce même client qui appartient à un groupe qui participe à ce même evenement !

[BaBeuH]

Effectivement, ma première modélisation ne prend pas en compte la notion de groupe de clients, ce modèle est à oublier...

Concernant la création d'une table groupe, j'avais effectivement pensé à ça, sauf que si j'ai bien compris votre modèle, cela implique que l'occurence d'une participation à un évènement peut se trouver dans 2 tables différentes selon que le participant participe (et que les athéniens s'atteignirent) seul ou en groupe à l'événement (participe1 ou participe2).

Afin d'éviter la gestion de 2 tables, on peut utiliser une unique table participe, mais on ne peut pas mettre en oeuvre de clé étrangère qui pointe soit vers un groupe soit vers un client... L'autre solution serait d'avoir 2 colonnes idclient ou idgroupe dans la table participe, mais qui engendrerait des bonhommes NULL...

L'objectif de ma table PARTICIPANT dans mon modèle est de s'affranchir du type de participant (client ou groupe de client) afin de ne gérer que des participants dans les autres entités... De plus, la création d'un attribut "artificiel" idparticipant (en lieu et place d'une identification relative) me permet de simplifier (du point de vue du développeur, toujours aussi fainéant) les relations avec les autres entités.

Voilà pourquoi j'en suis arrivé à mon modèle avec une table de "génération" d'identifiant des participants...

Si quelqu'un a une autre solution plus élégante, qu'il n'hésite pas...

A+

[CinePhil]

Il faut alors faire un héritage en inventant une entité mère Participant.

Règles de gestion :
1) Un participant participe à un à plusieurs événements et un événement voit la participation de un à plusieurs participants.
2) Un client est un participant et un participant peut être un client
3) Un groupe_client est un participant et un participant peut être un groupe_client
4) Un client peut appartenir un groupe_client et un groupe_client possède de un à plusieurs clients

MCD :

client -0.n-------------------appartenir--------------1,n- groupe_client
  |----(1,1)----être----0,1- participant -0,1----être----(1,1)---|
                                 |
evenement -0,n----avoir----0,n---|

Tables :
evenement (evt_id, ...)
participant (prt_id,...)
prt_participer_evt (ppe_id_participant, ppe_id_evenement)
client (clt_id_participant, ...)
groupe_client (gct_id_participant,...)
clt_appartenir_gct (cag_id_client, cag_id_groupe)

Dans ce MCD, j'ai fait une identification relative du client ou du groupe_client par rapport au participant, ce qui fait que le client ou le groupe_client récupère l'identifiant du participant. Mais on peut faire l'inverse si la participation d'un client ou d'un groupe de client n'est qu'un aspect secondaire du modèle et que les entités fortes ici sont le client et le groupe_client :

client -0.n-------------------appartenir--------------1,n- groupe_client
  |----0,1----être----(0,1)- participant -(0,1)----être----0,1---|
                                 |
evenement -0,n----avoir----0,n---|

Il faudra alors faire une légère entorse aux bonnes pratiques en ignorant que normalement une association 0,1-0,1 donne une table associative. Ce serait ici superflu du fait de l'identification relative de particpant depuis client ou groupe_client. C'est quasiment un héritage à l'envers !

Tables :
client (clt_id, ...)
groupe_client (gct_id,...)
clt_appartenir_gct (cag_id_client, cag_id_groupe)
evenement (evt_id, ...)
participant (prt_id,...) <= soit l'id du client, soit l'id du groupe_client !
prt_participer_evt (ppe_id_participant, ppe_id_evenement)

Dans ce second modèle, la structure de la table participant est quand même un poil ambigüe ! Pas de gestion de clé étrangère possible !

[BaBeuH]

Par rapport à ton dernier modèle, ce n'est effectivement pas trés propre et dans ce cas, je préfère autant la situation où participant possède 2 colonnes, idclient et idgroupe_client mais qui engendrent des colonnes NULL...

Concernant ton premier modèle, c'est effectivement un modèle qui pourrait convenir, il mets d'avantage l'accent sur la notion de groupe de client puisque c'est une entité à part entière.

Toutefois, si je fais le point, ta table participant ne possède comme attribut que l'identifiant idparticipant ?

evenement (evt_id, libelle, date)
participant (prt_id)
prt_participer_evt (ppe_id_participant, ppe_id_evenement)
client (clt_id_participant, nom, prenom)
groupe_client (gct_id_participant, nom)
clt_appartenir_gct (cag_id_client, cag_id_groupe)

Et donc, pour en revenir à ma question initiale, ce n'est donc pas une hérésie que d'avoir une table d'identifiants ?

PS: Si je regarde mon schéma et ce dernier schéma, je ne vois pas de grosses différences "fonctionnelles" si ce n'est que l'accent est mis sur la notion de "groupe de client", me trompe-je ?

[CinePhil]

Envoyé par BaBeuH

Par rapport à ton dernier modèle, ce n'est effectivement pas trés propre et dans ce cas, je préfère autant la situation où participant possède 2 colonnes, idclient et idgroupe_client mais qui engendrent des colonnes NULL...

Oui en le rédigeant, je me disais que c'était plutôt sale comme modèle !

Concernant ton premier modèle, c'est effectivement un modèle qui pourrait convenir, il mets d'avantage l'accent sur la notion de groupe de client puisque c'est une entité à part entière.

Toutefois, si je fais le point, ta table participant ne possède comme attribut que l'identifiant idparticipant ?

Réfléchis bien si tu n'as pas des propriétés communes quand même.
Nommes-tu les groupes de clients ?
Si oui, comme le client a lui aussi un nom, voilà une propriété commune.

Et donc, pour en revenir à ma question initiale, ce n'est donc pas une hérésie que d'avoir une table d'identifiants ?

Ce n'est pas forcément une hérésie de n'avoir pour seule colonne dans la table un identifiant.
J'ai eu le cas suivant à modéliser :
Certaines personnes sont des utilisateurs.
Certains utilisateurs sont des candidats.
Certains candidats sont des étudiants.

L'étape candidat était justifiée par l'existence d'une association spécifique mais l'entité fille candidat ne contenait pas de propriétés particulières par rapport aux utilisateurs et les propriétés des étudiants n'étaient pas encore nécessaires tant que le candidat n'était pas devenu étudiant. La table des candidats ne comportait donc qu'un identifiant hérité de la table des utilisateur qui elle-même héritait de la table des personnes.

PS: Si je regarde mon schéma et ce dernier schéma, je ne vois pas de grosses différences "fonctionnelles" si ce n'est que l'accent est mis sur la notion de "groupe de client", me trompe-je ?

Oui effectivement, c'est ce que je m'étais dit aussi en rédigeant mon message.

[BaBeuH]

Le nom pourrait être effectivement une propriété commune au client et groupe de client, toutefois, si je déporte le nom du client et groupe de client dans la table participant, j'obtiens une table client qui n'a plus de nom, or cette table des clients a d'autres relations qui ne sont pas liées à la "participation à un événement" et le nom du client pourrait être utile...

Si je ne déporte pas cette propriété "nom" mais que j'en crée une nouvelle dans la table participant, j'aurai dans le cas d'un client "unique" un doublon au niveau du nom...

Je ne vois pas actuellement d'autres propriétés communes, mais si cela ne choque personne en termes de conception que d'avoir une table "technique" (puisqu'elle n'a comme rôle que de fournir des identifiants générés), mais maintenant que j'écris ce message, je me rends compte qu'on est déjà au niveau du MPD et qu'on a "dépassé" la phase de conception...

Par contre, en réfléchissant bien à mon cahier des charges, je me suis rendu compte d'un petit oubli, à savoir que la composition d'un groupe de client n'est pas forcément connue (elle pourra être renseignée à posteriori). Le groupe de client est dans ce cas créé uniquement avec son nom.

Et ce détail change tout dans mon modèle puisque celui-ci n'autorise pas la création d'un "groupe de client vide"...

Par contre, ton modèle CinePhil respecte, lui, le cahier des charges.

Mon coté fainéant de développeur voulait éviter d'avoir à gérer plusieurs tables différentes (selon qu'il s'agit d'un client unique ou d'un groupe de client), mais je n'y couperai probablement pas !