System R

Durant l’année 1974, une équipe de chercheurs du laboratoire IBM de San José voulait démontrer que le modèle relationnel théorisé par Edgar F. Codd quatre ans plus tôt pouvait fonctionner dans la réalité, avec de vraies données et de vrais utilisateurs. Ce projet, baptisé System R, n’était pas qu’une simple expérimentation technique. Il s’agissait de construire un pont entre la beauté mathématique du modèle relationnel et les contraintes brutales du monde industriel.

L’équipe dirigée par W. F. King débuta par ce qu’elle appela la « Phase Zéro », une période d’exploration qui dura de 1974 à 1975. Le premier prototype, limité à un seul utilisateur, implémentait déjà les bases de ce qui deviendrait SQL. Cette version initiale s’appuyait sur le gestionnaire d’accès relationnel XRM développé par Raymond Lorie au Centre scientifique IBM de Cambridge. Les chercheurs découvrirent que transformer une théorie élégante en code fonctionnel soulevait des questions inattendues. Comment stocker efficacement les données ? Comment garantir l’intégrité des transactions ? Comment faire en sorte que les requêtes s’exécutent dans des temps raisonnables ?

La vraie révolution eut lieu pendant la « Phase Un », entre 1976 et 1977. L’équipe conçut une architecture à deux niveaux qui séparait clairement les responsabilités. Le RSS (Research Storage System) gérait tout ce qui touchait au stockage physique, aux verrous et à la journalisation des modifications. Au-dessus, le RDS (Relational Data System) s’occupait des autorisations et de l’optimisation des requêtes. Cette séparation n’était pas qu’une coquetterie d’ingénieur : elle rendait possible la maintenance et l’évolution du système.

Raymond Lorie proposa début 1976 l’idée de compiler les requêtes SQL au lieu de les interpréter. Traditionnellement, les systèmes de bases de données analysaient et exécutaient les requêtes à la volée, ce qui limitait leurs performances. L’approche de System R transformait chaque requête en code machine optimisé. Pour les applications qui répétaient les mêmes opérations des milliers de fois, le gain était spectaculaire. Pour les requêtes ponctuelles, le surcoût de compilation était largement compensé par la vitesse d’exécution.

L’optimiseur automatique de requêtes constituait le cerveau du système. Il analysait chaque demande, consultait les statistiques stockées dans le catalogue système, et choisissait la stratégie d’accès aux données la plus efficace. Son algorithme calculait le coût des entrées-sorties et du temps processeur pour différentes approches. Les index, sous forme de B-trees, garantissaient des accès rapides sur de gros volumes de données.

Le verrouillage hiérarchique réglait les problèmes d’accès concurrent avec une granularité variable. Un utilisateur pouvait verrouiller un seul enregistrement pour une modification ponctuelle, ou une table entière pour une opération de maintenance. Trois niveaux d’isolation permettaient aux développeurs de choisir entre cohérence stricte et performances. Le niveau le plus exigeant garantissait que relire un enregistrement plusieurs fois dans une transaction donnait toujours un résultat identique.

La récupération après incident s’appuyait sur un mécanisme ingénieux de « pages fantômes ». Lors d’une modification, le système créait une nouvelle version de la page à un autre emplacement du disque, préservant l’ancienne jusqu’à la validation de la transaction. Des points de contrôle périodiques purgeaient les versions obsolètes. Si elle compliquait l’organisation physique des données, cette approche simplifiait considérablement la gestion des pannes.

La « Phase Deux », de 1978 à 1979, sortit System R des laboratoires pour l’installer chez de vrais utilisateurs. Des sites pilotes IBM et trois clients sélectionnés testèrent le système dans des conditions réelles. Ces expérimentations confirmèrent l’intuition initiale : les développeurs gagnaient en productivité grâce à l’uniformité du langage SQL. Qu’ils écrivent du code applicatif, lancent des requêtes ponctuelles ou définissent la structure des données, ils utilisaient la même syntaxe.

Les tests révélèrent aussi les limites du système. Pour des transactions simples manipulant peu de données, l’utilisation de tables de hachage ou de pointeurs directs aurait donné de meilleures performances. Le mécanisme des pages fantômes, malgré ses avantages pour la récupération, empêchait de regrouper efficacement les données liées sur le disque.

Un phénomène inattendu émergea lors des tests de montée en charge. L’équipe le baptisa « convoi » : quand un processus tenant un verrou très demandé était mis en attente longue par l’ordonnanceur, tous les autres processus se retrouvaient bloqués en chaîne derrière lui. La solution nécessita de repenser le protocole de libération des verrous pour éviter ces embouteillages.

System R transforma durablement l’industrie. Ses innovations architecturales – compilation des requêtes, optimisation automatique basée sur des statistiques, verrouillage hiérarchique – furent reprises par pratiquement tous les systèmes relationnels qui suivirent. En 1981, IBM commercialisa SQL/DS, son premier produit de base de données relationnelle, suivi deux ans plus tard par DB2 pour les mainframes. Oracle, Ingres et d’autres éditeurs développèrent leurs propres systèmes, démocratisant cette technologie.

L’impact dépassa largement la technique. System R prouva qu’un système informatique pouvait combiner simplicité d’usage et sophistication interne. Les utilisateurs manipulaient des concepts intuitifs – tables, lignes, colonnes – sans se soucier des mécanismes complexes qui garantissaient cohérence et performance. Cette séparation entre vue logique et physique devint un principe de l’informatique de gestion.

Le projet valida la vision d’Edgar F. Codd sur l’importance de l’abstraction dans la gestion des données. Il établit aussi l’importance d’une démarche expérimentale rigoureuse dans le développement technologique. Plutôt que de se contenter d’élégantes démonstrations théoriques, l’équipe de San José construisit un système complet et le testa dans des conditions réelles.

Face à l’émergence des systèmes NoSQL qui remettent en question certains aspects du modèle relationnel, les principes architecturaux de System R gardent leur pertinence. L’optimisation déclarative des requêtes, la gestion transactionnelle et la séparation des niveaux logique et physique restent des références.