Introduction au langage SQL : du monde des fichiers aux bases de données

Partie 1 — Le monde des fichiers

Avant l’apparition des bases de données, chaque application gérait ses propres fichiers de données, sans logique commune de stockage.

1.1 — Comment travaillait-on avant les années 1970 ?

Cette partie est présentée en cours : prends des notes pendant l’explication.

1.2 — Des supports qui imposent leurs règles

La façon de stocker les données à cette époque n’est pas un choix : elle est dictée par les supports physiques disponibles.

• Cartes perforées : une carte = un enregistrement ; le programme lit un paquet de cartes triées, traitement obligatoirement « par lots » (batch).
• Bandes magnétiques : accès strictement séquentiel ; pour lire l’enregistrement n°1000, il faut dérouler la bande depuis le début. Aucun accès direct, contrairement à un disque.
• Langages de l’époque : COBOL domine la gestion. Sa DATA DIVISION décrit la structure du fichier directement dans le code : changer un fichier oblige donc à changer le programme.

1.3 — Exemple : le lycée « Chevrollier-sur-Fichiers »

Le service Scolarité et le service Comptabilité gèrent chacun un fichier séparé pour les mêmes élèves.

Q1. Quelle information est présente dans les deux fichiers, à ton avis ?

1.4 — Les 5 problèmes du monde des fichiers

Complète le tableau au fur et à mesure de l’explication.

Problème	Explication en une phrase (à compléter)
Redondance	…
Incohérence	…
Dépendance programme / données	…
Absence de partage	…
Sécurité limitée	…

1.5 — Nuance importante : les fichiers n’ont pas disparu

Les 5 problèmes vus juste avant concernent les données métier : partagées, structurées, interrogées. Pour d’autres usages, le fichier reste aujourd’hui le bon outil, y compris dans une infrastructure qui utilise un SGBD par ailleurs.

Usage	Exemples
Fichiers de configuration	.env, .yaml, .conf : paramètres lus au démarrage d’une application
Journaux (logs)	Écriture séquentielle en continu, rarement relue ligne à ligne
Contenus statiques	Images, vidéos, PDF : stockés sur disque ou en object storage (S3…)
Code source	Fichiers texte versionnés avec Git, indépendants de toute base

Partie 2 — La naissance des SGBD

Face aux limites du monde des fichiers, plusieurs modèles de bases de données voient le jour entre les années 1960 et 1970.

2.1 — Repères chronologiques

Date	Événement	Ce qu’il faut retenir
1966	IBM IMS	Modèle hiérarchique (arborescence)
1969	CODASYL	Modèle réseau (Charles Bachman)
1970	Modèle relationnel	Edgar F. Codd (IBM) — article fondateur
1974	System R / SEQUEL	IBM — premier prototype et premier langage
1979	Oracle	Premier SGBD relationnel commercialisé, le langage devient SQL
1986-1987	Normes ANSI / ISO	SQL devient un standard international

2.2 — IMS et CODASYL, deux approches techniques

• IMS (IBM, 1966) organise les données en arbre : chaque enregistrement « parent » a un ou plusieurs « enfants », stockés à proximité sur le disque. Le programme y accède via DL/I (Data Language/I), un jeu d’instructions appelées depuis COBOL ou PL/I.
• CODASYL (rapport du DBTG, 1969-1971, porté par Charles Bachman) assouplit ce modèle : un enregistrement peut appartenir à plusieurs « sets », reliés par des pointeurs. Le programme navigue avec des instructions comme FIND ou GET, en gardant en mémoire « où il en est » dans la structure.

2.3 — Programmer un chemin, ou décrire un résultat ?

Avec IMS et CODASYL, le programmeur est un « navigateur » : il écrit, pas à pas, comment se déplacer dans la structure. C’est l’accès navigationnel (ou procédural). Le modèle relationnel de Codd propose l’inverse : l’accès déclaratif.

	IMS / CODASYL (navigationnel)	SQL / relationnel (déclaratif)
Ce que dit le programme	COMMENT trouver la donnée, étape par étape	QUOI obtenir, sans se soucier du chemin
Connaissance requise	Il faut connaître la structure physique de la base	Aucun besoin de connaître l’organisation physique
Robustesse	Fragile : toute évolution de structure casse les programmes	Le SGBD optimise lui-même l’exécution

2.4 — Le modèle relationnel, en une phrase

Q2. D’après l’explication du cours, quelle est l’idée principale d’Edgar F. Codd en 1970 ?

2.5 — Les 12 règles de Codd (extrait)

En 1985, pour éviter que des éditeurs n’utilisent l’étiquette « relationnel » sans en respecter les principes, Codd publie douze règles de référence. En voici trois particulièrement structurantes :

• Règle 1 (représentation de l’information) : toute donnée est représentée sous forme de valeurs dans des tables, sans structure cachée.
• Règle 5 (sous-langage de données complet) : un seul langage doit permettre de définir, interroger, modifier les données et gérer les droits d’accès ; c’est ce rôle que SQL viendra remplir.
• Règle 9 (indépendance logique) : on doit pouvoir modifier la structure logique des tables sans casser les programmes existants.

Partie 3 — De la théorie au langage SQL

Le modèle relationnel de Codd est une théorie. Il fallait un langage pour l’utiliser concrètement : ce sera SQL.

3.1 — De SEQUEL à SQL

• 1974 : IBM lance le projet System R pour tester le modèle relationnel.
• Le langage créé pour interroger les données s’appelle SEQUEL (Structured English Query Language).
• SEQUEL entre en conflit avec une marque déposée : il est renommé SQL (Structured Query Language) dès la fin des années 1970.
• 1979 : la société qui deviendra Oracle commercialise le premier SGBD relationnel.

3.2 — SQL n’était pas seul : le cas INGRES

Au même moment, à l’université de Berkeley, Michael Stonebraker et Eugene Wong développent INGRES, un autre prototype de SGBD relationnel, financé par des fonds de recherche publics. Son langage s’appelle QUEL.

-- SQL (IBM)
SELECT nom FROM etudiant
WHERE id_classe = 1;

-- QUEL (INGRES, Berkeley)
RANGE OF e IS etudiant
RETRIEVE (e.nom)
WHERE e.id_classe = 1

3.3 — Premier aperçu du langage SQL

Voici à quoi ressemble une requête SQL très simple. Nous apprendrons à l’écrire au prochain cours :

SELECT nom, prenom
FROM etudiant
WHERE id_classe = 1;

Q3. À ton avis, que fait cette requête ? (traduis-la en français)

3.4 — Pourquoi standardiser SQL ?

Q4. Que se passerait-il si chaque éditeur de SGBD utilisait une version différente et incompatible de SQL ?

3.5 — Ce que chaque norme a ajouté

SQL n’est pas figé depuis 1986 : c’est un standard vivant, régulièrement enrichi.

Norme	Ce qu’elle a ajouté
SQL-86 / SQL-89	Première norme, minimale. SQL-89 ajoute les contraintes d’intégrité (clés primaires, étrangères).
SQL-92	Réécriture majeure : jointures, sous-requêtes et types de données solidement définis.
SQL:1999	Requêtes récursives, déclencheurs (triggers), extensions orientées objet.
SQL:2003 → 2016	Fonctions de fenêtrage, XML puis JSON : SQL s’adapte aux usages du Web.

Partie 4 — Du modèle conceptuel à la base de données

Avant d’écrire du SQL, on modélise le besoin avec la méthode Merise : MCD, puis MLD.

4.1 — Rappel : le MCD

Le Modèle Conceptuel de Données décrit les entités du monde réel et leurs associations, sans se soucier de la technologie utilisée ensuite.

4.2 — Du MCD au MLD : à toi de jouer

4.3 — Du MLD au SQL

Q5. Complète les instructions CREATE TABLE à partir de ton MLD ci-dessus.

CREATE TABLE classe (
    id_classe INT PRIMARY KEY,
    ......................................
);

CREATE TABLE etudiant (
    id_etudiant INT PRIMARY KEY,
    ......................................
    ......................................
    FOREIGN KEY (id_classe)
        REFERENCES classe(id_classe)
);

Synthèse — Ce qu’il faut retenir

Auto-évaluation rapide

Q1. Cite deux problèmes du monde des fichiers.

Q2. En quelle année Edgar F. Codd publie-t-il son article fondateur ?

Q3. Que signifient les sigles PK et FK ?

Q4. Quel mot-clé SQL permet de créer une table ?