Avant-propos

Introduction

Permettez-moi de me présenter, non seulement comme l’auteur de cet ouvrage, mais surtout comme un compagnon de route. Je suis, comme vous l’êtes ou l’aspirez à être, un architecte de données, un ingénieur, un chef de projet data… Bref, un artisan de l’information.

Et, comme vous, j’ai connu cette frustration.

Imaginez la scène : une réunion CODIR, un membre fixant un tableau de bord aux chiffres figés, demande : « C’est bien, mais… pourquoi ? Pourquoi les ventes de ce produit ont-elles chuté dans le Nord, mais seulement pour les clients de plus de quarante ans, et seulement la troisième semaine de mars ? »

Le silence qui suit cette question est souvent assourdissant.

Nous vivons ce que je peux appeler le paradoxe des données : nous n’avons jamais collecté autant de téraoctets de données opérationnelles, de logs, de transactions et, pourtant, nous n’avons jamais été aussi affamés d’une véritable compréhension. Nos bases de données transactionnelles sont des TGV conçus pour enregistrer l’information à toute vitesse. Mais essayer d’y faire de l’analyse, c’est comme demander au TGV d’aller lentement pour profiter du paysage. C’est lent, inefficace, et ce n’est pas fait pour cela.

Le problème n’est pas un manque de données....

La mission de l’ouvrage

C’est de ce constat qu’est né ce livre.

Après des années à construire, défaire, réparer et optimiser ces structures complexes, j’ai voulu créer la ressource que j’aurais rêvé d’avoir à mes débuts. Pas un simple manuel technique lié à un produit (qu’il s’agisse de Microsoft SSAS, Oracle Essbase ou d’autres), mais un guide de principes. Un livre qui se concentre sur le Pourquoi et le Comment de la conception, avant même d’écrire la moindre ligne de code.

La thèse centrale de cet ouvrage est simple : un cube OLAP performant n’est pas un entrepôt de données ; c’est l’incarnation d’un processus métier.

Sa conception n’est pas une simple affaire technique de jointures et d’index. C’est un exercice de traduction, où l’on transforme les questions stratégiques de l’entreprise en une structure de données élégante, rapide et flexible.

Ce livre est votre boussole. Il est conçu pour vous guider, étape par étape, de la page blanche à un modèle robuste capable de répondre non seulement aux questions d’aujourd’hui, mais aussi à celles, inconnues, de demain. Nous n’allons pas seulement apprendre des définitions ;...

À qui s’adresse ce livre ?

J’ai écrit ce livre en pensant à plusieurs profils, car la modélisation est un sport d’équipe :

La construction du livre

J’ai organisé ce livre comme un voyage. On pose un drapeau sur un nouveau territoire, puis on bâtit notre ville, des fondations aux systèmes de défense high-tech.

Voici la carte que je vous propose :

Partie 1 - Les bases (chapitre Introduction à la modélisation multidimensionnelle et chapitre Modélisation physique et conceptuelle OLAP)

On prend les choses par le début. Au chapitre Introduction à la modélisation multidimensionnelle, nous établirons notre langage commun. Quelle est la différence de base, philosophique et architecturale entre OLTP et OLAP ? C’est le commencement de tout. Nous allons décortiquer les notions de mesures (ce qu’on compte), de dimensions (comment on le compte), de faits (les événements) et de granularité (le niveau de détail). Nous aborderons également les technologies (MOLAP, ROLAP, HOLAP) pour comprendre comment ça fonctionne.

Au chapitre Modélisation physique et conceptuelle OLAP, on construit les fondations. Nous aborderons les trois principaux schémas : le schéma en étoile, pratique et performant ; le schéma en flocon de neige, normalisé et parfois indispensable ; et la constellation de faits, pour les processus métiers liés. Nous les présenterons, nous les opposerons, pour savoir quand utiliser quoi.

Partie 2 - Le cœur du modèle (chapitre Modélisation des dimensions et hiérarchies et chapitre Modélisation des tables de faits et des agrégats)

C’est là que se joue 80 % de la valeur (et des problèmes) de votre projet.

Le chapitre Modélisation des dimensions et hiérarchies est consacré à l’âme du cube : les dimensions. Une dimension n’est pas une liste. C’est un organisme vivant. Nous verrons comment créer des hiérarchies (Produit → Catégorie → Département) pour une navigation intuitive. Mais surtout, nous allons nous attaquer au monstre de la BI : le temps et le changement. Les SCD (Slowly Changing Dimensions) de Type 0 à 6 n’auront plus de secret pour vous.

Nous verrons comment modéliser le fait qu’un client déménage ou qu’un commercial change de secteur, sans perdre l’historique. Nous aborderons également les dimensions spéciales : multi-hiérarchies, parent-enfant (pour les organigrammes), multivaluées, à rôles multiples (une date est une date de commande, de livraison, de facture...), dégénérées et fourre-tout.

Le chapitre Modélisation des tables de faits et des agrégats s’intéresse au moteur : les tables de faits. Nous allons voir que tous les chiffres ne se valent pas. On distinguera les faits additifs (des ventes s’additionnent), semi-additifs (un solde de stock ne s’additionne pas dans le temps) et non-additifs (un ratio). Nous dompterons les types de tables de faits pour capturer vos processus : les snapshots périodiques (l’inventaire en fin de mois) et les snapshots cumulatifs (le cycle de vie d’une commande). Nous aborderons l’importance du choix de la granularité et nous présenterons les techniques d’agrégation pour répondre en quelques secondes sur des pétaoctets de données.

Partie 3 - Relations avancées et performance (chapitre Optimiser les relations faits et dimensions et chapitre Optimisation des performances des cubes OLAP)

Votre modèle est prêt. Maintenant, faisons-le à grande échelle.

Le chapitre Optimiser les relations faits et dimensions est important. Il parle de ce qui connecte tout : les relations. Nous aborderons la gestion des clés (l’importance des clés artificielles ou surrogate keys). Nous verrons comment gérer des modèles complexes avec plusieurs tables de faits (par exemple, Ventes et Stock) et comment permettre à l’utilisateur de « naviguer à travers » (drill-across) ces faits. Nous allons parler d’un sujet technique mais puissant : la gestion des relations Many-to-Many, généralement avec des tables de pont (bridge tables).

Le chapitre Optimisation des performances des cubes OLAP abordera l’optimisation. Un cube fonctionnel mais lent est un cube mort. Nous verrons les techniques d’optimisation de performance. On parlera d’indexation (Columnstore, Bitmap), de partitionnement (pour archiver les vieilles données ou charger les nouvelles plus rapidement), de pré-agrégation et de mise en cache. Nous irons jusqu’à...

Quelques conventions pour la route

Pour rendre la lecture la plus fluide possible, nous utiliserons quelques conventions :

SELECT 
    d.DimensionName, 
    SUM(f.MeasureValue) 
FROM 
    FactTable f 
JOIN 
    DimensionTable d ON f.DimensionKey = d.DimensionKey 
GROUP BY 
    d.DimensionName ; 

La modélisation multidimensionnelle constitue l’un des domaines les plus passionnants de l’ingénierie des données. Elle est en effet ce lieu où se croisent technique pure, optimisation des systèmes et compréhension fine des besoins métiers.

C’est un savoir-faire. Or, comme l’artisanat, il nécessite de la rigueur, de l’entraînement et de bons outils. Mon projet dans ce livre est de vous donner ces outils, de vous rendre, à l’issue de la lecture, apte à bâtir des univers analytiques...