Analyse et conception des Systèmes

d’Information
Chap. 4. MCD et MLD

Dr. Coulibaly Tiékoura

©Tiekoura, 2020
 4.1.
MODELE CONCEPTUEL DE
DONNEES (MCD)
-----------------------------------------------------------------------

Le dictionnaire de données
Entités – Associations - cardinalités
Normalisation et construction du MCD
2
 4.1. Le Modèle Conceptuel de Données
4.1.1. Le dictionnaire de données (1/2): Formalisme
 Pendant la phase de conception, les données recueillies et spécifiées sont inscrites dans un
dictionnaire. Ce dictionnaire est un outil important car il constitue la référence de toutes les
études effectuées ensuite.
 Le dictionnaire de donnée est un tableau qui regroupe toutes les données du SI, pour
chaque donnée identifiée il faut préciser :
- Un nom : (n_ client, n_ facture, nomClient,. . . )
- Son type (numérique (entier, réel, date) ou alphanumérique)
- Sa longueur
- Son origine (quel document(s) ?)
- Sa nature : donnée calculée (C) ou non calculée (NC)
- Des observations :
 Des contraintes d'intégrité : exemples : salaire > smic, age > 0
 Des règles de calcul : exemple: nouvelle valeur du salaire > ancienne valeur
exemple: passer une commande : prix (NC) * quantité (NC) = prixCommande(C)
3
 4.1. Le Modèle Conceptuel de Données
4.1.1. Le dictionnaire de données (2/2): Exploitation
L’ensemble des données recueillies constitue le dictionnaire des données Dictionnaire de données global brut
brut. Toutes les données ne seront pas utilisées de la même manière.

 Pour la phase de modélisation des données, il convient d’épurer ce

dictionnaire brut :
a) des synonymes noms différents pour une même valeur (Num-C et
Code-C ; Num-CL et Mat-CL),
b) des polysèmes deux données sont polysèmes si elles ont le même nom
et expriment deux valeurs différentes
(le même nom « Quantité » pour deux données différentes : Qté_cdé
et Qté_fact). Il faut les renommer.
c) Les redondances: chaque propriété identifiée, n’apparaît qu’une seule
fois dans le modèle.
d) Supprimer les données calculées ;
Remarque : certaines informations calculées nécessitent d'être conservées,
on parle d'informations calculées et mémorisées (CM) ; exemple : N°client
automatique.
e) Ajouter les informations détectées par les règles de calcul :
Introduction de tauxTVA
f) Décomposer les données concaténées : (Adresse : Rue, ville et code 4
postal)
 4.1. Le Modèle Conceptuel de Données
4.1.2. Les entités (1/3): Entité ou objet
Une entité permet de modéliser un ensemble d'objets concrets ou abstraits de même nature

Après avoir réalisé le dictionnaire de données, il faut regrouper ces données par paquet homogène. Ces paquets
représentent les entités.
Une entité est caractérisée par un un identifiant et une suite d’information liée à cet identifiant appelée propriétés

Représentation graphique d’une entité :

Véhicule
n° immatriculation
couleur
puissance

5
Méthode de modélisation des données
 4.1. Le Modèle Conceptuel de Données
4.1.2. Les entités (2/3): Occurrence 4.1.2. Les entités (3/3): Propriétés
 Une occurrence ou tuple est une réalisation particulière de l’entité ou  Une propriété est une donnée élémentaire d'une entité.
un exemplaire de l’entité.  Une propriété est unique dans un MCD; et ne peut pas être
rattachée à plusieurs entités différentes.
 L’ensemble des occurrences forme l’entité désignée.  Le nom de la propriété est indiqué à l'intérieur du rectangle
qui représente l'entité correspondante.
Remarque : Le but d’une analyse est de pouvoir à partir d’un Véhicule
dictionnaire de donnée aboutir à une collection d’entité sans redondance,
et ayant des liens logiques entre elles tel que quelques soit la donnée n° immatriculation
celle-ci sera accessible à volonté. couleur
puissance

