Conseils pour une mise en œuvre réussie de LuckyTemplates

Nous poursuivrons notre série sur la planification et la mise en œuvre de projets LuckyTemplates. Cette fois-ci, nous discuterons de la conception des ensembles de données , du profilage et des modes . Découvrez la première partie de notre série de planification de projet qui traite des modes de déploiement , et la deuxième partie qui parle de découverte et d'ingestion .

Table des matières

• Conception d'ensembles de données pour la mise en œuvre de projets LuckyTemplates
  • 4 étapes pour concevoir un jeu de données
  • Sélectionnez le processus métier.
    • L'anti-modèle à éviter dans la mise en œuvre de LuckyTemplates
  • Déclarez le grain.
  • Identifiez les dimensions.
  • Définissez les faits.
• Matrice de bus de données pour la mise en œuvre de projets LuckyTemplates
• Profilage des données pour la mise en œuvre de LuckyTemplates
  • Services d'intégration SQL Server
  • Studio DAX
  • Bureau LuckyTemplates
• Planification des jeux de données pour la mise en œuvre de LuckyTemplates
  • Choisir un mode de jeu de données
  • Quelques questions à poser lors du choix des modes de jeu de données
• Conclusion

Conception d'ensembles de données pour la mise en œuvre de projets LuckyTemplates

Parlons du processus de conception de l'ensemble de données et discutons de la matrice de bus d'entrepôt de données , qui est un outil qui existe depuis un certain temps.

La conception de jeux de données LuckyTemplates est similaire à la conception d'entrepôts de données. Ainsi, les ensembles de données et les entrepôts de données ont des concepts similaires tels que les tables de faits et de dimensions, les schémas en étoile, les dimensions à évolution lente, la granularité des tables de faits et les clés informées locales pour établir des relations entre les tables.

4 étapes pour concevoir un jeu de données

Le processus de conception d'un jeu de données comporte quatre étapes : sélectionnez le processus métier , déclarez le grain de vos tables de faits, identifiez les dimensions , puis définissez les faits .

Sélectionnez le processus métier.

Pour la première étape, chaque processus métier est représenté par une table de faits avec un schéma en étoile de relation plusieurs à un avec les dimensions.

Au cours d'un processus de découverte ou de collecte d'exigences, il est difficile de se concentrer sur un seul processus métier isolé, car les utilisateurs analysent régulièrement plusieurs processus métier simultanément.

L'anti-modèle à éviter dans la mise en œuvre de LuckyTemplates

L' anti-modèle courant (qui est une réponse à un problème récurrent qui est généralement inefficace et potentiellement contre-productif) que vous souhaitez éviter dans les projets LuckyTemplates est le développement de jeux de données pour des projets ou des équipes spécifiques plutôt que pour les processus métier .

Par exemple, développer un jeu de données exclusivement pour l'équipe marketing et un autre jeu de données pour l'organisation commerciale. Cette approche entraîne naturellement un gaspillage de ressources car les mêmes données de vente sont interrogées et actualisées deux fois dans les deux ensembles de données. Ceux-ci consommeront également des ressources de stockage dans le service LuckyTemplates.

ce sont quelques-unes des raisons pour lesquelles vous souhaitez passer par un bon processus de conception d'ensembles de données. Une approche isolée entraîne des problèmes de gestion et de contrôle de version, car les ensembles de données peuvent contenir des variations et des transformations.

Bien que les besoins analytiques des utilisateurs ou des équipes soient la priorité des projets LuckyTemplates, il est également important de planifier des solutions durables qui peuvent finalement être partagées entre les équipes.

Déclarez le grain.

Le grain des tables de faits couvre finalement le niveau de détail disponible pour les requêtes analytiques, ainsi que la quantité de données accessibles.

Ainsi, un grain plus élevé signifie plus de détails tandis qu'un grain plus faible signifie moins de détails. Par exemple, lorsque vous souhaitez obtenir le niveau de la ligne de commande client ou si vous souhaitez que le projet contienne uniquement le niveau récapitulatif de chaque commande client et ne descende pas aux produits spécifiques qui ont été commandés dans le cadre de cette vente.

Parfois, ce grain peut varier en fonction de votre calendrier. J'ai rencontré un certain nombre de clients qui voulaient des tableaux de faits très détaillés pour le trimestre en cours, mais pour les trimestres précédents, ils avaient juste besoin de savoir quel était le total des ventes pour le trimestre.

Au cours de cette étape, vous souhaitez déterminer ce que représente chaque ligne des différents processus métier . Par exemple, chaque ligne de la table de faits sur les ventes de notre entrepôt de données représente la ligne d'une commande client d'un client.

Inversement, les lignes d'un plan de ventes et de marges seront agrégées dans un mois calendaire, une sous-catégorie de produits et une région de territoire de vente. donc dans ce cas, vous avez deux tables de faits différentes et deux grains différents. si vous voulez comparer les deux, il y aura un travail de modélisation des données impliqué.

Identifiez les dimensions.

Les dimensions ne sont que le sous-produit naturel du grain choisi lors de l'étape de conception précédente.

Ainsi, une seule ligne d'échantillon de la table de faits doit clairement indiquer les dimensions de l'entité commerciale associées au processus donné, telles que le client qui a acheté un projet individuel, le produit à une certaine date et à un certain moment. Les tables de faits représentant des grains inférieurs ont moins de dimensions.

Par exemple, une table de faits représentant le niveau d'en-tête d'un bon de commande peut identifier le fournisseur, mais pas le produit individuel acheté auprès du fournisseur. dans ce cas, vous n'auriez pas besoin d'inclure une catégorie de produit ou une dimension de sous-catégorie de produit.

Définissez les faits.

Les faits représentent les colonnes numériques incluses dans les tables de faits. Ainsi, alors que les colonnes de dimension de l'étape 3 sont utilisées pour les relations, les colonnes de faits sont utilisées dans les mesures contenant une logique d'agrégation, comme la somme d'une colonne de quantité ou la moyenne d'une colonne de prix.

Matrice de bus de données pour la mise en œuvre de projets LuckyTemplates

La matrice de bus d'entrepôt de données est un élément de base de l'architecture d'entrepôt de données Ralph Kimball, qui fournit une approche incrémentielle et intégrée de la conception d'entrepôt de données.

L'architecture que vous voyez ici provient de The Data Warehouse Toolkit , 3e édition de Ralph Kimball. Il permet des modèles de données évolutifs dont plusieurs équipes ou fonctions métier ont souvent besoin pour accéder aux mêmes processus et dimensions métier.

Il est utile de conserver une matrice de bus d'entrepôt de données. lorsque vous le remplissez, vous saurez s'il existe d'autres ensembles de données contenant des tables de faits et des tables de dimensions similaires sur Internet. cela favorise la réutilisabilité du projet et améliore la communication du projet.

Ainsi, chaque ligne reflète un processus métier important et récurrent, tel que la clôture mensuelle du grand livre. chaque colonne représente une entité métier, qui peut se rapporter à un ou plusieurs des processus métier, tandis que les lignes grisées représentent les processus métier inclus dans le projet.

Profilage des données pour la mise en œuvre de LuckyTemplates

une fois que vous avez identifié le grain et que le processus de conception de l'ensemble de données en quatre étapes est terminé, il doit être immédiatement suivi d'une analyse technique des données source des tables de faits et de dimensions .

Les métadonnées techniques, y compris les diagrammes de base de données et les résultats du profilage des données, sont essentielles pour l'étape de planification du projet.

Ces informations sont utilisées pour garantir que le jeu de données LuckyTemplates reflète les définitions commerciales prévues et repose sur une source fiable et fiable.

Il y a donc trois façons différentes de collecter ces informations de profilage, ce qui devrait être la toute première étape que les gens feront une fois qu'ils seront sortis du processus de conception.

Services d'intégration SQL Server

Il y a plusieurs façons de procéder. Une méthode consiste à utiliser une tâche de profilage de données dans un package SQL Server Integration Services (SSIS).

La tâche de profilage des données nécessite une connexion ADO.NET et peut écrire sa sortie dans un fichier XML ou une variable SSIS.

Dans cet exemple, les données source ADO.NET sont un entrepôt de données, une base de données et un serveur SQL AdventureWorks, et la destination est un fichier XML.

Ainsi, une fois la tâche exécutée, le fichier XML peut être lu via un visualiseur de profil de données du serveur SQL. Vous pouvez voir les résultats en termes de nombre nul et de pourcentages de nombre nul.

Studio DAX

Une autre méthode de profilage des données consiste à utiliser DAX Studio. vous devez réellement ingérer les données dans un jeu de données LuckyTemplates en accédant à DAX Studio, accédez à l'onglet avancé et exécutez VertiPaq Analyzer .

Il vous montrera le même type d'informations autour de la cardinalité de vos colonnes afin que vous sachiez lesquelles occupent le plus d'espace dans votre modèle de données. il comprend toutes les différentes statistiques autour des données.

Bureau LuckyTemplates

le profilage des données est également disponible dans PowerQuery dans le bureau LuckyTemplates. Si vous accédez à l' onglet Affichage , vous pouvez activer des éléments tels que la qualité des colonnes, la distribution des colonnes et le profil des colonnes. Pour au moins les mille premières lignes environ, vous pouvez voir les informations telles que les erreurs, les valeurs nulles, les moyennes et les écarts types.

Planification des jeux de données pour la mise en œuvre de LuckyTemplates

