La modélisation conceptuelle des données Cours Merise sur le modèle conceptuel de données MCD le Modèle entité Association MEA

1 Introduction

Après avoir recherché et formalisé les dépendances fonctionnelles à partir du dictionnaire des données épuré, on peut élaborer le modèle conceptuel des données (MCD) du système d’information.

Son rôle est fondamental dans une étude d’informatisation. Le MCD conditionne fortement la suite de l’étude. Il permet de « dessiner » la structure des données du système d’information à implanter.

2 Concepts et formalisme

Le formalisme retenu est le modèle Entité-Association (MEA), mais on parlera souvent de MCD (Modèle Conceptuel des Données).

2.1 Les entités

Elles correspondent aux objets du système d’information. Par exemple, l’entité CLIENT rassemble toutes les informations communes aux clients de l’entreprise.

Les entités sont nommées.
Leur nom est unique dans le modèle et s'écrit en majuscule

Dans le système d’information, l'entité CLIENT représentera l'ensemble des clients. Chaque client constitue alors une occurrence de l’entité. Une occurrence représente un « exemplaire » de l’objet.

2.1.1 Propriétés

Une entité possède toujours au moins une propriété. Chacune de ces propriétés doit pouvoir être valorisée de manière unique.

Les propriétés des entités sont issues du dictionnaire des données.

2.1.2 Identifiant

Parmi les propriétés d’une entité, il y en a une qui joue un rôle particulier :

L’identifiant d’une l’entité est une propriété telle qu’à chaque valeur de la propriété corresponde une et une
seule occurrence de l’entité. Par conséquent :

on ne peut trouver deux occurrences d’une entité ayant le même identifiant

l’identifiant se confond avec l’entité : l’entité existe si on peut valoriser l’identifiant

si l’entité ne possède qu’une propriété, cette propriété est l’identifiant

toutes les propriétés sont en dépendance fonctionnelle élémentaire et directe avec l’identifiant

L’identifiant est représenté souligné dans le modèle.

2.2 Les associations

Une association est un lien entre des entités. Contrairement aux entités, les associations n'ont pas d’existence propre mais elles peuvent porter des propriétés.

Les associations sont nommées, généralement à l’aide d’un verbe d’action.
Une association peut lier plus de deux entités.

Exemples :

Association binaire :

Association porteuse de propriété

Association ternaire :

Le nombre d’entités impliquées dans l’association détermine sa dimension : pour les associations faisant intervenir deux entités, on parle d’association de dimension deux ou associations binaires. Pour les associations faisant intervenir plus de deux entités, on parle d’associations n-aires.

Remarques :

Les associations n-aires de dimension supérieure à quatre sont suspectes et assez rares. Il faut vérifier qu’il ne s’agit pas d’entités « cachées ». Il s’agit souvent d’objets abstraits faisant intervenir la notion de temps (historiques en particulier).
Ceci est également vrai parfois pour des associations ternaires. Une ternaire doit donc être vérifiée avec attention.

2.2.1 Identification d’une association

Une association est identifiée par la « concaténation » des identifiants des entités qu’elle relie. Cette identification est implicite et n’est pas représentée.

Il n’y a normalement pas de propriété identifiante dans une association. Si une propriété peut jouer ce rôle, il est probable que cette association soit en fait une entité mal interprétée.

Par exemple :

La représentation de gauche fait apparaître une propriété candidate à l’identification de l’association ternaire AFFAIRE. Cette association est en fait une entité comme le montre la figure de droite :

2.2.2 Rôles d’une association

Chaque « patte » d’une association vers une entité représente le rôle joué par l’association. Ces rôles peuvent être nommés, cela peut aider à clarifier le modèle dans certaines situations complexes.

Les rôles sont généralement faciles à identifier sur des associations binaires, ce n’est pas le cas des associations n-aires.

2.3 Cardinalités

2.3.1 Définition

La cardinalité représente le nombre d’occurrences minimum et maximum d’une association par rapport à une entité.

La cardinalité minimale représente le nombre de fois « au minimum » où une occurrence de l’association participe aux occurrences de l’entité. Cette cardinalité est choisie parmi 0 ou 1.
La cardinalité maximale représente le nombre de fois « au maximum » où une occurrence de l’association participe aux occurrences de l’entité. Cette cardinalité est choisie parmi 1 ou n où n indique une cardinalité maximale supérieure à 1 mais non quantifiée. Si la valeur de n est connue, on peut la mentionner.

2.3.2 Formalisme

Les cardinalités sont mentionnées par couple du côté de l’entité à considérer. La cardinalité minimale est représentée en premier, la maximale en second.

Exemple :

un employé peut suivre (0) ou plusieurs (n) affaires
une affaire est suivie par un (et un seul) employé
une affaire est passée avec un (et un seul) client
un client passe une (sinon ce n’est pas un client) ou plusieurs (n) affaires

La cardinalité minimale à 1 ou à 0 dépend des règles de gestion. Si sur le schéma précédent, on admettait à gauche une cardinalité 0,n cela voudrait dire qu'il existe des clients n'ayant pas passé d'affaire.

2.4 Associations réflexives

Ce sont des associations qui relient deux fois la même entité.

Une pièce (en mécanique par exemple) est composée de 1 ou plusieurs pièce.

Dans les associations réflexives, la notion de rôle prend tout son sens.

2.5 Petit aparté sur les contraintes d’intégrité fonctionnelle

Quand on détermine une association présentant une cardinalité maximale à 1, on est en présence d’une contrainte d’intégrité fonctionnelle (CIF). Une CIF traduit la présence d’une dépendance fonctionnelle entre les identifiants des entités participant à l’association.

Vous pourrez dans la littérature conceptuelle voir la représentation des CIF avec un formalisme différent :

L’association nommée est remplacée par une « pastille » CIF et la « patte » portant la cardinalité maximale à n est remplacée par une flèche. Cela signifie qu’il existe une dépendance fonctionnelle entre NoAffaire et NoClient. Cette écriture n'est pas celle que nous utiliserons.

3 Démarche de construction du MCD

Le MCD est élaboré à l’aide du dictionnaire des données et du graphe des dépendances fonctionnelles. Néanmoins, comme je vous l'ai laissé entendre dans le précédent cours, la partie recherche des dépendances fonctionnelles est souvent occulté, le MCD étant alors directement construit à partir du dictionnaire des données.

3.1 Repérage des entités

Les entités correspondent aux objets du SI. On peut les repérer intuitivement ou s’aider du graphe des dépendances fonctionnelles.

Repérer une entité revient à repérer une propriété identifiant (une source de dépendances fonctionnelles).

L’entité repérée, il faut la nommer. On choisira des identificateurs concis et parlants, en rapport avec le domaine de gestion étudié.
La propriété identifiant devient l’identifiant de l’entité. Il sera souligné et écrit en premier.
Les données, but de dépendances fonctionnelles deviennent des propriétés de l’entité.

3.2 Repérage des associations

Les associations représentent des liens entre entité. L'analyse des dépendances fonctionnelles doit nous aider à repérer ces associations. Dans ce repérage, il est important de repérer les associations simples de celles porteuses de données.

3.3 Placement des cardinalités

Le placement des cardinalités permet de vérifier la validité des dépendances fonctionnelles.

3.4 Vérification du modèle

En principe, si les dépendances fonctionnelles ont été correctement spécifiées et si les règles de construction ont été respectées, le MCD est correct.

Si l’étude des dépendances fonctionnelles n’a pas été utilisée, il faut absolument vérifier le modèle (je dirais même qu'il faut le vérifier dans tous les cas, surtout pour vous) :

Toutes les propriétés doivent être élémentaires (non décomposables)
Chaque entité possède un et un seul identifiant, rôle joué par une seule propriété.
Les propriétés d’une entité doivent être en dépendance fonctionnelle avec l’identifiant.
Les propriétés d’une association doivent être en dépendance fonctionnelle élémentaire avec l’identifiant implicite de l’association.
Une propriété ne peut figurer qu’une fois dans le modèle (pas de redondance)
Une propriété d’une entité ne peut être en dépendance fonctionnelle avec une autre propriété non identifiant de cette entité (pas de transitivité).
Une propriété portée d’une association doit être en dépendance fonctionnelle élémentaire avec la « concaténation » des identifiants des entités participant à l’association.