L'histoire de SQL - Comment tout a commencé

Qui a créé SQL et pourquoi ? Découvrez-le dans cet article !

Vous apprenez SQL ? Ou êtes-vous sur le point de faire le premier pas vers le travail avec des bases de données ? Bonne décision ! Quoi qu'il en soit, il est utile de connaître l'histoire de SQL : son origine, son créateur et ses raisons.

Voici un bref historique de SQL, en commençant par son concept fondamental : la base de données.

Ted Codd et le modèle de données relationnel

Les premières bases de données informatiques sont apparues à la fin des années 1960. C'était un domaine de recherche important à l'époque. De nombreux informaticiens se sont attachés à améliorer le fonctionnement des bases de données. L'un d'eux était Edgar Frank (Ted) Codd, un informaticien anglais employé chez IBM. Dans les années 1940, il a pris part au projet de calculateur électronique à séquence sélective, le premier ordinateur électromécanique au monde.

Mais ce qui rend Codd vraiment célèbre, c'est un article publié en 1970 intitulé A Relational Model of Data for Large Shared Data Banks (Un modèle relationnel de données pour les grandes banques de données partagées), qui a marqué le début de l'ère des bases de données relationnelles en informatique. Codd est donc souvent considéré comme l'ancêtre de SQL. En 1981, il a reçu le prix Turing, la plus haute distinction en informatique, parfois appelée le "prix Nobel de l'informatique".

À l'époque où Codd a écrit son article, les bases de données hiérarchiques et en réseau étaient dominantes. Elles étaient également assez peu flexibles. Pour extraire des données de la base, il fallait essentiellement écrire un programme informatique : les données n'étaient pas accessibles aux non-programmeurs. Toute modification du modèle nécessitait des changements dans les modèles d'accès aux données - en d'autres termes, les programmes d'accès aux données devaient essentiellement être réécrits.

