Premier article d'une (peut-être) série sur l'informatique décisionnelle.
Le truc de base dans le domaine des data warehouses, c'est de parler de modèle en étoiles. Vos interlocuteurs peuvent même pousser plus loin le romantisme et vous parler de modèle en flocons. Ces concepts sont accompagnés des termes faits et dimensions.
Aujourd'hui, je suis motivé et je vais tenter de vous expliquer comment tout cela s'articule est ce que cela apporte à un système d'informatique décisionnelle. Si vous êtes expert en BI, vous pourrez certainement passer votre chemin (il y a d'autres trucs intéressants à lire je crois).
Faits et dimensions
Plus généralement, le modèle de données associés aux applications data warehouse est appelé modèle dimensionnel. Il s'articule autour des notions de faits et de dimensions.Les faits, ce sont tous les événements mesurables qui sont stockés dans notre base de données : des lignes de facturation, des appels téléphoniques ou des entrées sur un compte bancaire. Les faits sont les éléments sur lesquels nous réalisons des agrégations : montant mensuel ou annuel facturé, nombre de minutes utilisé par un client sur un forfait de téléphonie mobile, compte de résultat, etc. L'autre particularité des faits ? Ils sont très nombreux et représentent la plus grande part des données stockées. En effet, ils sont insérés de façon continue dans la base : tous les jours, toutes les heures voire toutes les minutes ou toutes les secondes ! Imaginez un data warehouse derrière Amazon.com. Oui, moi aussi j'en tremble...
En dehors des éléments mesurables, les faits portent peu d'information : quasi systématiquement, un élément de date et une référence sur les éléments métier concernés comme un identifiant de compte ou un numéro de contrat.
Si nous nous limitons aux faits, nous voyons bien que les données sont difficilement exploitables. Il manque clairement de l'information sur ces faits. Combien est-ce que j'ai vendu de lampes de chevet à des hommes ayant souscrit au programme de fidélité de l'enseigne, dans mon magasin sur les Champs-Élysées pendant les soldes d'hiver ?
Difficile de le faire en l'état et encore plus difficile (impossible ?) de le faire en temps réel. C'est là que les dimensions entrent en scène. Les dimensions sont les points d'entrée pour l'interrogation des faits. Ce sont elles qui permettent de faire des requêtes comme celle décrite plus haut.
Prenons un cas concret à présent. Imaginons que nous sommes un constructeur automobile et que nous voulons garder l'historique des ventes dans un entrepôt de données. Pour chaque produit vendu, nous voulons tracer les informations ci-dessous :
- la date de vente,
- l'heure de vente,
- le produit vendu,
- l'identifiant du client,
- l'identifiant du vendeur,
- l'identifiant du concessionnaire,
- le prix de vente (évidemment).
Ce qu'on peut voir, c'est que j'ai choisi de faire porter toutes les informations par des identifiants à l'exception du prix, car je veux pouvoir faire des sommes facilement, pour fournir un résultat mensuel par exemple. Le reste des champs trouve une correspondance dans des tables de dimension spécifiques. Le modèle complet est le suivant :
Avec un peu d'imagination, on peut s'apercevoir que ça ressemble à une espèce d'étoile. Vous avez compris.
On parle parfois de modèle en flocon. Il s'agit d'une normalisation partielle du modèle en étoile : des sous-tables de dimension sont associées à une table de dimension principale. Dans notre exemple, nous pourrions sortir l'information de concessionnaire de notre table de fait pour l'associer à la dimension des vendeurs.
Points forts, points faibles
Le point fort principal de ce modèle est de donner la possibilité de faire porter autant d'information que souhaité par les dimensions. On peut ainsi répondre facilement à beaucoup de demandes métier. L'autre intérêt est technique car on rationalise l'espace de stockage. Nos faits contiennent des milliards de lignes. Dans notre modèle, chaque enregistrement n'est composé que de nombres, ce qui prends moins d'espace que des chaînes de caractères. Les dimensions contiennent quant à elle peu d'enregistrements en comparaison et même si elle sont essentiellement composées de chaînes de caractères, l'espace disque qu'elles occupent reste négligeable comparé à celui occupé par les faits.L'interrogation des faits à partir d'une dimension est simple : il suffit d'utiliser la jointure / clé étrangère correspondante.
Le défaut de ce modèle, si on peut dire est qu'il ne prend pas facilement en compte les évolutions des dimensions. Celles-ci peuvent évoluer dans le temps. C'est le cas par exemple de l'adresse d'un client. Chaque ensemble vérifié de dimensions doit rester stocké. Si vous traitez des comptes-rendus d'appels téléphoniques et qu'un client change de numéro de téléphonie au 1er Février, les interrogations de ses appels antérieurs à cette date doivent utiliser le son précédent numéro. À la longue, la taille des tables de dimension peuvent s'avérer importante, ce qui complexifie leur utilisation. Le modèle en flocon peut alors représenter une solution partielle au prix toutefois de la facilité d'interrogation.
J'en reste là pour l'instant. Le modèle dimensionnel est la clé de voute de l'informatique décisionnelle. J'espère ce cet article donne les rudiments pour permet d'adresser avec beaucoup de souplesse les problématiques fonctionnelles inhérentes à ce domaine.
Pour approfondir le sujet, je vous conseille la lecture du livre The datawarehouse toolkit de Ralph Kimball, qui vous enseignera l'ensemble des techniques pour la création d'un bon gros data warehouse.
