L'automatisé, Pas de code Pile de données
Apprener comment Astera Data Stack peut simplifier et rationaliser la gestion des données de votre entreprise.
Démarrez le développement d'un entrepôt de données avec la modélisation automatisée des données d'entreprise
Et si vous pouviez combiner la conception et le développement d'un entrepôt de données dans un processus transparent et automatisé qui vous ferait passer du reporting de base à l'analyse avancée de haut niveau en quelques semaines seulement ? Eh bien, mettez en place le bon processus de modélisation des données et vous pourrez créer une architecture BI rapide, évolutive et agile. Lisez la suite pour découvrir comment faire fonctionner le développement de modèles de données d'entreprise pour votre entreprise.
À la base, les entrepôts de données sont conçus pour répondre aux questions commerciales. Celles-ci peuvent aller de simples requêtes descriptives axées sur la génération de rapports périodiques à des analyses beaucoup plus ambitieuses visant à étudier les facteurs à l'origine d'un scénario pour une gestion efficace des données. Pour obtenir ce type d'intelligence ciblée de votre système de BI, vous devez vous assurer que les exigences des utilisateurs sont étroitement liées aux concepts commerciaux pendant la phase de développement de l'entrepôt de données.
La meilleure façon de connecter les objectifs des utilisateurs finaux à votre architecture de données consiste à placer la modélisation des données d'entreprise au centre de votre entrepôt de données. Ces schémas sont des diagrammes de relation d'entité visualisés et constituent des systèmes sources, les organisant dans une structure optimisée adaptée à une interrogation rapide et à la convivialité. Plus important encore, ils montrent la logique métier sous-jacente derrière différents processus opérationnels dans un format immédiatement compréhensible pour les utilisateurs non techniques et les développeurs.
S'il est conçu correctement, les avantages d'un modèle de données d'entreprise peuvent être réalisés pour l'ensemble de votre entrepôt de données. Ils vous aideront à identifier d'où les données critiques doivent être récupérées, les plates-formes qui peuvent le mieux prendre en charge votre modèle de données physique et votre base de données, et comment les pipelines de données circuleront de la source à la destination.
Jetons un coup d'œil à certaines techniques fondamentales de modélisation des données qui sont essentielles à ce processus.
Commencer à la source
Répliquez vos systèmes sources avec précision, et vous pourriez vous retrouver avec un schéma qui ressemble à ceci
La première chose dont vous devez vous assurer lors de la modélisation de schéma est que vous pouvez répliquer avec précision les systèmes sources au niveau logique.
Pour ce faire, vous devez identifier où résident vos données critiques - est-ce dans un base de données sur site, un lac de données cloud ou sur une plate-forme CRM comme Salesforce? Bien entendu, seules des tables spécifiques au sein de ces applications seront pertinentes à des fins de BI. Si vous avez déjà créé des rapports dans vos systèmes transactionnels, vous aurez alors une bonne idée des ensembles de données à intégrer dans votre entrepôt de données. En fin de compte, vous voulez vous assurer que vous pouvez exécuter toutes les mêmes requêtes qu'auparavant, sans interruption.
Créer un cadre de métadonnées standardisé
Lorsque vous créez des modèles de données logiques d'entreprise pour englober toutes vos sources, métadonnées doit être appliqué de manière cohérente sur chacun.
Au stade de la conception, vous souhaitez :
- Établir des relations entre les entités à l'aide de clés primaires et de clés étrangères appropriées
- Assurez-vous que vous joignez correctement les tables et que les types de relation d'entité sont correctement définis, donc plusieurs à plusieurs, un à plusieurs, parent-enfant, etc.
- Ayez un alias approprié en place pour vous assurer que le type/champ d'entité est renvoyé lorsqu'une requête est effectuée dans l'entrepôt de données. Par exemple, si vous établissez que les clients et les commandes ont une relation parent-enfant, il est facile de filtrer les clients par commande, mais si vous essayez de le faire dans l'autre sens, vous devrez vous assurer que les commandes sont liées à un client unique, sinon la requête échouera. Ce problème est résolu à l'aide de l'alias.
- Les conventions de dénomination des attributs doivent également être normalisées dans l'ensemble de votre modèle de données d'entreprise pour garantir une compréhensibilité aisée.
N'oubliez pas que vous devez vous assurer qu'il n'y a pas d'écart entre les métadonnées des tables système source et les entités de l'entrepôt de données ; sinon, des incompatibilités se produiront lors du remplissage de l'entrepôt de données. Ces écarts rendront beaucoup plus difficile la création cartographie des données pour déplacer les données de la source à la destination.
Mettre un cadre de métadonnées en place réduit considérablement la dette technique créée par les écarts dans le modèle de données et les pipelines de données ultérieurs. Ces écarts nécessitent davantage d'activités de maintenance et rendent beaucoup plus difficile la mise à jour cohérente des différents types de schémas. Au lieu de cela, vous avez testé et éprouvé, et surtout, des modèles adaptables sans écrire de code.
Des scripts peuvent ensuite être générés sur la base de ces modèles de données enrichis de métadonnées et des éléments de données propagés directement dans une base de données physique.
Rendez votre modèle de données d'entreprise agile
Avec agile, vous devriez être en mesure de gérer les données et d'intégrer les changements dans votre modèle de données de manière beaucoup plus transparente que cela.
Il est important de comprendre que la modélisation des données n'est pas une activité statique. Dans l'entreprise moderne, une BI précise et opportune est essentielle pour presque tous les départements. Cela signifie que davantage d'utilisateurs accèdent à l'entrepôt de données. Désormais, à mesure que ces exigences évoluent, le consommateur de données devra mettre à jour l'architecture existante pour intégrer rapidement de nouvelles sources. Cette capacité doit être intégrée à votre approche de conception.
La modélisation de schéma doit se concentrer sur la fourniture de livrables basés sur les exigences commerciales actuelles plutôt que sur la création d'un modèle de données d'entreprise approuvé avant le début du développement. La création d'un modèle de données qui représente l'intégralité de vos opérations commerciales prendrait beaucoup de temps et d'efforts de conception initiaux. À tel point qu'au moment où le développement commence réellement, le schéma pourrait bien être obsolète.
Dans une approche agile, les modèles de données seraient construits selon les exigences actuelles de la BI dans plusieurs itérations. Supposons que votre directeur des ventes souhaite comparer les performances de plusieurs unités régionales après une restructuration organisationnelle. Votre équipe construirait un modèle de données pour refléter spécifiquement ces règles métier (également connu sous le nom de magasin de données) qui serait capable de générer les informations nécessaires en quelques semaines. En conséquence, l'entrepôt de données se développe progressivement de manière beaucoup plus cohérente. À chaque phase, une nouvelle sortie est produite dont l'utilisateur final peut immédiatement vérifier l'exactitude et la pertinence.
En pratique, plusieurs aspects doivent être en place pour permettre à une telle approche de s'épanouir.
Tout d'abord, les utilisateurs métier doivent être en mesure de travailler en étroite collaboration avec le modélisateur de données tout au long du processus de conception pour garantir une qualité élevée des données. Cela signifie que le schéma doit être conçu de manière à être facilement compris par les deux équipes afin de minimiser les erreurs de communication.
Deuxièmement, si le processus de conception permet aux utilisateurs d'accéder aux systèmes sources, de sélectionner les tables pertinentes et de les répliquer dans un modèle de données, le temps de déploiement sera considérablement réduit. Désormais, les consommateurs de données auront les fonctionnalités en place pour s'assurer que les ensembles de données, qui doivent faire l'objet de rapports, sont disponibles dans le modèle de données fini. Lorsque ces exigences changent, de nouvelles tables peuvent également être ajoutées au modèle initial en utilisant les mêmes techniques.
Une approche agile de modélisation des données d'entreprise devrait également permettre la mise en place d'un système de gestion des versions afin que les mises à jour du schéma d'origine puissent être suivies et surveillées. Avec plusieurs versions en place, vous pouvez annuler toutes les modifications si nécessaire.
Exposer les données sur la base du besoin de savoir
Des données pour moi mais pas pour toi
L'approche itérative vous permet d'avoir une vision beaucoup plus granulaire des données fournies à des fins de BI.
Au lieu d'exposer tous vos magasins de données dans un modèle de données d'entreprise qui est ensuite accessible à tous les membres de l'organisation, vous concevez des schémas personnalisés pour répondre aux exigences de chaque groupe d'utilisateurs. Ces équipes peuvent alors limiter leurs requêtes aux ensembles de données pertinents et ainsi améliorer l'efficacité de leurs rapports et de leurs analyses. Dans le même temps, du point de vue de la sécurité des données, l'organisation garantit que les informations sensibles ne sont exposées qu'aux utilisateurs autorisés.
Adoptez un schéma pour votre modèle de données d'entreprise - Approche agnostique
Quelle conception de schéma choisirez-vous ? Ainsi, lorsque nous parlons des meilleures pratiques de modélisation des données, le schéma qui vient à l'esprit est Le modèle dimensionnel de Kimball. Dans ce schéma, les tables sont organisées selon une structure grossière en forme d'étoile avec une table de faits centrale fournissant des mesures commerciales et des tables de dimensions liées fournissant un contexte à ces nombres.
Cette structure est dominante dans l'industrie depuis plus de trois décennies maintenant, pour une bonne raison. Le modèle dimensionnel est principalement conçu pour des performances de requête rapides et offre une grande flexibilité lors de l'ajout de nouvelles sources à des fins de génération de rapports. Il s'agit également d'une approche orientée processus métier de la conception d'entrepôts de données. En d'autres termes, il organise et présente les données d'une manière que les utilisateurs finaux peuvent facilement comprendre.
Cependant, il existe des raisons pour lesquelles les utilisateurs finaux pourraient envisager une architecture alternative. Par exemple, un schéma en étoile traditionnel incorpore de nombreuses jointures, ce qui peut nuire aux performances des requêtes dans certains cas. Au lieu de cela, ils préféreront peut-être utiliser quelques tableaux larges (plusieurs colonnes) car cette conception convient mieux à certains outils de visualisation. De plus, l'approche permettrait aux utilisateurs finaux de simplifier les requêtes pour une seule table plutôt que d'appliquer plusieurs jointures, ce qui augmente le risque d'erreurs.
Un modèle conceptuel alternatif qui a gagné en popularité ces dernières années est l'architecture de coffre-fort de données. Ce schéma se traduit par une architecture flexible qui combine l'approche orientée métier du modèle dimensionnel avec l'évolutivité du format 3NF adopté par Bill Inmon. Le DV est constitué de hubs représentant les aspects identitaires d'une entreprise, et chacun contient des clés naturelles pour ces processus. Il existe également des liens qui servent de tables intersectionnelles définissant des relations plusieurs à plusieurs entre les différents hubs de l'architecture. Enfin, les satellites contiennent les attributs descriptifs des concentrateurs et des liens.
En fonction de vos exigences en matière de BI, n'importe laquelle de ces architectures peut être préférée, mais les techniques de modélisation de données que vous utilisez devraient vous permettre de concevoir et de propager facilement différents types de schémas, qu'il s'agisse d'un modèle dimensionnel, 3NF ou de coffre-fort de données.
Astera DW Builder - Un outil de modélisation de données d'entreprise pour le développement DW
La modélisation automatisée des données est à la base même d'ADWB
Astera DW Builder est un outil d'automatisation d'entrepôt de données basé sur les métadonnées qui accélère radicalement votre chemin vers le développement d'entrepôt de données.
Ce produit place la modélisation des données au cœur même de ses capacités. Vous permettant de concevoir des modèles de données d'entreprise conformes aux meilleures pratiques à partir de zéro ou de les rétroconcevoir à partir de systèmes sources existants avec la même facilité grâce à de simples commandes glisser-déposer.
À partir de là, vous pouvez enrichir vos schémas avec des spécifications supplémentaires pour des éléments tels que les attributs de table, les types de données, les clés primaires, les clés étrangères. Au niveau du modèle dimensionnel, vous pouvez définir des types SCD pour les champs dynamiques, les dates d'effet/d'expiration et les clés de substitution afin de faciliter un chargement et une interrogation efficaces. ADWB prend également en charge d'autres approches de conception de premier plan, notamment les coffres-forts de données et les modèles de données 3NF. Ces descriptions sont ensuite transmises à un moteur qui conçoit automatiquement tout ce schéma dans une base de données physique.
Travailler de manière logique dans un processus unifié accélère le développement de votre entrepôt de données, réduisant les délais de déploiement de quelques mois, voire plusieurs années, à quelques jours seulement.
Cette nouvelle approche encourage également la collaboration. Les parties prenantes non techniques peuvent facilement comprendre les définitions logiques et les éléments visuels utilisés dans un modèle de données enrichi de métadonnées. Cette connaissance leur permet de participer aux implémentations du début à la fin, garantissant que les livrables sont beaucoup plus étroitement alignés avec leurs besoins.
Le modèle de données sert désormais essentiellement de couche d'abstraction, permettant aux utilisateurs finaux de visualiser les données du système source sans y accéder directement. Cette séparation signifie que vous pouvez fournir des données pertinentes à des utilisateurs spécifiques sans vous soucier des problèmes de gouvernance des données.
Lorsque vient le temps d'analyser les données livrées, les métadonnées peuvent être propagées vers n'importe quelle plateforme de BI où elles sont utilisées pour identifier les ensembles de données à importer via le modèle de données.
Un autre avantage important ici est l'agnosticisme de la plate-forme, car le modèle de données d'entreprise n'est pas codé en dur dans une base de données spécifique, il sert de schéma qui peut être lu et facilement répliqué dans n'importe quelle base de données sur le cloud ou sur site.
Enfin, si vous regardez la nature fluctuante rapidement des données d'entreprise, la possibilité de mettre à jour et de modifier les éléments de métadonnées dans le modèle de données est essentielle, vous permettant d'itérer rapidement et donc d'ajuster les pipelines de reporting en fonction des besoins actuels des utilisateurs métier.
Lorsque vous mettez tous ces éléments ensemble, vous parlez d'un processus rapide, agile et vraiment économe en ressources pour le développement d'entrepôts de données.
Vous voulez avoir un aperçu de la façon dont ces fonctionnalités peuvent dynamiser le développement de votre entrepôt de données ? Inscrivez-vous pour notre prochain webinaire, où des experts en produits et des initiés de l'industrie démontreront le potentiel de cette approche des meilleures pratiques. Vous pouvez également contactez-nous directement pour organiser une consultation en fonction de vos besoins actuels.
