Conception des

systèmes
d’informations

Filière: DSI
Lycée Hassan 2 Marrakech
(2020/2021)
M. LACHHAB
 L'information est aujourd'hui une ressource stratégique pour la plupart
des entreprises, dans lesquelles de très nombreuses activités reposent sur
l'exploitation d'applications informatiques. Pour ces entreprises, la
fiabilité de leur système informatique et la qualité des logiciels utilisés
sont donc cruciales.
.
 Parallèlement, on constate que :
 la part du logiciel est aujourd'hui prépondérante dans le coût total d'un
système informatique .
 la demande d'applications nouvelles, et de plus en plus complexes, ne
cesse de croître .
 les utilisateurs sont de plus en plus exigeants en termes de fiabilité et
de sécurité.
  Définition de logiciel :

 Le logiciel est l'ensemble des programmes, procédés et

règles, et éventuellement de la documentation, relatifs au
fonctionnement d'un ensemble de traitements de
l'information.
.
 DIFFERENTS MODELES De CYCLES DE VIE D’UN LOGICIEL

 Introduction:
Notion de cycle de vie
C'est la description d'un processus couvrant les phases de:
 Création d'un produit .
 Distribution sur un marché .
 Disparition.
.

.
 Un système d'Information (noté SI) représente l'ensemble des éléments participant
à la gestion, au traitement, au transport et à la diffusion de l'information au sein de
l'organisation. 

 Il ne faut toutefois pas confondre un système d'information avec un système

informatique. En effet, les systèmes d'information ne sont pas toujours totalement
informatisés et existaient déjà avant l'arrivée des nouvelles technologies de
l'information et des communications dont l'informatique fait partie intégrante.
 Le SI possède 4 fonctions essentielles :

La saisie ou collecte de l'information
La mémorisation de l'information à l'aide de fichier ou de base de
données
Le traitement de l'information afin de mieux l'exploiter
(consultation, organisation, mise à jour, calculs pour obtenir de
nouvelles données, ...)
La diffusion de l'information
Prenons un exemple.

Vous connaissez tous le service de cartographie de Google appelé Google Maps. Pour simplifier,
c’est un site de cartographie en ligne qui vous permet de rechercher un lieu, n’importe où dans le
monde, depuis la barre de recherche sur le site.
 Mais c’est aussi un système d’information parce que Google Maps est un
ensemble de ressources humaines, matérielles et immatérielles :

 des ressources humaines, car Google Maps c’est une équipe de développeurs, de
cartographes, de géomètres, mais aussi les chauffeurs des voitures Google qui
prennent les rues en photos et encore bien d’autres personnes !

 des ressources matérielles, car des ordinateurs, serveurs, caméras, satellites sont
utilisés pour acquérir et stocker les données cartographiques.

 enfin, des ressources immatérielles car Google Maps c’est aussi des photos
satellites, des cartes, mais aussi des brevets créés et exploités par Google pour
mettre en œuvre ce service.
Eh bien en plus d’être un service de Google, Google Maps est un système
d’information à part entière.
Parce que tout d’abord, il permet de :

 collecter et stocker les données cartographiques prises par les satellites .

 les traiter en les combinant à vos recherches sur le site .

 et les distribuer, c’est-à-dire vous les afficher sur le site lors de vos
recherches .
 Le SI est le véhicule des différents services d’une entreprise. En
structurant les échanges, il les coordonne ainsi que les activités de
l’organisation. Il lui permet ainsi d'atteindre ses objectifs stratégiques.

 Comme nous venons de le voir, un SI est formé de l'ensemble de

ressources (les personnes, les matériels, les logiciels, les procédures)
permettant de mener les actions suivantes sur l'information :

 (1) COLLECTER => (2) STOCKER => (3) TRAITER => (4)
DIFFUSER
 En résumé :
 Le SI a 4 fonctions : collecter, stocker, traiter et diffuser l’information.

 Les informations collectées peuvent provenir de flux internes ou externes au

SI de l’organisation.

 Les informations peuvent être stockées sous forme de base de données ou

de fichiers.

 Les BDD et fichiers peuvent être stockés physiquement sur un serveur, une
aire de stockage au sein de l’organisation ou bien dans le Cloud.

 4 formes de traitement de l’information sont possibles : la consultation,

l’organisation, la mise à jour et la création de nouvelles informations.
Il y a 4 grands impacts / enjeux d’une SI sur la vie et l’économie d’une entreprise :

 améliorer de la productivité au sein de l’organisation .

 apporter une vue synthétique de l’organisation .

 assister la mise en œuvre de la stratégie de l’entreprise .

 favoriser la collaboration entre les interlocuteurs, internes ou externes de

l’organisation .
 MERISE

 MERISE est une méthode française née dans les années 70, développée
initialement par Hubert Tardieu. Elle fut ensuite mise en avant dans les années
80, à la demande du Ministère de l'Industrie qui souhaitait une méthode de
conception des SI.

 MERISE est donc une méthode d'analyse et de conception des SI basée sur le
