Modéliser un émetteur et un propriétaire de ticket

Bonjour,

OK, le titre n'est pas parlant (sauf quand on baigne dedans), mais pas trouvé plus explicite...

J'ai extrait d'un MCD complet la partie concernée :

Pièce jointe 604746

Les règles de gestion qui nous intéressent sont :

R001 : un ticket est la déclaration d'un bug sur produit (il existe dans le MCD complet une entité qui déclare un produit mais pas reportée ici)

R002 : un ticket est émis par un utilisateur (nommé submitter)

R003 : le propriétaire du ticket (pas forcément le submitter) est le customer.

S'il existe 2 entités (US_user et UST_user_ticket), c'est que UST_user_ticket est liée aux tickets uniquement alors que US_user ne concerne pas que les tickets.

Il convient donc de représenter dans le modèle (puis dans la base de données) les 2 utilisateurs : submitter et customer.

La question que je me pose : faut-il, comme ici, une seule classe UST_user_ticket ou bien 2 classes (USS_user_submitter et USR_user_requester), comme ici :

Pièce jointe 604749

Merci de votre avis.

Bonjour LaurentSC

Il me semble avoir déjà répondu à cette question dans le fil de discussion du MCD complet :weird:

Quoi qu'il en soit, il n'y a aucune raison de créer les deux sous-types en utilisant l'héritage : aucun des deux sous-types ne possède d'attribut spécifique, et la présence d'une occurrence d'association "RQ" ou "SUB" suffit à savoir si le USER est submitter et/ou requester ;)

Citation:

---

Envoyé par escartefigue

Il me semble avoir déjà répondu à cette question dans le fil de discussion du MCD complet

---

Si je ne m'en rappelle pas, cela vient de mon problème de mémoire (très mauvaise) ...:aie:

Citation:

---

Envoyé par escartefigue

Quoi qu'il en soit, il n'y a aucune raison de créer les deux sous-types en utilisant l'héritage : aucun des deux sous-types ne possède d'attribut spécifique, et la présence d'une occurrence d'association "RQ" ou "SUB" suffit à savoir si le USER est submitter et/ou requester ;)

---

Si je donne un peu plus de détails :
Pièce jointe 604756
on voit qu'il y a une différence entre les 2 entités : USR_user_requester aura des clés étrangères que n'a pas USS_user_submitter, ce qui à mon avis justifie l'existence des 2 classes. Qu'en pensez-vous ?

Comme toujours, au niveau tabulaire, les clefs étrangères sont ajoutées coté "1" de l'association, donc dans la table issue de l'entité-type "TI_ticket"

Ce faisant, le MCD correct est celui-ci :

Pièce jointe 604794

Ce qui donne le script suivant pour MySQL :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

CREATE TABLE US_user( US_ident INT AUTO_INCREMENT, PRIMARY KEY(US_ident) );   CREATE TABLE TI_ticket( TI_ident INT AUTO_INCREMENT, US_ident_SU INT NOT NULL, US_ident_RQ INT NOT NULL, PRIMARY KEY(TI_ident), FOREIGN KEY(US_ident_SU) REFERENCES US_user(US_ident), FOREIGN KEY(US_ident_RQ) REFERENCES US_user(US_ident) );

---

Merci sauf que je ne vois pas comment faire apparaître les entités COU_country et OZ_organization avec les associations is_in_country et includes qui ne doivent être liées qu'à un requester. Pourriez-vous en tenir compte dans votre schéma ?

Pour autant que je me souvienne de nos échanges dans le fil de discussion principal, le pays et l'organisation de l'utilisateur ne sont communiqués que dans le fichier CSV du requester, pour autant il n'est pas faux d'attacher les associations au sur-type utilisateur : ce sont des informations pertinentes pour tous les types d'utilisateurs.

Même si dans un premier temps, seuls les requester auront l'info enregistrée, si demain les fichiers CSV évoluent pour ajouter l'info également pour les submitter (ou si vous souhaitez les ajouter par un autre moyen), vous serez prêts.

OK,
par contre je crois que dans ce cas, il faut affecter une valeur par défaut null à ces colonnes. Comme ce n'est pas prévu dans Looping, on utilise peut-être le champ complément, non ?

Je me suis dit qu'il suffisait de mettre une cardinalité 0-1, ce que j'ai fait :

Pièce jointe 604810
mais contrairement à ce que je pensais, Looping n'a pas mis de valeur par défaut null pour les 2 clés étrangères :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

CREATE TABLE US_user( US_ident INT UNSIGNED AUTO_INCREMENT, US_sesa INT, US_firstname VARCHAR(50), US_lastname VARCHAR(50), COU_ident INT UNSIGNED, OZ_ident INT UNSIGNED, PRIMARY KEY(US_ident), UNIQUE(US_sesa), FOREIGN KEY(COU_ident) REFERENCES COU_country(COU_ident), FOREIGN KEY(OZ_ident) REFERENCES OZ_organization(OZ_ident) );

---

Pourtant, pour les users de type submitter, les 2 clés étrangères seront à null, non ?

En effet, il faudra, lors de l'insertion dans US_user, utiliser "null" pour les colonnes concernées (COU_ident et OZ_ident)

OK,
sachant que je ne souhaite pas modifier à la main la création des tables SQL générée par Looping (presque sûr d'oublier de le faire le plus souvent), je prévois donc d'insérer null dans ces colonnes quand la table US_user ne sera pas liée aux tables COU_country et OZ_organization.