C'est quoi une base de données ?

Avant de commencer

Pourquoi les bases de données sont partout

Ton réseau social mémorise des millions de comptes et de messages. Une boutique en ligne, ses produits et commandes. GLPI (que tu as installé), tout ton parc. Tout ça vit dans une base de données : un endroit conçu pour stocker beaucoup d'informations, de façon organisée, et les retrouver vite. C'est la 2e grande compétence du développeur, après savoir construire des pages.

Ce que tu sauras faire à la fin

0. Pourquoi pas juste un fichier ?

On pourrait stocker des infos dans un fichier texte ou un tableur (Excel). Pour quelques lignes, ça va. Mais dès qu'il y a beaucoup de données, ou plusieurs personnes qui y accèdent en même temps, ça casse. La base de données est faite exactement pour ça.

1. Base de données & SGBD

Une base de données (BDD) est un ensemble de données organisées. Le logiciel qui la gère (stocke, protège, répond aux questions) s'appelle un SGBD (Système de Gestion de Base de Données).

Les SGBD que tu croiseras — et quand choisir quoi

Et le « NoSQL », c'est quoi ?

Tout ce qu'on voit aujourd'hui, ce sont des bases relationnelles : des tables reliées entre elles. C'est de loin le plus répandu, et c'est le socle. Mais tu entendras parler de NoSQL (« Not Only SQL ») : une autre famille de bases qui ne range pas les données en tables.

Où vit la base ? (client-serveur)

Avec un SGBD comme MySQL, la base ne vit pas « dans l'appli » : elle vit sur un serveur, et plusieurs programmes (le client) lui parlent en même temps. C'est ça qui permet les milliers d'accès simultanés promis au début.

Les clients (appli, phpMyAdmin…) envoient leurs questions au SGBD, seul gardien de la base. Lui seul lit et écrit dans les données : il évite que deux clients se marchent dessus.

2. La table : lignes & colonnes

L'unité de base, c'est la table : un tableau où chaque ligne est un enregistrement (un client, un produit…) et chaque colonne un renseignement (le nom, le prix…).

Une table « visiteur » : 3 colonnes (id, nom, ville) et 2 lignes (2 visiteurs). Chaque ligne décrit UN visiteur.

À toi : lis une table

Entraîne-toi à lire « comme une base ». Voici une table produit d'une boutique :

3. Les types de données

Chaque colonne a un type : il dit quelle sorte de donnée elle accepte. Ça évite de mettre « bonjour » dans un prix.

Les types MySQL en détail — tailles et limites exactes

NULL : la valeur absente

Parfois, on ne connaît pas une valeur : un client n'a pas donné son numéro de téléphone, une date de validation n'existe pas encore. La case reste vide. En base de données, ce vide a un nom : NULL.

NULL veut dire « pas de valeur / on ne sait pas ». Attention, ce n'est pas la même chose que 0 (le nombre zéro) ni que "" (le texte vide) :

4. La clé primaire

Problème : deux visiteurs peuvent s'appeler « Marc Dupont ». Comment les distinguer ? Avec la clé primaire : une colonne dont la valeur est unique pour chaque ligne — souvent un id qui s'incrémente automatiquement.

Même nom, mais l'id (1 et 2) les distingue sans ambiguïté.

Comment l'id est généré automatiquement

En pratique, tu ne tapes jamais l'id à la main : le SGBD l'attribue seul. Deux mécanismes courants :

5. Relier les tables

La force d'une base, c'est de relier plusieurs tables. Exemple GSB : une table visiteur et une table frais (les notes de frais). Chaque frais appartient à un visiteur.

La table « frais » contient une clé étrangère id_visiteur qui pointe vers la clé primaire de « visiteur ». C'est ce lien qui dit « ce frais appartient à ce visiteur ».

6. Les cardinalités : combien pour combien ?

On vient de relier visiteur et frais. Mais dans quel sens ? Un visiteur a-t-il un seul frais, ou plusieurs ? Et un frais, appartient-il à un ou à plusieurs visiteurs ? Cette « quantité de chaque côté » s'appelle la cardinalité.

Dans GSB, c'est clair : un visiteur engage plusieurs frais (un repas, un péage, un hôtel…), mais chaque frais appartient à un seul visiteur. On dit que c'est une relation « un à plusieurs », notée 1-N (1 d'un côté, N — « plusieurs » — de l'autre).

Le visiteur 1 (Marc) est relié à 3 frais. Côté visiteur = 1, côté frais = N. La clé étrangère id_visiteur (toujours égale à 1 ici) matérialise ce lien.

