Merge Queries vs Relations in Model

Accueil – Le CFO masqué Forums Power Query Merge Queries vs Relations in Model

4 sujets de 1 à 4 (sur un total de 4)
  • Auteur
    Articles
  • #59919
    FraNoiseux
    Participant

    Bonjour,
    1- j’aimerais savoir quel est la “Best Practices” d’aller chercher des informations de champs dans d’autres Tables entre un Merge Queries dans Power Query et faire une Relation dans le Model du Frontend ?

    2- Dans les Relations de Model, Je n’ai pas réussi a lier 2 sources avec 2 champs a la fois pour avoir une clé unique… pourquoi ? et comment le faire ? Car avec le Merge Queries c’est simple.

    • Ce sujet a été modifié le il y a 11 mois et 1 semaine par FraNoiseux.
    #59921
    Sophie Marchand
    Participant

    Bonjour,

    Votre première question est complexe. Elle est entièrement répondue dans notre formation Excel – Introduction à Power Pivot et aux modèles de données: https://www.lecfomasque.com/formations/formations-en-entreprise/excel-introduction-a-power-pivot-et-aux-modeles-de-donnees/. On voit notamment dans cette formation tout le concept de “normalisation de données”, essentielle à l’utilisation de Power BI.

    On enseigne aussi graduellement les concepts de modélisation de données dans nos formations Power BI niveau 2, Power BI niveau 3 et Introduction au langage DAX.

    Mais pour répondre brièvement, voici certaines choses à savoir:

    D’abord, Power Query est un outil ETL, qui sert à préparer les données pour la modélisation. Parfois, il faut fusionner des tables entre elles pour créer une table de faits ou une table de dimensions. Dans ces cas-là, on va utiliser Power Query.

    Mais au final, on vise à créer un modèle de données avec des tables de faits (tables transactionnelles) et des tables de dimensions. Le modèle de données, notamment en étoile, va régler tout problème potentiel de performance. Par exemple, au lieu d’avoir une table de ventes par transaction avec une colonne “Nom client”, “Adresse client”, “Courriel client”, etc. Je vais avoir une table de ventes avec une colonne “ID Client” et dans une table de dimensions, j’aurai toutes les informations du clients, qui ne seront pas inutilement répétées. Je ferai alors une liaison sur le champ “ID client” des deux tables. Autrement, en les intégrant dans la table de faits, je vais alourdir inutilement cette table et la table de faits, par définition, c’est une table qui comprend des transactions et elle sera donc volumineuse.

    Et au-delà des problèmes de performance, il y a aussi toute la logique du langage DAX, qui s’applique à des modèles de données plutôt qu’à une grosse table plate. Par exemple, tout modèle de données aura au minimum une table de faits et une table de dates. C’est ce qui permettra d’utiliser les fonctions DAX de Time Intelligence pour créer des mesures comme “les ventes cumulées” ou encore “les ventes de l’année précédente à la même date”, etc.

    Quand vous allez évoluer dans votre apprentissange, ces notions deviendront de plus en plus concrètes. Si vous décidez de ne pas suivre cette voie, vous constaterez assez rapidement, que vous serez bloqué quand vous allez vouloir construire des visualisations un peu plus avancées.

    Pour ce qui est de votre deuxième question, les relations entre les tables d’un modèle de données se font uniquement à partir d’une colonne unique. Si vous voulez fournir un exemple de ce que vous avez fait, je pourrai vous répondre plus concrètement, sur la base de vos données.

    Merci.

    Sophie

    #59964
    philippe.muniesa
    Participant

    Bonjour,

    En France (et peut-être ailleurs), le modèle de fichiers transmis aux administrations (principalement) est souvent un fichier .TXT ne contenant que deux colonnes:
    – Un numéro d’identifiant ou rubrique.
    – une Variable attachée à la rubrique.

    Je pense que ce modèle de fichier imposé est lié aux systèmes d’exploitation des ordinateurs (AS400 et autres) qui exploitent les données transmises.

    Le suite de rubriques se répète autant de fois qu’il y a d’enregistrements.

    Ex: une première série de rubriques propres au déclarant.
    S01 , Nom du déclarant
    S01 , Num identification Déclarant
    S03 , Adresse déclarant

    Suivie d’une ou plusieurs séries répétitives de rubriques correspondant aux éléments déclarés.

    R01 , Nom première personne
    R01 , Prénom première personne
    R03 , Num Securité social première personne
    R04 , Rémunération Brute Première personne
    etc…

    R01 , Nom deuxième personne
    R01 , Prénom deuxième personne
    R03 , Num Securité social deuxième personne
    R04 , Rémunération Brute deuxième personne
    ETC..
    ..

    R01 , Nom énième personne
    R01 , Prénom énième personne
    R03 , Num Securité social énième personne
    R04 , Rémunération Brute énième personne

    Y aurait-il dans PowerQuery une technique permettant de présenter ce type de fichier en colonne ?

    R01 R02 R03 R04
    nom 1er P P1 Nss 1 Rem 1
    nom 2 em P P2 Nss 2 Rem 2


    nom Nième P Pn Nss n Rem n

    Et en fait à chaque fois qu’une rubrique finit par 001, on sait qu’il s’agit d’un nouvel enregistrement.

    Je joins un fichier source à titre d’exemple, dont j’ai changé des caractères par d’autres afin de préserver la confidentialité.

    J’ai de mon côté essayé plusieurs manipulations, mais je ne vois pas.
    Je voulais éviter un code VBA pour transformer ces données et les mettre sous forme de tableau pour pouvoir les exploiter.

    Merci d’avance.

    Cordialement

    Attachments:
    You must be logged in to view attached files.
    #59966
    Sophie Marchand
    Participant

    Bonjour,

    Je ne suis pas certaine d’avoir tout compris vos expliations à l’égard de vos données, mais je vous propose une approche, selon ma compréhension. Si le résultat n’est pas celui désiré, merci de me fournir une image du résultat désiré (les quelques premières lignes et colonnes notamment).

    Au plaisir,

    Sophie

    Attachments:
    You must be logged in to view attached files.
4 sujets de 1 à 4 (sur un total de 4)
  • Vous devez être connecté pour répondre à ce sujet.