ISI

IN S T I TUT
SUPERIEUR Année Universitaire
INFORMATIQUE
‫الـمعهـد العـالـي لإلعـالمــيـة‬ 2019-2020

Matière : Bases de données Niveau : 1ère année CS-GLSI

Enseignant : R. ZAÂFRANI Janvier 2020
Cours n°2 : Modélisation conceptuelle

1. Méthode d’analyse
Avant de s'attaquer à tout problème, il est toujours nécessaire de réfléchir profondément aux
tenants et aboutissants de ce que l'on veut réaliser. La phase de conception nécessite souvent
de nombreux choix qui auront parfois des répercussions importantes par la suite. La
conception de bases de données ne fait pas exception à la règle. Les théoriciens de
l'information ont donc proposé des méthodes permettant de structurer sa pensée et présenter
de manière abstraite le travail que l'on souhaite réaliser. Ces méthodes ont donné naissance à
une discipline, l'analyse, et un métier, l'analyste.
L'analyse est la discipline qui étudie et présente de manière abstraite le travail à effectuer. La
phase d'analyse est très importante puisque c'est elle qui sera validée par les utilisateurs avant
la mise en œuvre du système concret. Il existe de nombreuses méthodes d'analyse (AXIAL,
OMT, etc.), la plus utilisée en France étant la méthode Merise. Merise sépare les données et
les traitements à effectuer avec le système d'information en différents modèles conceptuels et
physiques. Celui qui nous intéresse particulièrement ici est le MCD ou le modèle Entité-
Relation (ER).
2. Modèle Entité-Relation (ER) :
Le schéma conceptuel d’une base de données décrit ses principaux objets principaux, leurs
caractéristiques et leurs relations, à l’aide d’un formalisme appelé modèle de données.
Nous utiliserons le modèle Entité-Relation(ER), en raison de sa large diffusion.
2.1 Les entités
Une entité est définie comme un objet pouvant être identifié distinctement.
Cet objet peut représenter un individu (un client), un objet concret (un livre) ou abstrait (un
compte bancaire) ayant une existence propre ou des évènements (une commande).
Un ensemble d'entités contient des entités similaires, mais distinguables deux à deux.
Exemples : des personnes, des voitures dans un parking, une bibliothèque de livres...

Les entités sont décrites par des attributs, caractéristiques ou propriétés.

Chaque attribut associe à une entité une valeur dans un domaine (entiers, réels, chaînes de
caractères ...)
Exemples :
- l'ensemble d'entités personne a les attributs : nom, prénom, age, adresse ...
 nom associe à l’entité personne une chaîne de caractères.
 Age associe à l’entité personne un entier court.
- livres a les attributs : numéro du livre (entier à 4 chiffres) auteur (chaîne de 20 caractères)
titre (chaîne de 50 caractères) éditeur (chaînes de 25 caractères)

On appelle déclaration d'entité, un ensemble constitué des attributs d'une entité :

Pour le livre : (numéro_du_livre, auteur, titre, éditeur)
Remarque : Ne pas confondre la déclaration d'entité avec l'instance de l'ensemble des entités à
un instant donné :
livres = {
(2004," François le Berre"," les bases de données bretonnes", "les éditions du far")
(1515," François 1er"," la bataille de Marignan"," historia"),
1
(12 693," gilles desrocques"," les bases du paramoteur"," cavole")
(309," gilles desrocques"," introduction a l'ULM"," cavole")…}
Remarque : différentes entités peuvent avoir certaines valeurs identiques.
Toutefois, elles doivent avoir une valeur au moins distincte.

