INF221 - Base de Données

INF2211 - Conception des Bases de Données

Etienne Kouokam, PhD

[Link]@[Link]

2 octobre 2023

Année académique 2023-2024

Table des matières

Informations générales iii

I Conception des Bases de Données 1

1 Introduction : Du Systèmes d’Information (SI) à la Base de Données (BD) 3

Introduction 3
1.1 Quelques définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Les composants d’une Base de Données relationnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Objectifs et propriétés d’un SGBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Que doit-on savoir pour utiliser un SGBD ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Définition du schéma de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.2 Les opérations sur les données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.3 Optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.4 Concurrence d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Plan du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Démarche et méthode de modélisation des données 11

2.1 Démarche de modélisation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Le groupe d’étude (angl. Project group) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Les étapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3 Les sources d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Méthode de modélisation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Pourquoi modéliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3 Le modèle conceptuel des données (MCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 Avantage et inconvénients du modèle E/A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Le modèle logique de données (MLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.1 Règles de transformation du MCD au MLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Le modèle physique de données (MPD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.1 Passage du MLD au MPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.2 Les contraintes d’intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.3 Exercices-TDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 Théorie de la normalisation et Algèbre relationnelle 43

3.1 Les dépendances fonctionnelles & Normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.1 Les dépendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.2 Propriétés des dépendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.3 Théorie de la normalisation relationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 L’algèbre relationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.1 La sélection, σ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.2 La projection, π . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.3 Le produit cartésien, × . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.4 L’union, ∪ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.5 La différence, ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
ii
3.2.6 La jointure, ./ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.7 Expression de requêtes avec l’algèbre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4 Les requêtes 55
4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Introduction au langage SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.2 Syntaxe SQL de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.3 Les critères de sélection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.4 Comparaison à un filtre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.5 Les opérateurs logiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

II Implémentation des Bases de Données 63

Table des figures 65

Liste des tableaux 67

Index 67
Informations générales

Ce cours s’adresse aux étudiants de 2ème année de la filière Informatique à l’Université de Yaoundé I et a pour objectif
l’é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 schéma relationnel : Il s’agit de savoir définir un sché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’intéresse pas aux problèmes de concurrence d’accès, dont la connaissance est nécessaire aux
développeurs d’applications basées sur des SGBD. Des travaux pratiques avec le SGBD MS Access permettent de mettre en
oeuvre les techniques étudiées en cours. Cela se fera dans le cadre de l’ECI INF2212.

L’accent est donc plutôt mis sur les notions de base (ce qu’est un SGBD, une base de données, un langage d’interroga-
tion) et leur application pratique. Il est demandé d’avoir acquis à la fin du cours les connaissances nécessaires à l’utilisation
d’un SGBD par un informaticien non-spécialiste. : création d’un schéma, insertion, mise à jour, destruction, et interroga-
tion de données dans la gestion d’un SGBD. En revanche, tout ce qui relève de la compréhension des mécanismes internes
d’un SGBD (représentation physique, évaluation de requêtes) ou des fondements théoriques du modèle relationnel n’est pas
abordé ici.

Ce document est un support de cours : il ne prétend certainement pas être exhaustif ni traiter en détail tous les sujets abordés.
L’assistance au cours proprement dit, ainsi qu’aux travaux dirigés et aux travaux pratiques est fortement recommandée.

La structure et le contenu des chapitres de ce document ont été synchronisés avec le contenu du programme établi par
le département d’INformatique de l’Université de Yaoundé I.

Pour ceux qui veulent en savoir plus, il existe une riche bibliographie dont voici quelques éléments recommandables :

Nous aurons une demi-douzaine de séances de cours ainsi réparties (à titre indicatif) :

Partie 1 : Modélisation d’un système d’information : Analyse et Structuration des données (chapitres 1 à 4)

Séance 1 : Des SI (Systèmes d’Indformation) aux Base de données

Séance 2 : Les objectifs des Bases de Données
Séance 3 : Méthodologie de conception des Bases de Données
Séance 4 : Algèbre relationnelle et Normalisation
Séance 5 : Interrogation des Bases de Données
Séance 6 : Conclusion

Partie 2 : Implémentation des bases de Données (ECI INF2212)

iv
Compétences visées
1. Etre capable de concevoir soi-même un modèle conceptuel à partir d’un énoncé

2. Être capable de passer d’un modèle à un autre (du schéma conceptuel au schéma relationnel ou du modèle logique au
modèle physique) ou vice versa

3. Etre capable de critiquer sérieusement un modèle proposé dans le cadre de l’informatisation d’un Système d’Informa-
tion

4. Être capable de normaliser des relations dans une base de données

5. Etre capable d’écrire des requêtes SQL, QBE et même pouvoir en dériver le calcul relationnel en s’aidant des opérations
vues en algèbre relationnelle.

Ouvrages :

1. Carrez C., Des Structures aux Bases de Donné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 Données : modè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.
 Première partie

Conception des Bases de Données

Chapitre 1

Introduction : Du Systèmes d’Information (SI) à la

Base de Données (BD)

La compétitivité d’une entreprise ainsi que sa valeur sur le marché sont déterminées par plusieurs éléments, d’une
importance différente selon le secteur d’activité. On peut généralement regrouper ces éléments en deux classes :

1. Les éléments matériels

• L’infrastructure
• Les supports financiers

2. Les éléments intellectuels

• La compétence des employés

• La motivation des employés
• Le recueil et l’exploitation optimale des informations utiles

Depuis quelques anné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 compétitivité à ne pas négliger.
Le développement rapide de l’informatique a donné aux entreprises la possibilité d’utiliser des moyens avancés et puis-
sants pour gérer et exploiter de très grands volumes de données. Il y a quelques années, le domaine de la gestion informatique
des données était réservé aux informaticiens. Actuellement, les tendances à l’intérieur des entreprises ont changé de façon
à ce que tous les employés soient de plus en plus impliqués dans les différents procédés liés à la gestion et l’exploitation
des données. De cette faç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 sophistiquées pour exploiter au mieux les
données. En parallèle avec les outils informatiques utiles pour gérer des données, tels que les ordinateurs de plus en plus
puissants et les logiciels adaptés (SGBD, Tableur etc.), ont été développées des méthodes d’analyse et de conception de
systèmes d’information. Ces méthodes nous offrent la possibilité d’analyser un systè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 modèle
qui représente ce système et d’implémenter finalement un système informatique, basé sur ce modèle.

1.1 Quelques définitions

Définition 1. Une information ou donnée est un élément qui permet de compléter notre connaissance sur une personne, un
objet, un événement. Elle est donc quelconque. C’est aussi une relation entre des informations : Des relations de ce genre
dé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 données.
Des relations de ce genre définissent des structures.
4

F IGURE 1.1 – Un modèle générique pour les SI

Définition 2. Le système d’information regroupe l’ensemble des ressources permettant de gérer (saisir, stocker, traiter,
restituer, transmettre) toutes les informations utiles aux décideurs et aux opérationnels.
Exemple 2.
Toutes les informations relatives à la gestion d’une librairie constituent le système d’information de cette librairie. Ce système
peut couvrir le simple stockage des livres, mais également la gestion des commandes, des ventes et même des clients.

Un système d’information ne doit pas nécessairement être informatisé. Bien que la plupart des systèmes actuels se basent
sur la technologie de l’informatique, il existe encore des systèmes d’information où l’information est stockée, manipulée et
communiquée à l’aide de moyens ”traditionnels” tels que les armoires, les classeurs, les calculatrices, les fiches sur papier
...
Le système d’information ne doit pas être confondu avec le système informatique qui lui, est constitué d’éléments
matériels et/ou logiciels (ordinateurs, programmes, structures de données, . . . )
Bien que les deux termes ”informations” et ”données” soient souvent utilisés comme synonymes, il existe une différence
subtile entre eux.
Exemple 3.
Dans une librairie, un client demande au vendeur si le livre ”L’étranger” (Albert Camus) est disponible en stock. Le vendeur
conseille la base de données de la librairie à l’aide de son ordinateur et confirme au client que le livre est disponible. Le
vendeur a donc donné au client l’information que le livre est en stock. Afin de pouvoir donner cette information, le vendeur
a du consulter les données qui représentent le stock de la librairie. Le fait de consulter le stock constitue un traitement sur
les données du stock.
L’image de la Figure 1.1 en est un modèle générique.

On peut donc dire qu’un système d’information contient les données et les traitements nécessaires pour assimiler et
stocker les informations en entrée et produire les informations en sortie.
Exemple 4.
Le propriétaire d’une vidéothèque reçoit une livraison avec des nouvelles cassettes vidéo. Pour chaque cassette vidéo, il lit
le titre, la langue et la durée et sauvegarde ces informations dans la base de données de la vidéothèque. Il a donc utilisé un
traitement d’ajout de données afin de transformer les informations en entrée (titre, langue, durée) en données.

Les données d’un système d’information peuvent être stockées et manipulées à l’aide d’un outil informatique spécialisé
dans ce domaine. Actuellement les Systèmes de Gestion de Bases de Données (SGBD) constituent le type de logiciel le
mieux adapté pour implémenter la plupart des systèmes d’information.
C’est donc un ensemble, en général volumineux, de telles informations, avec une caractéristique essentielle : on souhaite les
mémoriser de manière permanente. D’où la définition :
Définition 3. Une Base de Données (BD) peut être considérée comme un ensemble structuré de données, centralisé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, structurées et persistantes, concer-
nant un sujet.

Définition 4. La gestion ici est considérée comme l’action ou la manière de gérer, d’administrer, de diriger, d’organiser
quelque chose (une entreprise ou organisation dans notre cas)
Définition 5. Un Système de Gestion de Base de Données (SGBD) peut être défini comme un ensemble de logiciels prenant
en charge la structuration, le stockage, la mise à jour et la maintenance des données. Autrement dit, il permet de créer,
décrire, modifier, interroger et administrer les données. C’est, en fait, l’interface entre la base de données et les utilisateurs
(qui ne sont pas forcément informaticiens).
Exemple 5.
MS Access, Oracle, MySQL, SQL server, Postgre SQL . . .
 5

F IGURE 1.2 – BD du personnel

F IGURE 1.3 – Résultat d’une requête

1.2 Les composants d’une Base de Données relationnelles

Une base de données relationnelle contient en général quatre types de composants (ou d’objets). Nous allons brièvement
introduire ces types d’objets sans aller trop dans les détails. A chacun de ces objets sera consacré un chapitre séparé.
a. Les tables dans lesquelles sont stockées les données. Une table peut être comparée à une liste, qui contient des enregis-
trements relatifs à un domaine bien défini.
Exemple 6.
Le service du personnel de l’entreprise SCHAFFGAER SARl. entretient une BD avec en outre une table pour les
données des employées. Cette table contient un enregistrement pour chaque employé, avec le nom, le prénom, l’adresse,
la localité, la date de naissance, la date d’entrée en service, le salaire mensuel et le nom du département auquel l’em-
ployé est actuellement affecté. Voire Figure 1.2

b. Les requêtes qui correspondent dans un certain sens aux ”questions” qu’on pose au SGBD. Le résultat à une requête
correspond bien souvent à un sous-ensemble d’une ou de plusieurs tables.
Exemple 7.
Le chef du personnel de l’entreprise SCHAFFGAER SARL. désire connaı̂tre les noms, prénoms, adresses et localités
des employés recrutés en 1996. Il doit formuler une requête qui sera exécutée par le SGBD, et qui donnera comme
résultat une liste semblable à la table des employés, mais contenant uniquement les employés qui vérifient le critère
de sélection de la requête, et pour chacun de ces employés seulement les informations demandées. Voire Figure 1.3

c. Les formulaires sont utilisés pour ajouter, modifier ou supprimer des données dans les tables. Bien que la plupart des
SGBD nous permettent d’accéder aux données directement dans les tables, les formulaires nous offrent certains avan-
tages en ce qui concerne la facilité d’utilisation, mais également la sécurité des données.
Exemple 8.
La secrétaire du chef du personnel utilise un formulaire pour ajouter ou supprimer un employé de la BD. Ce formulaire
lui permet également de modifier les données d’un employé. Voire Figure 1.4

d. Il arrive souvent qu’on veuille imprimer des statistiques concernant certaines données d’une BD. C’est alors qu’inter-
viennent les rapports ou états. Les rapports sont similaires aux formulaires, à la différence près, qu’ils sont uniquement
destinés à être imprimés et qu’il n’y a pas de dialogue interactif avec l’utilisateur. Un rapport se base généralement sur
une ou plusieurs tables ou bien le résultat d’une requête.
Exemple 9.
A la fin de chaque mois le chef du personnel reçoit un rapport avec pour chaque département, la liste des employés,
leur salaire mensuel ainsi que le salaire mensuel total payé par département. Voire Figure 1.5
6

F IGURE 1.4 – Un formulaire

F IGURE 1.5 – Etat de paiement mensuel par département

 7
1.3 Objectifs et propriétés d’un SGBD
Un SGBD doit résoudre certains problèmes et répondre à des besoins précis :

• Indépendance physique : la façon de définir les données doit être indépendante des structures utilisées pour leur
stockage

• Indépendance logique : un utilisateur doit pouvoir percevoir seulement la partie des données qui l’intéresse (c’est ce
que l’on appelle une vue) et modifier la structure de celle-ci sans remettre en cause la majorité des applications

• Manipulation aisée des données par des non informaticiens, ce qui suppose des langages ”naturels”

• Accès efficaces aux données et obtention de résultats aux interrogations en un temps ”acceptable”

• Administration centralisée des données pour faciliter l’évolution de leur structure

• Non-redondance : chaque donnée ne doit être présente qu’une seule fois dans la base afin d’éviter les problèmes lors
des mises à jour

• Cohérence (ou intégrité) : les données ne doivent présenter ni ambiguı̈té, ni incohérence, pour pouvoir délivrer sans
erreur les informations désirées. Cela suppose un mécanisme de vérification lors de l’insertion, de la modification ou
de la suppression de données

• Partage des données pour un accès multi-utilisateur simultané aux mêmes données. Il faut entre autre assurer un
résultat d’interrogation cohérent pour un utilisateur consultant une base pendant qu’un autre la modifie

• Sécurité des données : robustesse vis-à-vis des pannes (il faut pouvoir retrouver une base ”saine” encas de plantage au
cours de modifications) et protection par des droits contre les accès non autorisés

Des objectifs cités ci-dessus découlent les propriétés fondamentales d’un SGBDr :

• Base formelle reposant sur des principes parfaitement définis

• Organisation structurée des données dans des tables interconnectées (d’où le qualificatif relationnelles), pour pouvoir
détecter les dépendances et redondances des informations

• Implémentation d’un langage relationnel ensembliste permettant à l’utilisateur de décrire aisément les interrogations
et manipulation qu’il souhaite effectuer sur les données

• Indépendance des données vis-à-vis des programmes applicatifs (dissociation entre la partie ”stockage de données” et
la partie ”gestion” - ou ”manipulation”)

• Gestion des opérations concurrentes pour permettre un accès multi-utilisateur sans conflit

• Gestion de l’intégrité des données, de leur protection contre les pannes et les accè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 fonctionnalités suivantes :

1. Définition du schéma de données en utilisant les modèles de données du SGBD.

2. Opérations sur les données : recherche, mises-à-jour, etc.

3. Partager les données entre plusieurs utilisateurs. (Mécanisme de transaction).

4. Optimiser les performances, par le réglage de l’organisation physique des données. Cet aspect relève plutôt de l’admi-
nistration et ne sera évoqué que dans l’introduction.

Reprenons dans l’ordre ces différents points.

8
1.4.1 Définition du schéma de données
Un schéma est simplement la description des données contenues dans la base. Cette description est conforme à un modèle
de données qui propose des outils de description (structures, contraintes et opérations). En fait, dans un SGBD, il existe plu-
sieurs modèles plus ou moins abstraits des mêmes objets, Exemple 10.

• Le modèle conceptuel : la description du système d’information

• Le modèle logique : interface avec le SGBD

• Le modèle physique : fichiers.

Ces différents modèles correspondent aux niveaux dans l’architecture d’un SGBD. Prenons l’exemple du modèle concep-
tuel le plus courant : le modèle Entité/Association. C’est essentiellement une description très abstraite qui présente les avan-
tages suivants :

• l’analyse du monde réel

• la conception du système d’information

• la communication entre différents acteurs de l’entreprise

En revanche, il ne propose pas d’opérations. Or définir des structures sans disposer d’opérations pour agir sur les données
stockées dans ces structures ne présente pas d’intérêt pratique pour un SGBD. D’où, à un niveau inférieur, des modèles
dits ?logiques ? qui proposent :

1. Un langage de définition de données (LDD) pour décrire la structure, incluant des contraintes.

2. Un langage de manipulation de données (LMD) pour appliquer des opérations aux données.

Ces langages sont abstraits : le LDD est indépendant de la représentation physique des données, et le LMD est indépendant
de l’implantation des opérations. On peut citer une troisième caractéristique : oute les structures et les opérations, un modèle
logique doit permettre d’exprimer des contraintes d’intégrité sur les données.
Exemple 11.

nom character 15, not null;

âge integer between 0 and 120;
débit = crédit;
...

Bien entendu, le SGBD doit être capable de garantir le respect de ces contraintes. Quand on conçoit une application
pour une BD, on tient compte (plus ou moins consciemment) de cette architecture en plusieurs niveaux. Typiquement : (1)
On décide la structure logique, (2) on décide la structure physique, (3) on écrit les programmes d’application en utilisant la
structure logique, enfin (4) Le SGBD se charge de transcrire les commandes du LMD en instructions appropriées appliquées
à la représentation physique.

Cette aproche offre de très grands avantages qu’il est important de souligner. Tout d’abord elle ouvre l’utilisation des SGBD
à de utilisateurs non-experts : les langages proposés par les modèles logiques sont plus simples, et donc plus accessibles,
que les outils de gestion de fichiers. Ensuite, on obtient une caractéristique essentielle : l’indépendance physique. On peut
modifier l’implantation physique sans modifier les programmes d’application. Un concept voisin est celui d’indépendance
logique : on peut modifier les programmes d’application sans toucher à l’implantation.
Enfin le SGBD décharge l’utilisateur, et en grande partie l’administrateur, de la lourde tâche de contrôler la sécurité et
l’intégrité des données.
 9
1.4.2 Les opérations sur les données
Il existe 4 opérations classiques (ou requêtes) :

1. La création (ou insertion).

2. La modification (ou mise-à-jour).

3. La destruction.

4. La recherche.

Ces opérations correspondent à des commandes du LMD. La plus complexe est la recherche en raison de la variété des
critères.

Pour l’utilisateur, une bonne requête a les caractéristiques suivantes. Tout d’abord elle s’exprime facilement : l’idéal serait
de pouvoir utiliser le langage naturel, mais celui-ci présente trop d’ambiguités. Ensuite le langage ne devrait pas demander
d’expertise technique (syntaxe compliquée, structures de données, implantation particulière ...). Il est également souhaitable
de ne pas attendre trop longtemps (à charge pour le SGBD de fournir des performances acceptables). Enfin , et peut-être
surtout, la réponse doit être fiable.

Une bonne partie du travail sur les SGBD consiste à satisfaire ces besoins. Le résultat est ce que l’on appelle un langage de
requêtes, et constitue à la fois un sujet majeur d’étude et une caractéristique essentielle de chaque SGBD. Le langage le plus
répandu à l’heure actuelle est SQL.

1.4.3 Optimisation
L’optimisation (d’une requête) s’appuie sur l’organisation physique des données. Les principaux types d’organisation
sont les fichiers séquentiels, les index (denses. secondaires, arbres B) et le regroupement des données par hachage.

Un module particulier du SGBD, l’optimiseur, tient compte de cette organisation et des caractéristiques de la requête pour
choisir le meilleur séquencement des opérations.

1.4.4 Concurrence d’accès

Plusieurs utilisateurs doivent pouvoir accéder en même temps aux mêmes données. Le SGBD doit savoir :

• Gérer les conflits si les deux font des mises-à-jour.

• Offrir un mécanisme de retour en arrière si on décide d’annuler des modifications en cours.

• Donner une image cohérente des données si l’un fait des requêtes et l’autre des mises-à-jour.

Le but : éviter les blocages, tout en empêchant des modifications anarchiques.

1.5 Plan du cours

Le cours comprend trois parties consacrées successivement à la conception d’une base de données relationnelles, aux
langages de requêtes relationnels, enfin à la pratique d’un SGBD relationnel.

1. La première partie présente dans ses grandes lignes les principes fondamentaux du modèle relationnel c’est-à-dire l’ana-
lyse et la structure des données en focalisant sur la construction du modèle de données, et en détaillant comment le
modèle entité-association permet d’obtenir un premier schéma relationnel et comment ce dernier est normalisé pour
obtenir une base cohérente.

2. La deuxième partie s’intéresse aux langages de requêtes relationnels. Ici, les langages d’interrogation et de manipulation
de données suivants sont présentés : l’algèbre relationnelle qui fournit un petit ensemble d’opérateurs permettant
d’exprimer des requêtes complexes et le langage SQL, norme SQL2.
Chapitre 2

Démarche et méthode de modélisation des données

2.1 Démarche de modélisation des données

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

Un système d’information qui n’est pas trop complexe et volumineux en terme d’informations, peut facilement être in-
formatisé par une seule personne, qui ne doit pas nécessairement être un informaticien. Il suffit d’être un peu familiarisé avec
une méthode de modélisation, et de savoir manipuler un SGBD pour réaliser une implémentation informatique, cohérente et
fonctionnelle, d’un tel système d’information.
Dès que le système d’information atteint une certaine envergure (exemple : informatiser la gestion des sinistres d’une
compagnie d’assurances), un groupe d’étude est généralement créé.
Ce groupe ne devra en aucun cas contenir seulement des informaticiens mais également :

• Un ou plusieurs représentants des futurs utilisateurs du système informatisé (Par exemple : Un employé du service qui
gère les sinistres) ;

• Un ou plusieurs représentants de chaque département impliqué (exemple : Un employé du service des contrats ) ;

• Un représentant de la direction.

Généralement, un responsable du groupe (Project Manager) est nommé, afin de coordonner les travaux effectués par le
groupe et de suivre le déroulement à partir de l’analyse jusqu’à la mise en place du système informatisé.

2.1.2 Les étapes

Chaque projet d’informatisation, qu’il soit exécuté par une seule personne, ou géré par un groupe d’étude, prévoit plu-
sieurs étapes.
En général, nous avons les étapes suivantes :

1. Analyse de la situation existante et des besoins

12

2. Création d’une série de modèles qui permettent de représenter tous les aspects importants

3. A partir des modèles, implémentation d’une base de données

2.1.3 Les sources d’information

La première étape de chaque projet est donc l’analyse de l’existant et des besoins. Afin de pouvoir ré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’étude de documents provenant du systè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 impliqués ;

• Pourvu que la tâche d’analyse soit partagée entre plusieurs membres du groupe d’études, il faut coordonner les actions
et comparer les résultats avec les autres membres.

Pour les projets qui se basent sur un système déjà partiellement informatisé s’ajoute :

• L’étude de l’application informatique existante.

2.2 Méthode de modélisation des données

Nous avons vu que la démarche classique d’un projet informatique comprend les étapes suivantes :

1. Analyse de la situation existante et des besoins ;

2. Création d’une série de modèles, qui permettent de représenter tous les aspects importants ;

3. A partir des modèles, implémentation d’une base de données.

En ce qui concerne la première étape, nous n’allons pas introduire de vraies règles, mais simplement utiliser nos connais-
sances de gestion d’une entreprise, notre esprit ouvert et même notre fantaisie pour analyser correctement la situation exis-
tante et les besoins des utilisateurs. Le résultat de l’analyse est généralement un ou plusieurs documents, qui contiennent les
indications principales sur le fonctionnement désiré du système informatisé. Le document d’analyse contient souvent déjà
des prototypes de certains documents importants, que le futur système devra être capable de produire.
Une fois que l’analyse est terminée, il s’agit d’élaborer une série de modèles, basés sur le document d’analyse. Ces
modèles nous permettront plus tard d’implémenter une base de données, qui contiendra toutes les informations nécessaires
au bon fonctionnement du système informatisé.
La création de ces modèles se fait selon une certaine méthode. Nous allons baser notre cours sur la méthode MERISE
(Méthode d’Etude et de Réalisation Informatique de Systèmes d’Entreprise), qui a été développée pendant les années ’70.
Merise est aujourd’hui largement répandue dans les pays d’Afrique et d’Europe francophone pour l’essentiel.
MERISE prévoit une conception par niveaux, et définit pour cela 3 niveaux essentiels :

1. Le niveau conceptuel, qui se base directement sur l’analyse, décrit l’ensemble des données du système d’information,
sans tenir compte de l’implémentation informatique de ces données. Ce niveau, qui représente donc la signification
des données, se traduit par un formalisme que nous appelons Modèle conceptuel des données (MCD)

2. Le niveau logique, qui se base sur le modèle conceptuel des données, prend en considération l’implémentation du
systè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 représenté par le Modèle logique des données (MLD)

3. Le niveau physique, qui se base sur le modèle logique des données, contient finalement les tables définies à l’aide
d ?un SGBD spécifique ([Link]. MS Access, dBASE, Oracle . . . ). Ce niveau est représenté par le Modèle physique des
données (MPD)

Voici donc les 4 étapes nécessaires pour traduire un système d’information naturel en une base de données :
14

2.2.1 Pourquoi modéliser

Nous avons vu qu’une base de données est constituée par un ensemble de tables qui contiennent toutes les données de
la base. Une méthode de modélisation nous permet de trouver le bon nombre de tables pour une base de données et de
déterminer quelles données sont représentées à l’intérieur de quelle table.
Pour l’instant, il nous suffit de savoir qu’une table est un ensemble d’enregistrements, dont chacun est composé par les
mêmes champs de données. On pourrait comparer une table à une liste en MS-Excel1.
Exemple 12.
NoEmp bf Nom Emp bf Prénom Emp bf NoEntr bf Nom Entr bf Localité
102 Belibi Emile 1 Tatiss SARL Yaoundé
103 Ntong Francis 1 INC Yaoundé
104 Kenmegne Jovin 2 MINEDUB Douala Nous voyons ici uniquement
105 Adamou Hamza 1 Tatiss SARL Yaoundé
106 Kuissi Aimée 2 MINJUSTICE Douala
... ... ... ... ... ...
quelques enregistrements. Une caisse de maladie ayant des milliers de membres, et cette table possédant un enregistrement
par membre, on peut bien s’imaginer la taille ré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
problèmes.

2.2.2 Exercices

Exercice 1.
Essayez de trouver en discussion quelques problèmes qui peuvent se manifester lors du travail journalier avec cette table.
Exercice 2.
Comment est-ce qu’on pourrait éviter ces problèmes sans toutefois perdre des informations ?

2.2.3 Le modèle conceptuel des données (MCD)

En se basant sur un document d’analyse, le modèle conceptuel des données (MCD) fait référence à tous les objets du
système d’information et à des relations entre ces objets. Le formalisme utilisé dans ce modèle est encore connu sous le
nom de ”Schéma Entité-Relation”. Ce formalisme se base autour de 3 concepts principaux, les entités, les relations et les
propriétés.
Voici par exemple un MCD qui représente une entreprise avec ses employés.
 15

(a) Entité (b) Occurrence d’entité

F IGURE 2.2 – Entité et occurrence d’entité.

Nous allons par la suite détailler le rôle de ces 3 concepts de base du MCD.

Notion d’entité
Une entité permet de modéliser un ensemble d’objets concrets ou abstraits de même nature.
Une entité est caractérisée par son nom et ses propriétés
Dans l’exemple du chapitre précédent , l’entité Employé spécifie donc l’ensemble des em-
ployés, qui nous intéressent dans le contexte de notre système d’information. Il en sera de
même pour l’entité Entreprise qui représente toutes les entreprises de notre système d’infor-
mation. de la sorte, la figure présente un exemple d’entité tandis que la figure correspond à
trois occurrences d’une telle entité

Notion de propriété F IGURE 2.1 – Représentation

graphique d’une entité
Une propriété est une donnée élémentaire d’une entité.
Une propriété est unique dans un MCD ; et ne peut pas être rattachée à plusieurs entités différentes.
Pour sa représentation graphique, le nom de la propriété est indiqué à l’intérieur du rectangle qui représente l’entité
correspondante.
Exemple 13.
Pour une entité Client :

• Nom du client

• [Link]́l. du client

A l’intérieur de chaque occurrence, chaque propriété prend une valeur, qui est dans la plupart des cas une valeur
numérique, une valeur sous forme de texte ou encore une date. . .
Exemple 14.
L’entité Client est définie par les propriétés vues à la figure 2.2
16
La propriété Nom prend les valeurs ”Meier”, ”Muller” et ”Weber” dans les 3 occurrences présentées.
A l’intérieur de chaque occurrence, chaque propriété 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 différentes occurrences d’une même entité, l’entité doit être dotée d’un identifiant. L’identi-
fiant est composé d’une ou de plusieurs propriétés de l’entité. Chaque occurrence d’une entité doit avoir une valeur différente
pour l’identifiant. Le choix d’un identifiant correct est très important pour la modélisation :
Comme choix pour l’identifiant d’une entité nous distinguons généralement 3 possibilités :

1. Une propriété naturelle Exemple 15.

Le nom d’un pays pour une entité Pays

2. Une propriété artificielle qui est inventée par le créateur du MCD Exemple 16.
Le numéro d’un client pour une entité Client

3. Une propriété composée d’autres propriétés naturelles Exemple 17.

Le nom et la localité pour une entité Entreprise

On représente graphiquement l’identifiant d’une entité en soulignant toutes les propriétés qui le constituent.
Exercice 3.
Indiquez graphiquement les entités qui représentent :

1. les passagers d’un vol d’une société aérienne. Nous supposons que la société garde ces informations après le vol ;

2. les résultats sportifs de l’entrainement d’un coureur ;

3. les médicaments d’une pharmacie.

Notion de relation
Définition Une relation 1 décrit un lien entre deux ou plusieurs entités.
Chaque relation possède un nom, généralement un verbe à l’infinitif. Bien qu’une relation n’ait pas d’identifiant propre,
elle est implicitement identifiée par les identifiants des entités auxquelles elle est liée.
Le nombre d’entités reliant une relation détermine le type de la relation. En général on parle de relation n-aire lorsque n
entités sont reliées par la même relation. On verra bien souvent :

• les relations binaires, qui sont liées à 2 entités ;

• les relations ternaires, qui sont liées à 3 entités.

Exemple 18.
L’occurrence d’une relation est représentée par les occurrences des entités liées à la relation. La figure 2.3 est une illustration
de ce qu’est une relation binaire. En outre, elle présente quelques occurrences de la relation Ecrire.
Pour chaque occurrence d’une relation, l’identifiant composé des identifiants des entités liées à la relation doit être unique.

Cardinalités d’une relation Une relation est liée à chacune de ses entités par une patte. Sur la patte, on indique les
cardinalités, lesquelles précisent la participation de l’entité concernée à la relation. Une cardinalité est un couple de nombres
entiers naturels dont le premier indique la cardinalité minimale, le deuxième la cardinalité maximale.
La figure 2.4 présente un exemple et illustre la sémantique associée aux différentes pattes. Dans le MCD de la Figure
figure 2.4,

Entre l’entité Client et la relation Passer, nous avons les cardinalités suivantes :

• Cardinalité minimale = 1 , ce qui veut dire que chaque client passe au moins une commande.
• Cardinalité maximale = n , ce qui veut dire que chaque client peut passer plusieurs (n) commandes.

Entre l’entité Commande et la relation Passer, nous retrouvons les cardinalité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 cardinalités (b) Exemple 1

F IGURE 2.4 – Les cardinalités.

• Cardinalité minimale = 1 , donc chaque commande est passée par au moins un client.
• Cardinalité maximale =1 , chaque commande est passée au maximum par un seul client.

De façon générale, on peut dire que :

1. La cardinalité minimale exprime le nombre minimum de fois q’une occurrence d’une entité participe à une relation.
Cette cardinalité est généralement 0 ou 1.

• Cardinalité minimale = 0 : Certaines occurrences de l’entité ne participent pas à la relation

• Cardinalité minimale = 1 : Chaque occurrence de l’entité participe au moins une fois à la relation

2. La cardinalité maximale exprime le nombre maximum de fois q’une occurrence d’une entité participe à une relation.
Cette cardinalité vaut souvent 1 ou n, avec n indiquant une valeur ¿1 mais pas connue à priori.

• Cardinalité maximale = 1 : Chaque occurrence de l’entité participe au maximum une seule fois à la relation.
• Cardinalité maximale = n : Chaque occurrence de l’entité peut participer plusieurs fois à la relation.

En pratique, afin de déterminer les bonnes cardinalités, le concepteur doit se référer aux résultats de l’analyse.

Exemple 19.
Pour les deux cas suivants, on peut affirmer qu’une commande est toujours passée par au moins un client. Une commande
est également passée au maximum par un client. Une commande est donc toujours passé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 modélisation ne tient pas compte des clients

qui ne passent aucune commande. Un client est unique-
ment considéré 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 modélisation tient compte des clients qui ne passent au-

cune commande.

On peut se poser la question de savoir laquelle de ces

modélisations est correcte. Bien entendu, toutes les deux
modélisations sont correctes. Le choix dépend uniquement du
résultat de l’analyse. Imaginez que vous avez fait pendant l’ana-
lyse une interview avec un futur utilisateur du système. Il vous
a dit qu’il veut enregistrer dans son système des clients poten-
tiels, c.à.d. des personnes dont la compagnie dispose des données
F IGURE 2.6 – Cas 2 personnelles, mais qui n’ont encore jamais passé de commande
auprès de la compagnie. La compagnie désire enregistrer les
données de ces personnes afin de leur envoyer de temps en temps
des publicités. Dans ce cas vous devez opter pour la deuxième
modélisation.

Exercice 4.
Interprétez ls modélisations de la figure 2.9 Dans le modèle 2 de la figure 2.9, on dit que Client est l’entité indépendante

F IGURE 2.7 – Modèle 1

F IGURE 2.8 – Modèle 2

F IGURE 2.9 – Relations utiliser et Disposer

par rapport à la relation disposer (cardinalité minimale = 0) , tandis que Carte membre est l’entité dépendante par rapport à
la relation disposer (cardinalité minimale = 1). Une occurrence d’un client peut donc très bien exister sans carte de membre,
mais une carte de membre ne peut jamais exister sans client.
In fine, la cardinalité minimale nous indique donc si une entité est indépendante ou dépendante.

On en tire deux remarques importantes :

• On dit qu’une entité est indépendante par rapport à une relation lorsque sa cardinalité minimale vaut 0, et dépendante
par rapport à une relation lorsque sa cardinalité minimale vaut 1.

• Une relation ne peut pas être liée uniquement à des entités dépendantes ayant en plus une cardinalité maximale de 1
La modélisation de la figure 2.10 par exemple n’est pas correcte :
Dans un tel cas, il faut réunir les propriétés des deux entités dans une seule.

Propriétés d’une relation Généralement, une relation peut être dotée de propriétés.
Exemple 20.

F IGURE 2.10 – Modélisation incorrecte F IGURE 2.11

Exercice 5.
Pourquoi est-ce qu’on ne peut pas associer la propriété Année à une des entités de la figure 2.11
 19
Cette propriété peut même devenir une partie de l’identifiant. Dans ce cas, elle doit être soulignée.
Exemple 21.
Comme un professeur peut avoir la même classe pendant plusieurs années, un identifiant composé de No Matricule et

F IGURE 2.12

Code Classe n’est pas suffisant, puisqu’il ne garantit pas l’unicité. On y ajoute l’Année (Cf. Figure 2.12).
Une relation à cardinalité (1,1) n’est jamais porteuse de propriétés. Dans ce cas, les propriétés migrent dans l’entité
portant cette cardinalité (1,1).
Exemple 22.
La modélisation de la Figure 2.13 n’est pas correcte ! Chaque facture ne possède qu’une et une seule date d’émission, ce qui

F IGURE 2.13

fait que la propriété Date émission doit migrer dans l’entité Facture.
La modélisation correcte est donnée à la figure 2.14 :

F IGURE 2.14

Exercice-Exemple 1 : ”KaafKaaf”
Partie 1 : La société ”KaafKaaf” désire informatiser son système de facturation. Un exemple de facture est présenté à la
figure 2.15.
Créez un MCD, qui permet de modéliser correctement le système d’information nécessaire, sachant que :

• Un client peut bien sûr recevoir plusieurs factures, mais il est uniquement considéré comme tel à partir du
moment où il reçoit sa première facture.
• Une facture concerne un et un seul client.

Remarque :
Bien que le numéro du client n’apparaisse pas en tant que tel sur la facture, il est préférable d’ajouter cette propriété
artificielle à l’entité Client, et de la définir comme identifiant de cette entité. Cela nous empêche de devoir définir un
identifiant composé de trop de propriétés.

Partie 2 : Il s’agit maintenant d’étendre le MCD obtenu précédemment.

Le responsable de la facturation de la société désire rendre les factures plus informatives. Comme un client peut acheter
plusieurs articles différents en même temps, la facture devrait indiquer pour chaque article le numéro , un libellé, le
prix unitaire, la quantité vendue et le prix total pour ce type d’article.
La figure 2.17 correspond à l’aspect que la facture devrait avoir :
Proposez un nouveau MCD qui reflète ces modifications, en sachant que :

• Tous les articles disponibles sont stockés ([Link]. No=234 Libellé=”Marteau” PU=470 FCFA.). Même si un article
n’est pas encore considéré par une facture, il existe dans le système d’information.
20

F IGURE 2.15 – Exemple de facture

F IGURE 2.16

Ce nouveau MCD est donné à la figure 2.18

Remarques :

• L’entité Facture ne contient plus la propriété Montant. Il existe une règle générale de conception qui dit : ”Aucune
propriété qui peut être calculée à partir d’autres propriétés existantes, ne devra être stockée dans le MCD.”
Pour la même raison, on n’a pas besoin de modéliser explicitement le prix à payer pour l’achat d’une quantité
d’articles donnés. Le prix pour chaque article figurant sur la facture peut être calculé à partir du prix unitaire et
de la quantité
• Nous retrouvons ici le cas d’une relation qui a une propriété. En fait, la propriété Quantité n’est pas spécifique
à un article, mais à l’achat de cet article à l’aide d’une facture. Cette façon de modéliser la situation est la plus
facile, mais il existe une alternative. On peut introduire l’entité abstraite Ligne de facture, qui représente une
ligne de détail d’une facture, [Link] celle pour le marteau. (Cf. Figure 2.19)

Exercice-Exemple 2 : La gestion d’une école

Partie 1 : Dans une école, on veut informatiser le système d’information qui gère les classes.
Elaborez un MCD sachant que :

• Un élève est caractérisé par son no. matricule, son nom et prénom, ainsi que sa date de naissance.
• Une classe est caractérisée par le nom de la classe ([Link] 13CG2) et par une indication du cycle (valeurs possibles :
”inférieur”, ”moyen”, ”supérieur”).
• Il faudra prévoir de connaı̂tre la fréquentation des classes des élèves sur plusieurs années consécutives.
 21

F IGURE 2.17

F IGURE 2.18

• Un élève enregistré dans le système fréquente au moins une classe au cours des années.

Partie 1 : Il s’agit maintenant de concevoir une extension au MCD précédent qui permet de représenter la situation suivante :

• La direction de l’école désire également saisir tous les professeurs dans le système d’information. Un professeur
est caractérisé par un code interne unique ([Link]. Jemp Muller aura le code JEMU), son nom et prénom et la
matière qu’il enseigne. Nous supposons que chaque professeur enseigne une seule matière.
• Modélisez le fait que chaque classe est enseignée chaque année par un ou plusieurs enseignants. Un enseignant
peut bien sûr donner des cours dans plusieurs classes, mais peut également ne pas donner des cours pendant une
ou plusieurs années.

Utilisation d’une relation ternaire

Lors de l’introduction des relations nous avons déjà mentionné la notion de relation ternaire. Une relation ternaire est
une relation à laquelle sont liées 3 entité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 entités) il existe cependant des situations où l’utilisa-
tion d’une relation ternaire s’impose.
Exemple 23.
A partir des 3 entités à savoir : Professeur (CodeProf, Nom, Prénom), Matière(CodeMatière, Libellé) et Classe(Nom,Cycle),
il s’agit de créer un MCD qui renseigne sur le fait quelle matière est enseignée dans quelle classe par quel professeur pour
une année scolaire donnée.

Exercice 6.
Essayez de montrer les limites/défauts d’un MCD qui représente l’énoncé de l’exemple précédent en utilisant uniquement
des relations binaires. Pour l’exemple précédent, la figure 2.22 donne une solution qui utilise une relation ternaire
Il existe 3 façons pour lire/interpréter ce modèle :

• Un professeur peut enseigner 1 à n fois une matière dans une classe.

 23

F IGURE 2.22

• Une matière peut être enseignée 1 à n fois par un professeur dans une classe.

• Une classe peut être enseignée 1 à n fois dans une matière par un professeur.

On peut dire que chaque occurrence de la relation enseigner associe un professeur à une matière et une classe pour une
année donnée. Ou encore, ce modèle nous permet de montrer pour chaque année scolaire quelle matière est enseignée dans
quelle classe par quel professseur.
Il n’est pas toujours facile de déterminer quand il faut utiliser une relation ternaire. Généralement, on peut déjà affirmer
que si une ou plusieurs des entités liées à une relation ternaire possèdent une cardinalité maximale de 1, la modélisation n’est
pas optimisée dans le sens qu’il faudrait mieux décomposer la relation ternaire, c.à.d. la représenter par 2 relations binaires.
Exemple 24.
La direction d’une chaı̂ne d’hôtels désire gérer les séjours des clients dans les différents hôtels. Comme on peut effectivement
dire ”Un client effectue un séjour dans un hôtel” on est ammené à proposer la modélisation de la figure 2.23.

F IGURE 2.23

Il existe 3 façons pour lire/interpréter ce modèle :

• Un client peut effectuer 1 à n fois un séjour dans un hôtel.

• Dans un hôtel peut être effectué 0 à n fois un séjour par un client.

• Un séjour peut être effectué une et une seule fois par un client dans un hôtel.

Chaque occurrence de la relation effectuer associe donc un séjour à un client et à un hôtel.

Hors, cette modélisation porte une contrainte supplémentaire, puisque la cardinalité 1,1 entre l’entité Séjour et la relation
nous indique que pour chaque occurrence de Séjour il ne peut exister qu’une et une seule occurrence de la relation. Donc
chaque séjour est associé une et une seule fois à une combinaison client/hôtel. Dans ce cas il vaut mieux décomposer la
relation ternaire et l’on obtient la modélisation de la figure 2.24.
24

F IGURE 2.24

Les contraintes d’intégrité fonctionnelles (CIF)

Quand on détermine entre une relation et une entité une cardinalité qui présente les valeurs 0,1 ou 1,1, alors cette relation
est particulière et on dit qu’elle représente une Contrainte d’Intégrité Fonctionnelle (CIF).
Exemple 25.
Soit donnée la figure

F IGURE 2.25

La relation Obtenir représente une CIF.

Une CIF indique que l’une des entités est totalement déterminée par la connaissance de l’autre. Dans notre exemple on
peut dire que connaissant une facture bien précise, on connaı̂t avec certitude le client correspondant.
Comment est-ce qu’on représente une CIF dans un MCD ?
Une CIF est souvent représentée par une flèche sur la patte opposée à celle ayant une cardinalité 0,1 ou 1,1. L’entité qui
est attachée à cette patte est appelée entité cible de la CIF, tandis que l’autre entité constitue l’entité émettrice de la CIF.

Exercices-TDs

Exercice 7.
Voici le résultat simplifié d’une analyse faite auprès d’une compagnie d’assurance qui désire informatiser la gestion des
contrats auto.

• Un client peut assurer plusieurs voitures auprès de la compagnie. Chaque voiture est assurée par un seul contrat. Un
contrat assure une seule voiture.

• En ce qui concerne un client, la compagnie désire connaı̂tre son nom, prénom, adresse complète, numéro de téléphone
ainsi qu’un numéro de compte bancaire avec indication de la banque.

• Chaque contrat contient un numéro de contrat unique, la prime annuelle à payer, la date de paiement annuel, la
marque de la voiture, le modèle de la voiture, le numéro d’immatriculation de la voiture, la valeur de la voiture et la
date d’acquisition de la voiture.

En ignorant la méthode de modélisation, on pourrait créer une BD avec une seule table ayant un champ pour chaque
donnée indiquée dans l’analyse. On aurait donc les données des clients et des contrats dans une seule table. Quelles en
seraient les inconvénients ?
 25
Créez le modèle conceptuel des données correspondant à cette situation
Exercice 8.

• Le responsable d’un magasin de location de cassettes vidéo désire informatiser le système de gestion des locations.
Voici les informations recueillies pendant l’analyse : Un membre est caractérisé par son numéro membre, son nom,
son prénom, son adresse ainsi que sa date de naissance. Dès que la carte de membre est payée (paiement unique), le
membre est enregistré dans le système et il peut désormais louer des cassettes vidéo.

• Un film est caractérisé par un numéro film, un titre, un code langue, un code genre et une durée. Le même film peut
être disponible en plusieurs exemplaires. Un exemplaire est déterminé par un numéro exemplaire ainsi que la date
d’achat de l’exemplaire.

• Lors d’une location, un membre peut louer plusieurs films en même temps. En principe, une location a une durée d’un
jour, mais cette durée peut être prolongée. Nous supposons qu’un membre rend tous les exemplaires loués en une seule
fois.

Créez le modèle conceptuel des données

Exercice 9.
Afin d’informatiser la gestion des séances du cinéma Limelight, vous disposez des informations suivantes.

• Un film est enregistré dans le système d’information dès que la (les) copie(s) sont arrivées au cinéma. A partir de ce
moment, on commence à programmer des séances pour le film en question. Comme le même film n’est jamais joué
dans deux séances parallèles, on peut ignorer la gestion des copies.

• Un film est représenté par un numéro courant interne, qui lui est affecté par le gestionnaire des séances. En plus, on
s’intéresse pour le titre, la langue et la durée du film. Lorsqu’un film apparaı̂t en plusieurs langues différentes, on
crée dans le système d’information simplement un enregistrement par langue. Chaque film est accompagné en général
d’une fiche technique, qui renseigne en outre sur le système son du film ([Link]. DOLBY, THX etc.). Cette information
est importante, puisque les capacités en ce qui concerne la reproduction du son varient d’une salle dans une autre. Une
salle peut supporter plusieurs systèmes différents, tandis qu’un film est tourné en utilisant un seul système son. Un
système son est caractérisé par un code identificateur ainsi qu’un libellé.

• Le cinéma dispose actuellement de 12 salles, avec 3 nouvelles salles en construction. Une salle est prise en compte
dans le système d’information, dès qu’elle est prête pour accueillir des séances. Une salle est caractérisée par son
numéro, sa capacité ainsi que des informations concernant le support des différents systèmes son.

• Le système d’information doit permettre de vendre des tickets pour une séance donnée, même plusieurs jours en
avance. La réservation des sièges n’étant pas demandée, il est toutefois nécessaire que le système soit capable de
prévenir un excès de la capacité d’une salle en ce qui concerne le nombre de tickets vendus.

• La gestion des prix pour les tickets se fait au niveau des séances, puisque le prix pour voir un même film peut varier
d’une séance à une autre ([Link]. Tarif réduit les lundis à 16h00). Une séance, qui se déroule évidemment sans une seule
salle, est identifiée par un numéro courant.

Créez le modèle conceptuel des données

Exercice 10.
Le commandant de la brigade municipale des Sapeurs-Pompiers de Mimboman se propose d’informatiser la gestion des
différentes interventions. Etant responsable de l’administration de la brigade, vous êtes en charge de créer une base de
données pour stocker les informations relatives aux interventions.

Partie 1 Voici le résultat de l’analyse préliminaire menée auprès des responsables de la brigade ([Link]. le commandant, le
sous-commandant ?)

• Chaque intervention est identifiée par un numéro unique

• Une intervention est en plus caractérisée par une date, une adresse et un type d’intervention ([Link]. Incendie,
Accident, Inondation)
• Pour chaque intervention, on veut savoir quels sapeurs-pompiers y ont participé
26
• Un sapeur-pompier est caractérisé par un numéro d’identification, son nom, son prénom, son âge ainsi qu’un
grade ([Link]. sapeur, chef de section, sous-commandant, commandant)

Créez le modèle conceptuel des données

Partie 2 Le commandant vous demande de représenter également l’utilisation des véhicules de la brigade. Lors d’une in-
tervention, les sapeurs-pompiers sont affectés aux différents véhicules selon les circonstances. Jusqu’à présent, le
commandant a rempli une fiche pour chaque intervention (Cf Figure 2.26)

F IGURE 2.26

• Un véhicule est identifié par son numéro d’immatriculation

• Un véhicule est en plus caractérisé par un type de véhicule ([Link]. Echelle, Transport . . . ), une marque, et le
nombre de places disponibles

Créez le modèle conceptuel des données

Cas particuliers du MCD

Plusieurs relation différentes entre deux entités Exemple 26.

Une personne, qui habite dans une maison n’est pas toujours propriétaire de cette maison, tandis que le propriétaire d’une
maison ne doit pas nécessairement habiter dans celle-ci. Il incombe donc de représenter le fait de posséder une maison par
une relation séparée et le fait d’habiter dans une maison par une relation séparée.
 27

F IGURE 2.27

Relation réflexive et rôle d’une patte de relation Exemple 27.

Une relation réflexive, est une relation, dont les deux pattes sont liées à une même entité. En général, la signification des
pattes d’une relation réflexive devrait être clarifiée par l’indication d’un rôle.

Cas 1 : Une illustration est donnée à la Figure 2.28

F IGURE 2.28 – Pattes dans une relation ré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 hiérarchie prédéfinie en ce qui concerne les brevets (structure arborescente). A chaque fois qu’un pilote a
réussi un brevet, il a la possibilité d’effectuer un certain nombre d’autres brevets, qui sont dépendants du brevet réussi.
Tous les brevets sont dépendants du brevet de base.

F IGURE 2.29

Notion d’identifiant relatif Sachant que chaque entité doit obligatoirement être dotée d’un identifiant, certaines entités
ont cependant une existence complètement dépendante et liée à une autre entité. Une entité A est complètement dépendante
d’une entité B, c.à.d. qu’une occurrence de l’entité A ne peut pas exister sans être reliée à une occurrence de l’entité B,
lorsque les deux conditions suivantes sont vraies :

1. L’entité A est émettrice d’une CIF tandis que l’entité B est cible de la même CIF.

2. L’entité A n’est pas indépendante par rapport à la CIF (Cardinalité minimale = 1)

Exemple 28.

L’entité Tâche est complètement dépendante de l’entité Projet.

Dans le cas d’une telle dépendance complète, on peut avoir recours à un identifiant relatif. Dans notre exemple, la
propriété No Tâche constitue l’identifiant relatif de l’entité Tâche. Cette propriété ne remplit dans ce cas pas les conditions
28

F IGURE 2.30

pour devenir identifiant absolu (Le même numéro de tâche est susceptible d’apparaı̂tre dans plusieurs projets). Toutefois, on
peut affirmer qu’en relation à un certain numéro de projet, le numéro de tâche est un identifiant absolu.
On note cette identification relative par la lettre (R) sur la patte reliée à l’entité qui contient l’identifiant relatif.

Historisation Pour certaines propriétés, entités ou relations, on désire parfois conserver les valeurs antérieures en cas de
modification. On parle dans ce contexte d’historisation. Théoriquement, cette idée n’est pas tout à fait en accord avec les
règles de conception d’un système d’information. Prenons l’exemple suivant :

Pour une occurrence de cette entité, c.à.d. pour un assuré spécifique, il existe uniquement une seule
valeur pour chaque propriété. Selon cette modélisation, un assuré ne peut par exemple pas habiter en
même temps dans deux localités différentes. En général, ceci ne pose aucun problème, comme un assuré
indique normalement une seule adresse de référence.
Toutefois, cette modélisation ne permet pas de représenter le tracé historique des adresses, lorsqu’un
assuré déménage une ou plusieurs fois. Dans la plupart des cas, cette modélisation de l’historique n’est
F IGURE 2.31
pas demandée, mais elle est quand même réalisable à l’aide de la méthode Merise. Au niveau conceptuel, nous indiquons
simplement ce que nous voulons historiser.
Nous distinguons 3 cas :

Propriété historisée La conservation des valeurs historiques s’applique à une ou plusieurs propriétés d’une entité ou d’une
relation. Dans le MCD, on indique une historisation de propriété par la lettre (H) derrière la resp. les propriétés
concernées. Cf. Figure 2.32

Entité historisée La conservation des valeurs s’applique à toutes les propriétés d’une l’entité. On indique l’historisation par
la lettre (H) derrière le nom de l’entité.Cf. Figure 2.33

Relation historisée La conservation des valeurs s’applique à toutes les propriétés d’une relation. On indique l’historisation
par la lettre (H) derrière le nom de la relation. Cf. Figure 2.34 On ne peut pas historiser une relation sans propriété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-
priétés d’une relation. On peut remarquer à ce moment que la méthode MERISE présente une particularité en ce
qu’elle ne prévoit pas l’historisation d’une propriété individuelle d’une relation

Exercices-TDs

Exercice 11.
Un club de tennis vous demande d’informatiser la gestion des réservations des diffé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 caractérisé par un numéro interne au club, par son nom, prénom, adresse, code postal, localité, numéro
de téléphone ainsi qu’une indication s’il est un joueur licencié auprès de la fédération de tennis ou non.

• Pour chaque réservation, on désire connaı̂tre l’identité des deux joueurs membres. Au cas où quatre joueurs réserveraient
un terrain, uniquement deux joueurs sont enregistrés dans le système.

• Le club dispose de plusieurs terrains, dont certains sont couverts. On distingue en plus le type du terrain selon la nature
du sol ([Link]. Sable, Herbe etc.)

• Une réservation se fait pour une date précise par tranches d’une heure.

Créez le MCD correspondant.

Exercice 12.
Une société aérienne utilise à présent les fiches suivantes pour la gestion des ressources.

F IGURE 2.35

Sachant que la société entretient déjà une BD avec tous les pilotes et qu’un pilote peut ê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 inconvénients du modèle E/A

Le modèle Entité/Association est simple et pratique.

1. Il n’y a que 3 concepts : entités, associations et attributs.

2. Il est approprié à une représentation graphique intuitive, même s’il existe beaucoup de conventions.

3. Il permet de modéliser rapidement des structures pas trop complexes.

Il y a malheureusement plusieurs inconvénients. Tout d’abord il est non-déterminisme : il n’y a pas de règle absolue pour
déterminer ce qui est entité, attribut ou relation. Exemple : est-il préférable de représenter le metteur en scène (MES) comme
un attribut de Film ou comme une association avec Artiste ? Réponse : comme une association ! Les arguments sont les
suivants :

1. On connaı̂t alors non seulement le nom, mais aussi toutes les autres propriétés (prénom, âge, ...).

2. L’entité MES peut-être associée à beaucoup d’autres films : on permet le partage de l’information.
30
Autre exemple : est-il indispensable de gérer une entité Horaire ? Réponse : pas forcément ! Arguments :

1. Pour. Permet de normaliser les horaires. Plusieurs séances peuvent alors faire référence au même horaire (gain de
place, facilité de mise à jour, cohérence, ...)

2. Contre. On alourdit le schéma inutilement : un horaire est propre à une séance. On peut le représenter comme un
attribut de Séance.

Enfin on a vu qu’une association pouvait être transformée en entité. Un des principaux inconvénients du modèle E/A reste
sa pauvreté : il est difficile d’exprimer des contraintes d’intégrité, des structures complexes.
Beaucoup d’extensions ont été proposées, mais la conception de schéma reste en partie matière de bon sens et d’expérience.
On essaie en général :

1. de se ramener à des associations entre 2 entités : au-delà, on a probablement intérêt a transformer l’association en
entité ;

2. d’éviter toute redondance : une information doit se trouver en un seul endroit ;

3. enfin ? et surtout ? de privilégier la simplicité et la lisibilité, notamment en ne représentant que ce qui est strictement
nécessaire.

2.3 Le modèle logique de données (MLD)

Jusqu’à présent nous avons établi des MCD basés sur une analyse d’un domaine bien défini ([Link]. Gestion des séances
d’un cinéma, Gestion des séjours des patients d’un hôpital etc.). La finalité d’un MCD est de nous faciliter la création d’une
base de données pour gérer un tel domaine.
Nous savons également qu’une base de données est constituée par un ensemble de tables, dont chacune est composée de
champs de données.
Hors le MCD ne connaı̂t pas la notion de table, tandis qu’une base de données ne connaı̂t pas le concept des entités
reliées entre-elles via des relations portant des cardinalités.
Pour cela, il existe un autre modèle, le modèle logique des données (MLD), qui utilise essentiellement le formalisme des
tables logiques. Un MLD, qui est toujours basé sur un MCD donné, contient donc toutes les informations de ce MCD, mais
les représente à l’aide d’un formalisme différent qui est très adapté aux structures d’une base de données.
Tandis que le MCD représente un système d’information d’une façon générale et indépendante d’un système informa-
tique, le MLD tient compte de la réalisation par le biais d’un SGBD.
Un MLD est essentiellement composé de tables logiques reliées entre elles par des flèches -Cf. Figures.

F IGURE 2.36 – Un MCD F IGURE 2.37 – Un MLD

En vous référant à l’exemple précédant, répondez brièvement aux questions suivantes.

Exercice 13.

1. Comment est-ce qu’on traduit une entité du MCD dans le MLD ?

2. Comment est-ce qu’on traduit une propriété d’une entité du MCD dans le MLD ?

3. Comment est-ce qu’on traduit un identifiant d’une entité du MCD dans le MLD ?

4. Comment est-ce qu’on traduit la relation Ecrire avec ses cardinalités du MCD dans le MLD ?

5. Le MCD nous dit que chaque livre est uniquement écrit par un seul auteur (cardinalité max.), tandis qu’un auteur peut
écrire plusieurs livres. Comment est-ce qu’on peut retrouver ces informations dans le MLD ?
 31
Remarque :
La méthode MERISE définit de façon générale certaines règles qui nous permettront de transformer n’importe quel MCD en
MLD.

2.3.1 Règles de transformation du MCD au MLD

Nous allons définir les règles de transformation pour le passage du MCD au MLD, en respectant les différents cas qui se
posent.

Transformation des entités

Toute entité est transformée en table. Les propriétés de l’entité deviennent les attributs de la table. L’identifiant de l’entité
devient la clé primaire de la table.
Exemple 29.

F IGURE 2.38

Transformation des relations binaires du type 2 (x,n) - (x,1)

Afin de représenter la relation, on duplique la clé primaire de la table basée sur l’entité à cardinalité (x,n) dans la table
basée sur l’entité à cardinalité (x,1). Cet attribut est appelé clé étrangère. Les deux tables sont liées par une flèche nommée
selon la relation, qui pointe de la table à clé étrangère vers la table qui contient la clé primaire correspondante.
Exemple 30.

F IGURE 2.39

L’attribut No Auteur qui est clé primaire de la table Auteur, devient clé étrangè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 clé de la table basée sur l’entité à cardinalité (0,1) dans la table basée sur
l’entité à cardinalité (1,1).
Exemple 31.

Le No Client, qui est clé primaire de la table Client, devient clé étrangè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 clé d’une des tables dans l’autre. Lorsque la relation contient elle-même des
propriétés, celles-ci deviennent également attributs de la table dans laquelle a été ajoutée la clé étrangère.
Exemple 32.

F IGURE 2.41

Soit on migre la clé primaire de la table Entreprise dans la table Salarié, soit on fait l’inverse.

Transformation des relations binaires du type (x,n) - (x,n)

On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires des 2 tables. Lorsque
la relation contient elle-même des propriétés, celles-ci deviennent attributs de la table supplémentaire. Une propriété de la
relation qui est soulignée devra appartenir à la clé primaire composée de la table supplémentaire.
Exemple 33.

F IGURE 2.42

On crée une table Porter, qui contient comme clé primaire une clé composée de No-Commande et Code Article. Elle
contient également la propriété Quantité issue de la relation Porter.
 33
Transformation des relations ternaires
On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires de toutes les tables
reliées. Cette règle s’applique de façon indépendante des différentes cardinalités. Lorsque la relation contient elle-même
des propriétés, celles-ci deviennent attributs de la table supplémentaire. Une propriété de la relation qui est soulignée devra
appartenir à la clé primaire composée de la table supplémentaire.
Exemple 34.

F IGURE 2.43

La table Enseigner contient une clé composée de No Enseignant, Code Matière et Nom Classe.

Transformation de plusieurs relations entre deux entités

Les règles géné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 posséder du type (x,n)-(x,n) est traduite par la création d’une table supplémentaire du même nom. Cette table
contient comme clé primaire composée, les clés des deux tables reliées Personne et Maison. On a donc simplement appliqué
2 fois de façon indépendante les règles de transfert MCD → MLD.

Transformation des relations réflexives

Nous appliquons les règles générales avec la seule différence que la relation est 2 fois reliée à la même entité
Exemple 36.

Comme il s’agit d’une relation (x,n)-(x,n), une table supplémentaire est créée. Cette table contient comme clé primaire
composée, la clé des ”deux” entités reliées. Comme la même entité est liée 2 fois à la relation, on ne peut pas utiliser 2 fois
le même nom pour la clé. Dans ce cas il convient d’utiliser des rôles dans le MCD, et d’intégrer le rôle dans le nom d’une
des clés migrées dans le MLD.
Exemple 37.

Comme il s’agit d’une relation (0,1)-(0,1), nous avons en général le choix en ce qui concerne quelle entité contiendra
la clé étrangère. Comme cette relation est liée deux fois à la même entité, il est évident que nous devons dupliquer la clé
primaire, tout en veillant que le même nom de clé ne sera pas utilisé pour la clé primaire et la clé étrangère. Dans notre
exemple, tous les hommes mariés, ont comme valeur de la clé étrangère la matricule de leur épouse actuelle. Pour les
34

F IGURE 2.45

F IGURE 2.46

hommes non mariés et les femmes, la clé étrangère est sans valeur. On pourrait bien sûr utiliser la modélisation inverse avec
une clé étrangère NO MATRICULE MARI, qui indique pour chaque femme mariée, la matricule de son mari.

Transformation de l’identifiant relatif

Sachant que l’entité dépendante est toujours liée à la relation par les cardinalités (1,1), nous pouvons appliquer les règles
générales. Dans chaque cas, la table issue de l’entité dépendante contient donc comme clé étrangère, la clé primaire de l’autre
table. L’identification relative est représentée par le fait que la table issue de l’entité dépendante contient une clé primaire
composée, constituée de la clé primaire transformée de l’identifiant de cette entité et de la clé étrangère.
Exemple 38.

F IGURE 2.47

Tout en respectant les règles générales du passage MCD→MLD, la clé primaire de la table Projet migre comme clé
étrangère dans la table Tâche. L’identification relative est représentée par le fait que la table tâche contient une clé primaire
composée de No Tache et No Projet.

Transformation de l’historisation

Historisation d’une propriété Pour chaque propriété à historiser, on crée une table qui contient :
 35
• Une clé primaire composée de la clé primaire de la table qui contient la propriété à historiser et de la date d’historisa-
tion.

• La propriété à historiser
Exemple 39.
Voir Figure 2.48

F IGURE 2.48

Historisation d’une entité Pour toute modification de valeur d’une des propriétés de l’entité, on historise l’ensemble des
valeurs des propriétés dans une table qui contient :
• Une clé primaire composée de la clé primaire de l’entité à historiser et de la date d’historisation

• Toutes les autres propriétés de l’entité à historiser

Exemple 40.
Voir Figure 2.49

F IGURE 2.49

Historisation d’une relation Pour toute modification de valeur d’une des propriétés de la relation, on historise l’ensemble
des valeurs des propriétés dans une table qui contient :
• Une clé primaire composée de la clé primaire de la table qui représente la relation à historiser et de la date d’histori-
sation

• Toutes les autres propriétés de la relation à historiser

Voir Figure 2.50
Exemple 41.

Exemple ”KaafKaaf”
Transformez le MCD de la Figure 2.51 , qui représente la facturation de la société ”KaafKaaf” (voir l’exercice-exemple
1 de la section 2.2.3), en un MLD en respectant toutes les rè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 réalisés jusqu’ici.
Exercice 15.
Transformez le MCD suivant en MLD en respectant toutes les règles de passage M CD → M LD.
Remarques :

• En ce qui concerne le rapport médical, une conclusion médicale pourrait par exemple ê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’entité Salarié est historisée.

 37

F IGURE 2.53 – MCD Médecine de travail

Exercice 16.
Voici un MCD qui représente de façon très simplifiée la gestion d’une compagnie d’assurances. Transformez le MCD en
MLD en respectant toutes les règles de passage M CD → M LD.

F IGURE 2.54 – MCD Assurance

Remarques :

• Le type de contrat indique les garanties pré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 + Dégâts matériels)

• Un contrat couvre un seul risque. Ce risque peut être une voiture ou une habitation.

• Afin d’améliorer l’exploitation statistique des données concernant les garanties, le tarif d’une garantie est historisé.
38
2.4 Le modèle physique de données (MPD)
Le modèle physique des données (MPD) est la traduction du modèle logique des données (MLD) dans une structure de
données spécifique au système de gestion de bases de données (SGBD) utilisé.
Le MPD est donc représenté par des tables définies au niveau du système de gestion de bases de données. C’est donc au
niveau du MPD que nous quittons la méthode générale de création d’un MCD et de sa transformation en MLD, pour nous
tourner vers la manipulation d’un SGBD spécifique.

2.4.1 Passage du MLD au MPD

Le passage M LD → M P D se fait par les étapes suivantes :

• Implémentation physique de chaque table du MLD dans le SGBD utilisé.

• Pour chaque table, indiquer au SGBD quel(s) champ(s) constitue(nt) la clé primaire.

• Pour chaque table, indiquer au SGBD la (les) clé(s) étrangère(s), et la (les) clé(s) primaire(s) correspondante(s).

Pour ce faire, la plupart des SGBD actuellement sur le marché nous offrent 2 possibilités.
Prenons à titre d’exemple l’implémentation du modèle logique suivant (Cf. Figure 2.55). On procède alors comme suit !

F IGURE 2.55 – MCD Assurance

1. Utilisation d’une ou de plusieurs interfaces graphiques, qui nous aident dans la création des tables physiques, dans la
définition des clés primaires et dans la définition des relations.
Exemple 42.
Définition de la table des employés avec le champ idEmployé étant défini comme clé primaire.

F IGURE 2.56
 39

F IGURE 2.57

Définition de la relation entre les deux tables.

Remarquez que les noms des différents champs ont été modifiés lors de l’implémentation du modèle logique. Cette
mesure dépend uniquement de la convention des noms utilisée et n’affecte pas du tout le fonctionnement correcte de
la BD.

2. Utilisation de commandes spéciales, faisant partie d’un langage de définition de données ([Link]. SQL-DDL, Cf figure
2.58)

Que vous avez utilisé l’une ou l’autre des 2 méthodes, le résultat sera toujours un ensemble de tables physiques reliées entre
elles, dans lesquelles vous pouvez stocker des données.

2.4.2 Les contraintes d’intégrité

Une modélisation correcte et cohérente est sans doute une condition nécessaire pour créer une BD fonctionnelle, mais ne
vaut pas grand chose, lorsque le SGBD utilisé pour implémenter la base, ne garantit pas l’intégrité de celle-ci lors du travail
journalier avec les données.
Exemple 43.

• Le système doit empêcher un utilisateur à entrer une valeur double ou indéterminée (NULL) pour un champ déclaré
comme clé primaire.

• Le système doit vérifier qu’une quantité livrée est toujours inférieure ou égale à une quantité commandée.

Les types de contraintes d’intégrité

• La contrainte d’intégrité des tables (angl. Table Integrity Constraint) Cette contrainte vérifie qu’il n’existe jamais des
doublons ou des valeurs indéterminées pour le(s) champ(s) qui constitue(nt) la clé primaire. La clé primaire doit donc
toujours être unique et bien définie.
Exemples de violation de cette contrainte

A. L’ajout d’une valeur de clé primaire qui existe déjà dans la table.
B. La modification d’une valeur de clé primaire vers une valeur qui existe déjà dans la table.
C. L’ajout d’une valeur indéterminée pour une clé primaire.
D. La modification d’une valeur de clé primaire vers une valeur indéterminée.

Méthodes de vérification dans un SGBD

Dans un SGBD il suffit généralement de déclarer un ou plusieurs champs comme clé primaire d’une table pour que
cette contrainte soit automatiquement vérifiée pour chaque insertion ou modification d’une valeur dans la table.

• La contrainte d’intégrité référentielle (angl. Referential Integrity Constraint)

Par contrainte d’intégrité référentielle, on entend l’obligation qu’à chaque valeur d’une clé étrangère correspond une et
une seule valeur de la clé primaire associée. Cette obligation doit toujours être vérifiée lors de l’ajout, de la suppression
ou de la modification de données.
Exemples de violation de cette contrainte

A. A. L’ajout d’une clé étrangère pour laquelle il n’existe pas de valeur correspondante dans la clé primaire associée.
40

F IGURE 2.58

B. B. La modification d’une clé étrangère vers une valeur pour laquelle il n’existe pas de valeur correspondante dans
la clé primaire associée.
 41
C. C. La suppression d’une clé primaire, qui est référencée par une ou plusieurs valeurs d’une clé étrangère.
D. D. La modification d’une clé primaire, qui est référencée par une ou plusieurs valeurs d’une clé étrangère.

Méthodes de vérification dans un SGBD

Un SGBD nous offre généralement une ou plusieurs des quatre méthodes suivantes pour spécifier à tout moment
l’intégrité référentielle des données d’une BD.

I. Interdiction des opérations du type A, B, C et D. Bien que cette possibilité soit très efficace, il existe parfois une
alternative préférable en fonction de la nature des données. Remarque : Tandis que les opérations A et B ne sont
jamais permises lorsque l’intégrité référentielle est appliquée, il n’en est pas de même pour les opérations C et
D. Le langage SQL par exemple contient une commande CREATE TABLE qui permet de dé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 réaliser explicitement l’interdiction des opérations C et D.
II. Cascade des opérations du type C et D vers les clés étrangères correspondantes. Une modification d’une clé pri-
maire aurait comme conséquence la modification de toutes les clés étrangères correspondantes. Une suppression
d’une clé primaire aurait comme conséquence la suppression automatique de tous les enregistrements dont la
clé étrangère a la même valeur. Cette option est à utiliser avec pré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 défaut aux clés étrangères concernées par une opération du type C ou D.
IV. Affectation d’une valeur indéterminée (NULL) aux clés étrangères concernées par une opération du type C ou D.

• La contrainte d’intégrité générale (angl. General Integrity Constraint) Une contrainte d’intégrité générale est utilisée
pour limiter les valeurs possibles d’un champ quelconque d’une table en fonction de la nature de celui-ci et de son rôle
dans le système d’information.
Exemples de violation de cette contrainte
Il existe plusieurs variantes de cette contrainte.

A. A chaque champ correspond un type de données, une longueur et un format bien définis.
Exemple 44.
Le numéro client doit être une valeur numérique.
Le nom du client ne doit pas dépasser 25 caractères.
Un numéro de compte doit respecter le format X-XXX/XX-X
B. Un champ peut avoir un domaine de valeurs prédéfini (une plage de valeurs possibles) et/ou une valeur par défaut.
Exemple 45.
Une note d’un devoir en classe doit être entre 0 et 60
La prix d’une facture ne doit pas être un nombre négatif.
La date d’une commande doit automatiquement être la date actuelle à 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 supérieure ou égale à la valeur du champ fldDateFacture pour une table
tblFactures.

2.4.3 Exercices-TDs
Soit la BD représentée à la figure 2.59.

a) Quelle(s) contrainte(s) est(sont) concernée(s) lors de l’ajout d’un client ?

