Définition

 Le modèle conceptuel des données (MCD) a pour but

d'écrire de façon formelle les données qui seront utilisées
par le système d'information et les relations entre eux. Il
s'agit donc d'une représentation des données, facilement
compréhensible, permettant de décrire le système
d'information à l'aide d'entités.
Entité
 Une entité est la représentation d'un élément matériel ou
immatériel ayant un rôle dans le système que l'on désire
décrire.

 Dans une entité, on met les informations nécessaires et

suffisantes pour caractériser cette entité. Ces données de base
pour l’entité sont appelées PROPRIETES ou ATTRIBUTS

 Ex : Personne (code, nom, tel, email, …)

Propriété
 Une propriétés est dite CONCATENEE s’elle est décomposable
en d’autres propriétés
 Ex: Adresse : rue + code postal + ville

 Une propriété est dite ELEMENTAIRE s’elle ne peut pas se

décomposer
 Ex: rue, code postal et ville

 Une propriété peut être mémorisée ou calculée (c’est

déductible des propriétés mémorisées)
 Solde = différence entre Débit et Crédit
Propriété
 On distingue 3 types de propriétés:
 Les code : a tout objet existant est associé une valeur et une
seule du code. A deux objets correspond deux valeurs distincts
du code
 Les libellés : ce sont des données alphanumériques, qualitatives,
de simples chaînes de caractères, ne pourront participer à aucun
calcul mais bien pour faire des tris ou des comparaisons.
Ex: Nom d’un client
 Les montants : ce sont des données numériques, quantitatives,
qui pourront participer à des calculs.
Ex: Prix d’un produit
Classification des entités
 Entité permanente
 c’est une entité que l’on conserve en permanence dans la base
d’information mais qu’on peut modifier à tout moment. Elle
correspond à la structure. Elle ne représente pas des faits
Ex: Client : on conserve ses propriétés en permanence
 Les propriétés d’une entité permanente peuvent changer mais
l’entité elle-même est stable
 Entité de type «mouvements»
 Une entité de types «mouvements» est le souvenir d’un
événement dans le SI
Ex: entité Commande (code, date), mémorisé dans le système
suite à l’événement PASSATION DE COMMANDE.
 Une fois la commande est mémorisée on peut plus la modifier
Relation
 Une relation (appelée aussi parfois association) représente les
liens sémantiques qui peuvent exister entre plusieurs entités.
Ex: « Said est mariée à Salima » exprime la relation « est marié à » qui
est une association entre les entités Said et Salima

 A une relation peuvent être rattachées des propriétés,

exactement comme pour les entités
Ex: la relation CONCERNE peut être porteuse de la propriété quantité
exprimant pour chaque produit commandé (concerné par la
commande) la quantité commandée.
Classification des relations
 Relation permanente
Ce sont des relations entre des entités permanentes qu’on conserve
en permanence et dont on peut modifier les propriétés à tout
moment
Ex: Employé (code, nom) Affecté à (début, fin) Service (code, intitulé)

 Relation de type mouvements

Ce sont des relations entre des entités permanentes ou de
mouvements qui représentent le souvenir d’un événement
Ex: Commande (num, date) Se Compose de (quantité) Produit (réf,
désig, prix)
Remarque
 Il ne faut pas confondre entre:
 ENTITE-TYPE et OCCURRENCE de l’entité-type
 PROPRIETE-TYPE et VALEUR de propriété
 RELATION-TYPE et OCCURRENCE de la relation

Ex: COMMANDE (numéro 123, du 08/10/02)

CONCERNE (quantité de 3 unités)
PRODUIT (Manteau de référence 456 à 100$)
Formalisme de représentation schématique
Nom d’entité-type Nom de Relation-type Nom d’entité-type

SALARIE AFFECTER A SERVICE

Code, nom Code.Num Num, intitulé
Date affectation
Noms propriétés-type Noms propriétés-type Noms propriétés-type
Identifiant souligné Identifiant souligné

•L’identifiant est toujours souligné

