Introduction au langage SQL

(Cours)
Partie 1 : Qu'est-ce que SQL ?

SQL (Structured Query Language) est le langage standard pour interagir avec les bases de
données relationnelles. Créé dans les années 1970 par IBM, SQL est devenu l'outil
incontournable pour gérer, interroger et manipuler les données stockées de manière
structurée.
Définition et caractéristiques principales
SQL est un langage déclaratif, ce qui signifie que vous exprimez ce que vous voulez obtenir
plutôt que comment l'obtenir. Cette approche simplifie considérablement l'interaction avec
les données, permettant aux utilisateurs de se concentrer sur les résultats souhaités plutôt
que sur les mécanismes techniques sous-jacents.

Caractéristiques fondamentales de SQL :

• Langage standardisé : reconnu et utilisé par tous les principaux systèmes de gestion de
bases de données
• Interface universelle : permet d'accéder aux données indépendamment du système de
stockage utilisé
• Syntaxe proche du langage naturel : facilite l'apprentissage et la compréhension
• Puissance et flexibilité : capable de gérer des opérations simples comme complexes
Domaines d'application de SQL
SQL trouve ses applications dans de nombreux domaines professionnels :
• Développement web : gestion des données utilisateurs, contenus dynamiques, systèmes
de e-commerce
• Analyse de données : extraction d'insights, création de rapports, analyses statistiques et
business intelligence
• Administration de bases de données : création et maintenance des structures de données,
gestion des performances, sauvegardes
• Applications métier : systèmes CRM, ERP, gestion de stocks, comptabilité
• Intelligence artificielle : préparation et nettoyage des données pour l'entraînement de
modèles

Systèmes de gestion de bases de données compatibles

SQL est supporté par tous les principaux SGBD du marché :
• MySQL : populaire pour les applications web
• PostgreSQL : reconnu pour sa robustesse et ses fonctionnalités avancées
• Microsoft SQL Server : largement utilisé en entreprise
• Oracle Database : solution haut de gamme pour les grandes organisations
• SQLite : idéal pour les applications mobiles et les prototypes
Cette universalité garantit la transférabilité des compétences SQL entre différents
environnements techniques.

Quiz 1 : Vérifiez vos connaissances

1. SQL est-il un langage de programmation traditionnel ?
2. Citez trois domaines où SQL est couramment utilisé
3. Que signifie "langage déclaratif" dans le contexte de SQL ?
Réponses : 1) Non, c'est un langage déclaratif 2) Développement web, analyse de données,
administration BDD 3) On exprime ce qu'on veut obtenir, pas comment l'obtenir

Partie 2 : Types de bases de données

