Vejledning til aktive forhold i forhold til inaktive relationer
Denne artikel henvender sig til dig som datamodel, 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.
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.
Aktive relationer
Generelt anbefaler vi, at du definerer aktive relationer, når det er muligt. De udvider omfanget af og potentialet for, hvordan din model kan bruges af rapportforfattere og brugere, der arbejder med Q&A.
Overvej et eksempel på en importmodel, der er designet til at analysere flyafgange til tiden (OTP). Modellen har en tabel af typen Flight , som er en tabel af faktatypen, 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 tabel af typen Lufthavn , som er en tabel af dimensionstypen, 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.
Der er to modelrelationer mellem tabellerne Flight og Airport . I tabellen Fly er kolonnerne Afgangslufthavn og Ankomstlufthavn relateret til kolonnen Lufthavn i tabellen Lufthavn . I design af stjerneskemaer beskrives tabellen Lufthavn 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, er det ikke til 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, hvordan du sikrer, at filteroverførselsstier er deterministiske, under Løs flertydigheden af relationsstien. Som beskrevet i dette eksempel er én relation derfor aktiv, mens den anden er inaktiv (repræsenteret af den stiplede linje). Det er specifikt relationen til kolonnen ArrivalAirport , der er aktiv. Det betyder, at filtre, der anvendes på tabellen Lufthavn , 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 Lufthavn for automatisk at isolere flyoplysninger for en afgangslufthavn. Da rapporteringskravene omfatter filtrering (eller gruppering) efter afgangs- og ankomstlufthavne på samme tid, er der behov for 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.
Modellen har nu to lufthavnstabeller: Afgangslufthavn og Ankomstlufthavn. Modelrelationerne mellem disse tabeller og tabellen Flight er aktive. Bemærk også, at kolonnenavnene i tabellerne Afgangslufthavn og Ankomstlufthavn har præfikset Afgang eller Ankomst.
Det forbedrede modeldesign understøtter udarbejdelse af følgende rapportdesign.
Rapportsiden filtrerer efter Melbourne som afgangslufthavn, og tabelvisualiseringen grupperer efter ankomstlufthavne.
Bemærk
For importmodeller har den ekstra tabel medført en øget modelstørrelse og længere opdateringstider. Det modsiger derfor de anbefalinger, der er beskrevet i artiklen Teknikker til reduktion af data til importmodellering . Men i eksemplet tilsidesætter kravet om kun at have aktive relationer disse anbefalinger.
Det er desuden almindeligt, at tabeller af dimensionstypen indeholder lave rækkeantal i forhold til antallet af tabelrækker af faktatypen. 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 tabel af dimensionstypen med forskellige roller til et design med én tabel pr. rolle.
Fjern inaktive relationer.
Overvej at omdøbe tabellen af dimensionstypen for at beskrive dens rolle bedre. I eksemplet er tabellen Lufthavn relateret til kolonnen ArrivalAirport i tabellen Flight , så den omdøbes til Ankomstlufthavn.
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 definerer en beregnet tabel. Hvis det er en DirectQuery-tabel, kan du duplikere Power Query-forespørgslen.
I eksemplet blev tabellen Afgangslufthavn oprettet ved hjælp af følgende beregnede tabeldefinition.
Departure Airport = 'Arrival Airport'Opret en aktiv relation for at relatere den nye tabel.
Overvej at omdøbe kolonnerne i tabellerne, så de afspejler deres rolle præcist. I eksemplet er alle kolonner præfikset med 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 deres spørgsmål.
Overvej at føje beskrivelser til tabeller med forskellige roller. (I vinduet Ruden Felter vises en beskrivelse i et værktøjstip, når en rapportforfatter holder markøren over tabellen.) På denne måde kan du kommunikere yderligere oplysninger om filteroverførsel til rapportforfatterne.
Inaktive relationer
I særlige tilfælde kan inaktive relationer håndtere særlige rapporteringsbehov.
Lad os nu overveje forskellige model- og rapporteringskrav:
- En salgsmodel indeholder en tabel af typen Sales , der har to datokolonner: OrderDate og ShipDate
- Hver række i tabellen Sales registrerer en enkelt ordre
- Datofiltre anvendes næsten altid på kolonnen OrderDate , som altid gemmer en gyldig dato
- Kun én måling kræver overførsel af datofilter til kolonnen ShipDate , som kan indeholde TOMME værdier (indtil ordren leveres)
- Der er ikke noget krav om samtidig at filtrere (eller gruppere efter) ordre - og afsendelsesdatoperioder
Her er et delvist modeldiagram over de to tabeller.
Der er to modelrelationer mellem tabellerne Sales og Date . I tabellen Sales relaterer kolonnerne OrderDate og ShipDate til kolonnen Date i tabellen Date . I denne model er de to roller for tabellen Date ordredato og afsendelsesdato. Det er relationen til kolonnen OrderDate , der er aktiv.
Alle de seks målinger – undtagen én – skal filtrere efter kolonnen OrderDate . Målingen Afsendte ordrer skal dog filtrere efter kolonnen ShipDate .
Her er målingsdefinitionen Ordrer . Det tæller blot rækkerne i tabellen Sales i filterkonteksten. Alle filtre, der anvendes på tabellen Date , overføres til kolonnen OrderDate .
Orders = COUNTROWS(Sales)
Her er målingsdefinitionen Afsendte ordrer . Den bruger DAX-funktionen USERELATIONSHIP , som kun aktiverer filteroverførsel for en bestemt relation 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.
Rapportsiden filtrerer efter kvartal 2019 Q4. Tabelvisualiseringen grupperer efter måned og viser forskellige salgsstatistikker. Målingerne Ordrer og Afsendte ordrer giver forskellige resultater. De bruger hver især den samme opsummeringslogik (antal rækker i tabellen Sales ), men forskellig filteroverførsel af tabellen Date .
Bemærk, at udsnittet for kvartalet indeholder et BLANK-element. Dette udsnit vises som et resultat af tabeludvidelsen. Hver række i tabellen Sales har en ordredato, men nogle rækker har en BLANK-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.
Bemærk
Sikkerhedsfiltre på rækkeniveau overføres kun via aktive relationer. Sikkerhedsfiltre på rækkeniveau overføres ikke for inaktive relationer, selvom UseRelationship udtrykkeligt føjes til en målingsdefinition.
Anbefalinger
Sammenfattende anbefaler vi, at du definerer aktive relationer, når det er muligt, især når sikkerhedsroller på rækkeniveau er defineret for din datamodel. De udvider omfanget af og potentialet for, hvordan din model kan bruges af rapportforfattere og brugere, der arbejder med Q&A. Det betyder, at tabeller af dimensionstypen med forskellige roller skal duplikeres i din model.
I bestemte situationer kan du dog definere en eller flere inaktive relationer for en tabel af dimensionstypen med forskellige roller. Du kan overveje dette design, 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:
Feedback
Kommer snart: I hele 2024 udfaser vi GitHub-problemer som feedbackmekanisme for indhold og erstatter det med et nyt feedbacksystem. Du kan få flere oplysninger under: https://aka.ms/ContentUserFeedback.
Indsend og få vist feedback om