b) Quelle(s) contrainte(s) est(sont) concernée(s) lors de la suppression d’un client ?

c) Quelle(s) contrainte(s) est(sont) concernée(s) lors de l’ajout d’une facture ?

d) Quelle(s) contrainte(s) est(sont) concernée(s) lors de la suppression d’une facture ?

e) Quelle(s) contrainte(s) est(sont) concerné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) concernée(s) lors de la suppression d’un enregistrement de la table tblConcerne ?

g) Quelle(s) contrainte(s) est(sont) concernée(s) lors de la modification du numéro d’un article dans la table des articles ?

h) Quelle(s) contrainte(s) est(sont) concernée(s) lors de la modification du numéro client d’une facture ?
Chapitre 3

Théorie de la normalisation et Algèbre

relationnelle

3.1 Les dépendances fonctionnelles & Normalisation

3.1.1 Les dépendances fonctionnelles
Dé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 dépendance fonctionnelle entre X et Y (ou que X détermine Y ou que Y est déterminé par X) noté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 à une valeur donnée de X correspond tout au plus à une valeur de B. A toute valeur x ∈ Dx, on ne
peut avoir qu ?une valeur unique y ∈ Dy.
Pour une dépendance fonctionnelle X −→ Y , S est la source et Y la cible.
Exemple 47.
Num Nom Prénom Adresse Télé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.
Dé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 où Y = U − X (i.e le complémentaire de X dans U).
Ainsi, la clef primaire d’une relation doit ê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 Propriétés des dépendances fonctionnelles

