Vejledning til en til en-relationer

Denne artikel henvender sig til dig som datamodel, der arbejder med Power BI Desktop. Den indeholder en vejledning i at arbejde med en til en-modelrelationer. Der kan oprettes en en til en-relation, når begge tabeller hver især indeholder en kolonne med fælles og entydige værdier.

Bemærk

En introduktion til modelrelationer er ikke beskrevet i denne artikel. Hvis du ikke er helt fortrolig med relationer, deres egenskaber, eller hvordan du konfigurerer dem, anbefaler vi, at du først læser artiklen Modelrelationer i Power BI Desktop .

Det er også vigtigt, at du har en forståelse af stjerneskemadesign. Du kan få flere oplysninger under Forstå stjerneskemaet og vigtigheden af Power BI.

Der er to scenarier, der involverer en til en-relationer:

• Degenererede dimensioner: Du kan udlede en forringet dimension fra en tabel af faktatypen.

• Rækkedata spænder over tabeller: Et enkelt forretningsobjekt eller en enkelt emne indlæses som to (eller flere) modeltabeller, muligvis fordi deres data stammer fra forskellige datalagre. Dette scenarie kan være almindeligt for tabeller af dimensionstypen. Masterproduktoplysninger gemmes f.eks. i et driftssystem, og supplerende produktoplysninger gemmes i en anden kilde.

  Det er dog usædvanligt, at du relaterer to tabeller af faktatypen med en en til en-relation. Det skyldes, at begge tabeller af faktatypen skal have samme dimensionalitet og granularitet. Hver tabel af faktatypen skal også bruge entydige kolonner for at tillade, at modelrelationen oprettes.

Degenerere dimensioner

Når kolonner fra en tabel af faktatypen bruges til filtrering eller gruppering, kan du overveje at gøre dem tilgængelige i en separat tabel. På denne måde kan du adskille kolonner, der bruges til filtrering eller gruppering, fra de kolonner, der bruges til at opsummere faktarækker. Denne adskillelse kan:

• Reducer lagerplads
• Forenkle modelberegninger
• Bidrag til forbedret forespørgselsydeevne
• Levér en mere intuitiv oplevelse af ruden Felter til dine rapportforfattere

Overvej en kildesalgstabel, der gemmer oplysninger om salgsordrer i to kolonner.

I kolonnen OrderNumber gemmes ordrenummeret, og kolonnen OrderLineNumber gemmer en sekvens af linjer i ordren.

Bemærk, at kolonnerne ordrenummer og ordrelinjenummer ikke er indlæst i tabellen Sales i følgende modeldiagram. I stedet blev deres værdier brugt til at oprette en surrogatnøglekolonne med navnet SalesOrderLineID. Nøgleværdien beregnes ved at multiplicere ordrenummeret med 1000 og derefter tilføje ordrelinjenummeret.

Tabellen Salgsordre giver rapportforfattere en omfattende oplevelse med tre kolonner: Salgsordre, Salgsordrelinje og Linjenummer. Den indeholder også et hierarki. Disse tabelressourcer understøtter rapportdesign, der skal filtrere, gruppere efter eller analysere ned gennem ordrer og ordrelinjer.

Da tabellen Sales Order er afledt af salgsdataene, skal der være nøjagtigt det samme antal rækker i hver tabel. Der skal desuden være matchende værdier mellem hver kolonne af typen SalesOrderLineID .

Rækkedata strækker sig over flere tabeller

Overvej et eksempel, der involverer to en til en-relaterede tabeller af dimensionstypen: Product og Product Category. Hver tabel repræsenterer importerede data og har en SKU-kolonne (Lagerenhed), der indeholder entydige værdier.

Her er et delvist modeldiagram over de to tabeller.

Den første tabel hedder Product og indeholder tre kolonner: Color, Product og SKU. Den anden tabel hedder Product Category og indeholder to kolonner: Category og SKU. En en til en-relation relaterer de to SKU-kolonner . Relationen filtrerer i begge retninger, hvilket altid er tilfældet for en til en-relationer.

Modeldiagrammet er blevet ændret for at hjælpe med at beskrive, hvordan overførsel af relationsfiltre fungerer, for at vise tabelrækkerne. Alle eksempler i denne artikel er baseret på disse data.

Bemærk

Det er ikke muligt at få vist tabelrækker i Power BI Desktop-modeldiagrammet. Det gøres i denne artikel for at understøtte diskussionen med tydelige eksempler.

Rækkedetaljerne for de to tabeller er beskrevet på følgende punktopstilling:

• Tabellen Product indeholder tre rækker:
  • SKU CL-01, Produkt-T-shirt, Farvegrøn
  • SKU CL-02, Produkt jeans, Farve blå
  • SKU AC-01, Produkthat , Farve blå
• Tabellen Produktkategori indeholder to rækker:
  • SKU CL-01, Kategori beklædning
  • SKU AC-01, Kategoritilbehør

Bemærk, at tabellen Produktkategori ikke indeholder en række for produktVAREVAREn CL-02. Vi diskuterer konsekvenserne af denne manglende række senere i denne artikel.

I ruden Felter finder rapportforfattere produktrelaterede felter i to tabeller: Produkt og Produktkategori.

Lad os se, hvad der sker, når felter fra begge tabeller føjes til en tabelvisualisering. I dette eksempel hentes KOLONNEN SKU fra tabellen Product .

Bemærk, at værdien Kategori for produkt-SKU'en CL-02 er BLANK. Det skyldes, at der ikke er nogen række i tabellen Produktkategori for dette produkt.

Anbefalinger

Når det er muligt, anbefaler vi, at du undgår at oprette en til en-modelrelationer, når rækkedata strækker sig over flere modeltabeller. Det skyldes, at dette design kan:

• Bidrag til rod i ruden Felter , der viser flere tabeller end nødvendigt
• Gør det svært for rapportforfattere at finde relaterede felter, fordi de distribueres på tværs af flere tabeller
• Begræns muligheden for at oprette hierarkier, da deres niveauer skal være baseret på kolonner fra den samme tabel
• Giver uventede resultater, når der ikke er et komplet match af rækker mellem tabellerne

Specifikke anbefalinger varierer, afhængigt af om en til en-relationen er en intern kildegruppe eller en tværgående kildegruppe. Du kan få flere oplysninger om evaluering af relationer under Modelrelationer i Power BI Desktop (evaluering af relationer).

En til en-relation for intern kildegruppe

Når der findes en en til en-relation for en intern kildegruppe mellem tabeller, anbefaler vi, at dataene konsolideres i en enkelt modeltabel. Det gøres ved at flette Power Query-forespørgslerne.

Følgende trin præsenterer en metode til at konsolidere og modellere de en til en-relaterede data:

1. Flet forespørgsler: Når du kombinerer de to forespørgsler, skal du overveje, om dataene i hver forespørgsel er fuldstændige. Hvis én forespørgsel indeholder et komplet sæt rækker (f.eks. en masterliste), skal du flette den anden forespørgsel med den. Konfigurer flettetransformationen til at bruge en venstre ydre joinforbindelse, som er standardjointypen for joinforbindelsen. Denne joinforbindelsestype sikrer, at du bevarer alle rækker i den første forespørgsel og supplerer dem med eventuelle tilsvarende rækker i den anden forespørgsel. Udvid alle påkrævede kolonner i den anden forespørgsel til den første forespørgsel.

2. Deaktiver indlæsning af forespørgsel: Sørg for at deaktivere indlæsningen af den anden forespørgsel. På denne måde indlæses resultatet ikke som en modeltabel. Denne konfiguration reducerer lagerstørrelsen for datamodellen og hjælper med at rydde op i ruden Felter .

   I vores eksempel finder rapportforfattere nu en enkelt tabel med navnet Produkt i ruden Felter . Den indeholder alle produktrelaterede felter.

   

3. Erstat manglende værdier: Hvis den anden forespørgsel indeholder rækker, der ikke stemmer overens, vises NULLs i de kolonner, der introduceres fra den. Overvej at erstatte NULLs med en tokenværdi, når det er relevant. Det er især vigtigt at erstatte manglende værdier, når rapportforfattere filtrerer eller grupperer efter kolonneværdier, da TOMME værdier kan vises i rapportvisualiseringer.

   Bemærk, at kategorien for produkt-SKU'en CL-02 nu læser [Udefineret] i følgende tabelvisualisering. I forespørgslen blev null-kategorier erstattet med denne tokentekstværdi.

   

4. Opret hierarkier: Hvis der findes relationer mellem kolonnerne i den nu konsoliderede tabel, kan du overveje at oprette hierarkier. På denne måde identificerer rapportforfattere hurtigt muligheder for analyse af rapportvisualiseringer.

   I vores eksempel kan rapportforfattere nu bruge et hierarki, der har to niveauer: Kategori og Produkt.

   

Hvis du kan lide, hvordan separate tabeller hjælper med at organisere dine felter, anbefaler vi stadig, at du konsoliderer til en enkelt tabel. Du kan stadig organisere dine felter, men ved at bruge visningsmapper i stedet.

I vores eksempel kan rapportforfattere finde feltet Kategori i visningsmappen Marketing .

Hvis du stadig beslutter dig for at definere en til en-relationer i en intern kildegruppe i din model, skal du sikre, at der er matchende rækker i de relaterede tabeller, når det er muligt. Da en en til en intern kildegrupperelation evalueres som en almindelig relation, kan problemer med dataintegritet dukke op i dine rapportvisualiseringer som tomme værdier. Du kan se et eksempel på en BLANK-gruppering i den første tabelvisualisering, der præsenteres i denne artikel.

En til en-relation på tværs af kildegrupper

Når der findes en en til en-relation på tværs af kildegrupper mellem tabeller, er der ikke noget alternativt modeldesign – medmindre du konsoliderer dataene på forhånd i dine datakilder. Power BI evaluerer en til en-modelrelationen som en begrænset relation. Sørg derfor for at sikre, at der er tilsvarende rækker i de relaterede tabeller, da rækker, der ikke stemmer overens, fjernes fra forespørgselsresultater.

Lad os se, hvad der sker, når felter fra begge tabeller føjes til en tabelvisualisering, og der findes en begrænset relation mellem tabellerne.

Tabellen viser kun to rækker. ProduktVARENUMMER CL-02 mangler, fordi der ikke er nogen tilsvarende række i tabellen Produktkategori .

Relateret indhold

Du kan få flere oplysninger, der er relateret til denne artikel, i følgende ressourcer:

• Modelrelationer i Power BI Desktop
• Forstå stjerneskemaet og vigtigheden af Power BI
• Vejledning til fejlfinding af relationer
• Spørgsmål? Prøv at spørge Power BI-community'et
• Forslag? Bidrag med idéer til forbedring af Power BI