Anbefalte fremgangsmåter for å optimalisere spørsmål og svar i Power BI

Det er kraftig å bruke vanlige uttrykk og naturlig språk til å stille spørsmål om dataene dine. Det er enda kraftigere når dataene svarer, og det er det Q&A-funksjonen i Power BI gjør.

Hvis du vil at spørsmål og svar skal kunne tolke den store samlingen av spørsmål den er i stand til å svare på, gjør spørsmål og svar antagelser om modellen. Hvis strukturen i modellen ikke oppfyller én eller flere av disse forutsetningene, må du justere modellen. Disse justeringene for spørsmål og svar er de samme optimaliseringene for anbefalte fremgangsmåter for alle modeller i Power BI, uavhengig av om du bruker spørsmål og svar.

Bruk Q&A-verktøy til å rette opp spørsmålene dine

I de følgende avsnittene beskriver vi hvordan du justerer modellen slik at den fungerer bra med Q&A i Power BI. Med Q&A-verktøy lærer du kjernebedriftsvilkårene dine til spørsmål og svar og løser spørsmål sluttbrukerne stiller. Noen ganger kan spørsmål fremdeles ikke løses fordi dataene er formet feil eller data mangler. I dette tilfellet kan du lese følgende inndelinger for å hjelpe deg med å optimalisere spørsmål og svar. Hvis du vil ha mer informasjon, kan du se Introduksjon til Q&A-verktøy.

Legge til manglende relasjoner

Hvis modellen mangler relasjoner mellom tabeller, kan ikke Power BI-rapporter og spørsmål og svar tolke hvordan du kobler sammen disse tabellene. Relasjoner er hjørnesteinen i en god modell. Du kan for eksempel ikke be om totalt salg for Seattle-kunder hvis relasjonen mellom ordretabellen og kundetabellen mangler. Følgende bilder viser en modell som trenger arbeid og en modell som er klar for spørsmål og svar.

Trenger arbeid

I det første bildet er det ingen relasjoner mellom tabellene Kunder, Salg og Produkter.

Screenshot showing Customers, Sales, and Products tables with no connected relationships.

Klar for spørsmål og svar

I det andre bildet defineres relasjoner mellom tabellene.

Screenshot showing Customers, Sales, and Products tables with interconnected relationships.

Gi nytt navn til tabeller og kolonner

Valg av tabeller og kolonner er viktig for spørsmål og svar. La oss for eksempel si at du har en tabell kalt CustomerSummary som inneholder en liste over kundene dine. Du må stille et spørsmål som «List opp kundesammendragene i Chicago» i stedet for «List opp kundene i Chicago».

Selv om spørsmål og svar kan gjøre noen grunnleggende ordbrudd og oppdage flertall, antar Spørsmål og svar at tabell- og kolonnenavnene nøyaktig gjenspeiler innholdet.

Et annet eksempel kan være hvis du har en tabell med navnet Antall ansatte som inneholder for- og etternavn og ansattnumre. Du har en annen tabell med navnet Ansatte som inneholder ansattnumre, jobbnumre og startdatoer. Folk som er kjent med modellen, forstår kanskje denne strukturen. Noen andre som spør «tell de ansatte» kommer til å få et antall rader fra «Ansatte»-tabellen. Dette resultatet er sannsynligvis ikke det de hadde i tankene, fordi det er en telling av hver jobb hver ansatt noensinne har hatt. Det er bedre å gi nytt navn til disse tabellene for å gjenspeile det de inneholder.

Trenger arbeid

Tabellnavn som StoreInfo og Produktliste må fungere.

Screenshot showing examples of table names that aren't optimal for Q and A.

Klar for spørsmål og svar

Tabeller med navnet Store og Produkter fungerer bedre.

Screenshot showing examples of table names that are optimal for Q and A.

Løse feil datatyper

Importerte data kan ha feil datatyper. Spesielt tolkes ikke dato - og tallkolonner som importeres som strenger , av Q&A som datoer og tall. Velg riktig datatype i Power BI-modellen.

