Modéliser une base de données MySQL : La relation 1-N

Créer une base de données peut sembler mystérieux lorsque l’on débute en MySQL. On écrit des requêtes, on crée des tables, mais comment tout cela s’organise vraiment ? Ce qui fait la différence entre une base solide et une base chaotique, c’est la manière de modéliser les relations entre les données. Apprenons à utiliser la relation 1-N (en français, un-à-plusieurs) ou one-to-many (en anglais).

• Comprendre simplement le principe du 1-N pour structurer ses données sans doublons ni incohérences
• Savoir modéliser proprement ce lien dans un schéma MySQL avec clés primaires et étrangères
• Être capable d’interroger des tables liées et faire évoluer sa base sans tout casser

Le schéma MySQL, c’est un peu l’architecture de votre application. Une mauvaise modélisation peut vite conduire à un système ingérable : doublons, incohérences, données impossibles à récupérer correctement. La bonne nouvelle, c’est qu’en apprenant un seul type de relation fondamental, vous faites déjà un énorme pas en avant.

Aujourd’hui, nous allons donc aborder la relation 1-N (ou one-to-many). Sous ce nom technique se cache un concept simple, souvent utilisé partout sur le web. En cinq minutes (ou un peu plus, parce qu’on prend le temps d’apprendre sereinement), vous allez comprendre ce que c’est, à quoi cela sert, et surtout comment l’utiliser dans un schéma MySQL propre et professionnel.

C’est quoi la relation 1-N ou one-to-many ?

Avant de plonger dans le SQL, prenons un exemple de la vraie vie. Imaginez une bibliothèque. Elle contient beaucoup de livres. Pourtant, chaque livre a un seul auteur principal. Ce lien naturel s’appelle une relation un-à-plusieurs : un auteur peut avoir plusieurs livres mais un livre ne peut avoir qu’un seul auteur.

On peut donc dire :

• Un auteur → peut avoir plusieurs livres
• Un livre → appartient à un seul auteur

Voilà une relation 1-N (1 pour l’auteur, N pour les livres).

Ce principe s’utilise partout :

• Un client peut passer plusieurs commandes
• Un professeur enseigne plusieurs cours
• Une catégorie contient plusieurs articles
• Une entreprise emploie plusieurs salariés

Sans ce type de relation, votre schéma MySQL ne pourrait pas représenter le monde réel.

Le schéma MySQL illustré avec l’auteur et ses livres

Lorsque l’on modélise une relation 1-N, on crée généralement deux tables :

• La table du côté “1” (ex : auteurs)
• La table du côté “N” (ex : livres)

Prenons ce modèle et transformons-le en structure :

Table auteurs :

• id_auteur (PRIMARY KEY)
• nom

Table livres :

• id_livre (PRIMARY KEY)
• titre
• id_auteur (FOREIGN KEY)

L’élément le plus important ici, c’est le champ id_auteur dans la table livres. C’est lui qui crée la relation. On l’appelle clé étrangère car il pointe vers une clé primaire d’une autre table.

Schéma relationnel

AUTEURS (1) --------< (N) LIVRES

Concrètement, on inscrit dans livres.id_auteur l’identifiant de l’auteur auquel appartient le livre. C’est comme coller une étiquette “écrit par” sur chaque ouvrage.

Et si un auteur écrit dix livres ? On enregistre dix lignes dans livres, toutes avec le même id_auteur. Simple, clair, efficace.

Pourquoi ne pas tout mettre dans une seule table ?

Si vous débutez, vous vous demandez peut-être : pourquoi ne pas créer une table unique avec le nom de l’auteur à côté du titre du livre ?

Par exemple :

• Table bibliotheque
• id_livre | titre | nom_auteur

Cela marcherait… au début. Mais imaginez l’auteur Georges Martin, qui publie des dizaines de romans. Vous allez taper son nom encore, encore, encore, encore. Et si un jour son nom change (parce qu’il se marie ou choisit un nom de plume), vous devrez mettre à jour toutes les lignes. Et si vous en oubliez une, bonjour les incohérences.

Le schéma MySQL avec relation 1-N (ou one-to-many) permet de centraliser chaque information à un seul endroit. L’auteur est stocké une seule fois. Les livres font juste référence à lui. C’est le secret d’une base de données fiable sur le long terme.

Relation 1-N ou one-to-many : comment l’écrire en SQL

Voyons maintenant comment on traduit ce schéma MySQL en SQL. L’exemple qui suit fonctionne sur n’importe quelle base MySQL :

CREATE TABLE auteurs (
    id_auteur INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    nom VARCHAR(100) NOT NULL
);

