COURS DE PROGRAMMATION WEB

CREATION ET GESTION DE BASE DE DONNEES

M. Réné ZEMBA
(226) 64 00 20 53/53 90 26 72
[email protected]
Ingénieur Statisticien Economiste (ENSAE-Sénégal)

1 07/06/2024
Année académique 2022-
 Chapitre I
Le modèle Entité/Association
 Plan

I. Principes généraux
1. Bon et mauvais schémas
2. La bonne méthode

II. Le modèle E/A: Présentation informelle

III. Le modèle
3. Entités, attributs et identifiants
4. Associations binaires
5. Entités faibles
6. Associations généralisées

IV. Avantage et inconvénients du modèle E/A

3 07/06/2024
 I. Principes généraux
 Ce chapitre présente le modèle Entité/Association (E/A) qui est utilisé à peu près

universellement pour la conception de bases de données (relationnelles principalement). La

conception d’un schéma correct est essentielle pour le développement d’une application
viable. Dans la mesure où la base de données est le fondement de tout le système, une erreur
pendant sa conception est difficilement récupérable par la suite.
 La présentation qui suit est délibérément axée sur l’utilité du modèle E/A dans le cadre de la

conception d’une base de données. Permettre d’être capable de comprendre et de

l’interpréter un modèle E/A. Dans tout ce chapitre nous prenons l’exemple d’une base de
données décrivant des films, avec leur metteur en scène et leurs acteurs, ainsi que les
cinémas où passent ces films.
 La méthode permet de distinguer les entités qui constituent la base de données, et les

associations entre ces entités. Ces concepts permettent de donner une structure à la base, ce
qui s’avère indispensable.

4 07/06/2024
 1. Bon et mauvais schémas
Considérons une table FilmSimple stockant des films avec quelques informations de base,
dont le metteur en scène. Voici une représentation de cette table.

titre année nomMES PrénomMES annéeNaiss

Alien 1979 Scott Ridley 1943
Vertigo 1958 Hitchcock Alfred 1899
Psychose 1960 Hitchcock Alfred 1899
Kagemusha 1980 Kurosawa Akira 1910
Volte-face 1997 Woo John 1946
Pulp Fiction 1995 Tarantino Quentin 1963
Titanic 1997 Cameron James 1954
Sacrifice 1986 Tarkovski Andrei 1932

Même pour une information aussi simple, il est facile d’énumérer tout un ensemble de
problèmes potentiels. Tous ou presque découlent d’un grave défaut de la table ci-dessus:
il est possible de représenter la même information plusieurs fois.

5 07/06/2024
 1. Bon et mauvais schémas

 Anomalies lors d’une insertion : Rien n’empêche de représenter plusieurs fois le même film.

Pire : il est possible d’insérer plusieurs fois le film Vertigo en le décrivant à chaque fois de
manière différente, par exemple en lui attribuant une fois comme réalisateur Alfred Hitchcock,
puis une autre fois John Woo, etc
 Anomalies lors d’une modification : La redondance d’information entraîne également des

anomalies de mise à jour. Supposons que l’on modifie l’année de naissance de Hitchcock pour
la ligne Vertigo et pas pour la ligne Psychose. On se retrouve alors avec des informations
incohérentes
 Anomalies lors d’une destruction : On ne peut pas supprimer un film sans supprimer du

même coup son metteur en scène. Si on souhaite, par exemple, ne plus voir le film Titanic
figurer dans la base de données, on va effacer du même coup les informations sur James
Cameron.

6 07/06/2024
 2. La bonne méthode
Une bonne méthode évitant les anomalies ci-dessus consiste à :
 être capable de représenter individuellement les films et les réalisateurs, de manière à ce
qu’une action sur l’un n’entraîne pas systématiquement une action sur l’autre;
 définir une méthode d’identification d’un film ou d’un réalisateur, qui permette d’assurer que
la même information est représentée une seule fois;
 préserver le lien entre les films et les réalisateurs, mais sans introduire de redondance.

Commençons par les deux premières étapes. On va d’abord distinguer la table des films et la
table des réalisateurs. Ensuite on décide que deux films ne peuvent avoir le même titre, mais que
deux réalisateurs peuvent avoir le même nom. Afin d’avoir un moyen d’identifier les réalisateurs,
on va leur attribuer un numéro, désigné par id. On obtient le résultat suivant, les identifiants (ou
clés) étant en gras.
titre année id nomMES PrénomMES annéeNaiss
Alien 1979 1 Scott Ridley 1943
Vertigo 1958 2 Hitchcock Alfred 1899
Psychose 1960 3 Kurosawa Akira 1910
Kagemusha 1980 4 Woo John 1946
Volte-face 1997 5 Tarantino Quentin 1963
Pulp Fiction 1995 6 Cameron James 1954
Titanic 1997 7 Tarkovski Andrei 1932
Sacrifice 1986
7 Tables des films Table des réalisateurs 07/06/2024
 2. La bonne méthode

Premier progrès: il n’y a maintenant plus de redondance dans la base de données. Le réalisateur
Hitchcock, par exemple, n’apparaît plus qu’une seule fois, ce qui élimine les anomalies de mise à
jour évoquées précédemment.

Il reste à représenter le lien entre les films et les metteurs en scène, sans introduire de
redondance. Maintenant que nous avons défini les identifiants, il existe un moyen simple pour
indiquer quel est le metteur en scène qui a réalisé un film: associer l’identifiant du metteur en
scène au film. On ajoute un attribut idMES dans la table Film, et on obtient la représentation
suivante.

titre année idMES id nomMES PrénomMES annéeNaiss

Alien 1979 1 1 Scott Ridley 1943
Vertigo 1958 2 2 Hitchcock Alfred 1899
Psychose 1960 2 3 Kurosawa Akira 1910
Kagemusha 1980 3 4 Woo John 1946
Volte-face 1997 4 5 Tarantino Quentin 1963
Pulp Fiction 1995 5 6 Cameron James 1954
Titanic 1997 6 7 Tarkovski Andrei 1932
Sacrifice 1986 7
Tables des films Tables des
8 07/06/2024
réalisateurs
 2. La bonne méthode

Cette représentation est correcte. La redondance est réduite au minimum puisque

seule la clé identifiant un metteur en scène a été déplacée dans une autre table (on
parle de clé étrangère). On peut vérifier que toutes les anomalies que nous avons
citées ont disparu.
 Anomalie d’insertion. Maintenant que l’on sait quelles sont les caractéristiques
qui identifient un film, il est possible de déterminer au moment d’une insertion si
elle va introduire ou non une redondance. Si c’est le cas on doit interdire cette
insertion.
 Anomalie de mise à jour. Il n’y a plus de redondance, donc toute mise à jour
affecte l’unique instance de la donnée à modifier.
 Anomalie de destruction. On peut détruire un film sans affecter les informations
sur le réalisateur.
La modélisation avec un graphique Entité/Association offre une méthode simple pour
arriver au résultat ci-dessus, et ce même dans des cas beaucoup plus complexes.

9 07/06/2024
 II. Le modèle E/A: Présentation informelle

Un schéma E/A décrit l’application visée, c’est-à-dire une abstraction d’un domaine d’étude,
pertinente relativement aux objectifs visés. Rappelons qu’une abstraction consiste à choisir
certains aspects de la réalité perçue (et donc à éliminer les autres). Cette sélection se fait en
fonction de certains besoins qui doivent être précisément définis.

Par exemple, pour notre base de données Films, on n’a pas besoin de stocker dans la base de
données l’intégralité des informations relatives à un internaute, ou à un film. Seules comptent
celles qui sont importantes pour l’application. Voici le schéma décrivant cette base de données
Films (figure 1). Sans entrer dans les détails pour l’instant, on distingue
 des entités, représentées par des rectangles, ici Film, Artiste, Internaute et Pays;
 des associations entre entités représentées par des liens entre ces rectangles. Ici on a
représenté par exemple le fait qu’un artiste joue dans des films, qu’un internaute note des
films, etc.

Chaque entité est caractérisée par un ensemble d’attributs, parmi lesquels un ou plusieurs
forment l’identifiant unique (en gras). Comme nous l’avons exposé précédemment, il est
essentiel de dire ce qui caractérise de manière unique une entité, de manière à éviter la
redondance d’information.

10 07/06/2024
 II. Le modèle E/A: Présentation informelle
Les associations sont caractérisées par des cardinalités. La notation 0..* sur le lien Réalise, du
côté de l’entité Film, signifie qu’un artiste peut réaliser plusieurs films, ou aucun. La notation
0..1 du côté Artiste signifie en revanche qu’un film ne peut être réalisé qu’au plus un artiste. En
revanche dans l’association Donne une note, un internaute peut noter plusieurs films, et un film
peut être noté par plusieurs internautes, ce qui justifie l’a présence de 0..* aux deux extrémités de
l’association.
Artiste Internaute

Donne une note

id email
Réalise
*
nom nom
0..1 note
prénom 0..* * prénom

annéeNaissance motDePpasse
Film
0..* annéeNaissance
id
Joue
titre
0..*
année

genre
rôle
résumé Pays

* code
1..1
nom

langue

11 figure 1 : Le schéma de la base de données Films 07/06/2024

 II. Le modèle E/A: Présentation informelle
o Le choix des cardinalités est essentiel. Ce choix est aussi parfois discutable, et constitue donc l’aspect le
plus délicat de la modélisation. Reprenons l’exemple de l’association Réalise. En indiquant qu’un film est
réalisé par un seul metteur en scène, on s’interdit les – rares – situations où un film est réalisé par plusieurs
personnes. Il ne sera donc pas possible de représenter dans la base de données une telle situation. Tout
est ici question de choix et de compromis: est-on prêt en occurrence à accepter une structure plus
complexe (avec « 0..* » de chaque côté) pour l’association Réalise, pour prendre en compte un nombre
minime de cas?
o Les cardinalités sont notées par deux chiffres. Le chiffre de droite est la cardinalité maximale, qui vaut en
général 1 ou *. Le chiffre de gauche est la cardinalité minimale. Par exemple la notation 0..1 entre Artiste et
Film indique qu’on s’autorise à ne pas connaître le metteur en scène d’un film. Attention: cela ne signifie
pas que ce metteur en scène n’existe pas. Une base de données, telle qu’elle est décrite par un schéma
E/A, n’est qu’une vision partielle de la réalité. On ne doit surtout pas rechercher une représentation
exhaustive, mais s’assurer de la prise en compte des besoins de l’application.
o La notation « 1..1 » entre Film et Pays indique au contraire que l’on doit toujours connaître le pays
producteur d’un film. On devra donc interdire le stockage dans la base d’un film sans son pays.
o Les cardinalités minimales (également appelées contraintes de participation) sont moins importantes que
les cardinalités maximales, car elles ont un impact moindre sur la structure de la base de données et
peuvent plus facilement être remises en cause après coup. Il faut bien être conscient de plus qu’elles ne
représentent qu’un choix de conception, souvent discutable. Dans la notation UML que nous présentons
ici, il existe des notations abrégées qui donnent des valeurs implicites aux cardinalités minimales:
 La notation « * » est équivalente à « 0..* »;
 la notation « 1 » est équivalente à « 1..1 ».

12 07/06/2024
 II. Le modèle E/A: Présentation informelle
 Outre les propriétés déjà évoquées (simplicité, clarté de lecture), évidentes sur ce schéma, on
peut noter aussi que la modélisation conceptuelle est totalement indépendante de tout choix
d’implantation. Le schéma de la figure 1 ne spécifie aucun système en particulier. Il n’est pas
non plus question de type ou de structure de données, d’algorithme, de langage, etc. En
principe, il s’agit donc de la partie la plus stable d’une application. Le fait de se débarrasser à
ce stade de la plupart des considérations techniques permet de se concentrer sur l’essentiel:
que veut-on stocker dans la base?
 Une des principales difficultés dans le maniement des schémas E/A est que la qualité du
résultat ne peut s’évaluer que par rapport à une demande qui est souvent floue et incomplète.
Il est donc souvent difficile de valider (en fonction de quels critères?) le résultat. Peut-on
affirmer par exemple que:
 toutes les informations nécessaires sont représentées;
 qu’un film ne sera jamais réalisé par plus d’un artiste;
 qu’il n’y aura jamais deux films avec le même titre.
 Il faut faire des choix, en connaissance de cause, en sachant toutefois qu’il est toujours
possible de faire évoluer une base de données, quand cette évolution n’implique pas de
restructuration trop importante. Pour reprendre les exemples ci-dessus, il est facile d’ajouter
des informations pour décrire un film ou un internaute; il serait beaucoup plus difficile de
modifier la base pour qu’un film passe de un, et un seul, réalisateur, à plusieurs. Quant à
changer la clé de Film, c’est une des évolutions les plus complexes à réaliser. Les cardinalités et
13 le choix des clés font vraiment partie des aspects décisifs des choix de conception. 07/06/2024
 III. Le modèle E/A

Le modèle E/A, conçu en 1976, est à la base de la plupart des méthodes de

conception. La syntaxe employée ici est celle de la méthode UML [(Unified
Modeling Language) représentent les systèmes selon différents niveaux de
détail)], reprise à peu près à l’identique de celle de la méthode OMT (La Object
Modeling Technique repose sur l'emploi d'une notation orientée objet pour
décrire les classes et les relations tout au long du cycle de vie). Il existe beaucoup
d’autres notations, dont celle de la méthode MERISE (Méthode d'Étude et de
Réalisation Informatique par les Sous-Ensembles) principalement utilisée en
France. Ces notations sont globalement équivalentes. Dans tous les cas la
conception repose sur deux concepts complémentaires, entité et association.

14 07/06/2024
 1. Entités, attributs et identifiants

Il est difficile de donner une définition très précise des entités. Les points essentiels sont
résumés ci-dessous.

Définition 1 (Entité) On désigne par entité tout objet identifiable et pertinent pour
l’application.
Comme nous l’avons vu précédemment, la notion d’identité est primordiale. C’est elle qui
permet de distinguer les entités les unes des autres, et donc de dire qu’une information est
redondante ou qu’elle ne l’est pas. Il est indispensable de prévoir un moyen technique pour
pouvoir effectuer cette distinction entre entités au niveau de la base de données: on parle
d’identifiant ou de clé.

15 07/06/2024
 1. Entités, attributs et identifiants

La pertinence est également essentielle: on ne doit prendre en compte que les informations
nécessaires pour satisfaire les besoins. Par exemple:
1. le film Impitoyable;
2. l’acteur Clint Eastwood ;
sont des entités pour la base Films.

La première étape d’une conception consiste à identifier les entités utiles. On peut souvent le
faire en considérant quelques cas particuliers. La deuxième est de regrouper les entités en
ensembles: en général on ne s’intéresse pas à un individu particulier mais à des groupes. Par
exemple il est clair que les films et les acteurs sont des ensembles distincts d’entités. Qu’en est-
il de l’ensemble des réalisateurs et de l’ensemble des acteurs? Doit-on les distinguer ou les
assembler? Il est certainement préférable de les assembler, puisque des acteurs peuvent aussi
être réalisateurs

16 07/06/2024
 1. Entités, attributs et identifiants

Attribut
Les entités sont caractérisées par des propriétés: le titre (du film), le nom (de l’acteur), sa
date de naissance, l’adresse, etc. Ces propriétés sont dénotées attributs dans la terminologie
du modèle E/A. Le choix des attributs relève de la même démarche d’abstraction qui a dicté
la sélection des entités: il n’est pas question de donner exhaustivement toutes les propriétés
d’une entité. On ne garde que celles utiles pour l’application.
Un attribut est désigné par un nom et prend ses valeurs dans un domaine énumérable
comme les entiers, les chaînes de caractères, les dates, etc. On peut considérer un nom
d’attribut comme une fonction définie sur un ensemble d’entités E et prenant ses valeurs dans
un domaine D. On note alors la valeur de l’attribut A pour une entité .
Considérons par exemple un ensemble de films et les attributs titre et année. Si est le film
Impitoyable, tourné par Clint Eastwood en 1992, on aura:

17 titre () = Impitoyable; année () = 1992 07/06/2024

 1. Entités, attributs et identifiants

Il est très important de noter que selon cette définition un attribut prend une valeur et une
seule. On dit que les attributs sont atomiques. Il s’agit d’une restriction importante puisqu’on
ne sait pas, par exemple, définir un attribut téléphones d’une entité Personne, prenant pour
valeur les numéros de téléphone d’une personne. Certaines méthodes admettent (plus ou
moins clairement) l’introduction de constructions plus complexes:

1. les attributs multivalués sont constitués d’un ensemble de valeurs prises dans un même
domaine; une telle construction permet de résoudre le problème des numéros de
téléphones multiples;

2. les attributs composés sont constitués par agrégation d’autres attributs; un attribut adresse
peut par exemple être décrit comme l’agrégation d’un code postal, d’un numéro de rue,
d’un nom de rue et d’un nom de ville.

Nous nous en tiendrons pour l’instant aux attributs atomiques qui, au moins dans le contexte
18 07/06/2024
d’une modélisation orientée vers un SGBD relationnel, sont suffisants.
 1. Entités, attributs et identifiants

Types d’entités
Il est maintenant possible de décrire un peu plus précisément les entités par leur
type.
Définition 2 (Type d’entité) Le type d’une entité est composé des éléments
suivants:
1. son nom;
2. la liste de ses attributs avec, – optionnellement – le domaine où l’attribut prend
ses valeurs: les entiers, les chaînes de caractères;
3. l’indication du (ou des) attribut(s) permettant d’identifier l’entité: ils constituent
la clé.
On dit qu’une entité est une instance de son type . Enfin, un ensemble
d’entités instance d’un même type est une extension de .
Il reste à définir plus précisément la notion de clé.

19 07/06/2024
 1. Entités, attributs et identifiants
Définition 3 (Clé) Soit un type d’entité et l’ensemble des attributs de . Une clé de est un sous-
ensemble minimal de permettant d’identifier de manière unique une entité parmi n’importe
quelle extension de .
Prenons quelques exemples pour illustrer cette définition. Un internaute est caractérisé par
plusieurs attributs: son email, son nom, son prénom, la région où il habite. L’email constitue
une clé naturelle puisqu’on ne trouve pas, en principe, deux internautes ayant la même
adresse électronique. En revanche l’identification par le nom seul paraît impossible puisqu’on
constituerait facilement un ensemble contenant deux internautes avec le même nom. On
pourrait penser à utiliser la paire (nom,prénom), mais il faut utiliser avec modération
l’utilisation d’identifiants composés de plusieurs attributs, quoique possible, peut poser des
problèmes de performance et complique les manipulations par SQL.
Il est possible d’avoir plusieurs clés pour un même ensemble d’entités. Dans ce cas on en
choisit une comme clé primaire, et les autres comme clés secondaires. Le choix de la clé
(primaire) est déterminant pour la qualité du schéma de la base de données. Les
caractéristiques d’une bonne clé primaire sont les suivantes:
– sa valeur est connue pour toute entité;
– on ne doit jamais avoir besoin de la modifier ;
enfin, pour des raisons de performance, sa taille de stockage doit être la plus petite07/06/2024
possible.
20
 1. Entités, attributs et identifiants

Il n’est pas toujours évident de trouver un ensemble d’attributs satisfaisant ces propriétés.
Considérons l’exemple des films, le choix du titre pour identifier un film serait incorrect puisqu’on
aura à faire un jour ou l’autre à deux films ayant le même titre. Même en combinant le titre avec un
autre attribut (par exemple l’année), il est difficile de garantir l’unicité.
Dans la situation, fréquente, où on a du mal à déterminer quelle est la clé d’une entité, on crée un
identifiant abstrait indépendant de tout autre attribut. On peut ainsi ajouter dans le type d’entité
Film un attribut id, correspondant à un numéro séquentiel qui sera incrémenté au fur et à mesure
des insertions. Ce choix est souvent le meilleur, dès lors qu’un attribut ne s’impose pas de manière
évidente comme clé. Il satisfait notamment toutes les propriétés énoncées précédemment (on peut
toujours lui attribuer une valeur, il ne sera jamais nécessaire de la modifier, et elle a une
représentation compacte).
On représente graphiquement un type d’entité comme sur la figure 2 qui donne l’exemple des
types Internaute et Film. L’attribut (ou les attributs s’il y en a plusieurs) formant la clé sont en gras.
21 07/06/2024
 1. Entités, attributs et identifiants

Internaute Nom du type d’entité Film

email id
Identifiant
nom titre

prénom année
Attributs
région résumé

genre

figure 2 : Représentation des types d’entité

Il est essentiel de bien distinguer types d’entités et entités. La distinction est la même
qu’entre schéma et base dans un SGBD, ou entre type et valeur dans un langage de
programmation.

22 07/06/2024
 2. Associations binaires
Définition 4: Une association binaire entre les ensembles d’entités et est un ensemble de
couples , avec et .
C’est la notion classique de relation en théorie des ensembles. On emploie plutôt le terme
d’association pour éviter toute confusion avec le modèle relationnel. Une bonne manière
d’interpréter une association entre des ensembles d’entités est de faire un petit graphe où on
prend quelques exemples, les plus généraux possibles.

Les réalisateurs Les liens "Réalise" Les films

Alfred Hitchcock Vertigo

Clint Eastwood Impitoyable

Psychose

23 figure 3 : Association entre deux ensembles.

07/06/2024
 2. Associations binaires

Prenons l’exemple de l’association représentant le fait qu’un réalisateur met en

scène des films. Sur le graphe de la figure 3 on remarque que:
1. certains réalisateurs mettent en scène plusieurs films;
2. inversement, un film est mis en scène par au plus un réalisateur.
La recherche des situations les plus générales possibles vise à s’assurer que les
deux caractéristiques ci-dessus sont vraies dans tous les cas. Bien entendu on peut
trouver 1% des cas où un film a plusieurs réalisateurs, mais la question se pose
alors: doit-on modifier la structure de notre base, pour 1% des cas. Ici, on a décidé
que non. Encore une fois on ne cherche pas à représenter la réalité dans toute sa
complexité, mais seulement la partie de cette réalité que l’on veut stocker dans la
base de données.
Ces caractéristiques sont essentielles dans la description d’une association entre
des ensembles d’entités.

24 07/06/2024
 2. Associations binaires
Définition 5 (Cardinalité) Soit une association entre deux types d’entités. La cardinalité de
l’association pour , est une paire [min, max] telle que:
1. Le symbole max (cardinalité maximale) désigne le nombre maximal de fois où une entité
de peut intervenir dans l’association. En général, ce nombre est 1 (au plus une fois) ou n
(plusieurs fois, nombre indéterminé), noté par le symbole « * »
2. Le symbole min (cardinalité minimale) désigne le nombre minimal de fois où une entité de
peut intervenir dans la relation. En général, ce nombre est 1 (au moins une fois) ou 0.

Les cardinalités maximales sont plus importantes que les cardinalités minimales ou, plus
précisément, elles s’avèrent beaucoup plus difficiles à remettre en cause une fois que le
schéma de la base est constitué. On décrit donc souvent une association de manière abrégée
en omettant les cardinalités minimales. La notation « * », en UML, est l’abréviation de
« 0..* », et « 1 » est l’abréviation de « 1..1 ». On caractérise également une association de
manière concise en donnant les cardinalités maximales aux deux extrémités, par exemple
« 1:n » (association de un à plusieurs) ou « n:n » (association de plusieurs à plusieurs).
25 07/06/2024
 2. Associations binaires

Les cardinalités minimales sont parfois désignées par le terme contraintes de participation.
La valeur 0 indique qu’une entité peut ne pas participer à l’association, et la valeur 1 qu’elle
doit y participer.
Insistons sur le point suivant: les cardinalités n’expriment pas une vérité absolue, mais des
choix de conception. Elles ne peuvent être déclarés valides que relativement à un besoin. Plus
ce besoin sera exprimé précisément, et plus il sera possible d’apprécier la qualité du modèle.
Il existe plusieurs manières de noter une association entre types d’entités. Nous utilisons ici
la notation de la méthode UML, qui est très proche de celle de la méthode OMT. En France,
on utilise aussi couramment – de moins en moins – la notation de la méthode MERISE que
nous ne présenterons pas ici. Réalisateur Film
0..1 0 ..n
id id
Réalise
nom titre
prénom année
annéeNaissance genre

