Modélisation dimensionnelle dans Microsoft Fabric Warehouse

S’applique à :✅ point de terminaison d’analytique SQL et entrepôt dans Microsoft Fabric

Cet article est le premier d’une série sur la modélisation dimensionnelle à l’intérieur d’un entrepôt. Il fournit des conseils pratiques pour Warehouse dans Microsoft Fabric, qui est une expérience qui prend en charge de nombreuses fonctionnalités T-SQL, telles que la création de tables et la gestion des données dans les tables. Par conséquent, vous contrôlez complètement la création de vos tables de modèles dimensionnels et leur chargement avec des données.

Remarque

Dans cet article, le terme entrepôt de données fait référence à un entrepôt de données d’entreprise, qui fournit une intégration complète des données critiques au sein de l’organisation. En revanche, le terme autonome entrepôt fait référence à Fabric Warehouse, qui est une offre de base de données relationnelle SaaS (Software as a Service) que vous pouvez utiliser pour implémenter un entrepôt de données. Pour plus de clarté, dans cet article, ce dernier est mentionné en tant que Fabric Warehouse.

Conseil

Si vous êtes inexpérimenté avec la modélisation dimensionnelle, considérez que cette série d’articles est votre première étape. Il n’est pas destiné à fournir une discussion complète sur la conception de modélisation dimensionnelle. Pour plus d’informations, reportez-vous directement au contenu publié et largement adopté, comme The Data Warehouse Toolkit : The Definitive Guide to Dimensional Modeling (3ème édition, 2013) par Ralph Kimball et d’autres auteurs.

Conception de schémas en étoile

Le schéma en étoile est une approche de modélisation dimensionnelle adoptée par les entrepôts de données relationnelles. Il est recommandé d’adopter une approche de conception lors d’une création Fabric Warehouse. Un schéma en étoile comprend des tables de faits et des tables de dimension.

• Les tables de dimension décrivent les entités pertinentes pour vos besoins en matière d’analyse et d’organisation. En général, elles représentent les éléments que vous modélisez. Les choses peuvent être des produits, des personnes, des lieux ou tout autre concept, y compris la date et l’heure. Pour plus d’informations et des meilleures pratiques de conception, consultez Tables de dimension dans cette série.
• Les tables de faits stockent les mesures associées aux observations ou aux événements. Elles peuvent stocker les commandes, les soldes du stock, les taux de change, les lectures de température, etc. Les tables de faits contiennent des clés de dimension avec des valeurs granulaires qui peuvent être agrégées. Pour plus d’informations et de meilleures pratiques de conception, consultez Tables de faits dans cette série.

Une conception de schéma en étoile est optimisée pour les charges de travail de requête analytiques. Pour cette raison, elle est considérée comme un prérequis pour les modèles sémantiques Power BI d’entreprise. Les requêtes analytiques concernent le filtrage, le regroupement, le tri et la synthèse des données. Les données de faits sont résumées dans le contexte des filtres et des regroupements des tables de dimension associées.

La raison pour laquelle elle est appelée schéma en étoile est qu’une table de faits forme le centre d’une étoile tandis que les tables de dimension associées forment les pointes de l’étoile.

Un schéma en étoile contient souvent plusieurs tables de faits, et donc plusieurs étoiles.

Un schéma en étoile bien conçu fournit des requêtes hautes performances (relationnelles) en raison de moins de jointures de table et de la probabilité plus élevée d’index utiles. En outre, un schéma en étoile nécessite souvent une faible maintenance à mesure que la conception de l’entrepôt de données évolue. Par exemple, l’ajout d’une nouvelle colonne à une table de dimension pour prendre en charge l’analyse par un nouvel attribut est une tâche relativement simple à effectuer. Comme il ajoute de nouveaux faits et dimensions à mesure que l’étendue de l’entrepôt de données évolue.

Périodiquement, peut-être quotidiennement, les tables d’un modèle dimensionnel sont mises à jour et chargées par un processus d’extraction, transformation et chargement (ETL). Ce processus synchronise ses données avec les systèmes sources, qui stockent les données opérationnelles. Pour plus d’informations, consultez Charger des tables dans cette série.

Modélisation dimensionnelle pour Power BI

Pour les solutions d’entreprise, un modèle dimensionnel dans Fabric Warehouse est un prérequis recommandé pour la création d’un modèle sémantique Power BI. Non seulement le modèle dimensionnel prend en charge le modèle sémantique, mais il s’agit également d’une source de données pour d’autres expériences, comme les modèles Machine Learning.

Toutefois, dans des circonstances spécifiques, il peut ne pas s’agir de la meilleure approche. Par exemple, les analystes en libre-service qui ont besoin de liberté et d’agilité pour agir rapidement, et sans dépendance sur l’informatique, peuvent créer des modèles sémantiques qui se connectent directement aux données sources. Dans ce cas, la théorie de la modélisation dimensionnelle est toujours pertinente. Cette théorie aide les analystes à créer des modèles intuitifs et efficaces, tout en évitant de créer et de charger un modèle dimensionnel dans un entrepôt de données. Au lieu de cela, un modèle quasi dimensionnel peut être créé à l’aide de Power Query, qui définit la logique pour se connecter aux données sources et les transformer afin de créer et charger les tables de modèle sémantique. Pour plus d’informations, consultez Comprendre le schéma en étoile et son importance pour Power BI.

Important

Lorsque vous utilisez Power Query pour définir un modèle dimensionnel dans le modèle sémantique, vous ne pouvez pas gérer les modifications historiques, ce qui peut être nécessaire pour analyser le passé avec précision. Si c’est une exigence, vous devez créer un entrepôt de données et autoriser les processus ETL périodiques à capturer et stocker correctement les modifications de dimension.

Planification d’un entrepôt de données

Vous devez aborder la création d’un entrepôt de données et la conception d’un modèle de dimension comme une entreprise sérieuse et importante. Cela est dû au fait que l’entrepôt de données est un composant principal de votre plateforme de données. Il doit constituer une base solide qui prend en charge l’analytique et la création de rapports, et donc la prise de décision, pour l’ensemble de votre organisation.

À cette fin, votre entrepôt de données doit s’efforcer de stocker des données de qualité, conformes et historiquement exactes en tant que version unique de la vérité. Il doit fournir des données compréhensibles et navigables avec des performances rapides et appliquer des autorisations afin que les données appropriées ne soient accessibles que par les bonnes personnes. Essayez de concevoir votre entrepôt de données pour la résilience, ce qui lui permet de s’adapter au changement à mesure que vos besoins évoluent.

L’implémentation réussie d’un entrepôt de données dépend d’une bonne planification. Pour plus d’informations sur les considérations stratégiques et tactiques et les éléments d’action qui mènent à l’adoption réussie de Fabric et de votre entrepôt de données, consultez la feuille de route d’adoption de Microsoft Fabric.

Conseil

Nous vous recommandons de créer votre entrepôt de données d’entreprise de manière itérative. Commencez par les domaines les plus importants, puis au fil du temps, en fonction de la priorité et des ressources, étendez l’entrepôt de données avec d’autres domaines.

Contenu connexe

Dans l’article suivant de cette série, découvrez les recommandations et les meilleures pratiques de conception pour les tables de dimension.