CREATE TABLE livres (
    id_livre INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    titre VARCHAR(255) NOT NULL,
    id_auteur INT UNSIGNED,
    FOREIGN KEY (id_auteur) REFERENCES auteurs(id_auteur)
);

Vous voyez ? Quelques lignes suffisent à modéliser une relation un-à-plusieurs correcte.

La clé primaire id_auteur dans auteurs est unique pour chaque auteur.
La colonne id_auteur dans livres permet de dire à quel auteur se rattache chaque livre.

C’est tout pour le moment. La magie de la relation 1-N est là.

Une erreur courante lorsque l’on débute

Beaucoup de débutants font l’erreur de placer une liste dans une cellule. Par exemple : une table auteurs avec une colonne livres_publies contenant “Livre A, Livre B, Livre C…”.

Cela paraît logique… jusqu’à ce que vous vouliez récupérer un seul livre, ou compter combien un auteur en possède. Vous devrez découper une chaîne de caractères, ce qui n’a rien de pratique, ni de propre.

Une base de données MySQL fonctionne à merveille lorsque chaque valeur reste simple. Dès que vous mettez plusieurs données dans une seule colonne, cela devient du bricolage.

La règle d’or :

Si une donnée peut exister plusieurs fois, elle doit être dans une autre table.

Cette règle vous sauvera bien des nuits de débogage.

Exemple : clients et commandes

Prenons un cas que vous trouverez dans toute boutique en ligne.

• Un client peut passer plusieurs commandes.
• Une commande appartient à un seul client.

Donc :

• La table clients contient les informations du client.
• La table commandes stocke chaque commande avec la référence du client.

CREATE TABLE clients (
    id_client INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    nom VARCHAR(100),
    email VARCHAR(255) UNIQUE
);

CREATE TABLE commandes (
    id_commande INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    date_commande DATE NOT NULL,
    id_client INT UNSIGNED,
    FOREIGN KEY (id_client) REFERENCES clients(id_client)
);

Chaque nouvelle commande ne fait qu’ajouter une nouvelle ligne dans commandes. Pas besoin de toucher à clients. Le schéma MySQL reste propre, quelle que soit la croissance de la base.

Et si un jour, un client change d’adresse e-mail, il suffit de mettre à jour une seule ligne. Tout continue de fonctionner comme prévu.

Comment lire une relation 1-N dans un schéma MySQL

Lorsque vous regardez un schéma MySQL (souvent représenté sous forme de rectangles reliés par des traits), vous pouvez identifier une relation 1-N en observant comment les clés primaires et étrangères sont reliées. La table du côté “1” a sa clé primaire reliée à la table du côté “N”, où cette clé est dupliquée sous forme de clé étrangère.

Pour vous guider, voici une manière simple de reconnaître la relation :

• Si une information peut être associée à plusieurs éléments, elle se trouve du côté “1”.
• Si un élément ne peut être lié qu’à une seule information de référence, il est du côté “N”.

Prenons encore notre exemple du client et de ses commandes. Sur un schéma, la table clients est à gauche avec la mention “1”, la table commandes est à droite avec la mention “N”. La flèche ou le trait pointe de commandes.id_client vers clients.id_client.

En un clin d’œil, vous comprenez qui “possède” plusieurs éléments, et qui “appartient” à un seul autre. C’est presque comme un arbre généalogique, mais pour les données.

Pour représenter une relation One-to-Many sur un schéma MySQL, on dessine généralement deux blocs, chacun représentant une table. Dans l’exemple de l’image, la table AUTEURS se trouve du côté “1” parce qu’un auteur peut écrire plusieurs livres, mais chaque livre n’a qu’un seul auteur. La table LIVRES est donc du côté “N”. On relie ensuite les deux avec une flèche ou un trait qui part de la clé étrangère id_auteur dans la table LIVRES vers la clé primaire id_auteurde la table AUTEURS. Ce trait signifie : « chaque livre est associé à un auteur ».

Lorsque vous créez votre propre schéma One-to-Many, gardez toujours en tête que la clé étrangère se trouve dans la table qui contient plusieurs éléments. Sur l’image, elle est en bas dans la table LIVRES. Si vous deviez faire la même chose avec des clients et leurs commandes, ou une catégorie et ses articles, la logique serait identique. Imaginez simplement que vous collez une étiquette sur chaque élément du côté “N” pour dire à quel élément du côté “1” il appartient. Grâce à cette représentation visuelle, vous pouvez vérifier en un coup d’œil que votre base restera cohérente et évolutive, même lorsque le nombre d’éléments grandit.

Récupérer les données liées en SQL