Soient X et Y deux ensembles d’attributs.
Réflexivité Si Y ⊆ Y , alors X −→ Y (et donc X −→ X)
Augmentation Si X −→ Y et W ⊆ Z, alors X, Z −→ Y, W
Transitivité Si X −→ Y et Y −→ Z, alors X −→ Z
Pseudo-transitivité Si X −→ Y et Y, Z −→ W , alors X, Z −→ W
Union Si X −→ Y et X −→ Z, alors X −→ Y, Z
Décomposition Si X −→ Y, Z alors X −→ Y et X −→ Z
Définition 8. Soit R(U) une relation et X, Y ⊂ U et X −→ Y .
On a une dé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 vérifiée
44
Définition 9. Soit R(U) une relation et X, Y ⊂ U et X −→ Y .
On a une dé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 vérifié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
Définition 10. Dépendance fonctionnelle élémentaire (DFE)
Soit G un groupe d’attributs et A un attribut, une DF X −→ Y est élémentaire si X n’est pas incluse dans Y et s’il n’existe
pas d’attribut X’ de X qui détermine A.
Exemple 49.

• AB −→ C est élémentaire si ni A, ni B pris individuellement ne déterminent C.

• Nom, DateNaissance, LieuNaissance −→ Prénom est élémentaire.

