Le modèle relationnel d'Edgar F. Codd : pourquoi SQL a conquis le monde de l'entreprise

L'idée centrale : des données comme des tables reliées

À 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 lignes représentent des choses individuelles (un client, une facture, un paiement).
• Les colonnes représentent des attributs de ces choses (nom du client, date de facture, montant).

Pourquoi cela importait pour les données métier

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.

Poser une attente : une cohérence sur laquelle on peut compter

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.

Un avant-goût : comment SQL a suivi

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 :

• sélectionner les lignes voulues,
• combiner les tables quand nécessaire,
• résumer les résultats pour les rapports.

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 Codd : pourquoi les systèmes de données précoces peinaient

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.

Systèmes basés sur des fichiers : rapides à démarrer, difficiles à faire évoluer

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.

La duplication créait des erreurs et du travail supplémentaire

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.

Le reporting et les questions ad hoc étaient pénibles

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.

Ce dont les entreprises avaient besoin

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.

Qui était Edgar F. Codd ?

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.

Le papier de 1970 qui a changé la conversation

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 :

• Les données devraient être décrites indépendamment de leur stockage physique.
• Les requêtes devraient se concentrer sur ce que vous voulez, pas comment y accéder.
• Les relations entre morceaux de données devraient être exprimées via des valeurs partagées (clés), pas des pointeurs codés en dur.

Pourquoi une base mathématique importait

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.

Un défi pour la pensée des bases existantes

À 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.

Blocs de construction : relations, lignes et colonnes

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.

Relations (tables)

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.

Lignes (tuples)

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.

Colonnes (attributs)

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é.

Domaines : garder les valeurs cohérentes

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 » signifie connexions, pas feuilles de calcul

« 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.

Clés et relations : la colle qui maintient les données en ordre

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.

Clés primaires : identifiants stables

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.

Clés étrangères : liens entre tables

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 :

• customers (customer_id PK, name, email)
• orders (order_id PK, customer_id FK → customers.customer_id, order_date)
• order_items (order_item_id PK, order_id FK → orders.order_id, product, quantity, price)

Contraintes : empêcher les données « orphelines » et conflictuelles

Les contraintes de clé étrangère agissent comme des garde‑fous. Elles empêchent :

• Les enregistrements orphelins : une commande qui référence un customer_id inexistant.
• Les mises à jour conflictuelles : supprimer un client alors que des commandes y font encore référence (sauf si des règles comme les suppressions en cascade sont explicitement choisies).

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.

Normalisation : des données plus propres, moins de surprises

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.

Ce que la normalisation cherche à éviter

Concrètement, la normalisation réduit des problèmes courants :

• Duplication : répéter le même fait (comme une adresse client) sur de nombreuses lignes.
• Anomalies de mise à jour : des changements nécessitant plusieurs modifications et entraînant des mises à jour partielles.

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).

1NF, 2NF, 3NF — l'intuition

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.

Compromis et « assez bien »

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.

Algèbre relationnelle : la logique derrière les requêtes

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.

Les opérations de base (en langage simple)

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.

Pourquoi les jointures sont centrales pour les données métier

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.

Résultats prévisibles, pas de surprises

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 :

• Le filtrage affecte quelles lignes sont incluses.
• La projection affecte quelles colonnes sont visibles.
• La jointure affecte comment les faits sont appariés entre tables.

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.

De la théorie à SQL : comment le modèle relationnel est devenu utilisable

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 vs le modèle relationnel « pur »

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.