Opprette og administrere relasjoner i Power BI Desktop
Når du importerer flere tabeller er det trolig at du kommer til å foreta analyser ved hjelp av data fra alle disse tabellene. Relasjoner mellom disse tabellene er nødvendige for å beregne nøyaktige resultater og vise riktig informasjon i rapportene. Power BI Desktop gjør det enkelt å opprette disse relasjonene. I de fleste tilfeller trenger du faktisk ikke gjøre noe, gjør funksjonen for automatisk gjenkjenning det for deg. I noen tilfeller må du kanskje allikevel opprette relasjoner selv, eller du må endre en relasjon. Det er uansett viktig å forstå relasjoner i Power BI Desktop, og hvordan du oppretter og redigerer dem.
Automatisk identifisering under innlasting
Hvis du spør i to eller flere tabeller samtidig, prøver Power BI Desktop å finne og opprette relasjoner for deg når dataene lastes. Relasjonsalternativene kardinalitet, kryssfiltreringsretning og gjør denne relasjonen aktiv blir angitt automatisk. Power BI Desktop ser på kolonnenavnene i tabellene du spør i for å finne ut om det er noen mulige relasjoner. I så fall opprettes disse relasjonene automatisk. Hvis Power BI Desktop ikke ikke kan fastslå med stor sikkerhet at det finnes et treff, opprettes det ikke en relasjon. Du kan fortsatt bruke dialogboksen Behandle relasjoner for å opprette eller redigere relasjoner manuelt.
Opprette en relasjon ved hjelp av automatisk gjenkjenning
Velg Administrer>relasjonautodetect på Modellering-fanen.
Opprette en relasjon manuelt
Velg Behandle relasjonerNy> på Modellering-fanen.
I dialogboksen Opprett relasjon, velger du en tabell i den første rullegardinlisten. Velg kolonnen du vil bruke i relasjonen.
Velg den andre tabellen du vi ha i relasjonen fra den andre rullegardinlisten. Merk den andre kolonnen du vil bruke, og velg deretter OK.
Power BI Desktop konfigurerer automatisk alternativene kardinalitet (retning), kryssfiltreringsretning og gjør denne relasjonen aktiv for den nye relasjonen. Du kan imidlertid endre innstillingene hvis det er nødvendig. For mer informasjon, kan du se Forstå flere alternativer.
Hvis ingen av tabellene som er valgt for relasjonen har unike verdier, vil du se følgende feilmelding: Én av kolonnene må ha unike verdier. Minst én av tabellene i en relasjon må ha en distinkt, unik liste over nøkkelverdier. Dette er et vanlig krav for alle relasjonsdatabaseteknologier.
Hvis du får denne feilmeldingen, er det et par måter du kan løse problemet på:
- Bruk Fjern duplikater for å opprette en kolonne med unike verdier. Ulempen med denne metoden er at du kan miste informasjon når du fjerner de dupliserte radene, det er ofte en årsak til at en nøkkel (rad) dupliseres.
- Legg til en mellomliggende tabell laget av listen over de distinkte nøkkelverdiene til modellen, som deretter kobles til begge de opprinnelige kolonnene i relasjonen.
For mer informasjon, kan du lese dette blogginnlegget.
Redigere en relasjon
Velg Behandle relasjoner på Modellering-fanen.
I dialogboksen Behandle relasjoner velger du relasjonen, og velger deretter Rediger.
Konfigurere flere alternativer
Når du oppretter eller redigerer en relasjon, kan du konfigurere flere alternativer. Som standard konfigurerer Power BI flere alternativer automatisk basert på dets beste anslag, som kan være forskjellig for hver relasjon basert på dataene i kolonnene.
Kardinalitet
Alternativet Kardinalitet kan ha én av følgende innstillinger:
Mange til én (*:1): En mange-til-én-relasjon er den vanligste standardtypen for relasjon. Det betyr at kolonnen i en gitt tabell kan ha mer enn én forekomst av en verdi, mens den andre relatert tabellen, ofte omtalt som oppslagstabellen, bare har én forekomst av en verdi.
Én til én (1:1) : I en én til én relasjon, har kolonnen i én tabell bare én forekomst av en bestemt verdi, og den relaterte tabellen har bare én forekomst av en bestemt verdi.
Én til mange (1:*) : I en én til mange relasjon, har kolonnen i én tabell bare én forekomst av en bestemt verdi, og den relaterte tabellen kan bare ha én forekomst av en bestemt verdi.
Mange til mange (*:*): Med sammensatte modeller kan du etablere en mange-til-mange-relasjon mellom tabeller, noe som fjerner krav til unike verdier i tabeller. Den fjerner også tidligere midlertidige løsninger, for eksempel introduksjon av bare nye tabeller for å opprette relasjoner. For mer informasjon, kan du se Relasjoner med en mange til mange kardinalitet.
For mer informasjon om når du skal endre kardinalitet, kan du se Forstå flere alternativer.
Kryssfiltreringsretning
Alternativet Kryssfiltreringsretning kan ha én av følgende innstillinger:
Begge: For filtreringsformål behandles begge tabellene som om de er én enkelt tabell. Innstillingen Begge fungerer bra med én enkelt tabell som har mange oppslagstabeller som omgir den. Et eksempel er en tabell for totale salgstall, med en oppslagstabell for dens avdeling. Denne konfigurasjonen kalles ofte en stjerneskjemakonfigurasjon (en sentral tabell med flere oppslagstabeller). Hvis du derimot har to eller flere tabeller som også har oppslagstabeller (med noen felles), bør du ikke bruke innstillingen Begge. For å fortsette med forrige eksempel har du i dette tilfellet også en tabell med salgsbudsjett som registrerer målbudsjettet for hver avdeling. Og avdelingstabellen er koblet til både salgs- og budsjettabellen. Unngå å bruke innstillingen Begge for denne typen konfigurasjon.
Enkel: Den vanligste standardretningen, som betyr at filtreringsvalg i tilkoblede tabeller fungerer på tabellen der verdiene aggregeres. Hvis du importerer en Power Pivot i Excel 2013 eller tidligere datamodell, får alle relasjoner én retning.
For mer informasjon om når du skal endre kryssfiltreringsretning, kan du se Forstå flere alternativer.
Gjør denne relasjonen aktiv
Når dette er merket av, fungerer relasjonen som den aktive standardrelasjonen. I tilfeller der det er mer enn én relasjon mellom to tabeller, er aktiv relasjon en måte for Power BI Desktop å automatisk opprette visualiseringer på som inneholder begge tabellene.
For mer informasjon om når du skal gjøre en spesifikk relasjon aktiv, kan du se Forstå tilleggsalternativer.
Forstå relasjoner
Når du har koblet to tabeller sammen i en relasjon, kan du arbeide med data i begge tabellene som om de var én enkelt tabell, og på den måten slippe å bekymre deg for relasjonsdetaljer, eller å slå sammen disse tabellene til én enkelt tabell før du importerer dem. I mange situasjoner kan Power BI Desktop automatisk opprette relasjoner for deg. Men hvis Power BI Desktop ikke kan fastslå med en høy grad av sikkerhet at det skal finnes en relasjon mellom to tabeller, opprettes det ikke automatisk en relasjon. I så fall må du gjøre det.
La oss gå gjennom en kjapp opplæring, for å bedre vise deg hvordan relasjoner fungerer i Power BI Desktop.
Tips!
Du kan fullføre denne leksjonen selv:
- Kopier følgende ProjectHours-tabell til et Excel-regneark (unntatt tittelen), merk alle cellene og velg Sett inn>Tabell.
- I dialogboksen Lag tabell velger du OK.
- Merk en tabellcelle, velg Tabellutformingsnavn>, og skriv deretter inn ProjectHours.
- Gjør det samme for tabellen CompanyProject.
- Importer dataene ved hjelp av Hent data i Power BI Desktop. Velg de to tabellene som en datakilde og velg deretter Last inn.
Den første tabellen, ProjectHours, er en oversikt over timekort som registrerer hvor mange timer en person har jobbet på et bestemt prosjekt.
ProjectHours
| Kort | SubmittedBy | Timer | Prosjekt | DatoAngitt |
|---|---|---|---|---|
| 1001 | Brewer, Alan | 22 | Blå | 1\.1.2013 |
| 1002 | Brewer, Alan | 26 | Rød | 1\.2.2013 |
| 1003 | Ito, Shu | 34 | Gul | 4\.12.2012 |
| 1004 | Brewer, Alan | 13 | Oransje | 2\.1.2012 |
| 1005 | Bowen, Eli | 29 | Lilla | 01.10.2013 |
| 1006 | Bento, Nuno | 35 | Grønn | 1\.2.2013 |
| 1007 | Hamilton, David | 10 | Gul | 01.10.2013 |
| 1008 | Han, Mu | 28 | Oransje | 2\.1.2012 |
| 1009 | Ito, Shu | 22 | Lilla | 1\.2.2013 |
| 1010 | Bowen, Eli | 28 | Grønn | 01.10.2013 |
| 1011 | Bowen, Eli | 09: | Blå | 15/10/2013 |
Den andre tabellen, CompanyProject, er en liste over prosjekter med en tilordnet prioritet: A, B eller C.
CompanyProject
| ProjName | Prioritet |
|---|---|
| Blå | A |
| Rød | B |
| Grønn | C |
| Gul | C |
| Lilla | B |
| Oransje | C |
Legg merke til at hver tabell har en prosjekt-kolonne. Hver navn er litt forskjellig, men verdiene ser ut til å være like. Dette er viktig, og vi kommer tilbake til dette snart.
Nå som vi har importert våre to tabeller til en modell, kan vi opprette en rapport. Det første vi ønsker er å få antall timer lagt inn etter prioritet på prosjekt, så vi velger Prioritet og Timer fra Felt-ruten.
Hvis vi ser på tabellen vår i rapportlerretet, ser du at antall timer er 256 for hvert prosjekt, og det er også totalen. Dette antallet er selvsagt ikke riktig. Hvorfor? Det er fordi vi ikke kan beregne en total av verdiene fra én tabell (Timer i tabellen Project), delt inn etter verdiene i en annen tabell (Prioritet i tabellen CompanyProject) uten en relasjon mellom disse to tabellene.
Så la oss opprette en relasjon mellom disse to tabellene.
Husker du de to kolonnene vi så i begge tabellene som inneholdt et prosjektnavn, men der verdiene så like ut? Vi skal bruke disse to kolonnene til å opprette en relasjon mellom våre tabeller.
Hvorfor disse kolonnene? Hvis vi ser på kolonnen Prosjekt i tabellen ProjectHours, ser vi verdier som blå, rød, gul, oransje og så videre. Faktisk ser vi flere rader som har de samme verdiene. Med andre ord har vi mange fargeverdier for Prosjekt.
Hvis vi ser på kolonnen ProjName i tabellen CompanyProject, ser vi det er bare én av hver fargeverdi for prosjektet. Hver fargeverdi i denne tabellen er unik, og det er viktig fordi vi kan opprette en relasjon mellom disse to tabellene. I dette tilfellet en mange-til-én-relasjon. I en mange-til-én-relasjon, må minst én kolonne i én av tabellene inneholde unike verdier. Det finnes flere alternativer for noen relasjoner, som vi skal se på senere. La oss nå opprette en relasjon mellom prosjektkolonnene i hver av de to tabellene.
Slik oppretter du den nye relasjonen
Velg Behandle relasjoner fra Modellering-fanen .
I Administrer relasjoner, velger du Ny for å åpne dialogboksen Opprett relasjon, der du kan velge tabeller, kolonner og eventuelle andre innstillinger som du ønsker for relasjonen.
I rullegardinlisten velger du ProjectHours som den første tabellen, velg deretter kolonnen Prosjekt. Dette er mange-siden av vår relasjon.
I den andre rullegardinlisten, forhåndsvelges CompanyProject som den andre tabellen. Velg ProjName-kolonnen. Dette er én-siden av vår relasjon.
Godta standardinnstillingene for relasjonsalternativene og velg deretter OK.
I dialogboksen Behandle relasjoner, velger du Lukk.
For å få komplett innlemming opprettet du denne relasjonen på den tungvinte måten. Du kunne også bare ha valgt Automatisk gjenkjenning i dialogboksen Behandle relasjoner. Faktisk ville automatisk gjenkjenning automatisk ha opprettet relasjonen for deg når du lastet dataene hvis begge kolonnene hadde samme navn. Men hva er utfordringen i det?
Nå skal vi se på tabellen i rapportlerretet igjen.
Det ser mye bedre ut, ikke sant?
Når vi summerer timer etter Prioritet, søker Power BI Desktop etter alle forekomstene av de unike fargeverdiene i oppslagstabellen CompanyProject, ser etter hver forekomst av hver enkelt av disse verdiene i tabellen CompanyProject og beregner deretter en total for hver unike verdi.
Det var enkelt. Med Automatisk gjenkjenning trenger du faktisk ikke engang å gjøre så mye som dette.
Forstå flere alternativer
Når en relasjon er opprettet, enten med automatisk gjenkjenning eller en du lager manuelt, konfigurerer Power BI Desktop automatisk ekstra alternativer basert på dataene i tabellene. Disse ekstra egenskapene for relasjoner er plassert i den nedre delen av dialogboksene Opprett relasjon og Rediger relasjon.
Power BI angir vanligvis disse alternativene automatisk, og du trenger ikke justere dem. Det finnes imidlertid flere situasjoner der du vil konfigurere disse alternativene selv.
Automatiske relasjonsoppdateringer
Du kan administrere hvordan Power BI behandler og automatisk justerer relasjoner i dine rapporter og modeller. Hvis du vil angi hvordan Power BI håndterer relasjonsalternativer, velger du Fil>Alternativer og innstillinger>Alternativer fra Power BI Desktop og velger deretter Databelastning i den venstre ruten. Alternativene for Relasjoner vises.
Det finnes tre alternativer som kan velges og aktiveres:
Importer relasjoner fra datakilder ved første lasting: Dette alternativet er valgt som standard. Når det er valgt, ser Power BI etter relasjoner som er definert i datakilden, for eksempel sekundærnøkkel/primærnøkkelrelasjoner i datalageret. Hvis slike relasjoner finnes, speiles de i Power BI-data modellen når du opprinnelig laster inn data. Med dette alternativet kan du raskt begynne å arbeide med modellen, i stedet for at du må finne eller definere disse relasjonene selv.
Oppdater eller slett relasjoner ved oppdatering av data: Dette alternativet er ikke valgt som standard. Hvis du valgte det, ser Power BI etter endringer i datakilderelasjoner når datasettet oppdateres. Hvis disse relasjonene ble endret eller fjernet, gjenspeiler Power BI disse endringene i sin egen datamodell, oppdaterer eller sletter dem for å samsvare.
Advarsel
Hvis du bruker sikkerhet på radnivå som er avhengig av de definerte relasjonene, anbefaler vi ikke at du velger dette alternativet. Hvis du fjerner en relasjon som RLS-innstillingen er avhengig av, kan modellen bli mindre sikker.
Gjenkjenn nye relasjoner automatisk etter at data er lastet: Dette alternativet er beskrevet i Identifiser automatisk under lasting.
Fremtidige oppdateringer av dataene krever en annen kardinalitet
Power BI Desktop kan normalt bestemme den beste kardinaliteten for relasjonen automatisk. Hvis du trenger å overstyre den automatiske innstillingen, fordi du vet at dataene vil bli endret i fremtiden, kan du endre det i Kardinalitet-kontrollen. La oss se på et eksempel der vi trenger å velge en annen kardinalitet.
CompanyProjectPriority-tabellen er en liste over alle firmaprosjekter og deres prioritet. Tabellen ProjectBudget er et sett med prosjekter hvor budsjettet har blitt godkjent.
CompanyProjectPriority
| ProjName | Prioritet |
|---|---|
| Blå | A |
| Rød | B |
| Grønn | C |
| Gul | C |
| Lilla | B |
| Oransje | C |
ProjectBudget
| Godkjente prosjekter | BudgetAllocation | AllocationDate |
|---|---|---|
| Blå | 40 000 | 1\.12.2012 |
| Rød | 100 000 | 1\.12.2012 |
| Grønn | 50 000 | 1\.12.2012 |
Hvis vi oppretter en relasjon mellom kolonnen Godkjente prosjekter i tabellen ProjectBudget og kolonnen ProjectName i tabellen CompanyProjectPriority, angir Power BI automatisk kardinalitet til én til én (1:1) og kryssfiltreringsretning til begge.
Power BI foretar disse innstillingene fordi den beste kombinasjonen av de to tabellene for Power BI Desktop er som følger:
| ProjName | Prioritet | BudgetAllocation | AllocationDate |
|---|---|---|---|
| Blå | A | 40 000 | 1\.12.2012 |
| Rød | B | 100 000 | 1\.12.2012 |
| Grønn | C | 50 000 | 1\.12.2012 |
| Gul | C | ||
| Lilla | B | ||
| Oransje | C |
Det er en én-til-én-relasjon mellom våre to tabeller fordi det ikke er noen gjentagende verdier i den kombinerte tabellens ProjName-kolonne. Kolonnen ProjName er unik fordi hver verdi forekommer bare én gang, og radene fra de to tabellene kan kombineres direkte uten duplisering.
Men la oss si at du vet at dataene endres neste gang du oppdaterer den. En oppdatert versjon av tabellen ProjectBudget har nå flere rader for de blå og røde prosjektene:
ProjectBudget
| Godkjente prosjekter | BudgetAllocation | AllocationDate |
|---|---|---|
| Blå | 40 000 | 1\.12.2012 |
| Rød | 100 000 | 1\.12.2012 |
| Grønn | 50 000 | 1\.12.2012 |
| Blå | 80.000 | 1\.6.2013 |
| Rød | 90.000 | 1\.6.2013 |
Disse ekstra radene betyr at den beste kombinasjonen av de to tabellene nå ser slik ut:
| ProjName | Prioritet | BudgetAllocation | AllocationDate |
|---|---|---|---|
| Blå | A | 40 000 | 1\.12.2012 |
| Rød | B | 100 000 | 1\.12.2012 |
| Grønn | C | 50 000 | 1\.12.2012 |
| Gul | C | ||
| Lilla | B | ||
| Oransje | C | ||
| Blå | A | 80.000 | 1\.6.2013 |
| Rød | B | 90.000 | 1\.6.2013 |
I den nye kombinerte tabellen har kolonnen ProjName gjentatte verdier. De to opprinnelige tabellene vil ikke ha en én-til-én-relasjon når tabellen er oppdatert. I dette tilfellet, fordi vi vet at disse fremtidige oppdateringene vil føre til at ProjName-kolonnen har duplikater, ønsker vi å angi kardinalitetentil mange til én (*:1), med mange-siden på ProjectBudget og den ene siden på CompanyProjectPriority.
Justere kryssfiltreringsretningen for et omfattende sett med tabeller og relasjoner
Kryssfiltreringsretningen er satt til Begge for de fleste relasjoner. Det finnes imidlertid noen mer uvanlige tilfeller der du kanskje må angi dette alternativet forskjellig fra standarden, som eksempelvis hvis du importerer en modell fra en eldre versjon av Power Pivot, der hver relasjon er satt til én retning.
Begge-innstillingen lar Power BI Desktop behandle alle aspekter av tilkoblede tabeller som om de er en enkelt tabell. Likevel finnes det noen tilfeller der Power BI Desktop ikke kan angi en relasjons kryssfiltreringsretning til Begge og samtidig holde et entydig sett med standarder som er tilgjengelig for rapporteringsformål. Hvis en relasjons kryssfiltreringsretning ikke er satt til Begge, skjer dette vanligvis fordi det ville føre til tvetydighet. Hvis standard kryssfiltreringsretning ikke fungerer for deg, kan du prøve å sette det til en bestemt tabell eller Begge.
Kryssfiltreringsretning i én retning fungerer i mange situasjoner. Hvis du importerte en modell fra Power Pivot i Excel 2013 eller tidligere, vil faktisk alle relasjoner bli satt til én retning. Én retning betyr at filtreringsvalg i tilkoblede tabeller virker inn på tabeller der aggregering skjer. Noen ganger kan det være litt vanskelig å forstå kryssfiltrering, så la oss se på et eksempel.
Med kryssfiltrering i én retning, hvor du oppretter en rapport om oppsummerer prosjekttimer, kan du velge å summere (eller filtrere) etter tabellen CompanyProject og dens kolonne Priority eller tabellen CompanyEmployee og dens kolonne City. Hvis du imidlertid vil telle antall ansatte per prosjekt (et mindre vanlig spørsmål), vil dette ikke fungere. Du får da en kolonne med verdier som alle er lik. I det følgende eksemplet er begge relasjonenes filtreringsretning satt til én retning: mot tabellen ProjectHours. I brønnen Values er feltet Project angitt til Count:
Filterspesifikasjonen flyter fra CompanyProject til ProjectHours (som vist på det følgende bildet), men den vil ikke flyte opp til CompanyEmployee.
Hvis du imidlertid setter kryssfiltreringsretningen til Begge vil dette fungere. Innstillingen Begge gjør det mulig for filtreringsspesifikasjonen å flyte opp til CompanyEmployee.
Med kryssfiltreringsretning angitt til Begge, vises rapporten vår nå riktig:
Kryssfiltreringsretningen begge fungerer bra for et mønster med tabellrelasjoner slik som mønsteret ovenfor. Dette skjemaet kalles vanligvis en stjerneskjema og ser ut som dette:
Kryssfiltreringsretning fungerer ikke sammen med et mer generelt mønster som ofte finnes i databaser, som i dette diagrammet:
Hvis du har et mønster som dette, med løkker, kan kryssfiltrering opprette et tvetydig sett med relasjoner. Hvis du for eksempel summerer et felt fra TabellX og deretter velge å filtrere etter et felt i TabellY, er det ikke tydelig hvordan filtreringen skal gå- Om den skal gå gjennom den øverste tabellen eller den nedre tabellen. Et vanlig eksempel på denne typen mønster er med TabellX som en salgstabell med faktiske data, og med TabellY som budsjettdata. Tabellene i midten er da oppslagstabeller som begge tabellene bruker, for eksempel avdeling eller område.
Som med aktive eller inaktive relasjoner, vil ikke Power BI Desktop la en relasjon bli angitt til Begge hvis det fører til tvetydighet i rapportene. Det finnes flere forskjellige måter du kan håndtere denne situasjonen på. Her er de to vanligste:
- Slett, eller merk relasjoner som inaktive for å redusere tvetydighet. Du kan da kanskje opprette en relasjons kryssfiltrering som Begge.
- Hent inn en tabell to ganger (med et annet navn andre gang) for å eliminere løkker. Dette gjør mønsteret for relasjoner til et stjerneskjema. Med et stjerneskjema kan alle relasjonene settes til Begge.
Feil aktiv relasjon
Når Power BI Desktop automatisk oppretter relasjoner, kan det noen ganger oppstå mer enn én relasjon mellom to tabeller. Når dette skjer, blir bare én av relasjonene satt til aktiv. Aktiv relasjon fungerer som standardrelasjonen, slik at når du velger felt fra to forskjellige tabeller, kan Power BI Desktop automatisk opprette en visualisering for deg. I noen tilfeller kan den automatisk merkede relasjonen imidlertid være feil. Du kan bruke dialogboksen Behandle relasjoner til å angi en relasjon som aktiv eller inaktiv, eller du kan angi aktiv relasjon i dialogboksen Rediger relasjon.
For å sikre at det finnes en standard relasjon, tillater Power BI Desktop bare én enkelt aktiv relasjon mellom to tabeller på et gitt tidspunkt. Derfor må du først angi gjeldende relasjon som inaktiv, og deretter angi relasjonen du vil skal være aktiv.
La oss se på et eksempel. Denne første tabellen er ProjectTickets og neste tabell er EmployeeRole.
ProjectTickets
| Kort | OpenedBy | SubmittedBy | Timer | Prosjekt | DatoAngitt |
|---|---|---|---|---|---|
| 1001 | Perham, Tom | Brewer, Alan | 22 | Blå | 1\.1.2013 |
| 1002 | Roman, Daniel | Brewer, Alan | 26 | Rød | 1\.2.2013 |
| 1003 | Roth, Daniel | Ito, Shu | 34 | Gul | 4\.12.2012 |
| 1004 | Perham, Tom | Brewer, Alan | 13 | Oransje | 2\.1.2012 |
| 1005 | Roman, Daniel | Bowen, Eli | 29 | Lilla | 01.10.2013 |
| 1006 | Roth, Daniel | Bento, Nuno | 35 | Grønn | 1\.2.2013 |
| 1007 | Roth, Daniel | Hamilton, David | 10 | Gul | 01.10.2013 |
| 1008 | Perham, Tom | Han, Mu | 28 | Oransje | 2\.1.2012 |
| 1009 | Roman, Daniel | Ito, Shu | 22 | Lilla | 1\.2.2013 |
| 1010 | Roth, Daniel | Bowen, Eli | 28 | Grønn | 01.10.2013 |
| 1011 | Perham, Tom | Bowen, Eli | 09: | Blå | 15/10/2013 |
EmployeeRole
| Ansatt | Rolle |
|---|---|
| Bento, Nuno | Prosjektleder |
| Bowen, Eli | Prosjektledelse |
| Brewer, Alan | Prosjektleder |
| Hamilton, David | Prosjektledelse |
| Han, Mu | Prosjektledelse |
| Ito, Shu | Prosjektledelse |
| Perham, Tom | Prosjektsponsor |
| Roman, Daniel | Prosjektsponsor |
| Roth, Daniel | Prosjektsponsor |
Det er faktisk to relasjoner her:
- Mellom Employee i tabellen EmployeeRole og SubmittedBy i tabellen ProjectTickets.
- Mellom OpenedBy i tabellen ProjectTickets og Employee i tabellen EmployeeRole.
Hvis vi legger til begge relasjonene i modellen (OpenedBy først), så vil dialogboksen Behandle relasjoner vise at OpenedBy er aktiv:
Hvis vi nå oppretter en rapport som bruker feltene Role og Employee fra EmployeeRole og feltet Hours fra ProjectTickets i en tabellvisning på rapportlerretet, ser vi bare prosjektets sponsor da de er de eneste som åpnet et prosjektkort.
Vi kan endre aktiv relasjon og få SubmittedBy i stedet for OpenedBy. I Behandle relasjon, fjerner vi markeringen for ProjectTickets(OpenedBy) til EmployeeRole(Employee) -relasjonen og merker deretter av EmployeeRole(Employee) til Project Tickets(SubmittedBy) -relasjonen.
Se alle relasjonene i Relasjonsvisning
Noen ganger har modellen flere tabeller og komplekse relasjoner mellom dem. Relasjonsvisningen i Power BI Desktop viser alle relasjonene i modellen, retningen og kardinalitet i et lettfattelig og konfigurerbart diagram.
For mer informasjon kan du se Relasjonsvisning i Power BI Desktop.
Feilsøking
Denne delen gir veiledning og feilsøkingsinformasjon når du arbeider med relasjoner i Power BI.
Relasjoner mellom felt kan ikke fastslås
Power BI forsøker å vise relevante data i visualobjekter ved å utlede relasjonene fra modellen som brukes. Noen ganger er ikke slike slutninger åpenbare, og du kan bli overrasket over å se en feil i visualobjektet, noe som indikerer at det ikke er noen relasjon mellom bestemte kolonner.
Hvis du vil forklare hvordan Power BI bestemmer om felt er relatert, kan vi bruke en eksempelmodell til å illustrere noen scenarioer i de følgende avsnittene. Bildet nedenfor viser eksempelmodellen vi skal bruke i eksempelscenarioene.
Scenario 1: Tradisjonelt stjerneskjema og ingen målbetingelse. Med henvisning til eksempelmodellen i det forrige bildet, skal vi først se på høyre halvdel av bildene med tabellene Leverandør – Kjøp – Produkt . Dette er et tradisjonelt stjerneskjema med faktatabellen (Kjøp) og to dimensjonstabeller (produkt og leverandør). Relasjonen mellom dimensjonstabellene og faktatabellen er 1 til Mange (ett produkt tilsvarer mange kjøp, én leverandør tilsvarer mange kjøp). I denne typen skjema kan vi svare på spørsmål som Hva slags salg har vi for produkt X? Og Hvilke salg har vi for Leverandør Y? og Hvilke produkter selger leverandør Y?
Hvis vi ønsker å koordinere produkter og leverandører, kan vi gjøre dette ved å se på Kjøp-tabellen for å se om det finnes en oppføring med samme produkt og leverandør. En eksempelspørring kan se slik ut:
Correlate Product[Color] with Vendor[Name] where CountRows(Purchases)>0
where CountRows(Purchases)>0 Er en implisitt begrensning som Power BI vil legge til for å sikre at relevante data returneres.
Ved å gjøre denne korrelasjonen gjennom Kjøp-tabellen , kan vi returnere sammenkoblinger av Product-Vendor som har minst én oppføring i en faktatabell, sammenkoblinger som gir mening fra dataperspektivet. Du kan forvente eventuelle nonsensiske kombinasjoner av Product-Vendor som det aldri har vært et salg (som ville være ubrukelig for analyse) ikke vil bli vist.
Scenario 2: Tradisjonelt stjerneskjema og målbetingelse angitt. I det forrige eksemplet i scenario 1, hvis brukeren angir en begrensning i form av summert kolonne (sum/gjennomsnitt/antall kjøpsantall, for eksempel) eller et modellmål (spesifikt antall VendID), kan Power BI generere en spørring i form av følgende:
Correlate Product[Color] with Vendor[Name] where MeasureConstraint is not blank
I slike tilfeller forsøker Power BI å returnere kombinasjoner som har meningsfulle verdier for betingelsen gitt av brukeren (ikke tom). Power BI trenger ikke å legge til sin egen implisitte begrensning av CountRows(Purchases)>0, for eksempel hvordan det ble gjort i forrige scenario 1, fordi betingelsen som er angitt av brukeren, er tilstrekkelig.
Scenario 3: Skjema som ikke er stjerne, og ingen målbetingelse er angitt. I dette scenarioet fokuserer vi på midten av modellen, der vi har tabellene Salg – Produkt – Kjøp , der vi har én dimensjonstabell (Produkt) og to faktatabeller (Salg, Kjøp). Siden dette ikke er et stjerneskjema, kan vi ikke svare på samme type spørsmål som vi hadde i scenario 1. La oss si at vi prøver å koordinere Kjøp og Salg. siden Kjøp har en mange-til-1-relasjon med produkt, og produktet har en 1-til-mange-relasjon med salg, salg og kjøp , er indirekte mange til mange. Vi kan koble ett produkt til mange kjøp og ett produkt til mange salg, men vi kan ikke koble ett salg til mange kjøp eller omvendt. Vi kan bare koble mange kjøp til mange salg.
I denne situasjonen, hvis vi prøver å kombinere Kjøp[VenID] og Salg[CustID] i et visualobjekt, Power BI ikke har en konkret begrensning det kan gjelde, på grunn av mange til mange-relasjonen mellom disse tabellene. Selv om det kan være egendefinerte begrensninger (som ikke nødvendigvis stammer fra relasjonene som er opprettet i modellen) som kan brukes for ulike scenarioer, kan Power BI ikke utlede en standardbetingelse utelukkende basert på relasjonene. Hvis Power BI forsøkte å returnere alle kombinasjoner av de to tabellene, ville det opprette en stor krysskobling og returnere ikke-relevante data. I stedet for dette, Power BI utløser en feil i visualobjektet, for eksempel følgende.
Scenario 4: Ikke-stjerneskjema og målbetingelse angitt. Hvis vi tar eksemplet fra scenario 3 og legger til en gitt brukerbetingelse i form av en oppsummert kolonne (for eksempel antall produkter[ProdID] eller et modellmål (Salg[Totalt antall]), kan Power BI generere en spørring i form av Korrelasjonskjøp[VenID] og Salg[CustID] der MeasureConstraint ikke er tom.
I dette tilfellet respekterer Power BI brukerens begrensning som den eneste begrensningen Power BI må bruke, og returnere kombinasjonene som produserer ikke-tomme verdier for den. Brukeren har veiledet Power BI til scenarioet den ønsker, og Power BI bruker veiledningen.
Scenario 5: Når en målbetingelse er angitt, men den er delvis relatert til kolonnene. Det finnes tilfeller der målbetingelsen gitt av brukeren ikke er helt relatert til alle kolonnene i visualobjektet. Et modellmål relaterer alltid alt. Power BI behandler dette som en svart boks når du prøver å finne relasjoner mellom kolonner i visualobjektet, og anta at brukeren vet hva de gjør ved hjelp av det. Summerte kolonner i form av summering, gjennomsnitt og lignende sammendrag som er valgt fra brukergrensesnittet, kan imidlertid bare relatere til et delsett av kolonnene/tabellene som brukes i visualobjektet, basert på relasjonene i tabellen som kolonnen tilhører. Begrensningen gjelder derfor for noen paringer av kolonner, men ikke for alle, i så fall Power BI forsøker å finne standardbetingelser som kan gjelde for kolonnene som ikke er relatert til brukerens angitte betingelse (for eksempel i scenario 1). Hvis Power BI ikke finner noen, returneres følgende feil.
Løse relasjonsfeil
Når du ser feilmeldingen Kan ikke bestemme relasjoner mellom felt , kan du utføre følgende trinn for å prøve å løse feilen:
Kontroller modellen. Er den riktig konfigurert for spørsmålstypene du vil besvare fra analysen? Kan du endre noen av relasjonene mellom tabeller? Kan du unngå å opprette en indirekte mange til mange?
Vurder å konvertere det omvendte V-figurskjemaet til to tabeller, og bruk en direkte mange-til-mange-relasjon mellom dem som beskrevet i bruk mange-mange-relasjoner i Power BI Desktop.
Legg til en begrensning i visualobjektet i form av en oppsummert kolonne eller et modellmål.
Hvis en oppsummert kolonne legges til og det fremdeles er en feil, kan du vurdere å bruke et modellmål.
Neste trinn
Hvis du vil ha mer informasjon om modeller og relasjoner, kan du se følgende artikler: