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) :
![](http://www.fsmwarden.com/developpez_4/fcmelina(Etudiants)Mwb.png)
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...
Partager