SYST'EME D'INFORMATION BASES DE DONN EES ET MYSQL - ANN EE 2014 - 2015 LILIANA IB ANESCU
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Système d’information
http://www.agroparistech.fr/Systeme-d-Information.html
Partie I
du TD 1 au TD 5
——————————————————-
Bases de données et MySQL
——————————————————-
Liliana Ibănescu
liliana.ibanescu@agroparistech.fr
UFR d’informatique
Département MMIP
Année 2014 - 2015
Ce support de cours s’appuie sur l’ouvrage Bases de données. Concepts,
utilisation et développement de Jean-Luc Hainaut, paru en 2009 aux éditions
Dunod.
2Table des matières
1 Les bases de données (BD) 7
1.1 La base de données client commande . . . . . . . . . . . . . . . . . 8
1.2 La base de données gie agricole . . . . . . . . . . . . . . . . . . . 10
1.3 BD, tables, lignes et colonnes . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Type de donnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1 Types de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.2 Opérateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.3 La valeur NULL . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Clé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.1 Clé primaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.2 Clés étrangères . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6 Modification et contraintes d’intégrité . . . . . . . . . . . . . . . . . . . 16
1.6.1 Contraintes imposées par les colonnes obligatoires . . . . . . . . 16
1.6.2 Contraintes d’unicité imposées par les clés primaires . . . . . . . 16
1.6.3 Contraintes référentielles imposées par les clés étrangères . . . . 17
1.7 Schéma et contenu d’une base de donnée . . . . . . . . . . . . . . . . . . 19
1.8 Le langage SQL (Structured Query Language) . . . . . . . . . . . . . . . 21
1.9 Les systèmes de gestion de bases de données (SGBD) . . . . . . . . . . . 22
2 Les instructions du langage SQL 23
2.1 Sites Web de référence pour SQL et MySQL . . . . . . . . . . . . . . . . 23
2.2 Le langage SQL DDL (Data Definition Language) . . . . . . . . . . . . . 23
2.2.1 Création d’un schéma . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2 Création d’une table (CREATE TABLE) . . . . . . . . . . . . . 24
2.2.3 Suppression d’une table (DROP) . . . . . . . . . . . . . . . . . . 25
2.2.4 Modification du schéma . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Le langage SQL DML (Data Manipulation Language) . . . . . . . . . . . 26
2.3.1 Extraction de données . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2 Extraction simple (SELECT-FROM) . . . . . . . . . . . . . . . . 26
2.3.3 Extraction de lignes sélectionnées (SELECT-FROM-WHERE) . . 27
2.3.4 Ordre des lignes d’un résultat (clause ORDER BY) . . . . . . . . 29
2.3.5 Les fonctions agrégatives (ou statistiques) . . . . . . . . . . . . . 29
2.3.6 Extraction de données de plusieurs tables (jointure) . . . . . . . . 30
2.3.7 Les sous-requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.8 Sous-requête ou jointure ? . . . . . . . . . . . . . . . . . . . . . 34
32.3.9 Ajout de lignes dans une table (INSERT) . . . . . . . . . . . . . 35
2.3.10 Suppression de lignes (DELETE) . . . . . . . . . . . . . . . . . . 35
2.3.11 Modification de lignes (UPDATE) . . . . . . . . . . . . . . . . . 36
3 Prise en main de l’environnement de développement 37
3.1 Pré-requis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Organisation du répertoire de travail . . . . . . . . . . . . . . . . . . . . 37
3.3 L’éditeur de texte Notepad++ . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.1 Démarrage de Notepad++ . . . . . . . . . . . . . . . . . . . . . 38
3.3.2 Créer un nouveau fichier . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3 Ouvrir un fichier existant . . . . . . . . . . . . . . . . . . . . . . 38
3.4 MySQL et phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.1 Utiliser MySQL avec phpMyAdmin . . . . . . . . . . . . . . . . 39
3.4.2 Opérations sur une base de données avec MySQL . . . . . . . . . 39
3.4.3 Opérations sur les tables d’une base de données . . . . . . . . . . 40
3.4.4 Opérations sur une seule table . . . . . . . . . . . . . . . . . . . 40
3.5 Ressources en ligne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 TD 1 : Travaux dirigés en BD, séance 1 – Requêtes simples sur une table 41
4.1 Premiers pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Exercice 1a : requêtes simples sur la base de données client commande 42
4.2.1 Exemples de requêtes . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2 Requêtes générées par l’interface de phpMyAdmin/MySQL . . . 43
4.2.3 Requêtes en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Exercice 1b : requêtes sur la BD gie agricole . . . . . . . . . . . . . 44
4.4 Pour terminer cet exercice . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5 Questions de révision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5.1 Q.R.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5.2 Q.R.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5.3 Q.R.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 TD 2 : Travaux dirigés en BD, séance 2 – Requêtes avec jointures entre tables 46
5.1 Exercice 2a : requêtes sur la BD client commande . . . . . . . . . . 46
5.1.1 Exemples de requêtes . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.2 Requêtes en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Exercice 2b : requêtes sur la BD gie agricole . . . . . . . . . . . . . 48
5.3 Exercice 3 : fonctions agrégatives . . . . . . . . . . . . . . . . . . . . . 48
5.3.1 Exemples de requêtes sur la BD client commande . . . . . . 48
5.3.2 Exercice 3a : fonctions agrégatives sur la BD client commande 49
5.3.3 Exercice 3b : fonctions agrégatives sur la BD gie agricole . 49
5.4 Questions de révision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4.1 Q.R.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4.2 Q.R.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4.3 Q.R.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4.4 Q.R.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
46 TD 3 : Travaux dirigés en BD, séance 3 – Requêtes de mise à jour 52
6.1 Exercice 4 : requêtes sur la BD client commande . . . . . . . . . . . 52
6.1.1 Exemples de requêtes . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.2 Requêtes générées par l’interface de phpMyAdmin/MySQL . . . 53
6.1.3 Requêtes en SQL . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2 Exercice 5 : Modification et contraintes d’intégrité . . . . . . . . . . . . 55
6.2.1 Question 5a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.2 Questions 5b . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.3 Question 5c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2.4 Question 5d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3 Questions de révision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.1 Q.R.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.2 Q.R.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.3 Q.R.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7 TD 4 : Travaux dirigés en BD, séance 4 – Le système d’information Starboat 58
7.1 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.1.1 Description du contexte . . . . . . . . . . . . . . . . . . . . . . 58
7.1.2 Fonctionnalités attendues du SI . . . . . . . . . . . . . . . . . . 59
7.2 Exercice 6a : le schéma . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.3 Exercice 6b : les requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.4 Exercice 6c : les données . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.5 Exercice 6d : questions . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
56
Chapitre 1
Les bases de données (BD)
L’objectif de ce chapitre est de présenter de manière formelle et succincte les notions
et le vocabulaire utile en base de données. Pour plus de détails vous pourrez vous re-
porter à l’ouvrage Bases de données. Concepts, utilisation et développement de Jean-Luc
Hainaut, paru en 2009 aux éditions Dunod.
Nous baignons dans un tourbillon d’informations : nous recevons des informations de
notre environnement et nous lui en transmettons.
Les informations prennent la forme de données (symboles mémorisés et véhiculés
sur un support matériel ou immatériel). Pour stocker (conserver ou enregistrer) et traiter
(interroger et transformer) ces données, on utilise des bases de données (BD), database
(DB) en anglais (voir les §1.3 à §1.8).
La gestion d’une base de données pose des problèmes complexes et elle est assurée
par des logiciels spécialisés : les systèmes de gestion de bases de données (SGBD), en
anglais DBMS pour database management system (voir le §1.9).
Tout au long de ce cours nous utiliserons deux exemples de bases de données :
1. La base de données appelée client commande, décrite dans le §1.1, est uti-
lisée pour enregistrer les clients, les produits et les commandes d’une entreprise
de matériaux de construction ; le système d’information construit sur cette base de
données permettra, entre autres, d’éditer des factures, de gérer les stocks et la comp-
tabilité.
2. La base de données appelée gie agricole, décrite dans le §1.2, est utilisée par
un GIE 1 agricole pour enregistrer les interventions de ses employés sur les parcelles
des agriculteurs ; le système d’information construit sur cette base de données per-
mettra, entre autres, d’éditer les fiches de paye des employés et les interventions
effectuées pour un agriculteur.
1. GIE = groupement d’intérêt économique
71.1 La base de données client commande
La base de données client commande est utilisée par une entreprise de matériaux
de construction pour lui permettre d’éditer des factures pour ses clients et de gérer ses
stocks.
Le schéma de la base de données client commande est présenté dans la figure 1.1 :
1. la table client est utilisée pour enregistrer les propriétés concernant les clients
de l’entreprise : leur nom, leur adresse, etc.
2. la table produit est utilisée pour enregistrer les propriétés concernant les matériaux
de construction disponibles à la vente : leur libellé, le prix à l’unité, la quantité en
stock.
3. la table commande est utilisée pour enregistrer les propriétés concernant une com-
mande : son numéro, la date de la commande et l’identifiant du client (NCLI) qui
permet de récupérer dans la table client toutes les informations relatives à ce
client.
4. la table detail est utilisée pour enregistrer les “lignes” des commandes : l’iden-
tifiant de la commande (NCOM), l’identifiant du produit (NPRO) et la quantité com-
mandée.
F IGURE 1.1 – Le schéma de la base de données client commande.
A un instant donné, les lignes (ou enregistrements) de la BD client commande
sont ceux donnés dans la figure 1.2.
8table client table commande
table produit table detail
F IGURE 1.2 – Les lignes de la base de données client commande à un instant donné.
91.2 La base de données gie agricole
La base de données gie agricole est utilisée par un groupement d’intérêt écono-
mique (GIE) agricole pour enregistrer les interventions de ses employés sur les parcelles
des agriculteurs. La main d’œuvre pour l’exploitation des parcelles est assurée par les em-
ployés du GIE, payés selon un salaire journalier brut. La BD permet, entre autre, d’éditer
les fiches de payes mensuelles des employés et de lister les interventions effectuées pour
un agriculteur.
Le schéma de la base de données gie agricole est présenté dans la figure 1.3 :
1. la table agriculteur est utilisée pour enregistrer les propriétés concernant un
agriculteur : son nom, son prénom et son adresse.
2. la table parcelle est utilisée pour enregistrer les propriétés concernant les par-
celles des agriculteurs : leur nom, leur lieu, leur superficie et l’identifiant de leur
propriétaire.
3. la table employe est utilisée pour enregistrer les propriétés concernant les em-
ployés.
4. la table intervention est utilisée pour enregistrer les interventions des em-
ployés du GIE sur les parcelles des agriculteurs.
F IGURE 1.3 – Le schéma de la base de données gie agricole.
A un instant donné, les lignes (ou enregistrements) de la BD gie agricole sont
ceux donnés dans la figure 1.4.
10table agriculteur table tarif
table parcelle
table employe
table intervention
F IGURE 1.4 – Les lignes de la base de données gie agricole à un instant donné.
111.3 BD, tables, lignes et colonnes
Une base de données est constituée d’un ensemble de tables.
Une table contient une collection/suite de lignes, aussi appelées enregistrements.
Une ligne d’une table est une suite de valeurs, chacune d’un type déterminé. Une ligne
regroupe les données relatives à une entité ou un fait du domaine d’application (la partie
du monde à laquelle on s’intéresse). Toutes les lignes d’une table ont le même format ou
structure.
Une colonne est définie par son nom et le type de ses valeurs.
Exemple 1. La figure 1.5 représente les informations enregistrées à un instant donné dans
la table produit de la BD client commande : la table a 7 lignes (enregistrements)
décrivant chacune un produit. On trouve dans chaque ligne quatre valeurs représentant
respectivement le code, le libellé, le prix à l’unité d’un produit, ainsi que la quantité restant
en stock. La colonne LIBELLE contient des valeurs qui sont des chaı̂nes de caractères,
les valeurs de la colonne PRIX sont des nombres décimaux (dont deux chiffres après la
virgule) et les valeurs de la colonne QSTOCK sont des nombres entiers (cf à la figure 1.1).
F IGURE 1.5 – Les lignes de la table produit de la BD client commande à un instant
donné.
1.4 Type de donnée
En informatique, un type de donnée, ou simplement type, définit le type des valeurs
que peut prendre une donnée, ce qui permet de déterminer les opérateurs qui peuvent être
appliqués à cette donnée.
1.4.1 Types de base
Les types de base sont les suivants :
– type booléen : les valeurs true et false.
– type numérique : des nombres entiers, des nombres décimaux, des nombres réels.
– type chaı̂ne de caractères : du texte.
– type temporel : une date (jour, mois et année), une heure (heure, minute et seconde).
121.4.2 Opérateurs
Les opérateurs utilisés pour comparer des valeurs sont :
= égal à
> plus grand que
< plus petit que
différent de
>= plus grand ou égal1.4.3 La valeur NULL
L’absence de valeur d’une colonne dans une ligne d’une table se signalera par l’affec-
tation de la valeur conventionnelle NULL à cette colonne.
On peut imposer l’interdiction d’assigner la valeur NULL à une colonne : cette colonne
sera alors une colonne obligatoire. Si la valeur NULL est autorisée, cette colonne sera dite
facultative.
Contrainte : Toute tentative d’insérer une ligne qui ne posséderait pas de valeur pour
une colonne obligatoire serait automatiquement signalée comme erreur.
Exemple 3. Dans la table client de la BD client commande la colonne CAT, pour
catégorie de client, est une colonne facultative. Si au moment de l’enregistrement d’un
client la valeur de la catégorie de ce client n’est pas connue, alors il est possible de ne pas
renseigner cette colonne pour ce client et c’est le marqueur NULL qui sera enregistré.
Remarque : La valeur NULL a un statut particulier par rapport aux autres valeurs, son
usage entraı̂ne de multiples difficultés et certains auteurs recommandent de l’éviter.
1.5 Clé
Une ligne dans une table regroupe des informations sur une entité. Une des propriété
importante dans une table c’est de pouvoir identifier de manière unique une ligne à l’aide
d’un identifiant ou une clé (key en anglais).
Une clé peut être composée de plusieurs colonnes de la table.
Exemple 4. Une ligne de la table client donne les informations relative à un client :
son nom, son adresse, la ville où il habite.
Déclarer que la colonne NOM est une clé de la table client, impliquerais alors, qu’à tout
instant, il n’existera pas deux (ou plusieurs) lignes ayant la même valeur dans la colonne
NOM.
Déclarer que le couple de colonnes (NOM, VILLE) est une clé de la table client, im-
plique alors, qu’à tout instant, il n’existera pas deux (ou plusieurs) lignes ayant la même
valeur pour le couple (nom du client, ville).
1.5.1 Clé primaire
Parmi les identifiants d’une table, l’un est déclaré identifiant primaire ou clé pri-
maire(primary key en anglais).
La clé primaire d’une table impose une contrainte d’unicité : le SGBD rejettera auto-
matiquement toute tentative d’insertion d’une ligne dont la valeur de la clé primaire est
déjà présente dans la table.
Une clé primaire peut être composée de plusieurs colonnes, qui doivent toutes être
obligatoires.
Il est recommandé de toujours déclarer une clé primaire dans une table.
14Exemple 5. La clé primaire de la table employe de la base de données gie agricole 2
est représentée par la colonne Emp Nss qui contient les numéros de sécurité sociale des
employés, qui sont donc uniques.
La clé primaire de la table detail de la base de données client commande 3 est
représentée par le couple de deux colonnes NCOM et NPRO, ce qui impose qu’on ne pourra
pas enregistrer deux lignes ayant le même numéro de commande et le même numéro de
produit (voir aussi l’exemple 9, page 16).
La clé primaire de la table intervention de la base de données gie agricole 4
est représentée par ses trois premières colonnes.
1.5.2 Clés étrangères
Dans une table, appelée table enfant, une de ses colonnes, appelée clé étrangère (fo-
reign key en anglais), peut faire référence à la colonne qui est clé primaire dans une autre
table, appelée table parent. Le couple constitué par une clé étrangère de la table enfant et
la clé primaire de la table parent permet de relier des lignes dans des tables distinctes.
Exemple 6. La table parcelle (table enfant) de la base de données gie agricole 5
a été définie avec une clé étrangère représentée par la colonne Par Prop qui fait référence
à la clé primaire Agr Id de la table agriculteur (table parent). Ceci implique que
pour une ligne de la table parcelle, la valeur de la colonne Par Prop permet de la
relier cette ligne à une ligne de la table agriculteur.
Pour la version de la BD de la figure 1.4, sur la troisième ligne de la table parcelle,
la valeur 1 dans la colonne Par Prop permet de relier la parcelle décrite sur cette ligne,
Plan des Bauges, avec la première ligne de la table agriculteur, en retrouvant ainsi
toutes les informations concernant l’agriculteur : son nom (Dulhac), son prénom et son
adresse.
Exemple 7. La table detail (table enfant) de la base de données client commande 6
a deux clés étrangères :
1. la colonne NCOM, appelée dans la suite FK1, qui fait référence à la clé primaire, la
colonne NCOM, de la table commande (table parent) ;
2. la colonne NPRO, appelée dans la suite FK2, qui fait référence à la clé primaire
NPRO, de la la table produit (table parent’).
Pour la version de la BD de la figure 1.2, pour la dernière ligne de la table detail
– la valeur 30188 dans la colonne NCOM permet de relier cette ligne avec la dernière
ligne de la table commande en retrouvant ainsi la date de la commande, le 3 janvier
2009 (par la clé FK1).
– la valeur PH222 dans la colonne NPRO permet de relier cette ligne avec l’avant-
dernière ligne de la table produit en retrouvant ainsi toutes les informations
concernant le produit PL. HETRE 200x20x2 (par la clé FK2).
2. voir la figure 1.3, page 10
3. voir la figure 1.1, page 8
4. voir la figure 1.3, page 10
5. voir la figure 1.3, page 10
6. voir la figure 1.1, page 8
15On notera que le nom d’une colonne formant une clé étrangère peut être le même ou
peut-être différent de celui de la clé primaire à laquelle elle fait référence.
Pour qu’une clé étrangère joue correctement le rôle de référence, il est nécessaire que
l’ensemble de ses valeurs dans la table enfant soit un sous-ensemble des valeurs de la
clé primaire de la table parent. Cette propriété est appelée contrainte référentielle (voire
aussi le §1.6.3, page 17). Elle est garantie par le SGBD pour autant qu’on ait explici-
tement déclaré les clés étrangères (c.à.d. créer les relations avec les clés primaires aux-
quelles elles font référence) : toute opération qui conduirait à violer cette contrainte serait
automatiquement rejetée.
1.6 Modification et contraintes d’intégrité
Les colonnes obligatoires, les clés primaires et les clés étrangères, imposent aux
données des contraintes qui doivent être satisfaites à tout instant. Ces contraintes, désignées
généralement sous le terme de contraintes d’intégrité, seront donc prises en compte lors
de toute tentative de modification sur les données. Ajouter une ligne, supprimer une ligne
ou modifier une valeur de colonne d’une ligne sont des opérations qui ne sont autorisées
que si ces contraintes sont toujours respectées par les données après ces opérations. Si ces
contraintes sont violées, on dit que les données ont perdu leur intégrité.
1.6.1 Contraintes imposées par les colonnes obligatoires
Si une colonne est déclarée obligatoire, chaque ligne doit en posséder une valeur. Lors
des opérations de création et de modification de lignes, cette colonne devra reçevoir une
valeur, à l’exclusion de la valeur NULL.
1.6.2 Contraintes d’unicité imposées par les clés primaires
Une clé primaire (cf. §1.5.1) impose une contrainte d’unicité signifiant qu’à tout ins-
tant les lignes d’une table possèdent des valeurs distinctes pour la ou les colonnes consti-
tuant la clé.
– La création d’une ligne est autorisée s’il n’existe pas de ligne possédant la même
valeur pour la clé primaire.
– Pour la suppression d’une ligne il n’y a pas de contrainte.
– La modification de la clé primaire d’une ligne est autorisée s’il n’existe pas déjà
une ligne possédant cette nouvelle valeur de la clé primaire.
Exemple 8. La clé primaire de la table client de la BD client commande 7 est
représentée par la colonne NCLI.
Pour la version de la BD de la figure 1.2, la création d’une nouvelle ligne ayant comme
valeur C123 dans la colonne NCLI n’est pas autorisée car il existe déjà une ligne, la
sixième, dans cette table ayant cette valeur dans la colonne NCLI.
Exemple 9. La clé primaire de la table detail de la BD client commande 8 est
7. voir la figure 1.1, page 8
8. voir la figure 1.1, page 8
16représentée par le couple de deux colonnes NCOM et NPRO.
Pour la version de la BD de la figure 1.2, la création d’une ligne ayant comme valeur
30188 dans la colonne NCOM et PH222 dans la colonne NPRO n’est pas autorisée car il
existe déjà une ligne, la dernière, ayant ces valeurs pour la clé primaire.
1.6.3 Contraintes référentielles imposées par les clés étrangères
Une contrainte référentielle précise que dans une table enfant chaque colonne iden-
tifiée comme étant une clé étrangère doit à tout instant, pour chaque ligne, contenir une
valeur correspondant à la valeur d’une clé primaire dans une ligne de la table parent.
Exemple 10. La clé étrangère de l’exemple 6 page 15 pour la BD gie agricole im-
pose que dans la colonne Par Prop de la table parcelle les seules valeurs acceptées
sont celles déjà présentes dans la colonne Agr Id de la table agriculteur.
Exemple 11. Les deux clés étrangères présentées dans l’exemple 7 page 15 pour la BD
client commande impose deux contraintes référentielles :
1. la première, cf. FK1, indique que toute valeur de la colonne NCOM dans detail
doit faire référence à une valeur de la colonne NCOM de la table commande ;
2. la seconde, cf. FK2, indique que toute valeur de la colonne NPRO dans detail
doit faire référence à une valeur de la colonne NPRO de la table produit.
Exemple 12. La table commande (table enfant) de la BD client commande doit
respecter la contrainte référentielle donnée par la colonne NCLI identifié comme étant
une clé étrangère, appelée FK3, qui fait référence à la colonne NCLI de la table client
(table parent) : dans la colonne NCLI de la table commande les seules valeurs acceptées
sont celles déjà présentes dans la colonne NCLI de la table client.
La suppression dans la table parent d’une ligne référencée par d’autres lignes dans
une table enfant sera exécutée selon une des stratégies possibles suivantes, appelées delete
mode :
– blocage : la suppression de la ligne dans la table parent est refusée ;
– cascade : la suppression de la ligne dans la table parent est accompagnée de la
suppression des lignes correspondantes dans la table enfant ;
– indépendance : la suppression de la ligne dans la table parent est accompagnée
par la mise à NULL des colonnes correspondant aux clés étrangères des lignes
concernées dans la table enfant.
Exemple 13. Dans la base de données client commande la table detail a pour clé
primaire le couple de colonnes (NCOM, NPRO) (voir aussi l’exemple 5) et doit respecter
les deux contraintes référentielles données dans l’exemple 11. Les conséquences sur la
modification de cette table sont les suivantes :
1. La création d’une ligne dans la table detail est autorisée seulement si :
(a) la valeur de la colonne NCOM de cette nouvelle ligne existe dans la colonne
NCOM de la table commande (cf. FK1) ;
17(b) la valeur de la colonne NPRO de cette nouvelle ligne existe dans la colonne
NPRO de la table produit (cf. FK2) ;
(c) le couple de valeurs (NCOM, NPRO) n’existe pas déjà dans une ligne de la table
detail (voir aussi l’exemple 8).
2. La suppression d’une ligne dans la table detail est autorisée.
3. La modification de la clé primaire d’une ligne dans la table detail, c’est-à-dire le
couple de valeurs (NCOM, NPRO), est autorisée seulement si ces valeurs respectent
les contraintes 1(a), 1(b) et 1(c) vues ci-dessus.
Exemple 14. Dans la base de données client commande, la table commande
i) a pour clé primaire la colonne NCOM,
ii) est la table parent dans la clé étrangère FK1 (voir aussi l’exemple 7), et
iii) est la table enfant dans la clé étrangère FK3 (voir aussi l’exemple 12).
Les conséquences sur la modification de cette table sont les suivantes :
1. La création d’une ligne dans la table commande est autorisée seulement si :
(a) la valeur de la colonne NCOM de cette nouvelle ligne n’existe pas déjà dans
une ligne de la table commande (NCOM est clé primaire) ;
(b) la valeur de la colonne NCLI de cette nouvelle ligne existe dans la colonne
NCLI de la table client (cf. FK3).
2. Si la stratégie de suppression est en mode blocage, alors la suppression d’une ligne
lcomm dans la table commande est autorisée seulement s’il n’existe pas de lignes
dans la table detail qui font référence à cette ligne lcomm (cf. FK1).
3. La modification de la clé primaire d’une ligne dans la table commande, c’est à
dire la valeur de la colonne NCOM, est autorisée seulement si cette valeur respecte
la contrainte 1(a).
Exemple 15. Dans la base de données client commande la table client a pour
clé primaire la colonne NCLI et elle est la table parent dans la clé étrangère FK3. Les
conséquences sur la modification de cette table sont les suivantes :
1. La création d’une ligne dans la table client est autorisée seulement si la valeur
de la colonne NCLI de cette nouvelle ligne n’existe pas déjà dans une ligne de la
table.
2. Si la stratégie de suppression est en mode blocage, alors la suppression d’une ligne
lcli dans la table client est autorisée seulement s’il n’existe pas de lignes dans la
table commande qui font référence à cette ligne lcli (cf. FK3).
3. La modification de la clé primaire d’une ligne dans la table client, c’est à dire la
valeur de la colonne NCLI, est autorisée seulement si cette valeur n’existe pas déjà
dans une ligne de la table client.
Exemple 16. Dans la base de données client commande, si la stratégie de suppres-
sion est en mode cascade pour les clés étrangères FK3 et FK1, alors la suppression d’une
ligne dans la table client sera accompagnée de la suppression de toutes les lignes de
la table commande qui y font référence (c.à.d. toutes les commandes de ce client), ainsi
que la suppression de toutes les lignes concernées de la table detail (c.à.d. toutes les
lignes de toutes les commandes de ce client).
181.7 Schéma et contenu d’une base de donnée
Une base de données est composée de deux parties distinctes : son schéma et son
contenu.
Le schéma d’une base de données spécifie la liste des tables et pour chacune son
nom, la liste de ses colonnes, sa clé primaire et, éventuellement, sa/ses clé(s) étrangère(s).
Pour chaque colonne il faut spécifier son nom, son type et préciser si c’est une colonne
obligatoire ou non.
Le contenu d’une base de données à un instant t est l’ensemble des lignes de toutes
les tables.
Le contenu d’une base de données réelle est généralement volumineux (plusieurs
millions de lignes) et est susceptible d’évoluer constamment. En revanche, le schéma
comporte un nombre limité d’éléments (quelques tables à quelques milliers de tables en
général) présentant une relative stabilité dans le temps : on ne modifie la structure d’une
base de données que lorsque la structure du domaine d’application à représenter évolue.
Il existe plusieurs conventions graphiques de représentation d’un schéma de BD,
parmi lesquelles les plus utilisées sont les suivantes :
1. Une table est représentée soit par un rectangle contenant le nom de la table et celui
de chaque colonne, en liste horizontale (à la mode “EXCEL”), soit par une boı̂te
dont le premier compartiment indique le nom de la table et ensuite les noms de ses
colonnes en liste verticale.
2. La clé primaire est soit soulignée d’un trait continu, soit elle est indiquée en gras,
soit elle est spécifiée par la clause “id :”.
3. Une clé étrangère est soit soulignée d’un trait pointillé, soit spécifiée par la clause
“ref :”.
4. Une contrainte référentielle est représentée par une flèche qui part du nom de la
colonne qui est une clé étrangère et qui pointe vers la clé primaire référencée dans
la table cible.
19Exemple 17. La figure 1.6 donne trois représentations graphiques du schéma de la base
de données client commande, décrite dans le §1.1. Nous utiliserons dans ce cours la
représentation graphique produite par MySQL, donnée dans la figure 1.1 et reprise dans
la figure 1.7.
F IGURE 1.6 – Différentes représentations graphiques d’un même schéma d’une BD
(source : “Bases de données. Concepts, utilisation et développement” de Jean-Luc Hai-
naut).
F IGURE 1.7 – Le schéma de la base de données client commande.
201.8 Le langage SQL (Structured Query Language)
Les SGBD proposent un langage de requête dénommé SQL (Structured Query Lan-
guage). Présenté pour la première fois en 1973, ce langage a rapidement été adopté comme
standard potentiel et pris en charge par les organismes de normalisation ANSI et ISO qui
ont publié 3 normes : SQL-89, SQL-92 (dénommée aussi SQL2) et SQL : 1999 (SQL3).
Malheureusement, les éditeurs de SGBD ne respectent pas intégralement ces normes :
ils ne reprennent qu’un sous-ensemble de spécifications, modifient la syntaxe, voire l’in-
terprétation des concepts retenus, et ajoutent leur propres fonctions. Dans ce cours, nous
utilisons la syntaxe SQL2 dans sa version MySQL.
Le langage de bases de données SQL est composé de deux sous-langages :
1. SQL DDL (Data Definition Language) pour la définition et la modification des
structures (table, colonne, contrainte). Les instructions sont : CREATE, ALTER, et
DROP ;
2. SQL DML (Data Manipulation Language) pour l’extraction et la modification des
données. Les instructions sont : SELECT, INSERT, DELETE, et UPDATE.
Une instruction SQL constitue une requête (en anglais query), c’est-à-dire la descrip-
tion d’une opération que le SGBD doit exécuter.
Une requête SQL peut être écrite en utilisant le clavier, générée à partir d’une interface
graphique, ou importée à partir d’un fichier.
Le résultat de l’exécution d’une requête peut apparaı̂tre à l’écran avec des éventuels
messages d’erreurs. Pour la première partie, du cours nous utilisons cette formulation
interactive des requêtes SQL.
Une requête peut également être envoyée par un programme (écrit en C, PHP ou Java,
par exemple) au SGBD. Dans ce cas, le résultat de la requête est rangé par le SGBD,
ligne par ligne, dans les variables du programme. Dans la deuxième partie du cours, nous
utiliserons le langage PHP pour envoyer des requêtes au SGBD et exploiter ensuite leurs
résultats dans des programmes.
211.9 Les systèmes de gestion de bases de données (SGBD)
La gestion d’une base de données est assurée par des logiciels spécialisés : les SGBD.
Les fonctions d’un SGBD sont les suivantes :
1. Organisation des données : le SGBD organise les données en tables stockées sur
disque et il crée les mécanismes garantissant un accès rapide aux données.
2. Gestion des données : le SGBD garantit l’évolution cohérente des données et il
vérifie que les contraintes (unicité, référence entre tables, etc.) sont respectées.
3. Accès aux données : le SGBD permet l’accès aux données à la fois par un utilisa-
teur occasionnel et par des programmes de traitement de données.
4. Gestion des accès concurrents : le SGBD permet l’accès simultané aux données
par des centaines voire des milliers d’utilisateurs. Il contrôle rigoureusement les
opérations simultanées sur les mêmes données.
5. Contrôle des accès : le SGBD garantit que seuls les utilisateurs autorisés peuvent
accéder aux données et les modifier.
Les différents SGBD sur le marché se différencient par le périmètre d’utilisation des
bases de données. Le périmètre influence le nombre d’utilisateurs simultanés, la taille
des bases de données et la puissance de calcul nécessaire. Certains SGBD, utilisés dans
les entreprises, supportent de très grandes bases de données et nécessitent des ordinateurs
puissants et très couteux. D’autres SGBD fonctionnent sur des ordinateurs personnels bon
marché, avec des limites quant à la taille des bases de données et la puissance de calcul.
Le marché des SGBD 9 se répartit entre
1. des SGBD commerciaux (payants) :
– Oracle Database 10 ,
– DB2 Database Software 11 d’IBM,
– SQL Server 12 de Microsoft,
– Access 13 , édité par Microsoft, qui fait partie de la suite bureautique MS Office
Pro, etc.
2. des SGBD Open Source (ou libre) :
– MySQL 14 ,
– PostgreSQL 15 , etc.
Nous utiliserons dans ce cours le SGBD MySQL 16 , un logiciel SGBD libre.
9. Pour en savoir plus sur les parts de marché consultez, par exemple, http://www.mysql.com/
why-mysql/marketshare/
10. http://www.oracle.com/fr/products/database/index.html
11. http://www-01.ibm.com/software/data/db2/
12. http://www.microsoft.com/france/serveur-cloud/sql/
13. http://office.microsoft.com/fr-fr/access/
14. http://www.mysql.fr/
15. http://www.postgresql.org/
16. http://www.mysql.fr/
22Chapitre 2
Les instructions du langage SQL
Dans la suite nous présentons une syntaxe simplifiée des instructions du langage SQL,
adaptée aux objectifs du cours. Le langage SQL est le standard utilisé pour la définition
du schéma d’une base de donnée et pour la manipulation des données.
2.1 Sites Web de référence pour SQL et MySQL
Une version complète de la syntaxe SQL DDL (Data Definition Language) se trouve,
par exemple, à l’adresse :
http://sqlpro.developpez.com/cours/sqlaz/ddl/
Pour consulter la syntaxe des instruction du SQL DML (Data Manipulation Language)
consultez les adresses suivantes :
http://sqlpro.developpez.com/cours/sqlaz/select/
http://sqlpro.developpez.com/cours/sqlaz/dml/
Le logiciel MySQL implémente le langage SQL, mais ne respecte pas toujours la
norme SQL. Sur le site de référence de MySQL se trouvent les instructions/commandes
pour la définition des données (l’implémentation du langage SQL DDL) :
http://dev.mysql.com/doc/refman/5.0/fr/data-definition.html
et pour la manipulation des données :
http://dev.mysql.com/doc/refman/5.0/fr/data-manipulation.html
2.2 Le langage SQL DDL (Data Definition Language)
Le langage SQL DDL offre des commandes de définition et de modification des struc-
tures permettant de définir (créer), de supprimer et de modifier une table, une colonne ou
une contrainte.
2.2.1 Création d’un schéma
Une base de données est définie par son schéma. Pour créer un schéma vide (sans
tables), le langage SQL propose l’instruction suivante :
23CREATE SCHEMA nom_schema
où nom schema est remplacé par le nom de la nouvelle base de données.
Sous MySQL la syntaxe pour créer le schéma d’une base de données est la suivante :
CREATE DATABASE nom_schema
où nom schema est remplacé par le nom de la nouvelle base de données.
Exemple 18. Pour créer en MySQL la base de données client commande il faut
écrire :
1 CREATE DATABASE client_commande
Cette opération produit une nouvelle BD, sans tables.
2.2.2 Création d’une table (CREATE TABLE)
Pour créer une table, le langage SQL propose l’instruction CREATE TABLE :
CREATE TABLE nom_table
( nom_colonne type,
nom_colonne type,
...
nom_colonne type )
Il faut spécifier le nom de la nouvelle table, nom table, ainsi que la description de ses
colonnes : pour chaque colonne il faut spécifier son nom, nom colonne, et le type de
ses valeurs. Sur les colonnes on peut ajouter des contraintes de colonne :
– pour définir une colonne obligatoire, il faut ajouter NOT NULL après sa définition ;
– pour définir une clé primaire, il faut ajouter PRIMARY KEY ;
– pour définir une clé étrangère, il faut ajouter
FOREIGN KEY REFERENCES table cible (colonne).
Cette opération produit une table vide (c’est-à-dire sans lignes).
Les colonnes et leurs types
SQL offre divers types de données, dites de base, possible pour une colonne d’une
table. On citera les principaux :
– smallint : entier signé court ;
– integer ou int : entier signé long ;
– numeric(p,q) : nombre décimaux de p chiffres dont q après le point décimal ;
si elle n’est pas mentionnée, la valeur de q est 0 ;
– decimal(p,q) : nombre décimaux d’au moins p chiffres dont q après le point
décimal ; si elle n’est pas mentionnée, la valeur de q est 0 ;
– float(p) ou float : nombre en virgule flottante ;
– character(p) ou char : chaı̂ne de longueur fixe de p caractères ;
– character varying ou varchar(p) : chaı̂ne de longueur variable de p ca-
ractères ;
24– date : date (année, mois et jour) ;
– time : instant (heure, minute, seconde, millième de seconde) ;
La norme SQL 3 (1999) a rajouté 3 types fondamentaux : booléen, CLOB et BLOB.
– boolean : type de données valant vrai ou faux ;
– les Binary Large Objects (BLOB) : sorte de contenants génériques pouvant accueillir
des chaı̂nes de bits de longueur non-bornée telles que des images, séquences vidéo,
séquences sonores ou musicales. Les Character Large Objects (CLOB) sont simi-
laires, mais considérés comme étant formés de caractères ; ce type est utilisé pour
stocker des textes de taille importante.
Exemple 19. Pour créer dans la base de données client commande la table client,
la commande MySQL est la suivante :
1 CREATE TABLE client
2 ( NCLI char(8) NOT NULL,
3 NOM char(18) NOT NULL,
4 ADRESSE char(24) NOT NULL,
5 LOCALITE char(20) NOT NULL,
6 CAT char(2) DEFAULT NULL,
7 COMPTE decimal(9,2) NOT NULL,
8 PRIMARY KEY (NCLI) )
Pour créer la table detail, la commande MySQL est la suivante :
1 CREATE TABLE detail
2 ( NCOM char(8) NOT NULL,
3 NPRO char(10) NOT NULL,
4 QCOM int(11) NOT NULL,
5 PRIMARY KEY (NCOM,NPRO)
6 FOREIGN KEY (NCOM) REFERENCES commande (NCOM),
7 FOREIGN KEY (NPRO) REFERENCES produit (NPRO) )
2.2.3 Suppression d’une table (DROP)
Pour supprimer une table, le langage SQL propose l’instruction suivante :
DROP nom_table
Attention : Toutes les données ainsi que la structure de la table seront perdues à la suite
de cette opération !
2.2.4 Modification du schéma
La modification du schéma d’une base de données implique le plus souvent des modi-
fications de données. Par exemple, l’ajout d’une colonne à une table contenant des lignes
est suivi de la modification de cette colonne pour chacune des lignes (mises à NULL ou à
la valeur par défaut). Pour pouvoir être appliquées, ces opérations de modification doivent
respecter les contraintes d’intégrité. Nous donnons quelques exemples de règles :
25• Ajout d’une colonne. Si la colonne est facultative, l’opération s’effectue sans con-
trainte. Si elle est obligatoire, alors la table doit être vide ou la colonne doit être
accompagnée d’une valeur par défaut.
• Suppression d’une colonne. Cette colonne ne peut pas intervenir dans la compo-
sition d’une clé primaire ou d’une clé étrangère. Si nécessaire, ces clés doivent
d’abord être modifiées ou supprimés.
• Ajout d’une clé primaire. Si la table n’est pas vide, les lignes doivent respecter la
contrainte d’unicité.
• Suppression d’une clé primaire. Cette suppression n’est pas soumise à des condi-
tions sur les données. Cependant, cette clé primaire ne doit pas être référencée par
une clé étrangère.
• Ajout d’une clé étrangère. Si la table n’est pas vide, les lignes doivent respecter la
contrainte référentielle.
Attention ! A cause de toutes ces règles, la modification du schéma d’une base de
données n’est pas une opération fréquente et s’il faut le faire alors il faut prendre des
précautions.
2.3 Le langage SQL DML (Data Manipulation Language)
Le langage SQL DML (Data Manipulation Language) comporte deux grandes classes
de fonctions : l’extraction de données et la modification de données.
2.3.1 Extraction de données
L’extration 1 de données fait l’objet d’une seule commande : la requête select.
Une requête select simple contient trois parties principales :
1. la clause select précise le nom des colonnes dont on veut récupérer les valeurs
dans le résultat de la requête,
2. la clause from indique la table ou les tables sur lesquelles portent la requête. Toutes
les colonnes de la clause select doivent appartenir à une des tables de la clause
from.
3. la clause where spécifie les conditions de sélection des valeurs du résultat de la
requête.
L’exécution d’une requête select produit un résultat qui est une table volatile car
ses lignes sont envoyées à l’écran, mais cette table n’est pas créée dans la base de données.
2.3.2 Extraction simple (SELECT-FROM)
La requête select la plus simple, appelée projection, n’a pas de clause where et
permet l’affichage de toutes les lignes d’une table, mais en ne montrant que certaines
1. Une donnée extraite reste dans la base de données, on en extrait une copie ! La commande delete
est utilisée pour extraire (effacer) une donnée.
26colonnes. Sa forme générale est :
SELECT liste_colonnes
FROM nom_table
Exemple 20. Pour la base de données client commande, la requête
1 SELECT NCLI, NOM, LOCALITE
2 FROM client
affiche pour toutes les lignes de la table client seulement les valeurs des trois colonnes
NCLI, NOM, et LOCALITE.
Pour obtenir les valeurs de toutes les colonnes, la requête est :
1 SELECT *
2 FROM client
2.3.3 Extraction de lignes sélectionnées (SELECT-FROM-WHERE)
Une requête de sélection contient dans la clause where des conditions qui permettent
de ne sélectionner que certaines lignes d’une table. Sa forme générale est :
SELECT liste_colonnes
FROM nom_table
WHERE condition
Exemple 21. Pour la base de données client commande, la requête
1 SELECT NCLI, NOM
2 FROM client
3 WHERE LOCALITE = ’ T o u l o u s e ’
n’affiche que les lignes de la table client dont la valeur de la colonne LOCALITE est
égale à la chaı̂ne de caractères ’Toulouse’. De plus, seules les valeurs des colonnes NCLI
et NOM seront affichées.
Conditions de sélection
Dans la clause where, pour construire la condition de sélection on dispose :
– des noms des colonnes de la table nom table ;
– des opérateurs du §1.4.2 ;
– des constantes :
• numériques et décimales, comme par exemple : 123, -0.003, 7.12 ;
• chaı̂nes de caractères : valeurs entre ’ et ’ (exemple : ’Jean Mercier’) ;
la présence du caractère ’ dans la chaı̂ne se représente par son redoublement
(exemple : ’rue de l’’Eté’) ;
• dates : ’2009-02-14’ (standard SQL 2) ; autres variantes selon les SGBD :
’14-02-2009’, ’14/02/2009’.
27Pour les expressions composées 2 l’usage des paranthèses permet de former des condi-
tions plus élaborées, comme par exemple :
1 SELECT NCLI, NOM
2 FROM client
3 WHERE COMPTE >0 AND (CAT = ’ C1 ’ OR LOCALITE = ’ P a r i s ’)
Conditions de sélection plus complexes
Une condition peut porter sur la présence de la valeur NULL :
1 CAT is null
2 CAT is not null
ou sur l’appartenance à un ensemble :
1 CAT in ( ’ C1 ’, ’ C2 ’, ’ C3 ’)
2 LOCALITE not in ( ’ T o u l o u s e ’, ’ Namur ’, ’ B r e d a ’)
ou encore sur la présence de certains caractères dans une valeur :
1 CAT like ’ 1 ’
2 ADDRESSE like ’%Neuve%’
Dans les deux dernières conditions, le signe ’ ’ désigne un caractère quelconque et ’%’
désigne toute suite de caractères, éventuellement vide.
Lignes dupliquées dans le résultat
Pour éliminer les lignes en double dans le résultat d’une requête, on utilise la clause
distinct
1 SELECT distinct LOCALITE
2 FROM client
Données extraites et données dérivées
La clause select permet aussi de spécifier des données calculées ou encore des
constantes. Dans l’exemple :
1 SELECT NPRO, ’ = ’, 0.196*PRIX*QSTOCK AS ” m o n t a n t TVA”
2 FROM produit
le résultat de la requête sera un tableau des montants TVA des articles en stock.
MySQL offre plusieurs fonctions permettant de dériver des valeurs à partir des valeurs des
colonnes des lignes extraites. Pour les chaı̂nes de caractères on peut utiliser, par exemple,
les fonctions : lower, upper, substring, trim 3 .
2. voir sur http://dev.mysql.com/doc/refman/5.0/fr/operator-precedence.
html, la priorité des opérateurs en MySQL
3. voir http://dev.mysql.com/doc/refman/5.0/en/string-functions.html
282.3.4 Ordre des lignes d’un résultat (clause ORDER BY)
Il est possible d’imposer un ordre de présentation spécifique lors de l’affichage des
lignes du résultat d’une requête en utilisant la clause order by :
SELECT liste_colonnes
FROM nom_table
WHERE condition
ORDER BY liste_colonnes ASC|DESC
Par défault, le classement se fait par ordre ascendant des valeurs. On peut également
spécifier explicitement un ordre ascendant (ASC) ou descendant (DESC).
Exemple 22. Pour la base de données client commande les lignes résultant de la
requête
1 SELECT *
2 FROM client
3 WHERE CAT is not null
4 ORDER BY LOCALITE
vont apparaı̂tre classées par ordre alphabétique croissant sur le noms des localités.
On peut indiquer plusieurs critères de tri :
1 SELECT *
2 FROM client
3 ORDER BY LOCALITE, CAT
Les clients vont apparaı̂tre classés par localité, puis dans chaque localité, classés par
catégorie.
L’ordre des composants du critère de tri est important. La requête
1 SELECT *
2 FROM client
3 ORDER BY CAT, LOCALITE
affiche les clients classés par catégorie, puis dans chaque catégorie, classés par localité.
2.3.5 Les fonctions agrégatives (ou statistiques)
Il existe des fonctions prédéfinies qui donnent une valeur “agrégée” calculée pour les
lignes sélectionnées par la requête select :
• count(*) compte le nombre de ligne trouvées,
• count(nom colonne) compte le nombre de valeurs de la colonne,
• avg(nom colonne) calcule la moyenne des valeurs de la colonne,
• sum(nom colonne) calcule la somme des valeurs de la colonne,
• min(nom colonne) calcule le minimum des valeurs de la colonne,
• max(nom colonne) calcule le maximum des valeurs de la colonne.
Il est à noter que ces fonctions, à l’exception de la première (count), ne considèrent que
les valeurs non NULL de la colonne. En outre, chaque valeur est prise en compte, même
si elle apparaı̂t plusieurs fois.
29Exemple 23. Pour la base de données client commande la requête
1 SELECT count(*)
2 FROM client
compte le nombre de clients, la requête
1 SELECT count(NCLI)
2 FROM commande
compte le nombre de commandes, la requête
1 SELECT count(distinct NCLI)
2 FROM commande
compte le nombre de clients ayant passé au moins une commande, et la requête
1 SELECT sum(QSTOCK*PRIX)
2 FROM produit
3 WHERE LIBELLE like ’%SAPIN%’
calcule le montant total de produits de type sapin en stock.
Attention : La requête
1 SELECT MAX(DATECOM)
2 FROM commande
affiche bien la date de la dernière commande enregistrée dans la table commande, mais
la requête
1 SELECT MAX(DATECOM), NCOM
2 FROM commande
est fausse car elle ne permet pas de récupérer le numéro de cette dernière commande ! La
solution est d’utiliser une sous-requête (voir aussi le §2.3.7) :
1 SELECT NCOM, DATECOM
2 FROM commande
3 WHERE DATECOM in (SELECT MAX(DATECOM)
4 FROM commande)
2.3.6 Extraction de données de plusieurs tables (jointure)
Pour extraire des données corrélées, stockées dans deux tables, on utilise une jointure
(join en anglais), définie par une condition de jointure, spécifiant la règle selon laquelle
les lignes des tables sont reliées :
SELECT liste_colonnes
FROM nom_table_E, nom_table_P
WHERE col_FK_E = col_PK_P
AND condition
Dans la clause FROM on donne la liste des noms des tables à relier.
Dans la clause WHERE on donne la condition de jointure qui se présente sous la forme
d’une égalité entre les valeurs de deux colonnes : col FK E = col PK P, où
30i) la colonne col FK E est la clé étrangère de la table nom table E (table enfant),
ii) la colonne col PK P est la clé primaire de la table nom table P (table parent),
et
iii) la table nom table P est la table parent référencée dans la table nom table E
par la clé étrangère col FK E.
Dans la clause WHERE, en plus de la condition de jointure (obligatoire !), on peut ajouter
d’autres conditions de sélection des valeurs dans la partie condition.
Exemple 24. Pour la base de données client commande, la requête
1 SELECT NCOM, DATECOM, NOM, LOCALITE
2 FROM commande, client
3 WHERE commande.NCLI = client.NCLI
affiche pour chaque commande de la table commande, le nom et la ville du client qui a
passé cette commande (voir la figure 2.1).
F IGURE 2.1 – Le résultat de la requête de l’exemple 24.
Les valeurs des colonnes NCOM et DATECOM sont extraites de la table commande
(table enfant) tandis que les valeurs des colonnes NOM et LOCALITE sont extraites de la
table client (table parent). La colonne commande.NCLI est une clé étrangère 4 de la
table commande et fait référence à la clé primaire client.NCLI de la table client.
Remarque 1 : Si les deux tables ont des colonnes qui ont le même nom, il faut le-
ver l’ambiguı̈té et préciser à quelle table appartient la colonne, en utilisant la syntaxe
suivante :
nom_table.nom_colonne
Remarque 2 : L’ordre des noms des tables dans la clause FROM ainsi que l’ordre des
conditions dans la clause WHERE n’a pas d’importance. La requête
1 SELECT NCOM, DATECOM, NOM, LOCALITE
2 FROM client, commande
3 WHERE client.NCLI = commande.NCLI
est la même que la requête de l’exemple 24 et que la requête suivante
4. notée FK3 dans l’exemple 11, page 17
311 SELECT NCOM, DATECOM, NOM, LOCALITE
2 FROM client, commande
3 WHERE commande.NCLI = client.NCLI
Le résultat d’une jointure entre deux tables est obtenu comme suit :
1. On construit une table (fictive) en couplant chaque ligne de la première table avec
chaque ligne de la seconde, sans prendre en compte la clause where. Si on lance la
requête de l’exemple 24 sur la base de données client commande contenant les
lignes données dans la figure 1.2, page 9, alors cette table fictive contient 9 colonnes
(3 colonnes de la table commande, plus 6 colonnes de la table client), et 112
lignes (112 = 7 x 16 : 7 lignes de la table commande, multiplié par 16 lignes de la
table client).
2. On sélectionne, parmi les lignes ainsi obtenues, celles qui vérifient la condition de
jointure. Pour l’exemple 24 on garde 7 lignes sur les 112.
3. On ne retient alors que les colonnes demandées. Quatre colonnes seront affichées
pour l’exemple 24.
Par extension, la jointure de trois tables réclamera deux conditions de jointure :
SELECT liste_colonnes
FROM nom_table_E, nom_table_P, nom_table_3
WHERE col_FK_E = col_PK_P
AND col_FK_E2 = col_PK_P2
AND condition
La deuxième condition de jointure, col FK E2 = col PK P2, spécifie la règle pour
relier la table nom table 3 à la table nom table E ou à la table nom table P.
Exemple 25. Pour la base de données client commande, la requête
1 SELECT NOM, commande.NCOM, commande.DATECOM, detail.NPRO, detail.QCOM
2 FROM client, commande, detail
3 WHERE client.NCLI = commande.NCLI
4 AND detail.NCOM = commande.NCOM
affiche pour chaque client et pour chaque commande qu’il a passé le numéro de produit
et la quantité commandé.
Pour avoir aussi le libellé du produit il faut faire une requête avec la jointure des
quatre tables en imposant trois conditions de jointure
1 SELECT client.NOM, commande.NCOM, commande.DATECOM, detail.NPRO,
2 detail.QCOM, produit.LIBELLE
3 FROM client, commande, detail, produit
4 WHERE client.NCLI = commande.NCLI
5 AND detail.NCOM = commande.NCOM
6 AND detail.NPRO = produit.NPRO
32Attention ! Une requête sans condition de jointure porte le nom de produit cartésien :
chaque ligne de la première table est couplée avec chaque ligne de la seconde table.
Si dans la requête de l’exemple 24 on oublie d’imposer la condition de jointure, alors la
requête
1 SELECT NCOM, DATECOM, NOM, LOCALITE
2 FROM commande, client
est le produit cartésien des deux tables.
Si on lance cette requête sur la BD client commande contenant les lignes données
dans la figure 1.2, page 9, alors les 7 lignes de la table commande seront reliées à chacune
des 16 lignes de la table client et le résultat de cette requête contient 112 lignes (112 =
7 × 16), ce qui, en général, n’a pas trop d’utilité.
2.3.7 Les sous-requêtes
Une sous-requête est une instruction select, cf. §2.3.3, qui intervient dans la clause
where d’une autre instruction select.
Exemple 26. Pour la base de données client commande, la requête
1 SELECT NCLI
2 FROM client
3 WHERE LOCALITE = ’ Namur ’
donne les identifiants des clients qui habitent à Namur. Elle est utilisée comme sous-
requête dans la requête
1 SELECT NCOM, DATECOM
2 FROM commande
3 WHERE NCLI in (SELECT NCLI
4 FROM client
5 WHERE LOCALITE = ’ Namur ’)
pour retrouver les commandes des clients qui habitent à Namur.
Exemple 27. Pour la base de données client commande, la requête
1 SELECT NOM, COMPTE
2 FROM client
3 WHERE COMPTE in (SELECT max(COMPTE)
4 FROM client)
affiche le nom et le compte du client qui a la plus grande valeur dans son compte.
Une sous-requête peut elle-même contenir une sous-requête.
Exemple 28. Pour la base de données client commande, la requête
1 SELECT NPRO
2 FROM detail
3 WHERE NCOM in (SELECT NCOM
4 FROM commande
5 WHERE NCLI in (SELECT NCLI
6 FROM client
7 WHERE LOCALITE = ’ Namur ’))
33donne les références des produits des commandes des clients qui habitent à Namur.
Si la sous-requête renvoie une seule ligne, il est permis d’utiliser les opérateurs de
comparaison classiques ; par exemple :
1 SELECT *
2 FROM client
3 WHERE COMPTE > (SELECT COMPTE
4 FROM client
5 WHERE NCLI = ’ C400 ’)
2.3.8 Sous-requête ou jointure ?
La jointure et la sous-requête permettent d’exprimer des conditions d’association entre
lignes, basées le plus souvent sur l’égalité des valeurs d’une clé étrangère avec celle d’une
clé primaire.
Exemple 29. La requête de l’exemple 26
1 SELECT NCOM, DATECOM
2 FROM commande
3 WHERE NCLI in (SELECT NCLI
4 FROM client
5 WHERE LOCALITE = ’ Namur ’)
peut s’écrire également sous la forme d’une jointure :
1 SELECT NCOM, DATECOM
2 FROM commande, client
3 WHERE commande.NCLI = client.NCLI
4 AND LOCALITE = ’ Namur ’
Exemple 30. La requête de l’exemple 28
1 SELECT NPRO
2 FROM detail
3 WHERE NCOM in (SELECT NCOM
4 FROM commande
5 WHERE NCLI in (SELECT NCLI
6 FROM client
7 WHERE LOCALITE = ’ Namur ’))
peut s’écrire également sous la forme d’une jointure :
1 SELECT NPRO
2 FROM detail,commande, client
3 WHERE commande.NCOM = detail.NCOM
4 AND commande.NCLI = client.NCLI
5 AND LOCALITE = ’ Namur ’
Attention : Les structures de select emboı̂tés qui utilisent des conditions de non-
association (not in) ne peuvent pas s’exprimer par une jointure !
34Vous pouvez aussi lire
