Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre à l'essai
    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



    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.

  2. #2
    Candidat au Club
    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.

  3. #3
    Membre à l'essai
    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.