7. Penser la base avant de la créer (Merise)

Avant de créer des tables, les pros dessinent la base sur papier. La méthode française pour ça s'appelle Merise (tu la reverras toute l'année). Elle tient en 3 mots.

Le dessin qu'on fait avant de coder s'appelle le MCD (Modèle Conceptuel de Données) : des rectangles (entités) reliés par des associations, avec les cardinalités. C'est la « carte » de la base.

2 entités (VISITEUR, FRAIS), 1 association (« engage »). 1,n côté visiteur = un visiteur engage de 1 à plusieurs frais ; 1,1 côté frais = un frais appartient à exactement un visiteur.

8. Exemple guidé : du besoin aux tables

On a tous les outils (entités, attributs, relations, cardinalités, clés). On les met bout à bout sur un cas neuf, pas GSB, pour apprendre à transformer un besoin écrit en français en une vraie structure de base.

Étape 1 — Repérer les entités (→ les tables)

On souligne les « choses » dont on stocke des infos. Ici : étudiant et emprunt. Deux entités → deux tables : etudiant et emprunt.

Étape 2 — Lister les attributs (→ les colonnes)

Étape 3 — Trouver la relation et sa cardinalité

« Un étudiant emprunte plusieurs livres » et « un emprunt concerne un seul étudiant » → relation 1-N entre etudiant (côté 1) et emprunt (côté N).

Étape 4 — Placer la clé étrangère

Règle du chapitre 6 : la clé étrangère va du côté N. On ajoute donc id_etudiant dans emprunt, qui pointe vers etudiant(id).

Étape 5 — Le MLD final (les tables prêtes)

9. Éviter les répétitions : la normalisation

Pourquoi a-t-on séparé visiteur et frais en deux tables, au lieu de tout mettre dans une seule ? Regarde ce qui se passe si on entasse tout dans frais :

« Marc Dupont » et « Lyon » sont recopiés à chaque ligne. Avec 500 frais pour Marc, c'est 500 fois la même chose. Trois problèmes :

La solution, c'est ce qu'on a fait : une table visiteur (Marc écrit une seule fois) et une table frais qui ne garde que son id_visiteur. Si Marc déménage, on change une seule case.

Les 3 formes normales (1FN, 2FN, 3FN) — les règles des pros

La normalisation a des règles précises. En pratique on vise la 3FN sur tout projet sérieux :

À toi : repère les défauts

Voici une table inscription mal conçue pour un club de sport. Lis-la en analyste : qu'est-ce qui cloche ?

Indices de réflexion : qui est recopié ? Que se passe-t-il si Léa change de téléphone ? Combien de fois « Judo / lundi » est-il écrit ?

10. Les garde-fous : contraintes & index

Une base sérieuse ne se contente pas de stocker : elle fait respecter des règles pour que les données restent justes. Ces règles s'appellent des contraintes d'intégrité.

Les messages d'erreur exacts à connaître par cœur

L'index : pour aller (très) vite

Dernier mot à connaître : l'index. Quand une table grossit (des millions de lignes), retrouver « tous les frais du visiteur 1 » peut devenir lent. Un index accélère ces recherches.

Et si tout se perd ? La sauvegarde

Une base, c'est précieux : un disque qui lâche ou une fausse manip peut tout effacer. On en fait donc des sauvegardes régulières. La forme la plus courante s'appelle un dump.

11. Explorer ET créer une vraie base

Assez de théorie : on ouvre un outil, on crée une vraie base à 2 tables (visiteur + frais), on y met des données, et on la parcourt. Tout dans le navigateur, sans rien installer.

Étape 1 — Ouvrir l'outil

Va sur sqliteonline.com (un bac à sable de base de données qui marche dans le navigateur, sans installation). Tu vois trois zones : à gauche l'arbre des tables (vide pour l'instant), au centre une zone blanche où taper du SQL, et un bouton Run (▶) pour l'exécuter.

Étape 2 — Créer la table « visiteur »

Dans la zone centrale, tape ceci puis clique Run :

CREATE TABLE visiteur (
  id     INTEGER PRIMARY KEY,
  nom    TEXT NOT NULL,
  ville  TEXT
);

Étape 3 — Créer la table « frais » (avec la clé étrangère)

CREATE TABLE frais (
  id           INTEGER PRIMARY KEY,
  montant      REAL NOT NULL,
  date_frais   TEXT,
  id_visiteur  INTEGER,
  FOREIGN KEY (id_visiteur) REFERENCES visiteur(id)
);