Avoir un beau schéma MySQL, c’est très bien. Mais ce qui intéresse vraiment, c’est comment récupérer les données liées entre elles.

Pour cela, on utilise souvent une requête JOIN, qui permet de “rassembler” virtuellement les tables le temps d’une interrogation. Le type de jointure le plus courant pour une relation 1-N est le INNER JOIN.

Imaginons que vous souhaitiez afficher les titres des livres avec le nom de leur auteur :

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

SELECT livres.titre, auteurs.nom
FROM livres
INNER JOIN auteurs ON livres.id_auteur = auteurs.id_auteur;

Cette requête lit les deux tables et assemble automatiquement chaque livre avec son auteur. Résultat, vos données paraissent regroupées alors qu’elles restent parfaitement séparées en base.

On peut même ajouter un filtre, par exemple pour n’afficher que les livres d’un auteur précis :

SELECT titre
FROM livres
WHERE id_auteur = 3;

Cette requête ne demande pas de JOIN car nous ciblons uniquement les livres en utilisant directement la clé étrangère.

Dans la pratique, les jointures permettent d’afficher toutes les informations nécessaires sans jamais dupliquer les données. C’est un avantage immense au quotidien.

Quand l’information manque ? La relation 1-N optionnelle

Les choses ne sont pas toujours aussi carrées que dans les livres. Dans la vraie vie, il arrive qu’une donnée ne soit pas encore liée à son parent.

Prenons un exemple simple : un article dans un blog qui n’a pas encore été classé dans une catégorie. La relation existe toujours, mais l’article peut être temporairement “orphelin”.

Dans le schéma MySQL, cela se traduit par une clé étrangère autorisée à être NULL :

CREATE TABLE categories (
    id_cat INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    nom VARCHAR(100) NOT NULL
);

CREATE TABLE articles (
    id_article INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    titre VARCHAR(255) NOT NULL,
    id_cat INT UNSIGNED NULL,
    FOREIGN KEY (id_cat) REFERENCES categories(id_cat)
);

Tant que id_cat reste à NULL, l’article n’est lié à aucune catégorie, mais tout fonctionne quand même. Vous gagnez en souplesse, ce qui est important lors du développement d’un site ou d’une application où tout n’est pas encore finalisé.

Le cas inverse : relation 1-N obligatoire

À l’inverse, certaines relations ne souffrent aucune exception. Une commande doit toujours être associée à un client. Un commentaire doit toujours être lié à un article. Un fichier facture doit toujours correspondre à un devis.

Dans ces cas-là, on impose que la clé étrangère ne puisse pas être NULL :

id_client INT UNSIGNED NOT NULL

Une tentative d’insertion sans renseigner id_client provoquerait une erreur. C’est une bonne chose, car cela vous évite stocker des données impossibles à utiliser ou totalement incohérentes.

Une base qui grandit sans casser

L’un des plus grands avantages du modèle 1-N, c’est qu’il rend la base MySQL extensible. Si demain un auteur publie mille livres (on a le droit de rêver), vous ne modifiez pas la table auteurs. Vous ajoutez simplement mille nouvelles lignes dans livres.

Votre base évolue, mais sa structure reste stable. C’est là que l’on comprend tout le génie de la modélisation.

Imaginez placer naïvement toutes les informations des commandes directement dans la table client. Si un utilisateur passe quarante commandes, tout deviendrait ingérable.

Les erreurs à éviter absolument

Même si la relation 1-N semble simple, quelques pièges sont très fréquents chez les débutants.

Erreur 1 : dupliquer des informations
Si le nom de l’auteur est écrit dans chaque livre, c’est tout de suite le bazar. Il n’y a pas à négocier, chaque donnée doit vivre une seule fois dans la base.

Erreur 2 : oublier la contrainte FOREIGN KEY
Sans cette contrainte, la base accepte des incohérences. Par exemple, un livre pourrait référencer un auteur qui n’existe pas. Les FOREIGN KEY garantissent l’intégrité des données.

Erreur 3 : relations inversées
Il ne faut jamais mettre une liste dans la table du côté 1. La clé étrangère doit toujours se placer dans la table qui contient plusieurs éléments.

Si vous évitez ces trois erreurs, vous êtes déjà au niveau de beaucoup de développeurs confirmés.

Les avantages concrets de la relation 1-N

Maintenant que vous l’avez bien en tête, regardons pourquoi cette relation est utilisée partout dans les schémas MySQL modernes.

D’abord, elle permet d’éviter les doublons. Lorsque votre base contient des milliers d’utilisateurs ou de produits, vous seriez bien content de ne pas répéter les mêmes informations cent fois. Le stockage reste propre, logique et facile à maintenir.

