ENSIT

Chapitre II

Modèle Conceptuel: Le Modèle

Entité/Association

1
 Plan

Partie 1 : Les concepts de base du modèle E/A

Partie 2 : Règles de vérification et de normalisation

2
Partie 1 : Les concepts de base du modèle E/A

3
 Motivations
• Plusieurs problèmes de BD sont dus à une mauvaise compréhension
des données à un niveau abstrait ou conceptuel

• Il faut une compréhension structurelle des données, indépendante de

l'implantation physique rôle de l'étape de conception de la BD

• opération à conduire en coopération avec les utilisateurs:

les utilisateurs décrivent leurs besoins et expliquent la sémantique des
données

• le schéma conceptuel n'est pas seulement un document intermédiaire

mais un élément important de la documentation du système
d'information, il facilite la compréhension, l'évolution et la
maintenance.

4
 Dictionnaire de données
• La première étape dans la modélisation des données consiste à
élaborer un dictionnaire de données (DD).

• Un DD est un inventaire exhaustif des données du domaine étudié.

• Un DD permet de recenser, structurer et donner une première

analyse des informations de la future BD

• Le recensement des données est effectué essentiellement par :

- L’étude de documents
- Les entretiens
- Parfois, les questionnaires

5
 Dictionnaire de données
• Le dictionnaire de données est présenté sous la forme d’un
tableau
Contraintes,
Nom Description Type Longueur Remarques Règles de
calcul
Numéro du Identifiant
Numcl entier 5
client
Nom ou
raison
Nomcl caractère 10 sociale Obligatoire
Format en
majuscule

… … … … … …

Remarque: Le nombre de colonnes peut varier en fonction des besoins et

de la nécessité de précision
6
 Dictionnaire de données
• Le DD doit être épuré (ne comporte pas de données redondantes, de
synonymes et de polysèmes).
• Pour chaque donnée que le concepteur recueille dans son
environnement, avant de l’ajouter au dictionnaire de données, il doit
répondre aux questions suivantes :
• La nouvelle donnée n’est-elle pas déjà répertoriée ?
(cas de redondance)
Ex: l’information n° police apparaisse dans de nombreux documents.
Dans ce cas, on considère la « nouvelle » information comme déjà
connue.
• La nouvelle information n’est-elle pas déjà répertoriée sous une
appellation différente ? (cas d’un synonyme )
Ex: Ref_dossier et N°police:
Dans ce cas, le concepteur doit alors ne prendre en compte qu’une
seule appellation.
7
 Dictionnaire de données
• L’appellation de cette information existe-t-elle déjà mais pour une
signification différente ?
(cas d’un polysème)
Ex: date de livraison (demandée) et date de livraison (effective)
• Le concepteur doit lever l’ambiguïté en modifiant les appellations
des informations.

• La nouvelle donnée est-elle élémentaire?

Une donnée élémentaire est la représentation d’informations ne
pouvant plus être décomposées dans le domaine étudié

Dictionnaire de données (DD) = liste récapitulative

des données élémentaires sans redondances,
sans synonymes et sans polysèmes. 8
 Dictionnaire de données
• Les données calculées doivent être examinées avec soin.

• Si une donnée calculée peut être obtenue par l’application d’un

traitement à partir de données élémentaires existantes dans DD, on
peut la supprimer du dictionnaire.

• EX: MntCde = Prix* QteCde

Les données élémentaires (Prix et QteCde) qui participent à son
calcul sont présentes. On peut donc éliminer cette donnée.

9
 Dictionnaire de données
Contraintes,
Nom Description Type Longueur Remarques Règles de
calcul
Numéro du Identifiant
Numcl entier 5
client
Nom ou
raison sociale
Nomcl Nom du client caractère 10 Obligatoire
Format en
majuscule

Villec Ville du client caractère 10

Quantité
QtitC entier 5 Obligatoire, >0
commandée

… … … … … …

10
 Exercice d’application

On considère les informations manipulées par un service de vente de produit :

Bon De Commande Facture

Code de la commande
Numéro commande
Matricule client
Date commande Quantité produit
Numéro facture
Numéro client
Prix unitaire produit
Nom client Montant pour un produit
Montant total
Référence produit

Prix unitaire produit

Quantité produit

Etablir le dictionnaire des données épuré ? 11

 Dictionnaire de données Brut

Contraintes,
Nom Description Type Longueur Observation
règles de calcul
Num_c Numéro commande entier 4 identifiant
Num_cl Numéro client entier 3 identifiant
Nom_cl Nom client caractères 30
Date_c Date commande date 8 JJMMAAA

Ref_p Référence produit entier 3 identifiant

P_u_p Prix unitaire produit réel 5 NNN,NN
Qte_p Quantité produit entier 3
Code_c Code de la commande entier 3

