Skille rapporter fra modeller i Power BI Desktop
Når du oppretter en ny Power BI Desktop-løsning, er en av de første oppgavene du må gjøre, å hente data. Å hente data kan resultere i to forskjellige resultater. Det kan:
- Opprett en live-tilkobling til en allerede publisert modell, som enten kan være en Semantisk Power BI-modell eller en ekstern analysis services-modell.
- Start utviklingen av en ny modell, som enten kan være en Import-, DirectQuery- eller Composite-modell.
Denne artikkelen er opptatt av det andre scenarioet. Den gir veiledning om hvorvidt en rapport og modell skal kombineres til én enkelt Power BI Desktop-fil.
Enkel filløsning
En enkelt filløsning fungerer bra når det bare er én enkelt rapport basert på modellen. I dette tilfellet er det sannsynlig at både modellen og rapporten er innsatsen til samme person. Vi definerer det som en Personlig BI-løsning , selv om rapporten kan deles med andre. Slike løsninger kan representere rapporter med rolleomfang eller engangsvurderinger av en forretningsutfordring – ofte beskrevet som ad hoc-rapporter .
Separate rapportfiler
Det er fornuftig å skille modell- og rapportutvikling i separate Power BI Desktop-filer når:
- Datamodellerere og rapportforfattere er forskjellige personer.
- Det er forstått at en modell vil være kilden for flere rapporter, nå eller i fremtiden.
Datamodellerere kan fortsatt bruke redigeringsopplevelsen for Power BI Desktop-rapporten til å teste og validere modellutformingene. Men like etter at de har publisert filen til Power Bi-tjeneste bør de fjerne rapporten fra arbeidsområdet. Og de må huske å fjerne rapporten hver gang de publiserer på nytt og overskriver den semantiske modellen.
Behold modellgrensesnittet
Noen ganger er modellendringer uunngåelige. Datamodellerere må passe på, da, ikke bryte modellgrensesnittet. Hvis de gjør det, er det mulig at relaterte rapportvisualobjekter eller instrumentbordfliser brytes. Ødelagte visualobjekter vises som feil, og de kan føre til frustrasjon for rapportforfattere og forbrukere. Og verre – de kan redusere tilliten til dataene.
Så administrer modellendringer nøye. Hvis det er mulig, unngå følgende endringer:
- Gi nytt navn til tabeller, kolonner, hierarkier, hierarkinivåer eller mål.
- Endrer kolonnedatatyper.
- Endrer måluttrykk slik at de returnerer en annen datatype.
- Flytte mål til en annen hjemmetabell. Det er fordi flytting av et mål kan bryte rapportomfangede mål som fullt ut kvalifiserer mål med navnet på hjemmetabellen. Vi anbefaler ikke at du skriver DAX-uttrykk ved hjelp av fullstendige målnavn. Hvis du vil ha mer informasjon, kan du se DAX: Kolonne- og målreferanser.
Det er trygt å legge til nye tabeller, kolonner, hierarkier, hierarkinivåer eller mål, med ett unntak: Det er mulig at et nytt målnavn kan kollidere med et målnavn med rapportomfang. For å unngå kollisjon anbefaler vi at rapportforfattere vedtar en navnekonvensjon når de definerer tiltak i rapportene sine. De kan prefiksere målnavn med rapportomfang med et understrekingstegn eller andre tegn.
Hvis du må gjøre endringer i modellene dine, anbefaler vi deg enten:
- Vis relatert innhold for semantisk modell i Power Bi-tjeneste.
- Utforsk dataavstammingsvisning i Power Bi-tjeneste.
Begge alternativene lar deg raskt identifisere relaterte rapporter og instrumentbord. Dataavstammingsvisning er sannsynligvis det beste valget fordi det er enkelt å se kontaktpersonen for hvert relaterte element. Faktisk er det en hyperkobling som åpner en e-postmelding adressert til kontakten.
Vi anbefaler at du kontakter eieren av hvert relaterte element for å fortelle dem om eventuelle planlagte bruddendringer. På denne måten kan de være forberedt og klare til å reparere og publisere rapportene sine på nytt, noe som bidrar til å minimere nedetid og frustrasjon.
Relatert innhold
Hvis du vil ha mer informasjon om denne artikkelen, kan du se følgende ressurser: