Chapitre 4 : Comprendre les tables et les données

L'anatomie d'une table SQL

Maintenant que vous avez installé vos outils, plongeons dans le cœur d'une base de données : les tables. C'est là que vos données vivent, et comprendre leur structure est essentiel pour bien utiliser SQL.

📊

Analogie du jour : Le registre de bibliothèque

Une table SQL, c'est comme un registre de bibliothèque. Chaque page est une ligne (un livre), et chaque colonne est un type d'information (titre, auteur, date). SQL vous permet de feuilleter ce registre intelligemment : "Montre-moi seulement les livres de science-fiction publiés après 2010".

📖

Définition : Table SQL

Une table est une collection de données organisées en lignes et colonnes. Chaque table a un nom unique et représente un type d'objet (clients, produits, commandes...). C'est l'élément de base d'une base de données relationnelle.

Visualiser une table SQL

Examinons chaque partie d'une table avec un exemple concret :

id	nom	prenom	ville	email
1	Dupont	Jean	Paris	jean.dupont@email.com
2	Martin	Marie	Lyon	marie.martin@email.com
3	Bernard	Pierre	Marseille	pierre.bernard@email.com

📑

Colonnes (Champs)
Fondamental

Ce sont les "catégories" d'information. Dans notre exemple :

id - Numéro unique
nom - Texte
prenom - Texte
ville - Texte
email - Texte

Chaque colonne a :

Un nom unique dans la table
Un type de données (texte, nombre, date...)
Des contraintes optionnelles (obligatoire, unique...)

📝

Lignes (Enregistrements)
Fondamental

Ce sont les "entrées" individuelles. Chaque ligne représente :

Un client (dans une table clients)
Un produit (dans une table produits)
Une commande (dans une table commandes)

Caractéristiques :

Chaque ligne a les mêmes colonnes
L'ordre des lignes n'a pas d'importance
On peut avoir des valeurs manquantes (NULL)
Chaque ligne est unique (idéalement)

Exemple d'un système e-commerce complet

Une base de données bien conçue a plusieurs tables spécialisées :

👥

Table : clients

Stocke les informations des clients

id_client (clé primaire)
nom
prenom
email
date_inscription

📦

Table : produits

Catalogue des produits disponibles

id_produit (clé primaire)
nom
prix
categorie
stock

🛒

Table : commandes

En-tête des commandes

id_commande (clé primaire)
id_client (clé étrangère)
date_commande
montant_total
statut

📋

Table : details_commande

Détail de ce qui a été commandé

id_detail (clé primaire)
id_commande (clé étrangère)
id_produit (clé étrangère)
quantite
prix_unitaire

💡

Conseil de conception

Quand vous concevez une base de données, posez-vous cette question : "Quelles sont les choses (entités) dont j'ai besoin ?" Chaque "chose" importante devient une table.

Exemple pour une bibliothèque : Livres, Auteurs, Membres, Emprunts → 4 tables.

Les relations entre tables

C'est là que les bases de données relationnelles brillent ! Les tables peuvent être connectées :

🔗

Relation 1 → plusieurs

Un client peut avoir plusieurs commandes, mais une commande appartient à un seul client.

Comment : La table commandes a une colonne id_client qui fait référence au client.

-- Dans la table commandes :
CREATE TABLE commandes (
    id_commande INTEGER PRIMARY KEY,
    id_client INTEGER,
    date_commande DATE,
    FOREIGN KEY (id_client) REFERENCES clients(id_client)
);

🔗

Relation plusieurs → plusieurs

Un produit peut être dans plusieurs commandes, et une commande peut contenir plusieurs produits.

Comment : On utilise une table intermédiaire details_commande qui relie les commandes aux produits.

-- Table intermédiaire :
CREATE TABLE details_commande (
    id_detail INTEGER PRIMARY KEY,
    id_commande INTEGER,
    id_produit INTEGER,
    quantite INTEGER,
    FOREIGN KEY (id_commande) REFERENCES commandes(id_commande),
    FOREIGN KEY (id_produit) REFERENCES produits(id_produit)
);

Les clés : identifiants uniques

🔑

Définition : Clé primaire (Primary Key)

Une clé primaire est une colonne (ou combinaison de colonnes) qui identifie de manière unique chaque ligne d'une table. C'est comme un numéro de sécurité sociale pour vos données.

Table	Clé primaire suggérée	Pourquoi
clients	`id_client`	Deux clients peuvent avoir le même nom, mais pas le même ID
produits	`id_produit`	Code produit unique, même si le nom change
commandes	`id_commande`	Numéro de commande unique
employes	`matricule`	Numéro d'employé unique

Caractéristiques d'une bonne clé primaire :

✅

Unique

Pas deux fois la même valeur dans toute la table.

✅

Non nulle

Doit toujours avoir une valeur (pas de NULL).

✅

Stable

Ne change pas dans le temps (une fois assignée).

✅

Simple

Idéalement un seul champ (parfois plusieurs pour les clés composites).

Exercice : Analyser une table existante

Examinez cette table et répondez aux questions :