principe de la séparation des données et des traitements .
Elle possède un certain nombre de modèles (ou schémas) qui sont
répartis sur 3 niveaux :

 Le niveau conceptuel .
 Le niveau logique ou organisationnel .
 Le niveau physique.
 Le dictionnaire de données
 Le graphe de dépendances fonctionnelles (matrice df)
 Le modèle conceptuel de donnes(MCD)
 Le modèle logique de données (MLD)
 Le passage sur un logiciel de SGBDR
  Les apports de Merise

 La force de la méthode Merise est de structurer les besoins des décideurs de façon simple et
 compréhensible. 
 Merise améliore la communication entre les différents acteurs du processus de
développement. 
 Cette méthode, grâce à ses modèles, encadre le projet et de ce fait protège les intervenants 

d’un possible développement hors sujet.
 Les apports de Merise

 Suivre ce cheminement intellectuel peut aussi aider l’entreprise à mieux se
 connaître, mieux se  comprendre et ainsi mieux communiquer.
 Le projet Merise s’articule autour d’un schéma directeur qui détermine et 
planifie le projet et ses enchaînements.
 Présentation de la méthode Merise

 Merise est une méthode de conception et de développement des systèmes

d’information ,elle vise a recenser la totalité des informations dont
l’entreprise a besoin pour assurer tout ou une partie de ces activités
fondamentales, elle est présentée souvent comme une méthode d’analyse
informatique.
 Elle nous permet de :
 Maitriser le développement du système , en répondant aux besoins net
de l’evolution de l’entreprise .
 Assurer la continuité du système .
 Facilite la communication
 Système d’information

 Un système d’information (SI) est un ensemble organise de

ressources(matériels , logiciels, personnels ,données et procédures ) qui
permet de collecter , regrouper ,classifier, traiter et diffuser de
l’information sur un environnement donne (Ex dans une entreprise) .
Cycle et conception d’un système
d’un formation
 Expression des besoins

 Tout d’abord cette étape et très importante pour commencer la collection des données se fait grâce
« au dictionnaire de données » .

 Le dictionnaire des données est un document qui permet de recenser, 
 de classer et de trier toutes les informations (les données) collectées lors des
  entretiens ou de l’étude des documents. 
 Le dictionnaire peut être plus ou moins élaboré selon le niveau de granularité 
 souhaité. En voici un exemple :

Nom Description Entité Type identifiant

 Expression des besoins

 Tout d’abord cette étape et très importante pour commencer la collection des
données se fait grâce « au dictionnaire de données » .
 Exemple d’un dictionnaire de données (client et les articles):
Nom Commentair Entité type Identifiant
e
NumClient Numéro de Client Numérique oui
client
nom Nom client Client Texte Non
prénom Prénom client Client Texte non
Adresse Adresse client Client texte Non
NumArticle Numero Article Numérique oui
Article
Désignation Désignation Article Texte non
Article
……………. …………….. ………….. …………….. ……………..
 Niveau conceptuel

 L'étude conceptuelle merise s’attache aux invariants de l’entreprise ou de

l’organisme : quells sont les activités , les métiers gérés par l’entreprise ,quels
sont les grands processus traités ….
 Au niveau conceptuel on veut décrire, le modèle(le système) de l’entreprise ou de
l’organisme ,cela se fait grace au :
 Modèle conceptuel des données (ou MCD),schéma représentant la structure du
système d’un formation, du point de vue des données ,c’est a dire les
dépendances ou relations entre les différentes données du système d’information
(par exemple :le client la commande ,la ligne de commande etc. ..).
 Introduction au Modèle Conceptuel des Données

 Le Modèle Conceptuel des Données introduit la notion d’entités, de relations et de propriétés. Nou
s allons commencer par voir certains aspects  «  théoriques»  avant de plonger dans la pratique.
Il décrit de façon formelle les données utilisées par le système d’information. La représentation 
graphique, simple et accessible, permet à un non informaticien de participer à son élaboration .
 Les éléments de base constituant un modèle conceptuel des données sont :
 les propriétés
 les entités
 les relations
 Les propriétés

 Les propriétés sont les informations de base du système d’information.
Un  client  possède  un  numéro  de  client,  un  nom,  un  prénom,  habite  à  une 
adresse  précise,  etc.  Ces  informations élémentaires essentielles sont 
des propriétés.
Les propriétés disposent d’un type. Elles peuvent être numériques, représenter une 
date, leur  longueur peut être aussi définie. Par exemple: 
 le nom est une propriété de type alphabétique et de longueur 50, c’est­à ­
dire que la valeur saisie ne comportera aucun chiffre et ne dépassera pas cinquante 
caractères.
Les  types  ne  sont  pas  décrits  au  niveau  conceptuel,  car  ce  niveau  est   trop 
proche  de  la  définition  du  système physique. Nous y reviendrons plus tard.
 Les entités ou objets