Une fois les données source profilées et évaluées par rapport aux exigences identifiées dans le processus de conception de l'ensemble de données en quatre étapes, l'équipe BI peut analyser plus en détail les options de mise en œuvre de l'ensemble de données.

Dans presque tous les projets LuckyTemplates, même ceux qui impliquent des investissements importants dans les données d'entreprise, l'entrepôt, l'architecture et les outils et processus ETL, un certain niveau de logique, d'intégration ou de transformation supplémentaire est nécessaire pour améliorer la qualité et la valeur des données sources.

L'étape de planification de l'ensemble de données détermine comment les problèmes de transformation de données identifiés sont traités pour prendre en charge l'ensemble de données. En outre, l'équipe de projet doit déterminer s'il convient de développer un jeu de données en mode importation , un jeu de données de requête directe ou un jeu de données composite .

Pour clarifier le processus de planification de l'ensemble de données, ce diagramme identifie les différentes couches de l'entrepôt de données et de l'ensemble de données LuckyTemplates où la transformation et la logique métier peuvent être implémentées.

dans certains projets, une transformation minimale est nécessaire et elle peut facilement être incluse dans le jeu de données LuckyTemplates. Par exemple, si seules quelques colonnes supplémentaires sont nécessaires pour une table de dimension et qu'il existe des instructions simples sur la manière dont ces colonnes seront calculées, l'organisation informatique peut choisir d'implémenter ces transformations dans les requêtes de puissance M plutôt que de réviser l'entrepôt de données.

Si l'écart substantiel entre les besoins de BI et l'entrepôt de données de l'entreprise persiste, les ensembles de données LuckyTemplates deviennent plus complexes à créer et à maintenir.

Les concepteurs d'ensembles de données doivent régulièrement analyser et communiquer les implications des ensembles de données s'il existe des niveaux de complexité plus élevés.

Cependant, si la logique de transformation requise est complexe ou extensive avec plusieurs opérations conjointes, filtres de ligne et changements de type de données, l'organisation informatique peut choisir d'implémenter des changements essentiels dans l'entrepôt de données pour prendre en charge le nouvel ensemble de données et les futurs projets BI.

Par exemple, une table intermédiaire et une procédure de magasin SQL peuvent être nécessaires pour prendre en charge, réviser et mettre à jour le processus, ou la création d'un index peut être nécessaire pour améliorer les performances des requêtes pour les ensembles de données DirectQuery.

Choisir un mode de jeu de données

Une étape ultérieure mais étroitement liée à la planification de l'ensemble de données consiste à choisir entre le mode d'importation par défaut, le mode DirectQuery/live ou le mode composite.

Dans certains projets, il s'agit d'une simple décision où une seule option est réalisable ou réaliste compte tenu des exigences connues, tandis que d'autres projets nécessiteront une analyse importante des avantages et des inconvénients de chaque conception.

Ainsi, si une source de données est considérée comme lente ou mal équipée pour gérer un volume élevé de requêtes analytiques, un ensemble de données en mode importation est très probablement l'option préférée.

De même, si la visibilité en temps quasi réel d'une source de données est essentielle, alors DirectQuery ou le mode direct est la seule option pour y parvenir. les modes DirectQuery et live sont très similaires. Les deux méthodes ne stockent pas les données dans l'ensemble de données lui-même et interrogent directement les systèmes source pour récupérer les données en fonction de l'action de l'utilisateur. Nous avons maintenant DirectQuery pour les jeux de données LuckyTemplates et DirectQuery pour Analysis Services.

Quelques questions à poser lors du choix des modes de jeu de données

Voici quelques questions à se poser pour décider du mode à utiliser. Existe-t-il une source unique pour notre ensemble de données ? S'il n'y a pas de source unique, vous ne pouviez pas utiliser la source DirectQuery/Live dans le passé.

Même si nous avons maintenant des ensembles de données en mode composite, c'est toujours une bonne question à poser au départ car s'il n'y a pas de source unique, alors ce sera soit importé, soit composite.

Si la source DirectQuery/Live est une option, la source est-elle capable de prendre en charge les requêtes analytiques ? Si vous travaillez avec des milliards ou des billions de lignes, un ensemble de données en mode importation n'est peut-être pas réalisable et vous devrez passer en mode DirectQuery ou composite pour vous assurer que l'ensemble de données est utilisable.

Si la source DirectQuery/Live est capable de prendre en charge la charge de travail, la connexion DirectQuery/Live est-elle plus précieuse que les performances et la flexibilité fournies par un modèle d'importation ?

Conclusion

Cet article conclut cette série sur la planification de projets LuckyTemplates. ce sont, je pense, les étapes essentielles de tous les projets LuckyTemplates sur lesquels vous travaillez. Ces étapes sont importantes lors de la vérification diligente, en particulier dans un contexte d'informatique décisionnelle d'entreprise.

Tous mes vœux,

Greg Decker