Relevé SQL
Onze séquences pour interroger puis modifier deux tables — les départements et leurs communes — suivies d'un bac à sable. Chaque requête est réellement exécutée par SQLite, dans votre navigateur.
Petite histoire — pourquoi toutes les bases se ressemblent
1970. Edgar F. Codd, mathématicien britannique employé par IBM en Californie, publie un article qui va tout changer : A Relational Model of Data for Large Shared Data Banks. Jusque-là, interroger des données supposait de savoir où elles étaient rangées et par quel chemin y accéder ; le programme devait connaître la plomberie. Codd propose l'inverse : rangeons tout dans de simples tables, et laissons la machine trouver le chemin. On lui décrit ce qu'on veut, pas comment l'obtenir.
1985. Quinze ans plus tard, les éditeurs collent l'étiquette « relationnel » sur à peu près n'importe quel produit. Agacé, Codd publie dans Computerworld une liste de critères pour trancher. Elle est restée célèbre sous le nom des douze règles de Codd — sauf qu'il les numérote à partir de zéro, la règle 0 étant la règle fondatrice. Elles sont donc treize. Le nom, lui, n'a jamais été corrigé.
En voici quelques-unes, celles dont vous verrez les conséquences dans ce tutoriel :
- 0Un système qui se dit relationnel doit gérer la base entièrement par ses capacités relationnelles. Pas de porte dérobée.
- 1Toute information est représentée d'une seule façon : une valeur, à l'intersection d'une ligne et d'une colonne.
- 3Les valeurs manquantes sont traitées de façon systématique, indépendamment du type de la donnée. C'est le
NULLde la séquence 7. - 4La description de la base est elle-même stockée dans des tables, interrogeables avec le même langage que les données.
- 5Un langage unique doit tout couvrir : définir les tables, les interroger, les modifier, poser les contraintes, gérer les droits et les transactions.
- 8 · 9Changer le stockage physique ou réorganiser les tables ne doit pas casser les requêtes existantes.
La règle 5 est celle qui vous concerne directement. Ce langage unique, IBM l'avait justement en chantier depuis 1974 sur le projet System R : SEQUEL, rebaptisé SQL. L'ANSI le normalise en 1986, l'ISO l'année suivante, et les versions successives l'enrichissent depuis.
D'où la situation d'aujourd'hui. Tous les grands systèmes — PostgreSQL, MySQL, Oracle, SQL Server, SQLite — visent le même modèle et parlent le même langage. Le SELECT … FROM … WHERE de ce tutoriel s'exécute à l'identique partout. Les écarts se logent dans les marges : le LIMIT de la séquence 5 s'écrit TOP chez SQL Server et FETCH FIRST dans la norme récente ; les fonctions de dates et de texte varient d'un éditeur à l'autre. Le noyau, lui, ne bouge pas.
L'ironie de l'histoireAucun système commercial n'a jamais coché les treize règles, et Codd lui-même jugeait SQL infidèle à son modèle : les lignes en double et le traitement des NULL lui déplaisaient particulièrement. Un compromis imparfait, donc — mais un compromis que le monde entier a adopté.
Le jeu de données
Deux tables : departement (code, nom, region, population) et commune (id, nom, code_departement, population). Le code du département est la clé qui relie les deux.
Deux anomalies y ont été glissées volontairement, elles serviront à partir de la séquence 6 : un département n'a aucune commune enregistrée, et une commune porte un code de département absent du référentiel. Chiffres arrondis, à but pédagogique uniquement.