•L’identifiant d’une relation est le produit cartésien (concaténation)
des identifiants des objets participant à la relation. Par exemple,
l’identifiant de la relation AFFECER A est : code.num
•La relation AFFECTE A est définie sur la collection {SALARIE, SERVICE}
Formalisme de représentation schématique
Exemple:
SALARIE SERVICE
AFFECTE A
A01, Ali 125, comptabilité
12/01/85

SALARIE
AFFECTE A
A12, Mohammed
23/02/90

SALARIE SERVICE
AFFECTE A
A02, Réda 260, commercial
16/06/90

Dans cet exemple, on voit que Ali et Mohammed sont affectés à la

comptabilité et martin au service commercial
Formalisme de représentation schématique
 On représente souvent les occurrences d’une entité sous forme
d’un tableau . Les lignes correspondent aux occurrences et les
colonnes correspondent aux valeurs des propriétés

CNE Nom Prénom Adresse

2245 Aarab Said Adresse 1
1587 Réda Said Adresse 2
2962 Youssef Kamal Adresse 3
Différents types de relations
Binaire:

Client HABITER REGION

Réflexive:

PERSONNE MARIER A
Différents types de relations
Ternaire:
TYPE VEHICULE TARIF REGION

USAGE
N-aire ou multiple:

QUANTITE DATE

PRODUIT PRIX REGION

CONDITION
Dimension d’une relation
La dimension d’une relation est le nombre d’occurrences d’entités
concernés par une occurrence de la relation. Elle est supérieur ou
égale au nombre d’entités de la collection
Ex:
-une relation de dimension 2 est une relation binaire
LIVRE ECRIT PAR AUTEUR

PERSONNE MARIE PAR

-une relation de dimension 3 est une relation ternaire

PERSONNE A VENDU A PRODUIT

-une relation de dimension n est dite n-aire

 Fonctionnalité d’une relation
On définit la fonctionnalité d’une relation par rapport à deux entités X et Y
On distingue les relation:
- 1 a 1 (1-1) : à toute occurrence de X ne correspond qu’une seule
occurrence de Y et réciproquement
Homme Est marié à Femme

- 1 a plusieurs (1-n) : à toute occurrence de X correspond une ou

plusieurs occurrences de Y et à toute occurrence de Y correspond une
seule de X
Véhicule Est possédé Personne

- plusieurs a plusieurs (n-n) : à toute occurrence de X correspond une

ou plusieurs occurrences de Y et réciproquement
Client commandé Produit
Totalité & Partialité
Une relation mettant en jeu les entités X et Y est dite:

 Totale : si aucune occurrence de X et aucune occurrence de Y ne

peuvent exister sans participer à une occurrence de la relation
Ex: Enseignant --- Enseigne --- Classe

 Partielle : si certaines occurrences de ou de certaines de Y peuvent

n’être impliquées dans aucune occurrence de la relation
Ex: Personne --- Possède --- Voiture
Cardinalité
 La cardinalité Couple de valeurs représentant la fréquence (min et
max) de participation d’une occurrence d ’entité à une association
 Elle permet d’exprimer la fonctionnalité et la totalité / partialité d’une
relation

Cardinalité minimum d’une relation est le nombre minimum de fois

où chaque occurrence d’une entité participe à la relation:
 0 : Certaines occurrences de l’entité peuvent ne pas participer à la
relation. (relation partielle)
 1 : Toute occurrence de l’entité participe obligatoirement à l’association
 n : implique que toute occurrence d’entité participe obligatoirement à n
occurrences de la relation

Les cardinalités non nulles correspondent à des relations totales

Cardinalité
Cardinalité maximum d’une relation est le nombre maximum de fois
où chaque occurrence d’une entité peut participer à la relation:
 1 : Toute occurrence de l’entité ne peut participer qu’à une occurrence de
la relation, au plus
 n : implique qu’une occurrence d’entité peut être impliquée dans un
maximum de n occurrences de la relation

Les cardinalités traduisent aussi les règles de gestion. Ce sont des règles
propres au SI étudié, qui expriment des contraintes d’intégrité du modèle
Représentation graphique

1, 1 1, n
Client Habiter Région

Cardinalité {min, max}

 Cardinalité