On appelle une surclé un ensemble d'attributs (parfois réduit à un seul) caractérisant l'entité :
si l'ensemble d'entités E a les attributs A1, A2, ... Ap,
si e a les valeurs d'attributs (a1,a2, ..., ap), et f a les valeurs d'attributs (a'1,a'2, ..., a'p),
alors si e est différent de f, l'un des ai au moins est différent de l'un des a'i.
L'ensemble A1, A2, ... Ap est une surclé pour l’entité.

Lorsque l'ensemble des Ai est minimal on dira que la surclé est une clé.
En résumé, une clé ou un identifiant est un ensemble minimal d'attributs permettant de
déterminer une et une seule entité à l’intérieur de l’ensemble.
Deux entités différentes doivent avoir des clés différentes.
Exemple : un numéro de livres caractérise l'exemplaire : c'est une clé
un numéro de sécurité sociale caractérise une personne : c'est une clé
Remarque : un nom, un prénom et une adresse caractérisent une personne, c'est une autre clé.
On voit que deux clés d'une même entité peuvent avoir un nombre d'attributs différent.
La clé est représentée en souligné dans le modèle (ER).

nom de l'entité

Clé
liste des propriétés

Représentation graphique d'une entité

2.2 Les associations

On appelle relation ou association une liste ordonnée d'ensemble d'entités : A = (E 1,E2, ... Ek).
Où k est Le nombre d’entités impliquées dans une relation. k est appelé dimension ou degré
de la relation. La relation peut être de :
 dimension 1 : dans ce cas, elle ne concerne qu’une entité type dont elle relie deux
éléments. Elle est dite réflexive. Par exemple, la relation a_pour_père relie deux
éléments de l’entité type PERSONNE ;
 dimension 2 : c’est le cas le plus fréquent, on dit que l'association est binaire ;
 dimension 3 : par exemple, une location de voiture représente une relation entre un
véhicule, une personne et une date. Cette relation est ternaire dans la mesure où elle ne
peut pas être décomposée en deux ou trois relations binaires équivalentes.
De façon générale, une relation peut être caractérisée par n dimensions.

Les associations sont caractérisées, comme les entités, par un nom et éventuellement des
attributs. L'identifiant d'une association est constitué de la réunion des identifiants des entités
qui participent à l'association.

Le schéma conceptuel peut-être représenté graphiquement pour en faciliter la lecture et la

compréhension. Habituellement, on représente les entités dans des rectangles et les relations
dans des ellipses. Les attributs identifiants des entités sont soulignés.
Personne Service

travaille dans un

2
 Représentation d'une association
-) Attributs associés à une association :
Lorsque l'on a déterminé un couple d'entités (e1,e2) et que l'on souhaite associer à ce couple
certaines valeurs, on associe un attribut à cette association (comme pour une entité).
- Exemple 1 : un employé peut passer 25% de son temps dans un service et 75% de son
temps dans un autre. L'association "travaille dans" qui relie une personne à un service portera
la propriété "volume de temps passé".
- Exemple 2 : lorsqu'une personne emprunte un livre on souhaite conserver la date
d'emprunt. EmpruntéPar(personne, livre, dateEmprunt).
Cette date n'aurait aucun sens dans l'entité personne, ni dans l'entité livre, puisqu'il peut y
avoir différentes dates d'emprunts pour une même personne de même que le livre peut-être
emprunté à différentes dates.
En définitive, un attribut d'association, ne peut être connu que lorsque l'on connaît chacune
des entités associées.

2.3 Les cardinalités

Une cardinalité est un couple de valeurs indiquant les nombres minimum et maximum
d'éléments associés. C'est-à-dire les nombre maximum et minimum de liens réels que peut
recevoir une instance d’entité pour une association donnée. Les cardinalités maximales sont
nécessaires pour la création de la base de données. Ces cardinalités traduisent les règles de
gestion ou les contraintes propres aux entités et relations. Les cardinalités minimales sont
nécessaires pour exprimer les contraintes d'intégrité.
Par exemple une personne peut avoir entre 0 et 30 enfants, un livre peut avoir entre 1 et 10
auteurs etc. A un instant donné, un livre peut être emprunté 0 ou 1 fois.
Lorsque l’on ne souhaite pas préciser on met 0,n
-) Relation entre cardinalité et type de l'association :

Type E1 E2 exemple
1 :1 (0,1) ou (1,1) (0,1) ou (1,1) aPourConjoint
1 :n (0,n) ou (1,n) (0,1) ou (1,1) edite
n :1 (0,1) ou (1,1) (0,n) ou (1,n) EditéPar
m :n (0,m) ou (1,m) (0,n) ou (1,n) ecritPar

-) Exemples de schémas :

Personne Service

1-n travaille dans un 1-n

Volume

De ce schéma on en déduit que "une personne peut travailler dans plusieurs services". On
constate de plus que "dans chaque service il y a au moins 1 personne mais qu'il peut y en
avoir plusieurs". Enfin, une mesure du "volume de travail" est stockée pour chaque personne
travaillant dans un service donné.
3. Modèle Entité-Relation étendu ou enrichi (EER) :
Dans un modèle ER de base, on n’utilise que les cardinalités maximales. Celui-ci peut–être
utilement étendu en y intégrant les concepts de cardinalité minimale et de généralisation
d’entités. Muni de ces extensions, il est généralement appelé modèle ER étendu ou enrichi.
La généralisation d’entités permet de décrire un même ensemble d’entités à différents niveaux
d’abstraction. Ainsi, un même ensemble de personnes travaillant dans une entreprise peut-être
3
divisé selon la qualification, le sexe, etc. Cette précision permet par exemple d’enrichir le
schéma conceptuel en représentant, pour chaque relation, l’ensemble des entités réellement
impliquées dans la relation.
On distingue deux catégories d’entités : les entités faibles et les entités régulières. Une entité
est dite faible si son existence dépend de l’existence d’une autre entité. Par exemple, une
entité LIGNE DE COMMANDE n’existe que si l’entité COMMANDE correspondante est
présente. Cette dépendance d’existence se traduit souvent – mais ce n’est pas une règle de
conception – par une dépendance au niveau de l’identification de cette entité. Autrement dit,
l’entité faible aura un identifiant composé de l’identifiant de l’entité dont elle dépend et d’un
autre attribut. Les entités qui ne sont pas faibles sont dites régulières. Graphiquement, on peut
encadrer les entités faibles d’un double rectangle.
A toute situation à modéliser, peuvent correspondre plusieurs schémas différents, avec leurs
avantages et leurs inconvénients. Il est souvent peu aisé de dégager une modélisation
largement supérieure aux autres. Se pose alors le problème d’évaluation des différentes
modélisations. En d’autres termes, cela revient à mesurer la qualité d’une modélisation ER ou
EER. Pour ce faire, on peut combiner les critères suivants :
 l’expressivité : Elle traduit la richesse sémantique du schéma. Elle peut être
caractérisée par exemple par le nombre de concepts et/ou de contraintes exprimés dans
le schéma ;
 la minimalité : Elle tend à privilégier les schémas introduisant un nombre de
redondances minimales ;
 la lisibilité : Elle consiste à évaluer la représentation graphique proprement dite, par
exemple en préférant un schéma où un minimum d’arcs se croisent ;
 la simplicité : Elle privilégie les schémas contenant un nombre de concepts minimum.
On peut, par exemple, la mesurer en calculant le nombre d’entités et d’associations
présentes sur un schéma.
4. La démarche de conception :
La démarche d’un schéma conceptuel peut-être conduite de la façon suivante :
1. Déterminer la liste des entités
2. Pour chaque entité :
a. Etablir la liste de ses attributs
b. Parmi ceux-ci ; déterminer un identifiant ou une clé.
3. Déterminer les relations entre les entités.
4. Pour chaque relation :
a. Dresser la liste des attributs propres à la relation.
b. Vérifier la dimension (binaire, ternaire, etc.).
c. Définir les cardinalités (1-1, 1-N, ou M-N).
5. Vérifier le schéma obtenu, notamment :
a. Supprimer les transitivités.
b. S’assurer que le schéma est connexe1.
c. S’assurer qu’il répond aux demandes.
6. Valider avec les utilisateurs.
5. Modèle conceptuel UML
5.1 Classes et attributs
- Classe : Groupe d’entités du monde réel ayant les mêmes caractéristiques et le même
comportement ex. ETUDIANT
- Attribut : Propriété de la classe ex. Nom et Prénom de l’étudiant e

1
En d’autres termes, nous vérifions qu’il existe un chemin de tout point (entité ou relation) à tout autre dans le
schéma. En effet, le schéma ER est supposé traduire une seule réalité, même complexe. Les différents éléments
du schéma ER doivent « se retrouver » autour d’entités et de relations fondamentales représentant les données
nécessaires aux différents traitements.
4
- Représentation graphique :

- Type d’attribut :
Nombre entier (Entier)
Nombre réel (Réel)
Chaîne de caractères (Chaîne)
Date (Date)

- Instances : Objets (individus) de la classe ETUDIANT = les étudiants

- Identifiant : Solution : Ajouter un attribut numéro d’étudiant

Le numéro d’étudiant est un attribut identifiant.

Un identifiant caractérise de façon unique les instances d’une classe.
Convention graphique :

NB: Ne pas confondre avec les attributs de classe UML dont c’est la notation usuelle
5.2 Associations :
Association : liaison perçue entre des classes
ex. Les étudiants passent des épreuves.

Les classes ETUDIANT et EPREUVE peuvent être qualifiées de participantes à l’association

PASSER.
Degré ou arité d’une association : nombre de classes participantes.
En général : associations binaires (de degré 2).
Associations récursives : Une classe peut être associée à elle-même, chaque instance pouvant
jouer plusieurs rôles dans l’association. ex. Employés et supérieurs hiérarchiques
5
Rôle : fonction de chaque classe participante (+).

5.3 Multiplicité (ou cardinalité)

Définition : Indicateur qui montre combien d’instances de la classe considérée peuvent être
liées à une instance de l’autre classe participant à l’association
–1 Un et un seul
– 0..1 Zéro ou un
– 0..* ou * Zéro ou plus
– 1..* Un ou plus
– M..N De M à N (M, N entiers)
ex. 4..10 (de 4 à 10)
Classes-associations : Il est possible de caractériser une association par des attributs.
ex. Un étudiant e qui passe une épreuve obtient une note.

