Le 14 septembre 2017, nous avons publié une version actualisée de notre Politique de confidentialité. En utilisant video2brain.com vous vous engagez à respecter ces documents mis à jour. Veuillez donc prendre quelques minutes pour les consulter.

Les fondements de l'informatique décisionnelle

Comprendre la notion de cube

TESTEZ LINKEDIN LEARNING GRATUITEMENT ET SANS ENGAGEMENT

Tester maintenant Afficher tous les abonnements
Abordez la notion de cubes et d'hypercubes pour une visualisation multidimensionnelle des données. Cette visualisation est basée sur des mesures et des dimensions.
06:38

Transcription

Nous avons déjà parlé de la notion de cube, de mesure et de dimension. Je vais revenir ici plus en détails sur ces concepts et sur la façon dont on les implémente. D'abord le cube : c'est une vision multidimensionnelle des données qui comporte des mesures analysées selon des axes qu'on appelle les dimensions. En général, les mesures sont des données chiffrées comme le montant des ventes, le nombre de produits, etc. Il est très rare que l'utilisateur voit les mesures à la granularité à laquelle elles sont stockées dans le cube. Lorsque vous voulez les afficher dans un rapport, ou que l'utilisateur créé un tableau croisé dynamique, par le fait même de l'analyse dimensionnelle, il verra les données agrégées. Par exemple le montant des ventes par mois et par semaine et par magasin. Le cube prend sa source dans un data mart qui est en général stocké dans un base de données relationnelle qui a été modélisée de façon spéciale. Cette modélisation s'appelle le schéma en étoile et on l'élargit parfois au schéma en flocon. Le schéma en étoile est simple à comprendre. On dessine une table de mesure, ou table de faits qui contient donc les données chiffrées à leur plus fine granularité par rapport aux dimensions. Par exemple, je souhaite analyser les données de vente par jour, par magasin, par client et par catégorie de produit. Je vais donc stocker dans ma table de fait une ligne pour chaque vente quotidienne d'une catégorie de produits dans un magasin pour un client. Si mes tables opérationnelles d'origine contiennent plus de détails, je peux donc agréger à cette granularité désirée plusieurs informations de vente dans ma table de fait. Mais je dois bien faire attention à rester à la granularité la plus fine demandée par chacune de mes dimensions, de façon à ne pas perdre un détail d'information qui serait nécessaire à l'analyse multi-dimensionnelle. On va voir bientôt qu'un outil qui va nous aider à faire cela est le Bus matrix. Dans ma table de faits, je vais lier les dimensions à l'aide de clés. J'aurai par exemple, pour chaque ligne de ma table de faits, l'information du jour de vente, l'identifiant du magasin, le numéro du client, le code de catégorie de produit. Cela me permettra de lier chaque ligne à toutes les dimensions par ses clés. Je place donc ma table de faits au centre, je dispose des tables de dimensions tout autour et chaque table de dimension comporte une clé primaire unique, qui est bien sûr la clé que j'ai indiqué dans la table de faits. C'est donc à cause de cette vision qu'on appelle ce modèle le schéma en étoile. Chaque table de dimension comporte des attributs. Par exemple, la table de clients indique son nom, si souhaité, sa tranche d'âge, sa région d'habitation, son sexe : toutes les informations que le business a jugé utile d'ajouter comme axe d'analyse. Dans la vision du cube, ce sont les attributs de la dimension. Les valeurs des attributs sont nommées des membres. Par exemple, les membres de l'attribut tranche d'âge peuvent être de 11 à 20 ans, de 21 à 30 ans, de 31 à 40 ans, etc. Dans une table de dimensions, chaque valeur distincte est un nombre de la dimension. Dans beaucoup de dimensions, il est logique de créer des hiérarchies. L'utilisateur du cube pourra alors descendre plus finement dans la hiérarchie pour analyser les données. La dimension de temps est en général représentée dans une hiérarchie, et on va pouvoir par exemple voir la somme des ventes de l'année et puis descendre ensuite par trimestre, par mois, par semaine, etc. On appelle cette opération le forage, ou drill down. Les outils de création de cube vous permettent facilement de définir une hiérarchie entre les attributs d'une dimension. Le modèle en étoile implique seulement deux niveaux, on l'a vu : une table de faits centrale et un niveau de dimensions tout autour. Dans les tables de dimensions, on est obligé de dupliquer des données qui auraient été normalisées dans plusieurs tables dans un modèle OLTP. Par exemple, dans la dimension des clients et dans l'attribut tranche d'âge, on aura de multiples fois la valeur de 21 à 30 ans. En modélisation relationnelle, on appelle ça une dénormalisation : on duplique volontairement les données de façon à simplifier le modèle et à ne pas créer de table de référence. Mais vous pouvez également opter pour une approche hybride qu'on appelle le schéma en flocon. Comme dans un flocon de neige, on peut avoir plusieurs niveaux de dimensions qui se référencent l'une l'autre. Par exemple, si dans ma table de faits, j'ai indiqué un code de produit, je vais le lier à un premier niveau qui est la dimension des produits. Et je peux ensuite créer une table de catégories de produits à laquelle je vais lier la dimension des produits, et ça fait deux références : les ventes référencent les produits et les produits référencent les catégories. C'est un choix de modélisation, mais si votre cube n'est pas trop compliqué, il est préférable de conserver un schéma en étoile plus simple à gérer et à maintenir. La nature des clés est aussi importante. Dans le système opérationnel, les tables ont déjà des clés. Par exemple un numéro de client ou un code de catégorie. En général on n'utilise pas ces clés dans notre schéma en étoile ou en flocon pour lier les faits et dimensions, et cela pour deux raisons. Les clés du data warehouse doivent rester stables. Afin de ne pas subir d'éventuels changements des clés présentes dans les systèmes sources, il est préférable de créer ses propres clés techniques qu'on appelle surrogate key. Surrogate signifie en anglais substitut. Il s'agit donc d'une clé de remplacement, ou d'une clé artificielle qu'on va utiliser comme clé primaire pour notre dimension. On la suffixe en général par SK au lieu de ID, pour indiquer qu'il s'agit d'une surrogate key. On va choisir une clé auto-incrémentée, générée par le système et qui ne sera visible que dans notre modèle de data warehouse. Ainsi dans chaque dimension, on va avoir la clé source de la base opérationnelle donc l'ID, et notre propre clé technique, donc la SK, qui sera elle la clé primaire de la table de dimension et qui fera le lien avec la table de faits. Je vous le disais, il y a aussi une deuxième raison, et cela a un lien avec l'évolution historique des valeurs dans la dimension. Je vais revenir plus tard sur ce point quand je vais parler des dimensions à évolution lente.

Les fondements de l'informatique décisionnelle

Abordez les principes fondamentaux de l’informatique décisionnelle. Explorez la gestion des données et leur traitement, les méthodologies et les technologies utilisées, etc.

1h05 (16 vidéos)
Aucun commentaire n´est disponible actuellement
 
Spécial abonnés
Date de parution :29 sept. 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !