Adskil rapporter fra modeller i Power BI Desktop
Når du opretter en ny Power BI Desktop-løsning, er en af de første opgaver, du skal udføre, "hent data". Hentning af data kan resultere i to forskellige resultater. Det kunne:
- Opret en direkte forbindelse til en allerede publiceret model, som enten kan være en semantisk Power BI-model eller en eksternt hostet Analysis Services-model.
- Begynd at udvikle en ny model, som kan være enten en import-, DirectQuery- eller sammensat model.
Denne artikel omhandler det andet scenarie. Den indeholder en vejledning i, om en rapport og model skal kombineres i en enkelt Power BI Desktop-fil.
Løsning med én 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 engangsvurderinger af en forretningsudfordring – ofte beskrevet som ad hoc-rapporter .
Adskil rapportfiler
Det giver mening at adskille model- og rapportudvikling til separate Power BI Desktop-filer, når:
- Dataudformere og rapportforfattere er forskellige personer.
- Det er underforstået, at en model vil være kilden til flere rapporter nu eller i fremtiden.
Dataudformere kan stadig bruge power BI Desktop-rapportredigeringsoplevelsen til at teste og validere deres modeldesign. Men lige efter publicering af deres fil til Power BI-tjeneste skal de fjerne rapporten fra arbejdsområdet. Og de skal huske at fjerne rapporten, hver gang de genudgiver og overskriver den semantiske model.
Bevar modelgrænsefladen
Nogle gange er modelændringer uundgåelige. Dataudformere skal være omhyggelige og ikke bryde modelgrænsefladen. Hvis de gør det, er det muligt, at relaterede rapportvisualiseringer eller dashboardfelter ødelægges. Brudte visualiseringer vises som fejl, og de kan resultere i frustration for rapportforfattere og -forbrugere. Og hvad værre er – de kan reducere tilliden til dataene.
Så administrer modelændringer omhyggeligt. Hvis det er muligt, skal du undgå følgende ændringer:
- Omdøbning af tabeller, kolonner, hierarkier, hierarkiniveauer eller målinger.
- Ændring af kolonnedatatyper.
- Ændring af målingsudtryk, så de returnerer en anden datatype.
- Flytte målinger til en anden hjemmetabel. Det skyldes, at flytning af en måling kan ødelægge rapportbaserede målinger, der fuldt ud kvalificerer målinger med navnet på deres hjemmetabel. Vi anbefaler ikke, at du skriver DAX-udtryk ved hjælp af fuldt kvalificerede navne på målinger. Du kan få flere oplysninger under DAX: Kolonne- og målingsreferencer.
Det er sikkert at tilføje nye tabeller, kolonner, hierarkier, hierarkiniveauer eller målinger med én undtagelse: Det er muligt, at et nyt målingsnavn kan kollidere med et rapportomfanget målingsnavn. For at undgå kollision anbefaler vi rapportforfattere at vedtage en navngivningskonvention, når de definerer målinger i deres rapporter. De kan præfiksere rapportbaserede målingsnavne med et understregningstegn eller nogle andre tegn.
Hvis du skal foretage banebrydende ændringer af dine modeller, anbefaler vi dig enten:
- Få vist relateret indhold for den semantiske model i Power BI-tjeneste.
- Udforsk visningen Dataafstamning i Power BI-tjeneste.
Begge indstillinger giver dig mulighed for hurtigt at identificere relaterede rapporter og dashboards. Dataafstamningsvisning er sandsynligvis det bedste valg, fordi det er nemt at se kontaktpersonen for hvert relateret element. Det er faktisk et link, der åbner en mail, der er adresseret til kontakten.
Vi anbefaler, at du kontakter ejeren af hvert relateret element for at fortælle dem om planlagte afbrydelsesændringer. På denne måde kan de forberedes og klar til at rette og publicere deres rapporter igen, hvilket hjælper med at minimere nedetid og frustration.
Relateret indhold
Du kan få flere oplysninger, der er relateret til denne artikel, i følgende ressourcer: