1

ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

INSTITUT SUPERIEUR PEDAGOGIQUE DE BUNIA

B.P. 340 BUNIA

SECRETARIAT GENERAL ACADEMIQUE

ispbunia2006@[Link]

SECTION: SCIENCES EXACTES

DEPARTEMENT: MATHEMATIQUE-PHYSIQUE

CONTRAT PEDAGOGIQUE: BASE DE DONNEES

ANNEE ACADEMIQUE : 2023-2024

I. Introduction
« Base de données » est un élément constitutif de l’unité d’enseignement
Modélisation de données et base de données proposée en deuxième année de licence
Informatique Technologie (L2IT).
Il constitue une introduction indispensable à la conception d’une base de
données informatisée.
II. Prérequis
Les prérequis pour cet élément constitutif sont: UE Informatique et Bureautique
(partie Excel) et l’élément constitutif modélisation de données.

III. Informations générales

 Langue d’enseignement : Français.
 Nombre de crédits : 3.
 Théories : 1crédit
 2

IV. Compétences ciblées

L’étudiant ayant suivi ce cours sera capable concevoir une base de données
informatisée.

V. Résultats d’apprentissage attendus

Les résultats d’apprentissage attendus sont présentés dans le tableau suivant :

Résultat d’Apprentissage Chapitres Moyens pédagogiques

Attendu mis en œuvre

INTRODUCTION AUX Chapitre I Cours Interactif

BASES DE DONNEES PowerPoint.
Supports de cours
Travaux Dirigés

CONCEPTION DE BASES Chapitre II Cours Interactif PowerPoint.

DE DONNEES Support de cours
Exposés des étudiants
Travaux Dirigés

BASES DE DONNEES Chapitre III Cours Interactif PowerPoint.

RELATIONNELLES Support de cours
Exposés des étudiants

LANGAGE SQL Chapitre Iv Cours Interactif PowerPoint.

Support de cours
Exposés des étudiants

VI. Modalités d’évaluation des apprentissages

L’évaluation de ce cours comporte quatre éléments:
a. Examen.
Cet examen final, compte 48% de la note finale, permet d’évaluer la capacité
de l’étudiant à :
 Décrire les notions de base de données
 Analyser les données
 3

 Concevoir une base de données

b. TD ET TP
Ces travaux comptent 30% de la note finale

c. Présence
La présence compte 10% de la note finale, permet d’évaluer la participation de
l’étudiant à l’UE.
d. Note non présentielle.
Cette note, qui compte 10% de la note finale, permet d’évaluer la capacité de l’étudiant
à synthétiser la note.

VII. Contact
 Nom de l’enseignant : SELYA KIYENGO Philippe-Martin
 Grade statutaire : Assistant du premier mandat
 Téléphone : +243816364843
 E-mail :selyakng@[Link]
 Disponibilité : IDAP/ISP-BUNIA

VIII. Bibliographie
 CORONEL, C., MORRIS S. et ROB P. (2012). Database Systems: Design,
Implementation, and Management, Cengage Learning.
 MARTIN, D. (1981), Bases de données : méthodes pratiques sur maxi et mini-
ordinateurs. Paris, Dunod.
 Delphi; Hamani, Berti. (2010). Les bases de données sous Access. Paris.
 Gardarin, G., Eyrolles. (20013). Base de données réparties. Paris.
 Boursier, P. (2022). Cours Bases de Données – UPF. Paris
 Gill, P.S. (2008). Database Management Systems, I. K. International Pvt Ltd
 Philippe, M. (2016).Les bases de données à l’Internet. Paris.
 4

Chapitre 1. Introduction aux bases de données

Objectifs :

Au terme de ce chapitre, le participant doit décrire :

a. Les notions de base de données

b. Le système de gestion de base de données
1.1. Historique

Dès les débuts de l’informatique, l’un des soucis majeurs de l’utilisateur fut de
pouvoir stocker massivement des données et de pouvoir en disposer régulièrement afin
d’en extraire de nouvelles informations, de les consulter et de les modifier.
De 1950 à 1960, seul existait le fichier pour satisfaire à cette demande. Les
applications devaient donc être complétées par une programmation qui se faisait souvent
en langage machine (assembleur). RCA (Radio Corporation of America) proposa une
machine spécialisée pour répondre à ce besoin, le BIZMAC, commercialisé en 1958.
Au début des années 60, l’arrivée de COBOL (COmmon Business Oriented
Language) permit de créer des structures de données hiérarchisées. C’est à ce moment
que le concept de base de données prit son essor et qu’apparurent les premiers systèmes
de gestion de bases de données. Comme ils fonctionnaient en relation étroite avec
COBOL, le modèle de représentation des données était calqué sur les structures de
données de COBOL. Les bases de données hiérarchiques étaient nées.
L’un des premiers systèmes de gestion de bases de données hiérarchiques
commercialisés fut IMS (Information Management System) d’IBM, puis DL1 et Système
2000. Grâce aux langages plus modernes, permettant de manipuler les données de
manière plus dynamique, avec, notamment, des pointeurs d’adresse, les informaticiens
mirent au point les bases de données dites "en réseau". Ce terme indique plus
précisément un modèle de données organisées en mailles, c’est-à-dire de structures de
données représentées par des noeuds rejoints par des arcs orientés. Le terme "réseau",
assez impropre aujourd’hui, aurait dû être remplacé par graphe, mais on ne refait pas
l’histoire...
 5

Ce modèle est issu des travaux du CODASYL (Conference On DAta SYstem and
Language) qui débutèrent en 1968. Les systèmes commercialisés furent IDMS
(Integrated Data Management System) d’IBM, IDS (Integrated Data Store) d’Honeywell,
DBMS 10 de DEC ou encore SOCRATE de CII-Bull.
La quatrième évolution est née des remarquables travaux mathématiques d’un
chercheur de la société IBM : Edgar F. CODD. Celui-ci partit du principe que l’on pouvait
établir entre les données des relations logiques de type "équivalence", "négation",
"infériorité" et même des opérations comme la "jointure". Ce modèle théorique, dit
"modèle relationnel", fit l’objet d’une communication en juin 1970 dans le journal ACM et
dans le cadre du projet System/R. Les premières réalisations de systèmes de gestion de
bases de données relationnels quant à elles ne furent entreprises qu’en 1974, à titre
expérimental (XRM d’IBM), et dotées d’un langage d’interrogation des données épousant
les concepts de la théorie relationnelle (SEQUEL,Structured English QUEry Language —
Dr Donald Chamberlin).
L’avantage de cette conception est la simplicité : les données stockées sont
organisées en tables (tableaux dont les colonnes sont hétérogènes et les lignes en accès
direct grâce à un index ou "clef"). Cette organisation logique des données permet de
s’affranchir d’une grande partie des problèmes physiques liés au stockage.

Toute l’attention se reportait alors sur l’étude du langage d’interrogation de la

base de données. SEQUEL devint, dans une seconde version améliorée, SEQUEL 2 et
fut annoncé par IBM sous le nom commercial de Sytem R. Le nom SEQUEL donné à
l’origine au langage d’interrogation fut en partie conservé, mais transformé en SQL
(Structured Query Langage) en 1976 parce que l’acronyme SEQUEL constituait déjà une
marque.

System R, premier système de gestion de bases de données relationnel, introduit à titre

expérimental chez certains clients d’IBM, permit d’affiner le langage d’interrogation des données
et aboutit au produit SQL/DS.
Hélas, IBM arrivait un peu tard, car déjà, une petite société du nom de "Relationnel
Software Inc" avait doublé "big blue" en commercialisant un SGBDR doté du langage
d’interrogation SQL. En l’occurrence il s’agissait du produit ORACLE. Finalement le SGBDR
 6

d’IBM sortit en 1981 et une version différente, mais néanmoins prétendument compatible, vit le
jour en 1983 avec, comme nom de code, DB2.
En parallèle, des universitaires de Californie, Michael STONEBRAKER et Eugene
WONG, commencèrent à réaliser à titre expérimental un nouveau prototype au sein de la
prestigieuse Berkeley University. Leur projet, adoptant des concepts un peu différents, fut baptisé
Ingres et le langage d’accès QUEL. Avec quelques autres professeurs, ils formèrent alors une
société Relational Technology Inc. et annoncèrent, en 1981, la première version commerciale de
leur SGBDR.
Une kyrielle de produits SQL firent ensuite leur apparition : DG/SQL (1984), SYBASE
(1986), INFORMIX, RDB, UNIFY, etc.
Lors de l’avènement du micro-ordinateur, différents éditeurs se penchèrent de nouveau
sur le problème des bases de données. IBM prit le parti de ne pas s’en mêler, jugeant qu’une
base de données implantée sur un micro-ordinateur ne présentait pas d’intérêt (systèmes
individuels, faibles capacités de stockage...).
Mais des éditeurs plus novateurs se regroupèrent afin de mettre au point un assemblage
de formats de fichiers capable de répondre facilement à une structuration des données sous
forme de "tables". A cette occasion, ils créèrent le modèle XBase basé sur des fichiers ISAM
(Indexed Sequential Access Method, fichier séquentiel à accès indexé). Selon ce modèle, chaque
table est un fichier et des fichiers annexes viennent enrichir la structure de la table et des
contraintes.
Dès lors, des produits spécifiques commencèrent à voir le jour. Le premier fut
dBase d’Ashton Tate qui connut un succès immédiat. Mais dBase essuya les plâtres et
fut sévèrement concurrencé par des SGBD plus modernes comme RBase de Microrim,
Paradox d’Ansa, racheté très tôt par Borland, puis Corel, ou encore FoxBase (dénommé
ensuite FoxPro), etc.
L’arrivée de l’interface graphique Windows de Microsoft conduisit les éditeurs à
un double mouvement : adapter à cette nouvelle interface les produits en mode caractère
existant (ce fut le cas de Paradox de Borland puis de dBase et, finalement, de Fox-Pro)
ou créer des SGBD dédiés Windows (en particulier ACCESS de Microsoft ou APPROCH
de Lotus).
Le dernier né de ce type de SGBD est MySQL, produit "libre" à faible intégrité,
destiné à des volumes de données moyen et particulièrement adapté à la création de
sites Web dynamiques à base de documents accessibles en lecture.
 7

D’autres langages d’interrogation ont vu le jour. Pour n’en citer qu’un, notons
QBE, système mis au point concurremment à SQL, mais qui n’a connu de succès que
grâce à l’introduction de Paradox.
QBE (Query By Example, interrogation par l’exemple) a été inventé par Moshe
Zloof (IBM 1977) et mis en place dès la première version de Paradox (1.0 pour DOS), en
1985, par ANSA Software, l’éditeur de Paradox.
Pour interroger une table avec ce système, il suffit de proposer une image de la
réponse (un "squelette" de table) et, par un mécanisme d’analogie, QBE va rechercher
les occurrences dans les tables qui correspondent aux différents critères établis.
Cependant, vous entendez parler de QBE bien souvent à tort... En effet, la plupart des
éditeurs de SGBD et certains produits d’extraction de données proposent une interface
graphique permettant de construire visuellement des requêtes SQL et s’intitulent
pompeusement QBE, alors que le langage inventé par Zloof n’y est nullement présent !
1.2. Notions de base de données
1.2.1. Base de données

Il est difficile de donner une définition exacte de la base de données. Une

définition très générale pourrait être : un ensemble organisé d’informations avec un
objectif commun. Peu importe le support utilisé pour rassembler et stocker les données
(papier, fichiers etc.), dès lors que des données sont rassemblées et stockées d’une
manière organisée dans un but spécifique, on parle de base de données.

Plus précisément, on appelle base de données un ensemble structuré et organisé

permettant le stockage de grandes quantités d’informations afin de faciliter l’exploitation
(ajout, mise à jour, recherche de données). Dans le cadre de ce cours nous nous
intéresserons aux bases de données informatisées.

1.2.2. Base de données informatisée

Une base de données informatisée par définition est un ensemble structuré de

données enregistrées sur des supports accessibles par l’ordinateur, représentant des
informations du monde réel et pouvant être interrogées et mises à jour par une
communauté d’utilisateur.
 8

Le résultat de la conception d’une base de données informatisée est une

description des données. Par description on entend définir les propriétés d’ensembles
d’objets modélisés dans la base de données et non pas d’objets particuliers. Les objets
particuliers sont créés par des programmes d’applications ou des langages de
manipulation lors des insertions et des mises à jour des données.

Cette description des données est réalisée en utilisant un modèle de données.

Ce dernier est un outil formel utilisé pour comprendre l’organisation logique des données.

La gestion et l’accès à une base de données sont assurés par un ensemble de

programmes qui constituent le Système de Gestion de Base de données. Un SGBD est
caractérisé par le modèle de description des données qu’il supporte (hiérarchique,
réseau, relationnel, objet). Les données sont décrites sous la forme de ce modèle, grâce
à un Langage de Description des Données (LDD). Cette description est appelée schéma.

Une fois la base de données spécifiée, on peut y insérer des données, les
récupérer, les modifier et les détruire. C’est qu’on appelle manipuler les données. Les
données peuvent être manipulées non seulement par un Langage spécifique de
Manipulation des Données mais aussi par des langages de programmation classiques.

1.3. Modèle de la base de données

1.3.1. Modèle hiérarchique

Une base de données hiérarchique est une forme de système de gestion base
de données qui lie des enregistrements dans une structure arborescente de façon à ce
que chaque enregistrement n’ait qu’un seul possesseur (par exemple une paire de
chaussure n’appartient qu’à une seule personne).

Les structures de données hiérarchiques ont été largement utilisées dans les
premiers systèmes de gestion de base de données conçus pour la gestion des données
du programme Apollo de la NAZA. Cependant, à cause de leurs limitations internes, elles
ne peuvent pas souvent être utilisées pour décrire des structures existantes dans le
monde réel.
 9

Les liens hiérarchiques entre les différents types de données peuvent rendre très
simple certaines questions, mais très difficile la réponse à d’autres formes de questions.
Si le principe de relation « 1 vers N » n’est pas respecté (par exemple, un malade peut
avoir plusieurs médecins et un médecin a, a priori, plusieurs patients), alors la hiérarchie
se transforme en un réseau.

1.3.2. Modèle réseau

Le modèle réseau est en mesure de lever de nombreuses difficultés du modèle

hiérarchique grâce à la possibilité d’établir les liaisons n-n, les liens entre objets pouvant
exister sans restriction. Pour retrouver une donnée dans une telle modélisation, il faut
connaître le chemin d’accès (les liens) ce qui rend les programmes dépendants de la
structure de données.

Ce modèle de bases de données a été inventé par C.W. Bachman. Pour son
modèle, il reçut en 1973 le prix Turing.

1.3.3. Modèle relationnel

Une base de données relationnelle est une base de données structurée suivant
les principes de l’algèbre relationnelle.

Le père des bases de données relationnelles est Edgar Frank Codd. Chercheur
chez IBM à la fin des années 1960, il étudiait alors de nouvelles méthodes pour gérer de
grandes quantités de données car les modèles et les logiciels de l’époque ne le
satisfaisaient pas. Mathématicien de formation, il était persuadé qu’il pourrait utiliser des
branches spécifiques des mathématiques (la théorie des ensembles et la logique des
prédicats du premier ordre) pour résoudre des difficultés telles que la redondance des
données, l’intégrité des données ou l’indépendance de la structure de la base de données
avec sa mise en œuvre physique.

En 1970, Codd (1970) publia un article où il proposait de stocker des données

hétérogènes dans des tables, permettant d’établir des relations entre elles. De nos jours,
ce modèle est extrêmement répandu, mais en 1970, cette idée était considérée comme
 10

une curiosité intellectuelle. On doutait que les tables puissent être jamais gérées de
manière efficace par un ordinateur.

Ce scepticisme n’a cependant pas empêché Codd de poursuivre ses recherches.

Un premier prototype de Système de gestion de base de données relationnelle (SGBDR)
a été construit dans les laboratoires d’IBM. Depuis les années 80, cette technologie a
mûri et a été adoptée par l’industrie. En 1987, le langage SQL, qui étend l’algèbre
relationnelle, a été standardisé. C’est dans ce type de modèle que se situe ce cours de
base de données.

1.3.4. Modèle objet

La notion de bases de données objet ou relationnel-objet est plus récente et

encore en phase de recherche et de développement. Elle sera très probablement ajoutée
au modèle relationnel.

1.4. Système de Gestion de Base de Données (SGBD)

1. Introduction
1.1. Définition d'un SGBD

Un système de gestion de base de données (SGBD) est un logiciel qui permet

de : décrire, modifier, interroger et administrer les données d'une base de données.

1.2. Structure d'un SGBD

Un SGBD est constitué de deux composantes principales :

1.2.1. Le moteur
1.2.2. L'interface
1.3. Les fonctions d'un SGBD
1.3.1. La définition des données

Le SGBD nous permet de créer et de décrire les objets de la base de données

(table, liens, utilisateur…), grâce au Langage de Description des Données (LDD).
Exemple : La commande CREATE TABLE nom_table ( ).
1.3.2. La manipulation des données
La manipulation des données peut être :
 11

- La recherche
- La lecture
- La suppression
- La modification
- L'ajout
Le SGBD nous offre un Langage de Manipulation des Données (LMD) à fin de
pouvoir réaliser ces opérations.
Exemple : La commande INSERT INTO nom_table( ).

1.3.3. L'intégrité des données

C'est l'ensemble des opérations de contrôle que le SGBD effectue pour préserver
la cohérence des données.
Exemple : Vérification de la validité de la valeur d'un champ.

1.3.4. La gestion des accès concurrents

Le SGBD gère l'accès simultané des utilisateurs à la base de données.

1.3.5. La confidentialité

Tous les utilisateurs d'une base de données ne sont pas supposés pouvoir
consulter toutes les informations. Des sous schémas de la base permettent de résoudre
ce problème en plus des mots de passes et droits d'accès.

1.3.6. La sécurité de fonctionnement

• Faire une copie de sauvegarde de la base.

• Remise en marche de la base en cas de panne.
2. Les principaux SGBD
• ORACLE
• Microsoft SQL SERVER
• MySQL
• Microsoft ACCESS
 12

3. Cycles de développement des bases de données

Niveau externe : Analyse de l'existant.
Niveau conception : Modélisation des entités du monde réel.
Niveau interne : Création de la base de données.
4. Intervenants du domaine BD
• Les utilisateurs
• Concepteurs
• Administrateur base de données (DBA)
• Développeur d'application base de données
5. Principes de fonctionnement
La gestion et l’accès à une base de données sont assurés par un ensemble de
programmes qui constituent le Système de gestion de base de données (SGBD). Un
SGBD doit permettre l’ajout, la modification et la recherche de données. Un système de
gestion de bases de données héberge généralement plusieurs bases de données, qui
sont destinées à des logiciels ou des thématiques différentes.

Actuellement, la plupart des SGBD fonctionnent selon un mode client/serveur. Le

serveur (sous-entendu la machine qui stocke les données) reçoit des requêtes de
plusieurs clients et ceci de manière concurrente. Le serveur analyse la requête, la traite
et retourne le résultat au client. Le modèle client/serveur est assez souvent implémenté
au moyen de l’interface des sockets (voir le cours de réseau en G3).

Une variante de ce modèle est le modèle ASP (Application Service Provider).

Dans ce modèle, le client s’adresse à un mandataire (broker) qui le met en relation avec
un SGBD capable de résoudre la requête. La requête est ensuite directement envoyée
au SGBD sélectionné qui résout et retourne le résultat directement au client.

Quel que soit le modèle, un des problèmes fondamentaux à prendre en compte

est la cohérence des données. Par exemple, dans un environnement où plusieurs
utilisateurs peuvent accéder concurremment à une colonne d’une table par exemple pour
la lire pour l’écrire, il faut s’accorder sur la politique d’écriture. Cette politique peut être :
les lectures concurrentes sont autorisées mais dès qu’il y a une écriture dans une
 13

colonne, l’ensemble de la colonne est envoyée aux autres utilisateurs l’ayant lue pour
qu’elle soit rafraîchie.

5.1.1. Objectifs

Des objectifs principaux ont été fixés aux SGBD dès l’origine de ceux-ci et ce,
afin de résoudre les problèmes causés par la démarche classique. Ces objectifs sont les
suivants :

- Indépendance physique : La façon dont les données sont définies doit être
indépendante des structures de stockage utilisées.
- Indépendance logique : Un même ensemble de données peut être vu
différemment par des utilisateurs différents. Toutes ces visions personnelles des
données doivent être intégrées dans une vision globale.
- Accès aux données : L’accès aux données se fait par l’intermédiaire d’un langage
de Manipulation de Données (LMD). Il est crucial que ce langage permette
d’obtenir des réponses aux requêtes en un temps « raisonnable ». Le LMD doit
donc être optimisé, minimisé le nombre d’accès disques, et tout cela de façon
totalement transparente pour l’utilisateur.
- Administration centralisée des données (intégration) : Toutes les données
doivent être centralisées dans un réservoir unique commun à toutes les
applications. En effet, des visions différentes des données (entre autres) se
résolvent plus facilement si les données sont administrées de façon centralisée.
- Non redondance des données : Afin d’éviter les problèmes lors des mises à jour,
chaque donnée ne doit être présente qu’une seule fois dans la base.
- Cohérence des données : Les données sont soumises à un certain nombre de
contraintes d’intégrité qui définissent un état cohérent de la base. Elles doivent
pouvoir être exprimées simplement et vérifiées automatiquement à chaque
insertion, modification ou suppression des données. Les contraintes d’intégrité
sont décrites dans le Langage de Description de Données (LDD).
- Partage des données : Il s’agit de permettre à plusieurs utilisateurs d’accéder
aux mêmes données au même moment de manière transparente. Si ce problème
est simple à résoudre quand il s’agit uniquement d’interrogations, cela ne l’est plus
 14

quand il s’agit de modifications dans un contexte multi-utilisateurs car il faut :

permettre à deux (ou plus) utilisateurs de modifier la même donnée « en même
temps » et assurer un résultat d’interrogation cohérent pour un utilisateur
consultant une table pendant qu’un autre la modifie.
- Sécurité des données : Les données doivent pouvoir être protégées contre les
accès non autorisées. Pour cela, il faut pouvoir associer à chaque utilisateur des
droits d’accès aux données.
- Résistance aux pannes : Après une panne intervenant au milieu d’une
modification deux solutions sont possibles : soit récupérer les données dans l’état
dans lequel elles étaient avant la modification, soit terminé l’opération interrompue.
5.1.2. Niveaux de description des données ANSI/SPARC

Pour atteindre certains de ces objectifs (surtout les deux premiers), trois niveaux
de description des données ont été définis par la norme ANSI/SPARC.

- Le niveau externe : correspond à la perception de tout ou partie de la base par

un groupe donné d’utilisateurs, indépendamment des autres. On appelle cette
description schéma externe ou vue. Il peut exister plusieurs schémas externes
représentant différentes vues sur la base de données avec des possibilités de
recouvrement. Le niveau externe assure l’analyse et l’interprétation des requêtes
en primitives de plus bas niveau et se charge également de convertir
éventuellement les données brutes, issues de la réponse à la requête, dans un
format souhaité par l’utilisateur.
- Le niveau conceptuel : décrit la structure de toutes les données de la base, leurs
propriétés, sans se soucier de l’implémentation physique ni de la façon dont
chaque groupe de travail voudra s’en servir. Dans le cas des SGBD relationnels,
il s’agit d’une vision tabulaire où la sémantique de l’information est exprimée en
utilisant les concepts de relation, attributs et de contraintes d’intégrité. On appelle
cette description le schéma conceptuel.
- Le niveau interne ou physique : s’appuie sur un système de gestion de fichiers
pour définir la politique de stockage ainsi que le placement des données. Le niveau
physique est donc responsable du choix de l’organisation physique des fichiers
 15

ainsi que de l’utilisation de telle ou telle méthode d’accès en fonction de la requête.

On appelle cette description le schéma interne.
 16

Chapitre 2. Conception des bases de données : le modèle entités-associations

Objectif :

Au terme de ce chapitre, le participant doit décrire les modèles entités-associations

2.1. Introduction

2.1.1. Pourquoi une modélisation préalable ?

Il est difficile de modéliser un domaine sous une forme directement utilisable par
un SGBD. Une ou plusieurs modélisations intermédiaires sont donc utiles, le modèle
entités-associations constitue l’une des premières et des plus courantes. Ce modèle,
présenté par Chen (1976), permet une description naturelle du monde réel à partir des
concepts d’entité et d’association. Basé sur la théorie des ensembles et des relations, ce
modèle se veut universel et répond à l’objectif d’indépendance données-programmes. Ce
modèle, utilisé pour la phase de conception, s’inscrit notamment dans le cadre d’une
méthode plus générale et très répandue : Merise.

2.1.2. Merise

Merise (Méthode d’Etude et de Réalisation Informatique pour les Systèmes

d’Entreprise) est certainement le langage de spécification le plus répandu dans la
communauté de l’informatique des systèmes d’information, et plus particulièrement dans
le domaine des bases de données. Une représentation Merise permet de valider des
choix par rapport aux objectifs, de quantifier les solutions retenues, de mettre en œuvre
des techniques d’optimisation et enfin de guider jusqu’à l’implémentation. Reconnu
comme standard, Merise devient outil de communication. En effet, Merise réussit le
compromis difficile entre le souci d’une modélisation précise et formelle, et la capacité
d’offrir un outil et un moyen de communication accessible aux non-informaticiens.

Un des concepts clés de la méthode Merise est la séparation des données et des
traitements. Cette méthode est donc parfaitement adaptée à la modélisation des
problèmes abordés d’un point de vue fonctionnel. Les données représentent la statique
du système d’information et le traitement sa dynamique. L’expression conceptuelle des
 17

données conduit à une modélisation des données entités et associations. Dans ce cours,
nous écartons volontairement la modélisation des traitements puisque nous ne nous
intéressons à la méthode Merise que dans la perspective de la modélisation de base de
données.

Merise propose une démarche, dite par niveaux, dans laquelle il s’agit de
hiérarchiser les préoccupations de modélisation qui sont de trois ordres : la conception,
l’organisation et la technique. En effet, pour aborder la modélisation d’un système, il
convient de l’analyser en premier lieu de façon globale et se concentrer sur sa fonction :
c’est-à-dire de s’interroger sur ce qu’il fait avant de définir comment il le fait. Ces niveaux
de modélisation sont organisés dans une double approche données/traitements. Les trois
niveaux de représentation des données, puisque ce sont eux qui nous intéressent, sont
détaillés ci-dessous :

- Niveau conceptuel : le modèle conceptuel des données (MCD) décrit les entités
du monde réel, en terme d’objet, de propriétés et de relations, indépendamment
de toute technique d’organisation et d’implantation des données. Ce modèle se
concrétise par un schéma entité-associations représentant la structure du système
d’information, du point de vue des données.
- Niveau logique : le modèle logique des données (MLD) précise le modèle
conceptuel par des choix organisationnels. Il s’agit d’une transcription (également
appelée dérivation) du MCD dans un formalisme adapté à une implémentation
ultérieure, au niveau physique, sous forme de base de données relationnelle ou
réseau, ou autres.
- Niveau physique : le modèle physique des données (MPD) permet d’établir la
manière concrète dont le système sera mise en place (SGBD retenu). C’est à ce
niveau que les choix techniques d’implémentation seront effectués.
 18

2.1.3. Eléments constitutifs du modèle entités-associations

La représentation du modèle entités-associations s’appuie sur trois concepts de

base :

- Entité ;
- Association ;
- Propriété.
a) Entité

Une entité est un objet, une chose concrète ou abstraite qui peut être reconnue
distinctement et qui est caractérisé par son unicité.

Un type-entité désigne un ensemble d’entité qui possèdent une sémantique et

des propriétés communes.

Les personnes, les livres et les voitures sont des exemples de type-entité. En
effet, dans le cas d’une personne par exemple, les informations associées sont appelées
propriétés, comme nom et le prénom, ne changent pas de nature.

b) Attribut ou propriété

Un attribut ou propriété est une caractéristique associée à un type-entité ou à un

type-association.

Quelques règles importantes:

- Un attribut ne peut en aucun cas être partagé par plusieurs types-entités ;

- Un attribut est une donnée élémentaire, ce qui exclut des données calculées ou
dérivées ;
 19

- Un type-entité et ses attributs doivent être cohérents entre eux (ne traiter que d’un
seul sujet).

Par exemple, si le modèle doit comporter des informations relatives à des articles et à
leur fournisseur, ces informations ne doivent pas coexister au sein d’un même type-entité.
Il est préférable de mettre les informations relatives aux articles dans un type-entité Article
et les informations relatives aux fournisseurs dans un type-entité Fournisseur. Ces deux
type-entités seront probablement ensuite reliés par un type-association.

c) Identifiant ou clé

Un identifiant (ou clé) d’un type-entité ou d’un type-association est constitué par
un ou plusieurs de ses attributs qui doivent avoir une valeur unique pour chaque entité
ou association de ce type.

Il est donc impossible que les attributs constituant l’identifiant d’un type-entité
(respectivement type-association) prennent la même valeur pour deux entités
(respectivement deux association) distinctes. Exemple d’identifiant : numéro de sécurité
sociale pour une personne, le numéro d’immatriculation pour une voiture, le code ISBN
d’un livre pour un livre (mais pas pour un exemplaire).

Deux personnes peuvent avoir le même nom, le même prénom et le même âge,
mais pas le même numéro de sécurité sociale. Ainsi, chaque type-entité possède au
moins un attribut qui, s’il est seul, est donc forcément l’identifiant. Dans la représentation
graphique, les attributs qui constituent l’identifiant sont soulignés et placés en tête.

d) Association ou relation
 20

Une association (ou une relation) est un lien entre plusieurs entités. Les
associations ne sont généralement pas représentées graphiquement.

Type-association désigne un ensemble de relations qui possèdent les mêmes

caractéristiques. Le type-association décrit un lien entre plusieurs type-entités. Les
associations de ce type-association lient des entités de ces types-entités.

Comme les type-entités, les types-associations sont définis à l’aide d’attributs qui
prennent leur valeur dans les associations.

Règle : Un attribut peut être placé dans un type-association lorsqu’il dépend de toutes les
entités liées par le type-association.

Un type-association peut ne pas posséder d’attribut explicite et cela est relativement

fréquent, mais on verra qu’il possède au moins des attributs implicites.

Exemples de type-association : L’emprunt d’un livre à la bibliothèque.

Une association est souvent nommée occurrence ou instance de son type-association.

Par abus de langage, on utilise souvent le mot association en lieu et place du mot type-
association, il faut cependant prendre garde à ne pas confondre les deux concepts.

e) Participant : Les types-entités intervenant dans un type-association sont appelés

les participants de ce type-association.
f) Collection : L’ensemble des participants d’un type-association est appelé la
collection de ce type-association. Cette collection comporte au moins un type-
entité, mais elle peut en contenir plus, on parle alors de type-association n-aire
(quand n=2 on parle de type-association binaire, quand n=3 de type-association
ternaire…)
 21

g) Dimension ou arité d’un type-association : La dimension est le nombre de type-

entités contenu dans la collection.

Règle : La concaténation des identifiants des type-entités liés à un type-association

un identifiant de ce type-association et cet identifiant n’est pas mentionné sur le
modèle (il est implicite).

Cette règle implique que deux instances d’un même type-association ne peuvent lier
un même ensemble d’entités. Souvent un sous-ensemble de la concaténation des
identifiants des type-entités liés suffit à identifier le type-association.

On admet également un identifiant plus naturel et explicite, la condition qu’il ne soit

qu’un moyen d’exprimer plus simplement cette concaténation.
f) Cardinalité

Une cardinalité d’une patte reliant un type-association et un type-entité précise le

nombre de fois minimal et maximal d’interventions d’une entité du type-entité dans une
association du type-association. La cardinalité minimale doit être inférieure ou égale à la
cardinalité maximale.

Règles :

- L’expression de la cardinalité est obligatoire pour chaque patte d’un type-

association.
- Une cardinalité minimale est toujours 0 ou 1 et une cardinalité maximale est
toujours 1 ou n.

Ainsi, si une cardinalité maximale est connue et vaut 2,3 ou plus, alors nous considérons
qu’elle est indéterminée et vaut n. En effet, si nous connaissons n au moment de la
conception, il se peut que cette valeur évolue au cours du temps. Il vaut donc mieux
considérer n comme inconnue dès le départ. De la même manière, on ne modélise pas
 22

des cardinalités minimales qui valent plus de 1 car ces valeurs sont également
susceptibles d’évoluer. Enfin, une cardinalité maximale de 0 n’a pas de sens car elle
rendrait le type-association inutile.

Les seules cardinalités admises sont donc :

0,1 : une occurrence du type-entité peut exister tout en étant impliquée dans aucune
association et peut être impliquée dans au maximum une association.

0,n : c’est la cardinalité la plus ouverte ; une occurrence du type-entité peut exister étant
impliquée dans aucune association et peut être impliquée, sans limitation, dans plusieurs
associations.

1,1 : une occurrence du type-entité ne peut exister que si elle est impliquée dans
exactement (au moins et au plus) une association.
1,n : une occurrence du type-entité ne peut exister que si elle est impliquée dans au
moins une association.

Remarques
La seule difficulté pour établir correctement les cardinalités est de se poser les questions
dans le bon sens. Pour augmenter le risque d’erreurs, il faut noter que, pour les habitués,
du modèle UML, les cardinalités d’un type-association sont à l’envers pours les type-
associations binaire et à l’endroit pour n-aires avec n>2. La notion de cardinalité n’est
pas définie de la même manière dans le modèle Américain et dans le modèle Européen
(Merise). Dans le premier n’existe que la notion de cardinalité maximale. Avec un SGBD
relationnel, nous pourrons contraindre des cardinalités à des valeurs 2,3 ou plus en
utilisant des déclencheurs.

2.4. Compléments sur les associations

 23

2.4.1. Association plurielles

Sur ce schéma, un type-association permet de modéliser que des personnes

écrivent des livres et un autre que des personnes critiquent (au sens de critique littéraire)
des livres.

Deux mêmes entités peuvent être plusieurs fois en association.

2.4.2. Association réflexive

Les type-associations réflexifs sont présents dans la plupart des modèles.

Un type-association est qualifié de réflexif quand il matérialise une relation entre
un type-entité et lui-même.

Le premier type-association permet de modéliser la relation parent/enfant et le deuxième

type-association la relation de fraternité.

Cette relation peut être symétrique, c’est le cas du type-association Etre frère ou ne pas
l’être, comme le type-association Etre parent sur cette même figure. Dans le cas où la
relation n’est pas symétrique, on peut préciser les rôles sur les pattes du type-association
comme relation Etre parent. L’ambiguïté posée par la non-symétrie d’un type-association
réflexif sera levée lors du passage au modèle relationnel.
 24

2.4.3. Association n-aire (n>2)

Ce type-association met en relation n type-entités. Même s’il n’y a, en principe

pas de limite sur l’arité d’un type-association, dans la pratique on ne va rarement au-delà
de trois. Les associations de degré supérieur à deux sont plus difficiles à manipuler et à
interpréter, notamment au niveau des cardinalités.

Exemple d’association n-aire inappropriée

Le type-association ternaire Contient associant les types-entités Facture, Produit

et Client représenté sur cette figure est inapproprié puisqu’une facture donnée est
toujours adressée au même client. En effet, cette modélisation implique pour les
associations (instances du type-association) Contient une répétition du numéro de client
pour chaque produit d’une même facture.
 25

La solution consiste à éclater le type-association ternaire Contient en deux type-

associations binaires comme représenté sur la figure ci-haut.

Décomposition d’une association n-aire

Cette figure nous montre un exemple de type-association ternaire entre les types-entités
Créneau horaire, Salle et Film. Il est toujours possible de d’affranchir d’un type-
association n-aire (n>2) en se ramenant à des type-associations binaires de la manière
suivante :
 26

- On remplace le type-association n-aire par un type-entité et on lui attribut un

identifiant.
- On crée les type-associations binaire entre le nouveau type-entité et tous les type-
entités de la collection de l’ancien type-association n-aire.
- La cardinalité de chacun des type-associations binaires créés est 1,1 du côté du
type-entité créé (celui qui remplace le type-association n-aire), et 0,n ou 1,n du
côté des type-entités de la collection de l’ancien type-association n-aire.

L’avantage de ce schéma est de rendre plus intelligible la lecture des cardinalités. C’est
la transformation du type-association ternaire de la figure précédente en un type-entité et
trois type-associations binaires.

Le passage d’un type-association n-aire (n>2) à un type-entité et n type-associations

binaires est surtout fait réversible à condition que :

- Toutes les pattes des type-associations binaires autour du type-entité central ont
une cardinalité maximale de 1 au centre et de n à l’extérieur.
- Les attributs du type-entité central satisfont la règle de bonne formation des
attributs de type-association.

Détection d’une erreur de modélisation par décomposition d’une association n-

aire.

Passer par cette étape intermédiaire ne comportant pas de type-association n-

aire (n>2) peut, dans certains cas éviter d’introduire un type-association n-aire
 27

inapproprié. Imaginons par exemple un type-association ternaire Vol liant trois type-
entités Avion, Trajet et Pilote.

La transformation consistant à supprimer le type-association ternaire. Ce modèle

fait immédiatement apparaître une erreur de conception qui était jusque-là difficile à
diagnostiquer : généralement, à un vol donné sont affectés plusieurs pilotes (par exemple
le commandant de bord et un copilote) et non pas un seul. Le modèle correct modélisant
cette situation est celui où le type-entité Vol ne peut être transformé en un type-
association ternaire Vol.

Modèle représentant un type-association ternaire Vol liant trois type-entités

Avion, Trajet et Pilote.

 28

Transformation du type-association ternaire en un type-entité et trois type-associations

binaires.
Modèle corrigé au niveau des cardinalités.

2.4.4. Règles de bonne formation d’un modèle entités-associations

La bonne formation d’un modèle entités-associations permet d’éviter une grande

partie des sources d’incohérences et de redondance. Pour être bien formé, un modèle
entités-associations doit respecter certaines règles et les type-entités et type-
associations doivent être normalisées. Un bon principe de conception peut être formulé

ainsi : « une seule place pour chaque fait ».

Bien que l’objectif des principes exposés dans cette section soit d’aider le
concepteur à obtenir un diagramme entités-associations bien formé, ces principes ne
doivent pas être interprétés comme des lois. Qu’il s’agisse des règles de bonne formation
ou des règles de normalisation, il peut exister, très occasionnellement, de bonnes raisons
pour ne pas les appliquer.
 29

1. Règles portant sur les noms :

Dans un modèle entités-associations, le nom d’un type-entité, d’un type-

association ou d’un attribut doit être unique.

La présence des deux type-entités Enseignant et Etudiant est symptomatique d’une

modélisation inachevée. A terme, ces deux type-entités doivent être fusionnés en un
unique type-entité Personne.

Ici, les attributs Adresse de facturation sont redondants. Cette situation doit être évitée à
tout prix car elle entraîne un gaspillage d’espace mémoire mais aussi et surtout un
grand risque d’incohérence.
En effet, que faire si, dans le cadre d’une occurrence du type-association Correspondre,
la valeur des deux attributs Adresse de facturation diffèrent ?

Dans cette situation, les deux attributs Adresse doivent simplement être renommés en
Adresse client et Adresse fournisseur. Il en va de même pour les deux attributs Nom.
Lorsque des attributs portent le même nom, c’est parfois le signe d’une
modélisation inachevée ou d’une redondance. Sinon, il faut simplement ajouter au nom
 30

de l’attribut le nom du type-entité ou du type-association dans lequel il se trouve. Il faut

toutefois remarquer que le dernier cas décrit n’est pas rédhibitoire et que les SGDB
Relationnel s’accommodent très bien de relations comportant des attributs de même
nom. L’écriture des requêtes sera tout de même plus lisible si les attributs ont tous des
noms différents.
2. Règles de normalisation des attributs
Règle 1. Il faut remplacer un attribut multiple en un type-association et un type-entité
supplémentaires.

Remplacement des attributs multiples en un type-association et un type-entité et

décomposition des attributs composites.
En effet, les attributs multiples posent régulièrement des problèmes d’évolutivité
du modèle. Par exemple, sur le modèle de gauche, comment faire si un employé possède
deux adresses secondaires ou plusieurs numéros de portable ? Il est également
intéressant de décomposer les attributs composites comme l’attribut Adresse par
exemple. Il est en effet difficile d’écrire une requête portant sur la ville où habitent les
employés si cette information est noyée dans un unique attribut Adresse.
Règle 2. Il ne faut jamais ajouter un attribut dérivé d’autres attributs, que ces autres
attributs se trouvent dans le même type-entité ou pas.
 31

Il faut supprimer l’attribut Montant total du type-entité Commande car on peut le calculer
à partir des attributs Quantité du type association Contenir et Prix unitaire du type-entité
Article.
En effet, les attributs dérivés induisent un risque d’incohérence entre les valeurs
des attributs de base et celles des attributs dérivés. La figure illustre le cas d’un attribut
Montant total dans un type-entité Commande qui peut être calculé à partir des attributs

Quantité du type association Contenir et Prix unitaire du type-entité Article. Il faut donc
supprimer l’attribut Montant total dans le type-entité Commande. D’autres attributs
dérivés sont également à éviter comme l’âge, que l’on peut déduire de la date de
naissance et de la date courante. Il faut cependant faire attention aux pièges : par
exemple, le code postal ne détermine ni le numéro de département ni la Ville. Comme
nous l’avons déjà dit, les attributs d’un type-association doivent dépendre directement
des identifiants de tous les type-entités de la collection du type-association.

– Comme la cardinalité maximale du type-association Livrer est 1 du côté du type-entité

Livraison, l’attribut Nom livreur de Livrer doit être déplacé dans Livraison.
Par exemple, sur la figure précédente, l’attribut Quantité du type-association
Contenir dépend bien à la fois de l’identifiant N° commande et de N° article des type-
entités de la collection de Contenir. Inversement, sur cette même figure, l’attribut Prix-
unitaire ne dépend que de N° article du type-entité Article, il ne pourrait donc pas être un
attribut du type-association Contenir. Une conséquence immédiate de cette règle est
qu’un type association dont la cardinalité maximale de l’une des pattes est 1 ne peut pas
posséder d’attribut. Si elle en possédait, ce serait une erreur de modélisation et il faudrait
les déplacer dans le type-entité connecté à la patte portant la cardinalité maximale de 1.
Règle3. Un attribut correspondant à un type énuméré est généralement
avantageusement remplacé par un type-entité.
 32