quelques exemples de Remarque: L’identifiant

clients C’est une propriété particulière de l’entité représentant
l’une des occurrences de l’entité ou de l’association.
ex: n° immatriculation est l’identifiant de l’entité
véhicule (dans le cas précédent)

 Chaque occurrence d’une entité doit avoir une valeur

différente pour l’identifiant
Chacun de ces clients représente une 6
occurrence de l'entité Client.
Méthode de modélisation des données
 4.1. Le Modèle Conceptuel de Données
4.1.3. Associations et cardinalités (1/11): Association 4.1.3. Associations et cardinalités (2/11): Types
d’Associations ou de relations
 L’association décrit un lien entre deux ou plusieurs entités.
1) Relation binaire. Une association entre deux entités
 Chaque relation possède un nom, généralement un verbe à
l'infinitif.
 Elle n'a pas d'identifiant propre, elle est implicitement
identifiée par les identifiants des entités auxquelles elle est
liée.

2) Partage d’une même collection

 Chaque entité joue un rôle dans l'association

- Les rôles devront être précisés si l’association relie une entité à elle-même.

7
Méthode de modélisation des données
 4.1. Le Modèle Conceptuel de Données
4.1.3. Associations et cardinalités (3/11): Types d’Associations ou de relations (suite)
3) Relation sur une même entité : relation 1-aire : entité récursive
Il faut ajouter un rôle à chaque à chaque élément de l’association  Une association ternaire peut se représenter par une combinaison
d’associations binaires

5) Associations réflexives: (n,n)

4) Relation n-aire
On peut avoir une association définie sur n entités (association n-aire ou
d’arité n ou de dimension n ou à « n pattes »).

8
Relation ternaire
Méthode de modélisation des données
 4.1. Le Modèle Conceptuel de Données
4.1.3. Associations et cardinalités (4/11): Types d’Associations ou de relations (suite)
6) Associations réflexives: relation récursives (n,n) non 8) Associations réflexives: [1, n]
symétrique

7) Associations réflexives: (n, n) avec propriétés
Relation ternaire
9) Entité faible:
Entité faible = entité dépendante d’une autre entité de cardinalité max 1.
On entoure sa cardinalité avec des parenthèses. L’entité dont elle dépend
s’appelle une entité forte (cardinalité max de n).
Exemple: un appartement à 1 numéro dans l’immeuble.
Son identifiant devient un identifiant relatif
car lors du passage au MLD, l’entité faible
récupère l’identifiant de l’entité forte, ce qui
donne pour clef primaire l’identifiant de
l’entité forte et l’identifiant de l’entité faible.
9
Méthode de modélisation des données
 4.1. Le Modèle Conceptuel de Données
4.1.3. Associations et cardinalités (5/11): Définition cardinalité 4.1.3. Associations et cardinalités (6/11): Typologie
des associations binaires
 Une relation est liée à chacune de ses entités par une patte. Sur la
patte, on indique les cardinalités.
 Les cardinalités précisent la participation de l'entité concernée à la
relation.
 Le premier nombre indique la cardinalité minimale, le deuxième la
cardinalité maximale.

10
Méthode de modélisation des données
 4.1. Le Modèle Conceptuel de Données
4.1.3. Associations et cardinalités (7/11): Quelques cardinalités 4.1.3. Associations et cardinalités (8/11): Interpréter des
cardinalités
 Une relation est liée à chacune de ses entités par une patte. Sur la
 Une relation hiérarchique ne peut être porteuse de propriétés
patte, on indique les cardinalités.
 Les cardinalités précisent la participation de l'entité concernée à la
relation.
 Le premier nombre indique la cardinalité minimale, le deuxième la
cardinalité maximale.
 Relation 1,1 - 0,1  Relation 0,n - 0,1
(Ou Relation hiérarchique) Que signifie Les cardinalités ? Ex: 1
Cardinalité minimale = 1 , chaque
client passe au moins une commande