-- Table : films
CREATE TABLE films (
    id_film INTEGER PRIMARY KEY,
    titre TEXT NOT NULL,
    realisateur TEXT,
    annee INTEGER,
    duree_minutes INTEGER,
    genre TEXT,
    note_imdb REAL,
    a_oscar BOOLEAN
);

Questions :

Combien de colonnes cette table a-t-elle ?
Quelle est la clé primaire ?
Quelle colonne est obligatoire (ne peut pas être NULL) ?
Quels types de données sont utilisés ?
Donnez un exemple de ce que pourrait contenir une ligne.

💡

Réponses :

8 colonnes : id_film, titre, realisateur, annee, duree_minutes, genre, note_imdb, a_oscar
Clé primaire : id_film
Colonne obligatoire : titre (grâce à NOT NULL)
Types de données : INTEGER, TEXT, REAL, BOOLEAN
Exemple de ligne : (1, 'Le Parrain', 'Francis Ford Coppola', 1972, 175, 'Drame', 9.2, true)

Bonnes pratiques pour nommer les tables et colonnes

📛

Nommer les tables

Utiliser le pluriel : clients pas client
Être descriptif : details_commande pas det_cmd
Éviter les espaces : Utiliser des underscores : code_postal
Rester simple : employes pas table_des_employes_de_la_societe

📛

Nommer les colonnes

Être clair : date_naissance pas dn
Utiliser des préfixes pour les clés : id_client dans la table commandes
Rester cohérent : Si vous utilisez date_creation dans une table, utilisez le même style partout
Éviter les mots réservés : Pas date ou order (ce sont des mots-clés SQL)

⚠️

Le piège à éviter : la table "fourre-tout"

Ne mettez pas tout dans une seule table !

Mauvaise conception :

-- Table "toutes_les_donnees" (À ÉVITER !)
CREATE TABLE toutes_les_donnees (
    id INTEGER,
    type TEXT,
    nom TEXT,
    prenom TEXT,
    email TEXT,
    produit TEXT,
    prix REAL,
    quantite INTEGER,
    date_commande DATE,
    adresse TEXT,
    ville TEXT,
    telephone TEXT,
    ... et ainsi de suite ...
);

Bonne conception :

-- Tables séparées (BON !)
CREATE TABLE clients (
    id_client INTEGER PRIMARY KEY,
    nom TEXT,
    prenom TEXT,
    email TEXT,
    adresse TEXT,
    ville TEXT,
    telephone TEXT
);

-- Continuer avec produits, commandes, details_commande...

Exercice pratique : Concevoir une base de données

Imaginez que vous créez une application pour une salle de sport. Quelles tables auriez-vous besoin ?

1

Identifier les "choses" importantes

Qu'est-ce qui doit être stocké ?

Les membres (adhérents)
Les entraîneurs
Les cours (yoga, musculation...)
Les inscriptions aux cours
Les paiements

2

Créez les tables correspondantes

Une table par "chose" :

-- Structure de base :
-- 1. membres
-- 2. entraineurs
-- 3. cours
-- 4. inscriptions (lie membres et cours)
-- 5. paiements

3

Définir les colonnes principales

Pour chaque table, quelles informations sont nécessaires ?

-- Table membres :
CREATE TABLE membres (
    id_membre INTEGER PRIMARY KEY,
    nom TEXT,
    prenom TEXT,
    date_naissance DATE,
    date_inscription DATE,
    statut TEXT
);

4

Penser aux relations

Un cours a un entraîneur (relation 1 → 1)
Un membre peut s'inscrire à plusieurs cours (relation 1 → plusieurs)
Un cours peut avoir plusieurs membres (relation plusieurs → plusieurs, via la table inscriptions)

Vérification des connaissances

Question 1

Quelle est la différence entre une ligne et une colonne ?

Colonne = Type d'information (ex: "nom")
Ligne = Entrée individuelle (ex: "Dupont Jean")

Question 2

Pourquoi chaque table a-t-elle besoin d'une clé primaire ?

Pour identifier de manière unique chaque ligne
Pour créer des relations entre tables
Pour éviter les doublons

Question 3

Combien de tables faudrait-il pour gérer une bibliothèque ?

Au moins 3 : Livres, Auteurs, Emprunts (et peut-être Membres)

✅

Récapitulatif du chapitre

Vous avez maintenant appris :

La structure d'une table : lignes (enregistrements) et colonnes (champs)
Qu'une base de données bien conçue a plusieurs tables spécialisées
Le concept de clé primaire pour identifier chaque ligne de manière unique
Les différents types de relations entre tables (1→1, 1→plusieurs, plusieurs→plusieurs)
Les bonnes pratiques pour nommer tables et colonnes
Comment concevoir une base de données étape par étape
Le piège à éviter : la table "fourre-tout"
Comment analyser une table existante

Vous comprenez maintenant comment les données sont organisées dans une base de données. Dans le prochain chapitre, nous allons créer notre première base de données avec SQL !

Chapitre 3 : Installer un environnement SQL Chapitre 5 : Créer une base de données