Tables, lignes et relations

Objectifs

À la fin de cette leçon, vous saurez :

• expliquer pourquoi une base de données remplace un fichier JSON ;
• définir table, ligne, colonne, type, clé primaire et étrangère ;
• modéliser une relation simple entre utilisateurs et tâches.

Le problème du fichier JSON

Votre API du chapitre 19 stocke les tâches dans un tableau en mémoire : chaque redémarrage efface tout. Un fichier JSON corrige la persistance, mais :

• deux processus qui l'écrivent en même temps se corrompent mutuellement ;
• chercher parmi 100 000 entrées impose de tout lire ;
• aucune garantie sur les données (un champ manquant passe inaperçu).

Une base de données relationnelle apporte : écritures concurrentes sûres, index de recherche, contraintes de cohérence.

Table, ligne, colonne

TABLE users
┌────┬──────┬───────────────────┐
│ id │ nom  │ email             │
├────┼──────┼───────────────────┤
│ 1  │ Ana  │ ana@exemple.fr    │   ← une LIGNE = un enregistrement
│ 2  │ Bob  │ bob@exemple.fr    │
└────┴──────┴───────────────────┘
  ↑ clé primaire      ↑ colonnes avec TYPES (texte, entier...)

Chaque colonne a un type (integer, text, boolean, timestamptz...) : la base refuse age = "vingt" — première couche de validation gratuite.

Clé primaire et clé étrangère

La clé primaire identifie sans ambiguïté chaque ligne : typiquement id, unique et non nul.

La clé étrangère pointe vers la clé primaire d'une autre table : c'est le lien entre les tables.

users                    tasks
id  nom                  id   titre        user_id (FK → users.id)
1   Ana                  10   "Courses"     1
2   Bob                  11   "Réviser"     1
                         12   "Dormir"      2

Ana possède les tâches 10 et 11 : on lit la relation sans dupliquer son nom. La base refuse d'insérer une tâche avec user_id: 99 si cet utilisateur n'existe pas : la cohérence est garantie mécaniquement.

Les trois cardinalités

one-to-one      : un utilisateur ↔ un profil détaillé
one-to-many     : un utilisateur → plusieurs tâches       ← notre cas
many-to-many    : des étudiants ↔ des cours (table intermédiaire)

Exercice

1. Dessinez users/tasks avec leurs colonnes, types et la FK.
2. Quelle cardinalité entre étudiant et cours ? Entre personne et empreinte digitale ?
3. Que devrait-il se passer si on supprime Ana alors que ses tâches existent ?

Résumé

• BDD = persistance + concurrence sûre + contraintes.
• Table = lignes typées ; PK identifie, FK relie.
• one-to-many est LE motif central des applications web.