Modélisation dimensionnelle dans Microsoft Fabric Warehouse : tables de faits

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

Remarque

Cet article fait partie de la série de modélisation dimensionnelle d’articles. Cette série se concentre sur les conseils et les meilleures pratiques de conception liées à la modélisation dimensionnelle dans Microsoft Fabric Warehouse.

Cet article vous fournit des conseils et des bonnes pratiques pour la conception de tables de faits dans un modèle dimensionnel. 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, tenez compte de cette série d’articles de 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.

Dans un modèle dimensionnel, une table de faits stocke les mesures associées aux observations ou aux événements. Elle peut stocker les commandes des ventes, les soldes du stock, les taux de change, les lectures de température, etc.

Les tables de faits incluent des mesures, qui sont généralement des colonnes numériques, telles que la quantité de commandes de ventes. Les requêtes analytiques résument les mesures (à l’aide de la somme, du nombre, de la moyenne et d’autres fonctions) dans le contexte des filtres de dimension et des regroupements.

Les tables de faits incluent également des clés de dimension, qui déterminent la dimensionnalité des faits. Les valeurs de clé de dimension déterminent la granularité des faits, qui est le niveau atomique par lequel les faits sont définis. Par exemple, une clé de dimension de date de commande dans une table de faits de ventes définit la granularité des faits au niveau de la date, tandis qu’une clé de dimension de date cible dans une table de faits de cible des ventes peut définir la granularité au niveau du trimestre.

Remarque

Bien qu’il soit possible de stocker des faits à une granularité plus élevée, il n’est pas facile de fractionner les valeurs de mesure à des niveaux de granularité inférieurs (si nécessaire). Les volumes de données élevés, ainsi que les exigences analytiques, peuvent fournir une raison valide de stocker des faits de granularité plus élevés, mais au détriment de l’analyse détaillée.

Pour identifier facilement les tables de faits, vous préfixez généralement leurs noms avec f_ ou Fact_.

Structure de la table de faits

Pour décrire la structure d’une table de faits, considérez l’exemple suivant d’une table de faits des ventes nommée f_Sales. Cet exemple applique les meilleures pratiques de conception. Chacun des groupes de colonnes est décrit dans les sections suivantes.

