Découvrez comment le modèle relationnel d'Edgar F. Codd a transformé les données en tables, clés et règles — ouvrant la voie aux bases SQL qui alimentent les applications métier.
À l'essentiel, le modèle relationnel stocke l'information sous la forme d'un ensemble de tables (ce que Codd appelait des « relations ») qui peuvent être liées via des valeurs partagées.
Une table est une grille ordonnée :
Les entreprises ne conservent pas les données isolément. Une vente implique un client, un produit, un prix, un commercial et une date — chacun évoluant à des rythmes différents et appartenant à des équipes différentes. Les systèmes anciens stockaient souvent ces détails dans des structures étroitement couplées et difficiles à modifier. Cela rendait le reporting lent, les changements risqués et les « petites questions » étonnamment coûteuses.
Le modèle relationnel a introduit une approche plus claire : garder des tables séparées pour des concepts séparés, puis les connecter quand on a besoin de réponses. Plutôt que de dupliquer les informations client sur chaque ligne de facture, on stocke les clients une fois et on les référence depuis les factures. Cela réduit les contradictions (deux orthographes différentes pour le même client) et rend les mises à jour plus prévisibles.
En insistant sur des tables bien définies et des règles pour les relier, le modèle a posé une nouvelle attente : la base de données doit aider à prévenir l'incohérence à mesure qu'elle grandit — surtout quand de nombreuses personnes et systèmes écrivent dedans.
Le modèle de Codd n'était pas un langage de requête, mais il en a inspiré un. Si les données vivent dans des tables reliées, il faut une façon standard de :
Ce chemin a mené à SQL, qui a transformé le modèle en une manière pratique pour des équipes quotidiennes de poser des questions sur les données métier et d'obtenir des réponses reproductibles et auditées.
Avant le modèle relationnel, beaucoup d'organisations stockaient des informations importantes dans des fichiers — souvent un fichier par application. La paie avait ses propres enregistrements, l'inventaire avait un autre, et le service client conservait encore une autre version du « client ». Chaque système fonctionnait en isolation, et cette isolation créait des douleurs prévisibles.
Le traitement des données précoce était généralement construit autour de formats de fichiers personnalisés et de programmes écrits pour un seul objectif. La structure des données (où chaque champ se situe, comment les enregistrements sont ordonnés) était fortement liée au code qui les lisait. Cela signifiait que même de petits changements — ajouter un champ, renommer une catégorie de produit, modifier le format d'une adresse — pouvaient nécessiter de réécrire plusieurs programmes.
Parce que les équipes ne pouvaient pas facilement partager une source unique de vérité, elles copiaient les données. Les adresses clients pouvaient exister dans les fichiers commerciaux, d'expédition et de facturation.
Quand une adresse changeait, chaque copie devait être mise à jour. Si un système était oublié, des incohérences apparaissaient : des factures envoyées au mauvais endroit, des expéditions retardées, et des agents de support voyant des « faits » différents selon l'écran utilisé. Les nettoyages de données devenaient des projets récurrents plutôt qu'une correction ponctuelle.
Les métiers posaient toujours des questions — « Quels clients ont acheté le produit X puis l'ont retourné ? » — mais y répondre exigeait d'assembler des fichiers qui n'avaient pas été conçus pour fonctionner ensemble. Les équipes construisaient souvent des extractions de reporting ponctuelles, ce qui introduisait encore plus de copies et d'opportunités de divergence.
Le résultat : les cycles de reporting étaient lents, et les « questions rapides » devenaient du travail d'ingénierie.
Les organisations avaient besoin de données partagées sur lesquelles plusieurs applications pouvaient s'appuyer, avec moins d'incohérences et moins d'effort dupliqué. Elles avaient aussi besoin d'un moyen de poser de nouvelles questions sans reconstruire le stockage sous-jacent à chaque fois. Ce fossé a préparé le terrain pour l'idée clé de Codd : définir les données de manière cohérente, indépendante des applications, afin que les systèmes puissent évoluer sans casser la vérité dont ils dépendent.
Edgar F. Codd était un informaticien britannique qui a passé une grande partie de sa carrière chez IBM, réfléchissant à la manière dont les organisations pouvaient stocker et récupérer efficacement l'information. Dans les années 1960, la plupart des « systèmes de base de données » ressemblaient davantage à des classeurs soigneusement gérés : les données étaient stockées dans des structures rigides et pré-définies, et changer ces structures signifiait souvent réécrire des applications. Cette fragilité frustrant les équipes à mesure que les entreprises grandissaient et que les besoins changeaient.
En 1970, Codd a publié un article au titre long — « A Relational Model of Data for Large Shared Data Banks » — qui proposait une idée étonnamment simple : représenter les données sous forme de tables reliées, et utiliser un ensemble formel d'opérations pour les interroger et les combiner.
À un niveau élevé, l'article avançait :
Codd a ancré sa proposition dans les mathématiques (théorie des ensembles et logique). Ce n'était pas une ostentation académique — cela donnait à la conception des bases de données une base claire et vérifiable. Avec un modèle formel, on peut raisonner sur l'exactitude d'une requête, sur l'équivalence de deux requêtes, et sur la façon d'optimiser l'exécution sans changer les résultats. Pour les logiciels métier, cela se traduit par moins de surprises à mesure que les systèmes montent en charge et évoluent.
À l'époque, beaucoup de systèmes reposaient sur des modèles hiérarchiques ou en réseau où les développeurs « naviguaient » les données le long de chemins prédéfinis. L'approche de Codd remettait en cause cet état d'esprit en affirmant que la base de données devait faire le gros du travail. Les applications ne devraient pas connaître la disposition du stockage ; elles devraient décrire le résultat souhaité, et la base devrait trouver un moyen efficace de le produire.
Cette séparation des responsabilités a préparé le terrain pour SQL et pour des bases de données capables de survivre à des années d'évolution des exigences produit.
Le modèle relationnel de Codd part d'une idée simple : stocker des faits dans des relations — ce que la plupart des gens reconnaissent comme des tables — mais les traiter comme une manière précise de décrire les données, pas comme des « feuilles de calcul intelligentes ». Une relation est un ensemble d'énoncés sur des choses qui intéressent votre entreprise : clients, commandes, paiements, produits, expéditions.
Une relation représente un type de motif factuel. Par exemple, une relation Orders pourrait capturer « une commande a un ID, une date, un client et un total ». Le point clé est que chaque relation a un sens clairement défini, et chaque colonne fait partie de ce sens.
Une ligne (Codd l'appelait un tuple) est une instance spécifique de ce fait : une commande particulière. Dans le modèle relationnel, les lignes n'ont pas de « position » inhérente. La ligne 5 n'est pas spéciale — ce qui compte ce sont les valeurs et les règles qui les définissent.
Une colonne (un attribut) est une propriété précise dans la relation : OrderDate, CustomerID, TotalAmount. Les colonnes ne sont pas que des étiquettes ; elles définissent quel type de valeur est autorisé.
Un domaine est l'ensemble autorisé de valeurs pour un attribut — comme des dates pour OrderDate, des nombres positifs pour TotalAmount, ou une liste de codes contrôlée pour Status (par ex. Pending, Paid, Refunded). Les domaines réduisent l'ambiguïté et empêchent des erreurs subtiles comme mélanger des formats de date ou stocker "N/A" dans des champs numériques.
« Relationnel » fait référence à la manière dont les faits peuvent être connectés entre relations (comme clients et commandes), permettant des tâches métier courantes — facturation, reporting, audit, support client — sans dupliquer la même information partout.
Les tables sont utiles en elles-mêmes, mais les données métier n'ont de sens que si vous pouvez connecter de façon fiable les faits : quel client a passé quelle commande, quels articles y figuraient, et combien a-t-on facturé. Les clés sont le mécanisme qui rend ces connexions fiables.
Une clé primaire est une colonne (ou un ensemble de colonnes) dont la valeur identifie de façon unique une ligne. Pensez-y comme le « badge nominatif » d'une ligne. L'élément important est la stabilité : les noms, emails et adresses peuvent changer, mais un ID interne ne devrait pas.
Une bonne clé primaire empêche des enregistrements dupliqués ou ambigus. Si deux clients partagent le même nom, la clé primaire les distingue.
Une clé étrangère est une colonne qui stocke la clé primaire d'une autre table. C'est ainsi que les relations sont représentées sans copier toutes les données.
Par exemple, on peut modéliser les ventes ainsi :
Les contraintes de clé étrangère agissent comme des garde‑fous. Elles empêchent :
Concrètement, les clés et contraintes permettent aux équipes de faire confiance aux rapports et aux workflows. Quand la base applique les relations, moins de bugs se glissent dans la facturation, l'exécution et le support client — parce que les données ne peuvent pas discrètement dériver vers des états impossibles.
La normalisation est la manière dont le modèle relationnel empêche les données de dériver vers des contradictions à mesure qu'elles grandissent. Quand le même fait est stocké à plusieurs endroits, il est facile de modifier une copie et d'en oublier une autre. C'est ainsi que les entreprises se retrouvent avec des factures envoyées à la mauvaise adresse, des rapports qui ne correspondent pas, ou un client marqué « inactif » ici et « actif » ailleurs.
Concrètement, la normalisation réduit des problèmes courants :
Elle évite aussi les anomalies d'insertion (on ne peut pas ajouter un client avant qu'il ne passe une commande) et les anomalies de suppression (supprimer la dernière commande efface accidentellement la seule copie des détails du client).
Pas besoin d'une théorie lourde pour bien utiliser l'idée :
Première forme normale (1NF) : garder chaque champ atomique. Si un client a plusieurs numéros de téléphone, ne les empilez pas dans une cellule ; utilisez une table séparée (ou des lignes séparées) pour que chaque valeur puisse être recherchée et mise à jour proprement.
Deuxième forme normale (2NF) : si l'identité d'une table dépend de plus d'une colonne (une clé composée), assurez-vous que les détails non clés dépendent de l'ensemble de la clé. Une ligne de commande doit stocker la quantité et le prix pour cette ligne, pas l'adresse client.
Troisième forme normale (3NF) : retirez les « faits secondaires » qui appartiennent ailleurs. Si une table stocke CustomerId et aussi CustomerCity, la ville devrait typiquement vivre dans la table client, pas être copiée dans chaque commande.
Plus de normalisation signifie généralement plus de tables et plus de jointures. Cela améliore la cohérence, mais peut compliquer le reporting et parfois affecter les performances. Beaucoup d'équipes visent la 3NF pour les entités cœur (clients, produits, factures), puis dénormalisent sélectivement pour des tableaux de bord en lecture intensive — tout en conservant une source d'autorité appliquée par les clés primaires / étrangères.
L'algèbre relationnelle est la « math » derrière le modèle relationnel : un petit ensemble d'opérations précises pour transformer un ensemble de lignes (une table) en un autre ensemble de lignes.
Cette précision compte. Si les règles sont claires, les résultats des requêtes le sont aussi. Vous pouvez prévoir ce qui se passe lorsque vous filtrez, remodellez ou combinez des données — sans dépendre de comportements non documentés ou de navigation manuelle.
L'algèbre relationnelle définit des briques que l'on compose. Trois des plus importantes sont :
Select (sélection) : choisir les lignes voulues.
Idée d'exemple : « seulement les commandes du mois dernier » ou « seulement les clients en France ». On garde les mêmes colonnes, mais on réduit le nombre de lignes.
Project (projection) : choisir les colonnes voulues.
Idée d'exemple : « afficher nom du client et email ». On garde les mêmes lignes (logiquement), mais on retire les colonnes inutiles.
Join (jointure) : combiner des faits liés depuis différentes tables.
Idée d'exemple : « rattacher les détails client à chaque commande », en utilisant un identifiant partagé (comme customer_id). La sortie est une nouvelle table où chaque ligne rassemble des champs précédemment stockés séparément.
Les données métier sont naturellement réparties par sujets : clients, commandes, factures, produits, paiements. Cette séparation permet de stocker chaque fait une seule fois (ce qui aide à éviter les divergences), mais signifie aussi que les réponses nécessitent souvent de recombiner ces faits.
Les jointures sont la manière formelle de faire cette recombinaison tout en préservant le sens. Plutôt que de copier les noms clients dans chaque ligne de commande (et de corriger ensuite les fautes partout), on stocke les clients une fois et on joint quand on veut un rapport.
Parce que l'algèbre relationnelle est définie comme des opérations sur des ensembles de lignes, l'issue attendue de chaque étape est bien délimitée :
C'est l'ossature conceptuelle qui a ensuite rendu SQL pratique : les requêtes deviennent des séquences de transformations bien définies, pas des récupérations de données ad hoc.
Le modèle de Codd décrivait ce que signifient les données (relations, clés et opérations) sans prescrire une façon conviviale de l'utiliser au quotidien. SQL a comblé ce manque : il a transformé les idées relationnelles en un langage pratique et lisible que les analystes, développeurs et produits de bases de données pouvaient partager.
SQL s'inspire de l'algèbre relationnelle, mais n'en est pas une implémentation parfaite.
Une différence clé est le traitement des valeurs manquantes ou inconnues. La théorie relationnelle classique se base sur une logique à deux valeurs (vrai/faux), tandis que SQL introduit NULL, menant à une logique à trois valeurs (vrai/faux/inconnu). Autre différence : la théorie relationnelle travaille avec des ensembles (pas de doublons), mais les tables SQL autorisent souvent des lignes dupliquées sauf si vous les empêchez explicitement.
Malgré ces différences, SQL a tenu la promesse centrale : vous décrivez le résultat souhaité (requête déclarative), et la base trouve comment l'exécuter.
Le modèle relationnel stocke les données sous forme de tables (relations) avec :
Son avantage principal est que des tables séparées peuvent être liées via des identifiants partagés, ce qui permet de conserver chaque fait en un seul endroit et de les recombiner pour des rapports et workflows.
Les systèmes basés sur des fichiers liaient la structure des données au code applicatif. Cela créait des problèmes pratiques :
Les bases relationnelles ont découplé la définition des données d'une application unique et rendu les requêtes transversales routinières.
Une clé primaire (PK) identifie de façon unique chaque ligne d'une table et doit rester stable dans le temps.
Conseils pratiques :
customer_id) plutôt que des champs modifiables comme l'email.Une clé étrangère (FK) est une colonne dont les valeurs doivent correspondre à une clé primaire existante dans une autre table. C'est ainsi qu'on représente les relations sans copier des enregistrements entiers.
Exemple de schéma :
orders.customer_id référence customers.customer_idAvec des contraintes FK activées, la base peut empêcher :
La normalisation vise à réduire l'incohérence en stockant chaque fait une seule fois (ou autant que possible). Elle aide à prévenir :
Une cible courante est la , puis une dénormalisation sélective uniquement lorsque le besoin est justifié par des mesures.
Règle simple pour la 1NF : un champ = une valeur.
Si vous commencez à ajouter des colonnes phone1, phone2, phone3, scindez-les dans une table liée :
customer_phones(customer_id, phone_number, type)Cela facilite la recherche, la validation et la mise à jour des numéros et évite des cas maladroits comme des colonnes vides ou manquantes.
L'algèbre relationnelle définit les opérations de base derrière les requêtes relationnelles :
Vous n'avez pas besoin d'écrire de l'algèbre relationnelle au quotidien, mais comprendre ces concepts aide à raisonner sur les résultats SQL et à éviter des duplications involontaires lors des jointures.
SQL a rendu les idées relationnelles utilisables en offrant une façon déclarative de poser des questions : vous décrivez le résultat, et la base choisit un plan d'exécution.
Gains pratiques clés :
GROUP BY)Même si SQL n'implémente pas parfaitement la théorie de Codd, il a préservé le flux de travail central : des requêtes fiables sur des tables liées.
SQL diffère du « pur » modèle relationnel sur quelques points importants :
NULL introduit une logique à trois valeurs (vrai/faux/inconnu), ce qui affecte filtres et jointures.Concrètement, soyez attentif au traitement des et imposez l'unicité là où elle compte.
Utilisez une base relationnelle quand vous avez besoin d'une forte exactitude pour les documents métiers partagés.
Checklist pratique :
Ajoutez NoSQL ou des stores spécialisés uniquement quand vous avez un besoin clair de formes flexibles, de patterns de distribution à grande échelle ou de requêtes spécialisées (recherche / graphe), tout en conservant un système de référence clair.
Les transactions regroupent un ensemble de changements en une seule opération métier (par ex. « transférer 100 $ », « expédier une commande »). Le principe clé est le comportement tout-ou-rien :
ACID expliqué simplement :
Quelques règles pratiques pour la conception de tables :
NULLLes contraintes (PK/FK/checks) + transactions sont le duo qui maintient l'honnêteté des systèmes à grande échelle.
CustomerPhones au lieu de phone1, phone2).Si vous transformez ces principes en produit, des outils qui alignent l'intention du schéma et le code applicatif aident beaucoup. Par exemple, Koder.ai peut générer une application React + Go + PostgreSQL à partir d'une invite, facilitant le prototypage d'un schéma normalisé tout en conservant la base comme source de vérité.