83932tgpa0109 PDF

BTS Informatique de gestion, 1re année
Jean-Yves Février
Développement d’applications
informatiques et génie logiciel
Cours 1 (Merise)
Directrice de publication : Valérie Brard-Trigo

Les cours du Cned sont strictement réservés à l’usage privé de leurs destinataires et ne sont pas destinés à une utilisation collective. Les personnes
qui s’en serviraient pour d’autres usages, qui en feraient une reproduction intégrale ou partielle, une traduction sans le consentement du Cned,
s’exposeraient à des poursuites judiciaires et aux sanctions pénales prévues par le Code de la propriété intellectuelle. Les reproductions par
reprographie de livres et de périodiques protégés contenues dans cet ouvrage sont effectuées par le Cned avec l’autorisation du Centre
français d’exploitation du droit de copie (20, rue des Grands Augustins, 75006 Paris).
Conseils généraux
La place de l’analyse
Dans le référentiel
Le cours que vous êtes en train de lire vous permettra d’acquérir la pratique de la méthode d’ana-
lyse Merise.
C’est un cours essentiel pour le BTS informatique de gestion car, dans cette branche de l’infor-
matique, la programmation doit impérativement être précédée d’une phase d’analyse pour bien
cerner le travail à effectuer.
Dans le référentiel de la formation, ce cours est inclus dans le savoir S3 DAIGL (Développement
d’Applications Informatiques et Génie Logiciel) avec la programmation. Plus précisément, nous
traiterons ici le savoir S32 du référentiel intitulé « Analyse et conception de systèmes logiciels :
méthodes et outils ».
Les neuf séquences de ce cours abordent les différents concepts du savoir S32.
Dans la formation
En formation initiale (en lycée), la première année s’étend sur 35 semaines, le volume horaire
hebdomadaire de l’analyse étant 2 heures de cours et 1 heure et demie de travaux dirigés. Cela
représente plus de 120 heures !
Faut-il donc passer 120 heures sur ce support ? Non, sans doute pas, car bien qu’apportant les
mêmes connaissances (vous n’êtes pas volé !) il est présenté de façon plus concise et l’apprentis-
sage est plus rapide. Néanmoins, il ne faut pas espérer maîtriser l’analyse en lisant d’une traite ce
cours. Vous devez apprendre à passer du temps sur les concepts présentés.
En effet, il y a une grande différence entre « comprendre plus ou moins le principe » et « parfaite-
ment assimiler un concept ». Dans le premier cas, le savoir n’est pas assimilé et cela vous bloquera
dans la suite du cours ; dans le second cas, tout ira bien.
Pour chacun des concepts que nous verrons, il faudra d’une part apprendre parfaitement sa défini-
tion (travail de mémoire) et d’autre part identifier ce que cela signifie (travail de compréhension).
Quand on commence un nouveau cours, on est toujours dubitatif face à tous les concepts et défi-
nitions. Certes, c’est du jargon et on a toujours l’impression que l’on passe son temps à redéfinir
des notions déjà connues. Ce n’est pas tout à fait vrai : il est nécessaire de tout redéfinir pour évi-
ter l’à-peu-près. On rencontrera d’ailleurs de nombreux cas où l’à-peu-près n’est pas acceptable.
Présentation du support de cours

Ce cours a été conçu pour pallier au maximum les difficultés de l’apprentissage à distance : les
notions à retenir (définitions…) sont mises en avant et des exercices et questions sont présents
tout au long du cours pour vous permettre de vérifier votre compréhension.
Mais j’insiste sur le point suivant : quelle que soit la qualité pédagogique de ce cours, il ne vous
permettra pas d’assimiler l’analyse par simple imprégnation visuelle. Vous devez fournir un travail
d’apprentissage (le cours), de réflexion (toujours le cours) et d’entraînement (les exercices).
3
8 3932 TG PA 01
Séquence 1
Le cours est constitué de deux fascicules : le cours proprement dit et un fascicule « autocorrection »
contenant la correction de tous les exercices.
Organisation
Le fascicule de cours contient différentes choses :
• neuf séquences de cours correspondant aux savoirs de S32 ; à la fin de chaque séquence, vous
trouverez une fiche « synthèse » vous rappelant les choses essentielles (à apprendre !) ;
• des exercices intégrés aux séquences de cours. Vous devez faire ces exercices quand vous arri-
vez dessus puis aller consulter la correction. Attention, ces exercices permettent de vérifier
votre assimilation du cours. Leur corrigé, très détaillé, ne doit pas être négligé : j’y présente
des situations, des techniques, des idées et des raisonnements qui ne sont pas anecdotiques
et font partie intégrante du cours. S’ils n’y sont pas physiquement, c’est uniquement pour
conserver une certaine lisibilité au document ;
• trois séries d’exercices jouant le rôle de travaux dirigés. Elles sont placées à des endroits stra-
tégiques du cours ;
• une étude de cas et d’analyse grandeur réelle équivalent à un BTS blanc. À faire à la fin de
l’année, il reprend tous les concepts abordés dans le cours.
Le fascicule de correction comprend :
• la correction des exercices intégrés aux séquences ;
• la correction des séquences de TD ;
• la correction de l’étude de cas.
En plus de vous donner la solution des exercices, j’ai essayé de détailler ces corrections pour envi-
sager les différentes solutions possibles, les erreurs à éviter… Plus que des corrections, ce sont de
véritables éléments de cours. Il ne faut donc pas les prendre à la légère !
Contenu
Les neuf séquences abordent cinq notions distinctes mais néanmoins liées :
• le modèle conceptuel des données (MCD) est étudié de la 1re à la 4e séquence avec un
complément dans la 6e ;
• la 5e séquence fait un sort au modèle logique des données (MLD) ;
• les dépendances fonctionnelles et leur utilisation pour construire le MCD sont étudiées dans
les 7e et 8e séquences. La 8e séquence aborde également le dictionnaire des données ;
• le graphe acteur/flux est disséqué dans la 9e séquence.
Vous remarquerez que le découpage des séquences ne correspond pas aux notions étudiées puis-
que, si le MLD tient en une séquence, le MCD s’étale sur cinq séquences. En effet, les séquences
ont été définies pour vous aider à établir votre progression. Elles représentent donc approxima-
tivement un volume de travail identique. Le découpage n’est néanmoins pas arbitraire : les diffé-
rents concepts ont été répartis au mieux pour que chaque séquence reste cohérente.
Notations
Pour vous aider à identifier les différents constituants du cours, j’ai utilisé les représentations
suivantes :
• tous les paragraphes dont les caractères sont en couleur doivent être appris par cœur.
Cela correspond aux définitions ou explications qu’il est absolument nécessaire de connaître
pour s’en sortir en analyse. Quand je dis apprendre, ce n’est pas retenir pour l’heure qui suit afin
d’épater les convives au prochain repas. Il s’agit d’une vraie leçon, dont vous devez vous souvenir
tout au long de votre vie d’informaticien, ou, plus prosaïquement, au moins jusqu’à l’examen.
Ces informations sont reprises à la fin de chaque séquence dans la fiche « synthèse » ;
4
8 3932 TG PA 01
Introduction
• les exercices intégrés dans les séquences et destinés à vérifier votre compréhension sont numé-
rotés et présentés sur fond couleur. Il faut donc les faire au fur et à mesure de la lecture du
cours. Leur correction se trouve dans le fascicule « autocorrection ».
Quelques conseils
Le seul conseil utile que je puisse vous donner est de garder à l’esprit la fable de La Fontaine
Le lièvre et la tortue : il ne sert à rien de travailler comme un fou en juin ; travaillez plutôt dès
maintenant quelques heures par semaine ré-gu-li-è-re-ment (j’aurais pu écrire régulièrement ou
RÉGULIÈREMENT, mon but étant juste d’insister sur le mot).
La difficulté de l’enseignement par correspondance réside dans le fait que, par définition, vous
êtes seul face au cours, personne n’est là pour vous guider, insister sur l’essentiel ou établir la
progression du cours.
Pour vous aider à suivre un rythme correct, une durée indicative est mentionnée en tête de chaque
séquence.
Attention ! Vous avez sans doute le souvenir de vos études où, pour obtenir un même résultat,
certains travaillaient toute la soirée et d’autres se contentaient d’être présents en cours. Il en est de
même ici. Par exemple, si 4 heures sont indiquées, ce n’est qu’un ordre de grandeur.
Cela signifie juste que 15 minutes, ce n’est pas assez, mais 25 heures, c’est trop.
Retenez qu’il vaut mieux passer 8 heures sur une séquence et la comprendre parfaitement, que
faire exactement 240 minutes (4 heures) en passant à côté de l’essentiel.
De plus, le cours contient des dizaines de petits exercices à faire au fur et à mesure. Plus vous pas-
serez du temps dessus (et c’est conseillé), plus vous risquez de dépasser les durées indiqueés.
Sommaire
Séquence 1 : Introduction 7
Séquence 2 : MCD : les concepts de base 1/2 17
Séquence 3 : MCD : les concepts de base 2/2 29
Travaux dirigés 1 51
Séquence 4 : MCD : fin 57
Séquence 5 : le MLD 71
Séquence 6 : règles de validation du MCD 89
Séquence 7 : les dépendances fonctionnelles (théorie) 107
Séquence 8 : les dépendances fonctionnelles (utilisation) 121
Séquence 9 : graphe acteurs/flux 151
Étude de cas récapitulative 167
5
8 3932 TG PA 01
Séquence 1
Introduction
Durée indicative : 2 heures
Cette séquence d’introduction va vous expliquer ce qu’est et à quoi sert une

méthode d’analyse. On présentera ensuite la méthode que vous étudierez dans
ce cours : Merise.
Capacités attendues
• Percevoir l’importance et le rôle de l’analyse
• Maîtriser le vocabulaire et la démarche de la méthode Merise
Contenu
1. Introduction à l’analyse ....................................................................... 8
1A. Pourquoi l’analyse ? ..................................................................................... 8
1B. L’informatique de gestion ........................................................................... 8
1C. Les méthodes d’analyse ............................................................................. 10
2. La méthode Merise .............................................................................. 11

2A. Données et traitements ............................................................................. 11
2B. Les trois niveaux de modélisation ............................................................ 12
3. Programme de la formation............................................................. 13
7
8 3932 TG PA 01
Séquence 1
1. Introduction à l’analyse
1A. Pourquoi l’analyse ?

L’analyse informatique est un outil indispensable pour la programmation.
D’ailleurs, qu’est-ce que la programmation en informatique de gestion ? Cela consiste à
écrire un programme (par exemple, Windows, Word, Internet Explorer… sont des pro-
grammes) permettant de réaliser informatiquement les tâches de gestion d’une entre-
prise : la paye, le suivi de la clientèle, la facturation…
L’informatique n’a rien inventé, que ce soit en analyse ou en programmation. Si vous
voulez tapisser une pièce, vous achetez le papier peint, la colle, deux ou trois outils et
vous vous lancez. En revanche, si vous souhaitez bâtir une maison… J’espère que vous
n’achèterez pas les matériaux pour, hop ! commencer la construction.
La démarche habituelle consiste à faire un plan détaillé pour se mettre d’accord sur la dis-
position des pièces, leur nombre et leur superficie. Ensuite, on choisit les matériaux (bri-
que, parpaing…), les revêtements (moquette, parquet, carrelage…) et les coloris. Enfin,
après toutes ces étapes, on débute la construction. Le plan sera le document contractuel
de référence. Le constructeur ne va pas bâtir une maison selon votre description (« je
veux une belle maison, ensoleillée, plein sud, un grand séjour, trois chambres »), mais en
fonction du plan, étant entendu que le plan doit traduire exactement vos souhaits.
L’intérêt du plan vis-à-vis de votre description ? Un grand séjour ne veut pas dire grand-
chose, chacun ayant sa propre vision de ce qu’est une grande pièce. En revanche, une
pièce de 30 m2, tout le monde comprend.
Tous les corps de métiers concernés (plombiers, carreleurs, maçons, menuisiers…) se
référeront au plan pour réaliser leur tâche. Ils ne vous demanderont rien directement,
et heureusement car a priori vous n’êtes pas du métier donc seriez bien en peine de
répondre à leurs questions techniques.
1B. L’informatique de gestion

C’est la même chose en informatique de gestion : on ne doit pas se lancer bille en tête
dans la programmation, cela ne peut qu’échouer. Avant de commencer, il faut bien
comprendre ce que l’on doit faire, quelles sont les données que l’on utilise, comment
l’entreprise fonctionne. On fera cela grâce à l’analyse.
Schématiquement, il y a deux types d’informatique : l’informatique de gestion et l’infor-
matique scientifique.
En informatique scientifique, on fait surtout des mathématiques en programmant des calculs
complexes (intégrales, équations…). La difficulté est principalement de trouver une solution
mathématique, la programmation s’en suivant naturellement. Il n’y a pas de problème avec
les données, puisque l’on ne manipule que des chiffres. Par exemple, la météorologie utilise
l’informatique pour faire ses prédictions. La difficulté est de trouver les équations représen-
tant le plus fidèlement possible le temps. Ensuite, il n’y a plus qu’à les résoudre.
En informatique de gestion, c’est le contraire : il s’agit d’automatiser les tâches de
gestion de l’entreprise (classiquement la comptabilité, les relations client/fournisseur
– commandes, factures, relances –, la paie, la gestion de stocks…). Le programme est en
général assez simple ; en revanche, la difficulté est reportée dans la gestion des données.
8
8 3932 TG PA 01
Introduction
En effet, on va manipuler non plus de « bêtes » chiffres, mais des objets réels.
Voici quelques exemples classiques d’objets manipulés en gestion :
• un client, caractérisé par son nom, son adresse, son téléphone ;
• un produit, caractérisé par son nom, son type, sa marque, son prix ;
• un fournisseur, caractérisé par son nom et son adresse.
De plus, il va falloir gérer la façon dont tous ces objets interagissent entre eux.
Prenons l’exemple suivant :
L’entreprise que l’on étudie achète le produit Pomme de terre au fournisseur LaFritte,
épluche, coupe et cuit ce produit puis le revend au client MacRé.
Cela semble simple ? Certes ! Mais c’est un cas d’école. Dans la réalité, l’entreprise va
mettre en concurrence plusieurs fournisseurs par produit, elle livrera beaucoup de
clients, emploiera des acheteurs qui négocieront les prix auprès des fournisseurs et des
commerciaux qui tenteront de convaincre des prospects (clients potentiels) d’acheter
leurs produits. Bien entendu, acheteurs et commerciaux seront rémunérés avec un fixe
plus une commission proportionnelle à leur résultat et à leur ancienneté. Évidemment, il
faut tenir compte des différents contrats possibles (CDD, CDI, stage), des congés, arrêts
maladie… J’oubliais les états fiscaux à sortir, les déclarations de TVA, d’URSSAF.
Si maintenant je vous demande de me donner la liste des commerciaux ayant plus de cinq
ans d’ancienneté et ayant réalisé moins de 80 % de leur objectif, comment ferez-vous ?
Deux solutions : soit vous compulsez pendant des heures des classeurs pleins de chiffres
pour trouver ceux dont vous avez besoin, puis vous faites les calculs. Et si ce n’est plus
cinq ans d’ancienneté, mais dix ? Il faut tout refaire. Seconde solution, vous utilisez un
programme informatique et, en quelques secondes, vous obtenez le résultat.
Mais comment fera le programme ? Exactement comme vous, mais en plus rapide. Il va
prendre la liste des commerciaux et ne conservera que ceux qui ont plus de cinq ans
d’ancienneté. Pour chacun d’eux, il comparera l’objectif avec le résultat. Si ce dernier est
inférieur à 80 % de l’objectif, il l’imprimera. Et l’utilisateur obtient la liste.
On voit ici la complexité du stockage des données : avoir deux listes indépendantes, la
liste des commerciaux d’un côté et la liste de leur objectif de l’autre, cela n’apporte rien.
Ce qu’il faut, c’est obtenir, pour un commercial donné, l’objectif qui lui est fixé. Bref, on
a besoin de relier les données entre elles de façon cohérente.
De même, on ne peut pas mélanger clients et fournisseurs : pas question d’envoyer un
chèque au client au lieu d’une facture ! On peut multiplier les exemples à l’envi : que le
CNED possède toutes les notes des inscrits ne sert à rien s’il ne peut pas attribuer la note
à l’étudiant concerné.
L’entreprise possède donc des données (liste des clients, fournisseurs, produits, compta-
bilité), dont l’ensemble forme le système d’information de l’entreprise. C’est une posses-
sion immatérielle, au contraire de bâtiments, d’outils, de véhicules… mais c’est la plus
importante car elle est irremplaçable et unique.
9
8 3932 TG PA 01
Séquence 1
Cet exemple me permet de vous donner la définition suivante :

L’informatique de gestion consiste à gérer, manipuler et exploiter le système d’infor-
mation (les données) de l’entreprise pour chercher l’information utile.
Réaliser un programme de gestion passe par une étape essentielle : s’imprégner du fonc-
tionnement de l’entreprise et des données qu’elle manipule. Et cela n’a rien d’évident
car chaque entreprise a ses propres règles. Ensuite, il n’y a plus qu’à écrire le programme.
Si vous avez mal compris l’interconnexion des données entre elles, le programme ne
pourra pas fonctionner correctement.
Par exemple, si vous avez géré les commerciaux individuellement alors qu’ils sont regrou-
pés en équipe, vous ne pourrez pas leur affecter une prime globale. Vous serez obligé
d’attribuer individuellement la prime à chaque membre de l’équipe en espérant ne faire
aucune erreur de saisie qui entraînerait des primes différentes au sein de l’équipe.
De même, supposons une entreprise qui installe des panneaux publicitaires sur des murs ou
des terrains et les loue ensuite à des clients. Si vous voulez informatiser cette activité, vous
êtes bien d’accord qu’il vaut mieux savoir avant de commencer si un panneau peut avoir une
publicité différente par face ou ne possède qu’une face utilisable. En d’autres termes, va-t-on
associer un seul ou deux clients à chaque panneau ? Ce n’est pas du tout la même chose !
1C. Les méthodes d’analyse

Eh bien, tout cela, c’est un des rôleså de l’analyse : modéliser les données de l’entreprise
et leur interconnexion. Bien entendu, il y a deux problèmes :
1. Comment faire cela ?
2. Comment faire pour que la modélisation soit compréhensible donc utilisable par
d’autres personnes que son concepteur ?
Des théoriciens ont étudié ce problème et ont fourni des solutions : les méthodes d’ana-
lyse. Elles répondent aux deux problèmes précédents :
1. D’une part, elles fournissent une façon (méthode) pour représenter (analyser) les don-
nées de manière efficace et complète.
2. D’autre part, elles permettent une représentation codifiée et normalisée compréhensi-
ble par tous ceux qui connaissent la méthode en question. Un développeur peut alors
réaliser le programme en exploitant uniquement l’analyse, sans se référer au « monde
réel ». Cela simplifie énormément le travail. On retrouve parfaitement la notion de
plan pour la construction de la maison : le maçon se réfère au plan qu’il sait lire, et non
à vous qui ne pouvez que répéter « un grand séjour, hein ! Et, plein sud ! ».
Je vous propose la définition suivante.
Méthode d’analyse : technique de modélisation du réel utilisant une représentation nor-
malisée.
å En fait, les méthodes d’analyse modélisent les données mais aussi les traitements (ce que l’on fait).
Mais l’essentiel du travail reste la gestion des données, sur laquelle on travaille cette année.
10
8 3932 TG PA 01
Introduction
Cette définition n’a l’air de rien, mais, comme souvent, chaque mot possède un sens très
précis qu’il faut comprendre :
« Technique »
« Ensemble de procédés employés pour [...] obtenir un résultat déterminé. » (Petit Robert)
Cela signifie que l’utilisation d’une méthode d’analyse ne se fait pas « au pif », mais en
utilisant une démarche et des règles précises, qui sont l’objet de ce cours.
« Modélisation du réel »
Représentation simplifiée mais fiable (correcte) du monde réel, qui permet une compré-
hension plus aisée de la réalité.
« Représentation normalisée »
Permet que toute personne connaissant la méthode puisse lire la modélisation et donc
assimiler le réel sous-jacent.
Je reviens sur mon grand mot : l’informatique n’a rien inventé. Ce besoin de représenter
la réalité de façon précise et codifiée n’est pas nouveau. C’est le rôle du dessin technique
par exemple.
Le travail d’analyse, fait par un analyste, consiste donc à comprendre parfaitement le réel
(comment l’entreprise fonctionne, quelles données elle manipule, ce qu’elle fait), puis à le
représenter. Ce n’est pas du tout évident car il faut obtenir les informations, les agencer…
La représentation obtenue (l’analyse) sera la base de travail du programmeur, qui pro-
grammera ce qui est modélisé. Il n’aura donc pas à faire l’effort de comprendre le réel.
Pour un petit projet, analyse et programmation peuvent être faites par une seule per-
sonne : un analyste-programmeur. Mais cela ne veut pas dire qu’il faut négliger l’analyse.
Car, répétons-le encore, sans travail d’analyse, il n’y a pas de compréhension du réel ;
l’informatisation sera donc nécessairement un échec.
Pour un gros projet, on aura plusieurs personnes pour réaliser l’analyse, puis une équipe
de programmeurs créant le programme, d’autres personnes étant chargées des tests
pour vérifier que le programme respecte bien l’analyse.
2. La méthode Merise
Cette partie n’est qu’une sensibilisation aux principes de la méthode Merise. Ne vous
inquiétez pas si cela ne vous semble pas très clair. C’est normal puisque vous n’avez pas
encore commencé le cours. Il serait judicieux de relire cette partie dans quelques semai-
nes. Tout s’éclairera !
La méthode d’analyse la plus utilisée en France dans l’informatique de gestion est la
méthode Merise, développée en 1979 par des industriels et universitaires français. C’est
elle que nous étudierons dans ce cours.
Merise modélise séparément les données et les traitements. Expliquons ces termes.
2A. Données et traitements

Données
Ce sont les objets que l’on manipule et leur interaction (en cuisine, ce sont les ingré-
dients). La modélisation des données signifie leur description complète. C’est ici que l’on
dira que l’entreprise de location d’espaces publicitaires gère des panneaux et des clients,
que les panneaux ont une taille précise, sont implantés à une adresse donnée et suppor-
tent une ou deux publicités…
11
8 3932 TG PA 01
Séquence 1
Traitements
C’est ce que l’on fait (en cuisine, ce serait la recette). La modélisation des traitements
permet de décortiquer la façon dont le travail est fait, ce qui permet ensuite de l’infor-
matiser en écrivant un programme. C’est ici que l’on dira que l’entreprise de location
d’espaces publicitaires installe un panneau après avoir reçu une commande d’un client,
envoie la facture après l’installation du panneau et éventuellement une relance si la
facture n’est pas payée au bout d’un mois.
Chacune de ces modélisations (données et traitements) se fera en trois étapes successi-
ves, du plus abstrait au plus concret. Ces étapes, appelées niveaux de modélisation, sont
dans l’ordre le niveau conceptuel, le niveau logique et enfin le niveau physique.
De même, en construction, on va dessiner le plan d’une maison (conceptuel), puis on
choisit les matériaux (logique), enfin on réalise la construction (physique).
2B. Les trois niveaux de modélisation

Niveau conceptuel
On va représenter (modéliser) le réel indépendamment de tout choix matériel ou d’or-
ganisation de l’entreprise. Par exemple, concernant les traitements, on retiendra que la
facture est établie après l’envoi de la commande. Le fait que ce soit le service facturation
qui envoie cette facture est sans importance. On modélisera :
• d’une part les données, ce qui donnera le MCD, Modèle Conceptuel des Données ;
• d’autre part les traitements, ce qui donnera le MCT, Modèle Conceptuel des
Traitements.
Niveau organisationnel (ou logique)
On adapte le modèle du niveau conceptuel pour prendre en compte les contraintes
matérielles (matériel informatique disponible, contraintes diverses…).
• le MCD donnera le MLD, Modèle Logique des Données ;
• le MCT donnera le MOT, Modèle Organisationnel des Traitements.
Niveau opérationnel (ou physique)
On adapte le modèle du niveau organisationnel pour produire le programme en prenant
en compte le formalisme du langage choisi :
• le MLD donnera le MPD, Modèle Physique des Données ;
• le MOT donnera le MOPT, Modèle OPérationnel des Traitements.
On notera que, données et traitements étant indépendants, leur modélisation peut être
effectuée en parallèle par deux équipes distinctes. Notez également que le premier
niveau (le conceptuel) est indépendant de tout matériel informatique ou choix techni-
que. Un même MCD peut donc donner différents MLD et MPD selon les choix techniques
retenus. Idem entre le MCT et les MOT et MOPT.
Le niveau conceptuel est le plus complexe. Par exemple, le passage du MCD au MLD est suf-
fisamment simple pour pouvoir se faire automatiquement (par des programmes). Le MLD
est néanmoins important car il décrit l’organisation des données en fonction du program-
me utilisé pour les stocker. Jadis on utilisait des fichiers, maintenant on utilise des bases de
données personnelles (Access, Paradox) ou professionnelles (SQL Server, Oracle…).
12
8 3932 TG PA 01
Introduction
En pratique, une informatisation réussie suivra le schéma suivant (on laisse de côté les
traitements) :
Compréhension Développement
Élaboration Élaboration
du métier de la base
du MCD du MLD
à informatiser de données
3. Programme de la formation
En première année, on étudiera les niveaux conceptuels et logiques des données (c.-à-d.
les MCD et MLD).
En seconde année, vous étudierez le reste. Notons que, depuis 1979, les techniques et
outils de programmation ont évolué. La méthode Merise également. Vous verrez donc
aussi en seconde année les extensions de Merise.
Vous pouvez maintenant apprécier la cohérence de l’organisation de vos cours :
• vous devez étudier l’analyse et l’algorithmique en parallèle ;
• ces deux savoirs étant acquis, vous pouvez ensuite étudier Access.
On retrouve le schéma de développement précédent : d’abord l’analyse puis la création
de la base de données. Les cours d’informatique ne sont pas du tout indépendants !
Comme promis, le paragraphe suivant synthétise toutes les informations importantes de
cette séquence. Il faut donc l’apprendre !
13
8 3932 TG PA 01
Synthèse
L’informatique de gestion consiste à gérer, manipuler et exploiter le système d’in-

formation (les données) de l’entreprise pour chercher l’information utile.
Une méthode d’analyse est une technique de modélisation du réel utilisant une
représentation normalisée.
La méthode d’analyse Merise modélise de façon séparée les données (les infor-
mations que l’on manipule et leurs interactions) et les traitements (ce que l’on
fait avec ces données). Données et traitements sont modélisés par trois niveaux
successifs, du plus abstrait au plus concret : conceptuel, organisationnel, opéra-
tionnel.
Le tableau ci-dessous résume les productions fournies à chaque étape.
Niveau Données Traitements

Conceptuel représente la perception MCD MCT
du réel sans se préoccuper des moyens Modèle Conceptuel Modèle Conceptuel
d’implantation des Données des Traitements
Organisationnel MLD MOT
spécification du niveau organisationnel Modèle Logique Modèle Organisationnel
avec les choix techniques (langages…) des Données des Traitements
Opérationnel prise en compte MPD MOPT
des moyens physiques d’implantation Modèle Physique des Modèle OPérationnel
Données des Traitements
Les trois étapes MCD, MCT et MLD sont incontournables. L’essentiel de la forma-
tion portera sur elles.
15
8 3932 TG PA 01
Séquence 2
MCD : les concepts de base 1/2
Dans cette séquence, nous allons étudier une partie des constituants élémentaires
du MCD. Nous allons apprendre ce que sont les entités, les propriétés et les associa-
tions. Nous verrons également comment représenter graphiquement ces notions.
u Capacités attendues
• Maîtriser le vocabulaire de Merise
• Assimiler les concepts véhiculés par ces termes
• Représenter graphiquement un MCD
u Contenu
1. Analyse du sujet ................................................................................... 18
2. Les entités ............................................................................................... 19
2A. Présentation ................................................................................................ 19
2B. Représentation graphique ......................................................................... 20
3. Les propriétés ........................................................................................ 21

3A. Définition .................................................................................................... 21
4. Les associations ..................................................................................... 23

4A. Présentation ................................................................................................ 23
5. Compléments ......................................................................................... 26
Synthèse
17
8 3932 TG PA 01
Séquence 2
1. Analyse du sujet
Nous allons travailler sur l’exemple suivant :
Le Cned vous demande de réaliser le MCD de la gestion des inscriptions de l’année sco-
laire courante en vue de son informatisation.
Bien, cela ne semble pas sorcier ! Si vous lisez ce document, c’est que vous vous êtes
inscrit au Cned ; vous connaissez donc la démarche de l’inscription, vous avez lu les con-
signes pour l’envoi des devoirs… sur cet exemple précis, vous avez donc l’avantage de
connaître déjà le « monde réel » que l’on veut modéliser.
Peut-on donc passer immédiatement à la modélisation des données ? Non, car il y a plu-
sieurs choses à préciser ! Relisons le sujet :
« de l’année scolaire courante »
Cela signifie que le Cned ne conserve pas l’historique des inscriptions des années précé-
dentes (on dira que l’on n’historiseå pas). En fin d’année scolaire, les données relatives
aux inscriptions sont détruites. Cette précision est importante car la modélisation sera
différente selon que l’on historise ou pas.
« gestion des inscriptions »
Déjà une remarque : on ne parle que d’inscription. Inutile donc de gérer les copies, les
notes… En première approximation, la phrase du sujet signifie qu’une personne va payer
pour suivre un cours. L’objectif sera donc de gérer le lien entre les personnes et les cours
pour savoir qui s’est inscrit à quoi. Cela permettra notamment d’envoyer les cours corres-
pondant à l’inscription. Mais qu’appelle-t-on une personne ? Déjà, il vaut mieux être pré-
cis ! Les personnes concernées ne sont pas n’importe qui dans la rue, mais quelqu’un qui
suit une formation. On utilisera donc plutôt le terme d’étudiant.
De même, qu’est-ce qu’un cours ? Deux possibilités.
• Ce peut être une formation (par exemple BTS informatique de gestion).
• Ce peut être un module inclus ou non dans une formation (par exemple ce module
d’analyse, inclus dans la formation BTS). On pourrait ruser en disant que l’inscription à
une formation signifie l’inscription à chacun de ses modules. Mais c’est une bien pau-
vre ruse, puisque cela obligerait le secrétariat à vous inscrire aux cours de français, de
maths, d’anglais, d’économie, d’analyse, de programmation… au lieu de vous inscrire
simplement à la formation BTS informatique de gestion. Dans le monde réel (dans la
« vraie vie »), vous pouvez vous inscrire :
• à une formation, comme le BTS informatique de gestion ;
• à un module d’une formation comme Préparation à l’épreuve pratique, issu du BTS
informatique ;
• à un module indépendant comme maîtrise de l’anglais ou initiation à l’informatique.
Vous remarquerez qu’un sujet d’une ligne peut amener à un travail poussé ! Nous allons tem-
porairement simplifier et dire que le Cned ne gère que les inscriptions à des cours indépen-
dants. Autrement dit, on ne gère pas la notion de formation regroupant plusieurs cours.
« Le Cned vous demande »
Quoi, il faut aussi décortiquer cette petite phrase toute simple ? Oui et non ! Il s’agit juste
de préciser que l’on veut modéliser l’intérieur du Cned. On ne va donc pas représenter
å Ce mot est un néologisme, inutile de le chercher dans le dictionnaire !
18
8 3932 TG PA 01
le Cned lui-même, qui reste implicite. Et, bien entendu, on modélise le fonctionnement
du Cned et non celui de votre ancien lycée. Donc attention à ne pas inventer des infor-
mations qui n’existent pas.
2. Les entités
2A. Présentation
Bien. Après une demi-page d’explications, on peut enfin produire le schéma suivant :
étudiant cours
Rien d’impressionnant. La flèche représente le lien entre un étudiant et un cours, à savoir
qu’un étudiant s’inscrit à un cours. Cependant, on pourrait tout aussi bien dire qu’un
cours est suivi par un étudiant. Bref, si l’étudiant est relié au cours, alors le cours est éga-
lement relié à l’étudiant. Le nouveau schéma sera alors :
étudiant cours
Bien, on progresse ! Mais en fait, à quoi sert une flèche ? À indiquer une direction. Ainsi,
le fait de mettre une flèche de chaque côté signifie finalement qu’il n’y a pas de sens
privilégié puisque le lien entre étudiant et cours peut se lire dans les deux sens. Dans ce
cas, on simplifie en ne mettant aucune flèche ! Ce qui donne :
étudiant cours
Maintenant, soyons réalistes : ce schéma représente-t-il toutes les données nécessaires
à la gestion des inscriptions ? Il faut bien avouer que non ! Concrètement, qui sont les
étudiants ? À quels cours sont-ils inscrits ? Informatique, économie, anglais ?
Si vous voulez gérer les étudiants et les intégrer dans votre base de données, c’est pour
leur envoyer les cours. Il faut donc un nom et une adresse pour chaque étudiant. Bien
entendu, un étudiant possède d’autres données : un numéro de téléphone, une date
de naissance… mais aussi des références bancaires, des parents, une formation scolaire,
peut-être un permis de conduire, un aliment préféré, etc. Cette énumération a pour
objet de bien vous faire comprendre qu’un étudiant est caractérisé par beaucoup (voire
une infinité) de données. Quand on parle de décrire un étudiant, ce n’est donc pas dans
l’absolu, mais en fonction de « l’usage » que l’on en fera. On ne lui attribuera pas les
mêmes caractéristiques selon que l’on veut représenter l’étudiant :
• dans le système d’information Gestion des inscriptions au Cned ;
• dans le système Sécurité Sociale étudiante ;
• dans le système Prêt étudiant d’une banque…
Dans notre exercice, on aura besoin des nom et prénom de l’étudiant et de son adresse
(rue, code postal et ville). On peut se poser la question de stocker le numéro de télé-
phone ou une adresse e-mail. Si vous informatisiez réellement les inscriptions, vous
demanderiez au responsable du Cned s’il désire (s’il a besoin de) ces informations.
Dans un devoir (ou l’examen du BTS), vous aurez plus ou moins clairement la liste des
informations nécessaires : certaines seront tout à fait explicites, tandis que d’autres ne se
laisseront débusquer qu’après une lecture très attentive du sujet. Cela fait partie de la
difficulté de l’exercice.
19
8 3932 TG PA 01
Séquence 2
O Leen fait de mettre un maximum d’informations partant du principe qu’il vaut mieux
mettre dix de trop qu’en oublier une n’est pas acceptable. D’une part ce n’est
pas intellectuellement défendable (on masque une incompréhension du modèle
par une profusion d’informations), d’autre part une telle démarche vous conduirait
à demander à l’étudiant de fournir des informations qui seraient sans rapport avec
l’inscription, ce qui ne lui plairait pas.
2B. Représentation graphique

Reprenons : un étudiant est caractérisé par ses nom, prénom et adresse. On va représenter
cela dans notre schéma. Le formalisme sera le suivant :
Ceci est une notation normalisée de Merise : dans un rectangle, on
ÉTUDIANT
met le nom d’un « objet », puis on tire un trait et l’on met la liste des
Nom caractéristiques utiles en dessous, qu’il y en ait une… ou cinquante, sans
Prénom ordre particulier.
Rue Le nom de l’objet est au singulier ; c’est sans importance pour l’instant,
Code postal on abordera ce point plus tard. Par contre, le fait d’écrire le nom de
Ville l’objet en majuscules est un choix personnel : je trouve cela plus lisible.
Tant qu’on y est, on va donner un nom plus professionnel que rectangle ou objet à cette
représentation : on dira qu’Étudiant est une entité, de même que Cours. La définition suit !
Entité : « Objet considéré comme un être doué d’unité matérielle […] » (Petit Robert).
Une entité est une « chose » du monde réel qui possède une existence propre (concrète
ou abstraite), des caractéristiques bien définies, qui présente un intérêt et a un sens
pour le système d’information étudié.
Encore une fois, il nous faut expliquer les mots de cette définition.
« chose du monde réel »
L’objectif de l’analyse est d’informatiser des activités humaines réelles. Ces activités
exploitent des données complexeså : un médecin ne traite pas un numéro de Sécurité
Sociale, mais un patient, décrit entre autres par ce numéro, un nom, un prénom… Ce
concept est à rapprocher des données structurées que vous verrez en programmation.
« possède une existence propre »
C’est une conséquence directe de l’expression précédente (« chose du monde réel »). Je
l’ai répété pour bien vous faire assimiler le fait qu’il s’agit de gérer des entités qui exis-
tent vraiment, qui sont cohérentes. D’où la notion d’unité matérielle.
« caractéristiques définies »
On manipule des objets réels ; il faut pouvoir les décrire complètement afin de les stocker
correctement dans le système d’information. Notons bien que seules les caractéristiques
utiles à l’entreprise seront retenues (en non toutes les caractéristiques décrivant l’entité
dans l’absolu). Ainsi la même entité pourra être valablement définie avec des caracté-
ristiques différentes dans deux systèmes d’information (par exemple une banque et une
entreprise de formation représenteront différemment l’entité Client).
« un intérêt et un sens pour le système d’information étudié »
C’est toujours la même chose : un objet réel possède des caractéristiques qui le décrivent com-
plètement, mais aussi une fonction précise, qui dépendra de ce que l’on veut informatiser.
å Complexe, dans le sens « qui contient, qui réunit plusieurs éléments différents ».
20
8 3932 TG PA 01
Un exemple classique : un grossiste a comme fournisseurs et comme clients des entreprises.

Aura-t-on une seule entité Entreprise ou deux entités Fournisseur et Client ? Certes, les four-
nisseurs et les clients ont, en tant qu’entreprises, les mêmes caractéristiques (un nom, une
adresse…). Mais leur fonction, donc leur sémantique, est distincte (voire opposée). On aura
donc deux entités différentes. Parmi tous les objets qui existent, on ne retiendra que ceux
qui sont utiles à l’entreprise et on les décrira d’après les données que cette dernière utilise.
On retiendra donc toujours le point de vue de l’entreprise.
« existence concrète ou abstraite »
C’est un point assez complexe, où les non-informaticiens achoppent. Nous venons de voir
assez longuement que les entités étaient des objets cohérents manipulés par le système
d’information. Mais il en existe de deux types.
• Les entités concrètes, qui ont une existence physique tangible. Elles ne posent pas de
problème car on identifie facilement un fournisseur, un client ou un patient comme
autant d’entités.
• En revanche, l’entreprise manipule d’autres entités qui n’ont pas forcément une exis-
tence tangible : les factures (qui ne sont physiquement que des feuilles de papier), mais
aussi des impayés, qui sont un concept abstrait mais crucial pour toute entreprise.
Pour fixer les idées, voici une définition moins théorique, mais regroupant les notions
vues plus haut :
Une entité est un objet cohérent vu (décrit) avec l’œil de l’entreprise étudiée.
Pour faire le MCD, on devra notamment structurer les informations en les regroupant
pour former des entités. C’est là qu’intervient l’entraînement et l’intelligence de l’ana-
lyste : il n’est pas toujours évident de bien cerner les contours des entités, d’autant qu’il
n’existe pas de technique rigoureuse. Il faut travailler par intuition.
3. Les propriétés
3A. Définition
Propriété : donnée élémentaire et pertinente pour le système d’information étudié. Le
regroupement cohérent de propriétés définit les entités. Symétriquement, une entité
sera décrite par ses propriétés.
C’est maintenant devenu une coutume… revenons sur quelques termes de cette définition :
« donnée pertinente pour le système d’information »
Nous l’avons déjà dit, on ne retient que les informations utiles à l’entreprise que l’on
informatise.
« donnée élémentaire pour le système d’information »
Voici un point théorique très discuté. Une donnée élémentaire est une donnée que l’on
ne peut plus décomposer (c’est l’équivalent d’un corps simple en chimie). Dit autrement,
si l’on décompose une donnée élémentaire, on n’obtient plus rien de significatif.
Par exemple, mon nom complet « Jean-Yves Février » n’est pas une donnée élémentaire,
puisque je peux le décomposer en « Jean-Yves » (mon prénom) et « Février » (mon nom).
En revanche, mon prénom et mon nom sont élémentaires puisqu’en les décomposant, je
n’obtiens qu’un groupe de lettres sans signification.
21
8 3932 TG PA 01
Séquence 2
Les données doivent être décomposées pour que l’informatisation se passe bien. Je ne
peux vous le démontrer, mais, de façon informelle, vous serez d’accord qu’il est plus sim-
ple d’accéder à un prénom s’il est directement fourni que s’il faut aller le chercher dans
une suite de mots.
Si l’on s’arrête à ce point de la définition, l’adresse « 1, boulevard Jean-Jaurès 54000
NANCY » n’est pas du tout élémentaire.
Exercice 1
D’ailleurs, pourriez-vous décomposer cette adresse en données élémentaires ?
Le corrigé de l’exercice montre qu’il y a de nombreuses façons de considérer l’aspect élémen-

taire des données. Pour régler le problème, il suffit de bien lire la définition : donnée élémen-
taire pour le système d’information. Cette nuance passe hélas souvent à la trappe. Ainsi,
on dira qu’une donnée est élémentaire pour le système d’information si sa décomposition ne
donne rien de significatif (d’utile) pour le système d’information étudié.
Donc, je ne le répéterai jamais assez, on ne prend en compte que les références de l’en-
treprise que l’on informatise pour savoir jusqu’où décomposer les données. Ce qui est
considéré comme élémentaire dans un cas ne le sera pas forcement dans un autre.
O Ild’une
ne s’agit pas de passer des heures à s’interroger sur l’éventuelle non-élémentarité
donnée. La difficulté n’est pas là. Il suffit d’utiliser son bon sens.
Exercice 2
Pourriez-vous nommer les propriétés de l’entité Étudiant du système d’information étudié
(inscriptions au Cned) ?

Il n’y a rien à en dire puisque la représentation de l’entité comprenait déjà celle des
propriétés ! Reprenons l’entité Étudiant vue dans le paragraphe 2B. en expliquant avec
les termes techniques la représentation graphique :
Dans un rectangle, on met le nom de l’entité, puis on tire un trait et

ÉTUDIANT
l’on met la liste des propriétés en dessous sans ordre particulier.
Nom
Prénom
Rue
Code postal
Ville
Revenons sur notre gestion des inscriptions. Après l’étude d’Étudiant, occupons-nous de
Cours. Il vous faut toutes les informations relatives à un cours. Vous demandez au res-
ponsable du Cned ce qui caractérise un cours. On vous répond qu’un cours possède un
titre et une durée en mois.
(On est d’accord que, face à un non-informaticien, vous éviterez d’employer des mots
tels que entité et propriété qui n’ont de sens que pour un analyste.)
22
8 3932 TG PA 01
Exercice 3
1. Le fait qu’un cours soit une entité dans le système étudié doit être assez naturel. Mais, à
votre avis, est-ce une entité concrète ou abstraite ?
2. Imaginez deux informaticiens discutant. Le second répond au premier « titre et durée en
mois ». Quelle était la question du premier ? (Utilisez les termes techniques.)
3. Dessinez l’entité Cours d’après le formalisme Merise.
4. Les associations
4A. Présentation
Bien. Dans notre schéma, j’ai remplacé les mots étudiant et cours par des entités. Nous
obtenons alors :
ÉTUDIANT
Nom COURS
Prénom
Rue Titre
Code postal Durée
Ville
Je ne connais pas votre façon de travailler. Peut-être que vous n’avez pas posé ce docu-
ment depuis que vous l’avez commencéå. En revanche, moi, j’ai fait une pause et viens
de reprendre la rédaction après deux jours d’interruption. Et je vous avouerai que le trait
entre les deux entités… je ne sais plus trop s’il signifie inscription, demande de rensei-
gnements ou autre. J’ai été obligé de relire les pages précédentes pour m’assurer de sa
signification (il représente une inscription).
C’est assez ennuyeux car dans un schéma réel, on aura d’autres intervenants en plus des
étudiants et des cours et ces intervenants seront reliés entre eux. On aurait donc une ou
plusieurs dizaines de traits ? Tout ceci serait complètement illisible.
Le formalisme Merise impose donc de nommer les traits. De façon assez logique, on va
leur donner un nom proche de leur fonction. Ainsi, le trait entre un étudiant et un cours
signifie que l’étudiant est inscrit à un cours.
å Et dans ce cas, je me demande si vous avez vraiment pu assimiler tout ce que l’on a vu ! Mine de rien,
il y a déjà beaucoup de concepts et de définitions.
23
8 3932 TG PA 01
Séquence 2

On obtiendra donc le schéma suivant :
ÉTUDIANT
Nom COURS
Prénom s’inscrire à
Rue Titre
Code postal Durée
Ville
Notons le formalisme Merise : le nom du lien est écrit dans un ovale.
Devinez ! Je vais vous donner une définition formelle d’un lien. Et, du coup, on oubliera
le mot lien au profit d’association.
Association : une association représente un lien sémantique entre des entités. On
parlera d’association binaire (ou plus simplement de binaire) si elle relie deux enti-
tés, de ternaire si elle relie trois entités…
Exceptionnellement, il y a peu de choses à expliquer. Le lien sémantique représente les
interactions des entités entre elles. On ajoute le terme sémantique car le lien vient du
sens des entités : si on relie l’entité Étudiant à Cours, c’est à cause de ce que représentent
les étudiants et les cours dans le monde réel.
On notera que l’association se fait entre plusieurs entités (au minimum deux, pas de
maximum). En pratique, on aura quasi exclusivement des binaires et des ternaires. Une
association quaternaire (4 entités) ou plus peut exister, mais c’est souvent une erreur de
conception.
Il semble y avoir une différence fondamentale entre entité et association ; pourtant, nous
verrons que pour modéliser certains objets, on peut valablement hésiter entre une entité
ou une association. Je vous l’avais promis : l’analyse est un loisir créatif.
On notera que l’association est un lien sémantique ; rien n’empêche qu’une entité soit
reliée par plusieurs associations, chacune représentant un lien. (On y reviendra.) Bien. On
progresse ! Mais on a vu il y a « longtemps » (quand on en était encore à relier les mots
étudiant et cours par une flèche) que l’association entre les deux entités est symétrique.
D’ailleurs, j’ai placé Étudiant à gauche et Cours à droite, mais je pourrais faire le contraire
puisqu’il n’y a pas d’ordre entre les deux concepts. Cela donnerait le schéma qui suit.
ÉTUDIANT
COURS Nom
s’inscrire à Prénom
Titre
Rue
Durée
Code postal
Ville
C’est toujours juste… mais un peu déroutant à la lecture, qui se fait habituellement de
gauche à droite. On préférera alors nommer l’association en prenant le cours comme
sujet, soit « est suivi par », comme dans le schéma page suivante.
24
8 3932 TG PA 01
ÉTUDIANT
COURS Nom
est suivi par Prénom
Titre
Rue
Durée
Code postal
Ville
On est confronté à un problème qui n’est pas du tout évident : essayer de nommer l’as-
sociation en fonction de la position des entités dans le schéma. Notre raisonnement va
d’ailleurs nous mener à une impasse car :
1. Il n’est pas question de privilégier arbitrairement une entité ou une autre pour donner
le sens de lecture. Si l’on peut dire ici qu’Étudiant l’emporte sur Cours (un étudiant est
un humain, donc on va nommer le lien « s’inscrire à »), on ne va pas lancer de débat
théorique pour savoir qui l’emporte entre Facture et Produit.
2. La façon dont on dispose les entités (Étudiant à gauche, Cours à droite ou l’inverse)
est uniquement guidée par la lisibilité du schéma : si Cours n’est lié qu’à Étudiant, on
aura tendance à le mettre sur un bord. En revanche, si Cours est lié à d’autres entités
(par exemple Correcteur, Rédacteur…), on le mettra au centre pour pouvoir tracer les
associations sans qu’elles se chevauchent. En pratique, la position de Cours par rapport
à Étudiant sera quelconque (une entité sous l’autre, en diagonale…)
Ainsi, un MCD n’aura pas de sens de lecture prédéfini (notamment pas de haut en bas et
de gauche à droite). On évitera donc d’ajouter artificiellement un ordre de lecture par
le nom des liens. La solution sera d’utiliser un verbe à l’infinitif.
Ici, on pourra utiliser s’inscrire ou suivre, et on ne relancera pas le débat pour savoir lequel
de ces deux verbes est le plus adéquat. En effet, je vois chaque année des étudiants passer
plus de temps à choisir un nom d’entité ou d’association qu’à élaborer le MCD lui-même. Or,
ces noms ne servent qu’à se repérer dans le schéma. Mettre s’inscrire, suivre, apprendre… est
totalement indifférent. L’essentiel est d’avoir un descriptif compréhensible et lié à l’associa-
tion que l’on décrit (on ne mettrait pas vendre, nourrir ou soigner entre Cours et Étudiant !).
Pour illustrer cela, vous trouverez ci-après trois représentations différentes, mais tout à
fait correctes, de notre schéma.
COURS
ÉTUDIANT
Titre
Nom COURS
suivre Durée
Prénom
Titre
Rue
Durée
Code postal apprendre
Ville
COURS ÉTUDIANT
ÉTUDIANT
Titre Nom
Durée Nom Prénom
Prénom Rue
s'inscrire Rue Code postal
Code postal Ville
Ville
25
8 3932 TG PA 01
Séquence 2
On remarque en passant que l’association reliant les deux entités peut s’articuler, la seule
contrainte étant que les entités soient clairement reliées. On ne s’autorisera néanmoins
que des segments de droites et aucune courbe.
Enfin, on s’obligera à écrire horizontalement et de gauche à droite tous les noms d’entités
et d’associations. Sinon, le modèle serait illisible. Cette association est donc proscrite :
COURS
Titre
Durée
Apprendre
ÉTUDIANT
Nom
Prénom
Rue
Code postal
Ville
Bien, nous avons presque terminé.
5. Compléments
L’étudiant Jean Dupond s’inscrit au cours initiation à Internet. Comment vais-je le repré-
senter dans mon schéma ?
Eh bien, je ne le représente pas ! Ce qui m’intéresse dans le MCD, c’est l’interconnexion
des données entre elles (un étudiant s’inscrit à un cours) indépendamment des données
elles-mêmes (quel étudiant s’inscrit à quel cours).
Pourtant, l’intérêt de l’informatisation des inscriptions est d’obtenir la liste des étudiants
à un cours donné. Comment faire le lien entre la représentation théorique des associa-
tions entre les entités et les données réelles ?
Ce sera le rôle des autres niveaux de modélisation (si vous avez joué le jeu et appris le
cours, vous comprenez de quoi je parle). Par exemple, le MLD décrira la façon dont les
données réelles seront stockées.
Ainsi, c’est le MLD qui va déterminer comment je vais stocker :
• l’étudiant Jean Dupond (et tous les autres) ;
• le cours initiation à Internet (et tous les autres) ;
• le fait que M. Jean Dupond soit inscrit au cours initiation à Internet (et toutes les
autres inscriptions).
26
8 3932 TG PA 01
Synthèse
Je vous rappelle pour la dernière fois que la synthèse reprend toutes les notions
imprimées en vert ; il faut donc l’apprendre.
Les définitions
Entité : une entité est une « chose » du monde réel qui possède une existence
propre (concrète ou abstraite), des caractéristiques bien définies, qui présente un
intérêt et a un sens pour le système d’information étudié.
Dit autrement : une entité est un objet cohérent vu (décrit) avec l’œil de l’entre-
prise étudiée.
Propriété : donnée élémentaire et pertinente pour le système d’information étu-
dié. Le regroupement cohérent de propriétés définit les entités. Symétriquement,
une entité sera décrite par ses propriétés.
On ne prend donc en compte que les références de l’entreprise que l’on informa-
tise pour savoir jusqu’où décomposer les données. Ce qui est considéré comme
élémentaire dans un cas ne le sera pas forcement dans un autre.
Association : une association représente un lien sémantique entre des entités.
On parlera d’association binaire (ou plus simplement de binaire) si elle relie deux
entités, de ternaire si elle relie trois entités…
Dans tout travail d’analyse, il faut prendre le point de vue de l’entreprise étudiée.
27
8 3932 TG PA 01
Séquence 3
Dans cette séquence, nous allons étudier les derniers constituants élémentaires
du MCD. Nous allons apprendre ce que sont les occurrences, les identifiants et
les cardinalités. Nous verrons également comment représenter graphiquement
ces notions, puis une technique assez empirique pour construire un MCD à partir
d’un sujet.
• Représenter graphiquement un MCD
• Se doter d’une démarche rigoureuse pour pouvoir bâtir un MCD
u Contenu
1. Les occurrences...................................................................................... 30
1A. Occurrence d’entité .................................................................................... 30
1B. Occurrence d’association ........................................................................... 31
2. Les identifiants ...................................................................................... 32

2A. Approche par le MLD ................................................................................. 32
2B. Identifiant d’une entité ............................................................................. 37
2C. Identifiant d’une association ..................................................................... 39
3. Interlude : comment construire un MCD (1)............................... 40

4. Les cardinalités ...................................................................................... 41
4A. Présentation par l’intuition ....................................................................... 41
4B. Définition des cardinalités ......................................................................... 44
4C. Les différentes cardinalités ....................................................................... 46
4D. Distinguons les cardinalités maximales.................................................... 47
5. Interlude : comment construire un MCD (2)............................... 48
Synthèse
29
8 3932 TG PA 01
Séquence 3
1. Les occurrences
1A. Occurrence d’entité

Oh non, encore une ? Euh, oui, encore une petite définition. Et en plus, c’est une défi-
nition très importante car en apparence évidente, mais du coup souvent oubliée et qui
entraîne des erreurs sur d’autres concepts.
Je vous préviens que le concept est évident, mais que je n’ai pas réussi à trouver une
définition simple. Heureusement tout s’éclaircira avec les explications et les exemples.
Occurrence d’entité : une occurrence d’entité est une réalisation (concrétisation) de
cette entité.
Vite, on explique.
« réalisation (concrétisation) de cette entité »
Je vous ai parlé d’entités concrètes et abstraites. C’était un abus de langage dans la
mesure où la notion même d’entité est abstraite. Cela devient de la philosophie, mais
l’entité Étudiant (le concept d’étudiant) est une abstraction. Seuls existent des étudiants
physiques. Dire que Jean Dupond est un étudiant est un raccourci pour dire « Jean
Dupond fait partie de l’ensemble des étudiants » et non « Jean Dupond est un synonyme
d’étudiant ». En fait, vous le saviez, car Jean Dupond est une invention de ma part, mais
cela ne signifie pas que les étudiants n’existent que dans ma tête.
De même un chat. J’aime beaucoup Pollen, mon chat, mais je sais que ce n’est pas Le
Chat, personnification, incarnation de toute la race des chats. En fait, Le Chat n’existe
pas. Seules existent physiquement des choseså qui font partie de la famille des chats.
Et comment peut-on dire que la chose qui s’appelle Pollen fait partie de la famille des
chats, et non de celle des teckels sympas et fins gourmets ? Parce que l’on connaît les
caractéristiques (propriétés) de la famille des chats, et que le petit Pollen, brave animal,
possède ces caractéristiques.
Eh bien, on peut reprendre le vocabulaire précis de l’analyseç pour dire que :
• la famille des chats se modélise par l’entité Chat ;
• mon petit Pollen est une occurrence de Chat.
Bien entendu, je ne demande pas à mon occurrence de Femme si elle a donné des occur-
rences de Croquette à notre occurrence de Chat. Cela ferait pédant. Mais pourtant, c’est
ce qu’il faudrait dire. Cette longue explication était nécessaire car très bientôt, on va
jongler entre les entités et les occurrences.
å Oui, il n’y a plus de limite. J’avais commencé par écrire « seuls existent des animaux qui font
partie […] », mais, de la même façon, l’Animal n’existe pas. On peut juste dire qu’il existe des
choses faisant partie de la famille des animaux, et encore, il n’existe pas de Chose, mais seulement
des occurrences de Chose. (Et ne me dites pas qu’une Occurrence n’existe pas, mais juste des occur-
rences d’Occurrence, car là, je craque.)
ç Ceci est la démonstration que l’on ne définit pas des termes pour le plaisir. Ces subtilités
sont obligatoires en analyse car on manipule autant les types d’objets que les objets eux-mêmes.
Heureusement, cette précision dans les termes n’a aucun intérêt dans la vie courante.
30
8 3932 TG PA 01
Faisons un petit détour par l’algorithmique (programmation) : on va retrouver le même

principe.
Quand vous déclarez une variable : On lit « i est un entier » mais cela signifie « i fait partie de la famille
var i : entier des entiers » et non « i est l’entier ». (sinon on aurait le syllogisme 0
est un entier, 1 est un entier donc 0 est 1 !)
Quand vous écrivez un test : Là, on dit « si a égale b », mais on pourrait dire « si a est b » car il
si a = b alors s’agit vraiment d’une équivalence absolue (d’ailleurs, vous savez
depuis longtemps que si a = 2 et a = b, alors b = 2).
On retrouve mon grand mot : non seulement, l’informatique n’invente rien, mais en plus
les mêmes concepts se retrouvent d’une discipline informatique à l’autre.
Exercice 4
Vous vous doutez sans doute de la question ! Citez-moi une occurrence d’Étudiant (sous-
entendu : une occurrence de l’entité Étudiant). Et, tant qu’à faire, pouvez-vous m’en donner
une seconde ?
Au vu de la correction de l’exercice 4, il est bon de préciser ce qui suit :

Une occurrence d’entité aura une valeur pour chaque propriété de l’entité. L’ensemble
de ces valeurs caractérise cette occurrence.
Exercice 5
Après avoir lu le corrigé de l’exercice précédent, donnez trois occurrences de l’entité Cours.
Le concept d’occurrence d’entité nous permet de justifier pourquoi le nom de l’entité

doit être au singulier.
Le nom de l’entité est au singulier car l’entité (le concept) est unique. Il n’y aura pas deux
entités Étudiant. Mettre un pluriel serait une confusion entre les occurrences de l’entité
et l’entité elle-même. En effet, s’il n’y a qu’une entité Étudiant, il y aura plusieurs occur-
rences d’Étudiant.
1B. Occurrence d’association
Exercice 6
Sans lire ce qui suit, essayez de donner une définition d’« occurrence d’association », sachant
que c’est tout à fait similaire à l’occurrence d’entité. Essayez de donner ensuite une occurrence
de l’association suivre (entre Étudiant et Cours) de notre MCD.
31
8 3932 TG PA 01
Séquence 3
Occurrence d’association : une occurrence d’association est une réalisation (concré-

tisation) de cette association.
Eh oui, la définition est similaire ! Mais le concept sous-jacent est moins simple. Que
peut-on appeler une réalisation d’association ? On va essayer de trouver un exemple.
Une occurrence d’entité revient finalement à renseigner (donner des valeurs) aux dif-
férentes propriétés. Dans ce cas, le concept d’occurrence d’association étant similaire, il
reviendrait à donner des valeurs aux propriétés de l’association. Le problème, c’est que
l’association n’en a pas (rassurez-vous, cela ne durera pas !). Cependant, nous avons dit
qu’une association reliait des entités. Donner une occurrence d’association reviendra
donc à donner une occurrence de chaque entité reliée.
Concrètement, l’association suivre représente le fait qu’un étudiant suit un cours. Une
occurrence de suivre sera constituée de deux choses :
• un étudiant donné (soit une occurrence d’Étudiant), tel Dupond/Jean/1, bd Jean-
Jaurès/54000/NANCY ;
• l’un des cours qu’il suit (soit une occurrence de Cours), tel Initiation à Internet/2.
Une occurrence de suivre sera donc Dupond/Jean/1, bd Jean-Jaurès/54000/NANCY//
Initiation à Internet/2.
Si Jean Dupond est inscrit à deux cours (Initiation à Internet et Analyse), l’occur-
O rence de suivre ne sera pas Dupond/Jean/1, bd Jean-Jaurès/54000/NANCY//Initiation
à Internet/2//Analyse/9, mais…
Exercice 7
Comment faire pour représenter l’inscription de Jean Dupond à ces deux cours ?
On retiendra ce qui suit :

Sur le MCD, une association relie des entités. En revanche, une occurrence d’asso-
ciation ne concerne que des occurrences d’entités. Elle sera formée par une (et une
seule) occurrence de chaque entité reliée.
2. Les identifiants
2A. Approche par le MLD
Ce n’était pas prévu, mais nous allons passer temporairement au MLD (vous êtes sensé
savoir exactement ce que c’est !).
Le MCD permet d’indiquer comment les données structurées (les entités, pas les données
réelles que sont les occurrences) sont reliées entre elles.
Le MLD va indiquer, pour un mode de stockage donné, de quelle façon on va organiser
les données physiques (réelles, donc les occurrences) pour maintenir les liens établis dans
le MCD.
Cela doit vous paraître plus clair que lors de l’introduction du cours ! Et cela va l’être
encore plus dans les lignes qui suivent.
32
8 3932 TG PA 01
Nous avons dit dans l’introduction que le MCD donnait naissance à des MLD différents
selon le mode de stockage choisi. Jadis, le mode de stockage était les fichiers. Depuis
l’avènement des bases de donnéeså, on n’utilise plus qu’elles. L’avenir nous fournira
sans doute de nouvelles techniques de stockage.
Oubliez temporairement tout ce que vous avez vu dans ce cours. Imaginez-vous travaillant
au CNED, sans avoir d’ordinateur à disposition. Comment allez-vous stocker la liste des
étudiants ? Dit autrement, comment stocker les occurrences de l’entité Étudiant ?
Eh bien, comme je viens de le dire, vous allez en faire une liste.
Si les informations qui vous intéressent sont les nom, prénom, adresse, code postal et
ville de l’étudiant, vous aurez la liste des étudiants écrite sur une feuille. Cela donnera,
en se limitant à quatre étudiants :
Jean Dupond 1, boulevard Jean-Jaurès 54000 NANCY
Pollen LeChat 8, avenue de la Libération 45000 ORLÉANS
Nina LeTeckel 13, rue de l’Europe 95000 CERGY
Alf LeLapin Square Fleuri 34830 CLAPIERS
De même, vous aurez une liste des cours (qui ont un titre et une durée) :
Initiation à Internet 2
Word 2
Excel 3
Access 6
Linux 4
(les données inscrites dans les listes sont mises sans ordre particulier.)
Le problème est que ces listes ne sont pas parlantes. S’il est évident que la première
est une liste de personnes et d’adresses, on peut s’interroger sur la seconde colonne de
la seconde liste : on ne peut pas deviner ce que représentent les chiffres. Dans la vraie
vie, vous mettrez donc une ligne d’en-tête, et vous obtenez… un tableau, ce qui vous
ramène en terrain connu…
On obtient donc les tableaux présentés ci-après.
Étudiant
PRÉNOM NOM ADRESSE CODE POSTAL VILLE
Jean Dupond 1, boulevard Jean-Jaurès 54000 NANCY
Pollen LeChat 8, avenue de la Libération 45000 ORLÉANS
Nina LeTeckel 13, rue de l’Europe 95000 CERGY
Alf LeLapin Square Fleuri 34830 CLAPIERS
Cours
TITRE DURÉE (MOIS)
Initiation à Internet 2
Word 2
Excel 3
Access 6
Linux 4
åTrès schématiquement, une base de données est un outil (un logiciel) gérant des données de façon
structurée. Ce logiciel propose à l’utilisateur un langage (SQL) pour récupérer les données utiles en for-
mulant une requête ; par exemple, on peut interroger la base de données des inscriptions pour deman-
der la liste des étudiants habitant Lyon qui se sont inscrits à un cours d’une durée de 3 à 6 mois.
L’intérêt est qu’il suffit d’écrire la requête car c’est le logiciel de base de données qui se « débrouillera »
pour récupérer les données. C’est une grande avancée face au stockage avec des fichiers où le déve-
loppeur d’applications devait programmer lui-même tous les accès aux données.
33
8 3932 TG PA 01
Séquence 3
Les tableaux, c’est peut-être un peu ringard. Mais, sans le savoir, que vient-on de faire ?
Eh bien, nous venons de définir le MLD ! Nous avons choisi le type de stockage des
données (les tableaux). Le MLD a consisté à définir les colonnes (combien de colonnes,
quelles données elles contiennent) ; le MLD est donc constitué de l’en-tête des tableaux
(la première ligne, grisée).
La phase suivante a consisté à remplir ces tableaux avec des données (les occurrences).
Exercice 8
Un bémol toutefois… notre MLD n’est pas complet : toutes les informations représentées dans
le MCD ne sont pas dans le MLD. Pouvez-vous trouver ce qui manque et le rajouter ?
Nous allons donc ajouter un tableau pour contenir les occurrences de suivre. Chaque
ligne du tableau contiendra le fait qu’un étudiant est inscrit à un cours :
Suivre
TITRE NOM
Excel LeTeckel
Initiation à Internet LeLapin
Access Dupond
Initiation à Internet Dupond
Initiation à Internet LeChat
Word Dupond
Quelques remarques
1. On avait dit qu’une occurrence de suivre était formée d’une occurrence d’Étudiant et
d’une occurrence de Cours. Dans le tableau, nous devrions donc avoir toutes les propriétés
de Cours et d’Étudiant et pas seulement le titre et le nom. Mais cela ferait un tableau un
peu long, donc je me suis permis de ne pas le faire, vu qu’a priori, cela ne change rien.
2. J’ai arbitrairement inscrit les étudiants à divers cours.
3. Tous les étudiants sont inscrits à au moins un cours. C’est logique, car sinon ils ne seraient
pas des étudiants (on reviendra sur ce point). En revanche, certains cours n’ont aucun
inscrit. On représentera cela avec les cardinalités dans la suite de cette séquence.
4. Comme pour les deux autres tableaux, il n’y a toujours pas d’ordre particulier, ni pour
les occurrences, ni pour les colonnes.
Nous pouvons être satisfaits de notre travail. En première approximation, nous pouvons
d’ailleurs estimer qu’il est terminé. En effet, si l’on veut envoyer les supports de forma-
tion aux inscrits du cours Initiation à Internet, notre tableau nous indique que Dupond,
LeChat et LeLapin sont concernés, leur prénom et adresse étant accessibles dans le
tableau contenant les étudiants comme le prouve le dessin suivant :
Suivre Étudiant
TITRE NOM PRÉNOM NOM ADRESSE CODE POSTAL VILLE
Excel LeTeckel Jean Dupond 1, boulevard Jean-Jaurès 54000 NANCY
Initiation à Internet LeLapin Pollen LeChat 8, avenue de la Libération 45000 ORLÉANS
Access Dupond Nina LeTeckel 13, rue de l’Europe 95000 CERGY
Initiation à Internet Dupond Alf LeLapin Square Fleuri 34830 CLAPIERS
Initiation à Internet LeChat
Word Dupond
34
8 3932 TG PA 01
Tout se passe donc bien… jusqu’à ce que Mlle Frédérique Dupond (11, rue des Arbres
60100 CREIL) s’inscrive aux cours d’Access et d’Excel.
Exercice 9
Mettez à jour les tableaux pour qu’ils contiennent les inscriptions de Mlle Dupond. Mettez en
évidence le problème qui se pose lorsque l’on désire la liste des adresses des étudiants inscrits
à la formation Excel ou si l’on veut retrouver à quels cours s’est inscrite Mlle Dupond.
Exercice 10
Après avoir consulté le corrigé de l’exercice précédent, proposez une solution pour remédier
au problème.
La correction de l’exercice précédent nous indique que le couple nom/prénom n’est pas
suffisant pour identifier à coup sûr un étudiant. En généralisant, on ne peut pas se con-
tenter de rajouter l’une ou l’autre des propriétés. Le risque d’homonymie n’est pas levé.
La seule solution est donc de mettre toutes les propriétés d’Étudiant dans le tableau
suivre. Bref, on met dans suivre toutes les informations dont on dispose sur les étudiants.
On obtient :
Suivre
TITRE PRÉNOM NOM ADRESSE CODE POSTAL VILLE
Excel Nina LeTeckel 13, rue de l’Europe 95000 CERGY
Initiation à Internet Alf LeLapin Square Fleuri 34830 CLAPIERS
Access Jean Dupond 1, boulevard Jean-Jaurès 54000 NANCY
Initiation à Internet Jean Dupond 1, boulevard Jean-Jaurès 54000 NANCY
Initiation à Internet Pollen LeChat 8, avenue de la Libération 45000 ORLÉANS

Word Jean Dupond 1, boulevard Jean-Jaurès 54000 NANCY
Access Frédérique Dupond 11, rue des Arbres 60100 CREIL
Excel Frédérique Dupond 11, rue des Arbres 60100 CREIL
On remarquera les points suivants :

1. Si l’on informatisait vraiment les inscriptions avec des tableaux, on n’aurait pour le
moment plus besoin du tableau Étudiant puisque toutes les informations qu’il conte-
nait sont dans le tableau suivre.
2. Le problème d’homonymie ne se pose pas pour le cours puisque son titre l’identifie
sans ambiguïté (heureusement !). On n’ajoute donc pas la durée.
Bon, on a toujours le risque d’avoir un homonyme à une même adresse… mais il faut
savoir s’arrêter, d’autant qu’il y a plus urgent : M. Dupond vient d’appeler. Il a déménagé,
voici sa nouvelle adresse : « 78, avenue de la Libération 58000 NEVERS ».
35
8 3932 TG PA 01
Séquence 3
Exercice 11
Corrigez les différents tableaux pour tenir compte du changement d’adresse.
Reprenons le tableau de la correction :

Suivre
TITRE PRÉNOM NOM ADRESSE CODE POSTAL VILLE
Excel Nina LeTeckel 13, rue de l’Europe 95000 CERGY
Initiation à Internet Alf LeLapin Square Fleuri 34830 CLAPIERS
Access Jean Dupond 78, avenue de la Libération 58000 NEVERS
Initiation à Internet Jean Dupond 78, av. de la Libération 58000 NEVERS
Initiation à Internet Pollen LeChat 8, avenue de la Libération 45000 ORLÉANS

Word Jean Dupond 78 av. Libérations 58000 NEVERS
Access Frédérique Dupond 11, rue des Arbres 60100 CREIL
Excel Frédérique Dupond 11, rue des Arbres 60100 CREIL
Vous observerez que les trois adresses ont été écrites différemment, de façon de plus
en plus abrégée. Certes, je l’ai fait sciemment. Mais je vous assure que, dans la vraie
vie, c’est ce qui se passerait. Au bout de quelques semaines, les données ne seraient pas
toutes à jour, chacun les saisissant comme il le veut, sans parler des problèmes de fautes
de frappe !
Ce problème porte le nom technique d’intégrité : l’intégrité des données (leur cohé-
rence) n’est pas assurée. Autre problème technique : la redondance d’informations. Rien
que dans le petit tableau ci-dessus, l’adresse de Jean Dupond est écrite trois fois.
Résumons-nous :
1. Avoir mis toutes les propriétés d’Étudiant dans le tableau des inscriptions a supprimé
tout problème d’ambiguïté. Mais…
2. …on paye cela au prix fort. En effet, le tableau des inscriptions devient volumineux
pour rien (redondance), il est difficile à mettre à jour.
3. Pire encore, les mises à jour peuvent introduire des erreurs dans les données (on en
oublie une, on fait une faute de frappe…).
Maintenant, pensez au cas général d’une informatisation et non à ce cas jouet. Imaginez
que vous informatisiez un cabinet médical gérant l’historique de plusieurs milliers de
patients, certains ayant plusieurs dizaines d’ordonnances archivées. Les problèmes de
redondance et d’intégrité deviennent réellement préoccupants !
Bien entendu, j’ai une solution à vous proposer. Eh oui…
Si l’on a rajouté toutes les propriétés d’Étudiant dans le tableau des inscriptions (suivre),
c’était uniquement pour identifier sans ambiguïté chaque étudiant. Le problème ne s’est
pas posé avec les cours puisque leur titre les identifie sans ambiguïté.
36
8 3932 TG PA 01
Exercice 12
En pensant aux différents contrats (EDF, téléphone…), commandes (vente à distance) ou relations
avec des organismes (Impôts, Sécurité Sociale, CNED) qui peuvent vous concerner dans la vraie
vie, pourriez-vous dire de quelle façon assez simple et naturelle toutes ces entreprises ou organis-
mes, qui ont un nombre considérable de clients, règlent le problème d’homonymie ?
Nous allons reprendre ce concept de numéro de client dans le MCD.
2B. Identifiant d’une entité

2B1. Définition
Identifiant d’une entité : l’identifiant d’une entité est une propriété ou un ensemble
de propriétés de cette entité. La valeur de l’identifiant doit être stable, non nulle
et caractériser de façon unique l’occurrence correspondante. L’identifiant peut être
naturel ou artificiel.
Analysons cette phrase

« un identifiant est une propriété d’une entité »
L’identifiant sera donc une caractéristique de l’entité. Comme pour toute propriété, cha-
que occurrence de l’entité possédera une valeur pour l’identifiant.
« la valeur de l’identifiant doit caractériser de façon unique l’occurrence correspon-
dante »
La différence entre une propriété quelconque et l’identifiant est la sémantique. Chaque
propriété apporte une information, une caractéristique, tandis que l’identifiant ne sert
qu’à… identifier.
Chaque valeur de l’identifiant ne correspond qu’à une seule occurrence de l’entité. Par
exemple, un numéro de Sécurité Sociale identifie de façon unique (ne correspond qu’à)
une personne.
De même, chaque occurrence d’entité ne possède qu’une valeur d’identifiant. En mathé-
matiques, on parlerait de bijection entre les identifiants et les occurrences.
Le fait que l’identifiant détermine l’occurrence ne signifie pas qu’à partir de la

O valeur de l’identifiant, vous pouvez déterminer la valeur des autres propriétés de
l’occurrence (si je vous donne un numéro de Sécurité Sociale, vous ne pourrez pas
en déduire le nom de la personne). Cela signifie que, pour une valeur donnée de
l’identifiant, il n’existe qu’une valeur pour chacune des autres propriétés de l’occur-
rence (mais quelles sont ces valeurs… mystère !).
Une conséquence importante : pour une entité donnée, chaque valeur de l’identifiant
est unique.
Une remarque : dans la définition, j’aurais dû mettre « la valeur de l’identifiant identi-
fie ». Mais comme cela faisait un peu redondant, j’ai préféré utiliser caractérise.
37
8 3932 TG PA 01
Séquence 3
Exercice 13
Attention à bien comprendre cet exercice, il y a une subtilité !
L’identifiant détermine l’occurrence ; or, le numéro de Sécurité Sociale est identifiant. Ainsi, le
numéro 1 70 11 54 395 997 88 correspond à une seule personne que l’on supposera être Jean
Dupond, 58 000 NEVERS.
Or, dans mon système d’information, j’ai aussi l’occurrence « 1 07 03 57 110 005 27, Jean Dupond,
58 000 NEVERS ».
J’ai l’impression qu’une même personne a deux numéros de Sécurité Sociale. Que pensez-vous
de cette situation ? Expliquez pourquoi elle peut néanmoins être correcte.
« la valeur de l’identifiant doit être stable [et] non nulle »

D’après ce que l’on vient de voir, l’identifiant peut varier en permanence. Mais le bon
sens peut-il accepter cela ? Si mon numéro de Sécurité Sociale change, ce n’est pas
gênant tant qu’il continue à m’identifier de façon unique. Enfin, pas gênant… en théorie
car en pratique je devrai changer ma carte d’ayant droit, prévenir mon employeur, ma
mutuelle…
De même, si le numéro d’un client change, il faut mettre à jour ses factures, ses com-
mandes, bref tout ce qui le concerne. Finalement, l’identifiant faisant référence à une
occurrence, on s’en servira très souvent. Accepter que les identifiants varient entraînerait
un travail de mise à jour énorme et finalement idiot.
Je peux justifier cela d’une manière plus intuitive, qu’il faut sentir : l’identifiant est un
peu la propriété phare de l’occurrence, celle qui détermine tout le reste. C’est en quel-
que sorte un point fixe. Le fait que ce point fixe varie est assez ennuyeux. Pour la même
raison, une valeur nulle est techniquement une valeur. Mais bon… être caractérisé par
rien, c’est angoissant. On refuse donc la valeur nulle à l’identifiant.
« propriété naturelle ou artificielle d’une entité »
Le rôle de l’identifiant est donc d’identifier. J’espère vous avoir montré dans l’exemple
des inscriptions au CNED que l’on avait besoin d’un identifiant pour gérer les étudiants.
En généralisant, on définira un identifiant pour chaque entité. Pour faire cela, on obser-
ve l’entité :
• soit il existe déjà une propriété qui peut servir d’identifiant car elle en a la caracté-
ristique. Dans ce cas, cette propriété naturelle est promue au rang d’identifiant. On
parlera d’identifiant naturel ;
• soit, et c’est le cas le plus fréquent, aucune propriété ne peut être identifiant. On va
donc rajouter une propriété artificielle (généralement juste un numéro) dont le seul
rôle est de servir d’identifiant. On parlera alors d’identifiant artificiel.
« propriété ou ensemble de propriétés »
Il peut tout à fait arriver qu’une seule propriété ne soit pas identifiant, mais que deux
propriétés accolées le soient. Nous verrons des exemples dans la suite du cours (cela reste
un cas assez rare).
(On définira plus tard de façon théorique l’identifiant dans la partie de cours
sur les dépendances fonctionnelles. On verra alors le cas où un identifiant est
constitué par plusieurs propriétés.)
38
8 3932 TG PA 01
2B2. Représentation graphique

Dans le MCD, on fait figurer toutes les propriétés de chaque entité. Pour distinguer
l’identifiant, on le souligne et on le met en tête des propriétés.
Voici l’exemple de l’entité Client avec l’identifiant NuméroClient, puis le cas général avec
l’entité Entité :
CLIENT ENTITÉ
NuméroClient Identifiant
NomClient Propriété_1
PrénomClient Propriété_2
AdrClient Propriété_3
CodeClient (etc)
VilleClient Propriété_n
TéléphoneClient
Exercice 14
On mettra donc systématiquement un identifiant à chaque entité. Donnez un identifiant pour
chaque entité Étudiant et Cours. Précisez si ces identifiants sont naturels ou artificiels.
Exercice 15
Après avoir vu le corrigé de l’exercice précédent, rajoutez les identifiants dans le MCD puis
modifiez en conséquence la définition et le contenu des tableaux, notamment suivre.
Exercice 16
Vérifiez qu’avec le changement dans le tableau des inscriptions, on a toujours la possibilité

d’obtenir :
• les adresses des inscrits au cours Excel ;
• à quels cours est inscrite Mlle Dupond.
2C. Identifiant d’une association
Exercice 17
Nous avons vu la notion d’identifiant d’entité. La notion d’identifiant d’association existe éga-
lement. Partant du principe que l’identifiant identifie l’occurrence concernée, essayez de réflé-
chir à ce que peut être l’identifiant d’une association sans regarder la suite du cours. Donnez
l’identifiant de l’association suivre.
39
8 3932 TG PA 01
Séquence 3
La définition sera la suivante :

Identifiant d’association : l’identifiant d’une association est la concaténation des
identifiants des entités reliées.
Par exemple, si Pollen LeChat (étudiant numéro 2) suivait le cours Excel, on aurait une
occurrence de suivre identifiée par 2/Excel (la concaténation des deux valeurs).
Cette notion ne sert pas à grand-chose. D’ailleurs, elle n’est pas représentée dans le
MCD : les identifiants des entités sont soulignés, mais on ne les souligne pas une seconde
fois pour indiquer qu’ils sont identifiants d’une ou plusieurs associations.
« Donc, me diriez-vous si j’étais devant vous, vous nous apprenez des choses inutiles ?
Ce n’est pas raisonnable ! ». Certes ; j’ai donc une justification : la notion d’identifiant
d’association est utile pour la compréhension de l’association.
Par définition, toute valeur d’identifiant (d’entité ou d’association) est unique. C’est
pourquoi on ne peut pas relier deux fois les mêmes occurrences d’entité par une
même association.
Dit autrement, le même ensemble d’occurrences d’entité ne peut constituer deux occur-
rences d’une même association. Par rapport à notre exemple d’inscription, cela signifie
que Jean Dupond ne peut pas s’inscrire deux fois au même cours. Ce qui, ma foi, est assez
raisonnable. Ce point semble même trivial, mais je vous assure que ce sera un bon garde-
fou lorsque vous ferez un MCD « trapu » où l’on a vite fait de perdre ses repères.
3. Interlude : comment construire un MCD (1)

Nous avons vu ensemble les différents constituants du MCD. Cependant, je ne vous ai
donné aucune technique pour passer d’un sujet en français au MCD. Le sujet ci-dessous
est donc volontairement explicite. De plus, je vous donne les conseils suivants :
1. Ne tenez pas compte dans le sujet de ce qui a trait aux traitements, ni de ce qui est
extérieur au domaine considéré.
2. Identifiez les entités et les associations.
3. Identifiez les propriétés.
4. Déterminez les identifiants (identifiants naturels) ou rajoutez-en (identifiants artificiels).
5. Il n’y a plus qu’à faire le MCD.
Avant d’aborder le dernier constituant (cardinalités) du MCD, je vous propose un petit
jeu : la modélisation du sujet suivant.
Gestion des permis de construire à la mairie (première partie).

Un terrain est caractérisé par une référence cadastrale, une surface en areså, un type
(constructible, inondable, indéterminé…). Un propriétaire est caractérisé par ses nom,
prénom, adresse et date de naissance.
Un terrain appartient à un seul propriétaireç, l’achat étant réalisé devant notaire. Les
gens qui ne sont pas du métier n’ayant pas une bonne compréhension de ce qu’est un
are, il est décidé d’avoir aussi la surface en m2.
å Un are = 100 m2 (et un hectare = 100 ares = 10 000 m2).

ç Dans la vraie vie, c’est faux. Mais c’est sans importance ici, puisque seul le sujet compte.
40
8 3932 TG PA 01
Exercice 18
Essayez d’établir le MCD. Une petite aide : il y a deux entités et une association.
Exercice 19
Au vu du corrigé de l’exercice précédent, faites le MLD (avec des tableaux) et mettez deux ou
trois terrains et propriétaires fictifs. Essayez d’avoir un jeu d’essai (des données) significatif, à
savoir représentatif de la réalité (c’est tout un art !). Quel est l’identifiant de posséder ?
4. Les cardinalités
4A. Présentation par l’intuition

C’est la dernière notion utile dans un MCD… et c’est sans doute la plus simple à com-
prendre.
Son importance est néanmoins énorrrrrrrrrrrrrrrrrrrrrrrrme ! Depuis le début du cours,
j’ai essayé de justifier tout ce que l’on voyait. En effet, mon dada est de dire que tout
en informatique a une justification et un intérêt. Ainsi, si l’on utilise des identifiants, ce
n’est pas pour le plaisir, mais parce qu’on en a besoin.
C’est la même chose pour les cardinalités, sauf que… je vous avoue humblement n’avoir
pas trouvé de biais pour le présenter. Le concept est tellement simple que je pourrais vous
dire « bon, les cardinalités, c’est comme cela, point ». Mais cela ne serait pas sérieux.
Reprenons les deux exercices précédents (les inscriptions et les permis de construire). Je
ne les ai pas choisis au hasard : bien que similaires (deux entités, une association, on ne
peut pas faire plus simple), ils ont une différence essentielle que l’on n’avait pas encore
exploitée.
Cas des inscriptions :
• un cours peut être suivi par plusieurs étudiants ;
• un étudiant peut suivre plusieurs cours.
Exercice 20
Vous remarquerez que le descriptif précédent concerne les occurrences. Pouvez-vous faire la
même chose entre les entités Propriétaire et Terrain ? Je vous conseille de relire le sujet, qui
contient explicitement la réponse.
Où est la différence avec les inscriptions ? Dans le cas des inscriptions, l’association est symétri-
que : chaque occurrence d’une entité peut être associée à plusieurs occurrences de l’autre. En
revanche, on ne retrouve pas cette symétrie dans la gestion des permis de construire.
À quoi va nous servir cette constatation ? À optimiser notre MLD, c’est-à-dire la façon
dont on stockera les données. Le MCD est par définition conceptuel. Mais il importe qu’il
41
8 3932 TG PA 01
Séquence 3
« embarque » le plus d’informations possible sur le réel pour que l’implantation future
sur ordinateur soit efficace.
Dit autrement, les niveaux de modélisation sont par principe tout à fait distincts. En
poussant le raisonnement jusqu’au bout, il n’est pas gênant qu’un niveau abstrait com-
porte des informations que l’on ne sache pas exploiter dans les niveaux plus élevés. En
effet, il est tout à fait possible que, la technique évoluant, l’on sache implanter cela dans
l’avenir. Cela dit, pas d’affolement : le raffinement que l’on va introduire sera exploité
dans le MLD.
La phrase qui m’intéresse est « un terrain n’a qu’un propriétaire ». Voyez-vous où je veux
en venir ? Je pourrais dire aussi « un terrain n’a qu’une surface ». Cela vous éclaire ? Vous
pensez que le propriétaire est en fait une propriété du terrain ? Eh bien, SURTOUT PAS !
Enfin, l’idée va revenir en gros au même, mais pas sous cette forme. En effet, comme
le propriétaire et le terrain sont des objets réels et autonomes (c’est la définition d’une
entité), on ne peut pas inclure l’un dans l’autre ; l’entité Terrain englobant un proprié-
taire n’est pas un objet réel.
J’insiste ! Oubliez à jamais toute idée du genre de celles présentées ci-après.
TERRAIN TERRAIN
RéférenceCadastrale RéférenceCadastrale
Surface Surface
Type Type
NuméroPropriétaire Propriété fautive PROPRIÉTAIRE
Nom NuméroPropriétaire
Nom
Prénom Concept fautif
Prénom
DateDeNaissance DateDeNaissance
Code Adresse
CodePostal
Ville Ville
Cela peut sembler séduisant, notamment la deuxième solution. Mais c’est un leurre !
Vous n’avez pas optimisé le modèle Merise, ni inventé un nouveau concept. C’est une
erreur de logique à laquelle on s’est tous fait prendre. Un tel Terrain n’a aucun sens
puisque vous imbriquez deux objets réels.
La remarque « un terrain n’a qu’un propriétaire » n’aura donc aucune incidence sur le
MCD, mais uniquement sur le MLD. On va pouvoir se passer du tableau posséder. En
effet, même si d’un point de vue conceptuel terrain et propriétaire sont des objets dis-
tincts, le fait est que l’on peut associer le propriétaire au terrain. Et c’est ce que l’on fera
en ajoutant une colonne.
J’insiste encore ! Vous voyez que le MCD ne change pas, seule l’implantation (MLD) est
modifiée. C’est ça, l’intérêt de la modélisation en niveaux différents. Dit autrement, inu-
tile d’utiliser un tableau posséder puisque l’on peut s’en passer. Et le fonctionnement du
programme sera d’autant plus rapide : pour trouver le propriétaire d’un terrain donné,
on gagne une étape puisque l’on passe par un tableau de moins.
42
8 3932 TG PA 01
Le jeu d’essai donné dans la correction de l’exercice précédent deviendra :

Propriétaire
NUMÉRO PROPRIETAIRE NOM PRÉNOM DATE DE NAISSANCE ADRESSE CODE VILLE
1 LeChat Pollen 25/01/1998 ici 59000 LILLE

2 LeTeckel Nina 12/04/1996 là 34000 MONTPELLIER
Terrain
RÉFÉRENCE CADASTRALE SURFACE TYPE NUMÉRO PROPRIÉTAIRE
1B19GH 20 constructible 2
BB2GH 15,5 constructible 1
FRRR88 10 inondable 1
Propriétaire est inchangé, terrain possède une colonne de plus (mise arbitrairement à la
fin) et posséder a disparu. Bien entendu, si les règles du jeu (le réel) changeaient et qu’un
terrain pouvait avoir plusieurs propriétaires, il faudrait revenir aux tableaux initiaux.
Normalement, quelque chose doit vous chiffonner : je vous dis que l’on modifiera le MLD en
fonction du réel en passant par dessus le MCD qui ne bouge pas. Cela va à l’encontre du prin-
cipe même de Merise, où toute modification du réel ne doit être répercutée que sur le MCD,
sachant qu’en cascade, les modifications du MCD en entraîneront d’autres sur le MLD.
Bref, il faut que l’on représente sur le MCD le nombre d’occurrences d’entité auxquelles
une occurrence d’entité donnée peut être reliée à travers une association donnée. Bon,
cette phrase n’est pas claire du tout, bien que j’aie passé dix minutes à la concevoir.
Soyons plus explicite : concrètement, on représentera combien un terrain peut avoir de
propriétaires, combien un propriétaire peut avoir de terrains, combien un étudiant peut
suivre de cours, combien d’étudiants peuvent être inscrits à un cours.
Maintenant, si je vous demande combien un propriétaire peut posséder de terrains,
ou à combien de cours vous pouvez vous inscrire au CNED… ma foi, vous n’avez pas la
réponse et moi non plus : la majorité des français ne possèdent qu’un terrain, sur lequel
ils ont fait construire leur maison. En revanche, il existe des investisseurs qui possèdent
des dizaines de terrains. Idem pour les cours : tant que vous payez chaque inscription, il
n’existe aucune limite théorique au nombre de cours que vous pouvez suivre.
Mais alors, comment faire ? Mettre un nombre arbitraire, par exemple 1 000 terrains
maximum par propriétaire, 10 cours par étudiant ? Et, dans ce cas, combien de comman-
des par client si l’on modélise l’activité d’un magasin ? Cela ne va pas !
La solution sera donc pragmatique : on ne distinguera que des cas généraux, en disant
qu’une occurrence d’entité sera reliée à 0, à 1 ou à plusieurs occurrences d’entité. Cette
simplification ne pose aucun problème puisque l’on vient de voir que les deux seuls cas
que l’on distingue sont :
• une occurrence d’entité est reliée à au plus une autre (comme le terrain relié au
propriétaire) ;
• une occurrence d’entité est reliée à plusieurs autres (un cours est relié à plusieurs
étudiants).
43
8 3932 TG PA 01
Séquence 3
4B. Définition des cardinalités

L’association traduit le lien sémantique abstrait entre les entités. Les cardinalités tradui-
ront le lien entre les occurrences.
Armé de ce savoir, on va donner la dernière définition de la séquence.
Cardinalités : les cardinalités d’une entité vis-à-vis d’une association indiquent le
nombre minimum (0 ou 1) et maximum (1 ou n) d’occurrences de l’association aux-
quelles participe chaque occurrence de l’entité.
Chaque association comportera autant de cardinalités (couple nombre minimum,
nombre maximum) que d’entités reliées.
Les cardinalités seront écrites au bout de chaque patte de l’association, à côté de l’entité
correspondante å. On séparera les cardinalités minimum et maximum par une virgule.
Bon, assez de blablabla, voici la représentation du MCD inscriptions :
ÉTUDIANT
NuméroÉtudiant
Nom COURS
Prénom suivre Titre
0, n
Rue 0, n Durée
CodePostal
Ville
(1) (2)
Première remarque
(1) et (2) vous indiquent les cardinalités. Vous remarquerez que les premières se trou-
vent sur « la patte » de l’association. Tandis que les secondes sont en-dessous. Rassurez-
vous, cela ne signifie rien ! C’est le logiciel que j’utilise pour dessiner les MCD qui place
les cardinalités là où il le veut. Lorsque vous faites le MCD à la main, il est préférable
d’écrire les cardinalités sous la patte comme dans le cas (2). Tout simplement car c’est
plus rapide !
Deuxième remarque : expliquons bien les cardinalités en les lisant ensemble.

(1) cardinalités liées à l’entité Étudiant ç.
Cardinalité minimum : 0
Une occurrence d’Étudiant participera au minimum à aucune occurrence de suivre (juste
pour la compréhension, cela signifie qu’un étudiant peut n’être inscrit à aucun coursé).
Cardinalité maximum : n
Une occurrence d’Étudiant peut participer au maximum à plusieurs occurrences de suivre (juste
pour la compréhension, cela signifie qu’un étudiant peut être inscrit à plusieurs coursè).
å Attention ! Les étudiants les moins sérieux n’apprennent pas suffisamment leur cours. Je vois tou-
jours des étudiants de seconde année qui se trompent de côté et mettent les cardinalités relatives à
une entité à côté de l’autre. La position des cardinalités étant arbitraire (les méthodes américaines
les mettent dans l’autre sens), il faut l’apprendre par cœur, il n’y a rien à comprendre.
ç J’insiste : les cardinalités à côté de l’entité Étudiant concernent les occurrences d’Étudiant, non
de Cours.
é Mais alors, est-ce un étudiant ? On va y revenir !
è Ce plusieurs signifiant « un nombre quelconque ».
44
8 3932 TG PA 01
On résumera en disant qu’une occurrence d’étudiant peut participer de 0 à plusieurs

occurrences de suivre (bref, qu’un étudiant peut être inscrit de 0 à plusieurs cours ; dit
autrement, tous les cas sont possibles, il n’y a pas de contrainte).
(2) cardinalités liées à l’entité Cours.
Exercice 21
Les cardinalités (2) sont identiques aux cardinalités (1). Essayez de les expliquer comme on vient
de le faire.
Remarquez bien que le raisonnement est globalement fait pour l’entité, c’est-à-dire pour
l’ensemble des occurrences possibles et à venir. On ne discute donc pas de l’étudiant
Machin ou Truc. On prend l’occurrence en toute généralité. Notamment, si l’étude des
inscriptions montre que, sur 1 000 étudiants, un seul est inscrit à plus d’un cours, il faudra
néanmoins utiliser la cardinalité maximale n.
Nous avons un petit souci : le CNED propose des cours et les étudiants choisissent ceux qui
les intéressent. L’éventail des cours étant très large, il est tout à fait possible qu’un cours
ne recueille aucun inscrit. En revanche, un étudiant ne suivant aucun cours… n’est pas un
étudiant d’après la définition que nous avons donnée en présentant le sujet.
Exercice 22
Bon, qu’à cela ne tienne… il y a juste un chiffre à corriger sur le MCD ; pouvez-vous le faire ?
Cet exercice permet une conclusion intéressante :

• certaines cardinalités sont négociables : dans cet exercice, mettre un 0 ou un 1 dépend
de ce que l’on appelle un étudiant. On peut justifier le 0 en envisageant un étudiant
qui s’inscrit, puis qui annule son inscription. Si on ne l’efface pas de la base de données,
on a bien un étudiant sans cours. Bref, mettre 0 ou 1 n’a pas d’incidence. Les deux
solutions sont correctes. Inutile donc de discuter dix minutes, de peser le pour et le
contre… c’est du temps perdu ;
• en revanche, certaines cardinalités ne sont absolument pas négociables : par exemple,
une facture doit être liée à un client. Mettre une cardinalité minimale de 0 n’a pas de
sens, puisque dans ce cas, personne ne la paiera ! (c’est une fausse facture).
On a vu précédemment que le MLD était différent selon que la cardinalité maximale était
1 ou n (avec un 1, l’association n’est pas transcrite en tableau dans le MLD). L’information
apportée par la cardinalité maximale étant exploitée, il est utile de la faire figurer dans
le MCD.
En revanche, à quoi sert la cardinalité minimale (0 ou 1) ? Elle n’a aucune influence dans
notre MLD tableau. Cependant, deux arguments militent en sa faveur :
1. Le principe du MCD est de représenter fidèlement et complètement le réel puisque,
pour tout le travail postérieur (l’informatisation réelle), le MCD se substituera au réel.
45
8 3932 TG PA 01
Séquence 3
Il est donc indispensable d’avoir le plus d’informations possible embarquées dans le

MCD, que l’on s’en serve ou non. Ce n’est pas de l’informatique mais du bon sens : il
vaut mieux avoir trop d’informations disponibles que pas assez.
2. De plus, cette information sera vraiment utile lors du développement de l’application.
Par exemple, une facture est liée au minimum à un client et non à zéro car une facture
sans client désigné ne sera jamais payée. Ainsi, le développeur concevra l’application
de telle façon que l’utilisateur ne puisse pas entrer de facture sans mentionner de
client associé. En revanche, si vous mettez 0 en cardinalité minimum, vous faites une
faute d’analyse qui entraînera une erreur dans le programme. Nous sommes bien en
présence d’une cardinalité minimale non négociable (1 est juste, 0 est faux).
4C. Les différentes cardinalités

Pour terminer sur les cardinalités, on va recenser tous les cas pouvant se trouver dans un
MCD, sachant que l’on utilise les valeurs 0, 1 ou nå :
0, 0 C’est une configuration impossible car signifiant que toute occurrence de
l’entité concernée participe à au moins 0 et au plus 0 occurrence d’asso-
ciation. Or, entre 0 et 0, il n’y a qu’une possibilité : 0. Une cardinalité 0,0
signifie donc que l’occurrence ne participe jamais à l’association. Dans ce
cas, on ne représente pas de patte !
0, 1 et 1, 1 La cardinalité minimale (0 ou 1) peut être ou non négociable. La cardinalité
maximale a un sens important (le MLD ne sera pas le même selon que l’on
a 1 ou n).
0, n et 1, n La cardinalité minimale (0 ou 1) peut être ou non négociable. La cardinalité
maximale a un sens important (le MLD ne sera pas le même selon que l’on
a 1 ou n).
n, n Cette configuration n’a pas de sens. En effet, quand vous rentrez une
occurrence, vous ne pouvez pas techniquement la relier immédiatement à
plusieurs autres occurrences au travers d’une même association.
On conclura en disant que la cardinalité maximale influe directement sur le MLD, tandis
que la cardinalité minimale a un sens dans la sémantique des données et sera exploitée
lors de la conception du programme.
å Certains auteurs mettent des valeurs précises au lieu de n quand ils possèdent l’information.
Par exemple, si le CNED vous dit que pour des raisons matérielles, un cours ne peut avoir que 100
inscrits au maximum, on peut mettre 0,100 au lieu de 0, n. Cela va dans le sens de la précision
que je prônais dans le MCD. Pourtant, j’estime que cela va un peu loin. En effet, au niveau con-
ceptuel (MCD), qu’il y ait 100, 5, 2 ou n étudiants, c’est pareil. Ensuite, le chiffre 100 venant d’un
problème d’organisation qui peut être réglé à tout moment, on s’éloigne du conceptuel. Je préconise
donc de laisser le n et de rajouter en règle de gestion (on y reviendra) le fait que n vaut pour le
moment 100. En revanche, si la valeur du n est déterminée par le concept étudié, on peut la mettre.
En tout état de cause, les deux solutions sont acceptables et acceptées.
46
8 3932 TG PA 01
La séquence est presque terminée ; faisons donc un petit exercice d’entraînement.
Exercice 23
Vérifions votre compréhension. Je n’ai pas parlé de certains couples de cardinalités « n, 1 »,
« 1,0 » Est-ce un oubli de ma part ou est-ce normal ? (bien entendu, il faut justifier !)
Exercice 24
Je n’ai plus parlé du cas gestion des permis de construire car je vous propose en exercice de
compléter le MCD correspondant (voir l’exercice 18) pour y rajouter les cardinalités.
4D. Distinguons les cardinalités maximales

Nous avons vu que les cardinalités minimales et maximales avaient un rôle différent.
Dans les dernières séquences de ce cours, nous aurons besoin de raisonner sur les cardi-
nalités maximales des associations.
Pour le faire facilement, on va utiliser une notation représentant exclusivement les car-
dinalités maximales d’une association : on les sépare par un tiret et on met l’ensemble
entre crochets. Par exemple :
• [n–n] signifie que l’association est une binaire dont les deux cardinalités maximales
sont n. Les deux couples de cardinalités peuvent être soit 1,n, soit 0,n.
• [1–n] signifie que l’un des couples de cardinalités sera 0,1 ou 1,1, l’autre étant 0,n
ou 1,n.
• [n–n–n] devrait représenter une ternaire avec les cardinalités maximales à n… mais
on écrira cette ternaire [n–n] quand même. Pourquoi ? Hé hé !
On retiendra : une association [1–n] est une binaire dont une cardinalité maximale vaut
1, l’autre n. Une association [n–n] est une association dont toutes les cardinalités maxi-
males valent n.
La suite du cours vous expliquera :
• pourquoi [1–n] est forcément une binaire ;
• pourquoi [n–n] peut représenter une association avec un nombre de pattes indé-
terminé et pas uniquement une binaire (on verra pourquoi [n–n–n], [n–n–n–n]… se
résument à [n–n]).
Poursuivez donc le cours pour découvrir tous ces mystères !
47
8 3932 TG PA 01
Séquence 3
5. Interlude : comment construire un MCD (2)

Nous terminerons la séquence en complétant la technique de base pour réaliser le MCD :
1. Ne tenez pas compte dans le sujet de ce qui a trait aux traitements, de ce qui est
extérieur au domaine considéré, de ce qui est tout simplement du blabla.
2. Identifiez les entités et les associations.
3. Identifiez les propriétés.
4. Déterminez les identifiants (identifiants naturels) ou rajoutez-en (identifiants
artificiels).
5. Dessinez le MCD. Pour chaque association, vous placerez les cardinalités.
(En pratique, pas question de faire cela dans un grand sujet : on fera plutôt les étapes 2
à 5 pour chaque entité et association. Nous y reviendrons dans des cas plus complexes.)
La séquence est terminée ! Pour profiter de la séance de TD suivante, apprenez

bien le cours avant de la commencer. Ne vous référez au cours que si vraiment
vous êtes bloqué. Bon courage et rendez-vous à la séquence suivante.
48
8 3932 TG PA 01
Synthèse
Définitions
Occurrence d’entité : une occurrence d’entité est une réalisation (concrétisa-
tion) de cette entité. Une occurrence d’entité aura une valeur pour chaque pro-
priété de l’entité. L’ensemble de ces valeurs caractérise cette occurrence.
Occurrence d’association : une occurrence d’association est une réalisation
(concrétisation) de cette association.
Identifiant d’entité : l’identifiant d’une entité est une propriété ou un ensem-
ble de propriétés de cette entité. La valeur de l’identifiant doit être stable, non
nulle et caractériser de façon unique l’occurrence correspondante. L’identifiant
peut être naturel ou artificiel.
Identifiant d’association : l’identifiant d’une association est la concaténation
des identifiants des entités reliées.
Cardinalités : les cardinalités d’une entité vis-à-vis d’une association indiquent
le nombre minimum (0 ou 1) et maximum (1 ou n) d’occurrences de l’association
auxquelles participe chaque occurrence de l’entité. Chaque association compor-
tera autant de cardinalités (couple nombre minimum, nombre maximum) que
d’entités reliées. Les cardinalités seront écrites au bout de chaque patte de l’asso-
ciation, à côté de l’entité correspondante. On séparera les cardinalités minimum
et maximum par une virgule.
Conseils
Le nom de l’entité est au singulier car l’entité (le concept) est unique. Il n’y aura pas
deux entités Étudiant. Mettre un pluriel serait une confusion entre les occurrences
de l’entité et l’entité elle-même. En effet, s’il n’y a qu’une entité Étudiant, il y aura
plusieurs occurrences d’Étudiant.
Sur le MCD, une association relie des entités. En revanche, une occurrence d’asso-
ciation ne concerne que des occurrences d’entité. Elle sera formée par une (et une
seule) occurrence de chaque entité reliée.
Dans le MCD, on fait figurer toutes les propriétés de chaque entité. Pour distin-
guer l’identifiant, on le souligne et on le met en tête des propriétés.
Par définition, toute valeur d’identifiant (d’entité ou d’association) est unique.
C’est pourquoi on ne peut pas relier deux fois les mêmes occurrences d’entité par
une même association.
On peut caractériser une association par ses cardinalités maximales : Une associa-
tion [1–n] est une binaire dont une cardinalité maximale vaut 1, l’autre n. Une asso-
ciation [n–n] est une association dont toutes les cardinalités maximales valent n.
49
8 3932 TG PA 01
Travaux dirigés 1
L’objet des exercices qui suivent est de mettre en œuvre de façon systémati-
que les concepts vus dans le cours pour que cela devienne un automatisme.
Je ne peux que vous rappeler une dernière fois la nécessité de bien connaître
le cours avant de commencer. Sinon, les exercices ne vous permettront pas
l’assimilation des différentes notions. Ces exercices vous permettront égale-
ment d’étudier des cas classiques. Plus que de simples exercices d’application,
ils sont plutôt un complément de cours. Ne les bradez pas !
Enfin, faites les exercices dans l’ordre, la difficulté (bien que modeste) étant
croissante.
Exercice 1
Plusieurs kinésithérapeutes se sont regroupés en un cabinet de kinésithérapie. Chacun d’eux
est identifié par un numéro identifiant attribué par le ministère de la Santé. Ils ont un nom et
un prénom. Chaque praticien possède une clientèle indépendante : chaque patient n’a affai-
re qu’à un seul praticien. On retiendra les nom, prénom et téléphone de chaque patient.
Travail à faire
Faites le MCD modélisant le cabinet.
Exercice 2
L’entreprise X est spécialisée dans la vente de produits informatiques. Elle vous demande
d’informatiser sa gestion des stocks. Comme vous débutez dans le métier (tout le monde a
commencé un jour, n’est-ce pas ?), vous ne savez pas trop ce que tout cela signifie. Le res-
ponsable de X, qui a conscience que vous ne pourrez informatiser la gestion du stock qu’en
la comprenant, vous donne les informations suivantes :
Nous vendons du matériel informatique à toute sorte de clients : particuliers, entreprises,
administrations… En général, les entreprises et administrations passent des commandes de
plusieurs dizaines de postes. Il n’est pas question de les livrer dans la journée. Les pièces en
stock ne leur sont pas destinées. En fait, nous réservons nos stocks aux particuliers qui vien-
nent directement au magasin ou passent leur commande par correspondance. Nous voulons
lancer le concept « votre PC prêt en 48 heures » : le client choisit sa configuration (quelle
carte mère, quel processeur, quelle carte graphique…) et nous assemblons son PC en deux
jours. Mais bien entendu, pour pouvoir réaliser l’assemblage, nous devons avoir les pièces en
51
8 3932 TG PA 01
Séquence 3
Bon, pour répondre à votre questionå, c’est très simple ! Une famille de produits (je pré-
férerais d’ailleurs le terme type à famille, cela fait plus professionnel) possède un nom (par
exemple carte mère) et un numéro d’étagère (car, comprenez-vous, on essaye de stocker les
produits de même type ensemble. Et, quitte à informatiser, j’aimerais avoir le numéro d’éta-
gères où sont stockés les produits d’une famille, euh non, d’un type donné).
Un produit a un nom, une marque, un prix hors taxes et fait partie d’une seule famille de
produits.
Travail à faire
1. Réalisez le MCD représentant les types de produits et les produits.
Le commercial de l’entreprise, qui est informaticien, vient vous voir discrètement pour vous
dire que le dirigeant que vous avez rencontré était avant tout un brillant gestionnaire, mais
n’était pas un spécialiste de l’informatique. Notamment, il n’a pas pris en compte le fait qu’un
produit pouvait appartenir à plusieurs types ; par exemple, une carte mère peut posséder un
circuit son voire vidéo, donc être à elle seule carte mère, carte son et carte graphique.
2. Corrigez le MCD en conséquence.
Vous êtes rappelé en catastrophe par le responsable : « pour gérer efficacement les stocks,
vous dit-il, il faut savoir combien l’on a d’exemplaires de chaque produit en stock. Et j’aime-
rais aussi savoir le nombre de produits de chaque type que je possède. »
3. Adaptez le MCD en conséquence si besoin est (une aide : repensez au cas de la gestion des
permis de construire quand on voulait la surface du terrain en ares et en m2).
Note sur cet exercice : cet exercice est important car la notion de couple produit/type de
produits est un classique.
Exercice 3
Un cabinet médical est constitué par une dizaine de médecins. Chacun d’eux est identifié
par un numéro attribué par le ministère de la Santé. Ils ont un nom, un prénom, un numéro
de poste téléphonique et une spécialité (généraliste, cardiologue…). Chaque praticien pos-
sède une clientèle indépendante : un patient ne consultera qu’un médecin par spécialité (le
patient d’un généraliste n’ira jamais consulter un autre généraliste du cabinet). En revanche,
un même patient peut consulter des spécialistes différentsç (comme un généraliste et un
cardiologue). On retiendra les nom, prénom et téléphone de chaque patient.
Travail à faire
Faites le MCD modélisant le cabinet.
å Oui, vous avez réussi à glisser une question dans ce discours fleuve qui, bien qu’intéres-
sant pour la culture générale, a peu d’intérêt pour ce que vous avez à faire.
52
8 3932 TG PA 01
Exercice 4
Le responsable d’un cabinet d’architectes souhaite informatiser la gestion des différentes éta-
pes pour construire une maison. Pour cela, il a distingué 20 étapes essentielles (fondations,
charpente, toiture, hors d’eau…). Chaque étape aura un nom l’identifiant sans ambiguïté,
une durée en jours et un lieu de réalisation (intérieur ou extérieur de la maison).
Le responsable du cabinet dispose d’une liste de 1 à 8 entreprises sérieuses pour chaque
étape, certaines entreprises pouvant être retenues pour plusieurs étapes. Une entreprise
seracaractérisée par les propriétés habituelles. Pour chaque étape, on aura le nom d’une
personne du cabinet apte à vérifier la bonne réalisation du travail fait.
Travail à faire
Faites le MCD modélisant la gestion des étapes.
Exercice 5
Je commence à être à court d’exercices 2 entités et une association binaire. Plus précisément,
je suis à court. De plus, ce n’est pas franchement intéressant. Nous allons donc aller un peu
au-delà. Cela ne rend pas les exercices plus compliqués pour autant !
On reprend le sujet précédent, sauf le contrôleur qu’on laisse dans l’exercice 4. Ce qui donne
(j’ai résumé) :
Une maison est construite par étapes (nom l’identifiant sans ambiguïté, une durée en jours, un
lieu de réalisation – intérieur ou extérieur de la maison –). Pour chaque étape, on dispose d’entre-
prises pouvant les réaliser. Certaines entreprises pouvent être retenues pour plusieurs étapes.
On rajoute ce qui suit : le cabinet d’architectes fait aussi bureau d’études, maîtrise d’ouvrage…
C’est une entreprise d’une taille importante, divisée en multiples services. Notamment, tous les
salariés compétents pour suivre une étape donnée du chantier sont regroupés dans un service.
On aura donc un service compétent par étape de construction. Pour faire la toiture d’une mai-
son, le cabinet prendra donc une des entreprises habilitées pour cette étape toiture et deman-
dera à l’un des salariés du service compétent dans la toiture de contrôler le travail.
Un service possède un libellé et une date de création. Un salarié possède un nom, un prénom,
une adresse, un téléphone et une date d’embauche. Un salarié pouvant être compétent dans
plusieurs domaines, il peut être affecté à différents services.
Travail à faire
Mettez à jour le MCD pour prendre en compte ces modifications.
Si vous avez du mal, travaillez par étapes : réalisez le MCD des services et salariés, puis reliez
les deux MCD.
Exercice 6
On reprend le sujet de l’exercice 4, en enlevant toute référence aux contrôles :
Une maison est construite par étapes (nom l’identifiant sans ambiguïté, une durée en jours, un
lieu de réalisation – intérieur ou extérieur de la maison –). Pour chaque étape, on dispose d’en-
treprises pouvant les réaliser. Certaines entreprises peuvent être retenues pour plusieurs étapes.
53
8 3932 TG PA 01
Séquence 3
Pour éviter tout problème de fraude, le cabinet décide d’externaliser le contrôle des chan-
tiers qu’elle dirige. Ainsi, ce n’est plus un salarié du cabinet qui ira vérifier la bonne réalisa-
tion d’une étape de la construction, mais une entreprise tierce. Pour chaque étape, le cabinet
a sélectionné une entreprise de vérification (jamais une entreprise déjà retenue pour réaliser
une étape). Chaque entreprise de vérification ne pourra vérifier qu’une étape.
Travail à faire
1. Mettez à jour le MCD pour prendre en compte l’entreprise de vérification. Il y a deux solu-
tions possibles : soit l’on regroupe toutes les entreprises (on n’a alors qu’une association
à rajouter), soit l’on distingue entreprises de construction et entreprises de vérification
(dans ce cas, il faut ajouter une entité et une association). Faites un MCD pour chaque
solution.
Exercice 7
Gestion des permis de construire (deuxième partie). Rappel du sujet initial (j’ai enlevé les
fioritures) :
Un terrain est caractérisé par une référence cadastrale, une surface en ares, un type (cons-
tructible, inondable, indéterminé…). Un propriétaire est caractérisé par ses nom, prénom,
adresse et date de naissance.
Un terrain appartient à un seul propriétaire.
On rajoute la gestion des maisons.
Une maison est décrite par une surface au sol, un nombre de pièces, un type de chauffage (gaz
ou électrique), une date d’achèvement. Elle appartient à un propriétaire unique. Bien entendu,
le terrain et le(s) maison(s) qui y sont bâties doivent appartenir à la même personne : pas ques-
tion d’aller construire une maison sur le terrain du voisin quand il est parti en vacances !
Travail à faire
Faites le MCD correspondant (attention aux redondances !)
Exercice 8
Changeons un peu de type d’exercice. Je vous donne un MCD, vous me donnez la description
du réel correspondant sans paraphraser le schéma. Bien entendu, la difficulté est de retrou-
ver les règles de gestion au travers des associations et cardinalités (aucune n’est anodine),
sachant que vous avez droit à une primeur : une ternaire !
Premier MCD :
ÉTUDIANT
NuméroÉtudiant
Nom COURS
1,n 0,n
Rue Durée
Code postal
Ville
54
8 3932 TG PA 01
Second MCD :
ÉTUDIANT
NuméroÉtudiant
suivre COURS
Nom 1,n 0,n
Titre
Prénom
Durée
Rue 1,n
Code postal
Ville ANNÉE
AAAA
L’entité Année ne dois pas vous angoisser. L’identifiant AAAA indique juste que l’on stocke
l’année (A pour Année) sur quatre chiffres (p. ex. 2001). L’entité est assez particulière puis-
qu’elle n’a qu’une seule propriété. Mais bon, que rajouter à une date ? La question à laquelle
vous devez répondre est en fait : « Pourquoi a-t-on besoin de gérer la date comme une
entité, donc d’utiliser une ternaire et non une binaire ? Hein ? »
Travail à faire
Donnez le réel représenté par le second MCD et comparez avec le premier, que vous con-
naissez déjà.
Exercice 9
Exploitons les ternaires !
Transportons-nous dans un lycée pour gérer les inspections des enseignants.
Un enseignant (nom, prénom, adresse, téléphone et date d’obtention du concours) est
inspecté à plusieurs reprises dans sa carrière. Bien entendu, toutes les informations liées à
chaque inspection (date [notée JJMMAAAA] et nom de l’inspecteur) sont mémorisées et
suivent l’enseignant tout au long de sa carrière. Un inspecteur est caractérisé par ses nom,
prénom, adresse et date d’arrivée dans le corps des inspecteurs. Tous les membres de l’Édu-
cation Nationale, dont les inspecteurs et enseignants, sont identifiés par un Numen (NUMéro
d’Éducation Nationale, identifiant interne à l’Éducation Nationale).
Travail à faire
Pour changer, faites donc le MCD de la gestion des inspections au sein du lycée !
Exercice 10
Encore plus qu’une ternaire !
Retournons dans le lycée pour terminer la gestion des inspections. On rajoute au sujet la
contrainte suivante :
Un professeur enseigne dans une discipline donnée. Un inspecteur n’est habilité que pour
une discipline. L’inspecteur ne visitera que les enseignants de sa discipline. Une discipline est
caractérisée par la matière (français, mathématiques…) et le niveau d’enseignement (collège,
lycée, lycée professionnel, BTS…).
Travail à faire
Rajoutez cette contrainte dans le MCD précédent (celui avec l’association inspecter).
55
8 3932 TG PA 01
Séquence 4
MCD : fin
Nous allons étudier ici les derniers concepts relatifs au MCD : les porteuses de
données, les réflexives et les entités faibles. Ce ne sont pas des choses nouvelles,
plutôt des cas particuliers d’associations.
• Représenter graphiquement un MCD.
u Contenu
1. Association porteuse de données ................................................ 58
1A. Introduction ............................................................................................... 58
1B. Définition ................................................................................................... 59
2. Association réflexive ......................................................................... 61

2A. Introduction ............................................................................................... 61
2B. Définition ................................................................................................... 63
3. Les entités faibles ............................................................................... 64

3A. Présentation ............................................................................................... 64
3B. Définition ................................................................................................... 66
3C. Autre formalisme ...................................................................................... 67
Synthèse
57
8 3932 TG PA 01
Séquence 4
1. Association porteuse de données
1A. Introduction
Revenons à l’inspection des enseignants vue dans les travaux dirigés. Ce n’est pas
quelque chose du style « descente de police ». L’enseignant ne risque pas son poste.
Cependant, ce n’est pas non plus une visite de courtoisie. L’inspecteur attribuera une
note et un commentaire (rapport d’inspection) qui influera sur la vitesse d’avancement
de carrière de l’enseignant.
Autant dire que l’important dans la visite n’est pas vraiment le nom de l’inspecteur qui
n’est conservé qu’à des fins de contrôle. C’est avant tout la note attribuée, ainsi que la
date de l’inspection qui indique quand prendre en compte la note.
Il faut donc stocker ces données (notes et commentaires) dans notre système d’informa-
tion, sachant que chaque inspection donne une note et un commentaire. Nous allons
travailler sur le sujet initial (exercice 9 des travaux dirigés précédents) que je complète
un peu, ce qui donne :
Un enseignant (nom, prénom, adresse, téléphone et date d’obtention du concours) est
inspecté à plusieurs reprises dans sa carrière.
Les informations liées à chaque inspection (date, inspecteur, note et commentaire) sont
mémorisées et suivent l’enseignant tout au long de sa carrière.
Un inspecteur est caractérisé par ses nom, prénom, adresse et date d’arrivée dans le corps
des inspecteurs.
Tous les membres de l’Éducation Nationale, dont les inspecteurs et les enseignants, sont
identifiés par un Numen (NUMéro d’Éducation Nationale, identifiant interne à l’Éduca-
tion Nationale).
Exercice 25
En reprenant le MCD où l’inspection était représentée par une entité (voir la correction de
l’exercice 9 des travaux dirigés précédents), prenez en compte les nouvelles données relatives
à l’inspection : la note et le commentaire.
Dans l’exercice 9, nous avions représenté l’inspection de deux façons différentes : avec
une entité puis une association. Le cas de l’entité vient d’être réglé facilement dans
l’exercice précédent. Reste donc l’association. Je vous rappelle le MCD :
INSPECTEUR ENSEIGNANT
Numenlnsp NumenEns
Nomlnsp NomEns
Prénomlnsp inspecter PrénomEns
1, n 0, n
Adrlnsp AdrEns
Codelnsp CodeEns
Villelnsp 1, n VilleEns
Datelnsp DateEns
DATE
JJMMAAAA
58
8 3932 TG PA 01
MCD : fin
Où faire figurer la note et le commentaire de l’inspection ? Quand l’inspection est une

entité, c’est simple, mais ici l’inspection est assez intangible puisque uniquement repré-
sentée par un lien.
La note et le commentaire sont liés à une inspection. Or, ici, qu’est-ce qui détermine l’ins-
pection ? c’est l’association. Et qu’est-ce qui identifie l’association ? C’est son identifiant,
soit la concaténation des identifiants des entités reliées.
Une inspection sera donc identifiée par NumenInsp, NumenEns et JJMMAAAA, bref par
une occurrence d’Inspecteur, une occurrence d’Enseignant et une occurrence de Date.
La note et le commentaire seront déterminés par ces mêmes valeurs, donc sont liés à
l’occurrence d’inspecter.
Nous allons donc lier les données à l’association elle-même. L’association sera dite por-
teuse de données, ou, plus simplement, porteuse :
Numenlnsp NumenEns
Nomlnsp NomEns
Prénomlnsp inspecter PrénomEns
1, n 0, n
Adrlnsp note AdrEns
commentaire
Codelnsp CodeEns
Villelnsp VilleEns
1, n
Datelnsp DateEns
DATE
JJMMAAAA
Notez le formalisme : les données (propriétés) sont écrites dans le rond de l’association, sous son nom (nom et
propriétés étant séparés par un trait).
On obtient alors la définition présentée dans les lignes suivantes.
1B. Définition
Association porteuse de données : une association est porteuse de données si elle
possède une ou plusieurs propriétés.
L’identifiant de l’association déterminant l’occurrence de l’association, il détermi-
nera aussi la valeur de ces propriétés (comme pour une entité).
Finalement, on peut faire un parallèle entre entité et association, puisque les deux ont
des occurrences, des identifiants et des propriétés. Ce parallèle est si fort qu’on hésite
parfois entre une entité et une association pour représenter un concept. On fera le point
sur ce problème dans la séquence suivante.
Très souvent, on est en plein ravissement lorsque l’on découvre un nouveau concept et
l’on tente de l’utiliser partout. Il ne faut donc pas se laisser aller et utiliser les associations
porteuses de données à tout bout de champ.
On ne mettra des propriétés dans une association que si ces propriétés sont déterminées
(identifiées) par tout l’identifiant de l’association.
59
8 3932 TG PA 01
Séquence 4
Exercice 26
Reprenons notre vieil exercice sur les étudiants s’inscrivant au CNED. Je vous rappelle le MCD :
ÉTUDIANT
NumeroÉtudiant
Nom COURS
1, n 0, n
Rue Durée
Code postal
Ville
Pour assurer le suivi pédagogique des étudiants, le CNED veut conserver la moyenne annuelle
des étudiants pour chaque cours suivi. Modélisez cela sur le MCD.
Attention, il y a une astuce !
Exercice 27
Simplifions le sujet : le CNED s’est aperçu que la multiplication des inscriptions nuisait aux étu-
diants, qui ne pouvaient pas valablement suivre plusieurs enseignements à la fois. Il est donc
décidé de n’admettre qu’une inscription annuelle. Modifiez le MCD de l’exercice précédent en
conséquence.
Attention, il y a une astuceå !
Reprenons la conclusion de l’exercice et faisons-en une règle de validation de MCD, à

savoir une règle absolue qui, lorsqu’elle est violée, indique irrémédiablement une erreur
dans le MCD :
une association ayant une cardinalité 1,1 (ou 0,1) ne peut pas être porteuse de données.
å Et cette fois, je ne plaisante pas.
60
8 3932 TG PA 01
MCD : fin
2. Association réflexive
2A. Introduction
Ce n’est pas un nouveau concept théorique, mais un cas particulier d’association. Nous
allons travailler sur le sujet suivant :
Nous sommes à la mairie pour informatiser la gestion de l’état civil, notamment les
mariages. Les conditions sont simples : une personne possède un nom, prénom, sexe,
adresse, date et lieu de naissance. Un mariage est réalisé entre deux personnes de sexes
différents. On considère qu’une personne peut être mariée plusieurs fois (bien entendu
à des dates différentes, mais on ne gère pas les dates pour le moment).
Exercice 28
Faites le MCD du sujet ci-dessus en prenant bien garde de respecter la contrainte du mariage
entre personnes de sexes différents.
La solution vue dans le corrigé de l’exercice n’est pas satisfaisante car, pour relier deux
personnes par les liens sacrés du mariage (pour relier deux occurrences de Personne par
une occurrence d’épouser), nous avons représenté deux fois la même entité.
Mais, au fait, pourquoi nous sommes-nous senti obligés de faire cela ? Regardez l’« ani-
mation » suivante :
PERSONNE PERSONNE PERSONNE

1, n
NumeroP NumeroP NumeroP épouser
NomP NomP NomP PERSONNE
PrénomP
SexeP
DateNaissanceP 1, n
épouser
1, n
PrénomP
SexeP
DateNaissanceP
u PrénomP
SexeP
DateNaissanceP
NumeroP
NomP
PrénomP
1, n
AdrP AdrP AdrP SexeP

CodeP CodeP CodeP DateNaissanceP
VilleP VilleP VilleP AdrP
CodeP
u
VilleP
PERSONNE
NumeroP PERSONNE
1, n NumeroP 1, n
NomP u
PrénomP épouser NomP PERSONNE
SexeP PrénomP
NumeroP épouser
1, n SexePNomP
DateNaissanceP
AdrP DateNaissanceP
PrénomP
CodeP AdrPSexeP
1, n
VilleP CodePDateNaissanceP
VilleP
AdrP
CodeP
VilleP
Il ne s’agit pas de mettre les deux entités Personne l’une sur l’autre. Je voulais juste vous mon-
O trer pourquoi il était intuitif et naturel de relier une entité avec elle-même par une association.
En fait, une occurrence d’épouser relie bien deux occurrences d’entité… que ces occurrences
appartiennent à la même entité est secondaire. Une telle association sera dite réflexive.
61
8 3932 TG PA 01
Séquence 4
Vous remarquerez que le problème évoqué dans la correction de l’exercice précédent est
résolu : on a bien unicité de l’entité et donc aucune partition des différentes occurrences.
Les deux pattes d’épouser symbolisent toujours la même chose : l’une des personnes est
le mari, l’autre est la femme. Sauf qu’avant, c’était évident (la patte reliée à Homme
représentait le mari, celle reliée à Femme représentait la femme). Maintenant, on ne sait
plus quelle patte représente qui puisque le MCD est parfaitement symétrique : les deux
pattes étant identiques, elles sont interchangeables.
Lorsque c’est utile pour la compréhension du MCD, on peut nommer les pattes des
réflexives pour savoir quel est le rôle de chacune d’elles.
Cela donnerait ici :
PERSONNE L'occurence de Personne reliée par cette

1, n époux patte d'épouser doit être un homme.
NumeroP
NomP épouser
PrénomP épouse
SexeP 1, n
DateNaissanceP
AdrP L'occurence de Personne reliée par cette patte
CodeP d'épouser doit être une femme.
VilleP
Remarques
1. Indiquer le rôle de chaque patte obligera à le respecter lors de la saisie des données.
Si la première patte indique l’homme et la seconde la femme, cela signifie que le pro-
gramme devra vérifier que la première personne indiquée pour le mariage a pour sexe
homme, la seconde ayant pour sexe femme. Il est inutile d’ajouter la moindre règle de
gestion puisque l’information est contenue dans le MCD.
2. À notre niveau, choisir l’une ou l’autre des pattes et l’appeler époux, l’autre étant
épouse, n’a aucune importance. En revanche, lorsque l’on créera la base de données,
des raisons d’efficacité du traitement rendront le choix moins anodin. Mais ces consi-
dérations opérationnelles n’ont aucune valeur au niveau conceptuel.
3. Si l’on est déterminé à faire des âneries, le MCD n’empêche pas qu’une personne
s’épouse elle-même ! (Sauf à mettre en œuvre la vérification par le programme vue
dans la première remarque.)
Je vous conseille d’indiquer systématiquement les rôles des pattes des réflexives pour
augmenter la lisibilité du modèle.
Oh là ! Tout à notre excitation de découverte de ce nouveau jouet qu’est la réflexive,
nous avons oublié nos réflexes de base : la vérification des cardinalités.
Exercice 29
Dans le MCD ci-dessus mettant en œuvre la réflexive, les cardinalités sont fausses. Pourtant,
elles sont justes dans les MCD représentant la même chose mais sans réflexive. Expliquez pour-
quoi, puis corrigez ces cardinalités.
62
8 3932 TG PA 01
MCD : fin
J’insiste ! on retiendra :
Lorsque l’on bâtit une nouvelle association sur une entité en comportant déjà (donc
quand on rajoute une patte d’association à une entité), les cardinalités déjà existan-
tes doivent être revisitées.
2B. Définition
Ah, j’oubliais la définition ! Il fallait me la réclamer !
Association réflexive : une association est réflexive si une entité participe plus
d’une fois à cette association. Il est préférable de toujours indiquer les rôles des pat-
tes et il faut vérifier soigneusement les cardinalités.
Vous remarquerez que la définition n’est pas restrictive ; les trois associations suivantes
sont donc des réflexives :
ENTITÉ
0,n
Propriété_1
ENTITÉ_1 0,n ENTITÉ_2
Propriété_2 association association
0,n (propriétés) (propriétés)
(etc)
0,n 1,n
Propriété_n 0,n
ENTITÉ_3
(propriétés)
0,n
ENTITÉ_1 0,n 0,n ENTITÉ_2
association
(propriétés) 0,n (propriétés)
0,n 0,n
Si ces associations sont correctes d’un point de vue modélisation, il n’est pas du
O tout évident que la sémantique qu’elles apportent ait un sens dans la vie réelle.
C’est d’ailleurs parce que je n’ai pas trouvé d’exemple que je n’ai pas donné de nom
aux associations et entités.
Dit autrement, si vous êtes amené à produire de tels mutants, vérifiez une dizaine de
fois leur validité.
Bien, nous allons exploiter notre nouvelle connaissance dans trois exercices sympathiques.
Exercice 30
Nous reprenons le sujet précédent (le mariage). Cette fois, nous voulons faire les choses cor-
rectement : un mariage est célébré à une date précise. Il prend éventuellement fin à une date
précise (correspondant à la date du divorce). Une personne ne peut contracter qu’un mariage
à la fois. Faites le MCD correspondant.
J’insiste ! On retiendra :
Lorsqu’un événement matérialisé par une association doit être historisé, la propriété
date devient une entité participant à l’association.
63
8 3932 TG PA 01
Séquence 4
Exercice 31
On rajoute les témoins : un mariage doit être célébré en présence de deuxå témoins (nom, pré-
nom, adresse, date de naissance… les choses classiques). Rajoutez les témoins dans le MCD.
Exercice 32
On n’a pas encore donné la correction de l’exercice précédent, mais ce nouvel exercice est sensé
vous aider. Je vous rajoute les contraintes suivantes : un mariage est célébré non seulement à
une date précise, mais aussi à une heure précise. Les époux peuvent avoir signé un contrat de
mariage auprès d’un notaire (nom, prénom, adresse…). Il y a plusieurs types de contrats : com-
munauté, communauté réduite aux acquêts, séparation de biens… Évidemment, il faut stocker
le type du contrat et le notaire pour pouvoir rédiger les actes officiels. Les époux doivent dési-
gner de 2 à 4 témoins. Enfin, le maire ou l’un de ses adjoints peut célébrer le mariage. Chacune
de ces personnes est identifiée par ses nom, prénom, date de naissance et date d’élection en
tant que maire ou adjoint. Faites le MCD. Attention, cet exercice n’est pas spécialement diffi-
cile, mais il contient des pièges potentiels.
å C’est inexact puisque en réalité, il doit y avoir de 2 à 4 témoins. Cette simplification sera
supprimée dès l’exercice suivant.
3. Les entités faibles
3A. Présentation
Pas question de leur faire faire de la musculation ! Elles ne sont pas faibles par manque
de muscle, mais parce qu’elles sont dépendantes d’autres entités, un peu comme un
bébé teckel dépend de sa maman teckel.
Exercice 33
Le fait qu’une entité dépende d’une autre doit vous choquer affreusement ; pourquoi ?
Nous allons voir que les entités faibles permettent de traduire un concept de la vraie vie :
la notion de dépendance, qui ne peut être correctement représenté par une association.
Étudions le cas suivant :
Une centrale hôtelière vous demande de gérer son parc de chambres d’hôtel. La descrip-
tion du réel est la suivante : la centrale gère une dizaine d’hôtels, chacun étant décrit
par un nom, une adresse et un nombre de chambres. Chaque chambre est décrite par son
étage, son numéro de porte, sa capacité (une, deux ou trois personnes) et la présence ou
l’absence de cabinet de toilette.
Exercice 34
Faites le MCD modélisant le système d’information de la centrale hôtelière.
64
8 3932 TG PA 01
MCD : fin
Analysons la solution de l’exercice : l’identifiant artificiel des chambres est très lourd.
Dans la réalité, on ne parlera pas de la chambre 984, mais plutôt de la chambre 27 de
l’hôtel numéro cinq. De plus, ces deux chiffres (27 et 5) sont stockés dans le système
d’information.
Exercice 35
Où sont stockées ces informations ? En d’autres termes, comment puis-je savoir dans quel
hôtel est la chambre d’identifiant artificiel 984 et quel est son numéro réel ?
Résumons-nous
1. Dans la vraie vie, on parlera de la chambre d’un hôtel donné (chambre 27 de l’hôtel
5) plutôt que de la chambre seule (chambre 984), puisque ce numéro 984 n’existe pas
dans la réalité.
2. La chambre est toujours liée à un et un seul hôtel (patte 1,1). Une chambre sans hôtel
associé n’a pas de sens.
On a déjà la solution intuitive à ce problème : on va supprimer l’identifiant artificiel
de Chambre et dire que chaque chambre est identifiée par son numéro d’hôtel et son
numéro de porte. Cela donnera le MCD suivant :
HÔTEL
CHAMBRE
NumeroHôtel
NuméroHôtel
NomHôtel
contenir NuméroChambre
NbrChambres 1,n 1,1
Étage
AdrHôtel
NbrPersonnes
CodeHôtel
Cabinet
VilleHôtel
Vous remarquerez que j’ai renommé NuméroPorteChambre en NuméroChambre puis-

qu’il n’y a plus d’ambiguïté.
Nous sommes d’accord sur le fait que la concaténation des deux propriétés NuméroHôtel
et NuméroChambre forme un identifiant valide. En effet :
− l’hôtel 5 possède de nombreuses chambres. NuméroHôtel n’est donc pas identifiant
de Chambre ;
− la chambre 27 existe dans chaque hôtel (NuméroChambre n’est donc pas non plus
identifiant) ;
− en revanche, la chambre 27 de l’hôtel 5 est unique. La concaténation des deux pro-
priétés est donc identifiant.
Exercice 36
Hélas pour nous, cette solution n’est pas conforme aux règles du MCD. Quel est le problème ?
65
8 3932 TG PA 01
Séquence 4
Ce n’est pas le seul problème : à la suite de notre raisonnement, il est évident, pour nous,
que la chambre et l’hôtel associés par contenir ont une même valeur pour NuméroHôtel.
Mais cela n’est pas évident pour quelqu’un prenant le cours en route.
En clair, ce que l’on veut représenter n’est pas modélisable pour le moment ; nous avons donc
besoin d’un outil supplémentaire. C’est outil, ce n’est pas une surprise, c’est l’entité faible.
Dans notre exercice, on dira que l’entité Chambre est une entité faible, dépendante de
l’entité Hôtel. On représentera cela en encadrant la propriété NuméroHôtel de Chambre
par des caractères # comme suit :
HÔTEL
CHAMBRE
NumeroHôtel
#NuméroHôtel#
NomHôtel
NuméroChambre
NbrChambres contenir
AdrHôtel 1,n 1,1 Étage
CodeHôtel NbrPersonnes
VilleHôtel Cabinet
C’est un peu décevant… la seule différence entre ce MCD et le précédent, ce sont deux #.
Mais il est important de comprendre que ces deux caractères changent tout !
Les # indiquent que l’on a affaire à une entité faible : les occurrences de Chambre et
Hôtel reliées par contenir ont la même valeur pour NuméroHôtel, cela traduisant le fait
que la chambre appartient à un hôtel précis.
Nous sommes prêts à aborder la définition.
3B. Définition
Entité faible : une entité faible est une « chose » du monde réel qui possède une exis-
tence propre dépendant de l’existence d’une autre entité, des caractéristiques bien
définies, qui présente un intérêt et a un sens pour le système d’information étudié.
(on retrouve la définition d’entité, j’ai mis en gras ce qui était nouveau.)
On apprendra également la remarque suivante :

Une occurrence d’entité faible n’existe que vis-à-vis de l’occurrence d’une autre entité.
On ne peut donc pas avoir d’autres cardinalités que 1,1 du côté de l’entité faible.
Je me permets un commentaire assez technique sur ce 1,1. Ces cardinalités signifient qu’une
occurrence de l’entité correspondante ne participe qu’à une et une seule occurrence d’asso-
ciation. Mais cela peut donner les deux situations tout à fait différentes que je vais illustrer.
66
8 3932 TG PA 01
MCD : fin
HÔTEL CHAMBRE SERVICE SALARIÉ

NuméroHôtel 1,n 1,1 #NuméroHôtel# NuméroService 0,n 1,1 NuméroSalarié
contenir travailler
NomHôtel NumeroChambre Description Nom
(etc) (etc) Prénom
La chambre est physiquement dans un seul hôtel, toujours Tant qu’il travaille dans l’entreprise, un salarié est toujours
le même. On dit alors que l’association contenir est stable affecté à un seul service. Mais, au fur et à mesure de sa
(sous entendu stable dans le temps) : lorsqu’une chambre est carrière, il peut changer de service. L’association travailler n’est
associée à un hôtel, c’est pour longtemps ! L’emploi d’une donc pas stable. On ne pourra pas utiliser d’entité faible.
entité faible est valide.
Ainsi, non seulement l’entité faible doit être liée à une autre entité, mais chaque
occurrence de l’entité faible doit être liée de façon permanente à une occurrence de
l’autre entité.
Classiquement, on utilisera une entité faible lorsque l’on aura explicitement un numéro
d’occurrence vis-à-vis d’une autre occurrence (un numéro de chambre dans un hôtel, un
numéro de place dans un train…).
Étudions cela au travers de quelques exercices.
Exercice 37
Nous voulons modéliser l’activité d’une médiathèque. Une inscription est faite au nom d’une
famille. Comme chaque enfant a droit à un nombre d’emprunts différent selon son âge, on
souhaite stocker, pour chaque inscription, la liste des enfants avec leur rang (le premier, le
deuxième…). Faites le MCD correspondant.
Exercice 38
Le service d’état civil d’une préfecture possède une base de données référençant les habitants.
Chaque personne est donc une occurrence d’une entité Personne contenant classiquement le
nom et l’adresse en propriétés.
Le service souhaite maintenant réaliser des statistiques sur les prénoms des habitants. Une per-
sonne possède de 1 à 3 prénoms dont l’ordre importe. Un prénom est décrit par son libellé et
par sa date d’apparition en France.
On vous demande de rajouter une entité Prénom et de mettre à jour le MCD en conséquence.
3C. Autre formalisme

Pour terminer, ouvrons les yeux sur ce qui se passe ailleurs : la représentation de l’entité
faible n’est pas standardisée. Vous pourrez donc trouver dans la littérature la représen-
tation suivante :
HÔTEL
CHAMBRE
NumeroHôtel
NuméroChambre
NomHôtel
Étage
NbrChambres contenir
1,n (1,1) NbrPersonnes
AdrHôtel
Cabinet
CodeHôtel
VilleHôtel
67
8 3932 TG PA 01
Séquence 4
C’est encore plus discret que les # ! Avez-vous vu le formalisme ? Les cardinalités 1,1
du côté de l’entité faible sont entre parenthèses. Et c’est tout ! Attention, notez bien
que cette représentation signifie toujours la même chose, à savoir que l’identifiant de
Chambre est constitué de NuméroHôtel et NuméroChambre même si cela n’est pas
repris explicitement dans le MCD.
Comme je trouve qu’il y a trop d’implicite dans ce formalisme, je vous conseille les #.
Voilà ! À bientôt dans la séquence suivante.

Vérifiez bien vos MCD !
Vous pouvez, dès maintenant, faire et envoyer à la correction le devoir 1 (voir fasci-
cule « devoirs » réf. 3932 DG).
68
8 3932 TG PA 01
Synthèse
Définitions
Association porteuse de données : une association est porteuse de données
si elle possède une ou plusieurs propriétés. L’identifiant de l’association détermi-
nant l’occurrence de l’association, il déterminera aussi la valeur de ces propriétés
(comme pour une entité).
Association réflexive : une association est réflexive si une entité participe plus
d’une fois à cette association. Il est préférable de toujours indiquer les rôles des
pattes et il faut vérifier soigneusement les cardinalités.
Entité faible : une entité faible est une « chose » du monde réel qui possède
une existence propre dépendant de l’existence d’une autre entité, des
caractéristiques bien définies, qui présente un intérêt et a un sens pour le système
d’information étudié.
Conseils
Si une association est porteuse de propriétés. Vérifiez que ces propriétés sont déterminées
(identifiées) par tout l’identifiant de l’association.
Lorsque l’on bâtit une nouvelle association sur une entité en comportant déjà (donc quand
on rajoute une patte d’association à une entité), les cardinalités déjà existantes doivent
être revisitées.
Lorsqu’un événement matérialisé par une association doit être historisé, la propriété date-
devient une entité participant à l’association.
Une occurrence d’entité faible n’existe que vis-à-vis de l’occurrence d’une autre entité. On
ne peut donc pas avoir d’autres cardinalités que 1,1 du côté de l’entité faible.
Ainsi, non seulement l’entité faible doit être liée à une autre entité, mais chaque occurrence
de l’entité faible doit être liée de façon permanente à une occurrence de l’autre entité.
69
8 3932 TG PA 01
Séquence 5
Le MLD
Cela ne vous posera aucun problème. Bien que simple, c’est une étape primordiale
car elle fait le lien entre le conceptuel et l’informatisation. Outre son intérêt dans
la compréhension globale du système d’information étudié, c’est une production
souvent demandée à l’examen.
• Comprendre l’importance du MLD
• Savoir réaliser un MLD prenant en compte toutes les particularités
du MCD
Contenu
1. Introduction ........................................................................................... 72
1A. Rappel de la définition ............................................................................. 72
1B. Rappel du sermon ..................................................................................... 72
2. Le MLD .................................................................................................... 73
2A. Utilisation du MLD .................................................................................... 73
2B. Rappel de vocabulaire .............................................................................. 73
2C. Notation ..................................................................................................... 74
2D. Règles de passage MCD " MLD .............................................................. 75
2E. Exemples .................................................................................................... 76
2F. Vérification ................................................................................................ 76
2G. Démarche et exemple ............................................................................... 78
2H. Quelques cas particuliers .......................................................................... 79
3. Conclusion (brève !) ........................................................................... 86
Synthèse
71
8 3932 TG PA 01
Séquence 5
1. Introduction
1A. Rappel de la définition

Le MLD se dérive du MCD. Alors que le MCD présente la connexion des données
entre elles de façon théorique (conceptuelle), l’objet du MLD est d’indiquer comment
ces données vont être stockées dans le système informatique pour conserver l’inter-
connexion établie dans le MCD.
Le MLD va dépendre du type d’application informatique utilisé. Jadis on utilisait les
fichiers, maintenant on exploite les SGBD Relationnels (SGBD pour Système de Gestion
de Base de Donnéeså).
Je vais donc vous présenter le MLD orienté SGBD. Notons que Merise a environ 30 ans,
tandis que les SGBD Relationnels ont une petite vingtaine d’années d’existence. Le fait
que la méthode Merise se soit adaptée sans problème à quelque chose de beaucoup plus
moderne montre sa validité : 30 ans après, ses concepts ne sont pas périmés.
Il est sans doute opportun de retourner en séquence 3 paragraphe 2A. pour relire en
diagonale l’approche par le MLD tableau que j’avais utilisée. On remarquera au passage
la simplicité du MLD ! Je m’en étais servi sans vous l’expliquer afin de mieux vous faire
comprendre des notions de MCD.
1B. Rappel du sermon

Je peux ressortir mon sermon de la séquence 5 sur l’obligation de respecter les règles.
Le MLD ne doit pas vous poser de problème puisqu’il s’obtient en appliquant stricte-
ment des règles peu nombreuses. Comme d’habitude, il est préférable de les compren-
dre (de les « sentir » par l’intuition). À défaut, il faut les apprendre et les appliquer
aveuglément.
Bref, il est indigne de répondre de travers quand on vous demande de fournir le MLD à
partir d’un MCD puisque le travail est tellement automatique que des logiciels font cela
sans problème.
Il y a quand même une difficulté : il faut une rigueur extrême car la simplicité de l’exer-
cice est telle que l’oubli de la moindre propriété fait perdre l’essentiel des points.
å Reportez-vous à votre cours de S2 (ALSI, Architecture Logicielle des Systèmes d’Information)

pour une description des SGBD et l’étude du SGBD Access. Notons que les SGBD Relationnels sont
la dernière version des SGBD, qui furent précédemment hiérarchiques ou réseaux.
72
8 3932 TG PA 01
Le MLD
2. Le MLD
2A. Utilisation du MLD

Je répète que nous utilisons un MLD orienté SGBD. Notre objectif est donc de développer
une application autour d’une base de données. Nous devons définir la façon dont on va
stocker les données dans la base pour conserver la structuration apportée par le MCD.
Eh bien, je lève le voile : à notre niveau (ceci est un cours d’analyse, pas de SGBD), le MLD
va être exactement le même que celui avec les tableaux vu en séquence 3 ! Sauf qu’au
lieu de la notion de tableau, on utilisera la notion de table, propre au vocabulaire des
SGBD, bien que le concept sous-jacent soit le mêmeå.
Le MLD va donc vous permettre de définir l’organisation des tables. Il est nécessaire de
connaître les bases de l’utilisation d’un SGBD, notamment la définition des tables sur
Access et le vocabulaire associé.
2B. Rappel de vocabulaire

Le MCD et les tables d’un SGBD partagent plusieurs concepts essentiels. Seuls leurs noms
diffèrent, car ils ont vu le jour à des époques et en des lieux différents. De même que l’on
emploiera le terme répertoire sous DOS et dossier sous Windows pour représenter la même
chose, il convient d’adopter le vocabulaire correspondant à chaque époque et outil.
Même si les termes se réfèrent au même concept, veillez à ne pas les mélanger car cela
sent sa province ! Vous retiendrez donc :
Vocabulaire MCD Vocabulaire MLD et SGBD

identifiant clé primaire
propriété champ
Notons que lorsqu’une propriété (notion conceptuelle) devient un champ, on doit lui
attribuer son type de données puisé dans le dictionnaire des données.
On justifie donc finalement l’emploi de termes différents : en première approximation,
les concepts sont identiques, mais, si l’on est rigoureux, le vocabulaire du SGBD corres-
pond à des notions beaucoup plus ancrées dans le réel.
Il existe un concept propre au MLD : la clé étrangère. Sa définition est simple.
Clé étrangère : une clé étrangère est un champ d’une table qui est clé primaire dans
une autre table.
Retournez très exactement à la séquence 3, paragraphe 4A. et regardez les tableaux
propriétaire et terrain… NuméroPropriétaire est une clé étrangère dans terrain puisque
c’est à la fois un champ de terrain et une clé primaire de propriétaire.
å En fait, le SGBD peut être vu comme un système de tableaux dont l’organisation et la gestion
sont réalisées automatiquement par le SGBD lui-même (évidemment, ce sont l’organisation et la
gestion qui font toute la puissance de ces outils). Lorsque vous ajoutez des données dans une table,
l’interface dans laquelle vous travaillez est un tableau.
73
8 3932 TG PA 01
Séquence 5
2C. Notation
Dans le MCD, on distingue l’identifiant des autres propriétés en le soulignant. De la
même façon, on doit distinguer les clés primaires et les clés étrangères dans le MLD.
Comment faire ?
On devrait utiliser des effets tels le gras et l’italique car rien d’autre n’existe en typogra-
phie, notamment pas le soulignement. En effet, l’italique est l’équivalent typographique
du souligné manuscritå.
Hélas, la communauté informatique a pris l’habitude de souligner les clés primaires, que
le travail soit fait à la main ou sur traitement de texte. Même si ce n’est pas correct, je
reprendrai cette notation pour ne pas me distinguer inutilement.
Notez que sur votre copie, la question ne se pose pas : vous ne pouvez ni écrire en gras,
ni en italique. Il ne vous reste que le soulignement.
La notation pour la clé étrangère est assez tordue. En effet, on fait suivre tout champ clé
étrangère d’un caractère #. Par exemple : NuméroProduit#. C’est une notation tellement
bizarre que je vais tenter de la justifier un peu :
• pourquoi un # ? Parce que l’on est sûr que ce caractère se distinguera du nom du
champ (pas question d’utiliser un e par exemple ; mais on aurait pu choisir %, $…) ;
• pourquoi le mettre en fin de mot ? Bah oui, on aurait également pu le mettre au
début. Je suppose que l’intérêt est de pouvoir lire de gauche à droite : Champ# se
lira Champ est clé étrangère ;
• pourquoi ne pas utiliser un autre soulignement, par exemple en pointillés ? Tout
simplement car un champ peut être à la fois identifiant et clé étrangère. Si vous
pouvez juxtaposer deux soulignements sous un mot à la main, on ne peut pas le
faire aisément avec le traitement de texte ! Word permet le souligné double mais
ne sait pas faire l’un des deux soulignements en pointillés.
Pour résumer, vous noterez que de bêtes problèmes techniques nous font utiliser les
notations suivantes :
Notion Notation Exemple

identifiant souligné NuméroClient
clé étrangère # en fin de mot NuméroProduit#
Vous reprendrez ces notations dans vos devoirs, en les rappelant toujours puisqu’elle ne
sont pas particulièrement normalisées.
Pour décrire une table, on met son nom, suivi entre parenthèses de la liste des champs
séparés par des virgules. On mettra l’identifiant en première position et les clés étrangè-
res éventuelles à la fin pour que ce soit plus lisible. Deux exemples :
NomTable (clé primaire, champ1, champ2…champn)
NomTable (clé primaire, champ1, champ2…champn, clé étrangère1#, clé étrangère2#)
Quelle que soit la notation que vous emploierez pour distinguer les identifiants et les
clés étrangères, je vous conseille de la rappeler après chaque MLD… car l’important n’est
pas la notation, mais le concept qu’elle représente.
å Par exemple, les titres d’œuvres se soulignent à la main et s’écrivent en italique en imprimerie.
74
8 3932 TG PA 01
Le MLD
Exercice 39
Au fait, je vous dis que le soulignement n’est pas correct en typographie. Or, les identifiants
Merise le sont. Pourquoi ? Les pères fondateurs se seraient-ils eux aussi trompés ?
2D. Règles de passage MCD " MLD

Partant du MCD, on va obtenir le MLD en appliquant les règles de passage suivantes :
1. Toute entité devient une table du même nom (identifiant et propriétés devenant
respectivement clé primaire et champs).
2. Toute association [n–n]å devient une table du même nom (identifiant de l’associa-
tion et propriétés éventuelles devenant respectivement clé primaire et champs).
3. Pour toute association [1–n]ç, l’identifiant de l’entité du côté n devient un champ
(appelé clé étrangère) dans la table issue de l’entité du côté 1.
(Retournez voir nos tableaux de la séquence 3 ; vous retrouverez ces règles de passage.)
Si l’on avait unicité des propriétés dans le MCD, on n’a plus unicité des champs dans le
MLD. La clé étrangère semble redondante puisque qu’elle est présente dans plusieurs
tables. C’est tout à fait voulu puisque cette redondance procure un lien entre les deux
tables qui permet de modéliser l’association [1–n]. La redondance n’existe donc pas puis-
qu’elle apporte de l’information.
å Je vous rappelle que la notation [x–y] représente les deux cardinalités maximales de l’association
(voir la séquence 3 § 4D). Une association [n–n] signifie que les cardinalités seront 0,n ou 1,n,
quel que soit le nombre de pattes. Le cas [n–n] couvre donc toute association dont les pattes ont
comme cardinalité maximale n.
ç [1–n] indique une patte 0,1 ou 1,1 et une autre 0,n ou 1,n (si une patte a une cardinalité maxi-
male de 1, on a vu que l’association ne pouvait être qu’une binaire).
75
8 3932 TG PA 01
Séquence 5
2E. Exemples
On va étudier le passage du MCD vers le MLD d’une entité, d’une association [n–n] por-
teuse ou non, puis d’une [1–n].
MCD Traduction MLD

PERSONNE Personne (NuméroPersonne, Nom, Adresse, Ville)
NuméroPersonne
Nom
Adresse
Ville
DATE Personne (NuméroPersonne, Nom, Adresse, Ville)

1,n Date (JJMMAAAA)
PERSONNE JJMMAAAA
NuméroPersonne emprunter Livre (ISBN, TitreLivre, DateAchat)
0,n
Nom LIVRE Emprunter (NuméroPersonne#, JJMMAAAA#, ISBN#)
Adresse ISBN
Ville 0,n
TitreLivre
DateAchat
PERSONNE LIVRE Personne (NuméroPersonne, Nom, Adresse, Ville)

NuméroPersonne
0,n
acheter
0,n ISBN Livre (ISBN, TitreLivre, DateAchat)
Nom date TitreLivre Acheter (NuméroPersonne#, ISBN#, date)
Adresse DateAchat
Ville
PERSONNE Personne (NuméroPersonne, Nom, Adresse, NomVille#)

LIVRE
NuméroPersonne
1,1
habiter
0,n
Ville (NomVille, CodePostal)
NomVille
Nom
Adresse CodePostal
clé étrangère
clé primaire correspondante
On notera plusieurs choses :

• les cardinalités minimales n’ont pas d’importance ici ;
• la table emprunter possède trois champs qui constituent à eux trois la clé primaire.
C’est pourquoi le soulignement est continu : « x, y, z » veut dire que les trois pro-
priétés forment la clé primaire, tandis que « x, y, z » signifierait plutôt que l’on a
trois clés primaires ;
• les trois champs d’emprunter sont suivis d’un #. En effet, ils répondent bien à la
définition d’une clé étrangère. Ce sera le cas à chaque [n–n] : tous les champs consti-
tuant l’identifiant seront également des clés étrangères (voir acheter dans l’exemple
ci-dessus).
2F. Vérification
On vérifie aisément que la sémantique des données est conservée (on a déjà fait cette
démarche avec les MLD sous forme de tableau). Je vous répète que même dans un SGBD
relationnel, les données sont présentées sous la forme d’un tableau, la machinerie étant
masquée. Le cours ci-dessus vient donc juste de présenter de façon formelle ce que l’on
a fait intuitivement dans la troisième séquence.
Reprenons le deuxième MCD du tableau ci-dessus (association emprunter). Voici un
exemple de contenu des tables (vous remarquerez qu’elles sont sans ordre particulier).
76
8 3932 TG PA 01
Le MLD
Personne Emprunter
NUMERO PERS. NOM ADRESSE VILLE NUMERO PERS. JJMMAAAA ISBN
13 LeChat 8, avenue de la Libération Orléans 8 22/08/2000 2.264.02454.2
8 LeTeckel 13, rue de l’Europe Cergy 13 13/04/2000 2.02.025380.1
9 LeLapin Square Fleuri Clapiers 8 19/05/2000 2.02.025380.1
9 15/10/2000 2.02.025380.1
8 18/11/2000 2.07.036209.4
Livre Date
ISBN TITRE LIVRE DATE ACHAT JJMMAAAA
2.264.02454.2 L’âge difficile 18/04/1999 13/04/2000
2.02.025380.1 American Psycho 07/12/2000 19/05/2000
2.264.01095.9 Moins que zéro 15/04/2000 22/08/2000
2.07.036209.4 Les célibataires 08/12/1999 15/10/2000
18/11/2000
Nous allons vérifier que l’organisation des données est en adéquation avec le monde
réel en cherchant les titres des livres empruntés par M. LeTeckel de Cergy. Comment
faire ? Les emprunts sont stockés dans la table Emprunter (c’est logique puisqu’ils étaient
matérialisés par l’association emprunter du MCD). Mais un coup d’œil au contenu de la
table Emprunter nous rappelle que pour des raisons d’efficacité et de non-redondance,
les occurrences concernées (livre, personne et date) ne sont représentées que par leur
identifiant. On va donc procéder en trois étapes :
1. Dans Personne, on cherche le numéro de M. LeTeckel. C’est le numéro 8.
2. Dans Emprunter, on relève les ISBN des livres empruntés par la personne numéro 8.
Il y a 2.264.02454.2, 2.02.025380.1 et 2.07.036209.4.
3. Dans Livre, on récupère le titre correspondant à chacun des ISBN retenus et on
obtient la réponse : L’âge difficile, American Psycho et Les célibataires.
Cette recherche est illustrée graphiquement dans le schéma suivant :
Personne
NUMÉRO PERS. NOM ADRESSE VILLE
13 LeChat 8, avenue de la Libération Orléans
1re étape 8 LeTeckel 13, rue de l’Europe Cergy
9 LeLapin Square Fleuri Clapiers
Emprunter Livre
NUMÉRO PERS. JJMMAAAA ISBN ISBN TITRE LIVRE DATE ACHAT
8 22/08/2000 2.264.02454.2 2.264.02454.2 L’âge difficile 18/04/1999
13 13/04/2000 2.02.025380.1 2.02.025380.1 American Psycho 07/12/2000
3e étape
2e étape 8 19/05/2000 2.02.025380.1 2.264.01095.9 Moins que zéro 15/04/2000

9 15/10/2000 2.02.025380.1 2.07.036209.4 Les célibataires 08/12/1999
8 18/11/2000 2.07.036209.4
77
8 3932 TG PA 01
Séquence 5
2G. Démarche et exemple

Le tableau précédent vous a prouvé la simplicité de l’obtention du MLD. La difficulté
du passage du MCD vers le MLD est de ne rien oublier. Je vous assure que sur un sujet
volumineux, si vous butinez sans méthode le MCD, vous omettrez des propriétés voire
des associations. Je vous propose la démarche suivante :
1. Vous écrivez toutes les tables issues des entités sans fermer la parenthèse pour
laisser la place aux clés étrangères éventuelles.
2. Pour chaque entité comportant des pattes 0,1 ou 1,1, vous rajoutez les clés étran-
gères correspondantes.
3. Vous fermez toutes les parenthèses.
4. Vous écrivez toutes les tables issues des associations [n–n]å.
Comme les tables sont triées par cette méthode, cela vous permettra de vérifier rapide-
ment votre MLD. Si le MCD est vraiment important, je vous conseille de rayer au crayon
de papier les entités et associations au fur et à mesure pour vous assurer que vous
n’oubliez rien. Ensuite, vous gommez et… ni vu ni connu !
Nous allons appliquer notre méthode sur le cas suivant :
FACTURE
NuméroFacture PRODUIT
TYPE PRODUIT ENTREPÔT
DateFacture NuméroProduit
NuméroTypeProduit NuméroEntrepôt
MontantHT LibelléProduit
LibelléTypeProduit AdrEntrepôt
MontantTTC PrixHT
DatePaiement 0,n 0,n 0,n
0,n 1,1
1,n
comporter être stocker

quantité
Première étape : les entités (sans fermer les parenthèses).

Facture (NuméroFacture, DateFacture, MontantHT, MontantTTC, DatePaiement
Produit (NuméroProduit, LibelléProduit, prixHT
TypeProduit (NuméroTypeProduit, LibelléTypeProduit
Entrepôt (NuméroEntrepôt, AdrEntrepôt
Deuxième étape : les [1–n]. Ici, on n’a que être qui est concernée, d’où la table Produit :
Produit (NuméroProduit, LibelléProduit, prixHT, NuméroTypeProduit#)
Troisième étape : on ferme les parenthèses (non représenté ici, je ne suis pas payé à la
ligne !)
Quatrième étape : les [n–n]
Comporter (NuméroFacture#, NuméroProduit#, quantité)
Stocker (NuméroTypeProduit#, NuméroEntrepôt#)
å Et là, vous pouvez fermer la parenthèse sans problème puisque qu’une [n–n] ne peut contenir de
patte avec une cardinalité maximale de 1 donc ne générera pas de clé étrangère.
78
8 3932 TG PA 01
Le MLD
Au final, on obtient le MLD suivant :

Facture (NuméroFacture, DateFacture, MontantHT, MontantTTC, DatePaiement)
Produit (NuméroProduit, LibelléProduit, PrixHT, NuméroTypeProduit#)
TypeProduit (NuméroTypeProduit, LibelléTypeProduit)
Entrepôt (NuméroEntrepôt, AdrEntrepôt)
Comporter (NuméroFacture#, NuméroProduit#, quantité)
Stocker (NuméroTypeProduit#, NuméroEntrepôt#)
(notations : clé primaire, clé étrangère#)
2H. Quelques cas particuliers

Ce que nous avons vu règle le cas de la majorité des MCD. Il y a cependant cinq points
intéressants sur lesquels nous allons réfléchir.
2H1. Toutes les entités ne sont pas bonnes à prendre

Devinez qui va encore se distinguer ? Eh oui, l’entité Date. Au terme de ce cours, on
pourra vraiment dire que le concept de date, évidemment primordial en informatique
de gestion, augmente sensiblement la difficulté de l’analyse.
Reprenons le MCD suivant :
DATE Nous avions dit que le MLD résultant était :

1,n
PERSONNE JJMMAAAA Personne (NuméroPersonne, Nom, Adresse, Ville)
NuméroPersonne emprunter Date (JJMMAAAA)
0,n
Nom LIVRE
Adresse ISBN
Livre (ISBN, TitreLivre, DateAchat)
0,n
Ville TitreLivre Emprunter (NuméroPersonne#, JJMMAAAA#, ISBN#)
DateAchat
En effet, les trois entités et l’association donnent chacune une table.

Revenons maintenant à l’intérêt du MLD : c’est de décrire les tables permettant de stoc-
ker les données de façon cohérente avec l’organisation mise au jour par le MLD.
La finalité des tables est donc le stockage des données.
Observons maintenant la cardinalité d’emprunter du côté de Date : 1,n. Cela signifie
que toutes les occurrences de Date participent à au moins une occurrence d’emprunter.
Dans la réalité, on dira cela dans l’autre sens : seules les dates où il y a un emprunt sont
stockées dans la base (donc deviennent des occurrences de Date).
Conclusion : Toutes les dates qui se trouvent dans la table Date se trouveront dans
Emprunter.
Date (JJMMAAAA) Emprunter (NuméroPersonne#, JJMMAAAA#, ISBN#)
79
8 3932 TG PA 01
Séquence 5
Graphiquement :
Emprunter Date
NUMÉRO PERS. JJMMAAAA ISBN JJMMAAAA
8 22/08/2000 2.264.02454.2 13/04/2000
13 13/04/2000 2.02.025380.1 19/05/2000
8 19/05/2000 2.02.025380.1 22/08/2000
9 15/10/2000 2.02.025380.1 15/10/2000
8 18/11/2000 2.07.036209.4 18/11/2000
Mais alors, à quoi nous sert Date ? Livre est utile car Emprunter ne contient que l’identi-
fiant ISBN, le reste des informations relatives aux livres se trouvant dans Livre. De même,
seul le numéro de personne se trouve dans Emprunter, le reste des informations sur les
emprunteurs se trouvant dans Personne.
Mais pour Date, rien de tel ! Toutes les informations se trouvant dans Emprunter, on n’a
aucune raison de se référer à Date, qui ne sert alors à rien !
L’entité Date ne sera donc pas traduite dans le MLD, qui se réduira alors aux 3 tables
suivantes :
Personne (NuméroPersonne, Nom, Adresse, Ville)
Livre (ISBN, TitreLivre, DateAchat)
Emprunter (NuméroPersonne#, JJMMAAAA, ISBN#)
(Du coup, JJMMAAAA n’est plus clé étrangère : le # disparaît.)
O laCetable
n’est pas une règle absolue concernant les entités Date. Si, pour diverses raisons,
Date contient des dates précises indépendamment des dates utilisées dans
des occurrences d’association – par exemple la liste des jours ouvrables –, alors on
créera une table Date.
Finalement, une entité ne sera pas transformée en table si les deux conditions sui-
vantes sont réunies :
1. L’entité ne possède qu’un identifiant et aucune propriété.
2. Toutes les occurrences de l’entité sont utilisées par des occurrences d’association.
Généralement, seule l’entité Date (ou Heure ou Année) peut remplir ces conditions.
L’infinie diversité des situations fait qu’il peut arriver qu’une autre entité que celles
mesurant le temps remplisse ces conditions. Mais bon… de ma vie d’informaticien je n’en
ai jamais croisé.
Souvenez-vous de l’exercice sur les prénoms.
Lorsque vous omettez de traduire Date dans le MLD, vous devez le justifier briè-
O vement (il s’agit juste de dire que les occurrences de Date sont redondantes puis-
que reprises dans les associations truc et bidule). Sinon, le correcteur pensera que
vous avez oublié de traiter l’entité Date, le fait qu’elle ne doive pas être conservée
n’étant qu’un coup de chance.
80
8 3932 TG PA 01
Le MLD
2H2. Et les [1–1] ?

Oui, il arrive (rarement, mais bon, cela arrive) d’avoir une association avec les deuxå
cardinalités maximales valant 1.
Exercice 40
On veut informatiser la gestion du paiement des factures dans une entreprise. Une facture est
identifiée par un numéro, un montant à payer, une date de facture et une date limite de paie-
ment. Un paiement est caractérisé par son type (chèque, virement, lettre de change…) et son
numéro éventuel (numéro de chèque ou numéro de virement). On supposera que le règlement
d’une facture se fait en une fois à une date qu’il faut conserver.
Faites le MCD correspondant.
Nous allons voir comment traduire payer dans le MLD. En fait, il y a trois solutions corres-
pondant à l’application de la règle générale des associations [1–n] selon trois points de
vue différents. En effet, on peut considérer que chaque patte joue le rôle du 1 que l’on
avait traité dans les [1–n]. Chaque identifiant devient donc clé étrangère dans la table
issue de l’autre entité. Notons que cette solution apporte de la redondance.
Exercice 41
Faites le MLD du sujet de l’exercice précédent en adoptant ce point de vue (chaque patte
joue le rôle du 1).
On peut aussi considérer que l’une des pattes joue le rôle du 1, l’autre jouant le rôle
du n. Un des identifiants seulement devient donc un champ clé étrangère. Cela donne
deux solutions, selon que l’un ou l’autre identifiant est choisi.
Exercice 42
Faites les deux MLD possibles correspondant à ce point de vue : la patte de Facture joue le
rôle du 1 puis la patte de Règlement joue ce rôle.
Laquelle des trois solutions adopter ? Les trois sont acceptables. Selon le contexte, on
pourra éventuellement dire que l’une ou l’autre est maladroite.
Tout va dépendre des traitements généralement effectués :
• si on recherche habituellement le règlement à partir de la facture, on mettra le
numéro de règlement en clé étrangère ;
• si on recherche plutôt la facture pour un règlement donné, on mettra le numéro de
facture en clé étrangère ;
• si on recherche indifféremment l’un des deux en fonction de l’autre, on mettra les
deux identifiants en clés étrangères, la redondance étant contrebalancée par le gain
d’efficacité ;
å D’après les règles vues précédemment, dès que l’on a une cardinalité maximale de 1, on ne peut
avoir qu’une binaire.
81
8 3932 TG PA 01
Séquence 5
• si le type de traitement à venir n’est pas déterminable, il est de bonne politique de

mettre chaque identifiant en clé étrangère pour être sûr de ne pas faire le mauvais
choix. Si intuitivement, vous savez quel objet sera recherché à partir de l’autre, vous
préciserez explicitement votre supposition puis vous prendrez la clé étrangère cor-
respondante. Attention, si, dans la vraie vie, vous ne connaissez pas les traitements
à venir, c’est que votre analyse n’est pas de bonne qualité ;
• pour mettre un bémol au tiret précédent, on peut également et fort logiquement
privilégier le lien 1,1 plus « complet » que le 0,1 en l’absence d’indication sur le
traitement à venir.
Ici, on n’a aucune idée des traitements qui seront réalisés puisque le sujet n’indique rien.
Cependant, on peut estimer que, le règlement étant une caractéristique de la facture
plutôt que l’inverse, on recherchera généralement le règlement d’une facture donnée.
Nous prendrons donc l’option de mettre NuméroRèglement en clé étrangère dans
Facture.
J’insiste sur le fait que c’est un raisonnement pointu puisque purement opérationnel à
un endroit qui ne l’est pas. Le fait de mettre le numéro de règlement en clé étrangère
n’empêche absolument pas de rechercher la facture d’un règlement donné. Mais ce sera
moins efficace. Dans tous les cas, il n’y a pas de solution erronée.
Dans notre raisonnement, nous n’avons pas pris en compte le fait qu’une cardinalité
minimale valait 0. La cardinalité minimale peut parfois nous aider à trancher (ce n’était
pas le cas ici) :
• si les deux cardinalités minimales sont identiques, ce n’est pas discriminant. Le pro-
blème reste donc entier ;
• si l’une est à 0 (et donc l’autre à 1), tout dépend de la sémantique du 0 :
• s’il signifie que l’occurrence d’association existera, mais plus tard (cas du règlement
d’une facture), le 0 est assimilé au 1. Cela n’aide pas à trancher ;
• en revanche, si le 0 signifie que parfois l’occurrence de l’entité ne participe à aucune
occurrence d’association, il semble naturel de transformer son identifiant en clé
étrangère puisque, a priori, c’est l’autre entité qui est « l’élément fort » toujours
présent du couple.
On retiendra donc :
Pour traduire une association [1–1] dans un MLD, on se rapprochera du 1 dans [1-n]
pour une des pattes ou pour les deux. Le choix se fera en fonction de la sémantique
des données et des traitements à venir.
2H3. Et les [i–n] ?

Oui, dans des cas très encadrés, j’ai admis voire recommandé de mettre une cardinalité
maximale chiffrée (2, 3…), bref ni 1, ni n. Dans ce cas, quel parti prendre ? Considérer
que 3, ce n’est guère plus de 1 ou au contraire estimer qu’un 3 est un n qui s’ignore ?
Bref, appliquer le cas [1–n] et utiliser une clé étrangère ou user du cas général [n–n] et
créer une nouvelle table ?
82
8 3932 TG PA 01
Le MLD
Pour nous décider, envisageons le MCD suivant :
PERSONNE
NuméroPersonne porter PRÉNOM
1,3 rang
0,n Prénom
Nom
Adresse
Ville
Exercice 43
Avant de parler de porter, faites le MLD des deux entités. Vous traiterez très attentivement
le cas de Prénom pour décider s’il relève du cas 2H1.
Pour porter, examinons les deux solutions.
On la considère comme une [1–n]

C’est-à-dire que l’on fait comme si on avait trois fois une [1–n] : on va ajouter trois fois
Prénom en clé étrangère dans la table Personne. D’ailleurs, pour pousser l’analogie, une
[1–n] ne pouvant être porteuse, on perdra en route la propriété rang, d’où le MLD :
Personne (NuméroPersonne, Nom, Adresse, Ville, Prénom1#, Prénom2#, Prénom3#)
Prénom (Prénom)
Cette solution est cohérente puisqu’on a toujours l’information véhiculée par la propriété
rang : pour les raisons classiques d’identification, les champs d’une table doivent avoir des
noms différents ; j’ai donc indicé les champs Prénom par leur rang.
On la considère comme une [n–n]

On créera donc une table porter qui donnera le MLD final :
Prénom (Prénom)
Porter (NuméroPersonne#, Prénom#, rang)
Laquelle des deux solutions allons-nous retenir ? D’un point de vue théorique, les deux sont
parfaitement équivalentes et correctes. Dans une copie, les deux solutions seront acceptées.
D’un point de vue opérationnel, la seconde solution est préférable car, bien qu’elle
rajoute une table, elle accélère les traitements : il est plus rapide de rechercher des
informations dans deux petites tables (Personne et Porter) que dans une seule grosse
(Personne avec les clés étrangères).
Bien entendu, le choix entre les deux solutions n’aura lieu qu’avec une cardinalité maxi-
male de 2 ou 3 au plus : si l’on avait une cardinalité 1,20, on ne mettrait pas 20 clés
étrangères !
On retiendra donc :
Pour traduire une association [i–n] dans un MLD, on pourra appliquer le cas [1–n]
(i petit) ou [n–n] (i grand).
83
8 3932 TG PA 01
Séquence 5
2H4. Et les réflexives ?

Revenons à nos mariages (exercice 29).
PERSONNE
NumeroP 0,n époux
NomP épouser
PrénomP épouse
SexeP 0,n
DateNaissanceP
AdrP
CodeP
VilleP
Le raisonnement que l’on a toujours utilisé avec les réflexives était de dire que, fina-
lement, c’étaient des associations binaires normales, sauf que les deux entités reliées
étaient… les mêmes, ce qui reste un détail.
Exercice 44
Faites le MLD du MCD précédent en gardant à l’esprit qu’il faut traiter la réflexive comme
une association normale.
Exercice 45
Décrivez précisément le réel modélisé par le MCD suivant qui représente les liens hiérarchi-
ques dans une entreprise, puis faites le MLD.
SALARIÉ
0,n dirige
NumeroS
NomS diriger
PrénomS est dirigé
AdrS
0,1
VilleS
On retiendra donc :
Pour traduire une association réflexive dans le MLD, on utilisera les règles classi-
ques, à ceci près que l’on renommera souvent l’identifiant pour en faire un nom de
champ intelligible.
84
8 3932 TG PA 01
Le MLD
2H5. Et les entités faibles ?

La notion d’entité faible est perdue dans le MLD. Le passage se fait donc très simple-
ment !
Étudions ce MCD (vu dans la séquence 4, 3A) :
HÔTEL
CHAMBRE
NumeroHôtel
#NuméroHôtel#
NomHôtel
1,n contenir 1,1 NuméroChambre
NbrChambres
Étage
AdrHôtel
NbrPersonnes
CodeHôtel
Cabinet
VilleHôtel
Imaginons que l’on ne soit pas confronté à une entité faible. Que ferait-on face à ce MCD
sans entité faible donc avec une association [1–n] classique ? On créerait deux tables
Hôtel et Chambre et l’identifiant d’Hôtel serait rajouté en clé étrangère dans Chambre.
Or, ici, c’est déjà fait par le principe même de l’entité faible puisque NuméroHôtel est
une propriété de Chambre.
Ainsi, le MLD va consister à créer une table pour chaque entité sans se poser de question
particulière. L’association est purement et simplement mise de côté. Cela donne :
Hôtel (NuméroHôtel, NomHôtel, NbrChambres, AdrHôtel, CodeHôtel, VilleHôtel)
Chambre (NuméroHôtel#, NuméroChambre, Étage, NbrPersonnes, Cabinet).
Notez que le champ NuméroHôtel dans Chambre est souligné et suivi de #. En effet, il
est clé primaire dans Chambre (donc souligné), mais il est aussi clé étrangère puisqu’on
le retrouve en clé primaire dans Hôtel. On lui greffe donc un #.
J’insiste : ne tenez pas compte de l’association contenir, sinon vous auriez deux fois
NuméroHôtel dans la table Chambre.
Il faut bien comprendre que cette règle de passage dépend du formalisme utilisé.
Rappelez-vous l’autre formalisme que l’on trouve dans la littérature avec les cardinalités
du côté de l’entité faible entre parenthèses :
HÔTEL
CHAMBRE
NuméroHôtel
NuméroChambre
NomHôtel
1,n contenir (1,1) Étage
NbrChambres
NbrPersonnes
AdrHôtel
Cabinet
CodeHôtel
VilleHôtel
Pour passer au MLD avec ce formalisme, on dira que les deux entités deviennent des
tables et que l’identifiant d’Hôtel formera avec NuméroChambre l’identifiant de
Chambre. Bien entendu, le MLD obtenu reste le même !
85
8 3932 TG PA 01
Séquence 5
On retiendra donc :
Pour traduire une entité faible dans le MLD, on se contente de traduire les deux entités
sans se soucier de l’association (dans le cas du formalisme # utilisé dans le cours).
3. Conclusion (brève !)
Si l’on enlève le blabla d’introduction et les cas particuliers longuement discutés, le MLD
se résume à une demi-page de règles : les entités et les associations [n–n] deviennent des
tables, les [1-n] donnent naissances aux clés étrangères.
Il est donc dommage de perdre des points sur une question qui vous les offre ! Notons
que dans un sujet d’examen, vous aurez généralement un MCD à concevoir puis à tra-
duire en MLD. Il est bien évident que vous serez noté sur votre capacité à traduire votre
MCD en MLD, donc à utiliser les règles de passage de l’un à l’autre. Ainsi, même si votre
MCD est complètement faux, vous pouvez avoir tous les points pour le MLD. D’où une
petite supplique de prof : faites le MCD et le MLD sur deux feuilles différentes que l’on
puisse les mettre côte à côte : vous gagnerez beaucoup de temps pour écrire le MLD, et
nous, à le corriger !
Vous pouvez dès à présent commencer le cours Access (réf. 3932 TG PA 02) et le cours
SQL, (réf. 3999 TG PA 02).
86
8 3932 TG PA 01
Synthèse
Définition du MLD
Le MLD se dérive du MCD. Alors que le MCD présente la connexion des données
entre elles de façon théorique (conceptuelle), l’objet du MLD est d’indiquer com-
ment ces données vont être stockées dans le système informatique pour conser-
ver l’interconnexion établie dans le MCD.
Vocabulaire MCD Vocabulaire MLD et SGBD

identifiant clé primaire
propriété champ
Une clé étrangère est un champ d’une table qui est clé primaire dans une autre
table.
Notations
Notion Notation Exemple
identifiant souligné NuméroClient
clé étrangère # en fin de mot NuméroProduit#
Passage MCD " MLD

Partant du MCD, on va obtenir le MLD en appliquant les règles de passage sui-
vantes :
1. Toute entité devient une table du même nom (identifiant et propriétés
devenant respectivement clé primaire et champs).
2. Toute association [n–n] devient une table du même nom (identifiant de
l’association et propriétés éventuelles devenant respectivement clé primaire
et champs).
3. Pour toute association [1–n], l’identifiant de l’entité du côté n devient un
champ (appelé clé étrangère) dans la table issue de l’entité du côté 1.
Cas particuliers
Une entité ne sera pas transformée en table si les deux conditions suivantes sont
réunies :
1. L’entité ne possède qu’un identifiant et aucune propriété.
2. Toutes les occurrences de l’entité sont utilisées par des occurrences d’as-
sociation. L’expérience montre que généralement seule l’entité Date (ou
Heure ou Année) peut remplir ces conditions.
Pour traduire une association [1–1] dans un MLD, on se rapprochera du cas
[1–n] pour une des pattes ou pour les deux. Le choix se fera en fonction de la
sémantique des données et des traitements à venir.
Pour traduire une association [i–n] dans un MLD, on pourra appliquer le cas
[1–n] (i petit) ou [n–n] (i grand).
87
8 3932 TG PA 01
Séquence 5
Méthodologie de construction
Elle tient en quatre étapes :
1. Vous écrivez toutes les tables issues des entités sans fermer la parenthèse
pour laisser la place aux clés étrangères éventuelles.
2. Pour chaque entité comportant des pattes 0,1 ou 1,1, vous rajoutez les clés
étrangères correspondantes.
3. Vous fermez toutes les parenthèses.
4. Vous écrivez toutes les tables issues des associations [n–n].
88
8 3932 TG PA 01
Séquence 6
Règles de validation du MCD
Nous sommes arrivés au milieu du cours. Vous pourriez vous en tenir là et avoir
des bases raisonnables. Mais, bien entendu, il vous manquerait l’aisance et l'en-
traînement que vous apporteront les séquences suivantes. Cette nouvelle séquen-
ce a pour objet la vérification de la correction des MCD. On va donc se situer à un
niveau moins terre à terre !
• Savoir vérifier son MCD pour éviter les fautes de logique.
u Contenu
1. Revenons sur l’identifiant ............................................................... 90
2. Revenons sur les associations ........................................................ 90
3. Entité ou association ......................................................................... 92
4. Règles de validation ............................................................................ 93
4A. Introduction en forme de sermon .............................................................. 93
4B. Les règles ................................................................................................... 94
Synthèse
89
8 3932 TG PA 01
Séquence 6
1. Revenons sur l’identifiant

Il est tentant d’utiliser le numéro de Sécurité Sociale pour identifier les personnes. Mais,
justement, c’est un identifiant tellement parfait que son emploi est sévèrement contrôlé
par la loi (Loi Informatique et Libertés de 1978 dont la CNIL est chargée de veiller à sa
bonne application).
Vous ne pouvez utiliser ce numéro que pour des applications liées à la Sécurité sociale
ou à la paie. Il conviendra alors de l’employer comme attribut simple et non comme
identifiant.
Un identifiant doit avoir une valeur stable dans le temps. Vous éviterez donc de prendre
un numéro de téléphone car, même s’il identifie de façon unique, il peut changer (démé-
nagement…). Ainsi, un numéro de téléphone correspond toujours à une seule personne
(enfin, famille) à un moment donné, mais cette famille peut ne plus être la même si le
numéro est réaffecté suite à un déménagement.
Notons que dans le cas très particulier de l’informatisation d’un opérateur téléphonique,
l’identifiant du client est bel et bien le numéro de téléphone ! En effet, le client est le
titulaire de la ligne.
Finalement, 9 fois sur 10, vous utiliserez un identifiant artificiel. C’est un cas tellement
répandu que les SGBD fournissent souvent un type spécial (NuméroAuto sous Access) qui
est un compteur numérotant automatiquement les nouvelles occurrences.
2. Revenons sur les associations

Je vous ai déjà dit que moins une association avait de pattes, mieux c’était. Il faut donc tou-
jours vérifier qu’une association quaternaire ne peut pas être simplifiée en deux ternaires
sans perte d’information et qu’une ternaire ne peut pas se simplifier en deux binaires.
Étudions le MCD suivant, qui contient plusieurs erreurs :
CLIENT livrer COMMANDE contenir PRODUIT

NuméroClient 0,n DateLivraison 1,1 NuméroCommande quantité 0,n NuméroProduit
1,n
NomClient DateCommande DescriptifProduit
PrénomClient 0,n MontantCommande PrixUnitaireProduit
AdrClient
ENTREPÔT
NuméroEntrepôt
AdrEntrepôt
TelEntrepôt
Rien à dire concernant l’association contenir. Elle n’est là que pour augmenter un peu la
taille du MCD. Ce qui m’intéresse, c’est livrer. A priori, tout va bien : elle traduit fidèle-
ment les contraintes du réel suivantes :
• une commande est passée par un client unique ;
• une commande est livrée en une fois à une date de livraison, depuis un seul entrepôt.
90
8 3932 TG PA 01
Exercice 46
L’emplacement de la propriété DateLivraison me pose problème. Qu’en pensez-vous ?
Continuons. Nous en sommes au MCD suivant :
CLIENT livrer COMMANDE contenir PRODUIT

NuméroClient 0,n DateLivraison 1,1 NuméroCommande quantité 0,n NuméroProduit
1,n
NomClient DateCommande DescriptifProduit
PrénomClient 0,n MontantCommande PrixUnitaireProduit
AdrClient
ENTREPÔT
NuméroEntrepôt
AdrEntrepôt
TelEntrepôt
Est-il parfait ? Toujours pas. On vient juste de réviser en passant la notion « une 1,1 ne peut
être porteuse de données ». L’exercice reste entier. Et c’est toujours livrer qui me déplaît.
Étudions les cardinalités de livrer.
Sur Commande : 1,1 signifie qu’une commande ne concerne qu’un client et un entrepôt.
Sur Entrepôt : 0,n signifie qu’un entrepôt livre plusieurs commandes et donc clients
sans plus de précision.
Sur Client : 0,n signifie qu’un client pourra se faire livrer plusieurs commandes
(éventuellement 0, je suppose donc qu’une personne ayant juste
demandé des informations sans pour autant passer commande est un
client… cela est sans importance).
Tout ceci est-il correct ? Oui. Tout ceci est-il satisfaisant ? Non !
L’association relie les trois entités, donc les relie sémantiquement. Or, intuitivement, le
fait qu’un client passe une commande est une chose, le fait que la commande soit livrée
est autre chose.
Ensuite, la cardinalité 1,1 de Commande indique deux choses distinctes et sans rapport
entre elles :
• premier point, une commande correspond à (est passée par) un client et un seul ;
• deuxième point, une commande correspond à (est livrée par) un et un seul entrepôt.
Ces deux liens peuvent se modéliser séparément. Et donc on va le faire, en transformant
la ternaire livrer en deux binaires commander et livrer.
Exercice 47
Eh bien, allez-y, transformez la ternaire livrer en deux binaires commander et livrer, en pre-
nant soin de relier les bonnes entités et de veiller aux cardinalités.
De cette partie, on retiendra la règle suivante :

Règle : une association possédant une patte 0,1 ou 1,1 ne peut être qu’une binaire
non porteuse de données.
(Le fait que cette association ne soit pas porteuse a déjà été vu.)
91
8 3932 TG PA 01
Séquence 6
3. Entité ou association
Il n’est pas vraiment utile de revenir sur ce point car on l’a abordé plusieurs fois dans les
exercices. J’ai pourtant envie de pratiquer la redondance pour être sûr que vous preniez
conscience du problème. Je serai brefå.
Il en est de même des choix de représentation des objets réels (par une entité ou une
association) que des cardinalités :
• parfois, on n’hésite pas : un client ne peut être qu’une entité. Un lien d’apparte-
nance entre un produit et un type de produit sera une association ;
• parfois, les deux sont possibles, un concept pouvant être valablement représenté par
une association ou une entité. Nous l’avons vécu avec l’inscription et le mariage.
Le drame est que, lorsque l’on se pose la question de l’entité ou de l’association, le choix
est véritablement cornélien. Les quelques indices rappelés ci-dessous vous permettront
de choisir plus sereinement.
Avant de commencer : un constat. Le problème se pose toujours dans le sens association vers
entité : on fait une association, on lui rajoute des pattes, des propriétés, on n’est pas satisfait
du résultat, on hésite et alors on se dit « et si je faisais une entité ? », mais on n’ose pas.
Voici les arguments en faveur d’une entité :
– plus l’association possède de pattes, plus cela milite pour une entité fortement
ancrée dans le MCD, chaque patte devenant une association ou une propriété
liée à cette entité ;
– plus l’association possède de propriétés, plus on est fondé à créer une entité
pour y mettre ces propriétés ;
– plus l’objet réel concerné a d’importance dans le système d’information, plus on
sera amené à le promouvoir en entité (être une entité, cela se mérite).
Je reprends le dernier tiret :
– si l’on souhaite modéliser les emprunts dans une bibliothèque, il est assez naturel
de faire une entité Emprunt car ce concept est l’élément clé auquel tout se rapporte
(nombre de livres empruntés, emprunteur, dates d’emprunt et de retour…) ;
– si je modélise une petite bibliothèque d’école primaire, je souhaite juste savoir qui a
emprunté quoi pour pouvoir le récupérer en fin d’année. Une association emprun-
ter entre Exemplaire et Lecteur porteuse de la date de retour me suffira ;
– en revanche, si nous voulons modéliser le fonds documentaire (livres, thèmes,
auteurs, éditeurs…) pour améliorer sa qualité, on mettra au mieux une propriété
booléenne Emprunté dans l’entité Exemplaire. Cela nous permettra accessoirement
d’éditer en fin d’année la liste des livres qui ne sont pas empruntés et donc qui doi-
vent être en rayon pour réaliser l’inventaire.
Vous voyez l’astuce ? Dans les trois cas, nous gérons les emprunts, mais de façon de plus
en plus périphérique. Cette notion passe de centre de la modélisation (cas gestion des
emprunts) à information tout à fait annexe (cas gestion du fond).
Il est donc raisonnable de traiter chaque concept selon son importance. Dans la réalité,
c’est ce qui se passe : dans mon BTS, nous avons une armoire de livres et de revues pour
les 60 étudiants de la formation. Quand ils prennent un livre, ils l’écrivent sur un cahier
å Si, si, promis ! Et je n’abuserai pas de la note de bas de page.
92
8 3932 TG PA 01
et le rayent quand ils le rendent. Dans le CDI du lycée (10 000 ouvrages, 1 600 élèves), la
gestion des emprunts est évidemment informatisée, chaque élève doit s’inscrire…
Bien entendu, ces considérations ne sont qu’une aide méthodologique, vous devez déve-
lopper votre intuition puis vous y fier.
4. Règles de validation
4A. Introduction en forme de sermon

Ce qui suit est une partie cruciale du cours. Il faut absolument l’apprendre. En analyse, comme
en programmation, en SQL, en peinture, en sport…, il y a deux aspects à développer :
– l’intuition et le potentiel, qui sont des capacités propres à chacun. C’est ce qui fait
qu’à entraînement égal, un sprinter descendra sous 11 secondes aux 100 mètres
et un autre sous 10,5 secondes. De même, un informaticien trouvera une solution
efficace pour modéliser un problème particulièrement complexe, tandis qu’un autre
échouera ;
– le respect des règles, qui ne peut s’acquérir que par leur apprentissage. C’est sans
doute l’aspect le moins enthousiasmant de toute formation, mais c’est absolument
nécessaire. Imaginez-vous au football, vexé de ne pas réussir à mettre un but, pren-
dre le ballon à pleines mains, mettre un coup de boule au gardien qui proteste
puis déposer « victorieusement » le ballon au fond du but adverse. Est-ce correct ?
Non. Le but sera-t-il accepté ? Non. En informatique (et partout ailleurs), il existe
des règles. Il n’y a pas de mystère. Si vous les apprenez (et bien entendu si vous les
appliquez), vous réussissez. Si vous ne les apprenez pas, vous échouez.
Notez que ces règles ne sont pas tombées du ciel pour vous nuire. En effet, si l’on vous dit
en algorithmique que l’on ne doit pas écrire « 5 ≤ x ≤ 10 » mais « 5 ≤ x et x ≤ 10 »å, ce
n’est pas pour vous ennuyer ou pour vous punir. C’est à cause des règles grammaticales
des langages.
De même, je n’ai pas décidé par recherche esthétique d’interdire qu’une association de
cardinalité 1,1 soit porteuse de données. Cela vient de la nature même de l’association.
La rendre porteuse conduit à violer une règle, certes, mais surtout montre que vous
n’avez pas compris ce que signifiait le fait d’être porteuse.
Les règles ne sont que le reflet du cours, résumé dans ses points cruciaux. Assimiler les
règles vous permet de comprendre la philosophie, l’esprit de ce que vous faites. Cela,
c’est le cas idéal. Dans le pire des cas, il vous reste à considérer ces règles comme un
dogme à appliquer mécaniquement sans chercher à les comprendre. C’est dommage,
intellectuellement, mais c’est mieux que de ne pas les appliquer du tout !
Bon, nous avons déjà passé un certain temps ensemble, je vais donc vous parler franche-
ment, sans langue de bois. Si j’accepte avec bienveillance une erreur de raisonnement
(il arrive à tout le monde d’en faire, moi compris), je prends extrêmement mal toute
erreur venant d’un non respect des règles de base puisqu’elle témoigne simplement d’un
apprentissage laxiste, bref pas sérieux.
Après ce « sermon », j’ai confiance en votre volonté d’apprendre très méticuleusement
les règles suivantes !
å Et encore ! Le caractère « ≤ » n’existe pas, il faut utiliser « <= ». Mais là, on ne viole aucu-
ne règle grammaticale.
93
8 3932 TG PA 01
Séquence 6
4B. Les règles

Pour une meilleure lisibilité, les règles de validation sont présentées par thème. Ne vous
affolez pas de leur nombre, elles s’apprennent facilement puisqu’elles ne sont finale-
ment que des résumés des différents concepts du cours.
Principe de vérification du MCD
À chaque étape importante du MCD, et en fin de réalisation, vérifiez systémati-
quement que les règles suivantes sont respectées. Si ce n’est pas le cas, vous savez
que votre MCD est erroné. Si elles sont respectées, cela ne veut pas dire que le MCD
représente correctement la réalité, mais vous savez au moins qu’il est syntaxique-
ment correct… et c’est déjà pas mal.
J’insiste une dernière fois sur l’importance de ce check list du MCD. Je suis le premier à
m’astreindre utilement à cette vérification car il y a des règles qui, bien qu’évidentes à
froid, se révèlent vite des carcans que l’on a envie de rompre pour modéliser, astucieuse-
ment croit-on (mais on se trompe), un morceau de réel particulièrement ardu.
4B1. Propriétés
Une propriété ne peut apparaître qu’une fois dans le MCD.
En effet, une propriété est un concept unique du monde réel qu’il est illogique de matéria-
liser plusieurs fois. Une propriété dédoublée marque souvent l’oubli d’une association.
Le dédoublement dont je parle peut être discret : vous ne pouvez bien sûr pas
O utiliser deux fois le même nom, mais vous ne pouvez pas non plus faire référence
au même concept (à la même « chose ») par deux propriétés, même si elles ont un
nom différent.
Exercice 48
Corrigez-moi vite cet horrible MCD ne respectant pas la règle précédente !
ÉTUDIANT FACULTÉ FORMATION

NuméroÉtudiant NuméroFaculté NuméroFormation
s'inscrire 1,n proposer
Nom 0,n NomFaculté 1,1 LibelléFormation
1,1
Prénom AdrFaculté Durée
NuméroFormationSuivie
Bien entendu, on se dépêche de s’accorder des dérogations : les dates et les adresses (villes)
sont employées tellement fréquemment qu’on s’autorise à en mettre dans chaque entité
ou association si nécessaire pour éviter de multiplier artificiellement les associations.
94
8 3932 TG PA 01
Le MCD suivant est correct d’après la règle ci-dessus, mais beaucoup trop lourd. En pra-
tique, si l’on appliquait cette règle pour les dates, les trois quarts des entités seraient
reliées à Date !
signer
CONTRAT 1,1 0,n DATE
NuméroContrat JJMMAAAA
1,1 prendre effet 0,n
TypeContrat
NatureContrat 0,n
1,1
payer
On lui préférera donc la version suivante :

CONTRAT
NuméroContrat
TypeContrat
NatureContrat
DateSignature
DateEffet
DatePaiement
En fait, le seul cas où l’on « sort » la date pour en faire une des pattes de l’association est
lorsque l’on veut historiser le concept réel sous-jacent. En effet, la date doit alors faire
partie de l’identifiant de l’association (revoir l’exercice 30).
Une propriété doit être monovaluée et élémentaire vis-à-vis du système d’information
étudié.
Élémentaire signifie qu’elle ne peut pas être décomposée en données pertinentes pour
le système d’information, monovaluée signifie qu’elle ne possède qu’une seule valeur ;
une propriété ne peut pas être un tableau de valeurs par exemple.
Exercice 49
Nous gérons l’état civil dans une mairie et voulons absolument stocker les trois prénoms des
gens dans l’ordre. Que penser de la solution suivante (prénoms vaudra par exemple ; « André
Paul Martin » si ce sont les trois prénoms de M. Durand) ? De plus, la propriété ville contient le
code postal et la ville. Cela est-il grave ?
Corrigez le MCD pour régler le problème des prénoms (il y a deux solutions possibles).
PERSONNE
NuméroPersonne
Nom
Prénoms
Adresse
Ville
95
8 3932 TG PA 01
Séquence 6
On retiendra :
Un identifiant a obligatoirement une valeur stable, unique et non nulle ; les autres
propriétés ont une valeur facultative.
Vu le rôle particulier de l’identifiant (identifier une occurrence), il doit avoir une valeur
(unique) pour chaque occurrence et cette valeur ne doit pas pouvoir changer. Un numéro
de téléphone, bien qu’identifiant un abonné, n’est pas assez stable pour servir d’identi-
fiant… sauf chez un opérateur téléphonique !
En revanche, les autres propriétés peuvent ne pas avoir de valeur, soit parce que le
moment n’est pas venu, soit parce que la nature de l’occurrence l’interdit : observons les
trois MCD suivants :
PERSONNE Dans l’entité Personne, la propriété NomJeuneFille ne sera rensei-

NuméroPersonne gnée (n’aura de valeur) que si l’occurence de la personne est une
Nom femme. Un homme n’attribuera pas de valeur à la propriété.
NomJeuneFille
Prénom
Adr
Code
Ville
Cas suivant :
ÉTUDIANT COURS
NuméroÉtudiant s'inscrire 0,n NuméroCours
Nom
1,n note
Libellé
Prénom
L’inscription est validée (donc l’occurrence de s’inscrire est créée) dès le début de l’année,
mais la note finale de l’étudiant n’est connue qu’en fin d’année.
Dernier exemple :
RÉPARATION VÉHICULE
NuméroRéparation effectuer 0,n NuméroVéhicule
1,1
Description DateVente
HeureDébut DateImmat
HeureFin ÉtatGénéral
Avant toute intervention, on rentrera dans la base les réparations demandées par le client
pour que les mécaniciens sachent ce qu’ils doivent faire. On ne pourra mettre l’heure de
début qu’au commencement de chaque réparation et l’heure de fin qu’à la fin. Les diffé-
rentes propriétés des occurrences de Réparation seront donc renseignées en trois fois.
4B2. Entités
Une entité n’ayant pas d’occurrence est une erreur. Une entité n’ayant qu’une ou
deux occurrences est très suspecte.
Si vous créez de telles entités, il y a très certainement une erreur d’analyse. Vérifiez donc
très soigneusement votre MCD.
96
8 3932 TG PA 01
Une entité n’ayant qu’une propriété (par force l’identifiant) doit être considérée d’un
œil attentif.
Hormis les entités Date qui n’ont classiquement qu’une propriété, toute autre entité de
cet acabit doit être justifiée par une contrainte très précise du réel étudié (voir l’exercice
42 ci-dessus).
Bien entendu, ne croyez pas valablement régler le problème en ajoutant un identifiant
artificiel doublant le nombre de propriétés (qui passe de 1 à 2).
4B3. Associations
Une occurrence d’association doit être définie sur toutes les entités reliées par l’as-
sociation.
Moins pompeusement : les pattes des associations ne sont pas facultatives. Par exemple,
une ternaire ne pourra pas avoir d’occurrence avec seulement deux entités.
Étudions le cas d’un restaurateur dont le concept est de proposer des dizaines d’entrées,
de plats et de desserts, le client devant faire son choix pour créer son propre menu à 3
plats (une entrée, un plat principal et un dessert). L’originalité est que le prix du menu
varie notamment en fonction des calories des différents plats (ce n’est donc pas une
donnée calculée, il faut la faire figurer dans le MCD).
Voici le MCD que vous proposez :
ENTRÉE DESSERT
NuméroEntrée coûter 1,n NuméroDessert
DescriptionEntrée
1,n montant
DescriptionDessert
CaloriesEntrée CaloriesDessert
1,n
PLAT PRINCIPAL
NuméroPlatPrincipal
DescriptionPlat
CaloriesPlat
Le restaurateur, que vos questions d’analyste ont fait réfléchir, vous dit « finalement,
pour le midi, je voudrais proposer une formule rapide à deux plats (une entrée et un plat
principal) basée sur le même modèle de prix variable. Le client aurait donc le choix entre
deux formules : entrée et plat ou entrée, plat et dessert »
Exercice 50
Cela change-t-il quelque chose à votre modèle ? Si oui, modifiez-le en conséquence.
Deux occurrences d’une association ne peuvent pas être définies sur les mêmes
occurrences d’entité.
O X,NeYpaset lire de travers cette phrase : si une association est définie sur les trois entités
Z, chaque occurrence de l’association sera définie sur des occurrences de X,
Y et Z. Mais il ne faut pas que ces occurrences soient les mêmes.
97
8 3932 TG PA 01
Séquence 6
Prenez l’association coûter du restaurateur (ci-dessus). On ne peut définir qu’une occur-

rence de coûter sur le menu « terrine de lapin, ragoût de lapine, crêpe de lapereau ». En
revanche, on peut définir une autre occurrence « terrine de lapin, ragoût de lapine, glace
au lapereau ». La contrainte est donc que les trois occurrences d’entité ne peuvent être
à la fois les mêmes. Et cela vient du fait que la concaténation des identifiants des entités
forme l’identifiant de l’association. Or, la valeur de l’identifiant est unique.
Pour historiser une association porteuse d’une date, on rajoute une patte que l’on
relie à une entité Date et on enlève la propriété date portée.
Considérons le MCD suivant :

ENSEIGNANT
NumenEns
NomEns
MATIÈRE
PrénomEns
NuméroMatière enseigner 1,n
1,n AdrEns
LibelléMatière année
CodeEns
Niveau
VilleEns
DateConc
Dans ce schéma, soit un professeur ne peut pas enseigner la même matière plus d’une
fois, soit je ne peux stocker que la dernière année où le professeur l’a enseignée. En
effet, un enseignant et une matière déterminent une seule occurrence d’enseigner donc
une seule valeur pour année.
Si je veux historiser et autoriser qu’un professeur enseigne la même matière plusieurs
années, je rajoute une entité Année à l’association, ce qui donne le MCD suivant.
ENSEIGNANT
NumenEns
NomEns
MATIÈRE
PrénomEns
NuméroMatière enseigner 1,n
1,n AdrEns
LibelléMatière
CodeEns
Niveau
1,n VilleEns
ANNÉE DateConc
AAAA
Une association ayant une cardinalité maximale à 1 ne peut être qu’une binaire non
porteuse de données.
Dès qu’une patte possède une cardinalité 0,1 ou 1,1, la donnée que vous avez envie de
rendre portée doit être intégrée à l’entité de cette patte. Si votre association est plus
qu’une binaire, vous l’éclaterez en binaires basées sur cette entité (voir le paragraphe 2
de cette séquence).
98
8 3932 TG PA 01
4B4. Cardinalités
Certaines cardinalités minimales sont discutables (donc toute réponse est accepta-
ble), d’autres ne sont pas négociables.
À l’examen, les points seront attribués sur les cardinalités où il n’y a qu’une réponse
possible. Ne mettez donc pas les cardinalités trop mécaniquement.
Lorsqu’une entité est reliée à plusieurs associations, les cardinalités minimales sont
souvent 0.
Le piège classique se pose avec l’entité Date ; regardons les deux extraits de MCD sui-
vants :
DATE acheter DATE louer

1,n 1,n
JJMMAAAA JJMMAAAA
Les cardinalités 1,n sont correctes puisque dans les deux cas, toutes les dates du calen-
drier ne seront pas des occurrences de Date, mais seulement celles où un achat (pour le
premier MCD) ou une location (pour le second) a lieu.
Si ces deux extraits de MCD correspondent au même système d’information, on ne peut
accepter la redondance des entités Date. Il faut donc réunir les deux associations sur une
seule entité. Les cardinalités deviennent alors automatiquement 0,n puisqu’une date d’achat
ne correspond pas forcément à une date de location et inversement. Ce qui donne :
louer
DATE 0,n
JJMMAAAA acheter
0,n
Voilà ! À bientôt dans la séquence suivante.

Vérifiez bien vos MCD !
99
8 3932 TG PA 01
Synthèse
Pour représenter un concept, on peut hésiter entre une entité ou une association.
Voici les arguments en faveur d’une entité :
– plus l’association possède de pattes, plus cela milite pour une entité forte-
ment ancrée dans le MCD, chaque patte devenant une association ou une
propriété liée à cette entité ;
– plus l’association possède de propriétés, plus on est fondé à créer une entité
pour y mettre ces propriétés ;
– plus l’objet réel concerné a d’importance dans le système d’information, plus
on sera amené à le promouvoir en entité (être une entité, cela se mérite).
Je reprends ici les différentes règles de validation du MCD de façon condensée.

Bien entendu, vous devez les vérifier à la fin de votre MCD :
1. Une propriété ne peut apparaître qu’une fois dans le MCD.
2. Une propriété doit être élémentaire vis-à-vis du système d’information étudié
et monovaluée.
3. Un identifiant a obligatoirement une valeur stable, unique et non nulle ; les
autres propriétés ont une valeur facultative.
4. Une entité n’ayant pas d’occurrence est une erreur. Une entité n’ayant qu’une
ou deux occurrences est très suspecte.
5. Une entité n’ayant qu’une propriété (par force l’identifiant) doit être considé-
rée d’un œil attentif.
6. Une occurrence d’association doit être définie sur toutes les entités reliées par
l’association.
7. Deux occurrences d’une association ne peuvent pas être définies sur les mêmes
occurrences d’entité.
8. Pour historiser une association porteuse d’une date, on rajoute une patte que
l’on relie à une entité Date et on enlève la propriété date portée.
9. Une association ayant une cardinalité maximale à 1 ne peut être qu’une binai-
re non porteuse de données.
10. Certaines cardinalités minimales sont discutables (donc toute réponse est
acceptable), d’autres ne sont pas négociables.
11. Lorsqu’une entité est reliée à plusieurs associations, les cardinalités minimales
sont souvent 0.
101
8 3932 TG PA 01
Travaux dirigés 2
Même conseil que pour le premier TD : il s’agit ici de mettre en pratique les
différents concepts du cours. Ainsi, si vous ne connaissez pas votre cours, ces
exercices ne vous serviront à rien. Ne vous étonnez pas si vous retrouvez ici
les réflexives, les entités faibles et les associations porteuses !
Exercice 1
Le CNED souhaite informatiser son activité. Une analyse détaillée de l’organisation actuelle
fait apparaître que le CNED propose des inscriptions à des formations décrites comme suit :
Une formation possède un titre (par exemple 1re année BTS Informatique de Gestion), un
niveau initial requis (par exemple le bac) et une durée en mois. La formation est composée
de modules (cours). Par exemple, la formation 1re année BTS Informatique de Gestion com-
prend les modules français, anglais, économie, ALSI, AMSI…
Un module possède un titre, un nombre de devoirs, une durée approximative en heures et un
coefficient vis-à-vis de la formation. Il est important de noter qu’un module n’appartient qu’à
une formation. En effet, les programmes n’étant pas les mêmes, le module de français de la
première année de BTS n’est pas le même que celui de la formation CAPES lettres modernes.
Travail à faire
Faites le MCD modélisant les formations.
Exercice 2
Continuons l’exercice précédent. Un étudiant (nom, prénom, adresse) s’inscrit à des forma-
tions. Il peut arriver qu’un étudiant suive plusieurs formations. Pour chacune d’elles, l’étu-
diant aura une moyenne.
Travail à faire
Complétez le MCD pour prendre en compte ces nouveaux éléments.
Exercice 3
Nous voulons gérer un tournoi de football. Une équipe est décrite par son nom, sa ville d’ori-
gine et son niveau (amateur ou professionnel). Un match est constitué par la rencontre de deux
équipes. Il se déroule à une date et une heure données. On doit conserver le score de chaque
match ainsi que l’endroit où il a eu lieu. Nous allons envisager successivement trois cas :
• deux équipes ne peuvent se rencontrer plus d’une fois ;
• deux équipes se rencontrent une fois et une seule ;
• deux équipes peuvent se rencontrer plusieurs fois.
103
8 3932 TG PA 01
Séquence 6
Travail à faire
1. Faites le MCD modélisant le tournoi dans le premier cas (deux équipes ne peuvent se
rencontrer plus d’une fois).
2. Faites le MCD modélisant le tournoi dans le deuxième cas (deux équipes se rencontrent
une fois et une seule).
3. Faites le MCD modélisant le tournoi dans le troisième cas (deux équipes peuvent se ren-
contrer plusieurs fois).
Exercice 4
Nous informatisons maintenant l’organisation d’un tournoi de judo. Le tournoi se déroule
sur deux jours sous forme de tours éliminatoires jusqu’à la finale. Comme dans les premiers
tours il y a des repêchages, les judokas peuvent se rencontrer plusieurs fois au cours du tour-
noi. Avant chaque match, un tirage au sort détermine qui portera le kimono blanc ; l’autre
adversaire portera un kimono bleu. Le score est indiqué en donnant d’abord celui du judoka
en blanc. Un judoka possède un numéro de licence, un nom, un prénom et un club d’affi-
liation. Un combat est programmé entre deux judokas à un moment (jour et heure) précis.
Pour pouvoir éditer les résultats, il faut savoir à quel tour (premier tour, demi-finale…) se
situe chaque combat. Notons que plusieurs combats peuvent avoir lieu simultanément, évi-
demment entre des adversaires différents ! Tout au long des deux jours de compétition, les
combats sont programmés par demi-heure (à 8 h, 8 h 30…).
Travail à faire
1. Faites le MCD modélisant le tournoi en utilisant une entité Combat.
2. Faites le MCD modélisant le tournoi sans entité Combat.
3. Quelle solution vous semble la meilleure ?
Exercice 5
Un organisme de vente par correspondance veut revoir son système informatique et fait
appel à vous pour réaliser l’analyse. Voici les notes que vous avez prises :
Un produit possède un prix, un libellé, des dimensions (longueur, largeur et hauteur) et un
poids. Les articles textiles ont également une composition : il faut stocker la liste des diffé-
rentes matières présentes et leur pourcentage. Par exemple, un tee-shirt sera 80 % coton,
20 % polyamide. Les meubles en kit auront une durée de montage, une difficulté (facile,
moyen ou difficile) et un nombre de personnes nécessaires pour le montage. Enfin, un pro-
duit appartient à une famille de produits et une seule. Une famille est caractérisée par son
nom (textile, meuble, meuble en kit…), son encombrement (faible, moyen, fort), son type de
livraison (par la Poste ou par transporteur) et sa garantie (aucune, un an ou cinq ans).
Ne sachant pas trop ce que contient une commande ni comment représenter un client,
vous demandez à votre interlocuteur de vous décrire précisément les caractéristiques d’une
commande. Comme cette personne estime qu’un document vaut mieux qu’un long discours,
104
8 3932 TG PA 01
vous donne un bon de commande vierge en vous disant que toutes les informations qui y
figurent sont nécessaires. Le bon de commande en question est repris ci-après.
.......................................................... Bon de commande (début) .........................................................
Numéro de client : .............................

Mme/Mlle/M. (rayer la mention inutile)
Nom : ...............................................Prénom : .............................................
Adresse : .......................................................................................................
Code : ..............................................Ville : ...................................................
Téléphone : .......................................
RÉF. ARTICLE DÉSIGNATION PRIX UNITAIRE QUANTITÉ PRIX TOTAL
TOTAL COMMANDE
PORT (forfait) 10 €
NET À PAYER
Mode de paiement :
q chèque postal q chèque bancaire q carte bleue
.......................................................... Bon de commande (fin) ...............................................................
Une commande est passée à une date donnée par un client. On supposera qu’elle est livrée
d’un bloc à une date donnée. Le règlement peut se faire en plusieurs fois. On veut conserver
les caractéristiques des différents règlements (date, nature – chèque, carte… –).
Travail à faire
Réalisez le MCD modélisant ce système d’information. Faites cet exercice sérieusement car
il est très formateur : relativement long, il possède plusieurs pièges potentiels et met en
œuvre des objets métiers classiques (la commande en l’occurrence).
105
8 3932 TG PA 01
Séquence 6
Exercice 6
Votre travail d’analyse est tellement digne d’éloges que l’on se bouscule pour faire appel à
vos services. Maintenant, c’est une médiathèque qui envisage d’informatiser son activité. Elle
fait appel à vous pour modéliser son système d’information. Voici ce que vos entretiens vous
ont permis d’apprendre :
Nous identifions les documents par un code barre. C’est un identifiant que nous attri-
buons à chaque document de notre fonds documentaire. Nous n’employons pas l’ISBN
qui est pourtant un identifiant dans le monde de l’édition car d’une part c’est un nombre
long à taper et d’autre part tous les documents (cassettes, revues) n’en possèdent pas.
Un document sera d’une nature donnée (livre, périodique, cassette…), aura une durée
en minutes ou un nombre de pages selon sa nature, une date de première parution, une
date et un prix d’achat. Tout document provient d’un éditeur unique et a été créé par
un ou plusieurs auteurs… Enfin, éventuellement 0 pour certains livres anonymes. Si le
document a été traduit, on souhaite savoir par qui. Un document sera dans un état précis
(neuf, moyen, abîmé, à changer).
Un auteur sera décrit par des renseignements pédagogiques (nom, prénom, date et lieu
de naissance et éventuellement de décès). Pour emprunter un document, il faut être ins-
crit à la bibliothèque. Tout emprunteur est décrit par les caractéristiques habituelles ainsi
que par sa date d’inscription (l’inscription est annuelle). Tout emprunteur n’a droit qu’à 3
documents à la fois et ne peut les garder que 3 semaines maximum.
Il faut bien entendu conserver les dates d’emprunt et de retour des documents pour véri-
fier que le délai n’est pas dépassé. Au fait, on peut avoir plusieurs exemplaires d’un même
document. Par exemple, les livres de Stephen King plaisent tellement à nos lecteurs que
nous en achetons toujours 5 exemplaires pour satisfaire la demande.
Travail à faire
Faites le MCD modélisant ce système d’information.
Attention, la notion de document est assez complexe à modéliser. La notion d’emprunt est
également délicate. D’ailleurs, vous envisagerez et modéliserez deux cas :
– celui où l’on emprunte et rend des documents comme on veut, la seule contrainte étant
de ne pas avoir plus de trois documents à un moment donné ; vous supposerez alors
qu’un exemplaire ne peut être emprunté plusieurs fois par la même personne ;
– celui où les documents (qu’il y en ait 1, 2 ou 3) sont empruntés et rendus en une fois.
Pour pouvoir emprunter d’autres documents, il faut avoir rendu celui ou ceux précé-
demment empruntés. Dans ce cas, la contrainte précédente est levée : un lecteur peut
emprunter plusieurs fois le même exemplaire.
106
8 3932 TG PA 01
Séquence 7
Les dépendances fonctionnelles
(théorie)
Nous allons étudier un concept assez théorique, mais pouvant être d’une grande
aide. Ne laissez donc pas tomber maintenant ! C’est dans la séquence suivante
que l’on abordera son utilisation pratique.
• Maîtriser le concept des dépendances fonctionnelles et leurs propriétés
u Contenu
1. Les dépendances fonctionnelles (DF) ........................................ 108
1A. Définition (cas simple) ............................................................................ 108
1B. Soyons précis sur les DF ! ....................................................................... 110
1C. Nouvelle définition (cas général) ........................................................... 111
2. Propriétés des dépendances fonctionnelles ........................... 112

2A. Réflexivité ................................................................................................ 112
2B. Augmentation ......................................................................................... 112
2C. Transitivité ............................................................................................... 112
2D. Composition ............................................................................................. 113
3. Simplification des DF ....................................................................... 113

3A. Atomicité .................................................................................................. 113
3B. Élémentarité ............................................................................................ 114
3C. DF directe ................................................................................................. 114
4. Normalisation d’un ensemble de DF ......................................... 115
4A. Intérêt de la normalisation ..................................................................... 115
4B. Ensemble de DF normalisé ..................................................................... 116
5. Enfin fini… ........................................................................................... 117
Synthèse
107
8 3932 TG PA 01
Séquence 7
1. Les dépendances fonctionnelles (DF)

Nous allons voir un concept qui, regardé de haut, est élémentaire et intuitif sous des allu-
res théoriques ardues. Concentrez-vous néanmoins au mieux pour aborder cette partie
car elle demeure plus théorique que les autres et va finalement assez loin.
Pas de panique cependant, j’essaierai de donner des exemples le plus souvent possible.
On étudie ce concept car il fournit une aide méthodologique réelle pour le choix des
identifiants, pour décider si une association peut être porteuse, voire pour construire un
morceau de MCD !
1A. Définition (cas simple)

Ouah, c’est une expression qui en impose ! « Dépendance fonctionnelle ». Est-ce aussi
ardu que le nom semble complexe ? Ma foi non. C’est un concept simple, mais dont les
applications sont importantes.
Les dépendances fonctionnelles sont définies entre des propriétés. Un exemple pour
être clair ? Eh bien, la dépendance fonctionnelle pourrait servir à définir l’identifiant.
Nous avons déjà vu dans le cours que l’identifiant d’une entité était choisi de telle façon
que sa valeur déterminait celles des propriétés de l’entité. Attention, il faut être précis.
Évitez de dire (et pire encore, de penserå) « quand on connaît l’identifiant, on connaît
les propriétés ». C’est faux et je vous le prouve.
Voici l’identifiant (numéro de Sécurité Sociale) d’une personne : 2 15 03 21 125 999.
Avoir la valeur de l’identifiant vous donne-t-il le nom de cette personne, son adresse,
téléphone… ? Non ! En revanche, vous savez qu’il n’y aura qu’un nom, un prénom
et une adresse qui vont correspondre puisque la valeur de l’identifiant identifie (de
façon unique) l’occurrence cherchée. Mais quelles seront les valeurs des propriétés,
c’est une autre histoire.
La définition parfaite de l’identifiant est donc : la valeur de l’identifiant caractérise l’oc-
currence correspondanteç.
Reformulons : caractériser l’occurrence signifie caractériser toutes ses propriétés. Ce qui
veut dire que la valeur de l’identifiant caractérise chaque propriété, donc que la valeur
de l’identifiant détermineé celle de chaque propriété.
Nous y sommes ! Si l’on veut employer un vocabulaire technique, on ne dira pas que la
valeur de la propriété X détermine celle de la propriété Y, mais que Y est en dépendance
fonctionnelle avec X.
Ainsi, on ne dira pas « la valeur de l’identifiant détermine celle de chaque propriété »,
mais plutôt « chaque propriété est en dépendance fonctionnelle avec l’identifiant ».
Comme toujours, voyons ce que signifient les termes.
å J’ai fait la confusion assez longtemps, d’où certaines incompréhensions ultérieures que j’aime-
rais vous éviter.
ç Définition parfaite ? Je viens de vérifier, c’est bien la définition que j’ai donnée dans la
séquence 2. Je suis assez fier de moi.
éAttention ! J’insiste sur le fait que détermine signifie que la valeur est unique et pas qu’on
la connaît !
108
8 3932 TG PA 01
Les dépendances fonctionnelles (théorie)
Fonctionnelle
Fonctionnelle : relatif à une fonction. (Petit Robert)
Fonction : rôle caractéristique que joue une chose dans l'ensemble dont elle fait partie.
(Bob)
Comme nous parlons de propriétés, le rôle dont on parle correspond à la valeur de la
propriété.
Dépendance
Dépendance : rapport qui fait qu’une chose dépend d’une autre. (idem)
Dépendre : ne pouvoir se réaliser sans l'action ou l'intervention. (idem)
La dépendance fonctionnelle indique donc que la valeur de la propriété dépend de la
valeur d’une autre propriété. Passons sans plus attendre à la définition théorique.
Dépendance fonctionnelle : on dira que la propriété Q dépend fonctionnellement de
la propriété P (noté P " Q) si la valeur de P détermine celle de Q, donc si à une valeur
de P ne correspond qu’une unique valeur de Q.
P est la source de la dépendance, Q est la cible.
Comme « Q dépend fonctionnellement de la propriété P » est difficile à lire et à pro-
noncer, on dénombre dans la littérature un nombre proprement stupéfiant de variantes,
chaque auteur préférant sa version :
– Q est en dépendance fonctionnelle avec P ;
– Q est en dépendance fonctionnelle vis-à-vis de P ;
– Q est en DF avec P ; [DF pour Dépendance Fonctionnelle]
– Q dépend fonctionnellement de P ;
– Q dépend de P. (J’utiliserai cette version, moins coûteuse en touches de clavierå.)
La flèche est assez explicite. On a bien l’idée d’implication, de détermination.
Métaphoriquement, la dépendance fonctionnelle est un lien de cause à effet sémanti-
que. En travaillant sur l’identifiant, on a donc bien déjà réfléchi sur les dépendances. On
notera que les dépendances s’écrivent sur des propriétés (dans P " Q, P et Q sont des
propriétés), mais qu’elles s’appliquent (se définissent) sur les valeurs de ces propriétés.
Exercice 51
D’une façon générale, y a-t-il un lien de dépendance fonctionnelle entre Prénom et
DateNaissance ? Si oui, lequel ?
Idem entre NuméroSécu et Prénom, puis entre NuméroSécu et DateNaissance.
å Attention ! Dans une copie ou oralement, placez au moins une fois les deux mots « dépendan-
ce fonctionnelle » pour montrer que vous les connaissez. Ensuite, vous avez le droit d’abréger
en « dépendance ».
109
8 3932 TG PA 01
Séquence 7
1B. Soyons précis sur les DF !

Attention, les dépendances fonctionnelles ne tombent pas du ciel. Si je vous donne deux
propriétés P et Q, y a-t-il un lien de dépendance fonctionnelle entre les deux ? Et si oui,
dans quel sens ? P " Q ou Q " P ? On n’en sait rien.
Les problèmes commencent ! Je vous dis que l’on ne peut pas décider au débotté s’il
existe une DF entre deux attributs et pourtant, dans l’exercice précédent, on a bien su
le faire avec NuméroSécu.
Pourquoi ? Parce que l’on sait que NuméroSécu est un identifiant ; il sera donc par
définition source de DF avec toutes les propriétés associées à l’entité qu’il identifie (ici,
une personne). Mais c’est un cas particulier de propriété tellement classique qu’elle est
connue indépendamment de tout système d’information.
En fait, pour décider s’il existe une dépendance fonctionnelle entre deux propriétés, il fau-
dra connaître le contexte, donc le système d’information observéå. Vous avez besoin de la
sémantique de la propriété pour conclure, et de la sémantique complète ! En effet, vous
me direz que le prénom, eh bien, c’est le prénom, que l’on soit dans l’entreprise, à la ferme,
à la Sécurité sociale… Certes. Mais dans certains cas, le prénom est plus que le prénom !
Nous sommes à la mairie où l’on veut informatiser la gestion des électeurs. Le prénom peut-
il être identifiant ? Non, car il y a de multiples personnes qui ont le même prénom. C’est
pourquoi on n’aura pas de dépendance fonctionnelle entre Prénom et DateNaissance.
Nous sommes maintenant au sein d’une famille (parents et enfants). Dans ce cas, le
prénom est sensé être un identifiant puisqu’on ne va pas appeler deux enfants par le
même prénom ou par le prénom des parents. Dans ce cas, on a une DF entre Prénom et
DateNaissance dans le sens suivant : Prénom " DateNaissance.
Exercice 52
Dans le cas de la famille que l’on vient d’étudier, pouvons-nous avoir la DF
DateNaissance " Prénom ?
Exercice 53
Les dépendances fonctionnelles sont liées aux propriétés et à leur sémantique in situ, c’est-à-
dire leur sémantique dans le système d’information considéré (dans le monde réel).
Un MCD est donc un support particulièrement adapté pour travailler sur les dépendances, puis-
qu’il a pour objet de modéliser parfaitement le réel. Je vous demande d’énumérer toutes les
dépendances fonctionnelles que vous trouverez avec les propriétés du MCD suivant (une aide, il
y en a 14, dont 8 tellement évidentes que l’on n’y pense pas forcément).
å J’y pense seulement maintenant… cette notion que « tout dépend du système d’information
observé » se retrouve en physique. Vous faites un raisonnable 130 km/h sur l’autoroute. Pouvez-
vous dire que vous bougez ? Oui si vous prenez comme référence un poteau indicateur, non si
votre référence est votre passager. D’où la formule tout est relatif. (Qui veut dire tout s’exprime
relativement (par rapport) au contexte.)
110
8 3932 TG PA 01
ÉTUDIANT
NuméroÉtudiant
Nom
COURS
Prénom suivre 0,n Titre
Rue 1,n
Durée
CodePostal
Ville
1C. Nouvelle définition (cas général)

Nous avons vu dans la séquence précédente que l’identifiant pouvait être constitué par
plusieurs propriétés. On pourra donc étendre la définition de la dépendance fonction-
nelle à plusieurs propriétés du côté gauche de ".
On dira que la propriété Q dépend fonctionnellement des propriétés P1 , P2 … Pn
(noté P1 , P2 … Pn " Q) si la valeur de P1 , P2 … Pn détermine celle de Q , donc si à une
valeur de P1 , P2 … Pn ne correspond qu’une unique valeur de Q.
La phrase précédente doit être expliquée car il y a un point ambigu.
Si la valeur de P1, P2 … Pn détermine celle de Q
La formule classique est plutôt « si les valeurs de P1, P2… et Pn déterminent celles de Q ».
Mais cela ne signifie pas que la valeur de P1 donnera une valeur de Q, celle de P2 donnera
une autre valeur à Q… comme l’illustre le schéma suivant :
{
P1 " Q
P2 " Q
u
Enfin, cela peut arriver, mais c’est une coïnci-
P1, P2… Pn " Q
… dence et pas le cas général.
Pn " Q
La phrase signifie que si chaque P1 à une valeur (ainsi la concaténation de P1, P2… Pn
possède une valeur) alors la valeur de Q sera déterminée.
En fait, si l’on pose P = P1, P2… Pn, on retrouve P " Q.
Vous remarquerez qu’il n’y a aucune notion d’ordre dans les propriétés sources :
A, B " C est équivalent à B, A " C.
Exercice 54
Dans le MCD suivant, donnez toutes les DF (ne tenez pas compte des DF d’une propriété vers
elle-même). Il y en a 14.
NumenInsp inspecter NumenEns
NomInsp note NomEns
PrénomInsp commentaire PrénomEns
1,n 0,n
AdrInsp AdrEns
CodeInsp 1,n CodeEns
VilleInsp VilleEns
DATE
CodeInsp DateConc
JJMMAAAA
111
8 3932 TG PA 01
Séquence 7
2. Propriétés des dépendances fonctionnelles

Si je voulais faire intello, je vous dirais que ce qui suit constitue les trois axiomes de
Armstrong. Par définition, les axiomes ne se démontrent pas. Il faut les admettre, ce qui
est facile si vous en comprenez le sens.
Dans ce qui suit, on pose que P, Q, Pi (pour tout i) et Qj (pour tout j) sont des propriétés
quelconques. Je vous donnerai la formule mathématique, puis une explication en fran-
çais pour aider votre intuition.
2A. Réflexivité
Cas particulier (vu dans l’exercice précédent) :
Q"Q
Cela signifie que toute propriété est en dépendance avec elle-même.
Cas général :
P1, P2… Pn " Pi (i ≤ n)
Comme la valeur de Pi détermine Pi (Pi " Pi), on peut rajouter d’autres propriétés à gau-
che qui comptent « pour du beurre ». En effet, comme Nom " Nom, alors Nom, Prénom
" Nom puisque, quelle que soit la valeur donnée à Prénom, celle de Nom donne… celle
de Nom.
Notons que cet axiome multiplie à l’infini le nombre de DF potentielles !
2B. Augmentation
Si Q dépend fonctionnellement de P, alors pour une propriété Z quelconque, Q, Z
dépend de P, Z :
si P " Q alors P, Z " Q, Z
En effet, dans le couple « Q, Z », Q sera déterminé par P (puisque P " Q) et Z par Z (car
Z " Z).
Par exemple : numéro de Sécu " année de naissance
donc numéro de Sécu, Prénom " année de naissance, Prénom
2C. Transitivité
J’espère qu’arrivés ici, nous sommes d’accord sur la relative simplicité de ce que l’on a déjà
vu. Voyons maintenant la transitivité des DF.
La transitivité ? Mais si, la transitivité ! Vous savez, comme dans la transitivité de l’égalité
qui dit que si a = b et b = c, alors a = c.
Eh bien, les dépendances fonctionnelles sont transitives :
P, Q et R étant des propriétés, si P " Q et Q " R, alors P " R
Par exemple, on a :
numéro de Sécu " département (chiffres 6 et 7 du numéro)
or département " préfecture du département (car une préfecture par département)
donc numéro de Sécu " préfecture du département
112
8 3932 TG PA 01
Encore une fois, cela ne veut pas dire que l’on a l’information. Cela veut juste dire
qu’elle existe. Mon numéro de Sécurité sociale est 1 xx xx 54 xxx xxx (les x remplacent
des chiffres sans intérêt ici). Le département 54, comme tout département, possède une
préfecture. Il vous faudra peut-être consulter le dictionnaire pour la trouver mais, une
chose est sûre, elle existe et est unique.
2D. Composition
Ceci n’est pas un axiome, mais un corollaire de ces axiomes, à savoir une conséquence
directe.
Si P1 " Q1 et P2 " Q2, alors P1, P2 " Q1, Q2.
Exercice 55
Pouvez-vous démontrer ceci ? Une petite aide : il faut utiliser deux fois l’augmentation puis la
transitivité.
Notez que l’inverse n’est pas vrai. Si A, B " C, D, on ne peut en déduire ni :

A " C et B " D ni
A " D et B " C.
3. Simplification des DF
Après avoir étudié les propriétés des DF, nous allons apprendre à les simplifier pour leur
donner une forme conventionnelle. C’est à partir de cette forme que l’on pourra générer
le MCD.
3A. Atomicité
Le cas vraiment général d’une DF est le suivant : P1, P2… Pn " Q1, Q2… Qm
Cette formule signifie, en appliquant strictement la définition, que la valeur de P1, P2… Pn
détermine celle de Q1, Q2… Qm. Dit autrement, si chacun des Pi possède une valeur, alors
chacun des Qj en possédera une unique. Donc chacun des Qj est en DF avec P1, P2… Pn.
Ainsi :
{
P1, P2 … Pn " Q1
P1, P2… Pn " Q2
P1, P2… Pn " Q1, Q2… Qm | équivalent } …
P1, P2… Pn " Qm
Définition : une dépendance fonctionnelle est atomique si elle ne possède qu’une

propriété cible (à droite de ").
Dès que l’on travaille sur des DF, on s’empresse de les rendre atomiques pour n’avoir
qu’un terme cible. Notons que cela augmente sensiblement leur nombre.
113
8 3932 TG PA 01
Séquence 7
Exemple : reprenons notre exemple d’enseignant identifié par son Numen. Toutes les
propriétés de l’enseignant sont en dépendance fonctionnelle avec le Numen, ce que l’on
peut écrire en une DF ou en six DF atomiques :
Numen " Nom
{
Numen " Prénom
Numen " Adr
Numen " Nom, Prénom, Adr, Code, Ville, DateConc | équivalent } Numen " Code
Numen " Ville
Numen " DatConc
Exercice 56
Démontrez, en utilisant l’atomicité et l’augmentation, que si P " Q, alors P, Z " Q.
3B. Élémentarité
Attention à ne pas confondre l’élémentarité d’une propriété et celle d’une DF !
Néanmoins, si c’est le même mot, c’est parce que les concepts sont similaires.
Une dépendance fonctionnelle est élémentaire si :
– elle est atomique ;
– les propriétés sources de la DF sont minimales, à savoir que si l’on en enlève
une, on n’a plus de dépendance.
Mathématiquement, on écrira : P1, P2… Pn " Q est élémentaire si pour tout i tel que
1 ≤ i ≤ n, P1, P2…, Pi-1, Pi+1… Pn " Q.
Voyons un exemple : NuméroSécu, Nom " DateNaissance n’est pas élémentaire.
En effet, comme NuméroSécu " DateNaissance, on peut enlever une propriété source
(ici, Nom) sans perdre la DF.
On remarquera que toute DF n’ayant qu’une propriété source et une propriété cible est
trivialement élémentaire (atomique car une seule propriété cible, minimale car une seule
propriété source).
3C. DF directe
Les deux caractéristiques précédentes concernaient chaque DF prise individuellement. En
revanche, la notion de DF directe n’a de sens que dans un ensemble de dépendances et
de propriétés.
Une dépendance fonctionnelle sera directe si elle n’est pas issue de la transitivité
d’autres dépendances. Ainsi, A " C sera directe s’il n’existe pas de propriété B telle
que A " B et B " C.
On notera que les dépendances qui ne sont pas directes sont inutiles dans la mesure où,
grâce à la transitivité, on les retrouve.
114
8 3932 TG PA 01
Exercice 57
Identifiez les dépendances qui ne sont pas directes dans cet ensemble :
1. DateNaissance " Âge 6. NuméroClient " MontantRemise
2. NuméroSécu " DateMajorité 7. DateNaissance " DateMajorité
3. NuméroClient " TypeClient 8. Nom " CodeSecret
4. DateNaissance " SigneZodiaque 9. TypeClient " MontantRemise
5. NuméroSécu " Nom, Prénom 10. NuméroSécu " DateNaissance
4. Normalisation d’un ensemble de DF
4A. Intérêt de la normalisation

Les exemples précédents et le cours montrent qu’avec quelques propriétés, on peut mul-
tiplier le nombre de DF de façon totalement déraisonnable !
Par exemple, avec les propriétés X et Y, on aura entre autres :
X"X X, Y " X, Y
X, X " X, X Y, Y, X, Y " Y, Y, Y, Y
Bien entendu, même si ces dépendances existent, elles sont triviales et n’ont absolument
aucun intérêt. On va donc apprendre à normaliser un ensemble de DF pour n’en garder
qu’un sous-ensemble représentatif, à savoir le plus petit sous-ensemble de DF permet-
tant de récupérer l’ensemble de départ en appliquant les différentes propriétés des DF.
Bref, on va tenter d’éliminer la redondance.
Exercice 58
Le principe d’élimination de la redondance est assez naturel : dans la vie de tous les jours, on
évite de dire plusieurs fois la même chose. Considérons les phrases suivantes :
1. Les parents de Jean-Yves sont Yves et Josette.
2. Le frère de Jean-Yves est Éric.
3. Les sœurs de Frédérique sont Élisabeth, Françoise, Marie-Claire et Pascale.
4. Les belles-sœurs de Jean-Yves sont Élisabeth, Françoise, Marie-Claire et Pascale.
5. Éric est le beau-frère de Frédérique.
6. Yves et Josette sont les parents d’Éric.
7. Les parents de Pascale sont Denise et Auguste.
8. Frédérique et Jean-Yves sont mariés ensemble.
9. Les parents de Frédérique sont Auguste et Denise.
10. Françoise est la belle-sœur de Jean-Yves.
En vous aidant éventuellement d’un arbre généalogique, enlevez le maximum de phrases en ne
perdant aucune information (n’enlevez que les phrases apportant une information redondante).
Notez que ceci n’a rien à voir avec les dépendances fonctionnelles, c’est juste une justification de la
traque à la redondance.
115
8 3932 TG PA 01
Séquence 7
Ce que l’on vient de faire avec les « règles de la vie », on va le faire sur les DF en exploi-
tant leurs différentes propriétés.
4B. Ensemble de DF normaliséå

Nous travaillons pour le moment avec un ensemble arbitraire (« tombé du ciel ») de
dépendances fonctionnelles. Dans la séquence suivante, les DF seront issues du système
d’information que l’on étudie.
On va reprendre les trois caractéristiques des DF pour les appliquer trivialement aux
ensembles de DF.
{ {
atomique atomiques
Un ensemble de DF est dit élémentaire si toutes les DF qu’il contient sont élémentaires
direct directes
Ensemble de DF normalisé : un ensemble de DF sera normalisé s’il est atomique,
élémentaire et direct.
On veillera toujours à ce que l’ensemble de DF sur lequel on travaille soit normalisé. En
pratique, on normalisera l’ensemble avant toute autre chose.
Notez bien que l’ensemble de départ et l’ensemble normalisé sont équivalents : ils trans-
mettent les mêmes informations. La différence est que l’ensemble normalisé transmet les
informations de la façon la plus concise possible.
Exercice 59
Nous allons travailler sur un ensemble de dépendances où les propriétés sont arbitraires (je les
appelle A, B…). Cela me permet de définir ce que je veux en DF pour faire un sujet un peu plus
complexe.
Il vous est demandé de normaliser l’ensemble de dépendances fonctionnelles suivant :
A, B, C " E, F B"D A, B " H
D"H E"H A, D " H
Une aide : il faut rendre les DF atomiques, puis élémentaires, puis enlever celles qui ne sont
pas directes.
å Attention normalisé et non normalisées car c’est l’ensemble qui est normalisé et non les DF.
Ne vous acharnez pas sur cette séquence si elle vous semble trop ardue. L’important,
c’est d’avoir compris le principe des DF pour pouvoir vous en servir dans la séquence
suivante.
116
8 3932 TG PA 01
5. Enfin fini…
C’est fini pour la théorie des dépendances fonctionnelles. On étudiera leur utilisation
pratique pour le MCD dans la séquence suivante. Vous devez néanmoins sentir en quoi la
notion de dépendance fonctionnelle est importante dans le MCD. En effet, les DF tradui-
sent les dépendances entre les propriétés, tandis que le MCD structure les données (en
entités et associations) en exploitant les liens entre propriétés mis au jour par les DF.
Donc on peut dire que :
MCD = structuration des données + dépendances entre ces données
Nous verrons d’ailleurs dans la séquence suivante comment construire le MCD à partir
des DF.
117
8 3932 TG PA 01
Synthèse
Définition
Dépendance fonctionnelle (cas général) : on dira que la propriété Q dépend
fonctionnellement des propriétés P1, P2… Pn (noté P1, P2… Pn " Q) si la valeur de
P1, P2… Pn détermine celle de Q, donc si à une valeur nn de P1, P2… Pn ne corres-
pond qu’une unique valeur de Q. Les Pi sont la source de la dépendance, Q est
la cible.
Propriétés des dépendances

Réflexivité : P1, P2… Pn " Pi (i ≤ n)
Augmentation : si P " Q alors P, Z " Q, Z
Transitivité : si P " Q et Q " R alors P " R
Normalisation des DF
Une dépendance fonctionnelle est atomique si elle ne possède qu’une propriété
cible.
Une dépendance fonctionnelle est élémentaire si :
– elle est atomique ;
– les propriétés sources de la DF sont minimales, à savoir que si l’on en enlève
une, on n’a plus de dépendance.
Une dépendance fonctionnelle sera directe si elle n’est pas issue de la transitivité
d’autres dépendances. Ainsi, A " C sera directe s’il n’existe pas de propriété B
telle que A " B et B " C.
{ {
atomique atomiques
Un ensemble de DF est dit élémentaire si toutes les DF qu’il contient sont élémentaires
direct directes
Un ensemble de DF sera normalisé s’il est atomique, élémentaire et direct.
119
8 3932 TG PA 01
Séquence 8
Les dépendances fonctionnelles
(utilisation)
Après avoir souffert dans la séquence précédente (c’était la plus théorique du

cours), nous allons exploiter de façon pratique nos nouveaux acquis. Les person-
nes qui liront ce qui suit, et n’auront donc pas abandonné le cours pendant les
DF, vont voir leurs efforts récompensés !
• Savoir établir le dictionnaire des données
• Utiliser la notion de forme normale pour valider son MCD
• Savoir réaliser une partie de MCD avec la méthode des DF
Contenu
1. Choix d’un identifiant ..................................................................... 122
1A. Les dépendances fonctionnelles au sein d’une entité ......................... 122
1B. Les dépendances fonctionnelles au sein d’une association ................. 123
1C. Les trois formes normales (FN) .............................................................. 123
1D. Résumé sur les formes normales ........................................................... 126
2. Démarche de construction du MCD à la papa (avec les DF) ... 126

2A. Introduction ......................................................................................... 126
2B. La démarche ............................................................................................ 127
2C. Le dictionnaire des données.................................................................... 127
2D. Graphe des dépendances fonctionnelles (graphe des DF) .................. 135
2E. Construction du MCD à partir du graphe .............................................. 137
3. Formes normales et MLD ................................................................ 141

3A. Première forme normale ......................................................................... 141
3B. Deuxième forme normale ....................................................................... 141
3C. Troisième forme normale ....................................................................... 141
Synthèse
121
8 3932 TG PA 01
Séquence 8
1. Choix d’un identifiant

Dans la séquence 5, nous avons étudié des considérations purement intuitives pour choisir
l’identifiant d’une entité. Grâce aux dépendances fonctionnelles, nous pouvons formali-
ser cela.
1A. Les dépendances fonctionnelles au sein d’une entité

Nous avons déjà vu que, par définition d’un identifiant, toute propriété d’une entité
était en dépendance fonctionnelle avec l’identifiant de l’entité.
Exercice 60
D’après ce que je viens de rappeler, donnez les dépendances fonctionnelles implicitement
contenues dans l’entité Client suivante, puis dans le cas général de l’entité Entité :
CLIENT ENTITÉ
NuméroClient Identifiant
NomClient Propriété_1
PrénomClient Propriété_2
AdrClient Propriété_3
CodeClient (etc)
VilleClient Propriété_n
TéléphoneClient
Si nous nous contentons de dire que l’identifiant est tel que toute propriété est en DF
avec, les candidats seront nombreux ! Dans le cas de Client, la concaténation des deux
propriétés NuméroClient et NomClient est également identifiant d’après les propriétés
des DF. Ainsi, l’entité suivante est pour le moment valide :
CLIENT
NuméroClient
NomClient
PrénomClient
AdrClient
CodeClient
VilleClient
TéléphoneClient
(je pouvais choisir n’importe quelle propriété de l’identifiant au lieu de NomClient.)
Exercice 61
Tiens, oui, c’est vrai, on les avait vues, ces propriétés des DF ! Pouvez-vous prouver que si
NuméroClient est source de DF avec toutes les propriétés de Client, alors il en est de même pour
la concaténation de NuméroClient et NomClient ? (cela revient à démontrer que ce couple est
identifiant.)
122
8 3932 TG PA 01
Les dépendances fonctionnelles (utilisation)
On se rend compte que notre notion d’identifiant est assez floue puisque de nombreux
candidats se présentent ! Intuitivement, on se doute que, fidèle à notre principe d’éco-
nomie, le meilleur identifiant sera le plus concis. Nous allons le formaliser avec la notion
de forme normale dans le paragraphe 1C.
1B. Les dépendances fonctionnelles au sein d’une association

Finalement, partout où il y a identifiant et propriété, il y aura dépendance fonctionnelle.
Donc dans les entités, mais aussi dans les associations porteuses de données.
Les propriétés d’une association seront en dépendance fonctionnelle avec l’identifiant
de cette association.
Reprenons le cas des inspections :
NumenInsp inspecter NumenEns
NomInsp note NomEns
PrénomInsp commentaire PrénomEns
1,n 0,n
AdrInsp AdrEns
CodeInsp 1,n CodeEns
VilleInsp VilleEns
DATE
CodeInsp DateConc
JJMMAAAA
Les DF seront :
NumenInsp, NumenEns, JJMMAAAA " note
NumenInsp, NumenEns, JJMMAAAA " commentaire
Cela ne vous paraît pas si évident ? Cela vient du fait que les propriétés portées sont
déterminées par l’identifiant de l’association (on a déjà fait cela, c’est l’exercice 54 !).
Vous remarquerez que nous exploitons intensément le cours ; ceux qui ne l’ont pas
appris doivent souffrir.
1C. Les trois formes normales (FN)

Habituellement, on exploite la notion de forme normale avec les relations, c’est-à-dire
dans le MLD (séquence 5). Mais comme le MLD découle directement du MCD, puisqu’il
en est la traduction dans un autre formalisme, les formes normales s’appliquent valable-
ment au MCD.
D’ailleurs, des relations non normalisées (ne suivant pas les formes normales) viennent
d’un MCD erroné (non normalisé lui aussi).
Nous exploiterons les formes normales avec les entités et les associations. Mais au fait, à
quoi servent-elles ? Ce sont des formes normalisées assurant la correction du MCD. Des
théoriciens ont en effet montré que si ces FN n’étaient pas respectées, le modèle était
faux. C’est pourquoi il est intéressant de les connaître ! Vous verrez qu’elles reprennent
des éléments de cours déjà connus.
123
8 3932 TG PA 01
Séquence 8
1C1. Première forme normale

L’entité ou l’association sera en première forme normale si toutes les propriétés
dépendent fonctionnellement de l’identifiant et sont élémentaireså.
Je vous rappelle que l’élémentarité des propriétés est relative, tout dépend du système
d’information (revoir séquence 2, paragraphe 3).
Bon, jusqu’à présent, toutes nos entités étaient en première forme normale ; passons
donc à plus intéressant.
1C2. Deuxième forme normale

Une entité ou association sera en deuxième forme normale si :
– elle est en première forme normale et
– toute propriété non identifiant est en dépendance fonctionnelle élémentaire
avec l’identifiant.
Dit autrement, toute propriété non identifiant doit dépendre de tout l’identifiant et
pas d’une partie. Bien entendu, si l’identifiant est élémentaire (composé d’une seule
propriété), toute entité en 1re FN est trivialement en 2e FN.
Exercice 62
Ah oui ? trivial ? Eh bien, expliquez-moi qu’avec un identifiant élémentaire, 1re FN et 2e FN sont
équivalentes !
Voici quelques exemples :

Dans le MCD des inspections (paragraphe 1B), les dépendances sont en 2e FN :
NumenInsp, NumenEns, JJMMAAAA " note
Si l’on enlève l’une des trois propriétés sources, la note n’est plus déterminée de façon
unique.
En revanche, observons cette entité :
CLIENT
NuméroClient
NomClient
PrénomClient
AdrClient
CodeClient
VilleClient
TéléphoneClient
Elle n’est pas en 2e FN car la dépendance NuméroClient, NomClient " PrénomClient (ou
toute autre propriété cible) n’est pas élémentaire (en enlevant NomClient, la dépen-
dance fonctionnelle est toujours juste).
å Élémentaire, élémentaire… vous avez un trou ? Allez voir séquence 7 paragraphe 3B.
124
8 3932 TG PA 01
Exercice 63
Dans le MCD suivant (déjà étudié en séquence 6), l’association livrer est-elle en 2e FN ?
CLIENT COMMANDE
NuméroClient livrer NuméroCommande
NomClient dateLivraison DateCommande
0,n 1,n
PrénomClient MontantCommande
AdrClient 0,n
ENTREPÔT
NuméroEntrepôt
AdrEntrepôt
TelEntrepôt
1C3. Troisième forme normale

Une entité ou association sera en troisième forme normale si :
– elle est en deuxième forme normale et
– il n’y a aucune dépendance fonctionnelle entre deux propriétés non identifiant.
En clair, les dépendances fonctionnelles doivent avoir comme seule source l’identifiant.
Encore plus clairement, cela signifie que l’entité ne doit contenir qu’un identifiant pos-
sible. Notons que cette forme normale peut ne pas être vérifiée. Mais il faudra alors
s’assurer que c’est justifié !
Exercice 64
Étudiez les entités suivantes et indiquez leur forme normale (1re, 2e ou 3e). Pour celles qui ne
sont pas en 3e forme normale, vous justifierez si elles sont valides ou non.
SALARIÉ ENTREPRISE ASSURÉ SOCIAL ENSEIGNANT
NuméroSalarié NuméroEnt NuméroSécuAS NumenEns
NumSécuSalarié NomEnt NomAs NomEns
NomSalarié AdrEnt PrénomAs PrénomEns
PrénomSalarié VilleEnt AdrAs AdrEns
AdrSalarié TelEnt VilleAs VilleEns
VilleSalarié FaxEnt
TelSalarié
1C4. Pourquoi pas des 4e, 5e, 6e formes normales ?

Au point où nous en sommes…
Eh bien, justement, puisque vous m’en parlez… Il existe d’autres formes normales (la 4e, la
5e, la forme normale de Boyce Codd…). Pourquoi une telle inflation ? Les formes normales
ont pour objet d’assurer une représentation des données correcte (qui « tienne la route »).
125
8 3932 TG PA 01
Séquence 8
D’où les trois premières, qui règlent beaucoup de problèmes. Mais à l’usage, on s’est rendu
compte que tous les problèmes n’étaient pas résolus. D’où les autres formes normales.
Nous ne les étudierons pas ici car elles n’apportent rien à notre propos.
1D. Résumé sur les formes normales

Comme les définitions ci-dessus ne sont pas forcément aisées à retenir, je vous propose
cette formulation condensée :
Une entité ou association doit être en troisième forme normale, à savoir : les proprié-
tés, élémentaires, dépendent de l’identifiant (1re FN), de tout l’identifiant (2e FN) et
que de l’identifiant (3e FN).
Vérifiez que cette phrase reprend bien toutes les caractéristiques des formes normales.
2. Démarche de construction du MCD à la papa (avec les DF)
2A. Introduction
Lorsque nos parents faisaient du Merise, ils n’avaient pas notre recul. Ils appliquaient
donc la méthode avec rigorisme. L’avantage était d’avoir une démarche presque scien-
tifique, donc sans risque d’erreur. Le problème est que l’analyse reste quelque chose de
créatif où les règles sont parfois plus un carcan qu’une aide.
Quelle technique vous ai-je appris pour concevoir un MCD ? Ma foi, beaucoup de vent
diront les mécontents. En effet, quelques conseils pratiques mis à part, on travaille finale-
ment à l’intuition : on lit le sujet, on crayonne un bout de MCD, on corrige, on complète…
Tout cela ne fait pas très professionnel. Cependant, c’est la technique la plus efficace avec
de l’entraînement. Et, surtout, c’est la seule praticable sur des cas réels.
Il existe cependant une technique beaucoup plus rigoureuse. C’est la technique originale
de conception des MCD initiée par les créateurs de la méthode Merise. Le problème est
que les utilisateurs de Merise se sont rendus compte que cette technique était inapplica-
ble pour des cas un tant soit peu volumineux.
Je sens votre inquiétude : pourquoi apprendre une technique inefficace ? Ce n’est pas
par goût de l’histoire informatique que je vais vous la présenter, mais simplement parce
que, quand vous sentez que tout votre raisonnement et votre intuition ne suffisent pas,
qu’un morceau du MCD vous semble bizarre et, osons le mot, faux, sans que vous sachiez
comment le résoudre, cette technique vous permet de remettre à plat l’extrait de MCD
fautif et d’appliquer des règles de construction strictes mettant de côté votre intuition.
Bref, si la méthode classique (l’intuition) ne donne rien, l’idée est d’aborder le problème
par un autre côté. J’insiste sur le fait que cela ne doit concerner qu’un sous-ensemble
restreint du MCD pour rester praticable. Cette technique met en œuvre les dépendances
fonctionnelles… ce qui n’est pas une surprise.
126
8 3932 TG PA 01
2B. La démarche
Les étapes à suivre sont les suivantes :
1. On recense toutes les données du système d’information. Après dépouillement, on
produit le dictionnaire des données.
2. On cherche ensuite toutes les dépendances fonctionnelles entre ces données. On
normalise cet ensemble de DF.
3. On représente graphiquement l’ensemble des dépendances normalisé.
4. Le MCD se déduit mécaniquement de cette représentation.
Inutile de rêver : ce n’est pas vraiment plus simple car la difficulté se retrouve dans
l’établissement des DF. L’intérêt est que c’est une démarche différente qui peut aboutir
quand l’intuition bloque.
De cette démarche, que nous reste-t-il à étudier ? Le dictionnaire des données, la repré-
sentation graphique des DF et sa traduction en MCD.
Vous êtes prêts ? Eh bien, on y va.
2C. Le dictionnaire des données

2C1. Introduction
J’ai placé le dictionnaire des données dans le cycle de conception du MCD à la papaå, puis-
qu’il en fait partie. J’attire votre attention sur le fait que, si l’on n’utilise plus la méthode
de conception par les DF, le dictionnaire des données reste néanmoins à l’ordre du jour.
Prenons un peu d’avance pour dire dès maintenant que les données du dictionnaire
deviendront un peu plus tard les propriétés du MCD. Bon. Pourquoi rajouter encore un
nouveau terme ? Le mot propriété ne suffisait-il pas ? En fait, je peux donner deux rai-
sons à cette distinction dans la terminologie :
• une propriété est une notion liée à une entité, ce qui n’a rien à voir avec le concept
de variable en programmation (c.-à-d. les données) ;
• une donnée est typée. Eh oui, on précise son type puisqu’un jour ou l’autre, il fau-
dra bien implanter tout cela ! Notez d’ailleurs que si la donnée est typée, le concept
correspondant dans le MCD ne l’est pas puis on retrouve le type dans la programma-
tion.
Le programmeur prendra les propriétés du MCD et cherchera leur type dans le diction-
naire. On peut conclure en disant que la propriété a pour représentation physique la
donnée. (Ne vous creusez pas trop la tête sur cette phrase, cela devient assez ardu !)
Le dictionnaire sera donc une énumération des données avec leur type. L’objectif est
de pouvoir créer la base de données grâce à ces informations. Si vous faites un MCD de
taille importante, vous aurez tout intérêt à faire le dictionnaire afin d’être sûr de ne pas
oublier d’information.
å Bon, je vais arrêter d’appeler cette technique ainsi, même si cela m’amuse beaucoup. En effet, la
dénomination officielle est conception du MCD par les dépendances fonctionnelles.
127
8 3932 TG PA 01
Séquence 8
Notez bien que le dictionnaire des données fournit la liste exhaustive des données avec
leur type, le MCD rajoutant la structuration de ces données. Une petite définition pour
enfoncer le clou :
Dictionnaire des données : il regroupe l’ensemble des données élémentaires (nom,
type…) constituant le système d’information.
2C2. Réalisation
Le dictionnaire va être fait en quatre étapes :
1. Recensement de toutes les données utilisées dans le système d’information.
2. Détermination du type des données.
3. Épuration des données.
4. Identification des données calculées avec leur règle de calcul.
Recensement des données

Les données dont on parle ici sont l’exact équivalent des variables ou constantes
O en programmation. Les données conservées deviendront des propriétés, jamais des
associations. Si dans le monde réel l’entreprise vend des produits à des clients, les
caractéristiques des produits et des clients seront des données, les caractéristiques
des ventes également, mais l’action de vendre n’en sera pas.
Une donnée sera élémentaire (comme toujours élémentaire vis-à-vis du système d’in-
formation considéré, voir l’exercice 1). Si on vous parle du nom d’un client, à vous de
décider s’il faut le représenter par deux données Nom et Prénom ou par une donnée
Nom regroupant les deux.
En théorie, les données seront présentées dans l’ordre alphabétique afin de pouvoir les
rechercher facilement. Ce n’est que beaucoup plus tard qu’on les regroupera pour en
faire des entités.
Remarquons que, dès notre premier MCD, nous procédions à cet inventaire de façon trans-
parente pour chercher les propriétés. Nous allons traiter ensemble un sujet déjà vu :
Un terrain est caractérisé par une référence cadastrale, une surface en ares et un type (constructible, inon-
dable, indéterminé…).
Un propriétaire est caractérisé par ses nom, prénom, adresse et date de naissance. Un terrain appartient à
un seul propriétaire, l’achat étant réalisé devant notaire.
Les gens qui ne sont pas du métier n’ayant pas une bonne compréhension de ce qu’est un are, il est décidé
d’avoir la surface en ares et en m2.
Nous allons relire le sujet ligne à ligne pour en tirer les différentes données que l’on
représentera en gras.
Un terrain est caractérisé par une référence cadastrale, une surface en ares et un
type (constructible, inondable, indéterminé…).
Remarque : terrain n’est pas une donnée (en programmation, ce sera un type de donnée structuré, dans
le MCD ce sera une entité).
Un propriétaire est caractérisé par ses nom, prénom, adresse et date de naissance.
(Idem, propriétaire n’est pas une donnée.)
Un terrain appartient à un seul propriétaire, l’achat étant réalisé devant notaire.

Aucune donnée ici.
Les gens qui ne sont pas du métier n’ayant pas une bonne compréhension de ce qu’est
un are, il est décidé d’avoir la surface en ares et en m2.
128
8 3932 TG PA 01
On aura donc deux données représentant la surface : une l’exprimant en ares, l’autre en m2. On ne peut
pas les appeler toutes deux surface car on les confondrait. L’une sera surface en ares, l’autre surface en m2.
Le fait que ces deux données soient liées ne sera pas important avant vingt minutes.
Il ne reste plus qu’à présenter les données proprement par ordre alphabétique. On va
utiliser un tableau à deux colonnes : une pour un nom raccourci (qui deviendra le nom
de la propriété), l’autre pour un commentaire en français si nécessaire.
Le nom raccourci devenant à terme une variable dans le programme, autant respecter
dès maintenant les contraintes de notation des langages, à savoir un mot sans espace,
contenant des lettres, chiffres, caractère de soulignement « _ » et rien d’autre.
Voici une première version du dictionnaire :
DONNÉE COMMENTAIRE
Adresse
DateDeNaissance
Nom
Prénom
Référence référence cadastrale du terrain
SurfaceA surface en ares
SurfaceM2 surface en m2
Type type du terrain : constructible, inondable, indéterminé
Je ne me suis pas fatigué pour le nom des données car j’ai repris le sujet au maximum.
Le problème est que la donnée Type n’est pas intuitive. Dans trois jours, je ne saurai plus
de quel type il s’agit, sauf à conserver le dictionnaire des données sous les yeux ! Type de
client, type de terrain… tout est possible ! De même, SurfaceA… on peut mieux faire !
Et Adresse, c’est celle du terrain ou du propriétaire ?
Vous essaierez d’avoir des noms parlants, sans qu’ils fassent 50 caractères de long,
comme on l’a toujours fait dans les MCD. Pour être transversal, vous choisirez les noms
de données avec le même soin que ceux des variables en programmation.
Voici une nouvelle version du dictionnaire avec des noms de données plus rigoureux.
DONNÉE COMMENTAIRE
AdresseProp
DateDeNaissance
Nom
Prénom
RéférenceTerrain référence cadastrale du terrain
SurfaceAres
SurfaceM2 surface en m2
TypeTerrain type du terrain : constructible, inondable, indéterminé
(Il n’y a plus d’ambiguïté.)
129
8 3932 TG PA 01
Séquence 8
Honnêtement, nous n’avons rien fait de complexe. On remarquera deux choses :

1. Je peux appeler mes données comme je veux (bien entendu, on essaye d’avoir des
noms intelligibles, pas question d’appeler PrixHorsTaxes le nom d’un client). Le plus
important est d’avoir des notations cohérentes. Par exemple, je pourrai nommer les
dates d’achat et de vente :
DateAchat et DateVente ou Date_achat et Date_vente, mais pas un mélange des
deux notations.
2. Bien entendu, on ne mettra un commentaire que lorsque c’est nécessaire. Ajouter
à la donnée NomClient le commentaire Nom du client n’est pas très utile.
Dans le cas des petits sujets que nous traitons, les données vous sautent littéralement aux
yeux. Dans des sujets plus importants, notamment des sujets d’examen, la formulation
sera moins explicite. Par exemple, le texte pourra être présenté sous forme de dialogue
entre l’informaticien et un membre de l’entreprise :
« Eh bien, ma bonne dame, si nous parlions des terrains ?å »
– Oh, c’est très simple, il n’y a rien à en dire, je suis sûre que vous connaissez cela, le
plus important c’est de savoir si le terrain est constructible, inondable ou si l’on a
pas d’information à ce sujet, car bien entendu le permis de construire ne sera pas
accordé pour un terrain inondable, imaginez-vous avec votre maison inondée, c’est
arrivé à la belle-sœur de la voisine de la boulangère de l’amie de ma tante par
alliance, ce n’était pas beau à voir.
– Oui, je vois. Et comment distinguez-vous les terrains les uns des autres ?
– Par la référence cadastrale, pourquoi, c’est important ?
– Oui, parce que…ç. Ah, au fait, êtes-vous intéressée par la surface du terrain ?
– Hou ! C’est capital pour vérifier que le coefficient d’occupation des sols est respecté !
– Et en quoi mesurez-vous la surface ?
– En ares, quoique il faut aussi […] »
Exercice 65
Vérifiez que toutes les données qui étaient dans la phrase « Un terrain est caractérisé par une
référence cadastrale, une surface en ares, un type (constructible, inondable, indéterminé…) »
sont présentes dans le court extrait ci-dessus (soulignez dans le dialogue les différentes
données).
Donc, on est d’accord que tout y est… je me suis un peu amusé avec les digressions de
la bonne dame, mais même sans cela, vous devez vous douter qu’un vrai dialogue ferait
facilement une à deux pages pour donner toutes les informations que j’ai synthétisées
en 5 lignes dans l’exercice.
D’autant que ce que j’ai stigmatisé dans mon dialogue est la vérité : vous devez extorquer
les informations aux gens, qui ne vous les donneront pas spontanément car ils n’y pensent
pas et n’en voient pas l’intérêt. C’est donc à vous de vous assurer que vous avez toutes les
informations… ce qui est une gageure car en général vous ne connaissez pas encore le
å Attention, ce style humoristique est à proscrire dans la vraie vie ! La « bonne dame » n’en serait
certainement pas satisfaite !
ç Je vous laisse le soin d’expliquer pourquoi il faut un identifiant… je n’en ai pas le courage.
130
8 3932 TG PA 01
métier que vous allez informatiser. Est-ce à dire que les gens sont stupides ? Évidemment
non ! C’est simplement que les gens ne sont pas informaticiens (sinon, ils ne feraient pas
appel à vous). Ils n’ont donc pas le même mode de pensée que vous. Vous serez obligé de
poser moult questions, de rencontrer de nombreuses fois les futurs utilisateurs… ce n’est
vraiment pas une étape facile. Bien entendu, si vous oubliez une donnée, vous le paierez
lors de la réalisation du programme car vous serez incapable de le faire.
Une autre façon de vous fournir des informations (que ce soit dans la réalité ou dans un
examen) : on vous donne les documents (formulaires, bordereaux…) utilisés par l’entre-
prise. Bien entendu, les informations que contiendront ces formulaires deviendront des
données. Je ne vais pas faire un cours sur l’historique du système d’information de l’en-
treprise. Disons juste en quelques mots qu’il est assez intuitif que l’entreprise ne se dote
pas du jour au lendemain de formulaires, de bordereaux… Ces documents viennent petit
à petit, en fonction des besoins. Non seulement ils sont réalisés de façon informelle, mais
en plus les données nécessaires à l’entreprise peuvent évoluer. Ceci fait qu’assez souvent,
ces documents contiennent des données inutiles, ou, au contraire, on leur greffe des
Post-it car il manque des informations. On observe par exemple que depuis quelques
années, les entreprises demandent volontiers aux clients leurs adresse email ou leur
numéro de portable. Cette nouveauté vient du développement de ces deux médias.
L’analyste doit donc étudier très attentivement les documents pour les « remettre à
plat », à savoir vérifier avec les utilisateurs quelles données manquent ou sont inutiles. Il
pourra être amené à concevoir de nouveaux imprimés par exemple.
On remarque en passant un rôle très important de l’informatique : elle structure. En
effet, un programme fonctionne selon des règles fixes. L’analyste doit donc formaliser
parfaitement les données et les traitements de l’entreprise, ce qui permet en général de
corriger beaucoup de travers apparus au fil du temps (travail fait deux fois, par exemple
saisie de la commande puis de la facture alors que les deux ont beaucoup d’informations
en commun, documents incomplets…).
Il faut ensuite que l’analyste justifie les changements éventuels qu’il propose… et là, il
faut de la diplomatie.
Exercice 66
Allez, à vous ! Faites-moi le dictionnaire des données du sujet suivant :
Plusieurs kinésithérapeutes se sont regroupés en un cabinet de kinésithérapie. Chacun d’eux
est identifié par un numéro identifiant attribué par le ministère de la Santé. Ils ont un nom,
un prénom.
On retiendra les nom, prénom et téléphone de chaque patient, ainsi que la date de
l’ordonnance du médecin prescrivant les séances de kinésithérapie.
Détermination du type des données

Deuxième étape : après le recensement des données, on va déterminer leur type de la
façon la plus précise possible.
On va rajouter une colonne contenant ce type. Cela sera utile lors de la création du
programme. Mais cela, vous le savez puisqu’en parallèle de ce cours d’analyse, vous
suivez également le cours de programmation où l’on a dû vous briefer longuement sur
la nécessité du typage des données. Sans refaire le cours de programmation ici, je vous
rappellerai que l’ordinateur code de façon différente une date, une chaîne de caractères,
131
8 3932 TG PA 01
Séquence 8
un chiffre, un nombre réel… car tout doit être stocké sous la forme de 0 et de 1 (les bits).
Bref, la même valeur binaire 11101011 peut représenter n’importe quel type de donnée :
un chiffre, mais aussi un caractère, des booléens… Pour savoir comment décoder ce nom-
bre binaire, il faut connaître le type de la donnée sous-jacente.
« Oh là ! » allez-vous me dire, « cela ne semble pas très conceptuel, ici on est très proche
de l’ordinateur ». C’est vrai. D’ailleurs, le type des données ne sera plus utilisé jusqu’à la
programmation. Mais il convient néanmoins de le déterminer dès à présent car :
1. Le type peut donner des informations sémantiques sur la donnée, notamment sur
son élémentarité. Par exemple, le numéro de Sécurité sociale peut être considéré
comme un nombre de 15 chiffres ou un nombre de 13 chiffres (le numéro lui-
même) plus un de 2 chiffres (la clé).
2. Cela permet de faire disparaître le réel : l’informaticien n’aura pas besoin de ques-
tionner les membres de l’entreprise pour déterminer le type des données, tout sera
déjà dans le dictionnaire.
Pour avoir le maximum d’informations, on mettra le type de la donnée, suivi entre
parenthèses de sa longueur. Le type des données sera assez classique. Les différentes
possibilités sont reprises dans le tableau suivant.
TYPE DE DONNÉES DESCRIPTION EXEMPLES DE DONNÉES DE CE TYPE

alphabétique (n) que des lettres (n caractères) nom, prénom, ville
alphanumérique (n) lettres et chiffres (n caractères) référence, adresse
des nombres (n chiffres dont m prix d’achat, taux de TVA, nombre d’articles
numérique (n,m)
décimales) commandés
date bah… une date, quoi date d’achat, date d’embauche…
toute propriété qui vaut vrai ou faux (ou oui ou non).
booléen vaudra soit oui, soit non
Par exemple : marié, emprunté…
La longueur des données est une notion assez floue :

• pour le numéro de Sécurité sociale, par exemple, on sait qu’il est codé sur 15 chiffres ;
• en revanche, le nom des personnes… va-t-on prendre 20 lettres ? 30 ? Cela a peu
d’importance (enfin, il vaut mieux en prendre trop que pas assez !) ;
• une somme d’argent sera toujours un réel avec deux décimales et… combien de
chiffres ? Si l’on estime que l’on n’aura jamais de somme supérieure à un million,
la somme la plus grande sera 999 999,99 soit 8 chiffres dont 2 après la virgule, soit
(8,2). Mais si l’on informatise une banque, on doit prévoir des montants plus impor-
tants !
Il ne faut pas faire le malin et n’utiliser strictement que les quatre types ci-dessus. Si
O vous vous doutez que vous allez utiliser un outil tel Access pour l’informatisation,
n’hésitez pas à être plus précis dans les types de donnée pour exploiter tous ceux
d’Access (par exemple le type monétaire qui est un réel à deux décimales). Cela
est d’autant plus vrai que l’identification précise du type se fera surtout lors de la
création de la base, d’après les choix proposés par les outils (allez voir votre cours
sur Access pour plus de détails).
132
8 3932 TG PA 01
En pratique, si on vous demandait de faire le dictionnaire des données lors de l’examen,

il suffirait d’avoir assez de recul pour :
• distinguer les données littérales des numériques ;
• identifier les données calculées (voir la suite) ;
• mettre des longueurs de donnée plausibles (notamment mettre deux décimales
pour les données monétaires) ;
• c’est tout !
Notons que les informations concernant les types ne sont jamais explicitées dans le sujet,
c’est à vous de les deviner.
Exercice 67
Reprenez le sujet de l’exercice précédent et refaites le dictionnaire en rajoutant et complétant
la colonne Type.
Épuration des données

Enfin une étape intéressante. Je ne vous cache pas que je trouve les deux précédentes
rébarbatives et abrutissantes et que je suis heureux d’aboutir à celle-là. J’aurais pu
appeler cette partie toilettage des données, mais cela faisait trop caniche. Il s’agit ici de
rajouter quelques données et d’en supprimer d’autres. Cette étape correspond au mot
nécessaire dans données nécessaires de la définition du dictionnaire.
1. ON VA RAJOUTER LES DONNEES MANQUANTES.
Quelles peuvent-elles être ? Uniquement les identifiants artificiels qui n’auraient
pas été utilisés dans le monde réel. En effet, j’ai mentionné dans la correction de
l’exercice 66 que toutes les entreprises, même non informatisées, utilisent des réfé-
rences client, des numéros de factures… qui sont des identifiants artificiels déjà
utilisés dans l’entreprise avant votre arrivée. En revanche, un médecin gérant sa
clientèle à la main (avec des petites fiches papier) se suffit d’un classement alpha-
bétique. Si vous informatisiez sa gestion de clientèle, vous devriez donc rajouter un
identifiant artificiel (numéro) pour identifier les patients.
2. ON VA SUPPRIMER LES DONNEES EN TROP.
Il y a deux types de données en trop : les données redondantes et les paramètres.
Les données redondantes :
Plus la taille de l’entreprise est importante, plus elle sera répartie en services qui risquent
d’avoir leur propre vocabulaire, ce qui conduira à utiliser des mots différents pour dési-
gner la même choseå. Par exemple :
• immeuble et copropriété ;
• référence client et numéro clientç ;
• bordereau de livraison et bon de livraison.
å Petite histoire vécue : j’ai informatisé récemment une entreprise de location de panneaux publicitaires. Le
personnel ? Réduit, deux personnes ! Le patron (commercial) et sa femme (secrétaire). Eh bien, suite à mes
questions, ils se sont presque disputés car ils n’arrivaient pas à se mettre d’accord sur un de leur document, le
bail. Et pourquoi ? Car ce que l’un appelait bail, l’autre l’appelait commande et vice-versa. Et ils ne s’en sont
rendus compte qu’à cause d’une question directe de ma part puisque avant, ils n’avaient jamais formalisé ces
documents en les nommant ; chacun lui avait donc donné un nom dans son esprit. Les problèmes de vocabu-
laire ne sont donc pas directement liés à la taille de l’entreprise.
ç Plus haut dans le cours, j’ai plusieurs fois dit référence client et numéro de facture. Normalement,
cela doit être assez pénible à lire et c’était voulu ! Il faudrait utiliser soit référence, soit numéro, mais
pas les deux.
133
8 3932 TG PA 01
Séquence 8
Comme, par la force des choses, vous êtes novice dans l’entreprise, il vous faudra une
vraie réflexion (et des questions qui paraîtront très naïves à vos interlocuteurs) pour
savoir si ces termes sont synonymes ou non.
Les paramètres
Il y a des informations utilisées par le système d’information sans qu’elles fassent partie
des données liées à l’activité de l’entreprise. Par exemple, un taux de TVA, le prix d’un
timbre, l’adresse et le nom de l’entreprise elle-même, le taux de conversion francs/
euros… Ces données sont des paramètres extérieurs à l’activité. On ne les fera pas figurer
dans le dictionnaire (d’ailleurs, quelle entité utiliser dans le MCD ?).
Dans l’application, nous placerons ces paramètres dans une table séparée et non dans
le code source pour des raisons de maintenance. Ils seront modifiables par l’utilisateur.
Certains les mettent donc dans le dictionnaire en arguant qu’ils font partie de l’applica-
tion. Ce n’est pas faux… vous pouvez donc le faire, à condition de bien les distinguer des
données. Sur ce point, c’est affaire de goût.
Lorsque ces paramètres changent, on les mettra à jour sans autre forme de procès. Dans
un programme, ces paramètres s’appellent des constantes.
Remarque importante
Une valeur peut être un paramètre dans un système d’information et une donnée
devenant une propriété dans un autre. Par exemple, si l’entreprise historise ses fac-
tures pour pouvoir les rééditer à la demande, les différents taux de TVA avec leur
évolution légale devront être stockés dans une entité, une association reliant chaque
occurrence de Facture avec l’occurrence de Taux concernée.
Les données calculées

C’est l’ultime étape et il était temps, car cela devient un peu longuetå.
Exercice 68
Les trois données suivantes : Montant_HT, Montant_TTC et Taux_TVA sont-elles liées ? Dit autrement,
peut-on, sans perte d’information, se passer de l’une voire de plusieurs d’entre elles ?
Exercice 69
Même question avec l’ensemble NuméroClient, NomClient, PrénomClient et AdrClient, puis avec
l’ensemble TarifHoraire, DuréeTravail, MontantAPayerHT, TauxTVA et MontantAPayerTTC. Je
ne peux pas vous fournir la sémantique de ces données puisque cela vous donnerait la réponse.
Disons que le deuxième ensemble de données correspond au calcul du montant de la facture du
garagiste qui est payé à l’heure.
å Je reconnais que, si je ne mettais pas des notes de bas de page à tout va, ce serait moins longuet.
Mais c’est mon petit péché mignon !
134
8 3932 TG PA 01
Ces deux exercices tiennent lieu de cours ; on retiendra :

Les données calculées (dont la valeur peut être retrouvée par calcul à partir d’autres
données) sont redondantes et n’ont pas à figurer dans le MCD. En revanche, elles
doivent apparaître dans le dictionnaire des données afin que le programmeur puisse
les calculer !
On rajoutera donc une dernière colonne dans le dictionnaire. Elle contiendra la formule de
calcul de la donnée dans le cas où celle-ci est calculée. La formule devra utiliser les autres
données du dictionnaire puisque, rappelons-le, le dictionnaire doit se suffire à lui-même.
DONNÉE FORMULE SI DONNÉE CALCULÉE COMMENTAIRE TYPE

Montant_HT numérique(8,2)
Montant_TTC Montant_HT * (1+Taux_TVA) numérique(8,2)
Taux_TVA en pourcentage (ex : 19,6) numérique(4,2)
La donnée Montant_TTC étant calculée, elle ne sera pas utilisée dans le MCD. On peut
trouver des présentations de dictionnaire où toutes les données calculées sont regrou-
pées à la fin.
Exercice 70
Que penser de la version suivante ?
DONNÉE FORMULE SI DONNÉE CALCULÉE COMMENTAIRE TYPE

Montant_HT Montant_TTC/(1+Taux_TVA) numérique(8,2)
Montant_TTC Montant_HT * (1+Taux_TVA) numérique(8,2)
Taux_TVA (Montant_TTC/Montant_HT-1)*100 en pourcentage (ex : 19,6) numérique(4,2)
Exercice 71
Faites le dictionnaire des données relatif à la facture du garagiste vu à l’exercice 69 (données
TarifHoraire, DuréeTravail, MontantAPayerHT, TauxTVA et MontantAPayerTTC).
Le fait est que réaliser un dictionnaire est avant tout un travail de copiste assez rébarba-
tif. En revanche, là où il faut être affûté, c’est dans l’étape d’épuration et surtout dans
la recherche des données calculées. En effet, si vous mettez une donnée calculée dans
le MCD, vous serez sanctionné car c’est une erreur de conception. À moins que cela soit
fait exprès, mais, dans ce cas, vous devrez dûment le justifier en expliquant que la redon-
dance est compensée par le gain à l’exécution (moins de traitements à réaliser).
2D. Graphe des dépendances fonctionnelles (graphe des DF)

2D1. Préparation
On part du dictionnaire des données. On établit toutes les dépendances fonctionnelles que
l’on trouve entre les données et, je vous l’assure, ce n’est pas un mince travail. Je vous rappelle
que pour établir ces DF, il faut exploiter la sémantique des données, donc le sujet. On norma-
lise ensuite l’ensemble des dépendances obtenues. On est alors fin prêt pour le graphe.
135
8 3932 TG PA 01
Séquence 8
2D2. Le graphe
On va représenter graphiquement les dépendances sous la forme d’un arbre. C’est élé-
mentaire puisque c’est une simple réécriture des DF. C’est très pénible à faire sur traite-
ment de texte (j’en sais quelque chose), mais à la main… c’est tout simple.
Il n’y a pas vraiment de formalisme : on met les données un peu en vrac sur la feuille et
on tire des flèches entre celles qui sont en DF. Comme pour le MCD, on essaie de placer
les données de telle façon que le graphe ne soit pas trop embrouillé.
Exemple : Supposons les DF suivantes (les lettres A, B… sont des propriétés) :
A"B A"D
B"C B"E
Le graphe correspondant sera :
A B C
B D ou A E
C E D
Bref, on le présente un peu comme on veut. Le premier, présenté verticalement, est pré-
férable car il y a plus de place verticalement qu’horizontalement sur une feuille. L’intérêt
du graphe est de présenter toutes les DF et leurs imbrications sur un même schéma.
Exercice 72
Allez, on va faire un vrai sujet pour s’entraîner.

Nous sommes à la préfecture où nous allons gérer le fichier des voitures. Une voiture est d’une
couleur et d’un type donné. Le type de voiture, appelé type mine, détermine la marque (exemple
Peugeot), le modèle (exemple 205) et la puissance fiscale (exemple 5 cv) du véhicule. La voiture
a une immatriculation.
Comme l’immatriculation change lorsque le propriétaire change de département (déménagement
ou vente de la voiture), on souhaite conserver la date de la dernière immatriculation (donc
l’immatriculation actuelle) et celle de la première immatriculation. Chaque voiture est identifiée
par un numéro de série alphanumérique unique.
Travail à faire
1. Faites le dictionnaire des données épuré.
2. Cherchez toutes les dépendances fonctionnelles engendrées par ces données puis normalisez
l’ensemble des DF.
3. Réalisez le graphe des DF.
4. Oubliez ce que vous venez de faire pour ne pas polluer le travail suivant par des
réminiscences.
5. Faites le MCD (avec la méthode intuitive du début de cours). Il nous permettra de vérifier
notre technique de construction du MCD par les DF.
136
8 3932 TG PA 01
2E. Construction du MCD à partir du graphe

La génération ne doit vous poser aucun problème puisque vous pouvez la faire sans
comprendre en vous contentant d’appliquer aveuglément les règles que je vais vous
donnerå.
2E1. Un peu de vocabulaire

C’est du vocabulaire emprunté à la théorie des graphes… logique, puisque c’est un
graphe !
Feuille : une feuille est une propriété étant cible de DF, mais pas source.
Nœud : un nœud est une propriété étant source de DF.
Intuitivement, les feuilles sont tout en bas du graphe (aux extrémités des DF), et tout ce
qui n’est pas une feuille est un nœud.
Exercice 73
Donnez la liste des feuilles et des nœuds du graphe de l’exercice précédent. La partie qui suit
va nous permettre de construire le MCD à partir du graphe des DF. La technique tient en trois
étapes simples mais dont la formalisation n’est pas évidente. Lors de mes nombreuses relectures
et corrections de ce support, j’ai à chaque fois modifié le texte des étapes qui suivent pour qu’il
corresponde sans ambiguïté à la réalité. L’ennui, c’est que j’ai obtenu des phrases assez denses
où chaque mot compte ! Je vous conseille donc de les lire puis d’étudier l’exemple qui suit avant
de tenter de les apprendre.
2E2. Construction du MCD : cas simple

Partant du graphe, on va identifier les entités puis les associations. Le MCD sera
alors terminé.
1. Les entités
Chaque feuille est par définition cible d’une DF. La source correspondante sera iden-
tifiant d’une entité dont les propriétés seront les feuilles cibles des DF ayant cet
identifiant (et lui seul) en source.
2. Les associations
Les DF entre deux identifiants (repérés dans la première étape) deviennent des
associations [1–n] (cardinalité maximale 1 du côté de la source de la DF, cardinalité
maximale n du côté de la cible).
Les noms des entités et associations identifiées seront à inventer, puisque ces con-
cepts ne figurent pas sur le graphe. De même, les cardinalités minimales devront
être déterminées d’après le sujet ou le monde réel.
å Ce n’est évidemment pas ce que je préconise. J’essaie juste de vous dire de façon diplomatique
que si vous n’arrivez pas à faire le MCD à partir du graphe, ce sera uniquement parce que vous
n’aurez pas appris le cours.
137
8 3932 TG PA 01
Séquence 8
Démonstration : on va travailler sur le graphe des voitures :
NuméroSérie
TypeMine
Immatriculation DateImmat Date1eImmat Couleur
Puissance Modèle Marque
On reprend les deux étapes :

1. Les entités
Chaque feuille est par définition cible d’une DF.
Les feuilles sont d’une part Immatriculation, DateImmat, Date 1°Immat, Couleur et
d’autre part Puissance, Modèle et Marque.
La source correspondante…
Pour les DF de cible Immatriculation, DateImmat, Date 1°Immat, Couleur, la source
est NuméroSérie.
Pour les DF de cible Puissance, Modèle et Marque, la source est TypeMine.
… sera identifiant d’une entité dont les propriétés seront les feuilles cibles des DF ayant
cet identifiant (et lui seul) en source.
Une entité ayant pour identifiant NuméroSérie et pour propriétés Immatriculation,
DateImmat, Date1°Immat et Couleur.
Une entité ayant pour identifiant TypeMine et pour propriétés Puissance, Modèle et
Marque.
Visuellement, voici où nous en sommes :
ENTITÉ VOITURE ENTITÉ TYPE

NuméroSérie TypeMine
Immatriculation DateImmat Date1eImmat Couleur Puissance Modèle Marque
Légende : entité identifiant

En fait, les propriétés les plus extrêmes dans le graphe seront les propriétés, celles juste
au-dessus seront les identifiants.
Notez bien que la première étape précise que seules les feuilles cibles des DF ayant
l’identifiant en source seront les propriétés. TypeMine a beau être cible d’une DF ayant
en source NuméroSérie, il n’est pas une propriété de Voiture car il n’est pas une feuille.
2. Les associations
Les DF entre deux identifiants (repérés dans la première étape) deviennent des associa-
tions [1–n], la cardinalité maximale 1 étant du côté de la source de la DF.
Il s’agit de la DF entre NuméroSérie et TypeMine, la cardinalité maximale 1 étant du
côté de Voiture.
138
8 3932 TG PA 01
Cela donne :
ENTITÉ VOITURE ENTITÉ TYPE

NuméroSérie TypeMine
?,1 être ?,n
Immatriculation DateImmat Date1eImmat Couleur

Puissance Modèle Marque
Eh bien, on a le MCD ! Il n’y a plus qu’à rajouter les cardinalités minimales et à le présen-
ter dans les règles pour obtenir :
VOITURE TYPE
NuméroSérie être 0,n TypeMine
1,1
Couleur Marque
Immatriculation Modèle
DateImmatriculation Puissance
Date1Immatriculation
Vous vérifiez que c’est le même que celui trouvé dans l’exercice précédent.
2E3. Construction du MCD : cas général

On va voir maintenant un cas plus complexe, mettant en œuvre des associations différentes.
Passage des DF au graphe

Le cas précédent ne mettait en œuvre que des dépendances fonctionnelles simples, avec
une propriété cible et une source. Que penser du cas général A, B " C avec plusieurs
propriétés sources ? On doit bien entendu représenter que les deux propriétés A et B
ensemble déterminent C.
Exercice 74
Expliquez pourquoi le graphe suivant ne représente pas A, B " C puis donnez la ou les DF
représentées.
A
C
B
On va représenter A, B " C en faisant partir une flèche de A et une de B, ces deux flèches
se réunissant en une seule partant vers C :
A La barre verticale représente un point d’ancrage pour bien

C visualiser que les deux flèches venant de A et B s’arrêtent et
B sont remplacées par une partant vers C.
Je présente le graphe horizontalement pour gagner de la place… on pourrait mettre A
et B en haut et C en bas, la barre verticale devenant bien entendu horizontale.
139
8 3932 TG PA 01
Séquence 8
Passage du graphe au MCD

Pour faire encore plus général, envisageons la DF A, B, C " D.
Exercice 75
Faites le graphe correspondant (c’est trivial).
La dépendance A, B, C " D peut se traduire de deux façons selon sa position dans le

graphe complet. Elle peut correspondre :
– à une entité ayant pour identifiant la concaténation des trois propriétés A, B et
C. D sera une propriété de cette entité ;
– à une association porteuse de données, A, B, C étant la concaténation des
identifiants des diverses entités reliées et D la donnée portée. Les cardinalités
maximales sont forcément n puisqu’il y a donnée portée.
Cela est valable quel que soit le nombre de propriétés sources. Remarquez que dans le
deuxième cas, on ne peut savoir combien de pattes a l’association car cela dépend de
l’élémentarité des identifiants des entités concernées :
• si les propriétés A, B et C sont chacune identifiant élémentaire d’une entité, l’asso-
ciation est une ternaire ;
• si A, C est l’identifiant (non-élémentaire) d’une entité et B celui d’une autre entité,
on aura une binaire.
Exercice 76
Les DF suivantes sont normalisées ; faites le graphe des DF.
NuméroProduit " NuméroTypeProduit NuméroFacture " MontantHT
NuméroFacture " DateFacture NuméroFacture " MontantTTC
NuméroFacture " DatePaiement NuméroFacture, NuméroProduit " Quantité
NuméroProduit " LibelléProduit NuméroProduit " PrixHT
NuméroTypeProduit " LibelléTypeProduit
Exercice 77
En partant du graphe de l’exercice précédent, faites le MCD en prenant soin de justifier ce qui
n’est pas directement issu du graphe (par exemple, les cardinalités minimales).
Exercice 78
Avoir le MCD, c’est avoir la liste des données du système d’information, mais aussi la sémantique.
Pouvez-vous me donner la description du réel en français du MCD établi dans l’exercice
précédent ?
Rien n’est jamais parfait

Il y a deux choses que le graphe des DF ne traduit pas :
• d’une part les cardinalités minimales, ainsi que nous l’avons vu. Mais ce n’est pas
important car elles se trouvent aisément ;
140
8 3932 TG PA 01
• les associations [n–n] non porteuses. Eh oui, les porteuses sont détectées par une DF
vers la propriété portée. Donc une association non porteuse n’engendre aucune DF.
Il est donc obligatoire de consulter le réel pour rechercher les liens (on ne peut pas
dire dépendances) entre les entités identifiées dans le graphe.
3. Formes normales et MLD

Souvenez-vous des formes normales (faites éventuellement une relecture rapide du
paragraphe 1C). Je vous avais dit que les formes normales sont habituellement utilisées
vis-à-vis du MLD. Nous allons donc les revoir brièvement.
En tout cas, n’oubliez pas l’intérêt des formes normales : s’assurer que notre MLD (ou
MCD) ne possède pas d’erreur grave vis-à-vis de l’identifiant.
Notons dès à présent que le MLD est en ie forme normale si l’ensemble des tables sont
en ie forme normale.
3A. Première forme normale

Une table sera en première forme normale si tous les champs dépendent fonctionnel-
lement de la clé primaire et sont élémentaires.
3B. Deuxième forme normale

Une table sera en deuxième forme normale si :
– tout champ non clé primaire est en dépendance fonctionnelle élémentaire avec
la clé primaire.
3C. Troisième forme normale

Une table sera en troisième forme normale si :
– il n’y a pas de dépendance fonctionnelle entre champs non clé primaire.
Je vous avoue que je ne me suis pas trop fatigué : grâce aux fonctionnalités classiques
des traitements de textes (ici, le copier/coller), j’ai recopié les définitions données dans
le paragraphe 1C. en remplaçant entité par table, propriété par champ et identifiant
par clé primaire. Si je vous dis cela, ce n’est pas pour vanter mon talent de réutilisation,
mais surtout pour bien vous faire prendre conscience que la notion de forme normale
est absolument identique, que l’on soit en MCD ou en MLD.
Bien entendu, pour pouvoir étudier la normalisation d’un MLD, il faut connaître la
sémantique des différents champs pour savoir s’ils dépendent les uns des autreså.
Un petit exercice sera suffisant pour valider cela.
å J’avais déjà fait cette remarque lors du cours sur les dépendances fonctionnelles.
141
8 3932 TG PA 01
Séquence 8
Exercice 79
Considérons ce MLD :
Prénom (Prénom)
Porter (NuméroPersonne#, Prénom#, rang)
Indiquez en quelle forme normale il est.
Notons que, comme dans beaucoup de points déjà abordés, les règles édictées ici sont
très strictes, mais peuvent être violées sans complexe… quand cela est justifié.
La gravité est une loi physique que l’on ne peut violer. En revanche, les règles étudiées
ne sont là que pour ne pas faire d’erreur. Si l’on justifie précisément le non-respect des
règles, c’est acceptable ; on parlera alors de dénormalisation. Si l’on ne justifie pas, c’est
bien entendu une erreur.
Exercice 80
En quelle forme normale le MLD suivant est-il ?
Personne (NuméroPersonne, Nom, Prénom, NumSécu, Adresse, Ville)
Service (NuméroService, LibelléService)
Travailler (NuméroPersonne#, NuméroService#, DateEntréeService)
Vous pouvez, dès maintenant, faire et envoyer à la correction le devoir 2 (voir fasci-
cule « devoirs » réf. 3932 DG).
142
8 3932 TG PA 01
Synthèse
Les formes normales

L’entité ou l’association sera en première forme normale si toutes les propriétés
dépendent fonctionnellement de l’identifiant et sont élémentaires. Une entité
ou association sera en deuxième forme normale si :
• elle est en première forme normale et
• toute propriété non identifiant est en dépendance fonctionnelle élémen-
taire avec l’identifiant.
Une entité ou association sera en troisième forme normale si :
• elle est en deuxième forme normale et
• il n’y a aucune dépendance fonctionnelle entre deux propriétés non iden-
tifiant.
Une entité ou association doit être en troisième forme normale, à savoir : les
propriétés, élémentaires, dépendent de l’identifiant (1re FN), de tout l’identifiant
(2e FN) et que de l’identifiant (3e FN).
Dictionnaire des données

Il regroupe l’ensemble des données élémentaires (nom, type…) constituant le
système d’information.
Les données calculées (dont la valeur peut être retrouvée par calcul à partir
d’autres données) sont redondantes et n’ont pas à figurer dans le MCD. En
revanche, elles doivent apparaître dans le dictionnaire des données afin que le
programmeur puisse les calculer !
Graphe des DF et création du MCD

Feuille : une feuille est une propriété étant cible de DF, mais pas source.
Nœud : un nœud est une propriété étant source de DF.
Les propriétés sont donc soit des feuilles (aux extrémités du graphe), soit des nœud.
Pour construire le MCD, on va partir du graphe et identifier les entités puis les
associations.
1. Les entités
Chaque feuille est par définition cible d’une DF. La source correspondante sera
identifiant d’une entité dont les propriétés seront les feuilles cibles des DF ayant
cet identifiant (et lui seul) en source.
2. Les associations [1–n]
Les DF entre deux identifiants (repérés dans la première étape) deviennent des
associations [1–n] (cardinalité maximale 1 du côté de la source de la DF, cardina-
lité maximale n du côté de la cible).
3. Les associations [n–n] porteuses
La dépendance A, B, C " D peut se traduire de deux façons selon sa position dans
le graphe complet. Elle peut correspondre :
• à une entité ayant pour identifiant la concaténation des trois propriétés A,
B et C. D sera une propriété de cette entité ;
143
8 3932 TG PA 01
Séquence 8
• à une association porteuse de données, A, B, C étant la concaténation des

identifiants des diverses entités reliées et D la donnée portée. Les cardinalités
maximales sont forcément n puisqu’il y a donnée portée.
Ce qui ne figure pas dans le graphe et reste à votre charge :
• les noms des entités et des associations identifiées ;
• les cardinalités minimales ;
• les associations [n–n] non porteuses. Attention à ne pas en oublier !
Formes normales
Une table sera en première forme normale si tous les champs dépendent fonction-
nellement de la clé primaire et sont atomiques.
Une table sera en deuxième forme normale si :
– tout champ non clé primaire est en dépendance fonctionnelle élémentaire
avec la clé primaire.
Une table sera en troisième forme normale si :
– il n’y a pas de dépendance fonctionnelle entre champs non clé primaire.
144
8 3932 TG PA 01
Travaux dirigés 3
Je vous le dis une dernière fois : pour profiter de ces exercices, vous devez
maîtriser le cours ! Nous allons travailler sur le dictionnaire des données et
les dépendances fonctionnelles. Essayez donc de ne pas raisonner en termes
d’entités et d’associations car cela tuerait l’exercice ! Dans chaque exercice,
je vous demanderai le dictionnaire des données, les DF, le graphe des DF et
enfin le MCD. N’hésitez pas à consulter le corrigé à chaque étape ! Si vos don-
nées sont fausses, le reste de l’exercice ne donnera pas grand-chose.
Exercice 1
Une entreprise loue des panneaux publicitaires. Un panneau est identifié par une référence,
une surface, une localisation (près du lavoir d’Houdemont, à la sortie d’Orléans direction
Paris…) et un nombre de faces.
Une location est faite par un client (caractérisé par les propriétés habituelles) ; elle possède
une date d’effet (date de début) et une durée en années (maximum trois ans). Le loyer est
calculé et payé annuellement. Il peut varier selon l’année de location. Les montants des
loyers annuels sont fixés dès la signature. Les loyers supportent la TVA.
Une location porte sur un ou plusieurs panneaux. En revanche, un panneau n’est loué qu’à
un seul client. On n’historise pas les anciennes locations des différents panneaux.
Travail à faire
1. Faites le dictionnaire des données épuré.
2. Recensez les dépendances fonctionnelles et établissez le graphe des dépendances fonc-
tionnelles.
3. Déduisez-en le MCD.
4. Que se passerait-il si les baux n’étaient plus triennaux mais décennaux (dix ans) ? Je ne
vous demande pas de refaire tout l’exercice, mais juste d’indiquer les changements en
quelques phrases.
Exercice 2
Finalement, ne pas historiser les contrats n’est pas une super idée. En effet, pour des raisons comp-
tables élémentaires, on veut conserver les différentes locations et les loyers correspondants.
Les règles du jeu changent donc ; je rajoute les deux petites phrases suivantes :
On doit historiser les locations pour les différents panneaux. Un annonceur ne peut jamais
louer deux fois un même panneau.
Travail à faire
Eh bien, on recommence !
1. Faites le dictionnaire des données épuré des nouvelles données (inutile de tout repren-
dre, complétez éventuellement le dictionnaire de l’exercice précédent).
145
8 3932 TG PA 01
Séquence 8
2. Recensez les nouvelles dépendances fonctionnelles et modifiez le graphe des dépendan-

ces fonctionnelles en conséquence.
3. Déduisez-en le nouveau MCD.
Exercice 3
Hum ! J’espère que le thème des exercices précédents vous plaît, car nous allons encore tra-
vailler dessus.
Il apparaît que notre description de la réalité était trop simpliste. En effet, un client peut bel
et bien louer plusieurs fois le même panneau. Comme la durée du bail est au maximum de
trois ans, le client satisfait de sa publicité doit faire un nouveau bail de location pour con-
server le panneau.
Travail à faire
Dois-je vous dire ce qu’il faut faire ?
1. Faites le dictionnaire des données épuré des nouvelles données (inutile de tout
reprendre, complétez juste le dictionnaire de l’exercice précédent).
2. Recensez les nouvelles dépendances fonctionnelles et modifiez le graphe des
dépendances fonctionnelles en conséquence.
3. Déduisez-en le nouveau MCD.
Exercice 4
Je vous promets que c’est le dernier exercice sur la location de panneau. Reprenons le sujet
de l’exercice précédent : nous sommes donc toujours dans le cadre de travail où un client
peut louer plusieurs fois le même panneau.
Mais bon, soyons honnêtes : la réalité est un peu moins simple. En effet, un panneau pouvant
avoir deux faces, on peut y mettre deux publicités différentes vantant les mérites de deux
annonceurs différents. De plus, pour certains gros panneaux, la surface d’affichage de chaque
face peut être partagée par plusieurs annonceurs. Par exemple, une des faces peut vanter les
cuisines X, tandis que l’autre face possède une grosse publicité pour le restaurant Y et une
petite pour le magasin Z. Comme le loyer payé est proportionnel à la surface occupée, il faut
avoir le pourcentage d’occupation de chaque publicité. Ainsi, on pourra dire que la publicité
de X occupe 100 % d’une face, tandis qu’Y et Z occupent respectivement 75 et 25 % de l’autre.
Vous remarquerez que chaque face est occupée au mieux à 100 %. Bien entendu, il y a peu de
chances que les différentes surfaces d’un panneau soient louées en même temps.
En pratique, un même panneau peut faire l’objet d’une (petit panneau simple face) ou plu-
sieurs (gros panneau, double face) locations ayant des caractéristiques différenteså.
å Je ne suis pas sûr d’être très clair. C’est exactement le principe de l’immobilier : l’immeuble
représente le panneau, les appartements les différentes surfaces d’adressage prévues sur le pan-
neau. Les différents baux de location d’appartement sont totalement indépendants les uns des
autres ; eh bien, c’est pareil avec les locations d’espaces publicitaires.
146
8 3932 TG PA 01
Ainsi, dans notre exemple, le contrat de :

– X a commencé le 14/07/2007 pour une durée de 1 an ;
– Y a commencé le 23/02/2006 pour une durée de 3 ans ;
– Z a commencé le 11/11/2007 pour une durée de 1 an.
Bien entendu, les différents loyers sont négociés entre l’annonceur et l’entreprise de publi-
cité. À qualité d’affichage égale, on peut avoir une face louée 10 000 €/an et l’autre louée
8 000 € si le client a mieux négocié ! Et, comme toujours, les loyers annuels sont déterminés
dès la signature du contrat de location. Un annonceur ne loue jamais en même temps les
deux faces d’un même panneau. Ah ! Il existe bien entendu un document matérialisant la
location. Chaque exemplaire porte un numéro de location.
Travail à faire
1. Mon sujet donne des exemples, explique en détail… tout ceci est un peu touffu !
Essayez de réécrire tout cela de façon plus condensée. Il s’agit de synthétiser la réalité
décrite en quelques phrases bien senties. Ces phrases vous permettront de faire la suite
de l’exercice plus facilement. En d’autres termes, vous devez réécrire le sujet.
2. Faites le dictionnaire des données nouvellement apparues ; inutile donc de reprendre
toutes les données de l’exercice 1 !
3. Donnez les nouvelles dépendances fonctionnelles.
4. Complétez le graphe acteurs/flux de l’exercice précédent pour prendre en compte ces DF.
5. Mettez à jour le MCD.
Exercice 5
Bon, nous allons changer de thème. Notre entreprise ne loue plus les panneaux, elles les
vend. Non, je plaisante. Elle les fabrique. Bon, j’arrête !
La SNCF vous demande de réaliser l’analyse de sa gestion des trains. Un point de l’analyse
vous posant problème, vous décidez d’utiliser la technique de la conception par les DF. Voici
ce que vous avez du mal à modéliser :
Un train (numéro, type (TGV…), à supplément ou non) est constitué de wagons. Chaque
wagon est décrit par son type (wagon restaurant, couchette, 1re classe, 2e classe…), son
numéro, sa date de fabrication et ses places. Dans chaque wagon, les places sont numérotées
en partant de 1. Une place possède différentes caractéristiques (couloir ou fenêtre, sens du
déplacement ou non, fumeur ou non, compartiment ou non).
Travail à faire
1. Le dictionnaire des données.
2. Les DF puis le graphe.
3. Le MCD.
Exercice 6
Qu’est-ce qui regarde passer les trains ? Les vaches ! Eh bien, intéressons-nous à l’élevage
raisonné de ce sympathique ruminant.
147
8 3932 TG PA 01
Séquence 8
Un éleveur souhaite informatiser la gestion de la généalogie de son cheptel. Voici l’analyse

que vous avez écrite :
Un animal possède un identifiant vétérinaire et est d’une race donnée. Il a également un
nom donné par l’éleveur qui les distingue ainsi plus facilement. Tout animal possède une
date de naissance, une date et une cause de décès (maladie, accident, abattoir…), un sexe et
une qualité (fier animal, quelconque, vache de jardin). Les animaux ont un père (un taureau)
et une mère (une vache). Il peut arriver qu’un ou les deux parents d’un animal ne soient pas
connus. Comme il y a des soins et des contrôles très précis à faire selon l’âge de l’animal,
l’éleveur veut également avoir l’âge en mois de chaque bête.
Travail à faire
1. Le dictionnaire des données.
2. Les DF puis le graphe.
3. Le MCD.
Exercice 7
Je vous propose un exercice sur un thème original. Faites-le sérieusement !
Nous allons modéliser Merise. Eh oui ! Plus particulièrement le MCD. À quoi cela peut-il ser-
vir ? Supposons que vous vouliez automatiser vos productions de MCD. Pour cela, vous allez
écrire un programme permettant de dessiner les MCD à l’écran. En fait, vous voulez écrire
l’équivalent de PowerAMC (ex AMC*Designor). Pour pouvoir faire cela, vous devez formali-
ser le MCD. Et, pour le formaliser, vous pouvez en faire le MCD !
Attention, notez bien que pour simplifier le sujet, nous posons les restrictions suivantes :
1. Nous ne tiendrons pas compte des entités faibles.
2. Nous ne tiendrons pas compte des associations réflexives.
3. Nous supposerons que les identifiants d’entité sont atomiques.
4. Nous accepterons que des propriétés soient utilisées plusieurs fois dans le MCD. Cette
contrainte viole les règles du cours, donc nous ne l’admettrons que pour simplifier tem-
porairement le sujetå.
Travail à faire
1. Sans lire ce qui suit, réfléchissez aux différents constituants du MCD et essayez de les
décrire comme si vous deviez écrire un sujet d’analyse. Ainsi, au lieu de décrire ce qui
caractérise un client, décrivez ce qui caractérise une entité et tout le reste ! Quand vous
penserez avoir fini, vous lirez la suite.
Normalement, vous avez dû avoir beaucoup de mal. Je vous avoue que moi, en tout cas, j’en
ai eu. En effet, nous devons réfléchir sur des concepts qui nous sont maintenant familiers, ce
qui ne devrait pas poser de problème. Mais nous devons y réfléchir d’une façon tout à fait
inhabituelle. Et là, on se mélange un peu les pinceaux. Voici ce que je vous propose :
Une entité est décrite par son nom, un identifiant et des propriétés. Une propriété est décrite
par son nom. Une association est décrite par son nom, ses cardinalités et les entités qu’elle
relie. Elle possède un identifiant (la concaténation des identifiants des entités reliées) et peut
être porteuse de données.
å D’après mon cours, on doit avoir unicité de la propriété. Les programmes comme PowerAMC
interdisent d’utiliser deux fois la même propriété… mais autorisent deux propriétés différentes
de même nom. Donc concrètement autorisent la duplication de propriétés.
148
8 3932 TG PA 01
Il y a différentes formulations possibles. Conservez la mienne pour que ma correction des

questions suivantes puisse vous servir.
Travail à faire
2. La description du réel est terminée ; elle paraît assez simple. Mais de là à faire le MCD
directement… je crains que l’on doive faire une entité Association. Vous aussi, vous
trouvez que c’est un peu trop abstrait ? Alors, cette fois, nous allons pouvoir réellement
utiliser l’approche par les DF car l’approche classique n’est pas aisée. Comme première
étape, faites le dictionnaire des données.
3. Les dépendances fonctionnelles, je vous prie.
4. Le graphe des DF, hop, et que cela saute.
5. Bon, le MCD, il vient ?
Exercice 8
On reprend le sujet de l’exercice précédent en interdisant qu’une propriété soit utilisée plu-
sieurs fois dans le MCD. La contrainte violant le cours disparaît…
Travail à faire
1. Dictionnaire des données.
2. Dépendances fonctionnelles.
3. Graphe des DF.
4. MCD.
Exercice 9
Nous allons travailler sur une formulation un peu différente de celles des deux exercices
précédents.
Précédemment, nous avions dit qu’une entité possédait un identifiant d’une part et des pro-
priétés d’autre part. Maintenant, on va dire qu’une entité possède des propriétés d’une part
et qu’une propriété peut être identifiant d’autre part. Le changement n’est pas flagrant…
réfléchissez néanmoins, car nos DF et tout ce qui en découle va être changé.
Pour mettre un peu de piment à cet exercice, je vais rajouter une petite chose. Dans le cours,
je vous ai dit que l’entité était écrite en mettant l’identifiant souligné en premier puis la liste
des propriétés dans un ordre quelconque. Bon, si l’ordre est quelconque, je veux néanmoins
pouvoir le définir moi-même : par exemple, j’ai l’habitude de faire une entité Client ainsi :
CLIENT
NuméroClient
NomClient
PrénomClient
AdrClient
CodeClient
VilleClient
TélClient
149
8 3932 TG PA 01
Séquence 8
Je ne veux pas, sous prétexte que l’ordde importe peu, mon programme de modélisation de
MCD m’affiche l’entité comme cela :
CLIENT
NuméroClient
CodeClient
NomClient
AdrClient
TélClient
VilleClient
PrénomClient
Travail à faire
1. Sans lire cette noteå, contenant la solution, dites-moi quoi rajouter pour pouvoir très
simplement définir l’ordre dans lequel je veux voir mes données.
Avec tout cela, la nouvelle description du réel est la suivante :
Une entité est décrite par son nom et ses propriétés qui ont toutes un rang d’affichage. Une
propriété est décrite par son nom ; elle peut être identifiant. Une association est décrite par son
nom, ses cardinalités et les entités qu’elle relie. Elle possède un identifiant (la concaténation
des identifiants des entités reliées) et peut être porteuse de données (chaque donnée ayant
un rang d’affichage). Une propriété n’est utilisée qu’une fois dans un MCD.
2. Faites le dictionnaire des nouvelles données par rapport à l’exercice précédent.
3. Établissez les nouvelles dépendances fonctionnelles.
4. Déduisez-en le graphe des DF.
5. Faites le MCD.
Exercice 10
Nous reprenons l’exercice 6. Revoici donc nos sympathiques ruminants à l’honneur ! Je sou-
haite recommencer le principe des trois exercices précédents : montrer que c’est le sujet qui
détermine le MCD final quand on utilise l’approche par les DF.
Je ne change que la phrase sur les parents (le nouveau texte est en gras).
Un animal possède un identifiant vétérinaire et est d’une race donnée. Il a également un
nom donné par l’éleveur qui les distingue plus facilement. Tout animal possède une date
de naissance, une date et une cause de décès (maladie, accident, abattoir…), un sexe et une
qualité (fier animal, quelconque, vache de jardin). Les animaux ont deux parents. Un des
parents est le père, l’autre la mère. Il peut arriver qu’un ou les deux parents d’un animal
ne soient pas connus. Comme il y a des soins ou des contrôles très précis à faire selon l’âge de
l’animal, l’éleveur veut également avoir l’âge en mois de chaque bête.
Travail à faire
1. Dictionnaire des données.
2. Dépendances fonctionnelles.
3. Graphe des DF. @
4. MCD.
å La solution est très simple : il suffit de donner un rang à chaque propriété dans l’entité ou
l’association. Les propriétés seront alors affichées selon leur rang.
150
8 3932 TG PA 01
Séquence 9
Graphe acteurs/flux
Le cours sur le MCD est définitivement terminé. Nous allons maintenant étudier
un graphe permettant d’appréhender de façon synthétique la circulation de l’in-
formation dans l’entreprise, ce qui est une aide précieuse pour comprendre son
fonctionnement.
• Maîtriser les notions d’acteurs et de flux
• Comprendre le rôle d’un graphe acteur/flux
• Savoir réaliser un graphe acteur/flux
Contenu
1. Introduction .......................................................................................... 152
2. Graphe acteurs/flux ......................................................................... 152
2A. Justification .............................................................................................. 152
2B. Un exemple .............................................................................................. 153
2C. Les acteurs ............................................................................................... 154
2D. Les flux ..................................................................................................... 156
2E. Graphe acteurs/flux ................................................................................. 157
3. Conclusion ............................................................................................ 163
Synthèse
151
8 3932 TG PA 01
Séquence 9
1. Introduction
Le grapheå acteurs/flux présente, comme son nom l’indique, les acteurs de l’entreprise
et les flux de documents qu’ils s’échangent. Il matérialise donc la circulation de l’infor-
mation dans l’entreprise.
C’est un outil utile, permettant d’appréhender de façon globale les documents qui circulent.
Cela permet de se faire une idée assez précise du mode de fonctionnement et d’organisation
du système que l’on va informatiser. Il vous permet également de recenser les documents,
ce qui sera utile pour ne pas en oublier lors de l’étude des données (MCD). Le graphe est un
document assez informel qui fait partie du cycle de modélisation des traitements. On le créera
au cours des entretiens avec les responsables de l’entreprise, avant toute ébauche de MCD.
2. Graphe acteurs/flux
2A. Justification
Le graphe acteurs/flux met en évidence… des acteurs et des flux. De façon informelle,
on précisera que :
• par acteurs, on sous-entend acteurs (intervenants) dans le système d’information ;
• par flux, on sous-entend flux (déplacement) d’informations au sein du système
d’information.
Comment appréhender de façon globale le fonctionnement de l’entreprise et son sys-
tème d’information ? En examinant les documents, en questionnant les membres de
l’entreprise, vous obtenez une vision structurée des données qui aboutira au MCD. Ce
MCD vous fournit-il une connaissance entière de l’entreprise ? Non ! Vous comprenez les
données manipulées, mais vous ne savez toujours pas comment elles le sontç.
Il n’est pas pensable de raisonner en entités et associations du MCD pour aller voir cha-
que service ou personne de l’entreprise et lui demander si elle intervient sur ces concepts.
En effet, les notions du MCD lui sont propres et un non informaticien aura d’autant plus
de mal à les percevoir qu’il aura, en temps que membre de l’entreprise, une structuration
différente en tête.
Imaginez la gestion des permis de construire : là où l’employé verra un formulaire de
demande, vous verrez plutôt les entités Terrain, Propriétaire et Permis, reliées par les liens
délicats des associations. Non, décidément, cette approche par les concepts du MCD n’est pas
envisageable. C’est vous qui entrez dans l’entreprise, c’est donc à vous de vous adapter.
å On emploie les deux termes graphe et diagramme. Après étude approfondie du dictionnaire,
graphe me semble plus approprié.
ç En réalité, c’est inexact car en interrogeant les divers intervenants de l’entreprise, vous avez
mélangé les questions portant sur les données et les traitements pour avoir la vue la plus globale
possible, sachant que, dans un premier temps, seules les informations liées aux données vous ser-
viront. Et il n’est pas question de jouer au schizophrène en ayant une personnalité qui s’occupe des
données et l’autre des traitements !
152
8 3932 TG PA 01
Graphe acteurs/flux
La solution est de raisonner sur les informations échangées dans l’entreprise en utili-
sant sa structuration (appel téléphonique, courrier électronique, imprimé, bon de com-
mande…). Notons que toutes ces informations constituent le système d’information de
l’entreprise ; elles seront réorganisées pour produire le MCD. Mais, alors que le MCD
est un document très codifié à destination des informaticiens, il s’agit juste ici de savoir
comment fonctionne l’entreprise.
Nous n’en sommes pas encore à demander concrètement à la secrétaire (ou au ser-
vice facturation, selon la taille de l’entreprise) comment elle gère les relances pour les
impayés : cela ne sera utile que lors de l’étude précise des traitements, pour savoir ce que
fait l’entreprise et surtout comment elle le fait.
Ici, on veut savoir comment l’information circule. On va donc identifier les différentes
informations (flux), ainsi que les groupes (acteurs) qui les émettent et les reçoivent. Et
on modélisera cela dans le graphe acteurs/flux.
À quoi cela nous servira-t-il ? À mieux appréhender le fonctionnement de l’entreprise.
De plus, si vous voulez savoir de quelle façon un document est rempli ou exploité (selon
quelles règles de gestion), vous irez voir la personne ou le groupe qui l’a généré.
Prenons une métaphore : le médecin s’intéresse au corps humain. Une des approches
pour le comprendre est d’étudier la circulation du sang : d’une part les organes qui
l’émettent et le reçoivent (les acteurs), d’autre part le type de sang : oxygéné ou non…
(les flux).
2B. Un exemple
Le graphe acteurs/flux est d’une simplicité sans commune mesure avec le MCD. Le plus
long est en fait de le dessiner !
Cela dit, la difficulté pour vous est de bien cibler son rôle et sa nature et de prendre
conscience des concepts qu’il utilise, radicalement différents de ceux du MCD.
Voici sans plus attendre un exemple simpliste de graphe acteurs/flux :
1. Demande d’informations
service
client
commercial
2. Catalogue
Voilà ce que nous apprend ce graphe :

• il y a deux acteurs, le client et le service commercial. Le client est un acteur externe
(cela est symbolisé par les pointillés), le service commercial est un acteur interne.
Bien entendu, un graphe possédera généralement plusieurs acteurs internes et
plusieurs externes ;
• il y a deux flux d’information numérotés chronologiquement :
– le premier est la demande d’informations, allant de l’acteur client vers l’acteur
service commercial,
– le second est le catalogue, allant de l’acteur service commercial à l’acteur client.
153
8 3932 TG PA 01
Séquence 9
De cet exemple, on peut déjà tirer les enseignements suivants :

• il y a deux types d’acteurs (internes et externes) ;
• un acteur peut être une personne (ex. : un client) ou un ensemble de personnes
(ex. : le service commercial) ;
• les acteurs sont identifiés par leur fonction dans l’entreprise (le client, la secrétaire,
l’atelier…) ;
• les flux sont ordonnés chronologiquement ;
• chaque flux est produit par un acteur à destination d’un autre acteur.
Exercice 81
Expliquez la différence entre un acteur interne et un acteur externe. Ce devrait être assez
simple si vous identifiez vis-à-vis de quoi l’acteur est interne ou externe. Inspirez-vous de
l’exemple précédent.
2C. Les acteurs

Une petite définition :
Acteur : un acteur (sous-entendu du système d’information) est constitué d’une ou
plusieurs personnes regroupées par leur fonction dans ce système. Il est identifié
par son nom.
Étudions cela d’un peu plus prèså :
« acteur du système d’information »
C’est un truisme dans mon cours : on ne parle pas d’acteur dans l’absolu, mais d’acteur
dans un système d’information donné.
« une ou plusieurs personnes regroupées par leur fonction »
On agrégera dans un groupe toutes les personnes ayant la même fonction dans l’en-
treprise. La notion de groupe est au sens large, puisqu’il peut contenir une ou plusieurs
personnes selon la taille de l’entrepriseç… On considérera aussi qu’une entreprise ou
organisme tiers (caisse de Sécurité sociale, Police…) constitue un acteur. En fait, seuls les
objets ne peuvent être des acteurs.
« leur fonction dans ce système »
Comme pour le MCD, on ne modélise que le système considéré et pas le monde entier.
Si on modélise l’activité d’un grossiste, on aura ses clients (entreprises) comme acteurs,
mais pas les clients de ses clients.
å J’avais commencé par écrire « un acteur est une entité du système définie par sa fonction ». Mais
j’ai changé cette définition car j’avais peur des confusions : il ne s’agit pas du tout de la notion
d’entité du MCD. Cela m’a d’ailleurs permis de préciser qu’un acteur était forcément humain
(entité humaine, cela faisait un peu trop science-fiction).
ç Oserais-je ? Allez… un groupe contient 1,n personnes !
154
8 3932 TG PA 01
Graphe acteurs/flux
« identifié par son nom »

On identifiera l’acteur par son nom et non par sa fonction ; ainsi, on ne dira pas livraison,
mais service livraison ou livreur. C’est plus poli et plus cohérent par rapport à la notion
d’acteur.
Il ne s’agit pas forcément de prendre l’organigramme de l’entreprise à la recherche de
groupes fonctionnels : on ne prendra que les groupes ayant une fonction précise dans le
système que l’on étudie, qui peut être un sous-système (une partie) de l’entreprise.
On va voir maintenant la réponse à l’exercice 81.
Un acteur sera soit interne, soit externe au système étudié.
Expliquons en quelques mots :
Ici, je parle du système étudié et non du système d’information étudié. En effet, ce qui
m’intéresse est, dit crûment : l’acteur fait-il partie de l’entreprise ou du monde extérieur ?
Les acteurs issus de l’entreprise sont internes, ceux du monde extérieur sont externes.
Évidemment, on doit faire figurer des acteurs externes puisque la finalité de l’entreprise
est de recevoir de l’argent en échange d’une contrepartie. Si aucun échange d’informa-
tion n’a lieu entre l’entreprise et l’extérieur, c’est très louche !
Si on ne modélise qu’un sous-système de l’entreprise, seuls les acteurs de ce sous-système
seront internes, les autres, même internes à l’entreprise elle-même, seront externes au
système étudié.
Notons que cette distinction d’acteurs internes et externes vient de mon obsession à
travailler non pas dans l’absolu, mais dans le cadre très précis et unique d’une entreprise
et d’un système d’information donnés.
Il peut tout à fait arriver que l’analyse d’entreprises de taille et de secteur d’activité identi-
ques aboutisse à des graphes acteurs/flux différents si leur organisation interne diffère.
Exercice 82
Étudions le cas d’achat d’une voiture d’occasion auprès d’un particulier.
Vous prospectez dans différentes revues, vous essayez plusieurs voitures, jusqu’à trouver la
bonne. Le vendeur vous remet si nécessaire l’attestation de contrôle technique, un certificat
de situation (anciennement appelé certificat de non-gage), la carte grise barrée, les clés et… la
voiture. En échange, vous lui donnez un chèque.
Identifiez les acteurs du texte précédent en précisant s’ils sont internes ou externes.
155
8 3932 TG PA 01
Séquence 9
Exercice 83
Étudions maintenant le système d’information d’une concession d’automobiles.

Lorsqu’un client veut commander une voiture neuve, le commercial remplit un bon de com-
mande que le client signe. Pour éviter tout abus, le commercial perçoit toujours un chèque
d’arrhes à la signature. Le bon de commande et le chèque sont remis à la secrétaire qui en fait
une copie mise dans le dossier du client. Elle faxe ensuite le bon de commande au constructeur
et remet le chèque au service comptabilité qui l’envoie à la banque pour encaissement.
Lorsque le constructeur livre la voiture au concessionnaire, ce dernier prévient le client que
la voiture est disponible. Parallèlement, l’acheteur est allé voir son assureur pour obtenir une
attestation d’assurance temporaire (carte verte temporaire). Le service comptabilité édite la
facture de la voiture en trois exemplaires (un qu’il conserve, un qui est remis à la secrétaire qui
le range dans le dossier du client, le dernier étant transmis au commercial qui le remettra au
client lorsque celui-ci aura réglé le véhicule).
Lorsque le client vient chercher sa voiture, il contrôle que le véhicule correspond bien à ce qu’il
a commandé et signe le bon de livraison attestant qu’il prend possession de la voiture. Il verse
au commercial le solde du prix et ce dernier lui remet en échange la facture et les clés. Le com-
mercial transmet à la secrétaire le bon de livraison et le chèque. Elle en fait une copie qu’elle
place dans le dossier du client et transmet les originaux au service comptabilité qui archive le
bon de livraison avec son exemplaire de la facture et envoie le chèque à la banque.
Généralement, le client demande au commercial de s’occuper de l’immatriculation. Il lui remet
les documents nécessaires (formulaire de demande d’immatriculation rempli, justificatif de
domicile, chèque du montant de la taxe régionale sur les cartes grises). Le commercial transmet
ces pièces à la secrétaire car c’est elle qui s’occupe des dossiers d’immatriculation. La secrétaire
enverra à la préfecture ces documents, ainsi qu’une copie de la facture de la voiture. Par retour
du courrier, la préfecture envoie la carte grise au domicile de l’acheteur. En présentant sa carte
grise à l’assureur, le client obtiendra une carte verte définitive (contre paiement de l’assurance
bien entendu). Ouf !
Identifiez les acteurs du roman ci-dessus ; vous préciserez s’ils sont internes ou externes.
Exercice 84
Nous étudions une entreprise individuelle. Elle vend des ordinateurs à des clients institutionnels
(administrations) et à des particuliers. Dans tous les cas, le client passe commande, paye l’ordi-
nateur à la livraison puis reçoit la facture acquittée.
Quels sont les acteurs du système étudié ? Donnez leur type (interne ou externe).
2D. Les flux

La traditionnelle définition :
Flux : un flux (sous-entendu d’informationå) matérialise l’échange d’une informa-
tion structurée d’un acteur à un autre.
å Je me suis longuement posé la question de mettre information au pluriel ou au singulier.

Comme je veux mettre l’accent sur le fait que c’est une information structurée et non plusieurs
informations en vrac, j’ai choisi le singulier.
156
8 3932 TG PA 01
Graphe acteurs/flux
Étudions cela d’un peu plus près :

« flux d’information d’un acteur à un autre »
Flux signifie ici déplacement (Petit Robert). Le déplacement se fait bien d’un point à
un autre, soit d’un acteur à un autre. Notons que la phrase doit être interprétée stric-
tement : l’acteur émettant le flux est unique (ce qui est assez naturel), mais celui qui le
reçoit également. Si un document est envoyé à deux acteurs, cela engendrera deux flux.
On ne prend en compte que les flux (échanges) d’informations et pas les flux d’objets.
(On mettra un bémol à cette règle dans les exercices.)
« information structurée »
Le flux représente l’information réelle utilisée par l’entreprise sans aucune modélisation.
L’information prendra généralement la forme d’un document précis (facture, carte grise,
bon de commande…). On pourra préciser lorsque c’est utile qu’un flux est la copie d’un
autre (par exemple facture et double de facture). Sinon, on indiquera facture pour les
deux flux.
Une remarque : on notera que la définition d’un acteur était faite vis-à-vis d’un système
donné puisque la notion même d’acteur, en tant qu’intervenant dans un système, impli-
quait d’avoir un système où intervenir. En revanche, la notion de flux d’information est
définie de façon très générale. Ce n’est que dans la partie 2E (Graphe acteurs/flux) que
nous préciserons les flux qui nous intéressent.
Exercice 85
Reprenons le sujet de l’exercice précédent en fusionnant les différents types de clients :

Nous étudions une EURL d’assemblage de PC. Son mode de fonctionnement est le suivant :
le client passe commande, paye l’ordinateur à la livraison et reçoit la facture acquittée en
échange.
Décrivez les différents flux (nom, acteur émetteur, acteur récepteur).
2E. Graphe acteurs/flux

2E1. Soyons puristes
Allez, une définition !
Graphe acteurs/flux : le graphe acteurs/flux est une représentation des acteurs et
des flux permettant de visualiser la nature, l’origine et la destination des informa-
tions qui circulent dans le système étudié.
Observons cela de plus près :
« information du système étudié »
Cela reprend l’idée que les acteurs doivent avoir une fonction au sein du système étu-
dié, qu’ils soient internes ou externes. Ainsi, tout flux d’information doit répondre à au
moins une des deux conditions suivantes :
• il doit être issu du système considéré (donc être émis par un acteur interne) ;
• il doit être à destination du système considéré (donc être reçu par un acteur interne).
157
8 3932 TG PA 01
Séquence 9
À défaut, le flux est complètement externe au système et n’a rien à voir avec lui, donc
ne doit pas être représenté.
Du paragraphe précédent, on retiendra la consigne suivante :
Il ne doit pas y avoir de flux entre deux acteurs externes.
Cela ne signifie pas que le flux n’existe pas dans la réalité, mais juste que le système con-
sidéré n’a pas la maîtrise (et ne doit pas l’avoir) de ce qui se passe à l’extérieur.
2E2. Comment le graphe est-il représenté ?

Un acteur est représenté par un cercle dans lequel on écrit son nom. Le cercle des
acteurs externes sera en pointillés.
Un flux sera représenté par une flèche allant de l’acteur émetteur à l’acteur destina-
taire. Il sera nommé par le document (ou l’information) échangé.
Demande d’informations
acteur externe service acteur interne
client
commercial
Catalogue
flux
Reprenons, en la complétant, la remarque faite sur les flux.

Il ne doit pas y avoir de flux entre deux acteurs externes. En conséquence, on ne
fera pas figurer d’acteur externe n’échangeant d’information qu’avec des acteurs
externes.
Exercice 86
Dans le graphe ci-après, rayez les acteurs et/ou les flux qui ne doivent pas être représentés.
Pour simplifier, je n’ai nommé ni les acteurs ni les flux puisque l’on travaille sur une règle de
construction indépendante de toute sémantique.
158
8 3932 TG PA 01
Graphe acteurs/flux
Exercice 87
Considérons le système entreprise de vente d’ordinateurs :

Le mode de fonctionnement d’une entreprise de vente d’ordinateurs est le suivant : le client
passe commande, paye l’ordinateur à la livraison et reçoit la facture acquittée en échange.
Faites le graphe acteurs/flux de ce système.
2E3. Accordons-nous une petite dérogation

Comparons les deux graphes que nous avons déjà étudiés :
Demande d’informations Bon de commande
service entreprise
client client
commercial de vente de PC
Catalogue Facture acquitée
Premier graphe : système de demande de catalogue Second graphe : système de commande de PC
Le premier graphe est tout à fait intelligible car on visualise un principe d’action/réac-
tionå du système : le stimulus demande d’information reçoit la réponse envoi de cata-
logue. On perçoit bien la logique de l’ensemble.
En revanche, le second graphe est hermétique : la légende nous informe qu’il s’agit de
vente de PC, mais l’on reste tout surpris des flux ; on comprend que figurent le stimulus
initial (le bon de commande), la réponse finale (la facture acquittée), mais il est clair que
toute une machinerie reste implicite. Il est évident que ce graphe est finalement trop
épuré pour nous aider à comprendre le fonctionnement de l’entreprise.
Nous n’en avons pas fini avec le second graphe. Il modélise quelque chose de fonda-
mental pour l’entreprise : une vente ! D’où ma remarque purement subjective mais
néanmoins valide : je souhaiterais que la vente, qui est la fonction même de l’entreprise,
soit matérialisée de façon plus précise. En effet, ce graphe est tellement imprécis qu’il
ne sert à rien.
Finalement, que nous manque-t-il ? Rajouter des flux, même s’ils représentent autre
chose que de l’information.
Le graphe acteurs/flux se veut une approche du fonctionnement du système étu-
dié par l’étude de la circulation de ses documents. L’important étant avant tout sa
lisibilité et l’efficacité de sa représentation, on s’autorisera à matérialiser des flux
financiers ou d’objets, sous réserve qu’ils apportent réellement des précisions.
å Pour changer, j’emprunte un peu le vocabulaire des systèmes réactifs (action, réaction, stimu-
lus). C’est naturel si on considère l’entreprise (le système étudié) comme une entité réagissant aux
sollicitations extérieures (les clients).
159
8 3932 TG PA 01
Séquence 9
En pratique, on représentera toujours les flux financiers car :

– le flux financier (l’échange d’argent) est éminemment important en gestion, et on
aime bien matérialiser les choses importanteså ;
– avec le principe des acomptes, arrhes, paiements par traites… de nombreux docu-
ments (factures, relances…) naissent des flux d’argent. Faire figurer la circulation
de ces documents sans mentionner les flux financiers sous-jacents rend incompré-
hensible leur rôle.
Quant aux flux d’objets (marchandise…), on ne les représentera que s’ils sont nécessaires
à la compréhension du graphe.
Exercice 88
Refaites l’exercice 87 en vous accordant les flux nécessaires à la compréhension du graphe.
Exercice 89
Modélisons le système de l’entreprise LIPAD (LIvraison de Pizza À Domicile)
Le client appelle le standard de LIPAD. On lui propose les pizzas du jour, ainsi que le délai
d’attente. Le client choisit sa pizza, donne ses coordonnées et raccroche. Le standardiste com-
munique le bon de commande au pizzaïolo. Celui-ci prépare la pizza puis la donne avec le bon
de commande au livreur qui, faisant fi des intempéries, enfourche son petit scooter (fidèle
destrier !) et fonce chez le client. Il lui remet la pizza contre paiement. De retour chez LIPAD,
le livreur remet le bon de livraison et l’argent au responsable.
Faites le graphe acteurs/flux du système LIPAD.
Exercice 90
Faites le graphe acteurs/flux du sujet de l’exercice 83 (concession automobile).
Nous avons quelques enseignements à tirer de l’exercice précédent sur la suppression de

l’acteur assureur. On ne travaille toujours que vis-à-vis d’un système considéré. Ainsi, on
ne matérialisera que les acteurs intervenant dans ce système, donc recevant ou échan-
geant de l’information venant de ce système.
Il en découle deux choses que l’on rappelle :
– un flux d’information entre deux acteurs externes n’a aucun intérêt pour l’entre-
prise. On ne le fait pas figurer ;
– corollaire : on ne fait figurer un acteur externe que s’il reçoit un flux d’un acteur
interne ou s’il lui en envoie un.
å C’est un raisonnement analogue qui me faisait dire (séquence 6 paragraphe 3) que plus l’objet
modélisé est important dans le système considéré, plus on le représente sous forme d’entité et non
d’association.
160
8 3932 TG PA 01
Graphe acteurs/flux
Notons une dernière fois que le graphe acteurs/flux demeure beaucoup moins formaliste
que le MCDå. Le graphe ayant pour seul objet l’explication du fonctionnement de l’en-
treprise par la modélisation des flux documentaires, on s’accordera des libertés si elles
aident manifestement à la compréhension.
Exercice 91
Plaçons-nous dans le système d’un marchand de biens (bâtiments, maisons…).

La personne voulant vendre une maison (le vendeur) mandatera le marchand de biens par un
document contractuel (mandat de vente) pour que celui-ci trouve un acheteur.
Le marchand de biens fera signer à l’acheteur un compromis de vente puis le fera signer par le
vendeur. Ce document oblige les deux parties (acheteur et vendeur) à conclure la transaction.
Le document est transmis chez un notaire qui va récupérer divers documents puis convoquer
les parties pour leur faire signer l’acte de vente.
Au moment de la signature, l’acheteur remet le chèque au notaire qui l’encaissera puis versera
sa commission au marchand de biens et le restant au vendeur.
Notons une chose importante : le financement d’un achat immobilier s’effectue presque
toujours grâce à un emprunt. La loi impose donc que le compromis de vente soit annulé si
l’acheteur n’obtient pas de prêt. Si le prêt est accordé, la banque verse directement l’argent au
notaire, l’acheteur n’ayant lui à verser que son apport initial.
Faites le graphe acteurs/flux du système marchand de biens.
La leçon à tirer de cet exercice est la suivante :

Par dérogation à la règle précédente, on peut représenter des flux ou des acteurs
étrangers au système s’ils ont une importance cruciale dans le fonctionnement de
l’entreprise.
2E4. Ordonnancement des flux

Mettez le graphe de l’exercice précédent sous vos yeux en essayant d’oublier le sujet
correspondant. Le graphe est-il compréhensible ? Oui ?
Exercice 92
Eh bien, pensez-vous que vous pourriez me dire, au seul vu du graphe, si la demande d’em-
prunt doit être faite avant ou après la signature du compromis de vente ?
La chronologie d’échange des documents est évidemment cruciale dans la compréhen-

sion du fonctionnement de l’entreprise : ici, le compromis de vente n’a de sens qu’en
tant qu’étape préalable avant la signature du contrat chez le notaire.
å Cela ne veut pas dire que son concepteur était moins rigoureux que celui du MCD, mais provient
de la nature des deux modèles. Le MCD est quasiment contractuel puisque toute l’application sera
bâtie dessus, tandis que le graphe est destiné à une meilleure compréhension du fonctionnement de
l’entreprise. C’est la différence entre une esquisse et un plan d’architecte.
161
8 3932 TG PA 01
Séquence 9
Pour remédier à cela, il suffit de numéroter les flux dans l’ordre où ils se produisent.
Reprenons le graphe de l’exercice 79 et ordonnançons les flux :
1. bon de commande
entreprise
client 2. paiement de vente de PC
3. facture
Bien entendu, vous pouvez numéroter comme vous voulez : « (2) Paiement » est tout
aussi bien !
Notons que sur un graphe touffu, il sera plus lisible de ne mettre que les numéros des
flux sur le graphe et d’indiquer à côté leur nom, comme dans le graphe qui suit.
(1)
(1) : bon de commande
entreprise
client (2) (2) : paiement
de vente de PC
(3) : facture
(3)
Dans le graphe ci-dessus, il n’y a que trois flux mis dans l’ordre les uns sous les autres.
L’ordonnancement n’apporte pas grand chose. Mais dans le cas d’un graphe plus com-
plexe… c’est nécessaire.
Exercice 93
Ordonnancez les flux de l’exercice 91 du système marchand de biens.
Vous prendrez l’habitude d’ordonnancer systématiquement les flux.

Nous terminerons cette partie sur un petit exercice :
Exercice 94
Étudions une seconde EURL d’assemblage de matériel informatique. Elle vend des ordinateurs
à des clients institutionnels (administrations) et à des particuliers. Le protocole de vente est
différent selon les clients :
• le particulier verse un acompte de 25 % à la commande, puis le solde le jour de la réception
de l’ordinateur. Il reçoit en échange une facture acquittée ;
• les clients institutionnels demandent un devis pour que l’intendant (le comptable) valide la
dépense. Si le devis est accepté, le client passe la commande sans verser d’acompte. Le jour
de la livraison, le client reçoit une facture. L’intégralité de la somme est versée 90 jours après
la livraison, à la suite de quoi le client reçoit une facture acquittée.
Faites le graphe acteurs/flux de ce système.
162
8 3932 TG PA 01
Graphe acteurs/flux
On retiendra de cet exercice la remarque suivante :

Le graphe acteurs/flux ne modélise que le fonctionnement normal (classique) de l’entre-
prise, soit le cas général où tout se passe bien.
Deux remarques :
• comme d’habitude, on peut déroger à cette règle si nécessaire ;
• le MCD, au contraire, modélise le cas général mais aussi tous les petits cas particu-
liers.
3. Conclusion
Je vous assure que le graphe acteurs/flux est quelque chose d’assez élémentaire. J’ai
réussi à faire une douzaine de pages car j’ai tenté l’exhaustivité et toutes les astuces que
l’on pourrait vous demander.
Hormis dans la définition des acteurs et des flux, il n’y a pas de règle immuable comme
pour le MCD. Les différentes règles que nous avons vues ne représentent qu’un cadre de
travail. On peut toutes les violer, mais on doit le faire consciemment, donc à bon escient
(c.-à-d. en le justifiant).
Le cours est terminé. Je tiens à féliciter ceux qui ont eu le courage d’arriver jusqu’ici et
j’espère que vous aurez eu autant de plaisir à lire le cours que moi à le rédiger.
Je peux vous assurer que si vous l’avez assimilé correctement, vous avez le niveau requis
en BTS.
Maintenant, haut les cœurs et passez au cas de synthèse (étude de cas autocorrigée) !
163
8 3932 TG PA 01
Synthèse
Définitions
Acteur : un acteur (sous-entendu du système d’information) est constitué d’une ou
plusieurs personnes regroupées par leur fonction dans ce système. Il est identifié par
son nom. Un acteur sera soit interne, soit externe au système étudié.
Flux : un flux (sous-entendu d’information) matérialise l’échange d’une informa-
tion structurée d’un acteur à un autre. Les flux financiers sont également repré-
sentés vu leur importance en informatique de gestion.
Graphe acteurs/flux : le graphe acteurs/flux est une représentation des acteurs
et des flux permettant de visualiser la nature, l’origine et la destination des infor-
mations qui circulent dans le système étudié.
Il ne doit pas y avoir de flux entre deux acteurs externes. En conséquence, on
ne fera pas figurer d’acteur externe n’échangeant des informations qu’avec des
acteurs externes.
Le graphe acteurs/flux ne modélise que le fonctionnement normal (classique) de
l’entreprise, soit le cas général où tout se passe bien.
Représentation
Un acteur est représenté par un cercle dans lequel on écrit son nom. Le cercle des
acteurs externes sera en pointillés.
Un flux sera représenté par une flèche allant de l’acteur émetteur à l’acteur
destinataire. Il sera nommé par le document (ou l’information) échangé. Vous
prendrez l’habitude d’ordonnancer systématiquement les flux.
Le graphe acteurs/flux se veut une approche du fonctionnement du système étu-
dié par l’étude de la circulation de ses documents. L’important étant avant tout sa
lisibilité et l’efficacité de sa représentation, on s’autorisera à matérialiser des flux
financiers ou d’objets, sous réserve qu’ils apportent réellement des précisions.
165
8 3932 TG PA 01
Graphe acteurs/flux
Étude de cas récapitulative
Nous allons étudier de façon quasi exhaustive le fonctionnement du CNED.

Ce sujet sera prétexte à reprendre l’ensemble des thèmes abordés dans le
cours. Faites-le donc très sérieusement !
Avertissement
Ce devoir répond à plusieurs impératifs :
• vous faire travailler sur un sujet de taille réelle et non sur des mini-cas
comme dans nos exercices ;
• mettre en œuvre la plupart des différents concepts abordés sans que
ce soit téléguidé (utiliser des entités faibles dans la séquence sur les
entités faibles, cela manque d’originalité) ;
• vous proposer un sujet d’examen blanc.
Hélas, il apparaît aux différentes relectures de la correction (j’ai évidemment un peu

d’avance sur vous) que ces trois objectifs sont inconciliables.
Le sujet que je vous propose est donc complexe pour une fin de première, voire seconde
année. Pourquoi ? Il ne contient pas de difficulté d’abstraction comme avec le sujet de
modélisation des MCD. La difficulté, c’est la densité de ce que l’on modélise. Pris isolément,
les éléments sont raisonnablement simples, mais l’ensemble forme un tout complexe.
Quelle solution adopter face à cet ennuyeux constat ? Soit je simplifiais le sujet, soit je
rajoutais un long avertissement (et, à votre avis, qu’êtes-vous en train de lire ?). L’intérêt
de ce sujet est qu’il est très représentatif :
• il constitue une étude complète d’un cas de gestion réel ;
• tout ce qui a été vu dans le cours se retrouve ici ;
• ce sujet comporte 90 % de choses très simples et 10 % de choses complexes. Supprimer
des éléments aurait déséquilibré cela.
Voici donc ce que je vous conseille :
Ce sujet est assez long et difficile. Je ne pense pas que vous puissiez raisonnablement le traiter
en moins de quatre heures. Selon votre aisance, fixez-vous de quatre à six heures. Mettez-
vous en condition d’examen en le faisant d’une traite (débranchez votre téléphone !).
À l’issue de l’épreuve (et non après 10 minutes de griffonnage), comparez votre solution
à la correction. Si, dès les premières lignes du corrigé, vous voyez que vous êtes passé à
côté, lisez la correction de la partie qui vous a posé problème (pas plus), attendez quelques
jours puis refaites le sujet.
167
8 3932 TG PA 01
Séquence 9
Encore une fois, ce sujet est plus complexe qu’un sujet de BTS (qui n’évalue pas que l’analyse).
Sans démagogie, je n’ai pas honte d’avouer que si écrire le sujet ne m’a pas posé trop de pro-
blèmes, j’ai passé beaucoup de temps pour mettre au point un corrigé correct. Or, j’ai tout de
même beaucoup plus de recul que vous. Ainsi, ne croyez pas n’avoir rien compris à l’analyse si
vous avez du mal avec ce sujet. Il n’est pas facile. Mais il constitue un très bon entraînement.
Évidemment, vous devrez étudier le volumineux corrigé avec beaucoup d’atten-
tion !
On vous demande de réaliser l’analyse de l’activité du CNED. Pour cela, les informations
suivantes vous sont fournies.
1. Objectif de l’informatisation
Le CNED assure un service de formation à distance dans de nombreuses disciplines. Pour
assurer sa mission, il est en relation avec beaucoup d’intervenants : des étudiants, mais
aussi des enseignants chargés de rédiger les cours et de corriger les copies. Le nombre de
disciplines, d’enseignants et d’étudiants est tel qu’il devient nécessaire de tout informati-
ser pour suivre l’activité du centre et savoir :
• si l’enseignant recevant des copies à corriger les retourne au CNED en temps et en
heure ;
• s’il n’y a pas trop de démissions dans un cours donné (ce qui serait un signe de mal-
façon) ;
• l’évolution du nombre d’inscrits ;
• les différentes versions et mises à jour des supports de cours ;
• les notes des inscrits ;
•…
2. Organisation générale
Lorsque le service pédagogique du CNED veut faire concevoir un nouveau cours, il envoie à
l’enseignant retenu les documents contractuels (contrat, cahier des charges) que ce dernier
retourne signé. Une fois le cours rédigé, l’enseignant l’envoie au service pédagogique qui
lui retourne une attestation de service fait. Une copie de l’attestation est envoyée au service
comptabilité du CNED qui procède alors au paiement de la rémunération de l’enseignant.
Un étudiant intéressé par des cours demande un dossier d’inscription au secrétariat du
CNED qui le lui envoie par retour de courrier. S’il y trouve la formation qui l’intéresse, il
retourne le dossier accompagné d’un chèque (couvrant les frais d’inscription) au secréta-
riat qui transmet le dossier au service scolarité et le chèque au service comptabilité. Le
service scolarité envoie à l’étudiant l’ensemble des documents de la formation correspon-
dante (supports de cours, fascicules d’exercices…).
Lorsqu’un étudiant envoie pour correction un devoir au secrétariat du CNED, ce dernier lui
expédie immédiatement le corrigé-type correspondant et envoie le devoir à l’enseignant
chargé de la correction.
Quinze jours maximum après réception de la copie, le correcteur la retourne corrigée au
secrétariat du CNED, qui la renvoie à l’étudiant concerné. Les notes sont communiquées
au département scolarité qui envoie aux inscrits un relevé de notes en fin de formation. Le
secrétariat relève le nombre de copies renvoyées par chaque correcteur et le communique
au service comptabilité qui paye trimestriellement les correcteurs.
168
8 3932 TG PA 01
Graphe acteurs/flux
3. Les cours
Le CNED dispense deux types de cours :
1. Le module. C’est un cours sur un thème donné ; par exemple : Apprentissage de Word
2003, Comptabilité…
2. La formation réglementée. C’est une formation conforme aux programmes de l’Édu-
cation Nationale. Par exemple : Classe de sixième, BTS informatique de gestion… Elle
est constituée de modules : le module Apprentissage de Word 2003 fera partie de la
formation BTS Informatique de Gestion.
Chaque cours (module ou formation) possède un titre (intitulé), une référence, des tarifs
(voir ci-dessous), une durée en heures, une date de début et de fin d’inscription (ces dates
étant mises à jour à chaque année scolaire) et le nombre de devoirs associés au cours.
4. Tarifs des cours

Les cours ont des tarifs différents selon la situation de l’inscrit.
Le tarif A1 concerne l’inscription à titre individuel.
Le tarif A2 concerne les inscrits de 16 à 28 ans pour les formations allant de l’élémentaire
au baccalauréat.
le tarif B concerne les inscriptions non financées par l’inscrit (formation continue, finance-
ment ANPE…).
Les cours peuvent donc avoir 2 ou 3 tarifs. Par exemple, une formation de BTS aura des
tarifs A1 et B mais pas A2 puisque ce dernier ne s’applique que jusqu’au baccalauréat.
Notons que le tarif d’une formation est moins élevé que la somme des tarifs des modules
qui le constituent.
5. Les supports de cours

Pour chaque module, le CNED a fait réaliser un ou plusieurs supports de cours. Ces derniers
ont une nature très variable puisqu’il peut s’agir de cassettes audio, vidéo, de fascicules de
cours, de fascicules de devoirs… Outre sa nature, un support de cours possède une réfé-
rence, un titre, un auteur et une date de réalisation. Il n’est utilisé que pour un module.
6. Étudiant
Un étudiant est caractérisé par ses nom, prénom, adresse complète, téléphone et date de
naissance.
7. Les inscriptions
Les inscriptions ne sont gérées que pour l’année en cours, on ne les historise pas. Un
étudiant peut s’inscrire à autant de cours (module et/ou formation) qu’il le souhaite. Un
étudiant peut bénéficier de tarifs différents. Par exemple, il peut avoir le tarif B pour la
formation BTS Informatique de Gestion financée par son entreprise, mais suivre en même
temps la formation Comptabilité à titre personnel et supporter le tarif A1. Une inscription
se fait à une date précise.
169
8 3932 TG PA 01
Séquence 9
8. Envoi des supports de cours

Une fois l’inscription enregistrée, le CNED envoie les supports correspondants à l’étudiant.
Comme il peut arriver qu’un support soit temporairement manquant, le CNED doit savoir
exactement ce qu’il a envoyé ainsi que la date d’envoi de chaque support.
9. Enseignant
Un enseignant est caractérisé par ses nom, prénom, adresse complète, téléphone et coor-
données bancaires. Parallèlement à son travail au CNED, l’enseignant est soit en retraite,
soit en poste dans un établissement scolaire (numéro d’établissement, nom, adresse, télé-
phone). Pour pouvoir travailler au CNED en plus de son service normal en établissement,
l’enseignant doit avoir une autorisation de cumul dont il faut conserver la date.
10. Rédaction des supports de cours

Le CNED s’adresse à des enseignants pour concevoir les supports de cours. Toute concep-
tion de support est encadrée par un contrat précisant la date de livraison du support et la
rémunération. Le contrat est signé à une date donnée. La conception d’un support peut
être faite conjointement par plusieurs enseignants. Dans ce cas, il y aura autant de contrats
que d’enseignants.
11. Les contrats de correction de copies

Les enseignants correcteurs signent un contrat de correction valable pour l’année scolaire
et pour un ou plusieurs modules. Pour chaque module concerné, le CNED associe plusieurs
étudiants à chaque correcteur. La rémunération est faite à la copie, le tarif étant fixé en
fonction du module. Le contrat est signé à une date donnée.
12. La gestion des devoirs

L’étudiant envoie son devoir au CNED (la date de réception est conservée), qui la fait par-
venir au correcteur ; ce dernier la retourne corrigée au CNED qui la renvoie à l’étudiant.
Chaque devoir a une date d’envoi théorique permettant aux étudiants de se situer dans
le rythme de progression.
13. Les paquets de devoirs

Entre l’étudiant et le CNED, les échanges se font copie par copie. En revanche, pour évi-
ter l’expédition anarchique, les échanges entre le CNED et les correcteurs sont faits par
paquets de copies. Un paquet est constitué d’une ou plusieurs copies (en pratique, les
copies des étudiants associés au correcteur correspondant). Les paquets sont envoyés cha-
que semaine, la date d’envoi étant stockée. Le correcteur ne peut renvoyer le paquet que
lorsqu’il en a corrigé toutes les copies. La date de réception par le CNED du paquet corrigé
est mémorisée. Pour chaque paquet, le CNED compte systématiquement le nombre de
copies envoyées et reçues pour s’assurer qu’aucune n’est perdue.
14. Les notes

Lorsque le CNED reçoit un paquet de copies corrigées, il archive les notes pour établir le
relevé de fin de formation.
170
8 3932 TG PA 01
Graphe acteurs/flux
Travail à faire
1. Faites le graphe acteurs/flux modélisant l’organisation générale du CNED (paragraphe

2). Vous ordonnancerez les flux.
2. Faites le MCD modélisant l’activité complète du CNED. Ce sujet possède deux difficultés
majeures : la gestion des contrats de correction et la gestion des copies et paquets de
copies. Tout n’étant pas forcément parfaitement modélisable, n’hésitez pas à utiliser des
règles de gestion.
3. Faites le MLD correspondant en jouant le jeu et en écrivant tous les champs (et non un
seul champ suivi de « … ») !
Vous pouvez, dès maintenant, faire et envoyer à la correction le devoir 3 (voir

fascicule « devoirs » réf. 3932 DG).
171
8 3932 TG PA 01

83932tgpa0109 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

83932tgpa0109 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

BTS Informatique de gestion, 1re année

Directrice de publication : Valérie Brard-Trigo

Présentation du support de cours

Cette séquence d’introduction va vous expliquer ce qu’est et à quoi sert une

2. La méthode Merise .............................................................................. 11

1A. Pourquoi l’analyse ?

1B. L’informatique de gestion

Cet exemple me permet de vous donner la définition suivante :

1C. Les méthodes d’analyse

2A. Données et traitements

2B. Les trois niveaux de modélisation

L’informatique de gestion consiste à gérer, manipuler et exploiter le système d’in-

Le tableau ci-dessous résume les productions fournies à chaque étape.

Niveau Données Traitements

3. Les propriétés ........................................................................................ 21

4. Les associations ..................................................................................... 23

å Ce mot est un néologisme, inutile de le chercher dans le dictionnaire !

2B. Représentation graphique

Un exemple classique : un grossiste a comme fournisseurs et comme clients des entreprises.

Le corrigé de l’exercice montre qu’il y a de nombreuses façons de considérer l’aspect élémen-

3B. Représentation graphique

Dans un rectangle, on met le nom de l’entité, puis on tire un trait et

4B. Représentation graphique

Notons le formalisme Merise : le nom du lien est écrit dans un ovale.

Bien, nous avons presque terminé.

2. Les identifiants ...................................................................................... 32

3. Interlude : comment construire un MCD (1)............................... 40

1A. Occurrence d’entité

Faisons un petit détour par l’algorithmique (programmation) : on va retrouver le même

Au vu de la correction de l’exercice 4, il est bon de préciser ce qui suit :

Le concept d’occurrence d’entité nous permet de justifier pourquoi le nom de l’entité

1B. Occurrence d’association

Occurrence d’association : une occurrence d’association est une réalisation (concré-

On retiendra ce qui suit :

Initiation à Internet Pollen LeChat 8, avenue de la Libération 45000 ORLÉANS

On remarquera les points suivants :

Reprenons le tableau de la correction :

Initiation à Internet Pollen LeChat 8, avenue de la Libération 45000 ORLÉANS

Nous allons reprendre ce concept de numéro de client dans le MCD.

2B. Identifiant d’une entité

Analysons cette phrase

Le fait que l’identifiant détermine l’occurrence ne signifie pas qu’à partir de la

« la valeur de l’identifiant doit être stable [et] non nulle »

2B2. Représentation graphique

Vérifiez qu’avec le changement dans le tableau des inscriptions, on a toujours la possibilité

2C. Identifiant d’une association

La définition sera la suivante :

3. Interlude : comment construire un MCD (1)

Gestion des permis de construire à la mairie (première partie).

å Un are = 100 m2 (et un hectare = 100 ares = 10 000 m2).

4A. Présentation par l’intuition

Le jeu d’essai donné dans la correction de l’exercice précédent deviendra :

NUMÉRO PROPRIETAIRE NOM PRÉNOM DATE DE NAISSANCE ADRESSE CODE VILLE

1 LeChat Pollen 25/01/1998 ici 59000 LILLE

RÉFÉRENCE CADASTRALE SURFACE TYPE NUMÉRO PROPRIÉTAIRE

4B. Définition des cardinalités

Deuxième remarque : expliquons bien les cardinalités en les lisant ensemble.

On résumera en disant qu’une occurrence d’étudiant peut participer de 0 à plusieurs

Cet exercice permet une conclusion intéressante :

Il est donc indispensable d’avoir le plus d’informations possible embarquées dans le

4C. Les différentes cardinalités

La séquence est presque terminée ; faisons donc un petit exercice d’entraînement.

4D. Distinguons les cardinalités maximales