CREATE TABLE f_Sales
(
    --Dimension keys
    OrderDate_Date_FK INT NOT NULL,
    ShipDate_Date_FK INT NOT NULL,
    Product_FK INT NOT NULL,
    Salesperson_FK INT NOT NULL,
    <…>
    
    --Attributes
    SalesOrderNo INT NOT NULL,
    SalesOrderLineNo SMALLINT NOT NULL,
    
    --Measures
    Quantity INT NOT NULL,
    <…>
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Clé primaire

Comme c’est le cas dans l’exemple, l’exemple de table de faits n’a pas de clé primaire. C’est parce qu’elle ne sert généralement pas à des fins utiles, et elle augmenterait inutilement la taille de stockage de table. Une clé primaire est souvent implicite par l’ensemble de clés de dimension et d’attributs.

Clés de dimension

L’exemple de table de faits a différentes clés de dimension, qui déterminent la dimensionnalité de la table de faits. Les clés de dimension sont des références aux clés de substitution (ou attributs de niveau supérieur) dans les dimensions associées.

Remarque

Il s’agit d’une table de faits inhabituelle qui n’inclut pas au moins une clé de dimension de date.

Une table de faits peut référencer une dimension plusieurs fois. Dans ce cas, il s’agit d’une dimension de jeu de rôles. Dans cet exemple, la table de faits a les clés de dimension OrderDate_Date_FK et ShipDate_Date_FK. Chaque clé de dimension représente un rôle distinct, mais il n’existe qu’une seule dimension de date physique.

Il est recommandé de définir chaque clé de dimension comme NOT NULL. Pendant le chargement de la table de faits, vous pouvez utiliser des membres de dimension spéciaux pour représenter les états d’erreur manquants, inconnus, N/A ou d’erreur (si nécessaire).

Attributs

L’exemple de table de faits a deux attributs. Les attributs fournissent des informations supplémentaires et définissent la granularité des données de faits, mais ils ne sont ni des clés de dimension ni des attributs de dimension, ni des mesures. Dans cet exemple, les colonnes d’attribut stockent les informations de commande vente. D’autres exemples peuvent inclure des numéros de suivi ou des numéros de ticket. À des fins d’analyse, un attribut peut former une dimension dégénérée.

Mesures

L’exemple de table de faits comporte également des mesures, comme la colonne Quantity. Les colonnes de mesure sont généralement numériques et couramment additives (ce qui signifie qu’elles peuvent être additionnées et résumées à l’aide d’autres agrégations). Pour plus d’informations, consultez la section Types de mesure plus loin dans cet article.

Attributs d’audit

L’exemple de table de faits possède également différents attributs d’audit. Les attributs d’audit sont facultatifs. Ils vous permettent de suivre le moment et la façon dont les enregistrements de faits ont été créés ou modifiés, et peuvent inclure des informations de diagnostic ou de résolution des problèmes générées pendant les processus d’extraction, transformation et chargement (ETL). Par exemple, vous souhaiterez suivre qui (ou quel processus) a mis à jour une ligne et quand. Les attributs d’audit peuvent également aider à diagnostiquer un problème difficile, comme lorsqu’un processus ETL s’arrête de façon inattendue.

Taille de la table de faits

Les tables de faits varient en taille. Leur taille correspond à la dimensionnalité, à la granularité, au nombre de mesures et à la quantité d’historique. Par rapport aux tables de dimension, les tables de faits sont plus étroites (moins de colonnes), mais volumineuses voire même immenses en termes de lignes (plusieurs milliards).

Concepts de conception de faits

Cette section décrit différents concepts de conception de faits.

Types de tables de faits

Il existe trois types de tables de faits :

• Tables de faits de transaction
• Tables de faits instantané périodiques
• Accumulation de tables de faits d’instantanés

Tables de faits de transaction

Une table de faits de transaction stocke les événements ou transactions commerciaux. Chaque ligne stocke les faits en termes de clés et de mesures de dimension, et éventuellement d’autres attributs. Toutes les données sont entièrement connues lorsqu’elles sont insérées et ne changent jamais (sauf pour corriger les erreurs).

En règle générale, les tables de faits transactionnelles stockent les faits au niveau de granularité le plus bas possible et contiennent des mesures qui sont additives dans toutes les dimensions. Une table de faits de ventes qui stocke chaque ligne commande vente est un bon exemple de table de faits de transaction.

Tables de faits instantané périodiques

Une table de faits d’instantané périodique stocke les mesures à un moment prédéfini ou à intervalles spécifiques. Elle fournit un résumé des métriques clés ou des indicateurs de performances au fil du temps, et elle est donc utile pour l’analyse des tendances et la surveillance des changements au fil du temps. Les mesures sont toujours semi-additives (description plus loin).

Une table de faits d’inventaire est un bon exemple de table d’instantané périodique. Il est chargé tous les jours avec le solde de stock de fin de jour de chaque produit.

Les tables d’instantanés périodiques peuvent être utilisées à la place d’une table de faits de transaction lorsque l’enregistrement de gros volumes de transactions est coûteux et ne prend pas en charge les exigences analytiques utiles. Par exemple, il peut y avoir des millions de mouvements de stock dans une journée (qui peuvent être stockés dans une table des faits transactionnels), mais votre analyse n’a besoin que des tendances des niveaux de stock de fin de jour.

Accumulation de tables de faits d’instantanés

Une table de faits d’instantané cumulée stocke les mesures qui s’accumulent sur une période ou un flux de travail bien défini. Elle enregistre souvent l’état d’un processus métier à des étapes ou des jalons distincts, qui peuvent prendre des jours, des semaines ou même des mois.

Une ligne de faits est chargée peu après le premier événement d’un processus, puis la ligne est mise à jour dans une séquence prévisible chaque fois qu’un événement jalon se produit. Les mises à jour continuent jusqu’à ce que le processus soit terminé.

L’accumulation d’une table de faits d’instantané a plusieurs clés de dimension de date, chacune représentant un événement jalon. Certaines clés de dimension peuvent enregistrer un état N/A jusqu’à ce que le processus arrive à un certain jalon. Les mesures enregistrent généralement des durées. Les durées entre les jalons peuvent fournir un aperçu précieux d’un flux de travail métier ou d’un processus d’assembly.

Types de mesure

Les mesures sont généralement numériques et couramment additives. Toutefois, certaines mesures ne peuvent pas toujours être additionnées. Ces mesures sont classées comme semi-additives ou non additives.

Mesures additives

Une mesure additive peut être additionnée sur n’importe quelle dimension. Par exemple, la quantité de commandes et le chiffre d’affaires sont des mesures additives (le chiffre d’affaires étant enregistré pour une devise unique).

Mesures semi-additives

Une mesure semi-additive peut être additionnée uniquement sur certaines dimensions.

Voici quelques exemples de mesures non additives.

• Toute mesure d’une table de faits d’instantané périodique ne peut pas être additionnée sur d’autres périodes. Par exemple, vous ne devez pas additionner l’âge d’un article d’inventaire échantillonné tous les soirs, mais vous pouvez additionner l’âge de tous les articles de stock sur une étagère, chaque nuit.
• Une mesure de solde de stock dans une table de faits d’inventaire ne peut pas être additionnée entre d’autres produits.
• Les produits des ventes d’une table de faits de ventes qui a une clé de dimension monétaire ne peuvent pas être additionnés avec des devises différentes.

Mesures non additives

Une mesure non-additive ne peut pas être additionnée sur n’importe quelle dimension. L’un des exemples est une lecture de température ; par sa nature, il n’est pas logique de l’ajouter à d’autres lectures.

D’autres exemples incluent les taux, tels que les prix unitaires et les ratios. Toutefois, il est considéré comme une meilleure pratique de stocker les valeurs utilisées pour calculer le ratio, ce qui permet de calculer le ratio si nécessaire. Par exemple, un pourcentage de remise d’un fait de vente peut être stocké sous la forme d’une mesure de montant de remise (pour être divisé par la mesure du chiffre d’affaires). Autre exemple : l’âge d’un article de stock sur l’étagère ne doit pas être additionné au fil du temps, mais vous pouvez observer une tendance dans l’âge moyen des articles de stock.

Bien que certaines mesures ne puissent pas être additionnées, elles sont toujours des mesures valides. Elles peuvent être agrégées à l’aide du nombre, du nombre distinct, du nombre minimal, du maximum, de la moyenne et d’autres. En outre, les mesures non additives peuvent devenir additifs lorsqu’elles sont utilisées dans les calculs. Par exemple, le prix unitaire multiplié par la quantité de commande produit le chiffre d’affaires, qui est additif.

Tables de faits sans faits

Lorsqu’une table de faits ne contient aucune colonne de mesure, elle est appelée table de faits sans faits. Une table de faits sans faits enregistre généralement des événements ou des occurrences, comme les étudiants qui assistent à la classe. D’un point de vue analytique, une mesure peut être obtenue en comptant les lignes de faits.

Agréger des tables de faits

Une table de faits agrégées représente un rollup d’une table de faits de base à une dimensionnalité inférieure et/ou supérieure. Son objectif est d’accélérer les performances des requêtes pour les dimensions couramment interrogées.

Remarque

Un modèle sémantique Power BI peut générer des agrégations définies par l’utilisateur pour obtenir le même résultat, ou utiliser la table de faits d’agrégation de l’entrepôt de données à l’aide du mode de stockage DirectQuery.

Contenu connexe

Dans l’article suivant de cette série, découvrez les recommandations et les meilleures pratiques de conception pour le chargement des tables de modèle dimensionnel.