IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Conception/Modélisation Discussion :

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


Sujet :

Conception/Modélisation

  1. #1
    Membre à l'essai
    Inscrit en
    Décembre 2002
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Décembre 2002
    Messages : 22
    Points : 19
    Points
    19
    Par défaut 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

    Nom : 2019-06-20 16-20-21.jpg
Affichages : 395
Taille : 101,3 Ko

    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
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2019
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2019
    Messages : 2
    Points : 4
    Points
    4
    Par défaut
    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
    Inscrit en
    Décembre 2002
    Messages
    22
    Détails du profil
    Informations forums :
    Inscription : Décembre 2002
    Messages : 22
    Points : 19
    Points
    19
    Par défaut
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [MCD] Quel modèle de données pour référencer un couple ?
    Par Laskar dans le forum Schéma
    Réponses: 2
    Dernier message: 21/04/2012, 13h18
  2. Modèle pour suivi des temps de travail
    Par giguoin dans le forum ALM
    Réponses: 5
    Dernier message: 16/05/2011, 12h03
  3. Pas de données en sortie pour ma table avec sqlserver
    Par Mandrake31 dans le forum Développement
    Réponses: 5
    Dernier message: 06/02/2009, 23h36
  4. quel modèle de données pour une carte 2d/3d?
    Par kain_tn dans le forum Développement 2D, 3D et Jeux
    Réponses: 6
    Dernier message: 23/01/2008, 18h00
  5. Méthode de développement pour le modèle de données
    Par onlytoine dans le forum Ruby on Rails
    Réponses: 2
    Dernier message: 07/11/2007, 18h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo