Blog ENI : Toute la veille numérique !
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée
En raison d'une opération de maintenance, le site Editions ENI sera inaccessible le mardi 10 décembre, en début de journée. Nous vous invitons à anticiper vos achats. Nous nous excusons pour la gêne occasionnée
  1. Livres et vidéos
  2. Modélisation décisionnelle
  3. Concevoir le modèle
Extrait - Modélisation décisionnelle Concevoir la base de données pour les traitements OLAP
Extraits du livre
Modélisation décisionnelle Concevoir la base de données pour les traitements OLAP Revenir à la page d'achat du livre

Concevoir le modèle

Identifier les étoiles

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 :

images/5-6.png

Exemple

L’analyse est sous...

Formaliser une dimension

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

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

  • Dimension de faits : l’axe d’analyse sur lequel est ventilée une mesure.

  • Dimension référentielle ou objet : hiérarchie descriptive d’un objet.

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].

images/5-45.png

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 :

  • Rendre explicite le modèle : identifier tout de suite le caractère analytique d’une dimension.

Exemple

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

  • Permettre de référencer plusieurs fois la même dimension référentielle dans une étoile.

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]...

Formaliser les indicateurs

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 :

  • Mesure

  • Métrique

  • Indicateur

  • KPI

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 :

  • Indicateurs bruts ou mesurés : les valeurs brutes reçues des systèmes sources.

  • Indicateurs calculés simples : les indicateurs simples et extensifs calculés ligne à ligne.

  • Indicateurs calculés complexes : les indicateurs calculés sur plusieurs lignes ou intensifs.

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 :

images/5-97.png

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.

images/5-89.png

Nous avons donc :

  • Indicateur brut : [PRIX] que l’on pourra renommer [CHIFFRE D’AFFAIRES]

  • Exemples d’indicateurs calculés simples :

    • [CHIFFRE D’AFFAIRES HORS TAXE] = [PRIX] / 1,20

    • [CHIFFRE D’AFFAIRES PROMO] = Si [PROMO]=’OUI’ alors [PRIX] sinon 0

  • Exemples d’indicateurs complexes :

    • [PRIX MOYEN...

Identifier les données

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 :

  • Les dimensions en différents niveaux hiérarchiques de plusieurs hiérarchies.

  • Les tables de faits en indicateurs de base.

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 :

images/5-55.png

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

  • Dimensions :

    • [Date naissance]

    • [Client]

    • [Lieu de résidence]

    • [Produit]

    • [Date achat]

    • [Lieu achat]

    • [Magasin]

    • [Lieu magasin]

    • [Date analyse]

    • [Employé]

  • Faits :

    • [Fidélité clients]

    • [Ventes]

    • [Activité magasin]

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

  • [Temps] : [Date naissance], [Date achat], [Date analyse]

  • [Zone géographique] : [Lieu résidence], [Lieu achat], [Lieu magasin]

L’unification de [Clients]...

Formaliser la table de faits

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 :

  • Les axes d’analyse, correspondant aux niveaux fins des dimensions.

  • Les mesures.

  • Les attributs.

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 :

  • Colonnes de dimensions à gauche (la dimension temps en premier).

  • Colonnes de mesures à droite.

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

Formaliser la table d’agrégats

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 :

  • Filtres sur les dimensions

  • Filtres sur les mesures

  • Agrégats sur les dimensions

  • Agrégats sur les faits

  • Suppression d’une dimension

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...

Nommer les objets

La mise en place d’un système décisionnel doit permettre de redonner une vision métier à la donnée, plutôt que technique.

Dans ce but, les objets spécifiques au décisionnel modélisés dans la base de données relationnelle - tables de référentiels, de dimensions, de faits et d’agrégats - doivent se détacher de leurs noms d’origine afin d’avoir des noms fonctionnels explicitant leur rôle. Il est également conseillé de nommer les objets dans le langage qui correspond à celui utilisé par les utilisateurs. Il est néanmoins nécessaire de respecter les règles usuelles quant aux noms dans les applications informatiques : éviter les espaces, caractères spéciaux et noms trop longs.

Au sein de chaque table, les colonnes doivent également suivre les mêmes règles quant au nommage. Par contre, les tables de l’ODS n’étant pas une organisation par objet de la donnée, mais une organisation par application de la donnée, et de plus, se voulant la réplication des bases de données sources, il est préférable de conserver les noms de tables et champs tels qu’ils sont reçus.

Il est d’usage d’avoir recours à des préfixes pour identifier le type d’objet décisionnel...

Schéma synthétique des flux et types d’objets

1. Entrepôt en flocon et magasins en étoile

La spécificité de cette modélisation est que les dimensions sont éclatées au sein de l’entrepôt de données en tables de référentiels, qui chacune, représente un niveau hiérarchique d’une dimension.

images/5-117.png

2. Entrepôt en étoile et magasins en étoile

Cette modélisation diffère de la précédente car la modélisation en étoile est de rigueur à la fois dans l’entrepôt de données et dans les magasins de données. Ainsi, les dimensions sont aplaties dès l’entrepôt. Ces tables de dimensions servent à la fois aux données de l’entrepôt et celles des magasins de données.

images/5-118.png

3. Entrepôt en flocon et magasins en flocon

De la même manière que le modèle précédent, le type de modèle étant le même entre l’entrepôt et les magasins de données, ces deux bases partagent les mêmes tables pour la partie référentielle. La dimension est dans tous les cas atomisée. C’est la couche multidimensionnelle qui viendra réunir ces tables au sein d’un seul et unique objet dimension.

images/5-119.png