Par exemple, sur la figure ci-dessous, l’attribut Type caractérise le type d’une
émission et peut prendre des valeurs comme : actualité, culturelle, reportage,
divertissement, etc. Remplacer cet attribut par un type-entité permet, d’une part,
d’augmenter la cohérence (en s’affranchissant, par exemple, des variations du genre
culturelle, culture, Culture, . . .) et d’autre part, si les cardinalités le permettent, de pouvoir
affecter plusieurs types à une même entité (ex : actualité et culturelle).

- Un attribut correspondant à un type énuméré est généralement avantageusement

remplacé par un type-entité.
3. Règles de fusion/suppression d’entités/associations
Règle 3.1. Il faut factoriser les type-entités quand c’est possible.
La spécialisation du type-entité obtenu peut se traduire par l’introduction d’un
attribut supplémentaire dont l’ensemble des valeurs possibles est l’ensemble des noms
des type-entités factorisés.

– Il faut factoriser les type-entités quand c’est possible, éventuellement en introduisant

un nouvel attribut.
 33

Mais l’introduction d’un attribut supplémentaire n’est pas forcément nécessaire ou

souhaitable. Par exemple, sur le modèle entités-associations final de la figure ci-dessous,
on peut distinguer les entités qui correspondent à des écrivains ou des abonnés en
fonction du type de l’association, Ecrire ou Emprunter, que l’entité en question entretient
avec une entité du type Livre. Ne pas introduire d’attribut permet en outre de permettre à
une personne d’être à la fois un Abonné et un Écrivain.

– Il faut factoriser les type-entités quand c’est possible, mais l’introduction d’un attribut
supplémentaire n’est pas toujours nécessaire. Remarque : ce diagramme est
intentionnellement simplifié à outrance.
Règle 3.2. Il faut factoriser les type-associations quand c’est possible.
Règle 3.3. Un type-entité remplaçable par un type-association doit être remplacé.
Règle 3.4. Lorsque les cardinalités d’un type-association sont toutes 1, 1 c’est que le
type-association n’a pas lieu d’être.
 34

Figure : Un seul type-association suffit pour remplacer les quatre type-associations

Jouer en tant que ...
Il faut aussi se poser la question de l’intérêt du type-association quand les cardinalités
maximale sont toutes de 1.

– Lorsque les cardinalités d’un type-association sont toutes 1, 1 c’est qu’il s’agit d’un type-

association fantôme.
Lorsque les cardinalités d’un type-association sont toutes 1, 1, le type-association
doit généralement être supprimé et les type-entités correspondant fusionnés comme
l’illustre la figure 2.29. Néanmoins, même si toutes ses cardinalités maximale sont de 1,
 35

il est parfois préférable de ne pas supprimer le type-association, comme dans l’exemple

de la figure ci-dessous.
Règle3.5. Il faut veiller à éviter les type-associations redondants. En effet, s’il existe deux
chemins pour se rendre d’un type-entité à un autre, alors ces deux chemins doivent avoir
deux significations ou deux durées de vie distinctes. Dans le cas contraire, il faut
supprimer le chemin le plus court puisqu’il est déductible des autres chemins.
Par exemple, dans le modèle représenté sur la figure 2.31, si un client ne peut pas régler
la facture d’un autre client, alors le type-association Payer est redondant et doit purement
et simplement être supprimé.

– Même si toutes les cardinalités maximale sont de 1, il vaut mieux conserver le type-
association Etre.
 36

FIG. – Si un client ne peut pas régler la facture d’un autre client, alors le type-association
Payer est inutile.

FIG. – Solution au problème de la redondance du type-association.

4. Normalisation des type-entités et type-associations

Introduction
Les formes normales sont les différents stades de qualité qui permettent d’éviter
la redondance, source d’anomalies. La normalisation peut être aussi bien effectuée sur
un modèle entités-associations, où elle s’applique sur les type-entités et type-
associations, que sur un modèle relationnel.
 37

Il existe 5 formes normales principales et deux extensions. Plus le niveau de

normalisation est élevé, plus le modèle est exempte de redondances. Un type-entité ou
un type-association en forme normale de niveau n est automatiquement en forme
normale de niveau n − 1. Une modélisation rigoureuse permet généralement d’aboutir
directement à des type-entités et type-associations en forme normale de Boyce-Codd.
Nous avons décidé de présenter deux fois cette théorie de la normalisation :
- Une première fois, dans le cadre du modèle entités-associations (la présente
section 2.5.4), en privilégiant une approche plus intuitive qui n’introduit pas
explicitement la notion de dépendance fonctionnelle (et encore moins les notions
de dépendance multivaluée et de jointure). Nous nous arrêterons, dans cette
section, à la forme normale de Boyce-Codd.
- Puis une seconde fois, dans le cadre de modèle relationnel (section 3.2), en
privilégiant une approche plus formelle s’appuyant sur la définition des
dépendances fonctionnelle, multivaluée et de jointure. Nous irons alors jusqu’à la
cinquième forme normale.
Première forme normale (1FN)
Un type-entité ou type-association est en première forme normale si tous ses attributs
sont élémentaires, c’est-à-dire non décomposables.
Un attribut composite doit être décomposé en attributs élémentaires ou faire l’objet d’une
entité supplémentaire. L’élémentarité d’un attribut est toutefois fonction des choix de
gestion. Par exemple, la propriété Adresse peut être considérée comme élémentaire si
la gestion de ces adresses est globale. Par contre, s’il faut pouvoir considérer les codes
postaux, les noms de rue,…,il convient d’éclater la propriété Adresse en Adresse (au
sens numéro d’appartement, numéro et nom de rue,…), Code postal et Ville. En cas de
doute, il est préférable (car plus général) d’éclater une propriété que d’effectuer un
regroupement.
Deuxième forme normale (2FN)
 38

Exemple de normalisation en deuxième forme normale. On suppose qu’un même

fournisseur peut fournir plusieurs produits et qu’un même produit peut être fourni par
différents fournisseurs.
Un type-entité ou un type-association est en deuxième forme normale si, et
seulement si, il est en première forme normale et si tout attribut n’appartenant pas à la
clé dépend de la totalité de cette clé.
Autrement dit, les attributs doivent dépendre de l’ensemble des attributs
participant à la clé. Ainsi, si la clé est réduite à un seul attribut, ou si elle contient tous les
attributs, le type-entité ou le type-association est, par définition, forcément en deuxième
forme normale.
Cette figure montre un type-entité Article décrivant des produits provenant de différents
fournisseurs.
On suppose qu’un même fournisseur peut fournir plusieurs produits et qu’un même
produit peut être fourni par différents fournisseurs. Dans ce cas, les attributs Produit ou
Fournisseur ne peuvent constituer un identifiant du type-entité Article. Par contre, le
couple Produit/Fournisseur constitue bien un identifiant du type-entité Article. Cependant,
l’attribut Adresse fournisseur ne dépend maintenant que d’une partie de la clé
(Fournisseur). Opter pour une nouvelle clé arbitraire réduite à un seul attribut N° article
permet d’obtenir un type-entité Article en deuxième forme normale. On va voir dans ce
qui suit que cette solution n’a fait que déplacer le problème.
Troisième forme normale (3FN)
Un type-entité ou un type-association est en troisième forme normale si, et
seulement si, il est en deuxième forme normale et si tous ses attributs dépendent
directement de sa clé et pas d’autres attributs.
 39

Cette normalisation peut amener à désimbriquer des type-entités cachées

comme le montre la figure ci-dessous.
Un type-entité ou un type-association en deuxième forme normale avec au plus
un attribut qui n’appartient pas à la clé est, par définition, forcément en troisième forme
normale.

– Exemple de normalisation en troisième forme normale. Dans cet exemple, l’attribut

Adresse fournisseur dépend de l’attribut Fournisseur.
Forme normale de Boyce-Codd (BCNF)

Exemple de normalisation en forme normale de Boyce-Codd.

Un type-entité ou un type-association est en forme normale de Boyce-Codd si, et
seulement si, il est en troisième forme normale et si aucun attribut faisant partie de la clé
dépend d’un attribut ne faisant pas partie de la clé.
Intéressons-nous, par exemple (cf. figure ci-haut), à un type-entité Diplômé modélisant
des personnes (Nom et Prénom) possédant un diplôme (Diplôme) d’une institution
(Institution). On suppose qu’il n’y a pas d’homonyme, qu’une même personne ne possède
pas deux fois le même diplôme mais qu’elle peut posséder plusieurs diplômes différents.
Une institution ne délivre qu’un type de diplôme, mais un même diplôme peut être délivré
par plusieurs institutions (par exemple, plusieurs écoles d’ingénieurs délivrent des
diplômes d’ingénieur). Une clé possible pour le type-entité Diplômé est donc Nom,
Prénom, Diplôme. Le type-entité obtenu est en troisième forme normale, mais une
 40

redondance subsiste car l’attribut Institution détermine l’attribut Diplôme. Le type-entité

Diplômé n’est donc pas en forme normale de Boyce-Codd.
Un modèle en forme normale de Boyce-Codd est considéré comme étant de qualité
suffisante pour une implantation.
Autres formes normales
Il existe d’autres formes normales. La quatrième et la cinquième forme normale
sont présentées dans le cadre du modèle relationnel.

4. Élaboration d’un modèle entités-associations

5.

5.1. Étapes de conceptions d’un modèle entités-associations

Pour concevoir un modèle entités-associations, vous devrez certainement passer

par une succession d’étapes. Nous les décrivons ci-dessous dans l’ordre chronologique.
Sachez cependant que la conception d’un modèle entités-associations est un travail non
linéaire. Vous devrez régulièrement revenir à une étape précédente et vous n’avez pas
besoin d’en avoir terminé avec une étape pour commencer l’étape suivante.
- Recueil des besoins : C’est une étape primordiale. Inventoriez l’ensemble des
données à partir des documents de l’entreprise, d’un éventuel cahier des charges
et plus généralement de tous les supports de l’information. N’hésitez pas à poser
des questions.
- Tri de l’information : Faites le tri dans les données recueillies. Il faut faire
attention, à ce niveau, aux problèmes de synonymie/polysémie. En effet, les
attributs ne doivent pas être redondants. Par exemple, si dans le langage de
l’entreprise on peut parler indifféremment de référence d’article ou de n° de produit
pour désigner la même chose, cette caractéristique ne devra se concrétiser que
par un unique attribut dans le modèle. Inversement, on peut parler d’adresse pour
désigner l’adresse du fournisseur et l’adresse du client, le contexte permettant de
lever l’ambiguïté. Par contre, dans le modèle, il faudra veiller à bien distinguer ces
deux caractéristiques par deux attributs distincts.
Un autre exemple est celui d’une entreprise de production fabricant des produits
à destination d’une autre société du même groupe. Il se peut que dans ce cas, le prix de
 41

production (i.e. le coût de revient industriel) soit le même que prix de vente (aucune marge
n’est réalisée). Même dans ce cas où les deux caractéristiques sont identiques pour
chaque entité (prix de production égale prix de vente), il faut impérativement les scinder
en deux attributs au niveau du type-entité Produit.
Sinon, cette égalité factuelle deviendrait une contrainte imposée par le modèle, obligeant
alors l’entreprise de production à revoir son système le jour où elle décidera de réaliser
une marge (prix de production inférieure au prix de vente).
- Identification des type-entités : Le repérage d’attributs pouvant servir
d’identifiant permet souvent de repérer un type-entité. Les attributs de ce type-
entité sont alors les attributs qui dépendent des attributs pouvant servir
d’identifiant.
Attention, un même concept du monde réel peut être représenté dans certains
cas comme un attribut et dans d’autres cas comme un type-entité, selon qu’il a ou non
une existence propre. Par exemple, la marque d’une automobile peut être vue comme un
attribut du type-entité Véhicule de la base de données d’une préfecture mais aussi
comme un type-entité Constructeur automobile dans la base de données du Ministère de
l’Industrie.
Lorsqu’on ne parvient pas à trouver d’identifiant pour un type-entité, il faut se demander
s’il ne s’agit pas en fait d’un type-association. Si ce n’est pas le cas, un identifiant
arbitraire numérique entier peut faire l’affaire.
- Identification des type-associations : Identifiez les type-associations reliant les
type-entités du modèle.
Le cas échéant, leur affecter les attributs correspondant.
Il est parfois difficile de faire un choix entre un type-entité et un type-association. Par
exemple, un mariage peut être considéré comme un type-association entre deux
personnes ou comme un
type-entité pour lequel on veut conserver un numéro, une date, un lieu, . . ., et que l’on
souhaite manipuler en tant que tel.
Étudiez également les cardinalités des type-associations retenus. Lorsque toutes les
pattes d’un
 42

type-association portent la cardinalité 1, 1, il faut se demander si ce type-association et

les type entités liés ne décrivent pas en fait un seul type-entité (cf. règle 2.29).
- Vérification du modèle – Vérifiez que le modèle respecte bien les règles que
nous avons énoncées et les définitions concernant la normalisation des type-
entités et des type-associations. Le cas échéant, opérez les modifications
nécessaires pour que le modèle soit bien formé.
Remarque : pour faciliter la lecture du schéma, il est assez courant de ne pas y faire
figurer les attributs ou de ne conserver que ceux qui font partie des identifiants. Les
attributs cachés doivent alors absolument être spécifiés dans un document à part.
6. 5. Conseils divers
- Concernant le choix des noms
Pour les type-entités, choisissez un nom commun décrivant le type-entité (ex :
Étudiant, Enseignant, Matière). Certain préfèrent mettre le nom au pluriel (ex : Étudiants,
Enseignants, Matières). Restez cependant cohérents, soit tous les noms de type-entité
sont au pluriel, soit ils sont tous au singulier.
Pour les type-association, choisissez un verbe à l’infinitif, éventuellement à la forme
passive ou accompagné d’un adverbe (ex : Enseigner, Avoir lieu dans).
Pour les attributs, utilisez un nom commun au singulier éventuellement accompagné du
nom du type-entité ou du type-association dans lequel il se trouve (ex : nom de client,
numéro d’article).
Concernant le choix des identifiants des type-entités
- Évitez les identifiants composés de plusieurs attributs (comme, par exemple, un
identifiant formé par les attributs nom et prénom d’un type-association Personne)
car :
 ils dégradent les performances du SGBD,
 mais surtout l’unicité supposée par une telle démarche finit généralement, tôt ou