Cardinalité maximale = n , chaque

client peut passer plusieurs (n)
commandes

Cardinalité minimale = 1 , chaque

client passe au moins une commande
 Relation 0,n - 0,n
(ou Relation N-P) Cardinalité maximale = n , chaque
client peut passer plusieurs (n)
commandes
Méthode de modélisation des données
 4.1. Le Modèle Conceptuel de Données
4.1.3. Associations et cardinalités (9/11): Cardinalité et 4.1.3. Associations et cardinalités (10/11): Cardinalité et
dépendance d’une relation proprietés d’une relation
On dit qu'une entité est indépendante par rapport à Une relation peut généralement être dotée de propriétés
une relation lorsque sa cardinalité minimale vaut
0, et dépendante par rapport à une relation lorsque Pourquoi est-ce qu’on
sa cardinalité minimale vaut 1. ne peut pas associer la
propriété Année à une
 Une relation ne peut pas être liée uniquement à
des entités ?
des entités dépendantes ayant en plus une
cardinalité maximale de 1 ! ! !

La modélisation suivante par Attention: Cette propriété

exemple n'est pas correcte peut même devenir une
partie de l'identifiant. Dans
Dans ce cas il ce cas, elle doit être
soulignée.
faut réunir les
propriétés des
deux entités dans Comme un professeur peut avoir la même classe pendant
une seule. plusieurs années , un identifiant composé de No_Matricule
et Code_Classe n'est pas suffisant, puisqu’il ne garantit pas 12
l’unicité. OnMéthode
y ajoute de
l'Année
modélisation des données
 4.1. Le Modèle Conceptuel de Données
4.1.3. Associations et cardinalités (11/11): Cardinalité et Application 1: interpréter le MCD 1 (cas a et b) et le MCD 2
proprietés d’une relation

Une relation à cardinalité (1,1) n'est jamais

porteuse de propriétés. Dans ce cas, les propriétés
migrent dans l'entité portant cette cardinalité (1,1). MCD 1

Pourquoi cette
modélisation n’est
pas correcte ?

Chaque facture ne possède qu’une seule date d’émission, ce qui

fait que la propriété Date_émission doit migrer dans l’entité
MCD 2
Facture.
Voici la modélisation
correcte:

13
Méthode de modélisation des données
 EXERCICES
EXERCICES A FAIRE
Exercice 1: Gestion de stock
1. Le magasin vend des produits à des clients.
2. Les produits possèdent une référence (un code), un libellé et un prix unitaire.
3. Les clients ont une identité (identifiant), nom, prénom, adresse.
4. Les clients passent des commandes de produits. On mémorise la date de la commande.
5. Pour chaque commande, le client précise une adresse de livraison.
6. La commande concerne un certain nombre de produits, en une quantité spécifiée pour chaque produit.

TAF: Etablir le dictionnaire de données.

Exercice 2: Pour un service achat, on peut recenser un certain nombre d’éléments suivants:
- Nom du fournisseur -Désignation de l’article - Unité de l’article
- Quantité commandé -Prix unitaire de l’article - Taux de TVA
- Date de la commande -Condition de livraison
- Numéro de la commande -Téléphone du fournisseur TAF: Etablir le dictionnaire de données.
- Quantité en stock de l’article - Adresse du fournisseur
14
- Référence de l’article - Adresse de livraison
 4.1. Le Modèle Conceptuel de Données
4.1.4. Normalisation et construction du MCD (1/10): Quelques règles
Règle 1: Deux entités qui doivent être reliées entre elles le Règle 3: Le nom de la relation doit représenter d’une manière
seront par le biais d’une relation concrète et significative l’information que l’on veut obtenir

Règle 2: Deux relations ne peuvent jamais être Règle 4: Un attribut est unique à une entité
directement reliées entre elles ou à une relation

15
Méthode de modélisation des données
 4.1. Le Modèle Conceptuel de Données