Comme il est aisé de le constater, les clients sont définis par certaines propriétés (numéro, nom, 
prénom…). 
Le fait de les regrouper amène naturellement à créer une entité Clients. Le 
symbolisme retenu est le suivant :
 L’identifiant

 Une de ces propriétés a un rôle bien précis, c’est l’identifiant nommé aussi la clé.
 L’identifiant permet de connaître de façon sûre et unique l’ensemble des propriétés qui participent à
l’entité. Par exemple, le fait de connaître la ville d’un client permet il de connaître son
nom ? La réponse est non.
 La connaissance du nom du client perme telle de connaître sa ville ? La réponse est
toujours non.
 Il faut donc trouver, ou inventer, une propriété qui lorsque sa valeur est connue permet la
connaissance de l’ensemble des valeurs qui s’y rattachent de façon formelle.
Voici le schéma modifié de l’entité  Clients
 Les relations ou associations

 Nous avons vu que les entités regroupaient un ensemble d’informations

élémentaires. Les entités sont souvent liées entre elles.
 Par exemple :

Un client peut commander des articles
 Les cardinalités

 Elles expriment le nombre de fois ou l’occurrence d’une entité participe aux occurrences de l
a relation.

 Dans notre exemple on peut se poser les questions suivantes :

 Combien de fois au minimum un client peut-il commander un article ?

 Combien de fois au maximum un client peut-il commander un article ?
 Il faut que nous nous posions les mêmes questions pour l’article :
 Combien de fois au minimum un article peut-il être commandé par un client
 Combien de fois au maximum un article peut-­il être commandé par un client ?

Une cardinalité minimale de 1 doit se justifier par le fait que les individus de l'entité en question ont
besoin de l'association pour exister (un client n'existe pas avant d'avoir commandé quoique ce soit,
donc la cardinalité minimale de l'entité clients dans l'association commander est 1).
 Définitions

 La cardinalité minimale (0 ou 1) exprime le nombre de fois minimum qu’une

 occurrence d’une entité participe aux occurrences d’une relation.

 La cardinalité maximale (1 ou n) exprime le nombre de fois maximal qu’une 

occurrence d’une entité participe aux occurrences de la relation.
 Si le maximum est connu, il faut inscrire sa valeur. Par exemple, si dans les règles
de gestion le client n’a le droit de commander qu’un maximum de 3 articles
en tout et pour tout, dans ce cas­là les cardinalités s’exprimeront de cette
façon : 1,3.
 Exercice :
Exercice

 Les cardinalités d'un mariage

 Déterminer les cardinalités de la relation mariage dans les 2 cas suivants :
 Pas de polygamie
 Avec polygamie
 Exercice

 Modélisons le fait qu’une mère élève des enfants.
 Nous avons deux entités Mères et Enfants :

 Modélisons le fait qu’un hôtel contenir des chambres.

 Correction

Des cardinalités :
Une mère peut élever un ou plusieurs enfants.
Un enfant peut être élevé par une et une seule mère.
 Exercice

 Exemple d’un dictionnaire de données (société qui a des filiales):

Nom Commentaire Entité type Identifiant

IdSte Identifiant société Numérique oui
RsSte Raison social société Texte Non
AdresseSt Adresse société Texte non
e
IdFil Identifiant Filiale Numérique oui
RsFil Raison social Filiale Texte non
AdresseFil Adresse Filiale Filiale Texte non
……………. …………….. ………….. …………….. ……………..
 Niveau conceptuel

Exemple: société qui a des filiales

Construire le MCD d’une société qui a des filiale .
.
 Exercices

Professeurs/Etudiants
On veut gérer les étudiants et les professeurs d’un
ensemble de formations dispensés par une université.
Un étudiant est identifié par son prénom, son nom et son
âge. Un étudiant suit une formation. Chaque formation a
un nom et une durée (nombre d’années). Elle est assurée
par un ensemble d’enseignants. Chaque enseignant est
connu par son nom, son prénom et la matière qu’il
enseigne.
Exercices
 Exercices

Entreprise/Employés

Dans une entreprise, un département est identifié par un

nom et caractérisé par une localisation.
Un employé est caractérisé par un numéro, son nom, son
grade et le département dans lequel il travaille.
Le numéro d’un employé est unique dans un département
mais pas dans l’entreprise.
Donner le MCD, en précisant les attributs.
 Exercices

Entreprise/Employés
 Exercices

Gestion des ordinateurs

Au service de l'intendance :
 Chaque ordinateur est identifié par un N° d'inventaire crée par l'intendant.
 Sa date d'achat doit être conservée, ainsi que son nom générique et sa marque.
 Les informations courantes sur le fournisseur de l'ordinateur sont notées.
 Certains sont couverts par un contrat de maintenance. Le type de garantie la date de