Screenshot showing the Formatting panel with the Data type and Date time format selected.

Endre kolonneinnstillingene for år og identifikator

Power BI aggregerer numeriske kolonner som standard, slik at spørsmål som «totalt salg etter år» noen ganger kan resultere i en total salgssum sammen med en totalsum på år. Hvis du har bestemte kolonner der du ikke vil at Power BI skal vise denne virkemåten, angir du standard summarization-egenskapen for kolonnen til Ikke oppsummer. Vær oppmerksom på kolonnene År, Måned, Dag og ID , da disse kolonnene er de vanligste problemene. Andre kolonner som ikke er fornuftige å summere, for eksempel Alder, kan også dra nytte av å angi standard sammendrag til Ikke oppsummer eller gjennomsnitt. Denne innstillingen er i Egenskaper-delen etter at du har valgt en kolonne.

Screenshot showing the Summarization field with Don't summarize selected.

Velg en datakategori for hver dato- og geografikolonne

Datakategorien gir kunnskap om innholdet i en kolonne utover datatypen. Du kan for eksempel merke en heltallskolonne som et postnummer eller en strengkolonne som poststed, land/område. Spørsmål og svar bruker denne informasjonen på to viktige måter, for visualiseringsvalg og for språkfordommer.

For det første bruker spørsmål og svar datakategoriinformasjonen til å gjøre valg om hvilken type visuell visning som skal brukes. Den gjenkjenner for eksempel at kolonner med datakategorier for dato eller klokkeslett er et godt valg for den vannrette aksen i et linjediagram eller avspillingsaksen i et boblediagram. Det forutsetter at resultater som inneholder kolonner med geografiske datakategorier , kan se bra ut på et kart.

For det andre, Q &A gjør noen utdannede gjetninger om hvordan brukerne er sannsynlig å snakke om dato og geografi kolonner for å hjelpe den å forstå visse typer spørsmål. For eksempel «når» i «Når ble John Smith ansatt?» er nesten sikker på å tilordne til en datokolonne, og "Brown" i "Count customers in Brown" er mer sannsynlig å være en by enn en hårfarge.

Screenshot showing the Data category field with Uncategorized selected.

Velg en Sorter etter kolonne for relevante kolonner

Sorter etter kolonne-egenskapen gjør at sortering i én kolonne automatisk kan sortere en annen kolonne i stedet. Når du for eksempel spør «sorter kunder etter hattestørrelse», vil du sannsynligvis at Kolonnen Hattestørrelse skal sortere etter det underliggende størrelsesnummeret (XS, S, M, L, XL) i stedet for alfabetisk (L, M, S, XL, XS).

Screenshot showing the Sort by column dropdown with Hat Size ID selected.

Normaliser modellen

Du trenger ikke å omforme hele modellen. Imidlertid er visse strukturer så vanskelige at Q &A ikke håndterer dem godt. Hvis du utfører en grunnleggende normalisering av strukturen i modellen, øker brukervennligheten til Power BI-rapporter betydelig, sammen med nøyaktigheten av Q&A-resultater.

Følg denne generelle regelen: Hver unike «ting» brukeren snakker om, skal representeres av nøyaktig ett modellobjekt (tabell eller kolonne). Så hvis brukerne snakker om kunder, bør det være ett kundeobjekt . Hvis brukerne snakker om salg, bør det være ett salgsobjekt . Det finnes omfattende dataformingsfunksjoner som er tilgjengelige i Power Query-redigering hvis du trenger dem. De mer enkle transformasjonene kan justeres ved hjelp av beregninger i Power BI-modellen.

Avsnittene nedenfor inneholder noen vanlige transformasjoner du kanskje må utføre. Se Normalisering kontra denormalisering i artikkelen Forstå stjerneskjema og viktigheten for Power BI for mer informasjon om normalisering av en modell.

Opprette nye tabeller for enheter med flere kolonner