Exemple
Un homme est fils d’au moins et d’au plus une femme, c.-à-d. d’une femme
et d’une seule. Une femme peut n’avoir pas d’enfants (0) ou au contraire
en avoir plusieurs (n)
1, 1 0, n
Homme Est fils de Femme

Un enseignant fait au moins un enseignement. Il peut en faire plusieurs.

Une matière peut ne pas être enseignée. Si elle l’est, elle peut l’être
plusieurs fois
1, n 0, n
Enseignant Enseigne Matière

Une classe a au moins un enseignant et peut en avoir plusieurs

1, n 1, n
Enseignant Enseigne Classe
Règles de gestion
 Les règles de gestion. Ce sont des règles propres au SI étudié, qui
expriment des contraintes d’intégrité du modèle
Ex: dans un MCD d’une école les règles de gestion peuvent être les
suivantes:
 RG1: tout professeur enseigne en principe au moins une matière, mais
certaines d’entre eux peuvent être dispensés d’enseignement en raison
de leurs travaux de recherche
 RG2: toute matière est enseignée dans au moins une classe
 RG3: toute classe a au moins trois enseignants
1, n Matière
0, n
Professeur Enseigne

3, n Classe
Règles de gestion
 Les contraintes statiques
 Sur une propriété : formes, liste de valeurs possibles, fourchettes de
valeurs admissibles
 Sur divers propriétés d’une même relation ou entité: Commande (Num,
date_cmd, date_lvrs), on doit toujours avoir date_cmd < date_lvrs
 Sur les cardinalités
 Sur les dépendances fonctionnelles
 Contraints dynamiques
les contraintes dynamiques expriment les règles d’évolution et
portent sur le passage du SI d’un état à un autre
Ex: le salaire d’un employé ne doit pas diminuer
Les dépendances fonctionnelles
Dépendances Fonctionnelles entre propriétés
 On dit que 2 propriétés a et b sont reliés par une dépendance
fonctionnelle (a --- df --- > b) si la connaissance de la valeur de a
détermine une et une seule valeur de b
Ex: Code-client --- df --- > Nom-client
 La connaissance du code-client détermine une et une seule valeur
de nom-client. Autrement dit, si on connaît le code du client, on doit
pouvoir connaître son nom et celui-ci sera unique
 La réciproque est fausse. Le nom du client ne permet pas de
déterminer son code du client, car plusieurs clients peuvent avoir le
même nom. Nom-client --- df --- > Code-client n’est pas vraie
Les dépendances fonctionnelles
Dépendances Fonctionnelles entre propriétés
Dépendance fonctionnelle élémentaire

 On parle de DFE entre les propriétés a et b (a -> b) si (a --- df --- > b) et

si aucune partie de a ne détermine b
Ex: Code-client + Nom-client --- df --- > Adresse-client, n’est pas
élémentaire puisque la connaissance du Code-client (partie de Code-
client + Nom-client) suffit pour déterminer l’Adresse-client
Code-client --- df --- > Adresse-client est élémentaire et on peut écrire
Code-client -> Adresse-client
Les dépendances fonctionnelles
Dépendances Fonctionnelles entre propriétés
Dépendance fonctionnelle élémentaire directe

 On dit que la propriété b dépend fonctionnellement de a par une

dépendance fonctionnelle directe si cette dépendance est
élémentaire (a -> b) et s’il n’existe pas de propriété c telle que
a --- df --- > c et c --- df --- > b (c.à.d. on élimine toute transitivité)
Ex:
N-prof -> Code-matière
Code-matière -> Nom-matière
N-prof -> Nom-matière
les 2 premières dépendances sont directes, mais la troisième ne
l’est pas en raison de la transitivité
(N-prof -> Code-matière -> Nom-matière)
Les dépendances fonctionnelles
Dépendances Fonctionnelles entre entités
 On dit qu’il existe une dépendance fonctionnelle entre deux entités A
et B et on note (A -> B) si toute occurrence de A détermine une et une
seule occurrence de B
 La cardinalité maximum 1 correspond toujours à une Df
 On peut assimiler les dépendances fonctionnelles entre entités aux
