Les quatre types de systèmes de gestion de données – hiérarchique, réseau, relationnel et orienté objet – reposent chacun sur un modèle de structuration distinct. Leur coexistence dans les architectures modernes n’est pas un héritage passif : elle répond à des contraintes techniques précises que nous détaillons ici.
Modèle hiérarchique et modèle réseau : ce que le schéma impose au SGBD
Le modèle hiérarchique organise les données en arborescence parent-enfant. Chaque nœud possède un seul parent. Cette rigidité du schéma rend les lectures descendantes très rapides, mais interdit les relations transversales sans duplication d’enregistrements.
Lire également : Quels sont les inconvénients du Bluetooth ?
Le modèle réseau lève cette contrainte en autorisant plusieurs relations parent-enfant entre nœuds. Un enregistrement peut appartenir à plusieurs ensembles simultanément. Le gain en flexibilité se paie par une complexité accrue de navigation : le développeur doit connaître la structure physique du graphe pour formuler ses requêtes.
Nous observons que ces deux modèles subsistent dans des systèmes critiques (télécommunications, mainframes bancaires) où la réécriture vers un SGBD relationnel représenterait un risque opérationnel disproportionné. Leur point commun : le langage de manipulation est procédural, pas déclaratif. L’application décrit comment parcourir les données, pas ce qu’elle veut obtenir.
Lire également : Quels sont les inconvénients de l'AI ?
SGBD relationnel et langage SQL : pourquoi le modèle domine encore
Le modèle relationnel structure les données en tables composées de lignes et de colonnes. Les relations entre entités passent par des clés étrangères, sans que l’application ait besoin de connaître le chemin d’accès physique. Le langage SQL, déclaratif, décrit le résultat attendu et laisse l’optimiseur du SGBD choisir le plan d’exécution.
Cette séparation entre logique et physique explique la domination du modèle. Oracle, MySQL, Microsoft SQL Server ou PostgreSQL fonctionnent tous sur ce principe. Le schéma est défini avant l’insertion des données, ce qui garantit l’intégrité référentielle et facilite les transactions conformes aux propriétés ACID.
La contrepartie est connue : un schéma rigide freine l’évolution rapide des structures de données. Ajouter une colonne à une table de plusieurs milliards de lignes reste une opération lourde sur la plupart des SGBD relationnels en production. C’est précisément ce point de friction qui a ouvert la voie aux bases NoSQL, souvent confondues à tort avec le quatrième type classique.
SGBD orienté objet : un modèle distinct du NoSQL
Le quatrième type de la classification traditionnelle est le système de gestion de base de données orienté objet. Il stocke les données sous forme d’objets, au sens de la programmation orientée objet : attributs, méthodes, héritage et encapsulation sont gérés directement par le SGBD.
L’intérêt principal est l’élimination du décalage d’impédance entre le modèle applicatif et le modèle de persistance. Une application Java ou C++ manipule des objets ; un SGBD orienté objet les persiste tels quels, sans conversion vers un schéma tabulaire.
En pratique, ce modèle n’a jamais atteint la part de marché du relationnel. Les raisons sont techniques :
- L’absence d’un langage de requête standardisé aussi répandu que SQL a freiné l’adoption par les équipes d’exploitation et les outils de reporting.
- Les performances en lecture analytique restent en retrait par rapport aux moteurs relationnels optimisés pour les jointures massives.
- La dépendance au langage de programmation hôte limite la portabilité entre écosystèmes techniques.
Nous recommandons de ne pas confondre SGBD orienté objet et bases NoSQL documentaires. Un document JSON dans MongoDB n’est pas un objet au sens OOP : il n’a ni méthode, ni héritage, ni polymorphisme géré par le moteur de stockage.
Architectures polyglot et Data Act : ce qui change pour le choix d’un SGBD
Les quatre types classiques ne suffisent plus à décrire les architectures en production. Nous observons un recours systématique à plusieurs moteurs en parallèle : une base relationnelle pour les transactions, un lakehouse pour l’analytique, une base vectorielle pour l’IA. Cette approche, dite polyglot persistence, impose de raisonner en termes de flux de données entre systèmes plutôt qu’en modèle unique.
Le cadre réglementaire européen accentue cette tendance. Depuis le 12 septembre 2025, le Data Act impose aux fournisseurs de services de traitement de données (IaaS, PaaS, SaaS) de supprimer les obstacles contractuels, techniques et commerciaux au changement de fournisseur. Concrètement, un SGBD cloud doit permettre l’export des données dans un format exploitable par un service concurrent.
La portabilité ne signifie pas conservation automatique des fonctionnalités. Le règlement distingue l’export des données de la fonctionnalité équivalente, exigée surtout pour les services d’infrastructure. Migrer d’un SGBD relationnel managé vers un autre récupère les données, mais pas nécessairement les procédures stockées, les index propriétaires ou les extensions spécifiques au fournisseur.
Pour les entreprises, le choix d’un type de SGBD devient indissociable de la stratégie de portabilité :
- Un SGBD relationnel sur infrastructure cloud doit exposer des formats d’export standard (SQL dump, Parquet, CSV structuré) pour rester conforme au Data Act.
- Un SGBD NoSQL documentaire ou clé-valeur doit documenter son schéma implicite pour qu’un service tiers puisse interpréter les données exportées.
- Un SGBD orienté objet, déjà marginal, pose un défi de portabilité accru : la sérialisation des objets dépend du langage hôte, ce qui complique l’interopérabilité.
Le modèle de données ne détermine plus seul le choix du SGBD. La conformité réglementaire, la capacité d’export et l’interopérabilité entre services pèsent désormais autant que les performances brutes du moteur. Les quatre types classiques restent un cadre utile pour comprendre la logique de structuration, mais ils ne couvrent qu’une partie des critères de sélection en environnement de production actuel.