Hvis du har flere kolonner som fungerer som én enkelt distinkt enhet i en større tabell, bør disse kolonnene deles inn i sin egen tabell. La oss for eksempel si at du har en kolonne med kontaktnavn, kontakttittel og kontakt Telefon i firmatabellen. En bedre utforming ville være å ha en egen kontakttabell som inneholder navn, tittel og Telefon, og en kobling tilbake til firmatabellen. Det gjør det enklere å stille spørsmål om kontakter uavhengig av spørsmål om selskaper de er kontakten for, og forbedrer skjermfleksibilitet.

Trenger arbeid

Screenshot showing a Suppliers table that includes contact information.

Klar for spørsmål og svar

Screenshot showing two tables, one for Suppliers and one for Contacts.

Pivot for å eliminere egenskapsposer

Hvis du har egenskapsposer i modellen, bør de omstruktureres til å ha én kolonne per egenskap. Egenskapsposer, selv om det er praktisk å administrere et stort antall egenskaper, har iboende begrensninger som Power BI-rapporter og Q&A ikke er utformet for å omgå.

Vurder for eksempel en CustomerDemographics-tabell med kolonnene CustomerID, Property og Value, der hver rad representerer en annen egenskap for kunden (for eksempel alder, sivilstatus eller poststed). Ved å overbelaste betydningen av Verdi-kolonnen basert på innholdet i egenskapskolonnen, blir det umulig for spørsmål og svar å tolke de fleste spørringer som refererer til den. Et enkelt spørsmål som «vis alderen på hver kunde» kan skje for å fungere, siden det kan tolkes som «vis kundene og kundenes demografi der eiendom er alder». Strukturen i modellen støtter imidlertid ikke mer komplekse spørsmål som «gjennomsnittsalder for kunder i Chicago». Selv om brukere som redigerer Power BI-rapporter direkte, noen ganger kan finne smarte måter å hente dataene de leter etter på, fungerer spørsmål og svar bare når hver kolonne har én enkelt betydning.

Trenger arbeid

Screenshot showing three columns with the headings Customer ID, Property, and Value.

Klar for spørsmål og svar

Screenshot showing three columns with the headings Customer ID, Age, Hat Size, and City.

Union for å eliminere partisjonering

Hvis du har partisjonert dataene på tvers av flere tabeller eller har pivoterte verdier på tvers av flere kolonner, er noen vanlige operasjoner vanskelige eller umulige for brukerne å oppnå. Vurder først en vanlig tabellpartisjonering: en Sales2000-2010-tabell og en Sales2011-2020-tabell . Hvis alle viktige rapporter er begrenset til et bestemt tiår, kan du sannsynligvis la det være slik for Power BI-rapporter. Fleksibiliteten til spørsmål og svar fører imidlertid til at brukerne forventer svar på spørsmål som «totalt salg etter år». For at denne spørringen skal fungere, må du slå sammen dataene i én enkelt Power BI-modelltabell.

På samme måte bør du vurdere en typisk pivotert verdikolonne: en BookTour-tabell som inneholder kolonnene Forfatter, Bok, By1, By2 og By3. Med en struktur som dette kan ikke selv enkle spørsmål som «telle bøker etter by» tolkes på riktig måte. For at denne spørringen skal fungere, oppretter du en egen BookTourCities-tabell , som fagforeninger byverdiene til én enkelt kolonne.

Trenger arbeid

Screenshot showing a table with pivoted value columns, City 1, City 2, and City 3.

Klar for spørsmål og svar

Screenshot showing two tables, one with book and author information for tours and one with cities associated with the tours.

Dele formaterte kolonner

Hvis kilden du importerer dataene fra, inneholder formaterte kolonner, kommer ikke Power BI-rapporter (og spørsmål og svar) inn i kolonnen for å analysere innholdet. Hvis du for eksempel har en fullstendig adressekolonne som inneholder kolonnene adresse, poststed og land/område, bør du også dele den inn i kolonnene Adresse, By og LandRegion, slik at brukerne kan spørre mot dem enkeltvis.

