Le MCD : entités, propriétés, identifiants, associations

Le modèle conceptuel de données (MCD) est le schéma qui représente les données d'un système d'information avec trois notions : des entités (les choses qu'on gère), des associations (les liens entre elles) et des cardinalités (combien de fois chaque entité participe à un lien). Il ne parle ni de tables ni de SQL : il se lit en français et se discute avec les futurs utilisateurs. Ce chapitre présente ses éléments un par un, puis construit le MCD des médiathèques Rivelire.

L'entité et ses occurrences

Une entité représente un ensemble d'objets de même nature que l'organisation veut mémoriser : des adhérents, des documents, des sites. Chaque objet concret est une occurrence de l'entité : l'adhérente Inès Durand, n° 20418, est une occurrence de l'entité ADHERENT.

Une entité se dessine par un rectangle : son nom en haut, puis la liste de ses propriétés. Son nom est un nom commun au singulier, écrit en majuscules par convention : ADHERENT, pas « Adhérents » ni « table_adherent ». Comme les noms deviendront ceux des tables, on les écrit sans accent.

Pour savoir si une « chose » de l'énoncé mérite d'être une entité, pose trois questions :

1. Y a-t-il plusieurs occurrences à mémoriser ? (plusieurs sites, plusieurs genres)
2. A-t-elle des propriétés propres, au-delà de son nom ? (un site a une adresse et une ville)
3. Faut-il pouvoir la désigner sans ambiguïté, et la relier à d'autres entités ? (un document appartient à un genre)

Si la réponse est oui à la première et à l'une des deux autres, c'est une entité.

Les propriétés

Une propriété (on dit aussi attribut) est une donnée élémentaire qui décrit une entité : le titre d'un document, la date de naissance d'un adhérent. Les propriétés viennent du dictionnaire des données, et chacune obéit à quatre règles :

La dernière règle reprend les dépendances fonctionnelles du chapitre 3 : une propriété qui dépend d'une autre propriété que l'identifiant est mal rangée.

Une propriété peut être facultative : le résumé d'un document, la date de retour d'un emprunt en cours. Le MCD ne le montre pas toujours, mais note-le dans le dictionnaire : il deviendra une colonne qui accepte NULL.

L'identifiant

L'identifiant est la propriété (ou le groupe de propriétés) dont la valeur distingue chaque occurrence de toutes les autres. Il est souligné dans le MCD et placé en tête de la liste. Toute entité en a un.

Un bon identifiant est :

• unique : deux occurrences n'ont jamais la même valeur ;
• toujours connu : il n'est jamais vide, dès la création de l'occurrence ;
• stable : il ne change pas pendant la vie de l'occurrence ;
• court : il sera recopié dans d'autres tables, comme clé étrangère.

Le nom d'une personne n'est pas unique. Son adresse électronique est unique mais pas stable : elle change. Son numéro de sécurité sociale est unique et stable, mais c'est une donnée sensible qu'on ne recopie pas partout. D'où le choix fréquent d'un identifiant artificiel, un numéro attribué par le système (num_adherent), plutôt que d'un identifiant naturel. Un identifiant naturel convient quand il est vraiment unique, stable et court : le code d'un site (CEN), le code-barres d'un exemplaire, le code ISO d'un pays.

L'association

Une association représente un lien entre des entités, que l'organisation veut mémoriser : un exemplaire est rattaché à un site, un adhérent réserve un document. Elle se dessine par une ellipse (ou un rectangle aux coins arrondis) reliée par des traits, qu'on appelle des pattes, aux entités qu'elle relie. Son nom est un verbe à l'infinitif : RATTACHER, RESERVER, CONTRIBUER.

Une occurrence d'association est un lien entre des occurrences précises : « l'exemplaire 3700001234567 est rattaché au site CEN ». Le nombre d'entités reliées est la dimension de l'association : la plupart sont binaires (deux entités) ; on verra les associations réflexives et ternaires au chapitre 6.

Une association n'a pas d'identifiant propre : une de ses occurrences est identifiée par les identifiants des entités qu'elle relie. Conséquence capitale : dans une association binaire, un même couple d'occurrences ne peut apparaître qu'une fois. Si Inès peut réserver le document 1204 une seule fois à la fois, RESERVER convient. Si elle peut emprunter deux fois le même exemplaire, EMPRUNTER entre ADHERENT et EXEMPLAIRE ne convient plus : il faut une entité EMPRUNT, avec son propre identifiant. C'est ce qu'avait révélé l'analyse des DF.

Les associations porteuses de propriétés

Certaines informations ne décrivent ni une entité ni l'autre, mais le lien entre les deux. Elles deviennent des propriétés de l'association, qu'on dit alors porteuse.

À Rivelire, le rôle d'un contributeur n'est pas une propriété du contributeur (Jean Dupuis est auteur ici, traducteur là), ni du document (un album a un auteur et un illustrateur). Il dépend du couple : c'est une propriété de l'association CONTRIBUER. De même, la date d'une réservation dépend du couple adhérent-document : elle est portée par RESERVER.

Le test : retire une des deux entités, la valeur a-t-elle encore un sens ? « Le rôle de Jean Dupuis », sans dire sur quel document : non. « La date de réservation du document 1204 », sans dire par qui : non plus. La propriété appartient donc à l'association.

Entité ou propriété ?

C'est la question qui revient le plus souvent. Le genre d'un document peut-il être une simple propriété genre de DOCUMENT, ou faut-il une entité GENRE ?

Le genre devient une entité : la médiathèque veut gérer la liste des genres, et elle filtrera le catalogue par genre. L'état d'un exemplaire reste une propriété : quatre valeurs fixes, contrôlées par une contrainte CHECK dans le SQL. Les deux choix se défendent souvent ; ce qui compte, c'est de pouvoir justifier le tien.

Dessiner un MCD : les conventions

Sur papier ou dans un logiciel, les conventions sont les mêmes :

• une entité est un rectangle : nom en majuscules, identifiant souligné en premier, puis les propriétés ;
• une association est une ellipse reliée aux entités par des pattes, avec son nom (un verbe) et ses éventuelles propriétés ;
• les cardinalités s'écrivent sur chaque patte, du côté de l'entité qu'elles concernent (chapitre 5).

Dans le texte de ce cours, les entités sont notées avec leur identifiant en gras, comme ADHERENT (num_adherent, nom_adherent, prenom_adherent), et les associations sur une ligne, chaque cardinalité collée à son entité :

DOCUMENT 1,1 ──── APPARTENIR ──── 0,n GENRE

Ici, 1,1 concerne DOCUMENT (un document appartient à un seul genre) et 0,n concerne GENRE (un genre regroupe zéro, un ou plusieurs documents).

Construire le MCD de Rivelire pas à pas

Reprends le dictionnaire des données du chapitre 2 et le graphe des DF du chapitre 3. La construction suit quatre étapes.

1. Les entités. Chaque source simple du graphe des DF donne une entité :

• SITE (code_site, nom_site, adresse_site, ville_site)
• GENRE (code_genre, libelle_genre)
• DOCUMENT (num_document, titre, annee_parution, resume)
• CONTRIBUTEUR (num_contributeur, nom_contributeur, prenom_contributeur)
• EXEMPLAIRE (code_barre, date_acquisition, etat)
• ADHERENT (num_adherent, nom_adherent, prenom_adherent, date_naissance, email, date_inscription)
• EMPRUNT (num_emprunt, date_emprunt, date_retour_prevue, date_retour)

Remarque ce qui n'est pas dans les entités : code_genre n'est pas une propriété de DOCUMENT, ni code_site une propriété d'EXEMPLAIRE. Dans un MCD, les liens entre entités passent par des associations, jamais par une propriété qui recopie l'identifiant d'une autre entité. Les clés étrangères n'apparaîtront qu'au MLD.

2. Les associations. Chaque flèche du graphe entre deux sources donne une association, chaque source composée une association porteuse, et la RG8 ajoute un lien de l'entité ADHERENT avec elle-même :

3. Les cardinalités. Elles se lisent dans les règles de gestion ; le chapitre suivant les justifie une à une.

4. La vérification. Chaque entité a un identifiant ; chaque propriété apparaît une fois ; chaque association a un verbe et deux cardinalités ; chaque règle de gestion de structure se retrouve dans le schéma.

Les erreurs fréquentes

• Une clé étrangère dans une entité. Écrire code_genre dans DOCUMENT, c'est mélanger le MCD et le MLD. Dans le MCD, le lien est l'association APPARTENIR.
• Une entité pour une simple valeur. Une entité DATE_EMPRUNT ou une entité ETAT à une seule propriété alourdit le schéma sans rien apporter (sauf dans les cas d'historisation du chapitre 7).
• Confondre le document et l'exemplaire. Le titre décrit l'œuvre ; le code-barres et l'état décrivent un objet physique, dont le réseau possède plusieurs copies. C'est un piège classique des sujets sur les bibliothèques, les locations de voitures (un modèle, des véhicules) ou les spectacles (un spectacle, des représentations).
• Une association entre deux entités déjà reliées par un chemin. Relier EMPRUNT à DOCUMENT alors que l'emprunt porte sur un exemplaire, qui correspond à un document : le lien est redondant, et il permettrait d'enregistrer un emprunt dont l'exemplaire ne correspond pas au document.
• Une association nommée par un nom. « EMPRUNT » entre ADHERENT et EXEMPLAIRE cache souvent une entité qui s'ignore. Nomme les associations par un verbe ; si seul un nom vient, demande-toi si ce n'est pas une entité.

Exercices