pdf - e-book - archive - github.com

1.4  Modèle conceptuel des données

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.

1.4.1  Exemple introductif

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 numetudnumsoiree parce qu’un étudiant peut avoir réservé des places pour plusieurs soirées (ou aucune). De façon analogue, on a numsoireenumetud, 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.

1.4.2  Les entités

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.

1.4.3  Les Associations

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.

1.4.4  Les Cardinalités

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 ?

1.4.5  Associations et attributs

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.

Exercice 1 - Chaîne d’approvisionnement

Construire un MCD modélisant la chaîne d’approvisionnement : A.2.

Corrigé.

1.4.6  Associations complexes

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.

Réflexives

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

Multiples

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

Ternaires

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.

Entité faible

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.

1.4.7  Exercices

Exercice 2 - Secrétariat pédagogique

Représentez un MCD associé au secrétariat pédagogique (A.1).

Corrigé.

Exercice 3 - Arbre généalogique

Représentez un arbre généalogique (A.3) avec un MCD.

Corrigé.

Exercice 4 - CMS

Réalisez un MCD permettant de représenter un CMS (A.4).

Corrigé.

Exercice 5 - Forum

Réalisez un MCD permettant de représenter un Forum (A.6).

Corrigé.

Exercice 6 - Covoiturage

Réalisez un MCD permettant de modéliser un site de covoiturage (A.7).

Corrigé.