Modélisation dimensionnelle

La modélisation dimensionnelle ( DM ) fait partie de la méthodologie Business Dimensional Lifecycle développée par Ralph Kimball qui comprend un ensemble de méthodes, de techniques et de concepts à utiliser dans la conception d'entrepôts de données . L'approche se concentre sur l'identification des processus métier clés au sein d'une entreprise et sur leur modélisation et leur mise en œuvre avant d'ajouter des processus métier supplémentaires, en tant qu'approche ascendante . Une approche alternative d' Inmon préconise une conception descendante du modèle de toutes les données d'entreprise à l'aide d'outils tels que la modélisation entité-relation (ER).

La modélisation dimensionnelle utilise toujours les concepts de faits (mesures) et de dimensions (contexte). Les faits sont généralement (mais pas toujours) des valeurs numériques qui peuvent être agrégées, et les dimensions sont des groupes de hiérarchies et de descripteurs qui définissent les faits. Par exemple, le montant des ventes est un fait ; l'horodatage, le produit, le numéro de caisse, le numéro de magasin, etc. sont des éléments de dimensions. Les modèles dimensionnels sont construits par domaine de processus métier, par exemple les ventes en magasin, l'inventaire, les réclamations, etc. Étant donné que les différents domaines de processus métier partagent certaines dimensions, mais pas toutes, l'efficacité de la conception, du fonctionnement et de la cohérence est obtenue en utilisant des dimensions conformes , c'est-à-dire en utilisant une copie de la dimension partagée entre les domaines thématiques.

La modélisation dimensionnelle n'implique pas nécessairement une base de données relationnelle. La même approche de modélisation, au niveau logique, peut être utilisée pour toute forme physique, telle qu'une base de données multidimensionnelle ou même des fichiers plats. Elle est orientée vers la compréhensibilité et la performance.

Le modèle dimensionnel est construit sur un schéma en étoile ou en flocon de neige , avec des dimensions entourant la table de faits. Pour construire le schéma, le modèle de conception suivant est utilisé :

1. Choisissez le processus métier
2. Déclarer le grain
3. Identifier les dimensions
4. Identifier le fait

Choisissez le processus métier

Le processus de modélisation dimensionnelle s'appuie sur une méthode de conception en 4 étapes qui permet de garantir la facilité d'utilisation du modèle dimensionnel et l'utilisation de l' entrepôt de données . Les bases de la conception s'appuient sur le processus métier réel que l' entrepôt de données doit couvrir. Par conséquent, la première étape du modèle consiste à décrire le processus métier sur lequel le modèle s'appuie. Il peut s'agir par exemple d'une situation de vente dans un magasin de détail. Pour décrire le processus métier, on peut choisir de le faire en texte brut ou d'utiliser le Business Process Model and Notation (BPMN) de base ou d'autres guides de conception comme le langage de modélisation unifié |UML).

Déclarer le grain

Après avoir décrit le processus métier, l’étape suivante de la conception consiste à déclarer le grain du modèle. Le grain du modèle est la description exacte de ce sur quoi le modèle dimensionnel doit se concentrer. Cela pourrait par exemple être « un article individuel sur un bordereau de client d’un magasin de détail ». Pour clarifier ce que signifie le grain, vous devez choisir le processus central et le décrire en une phrase. De plus, le grain (la phrase) est ce à partir duquel vous allez construire vos dimensions et votre table de faits. Vous pourriez trouver nécessaire de revenir à cette étape pour modifier le grain en raison de nouvelles informations obtenues sur ce que votre modèle est censé être capable de fournir.

Identifier les dimensions

La troisième étape du processus de conception consiste à définir les dimensions du modèle. Les dimensions doivent être définies dans le grain de la deuxième étape du processus en 4 étapes. Les dimensions sont la base de la table de faits et c'est là que les données de la table de faits sont collectées. En général, les dimensions sont des noms tels que date, magasin, inventaire, etc. Ces dimensions sont l'endroit où toutes les données sont stockées. Par exemple, la dimension de date peut contenir des données telles que l'année, le mois et le jour de la semaine.

Identifier les faits

Après avoir défini les dimensions, l'étape suivante du processus consiste à créer des clés pour la table de faits. Cette étape consiste à identifier les faits numériques qui rempliront chaque ligne de la table de faits. Cette étape est étroitement liée aux utilisateurs professionnels du système, car c'est là qu'ils ont accès aux données stockées dans l' entrepôt de données . Par conséquent, la plupart des lignes de la table de faits sont des chiffres numériques additifs tels que la quantité ou le coût par unité, etc.

La normalisation dimensionnelle ou la mise en flocons supprime les attributs redondants, qui sont connus dans les dimensions normales aplaties et dénormalisées. Les dimensions sont strictement jointes entre elles dans des sous-dimensions.

Le flocon de neige a une influence sur la structure des données qui diffère de nombreuses philosophies des entrepôts de données. Une seule table de données (faits) entourée de plusieurs tables descriptives (dimensions)

Les développeurs ne normalisent souvent pas les dimensions pour plusieurs raisons :

1. La normalisation rend la structure des données plus complexe
2. Les performances peuvent être plus lentes en raison des nombreuses jointures entre les tables
3. Les économies d'espace sont minimes
4. Les index bitmap ne peuvent pas être utilisés
5. Performances des requêtes. Les bases de données 3NF souffrent de problèmes de performances lors de l'agrégation ou de la récupération de nombreuses valeurs dimensionnelles qui peuvent nécessiter une analyse. Si vous ne faites que des rapports opérationnels, vous pourrez peut-être vous en sortir avec 3NF, car votre utilisateur opérationnel recherchera des données très fines.

Il existe plusieurs arguments pour expliquer pourquoi la normalisation peut être utile. Elle peut être avantageuse lorsqu'une partie de la hiérarchie est commune à plusieurs dimensions. Par exemple, une dimension géographique peut être réutilisable car les dimensions client et fournisseur l'utilisent toutes les deux.

Les avantages du modèle dimensionnel sont les suivants :

• Compréhensibilité. Comparé au modèle normalisé, le modèle dimensionnel est plus facile à comprendre et plus intuitif. Dans les modèles dimensionnels, les informations sont regroupées en catégories ou dimensions métier cohérentes, ce qui facilite la lecture et l'interprétation. La simplicité permet également aux logiciels de naviguer efficacement dans les bases de données. Dans les modèles normalisés, les données sont divisées en plusieurs entités discrètes et même un processus métier simple peut donner lieu à des dizaines de tables jointes de manière complexe.
• Performances des requêtes. Les modèles dimensionnels sont plus dénormalisés et optimisés pour l'interrogation des données, tandis que les modèles normalisés cherchent à éliminer les redondances de données et sont optimisés pour le chargement et la mise à jour des transactions. Le cadre prévisible d'un modèle dimensionnel permet à la base de données de formuler des hypothèses solides sur les données, ce qui peut avoir un impact positif sur les performances. Chaque dimension est un point d'entrée équivalent dans la table de faits, et cette structure symétrique permet une gestion efficace des requêtes complexes. L'optimisation des requêtes pour les bases de données jointes en étoile est simple, prévisible et contrôlable.
• Extensibilité. Les modèles dimensionnels sont évolutifs et s'adaptent facilement à de nouvelles données inattendues. Les tables existantes peuvent être modifiées en place, soit en ajoutant simplement de nouvelles lignes de données dans la table, soit en exécutant des commandes SQL alter table. Aucune requête ou application qui repose sur l'entrepôt de données n'a besoin d'être reprogrammée pour s'adapter aux modifications. Les anciennes requêtes et applications continuent de s'exécuter sans produire de résultats différents. Mais dans les modèles normalisés, chaque modification doit être considérée avec soin, en raison des dépendances complexes entre les tables de base de données.

Nous bénéficions toujours des avantages des modèles dimensionnels sur Hadoop et d'autres frameworks de Big Data similaires . Cependant, certaines fonctionnalités de Hadoop nous obligent à adapter légèrement l'approche standard de la modélisation dimensionnelle.

• Le système de fichiers Hadoop est immuable . Nous pouvons uniquement ajouter des données, mais pas les mettre à jour. Par conséquent, nous ne pouvons qu'ajouter des enregistrements aux tables de dimension. Les dimensions à évolution lente sur Hadoop deviennent le comportement par défaut. Afin d'obtenir l'enregistrement le plus récent et le plus à jour dans une table de dimension, nous avons trois options. Tout d'abord, nous pouvons créer une vue qui récupère le dernier enregistrement à l'aide de fonctions de fenêtrage . Deuxièmement, nous pouvons avoir un service de compactage exécuté en arrière-plan qui recrée l'état le plus récent. Troisièmement, nous pouvons stocker nos tables de dimension dans un stockage mutable, par exemple HBase et fédérer les requêtes sur les deux types de stockage.
• La façon dont les données sont distribuées sur HDFS rend la jointure des données coûteuse. Dans une base de données relationnelle distribuée ( MPP ), nous pouvons colocaliser des enregistrements avec les mêmes clés primaires et étrangères sur le même nœud d'un cluster. Cela rend relativement peu coûteuse la jointure de très grandes tables. Aucune donnée n'a besoin de traverser le réseau pour effectuer la jointure. C'est très différent sur Hadoop et HDFS. Sur HDFS, les tables sont divisées en gros morceaux et distribuées sur les nœuds de notre cluster. Nous n'avons aucun contrôle sur la façon dont les enregistrements individuels et leurs clés sont répartis sur le cluster. Par conséquent, les jointures sur Hadoop pour deux très grandes tables sont assez coûteuses car les données doivent circuler sur le réseau. Nous devons éviter les jointures autant que possible. Pour une grande table de faits et de dimensions, nous pouvons dénormaliser la table de dimensions directement dans la table de faits. Pour deux très grandes tables de transactions, nous pouvons imbriquer les enregistrements de la table enfant dans la table parent et aplatir les données au moment de l'exécution.

• Kimball, Ralph ; Margy Ross (2013). La boîte à outils de l'entrepôt de données : le guide définitif de la modélisation dimensionnelle (3e éd.). Wiley. ISBN 978-1-118-53080-1.
• Ralph Kimball (1997). "Un manifeste de modélisation dimensionnelle". SGBD et systèmes Internet . 10 (9).
• Margy Ross (Kimball Group) (2005). « Identification des processus métier ». Kimball Group, Conseils de conception (69). Archivé de l'original le 12 juin 2013.