signature, sa durée sont indispensables. Un contrat peut couvrir plusieurs ordinateurs
et a un coût forfaitaire.
 Un contrat est toujours signé auprès d'une société dont on désire garder toutes les
coordonnées. Celle-ci est bien souvent le fournisseur.
 Exercices

Gestion des ordinateurs

.
 Les relations porteuses

Définition

Une relation est dite porteuse lorsqu’elle contient des propriétés.

.
Imaginons que l’on veuille connaître la quantité d’articles commandé
s par clients, nous nous rondons compte qu’il faut utiliser une
nouvelle propriete quantite. Cette nouvelle propriété depond de
clients d’articles ou des deux. La bonne réponse est que quantité
dépend des deux entité.
 Les relations porteuses

Voici le modèle conceptuel correspondant :

Une relation faisant intervenir deux entités est dite  binaire.
 Les relations porteuses

Si nous désirons connaître la date d’achat, il nous suffit de créer une entité Date à la  relation 
Commander.

Une relation faisant intervenir trois entités est dite  ternaire. 
 Associations plurielles

Deux mêmes entités peuvent être plusieurs fois en association

Dans cet exemple issu d'une agence immobilière, une personne peut être
propriétaire, résider principalement ou résider secondairement dans un logement
géré par l'agence. Les logements qui ne sont pas gérés par l'agence ne figurent
pas dans l'entité des logements, ce qui explique certaines cardinalités 0 du
schéma. Nous supposons également qu'un logement n'est détenu que par une
seule personne et que ce propriétaire figure obligatoirement dans l'entité des
personnes.
 Les relations réflexives

Définition
Une relation réflexive est une relation d’une entité sur elle­même.
Par exemple, on désire modéliser le fait qu’un employé peut diriger d’autres employés.

À la lecture de ce schéma, nous interprétons donc qu’un employé peut diriger zéro ou
plusieurs personnes et qu’un employé est dirigé par un et un seul autre employé.
 Les relations réflexives

Définition
Il est permis à une association d'être branchée plusieurs fois à la même entité, comme
l'association binaire réflexive de la figure ci-dessus.

Dans cet exemple, tout employé est dirigé par un autre employé (sauf le directeur général) et
un employé peut diriger plusieurs autres employés, ce qui explique les cardinalités sur le
schéma.
 Associations non binaires

Lorsqu'autour d'une entité, toutes les associations ont pour cardinalités maximales 1 au centre et n à
l'extérieur, cette entité est candidate pour être remplacée par une association branchée à toutes les
entités voisines avec des cardinalités identiques 0,n.
La deuxième condition qu'il faut impérativement satisfaire est la règle de normalisation des attributs
des associations (section suivante). Cette règle conduit parfois à l'apparition d'associations qui
établissent un lien sémantique entre trois entités ou plus.
 Associations non binaires

Sur l'exemple de la figure suivante issu d'un cinéma, l'entité projections est uniquement entourée
d'associations dont les cardinalités maximales sont : 1 côté projections et n de l'autre côté. De plus, la
donnée d'un créneau, d'un film et d'une salle suffit à déterminer une projection unique. On peut donc
la remplacer par une association projeter branchée aux trois entités salles, créneaux horaires et films.
On parle alors d'association ternaire.
 Règles de normalisation

Un bon schéma entités-associations doit répondre à neuf règles de

normalisation, que le concepteur doit connaître par cœur.
 Les bonnes pratiques dans un schéma entités-associations

Normalisation des entités (importante) : toutes les entités qui sont remplaçables par
une association doivent être remplacées (comme sur la figure précédente).

Normalisation des noms : le nom d'une entité, d'une association ou d'un attribut doit
être unique.
Conseils :
 pour les entités, utiliser un nom commun au pluriel (par exemple : clients) ;
 Pour les associations, utiliser un verbe à l'infinitif (par exemple : effectuer,
concerner) éventuellement à la forme passive (être commandé) et accompagné
d'un adverbe (avoir lieu dans, pendant, à) ;
 pour les attributs, utiliser un nom commun singulier (par exemple : nom, numéro,
libellé, description), éventuellement accompagné du nom de l'entité ou de
l'association dans laquelle il se trouve (par exemple : nom de client, numéro
d'article).
 Les bonnes pratiques dans un schéma entités-associations

(a) Deux entités homogènes peuvent être fusionnées.

(b) Si deux attributs contiennent les mêmes informations, alors la redondance induit non
seulement un gaspillage d'espace mais également un grand risque d'incohérence : ici, les
adresses risquent de ne pas être les mêmes et dans ces conditions, où faut-il livrer ?
 Les bonnes pratiques dans un schéma entités-associations

Normalisation des identifiants : chaque entité doit posséder un identifiant.

Conseils :
éviter les identifiants composés de plusieurs attributs (comme un identifiant formé par les
attributs nom et prénom), car d'une part c'est mauvais pour les performances et d'autres part,
l'unicité supposée par une telle démarche finit tôt ou tard par être démentie ;

