Réaliser son premier système décisionnel

Introduction

Lors de ce chapitre, nous utiliserons les outils SQL Server pour réaliser la première brique de notre système décisionnel.

Nous commencerons par mettre en œuvre le système d’analyse des factures qui permettra à la société Distrisys, d’analyser son chiffre d’affaires (CA), ses marges et ses coûts.

Dans une entreprise commerciale, commencer par mettre en œuvre l’analyse des factures est généralement un bon choix, pour deux raisons :

Les données de facturation seront analysables par les utilisateurs suivant quatre axes principaux :

Lors de ce chapitre...

Création des tables de faits et de dimension

2. Création d’une table de faits

D’abord quelques explications sur la construction d’une table de faits. Chaque table de faits sera construite en trois blocs.

Le premier bloc détaille les liaisons avec les tables de dimension :

Les quatre axes pour analyser les factures sont les suivants :

• DateFacturation_FK permettra d’identifier la date de facturation et fera la liaison avec la dimension Temps.

• Site_FK permettra d’identifier le site de facturation et fera la liaison avec la dimension Site.

• Produit_FK permettra d’identifier le produit facturé et fera la liaison avec la dimension Produit.

• Client_FK permettra d’identifier le client facturé et fera la liaison avec la dimension Client.

Ces champs définissent la granularité de notre table de faits.

Dans notre cas, la granularité de la table de faits FactFacture correspond à une ligne : par jour (date de facturation), par site de facturation...

La dimension temps

Dans un système décisionnel, la dimension Temps revêt une importance particulière et doit faire l’objet de la plus grande attention. La table Temps est unique et sa présence est obligatoire dans toute table de faits, quelle qu’elle soit. La présence de la dimension Temps dans une table de faits est une des caractéristiques d’un système décisionnel par rapport à un système transactionnel.

La table de dimension Temps a une granularité au jour.

Le premier réflexe est de construire une table de dimension Temps assez simple, comme ci-dessous :

L’expérience vous apprendra qu’une table de dimension bien construite permettra d’anticiper bon nombre de complications ultérieures.

Au cours des pages suivantes, nous allons créer la table Temps, saisir son contenu, puis la peaufiner pour qu’elle corresponde à nos attentes. Néanmoins, la table DimTemps finale est disponible en téléchargement au format csv sur l’espace de téléchargement du livre.

L’intérêt de la procédure qui suit est de vous permettre de vous constituer votre propre DimTemps qui reflétera les spécificités de votre organisation.

Pour commencer, nous allons nous servir d’un assistant de projet SSAS, afin de générer une première version de la table DimTemps. La création de la table de dimension Temps va nous permettre d’avoir un premier contact avec l’outil de création de cubes de Microsoft :...

Création des étoiles

Dans les sections précédentes, nous avons créé une table de faits et les tables de dimensions associées. Au cours de cette section , nous allons achever la modélisation de notre entrepôt de données en assemblant ces tables en étoile.

Pourquoi en étoile ? Tout simplement parce que la table de faits est au centre d’un réseau de tables de dimension, le tout faisant penser à une étoile.

Représentation schématique d’une étoile

Vous entendrez aussi parler de schéma en flocon, tout simplement parce que les tables de dimension peuvent être liées à d’autres dimensions, le schéma global faisant penser alors à un flocon de neige.

Représentation schématique d’un flocon

La manière de nommer ces schémas étoile ou flocon n’a que peu d’importance. Il est surtout important de noter que les liaisons du centre vers l’extérieur se matérialisent uniquement par des relations de clé étrangère à clé primaire. De ce fait, dans une modélisation correcte :

Génération du jeu de test

Dans la section précédente, nous avons achevé la modélisation de notre entrepôt de données. Néanmoins, pour tester et appréhender le modèle, il nous faut des données concrètes.

Lors de la phase de conception, même si nous vous engageons à vérifier la disponibilité des informations sources, nous vous incitons vivement à ne pas chercher à travailler avec les données réelles mais avec un jeu de test. Et ce, jusqu’à une validation de la modélisation.

Nous allons voir dans cette section comment générer et travailler avec un jeu de test. Cette phase peut sembler lointaine des préoccupations du concepteur, elle reste cependant capitale pour la validation et la réussite de cette phase de modélisation. En effet, lors des phases de conception, il est important de faire des itérations très rapides avec les utilisateurs métier, et surtout d’être capable de leur faire voir et leur faire manipuler le fruit des décisions des dernières délibérations.

À l’issue de cette section, c’est-à-dire après la création du cube, dans notre étude de cas Distrisys, nous devrions réaliser une démonstration et un atelier. Cela permettra aux utilisateurs qui ont participé à sa conception de manipuler le modèle, ce afin de le leur faire valider. L’objectif étant qu’une fois le modèle validé à l’aide de données de test, nous le mettrons de côté. Nous pourrons alors nous intéresser exclusivement au chargement des données réelles : une phase qui peut se révéler très longue.

C’est justement parce que le chargement des données réelles est souvent long et fastidieux, qu’il faut :

Revenons à notre étude de cas....

Créer et utiliser simplement un cube brut

Dans les sections précédentes, nous avons construit l’entrepôt de données sous SQL Server, puis nous avons chargé un jeu de test cohérent.

À présent, nous allons nous atteler à restituer l’information contenue dans l’entrepôt de données de manière simple, présentable et rapide.

