Decideo - Actualités sur le Big Data, Business Intelligence, Data Science

Abonnez-vous gratuitement à Decideo !


Decideo

 


Petite histoire des bases relationnelles et du langage SQL


Rédigé par Damien POULAIN, CEA le 20 Septembre 2013



Damien POULAIN, Architecte applicatif au CEA
Damien POULAIN, Architecte applicatif au CEA

L'invention de David L. CHILDS

En 1968, le mathématicien hollandais D. L. Childs travaille à l'université de Michigan. Il maîtrise la théorie des ensembles du mathématicien allemand Georg Cantor et s'intéresse à l'informatique, notamment aux problèmes de performance des structures de stockage.
En août, il publie " Feasibility of a set-theoretical data structure ". 34 pages, 53 définitions, 10 théorèmes : c'est du lourd. Aucune référence : de la création pure.
Childs affirme que l'on peut exprimer toute question avec seulement 3 fonctions de base : la "sélection", la "relation", le "regroupement".
Childs démontre qu'il est beaucoup plus simple et rapide d'utiliser les fonctions ensemblistes pour répondre à des questions comme "Trouver, dans une population donnée, le nombre d'Espagnols dont la langue maternelle n'est pas l'espagnol" !

Réduire l'universalité du questionnement à 3 fonctions est fascinant.
Le penser est utopique.
Le démontrer est presque impensable.

Cette invention est à l'origine de l'aventure du SQL.

L'invention d'Edgar F. CODD

En 1965, l'informaticien Edgar Frank Codd obtient son doctorat en informatique à l'université de Michigan. A-t-il croisé Childs dans les couloirs ? L'histoire ne le dit pas.
En 1967, il rejoint le centre de recherche d'IBM à San Jose, en Californie.
Pendant que Childs publie ses travaux, Codd essaye d'inventer un système de stockage des données plus performant que le séquentiel indexé et les bases hiérarchiques. Il travaille sur une théorie d'arrangement de données basée sur des "relations".

En 1970, ses travaux aboutissent et il a une idée géniale : il pense que, grâce à son stockage de données organisé en "relationnel", la théorie de Childs peut donner lieu à l'implémentation d'un langage "universel", qu'il nomme "Universal Data Sublanguage". Il publie alors le célèbre article A Relational Model of Data for Large Shared Data Banks.
Contrairement à celui de Childs, cet article aura un retentissement énorme.

Extrait de l'introduction :
Existing noninferential, formatted data systems provide users with tree-structured files or slightly more general network models of the data. In Section 1, inadequacies of these models are discussed. A model based on n-ary relations, a normal form for data base relations, and the concept of a universal data sublanguage are introduced.
En trois phrases, tout est dit : comment passer d'une base hiérarchique à un modèle relationnel associé à un langage universel.

Autant Codd décrit très précisément le modèle relationnel, autant il décrit très peu le langage universel. Il conclue :
Many questions are raised and left unanswered. For example, only a few of the more important properties of the data sublanguage in Section 1.4 are mentioned. Neither the purely linguistic details of such a language nor the implementation problems are discussed.
Ou comment laisser la porte grande ouverte à l'invention d'un langage relationnel.

L'invention de Donald D. CHAMBERLIN

En 1974, c'est chose faite : deux informaticiens d'IBM D.D. Chamberlin et R.F. Boyce publient Sequel : a structured english query language.
Les premiers mots du futur langage SQL apparaissent.
Chamberlin et Boyce s'inspirent des travaux Childs en traduisant ses 3 fonctions ensemblistes : "sélection" par SELECT/WHERE, "relation" par FROM et "regroupement" par GROUP BY.
Ils reprennent également deux autres concepts de Childs : les sous-requêtes et l'union/intersection.
On notera que les notions de mise à jour et de jointure ne sont pas présentes. Ce n'est pas un hasard, Childs ne les a pas abordés.