4.1.4. Normalisation et construction du MCD (2/10): Quelques règles
Règle 5: Les entités et les relations ne doivent contenir que des Règle 7: Pour conserver l’historique d’une donnée d’une entité, on forme
données élémentaires, donc ne pas contenir des résultats de une nouvelle entité avec cette donnée et on ajoute une période d’application.
calcul/traitement

Règle 8:
 Seule une association de type plusieurs à plusieurs (N:M) peut avoir des attributs
 Si vous avez des attributs sur une relation 1:N, il y a un problème !
Règle 6: Pour une occurrence donnée, une seule valeur doit être  L’attribut doit être placée sur une entité
attribuée à chaque attribut de l’entité ou de la relation  L’attribut doit être éliminé (ex. valeur
calculée)
 Note : Une relation N:M n’a pas
obligatoirement des attributs

16
Méthode de modélisation des données
 4.1. Le Modèle Conceptuel de Données
4.1.4. Normalisation et construction du MCD (3/10): Extensions du formalisme Entité-relation
 Certaines contraintes ne sont pas représentables par le seul Exemple: Pour une période d’emploi du temps (mercredi de 9h
formalisme de base (entité, association, propriétés, à 12h), un professeur ne fait un cours que dans une seule salle
cardinalités) mais correspond à une règle que doit satisfaire le (CIF).
modèle pour être fidèle et cohérent avec l’activité à Période, Professeur Salle
représenter.
Exemple: Pour une période d’emploi du temps, un professeur ne  Les CIF sont des cardinalités de la forme 1,1 –X,X
fait un cours que dans une seule salle (CIF)
Typologie des contraintes: La relation Appartenir
contraintes d’intégrité fonctionnelle (CIF) représente une CIF.
contrainte ensembliste
contrainte de valeur
contrainte structurelle
options de gestion

1) Les contraintes d’intégrité fonctionnelle (CIF)
 Une CIF existe entre les entités A et B si toute
occurrence de l’une détermine obligatoirement une et
une seule occurrence de l’autre.
Quand on détermine entre une relation et une entité une cardinalité qui
présente les valeurs 0,1 ou 1,1, alors cette relation est particulière et on
dit qu'elle représente une Contrainte d'Intégrité Fonctionnelle (CIF).
17
 4.1. Le Modèle Conceptuel de Données
4.1.4. Normalisation et construction du MCD (4/10): Extensions du formalisme Entité-relation
1) Les contraintes d’intégrité fonctionnelle (CIF) (suite) 2) Les contraintes ensemblistes
 Représentation graphique des CIF sur une relation  Contraintes inter-relations:
ternaire. Les types de contraintes d’intégrité relatives aux associations sont les
suivants :
 Contrainte de partition :XT
 Contrainte de totalité : T
 Contrainte d’exclusion : X
 Contrainte d’égalité (ou simultanéité) :S
 Contrainte d’inclusion. :I
Pour chaque contrainte, il est nécessaire de préciser
CIF: Pour une période d’emploi du temps,
• Son type
un professeur ne fait un cours que dans une seule salle (CIF)
• L’entité concernée par la contrainte (on l’appelle pivot)
• Les 2 associations liées par la contrainte
Professeur*Période  Salle
Ces règles ne sont pas implantées au niveau relationnel, mais à travers des
triggers
ou équivalents.

18
 4.1. Le Modèle Conceptuel de Données
4.1.4. Normalisation et construction du MCD (5/10): Dépendances fonctionnelle et normalisation
1) dépendances fonctionnelles (DF)
 Le but des dépendances fonctionnelles et de la théorie de la
normalisation est de s'assurer que le schéma
relationnel défini pour une base de données est correctement
construit. Un mauvais schéma relationnel peut en effet
entrainer des anomalies lors des manipulations.
 Considérons la relation Approvisionnement suivante :
Informations sur fournisseurs
redondantes.
Mettre à jour l'adresse du
fournisseur "Labaleine",
revient à vérifier que toute les
adresses de Labaleine sont
mises à jour. Cette solution
n'est pas raisonnable.
-> La BD va très rapidement
devenir incohérente car il est
Cette relation est mal construite probable d'oublier d'actualiser
l'information partout où c'est
nécessaire.
2) Définition de la DF
Un attribut (ou groupe d'attributs) B d'une table R est fonctionnellement
dépendant d'un autre attribut (ou groupe d'attributs) A de R si, à tout instant,
chaque valeur de A n'a qu'une valeur associée de B.
on note: A -> B. Et on lit: A détermine B ou B dépend fonctionnellement
de A
Exemple: Soit la table Ligne_de_commande (n° commande, n° article,
désignation, qté cmdée)
On a les dépendances fonctionnelles suivantes :
 n° article -> désignation
(à une valeur de n° article ne correspond qu'une valeur de désignation) ;
 (n° commande, n° article) -> qté cmdée
(à un couple de valeurs n° commande et n° article, ne correspond qu'une
valeur de qté cmdée).
19
 4.1. Le Modèle Conceptuel de Données
4.1.4. Normalisation et construction du MCD (6/10): Dépendances fonctionnelle et normalisation
3) Propriétés des DF: 4) Graphe des DF
Les dépendances fonctionnelles sont : On peut représenter un ensemble de DFE par un graphe orienté (ou plus
 réflexivité (A -> A) ; précisément un réseau de Pétri), tel que les nœuds sont les attributs et les arcs
 transitivité (A -> B et B -> C alors A -> C). les DFE (avec un seul attribut en destination de chaque arc et éventuellement
plusieurs en source).
 Remarque: Clé primaire:
La clé primaire d'une table est un attribut (ou un ensemble Exemple 1:
d'attributs) tel que tous les autres attributs (non-clés) de la table Soit la relation Voiture(NVH, Marque, Type, Puis, Couleur) avec l'ensemble
sont en dépendance fonctionnelle avec la clé primaire. des DF:
F = {NVH→Type,Type→Marque, Type→Puis, NVH→Couleur}. On peut
Exemples : représenter F par le graphe ci-dessous :
Soit la Table Client (n° client, nom, adresse) ; on a les
dépendances fonctionnelles : Exemple 2: Soit la relation CodePostal(Code, Ville, Rue ) avec l'ensemble
•n° client -> nom ; des DF F={Code→Ville, (Ville,Rue)→Code}. On peut réprésenter F par le
•n° client -> adresse. graphe ci-dessous :

20
 4.1. Le Modèle Conceptuel de Données
4.1.4. Normalisation et construction du MCD (7/10): Normalisation
Comment normaliser ces relations en 1FN?
Les formes normales ont Solution 1: Créer autant d’attributs que le
pour objectif de permettre nombre maximum de valeurs multivaluées
la décomposition de (stockage horizontal)
relations sans perdre
d'informations, à partir de Solution 2: Créer une nouvelle relation
la notion de dépendance comportant la clef de la relation initiale et
fonctionnelle. On en l’attribut multivalué puis éliminer
distingue 6. l’attribut multivalué de la relation initiale
(stockage vertical)
Inconvénients:
Solution 1: stockage de valeurs nulles, impossibilité de stocker plus de valeurs que prévu
 Première forme normale (1FN): Solution 2: opération de jointure, lourdeur des auto-jointures.

Une relation est en première forme normale (1FN) Avantages:

si tous ses attributs sont atomiques (monovalués).
Elle consiste simplement à éviter les domaines
composés de plusieurs valeurs.
Exemple: Ci-dessous 2 exemples
de relations non en 1FN:
Solution 1: tout est dans la même relation (pas de jointure)
Solution 2: pas de valeur nulle, pas de limite au stockage
Préférences:
Solution 1: quand le nombre de valeurs de l’attributs multivalué est constant ou que le
nombre max de valeur est faible (très peu de valeurs nulles) 21
Solution 2: dans les autres cas.
 4.1. Le Modèle Conceptuel de Données