• AB −→ A n’est pas élémentaire car A est incluse dans AB.

• AB −→ CB n’est pas élémentaire car CB n’est pas un attribut, mais un groupe d’attributs.

• N˚SS −→ Nom, Prénom n’est pas élémentaire.

On peut toujours réécrire un ensemble de DF en un ensemble de DFE, en supprimant les DF triviales obtenues par
réflexivité et en décomposant les DF à partie droite non atomiques en plusieurs DFE. Exemple 50.
On peut réécrire les DF non élémentaires de l’exemple précédent en les décomposant en DFE. Ainsi :

• AB −→ A n’est pas considérée car c’est une DF triviale obtenu par réflexivité.

• AB −→ CB est décomposée en AB −→ C et AB −→ B, et AB −→ B n’est plus considérée car triviale.

• N˚SS −→ Nom, Prénom est décomposée en N˚SS −→ Nom et N˚SS −→ Prénom.

Dé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 être composées par
transitivité à 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}
Définition 12. Couverture minimale des DFE
La couverture minimale d’un ensemble de DFE est un sous-ensemble minimum des DFE permettant de générer toutes les
autres DFE, par application un nombre fini de fois des propriétés des dépendances fonctionnelles.
Synonymes : Famille géné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
Définition 13. Graphe des DFE
On peut représenter un ensemble de DFE par un graphe orienté (ou plus précisément un réseau de Pétri), tel que les n ?uds
sont les attributs et les arcs les DFE (avec un seul attribut en destination de chaque arc et éventuellement plusieurs en
source).

Exemple 53.

1. On considè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 représentation de F par est donné 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 représentation de F par est donné 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 )

Théorème 1. Tout ensemble de dépendances fonctionnelles a une couverture minimale

En effet, à partir d’un ensemble de dépendances fonctionnelles, pour obtenir une couverture minimale, il faut procéder
comme suit :

1. Toute dépendance X −→ Y avec Y = {A1 , A2 , . . . , An } est remplacée par les dépendances X −→ A1 , X −→ A2 ,

. . . X −→ An

2. On élimine le plus de dépendances (redondantes) possibles

3. On élimine le plus d’attributs possibles des membres de gauche

N.B. En géné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 éliminer CE −→ A et CG −→ B

3. On peut remplacer ACD −→ B par CD −→ B.

46
3.1.3 Théorie de la normalisation relationnelle
Les formes normales ont pour objectif de définir la décomposition des schémas relationnels, tout en préservant les DF et
sans perdre d’informations, afin de représenter les objets et associations canoniques du monde réel de façon non redondante.

On peut recenser les 6 formes normales suivantes, de moins en moins redondantes :

• la première forme normale

• la deuxième forme normale

• la troisième forme normale

• la forme normale de Boyce-Codd

• la quatrième forme normale

• la cinquième forme normale

La troisième forme normale est généralement reconnue comme la plus importante à respecter. La BCNF est la plus simple à
établir.