26 07/06/2024
figure 4: Représentation de l’association.
 2. Associations binaires
Dans la notation UML, on indique les cardinalités aux deux extrémités d’un lien
d’association entre deux types d’entités et . Les cardinalités pour sont placées à l’extrémité
du lien allant de vers et les cardinalités pour sont à l’extrémité du lien allant de vers . Pour
l’association entre Réalisateur et Film, cela donne l’association de la figure 4. Cette
association se lit Un réalisateur réalise zéro, un ou plusieurs films, mais on pourrait tout aussi
bien utiliser la forme passive avec comme intitulé de l’association Est réalisé par et une
lecture Un film est réalisé par au plus un réalisateur. Le seul critère à privilégier dans ce
choix des termes est la clarté de la représentation.
Prenons maintenant l’exemple de l’association (Acteur, Film) représentant le fait qu’un
acteur joue dans un film. Un graphe basé sur quelques exemples est donné dans la figure 5.
On constate tout d’abord qu’un acteur peut jouer dans plusieurs films, et que dans un film on
trouve plusieurs acteurs. Mieux: Clint EastWood, qui apparaissait déjà en tant que metteur en
scène, est maintenant également acteur, et dans le même film.
Les acteurs Les liens "Joue" Les films

Tom Cruise Ennemi d’état

Gene Hackman Impitoyable
Clint Eastwood
Jacques Dutronc Van Gogh

figure 5: Association (Acteur, Film)

27 07/06/2024
 2. Associations binaires

Cette dernière constatation mène à la conclusion qu’il vaut mieux regrouper les acteurs et
les réalisateurs dans un même ensemble, désigné par le terme plus général Artiste. On obtient
le schéma de la figure 6, avec les deux associations représentant les deux types de lien
possible entre un artiste et un film: il peut jouer dans le film, ou le réaliser. Ce ou n’est pas
exclusif: EastWood joue dans Impitoyable, qu’il a aussi réalisé.

Artiste Film
Réalise
id id
1..1 0..*
nom titre
0..* 0..*
prénom année
Joue
annéeNaiss genre
rôle

figure 6 : Associations entre Artiste et Film

28 07/06/2024
 2. Associations binaires

Dans le cas d’associations avec des cardinalités multiples de chaque côté, on peut
avoir des attributs qui ne peuvent être affectés qu’à l’association elle-même. Par
exemple l’association Joue a pour attribut le rôle tenu par l’acteur dans le film
(figure 6).
Rappelons qu’un attribut ne peut prendre qu’une et une seule valeur. Clairement,
on ne peut associer rôle ni à Acteur puisqu’il a autant de valeurs possibles qu’il y a
de films dans lesquels cet acteur a joué, ni à Film, la réciproque étant vraie
également. Seules les associations ayant des cardinalités multiples de chaque côté
peuvent porter des attributs.
Quelle est la clé d’une association? Si l’on s’en tient à la définition, une
association est un ensemble de couples, et il ne peut donc y avoir deux fois le même
couple (parce qu’on ne trouve pas deux fois le même élément dans un ensemble).
On a donc:
Définition 6 (Clé d’une association) La clé d’une association (binaire) entre un
type d’entité et un type d’entité est le couple constitué de la clé de et de la clé
de .
29 07/06/2024
 2. Associations binaires

En pratique cette contrainte est souvent trop contraignante car on souhaite autoriser deux
entités à être liées plus d’une fois dans une association. Imaginons par exemple qu’un
internaute soit amené à noter à plusieurs reprises un film, et que l’on souhaite conserver
l’historique de ces notations successives. Avec une association binaire entre Internaute et
Film, c’est impossible: on ne peut définir qu’un seul lien entre un film donné et un internaute
donné.
Le problème est qu’il n’existe pas de moyen pour distinguer des liens multiples entre deux
mêmes entités. Le seul moyen pour effectuer une telle distinction est d’introduire une entité
discriminante, par exemple la date de la notation. On obtient alors une association ternaire
dans laquelle on a ajouté un type d’entité Date (figure 7).
Date
date

Internaute Film
email id
note
nom titre
prénom année
région genre

figure 7: Ajout d’une entité Date pour conserver l’historique des notations
30 07/06/2024
 2. Associations binaires
Un lien de cette association réunit donc une entité Film, une entité Internaute et une entité
Date. On peut identifier un tel lien par un triplet (id, email, date) constitué par les clés des
trois entités constituant le lien.
Comme le montre la figure 8, il devient alors possible, pour un même internaute, de noter
plusieurs fois le même film, pourvu que ce ne soit pas à la même date. Réciproquement un
internaute peut noter des films différents le même jour, et un même film peut être noté
plusieurs fois à la même date, à condition que ce ne soit pas par le même internaute.
Internautes Films

