INF221 2023-2024 Physique

INF221 - Base de Données
Filière Physique
Etienne Kouokam, PhD

etienne.kouokam@facsciences-uy1.cm
3 octobre 2023
Année académique 2023-2024

Table des matières
Informations générales v
I Conception des Bases de Données 1
1 Introduction : Du Systèmes d’Information (SI) à la Base de Données (BD) 3
Introduction 3
1.1 Quelques définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Les composants d’une Base de Données relationnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Objectifs et propriétés d’un SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Que doit-on savoir pour utiliser un SGBD ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Définition du schéma de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.2 Les opérations sur les données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.3 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.4 Concurrence d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Plan du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Démarche et méthode de modélisation des données 11

2.1 Démarche de modélisation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Le groupe d’étude (angl. Project group) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Les étapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Les sources d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Méthode de modélisation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Pourquoi modéliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Le modèle conceptuel des données (MCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 Avantage et inconvénients du modèle E/A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Le modèle logique de données (MLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 Règles de transformation du MCD au MLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Le modèle physique de données (MPD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.1 Passage du MLD au MPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.2 Les contraintes d’intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.3 Exercices-TDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Théorie de la normalisation et Algèbre relationnelle 43

3.1 Les dépendances fonctionnelles & Normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.1 Les dépendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.2 Propriétés des dépendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.3 Théorie de la normalisation relationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 L’algèbre relationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.1 La sélection, σ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.2 La projection, π . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.3 Le produit cartésien, × . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.4 L’union, ∪ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.5 La différence, ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
ii
3.2.6 La jointure, ./ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.7 Expression de requêtes avec l’algèbre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4 Les systèmes de gestion de bases de données 55

4.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Un peu d’histoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3 Les composants d’une base de données relationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 Structures physiques et logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.1 Structures physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.2 Structures logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.3 Relation entre structure physique et structure logique . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5 Les réseaux informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.1 L’approche Client/Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5 Les tables 65
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.1 Les champs d’une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.1.2 Clé primaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.3 Relations entre tables - clé étrangère . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1.4 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2 Utilisation d’un outil de modélisation : WinDesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2.2 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2.3 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6 Les requêtes 75
6.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Introduction au langage SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.2 Syntaxe SQL de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2.3 Les critères de sélection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.2.4 Comparaison à un filtre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2.5 Les opérateurs logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
II Implémentation des Bases de Données 83
7 Création du schéma relationnel 87

7.1 Création de table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.2 Création des relations sous MS ACCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8 Les requêtes : Concepts théoriques et pratiques 95

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.2 Introduction au langage SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.2.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.2.2 Les critères de sélection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8.2.3 Comparaison à un filtre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
8.3 Création de requêtes QBE (Query By Example) en pratique . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.3.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.3.2 Création proprement dite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.3.3 Définition des critères de sélection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.3.4 Plusieurs critères portant sur des champs différents . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.3.5 Requête paramétrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.3.6 Les requêtes Multi-tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.3.7 Les fonctions de regroupement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.3.8 Les Requêtes d’Analyse Croisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.3.9 Les Requêtes Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
iii
9 Création des formulaires sous MS Access 109
9.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.2 Créer un formulaire à partir d’une table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.3 Les contrôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.3.1 Le contrôle ”Etiquette” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
9.3.2 Le contrôle ”Zone de Texte” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
9.3.3 Le contrôle ”Sous-Formulaire” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Table des figures 117
Liste des tableaux 119
Index 119
Informations générales
Ce cours s’adresse aux étudiants de 2ème année de la filière Physique à l’Université de Yaoundé I et a pour objectif
l’étude des principes des SGBD relationnels et la mise en pratique de ces principes. Le contenu du cours est essentiellement
le suivant :
Conception d’un schéma relationnel : Il s’agit de savoir définir un schéma relationnel complet et correct, comprenant des
tables, des contraintes, des vues.
Langages d’interrogation et de manipulation : L’accent est mis sur SQL et ses fondements.
Cependant, le cours ne s’intéresse pas aux problèmes de concurrence d’accès, dont la connaissance est nécessaire aux
développeurs d’applications basées sur des SGBD. Des travaux pratiques avec le SGBD MS Access permettent de mettre
en ?uvre les techniques étudiées en cours.
L’accent est donc plutôt mis sur les notions de base (ce qu’est un SGBD, une base de données, un langage d’interroga-
tion) et leur application pratique. Il est demandé d’avoir acquis à la fin du cours les connaissances nécessaires à l’utilisation
d’un SGBD par un informaticien non-spécialiste. : création d’un schéma, insertion, mise à jour, destruction, et interroga-
tion de données dans la gestion d’un SGBD. En revanche, tout ce qui relève de la compréhension des mécanismes internes
d’un SGBD (représentation physique, évaluation de requêtes) ou des fondements théoriques du modèle relationnel n’est pas
abordé ici.
Ce document est un support de cours : il ne prétend certainement pas être exhaustif ni traiter en détail tous les sujets abordés.
L’assistance au cours proprement dit, ainsi qu’aux travaux dirigés et aux travaux pratiques est fortement recommandée.
La structure et le contenu des chapitres de ce document ont été synchronisés avec le contenu du programme établi par
le département de Physique de l’Université de Yaoundé I.
Pour ceux qui veulent en savoir plus, il existe une riche bibliographie dont voici quelques éléments recommandables :
Nous aurons une demi-douzaine de séances de cours ainsi réparties (à titre indicatif) :
Partie 1 : Modélisation d’un système d’information : Analyse et Structuration des données (chapitres 1 à 6)
Séance 1 : Des SI (Systèmes d’Indformation) aux Base de données

Séance 2 : Les objectifs des Bases de Données
Séance 3 : Méthodologie de conception des Bases de Données
Séance 4 : Algèbre relationnelle et Normalisation
Séance 5 : Interrogation des Bases de Données
Séance 6 : Conclusion
Partie 2 : Implémentation des bases de Données, par vous-mêmes.

vi
Compétences visées
1. Etre capable de concevoir soi-même un modèle conceptuel à partir d’un énoncé
2. Être capable de passer d’un modèle à un autre (du schéma conceptuel au schéma relationnel ou du modèle logique au
modèle physique) ou vice versa
3. Etre capable de critiquer sérieusement un modèle proposé dans le cadre de l’informatisation d’un Système d’Informa-
tion
4. Être capable de normaliser des relations dans une base de données
5. Etre capable d’écrire des requêtes SQL, QBE et même pouvoir en dériver le calcul relationnel en s’aidant des opérations
vues en algèbre relationnelle.
6. Etre capable de se servir d’un atelier de Génie Logiciel tel que Win’Design (TP)
Ouvrages :
1. Carrez C., Des Structures aux Bases de Données, Masson
2. Ullman J.D., Principles of Database and Knowledge-Base Systems, 2 volumes, Computer Science Press
3. Gardarin G., Maı̂triser les Bases de Données : modèles et langages, Eyrolles
4. Date C.J., An Introduction to Database Systems, Addison-Wesley
5. Marcenac, P., SGBD relationnels, Optimisation des performances, Eyrolles.
6. Melton J. et A.R. Simon, Understanding SQL, A Complete Guide, Morgan Kaufmann, 1993.
Première partie
Conception des Bases de Données

Chapitre 1
Introduction : Du Systèmes d’Information (SI) à la

Base de Données (BD)
La compétitivité d’une entreprise ainsi que sa valeur sur le marché sont déterminées par plusieurs éléments, d’une
importance différente selon le secteur d’activité. On peut généralement regrouper ces éléments en deux classes :
1. Les éléments matériels
• L’infrastructure
• Les supports financiers
2. Les éléments intellectuels
• La compétence des employés

• La motivation des employés
• Le recueil et l’exploitation optimale des informations utiles
Depuis quelques années, les responsables des entreprises (banques, assurances, industrie etc. ) ont davantage reconnu et
admis que la gestion et l’exploitation des informations sont un facteur de compétitivité à ne pas négliger.
Le développement rapide de l’informatique a donné aux entreprises la possibilité d’utiliser des moyens avancés et puis-
sants pour gérer et exploiter de très grands volumes de données. Il y a quelques années, le domaine de la gestion informatique
des données était réservé aux informaticiens. Actuellement, les tendances à l’intérieur des entreprises ont changé de façon
à ce que tous les employés soient de plus en plus impliqués dans les différents procédés liés à la gestion et l’exploitation
des données. De cette façon, un certain niveau de connaissance des principes et des outils standards de l’informatique est
aujourd’hui requis pour la plupart des postes disponibles dans les entreprises.
Toutefois, il ne suffit pas d’utiliser les ressources informatiques les plus sophistiquées pour exploiter au mieux les
données. En parallèle avec les outils informatiques utiles pour gérer des données, tels que les ordinateurs de plus en plus
puissants et les logiciels adaptés (SGBD, Tableur etc.), ont été développées des méthodes d’analyse et de conception de
systèmes d’information. Ces méthodes nous offrent la possibilité d’analyser un système d’information naturel (par exemple
la gestion des livres d’une librairie ou la gestion des sinistres d’une compagnie d’assurances), de concevoir ensuite un modèle
qui représente ce système et d’implémenter finalement un système informatique, basé sur ce modèle.
1.1 Quelques définitions

Définition 1. Une information ou donnée est un élément qui permet de compléter notre connaissance sur une personne, un
objet, un événement. Elle est donc quelconque. C’est aussi une relation entre des informations : Des relations de ce genre
définissent des structures. . . .
Exemple 1.
Le nom d’une personne est une information concernant cette personne.
La couleur d’une voiture est une information concernant cette voiture.
Etienne enseigne les bases de données.
Des relations de ce genre définissent des structures.
4
F IGURE 1.1 – Un modèle générique pour les SI
Définition 2. Le système d’information regroupe l’ensemble des ressources permettant de gérer (saisir, stocker, traiter,
restituer, transmettre) toutes les informations utiles aux décideurs et aux opérationnels.
Exemple 2.
Toutes les informations relatives à la gestion d’une librairie constituent le système d’information de cette librairie. Ce système
peut couvrir le simple stockage des livres, mais également la gestion des commandes, des ventes et même des clients.
Un système d’information ne doit pas nécessairement être informatisé. Bien que la plupart des systèmes actuels se basent
sur la technologie de l’informatique, il existe encore des systèmes d’information où l’information est stockée, manipulée et
communiquée à l’aide de moyens ”traditionnels” tels que les armoires, les classeurs, les calculatrices, les fiches sur papier
...
Le système d’information ne doit pas être confondu avec le système informatique qui lui, est constitué d’éléments
matériels et/ou logiciels (ordinateurs, programmes, structures de données, . . . )
Bien que les deux termes ”informations” et ”données” soient souvent utilisés comme synonymes, il existe une différence
subtile entre eux.
Exemple 3.
Dans une librairie, un client demande au vendeur si le livre ”L’étranger” (Albert Camus) est disponible en stock. Le vendeur
conseille la base de données de la librairie à l’aide de son ordinateur et confirme au client que le livre est disponible. Le
vendeur a donc donné au client l’information que le livre est en stock. Afin de pouvoir donner cette information, le vendeur
a du consulter les données qui représentent le stock de la librairie. Le fait de consulter le stock constitue un traitement sur
les données du stock.
L’image de la Figure 1.1 en est un modèle générique.
On peut donc dire qu’un système d’information contient les données et les traitements nécessaires pour assimiler et
stocker les informations en entrée et produire les informations en sortie.
Exemple 4.
Le propriétaire d’une vidéothèque reçoit une livraison avec des nouvelles cassettes vidéo. Pour chaque cassette vidéo, il lit
le titre, la langue et la durée et sauvegarde ces informations dans la base de données de la vidéothèque. Il a donc utilisé un
traitement d’ajout de données afin de transformer les informations en entrée (titre, langue, durée) en données.
Les données d’un système d’information peuvent être stockées et manipulées à l’aide d’un outil informatique spécialisé
dans ce domaine. Actuellement les Systèmes de Gestion de Bases de Données (SGBD) constituent le type de logiciel le
mieux adapté pour implémenter la plupart des systèmes d’information.
C’est donc un ensemble, en général volumineux, de telles informations, avec une caractéristique essentielle : on souhaite les
mémoriser de manière permanente. D’où la définition :
Définition 3. Une Base de Données (BD) peut être considérée comme un ensemble structuré de données, centralisées ou
non, servant pour les besoins d’une ou plusieurs applications, interrogeables et modifiables par un groupe d’utilisateurs en
un temps opportun.
Plus formellement, une BD est un ensemble d’informations exhaustives, non redondantes, structurées et persistantes, concer-
nant un sujet.
Définition 4. La gestion ici est considérée comme l’action ou la manière de gérer, d’administrer, de diriger, d’organiser
quelque chose (une entreprise ou organisation dans notre cas)
Définition 5. Un Système de Gestion de Base de Données (SGBD) peut être défini comme un ensemble de logiciels prenant
en charge la structuration, le stockage, la mise à jour et la maintenance des données. Autrement dit, il permet de créer,
décrire, modifier, interroger et administrer les données. C’est, en fait, l’interface entre la base de données et les utilisateurs
(qui ne sont pas forcément informaticiens).
Exemple 5.
MS Access, Oracle, MySQL, SQL server, Postgre SQL . . .
5
F IGURE 1.2 – BD du personnel
F IGURE 1.3 – Résultat d’une requête
1.2 Les composants d’une Base de Données relationnelles

Une base de données relationnelle contient en général quatre types de composants (ou d’objets). Nous allons brièvement
introduire ces types d’objets sans aller trop dans les détails. A chacun de ces objets sera consacré un chapitre séparé.
a. Les tables dans lesquelles sont stockées les données. Une table peut être comparée à une liste, qui contient des enregis-
trements relatifs à un domaine bien défini.
Exemple 6.
Le service du personnel de l’entreprise SCHAFFGAER SARl. entretient une BD avec en outre une table pour les
données des employées. Cette table contient un enregistrement pour chaque employé, avec le nom, le prénom, l’adresse,
la localité, la date de naissance, la date d’entrée en service, le salaire mensuel et le nom du département auquel l’em-
ployé est actuellement affecté. Voire Figure 1.2
b. Les requêtes qui correspondent dans un certain sens aux ”questions” qu’on pose au SGBD. Le résultat à une requête
correspond bien souvent à un sous-ensemble d’une ou de plusieurs tables.
Exemple 7.
Le chef du personnel de l’entreprise SCHAFFGAER SARL. désire connaı̂tre les noms, prénoms, adresses et localités
des employés recrutés en 1996. Il doit formuler une requête qui sera exécutée par le SGBD, et qui donnera comme
résultat une liste semblable à la table des employés, mais contenant uniquement les employés qui vérifient le critère
de sélection de la requête, et pour chacun de ces employés seulement les informations demandées. Voire Figure 1.3
c. Les formulaires sont utilisés pour ajouter, modifier ou supprimer des données dans les tables. Bien que la plupart des
SGBD nous permettent d’accéder aux données directement dans les tables, les formulaires nous offrent certains avan-
tages en ce qui concerne la facilité d’utilisation, mais également la sécurité des données.
Exemple 8.
La secrétaire du chef du personnel utilise un formulaire pour ajouter ou supprimer un employé de la BD. Ce formulaire
lui permet également de modifier les données d’un employé. Voire Figure 1.4
d. Il arrive souvent qu’on veuille imprimer des statistiques concernant certaines données d’une BD. C’est alors qu’inter-
viennent les rapports ou états. Les rapports sont similaires aux formulaires, à la différence près, qu’ils sont uniquement
destinés à être imprimés et qu’il n’y a pas de dialogue interactif avec l’utilisateur. Un rapport se base généralement sur
une ou plusieurs tables ou bien le résultat d’une requête.
Exemple 9.
A la fin de chaque mois le chef du personnel reçoit un rapport avec pour chaque département, la liste des employés,
leur salaire mensuel ainsi que le salaire mensuel total payé par département. Voire Figure 1.5
6
F IGURE 1.4 – Un formulaire
F IGURE 1.5 – Etat de paiement mensuel par département

7
1.3 Objectifs et propriétés d’un SGBD
Un SGBD doit résoudre certains problèmes et répondre à des besoins précis :
• Indépendance physique : la façon de définir les données doit être indépendante des structures utilisées pour leur
stockage
• Indépendance logique : un utilisateur doit pouvoir percevoir seulement la partie des données qui l’intéresse (c’est ce
que l’on appelle une vue) et modifier la structure de celle-ci sans remettre en cause la majorité des applications
• Manipulation aisée des données par des non informaticiens, ce qui suppose des langages ”naturels”
• Accès efficaces aux données et obtention de résultats aux interrogations en un temps ”acceptable”
• Administration centralisée des données pour faciliter l’évolution de leur structure
• Non-redondance : chaque donnée ne doit être présente qu’une seule fois dans la base afin d’éviter les problèmes lors
des mises à jour
• Cohérence (ou intégrité) : les données ne doivent présenter ni ambiguı̈té, ni incohérence, pour pouvoir délivrer sans
erreur les informations désirées. Cela suppose un mécanisme de vérification lors de l’insertion, de la modification ou
de la suppression de données
• Partage des données pour un accès multi-utilisateur simultané aux mêmes données. Il faut entre autre assurer un
résultat d’interrogation cohérent pour un utilisateur consultant une base pendant qu’un autre la modifie
• Sécurité des données : robustesse vis-à-vis des pannes (il faut pouvoir retrouver une base ”saine” encas de plantage au
cours de modifications) et protection par des droits contre les accès non autorisés
Des objectifs cités ci-dessus découlent les propriétés fondamentales d’un SGBDr :
• Base formelle reposant sur des principes parfaitement définis
• Organisation structurée des données dans des tables interconnectées (d’où le qualificatif relationnelles), pour pouvoir
détecter les dépendances et redondances des informations
• Implémentation d’un langage relationnel ensembliste permettant à l’utilisateur de décrire aisément les interrogations
et manipulation qu’il souhaite effectuer sur les données
• Indépendance des données vis-à-vis des programmes applicatifs (dissociation entre la partie ”stockage de données” et
la partie ”gestion” - ou ”manipulation”)
• Gestion des opérations concurrentes pour permettre un accès multi-utilisateur sans conflit
• Gestion de l’intégrité des données, de leur protection contre les pannes et les accès illicites
1.4 Que doit-on savoir pour utiliser un SGBD ?

L’utilisation d’un SGBD suppose de comprendre (et donc de savoir utiliser) les fonctionnalités suivantes :
1. Définition du schéma de données en utilisant les modèles de données du SGBD.
2. Opérations sur les données : recherche, mises-à-jour, etc.
3. Partager les données entre plusieurs utilisateurs. (Mécanisme de transaction).
4. Optimiser les performances, par le réglage de l’organisation physique des données. Cet aspect relève plutôt de l’admi-
nistration et ne sera évoqué que dans l’introduction.
Reprenons dans l’ordre ces différents points.

8
1.4.1 Définition du schéma de données
Un schéma est simplement la description des données contenues dans la base. Cette description est conforme à un modèle
de données qui propose des outils de description (structures, contraintes et opérations). En fait, dans un SGBD, il existe plu-
sieurs modèles plus ou moins abstraits des mêmes objets, Exemple 10.
• Le modèle conceptuel : la description du système d’information
• Le modèle logique : interface avec le SGBD
• Le modèle physique : fichiers.
Ces différents modèles correspondent aux niveaux dans l’architecture d’un SGBD. Prenons l’exemple du modèle concep-
tuel le plus courant : le modèle Entité/Association. C’est essentiellement une description très abstraite qui présente les avan-
tages suivants :
• l’analyse du monde réel
• la conception du système d’information
• la communication entre différents acteurs de l’entreprise
En revanche, il ne propose pas d’opérations. Or définir des structures sans disposer d’opérations pour agir sur les données
stockées dans ces structures ne présente pas d’intérêt pratique pour un SGBD. D’où, à un niveau inférieur, des modèles
dits ?logiques ? qui proposent :
1. Un langage de définition de données (LDD) pour décrire la structure, incluant des contraintes.
2. Un langage de manipulation de données (LMD) pour appliquer des opérations aux données.
Ces langages sont abstraits : le LDD est indépendant de la représentation physique des données, et le LMD est indépendant
de l’implantation des opérations. On peut citer une troisième caractéristique : oute les structures et les opérations, un modèle
logique doit permettre d’exprimer des contraintes d’intégrité sur les données.
Exemple 11.
nom character 15, not null;

âge integer between 0 and 120;
débit = crédit;
...
Bien entendu, le SGBD doit être capable de garantir le respect de ces contraintes. Quand on conçoit une application
pour une BD, on tient compte (plus ou moins consciemment) de cette architecture en plusieurs niveaux. Typiquement : (1)
On décide la structure logique, (2) on décide la structure physique, (3) on écrit les programmes d’application en utilisant la
structure logique, enfin (4) Le SGBD se charge de transcrire les commandes du LMD en instructions appropriées appliquées
à la représentation physique.
Cette aproche offre de très grands avantages qu’il est important de souligner. Tout d’abord elle ouvre l’utilisation des SGBD
à de utilisateurs non-experts : les langages proposés par les modèles logiques sont plus simples, et donc plus accessibles,
que les outils de gestion de fichiers. Ensuite, on obtient une caractéristique essentielle : l’indépendance physique. On peut
modifier l’implantation physique sans modifier les programmes d’application. Un concept voisin est celui d’indépendance
logique : on peut modifier les programmes d’application sans toucher à l’implantation.
Enfin le SGBD décharge l’utilisateur, et en grande partie l’administrateur, de la lourde tâche de contrôler la sécurité et
l’intégrité des données.
9
1.4.2 Les opérations sur les données
Il existe 4 opérations classiques (ou requêtes) :
1. La création (ou insertion).
2. La modification (ou mise-à-jour).
3. La destruction.
4. La recherche.
Ces opérations correspondent à des commandes du LMD. La plus complexe est la recherche en raison de la variété des
critères.
Pour l’utilisateur, une bonne requête a les caractéristiques suivantes. Tout d’abord elle s’exprime facilement : l’idéal serait
de pouvoir utiliser le langage naturel, mais celui-ci présente trop d’ambiguités. Ensuite le langage ne devrait pas demander
d’expertise technique (syntaxe compliquée, structures de données, implantation particulière ...). Il est également souhaitable
de ne pas attendre trop longtemps (à charge pour le SGBD de fournir des performances acceptables). Enfin , et peut-être
surtout, la réponse doit être fiable.
Une bonne partie du travail sur les SGBD consiste à satisfaire ces besoins. Le résultat est ce que l’on appelle un langage de
requêtes, et constitue à la fois un sujet majeur d’étude et une caractéristique essentielle de chaque SGBD. Le langage le plus
répandu à l’heure actuelle est SQL.
1.4.3 Optimisation
L’optimisation (d’une requête) s’appuie sur l’organisation physique des données. Les principaux types d’organisation
sont les fichiers séquentiels, les index (denses. secondaires, arbres B) et le regroupement des données par hachage.
Un module particulier du SGBD, l’optimiseur, tient compte de cette organisation et des caractéristiques de la requête pour
choisir le meilleur séquencement des opérations.
1.4.4 Concurrence d’accès

Plusieurs utilisateurs doivent pouvoir accéder en même temps aux mêmes données. Le SGBD doit savoir :
• Gérer les conflits si les deux font des mises-à-jour.
• Offrir un mécanisme de retour en arrière si on décide d’annuler des modifications en cours.
• Donner une image cohérente des données si l’un fait des requêtes et l’autre des mises-à-jour.
Le but : éviter les blocages, tout en empêchant des modifications anarchiques.
1.5 Plan du cours

Le cours comprend trois parties consacrées successivement à la conception d’une base de données relationnelles, aux
langages de requêtes relationnels, enfin à la pratique d’un SGBD relationnel.
1. La première partie présente dans ses grandes lignes les principes fondamentaux du modèle relationnel c’est-à-dire l’ana-
lyse et la structure des données en focalisant sur la construction du modèle de données, et en détaillant comment le
modèle entité-association permet d’obtenir un premier schéma relationnel et comment ce dernier est normalisé pour
obtenir une base cohérente.
2. La deuxième partie s’intéresse aux langages de requêtes relationnels. Ici, les langages d’interrogation et de manipulation
de données suivants sont présentés : l’algèbre relationnelle qui fournit un petit ensemble d’opérateurs permettant
d’exprimer des requêtes complexes et le langage SQL, norme SQL2.
Chapitre 2
Démarche et méthode de modélisation des données
2.1 Démarche de modélisation des données
2.1.1 Le groupe d’étude (angl. Project group)
Un système d’information qui n’est pas trop complexe et volumineux en terme d’informations, peut facilement être in-
formatisé par une seule personne, qui ne doit pas nécessairement être un informaticien. Il suffit d’être un peu familiarisé avec
une méthode de modélisation, et de savoir manipuler un SGBD pour réaliser une implémentation informatique, cohérente et
fonctionnelle, d’un tel système d’information.
Dès que le système d’information atteint une certaine envergure (exemple : informatiser la gestion des sinistres d’une
compagnie d’assurances), un groupe d’étude est généralement créé.
Ce groupe ne devra en aucun cas contenir seulement des informaticiens mais également :
• Un ou plusieurs représentants des futurs utilisateurs du système informatisé (Par exemple : Un employé du service qui
gère les sinistres) ;
• Un ou plusieurs représentants de chaque département impliqué (exemple : Un employé du service des contrats ) ;
• Un représentant de la direction.
Généralement, un responsable du groupe (Project Manager) est nommé, afin de coordonner les travaux effectués par le
groupe et de suivre le déroulement à partir de l’analyse jusqu’à la mise en place du système informatisé.
2.1.2 Les étapes
Chaque projet d’informatisation, qu’il soit exécuté par une seule personne, ou géré par un groupe d’étude, prévoit plu-
sieurs étapes.
En général, nous avons les étapes suivantes :
1. Analyse de la situation existante et des besoins

12
2. Création d’une série de modèles qui permettent de représenter tous les aspects importants
3. A partir des modèles, implémentation d’une base de données
2.1.3 Les sources d’information

La première étape de chaque projet est donc l’analyse de l’existant et des besoins. Afin de pouvoir réaliser une analyse
correcte sur laquelle on peut baser la suite du projet, il faut d’abord identifier les sources d’information, et puis collectionner
13
exactement les informations importantes pour le projet.
Sources d’information primaires :
• L’interview avec les utilisateurs ;
• L’étude de documents provenant du système d’information actuel (Rapports, Bons de commandes, Facture. . . ).
Pour les projets d’une certaine envergure s’ajoutent :
• L’interview avec les responsables des services impliqués ;
• Pourvu que la tâche d’analyse soit partagée entre plusieurs membres du groupe d’études, il faut coordonner les actions
et comparer les résultats avec les autres membres.
Pour les projets qui se basent sur un système déjà partiellement informatisé s’ajoute :
• L’étude de l’application informatique existante.
2.2 Méthode de modélisation des données

Nous avons vu que la démarche classique d’un projet informatique comprend les étapes suivantes :
1. Analyse de la situation existante et des besoins ;
2. Création d’une série de modèles, qui permettent de représenter tous les aspects importants ;
3. A partir des modèles, implémentation d’une base de données.
En ce qui concerne la première étape, nous n’allons pas introduire de vraies règles, mais simplement utiliser nos connais-
sances de gestion d’une entreprise, notre esprit ouvert et même notre fantaisie pour analyser correctement la situation exis-
tante et les besoins des utilisateurs. Le résultat de l’analyse est généralement un ou plusieurs documents, qui contiennent les
indications principales sur le fonctionnement désiré du système informatisé. Le document d’analyse contient souvent déjà
des prototypes de certains documents importants, que le futur système devra être capable de produire.
Une fois que l’analyse est terminée, il s’agit d’élaborer une série de modèles, basés sur le document d’analyse. Ces
modèles nous permettront plus tard d’implémenter une base de données, qui contiendra toutes les informations nécessaires
au bon fonctionnement du système informatisé.
La création de ces modèles se fait selon une certaine méthode. Nous allons baser notre cours sur la méthode MERISE
(Méthode d’Etude et de Réalisation Informatique de Systèmes d’Entreprise), qui a été développée pendant les années ’70.
Merise est aujourd’hui largement répandue dans les pays d’Afrique et d’Europe francophone pour l’essentiel.
MERISE prévoit une conception par niveaux, et définit pour cela 3 niveaux essentiels :
1. Le niveau conceptuel, qui se base directement sur l’analyse, décrit l’ensemble des données du système d’information,
sans tenir compte de l’implémentation informatique de ces données. Ce niveau, qui représente donc la signification
des données, se traduit par un formalisme que nous appelons Modèle conceptuel des données (MCD)
2. Le niveau logique, qui se base sur le modèle conceptuel des données, prend en considération l’implémentation du
système d’information par un SGBD. Ce niveau introduit la notion des tables logiques, et constitue donc le premier
pas vers les tables des SGBD. Ce niveau est représenté par le Modèle logique des données (MLD)
3. Le niveau physique, qui se base sur le modèle logique des données, contient finalement les tables définies à l’aide
d ?un SGBD spécifique (p.ex. MS Access, dBASE, Oracle . . . ). Ce niveau est représenté par le Modèle physique des
données (MPD)
Voici donc les 4 étapes nécessaires pour traduire un système d’information naturel en une base de données :
14
2.2.1 Pourquoi modéliser
Nous avons vu qu’une base de données est constituée par un ensemble de tables qui contiennent toutes les données de
la base. Une méthode de modélisation nous permet de trouver le bon nombre de tables pour une base de données et de
déterminer quelles données sont représentées à l’intérieur de quelle table.
Pour l’instant, il nous suffit de savoir qu’une table est un ensemble d’enregistrements, dont chacun est composé par les
mêmes champs de données. On pourrait comparer une table à une liste en MS-Excel1.
Exemple 12.
NoEmp bf Nom Emp bf Prénom Emp bf NoEntr bf Nom Entr bf Localité
102 Belibi Emile 1 Tatiss SARL Yaoundé
103 Ntong Francis 1 INC Yaoundé
104 Kenmegne Jovin 2 MINEDUB Douala Nous voyons ici uniquement
105 Adamou Hamza 1 Tatiss SARL Yaoundé
106 Kuissi Aimée 2 MINJUSTICE Douala
... ... ... ... ... ...
quelques enregistrements. Une caisse de maladie ayant des milliers de membres, et cette table possédant un enregistrement
par membre, on peut bien s’imaginer la taille réelle de la table.
Or, cette solution bien qu’elle soit correcte dans le sens le plus large du terme, nous impose un certain nombre de
problèmes.
2.2.2 Exercices
Exercice 1.
Essayez de trouver en discussion quelques problèmes qui peuvent se manifester lors du travail journalier avec cette table.
Exercice 2.
Comment est-ce qu’on pourrait éviter ces problèmes sans toutefois perdre des informations ?
2.2.3 Le modèle conceptuel des données (MCD)
En se basant sur un document d’analyse, le modèle conceptuel des données (MCD) fait référence à tous les objets du
système d’information et à des relations entre ces objets. Le formalisme utilisé dans ce modèle est encore connu sous le
nom de ”Schéma Entité-Relation”. Ce formalisme se base autour de 3 concepts principaux, les entités, les relations et les
propriétés.
Voici par exemple un MCD qui représente une entreprise avec ses employés.
15
(a) Entité (b) Occurrence d’entité
F IGURE 2.2 – Entité et occurrence d’entité.
Nous allons par la suite détailler le rôle de ces 3 concepts de base du MCD.
Notion d’entité
Une entité permet de modéliser un ensemble d’objets concrets ou abstraits de même nature.
Une entité est caractérisée par son nom et ses propriétés
Dans l’exemple du chapitre précédent , l’entité Employé spécifie donc l’ensemble des em-
ployés, qui nous intéressent dans le contexte de notre système d’information. Il en sera de
même pour l’entité Entreprise qui représente toutes les entreprises de notre système d’infor-
mation. de la sorte, la figure présente un exemple d’entité tandis que la figure correspond à
trois occurrences d’une telle entité
Notion de propriété F IGURE 2.1 – Représentation

graphique d’une entité
Une propriété est une donnée élémentaire d’une entité.
Une propriété est unique dans un MCD ; et ne peut pas être rattachée à plusieurs entités différentes.
Pour sa représentation graphique, le nom de la propriété est indiqué à l’intérieur du rectangle qui représente l’entité
correspondante.
Exemple 13.
Pour une entité Client :
• Nom du client
• No.Tél. du client
A l’intérieur de chaque occurrence, chaque propriété prend une valeur, qui est dans la plupart des cas une valeur
numérique, une valeur sous forme de texte ou encore une date. . .
Exemple 14.
L’entité Client est définie par les propriétés vues à la figure 2.2
16
La propriété Nom prend les valeurs ”Meier”, ”Muller” et ”Weber” dans les 3 occurrences présentées.
A l’intérieur de chaque occurrence, chaque propriété ne prend qu’une seule valeur au maximum.
Le client 002 par exemple ne peut pas avoir 2 adresses.
Notion d’identifiant
Afin de pouvoir distinguer les différentes occurrences d’une même entité, l’entité doit être dotée d’un identifiant. L’identi-
fiant est composé d’une ou de plusieurs propriétés de l’entité. Chaque occurrence d’une entité doit avoir une valeur différente
pour l’identifiant. Le choix d’un identifiant correct est très important pour la modélisation :
Comme choix pour l’identifiant d’une entité nous distinguons généralement 3 possibilités :
1. Une propriété naturelle Exemple 15.

Le nom d’un pays pour une entité Pays
2. Une propriété artificielle qui est inventée par le créateur du MCD Exemple 16.
Le numéro d’un client pour une entité Client
3. Une propriété composée d’autres propriétés naturelles Exemple 17.

Le nom et la localité pour une entité Entreprise
On représente graphiquement l’identifiant d’une entité en soulignant toutes les propriétés qui le constituent.
Exercice 3.
Indiquez graphiquement les entités qui représentent :
1. les passagers d’un vol d’une société aérienne. Nous supposons que la société garde ces informations après le vol ;
2. les résultats sportifs de l’entrainement d’un coureur ;
3. les médicaments d’une pharmacie.
Notion de relation
Définition Une relation 1 décrit un lien entre deux ou plusieurs entités.
Chaque relation possède un nom, généralement un verbe à l’infinitif. Bien qu’une relation n’ait pas d’identifiant propre,
elle est implicitement identifiée par les identifiants des entités auxquelles elle est liée.
Le nombre d’entités reliant une relation détermine le type de la relation. En général on parle de relation n-aire lorsque n
entités sont reliées par la même relation. On verra bien souvent :
• les relations binaires, qui sont liées à 2 entités ;
• les relations ternaires, qui sont liées à 3 entités.
Exemple 18.
L’occurrence d’une relation est représentée par les occurrences des entités liées à la relation. La figure 2.3 est une illustration
de ce qu’est une relation binaire. En outre, elle présente quelques occurrences de la relation Ecrire.
Pour chaque occurrence d’une relation, l’identifiant composé des identifiants des entités liées à la relation doit être unique.
Cardinalités d’une relation Une relation est liée à chacune de ses entités par une patte. Sur la patte, on indique les
cardinalités, lesquelles précisent la participation de l’entité concernée à la relation. Une cardinalité est un couple de nombres
entiers naturels dont le premier indique la cardinalité minimale, le deuxième la cardinalité maximale.
La figure 2.4 présente un exemple et illustre la sémantique associée aux différentes pattes. Dans le MCD de la Figure
figure 2.4,
Entre l’entité Client et la relation Passer, nous avons les cardinalités suivantes :
• Cardinalité minimale = 1 , ce qui veut dire que chaque client passe au moins une commande.
• Cardinalité maximale = n , ce qui veut dire que chaque client peut passer plusieurs (n) commandes.
Entre l’entité Commande et la relation Passer, nous retrouvons les cardinalités suivantes :
1. Dans un autre contexte, on parle d’association
17
(a) Relation binaire (b) Occurrence de relation
F IGURE 2.3 – Relation et occurrence de relation.
(a) Signification des cardinalités (b) Exemple 1
F IGURE 2.4 – Les cardinalités.
• Cardinalité minimale = 1 , donc chaque commande est passée par au moins un client.
• Cardinalité maximale =1 , chaque commande est passée au maximum par un seul client.
De façon générale, on peut dire que :
1. La cardinalité minimale exprime le nombre minimum de fois q’une occurrence d’une entité participe à une relation.
Cette cardinalité est généralement 0 ou 1.
• Cardinalité minimale = 0 : Certaines occurrences de l’entité ne participent pas à la relation

• Cardinalité minimale = 1 : Chaque occurrence de l’entité participe au moins une fois à la relation
2. La cardinalité maximale exprime le nombre maximum de fois q’une occurrence d’une entité participe à une relation.
Cette cardinalité vaut souvent 1 ou n, avec n indiquant une valeur ¿1 mais pas connue à priori.
• Cardinalité maximale = 1 : Chaque occurrence de l’entité participe au maximum une seule fois à la relation.
• Cardinalité maximale = n : Chaque occurrence de l’entité peut participer plusieurs fois à la relation.
En pratique, afin de déterminer les bonnes cardinalités, le concepteur doit se référer aux résultats de l’analyse.
Exemple 19.
Pour les deux cas suivants, on peut affirmer qu’une commande est toujours passée par au moins un client. Une commande
est également passée au maximum par un client. Une commande est donc toujours passée par un et un seul client.
Dans le premier cas, un client passe au moins une commande et au maximum plusieurs (n) commandes.
Cette modélisation ne tient pas compte des clients

qui ne passent aucune commande. Un client est unique-
ment considéré comme tel s’il passe au moins une com-
mande.
F IGURE 2.5 – Cas 1 Dans ce second cas, contrairement au premier, un client

peut passer aucune commande et au maximum plusieurs (n)
commandes.
18
Cette modélisation tient compte des clients qui ne passent au-

cune commande.
On peut se poser la question de savoir laquelle de ces

modélisations est correcte. Bien entendu, toutes les deux
modélisations sont correctes. Le choix dépend uniquement du
résultat de l’analyse. Imaginez que vous avez fait pendant l’ana-
lyse une interview avec un futur utilisateur du système. Il vous
a dit qu’il veut enregistrer dans son système des clients poten-
tiels, c.à.d. des personnes dont la compagnie dispose des données
F IGURE 2.6 – Cas 2 personnelles, mais qui n’ont encore jamais passé de commande
auprès de la compagnie. La compagnie désire enregistrer les
données de ces personnes afin de leur envoyer de temps en temps
des publicités. Dans ce cas vous devez opter pour la deuxième
modélisation.
Exercice 4.
Interprétez ls modélisations de la figure 2.9 Dans le modèle 2 de la figure 2.9, on dit que Client est l’entité indépendante
F IGURE 2.7 – Modèle 1

F IGURE 2.8 – Modèle 2
F IGURE 2.9 – Relations utiliser et Disposer
par rapport à la relation disposer (cardinalité minimale = 0) , tandis que Carte membre est l’entité dépendante par rapport à
la relation disposer (cardinalité minimale = 1). Une occurrence d’un client peut donc très bien exister sans carte de membre,
mais une carte de membre ne peut jamais exister sans client.
In fine, la cardinalité minimale nous indique donc si une entité est indépendante ou dépendante.
On en tire deux remarques importantes :

• On dit qu’une entité est indépendante par rapport à une relation lorsque sa cardinalité minimale vaut 0, et dépendante
par rapport à une relation lorsque sa cardinalité minimale vaut 1.
• Une relation ne peut pas être liée uniquement à des entités dépendantes ayant en plus une cardinalité maximale de 1
La modélisation de la figure 2.10 par exemple n’est pas correcte :
Dans un tel cas, il faut réunir les propriétés des deux entités dans une seule.
Propriétés d’une relation Généralement, une relation peut être dotée de propriétés.
Exemple 20.
F IGURE 2.10 – Modélisation incorrecte F IGURE 2.11
Exercice 5.
Pourquoi est-ce qu’on ne peut pas associer la propriété Année à une des entités de la figure 2.11
19
Cette propriété peut même devenir une partie de l’identifiant. Dans ce cas, elle doit être soulignée.
Exemple 21.
Comme un professeur peut avoir la même classe pendant plusieurs années, un identifiant composé de No Matricule et
F IGURE 2.12
Code Classe n’est pas suffisant, puisqu’il ne garantit pas l’unicité. On y ajoute l’Année (Cf. Figure 2.12).
Une relation à cardinalité (1,1) n’est jamais porteuse de propriétés. Dans ce cas, les propriétés migrent dans l’entité
portant cette cardinalité (1,1).
Exemple 22.
La modélisation de la Figure 2.13 n’est pas correcte ! Chaque facture ne possède qu’une et une seule date d’émission, ce qui
F IGURE 2.13
fait que la propriété Date émission doit migrer dans l’entité Facture.
La modélisation correcte est donnée à la figure 2.14 :
F IGURE 2.14
Exercice-Exemple 1 : ”KaafKaaf”
Partie 1 : La société ”KaafKaaf” désire informatiser son système de facturation. Un exemple de facture est présenté à la
figure 2.15.
Créez un MCD, qui permet de modéliser correctement le système d’information nécessaire, sachant que :
• Un client peut bien sûr recevoir plusieurs factures, mais il est uniquement considéré comme tel à partir du
moment où il reçoit sa première facture.
• Une facture concerne un et un seul client.
Remarque :
Bien que le numéro du client n’apparaisse pas en tant que tel sur la facture, il est préférable d’ajouter cette propriété
artificielle à l’entité Client, et de la définir comme identifiant de cette entité. Cela nous empêche de devoir définir un
identifiant composé de trop de propriétés.
Partie 2 : Il s’agit maintenant d’étendre le MCD obtenu précédemment.

Le responsable de la facturation de la société désire rendre les factures plus informatives. Comme un client peut acheter
plusieurs articles différents en même temps, la facture devrait indiquer pour chaque article le numéro , un libellé, le
prix unitaire, la quantité vendue et le prix total pour ce type d’article.
La figure 2.17 correspond à l’aspect que la facture devrait avoir :
Proposez un nouveau MCD qui reflète ces modifications, en sachant que :
• Tous les articles disponibles sont stockés (p.ex. No=234 Libellé=”Marteau” PU=470 FCFA.). Même si un article
n’est pas encore considéré par une facture, il existe dans le système d’information.
20
F IGURE 2.15 – Exemple de facture
F IGURE 2.16
Ce nouveau MCD est donné à la figure 2.18

Remarques :
• L’entité Facture ne contient plus la propriété Montant. Il existe une règle générale de conception qui dit : ”Aucune
propriété qui peut être calculée à partir d’autres propriétés existantes, ne devra être stockée dans le MCD.”
Pour la même raison, on n’a pas besoin de modéliser explicitement le prix à payer pour l’achat d’une quantité
d’articles donnés. Le prix pour chaque article figurant sur la facture peut être calculé à partir du prix unitaire et
de la quantité
• Nous retrouvons ici le cas d’une relation qui a une propriété. En fait, la propriété Quantité n’est pas spécifique
à un article, mais à l’achat de cet article à l’aide d’une facture. Cette façon de modéliser la situation est la plus
facile, mais il existe une alternative. On peut introduire l’entité abstraite Ligne de facture, qui représente une
ligne de détail d’une facture, p.ex celle pour le marteau. (Cf. Figure 2.19)
Exercice-Exemple 2 : La gestion d’une école

Partie 1 : Dans une école, on veut informatiser le système d’information qui gère les classes.
Elaborez un MCD sachant que :
• Un élève est caractérisé par son no. matricule, son nom et prénom, ainsi que sa date de naissance.
• Une classe est caractérisée par le nom de la classe (p.ex 13CG2) et par une indication du cycle (valeurs possibles :
”inférieur”, ”moyen”, ”supérieur”).
• Il faudra prévoir de connaı̂tre la fréquentation des classes des élèves sur plusieurs années consécutives.
21
F IGURE 2.17
F IGURE 2.18
• Un élève enregistré dans le système fréquente au moins une classe au cours des années.
Partie 1 : Il s’agit maintenant de concevoir une extension au MCD précédent qui permet de représenter la situation suivante :
• La direction de l’école désire également saisir tous les professeurs dans le système d’information. Un professeur
est caractérisé par un code interne unique (p.ex. Jemp Muller aura le code JEMU), son nom et prénom et la
matière qu’il enseigne. Nous supposons que chaque professeur enseigne une seule matière.
• Modélisez le fait que chaque classe est enseignée chaque année par un ou plusieurs enseignants. Un enseignant
peut bien sûr donner des cours dans plusieurs classes, mais peut également ne pas donner des cours pendant une
ou plusieurs années.
Utilisation d’une relation ternaire

Lors de l’introduction des relations nous avons déjà mentionné la notion de relation ternaire. Une relation ternaire est
une relation à laquelle sont liées 3 entités.
22
F IGURE 2.19
F IGURE 2.20
F IGURE 2.21
Bien que dans la pratique la plupart des relations soient binaires (2 entités) il existe cependant des situations où l’utilisa-
tion d’une relation ternaire s’impose.
Exemple 23.
A partir des 3 entités à savoir : Professeur (CodeProf, Nom, Prénom), Matière(CodeMatière, Libellé) et Classe(Nom,Cycle),
il s’agit de créer un MCD qui renseigne sur le fait quelle matière est enseignée dans quelle classe par quel professeur pour
une année scolaire donnée.
Exercice 6.
Essayez de montrer les limites/défauts d’un MCD qui représente l’énoncé de l’exemple précédent en utilisant uniquement
des relations binaires. Pour l’exemple précédent, la figure 2.22 donne une solution qui utilise une relation ternaire
Il existe 3 façons pour lire/interpréter ce modèle :
• Un professeur peut enseigner 1 à n fois une matière dans une classe.

23
F IGURE 2.22
• Une matière peut être enseignée 1 à n fois par un professeur dans une classe.
• Une classe peut être enseignée 1 à n fois dans une matière par un professeur.
On peut dire que chaque occurrence de la relation enseigner associe un professeur à une matière et une classe pour une
année donnée. Ou encore, ce modèle nous permet de montrer pour chaque année scolaire quelle matière est enseignée dans
quelle classe par quel professseur.
Il n’est pas toujours facile de déterminer quand il faut utiliser une relation ternaire. Généralement, on peut déjà affirmer
que si une ou plusieurs des entités liées à une relation ternaire possèdent une cardinalité maximale de 1, la modélisation n’est
pas optimisée dans le sens qu’il faudrait mieux décomposer la relation ternaire, c.à.d. la représenter par 2 relations binaires.
Exemple 24.
La direction d’une chaı̂ne d’hôtels désire gérer les séjours des clients dans les différents hôtels. Comme on peut effectivement
dire ”Un client effectue un séjour dans un hôtel” on est ammené à proposer la modélisation de la figure 2.23.
F IGURE 2.23
Il existe 3 façons pour lire/interpréter ce modèle :
• Un client peut effectuer 1 à n fois un séjour dans un hôtel.
• Dans un hôtel peut être effectué 0 à n fois un séjour par un client.
• Un séjour peut être effectué une et une seule fois par un client dans un hôtel.
Chaque occurrence de la relation effectuer associe donc un séjour à un client et à un hôtel.

Hors, cette modélisation porte une contrainte supplémentaire, puisque la cardinalité 1,1 entre l’entité Séjour et la relation
nous indique que pour chaque occurrence de Séjour il ne peut exister qu’une et une seule occurrence de la relation. Donc
chaque séjour est associé une et une seule fois à une combinaison client/hôtel. Dans ce cas il vaut mieux décomposer la
relation ternaire et l’on obtient la modélisation de la figure 2.24.
24
F IGURE 2.24
Les contraintes d’intégrité fonctionnelles (CIF)

Quand on détermine entre une relation et une entité une cardinalité qui présente les valeurs 0,1 ou 1,1, alors cette relation
est particulière et on dit qu’elle représente une Contrainte d’Intégrité Fonctionnelle (CIF).
Exemple 25.
Soit donnée la figure
F IGURE 2.25
La relation Obtenir représente une CIF.

Une CIF indique que l’une des entités est totalement déterminée par la connaissance de l’autre. Dans notre exemple on
peut dire que connaissant une facture bien précise, on connaı̂t avec certitude le client correspondant.
Comment est-ce qu’on représente une CIF dans un MCD ?
Une CIF est souvent représentée par une flèche sur la patte opposée à celle ayant une cardinalité 0,1 ou 1,1. L’entité qui
est attachée à cette patte est appelée entité cible de la CIF, tandis que l’autre entité constitue l’entité émettrice de la CIF.
Exercices-TDs
Exercice 7.
Voici le résultat simplifié d’une analyse faite auprès d’une compagnie d’assurance qui désire informatiser la gestion des
contrats auto.
• Un client peut assurer plusieurs voitures auprès de la compagnie. Chaque voiture est assurée par un seul contrat. Un
contrat assure une seule voiture.
• En ce qui concerne un client, la compagnie désire connaı̂tre son nom, prénom, adresse complète, numéro de téléphone
ainsi qu’un numéro de compte bancaire avec indication de la banque.
• Chaque contrat contient un numéro de contrat unique, la prime annuelle à payer, la date de paiement annuel, la
marque de la voiture, le modèle de la voiture, le numéro d’immatriculation de la voiture, la valeur de la voiture et la
date d’acquisition de la voiture.
En ignorant la méthode de modélisation, on pourrait créer une BD avec une seule table ayant un champ pour chaque
donnée indiquée dans l’analyse. On aurait donc les données des clients et des contrats dans une seule table. Quelles en
seraient les inconvénients ?
25
Créez le modèle conceptuel des données correspondant à cette situation
Exercice 8.
• Le responsable d’un magasin de location de cassettes vidéo désire informatiser le système de gestion des locations.
Voici les informations recueillies pendant l’analyse : Un membre est caractérisé par son numéro membre, son nom,
son prénom, son adresse ainsi que sa date de naissance. Dès que la carte de membre est payée (paiement unique), le
membre est enregistré dans le système et il peut désormais louer des cassettes vidéo.
• Un film est caractérisé par un numéro film, un titre, un code langue, un code genre et une durée. Le même film peut
être disponible en plusieurs exemplaires. Un exemplaire est déterminé par un numéro exemplaire ainsi que la date
d’achat de l’exemplaire.
• Lors d’une location, un membre peut louer plusieurs films en même temps. En principe, une location a une durée d’un
jour, mais cette durée peut être prolongée. Nous supposons qu’un membre rend tous les exemplaires loués en une seule
fois.
Créez le modèle conceptuel des données
Exercice 9.
Afin d’informatiser la gestion des séances du cinéma Limelight, vous disposez des informations suivantes.
• Un film est enregistré dans le système d’information dès que la (les) copie(s) sont arrivées au cinéma. A partir de ce
moment, on commence à programmer des séances pour le film en question. Comme le même film n’est jamais joué
dans deux séances parallèles, on peut ignorer la gestion des copies.
• Un film est représenté par un numéro courant interne, qui lui est affecté par le gestionnaire des séances. En plus, on
s’intéresse pour le titre, la langue et la durée du film. Lorsqu’un film apparaı̂t en plusieurs langues différentes, on
crée dans le système d’information simplement un enregistrement par langue. Chaque film est accompagné en général
d’une fiche technique, qui renseigne en outre sur le système son du film (p.ex. DOLBY, THX etc.). Cette information
est importante, puisque les capacités en ce qui concerne la reproduction du son varient d’une salle dans une autre. Une
salle peut supporter plusieurs systèmes différents, tandis qu’un film est tourné en utilisant un seul système son. Un
système son est caractérisé par un code identificateur ainsi qu’un libellé.
• Le cinéma dispose actuellement de 12 salles, avec 3 nouvelles salles en construction. Une salle est prise en compte
dans le système d’information, dès qu’elle est prête pour accueillir des séances. Une salle est caractérisée par son
numéro, sa capacité ainsi que des informations concernant le support des différents systèmes son.
• Le système d’information doit permettre de vendre des tickets pour une séance donnée, même plusieurs jours en
avance. La réservation des sièges n’étant pas demandée, il est toutefois nécessaire que le système soit capable de
prévenir un excès de la capacité d’une salle en ce qui concerne le nombre de tickets vendus.
• La gestion des prix pour les tickets se fait au niveau des séances, puisque le prix pour voir un même film peut varier
d’une séance à une autre (p.ex. Tarif réduit les lundis à 16h00). Une séance, qui se déroule évidemment sans une seule
salle, est identifiée par un numéro courant.

Exercice 10.
Le commandant de la brigade municipale des Sapeurs-Pompiers de Mimboman se propose d’informatiser la gestion des
différentes interventions. Etant responsable de l’administration de la brigade, vous êtes en charge de créer une base de
données pour stocker les informations relatives aux interventions.
Partie 1 Voici le résultat de l’analyse préliminaire menée auprès des responsables de la brigade (p.ex. le commandant, le
sous-commandant ?)
• Chaque intervention est identifiée par un numéro unique

• Une intervention est en plus caractérisée par une date, une adresse et un type d’intervention (p.ex. Incendie,
Accident, Inondation)
• Pour chaque intervention, on veut savoir quels sapeurs-pompiers y ont participé
26
• Un sapeur-pompier est caractérisé par un numéro d’identification, son nom, son prénom, son âge ainsi qu’un
grade (p.ex. sapeur, chef de section, sous-commandant, commandant)
Partie 2 Le commandant vous demande de représenter également l’utilisation des véhicules de la brigade. Lors d’une in-
tervention, les sapeurs-pompiers sont affectés aux différents véhicules selon les circonstances. Jusqu’à présent, le
commandant a rempli une fiche pour chaque intervention (Cf Figure 2.26)
F IGURE 2.26
• Un véhicule est identifié par son numéro d’immatriculation

• Un véhicule est en plus caractérisé par un type de véhicule (p.ex. Echelle, Transport . . . ), une marque, et le
nombre de places disponibles
Cas particuliers du MCD
Plusieurs relation différentes entre deux entités Exemple 26.
Une personne, qui habite dans une maison n’est pas toujours propriétaire de cette maison, tandis que le propriétaire d’une
maison ne doit pas nécessairement habiter dans celle-ci. Il incombe donc de représenter le fait de posséder une maison par
une relation séparée et le fait d’habiter dans une maison par une relation séparée.
27
F IGURE 2.27
Relation réflexive et rôle d’une patte de relation Exemple 27.

Une relation réflexive, est une relation, dont les deux pattes sont liées à une même entité. En général, la signification des
pattes d’une relation réflexive devrait être clarifiée par l’indication d’un rôle.
Cas 1 : Une illustration est donnée à la Figure 2.28
F IGURE 2.28 – Pattes dans une relation réflexive
Cas 2 : Afin d’obtenir une licence pour piloter un avion de ligne, un pilote doit effectuer un certain nombre de brevets. Il
existe une hiérarchie prédéfinie en ce qui concerne les brevets (structure arborescente). A chaque fois qu’un pilote a
réussi un brevet, il a la possibilité d’effectuer un certain nombre d’autres brevets, qui sont dépendants du brevet réussi.
Tous les brevets sont dépendants du brevet de base.
F IGURE 2.29
Notion d’identifiant relatif Sachant que chaque entité doit obligatoirement être dotée d’un identifiant, certaines entités
ont cependant une existence complètement dépendante et liée à une autre entité. Une entité A est complètement dépendante
d’une entité B, c.à.d. qu’une occurrence de l’entité A ne peut pas exister sans être reliée à une occurrence de l’entité B,
lorsque les deux conditions suivantes sont vraies :
1. L’entité A est émettrice d’une CIF tandis que l’entité B est cible de la même CIF.
2. L’entité A n’est pas indépendante par rapport à la CIF (Cardinalité minimale = 1)
Exemple 28.
L’entité Tâche est complètement dépendante de l’entité Projet.

Dans le cas d’une telle dépendance complète, on peut avoir recours à un identifiant relatif. Dans notre exemple, la
propriété No Tâche constitue l’identifiant relatif de l’entité Tâche. Cette propriété ne remplit dans ce cas pas les conditions
28
F IGURE 2.30
pour devenir identifiant absolu (Le même numéro de tâche est susceptible d’apparaı̂tre dans plusieurs projets). Toutefois, on
peut affirmer qu’en relation à un certain numéro de projet, le numéro de tâche est un identifiant absolu.
On note cette identification relative par la lettre (R) sur la patte reliée à l’entité qui contient l’identifiant relatif.
Historisation Pour certaines propriétés, entités ou relations, on désire parfois conserver les valeurs antérieures en cas de
modification. On parle dans ce contexte d’historisation. Théoriquement, cette idée n’est pas tout à fait en accord avec les
règles de conception d’un système d’information. Prenons l’exemple suivant :
Pour une occurrence de cette entité, c.à.d. pour un assuré spécifique, il existe uniquement une seule
valeur pour chaque propriété. Selon cette modélisation, un assuré ne peut par exemple pas habiter en
même temps dans deux localités différentes. En général, ceci ne pose aucun problème, comme un assuré
indique normalement une seule adresse de référence.
Toutefois, cette modélisation ne permet pas de représenter le tracé historique des adresses, lorsqu’un
assuré déménage une ou plusieurs fois. Dans la plupart des cas, cette modélisation de l’historique n’est
F IGURE 2.31
pas demandée, mais elle est quand même réalisable à l’aide de la méthode Merise. Au niveau conceptuel, nous indiquons
simplement ce que nous voulons historiser.
Nous distinguons 3 cas :
Propriété historisée La conservation des valeurs historiques s’applique à une ou plusieurs propriétés d’une entité ou d’une
relation. Dans le MCD, on indique une historisation de propriété par la lettre (H) derrière la resp. les propriétés
concernées. Cf. Figure 2.32
Entité historisée La conservation des valeurs s’applique à toutes les propriétés d’une l’entité. On indique l’historisation par
la lettre (H) derrière le nom de l’entité.Cf. Figure 2.33
Relation historisée La conservation des valeurs s’applique à toutes les propriétés d’une relation. On indique l’historisation
par la lettre (H) derrière le nom de la relation. Cf. Figure 2.34 On ne peut pas historiser une relation sans propriétés,
F IGURE 2.34
F IGURE 2.32 F IGURE 2.33
puisque l’expression ’historiser une relation’ n’est qu’un abus de langage, il s’agit en fait d’historiser toutes les pro-
priétés d’une relation. On peut remarquer à ce moment que la méthode MERISE présente une particularité en ce
qu’elle ne prévoit pas l’historisation d’une propriété individuelle d’une relation
Exercices-TDs
Exercice 11.
Un club de tennis vous demande d’informatiser la gestion des réservations des différents terrains. A ces fins, vous disposez
des informations suivantes.
• Le club dispose d’une liste de membres. Quiconque veut jouer sur un des terrains, doit devenir membre du club.
29
• Un membre est caractérisé par un numéro interne au club, par son nom, prénom, adresse, code postal, localité, numéro
de téléphone ainsi qu’une indication s’il est un joueur licencié auprès de la fédération de tennis ou non.
• Pour chaque réservation, on désire connaı̂tre l’identité des deux joueurs membres. Au cas où quatre joueurs réserveraient
un terrain, uniquement deux joueurs sont enregistrés dans le système.
• Le club dispose de plusieurs terrains, dont certains sont couverts. On distingue en plus le type du terrain selon la nature
du sol (p.ex. Sable, Herbe etc.)
• Une réservation se fait pour une date précise par tranches d’une heure.
Créez le MCD correspondant.

Exercice 12.
Une société aérienne utilise à présent les fiches suivantes pour la gestion des ressources.
F IGURE 2.35
Sachant que la société entretient déjà une BD avec tous les pilotes et qu’un pilote peut être commandant d’un vol et
co-pilote d’un autre vol, proposez un MCD, qui permet l’informatisation de la gestion des ressources.
2.2.4 Avantage et inconvénients du modèle E/A

Le modèle Entité/Association est simple et pratique.
1. Il n’y a que 3 concepts : entités, associations et attributs.
2. Il est approprié à une représentation graphique intuitive, même s’il existe beaucoup de conventions.
3. Il permet de modéliser rapidement des structures pas trop complexes.
Il y a malheureusement plusieurs inconvénients. Tout d’abord il est non-déterminisme : il n’y a pas de règle absolue pour
déterminer ce qui est entité, attribut ou relation. Exemple : est-il préférable de représenter le metteur en scène (MES) comme
un attribut de Film ou comme une association avec Artiste ? Réponse : comme une association ! Les arguments sont les
suivants :
1. On connaı̂t alors non seulement le nom, mais aussi toutes les autres propriétés (prénom, âge, ...).
2. L’entité MES peut-être associée à beaucoup d’autres films : on permet le partage de l’information.
30
Autre exemple : est-il indispensable de gérer une entité Horaire ? Réponse : pas forcément ! Arguments :
1. Pour. Permet de normaliser les horaires. Plusieurs séances peuvent alors faire référence au même horaire (gain de
place, facilité de mise à jour, cohérence, ...)
2. Contre. On alourdit le schéma inutilement : un horaire est propre à une séance. On peut le représenter comme un
attribut de Séance.
Enfin on a vu qu’une association pouvait être transformée en entité. Un des principaux inconvénients du modèle E/A reste
sa pauvreté : il est difficile d’exprimer des contraintes d’intégrité, des structures complexes.
Beaucoup d’extensions ont été proposées, mais la conception de schéma reste en partie matière de bon sens et d’expérience.
On essaie en général :
1. de se ramener à des associations entre 2 entités : au-delà, on a probablement intérêt a transformer l’association en
entité ;
2. d’éviter toute redondance : une information doit se trouver en un seul endroit ;
3. enfin ? et surtout ? de privilégier la simplicité et la lisibilité, notamment en ne représentant que ce qui est strictement
nécessaire.
2.3 Le modèle logique de données (MLD)

Jusqu’à présent nous avons établi des MCD basés sur une analyse d’un domaine bien défini (p.ex. Gestion des séances
d’un cinéma, Gestion des séjours des patients d’un hôpital etc.). La finalité d’un MCD est de nous faciliter la création d’une
base de données pour gérer un tel domaine.
Nous savons également qu’une base de données est constituée par un ensemble de tables, dont chacune est composée de
champs de données.
Hors le MCD ne connaı̂t pas la notion de table, tandis qu’une base de données ne connaı̂t pas le concept des entités
reliées entre-elles via des relations portant des cardinalités.
Pour cela, il existe un autre modèle, le modèle logique des données (MLD), qui utilise essentiellement le formalisme des
tables logiques. Un MLD, qui est toujours basé sur un MCD donné, contient donc toutes les informations de ce MCD, mais
les représente à l’aide d’un formalisme différent qui est très adapté aux structures d’une base de données.
Tandis que le MCD représente un système d’information d’une façon générale et indépendante d’un système informa-
tique, le MLD tient compte de la réalisation par le biais d’un SGBD.
Un MLD est essentiellement composé de tables logiques reliées entre elles par des flèches -Cf. Figures.
F IGURE 2.36 – Un MCD F IGURE 2.37 – Un MLD
En vous référant à l’exemple précédant, répondez brièvement aux questions suivantes.
Exercice 13.
1. Comment est-ce qu’on traduit une entité du MCD dans le MLD ?
2. Comment est-ce qu’on traduit une propriété d’une entité du MCD dans le MLD ?
3. Comment est-ce qu’on traduit un identifiant d’une entité du MCD dans le MLD ?
4. Comment est-ce qu’on traduit la relation Ecrire avec ses cardinalités du MCD dans le MLD ?
5. Le MCD nous dit que chaque livre est uniquement écrit par un seul auteur (cardinalité max.), tandis qu’un auteur peut
écrire plusieurs livres. Comment est-ce qu’on peut retrouver ces informations dans le MLD ?
31
Remarque :
La méthode MERISE définit de façon générale certaines règles qui nous permettront de transformer n’importe quel MCD en
MLD.
2.3.1 Règles de transformation du MCD au MLD

Nous allons définir les règles de transformation pour le passage du MCD au MLD, en respectant les différents cas qui se
posent.
Transformation des entités

Toute entité est transformée en table. Les propriétés de l’entité deviennent les attributs de la table. L’identifiant de l’entité
devient la clé primaire de la table.
Exemple 29.
F IGURE 2.38
Transformation des relations binaires du type 2 (x,n) - (x,1)

Afin de représenter la relation, on duplique la clé primaire de la table basée sur l’entité à cardinalité (x,n) dans la table
basée sur l’entité à cardinalité (x,1). Cet attribut est appelé clé étrangère. Les deux tables sont liées par une flèche nommée
selon la relation, qui pointe de la table à clé étrangère vers la table qui contient la clé primaire correspondante.
Exemple 30.
F IGURE 2.39
L’attribut No Auteur qui est clé primaire de la table Auteur, devient clé étrangère dans la table Livre.
Transformation des relations binaires du type (x,1)-(x,1)

Nous devons distinguer plusieurs cas. Sachant qu’une relation binaire du type (1,1)-(1,1) ne doit pas exister il nous reste
les 2 cas suivants :
Relation binaire (0,1)-(1,1) : On duplique la clé de la table basée sur l’entité à cardinalité (0,1) dans la table basée sur
l’entité à cardinalité (1,1).
Exemple 31.
Le No Client, qui est clé primaire de la table Client, devient clé étrangère dans la table Carte Membre.
2. x peut prendre les valeurs 0 ou 1
32
F IGURE 2.40
Relation binaire (0,1)-(0,1) On duplique la clé d’une des tables dans l’autre. Lorsque la relation contient elle-même des
propriétés, celles-ci deviennent également attributs de la table dans laquelle a été ajoutée la clé étrangère.
Exemple 32.
F IGURE 2.41
Soit on migre la clé primaire de la table Entreprise dans la table Salarié, soit on fait l’inverse.
Transformation des relations binaires du type (x,n) - (x,n)
On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires des 2 tables. Lorsque
la relation contient elle-même des propriétés, celles-ci deviennent attributs de la table supplémentaire. Une propriété de la
relation qui est soulignée devra appartenir à la clé primaire composée de la table supplémentaire.
Exemple 33.
F IGURE 2.42
On crée une table Porter, qui contient comme clé primaire une clé composée de No-Commande et Code Article. Elle
contient également la propriété Quantité issue de la relation Porter.
33
Transformation des relations ternaires
On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires de toutes les tables
reliées. Cette règle s’applique de façon indépendante des différentes cardinalités. Lorsque la relation contient elle-même
des propriétés, celles-ci deviennent attributs de la table supplémentaire. Une propriété de la relation qui est soulignée devra
appartenir à la clé primaire composée de la table supplémentaire.
Exemple 34.
F IGURE 2.43
La table Enseigner contient une clé composée de No Enseignant, Code Matière et Nom Classe.
Transformation de plusieurs relations entre deux entités

Les règles générales s’appliquent
Exemple 35.
F IGURE 2.44
La relation habiter du type (x,n)-(x,1), est traduite par la migration de l’attribut Adresse dans la table Personne. La
relation posséder du type (x,n)-(x,n) est traduite par la création d’une table supplémentaire du même nom. Cette table
contient comme clé primaire composée, les clés des deux tables reliées Personne et Maison. On a donc simplement appliqué
2 fois de façon indépendante les règles de transfert MCD → MLD.
Transformation des relations réflexives

Nous appliquons les règles générales avec la seule différence que la relation est 2 fois reliée à la même entité
Exemple 36.
Comme il s’agit d’une relation (x,n)-(x,n), une table supplémentaire est créée. Cette table contient comme clé primaire
composée, la clé des ”deux” entités reliées. Comme la même entité est liée 2 fois à la relation, on ne peut pas utiliser 2 fois
le même nom pour la clé. Dans ce cas il convient d’utiliser des rôles dans le MCD, et d’intégrer le rôle dans le nom d’une
des clés migrées dans le MLD.
Exemple 37.
Comme il s’agit d’une relation (0,1)-(0,1), nous avons en général le choix en ce qui concerne quelle entité contiendra
la clé étrangère. Comme cette relation est liée deux fois à la même entité, il est évident que nous devons dupliquer la clé
primaire, tout en veillant que le même nom de clé ne sera pas utilisé pour la clé primaire et la clé étrangère. Dans notre
exemple, tous les hommes mariés, ont comme valeur de la clé étrangère la matricule de leur épouse actuelle. Pour les
34
F IGURE 2.45
F IGURE 2.46
hommes non mariés et les femmes, la clé étrangère est sans valeur. On pourrait bien sûr utiliser la modélisation inverse avec
une clé étrangère NO MATRICULE MARI, qui indique pour chaque femme mariée, la matricule de son mari.
Transformation de l’identifiant relatif
Sachant que l’entité dépendante est toujours liée à la relation par les cardinalités (1,1), nous pouvons appliquer les règles
générales. Dans chaque cas, la table issue de l’entité dépendante contient donc comme clé étrangère, la clé primaire de l’autre
table. L’identification relative est représentée par le fait que la table issue de l’entité dépendante contient une clé primaire
composée, constituée de la clé primaire transformée de l’identifiant de cette entité et de la clé étrangère.
Exemple 38.
F IGURE 2.47
Tout en respectant les règles générales du passage MCD→MLD, la clé primaire de la table Projet migre comme clé
étrangère dans la table Tâche. L’identification relative est représentée par le fait que la table tâche contient une clé primaire
composée de No Tache et No Projet.
Transformation de l’historisation
Historisation d’une propriété Pour chaque propriété à historiser, on crée une table qui contient :
35
• Une clé primaire composée de la clé primaire de la table qui contient la propriété à historiser et de la date d’historisa-
tion.
• La propriété à historiser
Exemple 39.
Voir Figure 2.48
F IGURE 2.48
Historisation d’une entité Pour toute modification de valeur d’une des propriétés de l’entité, on historise l’ensemble des
valeurs des propriétés dans une table qui contient :
• Une clé primaire composée de la clé primaire de l’entité à historiser et de la date d’historisation
• Toutes les autres propriétés de l’entité à historiser

Exemple 40.
Voir Figure 2.49
F IGURE 2.49
Historisation d’une relation Pour toute modification de valeur d’une des propriétés de la relation, on historise l’ensemble
des valeurs des propriétés dans une table qui contient :
• Une clé primaire composée de la clé primaire de la table qui représente la relation à historiser et de la date d’histori-
sation
• Toutes les autres propriétés de la relation à historiser

Voir Figure 2.50
Exemple 41.
Exemple ”KaafKaaf”
Transformez le MCD de la Figure 2.51 , qui représente la facturation de la société ”KaafKaaf” (voir l’exercice-exemple
1 de la section 2.2.3), en un MLD en respectant toutes les règles du passage M CD → M LD.
Voici une solution :
36
F IGURE 2.50
F IGURE 2.51
F IGURE 2.52
Exercices-TDs
Exercice 14.
Transformez en MLD tous les MCD que vous avez réalisés jusqu’ici.
Exercice 15.
Transformez le MCD suivant en MLD en respectant toutes les règles de passage M CD → M LD.
Remarques :
• En ce qui concerne le rapport médical, une conclusion médicale pourrait par exemple être ”Infection” ou ”Cancer de
la gorge”, tandis que la conclusion professionnelle qui s’en suit serait par exemple ”Apte” ou ”Inaptitude temporaire
¡x¿ jours”.
• L’entité Salarié est historisée.

37
F IGURE 2.53 – MCD Médecine de travail
Exercice 16.
Voici un MCD qui représente de façon très simplifiée la gestion d’une compagnie d’assurances. Transformez le MCD en
MLD en respectant toutes les règles de passage M CD → M LD.
F IGURE 2.54 – MCD Assurance
Remarques :
• Le type de contrat indique les garanties prévues.

Exemple :
Type AUTO-SIMPLE contient (RC-AUTO et Protection juridique)
Type AUTO-SPECIAL contient (Garanties AUTO-SIMPLE + FEU + VOL)
Type AUTO-DELUXE contient (Garanties AUTO-SPECIAL + Dégâts matériels)
• Un contrat couvre un seul risque. Ce risque peut être une voiture ou une habitation.
• Afin d’améliorer l’exploitation statistique des données concernant les garanties, le tarif d’une garantie est historisé.
38
2.4 Le modèle physique de données (MPD)
Le modèle physique des données (MPD) est la traduction du modèle logique des données (MLD) dans une structure de
données spécifique au système de gestion de bases de données (SGBD) utilisé.
Le MPD est donc représenté par des tables définies au niveau du système de gestion de bases de données. C’est donc au
niveau du MPD que nous quittons la méthode générale de création d’un MCD et de sa transformation en MLD, pour nous
tourner vers la manipulation d’un SGBD spécifique.
2.4.1 Passage du MLD au MPD

Le passage M LD → M P D se fait par les étapes suivantes :
• Implémentation physique de chaque table du MLD dans le SGBD utilisé.
• Pour chaque table, indiquer au SGBD quel(s) champ(s) constitue(nt) la clé primaire.
• Pour chaque table, indiquer au SGBD la (les) clé(s) étrangère(s), et la (les) clé(s) primaire(s) correspondante(s).
Pour ce faire, la plupart des SGBD actuellement sur le marché nous offrent 2 possibilités.
Prenons à titre d’exemple l’implémentation du modèle logique suivant (Cf. Figure 2.55). On procède alors comme suit !
F IGURE 2.55 – MCD Assurance
1. Utilisation d’une ou de plusieurs interfaces graphiques, qui nous aident dans la création des tables physiques, dans la
définition des clés primaires et dans la définition des relations.
Exemple 42.
Définition de la table des employés avec le champ idEmployé étant défini comme clé primaire.
F IGURE 2.56
39
F IGURE 2.57
Définition de la relation entre les deux tables.

Remarquez que les noms des différents champs ont été modifiés lors de l’implémentation du modèle logique. Cette
mesure dépend uniquement de la convention des noms utilisée et n’affecte pas du tout le fonctionnement correcte de
la BD.
2. Utilisation de commandes spéciales, faisant partie d’un langage de définition de données (p.ex. SQL-DDL, Cf figure
2.58)
Que vous avez utilisé l’une ou l’autre des 2 méthodes, le résultat sera toujours un ensemble de tables physiques reliées entre
elles, dans lesquelles vous pouvez stocker des données.
2.4.2 Les contraintes d’intégrité

Une modélisation correcte et cohérente est sans doute une condition nécessaire pour créer une BD fonctionnelle, mais ne
vaut pas grand chose, lorsque le SGBD utilisé pour implémenter la base, ne garantit pas l’intégrité de celle-ci lors du travail
journalier avec les données.
Exemple 43.
• Le système doit empêcher un utilisateur à entrer une valeur double ou indéterminée (NULL) pour un champ déclaré
comme clé primaire.
• Le système doit vérifier qu’une quantité livrée est toujours inférieure ou égale à une quantité commandée.
Les types de contraintes d’intégrité

• La contrainte d’intégrité des tables (angl. Table Integrity Constraint) Cette contrainte vérifie qu’il n’existe jamais des
doublons ou des valeurs indéterminées pour le(s) champ(s) qui constitue(nt) la clé primaire. La clé primaire doit donc
toujours être unique et bien définie.
Exemples de violation de cette contrainte
A. L’ajout d’une valeur de clé primaire qui existe déjà dans la table.
B. La modification d’une valeur de clé primaire vers une valeur qui existe déjà dans la table.
C. L’ajout d’une valeur indéterminée pour une clé primaire.
D. La modification d’une valeur de clé primaire vers une valeur indéterminée.
Méthodes de vérification dans un SGBD

Dans un SGBD il suffit généralement de déclarer un ou plusieurs champs comme clé primaire d’une table pour que
cette contrainte soit automatiquement vérifiée pour chaque insertion ou modification d’une valeur dans la table.
• La contrainte d’intégrité référentielle (angl. Referential Integrity Constraint)

Par contrainte d’intégrité référentielle, on entend l’obligation qu’à chaque valeur d’une clé étrangère correspond une et
une seule valeur de la clé primaire associée. Cette obligation doit toujours être vérifiée lors de l’ajout, de la suppression
ou de la modification de données.
A. A. L’ajout d’une clé étrangère pour laquelle il n’existe pas de valeur correspondante dans la clé primaire associée.
40
F IGURE 2.58
B. B. La modification d’une clé étrangère vers une valeur pour laquelle il n’existe pas de valeur correspondante dans
la clé primaire associée.
41
C. C. La suppression d’une clé primaire, qui est référencée par une ou plusieurs valeurs d’une clé étrangère.
D. D. La modification d’une clé primaire, qui est référencée par une ou plusieurs valeurs d’une clé étrangère.
Méthodes de vérification dans un SGBD

Un SGBD nous offre généralement une ou plusieurs des quatre méthodes suivantes pour spécifier à tout moment
l’intégrité référentielle des données d’une BD.
I. Interdiction des opérations du type A, B, C et D. Bien que cette possibilité soit très efficace, il existe parfois une
alternative préférable en fonction de la nature des données. Remarque : Tandis que les opérations A et B ne sont
jamais permises lorsque l’intégrité référentielle est appliquée, il n’en est pas de même pour les opérations C et
D. Le langage SQL par exemple contient une commande CREATE TABLE qui permet de définir la structure
d’une table. Cette commande contient entre autres les options ON DELETE NO ACTION et ON UPDATE NO
ACTION qui permettent de réaliser explicitement l’interdiction des opérations C et D.
II. Cascade des opérations du type C et D vers les clés étrangères correspondantes. Une modification d’une clé pri-
maire aurait comme conséquence la modification de toutes les clés étrangères correspondantes. Une suppression
d’une clé primaire aurait comme conséquence la suppression automatique de tous les enregistrements dont la
clé étrangère a la même valeur. Cette option est à utiliser avec précaution ! ! ! Remarque : En SQL la commande
CREATE TABLE nous offre les options ON DELETE CASCADE et ON UPDATE CASCADE.
III. Affectation d’une valeur par défaut aux clés étrangères concernées par une opération du type C ou D.
IV. Affectation d’une valeur indéterminée (NULL) aux clés étrangères concernées par une opération du type C ou D.
• La contrainte d’intégrité générale (angl. General Integrity Constraint) Une contrainte d’intégrité générale est utilisée
pour limiter les valeurs possibles d’un champ quelconque d’une table en fonction de la nature de celui-ci et de son rôle
dans le système d’information.
Il existe plusieurs variantes de cette contrainte.
A. A chaque champ correspond un type de données, une longueur et un format bien définis.
Exemple 44.
Le numéro client doit être une valeur numérique.
Le nom du client ne doit pas dépasser 25 caractères.
Un numéro de compte doit respecter le format X-XXX/XX-X
B. Un champ peut avoir un domaine de valeurs prédéfini (une plage de valeurs possibles) et/ou une valeur par défaut.
Exemple 45.
Une note d’un devoir en classe doit être entre 0 et 60
La prix d’une facture ne doit pas être un nombre négatif.
La date d’une commande doit automatiquement être la date actuelle à moins que l’utilisateur n’entre une autre
date.
C. La valeur d’un champ peut limiter les valeurs possibles pour un autre champ d’une table/d’une BD. Exemple 46.
La valeur du champ fldDatePaiement est supérieure ou égale à la valeur du champ fldDateFacture pour une table
tblFactures.
2.4.3 Exercices-TDs
Soit la BD représentée à la figure 2.59.
a) Quelle(s) contrainte(s) est(sont) concernée(s) lors de l’ajout d’un client ?
b) Quelle(s) contrainte(s) est(sont) concernée(s) lors de la suppression d’un client ?
c) Quelle(s) contrainte(s) est(sont) concernée(s) lors de l’ajout d’une facture ?
d) Quelle(s) contrainte(s) est(sont) concernée(s) lors de la suppression d’une facture ?
e) Quelle(s) contrainte(s) est(sont) concernée(s) lors de l’ajout d’un enregistrement dans la table tblConcerne ?
42
F IGURE 2.59
f) Quelle(s) contrainte(s) est(sont) concernée(s) lors de la suppression d’un enregistrement de la table tblConcerne ?
g) Quelle(s) contrainte(s) est(sont) concernée(s) lors de la modification du numéro d’un article dans la table des articles ?
h) Quelle(s) contrainte(s) est(sont) concernée(s) lors de la modification du numéro client d’une facture ?
Chapitre 3
Théorie de la normalisation et Algèbre