Dans son article, Codd proposait une idée totalement nouvelle : modéliser les données avec la notion mathématique de relations. (Aujourd'hui, nous les appelons des tables.) Le modèle de données relationnel de Codd offrait une plus grande flexibilité que les modèles de données hiérarchiques et en réseau. De nouvelles relations pouvaient être ajoutées sans modifier les relations existantes. Grâce à ses idées, le travail avec les bases de données est devenu beaucoup plus facile.

Le système R

Le modèle de Codd n'a pas connu un succès immédiat. IBM n'était pas pressé de mettre en œuvre ses suggestions. À l'époque, ils disposaient d'IMS, une base de données hiérarchique très performante. Ils ne voulaient pas saper les revenus qu'ils tiraient d'IMS en construisant un produit concurrent. () Ce n'est qu'en 1973 qu'IBM a lancé System R, un projet de recherche visant à explorer les idées de Codd sur le modèle de données relationnel. Codd n'a pas travaillé en étroite collaboration avec l'équipe de System R ; il est difficile de savoir pourquoi il a été écarté d'un projet basé sur ses propres travaux. Deux personnes impliquées dans le développement de System R, Don Chamberlin et Ray Boyce, étaient chargées de créer son langage d'interrogation.

Un langage d'interrogation pour les bases de données relationnelles

Les jointures dans l'article de Codd

Dans son article fondateur, Codd a proposé un ensemble d'opérations pouvant être utilisées pour extraire des données des relations. Vous pouvez considérer ces opérations comme le premier langage d'interrogation pour les bases de données relationnelles. Bien entendu, la syntaxe était complètement différente du SQL que nous connaissons aujourd'hui ; Codd a utilisé la notation mathématique pour ce langage. La plupart des opérations proposées par Codd peuvent être effectuées dans le SQL d'aujourd'hui, mais avec une notation différente.

À l'époque, Don Chamberlin travaillait sur les bases de données hiérarchiques et avait étudié le langage d'interrogation de ces bases. Il a immédiatement compris l'impact du modèle de données de Codd. En 1995, il se souvient :

"Pour Ray et moi, notre exposition au modèle de données relationnel lors du symposium de recherche de Codd a été une révélation. Pour la première fois, nous avons pu voir comment une requête qui aurait nécessité un programme complexe dans le langage DBTG pouvait être réduite à quelques lignes simples en utilisant l'un des langages relationnels de Codd. C'est devenu un jeu pour nous deux d'inventer des requêtes et de nous mettre au défi de les exprimer dans divers langages de requêtes." ^[1]

En fait, Codd a proposé deux langages différents pour le modèle relationnel : l'algèbre relationnelle (la base de ce langage se trouvait dans son article original de 1970), et le calcul relationnel (également connu sous le nom de langage Alpha). Ces deux langages utilisent une notation mathématique avec des quantificateurs et divers opérateurs mathématiques. Vous pouvez voir des idées de l'algèbre relationnelle de Codd dans SQL aujourd'hui.

Irv Traiger, qui a également travaillé chez IBM à cette époque, ajoute :

"Glenn Bacon, qui avait le département des systèmes, avait l'habitude de se demander comment Ted pouvait justifier que tout le monde soit capable d'écrire ce langage basé sur le calcul mathématique des prédicats, avec des quantificateurs universels et des quantificateurs existentiels, des variables et des trucs vraiment, vraiment poilus." ^[2]

Le calcul relationnel/Alpha est devenu la base de QUEL, le langage d'interrogation d'Ingres (Interactive Graphics Retrieval System), une des premières bases de données relationnelles développée par Michael Stonebraker à l'Université de Californie, Berkeley. Ingres a évolué vers de nombreuses applications de bases de données commerciales, telles que PostgreSQL.

Le jeu des requêtes

Avant même le lancement du projet System R, Chamberlin et Boyce ont mis au point un langage qu'ils ont appelé SQUARE (Specifying Queries as Relational Expressions). Ils appréciaient la puissance des idées de Codd, qui leur permettait d'utiliser quelques lignes pour exprimer des requêtes complexes qui prendraient des pages dans une base de données hiérarchique. Cependant, ils étaient convaincus que leur langage était plus simple et plus accessible aux utilisateurs ordinaires que l'algèbre relationnelle et le calcul relationnel de Codd.

"Ray et moi étions impressionnés par la manière compacte dont les langages de Codd pouvaient représenter des requêtes complexes. Cependant, dans le même temps, nous pensions qu'il devait être possible de concevoir un langage relationnel qui serait plus accessible aux utilisateurs sans formation formelle en mathématiques ou en programmation informatique." ^[1]

SQUARE était la base du nouveau langage d'interrogation de System R. SQUARE utilisait beaucoup d'indices et certaines notations mathématiques. Il était difficile à taper sur un clavier. Chamberlin et Boyce ont décidé de l'adapter pour qu'il ressemble à la structure d'une phrase anglaise et soit plus facile à taper.

"Nous avons donc commencé à dire que nous allions adapter les idées de SQUARE à une approche plus anglaise des mots-clés, plus facile à taper parce que basée sur des structures anglaises. Nous l'avons appelé Structured English Query Language et avons utilisé l'acronyme SEQUEL pour cela." ^[2]

Deux choses étaient importantes pour Chamberlin et Boyce dans la conception de SEQUEL. Tout d'abord, ils voulaient qu'il soit accessible aux utilisateurs ordinaires sans formation mathématique ou de programmation. Le personnel de System R a même recruté un groupe d'étudiants pour apprendre SEQUEL et voir s'ils trouvaient la syntaxe facile. En outre, ils voulaient que le langage contienne des éléments de modification et de définition des données, ce qui était quelque chose de très nouveau à l'époque.

"Ray et moi espérions concevoir un langage relationnel basé sur des concepts qui seraient familiers à une plus large population d'utilisateurs. Nous espérions également étendre le langage pour englober les mises à jour des bases de données et les tâches administratives telles que la création de nouvelles tables et vues, qui étaient traditionnellement hors de portée d'un langage de requête.
[...] Ce que nous pensions faire, c'était rendre possible l'interaction des non-programmeurs avec les bases de données. Nous pensions que cela allait ouvrir l'accès aux données à une toute nouvelle catégorie de personnes qui pourraient faire des choses qui n'étaient jamais possibles auparavant parce qu'elles ne savaient pas programmer." ^[2]

Enfin, Chamberlin et Boyce ont écrit deux articles sur SEQUEL : un sur le DML (langage de manipulation des données, par exemple les instructions SELECT, INSERT et UPDATE) et un sur le DDL (langage de définition des données, qui est utilisé pour créer et modifier la structure des bases de données).

"Nous avons écrit deux articles : un sur SEQUEL/DML et un sur SEQUEL/DDL. Nous avons coopéré très étroitement sur ce sujet. Les auteurs de l'article sur DML étaient Chamberlin et Boyce ; les auteurs de l'article sur DDL étaient Boyce et Chamberlin, sans raison particulière ; nous nous sommes simplement séparés. Nous voulions aller à Stockholm cette année-là parce que c'était l'année du congrès de l'IFIP à Stockholm. J'avais un billet pour Stockholm en raison d'un travail que j'avais fait à Yorktown, alors Ray a soumis le document DDL au congrès de l'IFIP à Stockholm, et le document DML a été soumis à SIGMOD. [...] Il s'agissait d'articles jumeaux dans notre estimation originale. Nous les avons écrits ensemble et pensions qu'ils étaient de valeur et d'impact comparables. Mais ce qui leur est arrivé est bien différent. L'article DDL a été rejeté par le congrès de l'IFIP ; Ray n'a pas pu aller à Stockholm". ^[2]

Et c'est ainsi que SEQUEL est né. Plus tard, SEQUEL a été renommé SQL en raison d'un problème de marque déposée.

Malheureusement, Ray Boyce est décédé peu de temps après avoir jeté les bases de SQL ; il n'a jamais pu voir l'impact qu'il aurait. En 1974, environ un mois après avoir présenté un article sur SEQUEL lors d'une conférence technique à Ann Arbor, Michigan, il est soudainement décédé d'une rupture d'anévrisme cérébral. Il n'avait que 26 ans.

Il est intéressant de noter que Donald Chamberlin ne considérait pas SQL comme un bon langage pour la façon dont il était utilisé à l'époque. En 1995, il a déclaré :

"Lorsque Ray et moi avons conçu Sequel en 1974, nous pensions que l'utilisation prédominante du langage serait pour des requêtes ad-hoc par des planificateurs et d'autres professionnels dont le domaine d'expertise n'était pas principalement la gestion de bases de données. Nous voulions que le langage soit suffisamment simple pour que les gens ordinaires puissent l'utiliser avec un minimum de formation. Au fil des ans, j'ai été surpris de constater que SQL est plus fréquemment utilisé par des spécialistes des bases de données formés pour mettre en œuvre des transactions répétitives telles que les dépôts bancaires, les achats par carte de crédit et les ventes aux enchères en ligne. Je suis heureux de voir le langage utilisé dans des environnements variés, même s'il ne s'est pas avéré aussi accessible aux utilisateurs non formés que Ray et moi l'espérions au départ." [1]

SQL devient un standard industriel

Au fil des ans, SQL est devenu une norme industrielle. Pour l'instant, il suffit de dire que SQL est devenu le langage de base pour travailler avec des bases de données. Il a été reconnu par toutes les organisations importantes, et les géants du marché tels que Google et Facebook l'utilisent quotidiennement pour de nombreux processus.

SQL et les bases de données sont actuellement l'une des branches de l'industrie informatique qui connaît la croissance la plus rapide. Rattraper cette tendance peut s'avérer payant. Si vous souhaitez commencer à apprendre SQL à partir de zéro, essayez notre SQL pour les débutants cours. Si vous connaissez déjà un peu SQL et que vous voulez apprendre à mieux analyser le comportement de vos clients ou les tendances de vos revenus, je vous recommande la piste SQL Reporting. Et si vous connaissez SQL et êtes bloqué sur un problème spécifique, consultez notre livre de recettes SQL, qui contient de nombreux scripts SQL prêts à l'emploi. N'hésitez pas à les copier dans votre projet.

Quel que soit votre choix parmi l'offre étendue de LearnSQL.fr, c'est le bon moment pour apprendre SQL. C'est un langage qui a 40 ans, mais qui n'est pas près de disparaître. La connaissance de SQL est une excellente compétence qui vous sera utile dans votre travail quotidien et donnera un coup de pouce à votre carrière.

Sources :

1. Chamberlin, Donald D. "Early History of SQL" Consulté le 11 novembre 2020 sur https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6359709

2. McJones et al. "The 1995 SQL Reunion : People, Projects and Politics ", consulté le 11 novembre 2020 sur http://www.scs.stanford.edu/~dbg/readings/SRC-1997-018.pdf.