IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

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


Sujet :

Schéma

  1. #1
    Expert confirmé
    Avatar de laurentSc
    Homme Profil pro
    Webmaster débutant perpétuel !
    Inscrit en
    Octobre 2006
    Messages
    10 339
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Webmaster débutant perpétuel !
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2006
    Messages : 10 339
    Points : 5 724
    Points
    5 724
    Billets dans le blog
    1
    Par défaut 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 :

    Nom : tickets.png
Affichages : 253
Taille : 22,2 Ko

    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 :

    Nom : ticket2.png
Affichages : 239
Taille : 23,9 Ko

    Merci de votre avis.
    Il vaut mieux viser la perfection et la manquer que viser l'imperfection et l'atteindre. - Bertrand Russell

    Si la discussion est résolue, merci de cliquer sur le bouton

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    Bonjour LaurentSC

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

    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

  3. #3
    Expert confirmé
    Avatar de laurentSc
    Homme Profil pro
    Webmaster débutant perpétuel !
    Inscrit en
    Octobre 2006
    Messages
    10 339
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Webmaster débutant perpétuel !
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2006
    Messages : 10 339
    Points : 5 724
    Points
    5 724
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    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) ...

    Citation Envoyé par escartefigue Voir le message
    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 :
    Nom : ticket2.png
Affichages : 246
Taille : 37,5 Ko
    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 ?
    Il vaut mieux viser la perfection et la manquer que viser l'imperfection et l'atteindre. - Bertrand Russell

    Si la discussion est résolue, merci de cliquer sur le bouton

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    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 SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    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)
    );

  5. #5
    Expert confirmé
    Avatar de laurentSc
    Homme Profil pro
    Webmaster débutant perpétuel !
    Inscrit en
    Octobre 2006
    Messages
    10 339
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Webmaster débutant perpétuel !
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2006
    Messages : 10 339
    Points : 5 724
    Points
    5 724
    Billets dans le blog
    1
    Par défaut
    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 ?
    Il vaut mieux viser la perfection et la manquer que viser l'imperfection et l'atteindre. - Bertrand Russell

    Si la discussion est résolue, merci de cliquer sur le bouton

  6. #6
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    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.

  7. #7
    Expert confirmé
    Avatar de laurentSc
    Homme Profil pro
    Webmaster débutant perpétuel !
    Inscrit en
    Octobre 2006
    Messages
    10 339
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Webmaster débutant perpétuel !
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2006
    Messages : 10 339
    Points : 5 724
    Points
    5 724
    Billets dans le blog
    1
    Par défaut
    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 ?
    Il vaut mieux viser la perfection et la manquer que viser l'imperfection et l'atteindre. - Bertrand Russell

    Si la discussion est résolue, merci de cliquer sur le bouton

  8. #8
    Expert confirmé
    Avatar de laurentSc
    Homme Profil pro
    Webmaster débutant perpétuel !
    Inscrit en
    Octobre 2006
    Messages
    10 339
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Webmaster débutant perpétuel !
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2006
    Messages : 10 339
    Points : 5 724
    Points
    5 724
    Billets dans le blog
    1
    Par défaut
    Je me suis dit qu'il suffisait de mettre une cardinalité 0-1, ce que j'ai fait :

    Nom : tickets.png
Affichages : 213
Taille : 34,0 Ko
    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 sql : Sélectionner tout - Visualiser dans une fenêtre à part
    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 ?
    Il vaut mieux viser la perfection et la manquer que viser l'imperfection et l'atteindre. - Bertrand Russell

    Si la discussion est résolue, merci de cliquer sur le bouton

  9. #9
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    En effet, il faudra, lors de l'insertion dans US_user, utiliser "null" pour les colonnes concernées (COU_ident et OZ_ident)

  10. #10
    Expert confirmé
    Avatar de laurentSc
    Homme Profil pro
    Webmaster débutant perpétuel !
    Inscrit en
    Octobre 2006
    Messages
    10 339
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Webmaster débutant perpétuel !
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2006
    Messages : 10 339
    Points : 5 724
    Points
    5 724
    Billets dans le blog
    1
    Par défaut
    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.
    Il vaut mieux viser la perfection et la manquer que viser l'imperfection et l'atteindre. - Bertrand Russell

    Si la discussion est résolue, merci de cliquer sur le bouton

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Quels logiciels de modélisation pour une base de données ?
    Par octopus dans le forum Décisions SGBD
    Réponses: 7
    Dernier message: 11/06/2023, 17h20
  2. Réponses: 2
    Dernier message: 03/06/2016, 19h20
  3. [MCD] Modélisation propriétaire-ancien propriétaire
    Par bobharris dans le forum Schéma
    Réponses: 9
    Dernier message: 18/11/2010, 03h36
  4. Propriétaire de dossier
    Par mixi dans le forum Langage
    Réponses: 4
    Dernier message: 23/01/2003, 15h15
  5. Réponses: 2
    Dernier message: 26/06/2002, 14h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo