Université de Kairouan Année Universitaire

Institut Supérieur d’Informatique 2020-2021

et de Gestion de Kairouan

Support de cours Base de Données

2èmeIG
Omar MAZHOUD

Chapitre n°1 : Présentation générale

1. Introduction générale
1.1 Définitions et propriétés :
* Donnée : Nous appellerons donnée toute valeur numérisée décrivant de manière élémentaire
un fait, une mesure, une réalité. Ce peut être une chaîne de caractères («paquet»), un
entier(365), une date13/10/2020).
Cette valeur est toujours associée au contexte permettant de savoir quelle information elle
représente.
* Base de données (BD) : Il est assez difficile de définir ce qu'est exactement une base de
données si ce n'est que de dire trivialement que tout système d'information peut être qualifié
de base de données.
Une base de données peut être aussi définie comme une collection de données interreliées,
stockées ensemble pour servir une ou plusieurs applications, en parallèle, de façon optimale.
Le stockage des données doit être indépendant des programmes d’utilisation.
* Système de Gestion de Bases de Données (SGBD = DBMS: DataBase Management
System) : Il semble plus facile de définir l'outil principal de gestion d'une base de données : le
système de gestion de bases de données (SGBD)
- C'est un outil permettant d'insérer, de modifier et de rechercher efficacement des
données spécifiques dans une grande masse d'informations.
- C'est une interface entre les utilisateurs et la mémoire secondaire facilitant le travail
des utilisateurs en leur donnant l'illusion que toute l'information est comme ils le
souhaitent. Chacun doit avoir l'impression qu'il est seul à utiliser l'information.
Le SGBD est composé de trois couches successives :

Disque

Programmes
d'application

Gestionnaire de fichiers
Terminaux

SGBD interne

SGBD externe

Modèle à 3 couches

1
 - Le système de gestion de fichiers : Il gère le stockage physique de l'information. Il
est dépendant du matériel utilisé (type de support, facteur de blocage, etc.)
- Le SGBD interne : Il s'occupe du placement et de l'assemblage des données, gestion
des liens et gestion de l'accès rapide.
- Le SGBD externe : Il s'occupe de la présentation et de la manipulation des données
aux concepteurs et utilisateurs. Il s'occupe de la gestion de langages de requêtes
élaborées et des outils de présentation (états, formes, etc.)
1.2 Objectifs et avantages des SGBD :
Un système d'information peut toujours être réalisé sans outil spécifique. On peut alors se
demander quels sont les objectifs et avantages de l'approche SGBD par rapport aux fichiers
classiques. La réponse tient en neuf points fondamentaux :
1. Indépendance physique. Les disques, la machine, les méthodes d'accès, les modes de
placement, les méthodes de tris, le codage des données ne sont pas apparents. Le SGBD
offre une structure canonique permettant la représentation des données réelles sans se
soucier de l'aspect matériel.
2. Indépendance logique. Chaque groupe de travail doit pouvoir se concentrer sur ce qui
l'intéresse uniquement. Il doit pouvoir arranger les données comme il le souhaite même si
d'autres utilisateurs ont une vue différente. L'administrateur doit pouvoir faire évoluer le
système d'informations sans remettre en cause la vue de chaque groupe de travail.
Exemple : une base de données contient les informations suivantes :
véhicule(num-véhicule, marque, type, couleur)
personne(num-ss, nom, prénom)
propriétaire(num-ss, num-véhicule, date-achat)
Un groupe de travail ne s'intéressera qu'aux personnes qui possèdent une voiture :
personne(num-ss, nom, prénom, num-véhicule)
Un autre groupe ne s'intéressera qu'aux véhicules vendus à une certaine date :
voiture(num-véhicule, type, marque, date-achat)
3. Manipulable par des non-informaticiens. Le SGBD doit permettre d'obtenir les données
par des langages non procéduraux. On doit pouvoir décrire ce que l'on souhaite sans
décrire comment l'obtenir.
4. Accès aux données efficace. Les accès disque sont lents relativement à l'accès à la
mémoire centrale. Il faut donc offrir les meilleurs algorithmes de recherche de données à
l'utilisateur.
5. Administration centralisée des données. Le SGBD doit offrir aux administrateurs des
données des outils de vérification de cohérence des données, de restructuration éventuelle
de la base, de sauvegarde ou de réplication. L'administration est centralisée et est réservée
à un très petit groupe de personnes pour des raisons évidentes de sécurité.
6. Non redondance des données. Le SGBD doit permettre d'éviter la duplication
d'informations qui, outre la perte de place mémoire, demande des moyens humains
importants pour saisir et maintenir à jour plusieurs fois les mêmes données.
7. Cohérence des données. Cette cohérence est obtenue par la vérification des contraintes
d'intégrité. Une contrainte d'intégrité est une contrainte sur les données de la base, qui doit
toujours être vérifiée pour assurer la cohérence de cette base. Les systèmes d'information
sont souvent remplis de telles contraintes, le SGBD doit permettre une gestion
automatique de ces contraintes d'intégrité sur les données. Par exemple :
- Un identifiant doit toujours être saisi.
- Le salaire doit être compris entre 400 et 1000D.
- Le nombre de commandes du client doit correspondre avec le nombre de commandes
dans la base.
- L'emprunteur d'un livre doit être un abonné du club.
- Dans un SGBD les contraintes d'intégrité doivent pouvoir être exprimées et gérées
dans la base et non pas dans les applications.

2
8. Partageabilité des données. Le SGBD doit permettre à plusieurs personnes (ou
applications) d'accéder simultanément aux données tout en conservant l'intégrité de la
base. Chacun doit avoir l'impression qu'il est seul à utiliser les données.
9. Sécurité des données. Les données doivent être protégées des accès non autorisés ou mal
intentionnés. Il doit exister des mécanismes permettant d'autoriser, contrôler et enlever des
droits d'accès à certaines informations pour n'importe quel usager. Par exemple un chef de
service pourra connaître les salaires des personnes qu'il dirige, mais pas de toute
l'entreprise. Le système doit aussi être tolérant aux pannes : si une coupure de courant
survient pendant l'exécution d'une opération sur la base, le SGBD doit être capable de
revenir à un état dans lequel les données sont cohérentes.
Remarque : ces neuf points, bien que caractérisant assez bien ce qu'est une base de données,
ne sont que rarement réunis dans les SGBD actuels. C'est une vue idéale des SGBD.
1.3 Différents types de bases de données
Il existe actuellement 5 grands types de bases de données :
• Les bases hiérarchiques. Ce sont les premiers SGBD apparus (notamment avec IMS
d'IBM). Elles font partie des bases navigationnelles constituées d'une gestion de pointeurs
entre les enregistrements. Le schéma de la base doit être arborescent.
• Les bases réseaux. Sans doute les bases les plus rapides, elles ont très vite supplanté les
bases hiérarchique dans les années 70 (notamment avec IDS II d'IBM). Ce sont aussi des
bases navigationnelles qui gèrent des pointeurs entre les enregistrements. Cette fois-ci le
schéma de la base est beaucoup plus ouvert.
• Les bases relationnelles. A l'heure actuelle les plus utilisées. Les données sont
représentées en tables. Elles sont basées sur l'algèbre relationnelle et un langage déclaratif
(généralement SQL).
• Les bases déductives. Les données sont aussi représentées en tables (prédicats), le
langage d'interrogation se base sur le calcul des prédicats et la logique du premier ordre.
• Les bases objets. Les données sont représentées en tant qu'instances de classes
hiérarchisées. Chaque champ est un objet. De ce fait, chaque donnée est active et possède
ses propres méthodes d'interrogation et d'affectation. L'héritage est utilisé comme
mécanisme de factorisation de la connaissance.
La répartition du parc des SGBD n'est pas équitable entre ces 5 types de bases. 75% sont
relationnelles, 20% réseaux, les 5% restants étant partagés entre les bases déductives et objets.
Ces chiffres risquent néanmoins d'évoluer d'ici quelques années et la frontière entre les bases
relationnelles et objets risque d'être éliminée par l'introduction d'une couche objets sur les
bases relationnelles.
1.4 Quelques systèmes existants
- Oracle (http://www.oracle.com)
- DB2 (IBM, http://www.software.ibm.com)
- Ingres
- Informix
- Sybase (http://www.sybase.com)
- SQL Server (Microsoft, http://www.microsoft.com)
- et sur micros : Access 97 (http://www.microsoft.com), Paradox 8.0 (http://www.corel.com),
Visual Dbase (http://www.borland.com), FoxPro (http://www.microsoft.com), FileMaker 4.0
(http://www.claris.fr), 4D, Windev (http://www.pcsoft.fr)

2. Modélisation conceptuelle
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

3
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.1 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.
Une entité est définie comme un objet pouvant être identifié distinctement. Cet objet peut
représenter des individus (un client), des objets concrets (un livre) ou abstraits (un compte
bancaire) ayant une existence propre ou des évènements (une commande).
Les entités sont décrites par des attributs, caractéristiques ou propriétés.
Parmi tous les attributs de l’entité, on définit un identifiant, qui est un attribut ou un ensemble
d’attributs permettant de déterminer une et une seule entité à l’intérieur de l’ensemble.
L'identifiant est représenté en souligné dans le modèle (ER).
nom de l'entité

liste des propriétés

Représentation d'une entité

Les relations ou associations représentent des liens existant entre les entités. Elles 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 nombre d’entités impliquées dans une relation est appelé dimension ou degré de la
relation. La relation peut être :
• 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 Mariage relie deux éléments
de l’entité type PERSONNE ;
• dimension 2 : c’est le cas le plus fréquent ;
• 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 ê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.
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

Représentation d'une association

4
Des propriétés peuvent être attachées aux associations. Par exemple, 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é".
La description complète d’une relation nécessite la définition précise de la participation des
entités. On appelle cardinalité le nombre de participations d’une entité à une relation.
La cardinalité d'une association est constituée d'une borne minimale et d'une borne maximale :
- minimale : nombre minimum de fois qu'une occurrence d'une entité participe aux
occurrences de l'association, généralement 0 ou 1.
- maximale : nombre maximum de fois qu'une occurrence d'une entité participe aux
occurrences de l'association, généralement 1 ou n.
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és.

Personne Service

1-n travaille dans un 1-n

Volume

Représentation des cardinalités

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é.
Remarque : il existe une notation "à l'américaine" dans laquelle on ne note que les cardinalités
maximum. Dans la figure ci-dessus la notation américaine serait n:m
- un lien hiérarchique est un lien 1:n en notation américaine.
- un lien maillé est un lien n:m en notation américaine.
Ainsi, une relation binaire peut-être de cardinalité 1-1, 1-N ou M-N. Pour les relations
ternaires, les cardinalités possibles sont 1-1-1, 1-1-N, 1-M-N et M-N-P.

2.2 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
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 (weak entity) 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.

5
2.3 Qualité d’une modélisation ER
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.

2.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.
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.

2.5 Les erreurs à ne pas commettre :

a) 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.

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.
6
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.
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
b) 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.

7
 PIECE PIECE

…
prix

Provenance Provenance
prix

FOURNISSEUR FOURNISSEUR

c) 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.
Employé 1 N PROJET
Travaille
1 1

Rattaché_à Géré_par

N
N DEPARTEMENT

d) 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.

e) Confondre le concept de donnée et celui de traitement :

La modélisation conceptuelle de données exclut la représentation des traitements futurs sur
ces données. Toutefois, elle nécessite la connaissance de ces traitements pour prévoir les
données élémentaires indispensables à ceux-ci. En conséquence, il existe une confusion
fréquente entre les concepts de données et les traitements. Ainsi, la facturation est un
traitement qui nécessite de connaître toutes les caractéristiques d’une commande. La
facturation n’est ni une entité ni une relation dans le schéma conceptuel.

8
 COMMANDE CLIENT

numéro_com 1-1 Passe 0-N Code_client

Date_commande Nom
montant Adresse

1-1

FACTURE
Génère
Quantité
Quantité 1-1 Numéro_de_facture
Date_facture

f) 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.

3. Conception logique relationnelle

3.1 Les concepts
Conçu par E.F. Codd au début des années 70, le modèle relationnel allie la simplicité de
représentation des données au moyen de tables à une définition rigoureuse des concepts
fondée sur la théorie mathématique des relations (l'algèbre relationnelle).
Le modèle relationnel s’appuie sur 3 concepts fondamentaux : le domaine, la relation ou table,
et l’attribut.
Un domaine est un ensemble fini ou infini de valeurs possibles. Le domaine des entiers, le
domaine des booléens, le domaine des couleurs primaire (rouge, bleu, jaune) etc...
Un domaine peut être simple ou composé. Il est dit simple si tous ses éléments sont atomiques
ou encore indécomposables. C’est le cas des exemples précédents. Un domaine est dit
composé si ses éléments peuvent être décomposés. Par exemple, les dates sont composées
d’un mois, un jour et une année. Cependant, on peut toujours considérer qu’un domaine n’est
pas décomposable. Ainsi, la date peut aussi être considérée comme un domaine simple.
On appelle relation ou table un sous-ensemble du produit cartésien d’une liste de domaines,
non nécessairement tous distincts. En d’autres termes, une relation est un tableau à deux
dimensions.
Chaque colonne, appelée aussi attribut, contient un sous-ensemble des valeurs d’un domaine.
Un attribut est donc un nom de colonne correspondant à une relation et qui prend ses valeurs
dans un domaine. Deux attributs ne peuvent porter le même nom, même s’ils partagent le
même domaine.
Chaque ligne représente un n_uplet ou t_uple, plus fréquemment appelé tuple, formé d’un
ensemble de n valeurs prises dans les n domaines considérés. Le degré de la relation est le
nombre de colonnes ou de domaines considéré.
On appelle schéma d’une relation le nom de la relation suivi de la liste des attributs et la
définition de leurs domaines. Par exemple, la table Salarié est caractérisée par le schéma
relationnel suivant :

9
SALARIÉ (matricule : entier,
Nom : chaîne de caractères,
Grade : {employé, agent de maîtrise, cadre},
Salaire :[250,1500])
Parfois les domaines sont omis pour ne donner que :
SALARIÉ (matricule, nom, Grade, Salaire)

On appelle schéma relationnel l’ensemble des relations d’une base de données.

A l’ensemble des tables d’un schéma relationnel, on associe généralement un ensemble de
contraintes d’intégrité. Une contrainte d’intégrité est une expression logique qui doit être
vraie, à tout moment, dans une base de données. Par exemple, deux employés ne peuvent
avoir la même matricule. Spécifier les contraintes d’intégrité permet d’en assurer la
vérification systématique par le SGBD et ainsi de contrôler la cohérence des données.
Il existe plusieurs types de contraintes d’intégrité (définition de domaine, contrainte de clé, la
contrainte obligatoire2, contrainte d’intégrité référentielle, etc.).
On peut ainsi définir de façon complète le schéma d’une relation comme le nom de la relation
suivi de la liste des attributs, de la définition de leurs domaines et de l’ensemble des
contraintes d’intégrité associées à cette table.

3.2 La démarche de transformation d’un modèle ER en un schéma relationnel

Décrivons maintenant les règles principales de transformation d’un schéma conceptuel entité-
relation en un schéma relationnel :
Règle 1. Toute entité est traduite en une table relationnelle dont les caractéristiques sont les
suivantes :
• le nom de la table est le nom de l’entité ;
• la clé de la table est l’identifiant de l’entité ;
• les autres attributs de l’entité forment les autres colonnes de la table.

Règle 2. Toute relation binaire M-N est traduite en une table relationnelle dont les
caractéristiques sont les suivantes :
• le nom de la table est le nom de la relation ;
• la clé de la table est formée par la concaténation des identifiants des entités participant
à la relation ;
• les attributs spécifiques de la relation forment les autres colonnes de la table.
Une contrainte d’intégrité référentielle est générée entre chaque colonne clé de la nouvelle
table et la table d’origine de cette clé.

Règle 3. Toute relation binaire 1-N est traduite :

• soit par un report de clé : l’identifiant de l’entité participant à la relation côté N est
ajouté comme colonne supplémentaire à la table représentant l’autre entité. Cette
colonne est appelée clé étrangère. Le cas échéant, les attributs spécifiques à la relation
sont eux aussi ajoutés à la même table ;
• soit par une table dont les caractéristiques sont les suivantes :
- le nom de la table est le nom de la relation ;
- la clé de la table est l’identifiant de l’entité participant à la relation côté 1;
- la clé de la table côté N et les attributs spécifiques de la relation forment les
autres colonnes de la table.
De plus, une contrainte d’intégrité référentielle est générée.
Le choix du mode de traduction (report de clé ou table spécifique) peut être dicté par des
considérations liées aux traitements futurs sur la base. Même si l’on ne dispose pas
nécessairement d’une spécification détaillée de ces traitements, on peut partiellement les
anticiper par l’analyse plus approfondie de cette relation.

2
qui précise qu’un attribut doit toujours avoir une valeur
10
Un élément d’appréciation de ces traitements est la cardinalité minimale de l’entité côté 1. Si
cette cardinalité minimale est égale à 1, il est préférable d’opter pour le report de clé, dont
l’avantage est de minimiser le nombre de tables. A noter que l’effet de cette minimisation
n’est pas tant d’économiser l’espace disque que d’améliorer les performances de la base en
réduisant le nombre de jointures entre tables.
Si la cardinalité minimale est égale à 0, on examinera la proportion d’entités participant
effectivement à la relation. Si cette proportion est importante, on peut en déduire que la
relation l’est aussi et opter encore pour le report de clé. En revanche, si cette proportion est
relativement faible, il est préférable d’opter pour la table spécifique, dans la mesure où l’on
peut penser que cette faible proportion exprime une importance relative dans l’application.

Règle 4. Toute relation binaire 1-1 est traduite, au choix, par l’une des 3 solutions suivantes :
• fusion des tables des entités qu’elle relie (choix 1) ;
• report de clé d’une table dans l’autre (choix 2) ;
• création d’une table spécifique reliant les clés des 2 entités (choix 3).
Les attributs spécifiques de cette relation sont ajoutés à la table résultant de la fusion
(choix 1), reportés avec la clé (choix 2), ou insérés dans la table spécifique (choix 3). Dans le
cas de la fusion (choix 1) comme dans celui de la table spécifique (choix 3), les 2 clés des
entités participant à la relation sont toutes deux clés candidates pour la table résultante. De
plus, deux contraintes d’intégrité référentielle sont générées.
Comme dans la règle précédente, le choix du mode de traduction dépend des cardinalités
minimales. Trois cas sont alors possibles :
• les deux cardinalités minimales sont égales à 1 : la relation forme une bijection entre les
2 ensembles d’entités. Alors, la meilleure traduction est la fusion (choix 1) ;
• l’une des deux est égale à 0, l’autre est 1 : l’une des 2 entités a toujours une entité
correspondante dans l’autre ensemble. Alors, la meilleure traduction est le report de clé
de l’entité dont la participation minimale est 0 dans la table représentant l’autre entité ;
• les 2 cardinalités minimales sont égales à 0. Il est recommandé d’examiner la proportion
d’entités participant effectivement à la relation. Si cette proportion est importante pour
les 2 entités, on optera pour la fusion (choix 1). En revanche, si cette proportion est
importante pour l’une des entités, mais secondaire pour l’autre, il est préférable d’opter
pour un report de clé (choix 2). Enfin, si cette proportion est faible pour les deux entités,
la table spécifique est la traduction la plus appropriée (choix 3).
Règle 5. Toute relation ternaire ou plus est traduite par une table spécifique. Sauf cas
particulier, la clé de cette table est constituée par la concaténation des identifiants des
entités de cette table. Pour chaque identifiant, une contrainte d’intégrité référentielle est
générée.

Règle 6. Toute généralisation de E de n entités E1, E2,… En peut être traduite au choix par
l’une des trois solutions suivantes :
• la création d’une seule table représentant l’entité générique E et intégrant tous les
attributs des entités spécifiques. Les relations éventuelles impliquant ces entités sont
alors considérées comme impliquant l’entité E avec une cardinalité minimale nulle. La
spécialisation est traduite par l’introduction d’un attribut supplémentaire dont
l’ensemble des valeurs possibles sera l’ensemble des noms des entités spécifiques ;
• la création de n tables représentant les entités E1, E2, …En qui héritent de l’ensemble
des attributs et des relations de l’entité générique E ;
• la création conjointe des tables E, E1, E2,… En. On peut considérer que l’entité
générique et ses spécifiques sont reliées par des relations 1-1. On est alors ramené à la
règle 4 pour les différentes traductions de ces relations.
Le choix entre ces trois solutions est dicté par la nature des traitements les plus courants. Si
ces derniers portent essentiellement sur les attributs spécifiques indépendamment des attributs
de l’entité générique, on préférera alors la solution 2. Si, au contraire, la plupart des
traitements opèrent conjointement sur tous les attributs, qu’ils soient au niveau générique ou

11
au niveau spécifique, la solution 1 est préférable. La solution 3 est la seule qui préserve toute
la sémantique. Cependant, elle est, la plupart du temps, trop complexe pour être
recommandée.

Règle 7. Toute relation réflexive est considérée comme une relation binaire. Sa traduction
dépend donc du type de cette relation binaire (1-1, 1-N ou M-N) et obéit à l’une des règles 2,3
ou 4.
Si, à la fin du processus de traduction de l’ensemble du schéma ER, on obtient des tables ne
comportant qu’une seule colonne, on ne représentera pas ces tables qui ne sont pas porteuses
d’information spécifique. Un schéma conceptuel, correct et correctement traduit selon les
règles ci-dessus, produit dans la plupart des cas un schéma relationnel en troisième forme
normale. C’est pourquoi on pourrait se contenter de vérifier le schéma relationnel obtenu en
utilisant la notion de dépendance fonctionnelle.

3.3 Exemple d’une base de données relationnelle

A titre d'exemple, considérons le cas d'un MCD rudimentaire, utilisant 2 entités Fournisseurs
et Produits et une association Commandes.
Fournisseurs Produits

numFrs numProd
nom 1-n Commandes 1-n design
adresse numCde, qté prix
ville poids
couleur
MCD Fournisseurs-Produits-Commandes

L'association commandes est un lien maillé porteur d'une propriété. Il y a donc création d'une
table commandes avec report des clés des entités liées, ce qui nous donne bien un MLD,
utilisant 3 tables représentant les commandes de produits à des fournisseurs.
Le schéma de cette base3 est donc :

3
Cet exemple sera utilisé par la suite pour illustrer l'écriture de requêtes.
12
produits(numProd, design, prix, poids, couleur)
fournisseurs(numFrs, nom, ville)
commandes(numCde, numFrs#, numProd#, qté)

Produits numProd design prix poids couleur

101 fauteuil 2000 7 gris
102 fauteuil 1500 9 rouge
103 bureau 3500 30 vert
104 bureau 4000 40 gris
105 armoire 2500 35 rouge
106 caisson 1000 12 gris
107 caisson 1000 12 jaune
108 classeur 1500 20 bleu

Fournisseurs numFrs nom ville

10 Ahmed Tunis
11 Bouaker Nefza
12 Karim Sfax
13 Mourad Sfax
14 Talel Beja
15 Mohamed Tunis
16 Samir Jendouba
17 Omar Tunis
19 Bechir Kairouan

Commandes numCde numFrs numProd qte

1001 17 103 10
1003 15 103 2
1005 17 102 1
1007 15 108 1
1011 19 107 12
1013 13 107 5
1017 19 105 3
1019 14 103 10
1023 10 102 8
1029 17 108 15

13