Concevoir le modèle

1. L’importance des étoiles

Clés de voûte du système décisionnel, les étoiles (ou flocons) peuvent être considérées comme le point de départ de la conception. D’une part découlera l’intégration des données nécessaires à l’alimentation de l’entrepôt de données (trouver les données sources, déterminer la granularité et la période de rétention) et d’autre part, découlera la modélisation des cubes à partir du modèle dans la base de données.

Ici, on s’attache à identifier aussi bien les étoiles de l’entrepôt que celles du magasin de données. Bien sûr, la conception des étoiles du datawarehouse et celle des étoiles des datamarts ont de fortes dépendances, mais comme expliqué dans la partie précédente, le point de départ pourra se situer au niveau magasin de données, ou inversement, au niveau de l’entrepôt de données, suivant la méthode projet retenue (Bottom-Up, Middle-out ou Top-Down).

2. Structuration ascendante

Modélisant chaque besoin unitaire sous forme d’étoile, ce modèle apparaît le plus simple de prime abord. Les analyses demandées sous forme de tableau servent de point de départ.

Le cas le plus simple est un tableau avec plusieurs mesures ventilées selon un axe d’analyse. Le tableau d’analyse est de la forme suivante :

Exemple

L’analyse est sous...

1. Dimension référentielle et dimension de faits

Derrière le terme "dimension", on peut distinguer deux éléments :

Exemple de distinction

La dimension [ZONE GÉOGRAPHIQUE] est une "dimension référentielle" : il s’agit d’un référentiel à plusieurs niveaux, hiérarchisant les [VILLES], [RÉGIONS], [PAYS]…

Les dimensions [LOCALISATION CLIENTS] et [LOCALISATION MAGASINS] sont des dimensions de faits : elles permettent de ventiler les faits liés aux [CLIENTS] et aux [MAGASINS] sur les différentes villes.

Bien évidemment, puisque ces deux dernières dimensions se réfèrent aux mêmes [VILLES], [PAYS] et autres éléments géographiques, ces deux dimensions de faits sont alimentées sur la base d’une unique dimension : [ZONE GÉOGRAPHIQUE].

Alors que la dimension référentielle fait référence à un objet indépendant des faits (une commune, un client, un magasin existent concrètement), la dimension n’existe que par le fait (la localisation d’un achat n’existe que s’il y a un achat).

Concrètement, dans la base de données décisionnelle, il n’y a pas de table (en relationnel) ou dimension (en multidimensionnel) créée pour une dimension de faits : il s’agit simplement d’une référence à une dimension référentielle. Cependant, il convient de nommer cette référence selon son rôle fonctionnel, pour deux raisons :

Exemple

[COMMUNE DE RÉSIDENCE D’UN CLIENT] plutôt que [COMMUNES] ; [DATE DE NAISSANCE D’UN CLIENT] plutôt que [TEMPS].

Exemple

La [COMMUNE] peut décrire la [COMMUNE DE NAISSANCE D’UN CLIENT], [COMMUNE DE RÉSIDENCE D’UN CLIENT], [COMMUNE DE LOCALISATION D’UN MAGASIN]...

1. Différents termes et différents concepts

Une nouvelle fois, le décisionnel utilise de nombreux termes pour nommer un même concept. Ainsi, on retrouve les termes :

Il n’y a pour l’heure aucun glossaire officiel permettant de faire la différence entre un terme et un autre.

Il est toutefois déconseillé d’utiliser le terme de "fait" afin d’éviter les ambiguïtés avec celui de la table de faits, qui identifie un événement, c’est-à-dire à la fois un ensemble d’axes analytiques et de mesures.

Quant au terme de KPI, acronyme du terme anglais Key Performance Indicator (que l’on retrouve rarement dans son équivalent français "Indicateur clé de performance" ou "d’efficacité" derrière l’acronyme "ICP"), il s’agit en soi d’un sous-ensemble d’indicateurs qui sont considérés, par le métier, comme ceux les plus à même de suivre la performance d’une entreprise, d’un projet, et d’évaluer la tenue des objectifs.

On peut cependant distinguer trois catégories d’indicateurs :

Comme expliqué dans les parties suivantes, chaque catégorie d’indicateurs, compte tenu de ses caractéristiques, ne sera calculable et lisible qu’à certains niveaux du décisionnel :

Exemple

Pour une chaîne de distribution, les données sources sont les lignes de tickets de caisse. À chaque transaction sont associés une date, un magasin, un client, un produit, la présence ou non de promotion et un prix.

Nous avons donc :

1. Dans la base de données décisionnelle

Une fois le besoin identifié, le concepteur se retrouve avec une liste d’étoiles, voire une constellation. Ceci permet donc d’obtenir une liste exhaustive des objets nécessaires à l’alimentation de la base de données décisionnelle, indépendamment des détails techniques que sont la granularité ou l’historisation.

L’expression du besoin doit également permettre de décomposer chaque objet (dimension ou table de faits) en un ensemble de sous-objets :

Comme expliqué dans la partie précédente, il faudra réussir à identifier les concepts et les référentiels sur lesquels ils reposent, afin de réunir plusieurs dimensions factuelles au sein d’une seule et unique dimension technique.

Exemple de déconstruction d’une étoile

Le modèle en étoiles pour l’analyse de l’activité d’une chaîne de grande distribution donne :

La première décomposition du modèle donne les objets suivants :

Il convient ensuite de déterminer les "dimensions référentielles" pouvant décrire plusieurs "dimensions factuelles" :

L’unification de [Clients]...

1. La structure type d’une table de faits

Concrètement, la table de faits est une table de la base de données décisionnelle relationnelle. Cette table comporte trois types fonctionnels de colonnes :

Placées au cœur de l’étoile, toutes les mesures de la table de faits doivent pouvoir être ventilées sur l’intégralité des dimensions qui y sont rattachées. En conséquence, il ne peut y avoir deux étoiles de structures identiques (id est, avec les mêmes dimensions) et périmètres identiques qui ne puissent être fusionnés au sein d’une seule et même étoile, et donc, d’une unique table de faits. La valorisation des colonnes relatives aux dimensions doit impérativement se faire avec le niveau le plus fin de ladite dimension, et non pas avec un niveau agrégé.

Les attributs sont les colonnes qui n’ont pas de valeur analytique car ils ne servent ni à contextualiser un fait (dimension) ni à le valoriser (mesure). Il s’agit par exemple d’un numéro de facture ou de transaction. Leur présence au sein du datawarehouse est donc discutable. Le principal apport d’un tel champ est technique : il permet de faire facilement le lien entre les données du DWH et celles de l’ODS afin de recetter ou comprendre un comportement ou une anomalie. Il peut également servir à extraire des listes pour des besoins opérationnels à partir des données du datawarehouse : certes, ce type d’utilisation est censé être banni du décisionnel, mais la réalité et les exigences métier demandent parfois de transgresser les dogmes. Dans l’absolu, afin de garantir le maximum de clarté dans le modèle et économiser de l’espace disque, l’implémentation d’attributs non analytiques dans la table de faits est à éviter.

Traditionnellement, la table de faits est conçue ainsi :

Il n’y a cependant aucune contrainte technique ne permettant pas de procéder autrement...

1. Rôle et structure d’une table d’agrégats

La table d’agrégats est à un magasin de données, ce qu’est la table de faits à un entrepôt de données. Il s’agit des données de transactions, au cœur d’une étoile (ou un flocon), ventilées sur les dimensions afférentes. Si la table de faits se veut fine et exhaustive, la table d’agrégats est censée se recentrer sur un besoin fonctionnel précis modélisé par une restitution dont la table d’agrégats sera indirectement ou directement la source (respectivement en cas d’utilisation ou non d’une solution OLAP).

Idéalement, une table d’agrégats se base sur une seule table de faits, mais rien n’empêche l’union ou la jointure de plusieurs tables de faits pour constituer une table d’agrégats.

Entre la table de faits et la table d’agrégats, on trouve les opérations suivantes :

Chacune de ces méthodes est détaillée par la suite.

Structurellement, la table d’agrégats reprend les mêmes principes que la table des faits, sans attribut non analytique toutefois. Ainsi, elle se compose uniquement de colonnes de dimensions (traditionnellement à gauche, initiée par la dimension Temps) et des colonnes de mesures (à droite). Chaque ligne représente donc un agrégat d’un ou plusieurs faits suivant les choix qui sont faits et décrits par la suite.

2. Utilisation de filtres

La notion de filtre est assez simple à mettre en place et ne pose pas de problème conceptuel : il suffit d’appliquer un filtre sur les valeurs des dimensions ou des mesures afin d’exclure des valeurs.

Exemples

Reprenant l’exemple de la grande distribution, une restitution doit permettre de visualiser les ventes en France. Ainsi, entre la table de faits des ventes et la table d’agrégats associée à cette restitution, sera appliqué un filtre sur la dimension [ZONES GÉOGRAPHIQUES] sur le niveau [PAYS] = ’FRANCE’ afin de ne conserver que les faits associés...