Del via

Vejledning til aktive forhold i forhold til inaktive relationer

  • Artikel

Denne artikel henvender sig til dig som dataudformer, der arbejder med Power BI Desktop. Den indeholder en vejledning i, hvornår du skal oprette aktive eller inaktive modelrelationer. Aktive relationer overfører som standard filtre til andre tabeller. Inaktive relationer overfører dog kun filtre, når et DAX-udtryk aktiverer (bruger) relationen.

Seddel

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

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.

Aktive relationer

Generelt anbefaler vi, at du definerer aktive relationer, når det er muligt. De udvider omfanget og potentialet for, hvordan din model kan bruges af rapportforfattere, og brugere, der arbejder med Q&A.

Se et eksempel på en importmodel, der er designet til at analysere flys ydeevne til tiden (OTP). Modellen har en Flight tabel, som er en faktatabel, der gemmer én række pr. flight. Hver række registrerer flydato, flynummer, afgangs- og ankomstlufthavne og eventuel forsinkelsestid (i minutter). Der er også en Airport tabel, som er en dimensionstabel, der gemmer én række pr. lufthavn. Hver række beskriver lufthavnskoden, lufthavnsnavnet og landet eller området.

Her er et delvist modeldiagram over de to tabeller.

diagram, der viser en model, der indeholder to tabeller: Flight og Airport. Relationsdesignet er beskrevet i følgende afsnit.

Der er to modelrelationer mellem tabellerne Flight og Airport. I tabellen Flight er kolonnerne DepartureAirport og ArrivalAirport relateret til kolonnen Airport i tabellen Airport. I design af stjerneskemaer beskrives tabellen Airport som en dimension med forskellige roller. I denne model er de to roller afgangslufthavn og ankomstlufthavn.

Selvom dette design fungerer godt til design af relationsstjerneskemaer, fungerer det ikke godt for Power BI-modeller. Det skyldes, at modelrelationer er stier til filteroverførsel, og disse stier skal være deterministiske. Du kan finde flere oplysninger om at sikre, at filteroverførselsstier er deterministiske, under løse flertydigheden af relationsstien. Som vist i dette eksempel er én relation derfor aktiv, mens den anden er inaktiv (repræsenteret af den stiplede linje). Det er specifikt relationen til den ArrivalAirport kolonne, der er aktiv, hvilket betyder, at filtre, der anvendes på tabellen Airport, automatisk overføres til kolonnen ArrivalAirport i tabellen Flight.

Dette modeldesign medfører alvorlige begrænsninger for, hvordan dataene kan rapporteres. Det er specifikt ikke muligt at filtrere tabellen Airport for automatisk at isolere flyoplysninger for en afgangslufthavn. Da rapporter skal filtrere (eller gruppere) efter afgangs- og ankomstlufthavne samtidig, kræves der to aktive relationer. Hvis du oversætter dette krav til et Power BI-modeldesign, betyder det, at modellen skal have to lufthavnstabeller.

Her er det forbedrede modeldesign.

diagram, der viser en model, der indeholder fire tabeller: Dato, Fly, Afgangslufthavn og Ankomstlufthavn.

Modellen har nu to lufthavnstabeller: Departure Airport og Arrival Airport. Hver modelrelation mellem disse tabeller og den Flight tabel er aktiv. Bemærk også, at kolonnenavnene i tabellerne Departure Airport og Arrival Airport har et præfiks med ordet Afgang eller Ankomst.

Det forbedrede modeldesign understøtter udarbejdelse af følgende rapportdesign.

diagram, der viser en rapportside, indeholder to udsnit og en tabelvisualisering. Udsnitsværktøjet er Måned og Afgangslufthavn.

Rapportsiden filtrerer efter Melbourne som afgangslufthavn, og tabelvisualiseringen grupperer efter ankomstlufthavne.

Seddel

I forbindelse med importmodeller har tilføjelsen af en anden dimensionstabel medført en øget modelstørrelse og længere opdateringstider. Det modsiger derfor de anbefalinger, der er beskrevet i artiklen Teknikker til datareduktion af importmodellering. Men i eksemplet tilsidesætter kravet om kun at have aktive relationer disse anbefalinger.

Det er desuden almindeligt, at dimensionstabeller gemmer lave rækkeantal i forhold til antallet af rækker i faktatabeller. Derfor er den øgede modelstørrelse og opdateringstider sandsynligvis ikke for store.

Omstruktureringsmetode