Mat_cl Matricule client entier 3 identifiant

Num_f Numéro facture entier 4 identifiant
Mnt_p Montant pour un produit réel 8 Mnt_p= p_u_p 
Qte_f
Mnt_total Montant total entier 8 Mnt_total= Mnt_p

12
Synonymes : num_c et code_c désigne la même donnée numéro
commande ; num_cl et mat_cl désigne la même donnée Numéro
client ;

Polysèmes :Qte_p désigne quantité commandée Qte_p_c et quantité

facturée Qte_p_f ;

Données calculées : Mnt_total=  Mnt_p =  p_u_p  Qte_f 

13
 Dictionnaire de données épuré

Nom Description Type Longueur Observation Contraintes, règles

de calcul
Num_c Numéro commande entier 4 identifiant

Num_cl Numéro client entier 3 identifiant

Nom_cl Nom client caractères 30

Date_c Date commande date 8 JJMMAAA

Ref_p Référence produit entier 3 identifiant

P_u_p Prix unitaire produit réel 5 NNN,NN

Qte_p_c Quantité commandée du entier 3

produit
Qte_p_f Quantité facturée du entier 3
produit
Num_f Numéro facture entier 4 identifiant

14
 Modèle Entité / Association

• Le modèle Entité-Association (appelé aussi Entité-Relation) est un

modèle conceptuel de données.

• Il permet de décrire une réalité en utilisant différents concepts

(principalement les entités, les associations et les attributs).

• Il permet de fournir des outils et un cadre rigoureux pour l’analyse

des données et de leurs liaisons.

• Il existe différents formalismes de modélisation des données. Dans

la suite de ce cours, nous utilisons le formalisme de la méthode
Merise.
15
 Entité
Entité et Occurrence d’entité

1. Entité
C’est un ensemble d’objets du monde réel (concrets ou abstraits) ayant les mêmes
caractéristiques.
Exemple: client, employé, produit, etc.
Dans le modèle EA, les entités sont représentées par des rectangles.

Employé

L’entité « Employé »

2. Occurrence d’entité
Une occurrence d’entité est une représentation d’un objet spécifique sur lequel nous
souhaitons connaître et enregistrer certaines informations.
Exemple: l’employé « Mohamed Ali », le film « le bonheur est dans le pré », le service
marketing, etc.
16
 Entité
Remarque:
On peut aussi nommer Type d’entité pour désigner un ensemble d’objets
ayant même caractéristiques et entité pour désigner un objet spécifique.

Que Retenir?
Une entité est créée dans le modèle EA chaque fois qu'il existera des
objets
distincts mais similaires sur lesquels on désire mémoriser des informations,
sachant que ces objets ont des relations avec des occurrences d'autres
entités.

17
 Association
Association et occurrence d’association

1. Association
• C’est un ensemble de liens ayant même sémantique et décrits par les mêmes
caractéristiques.
Exemple: l’association travaille entre l’entité employé et l’entité service.
• Dans le modèle EA, les associations sont représentées par des ovales.

Employé service
travaille

2. Occurrence d’ Association
c’est un lien entre deux ou plusieurs occurrences d’entités.

18
 Association

Occurrences de Occurrences de Occurrences de

l’entité l’association contient entre l’entité PRODUIT
FACTURE FACTURE et PRODUIT

FAC001 FAC001 PRO002 PRO001

FAC002 FAC001 PRO003 PRO002

FAC002 PRO003 PRO003

Remarque
De même, on peut aussi nommer Type d’association pour désigner un
ensemble de liens ayant même caractéristiques et association pour
désigner un lien spécifique.

19
 Association

CLIENT FACTURE PRODUIT

Paye Contient

Est préparée
par

EMPLOYÉ

20
 Attribut

• Caractéristique ou la propriété d’une entité ou d’une

association
• L'ensemble des attributs d'une entité (association) représente
l’ensemble des informations que l'on souhaite conserver.

CLIENT FACTURE PRODUIT

NoClient Paye NoFacture Contient NoProduit

NomClient QtéFacturée Description

Date
Prix

21
 Attribut

• Chaque entité doit posséder un ou un ensemble d’attributs qui permet d’identifier de

manière unique toutes les occurrences de cette entité.
• Cet attribut ou cet ensemble d’attributs est appelé identifiant.
• Il doit être spécifié au début de la liste des attributs et souligné

CLIENT FACTURE
NoClient Paye NoFacture
Nom Date
Prénom
Adresse

22
 Cardinalité

• La cardinalité d’un lien entre une entité et une association est

le minimum et le maximum de fois qu’un individu de l’entité
peut être concerné par l’association.
• Couple(nombre minimal, nombre maximal)
• Valeurs les plus utilisées:
- Nombre minimal
0 : peut ne correspondre à aucune occurrence
1 : peut correspondre à au moins une occurrence
- Nombre maximal
1 : peut correspondre à au plus 1 occurrence
n : peut correspondre à plusieurs occurrences
23
 Cardinalité