La compréhension des différents types de bases de données est essentielle pour choisir les
bons outils et approches d'analyse. Deux paradigmes dominent le paysage des bases de
données : OLTP et OLAP.
OLTP : Online Transaction Processing
Les systèmes OLTP (traitement transactionnel en ligne) sont conçus pour gérer les
opérations quotidiennes en temps réel. Ils constituent l'épine dorsale des applications métier
qui nécessitent des réponses immédiates et une grande fiabilité.
Caractéristiques des systèmes OLTP :
• Optimisation pour l'écriture : priorité donnée aux opérations INSERT, UPDATE, DELETE
• Transactions courtes et fréquentes : traitement en millisecondes de milliers d'opérations
simultanées
• Données normalisées : structure relationnelle minimisant la redondance
• Haute disponibilité : systèmes conçus pour fonctionner 24h/24 avec des temps d'arrêt
minimaux
Exemples concrets d'applications OLTP :
• Systèmes bancaires (virements, retraits aux distributeurs)
• Plateformes e-commerce (commandes, paiements, gestion stocks)
• Systèmes de réservation (billets d'avion, hôtels)
• Applications CRM (gestion des interactions clients)
OLAP : Online Analytical Processing
Les systèmes OLAP (traitement analytique en ligne) sont optimisés pour l'analyse complexe
de grandes quantités de données historiques. Ils transforment les données transactionnelles
en informations stratégiques.
Caractéristiques des systèmes OLAP :
• Optimisation pour la lecture : conçus pour exécuter des requêtes analytiques complexes
• Données dénormalisées : structures multidimensionnelles (cubes OLAP) pour accélérer les
analyses
• Volumes importants : traitement de téraoctets de données historiques
Latence acceptable : temps de réponse de quelques minutes à quelques heures selon la
complexité
Applications typiques d'OLAP :
• Tableaux de bord exécutifs et reporting
• Analyses de tendances et prévisions
• Études de marché et segmentation client
• Optimisation de la chaîne d'approvisionnement
Comparaison OLTP vs OLAP
Aspect OLTP OLAP
Objectif Transactions quotidiennes Analyse et aide à la décision
Utilisateurs Employés opérationnels Analystes, managers, dirigeants
Volume de données Petites transactions Gros volumes historiques
Fréquence d'utilisation Continue (24h/24) Périodique (rapports, analyses)
Structure des données Normalisée (3FN) Dénormalisée (schémas en étoile)
Type d'opérations INSERT, UPDATE, DELETE SELECT complexes avec agrégations
Temps de réponse Millisecondes Minutes à heures
Intégrité des données Critique (ACID) Important mais flexible
Complémentarité des approches
Dans la pratique, les organisations utilisent souvent les deux types de systèmes de manière
complémentaire :
1. Systèmes OLTP capturent et stockent les données opérationnelles en temps réel
2. Processus ETL (Extract, Transform, Load) transfèrent périodiquement les données vers
des systèmes OLAP
3. Systèmes OLAP permettent l'analyse et la génération de rapports stratégiques
4. Insights obtenus alimentent l'amélioration des processus OLTP
Cette architecture permet d'optimiser à la fois les performances opérationnelles et les
capacités analytiques.

Quiz 2 : OLTP vs OLAP

1. Quel type de système utiliseriez-vous pour un site e-commerce traitant les commandes ?
2. Pour analyser les tendances de vente sur 5 ans, quel système convient le mieux ?
3. Pourquoi les données OLAP sont-elles dénormalisées ?
Réponses : 1) OLTP 2) OLAP 3) Pour accélérer les requêtes analytiques complexes

Partie 3 : Propriétés ACID

Les propriétés ACID constituent le fondement de la fiabilité des bases de données

relationnelles.
Cet acronyme désigne quatre caractéristiques essentielles qui garantissent l'intégrité des
données lors des transactions : Atomicité, Cohérence, Isolation et Durabilité.

Atomicité (Atomicity)
L'atomicité garantit qu'une transaction est traitée comme une unité indivisible. Soit toutes les
opérations de la transaction réussissent, soit aucune n'est appliquée.
Principe : "Tout ou rien"
Exemple concret : Lors d'un transfert bancaire de 100€ du compte A vers le compte B :
BEGIN TRANSACTION;
UPDATE comptes SET solde = solde - 100 WHERE numero = 'A';
UPDATE comptes SET solde = solde + 100 WHERE numero = 'B';
COMMIT;
Si la deuxième opération échoue (compte B inexistant), la première est automatiquement
annulée.
L'argent ne disparaît pas du compte A sans arriver sur le compte B.
Bénéfices de l'atomicité :
• Prévention de la corruption des données
• Élimination des états incohérents
• Évitement des enregistrements orphelins

Cohérence (Consistency)
La cohérence assure que toute transaction fait passer la base de données d'un état valide à
un autre état valide. Les règles métier et contraintes d'intégrité sont respectées avant et
après chaque transaction.
Types de contraintes vérifiées :
• Contraintes de domaine : types de données, valeurs autorisées
• Contraintes d'intégrité référentielle : clés étrangères valides
• Contraintes métier : règles spécifiques à l'application
Exemple pratique :
-- Contrainte : un client doit avoir une adresse email valide
INSERT INTO clients (nom, email) VALUES ('Martin', 'email-invalide');
-- Cette transaction sera rejetée pour maintenir la cohérence
La base refuse les opérations qui violeraient les règles établies, préservant ainsi l'intégrité
logique des données.

Isolation (Isolation)
L'isolation garantit que les transactions simultanées n'interfèrent pas entre elles. Chaque
transaction a l'illusion d'être la seule à s'exécuter sur la base de données.
Problèmes évités par l'isolation :
• Lecture sale : lire des données non encore validées
• Lecture non reproductible : obtenir des résultats différents pour la même requête
• Lecture fantôme : voir apparaître de nouveaux enregistrements entre deux lectures
Niveaux d'isolation SQL standard :
1. READ UNCOMMITTED : pas d'isolation (performance maximale, risques élevés)
2. READ COMMITTED : lecture des données validées uniquement
3. REPEATABLE READ : résultats cohérents pour les lectures répétées
4. SERIALIZABLE : isolation complète (sécurité maximale, performance réduite)
Exemple d'isolation :

-- Transaction 1
BEGIN TRANSACTION;
UPDATE produits SET stock = stock - 1 WHERE id = 123;
-- Transaction en cours...
-- Transaction 2 (simultanée)
SELECT stock FROM produits WHERE id = 123;
-- Voit l'ancienne valeur jusqu'au COMMIT de la transaction 1
Durabilité (Durability)
La durabilité assure que les modifications validées persistent même en cas de panne
système. Une fois qu'une transaction est confirmée (COMMIT), ses effets sont permanents.
Mécanismes techniques garantissant la durabilité :
• Journalisation : écriture des modifications dans des logs de transaction
• Sauvegarde sur disque : persistance physique des données
• Réplication : copies de sécurité sur plusieurs serveurs
• Points de contrôle : synchronisation régulière entre mémoire et disque
Implications pratiques :
• Les données survivent aux pannes de courant
• Les redémarrages système n'affectent pas les transactions validées
• Les défaillances matérielles ne causent pas de perte de données
Importance des propriétés ACID en analyse de données
Pour les analystes de données, comprendre ACID est crucial car cela garantit :

❖ Fiabilité des analyses : les calculs sont basés sur des données intègres et cohérentes
❖ Reproductibilité : les mêmes requêtes produisent des résultats constants
❖ Traçabilité : l'historique des modifications est préservé
❖ Confiance dans les décisions : les insights s'appuient sur des fondations solides

Quiz 3 : Propriétés ACID

1. Que se passe-t-il si une partie d'une transaction échoue dans un système ACID ?
2. Pourquoi l'isolation est-elle importante dans un environnement multi-utilisateur ?
3. Comment la durabilité protège-t-elle contre les pannes système ?
Réponses : 1) Toute la transaction est annulée (atomicité) 2) Elle évite les interférences
entre transactions simultanées 3) Les données validées persistent même après une panne

Partie 4 : Sous-langages SQL

SQL se compose de cinq sous-langages spécialisés, chacun ayant un rôle spécifique dans
la gestion des bases de données. Cette division logique facilite l'apprentissage et
l'organisation des compétences SQL.

DDL : Data Definition Language (Langage de Définition des

Données)

Le DDL gère la structure et l'architecture des objets de base de données. Il permet de créer,
modifier et supprimer les éléments qui composent le schéma de la base.

Commandes principales du DDL :

CREATE : création d'objets (tables, index, vues, procédures)
ALTER : modification de la structure existante
ALTER TABLE clients
ADD COLUMN telephone VARCHAR(15);
ALTER TABLE clients
MODIFY COLUMN nom VARCHAR(100);
DROP : suppression définitive d'objets
DROP TABLE ancienne_table;
DROP INDEX idx_email;
Autres commandes DDL importantes :
• TRUNCATE : suppression rapide de toutes les données d'une table
• RENAME : renommage d'objets
• COMMENT : ajout de documentation
Le DDL est essentiel pour les administrateurs de bases de données et les développeurs qui
conçoivent l'architecture des données.
DML : Data Manipulation Language (Langage de Manipulation des
Données)
Le DML concerne les opérations sur les données elles-mêmes. Il permet d'ajouter, modifier
et supprimer les enregistrements contenus dans les tables.

Commandes fondamentales du DML :

