Oppdater datamodellen slik at den fungerer bra med Copilot For Power BI
GJELDER FOR: Power BI Desktop Power Bi-tjeneste
Før du begynner å bruke Copilot den semantiske modellen, må du evaluere dataene. Du må kanskje gjøre noe oppryddingsarbeid på den semantiske modellen, slik at den Copilot kan få innsikt fra den.
Merk
- Administratoren må aktivere Copilot i Microsoft Fabric.
- F64- eller P1-kapasiteten må være i et av områdene som er oppført i denne artikkelen, stoffområdetilgjengelighet. Hvis den ikke er det, kan du ikke bruke Copilot.
- Administratoren må aktivere leierbryteren før du begynner å bruke Copilot. Se leierinnstillingene for artikkelen Copilot for mer informasjon.
- Hvis leieren eller kapasiteten er utenfor USA eller Frankrike, deaktiveres som standard med Copilot mindre leieradministratoren for Fabric aktiverer at dataene som sendes til Azure OpenAI, kan behandles utenfor tenantens geografiske område, samsvarsgrense eller nasjonale leierinnstilling for skyforekomst i administrasjonsportalen for stoff.
- Copilot i Microsoft Fabric støttes ikke på prøveversjon av SKU-er. Bare betalte SKU-er (F64 eller høyere, eller P1 eller høyere) støttes.
Vurderinger for datasett for Copilot bruk
Tabellen nedenfor viser vilkårene for å hjelpe deg med å opprette nøyaktige rapporter med Copilot. Disse elementene er anbefalinger som kan hjelpe deg med å generere nøyaktige Power BI-rapporter.
Element | Vurdering | Bekrivelse | Eksempel |
---|---|---|---|
Tabellkobling | Definer fjern relasjoner | Sørg for at alle relasjoner mellom tabeller er tydelig definerte og logiske, noe som angir hvilke som er én-til-mange, mange-til-en eller mange-til-mange. | «Salg»-tabell koblet til «Dato»-tabell etter DateID-felt. |
Measures | Standardisert beregningslogikk | Mål bør ha standardisert, klar beregningslogikk som er enkel å forklare og forstå. | "Totalt salg" beregnet som summen av "SaleAmount" fra "Salg"-tabellen. |
Measures | Navnekonvensjoner | Navn på mål bør tydelig gjenspeile beregningen og formålet. | Bruk «Average_Customer_Rating» i stedet for «Gjennomsnitt». |
Measures | Forhåndsdefinerte mål | Inkluder et sett med forhåndsdefinerte mål som brukere mest sannsynlig vil be om i rapporter. | «Year_To_Date_Sales», «Month_Over_Month_Growth» osv. |
Faktatabeller | Fjern avgrenselse | Tydelig avgrense faktatabeller, som inneholder de målbare, kvantitative dataene for analyse. | "Transaksjoner", "Salg", "Besøk". |
Dimensjonstabeller | Støttende beskrivende data | Opprett dimensjonstabeller som inneholder beskrivende attributter relatert til kvantitative mål i faktatabeller. | "Product_Details", "Customer_Information". |
Hierarkier | Logiske grupperinger | Opprett klare hierarkier i dataene, spesielt for dimensjonstabeller som kan brukes til å drille ned i rapporter. | Et «Tid»-hierarki som bryter ned fra «År» til «Kvartal» til «Måned» til «Dag». |
Kolonne- navn | Entydige etiketter | Kolonnenavn bør være entydige og selvforklarende, og unngå bruk av ID-er eller koder som krever ytterligere oppslag uten kontekst. | Bruk «Product_Name» i stedet for «ProdID». |
Kolonnedatatyper | Riktig og konsekvent | Bruk riktige og konsekvente datatyper for kolonner på tvers av alle tabeller for å sikre at målene beregnes riktig, og for å aktivere riktig sortering og filtrering. | Kontroller at numeriske kolonner som brukes i beregninger, ikke er angitt som tekstdatatyper. |
Relasjonstyper | Klart angitt | Hvis du vil sikre nøyaktig rapportgenerering, må du tydelig angi relasjonstypen (aktiv eller inaktiv) og kardinaliteten. | Merk om en relasjon er «én-til-én», «én-til-mange» eller «Mange-til-mange». |
Datakonsekvens | Standardiserte verdier | Vedlikehold standardiserte verdier i kolonner for å sikre konsekvens i filtre og rapportering. | Hvis du har en «Status»-kolonne, bruker du konsekvent «Åpne», «Lukket», «Venter» osv. |
KPI-er (Key Performance Indicators) | Forhåndsdefinert og relevant | Opprett et sett med KPI-er som er relevante for forretningskonteksten og som vanligvis brukes i rapporter. | "Avkastning på investering (AVKASTNING)", "Kundeanskaffelseskostnad (CAC)", "Levetidsverdi (LTV)". |
Oppdater tidsplaner | Gjennomsiktig og planlagt | Kommuniser tydelig oppdateringsplanene for dataene for å sikre at brukerne forstår aktualiteten til dataene de analyserer. | Angi om dataene er sanntid, daglige, ukentlige osv. |
Sikkerhet | Definisjoner på rollenivå | Definer sikkerhetsroller for ulike nivåer av datatilgang hvis det finnes sensitive elementer som ikke alle brukere skal se. | Medlemmer av salgsteamet kan se salgsdata, men ikke HR-data. |
Metadata | Dokumentasjon av struktur | Dokumenter strukturen til datamodellen, inkludert tabeller, kolonner, relasjoner og mål, for referanse. | En dataordliste eller et modelldiagram som er angitt som en referanse. |
Relatert innhold
Tilbakemeldinger
https://aka.ms/ContentUserFeedback.
Kommer snart: Gjennom 2024 faser vi ut GitHub Issues som tilbakemeldingsmekanisme for innhold, og erstatter det med et nytt system for tilbakemeldinger. Hvis du vil ha mer informasjon, kan du se:Send inn og vis tilbakemelding for