4.1.4. Normalisation et construction du MCD (8/10): Normalisation
 Deuxième forme normale (2FN) :
Une relation est en 2FN si et seulement si:
 Elle est en 1FN
 Tout attribut non clef est en DF totale avec la clé
primaire (ne dépend pas d'une partie seulement de la
clé primaire).
Exemple:
Soit la relation Personne :
Personne(#NumeroEmployé, #Profession, Nom, Prénom,
Salaire)
Soit les DF suivantes sur cette relation :
NumeroEmployé, Profession→Nom
NumeroEmployé, Profession→Prénom
NumeroEmployé, Profession→Salaire
Profession→Salaire
Personne n'est pas en 2NF car Profession (une partie de clé)
détermine Salaire (un attribut qui n'appartient pas à une clé)
Pour avoir un schéma relationnel en 2NF, il faut alors
décomposer Personne en deux relations :
1. Personne(#NumeroEmployé, #Profession, Nom, Prenom)
2. Profession(#Profession, Salaire)
 Remarque: Si toutes les clés d'une relation ne contiennent qu'un
unique attribut, et que la relation est en 1NF,
alors la relation est en 2NF.
 Troisième forme normale (3FN) :
Une relation est en 3FN si et seulement si:
 elle est en 2FN
 et si tout attribut non clé ne dépend directement que de la clé primaire.
Exemple: Soit la relation Profession : Profession(#Profession, Salaire,
Prime)
Soit les DF suivantes sur cette relation :
Profession→Salaire
Profession→Prime
Salaire→Prime
22
 4.1. Le Modèle Conceptuel de Données
4.1.4. Normalisation et construction du MCD (9/10): Normalisation
Cette relation n'est pas en 3NF car Salaire, qui n'est pas une clé,
détermine Prime.
Pour avoir un schéma relationnel en 3NF, il faut décomposer
Profession :
1 Profession(#Profession, Salaire)
2 Salaire(#Salaire, Prime)
Ce schéma est en 3NF, car Prime est maintenant
déterminé par une clé.
Remarque:
 Une relation en 3NF permet des dépendances entre des
attributs n'appartenant pas à une clé vers des parties de clé
 Une relation en 3NF est forcément en 2NF
 Forme normale de Boyce-Codd (BCNF):
Une relation est en BCNF si et seulement si:
 Elle est en 3FN
 Toute source de DF est une clé primaire minimale.
Exemple:
Soit la relation Personne :
Personne(#N°SS, #Pays, Nom, Région)
Soit les DF suivantes sur cette relation :
N°SS,Pays→Nom
N°SS,Pays→Région
Région→Pays
Il existe une DFE qui n'est pas issue d'une clé et qui détermine un attribut
appartenant à une clé. Cette relation est en 3NF, mais pas en BCNF (car en
BCNF toutes les DFE sont issues d'une clé).
Pour avoir un schéma relationnel en BCNF, il faut décomposer Personne :
1. Personne(#N°SS, #Region, Nom)
2. Region(#Region, Pays)
Remarquons que les DF n'ont pas été préservées par la
décomposition puisque N°SS et Pays ne déterminent plus Région. 23
 4.1. Le Modèle Conceptuel de Données
4.1.4. Normalisation et construction du MCD (10/10): Construction du MCD
L'élaboration du MCD passe par les étapes suivantes :

1. La mise en place de règles de gestion (si celles-ci ne vous sont pas données),
2. L’Analyse de l'existant et élaboration du dictionnaire des données (épuré),
3. La recherche des dépendances fonctionnelles entre ces données,
4. Dégager les ‘entités naturelles’ grâce aux identifiants existants déjà dans l’organisation
5. Rattacher les propriétés aux entités
6. Recenser les associations entre entités et leur rattacher leurs éventuelles propriétés
7. Déterminer les cardinalités
8. Décomposer si possible les associations n-aires (cf. règles)
9. S'assurer de la conformité du modèle aux règles de construction (cf. règles)
10. Normaliser le modèle : s'assurer qu'il est en 3FN
24
 4.1. Le Modèle Conceptuel de Données
Exercice 1 (P1):
La société «Delta» désire informatiser son
système de facturation. Les factures
devraient se présenter de la façon
suivante:
Créez un MCD, qui permet de modéliser correctement le système
d'information nécessaire, sachant que:
• Un client peut bien sûr recevoir plusieurs factures, mais il
est uniquement considéré comme tel à partir du moment où
il reçoit sa première facture.
• Une facture concerne un et un seul client.
Exercice 1 (P2)
Il s'agit d'étendre le MCD de la partie 1.
Le responsable de la facturation de la société désire rendre les factures plus
informatives. Comme un client peut acheter plusieurs articles différents en
même temps, la facture devrait indiquer pour chaque article le numéro , un
libellé, le prix unitaire, la quantité vendue et le prix total pour ce type
d'article. Voici l'aspect que la facture devrait avoir:
Proposez un nouveau MCD qui reflète ces modifications, en respectant que:
Tous les articles disponibles sont stockés (p.ex. No=234 Libellé="Marteau"
PU=470 Luf.). Même si un article n'est pas encore considéré par une facture, il
existe dans le système d'information.
Méthode de modélisation des données
 4.1. Le Modèle Conceptuel de Données
Exercice 2 (P1): Gestion d’une école
Dans une école, on veut informatiser le système d'information
qui gère les classes.
Elaborez un MCD sachant que:
 Un élève est caractérisé par son no. matricule, son nom et
prénom, ainsi que sa date de naissance.
 Une classe est caractérisée par le nom de la classe (p.ex
13CG2) et par une indication du cycle (valeurs possibles:
"inférieur", "moyen", "supérieur").
 Il faudra prévoir de connaître la fréquentation des classes
des élèves sur plusieurs années consécutives.
 Un élève enregistré dans le système fréquente au moins une
classe au cours des années.
Exercice 2 (P2): Gestion d’une école
Il s'agit maintenant de concevoir une extension au MCD précédent qui
permet de représenter la situation suivante:
 La direction de l'école désire également saisir tous les professeurs dans le
système d'information. Un professeur est caractérisé par un code interne
unique (p.ex. Jemp Muller aura le code JEMU), son nom et prénom et la
matière qu'il enseigne. Nous supposons que chaque professeur
enseigne une seule matière.
 Modélisez le fait que chaque classe est enseignée chaque année par un ou
plusieurs enseignants. Un enseignant peut bien sûr donner des cours dans
plusieurs classes, mais peut également ne pas donner des cours pendant
une ou plusieurs années.
Méthode de modélisation des données
 4.2.
MODELE LOGIQUE DE
DONNEES (MLD)
-----------------------------------------------------------------------

Règles de transformation du MCD au MLD

Passage du MLD au MPD

27
 4.2. Le Modèle Logique de Données
4.2.1. Règles de transformation du MCD au MLD (1/5)
 Le modèle logique des données (MLD) consiste à décrire la
structure de données utilisée sans faire référence à un langage de
programmation. Il s'agit donc de préciser le type de données
utilisées lors des traitements.

Ainsi, le modèle logique est dépendant du type de base de données

utilisé. Il est toujours basé sur un MCD donné.
Un MLD est essentiellement composé de tables logiques reliées entre
elles par des flèches.

28
 4.2. Le Modèle Logique de Données
4.2.1. Règles de transformation du MCD au MLD (2/5)
2) Transformation des relations binaires du type
1) Transformation des entités (x,n) –(x,1)
 Afin de représenter la relation, on duplique la clé primaire de la
table basée sur l'entité à cardinalité (x,n) dans la table basée sur
 Toute entité est transformée en table. Les propriétés de
l'entité à cardinalité (x,1).
l'entité deviennent les attributs de la table.
L'identifiant de l'entité devient la clé primaire de la
table.

Cet attribut est appelé clé étrangère. Les deux tables sont liées par une flèche
nommée selon la relation, qui pointe de la table à clé étrangère vers la table qui
contient la clé primaire correspondante.
L'attribut No_Auteur qui est clé primaire de la table Auteur, devient clé
étrangère dans la table Livre.
 4.2. Le Modèle Logique de Données
4.2.1. Règles de transformation du MCD au MLD (3/5):
3) Transformation des relations binaires du type 4) Relation binaire (0,1)-(0,1)
(x,1) –(x,1)
 On duplique la clé d'une des tables dans l'autre. Lorsque la relation
 Nous devons distinguer plusieurs cas. Sachant qu'une contient elle-même des propriétés, celles-ci deviennent également
relation binaire du type (1,1)-(1,1) ne doit pas exister il attributs de la table dans laquelle a été ajoutée la clé étrangère.
nous reste les 2 cas suivants:
• Relation binaire (0,1)-(1,1)
• Relation binaire (0,1)-(0,1)
a- Relation binaire (0,1)-(1,1)
On duplique la clé de la table basée sur l'entité à cardinalité
(0,1) dans la table basée sur l'entité à cardinalité (1,1).
Le No_Client, qui est clé primaire de la table Client, devient
clé étrangère dans la table Carte_Membre
 4.2. Le Modèle Logique de Données
4.2.1. Règles de transformation du MCD au MLD (4/5):
5) Transformation des relations binaires du type
(x,n) –(x,n)
 On crée une table supplémentaire ayant comme clé
primaire une clé composée des clés primaires des 2
tables. Lorsque la relation contient elle-même des
propriétés, celles-ci deviennent attributs de la table
supplémentaire. Une propriété de la relation qui est
soulignée devra appartenir à la clé primaire composée de
la table supplémentaire.
On crée une table Porter, qui contient comme clé primaire une clé
composée de No-Commandeet Code_Article.
Elle contient également la propriété Quantité issue de la relation Porter
6) Transformation des relations ternaires
 On crée une table supplémentaire ayant comme clé primaire une clé composée
des clés primaires de toutes les tables reliées. Cette règle s'applique de façon
indépendante des différentes cardinalités. Lorsque la relation contient elle-
même des propriétés, celles-ci deviennent attributs de la table supplémentaire.
Une propriété de la relation qui est soulignée devra appartenir à la clé
primaire composée de la table supplémentaire.
La table
Enseigner
contient une clé
composée de
No_Enseignant,
Code_Matièreet
Nom_Classe.
 4.2. Le Modèle Logique de Données
4.2.1. Règles de transformation du MCD au MLD (5/5)
7) Transformation de plusieurs relations entre 2 8) Transformation de l'identifiant relatif
entités  Sachant que l'entité dépendante est toujours liée à la relation par les
cardinalités (1,1), nous pouvons appliquer les règles générales. Dans
 Les règles générales s’appliquent. chaque cas, la table issue de l'entité dépendante contient donc comme clé
étrangère, la clé primaire de l'autre table.
 L'identification relative est représentée par le fait que la table issue de
l'entité dépendante contient une clé primaire composée, constituée de la
clé primaire transformée de l'identifiant de cette entité et de la clé
étrangère.
 4.2. Le Modèle Logique de Données
4.2.2. Passage du MLD au MPD (1/1):
Le modèle physique des données (MPD) est la
traduction du modèle logique des données (MLD)
dans une structure de données spécifique au système
de gestion de bases de données (SGBD) utilisé.

Le passage MLD à MPD se fait par les étapes

suivantes:
 Implémentation physique de chaque table du MLD
dans le SGBD utilisé.
Utilisation d'une ou de plusieurs interfaces graphiques, qui nous aident
 Pour chaque table, indiquer au SGBD quel(s) dans la création des tables physiques, dans la définition des clés
champ(s) constitue(nt) la clé primaire. primaires et dans la définition des relations
 Pour chaque table, indiquer au SGBD la (les) clé(s)
étrangère(s), et la (les) clé(s) primaire(s)
correspondante(s).