Free Press

La modélisation dimensionnelle (DM) fait partie de la méthodologie Business Dimensional Lifecycle développée par Ralph Kimball qui comprend un ensemble de méthodes, de techniques et de concepts à utiliser dans la conception des entrepôts de données. L’approche se concentre sur l’identification des processus métier clés au sein d’une entreprise et sur la modélisation et la mise en œuvre de ceux-ci en premier lieu avant d’ajouter des processus métier supplémentaires, une approche ascendante.

Quels sont les objectifs de la modélisation des entrepôts de données ?

Les objectifs, énoncés par Ross et Kimball, sont simples :

• rendre l’information facilement accessible
• présenter l’information de manière cohérente
• adaptable et réceptive au changement
• présenter l’information en temps opportun
• protéger les actifs d’information

.

• servir de base faisant autorité et digne de confiance pour améliorer la prise de décision (source unique de vérité dans le langage de l’ingénierie des données)
• les VIP doivent accepter votre système

Si vous avez travaillé sur ou utilisé un système ETL, vous auriez remarqué que la cohérence des informations est obtenue par des mesures conformes, la rapidité fournie par les cycles ETL et l’adaptabilité dépend aussi largement de la conception de l’ETL.

Pourquoi la modélisation ?

En tant qu’ingénieur de données, vous connaissez très bien le SQL et pouvez probablement écrire des requêtes SQL pour toute la journée. Mais vous ne pouvez pas supposer que l’utilisateur final typique sera un expert en écriture de requêtes SQL. Donc, notre objectif est de construire un DW si facile pour les analystes d’écrire des requêtes d’analyse rapidement et efficacement.

Ce que vous ne voudriez pas que vos analystes fassent :

• Requêtes basées sur l’ID
• Jointes externes en cascade(même vous ne voudriez pas faire cela)
• Sous-requêtes multiples groupées ou jointes
• sous-requêtes récursives(visitez simplement Hackerrank SQL et vous comprendriez la douleur)
• Corrélation de sous-requêtes : récupérer des données sur plusieurs colonnes dans différentes sous-requêtes
• Joints sans PK/FK : même pour moi(1.5 ans d’expérience DE), c’est difficile à visualiser.

Ce que vous pourriez et devriez attendre de vos analystes :

• des jointures simples
• des colonnes avec des noms et du texte complet
• des agrégations simples
• des fonctions analytiques fenêtrées
• DISTINCT

Notez que les points ci-dessus ne sont pas les plus faciles et que votre système devrait être suffisamment évolutif pour tous ces types de requêtes.

Les bases de données OLTP sont transformées en faits et dimensions en raison des objectifs susmentionnés.

Transition des bases de données transactionnelles vers les faits

La plupart des entreprises mesurent leur succès et leur efficacité en mesurant certains types de données. Ces données capturent les activités et les progrès réels de l’entreprise. Ces données sont appelées des faits.

Les bases de données orientées OLTP enregistrent les transactions à la fois, un peu comme le streaming d’événements mais centralisé autour des transactions. Le DW est différent. Le DW n’a pas besoin d’enregistrer les détails au niveau transactionnel. Le DW a besoin d’avoir des faits à travers différents critères de votre entreprise. Le DW doit agréger (ou laisser les analystes agréger) les informations requises pour améliorer l’activité. Et donc, la redondance est un péché impardonnable dans le DW.

Que sont les mesures et pourquoi devriez-vous remplir vos tables de faits avec elles ?

Dans un entrepôt de données, une mesure est une propriété sur laquelle des calculs peuvent être effectués.

Les faits que nous dérivons des magasins de données opérationnelles viennent avec certaines données supplémentaires qui sont généralement additionnées dans notre analyse. Ce sont les aspects d’un fait qui permettent à l’analyste, ou au cadre qui consulte l’analyse, de voir la valeur du fait.

Pourquoi avez-vous besoin de maintenir un grain cohérent ?

Pour que vous puissiez vous assurer que votre système peut légitimement corréler et agréger entre les faits.

Mais il n’est pas toujours possible d’avoir des données à des niveaux atomiques. Donc, pour combler cette lacune, il existe deux méthodes :

• Tables de faits instantanés périodiques
• Tables de faits instantanés accumulatifs

Tables de faits instantanés périodiques

Comme leur nom l’indique, elles sont collectées à intervalles de temps réguliers. La consommation de gaz, l’audit et les inspections sont quelques exemples de collecte de données pour lesquelles les instantanés périodiques sont activés.

Tables de faits d’instantanés cumulatifs