tard, par être démentie !
- Évitez les identifiants susceptibles de changer au cours du temps (comme la
plaque d’immatriculation d’un véhicule).
- Évitez les identifiants du type chaîne de caractère.
 43

- En fait, il est souvent préférable de choisir un identifiant arbitraire de type entier

pour les type-entités. Cet identifiant deviendra une clé primaire dans le schéma
relationnel et le SGBD l’incrémentera automatiquement lors de la création de
nouvelles instances. L’inconvénient de cette pratique est qu’il devient possible de
se retrouver avec deux instances du type-entités représentant le même objet mais
avec deux numéros différents. Malgré cette inconvénient, cette politique de
l’identifiant reste largement avantageuse dans la pratique et permet, en outre, de
s’affranchir (en la satisfaisant automatiquement) de la deuxième forme normale.
Bien distinguer les concepts de données et de traitements
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 de
traitements. Par exemple, la facturation est un traitement qui nécessite de connaître
toutes les caractéristiques d’une commande. Par contre, la facturation ne se traduit ni par
un type-entité, ni par un type-association dans le schéma entités-associations.
 44

Chapitre 3. Bases de données relationnelles

Objectifs :

Au terme de ce chapitre, le participant doit décrire :

a. le modèle relationnel
b. l’algèbre relationnel

3.1. Introduction au modèle relationnel

3.1.1 Présentation

Retenez que, ce chapitre a été déjà abordé dans les chapitres précédents.
Dans ce modèle, les données sont représentées par des tables, sans préjuger
de la façon dont les informations sont stockées dans la machine. Les tables constituent
donc la structure logique1 du modèle relationnel. Au niveau physique, le système est libre
d’utiliser n’importe quelle technique de stockage (fichiers séquentiels, indexage,
adressage dispersé, séries de pointeurs, compression, . . .) dès lors qu’il est possible de
relier ces structures à des tables au niveau logique. Les tables ne représentent donc
qu’une abstraction de l’enregistrement physique des données en mémoire.
Le succès du modèle relationnel auprès des chercheurs, concepteurs et
utilisateurs est dû à la puissance et à la simplicité de ses concepts. En outre,
contrairement à certains autres modèles, il repose sur des bases théoriques solides,
notamment la théorie des ensembles et la logique des prédicats du premier ordre.
Les objectifs du modèle relationnel sont :
- proposer des schémas de données faciles à utiliser ;
- améliorer l’indépendance logique et physique (cf. section 1.2.2) ;
- mettre à la disposition des utilisateurs des langages de haut niveau ;
- optimiser les accès à la base de données ;
- améliorer l’intégrité et la confidentialité ;
- fournir une approche méthodologique dans la construction des schémas.
De façon informelle, on peut définir le modèle relationnel de la manière suivante
:
 45

- les données sont organisées sous forme de tables à deux dimensions, encore
appelées relations, dont les lignes sont appelées n-uplet ou tuple en anglais ;
- les données sont manipulées par des opérateurs de l’algèbre relationnelle ;
- l’état cohérent de la base est défini par un ensemble de contraintes d’intégrité.
Au modèle relationnel est associée à la théorie de la normalisation des relations
qui permet de se débarrasser des incohérences au moment de la conception d’une base
de données relationnelle.

3.1.2 Éléments du modèle relationnel

- attribut : Un attribut est un identificateur (un nom) décrivant une information

stockée dans une base.
Exemples d’attribut : l’âge d’une personne, le nom d’une personne, le numéro de sécurité
sociale.
- Domaine : Le domaine d’un attribut est l’ensemble, fini ou infini, de ses valeurs
possibles.
Par exemple, l’attribut numéro de sécurité sociale a pour domaine l’ensemble des
combinaisons de quinze chiffres et nom a pour domaine l’ensemble des combinaisons
de lettres (une combinaison comme cette dernière est généralement appelée chaîne de
caractères ou, plus simplement, chaîne).
- Relation : une relation est un sous-ensemble du produit cartésien de n domaines
d’attributs (n > 0).
Une relation est représentée sous la forme d’un tableau à deux dimensions dans
lequel les n attributs correspondent aux titres des n colonnes.
- Schéma de relation : Un schéma de relation précise le nom de la relation ainsi
que la liste des attributs avec leurs domaines.
Le tableau suivant montre un exemple de relation et précise son schéma.
 46

Exemple de relation de schéma Personne (N° sécu : Entier, Nom : Chaîne, Prénom :
Chaîne).

- Degré : Le degré d’une relation est son nombre d’attributs.

- occurrence ou n-uplets ou tuples : une occurrence, ou n-uplets, ou tuples, est
un élément de l’ensemble figuré par une relation. Autrement dit, une occurrence
est une ligne du tableau qui représente la relation.
- Cardinalité : La cardinalité d’une relation est son nombre d’occurrences.
- clé candidate : Une clé candidate d’une relation est un ensemble minimal des
attributs de la relation dont les valeurs identifient à coup sûr une occurrence.
La valeur d’une clé candidate est donc distincte pour toutes les tuples de la relation. La
notion de clé candidate est essentielle dans le modèle relationnel.
Règle. Toute relation a au moins une clé candidate et peut en avoir plusieurs.
Ainsi, il ne peut jamais y avoir deux tuples identiques au sein d’une relation. Les clés
candidates d’une relation n’ont pas forcément le même nombre d’attributs. Une clé
candidate peut être formée d’un attribut arbitraire, utilisé à cette seule fin.
- clé primaire : La clé primaire d’une relation est une de ses clés candidates. Pour
signaler la clé primaire, ses attributs sont généralement soulignés.
- clé étrangère : Une clé étrangère dans une relation est formée d’un ou plusieurs
attributs qui constituent une clé primaire dans une autre relation.
- schéma relationnel : Un schéma relationnel est constitué par l’ensemble des
schémas de relation.
- base de données relationnelle : Une base de données relationnelle est
constituée par l’ensemble des n-uplets des différentes relations du schéma
relationnel.

3.1.3 Passage du modèle entités-associations au modèle relationnel

Règles de passage
Pour traduire un schéma du modèle entités-associations vers le modèle relationnel, on
peut appliquer les règles suivantes :
 47

1. La normalisation devrait toujours être effectuée avant le passage au modèle relationnel

(cf. section2.5.4). Dans les faits, elle est parfois faite a posteriori (section 3.2), ce qui
impose toujours une surcharge de travail importante.
2. Chaque type-entité donne naissance à une relation. Chaque attribut de ce type-entité
devient un attribut de la relation. L’identifiant est conservé en tant que clé de la relation.
3. Chaque type-association dont aucune patte n’a pour cardinalité maximale 1 donne
naissance à une relation. Chaque attribut de ce type-association devient un attribut de la
relation. L’identifiant, s’il est précisé, est conservé en tant que clé de la relation, sinon
cette clé est formée par la concaténation des identifiants des type-entités qui
interviennent dans le type-association.
4. Un type-association dont au moins une patte a une cardinalité maximale à 1 (ce type-
association devrait être binaire et n’a généralement pas d’attribut) ne devient pas une
relation. Il décrit en effet une dépendance fonctionnelle (cf. section 3.2). La relation
correspondant au type-entité dont la patte vers le type-association a une cardinalité
maximale valant 1, se voit simplement ajouter comme attribut (et donc comme clé
étrangère) l’identifiant de l’autre type-entité.
Cas particulier d’un type-association du type 1 vers 1

- Reprise de l’exemple où toutes les cardinalités maximales sont de 1.

L’application des règles de passage du modèle entités-associations au modèle
relationnel énoncées ci-dessus nous donnerait :
- Citoyen (Num-Citoyen, Num-Candidat, Nom, Prénom, Adresse)
- Candidat (Num-Candidat), Num-Citoyen, Parti)
L’attribut Num-Candidat dans la relation Citoyen est une clé étrangère de la relation
Candidat. L’attribut
Num-Citoyen dans la relation Candidat est une clé étrangère de la relation Citoyen.
 48

Le type-association Etre étant du type 1 vers 1, il est entièrement matérialisé dans la

relation Candidat par l’attribut Num-Citoyen. Il est donc inutile de la rematérialiser dans
la relation Citoyen. L’attribut
Num-Candidat dans la relation Citoyen doit donc être supprimé. D’autre part, dans la
relation Candidat, l’attribut Num-Citoyen, en plus d’être une clé étrangère, constitue une
clé candidate. On peut donc se passer de la clé Num-Candidat.
Le schéma relationnel adéquat correspondant au modèle entités-associations de la figure
ci-haut devient donc :
- Citoyen (Num-Citoyen, Nom, Prénom, Adresse)
- Candidat (Num-Citoyen, Parti) où Num-Citoyen, en plus d’être la clé de la relation
Candidat, est une clé étrangère de la relation Citoyen.
Cas particulier d’un type-entité sans attribut autre que sa clé
Lorsqu’un type-entité ne possède pas d’attribut en dehors de sa clé, il ne faut pas
nécessairement en faire une relation.

- Ici, le type-entité Date ne doit pas se matérialiser par une relation.

Par exemple, le type-entité Date de la figure 3.2 ne doit pas se traduire par une relation.
Le schéma relationnel adéquat correspondant au modèle entités-associations de la figure
3.2 est donc :
- Exemplaire (Num-Exemplaire, date-achat)
- Personne (Num-Personne, nom, prénom, adresse)
- Emprunter (Num-Exemplaire, Num-Personne, Date, date-retour)
 49

Exemple complet

Exemple très simplifié de modélisation entités-associations.

Comme exemple d’application :

- Patient (Num-Patient, Nom-Patient, Num-Mutuelle)
- Mutuelle (Num-Mutuelle, Nom-Mutuelle)
- Médecin (Num-Médecin, Nom-Médecin, Prénom-Médecin)
- Affection (Num-Affection, Nom-Affection)
- Hospitaliser (Num-Patient, Num-Affection, Num-Médecin, Date-Entrée,Chambre,
Durée-Hospitalisation).

3.2 Normalisation

3.2.1 Introduction
Les formes normales sont différents stades de qualité qui permettent d’éviter la
redondance dans les bases de données relationnelles afin d’éviter ou de limiter : les
pertes de données, les incohérences au sein des données, l’effondrement des
performances des traitements.
Le processus de normalisation consiste à remplacer une relation donnée par
certaines projections afin que la jointure de ces projections permette de retrouver la
relation initiale. En d’autres termes, le processus est réversible (i.e. sans perte
 50

d’information). Les notions de projection et de jointure seront respectivement définies

dans les sections 3.4.3 et 3.4.8.
Il existe une hiérarchie dans les règles de normalisation : une relation en 5e forme
normale est forcément en 4e forme normale, une relation en 4e forme normale est
forcément en forme normale de Boyce-Codd, etc. Il existe des méthodes systématiques
pour normaliser une relation dans chacune des formes normales. Ces algorithmes de
décomposition, associés à chacune des formes normales, sortent du cadre de ce cours
et ne seront pas abordés.
La normalisation peut être effectuée, et c’est préférable, pendant la phase de
conception sur le modèle entités-associations (cf. section 2.5.4). Ce qui a été dit et les
exemples qui ont été donnés dans cette section restent transposables au modèle
relationnel. Dans le cas où la normalisation est faite en amont, lors de la conception, il
n’est pas nécessaire de la recommencer sur le modèle relationnel. On peut tout de même
vérifier que les relations obtenues par le passage du modèle entités-associations au
modèle relationnel sont toujours en forme normale, mais, sauf erreur, il ne devrait pas y
avoir de problème. Il en va tout autrement lorsque l’on ne connaît pas bien, ou maîtrise
pas bien, l’origine d’un modèle relationnel. Dans ce cas, vérifier la normalisation des
relations, et, le cas échéant, les normaliser, est une phase primordiale.
C’est également le cas lorsque le modèle relationnel est le modèle de conception
(i.e. on ne passe pas par un modèle entités-associations).
Contrairement à ce que nous avions fait dans la section 2.5.4 dans le cadre du
modèle entités-associations, nous abordons ici la normalisation en nous appuyant sur les
notions de dépendance fonctionnelle, dépendance multivaluée et dépendance de
jointure. Il est important de prendre conscience que la dépendance fonctionnelle, la
dépendance multivaluée et la dépendance de jointure sont des notions sémantiques.
Elles tirent leurs origines dans les contraintes du monde réel. Comme ces contraintes
participent à la sémantique de la situation, elles doivent avoir une manifestation dans la
base de données.
Les dépendances doivent donc être spécifiées dans la définition de la base de
données afin que le SGBD puisse les appliquer. Les concepts de normalisation
fournissent en fait un moyen indirect de déclarer ces dépendances. Autrement dit, la
 51

normalisation d’une base de données est une manifestation observable des

dépendances observées dans le monde réel. La dépendance fonctionnelle permet de
définir les premières formes normales jusqu’à la forme normale de Boyce-Codd (1FN,
2FN, 3FN et BCNF).
La dépendance multivaluée permet de définir la quatrième forme normale (4FN)
et la dépendance de jointure la cinquième forme normale (5FN).

3.2.2 Dépendance fonctionnelle (DF)

- dépendance fonctionnelle (DF) : Soit R (A1, A2, . . .An) un schéma de relation,

