Mettre à jour votre modèle de données pour qu’il fonctionne correctement avec Copilot pour Power BI
S’APPLIQUE À : 
Power BI Desktop 
Service Power BI
Avant de commencer à utiliser Copilot avec votre modèle sémantique, évaluez vos données. Vous devrez peut-être effectuer un travail de nettoyage sur votre modèle sémantique afin que Copilot puisse en déduire des insights.
Remarque
- Votre administrateur doit activer Copilot dans Microsoft Fabric.
- Votre capacité F64 ou P1 doit se trouver dans une des régions répertoriées dans cet article, Disponibilité des régions Fabric. Si ce n’est pas le cas, vous ne pouvez pas utiliser Copilot.
- Avant de commencer à utiliser Copilot, votre administrateur doit activer le commutateur de locataire. Pour obtenir plus d’informations, consultez l’article Paramètres du locataire Copilot.
- Copilot est désactivé par défaut si votre locataire ou votre capacité sont situés en dehors des États-Unis ou de la France, à moins que l’administrateur de votre locataire Fabric n’active le paramètre de locataire Les données envoyées à Azure OpenAI peuvent être traitées en dehors de la région géographique de votre locataire, de la limite de conformité ou de l’instance du cloud national dans le portail d’administration de Fabric.
- Copilot dans Microsoft Fabric n’est pas pris en charge sur les références SKU d’essais gratuits. Seules les références SKU payantes (F64 ou ultérieures, ou P1 ou version ultérieure) sont prises en charge.
Considérations relatives aux modèles sémantiques à Copilot utiliser
La table suivante répertorie les critères qui vous aident à créer des rapports précis avec Copilot. Ces éléments sont des recommandations qui peuvent vous aider à générer des rapports Power BI précis.
| Élément | Considération | Description | Exemple |
|---|---|---|---|
| Liaison de tables | Définir des relations claires | Assurez-vous que toutes les relations entre les tables sont clairement définies et logiques, indiquant celles qui sont une-à-plusieurs, plusieurs-à-une ou plusieurs-à-plusieurs. | Table « Ventes » connectée à la table « Date » par le champ « DateID ». |
| Mesures | Logique de calcul standardisée | La logique de calcul des mesures doit être standardisée, claire, facile à expliquer et à comprendre. | « Total des ventes » est calculé comme la somme de « SaleAmount » de la table « Ventes ». |
| Mesures | Conventions d'affectation de noms | Les noms des mesures doivent clairement refléter leur calcul et leur objectif. | Utilisez « Average_Customer_Rating » plutôt que « AvgRating ». |
| Mesures | Mesures prédéfinies | Incluez un ensemble de mesures prédéfinies que les utilisateurs demanderont certainement à inclure dans les rapports. | « Year_To_Date_Sales », « Month_Over_Month_Growth », etc. |
| Tables de faits | Effacer la délimitation | Délimitez clairement les tables de faits, qui contiennent les données quantitatives mesurables à des fins d’analyse. | « Transactions », « Ventes », « Visites ». |
| Tables de dimension | Données descriptives en soutien | Créez des tables de dimension qui contiennent les attributs descriptifs liés aux mesures quantitatives dans les tables de faits. | « Product_Details », « Customer_Information ». |
| Hiérarchies | Regroupements logiques | Établissez des hiérarchies claires dans les données, en particulier pour les tables de dimension qui peuvent être utilisées pour explorer les rapports. | Une hiérarchie de « Période » qui se décompose en « Année » « Trimestre », « Mois » et « Jour ». |
| Noms des colonnes | Étiquettes non ambiguës | Les noms de colonnes doivent être non ambigus et explicites, évitant ainsi l’utilisation d’ID ou de codes qui nécessitent une recherche supplémentaire sans contexte. | Utilisez « Product_Name » plutôt que « ProdID ». |
| Types de données de colonne | Correct et cohérent | Appliquez des types de données corrects et cohérents pour les colonnes de toutes les tables pour vous assurer que les mesures sont calculées correctement et pour activer le tri et le filtrage appropriés. | Vérifiez que les colonnes numériques utilisées dans les calculs ne sont pas définies en tant que types de données texte. |
| Types de relation | Clairement spécifié | Pour garantir une génération de rapport précise, spécifiez clairement la nature des relations (actives ou inactives) et leur cardinalité. | Indiquez si une relation est « une-à-une », « une-à-plusieurs » ou « plusieurs à plusieurs ». |
| Cohérence des données | Valeurs standardisées | Conservez des valeurs standardisées dans les colonnes pour garantir la cohérence entre les filtres et les rapports. | Si vous avez une colonne « État », utilisez « Ouvert », « Fermé », « En attente » etc. de manière cohérente. |
| Des indicateurs de performance clés (KPI) | Prédéfini et pertinent | Établissez un ensemble d’indicateurs de performance clés pertinents pour le contexte métier et qui sont couramment utilisés dans les rapports. | « Retour sur investissement (ROI) », « Coût d’acquisition du client (CAC) », « Valeur de durée de vie (LTV) ». |
| Calendriers d’actualisation | Transparent et planifié | Communiquez clairement les planifications d’actualisation des données pour vous assurer que les utilisateurs comprennent les chronologies des données qu’ils analysent. | Indiquez si les données sont en temps réel, quotidiennes, hebdomadaires, etc. |
| Sécurité | Définitions au niveau du rôle | Définissez des rôles de sécurité pour différents niveaux d’accès aux données s’il existe des éléments sensibles que tous les utilisateurs ne doivent pas voir. | Les membres de l’équipe commerciale peuvent voir les données de ventes, mais pas les données RH. |
| Métadonnées | Documentation de la structure | Documentez la structure du modèle de données, y compris les tables, les colonnes, les relations et les mesures, pour référence. | Un dictionnaire de données ou un diagramme de modèle fourni en tant que référence. |
Le tableau suivant répertorie des critères supplémentaires pour vous aider à créer des requêtes DAX précises avec Copilot. Ces éléments sont des recommandations qui peuvent vous aider à générer des requêtes DAX précises.
| Élément | Considération | Description | Exemple |
|---|---|---|---|
| Mesures, tables et colonnes | Descriptions | Incluez ce qu’il est et comment vous envisagez d’utiliser chaque élément dans la propriété description. Remarque : seuls les 200 premiers caractères sont utilisés. | [YOY Sales] description peut être « La différence d’année sur année (YOY) dans les commandes. Utilisez la colonne « Date » [Année] pour afficher les années autres que la dernière année. Les années partielles seront comparées à la même période de l’année précédente. |
| Groupes de calcul | Descriptions | Les éléments de calcul ne sont pas inclus dans les métadonnées du modèle. Utilisez la description de la colonne du groupe de calcul pour répertorier et expliquer l’utilisation des éléments de calcul. Remarque : seuls les 200 premiers caractères sont utilisés. | Par exemple, l’exemple de colonne de groupe de calcul Time Intelligence peut avoir cette description : « Utiliser avec des mesures & table de dates pour Current : current value, MTD : month to date, QTD : quarter to date, YTD : year to date, PY : prior year, PY MTD, PY QTD, YOY : year over year change, YOY% : YOY% : YOY as a % » et sur une table avec des mesures peut étendre l’utilisation d’une description telle que « Mesures sont utilisées pour agréger des données. Ces mesures peuvent être affichées sous la forme d’une année à l’autre à l’aide de cette syntaxe CALCULATE([Nom de mesure], 'Time intelligence'[Time calculation] = « YOY ») » |