Module 3 - Conception d'un Schéma Relationnel

1. Qu'est-ce qu'un Schéma Relationnel ? Le Plan de Votre Maison de Données

Un schéma relationnel est le plan d'architecte de votre base de données. Il ne contient pas les données elles-mêmes, mais il décrit :

Les pièces de la maison (les tables).
Ce que chaque pièce contient (les colonnes ou attributs).
Comment les pièces sont connectées par des portes et des couloirs (les relations).

Analogie

Sans un bon plan, vous pourriez construire une maison avec la salle de bain au milieu du salon et sans porte pour y accéder. De la même manière, sans un bon schéma, vous vous retrouverez avec des données incohérentes, difficiles à interroger et impossibles à maintenir.

Les 5 Étapes de la Conception d'un Schéma

La conception d'un schéma est un processus de réflexion qui se déroule avant d'écrire la moindre ligne de code SQL.

→ Étape 1 : Identifier les Entités (Les "Noms" de votre Histoire)

Qu'est-ce qu'une entité ? Une entité est un "objet" ou un concept distinct sur lequel vous voulez stocker des informations. C'est le sujet principal de votre base de données.

Comment les trouver ? Lisez la description de votre projet et surlignez tous les noms importants.

Exemple : "Un site de blog où des auteurs peuvent écrire des articles. Chaque article peut être classé dans plusieurs catégories."

Nos entités candidates sont : Auteurs, Articles, Catégories.

→ Étape 2 : Définir les Attributs et les Clés Primaires

Quels sont les attributs ? Ce sont les caractéristiques, les informations spécifiques que vous voulez stocker pour chaque entité. Ils deviendront les colonnes de vos tables.

La Clé Primaire (PK) : Pour chaque entité, vous devez choisir un attribut qui servira d'identifiant unique et non modifiable. C'est la clé primaire. La meilleure pratique est d'utiliser un id numérique qui s'incrémente automatiquement.

Exemple (suite) :

Auteur : id (PK), nom, email.
Article : id (PK), titre, contenu, date_publication.
Catégorie : id (PK), nom_categorie.

→ Étape 3 : Identifier les Relations et les Clés Étrangères

C'est l'étape la plus cruciale. Vous devez définir comment vos entités interagissent en utilisant des clés étrangères (FK). Une clé étrangère est une colonne dans une table qui fait référence à la clé primaire d'une autre table.

Relation Un-à-Plusieurs (1:N) : La plus courante

Question : "Un Auteur peut-il avoir plusieurs Articles ?" → Oui. "Un Article peut-il avoir plusieurs Auteurs ?" → Non (dans notre cas).
Relation : Auteurs 1 <---> N Articles.
Implémentation : On ajoute une clé étrangère (FK) dans la table du côté "plusieurs". La table Articles aura une colonne auteur_id qui fera référence à l'id de la table Auteurs.

Relation Plusieurs-à-Plusieurs (N:M)

Question : "Un Article peut-il avoir plusieurs Catégories ?" → Oui. "Une Catégorie peut-elle contenir plusieurs Articles ?" → Oui.
Relation : Articles N <---> M Catégories.
Implémentation : On ne peut pas les lier directement. On doit créer une table de jonction.

→ Étape 4 : La Normalisation (L'Art de Ranger Proprement)

Qu'est-ce que c'est ? La normalisation est un ensemble de règles qui visent à organiser vos tables pour réduire la redondance des données et améliorer leur intégrité.

Pourquoi est-ce important ? Pour éviter les "anomalies". Si le nom d'une catégorie est stocké dans 100 articles différents, un changement de nom nécessiterait 100 mises à jour ! C'est une source de bugs.

Première Forme Normale (1NF)

Pour les débutants, la règle la plus importante est la Première Forme Normale (1NF) :

Chaque cellule d'une table doit contenir une seule et unique valeur.

Exemple (NON normalisé) :

article_id	titre	categories
1	Mon Titre	"Tech, Java, Programmation"

Ceci viole la 1NF. La colonne categories contient plusieurs valeurs. La solution est de créer une table séparée pour les catégories et une table de jonction, comme nous l'avons vu à l'étape 3.

→ Étape 5 : Traduire le Modèle en Schéma SQL

C'est l'étape finale où notre plan conceptuel devient du code CREATE TABLE.

Exemple (suite du blog) :

-- Table pour l'entité Auteur
CREATE TABLE Auteurs (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nom VARCHAR(100) NOT NULL,
    email VARCHAR(255) NOT NULL UNIQUE
);

-- Table pour l'entité Catégorie
CREATE TABLE Categories (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nom_categorie VARCHAR(50) NOT NULL UNIQUE
);

-- Table pour l'entité Article, avec la relation 1:N vers Auteurs
CREATE TABLE Articles (
    id INT PRIMARY KEY AUTO_INCREMENT,
    titre VARCHAR(255) NOT NULL,
    contenu TEXT,
    date_publication TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    auteur_id INT,
    FOREIGN KEY (auteur_id) REFERENCES Auteurs(id)
);

-- Table de jonction pour la relation N:M entre Articles et Catégories
CREATE TABLE Article_Categories (
    article_id INT,
    categorie_id INT,
    PRIMARY KEY (article_id, categorie_id), -- Garantit qu'une paire article/catégorie est unique
    FOREIGN KEY (article_id) REFERENCES Articles(id),
    FOREIGN KEY (categorie_id) REFERENCES Categories(id)
);

Schéma Visuel (Diagramme Entité-Relation) :

Voici une représentation visuelle de la manière dont ces tables sont connectées :

Diagramme Entité-Relation du système de blog

La relation Auteurs → Articles est de type Un-à-Plusieurs. Un auteur peut avoir plusieurs articles.
La relation Articles ↔ Categories est de type Plusieurs-à-Plusieurs, gérée par la table de jonction Article_Categories.

2. L'Intégrité Référentielle : La Promesse de Cohérence

Les clés étrangères ne sont pas juste des liens, elles sont des règles que la base de données applique pour vous. C'est ce qu'on appelle l'intégrité référentielle.

La Promesse

La base de données vous garantit que vous ne pourrez jamais avoir de "liens brisés".

Vous ne pourrez pas insérer un article avec un auteur_id qui n'existe pas dans la table Auteurs.
Vous ne pourrez pas supprimer un auteur de la table Auteurs s'il a encore des articles qui lui sont liés (sauf si vous le spécifiez).

Cela protège vos données contre les incohérences et rend votre application beaucoup plus robuste.

Outils et Bonnes Pratiques

Utilisez un Diagramme Entité-Relation (ERD)

Avant d'écrire du code, dessinez votre schéma. Un ERD est une représentation visuelle de vos tables, de leurs colonnes et de leurs relations. C'est le meilleur moyen de valider votre logique.
Outils gratuits : Draw.io (maintenant diagrams.net), Lucidchart (version gratuite), dbdiagram.io.

Pensez aux Contraintes d'Intégrité

Utilisez NOT NULL, UNIQUE, DEFAULT pour vous assurer que les données insérées sont toujours valides. La base de données devient votre premier gardien de la qualité des données.

Anticipez les Évolutions

Votre schéma n'est pas gravé dans le marbre, mais un bon design initial vous évitera des migrations de données douloureuses plus tard. Posez-vous la question : "Est-ce que cette structure permettra d'ajouter facilement de nouvelles fonctionnalités demain ?".

Pour aller plus loin en vidéo

Source: Fabinou

SQL et Bases de Données Relationnelles

Conception d'un Schéma Relationnel - L'Art de l'Organisation