N’ayez pas peur du nom à rallonge, le concept est finalement assez simple 😉

Cette technique super utile est évidemment couchée sur le papier par nos amis les retraités, dans leur bible incontournable (oui je parle de Kimball…).

Imaginez que vous bossez pour une compagnie d’assurance, qui vend des polices d’assurance pour plusieurs types de produit: auto, moto, habitation, personnelle…

Côté modélisation dimensionnelle (après consultation du chapitre 16 du DWH Toolkit), on voit bien une table de fait qui va couvrir les transactions des polices, permettant de suivre le cycle de vie des dossiers:

• Création / modification du dossier (détails de l’assuré, dates de début…)
• Création de la couverture et association à l’objet à couvrir (type de produit, options… par exemple un tout risque auto + vol)
• Obtention d’un devis avec la génération du tarif
• Validation du devis et création de la police effective, demande des justificatifs
• Obtention des justificatifs et pérénisation du dossier
• …

A cette table de fait on va associer une série de dimensions, les axes d’analyse qui nous permettront de ventiler et analyser les faits. Ici on retrouvera les différentes dates, l’assuré, la couverture et l’objet couvert, l’employé responsable du dossier, les attributs du dossier…

Seulement voilà, après réunion avec le métier, on se rend compte que les attributs des dimensions Couverture et Objet Couvert ne sont pas du tout les mêmes entre le domaine auto et habitation. En effet, il paraît assez normal qu’on ne décrive pas une maison et une voiture avec les mêmes informations.

Il est quand même à noter que pour des soucis de consolidation et de reporting transverse, on doit tout de même constituer une table de dimension « chapeau », avec une série d’attributs simples qui concerneront à la fois l’auto et l’habitation (valeur, risque, localisation géographique…).

Côté modélisation, Kimball nous recommande alors d’utiliser la technique Sur-type / Sous-type (Supertype / Subtype). Nos tables de dimension initiales deviennent des tables de Sur-type, elles détiendront les attributs communs. A ces tables on va ajouter des tables de dimension de Sous-type, à savoir Couverture Auto, Couverture Habitation, Objet Couvert Auto et Objet Couvert Habitation, qui contiendront elles les attributs spécifiques à chaque ligne de business.

Deux choses à noter:

• On réutilise les mêmes valeurs de Surrogate Key pour les dimensions Sur-type et Sous-type, inutile d’encombrer la table de fait avec des FK supplémentaires
• On intercale des vues entre ce schéma et les utilisateurs, pour apporter:
  • la vision consolidée (toutes les lignes de la table de fait et uniquement la dimension Sur-type)
  • des visions par ligne métier (un filtre sur la table de fait pour n’exposer que les transactions du type) et la dimension Sur-type accompagnée de la dimension Sous-type:

Plutôt cool non? On a le beurre et l’argent du beurre avec cette approche 😉

Evidemment on ne peut appliquer cette méthode que si les mesures présentes dans la table de fait sont communes à tous les processus métier (Auto, Habitation…)

Dans le cas contraire, il est nécessaire de créer des tables de fait différentes, chacune avec ses mesures propres. Notez que dans ce cas, il est toujours possible d’utiliser l’approche Sur-type / Sous-type, pour disposer d’une table de dimension permettant la consolidation et le reporting transverse. Voir pourquoi ne pas aller plus loin et créer une table de fait de consolidation, qui portera les mesures communes et la table de dimension Sur-type. Le gros avantage c’est d’être capable d’exposer en une passe les données de haut niveau sans repasser par 2 tables de bas niveau qui peuvent être plus lourdes (mais on s’en passe très bien si la solution contient un cube OLAP).

Pour aller plus loin: les chapitres 10 et 16 du Datawarehouse Toolkit 3rd Edition.