INSERT : ajout de nouvelles données
INSERT INTO clients (nom, email)
VALUES ('Dupont', 'dupont@[Link]
INSERT INTO clients (nom, email)
VALUES
('Martin', 'martin@[Link]'),
('Bernard', 'bernard@[Link]');
UPDATE : modification de données existantes
UPDATE clients
SET telephone = '0123456789'
WHERE email = 'dupont@[Link]';
DELETE : suppression d'enregistrements
DELETE FROM clients
WHERE date_creation < '2020-01-01';

Le DML est utilisé quotidiennement par tous les professionnels qui travaillent avec des
données opérationnelles.

DQL : Data Query Language (Langage de Requête des Données)

Le DQL se concentre exclusivement sur l'interrogation et la récupération des données. Bien
que composé principalement de la commande SELECT, il offre une richesse fonctionnelle
considérable.

La commande SELECT et ses clauses :

SELECT colonne1, colonne2, fonction_agregat(colonne3)
FROM table1
JOIN table2 ON condition
WHERE conditions_filtrage
GROUP BY colonnes_groupement
HAVING conditions_post_agregation
ORDER BY colonnes_tri
LIMIT nombre_resultats;
Fonctionnalités avancées du DQL :
• Jointures : combinaison de données de plusieurs tables
• Sous-requêtes : requêtes imbriquées pour des analyses complexes
• Fonctions d'agrégation : COUNT, SUM, AVG, MIN, MAX
• Expressions conditionnelles : CASE, COALESCE, NULLIF
Le DQL représente souvent 80% de l'utilisation quotidienne de SQL pour les analystes de
données.

DCL : Data Control Language (Langage de Contrôle des Données)

Le DCL gère les autorisations et la sécurité d'accès aux données. Il contrôle qui peut faire
quoi sur quels objets de la base.
Commandes principales du DCL :
GRANT : attribution de privilèges
GRANT SELECT, INSERT ON clients TO utilisateur_analyse;
GRANT ALL PRIVILEGES ON database_ventes TO admin_ventes;
REVOKE : retrait de privilèges
REVOKE INSERT ON clients FROM utilisateur_analyse;
REVOKE ALL PRIVILEGES ON database_ventes FROM ancien_employee;

Types de privilèges gérés :

• Privilèges système : création de bases, d'utilisateurs
• Privilèges objet : SELECT, INSERT, UPDATE, DELETE sur des tables spécifiques
• Privilèges de rôle : ensembles de privilèges regroupés logiquement

Fonctionnalités avancées du DQL :

• Jointures : combinaison de données de plusieurs tables
• Sous-requêtes : requêtes imbriquées pour des analyses complexes
• Fonctions d'agrégation : COUNT, SUM, AVG, MIN, MAX
• Expressions conditionnelles : CASE, COALESCE, NULLIF

Le DQL représente souvent 80% de l'utilisation quotidienne de SQL pour les analystes de
données.

DCL : Data Control Language (Langage de Contrôle des Données)

Le DCL gère les autorisations et la sécurité d'accès aux données. Il contrôle qui peut faire
quoi sur quels objets de la base.

Commandes principales du DCL :

GRANT : attribution de privilèges
GRANT SELECT, INSERT ON clients TO utilisateur_analyse;
GRANT ALL PRIVILEGES ON database_ventes TO admin_ventes;
REVOKE : retrait de privilèges
REVOKE INSERT ON clients FROM utilisateur_analyse;
REVOKE ALL PRIVILEGES ON database_ventes FROM ancien_employee;

Types de privilèges gérés :

• Privilèges système : création de bases, d'utilisateurs
• Privilèges objet : SELECT, INSERT, UPDATE, DELETE sur des tables spécifiques
• Privilèges de rôle : ensembles de privilèges regroupés logiquement
Tableau récapitulatif des sous-langages
Sous-langage Objectif Commandes principales Utilisateurs types
DDL Structure des données CREATE, ALTER, DROP DBA, Développeurs
DML Manipulation des données INSERT, UPDATE, DELETE Tous utilisateurs
DQL Interrogation des données SELECT Analystes, Utilisateurs
DCL Sécurité et accès GRANT, REVOKE Administrateurs sécurité
TCL Gestion des transactions COMMIT, ROLLBACK Développeurs, DBA

Cette organisation modulaire de SQL permet d'adapter l'apprentissage aux besoins

spécifiques de chaque profil professionnel.

Quiz 4 : Sous-langages SQL

1. À quel sous-langage appartient la commande CREATE TABLE ?
2. Si vous voulez donner le droit de lecture sur une table à un utilisateur, quelle commande
utilisez-vous ?
3. Quelle commande permet d'annuler une transaction en cours ?
Réponses : 1) DDL 2) GRANT SELECT 3) ROLLBACK
Partie 5 : Structure d'une requête SQL
La maîtrise de la structure des requêtes SQL est fondamentale pour manipuler efficacement
les données. Une requête SQL suit un ordre logique précis qui détermine comment les
données sont récupérées, filtrées et présentées.
Anatomie d’une requête SELECT
La requête SELECT constitue le cœur du langage SQL pour l'extraction de données. Sa
structure standard suit cette séquence :
SELECT colonnes_à_afficher
FROM table_source
WHERE conditions_de_filtrage
GROUP BY colonnes_de_groupement
HAVING conditions_sur_groupes
ORDER BY colonnes_de_tri
LIMIT nombre_de_résultats;
Détail de chaque clause
SELECT : Spécification des colonnes
La clause SELECT détermine quelles informations seront retournées :
-- Sélection de colonnes spécifiques
SELECT nom, prenom, age FROM clients;
-- Sélection de toutes les colonnes (à éviter en production)
SELECT * FROM clients;
-- Calculs et alias
SELECT
nom,
prenom,
YEAR(CURRENT_DATE) - YEAR(date_naissance) AS age_calcule,
salaire * 12 AS salaire_annuel
FROM employes;
FROM : Source des données
FROM spécifie la ou les tables sources des données :
-- Table simple
SELECT nom FROM clients;
-- Jointures de plusieurs tables
SELECT [Link], com.date_commande, [Link]
FROM clients c
JOIN commandes com ON [Link] = com.client_id;
WHERE : Filtrage des enregistrements
WHERE applique des conditions pour filtrer les données avant tout traitement :
-- Conditions simples
SELECT * FROM produits WHERE prix > 100;
-- Conditions multiples
SELECT * FROM clients
WHERE age >= 18
AND ville = 'Paris'
AND actif = true;
-- Conditions avec motifs
SELECT * FROM clients WHERE nom LIKE 'Dup%';
-- Conditions avec listes
SELECT * FROM produits WHERE categorie IN ('Electronique', 'Informatique');
GROUP BY : Regroupement des données
GROUP BY organise les résultats en groupes pour appliquer des fonctions d'agrégation :
-- Regroupement simple avec comptage
SELECT ville, COUNT(*) as nombre_clients
FROM clients
GROUP BY ville;
-- Regroupement multiple avec plusieurs agrégations
SELECT
YEAR(date_commande) as annee,
MONTH(date_commande) as mois,
COUNT(*) as nombre_commandes,
SUM(montant) as chiffre_affaires,
AVG(montant) as montant_moyen
FROM commandes
GROUP BY YEAR(date_commande), MONTH(date_commande);
HAVING : Filtrage après regroupement
HAVING applique des conditions sur les résultats des fonctions d'agrégation :
-- Filtrage des groupes
SELECT ville, COUNT(*) as nombre_clients
FROM clients
GROUP BY ville
HAVING COUNT(*) > 10;
-- Conditions complexes sur agrégations
SELECT
categorie,
AVG(prix) as prix_moyen
FROM produits
GROUP BY categorie
HAVING AVG(prix) > 50 AND COUNT(*) >= 5;
ORDER BY : Tri des résultats
ORDER BY organise les résultats selon un ou plusieurs critères de tri :
-- Tri croissant (par défaut)
SELECT nom, prenom FROM clients ORDER BY nom;
-- Tri décroissant
SELECT nom, salaire FROM employes ORDER BY salaire DESC;
-- Tri multiple
SELECT ville, nom, prenom
FROM clients
ORDER BY ville ASC, nom ASC, prenom ASC;
-- Tri sur des calculs
SELECT nom, salaire, salaire * 12 as salaire_annuel
FROM employes
ORDER BY salaire_annuel DESC;
LIMIT : Limitation du nombre de résultats
LIMIT contrôle le nombre d'enregistrements retournés :
-- Les 10 premiers résultats
SELECT * FROM produits ORDER BY prix DESC LIMIT 10;
-- Pagination (OFFSET varie selon le SGBD)
SELECT * FROM clients ORDER BY nom LIMIT 20 OFFSET 40; -- MySQL/PostgreSQL
SELECT TOP 20 * FROM clients ORDER BY nom; -- SQL Server