dépendances fonctionnelles entre les identifiants de ces entités
Ex:
Commande ---> Client
est assimilé à
N-cmd ---> Code-client
 Les dépendances fonctionnelles
Propriétés des Dépendances Fonctionnelles

 Réflexivité : a --- df ---> a

 Projection : a --- df ---> b + c  a --- df ---> b et a --- df ---> c
 Augmentation : a --- df ---> b  ∀ c : a + c --- df ---> b
 Additivité : a --- df ---> b et a --- df ---> c  a --- df ---> b + c
 Transitivité : a --- df ---> b et b --- df ---> c  a --- df ---> c
 Pseudo-tansitivité : a --- df ---> b et b + c --- df ---> d  a + c --- df ---> d
 La normalisation des entités
 L’objectif de la normalisation est de construire, par rapport au MCD, un
schéma cohérant. Un mauvais schéma peut conduire à un certain
nombre d’anomalies pendant la phase d’exploitation physique.

 Pour qu’un modèle correspondant à un MCD soit normalisé, il faut qu’il

respecte certaines contraintes appelées les formes normales. Les
formes s’appuient les dépendances fonctionnelles entre les attributs

 La normalisation élimine les redondances, ce qui permet:

 Une diminution de la taille de la base de donnée sur le disque
 Une diminution des risques d’incohérence
 D’éviter une mise à jour multiple des mêmes données
 La normalisation des entités
Première forme normale (1FN)

Une entité est normalisée en première forme normale si:

1. Elle possède une clé qui identifie formellement chaque occurrence
2. Chaque attribut dépend fonctionnellement de la clé
3. Chaque attribut ne peut avoir qu’une seule valeur par enregistrement
4. Aucun attribut n’est décomposable en plusieurs attributs
 La normalisation des entités
Première forme normale (1FN) : Exemple

CLIENT (nom-client, adresse)

 Cette entité n’est pas en 1FN, car il n’y a pas de clé (plusieurs clients
peuvent avoir le même nom)
 D’autre part adresse-client est sans doute la concaténation de rue et
ville et ne constitue alors pas une propriété élémentaire
 Il doit être :
CLIENT (code_client, nom, rue, ville)
 La normalisation des entités
Deuxième forme normale (2FN)

Une entité est normalisée en deuxième forme normale si et seulement si :

1. Elle est en 1FN
2. Toute propriété de l’entité doit dépendre de la clé par une dépendance
fonctionnelle élémentaire. Autrement dit, toute propriété de l’entité
doit dépendre de tout l’identifiant

Conséquence : toutes les entités qui n’ont qu’un seul attribut clé, sont
en 2FN si elles sont en 1FN
 La normalisation des entités
Deuxième forme normale (2FN) : Exemple

LIGNE (num_cmd.num_article, desc_article, quantité_cmd)

 L’identifiant de cette entité est la concaténation de num_cmd et
num_article
 Cette entité n’est pas en 2FN car la dépendance fonctionnelle
num_cmd.num_article --- df ---> desc_article n’est pas élémentaire,
puisque « desc_article » ne dépend que d’une partie de la clé
 Elle doit être:
LIGNE (num_cmd)
liée par la relation « concerne (quantité) » à l’entité
ARTICLE (num_article, desc_article)
 La normalisation des entités
Troisième forme normale (3FN)

Une entité est normalisée en troisième forme normale si et seulement si :

1. Elle est en 2FN
2. Toute propriété de l’entité doit dépendre de la clé par une dépendance
fonctionnelle élémentaire directe, c’est-à-dire qu’aucune propriété de
l’entité ne doit dépendre de la clé par transitivité
 La normalisation des entités
Troisième forme normale (3FN) : Exemple

CLIENT (code_client, nom_clien, code_categ, nom_categ)

 Cette entité n’est pas en 3FN car la dépendance fonctionnelle
code_client --- df ---> nom_categ n’est directe du fait de la transitivité
code_client --- df ---> code_categ ---> nom_categ
 Ca doit être :
CLIENT (code_client, nom_client)
liée par la relation « appartient à » à l’entité
CATEGORIE (code_categ, nom_categ)
 Application des règles

 Si l’une des 3 règles n’est pas vérifiée, cela indique que le modèle n’est
