1. #1
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 974
    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 : 14 974
    Points : 28 810
    Points
    28 810
    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 : 70
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 966
    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 966
    Points : 6 525
    Points
    6 525
    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
    14 974
    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 : 14 974
    Points : 28 810
    Points
    28 810
    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 à 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 462
    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 462
    Points : 3 153
    Points
    3 153
    Billets dans le blog
    6

    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 966
    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 966
    Points : 6 525
    Points
    6 525
    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
    14 974
    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 : 14 974
    Points : 28 810
    Points
    28 810
    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 966
    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 966
    Points : 6 525
    Points
    6 525
    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
    14 974
    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 : 14 974
    Points : 28 810
    Points
    28 810
    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 966
    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 966
    Points : 6 525
    Points
    6 525
    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 : 13
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
    14 974
    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 : 14 974
    Points : 28 810
    Points
    28 810
    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 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 966
    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 966
    Points : 6 525
    Points
    6 525
    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

Discussions similaires

  1. Réponses: 2
    Dernier message: 14/06/2007, 13h11
  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, 11h05
  3. Réponses: 6
    Dernier message: 14/02/2007, 14h42
  4. Session selon le type d'utilisateur
    Par TomtomGesti dans le forum Sessions
    Réponses: 1
    Dernier message: 29/08/2006, 16h17
  5. Réponses: 18
    Dernier message: 08/12/2004, 14h04

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