Ordre d'exécution logique

Il est crucial de comprendre que l'ordre d'écriture des clauses diffère de l'ordre d'exécution :

Ordre d'écriture :
1. SELECT
2. FROM
3. WHERE
4. GROUP BY
5. HAVING
6. ORDER BY
7. LIMIT

Ordre d'exécution logique :

1. FROM (identification des tables)
2. WHERE (filtrage des lignes)
3. GROUP BY (regroupement)
4. HAVING (filtrage des groupes)
5. SELECT (sélection des colonnes)
6. ORDER BY (tri des résultats)
7. LIMIT (limitation du nombre de résultats)
Cette différence explique pourquoi certaines références ne sont possibles qu'à certains
moment (par exemple, impossible d'utiliser un alias de SELECT dans WHERE).

Exemples pratiques complets

Analyse des ventes par région :

SELECT
r.nom_region,
COUNT([Link]) as nombre_ventes,
SUM([Link]) as chiffre_affaires,
AVG([Link]) as panier_moyen,
MAX(v.date_vente) as derniere_vente
FROM ventes v
JOIN clients c ON v.client_id = [Link]
JOIN regions r ON c.region_id = [Link]
WHERE v.date_vente >= '2024-01-01'
GROUP BY r.nom_region
HAVING COUNT([Link]) >= 100
ORDER BY chiffre_affaires DESC
LIMIT 10;

Top des produits les plus vendus :

SELECT
p.nom_produit,
p.prix_unitaire,
SUM([Link]) as quantite_totale,
SUM([Link] * p.prix_unitaire) as revenus_generes
FROM produits p
JOIN lignes_commande lc ON [Link] = lc.produit_id
JOIN commandes c ON lc.commande_id = [Link]
WHERE [Link] = 'Livree'
AND c.date_commande >= DATE_SUB(CURRENT_DATE, INTERVAL 3 MONTH)
GROUP BY [Link], p.nom_produit, p.prix_unitaire
HAVING SUM([Link]) > 0
ORDER BY quantite_totale DESC, revenus_generes DESC
LIMIT 20;

Quiz 5 : Structure des requêtes

1. Dans quel ordre logique s'exécutent WHERE et GROUP BY ?
2. Peut-on utiliser un alias défini dans SELECT dans la clause WHERE ? Pourquoi ?
3. Quelle différence entre WHERE et HAVING ?
Réponses : 1) WHERE puis GROUP BY 2) Non, car WHERE s'exécute avant SELECT 3)
WHERE filtre les
lignes, HAVING filtre les groupes après agrégation
Partie 6 : Bonnes pratiques SQL
L'adoption de bonnes pratiques SQL est essentielle pour développer des requêtes efficaces,
sécurisées et maintenables. Ces recommandations couvrent la performance, la sécurité et la
lisibilité du code.
Optimisation des performances
Éviter SELECT *(all)

L'utilisation de SELECT * est fortement déconseillée en production :

-- Mauvaise pratique
SELECT * FROM clients WHERE ville = 'Paris';
-- Bonne pratique
SELECT id, nom, prenom, email FROM clients WHERE ville = 'Paris';

Il est donc conseillé de sélectionner les colonnes dont on aura besoin pour gagner en
performance.

Raisons d'éviter SELECT * :

• Transfert de données inutiles sur le réseau
• Consommation mémoire excessive
• Performances dégradées sur les grandes tables
• Code fragile face aux modifications de structure
• Difficultés d'optimisation pour le moteur SQL

Utilisation efficace des index

Les index accélèrent considérablement les requêtes lorsqu'ils sont bien utilisés :
-- Création d'index sur les colonnes fréquemment filtrées
CREATE INDEX idx_clients_ville ON clients(ville);
CREATE INDEX idx_commandes_date ON commandes(date_commande);
-- Requête optimisée avec utilisation d'index
SELECT nom, prenom FROM clients WHERE ville = 'Paris'; -- Utilise idx_clients_ville
Index composites pour les requêtes multi-critères :
-- Index composite sur plusieurs colonnes
CREATE INDEX idx_commandes_client_date ON commandes(client_id, date_commande);
-- Requête bénéficiant de l'index composite
SELECT * FROM commandes
WHERE client_id = 123 AND date_commande >= '2024-01-01';

