Il n’est pas rare d’entendre dans nos contrée que Ralph Kimball en est à l’origine… Rendons à César ce qui revient à César; à l’origine du monde de la data, il y a un génie quelque peu oublié: Edgar Frank Codd docteur en informatique, chercheur chez IBM.

naissance de l’informatique de gestion

L’informatique de gestion apparaît dans les années 60. A cette fin, on développe les premières bases de données.
En 1970, Edgar Frank Codd publie un article fondateur du Système de Gestion de Bases de Données Relationnelles alias SGBDR: il énonce 8 formes normales pour concevoir un système OLTP (OnLine Transaction Processing) robuste. Les formes normales expliquent comment créer les jeux de données et comment les relier entre eux pour assurer efficacement la mission de l’informatique de gestion: enregistrer des transactions, éviter les redondances, permettre plusieurs process simultanés d’écriture, gestion des accès concurrentiels…

standardisation du SGBDR

L’apparition des micro-processeurs dans les années 70 puis des micro-ordinateurs dans les années 80 provoquent une explosion de l’usage professionnel de l’informatique et particulièrement de l’informatique de gestion.
Les SGBDR sont des succès commerciaux (Oracle, DB2…). Ils reposent sur les fondamentaux :

• schéma de base de données “normalisé”
• gestion des transactions/verrous ACID

Les entreprises et autres organisations utilisent de nombreux systèmes OLTP basés sur des SGBDR:

• ERP
• CRM
• gestion de production
• gestion de stock
• payes - ressources humaines
• etc…

aide à la décision

La base de données OLTP d’abord créée pour faire vivre l’entreprise et ses processus est consultée à la demande des directions pour extraire des informations en vue d’aider à la prise de décisions.

• Quel est la progression du C.A., de la marge ?
• globale puis par catégorie de produits ?
• Quel est le profil des clients ayant profité de la promotion Saint Valentin?

Cette démarche rencontre vite des limites :

• lenteur
• parcours du modèle normalisé
• verrous, transactions
• pas d’historique : il faut aller le chercher sur des sauvegardes
• ralentissement de la production, freinée par les analyses
• difficile de présenter des résultats issus de plusieurs systèmes OLTP distincts : c’est souvent un emploi à plein temps, non automatisé.
• résultats / chiffres différents de ceux du voisin de bureau. Qui a raison ?

informatique décisionnelle

L’informatique décisionnelle apparaît pour répondre à ces limites par les solutions suivantes :

• modélisation OLAP : schéma de base “dénormalisé”, orienté métier, multi-dimensionnel
• Création d’une base de données “Entrepôt de données” ou data warehouse
  • dédiée à l’aide à la décision
  • synchronisée avec un ou plusieurs systèmes OLTP
  • conservant un historique
• outil de “requêtage”/“reporting” centralisé diffusant “une seule version de la vérité”

Fin 1993, 2 années avant la parution du célèbre the datawarehouse toolkit de Ralph Kimball, Edgar Frank Codd définit 12 règles que tout système de pilotage OLAP se doit de respecter pour

être en mesure de distribuer les données aux utilisateurs sans les obliger à apprendre des complexes formules de programmation, d’interrogation ou même à ce qu’ils aient à programmer les tableurs

Parmi ces règles (pour en savoir plus en anglais):

• Multidimensional conceptual view
• Generic Dimensionality
• Unrestricted cross-dimensional operations
• Unlimited Dimensions and aggregation levels

Or qui dit ‘dimensions’, dit ‘schema en étoiles’…

aparté sur le paradoxe de la dénormalisation

Naturellement, l’humain fait des listes dans des cahiers et des registres. Ces registres ont plein d’inconvénients : redondances, lenteur, écrivain unique du cahier… La liste est une forme naturelle de conservation de la donnée mais qui est optimale pour lire cette donnée, mais pose des problèmes quant à l’écriture. Les formes normales, sont la création d’un processus de transformation pour répondre à ce problème d’écriture. On passe d’une macro liste redondante à plusieurs micro listes sans redondance et reliées intelligemment. Une ligne de registre devient plusieurs petites lignes dans plusieurs sous registres : le registre des clients, le registre des codes postaux, le registre des produits… On autorise donc plusieurs accès simultanés et des accès beaucoup plus bref. Les formes normales définissent comment créer ces sous registres pour répondre au mieux à la problématique de l’écriture. A l’inverse, elles rendent difficile voire pénible la lecture de l’information complète puisqu’il faut consulter plusieurs registres et les mettre en relation. Mais notre façon de penser, c’est la liste, celle de la feuille Excel (ou multiplan, visicalc pour les retraités).

Donc le processus historique a été le suivant:

1. de Cro-Magnon à Codd, on remplit des listes dans des registres
2. Codd définit les formes normales
3. les formes normales répondent tellement au besoin de la société post révolution industrielle, qu’elles deviennent normales
4. pour lire ces données, on les transforme d’un modèle normal à un modèle naturel. On revient en arrière en quelque sorte. C’est la dé-normalisation ou la naturalisation.

La forme ultime de dénormalisation est la liste de la feuille Excel. La forme en étoile, ou dimensionnelle, est une étape, évidente et intuitive, entre cette liste et les formes normales de Codd. Pas besoin d’être chercheur chez IBM pour ranger les pays dans un registre des pays, les fournisseurs dans un registre fournisseurs… Les formes normales, c’est autrement plus ingénieux.

Le processus a donc été le suivant :

1. de Cro-Magnon à Codd, on remplit des listes dans des registres
2. on réfléchit à comment optimiser l’écritures des données, le schéma en étoile est une première étape mais ça ne répond pas par exemple à la problématique de redondance.
3. Codd définit les formes normales
4. les formes normales sont utilisées partout et stocke des trésors de data difficiles d’accès
5. l’informatique décisionnelle ou business intelligence impose un retour en arrière, la dénormalisation jusqu’au schéma en étoile (voire en flocon). Par rapport au registre plat, il offre un bon compromis pour l’écriture, la mise à jour, en offrant des très bonnes performances en lecture.

à suivre

Par la suite, l’histoire montrera avec le stockage vertical des données que la modélisation d’un espace multidimensionnel n’est peut-être pas la panacée pour remplir le cahier des charges OLAP, puisqu’on revient maintenant à des modèles relationnels (comme le vertipaq ou modèle tabulaire), mais toujours optimisés lorsqu’utilisés avec des schémas en étoile.

• histoire
• BI
• autre