Principe de la décomposition
L’objectif de la décomposition est de ”casser” une relation en relations plus petites afin d’en éliminer les redondances et
sans perdre d’information.

Définition 14. La décomposition d’un schéma de relation R(A1 , A2 , . . . , An ) est le processus de remplacement de ce
schéma par une collection de schémas R1 , R2 , . . . , Rn telle qu’il est possible de reconstruire R par des opérations relation-
nelles de jointure sur R1 , R2 , . . . , Rn .
Définition 15. Une décomposition d’une relation R en relations R1 , R2 , . . . , Rn préserve les DF si la fermeture transitive
F + des DF de R est la même que la fermeture transitive F + de l’union des DF de R1 , R2 , . . . , Rn .
Exemple 55.
Soit la relation Voiture(Numé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 décomposer Voiture en préservant les DF en deux relations R1(Numéro,Type,Couleur) et R2(Type,Puissance,Marque).

Première forme normale (1NF)

Une relation est en 1NF si elle possède au moins une clé et si tous ses attributs sont atomiques.

Définition 16. Un attribut est atomique si il ne contient qu’une seule valeur pour un tuple donné, et donc s’il ne regroupe
pas un ensemble de plusieurs valeurs.
Exemple 56.
On veut représenter une relation indiquant la profession d’une personne par la relation Personne(Nom, Profession)
On a les instanciations suivantes :
1 (Owona, Géomètre)

2 (Menom, Ingé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 à la clé et faire apparaı̂tre deux tuples pour
Owona, on obtiendrait :
Personne(Nom, Profession)
 47
1 (Owona, Géomètre)
2 (Menom, Ingénieur)
3 (Menom, Professeur)

Une autre solution aurait été d’ajouter un attribut ProfessionSecondaire. On obtiendrait ainsi :
Personne(Nom, Profession, ProfessionSecondaire)

(Menom, Ingénieur, Professeur)

(Owona, Géomètre, Null)

L’atomicité d’un attribut est souvent relative : on peut décider qu’un attribut contenant une date n’est pas atomique (et
que le jour, le mois et l’année constituent chacun une valeur), ou bien que l’attribut est de domaine date et donc qu’il est
atomique.
Le modèle relationnel impose qu’une relation ait une clé, donc la condition ”est en 1NF si elle possède une clé” est superflue
(au pire la relation est toute clé).

Il est néanmoins fondamental d’avoir identifié toutes les clés au début du processus de normalisation.

Deuxième forme normale (2NF)

Une relation est en 2NF si elle est en 1NF et si tout attribut n’appartenant à aucune clé candidate ne dépend pas d’une
partie seulement d’une clé candidate. Exemple 57.
On veut repré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 clé) détermine Salaire (un attribut qui n’appartient pas à une clé). Pour avoir un schéma relationnel en
2NF, il faut alors décomposer Personne en deux relations :

Personne(NumeroEmploye, Profession=>Profession, Nom, Prenom)

Profession(Profession, Salaire)

On remarque que ce schéma est en 2NF (puisque Salaire dépend maintenant fonctionnellement d’une clé et non plus d’une
partie de clé).
On remarque aussi que la décomposition a préservé les DF, puisque nous avons à présent :
P rof ession −→ Salaire (DF de la relation Profession)
N umeroEmploye, P rof ession?P rof ession (par Réflexivité)
N umeroEmploye, P rof ession?Salaire (par Transitivité)
N.B. La définition de la 2NF doit être vérifiée pour toutes les clés candidates et non seulement la clé primaire (dans le
cas où il y a plusieurs clés). Si toutes les clés d’une relation ne contiennent qu’un unique attribut, et que la relation est en
1NF, alors la relation est en 2NF.

Troisième forme normale (3NF)

Une relation est en 3NF si elle est en 2NF et si tout attribut n’appartenant à aucune clé candidate ne dépend directement
que de clés candidates.
C’est à dire que toutes les DFE vers des attributs n’appartenant pas à une clé, sont issues d’une clé. Exemple 58.
On veut repré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 clé, détermine Prime. Pour avoir un schéma relationnel en 3NF, il faut
décomposer Profession :

Profession(#Profession, Salaire=>Salaire)
Salaire(#Salaire, Prime)

Ce schéma est en 3NF, car Prime est maintenant déterminé par une clé.
On remarque que cette décomposition préserve les DF, car par transitivité, Profession détermine Salaire qui détermine
Prime, et donc Profession détermine toujours Prime.
48
La définition concerne toutes les clés candidates et non uniquement la clé primaire.
Il est souhaitable que les relations logiques soient en 3NF. En effet, il existe toujours une décomposition sans perte d’infor-
mation et préservant les DF d’un schéma en 3NF. Si les formes normales suivantes (BCNF, 4NF et 5NF) assurent un niveau
de redondance encore plus faible, la décomposition permettant de les atteindre ne préserve plus systé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 clé candidate
détermine un attribut. Exemple 59.
On veut repré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 clé et qui détermine un attribut appartenant à une clé. Cette relation est en 3NF, mais pas en
BCNF (car en BCNF toutes les DFE sont issues d’une clé).

Pour avoir un schéma relationnel en BCNF, il faut décomposer Personne :

Personne(N˚SS, Region, Nom)
Region(#Region, Pays)
Remarquons que les DF n’ont pas été préservées par la décomposition puisque N˚SS et Pays ne déterminent plus Région.

La BCNF est la forme normale la plus facile à appréhender intuitivement et formellement, puisque les seules DFE exis-
tantes sont de la forme K −→ A où K est une clé.
Par ailleurs, une décomposition en BCNF ne préserve pas toujours les DF.
Le premier langage étudié dans ce cours est l’algèbre relationnelle. Il consiste en un ensemble d’opérations qui permettent
de manipuler des relations, considérées comme des ensemble de tuples : on peut ainsi faire l’union ou la différence de deux
relations, sélectionner une partie de la relation, effectuer des produits cartésiens ou des projections, etc.
Une propriété fondamentale de chaque opération est qu’elle prend une ou deux relations en entrée, et produit une relation
en sortie. Cette propriété permet de composer des opérations : on peut appliquer une sélection au résultat d’un produit
cartésien, puis une projection au résultat de la sélection et ainsi de suite.
En fait on peut construire des expressions algébriques arbitrairement complexes qui permettent d’exprimer des manipulations
sur un grand nombre de relations.
Une requête est une expression algébrique qui s’applique à un ensemble de relations (la base de données) et produit
une relation finale (le résultat de la requête). On peut voir l’algèbre relationnelle comme un langage de programmation très
simple qui permet d’exprimer des requêtes sur une base de données relationnelle.
Dans tout ce chapitre on va prendre l’exemple de la (petite) base de données d’un organisme de voyage. Cet organisme
propose des séjours (sportifs, culturels, etc) se déroulant dans des stations de vacances. Chaque station propose un ensemble
d’activtés (ski, voile, tourisme). Enfin on maintient une liste des clients (avec le solde de leur compte !) et des séjours
auxquels ils ont participé avec leurs dates de début et de fin.
• Station (nomStation, capacité, lieu, région, tarif)

• Activite (nomStation, libellé, prix)

• Client (id, nom, prénom, ville, région, solde)

• Séjour (idClient, station, début, nbPlaces)

nomStation capacité lieu

nomStation libellé prix
nomStation capacité lieu région tarif
Venusa Voila 150
Venusa 350 Guadeloupe Antilles 1200
Venusa Plongée 120
Farniente 200 Seychelles Océan indien 1500
Farniente Plongée 130
Santalba 150 Guadeloupe Antilles 2000
Passac Ski 200
Passac 400 Alpes Europe 1000
Passac Piscine 20
Table Station
Santalba Kayac 50
Table Activité
 49
idClient Station début nbPlaces
10 Passac 1998/07/01 2
30 Santalba 1996/08/14 5
id nom prénom ville ré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 Amérique 9812
20 Venusa 1998/08/03 6
Table Client
30 Farniente 1999/06/24 5
10 Farniente 1998/09/05 3
Table Séjour

3.2 L’algèbre relationnelle

L’algèbre relationnelle est le support mathématique cohérent sur lequel repose le modèle relationnel. L’algèbre relation-
nelle propose un ensemble d’opérations élémentaires formelles sur les relations dans le but de créer de nouvelles relations.
Ces opérations permettent de représenter des requêtes sur la base de données dont le résultat s’exprime sous la forme d’une
relation (i.e. table). C’est ce formalisme qui est au c ?ur du langage de requête de SQL.

Nous pouvons distinguer trois familles d’opérateurs relationnels :

• Les opérateurs unaires (la sélection et la projection), qui sont les plus simples, permettent de produire une nouvelle
table à partir d’une autre table.
• Les opérateurs binaires ensemblistes (l’union, l’intersection et la différence) permettent de produire une nouvelle
relation à partir de deux relations de même degré et de même domaine.
• Les opérateurs binaires ou n-aires (le produit cartésien, la jointure et la division) permettent de produire une nouvelle
table à partir de deux ou plusieurs autres tables.
Remarque : Les notations de l’algèbre relationnelle ne sont pas standardisées.
L’algèbre se compose d’un ensemble d’opérateurs, parmi lesquels 5 sont nécessaires et suffisants et permettent de définir
les autres par composition. Ce sont :
1. La sélection, dénotée σ ;
2. La projection, dénotée π ;
3. Le produit cartésien, dénoté × ;
4. L’union, ∪ ;
5. La différence, − .
Les deux premiers sont des opérateurs unaires (ils prennent en entrée une seule relation) et les autres sont des opérateurs
binaires. A partir de ces opérateurs il est possible d’en définir d’autres, et notamment la jointure, ./ , qui est la composition
d’un produit cartésien et d’une sélection. Ces opérateurs sont maintenant présentés tour à tour.

3.2.1 La sélection, σ
La sélection σF (R) s’applique à une relation, R , et extrait de cette relation les tuples qui satisfont un critère de sélection,
F. Ce critère peut être :
• La comparaison entre un attribut de la relation, A, et une constante a. Cette comparaison s’écrit AΘa , où Θ peut être
¡, ¿, ≤ ou ≥
• La comparaison entre deux attributs A1 et A2 , qui s’écrit A1 ΘA2 avec les mêmes opérateurs de comparaison que
précédemment.
Premier exemple : exprimer la requête qui donne toutes les stations aux Antilles.
σF région =0 Antilles0 (Station)
On obtient donc le résultat : La sélection a pour effet de supprimer des lignes, mais chaque ligne garde l’ensemble de ses
attributs.
50
nomStation capacité lieu région tarif
Venusa 350 Guadeloupe Antilles 1200
Santalba 150 Guadeloupe Antilles 2000

3.2.2 La projection, π
La sélection πA1 ,A2 ,·,Ak (R) s’applique à une relation, R , et ne garde que les attributs A1 , A2 , ·, Ak .
Donc, contrairement à la sélection, on ne supprime pas des lignes mais des colonnes.
Exemple : donner le nom des stations, et leur région.

πnomStation,région (Station)

On obtient le résultat suivant, après suppression des colonnes capacité, lieu et tarif :

nomStation région
Venusa Antilles
Farniente Océan indien
Santalba Antilles
Passac Europe

En principe le nombre de lignes dans le résultat est le même que dans la relation initiale. Il y a cependant une petite sub-
tilité : comme le résultat est une relation, il ne peut pas y avoir deux lignes identiques (il n’y a pas deux fois le même élément
dans un ensemble). Il peut arriver qu’après une projection, deux lignes qui étaient distinctes initialement se retrouvent iden-
tiques, justement parce ce que l’attribut qui permettait de les distinguer a été supprimé. Dans ce cas on ne conserve qu’une
seule des deux (ou plus) lignes identiques.
Exemple : on souhaite connaı̂tre toutes les régions où il y a des stations. On exprime cette requête par :

πm boxregion(Station)

On obtient le résultat suivant, après suppression des colonnes capacité, lieu et tarif :

région
Antilles
Océan indien
Europe

La ligne ’Antilles’ était présente deux fois dans la relation Station, et n’apparaı̂t plus qu’en un seul exemplaire dans le
résultat.

3.2.3 Le produit cartésien, ×

Le premier opérateur binaire, et le plus utilisé, est le produit cartésien, ×. Le produit cartésien entre deux relations R et
S se note R × S, et permet de créer une nouvelle relation où chaque nuplet de R est associé à chaque nuplet de S.
Voici deux relations, la première, R, contient

C D
A B
c d
a b
u v
x y
x y

Et voici le résultat de R × S
Le nombre de lignes dans le résultat est exactement |R| × ×|S| (—R— dénote le nombre de lignes dans la relation R).
En lui-même, le produit cartésien ne présente pas un grand intérêt puisqu’il associe aveuglément chaque ligne de R à chaque
ligne de S. Il ne prend vraiment son sens qu’associé à l’opération de sélection, ce qui permet d’exprimer des jointures,
opération fondamentale qui sera détaillé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 schémas des relations R et S sont complètement distincts, il n’y a pas d’ambiguité sur la provenance des
colonnes dans le ré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 très souvent) que les deux relations aient des attributs qui ont le même nom. On doit alors se donner
les moyens de distinguer l’origine des colonnes dans la table résultat en donnant un nom distinct à chaque attribut.
Voici par exemple une table T qui a les mêmes noms d’attributs que R. Le schéma du résultat du produit cartésien R × T

A B
m n
o p

a pour schéma (A,B,A,B) et présente donc des ambiguités, avec les colonnes A et B en double.

La première solution pour lever l’ambiguité est d’adopter une convention par laquelle chaque attribut est préfixé par le
nom de la table d’où il provient. Le ré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 problèmes quand on crée des expressions complexes. Il existe une seconde possibilité,
plus rigoureuse, pour résoudre les conflits de noms : le renommage. Il s’agit d’un opérateur particulier, dénoté ρ, 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 cartésien R × ρA→C,B→D (T ) ne présente alors plus d’ambiguités. ρA Le renommage est
une solution très générale, mais assez lourde à utiliser.

Il est tout à fait possible de faire le produit cartésien d’une relation avec elle-même. Dans ce cas le renommage où l’uti-
lisation d’un préfixe distinctif est impératif. Voici par exemple le résultat de R × R, dans lequel on préfixe par R1 et R2
respectivement les attributs venant de chacune des opé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 opérateurs binaires, qui sont à la fois plus simples et moins fréquemment utilisés. Le premier est
l’union. L’expression R ∪ S crée une relation comprenant tous les nuplets existant dans l’une ou l’autre des relations R et S.
Il existe une condition impérative : les deux relations doivent avoir le même schéma, c’est-à-dire même nombre d’attributs,
mêmes noms et mêmes types.
52
L’union des relations R(A,B) et S(C,D) données en exemple ci-dessus est donc interdite (on ne saurait pas comment
nommer les attributs dans le résultat). En revanche, en posant S? = ρC→A,D→B (S), il devient possible de calculer R ∪ S 0 ,
avec le résultat suivant : Comme pour la projection, il faut penser à éviter les doublons. Donc le nuplet (x,y) qui existe à 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 résultat.

3.2.5 La différence, ?
Comme l’union, la différence s’applique à deux relations qui ont le même schéma. L’expression R ?S a alors pour résultat
tous les nuplets de R qui ne sont pas dans S.
Voici la différence de R et S ?, les deux relations étant définies comme précédemment. La différence est le seul opérateur

A B
a b
R−S

qui permet d’exprimer des requêtes comportant une négation (on veut ?rejeter ? quelque chose, on ?ne veut pas ? des lignes
ayant telle propriété). Il s’agit d’une fonctionnalité importante et difficile à manier : elle sera détaillée plus loin.

3.2.6 La jointure, ./
Toutes les requêtes exprimables avec l’algèbre relationnelle peuvent se construire avec les 5 opérateurs présentés ci-
dessus. En principe, on pourrait donc s’en contenter. En pratique, il existe d’autres opérations, très couramment utilisées, qui
peuvent se contruire par composition des opérations de base. La plus importante est la jointure.

Afin de comprendre l’intérêt de cet opérateur, regardons le produit cartésien Station ./ Activité.

Le résultat comprend manifestement un grand nombre de lignes qui ne nous intéressent pas. Cela ne présente pas beau-
coup de sens de rapprocher des informations sur Santalba, aux Antilles et sur l’activité de ski à Passac.

Si, en revanche, on considère le produit cartésien comme un résultat intermédiaire, on voit qu’il permet de se ramener
au cas où on effectue, par une simple sélection, des rapprochements de lignes distinctes. Sur notre exemple, en considérant
la table ci-dessus comme une table de la base, on rapproche les informations générales sur une station et la liste des activités
de cette station.
La sélection qui effectue un rapprochement pertinent est la suivante :

σF id = idStation(Station ./ Activité)

Prenez bien le temps de méditer cette opération de sélection : nous ne voulons conserver que les lignes de Station ./ Activité
pour lesquelles l’identifiant de la station (provenant de Station) est identique à celui provenant de Activité. En regardant le
produit cartésien ci-dessous, vous devriez pouvoir vous convaincre que cela revient à conserver les lignes qui ont un sens :
chacune contient des informations sur une station et sur une activité dans cette même station. Si vous saisissez cette logique,
vous avez fait un grand pas dans la connaissance des bases relationnelles : consacrez-y le temps de réflexion nécessaire.

En consultant les résultats, on constate qu’on a donc effectué une composition de deux opérations (un produit cartésien,
une sélection) afin de rapprocher des informations réparties dans plusieurs tables, mais ayant des liens entre elles (toutes
les informations dans un nuplet du résultat sont relatives à une seule station). Cette opération est une jointure, que l’on peut
directement, et simplement, noter :
Station ./id=idStation Activité
 53
La jointure consiste donc à 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 clé primaire de l’une des relations et (2)
la clé étrangère dans l’autre relation. Dans l’exemple ci-dessus, c’est le cas pour id (clé primaire de Station) et idStation (clé
étrangère dans Activité). La jointure permet alors de reconstruire l’association conceptuelle entre Station et Activité.

Remarque
La station Santalba, qui ne propose pas d’activité, n’apparaı̂t pas dans le résultat de la jointure. C’est normal et conforme
à la définition que nous avons donné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 critère de rapprochement, F, peut être n’im-
porte quelle opération de comparaison liant un attribut de R à un attribut de S. En pratique, on emploie peu les 6= ou < qui
sont difficiles à interpréter, et on effectue des égalités.

Remarque
Si on n’exprime pas de critère de rapprochement, la jointure est équivalente à un produit cartésien.

Il faut être attentif aux ambigüités dans le nommage des attributs qui peut survenir dans la jointure au même titre que
dans le produit cartésien. Les solutions à employer sont les mêmes : on pré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 requêtes avec l’algèbre

Cette section est consacrée à l’expression de requêtes algébriques complexes impliquant plusieurs opérateurs. On utilise
la composition des opérations, rendue possible par le fait que tout opérateur produit en sortie une relation sur laquelle on
peut appliquer à nouveau des opérateurs.
Chapitre 4

Les requêtes

4.1 Définition
Nous avons vu que la plupart des SGBD offrent la possibilité d’effectuer des recherches directement dans les tables.
Les possibilités de formuler des critères de recherche sont cependant souvent assez limitées. Heureusement, la plupart des
SGBD nous offrent également la possibilité de poser pratiquement n’importe quelle ”question” à nos tables, sous forme de
requêtes.
Les requêtes servent donc à répondre aux questions basées sur le contenu d’une ou de plusieurs tables. Nous allons plus
tard étudier des requêtes, qui se basent sur plusieurs tables, mais pour l’instant nous allons nous limiter aux questions simples
basées sur une seule table. Exemple 60.
Reprenons notre table avec les taxis (Cf. Fig ??) Une requête simple serait par exemple :

• Quelles sont les marques et modèles des voitures ayant une cylindrée supérieure à 2000 ?

Le résultat serait un sous-ensemble de la table avec seulement les enregistrements qui vérifient le critère de sélection (cy-
lindrée ¿ 2000). Pour chacun de ces enregistrements, le SGBD affiche en plus seulement les champs explicitement demandés
(fldMarque et fldModèle).
Une requête simple produit donc comme résultat un sous-ensemble des enregistrements d’une table. En plus, une requête
nous permet d’afficher seulement certains champs pour les enregistrements appartenant à ce sous-ensemble.
On appelle ces requêtes ”Requêtes de Sélection”, puisqu’il s’agit d’une sélection de certains enregistrements.
Il n’existe cependant pas seulement des requêtes de sélection, mais également :

• Des requêtes d’insertion consistant à insérer des enregistrements dans la table. [Link]. Insérer un nouveau taxi : 4, BMW,
325i, 2500, 1270.

• Des requêtes de modification consistant à modifier des enregistrements dans la table. [Link]. Modifier la cylindrée des
Ford Orion de façon à ce qu’elle devienne 2000.

• Des requêtes de suppression consistant à supprimer des enregistrements de la table. [Link]. Supprimer toutes les BMW.

Les requêtes possèdent l’avantage de pouvoir manipuler facilement un grand nombre d’enregistrements sans que l’utili-
sateur ne doive s’occuper de sélectionner enregistrement par enregistrement. Il lui suffit de spécifier des critères de sélection
pour la requête, ainsi que l’opération à effectuer (simple sélection et affichage, insertion, modification ou suppression).
Bien que les requêtes de sélection soient implémentées d’une manière plus ou moins cohérente à travers les SGBD
actuels, il existe des différences subtiles en ce qui concerne les requêtes d’insertion, de modification ainsi que de suppression.
En plus, l’insertion et la suppression se font souvent de manière plus facile directement dans la table.
Il existe 4 types de requêtes :

1. Requêtes de sélection.

2. Requêtes d’insertion.

3. Requêtes de modification.

4. Requêtes de suppression.
56

F IGURE 4.1

Pour chaque requête nous retrouvons le cycle suivant :

Exercice 17.
Quel est en général le résultat d’une requête :

• de sélection

• d’insertion

• de modification

• de suppression

4.2 Introduction au langage SQL

4.2.1 Généralités
Nous avons vu au chapitre précédent qu’il faut d’abord formuler une requête et puis l’exécuter, afin d’avoir des résultats.
Vous pouvez probablement bien vous imaginer que les SGBD actuels ne comprennent pas le langage naturel. Aucun SGBD
n’offre une possibilité d’écrire [Link]. Je veux voir tous les taxis dont la marque est Ford Pour formuler une requête, l’utilisateur
doit donc utiliser un langage spécialisé 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, désormais la présence de standards
internationaux tels que SQL-86, SQL-89 ou SQL-92, chaque SGBD sur le marché utilise un peu son propre dialecte du
langage SQL.

4.2.2 Syntaxe SQL de base

Nous distinguons les 4 types de requêtes suivants.

1. Requêtes de sélection.

SELECT <Nom des champs>

FROM <Nom de la table>
WHERE <Critères de sélection>;

2. Requêtes d’insertion.

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

VALUES ( <Valeurs pour les champs> );

Attention : Lorsque vous n’indiquez pas la liste des champs derrière INSERT INTO , vous devez spécifier une valeur
pour chaque champ de la table derrière VALUES . Les parenthèses derrière VALUES sont obligatoires. La liste des
champs, lorsqu’elle est indiquée, contient les noms des champs, séparés par une virgule, et doit également être entourée
de parenthèses.

3. Requêtes de modification.

UPDATE <Nom de la table>

SET <Nom d’un champ>=valeur, <Nom d’un champ>=valeur, . .
WHERE <Critères de sélection>;
 57
4. Requêtes de suppression.

DELETE FROM <Nom de la table>

WHERE <Critères de sélection>;

Soit une table des employés d’une entreprise avec la structure suivante :

F IGURE 4.2

Voici le code SQL nécessaire pour effectuer quelques requêtes élémentaires :

1. Afficher le prénom et le nom de tous les employés

SELECT fldPrénom, fldNom

FROM tblEmployés;

2. Insérer une nouvelle employée :

F IGURE 4.3

INSERT INTO tblEmployés

VALUES (20, ’Angela’, ’Portante’, ’ITA’, 27, ’F’, ’Comptabilité’);

Remarques Les valeurs sont séparées par des virgules.

En SQL, les données du type TEXTE sont entourées d’apostrophes.
Les dates sont entourées du caractère # et indiquées dans le format américain #Mois/Jour/Année#
Exemple 61.
20/4/98 → #04/20/98# ou #4/20/98# ou #04/20/1998# ou #4/20/1998#

3. Afficher toutes les nationalités représentées dans la société

SELECT fldNationalité
FROM tblEmployés;

Quel est l’inconvénient de cette requête ?

Soit l’adaptation suivante de la requête :
58
SELECT DISTINCT fldNationalité
FROM tblEmployés;

Expliquez l’utilité de l’option DISTINCT

4. Afficher tous les champs pour tous les employés

SELECT idEmployé, fldPrénom, fldNom, fldNationalité, fldAge, fldSexe, fldService

FROM tblEmployés;

ou

SELECT *
FROM tblEmployés;

Remarque : L’opérateur * permet d’afficher tous les champs définis dans la table.

4.2.3 Les critères de sélection

Les critères de sélection constituent une expression logique ; qui peut prendre la valeur ’Vrai’ ou ’Faux’. Les critères de
sélection sont appliqués à chaque enregistrement d’une table. Lorsque pour un enregistrement donné, l’expression logique
prend la valeur ’Vrai’, cet enregistrement :
• fait partie du résultat pour une requête de sélection ;

• est modifié pour une requête de modification ;

• est effacé pour une requête de suppression ;

Comparaison à une valeur donnée Pour chaque enregistrement, la valeur d’un champ donné est comparée à une valeur
fixe. Cette valeur fixe est généralement une valeur numérique, une date ou un texte.
Voici les opérateurs de comparaison :

= ”est égal”

¿ ”strictement supérieur”

¡ ”strictement inférieur”

¿= ”supérieur ou égal”

¡= ”inférieur ou égal”

¡¿ ”est différent”

Exemple 62.

1. Afficher le prénom et le nom de tous les employés du service ”Marketing”

SELECT fldPrénom, fldNom

FROM tblEmployés
WHERE fldService=’Marketing’;

2. Afficher le prénom, le nom et l’âge de tous les employés plus jeunes que 50 ans

SELECT fldPrénom, fldNom, fldAge

FROM tblEmployés
WHERE fldAge<50;
 59
Quel problème se pose lorsqu’on exécute cette même requête encore une fois un an plus tard ?
Comment peut-on éviter un tel problème dès le départ, déjà lors de la conception des tables ?
3. Augmentez de la valeur 1 l’âge de Madame Angela Portante.

UPDATE tblEmployés
SET fldAge=fldAge+1
WHERE fldNom=’Portante’;

Remarque : Cette requête peut provoquer des résultats imprévus au cas ou plusieurs employés ont par exemple le
même nom. Pour être certain de ne pas commettre d’erreur, il faudrait d’abord sélectionner tous les employés qui
s’appellent ”Portante”. Lorsque cette requête ne fournit qu’un seul enregistrement, vous pouvez exécuter la requête
comme indiqué en haut. Par contre lorsque vous remarquez que la table contient plusieurs employés au nom de
”Portante”, vérifiez les enregistrements, et retenez la valeur de la clé primaire (idEmployé) pour l’employé que vous
désirez modifier. Ensuite utilisez la valeur de idEmployé dans la partie WHERE de la commande UPDATE ( ?.WHERE
idEmployé=¡valeur¿).
4. Effacez tous les employés du service Informatique.

DELETE FROM tblEmployés

WHERE fldService=’Informatique’;

4.2.4 Comparaison à un filtre

Parfois, on ne connaı̂t pas la valeur exacte à 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 caractères spéciaux (angl.
Wildcards) suivants :

• % représente n’importe quelle séquence de 0 ou plusieurs caractères ;

• représente un seul caractère quelconque.

Exemple 63.
Pour rechercher des personnes dont le nom est ’SCHMITZ’ ou ’SCHMITT’ ou ’SCHMIT’ etc. on définit par exemple le
filtre suivant : ’SCHMI%’
Le filtre ’BL ’ sélectionne par exemple les valeurs ’BLEU’ ou ’BLUE’ mais pas ’BLANC’
Les filtres sont utilisés ensemble avec le mot réservé LIKE. Voici la syntaxe :
WHERE <Nom du champ> LIKE <Filtre>

Exemple 64.

1. Afficher le nom et le prénom des employés dont le prénom contient un trait d’union ([Link]. Jean-Jacques)

SELECT fldNom, fldPrénom

FROM tblEmployés
WHERE fldPrénom LIKE ’%-%’;

2. Afficher le nom, le prénom et l’âge des employés dont le nom commence par ’W’, est composé de 5 lettres et se
termine par ’R’

SELECT fldNom, fldPrénom, fldAge

FROM tblEmployés
WHERE fldNom LIKE ’W R’;
60
Remarque Pour les manipulations pratiques, il faut se rendre compte que certains SGBD utilisent des caractères spéciaux
différents pour représenter une séquence de caractères respectivement un caractère quelconque. MS-Accesstmpar exemple
utilise les caractères suivants :
SQL MS-Accesstm
Séquence de 0 ou plusieurs caractères % *
Un seul caractère quelconque ?

4.2.5 Les opérateurs logiques

Il existe 3 opérateurs logiques :

NOT (Négation logique) L’opérateur NOT inverse le résultat d’une expression logique.

AND (Et logique) L’opé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’opé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.

Priorité des opérateurs logiques Lorsqu’on combine plusieurs conditions par des opérateurs logiques, le résultat final
de l’expression logique dépend de l’ordre d’exécution des différentes conditions. Cet ordre est déterminé par la priorité des
opérateurs logiques. Voici l’ordre prédéfini en SQL :

1. Déterminer le résultat logique (’Vrai’,’Faux’) des comparaisons (=, ¡, ¿ etc.)

2. Effectuer les négations (NOT)

3. Effectuer les AND

4. Effectuer les OR

Pour modifier cet ordre d’exécution, nous pouvons utiliser des parenthèses afin de grouper les différentes conditions
logiques.
Exemple 65.

1. Afficher le prénom et le nom de tous les employés qui ne travaillent pas dans le service ”Marketing”

SELECT fldPrénom, fldNom

FROM tblEmployés
WHERE NOT fldService=’Marketing’;

Formulez une requête qui affiche exactement le même résultat, sans utiliser l’opérateur NOT.

SELECT fldPrénom, fldNom

FROM tblEmployés
WHERE fldService<>’Marketing’;

2. Afficher le numéro d’employé, le prénom et le nom de tous les employés dont le nom ne commence pas par la lettre
’W’

SELECT idEmployé, fldPrénom, fldNom

FROM tblEmployés
WHERE fldNom NOT LIKE ’W%’;
 61
3. Afficher le numéro de l’employé, le prénom et le nom pour les employés du service Informatique qui ont moins de 30
ans.

SELECT idEmployé, fldPrénom, fldNom

FROM tblEmployés
WHERE fldService=’Informatique’ AND fldAge<30;

4. Afficher le prénom et nom des employés féminins (code=F) qui ne travaillent pas au service marketing.

SELECT fldPrénom, fldNom

FROM tblEmployés
WHERE fldSexe=’F’ AND NOT fldService=’Marketing’;

ou

SELECT fldPrénom, fldNom

FROM tblEmployés
WHERE fldSexe=’F’ AND fldService<>’Marketing’;

5. Afficher tous les champs pour les employés de nationalité luxembourgeoise (Code=LUX) ou portugaise (Code=PRT).

SELECT *
FROM tblEmployés
WHERE fldNationalité=’LUX’ OR fldNationalité=’PRT’;

6. L’employé Emil Meier est transféré du service Comptabilité dans le service Informatique. Reflétez ce changement
dans la table.

UPDATE tblEmployés
SET fldService=’Informatique’
WHERE fldPrénom=’Emil’ AND fldNom=’Meier’;

Remarque Cette requête peut provoquer des résultats imprévus au cas ou plusieurs employés ont par exemple le
même nom. Pour être certain de ne pas commettre d’erreur, il faudrait d’abord sélectionner tous les employés qui
s’appellent Emil Meier. Lorsque cette requête ne fournit qu’un seul enregistrement, vous pouvez exécuter la requête
comme indiqué en haut. Par contre lorsque vous remarquez que la table contient plusieurs employés au nom de
Emil Meier, vérifiez les enregistrements, et retenez la valeur de la clé primaire (idEmployé) pour l’employé que vous
désirez modifier. Ensuite utilisez la valeur de idEmployé dans la partie WHERE de la commande UPDATE ( ?.WHERE
idEmployé=¡valeur¿).

7. Affichez tous les champs pour les employés féminins de nationalité luxembourgeoise (Code=’LUX’) ou allemande
(Code=’ALL’)

SELECT *
FROM tblEmployés
WHERE (fldNationalité=’LUX’ OR fldNationalité=’ALL’) AND fldSexe=’F’;

Est-ce que cette requête serait correcte sans les parenthèses ?

 Deuxième partie

Implémentation des Bases de Données

Table des figures

1.1 Un modèle générique pour les SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 BD du personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Résultat d’une requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Un formulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Etat de paiement mensuel par département . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Entité et occurrence d’entité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1 Représentation graphique d’une entité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Relation et occurrence de relation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Les cardinalités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Cas 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Cas 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 Modèle 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.8 Modèle 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.9 Relations utiliser et Disposer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.10 Modé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 ré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
66
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 Mé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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Liste des tableaux