Optimisation des jointures

-- Bonne pratique : spécifier les conditions de jointure clairement
SELECT [Link], com.date_commande
FROM clients c
INNER JOIN commandes com ON [Link] = com.client_id
WHERE [Link] = true;
-- Éviter les jointures cartésiennes accidentelles
SELECT [Link], com.date_commande
FROM clients c, commandes com; -- Produit cartésien = très lent !
Sécurité et prévention des injections SQL
Utilisation de requêtes paramétrées
Les requêtes paramétrées constituent la défense principale contre les injections SQL :
-- Vulnérable aux injections SQL
SELECT * FROM users WHERE username = '" + userInput + "' AND password = '" +
passInput + "'";
-- Requête paramétrée sécurisée (syntaxe dépend du langage)
-- En Java avec PreparedStatement :
String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement stmt = [Link](sql);
[Link](1, username);
[Link](2, password);

Validation et nettoyage des entrées

-- Validation stricte des formats attendus
-- Exemple : validation d'un ID numérique
WHERE id = CAST(@user_input AS INTEGER) -- Force la conversion numérique
-- Utilisation de listes blanches pour les valeurs autorisées
WHERE status IN ('active', 'inactive', 'pending') -- Seules ces valeurs sont acceptées

Principe du moindre privilège

-- Créer des utilisateurs avec des droits limités
CREATE USER 'app_reader'@'localhost' IDENTIFIED BY 'strong_password';
GRANT SELECT ON database_prod.clients TO 'app_reader'@'localhost';
-- Éviter les privilèges excessifs
GRANT ALL PRIVILEGES ON *.* TO 'app_user'@'%'; -- Trop permissif !

Lisibilité et maintenabilité du code

Utilisation d'alias explicites
-- Alias clairs et cohérents
SELECT
[Link] AS nom_client,
[Link] AS prenom_client,
com.date_commande,
com.montant_total
FROM clients c
JOIN commandes com ON [Link] = com.client_id
WHERE c.date_inscription >= '2024-01-01';
Formatage et indentation
-- Code bien formaté et lisible
SELECT
r.nom_region,
COUNT([Link]) AS nombre_ventes,
SUM([Link]) AS chiffre_affaires,
AVG([Link]) AS panier_moyen
FROM ventes v
INNER JOIN clients c ON v.client_id = [Link]
INNER JOIN regions r ON c.region_id = [Link]
WHERE v.date_vente BETWEEN '2024-01-01' AND '2024-12-31'
 AND [Link] = 'confirmee'
GROUP BY [Link], r.nom_region
HAVING COUNT([Link]) >= 10
ORDER BY chiffre_affaires DESC;
Documentation et commentaires
-- Analyse des performances commerciales par région
-- Objectif : identifier les régions les plus rentables sur l'année 2024
-- Auteur : Équipe Data Analytics
-- Date : 2024-03-15
SELECT
r.nom_region,
COUNT([Link]) AS nombre_ventes, -- Nombre total de transactions
SUM([Link]) AS chiffre_affaires, -- CA total de la région
AVG([Link]) AS panier_moyen, -- Valeur moyenne des transactions
-- Calcul du taux de croissance vs année précédente
ROUND(
(SUM([Link]) - LAG(SUM([Link])) OVER (ORDER BY r.nom_region))
/ LAG(SUM([Link])) OVER (ORDER BY r.nom_region) * 100,
2
) AS taux_croissance_pct
FROM ventes v
INNER JOIN clients c ON v.client_id = [Link]
INNER JOIN regions r ON c.region_id = [Link]
WHERE v.date_vente >= '2024-01-01'
AND [Link] = 'confirmee' -- Uniquement les ventes validées
GROUP BY [Link], r.nom_region
HAVING COUNT([Link]) >= 10 -- Minimum 10 ventes pour être significatif
ORDER BY chiffre_affaires DESC;

