> Data > Les bases de la modélisation dimentionelle

Les bases de la modélisation dimentionelle

Data - Par Joy Mundy et Warren Thornthwaite - Publié le 24 juin 2010
email

SQL Server 2005 Analysis Services utilise des dimensions à base d’attributs, de telle sorte que chaque attribut d’une dimension est traité automatiquement en tant que hiérarchie autonome. Désormais, vous pouvez employer la couche des métadonnées qui définit les cubes Analysis Services (le modèle dimensionnel unifié ou UDM) afin de spécifier une dimension client au lieu d’une demi-douzaine de dimensions séparées artificiellement. Un avantage de cette prise en charge plus poussée de l’approche dimensionnelle est que les développeurs de systèmes de data warehouse et d’analyse décisionnelle (BI) n’ont plus besoin de convertir des techniques de modélisation dimensionnelle standard à la vision limitée des anciennes versions de SQL Server. Désormais, vous pouvez construire des dimensions qui représentent de manière réaliste le mode de fonctionnement de votre activité et sont capables d’évoluer en phase avec celle-ci. L’objet de cet article est de définir les modèles dimensionnels, de décrire les éléments de base et les techniques qui les prennent en charge, et de proposer une architecture de données de type dimensionnel pour votre système de data warehouse et d’analyse décisionnelle.

Les bases de la modélisation dimentionelle

Que recouvre le concept de modélisation décisionnelle ? A la base, un modèle dimensionnel contient deux types d’entrées : les faits et les dimensions. Nous conservons les mesures d’un processus métier donné au sein d’entités appelées tables de faits dans le jargon relationnel, ou groupes de mesures dans Analysis Services. Dans sa forme classique, une table de faits relationnelle contient des clés étrangères et des champs de faits numériques qui mesurent le processus métier. Globalement, une table de faits est une structure normalisée servant au stockage efficace et à l’accès rapide d’ensembles de données relationnelles volumineux.

Par exemple, de nombreuses entreprises ont un processus métier intitulé Orders (commandes), chargé du suivi des demandes des clients concernant les produits et les marchandises. La figure 1 illustre un modèle de table de faits OrderLineItems simplifié, reposant sur la base de données exemple AdventureWorks Cycles dans SQL Server 2005. Les trois champs numériques non définis en tant que clé dans la table de faits correspondent aux quantités, aux valeurs exprimées en dollars et aux coûts d’expédition des produits commandés : autrement dit, ils représentent les mesures du processus métier Orders. Les clés étrangères dans la table de faits OrderLineItems sont liées au deuxième type d’entité dimensionnelle, à savoir les tables de dimensions, qui seront abordées un peu plus loin.

Le niveau de détail de la table de faits est appelé sa granularité. Celle de la table de faits OrderLineItems illustrée à la figure 1 se situe au niveau article de ligne de commande. Plus la granularité est fine, ou plus le niveau de détail est bas, plus la flexibilité de votre modèle sera grande. Vous pouvez toujours remonter vers un niveau de données moins détaillé, mais il est impossible d’effectuer une exploration vers des niveaux détaillés si votre base de données initiale est dépourvue des détails en question. Notre équipe conçoit les tables de faits au niveau le plus détaillé possible, à savoir le niveau atomique. En fonction des volumes de données de votre entreprise et des besoins de performances de vos utilisateurs, vous ne pourrez peut-être pas proposer cette granularité au niveau atomique, mais prenez le temps d’expliquer aux utilisateurs ce qu’ils perdent en termes de flexibilité.

Téléchargez gratuitement cette ressource

Guide de Cloud Privé : Enjeux & Perspectives

Guide de Cloud Privé : Enjeux & Perspectives

Dans ce nouveau Livre Blanc Blue + VMware, découvrez les 5 prérequis indispensables à la mise en œuvre d'une solution de Cloud Privé, agile, évolutive, garantissant la sécurité de vos infrastructures et de vos données.

Data - Par Joy Mundy et Warren Thornthwaite - Publié le 24 juin 2010