Chapitre 4 Langage SQL
Chapitre 4 Langage SQL
Chapitre 4 Langage SQL
4.1 INTRODUCTION
4.1.1 Présentation générale
Introduction
Le langage SQL (Structured Query Language) peut être considéré comme le langage d’accès
normalisé aux bases de données. Il est aujourd’hui supporté par la plupart des produits
commerciaux que ce soit par les systèmes de gestion de bases de données micro tel qu’Access ou
par les produits plus professionnels tels qu’Oracle. Il a fait l’objet de plusieurs normes ANSI/ISO
dont la plus répandue aujourd’hui est la norme SQL2 qui a été définie en 1992.
Le succès du langage SQL est dû essentiellement à sa simplicité et au fait qu’il s’appuie sur
le schéma conceptuel pour énoncer des requêtes en laissant le SGBD responsable de la stratégie
d’exécution. Le langage SQL propose un langage de requêtes ensembliste et assertionnel.
Néanmoins, le langage SQL ne possède pas la puissance d’un langage de programmation :
entrées/sorties, instructions conditionnelles, boucles et affectations. Pour certains traitements il est
donc nécessaire de coupler le langage SQL avec un langage de programmation plus complet.
De manière synthétique, on peut dire que SQL est un langage relationnel, il manipule donc
des tables (i.e. des relations, c’est-à-dire des ensembles) par l’intermédiaire de requêtes qui
produisent également des tables.
Historique rapide
– En 1970, E.F. CODD, directeur de recherche du centre IBM de San José, invente le modèle
relationnel qui repose sur une algèbre relationnelle. Ce modèle provoque une révolution
dans l’approche des bases des données.
– En 1977, création du langage SEQUEL (Structured English Query Language) et mise en
place du Système R, prototype de base de données reposant sur la théorie de CODD.
SEQUEL continue de s’enrichir pour devenir SQL (Structured Query Language).
– En 1981, la société ORACLE CORP lance la première version de son système de gestion
de base de données relationnelle (SGBDR), IBM sort SQL/DS et RTI lance INGRES.
– En 1982, IBM sort SQL/DS pour son environnement VM/CMS et l’ANSI (American
National Standard Institute) lance un projet de normalisation d’un langage relationnel.
– En 1983, IBM lance DB2 pour l’environnement MVS.
– En 1986, la société SYBASE lance son SGBDR conçu selon le modèle Client-Serveur.
– La première norme SQL (SQL-1) de l’ISO (International Standard Organisation) apparaît.
Il existe désormais plusieurs dizaines de produits proposant le langage SQL et tournant
sur des machines allant des micros aux gros systèmes.
– Depuis, les différents produits phares ont évolué, la norme SQL est passée à SQL-2,
puis SQL-3. SQL est désormais un langage incontournable pour tout SGBD moderne.
Par contre, bien qu’une norme existe, on assiste à une prolifération de dialectes propres à
chaque produit : soit des sous-ensembles de la norme (certaines fonctionnalités n’étant pas
implantées), soit des sur-ensembles (ajout de certaines fonctionnalités, propres à chaque
produit).
Oracle et Informix dominent le marché actuel, SQL-Server (de Microsoft) tente de s’imposer
dans le monde des PC sous NT. À côté de ces produits, très chers, existent heureusement des
1
Support de cours Base de Donnée
Engr. Mbelen Barnabé
Université Catholique Saint Jean Paul 2
Terminologie
Standard
Modèle relationnel
SQL
Français Anglais
Relation Relation Table
Domaine Domain Domaine
Attribut Attribute Colonne
n-uplet tuple Ligne
Clé primaire Primary key Primary key
2
Support de cours Base de Donnée
Engr. Mbelen Barnabé
Université Catholique Saint Jean Paul 2
Le langage de protections d’accès (ou Data Control Language, soit DCL en anglais) s’occupe
de gérer les droits d’accès aux tables. Les instructions du DCL sont : GRANT, REVOKE.
Langage de contrôle de transaction
bbLe langage de contrôle de transaction (ou Transaction Control Language, soit TCL en anglais)
gère les modifications faites par le LMD, c’est-à-dire les caractéristiques des transactions et la
validation et l’annulation des modifications. Les instructions du TCL sont : COMMIT, SAVEPOINT,
ROLLBACK, SET TRANSACTION
SQL intégré
Le SQL intégré (Embedded SQL) permet d’utiliser SQL dans un langage de troisième géné-
ration (C, Java, Cobol, etc.) :
– déclaration d’objets ou d’instructions ;
– exécution d’instructions ;
– gestion des variables et des curseurs ;
– traitement des erreurs.
Les instructions du SQL intégré sont : DECLARE, TYPE, DESCRIBE, VAR, CONNECT,
PREPARE, EXECUTE, OPEN, FETCH, CLOSE, WHENEVER.
4.1.3 PostgreSQL
Les systèmes traditionnels de gestion de bases de données relationnelles (SGBDR) offrent
un modèle de données composé d’une collection de relations contenant des attributs relevant
chacun d’un type spécifique. Les systèmes commerciaux gèrent par exemple les nombres décimaux,
les entiers, les chaînes de caractères, les monnaies et les dates. Il est communément admis que ce
modèle est inadéquat pour les applications de traitement de données de l’avenir car, si le modèle
relationnel a remplacé avec succès les modèles précédents en partie grâce à sa « simplicité spartiate
», cette dernière complique cependant l’implémentation de certaines applications. PostgreSQL
apporte une puissance additionnelle substantielle en incorporant les quatre concepts de base suivants
afin que les utilisateurs puissent facilement étendre le système : classes, héritage, types, fonctions.
D’autres fonctionnalités accroissent la puissance et la souplesse : contraintes, déclencheurs, règles,
intégrité des transactions. Ces fonctionnalités placent PostgreSQL dans la catégorie des bases de
données relationnelles objet. Ne confondez pas cette catégorie avec celle des serveurs d’objets qui ne
tolère pas aussi bien les langages traditionnels d’accès aux SGBDR. Ainsi, bien que PostgreSQL
possède certaines fonctionnalités orientées objet, il appartient avant tout au monde des SGBDR. C’est
essentiellement l’aspect SGBDR de PostgreSQL que nous aborderons dans ce cours. L’une des
principales qualités de PostgreSQL est d’être un logiciel libre, c’est-à-dire gratuit et dont les sources
sont disponibles. Il est possible de l’installer sur les systèmes Unix/Linux et Win32. PostgreSQL
fonctionne selon une architecture client/serveur, il est ainsi constitué :
– d’une partie serveur, c’est-à-dire une application fonctionnant sur la machine hébergeant la base
de données (le serveur de bases de données) capable de traiter les requêtes des clients ; il s’agit dans
le cas de PostgreSQL d’un programme résident en mémoire appelé postmaster ;
– d’une partie client (psql) devant être installée sur toutes les machines nécessitant d’accéder au
serveur de base de données (un client peut éventuellement fonctionner sur le serveur lui-même). Les
3
Support de cours Base de Donnée
Engr. Mbelen Barnabé
Université Catholique Saint Jean Paul 2
clients (les machines sur lesquelles le client PostgreSQL est installé) peuvent interroger le serveur de
bases de données à l’aide de requêtes SQL.
4.2 Définir une base – Langage de définition de données (LDD)
4.2.1 Introduction aux contraintes d’intégrité
Soit le schéma relationnel minimaliste suivant :
– Acteur(Num-Act, Nom, Prénom)
– Jouer(Num-Act, Num-Film)
– Film(Num-Film, Titre, Année)
Contrainte d’intégrité de domaine
Toute comparaison d’attributs n’est acceptée que si ces attributs sont définis sur le même
domaine. Le SGBD doit donc constamment s’assurer de la validité des valeurs d’un attribut.
C’est pourquoi la commande de création de table doit préciser, en plus du nom, le type de
chaque colonne.
Par exemple, pour la table Film, on précisera que le Titre est une chaîne de caractères et
l’Année une date. Lors de l’insertion de n-uplets dans cette table, le système s’assurera que
les différents champs du n-uplet satisfont les contraintes d’intégrité de domaine des attributs
précisées lors de la création de la base. Si les contraintes ne sont pas satisfaites, le n-uplet n’est,
tout simplement, pas inséré dans la table.
Contrainte d’intégrité de table (ou de relation ou d’entité)
Lors de l’insertion de n-uplets dans une table (i.e. une relation), il arrive qu’un attribut soit
inconnu ou non défini. On introduit alors une valeur conventionnelle notée NULL et appelée
valeur nulle.
Cependant, une clé primaire ne peut avoir une valeur nulle. De la même manière, une clé
primaire doit toujours être unique dans une table. Cette contrainte forte qui porte sur la clé
primaire est appelée contrainte d’intégrité de relation.
Tout SGBD relationnel doit vérifier l’unicité et le caractère défini (NOT NULL) des valeurs
de la clé primaire. Contrainte d’intégrité de référence
Dans tout schéma relationnel, il existe deux types de relation :
– les relations qui représentent des entités de l’univers modélisé ; elles sont qualifiées de
statiques, ou d’indépendantes ; les relations Acteur et Film en sont des exemples ;
– les relations dont l’existence des n-uplets dépend des valeurs d’attributs situées dans d’autres
relations ; il s’agit de relations dynamiques ou dépendantes ; la relation Jouer en est un exemple.
Lors de l’insertion d’un n-uplet dans la relation Jouer, le SGBD doit vérifier que les valeurs
Num-Act et Num-Film correspondent bien, respectivement, à une valeur de Num-Act existant
dans la relation Acteur et une valeur Num-Film existant dans la relation Film.
Lors de la suppression d’un n-uplet dans la relation Acteur, le SGBD doit vérifier qu’aucun
n-uplet de la relation Jouer ne fait référence, par l’intermédiaire de l’attribut Num-Act, au nuplet que
l’on cherche à supprimer. Le cas échéant, c’est-à-dire si une, ou plusieurs, valeur
correspondante de Num-Act existe dans Jouer, quatre possibilités sont envisageables :
– interdire la suppression ;
4
Support de cours Base de Donnée
Engr. Mbelen Barnabé
Université Catholique Saint Jean Paul 2
5
Support de cours Base de Donnée
Engr. Mbelen Barnabé
Université Catholique Saint Jean Paul 2
PRIMARY KEY : Désigne l’attribut comme clé primaire de la table. La clé primaire étant
unique,
cette contrainte ne peut apparaître qu’une seule fois dans l’instruction. La définition
d’une clé primaire composée se fait par l’intermédiaire d’une contrainte de table. En fait,
la contrainte PRIMARY KEY est totalement équivalente à la contrainte UNIQUE NOT
NULL.
REFERENCES table [(colonne)] [ON DELETE CASCADE] : Contrainte d’intégrité
référentielle
pour l’attribut de la table en cours de définition. Les valeurs prises par cet attribut doivent
exister dans l’attribut colonne qui possède une contrainte PRIMARY KEY ou UNIQUE dans
la table table. En l’absence de précision d’attribut colonne, l’attribut retenu est celui
correspondant à la clé primaire de la table table spécifiée.
CHECK (condition) : Vérifie lors de l’insertion de n-uplets que l’attribut réalise la condition
condition.
DEFAULT valeur : Permet de spécifier la valeur par défaut de l’attribut.
Contraintes de table
Les différentes contraintes de table que l’on peut déclarer sont les suivantes :
PRIMARY KEY (colonne, ...) : Désigne la concaténation des attributs cités comme clé
primaire de la table. Cette contrainte ne peut apparaître qu’une seule fois dans l’instruction.
UNIQUE (colonne, ...) : Désigne la concaténation des attributs cités comme clé secondaire
de la table. Dans ce cas, au moins une des colonnes participant à cette clé secondaire doit
permettre de distinguer le n-uplet. Cette contrainte peut apparaître plusieurs fois dans
l’instruction.
FOREIGN KEY (colonne, ...) REFERENCES table [(colonne, ...)]
[ON DELETE CASCADE | SET NULL] : Contrainte d’intégrité référentielle pour un
ensemble d’attributs de la table en cours de définition. Les valeurs prises par ces attributs
doivent exister dans l’ensemble d’attributs spécifié et posséder une contrainte PRIMARY
KEY ou UNIQUE dans la table table.
CHECK (condition) : Cette contrainte permet d’exprimer une condition qui doit exister entre
plusieurs attributs de la ligne.
Les contraintes de tables portent sur plusieurs attributs de la table sur laquelle elles sont
définies. Il n’est pas possible de définir une contrainte d’intégrité utilisant des attributs
provenant de deux ou plusieurs tables. Ce type de contrainte sera mis en œuvre par
l’intermédiaire de déclencheurs de base de données (trigger, cf. section ??).
Complément sur les contraintes
ON DELETE CASCADE : Demande la suppression des n-uplets dépendants, dans la table en
cours de définition, quand le n-uplet contenant la clé primaire référencée est supprimé dans la
table maître.
ON DELETE SET NULL : Demande la mise à NULL des attributs constituant la clé
étrangère qui font référence au n-uplet supprimé dans la table maître. La suppression d’un n-
7
Support de cours Base de Donnée
Engr. Mbelen Barnabé
Université Catholique Saint Jean Paul 2
uplet dans la table maître pourra être impossible s’il existe des nuplets dans d’autres tables
référençant cette valeur de clé primaire et ne spécifiant pas l’une de
ces deux options.
4.2.4 Supprimer une table : DROP TABLE
Supprimer une table revient à éliminer sa structure et toutes les données qu’elle contient.
Les index associés sont également supprimés.
La syntaxe est la suivante :
DROP TABLE nom_table
4.2.5 Modifier une table : ALTER TABLE
Ajout ou modification de colonne
ALTER TABLE nom_table {ADD/MODIFY} ([nom_colonne type [contrainte], ...])
Ajout d’une contrainte de table
ALTER TABLE nom_table ADD [CONSTRAINT nom_contrainte] contrainte
La syntaxe de déclaration de contrainte est identique à celle vue lors de la création de table.
Si des données sont déjà présentes dans la table au moment où la contrainte d’intégrité est
ajoutée, toutes les lignes doivent vérifier la contrainte. Dans le cas contraire, la contrainte
n’est pas posée sur la table.
Renommer une colonne
ALTER TABLE nom_table RENAME COLUMN ancien_nom TO nouveau_nom
Renommer une table
ALTER TABLE nom_table RENAME TO nouveau_nom
4.3 Modifier une base – Langage de manipulation de données (LMD)
4.3.1 Insertion de n-uplets : INSERT INTO
La commande INSERT permet d’insérer une ligne dans une table en spécifiant les valeurs à
insérer. La syntaxe est la suivante :
INSERT INTO nom_table(nom_col_1, nom_col_2, ...)
VALUES (val_1, val_2, ...)
La liste des noms de colonne est optionnelle. Si elle est omise, la liste des colonnes sera par
défaut la liste de l’ensemble des colonnes de la table dans l’ordre de la création de la table. Si
une liste de colonnes est spécifiée, les colonnes ne figurant pas dans la liste auront la valeur
NULL.
Il est possible d’insérer dans une table des lignes provenant d’une autre table. La syntaxe
est la suivante :
INSERT INTO nom_table(nom_col1, nom_col2, ...)
SELECT ...
8
Support de cours Base de Donnée
Engr. Mbelen Barnabé
Université Catholique Saint Jean Paul 2
Le SELECT (cf. section 4.5 et 4.7) peut contenir n’importe quelle clause sauf un ORDER BY
(cf. section 4.5.6).
4.3.2 Modification de n-uplets : UPDATE
La commande UPDATE permet de modifier les valeurs d’une ou plusieurs colonnes, dans
une ou plusieurs lignes existantes d’une table. La syntaxe est la suivante :
UPDATE nom_table
SET nom_col_1 = {expression_1 | ( SELECT ...) },
nom_col_2 = {expression_2 | ( SELECT ...) },
...
nom_col_n = {expression_n | ( SELECT ...) }
WHERE predicat
Les valeurs des colonnes nom_col_1, nom_col_2, ..., nom_col_n sont modifiées dans
toutes les lignes qui satisfont le prédicat predicat. En l’absence d’une clause WHERE, toutes
les lignes sont mises à jour. Les expressions expression_1, expression_2, ..., expression_n
peuvent faire référence aux anciennes valeurs de la ligne.
4.3.3 Suppression de n-uplets : DELETE La commande DELETE permet de supprimer des
lignes d’une table. La syntaxe est la suivante :
DELETE FROM nom_table
WHERE prédicat
Toutes les lignes pour lesquelles prédicat est évalué à vrai sont supprimées. En l’absence
de clause WHERE, toutes les lignes de la table sont supprimées.
9
Support de cours Base de Donnée
Engr. Mbelen Barnabé