et X et Y des sous-ensembles de A1, A2, . . . An. On dit que X détermine Y ou
que Y dépend fonctionnellement de X si, et seulement si, des valeurs identiques
de X impliquent des valeurs identiques de Y. On le note : X → Y.
Autrement dit, il existe une dépendance fonctionnelle entre un ensemble
d’attributs X et un ensemble d’attributs Y, que l’on note X → Y, si connaissant une
occurrence de X on ne peut lui associer qu’une seule occurrence de Y.
Il est essentiel de noter qu’une dépendance fonctionnelle est une assertion sur
toutes les valeurs possibles et non sur les valeurs actuelles : elle caractérise une intention
et non une extension de la relation.
- dépendance fonctionnelle élémentaire : Une dépendance fonctionnelle
élémentaire est une dépendance fonctionnelle de la forme X → A, où A est un
attribut unique n’appartenant pas à X et où il n’existe pas X′ inclus au sens strict
dans X (i.e. X′ ⊂ X) tel que X′ → A.
Autrement dit, une dépendance fonctionnelle est élémentaire si la cible est un attribut unique et si la
source ne comporte pas d’attributs superflus. La question sur l’élémentarité d’une
dépendance fonctionnelle ne doit donc se poser que lorsque la partie gauche de la
dépendance fonctionnelle comporte plusieurs attributs.
- dépendance fonctionnelle directe : Une dépendance fonctionnelle X → A est
une dépendance fonctionnelle directe s’il n’existe aucun attribut B tel que l’on
puisse avoir X → B et B → A.
En d’autres termes, cela signifie que la dépendance entre X et A ne peut pas être obtenue
par transitivité.
 52

3.2.3 Première et deuxième forme normale

Première forme normale

- première forme normale (1FN) : Une relation est en première forme normale si,
et seulement si, tout attribut contient une valeur atomique (non multiples, non
composées).
Par exemple, le pseudo schéma de relation Personne (num-personne, nom, prénom, rue-
et-ville, prénomsenfants) n’est pas en première forme normale. Il faut le décomposer en
:
 Personne (num-personne, nom, prénom, rue, ville)
 Prénoms-enfants (num-personne, num-prénom)
 Prénoms (num-prénom, prénom)
Remarques sur la première forme normale
La première forme normale impose que chaque ligne d’une relation ait une seule
valeur pour chaque colonne (i.e. attribut), ce qui est justement la définition d’une table.
Donc, une table est nécessairement en première forme normale au sens du modèle
relationnel.
Cependant, il faut noter que le modèle relationnel peut être étendu de manière à
permettre des colonnes à valeur complexe. On parle alors de modèle relationnel étendu
(NF2 pour Non First Normal Form en anglais).
Deuxième forme normale
- deuxième forme normale (2FN) : une relation est en deuxième forme normale si,
et seulement si, elle est en première forme normale et si toutes les dépendances
fonctionnelles entre la clé et les autres attributs sont élémentaires.
Autrement dit, une relation est en deuxième forme normale si, et seulement si, elle est en
première forme normale et si tout attribut n’appartenant pas à la clé ne dépend pas que
d’une partie de la clé.
Une relation peut être en deuxième forme normale par rapport à une de ses clés
candidates et ne pas l’être par rapport à une autre. Une relation avec une clé primaire
réduite à un seul attribut est, par définition, forcément en deuxième forme normale.
 53

Soit, par exemple, le schéma de relation suivant : CommandeLivre (Num-Commande,

Num-Client,Titre, Auteur, Quantité, Prix). Cette relation indique qu’un client (identifié par
Num-Client) a passé une commande (identifiée par Num-Commande) de livre. Elle est
bien en première forme normale. Par contre, les attributs Titre, Auteur, Quantité et Prix
ne dépendent que de Num-Commande, et pas de Num-Client.
Cette relation n’est donc pas en deuxième forme normale. Une solution simple pour la
normaliser est de la remplacer par : CommandeLivre (Num-Commande, Num-Client,
Titre, Auteur, Quantité, Prix).

3.2.4 Troisième forme normale

- troisième forme normale (3FN) : une relation est en troisième forme normale si,
et seulement si, elle est en deuxième forme normale et si toutes les dépendances
fonctionnelles entre la clé et les autres attributs sont élémentaires et directes.
Autrement dit, une relation est en troisième forme normale si, et seulement si, elle est en
deuxième forme normale et si tout attribut n’appartenant pas à la clef ne dépend pas d’un
attribut non-clé.
Une relation peut être en troisième forme normale par rapport à une de ses clés
candidates et ne pas l’être par rapport à une autre. Une relation en deuxième forme
normale avec au plus un attribut qui n’appartient pas à la clé primaire est, par définition,
forcément en troisième forme normale.
Soit, par exemple, le schéma de relation suivant : CommandeLivre (Num-Commande,
Num-Client,Titre, Auteur, Quantité, Prix). Comme nous l’avons vu plus haut, cette relation
est bien en deuxième forme normale. Par contre, les attributs Auteur et Prix dépendent
de l’attribut Titre. La relation n’est donc pas en troisième forme normale. Pour la
normaliser, il faut la décomposer de la manière suivante :
– CommandeLivre(Num-Commande, Num-Client, Num-Livre, Quantité)
– Livre(Num-Livre, Titre, Auteur, Prix)
Remarques importantes
Soit les schémas de relation suivant :
– Ville (Code-Postal, Nom, Population)
– Personne (Nom, Prénom, Téléphone)
 54

Dans ces relations, on suppose les dépendances fonctionnelles directes suivantes :

– Code-Postal→Nom
– Code-Postal→Population
– Nom, Prénom→Téléphone
Dans la section 2.6.2, nous avons dit qu’il est souvent préférable de choisir un
identifiant arbitraire de type entier. Cette pratique semble aller à l’encontre de la troisième
forme normale. Par exemple, la relation Ville (num-ville, Nom, Code-Postal, Population)
n’est pas en troisième forme normale si l’on suppose que les attributs Nom et Population
dépendent toujours de l’attribut Code-Postal. Cependant, comme nous l’avons dit dans
l’introduction, une dépendance fonctionnelle est la manifestation d’une notion
sémantique, pas d’une notion formelle ou absolue. Dans le cas du code postal, nous
avons déjà expliqué (cf. note page 33) qu’il n’existe pas de relation systématique entre le
code postal et le code du département ou la commune. Ainsi, il n’y a pas de dépendance
fonctionnelle entre les attributs Nom et Population et l’attribut Code-Postal. La relation
Ville(num-ville, Nom, Code-Postal, Population) est donc bien en troisième forme normale
(en France, plusieurs villes portent le même nom). La notion de dépendance fonctionnelle
est donc une question d’interprétation faisant appel à la connaissance du système
modélisé et au bon sens.
Il en va de même avec le schéma de relation Livre(Num-Livre, Titre, Auteur, Prix). Nous
avons ici introduit un identifiant numérique arbitraire Num-Livre car l’identifiant naturel
Titre, qui est une chaîne de caractères complexe, de taille non bornée et au format libre,
ne constitue pas un bon identifiant dans la pratique. Pour justifier la troisième forme
normale de cette relation, on peut imaginer que plusieurs livres peuvent porter le même
titre.
Il faut enfin noter que la normalisation n’est pas une fin en soi et qu’elle ne doit pas
nécessairement être systématiquement appliquée (nous y reviendrons section 3.2.7).

3.2.5 Forme normale de BOYCE-CODD

- Forme normale de BOYCE-CODD (BCNF) : une relation est en forme normale de

BOYCE-CODD (BCNF) si, et seulement si, elle est en troisième forme normale et si les
 55

seules dépendances fonctionnelles élémentaires sont celles dans lesquelles une clé
détermine un attribut.
Cette forme normale permet de renforcer certaines lacunes de la troisième forme
normale.
Soit, par exemple, le schéma relationnel décrivant l’enseignement d’une matière donnée
à une classe par un enseignant :
– Matière (nom-matière)
– Classe (num-classe)
– Enseignant (nom-enseignant)
– Enseignement (nom-enseignant, num-classe, nom-matière)

3.3. Algèbre relationnelle

3.4.1 Introduction

L’algèbre relationnelle est un support mathématique cohérent sur lequel repose

le modèle relationnel.
L’objet de cette section est d’aborder l’algèbre relationnelle dans le but de décrire
les opérations qu’il est possible d’appliquer sur des relations pour produire de nouvelles
relations. L’approche suivie est donc plus opérationnelle que mathématique.
On peut distinguer trois familles d’opérateurs relationnels :
- Les opérateurs unaires (Sélection, Projection) : ce sont les opérateurs les plus
simples, ils permettent de produire une nouvelle table à partir d’une autre table.
- Les opérateurs binaires ensemblistes (Union, Intersection Différence) : ces
opérateurs permettent de produire une nouvelle relation à partir de deux relations
de même degré et de même domaine.
- Les opérateurs binaires ou n-aires (Produit cartésien, Jointure, Division) : ils
permettent de produire une nouvelle table à partir de deux ou plusieurs autres
tables.
Les notations ne sont pas standardisées en algèbre relationnelle. Ce cours utilise
des notations courantes mais donc pas forcément universelles.
 56

3.4.2 Sélection

La sélection (parfois appelée restriction) génère une relation regroupant

exclusivement toutes les occurrences de la relation R qui satisfont l’expression logique
E, on la note _(E) R. Il s’agit d’une opération unaire essentielle dont la signature est :
relation × expression logique →relation
En d’autres termes, la sélection permet de choisir (i.e. sélectionner) des lignes
dans le tableau. Le résultat de la sélection est donc une nouvelle relation qui a les mêmes
attributs que R. Si R est vide (i.e. ne contient aucune occurrence), la relation qui résulte
de la sélection est vide. Ce tableau montre un exemple de sélection.

Exemple de sélection sur la relation Personne du tableau ci-dessus.

3.4.3 Projection

La projection consiste à supprimer les attributs autres que A1, . . .An d’une
relation et à éliminer les n-uplets en double apparaissant dans la nouvelle relation ; on
la note (A1, ...An)R. Il s’agit d’une opération unaire essentielle dont la signature est :
relation × liste d’attributs −→relation
En d’autres termes, la projection permet de choisir des colonnes dans le tableau.
Si R est vide, la relation qui résulte de la projection est vide, mais pas forcément
équivalente (elle contient généralement moins d’attributs).
 57

Exemple de projection sur la relation Personne du tableau 3.6

3.4.4 Union

L’union est une opération portant sur deux relations R1 et R2 ayant le même
schéma et construisant une troisième relation constituée des n-uplets appartenant à
chacune des deux relations R1 et R2 sans doublon, on la note R1 ∪ R2.
Il s’agit une opération binaire ensembliste commutative essentielle dont la signature est :
relation × relation −→relation
Comme nous l’avons déjà dit, R1 et R2 doivent avoir les mêmes attributs et si
une même occurrence existe dans R1 et R2, elle n’apparaît qu’une seule fois dans le
résultat de l’union. Le résultat de l’union est une nouvelle relation qui a les mêmes
attributs que R1 et R2. Si R1 et R2 sont vides, la relation qui résulte de l’union est vide.
Si R1 (respectivement R2) est vide, la relation qui résulte de l’union est identique à R2
(respectivement R1).
Le tableau montre un exemple d’union.
 58

3.4.5 Intersection

L’intersection est une opération portant sur deux relations R1 et R2 ayant le

même schéma et construisant une troisième relation dont les n-uplets sont constitués de
ceux appartenant aux deux relations, on la note R1 ∩ R2.
Il s’agit une opération binaire ensembliste commutative dont la signature est : relation ×
relation −→relation.
Comme nous l’avons déjà dit, R1 et R2 doivent avoir les mêmes attributs. Le résultat de
l’intersection est une nouvelle relation qui a les mêmes attributs que R1 et R2. Si R1 ou
R2 ou les deux sont vides, la relation qui résulte de l’intersection est vide.
Le tableau montre un exemple d’intersection.

3.4.6 Différence
La différence est une opération portant sur deux relations R1 et R2 ayant le même
schéma et construisant une troisième relation dont les n-uplets sont constitués de ceux
ne se trouvant que dans la relation R1 ; on la note R1 − R2.
Il s’agit une opération binaire ensembliste non commutative essentielle dont la signature
est : relation × relation −→relation
Comme nous l’avons déjà dit, R1 et R2 doivent avoir les mêmes attributs. Le résultat de
la différence est une nouvelle relation qui a les mêmes attributs que R1 et R2. Si R1 est
vide, la relation qui résulte de la différence est vide. Si R2 est vide, la relation qui résulte
de la différence est identique à R1.
Le tableau 3.11 montre un exemple de différence.
 59

3.4.7 Produit cartésien

Le produit cartésien est une opération portant sur deux relations R1 et R2 et qui
construit une troisième relation regroupant exclusivement toutes les possibilités de
combinaison des occurrences des relations R1 et R2, on la note R1 × R2.
Il s’agit une opération binaire commutative essentielle dont la signature est : relation ×
relation −→relation
Le résultat du produit cartésien est une nouvelle relation qui a tous les attributs
de R1 et tous ceux de R2. Si R1 ou R2 ou les deux sont vides, la relation qui résulte du
produit cartésien est vide. Le nombre d’occurrences de la relation qui résulte du produit
cartésien est le nombre d’occurrences de R1 multiplié par le nombre d’occurrences de
R2
Le tableau montre un exemple de produit cartésien.

.
 60

3.4.8 Jointure, thêta-jointure, équijointure, jointure naturelle

La jointure est une opération portant sur deux relations R1 et R2 qui construit une
troisième relation regroupant exclusivement toutes les possibilités de combinaison des
occurrences des relations R1 et R2 qui satisfont l’expression logique E. La jointure est
notée R1 ✄✁ER2.
Il s’agit d’une opération binaire commutative dont la signature est : relation × relation ×
expression logique −→relation
Si R1 ou R2 ou les deux sont vides, la relation qui résulte de la jointure est vide.
En fait, la jointure n’est rien d’autre qu’un produit cartésien suivi d’une sélection : R1
✄✁ER2 = _E(R1 × R2)
Le tableau montre un exemple de jointure.

- Theta-jointure

Une thêta-jointure est une jointure dans laquelle l’expression logique E est une
simple comparaison entre un attribut A1 de la relation R1 et un attribut A2 de la relation
R2. La theta-jointure est notée R1 ✄✁ER2.
- Equijointure
Une équijointure est une theta-jointure dans laquelle l’expression logique
E est un test d’égalité entre un attribut A1 de la relation R1 et un attribut A2 de la relation
R2. L’equijointure est notée R1 ✄✁A1,A2R2.
 61

