Adskille rapporter fra modeller i Power BI Desktop
Når du opretter en Power BI Desktop løsning, er "hent data" en af de første opgaver, du skal udføre. Dataindtægt kan resultere i to forskellige resultater. Det kunne:
- Opret en direkte forbindelse til en model, der allerede er publiceret, hvilket kan være et Power BI datasæt eller en fjern hostet Analysis Services model.
- Påbegynde udviklingen af en ny model, der enten kan være en import- eller DirectQuery-model eller en sammensat model.
Denne artikel beskæftiger sig med det andet scenarie. Den indeholder en vejledning i, om en rapport og model skal kombineres til en Power BI Desktop fil.
Løsning med en enkelt fil
En enkelt filløsning fungerer godt, når der kun er en enkelt rapport, der er baseret på modellen. I dette tilfælde er det sandsynligt, at både modellen og rapporten er den samme persons indsats. Vi definerer den som en personlig BI-løsning, selvom rapporten kan deles med andre. Sådanne løsninger kan repræsentere rollebaserede rapporter eller vurderinger af en forretningsudfordring én gang – hvilket ofte er beskrevet som ad hoc-rapporter.
Separate rapportfiler
Det giver mening at adskille model- og rapportudvikling i separate Power BI Desktop, når:
- Data modelers og rapportforfattere er forskellige personer.
- Der er en forståelse af, at en model vil være kilden til flere rapporter, nu eller i fremtiden.
Datamodeldesignere kan stadig bruge Power BI Desktop til oprettelse af rapporter til at teste og validere deres modeldesign. Men lige efter at de har publicere deres fil til Power BI-tjenesten, skal de fjerne rapporten fra arbejdsområdet. Og de skal huske at fjerne rapporten, hver gang de publicerer og overskriver datasættet.
Bevar modelgrænsefladen
Nogle gange er modelændringer forskellige. Data modelers skal derfor være forsigtige og ikke afbryde modelgrænsefladen. Hvis de gør det, er det muligt, at relaterede visualiseringer i rapporter eller dashboardfelter bliver brudt. Brudte visualiseringer vises som fejl, og de kan resultere i frustration for rapportforfattere og forbrugere. Og værre endnu – de kan reducere tilliden til dataene.
Du skal derfor administrere modelændringer omhyggeligt. Undgå følgende ændringer, hvis det er muligt:
- Omdøbning af tabeller, kolonner, hierarkier, hierarkiniveauer eller målinger.
- Ændring af kolonnedatatyper.
- Ændring af målingsudtryk, så de returnerer en anden datatype.
- Flytning af målinger til en anden hjemmetabel. Det skyldes, at flytning af en måling kan bryde rapportmål, der opfylder målingerne fuldt ud med deres navn på hjemmetabellen. Vi anbefaler, at du ikke skriver DAX-udtryk ved hjælp af fuldt kvalificerede navne på målinger. Du kan finde flere oplysninger under DAX: Kolonne- og målingsreferencer.
Det er sikkert at tilføje nye tabeller, kolonner, hierarkier, hierarkiniveauer eller målinger med en enkelt undtagelse: Det er muligt, at et nyt målingsnavn kolliderer med et rapportbaseret målingsnavn. Hvis du vil undgå kollisioner, anbefaler vi, at rapportforfattere indfører en navngivningskonvention, når de definerer målinger i deres rapporter. De kan foranstille rapportbaserede målingsnavne med et understregningstegn eller nogle andre tegn.
Hvis du skal ændre dine modeller, anbefaler vi enten, at du:
- Få vist relateret indhold for datasættet i Power BI service.
- Udforsk data af data af data-af data af data i Power BI datatjeneste.
Begge indstillinger giver dig mulighed for hurtigt at identificere relaterede rapporter og dashboards. Data af data-af data af data af datasæt er sandsynligvis det bedste valg, da det er nemt at se kontaktpersonen for hver relateret artefakt. Det er faktisk et link, der åbner en mail, der er sendt til kontakten.
Vi anbefaler, at du kontakter ejeren af hver relaterede artefakt for at give dem besked om eventuelle planlagte ændringer af brud. På denne måde kan de være forberedt og klar til at rette og genpublicere deres rapporter, hvilket hjælper med at minimere nedetid og frustration.
Næste trin
Du kan finde flere oplysninger, der er relateret til denne artikel, i følgende ressourcer: