Conseil 11: Compter correctement dans une dimension

Les tables de dimension qui possèdent de nombreux attributs descriptifs deviennent souvent la cible de requêtes directes indépendantes de toute table de faits. Par exemple, nous faisons quotidiennement différents calculs sur notre dimension Client pour répondre à des questions telles que le nombre de clients par type de paiement, par région, ou par sexe, etc. Ces calculs sur une dimension statique sont faciles, mais cela devient plus intéressant lorsque nous essayons d’effectuer ces calculs sur une dimension à évolution lente.

Calculs sur une dimension à évolution lente

Le problème est de s'assurer que nos calculs soient corrects. Dans la dimension (à évolution lente) Client, nous pouvons avoir plusieurs lignes par client, donc une requête simple qui compte le nombre de clients par statut finira par compter plusieurs fois les clients qui ont subit une modification (ceux qui ont plus d'un enregistrement). On pourrait utiliser un COUNT DISTINCT sur la clé client de la source si elle est disponible. Le problème, est que si l'attribut sur lequel vous faites votre calcul a changé, comme le passage d'un statut à un autre, vous compterez plusieurs fois le même client parce que sa clé sera unique par statut.

Nous devons donc trouver un moyen de limiter la dimension à une ligne par client. Cela peut se faire en utilisant, dans la dimension, un flag "Enregistrement_Actuel" qui marque l’enregistrement le plus récent de chaque client. Cette approche nous donnera le total pour le statut le plus récent de nos clients. Vous pouvez également créer une vue, une requête ou une table pré-calculée récupérant les enregistrements des clients actuels pour nous aider à réaliser notre calcul.

Calculs à travers le temps

Les calculs à date sont toujours utiles, mais la véritable astuce est d'obtenir le résultat à une date particulière dans le temps. Comprendre comment le résultat change au fil du temps est l'un des principaux objectifs de l'entrepôt de données. Savoir, par exemple, que nous avons actuellement 2 311 clients c’est bien, mais être en mesure de comparer ce chiffre avec le nombre de client de l’année précédente, c'est encore mieux. Vous devez utiliser une dimension à évolution lente pour obtenir ce genre de résultat. Par exemple, si vous avez besoin de savoir le nombre de clients que vous avez à la fin de l’année 1999, vous pouvez filtrer la Date_Début <= '12/31/1999’ AND Date_Fin > = '12/31/1999'. Cela limite l'ensemble aux lignes qui étaient "actives" le 31/12/1999. (Le choix des opérateurs de comparaison dépend de la façon dont vous définissez vos dates de début et de fin.) Nous avons supposé dans cet exemple que lorsqu'un enregistrement de la dimension Client est modifié, la Date_Fin du premier enregistrement est un jour avant la Date_Début du second enregistrement, et que plusieurs changements dans une même journée ne sont pas autorisés.

Si vous voulez quelque chose de plus sympa que filtrer directement les champs Date de la dimension Client, vous pouvez utiliser toute la puissance de la dimension Période pour fournir la date sélectionnée, ou même plusieurs dates cibles. Pour ce faire, vous utilisez les mêmes opérateurs de comparaison pour créer deux jointures entre le champ Date de votre dimension Période et les date de début et de fin de la dimension Client, puis vous filtrez le champ Date de la table Période afin qu’elle soit égale à la date choisie. Vous pouvez alors inclure le champ Date dans la clause SELECT pour voir le jour auquel le total s'applique.

Pour avoir un total sur plusieurs dates dans la même requête, comme le dernier jour du mois, supprimer la sélection sur le champ Date de la table Période et ajouter un filtre sur le champs Flag_DernierJourDuMois = 'Y'. La requête SQL ressemble à quelque chose comme ceci:

SELECT Periode.Date, Client.Statut, COUNT(Client.Client_Clé)

FROM Client, Periode

WHERE Client.Date_Debut <= Periode.Date

AND Client.Date_Fin>= Periode.Date

AND Periode.Flag_DernierJourDuMois= 'y'

Notez que ce type de jointure entre la dimension Période et la dimension Client peut poser un véritable défi pour le moteur d'une base de données contenant de grandes dimensions. Dans notre cas, nous avons un index bitmap sur les deux champs Date, et nous obtenons de bonnes performances.

De toute évidence, ce type de requête n’est pas facile à construire, et nous vous encourageons à informer vos utilisateurs de la gymnastique qu'implique les requêtes de cette nature. En fait, si les besoins de calcul pour certains attributs sont courants, il peut être judicieux de créer une table de faits agrégée qui comprend le résultat quotidien de chaque combinaison d'attributs. Ainsi nous sommes revenus à un simple modèle dimensionnel où chaque attribut est une dimension, et la table de faits a au moins un champ qui est le nombre de clients quotidien par combinaison d'attributs.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #11: Accurate counts within a dimension", publié le 6 août 2000.