relationnelle
3.1 Les dépendances fonctionnelles & Normalisation

3.1.1 Les dépendances fonctionnelles
Définition 6. Soit R(U) une relation avec U l’ensemble de ses attributs. Soit X, Y ⊆ U , i.e X et Y sont deux attributs ou
ensemble d’attributs de R de domaine DX et DY .
On dit qu’il existe une dépendance fonctionnelle entre X et Y (ou que X détermine Y ou que Y est déterminé par X) notée
X −→ Y si et seulement si ∀t1 et t2 deux tuples de R, si t1 (X) = t2 (X) alors t1 (Y ) = t2 (Y )
Autrement dit, une relation u sur U satisfait X −→ Y , si quels que soient deux n-uplets t et t’ de u, si t(X) = t’(X) alors t(Y)
= t’(Y). Ou encore si à une valeur donnée de X correspond tout au plus à une valeur de B. A toute valeur x ∈ Dx, on ne
peut avoir qu ?une valeur unique y ∈ Dy.
Pour une dépendance fonctionnelle X −→ Y , S est la source et Y la cible.
Exemple 47.
Num Nom Prénom Adresse Téléphone
420 Bilongue Laurelle ... ...
421 Tiomo Bertrand ... . . . Dans cet exemple, on voit bien qu’on a N um −→ N om
512 Ngounou Adeline 19, rue Biyem-assi 222222222
815 Ngounou Roger 27, rue Biyem-assi 699244140
mais pas N um −→ N om car au nom Ngounou correspondent les Num 512 et 815.
Définition 7. Soit R(U) une relation et X, Y ⊂ U .
Y est une clef possible ou candidate si et seulement si on a X −→ Y où Y = U − X (i.e le complémentaire de X dans U).
Ainsi, la clef primaire d’une relation doit être choisie dans l’ensemble des clefs possibles de la relation.
S’il n’y en a aucune, tous les attributs de la relation constituent sa clef. On parle alors de relation ”toute clef”.
3.1.2 Propriétés des dépendances fonctionnelles

