Gestion des grandes dimensions changeantes ou à évolution rapide
Dans le contexte d’une dimension de type HV de très grande taille ou dont les évolutions sont très rapides il n’est pas envisageable de mettre en oeuvre une évolution de type 2.
La solution est de mettre en oeuvre le concept de mini-dimension. Il s’agit d’isoler de la table de dimension les attributs dont l’évolution est trop rapide, pour les assembler dans une nouvelle dimension. Cette nouvelle dimension, appelée mini-dimension, sera particulière dans le sens où chaque ligne correspondra à un profil. Chaque profil correspond à une combinaison de valeurs ou de plages de valeurs pour chacun des attributs de façon à :
- réduire le nombre de lignes dans la dimension
- correspondre à un usage métier
Exemple
Prenons l’exemple d’une compagnie d’assurance santé. Afin d’avoir un suivi des ventes de polices d’assurance, le schéma dimensionnel présenté dans le schéma ci-dessous a été proposé.
On constate que la dimension POLICY est une dimension de type HV car à chaque modification des attributs marital_status, family_size, covered_parties, covered_children, deductible_amount on a ajouté une nouvelle ligne pour conserver les informations de la police d’assurance souscrite et de la couverture du client. Dans le tableau ci-dessus on comprend qu’il s’agit de la même police d’assurance car la clef métier (Business Key BK) correspondant à l’attribut policy_number reste toujours à la même valeur 40111. L’attribut policy_key, quant à lui, est une clef artificielle nous permettant ici de gérer l’évolution de la police d’assurance.
Afin de gérer l’évolution de la dimension POLICY, nous allons la diviser en deux dimensions : une dimension POLICYqui ne contiendra plus que les informations permanentes concernant la police (ici la clef métier et l’assuré) et une mini-dimension POLICY_COVERAGE qui contiendra les informations concernant la couverture de l’assuré (voir figure ci-dessous).
La dimension POLICY_COVERAGE est peuplée (c’est-à-dire remplie de lignes) une fois pour toutes en la remplissant de toutes les combinaisons possibles des valeurs d’attributs pour décrire la couverture d’un assuré. Attention toutefois à la cardinalité résultante ! Si avec les attributs ayant peu de valeurs discrètes possibles, il n’y a pas de problèmes (family_size, covered_parties, covered_children), des attributs comme deductible_amount pourraient faire exploser le nombre de profils. C’est pourquoi, pour ce type d’attributs à valeurs continues, nous allons le transformer en une plage de valeurs : 0-200, 200-500 et 500+ par exemple.
Au niveau de la table de faits, nous aurons ainsi à associer à chaque vente de police d’assurance une référence à la police et une référence à la couverture correspondante. La taille de la dimension POLICY_COVERAGE est désormais contrôlée et la dimension POLICE n’évolue plus en type 2. Un problème se pose toutefois : comment connaître la couverture actuelle offerte par une police ? En effet, dans la table de faits, nous n’avons l’information que pour le jour de la souscription. Pour cela, nous allons simplement ajouter une clef référentielle dans POLICY vers la valeur actuelle de POLICY_COVERAGE (voir figure ci-dessous).
En faisant cela, la dimension POLICY_COVERAGE devient une dimension déportée, en plus d’être une mini-dimension.
Lecture Mini-dimension : Star Schema. Christopher Adamson. pages 123-126
Lecture Mini-dimension : Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema Laurence Corr, and Jim Stagnitto. pages 166