[MCD] Modélisation Cas Université

[fcmelina]

Bonjour,

Pourriez vous m'aider à résoudre ce problème, j'avoue que j'ai beaucoup de difficultés.

Enoncé du problème:
Dans la base de données modélisant une université, on stocke les données concernant des étudiants et des professeurs.
Les étudiants ont un nom, un âge, un sexe, une ville et un pays de naissance, une ville et un pays d'habitation, les villes et les pays où ils ont habité avant (avec le nombre d'années pendant lesquelles ils y vivaient), les cours suivis avec le code, l'intitulé, le professeur, la date et la note obtenue.
Pour les cours de l'année en cours, on stocke aussi les jours, heure et salle où ils ont lieu et les étudiants inscrits (chaque cours a lieu au plus une fois par jour). Pour les étudiant en maîtrise, on stocke le nom du professeur tuteur et le nombre d'UV obtenues les années précédentes. Pour les étudiants de 3ème cycle, on note le thème et le domaine de recherche étudiés.
Enfin, chaque professeur est caractérisé par un nom, un âge, une ville et un pays de naissance, le nom de leur département, le numéro de téléphone du département, son titre, son statut marital, son domaine de recherche.
Modéliser cette base en utilisant au mieux les possibilités du modèle E-E-R.

Merci par avance pour votre aide précieuse me donnant les bases nécessaire pour réaliser ce modèle.

Cordialement,

[fsmrel]

Bonjour fcmelina,

Vous auriez dû proposer un 1er jet du modèle issu de vos réflexions...

Pour vous aider, je dirais qu’entre autres choses, on vous demande de procéder à la généralisation/spécialisation des entités-types : les étudiants et les professeurs partagent un certain nombre de propriétés que l’on peut donc factoriser ; nom, date de naissance, ville de naissance, pays.

Une esquisse de représentation à l’aide de Power AMC, montrant les données qui sont factorisables et celles qui ne le sont pas :



On a factorisé les attributs, mais certaines associations le sont aussi, car les villes et les pays donnent lieu à des entités-types de plein droit :




Je vous invite à nous proposer la suite. C'est comme pour remonter les casiers à homards, il suffit de tirer sur le boute et viennent de belles pièces (quitte parfois à se ramasser un gros queue d'ale, mais on n'a rien sans rien)...

[fcmelina]

Bonjour,

Je n'ai pas encore appris la factorisation des attributs, pouvez-vous m'expliquer simplement comment avez vous fait pour la partie Personne -> Etudiant / professeurs?

Merci par avance

[fcmelina]

[IMG]G:\capture.jpg[/IMG]

Merci pour les réponse, voici mon modelé (en PJ : Capture.jpg)

Ce que je n'arrive pas à modéliser, c'est :

- les villes et les pays où ils ont habité avant (avec le nombre d'années pendant lesquelles ils y vivaient)
- la note obtenue.

Merci par avance pour votre aide

[fsmrel]

Je réponds déjà au message #3.

L’entité-type (surtype) PERSONNE comporte les attributs communs aux étudiants et aux professeurs. L’entité-type (sous-type) ETUDIANT comporte les attributs qui caractérisent seulement les étudiants, tandis que l’entité-type (sous-type) PROFESSEUR comporte les attributs qui caractérisent seulement les professeurs.
Les associations valant pour les deux types de personnes sont établies au niveau PERSONNE, celles qui valent seulement pour les étudiants sont établies au niveau ETUDIANT (exemple : ville de résidence) et celles qui valent seulement pour les professeurs sont établies au niveau PROFESSEUR (département de rattachement par exemple).

La représentation graphique parle d’elle-même (il y en a d’autres, voir par exemple la FAQ Merise). La lunule permet d’établir la connexion entre le surtype PERSONNE et les sous-types ETUDIANT et PROFESSEUR. A noter la contrainte d’exclusion (symbolisée par la croix dans la lunule) et celle de totalité (symbolisée par le soulignement de la lunule) :

— Une personne ne peut pas être à la fois étudiant et professeur (exclusion ) ;
— Il n’y a pas d’autres types de personnes que les étudiants et les professeurs (totalité ).

A noter que les sous-types héritent des propriétés du surtype, c’est pourquoi il n’est nul besoin de définir d’identifiant particulier pour ETUDIANT et PROFESSEUR (ce qui ne préjuge pas de la mise en œuvre d’identifiants alternatifs tels que par exemple le matricule du professeur).

[fsmrel]

Reprenons votre représentation graphique :




En vertu de ce qu’on a dit à propos de la généralisation/spécialisation, les entités-types ETUDIANT (et pas ETUDIENT !) et PROFESSEUR deviennent des sous-types (spécialisations) de l’entité-type PERSONNE.

Concernant l’entité-type ETUDIANT

Les attributs ID_ETUD er DATE_NAISS n’ont plus lieu d’être puisqu’ils feraient double emploi avec les attributs PsnId, DateNaissance de l’entité-type (surtype) PERSONNE.

Du point de vue sémantique, les UV n’ont rien à faire là où vous les avez placées, puisqu’elles ne concernent que les étudiants en maîtrise ; de même selon votre représentation, des étudiants qui ne sont pas en maîtrise peuvent avoir un tuteur : il est préférable de mettre en œuvre un sous-type ETUDIANT_EN_MAITRISE, spécialisation de l’entité-type ETUDIANT (héritant donc des propriétés de celle-ci), en sorte que l’on s’y retrouve sémantiquement parlant :






Concernant l’entité-type PROFESSEUR

Il est préférable de dégager le nom du département et de faire de celui-ci une entité-type à part entière. En effet, celui qui saisira les noms des départements lors de l'acquisition des données propres aux professeurs risque de les orthographier de plusieurs façons. Et de toute façon, le numéro de téléphone sera saisi lui aussi à chaque fois et cela de façon redondante, on dit qu’en l’occurrence on viole la 3e forme normale et c’est condamnable par les tribunaux relationnels (privation de dessert) !

De la même façon autant faire des entités-types pour le domaine de recherche et le statut marital.





Une remarque concernant l’association « Est né » de votre représentation graphique

Je rappelle qu’un ovale symbolise une association (ou relation) entre différents types d’entités. Dans le cas général, une relation entre un professeur, un étudiant et une ville est certes possible, mais concernant la naissance, il y a là un non-sens...

Je vous laisse le soin de compléter le MCD.

[fcmelina]

Voici pour l'instant mon plus bel essai.

Qu'en pensez vous?

Ne regardez pas les cardinalités, elles sont en cours d'ajout.

Merci par avance

[fcmelina]

Avec la pj c'est mieux..

[fcmelina]

Remplace et annule le précédent schéma

[fcmelina]

Je sais pas si j'ai tout bien fait, je veux juste avoir votre validation.

J'ai beaucoup modifié depuis mon dernier schéma pour arriver à ceci mais j'avoue que j'ai certains doutes...

1) Modele EER en PJ
2) Modele relationnel en PJ

Merci par avance

[fsmrel]

Bonsoir fcmelina,


Il y a un bel effort de votre part, nonobstant les remarques à venir.

Concernant le MCD

Envoyé par fcmelina

