Chapitre III

1
Chapitre III
Le modèle Entité/Association
III.1. Introduction
La modélisation conceptuelle est une phase cruciale dans la conception des applications de base
de données réussites. Généralement, le terme application de base de données fait référence à
une base de données particulière – par exemple, une base de données d’une banque qui garde
trace des comptes clients– et les programmes associés qui implémentent les interrogations et les
mises à jour de la base de données –par exemple, les programmes qui implémentent les mises à
jour de la base correspondant au clients qui créditent ou débitent leurs comptes. Ces programmes,
souvent, offrent des interfaces utilisateur graphiques conviviales (GUIs) à base de menus ou fenêtres.
De ce fait, une partie d’une application de base de données demandera la conception,
l’implémentation, et le test des programmes d’applications. Traditionnellement, la conception et le
test des programmes d’application ont été considérés comme étant plus du domaine de génie logiciel
que du domaine de bases de données. Cependant, il est devenu évident qu’il y ait une certaine
intersection entre les méthodologies de conception de bases de données et les méthodologies de
conception du génie logiciel. Etant donné que les méthodologies de conception de la base de données
tentent d’inclure la plupart des concepts pour la spécification des opérations sur les objets de la base de
données, et que les méthodologies de génie logiciel spécifient en plus détail la structure des bases de
données que les logiciels vont utiliser et accéder, donc, il est certain que cette intersection sera
augmentée.
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. Le modèle E/A a pour caractéristiques d’être
simple et suffisamment puissant pour représenter des structures relationnelles. Surtout, il repose
sur une représentation graphique qui facilite considérablement sa compréhension. Le modèle E/A
souffre également de nombreuses insuffisances : la principale est de ne proposer que des
structures. Il n’existe pas d’opération permettant de manipuler les données, et pas (ou peu) de
moyen d’exprimer des contraintes. Un autre inconvénient du modèle E/A est de mener à certaines
ambiguïtés pour des schémas complexes.
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. Ajoutons qu’il ne s’agit pas de concevoir un schéma E/A (voir
un cours sur les systèmes d’information), mais d’être capable de le comprendre et de l’interpréter.
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. Nous
supposerons également que cette base de données st accessible sur le Web et que des internautes
peuvent noter les films qu’ils ont vus.
III.2. Utilisation des Modèles Conceptuels de données de Haut Niveau pour la
Conception de Base de Données
La figure 1 montre une description simplifiée du processus de conception de base de données. La
première étape illustrée est la collection et l’analyse de besoins. Durant cette étape, les
concepteurs de la base de données interviewent les utilisateurs prospectifs de la base de données

2
pour comprendre et documenter leurs besoins de données. Le résultat de cette étape est un
ensemble écrit succinctement des besoins d’utilisateurs. Ces besoins doivent être spécifiés dans
une forme assez détaillée et complète. En parallèle à la spécification des besoins, il est utile de
spécifier les besoins fonctionnels connus de l’application. Ces derniers consistent des
opérations définies par les utilisateur (ou transactions) qui seront appliquées sur la base de
données, et elles incluent les opérations d’interrogations et de mises à jour. Dans la conception
du logiciel, il est courant d’utiliser des digrammes de flux de données, des digrammes de
séquences, des scénarios, et d’autres techniques pour la spécification des besoins fonctionnels.
Une fois tous les besoins ont été collectés et analysés, la deuxième étape est la création le schéma
conceptuel de la base de données, en utilisant un modèle conceptuel de données de haut niveau.
Cette étape est appelée conception conceptuelle. Le schéma conceptuel est une description
concise des besoins de données des utilisateurs et inclut des descriptions détaillées des types
d’entités, associations, et contraintes ; Ces éléments sont exprimés en utilisant les concepts
fournis par le modèle de données de haut niveau. Etant donné que les concepts n’incluent pas les
détails d’implémentation, ils sont pratiquement plus facile à comprendre et peuvent être utilisés
pour communiquer avec les utilisateurs non techniciens. Le schéma conceptuel de haut niveau
peut être aussi utilisé comme une référence pour assurer que tous les besoins de données
d’utilisateurs sont satisfaits et que ces besoins ne présentent pas des conflits. Cette approche
permet aux concepteurs de se focaliser sur la spécification des propriétés des données, sans se
soucier des détails de stockage. Par conséquent, il est plus facile pour eux de s’en sortir avec une
bonne conception de la base de données conceptuelle.
Pendant ou après la conception du schéma conceptuel, les opérations fondamentales du modèle
de données peuvent être utilisés pour spécifier les opérations utilisateur de haut niveau
identifiées pendant l’analyse fonctionnelle. Ceci sert aussi à confirmer que le schéma conceptuel
satisfait tous les besoins fonctionnels identifiés. Des modifications du schéma conceptuel peuvent
être introduites si certains besoins fonctionnels ne peuvent pas être spécifiés dans le schéma
initial.
La deuxième étape dans la conception d’une base de données est l’implémentation réelle de la
base, en utilisant un SGBD commercial. La plupart des SGBDs commerciaux utilisent un modèle
d’implémentation de données – tel que le modèle relationnel ou objet- ainsi le schéma
conceptuel est transformé à partir du modèle de données haut niveau en un modèle
d’implémentation de données. Cette étape est appelée conception logique ou la transformation
du modèle de données, et son résultat est un schéma de la base dans le modèle d’implémentation
de données du SGBD.
Finalement, la dernière étape est la conception physique, durant laquelle les structures de
stockage internes, les chemins d’accès, et les organisations des fichiers pour les fichiers de la
base de données sont spécifiés. Parallèlement à ces activités, les programmes d’application sont
conçu et implémentés comme des transactions de base de données correspondant à des
spécifications de transactions de haut niveau.

3
Figure 1 : Diagramme simplifié illustrant les principales phases de conception.
II.3. Principes Généraux
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.
Nous commençons par montrer les problèmes qui surviennent si on traite une base de données
comme un simple fichier texte, sans se soucier de lui donner une structure correcte.
- Types de données
- Associations
- Contraintes
Opérations définies par
l’utilisateur (transactions)
Digramme de flux de données

4
III.3.1. Bons 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.
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.
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.
Une bonne question consiste d’ailleurs à se demander ce qui distingue deux films l’un de l’autre,
et à quel moment on peut dire que la même information a été répétée. Peut-il y avoir deux films
différents avec le même titre par exemple ? Si la réponse est non, alors on devrait pouvoir assurer
qu’il n’y a pas deux lignes dans la table avec la même valeur pour l’attribut titre. Si la réponse
est oui, il reste à déterminer quel est l’ensemble des attributs qui permet de caractériser de
manière unique un film.
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.
Les mêmes questions que précédemment se posent d’ailleurs. Jusqu’à quel point peut-on dire
qu’il n’y a qu’un seul réalisateur nommé Hitchcock, et qu’il ne doit donc y avoir qu’une seule
année de naissance pour un réalisateur de ce nom?
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.
III.3.2. La bonne méthode
Une bonne méthode évitant les anomalies ci-dessus consiste à ;
1. ê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 ;
2. 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 ;
3. préserver le lien entre les films et les réalisateurs, mais sans introduire de redondance.

5
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.
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.
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, ilest 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.