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

Merise Discussion :

Avis sur une modélisation Merise


Sujet :

Merise

  1. #1
    Membre actif Avatar de Ethan 0x21
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Août 2006
    Messages
    120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Août 2006
    Messages : 120
    Points : 261
    Points
    261
    Par défaut Avis sur une modélisation Merise
    Bonjour tout le monde,


    Je souhaiterez avoir vos avis pour la réalisation d'un MCD :

    Les utilisateurs d'un logiciels peuvent êtres soit des étudiants, professeurs ou personnel administratif, ils possédent quasiments tous les même propriétées (login, nom, prénom, courriel, ...) et peuvent se connecter au logiciel (login, mot de passe), êtres des utilisateurs en somme.

    Ainsi je souhaiterai savoir lequel des scénarios suivants et selon vous le plus optimisé :

    -Création d'une seule entitée "Utilisateur" possédant une propriété "type" permettant de savoir s'il sagit d'un étudiant, professeur ou personnel administratif
    -Création de 3 entitées étudiant, professeur, personnel administratif redondantes donc avec une entitée login possédant les propriétées login et mot de passe et une relation vers chacunes des 3 autres entitées
    -Création d'une entitée utilisateur comportant une contrainte de génération vers les entitées étudiant, professeur, personnel administratif, même si que pour certaines de ces 3 entitées ne comportent aucunes propriétées.

    Car selon moi le premier scénarios et le plus simple, cependant vis à vis du MCD les choses s'embrouilles car il n'est plus question d'étudiant,professeurs, etc.. mais juste d'utilisateur...


    En vous remerciant par avance pour vos avis,

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir Ethan 0x21,


    Citation Envoyé par Ethan 0x21
    ils possédent quasiment tous les même propriétées (login, nom, prénom, courriel, ...)
    Ce sont justement les autres attributs (propriétés), ceux qui sont spécifiques à telle ou telle catégorie d'utilisateurs qui détermineront la modélisation. Quels sont-ils ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  3. #3
    Membre actif Avatar de Ethan 0x21
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Août 2006
    Messages
    120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Août 2006
    Messages : 120
    Points : 261
    Points
    261
    Par défaut
    Bonsoir fsmrel,

    En fait il sagit juste de la propriété numéro INE pour étudiant, cependant je préfére laisser une possibilité dans le futur de pouvoir ajouter nouvelles propriétées (pas beaucoups mais juste avoir la possibilité) en fonction des évolutions du logiciel, d'ou mes interrogations sur comment organiser ces 3 entitées (les regroupées en une super entitée 'utilisateur' avec une propriété discriminante ou creer 3 entitées avec des propriétées quasi-redondantes).

    Merci

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Spécialisation des entités-types
    Bonsoir Ethan,



    Dans votre cas, il faut en passer par la généralisation/spécialisation, ce qui donne lieu à la représentation suivante (cas de PowerAMC) :





    L’entité-type UTILISATEUR joue le rôle de surtype, tandis que les entités-types ETUDIANT, PROFESSEUR et ADMINISTRATIF jouent le rôle de sous-types, c'est-à-dire que ce sont des entités-types qui héritent des propriétés du surtype.

    Cette façon de procéder permet en outre d’établir les associations pertinentes entre les entités-types : si l’on doit savoir, par exemple, quels professeurs dispensent leur enseignement à quels élèves, les utilisateurs administratifs ne sont pas concernés, et l’association ENSEIGNER ne fera intervenir que les sous-types PROFESSEUR et ETUDIANT.

    NB. Noter les identifiants alternatifs : utilisateur_login, matricule et numero_ine.


    MLD dérivé du MCD :





    Du fait de l’héritage, L’AGL a recopié l’attribut utilisateur_id dans l’en-tête des tables ETUDIANT, PROFESSEUR et ADMINISTRATIF.


    Code SQL correspondant :

    
    CREATE TABLE UTILISATEUR 
    (
       utilisateur_id                   INT                      NOT NULL,
       utilisateur_nom                  VARCHAR(32)              NOT NULL,
       utilisateur_prenom               VARCHAR(32)              NOT NULL,
       utilisateur_login                VARCHAR(32)              NOT NULL,
       utilisateur_mot_de_passe         VARCHAR(32)              NOT NULL,
       CONSTRAINT UTILISATEUR_PK PRIMARY KEY (utilisateur_id),
       CONSTRAINT UTILISATEUR_AK UNIQUE (utilisateur_login)
    ) ;
    
    CREATE TABLE PROFESSEUR 
    (
       utilisateur_id                   INT                      NOT NULL,
       CONSTRAINT PROFESSEUR_PK PRIMARY KEY (utilisateur_id),
       CONSTRAINT PROFESSEUR_UTILISATEUR_FK FOREIGN KEY (utilisateur_id)
          REFERENCES UTILISATEUR (utilisateur_id) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE ETUDIANT 
    (
       utilisateur_id                   INT                      NOT NULL,
       numero_ine                       VARCHAR(16)              NOT NULL,
       CONSTRAINT ETUDIANT_PK PRIMARY KEY (utilisateur_id),
       CONSTRAINT ETUDIANT_AK UNIQUE (numero_ine),
       CONSTRAINT ETUDIANT_UTILISATEUR_FK FOREIGN KEY (utilisateur_id)
          REFERENCES UTILISATEUR (utilisateur_id) ON DELETE CASCADE
    ) ;
    
    CREATE TABLE ADMINISTRATIF 
    (
       utilisateur_id                   INT                      NOT NULL,
       matricule                        VARCHAR(16)              NOT NULL,
       date_embauche                    DATE                     NOT NULL,
       CONSTRAINT ADMINISTRATIF_PK PRIMARY KEY (utilisateur_id),
       CONSTRAINT ADMINISTRATIF_AK UNIQUE (matricule),
       CONSTRAINT ADMINISTRATIF_UTILISATEUR_FK FOREIGN KEY (utilisateur_id)
          REFERENCES UTILISATEUR (utilisateur_id) ON DELETE CASCADE
    ) ;
    
    

    Vous pouvez aussi créer des vues par sous-type, voire une vue globale :

    
    CREATE VIEW INDIVIDU_PROFESSEUR (professeur_id, nom, prenom, login, mot_de_passe) AS
        SELECT PROFESSEUR.utilisateur_id, utilisateur_nom, utilisateur_prenom, utilisateur_login, utilisateur_mot_de_passe 
        FROM   PROFESSEUR JOIN UTILISATEUR ON PROFESSEUR.utilisateur_id = UTILISATEUR.utilisateur_id    
    ;
    
    CREATE VIEW INDIVIDU_ETUDIANT (etudiant_id, nom, prenom, login, mot_de_passe, numero_ine) AS
        SELECT ETUDIANT.utilisateur_id, utilisateur_nom, utilisateur_prenom, utilisateur_login, utilisateur_mot_de_passe, numero_ine 
        FROM   ETUDIANT JOIN UTILISATEUR ON ETUDIANT.utilisateur_id = UTILISATEUR.utilisateur_id    
    ;
    
    CREATE VIEW INDIVIDU_ADMINISTRATIF (administratif_id, nom, prenom, login, mot_de_passe, matricule, date_embauche) AS
        SELECT ADMINISTRATIF.utilisateur_id, utilisateur_nom, utilisateur_prenom, utilisateur_login, utilisateur_mot_de_passe, matricule, date_embauche 
        FROM   ADMINISTRATIF JOIN UTILISATEUR ON ADMINISTRATIF.utilisateur_id = UTILISATEUR.utilisateur_id    
    ;
    
    CREATE VIEW INDIVIDU_TOUT (type_individu, individu_id, nom, prenom, login, mot_de_passe, numero_ine, matricule, date_embauche) AS
        SELECT 'étudiant', etudiant_id, nom, prenom, login, mot_de_passe, numero_ine, 'sans objet', 'sans objet' 
        FROM   INDIVIDU_ETUDIANT  
    
        UNION
    
        SELECT 'professeur', professeur_id, nom, prenom, login, mot_de_passe, 'sans objet', 'sans objet', 'sans objet' 
        FROM   INDIVIDU_PROFESSEUR    
    
        UNION
        
        SELECT 'administratif', administratif_id, nom, prenom, login, mot_de_passe, 'sans objet', matricule, CAST(date_embauche AS CHAR(10))   
        FROM   INDIVIDU_ADMINISTRATIF 
    ;
    
    

    Un début de jeu d’essai :

    
    
    INSERT INTO UTILISATEUR (utilisateur_id, utilisateur_nom, utilisateur_prenom, utilisateur_login, utilisateur_mot_de_passe) VALUES
        (1, 'Naudin', 'Fernand', 'naudin', '********')     
      , (2, 'Volfoni', 'Raoul', 'volfor', '********') 
      , (3, 'Volfoni', 'Paul', 'paulo', '********') 
      , (4, 'Filoselle', 'Aristide', 'filo', '********') 
      , (5, 'Haddock', 'Archibald', 'millesabords', '********') 
      , (6, 'Tournesol', 'Tryphon', 'fonfon', '********') 
      , (7, 'Lampion', 'Séraphin', 'serapion', '********') 
      , (8, 'Trancène', 'Jean', 'jeannot', '********') 
    ;    
    
    INSERT INTO PROFESSEUR (utilisateur_id)  VALUES (1), (2), (3) ;
    
    INSERT INTO ETUDIANT (utilisateur_id, numero_ine)  VALUES (4, 'ine01'), (5, 'ine02'), (6, 'ine03') ;
    
    INSERT INTO ADMINISTRATIF (utilisateur_id, matricule, date_embauche)  VALUES (7, 'jb_007', '2010-01-01'), (8, 'gf_001', '2010-01-03') ;
    
    

    Exemple : Qui sont les professeurs ?

    
     SELECT * FROM INDIVIDU_PROFESSEUR ;   
    
    
    =>

    
    professeur_id    nom       prenom     login     mot_de_passe
    -------------    ------    -------    ------    ------------
    1                Naudin    Fernand    naudin    ********
    2                Volfoni   Raoul      volfor    ********
    3                Volfoni   Paul       paulo     ********
    
    

    Vue globale :

    
     SELECT * FROM INDIVIDU_TOUT ;   
    
    
    =>

    
    type_individu    individu_id    nom          prenom      login           mot_de_passe    numero_ine    matricule     date_embauche
    -------------    -----------    ---------    --------    ------------   -------------    --------- 
    professeur       1              Naudin       Fernand     naudin          ********        sans objet    sans objet    sans objet
    professeur       2              Volfoni      Raoul       volfor          ********        sans objet    sans objet    sans objet
    professeur       3              Volfoni      Paul        paulo           ********        sans objet    sans objet    sans objet
    étudiant         4              Filoselle    Aristide    filo            ********        ine01         sans objet    sans objet
    étudiant         5              Haddock      Archibald   millesabords    ********        ine02         sans objet    sans objet
    étudiant         6              Tournesol    Tryphon     fonfon          ********        ine03         sans objet    sans objet
    administratif    7              Lampion      Séraphin    serapion        ********        sans objet    jb_007        2010-01-01
    administratif    8              Trancène     Jean        jeannot         ********        sans objet    gf_001        2010-01-03
    
    


    Prévoir un trigger pour interdire qu’un étudiant soit aussi professeur ou administratif, etc.


    Quel est votre SGBD ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  5. #5
    Membre actif Avatar de Ethan 0x21
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Août 2006
    Messages
    120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Août 2006
    Messages : 120
    Points : 261
    Points
    261
    Par défaut
    Bonjour fsmrel,


    Tout d'abord merci pour cette explication fournie et trés didactique, je vois mieux en effet maintenant que le plus rationnel est de rassembler les propriétées communes et mettre celles 'spécialisées' dans des entitées à part, qui reçoivent une FK de l'entitée mére (et non tout ses attributs en doublon).

    Vis à vis du SGBD il sagit de MySQL


    En vous remerciant encore.

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

Discussions similaires

  1. Votre avis sur une proposition de job
    Par plex dans le forum Emploi
    Réponses: 7
    Dernier message: 18/01/2007, 10h11
  2. Votre avis sur une proposition de CDI!
    Par wapit dans le forum Emploi
    Réponses: 13
    Dernier message: 22/07/2005, 13h41
  3. [Programmation distribuée] Votre avis sur une archi
    Par Acarp47 dans le forum Plateformes (Java EE, Jakarta EE, Spring) et Serveurs
    Réponses: 7
    Dernier message: 29/06/2005, 14h01
  4. Votre avis sur une bannière animée developpez.com
    Par Marc Lussac dans le forum Evolutions du club
    Réponses: 14
    Dernier message: 02/02/2005, 07h52

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