Soient X et Y deux ensembles d’attributs.
Réflexivité Si Y ⊆ Y , alors X −→ Y (et donc X −→ X)
Augmentation Si X −→ Y et W ⊆ Z, alors X, Z −→ Y, W
Transitivité Si X −→ Y et Y −→ Z, alors X −→ Z
Pseudo-transitivité Si X −→ Y et Y, Z −→ W , alors X, Z −→ W
Union Si X −→ Y et X −→ Z, alors X −→ Y, Z
Décomposition Si X −→ Y, Z alors X −→ Y et X −→ Z
Définition 8. Soit R(U) une relation et X, Y ⊂ U et X −→ Y .
On a une dépendance fonctionnelle totale (DFT) entre X et U, X −→ (DF T )Y , si et seulement si ∀X 0 ⊂ X, X 0 −→
(DF T )Y n’est pas vérifiée
44
Définition 9. Soit R(U) une relation et X, Y ⊂ U et X −→ Y .
On a une dépendance fonctionnelle totale (DFT) entre X et U, X −→ (DF T )Y , si et seulement si ∀X 0 ⊂ X, X 0 −→
(DF T )Y n’est pas vérifiée
Exemple 48.
U = (A, B, C, D =)
A B C D
a b c d
X= ? Y= ?
a’ b c d’
a b c’ d
u |= A −→ B u |= D −→ A (1)
u |= A −→ D u |= D −→ B (2)
u |= C −→ B u |= AD −→ B
(1) et (2) ⇒ u |= D −→ AB
Définition 10. Dépendance fonctionnelle élémentaire (DFE)
Soit G un groupe d’attributs et A un attribut, une DF X −→ Y est élémentaire si X n’est pas incluse dans Y et s’il n’existe
pas d’attribut X’ de X qui détermine A.
Exemple 49.
• AB −→ C est élémentaire si ni A, ni B pris individuellement ne déterminent C.
• Nom, DateNaissance, LieuNaissance −→ Prénom est élémentaire.
• AB −→ A n’est pas élémentaire car A est incluse dans AB.
• AB −→ CB n’est pas élémentaire car CB n’est pas un attribut, mais un groupe d’attributs.
• N˚SS −→ Nom, Prénom n’est pas élémentaire.

On peut toujours réécrire un ensemble de DF en un ensemble de DFE, en supprimant les DF triviales obtenues par
réflexivité et en décomposant les DF à partie droite non atomiques en plusieurs DFE. Exemple 50.
On peut réécrire les DF non élémentaires de l’exemple précédent en les décomposant en DFE. Ainsi :
• AB −→ A n’est pas considérée car c’est une DF triviale obtenu par réflexivité.
• AB −→ CB est décomposée en AB −→ C et AB −→ B, et AB −→ B n’est plus considérée car triviale.
• N˚SS −→ Nom, Prénom est décomposée en N˚SS −→ Nom et N˚SS −→ Prénom.
Définition 11. Fermeture transitive des DFE (DFE)

On appelle fermeture transitive F + d’un ensemble F de DFE, l’ensemble de toutes les DFE qui peuvent être composées par
transitivité à partir des DFE de F.
Exemple 51.
Soit l’ensemble F = {A −→ B, B −→ C, B −→ D, A −→ E}.
La fermeture transitive de F est F + = {A −→ B, B −→ C, B −→ D, A −→ E, A −→ C, A −→ D}
Définition 12. Couverture minimale des DFE
La couverture minimale d’un ensemble de DFE est un sous-ensemble minimum des DFE permettant de générer toutes les
autres DFE, par application un nombre fini de fois des propriétés des dépendances fonctionnelles.
Synonymes : Famille génératrice
Tout ensemble de DFE (et donc tout ensemble de DF) admet au moins une couverture minimale (et en pratique souvent
plusieurs).
Exemple 52.
L’ensemble F = {A −→ B, A −→ C, B −→ C, C −→ B} admet les deux couvertures minimales :
CM1 = {A −→ C, B −→ C, C −→ B} et CM2 = {A −→ B, B −→ C, C −→ B}
45
Définition 13. Graphe des DFE
On peut représenter un ensemble de DFE par un graphe orienté (ou plus précisément un réseau de Pétri), tel que les n ?uds
sont les attributs et les arcs les DFE (avec un seul attribut en destination de chaque arc et éventuellement plusieurs en
source).
Exemple 53.
1. On considère la relation Voiture(NVH, Marque, Type, Puis, Couleur) avec l’ensemble des DF F = {N V H −→
T ype, T ype −→ M arque, T ype −→ P uis, N V H −→ Couleur}. Une représentation de F par est donné par le
graphe de la figure 3.1
2. Soit la relation CodePostal(Code, Ville, Rue ) avec l’ensemble des DF F = {Code −→ V ille, (V ille, Rue) −→
Code}. Une représentation de F par est donné par le graphe de la figure 3.2
F IGURE 3.1 – Voiture(NVH, Marque, Type, Puis, Couleur)
F IGURE 3.2 – CodePostal(Code, Ville, Rue )
Théorème 1. Tout ensemble de dépendances fonctionnelles a une couverture minimale
En effet, à partir d’un ensemble de dépendances fonctionnelles, pour obtenir une couverture minimale, il faut procéder
comme suit :
1. Toute dépendance X −→ Y avec Y = {A1 , A2 , . . . , An } est remplacée par les dépendances X −→ A1 , X −→ A2 ,

. . . X −→ An
2. On élimine le plus de dépendances (redondantes) possibles
3. On élimine le plus d’attributs possibles des membres de gauche
N.B. En général, les couvertures minimales ne sont pas uniques.

Exemple 54.
Soit Y = {AB −→ C, C −→ A}, BC −→ D, ACD −→ B, D −→ EG, BE −→ C, CG −→ BD, CE −→ AG
1. Y = {AB −→ C, C −→ A}, BC −→ D, ACD −→ B, D −→ E, D −→ G, BE −→ C, CG −→ B, CG −→

D, CE −→ A, CE −→ G
2. On peut éliminer CE −→ A et CG −→ B
3. On peut remplacer ACD −→ B par CD −→ B.

46
3.1.3 Théorie de la normalisation relationnelle
Les formes normales ont pour objectif de définir la décomposition des schémas relationnels, tout en préservant les DF et
sans perdre d’informations, afin de représenter les objets et associations canoniques du monde réel de façon non redondante.
On peut recenser les 6 formes normales suivantes, de moins en moins redondantes :
• la première forme normale
• la deuxième forme normale
• la troisième forme normale
• la forme normale de Boyce-Codd
• la quatrième forme normale
• la cinquième forme normale
La troisième forme normale est généralement reconnue comme la plus importante à respecter. La BCNF est la plus simple à
établir.
Principe de la décomposition
L’objectif de la décomposition est de ”casser” une relation en relations plus petites afin d’en éliminer les redondances et
sans perdre d’information.
Définition 14. La décomposition d’un schéma de relation R(A1 , A2 , . . . , An ) est le processus de remplacement de ce
schéma par une collection de schémas R1 , R2 , . . . , Rn telle qu’il est possible de reconstruire R par des opérations relation-
nelles de jointure sur R1 , R2 , . . . , Rn .
Définition 15. Une décomposition d’une relation R en relations R1 , R2 , . . . , Rn préserve les DF si la fermeture transitive
F + des DF de R est la même que la fermeture transitive F + de l’union des DF de R1 , R2 , . . . , Rn .
Exemple 55.
Soit la relation Voiture(Numéro,Marque,Type,Puissance,Couleur) avec la fermeture transitive suivante : F + = {N umero −→
M arque, N umero −→ T ype, N umero −→ P uissance, N umero −→ Couleur, T ype −→ M arque, T ype −→
P uissance}
On peut décomposer Voiture en préservant les DF en deux relations R1(Numéro,Type,Couleur) et R2(Type,Puissance,Marque).
Première forme normale (1NF)

Une relation est en 1NF si elle possède au moins une clé et si tous ses attributs sont atomiques.
Définition 16. Un attribut est atomique si il ne contient qu’une seule valeur pour un tuple donné, et donc s’il ne regroupe
pas un ensemble de plusieurs valeurs.
Exemple 56.
On veut représenter une relation indiquant la profession d’une personne par la relation Personne(Nom, Profession)
On a les instanciations suivantes :
1 (Owona, Géomètre)
2 (Menom, Ingénieur-Professeur)
La relation n’est pas en 1NF, car l’attribut Profession peut contenir plusieurs valeurs.
Pour que la relation soit en 1NF, on pourrait par exemple ajouter Profession à la clé et faire apparaı̂tre deux tuples pour
Owona, on obtiendrait :
Personne(Nom, Profession)
47
1 (Owona, Géomètre)
2 (Menom, Ingénieur)
3 (Menom, Professeur)
Une autre solution aurait été d’ajouter un attribut ProfessionSecondaire. On obtiendrait ainsi :
Personne(Nom, Profession, ProfessionSecondaire)
(Menom, Ingénieur, Professeur)

(Owona, Géomètre, Null)
L’atomicité d’un attribut est souvent relative : on peut décider qu’un attribut contenant une date n’est pas atomique (et
que le jour, le mois et l’année constituent chacun une valeur), ou bien que l’attribut est de domaine date et donc qu’il est
atomique.
Le modèle relationnel impose qu’une relation ait une clé, donc la condition ”est en 1NF si elle possède une clé” est superflue
(au pire la relation est toute clé).
Il est néanmoins fondamental d’avoir identifié toutes les clés au début du processus de normalisation.
Deuxième forme normale (2NF)

Une relation est en 2NF si elle est en 1NF et si tout attribut n’appartenant à aucune clé candidate ne dépend pas d’une
partie seulement d’une clé candidate. Exemple 57.
On veut représenter la relation Personne(NumeroEmploye, Profession, Nom, Prenom, Salaire)
Soit les DF suivantes sur cette relation : N umeroEmploye, P rof ession −→ N om N umeroEmploye, P rof ession −→
P renom N umeroEmploye, P rof ession −→ Salaire P rof ession −→ Salaire Personne n’est pas en 2NF car Profes-
sion (une partie de clé) détermine Salaire (un attribut qui n’appartient pas à une clé). Pour avoir un schéma relationnel en
2NF, il faut alors décomposer Personne en deux relations :
Personne(NumeroEmploye, Profession=>Profession, Nom, Prenom)

Profession(Profession, Salaire)
On remarque que ce schéma est en 2NF (puisque Salaire dépend maintenant fonctionnellement d’une clé et non plus d’une
partie de clé).
On remarque aussi que la décomposition a préservé les DF, puisque nous avons à présent :
P rof ession −→ Salaire (DF de la relation Profession)
N umeroEmploye, P rof ession?P rof ession (par Réflexivité)
N umeroEmploye, P rof ession?Salaire (par Transitivité)
N.B. La définition de la 2NF doit être vérifiée pour toutes les clés candidates et non seulement la clé primaire (dans le
cas où il y a plusieurs clés). Si toutes les clés d’une relation ne contiennent qu’un unique attribut, et que la relation est en
1NF, alors la relation est en 2NF.
Troisième forme normale (3NF)

Une relation est en 3NF si elle est en 2NF et si tout attribut n’appartenant à aucune clé candidate ne dépend directement
que de clés candidates.
C’est à dire que toutes les DFE vers des attributs n’appartenant pas à une clé, sont issues d’une clé. Exemple 58.
On veut représenter la relation Profession(Profession, Salaire, Prime)
Soit les DF suivantes sur cette relation : P rof ession −→ Salaire P rof ession −→ P rime Salaire −→ P rime Personne
n’est pas en 3NF car Salaire, qui n’est pas une clé, détermine Prime. Pour avoir un schéma relationnel en 3NF, il faut
décomposer Profession :
Profession(#Profession, Salaire=>Salaire)
Salaire(#Salaire, Prime)
Ce schéma est en 3NF, car Prime est maintenant déterminé par une clé.
On remarque que cette décomposition préserve les DF, car par transitivité, Profession détermine Salaire qui détermine
Prime, et donc Profession détermine toujours Prime.
48
La définition concerne toutes les clés candidates et non uniquement la clé primaire.
Il est souhaitable que les relations logiques soient en 3NF. En effet, il existe toujours une décomposition sans perte d’infor-
mation et préservant les DF d’un schéma en 3NF. Si les formes normales suivantes (BCNF, 4NF et 5NF) assurent un niveau
de redondance encore plus faible, la décomposition permettant de les atteindre ne préserve plus systématiquement les DF.
Forme normale de Boyce-Codd (BCNF)

Une relation est en BCNF si elle est en 3NF et si les seules DFE existantes sont celles pour lesquelles une clé candidate
détermine un attribut. Exemple 59.
On veut représenter la relation Personne(N˚SS, Pays, Nom, Region)
Soit les DF suivantes sur cette relation : N˚SS, P ays −→ N om N˚SS, P ays −→ Region Region −→ P ays Il existe une
DFE qui n’est pas issue d’une clé et qui détermine un attribut appartenant à une clé. Cette relation est en 3NF, mais pas en
BCNF (car en BCNF toutes les DFE sont issues d’une clé).
Pour avoir un schéma relationnel en BCNF, il faut décomposer Personne :

Personne(N˚SS, Region, Nom)
Region(#Region, Pays)
Remarquons que les DF n’ont pas été préservées par la décomposition puisque N˚SS et Pays ne déterminent plus Région.
La BCNF est la forme normale la plus facile à appréhender intuitivement et formellement, puisque les seules DFE exis-
tantes sont de la forme K −→ A où K est une clé.
Par ailleurs, une décomposition en BCNF ne préserve pas toujours les DF.
Le premier langage étudié dans ce cours est l’algèbre relationnelle. Il consiste en un ensemble d’opérations qui permettent
de manipuler des relations, considérées comme des ensemble de tuples : on peut ainsi faire l’union ou la différence de deux
relations, sélectionner une partie de la relation, effectuer des produits cartésiens ou des projections, etc.
Une propriété fondamentale de chaque opération est qu’elle prend une ou deux relations en entrée, et produit une relation
en sortie. Cette propriété permet de composer des opérations : on peut appliquer une sélection au résultat d’un produit
cartésien, puis une projection au résultat de la sélection et ainsi de suite.
En fait on peut construire des expressions algébriques arbitrairement complexes qui permettent d’exprimer des manipulations
sur un grand nombre de relations.
Une requête est une expression algébrique qui s’applique à un ensemble de relations (la base de données) et produit
une relation finale (le résultat de la requête). On peut voir l’algèbre relationnelle comme un langage de programmation très
simple qui permet d’exprimer des requêtes sur une base de données relationnelle.
Dans tout ce chapitre on va prendre l’exemple de la (petite) base de données d’un organisme de voyage. Cet organisme
propose des séjours (sportifs, culturels, etc) se déroulant dans des stations de vacances. Chaque station propose un ensemble
d’activtés (ski, voile, tourisme). Enfin on maintient une liste des clients (avec le solde de leur compte !) et des séjours
auxquels ils ont participé avec leurs dates de début et de fin.
• Station (nomStation, capacité, lieu, région, tarif)
• Activite (nomStation, libellé, prix)
• Client (id, nom, prénom, ville, région, solde)
• Séjour (idClient, station, début, nbPlaces)
nomStation capacité lieu

nomStation libellé prix
nomStation capacité lieu région tarif
Venusa Voila 150
Venusa 350 Guadeloupe Antilles 1200
Venusa Plongée 120
Farniente 200 Seychelles Océan indien 1500
Farniente Plongée 130
Santalba 150 Guadeloupe Antilles 2000
Passac Ski 200
Passac 400 Alpes Europe 1000
Passac Piscine 20
Table Station
Santalba Kayac 50
Table Activité
49
idClient Station début nbPlaces
10 Passac 1998/07/01 2
30 Santalba 1996/08/14 5
id nom prénom ville région solde
20 Santalba 1998/08/03 4
10 Fogg Phileas Londres Europe 12465
30 Passac 1998/08/15 3
20 Pascal Blaise Paris indien Europe 6763
30 Venusa 1998/08/03 3
30 Kerouac Jack New York Amérique 9812
20 Venusa 1998/08/03 6
Table Client
30 Farniente 1999/06/24 5
10 Farniente 1998/09/05 3
Table Séjour
3.2 L’algèbre relationnelle

L’algèbre relationnelle est le support mathématique cohérent sur lequel repose le modèle relationnel. L’algèbre relation-
nelle propose un ensemble d’opérations élémentaires formelles sur les relations dans le but de créer de nouvelles relations.
Ces opérations permettent de représenter des requêtes sur la base de données dont le résultat s’exprime sous la forme d’une
relation (i.e. table). C’est ce formalisme qui est au c ?ur du langage de requête de SQL.
Nous pouvons distinguer trois familles d’opérateurs relationnels :

• Les opérateurs unaires (la sélection et la projection), qui sont les plus simples, permettent de produire une nouvelle
table à partir d’une autre table.
• Les opérateurs binaires ensemblistes (l’union, l’intersection et la différence) permettent de produire une nouvelle
relation à partir de deux relations de même degré et de même domaine.
• Les opérateurs binaires ou n-aires (le produit cartésien, la jointure et la division) permettent de produire une nouvelle
table à partir de deux ou plusieurs autres tables.
Remarque : Les notations de l’algèbre relationnelle ne sont pas standardisées.
L’algèbre se compose d’un ensemble d’opérateurs, parmi lesquels 5 sont nécessaires et suffisants et permettent de définir
les autres par composition. Ce sont :
1. La sélection, dénotée σ ;
2. La projection, dénotée π ;
3. Le produit cartésien, dénoté × ;
4. L’union, ∪ ;
5. La différence, − .
Les deux premiers sont des opérateurs unaires (ils prennent en entrée une seule relation) et les autres sont des opérateurs
binaires. A partir de ces opérateurs il est possible d’en définir d’autres, et notamment la jointure, ./ , qui est la composition
d’un produit cartésien et d’une sélection. Ces opérateurs sont maintenant présentés tour à tour.
3.2.1 La sélection, σ
La sélection σF (R) s’applique à une relation, R , et extrait de cette relation les tuples qui satisfont un critère de sélection,
F. Ce critère peut être :
• La comparaison entre un attribut de la relation, A, et une constante a. Cette comparaison s’écrit AΘa , où Θ peut être
¡, ¿, ≤ ou ≥
• La comparaison entre deux attributs A1 et A2 , qui s’écrit A1 ΘA2 avec les mêmes opérateurs de comparaison que
précédemment.
Premier exemple : exprimer la requête qui donne toutes les stations aux Antilles.
σF région =0 Antilles0 (Station)
On obtient donc le résultat : La sélection a pour effet de supprimer des lignes, mais chaque ligne garde l’ensemble de ses
attributs.
50
nomStation capacité lieu région tarif
Venusa 350 Guadeloupe Antilles 1200
Santalba 150 Guadeloupe Antilles 2000
3.2.2 La projection, π
La sélection πA1 ,A2 ,·,Ak (R) s’applique à une relation, R , et ne garde que les attributs A1 , A2 , ·, Ak .
Donc, contrairement à la sélection, on ne supprime pas des lignes mais des colonnes.
Exemple : donner le nom des stations, et leur région.
πnomStation,région (Station)
On obtient le résultat suivant, après suppression des colonnes capacité, lieu et tarif :
nomStation région
Venusa Antilles
Farniente Océan indien
Santalba Antilles
Passac Europe
En principe le nombre de lignes dans le résultat est le même que dans la relation initiale. Il y a cependant une petite sub-
tilité : comme le résultat est une relation, il ne peut pas y avoir deux lignes identiques (il n’y a pas deux fois le même élément
dans un ensemble). Il peut arriver qu’après une projection, deux lignes qui étaient distinctes initialement se retrouvent iden-
tiques, justement parce ce que l’attribut qui permettait de les distinguer a été supprimé. Dans ce cas on ne conserve qu’une
seule des deux (ou plus) lignes identiques.
Exemple : on souhaite connaı̂tre toutes les régions où il y a des stations. On exprime cette requête par :
πm boxregion(Station)
On obtient le résultat suivant, après suppression des colonnes capacité, lieu et tarif :
région
Antilles
Océan indien
Europe
La ligne ’Antilles’ était présente deux fois dans la relation Station, et n’apparaı̂t plus qu’en un seul exemplaire dans le
résultat.
3.2.3 Le produit cartésien, ×

Le premier opérateur binaire, et le plus utilisé, est le produit cartésien, ×. Le produit cartésien entre deux relations R et
S se note R × S, et permet de créer une nouvelle relation où chaque nuplet de R est associé à chaque nuplet de S.
Voici deux relations, la première, R, contient
C D
A B
c d
a b
u v
x y
x y
Et voici le résultat de R × S
Le nombre de lignes dans le résultat est exactement |R| × ×|S| (—R— dénote le nombre de lignes dans la relation R).
En lui-même, le produit cartésien ne présente pas un grand intérêt puisqu’il associe aveuglément chaque ligne de R à chaque
ligne de S. Il ne prend vraiment son sens qu’associé à l’opération de sélection, ce qui permet d’exprimer des jointures,
opération fondamentale qui sera détaillée plus loin.
51
A B C D
a b c d
a b u v
a b x y
x y c d
x y u v
x y x y
R×S
Renommage
Quand les schémas des relations R et S sont complètement distincts, il n’y a pas d’ambiguité sur la provenance des
colonnes dans le résultat. Par exemple on sait que les valeurs de la colonne A dans R × S viennent de la relation R. Il peut
arriver (il arrive de fait très souvent) que les deux relations aient des attributs qui ont le même nom. On doit alors se donner
les moyens de distinguer l’origine des colonnes dans la table résultat en donnant un nom distinct à chaque attribut.
Voici par exemple une table T qui a les mêmes noms d’attributs que R. Le schéma du résultat du produit cartésien R × T
A B
m n
o p
a pour schéma (A,B,A,B) et présente donc des ambiguités, avec les colonnes A et B en double.
La première solution pour lever l’ambiguité est d’adopter une convention par laquelle chaque attribut est préfixé par le
nom de la table d’où il provient. Le résultat de R × T devient alors :
R.A R.B T.A T.B

a b m n
a b n p
x y u n
x y n p
R×T
Cette convention pose quelques problèmes quand on crée des expressions complexes. Il existe une seconde possibilité,
plus rigoureuse, pour résoudre les conflits de noms : le renommage. Il s’agit d’un opérateur particulier, dénoté ρ, qui permet
de renommer un ou plusieurs attributs d’une relation. L’expression ρA→C,B→D (T ) permet ainsi de renommer A en C et B
en D dans la relation T. Le produit cartésien R × ρA→C,B→D (T ) ne présente alors plus d’ambiguités. ρA Le renommage est
une solution très générale, mais assez lourde à utiliser.
Il est tout à fait possible de faire le produit cartésien d’une relation avec elle-même. Dans ce cas le renommage où l’uti-
lisation d’un préfixe distinctif est impératif. Voici par exemple le résultat de R × R, dans lequel on préfixe par R1 et R2
respectivement les attributs venant de chacune des opérandes.
R1.A R1.B R2.A R2.B

a b a b
a b x y
x y a b
x y x y
3.2.4 L’union, ∪
Il existe deux autres opérateurs binaires, qui sont à la fois plus simples et moins fréquemment utilisés. Le premier est
l’union. L’expression R ∪ S crée une relation comprenant tous les nuplets existant dans l’une ou l’autre des relations R et S.
Il existe une condition impérative : les deux relations doivent avoir le même schéma, c’est-à-dire même nombre d’attributs,
mêmes noms et mêmes types.
52
L’union des relations R(A,B) et S(C,D) données en exemple ci-dessus est donc interdite (on ne saurait pas comment
nommer les attributs dans le résultat). En revanche, en posant S? = ρC→A,D→B (S), il devient possible de calculer R ∪ S 0 ,
avec le résultat suivant : Comme pour la projection, il faut penser à éviter les doublons. Donc le nuplet (x,y) qui existe à la
A B
a b
x y
c d
u v
S? = ρC→A,D→B (S)
fois dans R et dans S ? ne figure qu’une seule fois dans le résultat.
3.2.5 La différence, ?
Comme l’union, la différence s’applique à deux relations qui ont le même schéma. L’expression R ?S a alors pour résultat
tous les nuplets de R qui ne sont pas dans S.
Voici la différence de R et S ?, les deux relations étant définies comme précédemment. La différence est le seul opérateur
A B
a b
R−S
qui permet d’exprimer des requêtes comportant une négation (on veut ?rejeter ? quelque chose, on ?ne veut pas ? des lignes
ayant telle propriété). Il s’agit d’une fonctionnalité importante et difficile à manier : elle sera détaillée plus loin.
3.2.6 La jointure, ./
Toutes les requêtes exprimables avec l’algèbre relationnelle peuvent se construire avec les 5 opérateurs présentés ci-
dessus. En principe, on pourrait donc s’en contenter. En pratique, il existe d’autres opérations, très couramment utilisées, qui
peuvent se contruire par composition des opérations de base. La plus importante est la jointure.
Afin de comprendre l’intérêt de cet opérateur, regardons le produit cartésien Station ./ Activité.
Le résultat comprend manifestement un grand nombre de lignes qui ne nous intéressent pas. Cela ne présente pas beau-
coup de sens de rapprocher des informations sur Santalba, aux Antilles et sur l’activité de ski à Passac.
Si, en revanche, on considère le produit cartésien comme un résultat intermédiaire, on voit qu’il permet de se ramener
au cas où on effectue, par une simple sélection, des rapprochements de lignes distinctes. Sur notre exemple, en considérant
la table ci-dessus comme une table de la base, on rapproche les informations générales sur une station et la liste des activités
de cette station.
La sélection qui effectue un rapprochement pertinent est la suivante :
σF id = idStation(Station ./ Activité)
Prenez bien le temps de méditer cette opération de sélection : nous ne voulons conserver que les lignes de Station ./ Activité
pour lesquelles l’identifiant de la station (provenant de Station) est identique à celui provenant de Activité. En regardant le
produit cartésien ci-dessous, vous devriez pouvoir vous convaincre que cela revient à conserver les lignes qui ont un sens :
chacune contient des informations sur une station et sur une activité dans cette même station. Si vous saisissez cette logique,
vous avez fait un grand pas dans la connaissance des bases relationnelles : consacrez-y le temps de réflexion nécessaire.
En consultant les résultats, on constate qu’on a donc effectué une composition de deux opérations (un produit cartésien,
une sélection) afin de rapprocher des informations réparties dans plusieurs tables, mais ayant des liens entre elles (toutes
les informations dans un nuplet du résultat sont relatives à une seule station). Cette opération est une jointure, que l’on peut
directement, et simplement, noter :
Station ./id=idStation Activité
53
La jointure consiste donc à rapprocher les lignes de deux relations pour lesquelles les valeurs d’un (ou plusieurs) attributs
sont identiques. De fait, dans la plupart des cas, ces attributs communs sont (1) la clé primaire de l’une des relations et (2)
la clé étrangère dans l’autre relation. Dans l’exemple ci-dessus, c’est le cas pour id (clé primaire de Station) et idStation (clé
étrangère dans Activité). La jointure permet alors de reconstruire l’association conceptuelle entre Station et Activité.
Remarque
La station Santalba, qui ne propose pas d’activité, n’apparaı̂t pas dans le résultat de la jointure. C’est normal et conforme
à la définition que nous avons donnée, mais peut parfois apparaı̂tre comme une contrainte. Nous verrons que SQL propose
une variante, la jointure externe, qui permet de la contourner.
La notation de la jointure, R ./F S, est un racourci pour σ(R ./F S). Le critère de rapprochement, F, peut être n’im-
porte quelle opération de comparaison liant un attribut de R à un attribut de S. En pratique, on emploie peu les 6= ou < qui
sont difficiles à interpréter, et on effectue des égalités.
Remarque
Si on n’exprime pas de critère de rapprochement, la jointure est équivalente à un produit cartésien.
Il faut être attentif aux ambigüités dans le nommage des attributs qui peut survenir dans la jointure au même titre que
dans le produit cartésien. Les solutions à employer sont les mêmes : on préfixe par le nom de la relation ou par un synonyme
clair, ou bien on renomme des attributs avant d’effectuer la jointure.
3.2.7 Expression de requêtes avec l’algèbre

Cette section est consacrée à l’expression de requêtes algébriques complexes impliquant plusieurs opérateurs. On utilise
la composition des opérations, rendue possible par le fait que tout opérateur produit en sortie une relation sur laquelle on
peut appliquer à nouveau des opérateurs.
Chapitre 4
Les systèmes de gestion de bases de données
4.1 Définitions
Une base de données (BD) est un ensemble bien structuré de données relatives à un sujet global. Ces données peuvent
être de nature et d’origine différentes.
Exemple 60.
Une banque peut avoir une BD, qui contient les informations nécessaires sur tous les clients et leurs dépôts d’épargne. Une
société d’assurances peut stocker les données relatives aux contrats d’assurances ainsi qu’aux sinistres dans une BD.
Un système de gestion de bases de données (SGBD) est un programme qui nous permet de créer, de modifier et
d’exploiter des bases de données. Ce système constitue donc notre interface pour accéder aux données.
Un utilisateur utilise un SGBD pour accéder aux données d’une base de données.
F IGURE 4.1
Par analogie :
Un utilisateur utilise un tableur pour accéder aux données d’une feuille de calcul, respectivement un traitement de texte
pour accéder le texte d’un document.
Exercice 17.
56
Discutez les avantages et désavantages d’une gestion de données informatisées à l’aide d’un SGBD, et comparez cette gestion
à la gestion non informatisée.
4.2 Un peu d’histoire

Avant les années ’70, la plupart des systèmes qui permettaient de gérer des grands volumes de données d’une façon plus
ou moins cohérente étaient basés sur de simples fichiers séquentiels. Ces systèmes de gestion de fichiers (SGF) s’avéraient
particulièrement limités lorsqu’il s’agissait de gérer une grande masse de données comportant des liens entre elles.
Classiquement, cette masse de données était répartie dans différents fichiers. L’utilisation de ces données n’était possible
que par le biais de programmes spécialisés, qui ont du être réalisés par des programmeurs ayant une connaissance tech-
nique approfondie de la structure des fichiers. Chaque nouvelle interrogation du SGF nécessitait donc l’intervention d’un
programmeur.
En plus, les SGF n’ont pas assuré la cohérence des données. Le programmeur était seul responsable pour garantir
l’intégrité des données. Prenons l’exemple d’un SGF qui était utilisé dans une banque pour la gestion des clients et de
leurs dépôts. Rien n’empêchait un programmeur de créer dans le fichier des dépôts un nouveau dépôt pour un client qui
n’existait pas du tout dans le fichier des clients etc.
Ceci étant seulement quelques exemples des inconvénients des SGF, nous remarquons qu’il était difficile pour un utilisa-
teur d’utiliser directement un tel système. Il fallait souvent l’intervention d’un programmeur, qui devait faire bien attention
à préserver la structure des données dans un rapport cohérent, tout en satisfaisant les besoins d’informations de l’utilisateur.
Déjà vers la fin des années 60, les premiers systèmes qui étaient capables de cacher la représentation interne des données
à l’utilisateur, apparaissaient sur le marché. Ces systèmes, qui offraient à l’utilisateur une certaine structure logique pour
stocker les données, étaient déjà équipés de certains mécanismes de base pour assurer la cohérence des données via des
règles qui pouvaient être définies par l’utilisateur. Le système vérifiait ces règles lors de chaque modification des données.
Dans un système de gestion des dépôts d’une banque, une telle règle pouvait par exemple exprimer le lien explicite entre un
dépôt client et une personne. Ces systèmes étaient essentiellement basés sur les deux modèles de données suivants :
Modèle réseau développé initialement par la ”Conference On Data Systems and Languages” (CODASYL) en 1961
Modèle hiérarchique développé pour la plus grande partie par la société IBM pendant les années 1965 - 1970
C’était en 1970 qu’un nouveau modèle pour représenter les données, le modèle relationnel, fut proposé par E.F.CODD.
Le but de ce modèle, était d’accroı̂tre l’indépendance vis-à-vis de l’implémentation interne des données. Du point de vue
de l’utilisateur, les données sont stockées dans un ensemble de tableaux, appelées ”tables relationnelles” ou simplement
”tables”. Le stockage ainsi que la manipulation des données se basent sur le concept mathématique de l’algèbre relationnelle
et du calcul relationnel. Ces concepts proviennent de la théorie mathématique des ensembles, et on y retrouve des notions
telles que ”Union”, ”Intersection” ou ”Produit cartésien”.
Il a fallu attendre le milieu des années 70 pour voir apparaı̂tre les premiers systèmes qui étaient basés sur le modèle
relationnel, les ”Systèmes de Gestion de Bases de Données Relationnelles (SGBDR)”.
En 1976 apparaı̂t le modèle Entité-Association, proposé par P.CHEN, qui donnait aux concepteurs des bases de données
relationnelles une méthode adéquate pour modéliser des données d’un domaine quelconque (banques, assurances, industrie
. . . ) par une structure bien cohérente de tables relationnelles. Le modèle Entité - Association devenait ainsi le modèle
théorique de conception de données sur lequel se basaient beaucoup de bases de données relationnelles.
Pendant les années 80 et 90, beaucoup de SGBDR étaient commercialisés pour les différentes plates-formes informa-
tiques (Mainframe, Serveurs UNIX, Serveurs VMS, PC...). Citons quelques exemples de SGBDR populaires qui tournent
actuellement sur PC : Personal ORACLE MS-ACCESS Visual dBASE Visual FOXPRO Borland PARADOX Lotus AP-
PROACH
Aujourd’hui, les bases de données relationnelles se réjouissent d’une grande popularité. Surtout le domaine de la gestion
des données à l’intérieur des entreprise est entièrement dominé par ces systèmes.
Pour la suite de ce cours, nous allons nous limiter à l’étude des bases de données relationnelles. Nous entendons donc
par chaque référence à une base de données (BD), la notion de base de données relationnelle. Il est également sous-entendu
que les deux notions SGBD et SGBDR dénotent un système de gestion de bases de données relationnelles dans le contexte
de ce cours.
4.3 Les composants d’une base de données relationnelle

Une base de données relationnelle contient en général quatre types de composants (d’objets). Nous allons brièvement
introduire ces types d’objets sans aller trop dans les détails. A chacun de ces objets sera consacré un chapitre séparé.
57
1. Les données sont stockées à l’intérieur de tables. Une table peut être comparée à une liste, qui contient des enregistre-
ments relatifs à un domaine bien défini.
Exemple 61.
Le service du personnel de l’entreprise SCHAFFGAER S.à r.l. entretient une BD avec en outre une table pour
les données des employées. Cette table contient un enregistrement pour chaque employé, avec le nom, le prénom,
l’adresse, la localité, la date de naissance, la date d’entrée en service, le salaire mensuel et le nom du département
auquel l’employé est actuellement affecté.
F IGURE 4.2
2. Les requêtes constituent dans un certain sens des ”questions” qu’on pose au SGBD. Le résultat d’une requête est
toujours un sous-ensemble d’une ou de plusieurs tables. Exemple 62.
Le chef du personnel de l’entreprise SCHAFFGAER S. à r.l. désire connaı̂tre les noms, prénoms, adresses et localités
des employés recrutés en 1996. Il doit formuler une requête qui sera exécutée par le SGBD, et qui donnera comme
résultat une liste semblable à la table des employés, mais contenant uniquement les employés qui vérifient le critère
de sélection de la requête, et pour chacun de ces employés seulement les informations demandées.
Voici le résultat de cette requête :
F IGURE 4.3
3. Les formulaires sont utilisés pour ajouter, modifier ou supprimer des données dans les tables. Bien que la plupart
des SGBD nous permettent d’accéder les données directement dans les tables, les formulaires nous offrent certains
avantages en ce qui concerne la facilité d’utilisation, mais également la sécurité des données. Exemple 63.
La secrétaire du chef du personnel utilise un formulaire pour ajouter ou supprimer un employé de la BD. Ce formulaire
lui permet également de modifier les données d’un employé.
4. Souvent on veut imprimer des statistiques ; concernant certaines données d’une BD. C’est ici qu’interviennent les
rapports. Les rapports sont similaires aux formulaires, à la différence près, qu’ils sont uniquement destinés à être
imprimés et qu’il n’y a pas de dialogue interactif avec l’utilisateur. Un rapport se base généralement sur une ou
plusieurs tables ou bien le résultat d’une requête. Exemple 64.
A la fin de chaque mois le chef du personnel reçoit un rapport avec pour chaque département, la liste des employés,
leur salaire mensuel ainsi que le salaire mensuel total payé par département.
4.4 Structures physiques et logiques

Un SGBD utilise les ressources de l’ordinateur sur lequel il est exécuté. Les données des SGBD sont ainsi stockées par
exemple sur un disque dur ou sur un autre support de stockage, de la même façon que les autres fichiers, générés par les
autres programmes (p.ex. Traitement de texte, Tableur ?) qui tournent sur l’ordinateur.
58
F IGURE 4.4
F IGURE 4.5
4.4.1 Structures physiques

Le système d’exploitation (p.ex. DOS, Windows, Windows NT ?), qui connaı̂t seulement la notion de fichier en ce qui
concerne le stockage des données, ignore en principe le contenu de ces fichiers. Les fichiers constituent dans un certain sens
la structure physique des données.
Chaque programme crée des fichiers ayant un format spécifique à ce programme. L’utilisateur peut reconnaı̂tre le format
par l’extension derrière le nom du fichier.
Exemple 65.
• .doc → fichier MS-Word

59
• .xls → fichier MS-Excel
4.4.2 Structures logiques

Chaque programme offre également à l’utilisateur la possibilité de manipuler des composants, qui existent seulement
dans le contexte de ce programme.
Exemple 66.
• Document → Composant logique de MS-Word

• Feuille de calcul → Composant logique de MS-Excel
• Classeur → Composant logique de MS-Excel
Ces composants ou structures logiques sont uniquement visibles par le biais du programme correspondant. Définis au
chapitre précédent 1, les composants standard d’un SGBD sont :
• Les tables
• Les requêtes
• Les formulaires
• Les rapports
4.4.3 Relation entre structure physique et structure logique

Cette relation dépend du programme.
MS-Word : Chaque document (composant logique) correspond en principe à un fichier .doc (structure physique).
MS-Excel : Chaque classeur (composant logique) correspond à un fichier .xls (composant physique). Attention : Un clas-
seur peut contenir plusieurs feuilles de calcul.
En ce qui concerne les SGBD, il existe deux variantes :
1. Chaque composant (table, formulaire ?) d’une BD est stocké dans un fichier séparé. Une base de données constitue
donc un ensemble de fichiers. Exemple : dBASE
2. Tous les composants d’une BD sont intégrés dans un seul fichier. Exemple 67.
MS-Access
Exercice 18.
Discutez les avantages et désavantages des deux concepts d’implémentation possibles pour les composants d’une BD.
4.5 Les réseaux informatiques

A son niveau le plus élémentaire, un réseau se compose de plusieurs ordinateurs reliés entre eux par un câble, afin de
pouvoir échanger des données et partager des ressources, tels que des imprimantes, de l’espace disque etc.
Dans le contexte d’un réseau, ces ordinateurs sont appelés postes de travail (angl. workstation). Les postes de travail
peuvent être répartis sur plusieurs étages d’un bâtiment ou même sur plusieurs bâtiments voisins. Un tel réseau est appelé
réseau local (angl. LAN = Local Area Network).
Afin de pouvoir être connecté à un réseau, un ordinateur doit disposer d’une carte réseau 1 . Ce dispositif est la liai-
son physique entre l’ordinateur et le réseau. Elle réunit les données à envoyer sous forme de paquets et contrôle les flux
d’information de et vers le réseau. Une illustration est donnée à la figure
La plupart des réseaux locaux contiennent des ordinateurs très puissants en termes de vitesse d’exécution et de capacité
de stockage. Ces ordinateurs, encore appelés serveurs dédiés (angl. Server), ne sont généralement pas utilisés comme poste
de travail, mais ils doivent effectuer un certain nombre de tâches variées.
On distingue plusieurs types de serveurs.
1. On dit aussi simplement ”Carte Réseau”
60
F IGURE 4.6 – un LAN
F IGURE 4.7 – Une carte réseau
F IGURE 4.8
Les serveurs de fichiers (angl. File Server) Les serveurs de fichiers (angl. File Server) contiennent généralement des fi-
chiers appartenant aux différents utilisateurs du réseau. Par exemple, si vous utilisez un programme de traitement de
texte sur un poste de travail, ce programme se trouve localement sur le poste. Cependant, le document sur lequel vous
désirez effectuer des modifications, stocké sur le serveur, est chargé dans la mémoire locale de votre poste de travail,
afin que vous puissiez l’utiliser. Lors de chaque opération de sauvegarde (angl. Save/Save As), le fichier est effective-
ment sauvegardé sur le serveur. Le serveur gère bien sûr l’accès des utilisateurs, qui doivent généralement s’identifier
61
par un nom et un mot de passe, afin de garantir une certaine sécurité des données.
Les serveurs d’impression (angl. Print Server) effectuent la gestion des imprimantes connectées au réseau. Lorsque le
réseau comporte une multitude d’imprimantes différentes, un utilisateur sur son poste de travail peut sélectionner
une imprimante en fonction des caractéristiques (p.ex. impression couleur/NB), des capacités (p.ex. nombre de pages
imprimées par minute) et de l’emplacement physique (p.ex. imprimante à la même étage que le poste de travail). Lors
de l’impression (angl. Print), le document à imprimer est d’abord envoyé dans une file d’attente (angl. Print Queue) qui
se trouve sur le serveur d’impression. Le serveur d’impression contient généralement une file d’attente par imprimante.
Les documents d’une file d’attente sont envoyés un après l’autre vers l’imprimante correspondante.
Les serveurs d’impression (angl. Print Server) contiennent des applications ou programmes destinés à l’utilisation en
réseau. Un exemple populaire constituent les applications du type ”Groupware”, qui permettent aux utilisateurs du
réseau d’échanger des messages électroniques (angl. E-Mail), d’entretenir un agenda électronique commun et de tra-
vailler soi-disant en même temps sur des document partagés. Les serveurs de bases de données (angl. Database
Server), appartenant également à cette catégorie, sont très répandues. Avant la période où les PC devenaient popu-
laires, les bases de données ainsi que les programmes pour les manipuler, se trouvaient sur des grands ordinateurs
puissants du type ”Mainframe”. L’utilisateur était connecté au mainframe à l’aide d’un terminal composé d’un clavier
et d’un écran. Contrairement à un PC, un terminal peut uniquement envoyer des caractères au mainframe et afficher
les caractères, qui lui sont envoyés par le mainframe. Avec l’arrivée des PC, dont les fonctionnalités ne se limitent pas
à l’envoi et à l’affichage de caractères, le rôle des serveurs a considérablement changé. Actuellement, dans les environ-
nements dits ”Client/Serveur”, les PC constituent des clients ”intelligents”, qui sont en parfaite communication avec
les serveurs, dont le but principal est de ”répondre” aux questions qui leurs sont posées par les clients. L’architecture
Client/Serveur est explicitée plus en détail dans la section 4.5.1.
Les réseaux informatiques ayant une certaine taille, en termes du nombre de postes et de serveurs, sont généralement
gérés par un administrateur réseau, personne (ou groupe de personnes) en charge de la gestion, du contrôle et de l’entretien
du réseau.
Lorsque la distance géographique couverte par un réseau augmente en connectant des utilisateurs situés par exemple
dans des villes ou même des pays différents, plusieurs réseaux locaux sont connectés en un seul réseau étendu (angl. WAN
= Wide Area Network), qui peut ainsi regrouper plusieurs milliers d’utilisateurs.
F IGURE 4.9
En utilisant de l’équipement réseau spécialisé dans ce domaine, on peut connecter plusieurs réseaux locaux via un réseau
public. Ce réseau public peut par exemple être constitué du réseau téléphonique public, d’un ensemble de lignes louées
62
(lignes dédiées), d’un réseau de câbles en fibre optique, d’un réseau rapide de commutation de paquets ou même d’une
liaison par satellite.
A titre d’exemple, on peut mentionner l’Internet, qui n’est rien d’autre qu’un gigantesque réseau étendu.
Pour un utilisateur, le travail dans un réseau local ou étendu est tout à fait transparent. Il peut par exemple accéder à des
fichiers distants de la même manière qu’à des fichiers qui se trouvent sur son disque dur local.
4.5.1 L’approche Client/Serveur

La période des ordinateurs du type ”Mainframe”
Avant la période où les PC devenaient populaires, les bases de données ainsi que les programmes pour les manipuler ;
se trouvaient sur de grands ordinateurs puissants du type ”mainframe”. On parlait d’une architecture centralisée, puisque les
BD, le SGBD et les objets tels que requêtes, formulaires, rapports étaient stockés sur le ”mainframe”.
L’utilisateur était connecté au ”mainframe” à l’aide d’un terminal composé d’un clavier et d’un écran. Contrairement à un
PC, un terminal ne possède aucune ”intelligence” propre, c.à.d. qu’il peut uniquement envoyer des caractères au ”mainframe”
et afficher les caractères, qui lui sont envoyés par le ”mainframe”, et ceci en plus uniquement en mode caractère1.
Lorsque l’utilisateur veut par exemple afficher un formulaire, la construction du formulaire se fait complètement sur
le ”mainframe”. Ensuite, le formulaire où plutôt l’apparence du formulaire est envoyé via le réseau vers le terminal de
l’utilisateur.
Exemple 68.
Un formulaire en mode caractère (Cf. Figure 4.10)
F IGURE 4.10
Avantages de l’architecture ”mainframe” • Les ”mainframe” étant de grands ordinateurs très puissants, les systèmes
atteignent de très belles performances, d’autant plus qu’il n’y a pas de représentation graphique sur les terminaux.
Inconvénients de l’architecture ”mainframe” • Aucune capacité de calcul sur le terminal, donc impossible d’exécuter
des programmes sur le terminal.
• Pas de représentation graphique sur le terminal. Formulaires etc. moins faciles à utiliser.
• Le ”mainframe” étant sous la seule gestion du service informatique, les utilisateurs peuvent uniquement accéder
les BD via des formulaires etc. créés par les informaticiens. (Cette mesure s’avère parfois avantageuse ?)
• Le réseau est assez chargé, surtout lorsque le nombre de terminaux accroı̂t.
• Les requêtes, formulaires etc. sont fortement couplés au SGBD ce qui les rend pratiquement inutilisable lors-
qu’une société veut migrer vers un autre SGBD.
Exemple 69.
SGBD pour ”Mainframe” :
• DB2 de IBM
• RDB de DEC
63
F IGURE 4.11 – Architecture ”Mainframe”
En fait, les informaticiens sont depuis longtemps à la recherche de systèmes ouverts. La finalité d’un système ouvert
consiste dans le fait que ses composants (ordinateurs, SGBD etc.) sont échangeables sans que tous les objets en utilisation
(requêtes, formulaires etc.) doivent être complètement redéfinis resp. reprogrammés. Tous les éléments d’un tel système
doivent donc supporter au maximum possible certains standards. Un élément important de la philosophie des systèmes
ouverts est constitué par l’approche Client/Serveur.
L’approche Client/Serveur
L’évolution historique des architectures informatiques vers les architectures du type Client/Serveur (angl. Client/Server)
dans les années ’90 ; peut être ramenée surtout aux facteurs suivants.
• L’arrivée au marché des PC.
• L’apparition de serveurs, machines moins chères et moins spacieuses que les ”mainframe”, avec cependant une capa-
cité de calcul et de stockage analogue à celle des ”mainframe”.
• L’émergence de systèmes d’exploitations standardisés tels que UNIX ou Windows NT.
• L’apparition des SGBD indépendants de la plate-forme 2 et disponible pour tous les systèmes d’exploitation standar-
disés
L’approche Client/Serveur implémente une décentralisation des applications BD. En fait, les BD sont gérées sur un
serveur BD, tandis que les interfaces pour visualiser et manipuler les données (p.ex. formulaires, rapports) se trouvent sur
les PC client, dans un environnement ergonomique 3 .
2. par plate-forme, on entend l’ordinateur sur lequel est exécuté le SGBD
3. plus facile à utiliser
64
Sur le poste client se trouve donc en principe un SGBD client, offrant toutes les fonctionnalités requises, qui émet des
requêtes formulées dans un langage d’interrogation de données 4 au serveur BD via le réseau. Le serveur exécute les requêtes
qui lui ont été transmises et renvoie le résultat au client. Le client représente alors le résultat en se servant par exemple d’un
formulaire ou d’un rapport qui a été défini antérieurement.
F IGURE 4.12 – Architecture ”Client/Serveur”
Avantages de l’architecture Client/Serveur :

• Les utilisateurs deviennent des clients avec des postes de travail intelligents (PC), à l’aide desquels ils peuvent connec-
ter les applications bureautiques directement aux serveurs BD, afin de gérer dans un environnement convivial les
données de l’entreprise, sans être dépendant des services d’un informaticien pour résoudre le moindre problème.
• Les réseaux informatiques modernes permettent un accès transparent à plusieurs serveurs BD, et ceci même de façon
simultanée.
• Une partie de la capacité de travail est partagée entre les serveurs et les clients, ce qui crée un certain équilibre.
• Une panne du serveur n’empêche pas nécessairement tous les utilisateurs de travailler avec l’outil informatique. Cer-
tains travaux peuvent être exécutés sans connexion au serveur.
• L’architecture Client/Serveur, reposant sur les systèmes ouvert, offre en plus l’avantage qu’il existe toute une panoplie
de logiciels standards, ce qui crée un marché multivendeur et une offre de produits équilibrée.
Exemple 70.
SGBD Client/Serveur :
• Côté serveur : Oracle, Sybase, Informix, MS-SQL-Server
• Côté client : BORLAND Paradox, Personal Oracle, MS-Access
4. par exemple SQL (voir section SQL)

Chapitre 5
Les tables
5.1 Introduction
Une table est une collection de données relatives à un domaine bien défini, par exemple les employés d’une société ou
les livres d’une bibliothèque. Elle contient des enregistrements dont chacun est composé par les mêmes champs de données.
Voici, Cf. Figure 5.1 , quelques employés d’une société :
F IGURE 5.1 – Quelques employés
Voici la table nécessaire pour stocker les informations concernant ces employés dans une BD :
F IGURE 5.2 – Table des employés
Propriétés des tables
• Les champs de données définissent les informations, qu’on veut stocker dans la table (p.ex. des informations concer-
nant les employés d’une société).
• Chaque enregistrement représente une occurrence de ce qu’on veut stocker (p.ex. un employé).
• Chaque table possède un nom unique (p.ex. : tblEmployés).
• Chaque enregistrement correspond à une ligne de la table.

66
• Chaque champ correspond à une colonne de la table.
• Chaque champ peut représenter des données de nature différente (Nom, Salaire, Date de naissance . . . ).
• Chaque champ peut représenter des données de type différent (Texte, Nombres, Dates, . . . ).
Convention des noms Il existe une convention concernant les noms des objets des BD. Généralement, les noms des
objets ne contiennent ni d’espaces, ni de caractères spéciaux. En plus, chaque nom d’un objet est précédé par un préfixe bien
déterminé pour chaque type d’objet. Cette convention fait partie d’une convention des noms générale pour les programmes
tournant sous une interface graphique du type Windows.
Les noms de tables sont précédés du préfixe tbl (angl. : table).
Exemple 71.
tblLivres, tblEmployés
Le nom d’une table doit être unique à l’intérieur d’une BD.
Une BD peut contenir une ou plusieurs tables, mais les tables sont généralement la condition nécessaire pour la création
d’autres objets tels que les requêtes, formulaires et rapports.
Exercice 19.
Déterminez les champs nécessaires pour une table qui contiendra des données concernant :
1. les élèves d’une école (nous ignorons la gestion des classes) ;
2. les livres d’une bibliothèque (nous supposons qu’un livre est rédigé par un seul auteur) ;
3. les produits d’un supermarché.
5.1.1 Les champs d’une table

Une table reprenant les données concernant les voitures d’une société de taxis contient par exemple pour chaque enre-
gistrement (= chaque taxi) les informations suivantes :
• Marque
• Modèle
• Cylindrée
• Poids
Il est évident que les informations sont de types différents. Tandis que la marque et le modèle sont représentés par des
chaı̂nes de caractères (p.ex. ”Ford”, ”BMW”, . . . ), la cylindrée et le poids sont représentés par des valeurs numériques.
La figure 5.3 montre à titre d’exemple, une table qui représente les taxis dans une BD :
F IGURE 5.3 – Données dans une BD
Afin de pouvoir représenter des données de types différentes, les SGBD offrent des types de données standards pour les
champs de données. La figure 5.4 les types de données connus par la plupart des SGBD :
Consultez le manuel d’utilisation de votre SGBD pour trouver des informations plus détaillées concernant les types de
données supportés.
Remarque : Les nombres qui ne sont pas utilisés lors de calculs numériques (p.ex. No.Tél) sont généralement représentés
à l’aide du type de données ”Texte”.
67
F IGURE 5.4 – Types de données dans une BD
Convention des noms : Les noms des champs sont souvent précédés du préfixe fld (angl. : field). Par exemple : fldMarque,
fldModèle, . . .
Exercice 20.
Réfléchissez pour chaque champ des 3 tables, que vous avez défini dans l’exercice de la page 66, sur le type de données
approprié.
Exercice 21.
Détaillez dans la table suivante, pour chaque type de données implémenté par votre SGBD, le nom ainsi qu’une description.
Référez vous au manuel d’utilisation ou au système d’aide en ligne.
Remarque : Lors de la création d’une table, nous devons indiquer au SGBD, pour chaque champ :
1. Le nom du champ, qui doit être unique dans la table
2. Le type de données du champ
5.1.2 Clé primaire

Dans la plupart des cas, on désire pouvoir identifier de manière unique chaque enregistrement de la table. Ceci n’est pas
possible pour notre table avec les taxis. Il se peut très bien que le propriétaire de la société achète par exemple une deuxième
BMW 320i , qui possède bien sur également une cylindrée de 2000 ccm et un poids de 1200 kg. Dans ce cas nous avons 2
enregistrement complètement identiques dans notre BD. Cela nous empêche d’identifier clairement un des 2 enregistrements.
Il nous faut donc un moyen, qui nous permet d’adresser sans ambiguı̈té chaque enregistrement dans la table ? une clé
primaire !
La clé primaire, constituée d’un ou de plusieurs champs, nous permet d’identifier de manière unique chaque enregistre-
ment d’une table.
Examinons notre cas de la société de taxis. Aucun des 4 champs seuls, et aucune combinaison des 4 champs ne se prêtent
comme candidats pour devenir clé primaire, car aucun de ces champs ne contient des valeurs uniques à un et un seul taxi.
Supposons par exemple la marque et le modèle comme clé primaire. Au cas ou la société achète un deuxième BMW 320i,
on ne pourrait plus distinguer entre les deux voitures.
Le ou les champs, qui forment la clé primaire doivent impérativement avoir des valeurs qui sont uniques pour toute la
table 1 , et qui permettent donc d’identifier chaque enregistrement.
1. pour une clé primaire composée de plusieurs champs, la combinaison des valeurs doit être unique
68
Exemple 72.
Le numéro de la matricule pour les assurés des caisses de maladie.
Le numéro client pour les clients d’une vidéothèque.
En ce qui concerne les taxis, nous avons deux possibilités :
1. Analyser s’il n’existe pas d’information concernant les taxis qui ne soit pas encore stockée dans la table et qui ferait
une clé primaire valable. Une telle information serait par exemple le numéro de chassis, unique pour chaque voiture.
On pourrait donc ajouter un champ fldNochassis et définir ce champ comme clé primaire. Ceci a comme désavantage
que le numéro de chassis d’une voiture est un numéro assez long et compliqué, ce qui défavorise une utilisation
conviviale de la table.
2. On pourrait inventer un numéro de taxi allant simplement de 1 jusqu’au nombre de taxis que la société possède. Le
premier taxi enregistré serait le numéro TAXI=1, le deuxième le numéro TAXI=2 etc. . Bien que ce numéro n’ait
aucune signification réelle, cette méthode de création de clés primaires artificielles est très répandue, et la plupart des
SGBD offrent même un type de données prédéfini pour générer des valeurs uniques pour de telles clés primaires.
Notre table aurait dans ce cas la structure de la figure ??.
Convention des noms Les noms des champs qui forment la clé primaire sont souvent précédés du préfixe id (angl. : iden-
tifier). Par exemple : idTaxi, idEmployé
Exercice 22.
Définissez pour chacune des 3 tables, que vous avez défini dans l’exercice de la section 66, une clé primaire parmi les champs
existants, resp. créez un nouveau champ qui assumera le rôle de clé primaire. Indiquez dans la grille de la Figure ?? pour
chaque table toutes les informations nécessaires.
5.1.3 Relations entre tables - clé étrangère

Une base de données bien faite est rarement composée d’une seule table, mais d’un ensemble de tables, entre lesquelles
il existe certaines relations.
Exemple 73.
Soit la BD suivante d’un organisme de sécurité sociale.
La table tblEmployés contient certaines informations concernant les employés, mais pas le nom de la société, qui em-
ploie un employé en question. Les informations des sociétés se trouvent dans la table tblSociétés. Cependant, dans la table
tblEmployés se trouve le champ fiSociété, qui contient pour chaque employé le numéro de la société patron. On peut retrou-
ver chaque numéro de société encore une fois dans le champ idSociété, qui constitue la clé primaire de tblSociétés. Les deux
tables sont donc logiquement liées via les champs fiSociété et idSociété.
On dit que fiSociété est une clé étrangère, qui fait référence à la clé primaire idSociété de la table tblSociétés.
69
Clé étrangère Un champ qui, dans une table, fait référence à la clé primaire d’une autre table est appelé clé étrangère
(angl. : foreign key). Ainsi sont définies les relations entre les tables.
5.1.4 Index
Une des utilisations fréquentes des tables consiste dans la recherche et le tri des enregistrements.
Lorsque les tables contiennent un grand nombre d’enregistrements, la recherche de certains enregistrements ainsi que le
tri d’enregistrements nécessitent de plus en plus de temps. Les index sont des structures qui accélèrent les tris et recherches
dans les tables, ainsi que l’exécution de certaines requêtes (voir chapitre 7).
Exemple 74.
Soit la BD suivante d’un organisme de sécurité sociale.
Reprenons notre exemple des employés d’une société. Une recherche intéressante serait par exemple : Montre-moi tous
les employés du service Informatique ! Il serait aussi intéressant de trier les employés sur leur nom de famille. Au cas ou la
table contient beaucoup d’enregistrements, on devrait d’abord créer un index sur le champ fldNom, afin d’accélérer le tri.
Créer par exemple un index sur le champ fldNom veut dire que le SGBD copie toutes les valeurs existantes du champ
fldNom dans une liste spéciale à 2 colonnes. La deuxième colonne contient les noms triés en ordre alphabétique, et la
première contient une référence vers l’enregistrement correspondant de la table.
Il est évident que par la suite de la création de cet index, toutes les recherches et les tris concernant le nom de l’employé
sont accélérées, puisque le SGBD consulte uniquement l’index pour retrouver le bon nom, pour ensuite utiliser la référence
de l’index vers l’enregistrement correspondant de la table.
Un index peut aussi comporter plusieurs champs comme par exemple fldService et fldNom.
Propriétés importantes des index
• Un index est toujours lié à un ou plusieurs champs d’une table.
• Un index peut seulement contenir des champs ayant un des types de données Texte, Numérique ou Date/Heure.
• Un index est automatiquement mis à jour par le SGBD lors d’un ajout, d’une modification ou d’une suppression
d’enregistrements dans la table. Ceci est transparent pour l’utilisateur de la BD.
• Il existe deux types d’index :
1. Index avec doublons (Les valeurs doubles sont permises)

2. Index sans doublons (Les valeurs doubles ne sont pas permises)
Voici quelques règles qui nous aident à déterminer les champs d’une table qui ont besoin d’être indexés :
1. La puissance des index joue uniquement pour des tables qui contiennent beaucoup d’enregistrements (Consultez la
documentation de votre SGBD afin d’avoir des précisions).
70
2. Un champ sur lequel on ne fait que rarement ou pas du tout de recherche ou de tri n’a pas besoin d’index.
3. Les champs référencés fréquemment dans les recherches et tris doivent par contre être indexés.
4. Pour les index multi-champs, il faut veiller à ce que la combinaison des champs dans l’index corresponde exactement
au critère de recherche. Un index sur nom&prénom n’accélère pas une recherche du type prénom=Jos & nom=Weber.
5. Un index sans doublons sur un champ empêche l’utilisateur d’entrer la même valeur dans ce champ, dans deux enre-
gistrements différents.
6. Définir trop d’index sur une table ralentit en général les opérations d’ajout, de modification et de suppression, parce
que le SGBD doit mettre à jour la table et l’index.
Remarque : La clé primaire est toujours indexée à l’aide d’un index sans doublons 2 !
TP :
Réaliser les travaux pratiques des pages des pages 87 à 93
5.2 Utilisation d’un outil de modélisation : WinDesign

5.2.1 Définitions
Un outil de modélisation est un programme spécialisé dans le support de la conception d’un système d’information.
Il existe actuellement sur le marché une offre très diverse d’outils de modélisation. Chaque outil de modélisation
implémente une méthode de modélisation. Comme la méthode MERISE est très répandue dans nos régions, il est évident
qu’il existe un certain nombre d’outils basés sur elle.
En principe, les outils de modélisation sont intégrés dans des applications capables de ne pas supporter uniquement la
conception d’un système d’information (BD), mais également le développement complet de programmes de gestion d’une
certaine envergure. Ces applications, appelées ”Ateliers de génie logiciel” (angl. CASE Tool : Computer Aided Software
Engineering Tool), sont généralement utilisés par les informaticiens afin de réaliser des grands projets.
Exemples :
L’outil Win’Design constitue une mise en œuvre de la méthode MERISE. Notons que Win’Design a été utilisé pour créer
les modèles conceptuels et logiques présentés dans cet ouvrage. La Figure 5.5 en est une illustration.
L’application Designer de la société Oracle, constituant un atelier de génie logiciel très répandu, implémente une méthode
plus ou moins compatible à MERISE en ce qui concerne la modélisation des données (Entity Relationship Modelling). La
Figure 5.6 en est une illustration.
5.2.2 Fonctionnalités
Bien que les différents outils de modélisation, actuellement disponibles sur le marché, varient considérablement en
termes de caractéristiques et fonctionnalités, ils offrent cependant les fonctions de base suivantes.
• Représentation graphique des modèles conceptuels et logiques avec les différents objets (p.ex. entités, relations, pro-
priétés, identifiants, tables, attributs, clés etc.). Vérification des règles de construction des différents modèles (p.ex.
Une relation ne peut pas être liée à deux entités via des cardinalités 1,1).
• Transformation automatique d’un MCD en MLD en respectant toutes les règles de transformation. Génération auto-
matique d’une BD à partir d’un MLD. Après avoir indiqué le SGBD cible (p.ex. Oracle, MS-Access, Informix), le
concepteur peut demander à l’outil de créer la BD. Pour ce faire, il existe deux alternatives :
– l’outil de modélisation accède directement au SGBD cible afin de créer la BD en question ;

– l’outil de modélisation génère un script 3 , qui est à la suite exécuté sur le SGBD afin de créer la BD.
2. Pour la plupart des SGBD, ceci est fait de façon automatique lors de la définition d’un ou de plusieurs champs comme clé primaire .
3. plusieurs commandes dans un langage supporté par le SGBD cible.
71
F IGURE 5.5 – Un MCD dans Win’Design
F IGURE 5.6 – Un MCD dans Designer
• Génération automatique de rapports imprimés concernant l’état actuel d’un travail de conception. Ces rapports contiennent
en général la représentation graphique des modèles, des listes avec tous les objets des différents modèles et des expli-
cations supplémentaires concernant certains objets.
72
• Gestion des objets de conception (p.ex. entités, relations, propriétés, identifiants, tables, attributs, clés etc.) dans un
dictionnaire 4 . Pour des petits projets de conception, effectués par un seul concepteur sur un ordinateur, le dictionnaire
est simplement un fichier stocké localement. Toutefois, pour les grands projets, effectués par plusieurs concepteurs,
certains outils de modélisation permettent la gestion d’un dictionnaire sur un serveur en réseau (voir section 4.5).
Dans ce cas, plusieurs concepteurs peuvent travailler en même temps sur un modèle, l’outil de modélisation veillant à
chaque moment que le modèle reste cohérent. L’intégration de plusieurs modèles en un seul modèle, et la gestion des
versions d’un objet ou d’un modèle constituent d’autres caractéristiques supportées par un tel système.
• La plupart des outils de modélisation sont capables de créer un MLD et un MCD à partir d’une BD existante. Ce
procédé, connu sous le nom de ”Reversement d’une BD” (angl. Database Reverse Engineering), est souvent utilisé à
la base d’un projet d’amélioration ou d’extension d’un système d’information existant déjà sous forme informatique.
5.2.3 Application
Pour ce TP, vous allez utiliser le logiciel WinDesign. Ce logiciel permet notamment de créer facilement un MCD et
de générer automatiquement le schéma relationnel et le script SQL de création de la base de données correspondants. Ce
premier exercice vise à vous familiariser avec le logiciel.
Pour cela, vous allez créer dans WinDesign le MCD correspondant à la figure 5.7. Pour ce faire :
F IGURE 5.7 – MCD à créer
• Ouvrir le logiciel en cliquant sur l’icône WinDesign.
• Dans le menu Fichier, cliquer sur Nouveau.
• Choisir le module de conception de base de données DataBase.
• Dans la fenêtre qui s’ouvre, modifier le nom du diagramme, puis cliquer sur Modèle Conceptuel de Données.
• Cliquer sur OK pour confirmer.
Vous allez maintenant commencer à rentrer le MCD correspondant à un exemple passé.
• Pour créer une nouvelle entité CLIENT, cliquer sur l’icône Entité dans la barre d’outil.
• Positionner la nouvelle entité sur le diagramme et entrer le nom de l’entité i-e (CLIENT) dans la fenêtre qui apparait.
• Double-cliquer sur l’entité CLIENT pour faire apparaitre la fenêtre permettant de décrire plus précisément l’entité.
• Cliquer sur le bouton Détails pour afficher la fenêtre de description détaillée des attributs de l’entité.
• Compléter la liste des propriétés (attributs) de l’entité CLIENT. Pour l’attribut NumClient, préciser qu’il s’agit de
l’identifiant de l’entité. Cliquer sur OK pour valider (voir fenêtre page suivante).
• Enregister votre modèle. Pour cela, choisir Enregistrer dans le menu Fichier. Le format du fichier enregistré est .mcd.
Dans la suite du TP, penser à enregistrer régulièrement votre modèle.
• Répéter ces opérations afin de créer une entité PRODUIT et une entité COMMANDE.
Remarque : En cas de problème, il est possible de supprimer une entité du modèle. Pour cela, sélectionner l’entité à
supprimer, puis choisir Supprimer dans le menu Editer.
73
F IGURE 5.8
• Pour créer une association entre entités, on utilise l’icône Association de la barre d’outil.
• Pour créer l’association passe entre CLIENT et COMMANDE, sélectionner les deux entités puis cliquer sur l’icône
Association de la barre d’outil. Préciser le verbe correspondant à l’association passe dans la fenêtre qui s’ouvre.
• Par défaut, WinDesign met les cardinalités des associations à ”0,n”. Pour modifier la cardinalité de l’association passe
du côté de l’entité COMMANDE, double-cliquer sur le lien entre l’entité COMMANDE et la bulle passe et choisir
la cardinalité ”1,1” dans la fenêtre qui s’ouvre.
• Répéter ces opérations pour créer l’association contient entre COMMANDE et PRODUIT.
Remarque : en cas de problème, il est possible de supprimer une association du modèle. Pour cela, sélectionner la
bulle représentant l’association à supprimer, puis choisir Supprimer dans le menu Editer.
• Il ne reste plus qu’à préciser l’attribut porté sur l’association contient. Pour cela, double-cliquer sur la bulle représentant
l’association contient, puis cliquer sur le bouton Détails dans la fenêtre qui s’ouvre. Préciser le nom de l’attribut porté
(QteCmde) dans la liste des propriétés de l’association.
• 15)Enregister le MCD final.
Il est possible d’exporter ce MCD sous forme d’image (par exemple pour l’intégrer à votre compte-rendu de TP). Pour cela :
• Choisir Exporter image sous-modèle dans le menu Editer
• Choisir l’emplacement où vous voulez enregistrer l’image. WinDesign crée un fichier .jpeg portant le même nom que
le diagramme MCD.
Reste maintenant à générer automatiquement le schéma relationnel correspondant à ce MCD.
• Choisir Générer modèle logique dans le menu Modèle. Cliquer sur le bouton SGBD, puis sélectionner comme
système de gestion de base de données MS Access 2000.
WinDesign génère le schéma relationnel (modèle logique relationnel) correspondant au MCD saisi. Les attributs
constituant la clé primaire de chaque table sont indiqués dans la partie PK nom de la table (PK = primary key).
Enfin, il est possible de générer automatiquement le script de création de la base de données correspondant à ce schéma
relationnel.
• Dans le menu Base de données, cliquer sur Générer script.
• Cliquer sur OK dans la fenêtre de contrôle de la génération du script, puis sur le bouton Voir script de la fenêtre de
fin de génération du script SQL.
Le script généré contient :
– des requêtes de suppression de tables (DROP TABLE) afin de supprimer des tables de même nom que les tables
à créer qui existeraient déjà éventuellement dans le SGBD.
– une requête de création de la base de données (CREATE DATABASE).
– des requêtes de création de tables (CREATE TABLE) et de modification de tables (ALTER TABLE) pour l’ajout
des contraintes d’intégrité référentielle.
– des requêtes de création d’index pour les tables crées (CREATE INDEX).
Dans une base de données, les index sont utilisés par le SGBD afin de retrouver plus rapidement les informations
dont il a besoin. Cela permet notamment d’améliorer les performances du SGBD
• Identification relative : Il est possible de définir une identification relative avec WinDesign.
Exemple : Identification relative d’une salle du bâtiment I de PrepaVogt par rapport à l’étage où elle se situe. Cf Figure
5.9 Pour cela, il suffit de créer une association est située dans entre ETAGE et SALLE et de modifier la cardinalité
de l’association du côté de SALLE en précisant qu’il s’agit d’un lien identifiant (en cochant sur Identifiant relatif).
4. une sorte de récipient logique pour les objets de conception.
74
F IGURE 5.9
• Association réflexive : Exemple : Un salarié encadre plusieurs autres salariés (en tant que chef). Cf Figure 5.10 Pour
F IGURE 5.10
cela, il suffit de créer une association réflexive comme suit :
– Créer l’entité SALARIE sur laquelle porte l’association réflexive.

– Sélectionner l’entité SALARIE et créer l’association réflexive encadre. Pour le moment, il n’y a qu’un seul lien
entre l’entité et l’association.
– Ajouter un lien formel entre l’entité SALARIE et la bulle représentant l’association encadre. Pour cela, cliquer
sur l’icône lien formel et créer le lien en cliquant sur l’entité puis sur l’association. Un deuxième lien avec
comme cardinalité 0,n apparait.
– Cliquer sur chaque lien pour modifier les cardinalités si besoin. Préciser le rôle de chaque occurrence dans
l’association (chef et subordonné).
Chapitre 6
Les requêtes
6.1 Définition
Nous avons vu que la plupart des SGBD offrent la possibilité d’effectuer des recherches directement dans les tables.
Les possibilités de formuler des critères de recherche sont cependant souvent assez limitées. Heureusement, la plupart des
SGBD nous offrent également la possibilité de poser pratiquement n’importe quelle ”question” à nos tables, sous forme de
requêtes.
Les requêtes servent donc à répondre aux questions basées sur le contenu d’une ou de plusieurs tables. Nous allons plus
tard étudier des requêtes, qui se basent sur plusieurs tables, mais pour l’instant nous allons nous limiter aux questions simples
basées sur une seule table. Exemple 75.
Reprenons notre table avec les taxis (Cf. Fig 5.3) Une requête simple serait par exemple :
• Quelles sont les marques et modèles des voitures ayant une cylindrée supérieure à 2000 ?
Le résultat serait un sous-ensemble de la table avec seulement les enregistrements qui vérifient le critère de sélection (cy-
lindrée ¿ 2000). Pour chacun de ces enregistrements, le SGBD affiche en plus seulement les champs explicitement demandés
(fldMarque et fldModèle).
Une requête simple produit donc comme résultat un sous-ensemble des enregistrements d’une table. En plus, une requête
nous permet d’afficher seulement certains champs pour les enregistrements appartenant à ce sous-ensemble.
On appelle ces requêtes ”Requêtes de Sélection”, puisqu’il s’agit d’une sélection de certains enregistrements.
Il n’existe cependant pas seulement des requêtes de sélection, mais également :
• Des requêtes d’insertion consistant à insérer des enregistrements dans la table. p.ex. Insérer un nouveau taxi : 4, BMW,
325i, 2500, 1270.
• Des requêtes de modification consistant à modifier des enregistrements dans la table. p.ex. Modifier la cylindrée des
Ford Orion de façon à ce qu’elle devienne 2000.
• Des requêtes de suppression consistant à supprimer des enregistrements de la table. p.ex. Supprimer toutes les BMW.
Les requêtes possèdent l’avantage de pouvoir manipuler facilement un grand nombre d’enregistrements sans que l’utili-
sateur ne doive s’occuper de sélectionner enregistrement par enregistrement. Il lui suffit de spécifier des critères de sélection
pour la requête, ainsi que l’opération à effectuer (simple sélection et affichage, insertion, modification ou suppression).
Bien que les requêtes de sélection soient implémentées d’une manière plus ou moins cohérente à travers les SGBD
actuels, il existe des différences subtiles en ce qui concerne les requêtes d’insertion, de modification ainsi que de suppression.
En plus, l’insertion et la suppression se font souvent de manière plus facile directement dans la table.
Il existe 4 types de requêtes :
1. Requêtes de sélection.
2. Requêtes d’insertion.
3. Requêtes de modification.
4. Requêtes de suppression.
76
F IGURE 6.1
Pour chaque requête nous retrouvons le cycle suivant :
Exercice 23.
Quel est en général le résultat d’une requête :
• de sélection
• d’insertion
• de modification
• de suppression
6.2 Introduction au langage SQL

6.2.1 Généralités
Nous avons vu au chapitre précédent qu’il faut d’abord formuler une requête et puis l’exécuter, afin d’avoir des résultats.
Vous pouvez probablement bien vous imaginer que les SGBD actuels ne comprennent pas le langage naturel. Aucun SGBD
n’offre une possibilité d’écrire p.ex. Je veux voir tous les taxis dont la marque est Ford Pour formuler une requête, l’utilisateur
doit donc utiliser un langage spécialisé pour ce domaine.
Le langage SQL (Structured Query Language) est un standard international, en ce qui concerne les langages de manipu-
lation des BD. SQL est connu par tous les SGBDR. Il faut cependant mentionner que, désormais la présence de standards
internationaux tels que SQL-86, SQL-89 ou SQL-92, chaque SGBD sur le marché utilise un peu son propre dialecte du
langage SQL.
6.2.2 Syntaxe SQL de base

Nous distinguons les 4 types de requêtes suivants.
SELECT <Nom des champs>

FROM <Nom de la table>
WHERE <Critères de sélection>;
INSERT INTO <Nom de la table> ?(<Liste des champs>)?

VALUES ( <Valeurs pour les champs> );
Attention : Lorsque vous n’indiquez pas la liste des champs derrière INSERT INTO , vous devez spécifier une valeur
pour chaque champ de la table derrière VALUES . Les parenthèses derrière VALUES sont obligatoires. La liste des
champs, lorsqu’elle est indiquée, contient les noms des champs, séparés par une virgule, et doit également être entourée
de parenthèses.
UPDATE <Nom de la table>

SET <Nom d’un champ>=valeur, <Nom d’un champ>=valeur, . .
77
DELETE FROM <Nom de la table>

Soit une table des employés d’une entreprise avec la structure suivante :
F IGURE 6.2
Voici le code SQL nécessaire pour effectuer quelques requêtes élémentaires :
1. Afficher le prénom et le nom de tous les employés
SELECT fldPrénom, fldNom

FROM tblEmployés;
2. Insérer une nouvelle employée :
F IGURE 6.3
INSERT INTO tblEmployés

VALUES (20, ’Angela’, ’Portante’, ’ITA’, 27, ’F’, ’Comptabilité’);
Remarques Les valeurs sont séparées par des virgules.

En SQL, les données du type TEXTE sont entourées d’apostrophes.
Les dates sont entourées du caractère # et indiquées dans le format américain #Mois/Jour/Année#
Exemple 76.
20/4/98 → #04/20/98# ou #4/20/98# ou #04/20/1998# ou #4/20/1998#
3. Afficher toutes les nationalités représentées dans la société
SELECT fldNationalité
FROM tblEmployés;
Quel est l’inconvénient de cette requête ?

Soit l’adaptation suivante de la requête :
78
SELECT DISTINCT fldNationalité
FROM tblEmployés;
Expliquez l’utilité de l’option DISTINCT
4. Afficher tous les champs pour tous les employés
SELECT idEmployé, fldPrénom, fldNom, fldNationalité, fldAge, fldSexe, fldService

FROM tblEmployés;
ou
SELECT *
FROM tblEmployés;
Remarque : L’opérateur * permet d’afficher tous les champs définis dans la table.
6.2.3 Les critères de sélection

Les critères de sélection constituent une expression logique ; qui peut prendre la valeur ’Vrai’ ou ’Faux’. Les critères de
sélection sont appliqués à chaque enregistrement d’une table. Lorsque pour un enregistrement donné, l’expression logique
prend la valeur ’Vrai’, cet enregistrement :
• fait partie du résultat pour une requête de sélection ;
• est modifié pour une requête de modification ;
• est effacé pour une requête de suppression ;
Comparaison à une valeur donnée Pour chaque enregistrement, la valeur d’un champ donné est comparée à une valeur
fixe. Cette valeur fixe est généralement une valeur numérique, une date ou un texte.
Voici les opérateurs de comparaison :
= ”est égal”
¿ ”strictement supérieur”
¡ ”strictement inférieur”
¿= ”supérieur ou égal”
¡= ”inférieur ou égal”
¡¿ ”est différent”
Exemple 77.
1. Afficher le prénom et le nom de tous les employés du service ”Marketing”

FROM tblEmployés
WHERE fldService=’Marketing’;
2. Afficher le prénom, le nom et l’âge de tous les employés plus jeunes que 50 ans
SELECT fldPrénom, fldNom, fldAge

FROM tblEmployés
WHERE fldAge<50;
79
Quel problème se pose lorsqu’on exécute cette même requête encore une fois un an plus tard ?
Comment peut-on éviter un tel problème dès le départ, déjà lors de la conception des tables ?
3. Augmentez de la valeur 1 l’âge de Madame Angela Portante.
UPDATE tblEmployés
SET fldAge=fldAge+1
WHERE fldNom=’Portante’;
Remarque : Cette requête peut provoquer des résultats imprévus au cas ou plusieurs employés ont par exemple le
même nom. Pour être certain de ne pas commettre d’erreur, il faudrait d’abord sélectionner tous les employés qui
s’appellent ”Portante”. Lorsque cette requête ne fournit qu’un seul enregistrement, vous pouvez exécuter la requête
comme indiqué en haut. Par contre lorsque vous remarquez que la table contient plusieurs employés au nom de
”Portante”, vérifiez les enregistrements, et retenez la valeur de la clé primaire (idEmployé) pour l’employé que vous
désirez modifier. Ensuite utilisez la valeur de idEmployé dans la partie WHERE de la commande UPDATE ( ?.WHERE
idEmployé=¡valeur¿).
4. Effacez tous les employés du service Informatique.
DELETE FROM tblEmployés

WHERE fldService=’Informatique’;
6.2.4 Comparaison à un filtre

Parfois, on ne connaı̂t pas la valeur exacte à laquelle on veut comparer la valeur d’un champ. Dans ce cas on peut utiliser
un filtre. Un filtre est une expression qui peut contenir des lettres, des chiffres et en plus les 2 caractères spéciaux (angl.
Wildcards) suivants :
• % représente n’importe quelle séquence de 0 ou plusieurs caractères ;

• représente un seul caractère quelconque.
Exemple 78.
Pour rechercher des personnes dont le nom est ’SCHMITZ’ ou ’SCHMITT’ ou ’SCHMIT’ etc. on définit par exemple le
filtre suivant : ’SCHMI%’
Le filtre ’BL ’ sélectionne par exemple les valeurs ’BLEU’ ou ’BLUE’ mais pas ’BLANC’
Les filtres sont utilisés ensemble avec le mot réservé LIKE. Voici la syntaxe :
WHERE <Nom du champ> LIKE <Filtre>
Exemple 79.
1. Afficher le nom et le prénom des employés dont le prénom contient un trait d’union (p.ex. Jean-Jacques)
SELECT fldNom, fldPrénom

FROM tblEmployés
WHERE fldPrénom LIKE ’%-%’;
2. Afficher le nom, le prénom et l’âge des employés dont le nom commence par ’W’, est composé de 5 lettres et se
termine par ’R’
SELECT fldNom, fldPrénom, fldAge

FROM tblEmployés
WHERE fldNom LIKE ’W R’;
80
Remarque Pour les manipulations pratiques, il faut se rendre compte que certains SGBD utilisent des caractères spéciaux
différents pour représenter une séquence de caractères respectivement un caractère quelconque. MS-Accesstmpar exemple
utilise les caractères suivants :
SQL MS-Accesstm
Séquence de 0 ou plusieurs caractères % *
Un seul caractère quelconque ?
6.2.5 Les opérateurs logiques

Il existe 3 opérateurs logiques :
NOT (Négation logique) L’opérateur NOT inverse le résultat d’une expression logique.
AND (Et logique) L’opérateur AND nous permet de combiner plusieurs conditions dans une expression logique. L’expres-
sion logique retourne uniquement la valeur ’Vrai’ lorsque toutes les conditions sont remplies.
OR (Ou logique) L’opérateur OR nous permet de combiner plusieurs conditions dans une expression logique. L’expression
logique retourne la valeur ’Vrai’ lorsque au moins une des conditions est remplie.
Priorité des opérateurs logiques Lorsqu’on combine plusieurs conditions par des opérateurs logiques, le résultat final
de l’expression logique dépend de l’ordre d’exécution des différentes conditions. Cet ordre est déterminé par la priorité des
opérateurs logiques. Voici l’ordre prédéfini en SQL :
1. Déterminer le résultat logique (’Vrai’,’Faux’) des comparaisons (=, ¡, ¿ etc.)
2. Effectuer les négations (NOT)
3. Effectuer les AND
4. Effectuer les OR
Pour modifier cet ordre d’exécution, nous pouvons utiliser des parenthèses afin de grouper les différentes conditions
logiques.
Exemple 80.
1. Afficher le prénom et le nom de tous les employés qui ne travaillent pas dans le service ”Marketing”

FROM tblEmployés
WHERE NOT fldService=’Marketing’;
Formulez une requête qui affiche exactement le même résultat, sans utiliser l’opérateur NOT.

FROM tblEmployés
WHERE fldService<>’Marketing’;
2. Afficher le numéro d’employé, le prénom et le nom de tous les employés dont le nom ne commence pas par la lettre
’W’
SELECT idEmployé, fldPrénom, fldNom

FROM tblEmployés
WHERE fldNom NOT LIKE ’W%’;
81
3. Afficher le numéro de l’employé, le prénom et le nom pour les employés du service Informatique qui ont moins de 30
ans.

FROM tblEmployés
WHERE fldService=’Informatique’ AND fldAge<30;
4. Afficher le prénom et nom des employés féminins (code=F) qui ne travaillent pas au service marketing.

FROM tblEmployés
WHERE fldSexe=’F’ AND NOT fldService=’Marketing’;
ou

FROM tblEmployés
WHERE fldSexe=’F’ AND fldService<>’Marketing’;
5. Afficher tous les champs pour les employés de nationalité luxembourgeoise (Code=LUX) ou portugaise (Code=PRT).
SELECT *
FROM tblEmployés
WHERE fldNationalité=’LUX’ OR fldNationalité=’PRT’;
6. L’employé Emil Meier est transféré du service Comptabilité dans le service Informatique. Reflétez ce changement
dans la table.
SET fldService=’Informatique’
WHERE fldPrénom=’Emil’ AND fldNom=’Meier’;
Remarque Cette requête peut provoquer des résultats imprévus au cas ou plusieurs employés ont par exemple le
s’appellent Emil Meier. Lorsque cette requête ne fournit qu’un seul enregistrement, vous pouvez exécuter la requête
Emil Meier, vérifiez les enregistrements, et retenez la valeur de la clé primaire (idEmployé) pour l’employé que vous
7. Affichez tous les champs pour les employés féminins de nationalité luxembourgeoise (Code=’LUX’) ou allemande
(Code=’ALL’)
SELECT *
FROM tblEmployés
WHERE (fldNationalité=’LUX’ OR fldNationalité=’ALL’) AND fldSexe=’F’;
Est-ce que cette requête serait correcte sans les parenthèses ?

Deuxième partie
Implémentation des Bases de Données

85
Dans cette partie, essentiellement pratique, nous nous focalisons sur l’implémentation des bases de données.
Nous étudions tour à tour la création d’une base de données, l’interrogation des bases de données, les création des formulaires
d’accès aux données ainsi que les états.
Nous nous appuierons davantage sur le SGBD Access et présentons aussi de façon sommaire un atelier de Génie Logiciel,
WinDesign.
Chapitre 7
Création du schéma relationnel
N.B. Les TPs se feront essentiellement dans MS Access, peu importe la version en votre possession : le principe général
varie très peu en fonction des versions. Vous vous adapterez bien vite. Vous pourrez par la suite essayer les mêmes exercices
sur d’autres SGBD (libres ou pas).
7.1 Création de table

Commençons par créer une nouvelle base de données :
Lancez le logiciel Microsoft Access. Pour découvrir les éléments qui composent Access, il faut ouvrir une base de données
existante, ou en créer une nouvelle.
• Cliquez sur ”Base de données vide”
• Sélectionnez votre dossier de travail. Dans la zone ”Nom du fichier”, tapez ”Magasin BD MF 2 MonNom” puis
cliquez sur créer. Par défaut, Une table vide va s’afficher et il va falloir la renseigner.
• En règle générale, il vous suffit de cliquer sur le menu ”Créer” pour apercevoir les différents types d’objets que mani-
pule MS Access que sont : les tables, les requêtes, les formulaires, les états et les macros.
Dans MS Access, une table peut se présenter en mode Création - on y voit alors sa structure - ou en mode Feuille de
données qui montre les différents enregistrements qu’elle contient et permet leur saisie. On peut basculer d’un mode à
l’autre en cliquant sur l’icone ”Affichage” dans la barre d’outils.
Créer une table consiste à déterminer ses différents champs et leurs caractéristiques ainsi qu’à déterminer la clé primaire de
cette table. Pour chaque champ, il est nécessaire de choisir quel type de données il est destiné à recevoir. La description du
champ est facultative.
1. Pour créer une table, choisir l’onglet Créer + le groupe Tables + la commande Création de table.
2. Créer un champ : le nom dd’un champ, qui ne doit comporter ni ponctuation ni opérateur arithmétique, est composé
de 1 à 64 caractères alphanumériques (cf. Aide). Je vous conseille d’éviter l’espace.
Application : Ajoutons le premier champ : Dans la colonne Nom du champ de la première ligne, tapez ”N˚ Client”
puis passez à la ligne suivante à l’aide de votre souris ou de la flèche de direction du clavier.
Remarquez que par défaut, le type de la donnée est ”Texte”.
Taper successivement dans les lignes suivantes ”Nom”, ”Prenom”, ”BP”, ”Date Naissance”, ”Telephone”, ”Ville”,
”Observations” sans accent (quoiqu’on ne soit pas obligé).
3. Sélectionner un champ : Quand un champ est sélectionné, la couleur distinctive à gauche de la colonne ”Nom de
Champ” indique que le champ est actif. Pour déplacer, supprimer ou insérer un champ, il faut sélectionner l’intégralité
de la ligne en cliquant sur cette couleur-là.
4. Insérer un champ :
Application : Ajoutons entre les champs ”Ville” et ”Observations”, un champ intitulé ”Sexe” correspondant au sexe
du client.
Sélectionner la ligne du champ ”Observations” et cliquez sur la touche ”Insérer des lignes” dans le groupe ”Outils du
88
menu ”Création”. Vous pouvez aussi ajouter une ligne en cliquant sur le bouton droit de la souris ”Insérer une ligne”.
Dans le nouveau nom du champ apparu, tapez ”Sexe”.
5. Supprimer un champ :
Application : supprimer le champ ”Telephone”. Sélectionner la ligne, et taper sur la touche SUPP (ou supprimer en
cliquant sur le bouton droit de la souris ”supprimer la ligne”). Insérez ce champ à nouveau.
6. Déplacer un champ :
Application : Déplaçons les champs ”Sexe” et juste avant le champ ”BP”.
Pour cela, sélectionnez la ligne ”Sexe”, et sans relâcher le bouton, faites-la glisser juste au-dessus de la ligne du champ
”BP”. Faites de même pour ”Date Naissance”
7. Type de données : cette colonne détermine la valeur contenue dans chaque champ. On a :
Type Description
Texte Texte ou suite de chiffres n’ayant pas de valeur mathématique et n’in-
tervenant pas dans des calculs
Mémo Champs texte ayant pour taille maximale 65536 caractères.
Numérique Valeurs numériques pouvant faire l’objet de calculs, excepté les valeurs
monétaires.
Date/Heure Champ numérique formaté sous forme d’une date et/ou d’une heure
Monétaire Champ numérique formaté sous forme monétaire
NuméroAuto Champ compteur qui s’incrémente automatiquement à chaque saisie
d’un nouvel enregistrement. Un tel champ est souvent utilisé comme
clé primaire.
Oui/Non Pour les champs qui ne comptent que deux états Oui/Non, Vrai/Faux
Objet OLE Objet crée par un logiciel autre qu’Access, par exemple un dessin ou
une photographie
Lien hypertexte Adresse d’un lien hypertexte vers une page (URL)
Assistant Liste Crée un champ qui permet de déterminer une valeur à partir d’une liste
de choix de valeurs prédéterminées figurant dans une liste déroulante
8. NuméroAuto (Compteur automatique) : Il s’agit de type associé aux valeurs attribuées automatiquement par Access à
chaque nouvel enregistrement. On l’utilise pour créer des numéros séquentiels (ou arbitraires selon les cas) pour les
factures, les clients ? Cependant, les numéros supprimés ne sont jamais remplacés. Application : Pour le champ ”N˚
Client”, choisir NuméroAuto dans le menu déroulant.
9. La colonne ”Description” permet d’ajouter des commentaires décrivant le rôle du champ y relatif.
Application : Tapez ”Numéro automatique attribué par Access” dans la zone description de ”N˚ Client”
10. Clé Primaire : Le numéro attribué à chaque nouvel enregistrement de ”N˚ Client” étant unique dans la table, c’est sur
lui qu’on place la clé primaire qui nous permettra de relier la table Client à d’autres tables.
Application : sélectionnez le champ ”N˚ Client” puis cliquez sur le symbole de la clé primaire dans la barre d’outils
du menu ”Création”. Une clé apparaı̂t à gauche du champ.
11. Propriété des champs :
• ”Taille” : Quand un champ est de type Texte, sa taille désigne le nombre de caractères. S’il est de type numérique,
elle désigne les limites des nombres.
Application : Pour le type de données du champ ”N˚ Client”, choisir numérique et conserve la taille ”Entier
long”.
Remarque : La taille ”Entier long” est obligatoire pour le type NuméroAuto.
• ”Indexée” : Les champs qui feront l’objet d’un tri doivent être indexés. Le champ de la clé primaire doit toujours
être indexé. Les factures seront triées par ordre de numéro. En fait, ce n’est pas une obligation, mais cela facilite
les recherches.
Application : choisissez ”oui-sans doublons” dans la propriété ”indexé” du champ ”N˚ Client” car c’est une clé
primaire. On l’appliquera systématiquement à tout ce qui est clé primaire.
89
• ”Format” : Elle définit le format d’affichage lors de la consultation de la table.
Application : Pour le champ ”Date Naissance”, choisissez Date/heure dans le type de données.
Dans la propriété Format, choisir Date, abrégé.
• ”Légende” : Par défaut, le nom du champ est utilisé comme intitulé dans les formulaires. Cette propriété permet
de modifier l’intitulé.
Application : Passez en mode feuille de données et remarquez le nom de champ correspondant à la date de
naissance. Repassez en mode création. Tapez ”Date de Naissance” dans la propriété légende et ”N˚ de Client”
pour le champ ”N˚ Client” et faites de même pour les autres champs. Réactivez le mode feuille de données. Que
constatez-vous ?
• ”Valeur par défaut” : La valeur définie ici sera automatiquement insérée pour les nouveaux enregistrements.
Par défaut, le champ Date Naissance contiendra la date du jour. La fonction ”Maintenant” retourne cette valeur.
Application : Tapez ”maintenant” dans la propriété ”Valeur par défaut”. Remarquez, qu’Access reconnaı̂t la
fonction maintenant. En effet, ”m” de ”maintenant” passe en majuscule et des parenthèses sont ajoutées.
• ”Valide si” et ”Message si erreur” : la propriété ”Valide si” vérifie si la saisie est correcte. Sinon, le message
contenu dans la propriété ”Message si erreur” est affiché.
Application : On souhaite que la date de la facture soit antérieure à la date du jour. Pour cela, tapez ”¡= mainte-
nant” dans la propriété Valide si. Dans ”message si erreur”, tapez ”Pas de naissance postdatée”.
• ”Null interdit” : Quand elle est sur Oui, cette propriété oblige l’utilisateur (qui renseigne les différents chants)
à taper une valeur. Sinon, des valeurs non renseignées dans ce champ peuvent être admises. En principe, toutes
les clés doivent avoir leur propriété ”Null interdit” fixée à Oui.
Application : ”N˚ Client”.
12. Sauver la table : Cliquez sur l’icône représentant une disquette (dans la barre d’outils) pour enregistrer la table. Tapez
”Clients” dans la zone ”Nom de la table” puis cliquez sur Ok.
Fermer la fenêtre Magasin : Table
13. En guise d’exercice, Créez les autres tables primaires représentées dans la BD ci-dessous.
N.B. On ne crée pas les tables au hasard. On les créera dans l’ordre suivant :
(a) Celles n’ayant aucune clé étrangère

(b) Celles ayant une ou des clé(s) étrangère(s) ne faisant pas partie de la clé primaire
(c) Celles ayant des clés étrangères comme élément constitutif de la clé primaire
90
7.2 Création des relations sous MS ACCESS
Une conception appropriée de base de données permet de supprimer les données redondantes (doublons). Pour atteindre
cet objectif, on procède par décompositions successives d’une relation (parfois universelle) en sous-schémas de relations.
Il faut ensuite spécifier ces relations dans MS Access. Ceci dit, vous effectuerez cette opération correctement après avoir
assimilé les relations entre les tables, puis après les avoir spécifiées dans MS Office Access. Cependant, il est important de
scinder entre relations dues aux listes et relations dues au type de relation . . . C’est le rôle dévolu à ce TP.
Nous réutilisons la table Clients, dans laquelle un champ ”Sexe” a été créé. Pour mémoire, rappelons-nous qu’une table, pour
nous qui la concevons, peut être affichée soit en mode ”création” (qui nous permet de définir la structure de ladite table) soit
en mode ”feuille de données” (utilisé par l’utilisateur qui n’est pas forcément le concepteur : Ici, on peut se permettre de
saisir des données, de les mettre à jour ou d’en supprimer . . . ). Certes, il peut y exister d’autres modes d’accès à une table
dans MS Access mais cela ne nous intéresse pas pour l’instant.
Application 1 :
• Fermez tous les autres onglets et double-cliquez sur la table ”Clients”. Dans le menu ”Accueil”, cliquez sur la pe-
tite flèche apparaissant en contrebas de l’outil ”Affichage”. Vous voyez apparaı̂tre tous les accès possibles. Cliquez
successivement sur les différents modes d’affichage ”création” et ”feuille de données”. Avez-vous remarqué que le
champ ”Date naissance” contient une valeur dite valeur par défaut ? Trouvez vous-même une explication à cela.
• Renseignez les champs d’une ligne de cette table, un peu comme si vous étiez sur Excel. Faites de même pour une
deuxième ligne de la table. Et surtout, ne vous privez pas de modifier la date de naissance si cela ne vous convient pas.
• Par ailleurs, quelle est l’apparence du nom de ce champ ? ”Date naissance” ou ”Date de naissance” ? Que faire pour
voir apparaı̂tre ”Date de naissance” plutôt que ”Date naissance” ?
(Réponse : Cf. TP de la page 105, propriété Légende et retenez la leçon une fois pour toute).
• En mode d’affichage ”feuille de données”, dans le champ ”Sexe” de la table, réalisez vous-même que vous êtes libre
d’introduire la valeur qui vous plaı̂t : certains ”F”, d’autres ”Fem” ou encore ” ”Féminin” ” pour désigner la gent
féminine. Ou encore ”M”, ”Masc” voire ”Masculin” pour le ”sexe fort” . . . sans tabou. Et vous pensez avoir une BD
cohérente ? Que non ! Essayez par exemple ”FemMasc” ou ”MascFem”. N’est-ce pas accepté comme valeur ?
• Eh ben ! Nous allons contraindre l’utilisateur à choisir dans une liste, des valeur que nous allons lui fournir. Pour cela,
activez la table ”Clients” en mode ”création”. Dans le type de données correspondant au sexe du client, sélectionnez
la dernière option i-e ”Assistant Liste de choix”. Lisez ce qui s’affiche. Sélectionnez ensuite la deuxième option. En
cliquant sur ”Suivant”, un tableau minuscule s’affiche ; sur la même colonne intitulée par défaut ”Col1” sur la ligne
ayant l’astérisque, saisissons une première valeur ”F” (pour ne pas faire honte à l’élégance). Puis juste en dessous,
”M”. Si vous pensez qu’il peut y avoir une troisième valeur différente des deux autres, saisissez-là . . . Si vous l’avez
fait, regardez-vous au miroir ! En avez-vous le courage ? Cliquez sur ”Suivant”. Laissez le champ par défaut ”Sexe”
qui va ainsi remplacer le titre ”Col1” et n’autorisez pas plusieurs valeurs pour ce champs. Terminez la besogne.
• Activez le mode ”feuille de données” de la table et essayez de saisir un enregistrement supplémentaire avec dans le
champ ”Sexe”, autre chose que ”M” ou ”F”. ça va pas, non ? C’est encore accepté. Rentrons de nouveau en mode
”création” et accédons aux propriétés de ce champ. Cliquez sur l’onglet ”Liste de choix” des propriétés de ce champ.
Lisez les rems qui apparaissent en-dessous. Modifiez la ligne ”Limiter à liste” en inscrivant ”Oui” pour exprimer
qu’aucune valeur autre que ”M” ou ”F” ne doit être saisie. Saisissez un autre enregistrement et faites un constat.
Nous voyons que parmi les types de données, est proposé un type particulier : la liste de choix. Ce n’est pas à proprement
parler un type de données particulier, c’est un moyen de simplifier la saisie de données dans une table en proposant à
l’utilisateur de cliquer sur un élément proposé dans une liste ; le champ de la table sera rempli avec l’élément sélectionné
dans la liste.
Une fois ces clients saisis, nous allons modifier le type de données du champ ”N˚ Client” de la table commande pour y
mettre une liste de choix.
Pourquoi ? Une commande contient le numéro du client qui l’a passée ; lorsque l’on saisit une commande et qu’on n’a que
le nom du client, il faut se souvenir de son numéro pour le taper, la liste de choix va ici proposer la liste de tous les clients se
trouvant dans la table ”Clients”, il suffira de cliquer sur le nom de l’un d’entre eux pour que son numéro soit automatiquement
entré dans le champ ”N˚ Client” de la table ”Commande”.
Application 2 :
91
• Fermez tous les autres onglets et double-cliquez sur la table ”Commandes”
• On change le type de données du champ ”N˚ Client” dans la table ”Commande” et on choisit ”Liste de Choix”. Si
jamais la mayonnaise peine à prendre, remettez d’abord le type Texte pour ”N˚ Client” avant de sélectionner ”Liste
de Choix”.
• Cette fois -ci, nous n’allons pas saisir tous les éléments de la liste, ça n’aurait pas de sens, il faudrait modifier cette
liste à chaque fois qu’on ajoute un nouveau client. Nous allons dire à MS Access de construire sa liste de choix en
allant chercher les éléments de cette liste dans une autre table. Pour ça on clique juste sur ”Suivant”.
• Access nous affiche les autres tables de la base : On choisit ”Clients” et on clique sur ”Suivant”.
• Access nous demande ici quels vont être les champs de cette table qui vont être affichés dans la liste ; nous n’avons
besoin que du numéro du client, de son nom, de son prénom, de sa date de naissance et de sa ville (au cas où il y aurait
deux clients homonymes et habitant la même ville, qui sait ?).
• On sélectionne à gauche les champs que l’on désire voir apparaı̂tre dans la liste, et on clique sur ”¿” pour les ajouter,
sur ”¡” pour les retirer, ”¿ ¿” et ”¡ ¡” ajoutent et retirent tous les champs.
• Nous trions dans l’ordre sur le nom, le prénom, la ville et la date de naissance (sachant que le tri nous facilite la
recherche d’une rem).
• Access affiche un exemple du contenu de la liste. Vous pouvez ici dimensionner la taille des colonnes. Nous avons
choisi d’afficher cinq champs de la table ”Clients” dans notre liste de choix, Access nous demande lequel de ces trois
champs va servir à initialiser le champ ”N˚ Client” de la table ”Commande” ; il est clair que nous voulons que le
champ ”N˚ Client” de la table ”Commande” soit initialisé avec le n˚ de client du client que nous aurons sélectionné
dans la liste, on choisit donc ”N˚ Client” et on clique sur Suivant, on nomme ensuite la liste, et on peut commencer à
saisir des commandes.
• Mais avant, essayez d’accéder aux propriétés de l’onglet ”Liste de choix” du champ ”N˚ Client” de la table ”Commandes”
• essayez de comprendre les rems affichées sans modifier quoi que ce soit.
• Essayons de comprendre ce qui se passe lorsqu’on se positionne sur le n˚ de client ?
– D’abord en mode ”création”, remarquez que le type de données correspondant à ”N˚ Client” est désormais
numérique dans la table ”Commandes” alors qu’il est NuméroAuto dans la table ”Clients”. Pourquoi ? Simple-
ment parce qu’en tant que clé étrangère dans la table ”Commandes”, si on le définissait comme NuméroAuto
dans cette table, Access lui attribuerait un numéro de façon automatique à chaque enregistrement de commande,
sans que cela ait un lien direct avec les enregistrements se trouvant dans la table ”Clients”.
– Et maintenant, en mode ”feuille de données”, Access va lire toute la table ”Clients”, et créer une liste de choix à
partir de cette table. Cette liste contient les champs que nous lui avons indiqués. Il suffit de sélectionner un client
dans la liste, et comme nous lui avons demandé d’initialiser le champ ”N˚ Client” de la table ”Commande” avec
la première colonne de la liste de choix, son numéro sera automatiquement copié.
C’est beau, non ?
Remarque : Outre les valeurs finies connues (comme c’est la cas avec le champ ”Sexe”, notons que l’utilisation de l’assis-
tant liste de choix se fait sur quasiment toutes les clés étrangères (ici, ”N˚ Client” dans la table ”Clients”).
Exercice : Faites de même pour toutes les autres clés étrangères de la BD.
Nous savons déjà qu’il existe trois types de relations : un à un, un à plusieurs (ou maı̂tre-esclaves) et plusieurs à plusieurs
(maı̂tre-maı̂tre).
Il est avantageux de relier des tables dans la requête pour accéder à de l’rem qu’aucune des tables prises seules ne possède.
Le problème avec cette technique est qu’il faut refaire les relations à chaque fois que vous faites une nouvelle requête. Access
vous offre une manière de créer des relations plus ”permanentes” entre les tables de votre base de données. Elle a aussi
l’avantage de vérifier ”l’intégrité” des relations entre les tables. À partir du menu principal, il est possible d’accéder à la
partie des relations
92
Application 3 :
1. Cliquez sur Relation dans le menu Outils puis ajouter toutes les tables (Un clic sur le bouton des relations suffit). Vous
vous souvenez des relations de type 1-n ou n-n. C’est à partir de ce moment qu’il faut mettre en œuvre les premiers
cours. C’est dans cette fenêtre que vous allez créer les relations entre les tables. Lorsque vous ouvrez cette section
pour la première fois, il n’y a pas de tables ; seulement un grand espace vide. Il faut premièrement ajouter les tables
ou les requêtes que vous voulez relier. Et maintenant, ajoutons toutes les tables de la base. Pour cela :
2. Dans la zone vide, cliquez droit sur ”Afficher la table . . . ”. Dans la fenêtre qui s’affiche, cliquez sur la table Clients.
3. Appuyer sur shift et, sans relâcher le bouton, cliquez sur la table Produits. Toutes les tables sont sélectionnées.
4. Cliquez sur Ajouter et fermez : les tables sont ajoutées dans la fenêtre Relations. Les champs en gras correspondent
aux clés primaires. Vous pouvez réorganiser vos champs en les faisant glisser. Placez-les maintenant de façon à avoir
l’architecture présenté à la page 89.
5. Nous voulons ajouter une relation entre les tables ”Clients” et ”Commandes” puis entre les tables ”Produits” et
”Lignes Commandes”. Pour cela, déplacez maintenant le champ ”N˚ client” de la table ”Clients” sur le champ ”N˚
Client” de la table ”Commandes”. Une fenêtre s’ouvre.
6. Sélectionner ”Appliquer l’intégrité référentielle” qui permet d’éviter les doublons dans une table. En fait, cette
option préserve les relations entre les enregistrements. La liaison est symbolisée par une ligne. Le chiffre 1 indique le
côté où la valeur est unique (un n˚ différent par client) et le symbole ∞ indique le côté ”plusieurs” (plusieurs lignes
de commandes par commande).
N.B. Le coté 1 est toujours une clé primaire ou un champ indexé sans doublon.
7. Sélectionner ”Mettre à jour en cascade . . . ” qui permet de changer les enregistrements dans les tables reliées :
en cas de modification du champ du coté 1, le champ des enregistrements du coté plusieurs est actualisé. Si vous
modifiez le nom d’un client dans la table Clients, toutes les lignes de la table Commandes qui contiennent ce client
seront modifiées (Comme il n’y a aucune raison que le numéro de commande change, nous n’aurons pas obligation
de cocher l’option Mettre à jour en cascade dans la relation Commandes - Lignes Commandes par exemple.).
8. Cocher enfin la case ”Effacer en cascade. . . ” qui permet d’effacer tous les enregistrements des 2 tables reliées.
9. Valider enfin par OK. Remarques ? ? ?
10. Cliquez et faites glisser le champ ”Code Produit” de la table ”Lignes Commandes” vers le champ ”Code Produit”
de la table ”Produit”. Sauf dans le cas où les deux champs sont des clés primaires, le sens de déplacement n’a pas
d’importance. Access reconnaı̂t les côtés 1 et plusieurs.
11. Cochez Appliquez l’intégrité référentielle. Cochez aussi l’option Mettre à jour en cascade. Vos remarques ? ? ?
12. Et maintenant : Sur la base de ce qui précède, reliez toutes les tables grâce à leurs clés.
13. Supprimer la relation entre Commandes et Lignes Commandes : cliquez avec le bouton droit sur la relation et
supprimez. Cliquez Oui pour confirmer.
14. Recréez cette relation, sans cocher l’intégrité référentielle. Une simple ligne relie alors les deux tables.
15. Modifier une relation : Double- cliquez la relation entre ”Commandes” et ”Lignes Commandes”. La boite Modifi-
cation des relations s’affiche : cochez l’intégrité référentielle et Cliquez Ok.
Enregistrer la mise en forme actuelle en cliquant sur l’icone symbolisant une disquette et fermer la fenêtre relations.
N.B. La fenêtre des relations représente à elle seule la structure de votre base de données. C’est à cette fenêtre qu’il
faut se référer si la base présente des dysfonctionnements.
Exercice : Renseignez les différents champs de chacune des tables : Les clients et autres fournisseurs peuvent être choisis
parmi les étudiant(e)s de la classe : Une 20aine d’enregistrements dans la table ”Clients”, une demi-douzaine au moins
dans la table ”Fournisseurs”, une trentaine dans la table ”Produits”. N’oublions pas non plus de renseigner les tables
93
”Commandes”, ”Lignes Commandes” et ”Fournisseurs Produits”.
Autres choses sur les enregistrements :

Jusqu’à présent, nous avons saisi rapidement des enregistrements dans les tables, attardons-nous sur la saisie et les recherches
/ filtres.
• Pour se déplacer parmi les enregistrements de la table, on utilise les icônes fléchées en bas à gauche de la fenêtre de
saisie.
• Pour supprimer un enregistrement, on clique à gauche de la ligne et on appuie sur la touche ”Suppr”, Access vous
demande alors une confirmation.
• Deux petits trucs avant d’en finir avec la saisie de données dans les tables : On peut cacher une colonne, pour ça, on
sélectionne en mode ”feuille de données” un champ quelconque de la table concernée et on clique droit sur l’option
”Afficher les colonnes. . . ”
• La liste des champs (colonnes) de la table s’affiche, vous sélectionnez celles que vous voulez voir apparaı̂tre, celles
que vous n’avez pas sélectionné disparaı̂tront de l’affichage quand vous cliquerez sur ”Fermer”. N.B. Attention, ça les
fait juste disparaı̂tre de l’affichage pour la saisie ; en aucun cas, le champ en Verbatim va être supprimé de la structure
de la table.
• Autre truc intéressant, on peut ”figer” une colonne, à quoi ça sert ? Si pendant la saisie nous voulons avoir en perma-
nence le numéro client, nous allons sélectionner la colonne en Verbatim en cliquant sur son titre : Une fois la colonne
sélectionnée, on clique droit sur ”Figer les colonnes”.
Application au champ ”N˚ client” de la table ”Clients”.
• Que se passe-t-il maintenant ? Quand on va déplacer l’ascenseur en bas pour modifier un des champs de l’enregistre-
ment, la colonne ”N˚ Client” sera toujours visible :
• La colonne ”N˚ Client” a bougé quand on a déplacé l’ascenseur, lorsqu’elle était figée, elle était bloquée.
• Pour autoriser le déplacement de toutes les colonnes et annuler l’option ”Figer les colonnes”, cliquez droit sur l’option
”Libérer les colonnes”.
• Pour trier la table sur un champ, on se positionne sur le champ en Verbatim (peu importe l’enregistrement) et on utilise
la petite flèche à droite pour sélectionner l’option de tri désiré.
• Les filtres permettent de limiter, de façon temporaire, les enregistrements visibles dans la table. On peut filtrer selon
deux méthodes : sur un seul critère ou sur plusieurs.
Chapitre 8
Les requêtes : Concepts théoriques et pratiques
8.1 Introduction
Nous avons vu que la plupart des SGBD offrent la possibilité d’effectuer des recherches directement dans les tables.
Les possibilités de formuler des critères de recherche sont cependant souvent assez limitées. Heureusement, la plupart des
SGBD nous offrent également la possibilité de poser pratiquement n’importe quelle ”Verbatim” à nos tables, sous forme de
requêtes.
Les requêtes servent donc à répondre aux Verbatims basées sur le contenu d’une ou de plusieurs tables. Nous allons
plus tard étudier des requêtes, qui se basent sur plusieurs tables, mais pour l’instant nous allons nous limiter aux Verbatims
simples basées sur une seule table. Exemple 81.
Reprenons notre table avec les taxis (Cf. Fig 5.3) Une requête simple serait par exemple :
Lister les marques et modèles de voitures de cylindrée supérieure à 2000 ?
Le résultat serait un sous-ensemble de la table avec seulement les enregistrements qui vérifient le critère de sélection (cy-
lindrée ¿ 2000).
Pour chacun de ces enregistrements, le SGBD affiche en plus seulement les champs explicitement demandés (fldMarque et
fldModèle).
Une requête simple produit donc comme résultat un sous-ensemble des enregistrements d’une table. En plus, une requête
nous permet d’afficher seulement certains champs pour les enregistrements appartenant à ce sous-ensemble.
On appelle ces requêtes ”Requêtes de Sélection”, puisqu’il s’agit d’une sélection de certains enregistrements.
Il n’existe cependant pas seulement des requêtes de sélection, mais également :
• Des requêtes d’insertion consistant à insérer des enregistrements dans la table. p.ex. Insérer un nouveau taxi : 4, BMW,
325i, 2500, 1270.
• Des requêtes de modification consistant à modifier des enregistrements dans la table. p.ex. Modifier la cylindrée des
Ford Orion de façon à ce qu’elle devienne 2000.
• Des requêtes de suppression consistant à supprimer des enregistrements de la table. p.ex. Supprimer toutes les BMW.
Les requêtes possèdent l’avantage de pouvoir manipuler facilement un grand nombre d’enregistrements sans que l’utilisateur
ne doive s’occuper de sélectionner enregistrement par enregistrement. Il lui suffit de spécifier des critères de sélection pour
la requête, ainsi que l’opération à effectuer (simple sélection et affichage, insertion, modification ou suppression).
Bien que les requêtes de sélection soient implémentées d’une manière plus ou moins cohérente à travers les SGBD ac-
tuels, il existe des différences subtiles en ce qui concerne les requêtes d’insertion, de modification ainsi que de suppression.
En plus, l’insertion et la suppression se font souvent de manière plus facile directement dans la table.
Au final, il existe 4 types de requêtes :
96
F IGURE 8.1
Pour chaque requête nous retrouvons le cycle suivant :
Exercice 24.
Quel est en général le résultat d’une requête :
• de sélection
• d’insertion
• de modification
• de suppression
8.2 Introduction au langage SQL

8.2.1 Généralités
Nous avons vu au chapitre précédent qu’il faut d’abord formuler une requête et puis l’exécuter, afin d’avoir des résultats.
Vous pouvez probablement bien vous imaginer que les SGBD actuels ne comprennent pas le langage naturel. Aucun SGBD
n’offre une possibilité d’écrire p.ex. Je veux voir tous les taxis dont la marque est Ford Pour formuler une requête, l’utilisateur
doit donc utiliser un langage spécialisé pour ce domaine.
Le langage SQL (Structured Query Language) est un standard international, en ce qui concerne les langages de manipu-
lation des BD. SQL est connu par tous les SGBDR. Il faut cependant mentionner que, désormais la présence de standards
internationaux tels que SQL-86, SQL-89 ou SQL-92, chaque SGBD sur le marché utilise un peu son propre dialecte du
langage SQL.
Syntaxe SQL de base

Nous distinguons les 4 types de requêtes suivants.
SELECT <Nom des champs>

FROM <Nom de la table>
INSERT INTO <Nom de la table> ?(<Liste des champs>)?

VALUES ( <Valeurs pour les champs> );
Attention : Lorsque vous n’indiquez pas la liste des champs derrière INSERT INTO , vous devez spécifier une valeur
pour chaque champ de la table derrière VALUES . Les parenthèses derrière VALUES sont obligatoires. La liste des
champs, lorsqu’elle est indiquée, contient les noms des champs, séparés par une virgule, et doit également être entourée
de parenthèses.
97
UPDATE <Nom de la table>
SET <Nom d’un champ>=valeur, <Nom d’un champ>=valeur, . .
DELETE FROM <Nom de la table>

Soit une table des employés d’une entreprise avec la structure suivante :
F IGURE 8.2
Voici le code SQL nécessaire pour effectuer quelques requêtes élémentaires :
1. Afficher le prénom et le nom de tous les employés

FROM tblEmployés;
2. Insérer une nouvelle employée :
F IGURE 8.3
INSERT INTO tblEmployés

VALUES (20, ’Angela’, ’Portante’, ’ITA’, 27, ’F’, ’Comptabilité’);
Remarques Les valeurs sont séparées par des virgules.

En SQL, les données du type TEXTE sont entourées d’apostrophes.
Les dates sont entourées du caractère # et indiquées dans le format américain #Mois/Jour/Année#
Exemple 82.
20/4/98 → #04/20/98# ou #4/20/98# ou #04/20/1998# ou #4/20/1998#
3. Afficher toutes les nationalités représentées dans la société
SELECT fldNationalité
FROM tblEmployés;
98
Quel est l’inconvénient de cette requête ?
Soit l’adaptation suivante de la requête :
SELECT DISTINCT fldNationalité

FROM tblEmployés;
Expliquez l’utilité de l’option DISTINCT
4. Afficher tous les champs pour tous les employés
SELECT idEmployé, fldPrénom, fldNom, fldNationalité, fldAge, fldSexe, fldService

FROM tblEmployés;
ou
SELECT *
FROM tblEmployés;
Remarque : L’opérateur * permet d’afficher tous les champs définis dans la table.
8.2.2 Les critères de sélection

Les critères de sélection constituent une expression logique ; qui peut prendre la valeur ’Vrai’ ou ’Faux’. Les critères de
sélection sont appliqués à chaque enregistrement d’une table. Lorsque pour un enregistrement donné, l’expression logique
prend la valeur ’Vrai’, cet enregistrement :
• fait partie du résultat pour une requête de sélection ;
• est modifié pour une requête de modification ;
• est effacé pour une requête de suppression ;
Comparaison à une valeur donnée Pour chaque enregistrement, la valeur d’un champ donné est comparée à une valeur
fixe. Cette valeur fixe est généralement une valeur numérique, une date ou un texte.
Voici les opérateurs de comparaison :
= ”est égal”
¿ ”strictement supérieur”
¡ ”strictement inférieur”
¿= ”supérieur ou égal”
¡= ”inférieur ou égal”
¡¿ ”est différent”
Exemple 83.
1. Afficher le prénom et le nom de tous les employés du service ”Marketing”

FROM tblEmployés
WHERE fldService=’Marketing’;
2. Afficher le prénom, le nom et l’âge de tous les employés plus jeunes que 50 ans
99
SELECT fldPrénom, fldNom, fldAge
FROM tblEmployés
WHERE fldAge<50;
Quel problème se pose lorsqu’on exécute cette même requête encore une fois un an plus tard ?
Comment peut-on éviter un tel problème dès le départ, déjà lors de la conception des tables ?
3. Augmentez de la valeur 1 l’âge de Madame Angela Portante.
SET fldAge=fldAge+1
WHERE fldNom=’Portante’;
Remarque : Cette requête peut provoquer des résultats imprévus au cas ou plusieurs employés ont par exemple le
s’appellent ”Portante”. Lorsque cette requête ne fournit qu’un seul enregistrement, vous pouvez exécuter la requête
”Portante”, vérifiez les enregistrements, et retenez la valeur de la clé primaire (idEmployé) pour l’employé que vous
4. Effacez tous les employés du service Informatique.
DELETE FROM tblEmployés

WHERE fldService=’Informatique’;
8.2.3 Comparaison à un filtre

Parfois, on ne connaı̂t pas la valeur exacte à laquelle on veut comparer la valeur d’un champ. Dans ce cas on peut utiliser
un filtre. Un filtre est une expression qui peut contenir des lettres, des chiffres et en plus les 2 caractères spéciaux (angl.
Wildcards) suivants :
• % représente n’importe quelle séquence de 0 ou plusieurs caractères ;
• représente un seul caractère quelconque.
Exemple 84.
Pour rechercher des personnes dont le nom est ’SCHMITZ’ ou ’SCHMITT’ ou ’SCHMIT’ etc. on définit par exemple le
filtre suivant : ’SCHMI%’
Le filtre ’BL ’ sélectionne par exemple les valeurs ’BLEU’ ou ’BLUE’ mais pas ’BLANC’
Les filtres sont utilisés ensemble avec le mot réservé LIKE. Voici la syntaxe :
WHERE <Nom du champ> LIKE <Filtre>
Exemple 85.
1. Afficher le nom et le prénom des employés dont le prénom contient un trait d’union (p.ex. Jean-Jacques)
SELECT fldNom, fldPrénom

FROM tblEmployés
WHERE fldPrénom LIKE ’%-%’;
2. Afficher le nom, le prénom et l’âge des employés dont le nom commence par ’W’, est composé de 5 lettres et se
termine par ’R’
SELECT fldNom, fldPrénom, fldAge

FROM tblEmployés
WHERE fldNom LIKE ’W R’;
100
Remarque Pour les manipulations pratiques, il faut se rendre compte que certains SGBD utilisent des caractères spéciaux
différents pour représenter une séquence de caractères respectivement un caractère quelconque. MS-Access par exemple
utilise les caractères suivants :
SQL MS-Access
Séquence de 0 ou plusieurs caractères % *
Un seul caractère quelconque ?
Les opérateurs logiques

Il existe 3 opérateurs logiques :
NOT (Négation logique) L’opérateur NOT inverse le résultat d’une expression logique.
AND (Et logique) L’opérateur AND nous permet de combiner plusieurs conditions dans une expression logique. L’expres-
sion logique retourne uniquement la valeur ’Vrai’ lorsque toutes les conditions sont remplies.
OR (Ou logique) L’opérateur OR nous permet de combiner plusieurs conditions dans une expression logique. L’expression
logique retourne la valeur ’Vrai’ lorsque au moins une des conditions est remplie.
Priorité des opérateurs logiques Lorsqu’on combine plusieurs conditions par des opérateurs logiques, le résultat final
de l’expression logique dépend de l’ordre d’exécution des différentes conditions. Cet ordre est déterminé par la priorité des
opérateurs logiques. Voici l’ordre prédéfini en SQL :
1. Déterminer le résultat logique (’Vrai’,’Faux’) des comparaisons (=, ¡, ¿ etc.)
2. Effectuer les négations (NOT)
3. Effectuer les AND
4. Effectuer les OR
Pour modifier cet ordre d’exécution, nous pouvons utiliser des parenthèses afin de grouper les différentes conditions
logiques.
Exemple 86.
1. Afficher le prénom et le nom de tous les employés qui ne travaillent pas dans le service ”Marketing”

FROM tblEmployés
WHERE NOT fldService=’Marketing’;
Formulez une requête qui affiche exactement le même résultat, sans utiliser l’opérateur NOT.

FROM tblEmployés
WHERE fldService<>’Marketing’;
2. Afficher le numéro d’employé, le prénom et le nom de tous les employés dont le nom ne commence pas par la lettre
’W’

FROM tblEmployés
WHERE fldNom NOT LIKE ’W%’;
3. Afficher le numéro de l’employé, le prénom et le nom pour les employés du service Informatique qui ont moins de 30
ans.
101
FROM tblEmployés
WHERE fldService=’Informatique’ AND fldAge<30;
4. Afficher le prénom et nom des employés féminins (code=F) qui ne travaillent pas au service marketing.

FROM tblEmployés
WHERE fldSexe=’F’ AND NOT fldService=’Marketing’;
ou

FROM tblEmployés
WHERE fldSexe=’F’ AND fldService<>’Marketing’;
5. Afficher tous les champs pour les employés de nationalité luxembourgeoise (Code=LUX) ou portugaise (Code=PRT).
SELECT *
FROM tblEmployés
WHERE fldNationalité=’LUX’ OR fldNationalité=’PRT’;
6. L’employé Emil Meier est transféré du service Comptabilité dans le service Informatique. Reflétez ce changement
dans la table.
SET fldService=’Informatique’
WHERE fldPrénom=’Emil’ AND fldNom=’Meier’;
Remarque Cette requête peut provoquer des résultats imprévus au cas ou plusieurs employés ont par exemple le
s’appellent Emil Meier. Lorsque cette requête ne fournit qu’un seul enregistrement, vous pouvez exécuter la requête
Emil Meier, vérifiez les enregistrements, et retenez la valeur de la clé primaire (idEmployé) pour l’employé que vous
7. Affichez tous les champs pour les employés féminins de nationalité luxembourgeoise (Code=’LUX’) ou allemande
(Code=’ALL’)
SELECT *
FROM tblEmployés
WHERE (fldNationalité=’LUX’ OR fldNationalité=’ALL’) AND fldSexe=’F’;
Est-ce que cette requête serait correcte sans les parenthèses ?

102
8.3 Création de requêtes QBE (Query By Example) en pratique
D’abord une BD supplémentaire à créer en guise de révision des TPs des pages et On veut mettre sur pied une BD de
gestion des spectacles cinématographiques ayant pour schéma relationnel :
• CINÉMAS (nomCinéma, numéro, rue, ville)
• SALLES (noSalle, nomCinéma, capacité, climatisée)
• HORAIRES (idHoraire, heureDébut, heureFin)
• SÉANCES (idFilm, nomCinéma, noSalle, idHoraire, tarif)
• METTEURS ES (idMES, nomMES,prenomMES)
• FILMS (idFilm, titre, annéeproduction, genre, résumé, idMES)
• ACTEURS (idActeur, nomActeur, prénomActeur, annéeNaissance)
• RÔLES (idActeur, idFilm, nomRôle)
N.B :
• Les capacités des salles sont comprises entre 50 et 500 places.
• Le genre d’un film peut être : Drame, Policier, Horreur, Action, Science-fiction, Suspense, Comédie.
• Le premier film de la journée commence à 08h :00 et le dernier à 20h :00.
• Les valeurs du champ climatisée peuvent être : Oui, Non.
Travail préliminaire
5. Pour chaque relation de la base de données, identifier par le symbole # ses clés étrangères.
6. Dessiner le schéma relationnel de la base de données.
7. Déduire du schéma obtenu au point précédent, un modèle E/A de la base de données, en respectant les normes en
matière d’écriture des noms des entités et des associations.
8. Établir le dictionnaire des données de la base de données.
Création de la BD :
En utilisant le logiciel Microsoft Office Access :
9. Créer cette base de données sous le nom ” OfficialDB+votre Nom ”
10. Créer toutes les tables de la base de données en utilisant le menu Créer, ensuite la commande Table.
11. Fermer toutes les tables créées et construire le schéma relationnel en respectant à chaque fois l’intégrité référentielle.
Insertion des données (Saisie du jeu d’essai pour le test de la BD)
Saisir dans votre base de données, le jeu d’essai ci-dessous en respectant l’ordre de création des tables. Vous songerez
également à créer les tables manquantes et complèterez les données en cas de besoin.
103
8.3.1 Présentation
Les requêtes vont servir à afficher uniquement certaines données contenues dans les tables selon certains critères. Elles
peuvent aussi faire des calculs sur vos données, et créer des sources de données pour les formulaires, les états et d’autres
requêtes pour ne citer que ces quelques applications.
Il existe différents types de requêtes que nous allons détailler dans la suite. On a ainsi la requête :
• Sélection permettant de sélectionner des enregistrements, de faire des calculs et des regroupements.
• Analyse croisée qui présente ses résultats sous forme de tableau. On l’utilisera pour comparer des valeurs, dégager des
tendances.
• Création de table qui permet de créer une table à partir des données qu’elle a extraites dans une ou plusieur(s) autres
table(s).
• Mise à Jour qui permet de modifier le contenu d’un ou plusieurs champs d’une ou plusieurs tables. C’est le moyen le
plus efficace pour mettre à jour un grand nombre d’enregistrements en une seule opération.
• Ajout qui permet d’ajouter les données qu’elle a extraites à la fin d’une table déjà existante.
• Suppression permettant de supprimer un ou plusieurs enregistrement(s) dans une ou plusieurs table(s).
8.3.2 Création proprement dite

Dans la fenêtre principale d’Access, cliquez sur l’onglet ”Requêtes”, puis sur le bouton ”Nouveau”. Access nous propose
5 façons de créer une requête.
• Mode création : nous allons créer la requête de A à Z par nous-mêmes.

104
• Assistant de Requête simple : Crée une requête simple sur une ou plusieurs tables, on pourra, dans cette requête simple,
faire des calculs, des regroupements.
• Assistant de Requête d’analyse croisée : Aide à la création d’une requête d’analyse croisée.
• Assistant de Requête trouver les doublons : il localise les doublons d’enregistrements dans une table ou une requête.
• Assistant de Requête de non-correspondance : il localise les Enregistrements d’une table auxquels ne correspond
aucun autre enregistrement d’une autre table.
Algorithme de création de requête en Mode création
1. Aller dans le menu Créer ;
2. Dans le groupe Autres, sélectionner Création de requête ;
3. Dans la boite de dialogue, sélectionner la table de la requête et cliquer sur Ok ;
4. Terminer avec les choix liés aux noms des colonnes.
Application : (Requête 1 nommée ListeSalleSup250places). Quelles sont les salles de plus de 250 ?
On veut voir apparaı̂tre le champ noSalle, le champ capacité et le champ climatisée, le critère de la requête va se faire sur
le champ capacité. Un des champs proposé s’appelle ’*’, utilisé pour désigner ”tous les champs de la table”. S’il est choisi,
tous les champs de la table apparaı̂tront dans le résultat de la requête, en plus des autres champs que vous aurez choisis.
• La ligne ”Table” sert à sélectionner la table à laquelle appartient le champ sélectionné, dans notre cas, il n’y a qu’une
table, le choix est vite fait.
• La colonne ”Tri” indique de quelle façon vont être triés les champs dans le résultat de la requête : il y a trois sortes de
tri : Croissant (de A à Z), Décroissant (de Z à A) et non trié.
• La colonne ”Afficher” indique si le champ doit être affiché ou non.
• Enfin la colonne ”Critères” va indiquer le critère de la requête, on veut la liste des salles ayant plus de 250 places ; le
critère est donc : 250 dans la colonne capacité.
8.3.3 Définition des critères de sélection

Opérateurs On peut utiliser dans les requêtes les opérateurs suivants : ”=” pour Egal, ”” pour Différent, ”” pour
Strictement inférieur, ”” pour Strictement supérieur, ”≤” pour Inférieur ou égal, ”≥” pour Supérieur ou égal. Access met
à notre disposition d’autres opérateurs :
• ”Entre” sélectionne les enregistrements pour lesquels la valeur d’un champ est comprise dans un intervalle de valeurs.
Exemple : Entre ”A” et ”C”, Entre 10 et 20, Entre #01/01/1999# et #31/12/1999#
• ”Dans” sélectionne les enregistrements pour lesquels la valeur d’un champ est comprise dans une liste.
Exemple : Dans (”André” ; ”Philippe”)
• ”Est” sélectionne les enregistrements pour lesquels un champ est vide ou non.
Exemple : Est NULL
• ”Comme” sélectionne les enregistrements contenant une donnée approximative.
Exemple : Comme ”And*”
• ”Pas” sélectionne les enregistrements ne correspondant pas au critère.
Exemple : Pas Entre ”A” et ”C”
Fonctions On peut intégrer des fonctions dans les critères de sélection. Access met à notre disposition un très grand
nombre de fonctions (pour en avoir la liste complète, consultez l’aide intégrée à Access). Ce sont les mêmes fonctions que
celles qui sont utilisés dans les contrôles des formulaires (et d’ailleurs dans tous les logiciels de la gamme Microsoft Office).
Exemple : Mois (#15/07/2014#) renvoie 7.
Une autre fonction, Date() renvoie la date du jour. On peut utiliser ces fonctions dans des critères de sélection :
Application : (Requête 2 nommée ListeFilms1971). Quels sont les films produits en 1991 ?
Application : (Requête 3 nommée CapaciteEntre). Quelles sont les salles de capacité comprise entre 50 et 200 ?
105
8.3.4 Plusieurs critères portant sur des champs différents
On peut avoir plusieurs critères de sélection, ces critères étant séparés entre eux par des OU ou des ET.
Application : (Requête 4 nommée ActeurLIKEn). Quelle est la liste des acteurs dont le nom commence par ”K” ou prénom
commence par ”A” ?
Application : (Requête 5 nommée ReservationC25000). Quelles sont les séances du film dont le tarif est plus grand
que 5000 ?
En règle générale :
• Si deux critères sont séparés par des ET, on les place sur la même ligne.
• Si deux critères sont séparés par des OU, on les place sur des lignes différentes.
8.3.5 Requête paramétrée

Pour l’instant, les critères de chaque requête que nous avons fait étaient indiqués explicitement dans la requête. Sup-
posons maintenant que nous voulions, dans le TP de la page 9.1, faire une requête du type : ” Liste de tous les clients qui
habitent dans une ville ” mais qu’on veuille entrer nous-même la ville au moment de l’exécution. On ne connaı̂t pas par
avance la ville en Verbatim, et on ne va pas préparer autant de requêtes qu’il peut y avoir de villes (on n’est pas sorti de
l’auberge), la solution la plus simple est alors de demander à l’utilisateur d’entrer la ville, et de faire la requête en fonction
de ce qu’il a entré comme donnée.
! ! ! Avant de continuer, prenez une pause pour deviner et trouver un moyen pour ce faire . . .
Solution ! Pour faire ça, au lieu d’indiquer une ville, on va inscrire dans la zone de critère ”=[Entrez la ville]”.
Que va-t-il se passer lorsqu’on va exécuter la requête ?
Habituellement, pour Access, tout ce qui est indiqué entre crochets est le nom d’un champ, si on avait mis par exemple =
[Nom], il aurait cherché les clients qui habitent une ville qui s’appelle comme leur nom. Or ici, [Entrez la ville] n’est pas un
nom de champ, Access ne sait donc pas ce que c’est, et il demande à l’utilisateur d’entrer la valeur de ce champ inconnu.
L’utilisateur va entrer ici la ville (notez que le message affiché est ce qui était indiqué entre crochets dans la requête). Mainte-
nant, à chaque fois que Access va rencontrer dans la requête [Entrez la ville], il va le remplacer par ce qu’a saisi l’utilisateur.
Si l’utilisateur a saisi Douala, Access va remplacer dans son critère =[Entrez la ville] par = ”Douala”.
Application : (Requête 6 nommée FilmsParamétrés). Quel sont les films ayant un titre donné en paramètre ?
8.3.6 Les requêtes Multi-tables

Pour l’instant, nos requêtes ne portaient que sur une seule table, il est possible de faire des requêtes qui portent sur
plusieurs tables simultanément. Dans ce cas, les requêtes peuvent être très complexes.
Exercice : A nouveau dans le TP de la page , on veut la liste des clients ayant commandé le code de produit P001. Comme
toujours, au lieu de P001, vous pouvez taper un code de produit qui convienne aux définitions faites dans votre base de
données.
Réfléchissez-y une ou deux minutes. Très honnêtement, essayez tout(e) seul(e) avant de consulter la solution ci-dessous.
Cela vous permet de capter une fois pour toute !
Solution ! On va choisir ici toutes les tables entrant en jeu pour pouvoir faire la requête. Ici on veut la liste des clients, il faut
donc la table clients. ”ayant commandé”, il faut donc la table commandes, ”le produit P001”, il faut donc la table produits.
Il faut aussi faire intervenir la table Lignes-commandes.
Pourquoi ? Parce que c’est elle qui fait la liaison entre la table commande et la table produits. De façon générale, lorsqu’on
fait une requête portant sur plusieurs tables, il faut respecter deux règles :
• Toutes les tables intervenant dans la requête doivent être reliées entre elles, il ne doit pas y avoir de tables isolées, sinon,
Access va essayer de trouver lui-même les relations entre ces tables isolées et parfois le résultat peut être folklorique.
C’est vous dire la place capitale que vous devez accorder préalablement à la définition des relations sous Access.
• Il ne doit pas y avoir de tables n’ayant rien à faire dans la requête, sinon Access pourrait produire des résultats erronés
pour votre requête.
En résumé : toutes les tables nécessaires, mais pas plus. Vous pouvez également noter que, une fois les bonnes tables
installées avec les bonnes relations entre elles, la requête est fort simple, il suffit d’indiquer produits=P001, et Access, grâce
aux relations, va retrouver la liste des clients ayant commandé ce produit.
Application : (Requête 7 nommée ActeursVertigo). Quelle est la liste des Acteurs (Nom et Prénom) ayant joué dans le film
Vertigo après l’année 1990.
106
8.3.7 Les fonctions de regroupement
Jusqu’à présent, nos requêtes nous permettent de répondre à des Verbatims du type : ”Liste des clients habitant Douala”,
”Liste des produits commandés par le client 1”. Grâce aux fonctions de regroupement, nous allons pouvoir répondre dans le
TP de la page , à des Verbatims du type : ”Combien de clients habitent Douala ?” ou ”Pour combien à commandé chaque
client ?”.
Pour cela, cliquez sur le bouton Σ :
Une nouvelle ligne ”Opération” apparaı̂t dans la requête, c’est grâce à elle que nous allons faire nos opérations.
a- Combien de clients habitent Douala ?
Qu’y-a-t-il de différent ? Nous avons deux champs : nous allons compter le nombre de clients. Puisque chaque client a
un numéro, on insère dans la requête le numéro de client car c’est le nombre de ces numéros que nous allons compter,
il faut qu’on compte les clients habitant Douala, d’où l’insertion du deuxième champ, Ville. La différence est sur la ligne
Opération : Elle indique comment va se faire l’opération, si nous voulons compter, on va choisir l’opération ”compte”. Dans
tous les champs où il y a un critère de sélection (ici Ville = ”Douala”), on choisira l’opération où. Le résultat de la requête
sera une table avec un unique champ, non modifiable, qui indiquera le nombre de clients habitant Paris.
b- Montant commandé par chaque client. Exercice : ! ! ! 3 minutes de réflexion sincère avant la . . . .
Solution ! Ca se corse ! Ici, on veut, par client, la somme de ses commandes.
Nous ajoutons tout d’abord les champs numéro, nom et prénom à notre requête, après avoir pris soin de sélectionner toutes
les tables utiles à savoir, ”Clients” et ”Produits”. Cependant, comme elles sont liées par d’autres tables, celles-là aussi sont
sélectionnées car cela nous servira à établir le lien entre les données. ( ! ! ! Encore les relations : mal faites, c’est le désastre.
Et même dans votre vie). A partir du moment où on veut un résultat par catégorie (une somme par client, un nombre de
clients par ville, etc ?), il y a regroupement, ici on veut la somme des commandes regroupées par clients, c’est pour ça qu’on
a choisi comme opération pour numéro de client ”Regroupement”.
Pourquoi a-t-on ajouté le champ ”nom” ? Simplement pour ne pas avoir une liste de numéros avec un montant correspondant.
Il faudrait encore fouiller pour savoir à qui est le numéro en Verbatim.
Pourquoi dans ce cas, n’a-t-on pas regroupé les clients par leur nom au lieu de le faire par numéro et nom ? Parce que plusieurs
clients peuvent avoir le même nom et qu’on ne veut pas cumuler le montant des commandes par clients homonymes, on
regroupe donc les clients par numéro et nom.
Enfin, le troisième champ : on veut la somme du montant des commandes : qu’est-ce qu’une commande ? c’est une liste
de prix unitaires * une quantité. A la place d’un champ, on indique donc qu’on veut les prix unitaires * les quantités. La
syntaxe est [nom de la table] ![champ de la table], une commande, c’est donc une liste de [produits] ![prix unitaire]
* [lignes commandes] ![quantité]. Et on veut la somme de toutes ces commandes, on choisi donc l’opération ”Somme”.
Visualisez le résultat de la requête. Et, si un même client apparaı̂t plusieurs fois dans votre le résultat de votre requête,
arrangez vous à ne le faire apparaı̂tre qu’une seule fois.
Applications :
1. (Requête 8 nommée NbConcertZ). Combien de concerts ayant pour titre ZANZIBAR ont eu lieu ?
2. (Requête 9 nommée ChampsCalculés). Quel est le Montant et Marge de bénéfice du plein d’une salle
Les opérations
En plus de la somme et de compte, il existe d’autres opérations possibles :
• ”Dernier” pour déterminer la valeur du dernier enregistrement,
• ”Ecartype” pour l’écart type,
• ”Max” pour la valeur la plus élevée,
• ”Min” pour la valeur la plus faible,
• ”Moyenne” pour la moyenne,
• ”Premier” pour la valeur du premier enregistrement,
• ”Somme” pour le total,
• ”Var” pour la variance.
Applications : (Requête 10 nommée OpérationsConcertsXMaleya). Donner le nombre de concerts de XMALEYA ainsi
que la date de présentation la plus récente.
107
D’autres exemples en exercice :
Dans le TP de la page , produire la requête donnant :
• Le nombre de clients nommés X par ville, X étant un paramètre introduit par l’utilisateur (i-e en mode affichage)
• La liste des clients ayant commandé plus de 100000 F du produit P001.
• Le montant total des produits X livrés par le fournisseur Y, X et Y étant choisi par l’utilisateur
8.3.8 Les Requêtes d’Analyse Croisée

Les requêtes d’analyse croisée permettent de répondre à des Verbatims du type ”qui à commandé combien de quoi ?”.
Elles retournent le résultat sous forme d’un tableau comportant des champs en abscisse et en ordonnée, avec, dans chaque
case la réponse à notre Verbatim.
Qui Qui
Exemple : Qui a commandé combien de quoi ? Quoi Combien Combien
Quoi Combien Combien
L’en-tete ”Qui” va contenir le nom des clients, l’en-tête ”Quoi” va contenir la liste des produits et combien va donner,
pour chaque client, le nombre de produits qu’il a commandé.
Appliqué au TP de la page , comment procède-t-on ?
1. D’abord on crée une requête standard : pour cette requête nous avons besoin du nom dans la table clients, du libellé
du produit dans la table produit et de la quantité commandé dans la table lignescommandes.
2. On transforme la requête en requête d’analyse croisée en allant dans le menu ”Requête” et en choisissant ”Analyse
croisée”.
3. Une nouvelle ligne apparaı̂t dans la requête : la ligne ”Analyse”
4. Dans cette ligne, on va indiquer si le champ qu’on a choisi va être l’en-tête des colonnes, l’en-tête des lignes ou la
valeur contenue dans les cases du tableau.
5. L’Opération pour les en-têtes est toujours ”Regroupement”
6. L’Opération pour les valeurs des cases dépend de ce qu’on cherche, ici on cherche le nombre de produits acheté,
l’opération est donc ”Somme”
Applications :(Requête 11 nommée RôlesJoués). Quel Acteur a joué quel rôle ?
8.3.9 Les Requêtes Action

Les requêtes faites jusqu’à présent se contentent de retourner le résultat d’une sélection sous forme de table, cette table,
étant, selon le type de requête, modifiable. Il existe cependant d’autres types de requêtes, les requêtes action, ces requêtes
vont permettre de :
• Créer une table à partir du résultat d’une requête
• Ajout des enregistrements à une table à partir des résultats de la requête
• Mettre à Jour une table en fonction de certains critères
• Supprimer des enregistrements répondant aux critères de la requête
Requêtes Création
Une requête création crée une table à partir des résultats qu’elle produit à partir d’une table existante. Dans le TP de
la page , supposons que nous voulions créer une table ”Commandes réglées” qui contiendrait la liste des commandes déjà
réglées.
1. Créer la requête normalement : nous voulons la liste des commandes réglées :
2. On la transforme en requête Création (Menu Requête / Requête Création de table)

108
3. Access nous demande le nom de la table à créer : Attention, si vous sélectionnez une table existante, la table va être
écrasée par cette opération
4. Exécutez la requête avec l’icône point d’exclamation : la table va être créée avec le résultat de la requête. Si vous vous
voulez vérifier avant de créer la table quel sera le résultat de la requête, cliquez sur l’icône : Une fois que le résultat
sera conforme à vos attentes, vous pourrez cliquer sur l’icône point d’exclamation.
Applications :(Requête 12 nommée AncienFilm). Créer une table ANCIENSFILMS qui contiendrait la liste des concerts
qui sont passés avant l’an 1997.
Requêtes Ajout
Une requête Ajout copie tout ou partie des enregistrements d’une table (la table source) à la fin d’une autre table (la table
cible). Toujours dans notre table ”Commandes réglées”, nous voulons ajouter les commandes qui ont été réglées depuis la
semaine dernière :
1.
2. Création de la requête normale :
3. On la transforme en requête Ajout (Menu Requête / Requête Ajout)
4. Access nous demande le nom de la table à laquelle il faut ajouter le résultat de la requête.
5. Comme précédemment, avec les icônes Affichage et point d’exclamation, vérifiez et validez votre requête.
Applications :(Requête 12 nommée AjoutFilm). Dans la table ANCIENSFILMS, ajouter les FILMS de 1997, 1998 1999
et 2000.
Requêtes Mise à Jour

Les requêtes mise à jour permettent de modifier rapidement tous les enregistrements d’une table ou un groupe d’entre
eux : Supposons que l’on veuille augmenter de 10% le prix des produits dont le prix actuel est inférieur à 1000 F.
1. On crée une requête, et dans le menu Requête, on clique sur ”Requête Mise à Jour”
2. Un champ ”Mise à jour” apparaı̂t dans la requête, c’est là qu’on va indiquer la modification qui va avoir lieu : Dans la
case Mise à Jour, on a indiqué, qu’à la place du prix unitaire, nous voulions [prix unitaire]*1.1 (soit une augmenta-
tion de 10%), ceci pour les produits dont le prix est inférieur à 1000 (critère).
Applications :(Requête 13 nommée Update). Augmenter de 10% le tarif des concerts dont le prix d’entrée est inférieur à
1500.
Chapitre 9
Création des formulaires sous MS Access
9.1 Présentation
Un formulaire est un objet de base de données qui permet d’entrer, de modifier ou d’afficher les données d’une table ou
d’une requête. Les formulaires permettent également de contrôler l’accès aux données en n’affichant, par exemple, que cer-
tains champs ou lignes de données. Par exemple, il est possible que certains utilisateurs n’aient besoin d’afficher que certains
champs d’une table constituée d’une multitude de champs. En leur proposant un formulaire qui ne contient que ces champs,
il leur sera plus facile d’utiliser la base de données. Vous pouvez également ajouter des boutons et d’autres fonctionnalités à
un formulaire afin d’automatiser les opérations fréquemment effectuées.
Les formulaires peuvent être comparés à des fenêtres à travers lesquelles les personnes voient et atteignent votre base de
données. Un formulaire efficace permet d’accélérer l’utilisation d’une base de données dans la mesure où les personnes
n’ont pas besoin de rechercher les éléments dont elles ont besoin. Un formulaire d’aspect agréable améliore non seule-
ment la convivialité et l’efficacité de la base de données, mais il permet également d’éviter la saisie de données incorrectes.
Microsoft Office Access contient des outils destinés à simplifier la création de formulaires, et propose différents types de
formulaires et de nouvelles fonctionnalités qui améliorent la facilité d’emploi de votre base de données.
Ainsi, le formulaire va nous permettre de manipuler sur une même feuille des rems provenant de plusieurs tables simul-
tanément : par exemple, dans notre exemple de base de données Magasin L3 issu du TP de la page , nous pourrons avoir
un formulaire qui affichera dans la même fenêtre toutes les rems concernant une commande : rems générales sur la com-
mande (provenant de la table Commande, rems sur le client ayant passé cette commande (provenant de la table Clients
et le détail de cette commande (provenant des tables lignes-commande et Produits) alors que précédemment, ces données
étaient éclatées sur plusieurs feuilles de données.
Les rems saisies ou modifiées dans le formulaire seront modifiées dans les tables à partir desquelles le formulaire a été créé.
9.2 Créer un formulaire à partir d’une table

Nous allons créer le formulaire associé à la table Clients. Pour créer un formulaire, on se place dans la fenêtre principale
d’Access et on clique sur l’onglet Formulaire, puis sur le bouton Nouveau. . . .
Il existe plusieurs méthodes pour générer un formulaire :
• Créer un formulaire à l’aide de l’aide de l’outil Formulaire :

L’outil Formulaire permet de créer facilement et rapidement un formulaire. Lorsque vous utilisez cet outil, tous les
champs de la source de données sous-jacente sont placés dans le formulaire. Vous pouvez commencer à utiliser le
nouveau formulaire immédiatement, comme vous pouvez le modifier en mode Page ou Création pour l’adapter à vos
besoins.
Application :
Dans le volet de navigation, cliquez sur la table ou la requête qui contient les données que vous souhaitez faire figurer
dans le formulaire. Dans notre cas, il s’agit de la table Clients.
Sous l’onglet Créer, dans le groupe Formulaires, cliquez sur Formulaire.
Access crée le formulaire et l’affiche en mode Page. Ce mode vous permet d’apporter des modifications à la conception
du formulaire tout en ayant les données affichées. Par exemple, vous pouvez ajuster la taille des zones de texte en
fonction des données à afficher, si nécessaire. Si Access détermine que seule une table a une relation un-à-plusieurs
avec la table ou la requête qui a servi à la création du formulaire, Access ajoute une feuille de données au formulaire,
basée sur la table ou la requête associée. Par exemple, si vous créez un formulaire standard à partir de la table Clients,
110
et qu’une relation un-à-plusieurs est définie entre la table Clients et la table Commandes, la feuille de données affiche
tous les enregistrements de la table Commandes se rapportant à l’enregistrement Client actif. Vous pouvez supprimer
la feuille de données du formulaire si vous jugez ne pas en avoir besoin. S’il existe plusieurs tables liées par une
relation un-à-plusieurs avec la table qui a servi à créer le formulaire, Access n’ajoute pas de feuilles de données au
formulaire. Tel n’est pas le cas dans notre BD.
• Créer un formulaire Double affichage à l’aide de l’outil formulaire Double affichage.

Le formulaire double affichage est une nouvelle fonctionnalité de Microsoft Office Access qui offre deux affichages
simultanés des données : un affichage Formulaire et un affichage Feuille de données. Ces deux affichages sont rattachés
à la même source de données et sont toujours synchronisés. Ainsi, si vous sélectionnez un champ dans une partie
du formulaire, le même champ est sélectionné dans l’autre partie du formulaire. Vous pouvez ajouter, modifier ou
supprimer des données dans chacune des parties, comme en modifier ou en supprimer (à condition que la source
d’enregistrement soit modifiable et que vous n’ayez pas configuré le formulaire de façon à empêcher ces opérations).
L’utilisation de formulaires double affichage offre les avantages de deux types de formulaires dans un seul et même
formulaire. Par exemple, vous pouvez utiliser la partie feuille de données du formulaire pour retrouver rapidement
un enregistrement, et utiliser ensuite la partie formulaire pour consulter ou modifier l’enregistrement. Pour créer un
formulaire double affichage à l’aide de l’outil Formulaire double affichage :
– Dans le volet de navigation, cliquez sur la table ou la requête qui contient les données que vous souhaitez faire
figurer dans le formulaire (Dans notre cas, la table Clients). Vous pouvez également ouvrir la table ou la requête
en mode Feuille de données.
– Sous l’onglet Créer, dans le groupe Formulaires, cliquez sur Formulaire double affichage.
– Access crée le formulaire et l’affiche en mode Page. Ce mode vous permet d’apporter des modifications à la
conception du formulaire tout en ayant les données affichées. Par exemple, vous pouvez ajuster la taille des
zones de texte en fonction des données à afficher, si nécessaire.
• Créer un formulaire affichant plusieurs enregistrements à l’aide de l’outil Plusieurs éléments : Lorsque vous créez un
formulaire à l’aide de l’outil Formulaire standard, le formulaire créé par Access affiche un seul enregistrement à la
fois. Si vous avez besoin d’un formulaire qui affiche plusieurs enregistrements tout en offrant davantage de possibilités
en termes de personnalisation qu’une feuille de données, vous pouvez utiliser l’outil Plusieurs éléments.
Dans le volet de navigation, cliquez sur la table ou la requête qui contient les données que vous souhaitez faire figurer
dans le formulaire (Par exemple, la table Clients).
Sous l’onglet Créer, dans le groupe Formulaires, cliquez sur Plusieurs éléments.
Access crée le formulaire et l’affiche en mode Page. Ce mode vous permet d’apporter des modifications à la concep-
tion du formulaire tout en ayant les données affichées. Par exemple, vous pouvez adapter la taille des zones de texte
en fonction des données à afficher.
Lorsque vous utilisez l’outil Plusieurs éléments, le formulaire créé par Access ressemble à une feuille de données.
Les données sont disposées dans des lignes et des colonnes, et vous voyez plusieurs enregistrements à la fois. Toute-
fois, un formulaire Plusieurs éléments offre davantage d’options de personnalisation qu’une feuille de données, avec
notamment la possibilité d’ajouter des éléments graphiques, des boutons et d’autres contrôles.
• Créer un formulaire à l’aide de l’Assistant Formulaire :

Pour être plus sélectif quant aux champs à faire figurer sur votre formulaire, vous pouvez utiliser l’Assistant Formulaire
à la place des divers outils de création de formulaires mentionnés précédemment. Vous pouvez également définir la
façon dont les données sont regroupées et triées, et vous pouvez utiliser les champs de plusieurs tables ou requêtes, si
tant est que vous ayez préalablement spécifié les relations entre les tables et les requêtes.
Application :
Sous l’onglet Créer, dans le groupe Formulaires, cliquez sur Plus de formulaires, puis sur Assistant Formulaire.
– Suivez les instructions fournies dans les pages de l’Assistant Formulaire.

– REMARQUE : Si vous souhaitez inclure des champs de plusieurs tables ou requêtes dans votre formulaire, ne
cliquez pas sur Suivant ou sur Terminer après avoir sélectionné les champs de la première table ou requête dans
la première page de l’Assistant Formulaire. Au lieu de cela, répétez les étapes afin de sélectionner une table ou
une requête, puis cliquez sur les champs supplémentaires que vous souhaitez inclure dans le formulaire. Cliquez
ensuite sur Suivant ou sur Terminer pour continuer.
– Dans la dernière page de l’Assistant, cliquez sur Terminer.
111
Application :
Dans la partie gauche de la fenêtre, nous allons choisir la table à partir de laquelle le formulaire va être généré : les
rems provenant de cette table seront affichées dans le formulaire, les modifications ou ajouts que nous ferons dans le
formulaire seront répercutées dans cette table :
Nous choisissons ici la table Clients et on active l’Assistant Formulaire (comme indiqué ci-dessus).
Nous allons choisir ici quels sont les champs de la table que nous voulons voir dans le formulaire, si nous voulons être
en mesure de modifier tous les champs de chaque enregistrement de la table, il faudra les choisir tous ; Par contre, si
notre formulaire ne doit servir qu’à afficher certaines rems, on choisira uniquement les champs pertinents.
Attention : Dans un formulaire, on va pouvoir, comme dans la feuille de données, ajouter des enregistrements dans la
table, les champs non présents dans le formulaire ne seront pas initialisés (ils resteront vides) lors de l’ajout. (Le seul
moyen alors pour remplir ces champs sera d’aller dans la feuille de données). Pour choisir les champs à ajouter ou à
enlever dans le formulaire, on va utiliser les boutons :
¿ : Ajouter le champ dans le formulaire

¿ ¿ : Ajouter tous les champs dans le formulaire
¡ : Supprimer un champ du formulaire
¡ ¡ : Supprimer tous les champs du formulaire
Pour le moment, nous affichons tous les champs de la table Clients. Ensuite nous cliquons sur Suivant. On choisit ici
la façon d’afficher les champs choisis dans le formulaire. Quatre possibilités se présentent :
Colonne simple : Le formulaire va afficher les champs sous la forme : nom du champ : contenu du champ. Le for-
mulaire va afficher les champs d’un enregistrement à la fois.
Tabulaire : Le formulaire va afficher les champs choisis sous la forme d’un tableau : en haut du formulaire vont être
affichés les noms des champs, et, en dessous sous forme de tableau, le contenu, avec un enregistrement par ligne.
Cette façon d’afficher les données ressemble à la feuille de données.
Feuille de données : C’est la même chose que la feuille de données utilisées pour saisir des rems dans une table, la
seule différence est que ne sont affichés ici que les champs sélectionnés dans l’étape précédente.
Justifié : Va afficher les champs choisis les un à la suite des autres, ce n’est pas très beau (enfin c’est une Verbatim
de goût).
Nous utiliserons le plus souvent le mode Colonne simple ou le mode Tabulaire. Nous choisissons ici le mode Colonne
Simple, puis on clique sur Suivant.
On choisit ici le ”décor” que l’on va donner au formulaire, il existe quasiment une trentaine de décors prédéfinis. Bien
sûr, on pourra, par la suite, modifier un décor choisi ici. Choisissez le décor qui vous semble le meilleur (celui qui
vous plaı̂t le plus).
Enfin, on va nommer son formulaire, c’est sous ce nom qu’il apparaı̂tra dans l’onglet Formulaires de la fenêtre
principale d’Access, puis cliquez sur Terminer, le formulaire est créé.
Access nous propose alors de commencer tout de suite la saisie dans notre nouveau formulaire. Vous pouvez voir ici
le formulaire tel qu’il est une fois créé : Il utilise les champs choisis dans la table sélectionnée, il affiche les champs
sous forme de Colonne simple (un couple nom du champ - contenu du champ par ligne) et utilise le décor choisi.
Les rems qui vont être saisies ou modifiées dans ce formulaire le seront dans la table qui est associée à ce formulaire.
Pour se déplacer parmi les enregistrements dans le formulaire, on utilise les icônes fléchés en bas du formulaire :
Exercice :
Sur cette base, créez des formulaires pour chacune des 6 tables de votre BD (Suivre l’ordre de création des tables).
9.3 Les contrôles

Pour modifier l’aspect et le contenu du formulaire, on bascule en mode création dudit formulaire.
Le formulaire est affiché en mode modification et le menu Création est activé par défaut.
Le formulaire est constitué de plusieurs parties : L’en-tête, le détail et le pied. Dans le cas d’un formulaire de type Colonnes
Simples (comme c’est le cas ici), l’en-tête et le pied n’ont aucune importance, ils sont utiles lorsque le formulaire est affiché
sous forme de tableau (type Tabulaire ou Feuille de Données), auquel cas, l’en-tête va contenir le titre des colonnes, le détail
va définir la façon dont vont être affichées les rems dans chaque ligne du tableau (nous verrons ça plus tard) et le pied pourra
112
contenir des rems supplémentaires, comme par exemple, après avoir affiché un tableau de nombres, il pourra afficher la
somme de ces nombres.
Tout ce qui se trouve sur le formulaire s’appelle un contrôle : un texte affiché sur le formulaire est un contrôle, un champ
d’un enregistrement est un contrôle, une image placée sur le formulaire est un contrôle : tout ce qui est affiché dans le
formulaire est un contrôle. La boı̂te à outils Contrôle du menu Création affiche tous les contrôles possibles que l’on peut
placer sur un formulaire. Ils sont assez nombreux et permettent d’afficher tous les types d’informations possibles (même du
son ou de la vidéo !).
Ces contrôles peuvent être divisés en trois catégories :
Les contrôles indépendants : Ils n’ont aucune relation avec la table qui est liée au formulaire (n’oubliez pas que chaque
formulaire manipule des rems provenant d’une table de la base). Par exemple une image placée sur le formulaire n’a
pas de relation avec la table, c’est un contrôle indépendant, du texte affiché sur le formulaire (on pourrait par exemple
placer un titre ”Formulaire Clients” en haut du formulaire), ce texte ne provient pas de la table, il n’a aucun rapport
avec elle, c’est donc un contrôle indépendant.
Les contrôles dépendants : Les contrôles dépendants sont liés à la table liée au formulaire, ils vont afficher le contenu d’un
champ, toute modification dans ce contrôle ira modifier le champ auquel il est lié dans la table : Dans notre exemple,
le contrôle à droite est dépendant du champ Nom de la table Clients, il affichera, pour l’enregistrement courant, le
contenu du champ Nom. Toute modification dans ce contrôle ira modifier le contenu du champ Nom de la table Client
pour l’enregistrement en cours.
Attention : Notez que le contrôle à gauche est un contrôle indépendant, il se contente d’afficher le texte ”nom”, tandis
que celui de droite est dépendant et va chercher son contenu dans le champ de la table dont le nom est affiché (champ
”nom”), nous verrons plus bas comment rendre un contrôle dépendant.
Les contrôles calculés : Les contrôles calculés ne vont pas chercher les rems qu’ils vont afficher dans un champ de la table
lié au formulaire mais à partir du contenu d’autres contrôle du formulaire, par exemple un contrôle dans le formulaire
lié à la table Produit pourra afficher le prix TTC à partir des contrôles affichant les prix hors taxe et la TVA.
La liste complète des contrôles que nous pourrons utiliser apparaı̂t dans le bouton Contrôle du menu Création. Vous pouvez
déplacer le curseur sur chacun d’eux pour obtenir leur nom (i-e leur rôle). Nous expliquons ci-dessous le rôle de certains
d’entre eux.
9.3.1 Le contrôle ”Etiquette”

Il va être utilisé pour afficher du texte ”statique”, c’est à dire qui ne variera pas d’un enregistrement à l’autre, c’est
donc un contrôle indépendant, qui servira typiquement à afficher par exemple le titre du formulaire, ou le nom d’un champ
dont le contenu sera affiché à côté dans un contrôle dépendant. Dans notre formulaire, tous les noms des champs affichés à
gauche sont des contrôles Etiquette, ce sont des textes statiques ne dépendant de rien, on peut modifier ce qui est affiché
sans affecter quoi que ce soit dans la table associée au formulaire.
9.3.2 Le contrôle ”Zone de Texte”

Ce contrôle est l’un des contrôles les plus utilisés dans les formulaires, on va, dans ce contrôle, pouvoir saisir des
données. Typiquement, ce contrôle est soit un contrôle dépendant, soit un contrôle calculé. Pourquoi ? On peut, dans ce
contrôle, saisir des rems, il serait alors judicieux que les rems saisies puissent servir à quelque chose, si le contrôle n’est lié
à aucun champ de la table associée au formulaire, les rems que l’on va taper vont se perdre dans la nature dès qu’on sera
passé sur l’enregistrement suivant. En revanche, si le contrôle est lié à un champ de la table, les rems entrées dans ce contrôle
seront placées dans le champ lié au contrôle.
Tout ce qui sera entré dans un contrôle dépendant affectera le contenu du champ auquel il est lié. Bien sûr, rien n’interdit de
113
lier un même champ sur plusieurs contrôles dans le même formulaire (ce qui n’a pas, à priori, d’intérêt).
Dans notre formulaire, tous les contrôles dans lesquels on va saisir des rems sur les clients sont des contrôles dépendants liés
à des champs de la table. Le nom du champ auquel est lié le contrôle est d’ailleurs écrit dans ce contrôle.
Souvenez-vous que nous avons vu différentes manières de créer un formulaire mais nous n’avons pas vu comment créer
un formulaire en mode Création de formulaire, donc à partir de rien du tout, sans assistant. Tout d’abord, fermez tous les
formulaires créés et actuellement ouvers dans Access. Nous voulons créer un formulaire nommé Saisie Clients. Pour cela,
• dans la boı̂te à outils Formulaires du menu Créer , nous cliquons sur Création de formulaire. Access nous crée un
formulaire vierge.
• Ensuite, ce qu’il faut faire, c’est dire à Access où puiser les rems qui figureront sur ce formulaire. Bien entendu, il
s’agit de la table Clients. Alors, nous double-cliquons sur le petit carré noir situé à l’intersection des règles verticales
et horizontales d’Access. Une feuille de propriétés s’affiche, laquelle contient un ensemble d’onglets. Nous cliquons
sur l’onglet Données puis, dans la partie Source de cet onglet, nous sélectionnons la table Clients.
• A partir de là, nous pouvons insérer tous les contrôles nécessaires dans ce formulaire.
• Nous enregistrons notre formulaire sous le nom Saisie Clients.
Ledit formulaire est ainsi créé, même s’il est encore vierge. Nous nous devons donc d’y insérer un certain nombre de
contrôles (paragraphe suivant). Toute modification effectuée sur le formulaire (choix de couleurs, police de caractères,
images, etc.) ne se fera que via les propriétés du formulaire. Il importe donc de bien parcourir lesdites propriétés pour
en retenir celles qui paraissent essentielles.
Application : (utilisation du contrôle zone de texte )

Pour relier un contrôle à un champ, procédez ainsi :
1. Cliquez dans la boı̂te à outils sur le contrôle zone de texte
2. Placez le contrôle sur le formulaire et dimensionnez-le
3. Access crée en fait DEUX contrôles : il suppose, à juste titre, que l’on va lier ce contrôle avec un champ, il crée
donc un contrôle Etiquette qu’on à vu avant qui contient le texte Texte xx (où xx est un nombre quelconque) et notre
fameux contrôle Zone de Texte qui contient la mention indépendant.
4. On va supposer ici qu’on veut lier ce contrôle au champ Nom de notre table Clients
5. On remplace Texte xx, par Nom : (histoire de savoir ce qu’il va falloir saisir dans le contrôle d’à côté)
6. Vous avez pu noter la mention indépendant, ce qui signifie que, pour l’instant, le contrôle Zone de Texte créé n’est lié
à rien, on peut taper du texte dedans mais le texte ne sera sauvé nulle part. Pour dire à Access qu’on veut sauver ce
texte dans le champ Nom de la table Clients, on clique avec le bouton droit sur le contrôle et on clique sur Propriétés :
(a) Ici se trouvent toutes les propriétés qui vont définir l’aspect et le comportement de notre contrôle, il y en a
beaucoup et je ne vais pas les détailler. Celle qui nous intéresse particulièrement et la propriété Source Contrôle
de l’onglet Données. C’est ici qu’on indique à Access d’où viennent les rems qui vont être affichées dans le
contrôle.
(b) Il y a une flèche qui descend à droite, si on clique dessus, tous les champs de la (ou des) table(s) liés au formulaire
vont s’afficher, on y choisi le champ Nom, et on ferme la fenêtre de propriétés.
7. Le contrôle n’est plus indépendant, à la place de la mention Indépendant, il est affiché Nom, c’est-à-dire le nom du
champ avec lequel il va être lié. A partir de maintenant, lors de l’affichage d’un enregistrement dans le formulaire, le
nom du client sera affiché dans ce contrôle, et toute modification de son contenu sera répercutée dans la table. Nous
pouvons le vérifier (en mode affichage).
Exercice : Complétez le formulaire Saisie Clients.

114
9.3.3 Le contrôle ”Sous-Formulaire”
Grâce à ce contrôle, nous allons pouvoir afficher des formulaires imbriqués dans d’autres, par exemple pour afficher
une liste d’enregistrement correspondant à un seul enregistrement : pour une commande donnée, on pourra, dans le même
formulaire, afficher toutes les lignes de cette commande.
Le but de la man ?uvre va être de réaliser un formulaire complexe que l’on va nommer Facture. Il contiendra toutes les rems
relatives à une commande : en en-tête le numéro de la commande, sa date, les rems sur le client, et en dessous le détail de
cette commande, avec en bas le montant total de la commande.
Pour cela, on crée le formulaire Facture. Ce formulaire va être l’en-tête de notre formulaire final : il va contenir les rems sur
la commande et sur le client qui l’a passé. On va donc aller chercher des rems dans deux tables : Clients et Commandes.
C’est ici qu’on va choisir les tables : En haut à gauche se trouvent les tables de la base, en dessous les champs de la table
choisie plus haut et à gauche les champs que nous allons utiliser dans notre formulaire.
Pour notre en-tête, nous avons besoin des rems suivantes : n˚ de la commande, n˚ du client qui a passé cette commande, la
date de la commande, ces rems provenant de la table Commande et le nom, le prénom et la ville du client qui a passé cette
commande, ces rems provenant de la table Clients.
Attention : A partir de maintenant, nous supposerons que les relations ont été bien réalisées entre les tables, c’est une
condition nécessaire au bon déroulement de la suite des opérations. Si les relations ne sont pas faites ou mal faites, Access
va tenter de relier comme il peut les tables entre elles, et c’est la source de problèmes. . .
Les relations étant correctement faites, Access, dans une crise d’intelligence remarque qu’à partir des champs choisis
précédemment, on peut faire deux choses : soit afficher les données par client, c’est à dire que, avec les champs choisis,
on peut afficher un client et en dessous afficher toutes les commandes qu’il a passées. Soit afficher les données par com-
mande, c’est à dire que pour une commande choisie, on va afficher les rems concernant le client qui a fait cette commande.
A droite s’affiche la façon dont les données seront affichées en fonction du mode qu’on aura choisi.
La deuxième proposition étant la bonne, nous la choisissons donc.
Les étapes suivantes sont classiques : choix de la disposition, de la décoration et du nom
Étape 1 terminée. Nous allons maintenant créer un nouveau formulaire, ce formulaire va être une sorte de super formulaire
ligne-commandes. Dans notre formulaire ligne commande, nous avons seulement le numéro de la commande, le numéro du
produit et la quantité.
Nous allons créer un formulaire Super ligne-commande qui va contenir sur chaque ligne : le numéro de la commande, le
numéro du produit, sa quantité (tout cela provenant de la table Lignes-commande), mais en plus le nom du produit, son
prix unitaire, son taux de TVA (tout cela provenant de la table Produits) et pour corser l’affaire, nous ajouterons le calcul du
montant TTC de la ligne, et hop !
Nous choisissons les champs numéro de commande, numéro de produit et quantité de la table Ligne-commande et les
champs libellé, prix unitaire et tva de la table Produits.
Une fois de plus, Access fait preuve d ?intelligence ! Il se rend compte qu’avec les champs que nous avons choisi, nous
pouvons afficher les données sous deux formes : soit par produit, dans ce cas il va afficher toutes les lignes de commandes
où ce produit est présent, pourquoi pas ? Mais ça ne nous intéresse pas spécialement, soit par ligne de commande, et il va
dans ce cas, afficher les rems sur le produit présent dans cette ligne de commande. Voilà qui est beaucoup plus intéressant.
Cette fois-ci, nous allons afficher le formulaire sous forme Tabulaire. Comme ce formulaire va contenir la liste des
lignes d’une commande, c’est la meilleure façon d’afficher une liste.
Dans l’en-tête se trouvent les titres des colonnes, et dans le détail, les lignes du formulaire.
Nous sommes bien d’accord, ce formulaire affiche le détail de toutes les commandes. Comme on peut le voir dans la 1ère
colonne, il concerne plusieurs commandes.
Bien, maintenant, nous allons ajouter un contrôle dans ce formulaire pour calculer le montant TTC de chaque ligne, c’est-à-
dire dans la zone détail, nous ajoutons deux contrôles :
• un contrôle Etiquette pour afficher l’en-tête de la colonne
• un contrôle Zone de Texte dans lequel on va calculer le montant TTC.
Pour calculer le montant TTC, on affiche les propriétés du contrôle et dans la propriété Source de l’onglet Données, on tape
la formule de calcul : ( [Prix Unit] + ( [Prix Unit] * [TauxTVA] / 100 ) ) * [Quantite].
Bien sûr, dans les crochets, n’utilisez que les noms effectifs utilisés pour créer vos tables.
Ca marche !
Plus fort, maintenant, nous allons afficher le montant total commandé. Nous sommes toujours d’accord, le montant total
115
va être le montant total pour toutes les commandes, notre formulaire pour l’instant ne fait pas de distinction entre les com-
mandes.
Vous avez pu remarquer que le formulaire a en plus de l’en-tête et du détail, une partie Pied de formulaire. Cette partie ne
sera affichée qu’en bas du formulaire, une fois toutes les lignes affichées. Comme précédemment, nous mettons dans cette
partie du formulaire un contrôle Zone de Texte dans lequel nous allons faire le calcul de la somme.
Que contient la formule ? La même que tout à l’heure, mais nous avons ajouté le mot-clef Somme avant :
Access va calculer la somme de toutes les lignes ici.
Et voilà le travail : en bas du formulaire apparaı̂t la somme totale.
Une fois arrivés ici, nous avons notre formulaire Facture qui contient les rems générales sur la commande et le formulaire
Super ligne commande qui contient les détails de toutes les commandes. Il serait bien de pouvoir insérer ce formulaire dans
le premier et de lui faire afficher seulement les lignes commandes correspondant à la commande choisie.
Pour cela, on va rouvrir notre formulaire Facture et poser dessus un contrôle Sous- Formulaire.
Un assistant s’affiche alors : Access nous demande à partir de quoi il va afficher ce sous-formulaire ? D’une table ou d’un for-
mulaire existant déjà ? Nous choisissons la deuxième solution et nous choisissons notre formulaire Super lignes commande.
C’est ici que tout se fait. Il va falloir indiquer à Access quel est le rapport entre le formulaire et le sous formulaire qu’il
contient. Si on se contentait d’insérer le sous formulaire tel quel dans le formulaire, il continuerait à afficher tout le temps la
totalité des lignes commandes quelle que soit la commande affichée dans le formulaire principal.
Nous voulons qu’il affiche dans le sous-formulaire les lignes commande correspondant à la commande affichée dans le for-
mulaire principal.
Quel est le rapport entre les deux ? Comment faire une relation entre les deux ? Simplement : le formulaire contient le numéro
de la commande en cours, le sous-formulaire contient pour chaque ligne de commande affichée le numéro de la commande
concernée. Il va donc falloir dire à Access que les lignes affichées dans le sous formulaire vont être celles dont le numéro de
commande est celui qui est affiché dans le formulaire.
Pour cela, on indique dans la colonne de gauche quel est le champ qui contient le numéro de commande dans le formulaire
principal et quel est le champ qui contient aussi un numéro de commande dans le sous-formulaire.
A la place du sous-formulaire, il y a un rectangle blanc. Ce qui implique que toute modification dans ce sous-formulaire ne
pourra se faire ici, il faudra la faire directement dans le formulaire Super ligne commandes. Dans Access, on peut directe-
ment modifier le sous-formulaire à partir d’ici, il n’y a plus de rectangle blanc mais directement le formulaire.
Maintenant, lorsque vous ouvrez le formulaire principal, vous avez, pour une commande donnée en haut, son contenu
exact et son montant. Vous noterez que le numéro de commande est répété pour chaque ligne, vous pouvez, comme il est
inutile maintenant puisque déjà présent dans l’en-tête, le supprimer du formulaire.
Voilà pour les sous-formulaires.
Il existe une méthode plus simple pour faire ce que nous venons de faire. Il suffit pour cela, d’abord de bien relier les tables
entre elles, ensuite lorsqu’on crée le premier formulaire de mettre toutes les champs de toutes les tables concernées dans le
même formulaire : n˚ de commande, n˚ de client, date venant de la table Commande, nom, prénom, adresse venant de la
table Client, n˚ de commande, n˚ de produit, quantité venant de la table Lignes-commande et libellé, prix unitaire et tva
venant de la table Produits.
Et là, ô magie ! Access a deviné tout seul ce que nous voulions faire (grâce aux relations quand même), et nous pro-
pose de faire tout seul ce que nous avons fait avant. Vous remarquez que l’exemple qu’il nous propose à droite ressemble
étrangement à ce que nous avons fait à la main.
Ici on nomme le formulaire, vous pouvez noter qu’il a crée tout seul le sous formulaire et qu’il en profite pour nous demander
son nom. Et voilà le travail ! En cinq secondes, il a fait ce qui nous a pris beaucoup de temps ! Il nous faudra simplement
ajouter ensuite dans le sous formulaire le calcul des montants TTC et le montant total.
Comme quoi, si les relations sont bien faites, Access fait les trois quart du boulot tout seul.
Ici se termine l’histoire des formulaires. Il reste d’autres contrôles comme les boutons bascule, les images, les objets OLE,
etc. . . Nous ne les utiliserons pas souvent.
Exercice : Essayez de reprendre ces créations de formulaires de vous-même, sans vous aider du support. . .
Table des figures
1.1 Un modèle générique pour les SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 BD du personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Résultat d’une requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Un formulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Etat de paiement mensuel par département . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Entité et occurrence d’entité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1 Représentation graphique d’une entité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Relation et occurrence de relation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Les cardinalités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Cas 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Cas 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 Modèle 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8 Modèle 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.9 Relations utiliser et Disposer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.10 Modélisation incorrecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.15 Exemple de facture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.26 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.28 Pattes dans une relation réflexive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.29 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.31 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.33 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.34 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.36 Un MCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.37 Un MLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.38 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.39 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
118
2.40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.42 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.43 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.44 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.45 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.46 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.47 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.48 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.49 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.51 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.52 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.53 MCD Médecine de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.54 MCD Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.55 MCD Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.56 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.57 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.58 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.59 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1 Voiture(NVH, Marque, Type, Puis, Couleur) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2 CodePostal(Code, Ville, Rue ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6 un LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.7 Une carte réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.11 Architecture ”Mainframe” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.12 Architecture ”Client/Serveur” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.1 Quelques employés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Table des employés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Données dans une BD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 Types de données dans une BD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5 Un MCD dans Win’Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.6 Un MCD dans Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.7 MCD à créer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Liste des tableaux

INF221 2023-2024 Physique

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

INF221 2023-2024 Physique

Transféré par

Droits d'auteur :

Formats disponibles

INF221 - Base de Données

Etienne Kouokam, PhD

Année académique 2023-2024

I Conception des Bases de Données 1

1 Introduction : Du Systèmes d’Information (SI) à la Base de Données (BD) 3

2 Démarche et méthode de modélisation des données 11

3 Théorie de la normalisation et Algèbre relationnelle 43

4 Les systèmes de gestion de bases de données 55

II Implémentation des Bases de Données 83

7 Création du schéma relationnel 87

8 Les requêtes : Concepts théoriques et pratiques 95

Table des figures 117

Liste des tableaux 119

Séance 1 : Des SI (Systèmes d’Indformation) aux Base de données

Partie 2 : Implémentation des bases de Données, par vous-mêmes.

4. Être capable de normaliser des relations dans une base de données

1. Carrez C., Des Structures aux Bases de Données, Masson

3. Gardarin G., Maı̂triser les Bases de Données : modèles et langages, Eyrolles

4. Date C.J., An Introduction to Database Systems, Addison-Wesley

5. Marcenac, P., SGBD relationnels, Optimisation des performances, Eyrolles.

Conception des Bases de Données

Introduction : Du Systèmes d’Information (SI) à la

1. Les éléments matériels

2. Les éléments intellectuels

• La compétence des employés

1.1 Quelques définitions

F IGURE 1.1 – Un modèle générique pour les SI

F IGURE 1.2 – BD du personnel

F IGURE 1.3 – Résultat d’une requête

1.2 Les composants d’une Base de Données relationnelles

F IGURE 1.4 – Un formulaire

F IGURE 1.5 – Etat de paiement mensuel par département

• Administration centralisée des données pour faciliter l’évolution de leur structure

• Base formelle reposant sur des principes parfaitement définis

1.4 Que doit-on savoir pour utiliser un SGBD ?

1. Définition du schéma de données en utilisant les modèles de données du SGBD.

2. Opérations sur les données : recherche, mises-à-jour, etc.

3. Partager les données entre plusieurs utilisateurs. (Mécanisme de transaction).

Reprenons dans l’ordre ces différents points.

• Le modèle conceptuel : la description du système d’information

• Le modèle logique : interface avec le SGBD

• Le modèle physique : fichiers.

• l’analyse du monde réel

• la conception du système d’information

• la communication entre différents acteurs de l’entreprise

nom character 15, not null;

1. La création (ou insertion).

2. La modification (ou mise-à-jour).

1.4.4 Concurrence d’accès

• Gérer les conflits si les deux font des mises-à-jour.

• Offrir un mécanisme de retour en arrière si on décide d’annuler des modifications en cours.

Le but : éviter les blocages, tout en empêchant des modifications anarchiques.

1.5 Plan du cours

Démarche et méthode de modélisation des données

2.1 Démarche de modélisation des données

2.1.1 Le groupe d’étude (angl. Project group)

2.1.2 Les étapes

1. Analyse de la situation existante et des besoins

3. A partir des modèles, implémentation d’une base de données

2.1.3 Les sources d’information

• L’interview avec les utilisateurs ;

Pour les projets d’une certaine envergure s’ajoutent :

• L’interview avec les responsables des services impliqués ;