Her er en metode til omstrukturering af en model fra en enkelt dimensionstabel med forskellige roller til et design med én tabel pr. rolle.

  1. Fjern inaktive relationer.

  2. Overvej at omdøbe dimensionstabellen med forskellige roller for bedre at beskrive dens rolle. I eksemplet i denne artikel er tabellen Airport relateret til kolonnen ArrivalAirport i tabellen Flight, så den omdøbes til Arrival Airport.

  3. Opret en kopi af tabellen med forskellige roller, der giver den et navn, der afspejler dens rolle. Hvis det er en importtabel, anbefaler vi, at du opretter en beregnet tabel. Hvis det er en DirectQuery-tabel, kan du duplikere Power Query-forespørgslen.

    I eksemplet blev den Departure Airport tabel oprettet ved hjælp af følgende beregnede tabeldefinition.

    Departure Airport = 'Arrival Airport'

  4. Opret en aktiv relation for at relatere den nye tabel.

  5. Overvej at omdøbe kolonnerne i tabellerne, så de afspejler deres rolle præcist. I eksemplet i denne artikel har alle kolonner ordet Afgang eller Ankomst. Disse navne sikrer, at rapportvisualiseringer som standard har selvbeskrivende og ikke-tvetydige mærkater. Det forbedrer også Q&A-oplevelsen, så brugerne nemt kan skrive præcise spørgsmål.

  6. Overvej at føje beskrivelser til tabeller med forskellige roller. I ruden Data vises der en beskrivelse i et værktøjstip, når en rapportforfatter holder markøren over tabellen. På denne måde kan du kommunikere andre oplysninger om filteroverførsel til rapportforfattere.

Inaktive relationer

I specifikke situationer kan inaktive relationer håndtere specifikke rapporteringsbehov.

Overvej forskellige model- og rapporteringskrav:

  • En salgsmodel indeholder en Sales tabel med to datokolonner: OrderDate og ShipDate.
  • Hver række i tabellen Sales registrerer en enkelt rækkefølge.
  • Datofiltre anvendes næsten altid på kolonnen OrderDate, som altid gemmer en gyldig dato.
  • Kun én måling kræver overførsel af datofilteret til kolonnen ShipDate, som kan indeholde TOMME værdier (indtil ordren leveres).
  • Der er intet krav om samtidig at filtrere (eller gruppere) ordre og afsendelsesdatoperioder.

Her er et delvist modeldiagram over de to tabeller.

diagram, der viser en model, der indeholder to tabeller: Salg og Dato. Tabellen Sales indeholder seks målinger.

Der er to modelrelationer mellem tabellerne Sales og Date. I tabellen Sales er kolonnerne OrderDate og ShipDate relateret til kolonnen Date i tabellen Date. I denne model er de to roller for tabellen Dateordredato og afsendelsesdato. Det er relationen til den OrderDate kolonne, der er aktiv.

Alle de seks målinger – undtagen én – skal filtrere efter den OrderDate kolonne. Den Orders Shipped måling skal dog filtrere efter kolonnen ShipDate.

Her er definitionen af Orders måling. Det tæller blot rækkerne i tabellen Sales i filterkonteksten. Alle filtre, der anvendes på den Date tabel, overføres til kolonnen OrderDate.

Orders = COUNTROWS(Sales)

Her er definitionen af Orders Shipped måling. Den bruger DAX-funktionen USERELATIONSHIP, som aktiverer filteroverførsel for en bestemt relation, men kun under evalueringen af udtrykket. I dette eksempel bruges relationen til kolonnen ShipDate.

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

Dette modeldesign understøtter udarbejdelse af følgende rapportdesign.

diagram, der viser en rapportside med ét udsnit og en tabelvisualisering. Udsnittet er Kvartal, og tabelvisualiseringen viser månedlige salgsstatistikker.

Rapportsiden filtrerer efter kvartal 2019 Q4. Tabelvisualiseringen grupperer efter måned og viser forskellige salgsstatistikker. De Orders og Orders Shipped målinger giver forskellige resultater. De bruger hver især den samme opsummeringslogik (antal rækker i den Sales tabel), men forskellige Date tabelfilteroverførsel.

Bemærk, at udsnittet for kvartalet indeholder en BLANK-indstilling. Denne indstilling for udsnit vises som et resultat af tabeludvidelse. Selvom hver Sales tabelrække har en gyldig ordredato, har nogle rækker en TOM afsendelsesdato – disse ordrer er endnu ikke afsendt. Tabeludvidelse tager også inaktive relationer i betragtning, og derfor kan TOMME værdier vises på grund af TOMME værdier på mange-siden af relationen (eller på grund af problemer med dataintegritet).

Seddel

Filtre på rækkeniveau (RLS) overføres kun via aktive relationer. RLS-filtre overføres aldrig for inaktive relationer, selvom USERELATIONSHIP- DAX-funktion bruges af en målingsdefinition.

Anbefalinger

Vi anbefaler, at du definerer aktive relationer, når det er muligt, især når der er defineret RLS-roller for din datamodel. De udvider omfanget og potentialet for, hvordan din model kan bruges af rapportforfattere, og brugere, der arbejder med Q&A. Det betyder, at dimensionstabeller med forskellige roller skal duplikeres i din model.

I bestemte situationer kan du dog definere en eller flere inaktive relationer for en dimensionstabel med forskellige roller. Du kan overveje denne fremgangsmåde, når:

  • Der er ikke noget krav om, at rapportvisualiseringer filtrerer efter forskellige roller samtidigt.
  • Du kan bruge DAX-funktionen USERELATIONSHIP til at aktivere en bestemt relation for relevante modelberegninger.

Relateret indhold

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