Base de données relationnelle : définition simple et exemples concrets
Vos clients, vos factures, vos articles, vos stocks : tout ce que votre ERP enregistre est rangé quelque part. Ce quelque part, c'est presque toujours une base de données relationnelle. Vous ne la voyez jamais, mais chacun de vos chiffres en sort.
Le modèle n'est pas neuf. Il a été inventé en 1970, et il domine toujours. Selon le classement DB-Engines, les bases de données relationnelles concentrent 71 % de la popularité de tous les systèmes en octobre 2026 (DB-Engines). Les modèles plus récents, regroupés sous le nom de NoSQL, ne les ont pas détrônées.
Pourquoi s'y intéresser quand on dirige une PME ? Parce que trois notions suffisent à comprendre pourquoi un reporting tombe juste ou faux : les tables, les clés et les relations entre les données. Ce guide vous les explique en mots simples, avec des exemples tirés des ERP que vous utilisez tous les jours. Il compare aussi les deux types de bases, relationnelles et non relationnelles.
Qu'est-ce qu'une base de données relationnelle ?
Une base de données relationnelle organise les données en tables, faites de lignes et de colonnes, reliées entre elles par des identifiants communs. Chaque information n'est saisie qu'une fois, au bon endroit. Les relations entre les tables permettent ensuite de la retrouver et de la combiner.
L'idée vient d'Edgar F. Codd, chercheur chez IBM. En 1970, il propose un nouveau modèle de données : ranger les données dans des tables reliables entre elles, pour obtenir une réponse nouvelle à partir de plusieurs tables en une seule question (IBM). Ce modèle de base de données s'impose dans les années 1980. Aujourd'hui encore, les bases de données relationnelles constituent le socle de presque tous les logiciels de gestion.
Pour l'exploiter, on utilise un système de gestion de base de données relationnelle, ou SGBDR. C'est le logiciel qui permet de stocker des données, de les protéger et de les interroger. Parmi les bases de données relationnelles les plus utilisées figurent Oracle, MySQL, Microsoft SQL Server et PostgreSQL, les quatre premiers du classement mondial DB-Engines.
Une image aide à comprendre. Imaginez un classeur Excel avec un onglet Clients, un onglet Factures et un onglet Articles. Dans un tableur, ces onglets s'ignorent. Dans une base de données relationnelle comme celle de votre ERP, ils sont liés : chaque facture « sait » à quel client et à quels articles elle se rapporte.
Comment les bases de données relationnelles fonctionnent-elles ?
Chaque table possède une clé primaire, un identifiant unique comme le numéro client. Une autre table y fait référence grâce à une clé étrangère : la facture porte le numéro du client. C'est ce lien qui permet de relier une facture à son client sans recopier son nom ni son adresse.
Prenons un exemple très simple, avec deux tables :
Le client C001 apparaît une seule fois dans la table Clients, mais deux fois dans la table Factures. Si Martin Industrie change d'adresse, on la modifie à un seul endroit, et toutes ses factures restent justes. C'est le principe de la base de données relationnelle : éviter les doublons, qui menacent la cohérence des données. On appelle ce rangement sans répétition la normalisation.
Chaque colonne a aussi un type de données spécifique : une date, un montant, un texte. Impossible de saisir « demain » dans une colonne de dates. Les liens, eux, prennent trois formes :
- Un à un : un salarié, un badge.
- Un à plusieurs : un client, plusieurs factures. C'est le cas le plus courant.
- Plusieurs à plusieurs : un article vendu par plusieurs fournisseurs, un fournisseur qui livre plusieurs articles. On passe alors par une table intermédiaire, qui contient par exemple le prix de chaque article chez chaque fournisseur.
Les bases de données relationnelles utilisent ces règles pour maintenir l'intégrité des données. Impossible, par exemple, de créer une facture pour un client qui n'existe pas.
À quoi sert le SQL ?
Le SQL est le langage qui permet d'interagir avec la base : lire, ajouter, mettre à jour et supprimer des données. On lui pose une question précise, par exemple « le chiffre d'affaires par client ce mois-ci », et il renvoie un tableau. L'opération clé s'appelle la jointure : elle relie deux tables grâce à leur colonne commune.
Dans notre exemple, la jointure entre Factures et Clients, sur le numéro client, donne directement : Martin Industrie, 7 000 € ; Atelier Durand, 1 350 €. C'est exactement ce que fait votre outil de reporting, en coulisses, chaque fois qu'il affiche un chiffre d'affaires par client.
C'est pourquoi on parle aussi de base de données SQL. Le SGBDR garantit en outre la fiabilité des enregistrements, selon des règles appelées ACID. Une facture est enregistrée en entier ou pas du tout : jamais d'en-tête sans lignes. Deux personnes peuvent saisir en même temps sans écraser le travail de l'autre. Les bases de données relationnelles excellent dans ce traitement des données au fil de l'eau, au cœur de toutes les applications de gestion.
Le langage est universel et toujours très vivant. PostgreSQL est la base la plus utilisée par les développeurs professionnels, à 55,6 % selon l'enquête de Stack Overflow 2025. Vous n'avez pas besoin d'écrire vous-même les requêtes SQL. Mais retenez ceci : chaque chiffre de votre reporting dépend d'une jointure, et une jointure mal faite donne un chiffre faux.
Votre ERP est une base de données relationnelle
Votre ERP, c'est d'abord une base relationnelle avec des écrans par-dessus. Sage 100, par exemple, s'appuie le plus souvent sur Microsoft SQL Server. Les en-têtes de documents (devis, bons de livraison, factures) forment une table. Les lignes de ces documents en forment une autre, les clients et fournisseurs une troisième.
C'est là que se cachent les pièges. Dans Sage 100, la table des tiers mélange clients, fournisseurs et prospects. Oubliez de filtrer le type de tiers, et un fournisseur se glisse dans votre classement des meilleurs clients. Autre classique : l'en-tête d'une facture désigne son client par un champ précis. Faites la jointure sur une autre colonne, au nom pourtant plus évident, et des factures disparaissent du calcul ou changent de client. Vos données peuvent donc être justes dans l'ERP et fausses dans le tableau de bord, sans aucune alerte.
Et les vrais ERP sont bien plus vastes que notre exemple. Dans une PMI métallurgique sous Clipper, nous avons trouvé 271 tables. Dans une cartonnerie sous Gespack, 517. Comprendre lesquelles comptent, et comment elles se relient, fait tout le travail : c'est ce qui préserve l'intégrité des données jusque dans vos rapports.
Pour piloter ses approvisionnements, un distributeur de matériel électrique sous Sage 100 croise ainsi six tables : articles, stocks par dépôt, tarifs fournisseurs, lignes de documents, tiers et familles d'articles. C'est ce croisement qui permet d'anticiper les ruptures de stock chaque matin. Pour aller plus loin, voyez comment exploiter les données de Sage 100 et, plus largement, exploiter les données de son ERP.
La leçon est simple. Les outils de reporting affichent une donnée déjà propre. Construire les bonnes jointures, sur les bonnes clés, est un travail à part entière : c'est lui qui rend vos chiffres fiables.
Bases de données relationnelles et non relationnelles : quelles différences ?
La différence entre une base de données relationnelle et une base de données non relationnelle tient à la structure. La première range des données structurées dans des tables aux colonnes fixées à l'avance. La seconde, dite NoSQL, accepte des modèles de données flexibles, adaptés aux données non structurées : on y ajoute des données sans définir de colonnes.
Les bases de données relationnelles stockent les données sous forme de tables. Les bases de données non relationnelles stockent l'information autrement, selon le besoin, et organisent les données de manière plus libre. On en distingue plusieurs familles :
- Les bases de données orientées documents, comme MongoDB. Une boutique en ligne dont les données sont stockées en documents garde toute une commande dans un seul bloc, sans jointure.
- Les bases clé-valeur, comme Redis. Elles retrouvent une information en un éclair à partir d'un identifiant.
- La base de données graphique, comme Neo4j, où les données forment un réseau de points reliés. Elle explore différents points de données et leurs liens, par exemple une chaîne de fournisseurs et de sous-traitants.
Les bases de données NoSQL savent aussi répartir les données sur plusieurs serveurs. Elles absorbent ainsi les grands volumes de données générées par les capteurs, les sites web ou les objets connectés. Certaines bases de données non relationnelles gèrent même des données complexes et non structurées, telles que les images, les vidéos ou les journaux d'activité.
Quel type de base de données choisir ?
Le choix entre les bases de données dépend d'abord de vos usages. Si vos données sont structurées et doivent rester justes au centime près, comme une comptabilité ou une gestion commerciale, le relationnel s'impose. Il sait gérer des données avec rigueur et traiter de grandes quantités de données structurées. Les bases de données relationnelles vous offrent la cohérence et la sécurité des données dont une entreprise a besoin. Une base de données NoSQL se justifie quand la structure change souvent, que les fichiers sont non structurés ou que le volume explose.
Pour une PME, l'utilisation de bases de données NoSQL reste plus rare : les logiciels de gestion reposent presque tous sur le modèle relationnel. Les grandes plateformes utilisent des bases de données des deux familles, en combinant divers modèles de données. Et les bases de données relationnelles peuvent elles aussi passer dans le cloud. La plupart des fournisseurs proposent un service de base de données géré, qui prend en charge la maintenance des bases de données, les sauvegardes et les performances. Ces bases de données cloud évitent d'entretenir un serveur dans vos murs.
Pourquoi ne pas faire son reporting dans la base de l'ERP ?
La base de l'ERP est réglée pour enregistrer vite, pas pour analyser les données de plusieurs années. Une grosse requête en pleine journée peut ralentir la saisie de toute l'équipe. Chez le distributeur évoqué plus haut, le serveur ne disposait que de 3 Go de mémoire : les extractions se font donc la nuit, par lots, pour ne jamais gêner l'ERP.
C'est le rôle de l'ETL : extraire les données, les transformer, puis les charger dans un data warehouse pensé pour l'analyse, avec des structures de données adaptées. Ce stockage de données dédié sépare la gestion des données au quotidien de leur analyse. Vos données vivent dans plusieurs bases, ERP, CRM et fichiers Excel ? Il faut alors consolider vos données et réconcilier différents types de données. C'est ainsi qu'on obtient une source unique de vérité.
Conclusion : vos données sont reliées, vos chiffres aussi
Une base de données relationnelle n'a rien de mystérieux. Retenez trois idées :
- les données sont rangées dans des tables reliées par des clés, pour ne jamais saisir deux fois la même information ;
- le SQL et ses jointures relient ces tables : chaque chiffre de votre reporting en dépend ;
- le NoSQL répond à d'autres besoins, mais votre gestion repose sur le relationnel.
Vous n'avez pas besoin de devenir informaticien pour en tirer parti. Mais comprendre le lien entre vos données et les chiffres de vos tableaux de bord change votre regard. Vos données ne sont pas en vrac : elles sont reliées. Comprendre ces liens, c'est déjà commencer à exploiter vos données sur des bases fiables.