• Les combinaisons les plus utilisées : 0,1 1,1 1,n 0,n
Exemple 1: Un employé travaille dans un département et un département est
occupé par un ou plusieurs employés

e1
e2 d1
e7
e6 d2
e5
e4 d3
e3

Employé 1,N
1,1 Département
travaille N°dep
N° employé
Nom NomDep
Prénom
Salaire
24
 Cardinalité
Exemple 2: Une personne peut acheter plusieurs produits et un produit peut être
acheté par plusieurs personnes

pd1
p1
pd2

p3
p2 pd4
pd5
p4
pd6
pd3

Personne 0,n 0,n produit

achète NP
N° employé
Nom NomP
Prénom

25
 Cardinalité
Exemple 3: Un employé peut diriger un service et un service est dirigé par un
employé
e1 S1

e4 S2
e2
e3 S3

e6 e5 S4

Employé 0,1 1,1 Service

dirige NS
N° employé
Nom NomS
Prénom
Salaire

RQ: Toute valeur entière >1 est aussi possible.

Si on considère l’entité parent qui est reliée par l’association «est parent de » à l’entité
enfant. Un parent peut avoir de 1 à N enfants alors qu’un enfant a toujours 2 parents
26
 Cardinalité et types d’association
Association N-aire
• C’est une association qui permet de relier plusieurs entités.
• Une association entre deux entités est nommée une association binaire et une association entre
trois entités est nommée une association ternaire.
Exemple1:
Date
Date Dans le cas d’association
ternaire, il faut placer la
0,n cardinalité près d’une
Etudiant entité en mettant en jeu
LIVRE les deux autres entités.
0,n EMPRUNTER 0,n EtudNum
LivCode

Du côté étudiant : Un étudiant peut n’avoir jamais emprunté de livre ou emprunté plusieurs livres
à une même date ou emprunté à des dates différentes le même livre.

Du côté date : A une date donnée, il n’y a eu aucun ou plusieurs emprunt (le dimanche par ex).

Du côté livre : Un livre peut n’être jamais emprunté ou au contraire par un même étudiant à des
dates différentes ou enfin par plusieurs étudiants différents à une même date.
L’exemple prouve la nécessité d’analyser de façon exhaustive la participation d’une
occurrence quelconque de l’entité par rapport aux occurrences de toutes les autres
entités (combinatoire de cas) au travers de l’association.
27
 Cardinalité et types d’association
Association Réflexive
• C’est une association qui relie deux occurrences d’une même entité.
Chaque occurrence joue un rôle bien déterminé.

• Dans ce cas la spécification du rôle de chaque occurrence est indispensable

pour supprimer les ambigüités.

Exemple:
Dirige est l’association entre des couples d’employés (Employé X, Employé
Y) tels que X dirige Y (supérieur et subalterne sont les rôles).

0,1 A pour chef 0,n Composant de

Employé dirige Produit Est composé de

0,n Est supérieur de

1,n
Composé de 28
 Cardinalité et types d’association
Association porteuse de données
Une propriété est affectée à une relation si et seulement si :
- la relation soit de type m-n (plusieurs à plusieurs)
- la propriété dépend fonctionnellement des identifiants des entités participantes à la
Relation.
Dépendance fonctionnelle (DF):
Soit deux attributs x et y, on dit que y dépend fonctionnellement de x
notée: xy
ou bien x détermine y
si la connaissance d’une valeur de x permet de déterminer la valeur de y
DF : ncin  nom

Exemple:

FACTURE PRODUIT
1,n 0,n
NFacture
Contient NProduit
QtéFacturée Description
Date
Prix
Source Cible

C’est la quantité facturée d’un produit donné DF: NFacture, NProduit QtéFacturée
et pour une facture donnée DF multi-attribut: la source de la29DF
est constituée de plusieurs attributs
 Cardinalité et types d’association
Pour éviter toute redondance, on s’assurera en outre que la dépendance fonctionnelle
est élémentaire.
On dit qu’une propriété est en dépendance fonctionnelle élémentaire avec une liste de
rubriques LR :
• si elle est fonctionnellement dépendante de LR,
• si elle n’est pas fonctionnellement dépendante d’une sous-liste de LR.
Exemple
Num_Client Nom_Client Dépendance fonctionnelle élémentaire

Contre exemple
Num_client, Nom_Client Prénom_Client
Non élémentaire car le numéro du client suffit à déterminer le prénom :
Num_client Prénom_Client
- Une DF entre deux attributs A et C (A  C) est dite DF directe s’il
n’existe aucune propriété B telle que : A  B et B C
Num_Client Nom_Client Dépendance fonctionnelle directe
Num_Facture Nom_Client Num_Facture Num_Client Nom_Client
Dépendance fonctionnelle non directe (DF transitive). 30
 Cardinalité

