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

  1. #1
    Membre à l'essai
    Double relation, comment dois-je aborder le problème?
    Bonsoir à tous,

    Je suis face à un problème (qui est probablement une erreur d’interprétation de ma part) que je n'arrive pas à résoudre.

    J'ai produit le mcd suivant:



    Le soucis se situe au niveau de la relation entre l'entité "utilisateur" et l'entité "formation irl". En effet, la relation actuelle représente un "crud" réalisable en fonction des droits de l'utilisateur. La cardinalité 1.1 est justifiée par le faite qu'il n'y a un qu'une seule personne qui aura le droit nécessaire pour "crud" une formation tandis que la cardinalité 0,1 dit qu'il peut y avoir au minimum aucune personne qui "crud" ou maximum une (la seule ayant les droits nécessaire).

    Donc deux questions me chiffonnent.

    1. Une relation 1.1 - 0.1 est-elle correct? Car cela me semble "bizarre".
    2. Ces cardinalités fonctionnent pour une relation "ajouter" mais on pourrait y mettre une relation "consulter", qui changerais les cardinalités car plusieurs personnes auraient les droits nécessaire. Peut-on ajouter plusieurs relations différentes entre deux entités? Et si non, comment choisir laquelle modéliser?


    Je suis conscient que je pose probablement des questions ridicule mais je suis en phase d'apprentissage donc veuillez m'excuser.

    Mille merci d'avance


    [EDIT]

    Plus je relis le mcd et plus je me dis qu'il est complètement faux. Je pense que, par exemple, la relation qui me pose problème ne doit tout simplement pas exister!
    Je vais quand même attendre vos retours.

  2. #2
    Modérateur

    Bonjour,

    Votre association "ajouter" entre "Utilisateur" et "Formation irl" est issue de la règle de gestion suivante :
    Une formation irl est ajoutée par un seul utilisateur et un utilisateur peut ajouter plusieurs formations irl.

    Est-ce la bonne ?

    En effet, la relation actuelle représente un "crud" réalisable en fonction des droits de l'utilisateur. La cardinalité 1.1 est justifiée par le faite qu'il n'y a un qu'une seule personne qui aura le droit nécessaire pour "crud" une formation

    Dans votre MCD, il n'y a pas de lien entre la partie gestion des droits et les formations irl.

    On peut comprendre, par votre MCD, que tout utilisateur étant d'un rôle qui a le droit d'ajouter des formations irl pourra être acteur de l'association Ajouter.
    => Il n'y a donc, a priori, pas une seule personne capable de faire ça, sauf si, dans la pratique, vous n'attribuez le droit d'ajouter une formation irl à un seul rôle tenu par une seule personne.

    tandis que la cardinalité 0,1 dit qu'il peut y avoir au minimum aucune personne qui "crud" ou maximum une (la seule ayant les droits nécessaire).
    Votre association "Ajouter" ne comprend pas cette cardinalité !

    1. Une relation 1.1 - 0.1 est-elle correct? Car cela me semble "bizarre".
    C'est tout à fait possible.
    Soit l'association suivante :
    A -1,1----associer----0,1- B

    Elle est issue de la règle de gestion suivante :
    A est associé à un seul B et B peut être associé à un seul A.

    Dans votre association "Ajouter", si vous remplacez 0,n par 0,1, cela voudra dire qu'un utilisateur ne peut ajouter qu'une seule formation irl.

    2. Ces cardinalités fonctionnent pour une relation "ajouter" mais on pourrait y mettre une relation "consulter", qui changerais les cardinalités car plusieurs personnes auraient les droits nécessaire. Peut-on ajouter plusieurs relations différentes entre deux entités?
    Oui, bien sûr !

    Vous pouvez tout à fait ajouter une association Consulter qui répond à la règle de gestion suivante :
    Un utilisateur peut consulter plusieurs formation irl et une formation irl peut être consultée par plusieurs utilisateurs.

    Ce qui donne le MCD suivant :
    Utilisteur -0,n----consulter----0,n- formation_irl

    Plus je relis le mcd et plus je me dis qu'il est complètement faux. Je pense que, par exemple, la relation qui me pose problème ne doit tout simplement pas exister!
    Non, votre association "Ajouter" est pertinente tel quel. Ce qui serait plus surprenant, ce serait l'association "Consulter", à moins que vous ne souhaitiez enregistrer toutes les consultations des formations irl par les utilisateurs. À vous de voir si c'est utile ou pas.

    Par contre, quelques remarques pour finir...

    1) Proscrivez les noms d'entités-types avec des espaces, les caractères accentués, diacritiques ou spéciaux
    Vous utilisez un logiciel de modélisation et il est probable que vous générerez le code SQL de votre BDD avec ce logiciel... et les noms d'objets de base de données avec un espace... y'en a qu'on essayé ; ils ont eu des problèmes !
    Donc, par exemple : "Formation irl" doit devenir "Formation_Irl" ou "FormationIrl".

    2) Vous avez une boucle qui peut être gênante.
    Entre Utilisateur, Formation_Irl et Catalogue_Formation, vous pouvez avoir un utilisateur qui ajoute une formation dans un catalogue dont il n'est pas administrateur. Pourquoi pas ? Mais à vérifier si c'est conforme aux spécifications.

    3) Nommez vos entités-types au singulier.
    Vous l'avez fait semble t-il partout, sauf pour Roles.
    Les entités-types sont issues des règles de gestion. Ces dernières décrivent ce qui se passe dans l'association pour UN exemplaire de l'entité-type. Regardez les règles que j'ai écrites plus haut et le billet de blog que j'ai consacré à ce sujet.


    Rassurez vous ; votre MCD n'est pas mal du tout, pour un débutant !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

###raw>template_hook.ano_emploi###