Étape 4 — Remplir les tables (les données)

INSERT INTO visiteur (id, nom, ville) VALUES
  (1, 'Marc Dupont',  'Lyon'),
  (2, 'Sophie Martin','Paris');

INSERT INTO frais (id, montant, date_frais, id_visiteur) VALUES
  (1, 45.00, '2026-09-15', 1),
  (2, 12.50, '2026-09-16', 1),
  (3, 80.00, '2026-09-17', 2);

Étape 5 — Regarder ce qu'on a créé

SELECT * FROM frais;

id | montant | date_frais | id_visiteur
1  | 45.0    | 2026-09-15 | 1
2  | 12.5    | 2026-09-16 | 1
3  | 80.0    | 2026-09-17 | 2

Étape 6 — Parcourir dans l'arbre

À gauche, l'arbre montre maintenant tes 2 tables. Déplie frais : tu vois ses colonnes (id, montant, date_frais, id_visiteur). Clique sur le nom de la table pour afficher son contenu. Repère pour chaque table : ses colonnes, sa clé primaire (id), le nombre de lignes, et — pour frais — la clé étrangère.

Étape 7 — Voir la relation fonctionner

Petit avant-goût de SQL (la prochaine séance) pour prouver que la clé étrangère relie bien les données : « montre-moi tous les frais du visiteur n°1 ».

SELECT * FROM frais WHERE id_visiteur = 1;

id | montant | date_frais | id_visiteur
1  | 45.0    | 2026-09-15 | 1
2  | 12.5    | 2026-09-16 | 1

Tu obtiens 2 lignes : les 2 frais de Marc, et pas celui de Sophie. C'est exactement ce que promettait la relation 1-N : retrouver tout ce qui appartient à un visiteur, sans avoir recopié son nom nulle part.

SQLite vs MySQL — les différences à retenir pour GSB Ordonnances

12. Mini-projet : concevoir TA base

Tu joues maintenant l'analyste-développeur : tu conçois une base à 2 tables reliées sur un thème de ton choix (autre que GSB), tu la crées dans l'outil, et tu la documentes — comme un vrai projet.

Choisis un thème

Par exemple : artiste / album, équipe / joueur, client / commande, auteur / livre… L'important : une relation 1-N (un côté « 1 », un côté « plusieurs »).

La mission (dans sqliteonline)

1. Décide tes 2 entités et leurs attributs (au moins 3 colonnes par table), avec un type par colonne.
2. Choisis la clé primaire de chacune (un id INTEGER PRIMARY KEY).
3. Place la clé étrangère du bon côté (le « N ») et fais-la pointer vers l'autre table.
4. Écris les CREATE TABLE (avec NOT NULL sur ce qui est obligatoire) et exécute-les.
5. Ajoute au moins 2 lignes par table avec INSERT, dont un côté « 1 » qui possède plusieurs lignes côté « N ».
6. Vérifie avec SELECT * FROM ...; sur tes deux tables.

Chapitre 12 bis — La base GSB Ordonnances vue de l'intérieur

Tu connais maintenant les tables, les types, les clés, les relations et la normalisation. Voici la base réelle de ton projet de l'année — GSB Ordonnances — lue avec ces outils.

Les entités et leurs colonnes clés

GSB Ordonnances : 6 tables, des relations 1-1, 1-N et N-N. Tout ce que tu as appris dans ce playbook, en vrai.

13. Les pièges du débutant

Avant de refermer, les 4 erreurs de conception que tout le monde fait au début. Les connaître, c'est déjà ne plus les commettre. Pour chacune : le piège, pourquoi c'est mauvais, et la bonne réflexe.

Pour finir

Ton antisèche (le vocabulaire)

Vérifie tes acquis

1. Pourquoi une base de données plutôt qu'un fichier Excel pour beaucoup de données ?
2. Différence entre une base de données et un SGBD ?
3. Dans une table, qu'est-ce qu'une ligne ? une colonne ?
4. À quoi sert le type d'une colonne ? Et que veut dire NULL ?
5. À quoi sert la clé primaire ?
6. Qu'est-ce qu'une clé étrangère, et que permet-elle ?
7. Une relation 1-N : de quel côté place-t-on la clé étrangère ?
8. Pourquoi normalise-t-on (séparer en plusieurs tables) ?
9. Cite deux contraintes d'intégrité et ce qu'elles imposent.

Glossaire