| Figure 1.4: Exemple entités |
Pour le moment, en analyse, nous avons vu comment décomposer une
situation réelle en données, et nous avons vu aussi comment
représenter des liaisons entre ces données. Cependant, le graphe des
dépendances fonctionnelles est incomplet dans le sens où il ne permet
pas de représenter suffisamment de liaisons pour représenter
fidèlement la réalité.
Le MCD, dit aussi Modèle Conceptuel des Données, est une
représentation graphique davantage complète que le graphe des
dépendances fonctionnelles. L’élaboration d’un MCD nécessite plus
d’observations de la situation que le graphe des
DF. Le modèle est par conséquent suffisamment complet pour qu’il soit
possible de déduire la répartition des données dans les tables sans
observation supplémentaire de la situation. Cette étape est donc la
dernière étape épineuse d’une analyse.
Commençons par examiner un exemple.
Le bureau des étudiants souhaite lorsqu’il planifie des soirées, lister les étudiants qui ont réservé des places pour gérer la billetterie. Nous utiliserons les données suivantes :
Il apparaît clairement que :
On observe que les dates des soirées ne peuvent pas servir
d’identifiant parce que plusieurs soirées peuvent être programmées le
même soir par le BDE. On remarque aussi que les données numetud,
nometud, prenomnometud et mailetud sont liées, parce que trois
d’entre elles dépendent de numetud. De même, on peut regrouper
numsoiree, nomsoiree et datesoiree.
A titre de parenthèse, rappelons que numetud ↛numsoiree parce qu’un étudiant peut avoir réservé des places pour
plusieurs soirées (ou aucune). De façon analogue, on a
numsoiree ↛numetud, parce qu’il peut y avoir
plusieurs étudiants dans une soirée, tout comme il peut n’y en avoir
aucun. On conclura donc que le graphe des DF ne permet pas de
représenter la façon complète la billetterie, vu qu’il ne permet pas
de mettre en correspondance les étudiants et les soirées.
Il est usuel, en analyse, de regrouper dans des entités des données liées à leur identifiant par une relation de dépendance fonctionnelle. On représente cela ainsi :
Figure 1.4: Exemple entités
Les boîtes dans lesquelles les données sont regroupées sont des entités, les identifants doivent être soulignés, et toutes les données doivent être en dépendance fonctionnelle avec l’identifiant.
La clé dessinée à côté de l’identifiant est ajoutée par Open Model Sphere, vous n’avez pas besoin de la dessiner. Par rapport à la question que nous nous posions, et qui était comment représenter graphiquement les correspondances entre les soirées et les étudiants, nous n’avons toujours pas répondu.
Les associations sont des correspondances entre les entités, on les représente ainsi :
Figure 1.5: Exemple associations
Le fait que Etudiant soit associé à Soirée signifie que la base de données devra permettre étant donné un étudiant particulier, de savoir à quelle(s) soirée(s) il a participé, et vice-versa, à partir d’une soirée donnée, il devra être possible de déterminer quels étudiants ont participé.
Il est usuel de choisir des verbes pour les nommer, pour la simple raison que la plupart du temps, les entités représentent des objets (au sens très large du terme), et les associations des actions impliquant ces objets.
Etendons notre modèle : supposons que le BDE souhaite aussi gérer les lieux réservés pour les soirées. Il serait envisageable d’agrandir notre MCD de la sorte :
Figure 1.6: Exemple incomplet...
Le problème qui se pose est que ce modèle est incomplet... En effet la
relation Se Dérouler n’est du tout de la même nature que la
relation Participer... Pourquoi ? Parce que pour une soirée
on ne réserve qu’une salle à la fois ! On s’en convainc en remarquant
qu’il y a une dépendance fonctionnelle entre numsoiree et numlieu.
Etant donnée une soirée particulière, on lui associe un et un seul
lieu, alors qu’à un lieu correspond un nombre de soirées inconnu à
l’avance. On complète le modèle en ajoutant ce que l’on appelle des
cardinalités :
Figure 1.7: Exemple cardinalités
Le 0, n entre Etudiant et Participer signifie qu’à un étudiant sera associé un nombre de soirées pouvant varier de 0 à plusieurs. Le n signifie que le nombre de soirées peut être aussi grand que l’on veut. Le 0, 1 séparant Soirée de Se Dérouler signifie qu’à une soirée est associé 0 ou 1 salle. A votre avis, que signifient les autres cardinalités ?
Supposons que les étudiants aient le droit de venir avec des personnes extérieures, c’est-à-dire qu’ils aient le droit de réserver plusieurs places. Où mettre la donnée nbPlaces ? On ne peut pas la mettre dans Etudiant, ni dans Soirée, parce que le nombre de place réservées par un étudiant à une soirée dépend à la fois de la soirée et de l’étudiant. La solution est la suivante :
Figure 1.8: Exemple attribut
Cet attribut de l’association Participer signifie qu’à chaque fois d’un étudiant annoncera sa participation pour une soirée, il devra préciser combien de places il souhaite réserver.
Construire un MCD modélisant la chaîne d’approvisionnement : A.2.
Il est possible d’exprimer avec des associations des situations relativement élaborées. Des bases données complexes comme par exemple celles que l’on peut trouver dans des réseaux sociaux se modélisent de façon surprenante.
Si l’on souhaite par exemple représenter une liste d’internautes pouvant étant être amis entre eux. L’association Etre ami met donc un Internaute avec un autre Internaute. Il faut donc pour représenter cela utiliser une association réflexive.
Figure 1.9: Exemple réflexive
Un autre cas qui pourrait se présenter est celui où il existe de multiples associations entre deux entités. Par exemple dans le cas d’un groupe (ou forum), il existe pour chaque groupe un internaute particulier qui en est le créateur. Cela ne doit pas empêcher d’autres internautes de s’inscrire sur le groupe. On représente cette situation avec deux associations différentes entre ces deux entités.
Figure 1.10: Exemple multiple
Il est aussi fréquent que plus deux associations soient impliquées dans une association. Si par exemple, on souhaite garder en mémoire des produits achetés par des clients sur un site, l’association mettant en relation le produit, la personne qui l’achète, et la date d’achat devra donc relier trois entités.
Figure 1.11: Exemple ternaire
On remarque au passage que la quantité dépend à la fois de l’internaute, du produit et de la date.
Si on considère qu’une photo appartient à une et une seule personne, et qu’elle ne pourra jamais changer de propriétaire, on utilise une entité faible comme dans l’exemple ci-dessous.
Figure 1.12: Exemple entité faible
On remarque que l’entité faible est notée en soulignant l’identifiant en pointillés.
Il est aussi possible d’indiquer la présence d’une entité faible en mettant les cardinalités (1, 1) entre parenthèses.
Représentez un MCD associé au secrétariat pédagogique (A.1).
Représentez un arbre généalogique (A.3) avec un MCD.
Réalisez un MCD permettant de représenter un CMS (A.4).
Réalisez un MCD permettant de représenter un Forum (A.6).
Réalisez un MCD permettant de modéliser un site de covoiturage (A.7).