pas normalisé, il faut alors apporter des modifications pour que les 3
règles soient vérifiées, si on souhaite la normalisation de notre schéma

 On vérifie les règles dans l’ordre. Si la première forme normale n’est pas
respectée, pas la peine de vérifier la 2FN. Et si la 2FN n’est pas vérifiée,
inutile de vérifier la 3FN
 Exemple de vérification
Soit le MCD suivant:
Client Passer commande Représentant
0, n 0, n
code_client N_bon_cmd code_rep
nom_client date, qté nom_rep

La relation Passer Commande n’est pas vérifié, car il peut y avoir plusieurs de la
quantité dans une commande passée par un client à un représentant. La
quantité ne dépend pas seulement du client et de représentant mais aussi du
produit commandé. Autrement dit :

Dans une relation, les propriétés doivent dépendre fonctionnellement

des identifiants des entités concernées par la relation. La
concaténation de ces identifiants constitue l’identifiant de la relation.
 Exemple de vérification
Amélioration du MCD :
Client Passer commande Représentant
0, n 0, n
code_client N_bon_cmd code_rep
nom_client date nom_rep
0, n
Produit
Commander produit
réf
qté
desig, pu

Mais dans la relation COMMANDER PRODUIT, la quantité ne dépend pas seulement

du client et du produit mais aussi du n° de bon de commande (un client peut
passer plusieurs commandes du même produit). Le n° de commande n’est pas
connu si on connaît CLIENT, PRODUIT et REPRESENTANT car il peut y avoir plusieurs
bons de commande pour un client, un représentant et un produit donnés. La règle
de vérification n’est pas respecté.

Il faut, en fait, créer l’entité COMMANDE. D’où le MCD

 Exemple de vérification
Amélioration du MCD :

Client Passer commande Représentant

0, n 0, n
code_client date code_rep
nom_client nom_rep
0, n 1, 1
Commande
Commander produit 1, n
N_bon_cmd
qté

0, n
Produit
réf
desig, pu
Exemple de vérification
Normalisation des relations
 Chaque propriété de la relation doit dépendre fonctionnellement de
l’ensemble des identifiants des entités qui participent à la relation,
mais d’aucun sous ensemble de cet ensemble
 Il doit y avoir une dépendance pleine de propriétés de la relation par rapport
aux entités
Exemple : dans le MCD précédant, on a N_bon_cmd -> date
car la date de la commande peut être connue si on connaît le n° de bon de
commande.
 La propriété date dépend de n° de bon de commande et donc d’un sous-
ensemble de la concaténation code_client + code_représentant + n_bon_cmd
et il n’y a pas de dépendance pleine par rapport à l’ensemble des entités
CLIENT, REPRESENTANT et COMMANDE qui participent à ma relation PASSER
COMMANDE
 La date est une propriété qui doit migrer dans l’entité COMMANDE
 Exemple de vérification
Amélioration du MCD :

Client Passer commande Représentant

0, n 0, n
code_client code_rep
nom_client nom_rep
0, n 1, 1
Commande
Commander produit 1, n
N_bon_cmd
qté
date
0, n
Produit
réf
desig, pu
Exemple de vérification
Normalisation des relations

Mais la quantité commandée est connue si on connaît le n° de bon de

commande et la référence commandée, on a donc:
N_bon_cmd + réf -> qté
et la quantité est vérifiée sur le sous-ensemble COMMANDE x PRODUIT
de la collection CLIENT x COMMANDE x PRODUIT de la relation
COMMANDER CLIENT.
celle-ci ne respecte donc pas la règle de normalisation
la propriété qté doit être affectée à une relation SE COMPOSE DE qui
ne met en jeu que les entités COMMANDE et PRODUIT
 Exemple de vérification
Amélioration du MCD :

Client Passer commande Représentant

0, n 0, n
code_client code_rep
nom_client nom_rep
0, n
1, 1
Commande
Commander produit 1, n
N_bon_cmd
date
1, n

0, n Se compose de
qté
Produit
réf
desig, pu 0, n