Les étudiants [...] les villes et les pays où ils ont habité avant (avec le nombre d'années pendant lesquelles ils y vivaient)

Pour ma part, je me suis cantonné au lieu de résidence actuel (tel étudiant réside dans telle ville). Votre représentation prend en compte le présent et le passé :

[ETUDIANT]----1,N----(Réside{Date_Debut, Date_Fin})----1,N----[VILLE]

Il faudrait néanmoins séparer le présent du passé, car si on sait que l’étudiant e1 a résidé par le passé dans la ville v1, depuis la date d1 jusqu’à la date d2, concernant le présent on sait seulement qu’il réside dans la ville v2 depuis telle date : la date de fin est en l’occurrence sans objet. Il faudrait donc deux associations entre ETUDIANT et VILLE : RESIDER (ou Réside ou ...) pour le présent et AVOIR_RESIDÉ (ou RESIDER_HISTO, ou Résida, ou ...) pour le passé.

Par ailleurs, il ne vous est pas demandé de traiter les périodes pendant lesquelles les étudiants ont résidé dans des villes, mais seulement le nombre d’années. Dans ces conditions, la partie correspondante du MCD pourrait ressembler à ceci :




Notez que côté VILLE, les cardinalités sont plutôt 0,N, car on traite peut-être par ailleurs de villes dans lesquelles aucun étudiant n’a résidé jusqu’ici.


Si vous tenez vraiment à faire figurer les dates, notez que selon votre représentation, si l’étudiant e1 a résidé dans la ville v1 pendant la période p1, puis dans la ville v2 pendant la période p2, on ne pourra pas traiter le fait qu’il a pu résider à nouveau dans la ville v1 pendant la période p3. Pour traiter ce cas, vous pouvez définir une association-type ternaire :

[ETUDIANT]----0,N----(AVOIR_RESIDÉ)----0,N---->[VILLE]
                           |
                           | 0,N
                           |
                       [PERIODE]

Où PERIODE représente en fait un type à deux arguments : Date début et Date Fin. L’utilisation de ce type permet de se simplifier la vie au niveau MCD, sinon il faudrait mettre en œuvre une quaternaire pour faire intervenir la date de début d’une part, la date de fin d’autre part et faire intervenir une 1re CIF (contrainte d’intégrité fonctionnelle) pour la date de début et une 2e CIF pour la date de fin, symétrie oblige. Une seule CIF suffit avec PERIODE, symbolisée par la pointe de flèche ciblant VILLE : ---->[VILLE].

Je rappelle que la CIF se lit ainsi : ETUDIANT X PERIODE ---> VILLE, c'est-à-dire qu’au cours d’une période donnée, un étudiant n’a pu résider que dans une seule ville. En l’absence de CIF, un étudiant a pu résider dans plusieurs villes au cours d’une période donnée.

Envoyé par fcmelina

...Les cours suivis avec le code, l'intitulé, le professeur, la date et la note obtenue.
Pour les cours de l'année en cours...

L’énoncé qui vous a été fourni est maladroit. On peut quand même comprendre qu’il faut s’intéresser non seulement aux cours de l’année en cours, mais aussi à ceux des années précédentes. On va dire que ces derniers constituent un historique où pour chaque cours on doit en connaître le code, l’intitulé, le professeur qui l’a dispensé, la date (mais qu’est-ce donc qu’une date de cours ???) ainsi que la note obtenue par chaque étudiant ayant suivi ce cours. Pour la date, on va supposer qu’il s’agit de l’année scolaire qui de toute façon doit être présente, sinon ça n’a pas de sens.

Pour votre part, pour un professeur donné p1 et un cours donné c1, vous interdisez que p1 ait donné deux fois c1 (par exemple durant l’année a1, puis durant l’année a2, etc.) Est-ce bien ce que vous voulez ? Sinon, il faut prendre en compte l’année scolaire.

On est en droit de supposer que la note représente celle qui a été obtenue en fin d’année : ceci ne vaut évidemment pas pour l’année en cours. Bref, on a encore un tas de raisons pour (prudemment) isoler le présent et le passé, « déplier » le modèle, quitte à voir par la suite dans quelles conditions on pourra le « replier », fondre le présent avec le passé.

Version dépliée




Si l’on respecte à la lettre l’énoncé qui vous est donné, un cours n’est donné que par un professeur : pour une année donnée, pourquoi pas, mais au fil des ans, les professeurs sont en droit de changer, de s’en aller, etc. Je propose un assouplissement minimum, en sorte qu’on ne s’éloigne pas trop de l’énoncé :

Au cours d’une année scolaire donnée, un cours donné n’est dispensé que par un seul professeur.

A noter la mise entre parenthèses de la cardinalité 1,1 au dessus de COURS_HISTO : avec l'AGL utilisé (Power AMC), cela signifie qu'on met en oeuvre l'identification relative : l'identifiant de COURS_HISTO n'est pas composé seulement de Annee, mais de la paire {CoursId, Annee} où CoursId est par convention hérité de COURS.


On verra plus tard le reste du MCD.

[fsmrel]

Modele EER + Modele relationnel

Attention, le modèle relationnel est une théorie ! Ce que vous montrez est en fait la représentation de la structure d’une base de données. Par référence à Merise, vous pouvez de préférence représenter un MLD (modèle logique de données) dérivé du MCD (modèle conceptuel de données).

Je vous invite à utiliser un outil gratuit tel que MySQL Workbench pour représenter le MLD (que cet outil nomme « EER diagram », mais on n’épiloguera pas là-dessus).
Voyez chez Jogodepau un exemple d'utilisation de l'outil.


Prenons maintenant la représentation que vous avez faite.

Structure de la relvar PAYS (abréviation de variable relationnelle, dont une image approchée est la table en SQL) :

PAYS {ID_PAYS, NOM_PAYS, ID_VILLE}

Vous avez souligné l’attribut ID_PAYS : OK, {ID_PAYS} est une clé.
Vous avez souligné en pointillés l’attribut ID_VILLE : je suppose que vous voulez signifier que PAYS fait référence à VILLE, dans le sens où un pays est en l’occurrence composé de plusieurs villes. Dans le cas des bases de données relationnelles, on fonctionne dans le sens inverse, c’est la ville qui fait référence au pays auquel elle appartient :

PAYS {ID_PAYS, NOM_PAYS} ;

VILLE {ID_VILLE, NOM_VILLE, ID_PAYS} ;

Plutôt que souligner les noms des attributs (surtout en pointillés), je préfère utiliser une notation où l’on appelle un chat un chat, c'est-à-dire une clé, une clé et une clé étrangère, une clé étrangère (qualification bizarre, qui au reste ferait mieux d’être appelée contrainte référentielle, mais bon) :

PAYS {ID_PAYS, NOM_PAYS}
KEY {ID_PAYS} ;

VILLE {ID_VILLE, NOM_VILLE, ID_PAYS}
KEY {ID_VILLE}
FOREIGN KEY {ID_PAYS} ;

PAYS a pour clé (qualifiée de primaire dans le cas de SQL) : {ID_PAYS}.

VILLE a pour clé : {ID_VILLE}.

En outre, VILLE est dotée d’une clé étrangère {ID_PAYS}, exprimant la contrainte selon laquelle une ville fait référence à un pays instance de PAYS.

Exemple de représentation avec MySQL Workbench (il s’agit de la traduction en MLD du début du MCD figurant dans mes précédents messages) :




Les cardinalités sont celles d’UML. Un pays est composé de 1 à N villes, une ville appartient à un et un seul pays, etc. Je n'ai pas pris ici en compte les villes dans lesquelles les étudiants ont résidé par le passé. Notez l’interprétation qu’il faut donner à l’association entre PERSONNE et ETUDIANT : une personne peut être un étudiant (cardinalité 0,1), tandis qu’un étudiant est nécessairement une personne (cardinalité 1,1). Les liens sous forme de traits en pointillés expriment des associations banales (non identifiantes). Les liens sous forme de traits pleins expriment des associations « identifiantes ». Par exemple, la clé primaire {PsnId} de la table ETUDIANT est aussi clé étrangère par rapport à la table PERSONNE.

Selon la notation relationnelle :

PERSONNE {PsnId, PsnNom, DateNaissance, VilleNaissanceId}
KEY {PsnId}
FOREIGN KEY {VilleNaissanceId} REFERENCES VILLE ;

ETUDIANT {PsnId, Sexe, VilleResidenceId}
KEY {PsnId}
FOREIGN KEY {PsnId} REFERENCES PERSONNE
FOREIGN KEY {VilleResidenceId} REFERENCES VILLE ;

Etc.

N.B. Noter l’utilisation des accolades : en effet les noms des attributs sont des éléments d’ensembles :

{PsnId, PsnNom, DateNaissance, VilleNaissanceId} constitue l’en-tête de la table PERSONNE,

{PsnId} constitue une clé de PERSONNE, etc.

Je crois que vous avez de quoi vous occuper pour mettre votre MLD d’équerre...

[fcmelina]

En suivant vos conseils et en optimisant un peu voici ce que j'obtiens.

Merci pour votre réponse

[fsmrel]

Bonsoir fcmelina,

Envoyé par fcmelina

En suivant vos conseils

De fait, vous avez remis les choses dans le bon sens dans le MLD, avec les clés étrangères référençant les clés (primaires) cibles.

Le diagramme (schéma) que vous fournissez peut être considéré comme étant un MLD puisque vous mettez en œuvre les concepts de clé primaire et clé étrangère. Il peut être qualifié de FEERD (Fcmelina Extended Entity Relationship Diagram), en effet, il ressemble à l’EERD de MySQL Workbench (lequel s’inspire de l’ERD de Chen...)

Votre représentation se démarque de celle de Workbench dans la mesure où pour ce dernier les tables sont uniformément représentées par des rectangles, tandis que vous avez conservé les ellipses du MCD : comme c’est juste une histoire de dessin, pas de problème.

Il y a quand même des erreurs techniques (clés étrangères absentes par exemple, voyez ci-dessous). Je vous engage à utiliser un outil comme MySQL Workbench pour modéliser, puisque le faire manuellement ne permet pas de contrôler qu’on travaille proprement. Exemple :

Votre structure pour la table PROFESSEUR est celle-ci :




Alors qu’elle devrait être celle-là :

PROFESSEUR {ID_Personne, ID_Titre, ID_StatutMarital, ID_Departement, ID_Domaine}
    KEY {ID_Personne}
    FOREIGN KEY {ID_Personne} REFERENCES PERSONNE
    FOREIGN KEY {ID_Titre} REFERENCES TITRE
    FOREIGN KEY {ID_StatutMarital} REFERENCES STATUT_MARITAL
    FOREIGN KEY {ID_Departement} REFERENCES DEPARTEMENT
    FOREIGN KEY {ID_ Domaine} REFERENCES DOMAINE_RECHERCHE ;

=>




Vous me direz que Workbench ne fait apparemment pas mieux :




Mais en réalité, si on soulève le capot, on voit bien que la clé primaire {PsnId} est aussi clé étrangère.



Quant à la partie importante, à savoir l’adéquation de la modélisation proprement dite aux règles de gestion, vous n’avez rien modifié et je reprends les observations que j’ai déjà faites.

A propos de la résidence des étudiants dans les villes :

Vous avez conservé les dates de début et de fin. Structurellement parlant, votre table RESIDE est la suivante :

RESIDE {ID_Personne, ID_Ville, Date_Debut, Date_Fin}
    KEY {ID_Personne, ID_Ville}
    FOREIGN KEY {ID_Personne} REFERENCES ETUDIANT
    FOREIGN KEY {ID_Ville} REFERENCES VILLE ;

Supposons que le contenu de la table RESIDE soit le suivant :

ID_Personne    ID_Ville    Date_Debut    Date_Fin
         P1          v1            d1          d2
         P1          v2            d3          d4
         P2          v3            d5          d6
        ...         ...           ...         ...

Comme je vous l’ai signalé, si l’étudiant p1 réside à nouveau la ville v1, vous ne pourrez pas prendre ce fait en compte, car la clé {ID_Personne, ID_Ville} interdit le doublon <p1, v1>.

Vous êtes donc pris en flagrant délit de non respect des règles de gestion des données, et comme il est hors de question de transformer le bug en fonctionnalité...

Je vous rappelle aussi que pour l’année en cours, avec votre représentation il y a un clash puisque vous exigez la présence d’une date de fin en l'occurrence sans objet puisqu’elle ne pourra être théoriquement connue qu’en fin d’année scolaire : votre modélisation est ici entachée comme d’un viol d’intégrité conceptuelle.

Ce que j’ai écrit en ce qui concerne les cours donnés par les professeurs reste valable, votre MLD (comme votre MCD) ne permet pas de prendre en compte les règles de gestion des données. Considérez votre table Enseigne (dans laquelle les clés étrangères sont absentes à tort) :

ENSEIGNE {ID_Personne, ID_Cours}
    KEY {ID_Personne, ID_Cours}
    FOREIGN KEY {ID_Personne} REFERENCES PROFESSEUR
    FOREIGN KEY {ID_Cours} REFERENCES COURS ;

Supposons que le contenu de la table ENSEIGNE soit le suivant :

ID_Personne    ID_Cours 
         P1          c1
         P1          c2
         P2          c3
         P2          c1
        ...         ...

Selon votre modélisation, on est — à tort — dans un contexte intemporel, et l'on peut en plus inférer qu'un cours donné peut être dispensé simultanément par plusieurs professeurs. Je vous renvoie à mon message précédent.


Il est temps que vous caliez votre modélisation sur les règles de gestion des données.