préférer un identifiant court pour rendre la recherche la plus rapide possible (éviter notamment
les chaînes de caractères comme un numéro de plaque d'immatriculation, un numéro de sécurité
sociale ou un code postal) ;
éviter également les identifiants susceptibles de changer au cours du temps (comme les plaques
d'immatriculation ou les numéros de sécurité sociale provisoires).

Conclusion : l'identifiant sur un schéma entités-associations (et donc la future clé primaire dans
le schéma relationnel) doit être un entier, de préférence incrémenté automatiquement .
 Les bonnes pratiques dans un schéma entités-associations

Normalisation des attributs (importante) : remplacer les attributs en plusieurs exemplaires en

une association supplémentaire de cardinalités maximales n et ne pas ajouter d'attribut
calculable à partir d'autres attributs.

En effet, d'une part, les attributs en plusieurs exemplaires posent des problèmes d'évolutivité
du modèle (sur la figure ci-dessus à gauche, comment faire si un employé a deux adresses
secondaires ?) et d'autre part, les attributs calculables induisent un risque d'incohérence entre
les valeurs des attributs de base et celles des attributs calculés, comme sur la 2eme figure
 Les bonnes pratiques dans un schéma entités-associations

D'autres d'attributs calculables classiques sont à éviter, comme l'âge (qui est calculable à partir
de la date de naissance) ou encore le département (calculable à partir d'une sous-chaîne du
code postal).
Normalisation des attributs des associations (importante) : les attributs d'une association
doivent dépendre directement des identifiants de toutes les entités en association.
Par exemple, sur la figure 5 la quantité commandée dépend à la fois du numéro de client et du
numéro d'article, par contre la date de commande non. Il faut donc faire une entité
commandes à part, idem pour les livraisons (figure ci dessus. )
 Les bonnes pratiques dans un schéma entités-associations

L'inconvénient de cette règle de normalisation est qu'elle est difficile à appliquer pour les associations qui
ne possèdent pas d'attribut. Pour vérifier malgré tout qu'une association sans attribut est bien normalisée,
on peut donner temporairement à cette association un attribut imaginaire (mais pertinent) qui permet de
vérifier la règle.

Par exemple, entre les entités livres et auteurs de la figure précédente, l'association écrire ne possède pas
d'attribut. Imaginons que nous ajoutions un attribut pourcentage qui contient le pourcentage du livre écrit
par chaque auteur (du même livre). Comme cet attribut pourcentage dépend à la fois du numéro de livre et
du numéro d'auteur, l'association écrire est bien normalisée.

Autre conséquence de la normalisation des attributs des associations : une entité avec une cardinalité de 1,1
ou 0,1 aspire les attributs de l'association
 Les bonnes pratiques dans un schéma entités-associations

Normalisation des associations (importante) : il faut éliminer les associations fantômes (figure (a)),
redondantes (figure (b)) ou en plusieurs exemplaires (figure (c)).

(a) Les cardinalités sont toutes 1,1 donc c'est une association fantôme .