Lorsqu’un indicateur de performance d’entreprise est un taux d’achèvement d’un processus d’entreprise à plusieurs étapes, vous pouvez vouloir capturer au grain de l’intégralité du processus et enregistrer le début, l’achèvement et les étapes intermédiaires. Il peut s’agir d’une transaction, mais il y a beaucoup de mesures entre les deux. Ainsi, vous utilisez des tableaux de faits d’instantanés cumulés pour répondre à des questions complexes dans le domaine de la veille économique, où il y a du temps entre les faits. Un bon exemple serait une ligne de table de faits de votre commande d’un sandwich au poulet et la ligne de table de faits du sac remis par la fenêtre de la voiture au drive-thru de McDonald’s.

Localiser les faits via les dimensions

Vous et vos analystes devez savoir comment interroger et filtrer les faits pour en tirer de la business intelligence. Cet objectif est servi par les dimensions.

Dessiner des dimensions à partir de données de référence et de méta données brutes

Les dimensions sont presque toujours créées avec une clé de substitution ; la clé de substitution, naturellement, est référencée par la ou les clés étrangères dans la table des faits. Nous interrogeons la table en recherchant les dimensions qui nous intéressent. Toutes les autres données décrivant nos faits, comme les horodatages, les agents clients, l’emplacement du magasin, le produit et le client sont ce que nous transformons en dimensions.

La beauté de la modélisation dimensionnelle est que les faits ne sont pas définis par les clés primaires ou toute sorte d’identifiant unique, au lieu de cela, ils sont définis par la combinaison des dimensions. Cela donne lieu à Star Schema.

Il est très important que nous ayons une unicité dans nos dimensions. En effet, lors des requêtes sur les faits, les doublons entre les combinaisons de dimensions se transformeront en désastre. Si vous ne pouvez pas, alors ajouter ou agréger des dimensions pour les rendre uniques.

Hiérarchie dans les dimensions

Considérez les deux images suivantes.

Un analyste aura la vie facile si vous lui configurez la deuxième table de dimension.

Donc, avec la deuxième table, vous avez la hiérarchie suivante :

Il existe toutes sortes de hiérarchies – hiérarchies multiples, hiérarchie unique, etc. Je ne les aborde pas dans ce billet de blog.

Une chose que je voudrais souligner est que la dimension temporelle est une vraie douleur dans le cou. Il faut s’occuper des jours magiques, du calendrier fiscal, des fuseaux horaires, des cycles(type bénéfice sur trimestre). Et ne soyez pas trop confiant dans ce domaine, même les bases de données de séries temporelles ne vous aideront pas dans les hiérarchies si votre ETL est défaillant. Vous pourriez vouloir jeter un coup d’œil aux dimensions Outrigger. Il arrive également qu’une dimension dépende naturellement d’une autre. Dans un tel cas, les concepteurs peuvent mettre une clé étrangère de l’une à l’autre. C’est ce qui constitue une « dimension externe ». Dans les dimensions de calendrier, c’est très courant.

Vous ne pouvez pas utiliser une date à un grain différent dans un outrigger des dates que vous utilisez dans la table de faits. Vous ne pouvez pas autoriser l’agrégation sur des dimensions d’outrigger. Si nécessaire, masquez les valeurs numériques dans l’outrigger avec des préfixes ou des suffixes textuels pour y faire obstacle.

Modification lente des dimensions

Même si j’aimerais écrire à ce sujet, je pense toujours qu’il est préférable pour mes lecteurs de comprendre ce concept en profondeur à partir d’ici.

Je ne discute pas des dimensions Snowflake mais juste pour signaler qu’elles sont toujours utilisées avec les bases de données OLAP.

Intégrez vos Big Data dans votre système ETL

Vous traiterez vos Big Data tabulaires comme ayant été acquises par l’une de vos phases d’extraction standard. Ainsi, vous lui appliquerez les mêmes étapes que celles de la transformation :

1. Nettoyage des données
2. Conformité des unités et des formats
3. Dédoublonnage
4. Restructuration
5. Stadification

Résumé

Je voulais comprendre les aspects théoriques de la conception de bases de données, ce qui m’a conduit à lire le livre, Ross et Kimball. J’ai ensuite eu la curiosité d’établir des différences et des analogies entre leurs méthodes et celles des principales entreprises d’aujourd’hui axées sur les données, comme Netflix, Airbnb, Uber, etc.

Dans cette quête, je peux équitablement dire que le format structuré de la modélisation dimensionnelle est préféré à un simple ETL hardcore. Parce que de cette façon, vous supprimez la dépendance à votre égard, votre équipe BI ne vous sonne pas sur Slack pour créer un nouveau DAG pour chaque autre insight, au lieu de cela, avec une modélisation correcte, vous leur permettez d’agir et d’explorer librement sans votre besoin.

Veuillez laisser des commentaires sur la façon dont je pourrais m’améliorer, je suis sûr que ce n’était pas votre meilleure lecture. Merci pour votre temps.

Notes de bas de page

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross et Kimball, ch 2 et ch 18

Kimball/Ross pp103-109