CLIENT FACTUR PRODUIT

1,n 1,n 0,n
NoClient Reçoit
1,1 E
NoFacture Contient NoProduit
NomClient Date Description
Prix

1,1

Est préparée par

0,n
0,n
superviseur
EMPLOYÉ
NoEmployé
Supervise
NomEmployé

Est supervisé 31
1,1
 Exercice d’application

• Un patient peut-il effectuer plusieurs visites ? oui

• Un médecin peut-il recevoir plusieurs patients dans la même consultation ? non
• Peut-on prescrire plusieurs médicaments dans une même consultation
oui
32
 Généralisation/Spécialisation

• Un même ensemble d’objets peut être perçu d’un certain point de

vue comme une seule entité, mais en même temps perçu d’un autre
point de vue comme plusieurs entités différentes malgré l’existence
de caractéristiques communes.

• Cette situation peut être représentée par le concept de

généralisation/spécialisation.

• Ce concept peut être représenté par un lien orienté d’une entité

spécifique vers une entité plus générale.

33
Généralisation/Spécialisation

34
 Généralisation/Spécialisation

• Les attributs communs à l’entité générale et aux entités

spécifiques ne sont décrits dans le schéma que dans l’entité
générale. Ils sont implicitement inclus dans les attributs des
entités spécifiques. On dit que ces derniers héritent des
attributs de l’entité générale.

• On parle de généralisation multiple lorsqu’une entité hérite

de plusieurs autres entités.

35
 Entité faible
• L’identifiant de cette entité est définie comme suit :
- Il est composé d’un identifiant d’une autre entité
(cas d’héritage)
- Il est composé de l’identifiant d’une autre entité et d’un
autre attribut.
Exemples

-L’entité appartement a comme identifiant N° bâtiment (identifiant

de l’entité bâtiment) et N° appartement.

Appartement Bâtiment
1,1 1,N
N° Appartement Est-dans N°Bâtiment

36
 Diagramme Entité-Association

• Le modèle EA permet une représentation graphique assez lisible du

schéma d'une base de données.

• Dans cette représentation, appelée diagramme EA, les entités sont

représentées par des rectangles, les associations sont représentées
par des ovales (hexagones, losange). Les attributs sont soit listés à
l’intérieur du rectangle (ou l’ovale) au dessous du nom de l’entité
(association) et séparés de celui-ci par une barre (convention utilisée
ici), soit rattachés à l’entité (association) par des traits.

37
 Diagramme Entité-Association

Employé Rayon
1,1 1,N
travaille NomR
N° employé
Nom étage
0,N
Prénom 0,N
Salaire
Livraison Vendre
0,N quantitél quantitév
0,N 0,N
Fournisseur
Article
N° fournisseur CodeA
Nom NomA
Prénom Type
Adresse
38
 Méthodologie de construction d’un modèle
E/A
• Étape 1 : Identifier les entités

• Étape 2 : Établir la liste des attributs relatifs aux entités

• Étape 3 : Déterminer les identifiants de chaque entité

• Étape 4 : Établir les associations entre les entités

• Étape 5 : Ajouter les attributs des associations

• Étape 6 : Déterminer les cardinalités

• Étape 7 : Vérifier et valider le modèle E/A

39
 Exercice : Une structure administrative
• On considère un sous-ensemble d’une structure administrative.

• Une direction est caractérisée par un nom identifiant et le nom de son président-directeur général.

• Plusieurs départements dépendent d’une direction et chaque département est doté d’un nom
identifiant et d’une localisation.

• Un département est découpé en services, doté chacun d’un nom et d’un responsable.

• Un service a la charge d’un certain nombre de dossiers identifiés par un numéro et doté d’un titre et
d’une date d’enregistrement.

• Dans chaque service travaillent des employés identifiés par un numéro et caractérisés par leur nom
et leur adresse.

40
 Exercice : Une structure administrative
• On considère un sous-ensemble d’une structure administrative.

• Une direction est caractérisée par un nom identifiant et le nom de son président-directeur général.
(1)

• Plusieurs départements dépendent d’une direction (2) et chaque département est doté d’un nom
identifiant et d’une localisation (3).

• Un département est découpé en services (4), doté chacun d’un nom et d’un responsable (5).

• Un service a la charge d’un certain nombre de dossiers (6) identifiés par un numéro et doté d’un titre
et d’une date d’enregistrement (7).

• Dans chaque service travaillent des employés (8) identifiés par un numéro et caractérisés par
leur nom et leur adresse (9).

41
 Exercice : Une structure administrative
(1):Une direction est caractérisée par un nom et le nom de son président général
(a) Une direction est caractérisée par un nom identifiant
(b) Une direction est caractérisée par le nom de son président-directeur général.

Direction
NomDir
Président

(2): Plusieurs département dépendent d’une direction

Département 1,n
dépendre de Direction
NomDir
Président

42
 Exercice : Une structure administrative
(3) chaque département est doté d’un nom identifiant et d’une localisation
(a) Un département est doté d’un nom identifiant
(b) Un département est doté d’une localisation

Département 1,n
dépendre de Direction
NomDep
NomDir
Localisation
Président

(4) Un département est découpé en services

1,n
Département services
Composé de
NomDep
Localisation

43
 Exercice : Une structure administrative
(5) chaque service est doté d’un nom et d’un responsable
(a) Un service et doté d’un nom identifiant
(b) Un service est doté d’un responsable

Département 1,n
Composé de services
NomDep NomSer
Localisation Responsable

(6) Un service a la charge d’un certain nombre de dossiers

1,n
services traite Dossier
NomSer
Responsable

44
 Exercice : Une structure administrative
(7) Chaque dossier est identifié par un numéro et doté d’un titre et d’une date
d’enregistrement
(a) Un dossier est identifié d’un numéro
(b) Un dossier est doté d’un titre
(c) Un dossier est doté d’un d’une date d’enregistrement
1,n
services traite Dossier
NomSer NumD

Responsable Titre
DateEnreg

(8) Dans chaque service travaillent des employés

1,n
services Occupé par Employé
NomSer
Responsable

45
 Exercice : Une structure administrative
(9) Chaque employé est identifié par un numéro et caractérisé par son nom et
son adresse (9).
(a) Un employé est identifié d’un numéro
(b) Un employé est caractérisé par un nom
(c) Un employé est caractérisé par une adresse

1,n
services Occupé par Employé
NomSer NumE
Responsable NomE
adresseE

46
 Exercice : Une structure administrative
Diagramme Entité-Association

Département 1,n
1,1
Dépend de Direction
NomDep
NomDir
Localisation
Président
1,n

Composé de

1,1

services 1,n 1,1 Employé

Occupé par
NomSer NumE
Responsable NomE
adresseE
1,n

traite 1,1 Dossier

NumD
Titre
47
DateEnreg
 Modélisation des données par analyse des DF

1. Construction d’un dictionnaire de données épuré (sans synonyme,

sans polysèmes, etc.)

2. Rechercher les dépendances fonctionnelles

3. Dégager les entités naturelles grâce à leur identifiant

4. Rattacher à ces entités leurs propriétés grâce aux dépendances

fonctionnelles.

5. Identifier les associations non porteuses de données.

6. Identifier les associations porteuses de données.

7. Spécifier les cardinalités

8. Vérifier et valider le modèle E/A 48

 Étapes de construction du modèle E/A
A partir d’un DD
Une société de vente souhaite informatiser son SI actuel (manuel) qui contient
essentiellement des données figurant sur des bons de commande du type :

N° Bon de Commande ……………………… Date ……………

Numéro du client ………………………
Nom du client …………………………………………………
Adresse …………………………………………………
……………………………………………………………..

Réf. Désignation Quantité Prix unitaire Montant

………… ………… ………. ………….. …………
………… ………… ………. …………. …………

Total …………

Recueil des informations (suite à des interviews)

- Un client peut passer une ou plusieurs commandes ou ne passer aucune commande
- Une commande concerne au moins un produit
- Une commande concerne un et un seul client 49
 Étapes de construction du modèle E/A
A partir d’un DD
1-Construction du Dictionnaire de données
Contraintes,
Nom Description Type Longueur Remarques
Règles de calcul
Numéro de bon de
NumBC entier 5
commande
Date de commande
DateC Date Format JJ/MM/AAAA

Numcl Numéro du client entier 5

Nom ou raison
Nomcl Nom du client caractère 10 sociale Obligatoire
Format en majuscule

Adressecl Adresse du client caractère 10

Référence du
Refp entier
produit

Désignation du
Design caractère 15
produit

PrixU Prix du produit réel

Quantité
QtitC entier 5 Obligatoire, >0
commandée

Remarque: Montant et total sont des valeurs calculées

50
 de construction du modèle E/A
A partir d’un DD
2-Recherche des Dépendances fonctionnelles
En reprenant les données du dictionnaire précédent, on peut établir les DF
directes suivantes :
NumBC→ dateC
NUMBC → numcli
Numcl → nomcl
Numcl → adress
refp → design
refp → prixU
NumBC, refp → QtitC

