Partager via

Conception du jeu de données de vues d’analytique

  • Article

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Chaque vue Analytics définit un jeu de données dans Power BI. Les jeux de données sont les tables et les propriétés utilisées pour créer des visualisations. Les jeux de données générés par Power BI Data Connector pour Azure DevOps présentent les caractéristiques suivantes :

  • Les entités et les champs associés disponibles dans Analytics sont aplatis (dénormalisés) dans une table unique. Par exemple, le nom d’utilisateur dans « Created By » est modélisé comme une chaîne (Nom d’utilisateur), plutôt que comme l’ID utilisateur. Il élimine la nécessité de créer des relations entre les tables pour créer des rapports.
  • Les données historiques sont modélisées sous forme d’instantanés pour chaque période, de sorte que la création de rapports de tendances est simple.

Pour plus d’informations sur Power BI et les jeux de données, consultez Power BI - Concepts de base pour service Power BI.

Aplatissement du point de terminaison OData Analytics

Le point de terminaison OData Analytics fournit une représentation normalisée des données Analytics. Les données sont normalisées principalement pour prendre en charge la création de rapports sur les relations « plusieurs-à-plusieurs » qui existent entre les données, telles que les éléments de travail et les balises associées.

Power BI Data Connector représente ces données sous la forme d’une table unique afin que les relations affichées dans notre modèle de données Analytics n’ont pas besoin d’être recréées dans Power BI. Cette représentation vous permet de filtrer immédiatement sur les champs complexes, tels que les balises d’élément de travail.

Le processus simplifie considérablement la mise en service et l’exécution de vos rapports. Toutefois, tous les champs disponibles via le point de terminaison OData Analytics ne sont pas disponibles pour la sélection dans une vue Analytics.

Champs sélectionnables dans les affichages Analytics

Les champs que vous pouvez sélectionner dans une vue Analytique correspondent aux champs de suivi de travail réguliers et aux champs de magasin de données Analytics.

Champs de suivi du travail

Vous pouvez sélectionner tous les champs de suivi du travail dans une vue Analytique, à l’exception des champs suivants :

  • Champs qui ne font pas partie du projet dans lequel la vue a été créée
  • Champs de texte long tels que Description, Historique et autres champs avec un type de données HTML
  • Champs de nombre de liens d’éléments de travail tels que ExternalLinkCount, HyperLinkCount, AttachedFileCount, RelatedLinkCount
  • Champs d’API REST spécifiques, tels que Filigrane, IsDeleted
  • Champs avec des relations plusieurs-à-plusieurs , tels que Team, Board Column, Board Name

Important

Les champs d’identité ou de nom de personne, tels que Créé par, Affecté à, etc., sont des champs sélectionnables, mais vous ne pouvez pas sélectionner ces champs pour l’instant en tant que critères de champ à des fins de filtrage des éléments de travail.

Pour obtenir une description de chaque champ de suivi d’élément de travail, consultez Informations de référence sur les entités et les propriétés pour Azure Boards.

Champs du magasin de données Analytics

Vous pouvez sélectionner les champs analytiques suivants dans une vue Analytics :

Champ Description
Durée de cycle Il est temps pour un élément de travail de passer d’une catégorie d’état « En cours » à « Terminé ».
Date (incluse automatiquement avec l’historique) Prend en charge l’affichage de l’historique quotidien, hebdomadaire ou mensuel de l’ensemble filtré d’éléments de travail.
Est actuel (inclus automatiquement avec l’historique) Prend en charge le filtrage des données pour afficher les instantané les plus récents de l’ensemble filtré d’éléments de travail en définissant la valeur sur True.
Delai Il est temps pour un élément de travail de passer d’une catégorie d’état « Proposé » à « Terminé ».
ID d’élément de travail parent ID d’élément de travail pour le parent d’un élément de travail.
Nom du projet Équivalent au champ de projet.
Révision Numéro assigné à la révision dans l'historique d'un élément de travail.
Étiquettes Liste de balises délimitées par des points-virgules.
WorkItemRevisionSK Clé unique Analytics pour la révision de l’élément de travail, utilisée pour joindre des entités associées.

Pour plus d’informations sur les catégories d’état, consultez États de flux de travail et catégories d’état. Pour plus d’informations sur le modèle de données Analytics, consultez Modèle de données pour Analytics.

Pour accéder à tous les autres champs disponibles via Analytics, incluez les clés de substitution (SK) ou l’ID d’élément de travail correspondants dans la vue Analytique. Créez ensuite les tables de mappage nécessaires en fonction de la propriété de navigation Analytics.

  • Itérations (ItérationSK)
  • Zones (AreaSK)
  • Teams (AreaSK - générer une table de mappage basée sur la propriété de navigation Teams )
  • BoardLocations (AreaSK - générer une table de mappage basée sur la propriété de navigation BoardLocations )
  • Dates (DateSK)
  • Process (AreaSK - générer une table de mappage basée sur la propriété de navigation du processus )
  • WorkItemLinks (ID d’élément de travail)

Relations des données

Il est essentiel de comprendre le modèle de données Analytics pour établir de bonnes relations entre les entités.

Par défaut, lorsque des données de base sont retournées à partir d’Analytics, les données sont liées comme indiqué dans la figure ci-dessous :

Relations d’entité

Les balises, teams et utilisateurs ne sont liés à aucune des autres données. Il est lié à la façon dont ces entités sont liées. Ils peuvent être liés de deux façons :

  • Relations plusieurs-à-plusieurs qui ne sont pas facilement gérées dans ces modèles
  • Il existe plusieurs relations entre les entités, comme entre les utilisateurs et les éléments de travail. Ils sont liés par :
    • Affecté à
    • Créé par
    • Modifié par
    • et ainsi de suite

Vous pouvez gérer plusieurs relations assez simplement. Par exemple, dans le modèle par défaut, vous pouvez modifier la requête, sélectionner la colonne AssignedTo de la table WorkItems et développer la colonne pour inclure toutes les données de la table Users . Vous pouvez également répéter ce processus pour les colonnes Created By et Changed By. Il vous permet d’avoir plusieurs liens d’une table à une autre, ce qui n’est pas autorisé.

Une autre raison de développer des colonnes de cette façon est de gérer les relations circulaires qui ne sont pas non plus autorisées. Par exemple, suivez le chemin suivant : Projects > Areas > Work Items > Projects. Il présente un problème circulaire typique. Que se passe-t-il si vous vouliez voir quelles ares faisaient partie d’un projet donné ? Le modèle tel qu’il est généré a des relations entre les zones et les éléments de travail et les projets et les éléments de travail, mais les projets ne peuvent pas être liés aux zones, car cela complète la relation circulaire et n’est donc pas autorisée. Pour gérer ce scénario, vous pouvez développer la colonne Project dans la table Areas. Pour cela, procédez comme suit :

  1. Sélectionnez Modifier les requêtes sous l’onglet Accueil.

  2. Sélectionnez la requête Zones.

  3. Faites défiler jusqu’à la colonne Project (la dernière colonne) et sélectionnez l’icône Développer en haut de la colonne.

    Requête zones, colonne de projet

  4. Décochez toutes les colonnes à l’exception de ProjectName et sélectionnez OK.

    Développer les options du projet

Vous pouvez maintenant répertorier les zones par projet et obtenir un nombre de zones dans chaque projet.