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. 2
Table 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 3
2.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 4
6 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 5
6
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 7
1.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. 8
table client table commande table produit table detail F IGURE 1.2 – Les lignes de la base de données client commande à un instant donné. 9
1.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. 10
table 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é. 11
1.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). 12
1.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 égal
1.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. 14
Exemple 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 15
On 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 16
repré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). 18
1.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. 19
Exemple 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. 20
1.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. 21
1.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/ 22
Chapitre 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 : 23
CREATE 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. 26
colonnes. 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’. 27
Pour 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 28
2.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. 29
Exemple 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ù 30
i) 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 31
1 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 32
Attention ! 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 ’)) 33
donne 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 ! 34
Vous pouvez aussi lire