N.B : Chamberlin et Boyce ne citent pas Childs dans leurs références, mais seulement Codd. A l'époque, ce ne sont pas les seuls : lire l'article de Ken North sur Childs.

En 1975, un an plus tard, Chamberlin, conscient des manques de la première version, s'associe à J.N. Gray and I.L. Traiger et publie Views, authorization, and locking in a relational data base system.
Cette publication est réellement novatrice, car elle amène tous les éléments du futur langage SQL : création des mots INSERT, UPDATE, DELETE, GRANT, REVOKE, VIEW.
Les notions de verrou et de jointure interne font également leur apparition.
Cette invention permettra la création du premier moteur SQL.

En 1976, Chamberlin résume le tout dans le livre SEQUEL-2: A Unified Approach to Data Definition.

L'invention d'Oracle

En 1978, IBM a toutes les cartes en main pour créer la première base de données relationnelle : les concepteurs (Codd et Chamberlin), des ingénieurs très motivés et un prototype nommé System/R.
Mais IBM est alors leader mondial d'un marché extrêmement rentable : les ordinateurs mainframes.
Codd essaye de convaincre IBM d'investir autour de System/R, sans succès.

La nature ayant horreur du vide, un certain Larry Ellison, saisit l'opportunité et commercialise une base de données relationnelle qu'il baptise Oracle.
Le langage Sequel est implémenté. L'acronyme se simplifie et devient Structured Query Language (on gardera la prononciation Sequel).

La bonne nouvelle concerne les mises à jour : les premières versions d'Oracle sont rapidement opérationnelles et les verrous fonctionnent.
La mauvaise surprise concerne les lectures : les jointures provoquent les produits cartésiens (prédits par le visionnaire Childs). Les temps de réponses en lecture multi-tables sont catastrophiques.
Les premières versions d'Oracle savent écrire des lignes, mais pas les restituer.

En urgence, Oracle invente la notion d'index afin de résoudre correctement les produits cartésiens et apporte la syntaxe non normalisée "+=" et "=+" des jointures externes.

Epilogue

A partir de 1980, plusieurs sociétés créent des bases de données relationnelles (IBM, Teradata, Informix, Sybase, ...). Lire l'article très bien écrit " La généalogie des SGDBR ".
Les moteurs SQL s'imposeront progressivement jusqu'à devenir le standard de fait de la gestion des données.

Les deux atouts qui font encore aujourd'hui la différence sont la simplicité de l'accès aux données :

en lecture, grâce au langage SQL
en mise à jour, grâce à la gestion automatique des verrous.
Quarante années plus tard, aucune nouvelle invention n'est venue détrôner le concept et Anne ne voit toujours rien venir.
Qui a dit que l'informatique est un perpétuel changement ?




Commentaires

1.Posté par joseph glorieux le 20/09/2013 14:31
Merci pour cet article avec plein de lien intéressant. Je suis juste choqué par votre phrase de fin "Quarante années plus tard, aucune nouvelle invention n'est venue détrôner le concept et Anne ne voit toujours rien venir". Au sens où aujourd'hui, si les bases relationnelles ont encore de longues années de vie devant elle, elles sont en perte de monopole sur le marché, challengés par le paradime NoSQL avec en fer de lance MongoDB, Cassandra, Hadoop ou neo4j par exemple.
Du coup j'en viens à ma question : qu'est-ce qui vous faire soutenir cette conclusion?

2.Posté par Abed Ajraou le 24/09/2013 14:57
Bonjour monsieur Poulain et merci pour cet article.
Comme Joseph, je m'étonne de la chute de l'article, alors que nous sommes qu'à une prémisse d'une nouvelle ère.
Le NoSQL est une avancée majeure avec son "schema less" ...
Est-ce qu'il s'agit de la première partie d'une série d'articles?

Nouveau commentaire :
Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.


Twitter
Rss
LinkedIn
Facebook
Apple Podcast
App Store
Google Play Store