Gestion des erreurs et tests

Vérification de l'intégrité des données

-- Test de cohérence : vérifier que toutes les commandes ont un client valide
SELECT COUNT(*) AS commandes_orphelines
FROM commandes c
LEFT JOIN clients cl ON c.client_id = [Link]
WHERE [Link] IS NULL;
-- Test de logique métier : détecter les montants négatifs anormaux
SELECT COUNT(*) AS montants_negatifs_suspects
FROM commandes
WHERE montant_total < 0;
Gestion transactionnelle appropriée
-- Transaction complète avec gestion d'erreur
BEGIN TRANSACTION;
-- Mise à jour du stock
UPDATE produits
SET stock_disponible = stock_disponible - 5
WHERE id = 123;

-- Vérification de la cohérence
IF (SELECT stock_disponible FROM produits WHERE id = 123) < 0
BEGIN
ROLLBACK TRANSACTION;
PRINT 'Erreur : Stock insuffisant';
END
ELSE
BEGIN
-- Enregistrement de la vente
INSERT INTO ventes (produit_id, quantite, date_vente)
VALUES (123, 5, CURRENT_DATE);

COMMIT TRANSACTION;
PRINT 'Transaction réussie';
END
Recommandations pour l'analyse de données
Optimisation des requêtes analytiques
-- Utilisation efficace des CTEs (Common Table Expressions) pour la lisibilité
WITH ventes_mensuelles AS (
SELECT
DATE_TRUNC('month', date_vente) AS mois,
SUM(montant) AS ca_mensuel
FROM ventes
WHERE date_vente >= '2024-01-01'
GROUP BY DATE_TRUNC('month', date_vente)
),
moyenne_mobile AS (
SELECT
mois,
ca_mensuel,
AVG(ca_mensuel) OVER (
ORDER BY mois
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
) AS moyenne_3_mois
FROM ventes_mensuelles
)
SELECT * FROM moyenne_mobile ORDER BY mois;
Documentation des analyses
/*
Analyse de cohorte des clients

Objectif : Analyser le comportement d'achat des clients par cohorte d'inscription

Méthode : Segmentation par mois d'inscription et suivi des achats
Utilisation : Tableau de bord direction commerciale
Fréquence de mise à jour : Mensuelle
*/

Ces bonnes pratiques, appliquées systématiquement, garantissent des requêtes SQL

performantes, sécurisées et maintenables dans le temps.

Quiz final : Bonnes pratiques

1. Pourquoi éviter SELECT * en production ?
2. Quelle est la meilleure défense contre les injections SQL ?
3. À quoi servent les index dans une base de données ?
Réponses : 1) Performance dégradée et transfert de données inutiles 2) Les requêtes
paramétrées 3)
Accélérer les requêtes en évitant les parcours complets de table
Conclusion
SQL est un outil incontournable pour tout professionnel travaillant avec des données. Cette
introduction vous a donné les bases nécessaires pour comprendre et utiliser efficacement ce
langage universel des bases de données relationnelles.
Points clés à retenir :
• SQL est un langage déclaratif standardisé et universel
• Les systèmes OLTP et OLAP répondent à des besoins complémentaires
• Les propriétés ACID garantissent la fiabilité des transactions
• Les cinq sous-langages SQL couvrent tous les aspects de la gestion des données
• Une requête SQL suit une structure logique précise et prévisible
• Les bonnes pratiques sont essentielles pour la performance et la sécurité
Cette fondation solide vous permettra d'approfondir vos compétences SQL et d'aborder
sereinement les défis de l'analyse de données moderne. La pratique régulière et l'application
de ces concepts sur des projets concrets consolideront votre maîtrise de ce langage
essentiel.