Vous êtes sur la page 1sur 41

Architecture client serveur – Exposé : Langage SQL

Plan
Introduction………………………………………………………… 02
I. Historique………………………………………………………. 03

II. Normes SQL…………………………………………………….. 04

III. Structure du langage…………………………………………… 06

IV. Commandes SQL……………………………………………… 08

V. Comparaison des fonctions SQL sur quelques systèmes de


gestion de bases de données relationnelles…………………… 27

Conclusion…………………………………………………………… 33

Références…………………………………………………………… 39

Page 1
Architecture client serveur – Exposé : Langage SQL

Introduction
Devant l’accroissement des collectes d’informations électroniques en vue de diverses
exploitations, il devenait urgent de mettre en place un système capable d’organiser et de
stocker un nombre considérable d’informations.

En 1970, ce besoin a été vécu dans les laboratoires d’IBM et a donné naissance à un
système capable d’entretenir les fichiers contenant les informations tout en masquant les
détails complexes et fastidieux liés à leurs gestions, permettant ainsi à l’utilisateur
d’accéder simplement aux informations via un langage d’interrogation. Cette première
étape a introduit de nouvelles notions comme les bases de données, le modèle relationnel
et le système de gestion de base de données.

Par la suite diverses sociétés ont proposé leur solution de gestion des données, leur langage
pour l’extraction des données.

Le langage SQL (Structured Query Language) (Langage de requêtes Structuré) est le fruit
d’années de réflexion sur la problématique de manipulation des données. Formalisé et
normalisé, il est né dans les années 1980 et a été rapidement adopté par la majorité des
éditeurs. Ses dernières normalisations l’ont fait s’orienter vers ce que l’on appelle
désormais le relationnel objet, c’est-à-dire l’introduction de certains principes de la
programmation objet au sein des bases de données relationnelles.

La normalisation laisse la possibilité aux producteurs de systèmes de gestion de bases de


données (SGBD) d'y ajouter des instructions spécifiques et non normalisées. En raison de
cette possibilité, ainsi que de l'évolution de la norme au cours des années, les éditeurs de
SGBD ajoutent souvent des possibilités avant que celle-ci fassent objet de normes, ce qui
provoque des variations dans la compréhension et l'interprétation qui est faite d'un code
source en SQL par les différents logiciels de SGBD.

Après un bref historique du langage SQL, nous donnerons des syntaxes de quelques
commandes pour aboutir à une comparaison de certaines fonctions dans des SGBD.

Page 2
Architecture client serveur – Exposé : Langage SQL

I. Historique

Comme beaucoup de technologies de l’informatique aujourd’hui matures, les bases de


données relationnelles sont nées des travaux d’IBM entre les années 1960 et 1970. De
nombreuses recherches ont été menées au cours de cette période sur des modèles de
données hiérarchiques, réseaux et relationnels. Le relationnel a été unanimement adopté
par la suite et programmé à l’aide du langage SQL.

La théorie sur laquelle repose SQL a été énoncée par le professeur Edgar Frank Codd
(1924-2003), un mathématicien d’Oxford, alors qu’il travaillait comme chercheur pour
IBM au laboratoire de San Jose. L’article « A relational model of data for large shared data
banks », publié en juin 1970 dans la revue Association for Computing Machinery, fait
toujours office de référence et a initié tous les travaux qui ont suivi et qui perdurent.

Codd voulait créer un système où l’interrogation des données utilisait le vocable anglais.
Les travaux de la NASA (National Aeronautics and space Adminstration) (Administration
Nationale de l’aéronautique et de l’espace), sur la base de données modélisant les rochers
rapportés du voyage sur la lune, a aidé au développement de ce langage en lui donnant de
la crédibilité.

Dès 1974, IBM entamait un prototype de bases de données relationnelles appelé System/R.
Ce projet se termina en 1979, prouvant ainsi la viabilité d’un tel système. Le langage de
programmation utilisé par IBM pour System/R fut appelé SEQUEL (Structured English
Query Language) rebaptisé par la suite SQL (Structured Query Language).
Comme tout langage, SQL a eu ses concurrents, le plus connu fut QUEL du SGBD Ingres
du début des années 1980.

Page 3
Architecture client serveur – Exposé : Langage SQL

II. Normes SQL


Le langage SQL est normalisé depuis 1986. Cette norme s’est enrichie au fil du temps
(publication X3.135-1986 de l’ANSI reprise par l’ISO peu de mois après : ISO 9075-
1987).

Cette première mouture, appelée SQL86 ou SQL1 (une centaine de pages), était le résultat
de compromis entre constructeurs, mais fortement influencée par le dialecte d’IBM.

En 1989, d’importantes mises à jour furent faites en matière d’intégrité référentielle (ANSI
X3.135-1989 et ISO/IEC 9075:1989).

La deuxième norme (appelée SQL92 ou SQL2 d’un volume d’environ 600 pages) fut
finalisée en 1992. Elle définissait quatre niveaux de conformité : le niveau d’entrée (entry
level), les niveaux intermédiaires (transitional et intermediate levels) et le niveau supérieur
(full level). Les langages SQL des principaux éditeurs sont tous conformes au premier
niveau et ont beaucoup de caractéristiques relevant des niveaux supérieurs.

Les groupes de travail X3H2 de l’ANSI et WG3 de l’ISO se penchèrent, à partir de 1993,
sur les extensions à apporter à la précédente norme. Les optimistes prévoyaient SQL3 pour
1996… Rien ne se passa comme prévu. Il fallut attendre 1999 pour voir établir le projet «
SQL:1999 » appelé communément SQL3 (volume de 1 600 pages à l’époque). Ce retard
fut probablement dû aux difficultés des nombreux protagonistes (Oracle, IBM, Microsoft,
Digital, Computer Associates, etc.) à remettre en cause leur mode de pensée, et aux risques
qu’ils pressentaient de ne pouvoir assurer la compatibilité des bases de leurs clients.

Les évolutions de l’ancienne norme ne sont pas limitées aux seules extensions objet. Bien
d’autres mécanismes ont été introduits dans ce projet (géographie, temps, réel, séries
temporelles, multimédia, OLAP, données et routines externes).
SQL:1999 est désormais une norme (au sens International Standard de l’ISO) qui apparaît
dans le domaine Information technology – Database languages – SQL. Elle porte
principalement la référence ISO/IEC 9075.

Peu après, une nouvelle version de SQL (SQL:2003), apportant des modifications
mineures, apparut. Ses apports concernent l’auto-incrément des clés, de nouvelles
fonctions dites analytiques, les colonnes calculées, l’ordre MERGE combinant UPDATE et
INSERT et surtout un support complet de XML.

Page 4
Architecture client serveur – Exposé : Langage SQL

Depuis 2006, des modules ont été révisés et publiés, mais il n’y a pas encore à proprement
parler de norme.

La norme internationale SQL est passée par un certain nombre de révisions :

Année Nom Appellation Commentaires

SQL-86 ou
1986 ISO/CEI 9075:1986 Édité par l'ANSI puis adopté par l'ISO en1987.
SQL-87

SQL-89 ou
1989 ISO/CEI 9075:1989 Révision mineure.
SQL-1

SQL-92 ou
1992 ISO/CEI 9075:1992 Révision majeure.
SQL2

Expressions régulières, requêtes récursives,


déclencheurs, types non-scalaires et quelques
SQL-99 ou
1999 ISO/CEI 9075:1999 fonctions orientées objet (les deux derniers points
SQL3
sont quelque peu controversés et pas encore
largement implémentés).

Introduction de fonctions pour la manipulation


