#Bases de données et SQL : introductionCopier le lien

Ce cours vous accompagne de l’idée « j’ai des données à organiser » jusqu’aux requêtes qui répondent à des questions concrètes. Plutôt que d’empiler de la syntaxe, on installe un modèle mental : des tables bien pensées, des liens explicites entre elles, et des requêtes lisibles qu’on sait mesurer et améliorer au besoin.

Contexte pédagogique : ce module correspond au niveau L2 (Valrose, UCA) et prépare aux projets où des choix de modélisation et des requêtes robustes sont exigés.

#Deux définitions pour commencerCopier le lien

Base de données : une collection partagée de données en relation logique, accompagnée d'une description de ces données, conçue pour satisfaire les besoins d'information d'une organisation. Deux mots comptent : partagée (plusieurs utilisateurs, plusieurs applications) et description (le schéma, qui est lui-même une donnée).

Système de gestion de base de données (SGBD) : le logiciel qui permet à des utilisateurs de définir, créer et mettre à jour une base de données, et d'en contrôler l'accès. Un SGBD offre deux langages distincts, et cette séparation structure tout le module :

• le langage de définition de données (LDD) décrit la structure : create table, alter table, contraintes, index, droits ;
• le langage de manipulation de données (LMD) interroge et modifie le contenu : select, insert, update, delete.

SQL couvre les deux, ce qui explique qu'une même session serve à créer le schéma puis à l'interroger.

#Ce qu'un SGBD doit assurerCopier le lien

Un tableur sait afficher des lignes et des colonnes. Un SGBD doit en plus tenir ces engagements, et chacun correspond à un chapitre du module :

• gérer de très grandes quantités de données et y répondre vite (sections Index et Plans d'exécution) ;
• contrôler la redondance de l'information (section Normalisation) ;
• partager les données entre utilisateurs et gérer les accès concurrents (section Transactions) ;
• gérer les autorisations d'accès et la sécurité ;
• offrir des interfaces d'accès multiples ;
• vérifier les contraintes d'intégrité (section Modélisation) ;
• assurer la reprise après panne (journalisation, durabilité).

#D'où vient le modèle relationnelCopier le lien

Le modèle relationnel est un modèle logique proposé en 1970 par Ted Codd, aux laboratoires IBM. Il repose sur trois appuis mathématiques : la notion de relation au sens de la théorie des ensembles, la théorie des ensembles elle-même, et la logique des prédicats du premier ordre. C'est ce socle qui rend l'algèbre relationnelle possible : manipuler des relations avec des opérations dont on peut démontrer les propriétés.

Le premier système commercial arrive en 1980 (Oracle, avec SQL/DS), suivi de DB2, Informix, Oracle, SQL Server, Ingres, Sybase, Access, MySQL. Aujourd'hui PostgreSQL et SQLite perpétuent le même modèle ; le vocabulaire a changé, la théorie non.

Côté langage, SQL est un langage orienté transformation : on décrit le résultat voulu, pas la suite d'opérations pour l'obtenir. Son histoire explique sa syntaxe parfois incohérente, parce que chaque version a ajouté des briques sans pouvoir casser les précédentes :

#PrérequisCopier le lien

Aucune connaissance préalable en base de données n’est supposée. Trois appuis aident :

• savoir lire un tableau lignes/colonnes et distinguer une colonne d’une ligne ;
• avoir croisé la notion de type (entier, texte, booléen) dans n’importe quel langage, par exemple Python ;
• pour les sections Index et Plans d’exécution, quelques notions de complexité (ordre de grandeur, logarithme) rendent les raisonnements plus nets, mais rien n’y est bloquant.

#Objectifs d’apprentissageCopier le lien

• Traduire un énoncé métier en schéma relationnel : entités, attributs, clés, cardinalités.
• Écrire des requêtes fiables : filtres, tris, jointures, agrégations, et NULL sous contrôle.
• Reconnaître les équivalences entre algèbre relationnelle et SQL.
• Normaliser un schéma (1NF à BCNF) et savoir quand s’arrêter.
• Mesurer une requête avec EXPLAIN, poser les bons index, encapsuler les mises à jour en transactions ACID.

#Poser une question à la baseCopier le lien

Une requête SELECT répond à quatre questions : quelles colonnes, quelles lignes, dans quel ordre, et combien. Afficher les 3 derniers utilisateurs par identifiant :

1select id, name2from users3order by id desc4limit 3;

Le moteur suit un ordre logique : FROM, puis WHERE, puis GROUP BY, HAVING, SELECT, ORDER BY et enfin LIMIT. Deux conséquences concrètes : WHERE filtre avant le SELECT et ne voit donc pas ses alias ; ORDER BY, évalué après, les voit.

#Tisser des liens : les jointuresCopier le lien

Relier des tables par clés (primaires, étrangères) reconstruit l’information dispersée. Un INNER JOIN ne garde que les correspondances ; un LEFT JOIN conserve toutes les lignes de gauche, complétées par des NULL en cas d’absence.

1select u.name, o.amount2from users u3left join orders o on o.user_id = u.id;

Pensez cardinalité : une relation 1 vers N multiplie les lignes. Si vous agrégerez ensuite, placez le GROUP BY après la jointure et vérifiez vos totaux.

#Résumer : agrégations par groupeCopier le lien

GROUP BY forme des groupes ; COUNT, SUM, AVG, MIN, MAX calculent des résumés. HAVING filtre les groupes déjà calculés, WHERE filtre les lignes en amont.

1select user_id, sum(amount) as total2from orders3group by user_id4having total > 50;

#L’atelier interactifCopier le lien

Chaque section comporte un « playground » SQL : un moteur SQLite compilé en WebAssembly (sql.js) qui tourne entièrement dans votre navigateur. Le bouton Exécuter lance le script, Réinitialiser restaure le code de départ, Importer base charge un fichier .sql ou .sqlite, et Nouvelle base repart d’une base vide pré-remplie avec users(id, name) contenant Alice et Bob. Le résultat s’affiche en JSON dans le panneau dédié : une ligne par requête, avec ses colonnes et ses valeurs. Aucune installation, aucun serveur : vous pouvez casser, recommencer, observer.

Mini-atelier guidé (10 minutes) :

1. Supprimez puis recréez users et orders, insérez le jeu de données ci-dessous.
2. Affichez chaque utilisateur et son total de commandes, 0 si aucune : LEFT JOIN plus COALESCE.
3. Tirez le top 3 par total décroissant.

Résultat attendu (3 lignes) : Bob 117.5, Alice 100.0, Charlie 0.0. Charlie n’a aucune commande : le LEFT JOIN produit une ligne avec amount à NULL, coalesce la ramène à 0. C’est exactement le genre de vérification à faire systématiquement : comparez le nombre de lignes attendu au résultat.

#Modéliser d’abord, optimiser ensuiteCopier le lien

La normalisation élimine la redondance et les anomalies de mise à jour. Indexer les colonnes filtrées et jointes accélère les requêtes critiques. Les transactions (ACID) regroupent plusieurs opérations en une unité cohérente, indivisible au moment d’un crash. Le module déroule ces étages dans cet ordre, parce que c’est l’ordre qui produit des systèmes maintenables : schéma correct, requêtes justes, ensuite seulement performance.

#Parcours conseillé dans le moduleCopier le lien

L'ordre des sections suit l'ordre du cours, et cet ordre n'est pas cosmétique : chaque étage suppose le précédent.

1. Modélisation : relation, attribut, domaine, clé candidate, clé primaire, clé étrangère, intégrité d'entité et intégrité référentielle.
2. Algèbre relationnelle : les opérateurs, leur fermeture, et la traduction vers SQL.
3. SELECT, JOIN, Agrégations : le langage de manipulation de données, du filtre simple aux questions en « tous les ».
4. Normalisation : dépendances fonctionnelles, 1NF à 3NF puis BCNF, décomposition sans perte.
5. Index et Plans d'exécution : mesurer avant d'optimiser.
6. Transactions : ACID, sérialisabilité, graphes de précédence et de attentes, verrouillage en deux phases.
7. Annales corrigées : les sujets d'examen réellement posés, avec leurs corrections détaillées.

Les sujets d'examen de ce cours ont une signature reconnaissable : une base de données décrite en quelques lignes, une question sur les clés étrangères, deux ou trois requêtes en algèbre relationnelle, deux ou trois requêtes en SQL, et selon la session une question de normalisation ou une question de contrôle de concurrence. Les sections concernées signalent explicitement ces attentes.