1. #1
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 182
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 182
    Points : 29 313
    Points
    29 313
    Billets dans le blog
    4

    Par défaut Héritage d'utilisateur et type d'utilisateur

    Bonjour,

    J'ai, d'une part, créé des héritages de utilisateur vers administrateur, professeur et élève, chacun de ces types d'utilisateur ayant des possibilités différentes sur les données (un prof peut créer un cours, un élève seulement s'y inscrire...).
    Pour autant, un prof peut très bien être un élève dans une autre matière que la sienne ou un élève peut devenir prof. Ce n'est donc pas un héritage exclusif.

    D'autre part, dans l'application, un type d'utilisateur accèdera à certaines fonctions mais pas à toutes.

    Voilà l'extrait de mon MCD actuel, fais avec JMerise :
    Nom : Capture_MCD_utilisateur_heritage_et_type.png
Affichages : 166
Taille : 37,6 Ko

    Ce MCD permet à un élève d'être de type prof ou même administrateur.

    Comment puis-je représenter la contrainte spécifiant que le type de l'utilisateur matérialisé par tj_ttu_typer_uti_ttu corresponde à l'un des trois héritages ?
    Et comment le matérialiser dans la BDD (Postgresql) ? Par un trigger ? Une assertion ?
    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 !

  2. #2
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 996
    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 : 2 996
    Points : 6 582
    Points
    6 582
    Billets dans le blog
    1

    Par défaut

    Bonsoir Cinephil

    Dans l'absolu qu'un élève puisse être également enseignant voire administrateur n'est pas forcément une aberration, du coup je pose l'incontournable question : quelles sont les règles de gestion ?

    Dans l'attente, j'aurai tendance à dire que chaque personne possède un rôle pour un cours ce qui conduirait à une relation à 3 pattes entre personne, cours et rôle

    En ce cas, ce serait la présence d'une occurrence de relation en tant qu'admin, qui autoriserait telle personne à avoir des droits étendus sur tel cours

  3. #3
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 182
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 182
    Points : 29 313
    Points
    29 313
    Billets dans le blog
    4

    Par défaut

    Escartefigue, ce n'est pas tout à fait ça ma problématique.

    D'un côté, il y a les différents rôles que peut avoir un utilisateur en utilisant l'application, ce qui lui donnera accès à différents menus et fonctions de l'application. C'est la partie basse de mon extrait de schéma.
    Ainsi, un utilisateur peut être :
    - seulement élève ;
    - seulement prof ;
    - élève et prof (parce qu'un prof dans une matière peut avoir envie de suivre un cours dans une autre matière) ;
    - élève et admin (parce qu'un admin a bien le droit de s'inscrire à un cours, après tout !) ;
    - prof et admin (parce qu'un admin peut avoir des compétences pour être prof dans une matière ou devenir admin après avoir été prof et rester prof sur sa matière tout en accédant aux fonctions d'admin).

    De l'autre côté il y a ce que font réellement les profs et les élèves sur le site (délivrer un cours, suivre un cours, proposer des exercices et les corriger, répondre aux exercices relatifs au cours...). C'est la partie héritage de mon schéma qui différencie les associations avec les autres données (cours, exercices...).

    Maintenant, si Jean Dupont est seulement élève et n'a accès qu'aux fonctions pour les élèves (il sera donc identifié dans th_eleve_elv), rien n'interdit dans mon schéma qu'il soit, par une manip accidentelle sur la BDD en fait enregistré dans tj_typer_uti_ttu en tant que prof ou admin et voit apparaitre les fonctions réservées aux profs ou aux admins.
    Inversement, si l'utilisateur Jean Dupont est déclaré en tant qu'élève dans tj_typer_uti_ttu mais ne figure pas dans th_eleve_elv, il aura accès aux fonctions des élèves mais ça pourra planter parce que ses données ne seraient pas en association avec th_eleve_elv.

    Donc, ma première question est :
    Comment représenter dans mon MCD la contrainte qui oblige un utilisateur de tel type de figurer également dans le bon héritage correspondant à ce type ?

    Ou bien y a t-il un autre moyen de modéliser ces deux aspects des choses pour empêcher une incohérence de données.

    Ma seconde question qui sort du cadre du forum schéma est :
    Que dois-je utiliser dans Postgresl pour formaliser cette contrainte ? Trigger(s) ? Assertion(s) ? Contraintes CHECK ?

    Bien entendu, mon programme applicatif va bien faire les choses mais il peut arriver n'importe quoi qui contourne l'application et empêche le bon enregistrement des données en BDD par l'application.

    Pour le moment, c'est simple ; je commence le développement et je suis tout seul et serai admin et prof. Mais j'espère qu'il y aura très vite d'autres profs (qui ne seront pas admins) et surtout qu'il y aura des élèves intéressés par mon site. Si mon concept fonctionne, j'aurai sans doute des cas de profs voulant aussi être élève, d'élèves devenant prof. Et le site a du succès, j'aurai besoin d'autres admins qui pourront être choisis parmi les profs et/ou les élèves. Voilà pourquoi je veux blinder ça dès le départ.
    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 !

  4. #4
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Recherche, formation, développement
    Inscrit en
    août 2006
    Messages
    1 467
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Mali

    Informations professionnelles :
    Activité : Recherche, formation, développement

    Informations forums :
    Inscription : août 2006
    Messages : 1 467
    Points : 3 169
    Points
    3 169
    Billets dans le blog
    7

    Par défaut

    Salut
    Citation Envoyé par CinePhil Voir le message
    - élève et prof (parce qu'un prof dans une matière peut avoir envie de suivre un cours dans une autre matière) ;
    - élève et admin (parce qu'un admin a bien le droit de s'inscrire à un cours, après tout !) ;
    - prof et admin (parce qu'un admin peut avoir des compétences pour être prof dans une matière ou devenir admin après avoir été prof et rester prof sur sa matière tout en accédant aux fonctions d'admin).
    ...
    En dehors de la fonctionnalité utilisateurs et droits comment le schéma répond-il à ces problématiques.
    Je suppose que prof, admin et élève héritent d'une table personne. A mon humble avis, c'est à cette dernière qu'il faut s'attaquer pour résoudre le problème.
    Pour moi je lie la table tuser à la table personne tout en ajoutant le champs (ou colonne si vous préférez) naturepersonne(=élève, prof, ou admin).
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  5. #5
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 996
    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 : 2 996
    Points : 6 582
    Points
    6 582
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    De l'autre côté il y a ce que font réellement les profs et les élèves sur le site (délivrer un cours, suivre un cours, proposer des exercices et les corriger, répondre aux exercices relatifs au cours...). C'est la partie héritage de mon schéma qui différencie les associations avec les autres données (cours, exercices...).
    C'est cette remarque qui me perturbe.
    A mon sens, un utilisateur est par exemple professeur, par ce que on l'a reconnu en tant que tel et donc accordé les droits qui vont avec, peu importe qu'il exerce véritablement son professorat ou non.
    En d'autres termes, ouvrir les droits "professeur d'histoire" à l'utilisateur "dupond" doit suffire à considérer que dupond intervient en tant que professeur dans la matière histoire
    A priori, sauf si le MCD fourni n'est qu'une ébauche, il n'y a aucun attribut spécifique lié aux sous-types, du coup ces sous-types ne sont plus nécessaires.
    Ensuite, pour vérifier que l'utilisateur "dupond" a le droit de rédiger ou corriger un cours d'histoire, il faut poser une CIF de la relation "rédiger" ou "corriger" vers la relation entre cet utilisateur et la matirère pour laquelle il est professeur.
    Cette CIF se résoudra par une contrainte de type "reference"

  6. #6
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 182
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 182
    Points : 29 313
    Points
    29 313
    Billets dans le blog
    4

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    C'est cette remarque qui me perturbe.
    A mon sens, un utilisateur est par exemple professeur, par ce que on l'a reconnu en tant que tel et donc accordé les droits qui vont avec, peu importe qu'il exerce véritablement son professorat ou non.
    En d'autres termes, ouvrir les droits "professeur d'histoire" à l'utilisateur "dupond" doit suffire à considérer que dupond intervient en tant que professeur dans la matière histoire
    Je pars du principe que la BDD doit interdire à l'élève Durand de créer un cours s'il n'est pas également typé en tant que professeur.
    L'héritage, dans mon schéma, sert à dire que c'est le prof Dupont qui a créé le cours et l'élève Durand qui s'y est inscrit.


    A priori, sauf si le MCD fourni n'est qu'une ébauche, il n'y a aucun attribut spécifique lié aux sous-types, du coup ces sous-types ne sont plus nécessaires.
    1) Ils sont nécessaires parce qu'ils ont des associations différentes.
    2) Il est fort probable que j'aie besoin de la date de naissance de l'élève pour avoir une idée de sa capacité en terme de compréhension des exercices qui lui seront proposés, et que j'aie par ailleurs besoin d'enregistrer le tarif du professeur ou d'autres informations spécifiques aux professeurs. Pour le moment, il est vrai que l'héritage vers administrateur est inutile et il est possible que ça le reste.

    Ensuite, pour vérifier que l'utilisateur "dupond" a le droit de rédiger ou corriger un cours d'histoire, il faut poser une CIF de la relation "rédiger" ou "corriger" vers la relation entre cet utilisateur et la matirère pour laquelle il est professeur.
    Cette CIF se résoudra par une contrainte de type "reference"
    Ça c'est un autre sujet.
    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 !

  7. #7
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 996
    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 : 2 996
    Points : 6 582
    Points
    6 582
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    Je pars du principe que la BDD doit interdire à l'élève Durand de créer un cours s'il n'est pas également typé en tant que professeur.
    L'héritage, dans mon schéma, sert à dire que c'est le prof Dupont qui a créé le cours et l'élève Durand qui s'y est inscrit.
    Citation Envoyé par escartefigue Voir le message
    Ensuite, pour vérifier que l'utilisateur "dupond" a le droit de rédiger ou corriger un cours d'histoire, il faut poser une CIF de la relation "rédiger" ou "corriger" vers la relation entre cet utilisateur et la matirère pour laquelle il est professeur.
    Cette CIF se résoudra par une contrainte de type "reference"
    Ça c'est un autre sujet.
    J'ai du mal à suivre, ou alors je me suis mal exprimé
    Dans ma proposition, avec la contrainte "référence" il est impossible à l'élève "durand" de créer un cours dans lequel il n'est pas professeur.

    Citation Envoyé par CinePhil Voir le message
    1) Ils sont nécessaires parce qu'ils ont des associations différentes.
    Comme les associations n'apparaissaient pas dans l'extrait commniqué, j'ai supposé que c'étaient justement celles requises pour "rédiger", "corriger" etc...
    Dans ma proposition, ces associations sont attachées directement à l'utilisateur, sans besoin de sous-type, et c'est la CIF qui règle le sujet

  8. #8
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 182
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 182
    Points : 29 313
    Points
    29 313
    Billets dans le blog
    4

    Par défaut

    Donc tu supprimerais les héritages et tu mettrais une CIF par association entre utilisateur et cours, exercice...
    Les héritages rendent inutiles ces CIF là, justement !

    Bon, pas très grave si la représentation n'est pas possible. À moi de développer ça correctement.
    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 !

  9. #9
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 996
    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 : 2 996
    Points : 6 582
    Points
    6 582
    Billets dans le blog
    1

    Par défaut

    Voilà c'est ça : je n'utilise que des CIF, plus besoin d'héritage
    Bien sur, applicable seulement si les relations qui n'apparaissent pas sur l'extrait du modèle, ont bien des identifiants communs et qui constituent une clef unique dans la table issue de la relation cible de la contrainte

    Exemple ci-dessous : j'utilise l'id relative du cours par rapport à la matière pour pouvoir vérifier que l'utilisateur qui rédige un cours est bien enseignant pour la matière concernée par le cours

    Nom : MCD01.png
Affichages : 96
Taille : 21,0 Ko

  10. #10
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 182
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 182
    Points : 29 313
    Points
    29 313
    Billets dans le blog
    4

    Par défaut

    Ce n'est pas exactement comme ça que je modéliserais...
    Dans mon projet, un utilisateur élève ne suit pas (ne s'inscrit pas à) une matière mais un cours et ce cours concerne effectivement une matière (quoique il n'est pas impossible qu'il y ait des cours concernant plusieurs matières ; c'est même fort probable).

    Votre CIF empêche un prof non enseignant d'une matière de rédiger un cours dans cette matière mais ce n'est pas le problème que j'expose.
    Votre schéma n'interdit pas un utilisateur de type élève seulement (pas prof, donc) de rédiger un cours. Pour aller loin, un bambin de huit ans pourrait être enregistré en tant que rédacteur d'un cours de maths de niveau master.

    Moi il me faut une sorte de cif qui empêche ça. En règle de gestion, la contrainte en langage commun serait celle-ci :
    Seul un utilisateur de type prof peut rédiger un cours, proposer un exercice et le corriger.

    Avec l'héritage, je suis sûr que le rédacteur sera un prof mais ce dont je veux m'assurer est que l'identifiant du prof dans th_professeur_prf soit bien associé à l'identifiant du type professeur dans tj_tyu_typer_uti_ttu.
    C'est ça que je souhaite représenter sur le MCD si c'est possible symboliquement (sinon une note suffira) et je m'interroge aussi sur la technique à mettre en oeuvre dans la BDD pour implémenter cette contrainte (assertion, trigger, check... ?).
    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 !

  11. #11
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 996
    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 : 2 996
    Points : 6 582
    Points
    6 582
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    Votre CIF empêche un prof non enseignant d'une matière de rédiger un cours dans cette matière mais ce n'est pas le problème que j'expose.
    Votre schéma n'interdit pas un utilisateur de type élève seulement (pas prof, donc) de rédiger un cours. Pour aller loin, un bambin de huit pourrait être enregistré en tant que rédacteur d'un cours de maths de niveau master.
    Non : avec ce modèle le MLD donne les tables et contraintes suivantes
    Cours : (MA_id, CO_id)
    constraint MA_id references matiere(MA_id)
    Rediger : (UT_id, MA_id, CO_id)
    constraint UT_id references utilisateur(ut_id)
    constraint MA_id, CO_id references cours(ma_id, co_id)
    constraint ma_id, ut_id references enseigner (ma_id, ut_id)
    Enseigner : (UT_id, MA_id)

    Mon modèle vérifie bien (ce que j'ai mis en rouge) que seul un utilisateur présent dans la relation enseigner pour la matière peut rédiger un cours de cette matière
    Du coup un élève non prof ne peut jamais rédiger de cours, seul un prof de la bonne matière peut le faire


    Mais le souci est que les cours peuvent être multi-matière du coup ça ne tient plus car je ne peux plus identifier un cours relativement à la matière
    Je n'ai pas le temps d'y réfléchir ce soir, j'essaye de reprendre le sujet demain

  12. #12
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 996
    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 : 2 996
    Points : 6 582
    Points
    6 582
    Billets dans le blog
    1

    Par défaut

    J'avoue ne pas arriver à trouver de solution via la modélisation à cause du cours multi-matière
    Si cette règle est incontournable, je sèche

  13. #13
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 996
    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 : 2 996
    Points : 6 582
    Points
    6 582
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    J'avoue ne pas arriver à trouver de solution via la modélisation à cause du cours multi-matière
    Si cette règle est incontournable, je sèche
    Quoi-que, je reviens à la charge car

    Si un cours est multi-matière
    Si seul un prof qualifié pour une matière peut rédiger un cours
    Alors il faut potentiellement deux profs pour rédiger le cours (sauf si, cas particulier, le prof enseigne les deux matières ce qui ne change rien à ma proposition)
    Du coup, on peut considérer qu'il s'agit en fait de deux cours, qu'on peut associer par une nouvelle relation pour matérialiser qu'ils sont enseignés ensemble dans une même unité de temps et dans un même lieu (relation avec une cardinalité mini de zéro bien sur)

    Avec cette proposition, mon schéma qui précède répond au besoin

  14. #14
    Modérateur

    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    août 2007
    Messages
    792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : août 2007
    Messages : 792
    Points : 1 955
    Points
    1 955

    Par défaut

    Bonsoir à tous,

    Mon avis est à l'inverse de celui d'escartefigue.

    Mais avant d'en parler, revenons à la problématique. Philippe, tu veux associer chacune des occurrences d'une entité (ta_type_utilisateur_tyu) à une entité (th_eleve_elv, th_professeur_prf, ...) Et bien, ce n'est pas prévu. A ma connaissance, seuls deux auteurs ont avancé dans cette voie : Yves Tabourier dans "De l'autre côté de MERISE" et José MOREJON dans "Merise vers une modélisation orientée objet".

    Ce dernier propose la modélisation d'un lien de type "est occurrence de" représenté par un triangle évidé au milieu du lien : [ S ]----|>----[ C ] ; S étant par ailleurs la spécialisation d'une entité G liée à C (entité critère) par une association de typage. Pour faire un parallèle avec ton schéma :

    • G correspond à th_utilisateur_uti
    • S correspond à th_eleve_elv, etc.
    • C correspond à ta_type_utilisateur_tyu

    Mais ces deux auteurs en restent au stade de la modélisation sans envisager l'implémentation en bdd.


    Pour en revenir à mon avis, je pense que l'entité ta_type_utilisateur_tyu est superflue. Sa suppression du MCD résoud tous les problèmes.
    1) Les types d'un utilisateur sont donnés par leur présence dans les entités spécialisées
    2) Tu ne peux plus avoir d'incohérence entre le type d'un utilisateur et sa présence dans une entité spécialisée ou une autre.
    3) Lorsque tu veux savoir si un utilisateur est élève, tu interroges l'entité Elève (oui, je raccourcis tes noms d'entités qui sont un peu longs à écrire ), idem pour les professeurs.

    Quant à savoir quels sont leurs droits, les entités associées à chacune des entités Elève, Professeur et Admin sont suffisantes pour celà.
    Par exemple : "seul un professur est habilité à rédiger un cours". Cette règle est implémentée en créant une occurrence d'association ("rédiger") entre Professeur et Cours. Par conséquent, il est impossible qu'un élève rédige un cours puisqu'on ne peut pas créer cette occurrence d'association.
    Modérateur du forum Schéma

    N'oubliez pas de consulter les Cours Merise et la F.A.Q. Merise
    _______________________________________________________

    Les Règles du Club Developpez.com
    Vous avez votre réponse ? Merci de cliquer sur

  15. #15
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    15 182
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 15 182
    Points : 29 313
    Points
    29 313
    Billets dans le blog
    4

    Par défaut

    je pense que l'entité ta_type_utilisateur_tyu est superflue.
    Elle sert, par son association avec ta_fonction_fct à ouvrir des droits sur les fonctions du logiciel selon le type d'utilisateur.
    Si je la supprime, comment je fais pour savoir que l'utilisateur Professeur Dupont a accès aux fonctions des profs ?

    La partie basse de mon schéma permet de gérer les accès aux fonctions de l'application selon le type d'utilisateur.
    La partie haute concerne les actions concrètes des utilisateurs (créer un cours, un exercice, suivre un cours, répondre à un exercice...).

    Encore une fois, j'aimerais empêcher, dans la BDD, un utilisateur seulement élève d'être enregistré en tant que créateur de cours ou d'exercices. Comme il est possible que je programme des procédures SQL pour tout ce qui touche au DML, la procédure de création d'un cours pourra vérifier que le prof créateur est bien un utilisateur de type prof. Ou bien la procédure de création d'un prof peut aussi créer automatiquement l'association entre l'utilisateur et son type prof.
    La représentation de cette contrainte sur le schéma est finalement un aspect secondaire. Si ce n'est pas représentable, tant pis.
    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 !

  16. #16
    Modérateur

    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    août 2007
    Messages
    792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : août 2007
    Messages : 792
    Points : 1 955
    Points
    1 955

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    Si je la supprime, comment je fais pour savoir que l'utilisateur Professeur Dupont a accès aux fonctions des profs ?
    Tu sélectionnes les lignes de la table Professeur avec l'identifiant de Dupont.
    Si une ligne est sélectionnée, c'est un prof.
    Si aucune ligne n'est sélectionnée, ce n'est pas un prof.
    Modérateur du forum Schéma

    N'oubliez pas de consulter les Cours Merise et la F.A.Q. Merise
    _______________________________________________________

    Les Règles du Club Developpez.com
    Vous avez votre réponse ? Merci de cliquer sur

Discussions similaires

  1. Réponses: 2
    Dernier message: 14/06/2007, 14h11
  2. Créer un contrôle utilisateur de type "openFileDialog"
    Par pavicf dans le forum Windows Forms
    Réponses: 3
    Dernier message: 02/03/2007, 12h05
  3. Réponses: 6
    Dernier message: 14/02/2007, 15h42
  4. Session selon le type d'utilisateur
    Par TomtomGesti dans le forum Sessions
    Réponses: 1
    Dernier message: 29/08/2006, 17h17
  5. Réponses: 18
    Dernier message: 08/12/2004, 15h04

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