Vägledning för en-till-en-relation

Den här artikeln riktar sig till dig som datamodellerare som arbetar med Power BI Desktop. Det ger dig vägledning om hur du arbetar med en-till-en-modellrelationer. En en-till-en-relation kan skapas när båda tabellerna innehåller en kolumn med gemensamma och unika värden.

Kommentar

En introduktion till modellrelationer beskrivs inte i den här artikeln. Om du inte är helt bekant med relationer, deras egenskaper eller hur du konfigurerar dem rekommenderar vi att du först läser artikeln Modellrelationer i Power BI Desktop .

Det är också viktigt att du har en förståelse för star-schemadesign. Mer information finns i Förstå star-schema och vikten för Power BI.

Det finns två scenarier som omfattar en-till-en-relationer:

• Degenererade dimensioner: Du kan härleda en degenererad dimension från en tabell av faktatyp.

• Raddata sträcker sig över tabeller: En enskild affärsentitet eller ämne läses in som två (eller flera) modelltabeller, möjligen på grund av att deras data kommer från olika datalager. Det här scenariot kan vara vanligt för tabeller av dimensionstyp. Till exempel lagras huvudproduktinformation i ett driftförsäljningssystem och kompletterande produktinformation lagras i en annan källa.

  Det är dock ovanligt att du relaterar två tabeller av faktatyp med en en-till-en-relation. Det beror på att båda tabellerna av faktatyp skulle behöva ha samma dimensionalitet och kornighet. Dessutom skulle varje tabell av faktatyp behöva unika kolumner för att modellrelationen ska kunna skapas.

Degenerera dimensioner

När kolumner från en tabell av faktatyp används för filtrering eller gruppering kan du överväga att göra dem tillgängliga i en separat tabell. På så sätt separerar du kolumner som används för filter eller gruppering, från de kolumner som används för att sammanfatta faktarader. Den här separationen kan:

• Minska lagringsutrymmet
• Förenkla modellberäkningar
• Bidra till bättre frågeprestanda
• Leverera en mer intuitiv fönsterupplevelse för fält till rapportförfattarna

Överväg en källförsäljningstabell som lagrar försäljningsorderinformation i två kolumner.

Kolumnen OrderNumber lagrar ordernumret och kolumnen OrderLineNumber lagrar en sekvens med rader i ordern.

I följande modelldiagram ser du att kolumnerna ordernummer och orderradsnummer inte har lästs in i tabellen Försäljning . I stället användes deras värden för att skapa en surrogatnyckelkolumn med namnet SalesOrderLineID. (Nyckelvärdet beräknas genom att du multiplicerar ordernumret med 1 000 och sedan lägger till orderradsnumret.)

Tabellen Försäljningsorder ger en omfattande upplevelse för rapportförfattare med tre kolumner: Försäljningsorder, Försäljningsorderrad och Radnummer. Den innehåller också en hierarki. Dessa tabellresurser stöder rapportdesigner som behöver filtrera, gruppera efter eller öka detaljnivån genom order- och orderrader.

Eftersom tabellen Försäljningsorder härleds från försäljningsdata bör det finnas exakt samma antal rader i varje tabell. Dessutom bör det finnas matchande värden mellan varje SalesOrderLineID-kolumn .

Raddata sträcker sig över tabeller

Överväg ett exempel som omfattar två en-till-en-relaterade tabeller av dimensionstyp: Produkt och Produktkategori. Varje tabell representerar importerade data och har en SKU-kolumn (Lagerhållningsenhet) som innehåller unika värden.

Här är ett partiellt modelldiagram över de två tabellerna.

Den första tabellen heter Product och innehåller tre kolumner: Färg, Produkt och SKU. Den andra tabellen heter Produktkategori och innehåller två kolumner: Kategori och SKU. En en-till-en-relation relaterar de två SKU-kolumnerna . Relationen filtrerar i båda riktningarna, vilket alltid är fallet för en-till-en-relationer.

För att beskriva hur relationsfilterspridningen fungerar har modelldiagrammet ändrats för att visa tabellraderna. Alla exempel i den här artikeln baseras på dessa data.

Kommentar

Det går inte att visa tabellrader i Power BI Desktop-modelldiagrammet. Det görs i den här artikeln för att stödja diskussionen med tydliga exempel.

Radinformationen för de två tabellerna beskrivs i följande punktlista:

• Tabellen Produkt har tre rader:
  • SKU CL-01, Produkt T-shirt, Färg grön
  • SKU CL-02, Produktjeans, Färgblå
  • SKU AC-01, Product Hat, Färg blå
• Tabellen Produktkategori har två rader:
  • SKU CL-01, Kategorikläder
  • SKU AC-01, kategoritillbehör

Observera att tabellen Produktkategori inte innehåller någon rad för produktenSKU CL-02. Vi går igenom konsekvenserna av den här saknade raden senare i den här artikeln.

I fönstret Fält hittar rapportförfattarna produktrelaterade fält i två tabeller: Produkt - och produktkategori.

Nu ska vi se vad som händer när fält från båda tabellerna läggs till i ett visuellt tabellobjekt. I det här exemplet hämtas SKU-kolumnen från tabellen Produkt .

Observera att kategorivärdet för produkten SKU CL-02 är BLANK. Det beror på att det inte finns någon rad i tabellen Produktkategori för den här produkten.

Rekommendationer

När det är möjligt rekommenderar vi att du undviker att skapa en-till-en-modellrelationer när raddata sträcker sig över modelltabeller. Det beror på att den här designen kan:

• Bidra till fältfönstrets oreda och visa fler tabeller än nödvändigt
• Gör det svårt för rapportförfattare att hitta relaterade fält, eftersom de är distribuerade över flera tabeller
• Begränsa möjligheten att skapa hierarkier, eftersom deras nivåer måste baseras på kolumner från samma tabell
• Skapa oväntade resultat när det inte finns en fullständig matchning av rader mellan tabellerna

Specifika rekommendationer varierar beroende på om en-till-en-relationen är intrakällgrupp eller korskällgrupp. Mer information om relationsutvärdering finns i Modellrelationer i Power BI Desktop (Relationsutvärdering).

En-till-en-relation inom källgruppen

När det finns en en-till-en-intrakällgrupprelation mellan tabeller rekommenderar vi att du konsoliderar data till en enda modelltabell. Det görs genom att slå samman Power Query-frågorna.

Följande steg visar en metod för att konsolidera och modellera en-till-en-relaterade data:

1. Sammanfoga frågor: När du kombinerar de två frågorna bör du tänka på datas fullständighet i varje fråga. Om en fråga innehåller en fullständig uppsättning rader (till exempel en huvudlista) sammanfogar du den andra frågan med den. Konfigurera sammanslagningsomvandlingen så att den använder en vänster yttre koppling, vilket är standardkopplingstypen. Den här kopplingstypen ser till att du behåller alla rader i den första frågan och kompletterar dem med matchande rader i den andra frågan. Expandera alla obligatoriska kolumner i den andra frågan till den första frågan.

2. Inaktivera frågebelastning: Se till att inaktivera inläsningen av den andra frågan. På så sätt läses inte resultatet in som en modelltabell. Den här konfigurationen minskar lagringsstorleken för datamodellen och hjälper till att rensa fönstret Fält .

   I vårt exempel hittar rapportförfattare nu en enda tabell med namnet Produkt i fönstret Fält . Den innehåller alla produktrelaterade fält.

   

3. Ersätt saknade värden: Om den andra frågan har omatchade rader visas NULL:er i kolumnerna som introduceras från den. När det är lämpligt bör du överväga att ersätta NULL:er med ett tokenvärde. Det är särskilt viktigt att ersätta saknade värden när rapportförfattare filtrerar eller grupperar efter kolumnvärden, eftersom BLANK:er kan visas i visuella rapportobjekt.

   I följande visuella tabellobjekt ser du att kategorin för produkten SKU CL-02 nu läser [Odefinierad]. I frågan ersattes null-kategorier med det här tokentextvärdet.

   

4. Skapa hierarkier: Om det finns relationer mellan kolumnerna i den nu konsoliderade tabellen bör du överväga att skapa hierarkier. På så sätt kan rapportförfattare snabbt identifiera möjligheter för visuell rapportgranskning.

   I vårt exempel kan rapportförfattare nu använda en hierarki som har två nivåer: Kategori och Produkt.

   

Om du gillar hur separata tabeller hjälper dig att organisera dina fält rekommenderar vi fortfarande att du konsoliderar till en enda tabell. Du kan fortfarande ordna dina fält, men med hjälp av visningsmappar i stället.

I vårt exempel kan rapportförfattare hitta fältet Kategori i visningsmappen Marknadsföring .

Om du fortfarande bestämmer dig för att definiera en-till-en-relationer mellan källgrupper i din modell bör du när det är möjligt se till att det finns matchande rader i de relaterade tabellerna. Eftersom en en-till-en-intrakällgruppsrelation utvärderas som en vanlig relation kan dataintegritetsproblem uppstå i dina visuella rapportobjekt som BLANK:er. (Du kan se ett exempel på en BLANK-gruppering i det första visuella tabellobjektet som visas i den här artikeln.)

En-till-en-relation mellan källgrupper

När det finns en en-till-en-relation mellan källgrupper mellan tabeller finns det ingen alternativ modelldesign – såvida du inte konsoliderar data i dina datakällor i förväg. Power BI utvärderar en-till-en-modellrelationen som en begränsad relation. Se därför till att det finns matchande rader i de relaterade tabellerna, eftersom omatchade rader kommer att elimineras från frågeresultat.

Nu ska vi se vad som händer när fält från båda tabellerna läggs till i ett visuellt tabellobjekt och det finns en begränsad relation mellan tabellerna.

Tabellen visar endast två rader. Produkt-SKU CL-02 saknas eftersom det inte finns någon matchande rad i tabellen Produktkategori .

Relaterat innehåll

Mer information om den här artikeln finns i följande resurser:

• Modellrelationer i Power BI Desktop
• Förstå star-schema och vikten för Power BI
• Vägledning för relationsfelsökning
• Frågor? Prova att fråga Power BI Community
• Förslag? Bidra med idéer för att förbättra Power BI