Afin d’identifier les entités et les associations, on applique les règles suivantes:
R1: Les DF de même source et dont les cibles ne sont pas sources forment des
entités.
R2: Les DF entre identifiants d’entités forment une association avec une
cardinalité 1,1
R3: Les DF où la source est composée de plusieurs identifiants d’entités
forment une association porteuse de données.
51
 de construction du modèle E/A
A partir d’un DD
3- Dégager les entités naturelles grâce à leur identifiant

NumBC→ dateC
NumBC→ numcli
Numcl → nomcl Les entités: commande, client et produit
Numcl → adress
refp → design
refp → prixU

52
 Étapes de construction du modèle E/A
A partir d’un DD
4-Rattacher à ces entités leurs propriétés grâce aux DF.
NumBC→ dateC Refp → design, prixU Numcl → nomcl, adressecl

Commande PRODUIT CLIENT

Refp Numcl
NumBC
Design nomcl
DateC
PrixU adressecl

5-Identifier les associations non porteuses de données

NumBC → NumCL Une association entre commande et client

Client Commande
NumCl passer
NumBC
NomCl
DateC 53
adresseCl
 Étapes de construction du modèle E/A
A partir d’un DD
6-Identifier les associations porteuses de données
NumBC, refp → QtitC

Commande PRODUIT Une association porteuse

Concerne Refp de données (QtitC) entre
NumBC
QtitC Design commande et produit
DateC
PrixU

54
 Étapes de construction du modèle E/A
A partir d’un DD

7-Spécifier les cardinalités

Client Commande PRODUIT

0,n 1,1 1,n Concerne 0,n
NumCl passer Refp
NumBC
NomCl QtitC Design
DateC
adresseCl PrixU

55
Partie 2 : Règles de bonne formation du modèle

56
 Règles de Vérification et de Normalisation

1. Contrôler la qualité du modèle vis-à-vis :

 des fondements du modèle d’une part (règles de vérification),

 de la redondance de données d’autre part (règles de
normalisation) .

2. Permet de détecter certaines incohérences dans la

construction des modèles.  

57
 Règles de vérification
Règle 1
• Deux entités qui doivent être reliées entre elles le seront par le
biais d’une relation

CLIENT FACTURE
À ne pas
faire

CLIENT FACTURE
1,n 1,1
NoClient Reçoit NoFacture
NomClient Date

58
 Règles de vérification
Règle 2
• Deux relations ne peuvent jamais être directement reliées
entre elles

PERSONNE IMMEUBLE
À ne Gère Possède
pas faire

0,n 1,1
Gère
PERSONNE IMMEUBLE

0,n 1,n
Possède
59
 Règles de vérification
Règle 3
• Le nom de la relation doit représenter d’une manière concrète et
significative l’information que l’on veut obtenir

PERSONNE IMMEUBLE
À ne Concerne
pas faire

PERSONNE IMMEUBLE
0,n 1,1
Gère

60
 Règles de vérification
Règle 4
• Les entités et les relations ne doivent contenir que des données
élémentaires, donc ne pas inclure des résultats de calcul/traitement

FACTURE 1,n
PRODUIT
0,n
Contient
À ne NoFacture
QtéFacturée
NoProduit
Description
pas faire Date PrixFacturé
TotalFacture TotalParProduit

FACTURE 1,n
PRODUIT
0,n
NoFacture Contient NoProduit

Date QtéFacturée Description

PrixFacturé

61
 Règles de vérification
Règle 5 : modélisation de la date

a) En propriété de l’objet

b) En propriété portée par une relation

Pour un couple (NumPersonne, NumVille), il ne peut y avoir qu’une

occurrence de la relation « HABITER ».
Toute création d’une nouvelle occurrence à partir de ce couple
d’identifiants écrase l’occurrence précédente.
On parle dans ce cas de dynamique partielle (les différents états62du
modèle ne sont pas conservés). 62
 Règle 5 : modélisation de la date
C) En Entité

L’objet « DATE » permet ici l’historisation en participant à l’identification

des occurrences de la relation « HABITER ».

On parle dans ce cas de dynamique totale (les différents états du

modèle sont conservés).
63
 Règles de vérification
Règle 6
• Lorsqu’une relation peut être déduite des autres relations, elle
n’est pas représentée à moins qu’on veuille sauvegarder une
information spécifique à cette relation
CLIENT FACTURE
1,n 1,1
NoClient Reçoit NoFacture
Nom
Date
Prénom

1,n
1,n Contient
QtéFacturée
PrixFacturé
0,n
Achète
0,n PRODUIT
NoProduit
Description
Qté en stock 64
Règles de vérification
Règle 6

ÉTUDIANT GROUPE
1,1 1,n
NoÉtudiant
Fait partie de
NoGroupe
Nom DateDébutGroupe
Prénom DateFinGroupe

1,n 1,n

Suit

0,n

Suit 0,n COURS

Absence
Note
NoCours
Description

65
 Règles de vérification
Règle 7: règles sur les propriétés
• Toute propriété doit apparaître une seule fois dans un modèle.

• Il faut éliminer la redondance des propriétés dans la même

entité ou dans des entités distinctes (parfois avec des noms
différents) :

PRODUIT PRODUIT Tarif

NoProduit 1,n 1,n
NoProduit Coute CodeTarif
Prix1 Prix
Prix2

66
Client Prospect Contact
CodeClient CodeProspect CodeContact
NomClient NomProspect NomContact
type

Les clients potentiels = prospects

Toutes les propriétés identifiées doivent apparaître dans le

modèle.

67
 Dépendance fonctionnelle Intra-entités
• Soit une entité E regroupant deux propriétés tel que à toute valeur de la propriété P1
doit correspondre au plus une valeur de la propriété P2.

• Ce fait traduit l’existence d’une dépendance fonctionnelle monovaluée entre P1 et P2

notée : P1  P2.

• P1 est alors rubrique identifiante de l’entité E. La représentation graphique de l’entité

E a la forme suivante :

E
La dépendance fonctionnelle au sein d’une
P1 entité doit être directe.
P2

Exemple:

Livre
idLivre idLivre  Titre
titre
68
 Dépendance fonctionnelle Intra-entités
ARTICLE 452GT
134ER 354TY
Référence Rateau Bêche Scie
Désignation 150 68 45
PrixUnitaireHT A A B
NoCatégorie Jardinage Jardinage Bricolage
LibelléCatégorie

Cette entité est juste mais elle implique une redondance d’information relative à
la catégorie.
L’association entre le numéro de la catégorie et son libellé est en effet répétée
dans chaque occurrence de l’entité ARTICLE.

Pour supprimer de telles redondances, on devra veiller à ce que toute

dépendance fonctionnelle entre la propriété identifiante de l’entité et une
propriété non identifiante de l’entité soit directe.

la DF: Référence  LibelléCatégorie n’est pas directe car il existe la propriété

NoCatégorie telle que :Référence  NoCatégorie et NoCatégorie  LibelléCatégorie

Éclater article en deux entités : article et catégorie

69
 Dépendance fonctionnelle Inter-entités
Une DF inter-entités, définies sur une collection d'objets, exprime le fait que les
occurrences de certains objets de cette collection sont déterminées par la
connaissance des occurrences des autres objets.

Cheval DF 1, N Propriétaire
1,1 A pour
Codecheval CodePropriétaire
…. …

L'association A pour est une DF:

- l'objet cheval est la source de cette DF codechaval  codepropriétaire
- l'objet propriétaire est la cible de cette DF
Cheval 1,1 1, N Propriétaire
DF DF forte
Codecheval CodePropriétaire
…. …

Une DF forte associe à chaque valeur de A une et une seule valeur de B : il y a unicité au départ
La DF est vérifiée pour toutes les valeurs de A : il y a totalité au départ (toutes les valeurs de A
70 B)
ont une image dans l’ensemble d’arrivée
 Dépendance fonctionnelle Inter-entités
Il existe une dépendance fonctionnelle faible entre A et B lorsque, connaissant une
valeur de A, quelque soit cette valeur, on détermine au plus une valeur de B.
La contrainte de totalité est supprimée: certaines valeurs de A n'ont pas de valeurs
de B.
DF
Client 0,1 1, N Représentant
A pour
Codcli CodeReprésentant DF faible
…. …

Client 1, N Représentant
0,1
DF
Codcli CodeReprésentant
…. …

71
 Dépendance fonctionnelle Inter-entités
La Contrainte d’intégrité fonctionnelle (CIF)
La CIF est le cas particulier d’une relation binaire, non porteuse de propriété, et
ayant une cardinalité 1,1 sur une des deux pattes. C’est une DF forte et stable
dans le temps

CIF
Enfant 1,1 Fils de 0,N Père
NumEnf Numpère
…. …

Enfant 1,1 CIF 0,N Père

NumEnf Numpère
…. …

72
 Règles de normalisation
Règle 1 - Chaque entité doit avoir un identifiant
- Pour chaque occurrence d’une entité, chaque propriété ne peut

Entités prendre qu’une valeur et elle doit être élémentaire (non-

décomposables)
Règle 2 Toutes les propriétés autres que l’identifiant doivent dépendre
pleinement et directement de l’identifiant
Associ-
ation

Règle 3 Pour chaque occurrence de l’association, il ne peut exister qu’une

et une seule valeur non décomposable pour chaque propriété de
l’association
Règle 4 Toutes les propriétés d’une association doivent dépendre pleinement
et directement de l’identifiant de la relation.
Règle 5 : Décomposer une association n-aire en deux associations quand il
existe une DF entre un sous-ensemble des entités à décomposer (on
parle aussi de ‘contrainte d’intégrité fonctionnelle’ ou CIF).
73
73
 Règles sur les entités
