Meilleures pratiques pour créer un modèle dimensionnel à l’aide de flux de données

La conception d’un modèle dimensionnel fait partie des tâches courantes qu’il est possible d’effectuer avec un flux de données. Cet article présente certaines des bonnes pratiques à suivre pour la création d’un modèle dimensionnel à l’aide d’un flux de données.

Flux de données intermédiaires

L’un des points clés de tout système d’intégration de données est la réduction du nombre de lectures du système opérationnel source. Dans l’architecture traditionnelle de l’intégration des données, cette réduction est obtenue en créant une base de données appelée base de données intermédiaire. L’objectif de la base de données intermédiaire est de charger les données « en l’état » à partir de la source de données à intervalles réguliers.

Le reste de l’intégration des données utilisera ensuite la base de données intermédiaire comme source en vue d’une transformation et d’une conversion vers la structure du modèle dimensionnel.

Nous vous recommandons de suivre la même approche en utilisant des flux de données. Créez un ensemble de flux de données qui devra charger des données « en l’état » à partir du système source (et uniquement pour les tables dont vous avez besoin). Le résultat est ensuite stocké dans la structure de stockage du flux de données (Azure Data Lake Storage ou Dataverse). Cette modification garantit que l’opération de lecture des données du système source sera minimale.

Ensuite, vous pouvez créer d’autres flux de données qui sourcent leurs données à partir de flux de données intermédiaires. Les avantages de cette approche incluent :

• La réduction du nombre d’opérations de lecture à partir du système source et la réduction de la charge sur le système source en conséquence.
• La réduction de la charge sur les passerelles de données si une source de données locale est utilisée.
• Le fait de disposer d’une copie intermédiaire des données à des fins de rapprochement, dans le cas où les données du système source viendraient à changer.
• Le fait de rendre les flux de données de transformation indépendants de la source.

Image mettant l’accent sur les flux de données intermédiaires et le stockage intermédiaire, et montrant les données accessibles à partir de la source de données par le flux de données intermédiaire, et les tables stockées dans Cadavers ou Azure Data Lake Storage. Les tables sont ensuite montrées en cours de transformation avec d’autres flux de données, qui sont ensuite envoyés sous forme de requêtes.

Flux de données de transformation

Quand vous séparez vos flux de données de transformation de vos flux de données intermédiaires, la transformation devient indépendante de la source. Cette séparation permet de migrer le système source vers un nouveau système. Dans ce cas, vous avez seulement à modifier les flux de données intermédiaires. Les flux de données de transformation fonctionneront probablement sans aucun problème, car ils sont sourcés uniquement à partir de flux de données intermédiaires.

Cette séparation aide également si la connexion au système source est lente. Le flux de données de transformation n’aura pas à attendre longtemps pour obtenir des enregistrements via une connexion lente au système source. Le flux de données intermédiaire s’est déjà occupé de cette tâche, et les données seront prêtes pour la couche de transformation.

Architecture multicouche

Une architecture multicouche est une architecture où vous effectuez des actions dans des couches distinctes. Les flux de données intermédiaires et les flux de données de transformation peuvent constituer les deux couches d’une architecture de flux de données multicouche. Le fait d’exécuter des actions sur des couches différentes garantit un niveau de maintenance minimal. Lorsque vous souhaitez modifier un élément, vous n’avez qu’à le modifier dans la couche où il se trouve. Les autres couches doivent toutes continuer à fonctionner correctement.

L’image suivante montre une architecture multicouche pour les flux de données dans laquelle leurs tables sont ensuite utilisées dans des modèles sémantiques Power BI.

Utilisez une table calculée autant que possible

Lorsque vous utilisez le résultat d’un flux de données dans un autre flux de données, vous utilisez le concept de table calculée, ce qui signifie obtenir des données à partir d’une table « déjà traitée et stockée ». La même chose peut se produire à l’intérieur d’un flux de données. Lorsque vous référencez une table à partir d’une autre table, vous pouvez utiliser la table calculée. Ceci est utile lorsque vous avez un ensemble de transformations qui doivent être effectuées dans plusieurs tables, appelées transformations communes.

Dans l’image précédente, la table calculée obtient les données directement de la source. Toutefois, dans l’architecture des flux de données intermédiaires et de transformation, il est probable que les tables calculées proviennent des flux de données intermédiaires.

Créer un schéma en étoile

Le meilleur modèle dimensionnel est un modèle de schéma en étoile qui comporte des dimensions et des tables de faits conçues de manière à réduire la durée d’interrogation des données du modèle, et qui facilite la compréhension des données visualisées.

Il n’est pas recommandé d’importer dans un système décisionnel des données qui ont la même disposition de système opérationnel. Les tables de données doivent être réorganisées. Certaines des tables doivent prendre la forme d’une table de dimension qui conserve des informations descriptives. Certaines des tables doivent prendre la forme d’une table de faits pour conserver les données agrégeables. La meilleure disposition à utiliser pour les tables de faits et les tables de dimension est le schéma en étoile. Informations supplémentaires : Comprendre le schéma en étoile et son importance pour Power BI

Utiliser une valeur de clé unique pour les dimensions

Lorsque vous créez des tables de dimension, assurez-vous d’avoir une clé pour chacune d’elles. Vous évitez ainsi les relations plusieurs-à-plusieurs (autrement dit, « faibles ») entre les différentes dimensions. Vous pouvez créer la clé en appliquant une transformation afin de garantir qu’une colonne ou une combinaison de colonnes retourneront des lignes uniques dans la dimension. Ensuite, cette combinaison de colonnes peut être marquée comme clé dans la table du flux de données.

Effectuer une actualisation incrémentielle pour les tables de faits volumineuses

Les tables de faits sont toujours les tables les plus grandes du modèle dimensionnel. Nous vous recommandons de réduire le nombre de lignes transférées pour ces tables. Si vous avez une table de faits très volumineuse, assurez-vous d’avoir recours à un rafraîchissement incrémentiel pour cette table. Un rafraîchissement incrémentiel peut être effectué dans le modèle sémantique Power BI, ainsi que dans les tables de flux de données.

Vous pouvez utiliser l’actualisation incrémentielle pour actualiser uniquement une partie des données, c’est-à-dire la partie qui a été modifiée. Il existe plusieurs options permettant de choisir la partie des données à actualiser et celle à conserver. Informations supplémentaires : Utilisation d’une actualisation incrémentielle avec des flux de données Power BI

Référencement pour créer tables de dimensions et des tables de faits

Dans le système source, vous disposez souvent d’une table que vous utilisez pour générer des tables de faits et des tables de dimension dans l’entrepôt de données. Ces tables sont de bons choix pour les tables calculées et les flux de données intermédiaires. La partie commune du processus (comme le nettoyage des données et la suppression des lignes et des colonnes en trop) ne peut être effectuée qu’une seule fois. En utilisant une référence issue de la sortie de ces actions, vous pouvez produire les tables de faits et les tables de dimension. Cette approche aura recours à la table calculée pour les transformations communes.