(b) Si un client ne peut pas régler la facture d'un autre client, alors l'association payer est inutile et doit
être supprimée (dans le cas contraire, l'association payer doit être maintenue).
 Les bonnes pratiques dans un schéma entités-associations

(c) Une association suffit pour remplacer les quatre associations participer en tant que…

En ce qui concerne les associations redondantes, cela signifie que s'il existe deux chemins pour se rendre d'une
entité à une autre, alors ils doivent avoir deux significations ou deux durées de vie différentes. Sinon, il faut
supprimer le chemin le plus court, car il est déductible à partir de l'autre chemin. Dans notre exemple de la
figure 15(b), si on supprime l'association payer, on peut retrouver le client qui a payé le règlement en passant par
la facture qui correspond.
Remarque : une autre solution pour le problème de la figure 15(b) consiste à retirer l'entité règlements et d'ajoute
une association régler avec les mêmes attributs (sauf l'identifiant) entre les entités clients et factures.
 Les bonnes pratiques dans un schéma entités-associations

Normalisation des cardinalités : une cardinalité minimale est toujours 0 ou 1 (et pas 2,
3 ou n) et une cardinalité maximale est toujours 1 ou n (et pas 2, 3…).

Cela signifie que si une cardinalité maximale est connue et vaut 2, 3 ou plus (comme
sur la figure 15(c) à droite, ou pour un nombre limité d'emprunts dans une
bibliothèque), alors nous considérons quand même qu'elle est indéterminée et vaut n.
Cela se justifie par le fait que même si nous connaissons n au moment de la
conception, il se peut que cette valeur évolue au cours du temps. Il vaut donc mieux
considérer n comme une inconnue dès le départ.
 Les bonnes pratiques dans un schéma entités-associations

Cela signifie également qu'on ne modélise pas les cardinalités minimales qui valent
plus de 1, car ce genre de valeur est aussi amené à évoluer. Par ailleurs, avec une
cardinalité maximale, l'association n'aurait aucune signification.

Dans un SGBD relationnel, nous pourrions assurer les cardinalités valant 2, 3 ou plus,
via l'utilisation de déclencheurs. Mais cette notion n'est pas abordée dans ce cours qui
se contente, au contraire, de décrire ce qu'il est possible de faire sans utiliser de
déclencheur.
 Les formes normales

À ces six règles de normalisation, il convient d'ajouter les trois premières formes
normales traditionnellement énoncées pour les schémas relationnels, mais qui
trouvent tout aussi bien leur place en ce qui concerne les schémas entités-
associations.
Première forme normale : à un instant donné dans une entité, pour un individu, un
attribut ne peut prendre qu'une valeur et non pas, un ensemble ou une liste de valeurs.
Si un attribut prend plusieurs valeurs, alors ces valeurs doivent faire l'objet d'une
entité supplémentaire, en association avec la première (figure ci -dessus).
 Les formes normales

Deuxième forme normale : l'identifiant peut être composé de plusieurs attributs, mais les
autres attributs de l'entité doivent dépendre de l'identifiant en entier (et non pas une partie de
cet identifiant).
Cette deuxième forme normales peut être oubliée si on suit le conseil de n'utiliser que des
identifiants non composés et de type entier. En vérité, elle a été vidée de sa substance par la
règle de normalisation des attributs des associations (paragraphe « Normalisation des attributs
des associations »).

Considérons malgré tout le contre-exemple suivant : dans une entité clients dont l'identifiant
est composé des attributs nom et prénom, la date de fête d'un client ne dépend pas de son
identifiant en entier mais seulement de prénom. Elle ne doit pas figurer dans l'entité clients, il
faut donc faire une entité calendrier à part, en association avec l'entité clients.
 Les formes normales

Troisième forme normale de Boyce-Codd (importante) : tous les attributs d'une entité doivent dépendre
directement de son identifiant et d'aucun autre attribut. Si ce n'est pas le cas, il faut placer l'attribut
pathologique dans une entité séparée, mais en association avec la première.

 Il y a redondance (et donc risque d'incohérence) dans les colonnes constructeur
et capacité
 Les formes normales

Par exemple, l'entité avions (figure ci-dessus à gauche) dont les valeurs sont données dans le
tableau 17, n'est pas en troisième forme normale de Boyce-Codd, car la capacité et le
constructeur d'un avion ne dépendent pas du numéro d'avion mais de son modèle. La solution
améliorée est donnée figure 18 à droite.

Application de la troisième forme normale de Boyce-Codd

En toute rigueur, la colonne constructeur ne doit pas être maintenue dans l'entité modèles
d'avion, mais doit être placée dans une entité séparée constructeurs (en association avec
modèles d'avion), afin d'éviter la redondance du nom d'un constructeur pour tous ses modèles.
 4. Règles d’usages

 Toute entité doit comporter un identifiant

 Toutes les propriétés de l’entité dépendent fonctionnellement de l’identifiant.

C’est-­à ­-dire que connaissant la valeur de l’identifiant, nous connaissons de faço

sûre et unique la valeur des propriétés associées. Si nous recherchons le client
numéro 5, nous devons récupérer le nom et le prénom du client numéro 5 et pas
ceux d’une autre personne.
 4. Règles d’usages

 Le nom d’une propriété ne doit apparaître qu’une seule fois dans le

modèle conceptuel des données. Si nous établissons une entité Client
et une nommée Prospects, nous ne devons pas retrouver la propriété
Nom dans les deux entités. Il faut préférer la dénomination suivante
Nom_client et Nom_prospect.

 Les propriétés résultantes d’un calcul ne doivent pas apparaître dans

le modèle conceptuel des données.
 Exercice

 un exercice (gestion de commandes)

 Les règles de gestion :
 Le magasin vend des produits a des clients.
 Les produits possèdent une référence (un code), un libelle et un prix unitaire.
 Les clients ont une identité (nom, prénom, adresse...).
 Les clients passent des commandes de produits. On mémorise
la date de la commande.
 Pour chaque commande, le client précise une adresse de livraison
 La commande concerne un certain nombre de produits, en une
quantité spécifiée pour chaque produit.
Exercice
 Exercice

 Une banque désire posséder un SGBD pour suivre ses

clients. Elle désire ainsi stocker les coordonnées de chaque
client (nom, prénom adresse),
 et les comptes dont elle dispose ainsi que leur solde (sachant
par ailleurs que certains compte ont plusieurs bénéficiaires).
On stockera également les opérations relatives à ces comptes
(retrait et dépôt, avec leur date et le montant).
Exercice
 Les dépendances fonctionnelles :

 Cas pratique :
Monique, sa fille Rachel et son gendre Marc gèrent un camping dans les Pyrénées orientales
. Le camping est ouvert du 1er juin au 30 septembre. Ils disposent de cinquante
emplacements sur un terrain d’une superficie totale de quarante hectares.
Ils sont équipés d’un logiciel spécialisé dans la réservation des emplacements qui fonctionn
e  très bien mais qui ne permet pas de gérer les achats de l’épicerie 
selon leurs règles de gestion. En effet, les vacanciers ne payent leurs achats qu’à la fin 
de leur séjour. Concrètement, les  achats sont inscrits manuellement sur une fiche bristol 
créée pour chaque famille
de vacanciers. À la fin du séjour, les cumuls sont réalisés et une facture manuelle concernan
t  les achats  est  établie.  Les  propriétaires  du  camping  souhaiteraient  disposer  d’un 
logiciel  permettant  d’automatiser 
la création de la facture grâce à la saisie journalière des achats.
 Voici une représentation de la fiche bristol :
 1) Dictionnaire des données

Nom Commentaire Entité type Identifiant

NumClient Numéro du Client Numérique oui
client
nom Nom du client Client Texte Non
prénom Prénom du Client Texte non
client
Adresse Adresse du Client texte Non
client
NumArticle Numero Article Article Numérique oui
Désignation Désignation Article Texte non
Article
PrixUnitaire Le prix unitaire Numérique Non
Qté La quantité Numérique Non
Date date date non
TotalLigne PrixUnitaire*Qté Numérique non
TotalFacture Somme des Numérique non
TotalLigne
 Les dépendance fonctionnelles :

Détermination des dépendances fonctionnelles ou DF

 À la lecture du dictionnaire nous pouvons déduire deux groupes d’informations 
distinctes. Un groupe caractérise les  clients, l’autre les produits.
 Les dépendance fonctionnelles :

Dépendances fonctionnelles pour les clients

 Posons ­nous la question :

 Quand je connais le numéro du client ,est ce que je connais de

façon sure et unique le nom du client ?
 Si la réponse est  « oui »  alors voici la transcription de la  DF :
 Les dépendance fonctionnelles :

Numcli  → Nom
Voici maintenant l’ensemble des DF élémentaires :
Numcli  → Prénom
Numcli  → Adresse
Numcli  → Code Postal
Numcli  → Ville
Dépendances fonctionnelles pour les articles :
CodeArticle  → Désignation
CodeArticle  → PrixUnitaire
 Les dépendance fonctionnelles :

 Les DF auraient pu s’écrire de la façon suivante :

Numcli → (Nom, Prénom, Adresse, Code Postal, Ville),
CodeArticle → (Désignation, PrixUnitaire).
 Les dépendance fonctionnelles :

 Intéressons ­nous à la donnée Qté : est­ce que la connaissance du code

de l’article nous permet de connaître de façon sûre et unique une
quantité ?
 Nous nous rendons compte que cette donnée Qté fait partie d’une
dépendance fonctionnelle composée.
 Voici une proposition :
(Numcli, CodeArticle, Date) → Qté
 Les dépendance fonctionnelles :

 Rappel

Les dépendances fonctionnelles ne concernent que les données non 
déduites. C’est pour cela que n’apparaissent  pas les données concernant
 le total par ligne et le total global de la facture qui sont des informations 
déduites par calcul.
 Les dépendance fonctionnelles :

 Graphe des dépendances fonctionnelles :

Le graphe des dépendances fonctionnelles est une étape intéressante car il

épure le dictionnaire en ne retenant que les données non déduites et
élémentaires et il permet une représentation spatiale de ce que sera le
futur modèle conceptuel des données.
 Les dépendance fonctionnelles :

 Voici le graphe des dépendances fonctionnelles :

 Les dépendance fonctionnelles :

4. Matrice des dépendances fonctionnelles

Une  autre  façon  de  représenter  les  dépendances  fonctionnelles  est  de  créer 
une  matrice.  Cependant, 
cette représentation ne présente pas le même intérêt que le graphe, qui lui perme
t une vision plus graphique du futur modèle conceptuel des données.
 Sources
But 1 2 3 4 5 6 7 8 9 10 11 12

1 Numcli

2 Nom 1
3 Prénom 1
4 Adresse 1
5 Code Postal 1
6 Ville 1
7 CodeArticle

8 Désignation 1
9 Prix 1
10 Date

11 Qté 1
12 Numcli, CodeArticle
, Date
  Une version simplifiée consiste à ne laisser que les colonnes sources ayant un  « 1 »  d’inscrit

Sources
But 1 7 12

1 Numcli

2 Nom 1
3 Prénom 1
4 Adresse 1
5 Code Postal 1
6 Ville 1
7 CodeArticle

8 Désignation 1
9 Prix 1
10 Date

11 Qté 1
12 Numcli, CodeArticle
, Date
 Conclusion

 Il est impératif de bien comprendre et bien maîtriser ces notions de

dépendances fonctionnelles, car elles sont les fondations des modèles
Merises qui vont suivre. Donc, il est nécessaire de passer du temps à
bien les définir pour éviter les erreurs de conception plus tard.
 Introduction au Modèle Logique des Données

 Le Modèle Logique des Données (MLD) est la suite normale du

processus Merise. Son but est de nous rapprocher au plus près du
modèle physique. Pour cela, nous partons du Modèle Conceptuel des
Données et nous lui enlevons les relations, mais pas n’importe
comment, il faut en effet respecter certaines règles. Voici la
procédure à suivre.
 Introduction au Modèle Logique des Données

1.  Cas (0, n), (1,1) ou (1,n), (0,1) :

Voici un modèle conceptuel de départ :

 Introduction au Modèle Logique des Données

 Nous devons supprimer la relation Elever, cela se réalise de façon tout à fa
it mécanique.
 L’entité ayant la cardinalité de type 1,1 ou 0,1 absorbe l’identifiant de l’entité
 la plus  forte (0, n ou 1, n). Cet identifiant est alors appelé  la clé étrangère.
 Introduction au Modèle Logique des Données

 Voici le Modèle Logique des Données découlant du Modèle conceptu
el précédent :
 Introduction au Modèle Logique des Données

 Cas (0,n), (0,n) ou (1,n), (1,n):

Illustrons ce cas sur le Modèle Conceptuel des Données suivant :
 Introduction au Modèle Logique des Données

 Voici le Modèle Logique des Données découlant du Modèle

conceptuel précédent :
 Introduction au Modèle Logique des Données

Continuons à modifier le Modèle Conceptuel des Données.

 Introduction au Modèle Logique des Données

Le Modèle Logique des Données en découlant sera :

 Introduction au Modèle Logique des Données

Modèle Logique des Données sur une relation réflexive
Reprenons ce Modèle Conceptuel des Données :
 Introduction au Modèle Logique des Données

Les règles de passage du MCD au MLD s’appliquent

toujours aussi mécaniquement. L’entité ayant la cardinalité la
plus faible absorbe l’identifiant de l’entité reliée. Ici, nous
n’avons qu’une seule entité, mais le principe est le même
nous devons donc dupliquer l’identifiant Numéro employé.
 Introduction au Modèle Logique des Données

 Règles simples de passage du MCD au MLD :

 L’entité  qui  possède  la  cardinalité  maximale  égale  à  1,  recevra  l’identifiant  ou  les 

identifiants  des  entités ayant les cardinalités maximales les plus fortes.

 Les  relations  ayant  toutes  leurs  entités  reliées  avec  des  cardinalités  maximales 

supérieures  à  1,  se transformeront en entité en absorbant les identifiants des

entités jointes .
 Introduction au Modèle Logique des Données

 Toute  relation  porteuse  de  propriétés  se  transformera  en  entité  et 
absorbera  comme  clé  étrangère  les  identifiants des entités qui lui sont
 liées.
 Introduction au Modèle Logique des Données

 Conclusion :

Comme vous l’avez ressenti, le passage du modèle conceptuel au Modèle Logique

des Données est purement mécanique, il suffit de respecter les quelques règles énoncées
plus haut. Il n’y a plus de travail de conceptualisation ou de réflexion proprement dit.
Lorsque nous réalisons un Modèle Logique des Données nous ne faisons que « détruire »
un Modèle Conceptuel des Données pour recréer un autre modèle.
 Introduction au Modèle Logique des Données

 Exercice «KaafKaaf»
 Transformez le MCD suivant, qui représente la facturation de la société
«KaafKaaf» en un MLD en respectant toutes les règles du passage MCD
à MLD.
 Introduction au Modèle Logique des Données

 Exercice «Gestion d'école»

 Transformez le MCD suivant, qui représente «la gestion d'une école» en
un MLD en respectant toutes les règles du passage MCD à MLD.
 Introduction au Modèle Logique des Données

 Exercice: bibliothèque
Une bibliothèque de prêts utilise les documents suivants
 Introduction au Modèle Logique des Données

on note les règles de gestions suivantes

Un livre existe en 1 ou plusieurs exemplaires dans une ou
plusieurs collections chez 1 ou plusieurs éditeurs.
 Un livre est emprunté ou non par 1 ou plusieurs adhérents
dans la limite du nombre d'exemplaires disponibles.
 Un adhérent peut emprunter un ou plusieurs livres mais il
ne peut pas emprunter plusieurs exemplaires du même
livre dans la même collection.
 Introduction au Modèle Logique des Données

 Questions :
Etablir :
1) le dictionnaire des données. (DD)
2) le graphe de dépendance fonctionnel (GDF)
3) le Modèle Conceptuel des Données M C D
4) le Modèle Logique des Données MLD
 Solution de l’Exercice :
1. dictionnaire de données
2. GDF
3. MCD