XML, « window functions », ordres standardisés et
2003 ISO/CEI 9075:2003 SQL:2003
colonnes avec valeurs auto-produites (y compris
colonnes d'identité).

Ajout de quelques fonctions de fenêtrage (ntile,


lead, lag, first value, last value, nth value),
2008 ISO/CEI 9075:2008 SQL:2008 limitation du nombre de ligne (OFFSET / FETCH),
amélioration mineure sur les types distincts,
curseurs et mécanismes d'auto incréments.

III. Structure du langage SQL


Page 5
Architecture client serveur – Exposé : Langage SQL

SQL est un langage composé de deux parties bien distinctes et, dans ces deux parties, de
diverses subdivisions.

La première partie de SQL est constituée de la partie déclarative du langage, c’est-à-dire


d’ordres SQL que le SGBDR doit exécuter. En d’autres termes, on spécifie ce que l’on
veut obtenir ou faire, et c’est la machine qui décide comment elle doit l’exécuter.

La seconde partie est constituée d’un langage plus classique de type procédural dans lequel
on retrouve les notions de fonctions, méthodes, procédures, etc.

III.1 SQL déclaratif

La partie déclarative de SQL est, elle-même, subdivisée en quatre parties :

• Le DDL (Data Definition Language) ou LDD (Langage de Définition de Données), c’est-


à-dire les ordres SQL permettant de créer (CREATE), modifier (ALTER) ou supprimer
(DROP) les objets de la base.
Les instructions de manipulation des objets de la base - description de la structure,
l'organisation et les caractéristiques de la base de données - commencent avec les mots clés
CREATE, ALTER ou DROP qui correspondent aux opérations d'ajouter, modifier ou
supprimer un objet. Ces mots clés sont immédiatement suivis du type de l’objet à
manipuler - TABLE, VIEW, INDEX, …

• Le DML (Data Manipulation Language) ou LMD (Langage de Manipulation de


Données), c’est-à-dire les ordres SQL permettant d’ajouter (INSERT), de modifier
(UPDATE), de supprimer (DELETE) ou d’extraire des données (SELECT).
Les instructions de manipulation du contenu de la base de données commencent par les
mots clés SELECT, UPDATE, INSERT ou DELETE qui correspondent respectivement aux
opérations de recherche de contenu, modification, ajout et suppression. Divers mots clés
tels que FROM, JOIN et GROUP permettent d'indiquer les opérations d'algèbre
relationnelle à effectuer en vue d'obtenir le contenu à manipuler.
Page 6
Architecture client serveur – Exposé : Langage SQL

• Le DCL (Data Control Language) ou LCD (Langage de Contrôle de Données), c’est-à-


dire les ordres SQL permettant de définir les privilèges afférents aux utilisateurs (GRANT,
REVOKE).
Les mots clés GRANT et REVOKE permettent d'autoriser des opérations à certaines
personnes, d'ajouter ou de supprimer des autorisations.

• Enfin, le TCL (Transaction Control Language) ou LCT (Langage de Contrôle des


Transactions) permet de gérer des transactions englobant des ordres des trois premières
subdivisions. Les mots clés COMMIT et ROLLBACK permettent de confirmer ou annuler
l'exécution de transactions.

III.2 SQL procédural

• PSM (Persistent Stored Module) : concerne les fonctions, procédures, méthodes et


déclencheurs (triggers) en tant qu’objets de la base (donc stockés dans la base et par
conséquent persistants).

• CLI (Call Level Interface) : en fait, des « API » destinées à piloter des objets encapsulant
des données dans des langages hôtes par l’intermédiaire, la plupart du temps, d’un
middleware (BDE, dbExpress de Borland, OBDC, ADO, OleDB de Microsoft,
JDBC, etc.).

• Embedded SQL : le lancement d’ordres SQL depuis un langage hôte et la récupération


des données dans un programme via l’utilisation de CURSOR.

Page 7
Architecture client serveur – Exposé : Langage SQL

IV. Les commandes SQL


IV.1. Les commandes DDL (Data Definition Language)

Les commandes CREATE, ALTER, DROP, RENAME permettent de définir et de


modifier la structure de la base de données.

IV.1.1 Création de base de données


Une base de données dans le SGBD SQL Server contient au minimum :
– un fichier de données principal (d’extension .mdf) où sont stockées les données ;
– un journal des transactions (d’extension .ldf) où sont répertoriées toutes les transactions.
Lorsque l’on crée une base, il faut donc préciser le nom, l’emplacement et la taille de ces
deux fichiers.
Exemple : créons une base de données nommé "test"
CREATE DATABASE test -- le nom de la base
ON PRIMARY -- le fichier de données principal
(
NAME = test_data, -- nom logique
FILENAME = ’C:\Data\test.mdf’, -- emplacement et nom du fichier
SIZE = 60MB, -- taille de départ
MAXSIZE = 70MB, -- taille maximale
FILEGROWTH = 1MB -- increment
)
LOG ON -- le journal
( NAME = test_log,
FILENAME = ’D:\Log\test.ldf’,
SIZE = 15MB,
MAXSIZE = 20MB,
FILEGROWTH = 1MB
)

IV.1.2 Création de table


SQL permet de créer des relations sous des tables d’une base de données existante et de
définir lors de la création les contraintes d’intégrité sur les attributs.
La commande de création permet de spécifier le nom de la table et de définir les éléments
de table correspondant aux colonnes et aux contraintes.

Page 8
Architecture client serveur – Exposé : Langage SQL

CREATE TABLE <nom-table> (colonne [, colonne…] [, contrainte-de-relation] [,


contrainte-de-relation …])
Colonne = nom-colonne type de données [défaut] [contrainte-de-colonne]

<nom de table>, nom-colonne :


- chaîne de caractères (donc doit commencer par une lettre) simple, ou composé (un
nom de schéma suivi d’un nom de table)
Type de données : chaîne de caractère de longueur fixe ou variable, numérique, date.
- chaîne de caractère de longueur fixe (sensible à la casse)
CHAR (<longueur>) [BYTE| CHAR] | NCHAR (<longueur>) la valeur par défaut
étant de longueur 1)
- chaîne de caractère de longueur variable (sensible à la casse)
VARCHAR2 (<longueur>) [BYTE | CHAR | NVARCHAR2 (<longueur>)
longueur obligatoire.
LONG
- Numérique
Les numériques exacts (NUMBER et DECIMAL avec précision, INTEGER et
SMALLINT)
Les numériques approchés (FLOAT, REAL et DOUBLE PRECISION)
- Date
DATE : toute date valide
Défaut : DEFAULT val
val peut être :
- Littéral
- Expression
- Fonction SQL
Contrainte-de-colonne : contrainte d’intégrité (CI) et CI-réf portant sur un seul attribut
[CONSTRAINT contrainte]
{ [NOT] NULL
|UNIQUE
|PRIMARY KEY
|REFERENCES [schéma.] nom-table [(nom-col)][ON DELETE CASCADE]
|CHECK (condition)
}
[DISABLE]
Contrainte-de-relation: CI et CI-réf portant sur une ou plusieurs colonnes
[CONSTRAINT contrainte]

Page 9
Architecture client serveur – Exposé : Langage SQL

{ UNIQUE (nom-col [, nom-col…]


|PRIMARY KEY (nom-col [, nom col])
|FOREIGN KEY (nom-col [, nom col])
REFERENCES [schéma.] nom-table [(nom-col [, nom-col…)][ON DELETE
CASCADE]
|CHECK (condition)
} [DISABLE]
Contraintes
NOT NULL : valeur NULL impossible
- uniquement en contrainte de colonne
PRIMARY KEY : attribut(s) constituant la clé primaire
- La valeur NULL n’est pas autorisée sur les attributs de la clé primaire, il est
donc inutile de rajouter la contrainte NOT NULL
- Si plusieurs attributs, alors obligatoirement contrainte de relation
UNIQUE : attribut(s) dont la valeur est unique pour toute la table
- NULL est autorisé sauf si on précise le contraire (contrainte NOT NULL
explicitement demandée)
- Si la valeur NULL est autorisée, plusieurs lignes peuvent avoir la valeur NULL sur
cet attribut (unicité pour le NULL non vérifiée)
- Si plusieurs attributs, alors obligatoirement contrainte de relation
FOREIGN KEY: attribut(s) constituant une clé étrangère
- NULL accepté
- REFERENCES: la précision d’attributs est optionnelle si identique aux attributs
référencés
- Si plusieurs attributs, alors obligatoirement contrainte de relation
CHECK (condition) : la condition peut être vérifiée avec
- Nom-col θ val, θ peut être {=, <>, <, ≤, >, ≥}
- Prédicat d’intervalle : BETWEEN … AND…
- Prédicat de comparaison de texte : LIKE
- Test de nullité : NULL
- Test d’appartenance : IN
- Interdit : référence à des pseudo colonnes (CURRVAL, NEXTVAL, …), appel à
certaines fonctions (SYSDATE, …), requêtes à des valeurs d’autres lignes
Activation des contraintes
ENABLE : contrainte active (par défaut), toutes les données doivent la vérifier
DISABLE : contrainte inactive

Page 10
Architecture client serveur – Exposé : Langage SQL

Exemple
 COMMANDE (NUM, CNOM, PNOM, QTE)
 PRIX (PNOM, FNOM, COUT)
 FOURNISSEUR (ID, FNOM, VILLE, SEXE, EMAIL)
CREATE TABLE COMMANDE
(NUM INT UNIQUE,
CNOM CHAR(20) NOT NULL,
PNOM CHAR(20) NOT NULL,
QTE DEC (7,2)
) ; 
CREATE TABLE PRIX
(PNOM CHAR(20) NOT NULL,
FNOM CHAR(20) NOT NULL,
COUT INT
) ;
CREATE TABLE FOURNISSEUR
(ID INT PRIMARY KEY,
FNOM VARCHAR(20) NOT NULL,
VILLE CHAR(20),
SEXE CHAR(20)
CONSTRAINT CK_SEXE CHECK (SEXE ='Masculin' OR SEXE = 'Féminin'),
EMAIL VARCHAR(50) NOT NULL UNIQUE,
CONSTRAINT CK_EMAIL CHECK (EMAIL LIKE ('%@%.%'))
) ;

IV.1.3 Modification de table


ALTER TABLE nom-table {clause-add | clause-modify | clause-drop…}
Clause-add : Ajout d’attribut (s) et / ou de contrainte(s)
ADD (colonne | contrainte-de-relation [colonne | contrainte-de-relation…])
Clause-modify : Permet de modifier le type, la taille et la valeur par défaut d’un attribut
MODIFY (nom-col [type] [DEFAULT expr] [NULL | NOT NULL] …)
Clause-drop : Suppression de la vérification de la contrainte et de son stockage dans le
dictionnaire des données.

Page 11
Architecture client serveur – Exposé : Langage SQL

DROP [PRIMARY KEY | UNIQUE (nom-col [, nom-col…]) | CONSTRAINT contrainte]


[CASCADE]
CASCADE : suppressions en cascades des CI qui dépendent de la CI supprimée (clés
étrangères par exemple)
IV.1.4 Suppression de table
DROP TABLE nom-table [CASCADE CONSTRAINTS]
Supprime la table du dictionnaire et toutes les lignes, index, blocs physiques, vues…
CASCADE CONSTRAINTS : pour demander la suppression de toutes les contraintes dans
les autres tables de la base qui font référence à la clé primaire et aux clés uniques de la
table supprimée ; si on ne précise pas CASCADE et s’il y a des références, alors message
d’erreur.
IV.1.5 Renommage de table
RENAME ancien_nom TO nouveau_nom
Tous les liens sont mis à jour
IV.1.6 Définition de vues
SQL permet de définir les vues au niveau des schémas.
Une vue est une table virtuelle calculée à partir des tables de base par une question.
CREATE [OR REPLACE] [FORCE | NOFORCE] VIEW view [(alias [, alias] …]
AS subquery
[WITH CHECK OPTION [CONSTRAINT contrainte]]
[WITH READ ONLY]
La vue est supprimée par la commande DROP VIEW view

IV.2 Les commandes DML (Data Manipulation Language)


Les commandes SELECT, INSERT, UPDATE, DELETE permettent la sélection et
la mise à jour des données de la base.

IV.2.1 SELECT: Forme Générale


 SELECT <liste de projection>
 FROM <liste de tables>
 [WHERE <critère de jointure> AND <critère de restriction>]
 [GROUP BY <attributs de partitionnement>]
Page 12
Architecture client serveur – Exposé : Langage SQL

 [HAVING <critère de restriction>]


 [ORDER BY <attribut>]
 Restriction :
 arithmétique (=, <, >, <> ³ £)
 textuelle (LIKE)
 sur intervalle (BETWEEN)
 sur liste (IN)
 Possibilité de blocs imbriqués par :
 IN, EXISTS, NOT EXISTS, ALL, SOME, ANY
IV.2.1.1 Clause SELECT
Cette clause permet d'indiquer quelles colonnes, ou quelles expressions doivent être
retournées par l'interrogation.
SELECT [DISTINCT] {expression [c_alias] |* ...]
Expression valide
- [[schéma.] table.] attribut
- ‘texte’
- Nombre
- Fonction [(argument)]
- Combinaison de ces expressions
Alias pour expressions / attribut
- Renomme l’entête d’une colonne (affichage ou clause ORDER BY)
- Utile si expression calculée
- Suit immédiatement l’expression (mot-clé AS facultatif entre attribut et
alias)
- à écrire entre guillemets (") si les majuscules et minuscules doivent être
différenciées, ou si la chaîne comporte des espaces ou caractères
spéciaux

SELECT * FROM PRIX


Ou
SELECT PNOM, FNOM, COUT FROM PRIX
_*_ signifie que toutes les colonnes de la table sont sélectionnées.

SELECT n’élimine pas les duplications. Pour les éliminer, on utilise la clause DISTINCT
ou UNIQUE: si, dans le résultat, plusieurs lignes sont identiques, une seule sera conservée.

IV.2.1.2 Clause FROM

Page 13
Architecture client serveur – Exposé : Langage SQL

La clause FROM donne la liste des tables participant à l'interrogation. Il est possible de
lancer des interrogations utilisant plusieurs tables à la fois.

FROM table [t-alias] [, table [t-alias]] ...


t-alias : renommage de la table le temps de la requête

IV.2.1.3 Clause WHERE

La clause WHERE permet de spécifier quelles sont les lignes à sélectionner dans une table
ou dans le produit cartésien de plusieurs tables. Elle est suivie d'un prédicat (expression
logique ayant la valeur vrai ou faux) qui sera évalué pour chaque ligne. Les lignes pour
lesquelles le prédicat est vrai seront sélectionnées.

SELECT PNOM, COUT AS ‘PRIX DU PRODUIT’


FROM PRIX
WHERE FNOM =’JEAN’ 
 

IV.2.1.3.1 Conditions de sélection


. Attribut opérateur Valeur
. Attribut opérateur Attribut
Opérateur : =, <, >, ≤, ≥, <>.
Utilisation des clauses BETWEEN, IN, LIKE, IS NULL
SELECT PNOM FROM PRIX
WHERE COUT BETWEEN 10000 AND 50000
La condition Y BETWEEN X AND Z est équivalente à Y<=Z et X <= Y

SELECT PNOM FROM PRIX


WHERE COUT IN (SELECT 1000, 10000, 30000)
SELECT COUT FROM PRIX
WHERE PNOM LIKE ′B%′

Le littoral qui suit LIKE doit être une chaîne de caractère avec éventuellement des
caractères jokers.
_ ___ remplace 1 caractère exactement
_ _%_ remplace une chaîne de caractères de longueur quelconque, y compris de longueur
nulle

Page 14
Architecture client serveur – Exposé : Langage SQL

IV.2.1.3.2 Requêtes imbriquées simples


La jointure s’exprime par deux blocs. SELECT… FROM…. WHERE imbriqués.
Requête : Nom, Coût et fournisseurs des produits commandés par ‘Jean’.
SELECT PNOM, COUT, FNOM FROM PRIX
WHERE PNOM IN (SELECT PNOM FROM COMMANDE
WHERE CNOM = ‘Jean’)

IV.2.1.3.3 Jointure

Quand on utilise deux tables ou plus, on effectue en réalité des jointures entre ces
tables.
Une jointure permet donc de combiner les colonnes de plusieurs tables.
Lorsque la jointure entre tables s'effectue en imposant l'égalité des valeurs d'une colonne
d'une table à une colonne d'une autre table, on parle de jointure naturelle ou équi-jointure.
On trouve aussi des jointures d'une table sur elle-même. On parle alors d'auto-jointure. Il
arrive que l'on doive procéder à des jointures externes, c'est-à-dire joindre une table à une
autre, même si la valeur de liaison est absente dans une table ou l'autre. Dans certains cas,
on peut procéder à des jointures hétérogènes, c'est-à-dire que l'on remplace le critère
d'égalité par un critère d'inégalité ou de différence.

Exemple :
SELECT a.PNOM, COUT, FNOM FROM PRIX AS a
JOIN COMMANDE AS b ON a.PNOM = b.PNOM -- condition de jointure
WHERE CNOM = ’Jean’ -- condition de sélection

IV.2.1.3.4 Requêtes imbriquées plus complexes

Requête : Fournisseurs de briques à un coût inférieur au coût des tuiles.

SELECT FNOM FROM PRIX


WHERE PNOM = "Briques" AND COUT < ANY (SELECT COUT
FROM PRIX
WHERE PNOM = "Tuiles")

Requête : Fournisseurs qui fournissent au moins un produit.

Page 15
Architecture client serveur – Exposé : Langage SQL

SELECT FNOM FROM FOURNISSEUR


WHERE EXISTS (SELECT * FROM PRIX
WHERE FOURNISSEUR.FNOM = PRIX.FNOM)

IV.2.1.3.5 Opérations ensemblistes


UNION, INTERSECT, MINUS
Requête: Produits commandés qui coûtent plus que 1000F ou ceux qui sont commandés
par Jean.
SELECT PNOM FROM PRIX WHERE COUT > 1000
UNION
SELECT PNOM FROM COMMANDE WHERE CNOM = ‘Jean’

IV.2.1.4 Fonctions de calcul


COUNT : Compte le nombre de n-uplets sans élimination des dupliqués ni des valeurs
nulles
Requête: Nombre de fournisseurs de Porto-Novo

SELECT COUNT (*) FROM FOURNISSEUR WHERE VILLE ="Porto-Novo"

Requête: Nombre de fournisseurs qui fournissent actuellement des produits


SELECT COUNT (DISTINCT ou UNIQUE FNOM) FROM PRIX

SUM : Permet de faire la somme.

Requête : Quantité totale de briques commandées


SELECT SUM (QTE) FROM COMMANDE WHERE PNOM = ‘Briques’

AVG : Calcul la moyenne


Requête: Fournisseurs des briques à un prix inférieur au coût moyen des briques

SELECT FNOM FROM PRIX WHERE PNOM = ‘BRIQUE’ AND COUT <
(SELECT AVG (COUT) FROM PRIX WHERE PNOM = ‘Brique’)

IV.2.1.5 Autres fonctions: MIN MAX

IV.2.1.6 Claude GROUP BY


Page 16
Architecture client serveur – Exposé : Langage SQL

GROUP BY exp1, exp2,...

Cette clause permet de préciser les attributs de partitionnement des relations déclarées dans
la clause FROM.
Elle se place juste après la clause WHERE, ou après la clause FROM si la clause WHERE
n'existe pas.

Requête : Requête pour chaque produit fourni, son coût moyen

SELECT PNOM AVG (COUT) FROM PRIX GROUP BY PNOM.

IV.2.1.7 Clause HAVING


HAVING prédicat
Cette clause permet d’éliminer les partitionnements comme la clause WHERE élimine des
n-uplets.
Elle sert à préciser quels groupes doivent être sélectionnés.
Elle se place après la clause GROUP BY.
Le prédicat suit la même syntaxe que celui de la clause WHERE. Cependant, il ne peut
porter que sur des caractéristiques de groupe : fonction de groupe ou expression figurant
dans la clause GROUP BY.

Requête : Les produits fournis et leur coût moyen pour les fournisseurs dont le siège est à
Cotonou seulement si le coût minimum du produit est >1000

SELECT PNOM, AVG (COUT) FROM PRIX, FOURNISSEUR


WHERE VILLE = ‘COTONOU’ AND PRIX.FNOM = FOURNISSEUR.FNOM
GROUP BY PNOM
HAVING MIN (COUT) > 1000

IV.2.1.8 Clause ORDER BY

Les lignes constituant le résultat d'un SELECT sont obtenues dans un ordre indéterminé.
La clause ORDER BY précise l'ordre dans lequel la liste des lignes sélectionnées sera
donnée.
ORDER BY exp1 [DESC], exp2 [DESC], ...

L'option facultative DESC donne un tri par ordre décroissant. Par défaut, l'ordre est
croissant.
Page 17
Architecture client serveur – Exposé : Langage SQL

IV.2.1.9 Limiter le nombre de lignes renvoyées

Aucune méthode standardisée ne permet de limiter le nombre de lignes renvoyées par un


select mais la plupart des SGBDs offre cette facilité.
Voici quelques exemples qui montrent comment quelques SGBDs limitent à 10 le nombre
de lignes renvoyées :

Avec MySQL et Postgresql :


SELECT PNOM, COUT FROM PRIX LIMIT 10

Avec Oracle:
SELECT PNOM, COUT FROM PRIX WHERE ROWNUM <= 10

Avec SQL Server:


SELECT TOP 10 PNOM, COUT FROM PRIX

IV.2.2 Insertion de données


 Insertion de lignes dans une table
 Via formulaire où via requêtes
INSERT INTO nom-table [(nom-col [, nom-col ...])]
{VALUES (constante [constante…]) | subquery}

La liste des colonnes :


- Contient des noms d’attributs de la table
- Si un attribut de la table est omis dans la liste, il prend la valeur par
défaut, NULL sinon (si autorisé)
- Si aucun nom d’attribut n’est donné, la clause VALUES ou la sous
requête doit fournir une valeur pour chaque attribut de la table suivant
l’ordre du schéma

Clause VALUES : spécifie un n-uplets de valeurs à insérer dans la relation


- Avec cette clause, un seul n-uplet peut être inséré à la fois
- Sous-requête : instruction SELECT qui renvoie les n_uplets à insérer

Exemple :
INSERT INTO PRIX (PNOM, FNOM, COUT)
VALUES (“Bois”, “PAUL”, 20000)
Page 18
Architecture client serveur – Exposé : Langage SQL

IV.2.3 Mises à jour de données

La commande UPDATE permet de modifier les valeurs d'un ou plusieurs champs, dans
une ou plusieurs lignes existantes d'une table.
UPDATE nom-table
SET {nom-col = {expression | (subquery) } [ (nom-col [, nom-col…]) = (subquery) }
[WHERE condition]

Mises à jour des attributs cités des lignes qui vérifient la condition, ou de toutes les lignes
si la condition est omise.

IV.2.4 Suppression de données

L'ordre DELETE permet de supprimer des lignes d'une table.

DELETE FROM nom-table [WHERE condition]

Suppression des lignes qui satisfont la condition. Pas de condition, suppression de toutes
les lignes

IV.3 Les commandes DCL (Data Control Language)


Les commandes GRANT et REVOKE permettent de contrôler la sécurité et les accès aux
données.

IV.3.1 Les Droits d’accès

La gestion des droits d’accès aux tables est décentralisée. Chaque créateur de table obtient
tous les droits d’accès à cette table en particulier le droit d’effectuer la sélection
(SELECT), l’insertion (INSERT) la suppression (DELETE), la mise à jour (UPDATE) et
aussi de référencer la table dans une contrainte avec la clause REFERENCE. Il peut
ensuite passer ses droits sélectivement à d’autres utilisateurs ou à tout le monde (PUBLIC).
Un droit peut être passé avec le droit de le transmettre ou non. C’est la clause WITH
GRANT OPTION

GRANT {priv_objet [, priv_obj…] | ALL} [(col)]


ON objet
Page 19
Architecture client serveur – Exposé : Langage SQL

TO {user| rôle | PUBLIC}


[WITH GRANT OPTION]

- ALL: tous les privilèges objets


- Col: colonnes d’une table ou vue pour lesquelles le privilège est
accordé
- TO : désigne le bénéficiaire du privilège
- PUBLIC : privilège accordé à tous les utilisateurs
- WITH GRANT OPTION : le bénéficiaire du privilège (user ou
PUBLIC) peut à son tour transmettre le privilège obtenu à d’autres
utilisateurs ou rôles. Les cycles sont interdits dans la propagation des
privilèges.

IV.3.2 Suppression de privilège objets


REVOKE {priv [, priv…] | ALL
ON objet
FROM {user [, user…] | role | PUBLIC}
[CASCADE CONSTRAINTS]

CASCADE CONSTRAINTS: nécessaire pour supprimer toutes les contraintes d’intégrité


référentielles demandées sur l’objet à l’aide du privilège qui avait été accordé.
L’instruction REVOKE peut être exécutée à tout moment.

Suppression du privilège :
- Pour l’utilisateur nommé dans REVOKE
- Aux autres utilisateurs de la base à qui l’utilisateur nommé avait
propagé le privilège (en utilisant son droit WITH GRANT OPTION)

IV.4 Les commandes TCL (Transaction Control Language)


Les commandes transactionnelles permettent de contrôler des transactions se déroulant
dans un système de gestion de base de données relationnelle (SGBDR).

Les transactions sont des séquences de tâches s'effectuant dans un ordre logique par
l'intermédiaire de l'utilisateur ou d'une automatisation.

Les tâches peuvent être essentiellement des commandes DML : d'insertion (INSERT), de
suppression (DELETE) ou de modification (UPDATE) d'objets dans une base de données.

Page 20
Architecture client serveur – Exposé : Langage SQL

Ces diverses tâches peuvent être annulées en cours d'exécution puisqu'elles possèdent un
commencement et une fin.

Au terme de la tâche, il est nécessaire de sauvegarder les changements. Toutefois, aucun


enregistrement n'est effectué si la tâche a échoué pour une raison quelconque.

Les principales commandes transactionnelles pour contrôler ces séquences sont :

{SET | BEGIN} TRANSACTION;


détermine le début d'une transaction. BEGIN est utilisée sous SQL Server.

COMMIT [WORK];
enregistre les modifications produites par des transactions.

ROLLBACK{ [WORK | TO nom_point] };


annule les modifications qui n'ont pas été enregistrées précédemment.

SAVEPOINT nom_point;
insère un point de sauvegarde dans la liste de transactions, servant en conjonction avec
ROLLBACK pour une annulation jusqu'à un point précis.

La commande SAVEPOINT évite une annulation complète des transactions par la


commande ROLLBACK.

Transactions...
SAVEPOINT nom_point
Transactions...
ROLLBACK TO nom_point;

D'ailleurs, une commande spécifique permet de supprimer des points de sauvegardes


créés par la commande SAVEPOINT.

RELEASE SAVEPOINT nom_point;

Exemple
BEGIN TRANSACTION MYTRAN
INSERT INTO COMMANDE (NUM, PNOM, CNOM, QTE)
VALUES (1, 'TOLES', 'JEAN', 30000)
Page 21
Architecture client serveur – Exposé : Langage SQL

INSERT INTO COMMANDE (NUM, PNOM, CNOM, QTE)


VALUES (2, 'TUILES', 'JEAN', 5000)
INSERT INTO COMMANDE (NUM, PNOM, CNOM, QTE)
VALUES (3, 'TOLES', 'PIERRE', 50000)
IF @@ERROR<>0
ROLLBACK TRANSACTION MYTRAN
ELSE
COMMIT TRANSACTION MYTRAN

IV.5 Les procédures stockées


Les procédures stockées contiennent du code SQL compilé, permettant d'exécuter des
requêtes lourdes ou des instructions régulièrement utilisées sur des bases de données.

Les procédures stockées sont conservées dans la base de données dans une forme
exécutable et sont capables d'appeler d'autres procédures ou fonctions comme d'être
appelées par d'autres programmes.

A l'instar des procédures des langages de programmation, outre qu'elles soient composées
de diverses instructions, les procédures stockées sont capables de recevoir des paramètres
d'entrée et de retourner des valeurs en sortie.

La création des procédures stockées s'effectue par l'intermédiaire de l'instruction CREATE


PROCEDURE.

Syntaxe pour SQL Server

CREATE PROC [ EDURE ] nom_procedure [ ; nombre ]


[ { @parametre type_donnee }
[ VARYING ] [ = valeur_defaut ] [ OUTPUT ]
] [ ,...n ]
[ WITH
{ RECOMPILE | ENCRYPTION | RECOMPILE , ENCRYPTION } ]
[ FOR REPLICATION ]

Page 22
Architecture client serveur – Exposé : Langage SQL

AS instructions_SQL...
GO

La clause VARYING, applicable aux paramètres de type CURSOR, indique le jeu de


résultats pris en charge.

La clause OUTPUT permet de retourner la valeur aux instructions appelantes.

L'instruction WITH RECOMPILE spécifie que la procédure est recompilée à l'exécution


sans utiliser le cache pour le plan de la procédure.

L'option RECOMPILE est généralement utilisée pour des valeurs temporaires ou


atypiques sans remplacer le plan d'exécution placé en mémoire cache.

La clause WITH ENCRYPTION indique un cryptage de l'entrée de la table syscomments


contenant le texte de l'instruction CREATE PROCEDURE. L'argument ENCRYPTION
permet d'éviter la publication de la procédure dans le cadre de la réplication SQL Server.

La clause FOR REPLICATION indique que la procédure stockée doit être exécutée lors
de la modification de la table concernée par un processus de réplication.

La clause AS indique les actions entreprises par la procédure.

L'instruction GO signale la fin d'un jeu d'instructions.

Syntaxe pour Oracle

CREATE [OR REPLACE] PROCEDURE [schema .] procedure


[ ( argument [ IN | OUT | IN OUT ] [ NOCOPY ] type_donnee
[, argumentN [ IN | OUT | IN OUT ] [ NOCOPY ] type_donnee] ) ]
[ AUTHID { CURRENT_USER | DEFINER }]
{ IS | AS }
{ instruction_pl/sql | instruction_langage };

La commande OR REPLACE recrée la procédure stockée si elle existe déjà.

La clause OUT permet de retourner la valeur aux instructions appelantes.

Page 23
Architecture client serveur – Exposé : Langage SQL

La clause IN est utilisée pour spécifier une valeur pour l'argument en appelant la
procédure.

La clause AS (dépréciée) ou IS indique les actions entreprises par la procédure.

Les procédures stockées peuvent être appelées au moyen de l'instruction EXECUTE


(SQL Server) ou CALL (Oracle) à partir d'une autre procédure ou d'un lot d'instructions.
SQL Server peut utiliser une abréviation EXEC.

-- SQL Server
EXECUTE Procedure @Parametre = Valeur, ..., @ParametreN = ValeurN
-- Oracle
CALL Procedure(Valeur, ..., ValeurN)

Exemple
-- Instruction pour SQL Server
CREATE PROCEDURE ajout_enregistrement
@proc_pnom char(20),
@proc_fnom char(20),
@proc_cout int
AS
INSERT INTO PRIX (pnom, fnom, cout)
VALUES (@proc_pnom, @proc_fnom, @proc_cout)
GO
-- Instruction pour Oracle
CREATE PROCEDURE Ajout_Enregistrement (
proc_pnom char(20),
proc_fnom char(20),
proc_cout int
)
IS
BEGIN
INSERT INTO PRIX (pnom, fnom, cout)
VALUES (proc_pnom, proc_fnom, proc_cout
END;

-- Utilisation

Page 24
Architecture client serveur – Exposé : Langage SQL

-- Sous SQL Server


execute Ajout_Enregistrement 'Fer', 'JACOB', 100000
-- Sous Oracle
call Ajout_Enregistrement('Fer', 'JACOB', 100000);

IV.6 Les déclencheurs (Triggers)


Les triggers (déclencheurs en français) ressemblent aux procédures stockées car ils sont
eux aussi compilés et enregistrés dans le dictionnaire des données de la base et ils sont le
plus souvent écrits dans le même langage.

La différence est que leur exécution est déclenchée automatiquement par des événements
liés à des actions sur la base. Les événements déclencheurs peuvent être les commandes
LMD insert, update, delete ou les commandes LDD create, alter, drop.

Une table peut comporter plusieurs déclencheurs d'un type donné, à condition que
chacun possède un nom différent. Cependant, un déclencheur donné ne peut être assigné
qu'à une seule et unique table tout en s'appliquant à la fois, à l'insertion, la mise à jour et la
suppression d'enregistrements sur la table en question.

Une table ne peut posséder qu'un seul déclencheur INSTEAD OF d'un type donné.

Les déclencheurs se produisent soit après (AFTER), soit avant (BEFORE) soit à la
place (INSTEAD OF) d'une action DML.

Un déclencheur sur INSERT s'exécute à chaque opération d'insertion lancée par


l'utilisateur ou par un programme. Lors d'une insertion, l'enregistrement est inséré à la
fois dans la table cible et dans une table temporaire dénommée inserted. Une telle table
peut permettre de vérifier la cohérence des enregistrements.

Un déclencheur sur DELETE s'exécute à chaque opération de suppression lancée par


l'utilisateur ou un programme. Lors d'une suppression, l'enregistrement est supprimé
physiquement de la table cible et inséré dans une table temporaire dénommée deleted.
Cela peut permettre de récupérer l'enregistrement supprimé.

Un déclencheur sur UPDATE s'exécute à chaque opération de mise à jour lancée par
l'utilisateur ou par un programme. Lors d'une mise à jour, l'ancien enregistrement est
supprimé et inséré dans la table temporaire deleted, tandis que le nouveau est inséré à
la fois dans la table cible et dans la table inserted.

Page 25
Architecture client serveur – Exposé : Langage SQL

La syntaxe des déclencheurs sous SQL Server :

CREATE TRIGGER nom_déclencheur


ON { nom_table | nom_vue }
[ WITH ENCRYPTION ]
{
{ { FOR | AFTER | INSTEAD OF } { [ INSERT ] [,] [ UPDATE ] [,] [ DELETE ] }
[ WITH APPEND ]
[ NOT FOR REPLICATION ]
AS
}
instruction_SQL...
}
}
La suppression des déclencheurs s'effectue par l'intermédiaire de l'instruction DROP.
DROP TRIGGER nom_déclencheur [ , nom_déclencheurN ]

La modification des déclencheurs s'effectue par l'intermédiaire de l'instruction


ALTER. La syntaxe complète de la commande ALTER TRIGGER est en fait identique dans
le cas d'Oracle ou de SQL Server à celle de CREATE TRIGGER.

ALTER TRIGGER nom_déclencheur_existant

ON nom_table
FOR INSERT, UPDATE, DELETE
AS instruction_SQL...

Tous les déclencheurs (ALL) ou certains peuvent être activés (ENABLE) ou désactivés
(DISABLE) au moyen de l'instruction ALTER TABLE.

ALTER TABLE table


{ ENABLE | DISABLE } TRIGGER
{ ALL | nom_déclencheur [ , nom_déclencheurN ] }

Exemple
CREATE TABLE tbl_produit ( nom VARCHAR(20), identificateur INTEGER )
GO
INSERT tbl_produit
SELECT 'dentifrice', 1 UNION
SELECT 'savon', 2 UNION
SELECT 'savon', 0 UNION
Page 26
Architecture client serveur – Exposé : Langage SQL

SELECT 'brosse à dent', 3 UNION


SELECT 'brosse à dent', 0 UNION
SELECT 'rasoir', 4 UNION
SELECT 'mousse à raser', 5 UNION
SELECT 'serviette', 6 UNION
SELECT 'serviette', 0 UNION
SELECT 'peigne', 7 UNION
SELECT 'brosse à cheveux', 8
GO
CREATE TRIGGER declencheur_suppression
ON tbl_produit FOR DELETE
AS
SELECT nom AS "Lignes à supprimer"
FROM deleted
GO
CREATE TRIGGER declencheur_insteadof
ON tbl_produit INSTEAD OF DELETE
AS
DELETE tbl_produit
FROM tbl_produit INNER JOIN deleted
ON tbl_produit.nom = deleted.nom
WHERE tbl_produit.identificateur = 0
GO
DELETE tbl_produit
WHERE nom IN ('brosse à dent', 'serviette', 'savon')
GO
SELECT * FROM tbl_produit

Cet exemple met en exergue le processus permettant de faire appel à différents types de
déclencheurs au sein d'une table. Le premier déclencheur FOR DELETE s'exécute lors
d'une suppression en sélectionnant les lignes supprimées à partir de la table temporaire
deleted. Le second Trigger se déclenche et exécute ses propres instructions à la place de la
commande de déclenchement DELETE afin d'effectuer une comparaison entre les noms de
produits sur les deux tables tbl_produit et deleted pour ensuite supprimer les
enregistrements possédant un identificateur égal à zéro.

IV.7 Les curseurs

Page 27
Architecture client serveur – Exposé : Langage SQL

Un curseur SQL représente une zone de mémoire de la base de données où la dernière


instruction SQL est stockée.

Syntaxe sous SQL Server


DECLARE nom_curseur [INSENSITIVE] [SCROLL] CURSOR
FOR instruction_sélection
[FOR {READ ONLY | UPDATE [OF nom_colonne [ ,...n ] ] } ]
Syntaxe sous Oracle
DECLARE CURSOR nom_curseur [(paramètre [, paramètre]...)]
[RETURN return_type] IS instruction_sélection;

Un curseur s'ouvre par l'intermédiaire de la commande OPEN suivi du nom du


curseur et de ses éventuels arguments.

OPEN nom_curseur[(liste_arguments...)];

La commande FETCH permet de parcourir un enregistrement du curseur ouvert.


L'ensemble des enregistrements d'un curseur peut être parcouru à l'aide d'une structure
itérative.

@@FETCH_STATUS retourne l'état de la dernière instruction FETCH appliquée au


curseur en cours d'utilisation. Les valeurs 0, -1 et -2 indiquent respectivement si
l'instruction FETCH a réussi ou a échouée et si la ligne recherchée n'a pas été trouvée.

L'attribut Oracle %NOTFOUND retourne FALSE si la dernière instruction FETCH


renvoie un enregistrement ou TRUE en cas d'échec.

Suite à la fin de son utilisation, le curseur peut être fermé afin de ne plus consommer de
ressources. Il est également possible de désallouer le curseur.

CLOSE nom_curseur;

-- Exemple SQL Server


DESALLOCATE nom_curseur;
-- Exemple Oracle
DESALLOCATE CURSOR nom_curseur;

Exemples
-- Déclaration du curseur
DECLARE mycursor CURSOR LOCAL
FOR
Page 28
Architecture client serveur – Exposé : Langage SQL

SELECT NUM, PNOM, QTE


FROM COMMANDE
WHERE CNOM='Jean'
-- Ouverture du curseur
OPEN mycursor
-- Premiere recuperation
FETCH NEXT FROM mycursor
-- puis on boucle tant qu'il reste des lignes à récupérer
WHILE @@FETCH_STATUS=0
BEGIN
-- ceci est exécuté pour chaque ligne du curseur
FETCH NEXT FROM mycursor
END
-- fermeture et déchargement du curseur
CLOSE mycursor
DEALLOCATE mycursor

IV.8 PL/SQL
PL/SQL (Procedural Language / Structured Query Language) est un langage procédural
propriétaire créé par Oracle et utilisé dans le cadre de bases de données relationnelles. Il
permet de combiner des requêtes SQL et des instructions procédurales (boucles,
conditions...), dans le but de créer des traitements complexes destinés à être stockés sur le
serveur de base de données (objets serveur), comme par exemple des procédures stockées
ou des déclencheurs.

Les dernières évolutions proposées par Oracle reposent sur un moteur permettant de créer
et gérer des objets contenant des méthodes et des propriétés.

IV.8.1 Structure d’un programme PL/SQL

La structure de base d’un programme PL/SQL est celle de bloc (possiblement imbriqué). Il
a généralement la forme suivante:
DECLARE
/* section de déclaration */
BEGIN
/* corps du bloc de programme
Il s’agit de la seule zone dont la présence est obligatoire */
EXCEPTION

Page 29
Architecture client serveur – Exposé : Langage SQL

/* gestion des exceptions */


END;

IV.8.2 Structure de contrôle


Comme n’importe quel langage procédural, PL/SQL possède un certain nombre de
structures de contrôles évoluées comme les branchements conditionnels et les boucles.

IV.8.2.1 Les branchements conditionnels

IF <condition> THEN
commandes;
[ ELSE IF <condition> THEN
commandes;]
[ ELSE
commandes; ]
END IF;

Exemple
IF nomEmploye=’TOTO’ THEN
salaire:=salaire*2;
ELSE IF salaire>10000 THEN
salaire:=salaire/2;
ELSE
salaire:=salaire*3;
END IF;

IV.8.2.2 Les boucles


LOOP
commandes;
END LOOP;
Au moins une des instructions du corps de la boucle doit être une instruction de sortie :
EXIT WHEN <condition>;

FOR <compteur> IN [REVERSE] <limite_inf> .. <limite_sup>


commandes;
END LOOP;

WHILE <condition> LOOP


Page 30
Architecture client serveur – Exposé : Langage SQL

commandes;
END LOOP
Toutes ces structures de contrôles peuvent évidemment être imbriquées les unes dans les
autres.

Page 31
Architecture client serveur – Exposé : Langage SQL

IV.8.3 La gestion des exceptions

PL/SQL permet de définir dans une zone particulière (de gestion d’exception), l’attitude
que le programme doit avoir lorsque certaines erreurs définies ou prédéfinies se produisent.
Un certain nombre d’exceptions sont prédéfinies sous Oracle. Citons, pour les plus
fréquentes : NO DATA FOUND (devient vrai dès qu’une requête renvoie un résultat vide),
TOO MANY ROWS (requête renvoie plus de lignes qu’escompté), CURSOR ALREADY
OPEN (curseur déjà ouvert), INVALID CURSOR (curseur invalide)...
L’utilisateur peut définir ses propres exceptions. Dans ce cas, il doit définir celles ci dans
la zone de déclaration.

Exemple :
excpt1 EXCEPTION

Puis, cette exception est levée quelque part dans le programme (après un test non
concluant, par exemple), par l’instruction :

RAISE excpt1

Enfin, dans la zone d’exception un traitement est affecté à chaque exception possible
(définie ou prédéfinie) :

EXCEPTION
WHEN <exception1> [OR <exception2> OR ...] THEN <instructions>
WHEN <exception3> [OR <exception2> OR ...] THEN <instructions>
WHEN OTHERS THEN <instructions>
END;
Evidemment, un seul traitement d’exception peut se produire avant la sortie du bloc.

IV.8.4 Affichage

PL/SQL n’est pas un langage avec des fonctionnalités d’entrées sorties évoluées (ce n’est
pas son but). Toutefois, on peut imprimer des messages et des valeurs de variables de
plusieurs manières différentes. Le plus pratique est de faire appel à un package prédéfini :
DBMS output.

Page 32
Architecture client serveur – Exposé : Langage SQL

En premier lieu, taper au niveau de la ligne de commande :

SET SERVEROUTPUT ON

Pour afficher, on utilise alors la commande suivante :

DBMS_OUTPUT.PUT_LINE (’Au revoir’ || nom || ’ à bientôt’);

Si on suppose que nom est une variable dont la valeur est ”toto”, l’instruction affichera :
Au revoir toto à bientôt.

Page 33
Architecture client serveur – Exposé : Langage SQL

V. Comparaison de quelques fonctions SQL dans


différents systèmes de gestion de bases de
données relationnelles
D’un SGBDR à un autre, les fonctions SQL ne sont pas identiques. La différence entre ces
fonctions se résume dans les tableaux ci-après :

Légende :
O : Oui
N : Non
X : Existe mais syntaxe hors norme
! : Même nom mais fonction différente
- : implémentation partielle
Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Interbase
SQL Server
AVG Moyenne O O O O O O O O
COUNT Nombre O O X O O O O O
MAX Maximum O O O O O O O O
MIN Minimum O O O O O O O O
SUM Total O O O O O O O O
EVERY Tous (booléen) O N N N N N N N
ANY / SOME Au moins un (booléen) O N N N N N N N

a. Agrégation statistique

b. Fonctions "système"
Norme PostGre SQL
Fonction Description Paradox Access MySQL Oracle Interbase
SQL SQL Server
CURRENT_DATE Date courante O N N O O N N O
CURRENT_TIME Heure courante O N N O O N N O
CURRENT_USER Utilisateur courant O N N N O O N N
SESSION_USER Utilisateur autorisé O N N X O O N N
SYSTEM_USER Utilisateur système O N N X O O N N
Nom de la bases de données
DATABASE N N N O N O O N
courante
SYSDATE Date et/ou heure courante N N N O N N O N
USER Utilisateur courant N N N O N O O O
VERSION Version du SGBDR N N N O O N N N

c. Fonctions générales
Page 34
Architecture client serveur – Exposé : Langage SQL

Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Interbase
SQL Server
OCTET_LENGTH Longueur en octet O N N O O N O N
DATALENGTH Longueur N N N N N O N N
Fonction
DECODE N N N N N N O N
conditionnelle
LENGTH Longueur N N O O O O O N
NVL Valeur non NULL N N N N N N O N
Conversion de
TO_CHAR N N N N N N O N
données en chaîne
TO_DATE Conversion en date N N N N O N O N
Conversion en
TO_NUMBER N N N N N N O N
nombre

d. Fonctions de chaînes de caractères


Nor
Para MyS PostGre SQL
Fonction Description me Access Oracle Interbase
dox QL SQL Server
SQL
|| Concaténation O O N X O N O O
CHAR_LENGTH Longueur d'une chaîne O N N X O N N N
CHARACTER_LENGTH Longueur d'une chaîne O N N O O O N N
CONCATENATE Concaténation O N N N N O N N
Conversion de format
CONVERT O N N N N ! O O
de caractères
LIKE (prédicat) Comparaison partielle O O X O O O O O
LOWER Mise en minuscule O O N O O O O N
Position d'une chaîne
POSITION O N N O O N N N
dans une sous chaîne
Extraction d'une sous
SUBSTRING O O N O O N N N
chaîne
UPPER Mise en majuscule O O N O O O O O

e. Fonctions de chaînes de bits


Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Interbase
SQL Server
BIT_LENGTH Longueur en bit O N N N N N N N
& "et" pour bit logique N N ? ? ? O ? ?
"ou" pour bit
| N N ? ? ? O ? ?
logique
"ou" exclusif pour
^ N N ? ? ? O ? ?
bit logique

Page 35
Architecture client serveur – Exposé : Langage SQL

f. Fonctions numériques
Norme PostGre SQL
Fonction Description Paradox Access MySQL Oracle Interbase
SQL SQL Server
% Modulo N N N O O O N N
Opérateurs et
+-*/() O O O O O O O O
parenthésage
ABS Valeur absolue N N O O O O O N
Conversion de caractère
ASCII N N O O O O O N
en code ASCII
EXP Exponentielle N N O O O O O N
LN Logarithme népérien N N N N N N O N
Logarithme en base n
LOG(n,m) N N N N O N O N
de m
LOG10 Logarithme décimal N N N O N O O N
MOD Modulo N N O O O O O N
POWER Elévation à la puissance N N O O N O O N
ROUND Arrondi N N O O O O N N
SQRT Racine carrée N N O O O O N N

g. Fonctions temporelles
Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Interbase
SQL Server
AGE Age N N N N O N N N
Ajout d'intervalle à
DATE_ADD N N N O N N N N
une date
DATE_FORMAT Formatage de date N N N O N N N N
DAY Jour d'une date N N N N N O N N
DAYNAME Nom du jour N N O O N O N N
HOUR Extraction de l'heure N N O O N O N N
LAST_DAY Dernier jour du mois N N N N N N O N
MINUTE   N N O O N O N N
MONTH Mois d'une date N N O O N O O N
Prochain premier jour
NEXT_DAY N N N N N N O N
de la semaine
SECOND Extrait les secondes N N O O N O N N
WEEK Numéro de la semaine N N O O N O O N
YEAR Année d'une date N N O O N O O N

Page 36
Architecture client serveur – Exposé : Langage SQL

h. Fonctions OLAP (norme SQL:1999)


Norme
Fonction Description Paradox Access MySQL PostGreSQL SQL Server Oracle Interbase
SQL
Sous totaux des
agrégats pour toutes
CUBE O N N N N O O N
les combinaisons
possibles
Sous totaux des
agrégats pour toutes
ROLLUP O N N N N O O N
les combinaisons
visibles
Sous totaux des
GROUPING agrégats pour toutes
O N N N N O O N
SETS les combinaisons
spécifiées
Indicateur de sous
GROUPINGS O N N N N O O N
totalisation
Spécification de
NULL FIRTS /
classement pour les O N N N N N O N
NULL LAST
marqueurs NULL

i. Fonctions de fenêtrage et analytiques (normes 2003 et 2008)


Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Firebird
SQL Server
ROW_NUMBER Numérotation des lignes O N N N N O O N
NTILE N-tile (décile, centile, ....) O N N N N O O N
Agrégats (MAX,
Calcul d'agrégat avec
MIN, COUNT, O N N N N O O N
fenêtrage
SUM...)
Fenêtre de calcul par
ROWS / RANGE O N N N N N O N
ligne ou valeurs
PRECEDING * /
Bornage de la fenêtre de
FOLLOWING * / O N N N N N O N
calcul
BETWEEN
Définition d'une fenêtre
Clause WINDOW O N N N N N N N
de calcul

Page 37
Architecture client serveur – Exposé : Langage SQL

j. Prédicat, opérateurs et structures diverses


Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Firebird
SQL Server
CASE Structure conditionnelle O N N O O O X O
IS [NOT] TRUE Vrai O N N N N N N N
INNER JOIN Jointure interne O O O O O O N O
LEFT, RIGHT, FULL
Jointure externe O O O O O O N O
OUTER JOIN
INTERSECT Intersection (ensemble) O ? N N O N X N
UNION Union (ensemble) O ? O N O O O O
EXCEPT Différence (ensemble) O ? N N O N X N
[NOT] BETWEEN Fourchette   O O O O O O O
[NOT] EXISTS Existence O ? ? N O O O O
Comparaison à toutes les
ALL O ? O N O O O O
valeurs d'un ensemble
Comparaison à au moins
ANY / SOME O ? O N O O O O
une valeur de l'ensemble
UNIQUE Existance sans doublons O N N N N N N N
Construteur de ligne
Row value construteur O N N N N - - N
valuées

k. Fonctions spéciales
Norme SQL
Fonction Description Paradox Access MySQL PostGreSQL Oracle Firebird
SQL Server
TABLE SAMPLE Echantillon de données O N N N N O O N
TRUNCATE Vidage de table O N N N N O O O
Limitation des lignes
OFFSET / FETCH O N N N N N N N
retournées
Nombre de ligne
LIMIT/TOP N N N LIMIT LIMIT TOP N ROWS
retournée
"Row Id" Identifiant de ligne N N N _rowid oid N rowid ?

l. Sous requêtes
Norme SQL
Fonction Paradox Access MySQL PostGreSQL Oracle Firebird
SQL Server
Imbriquées O O O N O O O O
Dans la clause SELECT O X O N O O O O
Dans la clause FROM O N N N O O O N
Dans la clause WHERE O O O N O O O O
Page 38
Architecture client serveur – Exposé : Langage SQL

Dans la clause HAVING O O N N O O O O


CTE (Common Table
Expression : expression de O N N N N O O O
table)
Requêtes récursives via CTE O N N N N O X O

Page 39
Architecture client serveur – Exposé : Langage SQL

Conclusion
SQL est un langage déclaratif régi par les normes qui sont diversement respectées par les
éditeurs des SGBDR. L’évolution de SQL permet aujourd’hui de manipuler aussi des
données relatives au multimédia et d’intégrer des données XML.

Le succès que connaissent les grands éditeurs de SGBDR a plusieurs origines et repose
notamment sur SQL.

SQL peut s’interfacer avec des langages de troisième génération comme C, Ada ou
Cobol, mais aussi avec des langages plus évolués comme C ++, Java, Delphi, C#, etc.
Les procédures stockées offrent des gros avantages pour les applications client/serveur,
surtout au niveau des performances :
- le trafic sur le réseau est réduit car les clients SQL ont seulement à envoyer
l'identification de la procédure et ses paramètres au serveur sur lequel elle est stockée.
- les procédures sont précompilées une seule fois quand elles sont enregistrées.
L'optimisation a lieu à ce moment et leurs exécutions ultérieures n'ont plus à passer par
cette étape et sont donc plus rapides. De plus les erreurs sont repérées dès la compilation et
pas à l'exécution.

Le principal inconvénient des procédures stockées est qu'elles impliquent une dépendance
forte vis-à-vis du SGBD car chaque SGBD a sa propre syntaxe et son propre langage de
programmation.

Ces différences font qu'un code source écrit sans précaution pour un SGBD donné ne
fonctionnera pas forcément avec un autre SGBD.

Page 40
Architecture client serveur – Exposé : Langage SQL

Références
Bibliographie

 Bases de données - de la modélisation au SQL - Laurent Audibert - Ellipses 2009

 SQL Synthèse de cours et exercices - 2e édition - Frédéric Brouard, Christian

 Soutou, Rudi Bruchez - Pearson Education 2008

 SQL par l'exemple - Antony Molinaro - O'reilly, 2007

Pages web

http://sql.developpez.com/

http://www2.laltruiste.com/document.php?
url=http://www2.laltruiste.com/courssql/sommaire.html

http://fr.wikipedia.org/wiki/Structured_Query_Language

http://www.asp-magazine.com/article-110.html

Page 41