Simple et présentable : cela signifie que l’utilisateur qui accède à l’information ne doit pas voir la complexité du traitement de l’information. Le fait que l’information provienne de multiples sources doit être totalement transparent. Le fait que la restitution de l’information suggère de nombreuses règles de gestion métier doit lui aussi être transparent. Un modèle réussi est un modèle que l’on peut donner à l’utilisateur sans avoir crainte qu’il ne se trompe, qu’il interprète mal les résultats ou qu’il se perde dans l’étendue de l’information.

Rapide signifie qu’un utilisateur, qui accède à des informations mises à disposition, doit avoir un temps d’attente de l’ordre de la seconde. Attendre 10 secondes peut déjà être considéré comme long.

La modélisation que nous venons de mettre en œuvre dans les sections précédentes en est l’illustration. La bonne modélisation est la clé de l’utilisation optimale d’Analysis Services.

Nous allons voir ici qu’un entrepôt de données bien modélisé, c’est 80 % du travail accompli. Les 20 % restants relèvent de la finition.

Peaufiner le cube

1. Dimensions : hiérarchies et attributs

Nous avons créé dans la section précédente un cube basé sur l’entrepôt de données DistrisysDW. La création et la génération du cube a été rapide. Mais il est apparu clairement que quelques finitions étaient nécessaires pour le rendre accessible aux utilisateurs. Une des finitions les plus évidentes est la nécessité de retravailler les dimensions.

Dans notre travail de finition, pour chaque dimension, nous allons devoir identifier les attributs à afficher et, quand c’est possible, chercher à les organiser en hiérarchie.

Voyons un peu comment procéder. Dans le premier onglet cube du projet Analysis Services, identifiez la zone de gestion des dimensions, en bas à gauche. Dépliez la dimension Temps et cliquez sur Modifier Temps :

Un nouvel onglet spécifique à la gestion de la dimension Temps s’ouvre. Vous pouvez revenir si nécessaire à la gestion générale du cube en cliquant sur l’onglet Distrisys.cube [Conception] :

La zone Attributs, la plus à gauche, vous permet de visualiser la liste des attributs de la dimension Temps.

Vous noterez que le seul attribut disponible est, par défaut, la clé technique.

La zone Hiérarchie centrale vous permettra de construire les hiérarchies.

La zone Vue de source de données, la plus à droite, vous permet de visualiser les tables concernées par la dimension.

Pour commencer, nous allons modifier l’attribut de clé Temps PK, afin que ce soit un attribut qui affiche le jour de l’année à l’utilisateur, plutôt qu’une clé technique.

 Affichez les Propriétés de Temps PK :

La barre de propriétés de l’attribut Temps PK s’affiche :

 Sélectionnez la propriété NameColumn et cliquez sur .

 Sélectionnez le champ Jour de la table DimTemps :

Vous devriez avoir :

 Renommez l’attribut Temps_PK en Jour :

Nous venons de créer l’attribut Jour. Cet attribut est l’attribut de clé, car il s’agit de l’attribut le plus fin de la dimension. Cet attribut a pour clé Temps_PK, mais l’affichage...

Sécuriser l’accès au cube

Le cube est maintenant finalisé ! Enfin presque… Car il nous faut penser maintenant à la mise à disposition des données aux utilisateurs et donc à la mise en place de la sécurité qui sera associée à cette nouvelle base de données.

Il est pertinent de penser à la sécurisation du cube DataWarehouse avant de commencer le développement des flux ETL, car notre expérience nous a prouvé à plusieurs reprises que la sécurité pouvait avoir une incidence non négligeable sur sa modélisation. Dans certains cas, l’impact était simplement la mise à disposition de nouvelles dimensions (fonctionnelles ou purement techniques), mais dans d’autres cas, il nous a fallu dupliquer des groupes de mesures en supprimant ou en ajoutant des liaisons avec certaines dimensions. Réfléchir à la mise en place de la sécurité apporte toujours un point de vue intéressant et neuf sur la modélisation finalisée que vous envisagez de mettre en place. C’est donc un excellent moyen de l’éprouver.

C’est pourquoi nous vous proposons dans cette section de découvrir les principes de restriction des accès dans Analysis Services.

Le cube et la matrice dimensionnelle

Nous venons d’achever la construction de notre cube reposant sur un entrepôt de données.

Pour finir le chapitre et préparer le suivant, nous allons découvrir le concept de matrice dimensionnelle.

La matrice qui est proposée est le véritable cœur du cube. Nous appellerons cette représentation matrice dimensionnelle.

La matrice dimensionnelle est la manière la plus efficace de modéliser et de représenter un entrepôt de données. Dans la matrice, les lignes sont les dimensions et les colonnes les tables de faits. L’intersection d’une dimension avec la table de faits spécifie si les mesures de la table de faits sont analysables par cette dimension.

La matrice dimensionnelle de l’entrepôt de données définie dans ce chapitre peut être représentée de la façon suivante :

Dans ce tableau, les croix (x) indiquent que les mesures de la table de faits Facture sont analysables par les attributs des dimensions Temps, Produit, Site et Client.

Une autre représentation possible de la matrice dimensionnelle, plus complète, est de représenter les intersections (remplaçant ainsi les croix) par le grain définissant l’intersection. Dans notre cas, la représentation...