R1 : a- Chaque entité doit voir un identifiant.
b- Pour une occurrence d’une entité, chaque propriété ne prend
qu’une seule valeur et elle doit être non décomposable.
Une entité est dite en première forme normale (1FN) si elle vérifie la
règle R1

Exemple1
Employé Employé Enfant
Matricule Matricule MatriculeE
Nom Nom PrénomEnfant
PrénomsEnfant

On décompose l’entité employé en deux entités : employé, enfant.

• Toutes les propriétés identifiées doivent apparaître dans le modèle.
74
Exemple 2
Employé
Employé Code employé
E01
Code employé Nom
Nom Ben Salah Prénom
Prénom Ali Fonction
caractéristique Analyste, 20/02/1996 Date d’embauche

Employé n'est pas 1FN car caractéristique n’est pas atomique 1FN
Exemple 3

ETUDIANT ETUDIANT
Nom N° étudiant
n'est pas 1FN Nom est 1FN
Prénom
Age Prénom
Age

75
 Règles sur les entités
R2.1:. Toutes le propriétés autre que l’identifiant doivent
dépendre pleinement de l’identifiant
Exemple 1
Commande
Commande produit
N°comm
N°prod N°comm N°prod
Contient
Qté DateCom
0,n Qté 0,n
DateComm N°Client
N°client

La DF n°-comm  date-comm, n°-client contredit la règle. On

décompose l’entité Commande en deux entités.

Une entité est dite en deuxième forme normale (2FN) si :

- elle est en première forme normale ,
- et elle vérifie la règle R2.1
76
Exemple 2
ETUDIANT
Code_Option, N°étudiant n'est pas 2FN car code_option  nom_option
Nom La DF n’est pas élémentaire
Prénom
Nom_option

ETUDIANT

N°étudiant
0,n
SUIVRE
0,n
OPTION
est 2FN
Nom Code_option
Prénom Nom_option

77
 Règles sur les entités
R2.2:. Tout attribut n’appartenant pas à une clé ne dépend pas d’un
autre attribut non clé.
Exemple 1

La DF: N°insee Nom, Adresse contredit la règle;

DF transitive et non directe
Numimmat  insee Nom, Adresse
On a une dépendance transitive qu’il faut éliminer.
Une entité est dite en troisième forme normale (3FN) si :
- elle est en deuxième forme normale , 78
- et elle vérifie la règle R2.2
Exemple 2

ETUDIANT

N°étudiant
n'est pas en 3FN
Nom Car la DF: N°étudiantnom_option est transitive
Prénom
Code_option
Nom_option

ETUDIANT

N°étudiant OPTION
SUIVRE
1,1 0,n
Nom
Est en 3FN
Code_option
Prénom Nom_option

79
 Règles sur les associations
R3 : Pour une occurrence d’association, chaque propriété ne prend
qu’une seule valeur et elle doit être non décomposable.

R4: Toutes les propriétés de l’association doivent dépendre

fonctionnellement et pleinement des identifiants des entités portant
l’association, et uniquement d’eux.

Voiture 0,n autorisé 0,n Personne

Date-aut N°insee
N°immatr
Date-permis

N°-insee  Date-permis donc Date-permis dépend

uniquement de l’identifiant du personne déplacer Date-
permis vers Personne)
80
R5 : La normalisation par décomposition des associations n-aires

Si on observe une DF entre un sous-ensemble des entités d’une

association, on peut la décomposer en deux associations

La décomposition n'est possible qu'à deux conditions:

1) La cardinalité minimum des entités à gauche dans la DF

doit être 1 dans la relation à décomposer.

2) si la DF provient d'une autre relation que la relation à

décomposer, il faut qu'elle concerne les mêmes occurrences
d'entités que la relation à décomposer

81
Exemple 1 Les professeurs assurent les cours à
différentes classes

Un même prof peut se charger de ++

cours

Un cours est toujours assuré par le

même prof: Cours  prof

82
Exemple 2
Prof Matière
N°prof N°mat
1,n 0,n
Nom
cours
Salle
heure
Classe
0,n
N°classe

Une éventuelle DF N°prof  N°mat donne la décomposition :

Prof 1,1 1,n Matière

assure N°mat
N°prof
Nom
cours
0,n
Salle
Classe
heure
0,n N°classe 83
Exemple 3

à un contrat est associé un client et un local :

Client Local

Client 0,n 0,n Local 0,n 0,n

location
concerne porte-sur
1,1
Contrat 1,1 1,1
Contrat

84
1FN : élémentarité des attributs et existence de l'identifiant.

2FN : DF élémentaire de l'identifiant.

3FN : DF directe de l'identifiant.

85