Projet : Modélisation d’un Data Warehouse

Contexte : Mon client travail dans le domaine des échanges de marchandises et ressources primaires et son métier repose sur l’utilisation de différents outils informatiques pour faire ses affaires. Dans le but de consolider ses données afin de pouvoir générer des rapports d’activités globaux, dbi-Services a été sollicité pour réaliser un Data Warehouse (DWH) et d’aider à la mise en place d’un processus d’intégration de données.

Confidentialité : Très Haute. Ce niveau de confidentialité m’oblige à anonymiser l’ensemble des modèles de données que je vais vous présenter.

Environnement de travail :

• Les différents outils de production du client
• SQL Server Management Studio
• DBSchema
• Azure SQL Data Warehouse
• Azure Synapse pipeline
• Power BI

Durée du projet : une 30aine de jours

Etude de l’existant :

Prise en main du métier : Dans un premier temps, afin de comprendre au mieux le métier, il a d’abord été nécessaire de voir le contexte du client. Pour ce faire, une démo de l’outil principal m’a été faite par le développeur principale ainsi que des discussions avec les utilisateurs m’ont permis de mieux cerner ce métier qui m’était inconnu jusqu’à présent.

Modélisation OLTP de l’outil principal : Au fur et à mesure de la découverte de l’outil, je découvrais en parallèle le modèle de données sur lequel il reposait.

• Comme expliqué plus haut, j’ai dû anonymiser le plus possible le modèle de mon client pour respecter les clauses de confidentialité signées lors de mon entrée.
• Ainsi, je ne peux montrer que le schéma dans son ensemble et non en détail. Il en sera de même pour le DWH.

Les besoins métiers

Le modèle ci-dessus ainsi que l’étude du métier, m’a permis d’identifier les points clés de l’outil.

• Quels sont les éléments d’activités principaux de mon client ? (KPI)
• Quel est le niveau de granularité dont mon client a besoin afin de constituer des rapports solides et parlants ?
• Quelles sont les données clés dont mon client a besoin dans ses futurs rapports ?

Il m’est bien souvent demandé de générer des modélisations sans forcément que le client ait une idée précise de ses besoins. Dans ce cas, mon client avait une idée déjà précise de son besoin final. Nous avons eu de longues discussions sur ce qui était faisable ou non.

Dans le cadre du projet, j’ai travaillé en étroite collaboration avec le responsable du développement. L’idée était de lui donner toutes les base de mon métier, pour qu’il puisse maintenir ce projet au quotidien. Bien-entendu, je reste à sa disposition en cas de souci majeur.

Design des tables de faits :

Basé sur le modèle OLTP ainsi que sur les nombreuses discussions avec mon client, J’ai pu identifier, dans un premier temps, 3 tables de faits.

• Afin de répondre à une demande précise, ainsi que des contraintes métier, j’ai pris la décision de séparer certaines tables de faits même si elles semblaient être « identiques » de premier abord.

J’ai pu identifier 7 Points clés métier qui nous serviront de tables de faits.

Chacun de ces points clés sera transformé en table de fait. Même si elles sembles porter les mêmes informations, Afin de répondre à des exigences de performances et de ségrégation de l’information, J’ai opté pour une constellation autour de ces 7 tables de faits.

La base source de mon clients contient des centaines de millions de lignes sur ces tables principales. Sachant qu’il y a un impératif, le Cloud, afin de réduire au maximum les coûts, ie : Avoir des tables plus petites pour ne pas monter en gamme d’abonnement.

Chacune des tables de faits représente un type d’achat différents pour mon client. Nous aurions pu avoir une dimension contenant la liste des produits, cependant, cela ne représente pas assez bien son métier. Chaque élément est indépendant et chaque échange sur type de produit est un fait en lui-même.

Design des dimensions :

Une fois identifié les différentes tables de faits, il est essentiel d’identifier l’ensemble de ses éléments constitutifs. Les dimensions.

Comme vous pouvez le voir sur le modèle au-dessus, il y a une dizaine de dimensions et entre 1 et 4 liaison par table

• La dimensions date est très utilisée dans le cadre métier de mon client et il peut y avoir jusqu’à 6 liens ( entre les date de création des lignes dans l’outil au date d’achats et de livraisons ) Cette dimension est un pilier des besoin client.
• A noter que ceci est un phénomène récurrent dans la plupart des DWH, à quelques exceptions près.

Un modèle OLTP repose sur un concept de relations entre tables et de contraintes d’intégrités fortes. Ceci dans le but de pouvoir assurer une performance sur de petites transactions contenant moins d’informations.

Note :

Dans le cadre d’un DWH, nous n’avons pas le même genre de contraintes. Nous traitons les données en masse, et selon les objectifs du client, une à plusieurs fois par jour. La mise en place d’une dimension dans un DWH repose sur notre capacité à identifier les éléments pouvant être regroupés en une seule table.

Nous nous basons sur un modèle OLTP assez simple à lire. Malgré quelques erreurs de modélisation, il nous est clairement possible d’identifier les faits et les dimensions en quelques lectures. Ceci nous a permis de nous concentrer sur d’autres sujets.

L’utilisation de DB Schema nous a aussi grandement simplifié la tâche. En effet, le concept de layout nous permet de travailler sur un DWH global, mais de n’afficher que les informations relatives à une activité (Dans notre cas un layout par table de fait et ses dimsensions associées).

Au final nous avons 7 tables de faits, et une 30aine de dimensions. La modélisation d’une constellation prends une toute autre forme grâce à cet outil.

Relations entre dimensions et faits

Comme vu au-dessus, nous avons identifié 30 dimensions, dans notre schéma, nous n’en présentons que 14. C’est un des éléments, outre le modèle OLTP d’origine, qui m’a poussé a créer 7 tables de faits. Certaines informations sont communes à tous les faits. Mais au final, une seule table de faits, contenant des liens sur les 30 dimensions auraient rendu l’exploitation bien trop complexe et la gestion du modèle sur un outil comme PowerBI s’en retrouve simplifié.

• Un schéma en étoile par table de fait correspond au modèle pour un shared DataSet dans PBI Online

Nous verrons dans un prochain blog la mise en place du processus d’intégration de données via un ETL.