Ensuite, elle protège votre application contre les incohérences. Si vous supprimez un client, MySQL peut vous empêcher de laisser des commandes “orphelines”. Vous pouvez même configurer les contraintes pour que toutes ses commandes disparaissent automatiquement, si cela a du sens pour votre projet. On appelle cela les règles de suppression en cascade.

Il y a aussi un troisième avantage, souvent sous-estimé : votre base devient plus simple à faire évoluer. Vous pouvez ajouter de nouvelles informations, ou de nouvelles tables liées au côté “1” ou au côté “N”, sans jamais casser tout votre modèle. Vos données s’enrichissent en douceur, comme une bibliothèque qui gagne de nouveaux rayons.

Et puis, avouons-le : travailler avec un schéma clair, c’est beaucoup plus agréable que se battre contre un truc incompréhensible. On dort mieux, on débogue moins, et on se sent presque architecte de données.

Exemple : entreprise et salariés, la relation du quotidien

Pour terminer de vous convaincre, prenons une situation très courante dans le monde professionnel. Une entreprise peut employer plusieurs salariés. Chaque salarié n’a qu’un seul employeur dans votre système.

Ce schéma MySQL respecte naturellement la relation 1-N :

Table entreprises :

id_entreprise | nom | adresse

Table salaries :

id_salarie | nom | poste | id_entreprise

Vous pourriez très bien afficher tous les employés d’une entreprise en une seule requête, ou au contraire récupérer les informations de leur employeur à partir de leur fiche individuelle.

Ce qui est puissant, c’est que vous pouvez faire cela pour des millions de lignes. La structure ne bouge pas. Les relations restent claires. Une entreprise peut embaucher demain cinquante nouvelles personnes, sa fiche ne changera pas : une ligne unique dans entreprises et cinquante nouvelles lignes dans salaries.

Et si un salarié change d’entreprise ? Une simple mise à jour de l’identifiant dans id_entreprise. C’est rapide et votre base reste cohérente.

Si vous commencez un projet de site de recettes de cuisine sans vraiment penser au modèle… vous utiliserez une énorme table où chaque ligne contiendrait tout : l’auteur de la recette, la liste des ingrédients, les étapes, les commentaires… Dans l’idée, c’est simple. Dans la réalité, c’est un cauchemar. Impossible d’ajouter un ingrédient sans tout casser, impossible de chercher toutes les recettes d’un même auteur sans manipulations absurdes.

En divisant les données et en appliquant des relations 1-N (un auteur, plusieurs recettes ; une recette, plusieurs ingrédients ; une recette, plusieurs commentaires…), votre projet se transforme. De bricolage fragile, il devient un vrai système évolutif.

Moralité, la modélisation n’est pas un petit détail technique. C’est ce qui détermine la qualité de votre base MySQL.

Ce qu’il faut retenir sur le 1-N

• Une relation 1-N, c’est un lien naturel entre deux tables.
• Un élément du côté “1” peut être associé à plusieurs éléments du côté “N”.
• La clé primaire du côté “1” devient une clé étrangère dans la table du côté “N”.
• Ce principe représente fidèlement le monde réel et reste simple à manipuler avec SQL, surtout avec des jointures.

En comprenant cela, vous avez déjà posé la pierre la plus importante de votre schéma MySQL. Toutes les plus grandes applications reposent sur ces relations, parfois des milliers d’entre elles en même temps.

Vous êtes donc définitivement sur la bonne voie.

Vous venez d’apprendre à modéliser une relation 1-N ou one-to-many dans une base de données MySQL, ce qui constitue l’un des piliers de tout projet informatique sérieux. Derrière une apparente simplicité, ce modèle permet de représenter les situations les plus variées, de l’auteur et ses livres au client et ses commandes, en passant par la catégorie et ses articles.

Savoir choisir où placer la clé primaire, où mettre la clé étrangère, et comment interroger ces données avec un JOIN fera de vous quelqu’un de beaucoup plus serein face aux bases de données. Vous n’êtes plus en train d’écrire des tables au hasard : vous construisez un modèle logique du monde.

Et le plus beau dans tout ça, c’est que vous venez de franchir une étape essentielle. Très vite, vous pourrez aller plus loin : relation 1-1, relation N-N, normalisation, cascade… Chaque nouvelle brique s’assemblera naturellement grâce à ce que vous maîtrisez maintenant.

Alors gardez cette confiance : le schéma MySQL n’a plus rien d’effrayant. Vous avez compris l’un de ses mécanismes les plus puissants. À vous de jouer pour bâtir des bases solides et évolutives.

Alban

Fondateur de l’agence Créa-troyes, affiliée France Num
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr