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 faktatabell.

• Raddata sträcker sig över tabeller: En enskild affärsentitet eller ett ä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 dimensionstabeller. Till exempel lagras huvudproduktinformation i ett driftförsäljningssystem och kompletterande produktinformation lagras i en annan källa.

  Det är dock ovanligt att du kopplar två faktatabeller genom en en-till-en-relation. Det beror på att båda faktatabellerna skulle behöva ha samma dimensionalitet och kornighet. Dessutom skulle varje faktatabell behöva unika kolumner för att modellrelationen ska kunna skapas.

Degenerera dimensioner

När kolumner från en faktatabell 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 filtrering 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.
• Ge rapportförfattarna en mer intuitiv Data-fönsterupplevelse.

Överväg en källtabell med namnet Sales som lagrar försäljningsorderradens referensinformation i två kolumner.

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

Observera att kolumnerna ordernummer och orderradsnummer inte har lästs in i tabellen Sales i följande bild. I stället användes deras värden för att skapa en surrogatnyckel kolumn med namnet OrderLineNumberID. (Nyckelvärdet beräknas genom att du multiplicerar ordernumret med 1 000 och sedan lägger till orderradsnumret.)

Dimensionstabellen Sales Order erbjuder en omfattande upplevelse för författarna av rapporter och har två kolumner: Sales Order och Sales Order Line. Dessa specifika kolumner stöder rapportdesign som behöver filtrera, gruppera eller öka detaljnivån genom order- och orderrader.

Eftersom den Sales Order tabellen 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 OrderLineNumberID kolumn.

Raddata sträcker sig över tabeller

Tänk dig ett exempel som omfattar två en-till-en-relaterade dimensionstabeller: Product och Product Category. Varje tabell representerar importerade data och har en kolumn för SKU (lagerhållningsenhet) som innehåller unika värden.

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

Den första tabellen heter Productoch innehåller tre kolumner: Color, Productoch SKU. Den andra tabellen heter Product Categoryoch innehåller två kolumner: Category och SKU. En en-till-en-relation förbinder 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 distributionen av relationsfiltret fungerar visar följande bild några tabellrader. Alla exempel i den här artikeln baseras på dessa data.

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

• Tabellen Product har tre rader:
  • SKU CL-01, ProductT-shirt, ColorGrön
  • SKU CL-02, ProductJeans, ColorBlue
  • SKU AC-01, ProductHatt, ColorBlå
• Tabellen Product Category har två rader:
  • SKU CL-01, CategoryKläder
  • SKU AC-01, CategoryTillbehör

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

I fönstret Data hittar rapportförfattarna produktrelaterade fält i två tabeller: Product och Product Category. 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 kolumnen SKU från tabellen Product.

Observera att Category värdet för produkt-SKU CL-02 är BLANK. Det beror på att det inte finns någon motsvarande rad i tabellen Product Category 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 datafö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.
• Generera 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.

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. Du kan göra det 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. Ange kopplingsomvandlingen så att den använder en vänster yttre koppling, som ä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 Data .

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

3. Ersätt saknade värden: Om den andra frågan har omatchade rader visas null-värden i kolumnerna som introduceras från den. När det är lämpligt bör du överväga att ersätta null-värden 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.

   Observera att kategorin för produkt-SKU CL-02 nu står det [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: Category och Product.

   

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 Category i Marketing visningsmapp.

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-korskällgrupp relation mellan tabeller finns det ingen alternativ modelldesign – såvida du inte konsoliderar data i datakällan 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 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.

Det första visuella tabellobjektet, som använder en grupprelation mellan källor, visar endast två rader. Produkt-SKU CL-02 saknas eftersom det inte finns någon matchande rad i tabellen Product Category. Det andra visuella tabellobjektet, baserat på en enda konsoliderad tabell i modellen, visar tre rader.

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 Fabric-gemenskapen
• Förslag? Bidra med idéer för att förbättra Textil