- jointure naturelle
Une jointure naturelle est une equi-jointure dans laquelle les attributs des
relations R1 et R2 portent le même nom A. Dans la relation construite, l’attribut A n’est
pas dupliqué mais fusionné en un seul attribut. La jointure naturelle est notée R1 ✄✁R2.
Le résultat de la jointure naturelle est une nouvelle relation qui a tous les attributs de R1
et tous ceux de R2 sauf A. Il est en fait indifférent d’éliminer l’attribut A de la relation R1
ou R2.
Le tableau montre un exemple de jointure naturelle.

- division
La division est une opération portant sur deux relations R1 et R2, telles que le
schéma de R2 est strictement inclus dans celui de R1, qui génère une troisième relation
regroupant toutes les parties d’occurrences de la relation R1 qui sont associées à toutes
les occurrences de la relation R2 ; on la note R1 ÷ R2.
Il s’agit d’une opération binaire non commutative dont la signature est :
relation × relation −→relation
Autrement dit, la division de R1 par R2 (R1 ÷ R2) génère une relation qui
regroupe tous les n-uplets qui, concaténés à chacun des n-uplets de R2, donne toujours
un n-uplet de R1. La relation R2 ne peut pas être vide. Tous les attributs de R2 doivent
être présents dans R1 et R1 doit posséder au moins un attribut de plus que R2 (inclusion
stricte). Le résultat de la division est une nouvelle relation qui a tous les attributs de R1
sans aucun de ceux de R2. Si R1 est vide, la relation qui résulte de la division est vide.
 62

Le tableau montre un exemple de division.

 63

Chapitre 4. Notions sur le langage SQL

Objectif :

A la fin de ce chapitre, le participant doit décrire :

a. le langage de définition de données
b. le langage de manipulation de données

4.1.1 Présentation générale

Introduction
Le langage SQL (Structured Query Language) peut être considéré comme le
langage d’accès normalisé aux bases de données. Il est aujourd’hui supporté par la
plupart des produits commerciaux que ce soit par les systèmes de gestion de bases de
données micro tel qu’Access ou par les produits plus professionnels tels qu’Oracle. Il a
fait l’objet de plusieurs normes ANSI/ISO dont la plus répandue aujourd’hui est la norme
SQL2 qui a été définie en 1992.
Le succès du langage SQL est dû essentiellement à sa simplicité et au fait qu’il
s’appuie sur le schéma conceptuel pour énoncer des requêtes en laissant le SGBD
responsable de la stratégie d’exécution. Le langage SQL propose un langage de requêtes
ensembliste et assertionnel. Néanmoins, le langage SQL ne possède pas la puissance
d’un langage de programmation : entrées/sorties, instructions conditionnelles, boucles et
affectations. Pour certains traitements il est donc nécessaire de coupler le langage SQL
avec un langage de programmation plus complet.
De manière synthétique, on peut dire que SQL est un langage relationnel, il
manipule donc des tables (i.e. des relations, c’est-à-dire des ensembles) par
l’intermédiaire de requêtes qui produisent également des tables.
Historique rapide
 En 1970, E.F. CODD, directeur de recherche du centre IBM de San José, invente
le modèle relationnel qui repose sur une algèbre relationnelle. Ce modèle
provoque une révolution dans l’approche des bases des données.
 En 1977, création du langage SEQUEL (Structured English Query Language) et
mise en place du Système R, prototype de base de données reposant sur la
 64

théorie de CODD. SEQUEL continue de s’enrichir pour devenir SQL (Structured

Query Language).
 En 1981, la société ORACLE CORP lance la première version de son système de
gestion de base de données relationnelle (SGBDR), IBM sort SQL/DS et RTI lance
INGRES.
 En 1982, IBM sort SQL/DS pour son environnement VM/CMS et l’ANSI (American
National Standard
Institute) lance un projet de normalisation d’un langage relationnel.
 En 1983, IBM lance DB2 pour l’environnement MVS.
 En 1986, la société SYBASE lance son SGBDR conçu selon le modèle Client-
Serveur.
 La première norme SQL (SQL-1) de l’ISO (International Standard Organisation)
apparaît. Il existe désormais plusieurs dizaines de produits proposant le langage
SQL et tournant sur des machines allant des micros aux gros systèmes.
 Depuis, les différents produits phares ont évolué, la norme SQL est passée à SQL-
2, puis SQL-3. SQL est désormais un langage incontournable pour tout SGBD
moderne. Par contre, bien qu’une norme existe, on assiste à une prolifération de
dialectes propres à chaque produit : soit des sous-ensembles de la norme
(certaines fonctionnalités n’étant pas implantées), soit des sur-ensembles (ajout
de certaines fonctionnalités, propres à chaque produit).
Oracle et Informix dominent le marché actuel, SQL-Server (de Microsoft) tente
de s’imposer dans le monde des PC sous NT. À côté de ces produits, très chers, existent
heureusement des systèmes libres et gratuits : MySQL et PostgreSQL sont les plus
connus.
Bien que ces SGBDR n’aient pas la puissance des produits commerciaux,
certains s’en approchent de plus en plus. Les différences notables concernent
principalement les environnements de développement qui sont de véritables ateliers
logiciels sous Oracle et qui sont réduits à des interfaces de programmation C, Python,
Perl sous PostgreSQL. Il en va de même pour les interfaces utilisateurs : il en existe pour
PostgreSQL, mais ils n’ont certainement pas la puissance de leurs équivalents
commerciaux.
 65

Le langage SQL est constitué de plusieurs langages, que l’on va voir en détails :

– un langage de définition de données,

– un langage de manipulation de données,
– un langage de contrôle de données,
– un langage de contrôle de transactions.

1. Langage de définition de données

C’est un ensemble de commandes qui permettent de créer les objets de la base.

1.1 Création d’une base

Il existe différentes méthodes pour créer une nouvelle base qui dépendent du
client utilisé. En SQL la commande est la suivante :
CREATE DATABASE polymorphisme
WITH OWNER = gallut
ENCODING = ’UTF8’;
Cette commande permet de créer une base « polymorphisme » dont le
propriétaire est « gallut » et dans laquelle les données seront encodées en « UTF8 ».
PostgreSQL peut gérer de nombreux encodages différents, pour le français les
encodages iso latin1 ou UTF8 permettent de prendre en compte les accents. Attention :
l’encodage par défaut dépend du serveur, généralement il s’agit de SQL_ASCII qui ne
permet pas l’utilisation de caractères accentués.
 66

1.2 Création d’une table

Pour créer une table, on utilise la commande CREATE TABLE. Il faut indiquer,
au minimum, le nom de la table, les noms des colonnes et le type de données de chacune
d’elles.
CREATE TABLE nom_table (nom_attribut_1 type_données_1,...,nom_attribut_n
type_données_n);
Chaque attribut prend la valeur NULL par défaut sauf si une valeur par défaut est
précisée. Par ailleurs il est possible, d’interdire la valeur NULL pour un attribut et de
rendre unique chaque valeur d’un attribut.
CREATE TABLE nom_table (nom_attribut_1 int DEFAULT 0, nom_attribut_2 varchar(10)
NOT NULL, nom_attribut_n text UNIQUE);
Les données peuvent êtres de différentes natures :
Entiers : 0 10, 3, 527, 19 etc.,
Réels : 3.67 3/7 3.14 etc.,
Chaînes de caractères : ’toto’ ’titi’ ’Gros minet’ etc.,
Date : ’2009-09-28’,
Heure : ’10h05’,
Booléens : Vrai Faux.
1.3 Création d’une contrainte
Une contrainte peut s’exercer sur un attribut ou sur une table. Une contrainte sur ne table
peut porter sur un ou plusieurs attribut contrairement à une contrainte sur un attribut qui
ne porte que sur ce dernier.
1.3.1 Clef primaire
Pour ajouter une clef primaire à une table, plusieurs syntaxes sont possibles :
CREATE TABLE nom_table (nom_attribut_1 int PRIMARY KEY, nom_attribut_2
varchar(10), nom_attribut_n text);
Dans ce cas il s’agit d’une contrainte d’attribut. Cette syntaxe ne permet pas de définir
une clef portant sur plusieurs attributs. D’autre part le nom de la contrainte n’est pas
précisé. La syntaxe suivante est préférable :
CREATE TABLE nom_table (nom_attribut_1 int, nom_attribut_2 varchar(10),
nom_attribut_n text, CONSTRAINT nom_contrainte PRIMARY KEY (liste_attributs));
 67

La contrainte de clef primaire nom_contrainte est un objet de la base. Il est

d’usage d’utiliser le nom de la table suivi de pkey : regions_pkey. La liste des attributs
représente la ou les colonnes qui constituent la clef primaire.
1.3.2. Clef étrangère
Pour ajouter une clef étrangère à une table lors de la création de la table :
CREATE TABLE nom_table (nom_attribut_1 int, nom_attribut_2 varchar(10),
nom_attribut_n text,CONSTRAINT nom_contrainte FOREIGN
KEY(liste_attributs_enfants)REFERENCES nom_table_parent
(liste_attributs_parents)MATCH FULL);
Il est d’usage d’utiliser le nom de la table ou des tables suivi de fkey. Le nombre et le type
des attributs des deux listes d’attributs qui se font référence doivent correspondre.
MATCH FULL permet de préciser comment se fait la correspondance entre les colonnes,
ici elle doit être complète.
Ces contraintes peuvent alternativement être créées en même temps que la table :
CREATE TABLE pays (nom_pays varchar(30) PRIMARY KEY, langue varchar(2), opulation
integer );

CREATE TABLE pays (nom_pays varchar(30), langue varchar(2), population integer,

CONSTRAINTE pays_pkey PRIMARY KEY (nom_pays));

CREATE TABLE villes (ville_id serial PRIMARY KEY, nom_ville varchar(50), nom_pays
varchar(30) REFERENCES pays);

CREATE TABLE villes (ville_id serial, nom_ville varchar(50), nom_pays varchar(30),

CONSTRAINTE villes_pkey PRIMARY KEY (ville_id), CONSTRAINT villes_pays_fkey
FOREIGN KEY (nom_pays) REFERENCES pays (nom_pays) MATCH FULL);
1.3.3. Contrainte de vérification
Une contrainte de vérification permet de s’assurer que les valeurs d’un attribut
sont bien comprises dans son domaine de valeurs :
CREATE TABLE etudiants (etudiant_id serial PRIMARY KEY, note integer
CONSTRAINT note_valide CHECK (note >= 0 AND note <= 20));
 68

1.4. Modification d’une table

Pour modifier une table on utilise la commande ALTER TABLE. Soit comme
précédemment pour ajouter une contrainte, soit pour ajouter ou supprimer un attribut. Il
est possible de modifier tous les éléments d’une table.
 Ajout d’une clef primaire :
ALTER TABLE nom_table ADD CONSTRAINT nom_contrainte PRIMARY KEY
(liste_attributs);
 Suppression d’une contrainte :
ALTER TABLE nom_table DROP CONSTRAINT nom_contrainte;
 Ajout d’un attribut :
ALTER TABLE nom_table ADD COLUMN nom_attribut type;
Toutes les options possibles à la création sont également possibles ici.
 Suppression d’un attribut :
ALTER TABLE nom_table DROP COLUMN nom_attribut;
Renommer une table ou un attribut :
RENAME TABLE Ancien_nom TO nouveau_nom_table;
ALTER TABLE nom_table CHANGE nom_attribut nouveau_nom_attribut;
 Modifier un attribut
Par exemple changer le type d’un attribut.
ALTER TABLE Nom_table MODIFY Nom_attribut nouveau_type_données ;
1.5 Destruction d’une table
Pour supprimer une table on utilise la commande DROP TABLE.
DROP TABLE nom_table;
1.6 Gestion des dépendances
Une table avec une contrainte de clef étrangère dépend de la table à laquelle elle
fait référence. Il est nécessaire de préciser le comportement que doit suivre le SGBD en
cas de modification ou suppression de la table parent. L’option CASCADE permet de
lever la contrainte de clef étrangère. Pour la modification et la suppression de données
dans la table parent les options suivantes permettent de définir le comportement :
 69

ALTER TABLE nom_table ADD CONSTRAINT nom_contrainte FOREIGN KEY

(liste_attributs) REFERENCES nom_table_parent (liste_attributs) ON UPDATE
CASCADE ON DELETE CASCADE;
L’option ’ON DELETE CASCADE’ entraîne la suppression des lignes de la table fille qui
font référence aux lignes supprimées dans la table parent.
L’option ’ON UPDATE CASCADE’ entraîne la modification de l’attribut clef étrangère de
la table fille lorsque l’attribut référencé de la table parent est modifié.

2 Langage de manipulation de données

La manipulation des données comprend la consultation des données, l’insertion et la

suppression de données et la mise à jour.
2.1 Consultation des données
La commande SELECT permet de retrouver les données selon différents critères à partir
d’une ou plusieurs tables. Voici la syntaxe générale :
SELECT liste_attributs FROM nom_table
WHERE condition_de_selection_de_lignes
GROUP BY liste_attributs
HAVING condition_de_selection_de_groupements
ORDER BY liste_attributs;
Requêtes d’un type simple :
SELECT * FROM nom_table;
Le caractère spécial * permet de prendre en compte tous les attributs de la table. Cette
requête renvoie toutes les lignes de la table.
Il est possible de donner des alias aux identifieurs pour faciliter l’écriture de la requête et
la lecture des résultats avec la clause AS :
SELECT nom AS "Nom étudiant" FROM etudiants AS e;
Une requête peut renvoyer plusieurs lignes identiques, pour éviter cela on utilise la clause
DISTINCT :
SELECT DISTINCT * FROM nom_table;
 70

Il est possible de préciser sur quels critères deux lignes sont considérées identiques, par
exemple, on peut considérer deux lignes comme identiques si elles ont les mêmes
valeurs pour un sous-ensemble de leurs attributs :
SELECT DISTINCT ON (attributs ) * FROM nom_table;
2.1.1 Opérateurs
En fonction du type de données il existe différents opérateurs pour manipuler les
données.
Opérateur Description
+ Addition
- soustraction
* multiplication
/ division (la division entière tronque les résultats)
% modulo (reste)
^ Exponentiel
|/ racine carrée
||/ racine cubique
! Factoriel
@ valeur absolue
ln(numerique) Logarithme
log(numerique) logarithme base 10
round(numerique) arrondi à l’entier le plus

Exemples d’utilisations :
SELECT 3 + 4;
SELECT note_cc + note_tp AS "Somme des notes" FROM etudiants;
Opérateurs de comparaison
Opérateur Description
< inférieur à
> supérieur à
<= inférieur ou égal à
>= supérieur ou égal à
= égal à
<> différent de

Opérateurs booléens
Opérateur Description
AND ET logique
OR OU logique
 71

NOT NON logique

AND ET logique
OR OU logique
NOT NON logique

2.1.2 Conditions de sélection

La clause WHERE permet de spécifier les lignes à sélectionner selon un critère particulier
:

SELECT * FROM etudiants WHERE nom = ’Dupont’;

Cette requête sélectionne toutes les lignes de la table etudiants pour lesquelles l’attribut

nom est égal à ’Dupont’.

SELECT * FROM etudiants WHERE note >= 15;

Cette requête sélectionne toutes les lignes de la table etudiants pour lesquelles l’attribut

note est supérieur ou égal à 15.

SELECT * FROM etudiants WHERE note IN (13, 14, 15 );

Cette requête sélectionne toutes les lignes de la table etudiants pour lesquelles l’attribut

note est égal à 13, 14 ou 15.

La clause LIKE permet d’avoir une correspondance partielle. Voici sa syntaxe :

SELECT * FROM nom_table WHERE chaîne LIKE motif;
SELECT * FROM nom_table WHERE chaîne NOT LIKE motif;
Un motif représente un ensemble de chaînes possibles, LIKE renvoie TRUE si chaîne
est contenu dans l’ensemble motif. Un tiret bas (_) dans motif correspond à n’importe
quel caractère, un signe pourcent (%) correspond à toutes les chaînes de zéro ou
plusieurs caractères. Si le motif ne contient ni signe pourcent ni tiret bas, LIKE agit
exactement comme l’opérateur d’égalité.
Quelques exemples :
’abc’ LIKE ’abc’ true
’abc’ LIKE ’a%’ true
’abc’ LIKE ’_ b_ ’ true
 72

’abc’ LIKE ’c’ false

2.1.3 Jointure
Une jointure relie deux tables entre elles. Il existe plusieurs types de jointures.
 Jointure croisée
La jointure croisée entre deux tables renvoie le produit cartésien de ces deux
tables.
Ce n’est pas très utile en pratique.
SELECT * FROM table1 CROSS JOIN table2;
 Jointures qualifiées
Une jointure qualifiée entre deux tables renvoie le sous ensemble du produit
cartésien de ces deux tables qui satisfait la condition de jointure. C’est avec une jointure
qualifiée que l’on joint deux tables qui se font référence avec un couple clef primaire / clef
étrangère. Il existe plusieurs sortes de jointures qualifiées :
– jointure interne,
– jointure externe gauche,
– jointure externe droite,
– jointure externe complète.
 Jointure interne
Pour chaque ligne de la table_1, le résultat contient une ligne pour chaque ligne de
table_2 qui satisfait la condition de jointure. Il y a plusieurs syntaxes :
SELECT * FROM table_1 AS T1 JOIN table_2 AS T2
ON T1.attribut_clef_P = T2.attribut_clef_E;
SELECT * FROM table_1 AS T1 INNER JOIN table_2 AS T2
ON T1.attribut_clef_P = T2.attribut_clef_E;
SELECT * FROM table_1 JOIN table_2
USING ( liste_attributs );
SELECT * FROM T1 NATURAL JOIN T2;

Ces syntaxes sont équivalentes lorsque les attributs qui se correspondent ont le même
nom dans les deux tables. La première forme permet de faire une jointure sur des attributs
qui ont des noms différents.
 Jointure externe
 73

Une jointure externe gauche est une jointure interne pour laquelle est ajoutée au
moins une ligne pour chaque ligne de la table de gauche. Ainsi pour chaque ligne de la
table de gauche qui ne satisfait pas la condition de jointure, une ligne
est ajoutée au résultat avec des valeurs NULL dans les colonnes de la table de droite. La
jointure a donc au moins une ligne pour chaque ligne de la table de gauche. La jointure
externe droite est l’inverse d’une jointure externe gauche. La jointure externe complète
est la combinaison des deux.
Syntaxe:
SELECT * FROM table_1 AS T1 LEFT JOIN table_2 AS T2
ON T1.attribut_clef_P = T2.attribut_clef_E;
SELECT * FROM table_1 AS T1 RIGHT OUTER JOIN table_2 AS T2
ON T1.attribut_clef_P = T2.attribut_clef_E;
SELECT * FROM table_1 AS T1 FULL OUTER JOIN table_2 AS T2
USING ( nom_attributs );
2.1.4 Agrégats
Une fois que les lignes ont été sélectionnées il est possible de faire des
regroupements en utilisant la clause GROUP BY, la clause HAVING permet de les filtrer
:
SELECT nom_attributs FROM T1 GROUP BY nom_attributs HAVING condition;
SELECT nom FROM etudiant GROUP BY nom;
Il est possible d’appliquer une fonction d’agrégat à un ensemble de valeurs pour
obtenir un résultat unique. Par exemple la somme des valeurs d’une colonne, la moyenne
des valeurs d’une colonne, le min ou le max.
SELECT nom, avg(note) FROM etudiant GROUP BY nom
HAVING avg(note) > 10;
Cette requête renvoie la moyenne des notes de chaque étudiant dont la moyenne est
supérieure à 10.
Fonction Type d’argument Description
avg(expression) Numérique la moyenne arithmétique de toutes les
valeurs en entrée
count(*) tout type nombre de lignes en entrée
 74

count(expression) tout type nombre de lignes en entrée pour lesquelles

l’expression n’est pas NULL
max(expression) tout type valeur maximale de l’expression pour
toutes les valeurs en entrée
min(expression) tout type valeur minimale de l’expression pour
toutes les valeurs en entrée
sum(expression) Numérique somme de l’expression pour toutes les
valeurs en entrée

2.1.5 Tri du résultat

Une fois que les lignes ont été sélectionnées il est possible de les trier. La clause
optionnelle
ORDER BY permet de spécifier le ou les attributs sur lesquels les lignes seront triées
ainsi que l’ordre du tri.
SELECT * FROM nom_table ORDER BY expression_tri [ASC | DESC];
SELECT * FROM etudiants ORDER BY nom, notes_cc;
SELECT * FROM etudiants WHERE note_cc >= 10 ORDER BY nom DESC;
2.1.6 Limitation du nombre de lignes
LIMIT et OFFSET permettent de limiter le nombre de lignes renvoyées par la requête,
LIMIT permet de spécifier le nombre de lignes et OFFSET permet de spécifier le nombre
des premières lignes qui seront omises :
SELECT * FROM nom_table [LIMIT { nombre | ALL } ] [OFFSET nombre]
SELECT * FROM personnes LIMIT 10;
Renvoie les 10 premières lignes.
SELECT * FROM personnes OFFSET 10;
Renvoie à partir de la 11e ligne.
2.1.7 Combiner des requêtes
Il est possible de combiner deux requêtes avec les opérations d’ensemble : union,
intersection et différence. Pour pouvoir être combinées, les deux requêtes doivent
renvoyer le même nombre de colonnes et les colonnes correspondantes doivent avoir
des types de données compatibles.
 75

L’union ajoute le résultat de requete_2 au résultat de requete_1, les lignes

dupliquées sont éliminées sauf si UNION ALL est utilisé : requete_1 UNION [ALL]
requete_2;
L’intersection renvoie toutes les lignes qui sont à la fois dans le résultat de
requete_1 et dans le résultat de requete_2. Les lignes dupliquées sont éliminées sauf si
on utilise INTERSECT ALL: requete_1 INTERSECT [ALL] requete_2;
La différence renvoie toutes les lignes qui sont dans le résultat de requete_1
mais pas dans le résultat de requete_2. Les lignes dupliquées sont éliminées sauf si
EXCEPT ALL est utilisé : requete_1 EXCEPT [ALL] requete_2;
Ces différentes opérations peuvent être utilisées conjointement.
2.2 Insertion de données
Pour entrer des données dans une table on utilise la commande INSERT INTO :
INSERT INTO nom_table VALUES ( valeur_1, ... valeur_n );
Le nombre de valeurs de la clause VALUES et l’ordre des valeurs doit correspondre aux
attributs de la table. Sinon il faut préciser la liste des attributs pour lesquels des données
sont fournies :
INSERT INTO nom_table ( attribut_1, ... attribut_n ) VALUES ( valeur_1, ... valeur_n );
Une table peut être remplie à partir du résultat d’une requête :
INSERT INTO nom_table SELECT DISTINCT nom_attributs FROM nom_table_2;
2.3 Mise à jour de données
Il est possible de mettre à jour une ligne spécifique, toutes les lignes ou un sous-
ensemble de lignes de la table. Chaque colonne peut être actualisée séparément.
UPDATE nom_table SET nom_attribut = valeur WHERE condition;
2.4 Suppression de données
La suppression touche une ou plusieurs lignes qui remplissent une condition :
DELETE FROM nom_table ;
 76

NOTES BIBLIOGRAPHIQUES

- CORONEL C., MORRIS S. et ROB P. (2012), Database Systems: Design,

Implementation, and Management, Cengage Learning.
- Daniel Martin. (1981), Bases de données : méthodes pratiques sur maxi et mini-
ordinateurs, Paris, Dunod.
- Delphi; Hamani, Berti. (2010.) Les bases de données sous Access ; Paris.
- Gardarin G, Eyrolles. (20013) Base de données réparties, Paris.
- P. Boursier Cours Bases de Données – UPF – Février 2002
- P.S. Gill. (2008), Database Management Systems, I. K. International Pvt Ltd
- Philippe M. (2016) Les bases de données à l’Internet, Paris.
- Hainaut J-L (1994), Bases de données et modèles de calcul, Paris, Dunod
 77

TABLE DES MATIERES

CONTRAT PEDAGOGIQUE

........................................................................................................................................ 1
Chapitre 1. Introduction aux bases de données ......................................................... 4
Objectifs : ................................................................................................................... 4
1.1. Historique ......................................................................................................... 4
1.2. Notions de base de données .............................................................................. 7
1.2.1. Base de données.............................................................................................. 7
1.2.2. Base de données informatisée ....................................................................... 7
1.3. Modèle de la base de données ........................................................................... 8
1.3.1. Modèle hiérarchique ........................................................................................ 8
1.3.2. Modèle réseau .................................................................................................. 9
1.3.3. Modèle relationnel............................................................................................ 9
1.3.4. Modèle objet ................................................................................................... 10
1.4. Système de Gestion de Base de Données (SGBD) ..................................... 10
1. Introduction ....................................................................................................... 10
Définition d'un SGBD ............................................................................................... 10
Structure d'un SGBD ............................................................................................... 10
Les fonctions d'un SGBD ........................................................................................ 10
La définition des données ....................................................................................... 10
La manipulation des données................................................................................. 10
L'intégrité des données ........................................................................................... 11
La gestion des accès concurrents ......................................................................... 11
La confidentialité ..................................................................................................... 11
La sécurité de fonctionnement ............................................................................... 11
2. Les principaux SGBD ........................................................................................ 11
3. Cycles de développement des bases de données ......................................... 12
4. Intervenants du domaine BD ............................................................................ 12
5. Principes de fonctionnement............................................................................... 12
5.1.1. Objectifs .......................................................................................................... 13
5.1.2. Niveaux de description des données ANSI/SPARC .................................... 14
Chapitre 2. Conception des bases de données : le modèle entités-associations . 16
 78

Objectif :....................................................................................................................... 16
2.1. Introduction .......................................................................................................... 16
2.1.1. Pourquoi une modélisation préalable ? .......................................................... 16
2.1.2. Merise ................................................................................................................. 16
2.1.3. Eléments constitutifs du modèle entités-associations .................................. 18
2.4. Compléments sur les associations .................................................................... 22
2.4.1. Association plurielles ....................................................................................... 23
2.4.2. Association réflexive ........................................................................................ 23
2.4.3. Association n-aire (n>2).................................................................................... 24
Décomposition d’une association n-aire .................................................................. 25
2.4.4. Règles de bonne formation d’un modèle entités-associations ..................... 28
1. Règles portant sur les noms : ............................................................................. 29
2. Règles de normalisation des attributs ................................................................ 30
3. Règles de fusion/suppression d’entités/associations ...................................... 32
4. Normalisation des type-entités et type-associations ........................................ 36
4. Élaboration d’un modèle entités-associations ..................................................... 40
5.1. Étapes de conceptions d’un modèle entités-associations .............................. 40
5. Conseils divers ..................................................................................................... 42
Chapitre 3. Bases de données relationnelles ........................................................... 44
Objectifs :..................................................................................................................... 44
3.1. Introduction au modèle relationnel..................................................................... 44
3.1.1 Présentation........................................................................................................ 44
3.1.2 Éléments du modèle relationnel ....................................................................... 45
3.1.3 Passage du modèle entités-associations au modèle relationnel ................... 46
3.2 Normalisation ........................................................................................................ 49
3.2.2 Dépendance fonctionnelle (DF)......................................................................... 51
3.2.3 Première et deuxième forme normale .............................................................. 52
3.2.4 Troisième forme normale .................................................................................. 53
3.2.5 Forme normale de BOYCE-CODD ..................................................................... 54
3.3. Algèbre relationnelle ............................................................................................ 55
3.4.1 Introduction ........................................................................................................ 55
3.4.2 Sélection ............................................................................................................. 56
 79

3.4.3 Projection ............................................................................................................ 56

3.4.4 Union ................................................................................................................... 57
3.4.5 Intersection ......................................................................................................... 58
3.4.7 Produit cartésien ................................................................................................ 59
3.4.8 Jointure, thêta-jointure, équijointure, jointure naturelle ................................. 60
Chapitre 4. Notions sur le langage SQL .................................................................... 63
Objectif :....................................................................................................................... 63
4.1.1 Présentation générale ........................................................................................ 63
1. Langage de définition de données ...................................................................... 65
2 Langage de manipulation de données ................................................................... 69
NOTES BIBLIOGRAPHIQUES ..................................................................................... 76