NB : Une classe-association demeure une association

6. Les erreurs à ne pas commettre :
*) Surestimer la dimension d’une relation :
Considérons par exemple la relation entre trois entités : FOURNISSEUR, CLIENT et
PRODUIT. Elle caractérise le fait qu’un client donné commande un produit donné à un
fournisseur donné. Cette relation peut être caractérisée notamment par la quantité
commandée.
Si cette relation est ternaire, la quantité commandée peut être la quantité totale commandée de
ce produit par ce client à ce fournisseur. Elle peut être au contraire la dernière quantité
commandée de ce produit par ce client à ce fournisseur.

PRODUIT Commande CLIENT

Code_produit Quantité 1-M Code_client

Désignation 1-N Dernière_date Nom
Prix Adresse
1-P
FOURNISSEUR

Code_fournisseur
nom
adresse
Si on souhaite enregistrer toutes les commandes de ce produit par ce client à ce fournisseur,
alors la relation devient quaternaire, la quatrième dimension étant la date de la commande.

6
Si on ne souhaite qu’une information synthétique, la relation est alors ternaire, la date de la
dernière commande pouvant être une caractéristique de la relation et non une dimension.
Notons que le problème de définition de la dimension de la relation se pose très fréquemment
avec la notion de temps. Le problème sous-jacent est celui de l’archivage des données
détaillées. Quand la date est intégrée comme une entité, participant à la relation, elle permet
l’archivage intégral de tous les évènements ou transactions. Dans le cas contraire, les
informations sont agrégées dans la relation et la date peut-être un attribut ;

PRODUIT CLIENT

Code_produit Code_client
Désignation 1-N 1-M Nom
Prix Commande Adresse

Quantité

FOURNISSEUR DATE
1-P 1-Q
Code_fournisseur Date
nom
adresse
*) Attribuer à une relation les attributs des entités participantes, ou inversement :
Dans de nombreux cas, il n’est pas évident de déterminer le propriétaire d’un attribut. Dans
l’exemple ci-dessous, l’attribut prix de la pièce peut être caractéristique de l’entité PIECE si
cette dernière provient toujours du même fournisseur. Dans le cas contraire, le prix est une
caractéristique de la relation Provenance.

PIECE PIECE

…
prix

Provenanace Provenanace
prix

FOURNISSEUR FOURNISSEUR

*) Exprimer des relations redondantes, c'est-à-dire déductibles par transitivité :

Lorsqu’un schéma ER contient un cycle de relations (deux, trois ou plus) – en d’autres
termes, le graphe présente une boucle- il est nécessaire de s’interroger sur l’éventuelle
redondance ainsi exprimée. Dans l’exemple ci-dessous, la relation Rattaché_à exprime la
composition des relations Travaille et Géré_par. Ainsi un employé est rattaché au
département qui gère le projet pour lequel il travaille.
Si la relation Rattaché_à ne porte pas d’attribut spécifique, si elle a la même durée de vie que
les autres relations et si les trois relations sont de cardinalité 1-N, alors elle est redondante,
n’exprimant que la transitivité des deux autres. Dans ce cas, elle doit être supprimée. En
revanche, si une des conditions citées n’est pas vérifiée, la relation Rattaché_à doit être
maintenue ;

7
 Employé 1 N PROJET
Travaille
1 1

Rattaché_à Géré_par

N
N DEPARTEMENT

*) Se tromper de niveau de discours :

Le schéma ER doit représenter fidèlement le monde réel. Ainsi, les entités doivent représenter
des ensembles d’objets ou de concepts. A titre d’exemple, si l’on informatise la gestion d’un
ensemble de magasins, MAGASIN est une entité, c'est-à-dire un ensemble d’entités magasin
ayant des caractéristiques du même type (code, nom, adresse, gérant, etc.). En revanche, si
l’on conçoit la gestion d’un magasin, le magasin est l’univers du discours et ne recouvre pas
un ensemble d’entités. Il ne figure donc pas de façon explicite dans le schéma ;
*) Introduire des attributs calculés :
Sauf exception, un schéma conceptuel ne doit pas contenir d’information redondante, tels des
attributs dont la valeur est calculable à partir d’autres attributs. Par exemple, le montant total
d’une commande, dont les différents éléments (ligne de commande, montant hors taxe, taux
des taxes) sont présents dans le schéma, ne doit pas figurer sous forme d’attribut. Au niveau
du schéma physique, les valeurs redondantes pourront être stockées délibérément pour
améliorer les performances de la base de données.