Modèle de donnée en étoile pour suivi industriel avec beaucoup (trop) de tag à suivre ?

Bonjour,

Je dois créer tes tableaux de suivi industriel dans PowerBI et je ne suis pas sûr de la structure qui doit être appliquée à mes données.

Mes données utilisées en intrant ont déjà été validées dans un genre d’entrepôt de donnée avec :

• Une table de production avec des millions d’enregistrements qui ressemble l’exemple ci-dessous (3 tags pour une date)
• Une table de référence pour les tags

Pièce jointe 485235

Points importants :

• Il y a plus de 100 tags qui ont tous la même granularité (valeurs quotidiennes)
• Ces tags ne sont pas vraiment reliés entre eux et sont uniques. La seule dimension utilisée est temporelle afin d’étudier leur variabilités mensuelles
• Il y a trois séries de données pour chaque tag (Actual, Budget et Forcast)
• Pour certains tags, je peux avoir la valeur quotidienne (D) ainsi que les valeurs MTD et YTD. Cela se retrouve pour des données complexes qui ont été dérivées en amont de l’entrepôt de donnée
• Je peux avoir de 3 à 9 valeurs quotidiennes pour un même tag

Quelle serait la meilleur structure pour travailler avec ces données ? J’avais pensé au modèle suivant mais je ne suis pas sûr du tout vu que c’est la première fois que je dois faire cela :

• 9 tables de fait avec une pour chaque combinaison "Time Serie - Corpo Type" (D-Actual ; D-Budget : etc ...)
• Les colonnes des tables de fait correspondent aux tags
• Une table de dimension temporelle avec des dates

Est-ce acceptable ou suis-je un hérétique qui court à sa perte ?

Merci.

Bonjour xla99,

Je ne connais pas Power BI. Je vais répondre uniquement sur l'aspect modélisation indépendamment de l'outil de restitution, en espérant que quelqu'un pourra te répondre sur d'éventuelles contraintes imposées par Power BI.

Il y a plusieurs solutions au problème. Le choix dépend du contexte et de l'utilisation de la base.
La solution que tu proposes est bonne si les conditions suivantes sont remplies :
- Les ajouts ou les suppressions de tags sont rares.
Chaque ajout ou suppression de tag nécessite une modification de la structure de la table de fait (ajout ou suppression de colonnes).
En général, aussi bien les SGBDR que les outils de restitution n'aiment pas trop.
- Les volumes et les temps de restitution nécessitent de retenir une solution optimisée.
Une structure plus proche de la source serait plus simple à créer et alimenter mais moins performante.
- Les restitutions mettent souvent cote à cote les données d'un grand nombre de tags différents
C'est ce critère qui justifie de mettre les tags en colonnes.
- Les restitutions mettent rarement cote à cote les données de "Corpo Type" (Actual, Budget et Forcast) différents
C'est ce critère qui justifie de mettre les "Time Serie - Corpo Type" dans des tables différentes.
D'après mon expérience cette affirmation est généralement fausse. On veut quasiment toujours mettre cote à cote le réalisé, le budget et les prévisions.

Un compromis entre simplicité de création/maintenance et performance pourrait être de faire une seule table de faits avec les colonnes :
Tag
Day
D-Actual
D-Budget
D-Forcast
MTD-Actual
MTD-Budget
MTD-Forcast
YTD-Actual
YTD-Budget
YTD-Forcast

Un plus pour la perf serait de partitionner par Tag.

Bonjour Pierre,

Merci pour la réponse.

Ok donc c'est bon car il n'y aura pas de changements de tags.

J'avais pensé à la solution avec une seule table de fait mais ce serait moins intuitif pour l'utilisateur final. Je voudrait éviter qu'il ait a appliquer des filtres sur les tags à chaque fois qu'il veut utiliser les données.

Merci.