Trenger arbeid

Screenshot showing a table with two columns, Customer and Full Address.

Klar for spørsmål og svar

Screenshot showing a table with five columns, Customer, Full address, Address, City, and Country or Region.

På samme måte, hvis du har noen fulle navnkolonner for en person, legger du til fornavn og etternavnkolonner , bare i tilfelle noen ønsker å stille spørsmål ved hjelp av delvise navn.

Opprett nye tabeller for kolonner med flere verdier

Også en lignende situasjon, hvis kilden du importerer dataene fra, inneholder kolonner med flere verdier, kan ikke Power BI-rapporter (og spørsmål og svar) nå inn i kolonnen for å analysere innholdet. Hvis du for eksempel har en Komponist-kolonne som inneholder navnene på flere komponister for en sang, kan du dele den inn i flere rader i en egen Komponister-tabell .

Trenger arbeid

Screenshot showing a table with four columns, ID, Name, Genre, and Composers.

Klar for spørsmål og svar

Screenshot showing two tables, one with ID, Name, and Genre and one with ID and Composer.

Denormalisere for å eliminere inaktive relasjoner

Det ene unntaket fra «normalisering er bedre»-regelen oppstår når det er mer enn én bane å hente fra én tabell til en annen. La oss for eksempel si at du har en Flyreiser-tabell med både SourceCityID- og DestinationCityID-kolonner, som hver er relatert til Byer-tabellen. En av disse relasjonene må merkes som inaktiv. Siden spørsmål og svar bare kan bruke aktive relasjoner, kan du ikke stille spørsmål om kilde eller mål, avhengig av hvilken du valgte. Hvis du i stedet nedvurderer kolonnene for bynavn i Flyreiser-tabellen , kan du stille spørsmål som «list opp flyreiser for i morgen med en kildeby i Seattle og en destinasjonsby i San Francisco».

Trenger arbeid

Screenshot showing two tables, Flights and Airports.

Klar for spørsmål og svar

Screenshot showing one table named Flights. The columns from the Airports table are added to the Flights table.

Legge til synonymer i tabeller og kolonner

Dette trinnet gjelder spesielt for spørsmål og svar (og ikke for Power BI-rapporter generelt). Brukere har ofte mange termer de bruker til å referere til det samme, for eksempel totalt salg, nettosalg og totalt nettosalg. Du kan legge til disse synonymene i tabeller og kolonner i Power BI-modellen.

Dette trinnet kan være viktig. Selv med enkle tabell- og kolonnenavn stiller brukere av Spørsmål og svar spørsmål ved hjelp av vokabularet som først kommer til dem. De velger ikke fra en forhåndsdefinert liste over kolonner. Jo mer fornuftige synonymer du legger til, desto bedre er brukerens opplevelse med rapporten. Hvis du vil legge til synonymer, går du til modellvisningen i Power BI Desktop ved å velge modellfanen og deretter velge et felt eller en tabell. Egenskaper-ruten viser Synonymer-boksen , der du kan legge til synonymer.

Screenshot showing the Q&A Properties pane with the Synonyms field highlighted.

Vær oppmerksom på at det å legge til det samme synonymet i mer enn én kolonne eller tabell introduserer tvetydighet. Spørsmål og svar bruker kontekst der det er mulig å velge mellom tvetydige synonymer, men ikke alle spørsmål har tilstrekkelig kontekst. Når en bruker for eksempel spør «tell kundene», hvis du har tre ting med synonymet «kunde» i modellen, får kanskje ikke brukeren svaret de leter etter. I disse tilfellene kan du gjøre det primære synonymet unikt fordi det synonymet er det som brukes i omskrivingen. Det kan varsle brukeren om tvetydighet (for eksempel en omskriving av «vis antall arkiverte kundeoppføringer»), noe som tyder på at de kanskje vil spørre om det på en annen måte.