Phileas Fogg
Ennemi d’état

Jules Maigret
Van Gogh

12 juillet 2023 6 juin 2000

Dates
31 figure 8: Graphe d’une association ternaire 07/06/2024
 3. Entités faibles

Jusqu’à présent nous avons considéré le cas d’entités indépendantes les unes des autres.
Chaque entité, disposant de son propre identifiant, pouvait être considérée isolément. Il existe
des cas où une entité ne peut exister qu’en étroite association avec une autre, et est identifiée
relativement à cette autre entité. On parle alors d’entité faible.
Prenons l’exemple d’un cinéma, et de ses salles. On peut considérer chaque salle comme
une entité, dotée d’attributs comme la capacité, l’équipement en son Dolby, ou autre. Il est
difficilement imaginable de représenter une salle sans qu’elle soit rattachée à son cinéma.
C’est en effet au niveau du cinéma que l’on va trouver quelques informations générales
comme l’adresse ou le numéro de téléphone.
Il est possible de représenter le lien en un cinéma et ses salles par une association classique,
comme le montre la figure 3.10.a. La cardinalité 1..1 force la participation d’une salle à un
lien d’association avec un et un seul cinéma. Cette représentation est correcte, mais présente
un inconvénient: on doit créer un identifiant artificiel id pour le type d’entité Salle, et
numéroter toutes les salles, indépendamment du cinéma auquel elles sont rattachées.
On peut considérer qu’il est beaucoup plus naturel de numéroter les salles par un numéro
interne à chaque cinéma. La clé d’identification d’une salle est alors constituée de deux
parties:

32 07/06/2024
 3. Entités faibles
1. la clé de Cinéma, qui indique dans quel cinéma se trouve la salle;
2. le numéro de la salle au sein du cinéma.
En d’autres termes, l’entité salle ne dispose pas d’une identification absolue, mais d’une
identification relative à une autre entité. Bien entendu cela force la salle a toujours être
associée à un et un seul cinéma.
La représentation graphique des entités faibles avec UML est illustrée dans la figure 10.b.
La salle est associée au cinéma avec une association qualifiée par l’attribut no qui sert de
discriminant pour distinguer les salles au sein d’un même cinéma. Noter que la cardinalité du
côté Cinéma est implicitement 1..1 .
Cinéma Cinéma

nom nom
ville ville
rue rue
numéro numéro

1 no

*
Figure 10: Modélisation du lien *
Salle
Cinéma-Salle (a) sous la forme d’une Salle
id
association classique (b) avec une capacité
capacité

entité faible dateConstr.

dateConstr.

33 (a) (b) 07/06/2024

 3. Entités faibles

L’introduction d’entités faibles n’est pas une nécessité absolue puisqu’on peut très
bien utiliser une association classique. La principale différence est que, dans le cas
d’une entité faible, on obtient un identification composée qui est souvent plus
pratique à gérer, et peut également rendre plus faciles certaines requêtes.
La présence d’un type d’entité faible associé à un type d’entité implique également
des contraintes fortes sur les créations, modifications et destructions des instances de
et car on doit toujours s’assurer que la contrainte est valide. Concrètement, en
prenant l’exemple de Salle et de Cinéma, on doit mettre en place les mécanismes
suivants:
1. Quand on insère une salle dans la base, on doit toujours l’associer à un cinéma;
2. quand un cinéma est détruit, on doit aussi détruire toutes ses salles;
3. quand on modifie la clé d’un cinéma, il faut répercuter la modification sur toutes
ses salles.
Pour respecter les règles de destruction/création énoncées, on doit mettre en place
une stratégie. Nous verrons que les SGBD relationnels nous permettent de spécifier
de telles stratégies.
34 07/06/2024
 4. Entités Généralisées
On peut envisager des associations entre plus de deux entités, mais elles sont plus difficiles
à comprendre, et surtout la signification des cardinalités devient beaucoup plus ambiguë. La
définition d’une association n-aire est une généralisation de celle des associations binaires.
Définition 7 : Une association n-aire entre n types d’entités , , …, est un ensemble de n-
uplets , , …, ) où chaque appartient à .
Même s’il n’y a en principe pas de limite sur le degré d’une association, en pratique on ne
va jamais au-delà d’une association entre trois entités.

Cinéma Horaire

nom id
ville heureDébut
rue heureFin
numéro

no

*
Salle Film
Séance
id
capacité
titre
dateConstr. année
tarif
genre

35 07/06/2024
figure 11: Association ternaire représentant les séances
 4. Entités Généralisées
Horaires

14 h−16h 16 h−18h

Films

Salles

Salle Rex−1 Impitoyable

Vertigo
Salle Kino−3

figure 12: Graphe d’une association ternaire

Nous allons prendre l’exemple d’une association permettant de représenter la projection de
certains films dans des salles à certains horaires. Il s’agit d’une association ternaire entre les
types d’entités Film, Salle et Horaire (figure 11). Chaque instance de cette association lie un
film, un horaire et une salle. La figure 12 montre quelques-unes de ces instances.
Bien que, jusqu’à présent, une association ternaire puisse être considérée comme une
généralisation directe des associations binaires, en réalité de nouveaux problèmes sont
soulevés.
36 07/06/2024
 4. Entités Généralisées
Tout d’abord les cardinalités sont, implicitement, 0..*. Il n’est pas possible de dire qu’une
entité ne participe qu’une fois à l’association. Il est vrai que, d’une part la situation se
présente rarement, d’autre part cette limitation est due à la notation UML qui place les
cardinalités à l’extrémité opposée d’une entité.
Plus problématique en revanche est la détermination de la clé. Qu’est-ce qui identifie un
lien entre trois entités? En principe, la clé est le triplet constitué des clés respectives de la
salle, du film et de l’horaire constituant le lien. On aurait donc le n-uplet [nomCinéma,
noSalle, idFilm, idHoraire]. Une telle clé est assez volumineuse, ce qui risque de poser des
problèmes de performance. De plus elle ne permet pas d’imposer certaines contraintes
comme, par exemple, le fait que dans une salle, pour un horaire donné, il n’y a qu’un seul
film. Comme le montre la figure 12, il est tout à fait possible de créer deux liens distincts qui
s’appuient sur le même horaire et la même salle.
Ajouter une telle contrainte, c’est signifier que la clé de l’association est en fait le couple
[ nomCinéma, noSalle, idHoraire]. Donc c’est un sous-ensemble de la concaténation des
clés, ce qui semble rompre avec la définition donnée précédemment. On peut évidemment
compliquer les choses en ajoutant une deuxième contrainte similaire, comme connaissant le
film et l’horaire, je connais la salle. Il faut ajouter une deuxième clé [idFilm, idHoraire]. Il
n’est donc plus possible de déduire automatiquement la clé comme on le faisait dans le cas
des associations binaires. Plusieurs clés deviennent possibles : on parle de clé candidates.
37 07/06/2024
 4. Entités Généralisées
Les associations de degré supérieur à deux sont donc difficiles à manipuler et à interpréter.
Il est toujours possible de remplacer cette association par un type d’entité. Pour cela on suit la
règle suivante:
Règle 1: Soit Aune association entre les types d’entité , , …, }. La transformation de A en
type d’entité s’effectue en trois étapes:
1. On attribue un identifiant autonome à A.
2. On crée une association de type « 1:n» entre A et chacun des . La contrainte minimale,
du côté de A, est toujours à 1.
L’association précédente peut être transformée en un type d’entité Séance. On lui attribue
un identifiant idSeance et des associations « 1-n » avec Film, Horaire et Salle.

Cinéma Horaire
nom id
ville heureDébut
rue heureFin
numéro
1..1
no
*
*
Salle Séance Film
1..1 * * 1..1 id
capacité id
titre
dateConstr. tarif année
genre
38 07/06/2024
figure 13: L’association Séance transformée en entité
 IV. Avantage et inconvénients du modèle E/A
Avantages
Le modèle Entité/Association est simple et pratique.
 Il n’y a que 3 concepts: entités, associations et attributs.
 Il est approprié à une représentation graphique intuitive, même s’il existe
beaucoup de conventions.
 Il permet de modéliser rapidement des structures pas trop complexes.

Inconvénients
o Non déterministe: il n’y a pas de règle absolue pour déterminer ce qui est entité,
attribut ou relation. Exemple: est-il préférable de représenter le metteur en scène
(MES) comme un attribut de Film ou comme une association avec Artiste?
Réponse: comme une association! Les arguments sont les suivants:
• On connaît alors non seulement le nom, mais aussi toutes les autres propriétés
(prénom, âge, ...).
• L’entité MES peut-être associée à beaucoup d’autres films: on permet le
partage de l’information.
39 07/06/2024
 IV. Avantage et inconvénients du modèle E/A

Inconvénients

o Enfin on a vu qu’une association pouvait être transformée en entité. Un

des principaux inconvénients du modèle E/A reste sa pauvreté: il est
difficile d’exprimer des contraintes d’intégrité, des structures complexes.
Beaucoup d’extensions ont été proposées, mais la conception de schéma
reste en partie matière de bon sens et d’expérience. On essaie en général:
 de se ramener à des associations entre 2 entités: au-delà, on a
probablement intérêt a transformer l’association en entité;
 d’éviter toute redondance: une information doit se trouver en un seul
endroit;
 enfin – et surtout – de privilégier la simplicité et la lisibilité, notamment
en ne représentant que ce qui est strictement nécessaire.

40 07/06/2024
 SECTION II
Modèle relationnel